Bug#905125: RM: xul-ext-monkeysphere -- ROM; broken, unsupported upstream

[Daniel Kahn Gillmor]

Package: ftp.debian.org
Severity: normal
Control: affects -1 src:xul-ext-monkeysphere

xul-ext-monkeysphere has not worked with a current version of firefox
for quite some time.

I was at one point upstream for it, but have not had time to keep up
with the pace of the changing firefox api.

I spoke with Jameson Rollins, debian maintainer for the package, and
he also doesn't have the time to keep it patched.

So we'd both like to have this package removed from debian.

Thanks!

Regards,

--dkg

Bug#905126: www.debian.org: Website search box unhelpful for common names (e.g. Buster) in certain character sets

[Jonathan Wiltshire]

Package: www.debian.org
Severity: normal

A number of search languages end up with no results for contextually
common search terms, for example "debian" or "buster".

To reproduce:
 - use the search box for the term "buster" in English. There are a
   number of results including release information, news items and
   errata.
 - set the language to Vietnamese, Chinese or similar and search again
 - there are no results.

I assume that this is an issue with translations into non-Latin
character sets without hint words nearby the translated word.

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

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

Bug#904609: mandelbulber2: Fractal ui file can't be loaded

[Claude Heiland-Allen]

Hi,

On 31/07/18 14:14, Giovanni Mascellani wrote:

tags 904609 + unreproducible moreinfo
thanks

Hi,

thanks for the report. Unfortunately I cannot reproduce it.


Thanks for your reply!

I found the problem.  It was user error on my part.  I had a 
self-compiled ~/opt/bin/mandelbulber2 earlier in my PATH (I guess it is 
a separate upstream bug that it tries to access files outside of its 
installed prefix).  Using /usr/bin/mandelbulber2 (or modifying PATH to 
remove ~/opt/bin) works correctly.  Sorry for wasting your time!



Il 25/07/2018 18:32, Claude Heiland-Allen ha scritto:

Error message:

Fractal ui file can't be loaded
/usr/share/mandelbulber2/formula/ui/amazing_surf_mod2.ui

* What outcome did you expect instead?

For it to load the UI from
/usr/share/mandelbulber2/formula/ui/fractal_amazing_surf_mod2.ui

Or for the latter file to be in the initial location.

I see not error messages and the Amazing Surf Mod2 formula loads
correctly. Could you please provide a settings file that fails loading?

Also, could you try to remove or rename the directories "mandelbulber"
and ".mandelbulber" in your home directory and try again? Maybe there
was some leftover from past versions.

Giovanni.


Claude

Bug#905073: RFS: golang-github-frankban-quicktest/1.0.0-1 [ITP]

[Shengjing Zhu]

X-Debbugs-CC: debian...@lists.debian.org

Hi Go team,

Here is 
https://salsa.debian.org/go-team/packages/golang-github-frankban-quicktest
PS, haven't run dch -r yet

Helping nodens for packaging lxd at debconf :)


-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#905075: RFS: golang-github-juju-collections/0.0~git20180717.9be91dc-1 [ITP]

[Shengjing Zhu]

X-Debbugs-CC: debian...@lists.debian.org

Hi Go team,

Here is https://salsa.debian.org/go-team/packages/golang-github-juju-collections
PS, haven't run dch -r yet

Helping nodens for packaging lxd at debconf :)

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#905074: RFS: golang-github-canonicalltd-raft-test/0.0~git20180628.c3345b5-1 [ITP]

[Shengjing Zhu]

X-Debbugs-CC: debian...@lists.debian.org

Hi Go team,

Here is 
https://salsa.debian.org/go-team/packages/golang-github-canonicalltd-raft-test
PS, haven't run dch -r yet

Helping nodens for packaging lxd at debconf :)

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Clément Hermann]

Hi,

On 31/07/2018 17:28, Free Ekanayaka wrote:
> Hello Clement,
> 
> dqlite upstream and LXD team member here.
> 
> Please note that dqlite is going through a bit of change, which I
> started to merge yesterday. So a few of the ITPs you have filed will no
> longer make sense.

Thanks a lot for the heads up!

> In a nutshell:
> 
> 1) https://github.com/CanonicalLtd/dqlite is now a C project
> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings
> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore
> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore
> 
> This will all be effective starting with LXD 3.4, to be released in 3
> weeks.
> 
> In LXD master, this will be effective once we land:
> 
> https://github.com/lxc/lxd/pull/4854
> 
> which should happen today or tomorrow at latest.

Good to know! I guess this won't change anything for 3.0.x series ?
That's what we're aiming for, since we want to package the LTS version:
the users needing cutting-edge version should use the snap IMO.

Cheers,

Bug#874973: [kprinter4] Future Qt4 removal from Buster

[Michael Banck]

tags 874973 +patch
thanks

Hi,

Am Sonntag, den 29.07.2018, 16:55 +0800 schrieb Boyuan Yang:
> I noticed that you are listed as the maintainer and uploader for Debian 
> package kprinter4 [1] and Marco is also the upstream author for kprinter4. As 
> you might already know, we intend to remove Qt4 and its reverse dependencies 
> from Debian.
> 
> It seems that kprinter4 has stopped development since 2014 and there's no 
> sign 
> of porting to Qt5. I'm wondering if you will pick up this software and port 
> it 
> to Qt5 or if there's already a Qt5 counterpart around. If none of those will 
> happen, kprinter4 will have to be removed from Debian eventually together 
> with 
> Qt4.
> 
> Please feel free to share your idea about the future of kprinter4 in Debian. 
> I 
> will submit a Removal bug to have the package removed 31 days later if 
> there's 
> no reply.

Marco pointed me at https://phabricator.kde.org/D9341 which is a review
request of Michael Weghorn's qt5Port branch from gitlab:

https://gitlab.com/michaelweghorn/kprinter4/tree/michaelweghorn/qt5Port

I have now integrated that into the kprinter4 packaging, and after
adjusting Build-Depends it built fine. However, I don't run KDE5 right
now, so can't test it. If somebody running KDE5 could run a smoke-test
on it that would be appreciated, I'v uploaded the package (along with
the source package here):

https://share.credativ.com/~mba/.packages/


Thanks,

Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.ba...@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

Bug#905056: libboost-numpy1.67-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/libboost_numpy*.so -> libboost_numpy*.so.1.67.0

[Giovanni Mascellani]

tags 905056 + pending
thanks

Hi, thanks for the report.

Il 31/07/2018 02:21, Andreas Beckmann ha scritto:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.

I believe the symlink is correct, but libboost-numpy1.67-dev does not
depend on libboost-numpy1.67, which contains the files pointed by the
symlinks. I pushed a patch the fixes the dependency in the repository.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#905127: ITP: python-freetype -- Python bindings for the FreeType library

[Bastian Germann]

Package: wnpp
Severity: wishlist
Owner: Bastian Germann 

Version 2.0.0 is out and I would like to package it.
It would be my first Debian package. According to the Debian Mentor's FAQ I
would have to upload a package version and then file a RFS.

Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Free Ekanayaka]

Hey,

I would think that Stéphane will want to backport these changes to the
3.0.x series, as they improve performance considereably. It wouldn't be
a big change for the LXD code itself, since this is mostly "backend"
code.

I'll Stéphane say the last workd tho.

Thanks for the initiative, looking forward to see LXD in Debian!

Free

Clément Hermann  writes:

> Hi,
>
> On 31/07/2018 17:28, Free Ekanayaka wrote:
>> Hello Clement,
>> 
>> dqlite upstream and LXD team member here.
>> 
>> Please note that dqlite is going through a bit of change, which I
>> started to merge yesterday. So a few of the ITPs you have filed will no
>> longer make sense.
>
> Thanks a lot for the heads up!
>
>> In a nutshell:
>> 
>> 1) https://github.com/CanonicalLtd/dqlite is now a C project
>> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings
>> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore
>> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore
>> 
>> This will all be effective starting with LXD 3.4, to be released in 3
>> weeks.
>> 
>> In LXD master, this will be effective once we land:
>> 
>> https://github.com/lxc/lxd/pull/4854
>> 
>> which should happen today or tomorrow at latest.
>
> Good to know! I guess this won't change anything for 3.0.x series ?
> That's what we're aiming for, since we want to package the LTS version:
> the users needing cutting-edge version should use the snap IMO.
>
> Cheers,

Bug#905128: ITP: libbson-xs-perl -- Perl XS implementation of MongoDB's BSON serialization

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libbson-xs-perl
  Version : 0.4.3
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/BSON-XS
* License : Apache-2.0
  Programming Lang: Perl
  Description : Perl XS implementation of MongoDB's BSON serialization

The BSON class implements a BSON encoder/decoder ("codec"). It consumes
"documents" (typically hash references) and emits BSON strings and vice versa
in accordance with the BSON Specification (http://bsonspec.org).

BSON is the primary data representation for MongoDB. While this module has
several features that support MongoDB-specific needs and conventions, it can
be used as a standalone serialization format.

This module contains an XS implementation for BSON encoding and decoding.
There is no public API. Use the BSON module and it will choose the best
implementation for you.

This module will be recommended by libmongodb-perl

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#905098: ledgersmb: [l10n:cs] Updated Czech PO debconf template translation

[Robert J. Clay]

On Tue, Jul 31, 2018 at 7:05 AM Michal Simunek  wrote:
> Dear Maintainer,
>
> In attachment there is updated Czech translation of PO debconf template 
> (cs.po)
> for package ledgersmb, please include it.

This is to advise that I have imported the new version of the cs.po
file into the package git repository and the update will be included
with the next package
release.


-- 
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us

Bug#905130: hedgewars: FTBFS on armhf (tests fails)

[Lisandro Damián Nicanor Pérez Meyer]

Source: hedgewars
Version: 0.9.24.1-dfsg-4
Severity: serious
Justification: FTBFS

Hi! durent the ongoing Qt transition your package FTBFS on armhf due to tests 
failures.

5/7 Test #1: drillrockets_boom.lua    Passed8.23 sec
6/7 Test #2: drillrockets_drill.lua ...   Passed   14.54 sec
7/7 Test #7: twothousandmines.lua .   Passed   82.14 sec

86% tests passed, 1 tests failed out of 7

Total Test time (real) =  84.47 sec

The following tests FAILED:
  6 - stuckcake.lua (Failed)
Errors while running CTest
make[1]: *** [Makefile:144: test] Error 8
make[1]: Leaving directory '/<>/obj-arm-linux-gnueabihf'
dh_auto_test: cd obj-arm-linux-gnueabihf && make -j4 test ARGS\+=-j4 returned 
exit code 2
make: *** [debian/rules:4: build-arch] Error 2

Regards, Lisandro.


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#905017: [workaround] Frozen display issue

[Carsten Schoenert]

Hello Julien,

On Mon, Jul 30, 2018 at 06:52:07PM +0200, Julien Puydt wrote:
> Package: thunderbird
> Version: 1:52.9.1-1
> Severity: grave
> 
> Launching thunderbird, my display would get half-frozen : only the mouse
> pointer was still moving, and changing (arrow, hand, etc) when it
> hovered over different things. I think I could still move windows
> around, because I could see it change when I take a window further (a
> hand), and then the places where it turned into arrows to resize a
> window border ( ->| ) seemed to correspond. I also could hear the sound
> event of an incoming mail. But I didn't see the window actually moving,
> I couldn't see when I click on a background icon, nor did panels spring
> out when I moved the pointer to the side of the screen.
> 
> It was the only program showing the problem ; I had to go to the
> console and restart lxdm to launch a new session!
> 
> I'm using the past tense : installing lightning made things work again.
> I had the idea to install it because I tried to get as much information
> as I could, tried to understand what could make it fail that didn't
> concern firefox...
> 
> It also happened with 1:60.0~b10-1.
...

unfortunately all the interesting things are missing or could only be
figured out partially from the the deep of your report. Do you have used
reportbug to create this report?

Which DE you are using? You mentioned lxdm shortly, but this is a display
manager so we still don't know what environment you exactly using.

Given the version of TB I assume you are running testing or unstable.
Could you please elaborate a bit more?

Regards
Carsten

Bug#759428: [installation-guide] non-US is no longer existing, so there is also no "export-restricted" software

[Ben Hutchings]

On Tue, 2018-07-31 at 11:00 +0200, Holger Wansing wrote:
> Hi,
> 
> Ben Hutchings  wrote:
[...]
> > I agree that this should be changed.  However I think that the wording
> > "standard versions" also relates to there being unrestricted (standard)
> > and non-US versions of some packages.
> > 
> > Perhaps "standard versions" could be changed to something like "the
> > &debian; system".
> 
> So, that could look like this:
> 
> 
> 
> diff --git a/en/post-install/orientation.xml b/en/post-install/orientation.xml
> index 0ec05037f..f3eb00bee 100644
> --- a/en/post-install/orientation.xml
> +++ b/en/post-install/orientation.xml
> @@ -59,10 +59,13 @@ around this by putting packages on hold in
>  
>  
>  One of the best installation methods is apt. You can use the command
> -line version of apt or full-screen text version
> -aptitude.  Note apt will also let you merge
> -main, contrib, and non-free so you can have export-restricted packages
> -as well as standard versions.
> +line version of apt as well as tools like
> +aptitude or synaptic
> +(which are just graphical frontends for apt).
> +Note that apt will also let you merge
> +main, contrib, and non-free so you can have restricted packages
> +(strictly spoken not belonging to &debian;) as well as packages from
> +&debian-gnu; at the same time.
>  
>  
>

Looks good to me.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#905129: im-config: Wrongly run shell scripts with user's shell interpreter, raises error with zsh

[Boyuan Yang]

Package: im-config
Severity: important
Version: 0.30-1
X-Debbugs-CC: os...@debian.org

Hi Osamu and debian-input-method team members,

TL;DR: file /etc/X11/Xsession.d/70im-config_launch is *not* called by /bin/sh,
as written in shabang; it is called by user's shell interpreter
instead, which may
result in unexpected outcome when user's default shell is neither
/bin/dash nor /bin/bash.

How to confirm that 70im-config_launch is not using "/bin/sh"


1. Add a single line at l13:
logger "im-config: WARNING: Currently the shell is ${SHELL}..."
2. Reboot, login and examine syslog. ${SHELL} is replaced by user
shell interpreter. If the user is using zsh, it will show "/usr/bin/zsh", which
is highly undesired.

Zsh-incompatible shell grammar in im-config shell snippet
==

In file /usr/share/im-config/data/21_ibus.rc:

GTK_IM_MODULE=xim
# use immodule only when available for both GTK 2.0 and 3.0
IM_CONFIG_MARKER2=0
for IM_CONFIG_MARKER in /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
/usr/lib/gtk-2.0/*/immodules/im-ibus.so ; do
if [ -e $IM_CONFIG_MARKER ]; then
IM_CONFIG_MARKER2=1
break
fi
done

Zsh does not accept the for statement, since on current unstable system
/usr/lib/gtk-2.0/*/immodules/im-ibus.so matches nothing. Zsh would fail here
while Bash and dash ignore the unmatched string.

Solution
===

While the zsh-incompatible grammar can be fixed (perhaps with a thorough
examination of all im-config source code), the problem that
Xsession.d scripts are executed by user shell interpreter is a big problem
and should receive further examination.

--
Regards,
Boyuan Yang

Bug#905131: dde-qt5integration: FTBFS on amd64 and mipsel

[Lisandro Damián Nicanor Pérez Meyer]

Source: dde-qt5integration
Version: 0.3.0-2
Severity: serious
Justification: FTBFS

Hi! During the ongoing Qt transition your package FTBFS on at least amd64 and 
mipsel.

It seems that it can not find local headers, which is strange.

Please take a look whenever possible.

Kinds regards, Lisandro.

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#905132: kmail doesn't show body of mails with qt5.11

[Reinhard Karcher]

Package: kmail
Version: 4:17.12.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
   Upgrading kdepim to 4:17.12.3-1, and some libkf5akonadi* packages

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

   * What was the outcome of this action?
   The body of all mails (new and old) are empty

   * What outcome did you expect instead?
   To able able to read my mails




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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:17.12.3-3
ii  kdepim-runtime   4:17.12.3-2
ii  kio  5.47.0-1
ii  libc62.27-5
ii  libgcc1  1:8.2.0-1
ii  libgpgmepp6  1.11.1-1
ii  libkf5akonadiagentbase5  4:17.12.3-3
ii  libkf5akonadicontact54:17.12.3-2
ii  libkf5akonadicore5abi1   4:17.12.3-3
ii  libkf5akonadimime5   4:17.12.3-1
ii  libkf5akonadisearch-bin  4:17.12.3-1
ii  libkf5akonadisearch-plugins  4:17.12.3-1
ii  libkf5akonadisearchdebug54:17.12.3-1
ii  libkf5akonadisearchpim5  4:17.12.3-1
ii  libkf5akonadiwidgets5abi14:17.12.3-3
ii  libkf5bookmarks5 5.47.0-1
ii  libkf5calendarcore5abi1  4:17.12.3-1
ii  libkf5calendarutils5 4:17.12.3-1
ii  libkf5codecs55.47.0-1
ii  libkf5completion55.47.0-1
ii  libkf5configcore55.47.0-1
ii  libkf5configgui5 5.47.0-1
ii  libkf5configwidgets5 5.47.0-1
ii  libkf5contacts5  4:17.12.3-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5dbusaddons55.47.0-1
ii  libkf5followupreminder5  4:17.12.3-1
ii  libkf5grantleetheme-plugins  17.12.3-1
ii  libkf5gravatar5abi1  4:17.12.3-1
ii  libkf5guiaddons5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5iconthemes55.47.0-1
ii  libkf5identitymanagement517.12.3-1
ii  libkf5itemmodels55.47.0-1
ii  libkf5itemviews5 5.47.0-1
ii  libkf5jobwidgets55.47.0-1
ii  libkf5kcmutils5  5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiofilewidgets55.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5kontactinterface5  17.12.3-1
ii  libkf5ksieveui5  4:17.12.3-1
ii  libkf5libkdepim-plugins  4:17.12.3-1
ii  libkf5libkdepim5 4:17.12.3-1
ii  libkf5libkdepimakonadi5  4:17.12.3-1
ii  libkf5libkleo5   4:17.12.3-2
ii  libkf5mailcommon5abi14:17.12.3-1
ii  libkf5mailtransport5 17.12.3-1
ii  libkf5mailtransportakonadi5  17.12.3-1
ii  libkf5messagecomposer5   4:17.12.3-1
ii  libkf5messagecore5   4:17.12.3-1
ii  libkf5messagelist5   4:17.12.3-1
ii  libkf5messageviewer5 4:17.12.3-1
ii  libkf5mime5abi1  17.12.3-2
ii  libkf5mimetreeparser54:17.12.3-1
ii  libkf5notifications5 5.47.0-1
ii  libkf5notifyconfig5  5.47.0-1
ii  libkf5parts5 5.47.0-1
ii  libkf5pimcommon5abi1 4:17.12.3-1
ii  libkf5pimcommonakonadi5  4:17.12.3-1
ii  libkf5pimtextedit5abi1   17.12.3-2
ii  libkf5sendlater5 4:17.12.3-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5sonnetui5  5.47.0-1
ii  libkf5templateparser54:17.12.3-1
ii  libkf5textwidgets5   5.47.0-1
ii  libkf5tnef5  4:17.12.3-1
ii  libkf5wallet-bin 5.47.0-1
ii  libkf5wallet55.47.0-1
ii  libkf5webengineviewer5   4:17.12.3-1
ii  libkf5widgetsaddons5 5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
ii  libkf5xmlgui55.47.0-1+b1
ii  libqgpgme7   1.11.1-1
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libqt5network5   5.11.1+dfsg-6
ii  libqt5widgets5   5.11.1+dfsg-6
ii  libqt5xml5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-1

Versions of packages kmail recommends:
ii  accountwizard   4:17.12.3-1
ii  gnupg   2.2.9-1
ii  kdepim-addons   17.12.3-2
ii  kdepim-themeeditors 4:17.12.3-1
ii  mbox-importer   4:17.12.3-1
ii  pim-data-exporter   4:17.12.3-1
ii  pim-sieve-editor4:17.12.3-

Bug#756859: installation-guide: USB boot

[Ben Hutchings]

On Tue, 2018-07-31 at 10:40 +0200, Holger Wansing wrote:
> Hi,
> 
> Ben Hutchings  wrote:
> > Please remove all the text about USB-ZIP.  Zip drives have been
> > obsolete for over 10 years and I think only very old BIOS versions will
> > expect that kind of partition table in USB storage devices.  This text
> > is more likely to confuse people than to be useful.
> 
> Done. Updated patch is attached.
> 
> 
> 
> diff --git a/en/howto/installation-howto.xml b/en/howto/installation-howto.xml
> index ff8a74184..f2afb5c3b 100644
> --- a/en/howto/installation-howto.xml
> +++ b/en/howto/installation-howto.xml
> @@ -162,8 +162,9 @@ sticks. For details, see  />.
>  
>  
>  Some BIOSes can boot USB storage directly, and some cannot. You may need to
> -configure your BIOS to boot from a removable drive or even a
> -USB-ZIP to get it to boot from the USB device. For helpful
> +configure your BIOS to enable USB legacy support. The boot 
> device
> +selection menu should show removable drive or 
> USB-HDD
> +to get it to boot from the USB device. For helpful
>  hints and details, see .
>  
>  
> 
> diff --git a/en/preparing/bios-setup/i386.xml 
> b/en/preparing/bios-setup/i386.xml
> index 4c50c1e2c..73f29271d 100644
> --- a/en/preparing/bios-setup/i386.xml
> +++ b/en/preparing/bios-setup/i386.xml
> @@ -67,6 +67,7 @@ In particular if you use an isohybrid CD/DVD image on a USB 
> stick
>  (see ), changing the device type to
>  USB CDROM helps on some BIOSes which will not boot from a USB 
> stick in 
>  USB harddisk mode.
> +You may need to configure your BIOS to enable USB legacy 
> support.
>  
>   
> 

Looks good to me.

(Though both these sections seem to need major work to talk about UEFI
as well as BIOS.  Oddly there doesn't seem to be a bug report covering
that.)

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#902263: Filling FTBFS bugs

[Lisandro Damián Nicanor Pérez Meyer]

block 902263 by 905130
block 902263 by 905131
thanks

I have filled the above bugs against hedgewars and dde-qt5integration. There 
is also libfm-qt FTBFS due to symbols changes, but the maintainer is aware and 
that should get fixed today.

Reagrds, Lisandro.

-- 
El futuro es WIN95 A no ser que hagamos algo a tiempo.

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#905133: RFP: libnginx-mod-pagespeed -- ngx_pagespeed

[Sam Bull]

Package: wnpp
Severity: wishlist

* Package name: libnginx-mod-pagespeed
  Version : 1.0.0
  Upstream Author : Pagespeed
* URL : https://www.modpagespeed.com/
* License : Apache
  Programming Lang: C
  Description : ngx_pagespeed

Instructions:
https://www.modpagespeed.com/doc/build_ngx_pagespeed_from_source

Bug#905134: ITP: libcoap2 -- C-Implementation of CoAP, API version 2

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: libcoap2
  Version : 4.2.0alpha
  Upstream Author : Olaf Bergmann 
* URL : https://libcoap.net
* License : BSD-2-clause
  Programming Lang: C
  Description : C-Implementation of CoAP, API version 2

Lightweight application-protocol for devices that are constrained their
resources such as computing power, RF range, memory, bandwidth, or
network packet sizes. This protocol, CoAP, is developed in the IETF
working group "CoRE",  and was standardized in RFC
7252. 

The existing libcoap package in the archive isn't able to use
any cryptography features. libcoap2 will provide an updated library
which also provides encryption based on the library libssl1.1. It's
planned to also support encryption based on GnuTLS at a later time. A
first RC is expected to be released soon.

The resulting upstream modifications to libcoap are not backwards
compatible. To keep the existing library coinstallable with the current
version I want to package the newest version within a separate source
package.

The packaging will be done within the IoT packaging group as a team
managed package.

Regards
Carsten

Bug#905135: task-kde-desktop is not installable

[Thue]

Package: task-kde-desktop
Severity: important

Dear Maintainer,
I get this error when trying to install task-kde-desktop on a fully updated 
Debian Sid system:

t@h ~> sudo apt-get install task-kde-desktop
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 task-kde-desktop : Depends: kde-standard but it is not going to be installed
Recommends: kdeaccessibility but it is not going to be 
installed
Recommends: k3b but it is not going to be installed
Recommends: k3b-i18n but it is not going to be installed
Recommends: plasma-nm but it is not going to be installed
Recommends: apper but it is not going to be installed
Recommends: dragonplayer but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
t@h ~>

Regards, Thue

*** 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 unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages task-kde-desktop depends on:
pn  kde-standard  
ii  sddm  0.18.0-1
ii  task-desktop  3.44
ii  tasksel   3.44

Versions of packages task-kde-desktop recommends:
pn  apper   
pn  dragonplayer
ii  gimp2.10.2-1
ii  hunspell-en-us  1:2018.04.16-1
ii  hyphen-en-us2.8.8-5
pn  k3b 
pn  k3b-i18n
pn  kdeaccessibility
ii  kdesudo 3.4.2.4-2+b1
ii  libreoffice 1:6.1.0~rc2-3
pn  libreoffice-help-en-us  
ii  mythes-en-us1:6.0.5-1
ii  orca3.28.1-2
pn  plasma-nm   
ii  system-config-printer   1.5.11-2

task-kde-desktop suggests no packages.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Guillem Jover]

Hi Gunnar,

On Mon, 2018-07-30 at 00:14:23 -0500, Gunnar Wolf wrote:
> Still, I would like to have Guillem's opinion.

Sorry, but I'd rather not participate in the processes I very strongly
disagree with, for a body I don't think should even exist.

Thanks,
Guillem

Bug#905136: RFP: libnginx-mod-security -- Nginx ModSecurity

[Sam Bull]

Package: wnpp
Severity: wishlist

* Package name: libnginx-mod-security
  Version : 3.0.0
  Upstream Author : Nginx 
* URL : https://www.nginx.com/
* License : BSD
  Programming Lang: C
  Description : Nginx ModSecurity

Some instructions on setting this up:
https://www.nginx.com/blog/compiling-and-installing-modsecurity-for-open-source-nginx/

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

Hi,

On Mon, 30 Jul 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> You might want to consider suscribing to pkg-kde-talk@a-l.d.n (CCed), it's a 
> *very low* traffic mailing list in which we coordinate some stuff.

Done.

> reason and time proved us to be right as many came in asking for it. Please 
> consider removing this meta packages in your next upload.

Done. We kept them because they were present in pyside 1. But we don't
need them.

> - Looking at https://buildd.debian.org/status/package.php?p=pyside2 you might 
> want to limit the qtwebengine5-dev to the archs in which it builts. If 
> pyside2 
> build system works like pyqt then the related packages will not get built on 
> those archs. Yes, this needs an arch list in the related binary packages too.

Done.

> - Looking at debian/control pyside2-tools seems to ship pyside2-uic, but 
> python[3]-pyside2uic too. This is confusing :-/

Hum, our goal was to make the tools use python3 but I see that upstream
seems to use python 2 so we fixed the dependencies to use the python 2
version of the module.

Thanks for your review. I uploaded a new version with all those
improvements and a few more (fixing an RC bug!).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature

Bug#905030: lintian: please verify debian/tests/control contains more tests than "Test-Command: /bin/true"

[Chris Lamb]

Hi Paul,

> Rather unconstructively, they refuse to fix it until lintian has the
> warning [2].

That seems.. strange. At the very least, Lintian is not Policy.

Unrelated to the above, do you feel there any real fear that a /bin/
true would simply be replaced with something else if a maintainer saw
this tag?  There are, of course, plenty of no-op commands available in
the base system... :)


Best wishes,

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

Bug#905137: RFP: libnginx-mod-http-limit-conn -- Nginx Limit Connections module

[Sam Bull]

Package: wnpp
Severity: wishlist

* Package name: libnginx-mod-http-limit-conn
  Version : 1.0.0
  Upstream Author : Nginx 
* URL : https://www.nginx.com/
* License : BSD
  Programming Lang: C
  Description : Nginx Limit Connections module

http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

Bug#905135: task-kde-desktop is not installable

[Ben Hutchings]

Control: tag -1 unreproducible moreinfo

On Tue, 2018-07-31 at 16:40 +0200, Thue wrote:
> Package: task-kde-desktop
> Severity: important
> 
> Dear Maintainer,
> I get this error when trying to install task-kde-desktop on a fully updated 
> Debian Sid system:
> 
> t@h ~> sudo apt-get install task-kde-desktop
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  task-kde-desktop : Depends: kde-standard but it is not going to be installed
> Recommends: kdeaccessibility but it is not going to be 
> installed
> Recommends: k3b but it is not going to be installed
> Recommends: k3b-i18n but it is not going to be installed
> Recommends: plasma-nm but it is not going to be installed
> Recommends: apper but it is not going to be installed
> Recommends: dragonplayer but it is not going to be 
> installed
> E: Unable to correct problems, you have held broken packages.
> t@h ~>

Looks fine to me:

# apt install task-kde-desktop
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  adwaita-icon-theme akonadi-backend-mysql akonadi-contacts-data
  akonadi-mime-data akonadi-server akregator ark aspell aspell-en baloo-kf5
  breeze breeze-cursor-theme breeze-icon-theme bsdmainutils ca-certificates
[...]
  xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-nouveau
  xserver-xorg-video-radeon xserver-xorg-video-vesa xserver-xorg-video-vmware
  xterm
Suggested packages:
  akonadi-backend-postgresql akonadi-backend-sqlite rar unrar | unrar-free
  aspell-doc spellutils orion-gtk-theme wamerican | wordlist whois vacation tk
  | wish wordlist pinentry-gnome3 tor docbook docbook-dsssl docbook-defguide
[...]
  libblockdev-crypto2 ntfs-3g libfile-mimeinfo-perl libnet-dbus-perl
  libx11-protocol-perl xserver-xorg-legacy xserver-xorg-input-wacom
  xserver-xorg-video-intel xserver-xorg-video-qxl
The following NEW packages will be installed:
  adwaita-icon-theme akonadi-backend-mysql akonadi-contacts-data
  akonadi-mime-data akonadi-server akregator ark aspell aspell-en baloo-kf5
  breeze breeze-cursor-theme breeze-icon-theme bsdmainutils ca-certificates
[...]
  xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-nouveau
  xserver-xorg-video-radeon xserver-xorg-video-vesa xserver-xorg-video-vmware
  xterm
0 upgraded, 1004 newly installed, 0 to remove and 36 not upgraded.
Need to get 506 MB/532 MB of archives.
After this operation, 1953 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

I used httpredir.debian.org (alias for deb.debian.org) as the mirror
hostname.  Perhaps your mirror is out of date?

Or, perhaps you have pinned packages (through /etc/apt/preferences.d)
that prevent the upgrade?

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#905132: kmail doesn't show body of mails with qt5.11

[Reinhard Karcher]

Actually, the problem appeared before I upgraded the akonadi moduls; 
downgrading those moduls didn't help. It started when I upgraded 
qt5.10 -> qt5.11. That happend before the akonadi upgrade.

Reinhard

Bug#905138: cmake: FTBFS on kfreebsd-any

[Svante Signell]

Source: cmake
Version: 3.11.2-1
Severity: important
Tags: patch
Usertags: linux-any, freebsd-any, hurd-any

Hello,

Currently cmake does FTBFs on kfreebsd-any due to a missing dependency
on libfreebsd-glue-0 and a missing dependency on freebsd-glue,
providing the link:
/usr/lib/libfreebsd-glue.so -> /lib/libfreebsd-glue.so.0

Ideally a library libfreebsd-glue-dev should be split out of the
package freebsd-glue. Until that happens, the added dependency will do,
see the attached file debian_control.diff.

With the attached patches bootstrap.patch, debian_control.diff, and the
upcoming bug report on linux-any,providing
Source_Modules_FindLibUV.cmake.diff cmake builds fine. 
Index: cmake-3.11.2/bootstrap
===
--- cmake-3.11.2.orig/bootstrap
+++ cmake-3.11.2/bootstrap
@@ -1352,7 +1352,7 @@ else
   libs="${libs} -ldl -lrt"
   ;;
 *BSD*)
-  libs="${libs} -lkvm"
+  libs="${libs} -lkvm -lfreebsd-glue"
   ;;
 *SunOS*)
   # Normally libuv uses '-D_XOPEN_SOURCE=500 -std=c90' on Solaris 5.10,
--- a/debian/control	2018-05-19 10:51:17.0 +0200
+++ b/debian_control	2018-07-29 17:38:11.272777000 +0200
@@ -15,6 +15,7 @@
librhash-dev,
libuv1-dev (>= 1.10),
procps [!hurd-any],
+   freebsd-glue [kfreebsd-any],
python3-sphinx,
qtbase5-dev ,
zlib1g-dev

Bug#903218:

[PICCA Frederic-Emmanuel]

looking at the fedora project they renames async -> async_

https://koji.fedoraproject.org/koji/buildinfo?buildID=1097515

Bug#902936: fixed in zutils 1.7-2

[Antonio Diaz Diaz]

Dear Ben,

I wrote:
"A double-free bug in zutils' zcat is not probable because zutils' zcat
is a C++ program that does not use neither malloc nor free."

You misquoted me as:
"this bug is impossible in C++!"

Please, don't misquote me.


On Tue, 31 Jul 2018 12:49:32 +0800 Ben Hutchings wrote:

The non-technical problem I see is that your upstream is dismissive of
valid bug reports ("but it's compatible with cat", "this bug is
impossible in C++!"), and that you are agreeing with this nonsense.


I think "valid" does not mean what you think it means.

First, 'zcat -t' is not standardized. Therefore it is not valid to 
expect it to be portable.


Second, a bug report is not valid until the bad code is pointed out or 
until a way to reproduce the failure is provided. Until then the bug may 
be anywhere else. The problem is that in spite of my efforts I have been 
unable to reproduce the problem reported in zutils' zcat. As soon as 
you, or anybody else, provide a way to reproduce the problem, or point 
out the cause of the bug, I'll fix it in 24h. Until then there is not 
much that I can do.


Stephen Kitt, please, could you send me the smallest file (not 
necessarily an initramfs) that causes zcat to crash? Thanks.



Best regards,
Antonio.

Bug#905139: apache-log4j2: FTBFS with Java 10 due to a javadoc bug triggered by static String literals containing angle brackets

[Emmanuel Bourg]

Source: apache-log4j2
Version: 2.10.0-2
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10

apache-log4j2 currently fails to build with Java 10, the build breaks
with the following javadoc error:

  [ERROR] javadoc: error - An internal exception has occurred. 
  [ERROR]   (java.lang.IllegalArgumentException: "")
  [ERROR] Please file a bug against the javadoc tool via the Java bug reporting 
page
  [ERROR] (http://bugreport.java.com) after checking the Bug Database 
(http://bugs.java.com)
  [ERROR] for duplicates. Include error messages and the following diagnostic 
in your report. Thank you.
  [ERROR] java.lang.IllegalArgumentException: ""
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.check(HtmlDocletWriter.java:1306)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getDocLink(HtmlDocletWriter.java:1300)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getDocLink(HtmlDocletWriter.java:1277)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getDocLink(HtmlDocletWriter.java:1260)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.TagletWriterImpl.valueTagOutput(TagletWriterImpl.java:409)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.taglets.ValueTaglet.getTagletOutput(ValueTaglet.java:161)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.taglets.TagletWriter.getInlineTagOutput(TagletWriter.java:274)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter$2.defaultAction(HtmlDocletWriter.java:1921)
  [ERROR]   at 
jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter$2.defaultAction(HtmlDocletWriter.java:1716)
  [ERROR]   at 
jdk.compiler/com.sun.source.util.SimpleDocTreeVisitor.visitValue(SimpleDocTreeVisitor.java:499)


This error is triggered by a static String literal in the CommandLine.java
class:

protected static final String DEFAULT_COMMAND_NAME = "";

It looks like the angle brackets are improperly interpreted as an HTML element.
It's possible to work around this issue by replacing the value with:

protected static final String DEFAULT_COMMAND_NAME = new String("");

Bug#900240: cmake: FTBFS on hurd-i386

[Svante Signell]

retitle 900240 cmake: FTBFS on hurd-i386 due to a PATH_MAX issue 
thanks

Hello,

Currently cmake FTBFS on GNU/Hurd due to a PATH_MAX issue. Attached is
the patch path_max.patch also provided by the first attachment in this
bug #900240, there named path_max.path. With the attached patch and the
upcoming bug report on linux-any, providing
Source_Modules_FindLibUV.cmake.diff cmake builds fine. 

Thanks!Index: cmake-3.11.2/Utilities/cmlibuv/src/unix/fs.c
===
--- cmake-3.11.2.orig/Utilities/cmlibuv/src/unix/fs.c
+++ cmake-3.11.2/Utilities/cmlibuv/src/unix/fs.c
@@ -427,6 +427,7 @@ static ssize_t uv__fs_scandir(uv_fs_t* r
 }
 
 
+#if _POSIX_VERSION < 200809L
 static ssize_t uv__fs_pathmax_size(const char* path) {
   ssize_t pathmax;
 
@@ -442,12 +443,19 @@ static ssize_t uv__fs_pathmax_size(const
 
   return pathmax;
 }
+#endif
 
 static ssize_t uv__fs_readlink(uv_fs_t* req) {
   ssize_t len;
   char* buf;
+  struct stat st;
+  int ret;
 
-  len = uv__fs_pathmax_size(req->path);
+  ret = lstat(req->path, &st);
+  if (ret != 0) {
+return -1;
+  }
+  len = st.st_size;
   buf = uv__malloc(len + 1);
 
   if (buf == NULL) {
@@ -474,9 +482,16 @@ static ssize_t uv__fs_readlink(uv_fs_t*
 }
 
 static ssize_t uv__fs_realpath(uv_fs_t* req) {
-  ssize_t len;
   char* buf;
 
+#if _POSIX_VERSION >= 200809L
+  buf = realpath(req->path, NULL);
+  if (buf == NULL) {
+return -1;
+  }
+#else
+  ssize_t len;
+
   len = uv__fs_pathmax_size(req->path);
   buf = uv__malloc(len + 1);
 
@@ -489,6 +504,7 @@ static ssize_t uv__fs_realpath(uv_fs_t*
 uv__free(buf);
 return -1;
   }
+#endif
 
   req->ptr = buf;
 

Bug#903218: python3-opengl: fails to install with python3.7 installed

[PICCA Frederic-Emmanuel]

looking at the fedora project they renames async -> async_

https://koji.fedoraproject.org/koji/buildinfo?buildID=1097515

Bug#889668: Please install fstrim.timer (but disabled!)

[Philipp Kern]

On 2018-07-31 10:46, Philipp Kern wrote:

On 2018-07-31 09:24, Philipp Kern wrote:

I buy the argument for attached removable file systems. It looks like
today fstrim iterates over /proc/self/mountinfo and trims all
non-pseudo/non-netfs. On the other hand enough guides on the internet
say that to have a working system with an SSD, you want to have TRIM. 
By

not applying the proper defaults, many users will still enable
fstrim.timer and then not think about it when the recovery/forensic 
case

comes along. So this is surprising nonetheless.

It feels like fstrim should have a mode that looks at volumes 
referenced
by /etc/fstab (just like mount -a, that it wanted to mimic according 
to

the code) instead of the currently mounted filesystems. And then we
actually should enable that by default.


I filed https://github.com/karelzak/util-linux/issues/673 upstream 
about this.


And the amazing util-linux upstream author Karel already fixed it in 
https://github.com/karelzak/util-linux/commit/c5b8909f13d29d066ee9882fe0e3129d2f3bcffc 
and now provides an -A option that just looks at fstab. I guess I'll go 
and file a separate bug once that's in a release to make that enabled by 
default.


Kind regards
Philipp Kern

Bug#903218:

[PICCA Frederic-Emmanuel]

In code search I found another package affected by this problem.
Which seems to embed pyOpenGL.

https://codesearch.debian.net/search?q=OpenGL.raw.GL.SGIX.async&perpkg=1

Cheers

Bug#905017: [workaround] Frozen display issue

[Julien Puydt]

Hi,

Le 31/07/2018 à 16:23, Carsten Schoenert a écrit :

Hello Julien,
unfortunately all the interesting things are missing or could only be
figured out partially from the the deep of your report. Do you have used
reportbug to create this report?


I never use reportbug, as I find it a pain to use.


Which DE you are using? You mentioned lxdm shortly, but this is a display
manager so we still don't know what environment you exactly using.


I'm using lxde, so gtk+2-based


Given the version of TB I assume you are running testing or unstable.
Could you please elaborate a bit more?


Yes, I'm running unstable.

I don't know exactly what information you might need : I don't really 
understand the problem.


Have you tried installing&activating lightning, then uninstalling it, to 
see if starting TB afterwards gave you the same symptoms?


jpuydt on irc.debian.org

Bug#905140: cmake: FTBFS with recent version of libuv1

[Svante Signell]

Source: cmake
Version: 3.11.2-1
Severity: serious
Tags: patch
Usertags: linux-any, freebsd-any, hurd-any

Hello,

cmake FTBFS with recent a version of libuv1: 1.22.0-x. The build for
most architectures was made 60+ days ago, then with 1.20.3-x. Since
then two upstream versions was released and the specific change was for
1.21.0:
* core: move all include files except uv.h to uv/ (Saúl Ibarra
Corretgé)

The attached patch, Source_Modules_FindLibUV.cmake.diff, fixes the
build for linux-any architectures by looking for libuv header files in
/usr/include/uv in addition to /usr/include/uv-* headers. This patch
also affects #900240 and #905138 and is needed for successful builds.

Index: cmake-3.11.2/Source/Modules/FindLibUV.cmake
===
--- cmake-3.11.2.orig/Source/Modules/FindLibUV.cmake
+++ cmake-3.11.2/Source/Modules/FindLibUV.cmake
@@ -63,6 +63,8 @@ mark_as_advanced(LibUV_INCLUDE_DIR)
 set(_LibUV_H_REGEX "#[ \t]*define[ \t]+UV_VERSION_(MAJOR|MINOR|PATCH)[ \t]+[0-9]+")
 if(LibUV_INCLUDE_DIR AND EXISTS "${LibUV_INCLUDE_DIR}/uv-version.h")
   file(STRINGS "${LibUV_INCLUDE_DIR}/uv-version.h" _LibUV_H REGEX "${_LibUV_H_REGEX}")
+elseif(LibUV_INCLUDE_DIR AND EXISTS "${LibUV_INCLUDE_DIR}/uv/version.h")
+  file(STRINGS "${LibUV_INCLUDE_DIR}/uv/version.h" _LibUV_H REGEX "${_LibUV_H_REGEX}")
 elseif(LibUV_INCLUDE_DIR AND EXISTS "${LibUV_INCLUDE_DIR}/uv.h")
   file(STRINGS "${LibUV_INCLUDE_DIR}/uv.h" _LibUV_H REGEX "${_LibUV_H_REGEX}")
 else()

Bug#904043: arm: Enable CONFIG_SPI_SPIDEV

[Gunnar Wolf]

Hi,

This bug is being added as several users (me included) have required
this information from the (unofficial) Raspberry Pi Debian "clean"
image.

There is a great number of devices with similar format, allowing for
GPIO communications, that would benefit from having SPIDEV enabled in
our mainline kernel. FWIW, my particular use case (for which I chose
to switch to Raspbian instead) was to flash ROM images.

Thanks for considering this bug as a harmless and easy-to-fulfill
wishlist request!


signature.asc
Description: PGP signature

Bug#905141: apt-transport-https: Mark apt-transport-https as Multi-Arch: foreign

[Ivan Krylov]

Package: apt-transport-https
Version: 1.4.8
Severity: wishlist

Dear Maintainer,

It is probably benefitical to mark apt-transport-https (perhaps other transports
as well) as Multi-Arch: foreign, because they are still useful as a dependency 
even
when requested by a foreign package. Otherwise installing a foreign package 
depening
on apt-transport-https would pull foreign apt and cause problems).

Example use-case: a fairly old but still useable laptop with 2G of RAM and 
mostly-i386
userland but running amd64 kernel. Skype for linux currently requires amd64 and 
depends
on apt-transport-https. With apt-transport-https having Multi-Arch: foreign it's
possible to have i386 version satisfy the dependency of an amd64 package and 
have
64-bit skypeforlinux coexist with everything else.

I've applied the one-line patch and built a custom version of 
apt-transport-https
for myself. It works okay.

(I'm omitting system information because I'm typing this bug report on another 
machine.)

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

Versions of packages apt-transport-https depends on:
ii  libapt-pkg5.01.4.8
ii  libc62.24-11+deb9u3
ii  libcurl3-gnutls  7.52.1-5+deb9u6
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libstdc++6   6.3.0-18+deb9u1

Versions of packages apt-transport-https recommends:
ii  ca-certificates  20161130+nmu1+deb9u1

apt-transport-https suggests no packages.

-- no debconf information

Bug#905135: task-kde-desktop is not installable

[thuejk]

I don't have pinned packages, and my mirror seems up-to-date.

Looking through a troublesome dependency of task-kde-desktop, I get
kde-standard->akregator->libkf5grantleetheme5->libkf5xmlgui5->qtbase-abi-5-10-0

libkf5xmlgui5 from my "apt-cache show" is the same version as the latest at
https://packages.debian.org/sid/libkf5xmlgui5 (5.47.0-1)

According to https://packages.debian.org/sid/qtbase-abi-5-10-0
, qtbase-abi-5-10-0 is a virtual package provided by libqt5core5a.

The version of libqt5core5a from my "apt-cache show" is the same as on
https://packages.debian.org/sid/libqt5core5a (5.11.1+dfsg-6, and is in fact
already installed on my system)

I am confused. libkf5xmlgui5 has some funky architecture-dependent
dependencies on qtbase-abi-5-10-0 vs qtbase-abi-5-11-0; perhaps it has
something to do with that?

Regard, Thue

Den tir. 31. jul. 2018 kl. 16.59 skrev Ben Hutchings :

> Control: tag -1 unreproducible moreinfo
>
> On Tue, 2018-07-31 at 16:40 +0200, Thue wrote:
> > Package: task-kde-desktop
> > Severity: important
> >
> > Dear Maintainer,
> > I get this error when trying to install task-kde-desktop on a fully
> updated Debian Sid system:
> >
> > t@h ~> sudo apt-get install task-kde-desktop
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> >
> > The following packages have unmet dependencies:
> >  task-kde-desktop : Depends: kde-standard but it is not going to be
> installed
> > Recommends: kdeaccessibility but it is not going to
> be installed
> > Recommends: k3b but it is not going to be installed
> > Recommends: k3b-i18n but it is not going to be
> installed
> > Recommends: plasma-nm but it is not going to be
> installed
> > Recommends: apper but it is not going to be installed
> > Recommends: dragonplayer but it is not going to be
> installed
> > E: Unable to correct problems, you have held broken packages.
> > t@h ~>
>
> Looks fine to me:
>
> # apt install task-kde-desktop
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
>   adwaita-icon-theme akonadi-backend-mysql akonadi-contacts-data
>   akonadi-mime-data akonadi-server akregator ark aspell aspell-en baloo-kf5
>   breeze breeze-cursor-theme breeze-icon-theme bsdmainutils ca-certificates
> [...]
>   xserver-xorg-video-ati xserver-xorg-video-fbdev
> xserver-xorg-video-nouveau
>   xserver-xorg-video-radeon xserver-xorg-video-vesa
> xserver-xorg-video-vmware
>   xterm
> Suggested packages:
>   akonadi-backend-postgresql akonadi-backend-sqlite rar unrar | unrar-free
>   aspell-doc spellutils orion-gtk-theme wamerican | wordlist whois
> vacation tk
>   | wish wordlist pinentry-gnome3 tor docbook docbook-dsssl
> docbook-defguide
> [...]
>   libblockdev-crypto2 ntfs-3g libfile-mimeinfo-perl libnet-dbus-perl
>   libx11-protocol-perl xserver-xorg-legacy xserver-xorg-input-wacom
>   xserver-xorg-video-intel xserver-xorg-video-qxl
> The following NEW packages will be installed:
>   adwaita-icon-theme akonadi-backend-mysql akonadi-contacts-data
>   akonadi-mime-data akonadi-server akregator ark aspell aspell-en baloo-kf5
>   breeze breeze-cursor-theme breeze-icon-theme bsdmainutils ca-certificates
> [...]
>   xserver-xorg-video-ati xserver-xorg-video-fbdev
> xserver-xorg-video-nouveau
>   xserver-xorg-video-radeon xserver-xorg-video-vesa
> xserver-xorg-video-vmware
>   xterm
> 0 upgraded, 1004 newly installed, 0 to remove and 36 not upgraded.
> Need to get 506 MB/532 MB of archives.
> After this operation, 1953 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
>
> I used httpredir.debian.org (alias for deb.debian.org) as the mirror
> hostname.  Perhaps your mirror is out of date?
>
> Or, perhaps you have pinned packages (through /etc/apt/preferences.d)
> that prevent the upgrade?
>
> Ben.
>
> --
> Ben Hutchings
> [W]e found...that it wasn't as easy to get programs right as we had
> thought. I realized that a large part of my life from then on was going
> to be spent in finding mistakes in my own programs.
>  - Maurice Wilkes, 1949
>
>

Bug#878337: Remove the package?

[Julien Puydt]

Hi,

is there any hope for this package? At one point node-source-map will 
need to be updated.


For now I have a RC bug on node-source-map to remind me not to update it 
too fast, but it's a bit unfair : the problem doesn't stem from 
node-source-map if node-grunt-contrib-concat is abandoned...


jpuydt on irc.debian.org

Bug#880738: Wrong attachment

[Otto Kekäläinen]

tags - patch + moreinfo

It seems the attached patch is a translation of xz, not MariaDB 10.1 at all.

Bug#905129: im-config: Wrongly run shell scripts with user's shell interpreter, raises error with zsh

[Boyuan Yang]

I also have to point out that I am using KDE + sddm as Display Manager.
It seems that /etc/X11/Xsession file is already called by sddm using
user-specified
shell interpreter. Haven't dug into it further.

--
Regards,
Boyuan Yang

Boyuan Yang <073p...@gmail.com> 于2018年7月31日周二 下午10:33写道：
>
> Package: im-config
> Severity: important
> Version: 0.30-1
> X-Debbugs-CC: os...@debian.org
>
> Hi Osamu and debian-input-method team members,
>
> TL;DR: file /etc/X11/Xsession.d/70im-config_launch is *not* called by /bin/sh,
> as written in shabang; it is called by user's shell interpreter
> instead, which may
> result in unexpected outcome when user's default shell is neither
> /bin/dash nor /bin/bash.
>
> How to confirm that 70im-config_launch is not using "/bin/sh"
> 
>
> 1. Add a single line at l13:
> logger "im-config: WARNING: Currently the shell is ${SHELL}..."
> 2. Reboot, login and examine syslog. ${SHELL} is replaced by user
> shell interpreter. If the user is using zsh, it will show "/usr/bin/zsh", 
> which
> is highly undesired.
>
> Zsh-incompatible shell grammar in im-config shell snippet
> ==
>
> In file /usr/share/im-config/data/21_ibus.rc:
>
> GTK_IM_MODULE=xim
> # use immodule only when available for both GTK 2.0 and 3.0
> IM_CONFIG_MARKER2=0
> for IM_CONFIG_MARKER in /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
> /usr/lib/gtk-2.0/*/immodules/im-ibus.so ; do
> if [ -e $IM_CONFIG_MARKER ]; then
> IM_CONFIG_MARKER2=1
> break
> fi
> done
>
> Zsh does not accept the for statement, since on current unstable system
> /usr/lib/gtk-2.0/*/immodules/im-ibus.so matches nothing. Zsh would fail here
> while Bash and dash ignore the unmatched string.
>
> Solution
> ===
>
> While the zsh-incompatible grammar can be fixed (perhaps with a thorough
> examination of all im-config source code), the problem that
> Xsession.d scripts are executed by user shell interpreter is a big problem
> and should receive further examination.
>
> --
> Regards,
> Boyuan Yang
>

Bug#905017: LXDE: Frozen display issue

[Carsten Schoenert]

On Tue, Jul 31, 2018 at 04:50:08PM +0200, Julien Puydt wrote:
> Hi,
> 
> Le 31/07/2018 à 16:23, Carsten Schoenert a écrit :
> > Hello Julien,
> > unfortunately all the interesting things are missing or could only be
> > figured out partially from the the deep of your report. Do you have used
> > reportbug to create this report?
> 
> I never use reportbug, as I find it a pain to use.

Well, this make the life of the package maintainer harder then as you
not provide much as possible information about the circumstances the
issue(s) happen as reportbug will do.

reportbug now even has a GUI mode and the Debian Wiki is hold several
information about configuration of reportbug.

https://wiki.debian.org/reportbug

I personally use nullmailer as a local pseudo MTA, this isn't all that
hard to configure.

In my opinion reportbug is the best thing to create bug reports. The
website about reporting bugs is holding additional options and
information to report bugs.

https://www.debian.org/Bugs/Reporting

Especially the information about the installed software versions is
really important for my or other people. The following example call is
printing out all the parts reportbug would use.

> $ reportbug -q --template -T none -s none -S normal -b --list-cc none -q 
> thunderbird

...
> > Which DE you are using? You mentioned lxdm shortly, but this is a display
> > manager so we still don't know what environment you exactly using.
> 
> I'm using lxde, so gtk+2-based

So you probably have an issue in the LXDE DE in combination with
Thunderbird.

> > Given the version of TB I assume you are running testing or unstable.
> > Could you please elaborate a bit more?
> 
> Yes, I'm running unstable.
> 
> I don't know exactly what information you might need : I don't really
> understand the problem.

As I don't know what you excatly running or doing. How should I, this is
based on the information from the reporter. How can anybody readjust the
issue then?

> Have you tried installing&activating lightning, then uninstalling it, to see
> if starting TB afterwards gave you the same symptoms?

No, as I don't know what would have to do until now? OTOH I can't test
and will not check all the possible combinations out there and it's
unlikely I will do this for LXDE. LXDE isn't a really common DE so far.

Can you please check if the issue is still happen with disabled
extensions and with a clean new profile?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

The root for the problem can be anythere and before I would asking LXDE
Maintainers we need to be clear the issue isn't within a fishy profil.

Regards
Carsten

Bug#905132: kmail doesn't show body of mails with qt5.11

[Lisandro Damián Nicanor Pérez Meyer]

tag 905132 confirmed
thanks

El martes, 31 de julio de 2018 12:01:55 -03 Reinhard Karcher escribió:
> Actually, the problem appeared before I upgraded the akonadi moduls;
> downgrading those moduls didn't help. It started when I upgraded
> qt5.10 -> qt5.11. That happend before the akonadi upgrade.

Indeed I can reproduce the bug. As a thought workaround replying to the mail 
allows one to see it's original content.

I think upstream might have seen this already, so it would be a matter of 
checking with them.

-- 
Los chicos tienen un mayor dominio de la tecnología (y las habilidades y
lenguaje que eso implica) que los adultos con los que se relacionan. Por lo
general saben más que sus propios padres, sus docentes, sus pediatras,
psicólogos, que los políticos y funcionarios de sus comunidades. Eso afectó la
autoridad que tenía un adulto para habilitar al mundo.
  Luis Pescetti
  http://www.luispescetti.com/regale-su-obra/

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#228692: User/group creation/removal in package maintainer scripts

[Andreas Henriksson]

Hi,

This is my attempt to unlock the progress on this issue.

I'm going to attempt to first collect what I've picked up both from the
previously mentioned mailinglist thread (and other similar ones) and
what I've seen when reviewing maintainerscripts of packages in the
archive. Hopefully others can speak up if they disagree or think I've
missed a common convention. Later we can attempt to formulate a specific
wording for policy.

## common conventions

users/groups should have an "invalid" prefix to avoid clashes with local
users
- sometimes inconvenient to change username and lots of packages doesn't
  do this so should only be recommended when possible, not mandatory.
- Debian- (common, see eg. exim4), D (very rarely used?), and _ (also
  used) are suggested prefix.

previously created users should *not* (ever) be removed
- it's much less rare these days but still some packages removes
  users/groups they created once the package is purged.
- the problem with removing users/groups (reusing uid/gid) is that files
  on filesystem can be owned by them which could lead to possible
  security issue.

packages generally relies on adduser to do the work, which is basically
a wrapper to implement common debian conventions around useradd, but it
might not be policys place to explicitly require using a specific tool
like adduser.

Packages commonly check if user/group already exists before calling
adduser to create them. Reason being quiet switch to adduser makes it
'too quiet'. Might be better if adduser just gets fixed with eg.
implementing a '--exists-ok' argument, than documenting the current
convention in policy so should leave some room open for this.

Possibly policy should document some of the things adduser does, just in
case someone attempts to /not/ use adduser (why?).

Writing manual mantainerscript code should always be avoided, because
it's a common source of bugs. There are also other issues like sharing
the same namespace and now being able to remove them. Thus adding users
and group should be avoided. Sometimes there are mechanisms that allow
that which can be used in more cases than is currently well known, so it
might be good if debian policy explicitly states that people should
avoid adding users/groups when possible. An example of a mechanism that
allows not creating static system users/groups is unit file option
DynamicUser=yes from systemd (and likely many others that I'm not aware
of). For further information see:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=
http://0pointer.net/blog/dynamic-users-with-systemd.html


## example postinst snippet

### Note that packages also needs to depend on adduser!

NEWUSER="_foo"
NEWGROUP="_bar"

if ! getent group "$NEWGROUP" >/dev/null; then
addgroup --force-badname \
--system "$NEWGROUP"
fi

if ! getent passwd "$NEWUSER" >/dev/null; then
adduser --force-badname \
--system --ingroup "$NEWGROUP" \
--home /nonexistent --no-create-home \
"$NEWUSER"
fi


### if username == groupname it can be simplified

NEWUSERGROUP="_foobar"

if ! getent passwd "$NEWUSERGROUP" && ! getent group "$NEWUSERGROUP" 
>/dev/null>/dev/null; then
adduser --force-badname \
--system --group \
--home /nonexistent --no-create-home \
"$NEWUSERGROUP"
fi


--
Regards,
Andreas Henriksson

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

[Paul Gevers]

Hi Florian,

On 30-07-18 23:14, Florian Weimer wrote:
> * Paul Gevers:
>> On 29-07-18 13:26, Florian Weimer wrote:
>>> I'm not sure why it is necessary to build glibc three times (unless
>>> it's impossible to get multi-arch packages into the buildroot).
>>
>> I am not sure if I understand what you mean, but currently having
>> multiple arches available in the autopkgtest testbed isn't supported. I
>> have seen packages try (gnupg2), but this goes easily wrong considering
>> the unstable-to-testing migration setup. If there is a real need for
>> this, it should come from autopkgtest.

> In concrete terms, what I meant was: Why build libc6-i386 on amd64
> when there is a libc6:i386 package as well?

I have no idea.

> In Fedora, there's a restriction that buildds cannot install foreign
> architecture packages.  Some packages need a 32-bit glibc on a 64-bit
> builder, too.  (Typical gcc flags, for example, or fake amd64 packages
> such as amd64).  That made me wonder if Debian has a similar
> restriction for its buildds.

I don't know what the restrictions are on buildds. But autopkgtest
doesn't run on buildds, so I'm not sure if you question is relevant
(unless the above paragraph answers your own question). In autopkgtest
installing foreign architecture packages isn't supported yet as I
mentioned in my previous e-mail.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905129: im-config: Wrongly run shell scripts with user's shell interpreter, raises error with zsh

[Osamu Aoki]

Hi,

On Tue, Jul 31, 2018 at 10:29:11PM +0800, Boyuan Yang wrote:
> Package: im-config
> Severity: important
> Version: 0.30-1
> X-Debbugs-CC: os...@debian.org
> 
> Hi Osamu and debian-input-method team members,
> 
> TL;DR: file /etc/X11/Xsession.d/70im-config_launch is *not* called by /bin/sh,
> as written in shabang; it is called by user's shell interpreter
> instead, which may
> result in unexpected outcome when user's default shell is neither
> /bin/dash nor /bin/bash.

I am aware ... but This is actually problem on how X startup calls in
/etc/X11/Xsession.d/* are called by desktop environment.  It should use
/bin/sh ...

Which which DE do you use?

But this is annoying.  Maybe I should force dash as work around until
alll DE startup codes are fixed.

> 
> Solution
> ===
> 
> While the zsh-incompatible grammar can be fixed (perhaps with a thorough
> examination of all im-config source code), the problem that
> Xsession.d scripts are executed by user shell interpreter is a big problem
> and should receive further examination.

Yes.  Please file bug to DE otherwise you may be breaking other part of
X startup.

Osamu

Bug#905017: LXDE: Frozen display issue

[Julien Puydt]

Hi,

Le 31/07/2018 à 17:40, Carsten Schoenert a écrit :

On Tue, Jul 31, 2018 at 04:50:08PM +0200, Julien Puydt wrote:

Hi,

Le 31/07/2018 à 16:23, Carsten Schoenert a écrit :

Hello Julien,
unfortunately all the interesting things are missing or could only be
figured out partially from the the deep of your report. Do you have used
reportbug to create this report?


I never use reportbug, as I find it a pain to use.


Well, this make the life of the package maintainer harder then as you
not provide much as possible information about the circumstances the
issue(s) happen as reportbug will do.

reportbug now even has a GUI mode and the Debian Wiki is hold several
information about configuration of reportbug.

https://wiki.debian.org/reportbug

I personally use nullmailer as a local pseudo MTA, this isn't all that
hard to configure.

In my opinion reportbug is the best thing to create bug reports. The
website about reporting bugs is holding additional options and
information to report bugs.

https://www.debian.org/Bugs/Reporting

Especially the information about the installed software versions is
really important for my or other people. The following example call is
printing out all the parts reportbug would use.


$ reportbug -q --template -T none -s none -S normal -b --list-cc none -q 
thunderbird


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

Kernel: Linux 4.17.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)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-5
ii  libcairo-gobject2 1.15.10-3
ii  libcairo2 1.15.10-3
ii  libdbus-1-3   1.12.8-3
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-1
ii  libgdk-pixbuf2.0-02.36.12-1
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libpango-1.0-01.42.1-2
ii  libpangocairo-1.0-0   1.42.1-2
ii  libpangoft2-1.0-0 1.42.1-2
ii  libpixman-1-0 0.34.0-2
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-1
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-2
ii  libxcb1   1.13-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
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+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.2-1
ii  lightning1:52.9.1-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13-6
ii  fonts-lyx 2.3.0-2
ii  libgssapi-krb5-2  1.16-2


...

Which DE you are using? You mentioned lxdm shortly, but this is a display
manager so we still don't know what environment you exactly using.


I'm using lxde, so gtk+2-based


So you probably have an issue in the LXDE DE in combination with
Thunderbird.


The fact that it only happens with lightning is part of the things I 
don't get.



Given the version of TB I assume you are running testing or unstable.
Could you please elaborate a bit more?


Yes, I'm running unstable.

I don't know exactly what information you might need : I don't really
understand the problem.


As I don't know what you excatly running or doing. How should I, this is
based on the information from the reporter. How can anybody readjust the
issue then?


Back and forth like we're doing :-)


Have you tried installing&activating lightning, then uninstalling it, to see
if starting TB afterwards gave you the same symptoms?


No, as I don't know what would have to do until now? OTOH I can't test
and will not check all the possible combinations out there and it's
unlikely I will do this for LXDE. LXDE isn't a really common DE so far.

Can you please check if the issue is still happen with disabled
extensions and with a clean new profile?


Something I had tried, before installing lightning, was:
- mv .thunderbird .thunderbird.bak
- thunderbird
and I still had the problem, so  I think a clean new p

Bug#904979: autopkgtest: add option to mark tests as trivial

[Paul Gevers]

Hi Rebecca,

On 30-07-18 08:57, Rebecca N. Palmer wrote:
> On 29/07/18 14:58, Paul Gevers wrote:
>> [...]> On 27-07-18 22:49, Rebecca N. Palmer wrote:
>>> [...]
>>> Simon McVittie wrote:
 At some point I might add a way to mark some tests as trivial, with
 the intention that migration is never sped up by trivial tests passing,
 only slowed down by them failing - but that's a future feature.
>>>
>>> With the neutral state proposed here, a test can effectively mark itself
>>> as trivial by returning 77(skip) if it passes.[...]
>>>
>>> However, that's also true of flaky (return 77 on fail), and I agree it
>>> would be more user-friendly to make this option explicit.
>>
>> Which option, to use flaky versus skippable? Sorry, could you try to
>> phrase that sentence again, because I don't get what you mean here.
> 
> I meant that once you have skippable, you can use it to simulate either
> flaky or trivial:
> 
> #equivalent to Restrictions: flaky
> Restrictions: skippable
> Test-Command: do_the_test || exit 77
> 
> #equivalent to Restrictions: trivial
> Restrictions: skippable
> Test-Command: do_the_test && exit 77

Right. Not until now did I really understand what you meant by trivial.

> but that this doesn't imply they shouldn't exist explicitly.

Got it now.

>>> Do you[Simon McVittie] propose to add this[trivial] to
>>> autodep8-generated "check that we can
>>> import the top-level module" tests?
> 
> His original proposed use case (in
> https://salsa.debian.org/ci-team/autopkgtest/merge_requests/19) was:
>> I've seriously considered mass-bug-filing patches to add trivial
>> autopkgtests to as many shared libraries as I can, because even
>> something as trivial as "link an implementation of hello(1) to the
>> library using pkg-config and -Wl,--no-as-needed" catches surprisingly
>> many embarrassing packaging errors.
> which would effectively be an autopkgtest-pkg-c, so probably yes.

Not sure if that would be the same value of trivial. I mean, doing this
may already be enough to be used for gating.

>> A similar idea has come to my mind
>> about allow-stderr, so I think this is worth discussing.
> 
> Do you mean setting allow-stderr by default in autodep8-generated tests?

That is indeed what I wanted to discuss.

>  There are packages that would pass only with that (e.g. theano prints a
> warning to stderr if one of its Recommends is not installed), but I
> don't know how many.

Indeed, but right now they shouldn't be using autodep8 then. And I
wonder if there are regression in this area if we want to block on that.
I.e. deprecation warnings in Python are printed on stderr. Having a new
Python version being blocked on this is NOT NICE in my opinion. I think
failing on stderr is good by default, but package maintainers have no
way to override it with autodep8, making it unusable by this class of
packages. (This recently came up in the python3.7 transition).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905030: lintian: please verify debian/tests/control contains more tests than "Test-Command: /bin/true"

[Paul Gevers]

Hi Chris,

On 31-07-18 16:55, Chris Lamb wrote:
>> Rather unconstructively, they refuse to fix it until lintian has the
>> warning [2].
> 
> That seems.. strange. At the very least, Lintian is not Policy.

Ack. I filed 6 bugs today against packages in their team (the ones
currently trying to migrate). They already fixed the first bug.

> Unrelated to the above, do you feel there any real fear that a /bin/
> true would simply be replaced with something else if a maintainer saw
> this tag?  There are, of course, plenty of no-op commands available in
> the base system... :)

Yes, let's make sure the message is not "don't use /bin/true (or only
true, or exit 0 or echo)" but rather, please make sure the set of
autopkgtests actually test the installed package somehow.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#893312: lombok FTBFS with openjdk-9

[Emmanuel Bourg]

Control: reopen -1
Control: severity -1 important

I'm reopening the bug because ultimately this issue will have to be
fixed, but I'm lowering the severity to prevent the autoremoval.

Bug#905142: polari: Stored password for user identification does not work with OFTC network

[Pr0metheus]

Package: polari
Version: 3.28.0-1
Severity: normal

Dear Maintainer,

How the problem appears:

Login with a registered nickname in OFTC, identify, save password. Close Polari
or disconnect and connect again to OFTC and nickserv sends:

This nickname is registered and protected.  If it is your nickname, you may
authenticate yourself to services with the IDENTIFY command.  You are
getting this message because you are not on the access list for the
#MYNICKNAME# nickname.
Nickname #MYPASSWORD# is not registered.  The nickname you specify must be a
registered nickname.  See HELP REGISTER for more information.

IDENTIFY command should send only the password for OFTC.

BR,

Pr0m



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

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

Versions of packages polari depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  gir1.2-gdkpixbuf-2.0 2.36.12-1
ii  gir1.2-glib-2.0  1.56.1-1
ii  gir1.2-gspell-1  1.6.1-1
ii  gir1.2-gtk-3.0   3.22.30-2
ii  gir1.2-pango-1.0 1.42.1-2
ii  gir1.2-secret-1  0.18.6-2
ii  gir1.2-soup-2.4  2.62.2-2
ii  gir1.2-telepathyglib-0.120.24.1-2
ii  gir1.2-telepathylogger-0.2   0.8.2-3
ii  gjs  1.52.3-2
ii  libc62.27-5
ii  libgirepository-1.0-11.56.1-1
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.52.3-2
ii  libglib2.0-0 2.56.1-2
ii  libglib2.0-bin   2.56.1-2
ii  libgtk-3-0   3.22.30-2
ii  libtelepathy-glib0   0.24.1-2
ii  telepathy-idle   0.2.0-2+b1
ii  telepathy-logger 0.8.2-3
ii  telepathy-mission-control-5  1:5.16.4-2

polari recommends no packages.

polari suggests no packages.

-- no debconf information

Bug#904934: [debian-policy] Add footnote to find easily the corresponding days for the urgency field

[Russ Allbery]

Addressing just this aside:

Agustin Henze  writes:

> Thanks for that :), anyway it'd be good accepting MR on salsa and having
> the discussion there. But it's a matter of team preferences of course.

Both the BTS and Salsa are workable, both communication paradigms are used
successfully by other projects, and both have their pluses and minuses.  I
don't really care which we use, but I do care a lot that we only use one
of them.  I'm more worried about splitting discussions and causing
confusion by having one half of the discussion miss the other half of the
discussion than about the details of the UI in those two options.

It probably makes sense to lean towards using the BTS and email in the
absence of strong feelings in favor of Salsa just because the broader
communication culture of the project is very email-centric and it allows
easy movement of discussions between debian-devel, Policy and the BTS,
dpkg maintenance discussions, the Technical Committee, and so forth.  I
admit that it would be rather nice to have the discussion tied directly to
patches against Policy in a mergeable form, though, rather than sometimes
awkwardly sending around diffs.

-- 
Russ Allbery (r...@debian.org)   

Bug#805697: Please add readline

[GCS]

Control: tags -1 +wontfix

Hi Emil,

On Tue, Jul 31, 2018 at 2:33 PM Emil Fihlman  wrote:
> I would also very much like to see this added to the system. The usability 
> increase is pretty great and the cost (--enable-readline=yes) is pretty small.
 Please note that users (like you in this case) often mix three
things: command line history, filename completion and command
completion.
The first two things already available and works as SQLite is built
with readline since February, 2005 (indeed, for thirteen years!).
For command completion readline is not enough, needs upstream support.
I've some memory that there's no plan to do it for keeping the library
and tool size small.
However you can reach the behavior with a tool called rlwrap. After
installing it, create the file ~/.rlwrap/sqlite3_completions with
SQLite3 commands in it:
-- cut --
ABORT ACTION ADD AFTER ALL ALTER ANALYZE AND AS ASC ATTACH
AUTOINCREMENT BEFORE BEGIN BETWEEN BY CASCADE CASE CAST CHECK COLLATE
COLUMN COMMIT CONFLICT CONSTRAINT CREATE CROSS CURRENT_DATE
CURRENT_TIME CURRENT_TIMESTAMP DATABASE DEFAULT DEFERRABLE DEFERRED
DELETE DESC DETACH DISTINCT DROP EACH ELSE END ESCAPE EXCEPT EXCLUSIVE
EXISTS EXPLAIN FAIL FOR FOREIGN FROM FULL GLOB GROUP HAVING IF IGNORE
IMMEDIATE IN INDEX INDEXED INITIALLY INNER INSERT INSTEAD INTERSECT
INTO IS ISNULL JOIN KEY LEFT LIKE LIMIT MATCH NATURAL NO NOT NOTNULL
NULL OF OFFSET ON OR ORDER OUTER PLAN PRAGMA PRIMARY QUERY RAISE
RECURSIVE REFERENCES REGEXP REINDEX RELEASE RENAME REPLACE RESTRICT
RIGHT ROLLBACK ROW SAVEPOINT SELECT SET TABLE TEMP TEMPORARY THEN TO
TRANSACTION TRIGGER UNION UNIQUE UPDATE USING VACUUM VALUES VIEW
VIRTUAL WHEN WHERE WITH WITHOUT
-- cut --
Then use the CLI tool as 'rlwrap -a -N -c -i sqlite3'.

Hope this helps or please convince upstream to implement command
completion in the CLI tool itself.

Regards,
Laszlo/GCS

Bug#905129: im-config: Wrongly run shell scripts with user's shell interpreter, raises error with zsh

[Boyuan Yang]

Osamu Aoki  于2018年7月31日周二 下午11:55写道：
>
> Hi,
>
> On Tue, Jul 31, 2018 at 10:29:11PM +0800, Boyuan Yang wrote:
> > Package: im-config
> > Severity: important
> > Version: 0.30-1
> > X-Debbugs-CC: os...@debian.org
> >
> > Hi Osamu and debian-input-method team members,
> >
> > TL;DR: file /etc/X11/Xsession.d/70im-config_launch is *not* called by 
> > /bin/sh,
> > as written in shabang; it is called by user's shell interpreter
> > instead, which may
> > result in unexpected outcome when user's default shell is neither
> > /bin/dash nor /bin/bash.
>
> I am aware ... but This is actually problem on how X startup calls in
> /etc/X11/Xsession.d/* are called by desktop environment.  It should use
> /bin/sh ...
>
> Which which DE do you use?
>
> But this is annoying.  Maybe I should force dash as work around until
> alll DE startup codes are fixed.

I'm using SDDM. Just read some sddm code and I found that sddm seems to
have made things work like this on purpose. Haven't read others' code (like gdm)
yet. Maybe it is a convention?

Sending mail copy to s...@packages.debian.org for help.

I doubt that we could ever push all DM upstream to use /bin/sh to call
/etc/X11/Xsession. Writing workaround at im-config side seems more reasonable.

Besides, is it possible to force some /etc/X11/Xsession.d/* scripts to
be called by
/bin/sh? The Xsession file calls all snippets with "." ("source"),
which made it almost
impossible to switch shell interpreter.

--
Regards,
Boyuan Yang


> > Solution
> > ===
> >
> > While the zsh-incompatible grammar can be fixed (perhaps with a thorough
> > examination of all im-config source code), the problem that
> > Xsession.d scripts are executed by user shell interpreter is a big problem
> > and should receive further examination.
>
> Yes.  Please file bug to DE otherwise you may be breaking other part of
> X startup.
>
> Osamu

Bug#902936: fixed in zutils 1.7-2

[Stephen Kitt]

Hi Antonio,

Le 31/07/2018 17:05, Antonio Diaz Diaz a écrit :

On Tue, 31 Jul 2018 12:49:32 +0800 Ben Hutchings wrote:

The non-technical problem I see is that your upstream is dismissive of
valid bug reports ("but it's compatible with cat", "this bug is
impossible in C++!"), and that you are agreeing with this nonsense.


I think "valid" does not mean what you think it means.

First, 'zcat -t' is not standardized. Therefore it is not valid to
expect it to be portable.

Second, a bug report is not valid until the bad code is pointed out or
until a way to reproduce the failure is provided. Until then the bug
may be anywhere else. The problem is that in spite of my efforts I
have been unable to reproduce the problem reported in zutils' zcat. As
soon as you, or anybody else, provide a way to reproduce the problem,
or point out the cause of the bug, I'll fix it in 24h. Until then
there is not much that I can do.


I did provide a way to reproduce the problem, and Daniel reproduced it;
I will readily admit that it's neither convenient nor particularly 
useful

to identify the source of the problem, but dismissing this because
there's no way to reproduce it seems rather unfair to me.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902936#5 for
details. (I did also suggest that the real issue may lie somewhere else,
since zutils 1.7 exhibits the bug if it's built on Debian stable, and
doesn't if it's built on unstable.)


Stephen Kitt, please, could you send me the smallest file (not
necessarily an initramfs) that causes zcat to crash? Thanks.


I'll try to come up with a smaller example; I'm rather busy just now so
it might take me a couple of weeks to get round to it.

Regards,

Stephen

Bug#829417: dosemu: *** stack smashing detected ***: /usr/bin/xdosemu terminated

[Bernhard Übelacker]

Hello,
just tried to reproduce this issue.

I think the problem is with the usage of the segment register
$fs in dosemu that is not compatible with gcc use of that
segment register $fs.

It looks like in "regular" processes the $fs register stays always
at a value of 0.

But after starting the unzip32.exe from message #15 we get to the
point where the stack protection canary value is filled in "dosemu_fault".
But this time $fs = 0xb7, therefore the canary gets a differnt value
than usual:
   0x555a5c4d :mov%fs:0x28,%rax
   0x555a5c56 :mov%rax,0x88(%rsp)

Later "dosemu_fault" executes "init_handler" that calls "syscall".
After that the $fs register is 0 again:
   147   return syscall(SYS_arch_prctl, code, addr);

Then at the end of dosemu_fault the stack protection canary value
is now compared again, but with a different $fs the values are different:
   0x555a5d18 :   xor%fs:0x28,%rax
   0x555a5d21 :   jne0x555a5e4b 

   ...
   0x555a5e4b :   callq  0x5557a140 
<__stack_chk_fail@plt>


So really there is no stack smashing going on, just the detection is
not working in this environment.

This is also confirmed in this link [1].
There is also a hint how to avoid the stack protection
mechanism to be added to some functions.
Attached patch does exactly this.


The stack smashing can be observed in the unstable package of dosemu too.


Kind regards,
Bernhard


[1] https://aur.archlinux.org/packages/dosemu-git/

apt install xserver-xorg lightdm openbox dosemu dosemu-dbgsym gdb valgrind zip 
dpkg-dev devscripts mc git
apt build-dep dosemu
(mkdir dosemu; cd dosemu; apt source dosemu)

wget --user-agent="" http://www.delorie.com/pub/djgpp/current/unzip32.exe
mv unzip32.exe .dosemu/drive_c/





/usr/bin/xdosemu

benutzer@debian:~$ /usr/bin/xdosemu
*** stack smashing detected ***: /usr/bin/xdosemu terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f57d2425bfb]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f57d24ae1f7]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f57d24ae1c0]
/usr/bin/xdosemu(+0x51e50)[0x55604d00be50]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7f57d23e8060]
/usr/bin/xdosemu(run_dpmi+0x119)[0x55604d059dc9]
=== Memory map: 





gdb -q --args /usr/bin/dosemu.bin -X -p -E "unzip32"
handle SIGSEGV nostop noprint
cont


*** stack smashing detected ***: /usr/bin/dosemu.bin terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7739abfb]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x774231f7]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x774231c0]
/usr/bin/dosemu.bin(+0x51e50)[0x555a5e50]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7735d060]
/usr/bin/dosemu.bin(run_dpmi+0x119)[0x555f3dc9]
=== Memory map: 






(gdb) disassemble dosemu_fault,0x555a5e4b+0x20
...
   0x561052192c4d :mov%fs:0x28,%rax
   0x561052192c56 :mov%rax,0x88(%rsp)
   0x561052192c5e :xor%eax,%eax
...
   0x561052192d10 :   mov0x88(%rsp),%rax
   0x561052192d18 :   xor%fs:0x28,%rax
   0x561052192d21 :   jne0x561052192e4b 

...
   0x561052192e4b :   callq  0x561052167140 
<__stack_chk_fail@plt>
   0x561052192e50 :   sub$0x8,%rsp
.








gdb -q --args /usr/bin/dosemu.bin -X -p -E "unzip32"

directory 
/home/benutzer/dosemu/orig/dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async
handle SIGSEGV nostop noprint
set height 0
set width 0
set pagination off
display/i $pc
b *(dosemu_fault+30)
run
print/x 0x88+$rsp
print/x *(int*)0x7fffe148
display/x $fs

b *(dosemu_fault+13)  if ($fs != 0)
disa 1
cont






benutzer@debian:~$ gdb -q --args /usr/bin/dosemu.bin -X -p -E "unzip32"
Reading symbols from /usr/bin/dosemu.bin...Reading symbols from 
/usr/lib/debug/.build-id/e6/269b11b17af3136254880ec6b9bd18f464db59.debug...done.
done.
(gdb) directory 
/home/benutzer/dosemu/orig/dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async
Source directories searched: 
/home/benutzer/dosemu/orig/dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async:$cdir:$cwd
(gdb) handle SIGSEGV nostop noprint
SignalStop  Print   Pass to program Description
SIGSEGV   NoNo  Yes Segmentation fault
(gdb) set height 0
(gdb) set width 0
(gdb) set pagination off
(gdb) display/i $pc
1: x/i $pc

(gdb) b *(dosemu_fault+30)
Breakpoint 1 at 0x51c5e: file sigsegv.c, line 453.
(gdb) run
Starting program: /usr/bin/dosemu.bin -X -p -E unzip32
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x555a5c5e in dosemu_fault (signal=11, si=0x7fffe2b0, 
uc=0x7fffe180) at sigsegv.c:453
453 {
1: x/i $pc
=> 0x555a5c5e :xor%eax,%eax
(gdb) print/x 0x88+$rsp
$1 = 0x7fffe148
(gdb) print/x *(int*)0x7

Bug#904047: eviacam: Please consider using getent instead of sg in maintscript

[Andreas Henriksson]

Control: tags -1 + patch

On Wed, Jul 18, 2018 at 11:06:37PM +0200, Andreas Henriksson wrote:
> Source: eviacam
> Version: 2.1.3-4
[...]
> If time permits and I haven't heard anything back I'll consider fixing
> this via a NMU while at DebCamp/DebConf.
[...]

I'm attaching the diff to fix this. It's been piuparts tested. Please
tell me if you'd like to incorporate it or if you want me to go ahead
with NMU.

Regards,
Andreas Henriksson
diff -Nru eviacam-2.1.3/debian/changelog eviacam-2.1.3/debian/changelog
--- eviacam-2.1.3/debian/changelog  2018-04-16 15:23:49.0 +0200
+++ eviacam-2.1.3/debian/changelog  2018-07-31 18:36:55.0 +0200
@@ -1,3 +1,13 @@
+eviacam (2.1.3-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace sg usage with getent group in maintainerscripts
+- note for further improvement:
+  removing group on purge likely violates common consensus
+  (See mailinglist thread linked in #228692)
+
+ -- Andreas Henriksson   Tue, 31 Jul 2018 18:36:55 +0200
+
 eviacam (2.1.3-4) unstable; urgency=medium
 
   * disable DH_VERBOSE = 1
diff -Nru eviacam-2.1.3/debian/postinst eviacam-2.1.3/debian/postinst
--- eviacam-2.1.3/debian/postinst   2018-02-28 16:20:44.0 +0100
+++ eviacam-2.1.3/debian/postinst   2018-07-31 18:36:31.0 +0200
@@ -14,7 +14,7 @@
if [ "$RET" = true ]; then

# Create group when necessary
-   if ! sg "$GROUP" true 2>/dev/null; then
+   if ! getent group "$GROUP" >/dev/null; then
addgroup --system "$GROUP"
fi

diff -Nru eviacam-2.1.3/debian/postrm eviacam-2.1.3/debian/postrm
--- eviacam-2.1.3/debian/postrm 2018-02-28 16:20:44.0 +0100
+++ eviacam-2.1.3/debian/postrm 2018-07-31 18:36:53.0 +0200
@@ -10,7 +10,7 @@
 
 case "$1" in
purge)
-   if sg "$GROUP" true 2>/dev/null; then
+   if getent group "$GROUP" >/dev/null; then
delgroup --quiet --only-if-empty "$GROUP" >/dev/null 
2>&1 || true
fi
;;  

Bug#904050: mlocate: Please consider using getent instead of sg in maintscript

[Andreas Henriksson]

Control: tags -1 + patch

On Wed, Jul 18, 2018 at 11:06:59PM +0200, Andreas Henriksson wrote:
> Source: mlocate
[...]
> If time permits and I haven't heard anything back I'll consider fixing
> this via a NMU while at DebCamp/DebConf.

As we discussed you'd handle this and suggested a slightly different
way, but I'm attaching my trivial patch anyway as I've already created
and piuparts tested it.

My only concern is for this to make it in well in time for buster
release.

Regards,
Andreas Henriksson
diff -u mlocate-0.26/debian/changelog mlocate-0.26/debian/changelog
--- mlocate-0.26/debian/changelog
+++ mlocate-0.26/debian/changelog
@@ -1,3 +1,10 @@
+mlocate (0.26-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace sg usage with getent group in mlocate.postinst (Closes: #904050)
+
+ -- Andreas Henriksson   Sat, 28 Jul 2018 14:55:03 +0200
+
 mlocate (0.26-2) unstable; urgency=medium
 
   * Add support for nocache(1) to cron.daily.  Closes: #711323
diff -u mlocate-0.26/debian/mlocate.postinst 
mlocate-0.26/debian/mlocate.postinst
--- mlocate-0.26/debian/mlocate.postinst
+++ mlocate-0.26/debian/mlocate.postinst
@@ -10,7 +10,7 @@
--slave /usr/bin/updatedb updatedb /usr/bin/updatedb.mlocate \
--slave /usr/share/man/man8/updatedb.8.gz updatedb.8.gz 
/usr/share/man/man8/updatedb.mlocate.8.gz
 
-if ! sg "$GROUP" true 2>/dev/null; then
+if ! getent group "$GROUP" >/dev/null; then
addgroup --system "$GROUP"
 fi
 

Bug#904046: netkit-telnet: Please consider using getent instead of sg in maintscript

[Andreas Henriksson]

Control: tags -1 + patch

On Wed, Jul 18, 2018 at 11:06:28PM +0200, Andreas Henriksson wrote:
> Source: netkit-telnet
[...]
> If time permits and I haven't heard anything back I'll consider fixing
> this via a NMU while at DebCamp/DebConf.

I'm attaching patch to implement the suggested change. It's been tested
using piuparts. Please reply if you'd like to incorporate this or if
you prefer I go ahead with NMU.

Regards,
Andreas Henriksson
diff -Nru netkit-telnet-0.17/debian/changelog 
netkit-telnet-0.17/debian/changelog
--- netkit-telnet-0.17/debian/changelog 2016-11-07 19:06:40.0 +0100
+++ netkit-telnet-0.17/debian/changelog 2018-07-28 15:49:47.0 +0200
@@ -1,3 +1,14 @@
+netkit-telnet (0.17-41.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace sg usage with getent group in postinst (Closes: #904046)
+- note that there's still much room for related improvements, like
+  using 'getent passwd' instead of id to match the common pattern
+  also don't remove the user in postrm as that violates the
+  common consensus (see discussion linked from #228692)
+
+ -- Andreas Henriksson   Sat, 28 Jul 2018 15:49:47 +0200
+
 netkit-telnet (0.17-41) unstable; urgency=low
 
   * Declare Standards version as 3.9.8, no changes.
diff -Nru netkit-telnet-0.17/debian/telnetd.postinst 
netkit-telnet-0.17/debian/telnetd.postinst
--- netkit-telnet-0.17/debian/telnetd.postinst  2016-11-05 14:51:10.0 
+0100
+++ netkit-telnet-0.17/debian/telnetd.postinst  2018-07-28 15:48:59.0 
+0200
@@ -14,7 +14,7 @@
 }
 
 if ! id -u telnetd >/dev/null 2>&1; then
-   if sg telnetd -c true 2>/dev/null; then
+   if getent group telnetd >/dev/null; then
adduser --quiet --no-create-home --disabled-password --system 
--ingroup telnetd --home /nonexistent telnetd
else
adduser --quiet --no-create-home --disabled-password --system 
--group --home /nonexistent telnetd

Bug#904048: netkit-telnet-ssl: Please consider using getent instead of sg in maintscript

[Andreas Henriksson]

Control: tags -1 + patch

On Wed, Jul 18, 2018 at 11:06:44PM +0200, Andreas Henriksson wrote:
> Source: netkit-telnet-ssl
[...]
> If time permits and I haven't heard anything back I'll consider fixing
> this via a NMU while at DebCamp/DebConf.

I'm attaching a patch implementing the suggested change. It's been
tested with piuparts. Please reply back if you'd like to incorporate it
or if you prefer I go ahead with NMU.

Please note that netkit-telnet-ssl maintainer-scripts likely violate
several cases of common convention and probably also policy by removing
user/groups, possibly even one created by another package. Would it be
possible netkit-telnet and netkit-telnet-ssl to use the same username?
That should simplify things alot. (See also #228692.)

Regards,
Andreas Henriksson
diff -Nru netkit-telnet-ssl-0.17.41+0.2/debian/changelog 
netkit-telnet-ssl-0.17.41+0.2/debian/changelog
--- netkit-telnet-ssl-0.17.41+0.2/debian/changelog  2017-01-22 
00:40:10.0 +0100
+++ netkit-telnet-ssl-0.17.41+0.2/debian/changelog  2018-07-28 
16:14:32.0 +0200
@@ -1,3 +1,15 @@
+netkit-telnet-ssl (0.17.41+0.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace sg usage with getent group in postinst (Closes: #904048)
+- note that there's still much room for related improvements, like
+  not removing users and groups in postrm (see discussion linked
+  from #228692) and not removing group created by another package,
+  maybe even use the same group for both netkit-telnet* packages
+  to simplify maintscripts if possible.
+
+ -- Andreas Henriksson   Sat, 28 Jul 2018 16:14:32 +0200
+
 netkit-telnet-ssl (0.17.41+0.2-3) unstable; urgency=low
 
   * Adapt to libssl of recent version.
diff -Nru netkit-telnet-ssl-0.17.41+0.2/debian/telnetd.postinst 
netkit-telnet-ssl-0.17.41+0.2/debian/telnetd.postinst
--- netkit-telnet-ssl-0.17.41+0.2/debian/telnetd.postinst   2017-01-10 
23:04:09.0 +0100
+++ netkit-telnet-ssl-0.17.41+0.2/debian/telnetd.postinst   2018-07-28 
16:08:27.0 +0200
@@ -38,10 +38,10 @@
;;
esac
 fi
-if sg telnetd -c true >/dev/null 2>&1; then
+if getent group telnetd > /dev/null ; then
groupdel telnetd 
 fi
-if sg telnetd-ssl -c true >/dev/null 2>&1 ; then
+if getent group telnetd-ssl > /dev/null ; then
adduser --quiet --no-create-home --disabled-password --system --ingroup 
telnetd-ssl --home /nonexistent  telnetd-ssl
 else
adduser --quiet --no-create-home --disabled-password --system --group 
--home /nonexistent telnetd-ssl

Bug#905135: task-kde-desktop is not installable

[Ben Hutchings]

On Tue, 2018-07-31 at 17:23 +0200, thu...@gmail.com wrote:
> I don't have pinned packages, and my mirror seems up-to-date.
> 
> Looking through a troublesome dependency of task-kde-desktop, I get
> kde-standard->akregator->libkf5grantleetheme5->libkf5xmlgui5->qtbase-abi-5-10-0
> 
> libkf5xmlgui5 from my "apt-cache show" is the same version as the latest at
> https://packages.debian.org/sid/libkf5xmlgui5 (5.47.0-1)

No, the latest is 5.47.0-1+b1.  An important difference: the release
team triggered a binNMU (rebuild) to fix this dependency problem.

> According to https://packages.debian.org/sid/qtbase-abi-5-10-0
> , qtbase-abi-5-10-0 is a virtual package provided by libqt5core5a.
> 
> The version of libqt5core5a from my "apt-cache show" is the same as on
> https://packages.debian.org/sid/libqt5core5a (5.11.1+dfsg-6, and is in fact
> already installed on my system)
> 
> I am confused. libkf5xmlgui5 has some funky architecture-dependent
> dependencies on qtbase-abi-5-10-0 vs qtbase-abi-5-11-0; perhaps it has
> something to do with that?
[...]

It has not been rebuilt for unofficial ports (yet).  I think the
release team does not trigger binNMUs for them.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949


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

Bug#905143: policykit-1 in jessie-security needs to be devuanized

[. fsmithred]

Package: policykit-1

$ apt-cache policy policykit-1
policykit-1:
  Installed: 0.105-9+devuan1
  Candidate: 0.105-15~deb8u3
  Version table:
 0.105-18+devuan2.3 0
100 http://auto.mirror.devuan.org/devuan/ experimental/main i386
Packages
 0.105-15~deb8u3 0
500 http://auto.mirror.devuan.org/merged/ jessie-security/main i386
Packages
500 http://pkgmaster.devuan.org/merged/ jessie-security/main i386
Packages
 *** 0.105-9+devuan1 0
500 http://us.mirror.devuan.org/merged/ jessie/main i386 Packages
500 http://pkgmaster.devuan.org/merged/ jessie/main i386 Packages
100 /var/lib/dpkg/status

Bug#905143: Oops! Sent to wrong bugtracker. Sorry about that.

[. fsmithred]

Bug#902936: fixed in zutils 1.7-2

[Antonio Diaz Diaz]

Stephen Kitt wrote:

I did provide a way to reproduce the problem, and Daniel reproduced it;
I will readily admit that it's neither convenient nor particularly useful
to identify the source of the problem, but dismissing this because
there's no way to reproduce it seems rather unfair to me.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902936#5 for
details. (I did also suggest that the real issue may lie somewhere else,
since zutils 1.7 exhibits the bug if it's built on Debian stable, and
doesn't if it's built on unstable.)


Thanks for the report and for your support. I have finally managed to 
reproduce the problem. It seems to happen only when the -t option is 
used. It is not a double-free as Ben Hutchings suggested, but a buffer 
overrun.


BTW, what I find unfair are all those accusations of dismissal. I do not 
have access to a Debian installation and have spent a lot of time trying 
to find a file that triggered this bug.


I'll release a fixed version later today.


Best regards,
Antonio.

Bug#903853: transition: removal of nepomuk support from src:kde4libs

[Pino Toscano]

In data lunedì 30 luglio 2018 07:25:08 CEST, Pino Toscano ha scritto:
> In data sabato 28 luglio 2018 10:16:15 CEST, Emilio Pozuelo Monfort ha 
> scritto:
> > Control: tags -1 confirmed
> > 
> > On 15/07/18 22:33, Pino Toscano wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Hi,
> > > 
> > > I'd like to remove the support for Nepomuk in src:kde4libs.
> > > 
> > > Since Nepomuk has been deprecated, and already unused in Debian for
> > > quite some time, this allows us to drop src:soprano &
> > > src:shared-desktop-ontologies. The result is the drop of 3 library
> > > packages from src:kde4libs: libnepomuk4, libnepomukquery4a, and
> > > libnepomukutils4.
> > > 
> > > The reason of this transition is that libnepomuk was so far listed as
> > > public library dependency for the kde4 versions of kio (libkio5), and
> > > kparts (libkparts4), resulting in overlinking. Fortunately, almost all
> > > the packages either already link in as-needed more, or switched to KDE
> > > Frameworks 5. The only exception is src:kpartsplugin.
> > > 
> > > Hence, the plan is the following:
> > > 1) upload src:kde4libs without Nepomuk support
> > > 2) binNMU src:kpartsplugin
> > > 
> > > I verified that src:kpartsplugin builds fine even without Nepomuk
> > > libraries, effectively not linking against them anymore. I also did
> > > a rebuild of all the other sources still using kdelibs 4.x, and there
> > > were no changes in their build.
> > > 
> > > PS: since I uploaded kde4libs 4:4.14.38-1 yesterday, I'd wait for it to
> > > migrate to testing, first.
> > 
> > Please go ahead.
> 
> Uploaded two days ago, and built everywhere now.  Can you please
> schedule the binNMUs for kpartplugins?

Anyone in release-team: considering Emilio is not around this week, can
you please schedule this binNMU?

Thanks in advance,
-- 
Pino Toscano

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

Bug#893167: Stack smashing protection trigged in eboard

[Bernhard Übelacker]

Hello,
just tried to reproduce the stack smashing.

It looks like the variable "gdouble c[3];" in colorb_csok
needs to be a "gdouble c[4];".

Did not find an related upstream ticket, neither in old SF nor at Github.
Also at Github this function was not yet changed, so this should be
forwarded to upstream.

See details below.

Kind regards,
Bernhard




# With a locally rebuild version to get debug information.

(gdb) cont
Continuing.

Hardware watchpoint 2: *0x7fffd428

Old value = -1459212032
New value = 0
gtk_color_selection_get_color (colorsel=0x55992370, color=0x7fffd410) 
at ./gtk/gtkcolorsel.c:2579
2579./gtk/gtkcolorsel.c: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x77a01c6e :  add$0x8,%rsp
(gdb) bt
#0  0x77a01c6e in gtk_color_selection_get_color 
(colorsel=0x55992370, color=0x7fffd410) at ./gtk/gtkcolorsel.c:2579
#1  0x555e6cdc in colorb_csok(_GtkWidget*, void*) (b=, 
data=0x558ec810) at widgetproxy.cc:364
#2  0x764f0f6d in g_closure_invoke () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x76503d3e in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x7650c3f5 in g_signal_emit_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7650ce0f in g_signal_emit () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x779e7785 in gtk_real_button_released (button=0x559564e0) at 
./gtk/gtkbutton.c:1712
#7  0x764f0f6d in g_closure_invoke () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x76503e0e in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x7650c3f5 in g_signal_emit_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7650ce0f in g_signal_emit () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x779e6709 in gtk_button_button_release 
(widget=widget@entry=0x559564e0, event=) at 
./gtk/gtkbutton.c:1604
#12 0x77a8c2bb in _gtk_marshal_BOOLEAN__BOXED (closure=0x556afa50, 
return_value=0x7fffdec0, n_param_values=, 
param_values=0x7fffdf20, invocation_hint=, 
marshal_data=) at ./gtk/gtkmarshalers.c:84
#13 0x764f0f6d in g_closure_invoke () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x76503ac8 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x7650bd8f in g_signal_emit_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x7650ce0f in g_signal_emit () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x77ba227c in gtk_widget_event_internal 
(widget=widget@entry=0x559564e0, event=event@entry=0x55a0f560) at 
./gtk/gtkwidget.c:5010
#18 0x77ba2517 in IA__gtk_widget_event 
(widget=widget@entry=0x559564e0, event=event@entry=0x55a0f560) at 
./gtk/gtkwidget.c:4807
#19 0x77a8a55c in IA__gtk_propagate_event (widget=0x559564e0, 
event=0x55a0f560) at ./gtk/gtkmain.c:2503
#20 0x77a8a95b in IA__gtk_main_do_event (event=) at 
./gtk/gtkmain.c:1698
#21 0x7770005c in gdk_event_dispatch (source=, 
callback=, user_data=) at 
./gdk/x11/gdkevents-x11.c:2425
#22 0x76215287 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x762154c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x762157d2 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x77a89987 in IA__gtk_main () at ./gtk/gtkmain.c:1270
#26 0x5557d854 in main (argc=, argv=) at 
main.cc:108
#27 0x755b0b17 in __libc_start_main (main=0x5557d630 , 
argc=1, argv=0x7fffe578, init=, fini=, 
rtld_fini=, stack_end=0x7fffe568)
at ../csu/libc-start.c:310
#28 0x5557dfea in _start () at main.cc:97
(gdb)





(gdb) list gtk_color_selection_get_color
2566void
2567gtk_color_selection_get_color (GtkColorSelection *colorsel,
2568   gdouble   *color)
2569{
2570  ColorSelectionPrivate *priv;
2571  
2572  g_return_if_fail (GTK_IS_COLOR_SELECTION (colorsel));
2573  
2574  priv = colorsel->private_data;
2575  color[0] = priv->color[COLORSEL_RED];
2576  color[1] = priv->color[COLORSEL_GREEN];
2577  color[2] = priv->color[COLORSEL_BLUE];
2578  color[3] = priv->has_opacity ? priv->color[COLORSEL_OPACITY] : 65535; 
<--- Here we access memory beyond the variable "gdouble c[3];"
2579}




(gdb) list colorb_csok
358
359 void colorb_csok(GtkWidget *b,gpointer data) {
360   ColorButton *me;
361   me=(ColorButton *)data;
362   gdouble c[3];
363   int v[3];
364   
gtk_color_selection_get_color(GTK_COLOR_SELECTION(GTK_COLOR_SELECTION_DIALOG(me->colordlg)->colorsel),c);
365   v[0]=(int)(c[0]*255.0);
366   v[1]=(int)(c[1]*255.0);
367   v[2]=(int)(c[2]*255.0);
368   me->ColorValue=(v[0]<<16)|(v[1]<<8)|v[2];
369   gtk_grab_remove(me->colordlg);
370   gtk_widget_dest

Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Stéphane Graber]

On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka  wrote:
>
> Hey,
>
> I would think that Stéphane will want to backport these changes to the
> 3.0.x series, as they improve performance considereably. It wouldn't be
> a big change for the LXD code itself, since this is mostly "backend"
> code.

Yes, we will be backporting the switch to the new dqlite
implementation in the 3.0.x branch, should be in 3.0.2.

> I'll Stéphane say the last workd tho.
>
> Thanks for the initiative, looking forward to see LXD in Debian!
>
> Free
>
> Clément Hermann  writes:
>
> > Hi,
> >
> > On 31/07/2018 17:28, Free Ekanayaka wrote:
> >> Hello Clement,
> >>
> >> dqlite upstream and LXD team member here.
> >>
> >> Please note that dqlite is going through a bit of change, which I
> >> started to merge yesterday. So a few of the ITPs you have filed will no
> >> longer make sense.
> >
> > Thanks a lot for the heads up!
> >
> >> In a nutshell:
> >>
> >> 1) https://github.com/CanonicalLtd/dqlite is now a C project
> >> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings
> >> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore
> >> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore
> >>
> >> This will all be effective starting with LXD 3.4, to be released in 3
> >> weeks.
> >>
> >> In LXD master, this will be effective once we land:
> >>
> >> https://github.com/lxc/lxd/pull/4854
> >>
> >> which should happen today or tomorrow at latest.
> >
> > Good to know! I guess this won't change anything for 3.0.x series ?
> > That's what we're aiming for, since we want to package the LTS version:
> > the users needing cutting-edge version should use the snap IMO.
> >
> > Cheers,

Bug#893167: Stack smashing protection trigged in eboard

[Felipe Bergo]

Thank you, I have just committed a fix for this to the github repository,
https://github.com/fbergo/eboard



On Tue, Jul 31, 2018 at 2:54 PM Bernhard Übelacker 
wrote:

> Hello,
> just tried to reproduce the stack smashing.
>
> It looks like the variable "gdouble c[3];" in colorb_csok
> needs to be a "gdouble c[4];".
>
> Did not find an related upstream ticket, neither in old SF nor at Github.
> Also at Github this function was not yet changed, so this should be
> forwarded to upstream.
>
> See details below.
>
> Kind regards,
> Bernhard
>
>
>
>
> # With a locally rebuild version to get debug information.
>
> (gdb) cont
> Continuing.
>
> Hardware watchpoint 2: *0x7fffd428
>
> Old value = -1459212032
> New value = 0
> gtk_color_selection_get_color (colorsel=0x55992370,
> color=0x7fffd410) at ./gtk/gtkcolorsel.c:2579
> 2579./gtk/gtkcolorsel.c: Datei oder Verzeichnis nicht gefunden.
> 1: x/i $pc
> => 0x77a01c6e :  add$0x8,%rsp
> (gdb) bt
> #0  0x77a01c6e in gtk_color_selection_get_color
> (colorsel=0x55992370, color=0x7fffd410) at ./gtk/gtkcolorsel.c:2579
> #1  0x555e6cdc in colorb_csok(_GtkWidget*, void*) (b= out>, data=0x558ec810) at widgetproxy.cc:364
> #2  0x764f0f6d in g_closure_invoke () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #3  0x76503d3e in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #4  0x7650c3f5 in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #5  0x7650ce0f in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #6  0x779e7785 in gtk_real_button_released (button=0x559564e0)
> at ./gtk/gtkbutton.c:1712
> #7  0x764f0f6d in g_closure_invoke () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #8  0x76503e0e in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #9  0x7650c3f5 in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #10 0x7650ce0f in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #11 0x779e6709 in gtk_button_button_release 
> (widget=widget@entry=0x559564e0,
> event=) at ./gtk/gtkbutton.c:1604
> #12 0x77a8c2bb in _gtk_marshal_BOOLEAN__BOXED
> (closure=0x556afa50, return_value=0x7fffdec0,
> n_param_values=, param_values=0x7fffdf20,
> invocation_hint=, marshal_data=) at
> ./gtk/gtkmarshalers.c:84
> #13 0x764f0f6d in g_closure_invoke () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #14 0x76503ac8 in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #15 0x7650bd8f in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #16 0x7650ce0f in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #17 0x77ba227c in gtk_widget_event_internal 
> (widget=widget@entry=0x559564e0,
> event=event@entry=0x55a0f560) at ./gtk/gtkwidget.c:5010
> #18 0x77ba2517 in IA__gtk_widget_event 
> (widget=widget@entry=0x559564e0,
> event=event@entry=0x55a0f560) at ./gtk/gtkwidget.c:4807
> #19 0x77a8a55c in IA__gtk_propagate_event (widget=0x559564e0,
> event=0x55a0f560) at ./gtk/gtkmain.c:2503
> #20 0x77a8a95b in IA__gtk_main_do_event (event=) at
> ./gtk/gtkmain.c:1698
> #21 0x7770005c in gdk_event_dispatch (source=,
> callback=, user_data=) at
> ./gdk/x11/gdkevents-x11.c:2425
> #22 0x76215287 in g_main_context_dispatch () at
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #23 0x762154c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #24 0x762157d2 in g_main_loop_run () at
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #25 0x77a89987 in IA__gtk_main () at ./gtk/gtkmain.c:1270
> #26 0x5557d854 in main (argc=, argv= out>) at main.cc:108
> #27 0x755b0b17 in __libc_start_main (main=0x5557d630 ,
> argc=1, argv=0x7fffe578, init=, fini=,
> rtld_fini=, stack_end=0x7fffe568)
> at ../csu/libc-start.c:310
> #28 0x5557dfea in _start () at main.cc:97
> (gdb)
>
>
>
>
>
> (gdb) list gtk_color_selection_get_color
> 2566void
> 2567gtk_color_selection_get_color (GtkColorSelection *colorsel,
> 2568   gdouble   *color)
> 2569{
> 2570  ColorSelectionPrivate *priv;
> 2571
> 2572  g_return_if_fail (GTK_IS_COLOR_SELECTION (colorsel));
> 2573
> 2574  priv = colorsel->private_data;
> 2575  color[0] = priv->color[COLORSEL_RED];
> 2576  color[1] = priv->color[COLORSEL_GREEN];
> 2577  color[2] = priv->color[COLORSEL_BLUE];
> 2578  color[3] = priv->has_opacity ? priv->color[COLORSEL_OPACITY] :
> 65535; <--- Here we access memory beyond the variable
> "gdouble c[3];"
> 2579}
>
>
>
>
> (gdb) list colorb_csok
> 358
> 359 void colorb_csok(GtkWidget *b,gpointer data) {
> 360   ColorButton *me;
> 361   me=(ColorButton *)data;
> 362   

Bug#905144: parted: useless warning and error when working with image file

[Lukas F. Hartmann]

Package: parted
Version: 3.2-21+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I'm trying to make a script that creates a system image with partitions.
As I'm working with an image file, I do not need root permissions. But every
start of parted makes it complain:

sh: 1: dmidecode: not found
WARNING: You are not superuser.  Watch out for permissions.

Example invocation:

dd if=/dev/zero of=reform-system.img bs=1M count=8000
/sbin/parted reform-system.img mklabel gpt

   * What outcome did you expect instead?

I find it unusual for a unix/linux command to complain preemptively about
not having root permissions, especially if they are not necessary.
Parted should also not try to use dmidecode if dealing with a file, IMHO.

*** 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: armhf, i386

Kernel: Linux 4.16.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)
LSM: AppArmor: enabled

Versions of packages parted depends on:
ii  libc6 2.27-3
ii  libparted23.2-21+b1
ii  libreadline7  7.0-3
ii  libtinfo6 6.1+20180210-4

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

-- no debconf information

Bug#905026: emacs: broken version

[Benoît Dejean]

On Mon, Jul 30, 2018 at 11:49:09PM +0100, Colin Watson wrote:
> On Mon, Jul 30, 2018 at 08:52:18PM +0200, Benoît wrote:
> > Source: emacs
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > the move to version-free breaks many packages.
> > Maybe this is because 1:25.2+1-8 < 47.0.
> 
> But 1:25.2+1-8 is in fact > 47.0, by the standard Debian version
> comparison algorithm:
> 
>   $ dpkg --compare-versions 1:25.2+1-8 gt 47.0 && echo yes
>   yes
> 
> So I think you need to go into quite a lot more detail about exactly
> what is failing ...

Hello Colin,

I'm not sure what happened, upgrading emacs actually removed emacs25
and half a dozen emacs elpa-* packages.
Or more likely i made a mistake in aptitude.

Sorry for wasting your time.
Thanks.

-- 
Benoît Dejean

Bug#905145: jakarta-jmeter: FTBFS with Java 9 due to Swing changes

[Emmanuel Bourg]

Source: jakarta-jmeter
Version: 2.13-3
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java9

jakarta-jmeter fails to build with Java 9 due to the generification
of the javax.swing.JTable constructors:

  compile-jorphan:
  [mkdir] Created dir: /build/1st/jakarta-jmeter-2.13/build/jorphan
  [javac] Using javac -source 1.6 is no longer supported, switching to 7
  [javac] Using javac -target 1.6 is no longer supported, switching to 7
  [javac] Compiling 55 source files to 
/build/1st/jakarta-jmeter-2.13/build/jorphan
  [javac] warning: [options] bootstrap class path not set in conjunction 
with -source 7
  [javac] 
/build/1st/jakarta-jmeter-2.13/src/jorphan/org/apache/jorphan/gui/JTreeTable.java:64:
 error: no suitable constructor found for JTable(Vector,Vector)
  [javac] super(rowData, columnNames);
  [javac] ^
  [javac] constructor JTable.JTable(TableModel,TableColumnModel) is not 
applicable
  [javac]   (argument mismatch; Vector cannot be converted to 
TableModel)
  [javac] constructor JTable.JTable(int,int) is not applicable
  [javac]   (argument mismatch; Vector cannot be converted to 
int)
  [javac] constructor JTable.JTable(Vector,Vector) 
is not applicable
  [javac]   (argument mismatch; Vector cannot be converted to 
Vector)
  [javac] constructor JTable.JTable(Object[][],Object[]) is not 
applicable
  [javac]   (argument mismatch; Vector cannot be converted to 
Object[][])
  [javac]   where CAP#1,CAP#2 are fresh type-variables:
  [javac] CAP#1 extends Object from capture of ?
  [javac] CAP#2 extends Object from capture of ?
  [javac] Note: Some input files use or override a deprecated API.
  [javac] Note: Recompile with -Xlint:deprecation for details.
  [javac] Note: 
/build/1st/jakarta-jmeter-2.13/src/jorphan/org/apache/jorphan/gui/JLabeledChoice.java
 uses unchecked or unsafe operations.
  [javac] Note: Recompile with -Xlint:unchecked for details.
  [javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
  [javac] 1 error
  [javac] 1 warning

Bug#905135: task-kde-desktop is not installable

[thuejk]

Ah, thanks, apt-get updating makes it work now.

Regards, Thue

Den tir. 31. jul. 2018 kl. 19.10 skrev Ben Hutchings :

> On Tue, 2018-07-31 at 17:23 +0200, thu...@gmail.com wrote:
> > I don't have pinned packages, and my mirror seems up-to-date.
> >
> > Looking through a troublesome dependency of task-kde-desktop, I get
> >
> kde-standard->akregator->libkf5grantleetheme5->libkf5xmlgui5->qtbase-abi-5-10-0
> >
> > libkf5xmlgui5 from my "apt-cache show" is the same version as the latest
> at
> > https://packages.debian.org/sid/libkf5xmlgui5 (5.47.0-1)
>
> No, the latest is 5.47.0-1+b1.  An important difference: the release
> team triggered a binNMU (rebuild) to fix this dependency problem.
>
> > According to https://packages.debian.org/sid/qtbase-abi-5-10-0
> > , qtbase-abi-5-10-0 is a virtual package provided by libqt5core5a.
> >
> > The version of libqt5core5a from my "apt-cache show" is the same as on
> > https://packages.debian.org/sid/libqt5core5a (5.11.1+dfsg-6, and is in
> fact
> > already installed on my system)
> >
> > I am confused. libkf5xmlgui5 has some funky architecture-dependent
> > dependencies on qtbase-abi-5-10-0 vs qtbase-abi-5-11-0; perhaps it has
> > something to do with that?
> [...]
>
> It has not been rebuilt for unofficial ports (yet).  I think the
> release team does not trigger binNMUs for them.
>
> Ben.
>
> --
> Ben Hutchings
> [W]e found...that it wasn't as easy to get programs right as we had
> thought. I realized that a large part of my life from then on was going
> to be spent in finding mistakes in my own programs.
>  - Maurice Wilkes, 1949
>

Bug#905146: libpqxx-6.2: missing Breaks+Replaces: libpqxx6 (>= 6.2)

[Andreas Beckmann]

Package: libpqxx-6.2
Version: 6.2.4-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
the previous version in sid,
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

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

  Selecting previously unselected package libpqxx-6.2.
  Preparing to unpack .../libpqxx-6.2_6.2.4-3_amd64.deb ...
  Unpacking libpqxx-6.2 (6.2.4-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libpqxx-6.2_6.2.4-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libpqxx-6.2.so', which is 
also in package libpqxx6 6.2.4-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libpqxx-6.2_6.2.4-3_amd64.deb


The suggested versioning "(>= 6.2)" is unusual, but intended,
since libpqxx-6.2 is co-installable with libpqxx6 (6.1.0-1) in testing.


cheers,

Andreas


libpqxx6=6.2.4-2_libpqxx-6.2=6.2.4-3.log.gz
Description: application/gzip

Bug#228692: User/group creation/removal in package maintainer scripts

[Simon McVittie]

On Tue, 31 Jul 2018 at 17:53:50 +0200, Andreas Henriksson wrote:
> previously created users should *not* (ever) be removed

There has been a suggestion in the past that these users should be locked
on package removal and unlocked on reinstallation, as implemented in
(for example) openarena-server. It is not entirely clear to me what
technical benefit this has, given that these users normally have a
disabled password anyway.

> Packages commonly check if user/group already exists before calling
> adduser to create them.

I have seen it suggested elsewhere that this is a bug or misunderstanding,
because adduser --system is already meant to exit successfully if the
requested user or group already exists in the system range. Calling
adduser conditionally prevents adduser from detecting whether the user
or group exists but is outside the system range.

> Writing manual mantainerscript code should always be avoided, because
> it's a common source of bugs.

Some alternatives to open-coding this:

systemd-sysusers(8) creates system users from declarative text files,
either at package installation or during early boot (part of a wider goal
for it to be feasible to boot a stateless or generic system after emptying
/etc and /var), in a way that is feasible to reimplement outside systemd
if people want to (but has not been reimplemented, as far as I'm aware).

dh-sysuser encapsulates maintainer script code into a single command,
although imperative rather than declarative. It uses useradd directly,
so it might be NIHing adduser(8).

> An example of a mechanism that
> allows not creating static system users/groups is unit file option
> DynamicUser=yes from systemd (and likely many others that I'm not aware
> of). For further information see:
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=
> http://0pointer.net/blog/dynamic-users-with-systemd.html

But note that:

- this doesn't work if some other daemon needs to know about your
  system user ahead of time: in particular, dbus-daemon system.d snippets
  cannot currently refer to dynamic users

- this is systemd-specific (suitable for systemd-systems-only software like
  systemd-cron, but not suitable for general daemons, unless Debian drops
  support for non-systemd init systems and non-Linux kernels)

Regards,
smcv

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Dmitry Shachnev]

On Sun, Jul 29, 2018 at 09:17:30PM +0200, John Paul Adrian Glaubitz wrote:
> On 07/29/2018 09:12 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Interesting, I have always used them inside the binary itself[1].
> >
> > [1] 
> >
> > But thanks to your comment I noted that indeed one can keep the resource 
> > file 
> > out of the main binary.
>
> I have actually never seen anyone compile them into the binary, not even
> on Windows. I'm surprised people still do that. Anyway.

There is an example in *this* package (qttools-opensource-src) — Qt Assistant
bundles its own help as a resource:

https://code.qt.io/cgit/qt/qttools.git/tree/src/assistant/assistant/assistant.qrc

Codesearch tells me that “aseba” and “speedcrunch” packages may be doing
a similar thing:

https://codesearch.debian.net/search?q=%5C.qch+path%3A.*%5C.qrc

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 31 Jul 2018 at 15:45, Dmitry Shachnev  wrote:
>
> On Sun, Jul 29, 2018 at 09:17:30PM +0200, John Paul Adrian Glaubitz wrote:
> > On 07/29/2018 09:12 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > Interesting, I have always used them inside the binary itself[1].
> > >
> > > [1] 
> > >
> > > But thanks to your comment I noted that indeed one can keep the resource 
> > > file
> > > out of the main binary.
> >
> > I have actually never seen anyone compile them into the binary, not even
> > on Windows. I'm surprised people still do that. Anyway.
>
> There is an example in *this* package (qttools-opensource-src) — Qt Assistant
> bundles its own help as a resource:
>
> https://code.qt.io/cgit/qt/qttools.git/tree/src/assistant/assistant/assistant.qrc

Mmm, I wonder how we did not step into this yet :-/

> Codesearch tells me that “aseba” and “speedcrunch” packages may be doing
> a similar thing:
>
> https://codesearch.debian.net/search?q=%5C.qch+path%3A.*%5C.qrc

Well, two more packages wouldn't be much of an issue, but qttools in
itself is :-/

Thanks Dmitry!

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

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John Paul Adrian Glaubitz]

On 07/31/2018 08:40 PM, Dmitry Shachnev wrote:
> There is an example in *this* package (qttools-opensource-src) — Qt Assistant
> bundles its own help as a resource:
> 
> https://code.qt.io/cgit/qt/qttools.git/tree/src/assistant/assistant/assistant.qrc
> 
> Codesearch tells me that “aseba” and “speedcrunch” packages may be doing
> a similar thing:
> 
> https://codesearch.debian.net/search?q=%5C.qch+path%3A.*%5C.qrc

It's still a bad practice, in my personal opinion, because it adds redundancy.

Resource files (docs, images etc) are normally architecture-independent, so
they should be separable from the binary packages.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#902936: fixed in zutils 1.7-2

[Stephen Kitt]

On Tue, 31 Jul 2018 19:29:54 +0200, Antonio Diaz Diaz  wrote:
> Stephen Kitt wrote:
> > I did provide a way to reproduce the problem, and Daniel reproduced it;
> > I will readily admit that it's neither convenient nor particularly useful
> > to identify the source of the problem, but dismissing this because
> > there's no way to reproduce it seems rather unfair to me.
> >
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902936#5 for
> > details. (I did also suggest that the real issue may lie somewhere else,
> > since zutils 1.7 exhibits the bug if it's built on Debian stable, and
> > doesn't if it's built on unstable.)  
> 
> Thanks for the report and for your support. I have finally managed to 
> reproduce the problem. It seems to happen only when the -t option is 
> used. It is not a double-free as Ben Hutchings suggested, but a buffer 
> overrun.

Fantastic, thanks!

> BTW, what I find unfair are all those accusations of dismissal. I do not 
> have access to a Debian installation and have spent a lot of time trying 
> to find a file that triggered this bug.

Please accept my apologies, I didn’t mean to mischaracterise your work or
your emails, and I do appreciate all your efforts in this matter.

Regards,

Stephen


pgpGomMp6ppUW.pgp
Description: OpenPGP digital signature

Bug#905041: [Pkg-dpdk-devel] Bug#905041: avf pmd missing in generated dependencies

[Luca Boccassi]

On Tue, 2018-07-31 at 09:03 +0200, Christian Ehrhardt wrote:
> Fortunately this is currently only in experimental.
> 
> This is actually a generated list of dependencies:
> 103 Package: libdpdk-dev
> 
> 104 Section: libdevel
> 
> 105 Architecture: amd64 arm64 i386 ppc64el
> 
> 106 Multi-Arch: same
> 
> 107 Pre-Depends: ${misc:Pre-Depends}
> 
> 108 Depends: libpcap-dev,
> 
> 109  zlib1g-dev,
> 
> 110  ${librte:Depends},
> 
> 111  ${misc:Depends}
> 
> With ${librte:Depends} being the one missing the entry.
> 
> Buildlog of 18.05
> 
> # debian/files will not exist until dh_gencontrol has ran at least
> once,
> # so we need to run gencontrol for libdpdk-dev and libdpdk-dbgsym
> after.
> # The list of libraries and PMDs is everchanging, so generate the
> dependency
> # list for libdpdk-dev to avoid having to maintain it manually.
> # Same for the recommends list for dpdk, were we want the PMDs and
> the mempools.
> dh_gencontrol -p libdpdk-dev -- -V"librte:Depends=`grep -E 'librte-*'
> ./debian/files | grep -v dbgsym | tr '_' ' ' | awk '{ print
> $1,"(=",$2
> ")" }' | paste -sd ',' - | sed -e 's/,/, /g'`"
>   dpkg-gencontrol -plibdpdk-dev -ldebian/changelog
> -Tdebian/libdpdk-dev.substvars -Pdebian/libdpdk-dev
> "-Vlibrte:Depends=librte-acl18.05 (= 18.05-1), librte-bbdev18.05 (=
> 18.05-1), librte-bitratestats18.05 (= 18.05-1), librte-bpf18.05 (=
> 18.05-1), librte-bus-dpaa18.05 (= 18.05-1), librte-bus-fslmc18.05 (=
> 18.05-1), librte-bus-ifpga18.05 (= 18.05-1), librte-bus-pci18.05 (=
> 18.05-1), librte-bus-vdev18.05 (= 18.05-1), librte-cfgfile18.05 (=
> 18.05-1), librte-cmdline18.05 (= 18.05-1), librte-common-
> octeontx18.05
> (= 18.05-1), librte-compressdev18.05 (= 18.05-1),
> librte-cryptodev18.05 (= 18.05-1), librte-distributor18.05 (=
> 18.05-1), librte-eal18.05 (= 18.05-1), librte-efd18.05 (= 18.05-1),
> librte-ethdev18.05 (= 18.05-1), librte-eventdev18.05 (= 18.05-1),
> librte-flow-classify18.05 (= 18.05-1), librte-gro18.05 (= 18.05-1),
> librte-gso18.05 (= 18.05-1), librte-hash18.05 (= 18.05-1),
> librte-ifcvf-vdpa18.05 (= 18.05-1), librte-ip-frag18.05 (= 18.05-1),
> librte-jobstats18.05 (= 18.05-1), librte-kvargs18.05 (= 18.05-1),
> librte-latencystats18.05 (= 18.05-1), librte-lpm18.05 (= 18.05-1),
> librte-mbuf18.05 (= 18.05-1), librte-member18.05 (= 18.05-1),
> librte-mempool-bucket18.05 (= 18.05-1), librte-mempool-dpaa18.05 (=
> 18.05-1), librte-mempool-dpaa2-18.05 (= 18.05-1),
> librte-mempool-octeontx18.05 (= 18.05-1), librte-mempool-ring18.05 (=
> 18.05-1), librte-mempool-stack18.05 (= 18.05-1), librte-mempool18.05
> (= 18.05-1), librte-meter18.05 (= 18.05-1), librte-metrics18.05 (=
> 18.05-1), librte-net18.05 (= 18.05-1), librte-pci18.05 (= 18.05-1),
> librte-pdump18.05 (= 18.05-1), librte-pipeline18.05 (= 18.05-1),
> librte-pmd-af-packet18.05 (= 18.05-1), librte-pmd-ark18.05 (=
> 18.05-1), librte-pmd-axgbe18.05 (= 18.05-1),
> librte-pmd-bbdev-null18.05 (= 18.05-1), librte-pmd-bnxt18.05 (=
> 18.05-1), librte-pmd-bond18.05 (= 18.05-1),
> librte-pmd-crypto-scheduler18.05 (= 18.05-1), librte-pmd-cxgbe18.05
> (=
> 18.05-1), librte-pmd-dpaa-event18.05 (= 18.05-1),
> librte-pmd-dpaa-sec18.05 (= 18.05-1), librte-pmd-dpaa18.05 (=
> 18.05-1), librte-pmd-dpaa2-18.05 (= 18.05-1),
> librte-pmd-dpaa2-cmdif18.05 (= 18.05-1), librte-pmd-dpaa2-event18.05
> (= 18.05-1), librte-pmd-dpaa2-qdma18.05 (= 18.05-1),
> librte-pmd-dpaa2-sec18.05 (= 18.05-1), librte-pmd-e1000-18.05 (=
> 18.05-1), librte-pmd-ena18.05 (= 18.05-1), librte-pmd-enic18.05 (=
> 18.05-1), librte-pmd-failsafe18.05 (= 18.05-1), librte-pmd-fm10k18.05
> (= 18.05-1), librte-pmd-i40e18.05 (= 18.05-1),
> librte-pmd-ifpga-rawdev18.05 (= 18.05-1), librte-pmd-ixgbe18.05 (=
> 18.05-1), librte-pmd-lio18.05 (= 18.05-1), librte-pmd-mlx4-18.05 (=
> 18.05-1), librte-pmd-mlx5-18.05 (= 18.05-1), librte-pmd-nfp18.05 (=
> 18.05-1), librte-pmd-null-crypto18.05 (= 18.05-1),
> librte-pmd-null18.05 (= 18.05-1), librte-pmd-octeontx-ssovf18.05 (=
> 18.05-1), librte-pmd-octeontx18.05 (= 18.05-1),
> librte-pmd-opdl-event18.05 (= 18.05-1), librte-pmd-openssl18.05 (=
> 18.05-1), librte-pmd-pcap18.05 (= 18.05-1), librte-pmd-qede18.05 (=
> 18.05-1), librte-pmd-ring18.05 (= 18.05-1),
> librte-pmd-skeleton-event18.05 (= 18.05-1),
> librte-pmd-skeleton-rawdev18.05 (= 18.05-1), librte-pmd-softnic18.05
> (= 18.05-1), librte-pmd-sw-event18.05 (= 18.05-1), librte-pmd-
> tap18.05
> (= 18.05-1), librte-pmd-thunderx-nicvf18.05 (= 18.05-1),
> librte-pmd-vdev-netvsc18.05 (= 18.05-1), librte-pmd-vhost18.05 (=
> 18.05-1), librte-pmd-virtio-crypto18.05 (= 18.05-1),
> librte-pmd-virtio18.05 (= 18.05-1), librte-pmd-vmxnet3-uio18.05 (=
> 18.05-1), librte-port18.05 (= 18.05-1), librte-power18.05 (= 18.05-
> 1),
> librte-rawdev18.05 (= 18.05-1), librte-reorder18.05 (= 18.05-1),
> librte-ring18.05 (= 18.05-1), librte-sched18.05 (= 18.05-1),
> librte-security18.05 (= 18.05-1), librte-table18.05 (= 18.05-1),
> librte-timer18.05 (= 18.05-1), librte-vhost18.05 (= 18.05-1)"

Bug#905050: mpv: why does mpv tell it's built on unknown

[shirish शिरीष]

at bottom :-

On 31/07/2018, James Cowgill  wrote:
> Hi,
>
> On 31/07/18 07:07, shirish शिरीष wrote:



>
>> At times when I'm running a video, I get this ffmpeg warning -
>>
>> [ffmpeg] NULL: Failed to parse extradata
>>
>> and have no idea why that error triggrs.
>
> Probably a broken input file. Does this only happen for some files?
>
> James
>

With quite a few more media files than I care to admit. It could be
something that a newer encoder could fix when encoding a media file,
dunno what. I'll try to see if somebody knows  a better de-bugging way
so I know what's missing or broken and try to see if there is
something that needs fixing.

Please share if anybody from the debian-multimedia can help in
identifying what could be done or info. found out .


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

Bug#905006: debian-edu: suggesting to add 3 new packages based on education level

[Holger Levsen]

On Tue, Jul 31, 2018 at 10:59:22PM +0530, Deepanshu wrote:
> On Tue, Jul 31, 2018 at 10:19 AM Holger Levsen 
> wrote:
> 
> 
> > please explain your plans here.
> >
> >
> Sure. 

please send this to 905...@bugs.debian.org, not me

> I have also created a merge request -
> https://salsa.debian.org/debian-edu/debian-edu/merge_requests/1

as I see it, this request just removes two packages, but doesnt explain
what you want to do with this new packages.

I might be too tired...


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#894978: lightning: Unable to create event with experimental version (working before migration to 58)

[Eric Valette]

On Fri, 27 Jul 2018 12:09:22 +0800 Carsten Schoenert 
 wrote:

Hello Eric,

On Thu, Apr 05, 2018 at 09:35:01PM +0200, Eric Valette wrote:
> Wanted to send an event as a reminder and was uable to vreate the
> event either by clicking, or keyboard.

how this looks like in recent version in experimental?
Still not working?



Well, as many thing broke related to extension, I  did not migrate. But 
the now stable 58 version does work.


Bug can probably be closed.

--eric

Bug#905147: lektor: Fails to install plugin

[Louis]

Package: lektor
Version: 3.1.1-1
Severity: normal

Dear Maintainer,
lektor fails to install plugins.

To reproduce this bug (only the last item fails).

1. Quickstart a lektor project (with default values).

$ lektor quickstart

2. Cd to the project directory, and build website.

$ cd DIRECTORY
$ lektor build

3. Everything is ok. Install a new plugin.

$ lektor plugins add lektor-markdown-highlighter
Package lektor-markdown-highlighter (0.3) was added to the project

4. Build project again.

$ lektor build
Updating packages in 
/home/louis/.cache/lektor/packages/8c910ec22f2d10ee8aeba5877bafc1eb for project
Collecting lektor-markdown-highlighter==0.3
  Using cached 
https://files.pythonhosted.org/packages/fb/c8/422a2b862df0d9fb518bcf4e14ce0ca900b2542c8f4db18a66898d3f0e0c/lektor_markdown_highlighter-0.3-py3-none-any.whl
Collecting Pygments (from lektor-markdown-highlighter==0.3)
  Using cached 
https://files.pythonhosted.org/packages/02/ee/b6e02dc6529e82b75bb06823ff7d005b141037cb1416b10c6f00fc419dca/Pygments-2.2.0-py2.py3-none-any.whl
Installing collected packages: Pygments, lektor-markdown-highlighter
Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in 
main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/commands/install.py", line 360, 
in run
prefix=options.prefix_path,
  File "/usr/lib/python3/dist-packages/pip/req/req_set.py", line 784, in 
install
**kwargs
  File "/usr/lib/python3/dist-packages/pip/req/req_install.py", line 851, 
in install
self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/usr/lib/python3/dist-packages/pip/req/req_install.py", line 1064, 
in move_wheel_files
isolated=self.isolated,
  File "/usr/lib/python3/dist-packages/pip/wheel.py", line 247, in 
move_wheel_files
prefix=prefix,
  File "/usr/lib/python3/dist-packages/pip/locations.py", line 153, in 
distutils_scheme
i.finalize_options()
  File "/usr/lib/python3.6/distutils/command/install.py", line 274, in 
finalize_options
raise DistutilsOptionError("can't combine user with prefix, "
distutils.errors.DistutilsOptionError: can't combine user with prefix, 
exec_prefix/home, or install_(plat)base
Traceback (most recent call last):
  File "/usr/bin/lektor", line 11, in 
load_entry_point('Lektor==3.1.1', 'console_scripts', 'lektor')()
  File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 64, in 
new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/lektor/cli.py", line 214, in 
build_cmd
ctx.load_plugins()
  File "/usr/lib/python3/dist-packages/lektor/cli.py", line 130, in 
load_plugins
load_packages(self.get_env(), reinstall=reinstall)
  File "/usr/lib/python3/dist-packages/lektor/packages.py", line 306, in 
load_packages
refresh=reinstall)
  File "/usr/lib/python3/dist-packages/lektor/packages.py", line 276, in 
update_cache
download_and_install_package(package_root, package, version)
  File "/usr/lib/python3/dist-packages/lektor/packages.py", line 105, in 
download_and_install_package
raise RuntimeError('Failed to install dependency package.')
RuntimeError: Failed to install dependency package.

In the last `lektor build`, lektor tries to install (in a custom
virtualenv) the newly added plugin, but this installation fails. I
expected it to succeed and to correctly build my website.

Regards,
Louis


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

Kernel: Linux 4.17.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)
LSM: AppArmor: enabled

Versions of packages lektor depends on:
ii  python33.6.5-3
ii  python3-babel  2.4.0+dfsg.1-2
ii  python3-click  6.7-5
ii  

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> We never break packages in testing (unless it's a critical situation, and this
> obviously isn't). Also the cruft package in unstable doesn't hurt much, so it
> can be left around for a while longer. What we want to do here is to get rid 
> of
> the old library in testing in order to finish the transition there: the only 
> two
> options for that are to remove scilab or to fix it. Given it's a key package 
> and
> probably has rdeps that'd mean the latter.

Okay. scilab received an upload an built properly. This was the only
keypackage. We have four packages left, none of them is in testing. Can
we close this transition now? :)

> Cheers,
> Emilio

Sebastian

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Sune Vuorela]

On Tuesday, July 31, 2018 8:48:42 PM CEST John Paul Adrian Glaubitz wrote:
> It's still a bad practice, in my personal opinion, because it adds
> redundancy.

It is kind of - from an upstream POV - what kind of situation you optimize 
for. 

 - embedding the resources in the executable or library  might add redundancy 
if someone distributes several versions, but disk space is cheap in these 
sizes.
 - not embedding the resources on some platforms gives different code paths. 
Code paths are quite expensive from a testing POV.
 - not embedding the resources on all platforms gives quite bigger deployment 
issues on some platforms. (windows, mac, some mobile targets)
 - embedding resources make the resources harder to hack/modify on disk. Some 
think it is an advantage. Others a disadvantage.
 - on some platforms, embedding resources gives faster startup and resource 
access. (Especially windows)

So embedding resources if you target cross platformness, and your resources 
aren't too big and not actually shared with others often the easiest and 
cheapest way forward. It costs mirroring linux distributions a slight disk 
overhead, but I don't think that is too big of a problem.

But, more and more are going to need libclang. Given libclang is mostly a c++ 
parser, I don't see why it shouldn't be buildable on most platforms ? Can't 
the compiler bits be stripped from the llvm source package on some archs?

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#905148: elpa-racket-mode: Fails to install or upgrade: racket-tests.el:20:1:Error: Cannot open load file: No such file or directory, faceup

[Axel Beckert]

Package: elpa-racket-mode
Version: 20180731+0+g948c8aa-1
Severity: serious

Hi David,

elpa-racket-mode fails to install (on the machine where I'm writing the
report) or upgrade (on some armhf-running Raspberry Pi 2 where I
discovered it first) as follows:

Setting up elpa-racket-mode (20180731+0+g948c8aa-1) ...
tsort: -: input contains a loop:
tsort: emacsen-common
tsort: elpa-s
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Real cl-lib shadowed by compatibility cl-lib? 
(/usr/share/emacs/site-lisp/mmm-mode/cl-lib.el)
cl-declare already defined, not rebinding
cl-dotimes already defined, not rebinding
cl-dolist already defined, not rebinding
cl-dolist already defined, not rebinding
cl-dotimes already defined, not rebinding
Install elpa-s for emacs
install/s-1.12.0: Handling install of emacsen flavor emacs
install/s-1.12.0: byte-compiling for emacs
Install elpa-racket-mode for emacs
install/racket-mode-20170731: Handling install of emacsen flavor emacs
install/racket-mode-20170731: byte-compiling for emacs

In toplevel form:
racket-tests.el:20:1:Error: Cannot open load file: No such file or directory, 
faceup
ERROR: install script from elpa-racket-mode package failed
dpkg: error processing package elpa-racket-mode (--configure):
 installed elpa-racket-mode package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 elpa-racket-mode

Might be a missing file or dependency.

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages elpa-racket-mode depends on:
ii  elpa-s 1.12.0-1
ii  emacs  1:25.2+1-8
ii  emacs-gtk [emacs]  1:25.2+1-8
ii  emacsen-common 3.0.2

Versions of packages elpa-racket-mode recommends:
ii  emacs  1:25.2+1-8
ii  emacs-gtk [emacs]  1:25.2+1-8

elpa-racket-mode suggests no packages.

-- no debconf information

Bug#905149: restic: Should Recommend fuse for mounting backups

[Jacob Adams]

Package: restic
Severity: wishlist

In order to mount a restic repository, the fuse package needs to be
installed. As this is fairly standard functionality, restic should
probably Recommend it.

Thanks,
Jacob

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

Kernel: Linux 4.17.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)
LSM: AppArmor: enabled

Versions of packages restic depends on:
ii  libc6  2.27-5

restic recommends no packages.

Versions of packages restic suggests:
ii  libjs-jquery  3.2.1-1
ii  libjs-underscore  1.8.3~dfsg-1

Bug#897790: [NMU] Re: Bug#897790: liboping: ftbfs with GCC-8

[Axel Beckert]

Control: tag -1 + pending

Hi Tokkee and Barak,

Niko Tyni wrote:
> > The package fails to build in a test rebuild on at least amd64 with
> > gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The
> > severity of this report will be raised before the buster release.
> 
> There's an upstream patch for this at
> 
>  
> https://github.com/octo/liboping/commit/18ca43507b351f339ff23062541ee8d58e813a53

I've prepared an NMU which includes this patch and fixes the FTBFS.
Since there was no maintainer reaction at all, not even since the bug
report became RC about two weeks ago, it should be eligble even for a
zero-day NMU.

But since I also added a debian/clean to be able to build the package
twice in a row, I intend to upload it after this mail to DELAYED/2 to
give yoiu some time to object to the NMU.

Feel free to tell me if I should fast-forward the NMU and upload it
directly.

Full source debdiff:

diff -Nru liboping-1.10.0/debian/changelog liboping-1.10.0/debian/changelog
--- liboping-1.10.0/debian/changelog2018-03-21 14:57:02.0 +0100
+++ liboping-1.10.0/debian/changelog2018-07-31 22:15:09.0 +0200
@@ -1,3 +1,12 @@
+liboping (1.10.0-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix FTBFS with GCC 8. (Closes: #897790)
+  * Create debian/clean with src/mans/*.[38] to be able to build twice in
+a row.
+
+ -- Axel Beckert   Tue, 31 Jul 2018 22:15:09 +0200
+
 liboping (1.10.0-2) unstable; urgency=medium
 
   * Bump policy
diff -Nru liboping-1.10.0/debian/clean liboping-1.10.0/debian/clean
--- liboping-1.10.0/debian/clean1970-01-01 01:00:00.0 +0100
+++ liboping-1.10.0/debian/clean2018-07-31 22:11:20.0 +0200
@@ -0,0 +1 @@
+src/mans/*.[38]
diff -Nru 
liboping-1.10.0/debian/patches/cherry-pick_18ca4350_ping_host_add_Decrease_buffer_size_to_make_GCCs_truncation_check_happy.patch
 
liboping-1.10.0/debian/patches/cherry-pick_18ca4350_ping_host_add_Decrease_buffer_size_to_make_GCCs_truncation_check_happy.patch
--- 
liboping-1.10.0/debian/patches/cherry-pick_18ca4350_ping_host_add_Decrease_buffer_size_to_make_GCCs_truncation_check_happy.patch
1970-01-01 01:00:00.0 +0100
+++ 
liboping-1.10.0/debian/patches/cherry-pick_18ca4350_ping_host_add_Decrease_buffer_size_to_make_GCCs_truncation_check_happy.patch
2018-07-31 22:06:51.0 +0200
@@ -0,0 +1,21 @@
+Origin: commit 18ca43507b351f339ff23062541ee8d58e813a53
+Author: Florian Forster 
+Bug: https://github.com/octo/liboping/issues/38
+Bug-Debian: https://bugs.debian.org/897790
+Description: ping_host_add: Decrease buffer size to make GCC's truncation 
check happy.
+
+--- a/src/liboping.c
 b/src/liboping.c
+@@ -1605,10 +1605,8 @@
+   }
+   else
+   {
+-  char errmsg[PING_ERRMSG_LEN];
+-
+-  snprintf (errmsg, PING_ERRMSG_LEN, "Unknown 
`ai_family': %i", ai_ptr->ai_family);
+-  errmsg[PING_ERRMSG_LEN - 1] = '\0';
++  char errmsg[64];
++  snprintf (errmsg, sizeof(errmsg), "Unknown `ai_family': 
%d", ai_ptr->ai_family);
+ 
+   dprintf ("%s", errmsg);
+   ping_set_error (obj, "getaddrinfo", errmsg);
diff -Nru liboping-1.10.0/debian/patches/series 
liboping-1.10.0/debian/patches/series
--- liboping-1.10.0/debian/patches/series   2018-03-21 14:57:02.0 
+0100
+++ liboping-1.10.0/debian/patches/series   2018-07-31 22:04:48.0 
+0200
@@ -1,3 +1,4 @@
 0002-autoupdate-and-enable-automake-Wall.patch
 0003-typo.patch
 debian-changes
+cherry-pick_18ca4350_ping_host_add_Decrease_buffer_size_to_make_GCCs_truncation_check_happy.patch

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


signature.asc
Description: Digital signature

Bug#905150: transition: libpqxx

[Marcin Kulisz]

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

There is a soname change requiring this transition, as well as I'd like to fix
package naming convencion which right now doesn't match soname.

Ben file:

title = "libpqxx";
is_affected = .depends ~ "libpqxx6" | .depends ~ "libpqxx-6.2";
is_good = .depends ~ "libpqxx-6.2";
is_bad = .depends ~ "libpqxx6";


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

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

Bug#905150: transition: libpqxx

[Sebastiaan Couwenberg]

Control

On 07/31/2018 10:32 PM, Marcin Kulisz wrote:
> There is a soname change requiring this transition, as well as I'd like to fix
> package naming convencion which right now doesn't match soname.

Please note that the update package has already been uploaded to
unstable and only osm2pgrouting & sqlsmith need binNMUs.

Kind Regards,

Bas

Bug#905146: Breaks+Replaces

[kuLa]

Hi Andreas,

Thx for this report, I'm not sure how it have happened that piuparts didn't
report any issues when I was testing it locally, but it doesn't really
matter right now.

In regards to what you suggest for Breaks+Replaces, do you mean this:

Replaces: libpqxx6 (>= 6.2)
Breaks:  libpqxx6 (>= 6.2)

To be honest I'm not sure if this is what we need as libpqxx-6.2.so has been
introduced in 6.2.4-2 and 6.2.4-3 is broken for upgrade. If I'll upload 6.2.4-4
then I'd expect to replace all earlier versions of 6.2, so I'd expect B+R as
below:

Replaces: libpqxx-6.2 (<< ${binary:Version})
Breaks:  libpqxx-6.2 (<< ${binary:Version})

But I have to say that I'm not 100% sure about it, so if you could shade a bit
more light on what you think it'd be great.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John Paul Adrian Glaubitz]

On 07/31/2018 09:16 PM, Sune Vuorela wrote:
>  - not embedding the resources on all platforms gives quite bigger deployment 
> issues on some platforms. (windows, mac, some mobile targets)

macOS always puts the resource files into separate folders inside the app bundle
(which is just a folder). At least when I did professional Qt development.

>  - on some platforms, embedding resources gives faster startup and resource 
> access. (Especially windows)

I think that difference is negligible. Plus, we're also not talking about
Windows or macOS here, so the situation is not comparable. On Debian, we
do have multiple versions of the same binary and storing the resource
files is explicitly desired as it makes a difference in disk space when
we're talking about hundreds or thousands of packages.

> So embedding resources if you target cross platformness, and your resources 
> aren't too big and not actually shared with others often the easiest and 
> cheapest way forward. It costs mirroring linux distributions a slight disk 
> overhead, but I don't think that is too big of a problem.

You're basically using the arguments for the Windows and macOS versions
on Debian. In Debian, saving disk space through redundancy does defnitely
make a difference.

> But, more and more are going to need libclang. Given libclang is mostly a c++ 
> parser, I don't see why it shouldn't be buildable on most platforms ? Can't 
> the compiler bits be stripped from the llvm source package on some archs?

That has to be seen. As I said, we're working on it. But it takes some
time.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#902831: wireguard-tools: /etc/wireguard permissions are open to the world, leaking private keys

[Daniel Kahn Gillmor]

Hi Mike--

On Sun 2018-07-01 13:16:56 -0700, Mike Swanson wrote:

> When installing wireguard-tools, the /etc/wireguard directory is created
> that can contain configuration files for the wg-quick service to use.
>
> These configuration files will contain the private key of the local
> machine for the VPN configuration, and as such, the default mode (755)
> for the directory is unsuitable for production use, since it creates an
> opportunity for any user to be able to print out the contents of the
> configuration files (if they were not changed to mode 600 themselves),
> and potentially break the security model of the Wireguard VPN altogether.

as you identify, the mode of the files in /etc/wireguard/ are indeed the
relevant features, not the mode of the parent directory itself.

I'd argue that if the local admin is putting secrets in those files, the
local admin should be responsible for locking them down correctly, and
probably shouldn't rely on the permissions of /etc/wireguard/.

> I propose changing the default mode of the /etc/wireguard directory to 600.
> I do this on my own machines and there is no functionality impact for the
> software, only that the private keys become completely inaccessible for
> anyone but root.

that would also mean that the user of the system cannot see what config
files are available (e.g. for tab completion of "sudo wg-quick up
").

I'm willing to make this change if there are no objections, but it'd be
great to get a clearer sense from other users whether this is a sensible
thing to do.

--dkg


signature.asc
Description: PGP signature

Bug#904380: (no subject)

[Timothy Pearson]

Just wanted to see if this was something we could get applied to the
kernel.  Right now people are needing to rebuild their kernels locally
to update firmware, or use a more complex out of band update mechanism,
which is not ideal.