Bug#870126: ecryptfs-mount-private: mount: No such file or directory

[Craig Small]

Package: ecryptfs-utils
Version: 111-4
Severity: important

I have setup the standard home ~/Private directory. It looks like it is 
confused about which key to use.

For the last few months or so, I get this (key IDs changed but consistent
in report):

$ ecryptfs-mount-private 
Enter your login passphrase:
Inserted auth tok with sig [] into the user session keyring
mount: No such file or directory

The kernel reports:
Jul 30 07:43:31 elmo kernel: [225198.624579] Could not find key with 
description: []

And plenty of other messages, all about the second key with ID 

These are the two keys:
$   keyctl list @u
2 keys in keyring:
270246897: --alswrv  1000  1000 user: 
996876983: --alswrv  1000  1000 user: 

The work-around. Is given below.
Note that I overrode the fnek signature on the command line.

$ ecryptfs-unwrap-passphrase .ecryptfs/wrapped-passphrase
Passphrase: (enter your usual passphrase)

(write down this unwrapped passphrase)

$ sudo ecryptfs-add-passphrase --fnek 
Passphrase: (enter the )
Inserted auth tok with sig [] into the user session keyring
Inserted auth tok with sig [] into the user session keyring
udo mount -t ecryptfs /home/username/.Private/ /home/username/Private/
Select key type to use for newly created files: 
 1) passphrase
 2) tspi
Selection: 1
Passphrase: 
Select cipher: 
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32
 2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]: 1
Select key bytes: 
 1) 16
 2) 32
 3) 24
Selection [16]: 1
Enable plaintext passthrough (y/n) [n]: 
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature []:  
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig= 
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt], it looks 
like you have never mounted with this key before. This could mean that you have 
typed your passphrase wrong.
Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [] to 
[/root/.ecryptfs/sig-cache.txt] 
in order to avoid this warning in the future (yes/no)? : no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (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 ecryptfs-utils depends on:
ii  gettext-base0.19.8.1-2+b1
ii  keyutils1.5.9-9
ii  libassuan0  2.4.3-2
ii  libc6   2.24-12
ii  libecryptfs1111-4
ii  libgpg-error0   1.27-3
ii  libgpgme11  1.8.0-3+b3
ii  libkeyutils11.5.9-9
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6
ii  libtspi10.3.14+fixed1-1

ecryptfs-utils recommends no packages.

Versions of packages ecryptfs-utils suggests:
pn  cryptsetup  

-- no debconf information

Bug#859177: meson is unuseable for package cross compilation

[Helmut Grohne]

On Sun, Jul 30, 2017 at 02:07:50AM +0200, Michael Biebl wrote:
> You mean as part of the Debian package build process? How would it make
> a difference if debhelper calls an external binary or generate the file
> directly? Can you please elaborate

When debcrossgen.py is shipped in a "known" location (e.g. $PATH), I
can simply run it myself, modify its output, and pass "--cross-file
myfile" to dh_auto_configure. The later --cross-file takes precedence as
far as I understand.

Helmut

Bug#870125:

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-moses"

 * Package name: lua-moses
   Version : 1.6.1+git20170613-1
   Upstream Author : Yonaba
 * URL :http://yonaba.github.io/Moses/
 * License : MIT
   Section : interpreters

  It builds those binary packages:

lua-moses  - Utility library for functional programming in Lua

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

  https://mentors.debian.net/package/lua-moses


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-moses/lua-moses_1.6.1+git20170613-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#unstable/lua-moses/1.6.1+git20170613-1/buildlog

Note, this new packages FIXES an RC bug of another pacakge,
because that package added this package as a new dependency.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870029

  Changes since the last upload:

lua-moses (1.6.1+git20170613-1) unstable; urgency=medium

  * Initial release. (Closes: #870124)

Bug#766804: gnome-orca: Fixed

[Jean-Philippe MENGUAL]

Package: gnome-orca
Followup-For: Bug #766804

Dear Maintainer,

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

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

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


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

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

Versions of packages gnome-orca depends on:
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-gtk-3.0 3.22.16-1
ii  gir1.2-pango-1.0   1.40.6-1
ii  gir1.2-wnck-3.03.24.0-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  python33.5.3-3
ii  python3-brlapi 5.4-7+b1
ii  python3-cairo  1.10.0+dfsg-5+b3
ii  python3-gi 3.22.0-2+b1
ii  python3-louis  3.0.0-3
ii  python3-pyatspi2.20.3+dfsg-1
ii  python3-speechd0.8.6-4+hypra1
ii  speech-dispatcher  0.8.6-4+hypra1

Versions of packages gnome-orca recommends:
ii  libgail-common  2.24.31-2
ii  xbrlapi 5.4-7+b1

gnome-orca suggests no packages.

-- no debconf information

Bug#757636: gnome-orca: Additional info

[Jean-Philippe MENGUAL]

Package: gnome-orca
Version: 3.24.0-1
Followup-For: Bug #757636

Dear Maintainer,

Actually seems to be related to flat review in general? Done 

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

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

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


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

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

Versions of packages gnome-orca depends on:
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-gtk-3.0 3.22.16-1
ii  gir1.2-pango-1.0   1.40.6-1
ii  gir1.2-wnck-3.03.24.0-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  python33.5.3-3
ii  python3-brlapi 5.4-7+b1
ii  python3-cairo  1.10.0+dfsg-5+b3
ii  python3-gi 3.22.0-2+b1
ii  python3-louis  3.0.0-3
ii  python3-pyatspi2.20.3+dfsg-1
ii  python3-speechd0.8.6-4+hypra1
ii  speech-dispatcher  0.8.6-4+hypra1

Versions of packages gnome-orca recommends:
ii  libgail-common  2.24.31-2
ii  xbrlapi 5.4-7+b1

gnome-orca suggests no packages.

-- no debconf information

Bug#683230: gnome-orca: Efficient solution

[Jean-Philippe MENGUAL]

Package: gnome-orca
Followup-For: Bug #683230

Dear Maintainer,

Just load xbrlapi and it fixes the problem

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

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

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


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

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

Versions of packages gnome-orca depends on:
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-gtk-3.0 3.22.16-1
ii  gir1.2-pango-1.0   1.40.6-1
ii  gir1.2-wnck-3.03.24.0-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  python33.5.3-3
ii  python3-brlapi 5.4-7+b1
ii  python3-cairo  1.10.0+dfsg-5+b3
ii  python3-gi 3.22.0-2+b1
ii  python3-louis  3.0.0-3
ii  python3-pyatspi2.20.3+dfsg-1
ii  python3-speechd0.8.6-4+hypra1
ii  speech-dispatcher  0.8.6-4+hypra1

Versions of packages gnome-orca recommends:
ii  libgail-common  2.24.31-2
ii  xbrlapi 5.4-7+b1

gnome-orca suggests no packages.

-- no debconf information

Bug#816869: thunderbird: Solution

[Jean-Philippe MENGUAL]

Package: thunderbird
Followup-For: Bug #816869

Dear Maintainer,

I close as the solution is installing selectinbox plugin. So bug is fixed by 
this plugin and the feature won't be shipped in Thunderbird

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

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

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


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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.12.3-0.2
ii  libatk1.0-0   2.24.0-1
ii  libc6 2.24-12
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libdbus-1-3   1.10.20-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.1.0-10
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.52.3-1
ii  libgtk-3-03.22.16-1
ii  libhunspell-1.6-0 1.6.1-2
ii  libpango-1.0-01.40.6-1
ii  libpangocairo-1.0-0   1.40.6-1
ii  libpangoft2-1.0-0 1.40.6-1
ii  libpixman-1-0 0.34.0-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++67.1.0-10
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 20070829-7
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.1-1
ii  lightning1:52.2.1-4

Versions of packages thunderbird suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15.1-2

-- no debconf information

Bug#792749: gnome-orca: Fixed

[Samuel Thibault]

Hello,

Please rather use the bts command to actually close the bug, for
instance:

bts close 792749 3.24.0-1

Thanks,
Samuel

Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Osamu Aoki]

Hi,

(I switched my ISP.  No more osamua...@e01.itscom.net  Thanks for the
reminder)

On Sat, Jul 29, 2017 at 06:44:43PM +0200, Michael Stapelberg wrote:
> Hi Osamu,
> 
> Sorry for the late reply, and thanks for looking into this! Replies
> inline:

It's good time to make feature enhancements now.
 
> Osamu Aoki  writes:
> > How should we explicitly specify such variables, I guess it should be
> > through "opts=..." such as:
> >
> >  opts="mode=git, pretty=0.0~git%cd.%h, date=%Y%m%d%H%M"
> 
> Sounds good.

I had to read the whole thread to recall what I was thinking ... OK ;-)

> > But this "git log" needs to have local clone of git repository.
> >
> > I wonder if I can do without cloning first.
> 
> After reading the git protocol and searching on the web for a little
> bit, my conclusion is that no, you cannot use “git log” without having a
> clone of the repository.
> 
> Given that we are talking about repositories which do not use tags, we
> could specify --depth=1 when cloning to get a shallow clone, i.e. only
> the latest commit. That saves bandwidth and disk space, but has the
> downside that we cannot do any additional validation, i.e. we can’t
> detect if upstream ever starts using tags — unfortunately, that is a
> plausible scenario, so I would suggest doing a full clone.

OK with FULL clone.  (I need to rethink details though... I totally lost
my memory on this topic)

The thing to consider is what git local repository looks like and how
you clone such remote tree. "upstream" branch used by git-buildpackage
is not really the upstream git repository but its series of commits from
the released upstream tarballs.  Maybe clone it into "upstream-git"
branch...

> For GitHub, we can apply an optimization: the GitHub HTTP API exposes
> repository details, such as:
> 
> 1. The default_branch of the repo, in
>https://developer.github.com/v3/repos/#get
> 
> 2. The latest commit of the branch, in
>https://developer.github.com/v3/repos/branches/#get-branch
> 
> For interactive use by individual developers, we could send these HTTP
> requests unauthenticated. For a setup which does many uscan calls, we’d
> need to create a GitHub account to get the higher rate limit. See
> https://godoc.org/github.com/google/go-github/github#hdr-Rate_Limiting
> for details.

(This optimization is a bit more work than I can do immediately.)

> > Adding support to the number of commits is complicated.  Let's be happy
> > to use hash to be unique commit.  I do not think we upload more than 2
> > Debian upstream tarball in a minute.
> 
> In a day, not in a minute. But regardless, you are probably right. I
> asked in the pkg-go IRC channel to see whether people are okay with
> removing that part from the version number, so barring any objections,
> we can probably get that done within the next few days.

Why in a day?

%cd is committer date and this format respects --date= option.
--date option I suggested was %Y%m%d%H%M" which specified down to minutes;-)
If you insist, I can add seconds ;-)

> > As for "git describe" like nearest tag feature, it's a interesting
> > thought but it may make things more complicate.  So unless someone
> > strongly request with patch, I would like to skip it.
> 
> Agreed — if we get rid of the number of commits, we shouldn’t need git
> describe, not even in dh-make-golang.
> 
> It seems like you have a good handle on implementing this in uscan. Do
> you need any additional details? Do you prefer an external patch from
> us over implementing this yourself? I’d be happy to give you feedback on
> a proposed patch or git commit.

OK.  I guess this will be a nice project during My Debconf17 travel for
me.

Osamu

Bug#792749: gnome-orca: Fixed

[Jean-Philippe MENGUAL]

Package: gnome-orca
Followup-For: Bug #792749

Bug can be closed
Dear Maintainer,

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

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

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


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

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

Versions of packages gnome-orca depends on:
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-gtk-3.0 3.22.16-1
ii  gir1.2-pango-1.0   1.40.6-1
ii  gir1.2-wnck-3.03.24.0-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  python33.5.3-3
ii  python3-brlapi 5.4-7+b1
ii  python3-cairo  1.10.0+dfsg-5+b3
ii  python3-gi 3.22.0-2+b1
ii  python3-louis  3.0.0-3
ii  python3-pyatspi2.20.3+dfsg-1
ii  python3-speechd0.8.6-4+hypra1
ii  speech-dispatcher  0.8.6-4+hypra1

Versions of packages gnome-orca recommends:
ii  libgail-common  2.24.31-2
ii  xbrlapi 5.4-7+b1

gnome-orca suggests no packages.

-- no debconf information

Bug#757464: ruby-gnome2: Please provide rubygem meta-information

[dai]

Control: reopen -1
Control: notfixed -1 ruby-gnome2/3.1.8-3

not fully fixed in 3.1.8-3, still working.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#870124: ITP: lua-moses/1.6.1 -- Lua utility-belt library for functional programming

[Lumin]

Package:wnpp
Severity: wishlist
Owner: lumin 

* Package name: lua-moses
  Version : 1.6.1
  Upstream Author : Yonaba
* URL : http://yonaba.github.io/Moses/
* License : MIT
  Programming Lang: lua
  Description : Lua utility-belt library for functional programming

Bug#869994: sql-ledger: Can't locate bin/mozilla/login.pl in @INC

[Robert J. Clay]

> I will attempt to let the sql-ledger developer know of the situation
> though I am not a subscriber to their forum.

I also am very interested in that;  please let know (or just reply to
the bug) what you find out about it. I was able to find postings about
similar issues in the forums but not ones specific to installations
attempting to use it with Perl v5.26.



-- 
Robert J. Clay
rjc...@gmail.com

Bug#870123: [pkg-boost-devel] Bug#870123: boost1.62: Make source packge bootstrappable

[Dimitri John Ledkov]

On 29 July 2017 at 23:38, Daniel Schepler  wrote:
> Source: boost1.62
> Version: 1.62.0+dfsg-4
> Severity: wishlist
>
> Currently, src:boost1.62 Build-Depends on mpi-default-dev, which
> creates a build dependency cycle:
>
> mpi-defaults Build-Depends on libopenmpi-dev
> openmpi Build-Depends on libhwloc-dev
> hwloc Build-Depends on libcairo2-dev
> cairo Build-Depends on libglib2.0-dev
> glib2.0 Build-Depends on gtk-doc-tools
> gtk-doc-tools Depends on highlight
> highlight Build-Depends on libboost-dev
> boost-defaults Build-Depends on libboost1.62-dev
>
> It would be nice if the boost1.* source packages could provide a build
> profile to allow for building without boost-mpi - and then, of course,
> the same for src:boost-defaults.  (Actually, in my experience, just
> having the pure header package available tends to be enough for
> bootstrapping purposes - but I also don't see any real reason for
> dropping any of the other binary library packages in a stage1
> bootstrap build.)
>

debian/rules had support for build without mpi, as that was kept
separate in Ubuntu for main vs universe, before we allowed for source
packages in main, to have build-dependencies from universe, as long as
binaries depends are self-contained in main.

So implementing this should be easy enoug: resurrect the non-mpi build
code, tweak it to be build-profile sensitive. There was the whole lot
there - targets to regenerated control without mpi packages, and do
non-mpi build, just-mpi build, or build everything (the current
default).

> It would also be good if doxygen could be moved to
> Build-Depends-Indep, as doxygen Build-Depends on default-jdk, and
> openjdk also requires several glib-based libraries.

I'm not sure if doxygen is still needed, as documentation build has
been broken for a while. However, I'm not sure if one can do a build
without doxygen, needs checking.

-- 
Regards,

Dimitri.

Bug#868544: Debian Bug #868544: RFS (dtksettings) Rejected

[Boyuan Yang]

X-Debbugs-CC: czc...@debian.org felixonm...@archlinux.org

在 2017年7月29日星期六 CST 下午6:08:37，Gianfranco Costamagna 写道：
> Seems to have been rejected
> 
> G.

Ack. The package is rejected since pkg-deepin does not exist (yet) on Alioth.

Here is the plan:

* Poke Alioth admins on IRC #alioth and DebConf (with the help of debconf 
attendees) and see when will pkg-deepin be set up.

* Before that, temporarily set packages as self-maintained.

Regards,
Boyuan Yang

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

Bug#861378: lists.debian.org: Please update list description for debian-chinese-{gb,big5}

[Boyuan Yang]

reopen 861378 =
thanks

在 2017年7月29日星期六 CST 下午4:11:08，Hanno 'Rince' Wagner 写道：
> Hi Boyuan!
> 
> On Sat, 29 Jul 2017, Boyuan Yang wrote:
> > The need of updating list descriptions is still valid. Please try to fix
> > them when possible. See Bug #861378 for details.
> 
> I just changed the descriptions on the webpages. If you want further
> changes, please don't hesitate to ask :-)

I'm sorry, but you seem to have text of two lists mixed up.

For example, https://lists.debian.org/debian-chinese-gb/ is only for Simplified 
Chinese and debian-chinese-big5 is only for Traditional Chinese.

I'm providing the correct description words here again for you reference:

debian-chinese-gb


debian-user in Chinese [Simplified Chinese]

Debian Chinese Project; Chinese localization (l10n) issues, documentation
and website translation, user support, Chinese-specific development, etc.

Posts may be in English or Chinese. The simplified variant of Chinese
(Simplified Chinese, like zh_CN or zh_SG) is preferred.

Languages used on this list: Chinese, English.

Posting address: debian-chinese...@lists.debian.org

debian-chinese-big5
=

debian-user in Chinese [Traditional Chinese]

Debian Chinese Project; Chinese localization (l10n) issues, documentation
and website translation, user support, Chinese-specific development, etc.

Posts may be in English or Chinese. The traditional variant of Chinese
(Traditional Chinese, like zh_TW or zh_HK) is preferred.

Languages used on this list: Chinese, English.

Posting address: debian-chinese-b...@lists.debian.org

---



Regards,
Boyuan Yang

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

Bug#858373: help needed to complete regression fix for apache2 Bug#858373

[Brian Kroth]

Hi, sorry for the delay. Gmail filed this one into spam :-(

Unfortunately, I don't have access to that environment anymore to confirm.
I'll pass this on to the folks that do so hopefully they can.

My recollection from this issue was that I'd tested it against different
package versions and the 400 ErrorDocuments had worked beforehand (we used
them for ModSec types of things primarily, and I'm confident that mode was
working well before hand and after), though possibly not in that particular
protocol error context. I vaguely recall having issues reproducing a
working ErrorDocument with non-cgi methods in that protocol error mode
style test as well, but I don't recall if rhat was only in the newer
versions of the software that I had been testing with or true before that
update as well.

Anyways, thanks much for following up. Sorry I don't have more info to
offer at the moment.

Cheers,
Brian

On Fri, Jul 21, 2017, 08:44 Antoine Beaupré  wrote:

> TL;DR: New proposed package (deb7u11) doesn't ctually show a new
> regression, please test:
>
>
> https://people.debian.org/~anarcat/debian/wheezy-lts/apache2_2.2.22-13+deb7u11_amd64.changes
>
> In particular, Brian Kroth: are you *sure* you had that ErrorDocument
> 400 working in apache2_2.2.22-13+deb7u7 (ie. before the DLA-841-1
> upload)? In my tests, it didn't actually work at all. It wouldn't
> trigger a segfault, but the CGI script wouldn't get called either. In
> the above package, we don't segfault anymore, but we yield a 400 + 500
> error message (because the ErrorDocument fails). The solution, here, is
> obviously to update to a later Apache version (e.g. update to jessie,
> really) to get that functionality working, from my perspective.
>
> More technical details follow.
>
> On 2017-07-21 09:24:00, Stefan Fritsch wrote:
> > Hi Antoine,
> >
> > On Wednesday, 19 July 2017 15:45:20 CEST Antoine Beaupre wrote:
> >> As I mentioned in the #858373 bug report, I started looking at fixing
> >> the regression introduced by the 2.2.22-13+deb7u8 upload, part of
> >> DLA-841-1. The problem occurs when a CGI(d) ErrorDocument is configured
> >> to handle 400 error messages that can be triggered with a simple "GET /
> >> HTTP/1.0\n\n". Such a request segfaults Apache in Wheezy right now.
> >
> >> Unfortunately, re-introducing the protocol initialization code isn't
> >> sufficient: it does fix the segfaults, but the ErrorDocument handling is
> >> not quite working yet. Instead of seeing the output of the
> >> ErrorDocument, after 10 seconds, I get the raw 400 message, doubled with
> >> a 500 error document warning:
> >
> >> Note that I have also tried to see if sending "\r\n" instead of just
> >> "\n" in my "hello world" example would work around the issue: it
> >> doesn't, unfortunately.
> >>
> >> I am at a loss as where to go from here, to be honest. The patch
> >> (attached) at least fixes the segfault, which resolves the primary issue
> >> at hand here (DoS by crashing processes!) but it would be nice to
> >> actually fix the ErrorDocument as well..
> >
> > This sounds familiar. Maybe it's simply broken in 2.2.22. Can you
> compare with
> > 2.2.22-13+deb7u7 if that bug has been there already?
>
> Well, the problem is - how do I reproduce this? I can't generate the
> same 400 error message in deb7u7 (I tried!) with the previous techniques
> because the new request handling code isn't there. That is, the
> following query just works:
>
> # printf "GET / HTTP/1.0\n\n" | nc localhost 80 | head -1
> HTTP/1.1 200 OK
>
>
> Furthermore, generating a 400 error, when it works in deb7u7, doesn't
> trigger the ErrorDocument - not sure why:
>
> # printf "G ET / HTTP/1.0\r\n\r\n" | nc localhost 80
> HTTP/1.1 400 Bad Request
> Date: Fri, 21 Jul 2017 13:40:48 GMT
> Server: Apache/2.2.22 (Debian)
> Vary: Accept-Encoding
> Content-Length: 302
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> 
> 
> 400 Bad Request
> 
> Bad Request
> Your browser sent a request that this server could not understand.
> 
> 
> Apache/2.2.22 (Debian) Server at wheezy.raw Port 80
> 
>
> Logs show the following:
>
> [Fri Jul 21 13:40:48 2017] [error] [client 127.0.0.1] Invalid URI in
> request G ET / HTTP/1.0
>
> ... whether or not the 400 ErrorDocument directive is present. Notice
> how the ErrorDocument isn't triggered at all here.
>
> Of course, a 404 ErrorDocument still works correctly:
>
> # printf "GET /wtf HTTP/1.0\r\n\r\n" | nc localhost 80
> HTTP/1.1 404 Not Found
> Date: Fri, 21 Jul 2017 13:23:46 GMT
> Server: Apache/2.2.22 (Debian)
> Vary: Accept-Encoding
> Connection: close
> Content-Type: text/plain
>
> Hello, World.
>
> I get this behavior consistently with deb7u7 and the proposed deb7u11
> (which only adds a 500 error document to *certain* 400 errors,
> basically). I find that is an acceptable compromise to fix a segfault,
> and, from my perspective, doesn't introduce a regression.
>
> > In 2.2.30, there is this fix, which is obviously missing from 

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Keith Packard]

Tollef Fog Heen  writes:

> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote R > F

-- 
-keith


signature.asc
Description: PGP signature

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Philip Hands]

Tollef Fog Heen  writes:

> I call for votes on the following resolution with regards to #862051.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
>
> === Resolution ===
>
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
>
> The Committee therefore resolves that:
>
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
>
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node.  The migration should
> be managed according to Debian's usual backwards-compatibility
> arrangements.
>
> === End Resolution ===
>
> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote:   R > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#855868: [pkg-gnupg-maint] Bug#855868: GPG_AGENT_INFO and SSH_AUTH_SOCK not set in wayland sessions

[rufo]

Hi folks,

Perhaps the solution might involve using systemd's
environment-generators [1].  This seems to be the new preferred way to
set environmental variables like SSH_AUTH_SOCK and the replacement for
putting scripts in /etc/X11/Xsession.d/.

For example the gnupg-agent package could create the file
/usr/lib/systemd/user-environment-generators/90gpg-agent containing
something like this:


#!/bin/bash

if [ -n "$(gpgconf --list-options gpg-agent | \
  awk -F: '/^enable-ssh-support:/{ print $10 }')" ]; then
echo SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
fi


This is what I'm using at the moment and it seems to work well.  What do
you think?

  --rufo

[1]
https://www.freedesktop.org/software/systemd/man/systemd.environment-generator.html

Bug#859177: meson is unuseable for package cross compilation

[Michael Biebl]

Am 29.07.2017 um 23:29 schrieb Helmut Grohne:
> On Sat, Jul 29, 2017 at 09:12:56AM +0200, Michael Biebl wrote:

>> dependency on Python. But the  debcrossgen.py code looks straightforward
>> enough to be ported to perl.
> 
> If it ends up being shipped in debhelper, I have a few questions. What
> should I do if the cross file mostly is correct, but I need to tweak one
> line (i.e. how to override it)?

You mean as part of the Debian package build process? How would it make
a difference if debhelper calls an external binary or generate the file
directly? Can you please elaborate




-- 
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#758238: help wanted

[Adam Borowski]

On Thu, Jul 27, 2017 at 09:51:38AM +0200, Gürkan Myczko wrote:
> I have a building package here
> 
> http://sid.ethz.ch/debian/cool-retro-term/
> (i386) however there's still some issues, help is welcome
> 
> one for amd64 is here:
> https://people.phys.ethz.ch/~myczko/debian/cool-retro-term/
> 
> there's some arch specific string in debian/cool-retro-term.install
> that needs help, and also after building and installing it, it doesn't run
> properly for me...

I can't seem to reproduce that failure -- it builds fine for me (in sbuild),
and works when installed.

It does look like ass because of not being able to find fonts in the correct
places, but error messages when you start it from a terminal are pretty
obvious.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄ • use glitches to walk on water

Bug#841951: [PATCH]: bitcoin-qt segfaults on startup

[Erik de Castro Lopo]

Lisandro Damián Nicanor Pérez Meyer wrote:

> As you can see in
> 
>   
> 
> the patch is not exactly right.

I've have be running with that patch in its current form since the start
of the year. Afaiac its works as intended.

> That needs to be fixed before we add that patch, be it locally or in upstream 
> (although upstream is much better).

So who is it that does that? 

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

Bug#752938: More details on swig Build-Depends cycles

[Daniel Schepler]

On my current iteration of trying to bootstrap Debian, I ran into this
package yet again.  One example cycle:

swig Build-Depends on tk-dev
tk-dev Depends on tk8.6-dev
tk8.6 Build-Depends on libxt-dev
libxt Build-Depends on libglib2.0-dev
glib2.0 Build-Depends on gtk-doc-tools
gtk-doc-tools Depends on highlight
highlight Build-Depends on swig

Right now src:swig is blocked on default-jdk, ruby, ruby-dev, and
tk-dev.  The ruby Build-Depends are stuck because ruby2.3 also
Build-Depends on tk-dev; and similarly openjdk-8 requires gtk2 and
several other glib-based libraries.

If for whatever reason you don't want to drop these Build-Depends
entirely, you could still drop them in a "stage1" or "nocheck" build
profile.
-- 
Daniel Schepler

Bug#870123: boost1.62: Make source packge bootstrappable

[Daniel Schepler]

Source: boost1.62
Version: 1.62.0+dfsg-4
Severity: wishlist

Currently, src:boost1.62 Build-Depends on mpi-default-dev, which
creates a build dependency cycle:

mpi-defaults Build-Depends on libopenmpi-dev
openmpi Build-Depends on libhwloc-dev
hwloc Build-Depends on libcairo2-dev
cairo Build-Depends on libglib2.0-dev
glib2.0 Build-Depends on gtk-doc-tools
gtk-doc-tools Depends on highlight
highlight Build-Depends on libboost-dev
boost-defaults Build-Depends on libboost1.62-dev

It would be nice if the boost1.* source packages could provide a build
profile to allow for building without boost-mpi - and then, of course,
the same for src:boost-defaults.  (Actually, in my experience, just
having the pure header package available tends to be enough for
bootstrapping purposes - but I also don't see any real reason for
dropping any of the other binary library packages in a stage1
bootstrap build.)

It would also be good if doxygen could be moved to
Build-Depends-Indep, as doxygen Build-Depends on default-jdk, and
openjdk also requires several glib-based libraries.
-- 
Daniel Schepler

Bug#870122: qjoypad: time to migrate to a live work?

[Adam Borowski]

Package: qjoypad
Version: 4.1.0-2.1
Severity: wishlist

Hi!
Current qjoypad's upstream has been dead since February 2010.

There are multiple forks, but the only one with significant new work is
https://github.com/panzi/qjoypad

It includes QT5 migration, and a bunch of fixes.




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

Kernel: Linux 4.13.0-rc2-debug-00025-g7c422cf6b36d (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qjoypad depends on:
ii  libc6   2.24-12
ii  libgcc1 1:7.1.0-10
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libstdc++6  7.1.0-10
ii  libx11-62:1.6.4-3
ii  libxtst62:1.2.3-1

qjoypad recommends no packages.

qjoypad suggests no packages.

-- no debconf information

Bug#767798: bind9: ignores OPTIONS from /etc/default/bind9 w/ systemd

[Anders Nordby]

When does this get backported to Debian Jessie, the latest release? This
is after all a bug in my opinion. This worked before, and it prevents
Bind9 from starting up on one of my servers. I had to make Puppet
auto-update the file to get rid of the problem with Bind9 not running
after an upgrade of the package. :-(

Bye,

-- 
Anders.

Bug#869180: src:hydrogen-drumkits: source contains unlicensed material (bogusly treated as GPL-2)

[Jonas Smedegaard]

Quoting umlae...@debian.org (2017-07-29 17:20:53)
> Zitat von Jonas Smedegaard :
> >> >
> >> > These drumkits are in upstream metadata listed _without_ license:
> >> >
> >> > ColomboAcousticDrumkit (sf)
> >> > EasternHop (sf)
> >> > Electric Empire (sf)
> >> > HardElectro (sf)
> >> > HipHop-1 (sf)
> >> > HipHop-2 (sf)
> >> > Millo's MultiLayered 2 (sf)
> >> > Synthie-1 (sf)
> >> > VariBreaks (sf)
> >> >
> >> > In Debian copyright file those are listed as licensed GPL-2.
> >>
> >> The fact that the metadata doesn't contain a license, does not imply
> >> that these files are not GPL-2. Have you actually checked the license
> >> of any of these?
> >
> > The issue here is that information about licensing is unavailable in the
> > source package.  Title now rephrased to not avoid assumption.
> >
> > If licensing is based on external information and/or guesswork, then
> > that should be documented in debian/copyright.
> 
> hmm.
> 
> the "orig.tar.gz" contains this information, since it includes  
> "drumkits.json" which includes the licenses for each drumkit as  
> specified by (their) upstream(s) (which is mostly a casual short name,  
> rather than the full license text; however, this doesn't make the  
> licenses any less valid).
> 
> since "drumkits.json" is generated by a script in debian/ this might  
> require some additional information, so:
> 
> the licenses are obtained from the same source as the information on  
> how to obtain the drumkits:
> "their drumkit feed" (as it is called in debian/README.source).
> with "them" being upstream (hydrogen), and their "drumkit feed" being  
> http://www.hydrogen-music.org/feeds/drumkit_list.php
> it is my understanding that this feed is generated from information  
> that has been directly entered by the upstreams' of the various  
> drumkits. i have no reason to distrust this source of information.
> 
> therefore, for me the license information *has* been added by  
> upstream, albeit on a separate channel, and i don't see any problem  
> with the licenses as stated in d/copyright)
> 
> i agree, this should probably be added to the d/README.source

A week ago I updated debian/copyright in git to elaborate on origin of 
copyright and licensing as best as I could - which took XML feed into 
account.  In that process, I relicensed some of the drumkits as I found 
no evidence of the stated licensing but evidence of another.

I have failed to identify a source of copyright + licensing for the 
following, however: EasternHop-1 HipHop-1 HipHop-2 Synthie-1.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#870121: mate-power-manager: sometimes hits not-reached assertion on startup

[brian m. carlson]

Package: mate-power-manager
Version: 1.16.2-1
Severity: important

mate-power-manager is not starting when I log in anymore.  It logs the
following to ~/.xsession-errors.

  **
  ERROR:gpm-kbd-backlight.c:342:gpm_kbd_backlight_on_dbus_signal: code should 
not be reached

Running it by hand the first time produced the same result.  Running a
second time caused it to start.

I believe this issue is preventing my screen from locking when I suspend
my laptop.  I've seen that issue on two separare Thinkpad X1 Carbon
laptops, both at home and at work.  On the work laptop, the machine does
not suspend at all.

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

Kernel: Linux 4.11.0-2-amd64 (SMP w/4 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 mate-power-manager depends on:
ii  dbus-user-session [default-dbus-session-bus]1.11.16+really1.10.22-1
ii  dbus-x11 [dbus-session-bus] 1.11.16+really1.10.22-1
ii  libatk1.0-0 2.24.0-1
ii  libc6   2.24-12
ii  libcairo-gobject2   1.14.10-1
ii  libcairo2   1.14.10-1
ii  libcanberra-gtk3-0  0.30-3
ii  libcanberra00.30-3
ii  libdbus-1-3 1.11.16+really1.10.22-1
ii  libdbus-glib-1-20.108-2
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.52.3-1
ii  libgnome-keyring0   3.12.0-1+b2
ii  libgtk-3-0  3.22.17-1
ii  libmate-panel-applet-4-11.16.2-1
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.6-1
ii  libpangocairo-1.0-0 1.40.6-1
ii  libupower-glib3 0.99.5-2
ii  libx11-62:1.6.4-3
ii  libxext62:1.3.3-1+b2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  mate-notification-daemon [notification-daemon]  1.16.1-1
ii  mate-power-manager-common   1.16.2-1
ii  notification-daemon 3.20.0-1+b1
ii  policykit-1 0.105-18
ii  systemd 234-2
ii  upower  0.99.5-2

mate-power-manager recommends no packages.

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.16.0-2

-- no debconf information

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#870120: CVE-2017-11539

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/582


Memory information leakage due to non initialization

Bug#870119: bad free in RelinquishMagickMemory

[Bastien ROUCARIES]

source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/621

DOS

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Ivan Sergio Borgonovo]

Sorry for the delay.

On 07/17/2017 04:39 AM, Michel Dänzer wrote:

aptitude reinstall glx-alternative-mesa
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/mesa-diverted because link group glx is broken


You don't need this package.


Thanks.


Does installing the libegl1-mesa package help?


No, still have to add

Option   "AccelMethod"   "EXA"

Let me know if you need more info to diagnose the problem.

Thanks

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

Bug#870118: memory leak in ReadOneJNGImage #618

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/618

Bug#870117: memory leak in ReadOneMNGImage #619

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/619

A memory leak vulnerability was found in function ReadOneMNGImage
,which allow attackers to cause a denial of service (memory leak) via
a crafted file.

Bug#870116: memory leak in ReadOneJNGImage #60

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/600

Bug#870115: memory leak in ReadOneJNGImage #602

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/602

The ReadOneJNGImage function in png.c:4525 allows attackers to cause a
denial of service (memory leak) via a crafted file.

Bug#865531: lintian: description of testsuite-autopkgtest-missing is unhelpful/incorrect

[Chris Lamb]

tags 865531 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=ce7942a08681a6e67a1a8449effa61fe612e3769

I've also added a `unnecessary-testsuite-header` in

 
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=7c1a32e91b5f9ad674a6f3f66a6a374028942556


Regards,

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

Bug#859177: meson is unuseable for package cross compilation

[Helmut Grohne]

On Sat, Jul 29, 2017 at 09:12:56AM +0200, Michael Biebl wrote:
> Am 28.07.2017 um 22:06 schrieb Helmut Grohne:
>
> >  2. The debcrossgen.py script needs some place to live. When debhelper
> > and meson are installed together, it needs to be in the filesystem.
> > An easy approach to do so is to put it into the meson binary
> > package. We should probably spend a little discussing bike shedding
> > questions such as:
> >  a. What path/filename to use?
> >  b. What options/arguments should it take?
> >  3. debhelper needs to call debcrossgen.py during cross compilation and
> > add the --cross-file option. This one is straight forward to
> > implement once the questions from 2. are answered.
>
> My gut feeling is, that this functionality should be shipped in
> debhelper directly, specifically in the meson build system class [1].
> debhelper is written in perl, and I don't think we want to add a
> dependency on Python. But the  debcrossgen.py code looks straightforward
> enough to be ported to perl.

If it ends up being shipped in debhelper, I have a few questions. What
should I do if the cross file mostly is correct, but I need to tweak one
line (i.e. how to override it)? What should I do if I want to cross
build for a Debian-based system, but don't want to build a Debian
package, just a binary? (Do I have to write the cross file manually?)

> That said, if Jussi thinks that this script might be useful for other
> distros / use cases, then shipping it upstream in the meson package
> might be an option as well.

Indeed, the tool could be extended to be useful for other distros. There
is a de facto standard for describing architectures used across a number
of distributions and that is the GNU triplet (i.e. DEB_HOST_GNU_TYPE).
If the tool were deriving all of the values from the GNU triplet rather
than checking all dpkg-architecture variables, it could become useful
for others. At the same time, it would essentially duplicate autotools'
config.guess. Choose either simple or generic, but not both.

On Sat, Jul 29, 2017 at 09:19:22AM +0200, Michael Biebl wrote:
> While generating a (temporary) cross.txt file is not a huge deal, being
> able to directly pass the necessary options to meson via command line
> options would be a tad nicer.

That's what we do for CMake indeed, but it is not without problems
there. Some build systems behave differently when a CMAKE_TOOLCHAIN_FILE
is given and assume a non-cross build when there is none. That pitfall
should be avoided.

Helmut

Bug#870114: RFP: gendev -- Sega Genesis development environment for Linux

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: gendev
  Version : 0.3.0
  Upstream Author : Matt Kubilus
* URL : https://github.com/kubilus1/gendev
  Programming Lang: C
  Description : Sega Genesis development environment for Linux

Gendev provides an easy way to setup a development environment to develop Sega
Genesis/Megadrive games.

Bug#866525: capnproto: New upstream release 0.6.1

[Tom Lee]

Thanks for the heads-up Jaromir, 0.6.1-1 is in the NEW queue and should
land in sid sometime over the next few days/weeks.

Bug#869180: src:hydrogen-drumkits: source contains unlicensed material (bogusly treated as GPL-2)

[umlaeute]

Zitat von Jonas Smedegaard :

>
> These drumkits are in upstream metadata listed _without_ license:
>
> ColomboAcousticDrumkit (sf)
> EasternHop (sf)
> Electric Empire (sf)
> HardElectro (sf)
> HipHop-1 (sf)
> HipHop-2 (sf)
> Millo's MultiLayered 2 (sf)
> Synthie-1 (sf)
> VariBreaks (sf)
>
> In Debian copyright file those are listed as licensed GPL-2.

The fact that the metadata doesn't contain a license, does not imply
that these files are not GPL-2. Have you actually checked the license
of any of these?


The issue here is that information about licensing is unavailable in the
source package.  Title now rephrased to not avoid assumption.

If licensing is based on external information and/or guesswork, then
that should be documented in debian/copyright.


hmm.

the "orig.tar.gz" contains this information, since it includes  
"drumkits.json" which includes the licenses for each drumkit as  
specified by (their) upstream(s) (which is mostly a casual short name,  
rather than the full license text; however, this doesn't make the  
licenses any less valid).


since "drumkits.json" is generated by a script in debian/ this might  
require some additional information, so:


the licenses are obtained from the same source as the information on  
how to obtain the drumkits:

"their drumkit feed" (as it is called in debian/README.source).
with "them" being upstream (hydrogen), and their "drumkit feed" being  
http://www.hydrogen-music.org/feeds/drumkit_list.php
it is my understanding that this feed is generated from information  
that has been directly entered by the upstreams' of the various  
drumkits. i have no reason to distrust this source of information.


therefore, for me the license information *has* been added by  
upstream, albeit on a separate channel, and i don't see any problem  
with the licenses as stated in d/copyright)


i agree, this should probably be added to the d/README.source

Bug#870113: libxcb: Make source package bootstrappable

[Daniel Schepler]

Source: libxcb
Version: 1.12-1
Severity: wishlist

Currently, libxcb's Build-Depends on check introduces build dependency
cycles.  For example:

check Build-Depends on libsubunit-dev
subunit Build-Depends on openstack-pkg-tools
openstack-pkg-tools Depends on pristine-tar
pristine-tar Build-Depends on git
git Build-Depends on subversion
subversion Build-Depends on kdelibs5-dev
And kde4libs, of course, requires X.

As far as I can tell, if I disable the testsuite, then the package
builds fine without check installed.  So, this cycle could be broken
by updating the Build-Depends of src:libxcb to something like:

Build-Depends: libxau-dev (>= 1:1.0.5-2), libxdmcp-dev (>= 1:1.0.3-2),
xcb-proto (>= 1.12), xcb-proto (<< 2.0), libpthread-stubs0-dev (>=
0.1), debhelper (>= 9), pkg-config, xutils-dev, xsltproc (>= 1.1.19),
check (>= 0.9.4-2) , python-xcbgen (>= 1.12), libtool,
automake, python, dctrl-tools
-- 
Daniel Schepler

Bug#869255: [Letsencrypt-devel] Bug#869255: DNS: wait a bit longer when NXDOMAIN returned in response to challenges

[zebian]

Zitat von Paul Wise :


Source: dehydrated
Version: 0.3.1-3
Severity: wishlist
X-Debbugs-Cc: debian-ad...@lists.debian.org
User: debian-ad...@lists.debian.org
Usertags: needed-by-DSA-Team

DSA are using dehydrated and the DNS mode of it, via a cron job run
under chronic. Occasionally we get mails containing failures like the
one below. I suspect this is because the DNS update for the challenge
hasn't synced to Debian's DNS providers by the time the LE servers do
the request. It would be nice if the NXDOMAIN could trigger a retry
after a certain amount of time, maybe 5 minutes. This would avoid us
getting non-actionable mails for slight delays in DNS synchronisation.



ouch, are you suggesting to fix a race condition by adding longer timeouts?

anyhow, i've a hook-script for dehydrated in the NEW queue since about  
1.5 months [1] that seems to fix this issue, by polling all DNS  
servers that are authoritative for the given NS entry *until* the  
relevant records show up.


gmsdr
IOhannes

[1] https://ftp-master.debian.org/new/dehydrated-hook-ddns-tsig_0.1.1-1.html

Bug#870112: gitlab-ci-multi-runner: please backport to stretch

[Dominik George]

Source: gitlab-ci-multi-runner
Version: 1.11.4+dfsg-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

it would be much appreciated if we could get gitlab-ci-multi-runner in
stretch-backports.

Kind regards,
Nik

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

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

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAll89XIxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pYFeA/+PoEt8fc+iZMIPPpTfu1H1sLuE4eu
pa0WrtDPXGMh9/dLXn4aYUdbD3BpTBLmVO5P8KUk5lpVJr6MwQmkfBOaj7RUPQAL
gS3x7FsKHq4qrmkrntXkT5s9LQ07EzAPXYNeOI9mWwoQTob/SrIjiWEgR1ZZs1jq
Z0Xknkl8k5dB7VJnPYgQESIhu0ocTyFOr+khdlZffhkMcQ2nboBo0q+/gMYEZ1VD
4KlEGD4DO0Gd4jc9Kew2ybjkiscgLDh9/EauaJ3XeVrGfvkDnakOEmcYkfhqY3TA
Z7hQdYt8w3fwIi9nups5s6QglT4Ot1aJMXcQQD1wQ1oeT4lBG8WHkF3po73IkBBV
86lGteQ7c3H1K4FFnLtxMKBL7y11eWLHmq3Qq/sd4eh50WGU8arSHOhvmJeJX3NL
ZfHi/3bFJcEIG5ge1jMJ/gLdiFoJ8UHvhuGJv/lT1rR0OJZm1NxFVw/vbjUtGTXh
/1kheQ3v8z17BJToz7g67sxAmwvknn1nYt3cyo9gZf4GsSmMWtOz4tDN15VqYaih
zfD9elidaUjdyyZMCxxL0LSsa0Mvzni835c3OUYNA6cf8aFlEQ/119qvluHcwOr4
3JL9oWzX9RDEkrjWrLY6Y9dMaEocw4MA5RFecihcblrePyewfNsHcA0ngc0CaJM1
cFw3tLBPPqOC+io=
=brTJ
-END PGP SIGNATURE-

Bug#870111: Stuck in LockSemaphoreInfo after reading a png with width==MAGICK_WIDTH_LIMIT #596

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded: https://github.com/ImageMagick/ImageMagick/issues/596

It appears to still be an issue with
https://www.imagemagick.org/download/beta/ImageMagick-6.9.9-1~beta20170721.tar.xz.

If you try to read an image whose width exactly matches
MAGICK_WIDTH_LIMIT, ImageMagick returns a "width or height exceeds
limit" error, as expected. However, the next time you try to read a
png, it gets permanently stuck in LockSemaphoreInfo - I'm assuming
that the first time failed to unlock it.

I'm able to reproduce it with this code:

#include 
#include 
#include "magick/MagickCore.h"
#include "magick/magick-config.h"

void PrintImage(char* filename) {
ImageInfo* info = CloneImageInfo((ImageInfo *) NULL);
strcpy(info->filename, filename);
SetImageInfoFile(info, NULL);

ExceptionInfo *exception = AcquireExceptionInfo();
printf("Attempt to read %s\n", filename);
Image* image = ReadImage(info, exception);

printf("%s: %s %s\n", info->filename, exception->reason,
exception->description);
if (image) {
printf("%ix%i\n", image->columns, image->rows);
DestroyImage(image);
}
DestroyExceptionInfo(exception);
DestroyImageInfo(info);
}

int main(int argc, char *argv[]) {
if (argc < 2) {
printf("specify a filename to read\n");
return 1;
}

MagickCoreGenesis(*argv,MagickTrue);

PrintImage(argv[1]);
PrintImage(argv[1]);

return 0;
}

by passing it the path to a png file, with MAGICK_WIDTH_LIMIT set to
the exact width of that png.

Bug#870109: out-of-bounds read with the MNG CLIP chunk.

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1


commit 22e0310345499ffe906c604428f2a3a668942b05
Author: Glenn Randers-Pehrson 
Date:   Mon Jul 10 08:23:01 2017 -0400

Fix potential out-of-bounds read with the MNG CLIP chunk.

Bug#870110: CVE-2017-11538: Memory-Leak in WriteOnePNGImage() coders/png.c #569

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:   https://github.com/ImageMagick/ImageMagick/issues/569

Bug#870108: memory leak in ReadOneJNGImage #550

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded:https://github.com/ImageMagick/ImageMagick/issues/550


Version: ImageMagick 7.0.6-1 Q16 x86_64

#./magick identify $FILE

=
==32637==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 13488 byte(s) in 1 object(s) allocated from:
#0 0x4def96 in __interceptor_malloc asan_malloc_linux.cc:66
#1 0x7fbe8d60af76 in AcquireMagickMemory memory.c:463:10
#2 0x7fbe8d5b9db9 in AcquireImage image.c:169:19
#3 0x7fbe8dc47483 in ReadOneJNGImage png.c:4483:21
#4 0x7fbe8dc1bb1d in ReadJNGImage png.c:5053:9
#5 0x7fbe8d3faf98 in ReadImage constitute.c:497:13
#6 0x7fbe8d771bd9 in ReadStream stream.c:1045:9
#7 0x7fbe8d3f9b3f in PingImage constitute.c:226:9
#8 0x7fbe8d3fa2e3 in PingImages constitute.c:327:10
#9 0x7fbe8cb5b126 in IdentifyImageCommand identify.c:319:18
#10 0x7fbe8cc18dff in MagickCommandGenesis mogrify.c:183:14
#11 0x514f77 in MagickMain magick.c:151:10
#12 0x5149d1 in main magick.c:263:10
#13 0x7fbe87456f44 in __libc_start_main libc-start.c:287

Direct leak of 13024 byte(s) in 1 object(s) allocated from:
#0 0x4def96 in __interceptor_malloc asan_malloc_linux.cc:66
#1 0x7fbe8d60af76 in AcquireMagickMemory memory.c:463:10
#2 0x7fbe8dc4739f in ReadOneJNGImage png.c:4477:39
#3 0x7fbe8dc1bb1d in ReadJNGImage png.c:5053:9
#4 0x7fbe8d3faf98 in ReadImage constitute.c:497:13
#5 0x7fbe8d771bd9 in ReadStream stream.c:1045:9
#6 0x7fbe8d3f9b3f in PingImage constitute.c:226:9
#7 0x7fbe8d3fa2e3 in PingImages constitute.c:327:10
#8 0x7fbe8cb5b126 in IdentifyImageCommand identify.c:319:18
#9 0x7fbe8cc18dff in MagickCommandGenesis mogrify.c:183:14
#10 0x514f77 in MagickMain magick.c:151:10
#11 0x5149d1 in main magick.c:263:10
#12 0x7fbe87456f44 in __libc_start_main libc-start.c:287

Indirect leak of 13024 byte(s) in 1 object(s) allocated from:
#0 0x4def96 in __interceptor_malloc asan_malloc_linux.cc:66
#1 0x7fbe8d60af76 in AcquireMagickMemory memory.c:463:10
#2 0x7fbe8d5be753 in AcquireImageInfo image.c:347:28
#3 0x7fbe8d5c78c3 in CloneImageInfo image.c:952:14
#4 0x7fbe8d5be688 in SyncImageSettings image.c:4051:21
#5 0x7fbe8d5bbe88 in AcquireImage image.c:290:10
#6 0x7fbe8dc47483 in ReadOneJNGImage png.c:4483:21
#7 0x7fbe8dc1bb1d in ReadJNGImage png.c:5053:9
#8 0x7fbe8d3faf98 in ReadImage constitute.c:497:13
#9 0x7fbe8d771bd9 in ReadStream stream.c:1045:9
#10 0x7fbe8d3f9b3f in PingImage constitute.c:226:9
#11 0x7fbe8d3fa2e3 in PingImages constitute.c:327:10
#12 0x7fbe8cb5b126 in IdentifyImageCommand identify.c:319:18
#13 0x7fbe8cc18dff in MagickCommandGenesis mogrify.c:183:14
#14 0x514f77 in MagickMain magick.c:151:10
#15 0x5149d1 in main magick.c:263:10
#16 0x7fbe87456f44 in __libc_start_main libc-start.c:287

Indirect leak of 9096 byte(s) in 1 object(s) allocated from:
#0 0x4def96 in __interceptor_malloc asan_malloc_linux.cc:66
#1 0x7fbe8d60af76 in AcquireMagickMemory memory.c:463:10
#2 0x7fbe8d60afd8 in AcquireQuantumMemory memory.c:536:10
#3 0x7fbe8d3891e4 in AcquirePixelCache cache.c:195:28
#4 0x7fbe8d5ba6bd in AcquireImage image.c:206:16
#5 0x7fbe8dc47483 in ReadOneJNGImage png.c:4483:21
#6 0x7fbe8dc1bb1d in ReadJNGImage png.c:5053:9
#7 0x7fbe8d3faf98 in ReadImage constitute.c:497:13
#8 0x7fbe8d771bd9 in ReadStream stream.c:1045:9
#9 0x7fbe8d3f9b3f in PingImage constitute.c:226:9
#10 0x7fbe8d3fa2e3 in PingImages constitute.c:327:10
#11 0x7fbe8cb5b126 in IdentifyImageCommand identify.c:319:18
#12 0x7fbe8cc18dff in MagickCommandGenesis mogrify.c:183:14
#13 0x514f77 in MagickMain magick.c:151:10
#14 0x5149d1 in main magick.c:263:10
#15 0x7fbe87456f44 in __libc_start_main libc-start.c:287

Indirect leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x4def96 in __interceptor_malloc asan_malloc_linux.cc:66
#1 0x7fbe8d60af76 in AcquireMagickMemory memory.c:463:10
#2 0x7fbe8d60afd8 in AcquireQuantumMemory memory.c:536:10
#3 0x7fbe8d64a44a in AcquirePixelChannelMap pixel.c:101:35
#4 0x7fbe8d5ba77b in AcquireImage image.c:208:22
#5 0x7fbe8dc47483 in ReadOneJNGImage png.c:4483:21
#6 0x7fbe8dc1bb1d in ReadJNGImage png.c:5053:9
#7 0x7fbe8d3faf98 in ReadImage constitute.c:497:13
#8 0x7fbe8d771bd9 in ReadStream stream.c:1045:9
#9 0x7fbe8d3f9b3f in PingImage constitute.c:226:9
#10 0x7fbe8d3fa2e3 in PingImages constitute.c:327:10
#11 0x7fbe8cb5b126 in IdentifyImageCommand identify.c:319:18
#12 0x7fbe8cc18dff in MagickCommandGenesis mogrify.c:183:14
#13 0x514f77 in MagickMain magick.c:151:10
 

Bug#870106: heap buffer overflow in ReadOneMNGImage

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded: https://github.com/ImageMagick/ImageMagick/issues/542

So a crafted file will cause x_off[i] out-of-bound operation vulnerability.

POC: https://github.com/jgj212/poc/blob/master/heap-mng

Bug#870107: memory exhaustion in ReadOneJNGImage in png.c

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1
forwarded: https://github.com/ImageMagick/ImageMagick/issues/549


When identify JNG file that contains chunk data, imagemagick will
allocate memory to store the chunk data in function ReadOneJNGImage

Here is the critical code:

if (length != 0)
  {
chunk=(unsigned char *)
AcquireQuantumMemory(length,sizeof(*chunk));   //length can be
controlled

if (chunk == (unsigned char *) NULL)
  ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");

for (i=0; i < (ssize_t) length; i++)
{
  int
c;

  c=ReadBlobByte(image);
  if (c == EOF)
break;
  chunk[i]=(unsigned char) c;
}

p=chunk;
  }

length can be controlled as follow:

length=ReadBlobMSBLong(image);   //length is from file data
count=(unsigned int) ReadBlob(image,4,(unsigned char *) type);

if (logging != MagickFalse)
  (void) LogMagickEvent(CoderEvent,GetMagickModule(),
"  Reading JNG chunk type %c%c%c%c, length: %.20g",
type[0],type[1],type[2],type[3],(double) length);

if (length > PNG_UINT_31_MAX || count == 0)
  ThrowReaderException(CorruptImageError,"CorruptImage");

So the only limitation is it must smaller than PNG_UINT_31_MAX, it is
still very large.

Also when chunk type is JDAT, it will write chunk data to file as follow:

if (memcmp(type,mng_JDAT,4) == 0)
  {
/* Copy chunk to color_image->blob */

if (logging != MagickFalse)
  (void) LogMagickEvent(CoderEvent,GetMagickModule(),
"Copying JDAT chunk data to color_blob.");

if (length != 0)
  {
(void) WriteBlob(color_image,length,chunk);
//write very large chunk data to file
chunk=(unsigned char *) RelinquishMagickMemory(chunk);
  }

continue;
  }

So a crafted jng file can cause memory exhausted and large I/O.

testcase:
https://github.com/jgj212/poc/blob/master/mem-jng

Credit: ADLab of Venustech

Bug#870105: Lack of validation of png file

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-13
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
control: found -1 8:6.7.7.10-5+deb9u1


Validate png file

Detected corrupted png early and avoid a crash

it is the merge of two upstream patch
aa84944b405acebbeefe871d0f64969b9e9f31ac and
46e3aabbf8d59a1bdebdbb65acb9b9e0484577d3

Bug#870104: kio_http_cache_cleaner runs indefinitely after logging out of KDE

[Brice Hunt]

Package: kio
Version: 5.28.0-2
Severity: normal

Dear Maintainer,

2nd or 3rd graphical logins to Plasma Desktop by various users sometimes hang 
in 
diverse and weird ways. Upon investigation, many processes were found to still 
be 
running after users log out. Further investigating, kio_http_cache_cleaner 
seems 
to be consistently running after a log out, causing other processes to not quit 
on logout. Killing this process would end the other processes that had remained
running, and the weird hangs never seem to happen if this process is killed 
after logging out.

I would submit a patch, but I am not sure of how sddm controls the logout to 
ensure processes are terminated appropriately.



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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 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 kio depends on:
ii  libacl1   2.2.52-3+b1
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgssapi-krb5-2  1.15-1
ii  libkf5archive55.28.0-2
ii  libkf5codecs5 5.28.0-1+b2
ii  libkf5completion5 5.28.0-1
ii  libkf5configcore5 5.28.0-2
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5dbusaddons5 5.28.0-1
ii  libkf5i18n5   5.28.0-2
ii  libkf5itemviews5  5.28.0-1
ii  libkf5kiocore55.28.0-2
ii  libkf5kiontlm55.28.0-2
ii  libkf5kiowidgets5 5.28.0-2
ii  libkf5notifications5  5.28.0-1
ii  libkf5service-bin 5.28.0-1
ii  libkf5service55.28.0-1
ii  libkf5solid5  5.28.0-3
ii  libkf5textwidgets55.28.0-1
ii  libkf5wallet-bin  5.28.0-3
ii  libkf5wallet5 5.28.0-3
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5windowsystem5   5.28.0-2
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5script5 5.7.1~20161021+dfsg-2
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5x11extras5  5.7.1~20161021-2
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  libxml2   2.9.4+dfsg1-2.2
ii  libxslt1.11.1.29-2.1

kio recommends no packages.

kio suggests no packages.

-- no debconf information

Bug#870103: freeplane: a Java (knopflerfish) exception will prevent freeplane from starting

[Sophoklis Goumas]

Package: freeplane
Version: 1.5.18-1
Severity: grave
Justification: renders package unusable

Hello, freeplane does NOT start due to a Java (knopflerfish) exception.

Here is the output of trying to start it from CLI:

$ freeplane
org.knopflerfish.framework.readonly=true
org.knopflerfish.gosg.jars=reference:file:/usr/share/freeplane/core/
org.freeplane.user.dir=/home/olspookishmagus
org.freeplane.basedirectory=/usr/share/freeplane
java.security.policy=/usr/share/freeplane/freeplane.policy
org.osgi.framework.storage=/usr/share/freeplane/fwdir
Knopflerfish OSGi framework launcher, version 
Copyright 2003-2016 Knopflerfish. All Rights Reserved.
See http://www.knopflerfish.org for more information.

Exception in thread "main" java.lang.IllegalArgumentException: xargs loading 
failed: java.io.FileNotFoundException: Didn't find xargs file: 
/usr/share/freeplane/fwdir/fwprops.xargs
at org.knopflerfish.framework.Main.loadArgs(Main.java:1373)
at org.knopflerfish.framework.Main.expandArgs(Main.java:907)
at org.knopflerfish.framework.Main.handleArgs(Main.java:480)
at org.knopflerfish.framework.Main.start(Main.java:224)
at org.knopflerfish.framework.Main.main(Main.java:156)
at org.freeplane.launcher.Launcher.run(Launcher.java:127)
at org.freeplane.launcher.Launcher.launch(Launcher.java:80)
at org.freeplane.launcher.Launcher.main(Launcher.java:67)

Sophoklis

-- Package-specific info:
[debug] /usr/bin/freeplane: Found JAVA_HOME = 
'/usr/lib/jvm/java-8-openjdk-amd64'
[debug] /usr/bin/freeplane: Found JAVA_CMD = 
'/usr/lib/jvm/java-8-openjdk-amd64/bin/java'
DEBUG:   Freeplane parameters are ''.
DEBUG:   Linux sojourn 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64 
GNU/Linux
No LSB modules are available.
DEBUG:   Distributor ID:Debian
Description:Debian GNU/Linux 8.9 (jessie)
Release:8.9
Codename:   jessie
DEBUG:   The following DEB packages are installed:
ii  freeplane   1.5.18-1   allJava 
program for working with Mind Maps
DEBUG:   Link '/usr/bin/freeplane' resolved to 
'/usr/share/freeplane/freeplane.sh'.
DEBUG:   Freeplane Directory is '/usr/share/freeplane'.
DEBUG:   Calling: /usr/lib/jvm/java-8-openjdk-amd64/bin/java
 -Xmx512m
 -Dorg.freeplane.basedirectory=/usr/share/freeplane
 -Dorg.freeplane.userfpdir=/home/olspookishmagus/.config/freeplane
 -Dorg.freeplane.old_userfpdir=/home/olspookishmagus/.freeplane
 -Dorg.freeplane.globalresourcedir=/usr/share/freeplane/resources
 -Dswing.systemlaf=javax.swing.plaf.metal.MetalLookAndFeel
 -Dorg.freeplane.os.lib.ext=/usr/share/java
 -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D
 -jar
 /usr/share/freeplane/freeplanelauncher.jar

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 freeplane depends on:
ii  default-jre [java7-runtime]  2:1.8-59
ii  groovy   2.4.8-1
ii  javahelp22.0.05.ds1-9
ii  jmapviewer   2.2+dfsg-2
ii  libbatik-java1.8-4
ii  libcommons-codec-java1.10-1
ii  libcommons-io-java   2.5-1
ii  libcommons-lang-java 2.6-6
ii  libfop-java  1:2.1-6
ii  libidw-java  1.6.1-1
ii  libjaxp1.3-java  1.3.05-2
ii  libjgoodies-forms-java   1.9.0-3
ii  libjlatexmath-java   1.0.3-1
ii  libjsyntaxpane-java  0.9.6~r156-6
ii  libknopflerfish-osgi-framework-java  5.2.0-2
ii  libmnemonicsetter-java   0.5-1
ii  librhino-java1.7.7.1-1
ii  libxerces2-java  2.11.0-7
ii  libxml-commons-external-java 1.4.01-2
ii  openjdk-8-jre [java7-runtime]8u141-b15-3
ii  simplyhtml   0.16.18-1

Versions of packages freeplane recommends:
ii  java-wrappers  0.1.28
ii  xdg-utils  1.1.1-1

Versions of packages freeplane suggests:
pn  freeplane-scripting-api  

-- no debconf information

Bug#870070: Debian 9.1 stretch: LibreOffice Writer crashes at startup

[benoit-petit-1]

Hi everybody

I have encountered the same concern on 32bit stretch and this one is solved by 
an uninstall and a new installation via synapic.

I noticed, somewhat by chance, that it is the freeoffice-gtk3 package that is 
problematic.

Installed, writer does not launch, but uninstalled, with synaptic or command 
line, writer launches.
It's up to you to play.

Best regards

Benoît

Bug#870102: automatically update schroots

[Antoine Beaupre]

Package: sbuild
Version: 0.73.0-4
Severity: wishlist
Tags: patch

It would be nice if sbuild automatically updated the configured
schroots. As things stand now, a configured schroot will slowly rot
down to a point where new builds will have to download a bunch of base
packages at each run, if sbuild is configured to automatically update
the schroot at build time. And if it's not, the resulting build will
be based on bit-rotten code as well.

I have used the following simple script in /etc/cron.weekly/sbuild:

#!/bin/sh -e

cd /etc/sbuild/chroot/
for chroot in *; do
sbuild-update --update --upgrade --clean --autoclean --autoremove $chroot 
>/dev/null
done

I don't like it so much: "> /dev/null" is a crude hack, and it should
be possible to silence apt more carefully. But it works and is good
enough for my purpose.

Could that be considered upstream?

Thanks!

A.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  libsbuild-perl  0.73.0-4
ii  perl5.24.1-3+deb9u1

Versions of packages sbuild recommends:
ii  autopkgtest  4.4
ii  debootstrap  1.0.89
ii  schroot  1.6.10-3+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  kmod   23-2
ii  wget   1.18-5

-- no debconf information

Bug#869952: [pkg-db-devel] Bug#869952: db5.3: Update bootstrapping code to build profile

[Ondřej Surý]

Hi Daniel,

patch would be very much appreciated.

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

On Fri, Jul 28, 2017, at 00:46, Daniel Schepler wrote:
> Source: db5.3
> Version: 5.3.28-13
> Severity: wishlist
> 
> It would be great if the next upload could update the DEB_STAGE=stage1
> support to support it as a build profile, i.e. support
> DEB_BUILD_PROFILES=stage1 and update the Build-Depends to something
> like:
> 
> Build-Depends: debhelper (>= 10),
>autotools-dev,
>dh-autoreconf,
>tcl-dev ,
>procps [!hurd-i386] ,
>javahelper [!m68k] ,
>default-jdk [!m68k] 
> 
> And also update the package stanzas for libdb5.3-java,
> libdb5.3-java-dev, libdb5.3-java-jni, libdb5.3-tcl in debian/control
> to include "Build-Profiles: ".
> 
> I should be able to write a patch for this if you want.
> -- 
> Daniel Schepler
> 
> ___
> pkg-db-devel mailing list
> pkg-db-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-db-devel

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Tollef Fog Heen]

]] Tollef Fog Heen 

> I call for votes on the following resolution with regards to #862051.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
> 
> === Resolution ===
> 
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
> 
> The Committee therefore resolves that:
> 
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
> 
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node.  The migration should
> be managed according to Debian's usual backwards-compatibility
> arrangements.
> 
> === End Resolution ===
> 
> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote R > F.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Tollef Fog Heen]

I call for votes on the following resolution with regards to #862051.
The voting period lasts for one week or until the outcome is no longer
in doubt (§6.3.1).

=== Resolution ===

The Technical Committee recognises that circumstances change in ways
that make previous resolutions no longer appropriate.  In 2012, it was
resolved that the nodejs package should not provide /usr/bin/node due to
the historical conflict with the ax25-node package.  Node.js is still
quite popular and the ax25-node package is no longer in stable, testing
or unstable so the requirement for nodejs to not provide /usr/bin/node
no longer applies.

The Committee therefore resolves that:

1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.

This means Debian's normal policies and practices take over and the
nodejs package is free to provide /usr/bin/node.  The migration should
be managed according to Debian's usual backwards-compatibility
arrangements.

=== End Resolution ===

R: Approve resolution and repeal the CTTE decision from 2012-07-12.
F: Further Discussion

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#870076: marked as done (src:chrony: maintainer address bounces)

[Paul Gevers]

Hi,

On 29-07-17 10:15, Debian Bug Tracking System wrote:
>> The maintainer address for chrony bounces, see below.
> 
> Indeed, that seems to happen from time to time. Sadly, my provider
> remains silent about these issues.
> 
> I’m naively closing the bug report in the hope that things will improve.

As sponsor for Vincent, I vouch that indeed it can't be "failing for a
long time" in general as I generally contact Vincent via that
e-mail-address as well. The issue is severe though. Vincent, is there
any way to bug your provider a bit more? I wonder if it is similar to my
issues with my ISP where DKIM is broken in the BTS, i.e. my ISP puts
responses that arrive via the BTS and that are DKIM signed in my SPAM
box (including my own). Also my ISP doesn't respond to my queries.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

On the git server you can find a new commit with all the changes requested.

2017-07-29 19:34 GMT+02:00 Andrey Rahmatullin :
> * The package now depends on python3
> Which package?
It's both a build dependency and a runtime dependency of "cyclograph"
the main binary package. The cyclograph-qt5 and cyclograph-gtk3 binary
packages depend on cyclograph, so they all depend on python3.
Please take a look at the new changelog and see if this is now clear.
> * The package now uses dh-python in combination with python3-setuptools
> "in combination"?
My understanding is that pybuild, provided by the dh-python package,
needs the setuptools for python3, but, since it cannot know if python2
or python3 is used, the correct B-D has to be manually added.
Please take a look at the new changelog and see if this is now clear.
> * Added cyclograph-qt5 ui
> Not clear that cyclograph-qt5 is a new subpackage.
Ok, last entry in the changelog was about the removal of
cyclograph-qt4, but I can understand that a longer description in the
changelog is more useful.
> * Debhelper compat version updated to 10
> It's "compat level", see debhelper(7).
Sorry for that. I confused the Debhelper version, with the compatibility level.
> * Updated Standards to 4.0.0
> It's "Standards-Version", and it's customary to add "(no change needed)"
> if an upgrade to the new version didn't require anything (I assume you've
> read the upgrade checklist?).
I read the checklist[1] and I didn't find anything to be done.
"(no change needed)" added.
> * Updated gtk to webkit2 version 4.0
> Not clear what is "gtk" here.
This is the "cyclograph-gtk3".
> * Added vcs field to debian/control
> It's not a "vcs" field but Vcs-Git and Vcs-Browser.
Modified
> You also didn't mention the switch to pybuild.
Added

 [1] https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
--
Federico

Bug#870101: cdparanoia: Error reading last track when using large sample offset

[Michael Below]

Package: cdparanoia
Version: 3.10.2+debian-11+b2
Severity: normal
Tags: patch

Dear Maintainer,

I can't rip the last track of a CD using cdparanoia on my CD drive. Other
tools like asunder work well. It is a HL-DT-ST, model: DVD-RAM GH40L ,
release: RB02

cdparanoia -B returns a long list of error messages like:

scsi_read error: sector=313555 length=1 retry=8
Sense key: 5 ASC: 21 ASCQ: 0
Transport error: Illegal SCSI request (rejected by target)
System error: Invalid argument

On drives that require a large -- presumably >= 588 -- sample offset
correction that do not support reading into the lead-out area of the disc,
cdparanoia will cause kernel transport errors and will fail when trying to
rip the last track.

Here's a patch:
http://lists.xiph.org/pipermail/paranoia-dev/2013-July/000277.html

This patch has not yet been applied upstream, since cdparanoia seems to be
not actively developed.

libcdio-tools contains a very similar tool, cd-paranoia, which has
adopted this patch and works fine.

Thanks for your work!

Cheers
Michael



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

Kernel: Linux 4.11.0-1-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 cdparanoia depends on:
ii  libc6   2.24-12
ii  libcdparanoia0  3.10.2+debian-11+b2

cdparanoia recommends no packages.

cdparanoia suggests no packages.

-- no debconf information

Bug#870100: RFS: hoteldruid/2.2.1-1

[Marco M. F. De Santis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "hoteldruid":

* Package name: hoteldruid
  Version : 2.2.1-1
  Upstream Author : Marco M. F. De Santis
* URL : http://www.hoteldruid.com
* License : AGPLv3
  Section : web

It builds those binary packages:

  hoteldruid - web-based property management system for hotels or B

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.2.1-1.dsc


More information about hoteldruid can be obtained from 
http://www.hoteldruid.com.


Changes since the last upload:

  * New upstream release.
  * debian/control: updated Standards-Version
  * debian/postinst: removed fallback to init.d script for new standards
version

Regards,
Marco M. F. De Santis

Bug#870099: latexdiff: Since some Perl update, latexdiff doesnt't even start

[Emmanuel Charpentier]

Package: latexdiff
Version: 1.1.1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?

Trying to use latexdiff-git, I got :
$ latexdiff-git -r HEAD~1 Spectro1.tex
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in
m/\\zref\@newlabel{ <-- HERE DIFchgb(\d*)}{.*\\abspage{(\d*)}}/ at
/usr/bin/latexdiff-git line 451.

It turns out that I get the same error for *any* invocation of latexdiff :

$ latexdiff --help
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in
m/\\includeonly{ <-- HERE (.*?)}/ at /usr/bin/latexdiff line 1572.


   * What exactly did you do (or not do) that was effective (or ineffective)?

Nothing : I can't think of any workaround...

A bit of googling leads to https://github.com/ftilmann/latexdiff/issues/43,
which hints that this bug is fixed in an upstream release not yet in Debian.

This issue also hints at a possible Perl-ish origin of the problem : indeed,
the issue appeared wit perl-5.22.1 and my current perl is :

$ perl --version

This is perl 5, version 26, subversion 0 (v5.26.0) built for x86_64-linux-gnu-
thread-multi
(with 51 registered patches, see perl -V for more detail)




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

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

Versions of packages latexdiff depends on:
ii  perl  5.26.0-4

Versions of packages latexdiff recommends:
ii  texlive-generic-recommended  2017.20170629-1
ii  texlive-latex-base   2017.20170629-1
ii  texlive-latex-extra  2017.20170629-1

Versions of packages latexdiff suggests:
ii  git 1:2.13.2-3
ii  subversion  1.9.6-1+b2

-- no debconf information

Bug#870086: Use " not ' for autopkgtest

[Mattia Rizzolo]

Control: clone -1 -2
Control: reassign -2 autopkgtest 4.4
Control: retitle -2 autopkgtest: single quotes in Test-Command makes test fail 
with -ENOENT

On Sat, Jul 29, 2017 at 04:42:03PM +0100, Iain Lane wrote:
> The ' is confusing autopkgtest (maybe an autopkgtest bug?)

definitely an autopkgtest bug, IMHO.
cloning & reassigning.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#870097: greybird-gtk-theme: The dates are the same color as the week numbers in the calendar

[Alexandre-Xavier Labonté-Lamoureux]

Package: greybird-gtk-theme
Version: 3.22.0-1
Severity: normal

Dear Maintainer,

I am using MATE and in the Clock applet, which can also display a calendar when
clicked on, the week numbers and the date are of the same color. This can lead
to some confusion because it is no clearly apparent that both are different
things (week numbers vs dates). Other themes display a different background
color or use a different font color for the week numbers and/or the days. I
noticed that Greybird, which is the one that I am using, is the only theme that
doesn't do that kind of demarcation when I compare it with the default themes
that are installed on my distro.

Please read the bug report here to better understand the problem and for
screenshots: https://github.com/mate-desktop/mate-panel/issues/628



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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 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 greybird-gtk-theme depends on:
ii  gtk2-engines-murrine  0.98.1.1-6

greybird-gtk-theme recommends no packages.

greybird-gtk-theme suggests no packages.

-- no debconf information

Bug#870096: bash: <(printf '%s' $'\177ELF')

[Askar Safin]

Package: bash
Version: 4.4-5
Severity: normal
Tags: upstream

Type this to bash:

cat <(printf '%s' $'\177ELF') > file-1

and this:

printf '%s' $'\177ELF' > file-2

Resulting files will be different. file-1 will contain 5 bytes (as opposed to 
expected 4)

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

Kernel: Linux 4.9.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   9.9
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u1
ii  libtinfo56.0+20161126-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi
if [ -x /usr/lib/command-not-found -o -x 
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
   /usr/lib/command-not-found -- "$1"
   return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
   /usr/share/command-not-found/command-not-found -- "$1"
   return $?
else
   printf "%s: command not found\n" "$1" >&2
   return 127
fi
}
fi
if ! shopt -oq posix; then #my-config# 
  if [ -f /usr/share/bash-completion/bash_completion ]; then #my-config# 
. /usr/share/bash-completion/bash_completion #my-config# 
  elif [ -f /etc/bash_completion ]; then #my-config# 
. /etc/bash_completion #my-config# 
  fi #my-config# 
fi #my-config# 

/etc/skel/.bash_logout [Errno 2] No such file or directory: 
'/etc/skel/.bash_logout'
/etc/skel/.bashrc changed:
case $- in
*i*) ;;
  *) return;;
esac
HISTCONTROL=ignoreboth
shopt -s histappend
HISTSIZE=1000
HISTFILESIZE=2000
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac
force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
 '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval 
"$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi


-- no debconf information

Bug#870095: liblwp-protocol-https-perl: Make source package bootstrappable

[Daniel Schepler]

Source: liblwp-protocol-https-perl
Version: 6.07-1
Severity: wishlist

Currently, liblwp-protocol-https-perl Build-Depends on libwww-perl
which in turn Depends on liblwp-protocol-https-perl.  It would be nice
if this build dependency cycle could be broken to aid the goal of a
bootstrappable Debian.

As far as I can tell, if you don't run the testsuite then libwww-perl
isn't required, so the package could update the Build-Depends-Indep to
something like:

Build-Depends-Indep: perl, libio-socket-ssl-perl ,
libnet-http-perl , libwww-perl (>= 6.05-2) ,
libtest-requiresinternet-perl 

which would take care of the cycle.

Otherwise, another potential way might be for libwww-perl to downgrade
the dependency on liblwp-protocol-https-perl to a Recommends.  In my
experience on other distributions, libwww-perl can still speak
straight HTTP without the HTTPS protocol suport installed.  I would
understand if you don't want to take this route, though.
-- 
Daniel Schepler

Bug#870094: gqrx-sdr: gqrx fails to start looking for old version of boost

[Henry Elliott]

Package: gqrx-sdr
Version: 2.6-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

This situation occurred when I tried to open gqrx for the first time since I
upgraded to Stretch.

I ran strace on gqrx with the following partial output:

open("/lib/x86_64-linux-gnu/tls/x86_64/libboost_chrono.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such 
file or directory)
open("/lib/x86_64-linux-gnu/tls/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls", 0x7ffdafd9afe0) = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/x86_64/libboost_chrono.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such file 
or directory)
open("/lib/x86_64-linux-gnu/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libboost_chrono.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/libboost_chrono.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/tls", {st_mode=S_IFDIR|0755, st_size=4096, 
...}) = 0
open("/usr/lib/x86_64-linux-gnu/x86_64/libboost_chrono.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=139264, ...}) 
= 0
open("/lib/tls/x86_64/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
stat("/lib/tls/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such file or directory)
open("/lib/tls/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
stat("/lib/tls", 0x7ffdafd9afe0)= -1 ENOENT (No such file or directory)
open("/lib/x86_64/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
stat("/lib/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such file or directory)
open("/lib/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
stat("/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/tls/x86_64/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
stat("/usr/lib/tls/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/libboost_chrono.so.1.55.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240-\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=27048, ...}) = 0
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libboost_date_time.so.1.55.0", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/libboost_date_time.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.55.0", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libboost_date_time.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/tls/libboost_date_time.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/usr/lib/x86_64/libboost_date_time.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
stat("/usr/lib/x86_64", 0x7ffdafd9afe0) = -1 ENOENT (No such file or directory)
open("/usr/lib/libboost_date_time.so.1.55.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=28672, ...}) = 0
writev(2, [{iov_base="gqrx", iov_len=4}, {iov_base=": ", iov_len=2}, 
{iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", 
iov_len=2}, {iov_base="libboost_date_time.so.1.55.0", iov_len=28}, {iov_base=": 
", iov_len=2}, {iov_base="cannot open shared object file", iov_len=30}, 
{iov_base=": ", iov_len=2}, {iov_base="No such file or directory", iov_len=25}, 
{iov_base="\n", iov_len=1}], 10gqrx: error while loading shared libraries: 
libboost_date_time.so.1.55.0: cannot open shared object file: No such file or 
directory
) = 132
exit_group(127) = ?
+++ exited with 127 +++
   * What was the outcome of this action?
   * What outcome did you expect instead?

This shows gqrx trying to access the version of boost (1.55.0) from Jessie.

Bug#870028: subunit: Make source package bootstrappable

[Rene Engelhard]

Hi,

On Sat, Jul 29, 2017 at 10:53:14AM -0700, Daniel Schepler wrote:
> > *shrugs*, Do I read that right that everything boils down to cppunit
> > using clang and that one build-dependig on ocaml for whatever reason?
> > This is hilarious.
> 
> It's actually doxygen that uses libclang.  Otherwise, that's correct.

Eh, yes, that's what I meant to write.

> On a second look at this cycle, I guess yet another possible place to 
>   
>   > break it would be if libxcb could be updated to 
> build-depend on "check
> > ".

Should be done nevertheless, imho. any check-only depends should be  
:)

> >> [...] and then doxygen could be moved to Build-Depends-Indep.
> >
> > That could be done, indeed...

Has been done. Has the nice side affect of the _all build just doing the docs.

Regards,

Rene

Bug#870028: subunit: Make source package bootstrappable

[Daniel Schepler]

On Sat, Jul 29, 2017 at 9:24 AM, Rene Engelhard  wrote:
> On Fri, Jul 28, 2017 at 06:43:40PM -0700, Daniel Schepler wrote:
>> doxygen Build-Depends on llvm-4.0-dev
>> llvm-toolchain-4.0 Build-Depends on ocaml-nox
>> ocaml Build-Depends on libx11-dev
>> libx11 Build-Depends on libxcb-dev
>> libxcb Build-Depends on check
>> check Build-Depends on libsubunt-dev
>> subunit Build-Depends on libcppunit-dev
>
> *shrugs*, Do I read that right that everything boils down to cppunit
> using clang and that one build-dependig on ocaml for whatever reason?
> This is hilarious.

It's actually doxygen that uses libclang.  Otherwise, that's correct.
(And I think the reason for llvm build-depending on ocaml is that
there's a seldom-used ocaml binding included in the package.  That
might be another place that a build profile, like "stage1" or
"no-ocaml", could potentially break the cycle.  Though at this point
in my bootstrap process there are several other packages that
llvm-toolchain-* is blocked on, so I'm not sure if that would be
sufficient.)

On a second look at this cycle, I guess yet another possible place to
break it would be if libxcb could be updated to build-depend on "check
".

>> [...] and then doxygen could be moved to Build-Depends-Indep.
>
> That could be done, indeed...

Thanks.
-- 
Daniel Schepler

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Russell Sim]

On 27 July 2017 at 14:01, Ximin Luo  wrote:

> Russell Sim:
> > [..]
> >
> > Thank you for the in depth description it was very helpful.  I was
> thinking
> > the same, but just wanted to clarify.
> >
> > I have tried to upload a new version, but was blocked because of the same
> > FTP ACL as before.  I think I should probably look at beginning the DD
> > process.  In the meantime it would be great if you could sponsor my
> upload
> > I have pushed it to git [0].
> >
> > 0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/
> >
>
> In d/changelog you said this is for unstable, but since other packages in
> Debian still link against libgit2 0.24 I think we are supposed to do a
> transition:
>
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> which means I should upload this to experimental first. However I also
> notice you already did that previously - did you also already check that
> the reverse dependencies also build correctly against 0.25? i.e. these
> packages:
>
> $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24 ~rnative
> !~e^libgit2$')
> eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate
> kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 libkf5texteditor5
> lua-gall python-pygit2 python3-pygit2 ruby-rugged
>
> If you did the check already, we might be able to upload directly to
> unstable, otherwise I think we are supposed to upload to experimental first
> and go through the process listed in the "Transitions" page I linked.
>
> This somewhat lengthy process, is also why I suggested to just package
> 0.26 directly and skip 0.25. Sorry, perhaps I should have explained it
> earlier.
>
> (I am fairly new to this process as well, despite me being a DD for
> several years I have not maintained a library package myself, that needs
> these sorts of rebuilds.)
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
>


Thanks for the info, I'll follow the document as described.

I think i may get some time on Monday to start building and testing the
rdepends.  In the meantime could you please upload 0.26.0+dfsg.1-1 to
experimental, I've pushed it to the collab-maint git.

-- 
Cheers,
Russell Sim

Bug#869692: RFS: cyclograph/1.9.0-1

[Andrey Rahmatullin]

On Fri, Jul 28, 2017 at 08:08:52PM +0200, Federico Brega wrote:
> > And there are other changes (about python for example) that are not listed
> > in the changelog.
> I listed all the changes done to files in the "debian" folder. The
> other changes are
> all made by upstream and, in my understanding, are out of scope from the 
> debian
> changelog.

* The package now depends on python3
Which package?
* The package now uses dh-python in combination with python3-setuptools
"in combination"? 
* Added cyclograph-qt5 ui
Not clear that cyclograph-qt5 is a new subpackage.
* Debhelper compat version updated to 10
It's "compat level", see debhelper(7).
* Updated Standards to 4.0.0
It's "Standards-Version", and it's customary to add "(no change needed)"
if an upgrade to the new version didn't require anything (I assume you've
read the upgrade checklist?).
* Updated gtk to webkit2 version 4.0
Not clear what is "gtk" here.
* Added vcs field to debian/control
It's not a "vcs" field but Vcs-Git and Vcs-Browser.

You also didn't mention the switch to pybuild.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#870093: plasma-desktop: plasma launchers log all stdout and stderr into .xsession-errors

[Alexander Schier]

Package: plasma-desktop
Version: 4:5.8.7.1-1
Severity: normal

Dear Maintainer,
KDE plasma writes all stdout/stderr from programs launched in the
plasmashell into .xsession-errors. This does not only create a huge
logfile depending on the program, but is also a privacy risk for example
when some browser extensions write debug output on the console
containing urls or other sensitive information.
I filed an upstream bug here:
https://bugs.kde.org/show_bug.cgi?id=382351
possibly debian could implement some workaround until the problem is
handled in upstream.

with kind regards,
Alexander Schier


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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.8.5-2
ii  kactivitymanagerd5.8.4-1
ii  kde-cli-tools4:5.8.7-1
ii  kded55.28.0-1
ii  kio  5.28.0-2
ii  libc62.24-12
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.12.3-0.2
ii  libgcc1  1:7.1.0-10
ii  libkf5activities55.28.0-1
ii  libkf5activitiesstats1   5.28.0-1
ii  libkf5archive5   5.28.0-2
ii  libkf5auth5  5.28.0-2
ii  libkf5baloo5 5.28.0-2
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5codecs55.28.0-1+b2
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5dbusaddons55.28.0-1
ii  libkf5emoticons-bin  5.28.0-1
ii  libkf5emoticons5 5.28.0-1
ii  libkf5globalaccel5   5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5iconthemes55.28.0-2
ii  libkf5itemmodels55.28.0-2
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-2
ii  libkf5kcmutils5  5.28.0-2
ii  libkf5kdelibs4support5   5.28.0-2
ii  libkf5kiocore5   5.28.0-2
ii  libkf5kiofilewidgets55.28.0-2
ii  libkf5kiowidgets55.28.0-2
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5parts5 5.28.0-1
ii  libkf5people55.28.0-1
ii  libkf5peoplewidgets5 5.28.0-1
ii  libkf5plasma55.28.0-2
ii  libkf5plasmaquick5   5.28.0-2
ii  libkf5quickaddons5   5.28.0-1
ii  libkf5runner55.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-4
ii  libkf5sonnetui5  5.28.0-2+b1
ii  libkf5wallet-bin 5.28.0-3
ii  libkf5wallet55.28.0-3
ii  libkf5widgetsaddons5 5.28.0-3
ii  libkf5windowsystem5  5.28.0-2
ii  libkf5xmlgui55.28.0-1
ii  libkfontinst54:5.8.7.1-1
ii  libkfontinstui5  4:5.8.7.1-1
ii  libkworkspace5-5 4:5.8.7-1
ii  libpackagekitqt5-0   0.9.6-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libpulse-mainloop-glib0  10.0-2
ii  libpulse010.0-2
ii  libqt5concurrent55.7.1+dfsg-4
ii  libqt5core5a 5.7.1+dfsg-4
ii  libqt5dbus5  5.7.1+dfsg-4
ii  libqt5gui5   5.7.1+dfsg-4
ii  libqt5network5   5.7.1+dfsg-4
ii  libqt5printsupport5  5.7.1+dfsg-4
ii  libqt5qml5   5.7.1-2+b2
ii  libqt5quick5 5.7.1-2+b2
ii  libqt5quickwidgets5  5.7.1-2+b2
ii  libqt5sql5   5.7.1+dfsg-4
ii  libqt5svg5   

Bug#870070: Debian 9.1 stretch: LibreOffice Writer crashes at startup

[Rene Engelhard]

tag 870070 - moreinfo
reassign 870070 src:linux
forcemerge 865303 870070
thanks

Hi,

On Sat, Jul 29, 2017 at 07:14:04PM +0200, Carmelo C wrote:
>"gdb --args /usr/lib/libreoffice/program/soffice.bin --writer"
>"run"
>"bt full"

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault. 


0xa969df95 in _expand_stack_to(unsigned char*) () from 
/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so  
 
(gdb) bt full   


#0  0xa969df95 in _expand_stack_to(unsigned char*) () from 
/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so  
 
No symbol table info available. 


#1  0xa96a07a4 in os::Linux::manually_expand_stack(JavaThread*, unsigned char*) 
()  

   from /usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so  


No symbol table info available.
[...]

There we go. It's that bug.

Somewhere in the kernel bugs is the boot command line to disable the security 
fix
as a workaround. Or install the original stretch (-2) kernel.

Reassigning to the kernel. Next time please check whether a bug already is 
reported.

You also might want to try running amd64 instead of an architecture already 
quite dead
in the last decade.

Regards,

Rene

Bug#860836: appstream-glib: run dh --with gir for ${gir:Depends}

[Matthias Klumpp]

2017-07-29 18:18 GMT+02:00 Iain Lane :
> tags 860836 + confirmed pending
> thanks
>
> Hi Dan,
>
> On Thu, Apr 20, 2017 at 02:29:11PM -0500, Dan Nicholson wrote:
>> Currently the gir1.2-appstreamglib-1.0 package has no dependencies.
>> This is because the ${gir:Depends} value used in the control file
>> never gets set since dh_girepository never runs. Pass --with gir to dh
>> to make that happen.
>
> Thanks for your report. I've committed your patch in git now - it'll be
> in unstable soon (which I'm hassling Matthias to do - hint, hint).

As soon as GLib and GObject-Introspection are updated ;-)

Bug#870078: libsane1 breaks all 3rd party scanner drivers

[Jörg Frings-Fürst]

Hello Gunter,

the version 1.0.27-1~experimental1ubuntu2 is a Ubuntu specific version.

They based on the Debian 1.0.27-1~experimental1 from the branch
experimental.

Quote from[1]:

Experimental is used for packages which are still being developed, and
with a high risk of breaking your system. It's used by developers who'd
like to study and test bleeding edge software. Users shouldn't be using
packages from there, because they can be dangerous and harmful even for
the most experienced people.

If Ubuntu uses packages from experimental this happens at your own
risk.

So I close this bug.

CU
Jörg


[1] https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.en.html

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#870070: Debian 9.1 stretch: LibreOffice Writer crashes at startup

[Carmelo C]

I apologize for mistaken publishing the bug with incorrect "Severity" and
"Tags"

I have installed the following packages from:
deb http://debug.mirrors.debian.org/debian-debug/ stretch-debug main

gdb (7.12-6)
libbabeltrace-ctf1 (1.5.1-1)
libbabeltrace1 (1.5.1-1)
libc6-dbg (2.24-11+deb9u1)
libdw1 (0.168-1)
libreoffice-writer-dbgsym (1:5.2.7-1)
libreoffice-base-core-dbgsym (1:5.2.7-1)
libreoffice-base-dbgsym (1:5.2.7-1)


And I executed the command:

"gdb --args /usr/lib/libreoffice/program/soffice.bin --writer"
"run"
"bt full"
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/libreoffice/program/soffice.bin...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /usr/lib/libreoffice/program/soffice.bin --writer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xafadfb40 (LWP 10652)]
[New Thread 0xae8edb40 (LWP 10654)]
[New Thread 0xadeffb40 (LWP 10655)]
[New Thread 0xad3aeb40 (LWP 10656)]
[New Thread 0xacbadb40 (LWP 10657)]
[New Thread 0xabf75b40 (LWP 10658)]
[New Thread 0xab759b40 (LWP 10659)]
Traceback (most recent call last):
  File 
"/usr/share/gdb/auto-load/usr/lib/libreoffice/program/libswlo.so-gdb.py", line 
23, in 
module=importlib.import_module("libreoffice."+mod)
  File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 986, in _gcd_import
  File "", line 969, in _find_and_load
  File "", line 958, in _find_and_load_unlocked
  File "", line 673, in _load_unlocked
  File "", line 673, in exec_module
  File "", line 222, in _call_with_frames_removed
  File "/usr/share/libreoffice/gdb/libreoffice/sw.py", line 11, in 
from libreoffice.util import printing
ImportError: No module named 'libreoffice.util'
[Thread 0xae8edb40 (LWP 10654) exited]

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0xa969df95 in _expand_stack_to(unsigned char*) () from 
/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
(gdb) bt full
#0  0xa969df95 in _expand_stack_to(unsigned char*) () from 
/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
No symbol table info available.
#1  0xa96a07a4 in os::Linux::manually_expand_stack(JavaThread*, unsigned char*) 
()
   from /usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
No symbol table info available.
#2  0xa96aace8 in os::create_main_thread(JavaThread*) () from 
/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
No symbol table info available.
#3  0xa97ed69e in Threads::create_vm(JavaVMInitArgs*, bool*) ()
   from /usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
No symbol table info available.
#4  0xa9498f45 in JNI_CreateJavaVM () from 
/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
No symbol table info available.
#5  0xb23399a1 in ?? () from /usr/lib/libreoffice/program/libjvmfwklo.so
No symbol table info available.
#6  0xb234bbf4 in jfw_startVM(JavaInfo const*, JavaVMOption*, long, JavaVM_**, 
JNIEnv_**) ()
   from /usr/lib/libreoffice/program/libjvmfwklo.so
No symbol table info available.
#7  0xa9ec711a in ?? () from /usr/lib/libreoffice/program/libjavavmlo.so
No symbol table info available.
#8  0xac302933 in ?? () from /usr/lib/libreoffice/program/libjavaloaderlo.so
No symbol table info available.
#9  0xac3047ef in ?? () from /usr/lib/libreoffice/program/libjavaloaderlo.so
No symbol table info available.
#10 0xb23ce058 in ?? () from 
/usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
No symbol table info available.
#11 0xb23d0274 in ?? () from 
/usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
No symbol table info available.
#12 0xb23d03a5 in ?? () from 
/usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
No symbol table info available.
#13 0xb23cbf87 in ?? () from 
/usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
No symbol table info available.
#14 0xb4ffde35 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
No symbol table info available.
#15 0xb50007ca in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
---Type  to continue, or q  to quit---
No symbol table info available.
#16 0xb50023c9 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so

Bug#841951: [PATCH]: bitcoin-qt segfaults on startup

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 29 de julio de 2017 18:06:45 -03 Erik de Castro Lopo wrote:
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > forwarded 841951 https://bugreports.qt.io/browse/QTBUG-58910
> > thanks
> > 
> > Erik: if possible please subscribe to the upstream bug, maybe we can
> > iron out another bug in the process.
> 
> To fix this issue locally, I have force (ie, quick and dirty) installed a
> patched version of libqxcb-glx-integration.so, but every time I update that
> package it breaks bitcoin-qt.
> 
> Since upstream seem to be in no hurry to fix this, can debian not ship
> a patched version, at least until upstream fixes it?

As you can see in

  

the patch is not exactly right.

That needs to be fixed before we add that patch, be it locally or in upstream 
(although upstream is much better).



-- 
...man had always assumed that he was more intelligent than dolphins because
he had achieved so much -- the wheel, New York, wars and so on -- whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man -- for precisely the same reasons.
  Douglas Adams, "The hitchhikers' guide to the galaxy"

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


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

Bug#858373: help needed to complete regression fix for apache2 Bug#858373

[Antoine Beaupré]

Control: fixed 858373 2.2.22-13+deb7u7
Control: tags 858373 +pending +patch

On 2017-07-21 09:44:38, Antoine Beaupré wrote:
> TL;DR: New proposed package (deb7u11) doesn't actually show a new
> regression, please test:
>
> https://people.debian.org/~anarcat/debian/wheezy-lts/apache2_2.2.22-13+deb7u11_amd64.changes
>
> In particular, Brian Kroth: are you *sure* you had that ErrorDocument
> 400 working in apache2_2.2.22-13+deb7u7 (ie. before the DLA-841-1
> upload)? In my tests, it didn't actually work at all. It wouldn't
> trigger a segfault, but the CGI script wouldn't get called either. In
> the above package, we don't segfault anymore, but we yield a 400 + 500
> error message (because the ErrorDocument fails). The solution, here, is
> obviously to update to a later Apache version (e.g. update to jessie,
> really) to get that functionality working, from my perspective.

Timing out on this one: I will assume that 2.2.22-13+deb7u7 didn't
segfault, but then didn't yield a proper ErrorDocument either (because I
cannot reproduce that behavior).

I have uploaded deb7u11 and will send the associated DLA-841-2
regression update when it hits the archives.

A.

-- 
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Karl Popper

Bug#870092: fvwm1 no menu on mouse 2

[Ulrich Teichert]

Package: fvwm1
Version: 1.24r-56+b1
Severity: important

After the dist-upgrade from jessie to stretch, the fvwm1 menu on mouse 2
disapeared. The middle mouse button (which referes to mouse 2) does work
for xterm (cut & paste) or firefox, though. Just that no menu comes up
from the root window. The other menus on mouse 1 and 3 are working fine.

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

Kernel: Linux 4.9.0-3-686-pae (SMP w/1 CPU core)
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 fvwm1 depends on:
ii  libc6 2.24-11+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxpm4   1:3.5.12-1
ii  m41.4.18-1

fvwm1 recommends no packages.

Versions of packages fvwm1 suggests:
pn  fvwm-icons | fvwm-common  
pn  librplay3 
pn  menu  
ii  xfonts-100dpi 1:1.0.4+nmu1
ii  xfonts-75dpi  1:1.0.4+nmu1

-- no debconf information

Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Hi Osamu,

Sorry for the late reply, and thanks for looking into this! Replies
inline:

Osamu Aoki  writes:
> How should we explicitly specify such variables, I guess it should be
> through "opts=..." such as:
>
>  opts="mode=git, pretty=0.0~git%cd.%h, date=%Y%m%d%H%M"

Sounds good.

>
> But this "git log" needs to have local clone of git repository.
>
> I wonder if I can do without cloning first.

After reading the git protocol and searching on the web for a little
bit, my conclusion is that no, you cannot use “git log” without having a
clone of the repository.

Given that we are talking about repositories which do not use tags, we
could specify --depth=1 when cloning to get a shallow clone, i.e. only
the latest commit. That saves bandwidth and disk space, but has the
downside that we cannot do any additional validation, i.e. we can’t
detect if upstream ever starts using tags — unfortunately, that is a
plausible scenario, so I would suggest doing a full clone.

For GitHub, we can apply an optimization: the GitHub HTTP API exposes
repository details, such as:

1. The default_branch of the repo, in
   https://developer.github.com/v3/repos/#get

2. The latest commit of the branch, in
   https://developer.github.com/v3/repos/branches/#get-branch

For interactive use by individual developers, we could send these HTTP
requests unauthenticated. For a setup which does many uscan calls, we’d
need to create a GitHub account to get the higher rate limit. See
https://godoc.org/github.com/google/go-github/github#hdr-Rate_Limiting
for details.

> Adding support to the number of commits is complicated.  Let's be happy
> to use hash to be unique commit.  I do not think we upload more than 2
> Debian upstream tarball in a minute.

In a day, not in a minute. But regardless, you are probably right. I
asked in the pkg-go IRC channel to see whether people are okay with
removing that part from the version number, so barring any objections,
we can probably get that done within the next few days.

> As for "git describe" like nearest tag feature, it's a interesting
> thought but it may make things more complicate.  So unless someone
> strongly request with patch, I would like to skip it.

Agreed — if we get rid of the number of commits, we shouldn’t need git
describe, not even in dh-make-golang.

It seems like you have a good handle on implementing this in uscan. Do
you need any additional details? Do you prefer an external patch from
us over implementing this yourself? I’d be happy to give you feedback on
a proposed patch or git commit.

Thank you very much!

-- 
Best regards,
Michael

Bug#868431: wmaker: uses static upstream menu

[Andreas Metzler]

On 2017-07-29 Andreas Metzler  wrote:
[...]
> #1 Providing a new full menu in /etc/GNUstep/Defaults/WMRootMenu does
> not make the new content available to users. Anybody who has started
> wmaker before will continue using ~/GNUstep/Defaults/WMRootMenu which
> references "menu.hook". So I think we need to provide a file named
> menu.hook in wmaker's search path with the new content.
[...]
> Afaict #1 only has an imperfect solution, shipping the menu in
> /usr/share/WindowMaker/menu.hook.
[...]

which does not seem to work, since with a WMRootMenu consisting of
"menu.hook"

wmaker expects the menu.hook file to contain a menu file in plain-text,
i.e. non proplist format.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#870028: subunit: Make source package bootstrappable

[Rene Engelhard]

Hi,

even with

> Sorry, I meant to file this against cppunit, not subunit.

from your reassign this bug report is weird.

On Fri, Jul 28, 2017 at 06:43:40PM -0700, Daniel Schepler wrote:
> The subunit source package's Build-Depends on doxygen creates a
> circular dependency which makes it difficult to bootstrap:
> 
> doxygen Build-Depends on llvm-4.0-dev
> llvm-toolchain-4.0 Build-Depends on ocaml-nox
> ocaml Build-Depends on libx11-dev
> libx11 Build-Depends on libxcb-dev
> libxcb Build-Depends on check
> check Build-Depends on libsubunt-dev
> subunit Build-Depends on libcppunit-dev

*shrugs*, Do I read that right that everything boils down to cppunit
using clang and that one build-dependig on ocaml for whatever reason?
This is hilarious.
 
> The easiest way I can think of to resolve this would be if the
> generated documentation could be split out into a separate
> libsubunit-doc package,

Erm, but you have seen that libcppunit-doc *DOES* exist?

> [...] and then doxygen could be moved to Build-Depends-Indep.

That could be done, indeed...

Regards,

Rene

Bug#860836: appstream-glib: run dh --with gir for ${gir:Depends}

[Iain Lane]

tags 860836 + confirmed pending
thanks

Hi Dan,

On Thu, Apr 20, 2017 at 02:29:11PM -0500, Dan Nicholson wrote:
> Currently the gir1.2-appstreamglib-1.0 package has no dependencies.
> This is because the ${gir:Depends} value used in the control file
> never gets set since dh_girepository never runs. Pass --with gir to dh
> to make that happen.

Thanks for your report. I've committed your patch in git now - it'll be
in unstable soon (which I'm hassling Matthias to do - hint, hint).

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#870091: ITP: pyaes -- Pure-Python Implementation of the AES block-cipher and common modes of operation

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann 

* Package name: pyaes
  Version : 1.6.0
  Upstream Author : Richard Moore 
* URL : https://github.com/ricmoo/pyaes
* License : License :: OSI Approved :: MIT License
  Programming Lang: Python
  Description : Pure-Python Implementation of the AES block-cipher and 
common modes of operation

Binary package names: python-pyaes

 A pure-Python implementation of the AES (FIPS-197)
 block-cipher algorithm and common modes of operation (CBC, CFB, CTR, ECB,
 OFB) with no dependencies beyond standard Python libraries. See README.md
 for API reference and details.

I intend to maintain this under the Debian Python Modules Team.

Bug#869994: perl5.26 update: postgresql databases cannot be viewed using browser

[gregor herrmann]

On Sat, 29 Jul 2017 08:12:28 +0100, Neil Redgate wrote:

> Thank you for your quick reply.

You're welcome.
 
> I am disappointed to learn that this problem is not fixable but at
> least I know what the situation is.

"not fixable" is a bit too strong IMO; there won't be a "fix" on the
perl side in Debian but there are other options:

> I will attempt to let the sql-ledger developer know of the situation
> though I am not a subscriber to their forum.

Having sql-leder work with perl 5.26 by making changes upstream would
be the best way forward.

Fixing the code yourself is another option.
And then it's also possible to fix the packaged (currently rather
old) version of sql-ledger in debian (which would need a new
maintainer first as the package is oprhaned -- but I already heard of
a person interested in the task), then you could switch to the debian
version.

> Can you confirm that perl 5.26 is being applied on all OS - windows,
> mac & linux?

It exists on all platforms; if it's installed probably depends on the
(packaging system of in the absence thereof on the) local admin.

> Is it possible to have both perl 5.24 and 5.26 running on the same
> linux system?

No, at least under Debian and derivatives.

But debian stable contains 5.24 and will be supported for another
couple of years; the problems you are facing come from running
testing where you got all the shiny new developments early :)
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#870088: libalien-gnuplot-perl: please upgrade to latest release

[gregor herrmann]

Control: clone -1 -2
Control: retitle -2 libpdl-graphics-gnuplot-perl: needs Alien::Gnuplot version 
1.031 or higher
Control: block -2 -1
Control: severity -1 normal

On Sat, 29 Jul 2017 17:56:40 +0200, Gianfranco Costamagna wrote:

> Package: libalien-gnuplot-perl
> Version: 1.030-2
> Severity: serious
> Justification: breaks other software
> tags: patch
> 
> Hello, seems that libpdl-graphics-gnuplot-perl now requires at least 1.031 of 
> gnuplot-perl

If libpdl-graphics-gnuplot-perl fails to build or to test/run, then
this is a bug in libpdl-graphics-gnuplot-perl, precisely that it
didn't declare the new requirement and wait for it to be available.
And it's not libpdl-graphics-gnuplot-perl suddenly breaking something
…


/*
Admittedly, after looking at libpdl-graphics-gnuplot-perl, it's not
very obvious that a newer libalien-gnuplot-perl is needed:

CHANGES: - Required Alien::Gnuplot version 1.031 (fixes a bug with terminal ID)
lib/PDL/Graphics/Gnuplot.pm:if($Alien::Gnuplot::VERSION < 1.031) {
lib/PDL/Graphics/Gnuplot.pm:die "PDL::Graphics::Gnuplot requires 
Alien::Gnuplot version 1.031 or higher\n (v$Alien::Gnuplot::VERSION found). You 
can pull the latest from CPAN.\n";

so nothing in META.* or Makefile.PL.
*/
 

Doing some BTS manipulations …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#868544: closing 868544

[Gianfranco Costamagna]

Seems to have been rejected

G.



signature.asc
Description: OpenPGP digital signature

Bug#870088: libalien-gnuplot-perl: please upgrade to latest release

[Gianfranco Costamagna]

Package: libalien-gnuplot-perl
Version: 1.030-2
Severity: serious
Justification: breaks other software
tags: patch

Hello, seems that libpdl-graphics-gnuplot-perl now requires at least 1.031 of 
gnuplot-perl

autopkgtest [08:01:26]: test command2: /usr/share/pkg-perl-autopkgtest/runner 
runtime-deps
autopkgtest [08:01:26]: test command2: [---

#   Failed test ' /usr/bin/perl -w -M"PDL::Graphics::Gnuplot" -e 1 2>&1 exited 
successfully'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 106.

#   Failed test ' /usr/bin/perl -w -M"PDL::Graphics::Gnuplot" -e 1 2>&1 
produced no (non-whitelisted) output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.

#   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"PDL::Graphics::Gnuplot" -e 1 2>&1 exited successfully'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 106.

#   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"PDL::Graphics::Gnuplot" -e 1 2>&1 produced no (non-whitelisted) output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.
# Looks like you failed 4 tests of 4.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 
1..4
# PDL::Graphics::Gnuplot requires Alien::Gnuplot version 1.031 or higher
#  (v1.030 found). You can pull the latest from CPAN.
# Compilation failed in require,  line 173.
# BEGIN failed--compilation aborted,  line 173.
not ok 1 -  /usr/bin/perl -w -M"PDL::Graphics::Gnuplot" -e 1 2>&1 exited 
successfully
not ok 2 -  /usr/bin/perl -w -M"PDL::Graphics::Gnuplot" -e 1 2>&1 produced no 
(non-whitelisted) output
# PDL::Graphics::Gnuplot requires Alien::Gnuplot version 1.031 or higher
#  (v1.030 found). You can pull the latest from CPAN.
# Compilation failed in require,  line 173.
# BEGIN failed--compilation aborted,  line 173.
not ok 3 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"PDL::Graphics::Gnuplot" 
-e 1 2>&1 exited successfully
not ok 4 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"PDL::Graphics::Gnuplot" 
-e 1 2>&1 produced no (non-whitelisted) output
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/4 subtests 


please update it
(you can grab the update from ubuntu with the rebased patch
https://launchpad.net/ubuntu/+source/libalien-gnuplot-perl/1.033-0ubuntu1 )

thanks

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#861378: Disable debian-chinese-b...@lists.debian.org list

[陳昌倬]

On Sat, Jul 29, 2017 at 11:31:15PM +0800, Andrew Lee wrote:
> * Why do we use -dug-taiwan and not just simply use -taiwan for the list
> name?

Just follow the naming schema in https://wiki.debian.org/LocalGroups.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#870087: 5.7.0 is compiled using -march=native

[Samuel Henrique]

Package: t50
Version: 5.6.15-1
Severity: grave

Upstream removed patch which accepted flags passed to compiler and now it uses
-march=native.

I'm one of the maintainers of t50 and i'm opening this bug to aware those who
wish to update t50 from unstable.
I will fix this in 2 days max (there's a chance someone from pkg-sec fix this
before me too).



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

Kernel: Linux 4.11.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages t50 depends on:
ii  libc6  2.24-12

t50 recommends no packages.

t50 suggests no packages.

Bug#870086: Use " not ' for autopkgtest

[Iain Lane]

Package: lua-torch-sys
Version: 0~20161027-gf073f05-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Hi,

See:

  
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lua-torch-sys/20170729_142419/log.gz

The ' is confusing autopkgtest (maybe an autopkgtest bug?)

Patch attached.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
diff -Nru lua-torch-sys-0~20161027-gf073f05/debian/tests/control 
lua-torch-sys-0~20161027-gf073f05/debian/tests/control
--- lua-torch-sys-0~20161027-gf073f05/debian/tests/control  2017-07-28 
10:40:09.0 +0100
+++ lua-torch-sys-0~20161027-gf073f05/debian/tests/control  2017-07-29 
16:33:21.0 +0100
@@ -1 +1 @@
-Test-Command: luajit -lsys -e 'print(true)'
+Test-Command: luajit -lsys -e "print(true)"

Bug#870085: trackballs-data needs to replace trackballs << 1.2.3-1

[Stephen Kitt]

Package: trackballs-data
Version: 1.1.4-4.3
Severity: serious
Justification: Policy 7.4

Dear Maintainer,

/usr/share/applications/trackballs.desktop moved from trackballs to
trackballs-data, but trackballs-data doesn’t break/replace trackballs,
resulting in

Preparing to unpack .../trackballs-data_1.2.3-1_all.deb ...
Unpacking trackballs-data (1.2.3-1) over (1.1.4-4.3) ...
dpkg: error processing archive 
/var/cache/apt/archives/trackballs-data_1.2.3-1_all.deb (--unpack):
 trying to overwrite '/usr/share/applications/trackballs.desktop', which is 
also in package trackballs 1.1.4-4.3
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

during upgrade attempts.

Please add the appropriate Breaks/Replaces relationships.

Regards,

Stephen


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

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

-- no debconf information

Bug#859213: x11vnc: stack smashing detected: x11vnc terminated

[Octocrobe Pigloo]

I just had the problem at least 20 times today.


If the problem is corrected upstream since middle of 2016 I'm not sure to 
understand why it's still waiting for something before entering into debian 9. 
Some validation ? Obviously, the current one does not work, it cannot be worst.


Thank you !

Bug#870084: apt-listchanges: [INTL:pt] Updated Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: apt-listchanges
Version: 3.14
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for samba's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org







# Portuguese translation of apt-listchanges's debconf messages.
# 2007, Rui Branco 
# Rui Branco - DebianPT , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listchanges 3.14\n"
"Report-Msgid-Bugs-To: apt-listchan...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-08 22:37+0200\n"
"PO-Revision-Date: 2017-07-29 16:28+\n"
"Last-Translator: Rui Branco - DebianPT \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: select
#. Choices
#: ../templates:2001
msgid "pager"
msgstr "pager"

#. Type: select
#. Choices
#: ../templates:2001
msgid "browser"
msgstr "browser"

#. Type: select
#. Choices
#: ../templates:2001
msgid "xterm-pager"
msgstr "xterm-pager"

#. Type: select
#. Choices
#: ../templates:2001
msgid "xterm-browser"
msgstr "xterm-browser"

#. Type: select
#. Choices
#: ../templates:2001
msgid "gtk"
msgstr "gtk"

#. Type: select
#. Choices
#. Type: select
#. Choices
#: ../templates:2001 ../templates:4001
msgid "text"
msgstr "texto"

#. Type: select
#. Choices
#: ../templates:2001
msgid "mail"
msgstr "mail"

#. Type: select
#. Choices
#: ../templates:2001
msgid "none"
msgstr "nenhum"

#. Type: select
#. Description
#: ../templates:2002
msgid "Method to be used to display changes:"
msgstr "Método de visualização das modificações:"

#. Type: select
#. Description
#: ../templates:2002
msgid ""
"Changes in packages can be displayed in various ways by apt-listchanges:"
msgstr ""
"Modificações nos pacotes podem ser visualizadas de variados modos pelo apt-"
"listchanges:"

#. Type: select
#. Description
#: ../templates:2002
msgid ""
" pager: display changes one page at a time;\n"
" browser  : display HTML-formatted changes using a web browser;\n"
" xterm-pager  : like pager, but in an xterm in the background;\n"
" xterm-browser: like browser, but in an xterm in the background;\n"
" gtk  : display changes in a GTK window;\n"
" text : print changes to the terminal (without pausing);\n"
" mail : only send changes via e-mail;\n"
" none : do not run automatically from APT."
msgstr ""
" pager : visualizar modificações uma página de cada vez;\n"
" browser   : visualizar modificações em HTML com um browser web;\n"
" xterm-pager   : como um pager, mas com uma consola xterm em fundo;\n"
" xterm-browser : como um browser, mas·com·uma·consola·xterm·em·fundo;\n"
" gtk   : visualizar modificações numa janela GTK;\n"
" text  : envia as modificações para o seu terminal (sem pausa);\n"
" mail  : apenas envia as modificações via mail;\n"
" none  : não corre automaticamente a partir do APT."

#. Type: select
#. Description
#: ../templates:2002
msgid ""
"This setting can be overridden at execution time. By default, all the "
"options except for 'none' will also send copies by mail."
msgstr ""
"Esta opção pode ser ultrapassada durante a execução. Por omissão, todas as "
"opções excepto 'none' podem também enviar uma cópia por mail."

#. Type: string
#. Description
#: ../templates:3001
msgid "E-mail address(es) which will receive changes:"
msgstr "Endereço(s) e-mail que receberá as modificações:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Optionally, apt-listchanges can e-mail a copy of displayed changes to a "
"specified address."
msgstr ""
"Em opção, o apt-listchanges pode enviar por email uma cópia das modificações "
"visualizadas para um endereço específico."

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Multiple addresses may be specified, delimited by commas. Leaving this field "
"empty disables mail notifications."
msgstr ""
"Podem ser especificados múltiplos endereços, delimitados por vírgulas. Deixe "
"este espaço vazio se não quiser que seja enviado qualquer notificação por "
"email."

#. Type: select
#. Choices
#: ../templates:4001
msgid "html"
msgstr "html"

#. Type: select
#. Description
#: ../templates:4002
msgid "Format of e-mail messages:"
msgstr "Formato das mensagens de e-mail:"

#. Type: select
#. Description
#: ../templates:4002
#| msgid "Please choose which type of changes should be displayed with APT."
msgid "Please choose a format of e-mail copies of the displayed changes."
msgstr ""
"Por favor escolha o formato das cópias de e-mail para visualização das"
" modificações."

#. Type: select
#. Description
#: ../templates:4002
msgid ""
" text  : plain 

Bug#861378: Disable debian-chinese-b...@lists.debian.org list

[Andrew Lee]

Thanks for bring up this proposal.
* I fully agree to disable -big5 list if we may keep the list archive for
old mail threads.
* Why do we use -dug-taiwan and not just simply use -taiwan for the list
name?

Best regards,
-Andrew

2017-07-29 22:32 GMT+08:00 ChangZhuo Chen (陳昌倬) :

>
> Hi All,
>
> I would like to propose to disable debian-chinese-b...@lists.debian.org
> for the following reasons:
>
> * For Chinese translation related discuss, we already have
>   debian-l10n-chinese@l.d.o
>
> * For Debian user in Taiwan, A new list debian-dug-taiwan has been
>   requested (#847950).
>
> * Big5 encoding is deprecated long time ago.
>
>
> Please raise your concern if you think we shall keep
> debian-chinese-big5@l.d.o.
>
>
> --
> ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
> http://czchen.info/
> Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B
>



-- 
-Andrew

Bug#869574: stretch-pu: package kdepim/4:16.04.3-4

[Adam D. Barratt]

On Sat, 2017-07-29 at 14:24 +0200, Sandro Knauß wrote:
> Hey,
> 
> > currently in stretch is 4:16.04.3-3. Thus the version which should
> > preferably be used would be 4:16.04.3-3+deb9u1.
> 
> just to understand the process better:
> * Do I need to send another debdiff with the corrected versionnumber first 
> before uploading?

If by that you mean taking the previously incorrectly generated diff and
simply changing the version number it contains, then no.

> * Do I need to close this bug within the changelog entry?

No. The bug will be closed by us once the package is actually in stable.
Until that point, the process is incomplete, so closing the bug would be
illogical.

> * Are there any further issues with my debdiff?

Besides not being what has been requested multiple times?

The point of the process is to demonstrate that you can build - and have
built - your proposed upload against the release that you're proposing
to upload it to and to confirm what the debdiff of the resulting package
against the target release looks like.

It's entirely possible that it will be the same as the diff between the
stable and testing packages that you previously provided. That's by no
means certain, however, and in any case diffing things that aren't what
you're proposing to upload misses the point of the review step.

This isn't theoretical nitpicking. We've seen there be a distinct
difference between what people propose and what they actually upload
enough times in the past that there's no way we'll agree an update based
on a hypothetical diff rather than an actually built and tested one.

Regards,

Adam

Bug#870083: prometheus-node-exporter: Inappropriate depends on daemon

[Tollef Fog Heen]

Package: prometheus-node-exporter
Version: 0.13.0+ds-1+b2
Severity: normal

Most systems don't need the daemon dependency since it's only used with
non-systemd setups.  It should be demoted to a Suggests or Recommends
rather than a depends.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#869689: Bug#870080: igtf-policy-bundle: [INTL:pt] Updated Portuguese translation for debconf messages

[Dennis van Dok]

Thanks, but now I have two translations. The earlier translation is tracked in 
bug 
#869689. Below is the diff; could you help sort out what to do about it?

Cheers,

Dennis


@@ -1,22 +1,22 @@
-# Translation of igtf-policy-bundle's debconf messages to European Portuguese
+# Translation of igtf-policy-bundle's debconf messages to Portuguese
 # Copyright (C) 2014 THE igtf-policy-bundle'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the igtf-policy-bundle 
package.
 #
-# Américo Monteiro , 2014, 2017.
+# Américo Monteiro , 2014.
+# Rui Branco - DebianPT , 2017.
 msgid ""
 msgstr ""
 "Project-Id-Version: igtf-policy-bundle 1.85-1\n"
 "Report-Msgid-Bugs-To: igtf-policy-bun...@packages.debian.org\n"
 "POT-Creation-Date: 2017-07-24 17:44+0200\n"
-"PO-Revision-Date: 2017-07-25 17:59+\n"
-"Last-Translator: Américo Monteiro \n"
-"Language-Team: Portuguese <>\n"
+"PO-Revision-Date: 2017-07-29 17:05+0200\n"
+"Last-Translator: Rui Branco - DebianPT \n"
+"Language-Team: Portuguese \n"
 "Language: pt\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: Lokalize 2.0\n"
 
 #. Type: boolean
 #. Description
@@ -94,14 +94,12 @@ msgid ""
 "The default location /etc/grid-security/certificates should work fine in "
 "most cases."
 msgstr ""
-"A localização predefinida /etc/grid-security/certificates deverá funcionar "
-"bem na maioria dos casos."
+"O local por predefinição /etc/grid-security/certificates deverá funcionar "
+"correctamente na maior parte dos casos."
 
 #. Type: string
 #. Description
 #: ../templates.in:5001
 msgid "An alternative location can be given here if needed."
-msgstr ""
-"Pode ser fornecida aqui uma localização alternativa se tal for necessário."
-
+msgstr "Um local alternativo pode ser fornecido se necessário."
 

Bug#861378: Disable debian-chinese-b...@lists.debian.org list

[林上智]

CZ,

I agree with that.

Thanks for your effort.

--

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

*Debian Developer*, debian.org.tw Administrator

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


2017-07-29 22:38 GMT+08:00 Kan-Ru Chen :

> On Sat, Jul 29, 2017, at 10:32 PM, ChangZhuo Chen (陳昌倬) wrote:
> >
> > Hi All,
> >
> > I would like to propose to disable debian-chinese-b...@lists.debian.org
> > for the following reasons:
> >
> > * For Chinese translation related discuss, we already have
> >   debian-l10n-chinese@l.d.o
> >
> > * For Debian user in Taiwan, A new list debian-dug-taiwan has been
> >   requested (#847950).
> >
> > * Big5 encoding is deprecated long time ago.
> >
> >
> > Please raise your concern if you think we shall keep
> > debian-chinese-big5@l.d.o.
>
> Thanks for bringing this up!
>
> I concur we can decommission the debian-chinese-big5 list.
>
> Kanru
>
> > --
> > ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
> > http://czchen.info/
> > Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B
>