Bug#890341: telegram-desktop: OpenType support missing for "Open Sans Semibold", script 11 in telegram-desktop

[shirish शिरीष]

Package: telegram-desktop
Version: 1.2.6-2
Severity: normal

Dear Maintainer,

I was running telegram-desktop and came across couple of bugs -

/home/shirish> telegram-desktop
QIODevice::read (QNetworkReplyHttpImpl): device not open
QIODevice::read (QNetworkReplyHttpImpl): device not open
  OpenType support missing for "Open Sans Semibold", script 11
  OpenType support missing for "Open Sans", script 11
  OpenType support missing for "Open Sans", script 11

Although the chat window was working and I was able to see, type everything.

There were more but I installed

 apt-cache policy fonts-open-sans
fonts-open-sans:
  Installed: 1.11-1
  Candidate: 1.11-1
  Version table:
 *** 1.11-1 900
900 http://httpredir.debian.org/debian buster/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

As can be seen fonts-open-sans neither has a dependency or even a
suggests to telegram-desktop which it should have.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8
(charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages telegram-desktop depends on:
ii  libavcodec57 7:3.4.1-1+b2
ii  libavformat577:3.4.1-1+b2
ii  libavutil55  7:3.4.1-1+b2
ii  libc62.26-6
ii  libgcc1  1:7.2.0-19
ii  libglib2.0-0 2.54.3-2
ii  libminizip1  1.1-8+b1
ii  libopenal1   1:1.18.2-2
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-9
ii  libqt5dbus5  5.9.2+dfsg-9
ii  libqt5gui5   5.9.2+dfsg-9
ii  libqt5network5   5.9.2+dfsg-9
ii  libqt5widgets5   5.9.2+dfsg-9
ii  libssl1.11.1.0g-2
ii  libstdc++6   7.2.0-19
ii  libswresample2   7:3.4.1-1+b2
ii  libswscale4  7:3.4.1-1+b2
ii  libtgvoip1.0 1.0~git20170704.445433f-4
ii  libx11-6 2:1.6.4-3
ii  qt5-image-formats-plugins5.9.2-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages telegram-desktop recommends:
ii  libappindicator3-1  0.4.92-5

telegram-desktop suggests no packages.

-- no debconf information


-- 
  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#890340: Unable to checkout Grafana 4.6.3

[Marcin Juszkiewicz]

Package: dh-make-golang
Version: 0.0~git20180129.37f630a-1

Go packagers suggest using 'dh-make-golang' to create skeleton package for 
software written in Go. So I tried it:

16:28 (0s) linaro@cb-r1-m1-c1n1:dh-make-golang$ dh-make-golang -git_revision 
v4.6.3   github.com/grafana/grafana 

2018/02/13 16:28:15 Downloading "github.com/grafana/grafana/..."
   
go get: 240.09 MiB2018/02/13 16:29:38 Checking out git revision "v4.6.3"
   
2018/02/13 16:29:38 Refreshing "github.com/grafana/grafana/..." 
   
go get: 516.27 MiBpackage assert: unrecognized import path "assert" (import 
path does not begin with hostname) 
2018/02/13 16:30:43 Could not create a tarball of the upstream source: exit 
status 1


Same result with version in 'stretch', 'sid' or with one built from git HEAD.

Bug#889356: Pending fixes for bugs in the httpcomponents-client package

[pkg-java-maintainers]

tag 889356 + pending
thanks

Some bugs in the httpcomponents-client package are closed in revision
bbeace96bc993f432ad992578b06f5f25f44ed05 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/httpcomponents-client.git/commit/?id=bbeace9

Commit message:

Removed Damien Raude-Morvan from the uploaders (Closes: #889356)

Bug#887209: debootstick should depend on e2fsprogs explicitly

[Andreas Henriksson]

Control: tags -1 + pending

Hello again,

After spending time on analysing and writing a followup on the bug
report I noticed the package tracker saying there's a new version
in the git repository that claims to have this issue fixed (and
the version release to unstable on 31 jan 2018!).

I'm thus tagging the bug as pending and hoping we'll soon see the
version actually be part of the debian archive.

Regards,
Andreas Henriksson

Bug#890338: bugs.debian.org: Please add dd rel="canonical" links to bug pages

[Chris Lamb]

Package: bugs.debian.org
Severity: wishlist
Tags: patch

Hi,

Attached is the following:

  commit 7068a3d4cc8dab4878db4341b0bace9463d18dfd
  Author: Chris Lamb 
  Date:   Tue Feb 13 16:07:43 2018 +
  
  Add rel="canonical" links to bug pages.
  
   templates/en_US/cgi/bugreport.tmpl | 1 +
   1 file changed, 1 insertion(+)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
>From 7068a3d4cc8dab4878db4341b0bace9463d18dfd Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Tue, 13 Feb 2018 16:07:43 +
Subject: [PATCH] Add rel="canonical" links to bug pages.

---
 templates/en_US/cgi/bugreport.tmpl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/templates/en_US/cgi/bugreport.tmpl b/templates/en_US/cgi/bugreport.tmpl
index 2f0ec04..d264df6 100644
--- a/templates/en_US/cgi/bugreport.tmpl
+++ b/templates/en_US/cgi/bugreport.tmpl
@@ -1,4 +1,5 @@
 {include(q(html/pre_title))}#{$bug_num} - {html_escape($status{subject})} - {html_escape($config{project})} {html_escape($config{bug})} report logs{include(q(html/post_title.tmpl))}
+
 

Bug#887201: cyrus-common should depend on e2fsprogs explicitly

[Andreas Henriksson]

On Sun, Jan 14, 2018 at 08:03:29PM +0100, Helmut Grohne wrote:
> Package: cyrus-common
[...]
> /usr/lib/cyrus/bin/makedirs contains chattr. According to file it is a POSIX 
> shell script, ASCII text executable
[...]

This file is found at debian/cyrus-makedirs in the source and indeed
uses the chattr command.

The file is renamed/installed via debian/rules as:
install debian/cyrus-makedirs $(TMPPKG)/usr/lib/cyrus/bin/makedirs

(And then installed in cyrus-common package via debian/cyrus-common.install)

The debian/README.Debian refers to cyrus-makedirs in multiple places
and among others says:
 o You can use /usr/sbin/cyrus-makedirs to generate the needed directories
 [...]
.. but there's so such file shipped. It seems like the cyrus-makedirs
might have been available under it's original name earlier and only
later got renamed/moved into a location where I assume it's executed
via a wrapper command (similar to how 'git foo' works).

Assuming the wrapper command is 'cyrus' (which seems to align well with
a cursory glance at ./debian/cyrus ) the makedirs script might be
invoked  from the debian/cyrus-common.postinst :
if [ -z "$2" ]; then
echo -n "cyrus-common: Creating cyrus-imapd directories..."
cyrus makedirs --cleansquat
echo "done."
fi

There are also several other places which references cyrus-makedirs
and even a cyrus-makedirs.8 manpage.

My conlusion is thus that a dependency seems warranted (along with a
good cleanup), but given that the package is already RC buggy and has
been removed from testing a long time ago and that noone seems to be
interested it might simply be better to ask for the package to be
removed (from unstable).

Would be great to hear from maintainers (or anyone else interested!) about
this

Regards,
Andreas Henriksson

Bug#887209: debootstick should depend on e2fsprogs explicitly

[Andreas Henriksson]

Control: tags -1 + confirmed

On Sun, Jan 14, 2018 at 08:03:41PM +0100, Helmut Grohne wrote:
> Package: debootstick
[...]
> /usr/share/debootstick/scripts/create-image/functions contains dumpe2fs, 
> mkfs.ext4 and resize2fs. According to file it is a ASCII text

dumpe2fs and resize2fs are only mentioned in comments.
Only mkfs.ext4 is actually used in the codes make_root_fs() function.

The make_root_fs function is called from create_formatted_image()
(in the same file), and the create_formatted_image function is called
twice unconditionally in the main debootstick script.

(For comparison mkfs.vfat is also used in the same file and dosfstools
is already listed in depends.)

> /usr/share/debootstick/scripts/live/init/migrate-to-disk.sh contains 
> resize2fs. According to file it is a Bourne-Again shell script, ASCII text 
> executable
> /usr/share/debootstick/scripts/live/init/occupy-space.sh contains resize2fs. 
> According to file it is a POSIX shell script, ASCII text executable
[...]

It seems both of the above files actually uses resize2fs.
(No deeper analysis given the previous file already seem to have
made it clear mkfs.ext4 from e2fsprogs is crutial.)

My conclusion is thus that a dependency on e2fsprogs should be added.

Would be great to hear from maintainers on this... Even if it's just to
say that an NMU to take care of this would be appreciated.


Regards,
Andreas Henriksson

Bug#890282: getmail: please ship with shebang line of #!/usr/bin/env python2

[Osamu Aoki]

HI,

On Mon, Feb 12, 2018 at 04:53:26PM -0500, Daniel Kahn Gillmor wrote:
> Package: getmail
> Version: 5.5-2
> Severity: normal
> 
> Getmail does not work with python3, and upstream has indicated that
> they are not likely to port it.
> 
> According to PEP 394 [0], it should use a python2 shebang line, so
> that systems can eventually switch /usr/bin/python to be supplied by
> python3.

YES #!/usr/bin/python2

NO  #!/usr/bin/env python2

Please read Debian Python policy.
https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#interpreter-directive
4.1. Interpreter directive (“Shebang”)

Executables written for interpretation by Python must use an appropraite
interpreter directive, or “shebang”, as the first line of the program.
This line should be of the form #!interpreter_location. See Section
2.4.1, “Interpreter Name” for the interpreter name to use.

As noted in Section 2.4.2, “Interpreter Location”, the form
#!/usr/bin/env interpreter_name is deprecated.

. I see typo. s/appropraite/appropriate/

Bug#890339: gnuradio: ControlPort not usable because gnuradio was compiled without Thrift

[Thomas L]

Package: gnuradio
Version: 3.7.10.1-2+b3
Severity: normal

Dear Maintainer,

The GNU Radio's ControlPort feature has a dependency on Apache Thrift (cf.
https://wiki.gnuradio.org/index.php/ControlPort).
However, the Debian package was not compiled with this dependency (cf. Debian
log file
https://buildd.debian.org/status/fetch.php?pkg=gnuradio=amd64=3.7.11-8=1518326331=0
:

-- Checking for module 'thrift'
--   No package 'thrift' found
-- Binary 'thrift' not found.
).


Moreover, the Thrift Debian package is outdated (GNU Radio requires >=0.9.2 and
only 0.9.1 is currently available in Debian).

One of the consequences is that the gr-perf-monitorx tool is not working:
~$ gr-perf-monitorx
Traceback (most recent call last):
  File "/usr/bin/gr-perf-monitorx", line 54, in 
from gnuradio.ctrlport.GrDataPlotter import *
  File "/usr/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py",
line 26, in 
from gnuradio.ctrlport.GNURadio import ControlPort
ImportError: No module named GNURadio



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

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

Versions of packages gnuradio depends on:
ii  libasound21.1.3-5
ii  libboost-atomic1.62.0 1.62.0+dfsg-4
ii  libboost-chrono1.62.0 1.62.0+dfsg-4
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libboost-filesystem1.62.0 1.62.0+dfsg-4
ii  libboost-program-options1.62.01.62.0+dfsg-4
ii  libboost-regex1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0 1.62.0+dfsg-4
ii  libboost-thread1.62.0 1.62.0+dfsg-4
ii  libc6 2.24-11+deb9u1
ii  libcodec2-0.4 0.5.1-1+b2
ii  libcomedi00.10.2-4+b3
ii  libfftw3-single3  3.3.5-3
ii  libgcc1   1:6.3.0-18
ii  libgnuradio-analog3.7.10  3.7.10.1-2+b3
ii  libgnuradio-atsc3.7.103.7.10.1-2+b3
ii  libgnuradio-audio3.7.10   3.7.10.1-2+b3
ii  libgnuradio-blocks3.7.10  3.7.10.1-2+b3
ii  libgnuradio-channels3.7.103.7.10.1-2+b3
ii  libgnuradio-comedi3.7.10  3.7.10.1-2+b3
ii  libgnuradio-digital3.7.10 3.7.10.1-2+b3
ii  libgnuradio-dtv3.7.10 3.7.10.1-2+b3
ii  libgnuradio-fcd3.7.10 3.7.10.1-2+b3
ii  libgnuradio-fec3.7.10 3.7.10.1-2+b3
ii  libgnuradio-fft3.7.10 3.7.10.1-2+b3
ii  libgnuradio-filter3.7.10  3.7.10.1-2+b3
ii  libgnuradio-noaa3.7.103.7.10.1-2+b3
ii  libgnuradio-pager3.7.10   3.7.10.1-2+b3
ii  libgnuradio-pmt3.7.10 3.7.10.1-2+b3
ii  libgnuradio-qtgui3.7.10   3.7.10.1-2+b3
ii  libgnuradio-runtime3.7.10 3.7.10.1-2+b3
ii  libgnuradio-trellis3.7.10 3.7.10.1-2+b3
ii  libgnuradio-uhd3.7.10 3.7.10.1-2+b3
ii  libgnuradio-video-sdl3.7.10   3.7.10.1-2+b3
ii  libgnuradio-vocoder3.7.10 3.7.10.1-2+b3
ii  libgnuradio-wavelet3.7.10 3.7.10.1-2+b3
ii  libgnuradio-wxgui3.7.10   3.7.10.1-2+b3
ii  libgnuradio-zeromq3.7.10  3.7.10.1-2+b3
ii  libgsl2   2.3+dfsg-1
ii  libgsm1   1.0.13-4+b2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  liblog4cpp5v5 1.1.1-3
ii  libportaudio2 19.6.0-1
ii  libpython2.7  2.7.13-2+deb9u2
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libqwt5-qt4   5.2.3-1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libstdc++66.3.0-18
ii  libuhd003 3.9.5-2+b3
ii  libusb-1.0-0  2:1.0.21-1
ii  libvolk1-bin  1.3-1+b4
ii  libvolk1.31.3-1+b4
ii  libzmq5   4.2.1-4
ii  python2.7.13-2
ii  python-cheetah2.4.4-4
ii  python-gtk2   2.24.0-5.1
ii  python-lxml   3.7.1-1
ii  python-opengl 3.1.0+dfsg-1
ii  python-qt44.11.4+dfsg-2+b1
ii  python-sip4.18.1+dfsg-2
ii  python-wxgtk3.0   3.0.2.0+dfsg-4
ii  python-zmq16.0.2-2

Versions of packages gnuradio recommends:
ii  gnuradio-dev   3.7.10.1-2+b3
ii  python-matplotlib  2.0.0+dfsg1-2
ii  python-networkx1.11-2
ii  python-numpy   1:1.12.1-3
ii  python-qwt5-qt45.2.1~cvs20091107+dfsg-8
ii  python-scipy   0.18.1-2
ii  python-tk  2.7.13-1
ii  rtl-sdr0.5.3-11+b2
ii  uhd-host 

Bug#890286: upstream bug link

[Chad William Seys]

Upstream bug:
https://github.com/oetiker/rrdtool-1.x/issues/876

Bug#890016: fig2dev: null dereference while running fig2dev

[Roland Rosenfeld]

Hi Thomas!

> would you mind to wait for the next release, which should be due in
> about two to four weeks? Bug #890016 is triggered by a pointer in an
> object struct which is left un-initialized in read1_3.c. The code in
> read1_3.c is full of these things and needs more proper initializing
> and sanitizing.

No problem with waiting.  I know, that you are already working on some
input sanitizing for fig2dev, and I only forwarded the two new bugs to
you to have it documented in the Debian BTS correctly and to give you
more test files to check whether you found all code blocks where input
sanitizing is necessary...

It's great to hear, that you seem to have some progress with this,
since it's only two to four weeks now.

Tell me, if I can support you in some way.

Greetings
Roland

Bug#859263: Bug#865599: bash can stop disabling PIE

[Raphael Hertzog]

Hello,

On Tue, 13 Feb 2018, Raphael Hertzog wrote:
> Unfortunately enabling PIE breaks usage of bash in qemu-user
> (see #889869) which makes it impossible to debootstrap any foreign
> architecture.

FYI I forwarded this upstream:
https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080

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/

Bug#890313: [DAViCal-devel] Bug#890313: awl: please make the build reproducible

[Chris Lamb]

Hi Florian,

Thank you for kind words re. reproducible builds.

> Isn't that a general doxygen issue, rather than of a package that
> happens to use doxygen with an @example tag?

That's very likely. I did try setting FULL_PATH_NAMES to "no" (the
usual fix for this problem) but it didn't seem to work, so I suspected
some awl-specific...  I am happy to be corrected however. :)

In case it helps (and for a more permanent reference) here is the diff:

  https://gist.github.com/lamby/d1ca2efc9e70e8590f3b26a24b84a150/raw


Best wishes,

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

Bug#890324: piuparts-master backup strategy

[Holger Levsen]

On Tue, Feb 13, 2018 at 01:22:08PM +, Holger Levsen wrote:
> > /srv/piuparts.debian.org/htdocs with a few flat directories with a huge
> > number of small files.  This causes backups to take too long and too
> > much space (and/or fail because they're taking too long).

I've just created that file, everything in /htdocs is generated, looking at
other directories in /srv/piuparts.debian.org/ now, assuming the rest (/) is
set up by DSA nicely already.

For restoring piuparts.debian.org all we need is in
/srv/piuparts.debian.org/, the stuff in the home directories or /etc all
comes from piuparts.git (or Debian main or DSA).


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#890313: [DAViCal-devel] Bug#890313: awl: please make the build reproducible

[Florian Schlichting]

Hi Chris,

thanks for working tirelessly on reproducible builds!

> Whilst working on the Reproducible Builds effort [0], we noticed
> that awl could not be built reproducibly as it includes the
> absolute build path in the doxygen output of an example.

Isn't that a general doxygen issue, rather than of a package that
happens to use doxygen with an @example tag?

Not generating API documentation for part of the API kind of defeats the
purpose of having an API documentation in the first place. So if this is
to be fixed in awl instead of in doxygen, instead of your patch I'd tend
to review the use of @example tags in inc/iCalendar.php - which seem to
produce entirely broken output with doxygen anyway :-(

Florian

Bug#890333: gitlab: javascript errors after upgrade to 9.5.4

[Pirate Praveen]

On 02/13/2018 08:19 PM, Libor Klepáč wrote:
> Package: gitlab
> Version: 9.5.4.+dfsg-2
> Severity: normal
> 
> Hello,
> after upgrading gitlab from 8.13.x to 9.5.4 we get no events in dashboard 
> grids.

Thanks for testing the new version. We need to fix this before uploading
to unstable.

> Errors in firefox console  are
> ReferenceError: Controller is not defined [Zjistit více]
> common.bundle.js:19235:1
> ../../../../javascript/jquery-atwho/jquery.atwho.js/ https://192.168.6.10/assets/webpack/common.bundle.js:19235:1
> ../../../../javascript/jquery-atwho/jquery.atwho.js/<   
> https://192.168.6.10/assets/webpack/common.bundle.js:19149:2
> ../../../../javascript/jquery-atwho/jquery.atwho.js 
> https://192.168.6.10/assets/webpack/common.bundle.js:18608:29
> __webpack_require__ 
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
> ./commons/jquery.js 
> https://192.168.6.10/assets/webpack/common.bundle.js:21974:78
> __webpack_require__ 
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
> ./commons/index.js  
> https://192.168.6.10/assets/webpack/common.bundle.js:21953:66
> __webpack_require__ 
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
> webpackJsonpCallback
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:26:23
> 
> 
> and
> 
> TypeError: 
> __WEBPACK_IMPORTED_MODULE_0_document_register_element___default(...) is not a 
> function [Zjistit více] main.bundle.js:10029:1
> ./behaviors/gl_emoji.js
> https://192.168.6.10/assets/webpack/main.bundle.js:10029:1
> __webpack_require__
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
> ./behaviors/index.js   
> https://192.168.6.10/assets/webpack/main.bundle.js:10089:68
> __webpack_require__
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
> ./main.js/<
> https://192.168.6.10/assets/webpack/main.bundle.js:22926:71
> ./main.js  
> https://192.168.6.10/assets/webpack/main.bundle.js:22886:29
> __webpack_require__
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
> webpackJsonpCallback   
> https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:26:23
> 
> 
> I also tried to regenerate webapack and assets. It finishes without errors 
> (after instaling node modules indexof and randomfill)
> 
> I also tried generate assets using yarn and
> # bundle exec rake gitlab:assets:compile

You may want to try like this
https://salsa.debian.org/ruby-team/gitlab/blob/master/debian/rake-tasks.sh#L39

> but it does not finish successfuly, complains about missing 
> webpack-stats-plugin, which seems to be installed.
> 
> Any clues what can be done?

Try replacing jquery.atwho.js with the version from npm. (npm install
jquery-atwho, then webpack and asset precompile).

> This all bundler and node and webpack and etc. magic is ... (+ i have to 
> allow traffic to our protected network, for npm to work)

We are getting very close to packaging all dependencies
https://wiki.debian.org/Javascript/Nodejs/Tasks/gitlab

I'm stuck with https://github.com/facebook/react/issues/12076 any help
on this is welcome.




signature.asc
Description: OpenPGP digital signature

Bug#839046: debootstrap: enable --merged-usr by default

[Julien Cristau]

On 02/13/2018 04:29 PM, Raphael Hertzog wrote:
> I believe that we have had quite some testing already last time and I
> would be surprised if we got many more RC bugs on dpkg that had to be fixed
> on a short timeframe. I guess nobody can give you any assurance but
> I'm sure that you can downgrade those bugs pointing to this discussion
> and showing that this was part of the deal.
> 
If we break user systems we don't get to downgrade bugs on the basis
that "we knew we were doing a half assed job with this transition".
That's not part of the deal we're making with our users.

Cheers,
Julien

Bug#890337: Disabling Trackpoint Scrolling via xorg.conf freezes screen/input

[Joachim Breitner]

Package: xserver-xorg-core
Version: 2:1.19.6-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have upgraded xserver-xorg-core and xserver-xorg-legacy from
2:1.19.5-1 to 2:1.19.6-1. When I rebooted, the system (a T460s Thinkpad)
would start, but as soon as the X server is started, the screen would
turn black and no input would be accepted -- not even switching to the
text terminal.

The problem disappeared once I removed the file
/etc/X11/xorg.conf.d/30-scoll.conf with this content:

Section "InputClass"
Identifier "TPPS/2 IBM TrackPoint"
Driver "libinput"
Option "ScrollMethod" "none"
EndSection


I have added the corresponding xorg log to the list of log files below,
note how it stops abruptly at

[   187.857] (II) event9  - (II) Integrated Camera: Integrated C: (II) is 
tagged by udev as: Keyboard
[   187.857] (II) event9  - (II) Integrated Camera: Integrated C: (II) device 
is a keyboard
[   187.858] (II) config/udev: Adding input device (unnamed) (/dev/ttyS0)
[   187.858] (**) (unnamed): Applying InputClass "TPPS/2 IBM TrackPoint"
[   187.858] (II) Using input driver 'libinput' for '(unnamed)'
[   187.858] (**) (unnamed): always reports core events
[   187.858] (**) Option "Device" "/dev/ttyS0"
[   187.858] (**) Option "_source" "server/udev"

Cheers,
Joachim



- -- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
- --
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 520 
[8086:1916] (rev 07)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
- -
total 8
- -rw-r--r-- 1 root root 168 Oct  6  2016 20-backlight.conf
- -rw-r--r-- 1 root root 316 Feb 13 10:00 30-scoll.conf-disabled

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
- ---
Linux version 4.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)

Xorg X server log files on system:
- --
- -rw-r--r-- 1 root root 38435 Feb 13 10:02 /var/log/Xorg.0.log
- -rw-r--r-- 1 root root 15114 Feb 13 10:01 /var/log/Xorg.0.log.old

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
- -
[21.106] 
X.Org X Server 1.19.6
Release Date: 2017-12-20
[21.106] X Protocol Version 11, Revision 0
[21.106] Build Operating System: Linux 4.9.0-5-amd64 x86_64 Debian
[21.106] Current Operating System: Linux kirk 4.14.0-3-amd64 #1 SMP Debian 
4.14.13-1 (2018-01-14) x86_64
[21.106] Kernel command line: BOOT_IMAGE=/vmlinuz-4.14.0-3-amd64 
root=/dev/mapper/kirk--vg-root ro single
[21.106] Build Date: 26 January 2018  04:30:21PM
[21.106] xorg-server 2:1.19.6-1 (https://www.debian.org/support) 
[21.106] Current version of pixman: 0.34.0
[21.106]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[21.106] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[21.106] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 13 10:02:31 
2018
[21.107] (==) Using config directory: "/etc/X11/xorg.conf.d"
[21.107] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[21.107] (==) No Layout section.  Using the first Screen section.
[21.107] (==) No screen section available. Using defaults.
[21.107] (**) |-->Screen "Default Screen Section" (0)
[21.107] (**) |   |-->Monitor ""
[21.108] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[21.108] (**) |   |-->Device "card0"
[21.108] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[21.108] (==) Automatically adding devices
[21.108] (==) Automatically enabling devices
[21.108] (==) Automatically adding GPU devices
[21.108] (==) Max clients allowed: 256, resource mask: 0x1f
[21.109] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[21.109]Entry deleted from font path.
[21.109] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[21.109]Entry deleted from font path.
[21.109] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[21.109]Entry deleted from font path.
[21.110] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[21.110]Entry deleted from font path.
[21.110] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[21.110]Entry deleted from font path.
[21.110] (==) FontPath set to:

Bug#839046: debootstrap: enable --merged-usr by default

[Raphael Hertzog]

On Mon, 12 Feb 2018, Ansgar Burchardt wrote:
> Guillem Jover writes:
> > In any case, I looked the other day into implementing the
> > --map-pathname option for dpkg-query, and I've got most of the code
> > ready. The problem is that this requires adding support for config
> > files and config fragments to dpkg-query, which has the additional
> > problem of making it possible to mess with the --showformat option
> > and breaking the expectations from maintscripts, for example. The
> > other problem is with the search behavior changing depending on the
> > packages providing those mappings being installed (because dpkg would
> > certainly not provide them).
> 
> So who should provide them?  debootstrap?  base-files?

It certainly makes sense for debootstrap to create those files given it
creates the symlinks in the first place.

An alternative solution could be to reuse the usrmerge package and let
debootstrap install this package if it exists. That way the usrmerge
package would exist until Debian switched entirely to put everything into
/usr/bin.

> The correct long-term fix is probably for packages to eventually install
> to the location in /usr anyway.  That doesn't work without some
> transition period of 1-2 releases though.

Ack.

On Mon, 12 Feb 2018, Guillem Jover wrote about usrmerge:
> This seems like a nice PoV for people to play with it, in the same way
> local admins can use, to some extent, symlinks to redirect subtrees to
> other mount points, but I don't see how this can be seen as a
> production-ready solution shipped by default, TBH.

Note that the change in debootstrap does not install usrmerge currently.
It only creates the required symlinks.


But this is enough to confuse "dpkg -S". This used to break dpkg-shlibdeps
and was the main reason for the initial revert. Fortunately dpkg-shlibdeps has
been fixed to try multiple paths until it can find the package owning the
library.


It might be that we will find other tools confused by "dpkg -S" non-answer
on some /lib/* or /usr/lib/* paths and some end users will definitely be 
surprised by
this.

Obviously we can document the problem in release notes but it would be
better to have a clean solution like suggested by Guillem:

> In any case, I looked the other day into implementing the
> --map-pathname option for dpkg-query, and I've got most of the code
> ready.

If this is forthcoming in the buster timeframe, it seems reasonable to
go ahead and re-enable the merged-usr by default. However to be able to
ship the new configuration files once their format is known, it would be
better for debootstrap to install a package whose role will be to provide
those configuration files ASAP after dpkg starts to support them.

> The problem is that this requires adding support for config
> files and config fragments to dpkg-query, which has the additional
> problem of making it possible to mess with the --showformat option
> and breaking the expectations from maintscripts, for example.

Forbid those options there? Do not parse those files if you detect
an environment variable DPKG_RUNNING_VERSION?

> The other problem is with the search behavior changing depending on the
> packages providing those mappings being installed (because dpkg would
> certainly not provide them).

That's the whole point of it so I would not consider this a problem.

> So I'll eventually try to find a solution for the dpkg-query issue,
> because it's a long-standing paper-cut in dpkg for local admins. But
> I'd not be very amused if this hack is enabled by default again and
> suddenly RC bugs start popping up in dpkg again, and people start
> pressuring with RCness to get those fixed again because well, it's
> obviously breaking people's systems…

Are you considering both "usrmerge" and "debootstrap creating symlinks" as
hacks even once they would provide mapping data for dpkg --search?

I believe that we have had quite some testing already last time and I
would be surprised if we got many more RC bugs on dpkg that had to be fixed
on a short timeframe. I guess nobody can give you any assurance but
I'm sure that you can downgrade those bugs pointing to this discussion
and showing that this was part of the deal.

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/

Bug#887222: Bug#887189: golang-github-docker-docker-dev should depend on e2fsprogs explicitly

[Andreas Henriksson]

Hello Tianon,

On Mon, Feb 12, 2018 at 09:47:03AM -0800, Tianon Gravi wrote:
> I agree that this bug as filed doesn't make much sense, but it does
> point to one that does make sense IMO, which would be adding the two
> packages mentioned (e2fsprogs and xfsprogs) to Suggests over in
> docker.io instead (since there are configurations of Docker where it'd
> be appropriate and necessary to have those packages installed).

Thanks for your feedback. Since we seem to be in agreement I'll close
this bug report (via bcc) and for the record copy #887222 which is the bug
report where docker.io dependencies are discussed. Lets continue the
discussion in that bug report if needed.

Regards,
Andreas Henriksson

Bug#890336: gcal FTCBFS: second ./configure is for build architecture

[Helmut Grohne]

Source: gcal
Version: 3.6.3-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gcal fails to cross build from source, because it configures for the
build architecture. It actually (correctly) configures for the host
architecture first (via dh_auto_configure) and the configures *again*
for the build architecture via override_dh_auto_configure. Configuring
just once and doing it through dh_auto_configure fixes the cross build.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru gcal-3.6.3/debian/changelog gcal-3.6.3/debian/changelog
--- gcal-3.6.3/debian/changelog 2013-12-29 18:41:19.0 +0100
+++ gcal-3.6.3/debian/changelog 2018-02-13 06:40:07.0 +0100
@@ -1,3 +1,11 @@
+gcal (3.6.3-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Configure only once and let dh_auto_configure do it. (Closes:
+#-1)
+
+ -- Helmut Grohne   Tue, 13 Feb 2018 06:40:07 +0100
+
 gcal (3.6.3-3) unstable; urgency=low
 
   * apply patch from Logan Rosen  to use autotools-dev
diff --minimal -Nru gcal-3.6.3/debian/rules gcal-3.6.3/debian/rules
--- gcal-3.6.3/debian/rules 2013-12-29 18:32:50.0 +0100
+++ gcal-3.6.3/debian/rules 2018-02-13 06:40:06.0 +0100
@@ -20,10 +20,10 @@
dh $@ --with autotools_dev
 
 
+override_dh_auto_configure:
+   PAGER1=pager dh_auto_configure
+
 override_dh_auto_build:
-   PAGER1=pager ./configure --prefix=/usr \
-   --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info 
$(MAKE) CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
 
 override_dh_clean:

Bug#890335: torbrowser-launcher: couldn't upload

[Vladmimir Stavrinov]

Package: torbrowser-launcher
Version: 0.2.9-1
Severity: normal

When trying to upload to any site got crash:

"Gah. Your tab just crashed."

While there are no such problem with firefox of the same version.

torbrowser 7.5
firefox 52.6.0

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20170717
ii  gnupg 2.2.4-3
ii  libdbus-glib-1-2  0.110-2
ii  python2.7.14-4
ii  python-gtk2   2.24.0-5.1+b1
ii  python-lzma   0.5.3-3
ii  python-parsley1.2-1
ii  python-psutil 5.4.2-1
ii  python-twisted17.9.0-1
ii  python-txsocksx   1.15.0.2-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.2.9-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor   2.12-2
pn  python-pygame  

-- Configuration Files:
/etc/apparmor.d/local/torbrowser.Browser.firefox changed:

/etc/apparmor.d/local/torbrowser.Tor.tor changed:


-- no debconf information

Bug#890334: source: errors in /etc/neomuttrc

[Jonathan Dowland]

Package: neomutt
Version: 20171215+dfsg.1-1
Severity: normal

When running neomutt and specifying the package muttrc explicitly, neomutt
complains about errors

   $ neomutt -F /etc/neomuttrc
   source: errors in /etc/neomuttrc

Running the above under "script" reveals further information that was not
visible when running it normally

   Error in /etc/neomuttrc, line 38: mixmaster: unknown variable
   Error in /etc/neomuttrc, line 41: ssl_ca_certificates_file: unknown variable

These lines occur before "source: errors in /etc/neomuttrc" so I think neomutt
is clearing the screen between reporting them and writing the "source:..." line.

   1) neomutt should be clearer in reporting these errors
   2) /etc/neomuttrc should not contain things that neomutt does not understand


-- Package-specific info:
NeoMutt 20170609-70-fd852e (1.8.3)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.14.12-x86_64-linode92 (x86_64)
libidn: 1.33 (compiled with 1.33)

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18) 

Configure options: 


Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fno-delete-null-pointer-checks

Compile options:
 +attach_headers_color +bkgdset +color +compose_to_sender +compress +cond_date 
 +curs_set -debug +encrypt_to_self +fcntl -flock -fmemopen 
 +forgotten_attachments +forwref +futimens +getaddrinfo -gnutls -gpgme -gss 
 -hcache -homespool -iconv_nontrans +ifdef +imap +index_color +initials 
 +keywords +idn +limit_current_thread +lmdb -locales_hack -lua +meta 
 -mixmaster +multiple_fcc +nested_if +new_mail +nls +nntp -notmuch -openssl 
 +pgp +pop +progress +quasi_delete +regcomp +reply_with_xorig +resizeterm 
 -sasl +sensible_browser +sidebar +skip_quoted +smime +smtp +start_color 
 +status_color +sun_attachment +timeout +tls_sni +trash +typeahead +wc_funcs 
ISPELL="/usr/bin/ispell"

MAILPATH="/var/mail"
PKGDATADIR="/usr/local/share/mutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/usr/local/etc"

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please raise an issue at:
   https://github.com/neomutt/neomutt/issues
or send an email to: 


-- System Information:
Debian Release: 9.3
 APT prefers stable
 APT policy: (990, 'stable'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages neomutt depends on:
ii  libc6 2.24-11+deb9u1
ii  libcomerr21.43.4-2
ii  libgnutls30   3.5.8-5+deb9u3
ii  libgpgme111.8.0-3+b2
ii  libgssapi-krb5-2  1.15-1+deb9u1
ii  libidn11  1.33-1
ii  libk5crypto3  1.15-1+deb9u1
ii  libkrb5-3 1.15-1+deb9u1
ii  liblua5.3-0   5.3.3-1
ii  libncursesw5  6.0+20161126-1+deb9u1
ii  libnotmuch5   0.26-1
ii  libsasl2-22.1.27~101-g0780600+dfsg-3
ii  libtinfo5 6.0+20161126-1+deb9u1
ii  libtokyocabinet9  1.4.48-11+b1

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-3
ii  locales   2.24-11+deb9u1
ii  mime-support  3.60

Versions of packages neomutt suggests:
ii  aspell 

Bug#890333: gitlab: javascript errors after upgrade to 9.5.4

[Libor Klepáč]

Package: gitlab
Version: 9.5.4.+dfsg-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,
after upgrading gitlab from 8.13.x to 9.5.4 we get no events in dashboard grids.
Errors in firefox console  are
ReferenceError: Controller is not defined [Zjistit více]
common.bundle.js:19235:1
../../../../javascript/jquery-atwho/jquery.atwho.js/https://192.168.6.10/assets/webpack/common.bundle.js:19235:1
../../../../javascript/jquery-atwho/jquery.atwho.js/<   
https://192.168.6.10/assets/webpack/common.bundle.js:19149:2
../../../../javascript/jquery-atwho/jquery.atwho.js 
https://192.168.6.10/assets/webpack/common.bundle.js:18608:29
__webpack_require__ 
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
./commons/jquery.js 
https://192.168.6.10/assets/webpack/common.bundle.js:21974:78
__webpack_require__ 
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
./commons/index.js  
https://192.168.6.10/assets/webpack/common.bundle.js:21953:66
__webpack_require__ 
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
webpackJsonpCallback
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:26:23


and

TypeError: __WEBPACK_IMPORTED_MODULE_0_document_register_element___default(...) 
is not a function [Zjistit více] main.bundle.js:10029:1
./behaviors/gl_emoji.js
https://192.168.6.10/assets/webpack/main.bundle.js:10029:1
__webpack_require__
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
./behaviors/index.js   
https://192.168.6.10/assets/webpack/main.bundle.js:10089:68
__webpack_require__
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
./main.js/<
https://192.168.6.10/assets/webpack/main.bundle.js:22926:71
./main.js  
https://192.168.6.10/assets/webpack/main.bundle.js:22886:29
__webpack_require__
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:55:12
webpackJsonpCallback   
https://192.168.6.10/assets/webpack/webpack_runtime.bundle.js:26:23


I also tried to regenerate webapack and assets. It finishes without errors 
(after instaling node modules indexof and randomfill)

I also tried generate assets using yarn and
# bundle exec rake gitlab:assets:compile

but it does not finish successfuly, complains about missing 
webpack-stats-plugin, which seems to be installed.

Any clues what can be done?
This all bundler and node and webpack and etc. magic is ... (+ i have to allow 
traffic to our protected network, for npm to work)

Thanks,

Libor


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

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

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEPGZVVU37tFmB0TQv8O+MbsKfR44FAlqC+vgVHGxpYm9yLmts
ZXBhY0BiY29tLmN6AAoJEPDvjG7Cn0eOBMwP/3Xk/cZcsEQf2S99vDtAZRv9Rdwl
IkYQr2NN0Mtq/xMetF8eDEugMOA2O7QoRMYV2iBuJ3Ork1oqPrrevtqonNltqIJh
UZZKy+SBQgYz8RLiGiZrvzKd82pBXjM8rHdMkH1EYES02MR09PEdvzdOyzvoHyQj
NvP6Y5dmYyZ7KEHDaDDJs3gObr/fs+yAoFsygB+aZObSyfYsiczyfVXQWgWg3GMb
v4g9ZSTUyoYOD1w/6xMSpShe8r3rqzr+st+gcR61VacC0ZREM2bA5M6Nm++b4e2E
XEE98rRC4YAYBBtYp0AIyVBSUM/vgR9EOGXsf9MuFUkUX1oT2zc2WJVSJzhi6Cv6
C3N1qQ9zRypDnSlDUyShJDaVvBbotejzpDtEN6GIwV/a+5yyl/iWq2id4fXSDqYH
jnE5iFOIv15jTQtYNBz6NGBwyKluRjbVPVAlADlQpEuKQpd7O2FyAWvSXN4axk74
6MLHIW2j6qDq5e3h4WrDMIhGvsbzVg826NdW27SUnxCCwUz4R/BGq1wGgMCgrxjj
OGx8I7hSZ4z9eBLyW7kU3KTHUY8YBd73716o8i8otS9rPecS40VfSNhUxRfivZSj
W/CboHerla+RQP/gIKfzzyad5Gh/ye6z8xZIcEH9AvcDr20vpev/FhhHY+Tbrrnd
JHwqhiFcTfmRtSmt
=9ewv
-END PGP SIGNATURE-

Bug#889952: backtrace

[Johannes Wagner]

Hello,
i attached a backtrace what i could generate with gdb from the coredump

Program terminated with signal SIGABRT, Aborted.
#0  0x7f5e0b2930bb in ?? ()
gdb-peda$ thread apply all bt full

Thread 1 (LWP 542):
#0  0x7f5e0b2930bb in ?? ()
#1  0x in ?? ()

Bug#762753: lintian: privacy-breach-generic false positives on ?

[Chris Lamb]

tags 762753 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#890332: There is no libboost_container library

[DllMain]

Package: libboost1.62-dev
Version: 1.62.0+dfsg-4

Since 1.56.0 Boost release Boost.Container is separetely-compiled library in 
some cases(from www.boost.org/doc/libs/1_62_0/doc/html/container.html):
>There is no need to compile Boost.Container, since it's a header-only library, 
>just include your Boost header directory in your compiler include path except 
>if you use:
>Extended Allocators
>Some Polymorphic Memory Resources classes.
But this library not exists in Debian 9 with Boost 1.62.0 version. Debian 8 
contains Boost 1.55.0 version where libboost_container is always header-only. 
libboost_container library must compiled and packaged in Debian 9 as other 
Boost binary libraries(e. g. libboost_system).

Reproduction:
Suspose we have source file test.cxx
>#include 
>#include 
>int main()
>{
>const auto p = 
> std::allocate_shared(boost::container::adaptive_pool(),0);
>}
and try to build this
>g++ -otest -lboost_container test.cxx
Build failed with follow linkage error:
>/usr/bin/ld: cannot find -lboost_container
>collect2: error: ld returned 1 exit status

System information:
Debian repositories(from /etc/apt/sources.list):
  deb http://ftp.ru.debian.org/debian/ stretch main contrib non-free
  deb http://security.debian.org/debian-security stretch/updates main contrib 
non-free
  deb http://ftp.ru.debian.org/debian/ stretch-updates main contrib non-free
  deb http://ftp.ru.debian.org/debian/ stretch-backports main contrib non-free
Installed Boost packages:
  libboost-all-dev 1.62.0.1
  libboost-atomic-dev:amd641.62.0.1
  libboost-atomic1.62-dev:amd641.62.0+dfsg-4
  libboost-atomic1.62.0:amd64  1.62.0+dfsg-4
  libboost-chrono-dev:amd641.62.0.1
  libboost-chrono1.62-dev:amd641.62.0+dfsg-4
  libboost-chrono1.62.0:amd64  1.62.0+dfsg-4
  libboost-context-dev:amd64   1.62.0.1
  libboost-context1.62-dev:amd64   1.62.0+dfsg-4
  libboost-context1.62.0:amd64 1.62.0+dfsg-4
  libboost-coroutine-dev:amd64 1.62.0.1
  libboost-coroutine1.62-dev:amd64 1.62.0+dfsg-4
  libboost-coroutine1.62.0:amd64   1.62.0+dfsg-4
  libboost-date-time-dev:amd64 1.62.0.1
  libboost-date-time1.62-dev:amd64 1.62.0+dfsg-4
  libboost-date-time1.62.0:amd64   1.62.0+dfsg-4
  libboost-dev:amd64   1.62.0.1
  libboost-doc 1.62.0.1
  libboost-exception-dev:amd64 1.62.0.1
  libboost-exception1.62-dev:amd64 1.62.0+dfsg-4
  libboost-fiber-dev:amd64 1.62.0.1
  libboost-fiber1.62-dev:amd64 1.62.0+dfsg-4
  libboost-fiber1.62.0:amd64   1.62.0+dfsg-4
  libboost-filesystem-dev:amd641.62.0.1
  libboost-filesystem1.62-dev:amd641.62.0+dfsg-4
  libboost-filesystem1.62.0:amd64  1.62.0+dfsg-4
  libboost-geometry-utils-perl 0.15-2+b4
  libboost-graph-dev:amd64 1.62.0.1
  libboost-graph-parallel-dev  1.62.0.1
  libboost-graph-parallel1.62-dev  1.62.0+dfsg-4
  libboost-graph-parallel1.62.01.62.0+dfsg-4
  libboost-graph1.62-dev:amd64 1.62.0+dfsg-4
  libboost-graph1.62.0:amd64   1.62.0+dfsg-4
  libboost-iostreams-dev:amd64 1.62.0.1
  libboost-iostreams1.62-dev:amd64 1.62.0+dfsg-4
  libboost-iostreams1.62.0:amd64   1.62.0+dfsg-4
  libboost-locale-dev:amd641.62.0.1
  libboost-locale1.62-dev:amd641.62.0+dfsg-4
  libboost-locale1.62.0:amd64  1.62.0+dfsg-4
  libboost-log-dev 1.62.0.1
  libboost-log1.62-dev 1.62.0+dfsg-4
  libboost-log1.62.0   1.62.0+dfsg-4
  libboost-math-dev:amd64  1.62.0.1
  libboost-math1.62-dev:amd64  1.62.0+dfsg-4
  libboost-math1.62.0:amd641.62.0+dfsg-4
  libboost-mpi-dev 1.62.0.1
  libboost-mpi-python-dev  1.62.0.1
  libboost-mpi-python1.62-dev  1.62.0+dfsg-4
  libboost-mpi-python1.62.01.62.0+dfsg-4
  libboost-mpi1.62-dev 1.62.0+dfsg-4
  libboost-mpi1.62.0   1.62.0+dfsg-4
  libboost-program-options-dev:amd64   1.62.0.1
  libboost-program-options1.62-dev:amd64   1.62.0+dfsg-4
  libboost-program-options1.62.0:amd64 1.62.0+dfsg-4
  libboost-python-dev  1.62.0.1
  libboost-python1.62-dev  1.62.0+dfsg-4
  libboost-python1.62.01.62.0+dfsg-4
  libboost-random-dev:amd641.62.0.1
  libboost-random1.62-dev:amd641.62.0+dfsg-4
  libboost-random1.62.0:amd64  1.62.0+dfsg-4
  libboost-regex-dev:amd64 1.62.0.1
  libboost-regex1.62-dev:amd64 1.62.0+dfsg-4
  libboost-regex1.62.0:amd64   1.62.0+dfsg-4
  

Bug#890199: ITP: go-zglob

[Michael Meskes]

On Sun, Feb 11, 2018 at 09:27:52PM +0100, Michael Meskes wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Michael Meskes 
> 
> * Package name: go-zglob
>   Version : 0.0~git20171230.4959821-1
>   Upstream Author : Yasuhiro Matsumoto
> * URL : https://github.com/mattn/go-zglob
> * License : MIT Expat
>   Programming Lang: Go
>   Description : glob library that descends into other directories

Argh, should hve mentioned that this is needed as dependency for browserpass, a
web extension for the pass password manager. It's actually the last one missing
afait.

Thanks.

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

Bug#866997: [Pkg-mozext-maintainers] Bug#866997: Packaging WebExtensions

[Michael Meskes]

> > Here's my attempt:
> > https://anonscm.debian.org/cgit/pkg-mozext/mozilla-devscripts.git/commit/?h=pu/webext
> https://anonscm.debian.org/cgit/pkg-mozext/mozilla-devscripts.git/diff/?id=pu/webext=master
> 
> > 
> > It can be used like this (only --with, no --buildsystem is needed):
> > https://anonscm.debian.org/cgit/pkg-mozext/tree-style-tab.git/commit/?h=pu/webext
> https://anonscm.debian.org/cgit/pkg-mozext/tree-style-tab.git/diff/?id=pu/webext=master

When can we expect this to come? Sooner rather than later, please. :)

While working on browserpass (should be ready as soon as the dependencies are
in) I figured to give this layout a try, albeit manually created. Seems to work
nicely. If anyone's interested: git.debian.org/git/pkg-mozext/browserpass.git

I'd love to convert some more, in particular https-everywhere is bugging me atm.

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

Bug#890331: ITP: browserpass -- web extension for the password manager pass

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes 

* Package name: browserpass
  Version : 2.0.11
  Upstream Author : Maxim Baz
* URL : https://github.com/dannyvankooten/browserpass
* License : MIT
  Programming Lang: go, javascript
  Description : web extension for the password manager pass

webext-browserpass is a Firefox/Chromium extension for the password manager
pass. It retrieves your decrypted passwords for the current domain and allows
you to auto-fill login forms, as well as copy it to clipboard. If you have
multiple logins for the current site, the extension shows you a list of
usernames to choose from.

git is already created for the pkg-mozext team.

Michael

Bug#890330: missing some jessie d-i files in http://snapshot.debian.org/archive/debian/20170506T092656Z/dists/jessie/main/installer-amd64/

[Steve McIntyre]

Package: snapshot.debian.org
Severity: normal

Hi,

Just had reports in debian-user that snapshot fallback for the 8.8.0
jigdos is failing:

  https://lists.debian.org/debian-user/2018/02/msg00553.html

I've dug up backup copies of the amd64 files and put them up at

  
http://us.cdimage.debian.org/cdimage/snapshot/Debian/dists/jessie/main/installer-amd64/20150422+deb8u4+b3/

(etc.) if you'd like to pull from there. I'm going to double-check
that all the arches are covered and I'll update here shortly.

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

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

Bug#890212: wxmaxima: Assertion failure: assert "m_group != NULL" failed in GetGroup()

[John Scott]

Package: wxmaxima
Version: 17.10.1-1
Followup-For: Bug #890212

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thank you for responding as quickly as you did! I'm glad that the issue is 
fixed upstream.

Regarding the two options, I think the second option is better. I can wait for 
an unstream
release to fix it, and making an early patch just for Unstable and Testing is 
unnecessary.
The bug isn't a big deal if you ask me, as long as it is fixed eventually.

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

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

Versions of packages wxmaxima depends on:
ii  ibus-gtk3 1.5.17-3
ii  libc6 2.26-6
ii  libgcc1   1:7.2.0-19
ii  libstdc++67.2.0-19
ii  libwxbase3.0-0v5  3.0.3.1+dfsg2-1
ii  libwxgtk3.0-0v5   3.0.3.1+dfsg2-1
ii  maxima5.41.0-1

Versions of packages wxmaxima recommends:
ii  maxima-doc  5.41.0-1

Versions of packages wxmaxima suggests:
pn  fonts-jsmath 
ii  texlive-latex-extra  2017.20180110-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlqC9bkSHGpzY290dEBw
b3N0ZW8ubmV0AAoJEH1hRKYneTBy3LoH/jICIWJHUl55ZrYp1lAJL8+HUmI27Wsa
kpoJz+QRErXnVpFjdcy4nRigtzoUxGiWsH5laz4z1YVUtzfvzx2PaK1cninNIKPG
fjrN7Ghz8V6QKmbbrFBz8KA4BpzVC1z7PVFjqALwDz9O4hNhOcj2v6mvP//6UO6b
7W7pPPdveihaVug7JOkT1+966Si5hODVsN9VpgOGlNByYUH2oFpIcZet6o6I8CgZ
TOhz/qZiNPQeOpHK/WeNF6Dksu2fG/8oJ6LmZfS4z3kUvG6NWTGGbarMI2GGAWaH
SsMX1RzzbS/y4TtiIV0cy1X1fEpe/p4vXePKUo/3XySBCiGovizpNVA=
=LJp6
-END PGP SIGNATURE-

Bug#890329: python3-stdeb: Missing pypi-* scripts

[John Goerzen]

Package: python3-stdeb
Version: 0.8.5-1
Severity: normal

Dear Maintainer,

Over at https://github.com/astraw/stdeb#the-commands, several commands
are documented.  These are in the source package at scripts/ but are
missing in the debs.  Please install them.

Thanks,

John


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

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

Versions of packages python3-stdeb depends on:
ii  debhelper   10.2.5
ii  python3 3.5.3-1
ii  python3-requests2.12.4-1
ii  python3-setuptools  33.1.1-1

Versions of packages python3-stdeb recommends:
ii  apt-file 3.1.4
ii  dpkg-dev 1.18.24
ii  python3-all  3.5.3-1

Versions of packages python3-stdeb suggests:
pn  python3-all-dev  

-- no debconf information

Bug#890328: RFH: pdf-redact-tools -- PDF Redact Tools helps with securely redacting and stripping

[Loic Dachary]

Package: wnpp
Severity: normal

pdf-redact-tools is one of many tools journalists need to protect the anonymity 
of their sources. It needs to be supported by a few developers so there is no 
single point of failure. Are you willing to be a co-maintainer ?

Cheers

Bug#855457: ITP: signal-cli -- commandline and dbus interface for WhisperSystems/libsignal-service-java

[Loic Dachary]

Control: retitle 855457 ITP: signal-cli -- commandline and dbus interface for 
WhisperSystems/libsignal-service-java
Control: owner 855457 l...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#890327: ITP: python-ua-parser -- Python module for parsing HTTP User-Agent strings

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 

* Package name: python-ua-parser
  Version : 0.7.3
  Upstream Author : Matt Robenolt 
* URL : https://github.com/ua-parser/uap-python
* License : Apache 2.0
  Programming Lang: Python
  Description : Python module for parsing HTTP User-Agent strings

Parse the User-Agent string from a web browser or other HTTP client.
Extracts information and version numbers for the device, operating
system and the user agent.

This is a dependancy for the user-agents Python module.

Bug#890326: linux: Thinkpad X61 brightness reset to 0% on each boot

[Thorsten Glaser]

Package: src:linux
Version: 4.14.13-1
Severity: minor

Ever since a recent kernel upgrade (I *think* 4.13 to 4.14; if
necessary, I can check), on each boot, my LCD brightness gets
reset to the minimum.

This is annoying; I currently work around it by putting
cat /sys/class/backlight/intel_backlight/max_brightness \
>/sys/class/backlight/intel_backlight/brightness
into /etc/rc.local, but it makes it virtually impossible to read
boot messages.

Furthermore, I have a slight feeling that the maximum brightness
is lower than it was before, or compared to my IBM Thinkpad X40.
That being said, several minutes after booting, it seems to be
becoming a bit brighter, so it’s maybe only on a cold start.

-- Package-specific info:
** Version:
Linux version 4.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-3-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y 
vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0

** Not tainted

** Kernel log:
[2.336544] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[2.336546] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[2.336547] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[2.336775] ata1.00: configured for UDMA/100
[2.444822] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[2.462065] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/input/input5
[2.480472] usb 1-4: New USB device found, idVendor=17ef, idProduct=1000
[2.480475] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[2.480883] hub 1-4:1.0: USB hub found
[2.480927] hub 1-4:1.0: 4 ports detected
[2.586157] Console: switching to colour frame buffer device 128x48
[2.688444] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[2.704395] scsi 0:0:0:0: Direct-Access ATA  INTEL SSDSA2M160 02HA 
PQ: 0 ANSI: 5
[2.712571] ata1.00: Enabling discard_zeroes_data
[2.714155] sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 
GiB)
[2.715443] sd 0:0:0:0: [sda] Write Protect is off
[2.716761] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[2.717396] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[2.718811] ata1.00: Enabling discard_zeroes_data
[2.720798]  sda: sda1 sda2 sda3 sda4
[2.722570] ata1.00: Enabling discard_zeroes_data
[2.724084] sd 0:0:0:0: [sda] Attached SCSI disk
[7.951700] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[8.459119] parport_pc 00:06: reported by Plug and Play ACPI
[8.463622] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
[8.483053] ACPI: Battery Slot [BAT0] (battery present)
[8.484975] ACPI: AC Adapter [AC] (on-line)
[8.499012] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[8.535866] ACPI Warning: SystemIO range 
0x1028-0x102F conflicts with OpRegion 
0x1000-0x107F (\_SB.PCI0.LPC.PMIO) 
(20170728/utaddress-247)
[8.539070] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.545082] sd 0:0:0:0: Attached scsi generic sg0 type 0
[8.548186] Non-volatile memory driver v1.3
[8.559618] ACPI Warning: SystemIO range 
0x11B0-0x11BF conflicts with OpRegion 
0x1180-0x11BF (\_SB.PCI0.LPC.LPIO) 
(20170728/utaddress-247)
[8.563081] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.565878] ACPI Warning: SystemIO range 
0x1180-0x11AF conflicts with OpRegion 
0x1180-0x11BF (\_SB.PCI0.LPC.LPIO) 
(20170728/utaddress-247)
[8.569374] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.571124] lpc_ich: Resource conflict(s) found affecting gpio_ich
[8.573177] yenta_cardbus :05:00.0: CardBus bridge found [17aa:20c6]
[8.589883] input: PC Speaker as /devices/platform/pcspkr/input/input7
[8.592433] thinkpad_acpi: ThinkPad ACPI Extras v0.25
[8.594648] thinkpad_acpi: http://ibm-acpi.sf.net/
[8.596444] thinkpad_acpi: ThinkPad BIOS 7NET30WW (1.11 ), EC 7MHT24WW-1.02
[8.598220] thinkpad_acpi: Lenovo ThinkPad X61, model 7673AG4
[8.617124] thinkpad_acpi: radio switch found; radios are enabled
[8.619014] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
brightness control, supported by the ACPI video driver
[8.620877] thinkpad_acpi: Disabling thinkpad-acpi brightness events by 
default...
[8.647113] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree:
[8.648901] iwl4965: Copyright(c) 2003-2011 Intel Corporation
[8.652264] iwl4965 :03:00.0: Detected 

Bug#877388: s-nail adoption (build flags)

[Paride Legovini]

On 2018-02-13 14:27, Hilko Bengen wrote:
> * Paride Legovini:
> 
>> I: s-nail: hardening-no-fortify-functions usr/bin/s-nail
>> I: s-nail: hardening-no-fortify-functions usr/lib/s-nail/s-nail-privsep
> 
> I believe that your CFLAGS/LDFLAGS analysis for this warning (as well as
> the proposed change) is correct.

It seems that I've been able to fix all the issues by modifying a few
things in d/rules. Here is the updated file, with some comments:

https://salsa.debian.org/debian/s-nail/blob/master/debian/rules

Lintian is happier now, still I would appreciate a manual review of the
changes I made.

Cheers,

Paride

Bug#890325: transmission: New upstream version (2.93)

[jim_p]

Package: transmission
Severity: wishlist
Tags: upstream

Dear Maintainer,

Please update transmission to 2.93 because it was released ~20 days ago. The
new release also closes this upstream bug which affects me since the very first
appearence of 2.92 in the repos in early September of 2016.

https://github.com/transmission/transmission/issues/27

Thank you in advance.



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

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

Versions of packages transmission depends on:
pn  transmission-common
pn  transmission-gtk | transmission-qt | transmission-cli  

transmission recommends no packages.

transmission suggests no packages.

Bug#877388: s-nail adoption (build flags)

[Hilko Bengen]

* Paride Legovini:

> I: s-nail: hardening-no-fortify-functions usr/bin/s-nail
> I: s-nail: hardening-no-fortify-functions usr/lib/s-nail/s-nail-privsep

I believe that your CFLAGS/LDFLAGS analysis for this warning (as well as
the proposed change) is correct.

> W: s-nail-dbgsym: debug-file-with-no-debug-symbols
> usr/lib/debug/.build-id/a7/0016ff0ddb7b0e70321b28e68f529204140f60.debug
> W: s-nail-dbgsym: debug-file-with-no-debug-symbols
> usr/lib/debug/.build-id/b0/3145705a4f0f2c7171bac4dc4b2c2ba23bb372.debug

There is more than one possible reason for this: The C compiler may not
have not added debug symbols in the first place (look for -g...). Or the
debug symbols may have been removed afterwards (look for strip or
install -s).

Cheers,
-Hilko

Bug#890324: piuparts-master backup strategy

[Holger Levsen]

package: piuparts.debian.org
severity: important
x-debbugs-cc: d...@debian.org

On Tue, Feb 13, 2018 at 02:01:47PM +0100, Julien Cristau wrote:
> can you please look at /srv/piuparts.d.o on pejacevic with backups in
> mind?  Any directory without a .nobackup file is getting backed up, this
> seems to include in particular things under
> /srv/piuparts.debian.org/htdocs with a few flat directories with a huge
> number of small files.  This causes backups to take too long and too
> much space (and/or fail because they're taking too long).

i'm pretty sure /srv/piu.d.o/htdocs/ doesnt need to be backed up at all, but 
need to double check.

 | h01ger: so we wonder what can be done about piuparts backups such
that we have backups of relevant things, but also that backups
actually work


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#890323: gnucash: some keys not working when ibus input is used

[Alexey Morsov]

Package: gnucash
Version: 1:2.6.18-1
Severity: normal
Tags: a11y

Dear Maintainer,


   * What led up to the situation?
I have installed 
ii  ibus1.5.17-3
   amd64Intelligent Input Bus - core
ii  ibus-gtk:amd64  1.5.17-3
   amd64Intelligent Input Bus - GTK+2 support
ii  ibus-gtk3:amd64 1.5.17-3
   amd64Intelligent Input Bus - GTK+3 support
ii  ibus-mozc   
2.20.2673.102+dfsg-2   amd64Mozc engine for IBus - 
Client of the Mozc input method



   * What exactly did you do (or not do) that was effective (or
 ineffective)?
From googling i've tried some workarounds (i.e. ibus exit before run
gnucash), but to result.

   * What was the outcome of this action?
in gnucash some keys (arrows, del, backspace) is not working.

   * What outcome did you expect instead?

I expect to use gnucash as allways, but with a japanese layout too.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnucash depends on:
ii  gnucash-common 1:2.6.18-1
ii  guile-2.0  2.0.13+1-5
ii  guile-2.0-libs 2.0.13+1-5
ii  libaqbanking35 5.7.6beta-2
ii  libaqbanking35-plugins 5.7.6beta-2
ii  libc6  2.26-6
ii  libcairo2  1.15.10-1
ii  libcrypt-ssleay-perl   0.73.04-2+b2
ii  libdate-manip-perl 6.60-1
ii  libdbi10.9.0-5
ii  libfinance-quote-perl  1.47-1
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libglib2.0-0   2.54.3-2
ii  libgnomecanvas2-0  2.30.3-3
ii  libgoffice-0.8-8   0.8.17-8
ii  libgtk2.0-02.24.32-1
ii  libgwengui-gtk2-0  4.18.0-1
ii  libgwenhywfar604.18.0-1
ii  libhtml-tableextract-perl  2.15-1
ii  libhtml-tree-perl  5.07-1
ii  libktoblzcheck1v5  1.49-4
ii  libofx71:0.9.12-1
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libpython2.7   2.7.14-6
ii  libsecret-1-0  0.18.5-6
ii  libwebkitgtk-1.0-0 2.4.11-3
ii  libwww-perl6.31-1
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-6.1
ii  libxslt1.1 1.1.29-5
ii  perl   5.26.1-4+b1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnucash recommends:
ii  dbus1.12.4-1
ii  dbus-x111.12.4-1
pn  gnucash-docs
ii  python-gnucash  1:2.6.18-1
ii  yelp3.26.0-2

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
pn  libdbd-sqlite3  

-- debconf-show failed

-- 
With best regards,
Alexey Morsov,
Ricom-Trust
 phone: +7 (499) 241-53-07
 email: mor...@ricom.ru
 jabber: samu...@www.fondmarket.ru



signature.asc
Description: PGP signature

Bug#884023: bibledit: Installs same file as bibledit-gtk

[Jeremy Bicha]

Control: reopen -1

I am reopening this bug. Even though bibledit-gtk has been removed,
this is still a RC bug because it will break people upgrading. Please
add the Breaks/Replaces relationship and a transitional package.

Feel free to ask if you need help with this.

Thanks,
Jeremy Bicha

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

[Abou Al Montacir]

Hi Andreas,


I'm also interested in this package and can help in packaging.

Let's have a plan to ensure this is done ASAP.
-- 
Cheers,
Abou Al Montacir


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

Bug#883707: ace-freecell crashes on KDE desktops

[Markus Koschany]

Am 12.02.2018 um 22:34 schrieb Esa Peuha:
> That's very odd. Presumably a program can only cause that error message
> by calling XGetImage, and freecell (like every other of these games
> except taipei) can only do so from line 819 of xwin.c in build_image.
> However, the only non-constant arguments to XGetImage are display and
> window, and if one of those variables has an invalid value, I would
> expect an error long before reaching that point. Looking at the sources,
> the only obvious difference between freecell and everything else is that
> freecell defaults to a window that is 640 pixels wide and 480 pixels
> high, and I can just about imagine that some piece of code might treat
> a window with those exact dimensions specially. That should be easy to
> test; if "ace-freecell -width 700 -height 500" works when it would fail
> without those arguments, and if the other games fail if you start them
> with "-width 640 -height 480" then it's pretty clear this is the cause.

Thank you very much for the detailed response. I have tried the above
but ace-freecell would still fail with any variation of -width and
-height options. The other games start fine with -width 640 and -height 480.

This only happens when I try to start ace-freecell for the first time.
If I try to start the game again it suddenly works. Maybe the code
should be changed so that it not defaults to 640 x 480 pixels and
behaves like the other games?






signature.asc
Description: OpenPGP digital signature

Bug#890322: transition: libgweather 3.27

[Jeremy Bicha]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: pkg-gnome-maintain...@lists.alioth.debian.org

I request permission to start the libgweather transition. The new
version of libgweather is required for GNOME 3.28.

https://release.debian.org/transitions/html/auto-tracker.html

I have completed test rebuilds in my PPA. evolution-data-server,
gnome-applets, and gnome-panel need cherry-picked patches. Since they
are all Debian GNOME packages, I can do those uploads.

After that, we'll need binNMUs for evolution, gnome-clocks,
gnome-initial-setup, and gnome-settings-daemon.

https://launchpad.net/~jbicha/+archive/ubuntu/templibgweather/+packages

Thanks,
Jeremy Bicha

Bug#890321: ITP: libbusiness-isin-perl -- validate International Securities Identification Numbers

[laurent . baillet]

Package: wnpp
Severity: wishlist
Owner: laurent.bail...@gmail.com

* Package name: libbusiness-isin-perl
  Version : 0.20
  Upstream Author : David Chan 
* URL : http://search.cpan.org/dist/Business-ISIN/ISIN.pm
* License : GPL
  Programming Lang: Perl
  Description : validate International Securities Identification Numbers

this module validates ISIN ( International Securities Identification Numbers ) 
of financial instruments according to ISO 3166

this version has now reached the noble age of 15 years old and still works 
perfectly

Bug#890320: apt: is there a better way to handle the FOO-common package upgrade problem?

[Thorsten Glaser]

On Tue, 13 Feb 2018, Thorsten Glaser wrote:

> I was thinking of adding a new header field to one of the two
> packages that declares “FOO-common is only here for the benefit
> of FOO” so the dependency resolver can DTRT (its default mecha‐

Hmm. But then, consider this:

src:musescore builds musescore:any, musescore-common:all and
fluidr3mono-gm-soundfont:all.

The latter was recently split off musescore-common because some
other packages may also make use of it. So, it’s not *strictly*
“only for the benefit of musescore”.

Still, upgrading it at the cost of musescore would suck.

I was thinking of writing “at the cost of any of its r-deps”,
but that’s not generally true either, I think.


Food for thought,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der EuroCIS!**
27. Februar bis 01. März 2018, Messe Düsseldorf / **Halle 10,** ** Stand
F15**
Leading Trade Fair for Retail Technology
[www.tarent.de/eurocis](http://www.tarent.de/eurocis)

Wir empfehlen unsere Vorträge

?Preisbeobachtung, Händlermonitoring, Plagiaterkennung: Ihre
Wettbewerbsvorteile?
am 27. Februar, 14:00 Uhr im EuroCIS Forum / Halle 10, Stand F04

?Internet of Things ? Der Handel im Wandel?
am 01. März, 11:30 Uhr im Omnichannel Forum / Halle 10, Stand A70

*

**Visit us at EuroCIS!** 27th February to 1st March, 2018, Messe
Düsseldorf
/ **Hall 10,** ** Booth F15**
Leading Trade Fair for Retail Technology
[www.tarent.de/eurocis](http://www.tarent.de/eurocis)

We recommend our presentations

?Your view on prices, retailers and plagiarism: Competitive advantages
with
monitoring apps?
on 27th February, 2 pm at EuroCIS Forum / Hall 10, Booth F04

?Internet of Things ? Retailing in a Changing World?
on 1st March, 11:30 am at Omnichannel Forum / Hall 10, Booth A70

*

Bug#890320: apt: is there a better way to handle the FOO-common package upgrade problem?

[Thorsten Glaser]

Package: apt
Version: 1.6~alpha7
Severity: wishlist

Recently, package splitting has become a lot more common, tons of
packages have FOO and FOO-common now, the latter being arch:all.

Now, in between the time FOO-common is ACCEPTed and FOO has been
rebuilt for that architecture, landed on the mirrors, etc., APT
wants to upgrade FOO-common and remove the old version of FOO.

I was thinking of adding a new header field to one of the two
packages that declares “FOO-common is only here for the benefit
of FOO” so the dependency resolver can DTRT (its default mecha‐
nism of upgrading everything it can is not incorrect in the ge‐
neral case, just here).

Perhaps you have a better idea. I’ll leave the details to you
and perhaps the dpkg maintainer.

This would help users of unstable, especially on debian-ports
architectures, massively.


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/preferences.d/dash-mksh.pref present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/local.list present, but not submitted) --


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages apt depends on:
ii  adduser 3.117
ii  debian-archive-keyring  2017.7
ii  gpgv2.2.4-3
ii  libapt-pkg5.0   1.6~alpha7
ii  libc6   2.26-6
ii  libgcc1 1:8-20180207-2
ii  libgnutls30 3.5.17-1
ii  libseccomp2 2.3.1-2.1
ii  libstdc++6  8-20180207-2

Versions of packages apt recommends:
ii  ca-bundle [ca-certificates]  20170309tarent1

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.0.5
ii  gnupg2.2.4-3
ii  gnupg1   1.4.22-4
ii  powermgmt-base   1.31+nmu1

-- no debconf information

Bug#890319: telegram-desktop: please package telegram upstream v1.2.8

[shirish शिरीष]

Package: telegram-desktop
Version: 1.2.6-2
Severity: wishlist

Dear Maintainer,

Please package new upstream v1.2.8

https://github.com/telegramdesktop/tdesktop/releases/tag/v1.2.8


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8
(charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages telegram-desktop depends on:
ii  libavcodec57 7:3.4.1-1+b2
ii  libavformat577:3.4.1-1+b2
ii  libavutil55  7:3.4.1-1+b2
ii  libc62.26-6
ii  libgcc1  1:7.2.0-19
ii  libglib2.0-0 2.54.3-2
ii  libminizip1  1.1-8+b1
ii  libopenal1   1:1.18.2-2
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-9
ii  libqt5dbus5  5.9.2+dfsg-9
ii  libqt5gui5   5.9.2+dfsg-9
ii  libqt5network5   5.9.2+dfsg-9
ii  libqt5widgets5   5.9.2+dfsg-9
ii  libssl1.11.1.0g-2
ii  libstdc++6   7.2.0-19
ii  libswresample2   7:3.4.1-1+b2
ii  libswscale4  7:3.4.1-1+b2
ii  libtgvoip1.0 1.0~git20170704.445433f-4
ii  libx11-6 2:1.6.4-3
ii  qt5-image-formats-plugins5.9.2-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages telegram-desktop recommends:
ii  libappindicator3-1  0.4.92-5

telegram-desktop suggests no packages.

-- no debconf information

-- 
  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#883069: Please consider enabling CONFIG_SLAB_FREELIST_HARDENED

[intrigeri]

Control: tag -1 + pending
Control: found -1 4.14.13-1
Control: found -1 4.15~rc8-1~exp1
Control: retitle -1 Please consider enabling CONFIG_SLAB_FREELIST_HARDENED

Hi,

CONFIG_SLAB_FREELIST_HARDENED was enabled in commit 3fa67126b5924
and is documented as pending in the changelog for 4.15.2-1~exp1.

Thanks!

Cheers,
-- 
intrigeri

Bug#890318: util-linux: FTBFS on big endian - sha1/sha1 test fails

[James Cowgill]

Source: util-linux
Version: 2.31.1-0.1
Severity: serious
Tags: sid buster fixed-upstream

Hi,

util-linux FTBFS on all big endian architectures with this testsuite failure:>  
script: /«PKGBUILDDIR»/tests/ts/sha1/sha1
> sub dir: /«PKGBUILDDIR»/tests/ts/sha1
> top dir: /«PKGBUILDDIR»/tests
>self: /«PKGBUILDDIR»/tests/ts/sha1
>   test name: sha1
>   test desc: sha1
>   component: sha1
>   namespace: sha1/sha1
> verbose: yes
>  output: /«PKGBUILDDIR»/tests/output/sha1/sha1
>valgrind: /«PKGBUILDDIR»/tests/output/sha1/sha1.vgdump
>expected: /«PKGBUILDDIR»/tests/expected/sha1/sha1
>  mountpoint: /«PKGBUILDDIR»/tests/output/sha1/sha1-mnt
> 
>  sha1: sha1   ... FAILED (sha1/sha1)
> = script: /«PKGBUILDDIR»/tests/ts/sha1/sha1 =
> = OUTPUT =
>  19844f81e1408f6ecb932137d33bed7cfdcf518a3
>  214c20690f653fb16396e4f804c9dafb46e513d4f
>  3b39356f080492701e97317f88ca581acffae89cf
>  45e7c72295e61b1f0d733e6485bac4237b17d293a
>  597faba6b0f94c599ad7dd08a8801b7e7f4994b15
>  608b5f5340abf513bc11f824daea8828bb00c4541
>  76d49c77f9f4fbb8ef5fd4db0bd3cad4111dcf1c3
> = EXPECTED ===
>  1da39a3ee5e6b4b0d3255bfef95601890afd80709
>  2a9993e364706816aba3e25717850c26c9cd0d89d
>  3da3175a32e6c1aacfd3d3f35770188ae0ab6d078
>  47496226c17d4d0a770cea72eebb659c16753b956
>  5db50ea8b1b20567cd4d8a7fa14de8d37ce9b722c
>  690e072e1df8de879ca307610d5ced675af55a4ac
>  72eda696c8df17722d80518bebb33742e311a4ac1
> = O/E diff ===
> --- /«PKGBUILDDIR»/tests/output/sha1/sha1 2018-02-09 19:15:42.389991140 
> +
> +++ /«PKGBUILDDIR»/tests/expected/sha1/sha1   2017-12-21 14:44:24.0 
> +
> @@ -1,7 +1,7 @@
> -9844f81e1408f6ecb932137d33bed7cfdcf518a3
> -14c20690f653fb16396e4f804c9dafb46e513d4f
> -b39356f080492701e97317f88ca581acffae89cf
> -5e7c72295e61b1f0d733e6485bac4237b17d293a
> -97faba6b0f94c599ad7dd08a8801b7e7f4994b15
> -08b5f5340abf513bc11f824daea8828bb00c4541
> -6d49c77f9f4fbb8ef5fd4db0bd3cad4111dcf1c3
> +da39a3ee5e6b4b0d3255bfef95601890afd80709
> +a9993e364706816aba3e25717850c26c9cd0d89d
> +da3175a32e6c1aacfd3d3f35770188ae0ab6d078
> +7496226c17d4d0a770cea72eebb659c16753b956
> +db50ea8b1b20567cd4d8a7fa14de8d37ce9b722c
> +90e072e1df8de879ca307610d5ced675af55a4ac
> +2eda696c8df17722d80518bebb33742e311a4ac1
> ==

I think this if fixed by this upstream commit:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=4ff4b1106e8c6a71cce59ca40a2019342a92d47d

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890317: gnucash: FTBFS on 32-bit architectures due to test failures

[Andreas Beckmann]

Source: gnucash
Version: 1:2.7.3-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

gnucash/experimental FTBFS on several architectures where the sid
version builds successfully:

https://buildd.debian.org/status/package.php?p=gnucash=experimental

e.g.

armel:
The following tests FAILED:
 21 - test-backend-dbi (SEGFAULT)
 59 - test-gnc-timezone (Failed)
105 - python-bindings (Failed)

i386:
The following tests FAILED:
 21 - test-backend-dbi (SEGFAULT)
 58 - test-gnc-numeric (Failed)
 59 - test-gnc-timezone (Failed)
105 - python-bindings (Failed)


There is a different FTBFS on s390x as well ...


Andreas

Bug#889740: xmotd: crashes when built with hardening

[Christoph Pleger]

Hello,

so, I suggest the attached patch for a solution. It removes most compile 
time warnings and makes xmotd to not crash (tested on stretch amd64).


Regards
  ChristophRemove compiler and linker warnings
Index: xmotd-1.17.3b/atom.c
===
--- xmotd-1.17.3b.orig/atom.c	2018-02-13 10:44:27.104309051 +0100
+++ xmotd-1.17.3b/atom.c	2018-02-13 10:44:27.096309028 +0100
@@ -29,6 +29,7 @@
  */
 #include 
 
+#include 
 #include 
 #include 
 #include 
Index: xmotd-1.17.3b/main.c
===
--- xmotd-1.17.3b.orig/main.c	2018-02-13 10:44:27.104309051 +0100
+++ xmotd-1.17.3b/main.c	2018-02-13 10:44:27.096309028 +0100
@@ -205,9 +205,10 @@
 : end-of-file()";
 
 char *
-getTimeStampName()
+getTimeStampName(void)
 {
   static char buf[256];
+  int result;
   
   sprintf(buf, "%s/%s", getenv("HOME"), app_res.stampfile);
 
@@ -215,10 +216,12 @@
 	{
 	  char domainame[256];
 
-	  getdomainname(domainame, 256);
+	  result = getdomainname(domainame, 256);
   
 	  strcat(buf, "."); 
-	  strcat(buf, domainame);
+
+	  if (result == 0)
+	strcat(buf, domainame);
 	}
 
   return(buf);
@@ -394,7 +397,7 @@
 
 		  if ((dir = opendir(argv[i]))) 
 			{
-			  while (dp = readdir(dir)) 
+			  while ((dp = readdir(dir)))
 {
   if (dp->d_ino == 0)
 	continue;
@@ -481,139 +484,21 @@
 	  /* next check if any messages need to be displayed, if there
  aren't any, go back to sleep; otherwise return to display
  messages*/
-	  if(numsg=numFilesToDisplay(gargc, gargv)) return(numsg);
-	}
-
-}
-
-
-main(argc, argv)
-int argc;
-char **argv;
-{
-  extern Boolean atomExists(String);
-  Display *display;
-  register int i, start=0;
-  int numsg;
-
-  
-  if ((argc > 1) && !(strcmp(argv[1],"-help")))
-	{
-	  printUsage(argv[0]);		/* and exit */
-	}
-
-  /* Test to see whether we are connected to an X display. If we
-	 aren't, we proceed in text-only mode: bare-bones functionality;
-	 output to stdout.  Why bare-bones, I hear you asking? Well, X
-	 does all the command-line options parsing for me and I don't feel
-	 like duplicating all that code. So there.*/
-
-  if((display=XOpenDisplay((char *)NULL))==NULL) 
-	{
-
-	  if(argc<2)
-		{
-		  fprintf(stderr, "xmotd: ERROR, missing file.\n");
-		  printUsage(argv[0]);	/* and exit */
-		}
-	  else
-		{
-		  extern void runInTextMode();
-		  runInTextMode(argc, argv); /* ...and exit... */
-		} 
-
-	  fprintf(stderr,"Never gets here!\n");
-	  exit(0);/* just in case */
-	  
-	} 
-  else 
-	{
-	  XCloseDisplay(display);
-	}
-  
-  /* we have to init the toolkit *before* we check the command-line so
- we can use X's parsing routines, since -geom options, etc. may be
- specified, in which case, the motd-filename is *not* the 2nd
- argument*/
-  topLevel = XtVaAppInitialize(_con, "XMotd", options, 
-			   XtNumber(options),
-			   , argv, fallback_resources, 
-			   NULL);
-
-  XtGetApplicationResources(topLevel, (caddr_t) _res,
-			resources, XtNumber(resources),
-			(ArgList) NULL, (Cardinal) 0);
-
-  if(argc<2)
-	{
-	  fprintf(stderr,"xmotd: ERROR, missing file\n");
-	  printUsage(argv[0]);	/* and exit */
-	}
-  
-  if(app_res.paranoid && !app_res.warnfile)
-	{
-	  fprintf(stderr,"xmotd: ERROR, specified \"-paranoid\" without \"-warnfile\"\n");
-	  printUsage(argv[0]);	/* and exit */
-	}
-
-  strcpy(timeStamp, getTimeStampName());
-
-  gargc=argc;
-  gargv=argv;
-  
-  /* first figure out how many of the files supplied on the
- command-line we will be actually displaying; i.e. we only show
- the new ones (unless -always has been specified, in which case we
- show all of them)*/
-  numsg=numFilesToDisplay(argc, argv);
-
-  if(!app_res.periodic && !numsg)
-	{
-	  /* if none of the messages need to be displayed and -wakeup not
-	  specified */
-
-	  XtDestroyApplicationContext(app_con);		
-	  exit(0);
-	}  
-
-  if(app_res.periodic)			/*-wakeup or -timeout specified*/
-	{
-
-	  /*ensure no other copies of xmotd are running*/
-	  if(atomExists(app_res.atomname)){
-		XtDestroyApplicationContext(app_con);		
-		exit(0);
-	  }
-
-	  if(fork()) exit(0);		/*we have to daemonize ourselves*/
-	  alreadyForked=1;			/* make a note of it */
-
-	  if(!numsg)
-		{
-		  /* if no messages to be displayed, we sleep */
-		  numsg=runSilentRunDeep(getAlarmTime(app_res.periodic));
-		}
-
+	  if((numsg=numFilesToDisplay(gargc, gargv))) return(numsg);
 	}
 
-  createWidgets(numsg);
-  nextMessage((Widget)NULL, (caddr_t)NULL, (caddr_t)NULL);  
-
-  XtAddEventHandler(topLevel, (EventMask)0, True,
-	(XtEventHandler)_XEditResCheckMessages, 0);
-
-  XtRealizeWidget(topLevel);  
-  XtAppMainLoop(app_con);
 }
 
 
-createWidgets(int anymsg)
+void createWidgets(int anymsg)
 {
-  Widget form, paned, logo, mlabel, hline;
+  Widget form, logo, mlabel, hline;
   XtTranslations shift1TransTable, tailTransTable;
   Pixel fg, bg;
+  #ifdef 

Bug#889968: RFS: inotify-tools/3.14-4

[Luca Falavigna]

2018-02-13 4:18 GMT+01:00  :
>> I suspect that the debomatic sid chroot is out-of-date.

amd64 chroot was updated on Sunday, February 11, 2018 4:20:10 PM UTC
(1518366010.2514317).

-- 
Cheers,
Luca

Bug#865599: bash can stop disabling PIE

[Raphael Hertzog]

Control: forcemerge -1 859263
Control: reopen -1

On Fri, 23 Jun 2017, Adrian Bunk wrote:
> Since both stretch and xenial use a recent enough kernel,
> please consider applying the following patch to enable PIE:

Unfortunately enabling PIE breaks usage of bash in qemu-user
(see #889869) which makes it impossible to debootstrap any foreign
architecture.

So I uploaded an NMU (with Matthias Klose's consent) to revert that change
and I re-open this bug instead.

Or maybe we should use --without-bash-malloc in all builds. Because I just
tested a build with PIE enabled and with the --without-bash-malloc
configure flag and it does not trigger the problem reported in #889869.

But I leave that decision to Matthias.

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/

Bug#889668: util-linux: diff for NMU version 2.31.1-0.2

[Laurent Bigonville]

Control: tags 889668 + patch
Control: tags 889668 + pending

Dear maintainer,

I've prepared an NMU for util-linux (versioned as 2.31.1-0.2) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru util-linux-2.31.1/debian/changelog util-linux-2.31.1/debian/changelog
--- util-linux-2.31.1/debian/changelog  2018-02-09 19:16:51.0 +0100
+++ util-linux-2.31.1/debian/changelog  2018-02-13 12:19:06.0 +0100
@@ -1,3 +1,11 @@
+util-linux (2.31.1-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install fstrim.timer and fstrim.service without enabling it by default
+(for now), see discussion in #732054 (Closes: #889668)
+
+ -- Laurent Bigonville   Tue, 13 Feb 2018 12:19:06 +0100
+
 util-linux (2.31.1-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru util-linux-2.31.1/debian/rules util-linux-2.31.1/debian/rules
--- util-linux-2.31.1/debian/rules  2018-02-09 19:16:51.0 +0100
+++ util-linux-2.31.1/debian/rules  2018-02-13 11:45:16.0 +0100
@@ -157,6 +157,10 @@
 override_dh_fixperms:
dh_fixperms -i -a -Xusr/bin/wall -Xbin/mount -Xbin/umount
 
+override_dh_installsystemd:
+   dh_installsystemd -putil-linux --no-enable --no-start fstrim.timer 
fstrim.service
+   dh_installsystemd --remaining-packages
+
 override_dh_auto_test:
 ifeq ($(DEB_HOST_ARCH_OS), linux)
dh_auto_test --max-parallel=1
diff -Nru util-linux-2.31.1/debian/util-linux.install 
util-linux-2.31.1/debian/util-linux.install
--- util-linux-2.31.1/debian/util-linux.install 2018-02-09 19:16:51.0 
+0100
+++ util-linux-2.31.1/debian/util-linux.install 2018-02-12 18:03:47.0 
+0100
@@ -7,8 +7,8 @@
 [linux-any] sbin/mkswap
 [!linux-any] debian/tmp/sbin/mkswap => /sbin/mkswap.linux
 # weekly fstrim only available on linux
-[linux-any] lib/systemd/system/fstrim.timer => 
/usr/share/doc/util-linux/examples/fstrim.timer
-[linux-any] lib/systemd/system/fstrim.service => 
/usr/share/doc/util-linux/examples/fstrim.service
+[linux-any] lib/systemd/system/fstrim.timer
+[linux-any] lib/systemd/system/fstrim.service
 bin/findmnt
 bin/more
 bin/mountpoint

Bug#889417: Pending fixes for bugs in the httpcomponents-core package

[pkg-java-maintainers]

tag 889417 + pending
thanks

Some bugs in the httpcomponents-core package are closed in revision
33a91477fb93e999f74bd1e1044e6dc981eb906e in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/httpcomponents-core.git/commit/?id=33a9147

Commit message:

Removed Damien Raude-Morvan from the uploaders (Closes: #889417)

Bug#762753: moreinfo

[Raphael Hertzog]

Control: tag -1 - moreinfo

On Mon, 27 Oct 2014, Bastien ROUCARIES wrote:
> Do you have some normative element about this tag?

It's not hard to find:
https://en.wikipedia.org/wiki/Canonical_link_element
https://tools.ietf.org/html/rfc6596

And I agree that this is false positive that should be fixed.

I use this field in debian-handbook to help search engines understand
taht the copy hosted on debian.org is the same as the one
on debian-handbook.info (the canonical location) and there's
no reason to forbid this.

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/

Bug#890316: neovim: cmd line shows special chars like":]2 q" instead of ":"

[Luffah]

Package: neovim
Version: 0.2.2-2
Severity: normal

Hello Maintainer,

   When i open `nvim -u NONE` and i press ':' command line
   shows special chars like":]2 q" instead of ":" .

Have a good day.

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

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

Versions of packages neovim depends on:
ii  libc62.24-11+deb9u1
ii  libjemalloc1 3.6.0-9.1
ii  libluajit-5.1-2  2.0.4+dfsg-1+b1
ii  libmsgpackc2 2.1.5-1
ii  libtermkey1  0.19-1
ii  libunibilium01.2.0-1
ii  libuv1   1.9.1-3
ii  libvterm00~bzr684-1
ii  neovim-runtime   0.2.2-2

Versions of packages neovim recommends:
pn  python-neovim   
pn  python3-neovim  
ii  xsel1.2.0-2+b1
ii  xxd 2:8.0.0197-4+deb9u1

Versions of packages neovim suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-11
pn  vim-scripts  

-- no debconf information

Bug#890315: python-docutils autopkg test needs to depend on 2to3 and use it instead of 2to3-3.6

[Matthias Klose]

Package: src:python-docutils
Version: 0.14+dfsg-2
Severity: important
Tags: sid buster

python-docutils autopkg tests are currently failing. the test needs to depend on
2to3 and use it instead of 2to3-3.6.

Bug#890313: awl: please make the build reproducible

[Chris Lamb]

Source: awl
Version: 0.59-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that awl could not be built reproducibly as it includes the
absolute build path in the doxygen output of an example.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2018-02-13 10:34:07.574275733 
+
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-02-13
+
+--- awl-0.59.orig/docs/Doxyfile
 awl-0.59/docs/Doxyfile
+@@ -873,7 +873,7 @@ RECURSIVE  = NO
+ # Note that relative paths are relative to the directory from which doxygen is
+ # run.
+ 
+-EXCLUDE=
++EXCLUDE= inc/iCalendar.php
+ 
+ # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+ # directories that are symbolic links (a Unix file system feature) are 
excluded
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2018-02-13 10:02:49.617251167 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#890314: cpl-plugin-visir: please make the build reproducible

[Chris Lamb]

Source: cpl-plugin-visir
Version: 4.3.3+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that cpl-plugin-visir could not be built reproducibly.

I think the index-based sorting is broken for some reason (probably
not reliably sorted prior to this) so moving to name-based in the
attached patch.


 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/create_sphinx.py   2018-02-13 09:42:43.632869456 +
--- b/debian/create_sphinx.py   2018-02-13 10:31:36.269867461 +
@@ -142,8 +142,7 @@
 oca = file(os.path.join("calib", "gasgano", "config", pipeline + 
".oca")).read()
 oca = oca[oca.find("action"):]
 recipes_oca = [recipe for recipe in recipes if recipe.__name__ in oca]
-index = [ oca.find(recipe.__name__) for recipe in recipes_oca ]
-recipes_oca = [r for (i, r) in sorted(zip(index, recipes_oca))]
+recipes_oca.sort(key = lambda x: x.__name__)
 
 recipes_x = [recipe for recipe in recipes if not recipe.__name__ in oca]
 recipes_x.sort(key = lambda x: x.__name__)

Bug#890312: desmume: please make the build reproducible

[Chris Lamb]

Source: desmume
Version: 0.9.11-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that desmume could not be built reproducibly.

The absolute build path ends up in the binary.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/configure.ac  2018-02-13 09:42:15.241096798 +
--- b/configure.ac  2018-02-13 10:26:54.357061647 +
@@ -169,7 +169,7 @@
 AC_SUBST(LIBGLADE_LIBS)
 
 dnl uninstalled glade ui dir
-
AC_DEFINE_UNQUOTED(GLADEUI_UNINSTALLED_DIR,"`pwd`/src/gtk-glade/glade/",[path 
to glade ui dir])
+AC_DEFINE_UNQUOTED(GLADEUI_UNINSTALLED_DIR,"src/gtk-glade/glade/",[path to 
glade ui dir])
 AC_SUBST(GLADEUI_UNINSTALLED_DIR)
 
 PKG_CHECK_MODULES(GTKGLEXT,

Bug#884956: vlc: icons are too big

[Vincent Lefevre]

Control: retitled -1 Qt 5: HiDPI scaling is broken

On 2018-02-13 10:11:45 +0100, Sebastian Ramacher wrote:
> … and QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to a workaround.

I confirm. And this also fixes font size, e.g. for the menus (the font
was smaller than the one in the Gtk apps).

This also avoids bug 884953 with the nVidia driver.

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

Bug#877388: s-nail adoption (build flags)

[Paride Legovini]

Hi Hilko,

I've been working a little bit on the package, and it seems to me that
at the moment the Debian build flags (CFLAGS and LDFLAGS as set by the
debhelper scripts) are not actually used when building the package.

Note for example this error (happens during dh_auto_install):

ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
/bin/chown: changing ownership of
'/tmp/s-nail/debian/s-nail/usr/lib/s-nail/s-nail-privsep': Operation not
permitted
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.

and these lintian messages:

I: s-nail: hardening-no-fortify-functions usr/bin/s-nail
I: s-nail: hardening-no-fortify-functions usr/lib/s-nail/s-nail-privsep

W: s-nail-dbgsym: debug-file-with-no-debug-symbols
usr/lib/debug/.build-id/a7/0016ff0ddb7b0e70321b28e68f529204140f60.debug
W: s-nail-dbgsym: debug-file-with-no-debug-symbols
usr/lib/debug/.build-id/b0/3145705a4f0f2c7171bac4dc4b2c2ba23bb372.debug

Adding a couple of lines like:

export EXTRA_CFLAGS="$(CFLAGS)"
export EXTRA_LDFLAGS="$(LDFLAGS)"

in d/rules makes the debug-file-with-no-debug-symbols warning go away,
so I truly think the Debian CFLAGS and LDFLAGS were not used.
Unfortunately this seems not to be sufficient to fix the other issues,
something I would like to do even if s-nail works fine as is.

Now I don't want you to dig into this issue for me, but if you already
thought about it in the past and somehow concluded, for example, that
those errors/warning are both unavoidable and not harmful, I'd like to
hear from you.

Thanks again,

Paride

Bug#890311: dashel: please make the build reproducible

[Chris Lamb]

Source: dashel
Version: 1.3.3-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that dashel could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2018-02-13 10:07:25.209962694 
+
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-02-13
+
+--- dashel-1.3.3.orig/dashelConfig.cmake.in
 dashel-1.3.3/dashelConfig.cmake.in
+@@ -42,8 +42,6 @@ else (WIN32)
+ endif (WIN32)
+ 
+ # Standard search
+-find_path(dashel_INCLUDE_DIRS dashel/dashel.h @PROJECT_SOURCE_DIR@ 
CMAKE_FIND_ROOT_PATH_BOTH)
+-find_library(dashel_LIBRARY dashel @PROJECT_BINARY_DIR@ 
CMAKE_FIND_ROOT_PATH_BOTH)
+ set(dashel_LIBRARIES ${dashel_LIBRARY} ${EXTRA_LIBS})
+ include(FindPackageHandleStandardArgs)
+ find_package_handle_standard_args(dashel DEFAULT_MSG dashel_LIBRARIES 
dashel_INCLUDE_DIRS)
--- a/debian/patches/series 2018-02-13 09:44:22.104092658 +
--- b/debian/patches/series 2018-02-13 10:07:24.237960278 +
@@ -1 +1,2 @@
 dashel-posix.cpp.patch
+reproducible-build.patch

Bug#890276: marked as done (RFS: wine/3.0-1~bpo9+1)

[Ferenc Wágner]

"Debian Bug Tracking System"  writes:

> For the sake of others who upload a backport-relying-on-backports, the
> incantation is:
>
> sbuild --build-dep-resolver=aptitude -s -d stretch-backports -c 
> stretch-amd64-sbuild wine_3.0-1~bpo9+1.dsc

You can leave out the -c option if you add
aliases=stretch-backports-amd64-sbuild to your stretch-amd64-sbuild
schroot config file (and of course APT in the chroot must know the
backports sources).
-- 
Regards,
Feri

Bug#886638: (No Subject)

[J.R Null]

Still present with gcc-7-aarch64-linux-gnu (7.3.0-1cross1).

Anyone reading this? Did I send the bug to the right tracker?

Bug#888765: Also affects compose-addressbook and others

[Athanasius]

  I'm also having to fix things with a symbolic link, so far for both:

compose-addressbook
keyboard-shortcuts

I'm only just setting up roundcube so may find others.  I can see
/var/lib/roundcube/plugins/ has also (with a - in them):

message-highlight
thunderbird-labels
virtuser_query

All five of these use _ in the main .php filename.
-- 
- Athanasius = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

Bug#890310: ITP: golang-github-containerd-fifo -- fifo pkg for Go

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: golang-github-containerd-fifo
  Version : 0.0~git20170714.fbfb6a1-1
  Upstream Author : containerd
* URL : https://github.com/containerd/fifo
* License : Apache-2.0
  Programming Lang: Go
  Description : fifo pkg for Go

 Go package for handling fifos in a sane way.

 This is a dependency of containerd.

Bug#890308: nautilus: Cannot delete folder on mounted smb share

[Massimo Barbieri]

Package: nautilus
Version: 3.26.2-2
Severity: normal

Dear Maintainer,

I can delete files, but I cannot delete folder on mounted samba shares. I do
not receve any error but the folder I want to delete is still there.

Thanks, in advance
Max-B



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-2
ii  gsettings-desktop-schemas  3.24.1-2
ii  gvfs   1.34.1-2
ii  libatk1.0-02.26.1-3
ii  libc6  2.26-4
ii  libcairo-gobject2  1.15.10-1
ii  libcairo2  1.15.10-1
ii  libexempi3 2.4.4-1
ii  libexif12  0.6.21-4
ii  libgail-3-03.22.26-2
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libglib2.0-0   2.54.3-2
ii  libglib2.0-data2.54.3-2
ii  libgnome-autoar-0-00.2.2-3
ii  libgnome-desktop-3-12  3.26.2-6
ii  libgtk-3-0 3.22.26-2
ii  libnautilus-extension1a3.26.2-2
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libselinux12.7-2+b1
ii  libtracker-sparql-2.0-02.0.3-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.26.2-2
ii  shared-mime-info   1.9-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.24.0-3
ii  gvfs-backends1.34.1-2
ii  librsvg2-common  2.40.20-2

Versions of packages nautilus suggests:
ii  eog 3.26.2-3
ii  evince [pdf-viewer] 3.26.0-3
ii  nautilus-extension-brasero  3.12.2-4
ii  nautilus-sendto 3.8.6-2
ii  totem   3.26.0-3
ii  tracker 2.0.3-1
ii  vlc [mp3-decoder]   3.0.0~rc8-1
ii  xdg-user-dirs   0.16-1

-- no debconf information

Bug#890309: make-dfsg fails it's tests on multiple architectures, including amd64

[Matthias Klose]

Package: src:make-dfsg
Version: 4.2.1-1
Severity: serious

according to https://buildd.debian.org/status/package.php?p=make-dfsg
make-dfsg fails tests on at least arm64, armhf, armel, i386, mipsel.

Test timed out after 30 seconds
Error running /<>/debian/build-make/tests/../make (expected 0; got
14): /<>/debian/build-make/tests/../make -f
work/features/output-sync.mk -j -Orecurse

Caught signal 14!
FAILED (14/15 passed)

I see it failing on amd64 and ppc64el as well here:
https://launchpad.net/ubuntu/+source/make-dfsg/4.2.1-1

Bug#889028: fixed in minissdpd 1.5.20161216-2

[Thomas Goirand]

On 02/02/2018 08:34 PM, f4...@f4fxl.org wrote:
> Hi,
> 
> I beg your pardon, but this looks like a half baked feature.
> IMHO package is missing some sort of migration from previous versions.
> Packages are not supposed to require manual steps or shall prompt the
> user what to do during update.

Could you explain what's wrong with the migration ? The file is in
/etc/default, so it's marked as CONFFILES, and as such, if you changed
it, dpkg will do a prompt. In my case, it did:

Setting up minissdpd (1.5.20161216-2~bpo9+1) ...
Installing new version of config file /etc/default/minissdpd ...
Installing new version of config file /etc/init.d/minissdpd ...

I don't see any trouble here...

If you do, please explain.

> Previous version seemed to accept 0.0.0.0 to listen on all interfaces,
> it is unclear what is required to achieve the same.

As much as I understand, you're supposed to just configure one interface
or IP pool, and miniupnpd will listen on all IPs on that device / pool.

/usr/sbin/minissdpd --help explains this.

If you just enter an interface name, like let's say eth0, then it will
listen on that. If you enter 0.0.0.0/0, then it will listen on
everything, no mater what. I tried putting 0.0.0.0 without the trailing
/0, and it looks like also working.

> Moreover, entering a
> valid address like the example specified in the error message also fails.

Contributions, suggestions, ideas are more than welcome for improving
the package.

Cheers,

Thomas Goirand (zigo)

Bug#890306: RFS: sphinxcontrib-doxylink/1.5-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sphinxcontrib-doxylink"

* Package name: sphinxcontrib-doxylink
  Version : 1.5-1
  Upstream Author : Matt Williams
* URL : https://github.com/sphinx-contrib/doxylink
* License : BSD
  Section : python

It builds those binary packages:

  python3-sphinxcontrib.doxylink - Sphinx extension for linking to Doxygen 
documentation (Python 3)

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

  https://mentors.debian.net/package/sphinxcontrib-doxylink

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sphinxcontrib-doxylink/sphinxcontrib-doxylink_1.5-1.dsc

Packaging repository:

  https://salsa.debian.org/python-team/modules/sphinxcontrib-doxylink

Debomatic build:

  
http://debomatic-amd64.debian.net/distribution#unstable/sphinxcontrib-doxylink/1.5-1

Changes since the last upload:

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org

  [ Ghislain Antony Vaillant ]
  * d/gbp.conf: Sign all tags
  * d/gbp.conf: Drop pq section
  * Source future releases from GitHub
  * New upstream version 1.5
  * Drop the patch queue, fixed upstream
  * Drop the packaging for Python 2, dropped upstream
  * Add new build dependency on doxygen and pytest
  * Add pybuild setup for running the tests
  * Run autopkgtests for all supported Python versions
  * Point the Homepage URI to the GitHub repository
  * Update the copyright years
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Normalize the package descriptions

Regards,
Ghislain Vaillant

Bug#890307: tortoisehg: needs update for mercurial 4.5

[Julien Cristau]

Package: tortoisehg
Version: 4.4.1-1
Severity: serious
X-Debbugs-Cc: mithra...@mithrandi.net

tortoisehg is uninstallable in sid since mercurial was updated to 4.5.

Cheers,
Julien

Bug#889028: minissdpd (1.5.20161216-2) assumes IPV6

[miniupnp]

It looks like the "-6" option is included MiniSSDPd_OTHER_OPTIONS
That causes minissdpd to fail to launch if IPv6 is disabled on the machine
https://salsa.debian.org/miniupnp-team/minissdpd/blob/debian-sid/debian/default#L16

Regards,

Thomas Bernard

Bug#890305: cppcheck still depends on python:any

[Alexandre Detiste]

Package: cppcheck
Version: 1.82-1
Severity: normal

Hi,

Thanks for migrating this package to python3.

There remains a tiny part of work to do:
replace the line "X-Python-Version: >= 2.6"
in debian/control by "X-Python3-Version: >= 3.5".

Greetings,

Alexandre

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cppcheck depends on:
ii  libc6 2.26-4
ii  libgcc1   1:7.2.0-19
ii  libpcre3  2:8.39-9
ii  libstdc++67.2.0-19
ii  libtinyxml2-6 6.0.0+dfsg-1
ii  python2.7.14-4
ii  python3-pygments  2.2.0+dfsg-1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
pn  cppcheck-gui  

-- no debconf information

Bug#890304: source:urwid-satext: new version 0.7.0D available

[W. Martin Borgert]

Source: urwid-satext
Version: 0.6.1-1
Severity: wishlist

Hi,

upstream is working on a new version 0.7.0.
The current pre-alpha is 0.7.0D.
According to upstream, this version is at least as good as 0.6.1.
If you don't mind, I'll update the package soon™.

Cheers

Bug#890281: xkbset FTCBFS: uses the build architecture compiler

[Paul Gevers]

Hi Helmut,

On 12-02-18 22:45, Helmut Grohne wrote:
> xkbset fails to cross build from source, because it uses the build
> architecture toolchain. dh_auto_build fixes that. Then it fails to cross
> build, because it uses the build architecture strip via install. The
> easiest way to fix that (deferring stripping to dh_strip) happens to
> also fix #438298. The attached patch contains both fixes. Please
> consider applying it. In compat 11, dh_auto_install will do.

I suggest you move to compat 11 and make the appropriate fixes in the
git archive. We'll upload soon (or feel free to do so yourself).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#890027: librsvg: please make the output reproducible

[Chris Lamb]

Chris Lamb wrote:

> I've forwarded this upstream here:
>
>  https://gitlab.gnome.org/GNOME/librsvg/merge_requests/10

Note that the patch is been updated at this URL after some discussion.


Regards,

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

Bug#890303: htslib: autopokgtest failure

[Graham Inggs]

Source: htslib
Version: 1.7-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

Since the upload of 1.7-1, htslib's autopkgtests have been
failing [1] with the following error:

autopkgtest [02:32:04]: test run-unit-test: [---
make: ./version.sh: Command not found
make: ./version.sh: Command not found
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o bgzip.o bgzip.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o kfunc.o kfunc.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o knetfile.o knetfile.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o kstring.o kstring.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o bcf_sr_sort.o bcf_sr_sort.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o bgzf.o bgzf.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o errmod.o errmod.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o faidx.o faidx.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o hfile.o hfile.c
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o hfile_net.o hfile_net.c

echo '#define HTS_VERSION ""' > version.h
gcc -O2 -fno-strict-aliasing -fno-code-hoisting -I. -Wdate-time 
-D_FORTIFY_SOURCE=2 -c -o hts.o hts.c

make: *** No rule to make target 'os/rand.c', needed by 'hts_os.o'.  Stop.
autopkgtest [02:32:10]: test run-unit-test: ---]
autopkgtest [02:32:10]: test run-unit-test:  - - - - - - - - - - results 
- - - - - - - - - -

run-unit-testFAIL non-zero exit status 2

Regards
Graham


[1] https://ci.debian.net/packages/h/htslib/unstable/amd64/

Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org

[Pierre-Elliott Bécue]

Le mardi 13 février 2018 à 10:07:52+0100, Guido Günther a écrit :
> On Tue, Feb 13, 2018 at 09:56:28AM +0100, Pierre-Elliott Bécue wrote:
> > Le mardi 13 février 2018 à 09:45:43+0100, Guido Günther a écrit :
> > > we can leave most of these out since they're not required:
> > >
> > >   https://docs.gitlab.com/ce/api/projects.html#create-project
> > 
> > Yes, but the defaults seem awkward to me for Debian git repositories, hence
> > the suggestion to set them.
> 
> I was hoping that not setting anything would use the salsa wide
> defaults? If not we set them to the same values that you get by default.

Nah, have a look at the output json example I pasted.

It's as you wish, but this default json seems really appropriate to me, at
least for the public vs private status of the project.

> > 
> > The only required intel is actually the project's name.
> > 
> > > > Python has plenty json api packages to send such json, so it's a matter 
> > > > of
> > > > implementation.
> > > 
> > > We already use requests for http so this can be used to simplify things
> > > furhter. There's also python3-gitlab.
> > 
> > Should we try to rely on p3-gitlab or to stick with requests?
> 
> Both is fine with me. The later would have the advantage that we could
> use it later to set hooks like the hook_tagpending.sh in salsa-scripts.
> If using p3-salsa we should make the use optional, that is fail if one
> wants to create a repo on salsa without p3-gitlab installed (so it stays
> simple for folks to port to other distros).

I'll give a try with requests.

> > > > I could take some time to code that, but I'd rather we agree on the 
> > > > "how"
> > > > and the "what" before spending any time in such work.
> > > 
> > > Would be great. Especially since we'd need some logic to figure out if
> > > the remote end is using gitlab. For the moment we could just do:
> > > 
> > >--remote-type=git+ssh (old behaviour)
> > >--remote-type=gitlab  (what you just describe)
> > >--remote-type=auto
> > >
> > > The last option could just look into a fixed list within create_repo
> > > 
> > >gitlab_hosts = ['salsa.debian.org'] 
> > > 
> > > to figure out what to do.
> > 
> > Could you help me confirming what are the different steps supposed to be
> > handled by create-remote-repo?
> > 
> > I assume it's roughly these:
> > 
> >  1. Find the url and determine the configurations, in particular, check if
> > such a remote doesn't alreaty exist in the .git/config file.
> 
> Yes, gbp-create-repo does this already.
>
> >  2. Create the actual remote repo
> >  3. Update the local git config with this remote.
> >  4. Push to this new remote.
> 
> Yes, see create_repo. The only part that needs to be adjusted is around
> build_remote_script.
> 
> > 
> > Am I right?
> 
> Yes, most of this is already here. As a bonus we could resolve insteadOf
> references but that could be a different patch/bug.

Alright, I'll give it a look and a try.

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2


signature.asc
Description: PGP signature

Bug#888313: please allow git remote configuration (e.g. for upstream remote)

[Guido Günther]

Hi,
Thanks for having a look.

On Tue, Feb 13, 2018 at 09:59:02AM +0100, Michael Stapelberg wrote:
> See the attached work-in-progress patch for how far I got at this point.
> Before I continue, here are two questions:
> 
> AFAICT, the control package doesn’t allow me to do case-insensitive
> lookups. Should we extend it to do that, or do we really want to insist on
> users capitalizing the directives correctly?

Policy says:

| Field names are not case-sensitive, but it is usual to capitalize the
| field names using mixed case as shown below. Field values are case-
| sensitive unless the description of the field says otherwise.

so we should capitalize them. We can likely do with a single control
file entry like:

X-Vcs-Upstream-Git:  -b 

which would match the existing Vcs-* syntax.

> Also, I’m wondering whether we should set up a branch automatically (e.g.
> “upstream” tracking “upstream/master”), not at all, or behind another
> option. This ties into our branch naming and import workflow discussion.
> Thoughts?

I would start out with naming the remote 'upstream'. I'm not sure
whether we need tracking branches. When I track remote git I usually
don't track upstream but rather only fetch from the remote. Different
people might have different expectations here so we likely need to come
up with an option to configure this.

Cheers,
 -- Guido

Bug#884956: vlc: icons are too big

[Sebastian Ramacher]

On 2018-02-13 10:07:02, Sebastian Ramacher wrote:
> Control: reassign -1 libqt5core5a 5.9.2+dfsg-6
> Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-53022
> Control: severity -1 normal
> Control: tags -1 = upstream
> 
> On 2017-12-21 23:39:03, Vincent Lefevre wrote:
> > Package: src:vlc
> > Version: 3.0.0~rc2-1
> > Severity: minor
> > 
> > Icons appear to be too big (much bigger than the associated text).
> > I don't think this is intentional. VLC 2.x didn't have such a problem.
> > 
> > I've attached a screenshot of a part of the main window.
> > 
> > Just in case this matters, the configured Xft.dpi is 132, and I can
> > see in ".config/vlc/vlc-qt-interface.conf", in particular:
> 
> It seems to be a Qt bug (maybe related to QTBUG-53022). Fedora seems to carry 
> a
> patch for that (https://bugzilla.redhat.com/show_bug.cgi?id=1381828).

… and QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to a workaround.

Cheers

> 
> Cheers
> 
> > 
> > [FullScreen]
> > pos=@Point(1200 1732)
> > screen=@Rect(0 0 3200 1800)
> > wide=false
> > 
> > [MainWindow]
> > QtStyle=System's default
> > adv-controls=0
> > bgSize=@Size(100 30)
> > pl-dock-status=true
> > playlist-visible=true
> > playlistSize=@Size(600 300)
> > status-bar-visible=false
> > 
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> > (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages vlc depends on:
> > ii  vlc-bin  3.0.0~rc2-1
> > ii  vlc-l10n 3.0.0~rc2-1
> > ii  vlc-plugin-base  3.0.0~rc2-1
> > ii  vlc-plugin-qt3.0.0~rc2-1
> > ii  vlc-plugin-video-output  3.0.0~rc2-1
> > 
> > Versions of packages vlc recommends:
> > ii  vlc-plugin-notify  3.0.0~rc2-1
> > ii  vlc-plugin-samba   3.0.0~rc2-1
> > ii  vlc-plugin-skins2  3.0.0~rc2-1
> > ii  vlc-plugin-video-splitter  3.0.0~rc2-1
> > ii  vlc-plugin-visualization   3.0.0~rc2-1
> > 
> > vlc suggests no packages.
> > 
> > Versions of packages libvlc-bin depends on:
> > ii  libc62.25-5
> > ii  libvlc5  3.0.0~rc2-1
> > 
> > Versions of packages libvlc5 depends on:
> > ii  libc62.25-5
> > ii  libvlccore9  3.0.0~rc2-1
> > 
> > Versions of packages libvlc5 recommends:
> > ii  libvlc-bin  3.0.0~rc2-1
> > 
> > Versions of packages vlc-bin depends on:
> > ii  libc6   2.25-5
> > ii  libvlc-bin  3.0.0~rc2-1
> > ii  libvlc5 3.0.0~rc2-1
> > 
> > Versions of packages vlc-plugin-base depends on:
> > ii  liba52-0.7.4 0.7.4-19
> > ii  libarchive13 3.2.2-3.1
> > ii  libaribb24-0 1.0.3-1
> > ii  libasound2   1.1.3-5
> > ii  libass9  1:0.14.0-1
> > ii  libavahi-client3 0.7-3
> > ii  libavahi-common3 0.7-3
> > ii  libavc1394-0 0.5.4-4+b1
> > ii  libavcodec57 7:3.4.1-1+b1
> > ii  libavformat577:3.4.1-1+b1
> > ii  libavutil55  7:3.4.1-1+b1
> > ii  libbasicusageenvironment12017.10.28-2
> > ii  libbluray2   1:1.0.2-1
> > ii  libc62.25-5
> > ii  libcairo21.14.10-1
> > ii  libcddb2 1.3.2-5
> > ii  libchromaprint1  1.4.2-1
> > ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
> > ii  libdbus-1-3  1.12.2-1
> > ii  libdc1394-22 2.2.5-1
> > ii  libdca0  0.0.5-10
> > ii  libdvbpsi10  1.3.1-2
> > ii  libdvdnav4   5.0.3-3
> > ii  libdvdread4  5.0.3-2
> > ii  libebml4v5   1.3.5-2
> > ii  libfaad2 2.8.8-1
> > ii  libflac8 1.3.2-1
> > ii  libfontconfig1   2.12.6-0.1
> > ii  libfreetype6 2.6.3-3.2
> > ii  libfribidi0  0.19.7-2
> > ii  libgcc1  1:7.2.0-18
> > ii  libgcrypt20  1.8.1-4
> > ii  libglib2.0-0 2.54.2-3
> > ii  libgnutls30  3.5.16-1
> > ii  libgpg-error01.27-5
> > ii  libgroupsock82017.10.28-2
> > ii  libharfbuzz0b1.4.2-1
> > ii  libjpeg62-turbo  1:1.5.2-2+b1
> > ii  libkate1 0.4.1-7+b1
> > ii  

Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org

[Guido Günther]

On Tue, Feb 13, 2018 at 09:56:28AM +0100, Pierre-Elliott Bécue wrote:
> Le mardi 13 février 2018 à 09:45:43+0100, Guido Günther a écrit :
> > Hi,
> > On Mon, Feb 12, 2018 at 06:10:09PM +0100, Pierre-Elliott Bécue wrote:
> > > Speaking to the gitlab API is actually quite simple.
> > > 
> > > The user has to create his own private token with API access. Then gbp
> > > would require a new config parameter to fetch such a token from the
> > > .gitconfig of the user, or a new option to the create-remote-repo command 
> > > to
> > > provide it.
> > > 
> > > Then, if the user wants to create the repo in a specific namespace (group,
> > > subgroup, whatever), he has to fetch the appropriate namespace_id. I 
> > > didn't
> > > find a basic method so far, but some urls contain it, so I found 2781 for
> > > DPMT subgroup.
> > > 
> > > Then, it's only about designing a POST request:
> > > 
> > > I made a simple json file: temp/test.json
> > > {
> > > "name": "apiproject",
> > > "namespace_id": 2781
> > > }
> > > 
> > > Then, I ran
> > > 
> > > # curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type: 
> > > application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects 
> > > -d "$(cat temp/test.json)"
> > > 
> > > {
> > > "id":12590,
> > > "description":null,
> > > "name":"apiproject",
> > > "name_with_namespace":"Debian Python Team / DPMT / apiproject",
> > > "path":"apiproject",
> > > "path_with_namespace":"python-team/modules/apiproject",
> > > "created_at":"2018-02-12T16:54:58.691Z",
> > > "default_branch":null,
> > > "tag_list":[],
> > > 
> > > "ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
> > > 
> > > "http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
> > > "web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
> > > "avatar_url":null,
> > > "star_count":0,
> > > "forks_count":0,
> > > "last_activity_at":"2018-02-12T16:54:58.691Z",
> > > "_links":{
> > > "self":"http://salsa.debian.org/api/v4/projects/12590;,
> > > 
> > > "merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
> > > 
> > > "repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
> > > "labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
> > > "events":"http://salsa.debian.org/api/v4/projects/12590/events;,
> > > "members":"http://salsa.debian.org/api/v4/projects/12590/members;
> > > },
> > > "archived":false,
> > > "visibility":"private",
> > > "resolve_outdated_diff_discussions":false,
> > > "container_registry_enabled":true,
> > > "issues_enabled":false,
> > > "merge_requests_enabled":true,
> > > "wiki_enabled":true,
> > > "jobs_enabled":true,
> > > "snippets_enabled":true,
> > > "shared_runners_enabled":true,
> > > "lfs_enabled":true,
> > > "creator_id":1983,
> > > "namespace":{
> > > "id":2781,
> > > "name":"DPMT",
> > > "path":"modules",
> > > "kind":"group",
> > > "full_path":"python-team/modules",
> > > "parent_id":2779
> > > },
> > > "import_status":"none",
> > > "import_error":null,
> > > "runners_token":"such_token_much_wow",
> > > "public_jobs":true,
> > > "ci_config_path":null,
> > > "shared_with_groups":[],
> > > "only_allow_merge_if_pipeline_succeeds":false,
> > > "request_access_enabled":false,
> > > "only_allow_merge_if_all_discussions_are_resolved":false,
> > > "printing_merge_request_link_enabled":true
> > > }
> > > 
> > > So, there are some parameters that'd require a default:
> > > 
> > > I suggest this template json for creating a remote repo:
> > > 
> > > {
> > > "name": "%(name)s",
> > > "namespace_id": %(namespace_id)d (if provided),
> > > "issues_enabled": true,
> > > "visibility": "public",
> > > "only_allow_merge_if_all_discussions_are_resolved": true
> > > }
> > 
> > we can leave most of these out since they're not required:
> >
> >   https://docs.gitlab.com/ce/api/projects.html#create-project
> 
> Yes, but the defaults seem awkward to me for Debian git repositories, hence
> the suggestion to set them.

I was hoping that not setting anything would use the salsa wide
defaults? If not we set them to the same values that you get by default.

> 
> The only required intel is actually the project's name.
> 
> > > Python has plenty json api packages to send such json, so it's a matter of
> > > implementation.
> > 
> > We already use requests for http so this can be used to simplify things
> > furhter. There's also python3-gitlab.
> 
> Should we try to rely on p3-gitlab or to stick with requests?

Both is fine with me. The later would have the advantage that we could
use it later to set hooks like the hook_tagpending.sh in salsa-scripts.
If using p3-salsa we should make 

Bug#884956: vlc: icons are too big

[Sebastian Ramacher]

Control: reassign -1 libqt5core5a 5.9.2+dfsg-6
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-53022
Control: severity -1 normal
Control: tags -1 = upstream

On 2017-12-21 23:39:03, Vincent Lefevre wrote:
> Package: src:vlc
> Version: 3.0.0~rc2-1
> Severity: minor
> 
> Icons appear to be too big (much bigger than the associated text).
> I don't think this is intentional. VLC 2.x didn't have such a problem.
> 
> I've attached a screenshot of a part of the main window.
> 
> Just in case this matters, the configured Xft.dpi is 132, and I can
> see in ".config/vlc/vlc-qt-interface.conf", in particular:

It seems to be a Qt bug (maybe related to QTBUG-53022). Fedora seems to carry a
patch for that (https://bugzilla.redhat.com/show_bug.cgi?id=1381828).

Cheers

> 
> [FullScreen]
> pos=@Point(1200 1732)
> screen=@Rect(0 0 3200 1800)
> wide=false
> 
> [MainWindow]
> QtStyle=System's default
> adv-controls=0
> bgSize=@Size(100 30)
> pl-dock-status=true
> playlist-visible=true
> playlistSize=@Size(600 300)
> status-bar-visible=false
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.0~rc2-1
> ii  vlc-l10n 3.0.0~rc2-1
> ii  vlc-plugin-base  3.0.0~rc2-1
> ii  vlc-plugin-qt3.0.0~rc2-1
> ii  vlc-plugin-video-output  3.0.0~rc2-1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  3.0.0~rc2-1
> ii  vlc-plugin-samba   3.0.0~rc2-1
> ii  vlc-plugin-skins2  3.0.0~rc2-1
> ii  vlc-plugin-video-splitter  3.0.0~rc2-1
> ii  vlc-plugin-visualization   3.0.0~rc2-1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.25-5
> ii  libvlc5  3.0.0~rc2-1
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.25-5
> ii  libvlccore9  3.0.0~rc2-1
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.0~rc2-1
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.25-5
> ii  libvlc-bin  3.0.0~rc2-1
> ii  libvlc5 3.0.0~rc2-1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-19
> ii  libarchive13 3.2.2-3.1
> ii  libaribb24-0 1.0.3-1
> ii  libasound2   1.1.3-5
> ii  libass9  1:0.14.0-1
> ii  libavahi-client3 0.7-3
> ii  libavahi-common3 0.7-3
> ii  libavc1394-0 0.5.4-4+b1
> ii  libavcodec57 7:3.4.1-1+b1
> ii  libavformat577:3.4.1-1+b1
> ii  libavutil55  7:3.4.1-1+b1
> ii  libbasicusageenvironment12017.10.28-2
> ii  libbluray2   1:1.0.2-1
> ii  libc62.25-5
> ii  libcairo21.14.10-1
> ii  libcddb2 1.3.2-5
> ii  libchromaprint1  1.4.2-1
> ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
> ii  libdbus-1-3  1.12.2-1
> ii  libdc1394-22 2.2.5-1
> ii  libdca0  0.0.5-10
> ii  libdvbpsi10  1.3.1-2
> ii  libdvdnav4   5.0.3-3
> ii  libdvdread4  5.0.3-2
> ii  libebml4v5   1.3.5-2
> ii  libfaad2 2.8.8-1
> ii  libflac8 1.3.2-1
> ii  libfontconfig1   2.12.6-0.1
> ii  libfreetype6 2.6.3-3.2
> ii  libfribidi0  0.19.7-2
> ii  libgcc1  1:7.2.0-18
> ii  libgcrypt20  1.8.1-4
> ii  libglib2.0-0 2.54.2-3
> ii  libgnutls30  3.5.16-1
> ii  libgpg-error01.27-5
> ii  libgroupsock82017.10.28-2
> ii  libharfbuzz0b1.4.2-1
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libkate1 0.4.1-7+b1
> ii  liblirc-client0  0.10.0-2+b1
> ii  liblivemedia61   2017.10.28-2
> ii  liblua5.2-0  5.2.4-1.1+b2
> ii  libmad0  0.15.1b-8.1
> ii  libmatroska6v5   1.4.8-1.1
> ii  libmicrodns0 0.0.8-1
> ii  libmpcdec6   

Bug#888313: please allow git remote configuration (e.g. for upstream remote)

[Michael Stapelberg]

See the attached work-in-progress patch for how far I got at this point.
Before I continue, here are two questions:

AFAICT, the control package doesn’t allow me to do case-insensitive
lookups. Should we extend it to do that, or do we really want to insist on
users capitalizing the directives correctly?

Also, I’m wondering whether we should set up a branch automatically (e.g.
“upstream” tracking “upstream/master”), not at all, or behind another
option. This ties into our branch naming and import workflow discussion.
Thoughts?

On Mon, Feb 12, 2018 at 12:13 PM, Michael Stapelberg 
wrote:

> When cloning a git repository containing Debian packaging (no matter
> whether you use git-clone or gbp-clone), you’ll end up with one or more
> branches all tracking the remote from which you cloned (e.g. alioth, or
> salsa).
>
> In debian-x, there is https://salsa.debian.org/xorg-team/debian/xsf-tools/
> blob/master/xsf-remote-add-upstream, which takes care of the problem.
>
> We’re discussing adding this feature to git-buildpackage, and were
> wondering whether the suggestion in this bug would be helpful for debian-x,
> too. If debian-x doesn’t use git-buildpackage, the question is moot of
> course (unless you intend to adopt it in the future) :).
>
> On Mon, Feb 12, 2018 at 12:02 PM, Julien Cristau 
> wrote:
>
>> On 02/11/2018 02:20 PM, Michael Stapelberg wrote:
>> > Given that it has been two weeks, I don’t think we’re going to get a
>> > reply from debian-x :)
>>
>> It's not clear to me what the question is.  I've also never used
>> git-buildpackage, so may be missing context.
>>
>> Cheers,
>> Julien
>>
>> >
>> > I’d suggest to just go ahead — I can’t see why the suggested approach
>> > wouldn’t work for debian-x, and even if they need something on top, it’d
>> > be easy to add that later.
>> >
>> > Guido, how do we proceed? Do you want to take care of this, or would you
>> > rely on an external patch for this feature?
>> >
>> > Thanks!
>> >
>> > On Mon, Jan 29, 2018 at 9:47 AM, Guido Günther > > > wrote:
>> >
>> > Hi,
>> > On Thu, Jan 25, 2018 at 09:32:01AM +0100, Michael Stapelberg wrote:
>> > >On Thu, Jan 25, 2018 at 8:11 AM, Guido Günther <[1]
>> a...@sigxcpu.org > wrote:
>> > >
>> > >  Hi Michael,
>> > >  On Wed, Jan 24, 2018 at 10:27:25PM +0100, Michael Stapelberg
>> wrote:
>> > >  > Package: git-buildpackage
>> > >  > Version: 0.9.6
>> > >  > Severity: wishlist
>> > >  >
>> > >  > When using a pure git workflow (no tarballs involved), as
>> documented
>> > >  in
>> > >  >
>> > >  file:///usr/share/doc/git-buildpackage/manual-html/gbp.impor
>> t.upstream-git.html,
>> > >  > it is common to configure the “upstream” git remote to be
>> the actual
>> > >  upstream,
>> > >  > whereas the “origin” git remote would be a repository on
>> alioth.
>> > >  >
>> > >  > E.g., for the golang-text package, I would configure:
>> > >  > remote “origin” is git.debian.org:/git/pkg-go/pac
>> kages/golang-text.git
>> > >  > remote “upstream” is [2]https://github.com/kr/text
>> > >  >
>> > >  > Now, when another team member of the pkg-go team uses
>> gbp-clone on the
>> > >  alioth
>> > >  > repository, they won’t get my “upstream” git remote
>> configuration.
>> > >  >
>> > >  > This means publishing git repositories is lossy: what I
>> have on my
>> > >  hard disk
>> > >  > does not reflect what other team members will get when
>> they clone the
>> > >  > repository.
>> > >  >
>> > >  > This makes updating packages way harder than it should be
>> :)
>> > >  >
>> > >  > Could we add options to debian/gbp.conf to get an upstream
>> git remote
>> > >  configured
>> > >  > automatically when cloning please?
>> > >
>> > >  For purely git based workflow this makes. For this to be
>> nicely
>> > >  integrated we'd
>> > >  need to store the information somehwere in the packakge e.g.
>> > >
>> > >X-Upstream-VCS:
>> > >
>> > >  in debian control so not each packaging team has to cook
>> it's own
>> > >  solution.
>> > >  However it could be nicely protyped using gbp clone's
>> postclone hooks.
>> > >  Cheers,
>> > >   -- Guido
>> > >
>> > >Done, see
>> > >
>> > [3]https://github.com/Debian/pkg-go-tools/blob/master/cmd/p
>> gt-remote-add-upstream/upstream.go
>> > > -remote-add-upstream/upstream.go>
>> > >To install, use:
>> > >% sudo apt install golang-go git
>> > >% go get -u
>> > [4]github.com/Debian/pkg-go-tools/cmd/pgt-remote-add-upstream
>> > 

Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org

[Pierre-Elliott Bécue]

Le mardi 13 février 2018 à 09:45:43+0100, Guido Günther a écrit :
> Hi,
> On Mon, Feb 12, 2018 at 06:10:09PM +0100, Pierre-Elliott Bécue wrote:
> > Speaking to the gitlab API is actually quite simple.
> > 
> > The user has to create his own private token with API access. Then gbp
> > would require a new config parameter to fetch such a token from the
> > .gitconfig of the user, or a new option to the create-remote-repo command to
> > provide it.
> > 
> > Then, if the user wants to create the repo in a specific namespace (group,
> > subgroup, whatever), he has to fetch the appropriate namespace_id. I didn't
> > find a basic method so far, but some urls contain it, so I found 2781 for
> > DPMT subgroup.
> > 
> > Then, it's only about designing a POST request:
> > 
> > I made a simple json file: temp/test.json
> > {
> > "name": "apiproject",
> > "namespace_id": 2781
> > }
> > 
> > Then, I ran
> > 
> > # curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type: 
> > application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects 
> > -d "$(cat temp/test.json)"
> > 
> > {
> > "id":12590,
> > "description":null,
> > "name":"apiproject",
> > "name_with_namespace":"Debian Python Team / DPMT / apiproject",
> > "path":"apiproject",
> > "path_with_namespace":"python-team/modules/apiproject",
> > "created_at":"2018-02-12T16:54:58.691Z",
> > "default_branch":null,
> > "tag_list":[],
> > 
> > "ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
> > 
> > "http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
> > "web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
> > "avatar_url":null,
> > "star_count":0,
> > "forks_count":0,
> > "last_activity_at":"2018-02-12T16:54:58.691Z",
> > "_links":{
> > "self":"http://salsa.debian.org/api/v4/projects/12590;,
> > 
> > "merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
> > 
> > "repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
> > "labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
> > "events":"http://salsa.debian.org/api/v4/projects/12590/events;,
> > "members":"http://salsa.debian.org/api/v4/projects/12590/members;
> > },
> > "archived":false,
> > "visibility":"private",
> > "resolve_outdated_diff_discussions":false,
> > "container_registry_enabled":true,
> > "issues_enabled":false,
> > "merge_requests_enabled":true,
> > "wiki_enabled":true,
> > "jobs_enabled":true,
> > "snippets_enabled":true,
> > "shared_runners_enabled":true,
> > "lfs_enabled":true,
> > "creator_id":1983,
> > "namespace":{
> > "id":2781,
> > "name":"DPMT",
> > "path":"modules",
> > "kind":"group",
> > "full_path":"python-team/modules",
> > "parent_id":2779
> > },
> > "import_status":"none",
> > "import_error":null,
> > "runners_token":"such_token_much_wow",
> > "public_jobs":true,
> > "ci_config_path":null,
> > "shared_with_groups":[],
> > "only_allow_merge_if_pipeline_succeeds":false,
> > "request_access_enabled":false,
> > "only_allow_merge_if_all_discussions_are_resolved":false,
> > "printing_merge_request_link_enabled":true
> > }
> > 
> > So, there are some parameters that'd require a default:
> > 
> > I suggest this template json for creating a remote repo:
> > 
> > {
> > "name": "%(name)s",
> > "namespace_id": %(namespace_id)d (if provided),
> > "issues_enabled": true,
> > "visibility": "public",
> > "only_allow_merge_if_all_discussions_are_resolved": true
> > }
> 
> we can leave most of these out since they're not required:
>
>   https://docs.gitlab.com/ce/api/projects.html#create-project

Yes, but the defaults seem awkward to me for Debian git repositories, hence
the suggestion to set them.

The only required intel is actually the project's name.

> > Python has plenty json api packages to send such json, so it's a matter of
> > implementation.
> 
> We already use requests for http so this can be used to simplify things
> furhter. There's also python3-gitlab.

Should we try to rely on p3-gitlab or to stick with requests?

> > I could take some time to code that, but I'd rather we agree on the "how"
> > and the "what" before spending any time in such work.
> 
> Would be great. Especially since we'd need some logic to figure out if
> the remote end is using gitlab. For the moment we could just do:
> 
>--remote-type=git+ssh (old behaviour)
>--remote-type=gitlab  (what you just describe)
>--remote-type=auto
>
> The last option could just look into a fixed list within create_repo
> 
>gitlab_hosts = ['salsa.debian.org'] 
> 
> to figure out what to do.

Could you help me confirming what are the different steps supposed to be
handled by 

Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org

[Guido Günther]

Hi,
On Mon, Feb 12, 2018 at 06:10:09PM +0100, Pierre-Elliott Bécue wrote:
> Speaking to the gitlab API is actually quite simple.
> 
> The user has to create his own private token with API access. Then gbp
> would require a new config parameter to fetch such a token from the
> .gitconfig of the user, or a new option to the create-remote-repo command to
> provide it.
> 
> Then, if the user wants to create the repo in a specific namespace (group,
> subgroup, whatever), he has to fetch the appropriate namespace_id. I didn't
> find a basic method so far, but some urls contain it, so I found 2781 for
> DPMT subgroup.
> 
> Then, it's only about designing a POST request:
> 
> I made a simple json file: temp/test.json
> {
> "name": "apiproject",
> "namespace_id": 2781
> }
> 
> Then, I ran
> 
> # curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type: 
> application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects -d 
> "$(cat temp/test.json)"
> 
> {
> "id":12590,
> "description":null,
> "name":"apiproject",
> "name_with_namespace":"Debian Python Team / DPMT / apiproject",
> "path":"apiproject",
> "path_with_namespace":"python-team/modules/apiproject",
> "created_at":"2018-02-12T16:54:58.691Z",
> "default_branch":null,
> "tag_list":[],
> 
> "ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
> 
> "http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
> "web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
> "avatar_url":null,
> "star_count":0,
> "forks_count":0,
> "last_activity_at":"2018-02-12T16:54:58.691Z",
> "_links":{
> "self":"http://salsa.debian.org/api/v4/projects/12590;,
> 
> "merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
> 
> "repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
> "labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
> "events":"http://salsa.debian.org/api/v4/projects/12590/events;,
> "members":"http://salsa.debian.org/api/v4/projects/12590/members;
> },
> "archived":false,
> "visibility":"private",
> "resolve_outdated_diff_discussions":false,
> "container_registry_enabled":true,
> "issues_enabled":false,
> "merge_requests_enabled":true,
> "wiki_enabled":true,
> "jobs_enabled":true,
> "snippets_enabled":true,
> "shared_runners_enabled":true,
> "lfs_enabled":true,
> "creator_id":1983,
> "namespace":{
> "id":2781,
> "name":"DPMT",
> "path":"modules",
> "kind":"group",
> "full_path":"python-team/modules",
> "parent_id":2779
> },
> "import_status":"none",
> "import_error":null,
> "runners_token":"such_token_much_wow",
> "public_jobs":true,
> "ci_config_path":null,
> "shared_with_groups":[],
> "only_allow_merge_if_pipeline_succeeds":false,
> "request_access_enabled":false,
> "only_allow_merge_if_all_discussions_are_resolved":false,
> "printing_merge_request_link_enabled":true
> }
> 
> So, there are some parameters that'd require a default:
> 
> I suggest this template json for creating a remote repo:
> 
> {
> "name": "%(name)s",
> "namespace_id": %(namespace_id)d (if provided),
> "issues_enabled": true,
> "visibility": "public",
> "only_allow_merge_if_all_discussions_are_resolved": true
> }

we can leave most of these out since they're not required:
   
  https://docs.gitlab.com/ce/api/projects.html#create-project

> Python has plenty json api packages to send such json, so it's a matter of
> implementation.

We already use requests for http so this can be used to simplify things
furhter. There's also python3-gitlab.

> I could take some time to code that, but I'd rather we agree on the "how"
> and the "what" before spending any time in such work.

Would be great. Especially since we'd need some logic to figure out if
the remote end is using gitlab. For the moment we could just do:

   --remote-type=git+ssh (old behaviour)
   --remote-type=gitlab  (what you just describe)
   --remote-type=auto

The last option could just look into a fixed list within create_repo

   gitlab_hosts = ['salsa.debian.org'] 

to figure out what to do.

Cheers,
 -- Guido

Bug#890302: RFS: libt3widget/0.6.1-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: libt3widget
  Version : 0.6.1-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3widget.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3widget-dev - Development files for libt3widget
  libt3widget1 - C++ terminal dialog toolkit

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3widget/libt3widget_0.6.1-1.dsc

Changes since the last upload:

  * New upstream release.

The upstream release fixes the broken keybindings for F8 and Shift-F8.

Regards,
  Gertjan Halkes

Bug#889653: netdata: missing python module 'pyyaml2'

[Thomas Leuxner]

* Guillaume Clercin  2018.02.12 13:05:

> Hi,
> 
> Finally, after copying "pyyam2" and "pyyaml3" from "python.d/python_modules" 
> from git repository of netdata to "/usr/lib/x86_64-linux-gnu/netdata/python.d/
> python_modules". Netdata's python modules works.

ln -s /usr/lib/python3/dist-packages/yaml/ pyyaml3
ln -s /usr/lib/python2.7/dist-packages/yaml/ pyyaml2

Does it for me. Since the packages are already installed elsewhere this is more 
like a kludge.

Regards
Thomas


signature.asc
Description: PGP signature

Bug#732054: util-linux: Add cron job for regular SSD trimming

[Laurent Bigonville]

Le 12/02/18 à 20:08, Josh Triplett a écrit :

On February 12, 2018 12:22:45 PM EST, Laurent Bigonville  
wrote:


Marco has opened #889668 to just install the .service and the .timer
file at the correct location but not enabling them by default.

I can live with that.


I'll try to see if I can provide a patch.


I guess that it would be a good compromise for now, I also think that
putting these file in an example directory is a bit meh.

But I'm seeing something weird, all my disks on my laptops have the
"discard" option set but for some reasons when running "fstrim -v -a"
it
still says that had trim data on all the FS.

Do I miss something?

Do you have an encrypted root filesystem? Or LVM? You need to take additional 
steps to enable discard if so.


For LVM there is AFAIK nothing to do, the TRIM operation are passed to 
the next layer by default, the only option in the config is to generate 
TRIM when changing the size of a LV.


For the cryptsetup/Luks level, I'm passing the discard option in the 
crypttab.


I just tried on my desktop at home (simple LVM without encryption) and I 
can see the same thing behavior.


Wouldn't that mean running fstrim is actually needed?

Bug#890284: marked as done (RFS: textedit.app/5.0-2 [RC])

[Adam Borowski]

On Tue, Feb 13, 2018 at 09:22:57AM +0200, Yavor Doganov wrote:
> >   * debian/maintscript: New file, replace Resources directory with a
> > symlink (Closes: #890070).
> 
> > Well, the previous version did work for me with C.UTF-8 ...
> 
> What worked?  If you install 5.0-1 afresh, it will work.  Upgrades
> will not work because dpkg will not replace a real directory with a
> symlink (and vice-versa).  We handled this with a preinst before the
> inception of dpkg-maintstript-helper.

A fresh install is exactly what I tested, yeah.


ᛗᛖᛟᚹ!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?