Bug#885445: calibre: [trivial] update description to mention supported ebook readers

2017-12-26 Thread Norbert Preining
> Thanks, I will fix that. Do you have any suggestion?

What about that:
Description: powerful and easy to use e-book manager
 Calibre is a complete e-library solution. It includes library management,
 format conversion, news feeds to e-book conversion, e-book viewer and editor,
 and e-book reader sync features.
 .
 Calibre is primarily an e-book cataloging program. It manages your e-book
 collection for you. It is designed around the concept of the logical book,
 i.e. a single entry in the database that may correspond to e-books in several
 formats. It also supports conversion to and from a dozen different e-book 
formats.
 .
 Calibre supports almost every single e-Reader (e.g., Kindle, Kobo, Nook) and
 is compatible with more devices with every update. Calibre can transfer your
 e-books from one device to another in seconds, wirelessly or with a cable.
 It will send the best file format for your device converting it if
 needed, automatically.
 .
 Calibre can automatically fetch news from a number of websites/RSS feeds,
 format the news into a e-book and upload to a connected device.
 .
 Calibre has also a built-in e-book viewer that can display all the major e-book
 formats.

Norbert

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



Bug#885445: calibre: [trivial] update description to mention supported ebook readers

2017-12-26 Thread Norbert Preining
Hi Nicholas,

> I just noticed that Calibre's description is out of date.  "Calibre
> has a modular device driver design that makes adding support for

Thanks, I will fix that. Do you have any suggestion?

> P.S, off-topic, if no one else would like to maintain a stretch bpo of
> it, I have a local (formal) backport of 3.14.0+dfsg-1.  Because it's a

What about doing the development for bpo in the same repo as main?
I have moved calibre to salsa.debian.org
  https://salsa.debian.org/preining/calibre
What about you join there and I add you to the repository? Then you can
push separate branches (like stretch-bpo) etc.

> I'm already using the bpo, because I have a new Kobo.

Which one? ;-)

Best

Norbert

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



Bug#885448: needrestart manual: typo: (a)dvaned -> (a)dvanced

2017-12-26 Thread Paul Wise
Package: needrestart
Version: 2.11-4
Severity: minor
File: /usr/share/man/man1/needrestart.1.gz

There is a typo in the manual page, this line:

  a   (a)dvaned mode

Should be changed to this line:

  a   (a)dvanced mode

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages needrestart depends on:
ii  dpkg   1.19.0.4
ii  gettext-base   0.19.8.1-4
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.24-1
ii  libproc-processtable-perl  0.53-2+b2
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.37-1+b2
ii  perl   5.26.1-3
ii  xz-utils   5.2.2-1.3

Versions of packages needrestart recommends:
ii  libpam-systemd  236-1

Versions of packages needrestart suggests:
ii  libnotify-bin0.7.7-3
ii  needrestart-session  0.3-5

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#878043: needrestart-session: Perl crash (SIGABRT) when pressing Refresh (sometimes)

2017-12-26 Thread Paul Wise
Package: needrestart-session
Version: 0.3-5
Followup-For: Bug #878043

I got another instance of this crash. As before, I hadn't upgraded perl
beetween starting needrestart-x11 and the crash happening.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core /var/crash/1000/22096-1000-1000-6-1514339889-chianamo--usr-bin-perl.core 
/usr/bin/perl

warning: core file may not match specified executable file.
[New LWP 22096]
[New LWP 28625]
[New LWP 28626]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl 
/usr/lib/needrestart-session/needrestart-x11 -n'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7ff7d7e10f40 (LWP 22096))]
#0  0x7ff7d718ba70 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7ff7d718d19a in __GI_abort () at abort.c:89
#2  0x7ff7d71ca300 in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7ff7d72c4d30 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x7ff7d71d095e in malloc_printerr (action=3, str=0x7ff7d72c4d88 
"munmap_chunk(): invalid pointer", ptr=, ar_ptr=) 
at malloc.c:5079
#4  0x7ff7d61756ca in XS_Wx__Event_DESTROY(PerlInterpreter*, CV*) 
(my_perl=0x55eda9dfb010, cv=) at Event.c:554
#5  0x55eda80ea391 in Perl_pp_entersub (my_perl=0x55eda9dfb010) at 
pp_hot.c:4231
#6  0x55eda805b238 in Perl_call_sv (my_perl=my_perl@entry=0x55eda9dfb010, 
sv=0x55edaa463148, flags=flags@entry=45) at perl.c:2848
#7  0x55eda80ef31e in S_curse (my_perl=my_perl@entry=0x55eda9dfb010, 
sv=sv@entry=0x55edaaa91638, check_refcnt=check_refcnt@entry=true) at sv.c:6972
#8  0x55eda80efbc8 in Perl_sv_clear (my_perl=my_perl@entry=0x55eda9dfb010, 
orig_sv=orig_sv@entry=0x55edaaa91608) at sv.c:6576
#9  0x55eda80f0081 in Perl_sv_free2 (my_perl=my_perl@entry=0x55eda9dfb010, 
sv=0x55edaaa91608, rc=) at sv.c:7073
#10 0x55eda8120397 in S_SvREFCNT_dec_NN (sv=, 
my_perl=0x55eda9dfb010) at inline.h:200
#11 0x55eda8120397 in Perl_free_tmps (my_perl=my_perl@entry=0x55eda9dfb010) 
at scope.c:212
#12 0x55eda805b5aa in Perl_call_sv (my_perl=my_perl@entry=0x55eda9dfb010, 
sv=0x55edaa785050, flags=flags@entry=13) at perl.c:2860
#13 0x7ff7d61822fd in wxPliEventCallback::Handler(wxEvent&) 
(this=, event=...) at cpp/e_cback.cpp:93
#14 0x7ff7d50ab2ce in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) (entry=..., handler=, event=...) at 
../src/common/event.cpp:1390
#15 0x7ff7d50ab6da in wxEvtHandler::SearchDynamicEventTable(wxEvent&) 
(this=0x55edaa891ac0, event=...) at ../src/common/event.cpp:1749
#16 0x7ff7d50ab76f in wxEvtHandler::TryHereOnly(wxEvent&) 
(this=0x55edaa891ac0, event=...) at ../src/common/event.cpp:1583
#17 0x7ff7d50ab823 in wxEvtHandler::TryBeforeAndHere(wxEvent&) (event=..., 
this=0x55edaa891ac0) at ../include/wx/event.h:3671
#18 0x7ff7d50ab823 in wxEvtHandler::ProcessEventLocally(wxEvent&) 
(this=0x55edaa891ac0, event=...) at ../src/common/event.cpp:1520
#19 0x7ff7d50ab885 in wxEvtHandler::ProcessEvent(wxEvent&) 
(this=0x55edaa891ac0, event=...) at ../src/common/event.cpp:1493
#20 0x7ff7d57aff1b in wxWindowBase::TryAfter(wxEvent&) 
(this=0x55edaaae84e0, event=...) at ../src/common/wincmn.cpp:3427
#21 0x7ff7d50ab5e7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) 
(this=, event=...) at ../src/common/event.cpp:1611
#22 0x7ff7d57b148c in wxWindowBase::HandleWindowEvent(wxEvent&) const 
(this=this@entry=0x55edaaae84e0, event=...) at ../src/common/wincmn.cpp:1525
#23 0x7ff7d562ea87 in wxgtk_button_clicked_callback(GtkWidget*, wxButton*) 
(button=0x55edaaae84e0) at ../src/gtk/button.cpp:40
#27 0x7ff7d3d0ce9f in  (instance=, signal_id=, 
detail=) at ../../../../gobject/gsignal.c:3447
#24 0x7ff7d3cf0f9d in g_closure_invoke (closure=0x55edaaac7e30, 
return_value=0x0, n_param_values=1, param_values=0x7ffcf4b15b00, 
invocation_hint=0x7ffcf4b15a80) at ../../../../gobject/gclosure.c:804
#25 0x7ff7d3d03b25 in signal_emit_unlocked_R 
(node=node@entry=0x55edaa441410, detail=detail@entry=0, 
instance=instance@entry=0x55edaa5b9f10, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7ffcf4b15b00) at 
../../../../gobject/gsignal.c:3705
#26 0x7ff7d3d0c485 in g_signal_emit_valist (instance=0x55edaa5b9f10, 
signal_id=, detail=0, var_args=var_args@entry=0x7ffcf4b15cc0) at 
../../../../gobject/gsignal.c:3391
#28 0x7ff7d46e90c5 in gtk_real_button_released (button=0x55edaa5b9f10 
[GtkButton]) at ./gtk/gtkbutton.c:1712
#32 0x7ff7d3d0ce9f in  (instance=, signal_id=, 
detail=) at ../../../../gobject/gsignal.c:3447
#29 0x7ff7d3cf0f9d in g_closure_

Bug#885447: adequate: check for libraries that are linked but not used

2017-12-26 Thread Paul Wise
Package: adequate
Version: 0.15.1
Severity: wishlist

Some libraries/executables link against libraries but do not use any
symbols from them, removing them would reduce file size slightly and
probably reduces RAM at runtime. It would be nice to detect this
situation and warn about it in adequate. dpkg-shlibdeps and symtree are other 
tools that can detect this scenario.

$ symtree /usr/lib/x86_64-linux-gnu/libopencv_freetype.so.3.2.0
/usr/lib/x86_64-linux-gnu/libopencv_freetype.so.3.2.0
...
libdl.so.2 => !?! useless link !?!
...
librt.so.1 => !?! useless link !?!
libtbb.so.2 => !?! useless link !?!
...
libm.so.6 => !?! useless link !?!
$ chronic getbuildlog opencv last amd64
$ grep useless.*libopencv_freetype opencv*.log 
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_phase_unwrapping.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_xphoto.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_optflow.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_stereo.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_img_hash.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_rgbd.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_saliency.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_datasets.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_freetype.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_hdf.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_bioinspired.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_tracking.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_text.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_ximgproc.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_xobjdetect.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_fuzzy.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_plot.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_bgsegm.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_line_descriptor.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_aruco.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_dpm.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_surface_matching.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_ccalib.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_structured_light.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_reg.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_face.so.3.3.0 
were not linked against librt.so.1 (they use none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_phase_unwrapping.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_xphoto.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_optflow.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_stereo.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_img_hash.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_rgbd.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_saliency.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_datasets.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_freetype.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_hdf.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_bioinspired.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_tracking.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_text.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_ximgproc.so.3.3.0
 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_xobjdetect.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_fuzzy.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_plot.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_bgsegm.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_line_descriptor.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_aruco.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_dpm.so.3.3.0 
debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_surface_matching.so.3.3.0
 debian/libopencv-contrib3.3/usr/lib/x86_64-linux-gnu/libopencv_ccalib.so.3.3.0 
debian/libopencv-contrib3.3/

Bug#884493: 1.8.0 packaged in git

2017-12-26 Thread Benda Xu
Hi,

It looks like this package has not been touch upon for almost 2 years.
I went ahead and committed version 1.8.0 to collab-maint/babeld.

  https://anonscm.debian.org/git/collab-maint/babeld.git

The compiled package works smoothly on jessie, stretch and sid.

Cheers,
Benda



Bug#885446: systemd: user processes remain after logout

2017-12-26 Thread Ian Bruce
Package: systemd
Version: 236-1
Severity: important

Is there any legitimate reason why after logging out of an XFCE session,
all these desktop processes should remain alive?


# ps axfu | grep ^ian
ian   1687  0.0  0.0  80544  8384 ?Ss   19:35   0:00 
/lib/systemd/systemd --user
ian   1688  0.0  0.0 198308  3328 ?S19:35   0:00  \_ (sd-pam)
ian   1712  0.0  0.0  49884  4628 ?Ss   19:35   0:00  \_ 
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only
ian   1761  0.0  0.0 287908  6696 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfsd
ian   1781  0.0  0.0 348884  8172 ?Ssl  19:35   0:00  \_ 
/usr/lib/at-spi2-core/at-spi-bus-launcher
ian   1786  0.0  0.0  49392  3612 ?S19:35   0:00  |   \_ 
/usr/bin/dbus-daemon 
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
--print-address 3
ian   1796  0.0  0.0  58948  5136 ?S19:35   0:00  \_ 
/usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
ian   1803  0.0  0.0  94464  2928 ?SLs  19:35   0:00  \_ 
/usr/bin/gpg-agent --supervised
ian   1866  0.0  0.0 362732 12304 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfs-udisks2-volume-monitor
ian   1870  0.0  0.0 286540  6172 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfs-gphoto2-volume-monitor
ian   1874  0.0  0.0 377216  7432 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfs-afc-volume-monitor
ian   1879  0.0  0.0 272236  5252 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfs-goa-volume-monitor
ian   1883  0.0  0.0 274168  5560 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfs-mtp-volume-monitor
ian   1903  0.0  0.0 364068  6684 ?Sl   19:35   0:00  \_ 
/usr/lib/gvfs/gvfsd-trash --spawner :1.5 /org/gtk/gvfs/exec_spaw/0
ian   1908  0.0  0.0 187628  5084 ?Sl   19:35   0:00  \_ 
/usr/lib/dconf/dconf-service
ian   1925  0.0  0.0 198308  4380 ?Ssl  19:35   0:00  \_ 
/usr/lib/gvfs/gvfsd-metadata
ian   2029  0.0  0.0  76028  5580 ?S19:35   0:00  \_ 
/usr/lib/x86_64-linux-gnu/gconf/gconfd-2
ian   1753  0.2  0.0 357636  7136 ?Ssl  19:35   0:01 
/usr/bin/ibus-daemon --daemonize --xim
ian   1773  0.0  0.0 276644  8308 ?Sl   19:35   0:00  \_ 
/usr/lib/ibus/ibus-dconf
ian   1806  0.0  0.0 200916  5752 ?Sl   19:35   0:00  \_ 
/usr/lib/ibus/ibus-engine-simple
ian   2051  0.0  0.0 303972 10976 ?Sl   19:35   0:00  \_ 
/usr/lib/ibus-mozc/ibus-engine-mozc --ibus
ian   2055  0.0  0.1  95956 29312 ?SLl  19:35   0:00  \_ 
/usr/lib/mozc/mozc_server
ian   1917  0.0  0.2 254324 33804 ?Sl   19:35   0:00 
/usr/bin/python3 /usr/share/system-config-printer/applet.py


It may be a related issue that also after logging out, a tmpfs remains
mounted at /run/user/.



-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.116
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.1-4
ii  libaudit1   1:2.8.2-1
ii  libblkid1   2.30.2-0.1
ii  libc6   2.25-5
ii  libcap2 1:2.25-1.2
ii  libcryptsetup4  2:1.7.5-1
ii  libgcrypt20 1.8.1-4
ii  libgpg-error0   1.27-5
ii  libidn111.33-2.1
ii  libip4tc0   1.6.1-2+b1
ii  libkmod224-1
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.3
ii  libmount1   2.30.2-0.1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.7-2
ii  libsystemd0 236-1
ii  mount   2.30.2-0.1
ii  procps  2:3.3.12-3
ii  util-linux  2.30.2-0.1

Versions of packages systemd recommends:
ii  dbus1.12.2-1
ii  libpam-systemd  236-1

Versions of packages systemd suggests:
ii  policykit-10.105-18
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 236-1

-- no debconf information



Bug#861011: RFS: qt5ct/0.31-2 [ITP]

2017-12-26 Thread Tobias Frost
Am Mittwoch, den 27.12.2017, 14:38 +0800 schrieb Paul Wise:
> On Wed, Dec 27, 2017 at 5:25 AM, Tobias Frost wrote:
> 
> > however, those are small problems, so I've uploaded it.
> 
> Please also see my review earlier in the RFS bug report.

Of course check also pabs list of points. (most of it has been
implemented though)

--
tobi



Bug#861011: RFS: qt5ct/0.31-2 [ITP]

2017-12-26 Thread Paul Wise
On Wed, Dec 27, 2017 at 5:25 AM, Tobias Frost wrote:

> - do not install AUTHORS. This information should be visible in
> d/copyright already.

The authors of a piece of software are not always the same as the
copyright holders of that software. There are various things that can
cause this, including employment law, employment contracts, commercial
copyright transfer, copyright donations etc. I would suggest
installing AUTHORS too, so the people who actually wrote the code also
get credit.

> however, those are small problems, so I've uploaded it.

Please also see my review earlier in the RFS bug report.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#885445: calibre: [trivial] update description to mention supported ebook readers

2017-12-26 Thread Nicholas D Steeves
Package: calibre
Version: 3.14.0+dfsg-1
Severity: minor

I just noticed that Calibre's description is out of date.  "Calibre
has a modular device driver design that makes adding support for
different e-reader devices easy. At the moment, it has support for the
SONY PRS 500/505/700 and the iPhone (with the stanza reader
software)." This software would be more discoverable if more popular
readers such as the Kindle and Kobo were also mentioned.

This bug can also probably be tagged newcomer if there aren't any
trademark issues with adding these brands to the description :-)

Regards,
Nicholas

P.S, off-topic, if no one else would like to maintain a stretch bpo of
it, I have a local (formal) backport of 3.14.0+dfsg-1.  Because it's a
complex piece of software I'm not sure if I'm the best candidate, but
I'm already using the bpo, because I have a new Kobo.



Bug#885444: O: phantomjs -- minimalistic headless WebKit-based browser with JavaScript API

2017-12-26 Thread Dmitry Smirnov
Package: wnpp
Severity: normal

I don't have enough capacity left to look after _phantomjs_
hence it needs new maintainer...

Maintaining this package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov.


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


Bug#817277: phantomjs: PhantomJS fails to run headless

2017-12-26 Thread Dmitry Smirnov
On Friday, 20 January 2017 2:08:01 PM AEDT David Guglielmi wrote:
> Have you try to use ?
> 
> export QT_QPA_PLATFORM=offscreen and and export
> 
> Just add it in /usr/bin/phantomjs and I can run phantomjs headlessly.

David, I'm very sorry that it took me so long to recognise your advise as 
useful. Thank you and apologies for my mistake.

You were right, setting "QT_QPA_PLATFORM=offscreen" allows to run all the 
scripts from http://phantomjs.org/screen-capture.html without Xvfb-run.

Also instead of setting "QT_QPA_PLATFORM" environment variable one can
invoke phantomjs with "-platform offscreen" options.

I will mention that in README.Debian...

-- 
Regards,
 Dmitry Smirnov.


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


Bug#884007: systemtap FTBFS on ia64

2017-12-26 Thread Ritesh Raj Sarraf
Control: tag -1 +pending

On Sun, 2017-12-10 at 06:59 -0500, Jason Duerstock wrote:
> Source: systemtap
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> systemtap fails to build from source on ia64.  The attached patch
> should correct the problem spots.

Thanks. I've applied the patch and it'll be part of the next upload.
I do not see ia64 in the list of build machines. Are you doing an
external build elsewhere ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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


Bug#862966: texlive-fonts-extra: Missing yinitas.tfm which makes yfonts.sty unusable

2017-12-26 Thread Norbert Preining
> @Norbert: could you care about this?

I pinged Karl. Our ctan2tds script contains:
   'yinit-as',"die 'skipping, wait request, old never-included variant of 
yinit'",
which is a bit cryptic. I guess it is about a missing license statement
that triggered removal.

If this is the case and the license situation is not cleared up, then
there is nothing we can do here. yfonts package supports 4 different
gothic fonts, one of which (yinit) we cannot ship. There is no way we
will remove yfonts package, and upstream will not remove support for
yinit fonts as they are there and can be installed by any user.

Best

Norbert

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



Bug#877041: RFA: ublock-origin -- general-purpose lightweight ads, malware, trackers blocker

2017-12-26 Thread Eolk
Just a heads up, I am still interested in this and have been working on 
it. You'll have to excuse the slowness. I am a bit of a sloth as you can 
see. 😁


For future reference, what's the best way to submit a patch?

Scott

On Sat, 25 Nov 2017 09:50:08 -0700 Sean Whitton 
 wrote:

> Dear Scott,
>
> On Tue, Nov 21, 2017 at 07:01:08PM -0500, Scott Hardin wrote:
> > I would like to help out or adopt this project with the original 
maintainer's
> > blessing. I use ublock origin all the time. I'm fairly new, so I 
will probably
> > have quite a few questions. If Sean doesn't want to give up the 
project to me
> > because he doesn't have any time to answer questions or because he 
believes
> > this project is too difficult for a newcomer, I'm okay with that as 
well.

>
> Thank you for your interest!
>
> I am happy to give up the package to someone able to come up with a
> complete patch for #877040. This would certainly demonstrate sufficient
> competence.
>
> How about you start working on that bug, and then you can become the
> maintainer once you have a patch for it?
>
> --
> Sean Whitton



Bug#885443: debsnap: should allow writing output to existing directory without -f

2017-12-26 Thread Marvin Renich
Package: devscripts
Version: 2.17.11
Severity: wishlist
File: /usr/bin/debsnap

It is clear that it was a conscious decision to give an error when
downloading a source or binary package to an existing directory (without
-f), but I don't understand what real problem this solves.  On the other
hand, I would expect an error if the output file already exists, and
would expect -f to override this and replace the output file.

The documentation does not specify what happens, with or without -f,
when the destination file exists.  Does -f allow overwriting an existing
.deb file, or just writing the .deb to an existing directory if the .deb
file doesn't exist?

I am writing a script to back out of an upgrade that had unintended
consequences.  The script generates a list of (package, version,
architecture) tuples (a multiarch system with amd64 and i386 packages)
that are not necessarily sorted, and uses debsnap to download the .deb
files.  This script fails because I want both amd64 and i386 versions of
some packages, but because they are requested via separate invocations
of debsnap, the destination dir (but not destination file) already
exists when the second architecture is requested.  The script would
require significant extra logic to sort the tuples and combine different
architectures for the same package into a single debsnap invocation.

I would like to see the behavior changed so that the existence of the
destination directory is irrelevant, and the presence of -f determines
whether to give an error if the output file exists (no -f) or overwrite
a pre-existing output file (-f).

Perhaps if I understood the real use case for the current behavior, I
would be less eager to ask for a change, but it sounds like the current
behavior was designed to guard against unrealistic circumstances, but
fails at doing so.  How do you guarantee that no other process writes to
the destination directory after debsnap creates it?  Under what
circumstances would some other process be trying to write to the
destination directory, and why?

The best you can do is ensure that debsnap does not overwrite an
existing file, and creating a new output directory is neither necessary
nor sufficient to accomplish that.

...Marvin

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.4
ii  libc6 2.25-3
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.1-3
ii  python3   3.6.4~rc1-2
ii  sensible-utils0.0.11

Versions of packages devscripts recommends:
ii  apt 1.6~alpha5
ii  at  3.1.20-3.1
ii  curl7.57.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.11.24
ii  dput-ng [dput]  1.15
pn  equivs  
ii  fakeroot1.22-2
ii  file1:5.32-1
ii  gnupg   2.2.3-1
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.19.0.4
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.23-1
ii  liburi-perl 1.72-2
ii  libwww-perl 6.29-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.65
ii  man-db  2.7.6.1-4
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-apt 1.4.0~beta3+b1
ii  python3-debian  0.1.31
ii  python3-magic   1:5.32-1
ii  python3-requests2.18.1-1
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.19-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.2-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.4
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot   

Bug#885442: Please ship GeoLite2 databases

2017-12-26 Thread Faidon Liambotis
Package: geoip-database
Version: 20171107-1
Severity: wishlist

Hi,

libmaxminddb/geoipupdate/etc. maintainer here. I've been thinking of
filing this for a while but I've neglected doing so!

Would it be possible for geoip-database to also ship GeoLite2 databases,
either in the same binary package or a new one?

GeoIP2/GeoLite2 is the successor to GeoIP (which is now renamed to
"GeoIP Legacy"). It addresses various issues that GeoIP had, including
the need for structured data, single databases for IPv4/IPv6 etc. You
can read more about GeoIP2 in MaxMind's website[1].

The three GeoLite2 databases (Country, City, ASN) are available under
the usual place[2] and seem to be under the CC-BY-SA 4.0 license.

MaxMind ships these in both CSVs and MMDB. MMDB is their new format,
which is an open file format (also licensed under CC-BY-SA 3.0).[3]

They also ship a DFSG-free writer library in Perl[4], but I don't think
it would be useful here, given that (AFAIK) MMDB seems to be their
preferred form of modification, and thus the actual, real source file.

Regards,
Faidon

1: https://dev.maxmind.com/geoip/geoip2/whats-new-in-geoip2/
2: https://dev.maxmind.com/geoip/geoip2/geolite2/
3: https://maxmind.github.io/MaxMind-DB/
4: https://github.com/maxmind/MaxMind-DB-Writer-perl



Bug#885432: bugs-field-does-not-refer-to-debian-infrastructure for non-Debian packages

2017-12-26 Thread Russ Allbery
Niels Thykier  writes:

> We have the lintian profile system that enables you to process packages
> in a different context than "debian" (e.g. "ubuntu" or your own personal
> context).  The profiles can enable / disable tags (or even change
> severity of the tags).

> However, we cannot guess which profile you want based on the package.
> Partly, because we select the profile first and then process the
> package.  Partly, because (as I recall) we do not have a reliable
> indicator of which "derivative" the package is targeting.  In the best
> case, we only have the "distribution", but e.g. "jessie" is used both by
> Debian but also third-parties (a notably Devuan, but ISVs may also have
> their own repositories that mirror the Debian release that they match).

Yeah, profiles would definitely work.  I wonder if it would make sense to
have a file in debian/source that indicates the profile in some way?

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



Bug#885441: Deprecate in favor of geoipupdate?

2017-12-26 Thread Faidon Liambotis
Package: geoip-database-contrib
Version: 1.19
Severity: normal

Hi,

libmaxminddb/geoipupdate/etc. maintainer here. This may be a bit of an
odd request:

Have you considered dropping this package in favor of geoipupdate?
geoipupdate is shipped by MaxMind and is officially supported by them.
It has a lot more code, and is capable for much more than the shell
scripts that geoip-database-contrib ships.

geoipupdate is capable of downloading both GeoIP Legacy and GeoIP2
databases, as well as GeoLite and GeoLite2 databases at the same time,
so it's a suitable replacement for geoip-database-contrib's
functionality, that's also forward-looking. (GeoIP Legacy is deprecated
and an increasing amount of software are switching to GeoIP2.)

I just uploaded geoipupdate 2.5.0-1 that includes:
* a configuration file, with only GeoLite2 enabled, but also with the
  edition codes for GeoLite Legacy commented-out to ease a transition,
* a weekly cronjob, at the request of a user and inspired from
   geoip-database-contrib's equivalent functionality.

All that said, a few caveats:
- (Debian's) geoipupdate uses /var/lib/GeoIP for the download location,
  instead of /usr/share/GeoIP, which is/would be an FHS violation.
  
- Additionally, the actual filenames of the databases are going to be
  different in some cases. geoipupdate names files according to what
  MaxMind's servers instruct it to and has no option to rename.

- Of the databases geoip-database-contrib ships, only one is not
  available using geoipupdate: GeoLite ASN IPv6. I don't think it's
  widely used, especially given that GeoLite IPv6 was and remained an
  experiment (paid GeoIP IPv6 never existed). If you disagree, we can
  always ask MaxMind to add it to their geoipupdate server and see what
  they say.

What do you think? Let me know if there are any ways I can help from the
geoipupdate side :)

Regards,
Faidon



Bug#885440: wiki.debian.org: whitelist account registration for all Debian contributors

2017-12-26 Thread Paul Wise
Package: wiki.debian.org
Severity: wishlist
Tags: newcomer

The Debian wiki requires account registration and requires admin
confirmation for possibly-spammy new accounts. In order to reduce
signup friction for existing contributors to other parts of Debian,
we should automatically whitelist all Debian contributors for new
account creation, similarly to how we whitelist Tor connections.

To achieve this, we need two things:

A script to automatically download a list of Debian contributor email
addresses from the relevant locations and write them here, one per line:

etc/moin/email_whitelist_auto

A modification to our internal scripts to pay attention to this file.
Once the first task has been completed, the wiki admins will do this.

Some possible locations to get Debian contributor addresses:

http://ftp.debian.org/ (Maintainer/Uploaders fields)
https://keyring.debian.org/ (OpenPGP key IDs)
https://db.debian.org/ (would require authentication)
https://contributors.debian.org/ (would require authentication)
https://alioth.debian.org/ (would require authentication)
https://salsa.debian.org/ (would require authentication)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#885439: RM: openxenmanager -- RoM; RoQA; uses deprecated pygtk

2017-12-26 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: openxenmana...@packages.debian.org

Please remove openxenmanager from Debian.

It was intentionally kept out of Stretch a year ago and hasn't been in
Testing since.
https://bugs.debian.org/842972

It's currently blocking the removal of python-gtk-vnc (requested since
pygtk is no longer maintained).
https://bugs.debian.org/885376

I got approval from the Debian maintainer Ritesh Raj Sarraf before
filing this bug.

Thanks,
Jeremy Bicha



Bug#885438: lintian: data/ permanently outdated

2017-12-26 Thread gregor herrmann
Package: lintian
Version: 2.5.66
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of my pet peeves with lintian is that the files in the data/ dir
are permanently outdated, as they are not automatically recreated
before a release.

Usually I only notice that if data/fields/perl-provides strays from
reality but today I decideded to take a closer look and ran all the
private/refresh-* scripts, and the result is something like

18 files changed, 1108 insertions(+), 1062 deletions(-)

which is still not reflecting reality, as those scripts sometimes
need a directory argument and sometimes don't, and sometimes write to
a file and sometimes to stdout, and sometimes accept a Contents-*.gz
file (which doesn't exist anymore locally) and sometimes don't, and
sometimes can be called directly, and sometimes are manually or
automatically called from debian/rules … etc.


My proposal is that all automatically created files in data/ are
refreshed before each release, which probably needs some mechanism to
do this more or less automatically; and I'm sorry for not providing a
nice patch series right now but I'm kinda lost in this organically
grown setup …


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlpDGg5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYs5w//a4A6LutTXpqBJWm1rEscX8lSsUEBPcjBshLB9aHJ/xJL4SSWCLGpawUx
zQPU7TBfsBG0FYwJrOYzVaa5OEk6fO0xOCa8ptQ1UG/icoz/kfEmo1/GIQdhmwob
Hl0/jTG4NnqO2dD1oER3sXpMMHrvsByVDaiGy6vkaP4YiQ7+WY9nB/GnixbRB9wq
tDiecnvTty31Lj4g2Xm6NguDTeuppbULkGfi6kXBwd6X4uIpiYVrxvkj6eGbSTPP
3TBstZsdCGH7rw+21WcdEGcSDBi0r0UCkaeCc3b3nDlqyLGURQG0JI76PartNCJh
vjbyYOpqi6HMTRW9m5Y3oW0f3194UMwQujV/m15/HOFjPM5O0DT9GGsqlPxvFeD1
gBbqWt/m0ZG+CRIfa/gVcV+oPAFs3HfODhRlRDN7rcAGXOlYomtczHbMd+21hTi/
oDgvKcYaULt0AoBJgMFFopjl9GPuiIrmX9uFV1cJQBmRuSJd2eM7Pjcwm8Eq2HUl
/K4nt4tBPPwyCv/+J4AHR8oeDlPhlHZVMTcU5XuJj1COljjLxrByYeL3DVbpMNfn
H4pOOJKzZ5lL6Zyue0OGn+cKfCpMO1yeXVwmunklrz4W0rvEbP1VmknPwQI646bR
xH6hZzZqK5L4G88OuV9y7UT7fE4sEP6F5ZawjvBqfYejkdZnH2A=
=skQA
-END PGP SIGNATURE-


Bug#885437: debsnap: fails when an old version uses a now-invalid version number

2017-12-26 Thread Marvin Renich
Package: devscripts
Version: 2.17.11
Severity: normal

If a package has in the past used a version number that is no longer
valid, debsnap cannot download any version of that package.

$ debsnap --binary -d . -a amd64 libnspr4 2:4.16-1
debsnap: error: M18-3 is not a valid version

According to snapshot.debian.org, in 2009 libnspr4 was built from source
package mozilla version M18-3.  This is no longer a valid Debian version
number, but was then(?).  debsnap cannot download a recent version of
this package because the available-version information from snapshot.d.o
contains a version number that debsnap doesn't know how to handle.

...Marvin

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.4
ii  libc6 2.25-3
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.1-3
ii  python3   3.6.4~rc1-2
ii  sensible-utils0.0.11

Versions of packages devscripts recommends:
ii  apt 1.6~alpha5
ii  at  3.1.20-3.1
ii  curl7.57.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.11.24
ii  dput-ng [dput]  1.15
pn  equivs  
ii  fakeroot1.22-2
ii  file1:5.32-1
ii  gnupg   2.2.3-1
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.19.0.4
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.23-1
ii  liburi-perl 1.72-2
ii  libwww-perl 6.29-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.65
ii  man-db  2.7.6.1-4
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-apt 1.4.0~beta3+b1
ii  python3-debian  0.1.31
ii  python3-magic   1:5.32-1
ii  python3-requests2.18.1-1
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.19-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.2-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.4
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.2.2+dfsg1-2
ii  gnuplot-qt [gnuplot] 5.2.2+dfsg1-2
ii  gpgv 2.2.3-1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.4-1
pn  mozilla-devscripts   
ii  mutt 1.9.2-1
ii  openssh-client [ssh-client]  1:7.6p1-2
pn  piuparts 
ii  quilt0.63-8.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34.1

-- no debconf information



Bug#851086: [Pkg-citadel-devel] Bug#851086: Bug#859789: RFH: citadel/webcit

2017-12-26 Thread Art Cancro


On 2017-12-20 4:06 AM, Michael Meskes wrote:


  have a new version number   :)
Great! Thanks Art! I'll do an upload when it's available.

Ok, everything is set.  Version 914 of all Citadel components is now 
available from the main website, or from git master.  My fleet of test 
systems is not very large, but I have tested on "old Debian" and "new 
Debian" and it built properly on both.


Once all the dust settles down and you guys confirm that the packages 
are building cleanly again, we'll probably start dropping support for 
old versions of some of the dependencies ... like older versions of 
openssl, libical, libdb, etc ... I'd like to keep the support matrix as 
small as possible because we are a small team.


Let me know how it goes!

   -- Art



Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

2017-12-26 Thread Marvin Renich
Package: aptitude
Version: 0.8.10-1
Severity: normal

/var/log/aptitude shows the default architecture (e.g. amd64) when
logging actions pertaining to an architecture:all package, e.g.

[UPGRADE] console-setup:amd64 1.171 -> 1.172

should be

[UPGRADE] console-setup:all 1.171 -> 1.172

This is making it more difficult to write a script to back out of last N
updates using debsnap, because debsnap can download debs for a specific
architecture or all available architectures, but does not automatically
select an architecture:all deb when a specific architecture is requested
(reasonable behavior for debsnap).

In the extremely rare (I think) case where an upgrade (or downgrade)
replaces a specific architecture package with an architecture all
package, or vice versa, I would be okay with my script breaking because
it does not have enough information from /var/log/aptitude to get it
right.  E.g. I think it is okay to arbitrarily choose one architecture
or the other, but I think it is more useful to know the architecture of
the package being replaced than that of the one being installed.

...Marvin

-- Package-specific info:
Terminal: screen
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.10
Compiler: g++ 7.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20171125
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffc98f75000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f8c1698d000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f8c1675d000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f8c16533000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f8c1632c000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f8c16031000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f8c15d29000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f8c15b11000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f8c158f8000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f8c156f4000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f8c152e9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f8c150cb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8c14d4c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8c14a39000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8c14822000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c1447f000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f8c14269000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8c1404f000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f8c13e3f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8c13c19000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f8c13a07000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8c137e9000)
/lib64/ld-linux-x86-64.so.2 (0x7f8c1734b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8c135e5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8c133dd000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8c131d8000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.10-1
ii  libapt-pkg5.0  1.6~alpha5
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4+b2
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4+b2
ii  libboost-system1.62.0  1.62.0+dfsg-4+b2
ii  libc6  2.25-3
ii  libcwidget3v5  0.5.17-6
ii  libgcc11:7.2.0-18
ii  libncursesw5   6.0+20171125-1
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsqlite3-0   3.21.0-1
ii  libstdc++6 7.2.0-18
ii  libtinfo5  6.0+20171125-1
ii  libxapian301.4.5-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.11

Versions of packages aptitude suggests:
ii

Bug#885435: cryptsetup: The file named debian/rules may be incorrect for 2:2.0.0~rc1-1

2017-12-26 Thread Alan Fung
Package: cryptsetup
Version: 2:2.0.0-1
Severity: normal

Dear Maintainer,

I used the debian/rules file to build deb files for installation.

I found that the link "/usr/lib/x86_64-linux-gnu/libcryptsetup.so" was pointed 
to a wrong location (/lib/x86_64-linux-gnu/), whlie it should point to 
/usr/lib/x86_64-linux-gnu/libcryptsetup.so.

The problem comes form the line in debian/rules:

dh_link -plibcryptsetup-dev lib/$(DEB_HOST_MULTIARCH)/$$(basename $$(readlink 
debian/libcryptsetup12/lib/$(DEB_HOST_MULTIARCH)/libcryptsetup.so.4)) 
usr/lib/$(DEB_HOST_MULTIARCH)/libcryptsetup.so

In which, "libcryptsetup.so.4" should be changed to "libcryptsetup.so.12", 
because after cryptsetup 2.0, the library changed from libcryptsetup.so.4 to 
libcryptsetup.so.12.

After updating the debian/rules script by myself, the installation worked 
without any error.


-- Package-specific info:

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

Kernel: Linux 4.9.72-intel (SMP w/40 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 cryptsetup depends on:
ii  cryptsetup-bin 2:2.0.0-1
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  dmsetup2:1.02.90-2.2+deb8u1
ii  libc6  2.19-18+deb8u10

Versions of packages cryptsetup recommends:
ii  busybox 1:1.22.0-9+deb8u1
ii  console-setup   1.123
ii  initramfs-tools [linux-initramfs-tool]  0.120+deb8u3
ii  kbd 1.15.5-2

Versions of packages cryptsetup suggests:
ii  dosfstools  3.0.27-1
pn  keyutils
ii  liblocale-gettext-perl  1.05-8+b1

-- Configuration Files:
/etc/bash_completion.d/cryptdisks 758d5cfcd9df55c82a7bb094728114b5 [Errno 2] No 
such file or directory: u'/etc/bash_completion.d/cryptdisks 
758d5cfcd9df55c82a7bb094728114b5'
/etc/init/cryptdisks-udev.conf ed789690d1770e3f3a2682c11e359bb6 [Errno 2] No 
such file or directory: u'/etc/init/cryptdisks-udev.conf 
ed789690d1770e3f3a2682c11e359bb6'
/etc/init/cryptdisks.conf e5527ceb5c020174a6464b81126bb5f7 [Errno 2] No such 
file or directory: u'/etc/init/cryptdisks.conf e5527ceb5c020174a6464b81126bb5f7'

-- debconf information excluded



Bug#885298: gquilt: Depends on unmaintained pygtk

2017-12-26 Thread Jeremy Bicha
On Tue, Dec 26, 2017 at 4:20 PM, Peter Williams  wrote:
> I lost interest in maintaining gquilt when I created darning
> (https://github.com/pwil3058/darning) and stopped using quilt.  I do not
> intend to do any more work on gquilt so if you wish to continue using it you
> should arrange for someone to take it over from me.

Thank you Peter for replying.

The bug I filed here will lead to gquilt being removed from Debian
Testing in a few weeks. And unless sometimes does the porting work and
takes over maintenance, we'll eventually remove gquilt from Debian
(unstable).

Thanks,
Jeremy Bicha



Bug#885430: ITP: darkcold-gtk-theme -- dark GTK2/GTK3/Metacity theme

2017-12-26 Thread Jeremy Bicha
Hi Adam,

Would you be interested in team maintenance and a bit of an experiment?

I was planning to start a Team for several months, but after I became
a DD and was about to request a team be set up, I found that there
wasn't really an obvious path for how to do that any more.
https://lists.debian.org/debian-devel/2017/09/msg00221.html

Now, things still aren't very clear but I guess it sort of works. We
can create a GitLab team and a Debian Tracker team. We can use
@packages.debian.org as the Maintainer for now.

See also today's debian-devel list discussion about salsa.debian.org.

Thanks,
Jeremy Bicha



Bug#885433: wiki.debian.org: Access to wiki.debian.org is blocked with 403 Forbidden

2017-12-26 Thread Luiz DAvila
Package: wiki.debian.org
Severity: normal

It appears some of our IPs have been blocked, and we receive a 403
Forbidden when trying to reach wiki.debian.org.


Can you please unblock *189.103.121.228 ?*


*thanks*


Bug#885432: bugs-field-does-not-refer-to-debian-infrastructure for non-Debian packages

2017-12-26 Thread Niels Thykier
Russ Allbery:
> Package: lintian
> Version: 2.5.66
> Severity: normal
> 
> The new tag bugs-field-does-not-refer-to-debian-infrastructure added in
> the most recent version of Lintian is a false positive for non-Debian
> packages.  I have a pile of personal packages that I maintain in a separate
> archive, but prefer to use all the normal Debian packaging methods and
> tools.  This tag will always be a false positive for those packages since
> they have:
> 
> Bugs: mailto:r...@debian.org
> 
> I could add an override to every personal package, but that's a little
> annoying to do.
> 
> Is there some way that I could tell Lintian that this is a non-Debian
> package to suppress this tag?  That might be a useful general feature to
> suppress a few other tags too, such as new-package-should-close-itp-bug.
> 
> [...]
> 

Hi,

We have the lintian profile system that enables you to process packages
in a different context than "debian" (e.g. "ubuntu" or your own personal
context).  The profiles can enable / disable tags (or even change
severity of the tags).

However, we cannot guess which profile you want based on the package.
Partly, because we select the profile first and then process the
package.  Partly, because (as I recall) we do not have a reliable
indicator of which "derivative" the package is targeting.  In the best
case, we only have the "distribution", but e.g. "jessie" is used both by
Debian but also third-parties (a notably Devuan, but ISVs may also have
their own repositories that mirror the Debian release that they match).

Thanks,
~Niels



Bug#885348: linux-image-4.14.0-2-amd64: aLatest kernel (linux-image-4.14.0-2-amd64) breaks e1000e driver on Intel 82579V Gigabit adapter

2017-12-26 Thread Timo van Roermund

Hi Salvatore,


On 26-12-2017 16:37, Salvatore Bonaccorso wrote:

Hi Timo,

On Tue, Dec 26, 2017 at 03:38:24PM +0100, T.A. van Roermund wrote:

Package: src:linux
Version: 4.14.7-1
Severity: critical
Tags: patch upstream
Justification: breaks the whole system

Dear Maintainer,

This morning, I updated the Linux kernel from linux-image-4.13.0-1-amd64 to 
linux-image-4.14.0-2-amd64.
Afterwards, my Intel Gigabit adapter (details below) did not work properly 
anymore (no link).
When booting back into the previous kernel (4.13), everything works properly 
again.

It seems like others experience the same behavior, see:
https://bugzilla.kernel.org/show_bug.cgi?id=198047

According to that thread, this bug was introduced in v4.14.3 through commit 
830466993daf09adbd179e4c74db07279a088f8c
("e1000e: Separate signaling for link check/link up", upstream: 
19110cfbb34d4af0cdfe14cd243f3b09dc95b013).

The thread also includes a patch that (apparently) fixes the problem:
https://bugzilla.kernel.org/attachment.cgi?id=261183&action=diff&collapsed=&headers=1&format=raw

Could you please apply this patch to the Debian kernel, until it is included in 
upstream?

Sorry to hear that. Would it be possible for you to confirm that the
patch fixes your issue, following:

https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2

Regards,
Salvatore


I followed these instructions to build a patched kernel:
Linux 4.14.0-2-amd64 #1 SMP Debian 4.14.7-1a~test (2017-12-27) x86_64 
GNU/Linux


With this kernel, the link of my Intel Gigabit adapter comes up again 
and works normally.


So yes, I can hereby confirm that the patch fixes my issue.

Best regards,

Timo



Bug#885432: bugs-field-does-not-refer-to-debian-infrastructure for non-Debian packages

2017-12-26 Thread Russ Allbery
Package: lintian
Version: 2.5.66
Severity: normal

The new tag bugs-field-does-not-refer-to-debian-infrastructure added in
the most recent version of Lintian is a false positive for non-Debian
packages.  I have a pile of personal packages that I maintain in a separate
archive, but prefer to use all the normal Debian packaging methods and
tools.  This tag will always be a false positive for those packages since
they have:

Bugs: mailto:r...@debian.org

I could add an override to every personal package, but that's a little
annoying to do.

Is there some way that I could tell Lintian that this is a non-Debian
package to suppress this tag?  That might be a useful general feature to
suppress a few other tags too, such as new-package-should-close-itp-bug.

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

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

Versions of packages lintian depends on:
ii  binutils  2.29.1-12
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information



Bug#885431: glhack: game overwrites files shipped in the package

2017-12-26 Thread Paul Wise
Package: glhack
Version: 1.2-3+b1
Severity: normal

After playing glhack, I noticed this in my cron output:

/etc/cron.monthly/debsums:
/var/games/glhack/logfile
/var/games/glhack/record

It looks like glhack overwrites files shipped in the package:

$ apt-file show glhack | grep /var
glhack: /var/games/glhack/logfile
glhack: /var/games/glhack/perm
glhack: /var/games/glhack/record

Instead, they should be removed from the package and created by the
game when it starts and removed by the package purge process.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages glhack depends on:
ii  libc62.25-5
ii  libgl1   1.0.0-1
ii  libgl1-mesa-glx  17.2.5-1
ii  libpng16-16  1.6.34-1
ii  libsdl1.2debian  1.2.15+dfsg2-0.1

glhack recommends no packages.

glhack suggests no packages.

-- debconf-show failed

-- debsums errors found:
debsums: changed file /var/games/glhack/logfile (from glhack package)
debsums: changed file /var/games/glhack/record (from glhack package)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#881725: apache2: reload fails inside (libvirt) lxc container

2017-12-26 Thread Matthew Gabeler-Lee

On Mon, 25 Dec 2017, Stefan Fritsch wrote:


Hi Matthew,

I don't know libvirt lxc containers at all, but ...

On Tue, 14 Nov 2017, Matthew Gabeler-Lee wrote:

Nov 14 14:38:33 hostname systemd[1]: Reloading The Apache HTTP Server.
Nov 14 14:38:33 hostname systemd[11798]: apache2.service: Failed at step 
NAMESPACE spawning /usr/sbin/apachectl: No such file or directory


this seems to say that /usr/sbin/apachectl is missing in your container. I
guess this is a configuration problem in your container config. I don't
think there is anything that can be done from the apache side.


I'm pretty sure that's actually _not_ what it's saying, or at least it's 
an overly literal interpretation.


For one, the container is a full debian OS container.  If apachectl 
wasn't there, apache would never _start_, much less fail to _restart_.


Second, when looking into the code, the "Failed at step NAMESPACE" is, I 
think, the crux of the issue.  It's failing at a step related to setting 
up the namespaces to run apachectl, not finding the binary.


Either way, apachectl is very definitely in the container.

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9



Bug#885430: ITP: darkcold-gtk-theme -- dark GTK2/GTK3/Metacity theme

2017-12-26 Thread Adam Borowski
Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: darkcold-gtk-theme
  Upstream Author : OriginalSeed
* URL : https://github.com/kilobyte/darkcold
   based on https://github.com/originalseed/darkcold
* License : GPL2+
  Description : dark GTK2/GTK3/Metacity theme
 A night-style window theme by OriginalSeed.  It is mostly black, with
 dark blue elements.



Bug#885429: Please add dep8 test

2017-12-26 Thread Robie Basak
Source: openscad
Version: 2015.03-2+dfsg-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Thank you for the openscad-testing package. It was very helpful in
pinning down a bug I'm chasing.

Please could you add a dep8 (http://dep.debian.net/deps/dep8/) test that
automatically runs the testsuite from openscad-testing? Patch below.
This will allow both Debian and Ubuntu infrastructure to automatically
run the tests including on reverse dependency changes, and the test
result history will help us better pin down regression root causes in
the future.

At the moment a number of tests in the test suite fail. I intend to file
a separate bug for this. But at least with the dep8 tests running we
will have better visibility of this.

Here's the (rather trivial) patch:

diff -Nru openscad-2015.03-2+dfsg/debian/tests/control 
openscad-2015.03-2+dfsg/debian/tests/control
--- openscad-2015.03-2+dfsg/debian/tests/control1970-01-01 
01:00:00.0 +0100
+++ openscad-2015.03-2+dfsg/debian/tests/control2017-12-24 
09:10:45.0 +
@@ -0,0 +1,3 @@
+Test-Command: openscad-testrun --virtual --directory $AUTOPKGTEST_TMP/testrun
+Depends: openscad-testing, xvfb
+Restrictions: allow-stderr



signature.asc
Description: PGP signature


Bug#885428: gcc-6: Please add support for building internal libunwind

2017-12-26 Thread John Paul Adrian Glaubitz
Source: gcc-6
Version: 6.4.0-11
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

In order to be able to build a cross-compiler for ia64, we need
to be able to build and use the internal libunwind of gcc as the
external libunwind is not available for cross-builds.

I have added a new flag "with_unwind" which is set in debian/
rules.defs for the case when a cross-compiler is built for the
ia64 target architecture. This "with_unwind" is used in debian/
rules2 to pass either --with-system-libunwind or --with-newlib/
--without-headers to the configure script, the latter are necessary
to set inhibit_libc without which building the internal libunwind
is not possible.

I also added the internal libunwind to debian/rules.sonames and
debian/rules.d/binary-libgcc.mk to install the static and shared
libunwind libraries into libgcc if libgcc built as a shared library.

Unfortunately, I couldn't figure out a clean way to avoid the
double check for ia64-linux == $(DEB_TARGET_GNU_TYPE), but this
is the only way to make sure I'm not breaking anything outside
ia64.

With the patch applied, rebuilding src:gcc-6 provides a gcc-6-source
package which can be used successully to build the package
cross-toolchain-base-ports with the ia64 target enabled which in
turn will allow us to enable ia64 in gcc-7-cross-ports (after
this patch has been added to src:gcc-7 as well).

Thanks,
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
diff -Nru old/gcc-6-6.4.0/debian/rules2 new/gcc-6-6.4.0/debian/rules2
--- old/gcc-6-6.4.0/debian/rules2   2017-12-27 01:32:47.0 +0100
+++ new/gcc-6-6.4.0/debian/rules2   2017-12-27 01:59:43.873507119 +0100
@@ -560,7 +560,12 @@
 endif
 
 ifneq (,$(findstring ia64-linux,$(DEB_TARGET_GNU_TYPE)))
-  CONFARGS += --with-system-libunwind
+  ifeq ($(with_unwind),yes)
+  CONFARGS += --with-newlib
+  CONFARGS += --without-headers
+  else
+  CONFARGS += --with-system-libunwind
+  endif
 endif
 
 ifneq (,$(findstring sh4-linux,$(DEB_TARGET_GNU_TYPE)))
diff -Nru old/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk 
new/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk
--- old/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk 2017-12-27 
01:32:47.0 +0100
+++ new/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk 2017-12-27 
01:10:46.587608383 +0100
@@ -265,6 +265,9 @@
$(if $(filter yes, $(with_qmath)),
$(call install_gcc_lib,libquadmath,$(QUADMATH_SONAME),$(1),$(2))
)
+   $(if $(filter yes, $(with_unwind)),
+   $(call install_gcc_lib,libunwind,$(UNWIND_SONAME),$(1),$(2))
+   )
 endef
 
 # do_gcc_devels(flavour)
diff -Nru old/gcc-6-6.4.0/debian/rules.defs new/gcc-6-6.4.0/debian/rules.defs
--- old/gcc-6-6.4.0/debian/rules.defs   2017-12-27 01:32:47.0 +0100
+++ new/gcc-6-6.4.0/debian/rules.defs   2017-12-27 00:51:30.727647629 +0100
@@ -1481,6 +1481,14 @@
 endif
   endif
 
+  # libunwind -
+  ifneq (,$(findstring ia64-linux,$(DEB_TARGET_GNU_TYPE)))
+with_unwind := no
+ifeq ($(DEB_CROSS)-$(with_shared_libgcc),yes-yes)
+  with_unwind := yes
+endif
+  endif
+
   # Shared libgcc 
   ifneq ($(DEB_STAGE),stage1)
 with_shared_libgcc := yes
diff -Nru old/gcc-6-6.4.0/debian/rules.sonames 
new/gcc-6-6.4.0/debian/rules.sonames
--- old/gcc-6-6.4.0/debian/rules.sonames2017-12-27 01:32:47.0 
+0100
+++ new/gcc-6-6.4.0/debian/rules.sonames2017-12-27 01:09:51.136178371 
+0100
@@ -38,6 +38,8 @@
echo TSAN_SONAME=$$v >> $$cache; \
v=`tail -1 $(srcdir)/libsanitizer/ubsan/libtool-version | cut -d: -f1`; 
\
echo UBSAN_SONAME=$$v >> $$cache; \
+   v=`tail -1 $(srcdir)/libunwind/unwind/libtool-version | cut -d: -f1`; \
+   echo UNWIND_SONAME=$$v >> $$cache; \
v=`awk -F= '/^libtool_VERSION/ {split($$2,v,":"); print v[1]}' \
$(srcdir)/libatomic/configure.ac`; \
 v=1; \
@@ -84,6 +86,7 @@
 LSAN_SONAME= $(call vafilt,$(SONAME_VARS),LSAN_SONAME)
 TSAN_SONAME= $(call vafilt,$(SONAME_VARS),TSAN_SONAME)
 UBSAN_SONAME   = $(call vafilt,$(SONAME_VARS),UBSAN_SONAME)
+UNWIND_SONAME  = $(call vafilt,$(SONAME_VARS),UNWIND_SONAME)
 VTV_SONAME = $(call vafilt,$(SONAME_VARS),VTV_SONAME)
 CILKRTS_SONAME = $(call vafilt,$(SONAME_VARS),CILKRTS_SONAME)
 QUADMATH_SONAME= $(call vafilt,$(SONAME_VARS),QUADMATH_SONAME)


Bug#826428: ITA: gcompris-qt -- Educational games for small children - Qt rewrite

2017-12-26 Thread Simon Quigley
Hello,

On 12/26/2017 02:21 AM, Sébastien Villemot wrote:
> On Mon, Dec 25, 2017 at 08:23:55PM -0600, Simon Quigley wrote:
> 
>> Tonight or tomorrow I'll get this ready for a review (I don't have
>> upload access to Debian so I'll need someone to review/sponsor).
> 
> Great! Just let me know when it’s ready, I’ll be happy to sponsor you.

Should be good now, could you please check it over?

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature


Bug#885427: lxc: Debian template hardcodes regular keyring even for -ports

2017-12-26 Thread Adam Borowski
Package: lxc
Version: 1:2.0.9-5
Severity: normal

Hi!
When trying to install a second class (ie, -ports) architecture, the Debian
template fails with:
[/srv/lxc]# lxc-create -t debian -B btrfs -n harad --dir /srv/lxc/harad -- -a 
x32 -r sid --packages=sysvinit-core,sysv-rc 
--mirror=http://apt.angband.pl:3142/ftp.debian-ports.org/debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-sid-x32 ... 
Downloading debian minimal ...
I: Retrieving InRelease 
I: Checking Release signature
E: Release signed by unknown key (key id 8BC3A7D46F930576)
Failed to download the rootfs, aborting.
Failed to download 'debian base'
failed to install debian
lxc-create: lxccontainer.c: create_run_template: 1427 container creation 
template for harad failed
lxc-create: tools/lxc_create.c: main: 326 Error creating container harad

This is somewhat expected, as debootstrap (being a low-level tool) doesn't
handle custom keyrings without being told
(--keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg).  However,
the Debian template:
* knows about keyrings, and has logic to pick and/or download one
* provides no way to override

Requiring the user to provide a path to the keyring would be acceptable.
If you'd want to be nice, though, it'd be good to detect if we're installing
one of -ports archs (Linux ones are: alpha hppa m68k powerpc powerpcspe
ppc64 sh4 sparc64 x32) and look for the keyring in
/usr/share/keyrings/debian-ports-archive-keyring.gpg.  It might be also good
to default the mirror to http://ftp.ports.debian.org/debian-ports/

(Note: to run x32 on an amd64 kernel, append syscall.x32=y to kernel's
cmdline and reboot -- CONFIG_X86_X32 is on in Debian kernels but is disabled
other than as a boot-time option.  Such kernels then work normally, exactly
same as i386 support on an amd64 kernel.)


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

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

Versions of packages lxc depends on:
ii  libapparmor1  2.11.1-4
ii  libc6 2.25-5
ii  libcap2   1:2.25-1.2
ii  libgnutls30   3.5.16-1
ii  liblxc1   1:2.0.9-5
ii  libseccomp2   2.3.1-2.1
ii  libselinux1   2.7-2
ii  lsb-base  9.20170808
ii  python3   3.6.4~rc1-2
ii  python3-lxc   1:2.0.9-5

Versions of packages lxc recommends:
ii  bridge-utils  1.5-14
ii  debootstrap   1.0.93
ii  dirmngr   2.2.3-1
pn  dnsmasq-base  
ii  gnupg 2.2.3-1
ii  iptables  1.6.1-2+b1
ii  libpam-cgfs   2.0.8-1
ii  lxcfs 2.0.8-1
ii  openssl   1.1.0g-2
ii  rsync 3.1.2-2.1
ii  uidmap1:4.5-1

Versions of packages lxc suggests:
pn  apparmor 
ii  btrfs-progs  4.13.3-1
pn  lvm2 

-- no debconf information



Bug#885426: Also made a Debian request on upstream's Github

2017-12-26 Thread 積丹尼 Dan Jacobson
I also made https://github.com/fyookball/electrum/issues/387 .



Bug#885426: Please also provide Bitcoin Cash version (fyookball)

2017-12-26 Thread 積丹尼 Dan Jacobson
Package: electrum
Version: 3.0.3-1
Severity: wishlist

Please also provide Bitcoin Cash package/version (fyookball).
https://github.com/fyookball/electrum
In fact some others are listed on
http://aurumbit.org/electrum.lzs/README .



Bug#732663: sparc & liblo

2017-12-26 Thread Steve Robbins
On Sunday, December 24, 2017 12:04:26 PM CST you wrote:
> Hi Steve,
> 
> Yes, liblo still (forcibly) fails on sparc. The failure is enforced in
> debian/rules 

Ah, thanks.  Now I see it :-)


> so I don't need a patch for it. So unfortunately you still
> need to avoid liblo in sparc/sparc64. Sorry.

Will do.
 
> Saludos
> 
> On Sun, Dec 24, 2017 at 12:51 AM, Steve Robbins  wrote:
> > Hello Felipe,
> > 
> > I'm unsure of the current state of liblo w.r.t. the SPARC architecture. 
> > At
> > one point -- see below -- it was forcibly failing.  But latest changelog
> > (0.29-1) reads "drop all debian packages".  So I presume the forced
> > failure is
> > gone?   Does liblo work now or do I still need to do something with
> > nyquist --
> > a user of liblo.
> > 
> > Thanks,
> > -Stev
> > 
> > On Thursday, December 19, 2013 10:13:21 PM CST you wrote:
> > > Dear maintainers of liblo-reverse dependencies, I forward you the mail
> > > in which I request the removal of liblo in sparc. If your package can
> > > opt out of using liblo and you want to support sparc, please drop the
> > > dependency there, as liblo will no longer be available in that
> > > architecture. Otherwise, your package will have to be removed from
> > > sparc.
> > > 
> > > Thanks
> > > 
> > > 
> > > 732386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732386
> > > 
> > > 
> > > -- Forwarded message --
> > > From: Felipe Sateler 
> > > Date: Tue, Dec 17, 2013 at 10:49 AM
> > > Subject: Bug#732386: RM: liblo [sparc] -- ANAIS; Does not work, never
> > > has
> > > To: Debian Bug Tracking System 
> > > 
> > > 
> > > Package: ftp.debian.org
> > > Severity: normal
> > > 
> > > liblo (all binaries) needs to be removed from sparc. I doesn't work, and
> > > never has. Please see bug #721617 for details (TLDR; unaligned access
> > > and SIGBUS). Upstream may or may not fix the issue eventually.
> > > 
> > > I have just uploaded a version (0.26~repack-8) that purposely fails on
> > > sparc and sparc64, so that it doesn't build again.



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


Bug#885425: software-properties-common: add-apt-repository edits all existing source files, reformatting them

2017-12-26 Thread Julian Andres Klode
Control: severity -1 wishlist
Control: reassign -1 python3-apt
Control: tag -1 wontfix

On Wed, Dec 27, 2017 at 12:34:04AM +0100, AG wrote:
> Package: software-properties-common
> Version: 0.96.20.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> the helper tool
> add-apt-repository
> modifies all existing source files
> sources.list
> sources.list.d/*
> reformatting the comments unnecessarily.
> 
> Example of the change:
> 
> -#deb [arch=amd64,i386] http://ftp.de.debian.org/debian/ unstable main 
> contrib non-free
> +# deb [arch=amd64,i386] http://ftp.de.debian.org/debian/ unstable main 
> contrib non-free
> 
> 
> I do expect a "Debian" tool to perform the requested task minimally, and not
> to unexpectedly touch all available files in a folder.
> The repository i requested to add was actually added at the very end of
> sources.list.

Well, it's not that easy. And this is a minor cosmetic difference you
have to live with - I'm not going to risk stuff by playing with the
algorithms there. It's fragile enough already :(

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#885425: software-properties-common: add-apt-repository edits all existing source files, reformatting them

2017-12-26 Thread AG
Package: software-properties-common
Version: 0.96.20.2-1
Severity: normal

Dear Maintainer,

the helper tool
add-apt-repository
modifies all existing source files
sources.list
sources.list.d/*
reformatting the comments unnecessarily.

Example of the change:

-#deb [arch=amd64,i386] http://ftp.de.debian.org/debian/ unstable main contrib 
non-free
+# deb [arch=amd64,i386] http://ftp.de.debian.org/debian/ unstable main contrib 
non-free


I do expect a "Debian" tool to perform the requested task minimally, and not
to unexpectedly touch all available files in a folder.
The repository i requested to add was actually added at the very end of
sources.list.

The tool should either add a new file in sources.list.d, or add a line in
sources.list, even better ask/prompt the user.

Thanks!


-- System Information:
Debian Release: 9.3
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages software-properties-common depends on:
ii  ca-certificates  20161130+nmu1
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-packagekitglib-1.01.1.5-2
ii  python-apt-common1.4.0~beta3
ii  python3  3.5.3-1
ii  python3-dbus 1.2.4-1+b1
ii  python3-gi   3.22.0-2
ii  python3-software-properties  0.96.20.2-1

Versions of packages software-properties-common recommends:
ii  packagekit  1.1.5-2

software-properties-common suggests no packages.

-- debconf-show failed



Bug#879811: psi-translations: update to version 1.3

2017-12-26 Thread Boris Pek
Hi Jan,

> On Thu, Oct 26, 2017 at 11:59:57AM +0300, Boris Pek wrote:
>>  Please update package src:psi-translations to version 1.3 and keep it in 
>> sync
>>  with src:psi package.
>
> Definitely a good idea, yes!
>
> Unfortunately, I currently don't have much spare time, so it may take
> some time.
>
>>  Localization files:
>>  https://github.com/psi-im/psi-l10n
>>
>>  Example of packaging rules:
>>  https://github.com/tehnick/psi-plus-l10n-debian
>
> Thanks for the pointers, those will be very useful for updating the
> package.

It looks that you do not have enough free time to maintain this package.

How about maintaining of src:psi and src:psi-translations packages under
umbrella of Debian XMPP Maintainers team [1] using git repos [2] at Salsa [3]?

In this case I would prepare a team upload for updating of src:psi-translations.

[1] https://wiki.debian.org/Teams/pkg-xmpp
[2] https://salsa.debian.org/xmpp-team
[3] https://wiki.debian.org/Salsa/Doc

Best regards,
Boris



Bug#885424: global: gtags call with pygments program fails

2017-12-26 Thread Pierre-Elliott Bécue
Package: global
Version: 6.5.7-4
Severity: important

Dear maintainer,

I discovered that new release of global was available into Debian, yay!

I installed it and gave it a try on my laptop, and…

.-(0:11:25)-(~/git/crans/cldap)---(git)-[cldap/wip_peb]-(becue@dawaj)-
`---> gtags -v --skip-unreadable
[Wed Dec 27 00:11:28 CET 2017] Gtags started.
 Using configuration file '/home/becue/.globalrc'.
 Using configuration label 'default'.
 Using plug-in parser.
[Wed Dec 27 00:11:28 CET 2017] Creating 'GTAGS' and 'GRTAGS'.
 [1] extracting tags of htmlcov/coverage_html.js
gtags: execvp failed.
gtags: unexpected EOF.

:(

I started to investigate in my .globalrc:

#
# Copyright (c) 1998, 1999, 2000, 2001, 2002, 2003, 2010, 2011, 2013,
#   2015, 2016
#   Tama Communications Corporation
#
# This file is part of GNU GLOBAL.
#
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# *
# Configuration file for GNU GLOBAL source code tag system.
#
# Basically, GLOBAL doesn't need this file ('gtags.conf'), because it has
# default values in itsself. If you have the file as '/etc/gtags.conf' or
# "$HOME/.globalrc" in your system then GLOBAL overwrite the default values
# with the values in the file.
#
# The format is similar to termcap(5). You can specify a target with
# GTAGSLABEL environment variable. Default target is 'default'.
#
# If you want to have a common record for yourself, it is recommended to
# use the following method:
#
# default:\
#   :tc=default@~/.globalrc:\   <= Load the default record from 
~/.globalrc.
#   :tc=native:
#
default:\
:tc=pygments:
native:\
:tc=gtags:tc=htags:
user:\
:tc=user-custom:tc=htags:
ctags:\
:tc=exuberant-ctags:tc=htags:
new-ctags:\
:tc=universal-ctags:tc=htags:
pygments:\
:tc=pygments-parser:tc=htags:
#-
# Configuration for gtags(1)
# See gtags(1).
#-
common:\

:skip=HTML/,HTML.pub/,tags,TAGS,ID,y.tab.c,y.tab.h,gtags.files,cscope.files,cscope.out,cscope.po.out,cscope.in.out,SCCS/,RCS/,CVS/,CVSROOT/,{arch}/,autom4te.cache/,*.orig,*.rej,*.bak,*~,#*#,*.swp,*.tmp,*_flymake.*,*_flymake,*.o,*.a,*.so,*.lo,*.zip,*.gz,*.bz2,*.xz,*.lzh,*.Z,*.tgz,*.min.js,*min.css:
#
# Built-in parsers.
#
gtags:\
:tc=common:\
:tc=builtin-parser:
builtin-parser:\

:langmap=c\:.c.h,yacc\:.y,asm\:.s.S,java\:.java,cpp\:.c++.cc.hh.cpp.cxx.hxx.hpp.C.H,php\:.php.php3.phtml:
#
# skeleton for user's custom parser.
#
user-custom|User custom plugin parser:\
:tc=common:\
:langmap=c\:.c.h:\
:gtags_parser=c\:$libdir/gtags/user-custom.la:
#
# Plug-in parser to use Exuberant Ctags.
#
exuberant-ctags|plugin-example|setting to use Exuberant Ctags plug-in parser:\
:tc=common:\
:ctagscom=/usr/bin/ctags:\
:ctagslib=$libdir/gtags/exuberant-ctags.la:\
:tc=common-ctags-maps:
#
# A common map for both Exuberant Ctags and Universal Ctags.
# Don't include definitions of ctagscom and ctagslib in this entry.
#
common-ctags-maps:\
# Ant  *.build.xml  (out of support)
# Asm  *.[68][68][kKsSxX] *.[xX][68][68](out of support)
:langmap=Asm\:.asm.ASM.s.S.A51.29k.29K:\
:langmap=Asp\:.asp.asa:\
:langmap=Awk\:.awk.gawk.mawk:\
:langmap=Basic\:.bas.bi.bb.pb:\
:langmap=BETA\:.bet:\
:langmap=C\:.c:\
:langmap=C++\:.c++.cc.cp.cpp.cxx.h.h++.hh.hp.hpp.hxx:\
:langmap=C#\:.cs:\
:langmap=Cobol\:.cbl.cob.CBL.COB:\
:langmap=DosBatch\:.bat.cmd:\
:langmap=Eiffel\:.e:\
:langmap=Erlang\:.erl.ERL.hrl.HRL:\
:langmap=Flex\:.as.mxml:\
:langmap=Fortran\:.f.for.ftn.f77.f90.f95:\
:langmap=HTML\:.htm.html:\
:langmap=Java\:.java:\
:langmap=JavaScript\:.js:\
:langmap=Lisp\:.cl.clisp.el.l.lisp.lsp:\
:langmap=Lua\:.lua:\
# Make  [Mm]akefile GNUmakefile (out of support)
:langmap=Make\:.mak.mk:\
:langmap=MatLab\:.m:\
:langmap=OCaml\:.ml.mli:\
:langmap=Pascal\:.p.pas:\
:langmap=Perl\:.pl.pm.plx.perl:\
:langmap=PHP\:.php.php3.phtml:\
:langmap=Python\:.py.pyx.pxd.pxi.scons:\
:langmap=REXX\:.cmd.rexx.rx:\
:langmap=Ruby\:.rb.ruby:\
:langmap=Scheme\:.SCM.SM.sch.scheme.scm.sm:\
:langmap=Sh\:.sh.SH.bsh.bash.ksh.zsh:\
:langmap=SLang\:.sl:\
:langmap=SML\:.sml.sig:\
:langmap=SQL\:.sql:\
:langmap=Tcl\:.tcl.tk.wish.

Bug#885415: vlc: When jumping to another position in a video there is no sound for several (5+) seconds

2017-12-26 Thread Svein Engelsgjerd

Sebastian Ramacher wrote:

Control: tags -1 + moreinfo

On 2017-12-26 22:04:24, Svein Engelsgjerd wrote:

Package: src:vlc
Version: 3.0.0~rc2-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I upgraded from VLC 2.x to 3.0

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

I did nothing other than upgrading VLC

   * What was the outcome of this action?

Now when I change position in a video all sound is paused for many seconds 
before resuming.
Typically more than 5 seconds always

   * What outcome did you expect instead?

I expected VLC 3.0 to be no worse than 2.x

Other information:
Recently pulseaudio enabled systemd socket activation which appears to have 
introduced a small millisecond delay globally for all audio.
Perhaps this could have something to do with it , just mentioning it to be on 
the safe side.


Please include vlc's log output (vlc -vvv) as when this happens. And if I read
the conversation in #videolan correctly, you were asked to file this bug report
in the vlc's bug tracker: https://trac.videolan.org/vlc



ii  libdca0  0.0.5-dmo2


Please replace all dmo versions with the ones provided by Debian and try again.
We do not support any mixtures of dmo and Debian packages.

Cheers
Ok I'll do an upgrade later and try again. Right now I would like to NOT 
upgrade all packages as kernel 4.14 might break BTRFS filesystem which I 
use for rootfs on this machine. I'll try upgrading in a week or three 
and (if I remember it) update this bug then.


Thanks




ii  libdvbpsi10  1.3.1-2
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.5-2
ii  libfaad2 2.8.8-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-0.1
ii  libfribidi0  0.19.7-2
ii  libgcc1  1:7.2.0-18
ii  libgcrypt20  1.8.1-4
ii  libglib2.0-0 2.54.1-1
ii  libgnutls30  3.5.16-1
ii  libgpg-error01.27-5
ii  libgroupsock82017.10.28-2
ii  libharfbuzz0b1.6.2-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.10.0-2+b1
ii  liblivemedia61   2017.10.28-2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8.1
ii  libmatroska6v5   1.4.8-1.1
ii  libmicrodns0 0.0.8-1
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-8
ii  libmpg123-0  1.25.8-1
ii  libmtp9  1.1.13-1
ii  libncursesw5 6.0+20171125-1
ii  libnfs8  1.11.0-2
ii  libogg0  1.3.2-1+b1
ii  libopenmpt-modplug1  0.3.4-1
ii  libopus0 1.2.1-1
ii  libpng16-16  1.6.34-1
ii  libpostproc547:3.4.1-1
ii  libprotobuf-lite10   3.0.0-9.1
ii  libpulse011.1-4
ii  libraw1394-112.1.2-1+b1
ii  libresid-builder0c2a 2.1.1-15
ii  librsvg2-2   2.40.18-2
ii  libsamplerate0   0.1.9-1
ii  libsdl-image1.2  1.2.12-7
ii  libsdl1.2debian  1.2.15+dfsg2-0.1
ii  libsecret-1-00.18.5-5
ii  libshine33.1.1-1
ii  libshout32.4.1-2
ii  libsidplay2  2.1.1-15
ii  libsndio6.1  1.1.0-3
ii  libsoxr0 0.1.2-3
ii  libspeex11.2~rc1.2-1+b2
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libssh2-11.8.0-1
ii  libstdc++6   7.2.0-18
ii  libswscale4  7:3.4.1-1
ii  libsystemd0  236-1
ii  libtag1v51.11.1+dfsg.1-0.2
ii  libtheora0   1.1.1+dfsg.1-14+b1
ii  libtinfo56.0+20171125-1
ii  libtwolame0  0.3.13-3
ii  libudev1 236-1
ii  libupnp6 1:1.6.24-2
ii  libusageenvironment3 2017.10.28-2
ii  libva-drm2   2.0.0-2
ii  libva2   2.0.0-2
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.0~rc2-2
ii  libvorb

Bug#885249: yoshimi: FTBFS on hurd-i386: PATH_MAX undeclared

2017-12-26 Thread Svante Signell
tags 885289 patch
thanks

On Mon, 2017-12-25 at 22:49 -0500, Aaron M. Ucko wrote:
> Source: yoshimi
> Version: 1.5.6-2
> Severity: important
> Tags: upstream
> Justification: fails to build from source
> User: debian-h...@lists.debian.org
> Usertags: hurd-i386

> The Hurd notoriously has no static PATH_MAX.  Best practice is to
> accommodate whatever you actually encounter (with the help of, e.g.,
> the GNU libc extension get_current_dir_name); alternatively, you can
> look up _PC_PATH_MAX via pathconf or supply a fallback constant
> (traditionally 4096).
> 
> Could you please take a look?

Hi,

Attached is a patch fixing the PATH_MAX issues of the package yoshimi
1.5.6-2.

Thanks!

Index: yoshimi-1.5.6/src/Misc/Config.cpp
===
--- yoshimi-1.5.6.orig/src/Misc/Config.cpp
+++ yoshimi-1.5.6/src/Misc/Config.cpp
@@ -231,17 +231,16 @@ bool Config::Setup(int argc, char **argv
 }
 if (restoreState)
 {
-char * fp;
+char *fp = NULL;
 if (! StateFile.size()) goto no_state0;
-else fp = new char [PATH_MAX];
+fp = realpath (StateFile.c_str(), NULL);
+if (fp == NULL) goto no_state0;
 
-if (! realpath (StateFile.c_str(), fp)) goto no_state1;
 StateFile = fp;
-delete (fp);
+free (fp);
 
 if (! isRegFile(StateFile))
 {
-no_state1: delete (fp);
 no_state0: Log("Invalid state file specified for restore " + StateFile, 2);
 return true;
 }
Index: yoshimi-1.5.6/src/Misc/MiscFuncs.cpp
===
--- yoshimi-1.5.6.orig/src/Misc/MiscFuncs.cpp
+++ yoshimi-1.5.6/src/Misc/MiscFuncs.cpp
@@ -339,9 +339,9 @@ string MiscFuncs::setExtension(string fn
 // replace 'src' with a different one in the compilation directory
 string MiscFuncs::localPath(string leaf)
 {
-char *tmpath;
-tmpath = (char*) malloc(PATH_MAX);
-getcwd (tmpath, PATH_MAX);
+char *tmpath = getcwd (NULL, 0);
+if (tmpath == NULL)
+   return "";
 string path = (string) tmpath;
 size_t found = path.rfind("/src");
 if (found != string::npos)


Bug#885223: cups-filters: conffiles not removed

2017-12-26 Thread Sven Joachim
Control: reopen -1

On 2017-12-26 12:40 +0100, Didier 'OdyX' Raboud wrote:

> Control: tags -1 +pending
>
> Le mardi, 26 décembre 2017, 09.54:49 h CET Paul Wise a écrit :
>> The recent upgrade did not deal with obsolete conffiles properly.
>> Please use the dpkg-maintscript-helper support provided by
>> dh_installdeb to remove these obsolete conffiles on upgrade.
>
> Oh, good catch, thanks!

Unfortunately the version passed to dpkg-maintscript-helper is too low,
and the obsolete conffile still remains when upgrading from 1.18.0-1 to
1.18.0-2.  Please bump that version to 1.18.0-3~ on your next upload.
See dpkg-maintscript-helper's manpage:

,
|   If  the conffile has not been shipped for several versions,
|   and you are now modifying the maintainer scripts  to  clean
|   up  the obsolete file, prior-version should be based on the
|   version of the package that you are now preparing, not  the
|   first version of the package that lacked the conffile. This
|   applies to all other actions in the same way.
`

Cheers,
   Sven



Bug#885423: Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)

2017-12-26 Thread Achim Schaefer
Package: beignet-opencl-icd
Version: 1.3.2-1
Severity: important

Dear Maintainer,

when starting darktable I always get this message:
darktable
Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)
This can usually be fixed by upgrading Linux to >= 4.2,
see /usr/share/doc/beignet-dev/Beignet.html or 
https://www.freedesktop.org/wiki/Software/Beignet/
Beignet: disabling non-working device

I'm curently running :
4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) x86_64 GNU/Linux

Thanks



-- Package-specific info:
Graphics hardware:
Providers: number : 1
Provider 0: id: 0x47 cap: 0xf, Source Output, Sink Output, Source Offload, Sink 
Offload crtcs: 3 outputs: 5 associated providers: 0 name:modesetting
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Extended renderer info (GLX_MESA_query_renderer):
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop 
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th 
Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)

Processor:
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   60
Model name:  Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Stepping:3
CPU MHz: 2993.294
CPU max MHz: 3600.
CPU min MHz: 800.
BogoMIPS:5986.58
Virtualization:  VT-x
L1d cache:   32K
L1i cache:   32K
L2 cache:256K
L3 cache:6144K
NUMA node0 CPU(s):   0-3
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes 
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb tpr_shadow vnmi flexpriority 
ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt 
dtherm ida arat pln pts

OpenCL library:
un  libopencl-1.1-1 
un  libopencl-1.2-1 
un  libopencl-2.0-1 
un  libopencl-2.1-1 
un  libopencl1  
un  nvidia-libopencl1-dev   
ii  ocl-icd-libopencl1:amd642.2.12-1
ii  ocl-icd-libopencl1:i386 2.2.12-1
ii  beignet-opencl-icd:amd641.3.2-1
un  opencl-icd  
/usr/lib/x86_64-linux-gnu/beignet//libcl.so

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

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

Versions of packages beignet-opencl-icd depends on:
ii  libc6  2.25-5
ii  libdrm-intel1  2.4.89-1
ii  libdrm22.4.89-1
ii  libegl11.0.0-1
ii  libgcc11:7.2.0-18
ii  libgl1 1.0.0-1
ii  libstdc++6 7.2.0-18
ii  libtinfo5  6.0+20171125-1
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  zlib1g 1:1.2.8.dfsg-5

beignet-opencl-icd recommends no packages.

beignet-opencl-icd suggests no packages.

-- no debconf information



Bug#885422: cabal-install: Missing C libraries

2017-12-26 Thread Frederic-Emmanuel Picca
Package: cabal-install
Version: 1.24.0.1-3
Severity: normal

Dear Maintainer,

I tryed to build a projet with cabal on stretch.
That think was working on jessie but now, I get an error
 message like this during the configuration.

:~/hkl/contrib/haskell$ cabal configure
Resolving dependencies...
Configuring hkl-0.1.0.0...
cabal: Missing dependencies on foreign libraries:
* Missing C libraries: hkl, gsl
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.

the dependency is defined via pkgconfig-depends: hkl

Indeed the C library was installed with the libhkl-dev package and it was 
working on jessie.

thanks for your help

Frederic

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

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

Versions of packages cabal-install depends on:
ii  ghc [libghc-cabal-dev]  8.0.1-17+b1
ii  libc6   2.24-11+deb9u1
ii  libffi6 3.2.1-6
ii  libgmp102:6.1.2+dfsg-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages cabal-install recommends:
ii  ghc  8.0.1-17+b1

cabal-install suggests no packages.

-- no debconf information



Bug#885421: RFS: webalizer/2.23.08-3

2017-12-26 Thread Julien Viard de Galbert
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 Package name: webalizer
 Version : 2.23.08-3
 Upstream Author : Bradford L. Barrett
 URL : http://www.mrunix.net/webalizer/
 License : GPL-2+
 Section : web

It builds those binary packages:

  webalizer  - web server log analysis program

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/webalizer/webalizer_2.23.08-3.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

   * Update debhelper to compat level 10 (remove explicit use of autoreconf as
 it's now the default).
   * Fix an error in Vcs field introduced while switching URLs to https
   * Updated Policy to 4.1.2 without changes.
   * Change dependency from libgd2-dev to libgd-dev. (Closes: #880783)
   * Debconf translation:
 - Russian, thanks Lev Lamberov. (Closes: #883914)
 - Portuguese. (Closes: #870528)
 - French, thanks Alban Vidal. (Closes: #873685).

Regards,
 Julien Viard de Galbert



Bug#878106: w3m: Typo in --help message: "ACII" should be "ASCII"

2017-12-26 Thread Tatsuya Kinoshita
Control: tags -1 + pending

On October 9, 2017 at 10:55PM +0200, abe (at debian.org) wrote:
> Package: w3m
> Version: 0.5.3-34
> Severity: minor
> Tags: upstream
>
> "w3m --help" shows this line among other lines:
>
> -no-graphuse ACII character for border of table and menu
>
> "ACII" is surely a typo and should be "ASCII".

Fixed in the Git repo.

  - 
https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=1fd08f383d99e9ffe32f3a336623ceb086eb36b8

Thanks,
--
Tatsuya Kinoshita


pgp6s5YitFkOh.pgp
Description: PGP signature


Bug#885415: vlc: When jumping to another position in a video there is no sound for several (5+) seconds

2017-12-26 Thread Sebastian Ramacher
Control: tags -1 + moreinfo

On 2017-12-26 22:04:24, Svein Engelsgjerd wrote:
> Package: src:vlc
> Version: 3.0.0~rc2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I upgraded from VLC 2.x to 3.0
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I did nothing other than upgrading VLC
> 
>* What was the outcome of this action?
> 
> Now when I change position in a video all sound is paused for many seconds 
> before resuming.
> Typically more than 5 seconds always
> 
>* What outcome did you expect instead?
> 
> I expected VLC 3.0 to be no worse than 2.x
> 
> Other information:
> Recently pulseaudio enabled systemd socket activation which appears to have 
> introduced a small millisecond delay globally for all audio.
> Perhaps this could have something to do with it , just mentioning it to be on 
> the safe side.

Please include vlc's log output (vlc -vvv) as when this happens. And if I read
the conversation in #videolan correctly, you were asked to file this bug report
in the vlc's bug tracker: https://trac.videolan.org/vlc


> ii  libdca0  0.0.5-dmo2

Please replace all dmo versions with the ones provided by Debian and try again.
We do not support any mixtures of dmo and Debian packages.

Cheers

> ii  libdvbpsi10  1.3.1-2
> ii  libdvdnav4   5.0.3-3
> ii  libdvdread4  5.0.3-2
> ii  libebml4v5   1.3.5-2
> ii  libfaad2 2.8.8-1
> ii  libflac8 1.3.2-1
> ii  libfontconfig1   2.12.6-0.1
> ii  libfreetype6 2.8.1-0.1
> ii  libfribidi0  0.19.7-2
> ii  libgcc1  1:7.2.0-18
> ii  libgcrypt20  1.8.1-4
> ii  libglib2.0-0 2.54.1-1
> ii  libgnutls30  3.5.16-1
> ii  libgpg-error01.27-5
> ii  libgroupsock82017.10.28-2
> ii  libharfbuzz0b1.6.2-1
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libkate1 0.4.1-7+b1
> ii  liblirc-client0  0.10.0-2+b1
> ii  liblivemedia61   2017.10.28-2
> ii  liblua5.2-0  5.2.4-1.1+b2
> ii  libmad0  0.15.1b-8.1
> ii  libmatroska6v5   1.4.8-1.1
> ii  libmicrodns0 0.0.8-1
> ii  libmpcdec6   2:0.1~r495-1+b1
> ii  libmpeg2-4   0.5.1-8
> ii  libmpg123-0  1.25.8-1
> ii  libmtp9  1.1.13-1
> ii  libncursesw5 6.0+20171125-1
> ii  libnfs8  1.11.0-2
> ii  libogg0  1.3.2-1+b1
> ii  libopenmpt-modplug1  0.3.4-1
> ii  libopus0 1.2.1-1
> ii  libpng16-16  1.6.34-1
> ii  libpostproc547:3.4.1-1
> ii  libprotobuf-lite10   3.0.0-9.1
> ii  libpulse011.1-4
> ii  libraw1394-112.1.2-1+b1
> ii  libresid-builder0c2a 2.1.1-15
> ii  librsvg2-2   2.40.18-2
> ii  libsamplerate0   0.1.9-1
> ii  libsdl-image1.2  1.2.12-7
> ii  libsdl1.2debian  1.2.15+dfsg2-0.1
> ii  libsecret-1-00.18.5-5
> ii  libshine33.1.1-1
> ii  libshout32.4.1-2
> ii  libsidplay2  2.1.1-15
> ii  libsndio6.1  1.1.0-3
> ii  libsoxr0 0.1.2-3
> ii  libspeex11.2~rc1.2-1+b2
> ii  libspeexdsp1 1.2~rc1.2-1+b2
> ii  libssh2-11.8.0-1
> ii  libstdc++6   7.2.0-18
> ii  libswscale4  7:3.4.1-1
> ii  libsystemd0  236-1
> ii  libtag1v51.11.1+dfsg.1-0.2
> ii  libtheora0   1.1.1+dfsg.1-14+b1
> ii  libtinfo56.0+20171125-1
> ii  libtwolame0  0.3.13-3
> ii  libudev1 236-1
> ii  libupnp6 1:1.6.24-2
> ii  libusageenvironment3 2017.10.28-2
> ii  libva-drm2   2.0.0-2
> ii  libva2   2.0.0-2
> ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.0~rc2-2
> ii  libvorbis0a  1.3.5-4
> ii  libvorbisenc21.3.5-4
> ii  libx264-148

Bug#880014: #880014: Call for Votes for new TC member

2017-12-26 Thread David Bremner
Didier 'OdyX' Raboud  writes:

> I call for votes on the following ballot to fill a vacant seat in the TC. The 
> voting period starts immediately and lasts for up to one week, or until the 
> outcome is no longer in doubt (§6.3.1).
>
> ===BEGIN
> The Technical Committee recommends that Gunnar Wolf  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> G: Recommend to Appoint Gunnar Wolf 
> F: Further Discussion
> ===END

I vote G > F

yay alphabetical order ;).


signature.asc
Description: PGP signature


Bug#885419: Additional info

2017-12-26 Thread Yetoo Happy
I have looked for this issue on the unstable release and it exists there.


Bug#601455: Steps towards a patch to document disabling a daemon upon installation

2017-12-26 Thread Andreas Henriksson
Hi,

On Mon, Dec 25, 2017 at 06:27:21PM -0800, Russ Allbery wrote:
> Ian Jackson  writes:
> > Sean Whitton writes:
> 
> >> 2. Do we need to include any text saying *why* the /etc/default practice
> >>is a bad idea?  I couldn't come up with a succinct way to state it.
> >>In general, I think we can err on the side of not including the text,
> >>since we have policy bugs that document the reasons.
> 
> > How about this text:
> 
> >   Setting a value in /etc/default/PACKAGE is nowadays troublesome
> >   because supporting that pattern is very hard due to inflexibility in
> >   systemd, which is usually the default init system.

I don't find anything about the above text to be true.

> 
> > This also makes it clear that this pattern is perfectly fine if for
> > any reason the package does not support systemd.
> 
> I don't really agree with this -- I've disliked this approach (and there
> were debian-devel threads against it) from long before systemd was
> written.  The explanation I'd give is that:

While I have several other things I find bad about the /etc/default/foo
anti-pattern I think the below text is short and clear that it should
serve well as one warning against it, thus...

> 
> Setting a flag in /etc/default/PACKAGE hides from the init system
> whether or not the daemon should actually be started, which leads to
> inconsistent and confusing behavior: ``service  start`` may
> return success but not start the service, services with a dependency
> on this service will be started even though the service isn't running,
> and init system status commands may incorrectly claim that the service
> was started.

Seconded.

Regards,
Andreas Henriksson



Bug#885420: transition: suitesparse

2017-12-26 Thread Sébastien Villemot
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-suitesparse.html

Dear Release Team,

Please schedule a transition for suitesparse. Only one library had an SONAME
bump, and actually there was no ABI change, so the transition should be
straightforward. I am in touch with upstream, who hopefully will avoid such
unneeded SONAME bumps in the future.

Thanks,


Ben file:

title = "suitesparse";
is_affected = .depends ~ "libsuitesparseconfig4" | .depends ~ 
"libsuitesparseconfig5";
is_good = .depends ~ "libsuitesparseconfig5";
is_bad = .depends ~ "libsuitesparseconfig4";

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


signature.asc
Description: PGP signature


Bug#885086: stretch-pu: package kildclient/3.1.0-1+deb9u1

2017-12-26 Thread Eduardo M KALINOWSKI
Control: tags -1 -moreinfo

On 23-12-2017 16:08, Adam D. Barratt wrote:
> On Sat, 2017-12-23 at 15:56 -0200, Eduardo M Kalinowski wrote:
>> I'd like to upload an update to kildclient to fix
>> bug #885007 / CVE-2017-17511:
> The BTS and Security Tracker metadata for that issue suggest that it
> affects the version of kildlcient in unstable and is not yet fixed
> there - is that correct? If so, please fix the package in unstable
> first and let us know once that's done.

A new upstream version has been uploaded to unstable, fixing this (and a
couple other things).

For the stretch (and jessie) uploads, the only changes are related to
CVE in question.


-- 
O dinheiro não traz a felicidade daquele que não o possui.
-- Boris Vian

Eduardo M KALINOWSKI
edua...@kalinowski.com.br



Bug#860766: gimp: diff for NMU version 2.8.20-1.1

2017-12-26 Thread Salvatore Bonaccorso
Control: tags 860766 + patch
Control: tags 860766 + pending
Control: tags 884836 + pending
Control: tags 884837 + patch
Control: tags 884837 + pending
Control: tags 884862 + patch
Control: tags 884862 + pending
Control: tags 884925 + pending
Control: tags 884927 + pending
Control: tags 885347 + pending

Hi Ari,

I've prepared an NMU for gimp (versioned as 2.8.20-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru gimp-2.8.20/debian/changelog gimp-2.8.20/debian/changelog
--- gimp-2.8.20/debian/changelog	2017-03-04 22:15:02.0 +0100
+++ gimp-2.8.20/debian/changelog	2017-12-26 22:11:46.0 +0100
@@ -1,3 +1,24 @@
+gimp (2.8.20-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Ari Pollak ]
+  * Move gimp to Enhances on gimp-data instead of Recommends (Closes: #860766)
+
+  [ Salvatore Bonaccorso ]
+  * Out of bounds read / heap overflow in TGA importer (CVE-2017-17786)
+(Closes: #884862)
+  * plug-ins: TGA 16-bit RGB (without alpha bit) is also valid
+  * Heap buffer overflow in PSP importer (CVE-2017-17789) (Closes: #884837)
+  * heap overread in gbr parser / load_image (CVE-2017-17784)
+(Closes: #884925)
+  * heap overread in psp importer (CVE-2017-17787) (Closes: #884927)
+  * Heap overflow while parsing FLI files (CVE-2017-17785) (Closes: #884836)
+  * buffer overread in XCF parser if version field has no null terminator
+(CVE-2017-17788) (Closes: #885347)
+
+ -- Salvatore Bonaccorso   Tue, 26 Dec 2017 22:11:46 +0100
+
 gimp (2.8.20-1) unstable; urgency=low
 
   * New upstream version 2.8.20
diff -Nru gimp-2.8.20/debian/control gimp-2.8.20/debian/control
--- gimp-2.8.20/debian/control	2016-09-12 00:27:25.0 +0200
+++ gimp-2.8.20/debian/control	2017-12-26 22:11:46.0 +0100
@@ -109,7 +109,7 @@
 
 Package: gimp-data
 Architecture: all
-Recommends: gimp
+Enhances: gimp
 Depends: ${misc:Depends}
 Conflicts: gimp (<< 2.4.0~rc2-2),
gimp-python (<< 2.6.0)
diff -Nru gimp-2.8.20/debian/patches/790783-buffer-overread-in-XCF-parser-if-version-fiel.patch gimp-2.8.20/debian/patches/790783-buffer-overread-in-XCF-parser-if-version-fiel.patch
--- gimp-2.8.20/debian/patches/790783-buffer-overread-in-XCF-parser-if-version-fiel.patch	1970-01-01 01:00:00.0 +0100
+++ gimp-2.8.20/debian/patches/790783-buffer-overread-in-XCF-parser-if-version-fiel.patch	2017-12-26 22:11:46.0 +0100
@@ -0,0 +1,29 @@
+From: Hanno Boeck 
+Date: Mon, 27 Nov 2017 00:37:29 +0100
+Subject: 790783 - buffer overread in XCF parser if version field...
+Origin: https://git.gnome.org/browse/GIMP/commit/?id=702c4227e8b6169f781e4bb5ae4b5733f51ab126
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-17788
+Bug-Debian: https://bugs.debian.org/885347
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=790783
+
+...has no null terminator
+
+Check for the presence of '\0' before using atoi() on the version
+string. Patch slightly modified (mitch).
+[carnil: backport to gimp-2-8: affected code in xcf_load_invoker]
+---
+ app/xcf/xcf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/app/xcf/xcf.c
 b/app/xcf/xcf.c
+@@ -318,7 +318,8 @@ xcf_load_invoker (GimpProcedure  *pr
+ {
+   info.file_version = 0;
+ }
+-  else if (id[9] == 'v')
++  else if (id[9]  == 'v' &&
++   id[13] == '\0')
+ {
+   info.file_version = atoi (id + 10);
+ }
diff -Nru gimp-2.8.20/debian/patches/Bug-739133-CVE-2017-17785-Heap-overflow-while-parsin.patch gimp-2.8.20/debian/patches/Bug-739133-CVE-2017-17785-Heap-overflow-while-parsin.patch
--- gimp-2.8.20/debian/patches/Bug-739133-CVE-2017-17785-Heap-overflow-while-parsin.patch	1970-01-01 01:00:00.0 +0100
+++ gimp-2.8.20/debian/patches/Bug-739133-CVE-2017-17785-Heap-overflow-while-parsin.patch	2017-12-26 22:11:46.0 +0100
@@ -0,0 +1,164 @@
+From: Tobias Stoeckmann 
+Date: Sun, 29 Oct 2017 15:19:41 +0100
+Subject: Bug 739133 - (CVE-2017-17785) Heap overflow while parsing FLI files.
+Origin: https://git.gnome.org/browse/GIMP/commit/?id=1882bac996a20ab5c15c42b0c5e8f49033a1af54
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-17785
+Bug-Debian: https://bugs.debian.org/884836
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=739133
+
+It is possible to trigger a heap overflow while parsing FLI files. The
+RLE decoder is vulnerable to out of boundary writes due to lack of
+boundary checks.
+
+The variable "framebuf" points to a memory area which was allocated
+with fli_header->width * fli_header->height bytes. The RLE decoder
+therefore must never write beyond that limit.
+
+If an illegal frame is detected, the parser won't stop, which means
+that the next valid sequence is properly parsed again. This should
+allow GIMP to parse FLI files as good as possible even if they are
+broken by an attacker or by accident.
+
+While at it, I changed the variable xc t

Bug#885298: gquilt: Depends on unmaintained pygtk

2017-12-26 Thread Peter Williams
I lost interest in maintaining gquilt when I created darning 
(https://github.com/pwil3058/darning) and stopped using quilt.  I do not 
intend to do any more work on gquilt so if you wish to continue using it 
you should arrange for someone to take it over from me.


Sorry,
Peter

On 26/12/17 15:39, Jeremy Bicha wrote:

Source: gquilt
Version: 0.25-5
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha





Bug#885418: Please provide transitional libengine-pkcs11-openssl1.1 package for buster

2017-12-26 Thread Adrian Bunk
Source: libp11
Version: 0.4.7-2
Severity: normal

With libengine-pkcs11-openssl now using OpenSSL 1.1, please provide
a transitional libengine-pkcs11-openssl1.1 package depending on
libengine-pkcs11-openssl to migrate installations that are using
libengine-pkcs11-openssl1.1 in stretch.



Bug#861011: RFS: qt5ct/0.31-2 [ITP]

2017-12-26 Thread Tobias Frost
Hi Mateusz,

a short review:

- do not install AUTHORS. This information should be visible in
d/copyright already.
- line 4 in d/copyright is redundant
- in the meantime, a new compat level and standard version .has been
released. (Something for the next upload)
- VCS-* repository in d/control is not working, but it is probably
anyway time to move it to salsa.debian.org...

however, those are small problems, so I've uploaded it.

Thanks for your contributions to Debian!


-- 
tobi



Bug#885127: vlc: Cast Chromecast unusable due to gnutls error

2017-12-26 Thread Floris


Apparently, on a windows machine you get a "trust this certificate"  
pop-up

window and you are able to import the chromecast certificate.


That popup also exists in Linux. But it is not adequate to handle  
insecure

algorithms, only unknown or mismatched certificates.


In Debian
there isn't such window. How to accept the chromecast certificate?


The TLS support within VLC is identical for Windows and Linux. The  
difference
is the Windows version ships an older version of GnuTLS, than that in  
Debian.
Presumably, the server is using SHA-1 certificate signatures - which are  
being

phased out industry-wide, and no longer accepted by newer GnuTLS version.

I don't see how this is a VLC bug. It's actually working as intended. If  
you

think the diagnostic is wrong, then it's a problem with GnuTLS.



I'm not sure this is a VLC bug, although I think it is odd that VLC 3 has  
a Chromecast feature, but it isn't working. Maybe build vlc without  
Chromecast support in Debian until Google and/ or GnuTLS has a decent fix  
for this issue. Or make a workaround.




Bug#885343: Close icon on Preferences dialog not centred on hover

2017-12-26 Thread Jason Crain
Control: tags -1 + upstream fixed-upstream

On Tue, Dec 26, 2017 at 01:56:35PM +, Phil Wyett wrote:
> Close icon on Preferences dialog not centred on hover. See attached 
> screenshot.

I believe this is because a "Full Text Search" option was added to the
"Search & Preview" page, making it a little too tall for your monitor.
It will be fixed in nautilus versions after 3.27.2 because that option
was removed from the Preferences dialog to a different part of the UI.



Bug#885417: Does not load under gnome-shell version 3.26

2017-12-26 Thread Jason Crain
Package: gnome-shell-extension-autohidetopbar
Version: 20170728-1
Severity: grave

This extension's metadata.json declares that it only works with
gnome-shell versions 3.24 and earlier.  Since testing and unstable now
have gnome-shell version 3.26, this extension no longer loads.  This is
fixed in upstream's git repo.

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

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

Versions of packages gnome-shell-extension-autohidetopbar depends on:
ii  gnome-shell  3.26.2-2

Versions of packages gnome-shell-extension-autohidetopbar recommends:
ii  gnome-tweak-tool  3.26.4-1

gnome-shell-extension-autohidetopbar suggests no packages.

-- no debconf information



Bug#882955: ufo-filters: diff for NMU version 0.14.1+dfsg1-1.1

2017-12-26 Thread Adrian Bunk
Control: tags 882955 + pending

Dear maintainer,

I've prepared an NMU for ufo-filters (versioned as 0.14.1+dfsg1-1.1) and 
uploaded it to DELAYED/5. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru ufo-filters-0.14.1+dfsg1/debian/changelog ufo-filters-0.14.1+dfsg1/debian/changelog
--- ufo-filters-0.14.1+dfsg1/debian/changelog	2017-10-13 19:39:58.0 +0300
+++ ufo-filters-0.14.1+dfsg1/debian/changelog	2017-12-26 23:03:53.0 +0200
@@ -1,3 +1,10 @@
+ufo-filters (0.14.1+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with glibc 2.25. (Closes: #882955)
+
+ -- Adrian Bunk   Tue, 26 Dec 2017 23:03:53 +0200
+
 ufo-filters (0.14.1+dfsg1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ufo-filters-0.14.1+dfsg1/debian/patches/0001-Fix-146-use-gnu99-instead-of-c99.patch ufo-filters-0.14.1+dfsg1/debian/patches/0001-Fix-146-use-gnu99-instead-of-c99.patch
--- ufo-filters-0.14.1+dfsg1/debian/patches/0001-Fix-146-use-gnu99-instead-of-c99.patch	1970-01-01 02:00:00.0 +0200
+++ ufo-filters-0.14.1+dfsg1/debian/patches/0001-Fix-146-use-gnu99-instead-of-c99.patch	2017-12-26 22:59:08.0 +0200
@@ -0,0 +1,39 @@
+From 8373b58c56d19833f166ccc95db4f9af3c4494a6 Mon Sep 17 00:00:00 2001
+From: Matthias Vogelgesang 
+Date: Tue, 28 Nov 2017 10:02:20 +0100
+Subject: Fix #146: use gnu99 instead of c99
+
+---
+ CMakeLists.txt | 2 --
+ src/CMakeLists.txt | 2 +-
+ 2 files changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 89c2890..fa80bb0 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -70,8 +70,6 @@ link_directories(${UFO_LIBRARY_DIRS})
+ add_definitions("-Wall -Wextra -fPIC")
+ add_definitions(-DG_LOG_DOMAIN="Ufo")
+ 
+-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
+-
+ if (CMAKE_COMPILER_IS_GNUCC OR ("${CMAKE_C_COMPILER_ID}" STREQUAL "Clang"))
+ add_definitions("-Wno-unused-parameter")
+ endif ()
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index 0f9802f..4c61f39 100644
+--- a/src/CMakeLists.txt
 b/src/CMakeLists.txt
+@@ -116,7 +116,7 @@ set(ufofilter_LIBS
+ ${UFO_LIBRARIES}
+ ${OpenCL_LIBRARIES})
+ 
+-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99 -pedantic -Wall -Wextra -fPIC -Wno-unused-parameter -Wno-deprecated-declarations")
++set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 -pedantic -Wall -Wextra -fPIC -Wno-unused-parameter -Wno-deprecated-declarations")
+ 
+ add_definitions(-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES)
+ #}}}
+-- 
+2.11.0
+
diff -Nru ufo-filters-0.14.1+dfsg1/debian/patches/series ufo-filters-0.14.1+dfsg1/debian/patches/series
--- ufo-filters-0.14.1+dfsg1/debian/patches/series	2017-10-13 19:38:42.0 +0300
+++ ufo-filters-0.14.1+dfsg1/debian/patches/series	2017-12-26 23:02:17.0 +0200
@@ -1 +1,2 @@
 patch-conf.py-in-order-to-use-the-locall
+0001-Fix-146-use-gnu99-instead-of-c99.patch


Bug#885415: vlc: When jumping to another position in a video there is no sound for several (5+) seconds

2017-12-26 Thread Svein Engelsgjerd
Package: src:vlc
Version: 3.0.0~rc2-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I upgraded from VLC 2.x to 3.0

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

I did nothing other than upgrading VLC

   * What was the outcome of this action?

Now when I change position in a video all sound is paused for many seconds 
before resuming.
Typically more than 5 seconds always

   * What outcome did you expect instead?

I expected VLC 3.0 to be no worse than 2.x

Other information:
Recently pulseaudio enabled systemd socket activation which appears to have 
introduced a small millisecond delay globally for all audio.
Perhaps this could have something to do with it , just mentioning it to be on 
the safe side.


*** 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.13.0-1-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vlc depends on:
ii  vlc-bin  3.0.0~rc2-2
ii  vlc-l10n 3.0.0~rc2-2
ii  vlc-plugin-base  3.0.0~rc2-2
ii  vlc-plugin-qt3.0.0~rc2-2
ii  vlc-plugin-video-output  3.0.0~rc2-2

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.0~rc2-2
ii  vlc-plugin-samba   3.0.0~rc2-2
ii  vlc-plugin-skins2  3.0.0~rc2-2
ii  vlc-plugin-video-splitter  3.0.0~rc2-2
ii  vlc-plugin-visualization   3.0.0~rc2-2

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.25-3
ii  libvlc5  3.0.0~rc2-2

Versions of packages libvlc5 depends on:
ii  libc62.25-3
ii  libvlccore9  3.0.0~rc2-2

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.0~rc2-2

Versions of packages libvlccore8 depends on:
ii  libc62.25-3
ii  libdbus-1-3  1.12.2-1
ii  libidn11 1.33-2.1

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.14-4

Versions of packages vlc-bin depends on:
ii  libc6   2.25-3
ii  libvlc-bin  3.0.0~rc2-2
ii  libvlc5 3.0.0~rc2-2

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-3.1
ii  libaribb24-0 1.0.3-1
ii  libasound2   1.1.3-5
ii  libass9  1:0.14.0-1
ii  libavahi-client3 0.7-3
ii  libavahi-common3 0.7-3
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.4.1-1
ii  libavformat577:3.4.1-1
ii  libavutil55  7:3.4.1-1
ii  libbasicusageenvironment12017.10.28-2
ii  libbluray2   1:1.0.2-1
ii  libc62.25-3
ii  libcairo21.15.8-2
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.12.2-1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-dmo2
ii  libdvbpsi10  1.3.1-2
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.5-2
ii  libfaad2 2.8.8-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-0.1
ii  libfribidi0  0.19.7-2
ii  libgcc1  1:7.2.0-18
ii  libgcrypt20  1.8.1-4
ii  libglib2.0-0 2.54.1-1
ii  libgnutls30  3.5.16-1
ii  libgpg-error01.27-5
ii  libgroupsock82017.10.28-2
ii  libharfbuzz0b1.6.2-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.10.0-2+b1
ii  liblivemedia61   2017.10.28-2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8.1
ii  libmatroska6v5   1.4.8-1.1
ii  libmicrodns0 0.0.8-1
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-8
ii  libmpg123-0  1.25.8-1
ii  libmtp9  1.1.13-1
ii  libncursesw5 6.0+20171

Bug#885416: transition: libharu

2017-12-26 Thread Johan Van de Wauw
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello Release Team,

I would like to request a transition for libharu. The package is in 
experimental for some time.
I have tested the reverse dependencies and they build fine.

Kind Regards,
Johan

Ben file:

title = "libharu";
is_affected = .depends ~ "libhpdf-2.2.1" | .depends ~ "libhpdf-2.3.0";
is_good = .depends ~ "libhpdf-2.3.0";
is_bad = .depends ~ "libhpdf-2.2.1";



Bug#861649: Newer version uploaded

2017-12-26 Thread Tobias Frost
Control: tags -1 moreinfo

Hi Gard,

I was checking your RFS, but I cannot get it compiled...
Please check and then remove the moreinfo tag again...

tobi

excerpt from the log:

/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:57:21: error: 'Bare_point' in 'using Gt = class
CGAL::Regular_triangulation_euclidean_traits_3 {aka class
CGAL::Regular_triangulation_euclidean_traits_3}' does not
name a type
 using Point_3 = Gt::Bare_point;
 ^~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:58:30: error: 'Weighted_point' in 'using Gt = class
CGAL::Regular_triangulation_euclidean_traits_3 {aka class
CGAL::Regular_triangulation_euclidean_traits_3}' does not
name a type
 using Weighted_point_3 = Gt::Weighted_point;
  ^~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp: In function 'int main(int, char* const*)':
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:31: error: 'Point_3' was not declared in this scope
   Gudhi::Points_3D_off_reader off_reader(offInputFile);
   ^~~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:31: note: suggested alternative:
In file included from /usr/include/CGAL/user_classes.h:42:0,
 from /usr/include/CGAL/Kernel/global_functions_2.h:33,
 from /usr/include/CGAL/Kernel/global_functions.h:31,
 from /usr/include/CGAL/Cartesian/Cartesian_base.h:30,
 from /usr/include/CGAL/Simple_cartesian.h:28,
 from
/usr/include/CGAL/Exact_predicates_inexact_constructions_kernel.h:28,
 from /build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:29:
/usr/include/CGAL/Point_3.h:39:7: note:   'CGAL::Point_3'
 class Point_3 : public R_::Kernel_base::Point_3
   ^~~
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:38: error: template argument 1 is invalid
   Gudhi::Points_3D_off_reader off_reader(offInputFile);
  ^
/build/gudhi-
2.0.1+dfsg/example/Persistent_cohomology/weighted_alpha_complex_3d_pers
istence.cpp:107:63: error: cannot convert 'std::__cxx11::string {aka
std::__cxx11::basic_string}' to 'int' in initialization
   Gudhi::Points_3D_off_reader off_reader(offInputFile);



Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

2017-12-26 Thread Greg Wooledge
Package: base-files
Version: 9.9+deb9u3
Severity: normal
Tags: patch

--- /usr/share/base-files/profile   2016-03-04 06:00:00.0 -0500
+++ /tmp/profile2017-12-26 15:49:08.839804524 -0500
@@ -26,8 +26,8 @@
 
 if [ -d /etc/profile.d ]; then
   for i in /etc/profile.d/*.sh; do
-if [ -r $i ]; then
-  . $i
+if [ -r "$i" ]; then
+  . "$i"
 fi
   done
   unset i


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

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

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.1.4+dfsg-1
ii  mawk [awk]  1.3.3-17+b3

base-files recommends no packages.

base-files suggests no packages.

-- debconf-show failed



Bug#885413: please create debian-octave mailing list

2017-12-26 Thread Sébastien Villemot
Package: lists.debian.org
Severity: wishlist

Dear listmasters,

With the upcoming shutdown of alioth, the Debian Octave Group [1] needs a
dedicated mailing lists for discussions about the packaging effort (we do not
use iRC).

The team maintains GNU Octave [2], and several dozens of add-ons and related
software.

The list would mainly be for human traffic. But if we are allowed to do so, we
would also be happy to use it for the Maintainer field of our packages; please
let us know if the latter is acceptable for you.

Also, we would be happy to import the archives from our previous list:
pkg-octave-de...@lists.alioth.debian.org


Name: debian-octave
Short description: Maintenance of GNU Octave and related software in Debian
Long description: Discussions about the packaging in Debian of GNU Octave (a
  Scientific Programming Language), the Octave Forge packages, and other
  software built on top of Octave.
Category: Developers
Subscription policy: open
Post policy: open
Web archive: yes


Thanks!


[1] https://wiki.debian.org/Teams/DebianOctaveGroup
[2] http://www.octave.org

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


signature.asc
Description: PGP signature


Bug#885412: nbd-server: please provide a tool to list status of exports

2017-12-26 Thread Adam Borowski
Package: nbd-server
Version: 1:3.15.2-3
Severity: wishlist

Hi!
Once a single server has enough exports, it might get messy knowing what
files are currently used and which are not.  In theory, one could grep
/var/log/daemons.log, but that would be error prone.  There's also
ss/netstat but that has no IP-to-export match.

Thus, it'd be nice to have a tool that produces a report such as:
kholdan.srv 2001:470:64f4::5
kholdan.swap2001:470:64f4::5
lorien.srv  -
lorien.swap -
scratch -
sirius.srv  2001:470:64f4::9
sirius.swap 2001:470:64f4::9

If there already is a way to query a running server, please consider this
bug a request for documentation pointer instead.


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

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

Versions of packages nbd-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u3
ii  ucf3.0036

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf information excluded



Bug#885383: find_java_runtime should use the preferred JRE

2017-12-26 Thread Markus Koschany
Control: reassign -1 java-wrappers
Control: retitle -1  find_java_runtime should use the preferred JRE
As the title says: The find_java_runtime command should use the
preferred JRE (first choice via update-alternatives --config java) when
two JREs (here Java 8 runtimes) are installed on the same system. Maybe
the Oracle JRE is not properly detected or it is a general issue with
different OpenJDK versions.

Markus





signature.asc
Description: OpenPGP digital signature


Bug#885411: python-pyelftools: Please mark python*-pyelftools as Multi-Arch: foreign

2017-12-26 Thread Vagrant Cascadian
Package: python-pyelftools
Version: 0.24-3
Severity: normal
Tags: patch

Please mark python-pyelftools and python3-pyelftools as "Multi-Arch:
foreign", so that it can be used to satisfy build-dependencies when
cross-building packages.

  
https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages


live well,
  vagrant

diff -Nru python-pyelftools-0.24/debian/control 
python-pyelftools-0.24/debian/control
--- python-pyelftools-0.24/debian/control   2017-04-30 02:43:50.0 
-0700
+++ python-pyelftools-0.24/debian/control   2017-12-26 12:19:24.0 
-0800
@@ -11,6 +11,7 @@
 Package: python-pyelftools
 Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
+Multi-Arch: foreign
 Description: pure-python2 library for parsing ELF and DWARF
  pyelftools is a pure-Python library for parsing and analyzing ELF
  files and DWARF debugging information. It can be used to query
@@ -22,6 +23,7 @@
 Package: python3-pyelftools
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
+Multi-Arch: foreign
 Description: pure-python3 library for parsing ELF and DWARF
  pyelftools is a pure-Python library for parsing and analyzing ELF
  files and DWARF debugging information. It can be used to query


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable'), (210, 'proposed-updates'), (120, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

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

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

python-pyelftools recommends no packages.

python-pyelftools suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#885383: sweethome3d: crashes during start with Cursor exception

2017-12-26 Thread Nagy Attila

On 12/26/2017 07:43 PM, Markus Koschany wrote:

Hi,

the line find_java_runtime java6 is basically correct. It is the minimum
requirement for running Sweethome3d. Nowadays it should be java7 though
because java6 is no longer supported in Debian.

Actually making the Oracle JDK the preferred JDK via the alternative
mechanism:

update-alternatives --config java

should resolve your issue. If not, then we have a bug in java-wrappers.
It seems this is the case. I've done this right after the installation 
of Oracle 8u152.
After reading a little bit about the find_java_runtime function, it 
seems that it only uses the alternatives list if it gets no parameter.



If two java8 JRE are installed on the same system, java-wrappers should
detect and use the one which is the preferred JRE based on the
update-alternative mechanism.

If you are really sure that the Oracle JRE is already the preferred one,
please report back and I'm going to reassign this bug report to
java-wrappers. The real issue is in openjdk though but this will be
fixed eventually.
Yes, I'm absolutely sure I've set the default. At one point I even tried 
to set the /usr/lib/jvm/default-java symlink to point to the newly 
installed directory but this got ignored as well.


So please reassign this bug.
As a side note the documentation of find_java_runtime doesn't really 
mention the role of the parameter (it's the minimum version or the 
wanted version), so maybe this should be fixed as well.


Best regards,
Tylla



Bug#885410: python-pyelftools: Please mark python*-pyelftools as Multi-Arch: foreign

2017-12-26 Thread Vagrant Cascadian
Package: python-pyelftools
Version: 0.24-3
Severity: normal

Please mark python-pyelftools and python

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable'), (210, 'proposed-updates'), (120, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

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

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

python-pyelftools recommends no packages.

python-pyelftools suggests no packages.

-- no debconf information



Bug#885335: abiword is missing required dependency

2017-12-26 Thread Jeremy Bicha
On Tue, Dec 26, 2017 at 3:07 PM, Tomas M  wrote:
> You probably do not understand me correctly.
> I am not an end user.
> I am a creator of Live distribution Slax (now based on Debian).
>
> I understand that installing 'xorg' package will add libgl1-mesa-dri.
> But I do not want this to be included in base Slax. I just want
> xorg-server inthere.

xserver-xorg-core already Recommends libgl1-mesa-dri. I do hope you
install Recommends.

> Anyway, this is not about Slax. This is about Debian.
>
> I understand Debian this way:
> 1) user can install any package by apt install.
> 2) user can choose himself what he wants to install
> 3) so I choose to install xorg-server only. This works perfectly well.
> I do not need libgl1-mesa-dri to use xorg-server package.
> 4) then later I choose to install abiword
> 5) Debian's dependency tracking system should know that abiword
> requires libgl1-mesa-dri to run (it fails to start without it).
>
> I believe that dependency tracking in Debian should understand that if
> user wants to install abiword, then the user must have installed
> libgl1-mesa-dri, because otherwise abiword does not start.

Ok, could you investigate why Abiword appears to require
libgl1-mesa-dri? It's unusual for a Debian app to need to manually
depend on that.

Jeremy



Bug#872724: pyasn1

2017-12-26 Thread Vincent Bernat
 ❦ 26 décembre 2017 21:08 +0200, Timo Aaltonen  :

 Do you expect one of us to upload or did you want to do that yourself
 (both are fine for me)? 
>>>
>>> I didn't read the bug history. I'll upload a new version shortly,
>>> without doing a transition because we don't usually do that with Python
>>> and nobody strongly disapproved me.
>> 
>> So, it's uploaded in experimental as it breaks pysnmp4. I'll look into
>> uploading a newer version for this one soon.
>
> I've just uploaded a new python-pyasn1-modules to experimental, since it
> requires the new pyasn1 version.

pysnmp4 would also require to package pysmi. I'll do that next year.
-- 
Big book, big bore.
-- Callimachus


signature.asc
Description: PGP signature


Bug#881624: The crashes

2017-12-26 Thread Konstantin Khomoutov
Oh, after closer examniation it appears the crashes are actually
different: the former has "double free or corruption (!prev)" as its
reason and has happened in garbage_collect() while the second has
"corrupted size vs. prev_size" and happened in win_free_lsize().

Still, both appear to relate to memory management.



Bug#885408: multipath-tools: please make the build reproducible

2017-12-26 Thread Chris Lamb
Source: multipath-tools
Version: 0.7.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -urNad multipath-tools-0.7.4.orig/debian/rules 
multipath-tools-0.7.4/debian/rules
--- multipath-tools-0.7.4.orig/debian/rules 2017-12-26 20:03:46.366914310 
+
+++ multipath-tools-0.7.4/debian/rules  2017-12-26 20:05:42.852097145 +
@@ -12,6 +12,8 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
+include /usr/share/dpkg/pkg-info.mk
+export KBUILD_BUILD_TIMESTAMP = $(SOURCE_DATE_EPOCH)
 #
 
 # Uncomment this to turn on verbose mode.


Bug#885409: RFP: cider-nrepl -- nREPL middleware for CIDER

2017-12-26 Thread Sean Whitton
Package: wnpp
Severity: wishlist
Control: block 885384 by -1

Hello Clojure team,

I am packaging CIDER for Debian, as elpa-cider.  But I need the
cider-nrepl middleware in Debian first.  Otherwise, `M-x cider-jack-in`
will download jars from the Internet with no warning, which is not
acceptable for a Debian package.

I'm told that you Clojure guys love CIDER ... if you'd like to be able
to install it with apt-get, please consider helping me by packaging the
cider-nrepl middleware for Debian :)

Otherwise, I'll convert this RFP to an ITP at some point, but it may take
me some time to learn enough about Java to package a Clojure library.

* Package name: cider-nrepl
  Version : 0.15.1
  Upstream Author : CIDER contributors
* URL : https://github.com/clojure-emacs/cider-nrepl
* License : EPL
  Programming Lang: Clojure
  Description : nREPL middleware for CIDER

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#885407: debhelper class broken in compat level 11 (dh_systemd_enable deprecated)

2017-12-26 Thread Sébastien Villemot
Package: cdbs
Version: 0.4.156
Severity: normal

Dear Maintainer,

The debhelper class does not work with compat level 11, because it tries to
call dh_systemd_enable, which has been deprecated, and errors out in that
compat level. It has been replaced by dh_installsystemd.

Thanks,

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



Bug#885406: RFS: pidgin-sipe/1.23.0-3 -- Pidgin plugin for Skype for Business and Microsoft Lync

2017-12-26 Thread Jakub Adam
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for package "pidgin-sipe", whose source code is at:

  https://anonscm.debian.org/cgit/collab-maint/pidgin-sipe.git

or you may also:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pidgin-sipe/pidgin-sipe_1.23.0-3.dsc

It builds this binary package:

  pidgin-sipe - Pidgin plugin for Skype for Business and Microsoft Lync

Changes since the last upload:

pidgin-sipe (1.23.0-3) UNRELEASED; urgency=medium

  * Make postinst script insensitive to locale (Closes: #885331).
- Fixes package upgrade on systems with non-English locale.
  * Bump Standards-Version to 4.1.2 (no changes required).

 -- Jakub Adam   Tue, 26 Dec 2017 19:47:19 +0100

Regards,

Jakub



signature.asc
Description: OpenPGP digital signature


Bug#799295: lvm

2017-12-26 Thread PF4Public
Looks like RedHat had a very similar issue and they fixed it with a simple patch, is this 
usable for Debian?


See here: https://bugzilla.redhat.com/show_bug.cgi?id=813766



Bug#873976: FTBFS with Java 9 due to -source/-target only

2017-12-26 Thread Markus Koschany
Control: tags -1 patch

Dear maintainer,

I've prepared a patch to fix the FTBFS with Java 9. I'm attaching it to
this bug report.

Regards,

Markus
From 9b1cb29f7dbdaaa94cfd04cc226f00ef62905235 Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Tue, 26 Dec 2017 20:46:03 +0100
Subject: [PATCH] fix FTBFS with Java 9.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 3cfa594..8f0616d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -80,7 +80,7 @@ CONFIGURE_SWITCHES += --enable-posixmutexes
 endif
 
 ifeq (yes,$(ENABLE_JAVA))
-JAVACFLAGS=-source 1.5 -target 1.5
+JAVACFLAGS=-source 1.7 -target 1.7
 JAVA_HOME ?= /usr/lib/jvm/default-java
 CFLAGS += -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
 CONFIGURE_SWITCHES += --enable-java
-- 
2.15.1



signature.asc
Description: OpenPGP digital signature


Bug#885245: linux: FTBFS on powerpcspe: sstep.c: ptesync unrecognized

2017-12-26 Thread Aaron M. Ucko
Ben Hutchings  writes:

> I would welcome a powerpcspe porter to join the kernel team, but until
> that happens you should not expect any fixes from our side.  (If you

Fair enough.  FTR, I'm not a porter for this (or any other) architecture
myself, just a regular DD who helps ensure that build errors for
packages that have recently emerged from NEW don't accidentally escape
notice.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#885335: abiword is missing required dependency

2017-12-26 Thread Jeremy Bicha
On Tue, Dec 26, 2017 at 2:40 PM, Tomas M  wrote:
> Hello
> I am not installing desktop from Debian's installer.
>
> I have xorg, of course, I've installed xserver-xorg package directly.
> I am running X without any problem. I am running other X applications
> without any problem too.

No, I'm saying you should install the package named 'xorg' which is
already installed by the usual supported ways of installing a desktop
on Debian.

Thanks,
Jeremy Bicha



Bug#885333: stretch-pu: package loook/0.8.4-1

2017-12-26 Thread Mechtilde Stehmann
Hello,

I discussed my wish also with wRAR at IRC #debian-mentors. He pointed
out to me that my versioning was wrong.

So I correct it a new build and a new patch file which i applied.


-- 
Mechtilde Stehmann
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## Key-ID 0x141AAD7F
diff -Nru loook-0.8.4/debian/changelog loook-0.8.4/debian/changelog
--- loook-0.8.4/debian/changelog	2016-02-13 17:06:14.0 +0100
+++ loook-0.8.4/debian/changelog	2017-12-26 17:43:48.0 +0100
@@ -1,3 +1,12 @@
+loook (0.8.4-1+deb9u1) UNRELEASED; urgency=medium
+
+  * now it is possible to search in directories which also contains password protected files.
++ fix for bug #884582
+  * Change E-Mail address of Maintainer after becoming DD in control and
+in changelog
+
+ -- Mechtilde Stehmann   Tue, 26 Dec 2017 17:43:48 +0100
+
 loook (0.8.4-1) unstable; urgency=low
 
   * New Upstream release
diff -Nru loook-0.8.4/debian/control loook-0.8.4/debian/control
--- loook-0.8.4/debian/control	2016-02-13 17:04:49.0 +0100
+++ loook-0.8.4/debian/control	2017-12-26 17:41:40.0 +0100
@@ -1,7 +1,7 @@
 Source: loook
 Section: utils
 Priority: optional
-Maintainer: Mechtilde Stehmann 
+Maintainer: Mechtilde Stehmann 
 Build-Depends: debhelper (>= 9), gettext
 Standards-Version: 3.9.7
 Homepage: http://mechtilde.de/Loook/
diff -Nru loook-0.8.4/debian/patches/fix884582.patch loook-0.8.4/debian/patches/fix884582.patch
--- loook-0.8.4/debian/patches/fix884582.patch	1970-01-01 01:00:00.0 +0100
+++ loook-0.8.4/debian/patches/fix884582.patch	2017-12-26 17:39:36.0 +0100
@@ -0,0 +1,80 @@
+Description: fix for bug #884582-now it is possible to search in directories which also contains password protected files.
+Forwarded: Yes
+Author: Mechtilde Stehmann 
+Last-Update: 2017-12-26
+Index: loook-0.8.4/loook.py
+===
+--- loook-0.8.4.orig/loook.py	2016-02-13 17:03:15.0 +0100
 loook-0.8.4/loook.py	2017-12-26 17:38:07.327473839 +0100
+@@ -213,7 +213,7 @@
+ 		"""Start OOo to view the file. This method lacks 
+ 		error handling (TODO)."""
+ 		items = event.widget.curselection()
+-		filename = "%s%s" % (self.search_path.get(), event.widget.get(items[0]))
++		filename = os.path.join(self.search_path.get(), event.widget.get(items[0]))
+ 		filename = os.path.normpath(filename)
+ 		prg = self.ooo_path.get()
+ 		if not prg:
+@@ -223,10 +223,7 @@
+ 			cmd = "\"%s\" \"%s\" &" % (prg, filename)
+ 			self.status.config(text=_("Starting viewer..."))
+ 			print(cmd)
+-			try:
+-res = os.system(cmd)
+-			except UnicodeError:
+-res = os.system(cmd)
++			res = os.system(cmd)
+ 			if res != 0:
+ # don't show a dialog, this check might not be system-indepenent:
+ print(_("Warning: Command returned code != 0: ") + cmd)
+@@ -273,6 +270,8 @@
+ 
+ 	def processFile(self, filename, query):
+ 		suffix = self.getSuffix(filename)
++		# needed for error messages
++		fsfilename =filename
+ 		try:
+ 			# Handle OpenOffice.org files:
+ 			if suffix in ('sxw', 'stw',		# OOo   1.x swriter
+@@ -299,7 +298,7 @@
+ 
+ 		if filename.endswith("document.xml"):
+ 			content += str(zip.read(filename), 'utf-8')
+-			
++
+ 	content = self.removeXMLMarkup(content, replace_with_space=0)
+ 	docinfo = str(zip.read("meta.xml"), 'utf-8')
+ 	docinfo = self.removeXMLMarkup(docinfo, replace_with_space=0)
+@@ -307,6 +306,10 @@
+ except KeyError as err:
+ 	print("Warning: %s not found in '%s'" % (err, filename))
+ 	return None
++# Patch for encrypted files
++except UnicodeDecodeError:
++	print("Warning: cannot open '%s'" % (fsfilename))
++	return None
+ title = ""
+ title_match = re.compile("(.*?)", re.DOTALL|re.IGNORECASE).search(docinfo)
+ if title_match:
+@@ -339,6 +342,10 @@
+ except KeyError as err:
+ 	print("Warning: %s not found in '%s'" % (err, filename))
+ 	return None
++# Patch for encrypted files
++except UnicodeDecodeError:
++	print("Warning: cannot open '%s'" % (fsfilename))
++	return None
+ title = ""
+ title_match = re.compile("(.*?)", re.DOTALL|re.IGNORECASE).search(docinfo)
+ if title_match:
+@@ -368,6 +375,10 @@
+ except KeyError as err:
+ 	print("Warning: %s not found in '%s'" % (err, filename))
+ 	return None
++# Patch for encrypted files
++except UnicodeDecodeError:
++	print("Warning: cannot open '%s'" % (fsfilename))
++	return None
+ title = ""
+ title_match = re.compile("(.*?)", re.DOTALL|re.IGNORECASE).search(docinfo)
+ if title_match:
diff -Nru loook-0.8.4/debian/patches/series loook-0.8.4/debian/patches/series
--- loook-0.8.4/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ loook-0.8.4/debian/patches/series	2017-12-26 17:36:52.0 +0100
@@ -0,0 +1 @@
+fix884582.patch


signature.asc
Description: OpenPGP digital signature


Bug#885405: RFP: waterfox -- graphical web browser based on Firefox

2017-12-26 Thread W. Martin Borgert
Package: wnpp
Severity: wishlist

* Package name: waterfox
  Version : 56.0.1
  Upstream Author : Alex Kontos
* URL : https://www.waterfoxproject.org/
* License : MPL 2.0
  Programming Lang: C++
  Description : graphical web browser based on Firefox

from Wikipedia:

> Waterfox differs from Firefox in a number of ways by:
>  - Disabling Encrypted Media Extensions (EME)
>  - Disabling Web Runtime
>  - Removing Adobe DRM
>  - Removing Pocket
>  - Removing Telemetry
>  - Removing data collection
>  - Removing startup profiling
>  - Allowing running of all 64-bit NPAPI plugins
>  - Allowing running of unsigned extensions
>  - Removing of Sponsored Tiles on New Tab Page
>  - Addition of Duplicate Tab option
>  - Addition of locale selector in about:preferences > General
>  - Defaulting to Ecosia as the search engine instead of Google or Yahoo

IMHO, it would be nice to have this in Debian to keep useful
packages like xul-ext-scrapbook alive.



Bug#885404: duc-nox: please provide bin/duc in duc-nox package

2017-12-26 Thread Jonathan Dowland
Package: duc-nox
Version: 1.4.3-2
Severity: normal

Dear Maintainer,

It would be great if the duc-nox package provided /usr/bin/duc (or /bin/duc or
whatever). It's frustrating to remember to type or tab complete the '-nox' part
on the machines I use where I have installed that, compared to the machines 
where
I've installed the full version.

This could be achieved in at least two ways

1) rename duc-nox to duc, add a compatibility symlink, add Conflicts: between 
the
   duc and duc-nox packages
2) Register duc and duc-nox as duc via the alternatives system (and install 
them to
   somewhere else e.g. /usr/lib/duc).

I can't think of a good reason why someone would install duc and duc-nox on the
same system, and solution 1) is simpler, so that's probably what I would do.

I will cook up a patch and attach to this bug.


Thanks

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

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

Versions of packages duc-nox depends on:
ii  libc6 2.24-11
ii  libncursesw5  6.0+20161126-1
ii  libtinfo5 6.0+20161126-1
ii  libtokyocabinet9  1.4.48-11+b1

duc-nox recommends no packages.

duc-nox suggests no packages.

-- no debconf information



Bug#848284: ping: please take over rxvt and migrate rxvt-unicode to 256

2017-12-26 Thread Adam Borowski
On Tue, Dec 26, 2017 at 11:47:05AM -0500, Ryan Kavanagh wrote:
> On Mon, Dec 25, 2017 at 06:06:23PM +0100, Adam Borowski wrote:
> > As I filed this just before Stretch's freeze, and you didn't act 
> > immediately,
> > the freeze precluded us from killing old rxvt.  It'd be nice if you could do
> > so for Buster.
> 
> Thanks for reminding me of this. I have a backlog of changes to urxvt I want 
> to
> upload in the next few days, so I'll make this change with those.

Awesome!

> > I think, though, that instead of migrating to rxvt-unicode-256color, it 
> > might
> > be better to take over rxvt, make it the primary package, and make all other
> > variants be dummy transitionals for it.
> 
> To confirm, you suggest making "rxvt" the primary binary package, and making 
> the
> following dummy transitionals for it:
>  * aterm
>  * rxvt-unicode
>  * rxvt-unicode-256color
> 
> I also propose making rxvt-unicode-lite a transition package. I don't know 
> that
> saving 200kb in an executable is worth the overhead given today's hardware:
> rak@zeta:/tmp$ for f in lite 256color; \
> do dpkg -c rxvt-unicode-${f}_9.22-1+b3_amd64.deb | grep 'bin/urxvt$'; done
> -rwxr-sr-x root/utmp   1136448 2017-07-22 02:35 ./usr/bin/urxvt
> -rwxr-sr-x root/utmp   1398784 2017-07-22 02:35 ./usr/bin/urxvt

Heh, now much point keeping it, indeed.

> I've never had to do a multi-package transition, but I assume I'll need to
> coordinate with debian-release following the same procedure as for library
> transitions?

The only interface goes through exec(), thus it's enough to provide symlinks
from the old executable names, no transition needed.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.



Bug#881624: Another crash: corrupted size vs. prev_size

2017-12-26 Thread Konstantin Khomoutov
I've just hit another case of this crash in the same environment.

This time I was able to recover the post-mortem printout Vim itself
generated; may be it will be of use; especially, it appears we now have
the exact reason for the crash formulated by Vim:

8<
*** Error in `vim': corrupted size vs. prev_size: 0x555d0da308a0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f92f94b3bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f92f94b9f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x78091)[0x7f92f94bb091]
vim(+0x1ad485)[0x555d0b1bb485]
vim(+0x14e358)[0x555d0b15c358]
vim(+0x14ec22)[0x555d0b15cc22]
vim(+0x1996ec)[0x555d0b1a76ec]
vim(+0x11e07c)[0x555d0b12c07c]
vim(+0x11e39c)[0x555d0b12c39c]
vim(+0x11e580)[0x555d0b12c580]
vim(+0x11e6d8)[0x555d0b12c6d8]
vim(+0x19e753)[0x555d0b1ac753]
vim(+0xba534)[0x555d0b0c8534]
vim(+0xbc464)[0x555d0b0ca464]
vim(+0xbcd68)[0x555d0b0cad68]
vim(+0xbd199)[0x555d0b0cb199]
vim(+0x102089)[0x555d0b110089]
vim(+0x1c5585)[0x555d0b1d3585]
vim(+0x1c63ab)[0x555d0b1d43ab]
vim(+0x2803d)[0x555d0b03603d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f92f94632b1]
vim(+0x28fba)[0x555d0b036fba]
=== Memory map: 
555d0b00e000-555d0b238000 r-xp  08:01 17563693   
/usr/bin/vim.basic
555d0b438000-555d0b444000 r--p 0022a000 08:01 17563693   
/usr/bin/vim.basic
555d0b444000-555d0b45b000 rw-p 00236000 08:01 17563693   
/usr/bin/vim.basic
555d0b45b000-555d0b465000 rw-p  00:00 0
555d0d2e2000-555d0df66000 rw-p  00:00 0  [heap]
7f92f3de3000-7f92f3df9000 r-xp  08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f3df9000-7f92f3ff8000 ---p 00016000 08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f3ff8000-7f92f3ff9000 r--p 00015000 08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f3ff9000-7f92f3ffa000 rw-p 00016000 08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f400-7f92f4021000 rw-p  00:00 0
7f92f4021000-7f92f800 ---p  00:00 0
7f92f8083000-7f92f8085000 r-xp  08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f8085000-7f92f8284000 ---p 2000 08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f8284000-7f92f8285000 r--p 1000 08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f8285000-7f92f8286000 rw-p 2000 08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f828b000-7f92f8295000 r-xp  08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8295000-7f92f8495000 ---p a000 08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8495000-7f92f8496000 r--p a000 08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8496000-7f92f8497000 rw-p b000 08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8497000-7f92f849d000 rw-p  00:00 0
7f92f84a3000-7f92f84ae000 r-xp  08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f84ae000-7f92f86ad000 ---p b000 08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f86ad000-7f92f86ae000 r--p a000 08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f86ae000-7f92f86af000 rw-p b000 08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f86b3000-7f92f86c7000 r-xp  08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f86c7000-7f92f88c7000 ---p 00014000 08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f88c7000-7f92f88c8000 r--p 00014000 08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f88c8000-7f92f88c9000 rw-p 00015000 08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f88c9000-7f92f88cb000 rw-p  00:00 0
7f92f88cb000-7f92f88d2000 r-xp  08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f88d2000-7f92f8ad1000 ---p 7000 08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f8ad1000-7f92f8ad2000 r--p 6000 08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f8ad2000-7f92f8ad3000 rw-p 7000 08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f8ad3000-7f92f8d9e000 r--p  08:01 17580799   
/usr/lib/locale/locale-archive
7f92f8da3000-7f92f8dbb000 r-xp  08:01 8916165
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f92f8dbb000-7f92f8fba000 ---p 00018000 08:01 8916165
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f92f8fba000-7f92f8fbb000 r--p 00017000 08:01 89161

Bug#872724: pyasn1

2017-12-26 Thread Timo Aaltonen
On 26.12.2017 09:23, Vincent Bernat wrote:
>  ❦ 26 décembre 2017 07:23 +0100, Vincent Bernat  :
> 
>>> Do you expect one of us to upload or did you want to do that yourself
>>> (both are fine for me)? 
>>
>> I didn't read the bug history. I'll upload a new version shortly,
>> without doing a transition because we don't usually do that with Python
>> and nobody strongly disapproved me.
> 
> So, it's uploaded in experimental as it breaks pysnmp4. I'll look into
> uploading a newer version for this one soon.

I've just uploaded a new python-pyasn1-modules to experimental, since it
requires the new pyasn1 version.

t



Bug#885403: ITP: node-postcss-merge-rules -- Merge CSS rules with PostCSS

2017-12-26 Thread Pirate Praveen
Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-postcss-merge-rules
  Version : 2.1.2
  Upstream Author : Ben Briggs  (http://beneb.info)
* URL : https://github.com/ben-eb/postcss-merge-rules
* License : Expat
  Programming Lang: JavaScript
  Description : Merge CSS rules with PostCSS

 PostCSS is a tool for transforming styles with JS plugins. These
plugins can
 lint your CSS, support variables and mixins, transpile future CSS syntax,
 inline images, and more.
 .
 Node.js is an event-based server-side JavaScript engine.

Dependency of gitlab 9.5



signature.asc
Description: OpenPGP digital signature


Bug#885360: pam-dbus-notify: Depends on unmaintained pygtk

2017-12-26 Thread Joachim Breitner
Hi,

I am not sure if pam-dbus-notify is used by anyone. Feel free to remove
it along with pygtk unless someone else complains (and wants to take
over this package.)

Opening an RFA for it…

Greetings,
Joachim

Am Dienstag, den 26.12.2017, 10:13 -0500 schrieb Jeremy Bicha:
> Package: pam-dbus-notify
> Version: 0.2.1-3
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtk
> Tags: sid buster
> 
> pygtk is unmaintained upstream. It has not had a release since GNOME 3
> was released in 2011.
> 
> The way forward is to port your app to use GObject Introspection
> bindings (and gtk3).
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Buster release as we're going to
> try to remove pygtk this cycle.
> 
> If you have any question don't hesitate to ask.
> 
> [1] https://wiki.gnome.org/Projects/GObjectIntrospection
> [2] https://wiki.gnome.org/Projects/PyGObject
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha
> 
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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


Bug#884973: tp-smapi-dkms: tp-smapi doesn't build for 4.15.0-rc?

2017-12-26 Thread Elimar Riesebieter
* Evgeni Golov  [2017-12-22 12:34 +0100]:

> control: severity -1 important
> 
> On Fri, Dec 22, 2017 at 10:03:17AM +0100, Elimar Riesebieter wrote:
> > Package: tp-smapi-dkms
> > Version: 0.42-1
> > Severity: serious
> > Justification: fails to build from source
> 
> Nope. 4.15 is not in Debian (not even experimental), so it can't be serious.
> 
> > tp-smapi doesn't build for the upcoming kernels 4.15:
> > 
> >  /var/lib/dkms/tp_smapi/0.42/build/hdaps.c: In function ‘hdaps_init’:¬
> >   /var/lib/dkms/tp_smapi/0.42/build/hdaps.c:781:2: error: implicit 
> > declaration of function ‘init_timer’; did you mean ‘init_timers’? [-Werr>
> > init_timer(&hdaps_timer);¬
> > ^~¬
> > init_timers¬
> >   /var/lib/dkms/tp_smapi/0.42/build/hdaps.c:782:23: error: assignment from 
> > incompatible pointer type [-Werror=incompatible-pointer-types]¬
> > hdaps_timer.function = hdaps_mousedev_poll;
> 
> Thanks for the report, I'll have a look with my upstream hat on when I
> find some time.

The patch mentioned in https://github.com/evgeni/tp_smapi/issues/31
works just fine for me.

Elimar
-- 
  Alles, was viel bedacht wird, wird bedenklich!;-)
 Friedrich Nietzsche


signature.asc
Description: PGP signature


Bug#880014: #880014: Call for Votes for new TC member

2017-12-26 Thread Keith Packard
Didier 'OdyX' Raboud  writes:

> ===BEGIN
> The Technical Committee recommends that Gunnar Wolf  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> G: Recommend to Appoint Gunnar Wolf 
> F: Further Discussion
> ===END

I vote G > F

-- 
-keith


signature.asc
Description: PGP signature


Bug#885401: openmw uninstallable

2017-12-26 Thread abunai
Subject: openmw uninstallable
Source: openmw
Version: 0.41.0-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Attempting to install openmw with apt fails.

When I try to install:

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

The following packages have unmet dependencies:
 openmw : Depends: libopenscenegraph-3.4-130 but it is not going to be installed
  Recommends: openmw-launcher but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

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

The following packages have unmet dependencies:
 libopenscenegraph-3.4-130 : Depends: gdal-abi-2-2-1 but it is not installable
E: Unable to correct problems, you have held broken packages.

sudo apt install gdal-abi-2-2-1
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package gdal-abi-2-2-1 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

It appears that I have the necessary libs on my machine, and that the virtual 
package that libgdal20 provides is missing.

-- 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-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#885402: vsftpd: 530 Login incorrect. PAM adding faulty module: /lib/security/pam_userdb.so

2017-12-26 Thread Nick Aquina
Package: vsftpd
Version: 3.0.3-8+b1
Severity: normal

The documentation in /usr/share/doc/vsftpd/examples/VIRTUAL_USERS/README.gz and 
/usr/share/doc/vsftpd/examples/VIRTUAL_USERS/vsftpd.pam states that we should 
have the following in /etc/pam.d/ftp:

auth required /lib/security/pam_userdb.so db=/etc/vsftpd_login
account required /lib/security/pam_userdb.so db=/etc/vsftpd_login

But when logging in to ftp this results in a login failure:
$ ftp localhost
Connected to localhost.
220 (vsFTPd 3.0.3)
Name (localhost:nick): username
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.
ftp> exit
221 Goodbye.   

Logging in twice produces the following status:
$ sudo service vsftpd status
   
● vsftpd.service - vsftpd FTP server
 
   Loaded: loaded (/lib/systemd/system/vsftpd.service; enabled; vendor preset: 
enabled)  
   Active: active (running) since Tue 2017-12-26 18:03:53 UTC; 2min 4s ago  
 
  Process: 12947 ExecStartPre=/bin/mkdir -p /var/run/vsftpd/empty (code=exited, 
status=0/SUCCESS)
 Main PID: 12950 (vsftpd)   
 
Tasks: 1 (limit: 19660) 
 
   CGroup: /system.slice/vsftpd.service 
 
   └─12950 /usr/sbin/vsftpd /etc/vsftpd.conf
 

 
Dec 26 18:03:53 hostname Dec 26 18:03:53 hostname systemd[1]: Starting vsftpd 
FTP server...   
Dec 26 18:03:53 hostname systemd[1]: Started vsftpd FTP server. 

Dec 26 18:04:03 hostname vsftpd[12961]: PAM unable to 
dlopen(/lib/security/pam_userdb.so): /lib/security/pam_userdb.so: cannot open sh
Dec 26 18:04:03 hostname vsftpd[12961]: PAM adding faulty module: 
/lib/security/pam_userdb.so   
Dec 26 18:05:03 hostname vsftpd[12979]: PAM unable to 
dlopen(/lib/security/pam_userdb.so): /lib/security/pam_userdb.so: cannot open sh
Dec 26 18:05:03 hostname vsftpd[12979]: PAM adding faulty module: 
/lib/security/pam_userdb.so   

Replacing the paths with names to modules in the ftp file as suggested at 
https://bugzilla.redhat.com/show_bug.cgi?id=206216#c2 fixes the issue:

auth required pam_userdb.so db=/etc/vsftpd_login
account required pam_userdb.so db=/etc/vsftpd_login

I think the documentation should be updated at both places with the new ftp 
file.

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

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

Versions of packages vsftpd depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  libc6  2.24-11+deb9u1
ii  libcap21:2.25-1
ii  libpam-modules 1.1.8-3.6
ii  libpam0g   1.1.8-3.6
ii  libssl1.1  1.1.0f-3+deb9u1
ii  libwrap0   7.6.q-26
ii  netbase5.4

Versions of packages vsftpd recommends:
ii  logrotate  3.11.0-0.1
ii  ssl-cert   1.0.39

vsftpd suggests no packages.

-- Configuration Files:
/etc/vsftpd.conf changed:
listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
anon_upload_enable=NO
anon_mkdir_write_enable=NO
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
local_root=/var/www
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=ftp
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=NO
guest_enable=YES
guest_username=virtual


-- debconf information:
  vsftpd/username: ftp
  vsftpd/directory: /srv/ftp


  1   2   3   >