Bug#901793: Info received (Bug#901793: certbot: Fails to renew because of a SSL/TLSv1 error and more)

[François Gannaz]

Here is the explanation: the /etc/hosts files had lines that gave static
IPs to the servers that renew certificates:

# /etc/hosts
104.85.23.247  acme-v01.api.letsencrypt.org
104.85.23.247  acme-staging.api.letsencrypt.org

These point to Akamai server. They were probably proxing letsencrypt
servers until last month, since renewing certificates worked for the last
10 months with this config.

I can't trace precisely the origin of those 2 lines, but etckeeper shows
they were introduced at the same time certbot was installed (2017-08). And
I certainly did not write them myself. I suppose certbot's install was a
bit flawed at that time.

You may close the ticket. Thank you for you help.

Bug#902239: enlightenment: source should be enlightenment not e17

[Andreas Metzler]

On 2018-06-24 sergio  wrote:
> On 24/06/2018 04:11, Ross Vandegrift wrote:

>>> could you update source to "enlightenment" as e17 is outdated.
 
>> We discussed this a while back, and decided to leave it.  See:
>> https://alioth-lists.debian.net/pipermail/pkg-e-devel/2015-November/002442.html

> It was about three years ago.

Has anything substantially changed since then?

> E17 is just a intermediate version that doesn't exists more.
> e17 confuses

> What is wrong to leave it orphaned and remove completely afterwards?

This is about the source package. Who is going to be confused? And what
to what effect? You fail to convince me that this is more than an
aestetic problem. On the other hand having one of the pts pages of
our binary packages () point to the
wrong source package is a usability problem /for/ /me/.

Switching source package names is significant effort, not only for us
but also for the for ftpmasters, which is an already resource limited
core team.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Dean Loros]

Well---I'm still picking up the pieces here.  Not sure what happened,
but that did not work for me & for some reason, I can't revert it back
or boot the older 4.16-1. everything just hangs. I'm in my backup
system, looking at the kernel logs. Last entry starts:

Jun 23 21:22:52 debian kernel: [0.00] Linux version
4.16.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0
(Debian 7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22)

Jun 23 21:22:52 debian kernel: [0.00] Command line:
BOOT_IMAGE=/boot/vmlinuz-4.16.0-2-amd64
root=UUID=c18c39f1-0e2c-4c89-a534-e3c8414bb273 ro cgroup_enable=memory
swapaccount=1 elevator=noop nvidia-current.NVreg_EnablePCIeGen3=1
slab_common.usercopy_fallback=y

Normal boot until GDM "should" come up, then I get:

Jun 23 21:23:00 debian kernel: [   28.992343] nvidia-uvm: Loaded the
UVM driver in 8 mode, major device number 242
Jun 23 21:23:00 debian kernel: [   29.383969] resource sanity check:
requesting [mem 0x000c-0x000f], which spans more than PCI Bus
:00 [mem 0x000c-0x000d window]
Jun 23 21:23:00 debian kernel: [   29.384003] caller
_nv001169rm+0xe3/0x1d0 [nvidia] mapping multiple BARs
Jun 23 21:23:02 debian kernel: [   30.747951] show_signal_msg: 14
callbacks suppressed
Jun 23 21:23:02 debian kernel: [   30.747953] gnome-shell[1370]:
segfault at 20 ip 7f2ee7714aed sp 7fff4654cb00 error 4 in
libmutter-2.so.0.0.0[7f2ee7617000+165000]

Last line repeats about 50 times with slightly different addresses
[7f2ee7617000+165000] is a typical example--the 165000 stays constant.

There is also a note about updating runlevels during this period.

I get the same result with my older 4.16-1 kernel now...no combination
of workaround(s) seem to have any effect. Thoughts welcome.

Bug#902264: dictd: post-installation fails

[Sven Joachim]

On 2018-06-24 00:17 -0400, Vincent Lefevre wrote:

> Package: dictd
> Version: 1.12.1+dfsg-5
> Severity: grave
> Justification: renders package unusable
>
> I got the following error during the installation:
>
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Setting up dictd (1.12.1+dfsg-5) ...
> insserv: warning: current stop runlevel(s) (1) of script `dictd' overrides 
> LSB defaults (0 1 6).
> Job for dictd.service failed because the control process exited with error 
> code.
> See "systemctl status dictd.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript dictd, action "restart" failed.
> ● dictd.service - LSB: Start and stop dictionary server daemon
>Loaded: loaded (/etc/init.d/dictd; generated)
>Active: failed (Result: exit-code) since Sun 2018-06-24 00:14:29 EDT; 5ms 
> ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 27093 ExecStart=/etc/init.d/dictd start (code=exited, 
> status=1/FAILURE)
>
> Jun 24 00:14:29 zira systemd[1]: Starting LSB: Start and stop dictionary 
> server daemon...
> Jun 24 00:14:29 zira dictd[27093]: Starting dictionary server: dictd failed!
> Jun 24 00:14:29 zira systemd[1]: dictd.service: Control process exited, 
> code=exited status=1
> Jun 24 00:14:29 zira systemd[1]: dictd.service: Failed with result 
> 'exit-code'.
> Jun 24 00:14:29 zira systemd[1]: Failed to start LSB: Start and stop 
> dictionary server daemon.
> dpkg: error processing package dictd (--configure):
>  installed dictd package post-installation script subprocess returned error 
> exit status 1
> Errors were encountered while processing:
>  dictd

Same here.  Rebuilding dictd without 17-fix-some-gcc-8-warnings.patch
fixes that, I leave it to the author of that patch to figure out what
exactly is wrong with it.

Cheers,
   Sven

Bug#902264: dictd: post-installation fails

[Vincent Lefevre]

Package: dictd
Version: 1.12.1+dfsg-5
Severity: grave
Justification: renders package unusable

I got the following error during the installation:

E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up dictd (1.12.1+dfsg-5) ...
insserv: warning: current stop runlevel(s) (1) of script `dictd' overrides LSB 
defaults (0 1 6).
Job for dictd.service failed because the control process exited with error code.
See "systemctl status dictd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript dictd, action "restart" failed.
● dictd.service - LSB: Start and stop dictionary server daemon
   Loaded: loaded (/etc/init.d/dictd; generated)
   Active: failed (Result: exit-code) since Sun 2018-06-24 00:14:29 EDT; 5ms ago
 Docs: man:systemd-sysv-generator(8)
  Process: 27093 ExecStart=/etc/init.d/dictd start (code=exited, 
status=1/FAILURE)

Jun 24 00:14:29 zira systemd[1]: Starting LSB: Start and stop dictionary server 
daemon...
Jun 24 00:14:29 zira dictd[27093]: Starting dictionary server: dictd failed!
Jun 24 00:14:29 zira systemd[1]: dictd.service: Control process exited, 
code=exited status=1
Jun 24 00:14:29 zira systemd[1]: dictd.service: Failed with result 'exit-code'.
Jun 24 00:14:29 zira systemd[1]: Failed to start LSB: Start and stop dictionary 
server daemon.
dpkg: error processing package dictd (--configure):
 installed dictd package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 dictd

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

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

Versions of packages dictd depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.67
ii  dictzip1.12.1+dfsg-5
ii  libc6  2.27-3
ii  libmaa41.4.2-1
ii  lsb-base   9.20170808
ii  netbase5.4
ii  ucf3.0038
ii  update-inetd   4.45
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages dictd recommends:
ii  dict [dict-client]  1.12.1+dfsg-5

Versions of packages dictd suggests:
ii  dict-foldoc [dictd-dictionary]20170105-1
ii  dict-freedict-eng-fra [dictd-dictionary]  2016.12.12-1
ii  dict-freedict-fra-eng [dictd-dictionary]  2016.12.12-1
ii  dict-gcide [dictd-dictionary] 0.48.4
ii  dict-jargon [dictd-dictionary]4.4.7-3
ii  dict-vera [dictd-dictionary]  1:1.23-1
ii  dict-wn [dictd-dictionary]1:3.0-35

-- debconf information:
  dictd/run_mode: daemon

Bug#902258: any docker command triggers an attempt to unlock my GPG key

[Dmitry Smirnov]

On Sunday, 24 June 2018 12:10:43 PM AEST Tianon Gravi wrote:
> I'll bet you've got "pass" [1] installed, and this is thus
> docker/cli#699 [2]. :)

Looks like everybody who have Graphical Desktop Environment installed would 
have "pass" by default.

I think the real problem is that password prompt appears even on `docker 
info` where there is nothing to unlock...

Although upstream would probably disagree, I've found that non-interactice 
commands (e.g. `watch -- docker ps`) are affected by this problem...

-- 
All the best,
 Dmitry Smirnov.

---

Every decent man is ashamed of the government he lives under.
-- H. L. Mencken


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

Bug#806174: apt: uninitialised value MUNIN_PLUGSTATE

[Lars Kruse]

Hello Martin,


Am Wed, 25 Nov 2015 14:33:04 +1300
schrieb martin f krafft :

> Package: munin-plugins-extra
> Version: 2.0.25-2
> Severity: minor
> File: /usr/share/munin/plugins/apt
> 
> I am seeing this on all hosts running the apt plugin:
> 
>   Use of uninitialized value $ENV{"MUNIN_PLUGSTATE"} in concatenation (.) or 
> string at
>   /etc/munin/plugins/apt line 78.

it looks to me as if this issue was fixed before (in v2.0.12) by the following
commit of upstream:
 
https://github.com/munin-monitoring/munin/commit/2b82c38fec32ba09de7a0d83996e54f07543513c

Do you have an idea, why it failed for you?
Does the problem still exist?

Cheers,
Lars

Bug#698302: munin_stats: wrong values for munin graph

[Lars Kruse]

Hi Uwe,

I assume, that this issue was caused by "munin_stats" ignoring that cgi-based
graph generation was configured?

In this case it was fixed in v2.0.27-1.

Or what do you think?

Cheers,
Lars

Bug#902116: regression: keyscript=decrypt_keyctl doesn't cache passphrase anymore

[Guilhem Moulin]

Control: retitle -1 off-by-one error in CRYPTTAB_TRIED breaks decrypt_keyctl 
keyscript (doesn't cache anymore)
Control: tag -1 pending

Hi Andras,

On Fri, 22 Jun 2018 at 15:36:26 +0200, Andras Korn wrote:
> This had the result that I was prompted for the passphrase for sda3 during
> the initramfs phase, but sda4 was not unlocked and I wasn't prompted for the
> passphrase either; booting failed, because sda4 contains zfs root pool.

I'm surprised this worked before (without 'initramfs' crypttab option),
cf. #820888 and #838001.  The initramfs hook now uses /proc/mounts
rather than /etc/fstab to determine which device holds the root FS (and
also /usr and the swap area).  How does the relevant /proc/mounts
entries look like in your case?

> Now booting works but I'm prompted for the passphrase twice (both times with
> "Caching passphrase for", meaning the decrypt_keyctl script gets run, but
> the caching is broken).

This was caused by an an off-by-one error in CRYPTTAB_TRIED (number of
previous tries).  Fixed in


https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/2a9946771a3fb9eef522eb933d58a22ab8d86603

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#902263: transition: qtbase-opensource-src

[Simon Quigley]

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

Hello Release Team!

We aren't ready to start the transition yet, but it would be great if
you could set up the transition tracker.

As usual, we have two sub-transitions in one large transition:

title = "qtbase-opensource-src";
is_affected = .depends ~ "qtbase-abi-5-10-0" | .depends ~ "qtbase-abi-5-11-0";
is_good = .depends ~ "qtbase-abi-5-11-0";
is_bad = .depends ~ "qtbase-abi-5-10-0";

and

title = "qtdeclarative-opensource-src";
is_affected = .depends ~ "qtdeclarative-abi-5-10-1" | .depends ~ 
"qtdeclarative-abi-5-11-0";
is_good = .depends ~ "qtdeclarative-abi-5-11-0";
is_bad = .depends ~ "qtdeclarative-abi-5-10-1";

This is my first transition in Debian, so I will be working with
lisandro and mitya57 to ensure it goes smoothly.

I'll reply to this bug when we have tested rdeps and are ready to
proceed with the transition.

Thank you in advance!

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



signature.asc
Description: OpenPGP digital signature

Bug#901831: thousands of GetVSyncParametersIfAvailable() failed!

[Michael Gilbert]

On Sat, Jun 23, 2018 at 11:03 PM, Michael Gilbert wrote:
> Do you have libgles2 installed?  If not, could you try installing it?

Also try using "--use-gl=osmesa" command line flag.

Best wishes,
Mike

Bug#902262: tracker.debian.org: incorrect data for owncloud removal

[Paul Wise]

Package: tracker.debian.org
Severity: important

The removals news items for owncloud differ from the PTS:

https://packages.qa.debian.org/o/owncloud.html

[2017-05-06] Removed 7.0.4+dfsg-4~deb8u4 from stable (None)
[2016-04-26] Removed 7.0.13~dfsg-1 from unstable (None)
[2016-04-15] owncloud REMOVED from testing (Britney)

https://tracker.debian.org/pkg/owncloud

[2016-04-26] Removed 7.0.13~dfsg-1 from unstable (Debian FTP Masters)
[2016-04-26] Removed 7.0.13~dfsg-1 from unstable (Debian FTP Masters)
[2016-04-15] owncloud REMOVED from testing (Debian testing watch)

The tracker data appears to have duplicated the removal from unstable
and dropped the removal from stable.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#896393: python-fastkml: fastkml fails to import

[Andreas Beckmann]

Followup-For: Bug #896393

Hi,

what about fixing this in stretch, too?
A simple rebuild of the sid package in stretch as 0.11-2~deb9u1 should
do the job. I could NMU it if you need help.


Andreas

Bug#901831: thousands of GetVSyncParametersIfAvailable() failed!

[Michael Gilbert]

On Sat, Jun 23, 2018 at 10:49 PM, Dan Jacobson wrote:
> [18200:18200:0624/103814.709689:ERROR:gl_implementation.cc(292)] : Failed to 
> load /usr/lib/chromium/swiftshader/libGLESv2.so: 
> /usr/lib/chromium/swiftshader/libGLESv2.so: cannot open shared object file: 
> No such file or directory

Do you have libgles2 installed?  If not, could you try installing it?

Best wishes,
Mike

Bug#901717: debootstrap: Version 1.0.102 breaks use of file mirrors

[Hideki Yamane]

Hi,

On Sat, 23 Jun 2018 11:14:58 +0100
Christopher Obbard  wrote:
> $ cat test/debootstrap/debootstrap.log
> ...
> /debootstrap/debootstrap: 1428: /debootstrap/debootstrap: cannot open
> //var/lib/apt/lists/http:__deb.debian.org_debian_dists_buster_main_binary-armhf_Packages:
> No such file

 Oh, that is not expected, installation was failed...
 Here's a proposed patch.

diff --git a/debootstrap b/debootstrap
index 023a54f..c61636f 100755
--- a/debootstrap
+++ b/debootstrap
@@ -422,6 +422,7 @@ fi
 if [ "$SECOND_STAGE_ONLY" = "true" ]; then
SUITE=$(cat "$DEBOOTSTRAP_DIR/suite")
ARCH=$(cat "$DEBOOTSTRAP_DIR/arch")
+   USER_MIRROR=$(cat "$DEBOOTSTRAP_DIR/mirror")
if [ -e "$DEBOOTSTRAP_DIR/variant" ]; then
VARIANT=$(cat "$DEBOOTSTRAP_DIR/variant")
SUPPORTED_VARIANTS="$VARIANT"
@@ -725,6 +726,7 @@ if am_doing_phase first_stage; then
cp "$DEBOOTSTRAP_DIR"/scripts/*-common  "$TARGET/debootstrap/"
echo "$ARCH">"$TARGET/debootstrap/arch"
echo "$SUITE"   >"$TARGET/debootstrap/suite"
+   echo "$USER_MIRROR" >"$TARGET/debootstrap/mirror"
[ "" = "$VARIANT" ] ||
echo "$VARIANT" >"$TARGET/debootstrap/variant"
echo "$required">"$TARGET/debootstrap/required"


> >> we should write the file mirror URI to sources.list
> >
> >  And that assumption needs to be discussed.
> >
> >  If we would create chroot with debootstrap specified with file:///
> >  mirror and bring it to another environment, sources.list should
> >  point local file mirror or not?
> 
> You are right, thinking about it mirror URI should not added to sources.list.
> I do like the original method debootstrap 1.0.101 uses of caching the
> list of packages when using a file mirror under debootstrap.invalid.
> All of the packages are cached in the first-stage anyway.
> 
> After the install is complete, we should clear /etc/apt/sources.list
> of debootstrap.invalid.
> The user should update /etc/apt/sources.list himself anyway.

 I prefer to use http(s)://deb.debian.org/debian as default mirror
 setting for it, since it's okay for most users and works.

Bug#901831: thousands of GetVSyncParametersIfAvailable() failed!

[積丹尼 Dan Jacobson]

Graphics Feature Status
Canvas: Software only. Hardware acceleration disabled
Flash: Software only. Hardware acceleration disabled
Flash Stage3D: Software only. Hardware acceleration disabled
Flash Stage3D Baseline profile: Software only. Hardware acceleration disabled
Compositing: Software only. Hardware acceleration disabled
Multiple Raster Threads: Disabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
undefined: Disabled
Rasterization: Software only. Hardware acceleration disabled
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Synchronization: Disabled
Video Decode: Software only. Hardware acceleration disabled
Viz Service Display Compositor: Disabled
WebGL: Disabled
WebGL2: Disabled
Problems Detected
GPU process was unable to boot: GPU process crashed too many times with 
SwiftShader.
Disabled Features: all
Raster is using a single thread.
Disabled Features: multiple_raster_threads
Native GpuMemoryBuffers have been disabled, either via about:flags or command 
line.
Disabled Features: native_gpu_memory_buffers
Viz service display compositor is not enabled by default.
Disabled Features: viz_display_compositor
Skia renderer is not used by default.
Disabled Features: skia_renderer
Skia deferred display list is not used by default.
Disabled Features: skia_deferred_display_list
Version Information
Data exported   2018-06-24T02:44:21.192Z
Chrome version  Chrome/68.0.3440.7
Operating systemLinux 4.16.0-2-amd64
Software rendering list URL 
https://chromium.googlesource.com/chromium/src/+/9bbd2d0687bd83181f22ac13565501690ee5b4c7/gpu/config/software_rendering_list.json
Driver bug list URL 
https://chromium.googlesource.com/chromium/src/+/9bbd2d0687bd83181f22ac13565501690ee5b4c7/gpu/config/gpu_driver_bug_list.json
ANGLE commit id unknown hash
2D graphics backend Skia/68 e9c81ee2ea3a77fb4641435a97fef447c1b85128-
Command Line/usr/lib/chromium/chromium --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --enable-remote-extensions 
--flag-switches-begin --flag-switches-end https://panel.dreamhost.com/
Driver Information
Initialization time 581
In-process GPU  false
Passthrough Command Decoder false
Direct Composition  false
Supports overlays   false
Sandboxed   false
GPU0VENDOR = 0x10de [nouveau], DEVICE= 0x0242 [NV4E] *ACTIVE*
Optimus false
AMD switchable  false
Driver vendor   Mesa
Driver version  18.1.2
Driver date 
Pixel shader version1.20
Vertex shader version   1.20
Max. MSAA samples   0
Machine model name  
Machine model version   
GL_VENDOR   nouveau
GL_RENDERER NV4E
GL_VERSION  2.1 Mesa 18.1.2
GL_EXTENSIONS   GL_AMD_shader_trinary_minmax GL_ANGLE_texture_compression_dxt3 
GL_ANGLE_texture_compression_dxt5 GL_APPLE_packed_pixels 
GL_ARB_ES2_compatibility GL_ARB_buffer_storage GL_ARB_clear_buffer_object 
GL_ARB_compressed_texture_pixel_storage GL_ARB_copy_buffer GL_ARB_debug_output 
GL_ARB_depth_clamp 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_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_half_float_pixel 
GL_ARB_half_float_vertex 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 
GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync 
GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map 
GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar 
GL_ARB_texture_env_dot3 GL_ARB_texture_filter_anisotropic 
GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_mirrored_repeat 
GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_storage 
GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transpose_matrix 
GL_ARB_vertex_array_object GL_ARB_vertex_attrib_binding 
GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader 
GL_ARB_window_pos GL_ATI_blend_equation_separate GL_ATI_draw_buffers 
GL_ATI_fragment_shader GL_ATI_separate_stencil GL_ATI_texture_env_combine3 
GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color 
GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax 
GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_texture 
GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord 
GL_EXT_framebuffer_blit GL_EXT_framebuffer_object 

Bug#901831: thousands of GetVSyncParametersIfAvailable() failed!

[Michael Gilbert]

control: tag -1 upstream, moreinfo, unreproducible
control: severity -1 minor

On Tue, Jun 19, 2018 at 2:33 AM, Dan Jacobson wrote:
> Many GetVSyncParametersIfAvailable() failed!

I am not able to reproduce this.  I assume its an issue specific to
your video driver, can you paste chrome://gpu here?

Did you see this in previous versions?  The VSync routines didn't
change between 67 and 68.

Best wishes,
Mike

Bug#902261: sddm: Tap-to-click on laptop trackpad does not work

[Qasim Ali]

Package: sddm
Version: 0.14.0-4
Severity: minor

Dear Maintainer,

On my XPS 13 9350 laptop, I'm unable to click on menu items from the login 
screen by simply tapping on the trackpad.

Once I log in to KDE, tap-to-click works as configured.

This inconsistent behaviour is confusing and may lead users to think that their 
trackpad is not properly supported by Debian.

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

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

Versions of packages sddm depends on:
ii  adduser 3.115
ii  debconf [debconf-2.0]   1.5.61
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libpam0g1.1.8-3.6
ii  libqt5core5a5.7.1+dfsg-3+b1
ii  libqt5dbus5 5.7.1+dfsg-3+b1
ii  libqt5gui5  5.7.1+dfsg-3+b1
ii  libqt5network5  5.7.1+dfsg-3+b1
ii  libqt5qml5  5.7.1-2+b2
ii  libqt5quick55.7.1-2+b2
ii  libstdc++6  6.3.0-18+deb9u1
ii  libsystemd0 232-25+deb9u3
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  qml-module-qtquick2 5.7.1-2+b2
ii  x11-common  1:7.7+19
ii  xserver-xorg [xserver]  1:7.7+19

Versions of packages sddm recommends:
ii  libpam-systemd   232-25+deb9u3
ii  sddm-theme-debian-maui [sddm-theme]  0.14.0-4

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.8.4-1+deb9u2

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

Bug#902260: modemmanager: postrm script broken: --runtime cannot be used with unmask

[Carl Suster]

Package: modemmanager
Version: 1.7.990-1
Severity: important

Dear Maintainer,

When trying to remove the modemmanager package dpkg reports an error:

Performing actions...
(Reading database ... 370879 files and directories currently installed.)
Removing modemmanager (1.7.990-1) ...
--runtime cannot be used with unmask
dpkg: error processing package modemmanager (--remove):
 installed modemmanager package post-removal script subprocess returned 
error exit status 1
Errors were encountered while processing:
 modemmanager
E: Sub-process /usr/bin/dpkg returned an error code (1)

The first few lines of the postrm script are:

#!/bin/sh
set -e

# drop the temporary mask from prerm
if [ -d /run/systemd/system ] && [ "$1" = remove ]; then
systemctl unmask --runtime ModemManager
fi

And checking the man page of systemctl under --runtime:

--runtime
When used with set-property, make changes only temporarily, so that
they are lost on the next reboot.

[...]

Note: this option cannot be used with disable, unmask, preset, or
preset-all, because those operations sometimes need to remove
symlinks under /etc to have the desired effect, which would cause a
persistent change.

So it seems that the script is indeed incorrect in its usage of that flag.


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

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

Versions of packages modemmanager depends on:
ii  libc6  2.27-3
ii  libglib2.0-0   2.56.1-2
ii  libgudev-1.0-0 232-2
pn  libmbim-glib4  
pn  libmbim-proxy  
ii  libmm-glib01.7.990-1
ii  libpolkit-gobject-1-0  0.105-20
pn  libqmi-glib5   
pn  libqmi-proxy   
ii  libsystemd0239-1

Versions of packages modemmanager recommends:
ii  usb-modeswitch  2.5.2+repack0-2

modemmanager suggests no packages.

-- no debconf information

Bug#900533: bug not fixed in v68

[Michael Gilbert]

On Sat, Jun 23, 2018 at 8:47 PM, 積丹尼 Dan Jacobson wrote:
> The browser won't let people switch back from 68 to 67 anyway,
> they would have to rip up their whole profile.

Have you ever considered not upgrading when packages land in
experimental?  They are after all experimental.

Best wishes,
Mike

Bug#902258: any docker command triggers an attempt to unlock my GPG key

[Tianon Gravi]

On Sat, 23 Jun 2018 at 18:51, Yaroslav Halchenko  wrote:
> IMHO doker must not ask for unlocking GPG key at all AFAIK, unless may be
> some functionality requires signing et.
>
> I've not yet tried to figure out what exactly leads to it.

I'll bet you've got "pass" [1] installed, and this is thus
docker/cli#699 [2]. :)

[1]: https://packages.debian.org/sid/pass
[2]: https://github.com/docker/cli/issues/699

(There's also a 5-day-old PR [3] which attempts to fix this.)

[3]: https://github.com/docker/cli/pull/1131

The alternative when you don't have "pass" installed is that "docker
login" will store your Docker Hub credentials with just base64
encoding in ~/.docker/config.json (with "pass" it'll use that to make
sure they're encrypted at rest instead).


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#902259: dmidecode: Please update Vcs field (and possibly host git repo on Salsa)

[Boyuan Yang]

Source: dmidecode
Version: 3.1-1
Severity: normal

With the decommission of Alioth, Vcs fields in your package (dmidecode) is now
defunct.

Please consider creating another git repo on Debian Salsa platform (ideally
under salsa.debian.org/debian group) and host your git packaging repository
there.

--
Regards,
Boyuan Yang



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

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

-- no debconf information

Bug#902239: enlightenment: source should be enlightenment not e17

[sergio]

On 24/06/2018 04:11, Ross Vandegrift wrote:


could you update source to "enlightenment" as e17 is outdated.


We discussed this a while back, and decided to leave it.  See:
https://alioth-lists.debian.net/pipermail/pkg-e-devel/2015-November/002442.html



It was about three years ago.
E17 is just a intermediate version that doesn't exists more.
e17 confuses
What is wrong to leave it orphaned and remove completely afterwards?


--
sergio.

Bug#902239: enlightenment: source should be enlightenment not e17

[sergio]

e17 is used in the url:

https://tracker.debian.org/pkg/e17

and has wrong description:

"transitional e17 package"

--
sergio.

Bug#902101: openmpi: OpenMPI 3 on ppc64el seems unstable

[Alastair McKinstry]

Hi,

There is a patch in 3.1.0-7 for powerpc / ppc*64 systems:


   Index: openmpi-3.0.1~rc1/opal/include/opal/sys/powerpc/atomic.h
   ===
   --- openmpi-3.0.1~rc1.orig/opal/include/opal/sys/powerpc/atomic.h
   +++ openmpi-3.0.1~rc1/opal/include/opal/sys/powerpc/atomic.h
   @@ -27,6 +27,13 @@
  * On powerpc ...
  */

   +/* Hack on Debian. See: https://github.com/open-mpi/ompi/issues/2055
   + *   -- amck, 2016-09-05
   + */
   +#undef OPAL_GCC_INLINE_ASSEMBLY
   +#define OPAL_GCC_INLINE_ASSEMBLY 1
   +
   +
 #define MB()  __asm__ __volatile__ ("sync" : : : "memory")
 #define RMB() __asm__ __volatile__ ("lwsync" : : : "memory")
 #define WMB() __asm__ __volatile__ ("lwsync" : : : "memory")

I've just checked and this fix is no longer needed. It may be 
interfering with the locking primitives used and hence I've removed it 
(in git).


Simarly for a patch for arm64 (note: not armel, so possibly not relevant 
for #902041).


I'm uploading a release with these removed.


Regards

Alastair




On 22/06/2018 09:18, Ansgar Burchardt wrote:

Source: openmpi
Version: 3.1.0-7
Severity: important

OpenMPI 3 on ppc64el seems unstable: the test suite for dune-grid only
passes ~30% of the time on ppc64el. In the other cases it hangs in MPI
communication or gets unexpected results.

I haven't been able to find a simpler test case yet (unlike armel,
#902041).

(Maybe related: on powerpc all MPI tests in dune-grid just run into a
timeout, but that one is not a release arch so I care less.)

Ansgar


--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#902258: any docker command triggers an attempt to unlock my GPG key

[Yaroslav Halchenko]

Package: docker.io
Version: 18.03.1+dfsg1-3
Severity: grave

Filing an official report so it doesn't get forgotten (we had some private
correspondence about it).  New behavior was detected while testing new version
in experimental (17.12.1+dfsg-2) and maintains with current one:  running any
docker command (even just docker --help) triggers a dialog to enter my GPG key
password.  I am really not sure why this should be necessary but it is
worrisome that it might result in leakage or unauthorized use of GPG keys,
happen user has it unlocked in the session (gpg-agent etc).

IMHO doker must not ask for unlocking GPG key at all AFAIK, unless may be
some functionality requires signing et.

I've not yet tried to figure out what exactly leads to it.

Cheers,
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages docker.io depends on:
ii  adduser 3.117
ii  iptables1.6.2-1
ii  libc6   2.27-2
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libltdl72.4.6-2
ii  libnspr42:4.18-1
ii  libnss3 2:3.35-2
ii  libseccomp2 2.3.1-2.1
ii  libsystemd0 238-3
ii  lsb-base9.20170808
ii  runc1.0.0~rc4+dfsg1-2
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20170717
ii  cgroupfs-mount   1.4
ii  git  1:2.17.0-1
ii  xz-utils 5.2.2-1.3

Versions of packages docker.io suggests:
ii  aufs-tools   1:4.9+20170918-1
ii  btrfs-progs  4.15.1-1
ii  debootstrap  1.0.93+nmu2
pn  docker-doc   
pn  rinse
pn  zfs-fuse | zfsutils  

-- debconf-show failed

Bug#902239: enlightenment: source should be enlightenment not e17

[Ross Vandegrift]

Control: tags -1 wontfix
Control: severity -1 wishlist

On Sat, Jun 23, 2018 at 09:02:40PM +0300, sergio wrote:
> could you update source to "enlightenment" as e17 is outdated.

We discussed this a while back, and decided to leave it.  See:
https://alioth-lists.debian.net/pipermail/pkg-e-devel/2015-November/002442.html

Ross

Bug#902257: groff-base: nroff crashes when the environment variable SHELL is unset

[Boris Jakubith]

Package: groff-base
Version: 1.22.4~rc2-2
Severity: important

I found out this problem after debugging 'dwww' which no longer created any
output for manual pages. After near 3 hours of debugging i found that the
command

man  -EUTF-8 -P/bin/cat  -l "/usr/share/man/man1/7z.1.gz" | dwww-txt2html 
--man --utf8

crashed with the following message:

man: nroff: Bad system call
man: command exited with status 159: /usr/lib/man-db/zsoelim | 
/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 
| tbl | nroff -mandoc -Tutf8

The same command worked without problems in a shell (with the normal
environment). Using 'env -i ... man ...' with all environment variables
supplied and eliminating the environment variables one by one, the command
crashed with the error message above after i eliminated 'SHELL=/bin/bash'.

This leads me to a work-around for 'dwww'. Insert in 'dwww-convert' near line
248 an environment setting for 'SHELL':

$ENV{'SHELL'} = '/bin/sh';

This should solve the problems with 'dwww', but if some other programs use
'man' with a limited environment, this problem may occur, too.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages groff-base depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-8
ii  libstdc++68.1.0-8
ii  libuchardet0  0.0.6-3

groff-base recommends no packages.

Versions of groff-base which are affected:
ii  groff-base  1.22.3-10
ii  groff-base  1.22.4~rc2-2

-- no debconf information

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Andreas Beckmann]

Hi Dean,

On 2018-06-24 01:34, Dean Loros wrote:
> I can also confirm that: slab_common.usercopy_fallback=y   works for
> 4-16-2. I have:
> 
> /etc/nvidia/current/nvidia-drm-outputclass.conf
> with this content:
> 
> Section "OutputClass"
> Identifier "nvidia"
> MatchDriver"nvidia-drm"
> Driver  "nvidia"
> ModulePath "/usr/lib/xorg/modules/linux"
> EndSection

Could you try this nvidia-drm-outputclass.conf instead?
It should do the same, but in a way compatible with both
Xserver >= 1.20 and Xserver < 1.20.

---
Section "Files"
ModulePath "/usr/lib/xorg/modules/linux"
ModulePath "/usr/lib/xorg/modules"
EndSection

Section "OutputClass"
Identifier "nvidia"
MatchDriver"nvidia-drm"
Driver "nvidia"
EndSection
---

Thanks


Andreas

Bug#902256: Broken with the latest Firefox versions

[Gunnar Hjalmarsson]

Package: browser-plugin-freshplayer-pepperflash
Version: 0.3.5-1
Severity: grave

Forwarding the Ubuntu bug .

Version 0.3.5 of browser-plugin-freshplayer-pepperflash does not work 
with the latest versions of Firefox. I think it's related to Firefox's 
improved sandboxing feature.


Upgrading to 0.3.9 seems to fix the problem.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#839233: munin: race condition when building plugins sometimes resulting in wrong plugin shipped

[Lars Kruse]

Hello,


Am Fri, 30 Sep 2016 14:55:26 +0200
schrieb Holger Levsen :

> from IRC:
> 
>  | 
> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/munin.html
>  - fascinating. also how this cannot be seen on i386?!?
> < ntyni> | race between ./plugins/node.d.linux/netstat.in and 
> ./plugins/node.d/netstat.in ?
>  | and "diff ./plugins/node.d.linux/netstat.in 
> ./plugins/node.d/netstat.in" confirms
> 
> the HTML diffoscope output is attached, the txt output can be seen 
> at
> https://tests.reproducible-builds.org/debian/dbdtxt/experimental/armhf/munin_2.999.3-1.diffoscope.txt
> 
> So as a result, the shipped /usr/shar/munin/plugins/netstat sometimes is
> the one from ./plugins/node.d and sometimes it's the one from
> ./plugins/node.d.linux ! (Filing this bug only with severity "important"
> as it just seems to affect one plugin…)

what a mysterious behaviour!

I went through the Makefile and failed to find an obvious source of the problem.

Thus I started to look for the "barely imaginable" places and found the
following ones:

1) The plugins are "compiled" individually by a perl script filter.
   There is a strict one-to-one mapping from input filenames to output
   filenames. Thus ordering cannot be an issue here.
   It _could_ be, that the filtering did not transfer all files (e.g. because
   the output of "find" was truncated). But this could not have happened
   without an error from "make".

2) The "OSTYPE" is determined (see debian/ostype_helper) by comparing the
   output of "uname" with "Linux" and "GNU/kFreeBSD". If there is no match (or
   "uname" fails silently - why should it?), the "OSTYPE" variable would end up
   empty.
   This could be an explanation for the generic plugin being installed instead
   of the linux-specific one.
   I added "set -e" to the "ostype_helper" script. In case this problem ever
   comes back again, we would know, that "ostype_helper" did not cause it.

3) The "compiled" files are copied within the following for loop:
 for p in build/plugins/node.d/* build/plugins/node.d.$(OSTYPE)/* ; do
   As far as I understand shell substitution (here: pathname expansion), the
   two tokens above are evaluated and substituted separately. Thus the
   resulting items are in proper order (first generic, second OS specific).
   This loop cannot be shorted, as far as I can tell. Thus it is hard to
   imagine, that the error happens here.


Do you have any ideas?
Should we just wait for the next reproducibility error?

Cheers,
Lars

Bug#900533: bug not fixed in v68

[積丹尼 Dan Jacobson]

The browser won't let people switch back from 68 to 67 anyway,
they would have to rip up their whole profile.

Bug#902255: llvm-toolchain-6.0: unicode non free license

[Michael Gilbert]

package: src:llvm-toolchain-6.0
version: 1:6.0-3
severity: serious
control: affects -1 src:chromium-browser

LLVM includes ConvertUTF, which has a non free license.  See #823100,
#900596, etc.  Files affected are:

lib/Support/ConvertUTF.cpp
include/llvm/Support/ConvertUTF.h

Best wishes,
Mike

Bug#902254: RFA: openfortivpn -- Fortinet client for PPP+SSL VPN tunnel services

[Sandro Tosi]

Package: wnpp
Severity: normal

I request an adopter for the openfortivpn package.

The package description is:
 openfortivpn is a client for PPP+SSL VPN tunnel services. It spawns a pppd
 process and operates the communication between the gateway and this process.
 .
 It is compatible with Fortinet VPNs.

I no longer use a fortinet vpn service, hence the request for someone else to
take maintainership of this package

Bug#901874: openmpi-bin is wrongly marked Multi-Arch: foreign

[Alastair McKinstry]

On 20/06/2018 21:33, Helmut Grohne wrote:

On Wed, Jun 20, 2018 at 07:19:01AM +0100, Alastair McKinstry wrote:

As the person responsible for this to date in openmpi / mpich, my thinking
is this:
(1) mpicc, etc. wrappers should be deprecated*, but are widespread amongst
the community.

I'm very relieved by that statement. No, it will not happen quickly, but
that paves the road for deploying proper fixes without carrying
non-upstreamable patches indefinitely.
Just to note: While I believe mpicc* should be deprecated, this is not 
yet accepted / discussed much in the community at large.

I think we should push this issue and the use of pkg-config.


They can be made to pull the data from pkg-config (or cmake equivalent)
files.

I'm not sure that making mpicc pull data out of pkg-config is useful. If
it makes your work easier, then that's fine. Still I don't think it
helps cross compilation in any way.
Making upstreams switch from mpicc to calling pkg-config directly will
fix this.


mpicc.openmpi pulls its data from /usr/share/openmpi/mpicc-wrapper-data.txt
. This needs to be moved into a multiarch
directory, and the binary pull the correct one according to architecture
($(DEB_BUILD_MULTIARCH)).

It's not that easy unfortunately. I might agree that
mpicc-wrapper-data.txt could live in a multiarch location. Using
DEB_BUILD_MULTIARCH is entirely wrong though.  ...
So unless you want to break people running mpicc outside
package builds, you cannot use DEB_* variables at all.

Let me try to turn this into a better draft though. If you need mpicc,
you cannot reasonably expect it to work for two architectures at the
same time (how should it tell which one you mean?). So if we remove the
M-A:same from libopenmpi-dev, we can move mpicc-wrapper-data.txt to
libopenmpi-dev *without* moving it to a multiarch location. (Note that
having it on /usr/share is conceptually wrong in any case as the content
is architecture-dependent.) Not being m-a:same sounds bad and it kinda
is, but in reality, we rarely need -dev packages to be M-A:same. For
instance, libgpg-error-dev is not M-A:same, can't be and that's mostly
fine. Now after installing libopenmpi-dev:arm64, it'll pull the native
openmpi-bin (e.g. :amd64), which will read the mpicc-wrapper-data.txt
from the arm64 package and output the right values! That alone should be
enough to fix valgrind.

If you implement that, please close this bug.

Sorry, I don't understand.
my thinking is that we need to move  mpicc-wrapper-data.txt from 
/usr/share to a M-A-aware location,

and make mpicc search the right path.

My question is: what is the canonical method we specify for determining 
the target architecture of a build?


using pkg-config (which i've done for other packages, eg ADIOS which 
ships adios-config, etc.) inherits the answer from pkg-config
(which I presume uses PKG_CONFIG_PATH over the default value of 
/usr/lib/pkg-config.multiarch)


If I have multiple architecture versions of libopenmpi-dev installed, 
how is a cross-build expected to choose the right paths? this is 
important for e.g. cmake as well as pkg-config.




If pkg-config is the way to go, I wonder how downstreams should search
for mpi. Should they ask for particular implementations in their order
of preference? E.g.

for mpi in ompi-c mpich-c; do pkg-config --exists $mpi && echo $mpi && 
break; done
Should we provide some alternative such as "mpi-c.pc" suggested in my
initial mail? Should the builder explicitly have to supply the
implementation? E.g. --with-mpi=ompi
I've been effectively doing this. OpenMPI ships ompi-c, ompi-cxx, 
ompi-fort; I've added mpich-c, mpich-cxx, mpich-fort.

and mpi-c, mpi-cxx, mpi-fort are (alternatives-based) symlinks to these.

I haven't yet extended this to LAM, as its unclear to me whether LAM 
should / will be removed from Buster, as it is

dead upstream (I'm in contact with the maintainer on this ATM).

To me it is very much unclear how one is supposed to use the pkg-config
interface to mpi due to its multiple implementations. Once I know, I'm
happy to send a patch that makes valgrind (and others) use that.

Helmut

Alastair

--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#901936: chromium: Please provide debug symbols

[Michael Gilbert]

control: reassign -1 www.debian.org
control: retitle -1 packages.debian.org: is not aware of dbgsym packages

Witold Baryluk wrote:
> Feel free to reassign to qa.debian.org , tracker.debian.org , or who ever is 
> more relevant for
> this problem.

This is because packages.debian.org is currently not aware of dbgsym packages.

Best wishes,
Mike

Bug#900533: bug not fixed in v68

[Jiri Palecek]

fixed 900533 67.0.3396.79-2

thanks

*
*

Hello,

this bug is fixed in the aforementioned version in unstable (not the one 
in experimental). The telling sign is whether it does or doesn't depend 
on libavcodecXX et al.


Therefore I'm correcting the found/fixed versions.

Regards

    Jiri Palecek

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Dean Loros]

I can also confirm that: slab_common.usercopy_fallback=y   works for
4-16-2. I have:

/etc/nvidia/current/nvidia-drm-outputclass.conf
with this content:

Section "OutputClass"
Identifier "nvidia"
MatchDriver"nvidia-drm"
Driver  "nvidia"
ModulePath "/usr/lib/xorg/modules/linux"
EndSection

 also set in my system.  I have looked at the nVidia bug report & it
"seems" that according to one user:

It seems to be fixed on 396.24.

[1.040981] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  396.24
Thu Apr 26 00:10:09 PDT 2018 (using threaded interrupts)
[1.041976] nvidia-modeset: Loading NVIDIA Kernel Mode Setting
Driver for UNIX platforms  396.24  Wed Apr 25 23:54:18 PDT 2018
[1.049701] nvidia-uvm: Loaded the UVM driver in 8 mode, major
device number 243
[1.050203] Linux agpgart interface v0.103
[1.058829] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver

Kernel 4.16.8-1

Bug#902253: enigmail: Incorrect Polish translation for "Sign message"

[Robert Luberda]

Package: enigmail
Version: 2:2.0.7-6
Severity: normal
Tags: l10n

For some reason Polish translation of "Sign message" menu position 
has been (recently?) changed from "Podpisz wiadomość" into "Znak Wiadomość" 
which I don't think any Pole can understand, unless they can restore original
English from this  pseudo-Polish after realizing that English noun "sign" 
can be translated into "znak" (e.g. "a road sign" is "znak drogowy").

Regards,
robert


-- System Information:
Debian Release: buster/sid
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 enigmail depends on:
ii  gnupg2.2.8-3
ii  gnupg-agent  2.2.8-3
ii  gnupg2   2.2.8-3
ii  gpg-agent [gnupg-agent]  2.2.8-3
ii  icedove  1:52.8.0-1~deb9u1
ii  thunderbird  1:52.8.0-1

Versions of packages enigmail recommends:
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-1+b1

enigmail suggests no packages.

-- no debconf information

Bug#895868: closed by Lars Kruse (Re: munin-cron: Fontconfig error: failed reading config file)

[Calum Mackay]

This is probably https://bugs.debian.org/853848https://bugs.debian.org/853848, 
fixed by upgrading/removing:
  fonts-beng-extra
  fonts-deva-extra
  fonts-gujr-extra
  fonts-guru-extra
  fonts-orya-extra, fixed by upgrading/removing:  


Debian bug 853848 was fixed a year ago, so upgrading won't help this issue.

I purged those pkgs, and the problem remained. The pkg removal resulted 
in various leftovers (with errors), despite --purge:


/etc/fonts/conf.avail/65-0-fonts-guru-extra.conf
/etc/fonts/conf.avail/65-0-fonts-orya-extra.conf
/etc/fonts/conf.avail/65-0-fonts-deva-extra.conf
/etc/fonts/conf.avail/65-0-fonts-gujr-extra.conf
/etc/fonts/conf.avail/65-0-fonts-beng-extra.conf

/usr/share/fonts/truetype/fonts-guru-extra/
/usr/share/fonts/truetype/fonts-orya-extra/
/usr/share/fonts/truetype/fonts-deva-extra/
/usr/share/fonts/truetype/fonts-gujr-extra/
/usr/share/fonts/truetype/fonts-beng-extra/

removing the above manually has finally sorted the problem for me.


thanks very much.

cheers,
calum.

Bug#902252: ITP: golang-github-smira-commander -- Simplify the creation of command line interfaces for Go,

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-smira-commander
  Version : 0.0~git20140515.f408b00-1
  Upstream Author : Andrey Smirnov
* URL : https://github.com/smira/commander
* License : BSD-3-clause
  Programming Lang: Go
  Description : Simplify the creation of command line interfaces for
Go, with commands and sub-commands, with argument checks and contextual
usage help. mirror of http://code.google.com/p/go-commander/.

 commander commander is a fork of a spin off of golang (http://golang.org)
 go tool infrastructure to provide commands and sub-commands.
 .
 Difference with original (http://github.com/gonuts/commander/): •
 flags could be placed anywhere on the command line• flags in whole
 subcommand tree should be non-conflicting (i.e. one name - one value
 type)• interface has changed: first flags should be parsed, then
 command dispatched A commander.Command has a Subcommands field holding
 []*commander.Command subcommands, referenced by name from the command
 line.

This is needed for aptly.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#898749: myspell-pl: Convert into dummy transitional package depending on hunspell-pl

[Robert Luberda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

reassign 898749 src:libreoffice-dictionaries
retitle 898749 Please provide dummy transitional myspell-pl package
thanks

Pander pisze:
> Package: myspell-pl Version: 20161007-1 Severity: normal Tags:
> l10n
> 
> Convert myspell-pl into dummy transitional package depending on 
> hunspell-pl and gradually phase out myspell-pl.

Actually hunspell-pl conflicts with myspell-pl. As the conflict needs
to be dropped anyway (or actually replaced with versioned Breaks), I
think that the libreoffice-dictionaries can provide the transational
package for myspell-pl instead. Once this is done, I can drop
myspell-pl from ipolish source package.

Regards,
robert



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEENeh2+rTTcy6TtNI3Yx3nVTvor9QFAlsu0gcACgkQYx3nVTvo
r9TY8g//RToRyePyvE463ivSu78u1i6tP/o39K80imfVWklBnqBCkYSfBKEipB08
l4PnBp1gUorORoa2hmO0qnw6xU+SjBVCh1LULr8kwafmHCa7orCeN5jaUuzX6Vns
/XboKgEo2cNLi1MnvspqOI3Hm5AWiX0RKkV/BHxVRzJWChCFwK3IrhPOQhSvhHwg
wCIXUZLeMMyPA9m5aAF0phSCpmZdCf802kIGDu4J4BW9xhr53NgwGHMYhW5DDDU0
a+aoVK8INiZ78tzoGGj8wkC2gj0txUf2dGANegP2/BIzrcbuSMwqxHu/aSXDvWVZ
cY8uOIT/pC/TimUb/FfjlBL9pAKhBhf2vRnvDyEltB/SiRrMGis8pZwqEvtAK+U8
7k56UkOtcqo06yxyhbP08e94mi2q8YE91f2ySD5DDp84xum1m1eY4t6R29G9qCCY
7me1ds3fso1Hi2D1l/ngkf6lb9zilO4TGHAHfQfBwcp8gH688J8/Xzo3abz+IKU5
twverhmYv/edNEa2hfqyKEMENYZo3yPZ6MEd9rSWFJBL8wVugxjVtGE/zpJQwf0q
GfKWvfNafqq+Mazi3Fv/OC8LpI6lCQ1cDEhXdO4KjLIU5dFzUzJs/M7DYlK2mlCE
kXE5HMaeEQl/t4TOJvs0XHvMjei5Dt7cGE9kfguG9axCtQ1fuhE=
=1C5m
-END PGP SIGNATURE-

Bug#902246: alien-arena crashes with SIGSEGV on ppc64el with amdgpu graphics

[Simon McVittie]

Control: reassign 902246 libglx-mesa0
Control: forwarded 902246 https://bugs.freedesktop.org/show_bug.cgi?id=107012
Control: tags 902246 + upstream

On Sat, 23 Jun 2018 at 15:15:54 -0500, Timothy Pearson wrote:
> When alien-arena loads a map, right before the gameplay starts, we get a
> SIGSEGV and the game quits

(mesa maintainers: see below for backtrace)

On Sat, 23 Jun 2018 at 16:35:22 -0500, Timothy Pearson wrote:
> This was actually a bug in mesa.  See
> https://bugs.freedesktop.org/show_bug.cgi?id=107012

Thanks. Which version of mesa?

(If possible please use reportbug to report Debian bugs - that
automatically gives package maintainers a lot of useful information,
like the versions of the relevant dependencies, which in this case would
hopefully have included mesa.)

I've sent a comment on the proposed patch to the upstream bug.

Regards,
smcv

> > Thread 1 "alienarena" received signal SIGSEGV, Segmentation fault.
> > 0x71ba5ec4 in llvm::Value::getContext() const () from 
> > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> > (gdb) bt
> > #0  0x71ba5ec4 in llvm::Value::getContext() const () from 
> > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> > #1  0x71ba7db8 in llvm::Value::setNameImpl(llvm::Twine const&) () 
> > from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> > #2  0x71ba8140 in llvm::Value::setName(llvm::Twine const&) () from 
> > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> > #3  0x71b27b60 in 
> > llvm::ExtractValueInst::init(llvm::ArrayRef, llvm::Twine 
> > const&) () from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> > #4  0x71aae6f0 in LLVMBuildExtractValue () from 
> > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> > #5  0x75a7b2e4 in si_build_ps_prolog_function (ctx=0x7fffa120, 
> > key=0x7fffe3f2) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7722
> > #6  0x75a7f8c8 in si_get_shader_part (sscreen=0x10b67dbc0, 
> > list=0x10b67e108, type=PIPE_SHADER_FRAGMENT, prolog=true, 
> > key=0x7fffe3f2, tm=0x10b635f80, debug=0x10c7050a8, build=0x75a7ab40 
> > ,
> > name=0x75c78420 "Fragment Shader Prolog") at 
> > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7154
> > #7  0x75a825c0 in si_shader_select_ps_parts (debug=0x10c7050a8, 
> > shader=0x10c7050a0, tm=0x10b635f80, sscreen=0x10b67dbc0) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7924
> > #8  si_shader_create (sscreen=0x10b67dbc0, tm=0x10b635f80, 
> > shader=0x10c7050a0, debug=0x10c7050a8) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:8114
> > #9  0x75aa21b0 in si_build_shader_variant (shader=0x10c7050a0, 
> > thread_index=, low_priority=) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1510
> > #10 0x75aa4fdc in si_shader_select_with_key (thread_index=-1, 
> > key=0x7fffe54e, compiler_state=0x7fffe6c0, state=0x10b5ed490, 
> > sscreen=0x10b67dbc0) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1772
> > #11 si_shader_select (ctx=0x10b5ec830, state=0x10b5ed490, 
> > compiler_state=0x7fffe6c0) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1790
> > #12 0x75aa5c28 in si_update_shaders (sctx=0x10b5ec830) at 
> > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:3242
> > #13 0x75a9e2a0 in si_draw_vbo (ctx=0x10b5ec830, info=0x10b6372e8) 
> > at ../../../../../src/gallium/drivers/radeonsi/si_state_draw.c:1331
> > #14 0x757513e8 in tc_call_draw_vbo (pipe=, 
> > payload=) at 
> > ../../../../src/gallium/auxiliary/util/u_threaded_context.c:2012
> > #15 0x7574e134 in tc_batch_execute (thread_index=0, job= > out>) at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:96
> > #16 _tc_sync (tc=0x10b636bd0, func=, info=) 
> > at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:207
> > #17 0x75752468 in tc_texture_subdata (_pipe=0x10b636bd0, 
> > resource=0x10c704890, level=, usage=, 
> > box=0x7fffea50, data=0x10ca68650, stride=, 
> > layer_stride=)
> > at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:1717
> > #18 0x75423a30 in st_TexSubImage (ctx=0x10b75ef60, dims=2, 
> > texImage=0x10c70d300, xoffset=0, yoffset=, 
> > zoffset=, width=, height=, 
> > depth=,
> > format=, type=, pixels=, 
> > unpack=) at 
> > ../../../src/mesa/state_tracker/st_cb_texture.c:1434
> > #19 0x75425d14 in st_TexImage (ctx=0x10b75ef60, dims= > out>, texImage=0x10c70d300, format=, type=, 
> > pixels=0x10ca68650, unpack=0x10b7684e8)
> > at ../../../src/mesa/state_tracker/st_cb_texture.c:1651
> > #20 0x75386f40 in teximage (no_error=false, pixels=0x10ca68650, 
> > imageSize=0, type=5121, format=6408, border=0, depth=, 
> > height=, width=, internalFormat=4, level=0, 
> > target=3553,
> > dims=2, compressed=0 '\000', ctx=0x10b75ef60) at 
> > 

Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud

[Lev Lazinskiy]

Hi Michael,

On Tue, 27 Mar 2018 01:00:50 +0200 Michael Biebl  wrote:
> Hi Lev
>
> On Wed, 03 May 2017 22:04:53 -0700 Lev Lazinskiy  wrote:
> > Owner: l...@levlaz.org
> > Control: retitle -1 ITP: nextcloud-client -- desktop client for nextcloud
>
> Any news on this ITP? Are you still interested in/working on this package?

I apologize for the delay here. Yes I am still interested in this package. I am 
starting a new initiative to get this packaged up along with nextcloud server. 
I think the client will be much easier to start with so I am going to begin 
here.

I made a separate request today on the debian-mentors list to get a repo up and 
running on salsa[1]. If you could help with that, that would be amazing.

I hope to have something to show in the next week or so.

[1] https://lists.debian.org/debian-mentors/2018/06/msg00183.html



signature.asc
Description: Message signed with OpenPGP

Bug#902251: ITP: golang-github-smira-flag -- A fork of the official "flag" package but with the flag.Value interface extended to provide a ``Get() interface{}`` method

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-smira-flag
  Version : 0.0~git20170926.695ea5e-1
  Upstream Author : Andrey Smirnov
* URL : https://github.com/smira/flag
* License : BSD-3-clause
  Programming Lang: Go
  Description : A fork of the official "flag" package but with the
flag.Value interface extended to provide a ``Get() interface{}`` method.

 flag A fork of fork of the official "flag" package but with: • the
 flag.Value interface extended to provide a Get() interface{} method,•
 method (FlagSet *) Merge to merge two non-conficting flag sets

This is needed for aptly.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#895868: closed by Lars Kruse (Re: munin-cron: Fontconfig error: failed reading config file)

[Calum Mackay]

On 23/06/2018 11:45 pm, Calum Mackay wrote:

 /usr/share/fonts/truetype/fonts-guru-extra/
 /usr/share/fonts/truetype/fonts-orya-extra/
 /usr/share/fonts/truetype/fonts-deva-extra/
 /usr/share/fonts/truetype/fonts-gujr-extra/
 /usr/share/fonts/truetype/fonts-beng-extra/


these failed to remove during the pkg removal owing to a leftover .uuid 
file within each:


dpkg: warning: fonts-beng-extra: conffile 
'/etc/fonts/conf.avail/65-0-fonts-beng-extra.conf' is not a plain file 
or symlink (= '/etc/fonts/conf.avail/65-0-fonts-beng-extra.conf')
dpkg: warning: while removing fonts-beng-extra, directory 
'/usr/share/fonts/truetype/fonts-beng-extra' not empty so not removed


$ ls -al /usr/share/fonts/truetype/fonts-beng-extra
total 12
drwxr-xr-x  2 root root 4096 Jun 23 23:35 .
drwxr-xr-x 81 root root 4096 Feb 28 22:51 ..
-rw-r--r--  1 root root   36 Apr 16 00:39 .uuid

Bug#902250: syncthing: Please update Syncthing to 0.14.48

[Giorgos Skafidas]

Package: syncthing
Version: 0.14.46+ds1-1
Severity: wishlist

Dear Maintainer,

please consider updating Syncthing to version 0.14.48.

Thank you!


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

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

Versions of packages syncthing depends on:
ii  libc6  2.27-3

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

[Guilhem Moulin]

Control: retitle -1 plain dm-crypt: crypttab's 'size=' option sets the 
device size not the key size
Control: reassign -1 cryptsetup-run
Control: tag -1 pending

Hi,

On Sat, 23 Jun 2018 at 16:31:09 -0400, skodde wrote:
> root /dev/device /path/to/key.gpg 
> cipher=aes-xts-plain64,size=256,hash=plain,initramfs,noearly,keyscript=decrypt_gnupg,discard

In fact it's not related to the ‘decrypt_gnupg’ keyscript, the
“size=256” wrongly translates to `cryptsetup --size=256`, which sets the
size of the device to 256 512-bytes sectors instead of setting the key
size.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#892275: redshift: Unable to connect to GeoClue.

[byanbyanroryan]

 ryan@pocketwee:~$ systemctl --user status redshift
● redshift.service - Redshift display colour temperature adjustment
   Loaded: loaded (/usr/lib/systemd/user/redshift.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: http://jonls.dk/redshift/
On Friday, June 22, 2018, 3:12:41 AM EDT, Ritesh Raj Sarraf 
 wrote:  
 
 On Sun, 2018-06-17 at 20:59 -0400, ryan wrote:
> GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 'redshift'
> disallowed, no
> agent for UID 1000.

Did you enable the systemd unit ?

What is the output from the below command ?
 systemctl --user status redshift


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

Bug#593940: [Pkg-dns-devel] Bug#593940: Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

[Bernhard Schmidt]

On Wed, Jan 03, 2018 at 02:35:18PM -0500, Daniel Kahn Gillmor wrote:

Hi,

> On Thu 2017-12-14 09:34:56 +0100, Ondřej Surý wrote:
> > I think that best course of action would be to wait till January and
> > fill an upstream issue in an upstream gitlab for BIND ;)
> 
> i don't see any gitlab for BIND, but i do see the RT instance over at
> https://bugs.isc.org/Public/Dist/Display.html?Name=bind9-public.
> 
> given that it's january, i've gone ahead and filed a bug report
> upstream (it doesn't seem to be visible to the public yet):
> 
>https://bugs.isc.org/Public/Bug/Display.html?id=46949

It's still not public, and I think the migration to the Gitlab tracker
is a manual process.

Would you mind filing it again at
https://gitlab.isc.org/isc-projects/bind9/issues ?

Thanks,
Bernhard

Bug#899972: bind9: apparmor profile includes local profile but does not provide it

[Bernhard Schmidt]

Control: tags -1 unreproducible

On Thu, May 24, 2018 at 10:22:11AM +0200, Laurent Bonnaud wrote:

Hi Laurent,

thanks for your report.

> Package: bind9
> Version: 1:9.11.3+dfsg-1
> Severity: normal
>
[...]
> 
> This is caused by /etc/apparmor.d/usr.sbin.named that contains this line:
> 
>   #include 
> 
> but the /etc/apparmor.d/local/usr.sbin.named file does not exist.

This is weird. The file is indeed not shipped in the package, but the
package is using dh_apparmor and the postinst code autogenerated by this
debhelper module (taken straight from the 1:9.11.3+dfsg-1 package) is

| # Automatically added by dh_apparmor/2.12-4
| aa_is_enabled() {
|if command aa-enabled >/dev/null 2>&1; then
|   # apparmor >= 2.10.95-2
|   aa-enabled --quiet 2>/dev/null
|else
|   # apparmor << 2.10.95-2
|   # (This should be removed once Debian Stretch and Ubuntu 18.04 are out.)
|   rc=0
|   aa-status --enabled 2>/dev/null || rc=$?
|   [ "$rc" = 0 ] || [ "$rc" = 2 ]
|fi
| }
| 
| if [ "$1" = "configure" ]; then
| APP_PROFILE="/etc/apparmor.d/usr.sbin.named"
| if [ -f "$APP_PROFILE" ]; then
| # Add the local/ include
| LOCAL_APP_PROFILE="/etc/apparmor.d/local/usr.sbin.named"
| 
| test -e "$LOCAL_APP_PROFILE" || {
| mkdir -p `dirname "$LOCAL_APP_PROFILE"`
| install --mode 644 /dev/null "$LOCAL_APP_PROFILE"
| }
| 
| # Reload the profile, including any abstraction updates
| if aa_is_enabled; then
| apparmor_parser -r -T -W "$APP_PROFILE" || true
| fi
| fi
| fi
| # End automatically added section

So an empty file should be installed in that location when it is
missing.

This worked in my testsystem. I wonder what's going on on your system.

Bernhard

Bug#901391: wpolish: Convert dictionaries-common file to UTF-8

[Robert Luberda]

Pander pisze:

Hi,

> Why is this package depending on the perl package? I see no reason.


The dependency is added by dh_perl due to debconf's config script put
into binary package by dictionary-common-dev.

Regards,
robert

Bug#902246: (no subject)

[Timothy Pearson]

This was actually a bug in mesa.  See
https://bugs.freedesktop.org/show_bug.cgi?id=107012

Bug#902247: Acknowledgement (glxgears crashes with SIGSEGV on ppc64el with amdgpu graphics)

[Timothy Pearson]

This is actually a bug in mesa.  See
https://bugs.freedesktop.org/show_bug.cgi?id=107012 .

Bug#901545: siggen: ignores config files

[Jacek Sobczak]

Hi Thorsten,

Thank you for the hint. It looks like the keywords must be in lowercase.

Jacek
On Sat, 23 Jun 2018 at 15:13, Thorsten Alteholz  wrote:
>
> Hi Jacek,
>
> On Thu, 14 Jun 2018, Jacek Sobczak wrote:
> > The siggen set of programs ignore (do not read?) config files
> > /etc/siggen.conf, $HOME/.siggen.conf, ./.siggen.conf.
>
> hmm, no it does try to read those files.
>
> Maybe the documentation is not the best. Did you try to use only lowercase
> characters in your keywords?
>
>Thorsten
>

Bug#902248: linux-image-4.16.0-2-amd64: General protection fault (with nvidia driver) redulting in Xork proces hanging in "D" state

[Bastian Blank]

Control: reassign -1 src:nvidia-graphics-drivers
Control: forcemerge 901990 -1

On Sat, Jun 23, 2018 at 11:15:07PM +0200, Lukasz Miller wrote:
> After booting new kernel after the upgrade the system came up with blank 
> screen (initial console boot messages were visible,
> but around the time display manager should load the screen went blank). I 
> could not switch local consoles.
> After logging in remotely i have discovered Xorg process hanging in a "D" 
> state. Searching the kernel logs 
> I have found the messages below in kern.log. The Nvidia binary driver version 
> (built by DKMS) is 390.59.

This have been already submitted.

Bastian

Bug#902249: Pull tarballs from the archive (or upstream location)

[Michael Biebl]

Package: git-buildpackage
Version: 0.9.9
Severity: wishlist

Hi,

I recently ran into a bug in pristine-tar [1], which means at least for
the systemd package we can no longer use pristine-tar for the time
being.

Imho it would be really useful  if gbp in the absence of pristine-tar,
would pull the tarball from the Debian archive or the upstream location
instead of generating an orig.tar.gz on the fly (which most likely will
not have the same md5sum as the one currently in the archive).

E.g. I have now explicitly turned off pristine-tar in gbp.conf for
systemd, and if I have removed the orig.tar.gz from my build/tarball
directory, so now I get:

$ gbp buildpackage
gbp:info: Tarballs 'systemd_239.orig.tar.gz' not found at '../tarballs/'
gbp:info: Creating systemd_239.orig.tar.gz from 'upstream/239'

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902115
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.3
ii  git1:2.18.0-1
ii  man-db 2.8.3-2
ii  python33.6.5-3
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  39.2.0-1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.87+b1
ii  pbuilder  0.229.3
ii  pristine-tar  1.44
ii  python3-requests  2.18.4-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.23-1
ii  unzip6.0-21

-- no debconf information

Bug#902248: linux-image-4.16.0-2-amd64: General protection fault (with nvidia driver) redulting in Xork proces hanging in "D" state

[Lukasz Miller]

Package: src:linux
Version: 4.16.16-2
Severity: important

Dear Maintainer,

After booting new kernel after the upgrade the system came up with blank screen 
(initial console boot messages were visible,
but around the time display manager should load the screen went blank). I could 
not switch local consoles.
After logging in remotely i have discovered Xorg process hanging in a "D" 
state. Searching the kernel logs 
I have found the messages below in kern.log. The Nvidia binary driver version 
(built by DKMS) is 390.59.
--- cut ---
Jun 23 22:43:39 sid kernel: [  810.244238] [ cut here ]
Jun 23 22:43:39 sid kernel: [  810.244238] kernel BUG at 
/build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!
Jun 23 22:43:39 sid kernel: [  810.244242] invalid opcode:  [#1] SMP PTI
Jun 23 22:43:39 sid kernel: [  810.244243] Modules linked in: nvidia_drm(PO) 
nvidia_modeset(PO) nvidia(PO) ctr ccm devlink ebtable_filter ebtables 
ip6table_filter ip6_tables iptable_filte
r bnep cpufreq_userspace cpufreq_conservative cpufreq_powersave binfmt_misc 
nls_ascii nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support mxm_wmi intel_rapl 
x86_pkg_temp_thermal intel_powercl
amp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul efi_pstore 
ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf arc4 btusb btrtl 
btbcm btintel pcspkr efivars bluetooth 
ath9k ath9k_common drbg snd_virtuoso snd_oxygen_lib ath9k_hw snd_mpu401_uart 
ath snd_rawmidi ansi_cprng snd_seq_device snd_pcm_oss mac80211 snd_mixer_oss 
snd_pcm evdev joydev snd_timer cf
g80211 snd soundcore ecdh_generic mei_me lpc_ich mei sg rfkill shpchp wmi 
coretemp f71882fg
Jun 23 22:43:39 sid kernel: [  810.244271]  video button parport_pc ppdev lp 
parport sunrpc efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
fscrypto ecb raid10 raid456 async_r
aid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c 
crc32c_generic raid1 raid0 multipath linear md_mod drm_kms_helper drm 
ata_generic sd_mod hid_logitech_hidpp hid_
logitech_dj hid_generic usbhid hid uas usb_storage crc32c_intel ahci libahci 
ipmi_devintf ipmi_msghandler aesni_intel ata_piix xhci_pci aes_x86_64 
crypto_simd cryptd glue_helper ehci_pci 
xhci_hcd ehci_hcd libata i2c_i801 r8169 scsi_mod mii usbcore usb_common fan 
thermal [last unloaded: nvidia]
Jun 23 22:43:39 sid kernel: [  810.244296] CPU: 2 PID: 17283 Comm: Xorg 
Tainted: P   O 4.16.0-2-amd64 #1 Debian 4.16.16-2
Jun 23 22:43:39 sid kernel: [  810.244297] Hardware name: MSI MS-7681/P67A-GD55 
(MS-7681), BIOS V4.3 01/09/2013
Jun 23 22:43:39 sid kernel: [  810.244301] RIP: 0010:usercopy_abort+0x69/0x80
Jun 23 22:43:39 sid kernel: [  810.244302] RSP: 0018:971d4237bb50 EFLAGS: 
00010282
Jun 23 22:43:39 sid kernel: [  810.244303] RAX: 006f RBX: 
0003 RCX: 
Jun 23 22:43:39 sid kernel: [  810.244304] RDX:  RSI: 
8bd35ed16738 RDI: 8bd35ed16738
Jun 23 22:43:39 sid kernel: [  810.244305] RBP: 0003 R08: 
03ba R09: 0004
Jun 23 22:43:39 sid kernel: [  810.244306] R10: a7277e48 R11: 
a79a8dcd R12: 0001
Jun 23 22:43:39 sid kernel: [  810.244307] R13: 8bd34b895cb3 R14: 
 R15: 8bd34b895cf8
Jun 23 22:43:39 sid kernel: [  810.244308] FS:  7f30a422e6c0() 
GS:8bd35ed0() knlGS:
Jun 23 22:43:39 sid kernel: [  810.244309] CS:  0010 DS:  ES:  CR0: 
80050033
Jun 23 22:43:39 sid kernel: [  810.244310] CR2: 7f309cbf5068 CR3: 
00020cae0005 CR4: 000606e0
Jun 23 22:43:39 sid kernel: [  810.244311] Call Trace:
Jun 23 22:43:39 sid kernel: [  810.244316]  __check_heap_object+0xe7/0x120
Jun 23 22:43:39 sid kernel: [  810.244318]  __check_object_size+0x9c/0x1a0
Jun 23 22:43:39 sid kernel: [  810.244429]  os_memcpy_to_user+0x21/0x40 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.244542]  _nv009383rm+0xbf/0xe0 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.244637]  ? _nv028084rm+0x79/0x90 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.244730]  ? _nv028084rm+0x55/0x90 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.244818]  ? _nv013694rm+0xee/0x100 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.244905]  ? _nv015342rm+0x154/0x270 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245017]  ? _nv008316rm+0x134/0x1a0 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245128]  ? _nv008295rm+0x29c/0x2b0 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245238]  ? _nv001072rm+0xe/0x20 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245349]  ? _nv007322rm+0xd8/0x100 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245457]  ? _nv001171rm+0x627/0x830 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245566]  ? rm_ioctl+0x73/0x100 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245625]  ? nvidia_ioctl+0xb0/0x720 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245684]  ? nvidia_ioctl+0x573/0x720 [nvidia]
Jun 23 22:43:39 sid kernel: [  810.245742]  ? 

Bug#902247: glxgears crashes with SIGSEGV on ppc64el with amdgpu graphics

[Timothy Pearson]

Package: mesa-utils
Version: 8.4.0-1

glxgears crashes immediately on startup using the amdgpu drivers.  Other
3D applications, including complex ones like rss-glx, openarena, and
supertux, work fine.

Package xserver-xorg-video-amdgpu is version 18.0.1-1.  Kernel is 4.18
staging.

Backtrace:

> Thread 9 (Thread 0x7fffe9fbf160 (LWP 4797)):
> #0  0x72ae5ec4 in llvm::Value::getContext() const () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #1  0x72ae7db8 in llvm::Value::setNameImpl(llvm::Twine const&) () 
> from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #2  0x72ae8140 in llvm::Value::setName(llvm::Twine const&) () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #3  0x72a67b60 in 
> llvm::ExtractValueInst::init(llvm::ArrayRef, llvm::Twine 
> const&) () from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #4  0x729ee6f0 in LLVMBuildExtractValue () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #5  0x769bb2e4 in si_build_ps_prolog_function (ctx=0x7fffe9fb9e80, 
> key=0x7fffe9fbe152) at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7722
> #6  0x769bf8c8 in si_get_shader_part (sscreen=0x100104f00, 
> list=0x100105448, type=PIPE_SHADER_FRAGMENT, prolog=true, key=0x7fffe9fbe152, 
> tm=0x1000aca60, debug=0x7fffc80adc68, build=0x769bab40 
> ,
> name=0x76bb8420 "Fragment Shader Prolog") at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7154
> #7  0x769c25c0 in si_shader_select_ps_parts (debug=0x7fffc80adc68, 
> shader=0x7fffc80adc60, tm=0x1000aca60, sscreen=0x100104f00) at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7924
> #8  si_shader_create (sscreen=0x100104f00, tm=0x1000aca60, 
> shader=0x7fffc80adc60, debug=0x7fffc80adc68) at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:8114
> #9  0x769e21b0 in si_build_shader_variant (shader=0x7fffc80adc60, 
> thread_index=, low_priority=) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1510
> #10 0x769e4fdc in si_shader_select_with_key (thread_index=-1, 
> key=0x7fffe9fbe2ae, compiler_state=0x7fffe9fbe420, state=0x100063fb0, 
> sscreen=0x100104f00) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1772
> #11 si_shader_select (ctx=0x100063350, state=0x100063fb0, 
> compiler_state=0x7fffe9fbe420) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1790
> #12 0x769e5c28 in si_update_shaders (sctx=0x100063350) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:3242
> #13 0x769de2a0 in si_draw_vbo (ctx=0x100063350, info=0x1000adf48) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_draw.c:1331
> #14 0x766913e8 in tc_call_draw_vbo (pipe=, 
> payload=) at 
> ../../../../src/gallium/auxiliary/util/u_threaded_context.c:2012
> #15 0x7668ae04 in tc_batch_execute (job=0x1000adc50, 
> thread_index=) at 
> ../../../../src/gallium/auxiliary/util/u_threaded_context.c:96
> #16 0x76488be8 in util_queue_thread_func (input=) at 
> ../../../src/util/u_queue.c:271
> #17 0x76488690 in impl_thrd_routine (p=) at 
> ../../../include/c11/threads_posix.h:87
> #18 0x773e86d8 in start_thread (arg=0x0) at pthread_create.c:463
> #19 0x77963f48 in clone () at 
> ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:82
> 
> Thread 8 (Thread 0x7fffea7cf160 (LWP 4796)):
> #0  0x773f1a0c in futex_wait_cancelable (private=, 
> expected=0, futex_word=0x200) at 
> ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0x1001055c8, 
> cond=0x1001055f0) at pthread_cond_wait.c:502
> #2  __pthread_cond_wait (cond=0x1001055f0, mutex=0x1001055c8) at 
> pthread_cond_wait.c:655
> #3  0x77977b14 in __pthread_cond_wait (cond=, 
> mutex=) at forward.c:149
> #4  0x76488b3c in cnd_wait (mtx=0x1001055c8, cond=0x1001055f0) at 
> ../../../include/c11/threads_posix.h:155
> #5  util_queue_thread_func (input=) at 
> ../../../src/util/u_queue.c:255
> #6  0x76488690 in impl_thrd_routine (p=) at 
> ../../../include/c11/threads_posix.h:87
> #7  0x773e86d8 in start_thread (arg=0x0) at pthread_create.c:463
> #8  0x77963f48 in clone () at 
> ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:82
> 
> Thread 7 (Thread 0x7fffeafdf160 (LWP 4795)):
> #0  0x773f1a0c in futex_wait_cancelable (private=, 
> expected=0, futex_word=0x200) at 
> ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0x1001055c8, 
> cond=0x1001055f0) at pthread_cond_wait.c:502
> #2  __pthread_cond_wait (cond=0x1001055f0, mutex=0x1001055c8) at 
> pthread_cond_wait.c:655
> #3  0x77977b14 in __pthread_cond_wait (cond=, 
> mutex=) at forward.c:149
> #4  0x76488b3c in cnd_wait (mtx=0x1001055c8, cond=0x1001055f0) at 
> ../../../include/c11/threads_posix.h:155
> #5  

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

[skodde]

Hi,

Sorry, the body was missing in the original message.

I've been using the following line in crypttab to unlock the root
volume in initrd and it's been working till version 2:2.0.2-1
included:


/etc/crypttab

root/dev/device /path/to/key.gpg
cipher=aes-xts-plain64,size=256,hash=plain,initramfs,noearly,keyscript=decrypt_gnupg,discard


With the current version (2:2.0.3-3) the volume is created with the
wrong size (256 blocks) and no filesystem is recognized, halting the
boot process.

If I recreate it manually in the initramfs emergency shell, then it
works as expected:


/lib/cryptsetup/scripts/decrypt_gnupg /path/to/key.gpg | cryptsetup -c
aes-xts-plain64 -d /dev/stdin -s 256 --allow-discards create root
/dev/device


I've also tried different values of hash= in crypttab, to mimic the
default cryptsetup behavior of not hashing the key when specified with
the -d option and creating a plain dm_crypt volume, without success.
Other values will not create the volume at all, as opposed to "plain"
which creates the wrong size volume.


Thanks

Bug#890881: Still no submitted patches applied

[Svante Signell]

PING!!!

Bug#901985: jpeginfo FTCBFS: configures for the build architecture

[Ola Lundqvist]

Thank you for the report. I'll consider this for next upload. Please note
that the package is very rarely updated so this may take some time.
And of course thank you for the patch.

Best regards

// Ola

On 21 June 2018 at 05:56, Helmut Grohne  wrote:

> Source: jpeginfo
> Version: 1.6.0-6
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> jpeginfo fails to cross build from source, because it configures for the
> build architecture. Using dh_auto_build does not fix that, because
> jpeginfo's ./configure is so old that it doesn't understand --host.
> Rather it needs a suitable CC exported. After doing so, jpeginfo cross
> builds succesfully. Please consider applying the attached patch.
>
> Helmut
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#895718: python-pyqt5: import PyQt5.QtCore fails

[Jürgen E . Fischer]

Hi,

my pbuilder workaround for this /var/cache/pbuilder/hooks/A01qt5stripabitag:

for i in /usr/lib/*-linux-gnu/libQt5Core.so.5.10.1; do
[ -f "$i" ] && strip --remove-section=.note.ABI-tag "$i"
done


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de


signature.asc
Description: PGP signature

Bug#902246: alien-arena crashes with SIGSEGV on ppc64el with amdgpu graphics

[Timothy Pearson]

Package: alien-arena
Version: 7.66+dfsg-5

When alien-arena loads a map, right before the gameplay starts, we get a
SIGSEGV and the game quits:

> Thread 1 "alienarena" received signal SIGSEGV, Segmentation fault.
> 0x71ba5ec4 in llvm::Value::getContext() const () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> (gdb) bt
> #0  0x71ba5ec4 in llvm::Value::getContext() const () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #1  0x71ba7db8 in llvm::Value::setNameImpl(llvm::Twine const&) () 
> from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #2  0x71ba8140 in llvm::Value::setName(llvm::Twine const&) () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #3  0x71b27b60 in 
> llvm::ExtractValueInst::init(llvm::ArrayRef, llvm::Twine 
> const&) () from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #4  0x71aae6f0 in LLVMBuildExtractValue () from 
> /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1
> #5  0x75a7b2e4 in si_build_ps_prolog_function (ctx=0x7fffa120, 
> key=0x7fffe3f2) at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7722
> #6  0x75a7f8c8 in si_get_shader_part (sscreen=0x10b67dbc0, 
> list=0x10b67e108, type=PIPE_SHADER_FRAGMENT, prolog=true, key=0x7fffe3f2, 
> tm=0x10b635f80, debug=0x10c7050a8, build=0x75a7ab40 
> ,
> name=0x75c78420 "Fragment Shader Prolog") at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7154
> #7  0x75a825c0 in si_shader_select_ps_parts (debug=0x10c7050a8, 
> shader=0x10c7050a0, tm=0x10b635f80, sscreen=0x10b67dbc0) at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7924
> #8  si_shader_create (sscreen=0x10b67dbc0, tm=0x10b635f80, 
> shader=0x10c7050a0, debug=0x10c7050a8) at 
> ../../../../../src/gallium/drivers/radeonsi/si_shader.c:8114
> #9  0x75aa21b0 in si_build_shader_variant (shader=0x10c7050a0, 
> thread_index=, low_priority=) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1510
> #10 0x75aa4fdc in si_shader_select_with_key (thread_index=-1, 
> key=0x7fffe54e, compiler_state=0x7fffe6c0, state=0x10b5ed490, 
> sscreen=0x10b67dbc0) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1772
> #11 si_shader_select (ctx=0x10b5ec830, state=0x10b5ed490, 
> compiler_state=0x7fffe6c0) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1790
> #12 0x75aa5c28 in si_update_shaders (sctx=0x10b5ec830) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:3242
> #13 0x75a9e2a0 in si_draw_vbo (ctx=0x10b5ec830, info=0x10b6372e8) at 
> ../../../../../src/gallium/drivers/radeonsi/si_state_draw.c:1331
> #14 0x757513e8 in tc_call_draw_vbo (pipe=, 
> payload=) at 
> ../../../../src/gallium/auxiliary/util/u_threaded_context.c:2012
> #15 0x7574e134 in tc_batch_execute (thread_index=0, job= out>) at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:96
> #16 _tc_sync (tc=0x10b636bd0, func=, info=) at 
> ../../../../src/gallium/auxiliary/util/u_threaded_context.c:207
> #17 0x75752468 in tc_texture_subdata (_pipe=0x10b636bd0, 
> resource=0x10c704890, level=, usage=, 
> box=0x7fffea50, data=0x10ca68650, stride=, 
> layer_stride=)
> at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:1717
> #18 0x75423a30 in st_TexSubImage (ctx=0x10b75ef60, dims=2, 
> texImage=0x10c70d300, xoffset=0, yoffset=, zoffset= out>, width=, height=, depth=,
> format=, type=, pixels=, 
> unpack=) at 
> ../../../src/mesa/state_tracker/st_cb_texture.c:1434
> #19 0x75425d14 in st_TexImage (ctx=0x10b75ef60, dims=, 
> texImage=0x10c70d300, format=, type=, 
> pixels=0x10ca68650, unpack=0x10b7684e8)
> at ../../../src/mesa/state_tracker/st_cb_texture.c:1651
> #20 0x75386f40 in teximage (no_error=false, pixels=0x10ca68650, 
> imageSize=0, type=5121, format=6408, border=0, depth=, 
> height=, width=, internalFormat=4, level=0, 
> target=3553,
> dims=2, compressed=0 '\000', ctx=0x10b75ef60) at 
> ../../../src/mesa/main/teximage.c:3101
> #21 teximage_err (ctx=0x10b75ef60, compressed=0 '\000', dims=2, 
> target=, level=, internalFormat= out>, width=, height=, depth=1, border=0, 
> format=6408, type=5121,
> imageSize=0, pixels=0x10ca68650) at ../../../src/mesa/main/teximage.c:3128
> #22 0x75388e9c in _mesa_TexImage2D (target=, 
> level=, internalFormat=, width=, 
> height=, border=, format=,
> type=, pixels=0x10ca68650) at 
> ../../../src/mesa/main/teximage.c:3166
> #23 0x0001000970b4 in ?? ()
> #24 0x000100097a9c in ?? ()
> #25 0x0001000987fc in ?? ()
> #26 0x0001000cbeec in ?? ()
> #27 0x0001000a4a5c in ?? ()
> #28 0x0001000a6624 in ?? ()
> #29 0x0001000a6998 in ?? ()
> #30 0x00010004a564 in ?? ()
> #31 0x000100043014 in ?? ()
> #32 0x000100036678 in ?? ()
> #33 0x000100083b50 in ?? ()
> #34 0x000100012778 in ?? ()
> #35 

Bug#902183: cryptsetup-initramfs: "ERROR: Couldn't find sysfs hierarchy for /dev/sda1"

[Guilhem Moulin]

On Sat, 23 Jun 2018 at 20:41:34 +0100, Chris Lamb wrote:
>> Nope, removing 'cryptsetup-initramfs' was the right thing to do since
>> you don't need to unlock anything at initramfs stage.
> 
> Out of interest, assuming I *did* actually use cryptsetup (!) would it
> have resulted an unbootable system? :)

Depends, the cryptsetup binaries wouldn't have been included to the
initramfs image, but if the root device isn't encrypted then it's always
possible to setup a chroot manually and run the “real” cryptsetup
binary.  (Assuming ‘cryptsetup-bin’ is installed, of course.)  That
being said, it's a bit strange to have devices that need to be present
that early in the boot process (typically the resume device, or the
device holding /usr; OTOH /home doesn't need to be present that early)
when the root device itself isn't encrypted…

Also, on systems with encrypted devices that need to be unlocked at
initramfs stage, `update-initramfs -u` doesn't suggest to remove
‘cryptsetup-initramfs’.  But perhaps we should ship a prerm script
warning the user that removing the package was a terrible idea, and that
they should most likely reinstall it before trying to reboot :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#902244: matplotlib: please remove armhf and riscv64 from the non-pandas architectures

[Adrian Bunk]

Source: matplotlib
Version: 2.2.2-4
Severity: normal

pandas is now available on armhf (sic) and riscv64,
please update the build dependencies accordingly.

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

[skodde]

Package: cryptsetup
Version: 2:2.0.2-1
Severity: important

/tmp/reportbug-cryptsetup-20180623-4415-imdw6ns_

-- Package-specific info:

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

Kernel: Linux 4.17.0-trunk-amd64 (SMP w/16 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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:2.0.2-1
ii  debconf [debconf-2.0]  1.5.67
ii  dmsetup2:1.02.145-4.1
ii  libc6  2.27-3

Versions of packages cryptsetup recommends:
ii  busybox 1:1.27.2-2
ii  console-setup   1.184
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kbd 2.0.4-3

Versions of packages cryptsetup suggests:
ii  dosfstools  4.1-2
pn  keyutils
ii  liblocale-gettext-perl  1.07-3+b3

-- debconf information excluded

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Sean Whitton]

[trimming CC]

Hello Simon,

On Thu, Jun 14 2018, Simon McVittie wrote:

> I've prepared patches for this, which are available here:
> https://salsa.debian.org/smcv/policy/merge_requests/1/diffs
>
> I've attached them here, except for the patch that replaces the bundled
> copy of FHS v2.3 with a bundled copy of FHS v3.0, which is inconveniently
> large.

Many thanks for this work.

>I think patch 0002 is the only normative one?

Yes, we need discuss only the patch that touches 9.1.1.

I have reviewed all the upstream commits between FHS 2.3 and FHS 3.0[1]
and I think your patch captures them, except:

1.  FHS 3.0 allows distributions to create directory hierarchies under
user's home directories conforming to the XDG Base Directories or
the GLib conventions on user directory contents.

We don't permit packages to install to home directories or
maintscripts to touch home directories, so maybe we need to add an
exception saying that packages can't actually do this (of course,
programs installed by those packages can do it).

2. The requirement for amd64 libraries to be installed to /lib64 have
   been removed, so we can drop/reword our exception for that (point 3 in
   9.1.1 in current Policy)

3. We are violating the new requirements that /usr/local/share/color
   must exist if /usr/share/color exists.  I guess we just need to file
   a bug after policy is updated.

> The only thing I found that would make Debian non-compliant is the
> fact that the /usr/bin/mh/ directory used to be allowed, but is not
> allowed any more. For the moment I think this should be documented as a
> departure from FHS v3.0, and if anyone cares enough about removing that
> exception, it should be discussed with the maintainers of nmh (which ships
> /usr/bin/mh/) and mailutils-mh (which is technically non-Policy-compliant,
> although does comply with the spirit of the policy) on a separate bug.

Yes, adding an exception makes sense.

Inline questions & suggestions:

> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 7d85c00..b18e2c2 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -12,7 +12,7 @@ File System Structure
>  ~
>
>  The location of all files and directories must comply with the
> -Filesystem Hierarchy Standard (FHS), version 2.3, with the exceptions
> +Filesystem Hierarchy Standard (FHS), version 3.0, with the exceptions
>  noted below, and except where doing so would violate other terms of
>  Debian Policy. The following exceptions to the FHS apply:
>
> @@ -76,25 +76,20 @@ Debian Policy. The following exceptions to the FHS apply:
>  ``/etc``, or at least are symlinked there, is relaxed to a
>  recommendation.
>
> -8.  The additional directory ``/run`` in the root file system is
> -allowed. ``/run`` replaces ``/var/run``, and the subdirectory
> -``/run/lock`` replaces ``/var/lock``, with the ``/var`` directories
> -replaced by symlinks for backwards compatibility. ``/run`` and
> -``/run/lock`` must follow all of the requirements in the FHS for
> -``/var/run`` and ``/var/lock``, respectively, such as file naming
> -conventions, file format requirements, or the requirement that files
> -be cleared during the boot process. Files and directories residing
> -in ``/run`` should be stored on a temporary file system.
> +8.  The ``/var/run`` and ``/var/lock`` directories are required to be
> +made equivalent to ``/run`` and ``/run/lock`` respectively, for
> +example using symbolic links or bind-mounts.

The change here is not just to update to FHS 3.0 but also to allow bind
mounting instead of symlinking, and indeed to allow any other way of
making them "equivalent".  The previous version of the text required
symlinking.  And FHS 3.0 only explicitly mentions symlinking.

Can you say why you made this change?  If this is not trivial we should
probably do it in a separate bug.

I am also a little uncomfortable with the use of 'equivalent' without a
definition.  If you wrote "equivalent, i.e. using symbolic links or
bind-mounts" there would be an implicit definition of 'equivalent' and
that would be better, but would of course restrict how the directories
may be made equivalent.

> +11. The requirement for there to be no subdirectories in ``/usr/bin``
> +is relaxed to allow the ``mh`` mail-handling suite to create
> +``/usr/bin/mh/``, as was allowed in FHS version 2.3.

I think this needs to be worded more strongly so that it is clear that
the mh case is the /only/ exception.

[1]  I did this by:

% apt-get install git-remote-bzr
% git clone bzr::http://bzr.linuxfoundation.org/lsb/devel/fhs-spec

and then look at every commit after the first, which imports FHS 2.3.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#902228: ITP: ffcvt -- ffmpeg convert wrapper tool

[Adam Borowski]

On Sat, Jun 23, 2018 at 03:22:48PM -0400, Tong Sun wrote:
> On Sat, Jun 23, 2018 at 3:06 PM Adam Borowski wrote:
> > So it would be a much better idea to use VP9 rather than HEVC in your tool.
> 
> Oh, glad to know. Thanks for the input -- I didn't know.
> 
> As long as VP9 is now supported by ffmepg, I'd be happy to add that in
> and switch it as the default.
> 
> Could you share how you are doing the trancoding with VP9 + Opus, the
> ffmepg command line, please?

Alas, I hardly ever transcode video files, thus can't meaningfully help you
there.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄ go back and forth wrt their intended target.

Bug#902243: Additional reason for request

[Charles Curley]

3.17 has a new API version number, meaning changes in the protocol.
While the new API *should* be transparent to clients, client developers
might care to test their clients.

-- 
"When we talk of civilization, we are too apt to limit the meaning of
the word to its mere embellishments, such as arts and sciences; but
the true distinction between it and barbarism is, that the one
presents a state of society under the protection of just and
well-administered law, and the other is left to the chance government
of brute force."
- The Rev. James White, Eighteen Christian Centuries, 1889
Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
https://charlescurley.com

Bug#902183: cryptsetup-initramfs: "ERROR: Couldn't find sysfs hierarchy for /dev/sda1"

[Chris Lamb]

Hi Guilhem,

> My commit from yesterday to make cryptsetup ≥2:2.0.3-2 work with d-i is
> also fixing this :-)
> 
> https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/8ea400db2e146ee9e4a0f475f9353bf87201d1f3

Ah, neat!

> > Anything I should be concerned with?
> 
> Nope, removing 'cryptsetup-initramfs' was the right thing to do since
> you don't need to unlock anything at initramfs stage.

Out of interest, assuming I *did* actually use cryptsetup (!) would it
have resulted an unbootable system? :)


Regards,

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

Bug#902228: ITP: ffcvt -- ffmpeg convert wrapper tool

[Tong Sun]

On Sat, Jun 23, 2018 at 3:06 PM Adam Borowski wrote:

> So it would be a much better idea to use VP9 rather than HEVC in your tool.

Oh, glad to know. Thanks for the input -- I didn't know.

As long as VP9 is now supported by ffmepg, I'd be happy to add that in
and switch it as the default.

Could you share how you are doing the trancoding with VP9 + Opus, the
ffmepg command line, please?

Thx

Bug#902233: [zfs-dkms]

[Antonio Russo]

Control: tag -1 patch

During deb package build, a pristine copy of the source is included
in the dkms package. We try to to strip everything except the files
needed to build the kernel modules.

The dpkg-architecture call is part of the ZFS_AC_PACKAGE macro, which
upstream ships to produce packages. This is obviously unnecessary in
the Debian dkms source.

Part of my cleanup [1] removes the call to that macro, and should
remove the need for dpkg-architecture.

That MR includes a few other fixes, hopefully all of them can be
merged soon.

Antonio

[1] https://salsa.debian.org/zfsonlinux-team/zfs/merge_requests/9

Bug#902243: gpsd 3.17 in stretch backports?

[Charles Curley]

Package: gpsd
Version: 3.16-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

gpsd 3.17-5+b1 is available for buster and sid. Any chance you could
make it available for stretch backports? I maintain a client for gpsd,
and would like to be able to test it against 3.17 without compiling
and installing from git head and without running testing or unstable
on production machines.

Thanks!


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

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

Versions of packages gpsd depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libbluetooth35.43-2+deb9u1
ii  libc62.24-11+deb9u3
ii  libdbus-1-3  1.10.26-0+deb9u1
pn  libgps22 
ii  libusb-1.0-0 2:1.0.21-1
ii  lsb-base 9.20161125
ii  netbase  5.4
ii  systemd-sysv 232-25+deb9u3

Versions of packages gpsd recommends:
ii  python  2.7.13-2
ii  udev237-3~bpo9+1

Versions of packages gpsd suggests:
ii  dbus  1.10.26-0+deb9u1
pn  gpsd-clients  

Bug#902228: ITP: ffcvt -- ffmpeg convert wrapper tool

[Adam Borowski]

On Sat, Jun 23, 2018 at 11:17:00AM -0400, Tong Sun wrote:
> * Package name: ffcvt
>   Version : 1.1.0+git20170914.a6d80b5-1
>   Upstream Author : Tong Sun
> * URL : https://github.com/suntong/ffcvt
> * License : MIT
>   Programming Lang: Go
>   Description : ffmpeg convert wrapper tool
> 
>  ffcvt - ffmpeg convert wrapper to make it simple to do high efficiency 
> audio/video compression (Opus/H.265) encoding, and for youtube as well. 
>  .
>  The next-generation High Efficiency Video codec (HEVC), H.265 can produce
>  videos visually comparable to libx264's, but in about half the size;
>  Meanwhile the Opus audio codec is becoming the best thing ever for
>  compressing audio -- A 64K Opus audio stream is comparable to mp3 files of
>  128K to 256K bandwidth. The ffcvt makes use of such fantastic high
>  efficiency audio/video codec/encoding capability while shielding people
>  from the complicated ffmpeg command line option settings, while versatile
>  and powerful enough to allow advanced users to touch every corner of
>  audio/video encoding.

I wonder why you would prefer HEVC over VP9 -- both provide about the same
quality at a given stream size[1], yet HEVC has serious freeness issues: you
are not allowed to have it as a part of any software that's preinstalled on
a computer, use hardware-assisted implementations, and so on, without paying
an extra fee.

For this reason, support for VP9 is drastically more widespread than HEVC:
no idea about standalone use, but in browsers, https://caniuse.com/ says
HEVC is 8% working 6% partial, while VP9 is 75% working 4% partial.

I also wonder why you use Opus with HEVC: usually HEVC goes with AAC, while
VP9 with Opus; the list of client setups that support HEVC is nearly
identical to the list of those that don't support Opus.  And yeah, Opus is
massively better than AAC.

So it would be a much better idea to use VP9 rathern than HEVC in your tool.


Alas, AV1 is not yet mature enough -- it beats both HEVC and VP9 by around
25% even in its early state.


Meow!

[1]. Note that VP9 encoders took longer to mature than HEVC, thus older
versions of encoders shown the latter as a bit better, this difference is no
more.
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄ go back and forth wrt their intended target.

Bug#877856: mysql-utilities: Parsing MySQL version is broken

[Lev Lazinskiy]

I have been working on packaging up 1.6.5 but this will likely go into testing 
at some point and not be available in stable until buster. 

> MySQL version parser is broken in 1.6.4, fixed in 1.6.5, but doesn't
> seem to be available:
> https://dev.mysql.com/doc/mysql-utilities/1.6/en/mysql-utils-install-deb.html
> refers to 1.6.4, and:
> https://dev.mysql.com/doc/mysql-utilities/1.6/en/mysql-utils-install-source.html
> refers to 1.6.4 too.

In the meantime, you can grab a 1.6.5 package from MySQL directly here: 
https://downloads.mysql.com/archives/get/file/mysql-utilities_1.6.5-1debian8_all.deb
 

It looks like the docs were never updated, but the package exists. It is listed 
for "jessie" but it should work on "stretch" without any issues. 

One other thing to note. While I was debugging this issue, I noticed the 
following warning on the MySQL downloads page. 

"Per Oracle's Lifetime Support policy[1], as of May 30, 2018, MySQL Utilities 
is covered under Oracle Sustaining Support. Users are encouraged to migrate to 
MySQL Shell[2]."

It sounds like 1.6.5 will be the last release of this software. From my brief 
inspection MySQL shell does not really do many of the things that 
mysql-utilities does out of the box so it is not exactly a "drop in" 
replacement. 

[1] https://www.oracle.com/support/lifetime-support/index.html
[2] https://dev.mysql.com/doc/mysql-shell-excerpt/8.0/en/

Bug#902242: wnpp-check: use HTTPS

[gregor herrmann]

Package: devscripts
Version: 2.18.3
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Find attached a patch which
- - uses https for fetching the wnpp overview page
- - outputs BTS links with https


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlsulMNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYeIg//SAFElsXjRFccYnNa4kOctT2rhhHAxJHBmWcYrUB0ZA1ucq5hjSRGkpee
iydsQRI9foMe4TOfLNI8x2eO39sfAjhiyIcz7aJ0F6U9BFK2ZMfbVi+DUflhMu4v
y8idBiPcmTAbMi4E1K83Wb97NKjTUmZNRgiKIR0EPx4w6bLUMHP8VqIt3kInfF6w
WaEhqwbbQKQ570bkIY0La7yoqKuzI/o7/TPxhM8qLOOhFEK0IyBuKExlwwBhJO02
wquIIwo5FVztB3WOkqZaGevIKpN0nugQoKdqk8jL08yQAT6O+rUAUKCOwllvOpji
1jCda0fs/RykvnPbg2DRWvTdgeyjj+YmAkIs/uLj3ezUc6QPg4QvEvY4UjZm7DRE
qxoQz2bMmyw9ZaJpstWUIFGGPDk2YJ62sH4wfs+12GFSA85EiZZGlmTlY03aTw44
MZqs50ZBYk4V2szH69Z6ecDp8xbm9tQWlMqFQSIaSRIg+nNXs9Tzhyp8hHsreNcX
2kR+aP9mykOuCJPN38TgLIMMeQ+2krJP17VGmZcPdUVBoZwPxaMV/9X48AMb/smi
QvPM758VIU29kQH0bLzmiAsojMq001PeaK6J54chsi4l5JAW2PG5UPZ8WeMPonU7
OFjeHX4OVPf4/XlHxN8AZp29Slovr7hUWgInqtRfH5S/yTAldUI=
=za6R
-END PGP SIGNATURE-
--- /usr/bin/wnpp-check 2018-05-23 13:32:26.0 +0200
+++ scripts/wnpp-check.sh   2018-06-23 20:36:29.177892907 +0200
@@ -80,15 +80,15 @@
 # every line; those which succeed execute the 'p' command, those
 # which don't skip over it to the label 'd'
 
-$GETCOMMAND $WNPPTMP http://www.debian.org/devel/wnpp/being_packaged || \
-{ echo "$PROGNAME: $CURLORWGET 
http://www.debian.org/devel/wnpp/being_packaged failed." >&2; exit 1; }
+$GETCOMMAND $WNPPTMP https://www.debian.org/devel/wnpp/being_packaged || \
+{ echo "$PROGNAME: $CURLORWGET 
https://www.debian.org/devel/wnpp/being_packaged failed." >&2; exit 1; }
 sed -ne 's/.*\([^:<]*\)[: 
]*\([^<]*\)<\/a>.*/ITP \1 \2 -- \3/; T d; p; : d' $WNPPTMP > $WNPP
 
-$GETCOMMAND $WNPPTMP http://www.debian.org/devel/wnpp/requested || \
-{ echo "$PROGNAME: $CURLORWGET http://www.debian.org/devel/wnpp/requested 
failed." >&2; exit 1; }
+$GETCOMMAND $WNPPTMP https://www.debian.org/devel/wnpp/requested || \
+{ echo "$PROGNAME: $CURLORWGET https://www.debian.org/devel/wnpp/requested 
failed." >&2; exit 1; }
 sed -ne 's/.*\([^:<]*\)[: 
]*\([^<]*\)<\/a>.*/RFP \1 \2 -- \3/; T d; p; : d' $WNPPTMP >> $WNPP
 
-awk -F' ' '{print "("$1" - #"$2") http://bugs.debian.org/"$2; "$3}' $WNPP | 
sort -k 5 > $WNPP_PACKAGES
+awk -F' ' '{print "("$1" - #"$2") https://bugs.debian.org/"$2; "$3}' $WNPP | 
sort -k 5 > $WNPP_PACKAGES
 
 FOUND=0
 for pkg in $PACKAGES

Bug#902241: python-proliantutils: FTBFS in stretch (AssertionError: IloConnectionError not raised)

[Santiago Vila]

Package: src:python-proliantutils
Version: 2.1.11-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in stretch and it failed:


[...]
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_asks_not_to_upload_firmware_file
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_asks_not_to_upload_firmware_file
 ... ok
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_asks_to_upload_firmware_file
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_asks_to_upload_firmware_file
 ... ok
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_calls_extract_of_fw_extractor_object
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_calls_extract_of_fw_extractor_object
 ... ok
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_throws_for_failed_extraction
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_throws_for_failed_extraction
 ... ok
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_throws_for_unknown_firmware_file_format
proliantutils.tests.test_utils.UtilsTestCase.test_process_firmware_image_throws_for_unknown_firmware_file_format
 ... ok

==
FAIL: 
proliantutils.tests.ilo.test_firmware_controller.FirmwareImageUploaderTestCase.test__get_socket_throws_exception_in_case_of_failed_connection_2
proliantutils.tests.ilo.test_firmware_controller.FirmwareImageUploaderTestCase.test__get_socket_throws_exception_in_case_of_failed_connection_2
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ddt.py", line 129, in wrapper
return func(self, *args, **kwargs)
  File "proliantutils/tests/ilo/test_firmware_controller.py", line 566, in 
test__get_socket_throws_exception_in_case_of_failed_connection
self.assertRaises(expected_exception_type, fw_img_uploader._get_socket)
  File "/usr/lib/python2.7/unittest/case.py", line 473, in assertRaises
callableObj(*args, **kwargs)
  File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
"{0} not raised".format(exc_name))
AssertionError: IloConnectionError not raised


--
Ran 473 tests in 5.071s

FAILED (failures=1)
debian/rules:14: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


I admit this is strange because it seems to build ok in the
reproducible builds autobuilders.

However, I've decided to report it anyway because I've tried to build
it 55 times and it failed 55 times, on 23 different autobuilders:

https://people.debian.org/~sanvila/build-logs/python-proliantutils/

I can even reproduce it with plain dpkg-buildpackage (i.e. without sbuild)
on a brand new machine from Digital Ocean, so if you could not reproduce
this, please contact me privately. As a last resort, I could give you
access to one of such machines.

Thanks.

Bug#902240: html-xml-utils: don't Build-Depends: man2html

[Helmut Grohne]

Source: html-xml-utils
Version: 7.7-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

html-xml-utils Build-Depends on man2html. This is a meta package that
pulls in apache2 and a lot more stuff that html-xml-utils doesn't need.
For just running man2html, the dependency should be "man2html-base". I
used reproducible builds to verify that demoting the dependency does not
change package contents. Please consider applying the attached patch.

The man2html dependency happens to break cross compilation.

Helmut
diff --minimal -Nru html-xml-utils-7.7/debian/changelog 
html-xml-utils-7.7/debian/changelog
--- html-xml-utils-7.7/debian/changelog 2018-05-02 08:23:36.0 +0200
+++ html-xml-utils-7.7/debian/changelog 2018-06-23 20:27:52.0 +0200
@@ -1,3 +1,10 @@
+html-xml-utils (7.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote Build-Depends: man2html to man2html-base. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 23 Jun 2018 20:27:52 +0200
+
 html-xml-utils (7.7-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru html-xml-utils-7.7/debian/control 
html-xml-utils-7.7/debian/control
--- html-xml-utils-7.7/debian/control   2018-05-02 08:23:36.0 +0200
+++ html-xml-utils-7.7/debian/control   2018-06-23 20:27:52.0 +0200
@@ -8,7 +8,7 @@
gperf,
libcurl4-gnutls-dev (>> 7.9.7) | libcurl-dev (>> 7.9.7),
libidn2-0-dev,
-   man2html,
+   man2html-base,
netcat-openbsd
 Standards-Version: 4.1.4
 Homepage: https://www.w3.org/Tools/HTML-XML-utils/

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

On 2018-06-02 10:07-0700 Alan W. Irwin wrote:


The propagation of kernel 4.16.12 from Sid to Buster has greatly
improved this situation, i.e., no lock ups so far (uptime approaching
3 days since I switched to 4.16.12 from 4.16.5) and may have
completely solved it. [...]


Well, further experience showed lockups occurred roughly as often for
4.16.12 as for 4.16.5.  So currently I am only able to use this
computer in a reliable way using an X-terminal (an alternate computer
with a different X server that runs "X -query "
to control and display remote desktop results that are running on this
computer).

Therefore I plan to wait for kernel 4.17.x (which apparently has many
graphics fixes for modern AMD cards such as the RX 550) to propagate
to Buster before I try this computer again with a local X server,
i.e., direct use rather than X-terminal use.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#902235: thunderbird: Freezes X on startup reproducibly

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> Will try. It at least prevent the freezes, but now I get "Your
> Thunderbird profile cannot be loaded. It may be missing or
> inaccessible." Might stem from hard rebooting the machine when it
> happened the first time.
> 
> And I still get that "Error: Access was denied while trying to open
> files in your profile directory."

This is #882218. Because as author of unburden-home-dir, I of course
use it. :-)

*sigh*

This helped:

~ # aa-disable =thunderbird
Disabling /usr/bin/thunderbird.

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

Bug#902238: lua5.3: arithmetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Attached script demonstrates the bug.

__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__--[[
Displays Greek letters and mathematically interesting Unicode ranges

Copyright (C) 2009  Werner Smekal

This file is part of PLplot.

PLplot is free software you can redistribute it and/or modify
it under the terms of the GNU Library General Public License as published
by the Free Software Foundation either version 2 of the License, or
(at your option) any later version.

PLplot is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU Library General Public License for more details.

You should have received a copy of the GNU Library General Public License
along with PLplot if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
--]]

-- initialise Lua bindings for PLplot examples.
--dofile("plplot_examples.lua")


-- main
--
-- Displays Greek letters and mathematically interesting Unicode ranges


Greek = {
  "#gA","#gB","#gG","#gD","#gE","#gZ","#gY","#gH","#gI","#gK","#gL","#gM",
  "#gN","#gC","#gO","#gP","#gR","#gS","#gT","#gU","#gF","#gX","#gQ","#gW",
  "#ga","#gb","#gg","#gd","#ge","#gz","#gy","#gh","#gi","#gk","#gl","#gm",
  "#gn","#gc","#go","#gp","#gr","#gs","#gt","#gu","#gf","#gx","#gq","#gw"
}

Type1 = {
  32, 33, 35, 37, 38,
  40, 41, 43, 44, 46,
  47, 48, 49, 50, 51,
  52, 53, 54, 55, 56,
  57, 58, 59, 60, 61,
  62, 63, 91, 93, 95,
  123, 124, 125, 169, 172,
  174, 176, 177, 215, 247,
  402, 913, 914, 915, 916,
  917, 918, 919, 920, 921,
  922, 923, 924, 925, 926,
  927, 928, 929, 931, 932,
  933, 934, 935, 936, 937,
  945, 946, 947, 948, 949,
  950, 951, 952, 953, 954,
  955, 956, 957, 958, 959,
  960, 961, 962, 963, 964,
  965, 966, 967, 968, 969,
  977, 978, 981, 982, 8226,
  8230, 8242, 8243, 8254, 8260,
  8465, 8472, 8476, 8482, 8486,
  8501, 8592, 8593, 8594, 8595,
  8596, 8629, 8656, 8657, 8658,
  8659, 8660, 8704, 8706, 8707,
  8709, 8710, 8711, 8712, 8713,
  8715, 8719, 8721, 8722, 8725,
  8727, 8730, 8733, 8734, 8736,
  8743, 8744, 8745, 8746, 8747,
  8756, 8764, 8773, 8776, 8800,
  8801, 8804, 8805, 8834, 8835,
  8836, 8838, 8839, 8853, 8855,
  8869, 8901, 8992, 8993, 9001,
  9002, 9674, 9824, 9827, 9829,
  9830
}

title = {
  "#<0x10>PLplot Example 23 - Greek Letters",
  "#<0x10>PLplot Example 23 - Type 1 Symbol Font Glyphs by Unicode (a)",
  "#<0x10>PLplot Example 23 - Type 1 Symbol Font Glyphs by Unicode (b)",
  "#<0x10>PLplot Example 23 - Type 1 Symbol Font Glyphs by Unicode (c)",
  "#<0x10>PLplot Example 23 - Number Forms Unicode Block",
  "#<0x10>PLplot Example 23 - Arrows Unicode Block (a)",
  "#<0x10>PLplot Example 23 - Arrows Unicode Block (b)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (a)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (b)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (c)",
  "#<0x10>PLplot Example 23 - Mathematical Operators Unicode Block (d)"
}

lo = {
  0,
  0,
  64,
  128,
  8531,
  8592,
  8656,
  8704,
  8768,
  8832,
  8896
}

hi = {
  48,
  64,
  128,
  166,
  8580,
  8656,
  8704,
  8768,
  8832,
  8896,
  8960
}

nxcells = {
  12,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8
}

nycells = {
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8,
  8
}

family = {
  "sans-serif",
  "serif",
  "monospace",
  "script",
  "symbol"
}

xstyle = {
  "upright",
  "italic",
  "oblique"
}

for page=1, 8 do
  deltax = 1.0/nxcells[page]
  deltay = 1.0/nycells[page]
  print(string.format("nxcells[page] = %d, deltax = %e", nxcells[page], deltax))
  print(string.format("nycells[page] = %d, deltay = %e", nycells[page], deltay))
end

Bug#902239: enlightenment: source should be enlightenment not e17

[sergio]

Package: enlightenment
Version: 0.22.3-1
Severity: normal

Dear Maintainer,

could you update source to "enlightenment" as e17 is outdated.

Bug#901789: Aw: Re: Bug#901789: mesa: white screen when running Xfwm4 with compositing

[Margot Berg]

Hello Stuart,

 

thanks for your replay.



Xfce does not have a wayland yet, this DE still works with xorg.



My debian sid has xserver-xorg-core 1.20.0-2, so very up to date.

Unfortunately, I have no idea how to fix this bug.
I do not want to downgrade xorg or xfce.

 

best regards

MB



 



 

Gesendet: Samstag, 23. Juni 2018 um 00:22 Uhr
Von: "Stuart Young" 
An: "Margot Berg" , 901...@bugs.debian.org
Betreff: Re: Bug#901789: mesa: white screen when running Xfwm4 with compositing



Hi All,

 

Can any of you try the fix for Bug 901497 ?

 

This could be an Xwayland issue that until recently was hard to trigger.

 

Alternatively try using the X.org X server rather than the Wayland one to see if that helps.

 

On Sat, 23 Jun. 2018, 02:33 Margot Berg,  wrote:




Hello Yves-Alexis,

the same error on my debian sid with xfce 4.13 - gtk3, kernel 4.17.2, intel kabylake.
It is experimental and not stable, therefore I have no hope, that this error will be corrected.
I am using apt-pinning on version 18.0.5-1.

best regards

MB

Bug#897892: zookeeper: ftbfs with GCC-8

[Adrian Bunk]

Control: tags -1 - help

On Fri, May 04, 2018 at 12:24:12PM +, Matthias Klose wrote:
>...
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./include -I./tests 
> -I./generated -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Werror -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c 
> src/zookeeper.c  -fPIC -DPIC -o .libs/zookeeper.o
> src/zookeeper.c: In function 'format_endpoint_info':
> src/zookeeper.c:3469:21: error: '%d' directive writing between 1 and 5 bytes 
> into a region of size between 0 and 127 [-Werror=format-overflow=]
>  sprintf(buf,"%s:%d",addrstr,ntohs(port));
>  ^~
> src/zookeeper.c:3469:17: note: directive argument in the range [0, 65535]
>  sprintf(buf,"%s:%d",addrstr,ntohs(port));
>  ^~~
> In file included from /usr/include/stdio.h:862,
>  from ./include/zookeeper.h:29,
>  from src/zookeeper.c:27:
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: 
> '__builtin___sprintf_chk' output between 3 and 134 bytes into a destination 
> of size 128
>return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
>   ^~
>__bos (__s), __fmt, __va_arg_pack ());
>~
> cc1: all warnings being treated as errors
>...

The relevant code is:

...
static char buf[128];
char addrstr[128];
...
inet_ntop(ep->ss_family,inaddr,addrstr,sizeof(addrstr)-1);
sprintf(buf,"%s:%d",addrstr,ntohs(port));
...


Both addrstr and buf have a size of 128.

After the inet_ntop() call addrstr might contain up to 128 characters 
(including \0 termination).

buf is a concatenation of addrstr, ':' and ntohs(port) into a string.
That's up to 127(addrstr) + 1(:) + 5(ntohs) + 1(\0) = 134 characters.

134 > 128

cu
Adrian

-- 

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

Bug#902235: thunderbird: Freezes X on startup reproducibly

[Axel Beckert]

Control: forcemerge 900840 -1

Hi Carsten,

Carsten Schoenert wrote:
> this at all is #900840.

Yes, sorry for the duplicate. I was too lazy to scroll further down
than "severity minor" bug reports in text mode and forgot that there
might have been pending bug reports further down.

> You should be able to fix this behavior by modify the AppArmor profile
> for Thunderbird.

Will try. It at least prevent the freezes, but now I get "Your
Thunderbird profile cannot be loaded. It may be missing or
inaccessible." Might stem from hard rebooting the machine when it
happened the first time.

And I still get that "Error: Access was denied while trying to open
files in your profile directory."

BTW, why does X freeze just because Thunderbird is not allowed to
access some files? This sounds like a horribly design flaw somewhere,
probably in X.

> https://salsa.debian.org/mozilla-team/thunderbird/commit/cb643970b166e46b07fe38a67ae85dec5c9e3d1a

And why does Thunderbird need to poke around that deep under /sys/
anyways? It's an application and it should be hardware-independent...

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

Bug#675318: munin-node: postfix_mailstats incorrect delivered message count

[Lars Kruse]

Package: munin-plugins-core
Version: 2.0.37-2
Followup-For: Bug #675318

Hi,

the issue is fixed upstream and will be part of the upcoming releases
2.0.38 and 2.999.9.

Cheers,
Lars

Bug#902238: lua5.3: arithemetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Package: lua5.3
Version: 5.3.3-1
Severity: important

Based on a more complex script that was generating incorrect numerical
results, I have created a fairly simple example lua script (which I will 
subsequently
attach to this bug report) which demonstrates the bug.

In this script I initialize 9 different arrays of
various sizes, and then calculate the numerical inverses of elements
of two of those arrays.  The inverses are not calculated properly (the
result just prints out as 1.0) if 9 arrays are initialized, but if I
remove any one of the array initializations that are not relevant to
the inverse calculation, the correct inverse result is printed.  For
the (incorrect) nine-array case, the printout shows the array value
that is inverted is correct so it is lua's ability to divide that gets
clobbered by the intialization of 9 arrays in this example,
and not the array value itself that is being inverted.

This bug makes lua5.3 largely unusable for any complex task that involves
arrays so I have set the Severity level to important.

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

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

Versions of packages lua5.3 depends on:
ii  libc6 2.27-3
ii  libreadline7  7.0-5

lua5.3 recommends no packages.

lua5.3 suggests no packages.

-- no debconf information

Bug#884304: Debian 8.10 is not installable via PXE

[Steve McIntyre]

Hi Jaikumar,

AFAICS the problem you're facing is that the d-i kernel modules and
the kernel you're running don't match up. Here's the kernel version
you have:

On Sat, Jun 23, 2018 at 09:47:39PM +0530, Jaikumar Sharma wrote:
>
>Jun 23 14:20:40 syslogd started: BusyBox v1.22.1
>Jun 23 14:20:40 kernel: klogd started: BusyBox v1.22.1 (Debian
>1:1.22.0-9+deb8u1)
>Jun 23 14:20:40 kernel: [    0.00] Initializing cgroup subsys cpuset
>Jun 23 14:20:40 kernel: [    0.00] Initializing cgroup subsys cpu
>Jun 23 14:20:40 kernel: [    0.00] Initializing cgroup subsys cpuacct
>Jun 23 14:20:40 kernel: [    0.00] Linux version 3.16.0-4-586 (
>debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian
>3.16.7-ckt9-2 (2015-04-13)
...

and here are lots of "Unknown symbol" errors when d-i is trying to
load various filesystem modules:

>Jun 23 14:22:42 preseed: running preseed command partman/early_command: wget -P
>/tmp ftp://192.168.1.34/localrepo/install.scripts/scripts/config.sh
>Jun 23 14:22:42 log-output: Connecting to 192.168.1.34 (192.168.1.34:21)
>Jun 23 14:22:42 log-output: ^Mconfig_backup.sh     100% |
>***|  2515   0:00:00 ETA
>Jun 23 14:22:42 kernel: [  139.713269] ext4: Unknown symbol setattr_prepare
>(err 0)
>Jun 23 14:22:42 kernel: [  139.713731] ext4: Unknown symbol __bread_gfp (err 0)
>Jun 23 14:22:42 kernel: [  139.713779] ext4: Unknown symbol __getblk_gfp (err
>0)
>Jun 23 14:22:42 kernel: [  139.713809] ext4: Unknown symbol
>posix_acl_update_mode (err 0)
>Jun 23 14:22:42 kernel: [  139.814438] raid6: mmxx1     5762 MB/s
>Jun 23 14:22:42 md-devices: mdadm: No devices listed in partitions
>Jun 23 14:22:42 md-devices: mdadm: No devices listed in conf file were found.
>Jun 23 14:22:42 kernel: [  139.882447] raid6: mmxx2     6136 MB/s
>Jun 23 14:22:42 kernel: [  139.950455] raid6: sse1x1    4760 MB/s
>Jun 23 14:22:42 kernel: [  140.018463] raid6: sse1x2    5924 MB/s
>Jun 23 14:22:42 kernel: [  140.086474] raid6: sse2x1    9564 MB/s
>Jun 23 14:22:42 kernel: [  140.154484] raid6: sse2x2   12018 MB/s
>Jun 23 14:22:42 kernel: [  140.154485] raid6: using algorithm sse2x2 (12018 MB/
>s)
>Jun 23 14:22:42 kernel: [  140.154486] raid6: using ssse3x1 recovery algorithm
>Jun 23 14:22:42 kernel: [  140.220352] xor: automatically using best
>checksumming function:
>Jun 23 14:22:42 kernel: [  140.258486]    avx       : 20146.000 MB/sec
>Jun 23 14:22:42 kernel: [  140.259696] btrfs: Unknown symbol setattr_prepare
>(err 0)
>Jun 23 14:22:42 kernel: [  140.260185] btrfs: Unknown symbol
>posix_acl_update_mode (err 0)
>Jun 23 14:22:42 kernel: [  140.264461] ext4: Unknown symbol setattr_prepare
>(err 0)
>Jun 23 14:22:42 kernel: [  140.264915] ext4: Unknown symbol __bread_gfp (err 0)
>Jun 23 14:22:42 kernel: [  140.264965] ext4: Unknown symbol __getblk_gfp (err
>0)
>Jun 23 14:22:42 kernel: [  140.265008] ext4: Unknown symbol
>posix_acl_update_mode (err 0)
>Jun 23 14:22:42 kernel: [  140.265748] ext4: Unknown symbol setattr_prepare
>(err 0)
>Jun 23 14:22:42 kernel: [  140.266191] ext4: Unknown symbol __bread_gfp (err 0)
>Jun 23 14:22:42 kernel: [  140.266239] ext4: Unknown symbol __getblk_gfp (err
>0)
>Jun 23 14:22:42 kernel: [  140.266270] ext4: Unknown symbol
>posix_acl_update_mode (err 0)
>Jun 23 14:22:42 kernel: [  140.270835] jfs: Unknown symbol setattr_prepare (err
>0)
>Jun 23 14:22:42 kernel: [  140.270975] jfs: Unknown symbol __bread_gfp (err 0)
>Jun 23 14:22:42 kernel: [  140.271009] jfs: Unknown symbol __getblk_gfp (err 0)
>Jun 23 14:22:42 kernel: [  140.271022] jfs: Unknown symbol
>posix_acl_update_mode (err 0)
>Jun 23 14:22:42 kernel: [  140.276230] xfs: Unknown symbol setattr_prepare (err
>0)
>Jun 23 14:22:42 kernel: [  140.276555] xfs: Unknown symbol
>posix_acl_update_mode (err 0)
>Jun 23 14:22:42 kernel: [  140.451316] device-mapper: uevent: version 1.0.3
>Jun 23 14:22:42 kernel: [  140.451490] device-mapper: ioctl: 4.27.0-ioctl
>(2013-10-30) initialised: dm-de...@redhat.com
>Jun 23 14:22:42 partman:   No matching physical volumes found
>Jun 23 14:22:42 partman:   Reading all physical volumes.  This may take a
>while...
>Jun 23 14:22:42 partman:   
>Jun 23 14:22:42 partman: No volume groups found
>Jun 23 14:22:42 partman: 
>Jun 23 14:22:42 partman-lvm:   
>Jun 23 14:22:42 partman-lvm: No volume groups found
>Jun 23 14:22:42 partman-lvm: 
>Jun 23 14:22:42 kernel: [  140.486141] efivars: Unknown symbol ucs2_as_utf8
>(err 0)
>Jun 23 14:22:42 kernel: [  140.486163] efivars: Unknown symbol ucs2_utf8size
>(err 0)
>Jun 23 14:22:42 kernel: [  140.486164] efivars: disagrees about version of
>symbol efivar_validate
>Jun 23 14:22:42 kernel: [  140.486165] efivars: Unknown symbol efivar_validate
>(err -22)
>Jun 23 14:22:50 init: starting pid 146, tty '/dev/tty2': '-/bin/sh'

The most common cause of this kind of problem for people netbooting is
them updating *some* of the installer (i.e. the modules in the Debian
archive) without also updating the kernel that's 

Bug#902235: thunderbird: Freezes X on startup reproducibly

[Carsten Schoenert]

Hello Axel,

On Sat, Jun 23, 2018 at 07:05:14PM +0200, Axel Beckert wrote:
... 
>   Error: Access was denied while trying to open files in your profile
>   directory.
> 
> I though couldn't find any such file using e.g. "find ~ -not -readable"
> or "find ~ -not -user `id -un`". But I do have apparmor active, so it
> might be related to that.
> 
> Actually I found some related messages in the dmesg output
> 
> [  111.046491] audit: type=1400 audit(1529769721.595:112): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [  111.046520] audit: type=1400 audit(1529769721.595:113): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [  111.046578] audit: type=1400 audit(1529769721.595:114): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [  111.046608] audit: type=1400 audit(1529769721.595:115): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [  111.050583] audit: type=1400 audit(1529769721.599:116): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [  111.050672] audit: type=1400 audit(1529769721.599:117): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [  111.071629] audit: type=1400 audit(1529769721.619:118): apparmor="DENIED" 
> operation="mkdir" profile="thunderbird" 
> name="/run/user/1000/.unburden-abe/cache/thunderbird/" pid=5299 
> comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [  111.517719] audit: type=1400 audit(1529769722.067:119): apparmor="DENIED" 
> operation="mknod" profile="thunderbird" 
> name="/run/user/1000/.unburden-abe/cache/fontconfig/2e755eb509a594ba7adde982574983b5-le64.cache-7.TMP-yAAa7a"
>  pid=5299 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 
> ouid=1000
> [ 2214.053670] audit: type=1400 audit(1529771824.595:124): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 2214.053707] audit: type=1400 audit(1529771824.595:125): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 2214.053768] audit: type=1400 audit(1529771824.595:126): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 2214.053804] audit: type=1400 audit(1529771824.595:127): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 2214.056597] audit: type=1400 audit(1529771824.595:128): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 2214.057319] audit: type=1400 audit(1529771824.595:129): apparmor="DENIED" 
> operation="open" profile="thunderbird" 
> name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [ 2214.059413] audit: type=1400 audit(1529771824.599:130): apparmor="DENIED" 
> operation="mkdir" profile="thunderbird" 
> name="/run/user/1000/.unburden-abe/cache/thunderbird/" pid=9394 
> comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [ 2214.245650] audit: type=1400 audit(1529771824.787:131): apparmor="DENIED" 
> operation="mknod" profile="thunderbird" 
> name="/run/user/1000/.unburden-abe/cache/fontconfig/2e755eb509a594ba7adde982574983b5-le64.cache-7.TMP-tid84T"
>  pid=9394 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 
> ouid=1000
> 
> This is likely from two tries to start thunderbird.
> 
> I also checked /var/log/Xorg.0.log as well as ~/.xsession-errors, but I
> found nothing which seems related or in the relevant time frame.

this at all is #900840.

intrigeri has added a updated AppArmor profile for Thunderbird,

Bug#902237: Feature Request: Package plugin installer separately

[procmem]

Package: gajim
Version: all
Severity: serious

Please consider packaging the plugin installer separately (to make its
install optional) as it prompts users to update and install additional
code from untrusted sources which violates Debian's package security
assumptions.

(/usr/share/gajim/plugins/plugin_installer/)

Bug#902236: catchsegv.1: Some corrections to the manual

[Bjarni Ingi Gislason]

Package: libc-bin
Version: 2.27-3
Severity: minor
Tags: patch

  Summary:

Remove space at end of lines.

Add a backslash if line ends in '\{'.

Define the macro "IX" also for F=0.

Use the italic font for names of variable content.

Begin a sentence in a new line when only one space character is between
sentences.

  Details:

Input file is catchsegv.1

mandoc: catchsegv.1:85:14: STYLE: whitespace at end of input line
mandoc: catchsegv.1:87:19: STYLE: whitespace at end of input line

###

Test nr. 1:

Remove space characters at the end of lines.

Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

85:.\"  TH  Title 
87:.\"  Sh  Subsection 

#

Input file is catchsegv.1
Test nr. 2:

Enable and fix warnings from 'test-groff'.

troff: :208: warning: macro 'IX' not defined

Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]



Test nr. 17:

Add a backslash, if it is missing after \{ at the end of a line.

92:.if \nF \{

#

Test nr. 21:

Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes them
  or
add the italic corrections.
[1] man-pages(7) [package "manpages"]

202:\fIcatchsegv\fR was written by Ulrich Drepper for the GNU C Library

#

Input file is catchsegv.1
Test nr. 29:

Surround a block of comments with the macros ".ig" and "..".
The .\" (\#) at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust length of lines.

NO PATCH

2:.\" $RCSfile: catchsegv.1,v $$Revision: 1.1.2.1 $$Date: 2003/09/22 21:33:35 $
3:.\"
4:.\" $Log: catchsegv.1,v $
5:.\" Revision 1.1.2.1  2003/09/22 21:33:35  jbailey
6:.\" New directory for things we add to the package
7:.\"
8:.\"
37:.\"
38:.\"
39:.\" Set up \*(-- to give an unbreakable dash;
40:.\" string Tr holds user defined translation string.
41:.\" Bell System Logo is used as a dummy character.
42:.\"
51:.\"   \*(M", \*(S", \*(N" and \*(T" are the equivalent of
52:.\"   \*(L" and \*(R", except that they are used on ".xx" lines,
53:.\"   such as .IP and .SH, which do another additional levels of
54:.\"   double-quote interpretation
83:.\"  If the F register is turned on, we'll generate
84:.\"  index entries out stderr for the following things:
85:.\"  TH  Title 
86:.\"  SH  Header
87:.\"  Sh  Subsection 
88:.\"  Ip  Item
89:.\"  X<> Xref  (embedded
90:.\"  Of course, you have to process the output yourself
91:.\"  in some meaningful fashion.

#

Test nr. 41:

Wrong distance between sentences or protect the indicator.

1) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) [package "manpages"] and "info groff".

Or

2) Adjust space between sentences (two spaces),

3) or protect the indicator by adding "\&" after it.

The "indicator" is an "end-of-sentence character" (.!?).

198:Used to debug segmentation faults in programs. The output is the
199:content of registers, plus a backtrace. Basically you call your

#

  Patch:

--- catchsegv.1 2018-03-29 19:47:29.0 +
+++ catchsegv.1.new 2018-06-22 18:21:18.0 +
@@ -82,17 +82,22 @@
 'br\}
 .\"If the F register is turned on, we'll generate
 .\"index entries out stderr for the following things:
-.\"TH  Title 
+.\"TH  Title
 .\"SH  Header
-.\"Sh  Subsection 
+.\"Sh  Subsection
 .\"Ip  Item
 .\"X<> Xref  (embedded
 .\"Of course, you have to process the output yourself
 .\"in some meaningful fashion.
-.if \nF \{
+.ie \nF \{\
 .de IX
 .tm Index:\\$1\t\\n%\t"\\$2"
 ..
+.\}
+.el \{\
+.de IX
+..
+.\}
 .nr % 0
 .rr F
 .\}
@@ -193,10 +198,12 @@
 .SH "NAME"
 catchsegv \- Catch segmentation faults in programs
 .SH "SYNOPSIS"
-\fBcatchsegv\fR \fBprogram\fR [\fBargs\fR]
+\fBcatchsegv\fR \fIprogram\fR [\,\fIargs\fR\/]
 .SH "DESCRIPTION"
-Used to debug segmentation faults in programs. The output is the
-content of registers, plus a backtrace. Basically you call your
+Used to debug segmentation faults in programs.
+The output is the
+content of registers, plus a backtrace.
+Basically you call your
 program and its arguments as the arguments to catchsegv.
 .SH "AUTHOR"
 \fIcatchsegv\fR was written by Ulrich Drepper for the GNU C Library


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

Kernel: Linux 4.9.88-1-u1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of 

Bug#902235: thunderbird: Freezes X on startup reproducibly

[Axel Beckert]

Package: thunderbird
Version: 1:52.8.0-1
Severity: important

Hi,

I use thunderbird seldomly (i.e. I got the popup about migrating icedove
profiles only today), so I have no idea with which this started to
happen. But when I now start thunderbird on my Thinkpad X250, X freezes
immediately. The mouse and Ctrl-Alt-F1 still works, but I can't control
my window manager (i3) anymore nor does the currently focussed shell
(where I started thunderbird) react to any keypress. For example the
clock in my i3bar which is updating every second, stopped, too.

I have to kill X to get back into a usable state.

This is reproducible. I tried it about four times. (The first time I
even rebooted the laptop hard by powering it off as I didn't notice that
I can still switch to a text console.)

I have no idea why this happens. The only thing I saw before the freeze
was that thunderbird emitted this error message in the shell where I
started it:

  Error: Access was denied while trying to open files in your profile
  directory.

I though couldn't find any such file using e.g. "find ~ -not -readable"
or "find ~ -not -user `id -un`". But I do have apparmor active, so it
might be related to that.

Actually I found some related messages in the dmesg output

[  111.046491] audit: type=1400 audit(1529769721.595:112): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  111.046520] audit: type=1400 audit(1529769721.595:113): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  111.046578] audit: type=1400 audit(1529769721.595:114): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  111.046608] audit: type=1400 audit(1529769721.595:115): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  111.050583] audit: type=1400 audit(1529769721.599:116): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  111.050672] audit: type=1400 audit(1529769721.599:117): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=5346 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  111.071629] audit: type=1400 audit(1529769721.619:118): apparmor="DENIED" 
operation="mkdir" profile="thunderbird" 
name="/run/user/1000/.unburden-abe/cache/thunderbird/" pid=5299 
comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[  111.517719] audit: type=1400 audit(1529769722.067:119): apparmor="DENIED" 
operation="mknod" profile="thunderbird" 
name="/run/user/1000/.unburden-abe/cache/fontconfig/2e755eb509a594ba7adde982574983b5-le64.cache-7.TMP-yAAa7a"
 pid=5299 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 
ouid=1000
[ 2214.053670] audit: type=1400 audit(1529771824.595:124): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 2214.053707] audit: type=1400 audit(1529771824.595:125): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 2214.053768] audit: type=1400 audit(1529771824.595:126): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 2214.053804] audit: type=1400 audit(1529771824.595:127): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 2214.056597] audit: type=1400 audit(1529771824.595:128): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 2214.057319] audit: type=1400 audit(1529771824.595:129): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:00/:00:02.0/vendor" pid=9409 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 2214.059413] audit: type=1400 audit(1529771824.599:130): apparmor="DENIED" 
operation="mkdir" profile="thunderbird" 

Bug#902233: Missing zfs-dkms dependencies for minimal install

[Joel Johnson]

Package: zfs-dkms
Version: 0.7.9-3~bpo9+1
Severity: important

It appears that at least one dependency is missing for zfs-dkms. I 
create a new squeeze installation using debootstrap, enabled 
squeeze-backports, and performed manual installation of zfs-dkms. The 
build failed, giving the following message early on and then eventually 
failing the build.


I installed the dh-exec package containing the dpkg-architecture command 
and the build succeeded after that. I didn't do extensive testing, but 
expect that additional transitive dependencies were also required for 
the build actually suceeding (e.g. autoconf, automake debhelper, etc.).


Building initial module for 4.16.0-0.bpo.2-amd64
/var/lib/dkms/zfs/0.7.9/build/configure: line 13069: dpkg-architecture: 
command not found


Joel

Bug#902234: allowMultipleSelection is wrong in korean data

[Hodong Kim]

Package: xkb-data
Version: 2.19-1+deb9u1

Hello.
I am a Korean user.

The allowMultipleSelection is wrong in korean data.
allowMultipleSelection should be "false".

root@debian:/usr/share/X11# git diff
diff --git a/xkb/rules/base.xml b/xkb/rules/base.xml
index ccb2267..5cfc6a4 100644
--- a/xkb/rules/base.xml
+++ b/xkb/rules/base.xml
@@ -7126,7 +7126,7 @@

   
 
-
+
   
 korean
 Korean Hangul/Hanja keys
@@ -7199,4 +7199,4 @@
   
 
   
-
\ No newline at end of file
+
diff --git a/xkb/rules/evdev.xml b/xkb/rules/evdev.xml
index ccb2267..5cfc6a4 100644
--- a/xkb/rules/evdev.xml
+++ b/xkb/rules/evdev.xml
@@ -7126,7 +7126,7 @@

   
 
-
+
   
 korean
 Korean Hangul/Hanja keys
@@ -7199,4 +7199,4 @@
   
 
   
-
\ No newline at end of file
+

I am using Debian Stretch.
hodong@debian:~$ dpkg -l | grep xkb-data
ii  xkb-data
2.19-1+deb9u1   all  X Keyboard
Extension (XKB) configuration data

This bug als​o​
appears in xkeyboard-config-2.24.
I also reported it on the ​freedesktop ​
project.
See https://bugs.freedesktop.org/show_bug.cgi?id=107011

hodong@debian:~/Downloads/xkeyboard-config-2.24/xkeyboard-config-2.24$ git
diff
diff --git a/rules/base.xml.in b/rules/base.xml.in
index 3608b60..fae781a 100644
--- a/rules/base.xml.in
+++ b/rules/base.xml.in
@@ -7250,7 +7250,7 @@

   
 
-
+
   
 korean
 <_description>Korean Hangul/Hanja keys
diff --git a/rules/evdev.xml.in b/rules/evdev.xml.in
index 3608b60..fae781a 100644
--- a/rules/evdev.xml.in
+++ b/rules/evdev.xml.in
@@ -7250,7 +7250,7 @@

   
 
-
+
   
 korean
 <_description>Korean Hangul/Hanja keys

Bug#690097: Bug #690097 - dynamips: Please enable buildd support

[Andrej Shadura]

On Sat, 23 Nov 2013 17:07:16 +0100 =?ISO-8859-1?Q?Arno_T=F6ll?=
 wrote:
> Hi,
> 
> On 22.11.2013 12:48, Danel Lintott wrote:
> > Is there anything else we need to do to get dynamips enabled for
> > autobuilding?
> 
> First of all you need to set "XS-Autobuild: yes" in your debian/control
> source file. Once you made an upload containing that flag, buildd
> support should reappear again without any further interaction from your
> side.

The latest upload has XS-Autobuild: yes, but the package still doesn’t
appear to have buildd support enabled. Is there anything wrong with the
package, or with buildds, or elsewhere?

Thanks.

-- 
Cheers,
  Andrej

Bug#902232: ITP: wmusic -- remote-control dockapp for MPRIS-compatible media players

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: wmusic
  Version : 2.0.0
  Upstream Author : Window Maker Team 
* URL : https://www.dockapps.net/wmusic
* License : GPL
  Programming Lang: C
  Description : remote-control dockapp for MPRIS-compatible media players

 wmusic is a dockapp that remote-controls MPRIS-compatible media players. Here
 is a list of the features:
 * VCR style controls including fast rewind and fast forward
 * Time and Playlist position display
 * Super stylee rotating arrow

wmusic was removed from Debian in 2008, when it was a remote control for xmms.

It was recently adopted upstream by the Window Maker Team, and a new release
was made available.  It now supports any media player with MPRIS (Media Player
Remote Interfacing Specification) [1] compatibilty by using the playerctl [2]
library, which is already available in Debian.

wmusic will be maintained by the Debian Window Maker Team.

[1] https://specifications.freedesktop.org/mpris-spec/latest/
[2] https://github.com/acrisci/playerctl

Bug#901148: Also hit

[Leandro Lucarella]

Hi, I can also confirm I'm affected by this and agree that the severity 
should be grave. It's not even trivial to debug where the problem comes 
from, I even wrongly filled a bug to the linux-image since it seems to be 
racy too, so sometimes (I guess if timidity starts too late in the boot 
sequence) it could work, and I was unlucky enough that when I rebooted 
with the previous kernel it worked.


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

Bug#884304: Debian 8.10 is not installable via PXE

[Jaikumar Sharma]

On Sat, Jun 23, 2018 at 9:07 PM, Steve McIntyre  wrote:

> If you're running with useful networking (e.g. bridged), then you can
> grab the log from d-i via a trivial built-in webserver. If not,
> probably the easiest way is to plug in a USB stick and copy it
> there. You're looking for /var/log/syslog.
>

Thank you steve. I've attached the syslog below:

Jun 23 14:20:40 syslogd started: BusyBox v1.22.1
Jun 23 14:20:40 kernel: klogd started: BusyBox v1.22.1 (Debian
1:1.22.0-9+deb8u1)
Jun 23 14:20:40 kernel: [0.00] Initializing cgroup subsys cpuset
Jun 23 14:20:40 kernel: [0.00] Initializing cgroup subsys cpu
Jun 23 14:20:40 kernel: [0.00] Initializing cgroup subsys cpuacct
Jun 23 14:20:40 kernel: [0.00] Linux version 3.16.0-4-586 (
debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1
Debian 3.16.7-ckt9-2 (2015-04-13)
Jun 23 14:20:40 kernel: [0.00] e820: BIOS-provided physical RAM map:
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0x-0x0009fbff] usable
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0x0009fc00-0x0009] reserved
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0x000f-0x000f] reserved
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0x0010-0xdffe] usable
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0xdfff-0xdfff] ACPI data
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0xfec0-0xfec00fff] reserved
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0xfee0-0xfee00fff] reserved
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0xfffc-0x] reserved
Jun 23 14:20:40 kernel: [0.00] BIOS-e820: [mem
0x0001-0x00021fff] usable
Jun 23 14:20:40 kernel: [0.00] Notice: NX (Execute Disable)
protection cannot be enabled: non-PAE kernel!
Jun 23 14:20:40 kernel: [0.00] SMBIOS 2.5 present.
Jun 23 14:20:40 kernel: [0.00] DMI: innotek GmbH
VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jun 23 14:20:40 kernel: [0.00] Hypervisor detected: KVM
Jun 23 14:20:40 kernel: [0.00] e820: update [mem
0x-0x0fff] usable ==> reserved
Jun 23 14:20:40 kernel: [0.00] e820: remove [mem
0x000a-0x000f] usable
Jun 23 14:20:40 kernel: [0.00] e820: last_pfn = 0xdfff0
max_arch_pfn = 0x10
Jun 23 14:20:40 kernel: [0.00] MTRR default type: uncachable
Jun 23 14:20:40 kernel: [0.00] MTRR variable ranges disabled:
Jun 23 14:20:40 kernel: [0.00] x86 PAT enabled: cpu 0, old
0x7040600070406, new 0x7010600070106
Jun 23 14:20:40 kernel: [0.00] CPU MTRRs all blank - virtualized
system.
Jun 23 14:20:40 kernel: [0.00] initial memory mapped: [mem
0x-0x01bf]
Jun 23 14:20:40 kernel: [0.00] Base memory trampoline at [c009b000]
9b000 size 16384
Jun 23 14:20:40 kernel: [0.00] init_memory_mapping: [mem
0x-0x000f]
Jun 23 14:20:40 kernel: [0.00]  [mem 0x-0x000f] page 4k
Jun 23 14:20:40 kernel: [0.00] init_memory_mapping: [mem
0x3700-0x373f]
Jun 23 14:20:40 kernel: [0.00]  [mem 0x3700-0x373f] page 2M
Jun 23 14:20:40 kernel: [0.00] init_memory_mapping: [mem
0x3000-0x36ff]
Jun 23 14:20:40 kernel: [0.00]  [mem 0x3000-0x36ff] page 2M
Jun 23 14:20:40 kernel: [0.00] init_memory_mapping: [mem
0x0010-0x2fff]
Jun 23 14:20:40 kernel: [0.00]  [mem 0x0010-0x003f] page 4k
Jun 23 14:20:40 kernel: [0.00]  [mem 0x0040-0x2fff] page 2M
Jun 23 14:20:40 kernel: [0.00] init_memory_mapping: [mem
0x3740-0x377fdfff]
Jun 23 14:20:40 kernel: [0.00]  [mem 0x3740-0x377fdfff] page 4k
Jun 23 14:20:40 kernel: [0.00] BRK [0x0171a000, 0x0171afff] PGTABLE
Jun 23 14:20:40 kernel: [0.00] RAMDISK: [mem 0x7f205000-0x7fff]
Jun 23 14:20:40 kernel: [0.00] Allocated new RAMDISK: [mem
0x36a03000-0x377fd7eb]
Jun 23 14:20:40 kernel: [0.00] Move RAMDISK from [mem
0x7f205000-0x77eb] to [mem 0x36a03000-0x377fd7eb]
Jun 23 14:20:40 kernel: [0.00] ACPI: Early table checksum
verification disabled
Jun 23 14:20:40 kernel: [0.00] ACPI: RSDP 0x000E 24 (v02
VBOX  )
Jun 23 14:20:40 kernel: [0.00] ACPI: XSDT 0xDFFF0030 34 (v01
VBOX   VBOXXSDT 0001 ASL  0061)
Jun 23 14:20:40 kernel: [0.00] ACPI: FACP 0xDFFF00F0 F4 (v04
VBOX   VBOXFACP 0001 ASL  0061)
Jun 23 14:20:40 kernel: [0.00] ACPI: DSDT 0xDFFF0410 0021FF (v02
VBOX   VBOXBIOS 0002 INTL 20100528)
Jun 23 14:20:40 kernel: [0.00] ACPI: FACS 0xDFFF0200 40
Jun 23 14:20:40 kernel: [0.00] ACPI: SSDT 0xDFFF0240 0001CC (v01
VBOX   VBOXCPUT 0002 INTL 20100528)
Jun 23 14:20:40 kernel: [0.00] 2695MB 

Bug#902231: Firefox 60 crash on armhf

[Andrew M. Bishop]

Package: firefox
Version: 60.0.2-1

Firefox does not run at all:

$ firefox -h
Segmentation fault


Running under the debugger doesn't show the source of the problem:

$ gdb firefox.real
GNU gdb (Debian 7.12-6+b2) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from firefox.real...(no debugging symbols found)...done.
{gdb}run
Starting program: /usr/bin/firefox.real 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xb19bdbf0 in ?? () from /usr/lib/firefox/libxul.so
{gdb}bt
#0  0xb19bdbf0 in ?? () from /usr/lib/firefox/libxul.so
#1  0xb19bdbd0 in ?? () from /usr/lib/firefox/libxul.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


Firefox version 61.0~b8-1 from experimental also has the same crash
and the same stack trace corruption signature.


This problem and a similar stack trace corruption signature (different
library but same identical stack frame) are reported here:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337/comments/38


The relevant Mozilla bug report seems to be this one (although the
title says Arm64 the specific comment is 32-bit):

https://bugzilla.mozilla.org/show_bug.cgi?id=1452128#c11

-- 
Andrew.