Bug#895502: libsmithwaterman FTBFS on 32bit: missing symbol

[Adrian Bunk]

Source: libsmithwaterman
Version: 0.0+git20160702.2610e25-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libsmithwaterman=sid

...
   dh_makeshlibs -a -O--no-parallel
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libsmithwaterman0/DEBIAN/symbols doesn't match 
completely debian/libsmithwaterman0.symbols
--- debian/libsmithwaterman0.symbols 
(libsmithwaterman0_0.0+git20160702.2610e25-1_armel)
+++ dpkg-gensymbolsbf8gA7   2018-04-11 13:29:25.035300351 +
@@ -69,7 +69,7 @@
  _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev@Base 
0.0+git20160702.2610e25
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE12_M_erase_auxESt23_Rb_tree_const_iteratorIS8_E@Base
 0.0+git20160702.2610e25
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE24_M_get_insert_unique_posERS7_@Base
 0.0+git20160702.2610e25
- 
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS8_ERS7_@Base
 0.0+git20160702.2610e25
+#MISSING: 0.0+git20160702.2610e25-1# 
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS8_ERS7_@Base
 0.0+git20160702.2610e25
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base
 0.0+git20160702.2610e25
  _ZeqRK11IndelAlleleS1_@Base 0.0+git20160702.2610e25
  _ZlsRSoRK11IndelAllele@Base 0.0+git20160702.2610e25
dh_makeshlibs: failing due to earlier errors
debian/rules:8: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2

Bug#895501: btrfs-progs: move out of asciidoc

[Joseph Herlant]

Package: btrfs-progs
Version: 4.15.1-1
Control: block 895462 by -1

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

btrfs-progs already supports asciidoctor to build its documentation
natively starting in 4.16. See:
https://github.com/kdave/btrfs-progs/blob/master/configure.ac#L107
and
https://github.com/kdave/btrfs-progs/blob/master/Documentation/Makefile.in#L56

All you have to do is change asciidoc to asciidoctor in debian/control
and you can remove the dependency on xmlto that is not needed anymore
also.

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks for your help,
Joseph

Bug#895500: ruby-slim FTBFS with ruby-tilt 2.0.8-1

[Adrian Bunk]

Source: ruby-slim
Version: 3.0.7-1
Severity: serious
Tags: buster sid

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

...
  1) Error:
TestSlimEmbeddedEngines#test_render_with_builder:
NameError: undefined local variable or method `xml' for 
#
(__TEMPLATE__):3:in `block in singleton class'
(__TEMPLATE__):-2:in `instance_eval'
(__TEMPLATE__):-2:in `singleton class'
(__TEMPLATE__):-5:in `__tilt_47056743556540'
/usr/lib/ruby/vendor_ruby/tilt/template.rb:170:in `call'
/usr/lib/ruby/vendor_ruby/tilt/template.rb:170:in `evaluate'
/usr/lib/ruby/vendor_ruby/tilt/template.rb:109:in `render'
/build/1st/ruby-slim-3.0.7/test/core/helper.rb:24:in `render'
/build/1st/ruby-slim-3.0.7/test/core/helper.rb:47:in `assert_html'
/build/1st/ruby-slim-3.0.7/test/core/test_embedded_engines.rb:102:in 
`test_render_with_builder'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:107:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:204:in `capture_exceptions'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:104:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:255:in `time_it'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:103:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:350:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:275:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:102:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:839:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:311:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:310:in `each'
/usr/lib/ruby/vendor_ruby/minitest.rb:310:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:350:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest.rb:337:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest.rb:309:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `block in __run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `map'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `__run'
/usr/lib/ruby/vendor_ruby/minitest.rb:136:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:63:in `block in autorun'

281 runs, 425 assertions, 0 failures, 1 errors, 0 skips
/usr/lib/ruby/vendor_ruby/rake/testtask.rb:130:in `block (3 levels) in define': 
Command failed with status (1): [ruby -w -I"lib:lib:test/core"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" 
"test/core/test_code_blocks.rb" "test/core/test_code_escaping.rb" 
"test/core/test_code_evaluation.rb" "test/core/test_code_output.rb" 
"test/core/test_code_structure.rb" "test/core/test_commands.rb" 
"test/core/test_embedded_engines.rb" "test/core/test_encoding.rb" 
"test/core/test_erb_converter.rb" "test/core/test_html_attributes.rb" 
"test/core/test_html_escaping.rb" "test/core/test_html_structure.rb" 
"test/core/test_parser_errors.rb" "test/core/test_pretty.rb" 
"test/core/test_ruby_errors.rb" "test/core/test_slim_template.rb" 
"test/core/test_tabs.rb" "test/core/test_text_interpolation.rb" 
"test/core/test_thread_options.rb" "test/core/test_unicode.rb" ] (RuntimeError)
from /usr/lib/ruby/vendor_ruby/rake/file_utils.rb:57:in `sh'
from /usr/lib/ruby/vendor_ruby/rake/file_utils.rb:105:in `ruby'
from /usr/lib/ruby/vendor_ruby/rake/testtask.rb:117:in `block (2 
levels) in define'
from /usr/lib/ruby/vendor_ruby/rake/file_utils_ext.rb:59:in `verbose'
from /usr/lib/ruby/vendor_ruby/rake/testtask.rb:111:in `block in define'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:271:in `block in execute'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:271:in `each'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:271:in `execute'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:213:in `block in 
invoke_with_call_chain'
from /usr/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:193:in 
`invoke_with_call_chain'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:237:in `block in 
invoke_prerequisites'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:235:in `each'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:235:in 
`invoke_prerequisites'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:212:in `block in 
invoke_with_call_chain'
from /usr/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:193:in 
`invoke_with_call_chain'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:237:in `block in 
invoke_prerequisites'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:235:in `each'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:235:in 
`invoke_prerequisites'
from /usr/lib/ruby/vendor_ruby/rake/task.rb:212:in `block in 
invoke_with_call_chain'
from /usr/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
from 

Bug#894256: [Pkg-mailman-hackers] Bug#894256: mailman3 wants to take away mailman.cfg from mailman3-core

[Pierre-Elliott Bécue]

Le mardi 27 mars 2018 à 22:34:21+0200, Bjoern Franke a écrit :
> [mailman3 is a bully]

Hey,

Thanks for your bug report, and sorry for the delay.

Indeed, the file is owned by both packages and as they conflict, the latter
wants to get rid of the one from the former. I'm not sure there's anything
we can do to smoothen the transition.

I'll ask out for some adivce in case I missed something, but it's possible
that all people having installed -core will have to handle manually the
transition and its side effects.

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#895499: enki-aseba FTBFS on armel/armhf: error: 'glGenLists' was not declared in this scope

[Adrian Bunk]

Source: enki-aseba
Version: 1:1.6.0-5
Severity: serious

https://buildd.debian.org/status/package.php?p=enki-aseba=sid

...
cd /<>/obj-arm-linux-gnueabi/viewer && /usr/bin/c++  -DQT_CORE_LIB 
-DQT_NO_DEBUG -DUSE_SDL 
-I/<>/obj-arm-linux-gnueabi/viewer/enkiviewer_autogen/include 
-I/usr/include/SDL2 -I/<> 
-I/<>/obj-arm-linux-gnueabi/viewer -isystem 
/usr/include/arm-linux-gnueabi/qt5 
-I/usr/include/arm-linux-gnueabi/qt5/QtWidgets 
-I/usr/include/arm-linux-gnueabi/qt5/QtGui -isystem 
/usr/include/arm-linux-gnueabi/qt5/QtCore -isystem 
/usr/lib/arm-linux-gnueabi/qt5/mkspecs/linux-g++ 
-I/usr/include/arm-linux-gnueabi/qt5/QtOpenGL  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -fPIC -fPIC 
-std=gnu++11 -o CMakeFiles/enkiviewer.dir/objects/EPuckBody.cpp.o -c 
/<>/viewer/objects/EPuckBody.cpp
/<>/viewer/objects/EPuckBody.cpp: In function 'GLint 
Enki::GenEPuckBody()':
/<>/viewer/objects/EPuckBody.cpp:712:12: error: 'glGenLists' was 
not declared in this scope
  GLint lid=glGenLists(1);

^~
/<>/viewer/objects/EPuckBody.cpp:712:12: note: suggested 
alternative: 'glFinish'
  GLint lid=glGenLists(1);

^~
glFinish
/<>/viewer/objects/EPuckBody.cpp:713:17: error: 'GL_COMPILE' was 
not declared in this scope
  glNewList(lid, GL_COMPILE);

 ^~
/<>/viewer/objects/EPuckBody.cpp:713:17: note: suggested 
alternative: 'GL_SAMPLER'
  glNewList(lid, GL_COMPILE);

 ^~
 GL_SAMPLER
/<>/viewer/objects/EPuckBody.cpp:713:2: error: 'glNewList' was not 
declared in this scope
  glNewList(lid, GL_COMPILE);

  ^
/<>/viewer/objects/EPuckBody.cpp:713:2: note: suggested 
alternative: 'glViewport'
  glNewList(lid, GL_COMPILE);

  ^
  glViewport
/<>/viewer/objects/EPuckBody.cpp:715:3: error: 'glBegin' was not 
declared in this scope
   glBegin (GL_TRIANGLES);

   ^~~
/<>/viewer/objects/EPuckBody.cpp:728:4: error: 'glNormal3f' was 
not declared in this scope
glNormal3f (normals[ni][1],-normals[ni][0],normals[ni][2]);

^~
/<>/viewer/objects/EPuckBody.cpp:728:4: note: suggested 
alternative: 'normals'
glNormal3f (normals[ni][1],-normals[ni][0],normals[ni][2]);

^~
normals
/<>/viewer/objects/EPuckBody.cpp:729:4: error: 'glTexCoord2f' was 
not declared in this scope
glTexCoord2f(textures[ti][0],textures[ti][1]);

^~~~
/<>/viewer/objects/EPuckBody.cpp:729:4: note: suggested 
alternative: 'glTexStorage2D'
glTexCoord2f(textures[ti][0],textures[ti][1]);

^~~~
glTexStorage2D
/<>/viewer/objects/EPuckBody.cpp:730:4: error: 'glVertex3f' was 
not declared in this scope
glVertex3f (vertices[vi][1],-vertices[vi][0],vertices[vi][2]);

^~
/<>/viewer/objects/EPuckBody.cpp:730:4: note: suggested 
alternative: 'glVertexAttrib3f'
glVertex3f (vertices[vi][1],-vertices[vi][0],vertices[vi][2]);

^~
glVertexAttrib3f
/<>/viewer/objects/EPuckBody.cpp:733:3: error: 'glEnd' was not 
declared in this scope
   glEnd ();

   ^
/<>/viewer/objects/EPuckBody.cpp:735:2: error: 'glEndList' was not 
declared in this scope
  glEndList();

  ^
viewer/CMakeFiles/enkiviewer.dir/build.make:132: recipe for target 
'viewer/CMakeFiles/enkiviewer.dir/objects/EPuckBody.cpp.o' failed
make[3]: *** [viewer/CMakeFiles/enkiviewer.dir/objects/EPuckBody.cpp.o] Error 1


The root cause is that on armel/armhf (and arm64 in Ubuntu)
Qt5 is compiled with OpenGL ES instead of OpenGL.

enki-aseba should be fixed to build and work with OpenGL ES,
but if this is not easily possible please
- change the build dependency from libqt5opengl5-dev
  to libqt5opengl5-desktop-dev, and
- file a removal bug for the old armel+armhf binaries
  of enki-aseba and aseba against ftp.debian.org

Bug#894855: [Pkg-mailman-hackers] Bug#894855: Bug#894855: Bug#894855: bind(): No such file or directory [core/socket.c line 230]

[Pierre-Elliott Bécue]

Le vendredi 06 avril 2018 à 13:19:31+0200, Pierre-Elliott Bécue a écrit :
> Le vendredi 06 avril 2018 à 12:34:44+0200, Pierre-Elliott Bécue a écrit :
> > Hi,
> > 
> > Thanks for submitting this bug.
> > 
> > Le mercredi 04 avril 2018 à 14:51:21-0700, Purism Sysadmins a écrit :
> > > Package: mailman3-web
> > > Version: 0+20170523-13~bpo9+1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > When I tried to install mailman3-full I got this:
> > > 
> > > ```
> > > Apr 04 12:36:10 lists systemd[1]: mailman3-web.service: Main process 
> > > exited, code=exited, status=1/FAILURE
> > > Apr 04 12:36:10 lists systemd[1]: Failed to start Mailman3-web uWSGI 
> > > service.
> > > Apr 04 12:36:10 lists systemd[1]: mailman3-web.service: Unit entered 
> > > failed state.
> > > Apr 04 12:36:10 lists systemd[1]: mailman3-web.service: Failed with 
> > > result 'exit-code'.
> > > dpkg: error processing package mailman3-web (--configure):
> > >  subprocess installed post-installation script returned error exit status 
> > > 1
> > > dpkg: dependency problems prevent configuration of mailman3-full:
> > >  mailman3-full depends on mailman3-web; however:
> > >   Package mailman3-web is not configured yet.
> > > 
> > > dpkg: error processing package mailman3-full (--configure):
> > >  dependency problems - leaving unconfigured
> > > Processing triggers for libc-bin (2.24-11+deb9u3) ...
> > > Processing triggers for systemd (232-25+deb9u3) ...
> > > Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.36.5-2+deb9u2) ...
> > > Errors were encountered while processing:
> > >  mailman3-web
> > >  mailman3-full
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > > W: Operation was interrupted before it could finish
> > > ```
> > > 
> > > Checking in the logs (/var/log/mailman3/web/mailman-web.log) I got this:
> > > 
> > > ```
> > > *** Starting uWSGI 2.0.14-debian (64bit) on [Wed Apr  4 12:36:10 2018] ***
> > > compiled with version: 6.3.0 20170516 on 17 March 2018 15:41:47
> > > os: Linux-4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> > > nodename: announcements
> > > machine: x86_64
> > > clock source: unix
> > > pcre jit disabled
> > > detected number of CPU cores: 1
> > > current working directory: /
> > > detected binary path: /usr/bin/uwsgi-core
> > > setgid() to 33
> > > setuid() to 33
> > > chdir() to /usr/share/mailman3-web
> > > your processes number limit is 7931
> > > your memory page size is 4096 bytes
> > > detected max file descriptor number: 1024
> > > lock engine: pthread robust mutexes
> > > thunder lock: disabled (you can enable it with --thunder-lock)
> > > bind(): No such file or directory [core/socket.c line 230]
> > > ```
> > > 
> > > My workaround was this:
> > > 
> > > ```
> > > mkdir /run/mailman3/web/
> > > chown www-data:www-data /run/mailman3/web/
> > > ```
> > 
> > Well, this one is reccurrent.
> > 
> > I really understood that the presence of
> > /usr/lib/tmpfiles.d/mailman3-web.conf is supposed to be enough for systemd
> > users.
> > 
> > I'll work on it (mostly, ask for advice) and we'll try to find a definitive
> > solution.
> 
> Thanks to wRAR (Andrey Rahmatullin), I think I have a proper explaination.
> 
> Apparently, this bug is most likely due to debhelper's snippets integration
> in postinst/prerm scripts. It has been reported in[1,2] and fixed in
> debhelper 11.1[3], but dh 11.1.X entered the backports only recently[4]
> 
> Until we rebuild/upload the packages again, there's most likely nothing we
> can do. I'll discuss with Jonas about speeding up the next upload in order
> to have proper postinst/prerm files.
> 
> [1] https://bugs.debian.org/814285
> [2] https://bugs.debian.org/885998
> [3] 
> https://salsa.debian.org/debian/debhelper/blob/648c357c09d109f8b802fe3dd1091b734aa45271/debian/changelog#L64
> [4] 
> https://tracker.debian.org/news/945655/accepted-debhelper-1116bpo91-source-into-stretch-backports/

I'm currently uploading a new release of -suite into unstable. As soon as
it's in the archive, I'll make a proper backport that will close this bug.

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#895498: openvpn fails permanently because it is started too early on system boot and network interface is not (completely) up

[Erik Thiele]

Package: openvpn
Version: 2.4.0-6+deb9u2

when booting the system, systemctl shows openvpn as failed. in the
openvpn logs I find:

TCP/UDP: Socket bind failed on local address
[AF_INET]192.168.90.1:1194: Cannot assign requested address

but in /etc/network/interfaces I have:

auto jacktrunk.13
iface jacktrunk.13 inet static
  address 192.168.90.1
  netmask 255.255.255.0

when restarting openvpn via sysctl restart, everything works fine. So
the network interface is not yet up when openvpn tries to bind to it.
As a workaround I patched:

/lib/systemd/system# diff -u openvpn\@.service~ openvpn\@.service
--- openvpn@.service~   2017-07-18 22:15:17.0 +0200
+++ openvpn@.service2018-04-11 17:39:37.759664731 +0200
@@ -20,6 +20,9 @@
 LimitNPROC=10
 DeviceAllow=/dev/null rw
 DeviceAllow=/dev/net/tun rw
+Restart=on-failure
+RestartSec=10
 
 [Install]
 WantedBy=multi-user.target

Now when rebooting everything works. Checking the logs I find, that the
first try fails as above, and then 10 seconds later the startup is
retried and everything works fine.

I know this is a hack. But maybe it is not possible to arrange systemd
to to the correct ordering in all use cases and a retry every 10 seconds
could be a more robust solution. Dunno.


Best Regards
Erik

Bug#895497: tryton-server fails to install

[Adrian Bunk]

Package: tryton-server
Version: 4.6.3-1
Severity: serious

https://piuparts.debian.org/sid/source/t/tryton-server.html

...
  Preparing to unpack .../tryton-server_4.6.3-1_all.deb ...
  Unpacking tryton-server (4.6.3-1) ...
  Setting up tryton-server (4.6.3-1) ...
  invoke-rc.d: could not determine current runlevel
  invoke-rc.d: policy-rc.d denied execution of start.
  update-rc.d: error: no runlevel symlinks to modify, aborting!
  dpkg: error processing package tryton-server (--configure):
   installed tryton-server package post-installation script subprocess returned 
error exit status 1
  Errors were encountered while processing:
   tryton-server
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#772877: Upstream moved to gitlab

[Petter Reinholdtsen]

Control: tags -1 fixed-upstream

I'm told by upstream this issue was fixed with commit
https://gitlab.xiph.org/xiph/vorbis/commit/e74456acc879665f80d3b9092e5afb4e8335d3a1
 >

I have not had time to verify if this is true, but the upstream bug is
closed now.

-- 
Happy hacking
Petter Reinholdtsen

Bug#895496: mgba FTBFS with Qt 5.10

[Adrian Bunk]

Source: mgba
Version: 0.5.2+dfsg1-3
Severity: serious

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

...
cd /build/1st/mgba-0.5.2+dfsg1/obj-x86_64-linux-gnu/qt && /usr/bin/c++  
-DBUILD_GL -DBUILD_QT_MULTIMEDIA -DBUILD_SDL -DDATADIR=\"share/mgba\" 
-DHAVE_CHMOD -DHAVE_LOCALE -DHAVE_LOCALTIME_R -DHAVE_SETLOCALE -DHAVE_STRDUP 
-DHAVE_STRNDUP -DHAVE_UMASK -DM_CORE_GB -DM_CORE_GBA -DQT_CORE_LIB -DQT_GUI_LIB 
-DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB 
-DQT_WIDGETS_LIB -DUSE_CLI_DEBUGGER -DUSE_FFMPEG -DUSE_GDB_STUB -DUSE_LIBZIP 
-DUSE_LZMA -DUSE_MAGICK -DUSE_PNG -DUSE_PTHREADS -DUSE_ZLIB 
-D_7ZIP_PPMD_SUPPPORT -D_GNU_SOURCE 
-I/build/1st/mgba-0.5.2+dfsg1/obj-x86_64-linux-gnu/qt 
-I/build/1st/mgba-0.5.2+dfsg1/src/platform/qt 
-I/build/1st/mgba-0.5.2+dfsg1/obj-x86_64-linux-gnu/qt/mgba-qt_autogen/include 
-I/build/1st/mgba-0.5.2+dfsg1/src -I/usr/include/editline 
-I/usr/include/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu/ImageMagick-6 
-I/usr/include/ImageMagick-6 -I/usr/lib/x86_64-linux-gnu/libzip/include 
-I/build/1st/mgba-0.5.2+dfsg1/third-party/lzma -I/usr/include/SDL2 
-I/build/1st/mgba-0.5.2+dfsg1/src/platform/sdl -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtOpenGL  -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11   
-fPIC -std=gnu++11 -o CMakeFiles/mgba-qt.dir/MemoryModel.cpp.o -c 
/build/1st/mgba-0.5.2+dfsg1/src/platform/qt/MemoryModel.cpp
/build/1st/mgba-0.5.2+dfsg1/src/platform/qt/MemoryModel.cpp: In member function 
'void QGBA::MemoryModel::setRegion(uint32_t, uint32_t, const QString&, int)':
/build/1st/mgba-0.5.2+dfsg1/src/platform/qt/MemoryModel.cpp:97:17: error: no 
match for 'operator=' (operand types are 'QStaticText' and 'const QString')
  m_regionName = name;
 ^~~~
In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/QStaticText:1:0,
 from 
/build/1st/mgba-0.5.2+dfsg1/src/platform/qt/MemoryModel.h:12,
 from 
/build/1st/mgba-0.5.2+dfsg1/src/platform/qt/MemoryModel.cpp:6:
/usr/include/x86_64-linux-gnu/qt5/QtGui/qstatictext.h:68:18: note: candidate: 
QStaticText& QStaticText::operator=(QStaticText&&)
 QStaticText =(QStaticText &) Q_DECL_NOTHROW { swap(other); 
return *this; }
  ^~~~
/usr/include/x86_64-linux-gnu/qt5/QtGui/qstatictext.h:68:18: note:   no known 
conversion for argument 1 from 'const QString' to 'QStaticText&&'
/usr/include/x86_64-linux-gnu/qt5/QtGui/qstatictext.h:70:18: note: candidate: 
QStaticText& QStaticText::operator=(const QStaticText&)
 QStaticText =(const QStaticText &);
  ^~~~
/usr/include/x86_64-linux-gnu/qt5/QtGui/qstatictext.h:70:18: note:   no known 
conversion for argument 1 from 'const QString' to 'const QStaticText&'
make[3]: *** [qt/CMakeFiles/mgba-qt.dir/build.make:717: 
qt/CMakeFiles/mgba-qt.dir/MemoryModel.cpp.o] Error 1

Bug#895494: kimap FTBFS: symbol disappeared

[Adrian Bunk]

Source: kimap
Version: 17.12.3-1
Severity: serious

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

...
dh_makeshlibs '-Xusr/lib/libkdeinit5_*'  
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libkf5imap5/DEBIAN/symbols doesn't match 
completely debian/libkf5imap5.symbols
--- debian/libkf5imap5.symbols (libkf5imap5_17.12.3-1_amd64)
+++ dpkg-gensymbolsrzXBbk   2019-05-14 17:20:45.321348109 -1200
@@ -1,5 +1,5 @@
 libKF5IMAP.so.5 libkf5imap5 #MINVER#
- _ZN10QByteArray7reserveEi@Base 17.08.0
+#MISSING: 17.12.3-1# _ZN10QByteArray7reserveEi@Base 17.08.0
  _ZN5KIMAP10AclJobBase10setMailBoxERK7QString@Base 15.07.90
  _ZN5KIMAP10AclJobBase11qt_metacallEN11QMetaObject4CallEiPPv@Base 15.07.90
  _ZN5KIMAP10AclJobBase11qt_metacastEPKc@Base 15.07.90
dh_makeshlibs: failing due to earlier errors
make[1]: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:97: 
pre_binary_dh_makeshlibs] Error 2


Why did kimap export a function from QByteArray()?

Bug#895495: libkf5eventviews FTBFS: symbol disappeared

[Adrian Bunk]

Source: libkf5eventviews
Version: 4:17.12.3-1
Severity: serious

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

dh_makeshlibs '-Xusr/lib/libkdeinit5_*'  
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libkf5eventviews5/DEBIAN/symbols doesn't match 
completely debian/libkf5eventviews5.symbols
--- debian/libkf5eventviews5.symbols (libkf5eventviews5_4:17.12.3-1_amd64)
+++ dpkg-gensymbolshYHHUq   2018-04-11 11:02:48.544501361 -1200
@@ -598,7 +598,7 @@
  _ZN10EventViews9MonthViewD0Ev@Base 4:17.12.2
  _ZN10EventViews9MonthViewD1Ev@Base 4:17.12.2
  _ZN10EventViews9MonthViewD2Ev@Base 4:17.12.2
- _ZN10QByteArray7reserveEi@Base 4:17.12.2
+#MISSING: 4:17.12.3-1# _ZN10QByteArray7reserveEi@Base 4:17.12.2
  
(optional=templinst)_ZN12KConfigGroup10writeEntryI10QByteArrayEEvPKcRKT_6QFlagsIN11KConfigBase15WriteConfigFlagEE@Base
 4:17.12.2
  
(optional=templinst)_ZN12KConfigGroup10writeEntryIiEEvPKcRK5QListIT_E6QFlagsIN11KConfigBase15WriteConfigFlagEE@Base
 4:17.12.2
  
(optional=templinst)_ZN12KConfigGroup10writeEntryIiEEvPKcRKT_6QFlagsIN11KConfigBase15WriteConfigFlagEE@Base
 4:17.12.2
dh_makeshlibs: failing due to earlier errors
make[1]: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:97: 
pre_binary_dh_makeshlibs] Error 2


Why did kmime export a function from QByteArray?

Bug#895493: kmime FTBFS: symbol disappeared

[Adrian Bunk]

Source: kmime
Version: 17.12.3-1
Severity: serious

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

...
dh_makeshlibs '-Xusr/lib/libkdeinit5_*'  
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libkf5mime5abi1/DEBIAN/symbols doesn't match 
completely debian/libkf5mime5abi1.symbols
--- debian/libkf5mime5abi1.symbols (libkf5mime5abi1_17.12.3-1_amd64)
+++ dpkg-gensymbolsxA3Agd   2018-04-11 10:56:49.406402045 -1200
@@ -1,6 +1,6 @@
 libKF5Mime.so.5abi1 libkf5mime5abi1 #MINVER#
  ABI_5_1@ABI_5_1 17.12.1
- _ZN10QByteArray7reserveEi@ABI_5_1 17.12.1
+#MISSING: 17.12.3-1# _ZN10QByteArray7reserveEi@ABI_5_1 17.12.1
  _ZN5KMime11NewsArticle10followUpToEb@ABI_5_1 17.12.1
  _ZN5KMime11NewsArticle10newsgroupsEb@ABI_5_1 17.12.1
  _ZN5KMime11NewsArticle10supersedesEb@ABI_5_1 17.12.1
dh_makeshlibs: failing due to earlier errors
make[1]: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:97: 
pre_binary_dh_makeshlibs] Error 2


Why did kmime export a function from QByteArray()?

Bug#895446: Error in startup script: bad screen distance "4.5"

[Torbjörn Andersson]

Michael Biebl  wrote:

> $ gitk
> Error in startup script: bad screen distance "4.5"

Downgrading fontconfig to 2.12.6-0.1 (from 2.13.0-2) fixes this problem 
for me. I don't know what the implications of that are, though.


Torbjörn Andersson

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> 
> 
> El 12 de abril de 2018 6:52:28 CEST, Christian PERRIER  
> escribió:
> >Quoting Laura Arjona Reina (larj...@debian.org):
> >> Hello all
> >> I applied a patch to the dl10n repo in salsa, with a workaround for
> >this
> >> bug (adding the problematic packages to an exclusion list).
> >> However, the material is not being updated, I think because the repo
> >in
> >> tye still uses alioth as origin.
> >> 
> >> Can somebody in the debian-i18n group update the config in
> >> /srv/i18n.debian.org/dl10n/git/ so it uses the salsa repo?
> >> 
> >> (I'm not sure if manual git pull is needed too, or if there is some
> >cron
> >> script that auto-updates the repo at some time. I'm not in the
> >> debian-i18n group so I think I cannot check...
> >
> >
> >Hi Laura,
> >
> >Thanks for your work.
> >
> >I logged in to i18n.d.o, then sudo'ed to debian-i18n, then moved to
> >/srv/i18n.debian.org/dl10n/git
> >
> >"git pull" mentions that the local copy is up-to-date and "git log"
> >says :
> >
> >commit d17144ddc047f48bc4609202bb6e48d04fe92f33
> >Author: David Prévot 
> >Date:   Wed Jan 7 12:12:43 2015 -0400
> >
> >Workaround recent SSL breakage from DSA
> >
> ><1420638006.22794.18.ca...@debian.org>.
> >
> >
> >So, it looks like I can't have your patch make its way to the
> >server:-(
> >
> 
> Please modify the .git/config file to change the origin to salsa instead of 
> alioth:
> 
> https://salsa.debian.org/l10n-team/dl10n.git
> 
> Then save and git pull.

Doh, I'm now in the salsa mess:

debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git pull
fatal: unable to access 'https://salsa.debian.org/l10n-team/dl10n.git/': server 
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
CRLfile: none

(for the record, I didn't move anything of what I personnally
maintain, to salsa: I decided that It's no longer time for me to learn
how to make things work with new stuff..call that lazyness, it's
prrobably more a lack of motivation)

So, well, help is welcomed again, here, sorry for being a n00b.




signature.asc
Description: PGP signature

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Laura Arjona Reina]

El 12 de abril de 2018 6:52:28 CEST, Christian PERRIER  
escribió:
>Quoting Laura Arjona Reina (larj...@debian.org):
>> Hello all
>> I applied a patch to the dl10n repo in salsa, with a workaround for
>this
>> bug (adding the problematic packages to an exclusion list).
>> However, the material is not being updated, I think because the repo
>in
>> tye still uses alioth as origin.
>> 
>> Can somebody in the debian-i18n group update the config in
>> /srv/i18n.debian.org/dl10n/git/ so it uses the salsa repo?
>> 
>> (I'm not sure if manual git pull is needed too, or if there is some
>cron
>> script that auto-updates the repo at some time. I'm not in the
>> debian-i18n group so I think I cannot check...
>
>
>Hi Laura,
>
>Thanks for your work.
>
>I logged in to i18n.d.o, then sudo'ed to debian-i18n, then moved to
>/srv/i18n.debian.org/dl10n/git
>
>"git pull" mentions that the local copy is up-to-date and "git log"
>says :
>
>commit d17144ddc047f48bc4609202bb6e48d04fe92f33
>Author: David Prévot 
>Date:   Wed Jan 7 12:12:43 2015 -0400
>
>Workaround recent SSL breakage from DSA
>
><1420638006.22794.18.ca...@debian.org>.
>
>
>So, it looks like I can't have your patch make its way to the
>server:-(
>

Please modify the .git/config file to change the origin to salsa instead of 
alioth:

https://salsa.debian.org/l10n-team/dl10n.git

Then save and git pull.

Thanks!


>From what I remember, there is no auto update of the local git
>repository copy, it has to be pulled manually.
>
>debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git remote -v
>origin  git://anonscm.debian.org/debian-l10n/dl10n.git (fetch)
>origin  git://anonscm.debian.org/debian-l10n/dl10n.git (push)
>
>I think that, indeed, it would be good if someone more active than me
>would apply to be included in the debian-i18n group

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Hello all
> I applied a patch to the dl10n repo in salsa, with a workaround for this
> bug (adding the problematic packages to an exclusion list).
> However, the material is not being updated, I think because the repo in
> tye still uses alioth as origin.
> 
> Can somebody in the debian-i18n group update the config in
> /srv/i18n.debian.org/dl10n/git/ so it uses the salsa repo?
> 
> (I'm not sure if manual git pull is needed too, or if there is some cron
> script that auto-updates the repo at some time. I'm not in the
> debian-i18n group so I think I cannot check...


Hi Laura,

Thanks for your work.

I logged in to i18n.d.o, then sudo'ed to debian-i18n, then moved to
/srv/i18n.debian.org/dl10n/git

"git pull" mentions that the local copy is up-to-date and "git log"
says :

commit d17144ddc047f48bc4609202bb6e48d04fe92f33
Author: David Prévot 
Date:   Wed Jan 7 12:12:43 2015 -0400

Workaround recent SSL breakage from DSA

<1420638006.22794.18.ca...@debian.org>.


So, it looks like I can't have your patch make its way to the
server:-(

From what I remember, there is no auto update of the local git
repository copy, it has to be pulled manually.

debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git remote -v
origin  git://anonscm.debian.org/debian-l10n/dl10n.git (fetch)
origin  git://anonscm.debian.org/debian-l10n/dl10n.git (push)

I think that, indeed, it would be good if someone more active than me
would apply to be included in the debian-i18n group





signature.asc
Description: PGP signature

Bug#895492: tiemu FTBFS: error: macro "abort" passed 1 arguments, but takes just 0

[Adrian Bunk]

Source: tiemu
Version: 3.04~git20110801-nogdb+dfsg-1
Severity: serious

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

...
gcc -I.. -I -DPREFIX=\"/usr\" -I. -I./core -I./core/uae -I./core/ti_hw 
-I./core/ti_sw -I./core/dbg -I./sound -I./gui -I./gui/calc -I./gui/debugger 
-I./ipc/dcop -I./ipc/dbus -I./ipc/com -I./kde -I./misc -DHAVE_CONFIG_H 
-DSHARE_DIR=\"/usr/share/tiemu\" -DLOCALEDIR=\"/usr/share/locale\" -c -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D__LINUX__ 
-fvisibility=hidden -DGTK_DISABLE_DEPRECATED -DDEBUGGER -DNO_GDB 
-I/usr/include/tilp2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/tilp2 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/tilp2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/tilp2 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/fribidi 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread 
-I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/fribidi 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/libxml2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT  
core/state.c -o core/state.o
In file included from /usr/include/glib-2.0/glib/gutils.h:306:0,
 from /usr/include/glib-2.0/glib/gthread.h:34,
 from /usr/include/glib-2.0/glib/gasyncqueue.h:32,
 from /usr/include/glib-2.0/glib.h:32,
 from core/ti68k_def.h:39,
 from core/ti68k_int.h:31,
 from core/state.c:39:
/usr/include/stdlib.h:588:24: error: macro "abort" passed 1 arguments, but 
takes just 0
 extern void abort (void) __THROW __attribute__ ((__noreturn__));
^

Bug#892656: even more tests fail with version 2.0.2

[Pirate Praveen]

On April 12, 2018 2:48:32 AM GMT+05:30, Paolo Greppi  
wrote:
>Normally you'd expect to fix bugs with a new version, in this case
>while trying to update node-define-property 1.0.0-1 -> 2.0.2 the
>failing tests actually increased from 1 to 4.
>
>What puzzled me was that no tests fail on upstream's CI (travis), which
>also tests nodejs version 8.
>
>Turns out that we have upgraded node-is-descriptor to version 2.0.0,
>but the npm registry only has 1.0.2.
>
>I have forwarded the issue upstream, and I expect upstream to answer
>that define-property correctly pins the major version of is-descriptor
>with ^1.0.2 (https://docs.npmjs.com/misc/semver), stating that it won't
>work with 2.x.
>
>^1.0.2 should be translated with >= 1.0.2 && < 2.0.0 but we can't
>encode that in debian/control.
>
>So how can we check reverse dependencies for this type of issues in the
>future ?
>
>Paolo

build-and-upload script from ruby-team/meta can help if we have enabled tests. 
If we used that, then is-descriptor 1.0 -> 2.0 update would notify the failure 
before upload. But its likely we added is-descriptor 2.0 directly.

The best choice is upstream updating their dependency. Second choice is we 
update and send merge request.

As a worse case, we can downgrade node-is-descriptor to 1.0 if we have no other 
reverse dependency or embed 1.0 in node-define-property.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#895004: dpkg: Dpkg::Version manpage documents workflows that reject version "0"

[Guillem Jover]

Control: severity -1 normal

Hi!

On Fri, 2018-04-06 at 07:18:49 +0200, Niels Thykier wrote:
> Package: dpkg
> Version: 1.19.0.5
> Severity: minor

> There are some examples in Dpkg::Version that (if followed) would
> imply that the problem will reject the version number "0" despite it
> being valid.
> 
> Example:
> """
> boolean evaluation
> When the Dpkg::Version object is used in a boolean evaluation (for 
> example in "if ($v)" or "$v || 'default'") it returns its string 
> representation if the
> version stored is valid ($v->is_valid()) and undef otherwise.
> """
> 
> This gives "surprising" results for version 0, which has a string
> value that is considered false.  To improve the correctness of the
> examples.  I have come to the following alternative examples:
> 
>   -> "if (defined($v) and $v->is_valid())"
>   -> "$v // 'default'"
> 
> Sadly, the "if"-case is no longer elegant but that is the best I could
> come up with that worked if $v is possibly undef and still have it
> work.  However, it no longer serves as a good example for "boolean
> evaluation" (but neither did the original if you want to support the
> version "0").

As mentioned on IRC, the current behavior is just broken, and it was
changed from the correct and expected one to fix a problem in
dpkg-shlibdeps, instead of fixing it there and avoiding breaking
Dpkg::Version users.

I've fixed this now locally, while also making the code emit a warning
so that users can notice the semantic change, it will be possible to
do a targetted silencing of the warning, once the code has been
verified or fixed.

Thanks,
Guillem

Bug#894118: dlib: New upstream release available

[Hugo Lefeuvre]

Hi Séverin,

> Sorry for the long delay with my reply: I've just moved to a new place, and
> I was rather disconnected from the Internet for the last 2 weeks.
> 
> My (freshly created) salsa account is 'skadge'. I've seen you've imported
> the dlib package there. Thank you! You can add me as a collaborator -- that
> said, and if it is fine with you, I'm happy to hand over the maintainership
> to you altogether. Let me know!

Thanks. I have already created a Salsa repository[0] and pushed some changes
for the next Debian release. I'll add you to the contributors tomorrow.

Cheers,
 Hugo

[0] https://salsa.debian.org/hle/dlib

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#475788: listadmin: Please add support for whitelisting senders

[Josh Triplett]

On Wed, Apr 11, 2018 at 06:16:47PM +0200, Johnny A. Solbu wrote:
> On Sat, 12 Apr 2008 16:26:57 -0700 Josh Triplett  wrote:
> > Package: listadmin
> > Version: 2.40-1
> 
> > When I approve mail for a moderated list, I almost always want to
> > whitelist the sender so their mail doesn't end up moderated again.
> > I'd like the option of doing this from listadmin.
> 
> I am the upstream maintainer, and I believe I have just fixed that.
> The new version 2.50 which was just released, can now have an 
> «approved_if_from»
> option in the config file, to automatically approve senders based on the From 
> field.

That's not quite the feature I was looking for. I'm talking about adding
the sender to Mailman's address whitelist, so that their mails don't end
up in the queue again.

Bug#895491: jenkins.debian.org: Update description for kernel variations

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal
Tags: patch

Since the upgrade to stretch(I think), amd64 no longer varies the kernel
version.

Git branch:

  
https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/commit/?h=kernel-variation-update

And patch (since it's a one-liner):

commit 281174711b188444cb5f2947ce875850572eb394
Author: Vagrant Cascadian 
Date:   Wed Apr 11 20:49:04 2018 -0700

Update kernel variation description as amd64 is not currently varied.

diff --git a/bin/reproducible_common.sh b/bin/reproducible_common.sh
index d2f50aef..4c3cb969 100755
--- a/bin/reproducible_common.sh
+++ b/bin/reproducible_common.sh
@@ -474,7 +474,7 @@ write_variation_table() {
write_page "$(cat 
/srv/reproducible-results/node-information/*$a* | grep KERNEL | cut -d '=' -f2- 
| sort -u | tr '\n' '\0' | xargs -0 -n1 echo '')"
done
write_page ""
-   write_page "(on amd64 systematically varied, on 
i386 as well and also with 32 and 64 bit kernel variation, while on armhf not 
systematically)"
+   write_page "(not varied on amd64, on i386 version 
varies as well as 32 and 64 bit kernel variation, while on armhf not 
systematically)"
for a in ${ARCHS} ; do
write_page "on $a one of:"
write_page "$(cat 
/srv/reproducible-results/node-information/*$a* | grep KERNEL | cut -d '=' -f2- 
| sort -u | tr '\n' '\0' | xargs -0 -n1 echo '')"


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#895490: cpufreq problems on Odroid-XU4.

[Vagrant Cascadian]

Package: src:linux
Version: 4.15.11-1
Severity: normal
File: /lib/modules/4.15.0-2-armmp-lpae/kernel/drivers/cpufreq/cpufreq-dt.ko

Accessing files in /sys regarding cpufreq stats doesn't appear to work.

  $ ls -l  /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
  -r--r--r-- 1 root root 4096 Apr 11 20:15 
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
  $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state

And "cat" just sits there indefinitely. Using "cpufreq-info" similarly
hangs indefinitely...

After downgrading to linux-image-4.14.0-0.bpo.3-armmp-lpae
4.14.13-1~bpo9+1 from stretch-backports, accessing cpufreq files in
/sys works as well as "cpufreq-info".

I've observed the same behavior on another Odroid-XU4 board running
stretch.


live well,
  vagrant

-- Package-specific info:
** Version:
Linux version 4.15.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-11)) #1 SMP Debian 4.15.11-1 (2018-03-20)

** Command line:
  console=ttySAC2,115200n8 

** Tainted: D (128)
 * Kernel has oopsed before.

** Kernel log:
[   83.977854] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   83.983924] PC is at 0xe7fddef0
[   83.987046] LR is at notifier_call_chain+0x58/0x94
[   83.991805] pc : []lr : []psr: 20010013
[   83.998043] sp : ed1f59e0  ip : c0eba69c  fp : ed1f5a04
[   84.003249] r10: cf829178  r9 : c10e4a38  r8 : 
[   84.003256] r7 :   r6 : ed1f5a64  r5 : e7fddef0  r4 : 
[   84.003263] r3 : e7fddef0  r2 : ed1f5a64  r1 :   r0 : c0eba69c
[   84.003271] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   84.003291] Control: 30c5387d  Table: 6e7f2a40  DAC: 
[   84.003302] Process systemd-udevd (pid: 384, stack limit = 0xaeec5f83)
[   84.003309] Stack: (0xed1f59e0 to 0xed1f6000)
[   84.003319] 59e0:  c10e4a40 ed1f5a64 cf829100 c10e49e0 c10e4a38 
ed1f5a2c ed1f5a08
[   84.003329] 5a00: c029a51c c0299b58  c10e4c10 ed1f5a2c ed1f5a64 
c115ef38 
[   84.003339] 5a20: ed1f5a5c ed1f5a30 c08376a8 c029a4d4 ed1f5a5c ed1f5a40 
c083563c cf829100
[   84.003348] 5a40: c1005dd8 c10e4c10 c115ef38 c10e49e0 ed1f5b84 ed1f5a60 
c0837d28 c0837630
[   84.003357] 5a60:  000f 000f 000f   
ed2de700 0013d620
[   84.003367] 5a80: 00030d40 00025990 00030d40 0013d620 000c3500  
 
[   84.003375] 5aa0:  c10e4c10     
 ffe0
[   84.003384] 5ac0: cf82915c cf82915c c0837a50 00030d40 0013d620 cfe52e40 
0001 c10e4a38
[   84.003393] 5ae0: c10e4a38 ed2debc0 cf829184 cf829184 ee34ce40  
c10e4a70 cfcece40
[   84.003401] 5b00: 0001 0003   cf8291ac cf8291ac 
0001 cf8291b8
[   84.003410] 5b20: cf8291b8   ed1d8f00   
0001 
[   84.003418] 5b40:     cf8291ec cf8291ec 
 ed2de340
[   84.003426] 5b60: ed2de280 af3200b3  cf829100  c10e4a38 
ed1f5bcc ed1f5b88
[   84.003435] 5b80: c0838308 c0837cac  c1005dd8   
cf8291b4 60010013
[   84.003444] 5ba0: c04d38b0  c10d66bc c1005dd8 ee262600 ee262638 
c10e4a28 ee262638
[   84.003452] 5bc0: ed1f5bec ed1f5bd0 c0838524 c0837d94 c073cc08 c09cc244 
c10e4a20 c10e4a20
[   84.003460] 5be0: ed1f5c2c ed1f5bf0 c073da90 c08384a8 ee262658 ee45f734 
 af3200b3
[   84.003470] 5c00: c09e1d34 bf46a03c c115ef38 ee7d9c00 c10e49e0 bf46a0c0 
 0036
[   84.003479] 5c20: ed1f5c54 ed1f5c30 c08361ac c073d9d4 ed1f5c54 ed1f5c40 
 eed69020
[   84.003488] 5c40: ee7d9c00 fdfb ed1f5c74 ed1f5c58 bf468638 c0836034 
ee7d9c10 ffed
[   84.003497] 5c60: bf46a0c0 fdfb ed1f5c94 ed1f5c78 c0741470 bf4685b0 
ee7d9c10 c115dc9c
[   84.003506] 5c80: c115dca0  ed1f5ccc ed1f5c98 c073f024 c074141c 
c09e1d34 c02f1cc4
[   84.003516] 5ca0: ee7d9c44 ee7d9c44 ee7d9c10 bf46a0c0 c1005dd8 bf46d000 
bf46a1c0 c1005dd8
[   84.003525] 5cc0: ed1f5cec ed1f5cd0 c073f268 c073ed1c  bf46a0c0 
c073f198 c1005dd8
[   84.003534] 5ce0: ed1f5d1c ed1f5cf0 c073ca94 c073f1a4 ee262a6c ee262a58 
ee730d34 af3200b3
[   84.003542] 5d00: bf46a0c0 c10d6630 cfeca700  ed1f5d2c ed1f5d20 
c073e774 c073ca30
[   84.003550] 5d20: ed1f5d54 ed1f5d30 c073e100 c073e754 bf4693b0 ed1f5d40 
bf46a0c0 
[   84.003559] 5d40: e000 ed2def00 ed1f5d6c ed1f5d58 c073ffd0 c073df54 
c1005dd8 
[   84.003568] 5d60: ed1f5d7c ed1f5d70 c07413b8 c073ff54 ed1f5d8c ed1f5d80 
bf46d024 c0741374
[   84.003576] 5d80: ed1f5e04 ed1f5d90 c02021a8 bf46d00c c03e1d94 c09e1d34 
 0001
[   84.003585] 5da0: ed1f5dc4 ed1f5db0 c09e1d34 c02f1cc4 014000c0 c042c0ec 
ed1f5e04 ed1f5dc8
[   84.003593] 5dc0: c042c0ec c0442940 0001 c040d91c eac24e04 eac24504 
ed0e1080 af3200b3
[   84.003602] 5de0: bf46a1c0 0001 ed2de8c0 ed2def00 ed2de8e4 bf46a1c0 
ed1f5e2c ed1f5e08
[   84.003610] 5e00: c031b29c c0202150 ed1f5e2c 

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[peter green]

This was blocking stuff up in Raspbian buster so I decided to take a look.

I decided to base my work on the version currently in Debian experimental.

First of all I reduced the exiv2 dependency in both the Debian packaging and 
the upstream cmake to 0.25.

I then turned my attention to the kdepim problem. After some time messing 
around with upstreams broken git history I was able to locate the relevent 
patches, merge them together and fix-up the filepaths. They then applied 
cleanly.

I then ran into another build failure.

In file included from /usr/include/c++/7/cmath:45:0,
 from /usr/include/c++/7/math.h:36,
 from 
/digikam-5.7.0/core/libs/rawengine/libraw/internal/dcraw_common.cpp:22:
/usr/include/arm-linux-gnueabihf/bits/mathcalls.h:140:1: note: candidate: 
_Float64 powf64(_Float64, _Float64)
 __MATHCALL_VEC (pow,, (_Mdouble_ __x, _Mdouble_ __y));
 ^
/digikam-5.7.0/core/libs/rawengine/libraw/internal/dcraw_common.cpp:5752:14: 
note: candidate: float powf64(float, float)
 static float powf64(float a, float b)

it looks like there is a conflict between a function called "powf64" in the dcraw code in 
digikam and a "powf64" function in the kernel headers upstream fixed this by renaming 
powf64 to libraw_powf64, I did the same. In this case since it was a simple rename I did not bother 
going digging for the original upstream patch.

I am currently doing a final build with the changes, assuming it suceeds I will 
upload it to Raspbian and post a
debdiff to this bug.

No intent to NMU in Debian.

Bug#877467: Odroid-XU4: success despite several challenges

[Vagrant Cascadian]

Package: installation-reports
Followup-For: Bug #877467

Tested same model board with a newer debian-installer and buster, and
this install went a bit easier(mostly due to USB being fixed in the
current kernels), but still had many of the same problems.

Modules needed to detect the ethernet adapter were still not present in
the netboot image. There was a confusing message about partitioning
location. The boot firmware was overwritten as part of the install, but
I suspect that is an old vendor conflict with dos partition tables that
should be fixed in more recent versions of the firmware.


live well,
  vagrant

-- Package-specific info:

Boot method: network
Image version: 
https://d-i.debian.org/daily-images/armhf/20180411-00:11/netboot/netboot.tar.gz
Date: 2018-04-11

Machine: Odroid-XU4
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1002724   0   1002724   0% /dev
tmpfs  tmpfs   2041045392198712   3% /run
/dev/sda3  ext4   4740148 1227768   3251880  28% /
tmpfs  tmpfs  1020508   0   1020508   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  1020508   0   1020508   0% /sys/fs/cgroup
/dev/mmcblk1p3 ext4464790   50855385417  12% /boot
tmpfs  tmpfs   204100   0204100   0% /run/user/1000

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

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

Comments/Problems:

The modules included on the netboot initrd didn't include enough to
actually load the modules for the ethernet adapters. Appending all the
kernel modules for that kernel version to the initrd worked around the
problem, and ethernet detected fine.

Modules from non-working install:

Module  Size  Used by
dwc3_exynos16384  0
ohci_exynos16384  0
ohci_hcd   45056  1 ohci_exynos
ehci_exynos16384  0
ehci_hcd   77824  1 ehci_exynos
dw_mmc_exynos  16384  0
dw_mmc_pltfm   16384  1 dw_mmc_exynos
usbcore   204800  4
ehci_exynos,ehci_hcd,ohci_hcd,ohci_exynos
dw_mmc 36864  2 dw_mmc_pltfm,dw_mmc_exynos
phy_exynos_usb220480  2
usb_common 16384  1 usbcore
phy_exynos5_usbdrd 16384  0

Modules from working install:

Module  Size  Used by
sd_mod 45056  0
uas20480  0
usb_storage53248  1 uas
scsi_mod  196608  3 sd_mod,usb_storage,uas
cdc_ether  16384  0
usbnet 32768  1 cdc_ether
r8152  57344  0
mii16384  2 usbnet,r8152
snd_soc_hdmi_codec 16384  0
snd_soc_core  163840  1 snd_soc_hdmi_codec
xhci_plat_hcd  16384  0
snd_pcm_dmaengine  16384  1 snd_soc_core
snd_pcm90112  3 
snd_pcm_dmaengine,snd_soc_hdmi_codec,snd_soc_core
snd_timer  28672  1 snd_pcm
xhci_hcd  196608  1 xhci_plat_hcd
snd61440  4 
snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm
soundcore  16384  1 snd
dwc3  102400  0
udc_core   36864  1 dwc3
phy_generic16384  0
clk_s2mps1116384  0
s2mps1157344  17
dwc3_exynos16384  0
phy_exynos_mipi_video16384  0
phy_exynos_dp_video16384  0
ohci_exynos16384  0
ohci_hcd   45056  1 ohci_exynos
ehci_exynos16384  0
ehci_hcd   77824  1 ehci_exynos
exynosdrm  90112  0
analogix_dp36864  1 exynosdrm
drm_kms_helper135168  2 exynosdrm,analogix_dp
drm   335872  4 exynosdrm,analogix_dp,drm_kms_helper
pwm_samsung16384  2
exynos_adc 24576  0
i2c_exynos516384  0
industrialio   57344  1 exynos_adc
dw_mmc_exynos  16384  0
dw_mmc_pltfm   16384  1 dw_mmc_exynos
usbcore   204800  11
ehci_exynos,usbnet,usb_storage,ehci_hcd,cdc_ether,xhci_plat_hcd,uas,ohci_hcd,ohci_exynos,r8152,xhci_hcd
usb_common 16384  3 udc_core,usbcore,dwc3
dw_mmc 36864  2 dw_mmc_pltfm,dw_mmc_exynos
phy_exynos_usb220480  2
phy_exynos5_usbdrd 16384  4
s3c2410_wdt16384  0
evdev  24576  0
leds_pwm   16384  0
pwm_fan16384  0
cpufreq_dt 16384  0


After finalizing partitioning, there was a confusing prompt about the
start location of the partition, but the instructions to fix it didn't
make much

Bug#895489: nmu: kodi (libnfs transition)

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu transition
X-Debbugs-CC: rbal...@ubuntu.com

Please rebuild kodi for the libnfs transition. It doesn't show up
because its dependency on the libnfs library is only a recommends.

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

Thanks,
Jeremy Bicha

Bug#895488: RFP: libghc-rate-limit -- A basic library for rate-limiting IO actions

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: libghc-rate-limit
  Version : 1.4.0
  Upstream Author : Adam Wick 
* URL : https://hackage.haskell.org/package/rate-limit
* License : BSD-3-Clause
  Programming Lang: Haskell
  Description : A basic library for rate-limiting IO actions

In many cases, it is useful, necessary, or simply nice to limit how
frequently you perform some action. For example, you may want to limit
how often your program makes a request of some web site. This library
is intended as a general-purpose mechanism for rate-limiting IO
actions.

--

According to Clint, this will be required for the new taffybar package
(#895264).

I do not plan on maintaining this, and hope someone will magically
step up to do so. :) But I would certainly use the resulting taffybar,
which I'm pretty excited about...

Bug#895474: Fontconfig errors

[brian m. carlson]

I've also seen these errors, except that they're showing up in my tmux
panes, which is significantly more annoying than .xsession-errors.  This
is probably because vim-gtk3 (gvim) links to libfontconfig1.

libfontconfig definitely shouldn't be producing errors to stdout or
stderr unless specifically requested by the calling application.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#895487: libpoppler-glib8: poppler 0.62 has very slow cairo rendering

[Rogério Brito]

Package: libpoppler-glib8
Version: 0.62.0-2
Severity: important
Tags: upstream

Hi.

With moderately recent versions of poppler (approximately from 0.60 to 0.62,
but possibly earlier than 0.60), poppler has changed the Cairo rendering
from using the GOOD downscaling to BEST downscaling.

This affects potentially the usability of all PDF files that contain scanned
pages by slowly presenting them (especially on less powerful machines, but
also on amd64 machines).

The problem is recognized upstream [0] and the change [1] was reverted in
version 0.63 [2] of poppler.  In fact, even cairo's documentation says that
BEST "may not be suitable for interactive use" [3].


[0]: https://bugs.freedesktop.org/show_bug.cgi?id=103136
[1]: 
https://cgit.freedesktop.org/poppler/poppler/commit/?id=4afe2fb10ab969bfd9895c0ba9d4990c5881b451
[2]: 
https://cgit.freedesktop.org/poppler/poppler/tree/NEWS?id=f26285f361478219ea9d3c6de1529ecd5ff96ac9#n5
[3]: 
https://www.cairographics.org/manual/cairo-cairo-pattern-t.html#cairo-filter-t


Note that the qt5 version of the package doesn't contain this slowdown and,
for parity between versions (tested with qpdfview), it would be nice to
have similar performance between, say, evince/atril and qpdfview...

Given the small patch (as shown in [1]), can we have this updated in Debian
as soon as possible, before a new upstream version is uploaded to the
archive (which would, quite possibly need a new transition etc.)?


Thanks in advance,

Rogério.

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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 libpoppler-glib8 depends on:
ii  libc6 2.27-3
ii  libcairo2 1.15.10-1
ii  libfreetype6  2.8.1-2
ii  libglib2.0-0  2.56.0-4
ii  libpoppler73  0.62.0-2
ii  libstdc++68-20180402-1

libpoppler-glib8 recommends no packages.

libpoppler-glib8 suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#895429: nvidia-kernel-dkms: doesn't build with linux 4.16 from experimental (missing symbol swiotlb_map_sg_attrs)

[Jiri Palecek]

On 4/11/18 4:07 PM, Luca Boccassi wrote:

On Wed, 11 Apr 2018 14:57:56 +0200 Jiri Palecek 
wrote:

Package: nvidia-kernel-dkms
Version: 390.42-1
Severity: normal
  


390.48 has been in unstable and testing for a while, have you tried
with it?


In unstable, not testing. Anyway, I just tried it and it's just the same.

Regards

    Jiri Palecek

Bug#895486: openvas-manager: dpkg fails to upgrade if existing certificate infrastructure is present

[Francesco]

Package: openvas-manager
Version: 7.0.2-4
Severity: minor

Dear Maintainer,


   apt-get update
   apt-get dist-upgrade

   Configurazione di openvas-manager (7.0.2-4)...
Creating openvas-scanner's certificate files
Existing certificate infrastructure found, aborting.
Use '-f' parameter to overwrite existing certificates.
dpkg: errore nell'elaborare il pacchetto openvas-manager (--configure):
 installed openvas-manager package post-installation script subprocess returned 
error exit status 1
Si sono verificati degli errori nell'elaborazione:
 openvas-manager
E: Sub-process /usr/bin/dpkg returned an error code (1)

(Sorry if some messages are in italian, I think you should be able to
understand since only apt related messages are translated)

To see certificates installed:

# openvas-manage-certs -V
OK: Directory for keys (/var/lib/openvas/private/CA) exists.
OK: Directory for certificates (/var/lib/openvas/CA) exists.
OK: CA key found in /var/lib/openvas/private/CA/cakey.pem
OK: CA certificate found in /var/lib/openvas/CA/cacert.pem
ERROR: CA certificate failed verification, see 
/tmp/tmp.2QE82PaD12/openvas-manage-certs.log for details. Aborting.
ERROR: Certificate /var/lib/openvas/CA/servercert.pem failed verification, see 
/tmp/tmp.2QE82PaD12/openvas-manage-certs.log for details. Aborting.

ERROR: Your OpenVAS certificate infrastructure did NOT pass validation.
   See messages above for details.

so I tried to find what command in post-install script could be:

kpc:/var/lib/openvas/CA# openvas-manage-certs -a
Existing certificate infrastructure found, aborting.
Use '-f' parameter to overwrite existing certificates.

and solved with

openvas-manage-certs -f -a

I don't know if it was a problem with my old certificates but you should
consider having the "-f" option presented in post install script.



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

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

Versions of packages openvas-manager depends on:
ii  doc-base0.10.8
ii  libassuan0  2.5.1-2
ii  libc6   2.27-3
ii  libglib2.0-02.56.0-4
ii  libgnutls30 3.5.18-1
ii  libgpg-error0   1.28-2
ii  libgpgme11  1.10.0-2
ii  libopenvas9 9.0.1-4
ii  libsqlite3-03.23.0-1
ii  lsb-base9.20170808
ii  openvas-manager-common  7.0.2-4

openvas-manager recommends no packages.

openvas-manager suggests no packages.

-- no debconf information

Bug#895485: booth: move out of asciidoc

[Joseph Herlant]

Package: booth
Version: 1.0-6
Severity: wishlist
Control: block 895462 by -1
Control: forwarded -1 https://github.com/ClusterLabs/booth/pull/67

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

I pushed a PR to upstream (see forwarded field), so when it's in and
released you can migrate more easily.
Note that I'm not sure you'll need docbook-* and xsltproc as
dependencies anymore once you're done.

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks

Bug#895237: [Letsencrypt-devel] Bug#895237: certbot: Stop/start Apache using systemctl instead of apachectl

[Harlan Lieberman-Berg]

reassign 895237 apache2 2.4.33-1
retitle 895237 apache2: apachectl does not use systemd for restarts
affects 895237 certbot
thanks

Hi Jan,

Hm, looks like this is actually a bug over in apache-land.  We do the right
thing for `apachectl start` in terms of wrapping to use systemd, but we
don't do that during `apachectl restart`.

Apache folx, can we potentially just turn restart into a shim that calls
`apachectl stop` and `apachectl start`?  That will solve the problem with
the least amount of fuss.

Sincerely,

On Sun, Apr 8, 2018 at 12:51 PM, Jan Heitkötter  wrote:

> Package: certbot
> Version: 0.21.1-1~bpo9+1
> Severity: normal
>
> Dear Maintainer,
>
> on certificate renewal certbot will stop Apache and start it afterwards.
> The relevant commands are pre_hook and post_hook in
> /etc/letsencrypt/renewal/CERTNAME.conf.
>
> Default behaviour is do stop/start Apache using apachectl which fails in
> installations running systemd. Apache will stop, but not start again.
>
> Fix: use systemctl to start/stop Apache.
>
> Regards
>
> Jan
>
>
> -- System Information:
> Debian Release: 9.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages certbot depends on:
> ii  python3  3.5.3-1
> ii  python3-certbot  0.21.1-1~bpo9+1
>
> certbot recommends no packages.
>
> Versions of packages certbot suggests:
> pn  python-certbot-doc  
> ii  python3-certbot-apache  0.21.1-1~bpo9+1
> pn  python3-certbot-nginx   
>
> -- no debconf information
>
> ___
> Letsencrypt-devel mailing list
> letsencrypt-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel
>
> --
> Harlan Lieberman-Berg
> ~hlieberman
> 

Bug#893578: 0.7.7 Regression

[Chris Zubrzycki]

On Tue, 10 Apr 2018 07:17:53 -0600 Chris Dos  wrote:
> 0.7.7 had a critical regression.  0.7.8 is out now.
> 
>   Chris
> 
> 

If possible please also include this small off-by-1 patch that was accepted 
into upstream: https://github.com/zfsonlinux/zfs/pull/7417

Bug#895483: Directory '/usr/lib/jvm/java-9-openjdk-amd64/lib/server' not empty so not removed

[積丹尼 Dan Jacobson]

Package: openjdk-9-jre-headless
Version: 8u162-b12-1
Severity: minor

dpkg: warning: while removing openjdk-9-jre-headless:amd64, directory 
'/usr/lib/jvm/java-9-openjdk-amd64/lib/server' not empty so not removed
Purging configuration files for openjdk-8-jre-headless:amd64 (8u162-b12-1) ...

$ find /usr/lib/jvm/java-9-openjdk-amd64/
/usr/lib/jvm/java-9-openjdk-amd64/
/usr/lib/jvm/java-9-openjdk-amd64/lib
/usr/lib/jvm/java-9-openjdk-amd64/lib/server
/usr/lib/jvm/java-9-openjdk-amd64/lib/server/classes.jsa

Bug#895484: ITP: cutelyst -- Qt Web Framework

[Simon Quigley]

Package: wnpp
Severity: wishlist
Owner: Simon Quigley 

* Package name: cutelyst
  Version : 2.1.0
  Upstream Author : Daniel Nicoletti
* URL : https://cutelyst.org
* License : LGPLv2+, MIT
  Programming Lang: C++
  Description : Qt Web Framework

I plan on maintaining this under the Debian Qt/KDE Team umbrella,
specifically under the Qt Extras umbrella.

Uploading this to Debian is by the request of the upstream author; they
had packaged it for Debian/Ubuntu and I agreed to help them get it into
the official repositories.

Thank you,
-- 
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#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi,

Axel Beckert wrote:
> On other sid installations (including architectures amd64, i386 and
> armhf), the upgrade worked fine, […]

Correction: It failed on one i386 sid machine, too:

Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/GeoTrust_Global_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_1.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_EV_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
rehash: skipping Swisscom_Root_CA_1.pem, cannot open file
rehash: skipping Swisscom_Root_CA_2.pem, cannot open file
rehash: skipping GeoTrust_Global_CA_2.pem, cannot open file
rehash: skipping Swisscom_Root_EV_CA_2.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
Errors were encountered while processing:
 ca-certificates

Still, it worked fine on at least one amd64 and one armhf machine.

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

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Laura Arjona Reina]

Hello all
I applied a patch to the dl10n repo in salsa, with a workaround for this
bug (adding the problematic packages to an exclusion list).
However, the material is not being updated, I think because the repo in
tye still uses alioth as origin.

Can somebody in the debian-i18n group update the config in
/srv/i18n.debian.org/dl10n/git/ so it uses the salsa repo?

(I'm not sure if manual git pull is needed too, or if there is some cron
script that auto-updates the repo at some time. I'm not in the
debian-i18n group so I think I cannot check...

Cheers
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Package: ca-certificates
Version: 20180409
Severity: serious

Upgrading ca-certificates from 20170717 to 20180409 fails for me as
follows on one machine:

Before unpacking, I have been shown this dialog, which I acknowledged
by pressing enter:

  ┌┤ ca-certificates configuration 
├─┐
  │ During upgrades, new certificates will be added. Please choose 
those you trust.  │
  │ 
 │
  │ New certificates to activate:   
 │
  │ 
 │
  │[ ] mozilla/GDCA_TrustAUTH_R5_ROOT.crt   
 │
  │[ ] mozilla/SSL.com_EV_Root_Certification_Authority_ECC.crt  
 │
  │[ ] mozilla/SSL.com_EV_Root_Certification_Authority_RSA_R2.crt   
 │
  │[ ] mozilla/SSL.com_Root_Certification_Authority_ECC.crt 
 │
  │[ ] mozilla/SSL.com_Root_Certification_Authority_RSA.crt 
 │
  │[ ] mozilla/TrustCor_ECA-1.crt   
 │
  │[ ] mozilla/TrustCor_RootCert_CA-1.crt   
 │
  │[ ] mozilla/TrustCor_RootCert_CA-2.crt   
 │
  │ 
 │
  │ 
 │
  │ 
 │
  │ 
 │
  
└──┘

Unpacking went fine:

Preparing to unpack .../04-ca-certificates_20180409_all.deb ...
Unpacking ca-certificates (20180409) over (20170717) ...

The first as well as the second try to configure ca-certificates
failed identically:

Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/AddTrust_Public_Services_Root.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/AddTrust_Qualified_Certificates_Root.crt 
not found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/UTN_USERFirst_Hardware_Root_CA.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt not found, but listed 
in /etc/ca-certificates.conf.
rehash: skipping DST_ACES_CA_X6.pem, cannot open file
rehash: skipping AddTrust_Qualified_Certificates_Root.pem, cannot open file
rehash: skipping UTN_USERFirst_Hardware_Root_CA.pem, cannot open file
rehash: skipping AddTrust_Public_Services_Root.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
[…]
Errors were encountered while processing:
 ca-certificates
[…]
E: Sub-process /usr/bin/dpkg returned an error code (1)
[…]
Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/AddTrust_Public_Services_Root.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/AddTrust_Qualified_Certificates_Root.crt 
not found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/UTN_USERFirst_Hardware_Root_CA.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt not found, but listed 
in /etc/ca-certificates.conf.
rehash: skipping DST_ACES_CA_X6.pem, cannot open file
rehash: skipping AddTrust_Qualified_Certificates_Root.pem, cannot open file
rehash: skipping UTN_USERFirst_Hardware_Root_CA.pem, cannot open file
rehash: skipping AddTrust_Public_Services_Root.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
Errors were encountered while processing:
 ca-certificates

On other sid installations (including architectures amd64, i386 and
armhf), the upgrade worked fine, despite most (if not all) of my
systems have similar ca-certificates settings, namely
"ca-certificates/trust_new_crts: ask" and just a few CAs
selected. It's though very likely that the actual list of CAs differs
from installation to installation as I enabled further ones per
machine as needed.

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

Bug#895478: gnome-screensaver: package Description should mention that it is not part of GNOME 3

[Justin B Rye]

Simon McVittie wrote:
> Here is an attempt at a more current description:
> 
>  Screensaver and screen lock formerly used in GNOME
> 
>  gnome-screensaver is a simple screen saver and screen lock, used in older
>  versions of the GNOME desktop environment.
>  .
>  It is designed to support, among other things:
>  .
>   * the ability to lock down configuration settings
>   * translation into other languages
>   * user switching
>  .
>  This package is not necessary in the GNOME desktop environment, because
>  GNOME Shell contains its own screen lock implementation. It is
>  used by lighter-weight desktop environments such as GNOME Flashback.

For me (and most of the people I see considering this question on the
net) that has to be "more lightweight", not "lighter-weight"...

And is it a matter of "It is used" or "It can be used"?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#895481: cinnamon-settings-daemon: runs gnome-power-statistics without a dependency and via the old desktop file name

[Simon McVittie]

Source: cinnamon-settings-daemon
Version: 3.6.2-1
Severity: normal

While checking what gnome-power-manager does and whether it's still a
desirable package to have, I tried asking codesearch.debian.net
what runs its one remaining binary (gnome-power-statistics).

It appears that cinnamon-settings-daemon tries to run
gnome-power-statistics via its .desktop file. However, it is using the
old .desktop filename, gnome-power-statistics.desktop, which changed
to org.gnome.PowerStats in GNOME 3.22; so I don't think this has worked
since before stretch.

cinnamon-settings-daemon also does not have a (strong or weak) dependency
on the gnome-power-manager package. It should perhaps have a Suggests,
at least?

smcv

Bug#895480: gnome-power-manager: package Description is outdated and misleading

[Simon McVittie]

Package: gnome-power-manager
Version: 3.4.0-2
Severity: normal
X-Debbugs-Cc: debian-l10n-engl...@lists.debian.org, 
debian-gtk-gn...@lists.debian.org

gnome-power-manager's Description says:

>Description: power management tool for the GNOME desktop
> GNOME Power Manager is a session daemon for the GNOME desktop
> that takes care of system or desktop events related to power, and
> triggers actions accordingly. Its philosophy is to completely hide
> these complex tasks and only show some settings important to the user.
> .
> GNOME power manager displays and manages battery status, power plug
> events, display brightness, CPU, graphics card and hard disk drive
> power saving, and can trigger suspend-to-RAM, hibernate or shutdown
> events, all integrated to other components of the GNOME desktop.

However, this hasn't been true since oldoldstable. The power management
daemon functionality was moved to gnome-settings-daemon in GNOME 3.2,
and the daemon was deleted from gnome-power-manager, leaving only the
gnome-power-statistics application.

I think the description should be more like this:

"""
Description: power statistics viewer for the GNOME desktop
 GNOME Power Statistics displays detailed information about battery
 status, including charging and discharging rates.
 .
 This package previously contained background services that triggered
 actions in response to power-related events, but the
 gnome-settings-daemon package is now responsible for providing those
 services.
"""

Perhaps the package should also be renamed to gnome-power-statistics,
with a transitional gnome-power-manager package that depends on
gnome-power-statistics and gnome-settings-daemon. That would incidentally
also resolve  by providing a way to get
the gnome-power-statistics tool without gnome-settings-daemon.

(I'm not sure how maintained this package is any more; it had a release
earlier this year, but very little is changing, and there are plans
upstream for gnome-usage to grow a Power panel, which would mostly
obsolete gnome-power-statistics.)

smcv

Bug#895455: Pending fixes for bugs in the gradle package

[pkg-java-maintainers]

tag 895455 + pending
thanks

Some bugs in the gradle package are closed in revision
a787cb7b8b60bbc6928faa90639cead0675833ca in branch 'master' by Markus
Koschany

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

Commit message:

Update groovy-jar.patch and fix runtime errors with new Groovy versions.

Closes: #895455

Bug#895452: gcc-7: libquadmath is disabled for gcc 7.3.0 on powerpc64-linux-gnu

[Dennis Clarke]

On 11/04/18 04:52 PM, Matthias Klose wrote:

On 11.04.2018 19:04, Dennis Clarke wrote:

Package: gcc-7
Version: 7.3.0-15
Severity: important

Dear Maintainer,

* What led up to the situation?

Attempt to compile a trivial code test that uses #include 
as well as _Float128 datatype and quadmath_snprintf() call fails with

  fatal error: quadmath.h: No such file or directory


I have dark memories, that quadmath didn't build. Please could you check that
again with a native build and a cross build, if you have access to a ppc64 
platform?



I am working on it. I need to get past some new silly dependency that
makes little sense given that the bootstrap fails in stage 3 of all
places :

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686

So I should ( in theory ) be able to build the gc code in place and in 
the tree in the same manner as gmp, mpfr, mpc and isl.  So I am working

on that but it just isn't working.

In any case I'll get the sources from http://www.hboehm.info/gc/ and 
keep hacking at this on ppc64.


Dennis

Bug#895479: ayatana-indicator-power: runs gnome-power-statistics but does not depend on it

[Simon McVittie]

Package: ayatana-indicator-power
Version: 2.0.93-2
Severity: normal

While checking what gnome-power-manager does and whether it's still a
desirable package to have, I tried asking codesearch.debian.net
what runs its one remaining binary (gnome-power-statistics). It appears
that ayatana-indicator-power tries to run gnome-power-statistics in
GNOME and Unity sessions. However, it does not have a (strong or weak)
dependency on the gnome-power-manager package, and neither do GNOME
metapackages other than gnome-session-flashback.

(I'm also a little concerned that this

  char *cmd = g_strconcat ("gnome-power-statistics", " --device ",
   g_variant_get_string (param, NULL), NULL);
  execute_command (cmd);

might be susceptible to unintended shell injection. Please consider
using an argv-based API like GSubprocess, or at least quote arguments
that are interpolated into a /bin/sh command with g_shell_quote().)

smcv

Bug#879176: transition: lz4

[Nobuhiro Iwamatsu]

Hi, all.

2017-10-23 10:04 GMT+09:00 Nobuhiro Iwamatsu :
> Hi, all.
>
> Thanks for your comment.
>
> 2017-10-22 1:37 GMT+09:00 Emilio Pozuelo Monfort :
>> Control: tags -1 moreinfo
>>
>> On 20/10/17 11:13, Mattia Rizzolo wrote:
>>> On Fri, Oct 20, 2017 at 12:32:06PM +0900, Nobuhiro Iwamatsu wrote:
 I'd like to push lz4 1.8.0 into unstable.
 The library packge name has not changed since the previous version. 
 However,
 some API have been removed . Therefore, lz4 1.8.0 requires transition
 processing,
>>>
>>> Since, as the symbols diff you attached, this version removes symbols,
>>> therefore breaking the ABI, shouldn't the SONAME be changed as well,
>>> together with the package name (i.e. liblz4-1 → liblz4-2).
>>
>> Yes, if symbols are removed, then the ABI is broken and the library needs to
>> bump the SONAME. Worst case, if upstream doesn't want to bump it, you can 
>> rename
>> the package to e.g. liblz4-1a, with Conflicts/Breaks/Replaces against 
>> liblz4-1.
>> The SONAME bump is preferred though so that liblz4-1 and liblz4-2 are
>> co-installable, which eases both the transition and upgrades.
>
> I see. I undetstood.
>
>>
>> We could ignore the fact that symbols were removed IF those symbols weren't 
>> part
>> of the public ABI (e.g. they weren't exported in the public headers). Which
>> seems to be the case here from a quick grep, but I don't know this library 
>> well
>> enough to affirm that...
>
> OK, I will check the dependencies of the library and the software that uses 
> it.
>

I checked the binary and source code of packages that depend on lz4 and
I confirmed that they do not affect the ABI changed this time.
Therefore, we do not need to do transition.
And Julian's comment, we can see that we do not need to do this.
Thanks, Julian.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name

[Francois Gouget]

reopen #770265

This bug is still present in Debian 9.4 which is the official stable 
release of Debian, the one that people are supposed to use.

This despite the bug being known 4 years before the Debian 9.4 release!
This despite the bug breaking package management!
This despite a fix being known and implemented!

So until this bug is fixed in the Debian release everyone uses I don't 
think it should be closed.


-- 
Francois Gouget   http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

On 05 Apr 2018, Jürgen Göricke wrote:

>Oh, I'm so surprised! Because the error message suggests otherwise.

I still do not understand what prevents .m3u URLs (such as the one
you want to use) from being played correctly on pragha, but I collected
some extra information and I have a workaround for you.

First, the workaround:

Use curl to display what's in your .m3u URL:

$ curl http://media-ice.musicradio.com/ClassicFMMP3.m3u 
http://media-the.musicradio.com:80/ClassicFMMP3

Then use this URL, instead of the original, to test your gstreamer installation:

$ gst-launch-1.0 -v playbin 
uri=http://media-the.musicradio.com:80/ClassicFMMP3

You can add this link to Pragha and it will work.

Could you test this workaround on your system and tell me if it works?



I'll keep trying to understand why the original URL is not acceptable.  Below 
is the output of a call to gst-launch-1.0, which shows that the problem is the 
lack of a decoder for 'text/uri-list' (it seems odd that a *decoder* is needed 
for text/uri-list.  I'd expect a *parser*.)

$ gst-launch-1.0 -v playbin
uri=http://media-ice.musicradio.com/ClassicFMMP3.m3u Setting pipeline to PAUSED 
...
Pipeline is PREROLLING ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: download = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: uri = 
http://media-ice.musicradio.com/ClassicFMMP3.m3u
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: connection-speed = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: source = 
"\(GstSoupHTTPSrc\)\ source"
Got context from element 'source': gst.soup.session=context, 
session=(SoupSession)NULL, force=(boolean)false;
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement0.GstPad:src:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
 force-caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: 
sink-caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:sink:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:src:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src:
 caps = text/uri-list
Missing element: text/uri-list decoder
WARNING: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: No 
decoder available for type 'text/uri-list'.
Additional debug info:
gsturidecodebin.c(921): unknown_type_cb (): 
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: Your 
GStreamer installation is missing a plug-in.
Additional debug info:
gsturidecodebin.c(988): no_more_pads_full (): 
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0:
no suitable plugins found:
gstdecodebin2.c(4640): gst_decode_bin_expose (): 
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0:
no suitable plugins found:
Missing decoder: text/uri-list (text/uri-list)

ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Bug#895478: gnome-screensaver: package Description should mention that it is not part of GNOME 3

[Simon McVittie]

Package: gnome-screensaver
Version: 3.6.1-4
Severity: normal
X-Debbugs-Cc: debian-l10n-engl...@lists.debian.org, 
debian-gtk-gn...@lists.debian.org

Like GNOME Panel (#895348), gnome-screensaver is left over from GNOME 2
and is no longer necessary or desirable in a GNOME 3 environment. Unlike
GNOME Panel, gnome-screensaver is no longer maintained upstream (I've
just filed a bug tagged as "upstream wontfix" to document this).

The package's Description doesn't give any hints that it is no longer
part of a "normal" GNOME installation, and I think it should.

Currently, the Description is:

> GNOME screen saver and locker
>
> gnome-screensaver is a screen saver and locker that aims to have simple,
> sane and secure defaults, and be well integrated with the GNOME desktop.
> .
> It is designed to support, among other things:
> .
>  * the ability to lock down configuration settings
>  * translation into other languages
>  * user switching

Here is an attempt at a more current description:

 Screensaver and screen lock formerly used in GNOME

 gnome-screensaver is a simple screen saver and screen lock, used in older
 versions of the GNOME desktop environment.
 .
 It is designed to support, among other things:
 .
  * the ability to lock down configuration settings
  * translation into other languages
  * user switching
 .
 This package is not necessary in the GNOME desktop environment, because
 GNOME Shell contains its own screen lock implementation. It is
 used by lighter-weight desktop environments such as GNOME Flashback.

Rationale:
- mention that it isn't part of GNOME
- mention the replacement
- mention GNOME Flashback
- remove "secure defaults" because I don't think we should advertise
  unmaintained software as being particularly secure
- remove statements about integration with the GNOME desktop because
  the only screensaver that is integrated with the current GNOME desktop
  is tightly integrated as part of GNOME Shell

Opinions?

Regards,
smcv

Bug#895224: pdf-presenter-console: [regression] after upgrading to GStreamer 1.14.0, fails to play movies

[Francesco Poli]

On Sun, 8 Apr 2018 19:01:37 +0200 Francesco Poli wrote:

> On Sun, 08 Apr 2018 15:45:07 +0200 Francesco Poli (wintermute) wrote:
> 
> [...]
> > It now seems that no movie can be played at all,
> [...]
> 
> Mmmmh, I am trying to rebuild the binary package from the source
> package, but I get some weird messages, among which:
> 
>   dpkg-gencontrol: warning: Depends field of package pdf-presenter-console: 
> unknown substitution variable ${shlibs:Depends}
> 
> and I obtain a basically empty package with _no_ compiled executable
> pdfpc (by looking at the .build file, it seems to me that no
> compilation was performed)...
> 
> Do you happen to know of any fix needed to rebuild the package on
> current sid?

I managed to rebuild the Debian package, but that did not solve my
issue (I didn't have high hopes that a simple rebuild could suffice,
but I thought I could give it a try anyway...).

Could you please investigate the issue and/or forward my bug report
upstream?

Thanks for your time!
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpJEjDxE2g6O.pgp
Description: PGP signature

Bug#515856: Debian Policy 4.1.4.0 released

[Sean Whitton]

Hello,

On Wed, Apr 11 2018, Russ Allbery wrote:

> I'm pretty reluctant to specify this sort of optional target that
> works differently in every package that uses it back in Policy because
> it's really not standardized, nor do I think it's possible to
> standardize.  If we really want to write something down about the
> target, maybe the Developer's Reference would be a better spot?  There
> were a whole host of issues with having this in Policy that were
> resolved by moving it outside the scope of Policy, such as how to
> document dependencies required for running the get-orig-source target.

The Developer's Reference seems like a more appropriate place for a
convention that it is not possible to specify precisely.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#895477: gnome-screensaver: unmaintained upstream

[Simon McVittie]

Package: gnome-screensaver
Version: 3.6.1-4
Severity: important
Tags: upstream wontfix

gnome-screensaver is no longer part of GNOME, and is no longer maintained.
Last time it was discussed[1], some GNOME upstream maintainers expressed
a preference for anyone wanting to continue its development to use
a different name for their version. Perhaps gnome-flashback-screensaver
would be appropriate.

[1] https://mail.gnome.org/archives/desktop-devel-list/2016-July/msg00030.html

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

[Paulo]

Package: wiki.debian.org
Followup-For: Bug #885433

Dear Maintainer,

As of today (2018/04/11), it seems my IP address (177.141.158.166) is 
blacklisted. 

Would it be possible to restore access to the website?

Thank you.



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

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

Bug#895476: fwbuilder FTBFS: Cannot find file: .

[Adrian Bunk]

Source: fwbuilder
Version: 5.3.7-1
Severity: serious

Some recent change in unstable (Qt 5.10?) makes fwbuilder FTBFS:

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

...
configure: creating ./config.status
config.status: creating qmake.inc
config.status: creating src/res/objects_init.xml
config.status: creating src/res/templates.xml
config.status: creating src/libfwbuilder/qmake.inc
config.status: creating src/libfwbuilder/etc/fwbuilder.dtd
config.status: creating packaging/fwbuilder.control
config.status: creating packaging/fwbuilder.spec
config.status: creating packaging/fwbuilder-static-qt.spec
config.status: creating packaging/fwbuilder.nsi
config.status: creating config.h
config.status: creating src/libfwbuilder/src/fwbuilder/libfwbuilder-config.h
config.status: executing libtool commands
configure: WARNING: unrecognized options: --disable-maintainer-mode, 
--disable-dependency-tracking, --disable-silent-rules
QTDIR=""
Running qmake: /usr/bin/qmake -recursive
Empty filename passed to function
Cannot find file: .
make: *** [/usr/share/cdbs/1/class/autotools.mk:46: debian/stamp-autotools] 
Error 2

Bug#895475: openshot-qt: non-DFSG assets in package

[Alex Krusemark]

Package: openshot-qt
Version: 2.4.1-2
Severity: normal

Dear Maintainer,

I found that this package includes a bundled font "Ubuntu Regular", which was 
determined to be non-DFSG 
(https://bugs.launchpad.net/ubuntu-font-licence/+bug/769874). It installs to 
the path 
"/usr/lib/python3/dist-packages/openshot_qt/images/fonts/Ubuntu-R.ttf". I know 
that in some other packages with this issue, the font has been replaced with a 
DFSG font such as Cantarell or DejaVu Sans.

Alex Krusemark

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

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

Versions of packages openshot-qt depends on:
ii  libjs-jquery3.2.1-1
ii  python3 3.6.4-1
ii  python3-openshot0.1.9+dfsg1-3+b2
ii  python3-pyqt5   5.9.2+dfsg-1
ii  python3-pyqt5.qtsvg 5.9.2+dfsg-1
ii  python3-pyqt5.qtwebkit  5.9.2+dfsg-1
ii  python3-zmq 17.0.0-1

Versions of packages openshot-qt recommends:
ii  blender   2.79.b+dfsg0-1
ii  inkscape  0.92.3-1

Versions of packages openshot-qt suggests:
pn  openshot-qt-doc  

-- no debconf information

Bug#869648: ITP: node-mimelib -- MIME functions to encode/decode e-mails etc.

[Steve Cotton]

On Tue, Jul 25, 2017 at 06:33:35PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> * Package name: node-mimelib
>
>  This is a deprecated lib. Please read README.Debian to find a new lib
> for you.

Hi PaulLiu,

If you'll pardon the question, why are you packaging a library that's
deprecated, one for which the upstream author's README now starts with "All
users of this project are urged to find an alternative as it is not maintained
anymore."?

I can't read the file contents while the package is still in the NEW queue, so
can't see if this question is already answered there.  But another thread has
started on debian-devel about the number of items in the NEW queue, and this
seemed an obvious question to ask about the package that's spent longest on the
queue.

Best regards,
Steve

Bug#895474: fontconfig: Fontconfig filling .xsession-errors file with errors

[Frank McCormick]

Package: fontconfig
Version: 2.13.0-2
Severity: normal

Dear Maintainer,

Latest version of fontconfig filling my .xsession-errors file
with errors


Fontconfig warning: "/etc/fonts/fonts.conf", line 5: unknown element
"its:rules"
Fontconfig warning: "/etc/fonts/fonts.conf", line 6: unknown element
"its:translateRule"
Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute
'translate'
Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute 'selector'
Fontconfig error: "/etc/fonts/fonts.conf", line 7: invalid attribute
'xmlns:its'
Fontconfig error: "/etc/fonts/fonts.conf", line 7: invalid attribute 'version'
Fontconfig warning: "/etc/fonts/fonts.conf", line 9: unknown element
"description"
Fontconfig warning: "/etc/fonts/conf.d/10-hinting-full.conf", line 4: unknown
element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/10-hinting-full.conf", line 5: unknown
element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/10-hinting-full.conf", line 5: invalid
attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/10-hinting-full.conf", line 5: invalid
attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/10-hinting-full.conf", line 6: invalid
attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/10-hinting-full.conf", line 6: invalid
attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/10-hinting-full.conf", line 8: unknown
element "description"
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 4:
unknown element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 5:
unknown element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 5:
invalid attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 5:
invalid attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 6:
invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 6:
invalid attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 8:
unknown element "description"
Fontconfig warning: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 4: unknown
element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 5: unknown
element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 5: invalid
attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 5: invalid
attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 6: invalid
attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 6: invalid
attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/10-sub-pixel-rgb.conf", line 8: unknown
element "description"
Fontconfig warning: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 4:
unknown element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 5:
unknown element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 5:
invalid attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 5:
invalid attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 6:
invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 6:
invalid attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/11-lcdfilter-default.conf", line 8:
unknown element "description"
Fontconfig warning: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 4:
unknown element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 5:
unknown element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 5:
invalid attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 5:
invalid attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 6:
invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 6:
invalid attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/20-unhint-small-vera.conf", line 8:
unknown element "description"
Fontconfig warning: "/etc/fonts/conf.d/30-metric-aliases.conf", line 4: unknown
element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/30-metric-aliases.conf", line 5: unknown
element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/30-metric-aliases.conf", line 5: invalid
attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/30-metric-aliases.conf", line 5: invalid
attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/30-metric-aliases.conf", line 6: invalid
attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/30-metric-aliases.conf", line 6: invalid
attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/30-metric-aliases.conf", line 8: unknown

Bug#682264: #682264,libapache2-mod-perl2: Crash at server startup when pre-loading Plack app

[Dominic Hargreaves]

On Fri, Sep 01, 2017 at 10:33:38AM +0100, Dominic Hargreaves wrote:
> On Fri, Sep 01, 2017 at 03:47:57PM +1000, Dmitry Smirnov wrote:
> > I had the same problem until I've realised that Apache now uses event module
> > by default. Solution is simple -- just switch to (traditional) MPM Prefork
> > model as follows:
> > 
> > 
> > a2dismod mpm_event
> > a2enmod mpm_prefork
> > 
> 
> Hi Dmitry,
> 
> Thanks for pointing this out. And to the original submitter, I'm sorry
> that there was no reply on this bug before in many years!
> 
> As far as I know from a quick bit of digging it is indeed the case
> that mod_perl will not work with the event mpm, so we should
> arrange for it to either not be possible to load it it in that
> configuration, or at least to print dire warnings if that happens
> (which may be safer in any case).
> 
> I will try and have a look at this at some point but it might not be
> soon, so help would be appreciated.
> 
> FTR, Red Hat does the same thing:
> .

I asked Jan Kaluza (the Redhat contact) if the Redhat fix could be
shared, as I couldn't find that change anywhere online. No response
yet. Maybe someone more familiar with the Redhat ecosystem could dig it up?

Cheers,
Dominic.

Bug#849754: RFS: guerillabackup/0.0.0-1

[halfdog]

Hello Gianfranco,

Gianfranco Costamagna writes:
> control: owner -1 !
> control: tags -1 moreinfo
> Hello,
> 
> >I am looking for a sponsor for my package "guerillabackup"
> 
> I would really like to see the package working, but I see the
> upstream repo is lacking the history, this makes the Debian
> work less efficient in cherrypicking new stuff.
> Two commits are really not that much, seems like an inactive project.

Well, one commit (the first one is the github creation commit).
The software is the Python2 port of a quite old project, so just
rewriting it, comparing result with old program by unit tests
and committing the result to github resulted in a single commit.

All other changes are from the request to transform it to Python3
(some earlier review), fixes for problems introduced by that changes,
which were then added as a diff for packaging the initial release
version

If it would help, I could move those changes from my local branch
(which is used to create the patches for the Debian package by
comparing it to the github trunk) also to the github trunk. This
would then create a new github trunk (upstream) version, thus
starting a new RFS process I guess (due to version change). Then
there would also be more upstream commits.

> Is it the case?

Yes and no: it is working on all my machines without any flaws
or major changes for more than a year or so now and as long as
I do not change my setup to expose new bugs (which I do not plan
to do) or someone else reports bugs from his setup (which would
require solid packaging to have new users), so long there is no
real need for further development.

While the RFS was running, all changes went to the Debian packaging
repository and now the new salsa repository, which should build
the package using "gbp", hence also no upstream changes. But I
did not manage to get gbp running from the documentation, e.g.
trying the following did not work out and the various (sometimes
contradictory) recommendations from IRC did not really improve
the situation. You can test with:

git clone https://salsa.debian.org/halfdog-guest/guerillabackup.git
cd guerillabackup
git config user.email "m...@halfdog.net"
git config user.name "halfdog"
gbp buildpackage

So I stopped trying with salsa/gbp. Maybe in some years when alioth/
salsa transition has progressed, documentation will be more conclusive
for packaging noobs and make that step easier.

> Please note: I maintain borgbackup, that I think is really more
> powerful (complete) than your tool (please have a look at it).

Now I had time to check that one out. If I understand correctly,
it could be a nice preprocessor for the guerillabackup:

* borgbackup: does local file deduplication, uses nearby storages
  (similar trust zone, high bandwidth, reliable connections)
  to create repository with or without symmetric encryption

* guerillabackup: performs assymetric encryption of borgbackup
  outputs (e.g. the borgbackup repositories or changesets exported
  from the repository), distribution of redundant copies of those
  outputs to remote cloud storage with lower trust (other trust
  zones, low bandwith, unreliable connections)

hd

Bug#892656: even more tests fail with version 2.0.2

[Paolo Greppi]

Normally you'd expect to fix bugs with a new version, in this case while trying 
to update node-define-property 1.0.0-1 -> 2.0.2 the failing tests actually 
increased from 1 to 4.

What puzzled me was that no tests fail on upstream's CI (travis), which also 
tests nodejs version 8.

Turns out that we have upgraded node-is-descriptor to version 2.0.0, but the 
npm registry only has 1.0.2.

I have forwarded the issue upstream, and I expect upstream to answer that 
define-property correctly pins the major version of is-descriptor with ^1.0.2 
(https://docs.npmjs.com/misc/semver), stating that it won't work with 2.x.

^1.0.2 should be translated with >= 1.0.2 && < 2.0.0 but we can't encode that 
in debian/control.

So how can we check reverse dependencies for this type of issues in the future ?

Paolo

Bug#858294: Unreproducible, moreinfo needed

[Vladimir Berezenko]

> > This is definitely reproducible. The current Qt5 version is 5.9.2-2 on my
> > quad G5, and 5.8.4 on G4 powerbook. Both machines are not reacting on
> > mousewheel events at all. I've tried KDE, LXQt. GTK2/3 apps are not
> > affected at all.
> Well, this is totally strange, as the only report we have heard so far is
> from you.

This might be because others are not using Qt5 at all. It's strange, but 
understandable in case that newer Qt5 is using chromium as a web backend and 
it is not compileable to anything except x86 and arm and this renders Qt5 
almost unusable in modern cases.
 
> I understand that you tried on two machines. Just to be clear: have you
> tried with a new user?

The older installation on G5 is working the same in all users (tried new one). 
The G4 installation on powerbook is the fresh one.

> There is the chance that you might have configured something in the same way
> in both machines. If you still can reproduce this bug with a new user then
> we can file a bug upstream.
Both installations are independent and on older one (G5 one) I've tried 
several users.

> Actually you should do it yourself, as I don't have any ways of reproducing
> this bug. Please file the upstream bug at https://bugreports.qt.io and then
> please send the bug number here. I'll happily subscribe to the bug to follow
> it and, if possible at all, help.
Reading the bugs there I've found that it is possible that the problem is in 
QXcbAtom::ButtonWheel* wrong detection. I'm yet unable to find how does Qt5 
detects wheel buttons and where from it is getting the mouse events.
The xinput shows everything ok, and Qt4 and GTK2/3 apps all are using the 
wheel perfectly
Regarding the bugreport. I should register on the site and when I will fill 
bug report I'll attach it here.

-- 
WBR, Vladimir Berezenko

Bug#895473: ca-certificates: Post-install script subprocess return error exit status 3 while upgrading

[Pr0metheus]

Package: ca-certificates
Version: 20180409
Severity: important

Dear Maintainer,

   * What led up to the situation?

apt-get upgrade

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

Cannot fix the problem

   * What was the outcome of this action?

Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
rehash: skipping duplicate certificate in HaricaRootCA2011.pem
rehash: skipping vpn.auth.gr.pem, cannot open file
rehash: skipping AutCentralCAR5.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned
error exit status 3
Errors were encountered while processing:
 ca-certificates
E: Sub-process /usr/bin/dpkg returned an error code (1)

   * What outcome did you expect instead?

Like previous upgrades, maintain my existing list and update the rest.



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

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  openssl1.1.0h-2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/title:
* ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/Actalis_Authentication_Root_CA.crt, 
mozilla/AddTrust_External_Root.crt, mozilla/AffirmTrust_Commercial.crt, 
mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, 
mozilla/AffirmTrust_Premium_ECC.crt, mozilla/Amazon_Root_CA_1.crt, 
mozilla/Amazon_Root_CA_2.crt, mozilla/Amazon_Root_CA_3.crt, 
mozilla/Amazon_Root_CA_4.crt, mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certinomis_-_Root_CA.crt, 
mozilla/Certplus_Class_2_Primary_CA.crt, mozilla/Certplus_Root_CA_G1.crt, 
mozilla/Certplus_Root_CA_G2.crt, mozilla/certSIGN_ROOT_CA.crt, 
mozilla/Certum_Trusted_Network_CA_2.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/Deutsche_Telekom_Root_CA_2.crt, 
mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/EE_Certification_Centre_Root_CA.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G2.crt, 
mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/GDCA_TrustAUTH_R5_ROOT.crt, mozilla/GeoTrust_Global_CA.crt, 
mozilla/GeoTrust_Primary_Certification_Authority.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, 
mozilla/GeoTrust_Universal_CA_2.crt, mozilla/GeoTrust_Universal_CA.crt, 
mozilla/Global_Chambersign_Root_-_2008.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R5.crt, mozilla/GlobalSign_Root_CA.crt, 
mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, 
mozilla/Go_Daddy_Class_2_CA.crt, 
mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_ECC_RootCA_2015.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2015.crt, 
mozilla/Hongkong_Post_Root_CA_1.crt, 
mozilla/IdenTrust_Commercial_Root_CA_1.crt, 
mozilla/IdenTrust_Public_Sector_Root_CA_1.crt, mozilla/ISRG_Root_X1.crt, 
mozilla/Izenpe.com.crt, mozilla/LuxTrust_Global_Root_2.crt, 
mozilla/Microsec_e-Szigno_Root_CA_2009.crt, 
mozilla/NetLock_Arany_=Class_Gold=_Főtanúsítvány.crt, 
mozilla/Network_Solutions_Certificate_Authority.crt, 
mozilla/OISTE_WISeKey_Global_Root_GA_CA.crt, 

Bug#895472: ocaml: CVE-2018-9838

[Salvatore Bonaccorso]

Source: ocaml
Version: 4.05.0-10
Severity: important
Tags: security upstream
Forwarded: https://caml.inria.fr/mantis/view.php?id=7765

Hi,

The following vulnerability was published for ocaml.

CVE-2018-9838[0]:
| The caml_ba_deserialize function in byterun/bigarray.c in the standard
| library in OCaml 4.06.0 has an integer overflow which, in situations
| where marshalled data is accepted from an untrusted source, allows
| remote attackers to cause a denial of service (memory corruption) or
| possibly execute arbitrary code via a crafted object.

A solution is still beeing discussed upstream in [2].

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-9838
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9838
[1] https://caml.inria.fr/mantis/view.php?id=7765
[2] https://github.com/ocaml/ocaml/pull/1718

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#895452: gcc-7: libquadmath is disabled for gcc 7.3.0 on powerpc64-linux-gnu

[Matthias Klose]

On 11.04.2018 19:04, Dennis Clarke wrote:
> Package: gcc-7
> Version: 7.3.0-15
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Attempt to compile a trivial code test that uses #include 
> as well as _Float128 datatype and quadmath_snprintf() call fails with
> 
>  fatal error: quadmath.h: No such file or directory

I have dark memories, that quadmath didn't build. Please could you check that
again with a native build and a cross build, if you have access to a ppc64 
platform?

Bug#515856: Debian Policy 4.1.4.0 released

[Russ Allbery]

Ian Jackson  writes:

> (ii) You make a very good argument that policy should continue to give
> guidance for this kind of situation.  The target should probably be
> put back in policy, but with an explicit note saying it's not normally
> desirable, or something.

I think the Policy guidance is that you should document your maintenance
procedures in README.source if they're unusual, which would include this.
In that documentation, you can reference whatever scripts or targets would
be involved in doing an update.

I'm dubious there are really that many cases where knowing about a
get-orig-source target is the *only* piece of additional information
required about a source package and everything else is entirely standard.
I would expect somewhat non-standard upstreams to need at least some
additional explanation (how to choose a good upstream commit to package,
for instance).

I see that the current wording in Policy about README.source doesn't call
out this case (upstream updates) explicitly.  Maybe it should.

I'm pretty reluctant to specify this sort of optional target that works
differently in every package that uses it back in Policy because it's
really not standardized, nor do I think it's possible to standardize.  If
we really want to write something down about the target, maybe the
Developer's Reference would be a better spot?  There were a whole host of
issues with having this in Policy that were resolved by moving it outside
the scope of Policy, such as how to document dependencies required for
running the get-orig-source target.

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

Bug#895471: gnudatalanguage FTBFSon mips/mipsel:

[Adrian Bunk]

Source: gnudatalanguage
Version: 0.9.8-2
Severity: serious
Tags: patch

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

...
cd /<>/obj-mips-linux-gnu/src && /usr/bin/c++  -DHAVE_CONFIG_H 
-DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -Dgnudatalanguage_EXPORTS 
-I/usr/include/GraphicsMagick 
-I/usr/lib/mips-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 
-I/usr/include/hdf5/serial -I/usr/include/hdf -I/usr/include/python2.7 
-I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/eigen3 
-I/<> -I/<>/obj-mips-linux-gnu  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DBUILD_DATE="\"Apr  3 2018\"" -std=gnu++11 -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC   -fopenmp -o 
CMakeFiles/gnudatalanguage.dir/datatypes.cpp.o -c 
/<>/src/datatypes.cpp
In file included from /usr/include/python2.7/numpy/ndarraytypes.h:1809:0,
 from /usr/include/python2.7/numpy/ndarrayobject.h:18,
 from /usr/include/python2.7/numpy/arrayobject.h:4,
 from /<>/src/datatypes.cpp:21:
/usr/include/python2.7/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning 
"Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API 
NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it by " \
  ^~~

cc1plus: out of memory allocating 972584 bytes after a total of 51625984 bytes
make[3]: *** [src/CMakeFiles/gnudatalanguage.dir/build.make:282: 
src/CMakeFiles/gnudatalanguage.dir/datatypes.cpp.o] Error 1


Fix:

--- debian/rules.old2018-04-08 14:31:59.814323615 +
+++ debian/rules2018-04-08 14:33:25.220985470 +
@@ -1,9 +1,16 @@
 #!/usr/bin/make -f
 
 include /usr/share/dpkg/pkg-info.mk
+include /usr/share/dpkg/architecture.mk
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+# less debug info to avoid running
+# out of address space
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
+  export DEB_CXXFLAGS_MAINT_APPEND += -g1
+endif
+
 CXXFLAGS += -DBUILD_DATE="\"$(shell LC_ALL=C date -u 
--date=@"$(SOURCE_DATE_EPOCH)" +'%b %e %Y')\"" -std=gnu++11
 
 %:

Bug#895470: libfontconfig1 2.13.0-2 breaks Emacs in certain locales

[Peter De Wachter]

Package: libfontconfig1
Version: 2.13.0-2
Severity: important
Tags: upstream

Please see https://bugs.freedesktop.org/show_bug.cgi?id=105492

This version of fontconfig uses setlocale() in a way that breaks
Emacs' Lisp reader, causing all kinds of odd problems.

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

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

Versions of packages libfontconfig1:amd64 depends on:
ii  fontconfig-config  2.13.0-2
ii  libc6  2.27-3
ii  libexpat1  2.2.5-3
ii  libfreetype6   2.8.1-2
ii  libuuid1   2.31.1-0.5

libfontconfig1:amd64 recommends no packages.

libfontconfig1:amd64 suggests no packages.

-- no debconf information

Bug#894815: plasma-workspace: Lock screen media controls cannot be disabled

[Maximiliano Curia]

¡Hola Gregor!

El 2018-04-04 a las 15:34 +0200, Gregor Riepl escribió:

Package: plasma-workspace
Version: 4:5.12.4-1
Severity: normal



The Plasma lockscreen displays start/stop/forward/backward controls when an
media player application like VLC, Amarok or SMPlayer is active.
It was previously impossible to disable these controls.



In Plasma 5.12.2, a system setting was introduced that allows enabling and
disabling the feature.
In the Debian version of lockscreen however, these settings aren't shown, for
an unknown reason.



The original KDE bug report is here:
https://bugs.kde.org/show_bug.cgi?id=389483
A user confirmed that the setting indeed doesn't appear in Debian and Ubuntu,
but it works fine in Neon and Arch Linux.



Please fix this bug as soon as possible.


I can't reproduce the issue here. I see the Show media controls option in the 
Screen Locking / Appearance kcm interface.


Just to be certain, have you tried restarting the session after upgrading 
plasma-workspace?



Versions of packages plasma-workspace depends on:


Given that the files mentioned in the bug are under a breeze related path, it 
might be possible that breeze is implied in this bug.


Somehow breeze was not included in the generated list, could you please check 
and include the output of:

apt policy breeze breeze-cursor-theme breeze-dev kde-style-breeze 
kwin-style-breeze qml-module-qtquick-controls-styles-breeze

Happy hacking,
--
"If you have too many special cases, you are doing it wrong." -- Craig Zarouni
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#895469: openjfx FTBFS on armel: invalid instructions

[Adrian Bunk]

Source: openjfx
Version: 8u141-b14-3
Severity: serious
Tags: buster sid patch

https://buildd.debian.org/status/fetch.php?pkg=openjfx=armel=8u161-b12-1=1523051663=0

...
/tmp/ccxxsDUf.s: Assembler messages:
/tmp/ccxxsDUf.s:311: Error: selected processor does not support `movw 
r8,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
/tmp/ccxxsDUf.s:312: Error: selected processor does not support `movt 
r8,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
/tmp/ccxxsDUf.s:316: Error: selected processor does not support `movw 
r8,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
/tmp/ccxxsDUf.s:317: Error: selected processor does not support `movt 
r8,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
...


The baseline of the armel port was raised a few months ago,
this can be fixed with:

debian/patches/26-disable-webkit-jit-for-armv4.patch
-+#if CPU(ARM) && WTF_ARM_ARCH_VERSION < 5
++#if CPU(ARM) && WTF_ARM_ARCH_VERSION <= 5

Bug#890305: cppcheck still depends on python:any

[Adrian Bunk]

Control: tags -1 -help

On Fri, Apr 06, 2018 at 06:15:34PM +0200, Joachim Reichel wrote:
> tag 890305 -pending
> tag 890305 +help
> thanks
> 
> Hi,
> 
> I did the suggested change but I still get
> 
> Depends: [...] python3:any (>= 3.5~), python:any, python3-pygments
> 
> in the cppcheck binary package. And there is still the lintian warning about 
> the
> old python version.
> 
> Is there something else that needs to be done?

$ head -1 htmlreport/cppcheck-htmlreport
#!/usr/bin/env python
$ 

>   Joachim

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

Bug#895467: libsearpc FTBFS on 64bit big endian: test failure

[Adrian Bunk]

Source: libsearpc
Version: 3.0.8-2
Severity: serious

https://buildd.debian.org/status/package.php?p=libsearpc=sid

...
FAIL: test-searpc
=

Loaded 1 suites: 
Started

(process:10121): Searpc-WARNING **: 17:59:21.601: failed to read rpc request: 
Bad address

(process:10121): Searpc-WARNING **: 17:59:21.601: failed to read rpc response: 
Connection reset by peer
F
(process:10121): Searpc-WARNING **: 17:59:21.923: failed to read rpc request: 
Bad address

(process:10121): Searpc-WARNING **: 17:59:21.923: failed to send rpc call: 
Broken pipe
F
(process:10121): Searpc-WARNING **: 17:59:22.122: failed to read rpc request: 
Bad address

(process:10121): Searpc-WARNING **: 17:59:22.125: failed to read rpc response: 
Connection reset by peer
F

  1) Failure:
searpc::pipe_simple_call [searpc.c:427]
  Expression is not true: error == NULL
  Transport Error

  2) Failure:
searpc::pipe_large_request [searpc.c:454]
  Expression is not true: error == NULL
  Transport Error

  3) Failure:
searpc::pipe_concurrent_clients [searpc.c:483]
  Expression is not true: error == NULL
  Transport Error

System error: `fork()` call failed (12) - Cannot allocate memory
FAIL test-searpc (exit status: 255)


Testsuite summary for libsearpc 3.0.8

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to i...@seafile.com

make[5]: *** [Makefile:687: test-suite.log] Error 1

Bug#895468: ryu: Fix test_0_call_bytearray failure

[Corey Bryant]

Package: ryu
Version: 4.21+dfsg1-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/test_rpc-Adopt-to-msgpack-python-0.50.patch: Cherry-picked from
upstream to fix test failure "test_0_call_bytearray() did not raise
TypeError".


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-13-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ryu-4.21+dfsg1/debian/patches/remove-failing-test.patch 
ryu-4.21+dfsg1/debian/patches/remove-failing-test.patch
--- ryu-4.21+dfsg1/debian/patches/remove-failing-test.patch 2018-03-18 
17:00:30.0 -0400
+++ ryu-4.21+dfsg1/debian/patches/remove-failing-test.patch 1969-12-31 
19:00:00.0 -0500
@@ -1,23 +0,0 @@
-Description: Remove failing test
- This test fails for an unknown reasons, let's just remove it.
-Author: Thomas Goirand 
-Forwarded: no
-Last-Update: 2018-02-16
-
 ryu-4.21+dfsg1.orig/ryu/tests/unit/lib/test_rpc.py
-+++ ryu-4.21+dfsg1/ryu/tests/unit/lib/test_rpc.py
-@@ -138,14 +138,6 @@ class Test_rpc(unittest.TestCase):
- assert result == obj
- assert isinstance(result, numbers.Integral)
- 
--@raises(TypeError)
--def test_0_call_bytearray(self):
--c = rpc.Client(self._client_sock)
--obj = bytearray(b'foo')
--result = c.call('resp', [obj])
--assert result == obj
--assert isinstance(result, str)
--
- def test_1_shutdown_wr(self):
- # test if the server shutdown on disconnect
- self._client_sock.shutdown(socket.SHUT_WR)
diff -Nru ryu-4.21+dfsg1/debian/patches/series 
ryu-4.21+dfsg1/debian/patches/series
--- ryu-4.21+dfsg1/debian/patches/series2018-03-18 17:00:30.0 
-0400
+++ ryu-4.21+dfsg1/debian/patches/series2018-04-11 16:24:30.0 
-0400
@@ -1,2 +1,2 @@
 remove-test-requirements-units.patch
-remove-failing-test.patch
+test_rpc-Adopt-to-msgpack-python-0.50.patch
diff -Nru 
ryu-4.21+dfsg1/debian/patches/test_rpc-Adopt-to-msgpack-python-0.50.patch 
ryu-4.21+dfsg1/debian/patches/test_rpc-Adopt-to-msgpack-python-0.50.patch
--- ryu-4.21+dfsg1/debian/patches/test_rpc-Adopt-to-msgpack-python-0.50.patch   
1969-12-31 19:00:00.0 -0500
+++ ryu-4.21+dfsg1/debian/patches/test_rpc-Adopt-to-msgpack-python-0.50.patch   
2018-04-11 16:24:09.0 -0400
@@ -0,0 +1,44 @@
+From 81cdd4f0d76952c16d6e65e6af8da82702175220 Mon Sep 17 00:00:00 2001
+From: IWASE Yusuke 
+Date: Thu, 11 Jan 2018 16:02:40 +0900
+Subject: [PATCH] test_rpc: Adopt to msgpack-python>=0.50
+
+msgpack-python version 0.50 or later supports bytearray objects, this
+patch fixes to adopt to this change.
+
+Signed-off-by: IWASE Yusuke 
+Signed-off-by: FUJITA Tomonori 
+---
+ ryu/tests/unit/lib/test_rpc.py | 13 +
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/ryu/tests/unit/lib/test_rpc.py b/ryu/tests/unit/lib/test_rpc.py
+index 2df123ee..4fba5068 100644
+--- a/ryu/tests/unit/lib/test_rpc.py
 b/ryu/tests/unit/lib/test_rpc.py
+@@ -138,13 +138,18 @@ class Test_rpc(unittest.TestCase):
+ assert result == obj
+ assert isinstance(result, numbers.Integral)
+ 
+-@raises(TypeError)
+ def test_0_call_bytearray(self):
+ c = rpc.Client(self._client_sock)
+ obj = bytearray(b'foo')
+-result = c.call('resp', [obj])
+-assert result == obj
+-assert isinstance(result, str)
++# Note: msgpack-python version 0.50 or later supports bytearray
++# objects, here ignores TypeError for the backward compatibility.
++try:
++result = c.call('resp', [obj])
++except TypeError:
++# Case with msgpack-python version 0.4.x or earlier.
++return
++self.assertEqual(obj, result)
++self.assertIsInstance(result, six.binary_type)
+ 
+ def test_1_shutdown_wr(self):
+ # test if the server shutdown on disconnect
+-- 
+2.15.1
+

Bug#882655: bump

[Julien Puydt]

Hi,

Le 11/04/2018 à 12:51, Paolo Greppi a écrit :
> Hi, node-nanomatch >= 1.2.9 is required to update node-micromatch to 3.1.10:
> https://salsa.debian.org/js-team/node-micromatch/wikis/home
> 
> I have noticed there is a repo here:
> https://anonscm.debian.org/git/pkg-javascript/node-nanomatch.git
> 
> Do you plan to move the repo to salsa, update it and upload it ?

My local repo is three commits further than what I have up on anonscm,
but it's not finished because I saw I needed newer versions of (at
least!) node-define-property (Debian has 1.0.0-1 and 2.0.2 is needed)
and node-extend-shallow (3.0.1-1 vs 3.0.2) ; I haven't reported the need
and didn't find the time to work on it. The last one should be easy, and
I don't know for the first one.

If you want to help, you might start with having a look at
node-define-property.

Yes, I'll move the repos to salsa, but first I need to get in the teams,
read how to do that, and then move my packages one by one... which might
take some time.

Cheers,

Snark on irc.debian.org

Bug#895466: debootstrap 1.0.96 fails due to missing apt-config

[Olliver Schinagl]

Package: debootstrap
Version: 1.0.96
Severity: important
Tags: newcomer


Dear maintainer,

While running debootstrap on a non-native debian system, debootstrap 
keeps failing with


debootstrap: line 55: apt-config: command not found

The change causing the issue seems to be 
https://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=98858a907a9f69e 
which always seems to pass the if check (even though it's not installed) 
and then fails on the eval.

Bug#895129: linux: Battery not detected on Lamina 2-in-1 tablet

[Marcus Lundblad]

It seems these modules are already built for armhf:
https://salsa.debian.org/kernel-team/linux/commit/0138e6bc4eedd8c10ad63
7e742a4fe6c625c6def

Fixed in bug #873038

Maybe these should also be enabled for x86/amd64.

//Marcus

Bug#895235: sugar-toolkit-gtk3 FTBFS: devlibs error: There is no package matching [libfribidi0-dev] and noone provides it

[Adrian Bunk]

Control: reassign -1 libpango1.0-dev 1.42.1-1
Control: retitle -1 "pkg-config --libs pango" incorrectly contains -lfribidi
Control: affects -1 src:sugar-toolkit-gtk3 src:osm-gps-map src:gtkdataboxmm 
src:fontforge

On Sun, Apr 08, 2018 at 08:12:42PM +0300, Adrian Bunk wrote:
> Source: sugar-toolkit-gtk3
> Version: 0.112-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sugar-toolkit-gtk3.html
> 
> ...
> d-shlibmove --commit \
>   --multiarch \
>   --exclude-la --exclude-a \
>   --devunversioned --ignorelibdep \
>   --movedev debian/tmp/usr/share/gir-1.0 usr/share/ \
>   --extralib 
> debian/tmp/usr/lib/x86_64-linux-gnu/libsugar-eventcontroller.so \
>   debian/tmp/usr/lib/x86_64-linux-gnu/libsugarext.so
> Library package automatic movement utility
>  --> libasound2-dev package exists.
>  --> libatk1.0-dev package exists.
>  --> libcairo-dev is provided by a package.
>  --> libcairo2-dev package exists.
> devlibs error: There is no package matching [libfribidi0-dev] and noone 
> provides it, please report bug to d-shlibs maintainer
>  --> libglib2.0-dev package exists.
>  --> libgtk-3-dev package exists.
>  --> libgtk2.0-dev package exists.
>  --> libice-dev package exists.
>  --> libpango1.0-dev package exists.
>  --> librsvg2-dev package exists.
>  --> libsm-dev package exists.
>  --> libx11-dev package exists.
>  --> libxfixes-dev package exists.
>  --> libxi-dev package exists.
> make: *** [debian/rules:118: debian/stamp-local-shlibs-libsugarext] Error 1

The root cause is:

$ pkg-config --libs pango
-lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfribidi 
$

See also
  https://bugzilla.gnome.org/show_bug.cgi?id=794570#c2

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

Bug#895465: qalculate-gtk: please package/update qalculate to 2.4 released 11/04/2018

[shirish शिरीष]

Package: qalculate-gtk
Version: 2.2.1-1
Severity: wishlist

Dear Maintainer,

First of all thank you for uploading qalculate-gtk 2.2.1 . While I am
keeping my fingers crossed that you get a transition slot as and when
possible.
I have seen qalculate-gtk has released couple of point releases and
now is at 2.4 . Till the transition doesn't happen, maybe it's
possible to update to 2.4 unless it needs a bump in the build or
run-time dependencies which isn't available in Debian (unlikely but
still something that you may need to look into.)

Look forward to seeing qalculate 2.4 in Debian experimental if not unstable :)


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

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

Versions of packages qalculate-gtk depends on:
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libgcc1  1:8-20180402-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-4
ii  libgtk-3-0   3.22.29-3
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libqalculate14   2.2.1-2
ii  libstdc++6   8-20180402-1
ii  libxml2  2.9.4+dfsg1-6.1
ii  qalc 2.2.1-2

Versions of packages qalculate-gtk recommends:
ii  gnuplot-x11 [gnuplot-nox]  5.2.2+dfsg1-2

qalculate-gtk suggests no packages.

-- no debconf information


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

Bug#895464: dnss FTBFS: FAIL: TestEndToEnd

[Adrian Bunk]

Source: dnss
Version: 0.0~git20170810.0.860d2af1-1
Severity: serious

Some recent change in unstable makes dnss FTBFS:

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

...
=== RUN   TestEndToEnd
--- FAIL: TestEndToEnd (0.00s)
dnss_test.go:107: error parsing zone: dns: missing TTL with no previous 
value: "A" at line: 1:13

Bug#895463: keyutils FTBFS: Can't Determine Endianness

[Adrian Bunk]

Source: keyutils
Version: 1.5.9-9.2
Severity: serious

Some recent change in unstable makes keyutils FTBFS:

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

...
dh_auto_test -- \
PATH=/build/1st/keyutils-1.5.9:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games 
\
LD_LIBRARY_PATH=/build/1st/keyutils-1.5.9 \
SKIPROOT=yes \
SKIPINSTALLED=yes
make -j1 test 
PATH=/build/1st/keyutils-1.5.9:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games 
LD_LIBRARY_PATH=/build/1st/keyutils-1.5.9 SKIPROOT=yes SKIPINSTALLED=yes
make[2]: Entering directory '/build/1st/keyutils-1.5.9'
grep: /etc/rpm/macros.dist: No such file or directory
make -C tests run
make[3]: Entering directory '/build/1st/keyutils-1.5.9/tests'
sh runtest.sh  keyctl/update/userupdate keyctl/update/noargs 
keyctl/update/bad-args keyctl/unlink/valid keyctl/unlink/noargs 
keyctl/unlink/bad-args keyctl/unlink/all keyctl/timeout/valid 
keyctl/timeout/noargs keyctl/timeout/bad-args keyctl/show/valid 
keyctl/show/noargs keyctl/session/valid keyctl/session/bad-args 
keyctl/search/valid keyctl/search/noargs keyctl/search/bad-args 
keyctl/revoke/valid keyctl/revoke/noargs keyctl/revoke/bad-args 
keyctl/requesting/valid keyctl/requesting/piped keyctl/requesting/noargs 
keyctl/requesting/bad-args keyctl/reading/valid keyctl/reading/noargs 
keyctl/reading/bad-args keyctl/pupdate/userupdate keyctl/pupdate/noargs 
keyctl/pupdate/bad-args keyctl/permitting/valid keyctl/permitting/noargs 
keyctl/permitting/bad-args keyctl/padd/useradd keyctl/padd/noargs 
keyctl/padd/bad-args keyctl/noargs keyctl/newring/valid keyctl/newring/noargs 
keyctl/newring/bad-args keyctl/listing/valid keyctl/listing/noargs 
keyctl/listing/bad-args keyctl/link/valid keyctl/link/recursion 
keyctl/link/noargs keyctl/link/bad-args keyctl/invalidate/valid 
keyctl/invalidate/noargs keyctl/invalidate/bad-args keyctl/instantiating/noargs 
keyctl/instantiating/bad-args keyctl/describing/valid keyctl/describing/noargs 
keyctl/describing/bad-args keyctl/clear/valid keyctl/clear/noargs 
keyctl/clear/bad-args keyctl/add/useradd keyctl/add/noargs keyctl/add/bad-args 
bugzillas/bz1033467
 Some tests require root privileges.
 It is recommended that this be run as root.
Running with session keyring RHTS/keyctl/45279
Joined session keyring: 541509331
=== /build/1st/keyutils-1.5.9/tests/keyctl/update/userupdate/test.out ===
+++ Can't Determine Endianness
make[3]: *** [Makefile:42: run] Error 1

Bug#787080: Bug#894119: libreoffice: Please add libreoffice-online to the debian repository.

[Rene Engelhard]

retitle 894119 RFP: libreoffice-online
reassign 894119 wnpp
forcemerge 787080 894119
thanks

On Mon, Mar 26, 2018 at 06:16:04PM +0300, kpp wrote:
> Package: libreoffice
> Version: 1:5.2.7-1+deb9u3
> Severity: wishlist

No, this is not a bug in LibreOffice itself. It's a wish for a new
package, which isn't even developed inside the LO "core" code and thus
wouldn't be built from here anyway.

And definitely not in stable in any case.

> Please add libreoffice-online to the debian. I suppose it is very useful
> feature.

Maybe, but you need consumers for it. Of which I know of nextclouds
richdocument stff but that one isn't packaged either. :)
A daemon and JS stuff for "nothing" doesn't really help, does it?

Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787080.
I have a building (with npm from nodejs package...) package, but I am not
succeeding getting it to work... It's all theory anyway given the npm
JS mess and that it 

Current packaging is at
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online,
though...

Regards,

Rene

Bug#894965: dpkg-architecture should stop warning about unset CC

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Apr 11, 2018 at 05:31:15PM +0100, Wookey wrote:
> On 2018-04-06 11:54 +0200, to...@tuxteam.de wrote:

[buildtools.mk]

> > Hm. I can't find that file. Apt-file (and packages.debian.org) can't
> > either?
> 
> It's part of dpkg-dev (but was typoed: /usr/share/dpkg/buildflags.mk )

Thanks. This one shows on my radar :-)

> > >  * For many build systems, setting CC is not necessary and
> > >dh_auto_configure does the right thing anyway.
> > 
> > Yes, but how do I find out why it is failing in my case?
> 
> Is it actually failing if you don't set CC: or is it just spitting out
> a confusing message?

I somehow dreamt it failed: it didn't (I already retracted in another mail).

> Setting DH_VERBOSE can help, or using make -d (or see man make '-debug' for
> more details). To see when the message is being issued. 

But thanks for that: duly noted.

> > the build system *was* using the wrong compiler, i.e. x86_64 instead
> > of armhf.
> 
> OK, so that's a useful error then? Is the problem that it's not gone
> away now that you are in fact setting the right one? It should do (and
> just did in my quick test). But I guess if the arch is set first, and
> CC later (as is probably normal in most rules files driven by
> dpkg-buildpackage -a) then you will always see this warning, where
> it's not really very helpful.

No: the "wrong compiler" problem disappeared, so I assume I was doing
something wrong. As far as I am concerned, the error isn't useful
anymore.

Thanks a lot for your help!

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrOWs4ACgkQBcgs9XrR2kas4gCfRLUioB8pBu+bCtQ0QDeri3Cw
V/8AnA0p1ahMGTBiF1QJRORQzfM0XaED
=4dfQ
-END PGP SIGNATURE-

Bug#895462: asciidoc: deprecate in Debian

[Joseph Herlant]

Package: asciidoc
Version: 8.6.10-2
​Control: b​
lock -1 by 884213 893467 895186 895187 894192 894194 894188 894697 894700
894710 895165 895166 895167 895168

As announced by upstream in their last release[1], this is probably the
last release of asciidoc and encourage people to move to alternate tools
such as asciidoctor.

Asciidoc currently supports python2 only and the port to python3 [2] don't
seem to receive enough effort to go through [3], [4].

As we are pushing EOL of python2 in Debian, we need to properly manage the
EOL of asciidoc.

Concerning the move to asciidoctor, the following bugs need to be solved
before being able to really push forward: #884213, #893467, #895186, #895187

Command I used to get the list of packages that depends on asciidoc:
grep-dctrl -FBuild-Depends,Build-Depends-Indep,Recommends,Suggests -e
asciidoc[^t] -sPackage /var/lib/apt/lists/*Sources | cut -f2 -d ' '

I'll open debian bugs as I go and sometimes push upstream fixes. Here's
what I got so far:

​​
altos --> #894192
anet  --> #894194
ansible --> fixed upstream, debian: #894188
apgdiff --> used in the debain side only. #894697
autorevision --> #894700
awesome --> fixed upstream, debian: #894710
awesome-extra --> #895165
ben --> #895166
bgpdump --> #895167
boot-info-script --> #895168
booth
btrbk
btrfs-progs
butteraugli
cclive
ccontrol
cconv
cgit
clfswm
cluster-glue
codequery
compton
crmsh
cross-toolchain-base
cross-toolchain-base-ports
ctop
cvs-fast-export
cxxtest
cyclograph
czmq
dahdi-linux
dahdi-tools
dbusada
debian-security-support
debmake-doc
deutex
disorderfs
dpmb
dput-ng
dracut
drbd-doc
elasticsearch-curator
ent
erlang-ranch
evemu
evtest
fai
flactag
flashproxy
fldigi
frame
freedoom
fwknop-gui
genometools
git
git-cola
git-phab
git-reintegrate
git-remote-bzr
gitinspector
gitmagic
graphite2
grml-debootstrap
grml2usb
guetzli
guilt
gyp
herbstluftwm
httpfs2
i3-wm
i3status
jack-tools
jid
k3d
kakoune
kanboard-cli
katarakt
kicad
libalog
libam7xxx
libaqbanking
libchipcard
libcoap
libgwenhywfar
libmodbus
libpam-abl
libquvi
libquvi-scripts
libvmime
libxi
linux
lizardfs
lsyncd
madwimax
megatools
mlton
mp3fs
mpris-remote
mylvmbackup
nanomsg
newsbeuter
newsboat
ninja-build
nss-wrapper
ntpsec
nut
obfsproxy
ocl-icd
offlineimap
open-adventure
open-infrastructure-apache-icons
open-infrastructure-container-tools
open-infrastructure-package-tracker
open-infrastructure-storage-tools
pacemaker
pajeng
passenger
pavucontrol
pavumeter
pcscada
pegasus-wms
pepper
phodav
piuparts
poedit
postgresql-plproxy
psensor
pylama
python-ethtool
qutebrowser
quvi
rear
resolv-wrapper
rurple-ng
sen
shadowsocks-libev
shellex
shove
shunit2
simple-obfs
socket-wrapper
spring
springlobby
ssh-audit
stgit
tesseract
tig
tinyproxy
tor
trace-cmd
tweeper
udiskie
ufo-core
vmfs-tools
voltron
w1retap
warzone2100
wireshark
xnbd
yash
zeal
zynaddsubfx --> fixed upstream and fixed in the debian repo: #892969


[1] https://github.com/asciidoc/asciidoc/releases/tag/8.6.10
[2] https://github.com/asciidoc/asciidoc3/
[3] https://github.com/asciidoc/asciidoc3/pull/1
[4] https://github.com/asciidoc/asciidoc/issues/83

Bug#895461: mariadb-10.2: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: mariadb-10.2 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of mariadb-10.2
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#895460: horizon: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: horizon 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of horizon debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#895459: openafs: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: openafs 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of openafs debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#895458: mysql-5.7: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: mysql-5.7 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of mysql-5.7 debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#895447: move botan-2.pc to a multiarch location

[GCS]

Control: tags -1 +confirmed peding

On Wed, Apr 11, 2018 at 5:38 PM, Helmut Grohne  wrote:
> qtcreator fails to cross build from source, because it cannot find
> botan-2.pc. During cross compilation, pkg-config searches
> /usr/lib//pkgconfig and /usr/share/pkgconfig, but not
> /usr/lib/pkgconfig. The latter is where botan-2.pc currently lives. The
> attached patch moves it to the multiarch location. Please consider
> applying it.
 Indeed, this is a must have. How quick do you need it?

Cheers,
Laszlo/GCS

Bug#874949: [kdiff3] Future Qt4 removal from Buster

[Michael Weghorn]

On 2018-04-11 19:47, Eike wrote:
> For KDiff3 QT, it would not be hard. For the KDE version, there's no upstream
> KDE 5 version and the upstream author doesn't have time to implement it. 
> There are people trying to create a KDE5 version, though. I'd prefer to 
> package that when/if it works. The alternative would be to deprecate the
> KDE version and just have kdiff3-qt.
> 

According to [1] (s.a. the links given there), kdiff3 is now a project
under the KDE umbrella. I haven't tested the version there yet, though,
and can't say anything about how well it works.


1:
https://www.phoronix.com/scan.php?page=news_item=KDiff3-Restored-And-Joins-KDE

Bug#885756: choqok: Interface is missing many icons

[Lisandro Damián Nicanor Pérez Meyer]

El mié., 11 de abr. de 2018 13:45, Frédéric Brière 
escribió:

> Quick followup: I've seen the same thing happen with another KDE
> application (KAddressBook), so this is most likely not specific to
> Choqok after all.
>
> (At this point, I would usually reassign the bug report myself, but I
> have no clue on which of the various KDE packages it should belong to.)
>

Ideally we should know which package ships the missing icons, then we can
figure out if it's a choqok issue or some other package's.

>

Bug#894891: [Pkg-phototools-devel] Bug#894891: Bug#894891: pngquant: please, package new upstream version

[Herbert Fortes]

Em 06-04-2018 09:40, Herbert Fortes escreveu:
> Em 06-04-2018 07:19, Rogério Brito escreveu:
>> Hi, Herbert.
>>
>> On Thu, Apr 5, 2018 at 11:52 AM, Herbert Fortes  wrote:
>>> Em 05-04-2018 06:57, Rogério Brito escreveu:
 The upstream of pngquant has released quite a few releases since 2.5.0
 that's currently in Debian. The current version is 2.11.7.

 Can we, please, have something newer than the current version?
>>>
>>> It is stopped because of a dependency:
>>>
>>> pngquant (2.8.2-1) UNRELEASED; urgency=medium
>>>
>>>   TODO: * Needs packaging of
>>> https://github.com/ImageOptim/libimagequant
>>>   (but no new packages for Stretch ...)
>>> * check whether CVE-2016-5735 is fixed in latest upstream
>> (...)
>>
>> Ah, I see... I didn't know that newer versions of the package required
>> a new library...
> 
> 
> I think the project was splitted.
> 
> version 2.8
> ---
>  - libimagequant is a separate project
> 
> The maintainer is very active. And I think the packages - pngquant
> and libimagequant - should walk together.
> 
>>
>> BTW, taking a look at the repository for the library, it has bindings
>> for a lot of languages and, perhaps, they should be built as needed,
>> since, otherwise, they may be bloating the archive and never be used
>> (depending if clients in the archive use this library)...
> 
> I saw that too. I do not know what to do exactly (right now).
> 
>>
>>> I can send an ITP and try to do the Debian package if that helps.
>>
>> That would be awesome, if you could do that, because the lack of SSE2
>> optimization (if I understood things correctly with the current
>> binaries) is a pain with amd64 systems (especially on my Core 2 Duo
>> notebook that is already being loaded with some image processing tasks
>> and trying to help the kernel team with support for the recent
>> oversized armel kernels).
>>
> 
> As said, the maintainer is very active. Let's wait a few days.
> 

I started the packaging - libimagequant0(shared) and libimagequant-dev.
No *-doc package yet. I think it can be an overkill.

And I created a repository[0].

[0] - https://salsa.debian.org/debian-phototools-team/libimagequant

About the build:

 - debian/copyright must be checked.
 - there is a lintian that I do not understand why:

   W: file-name-contains-wildcard-character
   N:
   N:   The file name contains shell wildcard characters.
   N:   
   N:   These are most likely unexpanded wildcard characters from (for
   N:   example) debian/*.install files, or it may have been installed by
   N:   accident.
   N:   
   N:   Severity: normal, Certainty: possible
   N:   
   N:   Check: files, Type: binary, udeb
   N:

  It is true. The '*' is unexpanded. Here it should be 'x86_64-linux-gnu'
  as it is in 'debian/tmp'.


If someone wants to be a 'Uploaders', please do it.



Regards,
Herbert

Bug#874949: [kdiff3] Future Qt4 removal from Buster

[Eike]

Am Mittwoch, 11. April 2018, 10:07:28 CEST schrieb Wade Chandler:
> The kdiff3 readme states "Supported Qt-versions: 4.8, 5.2 or higher", so
> perhaps only the packaging needs updated?

For KDiff3 QT, it would not be hard. For the KDE version, there's no upstream
KDE 5 version and the upstream author doesn't have time to implement it. 
There are people trying to create a KDE5 version, though. I'd prefer to 
package that when/if it works. The alternative would be to deprecate the
KDE version and just have kdiff3-qt.


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

Bug#895457: gnome-core: cannot install "gnome-core" meta package without "standard system utilities" task.

[Ben]

Package: gnome-core
Version: 1:3.22+3
Severity: important

Dear Maintainer,

   * What led up to the situation?
 A minimal installation (i.e. no packages specified within the task 
selector) of Debian 9.4.0 via the network install CD/USB.

   * What exactly did you do (or not do) that was effective (or ineffective)?
 Installation of the "gnome-core" meta package fails unless the "standard 
system utilities" task is specified within the task selector during the initial 
installation. Essentially, the service for the "rtkit-daemon" produces a 
timeout error, and then the installation process hangs indefinitely whilst 
setting up "dbus". The installation process needs to be forcefully terminated, 
the computer rebooted, and then resumed with "dpkg --configure -a".

   * What was the outcome of this action?
 As above.

   * What outcome did you expect instead?
 For the installation process to complete successfully.

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

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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.22.0-1+deb9u1
ii  at-spi2-core  2.22.0-6+deb9u1
ii  baobab3.22.1-1
ii  caribou   0.4.21-1+b1
ii  chrome-gnome-shell8-4
ii  dconf-cli 0.26.0-2+b1
ii  dconf-gsettings-backend   0.26.0-2+b1
ii  eog   3.20.5-1+b1
ii  evince3.22.1-3+deb9u1
ii  evolution-data-server 3.22.7-1
ii  firefox-esr   52.7.3esr-1~deb9u1
ii  fonts-cantarell   0.0.25-2
ii  gdm3  3.22.3-3+deb9u1
ii  gedit 3.22.0-2
ii  gkbd-capplet  3.22.0.1-1+b1
ii  glib-networking   2.50.0-1+b1
ii  gnome-backgrounds 3.22.1-1
ii  gnome-bluetooth   3.20.1-1
ii  gnome-calculator  3.22.3-1
ii  gnome-characters  3.22.0-1
ii  gnome-contacts3.22.1-1+b2
ii  gnome-control-center  1:3.22.2-3
ii  gnome-disk-utility3.22.1-1
ii  gnome-font-viewer 3.22.0-1+b1
ii  gnome-keyring 3.20.0-3
ii  gnome-logs3.22.1-2
ii  gnome-menus   3.13.3-9
ii  gnome-online-accounts 3.22.5-1
ii  gnome-online-miners   3.22.0-1
ii  gnome-session 3.22.3-1
ii  gnome-settings-daemon 3.22.2-2+deb9u2
ii  gnome-shell   3.22.3-3
ii  gnome-shell-extensions3.22.2-1
ii  gnome-software3.22.5-1
ii  gnome-sushi   3.21.91-2
ii  gnome-system-monitor  3.22.2-1
ii  gnome-terminal3.22.2-1
ii  gnome-themes-standard 3.22.2-2
ii  gnome-user-guide  3.22.0-1
ii  gnome-user-share  3.18.3-1+b1
ii  gsettings-desktop-schemas 3.22.0-1
ii  gstreamer1.0-plugins-base 1.10.4-1
ii  gstreamer1.0-plugins-good 1.10.4-1
ii  gstreamer1.0-pulseaudio   1.10.4-1
ii  gvfs-backends 1.30.4-1
ii  gvfs-bin  1.30.4-1
ii  gvfs-fuse 1.30.4-1
ii  libatk-adaptor2.22.0-2
ii  libcanberra-pulse 0.30-3
ii  libcaribou-gtk-module 0.4.21-1+b1
ii  libcaribou-gtk3-module0.4.21-1+b1
ii  libpam-gnome-keyring  3.20.0-3
ii  libproxy1-plugin-gsettings0.4.14-2
ii  nautilus  3.22.3-1+deb9u1
ii  pulseaudio10.0-1+deb9u1
ii  sound-theme-freedesktop   0.8-1
ii  system-config-printer-common  1.5.7-3
ii  system-config-printer-udev1.5.7-3+b1
ii  totem 3.22.1-1
ii  tracker-gui   1.10.5-1
ii  vino  3.22.0-1
ii  yelp  3.22.0-1
ii  zenity3.22.0-1+b1

Versions of packages gnome-core recommends:
ii  anacron  2.3-24
ii  libproxy1-plugin-networkmanager  0.4.14-2
ii  network-manager-gnome1.4.4-1

Versions of packages gnome-core suggests:
pn  gnome  

-- no debconf information

Bug#895453: Disable check for NUL bytes in /proc/pid/cmdline

[Sergio Durigan Junior]

On Wednesday, April 11 2018, Paul-Antoine Arras wrote:

> Dear Maintainer,
>
> gdb incorrectly parses /proc/pid/cmdline, stopping at the first NUL
> byte encountered with a warning.
>
> * Steps to reproduce:
>
> $ gdb --args /bin/ls -l
> Reading symbols from /bin/ls...(no debugging symbols found)...done.
> (gdb) b _start
> Function "_start" not defined.
> Breakpoint 1 (_start) pending.
> (gdb) r
> Starting program: /bin/ls -l
>
> Breakpoint 1, 0x77dd9090 in _start () from
> /lib64/ld-linux-x86-64.so.2
> (gdb) info proc
> process 5618
> warning: target file /proc/5618/cmdline contained unexpected null characters
> cmdline = '/bin/ls'
> cwd = '/homes/parras'
> exe = '/bin/ls'
>
> This happens for all command lines with arguments.
>
> The bug has already been fixed quite some time ago:
> https://sourceware.org/ml/gdb-patches/2014-04/msg00204.html
> Not sure why the Debian version still has it...

This patch was posted upstream, but it wasn't incorporated into the
official repository until this year, when Andreas Arnez took it over and
pushed it:

  commit 26d6cec4a9291f154e549fb6f4318ace6cfaa2a5
  Author: Andreas Arnez 
  Date:   Thu Mar 22 10:02:18 2018 +0100

  Make "info proc cmdline" show args on GNU/Linux

The GDB version currently packaged in Debian is older and doesn't
include this commit.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#895456: axlisten: Could not initialize color support.

[Francois Marier]

Package: ax25-apps
Version: 0.0.8-rc4-2
Severity: normal

When I start axlisten with the "-c" option, I get the following error
message:

  $ axlisten -cart
  Could not initialize color support.

This happens in both gnome-terminal and xterm.

Francois

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

Versions of packages ax25-apps depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  libax250.0.12-rc4-2
ii  libc6  2.27-3
ii  libncurses56.1-1
ii  libtinfo5  6.1-1

ax25-apps recommends no packages.

Versions of packages ax25-apps suggests:
ii  ax25-tools  0.0.10-rc4-3

-- debconf information:
  ax25-apps/suid_listen: false

-- 
https://fmarier.org/

Bug#893439: stretch-pu: package gnucash/1:2.6.15-1+deb9u1

[Adrian Bunk]

openbsc also FTBFS in stretch due to the libdbi change: #880233

cu
Adrian

On Mon, Apr 02, 2018 at 03:20:56PM +0200, Julien Cristau wrote:
> On Mon, Apr  2, 2018 at 14:51:54 +0300, Adrian Bunk wrote:
> 
> > Control: tags -1 -moreinfo
> > 
> > On Mon, Apr 02, 2018 at 01:05:39PM +0200, Julien Cristau wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > On Sun, Mar 18, 2018 at 22:07:25 +0200, Adrian Bunk wrote:
> > > 
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > Tags: stretch
> > > > User: release.debian@packages.debian.org
> > > > Usertags: pu
> > > > 
> > > > libdbi 0.9.0-4+deb9u1 broke gnucash tests, runtime issues
> > > > with this backend were so far not reported but are not unlikely.
> > > 
> > > How comprehensive are automated tests for this package,
> > 
> > Comprehensive enough that gnucash in stretch does FTBFS since the 
> > stretch-pu update of libdbi.
> > 
> > > and what manual testing was done on the new version?
> > 
> > Only very lightweight testing that is can be installed, upgraded,
> > and doesn't seem to be completely broken after startup.
> > 
> So the other option here would be to revert the libdbi change.  As far
> as I can tell from #880896 it wasn't prompted by a specific problem, so
> a revert there might be the safest course of action and sidesteps the
> gnucash issue.  László, any thoughts?
> 
> Cheers,
> Julien

Bug#895455: gradle breaks everytime Groovy is upgraded

[Adrian Bunk]

Package: gradle
Version: 3.4.1-6
Severity: serious
Control: affects -1 src:triplea src:zeroc-ice src:gradle-propdeps-plugin 
src:groovy src:gradle-jflex-plugin

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gradle-jflex-plugin.html

...
FAILURE: Build failed with an exception.

* What went wrong:
Could not create service of type ClassLoaderRegistry using 
GlobalScopeServices.createClassLoaderRegistry().

* Try:
Run with --debug option to get more log output.

* Exception is:
org.gradle.internal.service.ServiceCreationException: Could not create service 
of type ClassLoaderRegistry using 
GlobalScopeServices.createClassLoaderRegistry().
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:807)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:761)
at 
org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:598)
at 
org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:643)
at 
org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:253)
at 
org.gradle.internal.service.DefaultServiceRegistry.findProviderMethods(DefaultServiceRegistry.java:214)
at 
org.gradle.internal.service.DefaultServiceRegistry.addProvider(DefaultServiceRegistry.java:352)
at 
org.gradle.internal.service.ServiceRegistryBuilder.build(ServiceRegistryBuilder.java:52)
at 
org.gradle.launcher.cli.BuildActionsFactory.createGlobalClientServices(BuildActionsFactory.java:153)
at 
org.gradle.launcher.cli.BuildActionsFactory.runBuildInSingleUseDaemon(BuildActionsFactory.java:141)
at 
org.gradle.launcher.cli.BuildActionsFactory.createAction(BuildActionsFactory.java:89)
at 
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.createAction(CommandLineActionFactory.java:249)
at 
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239)
at 
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:217)
at 
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:33)
at 
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at 
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at 
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at 
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:210)
at 
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:174)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
at 
org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: java.lang.IllegalArgumentException: Cannot find JAR 
'groovy-all-2.4.14.jar' required by module 'gradle-plugins' using classpath or 
distribution directory '/usr/share/gradle'
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.findDependencyJar(DefaultModuleRegistry.java:233)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.findDependencyJars(DefaultModuleRegistry.java:123)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.module(DefaultModuleRegistry.java:113)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.loadModule(DefaultModuleRegistry.java:89)
at 
org.gradle.api.internal.classpath.DefaultModuleRegistry.getModule(DefaultModuleRegistry.java:77)
at 
org.gradle.api.internal.classpath.DefaultPluginModuleRegistry.getPluginModules(DefaultPluginModuleRegistry.java:39)
at 
org.gradle.api.internal.DynamicModulesClassPathProvider.findClassPath(DynamicModulesClassPathProvider.java:47)
at 
org.gradle.api.internal.DefaultClassPathRegistry.getClassPath(DefaultClassPathRegistry.java:34)
at 
org.gradle.initialization.DefaultClassLoaderRegistry.(DefaultClassLoaderRegistry.java:31)
at 

Bug#895454: osmo-bts FTBFS with libosmocore 0.10.2

[Adrian Bunk]

Source: osmo-bts
Version: 0.4.0-3
Severity: serious

https://buildd.debian.org/status/package.php?p=osmo-bts

...
gcc -DHAVE_CONFIG_H -I. -I../..   -I../../include -I/usr/include/osmocom 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wall -I/usr/include/ -I/usr/include/ -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o oml.o oml.c
oml.c:46:30: error: conflicting type qualifiers for 'abis_nm_att_tlvdef_ipa'
 static struct tlv_definition abis_nm_att_tlvdef_ipa = {
  ^~
In file included from oml.c:33:0:
/usr/include/osmocom/gsm/abis_nm.h:42:36: note: previous declaration of 
'abis_nm_att_tlvdef_ipa' was here
 extern const struct tlv_definition abis_nm_att_tlvdef_ipa;
^~
oml.c:373:6: error: nested redefinition of 'enum abis_nm_t200_idx'
 enum abis_nm_t200_idx {
  ^~~~
oml.c:373:6: error: redeclaration of 'enum abis_nm_t200_idx'
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:646:6: note: originally defined 
here
 enum abis_nm_t200_idx {
  ^~~~
oml.c:374:2: error: redeclaration of enumerator 'T200_SDCCH'
  T200_SDCCH  = 0,
  ^~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:647:2: note: previous definition 
of 'T200_SDCCH' was here
  T200_SDCCH  = 0,
  ^~
oml.c:375:2: error: redeclaration of enumerator 'T200_FACCH_F'
  T200_FACCH_F  = 1,
  ^~~~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:648:2: note: previous definition 
of 'T200_FACCH_F' was here
  T200_FACCH_F  = 1,
  ^~~~
oml.c:376:2: error: redeclaration of enumerator 'T200_FACCH_H'
  T200_FACCH_H  = 2,
  ^~~~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:649:2: note: previous definition 
of 'T200_FACCH_H' was here
  T200_FACCH_H  = 2,
  ^~~~
oml.c:377:2: error: redeclaration of enumerator 'T200_SACCH_TCH_SAPI0'
  T200_SACCH_TCH_SAPI0 = 3,
  ^~~~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:650:2: note: previous definition 
of 'T200_SACCH_TCH_SAPI0' was here
  T200_SACCH_TCH_SAPI0 = 3,
  ^~~~
oml.c:378:2: error: redeclaration of enumerator 'T200_SACCH_SDCCH'
  T200_SACCH_SDCCH = 4,
  ^~~~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:651:2: note: previous definition 
of 'T200_SACCH_SDCCH' was here
  T200_SACCH_SDCCH = 4,
  ^~~~
oml.c:379:2: error: redeclaration of enumerator 'T200_SDCCH_SAPI3'
  T200_SDCCH_SAPI3 = 5,
  ^~~~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:652:2: note: previous definition 
of 'T200_SDCCH_SAPI3' was here
  T200_SDCCH_SAPI3 = 5,
  ^~~~
oml.c:380:2: error: redeclaration of enumerator 'T200_SACCH_TCH_SAPI3'
  T200_SACCH_TCH_SAPI3 = 6
  ^~~~
In file included from oml.c:32:0:
/usr/include/osmocom/gsm/protocol/gsm_12_21.h:653:2: note: previous definition 
of 'T200_SACCH_TCH_SAPI3' was here
  T200_SACCH_TCH_SAPI3 = 6
  ^~~~
make[4]: *** [Makefile:371: oml.o] Error 1

Bug#895449: [Pkg-zsh-devel] Bug#895449: zsh: mv completion fails with "missing file operand"

[sergio]

On 11/04/18 19:09, Axel Beckert wrote:

Sorry, but I did not understand, what can and what can not be reproduced?



Especially the latter shows that this is completely independent of the
aliasing.


Yes, sorry for misrepresentation, it doesn't depend on alias.

The only thing I'm sure is that this has been broken after the last update.

--
sergio.

Bug#895452: gcc-7: libquadmath is disabled for gcc 7.3.0 on powerpc64-linux-gnu

[Dennis Clarke]

Package: gcc-7
Version: 7.3.0-15
Severity: important

Dear Maintainer,

   * What led up to the situation?

Attempt to compile a trivial code test that uses #include 
as well as _Float128 datatype and quadmath_snprintf() call fails with

 fatal error: quadmath.h: No such file or directory

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

Wrote a trivial piece of test code and then issued a compile :

$ gcc -mcpu=970 -mno-altivec -g -m64 -std=c99 -pedantic-errors -o s s.c 
s.c:82:10: fatal error: quadmath.h: No such file or directory
 #include 
  ^~~~
compilation terminated.


   * What was the outcome of this action?

Compile can not proceed.


   * What outcome did you expect instead?

Expected a trivial to compile to generate pre-processed intermediate
file and then assembly and then an object file and then a final ELF
executable file that runs as expected.

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ppc64

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

Versions of packages gcc-7 depends on:
ii  binutils  2.30-15
ii  cpp-7 7.3.0-15
ii  gcc-7-base7.3.0-15
ii  libc6 2.27-3
ii  libcc1-0  8-20180402-1
ii  libgcc-7-dev  7.3.0-15
ii  libgcc1   1:8-20180402-1
ii  libgmp10  2:6.1.2+dfsg-3
ii  libisl19  0.19-1
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.1-1
ii  libstdc++68-20180402-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-7 recommends:
ii  libc6-dev  2.27-3

Versions of packages gcc-7 suggests:
pn  gcc-7-doc 
pn  gcc-7-locales 
ii  gcc-7-multilib7.3.0-15
pn  libasan4-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information