Bug#890375: gnome-tweaks: update changes touchpad right click behavior silently

2018-02-14 Thread Andreas Hehn
Package: gnome-tweaks
Version: 3.27.90-1
Severity: important

Dear Maintainer,

sometime last week I suddenly lost the ability to right and middle click on my
(button-less) synaptics touchpad.
Today I investigated the problem and found out gnome-tweaks was one of the
relevant packages updated last week (3.27.4-1 -> 3.27.90-1).
In the new version I found the "Mouse Click Emulation" setting, which was set
to "Fingers". I realized the right click ability wasn't lost, but the the way
you right click changed from the bottom right corner click on the touchpad to a
two-finger click (I like the idea!).
Setting it to "Area" brought back the old behavior.
This setting is not present on the previous version of gnome-tweaks (3.27.4-1)
(at least on my installation) and I highly suspect the update to 3.27.90-1
changed the setting silently.
This is a really unexpected change which may leave a user puzzled for quite a
while.

I would expect the introduction of such a setting not to change the previous
behavior automatically, but to default on the old behavior.
At least I would expect this change to be announced during the update.

Please let me know if I can be of further assistance to resolve this problem!
Best,
Andreas

-- 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/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-tweaks depends on:
ii  gir1.2-glib-2.01.54.1-4
ii  gir1.2-gnomedesktop-3.03.26.2-6
ii  gir1.2-gtk-3.0 3.22.26-2
ii  gir1.2-notify-0.7  0.7.7-3
ii  gir1.2-pango-1.0   1.40.14-1
ii  gir1.2-soup-2.42.60.3-1
ii  gnome-settings-daemon  3.26.2-1
ii  gnome-shell-common 3.26.2-4
ii  gsettings-desktop-schemas  3.27.90-1
ii  mutter-common  3.26.2-1
ii  nautilus-data  3.26.2-2
ii  python33.6.4-1
ii  python3-gi 3.26.1-2

gnome-tweaks recommends no packages.

gnome-tweaks suggests no packages.

-- no debconf information



Bug#890370: Acknowledgement (borgbackup: Installing borgbackup package from sid can break qgis 2.18.16 and qgis 2.99 )

2018-02-14 Thread Patrick Dunford
Here is the simulated install result on one of my other computers also 
running Debian 9


Why do I need 110 packages updated and 48 new ones for borgbackup?


Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer 
required:

  fonts-freefont-ttf fonts-lyx gdal-bin gdal-data geoclue-2.0 grass-core
  grass-doc iio-sensor-proxy libaec0 libaribb24-0 libarmadillo7 
libarmadillo8

  libarpack2 libbasicusageenvironment1 libboost-atomic1.62.0
  libboost-program-options1.62.0 libboost-regex1.62.0
  libboost-serialization1.62.0 libboost-test1.62.0 libboost-timer1.62.0
  libcddb2 libcdio-cdda1 libcdio-paranoia1 libcgal12 libcoin80v5 libdap23
  libdap25 libdapclient6v5 libdapserver7v5 libdca0 libdirectfb-1.2-9
  libdouble-conversion1 libdrm-dev libdvbpsi10 libebml4v5 libebur128-1
  libepsilon1 libfaad2 libfcgi-bin libfcgi0ldbl libfreexl1 libfyba0 
libgdal20

  libgeoclue-2-0 libgeos-3.5.1 libgeos-c1v5 libgeotiff2 libgl1-mesa-dev
  libglade2-0 libgles1-mesa libgles2-mesa libgltf-0.0-0v5 libglu1-mesa-dev
  libgraphicsmagick-q16-3 libgroupsock8 libgsl2 libhdf4-0-alt libhdf5-100
  libiso9660-8 libjs-jquery-ui libjs-leaflet libjson-c3 libkate1 
libkmlbase1

  libkmlconvenience1 libkmldom1 libkmlengine1 libkmlregionator1 libkmlxsd1
  liblas-c3 liblas3 liblirc-client0 liblivemedia57 liblivemedia62 
liblua5.2-0

  liblwgeom-2.3-0 liblwgeom-dev libmatroska6v5 libmicrodns0 libminizip1
  libmpcdec6 libmtp-common libmtp-runtime libmtp9 libnetcdf11 libnetcdf13
  libodbc1 libogdi3.2 libopencv-core2.4v5 libopencv-imgproc2.4v5
  libopenmpt-modplug1 libopenscenegraph100v5 libopenthreads20 
liborcus-0.11-0

  libpcre16-3 libpcre2-16-0 libproj12 libprotobuf-lite10 libproxy-tools
  libpthread-stubs0-dev libqca-qt5-2 libqca-qt5-2-plugins libqca2
  libqca2-plugin-ossl libqca2-plugins libqgis-core2.14.21
  libqgis-customwidgets libqgis-gui2.14.21 libqgis-native2.99.0
  libqgis-networkanalysis2.14.21 libqgisgrass7-2.14.21 libqgispython2.14.21
  libqhull7 libqscintilla2-12v5 libqscintilla2-l10n libqt4-declarative
  libqt4-designer libqt4-dev libqt4-dev-bin libqt4-help libqt4-network
  libqt4-opengl libqt4-opengl-dev libqt4-qt3support libqt4-script
  libqt4-scripttools libqt4-sql libqt4-sql-mysql libqt4-sql-sqlite 
libqt4-svg
  libqt4-test libqt4-xmlpatterns libqt5clucene5 libqt5concurrent5 
libqt5core5a

  libqt5dbus5 libqt5keychain1 libqt5network5 libqt5positioning5 libqt5qml5
  libqt5scintilla2-l10n libqt5sql5 libqt5sql5-sqlite libqt5test5 libqt5xml5
  libqtassistantclient4 libqtwebkit4 libqwt6abi1 libreoffice-pdfimport
  libresid-builder0c2a libsdl-image1.2 libsfcgal1 libsidplay2
  libspatialindex4v5 libspatialite7 libsqlite3-mod-spatialite libsuperlu5
  libsz2 libtbb2 libupnp6 liburiparser1 libusageenvironment3 libva-drm1
  libvcdinfo0 libvisio-0.1-1 libvlc-bin libvlc5 libvlccore8 libvlccore9
  libx11-dev libx11-doc libx11-xcb-dev libx265-95 libxau-dev 
libxcb-dri2-0-dev
  libxcb-dri3-dev libxcb-glx0-dev libxcb-icccm4 libxcb-image0 
libxcb-keysyms1

  libxcb-present-dev libxcb-randr0 libxcb-randr0-dev libxcb-render-util0
  libxcb-render0-dev libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev
  libxcb-xinerama0 libxcb-xkb1 libxcb-xv0 libxcb1-dev libxdamage-dev
  libxdmcp-dev libxerces-c3.1 libxerces-c3.2 libxext-dev libxfixes-dev
  libxine2 libxine2-bin libxine2-doc libxine2-ffmpeg libxine2-misc-plugins
  libxine2-plugins libxkbcommon-x11-0 libxshmfence-dev libxxf86vm-dev 
libzip4
  mesa-common-dev odbcinst odbcinst1debian2 proj-bin proj-data 
python-cycler

  python-egenix-mxdatetime python-egenix-mxtools python-functools32
  python-gdal python-glade2 python-httplib2 python-jinja2 python-markupsafe
  python-matplotlib python-matplotlib-data python-psycopg2 python-pygments
  python-pyparsing python-pyspatialite python-qgis-common 
python-qscintilla2

  python-qt4 python-qt4-sql python-shapely python-sip python-subprocess32
  python-tz python-yaml python3-bs4 python3-cycler python3-dateutil
  python3-future python3-gdal python3-html5lib python3-jinja2 python3-lxml
  python3-markupsafe python3-matplotlib python3-numpy python3-olefile
  python3-owslib python3-pil python3-plotly python3-psycopg2 
python3-pygments
  python3-pyparsing python3-pyproj python3-sip python3-tz 
python3-webencodings

  python3-yaml python3.5 python3.5-minimal qgis-common
  qgis-plugin-grass-common qgis-providers-common qt4-designer
  qt4-linguist-tools qt4-qmake qttranslations5-l10n vlc-bin vlc-data 
vlc-l10n
  vlc-plugin-base vlc-plugin-notify vlc-plugin-samba 
vlc-plugin-video-output

  vlc-plugin-video-splitter vlc-plugin-visualization x11proto-core-dev
  x11proto-damage-dev x11proto-dri2-dev x11proto-fixes-dev x11proto-gl-dev
  x11proto-input-dev x11proto-kb-dev x11proto-xext-dev
  x11proto-xf86vidmode-dev xorg-sgml-doctools xtrans-dev
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  coinor-libcoinmp1v5 coinor-libcoinutils

Bug#886514: Verdigris - header only Qt moc replacement

2018-02-14 Thread Boris Pek
Hi,

> I was wondering if Verdigris would be suitable for this team.
> Here's RFP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886514
>
> It has just reached 1.0,
> and I am thinking about Debian packaging.
> Your team and sponsorship would be very helpful.

I have seen this article [1] long time ago (about 2016 IIRC). And provided
library was just a proof of concept. Have anything changed since that time?

Are developers going to support this library on constant basis?
Do you have examples of applications which use this library?

[1] https://woboq.com/blog/verdigris-qt-without-moc.html

Best wishes,
Boris



Bug#890376: RFS: tilde/0.4.0-1

2018-02-14 Thread Gertjan Halkes
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: tilde
  Version : 0.4.0-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/tilde.html
* License : GPLv3
  Section : editors

It builds those binary packages:

  tilde - Intuitive text editor for the terminal

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/t/tilde/tilde_0.4.0-1.dsc

Changes since the last upload:

  * New upstream release.

The new upstream releases handles editing files in unmodifiable directories
better, and adds some more menu entries for actions that were already
available through short-cuts.

Regards,
  Gertjan Halkes



Bug#890361: lintian: handling of new source override location possibly buggy

2018-02-14 Thread Chris Lamb
tags 890361 + pending
thanks

Hi Thorsten,

> sorry, I don’t even have a testcase. I only noticed it during
> looking at the source, trying to figure out whether a symlink
> in the new position was good enough.

:)

> >  +last if $file;

Applied here:

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

Many thanks :)


Regards,

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



Bug#890303: [Help] Please fix symbols file of htslib and more importantly check samtools dependency line (Was: Bug#890303: htslib: autopokgtest failure)

2018-02-14 Thread Andreas Tille
Control: tags -1 pending

Hi,

while I think I've fixed the reported bug the upload of htslib came a
bit uncoordinated.  We all know that the dependency line of htslib and
samtools is a bit weak and just uploading the first chain link in an
unfinished state (symbols file is broken and lintian is throwing an
error) should not happen to unstable (at best to experimental).  I'm
currently on my extended travel home from Debian Med sprint and can not
do much more than fixing the bug below but I think an upload should at
least include a fixed symbols file.  Could anybody please care for
this.

Moreover:  I imported samtools 1.7 into Git but the patches do not apply
and also need some work.  Can somebody please take over to make the
samtools chain consistent at least in the beginning?

Thank you

  Andreas.

On Tue, Feb 13, 2018 at 11:28:12AM +0200, Graham Inggs wrote:
> Source: htslib
> Version: 1.7-1
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic autopkgtest
> ...
> 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

-- 
http://fam-tille.de



Bug#890286: rrdcached: "gmetad RRD_update [...] rrdcached: Permission denied" if limited socket specified first

2018-02-14 Thread Jean-Michel Vourgère
Hi Chad

Thank you for your detailed report.

Before I dig more into it, can you double check there is no other instance of 
rrdcached running, and using the same socket location?

I think rrdcached was disabled by default on jessie, and was enabled by 
default on stretch. And since you are using the default rrdcached socket 
location /var/run/rrdcached.sock there might be a conflict there.

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


Bug#890377: [ejabberd] server2server works only if no deny section given

2018-02-14 Thread Michael Kesper
Package: ejabberd
Version: 16.09-4
Severity: normal

--- Please enter the report below this line. ---

If I configure server2server, it only works if no deny section is
configured for access rules.
It doesn't matter whether I deny one single host or a whole list like
https://github.com/agx/jabber-spam-blacklist/

See attached access_rules for one version we tried and
ejabberd_crash.log for a corresponding crash log.

NB: s2s_default_policy: allow is reported as deprecated by this version
and doesn't seem to work at all.

--- System information. ---
Architecture: 
Kernel:   Linux 4.14.0-0.bpo.3-amd64

Debian Release: 9.3
  500 stretch download.docker.com 
  500 stable-updates  ftp2.de.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp2.de.debian.org 
  100 stretch-backports ftp2.de.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-
adduser  | 3.115
openssl  | 1.1.0f-3+deb9u1
ucf  | 3.0036
debconf(>= 0.5)  | 1.5.61
 OR debconf-2.0  | 
init-system-helpers   (>= 1.18~) | 1.48
lsb-base  (>= 3.0-6) | 9.20161125
erlang-base   (>= 1:17)  | 1:19.2.1+dfsg-2+deb9u1
 OR erlang-abi-17.0  | 
erlang-asn1   (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-base  (>= 1:19.2.1+dfsg)  | 1:19.2.1+dfsg-2+deb9u1
 OR erlang-base-hipe  (>= 1:19.2.1+dfsg) | 
erlang-crypto (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-inets  (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-mnesia (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-odbc   (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-public-key (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-ssl(>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-syntax-tools   (>= 1:19.2.1+dfsg) | 1:19.2.1+dfsg-2+deb9u1
erlang-jiffy | 0.14.8+dfsg-1
erlang-lager  (>= 3.2.1) | 3.2.4-1
erlang-p1-cache-tab   (>= 1.0.4) | 1.0.4-2
erlang-p1-iconv   (>= 1.0.2) | 1.0.2-2
erlang-p1-stringprep  (>= 1.0.6) | 1.0.6-2
erlang-p1-tls (>= 1.0.7) | 1.0.7-2+deb9u1
erlang-p1-utils   (>= 1.0.5) | 1.0.5-3
erlang-p1-xml(>= 1.1.15) | 1.1.15-2
erlang-p1-yaml(>= 1.0.6) | 1.0.6-2
erlang-p1-zlib(>= 1.0.1) | 1.0.1-4
erlang-xmerl | 1:19.2.1+dfsg-2+deb9u1


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-=
apparmor | 2.11.0-3
apparmor-utils   | 
libunix-syslog-perl  | 
imagemagick  | 8:6.9.7.4+dfsg-11+deb9u4
yamllint | 
ejabberd-contrib  (>> 0.2015.08) | 
erlang-luerl | 
erlang-p1-oauth2  (>= 0.6.1) | 
erlang-p1-mysql   (>= 1.0.1) | 
erlang-p1-pam (>= 1.0.0) | 
erlang-p1-pgsql   (>= 1.1.0) | 
erlang-p1-sip (>= 1.0.8) | 
erlang-p1-stun(>= 1.0.7) | 
erlang-p1-sqlite3   (>= 1.1.5~dfsg0) | 
erlang-redis-client   (>= 1.0.8) | 
access_rules:
  s2s:
- deny:
  - algebra20.de
  - dcgate.org.ua
  - dmvu.de
  - fritzler-avr.de
  - germes.space
  - invisible.place
  - jabber.algebra20.de
  - jabber.co.za
  - jabber.dk
  - jabber.linux.by
  - jabber.nerdbase.de
  - jabber.olc.cz
  - jabber.org.by
  - jabber.perm.ru
  - jabber.westchat.de
  - jclub.pw
  - justnet.pl
  - kdetalk.net
  - km-net.pl
  - librenet.uy
  - librenet.uy
  - lih.im
  - onexp.dencom.nl
  - plum.pink
  - spiel-der-maechte.de
  - sweetway.info
  - ucc.asn.au
  - vsjmaxx.co
  - xjabber.org
  - xjabber.pro
  - yif.fi
- allow

s2s_default_policy: allow
s2s_access: s2s

2018-02-13 12:43:45 =ERROR REPORT
** State machine <0.561.0> terminating
** Last event in was {xmlstreamelement,{xmlel,<<"auth">>,[{<<"xmlns">>,<<"urn:ietf:params:xml:ns:xmpp-sasl">>},{<<"mechanism">>,<<"EXTERNAL">>}],[{xmlcdata,<<"amFiYmVyLmZzZmUub3Jn">>}]}}
** When State == wait_for_feature_request
**  Data  == {state,{socket_state,fast_tls,{tlssock,#Port<0.6841>,#Port<0.6842>},<0.560.0>},ejabberd_socket,<<"6193705401366314485">>,s2s_shaper,true,true,true,false,[compression_none,compression_none,{dhfile,<<"/etc/ejabberd/dh2048.pem">>},{protocol_options,<<"no_tlsv1_1|no_tlsv1|no_s

Bug#890380: polipo: ForbiddenFile not used for https requests

2018-02-14 Thread Emmanuel Hainry
Package: polipo
Version: 1.1.1-7
Severity: normal

Dear Maintainer,

I use /etc/polipo/forbidden to list domain names that I don't want to
ever query. This works for http requests but seems to be ignored when
requests go through https.

For example, I have a line forbidding domain "criteo.net" and

$ http_proxy=http://localhost:8123  curl http://criteo.net

As expected gives me a 403 Forbidden response

However

$ https_proxy=http://localhost:8123  curl https://static.criteo.net \
--output /tmp/x

Makes the query and downloads a 1x1 gif file.

(I have checked that https connections correctly go through polipo)


Best regards,
Emmanuel

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

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

Versions of packages polipo depends on:
ii  libc6 2.26-6
ii  lsb-base  9.20170808

Versions of packages polipo recommends:
pn  dnsmasq | pdnsd | unbound  
ii  python 2.7.14-4

polipo suggests no packages.

-- Configuration Files:
/etc/polipo/config changed:
logSyslog = true
logFile = /var/log/polipo/polipo.log
socksParentProxy = localhost:9050


-- no debconf information



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

2018-02-14 Thread Libor Klepáč
Hello,

On úterý 13. února 2018 16:40:03 CET Pirate Praveen wrote:
> 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.
> 

> 
> You may want to try like this
> https://salsa.debian.org/ruby-team/gitlab/blob/master/debian/rake-tasks.sh#L
> 39
yes, this is in rake-tasks and i'm running it manualy, my sequence of commands 
was (if i remember correctly):
#(only once)
# npm install
# npm install indexof
# npm install randomfill

#repeated after each try
# NODE_PATH=/usr/share/gitlab/node_modules webpack \ 
--config config webpack.config.js
# bundle exec rake tmp:cache:clear assets:precompile


> > 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).

No luck, there is no jquery-atwho available in npm.

But i have downloaded version 1.5.4 of At.js and replaced files in 
/usr/share/javascript/jquery-atwho
and one of errors disappeared.

> 
> > 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.
Huh, i can see, this is frustrating.

Libor



Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

2018-02-14 Thread Ghislain Vaillant
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-jsonrpc"

* Package name: python-jsonrpc
  Version : 1.10.8-1
  Upstream Author : Kirill Pavlov 
* URL : https://github.com/pavlov99/json-rpc
* License : Expat
  Section : python

It builds those binary packages:

  python-jsonrpc-doc - documentation for json-rpc
  python3-jsonrpc - Python implementation of JSON-RPC 1.0 and 2.0 (Python 3)

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

  https://mentors.debian.net/package/python-jsonrpc

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-jsonrpc/python-jsonrpc_1.10.8-1.dsc

Packaging repository:

  https://salsa.debian.org/python-team/modules/python-jsonrpc

Debomatic build:

  
http://debomatic-amd64.debian.net/distribution#unstable/python-jsonrpc/1.10.8-1

Changes since the last upload:

  * Initial release. (Closes: #879050)

Regards,
Ghislain Vaillant



Bug#890378: centrifuge: FTBFS on !x86 and FTBFS on i386

2018-02-14 Thread Adrian Bunk
Source: centrifuge
Version: 1.0.3~beta-1
Severity: serious

https://buildd.debian.org/status/package.php?p=centrifuge&suite=sid

-msse2 is:
- already enabled by default on amd64
- a baseline violation on i386
- not available on any other architectures (except x32)

Related to the resolution of this bug:
centrifuge/i386 unsatisfiable Depends: hisat2
centrifuge/i386 unsatisfiable Depends: jellyfish

Since the dependency hisat2 is amd64-only,
there is no point in trying to build centrifuge
on other architectures.



Bug#890375: gnome-tweaks: update changes touchpad right click behavior silently

2018-02-14 Thread Simon McVittie
Control: retitle 890375 gsettings-desktop-schemas: update changes touchpad 
right click behaviour silently
Control: reassign 890375 gsettings-desktop-schemas 3.27.90-1

On Wed, 14 Feb 2018 at 09:09:09 +0100, Andreas Hehn wrote:
> This setting is not present on the previous version of gnome-tweaks (3.27.4-1)
> (at least on my installation) and I highly suspect the update to 3.27.90-1
> changed the setting silently.

gnome-tweaks is just a user interface for manipulating settings, so I would
hope that it never changes something by itself. Everything that it can
configure is a (hidden) configuration option in either
gsettings-desktop-schemas (which contains settings and defaults for the
GNOME desktop as a whole) or the individual package that implements the
configurable behaviour (often gnome-shell or gnome-settings-daemon).

> Versions of packages gnome-tweaks depends on:
...
> ii  gsettings-desktop-schemas  3.27.90-1

This seems to be the package that caused the change. From its NEWS:

- Change default click method for touchpads, from Windows-style
  soft-button areas, to Mac-style two-finger right-click. This
  does not change the settings for trackpoints or touchpads that
  don't support multi-touch

(See also 

which suggests that the previous default was to use Mac-style two-finger
right-click on certain special-cased machines, presumably including Macs.)

Perhaps a NEWS.Debian entry would be appropriate? Or this seems like
something that should maybe go into the buster release notes if there's
a "new version of GNOME" section.

Regards,
smcv



Bug#890382: RFS: libbusiness-isin-perl/0.20-1 [ITP]

2018-02-14 Thread Laurent Baillet
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libbusiness-isin-perl"

 * Package name: libbusiness-isin-perl
   Version : 0.20-1
   Upstream Author : David Chan 
 * URL : https://metacpan.org/release/Business-ISIN
 * License : GPL-1+ or Artistic
   Section : perl

  It builds those binary packages:

libbusiness-isin-perl - validate International Securities
Identification Numbers

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

  https://mentors.debian.net/package/libbusiness-isin-perl


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

dget -x 
https://mentors.debian.net/debian/pool/main/libb/libbusiness-isin-perl/libbusiness-isin-perl_0.20-1.dsc

  More information about libbusiness-isin-perl can be obtained from
https://metacpan.org/changes/distribution/Business-ISIN.

I've been using this simple perl module in production since its
release more than 15 years ago and still works as expected according
to ISO 3166


  Regards,
   Laurent Baillet


Bug#890381: unattended-upgrades: Upgrades downloaded even when on metered (mobile) connection

2018-02-14 Thread Ralf Jung
Package: unattended-upgrades
Version: 0.98
Severity: normal

Dear Maintainer,

I just had roughly 20% of my monthly data volume (aka 100 MByte) used up within
minutes because this package decided to do `apt update` while I am connected via
Bluetooth and my mobile phone.  Lucky enough I noticed this while the update as
still going and before my data was completely used up.  I am not sure why the
download was so big, maybe it already started downloading the .deb files?

I did not even know that this package was installed; it came in via dependencies
and recommendations from Gnome.  The end-result us unacceptable behavior: Using
the Gnome desktop in the default configuration results in huge downloads being
performed over metered connections without any way for the user to know, let
alone abort the download.

Kind regards,
Ralf

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 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 unattended-upgrades depends on:
ii  apt1.6~alpha7
ii  apt-utils  1.6~alpha7
ii  debconf [debconf-2.0]  1.5.65
ii  init-system-helpers1.51
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  python33.6.4-1
ii  python3-apt1.4.0~beta3+b1
ii  ucf3.0036
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-24
ii  cron [cron-daemon]  3.0pl1-128.1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20160123cvs-4
pn  needrestart 
ii  postfix [mail-transport-agent]  3.2.5-1



Bug#890364: pybind11-dev: Request migration to unstable

2018-02-14 Thread Ghislain Vaillant
Hi Shane, thanks for reaching out,

On Wed, 14 Feb 2018 00:48:14 + Shane Loretz  wrote:
> Would the maintainer be willing to migrate 2.2.1 from experimental to
unstable? I'm a user of a distribution based on debian unstable. I have
been using pybind11 from pip previously. The package in experimental
appears to be working flawlessly for my usecase and has some nice new
features not in the version currently in unstable.

There are a few rdpends I have got to test first to guarantee a smooth
upgrade. But yes, I intend to migrate the new version to unstable soon.

Cheers,
Ghis



Bug#890383: ignition-common FTBFS on big endian: UNIT_Util_TEST (Failed)

2018-02-14 Thread Adrian Bunk
Source: ignition-common
Version: 1.0.1-1
Severity: important

https://buildd.debian.org/status/package.php?p=ignition-common&suite=sid

...

98% tests passed, 1 tests failed out of 59

Total Test time (real) =  10.32 sec

The following tests FAILED:
 49 - UNIT_Util_TEST (Failed)
Errors while running CTest
Makefile:143: recipe for target 'test' failed
make[2]: *** [test] Error 8



Bug#887216: rear should depend on e2fsprogs explicitly

2018-02-14 Thread Frédéric Bonnard
Hi Andreas and Helmut,
I crafted a new packaging for 2.3 upstream release one month ago and
came up to the same conclusion as Andreas, and if I remember correctly
I also confirmed this by testing without that dependency which led to
some issue.
Sorry for not detailing this here in the meantime, that would have save
you Andreas a bit of time, but I got hooked on other things and forgot.
I hope to release the new packaging soon.
Thanks,

F.

On Tue, 13 Feb 2018 18:29:59 +0100, Andreas Henriksson  wrote:
> On Sun, Jan 14, 2018 at 08:10:35PM +0100, Helmut Grohne wrote:
> > Package: rear
> [...]
> > /usr/share/rear/conf/GNU/Linux.conf contains e2fsck, fsck.ext2, fsck.ext3, 
> > fsck.ext4, mke2fs, mkfs.ext2, mkfs.ext3, mkfs.ext4 and tune2fs. According 
> > to file it is a ASCII text, with very long lines
> 
> The commands are listed in the PROGS variable, which also lists commands
> like ifconfig, etc. and their respective package is not listed in any
> relationship specified in the package. I'm thus assuming there's
> no need to explicitly list e2fsprogs either for this occurance.
> 
> 
> > /usr/share/rear/conf/examples/SLE12-SP1-btrfs-example.conf contains chattr 
> > and lsattr. According to file it is a ASCII text
> > /usr/share/rear/conf/examples/SLE12-SP2-btrfs-example.conf contains chattr 
> > and lsattr. According to file it is a ASCII text, with very long lines
> 
> Example files (for Suse?) are likely not important to consider.
> 
> > /usr/share/rear/format/USB/default/300_format_usb_disk.sh contains tune2fs. 
> > According to file it is a ASCII text
> > /usr/share/rear/format/USB/default/350_label_usb_disk.sh contains e2label. 
> > According to file it is a ASCII text
> 
> The above two executes the command and calls the Error function if
> failing.
> 
> > /usr/share/rear/layout/prepare/GNU/Linux/130_include_filesystem_code.sh 
> > contains tune2fs. According to file it is a ASCII text
> 
> The command is both used directly and written to a generate script.
> 
> > /usr/share/rear/layout/prepare/GNU/Linux/130_include_mount_subvolumes_code.sh
> >  contains chattr. According to file it is a ASCII text
> 
> The command is written to a generated script.
> 
> > /usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh contains 
> > chattr, e2label, lsattr and tune2fs. According to file it is a ASCII text
> 
> Commands are executed directly and there doesn't seem to be any real
> fault handling. The commands seems to be expected to be in place
> and work.
> 
> > /usr/share/rear/skel/default/etc/fstab contains debugfs. According to file 
> > it is a ASCII text
> [...]
> 
> This mostly seem to be an example of mounting debugfs filesystem. Not
> using the debugfs command.
> 
> My conclusion is based on the above that e2fsprogs should indeed
> be a dependency.
> 
> Would be great to hear maintainers view on this!
> 
> Regards,
> Andreas Henriksson
> 


pgpPSIhqZIezK.pgp
Description: PGP signature


Bug#888495: check_haproxy_stats: Please change default location admin sock

2018-02-14 Thread Jean-Michel Vourgère
Control: tags -1 +patch

Trivial patch attached
Description: Change haproxy default socket to match debian haproxy
 haproxy enables admin socket at /var/run/haproxy/admin.sock by default since 1.5~dev24-2.
 .
 This fixes the default location to work out of the box.
Bug-Debian: https://bugs.debian.org/888495
Forwarded: not-needed
Author: Jean-Michel Vourgère 
Last-Update: 2018-02-14

--- a/check_haproxy_stats/check_haproxy_stats.pl
+++ b/check_haproxy_stats/check_haproxy_stats.pl
@@ -57,7 +57,7 @@
 in list.
 
 -s, --sock, --socket
-Use named UNIX socket instead of default (/var/run/haproxy.sock)
+Use named UNIX socket instead of default (/var/run/haproxy/admin.sock)
 
 -w, --warning
 Set warning threshold for sessions number to the specified percentage (see -c)
@@ -114,7 +114,7 @@
 # Defaults
 my $swarn = 80.0;
 my $scrit = 90.0;
-my $sock  = "/var/run/haproxy.sock";
+my $sock  = "/var/run/haproxy/admin.sock";
 my $dump;
 my $proxy;
 my $help;


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


Bug#890385: seqan2: fix the build on mips/mipsel

2018-02-14 Thread Adrian Bunk
Source: seqan2
Version: 2.4.0+dfsg-5
Severity: wishlist
Tags: patch

seqan2 with the change below builds for me on minkus.

The contents is a partial revert back to 2.4.0+dfsg-3
plus adding -g1 on mips/mipsel to fix the virtual
memory exhaustion.

--- debian/control.old  2018-02-12 10:23:26.913006985 +
+++ debian/control  2018-02-12 10:24:47.173002461 +
@@ -27,8 +27,7 @@
 Rules-Requires-Root: no
 
 Package: seqan-apps
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x 
alpha hppa ia64 m68k powerpc powerpcspe ppc64 sh4 sparc64 x32
-# Skipping mips & mipsel due to lack of memory
+Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: C++ library for the analysis of biological sequences
--- debian/rules.old2018-02-12 10:23:20.209674029 +
+++ debian/rules2018-02-12 10:42:30.956275835 +
@@ -21,14 +21,13 @@
 endif
 
 ifneq (,$(filter mips mipsel mips64el,$(DEB_BUILD_ARCH)))
-DEB_CXXFLAGS_MAINT_APPEND+=-mxgot -O2
-export DEB_CFLAGS_MAINT_APPEND+=-O2
-else
-DEB_CXXFLAGS_MAINT_APPEND+=-O3
-export DEB_CFLAGS_MAINT_APPEND+=-O3
+DEB_CXXFLAGS_MAINT_APPEND+=-mxgot
+endif
+
+ifneq (,$(filter mips mipsel,$(DEB_BUILD_ARCH)))
+DEB_CXXFLAGS_MAINT_APPEND+=-g1
+DEB_CFLAGS_MAINT_APPEND+=-g1
 endif
-# As per upstream's instructions
-DEB_CXXFLAGS_MAINT_APPEND+=-DNDEBUG
 
 MAX_PARALLEL=""
 # Disable or limit parallel building on some build archs to save memory
@@ -44,7 +43,10 @@
 # DEB_CXXFLAGS_MAINT_APPEND+=-DSEQAN_ASYNC_IO=0
 # endif
 
-export DEB_CXXFLAGS_MAINT_APPEND
+# As per upstream's instructions
+DEB_CXXFLAGS_MAINT_APPEND+=-DNDEBUG -O3
+export DEB_CFLAGS_MAINT_APPEND+=-O3
+export DEB_CXXFLAGS_MAINT_APPEND DEB_CFLAGS_MAINT_APPEND
 
 pkgapps=seqan-apps
 pkgdev=libseqan2-dev



Bug#890384: ignition-math4: baseline violation on amd64

2018-02-14 Thread Adrian Bunk
Source: ignition-math4
Version: 4.0.0+dfsg1-1
Severity: serious

https://sources.debian.org/src/ignition-math4/4.0.0+dfsg1-1/debian/rules/#L10

ifeq ($(DEB_HOST_ARCH),amd64)
SSE_FLAGS = -mfpmath=sse -msse -msse2 -msse3 -mssse3 -DSSE
endif

SSE3 and SSSE3 are not part of the amd64 baseline.

"-mfpmath=sse -msse -msse2" are already enabled
by default on amd64, no need to do that manually.

The SSE define does not seem to be used anywhere in the code.



Bug#890387: python-jpype FTBFS: ImportError: No module named setuptools

2018-02-14 Thread Adrian Bunk
Source: python-jpype
Version: 0.6.2+dfsg-1
Severity: serious

https://buildd.debian.org/status/package.php?p=python-jpype&suite=sid

...
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py clean 
Traceback (most recent call last):
  File "setup.py", line 10, in 
from setuptools import setup
ImportError: No module named setuptools
E: pybuild pybuild:283: clean: plugin distutils failed with: exit code=1: 
python2.7 setup.py clean 
dh_auto_clean: pybuild --clean -i python{version} -p 2.7 returned exit code 13
debian/rules:9: recipe for target 'clean' failed
make: *** [clean] Error 25



Bug#890386: squashfs-tools: Add default value of -Xdict-size to man page

2018-02-14 Thread Dryden Personalis
Source: squashfs-tools
Severity: minor

Being generally somewhat confused by the wording in the man page regarding the 
default value of
-Xdict-size to XZ, I would like to suggest an edit to include this information.

Please change the wording according to your wishes, but this is the most 
pleasant way of wording
it that I could come up with.

As per xz_wrapper.c:

/* No -Xdict-size specified, use defaults */
dictionary_size = block_size;

The reader might be confused whether using this option would do any good (as 
some have been) but
effectively you cannot improve over the default option; this could also be 
explicitly stated.

Best wishes,

Dryden
--- mksquashfs.1.old2013-05-09 22:22:49.0 +0200
+++ mksquashfs.12018-02-14 09:52:13.2 +0100
@@ -113 +113 @@
-Use \fIDICT_SIZE\fR as the XZ dictionary size. The dictionary size can be 
specified as a percentage of the block size, or as an absolute value. The 
dictionary size must be less than or equal to the block size and 8192 bytes or 
larger. It must also be storable in the xz header as either 2^n or as 
2^n+2^(n+1). Example dict\-sizes are 75%, 50%, 37.5%, 25%, or 32K, 16K, 8K etc.
+Use \fIDICT_SIZE\fR as the XZ dictionary size. The dictionary size can be 
specified as a percentage of the block size, or as an absolute value. The 
default size is 100% of the block size. The size must be less than or equal to 
the block size and 8192 bytes or larger. It must also be storable in the xz 
header as either 2^n or as 2^n+2^(n+1). Example dict\-sizes are 75%, 50%, 
37.5%, 25%, or 32K, 16K, 8K etc. The default is 100%.


Bug#890377: [ejabberd] server2server works only if no deny section given

2018-02-14 Thread Philipp Huebner
Hi,

which documentation were you consulting?
http://docs.ejabberd.im/ refers to the latest release (currently 18.01),
so would not exactly match 16.09 from Debian Stretch.

You can find a working example here:
https://github.com/debalance/ansible-playbook-jabber.rwth-aachen.de/blob/master/files/ejabberd/ejabberd.yml

BTW: in case you would like to run 18.01, it's available via
stretch-backports.

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature


Bug#890388: squashfs-tools: Add default value of -Xblock-size to man page

2018-02-14 Thread Dryden Personalis (me)
Source: squashfs-tools
Version: 1:4.2+20130409-2
Severity: minor

Dear Maintainer,

Being generally somewhat confused by the wording in the man page regarding the 
default value of -Xdict-size to XZ, I would like to suggest an edit to include 
this information.

Please change the wording according to your wishes, but this is the most 
pleasant way of wording it that I could come up with.

As per xz_wrapper.c:

/* No -Xdict-size specified, use defaults */
dictionary_size = block_size;

The reader might be confused whether using this option would do any good (as 
some have been) but effectively you cannot improve over the default option; 
this could also be explicitly stated.

Best wishes,

Dryden
--- mksquashfs.1.old2013-05-09 22:22:49.0 +0200
+++ mksquashfs.12018-02-14 09:52:13.2 +0100
@@ -113 +113 @@
-Use \fIDICT_SIZE\fR as the XZ dictionary size. The dictionary size can be 
specified as a percentage of the block size, or as an absolute value. The 
dictionary size must be less than or equal to the block size and 8192 bytes or 
larger. It must also be storable in the xz header as either 2^n or as 
2^n+2^(n+1). Example dict\-sizes are 75%, 50%, 37.5%, 25%, or 32K, 16K, 8K etc.
+Use \fIDICT_SIZE\fR as the XZ dictionary size. The dictionary size can be 
specified as a percentage of the block size, or as an absolute value. The 
default size is 100% of the block size. The size must be less than or equal to 
the block size and 8192 bytes or larger. It must also be storable in the xz 
header as either 2^n or as 2^n+2^(n+1). Example dict\-sizes are 75%, 50%, 
37.5%, 25%, or 32K, 16K, 8K etc. The default is 100%.


Bug#890389: network-manager: fail to connect to internet using android wifi tethering

2018-02-14 Thread lahirdenganselamat
Package: network-manager
Version: 1.10.4-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I think last update of network-manager from last week. KDE network widget says 
that I'm connected to my phone AP, but I cannot use internet from it. USB 
tethering still work fine, other wifi AP (but phone) works fine
KDE connect also cannot detect the phone (despite being the same network)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I try using different phone (mine's Xiaomi) to tether (samsung, LG) none works, 
using public wifi AP, works just fine.
I try using other linux on other partition (Kubuntu 14.04) and wifi tethering 
still works there

Thank you for your attention.


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

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)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser3.117
ii  dbus   1.12.4-1
ii  libaudit1  1:2.8.2-1
ii  libbluetooth3  5.47-1+b1
ii  libc6  2.26-6
ii  libcurl3-gnutls7.58.0-2
ii  libglib2.0-0   2.54.3-2
ii  libgnutls303.5.17-1
ii  libjansson42.10-1
ii  libmm-glib01.6.8-2
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-2
ii  libnl-3-2003.2.27-2
ii  libnm0 1.10.4-1
ii  libpam-systemd 236-3
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libpsl50.19.1-4
ii  libreadline7   7.0-3
ii  libselinux12.7-2+b1
ii  libsystemd0236-3
ii  libteamdctl0   1.26-1+b1
ii  libudev1   236-3
ii  libuuid1   2.30.2-0.3
ii  lsb-base   9.20170808
ii  policykit-10.105-18
ii  udev   236-3
ii  wpasupplicant  2:2.6-15

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.78-3
ii  iptables 1.6.2-1
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3+b2
ii  modemmanager 1.6.8-2
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information



Bug#878867: cups-filters: unreadable file /usr/lib/cups/backend/cups-brf

2018-02-14 Thread Άλκης Γεωργόπουλος

I too got affected by this. To verify my system integrity, I ran
debsums -s

...and /usr/lib/cups/backend/cups-brf was not readable so it was not 
verifiable, without requiring root.


It actually attracts attention, "I can easily download that file, so why 
is it not readable, what are they trying to protect, how can I exploit it?"




Bug#890390: /usr/bin/chattr: chattr manpage minor bugs on attributes

2018-02-14 Thread Witold Baryluk
Package: e2fsprogs
Version: 1.43.9-1
Severity: minor
File: /usr/bin/chattr

"""
   The following attributes are read-only, and may be listed by lsattr(1) 
but not modified by chattr: compression error (E), huge  file  (h),  indexed  
directory  (I),
   inline data (N), compression raw access (X), and compressed dirty file 
(Z).
"""

No. E is not "compression error". It means "file system level encrypted file".


"""
   A file with the 'i' attribute cannot be modified: it cannot be deleted 
or renamed, no link can be created to this file and no data can be written to 
the file.  Only
   the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability 
can set or clear this attribute.
"""

what about other metadata: owner, group, unix permissions, posix acls,
xattrs, modification date, "normal" attributes itself, access time?

It would also be good to explain why normal user cannot set or unset this
attribute on file that they own. (I have some ideas why, but it is
tricky).


"""
   The 'c', 's',  and 'u' attributes are not honored by the ext2, ext3, and 
ext4 filesystems as implemented in the current mainline Linux kernels.
"""

It would be much better to instead list which file systems DO HONOR it, and 
since which Linux kernel version.

"""
   The 'j' option is only useful if the filesystem is mounted as ext3 or 
ext4.
"""

the word "as" is not clear here (what if I mount ext2 as ext4?). I guess
it would be better to just say "only useful for ext3 and ext4
filesystems". (it might also be useful to mention or point to ext2
feature flags and/or mount options and/or tune2fs, that are required to
be enabled).



Regards,
Witold Baryluk


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

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

Versions of packages e2fsprogs depends on:
ii  libblkid12.31.1-0.1
ii  libc62.26-6
ii  libcom-err2  1.43.9-1
ii  libext2fs2   1.43.9-1
ii  libss2   1.43.9-1
ii  libuuid1 2.31.1-0.1

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.43.9-1

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
ii  fuse2fs1.43.9-1
pn  gpart  
ii  parted 3.2-20

-- no debconf information



Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

2018-02-14 Thread Pirate Praveen
Package: libjs-jquery-atwho
Version: 1.5.3+dfsg.1-1
Severity: grave
Justification: makes the package unuseable
Control: block 890333 by -1

Originally reported with full error log at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890333 and I was able
to reproduce it in my system.

gulp is now packaged, so may be its a good idea to use the upstream
build system (so its easier to support the package than learning a
custom build script). Also if it were part of javascript packaging team
repos, I could have helped directly.



signature.asc
Description: OpenPGP digital signature


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

2018-02-14 Thread KAction

> > [2018-02-12 13:07] Sean Whitton 
> >> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe,
> >> > you could try again?
> >>
> >> Still FTBFSs.  Log attached.
> >>
> >> I suspect that the debomatic sid chroot is out-of-date.
> >
> > Stange. Just did 'sbuild-update -udcar', and still fails to reproduce.
> > I have same version of build-essential, by the way.
> >
> > Added debomatic admin into CC, maybe he has any opinion about
> > situation.  If not, I could remove sanitize support, although I am not
> > so happy with it. Or maybe you could tar.gz your chroot and upload
> > somewhere?
> 
> I tried deleting and rebuilding my chroot and disabling ccache and
> tmpfs, and I tried building on my i386 machine, again after rebuilding,
> disabling ccache and disabling tmpfs.
> 
> In all cases the package FTBFS.  I attach my i386 log..
> 
> I'm not sure how to proceed.  I can't upload this if I can't build it,
> and my configuration seems sufficiently standard that even if you are
> able to build it, we shouldn't upload.  Maybe we should try disabling
> sanitize support for now.

I understand your concerns, Sean. I invited Gianfranco into thread,
maybe he would sponspor instead.  Ah, another absurd idea. What about
your building package on debomatic? Maybe for some reason your source
package, generated from git repository, differs from mine? Also, could
you please try to run binaries, built by debomatic? Do they crash?

Hello! Gianfranco, could you please consider building and, probably,
sponsoring this package? We have issue, that it FTBFS on Sean's setup,
but builds on mine and on debomatic. As debomatic admin notified,
debomatic is not out-of-date {updated this sunday}.

https://salsa.debian.org/iu-guest/inotify-tools



Bug#780005: mate-terminal: reset option does not reset colors to defaults

2018-02-14 Thread Mike Gabriel

Hi Brian,

On  So 08 Mär 2015 01:00:36 CET, brian m. carlson wrote:


Package: mate-terminal
Version: 1.8.1+dfsg1-4
Severity: normal

If the terminal color mapping has been changed by a terminal  
sequence, neither Terminal → Reset nor Terminal → Reset and Clear  
restores the colors to the defaults.


To demonstrate this, run the attached script as "color-bug-test  
--no-change".  Notice that color 1 is a dark red (at least by  
default). Now run the script as "color-bug-test".  Color 1 is now a  
light blue. No matter what you do, color 1 will remain a light blue  
unless you change it again with an escape sequence.  You'll have to  
open a new terminal tab to get the original colors again.


I discovered this when I logged into someone else's VM at work and  
their shell setup changed the red in my terminal to magenta.  I then  
had to close the terminal tab and open a new one to get my colors  
back.


there has been some work done regarding color palette initialization.

Please check the above with upcoming mate-terminal 1.20.0-1 and report  
back if the issue persists for you.


Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp3F452cmeH9.pgp
Description: Digitale PGP-Signatur


Bug#890392: please add file in /etc/chromium.d to load extensions

2018-02-14 Thread Michael Meskes
Package: chromium
Version: 64.0.3282.119-2
Severity: wishlist

With more and more extensions being packaged it would be nice to have chromium
load them automatically instead of requiring user action. And the chromium
package seems to be the natural place for this.

It appears to me that it's sufficient to add the attached file to 
/etc/chromium.d.

Thanks

Michael

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

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

Versions of packages chromium depends on:
ii  chromium-common  64.0.3282.119-2
ii  libasound2   1.1.3-5
ii  libatk-bridge2.0-0   2.26.1-1
ii  libatk1.0-0  2.26.1-3
ii  libavcodec57 10:3.4.2-dmo1
ii  libavformat5710:3.4.2-dmo1
ii  libavutil55  10:3.4.2-dmo1
ii  libc62.26-6
ii  libcairo21.15.10-1
ii  libcups2 2.2.6-5
ii  libdbus-1-3  1.12.4-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.5-3
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8-20180207-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-2
ii  libgtk-3-0   3.22.26-2
ii  libharfbuzz0b1.7.2-1
ii  libicu57 57.1-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.18-1
ii  libnss3  2:3.35-2
ii  libopus0 1.2.1-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpng16-16  1.6.34-1
ii  libpulse011.1-4
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8-20180207-2
ii  libvpx4  1.6.1-3
ii  libwebp6 0.6.0-4
ii  libwebpdemux20.6.0-4
ii  libwebpmux3  0.6.0-4
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-6.1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-5
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-5

Versions of packages chromium suggests:
pn  chromium-driver
ii  chromium-l10n  64.0.3282.119-2
pn  chromium-shell 
pn  chromium-widevine  

-- Configuration Files:
/etc/chromium.d/extensions changed [not included]

-- no debconf information
export CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --load-extension=`ls -dm 
/usr/share/chromium/extensions/*|tr -d '\n'`"



Bug#869337: mate-terminal: all mate terminals crashed unexpectedly

2018-02-14 Thread Mike Gabriel

Control: tags -1 moreinfo

Hi,

On  Sa 22 Jul 2017 16:47:20 CEST, treaki wrote:


Package: mate-terminal
Version: 1.8.1+dfsg1-4
Severity: important

Dear Maintainer,

   * What led up to the situation?
My system is running as always uptime
16:37:39 up 11 days,  5:10, 12 users,  load average: 0.42, 0.82, 1.25
with a huge amount of terminals opened as always, but suddenly,  
without a terminal in the foreground they all where gone (and  
thereby also the application in the foreground and all other  
applications running in terminal which broke a bunch of  
processes/transfers/etc like a half system crash)

* What exactly did you do (or not do) that was effective (or
ineffective)?
nothing within the terminal
* What was the outcome of this action?
a lot was gone but others where still running (that i didn't started  
inside mate-terminals) and i was first wondering what the hell has  
happened because this was the first and hopefully last time that  
such an essential application like the terminal emulator crashes  
without a given reason.

* What outcome did you expect instead?
that everything else but the terminal emulator would crash

here are the last lines of my .xsession-errors, i hope they can help  
you. ive got no way to reproduce the problem because i dont know the  
reason, maybe someone got an idea on that...


Window manager warning: No rect to clip to found!
Window manager warning: No rect to clip to found!
Window manager warning: No rect to clip to found!
Window manager warning: No rect to clip to found!
Window manager warning: No rect to shove into found!
Window manager warning: No rect to shove into found!
Window manager warning: No rect to shove into found!
Window manager warning: No rect to shove into found!
Window manager warning: No rect to shove into found!
Window manager warning: Log level 8: Source ID 78861 was not found  
when attempting to remove it

The program 'mate-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 5265511 error_code 9 request_code 139 minor_code 4)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Window manager warning: Log level 8: Source ID 79953 was not found  
when attempting to remove it
Window manager warning: Log level 8: Source ID 80291 was not found  
when attempting to remove it
Window manager warning: Log level 8: Source ID 80295 was not found  
when attempting to remove it


(caja:1769): GLib-GObject-WARNING **:  
/build/glib2.0-y6934K/glib2.0-2.42.1/./gobject/gsignal.c:2579:  
instance '0x59d2c70' has no handler with id '623505'


(caja:1769): GLib-GObject-WARNING **:  
/build/glib2.0-y6934K/glib2.0-2.42.1/./gobject/gsignal.c:2579:  
instance '0x24024a0' has no handler with id '613558'


nothing relevant in dmesg/Xorg.0.log ant thats all i could think of  
to be relevent. Maybe someone can give me some advices what to do to  
get more debug output on such errors.


thanks a lot in advance


I assume this issue is hard to reproduce. Upstream solved an issue  
with segfaulting mate-terminal during handling DBus method calls.


I will not mark this bug as resolved. Rather, I'd be happy, if you  
could re-test the above with upcoming mate-terminal 1.20.0-1 (or  
newer) and report back after some time, if you have seen this issue  
once more.


If we don't hear back from you within the next coupld of months on  
this, I will close this bug report and consider it resolved by 1.20.0-1.


Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpRxDUtn6rPU.pgp
Description: Digitale PGP-Signatur


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

2018-02-14 Thread Raphael Hertzog
On Tue, 13 Feb 2018, Julien Cristau wrote:
> 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.

Granted, but RC bugs against dpkg does not translate into "break user
systems". I would be very surprised if we found out a tool using dpkg
--search that would break the system on which it is running because
it did not get an answer to a specific dpkg --search query.

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#883573: Call for vote on waiving libpam-systemd dependencies' ordering

2018-02-14 Thread David Bremner
Didier 'OdyX' Raboud  writes:

> === Resolution ===
>
> In 2014, it was resolved in #746578 that the libpam-systemd binary package 
> alternative dependency on systemd-shim and systemd-sysv shall be set in that 
> order, in order to avoid unwanted init system changes accross upgrades. 
> Debian 
> Stretch has since been released.
>
> The Committee therefore resolves that:
>
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.
>
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering 
> constraints.  The migration should be managed according to Debian's usual 
> backwards-compatibility arrangements.
>
> === End Resolution ===
>
> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion

I vote R > F


signature.asc
Description: PGP signature


Bug#890393: linux-image-4.9.0-3-amd64: backport of the megaraid_sas driver for Debian stable

2018-02-14 Thread Vincent Danjean
Package: src:linux
Version: 4.9.30-2+deb9u5
Severity: normal

  Hi,

  Debian Stretch comes with a old version of megaraid_sas (v6.x) which does not 
support
the last raid controller from DELL (e.g. H740p). We known several workarounds:
- using the kernel from backports
- using the dkms driver provided by DELL
- manually recompile our own kernel (as a Debian package or not)

  however, we have a cluster of such machines where users are able to 
deploy/install
their own environment (including the OS). Being able to use the plain Debian 
stable
on this hardware would be great.
  Do you know if a backport of the megaraid_sas driver in the 4.9 kernel
can be expected?

  Regards,
Vincent

PS: I removed the generated kernel info as my current machine is irrelevant for 
this bug.



Bug#887659: RFS: urlwatch/2.7-1 [ITA]

2018-02-14 Thread Maxime Werlen
Thanks, I'll look into it.

Le 13 févr. 2018 06:03, "Paul Wise"  a écrit :

> On Fri, 2018-02-09 at 07:29 +0100, Maxime Werlen wrote:
>
> > Thanks for your time reviewing my packages.
>
> Thanks for adopting urlwatch!
>
> > I've tried to fix as much issues as I'm capable.
>
> There is only the blocker of ftp-masters accepting minidb now.
>
> It would be nice to fix these extra issues at some point:
>
> Upstream released 2.8 on 2018-01-28.
>
> The upstream thpinfo.com website has a broken TLS certificate:
>
> The certificate is only valid for thp.io
> The certificate expired on 22/03/17 04:52.
>
> I would suggest switching Debian copyright/control to thp.io
> and or contacting upstream about fixing their TLS certificate.
>
> I would suggest wrapping debian/watch between the URL and regex.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>


Bug#890394: please package latest crash 7.2.1

2018-02-14 Thread Thadeu Lima de Souza Cascardo
Package: crash
Version: 7.2.0-1
Severity: important

Latest kernel versions require such a crash version to analyze them.
Please, update it.

If you would like me to do the work and upload it, either as an NMU or
as a new co-maintainer (Uploader), let me know.

Thank you very much.
Cascardo.

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

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

Versions of packages crash depends on:
ii  binutils  2.30-4
ii  libc6 2.26-6
ii  liblzo2-2 2.08-1.2+b2
ii  libncurses5   6.0+20171125-1
ii  libsnappy1v5  1.1.7-1
ii  libtinfo5 6.0+20171125-1
ii  zlib1g1:1.2.8.dfsg-5

crash recommends no packages.

Versions of packages crash suggests:
ii  kexec-tools   1:2.0.15-1
ii  makedumpfile  1:1.6.3-1

-- no debconf information



Bug#890395: uglifyjs: Please update the package to new version v3.3.10

2018-02-14 Thread W. Martin Borgert

Source: uglifyjs
Version: 2.8.29-3
Severity: wishlist

v3.3.10 has been released on 2018-02-08.
Please consider updating the Debian package.
Thanks!



Bug#843951: [node-async] Please update to version 1.5.2

2018-02-14 Thread W. Martin Borgert

Meanwhile v2.6.0 has been released on 2017-11-07.
Please consider updating the Debian package.
Thanks!



Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

2018-02-14 Thread W. Martin Borgert

Dear Robin,

did the discussion about coffeescript vs ECMA6 already lead to something?

In any case, I suggest mass-file RFPs/ITPs for all needed node packages.
Then package as many as you feel like. Maybe others will help, let's see.
I cannot promise any help, because I'm already busy with other tasks.

I recommend to package all node libraries under the umbrella of the
Debian Javascript Maintainers 
They have their git repo here: https://salsa.debian.org/js-team

Thanks for caring! Cheers



Bug#890396: torch3 FTCBFS: builds for the build architecture

2018-02-14 Thread Helmut Grohne
Source: torch3
Version: 3.1-2.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

torch3 fails to cross build from source, because it builds for the build
architecture. The packaging fails to pass a cross compiler to make. The
easiest way to fix that is using dh_auto_build. The upstream build
system is dependent on the kernel and detects it from uname. Thus we
need to pass OS into the build. The attached patch fixes both aspects.
Please consider applying it.

Helmut
diff -u torch3-3.1/debian/changelog torch3-3.1/debian/changelog
--- torch3-3.1/debian/changelog
+++ torch3-3.1/debian/changelog
@@ -1,3 +1,12 @@
+torch3 (3.1-2.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS:
++ Let dh_auto_build pass cross compilers to make.
++ Pass OS to make.
+
+ -- Helmut Grohne   Wed, 14 Feb 2018 12:28:11 +0100
+
 torch3 (3.1-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u torch3-3.1/debian/rules torch3-3.1/debian/rules
--- torch3-3.1/debian/rules
+++ torch3-3.1/debian/rules
@@ -5,6 +5,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+include /usr/share/dpkg/architecture.mk
 
 CFLAGS = -Wall -g
 
@@ -17,6 +18,11 @@
INSTALL_PROGRAM += -s
 endif
 
+OSMAP_linux = Linux
+OSMAP_kfreebsd = GNU_kFreeBSD
+OSMAP_hurd = GNU
+OS=$(OSMAP_$(DEB_HOST_ARCH_OS))
+
 package=libtorch3c2
 devpackage=libtorch3-dev
 
@@ -49,8 +55,8 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) depend PACKAGES="$(PACKAGES)"
-   $(MAKE) PACKAGES="$(PACKAGES)" 
+   dh_auto_build -- depend PACKAGES="$(PACKAGES)" OS="$(OS)"
+   dh_auto_build PACKAGES="$(PACKAGES)"
#LIBTORCH="$(CURDIR)/lib/libtorch.a"
 
touch build-stamp


Bug#890397: python3-aiohttp: Can't use new yarl version

2018-02-14 Thread Salvo Tomaselli
Package: python3-aiohttp
Version: 2.3.6-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The new version of python3-yarl present in the archive
makes this package completely unusable.

I have opened a bug against yarl as well, but probably the most effective fix
is to patch it here.

Best

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

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) (ignored: LC_ALL 
set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to 
it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-aiohttp depends on:
ii  libc6  2.26-6
ii  python33.6.4-1
ii  python3-async-timeout  2.0.0-1
ii  python3-chardet3.0.4-1
ii  python3-multidict  4.1.0-1
ii  python3-yarl   1.1.0-1

python3-aiohttp recommends no packages.

python3-aiohttp suggests no packages.

-- no debconf information



Bug#886124: python3-distutils, python3-lib2to3: installed files not cleaned up on removal

2018-02-14 Thread Simon McVittie
Control: tags -1 + patch

On Tue, 02 Jan 2018 at 15:07:52 +, Simon McVittie wrote:
> Expected result: all installed files are cleaned up by the time the
> Python packages have been purged
> 
> Actual result:
>   /usr/lib/python3.6/distutils/owned by: python3-distutils

Please consider applying the attached patch. I assumed you're deliberately
not using dh_python3 (to avoid a circular dependency or some reason like
that?) and NIH'd it, but if switching to dh_python3 would be acceptable
and straightforward, that would probably also be a good solution.

(It would also be great if you could mention in d/README.source why this
package isn't using dh_python3, so that future contributors don't have
to guess.)

Thanks,
smcv
>From ba7b5d7282ae7cb27d34801dc21411096d2493e2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 14 Feb 2018 11:30:12 +
Subject: [PATCH] Clean up empty __pycache__ directories in prerm

I implemented this the same way as dh_python3's fallback mode when
py3clean isn't found.

Closes: #886124
---
 debian/changelog   | 9 +
 debian/python3-distutils.prerm | 1 +
 debian/python3-lib2to3.prerm   | 1 +
 debian/python3-tk.prerm| 1 +
 4 files changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index b7635f8..f5ec622 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+python3-stdlib-extensions (3.6.4-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Clean up empty __pycache__ directories in prerm, the same way as
+dh_python3's fallback mode when py3clean isn't found
+(Closes: #886124)
+
+ -- Simon McVittie   Wed, 14 Feb 2018 10:58:21 +
+
 python3-stdlib-extensions (3.6.4-4) unstable; urgency=medium
 
   * Update to 20180212 from the 3.6 branch.
diff --git a/debian/python3-distutils.prerm b/debian/python3-distutils.prerm
index bdc8320..0c680e2 100644
--- a/debian/python3-distutils.prerm
+++ b/debian/python3-distutils.prerm
@@ -10,6 +10,7 @@ remove_bytecode()
 	| awk -F/ 'BEGIN {OFS="/"} /\.py$/ {$NF=sprintf("__pycache__/%s.*.py[co]", substr($NF,1,length($NF)-3)); print}' \
 	| xargs --max-chars="$max" echo \
 	| while read files; do rm -f $files; done
+find /usr/lib/python3.? -type d -name __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir
 }
 
 case "$1" in
diff --git a/debian/python3-lib2to3.prerm b/debian/python3-lib2to3.prerm
index a70657c..6dc4dbc 100644
--- a/debian/python3-lib2to3.prerm
+++ b/debian/python3-lib2to3.prerm
@@ -10,6 +10,7 @@ remove_bytecode()
 	| awk -F/ 'BEGIN {OFS="/"} /\.py$/ {$NF=sprintf("__pycache__/%s.*.py[co]", substr($NF,1,length($NF)-3)); print}' \
 	| xargs --max-chars="$max" echo \
 	| while read files; do rm -f $files; done
+find /usr/lib/python3.? -type d -name __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir
 }
 
 case "$1" in
diff --git a/debian/python3-tk.prerm b/debian/python3-tk.prerm
index 92ae334..ad6619b 100644
--- a/debian/python3-tk.prerm
+++ b/debian/python3-tk.prerm
@@ -10,6 +10,7 @@ remove_bytecode()
 	| awk -F/ 'BEGIN {OFS="/"} /\.py$/ {$NF=sprintf("__pycache__/%s.*.py[co]", substr($NF,1,length($NF)-3)); print}' \
 	| xargs --max-chars="$max" echo \
 	| while read files; do rm -f $files; done
+find /usr/lib/python3.? -type d -name __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir
 }
 
 case "$1" in
-- 
2.16.1



Bug#890398: python3-yarl: API has breaking changes

2018-02-14 Thread Salvo Tomaselli
Package: python3-yarl
Version: 1.1.0-1
Severity: important

Dear Maintainer,

this package introduces breaking API changes, causing python3-aiohttp to
stop working.

In [6]: from aiohttp import web, web_request
   ...: 
---
ImportError   Traceback (most recent call last)
 in ()
> 1 from aiohttp import web, web_request

/usr/lib/python3/dist-packages/aiohttp/web.py in ()
 13 from yarl import URL
 14 
---> 15 from . import (hdrs, web_exceptions, web_fileresponse, web_middlewares,
 16web_protocol, web_request, web_response, web_server,
 17web_urldispatcher, web_ws)

/usr/lib/python3/dist-packages/aiohttp/web_middlewares.py in ()
  3 
  4 from aiohttp.web_exceptions import HTTPMovedPermanently
> 5 from aiohttp.web_urldispatcher import SystemRoute
  6 
  7 

/usr/lib/python3/dist-packages/aiohttp/web_urldispatcher.py in ()
 19 # use `URL(path).raw_path` instead of `quote(path)`
 20 # Escaping of the URLs need to be consitent with the escaping done by 
yarl
---> 21 from yarl import URL, unquote
 22 
 23 from . import hdrs, helpers

ImportError: cannot import name 'unquote'

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

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) (ignored: LC_ALL 
set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to 
it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-yarl depends on:
ii  libc6  2.26-6
ii  python33.6.4-1
ii  python3-idna   2.6-1
ii  python3-multidict  4.1.0-1

python3-yarl recommends no packages.

python3-yarl suggests no packages.

-- no debconf information



Bug#890399: gitlab: override.conf in /etc/systemd/system/gitlab-*.service.d is not overwriten

2018-02-14 Thread Libor Klepáč
Package: gitlab
Version: 9.5.4.+dfsg-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,
another problem. 
If admin creates for example:
/etc/systemd/system/gitlab-sidekiq.service.d/override.conf
by hand, changing properties other than User, then postinst script fails to 
update User property.
My file is
#[Service]
#Restart=always

so no User to change by sed inside postinst.

I don't know if some debian policy on naming such override files exists, but 
can you use for example
gitlab(-user).conf ? It is also parsed and included by systemd.

Also systemd doesn't like
EnvironmentFile=-/etc/default/gitlab
in /lib/systemd/system/gitlab-unicorn.service

service doesn't start because of
Feb 14 12:35:41 ms-gitlab systemd[1]: gitlab-unicorn.service: Ignoring invalid 
environment assignment 'for i in $(grep -v '#' /etc/gitlab/gitlab-debian.conf | 
cut -d=-f 1)': /etc/default/gitlab


Thanks,
Libor

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEPGZVVU37tFmB0TQv8O+MbsKfR44FAlqEIHwVHGxpYm9yLmts
ZXBhY0BiY29tLmN6AAoJEPDvjG7Cn0eOdhQQAJZ4dwoDavpwDz8m7+0JhbXyYOrz
CJYSC/Z9v5bQNvNqj771GXuWdwIxd3sAudwJShctYZWJA51d4gl9wPJ9WZf1FX70
kYrrsyWm48fyHv1BSsk4rbgbYGQ5Pc5yZx7L/ekbZohKf+2IR0fgg+nPxtJ5pxnG
g7/uIST+uQS3O66nRvkWccelnP/X0xIO/oiVAvCaI75Jj5YYx3ziyD9XyNx6NEoS
NwEy0QQdPvBfJvHq/qS30fDbtkMdP4YMi0mbqb32+FBq0yxt8MCKoYFWSBEqdPV+
VXyeFkMNXxJd6Z/lZoRDnVJXepmBdhowVDdj5a28EHrVra+8hCYiQO4/xurnEXPO
ACbFUFAgLOCC+9vyGe7fRZ2BpfeSmA/h1scPe9lXLE9WN2iyqlAmBO8RPLPTTcsd
VybEkzkb9RbpqFgrgbqfkBCcH7e+RAsySeJQiZA3XKcPG9VoefcqNq5rRSt5OxuI
0adii49pbRLjL493v73FdCC+6GnlDrdgi9XX6/jqwX6jg3ofwjXI5MCzWJ8jrdvW
94QX9qbs7NfY7EjBrKwrRnXzDRlMKAZENwCzoUYV8pR+FIRDOAiYCSdZT+48jdvQ
HPnCqSRNybeqMTTS1/yrMLZHtXDOtzP38nsVYFmsYZOQ5zMV7RGS84Pspf4aI6QV
DvgsPm8FpIEhPZ2e
=IcDF
-END PGP SIGNATURE-



Bug#890400: physamp: autopkgtest failure

2018-02-14 Thread Graham Inggs

Source: physamp
Version: 1.0.3-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

Since the upload of libbpp-core 2.3.2-1, physamp's autopkgtests have 
been failing [1] with the following error:


autopkgtest [03:46:54]: test run-unit-test: [---
bppalnoptim: symbol lookup error: bppalnoptim: undefined symbol: 
_ZN3bpp16ApplicationTools18getDoubleParameterERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt3mapIS6_S6_St4lessIS6_ESaISt4pairIS7_S6_EEEdS8_bi

autopkgtest [03:46:55]: test run-unit-test: ---]
autopkgtest [03:46:55]: test run-unit-test:  - - - - - - - - - - results 
- - - - - - - - - -

run-unit-testFAIL non-zero exit status 127


It looks like a symbol was dropped and a transition is needed.

Regards
Graham


[1] https://ci.debian.net/packages/p/physamp/unstable/amd64/



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

2018-02-14 Thread Pirate Praveen
On 02/14/2018 02:43 PM, Libor Klepáč wrote:
> No luck, there is no jquery-atwho available in npm.
> But i have downloaded version 1.5.4 of At.js and replaced files in 
> /usr/share/javascript/jquery-atwho
> and one of errors disappeared.
This is a bug in libjs-jquery-atwho and I have reported it (#890391) and
added a workaround for it in 9.5.4+dfsg-4.

You can try and install document-register-element@1.3.0 from npm (it is
now 1.7.2). Or we may have a problem with our webpack.config.js or one
of the webpack loaders.



signature.asc
Description: OpenPGP digital signature


Bug#887192: singularity-container should depend on e2fsprogs explicitly

2018-02-14 Thread Andreas Henriksson
Control: tags -1 + confirmed
Control: retitle -1 singularity-container should recommend e2fsprogs

Hello Afif,

Thanks alot for your feedback!

On Wed, Feb 14, 2018 at 01:43:42AM -0500, Afif Elghraoui wrote:
> I would say it should rather be a Recommends. The old default container
> image format was based on ext3. It's still supported, but it's just one
> of a few possible options.

If ext* is no longer the default, I agree that a recommends might be
more suitable.

> 
> If that's no problem to you, we can go ahead and make it happen.

Would be great if you could have this fixed ASAP. If you're busy
feel free to just ask for help with a non-maintainer upload in
the meantime and I'll make it happen.

Regards,
Andreas Henriksson



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread John Paul Adrian Glaubitz
Source: llvm-toolchain-4.0
Version: 1:4.0.1-10
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

In order to get the Rust compiler work on sparc64, we need another
LLVM patch which is currently being upstreamed [1] which fixes the
code generation on sparc64.

Without the patch, LLVM generates invalid code that binutils stumbles
over and crashes with an internal error [2]. With the patch merged,
LLVM is working properly and allows a full native build of the Rust
compiler on sparc64 :).

Since Rust upstream is currently still on LLVM 4.0, even for Rust
1.24, it would be nice to have the patch merged for the 4.0 version
as well as the 6.0 version of the llvm-toolchain package. Although
we are going to convince upstream to backport the patch for 6.0.

Thanks,
Adrian

> [1] https://reviews.llvm.org/D43271
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22832

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: [Sparc] Include __tls_get_addr in symbol table for TLS calls to it
 Global Dynamic and Local Dynamic call relocations only implicitly
 reference __tls_get_addr, but it still needs to be in the symbol table
 to be bound at link time otherwise it fails to link. For details, see
 https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
Author: James Clarke 
Last-Update: 2018-02-14

--- llvm-toolchain-4.0-4.0.1.orig/lib/Target/Sparc/MCTargetDesc/SparcMCExpr.cpp
+++ llvm-toolchain-4.0-4.0.1/lib/Target/Sparc/MCTargetDesc/SparcMCExpr.cpp
@@ -194,14 +194,30 @@ static void fixELFSymbolsInTLSFixupsImpl
 void SparcMCExpr::fixELFSymbolsInTLSFixups(MCAssembler &Asm) const {
   switch(getKind()) {
   default: return;
+  case VK_Sparc_TLS_GD_CALL:
+  case VK_Sparc_TLS_LDM_CALL: {
+// The corresponding relocations reference __tls_get_addr, as they call it,
+// but this is only implicit; there is no connection in the ELF file
+// between the relocation and the symbol, other than the specification for
+// the semantics of the relocations. However, the symbol must be included
+// in our symbol table despite the lack of references to it, since it needs
+// to be bound during linking for these relocations. For details see
+// https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
+MCSymbol *Symbol = Asm.getContext().getOrCreateSymbol("__tls_get_addr");
+Asm.registerSymbol(*Symbol);
+auto ELFSymbol = cast(Symbol);
+if (!ELFSymbol->isBindingSet()) {
+  ELFSymbol->setBinding(ELF::STB_GLOBAL);
+  ELFSymbol->setExternal(true);
+}
+LLVM_FALLTHROUGH;
+  }
   case VK_Sparc_TLS_GD_HI22:
   case VK_Sparc_TLS_GD_LO10:
   case VK_Sparc_TLS_GD_ADD:
-  case VK_Sparc_TLS_GD_CALL:
   case VK_Sparc_TLS_LDM_HI22:
   case VK_Sparc_TLS_LDM_LO10:
   case VK_Sparc_TLS_LDM_ADD:
-  case VK_Sparc_TLS_LDM_CALL:
   case VK_Sparc_TLS_LDO_HIX22:
   case VK_Sparc_TLS_LDO_LOX10:
   case VK_Sparc_TLS_LDO_ADD:


Bug#890402: cgminer FTCBFS: debian/rules runs the build architecture compiler

2018-02-14 Thread Helmut Grohne
Source: cgminer
Version: 4.9.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cgminer fails to cross build from source, because debian/rules runs the
build architecture compiler as a make default. Including dpkg's new
buildtools.mk fixes this as it takes care to place a cross compiler into
$(CC). Please consider applying the attached patch.

Helmut
diff --minimal -Nru cgminer-4.9.2/debian/changelog 
cgminer-4.9.2/debian/changelog
--- cgminer-4.9.2/debian/changelog  2015-06-25 17:26:18.0 +0200
+++ cgminer-4.9.2/debian/changelog  2018-02-14 13:09:23.0 +0100
@@ -1,3 +1,10 @@
+cgminer (4.9.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use dpkg's buildtooks.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Feb 2018 13:09:23 +0100
+
 cgminer (4.9.2-1) unstable; urgency=medium
 
   * New release
diff --minimal -Nru cgminer-4.9.2/debian/rules cgminer-4.9.2/debian/rules
--- cgminer-4.9.2/debian/rules  2015-06-25 17:19:30.0 +0200
+++ cgminer-4.9.2/debian/rules  2018-02-14 13:09:21.0 +0100
@@ -4,6 +4,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+-include /usr/share/dpkg/buildtools.mk
+
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
 #Below list is taken from README
 DRIVERS= --enable-avalon\


Bug#890400: physamp: autopkgtest failure

2018-02-14 Thread Andreas Tille
Hi Graham,

I guess Julien Dutheil will care for a patch.

Kind regards

   Andreas.

On Wed, Feb 14, 2018 at 02:00:18PM +0200, Graham Inggs wrote:
> Source: physamp
> Version: 1.0.3-1
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic autopkgtest
> 
> Hi Maintainer
> 
> Since the upload of libbpp-core 2.3.2-1, physamp's autopkgtests have been
> failing [1] with the following error:
> 
> autopkgtest [03:46:54]: test run-unit-test: [---
> bppalnoptim: symbol lookup error: bppalnoptim: undefined symbol: 
> _ZN3bpp16ApplicationTools18getDoubleParameterERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt3mapIS6_S6_St4lessIS6_ESaISt4pairIS7_S6_EEEdS8_bi
> autopkgtest [03:46:55]: test run-unit-test: ---]
> autopkgtest [03:46:55]: test run-unit-test:  - - - - - - - - - - results - -
> - - - - - - - -
> run-unit-testFAIL non-zero exit status 127
> 
> 
> It looks like a symbol was dropped and a transition is needed.
> 
> Regards
> Graham
> 
> 
> [1] https://ci.debian.net/packages/p/physamp/unstable/amd64/
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de



Bug#890399: gitlab: override.conf in /etc/systemd/system/gitlab-*.service.d is not overwriten

2018-02-14 Thread Libor Klepáč
Here is little patch to migrate from override.conf to gitlab-user.conf in 
postinst.
Feel free to use or modify or discard ;)

Libor
diff -ur a/debian/postinst b/debian/postinst
--- a/debian/postinst	2018-02-14 12:52:35.904334762 +0100
+++ b/debian/postinst	2018-02-14 12:58:49.583882426 +0100
@@ -268,11 +268,15 @@
 path=/etc/systemd/system/gitlab-${service}.service.d
 mkdir -p $path
 if [ -e $path/override.conf ]; then
-  echo "$path/override.conf already exist"
+  # Disable user in override.conf
+  sed -i "s/^\( *\)\(User=.*\)/\1#\2/" $path/override.conf
+fi
+if [ -e $path/gitlab-user.conf ]; then
+  echo "$path/gitlab-user.conf already exist"
   # Make sure only gitlab user is updated
-  sed -i "s/^ *User=.*/User=$gitlab_user/" $path/override.conf
+  sed -i "s/^ *User=.*/User=$gitlab_user/" $path/gitlab-user.conf
 else
-  printf "[Service]\nUser=${gitlab_user}\n" > $path/override.conf
+  printf "[Service]\nUser=${gitlab_user}\n" > $path/gitlab-user.conf
 fi
   done
 


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

2018-02-14 Thread Luffah
Hello,

I used 'lxterminal 0.3.0'.
According to what you said, i upgraded it to testing version 'lxterminal
0.3.1'.

Now, it works.

THANK YOU.

Have a good day.


Le 14/02/2018 à 02:31, James McCoy a écrit :
> On Tue, Feb 13, 2018 at 12:11:47PM +0100, Luffah wrote:
>>When i open `nvim -u NONE` and i press ':' command line
>>shows special chars like":]2 q" instead of ":" .
> Quoting from upstream's [FAQ]:
>
>> This is a bug in your terminal emulator. It happens because Nvim sends
>> cursor-shape termcodes by default, if the terminal appears to be
>> xterm-compatible (TERM=xterm-256color).
>>
>> To workaround the issue, you can:
>>
>>   * Use a different terminal emulator
>>   * Disable guicursor in your Nvim config:
>>
>>   set guicursor=
> What terminal emulator are you using?
>
> [FAQ]: 
> https://github.com/neovim/neovim/wiki/FAQ#nvim-shows-weird-symbols-2-q-when-changing-modes
>
> Cheers,

-- 
_luffah_



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread Sylvestre Ledru
Hello,

On 14/02/2018 13:11, John Paul Adrian Glaubitz wrote:
> Source: llvm-toolchain-4.0
> Version: 1:4.0.1-10
> Severity: normal
> Tags: patch
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> 
> Hello!
> 
> In order to get the Rust compiler work on sparc64, we need another
> LLVM patch which is currently being upstreamed [1] which fixes the
> code generation on sparc64.
> 
> Without the patch, LLVM generates invalid code that binutils stumbles
> over and crashes with an internal error [2]. With the patch merged,
> LLVM is working properly and allows a full native build of the Rust
> compiler on sparc64 :).
> 
> Since Rust upstream is currently still on LLVM 4.0, even for Rust
> 1.24, it would be nice to have the patch merged for the 4.0 version
> as well as the 6.0 version of the llvm-toolchain package. Although
> we are going to convince upstream to backport the patch for 6.0.
> Could you please commit directly this change in the repo?

Thanks,
Sylvestre



Bug#890403: Claws Mail crashes during startup. Uninstalling claws-mail-fancy-plugin lets me start.

2018-02-14 Thread Johan T-Katiska

Package: claws-mail-fancy-plugin
Version: 3.14.1-3+b1
Severity: important

Dear Maintainer,

I updated the repositories 120218 or 130218. After this starting Claws
Main with the plugin enabled makes Claws Mail crash. A good outcome
would be for me to start Claws Mail with the plugin enabled.

Debug message:

plugin.c:452:trying to load
`/usr/lib/x86_64-linux-gnu/claws-mail/plugins/fancy.so'

Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 541:
elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) ==
R_X86_64_RELATIVE' failed!


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

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

Versions of packages claws-mail-fancy-plugin depends on:
ii  claws-mail  3.14.1-3+b1
ii  libarchive133.2.2-2
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11+deb9u1
ii  libcairo2   1.14.8-1
ii  libcurl3-gnutls 7.52.1-5+deb9u4
ii  libdb5.35.3.28-12+deb9u1
ii  libetpan17  1.6-3
ii  libfontconfig1  2.11.0-6.7+b1
ii  libfreetype62.6.3-3.2
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
pn  libgnutls-deb0-28   
ii  libgnutls30 3.5.8-5+deb9u3
ii  libgtk2.0-0 2.24.31-2
ii  libjavascriptcoregtk-1.0-0  2.4.11-3
ii  liblockfile11.14-1+b1
ii  libpango-1.0-0  1.40.5-1
ii  libpangocairo-1.0-0 1.40.5-1
ii  libpangoft2-1.0-0   1.40.5-1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libsoup2.4-12.56.0-2+deb9u1
ii  libwebkitgtk-1.0-0  2.4.11-3
ii  zlib1g  1:1.2.8.dfsg-5

claws-mail-fancy-plugin recommends no packages.

Versions of packages claws-mail-fancy-plugin suggests:
pn  html2ps  


pgpqnX48upXKM.pgp
Description: OpenPGP digital signature


Bug#890399: gitlab: override.conf in /etc/systemd/system/gitlab-*.service.d is not overwriten

2018-02-14 Thread Libor Klepáč
Here is little patch to migrate from override.conf to gitlab-user.conf in 
postinst.
Feel free to use or modify or discard ;)

Libor
diff -ur a/debian/postinst b/debian/postinst
--- a/debian/postinst	2018-02-14 12:52:35.904334762 +0100
+++ b/debian/postinst	2018-02-14 12:58:49.583882426 +0100
@@ -268,11 +268,15 @@
 path=/etc/systemd/system/gitlab-${service}.service.d
 mkdir -p $path
 if [ -e $path/override.conf ]; then
-  echo "$path/override.conf already exist"
+  # Disable user in override.conf
+  sed -i "s/^\( *\)\(User=.*\)/\1#\2/" $path/override.conf
+fi
+if [ -e $path/gitlab-user.conf ]; then
+  echo "$path/gitlab-user.conf already exist"
   # Make sure only gitlab user is updated
-  sed -i "s/^ *User=.*/User=$gitlab_user/" $path/override.conf
+  sed -i "s/^ *User=.*/User=$gitlab_user/" $path/gitlab-user.conf
 else
-  printf "[Service]\nUser=${gitlab_user}\n" > $path/override.conf
+  printf "[Service]\nUser=${gitlab_user}\n" > $path/gitlab-user.conf
 fi
   done
 


Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread Sylvestre Ledru
On 14/02/2018 13:20, John Paul Adrian Glaubitz wrote:
> On 02/14/2018 01:16 PM, Sylvestre Ledru wrote:
>> Could you please commit directly this change in the repo?
> 
> Which repository?
https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/

Sylvestre



Bug#887209: debootstick should depend on e2fsprogs explicitly

2018-02-14 Thread Etienne DUBLE
Hello again,
OK, I see. Actually debootstick should get important new features shortly.
Thus I might have to rebuild a package in one or two weeks, I guess. That
is why I did not bother Vincent too much for now. But I will see how fast
things go, and if things go slower I will soon remind Vincent about this
version of the package (or look for temporary alternate sponsorship).
Thanks for the information.
Etienne


2018-02-13 20:35 GMT+01:00 Andreas Henriksson :

> Hello Etienne Dublé,
>
> On Tue, Feb 13, 2018 at 08:16:31PM +0100, Etienne DUBLE wrote:
> > Hi,
> > I am the maintainer of debootstick, sorry for the silence.
>
> Thanks for your reply now though!
>
> > Yes, I uploaded a fixed version at:
> > https://mentors.debian.net/package/debootstick
> > My sponsor (Vincent Danjean) should review it shortly.
>
> Thanks for this information. If Vincent Danjean is too busy at the
> moment please feel free to reach out for temporary help with sponsorship!
>
> > Is it an urgent matter? I mean, what is the expected date for the
> > removal of e2fsprogs from essentials?
>
> We're aiming at getting this done before buster goes into freeze.
> For a change to the base system like this, the change (in e2fsprogs
> package) needs to happen well before the freeze date. There's no strict
> date for when all the bug reports Helmut filed needs to be done though,
> but the sooner the better. The most important part is knowing that
> maintainers have a plan for their package so we can identify the
> packages which needs help being taken care of.
>
> Regards,
> Andreas Henriksson
>


Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread John Paul Adrian Glaubitz

On 02/14/2018 01:22 PM, Sylvestre Ledru wrote:

Which repository?

https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/


I didn't know I have commit access to this repository, do I?

Adrian

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



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread John Paul Adrian Glaubitz

On 02/14/2018 01:16 PM, Sylvestre Ledru wrote:

Could you please commit directly this change in the repo?


Which repository?

Adrian

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



Bug#890404: (no subject)

2018-02-14 Thread D
Package: installation-reports

Boot method: microSD
Image versions: debian-9.3.0-i386-netinst, debian-9.3.0-i386-xfce-CD-1, 
debian-live-9.3.0-i386-xfce, debian-testing-i386-netinst (from 14.02)
Date: 14.02.18

Machine: Lenovo IdeaPad Miix 10
Processor: Intel Atom Z2760
Memory: 2048 MB

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Problems:
GRUB boots OK. Choosing any boot menu entry (graphical install, install, etc.) 
the system freezes completely. I tried run commands manually as following:
linux /install.i386/vmlinuz
initrd /install.i386/initrd.gz
boot

Then got same effect without errors. I also tested vmlinuz and initrd.gz from 
each image except live in qemu-system-i386. Both 9.3.0 continuously print error 
message after "fast init done". The testing one boots here without errors



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread Sylvestre Ledru
On 14/02/2018 13:23, John Paul Adrian Glaubitz wrote:
> On 02/14/2018 01:22 PM, Sylvestre Ledru wrote:
>>> Which repository?
>> https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/
> 
> I didn't know I have commit access to this repository, do I?

You are now :)

(sorry for svn btw)

Sylvestre



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

2018-02-14 Thread Libor Klepáč
Hi,
so running:
# npm install document-register-element@1.3.0
and 
# NODE_PATH=/usr/share/gitlab/node_modules webpack --config config/
webpack.config.js 

fixed second browser console error, javascript now loads, dashboard loads too

Thanks,

Libor


On středa 14. února 2018 13:05:16 CET Pirate Praveen wrote:
> On 02/14/2018 02:43 PM, Libor Klepáč wrote:
> > No luck, there is no jquery-atwho available in npm.
> > But i have downloaded version 1.5.4 of At.js and replaced files in
> > /usr/share/javascript/jquery-atwho
> > and one of errors disappeared.
> 
> This is a bug in libjs-jquery-atwho and I have reported it (#890391) and
> added a workaround for it in 9.5.4+dfsg-4.
> 
> You can try and install document-register-element@1.3.0 from npm (it is
> now 1.7.2). Or we may have a problem with our webpack.config.js or one
> of the webpack loaders.



Bug#890324: piuparts-master backup strategy

2018-02-14 Thread Holger Levsen
On Tue, Feb 13, 2018 at 03:51:28PM +, Holger Levsen wrote:
> 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).

piupartsm@pejacevic:/srv/piuparts.debian.org$ du -sch *
474Mbackup
516Ketc
0   fails
336Khome-master
24K home-slave
192Ghtdocs
3,0Mlib
60G master
2,9Msbin
616Kshare
14M src
0   tmp
252Gtotal

so /htdocs is ignored now and *if possible* I would like /master to be
backed up. Do you have the capacity to backup those 60G?


-- 
cheers,
Holger


signature.asc
Description: PGP signature


Bug#890324: [Piuparts-devel] Bug#890324: piuparts-master backup strategy

2018-02-14 Thread Andreas Beckmann
On 2018-02-14 13:33, Holger Levsen wrote:
> piupartsm@pejacevic:/srv/piuparts.debian.org$ du -sch *
> 474Mbackup
> 516Ketc
> 0   fails
> 336Khome-master
> 24K home-slave
> 192Ghtdocs
> 3,0Mlib
> 60G master
> 2,9Msbin
> 616Kshare
> 14M src
> 0   tmp
> 252Gtotal
> 
> so /htdocs is ignored now and *if possible* I would like /master to be
> backed up. Do you have the capacity to backup those 60G?

Since htdocs/ contains a lot of hardlinks to master/ and df counts the
files only on the first occurrence. I'm afraid master will be much
larger than 60GB. Probably 200+ GB.


Andreas



Bug#890406: linux-image-4.14.0-0.bpo.3-amd64: Installing kernel fails to build broadcom-sta

2018-02-14 Thread Steve
Package: src:linux
Version: 4.14.13-1~bpo9+1
Severity: important

Hi,

While installing this kernel, I get:
Préparation du dépaquetage de 
.../linux-image-4.14.0-0.bpo.3-amd64_4.14.13-1~bpo9+1_amd64.deb ...
Dépaquetage de linux-image-4.14.0-0.bpo.3-amd64 (4.14.13-1~bpo9+1) sur 
(4.14.13-1~bpo9+1) ...
Paramétrage de linux-image-4.14.0-0.bpo.3-amd64 (4.14.13-1~bpo9+1) ...
/etc/kernel/postinst.d/dkms:
Error ! Bad return status for module build on kernel:
4.14.0-0.bpo.3-amd64 (x86_64)
Consult /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log for more 
information.

make.log:

DKMS make.log for broadcom-sta-6.30.223.271 for kernel 4.14.0-0.bpo.3-amd64 
(x86_64)
mercredi 14 février 2018, 13:34:14 (UTC+0100)
/bin/sh: 1: [: Illegal number: 
/bin/sh: 1: [: Illegal number: 
Wireless Extension is the only possible API for this kernel version
Using Wireless Extension API
KBUILD_NOPEDANTIC=1 make -C /lib/modules/4.14.0-0.bpo.3-amd64/build M=`pwd`
make[1]: avertissement : jobserver n'est pas disponible : utilisation de -j1. 
Ajouter « + » à la règle parent du make.
make[1] : on entre dans le répertoire « 
/usr/src/linux-headers-4.14.0-0.bpo.3-amd64 »
CFG80211 API is prefered for this kernel version
Using CFG80211 API
Kernel architecture is X86_64
  AR  /var/lib/dkms/broadcom-sta/6.30.223.271/build/built-in.o
  CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c: In 
function ‘osl_os_get_image_block’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:1083:26: 
warning: passing argument 2 of ‘kernel_read’ makes pointer from integer without 
a cast [-Wint-conversion]
  rdlen = kernel_read(fp, fp->f_pos, buf, len);
  ^~
In file included from 
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/huge_mm.h:7:0,
 from 
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/mm.h:454,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:65,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:25:
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/fs.h:2833:16: note: 
expected ‘void *’ but argument is of type ‘loff_t {aka long long int}’
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^~~
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:1083:37: 
warning: passing argument 3 of ‘kernel_read’ makes integer from pointer without 
a cast [-Wint-conversion]
  rdlen = kernel_read(fp, fp->f_pos, buf, len);
 ^~~
In file included from 
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/huge_mm.h:7:0,
 from 
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/mm.h:454,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:65,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:25:
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/fs.h:2833:16: note: 
expected ‘size_t {aka long unsigned int}’ but argument is of type ‘char *’
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^~~
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:1083:42: 
warning: passing argument 4 of ‘kernel_read’ makes pointer from integer without 
a cast [-Wint-conversion]
  rdlen = kernel_read(fp, fp->f_pos, buf, len);
  ^~~
In file included from 
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/huge_mm.h:7:0,
 from 
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/mm.h:454,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:65,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:25:
/usr/src/linux-headers-4.14.0-0.bpo.3-common/include/linux/fs.h:2833:16: note: 
expected ‘loff_t * {aka long long int *}’ but argument is of type ‘int’
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^~~
  CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In 
function ‘wl_pci_probe’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:774:2: 
warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
  if ((val & 0xff00) != 0)
  ^~
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:776:3: 
note: ...this statement, but the latter is misleadingly indented as if it is 
guarded by the ‘if’
   bar1_size = pci_resource_len(pdev, 2);
   ^
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In 
function ‘wl_monitor’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:2915:10: 
error: ‘str

Bug#890324: [Piuparts-devel] Bug#890324: piuparts-master backup strategy

2018-02-14 Thread Holger Levsen
On Wed, Feb 14, 2018 at 01:41:31PM +0100, Andreas Beckmann wrote:
> Since htdocs/ contains a lot of hardlinks to master/ and df counts the
> files only on the first occurrence. I'm afraid master will be much
> larger than 60GB. Probably 200+ GB.

hmpf. also DSA still seems to be unhappy about too many files in
master/. hmmm.


-- 
cheers,
Holger


signature.asc
Description: PGP signature


Bug#887278: live-build should depend on e2fsprogs explicitly

2018-02-14 Thread Andreas Henriksson
Hello Raphael Hertzog,

thanks for your feedback on the issue

On Thu, Jan 25, 2018 at 04:49:37PM +0100, Raphael Hertzog wrote:
> On Mon, 22 Jan 2018, Andreas Henriksson wrote:
[...]
> > My conclusion is thus that this is a false positive and the bug report
> > should simply be closed.
[...]
> There are multiple calls to mkfs.${MKFS} that have not been detected.
> Some of them are already adequately protected by a "Check_package" call
> but I believe that scripts/build/binary_hdd and scripts/build/source_hdd
> have to be updated.

The source of live-build might well need improvements to deal with
what's inside the chroot it works with, but I don't think that's
the main focus of this bug report. A package relationship of live-build,
could not influence what's available in the chroot (unless I'm
mistaken), so the chroot is out of scope I'd say.

Please also note that e2fsprogs will still be installed on *any* system
where it has not explicitly been removed, even after it's no longer
marked 'Essential: yes'. Thus if the chroot live-build works with is
debootstrapped it'll still have e2fsprogs installed. The main question
for this bug report is 'if e2fsprogs is uninstalled, does live-build
also have to be uninstalled on the same system because of that?'.

Looking again, for places where mkfs is used *outside* the chroot
it seems cases looking at LB_BUILD_WITH_CHROOT being false
and then using mkfs is relevant, like for example this one:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_rootfs/#L187

... but at the same time, the same happens for parted usage
and there's no package relationship specified against parted:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L183

 or mkfs.jffs2:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L183


I'm confused about the current status and if we agree or not.
Would likely be better if we file separate bug reports for separate
issues, for example this typo will likely always make the ntfs check
fail but that's offtopic for this bug report:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L53

Would be happy to hear more about if maintainers thinks we need a
dependency or not. It still looks to me like *if* a dependency on
e2fsprogs is warranted, it should come with lots of other dependencies
at the same time (like parted, mtd-utils, etc., etc.).
(I'm happy to help out with work on that, but I'm not going to pick up
live-build maintenance and fix every possible bug in it. My interest is
limited to making e2fsprogs non-essential.)


Regards,
Andreas Henriksson



Bug#890405: maffilter: undefined symbol

2018-02-14 Thread Graham Inggs

Hi Maintainer

maffilter is affected by the same dropped symbol as in #890400:


$ maffilter
maffilter:symbol lookup error: maffilter: undefined symbol:
_ZN3bpp16ApplicationTools18getDoubleParameterERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt3mapIS6_S6_St4lessIS6_ESaISt4pairIS7_S6_EEEdS8_bi


Regards
Graham



Bug#890407: milkytracker: various buffer overflows possibly leading to remote code execution

2018-02-14 Thread James Cowgill
Package: milkytracker
Severity: grave
Tags: security upstream

Forwarding this bug sent to me by Johannes Schultz. It sounds bad. I
have not investigated it (and I don't know if it affects the pre-1.0
version in stable or not)

 Forwarded Message 
Subject: MilkyTracker - critical patches
Date: Wed, 14 Feb 2018 13:39:45 +0100
From: Johannes Schultz 
To: jcowg...@debian.org

Hi James,
I have recently fixed a bunch of very obvious and at the same time very
dangerous bugs in various module loaders in MilkyTracker, most of them
leading to out-of-bond writes both on the heap and stack. I think most
of them would be suitable for remote code execution.
You can find them here:
https://github.com/milkytracker/MilkyTracker/commit/6f7922616f31e5ceddd6f346cfc7f5d61a2f7683
You will also see the individual commits in the commit timeline around
October 2017.
I don't know if there is any immediate release planned by Deltafire, so
I recommend you to update the Debian packages based on those patches ASAP.
The individual diffs can also be found here:
https://sagagames.de/stuff/mt-patches.zip
They should apply to all MilkyTracker versions supported by the various
Debian releases, not just 1.01.00.

Best regards,
Johannes / OpenMPT Dev (and occasionall MilkyTracker bugfixer ;)



signature.asc
Description: OpenPGP digital signature


Bug#890374: Aw: Re: bug in lirc - 'post' and 'pre' not sent

2018-02-14 Thread Alec Leamas


On 14/02/18 10:11, softw...@quantentunnel.de wrote:
> Hi Alec
>
> Thanks. I have filed a bug, see 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890374
>
> Although not my opinion, I make you aware that Bengt Martensson on the lirc 
> mailing list is against patching the code. As I wrote in the bug report, I 
> see no reason why a directive in the conf file should be ignored. The patch 
> would only negatively affect a conf file where someone has included a 
> spurious 'post' or 'pre' directive, and the conf file only works because 
> luckily a bug prevents that spurious directive to have an effect.
>
> Best regards
>
> Andreas
>
Thanks for filing. That said, I'm moving this bug upstream to
https://sf.net/p/lirc/tickets/319/. In that bug I have also repeated my
reply, which basically requests some feedback from you. Let's keep
discussion in the upstream bug, it really belongs there.

Cheers!
.
--alec



Bug#775481:

2018-02-14 Thread alberto fuentes
Control: retitle -1 New upstream version 7.7

https://awstats.sourceforge.io/docs/awstats_changelog.txt

CVE-2017-1000501 has already been fixed in 7.6+dfsg-2


Bug#890408: dirvish: last character gobbled when tree alias is used

2018-02-14 Thread Peter Lebbing
Package: dirvish
Version: 1.2.1-1.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

The "tree" configuration option accepts an "alias" which causes the
index of all files in a vault to have a different path. There is a bug
in an old bugfix which causes misparsing.

The following can be observed:

Statement:
tree: /somewhere

Effect:
$srctree = "/somewhere"
$aliastree is empty

Correct!

Statement:
tree: /somewhere/

Effect:
$srctree = "/somewhere"
$aliastree is empty

Correct! Trailing slashes are removed.

Statement:
tree: /somewhere/ /alias

Effect:
$srctree = "/somewhere"
$aliastree = "/alias"

Correct! But accidentally. This is probably why the bug was not spotted
when it was introduced.

Statement:
tree: /somewhere /alias

Effect:
$srctree = "/somewher"
$aliastree = "/alias"

Wrong!

This is because of the following snippet:
- --8<---cut here---start->8---
#+SIS: KHL 2005-02-18  SpacesInSource fix
#-SIS: ($srctree, $aliastree) = split(/\s+/, $$Options{tree})
($srctree, $aliastree) = split(/[^\\]\s+/, $$Options{tree})
or seppuku 228, "ERROR: no source tree defined";
$srctree =~ s(\\ )( )g; #+SIS
$srctree =~ s(/+$)();
- --8<---cut here---end--->8---

So what happened on the last example? The split statement splits the
string "/somewhere /alias" into the components:
First part: "/somewher"
Separator: "e "
Second part: "/alias"

So the last character of the first part is gobbled as part of the
separator. Since an optional trailing slash is also removed, as long as
a trailing slash is used on the first part, everything still works. But
not including the trailing slash is a perfectly valid configuration.

I don't know any Perl, so I don't know the correct way to fix this. I
had a quick look and didn't see it.

Cheers,

Peter.

- -- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages dirvish depends on:
ii  libtime-modules-perl  2015.103-2
ii  libtime-period-perl   1.20-8.2
ii  perl  5.24.1-3+deb9u2
ii  perl-modules-5.24 [perl-modules]  5.24.1-3+deb9u2
ii  rsync 3.1.2-1+deb9u1

Versions of packages dirvish recommends:
pn  ssh  

dirvish suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFMBAEBCAA2FiEEZQCNwiCq4qJXTWzVlp4Bj95s3KEFAlqENdMYHHBldGVyQGRp
Z2l0YWxicmFpbnMuY29tAAoJEJaeAY/ebNyhA7oH/3fop7cthO1D+8jufZNFBnaK
kvNup5afXdBG7n1DC+FjPg8IqjiTQgsdzg4Q875h+anjFKNQuvROoYlpzwRwsjEI
OinjA/GZfzSxrwjGrx1kO8CcoL/B9ucppE1KXctc7qy6lO2KlqfMzoX/ZidV7Db1
GlgaCoBFeiWo+aqpAbBmlPi6M8xKpZj8k7BteHzklxJeWiDcym7B87IR1Q+Vntw5
sw8OzyVQzBGJgYcq4dZeHQ8xHd67sCaUTZGWdzQgIjdhWt1Aw2EtyMumT0q5u6rA
/NFcbvjt3GwQJ5oM/d8xXfYWZF0g/sabLbC6M+UydDDG4iu7cQ7kqem8cAzuRWk=
=+yoZ
-END PGP SIGNATURE-



Bug#775481:

2018-02-14 Thread alberto fuentes
Control: tags -1 - pending


Bug#890388: Acknowledgement (squashfs-tools: Add default value of -Xblock-size to man page)

2018-02-14 Thread DP

Never mind, I am going to stop submitting bugs to the Debian project, I
can no longer bear the mistreatment I get from Debian people.



Bug#890409: jenkins: when upgrading jenkins re-start intervenes with currently running jobs

2018-02-14 Thread Christof Schulze
Package: jenkins
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   when jenkins is installed, and a long-running jenkins-job is running, 
   execute:
   apt-get update
   apt-get install jenkins
   
   This causes jenkins to abort currently running jobs and re-start. 
   Jenkins has an option to re-start as soon as it is idle. Using that 
   during upgrades would lead to less-intrusive update behavior.

   * What outcome did you expect instead?
   I expect system upgrades to not interfere with user processes. 
   Unfortunately at this time, upgrading jenkins cancels currently 
   running jenkins jobs when jenkins is re-started immediately.

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


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

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



Bug#890410: mpv: fix for CVE-2018-6360 overlooks subtitles

2018-02-14 Thread James Cowgill
Package: mpv
Version: 0.23.0-1
Severity: grave
Tags: security upstream

Yet another bug relating to the fix for CVE-2018-6360...

This time the bug is not a regression, but a mistake upstream made when
writing the original patch. Upstream overlooked the handling of subtitle
URLs which were not protected.

Upstream has released 0.27.2 and 0.28.2 to fix these. I think the bug
affects 0.23 as well (but I have not yet checked).

Possibly this warrants a new CVE number.

Upstream commit:
https://github.com/mpv-player/mpv/commit/3e71eb8676de53a05f51b987d294e7d2fa0a5bc1

James



signature.asc
Description: OpenPGP digital signature


Bug#890411: flex: backported commit causes FTBFS (and potentially miscompilation) of generated files

2018-02-14 Thread Adrian Bunk
Package: flex
Version: 2.6.4-2
Severity: serious
Forwarded: https://github.com/westes/flex/issues/313
Control: affects -1 src:libreswan

https://buildd.debian.org/status/package.php?p=libreswan&suite=sid

...
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -I/<>/ports/linux/include 
-I../../OBJ.linux.aarch64/lib/libipsecconf -I. 
-I/<>/linux/net/ipsec -I/<>/linux/include 
-I/<>/include -I/usr/include/nss -I/usr/include/nspr  -pthread 
-std=gnu99 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all 
-fno-strict-aliasing -fPIE -DPIE -DUSE_DNSSEC 
-DDEFAULT_DNSSEC_ROOTKEY_FILE=\"/usr/share/dns/root.key\" -DUSE_NIC_OFFLOAD 
-DHAVE_LABELED_IPSEC -DLIBCURL -DUSE_LINUX_AUDIT -DUSE_SYSTEMD_WATCHDOG 
-DLIBLDAP -DHAVE_NM -DXAUTH_HAVE_PAM -DUSE_MD5 -DUSE_SHA2 -DUSE_SHA1 -DUSE_AES 
-DUSE_3DES -DUSE_CAMELLIA -DUSE_SERPENT -DUSE_TWOFISH -DUSE_CAST 
-DDEFAULT_RUNDIR=\"/run/pluto\" -DFIPSPRODUCTCHECK=\"/etc/system-fips\" 
-DIPSEC_CONF=\"/etc/ipsec.conf\" -DIPSEC_CONFDDIR=\"/etc/ipsec.d\" 
-DIPSEC_NSSDIR=\"/var/lib/ipsec/nss\" -DIPSEC_CONFDIR=\"/etc\" 
-DIPSEC_EXECDIR=\"/usr/lib/ipsec\" -DIPSEC_S
 BINDIR=\"/usr/sbin\" -DIPSEC_VARDIR=\"/var\" 
-DPOLICYGROUPSDIR=\"/etc/ipsec.d/policies\" 
-DIPSEC_SECRETS_FILE=\"/etc/ipsec.secrets\" -DFORCE_PR_ASSERT -DUSE_FORK=1 
-DUSE_VFORK=0 -DUSE_DAEMON=0 -DUSE_PTHREAD_SETSCHEDPRIO=1 -DGCC_LINT 
-DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat 
-Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations 
-Wredundant-decls -Wnested-externs -I/<>/ports/linux/include 
-I../../OBJ.linux.aarch64/lib/libipsecconf -I. 
-I/<>/linux/net/ipsec -I/<>/linux/include 
-I/<>/include -I/usr/include/nss -I/usr/include/nspr  -pthread 
-std=gnu99 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all 
-fno-strict-aliasing -fPIE -DPIE -DUSE_DNSSEC 
-DDEFAULT_DNSSEC_ROOTKEY_FILE=\"/usr/share/dns/root.key\" -DUSE_NIC_OFFLOAD 
-DHAVE_LABELED_IPSEC -DLIBCURL -DUSE_LINUX_AUDIT -DUSE_SYSTEMD_WATCHDOG 
-DLIBLDAP -DHAVE_NM -DXAUTH_HAVE_PAM -DUSE_MD5 -DUSE_SHA2 -DUSE_SHA1 -DUSE_AES 
-DUSE_3DES -DUSE_
 CAMELLIA -DUSE_SERPENT -DUSE_TWOFISH -DUSE_CAST 
-DDEFAULT_RUNDIR=\"/run/pluto\" -DFIPSPRODUCTCHECK=\"/etc/system-fips\" 
-DIPSEC_CONF=\"/etc/ipsec.conf\" -DIPSEC_CONFDDIR=\"/etc/ipsec.d\" 
-DIPSEC_NSSDIR=\"/var/lib/ipsec/nss\" -DIPSEC_CONFDIR=\"/etc\" 
-DIPSEC_EXECDIR=\"/usr/lib/ipsec\" -DIPSEC_SBINDIR=\"/usr/sbin\" 
-DIPSEC_VARDIR=\"/var\" -DPOLICYGROUPSDIR=\"/etc/ipsec.d/policies\" 
-DIPSEC_SECRETS_FILE=\"/etc/ipsec.secrets\" -DFORCE_PR_ASSERT -DUSE_FORK=1 
-DUSE_VFORK=0 -DUSE_DAEMON=0 -DUSE_PTHREAD_SETSCHEDPRIO=1 -DGCC_LINT 
-DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat 
-Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations 
-Wredundant-decls -Wnested-externs \
-MF ../../OBJ.linux.aarch64/lib/libipsecconf/lex.yy.d \
-MP -MMD -MT lex.yy.o \
-o ../../OBJ.linux.aarch64/lib/libipsecconf/lex.yy.o \
-c /<>/OBJ.linux.aarch64/lib/libipsecconf/lex.yy.c
parser.l: In function 'parser_y_init':
parser.l:104:33: error: implicit declaration of function 'strdup' 
[-Werror=implicit-function-declaration]
  ic_private.stack[0].filename = strdup(name);
 ^~
parser.l:104:33: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
parser.l: In function 'parser_y_nextglobfile':
parser.l:155:18: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
  iis->filename = strdup(iis->fileglob.gl_pathv[fcnt]);
  ^~
parser.l: In function 'yylex':
parser.l:451:16: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
 yylval.s = strdup(yytext);
^~
parser.l:467:16: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
 yylval.s = strdup(s);
^~
parser.l:483:16: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
 yylval.s = strdup(s);
^~
parser.l:490:16: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
 yylval.s = strdup(yytext);
^~
parser.l:497:16: error: incompatible implicit declaration of built-in function 
'strdup' [-Werror]
 yylval.s = strdup(yytext);
^~
cc1: all warnings being treated as errors
../../mk/depend.mk:34: recipe for target 'lex.yy.o' failed
make[5]: *** [lex.yy.o] Error 1



Bug#890412: CVE-2017-10689

2018-02-14 Thread Moritz Muehlenhoff
Source: puppet
Severity: important
Tags: security

Hi,
please see https://puppet.com/security/cve/CVE-2017-10689

Report is here: https://tickets.puppetlabs.com/browse/PUP-7866
Patch is here: 
https://github.com/puppetlabs/puppet/commit/17d9e02da3882e44c1876e2805cf9708481715ee

Cheers,
Moritz



Bug#884173: chromiun cast problem on rpi with debian stretch

2018-02-14 Thread Peter van Klink
Hi,

Still can’t cast from debian stretch.
I installed the latest updates by

sudo apt-get update
sudo apt-get upgrade

Do i have to do more than that to get chromium and casting working?

Peter
famvankl...@ziggo.nl 

Verzonden vanuit Mail voor Windows 10



Bug#890224: udftools: Cannot be upgraded inside a chroot due to udevadm call in postinst

2018-02-14 Thread Chris Lamb
tags 890224 - pending
tags 890298 + pending
thanks

Hi,

Oh dear, looks like I copied the wrong bug number. To clarify, bug #890298
in Lintian should be fixed in:

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

I have not made any changes to udftools (#890224).


Regards,

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



Bug#888985: [pkg-go] Bug#888985: Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

2018-02-14 Thread Pete Heist

> On Feb 12, 2018, at 11:05 PM, Pete Heist  wrote:
> 
>> On Feb 12, 2018, at 10:22 PM, Michael Stapelberg > > wrote:
>> 
>> Would you like me to sponsor the upload of irtt now?
> 
> Yes, if you would. Thanks!

Glad to see it in the queue, although I noticed there is “source amd64” in the 
Arch column, whereas Go libs seem to have “source all”. I’d like to make sure 
it’s available for any architectures Go supports. I see that dh-make-golang 
adds "Architecture: any” to debian/control for programs, and it adds 
“Architecture: all” for libraries. Is there something more I need to do?

Thanks,
Pete



Bug#840104: Encrypted uploads to the security archive

2018-02-14 Thread Aurelien Jarno
On 2018-02-01 20:45, Philipp Kern wrote:
> On 01.02.2018 10:30, Ansgar Burchardt wrote:
> > Hmm, another issue comes to mind:
> > 
> > If we care about encrypted buildd uploads, the buildds should probably
> > also download from the (private) security-buildd archive over an
> > encrypted connection, ideally with client authentication.  Otherwise
> > people could see the embargoed fixes in the source package.
> 
> Well, I thought this was already the case at this point. I suppose it
> shouldn't be too hard to add https:// support at this point given that
> apt supports it natively. But I think client auth should be a weak
> requirement at this point.

Since a few hours ago the build daemons access the security archive in
https. This might not be the perfect solution, but it's already an
improvement compared to plain http:// and it was (relatively) easy to
do. It doesn't prevent looking for a better solution though.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#890413: libqt5webkit5-dev: Qt5WebKit.pc provides incorrect include path

2018-02-14 Thread Georg Lukas
Package: libqt5webkit5-dev
Version: 5.212.0~alpha2-7
Severity: important

Building applications that rely on QtWebKit from Qt5 fails with the
following error:

./Swift/QtUI/QtWebKitChatView.h:13:10: fatal error: QWebElement: No such file 
or directory
 #include 
  ^
compilation terminated.

The header location is obtained from `pkg-config --cflags Qt5WebKit`
which returns this (formatted):

-I/usr/include/x86_64-linux-gnu/qt5/Qt5WebKit
-I/usr/include/x86_64-linux-gnu/qt5/QtGui
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtNetwork
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/include/x86_64-linux-gnu/qt5

However, the first path does not exist, the according directory is
called QtWebKit (without the "5") instead:

/usr/include/x86_64-linux-gnu/qt5/QtWebKit/QWebElement

Please fix the pkg-config file and provide updated packages. Thanks!


Kind regards,

Georg

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

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

Versions of packages libqt5webkit5-dev depends on:
ii  dpkg1.19.0.5
ii  libqt5webkit5   5.212.0~alpha2-7
ii  qtbase5-dev 5.9.2+dfsg-10
ii  qtdeclarative5-dev  5.9.2-3

libqt5webkit5-dev recommends no packages.

libqt5webkit5-dev suggests no packages.

-- no debconf information



Bug#888985: [pkg-go] Bug#888985: Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

2018-02-14 Thread Michael Stapelberg
There’s nothing you need to do. I built it on amd64, as is currently still
required when uploading to the NEW queue (I would have preferred to upload
source-only). Once it’s accepted, the buildds will build it for all
architectures.

On Wed, Feb 14, 2018 at 2:53 PM, Pete Heist  wrote:

>
> On Feb 12, 2018, at 11:05 PM, Pete Heist  wrote:
>
> On Feb 12, 2018, at 10:22 PM, Michael Stapelberg 
> wrote:
>
> Would you like me to sponsor the upload of irtt now?
>
>
> Yes, if you would. Thanks!
>
>
> Glad to see it in the queue, although I noticed there is “source amd64” in
> the Arch column, whereas Go libs seem to have “source all”. I’d like to
> make sure it’s available for any architectures Go supports. I see that
> dh-make-golang adds "Architecture: any” to debian/control for programs, and
> it adds “Architecture: all” for libraries. Is there something more I need
> to do?
>
> Thanks,
> Pete
>
>


-- 
Best regards,
Michael


Bug#888985: [pkg-go] Bug#888985: Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

2018-02-14 Thread Pete Heist

> On Feb 14, 2018, at 3:05 PM, Michael Stapelberg  wrote:
> 
> There’s nothing you need to do. I built it on amd64, as is currently still 
> required when uploading to the NEW queue (I would have preferred to upload 
> source-only). Once it’s accepted, the buildds will build it for all 
> architectures.

Great, thanks…

Pete



Bug#890414: awstats: run-parts doesnt work with .sh files

2018-02-14 Thread Alberto Fuentes
Package: awstats
Severity: normal
Tags: patch

Please, rename the file /etc/logrotate.d/httpd-prerotate/awstat/prerotate.sh

It will never run because run-parts ignore files with extension

Thanks



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

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

Versions of packages awstats depends on:
ii  perl  5.26.1-4

Versions of packages awstats recommends:
ii  coreutils   8.28-1
pn  libnet-xwhois-perl  

Versions of packages awstats suggests:
pn  apache2 | httpd 
pn  libgeo-ipfree-perl  
ii  libnet-dns-perl 1.10-2
ii  libnet-ip-perl  1.26-1
ii  liburi-perl 1.73-1



Bug#890414:

2018-02-14 Thread alberto fuentes
control: tags -1 - patch


Bug#890415: libfl-dev: Debian-specific libfl.so linker script causes FTBFS

2018-02-14 Thread Adrian Bunk
Package: libfl-dev
Version: 2.6.4-2
Severity: serious
Control: affects -1 src:acedb src:bsdgames src:chemeq src:ctn src:filters

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/acedb.html

...
/usr/bin/ld: cannot find /usr/lib/x86_64-linux-gnu/libfl_pic.a
collect2: error: ld returned 1 exit status
make[3]: *** [makefile:1271: metacheck] Error 1


See #837658 and the upstream bug linked there for background.



Bug#890416: Leafpad over ssh erases file content upon saving

2018-02-14 Thread Oralis Temp
Package: leafpad
Version: 0.8.18.1-5
Severity: important

Dear Maintainer,

I am using Leafpad to view / edit files on remote computers. If I log in
via a terminal using ssh -X [...], I observe no issue with the the program.
However, when logging in using "Caja" file browser for the Mate DE (via ssh
protocol), and editing a file with Leafpad, hitting the save button erases
(!) the file content, leaving me with an empty file. The issue seems to be
Leafpad-specific: I have tried out other text editors with GUI: Vim, Pluma,
and Kate, they do not seem to produce this effect, and also, nothing
irregular happens when using the editor locally. The remote computer hosts
a similarly configured Debian system.

Based on these, I wanted to notify you, although I am not exactly sure how
to exclude completely the possibility that it is a bug in Caja.

Thank you for looking into this.

All the bests,
Árpád


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

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

Versions of packages leafpad depends on:
ii  libc62.25-3
ii  libcairo21.15.8-2
ii  libglib2.0-0 2.54.1-1
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1

leafpad recommends no packages.

Versions of packages leafpad suggests:
pn  evince-gtk  

-- no debconf information


Bug#876900: in package dupload marked as pending

2018-02-14 Thread Aurelien Jarno
Hi Guillem,

On 2017-10-11 19:03, Guillem Jover wrote:
> Control: tag 876900 pending
> 
> Hi!
> 
> Bug #876900 in package dupload reported by you has been fixed in
> the dpkg/dupload.git Git repository. You can see the changelog below, and
> you can check the diff of the fix at:
> 
> https://anonscm.debian.org/cgit/dpkg/dupload.git/diff/?id=ef0b3ca
> 
> ---
> commit ef0b3caaced32728f6918900192c02a55a27072f
> Author: Guillem Jover 
> Date:   Tue Oct 10 18:25:02 2017 +0200
> 
> Do not change the file mode for security uploads
> 
> Closes: #876900
> 
> diff --git a/debian/changelog b/debian/changelog
> index 1c54754..922a5e8 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -12,7 +12,8 @@ dupload (2.9.1) UNRELEASED; urgency=medium
>  - Switch rsync method to use -L and -t instead of -a.
>  - Add a new host filemode option to configure the destination files mode.
>  - Use --chmod=F for rsync method instead of using a chmod command.
> -Proposed by Ansgar Burchardt .
> +- Do not change the file mode for Debian security uploads.
> +Proposed by Ansgar Burchardt . Closes: #876900
>  
>   -- Guillem Jover   Thu, 24 Aug 2017 20:45:05 +0200

Do you think such changes can be backported to stretch? That would be
very useful for the build daemons.

If you lack time, I can try to do the backport myself and provide you
the patches. Just ask.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#887278: live-build should depend on e2fsprogs explicitly

2018-02-14 Thread Raphael Hertzog
Hello,

On Wed, 14 Feb 2018, Andreas Henriksson wrote:
> The source of live-build might well need improvements to deal with
> what's inside the chroot it works with, but I don't think that's
> the main focus of this bug report. A package relationship of live-build,
> could not influence what's available in the chroot (unless I'm
> mistaken), so the chroot is out of scope I'd say.

Ack. But as you noticed afterwards, with LB_BUILD_WITH_CHROOT=false it
would use the binary from the host system.

> debootstrapped it'll still have e2fsprogs installed. The main question
> for this bug report is 'if e2fsprogs is uninstalled, does live-build
> also have to be uninstalled on the same system because of that?'.

Clearly, no. But it might be a good idea to add it to Recommends or
Suggests.

> Looking again, for places where mkfs is used *outside* the chroot
> it seems cases looking at LB_BUILD_WITH_CHROOT being false
> and then using mkfs is relevant, like for example this one:
> https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_rootfs/#L187

This one is fine as we have a Check_package here:
https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_rootfs/#L84

So if the package is not installed, it would fail and tell the user to
install the missing package. Ideally we would not give such error messages
to the user but LB_BUILD_WITH_CHROOT defaults to true and it doesn't seem
a good idea to add all those packages into Depends or Recommends when they
are usually not needed on the host.

> I'm confused about the current status and if we agree or not.

I believe this bug can be closed by adding a Suggests dependency. I will
do that in git.

> Would likely be better if we file separate bug reports for separate
> issues, for example this typo will likely always make the ntfs check
> fail but that's offtopic for this bug report:
> https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L53

What typo ?

ntfs-3g is a valid package
/sbin/mkfs.ntfs is a path to an existing program

> Would be happy to hear more about if maintainers thinks we need a

(I'm basically the de-facto maintainer nowadays)

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#890417: bctoolbox: FTBFS with mbedtls 2.7.0

2018-02-14 Thread James Cowgill
Source: bctoolbox
Version: 0.6.0-1
Severity: important
Tags: sid buster

Hi,

mongrel2 FTBFS when compiled against mbed TLS 2.7. This version fixes
some security issues, so I would like to upload it reasonably quickly.
This is the only package which FTBFS with the new version.

Build log extract (full log attached):
> /<>/src/crypto/mbedtls.c:421:4: error: 'mbedtls_sha1' is 
> deprecated [-Werror=deprecated-declarations]
> mbedtls_sha1(crt->raw.p, crt->raw.len, buffer);
> ^~~~
> In file included from /<>/src/crypto/mbedtls.c:38:0:
> /usr/include/mbedtls/sha1.h:320:39: note: declared here
>  MBEDTLS_DEPRECATED static inline void mbedtls_sha1( const unsigned char 
> *input,
>^~~~
> /<>/src/crypto/mbedtls.c:427:4: error: 'mbedtls_sha256' is 
> deprecated [-Werror=deprecated-declarations]
> mbedtls_sha256(crt->raw.p, crt->raw.len, buffer, 1); /* last argument is 
> a boolean, indicate to output sha-224 and not sha-256 */
> ^~
> In file included from /<>/src/crypto/mbedtls.c:39:0:
> /usr/include/mbedtls/sha256.h:279:39: note: declared here
>  MBEDTLS_DEPRECATED static inline void mbedtls_sha256(
>^~

I am guessing that disabling -Werror will fix this.

Thanks,
James
dpkg-buildpackage: info: source package bctoolbox
dpkg-buildpackage: info: source version 0.6.0-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Bernhard Schmidt 
 dpkg-source --before-build bctoolbox-0.6.0
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --buildsystem=cmake
   dh_auto_clean -O--buildsystem=cmake
   dh_clean -O--buildsystem=cmake
 debian/rules build-arch
dh build-arch --buildsystem=cmake
   dh_update_autotools_config -a -O--buildsystem=cmake
   dh_autoreconf -a -O--buildsystem=cmake
aclocal: warning: couldn't open directory 'm4': No such file or directory
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:25: installing './compile'
configure.ac:23: installing './config.guess'
configure.ac:23: installing './config.sub'
configure.ac:30: installing './install-sh'
configure.ac:30: installing './missing'
src/Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DCMAKE_SKIP_RPATH=ON -DENABLE_TESTS_COMPONENT=OFF
cd obj-x86_64-linux-gnu && cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_SKIP_RPATH=ON 
-DENABLE_TESTS_COMPONENT=OFF
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE) (Required is at least version 
"1.7.10")
-- Setting install rpath to /usr/lib/x86_64-linux-gnu
-- Looking for mbedtls_ssl_init
-- Looking for mbedtls_ssl_init - found
-- Looking for mbedtls_ssl_get_dtls_srtp_protection_profile
-- Looking for mbedtls_ssl_get_dtls_srtp_protection_profile - not found
-- Found MbedTLS: /usr/include  
-- Using mbedTLS
-- DTLS SRTP not available
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Looking for dladdr in dl
-- Looking for dladdr in dl - found
-- Looking for execinfo.h
-- Looking for execinfo.h - found
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   dh_auto_build -a -O--buildsystem=cmake
c

Bug#890419: [PATCH] Fix boostrapping libvirt LXC containers

2018-02-14 Thread Lubomir Rintel
Package: debootstrap
Severity: normal

Hi,

I'm attaching a patch set I'm using to bootstrap Debian in LXC
containers (managed by libvirtd).

Cheers,
LuboFrom 6b3b08f72331d533bfceb5e3cced6906027b665f Mon Sep 17 00:00:00 2001
From: Lubomir Rintel 
Date: Sat, 27 Jan 2018 13:21:06 +0100
Subject: [PATCH 3/3] Don't insist on preserving resolv.conf and hostname owner

If we're bootstrapping a Debian tree in a new user namespace, the files
from the host filesystem owned by users from outside our user mapping
range seem to be owned by 65534:65534.

We neither not want to create such files. Also, there doesn't seem to
much point in preserving the ownership information -- the alternative to
copying the files (just a couple of lines above) is just cat-ing files
and we're perfectly fine with that.
---
 functions | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/functions b/functions
index aea6ba9..5fb73de 100644
--- a/functions
+++ b/functions
@@ -1017,7 +1017,7 @@ conditional_cp () {
 		if [ -L "$1" ] && [ -e "$1" ]; then
 			cat "$1" >"$2/$1"
 		elif [ -e "$1" ]; then
-			cp -a "$1" "$2/$1"
+			cp "$1" "$2/$1"
 		fi
 	fi
 }
-- 
2.14.3

From 273978f25010b135a66e5c47f4a18e1a0f454caf Mon Sep 17 00:00:00 2001
From: Lubomir Rintel 
Date: Sat, 27 Jan 2018 11:36:46 +0100
Subject: [PATCH 2/3] Make devices setup work in lxc-libvirt containers

We're allowed to use some basic devices, but not to create new device
nodes. No problem, we can just bind the existing ones.

Another alternative would be to bind the whole host /dev. However,
binding just the devices we need ensures everything we need is there and
nothing more (to be consistent with other ways to set up the target
/dev).

The libvirt LXC containers are recognized by the container variable
in PID 1's environment, as defined in the "Container Interface"
specification.
---
 functions | 35 +++
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/functions b/functions
index 27458a9..aea6ba9 100644
--- a/functions
+++ b/functions
@@ -1131,6 +1131,11 @@ setup_devices () {
 		return 0
 	fi
 
+	if grep -q container=lxc-libvirt /proc/1/environ; then
+		setup_devices_bind
+		return 0
+	fi
+
 	case "$HOST_OS" in
 	kfreebsd*)
 		;;
@@ -1188,6 +1193,26 @@ setup_devices_fakechroot () {
 	ln -s /dev "$TARGET"
 }
 
+setup_devices_bind () {
+	mount -t tmpfs nodev $TARGET/dev
+	umount_on_exit /dev
+	for device in null zero full random urandom tty pts shm ptmx; do
+		if [ -d /dev/$device ]; then
+			mkdir $TARGET/dev/$device
+		elif [ -c /dev/$device ]; then
+			touch $TARGET/dev/$device
+		else
+			continue
+		fi
+		mount -o bind /dev/$device $TARGET/dev/$device
+		umount_on_exit /dev/$device
+	done
+	ln -s /proc/self/fd   $TARGET/dev/fd
+	ln -s /proc/self/fd/0 $TARGET/dev/stdin
+	ln -s /proc/self/fd/1 $TARGET/dev/stdout
+	ln -s /proc/self/fd/2 $TARGET/dev/stderr
+}
+
 setup_dselect_method () {
 	case "$1" in
 	apt)
@@ -1450,12 +1475,14 @@ check_sane_mount () {
 	*freebsd*|hurd*)
 		;;
 	*)
-		mknod "$1/test-dev-null" c 1 3 || return 1
-		if ! echo test > "$1/test-dev-null"; then
+		if ! grep -q container=lxc-libvirt /proc/1/environ; then
+			mknod "$1/test-dev-null" c 1 3 || return 1
+			if ! echo test > "$1/test-dev-null"; then
+rm -f "$1/test-dev-null"
+return 1
+			fi
 			rm -f "$1/test-dev-null"
-			return 1
 		fi
-		rm -f "$1/test-dev-null"
 		;;
 	esac
 
-- 
2.14.3

From 1892105130c3302f1fe2eea271b57f257be3e16a Mon Sep 17 00:00:00 2001
From: Lubomir Rintel 
Date: Tue, 13 Feb 2018 15:22:50 +0100
Subject: [PATCH 1/3] Umount filesystems in reverse order than they were
 mounted in

This will allow us to clean up the nested mounts more easily.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/functions b/functions
index e30687c..27458a9 100644
--- a/functions
+++ b/functions
@@ -1069,7 +1069,7 @@ umount_exit_function () {
 
 umount_on_exit () {
 	if [ "$UMOUNT_DIRS" ]; then
-		UMOUNT_DIRS="$UMOUNT_DIRS $1"
+		UMOUNT_DIRS="$1 $UMOUNT_DIRS"
 	else
 		UMOUNT_DIRS="$1"
 		on_exit umount_exit_function
@@ -1103,8 +1103,8 @@ setup_proc () {
 	*)
 		umount_on_exit /dev/pts
 		umount_on_exit /dev/shm
-		umount_on_exit /proc/bus/usb
 		umount_on_exit /proc
+		umount_on_exit /proc/bus/usb
 		umount "$TARGET/proc" 2>/dev/null || true
 		in_target mount -t proc proc /proc
 		if [ -d "$TARGET/sys" ] && \
-- 
2.14.3



Bug#890418: [PATCH] Don't let host PATH leak into the target commands

2018-02-14 Thread Lubomir Rintel
Package: debootstrap
Severity: normal

This fixes debootstrap on Fedora host, with unified /usr and PATH
lacking /bin and /sbin.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)From 03f508d24fd5f582c0fda420f9698174ab9128c0 Mon Sep 17 00:00:00 2001
From: Lubomir Rintel 
Date: Sat, 27 Jan 2018 11:04:11 +0100
Subject: [PATCH] Don't let host PATH leak into the target commands

This fixes debootstrap on Fedora host, with unified /usr and PATH
lacking /bin and /sbin.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/functions b/functions
index 3cfa0d4..e30687c 100644
--- a/functions
+++ b/functions
@@ -976,7 +976,7 @@ extract () { (
 ); }
 
 in_target_nofail () {
-	if ! $CHROOT_CMD "$@" 2>/dev/null; then
+	if ! PATH=/sbin:/usr/sbin:/bin:/usr/bin $CHROOT_CMD "$@" 2>/dev/null; then
 		true
 	fi
 	return 0
@@ -987,7 +987,7 @@ in_target_failmsg () {
 	local msg="$2"
 	local arg="$3"
 	shift; shift; shift
-	if ! $CHROOT_CMD "$@"; then
+	if ! PATH=/sbin:/usr/sbin:/bin:/usr/bin $CHROOT_CMD "$@"; then
 		warning "$code" "$msg" "$arg"
 		# Try to point user at actual failing package.
 		msg="See %s for details"
-- 
2.14.3



Bug#890413: Also missing QWebFrame path

2018-02-14 Thread Georg Lukas
The pc file is also missing the header path for the webkit widgets:

-I/usr/include/x86_64-linux-gnu/qt5/QtWebKitWidgets

Georg



Bug#861067: GNUstep

2018-02-14 Thread Ana C. Custura
Hi Alex,

No updates from the tasksel maintainers on #861065.  I built a live-gnustep 
image and did some preliminary testing, will update the other bug with some 
comments.

Ana

On Thu, Dec 14, 2017, at 12:23 PM, Alex Myczko wrote:
> Thanks Ana
> 
> Any updates on this? Who is on the other bug?
> 
> Best,
> 
> > On Sep 11, 2017, at 12:11, Ana C. Custura  wrote:
> > 
> > Hi
> > 
> > Thank you for this, just to let you know I'm on it and ready to update,
> > just waiting for taskel bug 861065 .
> > 
> > Ana
> > 



Bug#837304: sylpheed phones home

2018-02-14 Thread Hideki Yamane
On Sun, 11 Sep 2016 01:59:50 +0200 Ricardo Mones  wrote:
> > Without disabling auto update check feature, it seems that it is better to
> > disable auto update check configuration only. attached patch disables it
> > by default. It makes that user can enable it by clicking manually
> > configuration option.
> 
> If it's better, shouldn't that be done at upstream level?
> 
> IMHO all Sylpheed users deserve the same level of goodness, not only the
> Debian users of Sylpheed, don't they? :)

 It's good for Debian and other distro package users but not for
 Windows and binary from source users, since we distro just provide
 one version for each release.

 Well,
  - set disable auto update check configuration by default
  - and for Windows users, install wizard provides enable option
for it
 is best solution, IMO.


 But I'm not sure whether upstream work on this issue, until then,
 just specify --disable-updatecheck (and maybe --disable-updatecheckplugin?)
 for Debian package is simple.

 
-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp



Bug#887278: live-build should depend on e2fsprogs explicitly

2018-02-14 Thread Stefan Baur
Am 14.02.2018 um 15:46 schrieb Raphael Hertzog:
>> Would likely be better if we file separate bug reports for separate
>> issues, for example this typo will likely always make the ntfs check
>> fail but that's offtopic for this bug report:
>> https://sources.debian.org/src/live-build/1:20171207/scripts/build/binary_hdd/#L53
> What typo ?
> 
> ntfs-3g is a valid package
> /sbin/mkfs.ntfs is a path to an existing program

Yes, /sbin/mkfs.ntfs is.
But, /sbin/mkfs.nfts is not.  And that's what that source looks for.

Kind Regards,
Stefan Baur



  1   2   3   >