Bug#630617: Fonds von Ihren verstorbenen Verwandten

[John Geoffrey]

[image: Inline image 1]

Bug#699038: Fonds von Ihren verstorbenen Verwandten

[John Geoffrey]

[image: Inline images 1]

Bug#880518: haskell-xml-hamlet: unsatisfiable B-D: libghc-xml-conduit-dev (<< 1.5) but sid has 1.5.1-1

[Steve Langasek]

Hi all,

FYI, this is resolved in the 0.4.1.1 new upstream release of
haskell-xml-hamlet, which is a microrelease to fix this exact problem in
xml-hamlet.cabal.  Packaging the new upstream version and dropping the <<
versioned dependency solves this bug.

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


signature.asc
Description: PGP signature

Bug#871502: Re : Bug#871502: zotero-standalone-build: The newer Zotero is standalone only ; a reorganization is neded.

[Félix Sipma]

On 2017-11-05 19:12+0100, Sébastien Villemot wrote:
>> As you may have already seen, this is a rather complex package.

Yes :-). Upstream seems to have completely modified the distribution, and now
provides one repo for each of zotero-standalone, zotero-connectors,
zotero-libreoffice-integration, which may help to go back to something more
sustainable. They also seem to have switched to javascript-only for
zotero-standalone, but they use a recent version of nodejs, so we need to wait
for #880936...

I'd like to move to something manageable, with git-buildpackage.

A first step would be to add a new source package for
zotero-libreoffice-integration, and to upload this one to experimental. This
one may build with the bits taken from the current zotero-standalone-build 
source package.

Do you have objections if I start from the beginning for this package? I'll
import the changelog and the other needed bits from zotero-standalone-build but
we'll lose the git history.

I've asked the Debian Science administrators to join.

>> The first step is to update the machinery under the get-orig-source target of
>> debian/rules, in order to get a new orig tarball.
>> 
>> And the most painful part is to deal with all the minified javascript that is
>> spread across the various translators, and which are problematic from a DFSG
>> perspective. See debian/source/lintian-overrides and the files under
>> debian/missing-sources/*. This is a grunt work that has to be updated with
>> every new release; I did not check if there is much to update for the 5.0
>> release.
> 
> I forgot to mention the debian/copyright file, which is also a tad painful to
> update.

Hopefully, the new zotero will be easier to deal with... We'll see how it goes
;-).


signature.asc
Description: PGP signature

Bug#880951: transition: armadillo

[Kumar Appaiah]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please help me effect a transision of armadillo to unstable. All
reverse dependencies should build fine, based on my tests.

Thanks.

Kumar

Ben file:

title = "armadillo";
is_affected = .depends ~ "libarmadillo7" | .depends ~ "libarmadillo8";
is_good = .depends ~ "libarmadillo8";
is_bad = .depends ~ "libarmadillo7";


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

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

-- 
Kumar Appaiah

Bug#880950: shellcheck: Incorrect parsing of default value in variable

[Martin Schwenke]

Package: shellcheck
Version: 0.4.6-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

Here's a snippet or screenshot that shows the problem:

#!/bin/sh
b=$(d=$(dirname "$0") ; cd -P "$d" || exit ; dirname "$PWD")
bar="${FOOBAR:-${b}/foobar.d}"
echo "$bar"

Here's what shellcheck currently says:

In foo.sh line 2:
b=$(d=$(dirname "$0") ; cd -P "$d" || exit ; dirname "$PWD")
^-- SC2030: Modification of d is local (to subshell caused by $(..)
expansion).

In foo.sh line 3:
bar="${FOOBAR:-${b}/foobar.d}"
^-- SC2031: d was modified in a subshell. That change might be lost.

Here's what I wanted or expected to see:

Nothing!

For more details please see shellcheck issue #950 at:

  https://github.com/koalaman/shellcheck/issues/950

This is fixed upstream though there is no release yet.  The patch is
at:

  
https://github.com/koalaman/shellcheck/commit/807d899f3b6139a61b644420d3f74b21bb0fb272

This is a regression to version 0.4.4, so I'm wondering if you could
apply this patch to fix the regression until there's a new shellcheck
release.

Thanks!

peace & happiness,
martin

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

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

Versions of packages shellcheck depends on:
ii  libc6 2.24-17
ii  libffi6   3.2.1-6
ii  libgmp10  2:6.1.2+dfsg-1.1

shellcheck recommends no packages.

shellcheck suggests no packages.

-- no debconf information

Bug#879984: libgcrypt20: copyright does not mention OCB patent license

[Jan Kiszka]

On 2017-11-03 19:28, Andreas Metzler wrote:
> On 2017-11-03 Jan Kiszka  wrote:
>> Has this topics also been brought up upstream already? Didn't find a
>> reference so far.
> 
> No, I have not yet done so. The OCB licenses is listed in GIT's LICENSES
> file, it is just not listed in EXTRA_DIST and therefore missing in the
> tarball.
> 
> Re Debian I think we 'll just need to update the copyright file, there
> are multiple OCB implementatios in Debian/main and some are using the
> genneric opensource license grant.
> 
> cu Andreas
> 

I think, and I've heard this from other sides as well, that the problems
is not just a missing OCB license listing: Adding code under this
license to the library seems to effectively downgrade the lib from LGPL
to GPL. So it has impact on the top-level license - and likely some users.

Would be good to sort this out prior to making the new version part of a
stable release. Therefore my question if upstream is aware of this
already (and maybe has some comments).

Thanks,
Jan

Bug#879936: xterm quits with "Selected font has no non-zero width for ISO-8859-1 encoding"

[Philipp Marek]

Hi Thomas,

"xterm" doesn't crash, it just gives the above message and quits - 
which

would've been unfortunate, hadn't I be running tmux at the time ;)


I don't see a crash (it probably depends on whether you have the bitmap
fonts installed).  Instead, it gives a message:

xterm-dev: cannot load font "2"

To reproduce it needs a few tries.

Here's my ~/.Xresources; I'm using TT fonts, perhaps that's another
factor as well:

  XTerm*charClass: 36:48,43:48,45-47:48,59:48,63-64:48,95:48,126:48
  XTerm*background: lightyellow
  XTerm*foreground: black
  XTerm*altSendsEscape: true
  XTerm*metaSendsEscape: true
  XTerm*utf8Title: true
  XTerm*utf8: always
  XTerm*visualBell: true
  XTerm*renderFont: true
  XTerm*faceName: DejaVu Sans Mono
  XTerm*faceSize1: 8
  XTerm*faceSize2: 10
  XTerm*faceSize3: 12
  XTerm*faceSize: 13
  XTerm*faceSize4: 15
  XTerm*faceSize5: 17
  XTerm*faceSize6: 19
  XTerm*fullscreen: never

and the locale is "de_AT.UTF-8", although xterm's message is talking
about 8859-1.



In the manual for xtermcontrol:

the "#" is literally part of the parameter (though the quotes are
misleading).

Yeah, I tried that as well.


Still, simply quitting just because the user asks for a different font 
size
is bad behaviour - and real data might be lost (generated but 
not-yet-saved

console output).
If there's no bitmap fonts, xterm's supposed to recover (and gray-out 
the
items for the missing fonts).  But I don't recall someone using 
xtermcontrol
to test that with.  If I knew the fonts you're using, I could reproduce 
this.

Does the above ~/.Xresources help?


Perhaps it's easier to find out how xterm lands in that code path...


Thank you for your patience!

Bug#880936: nodejs: updated version available upstream

[Félix Sipma]

On 2017-11-05 21:27+0100, Jérémy Lal wrote:
> Sure, but nodejs 6.11.x first has to go in testing...

Maybe you could upload 8.9.0 to experimental? It can't hurt, and, who knows, it
may also fix #878674...


signature.asc
Description: PGP signature

Bug#880949: no progress information or stats

[Eduard Bloch]

Package: borgbackup
Version: 1.1.1-1
Severity: normal

Hi,

I haven't used borg for a while and tried again. Wanted to see how it
behaves, using:

borg create --stats --verbose --dry-run $PWD::$(date +%F)  ~

Result:
shows only error messages on permission problems. The process seems to
finish with a backup set, though (at least "borg list" reports it).

Expected result:
a) progress information
b) stats of the data matching in the end

I checked the manpages, this is basically the main example in borg(1)
and is supposed to work.

Best regards,
Eduard.

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

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

Versions of packages borgbackup depends on:
ii  fuse   2.9.7-1
ii  libacl12.2.52-3+b1
ii  libb2-10.97-4
ii  libc6  2.24-17
ii  liblz4-1   0.0~r131-2+b1
ii  libssl1.1  1.1.0f-5
ii  python33.6.3-1
ii  python3-llfuse 1.3+dfsg-3
ii  python3-msgpack0.4.8-1+b1
ii  python3-pkg-resources  36.2.7-2

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

Bug#880948: wicd: won't retain leading '+' char in pwd

[vanhemt]

Package: wicd
Version: 1.7.4+tb2-4
Severity: minor

Dear Maintainer,

The password for my network starts with a '+'.
Every time I restart wicd, I have to restore the char in Properties.
There's nothing else I have tried.


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

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

Versions of packages wicd depends on:
ii  wicd-daemon 1.7.4+tb2-4
ii  wicd-gtk [wicd-client]  1.7.4+tb2-4

wicd recommends no packages.

wicd suggests no packages.

Versions of packages wicd-gtk depends on:
ii  python 2.7.13-2
ii  python-glade2  2.24.0-5.1
ii  python-gtk22.24.0-5.1
ii  wicd-daemon1.7.4+tb2-4

Versions of packages wicd-gtk recommends:
ii  gksu   2.0.2-9+b1
ii  python-notify  0.1.1-4

Versions of packages wicd-daemon depends on:
ii  adduser  3.115
ii  dbus 1.10.22-0+deb9u1
ii  debconf  1.5.61
ii  iproute2 4.9.0-1
ii  iputils-ping 3:20161105-1
ii  isc-dhcp-client  4.3.5-3
ii  lsb-base 9.20161125
ii  net-tools1.60+git20161116.90da8a0-1
ii  psmisc   22.21-2.1+b2
ii  python   2.7.13-2
ii  python-dbus  1.2.4-1+b1
ii  python-gobject   3.22.0-2
ii  python-wicd  1.7.4+tb2-4
ii  wireless-tools   30~pre9-12+b1
ii  wpasupplicant2:2.4-1

Versions of packages wicd-daemon recommends:
ii  rfkill  0.5-1+b1
ii  wicd-gtk [wicd-client]  1.7.4+tb2-4

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages python-wicd depends on:
ii  python  2.7.13-2

-- debconf information:
* wicd/users:

Bug#617242: [Pkg-mlmmj-devel] Bug#617242: mlmmj-make-ml does not ensure correct permissions for created files and directories

[Zhang Huangbin]

> On Nov 6, 2017, at 11:07 AM, Chris Knadle  wrote:
> 
>> I have my umask set to 0027. If I run mlmmj-make-ml with sudo, then
>> this umask is inherited, and used to create all the files and
>> directories for a new mailing list, which is wrong. The files and
>> directories should be explicitly chmodded to the correct permissions.
> 
> The mlmmj package in Debian doesn't come with pre-configuration for a
> specific MTA, nor setting up a user for mlmmj, instead giving
> administrative guidance for basic setups with various MTAs, and allowing
> for more complex configurations by leaving ownership and permissions
> configuration to the administrator. As far as I can tell, the specific
> permissions for files in /var/spool/mlmmj/ likely differ depending on
> the specific setup used.
> 
> Do you believe there are specific permissions that always neeed to be
> used regardless of specific MTA and setup?

I use mlmmj with Postfix, it’s configured by following mlmmj doc[1].

*) Postfix pipes email to command 'mlmmj-receive’. Postfix doesn’t
need to know any further info about the mail message itself, we’d better
run ‘mlmmj-receive’ as a non-privileged user/group. In my case, it's
“mlmmj:mlmmj”.

*) After take over the mail message, mlmmj is the only one program who
processes the message, so the directory used to store mailing lists is better
to be set to owner/group “mlmmj:mlmmj” with permission 0700 (or 0770).

IMO, with Postfix integration, it should be a requirement to:

- create user/group “mlmmj:mlmmj”
- create directory /var/spool/mlmmj, and owned by “mlmmj:mlmmj” with
  permission 0700.
- also setup a cron job to run command “mlmmj-maintd”[2] every 2 hours.

[1] http://mlmmj.org/docs/readme-postfix/
[2] http://mlmmj.org/docs/mlmmj-maintd/


Zhang Huangbin, founder of iRedMail project: http://www.iredmail.org/
Time zone: GMT+8 (China/Beijing).
Available on Telegram: https://t.me/iredmail

Bug#880411: Subject: RFS: sqldeveloper-package/0.4.4

[Lazarus Long]

On Tue, Oct 31, 2017 at 9:56 AM, Lazarus Long  wrote:
> Alternatively, one can download the package with dget using this command:
>
>dget -x 
> https://mentors.debian.net/debian/pool/contrib/s/sqldeveloper-package/sqldeveloper-package_0.4.1.dsc

Sorry about this, the last line should read:

   dget -x 
https://mentors.debian.net/debian/pool/contrib/s/sqldeveloper-package/sqldeveloper-package_0.4.4.dsc


-- 
Lazarus

Bug#880946: chessx: Clicking board pieces in board setup mode makes program unresponsive

[annadane]

Package: chessx
Version: 1.4.6-1
Severity: important

Dear Maintainer,

When I go into board setup mode, clicking pieces to put them on the board gives 
the "red circle with a line through it" icon and "freezes" the mouse, making me 
unable to click on anything else in the program and indeed, freezing the mouse 
in general. Only being able to go to the process manager and killing chessx 
that way will close the window and free up the mouse. I am using KDE Plasma.


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

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

Versions of packages chessx depends on:
ii  libc62.24-17
ii  libgcc1  1:7.2.0-12
ii  libgl1-mesa-glx  17.2.4-1
ii  libqt5core5a 5.9.2+dfsg-4
ii  libqt5gui5   5.9.2+dfsg-4
ii  libqt5multimedia55.9.2-1
ii  libqt5network5   5.9.2+dfsg-4
ii  libqt5printsupport5  5.9.2+dfsg-4
ii  libqt5svg5   5.9.2-2
ii  libqt5widgets5   5.9.2+dfsg-4
ii  libqt5xml5   5.9.2+dfsg-4
ii  libstdc++6   7.2.0-12
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chessx recommends:
ii  stockfish  8-3

chessx suggests no packages.

-- no debconf information

Bug#617242: mlmmj-make-ml does not ensure correct permissions for created files and directories

[Chris Knadle]

tag 617242 + moreinfo
thanks

Although this bug is very old I think it deserves are maintainer response.

> I have my umask set to 0027. If I run mlmmj-make-ml with sudo, then
> this umask is inherited, and used to create all the files and
> directories for a new mailing list, which is wrong. The files and
> directories should be explicitly chmodded to the correct permissions.

The mlmmj package in Debian doesn't come with pre-configuration for a
specific MTA, nor setting up a user for mlmmj, instead giving
administrative guidance for basic setups with various MTAs, and allowing
for more complex configurations by leaving ownership and permissions
configuration to the administrator. As far as I can tell, the specific
permissions for files in /var/spool/mlmmj/ likely differ depending on
the specific setup used.

Do you believe there are specific permissions that always neeed to be
used regardless of specific MTA and setup?

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#822936: Occurs on Stretch

[Jiann-Ming Su]

# uname -v
#1 SMP Debian 4.9.51-1 (2017-09-28)

[256204.725417] INFO: rcu_sched self-detected stall on CPU
[256204.725450] INFO: rcu_sched detected stalls on CPUs/tasks:
[256204.725473] 0-...: (2 GPs behind) idle=52b/2/0
softirq=1717403/1717404 fqs=0
[256204.725477]
[256204.725485] (detected by 1, t=18640 jiffies, g=600410, c=600409, q=1)
[256204.725490] Task dump for CPU 0:
[256204.725495] swapper/0   R
[256204.725498]   running task
[256204.725505] 0 0  0 0x0008
[256204.725512]  d07c55f0
[256204.725517]  d0761fbc
[256204.725520]  
[256204.725523]  d076007b
[256204.725527]  f3ec007b
[256204.725530]  00d8
[256204.725533]  d07c00e0
[256204.725537]  ff5e
[256204.725542]  d0480944
[256204.725545]  0060
[256204.725548]  00200246
[256204.725552]  000ad6bb
[256204.72]  f3ea7231
[256204.725558]  e8f2
[256204.725561]  
[256204.725565]  d07c54a0
[256204.725570]  0004
[256204.725573]  ff9d7fe0
[256204.725576]  f3ec141f
[256204.725580]  e8f2
[256204.725583]  
[256204.725586]  ff9d7fe0
[256204.725589]  d07c54a0
[256204.725593]  d0761fe4
[256204.725598] Call Trace:
[256204.725653]  [] ? cpuidle_enter_state+0x134/0x330
[256204.725673]  [] ? cpu_startup_entry+0x135/0x220
[256204.725685]  [] ? start_kernel+0x39d/0x3b4
[256204.725696] rcu_sched kthread starved for 18640 jiffies! g600410
c600409 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
[256204.725701] rcu_sched   S
[256204.725705] 0 7  2 0x
[256204.725709]  
[256204.725711]  f79f2ac0
[256204.725713]  f6c9be00
[256204.725715]  f751bed4
[256204.725717]  d05a9e7e
[256204.725719]  f751bebc
[256204.725727]  d00d4cd7
[256204.725729]  d08b8280
[256204.725732]  0051bec4
[256204.725734]  f7518db8
[256204.725736]  f7520a00
[256204.725737]  f7520a00
[256204.725739]  f79f2ac0
[256204.725741]  f75189c0
[256204.725744]  f751bee0
[256204.725746]  f75189c0
[256204.725749]  f79ec900
[256204.725750]  f751bf00
[256204.725752]  f751bee0
[256204.725754]  d05aa3ae
[256204.725756]  f79ec900
[256204.725758]  f751bf28
[256204.725760]  d05ad08f
[256204.725762]  0002
[256204.725765] Call Trace:
[256204.725779]  [] ? __schedule+0x25e/0x760
[256204.725790]  [] ? lock_timer_base+0x67/0x80
[256204.725798]  [] ? schedule+0x2e/0x80
[256204.725807]  [] ? schedule_timeout+0x12f/0x300
[256204.725815]  [] ? del_timer_sync+0x50/0x50
[256204.725823]  [] ? rcu_gp_kthread+0x4a1/0x7c0
[256204.725833]  [] ? kthread+0xb4/0xd0
[256204.725839]  [] ? rcu_note_context_switch+0xf0/0xf0
[256204.725847]  [] ? kthread_park+0x50/0x50
[256204.725854]  [] ? ret_from_fork+0x1b/0x28
[256204.726675] 0-...: (2 GPs behind) idle=52b/2/0
softirq=1717403/1717404 fqs=0
[256204.726951]  (t=18640 jiffies g=600410 c=600409 q=1)
[256204.727207] rcu_sched kthread starved for 18640 jiffies! g600410
c600409 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0
[256204.727557] rcu_sched   R  running task0 7  2 0x
[256204.727579]   f79f2ac0 f6c9be00 f751bed4 d05a9e7e f751bebc
d00d4cd7 d08b8280
[256204.727599]  0051bec4 f7518db8 f7520a00 f7520a00 f79f2ac0 f75189c0
f751bee0 f75189c0
[256204.727618]  f79ec900 f751bf00 f751bee0 d05aa3ae f79ec900 f751bf28
d05ad08f 0002
[256204.727638] Call Trace:
[256204.727667]  [] ? __schedule+0x25e/0x760
[256204.727681]  [] ? lock_timer_base+0x67/0x80
[256204.727693]  [] ? schedule+0x2e/0x80
[256204.727704]  [] ? schedule_timeout+0x12f/0x300
[256204.727714]  [] ? del_timer_sync+0x50/0x50
[256204.727722]  [] ? rcu_gp_kthread+0x4a1/0x7c0
[256204.727733]  [] ? kthread+0xb4/0xd0
[256204.727741]  [] ? rcu_note_context_switch+0xf0/0xf0
[256204.727750]  [] ? kthread_park+0x50/0x50
[256204.727758]  [] ? ret_from_fork+0x1b/0x28
[256204.727769] Task dump for CPU 0:
[256204.727774] swapper/0   R  running task0 0  0 0x0008
[256204.727784]  f742fe54 d0091941 d06b35df   
0008 d0782140
[256204.727802]  d0782140  f742fe6c d0166884 00200087 f79df300
d0782140 d0782140
[256204.727820]  f742feb8 d00d20e1 d06a9ed0 48d0 0009295a 00092959
0001 f79deac0
[256204.727839] Call Trace:
[256204.727848]  
[256204.727872]  [] ? sched_show_task+0xf1/0x160
[256204.727892]  [] ? rcu_dump_cpu_stacks+0x79/0x95
[256204.727908]  [] ? rcu_check_callbacks+0x631/0x780
[256204.727922]  [] ? account_process_tick+0x5a/0x150
[256204.727937]  [] ? update_process_times+0x28/0x50
[256204.727949]  [] ? tick_sched_handle.isra.11+0x26/0x60
[256204.727956]  [] ? tick_sched_timer+0x3a/0x80
[256204.727965]  [] ? __remove_hrtimer+0x3f/0x80
[256204.727976]  [] ? __hrtimer_run_queues+0xc0/0x260
[256204.727987]  [] ? tick_sched_handle.isra.11+0x60/0x60
[256204.727999]  [] ? hrtimer_interrupt+0x93/0x1a0
[256204.728012]  [] ? timer_interrupt+0x12/0x20
[256204.728024]  [] ? __handle_irq_event_percpu+0x78/0x190
[256204.728034]  [] ? handle_irq_event_percpu+0x2b/0x70
[256204.728041]  [] ? handle_irq_event+0x2f/0x50
[256204.728049]  [] ? handle_edge_irq+0x6d/0x120

Bug#880945: ITP: ddgr -- DuckDuckGo from the terminal

[林上智]

Package: wnpp
Severity: wishlist
Owner: SZ Lin (林上智) 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ddgr
  Version : 1.0
  Upstream Author : Arun Prakash Jana 
* URL : https://github.com/jarun/ddgr
* License : GPL-3
  Programming Lang: Python
  Description: DuckDuckGo from terminal

 ddgr is a command line utility to search DuckDuckGo from the terminal.
 .
 Features
 .
  - Fast and clean (no ads, stray URLs or clutter), custom color
  - Navigate result pages from omniprompt, open URLs in browser
  - Search and option completion scripts for Bash, Zsh and Fish
  - DuckDuckGo Bang support (along with completion)
  - Open the first result directly in browser (as in I'm Feeling Ducky)
  - Non-stop searches: fire new searches at omniprompt without exiting
  - Keywords (e.g. filetype:mime, site:somesite.com) support
  - Specify region, disable safe search
  - HTTPS proxy support, Do Not Track set, optionally disable User Agent
  - Support custom url handler script or cmdline utility
  - Comprehensive documentation, man page with handy usage examples
  - Minimal dependencies
 .
 ddgr is under GNU GPLv3.

--

SZ Lin (林上智) , http://people.debian.org/~szlin

4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9

Bug#879905: glee: source for GLee.c and GLee.h is missing

[Steve Cotton]

On Fri, Oct 27, 2017 at 07:55:52AM +0200, Steve Cotton wrote:
> On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote:
> > These files are clearly not source code. But luckily it should
> > be possible to regenerate them from the git repo I mentioned:
> >
> > > [..] https://github.com/kallisti5/glee
> 
> It seems that repo is also not the complete source, the build
> steps in CMakeLists.txt download specs for the GL extensions from
> http://www.opengl.org/registry/

It doesn't manage to download the specifications any more, which is
probably because the website has changed since 2011. OTOH, anything
that works with Debian's 2009 version of GLee can only be using
extensions that existed in 2009.

AFAICS, what GLeeGen creates is a mix of:

1. An easy wrapper for checking if an extension is supported
2. The DFSG-free files which are now packaged in khronos-api
3. The specifications under Khronos' speccopyright (not DFSG-free)

The speccopyright means that we can't make a DFSG version of GLee, but
it also seems that it might be easier to just fix the rdeps to not use
GLee at all.  The wrapper for checking if extensions are supported
could be ported to use the khronos-api, if it's needed at all.

Looking at the packages that use GLee:

Fife: only a few extensions, all of them now in khronos-api. Would
need the wrapper function.

FS-UAE: build-depends on glee-dev, but the changelog includes "use
GLEW instead of GLee", none of the binaries depend on libglee, and the
two #includes in the source are commented out. Bug #880944 logged.

Out Of Order: transitive dependency via Sludge

Pink Pony: build-depends on glee-dev, but doesn't #include GLee.h
anywhere. Builds and runs fine without it (bug #880941 logged for
dropping the dependency).

Sludge: if a compile-time check finds OpenGL ES 2.0, the code assumes
that all of the extensions that it wants are already present, and
doesn't use GLee's wrapper.

Unknown Horizons: transitive dependency via Fife

Steve

Bug#880944: fs-uae: glee.c and build-dep on glee, but doesn't use glee any more

[Steve Cotton]

Source: fs-uae
Version: 2.8.3+dfsg-1
Severity: serious
Justification: missing source, and dependency scheduled for auto-removal

Hi Games Team,

The fs-uae package build-depends on glee-dev and also includes an embedded copy
of glee.  The dependency on glee-dev has already scheduled it to be
auto-removed from testing because of #879123 and #879905. The embedded copy of
GLee.c is itself affected by #879905 (missing source for GLee.c).

Upstream's changelog includes "Use GLEW instead of GLee", done in version
2.5.34dev. The two relevant #includes in the source are commented out, and none
of the binaries depend on libglee, so it might be a simple cleanup.

BR,
Steve

Bug#879936: xterm quits with "Selected font has no non-zero width for ISO-8859-1 encoding"

[Thomas Dickey]

On Fri, Oct 27, 2017 at 03:00:32PM +0200, Philipp Marek wrote:
> Package: xterm
> Version: 330-1
> Severity: normal
> 
> Having an xterm with "Allow font ops" being enabled, it happens to quit 
> after some of these:
> 
>  * use "xtermcontrol --font=" with  being eg. 0 or 5
>  * choose a different size from the font menu
> 
> "xterm" doesn't crash, it just gives the above message and quits - which 
> would've been unfortunate, hadn't I be running tmux at the time ;)

I don't see a crash (it probably depends on whether you have the bitmap
fonts installed).  Instead, it gives a message:

xterm-dev: cannot load font "2"

In the manual for xtermcontrol:

   --font=FONT
  Set  font name (see also FONT NAMES). Alternatively it is possi‐
  ble to specify a fontmenu index  as  ´#[0-6]´  or  navigate  the
  fontmenu  by  relative  sizes  as  ´#+N´ or ´#-N´, where N is an
  optional integer.

the "#" is literally part of the parameter (though the quotes are misleading).
 
> Still, simply quitting just because the user asks for a different font size 
> is bad behaviour - and real data might be lost (generated but not-yet-saved
> console output).

If there's no bitmap fonts, xterm's supposed to recover (and gray-out the
items for the missing fonts).  But I don't recall someone using xtermcontrol
to test that with.  If I knew the fonts you're using, I could reproduce this.

> Versions of packages xterm depends on:

for whatever reason, xterm doesn't depend on any fonts...

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


signature.asc
Description: Digital signature

Bug#878883: patch

[Mike Miller]

On Sat, Nov 04, 2017 at 22:14:22 -0400, Jeremy Bicha wrote:
> Could you do an NMU for this RC bug? I see you've done other uploads
> for this package previously.

I was going to nmu this since I thought it might be holding up the
libtomcrypt transition, but that seems to have gone ahead anyway despite
this bug. And Kevin looks to be taking care of this.

-- 
mike


signature.asc
Description: PGP signature

Bug#880943: pink-pony-data: GL shader error when using fancy water

[Steve Cotton]

Package: pink-pony-data
Version: 1.4.1-2
Severity: minor
Tags: patch

A trivial bug which I'm logging because it's something that
caused me to spend time checking that removing the glee-dev
dependency hadn't broken it.

In the settings, change "Simple water" to "Fancy water", and this
error appears:

/usr/share/games/pink-pony/GLSL/water.frag: Compilation failed.
0:29(51): error: no matching function for call to `pow(float, int)'; candidates 
are:
0:29(51): error:float pow(float, float)
0:29(51): error:vec2 pow(vec2, vec2)
0:29(51): error:vec3 pow(vec3, vec3)
0:29(51): error:vec4 pow(vec4, vec4)
0:29(47): error: operands to arithmetic operators must be numeric

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

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

Versions of packages pink-pony depends on:
ii  libc6   2.24-17
ii  libdevil1c2 1.7.8-10+b2
ii  libftgl22.1.3~rc5-4+nmu1.1
ii  libgcc1 1:7.2.0-12
ii  libgl1  0.2.999+git20170802-5
ii  libgl1-mesa-glx 17.2.4-1
ii  libglfw33.2.1-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libilmbase122.2.0-12
ii  libprotobuf10   3.0.0-9.1
ii  libsdl-mixer1.2 1.2.12-14
ii  libsdl1.2debian 1.2.15+dfsg2-0.1
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  7.2.0-12
ii  libtinyxml2.6.2v5   2.6.2-4
ii  pink-pony-data  1.4.1-2

pink-pony recommends no packages.

Versions of packages pink-pony suggests:
pn  pink-pony-dbg  

-- no debconf information
Fix a bug in the fancy water shader, pow() expects two floats.

Fancy water can be enabled in the settings, by default the game
uses "simple water" instead.
Index: pink-pony/resources/GLSL/water.frag
===
--- pink-pony.orig/resources/GLSL/water.frag
+++ pink-pony/resources/GLSL/water.frag
@@ -26,7 +26,7 @@ float dispf(vec2 p)
 
 vec3 displacement(vec3 wp, float dist)
 {
-return wp + normal * (dispf(wp.xz) * min(1.0,2.0/pow(dist,1)) * 0.5 + 0.5) 
* 4.0;
+return wp + normal * (dispf(wp.xz) * min(1.0,2.0/pow(dist,1.0)) * 0.5 + 
0.5) * 4.0;
 }
 
 void main (void)

Bug#880901: texlive-pstricks-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/texlive-doc/latex/pst-pdf/CHANGES.gz

[Norbert Preining]

>   dpkg: error processing archive 
> /var/cache/apt/archives/texlive-pstricks-doc_2017.20171031-1_all.deb 
> (--unpack):

Umpf, indeed. Again the -doc packages... the package source
autogeneration script needs to get more intelligent.

Thanks, will be fixed soon.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#880942: ITP: ghdl -- VHDL 2008/93/87 simulator

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe 

* Package name: ghdl
  Version : 0.35-dev
  Upstream Author : Tristan Gingold
* URL : https://github.com/tgingold/ghdl
* License : GPL-2+
  Programming Lang: Ada, VHDL
  Description : VHDL 2008/93/87 simulator

 GHDL is a simulator for hardware designs written in VHDL. It is not an
 interpreter, it generates machine code from your design for high speed
 simulation. GHDL fully supports IEEE 1076-1987, IEEE 1076-1993, IEEE
 1076-2002 and partially the IEEE 1076-2008 version of VHDL.


This package has been in Debian previously and stagnated due to slow
upstream activity at the time (last maintainer upload 2010, orphaned
2012) and was finally removed from the archive last year. I was briefly
involved in an attempt to revive the package in Debian but I considered
the non-free license of the IEEE sources for the essential standard
library definitions problematic (even though it has been in Debian in
that state for over a decade).

Back then we all agreed that writing free replacements was the way to go
but I never got around to help out with that. Turns out upstream has
implemented that in the meantime (not yet for VHDL 2008 though) so I
guess now is the time to really bring it back.

I am not yet a member of the Debian Electronics Team, but I think this
package should fit in there (like the Verilog simulator iverilog).

Bug#880941: pink-pony: Build-depends on glee-dev, but doesn't need it

[Steve Cotton]

Source: pink-pony
Version: 1.4.1-2
Severity: serious
Justification: glee is marked for auto-removal from testing

Dear Games Team,

Pink-pony build-depends on glee-dev, but 1.4.1-2 doesn't seem to need
this dependency, it builds and runs fine without it.

Because of this dependency, it's affected by Glee's auto-removal
from testing.  For Glee's #879905 I'm analysing how much effort
it would take to remove the glee package without losing any of
the rdeps.

Steve

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

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

-- no debconf information

Bug#846222: [Pkg-xfce-devel] Bug#846222: x11-common: Please provide a default xsession in /usr/share/xsessions

[Michael Biebl]

Am 06.11.2017 um 00:32 schrieb Michael Biebl:
> On Tue, 29 Nov 2016 12:07:26 +0100 Yves-Alexis Perez 

>> If other DM have the same behavior as LightDM, I guess it's a good idea
>> indeed, although I'm wondering if it can have side effects.

[..]

> I would prefer though, if that xsession.desktop file is *not* provided
> by x11-common, as some desktop environments might actually choose not
> wanting to have such an entry in the display manager menu, and
> x11-common is not really uninstallable.
> So a separate binary package seems like the most flexible approach to me.
> 
> lightdm's /usr/share/xsessions/lightdm-xsession.desktop file might be a
> good basis for such a package.

Another reason why it might be a good idea to ship that as a package
separate from x11-common is, that as you mentioned, not all display
manager might support that ExecStart=default feature.
Only those that do could decide to add a Recommend or Depends on that
new xsession-default package.

If there is some agreement on this, I could prepare a patch for src:xorg
which adds such a new xsession-default package. I think src:xorg would
be the right source package for building such a package.


Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#876673: catdoc: diff for NMU version 1:0.95-4.1

[Olly Betts]

Control: tags 876673 + patch
Control: tags 876673 + pending

Dear maintainer,

I've prepared an NMU for catdoc (versioned as 1:0.95-4.1) and uploaded
it under the zero-day NMU rules.

Cheers,
Olly
diff -Nru catdoc-0.95/debian/changelog catdoc-0.95/debian/changelog
--- catdoc-0.95/debian/changelog	2017-09-14 09:03:58.0 +1200
+++ catdoc-0.95/debian/changelog	2017-11-06 11:48:29.0 +1300
@@ -1,3 +1,11 @@
+catdoc (1:0.95-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Restore -lm when linking programs as it's needed for rint() on some
+architectures. Closes: #876673
+
+ -- Olly Betts   Mon, 06 Nov 2017 11:48:29 +1300
+
 catdoc (1:0.95-4) unstable; urgency=medium
 
   * Automated fixes from cme, and some cleanup.
diff -Nru catdoc-0.95/debian/patches/02-Makefile_fixes.patch catdoc-0.95/debian/patches/02-Makefile_fixes.patch
--- catdoc-0.95/debian/patches/02-Makefile_fixes.patch	2017-09-14 09:03:58.0 +1200
+++ catdoc-0.95/debian/patches/02-Makefile_fixes.patch	2017-11-06 11:40:22.0 +1300
@@ -46,18 +46,3 @@
  	$(INSTALL) -m 644 wordview.1 $(installroot)$(mandir)/man1/wordview.1
  distclean: clean
  	$(RM)  Makefile catdoc.1 xls2csv.1 catppt.1 wordview.1
 a/src/Makefile.in
-+++ b/src/Makefile.in
-@@ -77,10 +77,10 @@
- catdoc: $(OBJ)
- 	$(CC)  -o catdoc  $(OBJ) $(LDFLAGS)
- xls2csv: $(OBJXLS)
--	$(CC) -o xls2csv $(OBJXLS) -lm $(LDFLAGS)
-+	$(CC) -o xls2csv $(OBJXLS) $(LDFLAGS)
- 
- catppt: $(OBJPPT)
--	$(CC) -o catppt $(OBJPPT) -lm $(LDFLAGS)
-+	$(CC) -o catppt $(OBJPPT) $(LDFLAGS)
- 
- install: @installtargets@
- install-catdoc:catdoc xls2csv catppt 


signature.asc
Description: PGP signature

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

Christoph Biedl wrote...

> Status: Packaging done but there are serious issues on other
> architectures that need fixing first.

Never mind, the test suite just takes a *long* time on slow single-core
systems. With jose just uploaded, it's now up to ftp-master.

Christoph


signature.asc
Description: Digital signature

Bug#846222: [Pkg-xfce-devel] Bug#846222: x11-common: Please provide a default xsession in /usr/share/xsessions

[Michael Biebl]

Hi

On Tue, 29 Nov 2016 12:07:26 +0100 Yves-Alexis Perez 
wrote:
> On Tue, 2016-11-29 at 11:52 +0100, Maximiliano Curia wrote:
> > Thanks to the #845948 report against sddm, we noticed that the "Default 
> > Xsession" xsession desktop file is being provided by the lightdm display 
> > manager (in the /usr/share/xsessions/lightdm-xsession.desktop file). And 
> > since: 
> > 
> >  - This xsession file is useful for other display managers, such as sddm, 
> > that
> >    uses the /usr/share/xsessions/*.desktop to allow the users to choose 
> > their
> >    preferred sessions.
> > 
> >  - This ends up calling /etc/X11/Xsession default which is the only way to 
> > use
> >    the user's ~/.xsession file
> > 
> >  - The script that processes the "default" parameter
> >    (/etc/X11/Xsession.d/20x11-common_process-args) as a special case is
> >    provided by the x11-common package.
> > 
> > I believe, it would be better to this file in the x11-common package 
> > (renamed 
> > as
> > /usr/share/xsessions/user-xsession.desktop or 
> > /usr/share/xsessions/default-xsession.desktop).
> 
> If other DM have the same behavior as LightDM, I guess it's a good idea
> indeed, although I'm wondering if it can have side effects.
> 
> In any case, keep me in the loop so I can remove the file from LightDM when
> needed :)

Fwiw, we just discussed today to drop
/usr/share/gdm/BuiltInSessions/default.desktop from gdm3 as well
(which starts Xsession).

It would be nice if such a xsession.desktop file would be provided by a
common package, which invididual desktop environments can depend on, if
they want. This would have the benefit, that we would have no
duplication in all the different display manager.

I would prefer though, if that xsession.desktop file is *not* provided
by x11-common, as some desktop environments might actually choose not
wanting to have such an entry in the display manager menu, and
x11-common is not really uninstallable.
So a separate binary package seems like the most flexible approach to me.

lightdm's /usr/share/xsessions/lightdm-xsession.desktop file might be a
good basis for such a package.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#860995: patch proposal

[Matthias Brinke]

Hello,

attached is a patch (tested with jessie, I don't use Debian 9/stretch yet) to 
fix CVE-2017-8054.

The source code for a program using PoDoFo to generate the PoC I tested with is 
also attached.

Best regards, Matthias--- src/doc/PdfPagesTree.cpp	(revision 1793)
+++ src/doc/PdfPagesTree.cpp	(working copy)
@@ -34,6 +34,7 @@
 #include "PdfPagesTree.h"
 
 #include "base/PdfDefinesPrivate.h"
+#include 
 
 #include "base/PdfArray.h"
 #include "base/PdfDictionary.h"
@@ -478,7 +479,17 @@ PdfObject* PdfPagesTree::GetPageNodeFrom
 if( rVar.IsArray() ) 
 {
 // Fixes some broken PDFs who have trees with 1 element kids arrays
-return GetPageNodeFromArray( 0, rVar.GetArray(), rLstParents );
+// Recursive call removed to prevent stack overflow, replaced by:
+// all the following inside this conditional, plus restart looping
+const PdfArray & rVarArray = rVar.GetArray();
+if (rVarArray.GetSize() == 0)
+{
+PdfError::LogMessage( eLogSeverity_Critical, "Trying to access"
+" first page index of empty array" );
+return NULL;
+}
+rVar = rVarArray[0];
+continue;
 }
 else if( !rVar.IsReference() )
 {
@@ -502,6 +513,19 @@ PdfObject* PdfPagesTree::GetPageNodeFrom
 if( !pgObject->GetDictionary().HasKey( "Kids" ) )
 return NULL;
 
+if ( std::find( rLstParents.begin(), rLstParents.end(), pgObject )
+!= rLstParents.end() ) // cycle in parent list detected, fend
+{ // off security vulnerability CVE-2017-8054 (infinite recursion)
+std::ostringstream oss;
+oss << "Cycle in page tree: child in /Kids array of object "
+<< ( *(rLstParents.rbegin()) )->Reference().ToString()
+<< " back-references to object " << pgObject->Reference()
+.ToString() << " one of whose descendants the former is.";
+const char* pszErrorDesc = oss.str().c_str();
+PODOFO_RAISE_ERROR_INFO( ePdfError_PageNotFound,
+pszErrorDesc );
+}
+
 rLstParents.push_back( pgObject );
 rVar = *(pgObject->GetDictionary().GetKey( "Kids" ));
 } else {
#include "workaround_create_base14.h"
#include 

using namespace PoDoFo;

void CreatePagesLoopPoC(PdfDocument& doc)
{
PdfPage* pFirstPage = doc.GetPage( 0 );
PdfObject* pFirstPageObject = pFirstPage->GetObject();
PdfObject* pParentObject = pFirstPageObject->MustGetIndirectKey("Parent");
PdfArray & rParentKidsArray = pParentObject->MustGetIndirectKey("Kids")
->GetArray();
rParentKidsArray.insert(rParentKidsArray.begin(),
pParentObject->Reference());
pdf_int64 ll2 = 2; // needed to make the following call unambiguous
pParentObject->GetDictionary().AddKey("Count", ll2); // 1 original, 1 loop
}

#define FONTNAME "Helvetica"
#define TEXTPOS_X 72.0
#define TEXTPOS_Y 72.0

#define SAMPLE_TEXT "Sample"

void DrawSampleTextOnPage(PdfPage* pPage)
{
PdfPainter painter;
painter.SetPage( pPage );

PdfFont* pFont = PdfFontFactory::CreateBase14Font( FONTNAME, 0,
PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
pPage->GetObject()->GetOwner() );
painter.SetFont( pFont );
painter.DrawText( TEXTPOS_X, TEXTPOS_Y, PdfString( SAMPLE_TEXT,
pFont->GetEncoding() ));
painter.FinishPage();
}

#define OUTFILE "my-CVE-2017-8054-PoC.pdf"

int main()
{
PdfMemDocument doc;
PdfPage* pPage
= doc.CreatePage( PdfPage::CreateStandardPageSize( ePdfPageSize_A4 ));

DrawSampleTextOnPage( pPage );
CreatePagesLoopPoC( doc );

doc.Write( OUTFILE );

return 0;
}

Bug#852944: chromium: Poor font rendering

[Michael Gilbert]

control: tag -1 moreinfo

> Chromium renders the body text on vox.com poorly. Vertical strokes in
> the 'T' and 'e' characters among others are too thick. Changing the text
> zoom size makes everything look fine. Attached is a test case and
> screenshot.

This works well in chromium 62 for me.  Can you provide more info
about the font configuration on your system if its still a problem?

Best wishes,
Mike

Bug#861211: festival: text2wave no longer works in pipe

[Andy Bennett]

Hi,


Sorry for having missed your report for so long.

Andy Bennett, on mer. 26 avril 2017 00:23:34 +0100, wrote:

echo "$string" | text2wave |aplay -q

This now no longer works under Jessie.


Indeed, text2wave now uses fseek, which can't work with pipes.

I have forwarded the report to upstream, but I'm afraid it'll be
difficult for them to work back to avoid using fseek. It probably means
you will have to use a temporary file.


No worries and thanks for getting back to me.

I've been using a temporary file thus:

-
TMP=`mktemp`
echo "$string" | text2wave > $TMP
aplay -q $TMP
rm $TMP
-

...and if that's the intended behaviour then it'd be nice to get an error 
when it gets a pipe rather than just nothing. Better still would be to 
change the interface to only deal with named files and not output to stdout 
at all.






Regards,
@ndy

--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF

Bug#880940: firefox-esr-l10n-en-gb: recommends non-existing package myspell-en-gb (should be hunspell-en-gb)

[Jonas Smedegaard]

Package: firefox-esr-l10n-en-gb
Version: 52.4.0esr-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

firefox-esr-l10n-en-gb recommends myspell-en-gb which no longer exist.

Instead it should recommend hunspell-en-gb.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAln/kyQACgkQLHwxRsGg
ASEaQQ//TqnvGwROTQB4als/zbMfkZTt6XuzOun1Axlxs0M6lKIMcD+DEm/zpwpX
0LAlX/jhcGlt695vvs1DF/uhpGGFxny7ilBpIU8HC3PIW+jKLbW3xuW51dpzEMg1
pGxMUhQy5rSA3QzRY8STqn8DupbGeoCJUTA/5LA557PbLuPIHXVkdEFIAIETdnlN
vww51obJXTDwvnUYd73HZ2I5oaqNCjfRiRTcOerPIMi7AObIj35Ad84diMs3ucBr
IdNMNGwPIukAge9+aXkuELXWwy8Usc9vZTtGpZmX3PVD70+eS4me7IlDJNIAPFgS
nnONfah8zjxYncB4ihVUo3K5CsrdoFEZtr4P8CnV5B+k6ByPIOggTswYExi0gDL9
itvCzCWTMR5uEWbC/Q6dB1mtSvL8qddjdLIXyvwzbfVwouJXmAPTqFvgLYF7Llmb
EyvoVbjAyW4/k6ffiN6YbVYG+5OMt7WdLRjMPrHwUTQltaA37JpXTUtmeTleTQLZ
1sv8mPCJq/8CXlfGq6Jux2Xtv+DD7XoY4xpLhAZ8qy7eaUo4LIug9BlVykkEg1nf
HNBjiyFJzXRzNblGVhUsy36fegKRfK6my6znEFj1E525E5qaG8WiXn6lZC8Zt6st
LK6TeV9XcOAYvCeWeeP5BeUnj8+PE1xlcptVC7XD4+tBNPcNM+4=
=TyIU
-END PGP SIGNATURE-

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Alf Gaida]

> This is actually a desired feature but I won't argue that here, but
> if you feel strongly enough, please reassign to debhelper and argue
> the case there :)
Ouch, that would mean to be between Scylla and Charybdis - also called
dh-team or debian-systemd. Hard to decide.

Cheers Alf




signature.asc
Description: OpenPGP digital signature

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Chris Lamb]

[Re-adding 880...@bugs.debian.org to Cc]

Alf

> + Attachment1
>   1k (application/pgp-encrypted)
> + encrypted.asc
>  3k (text/plain

Please resend your mail, un-encrypted, and including all the CCs…


Regards,

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

Bug#880939: ITP: r-cran-haven -- GNU R package to import/export SPSS, Stata and SAS files

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-haven
  Version : 1.1.0-1
  Upstream Author : Hadley Wickham and Evan Miller
* URL or Web page : https://github.com/tidyverse/haven
* License : MIT
  Description : GNU R package to import/export SPSS, Stata and SAS files

This is yet another new build-dependency of the package Rcmdr (via its
spinoff and build-dependency RcmdrMisc).  Rcmdr aka r-cran-rcmdr has been in
Debian since 2003.

Dirk

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

Bug#880775: mldonkey build depends on removed libgd2*-dev provides

[Adrian Bunk]

On Sun, Nov 05, 2017 at 10:05:19PM +0100, Ralf Treinen wrote:
> On Sat, Nov 04, 2017 at 09:43:53PM +0200, Adrian Bunk wrote:
> > Source: mldonkey
> > Version: 3.1.5-3.1
> > Severity: serious
> > Tags: buster sid
> > 
> > The following packages have unmet dependencies:
> >  builddeps:mldonkey : Depends: libgd2-xpm-dev but it is not installable
> > 
> > 
> > Please change the build dependency to libgd-dev.
> 
> Thanks, pushed to git, but not uploaded since we still have another FTBFS
> (#876735).

#876735 seems fixed in 3.1.6-0ubuntu1, so upgrading to 3.1.6 is likely
the solution for that.

> -Ralf.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Chris Lamb]

Alf,

> Hmm - imho the package should not be able to break apt. Thats my
> main point.

This is how APT/daemons etc. work in Debian, nothing special to Redis.

This is actually a desired feature but I won't argue that here, but
if you feel strongly enough, please reassign to debhelper and argue
the case there :)


Regards,

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

Bug#879261:

[Alex Henry]

Thank you Luca - I did see that the -nvidia libs are being dropped on the
-8 changelog but I had no idea what that actually meant until I read your
explanation.

I was assuming these were modified library versions by Nvidia with
enhancements to make the most out of the hardware but I guess their removal
goes to show they're equivalent in any way. In that sense, my system should
be fine right now, with maybe just a little headache to make sure all
-nvidia packages are replaced properly in the next update.

Thanks again for the extra information!

On 5 November 2017 at 15:09, Luca Boccassi  wrote:

> On Sun, 2017-11-05 at 00:03 -0200, Alex Henry wrote:
> > Just wanted to apologize for my last message since I missed the
> > "Fixed in
> > version nvidia-graphics-drivers/375.82-8" message in the header. It
> > also
> > only seems to have been marked as a resolved bug (bugtracker
> > category) as I
> > was writing it. I'll wait for 375.82-8 to trickle down to testing and
> > try
> > to install it again and report here.
> >
> > Also, usually the bug tracker adds an internal message to the report
> > once
> > the bug is resolved, not sure why it didn't happen here? Maybe it
> > doesn't
> > work like that anymore...
> >
> > Anyway, thanks for the fix, looking forward to having my nvidia
> > driver
> > fully functional again soon!
>
> Hi,
>
> What you noted in the previous email is correct - the problem appears
> to be due to having both i386 and amd64 libglvnd0-nvidia.
>
> There are other problems with that package as noted elsewhere - namely
> not all symbols are exposed, for whatever reason. Although it's an open
> source library we can't know since it's distributed as a binary blob,
> we don't know how Nvidia builds it.
>
> libglvnd0 is the equivalent - they are built from the same source so
> the -nvidia specific ones are getting deprecated and should be removed
> in favour of the "system" ones in -8.
>
> Kind regards,
> Luca Boccassi

Bug#813158: wget: segfault executing sgfxi script

[Chris Manougian]

Package: wget
Version: 1.19.2-1
Followup-For: Bug #813158

Dear Maintainer,

A full discussion is at http://techpatterns.com/forums/about2621.html

Running the sgfxi script after installing wget 1.19.2-1 produces the following
segfault:
wget -O - smxi.org/sm/sm-versions
--2017-11-04 14:23:41--  http://smxi.org/sm/sm-versions
Resolving smxi.org (smxi.org)... 216.92.31.53
Connecting to smxi.org (smxi.org)|216.92.31.53|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://smxi.org/sm/sm-versions [following]
--2017-11-04 14:23:41--  https://smxi.org/sm/sm-versions
Connecting to smxi.org (smxi.org)|216.92.31.53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Segmentation fault

4 people are reporting the exact same error. I'm not getting
this segfault with 1.19.1-4 

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

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

Versions of packages wget depends on:
ii  libc62.24-17
ii  libgnutls30  3.5.16-1
ii  libidn2-02.0.2-5
ii  libnettle6   3.3-2
ii  libpcre3 2:8.39-4
ii  libpsl5  0.18.0-4
ii  libuuid1 2.30.2-0.1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages wget recommends:
ii  ca-certificates  20170717

wget suggests no packages.

-- no debconf information

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Alf Gaida]

Hmm - imho the package should not be able to break apt. Thats my
main point. Ok, starting the service fails, it might be a problem
in systemd or in the generated service. Different thing - so even
if the start fail, it should not break the installation.

 
> # Automatically added by dh_systemd_enable/10.10.5
> # This will only remove masks created by d-s-h on package removal.
> deb-systemd-helper unmask 'redis-server.service' >/dev/null || true
>
> # was-enabled defaults to true, so new installations run enable.
> if deb-systemd-helper --quiet was-enabled 'redis-server.service'; then
>     # Enables the unit on first installation, creates new
>     # symlinks on upgrades if the unit file has changed.
>     deb-systemd-helper enable 'redis-server.service' >/dev/null ||
> true
> else
>     # Update the statefile to add new symlinks (if any), which
> need to be
>     # cleaned up on purge. Also remove old symlinks.
>     deb-systemd-helper update-state 'redis-server.service'
> >/dev/null || true
> fi
> # End automatically added section
> # Automatically added by dh_installinit/10.10.5
> if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
>     if [ -x "/etc/init.d/redis-server" ]; then
>     update-rc.d redis-server defaults >/dev/null
>     if [ -n "$2" ]; then
>     _dh_action=restart
>     else
>     _dh_action=start
>     fi
>     invoke-rc.d redis-server $_dh_action || exit $?
>     fi
> fi
The part added by dh_systemd_enable is ok and should not fail. But the line:
 
> invoke-rc.d redis-server $_dh_action || exit $?
added by dh_installinit look fugly - exit with error no is not the
outcome that the
very most people would expect or prefer - so what do you suggest? Filing
a bug against
dh?

Cheers Alf


On 05.11.2017 22:14, Chris Lamb wrote:
> Hi Alf,
>
> Thanks for your reply.
>
>> * redis-server isn't installable, it should be
>> * the start in postinst fails - for what reasons ever, nothing of any
>> interest at this point - but that make the package uninstallable
> The reason is surely highly relevant. ie. it is due to a bug in lxc
> and/or systemd (or something else entirely), not Redis, and thus it
> should be reassigned elsewhere?
>
> You can then use the "affects" tag in the BTS so that it appears in
> the Redis bug list, but that's simply to help direct others and
> prevent potential duplicates.
>
>
> Regards,
>

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

retitle 873939 ITP: jose -- Jose is a C-language implementation of the 
Javascript Object Signing and Encryption standards
thanks

Christoph Biedl wrote...

> * Package name: libjose

Upstream calls it "jose", so follow this name for the source package.

>   Version : 9
>   Upstream Author : Nathaniel McCallum https://github.com/npmccallum
> * URL : https://github.com/latchset/jose
> * License : Apache-2.0
>   Programming Lang: C
>   Description : José is a C-language implementation of the Javascript 
> Object Signing and Encryption standards

Status: Packaging done but there are serious issues on other
architectures that need fixing first.

Christoph


signature.asc
Description: Digital signature

Bug#862197: mark elinks-data Multi-Arch: foreign

[Manuel A. Fernandez Montecelo]

2017-11-05 11:54 GMT+01:00 Moritz Mühlenhoff :
> On Sun, Nov 05, 2017 at 12:26:00AM +0100, Manuel A. Fernandez Montecelo wrote:
>> Hello,
>>
>> 2017-05-09 19:38 Helmut Grohne:
>> > Package: elinks-data
>> > Version: 0.12~pre6-12
>> > Tags: patch
>> > User: helm...@debian.org
>> > Usertags: rebootstrap
>> >
>> > elinks cannot be installed for non-native architectures, because its
>> > dependency on elinks-data would be unsatisfiable. In general,
>> > Architecture: all packages can never satisfy dependencies from
>> > non-native architectures unless marked Multi-Arch: foreign. In this
>> > case, such a marking is correct, because elinks-data does not have any
>> > maintainer scripts nor dependencies. The same holds for elinks-doc. The
>> > attached patch marks both of them Multi-Arch: foreign. Please consider
>> > applying it after stretch is released.
>>
>> Could this fix be applied now, after the realease?
>>
>> It looks like a net improvement in the package, in any case, and would
>> enable to cross-build a few packages [1].
>
> Yeah, I can make an upload in the next week.

Great, thanks a lot!

-- 
Manuel A. Fernandez Montecelo 

Bug#834714: fixed in libxslt 1.1.29-3

[Manuel A. Fernandez Montecelo]

2017-11-05 13:27 GMT+01:00 Mattia Rizzolo :
> On Sun, Nov 05, 2017 at 05:57:24AM +, Hugh McMaster wrote:
>> I've finished building libxslt's reverse dependencies both with the
>> multi-arch patch and without it.
>
> Great, thank you!
>
>> Several packages failed to complete the build process in some way,
>> but these failures were unrelated to the multi-arch change.

Great job, thanks!

Just in case, did you verify if those build problems were already
reported as FTBFS bugs in those packages?

I don't know if they are many and I don't want to impose extra work on
you, but specially if you still have the build logs around, perhaps
you could verify and submit FTBFS attaching the logs, so there are
some chances of fixing those problems earlier (they'll be catched at
some point, but still...).


> Cool, I'll see about uploading it to unstable soon then ^^

Thanks Mattia for taking care, too!


-- 
Manuel A. Fernandez Montecelo 

Bug#873940: ITP: libluksmeta -- LUKSMeta is a simple library for storing metadata in the LUKSv1 header

[Christoph Biedl]

Christoph Biedl wrote...

> * Package name: libluksmeta
>   Version : 7
>   Upstream Author : Nathaniel McCallum https://github.com/npmccallum
> * URL : https://github.com/latchset/luksmeta
> * License : LGPL-2.1+
>   Programming Lang: C
>   Description : LUKSMeta is a simple library for storing metadata in the 
> LUKSv1 header

Status: This package is now in NEW (as luksmeta).

Christoph


signature.asc
Description: Digital signature

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Chris Lamb]

Hi Alf,

Thanks for your reply.

> * redis-server isn't installable, it should be
> * the start in postinst fails - for what reasons ever, nothing of any
> interest at this point - but that make the package uninstallable

The reason is surely highly relevant. ie. it is due to a bug in lxc
and/or systemd (or something else entirely), not Redis, and thus it
should be reassigned elsewhere?

You can then use the "affects" tag in the BTS so that it appears in
the Redis bug list, but that's simply to help direct others and
prevent potential duplicates.


Regards,

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

Bug#880775: mldonkey build depends on removed libgd2*-dev provides

[Ralf Treinen]

On Sat, Nov 04, 2017 at 09:43:53PM +0200, Adrian Bunk wrote:
> Source: mldonkey
> Version: 3.1.5-3.1
> Severity: serious
> Tags: buster sid
> 
> The following packages have unmet dependencies:
>  builddeps:mldonkey : Depends: libgd2-xpm-dev but it is not installable
> 
> 
> Please change the build dependency to libgd-dev.

Thanks, pushed to git, but not uploaded since we still have another FTBFS
(#876735).

-Ralf.

Bug#880915: python3-gnupg: Fails to import keys, exception "KEY_CONSIDERED"

[W. Martin Borgert]

On 2017-11-05 21:14, Elena ``of Valhalla'' wrote:
> It is true, however, that debian is migrating towards gnupg2, so if you
> (or anybody else) don't want to be stuck with both versions for another
> release what I can do is to provide a backport of the version currently
> in testing, as that one has gone back to use gpg as the gpgbinary.

Yes, please backport!

> (A note to myself, so that I don't forget about it: before uploading the
> backport I need to check that it does not break gajim and act
> appropriately if it does.)

Gajim 0.16.6-1.1 in stable still embeds its own copy of
python-gnugp. Not good, but good in this case.

Gajim 0.16.8-3~bpo9+1 in stretch-backports explicitely uses
'gpg1', but if a newer python-gnupg were in backports, we could
just depend on python-gnupg >= 0.4.1 what is done in testing
anyway. I can upload as soon as your backport passes bpo-NEW.


signature.asc
Description: PGP signature

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Alf Gaida]

Ok, second attempt. Only a few notes:
* redis-server isn't installable, it should be
* the start in postinst fails - for what reasons ever, nothing of any
interest at this point - but that make the package uninstallable
* it is a known problem - ok, not so much Stephan Graber or you can do
right now
* it turns out that it is a problem of the service or systemd - even
here it is not a problem
* there is a temporary "solution" - using the old init scripts which
still work as expected

So the situation right now is: redis-server don't start and apt is
messed up, not the best outcome. I would prefer if the package installs
- even if the server don't work afterwards. Not less, not more. The bug
in the service or in systemd is something completly different and should
be handled in a separated bug. And if the "workaround" is to use
systemd-sysv and the old init scripts, why not, as it is a test
installation in my case.

Cheers Alf



signature.asc
Description: OpenPGP digital signature

Bug#592159: Status update?

[Elena ``of Valhalla'']

Hello

I've seen that the required dependencies that blocked this bug have been
uploaded, so I wonder: what is the status of this ITP?

Is there any other dependency that is missing? or are there other
issues?

As somebody that is still looking for a great text-based xmpp client I'd
love to try poezio.

BTW, I've noticed that the homepage for it has changed: now it's 
https://poez.io/en/

Thanks for your packaging work.
-- 
Elena ``of Valhalla''

Bug#879474: quagga-bgpd: BGP session termination due to rather long AS paths in update messages

[Christoph Biedl]

Scott Leggett wrote...

> I've packaged upstream release 1.2.2 that fixes this bug (and several
> others including #880522) in unstable. I'm waiting on sponsorship for
> that upload [0].

Did some tests, looks good. As I already wrote in private, if I should
sponsor an upload, drop me a line.

Christoph


signature.asc
Description: Digital signature

Bug#880938: base-installer: must define _GNU_SOURCE for vasprintf in pkgdetails.c

[Shawn Landden]

Package: base-installer
Version: 1.171
Severity: important

in order to compile pkgdetails.c for debootstrap I had to add
#define _GNU_SOURCE

for vasprintf

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

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

Bug#880372: Pending fixes for bugs in the dom4j package

[pkg-java-maintainers]

tag 880372 + pending
thanks

Some bugs in the dom4j package are closed in revision
19d456eb3bfc83edfd1cdd3785aa50c56da686b7 in branch 'master' by tony
mancill

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/dom4j.git/commit/?id=19d456e

Commit message:

Remove link for changelog.html (Closes: #880372)

Bug#880690: [Pkg-rust-maintainers] Bug#880690: Bug#880690: dh-cargo: should build and test library

[Ximin Luo]

Josh Triplett:
> tags 880690 + confirmed
> severity 880690 wishlist
> thanks
> 
> On Fri, Nov 03, 2017 at 10:05:31PM +0100, Jonas Smedegaard wrote:
>> Package: dh-cargo
>> Version: 2
>> Severity: important
>>
>> dh-cargo registers as a _build_ system, yet does not build the library
>> nor does it execute its testsuite.
>>
>> I understand that Rust packaging policy mandates libraries should be
>> _installed_ only as source, but that does not preclude ensuring that it
>> properly builds and passes its testsuite.
> 
> This is something we should work towards, and may be able to do on a
> case-by-case basis, but we cannot run crate testsuites by default.
> *Many* crates are not capable of running their testsuites given only the
> contents of the .crate file; some require the full contents of the
> upstream git repository (including non-trivial test data), or
> non-standard tools, or git submodules, or any number of other things.
> 
> Beyond that, even if the testsuite could be run with only those files,
> neither "cargo test" nor "cargo build" can be reliably be run from the
> unpacked .crate, because the unpacked crate may incorporate things like
> workspaces. Only "cargo install cratename" (with a directory registry)
> is expected to work from a .crate, and only from a binary package, not a
> library package.
> 
> I'm tagging this as confirmed because we *do* want to do it at some
> point, and marking it as wishlist for the feature of allowing a package
> to opt in to running the testsuite in cases where it is known to work.
> 

It's issues like this that make me wonder if it would be better to re-architect 
debcargo and the Rust packaging policy to be workspace-oriented rather than 
crate-oriented. I was unfortunately not aware of this distinction back when I 
was first reviewing this stuff, but now I am.

The benefit is that a "workspace" usually corresponds to a git repo, and this 
would map more easily to a Debian source package, and you could make sure that 
all the files needed to run tests are present.

OTOH there are a couple of issues I can see immediately:

1. crates have their own version number histories, separate from the 
workspace's version number history. So we'd have to do some convoluted thing 
involving versioned Provides, for the binary packages, as well as some 
redundant naming scheme so dependencies can be properly expressed.

2. cargo does not seem to forbid the situation where workspace-A/crate-1 
depends on workspace-B/crate-1 depends on workspace-A/crate-2 which would give 
a circular dependency if we did workspace-based source packages. We have a 
similar situation with opam the ocaml package manager, and had seen some 
arrangements like this "in the wild" but so far was able to convince upstreams 
to break these quasi-cycles, after some bumps in the initial explanation 
attempts. I am not sure if most rust projects would accept our argument that 
these sorts of arrangements are Bad however, it took many paragraphs over 
several mails for me and others to explain this to the aforementioned ocaml 
projects.

and possibly other issues too.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#880937: qttools-opensource-src FTCBFS: does not pass cross tools to qmake

[Helmut Grohne]

Source: qttools-opensource-src
Version: 5.9.2-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

qttools-opensource-src does not cross build from source, because it does
not pass cross tools to qmake. Using debhelper should fix that.
qttools-opensource-src added an override for dh_auto_configure to work
around https://bugreports.qt.io/browse/QTBUG-30735, but that bug is
fixed now. Thus removing the override seems logical. Doing so makes the
configure step (but not the build step) succeed. Please consider
applying the attached patch and close this bug when doing so.

Helmut
diff --minimal -Nru qttools-opensource-src-5.9.2/debian/changelog 
qttools-opensource-src-5.9.2/debian/changelog
--- qttools-opensource-src-5.9.2/debian/changelog   2017-10-26 
23:35:11.0 +0200
+++ qttools-opensource-src-5.9.2/debian/changelog   2017-11-05 
20:48:58.0 +0100
@@ -1,3 +1,10 @@
+qttools-opensource-src (5.9.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_auto_configure pass cross tools to qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Nov 2017 20:48:58 +0100
+
 qttools-opensource-src (5.9.2-3) unstable; urgency=medium
 
   * Move Qt5LinguistTools*.cmake from qttools5-dev-tools to qttools5-dev.
diff --minimal -Nru qttools-opensource-src-5.9.2/debian/rules 
qttools-opensource-src-5.9.2/debian/rules
--- qttools-opensource-src-5.9.2/debian/rules   2017-10-26 23:35:11.0 
+0200
+++ qttools-opensource-src-5.9.2/debian/rules   2017-11-05 20:48:55.0 
+0100
@@ -16,11 +16,6 @@
 %:
dh $@ --with pkgkde_symbolshelper
 
-# We override qmake until https://bugreports.qt.io/browse/QTBUG-30735
-# gets solved (FTBFS with -nocache).
-override_dh_auto_configure:
-   qmake 
-
 override_dh_auto_clean:
dh_auto_clean
rm -fv .qmake.cache

Bug#880936: nodejs: updated version available upstream

[Jérémy Lal]

2017-11-05 21:19 GMT+01:00 Félix Sipma :

> Package: nodejs
> Version: 6.11.4~dfsg-1
> Severity: wishlist
>
> node version 8.9.0 LTS is available upstream. Could you consider packaging
> it?
>
> Thanks!


Sure, but nodejs 6.11.x first has to go in testing...

Jérémy

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[Don Armstrong]

On Sun, 05 Nov 2017, Dominique Dumont wrote:
> Anyway, using YAML::Any has several problems:
> - it's deprecated
> - it may load YAML or YAML::XS which have some security issues [1]

Heh; that's a pretty nice bug.

> Instead, I'm going to replace YAML::Any with YAML::Tiny (which is more than 
> enough in this case).

Sounds great; any solution is good for me. [I just want to be able to
write out UTF-8 names of copyright holders.]

> Thanks for the report . This helps me improve dpkg model for cme (and
> led to the release of Config::Model::Tester 3.003 which did not handle
> utf-8 correctly while checking file content).

No problem! Thanks for maintaining this. [It made updating
debian/copyright in autorandr much, much easier.]

-- 
Don Armstrong  https://www.donarmstrong.com

The game of science is, in principle, without end. He who decides one
day that scientific statements do not call for any further test, and
that they can be regarded as finally verified, retires from the game.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §11

Bug#880936: nodejs: updated version available upstream

[Félix Sipma]

Package: nodejs
Version: 6.11.4~dfsg-1
Severity: wishlist

node version 8.9.0 LTS is available upstream. Could you consider packaging it?

Thanks!

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

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

Versions of packages nodejs depends on:
ii  libc-ares2   1.13.0-2
ii  libc62.24-17
ii  libgcc1  1:7.2.0-12
ii  libicu57 57.1-8
ii  libssl1.0.2  1.0.2m-2
ii  libstdc++6   7.2.0-12
ii  libuv1   1.9.1-3
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages nodejs recommends:
ii  ca-certificates  20170717
pn  nodejs-doc   

nodejs suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#880915: python3-gnupg: Fails to import keys, exception "KEY_CONSIDERED"

[Elena ``of Valhalla'']

On 2017-11-05 at 19:56:07 +0100, deb...@activityworkshop.net wrote:
> Thanks very much for looking at this so promptly, and sorry for the
> incompleteness of the description.

it's fine, thanks for answering back promptly with the clarifications.

> On 2017-11-05 18:22, Elena ``of Valhalla'' wrote:
> > > from gpg import GPG
> > 
> > is this a typo for ``from gnupg import GPG``?
> Yes, you're right, sorry.

NP, just wanted to be sure before spending time on a wild chase :)

> [...]
> Unfortunately when I tried it again with a fresh keyring I realised that I'd
> made a mistake earlier, and the GPG construction wasn't what I had thought.
> I was actually doing this:
> gpg = GPG(gnupghome="/path/to/keyring", gpgbinary="gpg")
> [...]

then I know what the issue is:

the version of python3-gnupg currently in stretch has known issues with
gnupg version 2.1+: it had support for gnupg 2.0, but there were enough
changes in 2.1 that some features broke and they weren't fixed in time
for the freeze, so python(3)-gnupg was configured to default on gpg1 as
the gpgbinary.

The difference between stable and oldstable is that in jessie the binary
gpg was provided by gnupg 1.4, while in stretch this is gnupg 2.1, with
a significant interface difference.

> I need to do some reading about gpg1 and gpg2 and presumably just take the
> default instead of trying to specify one (I don't yet understand the
> differences).  I had thought that specifying the gpgbinary was necessary
> because on non-linux platforms it wouldn't necessarily be called "gpg".

I'm sorry that I don't know enough of non-linux platforms to help on
this point, but in the upstream code of this module there is already a
default set on gpgbinary to be 'gpg', so I believe that you probably
don't need to set it unless you need to do so in a platform-dependant
way in the cases where it has to differ from the default.

As for the choice between gpg1 and 2, python(3)-gnupg tries to
autodetect what it's working with and do the right thing, so if you
don't need the features provided by gpg2 you are probably fine just
using the default as that will work the same way on jessie, stretch and
buster even if the backend gpg changes.

It is true, however, that debian is migrating towards gnupg2, so if you
(or anybody else) don't want to be stuck with both versions for another
release what I can do is to provide a backport of the version currently
in testing, as that one has gone back to use gpg as the gpgbinary.
In that case, if you don't specify a gpgbinary yourself the users of
your program can choose whether to install the dependency from stable
(and live with both versions of gnupg installed) or use the one in
backports and be able to be rid of gnupg1.

(A note to myself, so that I don't forget about it: before uploading the
backport I need to check that it does not break gajim and act
appropriately if it does.)
-- 
Elena ``of Valhalla''

Bug#880551: xterm: corrections to man page

[Thomas Dickey]

On Thu, Nov 02, 2017 at 02:20:54AM -0400, G. Branden Robinson wrote:
> Package: xterm
> Version: 327-2 (but I prepared the diff against xterm-330)
> Severity: normal
> Tags: upstream
...
> 10. Remove boldfacing from portions of code examples; these escapes
> changed the font family back to Times from Courier.  If this change
> is unacceptable, I can come up with one that will stay within the
> Courier family, but it will only work for groff.  I don't know of
> a portable way to do what I think is desired here.

This is a problem, since I'm using the boldface to guide
a script which generates the hyperlinks here:

https://invisible-island.net/xterm/manpage/xterm.html

The \fP's should have done what was needed to restore the font-family...

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


signature.asc
Description: Digital signature

Bug#880905: exim4-config: Sender verification could be exploited for brute-force scan

[Paul Graham]

Hi!


At 05/11/17 18:59, Marc Haber wrote:

On Sun, Nov 05, 2017 at 04:09:37PM +0100, Andreas Metzler wrote:

I do not see the attacker gain, the same information can be extracted by
trying out RCPT TO *@omega-software.com with FROM attac...@gmail.com.

Additionally, we are desperately trying to stay close to the upstream
configuration. If this is really an issue, then all non-Debian exim
installations are vulnerable as well.

What I am trying to say is, this issue should be reported and
discussed with upstream _before_ we make this change. Paul, can you do
that to make your point there?

Yes of course. As moving sender verification is only useful if recipient 
verification is moved, I'll make my point for recipient verification first then.

If they're receptive I'll bring up sender verification after that.

--
Paul Graham
Development Dept.
http://Omega-Software.com/

Omega Software

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Chris Lamb]

[Re-adding 880...@bugs.debian.org to CC]

Hi Alf Gaida,

> + Attachment1
>   1k (application/pgp-encrypted)
> + encrypted.asc
>   3k (text/plain)

Please resend your mail, un-encrypted, and including all the CCs. :)


Best wishes,

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

Bug#880935: virtualbox: B-D on transitional package lynx-cur which is now gone

[Andreas Beckmann]

Source: virtualbox
Version: 5.2.0-dfsg-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

virtualbox Build-Depends on lynx-cur which was a transitional package in
stretch and is now gone from sid. Please switch to lynx instead.


Andreas

Bug#846260: numlockx: 'Homepage' URL dead

[Paul "LeoNerd" Evans]

On Tue, 29 Nov 2016 20:19:23 +0100
Michal Čihař  wrote:

> Sure it does.  The original author should be reachable as well (last
> time I know he AFAIK worked for Collabora), though I don't have
> working email contact.

Any further update on this?

I have a nicely working 'capslockx' program in a locally-modified
version of this package I'd like to get submitted back into Debian.

What steps next can we take to achieve this?

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/


pgpk6Koi8FxVc.pgp
Description: OpenPGP digital signature

Bug#880576: targetcli-fb: Cannot create PSCSI backend for SCSI tape drive

[Christian Seiler]

Control: tags -1 + confirmed upstream

Hi,

On 11/02/2017 02:29 PM, Herbert Nachtnebel wrote:
> exporting a local SCSI tape drive using targetcli is not possible. The used
> SCSI tape
> drive is an older HP Ultrium-2 SCSI drive connected via a Adaptec 29320ALP 
> U320
> PCIe
> SCSI controller to the host.  The host is a freshly set up Debian 9.2 system.

Thanks for the detailed bug report! Unfortunately I don't have a SCSI
tape drive with which I can test this (I only have disks and CD drives,
which do work according to your report), so I can't reproduce this
myself.

That said, I've looked at the code, and the current pscsi interface
in the targetcli GUI can only export block devices, but tape drives
are actually character devices - that's why it doesn't find anything,
because it looks for devices in /sys/block in the sysfs structure, and
the tape drive doesn't exist there.

Now I'm not currently sure whether this is just a but in targetcli
because it assumes block devices and that tape device export would
actually work on the kernel side, or if this also has problems with
the kernel.

Could you perhaps try to add this manually via the configfs interface?

1. Ensure that rtslib-fb-targetctl.service is started. (To make sure
   the configfs filesystem for LIO is mounted.)

2. Run the following commands to try to create the backstore manually:

# Create backstore ('tape' is just the name here, you can also call
# it something else if you like; the other part of the path is fixed
# though)
mkdir -p /sys/kernel/config/target/core/pscsi_0/tape

# Generate a unique WWN
uuidgen > /sys/kernel/config/target/core/pscsi_0/tape/wwn/vpd_unit_serial

# Add the device (IDs taken from your lsscsi output)
echo scsi_host_id=2,scsi_channel_id=0,scsi_target_id=0,scsi_lun_id=0 \
 > /sys/kernel/config/target/core/pscsi_0/tape/control

# Enable the backstore
echo 1 > /sys/kernel/config/target/core/pscsi_0/tape/enable

# Check kernel logs
# Check 'targetcli ls' output

If that works and the device is added you _should_ be able to export
it via targetcli. If that also works you should be able to use the
tape device from an iSCSI initiator.

What most likely won't work is targetctl being able to reload the
configuration when the system reboots, so this is only temporary. [1]

But if the export of the device actually does work on your system I
could create a patch for targetctl (and possibly targetcli) that
should fix this, and if that does work I'll ask the release team
whether I can get that into the next point release of Stretch.

Regards,
Christian

[1] Note: targetctl is the command used to restore configuration at
boot, targetcli is the shell to configure it.

Bug#880934: qtscript-opensource-src FTCBFS: does not pass cross tools to qmake

[Helmut Grohne]

Source: qtscript-opensource-src
Version: 5.9.2+dfsg-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

qtscript-opensource-src fails to cross build from source, because it
does not pass cross tools to qmake. Nowadays, debhelper should handle
that task and simply deferring it to dh_auto_configure makes the
configure step (but not the build step) succeed. Please consider
applying the attached patch and close this bug when doing so.

Helmut
diff --minimal -Nru qtscript-opensource-src-5.9.2+dfsg/debian/changelog 
qtscript-opensource-src-5.9.2+dfsg/debian/changelog
--- qtscript-opensource-src-5.9.2+dfsg/debian/changelog 2017-10-27 
20:03:34.0 +0200
+++ qtscript-opensource-src-5.9.2+dfsg/debian/changelog 2017-11-05 
20:41:22.0 +0100
@@ -1,3 +1,10 @@
+qtscript-opensource-src (5.9.2+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_auto_configure pass cross tools to qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Nov 2017 20:41:22 +0100
+
 qtscript-opensource-src (5.9.2+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru qtscript-opensource-src-5.9.2+dfsg/debian/rules 
qtscript-opensource-src-5.9.2+dfsg/debian/rules
--- qtscript-opensource-src-5.9.2+dfsg/debian/rules 2017-10-27 
20:03:34.0 +0200
+++ qtscript-opensource-src-5.9.2+dfsg/debian/rules 2017-11-05 
20:41:20.0 +0100
@@ -13,7 +13,7 @@
dh $@ --with pkgkde_symbolshelper
 
 override_dh_auto_configure:
-   qmake QT_BUILD_PARTS+=tests
+   dh_auto_configure -- QT_BUILD_PARTS+=tests
 
 override_dh_auto_build-indep:
dh_auto_build -- docs

Bug#880918: nfdump: New upstream release 1.6.16, fixing issues with netflows generated by recent Cisco firmwares

[Axel Beckert]

Hi Bernhard,

Bernhard Schmidt wrote:
> > Peter Haag has just released nfdump 1.6.16:
> 
> Thanks, I've uploaded a new package.

Much appreciated!

> It needs to go through NEW because I switched to -dbgsym packages,
> will hopefully be in the archive soon.

Might not be necssary. IIRC -dbgsym packages are excluded from
triggering the NEW process.

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

Bug#879914: fmtlib: please make the build reproducible

[Eugene V. Lyubimkin]

Hi,

On 27.10.2017 10:41, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that fmtlib could not be built reproducibly as — in a Doxygen error
> message — it exposes the use of Doxygen's "FULL_PATH_NAMES = YES".
> 
> Patch attached.

Looks good, thanks. Will be applied in the next upload.


-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Chris Lamb]

Hi Alf,

> Corresponding bug: https://github.com/lxc/lxd/issues/3799

As this link implies, this is not a bug in Debian's redis-server
package.

Or rather; what "next action" would you expect one to make after
receiving this bug — drop the systemd support altogether?

> Temporary "Solution" - drop the service files and invoke
> redis-server with the old init-scripts that work without flaw.

This seems excessive; the above URL has a superior temporary fix
that keeps (almost) all of the hardening features intact.


Regards,

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

Bug#877878: ITP: mailman-suite -- Django project integrating Mailman3 Postorius and HyperKitty

[Pierre-Elliott Bécue]

retitle -1 ITP: mailman-suite -- Django project integrating Mailman3 Postorius 
and HyperKitty

-- 
PEB

Bug#880932: ITP: node-bin-version -- Get the version of a binary in semver format

[Ross Gammon]

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

* Package name    : node-bin-version
  Version : 2.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/bin-version
* License : Expat
  Programming Lang: JavaScript
  Description : Get the version of a binary in semver format

 Node-bin-version returns the version of a binary in semver format. Semver
 is the semantic versioning system for npm.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#880933: Installation of redis-server fails badly in a buster lxc container

[Alf Gaida]

Package: redis-server
Version: 4:4.0.2-5
Severity: important

Dear Maintainer.

as the subject says, apt fails to install redis-server inside a buster 
container:

Setting up redis-server (4:4.0.2-5) ...
Installing new version of config file /etc/init.d/redis-server ...
Installing new version of config file /etc/redis/redis.conf ...
Job for redis-server.service failed because the control process exited with 
error code.
See "systemctl  status redis-server.service" and "journalctl  -xe" for details.
invoke-rc.d: initscript redis-server, action "restart" failed.
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Sun 2017-11-05 
19:16:06 UTC; 50ms ago
 Docs: http://redis.io/documentation,
   man:redis-server(1)
  Process: 27358 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf 
(code=exited, status=237/KEYRING)

Nov 05 19:16:07 gitlab systemd[1]: Starting Advanced key-value store...
Nov 05 19:16:07 gitlab systemd[1]: redis-server.service: Control process 
exited, code=exited status=237
Nov 05 19:16:07 gitlab systemd[1]: redis-server.service: Failed with result 
'exit-code'.
Nov 05 19:16:07 gitlab systemd[1]: Failed to start Advanced key-value store.
Nov 05 19:16:07 gitlab systemd[1]: redis-server.service: Service hold-off time 
over, scheduling restart.
Nov 05 19:16:07 gitlab systemd[1]: redis-server.service: Scheduled restart job, 
restart counter is at 5.
Nov 05 19:16:07 gitlab systemd[1]: Stopped Advanced key-value store.
Nov 05 19:16:07 gitlab systemd[1]: redis-server.service: Start request repeated 
too quickly.
Nov 05 19:16:07 gitlab systemd[1]: redis-server.service: Failed with result 
'exit-code'.
Nov 05 19:16:07 gitlab systemd[1]: Failed to start Advanced key-value store.
dpkg: error processing package redis-server (--configure):
 installed redis-server package post-installation script subprocess returned 
error exit status 1

Corresponding bug: https://github.com/lxc/lxd/issues/3799

Temporary "Solution" - drop the service files and invoke redis-server with the 
old init-scripts that work 
without flaw.

Cheers Alf


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

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

Versions of packages redis-server depends on:
ii  adduser  3.116
ii  lsb-base 9.20170808
ii  redis-tools  4:4.0.2-5

redis-server recommends no packages.

redis-server suggests no packages.

-- no debconf information

Bug#880931: qtx11extras-opensource-src FTCBFS: does not pass cross tools to qmake

[Helmut Grohne]

Source: qtx11extras-opensource-src
Version: 5.9.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

qtx11extras-opensource-src fails to cross build from source, because it
does not pass cross tools to qmake. Nowadays, debhelper should be able
to do so and thus removing the override_dh_auto_configure makes the
configure step (but not the build step) succeed. This seems like a
general packaging improvement to me. Please consider applying the
attached patch and close this bug when doing so.

Helmut
diff --minimal -Nru qtx11extras-opensource-src-5.9.2/debian/changelog 
qtx11extras-opensource-src-5.9.2/debian/changelog
--- qtx11extras-opensource-src-5.9.2/debian/changelog   2017-10-26 
15:32:12.0 +0200
+++ qtx11extras-opensource-src-5.9.2/debian/changelog   2017-11-05 
20:30:17.0 +0100
@@ -1,3 +1,10 @@
+qtx11extras-opensource-src (5.9.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_auto_configure pass cross tools to qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Nov 2017 20:30:17 +0100
+
 qtx11extras-opensource-src (5.9.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru qtx11extras-opensource-src-5.9.2/debian/rules 
qtx11extras-opensource-src-5.9.2/debian/rules
--- qtx11extras-opensource-src-5.9.2/debian/rules   2017-10-26 
15:32:12.0 +0200
+++ qtx11extras-opensource-src-5.9.2/debian/rules   2017-11-05 
20:30:08.0 +0100
@@ -13,9 +13,6 @@
 %:
dh $@ --with pkgkde_symbolshelper
 
-override_dh_auto_configure:
-   qmake 
-
 override_dh_auto_build-indep:
dh_auto_build -Smakefile -- docs
 

Bug#880930: qtsvg-opensource-src FTCBFS: doesn't pass cross tools to qmake

[Helmut Grohne]

Source: qtsvg-opensource-src
Version: 5.9.2-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

qtsvg-opensource-src fails to cross build from source, because it
doesn't pass any cross tools to qmake. Now debhelper learned how to do
that for qmake, so using dh_auto_configure should be sufficient. Indeed,
it does make the configure step (but not the build step succeed). Using
dh_auto_configure also ensures that build flags are passed down and that
stripping is deferred to dh_strip, so this seems like a general
improvement. Please consider applying the attached patch.

Helmut
diff --minimal -Nru qtsvg-opensource-src-5.9.2/debian/changelog 
qtsvg-opensource-src-5.9.2/debian/changelog
--- qtsvg-opensource-src-5.9.2/debian/changelog 2017-10-26 15:49:09.0 
+0200
+++ qtsvg-opensource-src-5.9.2/debian/changelog 2017-11-05 20:17:50.0 
+0100
@@ -1,3 +1,10 @@
+qtsvg-opensource-src (5.9.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_auto_configure pass cross tools to qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Nov 2017 20:17:50 +0100
+
 qtsvg-opensource-src (5.9.2-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru qtsvg-opensource-src-5.9.2/debian/rules 
qtsvg-opensource-src-5.9.2/debian/rules
--- qtsvg-opensource-src-5.9.2/debian/rules 2017-10-26 15:49:09.0 
+0200
+++ qtsvg-opensource-src-5.9.2/debian/rules 2017-11-05 20:17:48.0 
+0100
@@ -14,7 +14,7 @@
dh $@ --with pkgkde_symbolshelper
 
 override_dh_auto_configure:
-   qmake QT_BUILD_PARTS+=tests
+   dh_auto_configure -- QT_BUILD_PARTS+=tests
 
 override_dh_auto_build-indep:
dh_auto_build -Smakefile -- docs

Bug#644632: Patch needed

[Bernhard Schmidt]

Control: tags -1 help

Since nfdump is now started in a systemd unit this needs to be
implemented differently, preferably with a systemd generator and
instances. Patches (tested, preferably upstreamable) are welcome.

Bernhard


signature.asc
Description: PGP signature

Bug#880929: RM: fpc 3.0.2 [ppc64el s390x] -- NVIU; britney isn't clever enough to detect that arch:all is cruft on these arches

[Paul Gevers]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As described in bug 859566¹, britney isn't clever enough to detect some cases
where old arch:all packages should be considered cruft. fpc 3.0.2 has built the
following binary package that are not build by 3.0.4 and that are now included
in the packages list for ppc64el and s390x while fpc FTBFS on those arches
(bootstrapping hasn't happened so far):
fp-docs-3.0.2
fpc-3.0.2
fpc-source-3.0.2

In the past I have requested removal of individual binary packages for this
situation. It has been recommend to request source removal instead.

Please remove fpc 3.0.2 from unstable on ppc64el and s390x or do whatever is
most convenient to let fpc 3.0.4 migrate to testing while britney isn't fixed.

Paul

¹ https://bugs.debian.org/859566

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAln/ZmoACgkQnFyZ6wW9
dQrR1wgAvReHADvixc4y4tx7wNB1mtm4rROGlAR4J2mNqmbHnzc0OWa/5dwouTtU
UjCnCzm0tIWVyaluvi1UI4pdmkiALFA2duHGJfd3u796Bv/IhFTKNNA+QQBrOo8M
n/m53Ke/ONd0WL+zLz884QzZLfLdY/o4rFklzvDGkwOZ22jhVCPRJXzdctQbGmeY
/kOuoD7eSAX2BnsFOu6cjAGGGndZvtpxDcLWFvsIiE9wCOQegG25pTJnw5tUUmjl
GWMwq8GjdifhFaAjUQK6x1fpbV4yE68OSsUMsmDN2FOhHeXcgS/Q4GJSWcZWjYXz
k/1VRHa7USyU32Uc+zYttWph4fldWg==
=1S+g
-END PGP SIGNATURE-

Bug#843602: WONTFIX, please use systemd overrides

[Bernhard Schmidt]

Control: tags 843602 wontfix

Hi,

nfdump is nowadays (since stretch, it was not part of jessie) started by
a native systemd unit.

#416501, #497446, #843602
The proper way to change configuration from the systemd units are
overrides, i.e. to set a commandline parameter

# systemctl edit nfdump.service

and enter this into the spawning editor

---
[Service]
ExecStart=/usr/bin/nfcapd 
---

using /etc/default/nfdump is deprecated with systemd, and extremely hard
to model using a native systemd unit in the way it has been done with
the previous initscript (with defaults being set in the initscript, and
DAEMON_ARGS referencing other variables).

I'm marking 843602 as wontfix to document this and close the others.

Bernhard


signature.asc
Description: PGP signature

Bug#799292: ITP: mailman-suite -- Mailman3 mailing list manager suite

[Pierre-Elliott Bécue]

Control: retitle -1 ITP: mailman-suite -- Mailman3 mailing list manager suite

Soon.

-- 
PEB

Bug#879785: Info received (Bug#879785: cinnamon: windows lose focus often)

[Christophe Collaudin]

hello
the change of my mouse (usb mouse instead bluetooth mouse) resolve the bug

Le 26 oct. 2017 19:57, "Debian Bug Tracking System" 
a écrit :

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Cinnamon Team 
>
> If you wish to submit further information on this problem, please
> send it to 879...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 879785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879785
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#799288: Acknowledgement (ITP: mailman3-hyperkitty-plugin -- Mailing list management system)

[Pierre-Elliott Bécue]

Control: retitle -1 ITP: mailman-hyperkitty -- Plugin for interaction between 
mailman core server and hyperkitty archiver.

In new.

-- 
PEB

Bug#880928: gfan does not support DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: gfan
Version: 0.5+dfsg-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

While trying to cross build gfan, I noticed that it runs the test suite
despite DEB_BUILD_OPTIONS=nocheck. The attached patch makes it honour
that setting, but doesn't make it cross build. Can you apply it anyway?

Helmut
diff --minimal -Nru gfan-0.5+dfsg/debian/changelog 
gfan-0.5+dfsg/debian/changelog
--- gfan-0.5+dfsg/debian/changelog  2016-07-14 09:54:58.0 +0200
+++ gfan-0.5+dfsg/debian/changelog  2017-11-05 20:01:21.0 +0100
@@ -1,3 +1,10 @@
+gfan (0.5+dfsg-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Nov 2017 20:01:21 +0100
+
 gfan (0.5+dfsg-6) unstable; urgency=medium
 
   * debian/control:
diff --minimal -Nru gfan-0.5+dfsg/debian/rules gfan-0.5+dfsg/debian/rules
--- gfan-0.5+dfsg/debian/rules  2016-07-14 09:54:58.0 +0200
+++ gfan-0.5+dfsg/debian/rules  2017-11-05 20:01:20.0 +0100
@@ -15,8 +15,10 @@
 override_dh_auto_install:
$(MAKE) install PREFIX=$(DEB_DESTDIR)/usr
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 override_dh_auto_test:
./gfan _test
+endif
 
 override_dh_clean:
dh_clean -X~

Bug#862120: please enable ASA/NSEL/NEL event data processing

[Bernhard Schmidt]

Control: tags -1 pending

On Mon, May 08, 2017 at 08:35:58PM +0200, Sven Hartge wrote:

Hi Sven,

> To be able to process Netflow-v9/IPFIX NAT events, for example sent by
> Cisco ASA or ipt_NETFLOW, nfdump needs to be compiled with --enable-nsel.

Will be in 1.6.16-1, currently in NEW.

Bernhard

Bug#872569: RFS: kadu/4.3-0.1 [RC]

[Adrian Bunk]

On Wed, Aug 30, 2017 at 08:13:08PM +0200, Mateusz Łukasik wrote:
>...
> debdiff attacted.
>...

Thanks, uploaded.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#880918: nfdump: New upstream release 1.6.16, fixing issues with netflows generated by recent Cisco firmwares

[Bernhard Schmidt]

Control: tags -1 pending

On Sun, Nov 05, 2017 at 05:50:49PM +0100, Axel Beckert wrote:

Hi,

> Peter Haag has just released nfdump 1.6.16:

Thanks, I've uploaded a new package. It needs to go through NEW because
I switched to -dbgsym packages, will hopefully be in the archive soon.

Bernhard


signature.asc
Description: PGP signature

Bug#842363: nfdump: Wrong URL in debian/copyright, Homepage header and debian/copyright seem out of date

[Bernhard Schmidt]

On Fri, Sep 22, 2017 at 03:14:13PM +0200, Axel Beckert wrote:

Hi Axel,

> Since nfdump is under collab-maint, I've allowed myself to make these
> changes in git and push the change into the unstable branch, so that
> they will be fixed whenever the next upload happens.

Thanks, uploaded with 1.6.16-1. Will need to go through NEW due to
-dbgsym migration.

Feel free to make any changes to nfdump in collab-maint you want, that's
what collab-maint is for :-)

Bernhard


signature.asc
Description: PGP signature

Bug#880915: python3-gnupg: Fails to import keys, exception "KEY_CONSIDERED"

[debian]

Thanks very much for looking at this so promptly, and sorry for the 
incompleteness of the description.


On 2017-11-05 18:22, Elena ``of Valhalla'' wrote:

from gpg import GPG


is this a typo for ``from gnupg import GPG``?

Yes, you're right, sorry.


I've tried to reproduce it by exporting a secret key both by armouring
it and reading it as a string (``with open('somekey.asc') as fp: strKey
= fp.read()``) ...


that's right, I'm using a file containing an armoured key (readable 
encoded characters) and reading it into a string.


Unfortunately when I tried it again with a fresh keyring I realised that 
I'd made a mistake earlier, and the GPG construction wasn't what I had 
thought.  I was actually doing this:

gpg = GPG(gnupghome="/path/to/keyring", gpgbinary="gpg")

I thought I had removed the gpgbinary parameter and demonstrated that it 
didn't make any difference, but I was mistaken.


In /usr/bin/ I have gpg, gpg1, and gpg2 which is a link to gpg.
If I do not specify a gpgbinary, or if I specify gpg1, then the import 
works.  If I specify gpg or gpg2 then I get the error I reported 
earlier, with KEY_CONSIDERED.


I need to do some reading about gpg1 and gpg2 and presumably just take 
the default instead of trying to specify one (I don't yet understand the 
differences).  I had thought that specifying the gpgbinary was necessary 
because on non-linux platforms it wouldn't necessarily be called "gpg".


Sorry for the confusion.

Bug#880927: python-django-pyscss FTBFS: test failures

[Adrian Bunk]

Source: python-django-pyscss
Version: 2.0.2-7
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-pyscss.html

...
===> Testing with python2.7
running test
running egg_info
writing requirements to django_pyscss.egg-info/requires.txt
writing django_pyscss.egg-info/PKG-INFO
writing top-level names to django_pyscss.egg-info/top_level.txt
writing dependency_links to django_pyscss.egg-info/dependency_links.txt
reading manifest file 'django_pyscss.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files matching '*.pyc' found under directory 
'tests'
warning: no previously-included files matching '*.pyc' found under directory 
'testproject'
writing manifest file 'django_pyscss.egg-info/SOURCES.txt'
running build_ext
System check identified some issues:

WARNINGS:
?: (1_8.W001) The standalone TEMPLATE_* settings were deprecated in Django 1.8 
and the TEMPLATES dictionary takes precedence. You must put the values of the 
following settings into your default TEMPLATES dict: TEMPLATE_DEBUG.

System check identified 1 issue (0 silenced).
FF
==
FAIL: test_compressor_can_compile_scss (tests.test_compressor.CompressorTest)
--
Traceback (most recent call last):
  File "/build/1st/python-django-pyscss-2.0.2/tests/test_compressor.py", line 
31, in test_compressor_can_compile_scss
self.assertIn('6e08ca3b084a.css', actual)
AssertionError: '6e08ca3b084a.css' not found in u'\n\n\n'

==
FAIL: test_compressor_can_compile_scss_from_style_tag 
(tests.test_compressor.CompressorTest)
--
Traceback (most recent call last):
  File "/build/1st/python-django-pyscss-2.0.2/tests/test_compressor.py", line 
38, in test_compressor_can_compile_scss_from_style_tag
self.assertIn('6e08ca3b084a.css', actual)
AssertionError: '6e08ca3b084a.css' not found in u'\n\n\n'

--
Ran 30 tests in 3.592s

FAILED (failures=2)
Creating test database for alias 'default'...
Destroying test database for alias 'default'...
debian/rules:19: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?

[Clément Hermann]

Control: retitle -1 ITA: seahorse-nautilus -- Nautilus extension for Seahorse 
integration

Fixing title. Thunderbird wrapped it.


Cheers,

-- 
nodens

Bug#880925: no checks to know if the debdelta mirror is up or down.

[shirish शिरीष]

Package: debdelta
Version: 0.60
Severity: normal

Dear Maintainer,

First of all thank you for still maintaining and caring about
debdelta. I did see the last update according to changelog.gz is 12th
Oct which means you are still maintaining it.

Now when I run debdelta-upgrade even with -d flat it goes like -

─[$] sudo debdelta-upgrade -d

Delta missing, server failed to create it:
aisleriot_1%3a3.22.3-1_1%3a3.22.4-1_amd64.debdelta
Delta missing, server failed to create it:
asymptote_2.41-2+b1_2.41-3_amd64.debdelta

Now as shared also in #779897 it just doesn't tell where the issue is ?

This has been happening over a week now. It seems the server is down.

Pinging debdelta.debian.net gets you nowhere.

Preferably

[$] ping debdelta.debian.net

PING flip.selfip.org (82.59.164.70) 56(84) bytes of data.
^C
--- flip.selfip.org ping statistics ---
201 packets transmitted, 0 received, 100% packet loss, time 204759ms

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

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

Versions of packages debdelta depends on:
ii  binutils2.29.1-6
ii  bzip2   1.0.6-8.1
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-17
ii  python  2.7.14-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages debdelta recommends:
ii  bsdiff   4.3-20
ii  gnupg-agent  2.2.1-5
ii  gnupg2   2.2.1-5
ii  gpg-agent [gnupg-agent]  2.2.1-5
ii  python-apt   1.4.0~beta3+b1
ii  python-debian0.1.31
ii  xdelta   1.1.3-9.1+b1
ii  xdelta3  3.0.11-dfsg-1+b1
ii  xz-utils [lzma]  5.2.2-1.3

Versions of packages debdelta suggests:
ii  debdelta-doc  0.60

-- no debconf information

Please fix the above.


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

Bug#880926: RFH: linphone -- SIP softphone - graphical client

[Bernhard Schmidt]

Package: wnpp
Severity: normal

Hi,

although I'm not the maintainer of the current linphone package (and not
a user anyway), I'm asking for help on behalf of the pkg-voip team.

linphone in Debian is in a pretty bad shape, it has not seen an upstream
release packaged for four years.

There have been a couple of attempts to revive packaging of a current
linphone [1][2][3], but all of them have somewhat stalled.

The dependency stack is quite large and tightly coupled. Part of it is
already in Debian, part is in NEW, most of the updated packages are
already in the pkg-voip git repo. Most of them need minor updates to
build with gcc-7. I've written about the current status here [4]

Upstream is now switching away from the GTK2+ GUI client bundled in
src:linphone towards a Qt5-based linphone-desktop, which needs to be
packaged as well.

linphone needs at least one Developer (or maintainer, I can sponsor 
the uploads if necessary) to take care of this reliably.

Best Regards,
Bernhard

[1] 
https://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2016-November/029603.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2016-December/029963.html
[3] 
http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2017-April/030495.html
[4] 
http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2017-October/031389.html

Bug#835197: RFP: fonts-eosrei-emojione

[Jeremy Bicha]

On Sun, Nov 5, 2017 at 11:48 AM, Jeremy Bicha  wrote:
> Fedora 27 includes the Noto emoji by default.

Let me clarify: Fedora 27 pre-release includes an ancient black &
white version of the Noto emoji font which is surprising. And it's not
clear yet whether they will ship the Noto color emoji font in future
releases by default or the old Emoji One / Emoji Two font.

Thanks,
Jeremy Bicha

Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?

[intrigeri]

Clément Hermann:
> Since there is no news for a while and seahorse-nautilus has been
> removed from testing, I'll resume work on this under the pkg-privacy
> umbrella.

Excellent, thanks!

> Carlos, feel free to jump in if you still want to work on this package!

Indeed, team-maintenance is more pleasant (having someone around to
ask for advice/opinions in nice) and produces higher-quality packages.

And Ulrike is committed to work on this package as well, at least
until the end of 2018Q1, so you folks have a dedicated sponsor to
upload your work already :)

Cheers,
-- 
intrigeri

Bug#861211: festival: text2wave no longer works in pipe

[Samuel Thibault]

Control: forwarded -1 festival-t...@festvox.org
Control: tags -1 + upstream
Control: severity -1 normal

Hello,

Sorry for having missed your report for so long.

Andy Bennett, on mer. 26 avril 2017 00:23:34 +0100, wrote:
> echo "$string" | text2wave |aplay -q
> 
> This now no longer works under Jessie.

Indeed, text2wave now uses fseek, which can't work with pipes.

I have forwarded the report to upstream, but I'm afraid it'll be
difficult for them to work back to avoid using fseek. It probably means
you will have to use a temporary file.

Samuel

Bug#880851: libva: FTBFS on non-Linux: __NR_gettid undeclared

[Sebastian Ramacher]

Control: tags -1 + help

On 2017-11-05 00:17:54, Aaron M. Ucko wrote:
> Source: libva
> Version: 1.8.3-2
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
> 
> Builds of libva for kfreebsd-* (admittedly not release architectures)
> have been failing lately:
> 
>   va_trace.c: In function 'add_trace_config_info':
>   va_trace.c:294:28: error: '__NR_gettid' undeclared (first use in this 
> function); did you mean '__getpgid'?
>pid_t thd_id = syscall(__NR_gettid);
> 
> (plus a few more uses further down in va_trace.c).  Builds for
> hurd-i386 (not a release architecture) are blocked on the
> unavailability of libdrm-dev there, but will presumably encounter the
> same error if and when it ever becomes available.
> 
> Could you please take a look?

Dear kfreebsd-porters, could you have a look at that issue?

Cheers

> 
> Thanks!
> 
> -- 
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

-- 
Sebastian Ramacher

Bug#743494: linphone: Does not work with TLS

[Franko]

Package: linphone
Version: 3.6.1-3
Followup-For: Bug #743494

Hi,

The same problem with Linphone 3.6.1 on Debian 9-testing, kernel
4.13.0-1-amd64.
If I change port or protocol to SIP(UDP) or SIP(TCP), always the same error:
Could not start tls transport on port 5062, maybe this port is already used.
Thanks,
Franko



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

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

Versions of packages linphone depends on:
ii  libasound2  1.1.3-5
ii  libatk1.0-0 2.26.0-2
ii  libavcodec577:3.3.4-2+b2
ii  libavutil55 7:3.3.4-2+b2
ii  libc6   2.24-17
ii  libcairo2   1.15.8-2
ii  libexosip2-11   4.1.0-2.1
ii  libfontconfig1  2.12.3-0.2
ii  libfreetype62.8.1-0.1
ii  libgdk-pixbuf2.0-0  2.36.11-1
ii  libgl1  0.2.999+git20170802-5
ii  libgl1-mesa-glx 17.2.3-1
ii  libglew2.0  2.0.0-5
ii  libglib2.0-02.54.1-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgtk2.0-0 2.24.31-2
ii  liblinphone53.6.1-3
ii  libmediastreamer-base3  3.6.1-3
ii  libnotify4  0.7.7-2
ii  libogg0 1.3.2-1+b1
ii  libopus01.2.1-1
ii  libortp93.6.1-3
ii  libosip2-11 4.1.0-2.1
ii  libpango-1.0-0  1.40.12-1
ii  libpangocairo-1.0-0 1.40.12-1
ii  libpangoft2-1.0-0   1.40.12-1
ii  libpulse0   11.1-1
ii  libsoup2.4-12.60.1-1
ii  libspandsp2 0.0.6+dfsg-0.1
ii  libspeex1   1.2~rc1.2-1+b2
ii  libspeexdsp11.2~rc1.2-1+b2
ii  libsqlite3-03.20.1-2
ii  libswscale4 7:3.3.4-2+b2
ii  libtheora0  1.1.1+dfsg.1-14+b1
ii  libudev1235-2
ii  libupnp61:1.6.22-1
ii  libv4l-01.12.5-1
ii  libvpx4 1.6.1-3
ii  libx11-62:1.6.4-3
ii  libxv1  2:1.0.11-1
ii  linphone-nogtk  3.6.1-3

linphone recommends no packages.

Versions of packages linphone suggests:
ii  yelp  3.26.0-1

-- no debconf information

Bug#871502: Re : Bug#871502: zotero-standalone-build: The newer Zotero is standalone only ; a reorganization is neded.

[Sébastien Villemot]

On Sun, Nov 05, 2017 at 07:10:36PM +0100, Sébastien Villemot wrote:
> On Sun, Nov 05, 2017 at 06:59:38PM +0100, Félix Sipma wrote:
> > On 2017-11-05 18:50+0100, Sébastien Villemot wrote:
> > > On Sun, Nov 05, 2017 at 06:28:42PM +0100, Emmanuel Charpentier wrote:
> > >> Le dimanche 05 novembre 2017 à 18:11 +0100, Sébastien Villemot a
> > >> écrit :
> > >>> On Sun, Nov 05, 2017 at 03:15:59PM +0100, Félix Sipma wrote:
> > >>> So, unless I am missing something, it’s not yet possible to provide
> > >>> Zotero 5
> > >>> with the new Firefox connector. And shipping only the standalone app
> > >>> is rather
> > >>> useless in my opinion.
> > >> 
> > >> Nope. For two reasons :
> > >> 
> > >>   - Zotero standalone can be used with Chrom{e|ium} and the
> > >> corresponding connector.
> > >> 
> > >>   - At least as an interim measure, Debian users could use Zotero-
> > >> built connectors along with Debian-packaged Chromium and Firefox.
> > > 
> > > Since I am using zotero with Firefox, I must say that my motivation to 
> > > package
> > > it without the Firefox connector is rather low (and I am not interested in
> > > packaging node-web-ext).
> > > 
> > > Basically if any of you wants to become (co-)maintainer of the package 
> > > and do
> > > the work, you are more than welcome! I may even open an official RFH/RFA, 
> > > I’ll see.
> > 
> > OK, I can try to update the package, and may be interested in 
> > (co-)maintaining
> > it.
> 
> Thanks Félix, this is a good news.
> 
> As you may have already seen, this is a rather complex package.
> 
> The first step is to update the machinery under the get-orig-source target of
> debian/rules, in order to get a new orig tarball.
> 
> And the most painful part is to deal with all the minified javascript that is
> spread across the various translators, and which are problematic from a DFSG
> perspective. See debian/source/lintian-overrides and the files under
> debian/missing-sources/*. This is a grunt work that has to be updated with
> every new release; I did not check if there is much to update for the 5.0
> release.

I forgot to mention the debian/copyright file, which is also a tad painful to
update.

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


signature.asc
Description: PGP signature

Bug#880718: Test with latest arut/nginx-rtmp-module

[Cyril M.]

Dear maintainer,

I rebuild libnginx-mod-rtmp with the 4 missing commits from the main
repository of libnginx-mod-rtmp and despite the still present "syntax
errors" constantly spawning in the web browser console, the MPEG-dash
streaming seems to be functional (at least with Firefox 56).

I suggest to use the module in its latest revision (10/07/2017 as per
git commits) for at least having a working MPEG-dash streaming and
hoping for better options in the future in case of other bugs being found.

Regards,
Cyril



signature.asc
Description: OpenPGP digital signature

Bug#880924: scilab launch problem in buster

[laa]

Package: scilab
Version: 5.5.2-6
Severity: normal

Dear Maintainer,

Scilab does not launch in buster:
$ scilab
Не удалось создать главный класс Scilab. Ошибка:
Exception in thread "main" java.lang.InternalError: XXX0 profile[1]: GL3bc ->
profileImpl GL4bc !!! not mapped
at com.jogamp.opengl.GLProfile.computeProfileMap(GLProfile.java:2071)
at
com.jogamp.opengl.GLProfile.initProfilesForDeviceCritical(GLProfile.java:1954)
at
com.jogamp.opengl.GLProfile.initProfilesForDevice(GLProfile.java:1875)
at
com.jogamp.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1842)
at com.jogamp.opengl.GLProfile.access$000(GLProfile.java:80)
at com.jogamp.opengl.GLProfile$1.run(GLProfile.java:230)
at java.security.AccessController.doPrivileged(Native Method)
at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:216)
at com.jogamp.opengl.GLProfile.getProfileMap(GLProfile.java:2297)
at com.jogamp.opengl.GLProfile.get(GLProfile.java:988)
at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:722)
at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:733)
at org.scilab.modules.gui.SwingView.(Unknown Source)
at org.scilab.modules.gui.SwingView.registerSwingView(Unknown Source)
at org.scilab.modules.core.Scilab.(Unknown Source)

Scilab не может создать Scilab Java Main-Class (не удалось найти главный класс
Scilab. Проверьте доступны ли Scilab и сторонние пакеты).




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

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

Versions of packages scilab depends on:
ii  scilab-cli   5.5.2-6
ii  scilab-full-bin  5.5.2-6

Versions of packages scilab recommends:
ii  scilab-doc  5.5.2-6

Versions of packages scilab suggests:
pn  scilab-doc-fr 
pn  scilab-doc-ja 
pn  scilab-doc-pt-br  

-- no debconf information

Bug#871502: Re : Bug#871502: zotero-standalone-build: The newer Zotero is standalone only ; a reorganization is neded.

[Sébastien Villemot]

On Sun, Nov 05, 2017 at 06:59:38PM +0100, Félix Sipma wrote:
> On 2017-11-05 18:50+0100, Sébastien Villemot wrote:
> > On Sun, Nov 05, 2017 at 06:28:42PM +0100, Emmanuel Charpentier wrote:
> >> Le dimanche 05 novembre 2017 à 18:11 +0100, Sébastien Villemot a
> >> écrit :
> >>> On Sun, Nov 05, 2017 at 03:15:59PM +0100, Félix Sipma wrote:
> >>> So, unless I am missing something, it’s not yet possible to provide
> >>> Zotero 5
> >>> with the new Firefox connector. And shipping only the standalone app
> >>> is rather
> >>> useless in my opinion.
> >> 
> >> Nope. For two reasons :
> >> 
> >>   - Zotero standalone can be used with Chrom{e|ium} and the
> >> corresponding connector.
> >> 
> >>   - At least as an interim measure, Debian users could use Zotero-
> >> built connectors along with Debian-packaged Chromium and Firefox.
> > 
> > Since I am using zotero with Firefox, I must say that my motivation to 
> > package
> > it without the Firefox connector is rather low (and I am not interested in
> > packaging node-web-ext).
> > 
> > Basically if any of you wants to become (co-)maintainer of the package and 
> > do
> > the work, you are more than welcome! I may even open an official RFH/RFA, 
> > I’ll see.
> 
> OK, I can try to update the package, and may be interested in (co-)maintaining
> it.

Thanks Félix, this is a good news.

As you may have already seen, this is a rather complex package.

The first step is to update the machinery under the get-orig-source target of
debian/rules, in order to get a new orig tarball.

And the most painful part is to deal with all the minified javascript that is
spread across the various translators, and which are problematic from a DFSG
perspective. See debian/source/lintian-overrides and the files under
debian/missing-sources/*. This is a grunt work that has to be updated with
every new release; I did not check if there is much to update for the 5.0
release.

I hope you are still motivated to do the work after having looked at this :)

Ideally I would also like to move the package under the Debian Science Team
umbrella, because team maintenance is always better. But this can be postponed
if it complicates things for you (e.g. if you're not already in the Debian
Science team on Alioth).

Please feel free to update the repository (possibly on a new branch if you are
not confident enough). I will be happy to sponsor your work once it is ready
(I understand that you are a DM and not yet a DD).

Best,

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


signature.asc
Description: PGP signature

Bug#880905: exim4-config: Sender verification could be exploited for brute-force scan

[Marc Haber]

On Sun, Nov 05, 2017 at 04:09:37PM +0100, Andreas Metzler wrote:
> I do not see the attacker gain, the same information can be extracted by
> trying out RCPT TO *@omega-software.com with FROM attac...@gmail.com.

Additionally, we are desperately trying to stay close to the upstream
configuration. If this is really an issue, then all non-Debian exim
installations are vulnerable as well.

What I am trying to say is, this issue should be reported and
discussed with upstream _before_ we make this change. Paul, can you do
that to make your point there?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421