Bug#881797: fix ftbfs with updated libcdio-paranoia

[Matthias Klose]

Package: src:xmms2
Version: 0.8+dfsg-18
Severity: serious
Tags: sid buster patch

patch at
https://patches.ubuntu.com/x/xmms2/xmms2_0.8+dfsg-18ubuntu1.patch

Bug#881796: CVE-2017-1001001: pluxml: XSS and missing httponly flag

[Henri Salo]

Package: pluxml
Version: 5.5-2
Severity: grave
Tags: security upstream

https://nvd.nist.gov/vuln/detail/CVE-2017-1001001
https://github.com/pluxml/PluXml/issues/253

PluXml version 5.6 is vulnerable to stored cross-site scripting vulnerability,
within the article creation page, which can result in escalation of privileges.

Two problems:
- Cross-site scripting vulnerability with "writer" role
- Missing HttpOnly flag

-- 
Henri Salo


signature.asc
Description: PGP signature

Bug#881795: fix ftbfs with updated libcdio

[Matthias Klose]

Package: src:kover
Version: 1:4-11
Severity: serious
Tags: sid buster patch

kover ftbfs with updated libcdio with the updated libcdio. Upstream version 6
builds fine with that.

see https://launchpad.net/ubuntu/+source/kover for a packaging proposal.

Bug#794138: reopening 794138

[Petter Reinholdtsen]

[Helmut Grohne]
> I traced down the debhelper git history and it did that since the
> invention of dh_auto_test in version 7.0.0. Support for nocheck came
> later.

Thank you for checking.  The build depend is already on dh >= 9, so
there should be no chance of creating a broken package.

-- 
Happy hacking
Petter Reinholdtsen

Bug#881793: fix ftbfs with updated libcdio-paranoia

[Matthias Klose]

Package: src:daisy-player
Version: 11.2-1
Severity: serious
Tags: sid buster patch

patch at
https://patches.ubuntu.com/d/daisy-player/daisy-player_11.2-1ubuntu1.patch

Bug#881794: fix ftbfs with updated libcdio-paranoia

[Matthias Klose]

Package: src:gmerlin
Version: 1.2.0~dfsg+1-6
Severity: serious
Tags: sid buster patch

patch at
https://patches.ubuntu.com/g/gmerlin/gmerlin_1.2.0~dfsg+1-6ubuntu2.patch

Bug#881775: gcc-7-base: please add Breaks: gnat (<< 7)

[Matthias Klose]

On 15.11.2017 01:05, Andreas Beckmann wrote:
> Package: gcc-7-base
> Version: 7.2.0-14
> Severity: normal
> 
> Hi,
> 
> please add a 
>   Breaks: gnat (<< 7)
> to gcc-7-base (and merge this to gcc-8-base ...) to fix some stretch ->
> buster upgrade paths involving old ada libraries where apt may prefer to
> keep gnat-6 installed instead of switching to gnat-7 ...

no, adding the Breaks to gcc-8-base would make gnat 7 uninstallable.

> (I assume there is a good reason for gnat-6 and gnat-7 not being
> co-installable.)

still unversioned binaries in the gnat-X packages.

Bug#881792: paperkey test suite fails when run in parallel

[Daniel Kahn Gillmor]

Package: paperkey
Version: 1.5-1
Severity: normal

We're now building paperkey in parallel rather than serially.

The paperkey test suite itself appears to re-use the file "regen.pgp"
across tests.

if the tests are run in parallel, then one of them is likely to
intermittently fail.  We're seeing this on the build servers.

   --dkg

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

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

Versions of packages paperkey depends on:
ii  libc6  2.24-17

Versions of packages paperkey recommends:
ii  gnupg  2.2.2-1

paperkey suggests no packages.

-- no debconf information

Bug#881791: libgl1-mesa-dri: Poor Performance on Stretch

[bw]

Package: libgl1-mesa-dri
Version: 13.0.6-1+b2
Severity: normal

Dear Maintainer,

I have a pretty good setup on jessie, all the opengl works really well,
but since I have been using stretch I can't get it to work.  Very slow,
stuttering on any emulators, compositing insists on Xrender, which actually
performs well.

I like opengl okay but it's not a huge loss. I just thought if I filed a bug
it might help to sort things out.  I have a really old setup, so I suppose
the newer stuff can't always stay stuck in the past.

Thanks for all the fun!

L8r,
bw 


-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_texture_from_pixmap, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, 
GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, 
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
GLX_SGI_make_current_read, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org R300 Project (0x1002)
Device: ATI R430 (0x554f)
Version: 13.0.6
Accelerated: yes
Video memory: 512MB
Unified memory: no
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI R430
OpenGL version string: 2.1 Mesa 13.0.6
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_AMD_shader_trinary_minmax, GL_ANGLE_texture_compression_dxt3, 
GL_ANGLE_texture_compression_dxt5, GL_APPLE_packed_pixels, 
GL_APPLE_vertex_array_object, GL_ARB_ES2_compatibility, 
GL_ARB_buffer_storage, GL_ARB_clear_buffer_object, GL_ARB_clip_control, 
GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, 
GL_ARB_debug_output, GL_ARB_depth_texture, GL_ARB_draw_buffers, 
GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, 
GL_ARB_explicit_uniform_location, GL_ARB_fragment_coord_conventions, 
GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, 
GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
GL_ARB_get_program_binary, GL_ARB_get_texture_sub_image, 
GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, 
GL_ARB_instanced_arrays, GL_ARB_internalformat_query, 
GL_ARB_internalformat_query2, GL_ARB_invalidate_subdata, 
GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind, 
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, 
GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, 
GL_ARB_point_parameters, GL_ARB_point_sprite, 
GL_ARB_program_interface_query, GL_ARB_provoking_vertex, 
GL_ARB_robustness, GL_ARB_sampler_objects, GL_ARB_separate_shader_objects, 

Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA

[Leon Romanovsky]

On Tue, Nov 14, 2017 at 03:41:13PM -0500, Don Dutile wrote:
> On 11/14/2017 02:08 PM, Jason Gunthorpe wrote:
> > > However, it would of course be better to teach udma_barrier.h about
> > > these architectures.
> >
> > The issue is that some architectures just can't do cache coherent DMA
> > on any implementation. eg m68k
> >
> > There is no correct udma_barrier.h at all in those cases.
> >
> > We need to teach debian to follow cmake and exclude the missing
> > installables in these cases..
> >
> > Or do not build at all on these arch's..
> >
> > Jason
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> Jason:
> Why am I being cc'd on this debian bug?
> I also received a notice about a bug fix in debian, and I had zip to do with 
> it.
>
> Is my name tagged in Debian wrt rdma for some reason? by someone? other?

Don,

All of us received this email [1], because maintainer of rdma-core package
is mailing list:

"Package: src:rdma-core; Maintainer for src:rdma-core is Linux RDMA
Mailing List ;"

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881731

Thanks

>
> -dd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Bug#881782: earlyoom: FTBFS on hurd-i386: PATH_MAX undeclared

[Yangfl]

Actually I'm in huge doubt that this could ever run on non-Linux since
it depends on proc stuff like /proc/meminfo, /proc/[pid]/oom_score_adj
and more. And do non-Linux also suffer from not triggering oom due to
swap?

Sorry for having no non-Linux platform. But I think maybe I should
simply mark it as linux-any.

2017-11-15 10:28 GMT+08:00 Aaron M. Ucko :
> Source: earlyoom
> Version: 0.12-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source
> User: debian-h...@lists.debian.org
> Usertags: hurd-i386
>
> The build of earlyoom for hurd-i386 (admittedly not a release
> architecture) failed:
>
>   kill.c:104:12: error: 'PATH_MAX' undeclared (first use in this function); 
> did you mean 'NAME_MAX'?
>
> The Hurd famously has no static PATH_MAX.  Best practice is to
> allocate path buffers dynamically based on what you actually
> encounter, but if that's not convenient, you can look up _PC_PATH_MAX
> via pathconf or define a fallback constant (traditionally 4096).
>
> Could you please take a look?
>
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#881790: xine-ui FTCBFS: debian/rules says so

[Helmut Grohne]

Source: xine-ui
Version: 0.99.9-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xine-ui fails to cross build from source, because debian/rules says so
and simply errors out. After removing the deliberate error, xine-ui
cross builds successfully for e.g. s390x. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru xine-ui-0.99.9/debian/changelog 
xine-ui-0.99.9/debian/changelog
--- xine-ui-0.99.9/debian/changelog 2017-01-22 04:12:02.0 +0100
+++ xine-ui-0.99.9/debian/changelog 2017-11-15 06:22:10.0 +0100
@@ -1,3 +1,10 @@
+xine-ui (0.99.9-1.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Remove error saying that it doesn't cross. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 15 Nov 2017 06:22:10 +0100
+
 xine-ui (0.99.9-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru xine-ui-0.99.9/debian/rules xine-ui-0.99.9/debian/rules
--- xine-ui-0.99.9/debian/rules 2017-01-22 04:04:30.0 +0100
+++ xine-ui-0.99.9/debian/rules 2017-11-15 06:22:10.0 +0100
@@ -5,16 +5,13 @@
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
-ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
-  $(error cross compiling is not supported by xine)
-endif
-
 config.status:
dh_testdir
sh ./configure \
--prefix=/usr --mandir=\$${prefix}/share/man \
--with-aalib --enable-vdr-keys \
-   --build $(DEB_HOST_GNU_TYPE) || \
+   --build $(DEB_BUILD_GNU_TYPE) \
+   --host $(DEB_HOST_GNU_TYPE) || \
(echo "=== config.log: ==="; cat config.log; false)
 
 build: build-arch build-indep

Bug#881715: alsa-utils: High CPU usage on the default device

[Elimar Riesebieter]

* Andoru  [2017-11-14 23:45 +0200]:

> >
> > Just run htop while an alsa-process needs high cpu load. Copy the
> > line which shows that from (h)top to this bug report. Or just file a
> > screenshot to a puplic server somewhere.
> >
> 
> Alright:
> VLC playing a FLAC file on the default device:
> 
> >  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
> COMMAND
> > 26183 andoru20   0 1191000  66424  46296 S  13.6  0.8   0:09.43 vlc

Did you started vlc within wine?

Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)


signature.asc
Description: PGP signature

Bug#881789: libglvnd: missing libGLX_indirect.so, breaks GLX with remote X server

[James Braid]

Package: libglx0
Version: 1.0.0-1
Severity: important

Dear Maintainer,

I'm running testing on a headless system, and a recent change to use
libglxvnd has stopped GLX from working when displayed to a remote
machine. This was working fine before the migration to use glvnd for
libGL/libGLX.

e.g. running glxinfo fails with the following error:

$ glxinfo
name of display: localhost:11.0
Error: couldn't find RGB GLX visual or fbconfig

strace'ing glxinfo shows it trying to load libGLX_indirect.so.0 and
failing:

$ strace -etrace=open glxinfo

open("/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)

Adding a symlink from libGLX_mesa.so.0 to libGLX_indrect.so.0 makes
things work:

$ sudo ln -s /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 
/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0
$ glxinfo | head
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
name of display: localhost:11.0
display: localhost:11  screen: 0
direct rendering: No (If you want to find out why, try setting 
LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample,
GLX_SGIX_fbconfig

Looking at the source for glvnd and reading some NVIDIA documentation,
it seems like glvnd is trying to fallback to a generic libGLX_indirect
library if vendor-specific library doesn't exist or GLX_EXT_glvnd is not
present on the remote X server (this is my situation).

However, I can't find libGLX_indirect.so.0 provided by any Debian
packages. It seems like either libglvnd or mesa should provide a symlink
from libGLX_indirect.so.0 to a default GL implementation for these
situations.

I'd provide a patch but I'm not sure what package should be taking care
of this 



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

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

Versions of packages libglx0:amd64 depends on:
ii  libc6 2.24-17
ii  libglvnd0 1.0.0-1
ii  libglx-mesa0 [libglx-vendor]  17.2.4-1+b1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2

libglx0:amd64 recommends no packages.

libglx0:amd64 suggests no packages.

-- no debconf information

Bug#881788: opusfile: please make the build reproducible

[Chris Lamb]

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

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in
index 0fa3363..d0b229c 100644
--- a/doc/Doxyfile.in
+++ b/doc/Doxyfile.in
@@ -18,3 +18,5 @@ SORT_MEMBER_DOCS   = NO
 HAVE_DOT   = @HAVE_DOT@
 
 PROJECT_LOGO   = @top_srcdir@/doc/opus_logo.svg
+
+FULL_PATH_NAMES= NO

Bug#881769: udev: Docs on upgrading to predictable network interface names don't work

[Karl O. Pinc]

On Wed, 15 Nov 2017 01:08:06 +0100
Michael Biebl  wrote:

> Am 14.11.2017 um 23:46 schrieb Karl O. Pinc:

> > The stretch README.Debian.gz for udev omits mention that
> > update-initramfs -u must be run after changing configuration files
> > when converting to the new "predictable network interface names".
> >   
> 
> Well, we already mention it earlier:
> 
> 
>   - Disable the default *.link rules with
> "ln -s /dev/null /etc/systemd/network/99-default.link"
> and rebuild the initrd with "update-initramfs -u".

Sure.  But the README is organized into sections.  You don't
mention the initramfs in the section that's telling you how
to convert your pre Debian 9 systems into something suitable
for Debian 10.

I should be able to follow the instructions given in the
migration section and, well, migrate.  I should not 
have to carefully read the whole document.
But if I follow the document as written
my interface name never changes (until I somehow figure out
that I need to update the initramfs to make this happen.)

So, the "migration" section needs mention of update-initramfs.

> Besides, your patch seems to contain a lot of other changes.
> Please elaborate

A few goals of the patch:

Improve random sentences.  (Without re-writing the entire
document.)  Generally this falls along the lines of changing
"will", as in "always must", to "may", as in "are allowed to".
This isn't perfect.  There could remain potentially unanswered questions
in the reader's mind as to what happens automatically and what
must be done manually.  If you think this is a problem
I think it should be addressed with specificity in a sentence
like: "Software upgrades do not automatically change network interface
names."

Likewise, add caveats to overly definitive statements where
awkward surprises can result if the statements are taken
at face value.  E.g. "replacing a broken network card does
not change the name".  Well, if you replace a broken network
card and put the new card in a different PCI slot the names
of the system's interfaces likely change.  Caveats lengthen
the README, but it's harder to (re)craft a good, accurate,
short sentence than to add an additional qualifying sentence,
so that's what I did.

Finally, the main goal was to make the section on
"migration" closer to a procedure which could be followed
step-by-step.  The old document told you to go through your
config files and find all places where the old interface
names occurred _before_ it told you how to find the new
interface names which which to replace the old.

Once I started down the road toward a step-by-step
procedure it became clear that blindly following some
of the steps could lead to a dangerous place.  Like
having a remotely accessible system which is no longer
remotely accessible -- what you get when you delete
the 70-persistent-net.rules files and reboot without
thinking through the consequences.  This led to a lot 
of problem mitigation verbiage.

I didn't do an awesome job.  Writing good sentences
is hard.  And in my opinion there's a lot to
be done by a good editor almost everywhere in the document. I think 
that, overall, the patch is an improvement.  
A step forward.  If you don't think so that's ok.
Or take the hunks you like.  Or apply it and then edit
over what you don't care for.

I patched because I think that it's entirely unacceptable to
have a document that looks like a step by step
procedure and leave out the critical step of generating
a new initramfs.  Once I started it was hard to stop
banging out the dents and applying some polish to the 
rough spots.

See also: Bug#881771

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#881787: packagekit: refresh-cache transaction restarts about every 5 minutes

[Gerry Cocco]

Package: packagekit
Version: 1.1.5-2
Severity: normal

Dear Maintainer,

Problem: On 3 new installs of Stretch (KDE), I noticed that PackageKit was
   updating frequently (about every 5 minutes - continuously). There is no
   good reason for the updates.  This doesn't happen on a similarly
   configured Gnome system.

Bypass: The only way I found to stop the updates is to uninstall 
"packagekit".
   I'm not sure what the side-effects of that may be, but I'm sure 
packagekit

   is installed on the default system for a reason.

Discussion: In trying to diagnose what was happening on my real hardware,
   I've installed several copies of Stretch on VMware.  I installed 
them with
   the same installer configuration parameters as my real systems.  
Then I started
   to add software.  As soon as I added Chromium, the problem started 
showing

   up in "syslog". Notice the times, around every 5 minutes

   Nov 14 16:02:24 vm921 systemd[1]: Started Run anacron jobs.
   Nov 14 16:02:24 vm921 anacron[54523]: Anacron 2.3 started on 2017-11-14
   Nov 14 16:02:24 vm921 anacron[54523]: Normal exit (0 jobs run)
   Nov 14 16:02:24 vm921 systemd[1]: anacron.timer: Adding 1min 
18.530212s random time.
   Nov 14 16:04:58 vm921 PackageKit: refresh-cache transaction 
/1630_dadb from uid 1000 finished with success after 948ms
   Nov 14 16:04:58 vm921 PackageKit: get-updates transaction 
/1631_cedaadac from uid 1000 finished with success after 734ms
   Nov 14 16:04:59 vm921 PackageKit: get-updates transaction 
/1632_ceaaccaa from uid 1000 finished with success after 244ms
   Nov 14 16:05:00 vm921 PackageKit: get-updates transaction 
/1634_aeeebeaa from uid 1000 finished with success after 249ms
   Nov 14 16:05:00 vm921 PackageKit: get-updates transaction 
/1635_ddcbbaaa from uid 1000 finished with success after 240ms
   Nov 14 16:10:57 vm921 PackageKit: refresh-cache transaction 
/1637_aeadadba from uid 1000 finished with success after 857ms
   Nov 14 16:10:58 vm921 PackageKit: get-updates transaction 
/1638_bcbabdbb from uid 1000 finished with success after 833ms
   Nov 14 16:10:59 vm921 PackageKit: get-updates transaction 
/1639_abaecbee from uid 1000 finished with success after 228ms
   Nov 14 16:11:00 vm921 PackageKit: get-updates transaction 
/1641_dcccabdc from uid 1000 finished with success after 224ms
   Nov 14 16:11:00 vm921 PackageKit: get-updates transaction 
/1642_ccadcceb from uid 1000 finished with success after 214ms
   Nov 14 16:16:57 vm921 PackageKit: refresh-cache transaction 
/1644_bbaddbbe from uid 1000 finished with success after 835ms
   Nov 14 16:16:58 vm921 PackageKit: get-updates transaction 
/1645_cccdedca from uid 1000 finished with success after 767ms
   Nov 14 16:16:59 vm921 PackageKit: get-updates transaction 
/1646_abcaaeec from uid 1000 finished with success after 243ms
   Nov 14 16:17:00 vm921 PackageKit: get-updates transaction 
/1648_cbdededb from uid 1000 finished with success after 247ms
   Nov 14 16:17:00 vm921 PackageKit: get-updates transaction 
/1649_bdacdeaa from uid 1000 finished with success after 238ms
   Nov 14 16:17:01 vm921 CRON[55165]: (root) CMD (   cd / && run-parts 
--report /etc/cron.hourly)
   Nov 14 16:22:57 vm921 PackageKit: refresh-cache transaction 
/1651_adbccadb from uid 1000 finished with success after 828ms
   Nov 14 16:22:58 vm921 PackageKit: get-updates transaction 
/1652_abbddcbb from uid 1000 finished with success after 693ms
   Nov 14 16:22:58 vm921 PackageKit: get-updates transaction 
/1653_babbeddd from uid 1000 finished with success after 217ms
   Nov 14 16:23:00 vm921 PackageKit: get-updates transaction 
/1655_ccabdeae from uid 1000 finished with success after 229ms
   Nov 14 16:23:00 vm921 PackageKit: get-updates transaction 
/1656_bbeadecb from uid 1000 finished with success after 220ms


   On my real hardware systems the refresh-cache transaction can last 
up to 300-400 seconds


   ## syslog entry from a "real" system that was up for a while
   Nov 14 14:59:48 sake PackageKit: refresh-cache transaction 
/80459_bbcaceec from uid 1000 finished with success after 374505ms


  You can also see how many transactions that sytem is up to 80459!

  I also installed a Gnome GUI installation on a VM.  Other than that,
  everything was the same.  This setup installed and runs FINE.
  No packagekit issues.

  This seems like an installation parameter configuration problem, but 
I can't
  figure out what to change/fix.  Since it is absolutely reproducable, 
what

  can I try next on my other systems other than un-installing packagekit?
  Since I have several VM copies, I can experiment is someone has some 
suggestions...


  Thanks...gmc





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

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 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 

Bug#853613: [NMU] Re: Bug#853613: pinfo: gcc-7 with -Os: undefined references to inline functions

[Axel Beckert]

Control: tag -1 + pending

Hi Bas,

Joost van Baal-Ilić wrote on 4th of October 2017:
> Have verified package builds succesfully with gcc-7 in current sid chroot.

Thanks a lot, Joost!

> Made another house-keeping change, updated debdiff attached.

Unfortunately that debdiff seems incomplete:

* No debian/patches/series file needed for source format '3.0
  (quilt)'.
* debian/rules still contains a patch target which calls dpatch.
* Patches are still in dpatch format, including the new one.

Since pinfo already has been autoremoved from Testing quite a while
ago, I've uploaded an NMU to DELAYED/5. It's based on Joost's original
and minimal NMU patch. See my full debdiff at the end of this mail.

Bas: I'd really prefer if you could declare a new upstream release and
upload that one instead of my NMU. Hence I uploaded to DELAYED/5
despite the age of the RC bug would easily validate a direct NMU
without any delay.

You seem to keep pinfo uptodate upstream, even made a new upstream
release 7 years ago and fixed this bug in your GitHub repository
several months ago. But you never uploaded that new upstream release
to Debian, nor did you upload the committed RC fix to Debian. Why? You
seem to be otherwise active in Debian, e.g. in the BTS…

So please, do a new upstream release and upload that one to Debian
Unstable. If you prefer, I can also delay this NMU longer. Just tell
me to do so.

diff -u pinfo-0.6.9/debian/changelog pinfo-0.6.9/debian/changelog
--- pinfo-0.6.9/debian/changelog
+++ pinfo-0.6.9/debian/changelog
@@ -1,3 +1,19 @@
+pinfo (0.6.9-5.2) unstable; urgency=low
+
+  [ Joost van Baal-Ilić ]
+  * Get rid of undefined references to inline functions when compiling
+with gcc-7 using -Os by first declaring these 3 functions without
+using the inline keyword.  Thanks Matthias Klose for reporting,
+Adrian Bunk for writing a test case and Jakub Jelinek for pointing
+the way to a fix in
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734#c3.
+(Closes: #853613) [06_gcc_7_Os_inline_functions.dpatch]
+
+  [ Axel Beckert ]
+  * Non-maintainer upload.
+
+ -- Axel Beckert   Wed, 15 Nov 2017 02:47:08 +0100
+
 pinfo (0.6.9-5.1) unstable; urgency=low
 
   * NMU
diff -u pinfo-0.6.9/debian/patches/00list pinfo-0.6.9/debian/patches/00list
--- pinfo-0.6.9/debian/patches/00list
+++ pinfo-0.6.9/debian/patches/00list
@@ -5,0 +6 @@
+06_gcc_7_Os_inline_functions.dpatch
only in patch2:
unchanged:
--- pinfo-0.6.9.orig/debian/patches/06_gcc_7_Os_inline_functions.dpatch
+++ pinfo-0.6.9/debian/patches/06_gcc_7_Os_inline_functions.dpatch
@@ -0,0 +1,40 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 06_gcc_7_Os_inline_functions.dpatch by Joost van Baal-Ilić 

+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Get rid of undefined references to inline functions when compiling
+## DP: with gcc-7 using -Os by first declaring these 3 functions without
+## DP: using the inline keyword.
+## DP: Thanks Matthias Klose for reporting, Adrian Bunk for writing a test
+## DP: case and Jakub Jelinek for pointing the way to a fix.
+
+@DPATCH@
+
+--- pinfo-0.6.9/src/initializelinks.c  2006-03-15 22:54:56.0 +0100
 pinfo-0.6.9/src/initializelinks.c  2017-10-04 04:37:18.782964086 +0200
+@@ -75,6 +75,7 @@
+  * checks if an item belongs to tag table. returns 1 on success and 0 on
+  * failure.  It should be optimised...
+  */
++extern int exists_in_tag_table(char *item);
+ inline int
+ exists_in_tag_table(char *item)
+ {
+--- pinfo-0.6.9/src/filehandling_functions.c   2006-03-16 16:15:02.0 
+0100
 pinfo-0.6.9/src/filehandling_functions.c   2017-10-04 04:37:59.519976805 
+0200
+@@ -551,6 +551,7 @@
+   return 1;
+ }
+ 
++extern void buildcommand(char *dest, char *command, char *filename, const 
char *tmpfilename);
+ inline void
+ buildcommand(char *dest, char *command, char *filename, const char 
*tmpfilename)
+ {
+@@ -561,6 +562,7 @@
+   strcat(dest, tmpfilename);
+ }
+ 
++extern void builddircommand(char *dest, char *command, char *filename, const 
char *tmpfilename);
+ inline void
+ builddircommand(char *dest, char *command, char *filename, const char 
*tmpfilename)
+ {

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


signature.asc
Description: Digital signature

Bug#881786: gnome-session-flashback: input source does not show input mode

[T Yamada]

Package: gnome-session-flashback
Version: 3.22.0-3
Severity: important

Dear Maintainer,

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

gnome-session-flashback's input source does not show input mode, so I cannot
select Hiragana in ibus-mozc.

It is fixed in upstream, so buster is ok. But could you backport the fix to
stretch?

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



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

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

Versions of packages gnome-session-flashback depends on:
ii  gnome-flashback3.22.0-3
ii  gnome-panel3.20.1-1+b2
ii  gnome-session-bin  3.22.3-1
ii  gnome-session-common   3.22.3-1
ii  gnome-settings-daemon  3.22.2-2+deb9u2
ii  metacity   1:3.22.1-1
ii  nautilus   3.22.3-1+deb9u1

Versions of packages gnome-session-flashback recommends:
ii  gnome-power-manager  3.22.2-2
ii  gnome-screensaver3.6.1-7+b2

Versions of packages gnome-session-flashback suggests:
ii  desktop-base  9.0.2+deb9u1
ii  gnome-keyring 3.20.0-3
ii  gnome-user-guide  3.22.0-1

-- no debconf information

Bug#881784: lmdbxx: FTBFS on hurd-i386: mdb_env_open: Operation not supported

[Aaron M. Ucko]

Source: lmdbxx
Version: 0.9.14.1+git20160228.0b43ca8-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of lmdbxx for hurd-i386 (admittedly not a release
architecture) failed:

  g++  -o check check.o -llmdb && ./check
  Failed with error: mdb_env_open: Operation not supported
  Makefile:36: recipe for target 'check' failed
  make[1]: *** [check] Error 1
  make[1]: Leaving directory '/<>/lmdbxx-0.9.14.1+git20160228.0b43ca8'
  dh_auto_test: make -j1 check returned exit code 2
  debian/rules:18: recipe for target 'build-arch' failed
  make: *** [build-arch] Error 2

Could you please take a look?

Thanks!

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

Bug#881785: gnome-session-flashback: input source does not show input mode

[T Yamada]

Package: gnome-session-flashback
Version: 3.22.0-3
Severity: important
Tags: patch

Dear Maintainer,

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

gnome-session-flashback's input source does not show input mode, so I cannot
select Hiragana in ibus-mozc.

It is fixed in upstream: https://bugzilla.gnome.org/show_bug.cgi?id=788547
Debian buster is ok, but stretch will not have gnome 3.26... So could you
backport the fix to 3.22?

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



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

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

Versions of packages gnome-session-flashback depends on:
ii  gnome-flashback3.22.0-3
ii  gnome-panel3.20.1-1+b2
ii  gnome-session-bin  3.22.3-1
ii  gnome-session-common   3.22.3-1
ii  gnome-settings-daemon  3.22.2-2+deb9u2
ii  metacity   1:3.22.1-1
ii  nautilus   3.22.3-1+deb9u1

Versions of packages gnome-session-flashback recommends:
ii  gnome-power-manager  3.22.2-2
ii  gnome-screensaver3.6.1-7+b2

Versions of packages gnome-session-flashback suggests:
ii  desktop-base  9.0.2+deb9u1
ii  gnome-keyring 3.20.0-3
ii  gnome-user-guide  3.22.0-1

-- no debconf information

Bug#881782: earlyoom: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: earlyoom
Version: 0.12-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of earlyoom for hurd-i386 (admittedly not a release
architecture) failed:

  kill.c:104:12: error: 'PATH_MAX' undeclared (first use in this function); did 
you mean 'NAME_MAX'?

The Hurd famously has no static PATH_MAX.  Best practice is to
allocate path buffers dynamically based on what you actually
encounter, but if that's not convenient, you can look up _PC_PATH_MAX
via pathconf or define a fallback constant (traditionally 4096).

Could you please take a look?

Thanks!

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

Bug#881783: libesedb: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: libesedb
Version: 20170121-3
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

Builds of libesedb for hurd-i386 (admittedly not a release
architecture) have been failing:

  libcpath_path.c:487:45: error: 'PATH_MAX' undeclared (first use in this 
function); did you mean 'INT8_MAX'?

The Hurd famously has no static PATH_MAX.  Best practice is to
allocate path buffers dynamically based on what you actually
encounter, but if that's not convenient, you can look up _PC_PATH_MAX
via pathconf or define a fallback constant (traditionally 4096).

Could you please take a look?

Thanks!

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

Bug#881781: stenc: FTBFS on non-Linux: memset, memcpy, strncmp undeclared

[Aaron M. Ucko]

Source: stenc
Version: 1.0.7-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

Builds of stenc for hurd-i386 and kfreebsd-* (admittedly not release
architectures) have been failing:

  main.cpp: In function 'int main(int, char**)':
  main.cpp:72:5: error: 'memset' was not declared in this scope
  main.cpp:76:5: error: 'memcpy' was not declared in this scope
  main.cpp:107:13: error: 'strncmp' was not declared in this scope

These declarations are absent because upstream for some reason decided
to conditionalize the inclusion of  (and , for
that matter) on OS_LINUX.  These are bog-standard headers that should
be safe to #include unconditionally.  However, if the upstream
developers really want to be paranoid, they can capitalize on the
build system's existing checks and conditionalize on HAVE_STRING_H
and/or HAVE_STDLIB_H as desired.

Could you please take a look?

Thanks!

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

Bug#881780: clamav-freshclam: reconfiguring to manual update doesn't disable daemon

[Bob Bib]

Package: clamav-freshclam
Version: 0.99.3~beta1+dfsg-2
Severity: normal

Dear Maintainer,

I've tried reconfiguring clamav-freshclam,
to disable the daemon:

# dpkg-reconfigure clamav-freshclam
...
Virus database update method: manual
...

The reconfiguration process ends up with database update and stopped daemon;
unfortunately, after reboot, the daemon starts again.

$ ps -ef | grep freshclam
clamav 505 1  0 Nov14 ?00:00:10 /usr/bin/freshclam -d 
--foreground=true

Workaround.
Add the following line to "/etc/clamav/freshclam.conf":

Checks 0

After reboot, the daemon tries to start, but exits succesfully with a warning.

$ journalctl | grep freshclam
Nov 14 01:07:35 Computer freshclam[501]: WARNING: Number of checks must be a 
positive integer.
Nov 14 01:07:35 Computer systemd[1]: clamav-freshclam.service: Main process 
exited, code=exited, status=41/n/a
Nov 14 01:07:35 Computer systemd[1]: clamav-freshclam.service: Failed with 
result 'exit-code'.



-- Package-specific info:
--- configuration ---
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate true
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
ConnectTimeout 30
ReceiveTimeout 30
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
SafeBrowsing false
Bytecode true
NotifyClamd /etc/clamav/clamd.conf
DatabaseMirror db.ua.clamav.net
DatabaseMirror database.clamav.net

--- data dir ---
total 240088
-rw-r--r-- 1 clamav clamav766976 Nov  8 00:25 bytecode.cld
-rw-r--r-- 1 clamav clamav 127169536 Nov 14 02:14 daily.cld
-rw-r--r-- 1 clamav clamav 117892267 Nov  3 02:00 main.cvd
-rw--- 1 clamav clamav   364 Nov 14 04:14 mirrors.dat

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

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

Versions of packages clamav-freshclam depends on:
ii  clamav-base0.99.3~beta1+dfsg-2
ii  debconf [debconf-2.0]  1.5.64
ii  dpkg   1.18.24
ii  init-system-helpers1.50
ii  libc6  2.24-17
ii  libclamav7 0.99.3~beta1+dfsg-2
ii  libssl1.1  1.1.0f-5
ii  logrotate  3.11.0-0.1
ii  lsb-base   9.20170808
ii  procps 2:3.3.12-3
ii  ucf3.0036
ii  zlib1g 1:1.2.8.dfsg-5

clamav-freshclam recommends no packages.

Versions of packages clamav-freshclam suggests:
pn  apparmor 
pn  clamav-docs  

-- debconf information:
* clamav-freshclam/SafeBrowsing: false
  clamav-freshclam/internet_interface:
* clamav-freshclam/LogRotate: true
  clamav-freshclam/proxy_user:
* clamav-freshclam/Bytecode: true
* clamav-freshclam/local_mirror: db.ua.clamav.net (Ukraine)
* clamav-freshclam/update_interval: 1
* clamav-freshclam/autoupdate_freshclam: manual
* clamav-freshclam/http_proxy:
* clamav-freshclam/NotifyClamd: true
* clamav-freshclam/PrivateMirror:

--
Best wishes,
Bob

Bug#881779: ruby2.5: FTBFS on kFreeBSD: megacontent-copy_stream timeout

[Aaron M. Ucko]

Source: ruby2.5
Version: 2.5.0~preview1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: kfreebsd

Builds of ruby2.5 for kfreebsd-* (admittedly not release
architectures) failed per the below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=kfreebsd-amd64=2.5.0%7Epreview1-1=1510662681=0
and
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=kfreebsd-i386=2.5.0%7Epreview1-1=1510662421=0
(appearing identically in both).  Could you please take a look?

Thanks!



#452 test_io.rb:87:in `block in ': 
   at_exit { p :foo }
   
   megacontent = "abc" * 12345678
   #File.open("megasrc", "w") {|f| f << megacontent }
   
   t0 = Thread.main
   Thread.new { sleep 0.001 until t0.stop?; Process.kill(:INT, $$) }
   
   r1, w1 = IO.pipe
   r2, w2 = IO.pipe
   t1 = Thread.new { w1 << megacontent; w1.close }
   t2 = Thread.new { r2.read; r2.close }
   IO.copy_stream(r1, w2) rescue nil
   w2.close
   r1.close
   t1.join
   t2.join
  #=> killed by SIGKILL (signal 9) (timeout)
| bootstraptest.tmp.rb:14:in `copy_stream': Interrupt
|   from bootstraptest.tmp.rb:14:in `'
  megacontent-copy_stream
FAIL 1/1197 tests failed
uncommon.mk:659: recipe for target 'yes-btest-ruby' failed

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

Bug#881778: ruby2.5: FTBFS on hurd-i386: recipe for build-ext failed (no rule for note)

[Aaron M. Ucko]

Source: ruby2.5
Version: 2.5.0~preview1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of ruby2.5 for hurd-i386 (admittedly not a release
architecture) failed, per the below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=hurd-i386=2.5.0%7Epreview1-1=1510662502=0:

  ./miniruby -I./lib -I. -I.ext/common  ./tool/generic_erb.rb -o exts.mk -c \
  ./template/exts.mk.tmpl --gnumake=yes
  exts.mk updated
  make -f exts.mk -w libdir="/usr/lib" LIBRUBY_EXTS=./.libruby-with-ext.time \
  EXTENCS="dmyenc.o" UPDATE_LIBRARIES=no 
  make[3]: Entering directory '/<>'
  make[3]: Nothing to be done for 'all'.
  make[3]: Leaving directory '/<>'
  make -f exts.mk -w RUBY="./miniruby -I./lib -I. -I.ext/common " 
top_srcdir="." note
  make[3]: Entering directory '/<>'
  make[3]: *** No rule to make target 'note'.  Stop.
  make[3]: Leaving directory '/<>'
  uncommon.mk:236: recipe for target 'build-ext' failed
  make[2]: *** [build-ext] Error 2

Given that exts.mk is generated, this error presumably points to a
problem with miniruby.

Could you please take a look?

Thanks!

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

Bug#881776: AttributeError: 'NoneType' object has no attribute 'get_pixel'

[dann frazier]

Package: gtk-recordmydesktop
Version: 0.3.8-4.1
Severity: normal

It crashes on startup (gnome-shell/wayland desktop):

dannf@xps13:~$ gtk-recordmydesktop 
Traceback (most recent call last):
  File "/usr/bin/gtk-recordmydesktop", line 43, in 
main()
  File "/usr/bin/gtk-recordmydesktop", line 40, in main
tr=rmdSimple.simpleWidget()
  File "/usr/lib/python2.7/dist-packages/recordMyDesktop/rmdSimple.py", line 
505, in __init__
self.__subWidgets__()
  File "/usr/lib/python2.7/dist-packages/recordMyDesktop/rmdSimple.py", line 
88, in __subWidgets__
self.image=sT.GtkThumbSelector(self,self.values[5],self.hidden,2000)
  File "/usr/lib/python2.7/dist-packages/recordMyDesktop/rmdSelectThumb.py", 
line 69, in __init__
self.__subsample__(sroot,self.wwidth,self.wheight,self.root,self.factor)
  File "/usr/lib/python2.7/dist-packages/recordMyDesktop/rmdSelectThumb.py", 
line 79, in __subsample__
im2.put_pixel(k/stride,i/stride,im1.get_pixel(k,i))
AttributeError: 'NoneType' object has no attribute 'get_pixel'


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

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

Versions of packages gtk-recordmydesktop depends on:
ii  python   2.7.14-1
ii  python-gtk2  2.24.0-5.1
ii  python2.72.7.14-2
ii  recordmydesktop  0.3.8.1+svn602-1+b2

gtk-recordmydesktop recommends no packages.

gtk-recordmydesktop suggests no packages.

-- no debconf information

Bug#881664: Reproducible-build

[Danny Lee]

Hi,

This is the simple correction. It was later found that chessx package takes
the hostname into the account when it gets built which makes the program
not reproducible not different number of cores. At the moment, the culprit
is the autoreconf where it uses the hostname in the configuration but it is
still in the investigation.

Cheers,
Danny

Bug#881753: closed by Joachim Breitner <nome...@debian.org> (Bug#881753: fixed in local-apt-repository 0.5)

[Joachim Breitner]

Hi,

Am Dienstag, den 14.11.2017, 23:49 +0100 schrieb Andreas Beckmann:
> On 11/14/2017 11:24 PM, Debian Bug Tracking System wrote:
> >* Make sure /etc/apt/sources.list.d/ exists only when package is 
> > installed
> >  (but not removed but not purged) (Closes: #881753)
> 
> That sounds like postrm remove: 'rm -rf /etc/apt/sources.list.d/' which
> made me curious :-) (Good, it doesn't do *that* rm)
> 
> I think your postinst wants a 'ln -sf' (otherwise it may fail on
> reinstall/upgrade if the link exists already).
> And you may want a .maintscript to rm_conffile the old conffile properly.

thanks for the suggestions, they are now in 0.6

Cheers,
Joachim
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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

Bug#881769: udev: Docs on upgrading to predictable network interface names don't work

[Michael Biebl]

Am 14.11.2017 um 23:46 schrieb Karl O. Pinc:
> Package: udev
> Version: 232-25+deb9u1
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> The stretch README.Debian.gz for udev omits mention that
> update-initramfs -u must be run after changing configuration files
> when converting to the new "predictable network interface names".
> 

Well, we already mention it earlier:


  - Disable the default *.link rules with
"ln -s /dev/null /etc/systemd/network/99-default.link"
and rebuild the initrd with "update-initramfs -u".

Besides, your patch seems to contain a lot of other changes.
Please elaborate

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#881775: gcc-7-base: please add Breaks: gnat (<< 7)

[Andreas Beckmann]

Package: gcc-7-base
Version: 7.2.0-14
Severity: normal

Hi,

please add a 
  Breaks: gnat (<< 7)
to gcc-7-base (and merge this to gcc-8-base ...) to fix some stretch ->
buster upgrade paths involving old ada libraries where apt may prefer to
keep gnat-6 installed instead of switching to gnat-7 ...

(This would probably solve itself in case src:gcc-6 leaves buster.)
(I assume there is a good reason for gnat-6 and gnat-7 not being
co-installable.)


Thanks

Andreas

Bug#881774: python-oslo.messaging: leaves alternatives after purge: /usr/bin/oslo-messaging-zmq-proxy

[Andreas Beckmann]

Package: python-oslo.messaging
Version: 5.30.0-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

While there is ongoing discussion how to remove alternatives correctly
(see https://bugs.debian.org/71621 for details) the following strategy
should work for regular cases:
* 'postinst configure' always installs the alternative
* 'prerm remove' removes the alternative
* 'postrm remove' and 'postrm disappear' remove the alternative
In all other cases a maintainer script is invoked (e.g. upgrade,
deconfigure) the alternatives are not modified to preserve user
configuration.
Removing the alternative in 'prerm remove' avoids having a dangling link
once the actual file gets removed, but 'prerm remove' is not called in
all cases (e.g. unpacked but not configured packages or disappearing
packages) so the postrm must remove the alternative again
(update-alternatives gracefully handles removal of non-existing
alternatives).

Note that the arguments for adding and removing alternatives differ, for
removal it's 'update-alternatives --remove  '.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

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

1m4.8s INFO: Warning: Package purging left files on system:
  /etc/alternatives/oslo-messaging-zmq-proxy -> 
/usr/bin/python2-oslo-messaging-zmq-proxynot owned
  /usr/bin/oslo-messaging-zmq-proxy -> 
/etc/alternatives/oslo-messaging-zmq-proxynot owned


This was observed after a stretch->buster upgrade, there is no such
problem while testing only stretch or buster.
So this is likely an obsolete alternative, and the postinst script
in stretch should clean it up.


cheers,

Andreas


python-oslo.messaging_5.30.0-2.log.gz
Description: application/gzip

Bug#845498: [Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[peter green]

On 14/11/17 22:21, Abou Al Montacir wrote:

Hi Paul, and All,

I've just pushed a commit [1] that I hope will improve the situation of MA
support.

In this commit I've moved units from ${LIB_DIR}/units/${FPCTARGET}-${FPCARCH}
to ${LIB_DIR}/units/${FPCTARGET}-${FPCARCH}/'$${PACKAGE_NAME}'

where
LIB_DIR=/usr/lib/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION}
FPCTARGET=$(CPU_TARGET)-$(OS_TARGET)
FPCARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH_ABI)

This makes each architecture installs its units in a separate directory.

I've also added a patch against fpcmkcfg to change /etc/fpc.cfg to look for the
units in the right place depending on the cpu/os tragets and the used ARCH/ABI.

I did not upload this as I did not test it extensively and I fear this is a
quite big change that may require manual upload for many arches is not tested
extensively before it is uploaded. I'd prefer to have it in experimental first
also in order to avoid annoyance to our users.

Please let me know what do you think about it.

[1]: https://anonscm.debian.org/cgit/pkg-pascal/fpc.git/commit/?id=a5bfc6ba0fa81
c9e1d627d9314078cb1ddb3d329


Going to experimental before unstable with aggressive changes certainly makes 
sense. IIRC experimental buildds only use build-depends from experimental when 
required to satisfy version constraints, so by changing version constraints one 
can choose whether to build a new version in experimental with the previous 
version from experimental or with the known-good version from unstable.

However I am skeptical as to whether such an aggressive change is really 
needed. IMO given the relatively small scale of this problem it makes more 
sense to leave most architectures alone and only deviate from upstream where we 
actually need to do so.

I just ran a quick check and currently the only architectures with a conflict 
are armel and armhf. It seems likely ppc64el would also have a conflict but IMO 
we can cross that bridge when we come to it.

Bug#881344: aptitude: Cannot initiate the connection to - while wget can grab the file

[Manuel A. Fernandez Montecelo]

2017-11-15 0:00 GMT+01:00 Benoît-Pierre DEMAINE :
> On 14/11/17 22:42, Manuel A. Fernandez Montecelo wrote
> Would you
> be able to try, or are the packages/ABIs completely incompatible?
>
>
> Try what ?

To try to install the equivalent package but from Debian mirrors -- if
it can work along with the rest of the binaries of the system.

Even if we discovered that it was a problem that we could fix, we
don't have any control over Raspbian repositories, after all.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#881773: ruby2.5: FTBFS on hppa: recursive once test fails

[Aaron M. Ucko]

Source: ruby2.5
Version: 2.5.0~preview1-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of ruby2.5 for hppa (admittedly not a release architecture)
failed per the below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=hppa=2.5.0%7Epreview1-1=1510669827=0

Could you please take a look?

Thanks!



#361 test_insns.rb:389:in `block in ': 
   # recursive once
   def once n
 return %r/#{
   if n == 0
 true
   else
 once(n-1) # here
   end
 }/ox
   end
   x = once(128); x = once(7); x = once(16);
   x =~ "true" && $~
  #=> "" (expected "true")  once
FAIL 1/1197 tests failed
uncommon.mk:659: recipe for target 'yes-btest-ruby' failed

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

Bug#871948: aptitude search: please support build-depends et. al. as a depType for ~D, ~R, etc

[Manuel A. Fernandez Montecelo]

Hi,

2017-08-12 23:19 Ximin Luo:

Package: aptitude
Version: 0.8.8-1
Severity: wishlist

Dear Maintainer,

It would be nice if I could do something like

 $ aptitude search '~Rbuild-depends:sagemath'

which could help with managing transitions and things like that.


It would certainly help these situations.

However, as a note for possible implementations or people looking into
this in the future, pkgCache::Dep::DepType from apt-pkg/pkgcache.h does
only have into account dependencies between binary packages, so it's not
very straightforward to achieve.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep

[Aaron M. Ucko]

Source: ruby2.5
Version: 2.5.0~preview1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-powe...@lists.debian.org
Usertags: ppc64 ppc64el

Builds of ruby2.5 for ppc64el and the non-release architecture ppc64
have been failing per the below excerpt from

https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=ppc64el=2.5.0%7Epreview1-1=1510662722=0

FTR, the ppc64 log, which exhibits the same error, is at

https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=ppc64=2.5.0%7Epreview1-1=1510663941=0

Could you please take a look?

Thanks!

  1) Error:
TestBacktrace#test_caller_lev:
SystemStackError: stack level too deep
/<>/test/ruby/test_backtrace.rb:96:in `times'
/<>/test/ruby/test_backtrace.rb:96:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:92:in `times'
/<>/test/ruby/test_backtrace.rb:92:in `block in 
test_caller_lev'
/<>/test/ruby/test_backtrace.rb:106:in `block in 
test_caller_lev'

Finished tests in 517.516592s, 33.1661 tests/s, 4326.2574 assertions/s.
17164 tests, 2238910 assertions, 0 failures, 1 errors, 85 skips

ruby -v: ruby 2.5.0dev (2017-10-10) [powerpc64le-linux-gnu]
uncommon.mk:691: recipe for target 'yes-test-almost' failed

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

Bug#681726: Time to remove eclipse from Testing?

[Markus Koschany]

Am 09.11.2017 um 21:34 schrieb Jeremy Bicha:
[...]
> Have you considered dropping the libswt-webkit-gtk-3-jni dependency
> from eclipse-rcp? Then the swt-gtk source package could stop building
> libswt-webkit-gtk-3-jni and we could complete the webkitgtk removal
> from Debian Testing.
> 
> Thanks,
> Jeremy Bicha

Hi,

sorry for the delay.

I haven't tested that yet but I believe this will simply make the
package unusable for everyone. I'm not sure what we can do to assist you
in your effort to remove webkitgtk from Debian. Ok, most obviously we
could "just" package the latest Eclipse version but that won't happen
anytime soon.

We should definitely try to avoid this sort of dependency mess in the
future by packaging important libraries like eclipse-rcp in a separate
source package. That would be similar to what we are doing whith
Netbeans and libnb-platform18-java at the moment. It simply ensures that
we can resolve such issues more easily by dropping the hard to maintain
IDE but keeping other important dependencies which don't require that
much effort in theory.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#878416: aptitude still doesn't do good conflict resolution

[Manuel A. Fernandez Montecelo]

2017-10-13 15:19 shirish शिरीष:

Package: aptitude
Version: 0.8.9-1
Severity: normal

Dear Maintainer,
I have been trying to install libegl-mesa0 libegl1 libglvnd0 and
upgrade libgbm1 but without any success -

[$] sudo aptitude install libegl-mesa0=17.2.2-1 libgbm1=17.2.2-1
libegl1=0.2.999+git20170802-5 libglvnd0=0.2.999+git20170802-5
The following NEW packages will be installed:
 libegl-mesa0 libegl1{b} libglvnd0{b}
The following packages will be upgraded:
 libgbm1
1 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 261 kB of archives. After unpacking 1,042 kB will be used.
The following packages have unmet dependencies:
libegl1 : Breaks: libegl1-mesa (< 17.2.0~rc4-1) but 13.0.6-1+b2 is installed
libegl1-mesa : Depends: libgbm1 (= 13.0.6-1+b2) but 17.2.2-1 is to be installed
open: 255; closed: 6646; defer: 10; conflict: 42

The following actions will resolve these dependencies:

Keep the following packages at their current version:
1) libegl-mesa0 [Not Installed]
2) libegl1 [Not Installed]
3) libgbm1 [13.0.6-1+b2 (now, testing)]



Accept this solution? [Y/n/q/?] n
open: 652; closed: 44149; defer: 85; conflict: 196

I can understand if the package is uninstallable or something but the
amount of time it takes to give an alternative solution is a bit too
much. It has happened with this upgrade as well as other upgrades as
well. I am at a sort of loss to understand how to navigate this.
[...]


and


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


Essentially, aptitude tries hard to satisfy the users' requests, and the
problems grow exponentially when adding different suites and
architectures, because there are so many different possibilities to
combine packages.

If left to run long enough, probably it would end up spitting "no
solution".  You can stop it if you don't want to wait that long.

One way to guide its way to a quick solution would be to accept or
reject actions in the first solution offered, e.g., reject the solution
of keeping those not installed.

At least in the occasions that I did it, guiding aptitude to your
preferred outcomes leads to a very quick solution.  But there's never a
guarantee that it's not going to explore the possible solutions, even if
it takes ages.

So I am not sure if it's possible to do something, but I don't see that
changing this to not explore all solutions is a good option.

BTW, that doesn't mean that aptitude doesn't do good conflict resolution
-- maybe that's true, but I don't see this scenario as a good example of
that, because probably what you requested has no solution at all.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#881770: jbuilder: library builds fail on byte-code-only architectures

[Aaron M. Ucko]

Package: jbuilder
Version: 1.0~beta14-1
Severity: important
Tags: upstream
Control: affects -1 src:ocaml-migrate-parsetree

Builds of ocaml-migrate-parsetree on byte-code-only architectures
(armel, mips*, and some non-release architectures) have been failing:

  jbuilder build @install
  No rule found for 
_build/default/ocamlbuild_plugin/migrate_parsetree_ocamlbuild.cmx

It appears that when jbuilder encounters a library stanza with no
explicit modes setting, it always tries to produce both native and
byte-code versions, even when only the latter is an option on the
current architecture.  Please adjust the default modes setting to
reflect the availability of ocamlopt, as already done for executables
(at least according to
https://github.com/janestreet/jbuilder/blob/master/doc/jbuild.rst).

Thanks!

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

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

Versions of packages jbuilder depends on:
ii  libc6  2.24-17

jbuilder recommends no packages.

jbuilder suggests no packages.

-- no debconf information

Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

[Karl O. Pinc]

Package: release-notes
Severity: normal

Hi,

Section 4.7 "Preparing for the next release" of the jessie->stretch
release notes do not mention that Debian 10 will require migration to
the kernel's "predictable network names".  (Or, I imagine, manual
assignment of network names.)

Because users are going to have to migrate anyway it might be useful
to do so sooner rather than later and "prepare for the next release".  :-)

See:
/usr/share/doc/udev/README.Debian.gz
https://sources.debian.org/src/systemd/235-2/debian/udev.README.Debian/
Bug#881769

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

Bug#881344: aptitude: Cannot initiate the connection to - while wget can grab the file

[Benoît-Pierre DEMAINE]

On 14/11/17 22:42, Manuel A. Fernandez Montecelo wrote:
> Would you
> be able to try, or are the packages/ABIs completely incompatible? 

Try what ?

I had similar issue (but not identical) with several old Debian running
under chroot. It really looks to me as a resolution issue, or a timeout;
IPv6 may be involved. Fact is, wget makes it better than aptitude.

-- 
 >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would'nt have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Bug#881769: udev: Docs on upgrading to predictable network interface names don't work

[Karl O. Pinc]

Package: udev
Version: 232-25+deb9u1
Severity: normal
Tags: patch

Hi,

The stretch README.Debian.gz for udev omits mention that
update-initramfs -u must be run after changing configuration files
when converting to the new "predictable network interface names".

Attached is a patch which clarifies the README.Debian.

Note also that the upgrade process would be greatly simplified if
there was a tool which reported the default "predictable network
interface name"s, along with their MAC address for mapping to existing
network interface names.

Regards,
Karl

-- Package-specific info:

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
P: /devices/LNXSYSTM:00
E: DEVPATH=/devices/LNXSYSTM:00
E: MODALIAS=acpi:LNXSYSTM:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:02
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXPWRBN:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=938931

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event3
N: input/event3
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event3
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event3
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=67
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=879724
E: XKBLAYOUT=us
E: XKBMODEL=pc105
E: XKBOPTIONS=terminate:ctrl_alt_bksp

P: /devices/LNXSYSTM:00/LNXSYBUS:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: MODALIAS=acpi:LNXSYBUS:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0103:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0103:00
E: MODALIAS=acpi:PNP0103:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: MODALIAS=acpi:PNP0A03:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:02
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:02
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:03
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:04
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:04
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:06
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:06
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP:00
E: MODALIAS=acpi:PNP:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0100:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0100:00
E: MODALIAS=acpi:PNP0100:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0200:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0200:00
E: MODALIAS=acpi:PNP0200:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0303:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0303:00
E: MODALIAS=acpi:PNP0303:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0401:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0401:00
E: MODALIAS=acpi:PNP0401:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/PNP0501:00
E: 

Bug#881753: closed by Joachim Breitner <nome...@debian.org> (Bug#881753: fixed in local-apt-repository 0.5)

[Andreas Beckmann]

On 11/14/2017 11:24 PM, Debian Bug Tracking System wrote:
>* Make sure /etc/apt/sources.list.d/ exists only when package is installed
>  (but not removed but not purged) (Closes: #881753)

That sounds like postrm remove: 'rm -rf /etc/apt/sources.list.d/' which
made me curious :-) (Good, it doesn't do *that* rm)

I think your postinst wants a 'ln -sf' (otherwise it may fail on
reinstall/upgrade if the link exists already).
And you may want a .maintscript to rm_conffile the old conffile properly.


Andreas

Bug#874015: aptitude: forgets selection state for package downgrade

[Manuel A. Fernandez Montecelo]

Hi Yann,

2017-09-02 00:22 Yann Dirson:

Package: aptitude
Version: 0.8.7-1
Severity: normal

Let's choose a package tha is a candidate for upgrade (previous testing
version is installed, and more recent than current stable version).

If I select it for upgrade to testing and quit aptitude, the selected
version is still selected when I launch aptitude again.

Now if I select it for downgrade and quit, then on next launch
not only the downgrading choice is lost, but the package is now selected
for *upgrade*.


That's odd.  Is Auto-Upgrade enabled?



Combine this with a bug like #874012, where for some reason it seems to reset
selections as if user had quit and relaunched, and a time-consuming
selection of packages while attempting to restore a broken situation
just gets frustratingly lost.


There is no mention in that report about missing selections :-?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#879196: patch attached

[Ana C. Custura]

Hi Ghis,

Thank you for the patches. I have merged this one (I thought the way you
rewrote the rules file was very elegant), and the ones you sent
separately with regards to enabling tests. 
 
I'm waiting for a review - https://mentors.debian.net/package/yapf

Iain, what is the timeline for looking at this?

Thank you,
Ana

On Tue, Nov 14, 2017, at 09:42 AM, Ghislain Vaillant wrote:
> Here is a patch implementing the proposed split.
> Email had 1 attachment:
> + 0001-Ship-the-modules-in-separate-binary-packages.patch
>   5k (text/x-patch)

Bug#880958: yapf3 explicitly depends on python3.5

[Ghislain Vaillant]

What about the patches fixing the other two bugs affecting yapf? Please
consider checking the BTS.

Ghis


Le 14 nov. 2017 22:25, "Ana C. Custura"  a écrit :

Hi Ghis,

Thank you for the reply. There is a package on mentors that addresses
both this bug (88958) and the split (879196) bug you raised. I am
waiting for my mentor to review it before uploading.

Ana

On Tue, Nov 14, 2017, at 08:59 AM, Ghislain Vaillant wrote:
> Thank you Matthias for raising this issue. CC'ing the maintainer in case
> she's not subscribed.
>
> On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose  wrote:
> > Package: yapf3
> > Version: 0.17.0-1
> > Severity: serious
> > Tags: sid buster
> >
> > yapf3 explicitly depends on python3.5. One mistake certainly is the b-d
on
> > python3-all, which is wrong for an application-only package.
>
> The application is not compliant with the Python packaging guidelines.
> The public modules should be split from the application package. See
> #879196 for a discussion about it.
>
> I have proposed a patch offline but it has yet to be applied. Fixing
> #879196 will transitively fix the issue you just reported.
>
> > And if this package is application-only, why ship both Python2 and
Python3 vesions?
>
> It is nether application-only, nor Python 3 specific.
>
> Cheers,
> Ghis

Bug#881743: [PKG-Openstack-devel] Bug#881743: openstack-dashboard: fails to upgrade from 'stretch': Couldn't find anything to import: /horizon/lib/roboto_fontface/css/roboto-fontface.scss

[Thomas Goirand]

On 11/14/2017 06:42 PM, Andreas Beckmann wrote:
> Since the problem happened while running trigger processing of the
> *old* (stretch) version of openstack-dashboard, probably the package
> shipping (or no longer shipping) the "offending file"
> (roboto-fontface.scss ?) needs to declare a
> 
> Breaks: openstack-dashboard (<< 3:12)

Good catch, indeed, that should be the way to fix it.

FYI, Horizon copies and compile a bunch of js / css / scss, and
therefore, has a trigger on these packages, so that it can rebuild its
local (compiled / compress) copy whenever one of these packages update.

Now, I'm not sure where the logic is, and how this will affect other
packages than this one. :/ I guess our only hope here is testing, just
the way you do.

Cheers,

Thomas Goirand (zigo)

Bug#845498: [Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Abou Al Montacir]

Hi Paul, and All,

I've just pushed a commit [1] that I hope will improve the situation of MA
support.

In this commit I've moved units from ${LIB_DIR}/units/${FPCTARGET}-${FPCARCH}
to ${LIB_DIR}/units/${FPCTARGET}-${FPCARCH}/'$${PACKAGE_NAME}'

where 
LIB_DIR=/usr/lib/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION}
FPCTARGET=$(CPU_TARGET)-$(OS_TARGET)
FPCARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH_ABI)

This makes each architecture installs its units in a separate directory.

I've also added a patch against fpcmkcfg to change /etc/fpc.cfg to look for the
units in the right place depending on the cpu/os tragets and the used ARCH/ABI.

I did not upload this as I did not test it extensively and I fear this is a
quite big change that may require manual upload for many arches is not tested
extensively before it is uploaded. I'd prefer to have it in experimental first
also in order to avoid annoyance to our users.

Please let me know what do you think about it.

[1]: https://anonscm.debian.org/cgit/pkg-pascal/fpc.git/commit/?id=a5bfc6ba0fa81
c9e1d627d9314078cb1ddb3d329
-- 
Cheers,
Abou Al Montacir

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

Bug#880953: thunderbird: upon startup apparmor denies mmap of python3.6

[Simon Deziel]

On 2017-11-12 07:46 AM, intrigeri wrote:
> can you please review my MR upstream?

I'm not familiar with with GitLab (yet) so I don't know how to re-assign
to you but it LGTM.

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#880958: yapf3 explicitly depends on python3.5

[Ana C. Custura]

Hi Ghis,

Thank you for the reply. There is a package on mentors that addresses
both this bug (88958) and the split (879196) bug you raised. I am
waiting for my mentor to review it before uploading. 

Ana

On Tue, Nov 14, 2017, at 08:59 AM, Ghislain Vaillant wrote:
> Thank you Matthias for raising this issue. CC'ing the maintainer in case 
> she's not subscribed.
> 
> On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose  wrote:
> > Package: yapf3
> > Version: 0.17.0-1
> > Severity: serious
> > Tags: sid buster
> > 
> > yapf3 explicitly depends on python3.5. One mistake certainly is the b-d on
> > python3-all, which is wrong for an application-only package.
> 
> The application is not compliant with the Python packaging guidelines. 
> The public modules should be split from the application package. See 
> #879196 for a discussion about it.
> 
> I have proposed a patch offline but it has yet to be applied. Fixing 
> #879196 will transitively fix the issue you just reported.
> 
> > And if this package is application-only, why ship both Python2 and Python3 
> > vesions?
> 
> It is nether application-only, nor Python 3 specific.
> 
> Cheers,
> Ghis

Bug#881627: Congratulations AmazonShopper! fVhLRz

[mannywellz2005]

Bye


> On Nov 13, 2017, at 12:30 PM, AmazonReward Alert 
>  wrote:
> 
> Message for emanuel
> 
> 
> 
>
> 
>   
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Source: ruby-http-parser.rb Version: 0.6.0-3+b3 Severity: serious Tags: 
> upstream Dear Maintainer, your package build-depends on http-parser, and a 
> new version of that one has been around for a while. Even before eventually 
> uploading last night I already saw a problem in the test suite of your 
> package. However, due to a fault on my side, the new http-parser went to 
> unstable instead of experimental. So this increases the pressure for your 
> package, sorry about that. With http-parser 2.7.1, one test fails: 1) 
> HTTP::Parser should parse request: line folding in header value 
> Failure/Error: expect(@headers).to eq(test) expected: 
> {"Line1"=3D>"abcdefghijklmno qrs", "Line2"=3D>"line2\t"} got: 
> {"Line1"=3D>"abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2"= =3D>"line2\t"} 
> (compared using =3D=3D) Diff: @@ -1,3 +1,3 @@ -"Line1" =3D> "abcdefghijklmno 
> qrs", +"Line1" =3D> "abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2" =3D> 
> "line2\t", # ./spec/parser_spec.rb:347:in `block (4 levels) in ' If I 
> understand correctly, this is taken from spec/support/requests.json line 445 
> and 457f. While doubtlessly http-parser changed the behaviour, I'm not sure 
> yet whether this wasn't rather about fixing bugs - bugs the test in 
> ruby-http-parser.rb relied upon. However, HTTP header line folding is 
> complicated and actually also deprecated in RFC 7230. Reading that one and 
> also the older description in RFC 2616 I guess there a too many freedoms to 
> expect a certain result. Also it seems http-parser 2.7.1 does unfolding in a 
> ... surprising manner. Now, quite frankly, my main interest is a sound 
> solution. Otherwise, I'm not keen on legal discussions, especially when it's 
> about a deprecated feature like this one. It's my job to sort these things 
> out with http-parser upstream but since I'm not sure how long this will take: 
> Would you mind disabling or relaxing the test on your side for the time 
> being? You might as well upgrade the test to the one in 
> http-parser/test.c=C2=B9 which is where obviously it was taken from in the 
> first place - but I'd expect this to change again soon. Sorry for the mess, 
> and kind regards, Christoph =C2=B9 
> https://github.com/nodejs/http-parser/blob/master/test.c (line 614)

Bug#881291: libdbd-sqlite3-perl FTBFS with libsqlite3-dev 3.21.0-1

[gregor herrmann]

Control: forwarded -1 https://github.com/DBD-SQLite/DBD-SQLite/issues/28

On Tue, 14 Nov 2017 21:43:25 +, Damyan Ivanov wrote:

> So this seems like a genuine problem with newer sqlite. Upstream's 
> sqlite3.h is 3.13.0, while Debian/unstable now has 3.21.0.

Upstream's git master is at 3.20.1 but still not at 3.21.x

And Florian was faster with forwarding:
https://github.com/DBD-SQLite/DBD-SQLite/issues/28
:)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: All the World Is Green


signature.asc
Description: Digital Signature

Bug#881422: Seems like some signal callbacks are causing the wait

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Dominique,

2017-11-14 00:20 Dominique Brazziel:

I found some signal mask stuff that must be the source of the futex waits
in do_changelog stuff from the source. Looking at the source code now.


There was a change in libapt to make things more general, and we didn't
adapt in time.  Basically it's to use "store://" instead of "gzip://"
in the URIs to download the changelog.

Fix on its way now.

Thanks for reporting and for taking a look into it.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#881768: 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. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#881767: sensible-utils: Argument injection in sensible-browser

[Gabriel Corona]

Package: sensible-utils
Version: 0.0.10
Severity: grave
Tags: security
Justification: user security hole

When the BROWSER environment variable is set, an invalid URI can be
used to inject arguments in sensible-browser.


Description
===

When BROWSER is set, sensible-browser calls the actual browser with:

~~~sh
cmd=$(printf "$i\n" "$URL")
$cmd && exit 0
~~~

If a IFS character is in $URL, this leads to the injection of extra
arguments when calling the actual browser.

For example, this commands triggers the incognito mode of Chromium:

~~~sh
BROWSER=chromium sensible-browser "http://www.example.com/ --incognito
~~~

This URI is invalid but if the caller does not properly validate the
URI, an attacker could add extra arguments when calling the browser.


For example, Emacs might call sensible-browser with an invalid
URI. With this configuration:

~~~elisp
(setq browse-url-browser-function (quote browse-url-generic))
(setq browse-url-generic-program "sensible-browser")
~~~

an org-mode file like this one:

~~~org
[[http://www.yahoo.fr --incognito][test]]
~~~

will trigger the incognito mode of Chromium (this does not happen with
org-mode 8.2.10 shipped in the emacs25 package but it does happen
using org-mode 9.1.2 shipped in the elpa-org package).


While this particular example is not very dangerous other arguments
can be more harmful. For example, it is possible to inject an argument
which overrides the proxy configuration (with a PAC file). This
org-mode link launches Chromium with an alternative PAC file
(silently):


~~~org
[[http://www.example.com/ 
--proxy-pac-file=http://dangerous.example.com/proxy.pac][test]]
~~~

An attacker could use this type of URI, to forward all the traffic
coming from the browser to a server he's controlling.



Possibles fixes
===

* A simple fix, would be for sensible-browser to actually check that
  the URI parameter does not contain any IFS character (which are not
  valid in URI or IRI and fail if it does).  It should probably add
  extra verification (such as checking that the argument does not
  begin by a dash).

* Another solution would be to escape IFS characters.

* The simpler fix would probably to drop support for "%s" in the
  BROWSER string: this feature is not supported by other programs
  anyway. This is "Alternative Secure BROWSER Definition" in [1].

* Or we could implement "Compatible Secure BROWSER Definition" from
  [1] but it may not be very convenient to do in shell.

Moreover, we should probably add some basic URI validation in order to
reject things like:

~~~sh
BROWSER=chromium sensible-browser "--incognito"
~~~



Additional problems
===

sensible-browser does not handle empty browser in the BROWSER
environment variable:

~~~sh
BROWSER=":chromium" sensible-browser "xterm"
~~~

This command runs xterm (we could have used "rm -rf /").



Similar vulnerabilities in other packages
=

* lilypond

  lilypond-invoke-editor is vulnerable to the same argument injection
  [2]:

  ~~~sh
  BROWSER="chromium" lilypond-invoke-editor "http://www.example.com/ 
--incognito"
  ~~~
  
  Lilypond suggests using it as URI handler [3]:

  > When this functionality is active, LilyPond adds hyperlinks to the
  > PDF file. These hyperlinks are sent to a ‘URI helper’
  > or a web-browser, which opens a text-editor with the cursor in
  > the right place.
  >
  > To make this chain work, you should configure your PDF viewer
  > to follow hyperlinks using the ‘lilypond-invoke-editor’
  > script supplied with LilyPond.
  >
  > The program ‘lilypond-invoke-editor’ is a small helper program.
  > It will invoke an editor for the special textedit URIs, and run
  > a web browser for others. [...]

* xdg-open

  xdg-open's 'envvar' implementation (open_envvar) has this same
  problem when '%s' is present in $BROWSER:

  # Triggers incognito mode:
  BROWSER="chromium %s" xdg-open "http://www.example.com/ --incognito"

  # Does not trigger incognito mode:
  BROWSER="chromium" xdg-open "http://www.example.com/ --incognito"


References
==

[1] https://www.dwheeler.com/browse/secure_browser.html

[2] 
http://sources.debian.net/src/lilypond/2.18.2-9/scripts/lilypond-invoke-editor.scm/#L129

[3] 
http://lilypond.org/doc/v2.18/Documentation/usage/configuring-the-system-for-point-and-click

[4] https://specifications.freedesktop.org/desktop-entry-spec/1.1/ar01s06.html


Thanks to Bastien Roucaries for some material and references.

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

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

-- no debconf information

Bug#881762: ITA: gtkterm/0.99.7~rc1-1

[Adam Borowski]

On Tue, Nov 14, 2017 at 10:19:27PM +0100, Willem van den Akker wrote:
> * Package name: gtkterm
>   Version : 0.99.7~rc1-1
>   Upstream Author : [fill in name and email of upstream]
> * URL : [fill in URL of upstreams web site]
> * License : [fill in]
>   Section : comm
> 
>   Changes since the last upload:
> 
>   * New maintainer upload (Closes: #857476).
>   * debian/control
> - description updated conform Developer's Reference.
>   * Bump standards version to 4.1.1.1.

> Remarks:
> Homepage, watch file are not known yet. gtkterm has many, often
> inactive, respositories. I am in contact with a few owners to take
> over the most recent respository. After that a new release and
> homepage/watch file are filled in.
> Also one file serie.c is modified other then the 'quilt-way'. This will
> be corrected after a new version upload.

I don't see any changes other than removal of an article from the short desc
and removal of the Homepage: field.

Thus, this upload would serve no other purpose than to stake your claim. 
This can be done just by mentioning in the ITA bug.

I'd refrain from uploading until there are some actual changes.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.

Bug#881766: barbican: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: barbican 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of barbican 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#794138: reopening 794138

[Helmut Grohne]

On Mon, Nov 13, 2017 at 06:33:20AM +0100, Petter Reinholdtsen wrote:
> I added this in 2014, to ensure it was impossible for a autobuilder to
> build a package that did not handle the test suite, to avoid ending up
> with unbootable systems on some of the less used architectures.  I
> believe this is an important safety fuse in the build system.  As long
> as the default build will run the check, I am fine with the change.

Unless DBE_BUILD_OPTIONS contains nocheck, dh_auto_test will run the
target.

I do note that some autobuilders (maybe m68k?) set that, but that seems
like deliberately accepting breakage to me. (Cross builders of course
do.)

> If dh_auto_test now run 'make check' automatically, can you figure out
> which version of it started doing this, and update the build
> dependencies, to ensure it still is impossible to build the source
> without checking that it work?

I traced down the debhelper git history and it did that since the
invention of dh_auto_test in version 7.0.0. Support for nocheck came
later.

Helmut

Bug#878183: systemd-journal-remote: Should stop creating systemd-journal-gateway user

[Martin Pitt]

Control: tag -1 pending

Martin Pitt [2017-10-11 22:37 +0200]:
> if there's any doubt in whether it's safe to remove, I think it's okay to not
> bother -- after all, a DynamicUser= unit will still use the existing system
> user if it exists, so there isn't that much gain in cleaning it up.

Done in git now.

Martin


signature.asc
Description: PGP signature

Bug#881291: libdbd-sqlite3-perl FTBFS with libsqlite3-dev 3.21.0-1

[Florian Schlichting]

Control: Forwarded 881291 https://github.com/DBD-SQLite/DBD-SQLite/issues/28

> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libdbd-sqlite3-perl.html
> 
> ...
> Test Summary Report
> ---
> t/virtual_table/rt_99748.t  (Wstat: 512 Tests: 24 
> Failed: 1)
>   Failed test:  24
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 52 tests but ran 24.
> Files=105, Tests=3555, 22 wallclock secs ( 0.81 usr  0.26 sys + 12.46 cusr  
> 1.88 csys = 15.41 CPU)
> Result: FAIL
> Failed 1/105 test programs. 1/3555 subtests failed.
> Makefile:1078: recipe for target 'test_dynamic' failed
> make[1]: *** [test_dynamic] Error 2


I can confirm that it fails with libsqlite3-dev 3.21.0-1 and does not fail
with 3.20.1-2, all else being equal.

The test fails because of two warnings about uninitialized values, which
lead to a syntax error (missing operator) in the generated/eval'd code:

couldn't eval q{sub {my ($self, $i) = @_; my $row = $self->row($i); 
(defined($row->[1]) && defined($vals[0]) && $row->[1]  $vals[0])}} : syntax 
error at (eval 19) line 1, near "]  $vals"

#   Failed test 'no warnings'
#   at /usr/share/perl/5.26/Test/Builder.pm line 135.
# There were 2 warning(s)
#   Previous test 23 'SELECT rowid FROM vtb WHERE c = 'six''
#   Use of uninitialized value $op in pattern match (m//) at 
/home/fs/src/pkg-perl/git/packages/libdbd-sqlite3-perl/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm
 line 104.
#  at 
/home/fs/src/pkg-perl/git/packages/libdbd-sqlite3-perl/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm
 line 104.
#   
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x557070b2ec60),
 ARRAY(0x557070b277e8), ARRAY(0x557070b271e8)) called at 
/home/fs/src/pkg-perl/git/packages/libdbd-sqlite3-perl/blib/lib/DBD/SQLite.pm 
line 202
#   DBD::SQLite::db::prepare(DBI::db=HASH(0x557070b15c60), "SELECT a FROM 
vtb WHERE b IS NULL ORDER BY a", undef) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 1690
#   DBD::_::db::selectcol_arrayref(DBI::db=HASH(0x557070b15c60), "SELECT a 
FROM vtb WHERE b IS NULL ORDER BY a") called at t/virtual_table/rt_99748.t line 
80
#   main::test_table(DBI::db=HASH(0x557070b15d08), "vtb") called at 
t/virtual_table/rt_99748.t line 57
# 
# --
#   Previous test 23 'SELECT rowid FROM vtb WHERE c = 'six''
#   Use of uninitialized value $op in concatenation (.) or string at 
/home/fs/src/pkg-perl/git/packages/libdbd-sqlite3-perl/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm
 line 108.
#  at 
/home/fs/src/pkg-perl/git/packages/libdbd-sqlite3-perl/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm
 line 108.
#   
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x557070b2ec60),
 ARRAY(0x557070b277e8), ARRAY(0x557070b271e8)) called at 
/home/fs/src/pkg-perl/git/packages/libdbd-sqlite3-perl/blib/lib/DBD/SQLite.pm 
line 202
#   DBD::SQLite::db::prepare(DBI::db=HASH(0x557070b15c60), "SELECT a FROM 
vtb WHERE b IS NULL ORDER BY a", undef) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 1690
#   DBD::_::db::selectcol_arrayref(DBI::db=HASH(0x557070b15c60), "SELECT a 
FROM vtb WHERE b IS NULL ORDER BY a") called at t/virtual_table/rt_99748.t line 
80
#   main::test_table(DBI::db=HASH(0x557070b15d08), "vtb") called at 
t/virtual_table/rt_99748.t line 57
# 
# Looks like your test exited with 2 just after 24.
t/virtual_table/rt_99748.t 

Florian

Bug#878182: systemd: Should stop creating systemd-bus-proxy user

[Martin Pitt]

Control: tag -1 pending

Michael Biebl [2017-10-11 18:41 +0200]:
> This one seems safe. v232 from stretch no longer ships the
> systemd-bus-proxyd service, so we can safely drop the useradd call and
> remove the obsolete system user account.

Agreed. Done in git.

Martin

Bug#835654: [Pkg-net-snmp-devel] Orphaning net-snmp?

[Paul Gevers]

Hi Craig,

On Thu, 20 Apr 2017 21:42:22 + Craig Small  wrote:
> I tried taking over this but the alioth permissions were wrong and admin is
> unresponsive.

So why not move it over to collab-maint and be done with it?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge

[Guido Günther]

Hi,
On Tue, Nov 14, 2017 at 08:00:42PM +0100, Víctor Cuadrado Juan wrote:
> Package: git-buildpackage
> Version: 0.9.1
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello,
> 
> While importing upstream's version 0.36.0 of package guitarix, I've found that
> `gbp --import-orig --merge-mode=replace` and `--merge-mode=auto` behaves as
> `--merge-mode=merge`. To reproduce do:
> 
> I've reproduced this bug against gbp 0.9.1 and 0.9.2. Please see attached
> output on clean unstable machine.
> root@desktop:~# git clone 
> git://anonscm.debian.org/pkg-multimedia/guitarix.git guitarix && cd guitarix
> Cloning into 'guitarix'...
> remote: Counting objects: 11042, done.
> remote: Compressing objects: 100% (4054/4054), done.
> remote: Total 11042 (delta 7947), reused 9746 (delta 6821)
> Receiving objects: 100% (11042/11042), 88.77 MiB | 4.60 MiB/s, done.
> Resolving deltas: 100% (7947/7947), done.
> root@desktop:~/guitarix# git fetch origin upstream:upstream 
> pristine-tar:pristine-tar
> From git://anonscm.debian.org/pkg-multimedia/guitarix
>  * [new branch]  upstream -> upstream
>  * [new branch]  pristine-tar -> pristine-tar
> root@desktop:~/guitarix# gbp import-orig --pristine-tar --uscan --verbose 
> --merge-mode=replace
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
> gbp:debug: ['git', 'show-ref', 'refs/heads/upstream']
> gbp:debug: ['git', 'status', '--porcelain']
> gbp:info: Launching uscan...
> uscan: Newest version of guitarix on remote site is 0.36.0, local version is 
> 0.35.6
> uscan:=> Newer package available from
>   http://qa.debian.org/watch/sf.php/guitarix/guitarix2-0.36.0.tar.xz
> gbp:info: Using uscan downloaded tarball ../guitarix_0.36.0.orig.tar.xz
> What is the upstream version? [0.36.0]
> gbp:debug: ['git', 'tag', '-l', 'upstream/0.36.0']
> gbp:debug: tar ['-C', '../tmp2_xslh4t', '-a', '-xf', 
> '../guitarix_0.36.0.orig.tar.xz'] []
> gbp:debug: Unpacked '../guitarix_0.36.0.orig.tar.xz' to 
> '../tmp2_xslh4t/guitarix-0.36.0'
> gbp:info: Importing '../guitarix_0.36.0.orig.tar.xz' to branch 'upstream'...
> gbp:info: Source package is guitarix
> gbp:info: Upstream version is 0.36.0
> gbp:debug: ['git', 'show-ref', 'refs/heads/upstream']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
> gbp:debug: ['git', 'add', '-f', '.']
> gbp:debug: ['git', 'write-tree']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
> gbp:debug: ['git', 'commit-tree', '3e9fc90df9d883cc4ee657c9466ea835336eeb94', 
> '-p', 'b71e4eb38c6b8d9a35d1e88d6ff72a095a7cb7b1']
> gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 0.36.0', 
> 'refs/heads/upstream', '87a3e934062d1ad81c6d9c557afe8b94ffc6a17d', 
> 'b71e4eb38c6b8d9a35d1e88d6ff72a095a7cb7b1']
> gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
> gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--']
> gbp:debug: ['git', 'mktree', '-z']
> gbp:debug: pristine-tar [] ['commit', '../guitarix_0.36.0.orig.tar.xz', 
> '3e9fc90df9d883cc4ee657c9466ea835336eeb94']
> gbp:debug: ['git', 'tag', '-m', 'Upstream version 0.36.0', 'upstream/0.36.0', 
> '87a3e934062d1ad81c6d9c557afe8b94ffc6a17d']
> gbp:debug: ['git', 'show-ref', 'refs/heads/master']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
> gbp:info: Replacing upstream source on 'master'
> gbp:debug: ['git', 'ls-tree', '-z', 'upstream/0.36.0^{tree}', '--']
> gbp:debug: ['git', 'ls-tree', '-z', 'master^{tree}', '--']
> gbp:debug: Using c4a8a211261fc53b556732b1b724f938060d0135 as debian/ tree

This all looks fine so I don't see a bug here. 

> gbp:debug: ['git', 'mktree', '-z']
> gbp:debug: ['git', 'commit-tree', 'e6fc6f222c9d84c3f8af093e743a220bd633d59f', 
> '-p', 'master^{commit}', '-p', 'upstream/0.36.0^{commit}']
> gbp:debug: ['git', 'update-ref', '-m', 'gbp: Updating master after import of 
> upstream/0.36.0', 'refs/heads/master', 
> '69f13f7d26624e430f433432f35f5cf4c59392fc']
> gbp:debug: ['git', 'reset', '--quiet', '--hard', 
> '69f13f7d26624e430f433432f35f5cf4c59392fc', '--']
> gbp:debug: ['git', 'symbolic-ref', 'HEAD']
> gbp:debug: ['git', 'show-ref', 'refs/heads/master']
> gbp:debug: rm ['-rf', '../tmp2_xslh4t'] []
> gbp:info: Successfully imported version 0.36.0 of 
> ../guitarix_0.36.0.orig.tar.xz
> root@desktop:~/guitarix# git status
> On branch master
> Your branch is ahead of 'origin/master' by 2 commits.
>   (use "git push" to publish your local commits)
> 
> Changes to be committed:
>   (use "git reset HEAD ..." to unstage)
> 
> new file:   debian/NEWS.Debian
> typechange: debian/changelog
> new file:   debian/clean
> modified:   debian/compat
> modified:   debian/control
> modified:   

Bug#881748: akregator: crash on startup

[Sandro Knauß]

Hey,

unfortunately there are more packages of KDE Application 17.08 waiting in NEW 
queue. So please check the status of packages in NEW queue before filing bugs. 
And you need debug symbols otherwise the backtrace is quite useless.

Best regards,

sandro

--

> Dear maintainer,
> akregator crash on startup with this log:
> 
> 
> $ akregator
> 
> terminate called after throwing an instance of 'std::logic_error'
>   what():  basic_string::_M_construct null not valid
> 
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = akregator path = /usr/bin pid = 6259
> KCrash: Arguments: /usr/bin/akregator
> KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from
> kdeinit
> sock_file=/run/user/0/kdeinit5__0
> [6259:6277:1114/193013.420227:FATAL:rand_util_posix.cc(54)] Check failed:
> success.
> #0 0x7f76b93d52fe 
> #1 0x7f76b93e7992 
> #2 0x7f76b940bc31 
> #3 0x7f76b9164dfa 
> #4 0x7f76b9165e23 
> #5 0x7f76b9169164 
> #6 0x7f76b916924c 
> #7 0x7f76b9f3da66 
> #8 0x7f76b9f38c5c 
> #9 0x7f76b9f3183c 
> #10 0x7f76b9b230ba 
> #11 0x7f76b9b25cbd 
> #12 0x7f76b8b21a9a 
> #13 0x7f76b916dea9 
> #14 0x7f76b9175670 
> #15 0x7f76b916c9ee 
> #16 0x7f76b8b1c0a3 
> #17 0x7f76b9b263b6 
> #18 0x7f76b9b299db 
> #19 0x7f76b9b2bf94 
> #20 0x7f76b9b23af5 
> #21 0x7f76b9b23c4e 
> #22 0x7f76b9b31095 
> #23 0x7f76b944c3e3 
> #24 0x7f76b93f02b0 
> #25 0x7f76b93f1908 
> #26 0x7f76b93f1c9b 
> #27 0x7f76b93f3372 
> #28 0x7f76b93ef658 
> #29 0x7f76b940c09b 
> #30 0x7f76b8ca92c8 
> #31 0x7f76b8ca987b 
> #32 0x7f76b9423e48 
> #33 0x7f76b941fe9b 
> #34 0x7f76c3cba494 start_thread
> #35 0x7f76c999dabf clone
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (550, 'unstable'), (520, 'testing'), (500,
> 'stable-updates'), (500, 'stable'), (100, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.14.0-custom (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1), LANGUAGE=it
> (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages akregator depends on:
> ii  kinit5.37.0-2
> ii  kio  5.37.0-2
> ii  libc62.24-17
> ii  libgcc1  1:7.2.0-14
> ii  libkf5codecs55.37.0-2
> ii  libkf5completion55.37.0-2
> ii  libkf5configcore55.37.0-2
> ii  libkf5configgui5 5.37.0-2
> ii  libkf5configwidgets5 5.37.0-2
> ii  libkf5coreaddons55.37.0-2
> ii  libkf5crash5 5.37.0-2
> ii  libkf5grantleetheme-plugins  17.08.0-1
> ii  libkf5grantleetheme5 17.08.0-1
> ii  libkf5i18n5  5.37.0-2
> ii  libkf5iconthemes55.37.0-2
> ii  libkf5jobwidgets55.37.0-2
> ii  libkf5kcmutils5  5.37.0-2
> ii  libkf5kiocore5   5.37.0-2
> ii  libkf5kiogui55.37.0-2
> ii  libkf5kiowidgets55.37.0-2
> ii  libkf5kontactinterface5  16.04.2-1
> ii  libkf5libkdepim-plugins  4:17.08.0-1
> ii  libkf5libkdepim5 4:17.08.0-1
> ii  libkf5messageviewer5 4:17.08.0-1
> ii  libkf5mimetreeparser54:17.08.0-1
> ii  libkf5notifications5 5.37.0-2
> ii  libkf5notifyconfig5  5.37.0-2
> ii  libkf5parts5 5.37.0-2
> ii  libkf5pimcommon-plugins  4:17.08.0-1
> ii  libkf5pimcommon5 4:17.08.0-1
> ii  libkf5pimtextedit5   17.08.0-1
> ii  libkf5service-bin5.37.0-2
> ii  libkf5service5   5.37.0-2
> ii  libkf5syndication5   16.04.2-1
> ii  libkf5textwidgets5   5.37.0-2
> ii  libkf5webengineviewer5   4:17.08.0-1
> ii  libkf5webkit55.37.0-2
> ii  libkf5widgetsaddons5 5.37.0-2
> ii  libkf5xmlgui55.37.0-2
> ii  libqt5core5a 5.9.2+dfsg-4
> ii  libqt5dbus5  5.9.2+dfsg-4
> ii  libqt5gui5   5.9.2+dfsg-4
> ii  libqt5network5   5.9.2+dfsg-4
> ii  libqt5printsupport5  5.9.2+dfsg-4
> ii  libqt5webenginewidgets5  5.9.2+dfsg-2
> ii  libqt5webkit55.212.0~alpha2-5
> ii  libqt5widgets5   5.9.2+dfsg-4
> ii  libqt5xml5   5.9.2+dfsg-4
> ii  libstdc++6   7.2.0-14
> 
> Thanks



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

Bug#881715: alsa-utils: High CPU usage on the default device

[Andoru]

>
> Just run htop while an alsa-process needs high cpu load. Copy the
> line which shows that from (h)top to this bug report. Or just file a
> screenshot to a puplic server somewhere.
>

Alright:
VLC playing a FLAC file on the default device:

>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 26183 andoru20   0 1191000  66424  46296 S  13.6  0.8   0:09.43 vlc
___

VLC playing the same file with "Analog Front Speakers" subdevice selected
under Audio -> Audio Device:

>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 26183 andoru20   0 1195412  69176  48644 S   1.3  0.9   0:11.35 vlc

___

As you can see, the CPU decreased from 13.6% to 1.3% when switching the
device.
___
To confirm that this is not an issue with the decoder in VLC here's VLC
playing an OGG Vorbis file on the default device:

>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 26183 andoru20   0 1263372  76228  48368 S  18.3  1.0   0:15.95 vlc
___

Same test as above, this time with an MP3 file:

>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 26183 andoru20   0 1416816  91532  60188 S  17.0  1.2   0:19.64 vlc

___

And foobar2000 playing FLAC OGG and MP3 files, respectively:


>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 2375 andoru20   0 1153140  62276  13140 S  21.3  0.8  29:36.91
foobar2000+

>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 2375 andoru20   0 1153140  62032  13140 S  24.6  0.8  29:16.33
foobar2000+

>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
> 2375 andoru20   0 1153140  72756  11808 S  22.6  0.9  29:03.99
foobar2000+


Let me know if you need any additional info.

Also, in the initial report, I forgot to mention that when I select "Analog
Front Speakers" subdevice in VLC, with some decoders (particularly APE) and
when the sample rate is below 44100Hz, I can hear some distortion
(crackling on high pitched sounds), so I'm guessing the high CPU usage is
maybe due to an inefficient resampler?

Bug#881291: libdbd-sqlite3-perl FTBFS with libsqlite3-dev 3.21.0-1

[Damyan Ivanov]

Control: tag -1 confirmed upstream

-=| Adrian Bunk, 09.11.2017 20:25:17 +0200 |=-
> Source: libdbd-sqlite3-perl
> Version: 1.54-2
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libdbd-sqlite3-perl.html
> 
> ...
> Test Summary Report
> ---
> t/virtual_table/rt_99748.t  (Wstat: 512 Tests: 24 
> Failed: 1)
>   Failed test:  24
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 52 tests but ran 24.
> Files=105, Tests=3555, 22 wallclock secs ( 0.81 usr  0.26 sys + 12.46 cusr  
> 1.88 csys = 15.41 CPU)
> Result: FAIL
> Failed 1/105 test programs. 1/3555 subtests failed.
> Makefile:1078: recipe for target 'test_dynamic' failed

This also falils in a current sbuild chroot:

#   Failed test 'no warnings'
#   at /usr/share/perl/5.26/Test/Builder.pm line 135.
# There were 2 warning(s)
#   Previous test 23 'SELECT rowid FROM vtb WHERE c = 'six''
#   Use of uninitialized value $op in pattern match (m//) at 
/<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 104.
#  at /<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 104.
#   
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x55efd272a948),
 ARRAY(0x55efd2757f10), ARRAY(0x55efd26e8c98)) called at 
/<>/blib/lib/DBD/SQLite.pm line 202
#   DBD::SQLite::db::prepare(DBI::db=HASH(0x55efd26dc460), "SELECT a FROM 
vtb WHERE b IS NULL ORDER BY a", undef) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 1690
#   DBD::_::db::selectcol_arrayref(DBI::db=HASH(0x55efd26dc460), "SELECT a 
FROMvtb WHERE b IS NULL ORDER BY a") called at t/virtual_table/rt_99748.t line 
80
#   main::test_table(DBI::db=HASH(0x55efd26dc508), "vtb") called at 
t/virtual_table/rt_99748.t line 57
#
# --
#   Previous test 23 'SELECT rowid FROM vtb WHERE c = 'six''
#   Use of uninitialized value $op in concatenation (.) or string at 
/<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 108.
#  at /<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 108.
#   
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x55efd272a948),
 ARRAY(0x55efd2757f10), ARRAY(0x55efd26e8c98)) called at 
/<>/blib/lib/DBD/SQLite.pm line 202
#   DBD::SQLite::db::prepare(DBI::db=HASH(0x55efd26dc460), "SELECT a FROM 
vtb WHERE b IS NULL ORDER BY a", undef) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 1690
#   DBD::_::db::selectcol_arrayref(DBI::db=HASH(0x55efd26dc460), "SELECT a 
FROM vtb WHERE b IS NULL ORDER BY a") called at t/virtual_table/rt_99748.t line 
80
#   main::test_table(DBI::db=HASH(0x55efd26dc508), "vtb") called at 
t/virtual_table/rt_99748.t line 57

Some observations:

 - no similar bug report exists upstream 
   (https://rt.cpan.org/Dist/Display.html?Queue=DBD-SQLite)
 - disabling the use_system_sqlite patch works around the failure
 - applying the patch from 
   https://rt.cpan.org/Ticket/Display.html?id=114138 for guaranteed 
   usage of system sqlite3.h does not help.
 - removing the upstream sqlite3.h from debian/rules also does not 
   help

So this seems like a genuine problem with newer sqlite. Upstream's 
sqlite3.h is 3.13.0, while Debian/unstable now has 3.21.0.

-- dam

Bug#881344: aptitude: Cannot initiate the connection to - while wget can grab the file

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi,

2017-11-10 16:07 Benoît-Pierre DEMAINE:

Subject: aptitude: Cannot initiate the connection to
Package: aptitude
Version: 0.6.11-1
Severity: important

Dear Maintainer,

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

Aptitude is unable to grab file while wget can do it
[...]
-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l


I am not sure what's wrong there, but the same code has been working
fine without changes for many years, at least 5 or so, and part of the
code doing the job of grabbing files is actually the libapt library.

Since this happens with Raspbian, there's a small chance that it's
broken in Raspbian but working in the equivalnent Debian one.  Would you
be able to try, or are the packages/ABIs completely incompatible?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#881765: yapf3: uninstallable in jessie-backports

[Andreas Beckmann]

Package: yapf3
Version: 0.15.1-1~bpo8+1
Severity: serious
Control: fixed -1 0.15.1-1

Hi,

the yapf backport was not built in a clean jessie environment and
therefore yapf3 picked up a dependency on python3.5 from stretch,
but jessie has only python3.4, rendering the yapf3 package
uninstallable in jessie-backports.


Andreas

Bug#881763: pynmea2: duplicate package with python-nmea2

[Adam Borowski]

Source: pynmea2
Version: 1.9.0-1
Severity: serious
Justification: Policy 4.13, 7.4


Hi!
I'm afraid that your package ships the very same code as python-nmea2 (other
than yours being outdated: while 1.9.0 sat in NEW, 1.12.0 was released
upstream and the other package is already updated).  Both are packagings of
https://github.com/Knio/pynmea2 .

src: pynmea2
* python3-pynmea2
src: python-nmea2
* python-nmea2
* python3-nmea2

This violates Policy 4.13 (sort of: this is no mere convenience copy but a
whole-sale duplicate), and also 7.4 because of undeclared file conflict:

dpkg: error processing archive 
/var/cache/apt/archives/python3-pynmea2_1.9.0-1_all.deb (--unpack):
 trying to overwrite '/usr/lib/python3/dist-packages/pynmea2/__init__.py', 
which is also in package python3-nmea2 1.12.0-1


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

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

Bug#881764: openjdk-7: several vulnerabilities

[Emilio Pozuelo Monfort]

Source: openjdk-7
Version: 7u151-2.6.11-1
Severity: serious

Hi,

The last round of vulnerabilities for OpenJDK hasn't been fixed in openjdk-7
yet. It'd be good to get an updated package in experimental so it can be
pushed to jessie and wheezy.

Thanks,
Emilio

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

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

Bug#881627: Congratulations AmazonShopper! fm

[Sundra Johnson]

sunshine45...@gmail.com

On Nov 14, 2017 2:08 PM, "AmazonReward Alert" <
debian.a...@manchmal.in-ulm.de> wrote:

> Message for sundra
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Source: ruby-http-parser.rb Version: 0.6.0-3+b3 Severity: serious Tags:
> upstream Dear Maintainer, your package build-depends on http-parser, and a
> new version of that one has been around for a while. Even before eventually
> uploading last night I already saw a problem in the test suite of your
> package. However, due to a fault on my side, the new http-parser went to
> unstable instead of experimental. So this increases the pressure for your
> package, sorry about that. With http-parser 2.7.1, one test fails: 1)
> HTTP::Parser should parse request: line folding in header value
> Failure/Error: expect(@headers).to eq(test) expected:
> {"Line1"=>"abcdefghijklmno qrs", "Line2"=>"line2\t"} got:
> {"Line1"=>"abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2"=>"line2\t"} (compared
> using ==) Diff: @@ -1,3 +1,3 @@ -"Line1" => "abcdefghijklmno qrs", +"Line1"
> => "abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2" => "line2\t", #
> ./spec/parser_spec.rb:347:in `block (4 levels) in ' If I understand
> correctly, this is taken from spec/support/requests.json line 445 and 457f.
> While doubtlessly http-parser changed the behaviour, I'm not sure yet
> whether this wasn't rather about fixing bugs - bugs the test in
> ruby-http-parser.rb relied upon. However, HTTP header line folding is
> complicated and actually also deprecated in RFC 7230. Reading that one and
> also the older description in RFC 2616 I guess there a too many freedoms to
> expect a certain result. Also it seems http-parser 2.7.1 does unfolding in
> a ... surprising manner. Now, quite frankly, my main interest is a sound
> solution. Otherwise, I'm not keen on legal discussions, especially when
> it's about a deprecated feature like this one. It's my job to sort these
> things out with http-parser upstream but since I'm not sure how long this
> will take: Would you mind disabling or relaxing the test on your side for
> the time being? You might as well upgrade the test to the one in
> http-parser/test.c¹ which is where obviously it was taken from in the first
> place - but I'd expect this to change again soon. Sorry for the mess, and
> kind regards, Christoph ¹ 
> https://github.com/nodejs/http-parser/blob/master/test.c
> (line 614)

Bug#881762: ITA: gtkterm/0.99.7~rc1-1

[Willem van den Akker]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

* Package name: gtkterm
  Version : 0.99.7~rc1-1
  Upstream Author : [fill in name and email of upstream]
* URL : [fill in URL of upstreams web site]
* License : [fill in]
  Section : comm

It builds those binary packages:

  gtkterm- simple GTK+ serial port terminal

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/g/gtkterm/gtkte
rm_0.99.7~rc1-1.dsc

  Changes since the last upload:

  * New maintainer upload (Closes: #857476).
  * debian/control
- description updated conform Developer's Reference.
  * Bump standards version to 4.1.1.1.

Remarks:
Homepage, watch file are not known yet. gtkterm has many, often
inactive, respositories. I am in contact with a few owners to take
over the most recent respository. After that a new release and
homepage/watch file are filled in.
Also one file serie.c is modified other then the 'quilt-way'. This will
be corrected after a new version upload.


  Regards,
   W. van den Akker

Bug#881761: signon-plugin-oauth2 FTCBFS: does not pass cross tools to qmake and other issues

[Helmut Grohne]

Source: signon-plugin-oauth2
Version: 0.22-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

signon-plugin-oauth2 fails to cross build from source for multiple
reasons:
 * It does not pass cross tools to qmake. This task can be easily
   deferred to dh_auto_configure these days, but it doesn't fully work,
   so in the best case dh_auto_build will fail until debhelper is fixed.
 * It uses uname -m to discover the host cpu, but that returns the build
   cpu of course.
 * It uses plain pkg-config, which is the build architecture pkg-config
   while the host architecture one was expected.

After fixing all of the above, the package fails with the expected
failure in dh_auto_build to be fixed in debhelper. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru signon-plugin-oauth2-0.22/debian/changelog 
signon-plugin-oauth2-0.22/debian/changelog
--- signon-plugin-oauth2-0.22/debian/changelog  2015-11-07 07:34:11.0 
+0100
+++ signon-plugin-oauth2-0.22/debian/changelog  2017-11-14 21:44:59.0 
+0100
@@ -1,3 +1,13 @@
+signon-plugin-oauth2 (0.22-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix some cross build issues: (closes: #-1)
++ Let dh_auto_configure pass cross tools to qmake.
++ Do not use uname -m to discover the host cpu.
++ Allow substituting pkg-config.
+
+ -- Helmut Grohne   Tue, 14 Nov 2017 21:44:59 +0100
+
 signon-plugin-oauth2 (0.22-1) unstable; urgency=low
 
   * Initial release
diff --minimal -Nru signon-plugin-oauth2-0.22/debian/patches/cross.patch 
signon-plugin-oauth2-0.22/debian/patches/cross.patch
--- signon-plugin-oauth2-0.22/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ signon-plugin-oauth2-0.22/debian/patches/cross.patch2017-11-14 
21:44:59.0 +0100
@@ -0,0 +1,33 @@
+Index: signon-plugin-oauth2-0.22/common-project-config.pri
+===
+--- signon-plugin-oauth2-0.22.orig/common-project-config.pri
 signon-plugin-oauth2-0.22/common-project-config.pri
+@@ -47,14 +47,7 @@
+ message(" install prefix set to `$${INSTALL_PREFIX}'")
+ }
+ 
+-# Setup the library installation directory
+-exists( meego-release ) {
+-ARCH = $$system(tail -n1 meego-release)
+-} else {
+-ARCH = $$system(uname -m)
+-}
+-
+-contains( ARCH, x86_64 ) {
++contains( QMAKE_HOST.arch, x86_64 ) {
+ INSTALL_LIBDIR = $${INSTALL_PREFIX}/lib64
+ } else {
+ INSTALL_LIBDIR = $${INSTALL_PREFIX}/lib
+@@ -73,7 +66,11 @@
+ }
+ 
+ # Default directory for signond extensions
+-_PLUGINS = $$system(pkg-config --variable=plugindir signon-plugins)
++pkgConfig = $${PKG_CONFIG}
++isEmpty( pkgConfig ) {
++pkgConfig = "pkg-config"
++}
++_PLUGINS = $$system($$pkgConfig --variable=plugindir signon-plugins)
+ isEmpty(_PLUGINS) {
+ error("plugin directory not available through pkg-config")
+ } else {
diff --minimal -Nru signon-plugin-oauth2-0.22/debian/patches/series 
signon-plugin-oauth2-0.22/debian/patches/series
--- signon-plugin-oauth2-0.22/debian/patches/series 2015-10-15 
19:42:14.0 +0200
+++ signon-plugin-oauth2-0.22/debian/patches/series 2017-11-14 
21:44:59.0 +0100
@@ -1,3 +1,4 @@
 dont-install-examples.patch
 hardening.patch
 unused-variable.patch
+cross.patch
diff --minimal -Nru signon-plugin-oauth2-0.22/debian/rules 
signon-plugin-oauth2-0.22/debian/rules
--- signon-plugin-oauth2-0.22/debian/rules  2015-11-07 19:07:43.0 
+0100
+++ signon-plugin-oauth2-0.22/debian/rules  2017-11-14 21:42:26.0 
+0100
@@ -8,7 +8,7 @@
dh $@ --buildsystem qmake
 
 override_dh_auto_configure:
-   qmake PREFIX=/usr LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
+   dh_auto_configure -- PREFIX=/usr LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
 
 override_dh_auto_clean:
if [ -f Makefile ] ; then make distclean; fi

Bug#881760: nmu: seer_1.1.2-3~bpo8+1

[Andreas Beckmann]

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

nmu seer_1.1.2-3~bpo8+1 . ANY . jessie-backports . -m "Rebuild against 
libarmadillo7"

libarmadillo6 is not (any more) available in jessie-backports, rendering
the current seer packages in jessie-backports uninstallable.

Rebuild tested in a pbuilder jessie+backports amd64 environment.


Andreas

Bug#881627: Congratulations AmazonShopper! lxmrr2

[Edwin Carter]

nice con attempt, I will be reporting you to officials

On Mon, Nov 13, 2017 at 11:30 AM, AmazonReward Alert <
debian.a...@manchmal.in-ulm.de> wrote:

> Message for Ed
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Source: ruby-http-parser.rb Version: 0.6.0-3+b3 Severity: serious Tags:
> upstream Dear Maintainer, your package build-depends on http-parser, and a
> new version of that one has been around for a while. Even before eventually
> uploading last night I already saw a problem in the test suite of your
> package. However, due to a fault on my side, the new http-parser went to
> unstable instead of experimental. So this increases the pressure for your
> package, sorry about that. With http-parser 2.7.1, one test fails: 1)
> HTTP::Parser should parse request: line folding in header value
> Failure/Error: expect(@headers).to eq(test) expected:
> {"Line1"=>"abcdefghijklmno qrs", "Line2"=>"line2\t"} got:
> {"Line1"=>"abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2"=>"line2\t"} (compared
> using ==) Diff: @@ -1,3 +1,3 @@ -"Line1" => "abcdefghijklmno qrs", +"Line1"
> => "abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2" => "line2\t", #
> ./spec/parser_spec.rb:347:in `block (4 levels) in ' If I understand
> correctly, this is taken from spec/support/requests.json line 445 and 457f.
> While doubtlessly http-parser changed the behaviour, I'm not sure yet
> whether this wasn't rather about fixing bugs - bugs the test in
> ruby-http-parser.rb relied upon. However, HTTP header line folding is
> complicated and actually also deprecated in RFC 7230. Reading that one and
> also the older description in RFC 2616 I guess there a too many freedoms to
> expect a certain result. Also it seems http-parser 2.7.1 does unfolding in
> a ... surprising manner. Now, quite frankly, my main interest is a sound
> solution. Otherwise, I'm not keen on legal discussions, especially when
> it's about a deprecated feature like this one. It's my job to sort these
> things out with http-parser upstream but since I'm not sure how long this
> will take: Would you mind disabling or relaxing the test on your side for
> the time being? You might as well upgrade the test to the one in
> http-parser/test.c¹ which is where obviously it was taken from in the first
> place - but I'd expect this to change again soon. Sorry for the mess, and
> kind regards, Christoph ¹ 
> https://github.com/nodejs/http-parser/blob/master/test.c
> (line 614)

Bug#881753: local-apt-repository: breaks apt operation if removed

[Felipe Sateler]

Hi Joachim,

On Tue, Nov 14, 2017 at 4:35 PM, Joachim Breitner  wrote:
>
> Hi Felipe,
>
> this just came in. Since you last worked on this package, would you be
> interesting in fixing this bug?
>

Sorry, I'm currently lacking time to do this.

-- 

Saludos,
Felipe Sateler

Bug#881715: alsa-utils: High CPU usage on the default device

[Elimar Riesebieter]

* Andoru  [2017-11-14 22:03 +0200]:

> > What makes you think an alsa process eats high cpu usage?
> 
> You skipped a paragraph from my report:
> 
> > It's just easy to tell if an app/ALSA uses too much CPU if you just play
> some audio files
> > and you don't have anything else that might need the extra CPU power,
> > like rendering the video stream or render the graphics. I can fix the
> > high CPU usage in VLC if I switch the audio sub-device from the Default
> > to a specific one (in my case: Analog Front Speakers).
> 
> ///
> 
> > Can you post the tespective line with column
> > headers aou of htop or top please?
> 
> Sorry... could you elaborate what you mean? What parameters should I start
> htop to get he info you need?

Just run htop while an alsa-process needs high cpu load. Copy the
line which shows that from (h)top to this bug report. Or just file a
screenshot to a puplic server somewhere.

Elimar
-- 
.~.
/V\   L   I   N   U   X
   /( )\ >Phear the Penguin<
   ^^-^^


signature.asc
Description: PGP signature

Bug#881733: totem: Totem unable to play anything with any user but root

[jEsuSdA 8)]

El 14/11/17 a las 20:12, Michael Biebl escribió:

I suspect it is
~/.cache/gstreamer-1.0/registry.x86_64.bin which got messed up.
That's why I asked you to test with a fresh user account.


I think so.

I think this file was caused all my headhaches!



I vaguely remember a few bug reports in that regard.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715529 is a rather old
one but I think we had similar user reports just recently.




What Jeremy said is true as well: Please don't run graphical
applications as root!


Of course!
I test it to discard any permission or group issue. I'll never do again. ;)

Thanks a lot!!!

Bug#881757: collectd: snmp plugin: double free or heap corruption

[Salvatore Bonaccorso]

Control: retitle -1 collectd: CVE-2017-16820: snmp plugin: double free or heap 
corruption

Hi Philippe

Thanks for providing the details as well in the BTS.

FTR, this issue has been assigned CVE-2017-16820.

Regards,
Salvatore

Bug#881759: ITP: libbarcode-datamatrix-png-perl -- Generator of PNG Data Matrix barcodes

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libbarcode-datamatrix-png-perl
  Version : 0.04
  Upstream Author : Kasem Omary 
* URL : https://metacpan.org/pod/Barcode::DataMatrix::PNG
* License : Artistic or GPL-1
  Programming Lang: Perl
  Description : Generator of PNG Data Matrix barcodes

Barcode::DataMatrix::PNG extends Barcode::DataMatrix to create graphical
representations of data matrix barcodes

Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA

[Don Dutile]

On 11/14/2017 02:08 PM, Jason Gunthorpe wrote:

However, it would of course be better to teach udma_barrier.h about
these architectures.


The issue is that some architectures just can't do cache coherent DMA
on any implementation. eg m68k

There is no correct udma_barrier.h at all in those cases.

We need to teach debian to follow cmake and exclude the missing
installables in these cases..

Or do not build at all on these arch's..

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Jason:
Why am I being cc'd on this debian bug?
I also received a notice about a bug fix in debian, and I had zip to do with it.

Is my name tagged in Debian wrt rdma for some reason? by someone? other?

-dd

Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA

[Jason Gunthorpe]

On Tue, Nov 14, 2017 at 03:41:13PM -0500, Don Dutile wrote:
> On 11/14/2017 02:08 PM, Jason Gunthorpe wrote:
> >>However, it would of course be better to teach udma_barrier.h about
> >>these architectures.
> >
> >The issue is that some architectures just can't do cache coherent DMA
> >on any implementation. eg m68k
> >
> >There is no correct udma_barrier.h at all in those cases.
> >
> >We need to teach debian to follow cmake and exclude the missing
> >installables in these cases..
> >
> >Or do not build at all on these arch's..
> >
> >Jason
> Jason:
> Why am I being cc'd on this debian bug?

You were not cc'd...

The linux-rdma mailing list has been subscribed to the debian bug feed
for rdma-core :\

Unclear if this is a good idea or not, but for now I think being
supportive of Benjamin is a good call as he has done so much work to
get the packages accepted.

You can probably filter and discard messages with these two headers
together:

List-ID: 
X-Debian-PR-Package: src:rdma-core

Jason

Bug#881757: Details

[Philippe Duke]

When NET-SNMP's snmp_sess_synch_response(sess,*req,**res) receives response 
(and it is correct from snmp_synch_input callback) it ALWAYS free()'s second 
parameter - req.

Looking for (net-snmp-5.7.3...)/snmplib/snmp_api.c:5424 - packet processing
routine.

In case of bad SNMP table response snmp_sess_synch_response returns success 
code, but logic breaks down. It may happen in case of broken SNMP agent 
response. Collectd tries to put into the table and fails on
collectd-5.7.1/src/snmp.c:1423 and breaks out down from (result == 0) while 
loop.

Usually when collectd successfully finished probing all OID from subtree
it creates a fresh new req before using snmp_pdu_create() (snmp.c:1341)
so it safely free()'s it (snmp.c:1496). But in the situation when such
error happens it just drops down with already free()'d req structure.
Double-free happens and heap corrupts. Taking into the account that collectd 
usually runs as root, taking control over heap structures may lead to bad 
consequences for the monitoring server.

ASAN OUTPUT:

=
==16386==ERROR: AddressSanitizer: heap-use-after-free on address
0x61217d40 at pc 0x0044866c bp 0x7fffedcc9e20 sp 0x7fffedcc95d0
WRITE of size 272 at 0x61217d40 thread T7
    #0 0x44866b in __interceptor_memset.part.43
(/usr/sbin/collectd+0x44866b)
    #1 0x7219c482 in snmp_free_pdu snmplib/snmp_api.c:5153
    #2 0x72459195 in csnmp_read_table src/snmp.c:1496:5
    #3 0x72455e2e in csnmp_read_host src/snmp.c:1648:16
    #4 0x5111a6 in plugin_read_thread src/daemon/plugin.c:537:16
    #5 0x778bf493 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)
    #6 0x76bceafe in clone (/lib/x86_64-linux-gnu/libc.so.6+0xe8afe)

0x61217d40 is located 0 bytes inside of 272-byte region
[0x61217d40,0x61217e50)
freed by thread T7 here:
    #0 0x4be120 in __interceptor_cfree.localalias.0
(/usr/sbin/collectd+0x4be120)
    #1 0x7219c48e in snmp_free_pdu snmplib/snmp_api.c:5154
    #2 0x7219d087 in _sess_process_packet snmplib/snmp_api.c:5424
    #3 0x7219e7bc in _sess_read snmplib/snmp_api.c:5876
    #4 0x7219e8b9 in snmp_sess_read2 snmplib/snmp_api.c:5908
    #5 0x7219e865 in snmp_sess_read snmplib/snmp_api.c:5896
    #6 0x7216adac in snmp_sess_synch_response snmplib/snmp_client.c:1157
    #7 0x72457e20 in csnmp_read_table src/snmp.c:1365:14
    #8 0x72455e2e in csnmp_read_host src/snmp.c:1648:16
    #9 0x5111a6 in plugin_read_thread src/daemon/plugin.c:537:16
    #10 0x778bf493 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)

previously allocated by thread T7 here:
    #0 0x4be490 in calloc (/usr/sbin/collectd+0x4be490)
    #1 0x72169239 in snmp_pdu_create snmplib/snmp_client.c:135
    #2 0x72457bff in csnmp_read_table src/snmp.c:1341:11
    #3 0x72455e2e in csnmp_read_host src/snmp.c:1648:16
    #4 0x5111a6 in plugin_read_thread src/daemon/plugin.c:537:16
    #5 0x778bf493 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)

Thread T7 created by T0 here:
    #0 0x432b19 in __interceptor_pthread_create
(/usr/sbin/collectd+0x432b19)
    #1 0x5088f3 in start_read_threads src/daemon/plugin.c:645:18
    #2 0x5079d7 in plugin_init_all src/daemon/plugin.c:1658:7
    #3 0x4f181d in do_init src/daemon/collectd.c:297:10
    #4 0x4eff1f in main src/daemon/collectd.c:655:7
    #5 0x76b062b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: heap-use-after-free
(/usr/sbin/collectd+0x44866b) in __interceptor_memset.part.43
Shadow bytes around the buggy address:
  0x0c247fffaf50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c247fffaf60: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x0c247fffaf70: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c247fffaf80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c247fffaf90: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
=>0x0c247fffafa0: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd
  0x0c247fffafb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c247fffafc0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x0c247fffafd0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c247fffafe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c247fffaff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:    f7
  Container overflow:  fc
  Array cookie:    ac
  Intra object redzone:    bb
  ASan 

Bug#877442: marked as pending

[Moritz Muehlenhoff]

On Wed, Nov 01, 2017 at 10:28:22PM +, Dylan Aïssi  wrote:
> 
> ---
> commit 25174e187c6211a7e05c44c0fb3eb17556484e61
> Author: Dylan Aïssi 
> Date:   Wed Nov 1 22:47:00 2017 +0100
> 
> Add an upstream patch to fix CVE-2017-14731 (Closes: #877442)
> 
> diff --git a/debian/changelog b/debian/changelog
> index 9fb1aa9..103b223 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +libofx (1:0.9.11-5) unstable; urgency=high
> +
> +  * Add an upstream patch to fix CVE-2017-14731 (Closes: #877442).
> +
> + -- Dylan Aïssi   Wed, 01 Nov 2017 22:44:52 +0100

Hi Dylan,
this vulnerability doesn't warrant a DSA.

There's still the possibility to fix this via a stable point update
[1], so I was wondering whether anything of that sort is planned by
you.

Cheers,
Moritz

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch05.html#upload-stable 

Bug#881758: ITP: libbarcode-datamatrix-perl -- Data matrix generator

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libbarcode-datamatrix-perl
  Version : 0.09
  Upstream Author : Mark A. Stratman 
* URL : https://metacpan.org/release/Barcode-DataMatrix
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Data matrix generator

Barcode::DataMatrix generates data for Data Matrix barcodes. It is primarily
useful as a data source for barcode modules that do rendering such as
HTML::Barcode::DataMatrix or Barcode::DataMatrix::PNG.

Bug#881715: alsa-utils: High CPU usage on the default device

[Andoru]

> What makes you think an alsa process eats high cpu usage?

You skipped a paragraph from my report:

> It's just easy to tell if an app/ALSA uses too much CPU if you just play
some audio files
> and you don't have anything else that might need the extra CPU power,
> like rendering the video stream or render the graphics. I can fix the
> high CPU usage in VLC if I switch the audio sub-device from the Default
> to a specific one (in my case: Analog Front Speakers).

///

> Can you post the tespective line with column
> headers aou of htop or top please?

Sorry... could you elaborate what you mean? What parameters should I start
htop to get he info you need?

Bug#881757: collectd: snmp plugin: double free or heap corruption

[Salvatore Bonaccorso]

Source: collectd
Version: 5.7.2-2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/collectd/collectd/issues/2291
Control: found -1 5.7.1-1.1 

Hi

There is a a double free or heap corruption issue in collectd, as
reported upstream in https://github.com/collectd/collectd/issues/2291
.

Details in the upstrema bugreport.

Regards,
Salvatore

Bug#876934: openorienteering-mapper FTBFS: test failures

[Kai Pastor, DG0YT]

Am 13.11.2017 um 20:15 schrieb Adrian Bunk:

I didn't find a recommendation how to solve the issue. I hope a custom macro
is okay.

Based on the discussion in #876901 [1] it is still unclear how this
should be resolved in general.


One more remark:

Replacing __FILE__ with an individual macro makes it much harder to 
detect embedded build paths in source code review. Proliferation of 
individual macros could become worse than __FILE__ IMO.



I see the discussion on debian-qt-kde. The proposal in 
https://lists.debian.org/debian-qt-kde/2017/11/msg00110.html:


> If all the test files reside underneath the same directory, like 
tests/, you could:


> 4. export 
BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests".


will probably worked for this package (old versions). But such 
information needs to be in documentation, at the time such a change is 
introduced. In addition, there needs to be much better correlation of 
changes in the environment and changes in reproducibility build success. 
It seems there are two variations tested, but __FILE__ vs. not __FILE__ 
is not included.


I remember that I spent time studying changelogs of gcc and Qt packages 
in Debian when this bug was opened, but I was unaware of the 
particularities of the gcc in reproducible builds. The rbuild log that I 
find online does not contain the exact c++ compiler package name and 
version. What an irony, the reproducible-builds logs do not provide 
enough information to consider them reproducible. Even Debian package 
build logs on build.opensuse.org offer more details. We could have 
solved this much earlier, and without wasting CPU cycles and developer time.


Regards,
Kai.

Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM

[Lev Lamberov]

Package: swi-prolog
Version: 7.4.2+dfsg-2
Severity: serious
Justification: fails to build from source

The mips build of swi-prolog failed:

Running scripts from core ...
E: Build killed with signal TERM after 360 minutes of inactivity

The bug can be reproduced on mips porterbox. Hitting Ctrl+X gives:

Interrupted test cgc:shift_cgc at 
/home/dogsleg/swi-prolog-7.6.1+dfsg/src/Tests/core/test_cgc.pl:102

The most strange thing is that 7.6.1-1 built successfully on mips. The
only difference between 7.6.1-1 and 7.6.1-2 is that java tests (only
tests) are disabled now (via debian/rules). Note that the 7.6.1-2
version builds successfully on mipsel and mips64el (little-endian), but
fails on mips (big-endian).

The similar problem occures on powerpc [1][2], which also works in
big-endian mode:

Running scripts from core Makefile:418: 
recipe for target 'check' failed
make[2]: *** [check] Terminated

[1] 
https://buildd.debian.org/status/fetch.php?pkg=swi-prolog=powerpc=7.6.1%2Bdfsg-2=1510047696=0

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869701


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

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

Versions of packages swi-prolog depends on:
ii  swi-prolog-nox  7.4.2+dfsg-2
ii  swi-prolog-x7.4.2+dfsg-2

swi-prolog recommends no packages.

swi-prolog suggests no packages.

-- no debconf information

Bug#881755: baloo: Baloo can take up all system resources when indexing

[Leos Pohl]

Package: baloo
Version: 4:5.28.0-2
Severity: important

Dear Maintainer,

When baloo indexes files, it takes up all system resources (CPU, memory, disk) 
and the computer becomes unusable until it finishes which can take from several 
minutes to almost half an hour. 
This is erroneous behavious as it equals crashing the system. There need to be 
implemented limitations that baloo has to respect to provide a usable indexing. 
Also the indexing runs not only when the computer
is idle but also under load. When I get the console running and ask balooctl 
status, I after almost a minute:
Baloo File Indexer is running
Indexer state: Idle
Indexed 34283 / 34283 files
Current size of index is 15.80 GiB


How can it be idle when even the terminal is unusable...

Please maintainer, is there any fix that could be applied to stable debian that 
resolves this issue?

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 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)

Versions of packages baloo depends on:
ii  baloo-kf5  5.28.0-2

baloo recommends no packages.

baloo suggests no packages.

-- no debconf information

Bug#864953: closed by Emilio Pozuelo Monfort <po...@debian.org> (Bug#864953: fixed in shared-mime-info 1.9-1)

[Andreas Beckmann]

On 09/28/2017 12:57 AM, Debian Bug Tracking System wrote:
> #864953: dpkg: trigger problems with shared-mime-info while upgrading 
> gnome-screensaver:i386 from jessie to stretch

Do you plan to fix this in stretch, too? If the package reaches
stretch-proposed-updates with some time left before the point release I
should be able to fully rerun all stretch and jessie->stretch piuparts
tests that involve shared-mime-info using the stretch-pu packages.


Andreas

Bug#881753: local-apt-repository: breaks apt operation if removed

[Joachim Breitner]

Hi Felipe,

this just came in. Since you last worked on this package, would you be
interesting in fixing this bug?

Thanks,
Joachim

Am Dienstag, den 14.11.2017, 20:30 +0100 schrieb Andreas Beckmann:
> Package: local-apt-repository
> Version: 0.4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package can cause problems.
> 
> If local-apt-repository is removed (but not purged) from stretch,
> /etc/apt/sources.list.d/local-apt-repository.list is left behind.
> 
> Subsequent 'apt-get update' will fail since the repository is no longer
> available:
> 
> 4m5.4s ERROR: Command failed (status=100): ['chroot', 
> '/tmp/piupartss/tmpeMVqg3', 'apt-get', 'update']
>   Get:1 file:/var/lib/local-apt-repository ./ InRelease
>   Ign:1 file:/var/lib/local-apt-repository ./ InRelease
>   Get:2 file:/var/lib/local-apt-repository ./ Release
>   Ign:2 file:/var/lib/local-apt-repository ./ Release
>   Get:3 file:/var/lib/local-apt-repository ./ Sources
>   Ign:3 file:/var/lib/local-apt-repository ./ Sources
>   Get:4 file:/var/lib/local-apt-repository ./ Packages
>   Ign:4 file:/var/lib/local-apt-repository ./ Packages
>   Get:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Get:3 file:/var/lib/local-apt-repository ./ Sources
>   Ign:3 file:/var/lib/local-apt-repository ./ Sources
>   Get:4 file:/var/lib/local-apt-repository ./ Packages
>   Ign:4 file:/var/lib/local-apt-repository ./ Packages
>   Get:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Get:3 file:/var/lib/local-apt-repository ./ Sources
>   Ign:3 file:/var/lib/local-apt-repository ./ Sources
>   Get:4 file:/var/lib/local-apt-repository ./ Packages
>   Ign:4 file:/var/lib/local-apt-repository ./ Packages
>   Get:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Get:3 file:/var/lib/local-apt-repository ./ Sources
>   Ign:3 file:/var/lib/local-apt-repository ./ Sources
>   Get:4 file:/var/lib/local-apt-repository ./ Packages
>   Ign:4 file:/var/lib/local-apt-repository ./ Packages
>   Get:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Get:3 file:/var/lib/local-apt-repository ./ Sources
>   Ign:3 file:/var/lib/local-apt-repository ./ Sources
>   Get:4 file:/var/lib/local-apt-repository ./ Packages
>   Ign:4 file:/var/lib/local-apt-repository ./ Packages
>   Get:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
>   Get:3 file:/var/lib/local-apt-repository ./ Sources
>   Err:3 file:/var/lib/local-apt-repository ./ Sources
> File not found - /var/lib/local-apt-repository/./Sources (2: No such file 
> or directory)
>   Get:4 file:/var/lib/local-apt-repository ./ Packages
>   Ign:4 file:/var/lib/local-apt-repository ./ Packages
>   Get:6 http://ftp.de.debian.org/debian buster InRelease [136 kB]
>   Get:7 http://ftp.de.debian.org/debian buster/main amd64 Packages [7258 kB]
>   Get:8 http://ftp.de.debian.org/debian buster/main Translation-en [5553 kB]
>   Fetched 12.9 MB in 18s (696 kB/s)
>   Reading package lists...
>   E: Failed to fetch file:/var/lib/local-apt-repository/./Sources  File not 
> found - /var/lib/local-apt-repository/./Sources (2: No such file or directory)
>   E: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> 
> 
> Andreas
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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

Bug#881754: amanda-server: Amanda does not lock while dumping - multiple sessions possible

[Kamil Jonca]

Package: amanda-server
Version: 1:3.5-2
Severity: grave
Tags: upstream
Justification: causes non-serious data loss

(I am not sure if it is upstream)

I used to make backup two phases. 
1. amdump to holding space, and then 
2. amflush to target disk (vtapes)
I noticed that I can make amflush during amdump - it should not be possible as 
can flush incomplete file. 
Moreover I can run multiple amflush processes - I supsect, that they destroy 
backup files during flush .
KJ


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

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

Versions of packages amanda-server depends on:
ii  amanda-common  1:3.5-2
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
ii  libc6  2.24-17
ii  libcurl3   7.56.1-1
ii  libglib2.0-0   2.54.2-1
ii  libjson-perl   2.94-1
ii  libssl1.1  1.1.0g-2
ii  perl   5.26.1-2

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
ii  amanda-client 1:3.5-2
ii  cpio  2.11+dfsg-6
ii  gnuplot   5.2.2+dfsg1-2
ii  gnuplot-qt [gnuplot]  5.2.2+dfsg1-2

-- no debconf information

Bug#878853: please provide python3-eyed3

[Alexandre Detiste]

Hi,

Half the world done, thanks already.

> Depends: python-eyed3 (= 0.8.3-2), python3, python3-magic, python3-six, 
> python3:any (>= 3.3.2-2~)

The Python3 modules depends on the Python2 one, which is weird.
I know it may comes from dh_pytho, but I don't see how to fix it immediatly.

Greets.

Bug#881626: busybox: enable telnetd

[Lennart Sorensen]

On Tue, Nov 14, 2017 at 06:59:41PM +, Holger Levsen wrote:
> you are aware that this would only cause (these) people to switch away
> from Debian, but not from telnet?

I honestly believe they just haven't tried.  As long as you indulge them,
they will keep training new people with bad habits.  It won't go away
until you make it go away.  Sometimes you really do have to tell
people no.

> also, I miss your removal requests for the telnetd and ftpd and
> (countless) other packages.
> 
> to the original poster: what's wrong with installing telnetd? its only
> 103kb in size...

Well at least in a separate package you don't accidentally get it just
by installing busybox.

-- 
Len Sorensen

Bug#881753: local-apt-repository: breaks apt operation if removed

[Andreas Beckmann]

Package: local-apt-repository
Version: 0.4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package can cause problems.

If local-apt-repository is removed (but not purged) from stretch,
/etc/apt/sources.list.d/local-apt-repository.list is left behind.

Subsequent 'apt-get update' will fail since the repository is no longer
available:

4m5.4s ERROR: Command failed (status=100): ['chroot', 
'/tmp/piupartss/tmpeMVqg3', 'apt-get', 'update']
  Get:1 file:/var/lib/local-apt-repository ./ InRelease
  Ign:1 file:/var/lib/local-apt-repository ./ InRelease
  Get:2 file:/var/lib/local-apt-repository ./ Release
  Ign:2 file:/var/lib/local-apt-repository ./ Release
  Get:3 file:/var/lib/local-apt-repository ./ Sources
  Ign:3 file:/var/lib/local-apt-repository ./ Sources
  Get:4 file:/var/lib/local-apt-repository ./ Packages
  Ign:4 file:/var/lib/local-apt-repository ./ Packages
  Get:5 file:/var/lib/local-apt-repository ./ Translation-en
  Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
  Get:3 file:/var/lib/local-apt-repository ./ Sources
  Ign:3 file:/var/lib/local-apt-repository ./ Sources
  Get:4 file:/var/lib/local-apt-repository ./ Packages
  Ign:4 file:/var/lib/local-apt-repository ./ Packages
  Get:5 file:/var/lib/local-apt-repository ./ Translation-en
  Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
  Get:3 file:/var/lib/local-apt-repository ./ Sources
  Ign:3 file:/var/lib/local-apt-repository ./ Sources
  Get:4 file:/var/lib/local-apt-repository ./ Packages
  Ign:4 file:/var/lib/local-apt-repository ./ Packages
  Get:5 file:/var/lib/local-apt-repository ./ Translation-en
  Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
  Get:3 file:/var/lib/local-apt-repository ./ Sources
  Ign:3 file:/var/lib/local-apt-repository ./ Sources
  Get:4 file:/var/lib/local-apt-repository ./ Packages
  Ign:4 file:/var/lib/local-apt-repository ./ Packages
  Get:5 file:/var/lib/local-apt-repository ./ Translation-en
  Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
  Get:3 file:/var/lib/local-apt-repository ./ Sources
  Ign:3 file:/var/lib/local-apt-repository ./ Sources
  Get:4 file:/var/lib/local-apt-repository ./ Packages
  Ign:4 file:/var/lib/local-apt-repository ./ Packages
  Get:5 file:/var/lib/local-apt-repository ./ Translation-en
  Ign:5 file:/var/lib/local-apt-repository ./ Translation-en
  Get:3 file:/var/lib/local-apt-repository ./ Sources
  Err:3 file:/var/lib/local-apt-repository ./ Sources
File not found - /var/lib/local-apt-repository/./Sources (2: No such file 
or directory)
  Get:4 file:/var/lib/local-apt-repository ./ Packages
  Ign:4 file:/var/lib/local-apt-repository ./ Packages
  Get:6 http://ftp.de.debian.org/debian buster InRelease [136 kB]
  Get:7 http://ftp.de.debian.org/debian buster/main amd64 Packages [7258 kB]
  Get:8 http://ftp.de.debian.org/debian buster/main Translation-en [5553 kB]
  Fetched 12.9 MB in 18s (696 kB/s)
  Reading package lists...
  E: Failed to fetch file:/var/lib/local-apt-repository/./Sources  File not 
found - /var/lib/local-apt-repository/./Sources (2: No such file or directory)
  E: Some index files failed to download. They have been ignored, or old ones 
used instead.


Andreas


local-apt-repository_0.4.log.gz
Description: application/gzip

Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA

[Jason Gunthorpe]

> However, it would of course be better to teach udma_barrier.h about
> these architectures.

The issue is that some architectures just can't do cache coherent DMA
on any implementation. eg m68k

There is no correct udma_barrier.h at all in those cases.

We need to teach debian to follow cmake and exclude the missing
installables in these cases..

Or do not build at all on these arch's..

Jason

Bug#881733: totem: Totem unable to play anything with any user but root

[Michael Biebl]

Am 14.11.2017 um 19:39 schrieb jEsuSdA 8):
> El 14/11/17 a las 17:41, Michael Biebl escribió:

> With a fresh user it works.
> 
> I try to delete some .cache .dbus files and it works!

I suspect it is
~/.cache/gstreamer-1.0/registry.x86_64.bin which got messed up.
That's why I asked you to test with a fresh user account.

I vaguely remember a few bug reports in that regard.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715529 is a rather old
one but I think we had similar user reports just recently.

What Jeremy said is true as well: Please don't run graphical
applications as root!

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature