Bug#1065270: Unable to open VTK file with appended data that were fine with previous versions (invalid token in vtkXMLDataParser)

[Giuseppe Bilotta]

Package: paraview
Version: 5.11.2+dfsg-6+b9
Followup-For: Bug #1065270

The issue is still present with the current version of paraview
(5.11.2+dfsg-6+b9) and libexpat (2.6.2-1), except that now downgrading
to the previous version of expat to work around the issue
is not possible anymore.

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

Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages paraview depends on:
ii  libadios2-mpi-c++11-2 2.9.2+dfsg1-13+b1
ii  libavcodec60  10:6.1.1-dmo4
ii  libavformat60 10:6.1.1-dmo4
ii  libavutil58   10:6.1.1-dmo4
ii  libc6 2.37-17
ii  libdouble-conversion3 3.3.0-1+b1
ii  libexpat1 2.6.2-1
ii  libfreetype6  2.13.2+dfsg-1+b3
ii  libgcc-s1 14-20240330-1
ii  libgdal34t64  3.8.5+dfsg-1
ii  libgl2ps1.4   1.4.2+dfsg1-2
ii  libglew2.22.2.0-4+b1
ii  libglx0   1.7.0-1
ii  libgmsh4.12t644.12.1+ds1-1.1+b1
ii  libhdf5-openmpi-103-1t64  1.10.10+repack-3.3
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  liblz4-1  1.9.4-2
ii  liblzma5  5.6.1+really5.4.5-1
ii  libnetcdf19t641:4.9.2-5+b1
ii  libogg0   1.3.5-3
ii  libopengl01.7.0-1
ii  libopenmpi3t644.1.6-9
ii  libpng16-16t641.6.43-5
ii  libpython3.11t64  3.11.9-1
ii  libpython3.12t64  3.12.3-1
ii  libqt5core5t645.15.10+dfsg-7.2+b1
ii  libqt5gui5t64 5.15.10+dfsg-7.2+b1
ii  libqt5help5   5.15.10-6+b2
ii  libqt5network5t64 5.15.10+dfsg-7.2+b1
ii  libqt5opengl5t64  5.15.10+dfsg-7.2+b1
ii  libqt5widgets5t64 5.15.10+dfsg-7.2+b1
ii  libstdc++614-20240330-1
ii  libswscale7   10:6.1.1-dmo4
ii  libtheora01.1.1+dfsg.1-16.1+b2
ii  libtiff6  4.5.1+git230720-4
ii  libx11-6  2:1.8.7-1
ii  libxcursor1   1:1.2.1-1
ii  libxml2   2.9.14+dfsg-1.3+b2
ii  python3-matplotlib3.6.3-1.1
ii  python3-mpi4py3.1.5-5+b1
ii  tcl [tclsh]   8.6.14
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages paraview recommends:
ii  mpi-default-bin   1.15
ii  paraview-doc  5.11.2+dfsg-6
ii  python3-paraview  5.11.2+dfsg-6+b9

Versions of packages paraview suggests:
pn  h5utils 
ii  hdf5-tools  1.10.10+repack-3.3

-- no debconf information

Bug#1065270: Unable to open VTK file with appended data that were fine with previous versions (invalid token in vtkXMLDataParser)

[Giuseppe Bilotta]

Package: paraview
Version: 5.11.2+dfsg-6+b1
Severity: important

Per the title, after a recent upgrade opening any data file with
appended data in 'raw' format, which was possible before the update,
fails with errors like:

vtkXMLDataParser (0x56138248c210): Error parsing XML in stream at line 27, 
column 1, byte index 1348: not well-formed (invalid token)

This may be an issue with the system expat library, at least according
to the thread
https://discourse.paraview.org/t/i-cannot-read-a-vtp-file-i-could-open-yesterday-can-someone-try-to-open-it/13938
where the same issue is being discussed for an Arch installation.

As reported there, downgrading libexpat1 to 2.5.0-2+b2 seems to fix the
issue, so it's either an issue in expat or in the way ParaView is using
it (maybe some changed default about the strictness off the parsing?).

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

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages paraview depends on:
ii  libadios2-mpi-c++11-2  2.9.2+dfsg1-13
ii  libavcodec60   10:6.1.1-dmo1
ii  libavformat60  10:6.1.1-dmo1
ii  libavutil5810:6.1.1-dmo1
ii  libc6  2.37-15
ii  libdouble-conversion3  3.3.0-1+b1
ii  libexpat1  2.6.0-1
ii  libfreetype6   2.13.2+dfsg-1+b1
ii  libgcc-s1  14-20240201-3
ii  libgdal34  3.8.4+dfsg-1
ii  libgl2ps1.41.4.2+dfsg1-2
ii  libglew2.2 2.2.0-4+b1
ii  libglx01.7.0-1
ii  libgmsh4.124.12.1+ds1-1
ii  libhdf5-openmpi-103-1  1.10.10+repack-3+b1
ii  libjpeg62-turbo1:2.1.5-2+b2
ii  liblz4-1   1.9.4-1+b2
ii  liblzma5   5.4.5-0.3
ii  libnetcdf191:4.9.2-3+b1
ii  libogg01.3.5-3
ii  libopengl0 1.7.0-1
ii  libopenmpi34.1.6-5
ii  libpng16-161.6.42-1
ii  libpython3.11  3.11.8-1
ii  libpython3.12  3.12.2-1
ii  libqt5core5a   5.15.10+dfsg-7
ii  libqt5gui5 5.15.10+dfsg-7
ii  libqt5help55.15.10-6
ii  libqt5network5 5.15.10+dfsg-7
ii  libqt5opengl5  5.15.10+dfsg-7
ii  libqt5widgets5 5.15.10+dfsg-7
ii  libstdc++6 14-20240201-3
ii  libswscale710:6.1.1-dmo1
ii  libtheora0 1.1.1+dfsg.1-16.1+b1
ii  libtiff6   4.5.1+git230720-4
ii  libx11-6   2:1.8.7-1
ii  libxcursor11:1.2.1-1
ii  libxml22.9.14+dfsg-1.3+b2
ii  python3-matplotlib 3.6.3-1+b2
ii  python3-mpi4py 3.1.5-5
ii  tcl [tclsh]8.6.13+b1
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages paraview recommends:
ii  mpi-default-bin   1.15
ii  paraview-doc  5.11.2+dfsg-6
ii  python3-paraview  5.11.2+dfsg-6+b1

Versions of packages paraview suggests:
pn  h5utils 
ii  hdf5-tools  1.10.10+repack-3+b1

-- no debconf information

Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box

[Giuseppe Bilotta]

Package: inkscape
Version: 1.2.2-2+b1
Followup-For: Bug #1034289

Additional information: the issue I'm seeing seems to match upstream
issue #3664
https://gitlab.com/inkscape/inkscape/-/issues/3664
and seems to be related to a GTK bug when GTK_IM_MODULE=xim
Unsetting the variable or testing one of the values recommended in the
comments to the bug solves the issue for me.

Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box

[Giuseppe Bilotta]

Package: inkscape
Version: 1.2.2-2+b1
Severity: serious

Adding or editing a text box causes the canvas to stop updating
altogether. Writing, selecting, etc still works, but the canvas does not
refresh anymore until Inkscape is closed and reopened.
This is also with the Preferences > Rendering > Update strategy
set to "Full redraw".



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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inkscape depends on:
ii  lib2geom1.2.0  1.2.2-3
ii  libatkmm-1.6-1v5   2.28.3-1
ii  libboost-filesystem1.74.0  1.74.0+ds1-20
ii  libc6  2.36-9
ii  libcairo-gobject2  1.16.0-7
ii  libcairo2  1.16.0-7
ii  libcairomm-1.0-1v5 1.14.4-2
ii  libcdr-0.1-1   0.1.6-2+b2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgc1 1:8.2.2-3
ii  libgcc-s1  12.2.0-14
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.6-2
ii  libglibmm-2.4-1v5  2.66.5-2
ii  libgomp1   12.2.0-14
ii  libgsl27   2.7.1+dfsg-3+b1
ii  libgspell-1-2  1.12.0-1+b2
ii  libgtk-3-0 3.24.37-2
ii  libgtkmm-3.0-1v5   3.24.7-1
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  liblcms2-2 2.14-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.6
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpangocairo-1.0-01.50.12+ds-1
ii  libpangoft2-1.0-0  1.50.12+ds-1
ii  libpangomm-1.4-1v5 2.46.3-1
ii  libpng16-161.6.39-2
ii  libpoppler-glib8   22.12.0-2+b1
ii  libpoppler126  22.12.0-2+b1
ii  libpotrace01.16-2
ii  libreadline8   8.2-1.3
ii  librevenge-0.0-0   0.0.5-3
ii  librsvg2-common2.54.5+dfsg-1
ii  libsigc++-2.0-0v5  2.12.0-1
ii  libsoup2.4-1   2.74.3-1
ii  libstdc++6 12.2.0-14
ii  libvisio-0.1-1 0.1.7-1+b3
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.8.4-2
ii  libxml22.9.14+dfsg-1.1+b3
ii  libxslt1.1 1.1.35-1
ii  python33.11.2-1+b1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4+b1
ii  fig2dev  1:3.2.8b-3
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  imagemagick-7 [imagemagick]  8:7.1.1.6-dmo1
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.6
ii  libwmf-bin   0.2.12-5
ii  python3-cssselect1.2.0-2
ii  python3-lxml 4.9.2-1+b1
ii  python3-numpy1:1.24.2-1
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
ii  dia   0.97.3+git20220525-5
pn  inkscape-tutorials
pn  libsvg-perl   
ii  pstoedit  3.78-2
ii  python3-packaging 23.0-1
pn  python3-uniconvertor  
ii  ruby  1:3.1

-- no debconf information

Bug#1033204: bitlbee-plugin-mastodon: sporadically but consistently segfaults in unclear circumstances

[Giuseppe Bilotta]

Package: bitlbee-plugin-mastodon
Version: 1.4.5-1
Severity: important

In certain circumstances that I have yet been unable to fully clarify,
the plugin segfaults (bringing down all of bitlbee with it) while processing 
the timeline.
This is the relevant part of the backtrace as reported in the journal:

#0  0x7f47993106d1 mastodon_status_show_chat (mastodon.so + 0xe6d1)
#1  0x7f4799310ff8 mastodon_http_timeline (mastodon.so + 0xeff8)
#2  0x56291351f129 http_incoming_data (bitlbee + 0x29129)
#3  0x56291351dfc8 gaim_io_invoke (bitlbee + 0x27fc8)
#4  0x7f47a409867f g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f)
#5  0x7f47a4098a38 n/a (libglib-2.0.so.0 + 0x54a38)
#6  0x7f47a4098cef g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#7  0x562913506c87 main (bitlbee + 0x10c87)
#8  0x7f47a39b918a __libc_start_call_main (libc.so.6 + 0x2718a)
#9  0x7f47a39b9245 __libc_start_main_impl (libc.so.6 + 0x27245)
#10 0x56291350728a _start (bitlbee + 0x1128a)

When this happens, I have to stop bitlbee, wait an unspecified amount of time,
and then try restarting it hoping that th message responsible for the segfault
isn't in my timeline(s) anymore.

I'm afraid I still haven't been able to identify the kind of message(s) that 
cause the fault.



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

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bitlbee-plugin-mastodon depends on:
ii  bitlbee-libpurple  3.6-1.3
ii  libc6  2.36-8
ii  libglib2.0-0   2.74.6-1

bitlbee-plugin-mastodon recommends no packages.

bitlbee-plugin-mastodon suggests no packages.

-- no debconf information

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Giuseppe Bilotta]

Package: media-types
Version: 8.0.0
Severity: normal

Although the IANA registratio was apparently never finished, it is de facto 
used everywhere today.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1010027: python3-paraview: pvpython does not run scripts

[Giuseppe Bilotta]

Package: python3-paraview
Version: 5.10.1-2+b1
Followup-For: Bug #1010027

The bug is still present in 5.10.1-2+b1, and it affects both pvpython
and (arguably even worse) pvbatch. It seems that the command-line
options are never even read, even putting in a bogus file name like:

pvbatch nonexistent.py

(with no actual nonexistent.py file present) has no effect.
This is in contrast e.g. with 5.9.0 that (as expected) errored out with:

/usr/bin/../lib/x86_64-linux-gnu/vtkpython: can't open file 
'//x/nonexistent.py': [Errno 2] No such file or directory

One thing of note is that in the working 5.9 installation, pvpython ends
up delegating to vtkpython. Running strace on the broken 5.10 reveals
pvpython trying to access vtkpython and failing

readlink("/usr/bin/../lib/x86_64-linux-gnu/vtkpython", 0x7fffe0794790, 
4096) = -1 ENOENT (No such file or directory)

and then falling back to the standard python interpreter. I suspect this
may be related to the issue.



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

Kernel: Linux 5.18.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-paraview depends on:
ii  libc6  2.33-8
ii  libgcc-s1  12.1.0-7
ii  libpython3.10  3.10.5-1
ii  libstdc++6 12.1.0-7
ii  paraview   5.10.1-2+b1
ii  python33.10.5-3

python3-paraview recommends no packages.

python3-paraview suggests no packages.

-- no debconf information

Bug#1014285: nvtop: new version available with AMD GPU support

[Giuseppe Bilotta]

Package: nvtop
Version: 1.2.2-1
Severity: normal

Upstream has updated to version 2.0.2 that introduces support for AMD GPUs. 
Would it be possibel to update the package?


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

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

Versions of packages nvtop depends on:
ii  libc6 2.33-7
ii  libncursesw6  6.3+20220423-2
ii  libtinfo6 6.3+20220423-2

nvtop recommends no packages.

nvtop suggests no packages.

-- no debconf information

Bug#1005331: tt-rss: entries don't get automatically marked as read

[Giuseppe Bilotta]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1
Severity: normal

After a recent update, it seems entries can only get marked as read manually 
and one by one.
Entries do not get marked as read when the link is followed,
and trying to mark all the entries in a feed as read nothing happens,
even after confirming OK at the dialog.
Marking an item as read manually ('M' key) works.
Trying this with the JS log open shows no errors.
Pressing the M key results in an RPC call, while the other actions do not.

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

Kernel: Linux 5.16.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tt-rss depends on:
ii  dbconfig-common 2.0.21
ii  dbconfig-mysql  2.0.21
ii  debconf [debconf-2.0]   1.5.79
ii  fonts-material-design-icons-iconfont6.1.0+dfsg-1
ii  init-system-helpers 1.61
ii  libapache2-mod-php  2:8.1+92
ii  libapache2-mod-php8.1 [libapache2-mod-php]  8.1.2-1+b1
ii  libjs-dojo-core 1.15.4+dfsg1-1
ii  libjs-dojo-dijit1.15.4+dfsg1-1
ii  libjs-scriptaculous 1.9.0-2.1
ii  lsb-base11.1.0
ii  php 2:8.1+92
ii  php-cli 2:8.1+92
ii  php-intl2:8.1+92
ii  php-json2:8.1+92
ii  php-mbstring2:8.1+92
ii  php-mysql   2:8.1+92
ii  php-php-gettext 1.0.12-5
ii  php-psr-log 1.1.4-2
ii  php-xml 2:8.1+92
ii  php8.1 [php]8.1.2-1
ii  php8.1-cli [php-cli]8.1.2-1+b1
ii  php8.1-intl [php-intl]  8.1.2-1+b1
ii  php8.1-mbstring [php-mbstring]  8.1.2-1+b1
ii  php8.1-xml [php-xml]8.1.2-1+b1
ii  phpqrcode   1.1.4-3.1

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.52-1
ii  ca-certificates 20211016
ii  php-curl2:8.1+92
ii  php-gd  2:8.1+92
pn  php-mcrypt  
ii  php8.1-curl [php-curl]  8.1.2-1+b1
ii  php8.1-gd [php-gd]  8.1.2-1+b1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/default/tt-rss changed:
DISABLED=0
FORKING=0

/etc/tt-rss/config.php changed:
http://tt-rss.oblomov.eu');
// This should be set to a fully qualified URL used to access
// your tt-rss instance over the net, such as: 
https://example.org/tt-rss/
// The value should be a constant string literal. Please don't use
// PHP server variables here - you might introduce security
// issues on your install and cause hard to debug problems.
// If your tt-rss instance is behind a reverse proxy, use the external 
URL.
define('SINGLE_USER_MODE', false);
// Operate in single user mode, disables all functionality related to
// multiple users and authentication. Enabling this assumes you have
// your tt-rss directory protected by other means (e.g. http auth).
define('SIMPLE_UPDATE_MODE', false);
// Enables fallback update mode where tt-rss tries to update feeds in
// background while tt-rss is open in your browser.
// If you don't have a lot of feeds and don't want to or can't run
// background processes while not running tt-rss, this method is 
generally
// viable to keep your feeds up to date.
// Still, there are more robust (and recommended) updating methods
// available, you can read about them here: 
https://tt-rss.org/wiki/UpdatingFeeds
// *
// *** Files and directories ***
// *
define('PHP_EXECUTABLE', '/usr/bin/php');
// Path to PHP *COMMAND LINE* executable, used for various command-line 
tt-rss
// programs and update daemon. Do not try to use CGI binary here, it 
won't work.
// If you see HTTP headers being displayed while running tt-rss scripts,
// then most probably you are using the CGI binary. If you are unsure 
what to
// put in here, ask your hosting provider.
define('LOCK_DIRECTORY', 

Bug#998119: debug info invalid for /usr/lib/x86_64-linux-gnu/libvtkPVPythonCatalyst-pv5.9.so.1

[Giuseppe Bilotta]

Package: paraview
Version: 5.9.0-2+b2
Severity: normal
File: /usr/lib/x86_64-linux-gnu/libvtkPVPythonCatalyst-pv5.9.so.1


Try got gdb a process linking to
/usr/lib/x86_64-linux-gnu/libvtkPVPythonCatalyst-pv5.9.so.1
or trying to run addr2line on it fails. gdb will just get stuck
somewhere due a smashed stack, but addr2line reports the following
error:

$ addr2line -e /usr/lib/x86_64-linux-gnu/libvtkPVPythonCatalyst-pv5.9.so.1 
+0xe422
addr2line: DWARF error: section .debug_info is larger than its filesize! 
(0x5219e vs 0x48508)
??:?




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

Kernel: Linux 5.14.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages paraview depends on:
ii  libavcodec58   10:4.4-dmo6
ii  libavformat58  10:4.4-dmo6
ii  libavutil5610:4.4-dmo6
ii  libc6  2.32-4
ii  libdouble-conversion3  3.1.5-6.1
ii  libexpat1  2.4.1-2+b1
ii  libfreetype6   2.11.0+dfsg-1
ii  libgcc-s1  11.2.0-10
ii  libgdal29  3.3.2+dfsg-2+b1
ii  libgl2ps1.41.4.2+dfsg1-2
ii  libglew2.2 2.2.0-4
ii  libglx01.3.4-2+b1
ii  libhdf5-103-1  1.10.7+repack-4
ii  libjpeg62-turbo1:2.0.6-4
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libnetcdf191:4.8.1-1
ii  libopengl0 1.3.4-2+b1
ii  libopenmpi34.1.2~rc1-4
ii  libpdal-base13 2.3.0+ds-2
ii  libpng16-161.6.37-3
ii  libpython3.9   3.9.7-4
ii  libqt5core5a   5.15.2+dfsg-12
ii  libqt5gui5 5.15.2+dfsg-12
ii  libqt5help55.15.2-5
ii  libqt5network5 5.15.2+dfsg-12
ii  libqt5widgets5 5.15.2+dfsg-12
ii  libstdc++6 11.2.0-10
ii  libswscale510:4.4-dmo6
ii  libtiff5   4.3.0-2
ii  libx11-6   2:1.7.2-2+b1
ii  libxcursor11:1.2.0-2
ii  libxml22.9.12+dfsg-5
ii  python3-autobahn   17.10.1+dfsg1-7
ii  python3-matplotlib 3.3.4-2
ii  python3-mpi4py 3.1.1-8
ii  python3-six1.16.0-2
ii  python3-twisted20.3.0-7
ii  tcl [tclsh]8.6.11+1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages paraview recommends:
ii  mpi-default-bin  1.14
ii  paraview-doc 5.9.0-2
ii  python3-paraview [python3-paraview]  5.9.0-2+b2

Versions of packages paraview suggests:
pn  h5utils 
ii  hdf5-tools  1.10.7+repack-4

-- no debconf information

Bug#998102: paraview-config fails due to missing dependencies and invalid version numbers

[Giuseppe Bilotta]

Package: paraview-dev
Version: 5.9.0-2+b2
Severity: normal

Trying to run paraview-config fails with:


CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/VTK-vtk-module-find-packages.cmake:303
 (find_package):
  By not providing "FindPDAL.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "PDAL", but
  CMake did not find one.

  Could not find a package configuration file provided by "PDAL" with any of
  the following names:

PDALConfig.cmake
pdal-config.cmake

  Add the installation prefix of "PDAL" to CMAKE_PREFIX_PATH or set
  "PDAL_DIR" to a directory containing one of the above files.  If "PDAL"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/vtk-config.cmake:138 
(include)
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/paraview-config.cmake:53 
(find_package)
  CMakeLists.txt:5 (find_package)


Traceback (most recent call last):
  File "/usr/bin/paraview-config", line 267, in 
extract_paraview_flags(opts.components, cmake=opts.cmake,
  File "/usr/bin/paraview-config", line 165, in extract_paraview_flags
subprocess.check_call(configure_cmd, cwd=builddir,
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '-GUnix Makefiles', 
'/tmp/tmpuazuzahm/src', '-DCMAKE_PREFIX_PATH:STRING=/usr']' returned non-zero 
exit status 1.



Installing libpdal-dev solves the issue, but presents a new one:


CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/VTK-vtk-module-find-packages.cmake:350
 (find_package):
  find_package called with invalid argument "4.4-6+b2"
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/vtk-config.cmake:138 
(include)
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/paraview-config.cmake:53 
(find_package)
  CMakeLists.txt:5 (find_package)


CMake Error at 
/usr/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find GL2PS (missing: GL2PS_LIBRARY GL2PS_INCLUDE_DIR) (Required
  is at least version "1.4.2")
Call Stack (most recent call first):
  /usr/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 
(_FPHSA_FAILURE_MESSAGE)
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/FindGL2PS.cmake:24 
(find_package_handle_standard_args)
  
/usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/VTK-vtk-module-find-packages.cmake:397
 (find_package)
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/vtk/vtk-config.cmake:138 
(include)
  /usr/lib/x86_64-linux-gnu/cmake/paraview-5.9/paraview-config.cmake:53 
(find_package)
  CMakeLists.txt:5 (find_package)


Traceback (most recent call last):
  File "/usr/bin/paraview-config", line 267, in 
extract_paraview_flags(opts.components, cmake=opts.cmake,
  File "/usr/bin/paraview-config", line 165, in extract_paraview_flags
subprocess.check_call(configure_cmd, cwd=builddir,
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '-GUnix Makefiles', 
'/tmp/tmpy12r9x1m/src', '-DCMAKE_PREFIX_PATH:STRING=/usr']' returned non-zero 
exit status 1.



which I believe seems to indicate the cmake version check system doesn't like
suffixes such as "+b2"

As it is now, it is therefore not possible to link to cmake using
paraview-config to find the include paths and link flags.


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages paraview-dev depends on:
ii  libc6   2.32-4
ii  libeigen3-dev   3.3.9-2
ii  paraview5.9.0-2+b2
ii  qttools5-dev-tools  5.15.2-5

paraview-dev recommends no packages.

paraview-dev suggests no packages.

-- no debconf information

Bug#995069: libclc-12: tahiti-amdgcn-mesa-mesa3d.bc is missing

[Giuseppe Bilotta]

Package: libclc-12
Version: 1:12.0.1-9
Followup-For: Bug #993904

To add to this bug report, I'm getting a similer error message when trying to
use OpenCL on my machine, that has a Polaris10 card. Trying to run even just
clinfo gives the following error message:

=== CL_PROGRAM_BUILD_LOG ===
fatal error: cannot open file '/usr/lib/clc/polaris10-amdgcn-mesa-mesa3d.bc': 
No such file or directory

As it turns out, /usr/lib/clc _does_ contain the .bc files; however,
most of them are missing the 'mesa ' and/or 'mesa3d' part in the name,
as shown by this listing of the directory:

total 70M
drwxr-xr-x   2 root root 4.0K Sep 21 20:51 .
drwxr-xr-x 170 root root  36K Sep 24 22:14 ..
-rw-r--r--   1 root root 7.8M Sep 18 11:03 amdgcn--amdhsa.bc
lrwxrwxrwx   1 root root   16 Sep 18 11:03 aruba-r600--.bc -> cayman-r600--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 barts-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 bonaire-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 caicos-r600--.bc -> barts-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 carrizo-amdgcn--.bc -> 
tahiti-amdgcn--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 cayman-r600--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 cedar-r600--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 cypress-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 fiji-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx900-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx902-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx904-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx906-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 hainan-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 hawaii-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   17 Sep 18 11:03 hemlock-r600--.bc -> 
cypress-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 iceland-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 juniper-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 kabini-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 kaveri-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 mullins-amdgcn--.bc -> 
tahiti-amdgcn--.bc
-rw-r--r--   1 root root 8.0M Sep 18 11:03 nvptx64--.bc
-rw-r--r--   1 root root 8.0M Sep 18 11:03 nvptx64--nvidiacl.bc
-rw-r--r--   1 root root 7.9M Sep 18 11:03 nvptx--.bc
-rw-r--r--   1 root root 7.9M Sep 18 11:03 nvptx--nvidiacl.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 oland-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 palm-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 pitcairn-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 polaris10-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 polaris11-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 redwood-r600--.bc -> cedar-r600--.bc
-rw-r--r--   1 root root 2.5M Sep 18 11:03 spirv64-mesa3d-.spv
-rw-r--r--   1 root root 2.5M Sep 18 11:03 spirv-mesa3d-.spv
lrwxrwxrwx   1 root root   18 Sep 18 11:03 stoney-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 sumo2-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 sumo-r600--.bc -> cedar-r600--.bc
-rw-r--r--   1 root root 7.8M Sep 18 11:03 tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 tonga-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 turks-r600--.bc -> barts-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 verde-amdgcn--.bc -> 
tahiti-amdgcn--.bc

This seems to be only a naming issue, as adding a symlink with the appropriate 
name fixes it for me.


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

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

Versions of packages libclc-12 depends on:
ii  libclang-common-12-dev  1:12.0.1-9
ii  libclc-12-dev   1:12.0.1-9

libclc-12 recommends no packages.

libclc-12 suggests no packages.

-- no debconf information

Bug#994928: kde-style-qtcurve-qt5 should Provide: kde-style-qtcurve

[Giuseppe Bilotta]

Package: kde-style-qtcurve-qt5
Version: 1.9-7+b2
Severity: normal

I noticed this while cleaning up my installation from obsolete Qt4
stuff. The breeze package recommends kde-style-qtcurve, but this leads
to the installation of kde-style-qtcurve-qt4, not kde-style-qtcurve-qt5.
Marking kde-style-qtcurve-qt5 for auto installation thus leads to its
removal (instead of keeping it as a recommend from breeze).


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-style-qtcurve-qt5 depends on:
ii  kio   5.86.0-1
ii  libc6 2.32-4
ii  libkf5archive55.86.0-1
ii  libkf5completion5 5.86.0-1
ii  libkf5configcore5 5.86.0-1
ii  libkf5configwidgets5  5.86.0-1
ii  libkf5coreaddons5 5.86.0-1
ii  libkf5guiaddons5  5.86.0-1
ii  libkf5i18n5   5.86.0-1
ii  libkf5iconthemes5 5.86.0-1
ii  libkf5kdelibs4support55.86.0-1
ii  libkf5kiowidgets5 5.86.0-1
ii  libkf5style5  5.86.0-1
ii  libkf5widgetsaddons5  5.86.0-1
ii  libkf5windowsystem5   5.86.0-1
ii  libkf5xmlgui5 5.86.0-1
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-10
ii  libqt5dbus5   5.15.2+dfsg-10
ii  libqt5gui55.15.2+dfsg-10
ii  libqt5printsupport5   5.15.2+dfsg-10
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-10
ii  libqt5x11extras5  5.15.2-2
ii  libqtcurve-utils2 1.9-7+b2
ii  libstdc++611.2.0-7

kde-style-qtcurve-qt5 recommends no packages.

Versions of packages kde-style-qtcurve-qt5 suggests:
pn  gtk2-engines-qtcurve  

-- no debconf information

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Giuseppe Bilotta]

On Wed, Sep 22, 2021 at 8:32 AM Andreas Beckmann  wrote:
> So if it does matter abi-wise for intel-opencl-icd which version of llvm
> libigfoo1 was compiled against, we should model this in the dependency
> chain.

To be able to confirm this, I would need a version of all the libig*
stuff correctly
compiled against LLVM12 (rather than the mix-up we currently have for
libigdfcl1).
I can then test against intel-opencl-icd version 20.x, which is built
with LLVM11,
and (most probably) confirm that the setup is broken.

> It's probably best if all libigfoo1 library packages provide a virtual
> package libigfoo1-llvmXX (don't hardcode it, use substvars) and
> intel-opencl-icd depends on that (in addition to libigfoo1 (>= xx)) to
> specify the specific abi needed.
> (renaming the real package to libigfoo1-llvmXX each time the llvm major
> version changes is probably overkill)

The virtual ABI package sounds like the best choice.
I don't think renaming the real package makes sense,
at least at the moment. It might become useful if there ever is a need
for the different ABIs to be co-installed.

> Are there other users of libigfoo1 besides intel-opencl-icd?

The only one I can see is intel-media-va-driver{,-non-free} depending
on libigdgmm11,
but that particular package doesn't seem to have an LLVM dependency
(directly or not).

> We will proably still run into problems if different ICDs built against
> different LLVM versions are going to be loaded at the same time (e.g.
> pocl/llvm9 and intel/llvm1x) because the different llvm versions seem to
> stomp on each others internal bits. There are bugs open about that ...

FWIW, I haven't had these issues in a while now
(but I'm also building my own pocl, so maybe by chance I'm using the
same LLVM version anyway.)

> I may come up with a patch if time permits.

Much appreciated.

-- 
Giuseppe "Oblomov" Bilotta

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Giuseppe Bilotta]

Package: intel-opencl-icd
Followup-For: Bug #994833

Downgrading ONLY intel-opencl-icd to version 20.44.18297-1 leads to a
different error:

Abort was called at 41 line in file:
/build/intel-compute-runtime-7vSeZ9/intel-compute-runtime-20.44.18297/shared/source/built_ins/built_ins.cpp
Aborted

Downgrading ALSO libigc1 and libigdfcl1 to version 1.0.5353.1-2 makes
the package usable again. This makes me suspect that the issue is in
those libraries instead.

Running clinfo with
OCL_ICD_VENDORS=/etc/OpenCL/vendors/intel.icd LD_DEBUG=libs
gives me the following 

=
342713: find library=libOpenCL.so.1 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/usr/lib/x86_64-linux-gnu/libOpenCL.so.1
342713: 
342713: find library=libdl.so.2 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/lib/x86_64-linux-gnu/libdl.so.2
342713: 
342713: find library=libc.so.6 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/lib/x86_64-linux-gnu/libc.so.6
342713: 
342713: 
342713: calling init: /lib64/ld-linux-x86-64.so.2
342713: 
342713: 
342713: calling init: /lib/x86_64-linux-gnu/libc.so.6
342713: 
342713: 
342713: calling init: /lib/x86_64-linux-gnu/libdl.so.2
342713: 
342713: 
342713: calling init: /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
342713: 
342713: 
342713: initialize program: clinfo
342713: 
342713: 
342713: transferring control: clinfo
342713: 
342713: find library=libpthread.so.0 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/lib/x86_64-linux-gnu/libpthread.so.0
342713: 
342713: find library=libigdgmm.so.11 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/usr/lib/x86_64-linux-gnu/libigdgmm.so.11
342713: 
342713: find library=libstdc++.so.6 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6
342713: 
342713: find library=libm.so.6 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/lib/x86_64-linux-gnu/libm.so.6
342713: 
342713: find library=libgcc_s.so.1 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/lib/x86_64-linux-gnu/libgcc_s.so.1
342713: 
342713: 
342713: calling init: /lib/x86_64-linux-gnu/libpthread.so.0
342713: 
342713: 
342713: calling init: /lib/x86_64-linux-gnu/libgcc_s.so.1
342713: 
342713: 
342713: calling init: /lib/x86_64-linux-gnu/libm.so.6
342713: 
342713: 
342713: calling init: /usr/lib/x86_64-linux-gnu/libstdc++.so.6
342713: 
342713: 
342713: calling init: /usr/lib/x86_64-linux-gnu/libigdgmm.so.11
342713: 
342713: 
342713: calling init: 
/usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
342713: 
342713: find library=libigfxdbgxchg64.so [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/usr/lib/x86_64-linux-gnu/libigfxdbgxchg64.so
342713: 
342713: find library=libigfxdbginfo.so [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/usr/lib/x86_64-linux-gnu/libigfxdbginfo.so
342713: 
342713: find library=libelfdwarf.so [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:   trying file=/usr/lib/x86_64-linux-gnu/libelfdwarf.so
342713: 
342713: 
342713: calling init: /usr/lib/x86_64-linux-gnu/libelfdwarf.so
342713: 
342713: 
342713: calling init: /usr/lib/x86_64-linux-gnu/libigfxdbginfo.so
342713: 
342713: 
342713: calling init: /usr/lib/x86_64-linux-gnu/libigfxdbgxchg64.so
342713: 
342713: find library=libigdml.so.1 [0]; searching
342713:  search cache=/etc/ld.so.cache
342713:  search 

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Giuseppe Bilotta]

=0x7fffcf28) at ./opencl/source/api/api.cpp:137
#19 0x77f439f4 in _find_and_check_platforms (num_icds=7) at 
ocl_icd_loader.c:469
#20 __initClIcd () at ocl_icd_loader.c:773
#21 _initClIcd_real () at ocl_icd_loader.c:824
#22 0x77f4474e in _initClIcd () at ocl_icd_loader.c:853
#23 clGetPlatformIDs (num_entries=0, platforms=0x0, 
num_platforms=0x7fffe034) at ocl_icd_loader.c:1014

The issue is present also when intel-opencl-icd is the only installed
ICD.

I used to be able to use the ICD without issues on this machine. I'm not
sure which upgrade broke it (in particulr, I'm not sure if this was
broken by an upgrade of this package or by a kernel upgrade).

Cheers,

Giuseppe Bilotta


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages intel-opencl-icd depends on:
ii  libc6   2.32-4
ii  libgcc-s1   11.2.0-7
ii  libigc1 1.0.8279-1
ii  libigdfcl1  1.0.8279-1
ii  libigdgmm11 21.2.2+ds1-1
ii  libstdc++6  11.2.0-7
ii  ocl-icd-libopencl1  2.2.14-2

intel-opencl-icd recommends no packages.

intel-opencl-icd suggests no packages.

-- no debconf information

Bug#935950: fonts-symbola: Much newer version is available at upstream

[Giuseppe Bilotta]

Package: fonts-symbola
Version: 2.60-1.1
Followup-For: Bug #935950

The font (and the other ancient scripts fonts) have moved to
https://dn-works.com/ufas/

An even newer version of Symbola than previously reported has
also been released. However the UFAS License under which the fonts
are released

https://dn-works.com/wp-content/uploads/2020/UFAS-Docs/License.pdf

is non-free in the Debian sense (in particular, it's not for commercial
use).

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#974702: intel-opencl-icd causes all OpenCL programs to abort

[Giuseppe Bilotta]

On Sat, Nov 14, 2020 at 9:46 AM Timo Aaltonen  wrote:

> Hi, please try with the current version, I think this was due to the old
> driver being built with llvm10. 20.44 was uploaded yesterday.

> And 972620 should be fixed as well.

Hello, I just tested intel-opencl-icd 20.44.18297-1 with libigc1 and
libigdfcl1 at version 1.0.5353.1-2 and indeed both bugs seem to be
fixed.

(I'd be wary of the code still calling abort in case of issues,
though, since an ICD should just fail “properly” when things go wrong
during init.)

Thanks a lot,

Giuseppe Bilotta

-- 
Giuseppe "Oblomov" Bilotta

Bug#974702: intel-opencl-icd causes all OpenCL programs to abort

[Giuseppe Bilotta]

Package: intel-opencl-icd
Followup-For: Bug #974702

Some additional information: I have tried downgrading to previous
versions of the package, and I found out that:

intel-opencl-icd 20.13.16352-1 has the issue
intel-opencl-icd 20.02.15268-1 has not

In fact, with 20.02 clinfo at least works, even though kernels fail to
compile for this ICD giving a CL_OUT_OF_HOST_MEMORY (-6) error.

If I downgrate libigc1 and libigdfcl1 to 1.0.3627-2, both 20.02 and
20.13 work correctly, but 20.37.17906-1 still aborts.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages intel-opencl-icd depends on:
ii  libc62.31-4
ii  libgcc-s1 [libgcc1]  10.2.0-17
ii  libigc1  1.0.5353.1-2
ii  libigdfcl1   1.0.5353.1-2
ii  libigdgmm11  20.3.2+ds1-1
ii  libstdc++6   10.2.0-17
ii  ocl-icd-libopencl1   2.2.12-4

intel-opencl-icd recommends no packages.

intel-opencl-icd suggests no packages.

-- no debconf information

Bug#974702: intel-opencl-icd causes all OpenCL programs to abort

[Giuseppe Bilotta]

Package: intel-opencl-icd
Version: 20.37.17906-1
Severity: critical

When this package is installed, any OpenCL program will abort with the
message

Abort was called at 42 line in file:
/build/intel-compute-runtime-WsWnhf/intel-compute-runtime-20.37.17906/shared/source/built_ins/built_ins.cpp
Application Error

This is reproducible with a simple `clinfo -l`, but even something like
LibreOffice with OpenCL support enabled will fail to start (making it
impossible to actually even the LibreOffice configuration to disable
OpenCL), which is the reason for the critical severity.

Running `clinfo -l` under gdb shows the following backtrace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77da6537 in __GI_abort () at abort.c:79
#2  0x76baab53 in NEO::abortExecution () at 
./shared/source/helpers/abort.cpp:14
#3  0x76bc0b71 in NEO::abortUnrecoverable (line=line@entry=42, 
file=file@entry=0x76f1b868 
"/build/intel-compute-runtime-WsWnhf/intel-compute-runtime-20.37.17906/shared/source/built_ins/built_ins.cpp")
at ./shared/source/helpers/debug_helpers.cpp:24
#4  0x76ed07b4 in operator() (__closure=0x7fffdd60) at 
./shared/source/built_ins/built_ins.cpp:42
#5  std::__invoke_impl&> (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#6  std::__invoke&> (__fn=...) at /usr/include/c++/10/bits/invoke.h:95
#7  operator() (this=) at /usr/include/c++/10/mutex:717
#8  operator() (this=0x0) at /usr/include/c++/10/mutex:722
#9  _FUN () at /usr/include/c++/10/mutex:722
#10 0x7710b34f in __pthread_once_slow (once_control=0x55786400, 
init_routine=0x77495fc0 <__once_proxy>) at pthread_once.c:116
#11 0x76ed0ae2 in __gthread_once (__func=, 
__once=0x55786400) at 
/usr/include/x86_64-linux-gnu/c++/10/bits/gthr-default.h:700
#12 std::call_once&> (__f=..., __once=...) at 
/usr/include/c++/10/mutex:729
#13 NEO::BuiltIns::getSipKernel (this=0x55785ff0, type=, 
device=...) at ./shared/source/built_ins/built_ins.cpp:64
#14 0x76be2516 in NEO::initSipKernel (type=, device=...) 
at ./opencl/source/helpers/built_ins_helper.cpp:16
#15 0x76c29878 in NEO::Platform::initialize (this=0x557841b0, 
devices=std::vector of length 1, capacity 1 = {...}) at 
./opencl/source/platform/platform.cpp:145
#16 0x76bdc85d in clGetPlatformIDs (numEntries=, 
platforms=, numPlatforms=) at 
./opencl/source/api/api.cpp:100
#17 0x76bdce54 in clIcdGetPlatformIDsKHR (numEntries=0, platforms=0x0, 
numPlatforms=0x7fffe04c) at ./opencl/source/api/api.cpp:136
#18 0x77f51ae3 in _find_and_check_platforms (num_icds=5) at 
ocl_icd_loader.c:445
#19 __initClIcd () at ocl_icd_loader.c:652
#20 _initClIcd_real () at ocl_icd_loader.c:702
#21 0x77f524e3 in _initClIcd () at ocl_icd_loader.c:724
#22 clGetPlatformIDs (num_entries=0, platforms=0x0, 
num_platforms=0x7fffe170) at ocl_icd_loader.c:846
#23 0x55564d42 in main (argc=2, argv=0x7fffe2d8) at 
src/clinfo.c:3351

Note that no OpenCL ICD should _ever_ invoke abort: OpenCL has specific
ways to pass failure information up to the caller, those shold be used
instead.

(That aside, it's unclear why the failure even happens in the first
place.)


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages intel-opencl-icd depends on:
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-17
ii  libigc1 1.0.5353.1-2
ii  libigdfcl1  1.0.5353.1-2
ii  libigdgmm11 20.3.2+ds1-1
ii  libstdc++6  10.2.0-17
ii  ocl-icd-libopencl1  2.2.12-4

intel-opencl-icd recommends no packages.

intel-opencl-icd suggests no packages.

-- no debconf information

Bug#972620: building OpenCL kernels fails with error: unknown argument: '-dwarf-column-info'

[Giuseppe Bilotta]

Package: intel-opencl-icd
Version: 20.37.17906-1
Severity: important

Hello,

it seems that the last upgrade has broken the compilation of OpenCL
kernels, resulting in the error

   unknown argument: '-dwarf-column-info'

and thus preventing use of the Intel iGP as compute device.

The error is illustrated even by simply running `clinfo`, optionally directing
stdout to /dev/null so that only the error is visible (on stderr).

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages intel-opencl-icd depends on:
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-15
ii  libigc1 1.0.5186-1
ii  libigdfcl1  1.0.5064-2
ii  libigdgmm11 20.3.2+ds1-1
ii  libstdc++6  10.2.0-15
ii  ocl-icd-libopencl1  2.2.12-4

intel-opencl-icd recommends no packages.

intel-opencl-icd suggests no packages.

-- no debconf information

Bug#964335: linux-headers-amd64: cannot upgrade to 5.7.6-1

[Giuseppe Bilotta]

Package: linux-headers-amd64
Version: 5.6.14-2
Severity: serious

Try to upgrade linux-headers-amd64, linux-image-amd64 and linux-perf to
version 5.7.6-1 results in the following errors:

Preparing to unpack .../15-linux-headers-amd64_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-headers-amd64/copyright' not owned by package 
'linux-headers-amd64'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-headers-amd64/changelog.gz' not owned by package 
'linux-headers-amd64'
dpkg-maintscript-helper: error: directory 
'/usr/share/doc/linux-headers-amd64' contains files not owned by package 
linux-headers-amd64, cannot switch to symlink
dpkg: error processing archive 
/tmp/apt-dpkg-install-zTcKDN/15-linux-headers-amd64_5.7.6-1_amd64.deb 
(--unpack):
 new linux-headers-amd64 package pre-installation script subprocess 
returned error exit status 1
Preparing to unpack .../16-linux-image-amd64_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-image-amd64/NEWS.Debian.gz' not owned by package 
'linux-image-amd64'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-image-amd64/copyright' not owned by package 
'linux-image-amd64'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-image-amd64/changelog.gz' not owned by package 
'linux-image-amd64'
dpkg-maintscript-helper: error: directory 
'/usr/share/doc/linux-image-amd64' contains files not owned by package 
linux-image-amd64, cannot switch to symlink
dpkg: error processing archive 
/tmp/apt-dpkg-install-zTcKDN/16-linux-image-amd64_5.7.6-1_amd64.deb (--unpack):
 new linux-image-amd64 package pre-installation script subprocess returned 
error exit status 1
Preparing to unpack .../17-linux-perf_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file '/usr/share/doc/linux-perf/copyright' 
not owned by package 'linux-perf'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-perf/changelog.gz' not owned by package 'linux-perf'
dpkg-maintscript-helper: error: directory '/usr/share/doc/linux-perf' 
contains files not owned by package linux-perf, cannot switch to symlink
dpkg: error processing archive 
/tmp/apt-dpkg-install-zTcKDN/17-linux-perf_5.7.6-1_amd64.deb (--unpack):
 new linux-perf package pre-installation script subprocess returned error 
exit status 1

Note that the dependencies linux-headers-5.7.0-1-{amd64,common},
linux-image-5.7.0-1-amd64, linux-perf-5.7 have all been upgrade to
5.7.6-1, it's only the versionless one that fail.

(I'm not sure how to tag this as also affecting the linux-image-amd64 and
linux-perf packages, sorry.)

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-headers-amd64 depends on:
ii  linux-headers-5.6.0-2-amd64  5.6.14-2

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

-- no debconf information

Bug#953152: grass GUI fails to start with python traceback

[Giuseppe Bilotta]

Package: grass
Version: 7.8.2-1
Severity: important

Hello,

trying to start grass with the GUI results in the following traceback

--8<---

Launching  GUI in the background, please wait...
GRASS 7.8.2 (Etna):~ > Traceback (most recent call last):
  File "/usr/lib/python3.7/ctypes/__init__.py", line 97, in CFUNCTYPE
return _c_functype_cache[(restype, argtypes, flags)]
KeyError: (, (,), 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/grass78/gui/wxpython/wxgui.py", line 105, in OnInit
from lmgr.frame import GMFrame
  File "/usr/lib/grass78/gui/wxpython/lmgr/frame.py", line 51, in 
from lmgr.layertree import LayerTree, LMIcons
  File "/usr/lib/grass78/gui/wxpython/lmgr/layertree.py", line 38, in 
from mapdisp.frame import MapFrame
  File "/usr/lib/grass78/gui/wxpython/mapdisp/frame.py", line 33, in 
from mapdisp.toolbars import MapToolbar, NvizIcons
  File "/usr/lib/grass78/gui/wxpython/mapdisp/toolbars.py", line 22, in 
from nviz.main import haveNviz
  File "/usr/lib/grass78/gui/wxpython/nviz/main.py", line 24, in 
from nviz import mapwindow
  File "/usr/lib/grass78/gui/wxpython/nviz/mapwindow.py", line 42, in 
from nviz.workspace import NvizSettings
  File "/usr/lib/grass78/gui/wxpython/nviz/workspace.py", line 23, in 
from nviz import wxnviz
  File "/usr/lib/grass78/gui/wxpython/nviz/wxnviz.py", line 51, in 
from grass.lib.gis import *
  File "/usr/lib/grass78/etc/python/grass/lib/gis.py", line 552, in 
('checker', CFUNCTYPE(UNCHECKED(c_int), String)),
  File "/usr/lib/python3.7/ctypes/__init__.py", line 99, in CFUNCTYPE
class CFunctionType(_CFuncPtr):
TypeError: item 1 in _argtypes_ passes a union by value, which is unsupported.
OnInit returned false, exiting...

--8<---

and the GUI not starting.

I have found an issue on the osgeo trac

https://trac.osgeo.org/grass/ticket/4015

that seems to indicate the issue is actually in the Python 3
interpreter.

Best regards,

GB



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

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

Versions of packages grass depends on:
ii  grass-core  7.8.2-1+b2
ii  grass-gui   7.8.2-1+b2

Versions of packages grass recommends:
ii  grass-doc  7.8.2-1

Versions of packages grass suggests:
pn  grass-dev  

-- no debconf information

Bug#941282: ifupdown: pre-up scripts being executed AFTER up script, fails to bring up wireless network with WPA

[Giuseppe Bilotta]

Package: ifupdown
Version: 0.8.35+b1
Severity: important

Trying to bring up any wireless interface on a network with WPA auth
fails in a very peculiar way: the interface gets correctly configured,
including WPA auth, DHCP manages to get an IP, and then an error about
failure to bring up wpa_supplicant causes the interface to be brought
down.

wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
ifup: failed to bring up ***

Debugging `ifup -v wlan=***` gives the following log:

-- Log:

ifup: reading directory /etc/network/interfaces.d
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***
ifup: parsing file /etc/network/interfaces.d/***

ifup: configuring interface wlan0=*** (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
wpa_supplicant: wpa-driver nl80211,wext (default)
wpa_supplicant: /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i 
wlan0 -D nl80211,wext -C /run/wpa_supplicant
wpa_supplicant: creating sendsigs omission pidfile: 
/run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
wpa_supplicant: ctrl_interface socket located at /run/wpa_supplicant/wlan0
wpa_supplicant: configuring network block -- 0
wpa_supplicant: wpa-ssid "***" -- OK
wpa_supplicant: wpa-psk * -- OK
wpa_supplicant: enabling network block 0 -- OK

/sbin/dhclient -4 -v -i -pf /run/dhclient.wlan0.pid -lf 
/var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases 
wlan0   
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/e8:2a:ea:ab:36:3c
Sending on   LPF/wlan0/e8:2a:ea:ab:36:3c
Sending on   Socket/fallback
DHCPREQUEST for 192.168.0.3 on wlan0 to 255.255.255.255 port 67
DHCPREQUEST for 192.168.0.3 on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
DHCPOFFER of 192.168.0.3 from 192.168.0.1
DHCPREQUEST for 192.168.0.3 on wlan0 to 255.255.255.255 port 67
DHCPACK of 192.168.0.3 from 192.168.0.1
RTNETLINK answers: File exists
bound to 192.168.0.3 -- renewal in 21269 seconds.
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/00check-network-cable
run-parts: executing /etc/network/if-up.d/10check-duplicate-ip
run-parts: executing /etc/network/if-up.d/10check-duplicate-ip6
run-parts: executing /etc/network/if-up.d/20static-routes
run-parts: executing /etc/network/if-up.d/30check-gateway
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/openvpn
run-parts: executing /etc/network/if-up.d/wpasupplicant
ifup: configuring interface wlan0=marfib (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
wpa_supplicant: terminating wpa_supplicant daemon via pidfile 
/run/wpa_supplicant.wlan0.pid
Stopped /sbin/wpa_supplicant (pid 2590).
wpa_supplicant: removing 
/run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
wpa_supplicant: wpa-driver nl80211,wext (default)
wpa_supplicant: /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i 
wlan0 -D nl80211,wext -C 

Bug#940902: doesn't read the data

[Giuseppe Bilotta]

Package: cycle
Version: 0.3.1-16
Followup-For: Bug #940902

I'm experiencing this issue as well. For debugging purposes, I moved the
previous .cycle directory out of the way, created a new user, saved, and
on restart it asked me to create a new user again —despite having
created the new profile. So the bug is present even for data file
created in the new version, not only when trying to read old data.

-- 
Giuseppe "Oblomov" Bilotta


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

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

Versions of packages cycle depends on:
ii  python3   3.7.3-1
ii  python3-wxgtk4.0  4.0.6+dfsg-2

cycle recommends no packages.

cycle suggests no packages.

-- no debconf information

Bug#940651: cycle: package installation fails at configuration stage due to TabError

[Giuseppe Bilotta]

Package: cycle
Version: 0.3.1-15
Severity: serious

Upgrading cycle to the latest version in unstable leads to the following
error during configuration:

Sorry: TabError: inconsistent use of tabs and spaces in indentation (cycle.py, 
line 29)

This is due to the mix of 4 spaces for one level of indent vs 1 tab for
two levels, which is not supported in Python3.

Best regards,

Giuseppe Bilotta


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

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

Versions of packages cycle depends on:
ii  python3   3.7.3-1
ii  python3-wxgtk4.0  4.0.6+dfsg-2

cycle recommends no packages.

cycle suggests no packages.

-- no debconf information

Bug#926393: surf: Cannot read local files/ directories: "Error opening file [filename] : Permission denied"

[Giuseppe Bilotta]

Hello Reiner,

On Thu, Jun 20, 2019 at 11:43 AM Reiner Herrmann  wrote:
> On Thu, Jun 20, 2019 at 09:30:59AM +0200, Giuseppe Bilotta wrote:
> > I came across this issue just now. This is an apparmor profile issue,
> > since by default it's configured to prevent access to local files except
> > for a small selection (it even fails to load the corret theme in my
> > case).
> >
> > A temporary workaround until this is fixed is to put apparmor in
> > complain mode for surf (`aa-complain /usr/bin/surf` as root should do
> > it).
>
> Local files are intentionally not allowed to be accessed by the browser,
> expect those needed for it to work properly.

While I appreciate the intent behind this restriction (prevent the
usage of the browser as a remote attach vector), the downsides are too
vast. It effectively prevents the use of that browser to browse/view
local HTML files or SVG images, something which is actually pretty
common. It also prevents explicit (user-controlled) requests to access
local files, e.g. to upload them to a website (attachments to email
with webmail, custom images for forum profiles and whatnot).

I do not think the kind of security that this profile intends to
provide can actually be provided by AppArmor profiles, because they
get too restrictive; non-local access to local files is something that
the browser must protect against in its own code, because the choice
can only be made based on contextual information that is not available
to AppArmor.

> Which theme files does it fail to load?

Here's the full audit log with surf in complain mode when I launch it
from the command-line to view a local HTML file.

[  +0.02] audit: type=1400 audit(1561092652.194:52):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/usr/share/themes/Breeze/gtk-3.20/gtk.css" pid=19839 comm="surf"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  +0.113718] audit: type=1400 audit(1561092652.306:53):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/.uuid" pid=19839 comm="surf"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.04] audit: type=1400 audit(1561092652.306:54):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/" pid=19839 comm="surf"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.166007] audit: type=1400 audit(1561092652.474:55):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/usr/share/themes/Breeze/gtk-3.20/gtk.css" pid=19847
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000
ouid=0
[  +0.049100] audit: type=1400 audit(1561092652.522:56):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/.uuid" pid=19847
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000
ouid=1000
[  +0.06] audit: type=1400 audit(1561092652.522:57):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/" pid=19847
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000
ouid=1000
[  +0.043384] audit: type=1400 audit(1561092652.566:58):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/file.html" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.023214] audit: type=1400 audit(1561092652.586:59):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/file.css" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.88] audit: type=1400 audit(1561092652.586:60):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/otherfile.css" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.000457] audit: type=1400 audit(1561092652.590:61):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/image.png" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000


(Sorry for the line wrap, this is being sent from gmail.)

-- 
Giuseppe "Oblomov" Bilotta

Bug#926393: surf: Cannot read local files/ directories: "Error opening file [filename] : Permission denied"

[Giuseppe Bilotta]

Package: surf
Version: 2.0+git20181009-4
Followup-For: Bug #926393

I came across this issue just now. This is an apparmor profile issue,
since by default it's configured to prevent access to local files except
for a small selection (it even fails to load the corret theme in my
case).

A temporary workaround until this is fixed is to put apparmor in
complain mode for surf (`aa-complain /usr/bin/surf` as root should do
it).

(I'm not sure if there is a bugtracker tag for apparmor profiles.)


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

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

Versions of packages surf depends on:
ii  libc6 2.28-10
ii  libgcr-base-3-1   3.28.1-1
ii  libgcr-ui-3-1 3.28.1-1
ii  libglib2.0-0  2.58.3-2
ii  libgtk-3-03.24.5-1
ii  libwebkit2gtk-4.0-37  2.24.2-dmo1
ii  libx11-6  2:1.6.7-1

Versions of packages surf recommends:
ii  curl7.64.0-4
ii  konsole [x-terminal-emulator]   4:18.04.0-1
ii  rxvt-unicode [x-terminal-emulator]  9.22-6
ii  stterm [x-terminal-emulator]0.8.2-1
ii  suckless-tools  44-1
ii  x11-utils   7.7+4
ii  xterm [x-terminal-emulator] 344-1

Versions of packages surf suggests:
ii  apparmor  2.13.2-10

-- no debconf information

Bug#921533: nvidia-cuda-dev: cannot install with uuid-dev

[Giuseppe Bilotta]

Package: nvidia-cuda-dev
Version: 10.0.130-1
Severity: normal

Hello,

trying to install nvidia-cuda-dev when uuid-dev is installed fails
because both packages have a '/usr/share/man/man3/uuid.3.gz' file. The
one in nvidia-cuda-dev is a symlink to the cudaDeviceProp man page
(because cudaDeviceProp now has an uuid member field).

(I was tempted to up the severity of the bug due to uuid-dev being in
the dependency chain of several “essential” UI -dev packages, including
xorg-dev, libgtk-3-dev etc, but ultimately decided not to.)

Cheers,

GB

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

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

Versions of packages nvidia-cuda-dev depends on:
ii  libaccinj64-10.0  10.0.130-1
ii  libcublas10.0 10.0.130-1
ii  libcudart10.0 10.0.130-1
ii  libcufft10.0  10.0.130-1
ii  libcufftw10.0 10.0.130-1
ii  libcuinj64-10.0   10.0.130-1
ii  libcurand10.0 10.0.130-1
ii  libcusolver10.0   10.0.130-1
ii  libcusparse10.0   10.0.130-1
ii  libnppc10.0   10.0.130-1
ii  libnppial10.0 10.0.130-1
ii  libnppicc10.0 10.0.130-1
ii  libnppicom10.010.0.130-1
ii  libnppidei10.010.0.130-1
ii  libnppif10.0  10.0.130-1
ii  libnppig10.0  10.0.130-1
ii  libnppim10.0  10.0.130-1
ii  libnppist10.0 10.0.130-1
ii  libnppisu10.0 10.0.130-1
ii  libnppitc10.0 10.0.130-1
ii  libnpps10.0   10.0.130-1
ii  libnvblas10.0 10.0.130-1
ii  libnvgraph10.010.0.130-1
ii  libnvjpeg10.0 10.0.130-1
ii  libnvrtc10.0  10.0.130-1
ii  libnvtoolsext110.0.130-1
ii  libnvvm3  10.0.130-1
pn  libthrust-dev 

Versions of packages nvidia-cuda-dev recommends:
ii  libcuda1 410.93-1
ii  libgl1-mesa-dev [libgl-dev]  18.3.2-1
pn  libnvcuvid1  
ii  libvdpau-dev 1.1.1-9

nvidia-cuda-dev suggests no packages.

-- no debconf information

Bug#919647: CUDA 9.2.148 depends on driver version 396.37 or higher

[Giuseppe Bilotta]

On Fri, Jan 18, 2019 at 10:45 AM Andreas Beckmann  wrote:
>
> On 2019-01-18 10:19, Giuseppe Bilotta wrote:
> > Package: nvidia-cuda-dev
> > Version: 9.2.148-5
> > Severity: important
>
> > it is currently impossible to do any CUDA development and deployment in
> > (a fresh install of) Debian testing and unstable, due to an
> > incompatibility between the available CUDA toolkit version and the
> > available NVIDIA driver versions.
>
> It was intentional relax the driver dependency in order to perform the
> CUDA 9.2 transition in time for the transition freeze.
> Please use the drivers from experimental for CUDA.
> I don't want to upload a new driver version to unstable before I got the
> driver in stretch updated to the well tested 390.xx series in sid.

Thanks for the reply. So I assume you expect to be able to complete
the upgrade of stretch to 390.xx and the subsequent migration of
410.xx to testing and unstable before the hard freeze? Otherwise, I'm
a bit worried that with this early transition we'll end up having an
unusable CUDA in buster.

Best regards,

GB

Bug#919647: CUDA 9.2.148 depends on driver version 396.37 or higher

[Giuseppe Bilotta]

Package: nvidia-cuda-dev
Version: 9.2.148-5
Severity: important

Hello,

it is currently impossible to do any CUDA development and deployment in
(a fresh install of) Debian testing and unstable, due to an
incompatibility between the available CUDA toolkit version and the
available NVIDIA driver versions.

For CUDA 9.2.148, the minimum driver version is 396.37, which is
currently unavailable in testing and unstable. I believe there is an
issue in the dependencies (the Recommends for nvidia-cuda-dev, as well
as the ones for libcudart9.2).

(I understand that reverting to 9.1 is problematic due to the reduction
of available gcc versions, so it might be necessary to migrate 410.x
from experimental?)

Best regards,

GB


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

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

Versions of packages nvidia-cuda-dev depends on:
ii  libaccinj64-9.2  9.2.148-5
ii  libcublas9.2 9.2.148-5
ii  libcudart9.2 9.2.148-5
ii  libcufft9.2  9.2.148-5
ii  libcufftw9.2 9.2.148-5
ii  libcuinj64-9.2   9.2.148-5
ii  libcurand9.2 9.2.148-5
ii  libcusolver9.2   9.2.148-5
ii  libcusparse9.2   9.2.148-5
ii  libnppc9.2   9.2.148-5
ii  libnppial9.2 9.2.148-5
ii  libnppicc9.2 9.2.148-5
ii  libnppicom9.29.2.148-5
ii  libnppidei9.29.2.148-5
ii  libnppif9.2  9.2.148-5
ii  libnppig9.2  9.2.148-5
ii  libnppim9.2  9.2.148-5
ii  libnppist9.2 9.2.148-5
ii  libnppisu9.2 9.2.148-5
ii  libnppitc9.2 9.2.148-5
ii  libnpps9.2   9.2.148-5
ii  libnvblas9.2 9.2.148-5
ii  libnvgraph9.29.2.148-5
ii  libnvrtc9.2  9.2.148-5
ii  libnvtoolsext1   9.2.148-5
ii  libnvvm3 9.2.148-5
ii  libthrust-dev1.9.2~9.2.148-5

Versions of packages nvidia-cuda-dev recommends:
ii  libcuda1 390.87-3
ii  libgl1-mesa-dev [libgl-dev]  18.2.8-2
ii  libnvcuvid1  390.87-3
ii  libvdpau-dev 1.1.1-9

nvidia-cuda-dev suggests no packages.

-- no debconf information

Bug#901432: calligra-gemini needs qml-module-qtwebengine, but does not depend on it

[Giuseppe Bilotta]

Package: calligra-gemini
Version: 1:3.1.0+dfsg-2+b1
Severity: normal

Installing calligra-gemini without qml-module-qtwebengine results in an
completely empty UI, with the following errors being output on console:

--8<-

file:///usr/share/calligragemini/calligragemini.qml:45:34: Type WelcomePage 
unavailable 
 Component { id: welcomePage; WelcomePage { } } 
  ^
file:///usr/share/calligragemini/qml/WelcomePage.qml:85:39: Type 
WelcomePageCloud unavailable 
 Component { id: welcomePageCloud; WelcomePageCloud { } } 
   ^
file:///usr/share/calligragemini/qml/welcomepages/WelcomePageCloud.qml:117:9: 
Type CloudAccounts unavailable 
 CloudAccounts { 
 ^
file:///usr/share/calligragemini/qml/welcomepages/cloud/CloudAccounts.qml:193:9:
 Type AddDropbox unavailable 
 AddDropbox { addEmpty: addEmptyComp; } 
 ^
file:///usr/share/calligragemini/qml/welcomepages/cloud/AddDropbox.qml:42:5: 
Type Dropbox.SetupPage unavailable 
 Dropbox.SetupPage { 
 ^
file:///usr/share/calligragemini/qml/welcomepages/cloud/dropbox/SetupPage.qml:81:9:
 Type LoginPage unavailable 
 LoginPage { } 
 ^
file:///usr/share/calligragemini/qml/welcomepages/cloud/dropbox/LoginPage.qml:31:5:
 Type DropboxWebView unavailable 
 DropboxWebView { id: webView } 
 ^
file:///usr/share/calligragemini/qml/welcomepages/cloud/dropbox/DropboxWebView.qml:20:1:
 module "QtWebEngine" is not installed 
 import QtWebEngine 1.5 
 ^

--8<-


This is solved by installing qml-module-qtwebengine. So either calligra-gemini
(or maybe calligra-gemini-data, which actually holds the QMLs) should depend on 
qml-module-qtwebengine.

(A possible alternative might be to disable DropBox support if the QtWebEngine
module was not present, maybe?)



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

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

Versions of packages calligra-gemini depends on:
ii  calligra-gemini-data  1:3.1.0+dfsg-2
ii  calligra-libs 1:3.1.0+dfsg-2+b1
ii  calligrasheets1:3.1.0+dfsg-2+b1
ii  calligrastage 1:3.1.0+dfsg-2+b1
ii  calligrawords 1:3.1.0+dfsg-2+b1
ii  libc6 2.27-3
ii  libgit2-260.26.0+dfsg.1-1.2
ii  libkf5configcore5 5.46.0-1
ii  libkf5configwidgets5  5.46.0-1
ii  libkf5coreaddons5 5.46.0-1
ii  libkf5crash5  5.46.0-1
ii  libkf5i18n5   5.46.0-1
ii  libkf5iconthemes5 5.46.0-1
ii  libkf5widgetsaddons5  5.46.0-1
ii  libkf5xmlgui5 5.46.0-1
ii  libqt5core5a  5.10.1+dfsg-7
ii  libqt5gui55.10.1+dfsg-7
ii  libqt5network55.10.1+dfsg-7
ii  libqt5qml55.10.1-4
ii  libqt5quick5  5.10.1-4
ii  libqt5quickwidgets5   5.10.1-4
ii  libqt5widgets55.10.1+dfsg-7
ii  libstdc++68.1.0-5

calligra-gemini recommends no packages.

calligra-gemini suggests no packages.

-- no debconf information

Bug#895980: zathura: symbol lookup error: zathura: undefined symbol: synctex_next_result

[Giuseppe Bilotta]

Package: zathura
Version: 0.3.9-1
Severity: normal

This error has appeared after an upgrade of the texlive system, which includes
a new libsynctex1. Probably zathura needs to be rebuilt against the latest 
libsynctex


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

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

Versions of packages zathura depends on:
ii  libc62.27-3
ii  libcairo21.15.10-2
ii  libgirara-gtk3-3 0.2.9-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.30-1
ii  libmagic11:5.32-2
ii  libpango-1.0-0   1.42.1-1
ii  libsqlite3-0 3.23.1-1
ii  libsynctex1  2018.20180416.47457-1
ii  zathura-pdf-poppler  0.2.9-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  chromium [www-browser]  66.0.3359.26-2
ii  dillo [www-browser] 3.0.5-4
ii  elinks [www-browser]0.12~pre6-13
ii  falkon [www-browser]3.0.0-3
ii  firefox [www-browser]   59.0.2-1
ii  firefox-esr [www-browser]   52.7.3esr-1
ii  konqueror [www-browser] 4:17.08.3-2
ii  links2 [www-browser]2.14-5
ii  lynx [www-browser]  2.8.9dev17-1
ii  netsurf-fb [www-browser]3.6-3.1
ii  opera [www-browser] 12.16.1860
ii  surf [www-browser]  2.0-5
ii  vivaldi-snapshot [www-browser]  1.15.1147.23-1
ii  w3m [www-browser]   0.5.3-36
ii  zathura-cb  0.1.8-2
ii  zathura-djvu0.2.8-1
ii  zathura-ps  0.2.6-1

-- no debconf information

Bug#895593: inadequate apparmor profile

[Giuseppe Bilotta]

Package: surf
Version: 2.0-5
Severity: normal

Running surf triggers the following apparmor alerts:

audit: type=1400 audit(1523602672.524:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/surf" pid=865 
comm="apparmor_parser"
audit: type=1400 audit(1523606448.089:48): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/home/USERNAME/.config/gtk-3.0/settings.ini" pid=4505 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606448.257:49): apparmor="DENIED" 
operation="file_mmap" profile="/usr/bin/surf" 
name="/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so" pid=4505 
comm="surf" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
audit: type=1400 audit(1523606448.257:50): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/home/USERNAME/.cache/gtk-3.0/compose/93817a95.cache" pid=4505 
comm="pool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606448.257:51): apparmor="DENIED" 
operation="mknod" profile="/usr/bin/surf" 
name="/home/USERNAME/.cache/gtk-3.0/compose/93817a95.cache.1A3JHZ" pid=4505 
comm="pool" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606448.297:52): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/usr/share/fontconfig/conf.avail/" pid=4505 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1523606448.493:53): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/home/USERNAME/.config/gtk-3.0/settings.ini" pid=4522 
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606448.537:54): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/usr/share/fontconfig/conf.avail/" pid=4522 comm="WebKitWebProces" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1523606448.561:55): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
pid=4524 comm="WebKitNetworkPr" requested_mask="wc" denied_mask="wc" fsuid=1000 
ouid=1000
audit: type=1400 audit(1523606448.561:56): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
pid=4524 comm="WebKitNetworkPr" requested_mask="wc" denied_mask="wc" fsuid=1000 
ouid=1000
audit: type=1400 audit(1523606448.561:57): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
pid=4524 comm="WebKitNetworkPr" requested_mask="wc" denied_mask="wc" fsuid=1000 
ouid=1000
audit: type=1400 audit(1523606456.793:65): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/home/USERNAME/.config/gtk-3.0/settings.ini" pid=4557 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606456.853:66): apparmor="DENIED" 
operation="file_mmap" profile="/usr/bin/surf" 
name="/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so" pid=4557 
comm="surf" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
audit: type=1400 audit(1523606456.857:67): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/home/USERNAME/.cache/gtk-3.0/compose/93817a95.cache" pid=4557 
comm="pool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606456.857:68): apparmor="DENIED" 
operation="mknod" profile="/usr/bin/surf" 
name="/home/USERNAME/.cache/gtk-3.0/compose/93817a95.cache.9UJWHZ" pid=4557 
comm="pool" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606456.865:69): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/usr/share/fontconfig/conf.avail/" pid=4557 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1523606456.901:70): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/home/USERNAME/.config/gtk-3.0/settings.ini" pid=4564 
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1523606456.933:71): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" 
name="/usr/share/fontconfig/conf.avail/" pid=4564 comm="WebKitWebProces" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1523606456.949:72): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
pid=4566 comm="WebKitNetworkPr" requested_mask="wc" denied_mask="wc" fsuid=1000 
ouid=1000
audit: type=1400 audit(1523606456.949:73): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
pid=4566 comm="WebKitNetworkPr" requested_mask="wc" denied_mask="wc" fsuid=1000 
ouid=1000
audit: type=1400 audit(1523606456.949:74): apparmor="DENIED" 
operation="open" profile="/usr/bin/surf" name="/run/user/1000/dconf/user" 
pid=4566 comm="WebKitNetworkPr" 

Bug#890099: Th symlink seems to be invisible to all services

[Giuseppe Bilotta]

With some further testing, it would seem that the issue of not being
able to find/access anything under that path with the intermediate
symlink affects all services,not just nfs. I'm seeing it with
git-daemon-run (which runs via runit), as well as with apache (the
gitweb site is unable to follow those symlinks). I'm completely
stymied at what the cause might be. Is systemd somehow passing a
different view of mounted filesystems to its children?

-- 
Giuseppe "Oblomov" Bilotta

Bug#890099: nfs-server: fails to start if export path has intermediate symlinks

[Giuseppe Bilotta]

Package: nfs-kernel-server
Version: 1:1.3.4-2.1+b1
Severity: normal

I have recently changed my NFS setup so that one of the intermediate paths for 
the
exported filesystem is a symlink. With this setup, trying to start the system 
with

systemctl start nfs-server

fails, with `systemctl status nfs-server` reporting:

● nfs-server.service - NFS server and services  

 
   Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sat 2018-02-10 19:06:15 CET; 14h ago
  Process: 27521 ExecStopPost=/usr/sbin/exportfs -f (code=exited, 
status=0/SUCCESS)
  Process: 27520 ExecStopPost=/usr/sbin/exportfs -au (code=exited, 
status=0/SUCCESS)
  Process: 27519 ExecStartPre=/usr/sbin/exportfs -r (code=exited, 
status=1/FAILURE)

Feb 10 19:06:15 labrador systemd[1]: Starting NFS server and services...
Feb 10 19:06:15 labrador exportfs[27519]: exportfs: Failed to stat 
///: No such file or directory
Feb 10 19:06:15 labrador exportfs[27519]: exportfs: Failed to stat 
///: No such file or directory
Feb 10 19:06:15 labrador systemd[1]: nfs-server.service: Control process 
exited, code=exited status=1
Feb 10 19:06:15 labrador systemd[1]: nfs-server.service: Failed with result 
'exit-code'.
Feb 10 19:06:15 labrador systemd[1]: Stopped NFS server and services.

journalctl -u nfs-server-.service -b has exactly those lines too.

Running all the appropriate daemons manually, including the sequence exportfs 
-f, exportfs -au, exportfs -r works correctly,
with the final export being /// as expected.


-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
133   tcp   2049  nfs
134   tcp   2049  nfs
1002273   tcp   2049
133   udp   2049  nfs
1002273   udp   2049
1000211   udp  49410  nlockmgr
1000213   udp  49410  nlockmgr
1000214   udp  49410  nlockmgr
1000211   tcp  38281  nlockmgr
1000213   tcp  38281  nlockmgr
1000214   tcp  38281  nlockmgr
151   udp  44790  mountd
151   tcp  36505  mountd
152   udp  58345  mountd
152   tcp  40191  mountd
153   udp  50245  mountd
153   tcp  39943  mountd
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=""
RPCSVCGSSDOPTS=""
-- /etc/exports --
/// (rw,sync,no_root_squash,no_subtree_check) 
(rw,sync,no_root_squash,no_subtree_check) (ro,sync,root_squash,no_subtree_check)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs

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

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

Versions of packages nfs-kernel-server depends on:
ii  init-system-helpers  1.51
ii  keyutils 1.5.9-9.2
ii  libblkid12.30.2-0.1
ii  libc62.26-2
ii  libcap2  1:2.25-1.2
ii  libsqlite3-0 3.21.0-1
ii  libtirpc10.2.5-1.2
ii  libwrap0 7.6.q-27
ii  lsb-base 9.20170808
ii  netbase  5.4
ii  nfs-common   1:1.3.4-2.1+b1
ii  ucf  3.0036

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information

Bug#878667: New upstream version available (1.4.6)

[Giuseppe Bilotta]

Package: lua-ldoc
Version: 1.4.3-5+nmu1
Severity: normal

Hello,

version 1.4.6 of lua-ldoc was released nearly a year ago (relevant tag on
GitHub: https://github.com/stevedonovan/LDoc/tree/1.4.6). It has a number of
fixes and improvements (among which, support for the --fatalwarnings command
line option) that are useful in development. It would be nice to have it
packaged in Debian 8-)

Best regards,

GB

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

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

Versions of packages lua-ldoc depends on:
ii  lua-any 24
ii  lua-filesystem  1.6.3-1
ii  lua-penlight1.3.2-2
ii  lua5.1  5.1.5-8.1+b2

lua-ldoc recommends no packages.

Versions of packages lua-ldoc suggests:
pn  lua-discount  
pn  lua-markdown  

-- no debconf information

Bug#853750: Merge this bug into 848257

[Giuseppe Bilotta]

Sorry for the late reply, for some reason I didn't get this message in my mail.


On Tue, 16 May 2017 15:31:47 -0500 Liam Healy
 wrote:
> I believe this bug is already reported, see https://bugs.debian.org/848257.

I'm not sure it's the same bug. The java runtime warning doesn't seem
to be connected with the impossibility to view HDF files.

Using hdfview version 2.9-3+b2 with libjhdf{4,5}-{java,jni} version
2.9-3+b2 works, even though I get the warning about the java runtime
in #848257.

Upgrading libjhdf* makes all HDF5 come up blank. So the warning seems
like a separate problems.

I think the problem here is different, and it depends on an
non-documented ABI incomatibility between HDF5 versions. the 2.9-3 jni
depends on libhdf5-8 (1.8.13), whereas the 2.11 one depends on
libhdf5-100 (1.10). I suspect the Java bindings were not properly
updated to the latest ABI of libhdf5.

The upstream page
https://support.hdfgroup.org/products/java/release/download.html has
some notices about this. Among other things, it remarks:

> Please be aware that the software included below uses the HDF4 and HDF5 Java 
> wrappers with 32-bit object identifiers for use with HDF5-1.8.17 and HDF 
> 4.2.12

Even more importantly, the ABI compatibility check for libhdf5
https://abi-laboratory.pro/tracker/timeline/hdf5/ remark that 1.8.14
introduced some breaking changes compared to previous HDF5 versions,
and further changes were introduced in 1.10.0. I am not sure how this
all affects hdfview, but it might be worth to at least try and upgrade
to the latest version (2.13), since otherwise Stretch will have no
usable version of hdfview.

Bug#862452: Update to newer QtWebKit

[Giuseppe Bilotta]

On Sat, May 13, 2017 at 12:42 PM, Konstantin Tokarev  wrote:
> Note that there is unofficial package already:
>
> http://repo.paretje.be/unstable/#
>
> See packages libqt5webkit5, libqt5webkit5-dev
>
> Git repo of package is at 
> https://gitlab.com/paretje/qtwebkit/tree/master/debian
>
> Package is loosely based of webkitgtk's, and contains a few build 
> dependencies that are not actually needed:
>
> libharfbuzz-dev, libfreetype6-dev, libfontconfig1-dev (these are used when 
> qtbase is built, not directly in qtwebkit)
> libgnutls28-dev, libsoup2.4-dev, libenchant-dev, geoclue-2.0, libsecret-1-dev 
> - not used at all
> libxt-dev - probably unused as well
>
> Otherwise, packaging files look good to me


Interesting, thanks a lot. That looks like it will make the work much
easier for the maintainers after the Stretch release, just what they
were looking for ;-).

I wonder if there's a reason why they went with the same package name
instead of using a different name (say, libqt5webkit-ng5), and then
adding Provides/Breaks to allow replacement.


-- 
Giuseppe "Oblomov" Bilotta

Bug#862452: Update to newer QtWebKit

[Giuseppe Bilotta]

Package: libqt5webkit5
Version: 5.7.1+dfsg-1
Severity: wishlist

QtWebKit has recently restarted, due to it being faster,
lighter and more standard compliant than the Blink-derived
QtWebEngine, see e.g.

http://qtwebkit.blogspot.it/2016/08/qtwebkit-im-back.html

for the announcement (and comparisons). A “Technology
Preview” compatible with Qt 5.8 is available

https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5

Would it be possible to package it (as `libqt5webkit-ng5`
for example) when Qt gets upgraded? It might also be possible
to package the previous Tech Preview 3 

https://github.com/annulen/webkit/releases/tag/qtwebkit-tp3

for Qt 5.7.

The upgrade would give better HTML5 support to browsers
relying on this engine, such as the Otter browser, as shown
in the Otter issue about MathML support:

https://github.com/OtterBrowser/otter-browser/issues/1358


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

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

Versions of packages libqt5webkit5 depends on:
ii  dpkg  1.18.23
ii  libc6 2.24-10
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglib2.0-0  2.50.3-2
ii  libgstreamer-plugins-base1.0-01.10.4-1
ii  libgstreamer1.0-0 1.10.4-1
ii  libicu57  57.1-6
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpng16-16   1.6.28-1
ii  libqt5core5a [qtbase-abi-5-7-1]   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5opengl5 5.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5qml5 [qtdeclarative-abi-5-7-0]  5.7.1-2+b2
ii  libqt5quick5  5.7.1-2+b2
ii  libqt5sql55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libsqlite3-0  3.16.2-3
ii  libstdc++66.3.0-17
ii  libwebp6  0.5.2-1
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxml2   2.9.4+dfsg1-2.2
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-2.1
ii  zlib1g1:1.2.8.dfsg-5

libqt5webkit5 recommends no packages.

libqt5webkit5 suggests no packages.

-- no debconf information

Bug#857679: reopen #761909: system fails to shutdown if there is a mounted nfs share, due to it not being unmounted before network is brought down

[Giuseppe Bilotta]

Package: ifupdown
Version: 0.8.19
Severity: normal

I am still affected by issue #761909. Essentially, if there is a mounted nfs
share, shutdown will stall forever trying to unmount it unsuccessfully due to
the network going down before the attempted unmounting of the share. This only
happens with systemd.

The mount unit correctly depends on networking.service:

oblomov@oblomov:~$ systemctl list-dependencies oneforall.mount 
oneforall.mount
● ├─-.mount
● ├─system.slice
● └─network-online.target
●   └─networking.service
oblomov@oblomov:~$ 

but apparently this is not sufficient to get it unmounted before the network is
brought down. It's also hard to see why the network gets brought down early,
because the logs are always corrupt since the only way to complete the shutdown
or reboot is to forcefully kill the machine.


-- Package-specific info:
--- up and down scripts installed:
/etc/network/if-down.d:
total 16
-rwxr-xr-x 1 root root 1015 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  372 Jul  4  2016 openvpn
-rwxr-xr-x 1 root root  256 Jul 20  2013 resolvconf
-rwxr-xr-x 1 root root  332 Jan  6  2013 upstart
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
lrwxrwxrwx 1 root root   23 Jan 23 09:41 avahi-daemon -> ../if-up.d/avahi-daemon
lrwxrwxrwx 1 root root   29 Feb 11 00:16 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 1409 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 12
lrwxrwxrwx 1 root root   29 Feb 11 00:16 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root  344 Jan 28  2014 ethtool
-rwxr-xr-x 1 root root 4178 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 84
-rwxr-xr-x 1 root root  817 Jul 20  2013 000resolvconf
-rwxr-xr-x 1 root root 4359 May 29  2016 00check-network-cable
-rwxr-xr-x 1 root root 4341 Oct  1  2014 00check-network-cable.dpkg-old
-rwxr-xr-x 1 root root 5530 Feb  6  2016 10check-duplicate-ip
-rwxr-xr-x 1 root root 3848 Feb  6  2016 10check-duplicate-ip6
-rwxr-xr-x 1 root root 4280 Apr 10  2014 20static-routes
-rwxr-xr-x 1 root root 4566 Apr 10  2014 30check-gateway
-rwxr-xr-x 1 root root  923 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  484 Mar  6  2013 avahi-daemon
-rwxr-xr-x 1 root root 1685 Sep 22  2014 ethtool
-rwxr-xr-x 1 root root 4958 Jun  8  2014 mountnfs
-rwxr-xr-x 1 root root  900 Apr 28  2016 ntpdate
-rwxr-xr-x 1 root root  980 Jul 29  2016 openssh-server
-rwxr-xr-x 1 root root  385 Jul  4  2016 openvpn
-rwxr-xr-x 1 root root 1483 Jan  6  2013 upstart
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


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

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

Versions of packages ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.47
ii  iproute2 4.9.0-1
ii  libc62.24-9
ii  lsb-base 9.20161125

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5-3

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+4
pn  rdnssd  

-- no debconf information

Bug#853750: hdfview: HDF5 files appear empty

[Giuseppe Bilotta]

Package: hdfview
Version: 2.11.0+dfsg-2+b1
Severity: important

The current version of hdfview does not show the content of any of my
HDF5 files.

Downgrading to the 2.9-3+b2 version of libjhdf{4,5}-{java, jni}, which
also installs libhdf5-8 version 1.8.13+docs-15, seems to fix the issue
for me, even if hdfview is kept at the 2.11 version. This seems to
suggest that the problem lies in libjhdf rather than in hdfview itself,
and/or in the API of libhdf5 used by jhdf.

FWIW, a similar bug seems to affect also jhdf 2.9-5 as found in Ubuntu,
which is using libhdf5-10 (1.8.16), which would further support the idea
of a breaking API change between version 1.8.13 and 1.8.16 of libhdf5.


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

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

Versions of packages hdfview depends on:
ii  default-jre 2:1.8-58
ii  java-wrappers   0.1.28
ii  libjgraph-java  5.12.4.2+dfsg-5
ii  libjhdf4-java   2.11.0+dfsg-2+b1
ii  libjhdf5-java   2.11.0+dfsg-2+b1
ii  libslf4j-java   1.7.22-1

hdfview recommends no packages.

Versions of packages hdfview suggests:
ii  chromium [www-browser]  55.0.2883.75-6
ii  dillo [www-browser] 3.0.5-3
ii  elinks [www-browser]0.12~pre6-12
ii  firefox [www-browser]   51.0-1
ii  iceape [www-browser]2.7.12-1+b1
ii  konqueror [www-browser] 4:16.08.3-1
ii  links2 [www-browser]2.14-2
ii  lynx [www-browser]  2.8.9dev11-1
ii  netsurf-fb [www-browser]3.6-3
ii  opera [www-browser] 12.16.1860
ii  surf [www-browser]  0.7-2
ii  vivaldi-snapshot [www-browser]  1.7.735.11-1
ii  w3m [www-browser]   0.5.3-34

-- no debconf information

Bug#848257: hdfview: No java runtime was found

[Giuseppe Bilotta]

Package: libjhdf5-jni
Version: 2.11.0+dfsg-2+b1
Followup-For: Bug #848257

I am also affected by this issue, opening an HDF5 file in hdfview results 
works, but
none of the data is visible (as if the file was empty). I've done some testing 
by rolling
back the versions of various packages, and it seems that the culprit is either 
libjhdf5-jni
or libjhdf5-java, since installing the 2.9 version from stable of these 
packages makes
hdfview work again.


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

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

Versions of packages libjhdf5-jni depends on:
ii  libc62.24-8
ii  libhdf5-100  1.10.0-patch1+docs-3
ii  libsz2   0.3.2-1
ii  zlib1g   1:1.2.8.dfsg-4

libjhdf5-jni recommends no packages.

libjhdf5-jni suggests no packages.

-- no debconf information

Bug#837933: networking.service should depend on wpa_supplicant.service when interfaces using WPA are active

[Giuseppe Bilotta]

Package: ifupdown
Version: 0.8.13
Severity: normal


This is related to Bug#761909 (NFS not brought down during shutdown or
reboot due to the network dying too soon), which I'm still seeing on my
machine with ifupdown 0.8.13 and systemd 231-6, at least with wireless
connections (I haven't checked wired connections recently).

I looked at the dependencies of my NFS share mount; systemctl
list-dependencies oneforall.mount gives:

oneforall.mount
● ├─-.mount
● ├─system.slice
● └─network-online.target
●   └─networking.service

so in theory it should be working correctly. _However_, there is
nothing in there preventing dbus from being killed before the network
is brought down, and if dbus gets stopped too early then
wpa_supplicant will die too, and my wireless connection will die due to
wpa_supplicant dying, which forcefully brings down the whole network
even with systemd thinking it's still active.

The solution in this case is to add a dependency of networking.service
on wpa_supplicant.service (which in turns depends on dbus and therefore
prevents dbus from being brought down too early). Ideally this
dependency should only be added when a network connection that needs WPA
is brought up (and removed when no network connections depending on WPA
are up).

I have verified that this works at least on my system: testing by
forcing a runtime dependency of this sort manually seems to fix the NFS
share unmounting, as well as other network-related shutdown/reboot
issues I come across from time to time.


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

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

Versions of packages ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.44
ii  iproute2 4.6.0-4
ii  libc62.24-2
ii  lsb-base 9.20160629

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5~b1-1

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+3
pn  rdnssd  

-- no debconf information

Bug#833068: please package the zathura-pdf-mupdf backend

[Giuseppe Bilotta]

Package: zathura
Version: 0.3.6-2
Severity: wishlist

The Zathura project also provides a mupdf plugin:
https://pwmt.org/projects/zathura-pdf-mupdf/
which can be used as an alternative to the poppler-based plugin to view
PDF files.


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

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

Versions of packages zathura depends on:
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libgirara-gtk3-2 0.2.6-1+b1
ii  libglib2.0-0 2.48.1-2
ii  libgtk-3-0   3.20.6-2
ii  libmagic11:5.28-4
ii  libsqlite3-0 3.13.0-1
ii  libsynctex1  2016.20160513.41080-4
ii  zathura-pdf-poppler  0.2.6-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  chromium [www-browser]52.0.2743.82-2
ii  dillo [www-browser]   3.0.5-2+b1
ii  elinks [www-browser]  0.12~pre6-11+b2
ii  firefox-esr [www-browser] 45.2.0esr-1
ii  iceape [www-browser]  2.7.12-1+b1
ii  konqueror [www-browser]   4:16.04.2-1+b1
ii  links2 [www-browser]  2.13-1
ii  lynx [www-browser]2.8.9dev9-1
ii  opera [www-browser]   12.16.1860
ii  surf [www-browser]0.7-2
ii  vivaldi-stable [www-browser]  1.2.490.43-1
ii  w3m [www-browser] 0.5.3-29
ii  zathura-cb0.1.5-1
ii  zathura-djvu  0.2.5-1
ii  zathura-ps0.2.3-1

-- no debconf information

Bug#823226: segfaults and bogus data read from SEVIRI .grb files (regression)

[Giuseppe Bilotta]

Hello Alastair,

I've managed to pinpoint the issue: in 1.6.0, the original Makefile
defines a -D__64BIT__ which changes the meaning of g2int and g2uint
from long to int. However, this is wrong on 64-bit Linux where int is
still 32-bit, not 64-bit. The quick and dirty solution to this is to
remove the -D__64BIT__ define from the makefile. The long-term
solution would be to ask the libgrib2c developers to replace the
conditional definition based on the __64BIT__ macro with an #include
 and then typedef int64_t gint; typedef uint64_t g2uint,
which is guaranteed to use the correct dimensions regardless of
architecture (as long as the host compiler has a stdint.h, which it
should have since they force gcc now).

Best regards,

Giuseppe Bilotta

On Mon, May 2, 2016 at 4:04 PM, Alastair McKinstry
<alastair.mckins...@sceal.ie> wrote:
> Hi,
>
> Can you point me to somewhere I can get such files (I will work with
> EUMETSAT to do so, if necessary),
>
> and some hints as to what processing you did?
>
>
> thanks
>
> Alastair
>
>
> On 02/05/2016 14:36, Giuseppe Bilotta wrote:
>
> Package: libgrib2c-dev
> Version: 1.6.0-2+b1
> Severity: important
>
> Version 1.6.0-2 (and then 1.6.0-2+b1) fail to process correctly all .grb
> files in our possession (obtained by EUMETSAT). Package version 1.4.0-2
> (currently in stable) works correctly on those same files..
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libgrib2c-dev depends on:
> ii  libgrib2c0d  1.6.0-2+b1
>
> Versions of packages libgrib2c-dev recommends:
> ii  pkg-config  0.29-4
>
> libgrib2c-dev suggests no packages.
>
> -- no debconf information
>
>
> --
> Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
> https://diaspora.sceal.ie/u/amckinstry
> Misentropy: doubting that the Universe is becoming more disordered.



-- 
Giuseppe "Oblomov" Bilotta

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

> You are right.
> Meanwhile I added an entry in my TODO list concerning this package.
> I also noticed that there is two flag-file on my box: I would say that one is 
> enough,
> but I cannot say more right now because I am not familiar with this part of 
> the code.
> (In the past, I mainly add new key types support)

I downloaded the pam-ssh module and gave it a quick look: it would
seem that there is one general flag-file per user, _plus_ one
flag-file per login (so if you log in in two ttys you'd have three
flag files).

Also I see that the flag files to store the information about the
agent PID and socket location, so it should be relatively easy for
pam-ssh to check if the agent in question is actually running.

Thanks again for your time,

-- 
Giuseppe "Oblomov" Bilotta

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

On Fri, Jun 24, 2016 at 4:43 PM, Jerome BENOIT <calcu...@rezozer.net> wrote:
> On 24/06/16 15:21, Giuseppe Bilotta wrote:
>> So the problem is that one of the leftover files prevented the agent
>> from starting.
>
> This is not a problem, this mechanism is meant to allow several sessions
> to use the same agent.

Indeed, and that makes perfect sense. However it does cause issues if
the agent is not actually running, either because it crashed or
because the control file was left over from a previous run.

> What is not normal is that the flag file was not removed: I suspect an 
> accident
> and/or any confusions as it happens at migration time.

In my case, this is probably due to an unclean shutdown. I have two
issues on my machine: one is due to the system never closing down
properly if an NFS mount is active when using systemd as init. The
other is that sometimes my video driver acts up in multi-monitor
setups, especially when switching consoles and running rootless X. I
think that what happened in this case is that my machine went
completely dead after a switch from a rootless X on tty1 to
(framebuffer) console on tty2 and then back, so I was forced to do a
hard reset of the machine without logging off properly. Due to me not
logging off, the control files were still there and were never cleaned
up.

>> May I suggest adding a few more debug outputs centered around starting
>> up the agent? I don't know how it's done in pam_ssh, but if it does
>> some checks before then actually printing on debug "checking for
>> running agents" and maybe "found agent from X file, not starting"?
>
> I am agree that the DEBUG message policy must be revisited.

Indeed, It should be fine to be quite verbose with what's happening,
since it's debug-only output.

>> This would at least hint at the reason why the agent is not being started.
>>
>> (Bonus points: making sure that the agent is actually running and not
>> just some lefover file?)
>
> The leftover file is a flag file (see above).
> How do you suggest to decide whether or not an agent was indeed launched by 
> pam_ssh but not any other process ?

If the flag file contains the PID of the agent it launches, it could
be used to check if the agent is actually running before deciding to
not launch one.

>> (Anyway, the issue is solved for me; maybe demote it to wishlist for
>> the improved checks?)
>
> I guess that we can close it.

Sure.

> Note that you may want to launch the pam_tmpdir module before pam_ssh as 
> pam_ssh honours TMPDIR.

I have not altered the order of the modules myself, so probably the
pam-auth-update configuration file for pam_ssh should specify that it
needs to go after pam_tmpdir?

-- 
Giuseppe "Oblomov" Bilotta

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

OK, I think I found a solution!

When I checked the permissions of my .ssh folder and all the files
within, I noticed there were a lot of leftover agent-* files in it. I
killed my manually-started ssh-agent session, removed all the leftover
files, logged out, and now the agent starts correctly when I log in.

So the problem is that one of the leftover files prevented the agent
from starting.

May I suggest adding a few more debug outputs centered around starting
up the agent? I don't know how it's done in pam_ssh, but if it does
some checks before then actually printing on debug "checking for
running agents" and maybe "found agent from X file, not starting"?

This would at least hint at the reason why the agent is not being started.

(Bonus points: making sure that the agent is actually running and not
just some lefover file?)

(Anyway, the issue is solved for me; maybe demote it to wishlist for
the improved checks?)

Thanks a lot for your time,

-- 
Giuseppe "Oblomov" Bilotta

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

>> I'm using ssh 1:7.2p2-5
>
> Now I am also using ssh 1:7.2p2-5 , but I cannot still reproduce the issue.

8-/

> I suspect a bad interference with some pam_module present on your box but 
> absent on mine
> and/or a privilege issue.

I will try disabling some of the less used modules and see if I can at
least find which one it's interacting with.

> Can you confirm that pam_ssh emits not `start ssh-agent' message in 
> /var/log/auth.log ?
> What are the permission of your $HOME/.ssh folder ? (ls -ld $HOME/.ssh folder 
> )

The only lines in auth.log that contain the word 'agent' are in the form:

/tmp/ssh-/agent.: No such file or
directory, the last of which was from yesterday morning, before the
reboot that first exhibited the issue (lack of agent startup). There
are plenty more before that (mostly due to the system not shutting
down cleanly with active NFS mounts and systemd), so they don't seem
to be related. Maybe there's some leftover that makes pam_ssh think
the agent is running already? Where could I look for?

The permission for ~/.ssh are rwx--, and rw--- are the
permissions for all private keys, the known_hosts, the authorized_keys
and config files.

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello,
>
> My understanding is that you have only one key, the traditional rsa key.

This is indeed the case.

> I have tried to reproduce your issue with a fake user on my box: it works 
> here.
> Have you tried to start an ssh-agent by hand ?

Starting ssh-agent by hand with

eval $(ssh-agent)

after login works perfectly fine, and I can add my key with ssh-add,
and it works. ssh

> What is the version of your ssh ? (I am asking because my box is merely a 
> Jessie
> with some Stretch stuff.)


I'm using ssh 1:7.2p2-5

> Can you show your /etc/pam.d/common-session and /etc/pam.d/common-auth and 
> /etc/pam.d/login
> configuration files ?

> common-session:

#
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so
session optional pam_winbind.so
session optional pam_ssh.so debug
session optional pam_tmpdir.so
session optional pam_systemd.so
session optional pam_ecryptfs.so unwrap
session optional pam_ck_connector.so nox11
# end of pam-auth-update config

===> common-auth:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=1 default=ignore] pam_winbind.so krb5_auth
krb5_ccache_type=FILE cached_login try_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_ssh.so use_first_pass debug
auth optional pam_ecryptfs.so unwrap
auth optional pam_cap.so
# end of pam-auth-update config

=> login:


#
# The PAM configuration file for the Shadow `login' service
#

# Enforce a minimal delay in case of failure (in microseconds).
# (Replaces the `FAIL_DELAY' setting from login.defs)
# Note that other modules may require another minimal delay. (for example,
# to disable any delay, you should add the nodelay option to pam_unix)
auth   optional   pam_faildelay.so  delay=300

# Outputs an issue file prior to each login prompt (Replaces the
# ISSUE_FILE option from login.defs). Uncomment for use
# auth   required   pam_issue.so issue=/etc/issue

# Disallows root logins except on tty's listed in /etc/securetty
# (Replaces the `CONSOLE' setting from login.defs)
#
# With the default control of this module:
#   [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die]
# root will not be prompted for a password on insecure lines.
# if an invalid username is entered, a password is prompted (but login
# will eventually be rejected)
#
# You can change it to a "requisite" module if you think root may mis-type
# her login and should not be prompted for a password in that case. But
# this will leave the system as vulnerable to user enumeration attacks.
#
# You can change it to a "required" module if you think it permits to
# guess valid user names of your system (invalid user names are considered
# as possibly being root on insecure 

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello again,>> Is there anything I can do to debug the issue and
provide more information?
>
> Can you check that your current set is conform to pam_ssh(8) ?

I have not altered the pam configuration myself until now, so the
configuration is the one enabled by the package directly. greppng for
ssh gives:

/etc/pam.d/common-auth:auth optional pam_ssh.so use_first_pass debug
/etc/pam.d/common-session:session optional pam_ssh.so debug

(the debug lines are what I added as per your suggestion).

I also don't have any ~/.ssh/login-keys.d/ or ~/.ssh/session-keys.d/,

> If yes, please try the debug option (see pam_ssh(8)) to figure out what is 
> going wrong;
> the log files are welcome.

Here's a snippet from /var/log/auth.log, which seems to be the only
log with relevant information

Jun 23 15:58:34 user pam_ssh[1418]: open session
Jun 23 15:58:42 user pam_ssh[1869]: init authentication module
Jun 23 15:58:42 user pam_ssh[1869]: No SSH login-keys directory.
Jun 23 15:58:42 user pam_ssh[1869]: Grabbing password from preceding
auth module.
Jun 23 15:58:42 user pam_ssh[1869]: Using previous password for SSH keys.
Jun 23 15:58:42 user pam_ssh[1869]: Looking for SSH keys in
'/home/user/.ssh/session-keys.d'.
Jun 23 15:58:42 user pam_ssh[1869]: No SSH session-keys directory.
Jun 23 15:58:42 user pam_ssh[1869]: Looking for SSH keys in '/home/user/.ssh'.
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_ed25519'.
Jun 23 15:58:42 user pam_ssh[1869]: debug1: key_load_private: No such
file or directory
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_ed25519' failed.
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_ecdsa'.
Jun 23 15:58:42 user pam_ssh[1869]: debug1: key_load_private: No such
file or directory
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_ecdsa' failed.
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_dsa'.
Jun 23 15:58:42 user pam_ssh[1869]: debug1: key_load_private: No such
file or directory
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_dsa' failed.
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'id_rsa'.
Jun 23 15:58:42 user pam_ssh[1869]: SSH key 'id_rsa' decrypted.
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'identity'.
Jun 23 15:58:42 user pam_ssh[1869]: debug1: key_load_private: No such
file or directory
Jun 23 15:58:42 user pam_ssh[1869]: SSH key candidate 'identity' failed.
Jun 23 16:00:47 user pam_ssh[1418]: close session
Jun 23 16:00:56 user pam_ssh[2231]: init authentication module
Jun 23 16:00:56 user pam_ssh[2231]: No SSH login-keys directory.
Jun 23 16:00:56 user pam_ssh[2231]: Grabbing password from preceding
auth module.
Jun 23 16:00:56 user pam_ssh[2231]: Using previous password for SSH keys.
Jun 23 16:00:56 user pam_ssh[2231]: Looking for SSH keys in
'/home/user/.ssh/session-keys.d'.
Jun 23 16:00:56 user pam_ssh[2231]: No SSH session-keys directory.
Jun 23 16:00:56 user pam_ssh[2231]: Looking for SSH keys in '/home/user/.ssh'.
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_ed25519'.
Jun 23 16:00:56 user pam_ssh[2231]: debug1: key_load_private: No such
file or directory
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_ed25519' failed.
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_ecdsa'.
Jun 23 16:00:56 user pam_ssh[2231]: debug1: key_load_private: No such
file or directory
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_ecdsa' failed.
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_dsa'.
Jun 23 16:00:56 user pam_ssh[2231]: debug1: key_load_private: No such
file or directory
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_dsa' failed.
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'id_rsa'.
Jun 23 16:00:56 user pam_ssh[2231]: SSH key 'id_rsa' decrypted.
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'identity'.
Jun 23 16:00:56 user pam_ssh[2231]: debug1: key_load_private: No such
file or directory
Jun 23 16:00:56 user pam_ssh[2231]: SSH key candidate 'identity' failed.
Jun 23 16:00:56 user pam_ssh[2231]: open session
Jun 23 16:01:06 user pam_ssh[2285]: init authentication module
Jun 23 16:01:06 user pam_ssh[2285]: No SSH login-keys directory.
Jun 23 16:01:06 user pam_ssh[2285]: Grabbing password from preceding
auth module.
Jun 23 16:01:06 user pam_ssh[2285]: Using previous password for SSH keys.
Jun 23 16:01:06 user pam_ssh[2285]: Looking for SSH keys in
'/home/user/.ssh/session-keys.d'.
Jun 23 16:01:06 user pam_ssh[2285]: No SSH session-keys directory.
Jun 23 16:01:06 user pam_ssh[2285]: Looking for SSH keys in '/home/user/.ssh'.
Jun 23 16:01:06 user pam_ssh[2285]: SSH key candidate 'id_ed25519'.
Jun 23 16:01:06 user pam_ssh[2285]: debug1: key_load_private: No such
file or directory
Jun 23 16:01:06 user pam_ssh[2285]: SSH key candidate 'id_ed25519' failed.
Jun 23 16:01:06 user pam_ssh[2285]: SSH key candidate 'id_ecdsa'.
Jun 23 16:01:06 user pam_ssh[2285]: debug1: key_load_private: No such
file or directory
Jun 23 16:01:06 user 

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Hello Jerome,

thanks for your time

>> Not much to say: as per the title, I just found out that the latest
>> version of libpam-ssh does not launch an ssh-agent,
>
> It does on my box.

Is there anything I can do to debug the issue and provide more information?

>> even though the
>> password does unlock at least one of the user keys. This is both for
>> local and remote logins.
>
> What do you mean by local and remote ?

By local I mean when logging in while sitting in front the machine and
typing on the keyboard at the login prompt that comes up on the tty (I
boot into text mode and then start X manually). Remote I mean when
ssh'ing into the machine.

-- 
Giuseppe "Oblomov" Bilotta

Bug#827949: libpam-ssh does not launch an ssh-agent

[Giuseppe Bilotta]

Package: libpam-ssh
Version: 2.1+ds1-1
Severity: important

Not much to say: as per the title, I just found out that the latest
version of libpam-ssh does not launch an ssh-agent, even though the
password does unlock at least one of the user keys. This is both for
local and remote logins.

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

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

Versions of packages libpam-ssh depends on:
ii  libc6   2.22-12
ii  libpam-runtime  1.1.8-3.3
ii  libpam0g1.1.8-3.3
ii  libssl1.0.2 1.0.2h-1

Versions of packages libpam-ssh recommends:
ii  libpam-tmpdir0.09
ii  openssh-client [ssh-client]  1:7.2p2-5

libpam-ssh suggests no packages.

-- no debconf information

Bug#823226: segfaults and bogus data read from SEVIRI .grb files (regression)

[Giuseppe Bilotta]

Hello Alastair,


On Mon, May 2, 2016 at 4:04 PM, Alastair McKinstry
 wrote:
> Hi,
>
> Can you point me to somewhere I can get such files (I will work with
> EUMETSAT to do so, if necessary),
>
> and some hints as to what processing you did?

Thanks for your interest in the matter. You can find a sample data
file as well as a subset of the C code that we use to read it at
http://labrador.oblomov.eu/grib/ —the grib file itself is compressed
to reduce load on my home server. Simply gunzip the grib and make &&
./test *grb will exhibit the issue. The segfaulting instruction is a
printf in my grib2load.h which simply tries to access some fields that
should have been initialized correctly. If you trap with gdb before
it, and inspect the fields data, you'll see that it's pretty much
bogus. Compared with what you get with the older version of the
library to find the sane (and correct) values. Let me know if you need
anything else to reproduce.

Best regards,

-- 
Giuseppe "Oblomov" Bilotta

Bug#823226: segfaults and bogus data read from SEVIRI .grb files (regression)

[Giuseppe Bilotta]

Package: libgrib2c-dev
Version: 1.6.0-2+b1
Severity: important

Version 1.6.0-2 (and then 1.6.0-2+b1) fail to process correctly all .grb
files in our possession (obtained by EUMETSAT). Package version 1.4.0-2
(currently in stable) works correctly on those same files..


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

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

Versions of packages libgrib2c-dev depends on:
ii  libgrib2c0d  1.6.0-2+b1

Versions of packages libgrib2c-dev recommends:
ii  pkg-config  0.29-4

libgrib2c-dev suggests no packages.

-- no debconf information

Bug#822311: visual glitch in opengl games on intel haswell igp

[Giuseppe Bilotta]

Package: libgl1-mesa-glx
Version: 11.1.3-1
Severity: normal

The glitch manifests consistently (although not in glxgears) in the form
of uniformly colored triangles covering the rendered scenes; triangles
seem to have common vertices aroung the middle of each side of the
screen, typically. The glitch is somewhat hard to describe in words, but
a screenshot taken from Neverputt is available here:

http://labrador.oblomov.eu/images/mesa-intel-glitch-neverputt.png

Similar glitches are visible in both open source games (such as
neverputt or neverball) and closed source ones (such as Race the Sun or
Portal), making all of them unplayable.

-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Haswell Mobile  (0x416)
Version: 11.1.3
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
GL_3DFX_texture_compression_FXT1, GL_AMD_conservative_depth, 
GL_AMD_draw_buffers_blend, GL_AMD_performance_monitor, 
GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_trinary_minmax, 
GL_AMD_vertex_shader_layer, GL_AMD_vertex_shader_viewport_index, 
GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, 
GL_APPLE_object_purgeable, GL_ARB_ES2_compatibility, 
GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, 
GL_ARB_blend_func_extended, GL_ARB_buffer_storage, 
GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, 
GL_ARB_compressed_texture_pixel_storage, 
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_debug_output, 
GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_derivative_control, 
GL_ARB_direct_state_access, GL_ARB_draw_buffers, 
GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, 

Bug#815602: xserver-xorg-core: cannot start second session on different display if one is already running

[Giuseppe Bilotta]

Package: xserver-xorg-core
Version: 2:1.18.1-1
Severity: normal

I normally boot in console (text mode w/ KMS) and start X manually.
Today I discovered that I cannot start a second X session while the
first one is running.

Steps to reproduce:

1. boot to console (not X);
2. login;
3. start X (e.g. with `xinit`);
4. switch to a different VT (ctrl+alt+f2);
5. login as the same user;
6. start X again on a different disply (e.g. with: `xinit -- :1`);

the second session fails to start. The error is something like:

[ 15201.424] (EE) 
Fatal server error:
[ 15201.424] (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or 
directory)
[ 15201.424] (EE) 
[ 15201.424] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[ 15201.424] (EE) Please also check the log file at 
"/home/oblomov/.local/share/xorg/Xorg.1.log" for additional information.
[ 15201.424] (EE) 


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug  9  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb  9 12:12 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion 

Bug#815329: mah-jong: new upstream version available

[Giuseppe Bilotta]

Package: mah-jong
Version: 1.11-2
Severity: normal

Version 1.14 is available from te author's website.


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

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

Versions of packages mah-jong depends on:
ii  libc6 2.21-9
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1

mah-jong recommends no packages.

mah-jong suggests no packages.

-- no debconf information

Bug#813625: xserver-xorg-video-intel: rendering corruption when not on battery power

[Giuseppe Bilotta]

Hello Julien,

On Thu, Feb 4, 2016 at 5:17 PM, Julien Cristau <jcris...@debian.org> wrote:
> On Wed, Feb  3, 2016 at 20:48:56 +0100, Giuseppe Bilotta wrote:

[snip]
>> Most interesting, the glitch only manifests when running on AC. If the
>> laptop is on battery, there are no issues.
>>
> Please report this upstream following
> https://01.org/linuxgraphics/documentation/how-report-bugs and let us
> know the bug number for tracking.

Reported upstream as https://bugs.freedesktop.org/show_bug.cgi?id=94011

I notice that the new (buggy for me) version is in testing too now 8-/

-- 
Giuseppe "Oblomov" Bilotta

Bug#813625: xserver-xorg-video-intel: rendering corruption when not on battery power

[Giuseppe Bilotta]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20160127-1+b1
Severity: normal

Since the upgrade to xserver-xorg 2:1.18.0-3 and
xserver-xorg-video-intel 2:2.99.917+git20160127-1+b1 I'm experiencing
the wierdest rendering corruption, which mostly manifests through a
horizontal banding of the display. Snapshots of the correct and glitched
display can be found at these imgur links:

http://i.imgur.com/V9V8s8h.png
http://i.imgur.com/NhNq9OF.png

The issue does't normally manifest in my setup and with the applications
I use, with the only exception of Opera 12, which manifests it quite
consistently. Previous versions of the graphics stack (particularly
xserver-xorg-video-intel 2:2.99.917-2 from testing, on pre-1.18
Xorg) work fine.

Most interesting, the glitch only manifests when running on AC. If the
laptop is on battery, there are no issues.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug  9  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Jan 27 15:55 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 

Bug#813252: pkg-config --libs libgit2 should include -lhttp_parser too

[Giuseppe Bilotta]

Package: libgit2-dev
Version: 0.23.1-1+b1
Severity: important

libgit2 depends on libhttp-parser, and libgit2-dev depends on
libhttp-parser-dev. However, the pkg-config information for libgit2 does
not include -lhttp_parser among the needed libraries, hence trying to
compile a program that depends on libgit2 using $(pkg-config --libs
libgit2) to get the compile flags will fail due to undefined references
to http_parser_init and http_parser_execute methods.

This should be trivial to fix, by moving -lhttp_parser from the
Libs.private to the Libs field in the .pc file.


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

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

Versions of packages libgit2-dev depends on:
ii  libcurl4-openssl-dev   7.47.0-1
ii  libgit2-23 0.23.1-1+b1
ii  libhttp-parser-dev 2.1-2
ii  libssh2-1-dev  1.5.0-2+b1
ii  libssl-dev 1.0.2f-2
ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-2+b1

libgit2-dev recommends no packages.

libgit2-dev suggests no packages.

-- no debconf information

Bug#785697: clang-3.6: Clang++ does not find standard include files, e.g.

[Giuseppe Bilotta]

Package: clang-3.6
Version: 1:3.6.2-1
Followup-For: Bug #785697

I've found this happens when using the --gcc-toolchain command-line
option to choose the toolchain to use. The include path in this case is
seriously defective. Compare:


== 8< === without --gcc-toolchain =

$ echo | clang++ -x c++ -c -v -o /dev/null -
Debian clang version 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/5.2.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/5.2.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.2.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
 "/usr/lib/llvm-3.6/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj 
-mrelax-all -disable-free -disable-llvm-verifier -main-file-name - 
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno 
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array 
-target-cpu x86-64 -target-linker-version 2.25 -v -dwarf-column-info 
-coverage-file /dev/null -resource-dir /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/x86_64-linux-gnu/c++/5.2.1
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/x86_64-linux-gnu/c++/5.2.1
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/backward
 -internal-isystem /usr/local/include -internal-isystem 
/usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include -internal-externc-isystem 
/usr/include/x86_64-linu
 x-gnu -internal-externc-isystem /include -internal-externc-isystem 
/usr/include -fdeprecated-macro -fdebug-compilation-dir /home/oblomov 
-ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc 
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /dev/null -x c++ -
clang -cc1 version 3.6.2 based upon LLVM 3.6.2 default target 
x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
ignoring duplicate directory 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/x86_64-linux-gnu/c++/5.2.1"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1
 
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/x86_64-linux-gnu/c++/5.2.1
 
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/backward
 /usr/local/include
 /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

== 8< ==


versus:

== 8< === with --gcc-toolchain =

$ echo | clang++ -x c++ 
--gcc-toolchain=/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1 -c -v -o /dev/null -

Debian clang version 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/lib/llvm-3.6/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj 
-mrelax-all -disable-free -disable-llvm-verifier -main-file-name - 
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno 
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 
-target-linker-version 2.25 -v -dwarf-column-info -coverage-file /dev/null 
-resource-dir /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 -internal-isystem 
/usr/local/include -internal-isystem 
/usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include -internal-externc-isystem 
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include 
-internal-externc-isystem /usr/include -fdeprecated-macro 
-fdebug-compilation-dir /home/oblomov -ferror-limit 19 -fmessage-length 0 
-mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions 
-fdiagnostics-show-option -o /dev/null -x c++ -
clang -cc1 version 3.6.2 based upon LLVM 3.6.2 default target 
x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
 /usr/include/x86_64-linux-gnu
 

Bug#801401: cannot start X from the console command line

[Giuseppe Bilotta]

On Mon, Oct 12, 2015 at 10:29 AM, Giuseppe Bilotta
<giuseppe.bilo...@gmail.com> wrote:
> On Sun, Oct 11, 2015 at 4:39 PM, Julien Cristau <jcris...@debian.org> wrote:
>> How exactly are you starting X?  'startx' is supposed to do the right
>> thing.
>
> I typically start with either startx or a script that does "xinit
> ~/some-local-xinitrc", and neither works. However, I was affected by
> the 227-1 systemd service timeout bug, so that might be part of the
> problem. I'll try again with systemd 227-2

Ok, it seems that with the latest systemd and the latest xorg now
startx works, but xinit doesn't. I've upgraded my script to use startx
instead of xinit.

Is there a reason why it wouldn't work with xinit?

-- 
Giuseppe "Oblomov" Bilotta

Bug#801401: cannot start X from the console command line

[Giuseppe Bilotta]

On Sun, Oct 11, 2015 at 4:39 PM, Julien Cristau  wrote:
> How exactly are you starting X?  'startx' is supposed to do the right
> thing.

I typically start with either startx or a script that does "xinit
~/some-local-xinitrc", and neither works. However, I was affected by
the 227-1 systemd service timeout bug, so that might be part of the
problem. I'll try again with systemd 227-2

-- 
Giuseppe "Oblomov" Bilotta

Bug#801401: cannot start X from the console command line

[Giuseppe Bilotta]

Package: xserver-xorg
Version: 1:7.7+12
Severity: important

I normally boot to console and then manually launch X if/when I need it.
With the latest update to Xorg, trying to start X fails with the error

 (EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

Interestingly, the error is about /dev/tty0 regardless of whether I try
to start it from the first VT or from a different one (see attached
logs).

I've also installed xserver-xorg-legacy, but the problem persists.

=== 8< === log when starting from the first VT 

[  1577.167] 
X.Org X Server 1.17.2
Release Date: 2015-06-16
[  1577.186] X Protocol Version 11, Revision 0
[  1577.192] Build Operating System: Linux 4.2.0-1-amd64 x86_64 Debian
[  1577.198] Current Operating System: Linux oblomov 4.2.0-1-amd64 #1 SMP 
Debian 4.2.3-1 (2015-10-06) x86_64
[  1577.198] Kernel command line: BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 
root=UUID=0f69635c-b68c-476c-ba1c-6bdc4c44f397 ro init=/sbin/sysvinit
[  1577.209] Build Date: 06 October 2015  07:27:47AM
[  1577.214] xorg-server 2:1.17.2-3 (http://www.debian.org/support) 
[  1577.219] Current version of pixman: 0.33.2
[  1577.228]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1577.228] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1577.245] (==) Log file: "/home/oblomov/.local/share/xorg/Xorg.0.log", Time: 
Fri Oct  9 18:20:15 2015
[  1577.249] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1577.253] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1577.253] (==) No Layout section.  Using the first Screen section.
[  1577.253] (==) No screen section available. Using defaults.
[  1577.253] (**) |-->Screen "Default Screen Section" (0)
[  1577.253] (**) |   |-->Monitor ""
[  1577.254] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1577.254] (==) Automatically adding devices
[  1577.254] (==) Automatically enabling devices
[  1577.254] (==) Automatically adding GPU devices
[  1577.254] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1577.254]Entry deleted from font path.
[  1577.254] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1577.254] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1577.254] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1577.254] (II) Loader magic: 0x55dea5f46de0
[  1577.254] (II) Module ABI versions:
[  1577.254]X.Org ANSI C Emulation: 0.4
[  1577.254]X.Org Video Driver: 19.0
[  1577.254]X.Org XInput driver : 21.0
[  1577.254]X.Org Server Extension : 9.0
[  1577.256] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_31
[  1577.257] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1577.257] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 8 paused 0
[  1577.258] (--) PCI:*(0:0:2:0) 8086:0416:1028:05fe rev 6, Mem @ 
0xf740/4194304, 0xd000/268435456, I/O @ 0xf000/64
[  1577.259] (--) PCI: (0:2:0:0) 10de:0fe4:1028:05fe rev 161, Mem @ 
0xf600/16777216, 0xe000/268435456, 0xf000/33554432, I/O @ 
0xe000/128, BIOS @ 0x/524288
[  1577.259] (II) LoadModule: "glx"
[  1577.259] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  1577.260] (II) Module glx: vendor="X.Org Foundation"
[  1577.260]compiled for 1.17.2, module version = 1.0.0
[  1577.260]ABI class: X.Org Server Extension, version 9.0
[  1577.260] (==) AIGLX enabled
[  1577.260] (==) Matched intel as autoconfigured driver 0
[  1577.260] (==) Matched intel as autoconfigured driver 1
[  1577.260] (==) Matched modesetting as autoconfigured driver 2
[  1577.260] (==) Matched fbdev as autoconfigured driver 3
[  1577.260] (==) Matched vesa as autoconfigured driver 4
[  1577.260] (==) Assigned the driver to the xf86ConfigLayout
[  1577.260] (II) LoadModule: "intel"
[  1577.260] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  1577.260] (II) Module intel: vendor="X.Org Foundation"
[  1577.260]compiled for 1.17.2, module version = 2.99.917
[  1577.260]Module class: X.Org Video Driver
[  1577.260]ABI class: X.Org Video Driver, version 19.0
[  1577.260] (II) LoadModule: "modesetting"
[  1577.260] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  1577.260] (II) Module modesetting: vendor="X.Org Foundation"
[  1577.260]compiled for 1.17.2, module version = 1.17.2
[  1577.260]Module class: X.Org 

Bug#801401: cannot start X from the console command line

[Giuseppe Bilotta]

Package: xserver-xorg
Version: 1:7.7+12
Followup-For: Bug #801401

Additional information: I've added my user to the `tty` group, and while
Xorg still fails to start, the error is now different:

 (EE) xf86OpenConsole: Cannot open virtual console 5 (Permission denied)

where VC5 is the next free one (so the number changes based on how many
gettys I have spawned).

This is very odd though, shouldn't usermode Xorg try to use the same VC
where it's being launched from?

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug  9  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct  6 09:35 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to 

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

[Giuseppe Bilotta]

Hello

On Mon, Oct 5, 2015 at 11:15 AM, Martin Pitt  wrote:
>> However, when the network is brought down (manually, or automatically
>> during system shutdown), the mountpoint is not unmounted, causing a
>> number of issues.
>
> This sounds very similar to https://launchpad.net/bugs/1492546 .
> ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf)
> call functions check_network_file_systems() and check_network_swap()
> and don't tear down the interface(s) in the above situation. This also
> applies to e. g. iscsi.
>
> But we don't do the same with the autogenerated ifup@.service -- that
> always unconditionally calls "ifdown" on stopping. IMHO we should make
> "systemctl stop ifup@ethX.service" a no-op at least during shutdown,
> as stopping /etc/init.d/networking will stop them all anyway (or not,
> if network file systems are being used).

Shouldn't a dependcy of network filesystems on network interfaces
automatically prevet the network interfaces services from being
stoppable while the network filesystems are up?

-- 
Giuseppe "Oblomov" Bilotta

Bug#793488: (no subject)

[giuseppe . bilotta]

I think I found the problem: recently part of the OpenCL ICD seems to

have been split into a separate library, which is not packaged in
Debian:

* for x86_64, libamdocl12cl64.so is needed in addition to libamdocl64.so
* for x86, libamdocl12cl32.so is needed in addition to libamdocl32.so

Bug#796097: texlive-base / texlive-fonts-recommended: mflogo .tfm metrics missing

[Giuseppe Bilotta]

Package: texlive-base
Version: 2015.20150810-1
Severity: normal

The bug affects the texlive-base and/or texlive-fonts-recommended
packages currently in testing and unstable, but not in stable. In the
migration between stable and testing, the mflogo fonts was moved from
texlive-base to texlive-fonts-recommended, but the TeX font metrics
(.tfm) have gone missing, effectively preventing (quality) use of the
font.

$ for dist in stable testing unstable ; do echo $dist ; apt-file -s 
/etc/apt/sources.list.d/${dist}.list search logosl8.pfb ; done
stable
texlive-base:
/usr/share/texlive/texmf-dist/fonts/type1/hoekwater/mflogo/logosl8.pfb
testing
texlive-fonts-recommended:
/usr/share/texlive/texmf-dist/fonts/type1/hoekwater/mflogo-font/logosl8.pfb
unstable
texlive-fonts-recommended:
/usr/share/texlive/texmf-dist/fonts/type1/hoekwater/mflogo-font/logosl8.pfb

$ for dist in stable testing unstable ; do echo $dist ; apt-file -s 
/etc/apt/sources.list.d/${dist}.list search logosl8.tfm ; done
stable
texlive-base:
/usr/share/texlive/texmf-dist/fonts/tfm/public/mflogo/logosl8.tfm
testing
unstable

(I'm not sure which of the two packages it should be reported against.)


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

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

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.57
ii  libpaper-utils 1.1.24+nmu4
ii  tex-common 6.02
ii  texlive-binaries   2015.20150524.37493-5
ii  ucf3.0030
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages texlive-base recommends:
ii  lmodern  2.004.4-5

Versions of packages texlive-base suggests:
ii  acroread [pdf-viewer]9.5.5-dmo2
ii  evince [postscript-viewer]   3.16.1-1
ii  ghostscript [postscript-viewer]  9.16~dfsg-2
ii  gv [postscript-viewer]   1:3.7.4-1
ii  okular [postscript-viewer]   4:4.14.2-3
pn  perl-tk  none
ii  xpdf [pdf-viewer]3.03-17+b1
ii  zathura [pdf-viewer] 0.3.3-2
ii  zathura-ps [postscript-viewer]   0.2.2-8

Versions of packages tex-common depends on:
ii  dpkg  1.18.1
ii  ucf   3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20150628

Versions of packages texlive-base is related to:
ii  tex-common6.02
ii  texlive-binaries  2015.20150524.37493-5

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:

Bug#789483: Found a patch

[Giuseppe Bilotta]

The following patch to uvm/Kbuild seems to fix the problem for me
(hoping gmail doesn't wrap it)

--- uvm/Kbuild~ 2015-06-21 15:33:08.438616334 +0200
+++ uvm/Kbuild 2015-06-21 15:33:22.662669880 +0200
@@ -219,6 +219,8 @@
RM_MODULE_SYMVERS:= $(RM_OUT_DIR)/Module.symvers
UVM_MODULE_SYMVERS:= $(obj)/Module.symvers

+KBUILD_EXTRA_SYMBOLS += $(RM_MODULE_SYMVERS)
+
module $(MODULE_NAME).ko: $(UVM_MODULE_SYMVERS) debug_diagnostics_printing

$(MODULE_NAME)-y := $(MODULE_GLUE_OBJS)



-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789483: nvidia-kermel-dkms: uvm driver builds but fails to load due to missing symbols

[Giuseppe Bilotta]

Package: nvidia-kernel-dkms
Version: 346.72-1
Severity: important

The nvidia-uvm driver (essential to run CUDA or OpenCL programs) builds
successfully, but fails to load due missing symbols

nvUvmInterfaceSessionCreate
nvUvmInterfaceChannelAllocate
nvUvmInterfaceGetGpuArch

(etc), at least on kernel 4.0.0-2 (Debian package)

This may be a rehash of issue #747366.


-- Package-specific info:
uname -a:
Linux oblomov 4.0.0-2-amd64 #1 SMP Debian 4.0.5-1 (2015-06-16) x86_64 GNU/Linux

/proc/version:
Linux version 4.0.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-21) ) #1 SMP Debian 4.0.5-1 (2015-06-16)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  346.72  Tue May  5 22:03:13 PDT 
2015
GCC version:  gcc version 4.9.2 (Debian 4.9.2-21) 

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: Dell Device [1028:05fe]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 35
Region 0: Memory at f740 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

dmesg:
[0.00] AGP: No AGP bridge found
[0.00] AGP: Checking aperture...
[0.00] AGP: No AGP bridge found
[0.475600] vgaarb: setting as boot device: PCI::00:02.0
[0.475603] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.475609] vgaarb: loaded
[0.475612] vgaarb: bridge control possible :00:02.0
[0.835527] Linux agpgart interface v0.103
[3.638764] [drm] Replacing VGA console driver
[3.661677] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[3.885426] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
[27019.265754] nvidia: module license 'NVIDIA' taints kernel.
[27019.274029] nvidia :02:00.0: enabling device (0006 - 0007)
[27019.274357] [drm] Initialized nvidia-drm 0.0.0 20150116 for :02:00.0 on 
minor 1
[27019.274361] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  346.72  Tue May  
5 22:03:13 PDT 2015
[27019.287547] nvidia_uvm: no symbol version for nvUvmInterfaceChannelDestroy
[27019.287551] nvidia_uvm: Unknown symbol nvUvmInterfaceChannelDestroy (err -22)
[27019.287553] nvidia_uvm: no symbol version for nvUvmInterfaceQueryCaps
[27019.287554] nvidia_uvm: Unknown symbol nvUvmInterfaceQueryCaps (err -22)
[27019.287559] nvidia_uvm: no symbol version for nvUvmInterfaceMemoryAllocSys
[27019.287559] nvidia_uvm: Unknown symbol nvUvmInterfaceMemoryAllocSys (err -22)
[27019.287561] nvidia_uvm: no symbol version for nvUvmInterfaceMemoryCpuMap
[27019.287561] nvidia_uvm: Unknown symbol nvUvmInterfaceMemoryCpuMap (err -22)
[27019.287563] nvidia_uvm: no symbol version for nvUvmInterfaceKillChannel
[27019.287564] nvidia_uvm: Unknown symbol nvUvmInterfaceKillChannel (err -22)
[27019.287566] nvidia_uvm: no symbol version for nvUvmInterfaceMemoryCpuUnMap
[27019.287567] nvidia_uvm: Unknown symbol nvUvmInterfaceMemoryCpuUnMap (err -22)
[27019.287569] nvidia_uvm: no symbol version for 
nvUvmInterfaceAddressSpaceCreateMirrored
[27019.287570] nvidia_uvm: Unknown symbol 
nvUvmInterfaceAddressSpaceCreateMirrored (err -22)
[27019.287592] nvidia_uvm: no symbol version for 
nvUvmInterfaceServiceDeviceInterruptsRM
[27019.287593] nvidia_uvm: Unknown symbol 
nvUvmInterfaceServiceDeviceInterruptsRM (err -22)
[27019.287594] nvidia_uvm: no symbol version for nvUvmInterfaceDeRegisterUvmOps
[27019.287595] nvidia_uvm: Unknown symbol nvUvmInterfaceDeRegisterUvmOps (err 
-22)
[27019.287596] nvidia_uvm: no symbol version for nvUvmInterfaceMemoryFree
[27019.287597] nvidia_uvm: Unknown symbol nvUvmInterfaceMemoryFree (err -22)
[27019.287598] nvidia_uvm: no symbol version for nvUvmInterfaceGetUvmPrivRegion
[27019.287599] nvidia_uvm: Unknown symbol nvUvmInterfaceGetUvmPrivRegion (err 
-22)
[27019.287602] nvidia_uvm: no symbol version for nvUvmInterfaceGetAttachedUuids
[27019.287603] nvidia_uvm: Unknown symbol nvUvmInterfaceGetAttachedUuids (err 
-22)
[27019.287606] nvidia_uvm: no symbol version for nvUvmInterfaceSessionDestroy
[27019.287607] nvidia_uvm: Unknown symbol nvUvmInterfaceSessionDestroy (err -22)
[27019.287608] nvidia_uvm: no symbol version for 
nvUvmInterfaceCheckEccErrorSlowpath
[27019.287609] nvidia_uvm: Unknown symbol nvUvmInterfaceCheckEccErrorSlowpath 
(err -22)
[27019.287611] nvidia_uvm: no symbol version for 
nvUvmInterfaceAddressSpaceCreate

Bug#785205: nvidia-kernel-dkms: fails to build with kernel 4.0 (sid)

[Giuseppe Bilotta]

Hello,

any news about this?

On Sat, May 16, 2015 at 7:22 AM, Vincent Cheng vch...@debian.org wrote:
 Hi Giuseppe,

 On Fri, May 15, 2015 at 10:08 AM, Giuseppe Bilotta
 giuseppe.bilo...@gmail.com wrote:
 Hello Vincent,

 thanks for the prompt reply!

 On Thu, May 14, 2015 at 9:49 AM, Vincent Cheng vch...@debian.org wrote:
 Please install either nvidia 340.76-2 (sid) or 346.59-1
 (experimental), and try rebuilding the nvidia module using dkms.

 It seems 346.59-1 hasn't been pushed to experimental yet? I still see 
 343.36-1

 Looks like the source package failed to build on the Debian buildds;
 I'll investigate and fix it ASAP.

 Regards,
 Vincent



-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788412: tt-rss: fails to import OPML files

[Giuseppe Bilotta]

Package: tt-rss
Version: 1.15+dfsg-1
Severity: normal
Tags: patch upstream

tt-rss version 1.15 fails to import OPML feed lists, with error

DOMDocument::load(): I/O warning : failed to load external entity 
quot;/var/cache/tt-rss/upload/opmlSR5e4iquot;

The error is upstream, see e.g. 
https://tt-rss.org/forum/viewtopic.php?f=1t=3231
which also provides a link to a patch that fixes the issue:

https://github.com/gothfox/Tiny-Tiny-RSS/commit/3457ce7c5963e507a2116866cedb1f1509230c93

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

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

Versions of packages tt-rss depends on:
ii  dbconfig-common1.8.47+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.23
ii  libapache2-mod-php55.6.7+dfsg-1
ii  libjs-dojo-core1.10.2+dfsg-1
ii  libjs-dojo-dijit   1.10.2+dfsg-1
ii  libjs-scriptaculous1.9.0-2
ii  libphp-phpmailer   5.2.9+dfsg-2
ii  php-gettext1.0.11-1
ii  php5   5.6.7+dfsg-1
ii  php5-cli   5.6.7+dfsg-1
ii  php5-json  1.3.6-1
ii  php5-mysql 5.6.7+dfsg-1
ii  phpqrcode  1.1.4-1

Versions of packages tt-rss recommends:
ii  apache2 [httpd]  2.4.12-1
ii  php5-gd  5.6.7+dfsg-1
ii  php5-mcrypt  5.6.7+dfsg-1

Versions of packages tt-rss suggests:
ii  mysql-client 5.5.42-1
ii  mysql-client-5.5 [mysql-client]  5.5.42-1
ii  mysql-server 5.5.42-1
pn  php-apc  none
pn  sphinxsearch none

-- Configuration Files:
/etc/default/tt-rss changed [not included]
/etc/tt-rss/config.php changed [not included]

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787822: systemd: network brought down before network filesystems are unmounted

[Giuseppe Bilotta]

Hello,

On Fri, Jun 5, 2015 at 6:48 PM, Michael Biebl bi...@debian.org wrote:

 Can you please describe what kind of network setup you have and which
 tools you use to configure your network.
 How do you mount your NFS shares, is this the one listed in your fstab?

Yes, the network share is the one listed in the fstab. I have two machines.

In this machine (the one I wrote the report from and with the given
fstab) I bring up the network manually using interfaces (ifup
wlan0=networkname) if I'm on wireless, or automatically (still via the
interfaces mechanism, using guessnet) for ethernet. In both cases, as
soon as the network is up, nfs-common is loaded and /oneforall gets
mounted (if the server resolves).

In the other machine (the fresh Jessie installation), NetworkManager
is in use, and /oneforall is mounted manually (it's in fstab there
too, but set to noauto).

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787305: v86d: stuck a 100% CPU after boot, must be killed manually

[Giuseppe Bilotta]

Package: v86d
Version: 0.1.10-1
Severity: normal

I _think_ this has started happening with the latest kernel upgrade,
but I don't have the immediate preceding version to check. Basically,
the system boot fines, but one of my cores is stuck at 100% CPU by v86d.

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

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

Versions of packages v86d depends on:
ii  libc6 2.19-18
ii  libx86-1  1.1+ds1-10

Versions of packages v86d recommends:
ii  initramfs-tools  0.120

v86d suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785458: xserver-xorg-video-intel: corrupted rendering of xfonts-terminus-oblique in rxvt-unicode

[Giuseppe Bilotta]

Package: xserver-xorg-video-intel
Version: 2:2.99.917-1
Severity: normal

I've recently upgraded to the latest Xorg and Xorg intel driver in sid,
and I've noticd corrupted rendering of the terminus-oblique
font in my terminal (rxvt-unicode-256color). The problem is consistent,
in the form of missing pixels in the upper right areas of each glyph,
manifests right from the start of the session, is independent of the
kernel version (linux 3.16 or 4.0), and does not present itself when I
force xorg to use the modesetting driver instead.

The rendering issue only seems to appear in rxvt-unicode and
rxvt-unicode-256color though (e.g. not in konsole or gnome-terminal, nor
in xterm or xfontsel).


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug  9  2014 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2384712 May  5 01:24 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to 

Bug#785205: nvidia-kernel-dkms: fails to build with kernel 4.0 (sid)

[Giuseppe Bilotta]

Hello Vincent,

thanks for the prompt reply!

On Thu, May 14, 2015 at 9:49 AM, Vincent Cheng vch...@debian.org wrote:
 Please install either nvidia 340.76-2 (sid) or 346.59-1
 (experimental), and try rebuilding the nvidia module using dkms.

It seems 346.59-1 hasn't been pushed to experimental yet? I still see 343.36-1


-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785205: nvidia-kernel-dkms: fails to build with kernel 4.0 (sid)

[Giuseppe Bilotta]

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

I've recently upgraded the kernel on my machine to the latest
4.0.0-1-amd64 available on debian sid, and apparently the kernel side of
the nvidia driver 343.36-1 fails to build due to API differences. Might
be a good opportunity to upgrade the nvidia packages in debian to the
latest upstream.


-- Package-specific info:
uname -a:
Linux oblomov 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux

/proc/version:
Linux version 4.0.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: Dell Device [1028:05fe]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 35
Region 0: Memory at f740 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

dmesg:
[0.00] AGP: No AGP bridge found
[0.00] AGP: Checking aperture...
[0.00] AGP: No AGP bridge found
[0.475600] vgaarb: setting as boot device: PCI::00:02.0
[0.475604] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.475610] vgaarb: loaded
[0.475612] vgaarb: bridge control possible :00:02.0
[0.856335] Linux agpgart interface v0.103
[8.593366] [drm] Replacing VGA console driver
[8.616465] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[8.875660] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   22 Oct 21  2014 /etc/alternatives/glx - 
/usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   51 Oct 21  2014 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Aug 10  2014 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Aug 10  2014 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Oct 21  2014 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Oct 21  2014 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Oct 21  2014 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Oct 21  2014 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   54 Oct 21  2014 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Oct 21  2014 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   22 Aug 10  2014 /etc/alternatives/libGL.so-master 
- /usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   23 Mar 26 18:34 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   52 Mar 26 18:34 
/etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
lrwxrwxrwx 1 root root   49 Mar 26 18:34 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Mar 26 18:34 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Mar 26 18:34 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Mar 26 18:34 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   58 Mar 26 18:34 
/etc/alternatives/nvidia--libGLESv1_CM.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   58 Mar 26 18:34 
/etc/alternatives/nvidia--libGLESv1_CM.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   55 Mar 26 18:34 

Bug#781875: beignet: [regression] broken on Haswell

[Giuseppe Bilotta]

On Fri, Apr 17, 2015 at 11:16 PM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 now every kernel invocation, regardless of arguments
 counts and array sizes, fails

 i.e. including ones that worked in 1.0.2-1?

Yes.

 Do they use the 'local' memory
 space (which triggers a third known bug on Haswell)?

No, even the most trivial inits that simply writes to gmem fails the same way.

 drm_intel_gem_bo_context_exec() failed: Invalid argument

 That's the error check added by this patch, but not the same error code as I
 get for a too-large array on Ivy Bridge (that's
 drm_intel_gem_bo_context_exec() failed: No space left on device), so may
 be it catching a different bug.

 I will report this upstream.

Quite possible.

 sudo cat /sys/module/i915/parameters/enable_cmd_parser
 returns 1

 That means you don't have the #767148 workaround enabled.  Does it ( sudo
 echo 0  /sys/module/i915/parameters/enable_cmd_parser ) help?

Absolutely yes. I can e.g. manipulate arrays with up to 128Mi
elements, and if I go too high I get the No space left on device
error instead. So it looks like I _do_ need that workaround.

 What are your other i915 parameters ( sudo head
 /sys/module/i915/parameters/* )?

With the enable_cmd_parser set to 0 as above, this is the whole dump:

== /sys/module/i915/parameters/disable_display ==
N

== /sys/module/i915/parameters/disable_power_well ==
1

== /sys/module/i915/parameters/disable_vtd_wa ==
N

== /sys/module/i915/parameters/enable_cmd_parser ==
0

== /sys/module/i915/parameters/enable_fbc ==
-1

== /sys/module/i915/parameters/enable_hangcheck ==
Y

== /sys/module/i915/parameters/enable_ips ==
1

== /sys/module/i915/parameters/enable_ppgtt ==
1

== /sys/module/i915/parameters/enable_psr ==
0

== /sys/module/i915/parameters/enable_rc6 ==
1

== /sys/module/i915/parameters/fastboot ==
N

== /sys/module/i915/parameters/invert_brightness ==
0

== /sys/module/i915/parameters/lvds_channel_mode ==
0

== /sys/module/i915/parameters/lvds_downclock ==
0

== /sys/module/i915/parameters/lvds_use_ssc ==
-1

== /sys/module/i915/parameters/modeset ==
-1

== /sys/module/i915/parameters/panel_ignore_lid ==
1

== /sys/module/i915/parameters/powersave ==
1

== /sys/module/i915/parameters/prefault_disable ==
N

== /sys/module/i915/parameters/preliminary_hw_support ==
0

== /sys/module/i915/parameters/reset ==
Y

== /sys/module/i915/parameters/semaphores ==
-1

== /sys/module/i915/parameters/vbt_sdvo_panel_type ==
-1



-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781875: beignet: silently does nothing on large arrays

[Giuseppe Bilotta]

Hello,

I've finally had time to test the latest version in experimental
(1.0.2-2) and now every kernel invocation, regardless of arguments
counts and array sizes, fails with

drm_intel_gem_bo_context_exec() failed: Invalid argument

so I might be among the ones affected by the other bug you mention (I
run on 3.16.7-ckt9-2).

I do not have the workaround from #767148 enabled, at least I don't
remember ever enabling it.

sudo cat /sys/module/i915/parameters/enable_cmd_parser

returns 1.



On Fri, Apr 10, 2015 at 2:04 PM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 Control: tags -1 pending

 This is now fixed upstream and in Alioth (
 https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/log/ ).

 However, another recently-reported bug causes beignet to totally fail
 (appears in the platform list, but can't do any computations) on 3.15 and
 later kernels on at least some Haswell processors:
 http://lists.freedesktop.org/archives/beignet/2015-April/thread.html#5463

 Do you still have the workaround from #767148 enabled (which also avoids
 that bug but may be a security risk, to check run:
 sudo cat /sys/module/i915/parameters/enable_cmd_parser ), or is your
 processor just not affected?




-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781875: [Pkg-opencl-devel] Bug#781875: beignet: kernels don't seem to run

[Giuseppe Bilotta]

On Sat, Apr 4, 2015 at 10:30 AM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 The ICD interface works for me (i5-3230M), which makes this bug _both_
 hardware- and interface-dependent, which is weird.

The other person that I'm in contact with and whose machine exhibits
the same problem has an Iris Pro.

 Are you saying 1.0.0 didn't work for you at all, or are you saying 1.0.0
 worked properly and this is a regression?

The full story goes like this:

until now, I've used the Debian-shipped packages (in a combination of
unstable and experimental versions). I've never tested it extensively
though, mostly running through (my own) clinfo. The first version that
_seemed_ to work properly (at least under clinfo) was 1.0.1-1, which I
recently upgraded to 1.0.2-1. It was only at this point that I
actually tried running some kernels on the device, and noticed the
failures. I've discussed this with the Iris Pro user on FreeNode
(#opencl channel), and it turns out that they had a similar
experience, except they were using the git tree and 1.0.0 actually
worked for them, but 1.0.1 didn't.

I've finally found the time to do the testing and run git bisect,
which found the culprit at this commit:

a27428d2f30d7859cb988c6fa93a2964c443373d is the first bad commit
commit a27428d2f30d7859cb988c6fa93a2964c443373d
Author: Zhigang Gong zhigang.g...@intel.com
Date:   Wed Dec 24 09:21:28 2014 +0800

runtime: tweak max memory allocation size.

Increase the maximum memory allocation size to at least 512MB and
will set it to larger if the system has more total memory.

This tweak will make darktable happy to handle big pictures.

Signed-off-by: Zhigang Gong zhigang.g...@intel.com

v2:
reduce max constant buffer to 128MB.
v3:
fix the sysinfo usage.

Signed-off-by: Zhigang Gong zhigang.g...@intel.com
Tested-by: Meng, Mengmeng mengmeng.m...@intel.com

:04 04 af8bd19e9bf6f59d27fa2abc9fb67e4f6d476643
45aa59e8d4e84856d0152db1bcd814c58710e85b M  src

which I find odd but honestly I don't know anything about the beignet
internals to judge 8-P

I've been testing the commits primarily with my suite of
overallocation/migration tests available at
http://github.com/Oblomov/cltests which is a bit special, but in fact
even simpler setups will fail.

I'm also testing a much simpler program (trivial vector sum, of which
I can attach the code), from which I have some interesting findings.
The simple vector sum allocates three vectors of ints, initializes two
of them to some specific values (i, numels - i respectively) and then
computes the sum. The findings are:

* up to 128*1024*1024 elements, things work even at the 'bad' commit;
* twice that results in the failure;
* thrice that or more results in an invalid buffer size error (-61).

Now the interesting result is thus that 256Mi elements claim to work
(in term of buffer allocation), _but_ the kernels fail to run _at all_
(with the 'culprit' commit): even the first element in the buffers is
NOT updated correctly.

Instead, with the commit right before that (last 'good' commit), 128Mi
elements fail to allocate (64Mi elements work).

To sum it up, the increase in maximum memory allocation size to at
least 512MiB 'works', but only up to a point: specifically, 512MiB
buffers work correctly, but (at least on my device) 1024MiB buffers
(which are allowed) cause the kernel to fail launching even though the
allocation allegedly works.

Should I Cc: Zhigang Gong on the discussion? I can also produce the
simple vector sum core if needed.

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781754: crash in libclang while parsing autocomplete options

[Giuseppe Bilotta]

On Thu, Apr 2, 2015 at 6:32 PM, Onur Aslan o...@onur.im wrote:
 Control: tags -1 wontfix

 On 2015-04-02, Giuseppe Bilotta wrote:
 def FlagsForFile( filename ):
   return { 'flags' : ['-x c'] + cppflags + cflags, 'do_cache' : False }

 I think issue is '-x c', I tried your conf with ['-x', 'c'] and didn't
 get any crash.

I can't believe I made such a stupid mistake.

(Still, crashing with a wrong option doesn't sound like correct behavior).

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740949: segfault in webseed_destruct on exit if download speed limiting is enabled

[Giuseppe Bilotta]

I haven't had any issue with speed limiting and segfaults with the
latest release, I think the issue can be closed.

On Fri, Apr 3, 2015 at 5:10 PM, Sandro Tosi mo...@debian.org wrote:
 control: tags -1 + moreinfo

 Hello Giuseppe,
 are you able to replicate this segfault with 2.84? If so, can you
 install transmission-dbg and run transmission with gdb and when it
 crashes execute:

 bt
 bt full
 thread apply all bt

 ?

 Thanks,
 --
 Sandro Tosi (aka morph, morpheus, matrixhasu)
 My website: http://matrixhasu.altervista.org/
 Me at Debian: http://wiki.debian.org/SandroTosi



-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740950: segmentation fault in libcurl-gnutls.so.4 if download speed limiting is enabled

[Giuseppe Bilotta]

On Wed, Apr 1, 2015 at 12:10 AM, Sandro Tosi mo...@debian.org wrote:
 Hello,
 are you still able to replicate these frequent crashes with 2.84
 uploaded in sid? If so, please run again gdb executing

I haven't seen this issue in sid recently, I think we can close the issue.

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740948: stuck at 100% CPU utilization after --exit if download speed limiting is enabled

[Giuseppe Bilotta]

Hello, I can't seem to reproduce it anymore, I think we can close this.

On Fri, Apr 3, 2015 at 5:12 PM, Sandro Tosi mo...@debian.org wrote:
 control: tags -1 + moreinfo

 Hello Giuseppe,
 does it still happen with 2.84?

 Thanks,
 --
 Sandro Tosi (aka morph, morpheus, matrixhasu)
 My website: http://matrixhasu.altervista.org/
 Me at Debian: http://wiki.debian.org/SandroTosi



-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781875: beignet: kernels don't seem to run

[Giuseppe Bilotta]

Package: beignet-opencl-icd
Version: 1.0.2-1
Severity: grave
Tags: upstream

Since version 1.0.1 beignet has been able to recognitze the hardware on
my machine

00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06)

and responds regularly to device info queries as well as buffer
allocation commands. However, kernels don't seem to run at all, in any
form and with any queue properties. Buffers return untouched.

Discussion with people on #opencl indicate that the bug:

* affects upstream;
* only occurs when using beignet through the ICD interface;
* has been introduced _probably_ somewhere between 1.0.0 and 1.0.1.

It also seems that the issue cannot be noticed by simply running the
beignet tests, since they link directly to the library.

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

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

Versions of packages beignet-opencl-icd depends on:
ii  libc6  2.19-17
ii  libdrm-intel1  2.4.58-2
ii  libdrm22.4.58-2
ii  libedit2   3.1-20140620-2
ii  libffi63.1-2+b2
ii  libgcc11:4.9.2-10
ii  libllvm3.5 1:3.5-10
ii  libstdc++6 4.9.2-10
ii  libtinfo5  5.9+20140913-1+b1
ii  libx11-6   2:1.6.2-3
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.1-2+b2
ii  zlib1g 1:1.2.8.dfsg-2+b1

beignet-opencl-icd recommends no packages.

beignet-opencl-icd suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781754: crash in libclang while parsing autocomplete options

[Giuseppe Bilotta]

Package: vim-youcompleteme
Version: 0+20140207+git18be5c2-2
Severity: normal

With some configurations, libclang autocompletion is not available due
to an instantaneous crash. For example, I have a (whitelisted)
.ycm_extra_conf.py structured as such:

--- 8 --
import subprocess

cppflags=subprocess.check_output(env | grep CPPFLAGS - Makefile | cut -f2- 
-d=, shell=True).strip().split()
cflags=subprocess.check_output(env | grep CFLAGS - Makefile | cut -f2- -d=, 
shell=True).strip().split()

def FlagsForFile( filename ):
  return { 'flags' : ['-x c'] + cppflags + cflags, 'do_cache' : False }
--- 8 --

with a Makefile that includes the line

--- 8 --
CFLAGS+=-std=c99 -O3 -march=native -g -Wall
--- 8 --

and the resulting server logfiles for YCM end up being like this:

--- 8 --
2015-04-02 17:17:59,895 - INFO - Received event notification
2015-04-02 17:17:59,896 - INFO - Received event notification
2015-04-02 17:17:59,896 - INFO - Adding buffer identifiers for file: 
/home/oblomov/uni/PRISMA/codice/vecsum_ocl.c
libclang: crash detected during parsing: {
  'source_filename' : '/home/oblomov/uni/PRISMA/codice/vecsum_ocl.c'
  'command_line_args' : ['-x c', '-std=c99', '-O3', '-march=native', '-g', 
'-Wall', '-isystem', '/usr/lib/vim-youcompleteme/clang_includes'],
  'unsaved_files' : [('/home/oblomov/uni/PRISMA/codice/vecsum_ocl.c', '...', 
2829)],
  'options' : 12,
}
2015-04-02 17:18:03,762 - INFO - Received health request
2015-04-02 17:18:03,769 - INFO - Received debug info request
--- 8 --

This might be a bug in libclang rather than in the way YCM, but I don't
know. :YcmDebugInfo shows:

--- 8 --
-- Server has Clang support compiled in: True
-- Clang version: Debian clang version 3.5.0-10 (tags/RELEASE_350/final)
(based on LLVM 3.5.0)
-- Flags for /home/oblomov/uni/PRISMA/codice/vecsum_ocl.c loaded from 
/home/oblomov/uni/PRISMA/codice/.ycm_extra_conf.py:
-- ['-x c', '-std=c99', '-O3', '-march=native', '-g', '-Wall', '-isystem', 
'/usr/lib/vim-youcompleteme/clang_includes']
--- 8 --

Anything else I can do to help track down the issue?

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

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

Versions of packages vim-youcompleteme depends on:
ii  libboost-filesystem1.55.0   1.55.0+dfsg-3
ii  libboost-python1.55.0   1.55.0+dfsg-3
ii  libboost-regex1.55.01.55.0+dfsg-3
ii  libboost-system1.55.0   1.55.0+dfsg-3
ii  libc6   2.19-17
ii  libclang1-3.5   1:3.5-10
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10
ii  python-bottle   0.12.7-1
ii  python-concurrent.futures [python-futures]  2.2.0-1
ii  python-jedi 0.8.1-1
ii  python-requests 2.4.3-6
ii  python-waitress 0.8.9-2
ii  python2.7   2.7.9-2
pn  python:any  none
ii  vim-gtk [vim-python]2:7.4.488-7

Versions of packages vim-youcompleteme recommends:
ii  vim-addon-manager  0.5.3

vim-youcompleteme suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780390: v86d: segfault in libc

[Giuseppe Bilotta]

Package: v86d
Version: 0.1.10-1
Severity: normal

I've recently noticed this message in my early dmesg boot:

[1.594636] v86d[160]: segfault at 7ffd29b9f3e0 ip 7f66ca1f6e64 sp 
7ffc29bb02f8 error 4 in libc.so.6[7f66ca175000+19f000]

I'm honestly not sure when it started happening though. The system
doesn't seem to be otherwise affected, AFAICS.

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

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

Versions of packages v86d depends on:
ii  libc6 2.19-15
ii  libx86-1  1.1+ds1-10

Versions of packages v86d recommends:
ii  initramfs-tools  0.119

v86d suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761981: systemd re-enables masked services on upgrade

[Giuseppe Bilotta]

Hello,

On Mon, Nov 17, 2014 at 2:32 PM, intrigeri intrig...@debian.org wrote:
 Can you reproduce the problem (e.g. by re-installing systemd or
 downgrading and upgrading systemd again)?

Can't seem to reproduce. We can close this bug, I'll reopen it with
more information if it reoccurs.

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769293: [Pkg-opencl-devel] Bug#769293: beignet: upgrade or OCL_STRICT_CONFORMANCE change requires reboot

[Giuseppe Bilotta]

On Wed, Nov 12, 2014 at 5:30 PM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 Don't quite understand this issue. How do you set the
 OCL_STRICT_CONFORMANCE?

 This is Debian's beignet 0.9.3~dfsg-1 (current unstable)
 and accuracy_speed_test.py from
 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;filename=accuracy_speed_test.py;att=4;bug=768090

 rnpalmer@rnpalmer-laptop:~$ python3 ~/Debian/OpenCL/accuracy_speed_test.py
 [...]
 cos abs avg err: 1.72732e-05  max err: 6.10352e-05 rel avg err: 2.02569e-05
 max err: 6.10352e-05  time: 0.07409429550170898
 [...]
 rnpalmer@rnpalmer-laptop:~$ export OCL_STRICT_CONFORMANCE=1
 rnpalmer@rnpalmer-laptop:~$ python3 ~/Debian/OpenCL/accuracy_speed_test.py
 [...]
 cos abs avg err: 1.73168e-05  max err: 6.10352e-05 rel avg err: 2.03032e-05
 max err: 6.10352e-05  time: 0.0025167465209960938
 [...]

Could it be an issue with compiled kernel cache? I haven't looked at
how beignet handles this, but some platforms have some very aggressive
policy for compiled kernels. Can you try to find where beignet caches
its compiles and see if removing the cached kernels fixes this? If so,
the only thing that should be changed in beignet is that a kernel
cache invalidation on OCL_STRICT_CONFORMANCE change, or a way to have
separate caches for separate settings.


-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768185: beignet kills calling application on program build errors, logging errors to console

[Giuseppe Bilotta]

On Wed, Nov 5, 2014 at 8:38 PM, Andreas Beckmann a...@debian.org wrote:
 On 2014-11-05 20:16, Giuseppe Bilotta wrote:
 Running clinfo from http://github.com/Oblomov/clinfo with beignet installed

 Which other icds do you have installed?

 find /etc/OpenCL/vendors

I have a multitude of them:

mesa.icd (from Debian's unstable package repositories)
nvidia.icd (from Debian's unstable package repositories)
amdocl64.icd (from Debian's unstable package repositories)
intel64.icd (Intel's proprietary CPU OpenCL platform, downloaded from
their website)
intel-beignet.icd (from Debian's unstable package repositories)
pocl.icd (hand-compiled from pocl' master git branch)

 I've seen that as well, but it seems to be related to ordering of
 multiple icds that may not cooperate cleanly depending on the loading
 order ...

 have you tried

 OCL_ICD_VENDORS=intel-beignet.icd path/to/your/clinfo

I've filtered out all vendors and then started adding them back one by
one. The one that causes troubles seems to be the mesa ICD.

So there are actually THREE issues here:

1. kernel build errors should not go to stderr, but to the build log;
2. the library shoud not terminate the calling program in case of errors;
3. there's a conflict with the mesa ICD (maybe beignet and mesa are
compiled against different versions of libllvm?)

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768185: [Pkg-opencl-devel] Bug#768185: beignet kills calling application on program build errors, logging errors to console

[Giuseppe Bilotta]

On Wed, Nov 5, 2014 at 9:33 PM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)

 beignet doesn't work on that version of Linux (#767148); a fixed version was
 uploaded yesterday.  Does upgrading to that help?

Ah, interesting. I see there's also a kernel upgrade. I'll upgrade
everything and report back on it.

 What hardware are you using?

It's a Dell XPS 15 from two months ago. This is the lspci -nnvv of my
integrated GPU:

00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen
Core Processor Integrated Graphics Controller [8086:0416] (rev 06)
(prog-if 00 [VGA controller])
Subsystem: Dell Device [1028:05fe]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 51
Region 0: Memory at f740 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

The CPU is an eight-core specced as such:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4712HQ CPU @ 2.30GHz
stepping : 3
microcode : 0x1c
cpu MHz : 2308.625
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm
ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept
vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips : 4589.41
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

(etc)

 Does the error occur on any attempt to use OpenCL, or only with this
 program?  (If you don't have any real OpenCL-using programs yet, there's a
 test script at
 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=beignet_test.py;att=1;bug=767148
 , requires python3-pyopencl, python3-numpy)

I have a variety of opencl applications, and the error appears quite
consistently when I try to compile my kernels.

 If the latter, the clinfo Debian package is a different program with similar
 functionality, so you may want to use that instead (though I do agree this
 is probably a beignet bug).

The clinfo in Debian fails on my system due to the presence of 1.1
platforms and platforms without devices (mesa).

There is most likely something in my system that causes the issue,
which needs to be looked into more closely, but the point is that the
library should _not_ call an exit() in case of error (and it shouldn't
dump compilation errors on stderr).

I'm adding more information about the configuration of my system in my
reply to Andreas.

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768185: [Pkg-opencl-devel] Bug#768185: Bug#768185: beignet kills calling application on program build errors, logging errors to console

[Giuseppe Bilotta]

On Fri, Nov 7, 2014 at 2:37 PM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 It's a Dell XPS 15 from two months ago. [...]
 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen
 Core Processor Integrated Graphics Controller [8086:0416] (rev 06)
 (prog-if 00 [VGA controller]) [...]
 model name : Intel(R) Core(TM) i7-4712HQ CPU @ 2.30GHz

 That should work after upgrading linux if the Intel GPU is enabled (see
 http://nouveau.freedesktop.org/wiki/Optimus/ for how to check that), but
 shared local memory won't work.  (There is a fix for that, but for security
 reasons I can't recommend it:
 https://01.org/beignet/downloads/linux-kernel-patch-hsw-support?langredirect=1
 )

Thanks for the information. The IGP is enabled (it's what I use for my
primary display). I'm only toying around with it for compute though (I
use the discrete NVIDIA GPU for the serious stuff, due to the ratio in
power), but thanks for the hint.

 library should _not_ call an exit() in case of error

 I agree: one of my goals is to have OpenCL just work (without the user
 needing to specifically set it up), which requires proper hardware not
 supported handling:
 http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140421/000122.html

Ah, that's tricky, at the packaging level. What I think is:

* all GPU-related ICDs should be installed, whenever the corresponding
video driver is;
* at least one CPU-capable ICD should also be installed;

tagging the ICDs appropriately might be the way to go about it.

 The clinfo in Debian fails on my system due to the presence of 1.1
 platforms and platforms without devices (mesa).

 That was supposed to be fixed (#721103), but #767985 suggests you're not the
 only one with that problem.

I think the 1.1 was fixed, but the platform with no devices
definitely wasn't. Possibly because I forgot to report it.

 Giuseppe Oblomov Bilotta

 Oblomov as in the author of this clinfo?

Yes, I'm in fact the author of this clinfo.

 We're currently discussing whether
 to replace Debian's clinfo with it (though due to the release freeze, this
 can't happen immediately):
 http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20141103/date.html

Well, I can obviously recommend mine 8-)

Should I subscribe to the pkg-opencl-devel ML?

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768185: [Pkg-opencl-devel] Bug#768185: Bug#768185: beignet kills calling application on program build errors, logging errors to console

[Giuseppe Bilotta]

On Fri, Nov 7, 2014 at 7:45 PM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
 Warning on the kernel upgrade: it froze my system, see #768483.

 Ah, that's tricky, at the packaging level. What I think is:

 * all GPU-related ICDs should be installed, whenever the corresponding
 video driver is;
 * at least one CPU-capable ICD should also be installed;

 Linking it to the video driver doesn't help because those currently default
 to installing them all (which is where I got the idea of doing the same for
 ICDs): you still need to properly handle the ICD installed (platform) but
 no hardware (device) case, which as noted in this bug and in
 http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140421/000122.html
 , many things currently don't.

Ah, good point. I had missed the detailed comment about that on my
first quick read. I'll think about it.

 Should I subscribe to the pkg-opencl-devel ML?

 If you want to participate in more general OpenCL-in-Debian discussions,
 yes; anyone can do so.  It does receive some spam, but typically only every
 few days.

I've subscribed, and sent a comment about the clinfo. I'll also share
my thoughts on the ICD thing as soon as I have an idea about it.

-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768185: beignet kills calling application on program build errors, logging errors to console

[Giuseppe Bilotta]

Package: beignet
Version: 0.9.3~dfsg-1
Severity: important

Running clinfo from http://github.com/Oblomov/clinfo with beignet installed
results in two undesired behaviours when clinfo tries to compile some
kernels:

1. the following messages are logged to stderr

premain: CommandLine Error: Option 'error-reporting-is-cold' registered more 
than once!
premain: CommandLine Error: Option 'simplifycfg-hoist-cond-stores' registered 
more than once!
premain: CommandLine Error: Option 'simplifycfg-sink-common' registered more 
than once!
premain: CommandLine Error: Option 'simplifycfg-dup-ret' registered more than 
once!
premain: CommandLine Error: Option 'phi-node-folding-threshold' registered 
more than once!
premain: CommandLine Error: Option 'unlikely-branch-weight' registered more 
than once!
premain: CommandLine Error: Option 'likely-branch-weight' registered more 
than once!
premain: CommandLine Error: Option 'no-discriminators' registered more than 
once!
premain: CommandLine Error: Option 'combine-loads' registered more than once!
premain: CommandLine Error: Option 'reroll-loops' registered more than once!
premain: CommandLine Error: Option 'use-new-sroa' registered more than once!
premain: CommandLine Error: Option 'use-gvn-after-vectorization' registered 
more than once!
premain: CommandLine Error: Option 'vectorize-slp-aggressive' registered more 
than once!
premain: CommandLine Error: Option 'vectorize-slp' registered more than once!
premain: CommandLine Error: Option 'vectorize-loops' registered more than 
once!
premain: CommandLine Error: Option 'internalize-public-api-list' registered 
more than once!
premain: CommandLine Error: Option 'internalize-public-api-file' registered 
more than once!
premain: CommandLine Error: Option 'inlinecold-threshold' registered more 
than once!
premain: CommandLine Error: Option 'inlinehint-threshold' registered more 
than once!
premain: CommandLine Error: Option 'inline-threshold' registered more than 
once!
premain: CommandLine Error: Option 'enable-objc-arc-opts' registered more 
than once!
premain: CommandLine Error: Option 'enable-tbaa' registered more than once!
premain: CommandLine Error: Option 'verify-scev' registered more than once!
premain: CommandLine Error: Option 'scalar-evolution-max-iterations' 
registered more than once!
premain: CommandLine Error: Option 'verify-loop-info' registered more than 
once!
premain: CommandLine Error: Option 'da-delinearize' registered more than once!
premain: CommandLine Error: Option 'info-output-file' registered more than 
once!
premain: CommandLine Error: Option 'track-memory' registered more than once!
premain: CommandLine Error: Option 'stats' registered more than once!
premain: CommandLine Error: Option 'rng-seed' registered more than once!
premain: CommandLine Error: Option 'view-background' registered more than 
once!
premain: CommandLine Error: Option 'version' registered more than once!
premain: CommandLine Error: Option 'print-all-options' registered more than 
once!
premain: CommandLine Error: Option 'print-options' registered more than once!
premain: CommandLine Error: Option 'help-hidden' registered more than once!
premain: CommandLine Error: Option 'help' registered more than once!
premain: CommandLine Error: Option 'help-list-hidden' registered more than 
once!
premain: CommandLine Error: Option 'help-list' registered more than once!
premain: CommandLine Error: Option 'sample-profile-max-propagate-iterations' 
registered more than once!
premain: CommandLine Error: Option 'sample-profile-file' registered more than 
once!
premain: CommandLine Error: Option 'sroa-strict-inbounds' registered more 
than once!
premain: CommandLine Error: Option 'sroa-random-shuffle-slices' registered 
more than once!
premain: CommandLine Error: Option 'force-ssa-updater' registered more than 
once!
premain: CommandLine Error: Option 'mlsm' registered more than once!
premain: CommandLine Error: Option 'loop-unswitch-threshold' registered more 
than once!
premain: CommandLine Error: Option 'pragma-unroll-threshold' registered more 
than once!
premain: CommandLine Error: Option 'unroll-runtime' registered more than once!
premain: CommandLine Error: Option 'unroll-allow-partial' registered more 
than once!
premain: CommandLine Error: Option 'unroll-count' registered more than once!
premain: CommandLine Error: Option 'unroll-threshold' registered more than 
once!
premain: CommandLine Error: Option 'rotation-max-header-size' registered more 
than once!
premain: CommandLine Error: Option 'max-reroll-increment' registered more 
than once!
premain: CommandLine Error: Option 'disable-licm-promotion' registered more 
than once!
premain: CommandLine Error: Option 'jump-threading-threshold' registered more 
than once!
premain: CommandLine Error: Option 'liv-reduce' registered more than once!
premain: CommandLine Error: Option 'verify-indvars' registered more than once!
premain: CommandLine Error: Option 'max-recurse-depth' registered more 

Bug#766343: nvidia-smi: nvidia-smi not available

[Giuseppe Bilotta]

Package: nvidia-smi
Version: 340.46-3
Severity: important

Something in the recent upgrades (I think starting from 340.46.2) has
made nvidia-smi unavailable on the command line. The executable is still
available under /usr/lib/#PRIVATE#, but no symlink to /usr/bin is
created. This could be related to the newly introduced support for the
switch via nvidia-alternative (which apparently fails to actually enable
the alternative for nvidia-smi).

-- Package-specific info:
uname -a:
Linux oblomov 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10) x86_64 GNU/Linux

/proc/version:
Linux version 3.16-3-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-12) ) #1 SMP Debian 3.16.5-1 (2014-10-10)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.46  Wed Sep 24 14:23:40 PDT 
2014
GCC version:  gcc version 4.8.3 (Debian 4.8.3-13) 

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: Dell Device [1028:05fe]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 50
Region 0: Memory at f740 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

dmesg:
[0.00] AGP: No AGP bridge found
[0.00] AGP: Checking aperture...
[0.00] AGP: No AGP bridge found
[0.535940] vgaarb: setting as boot device: PCI::00:02.0
[0.535942] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.535946] vgaarb: loaded
[0.535948] vgaarb: bridge control possible :00:02.0
[0.911944] Linux agpgart interface v0.103
[8.727323] [drm] Replacing VGA console driver
[8.765062] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[8.814463] nvidia: module license 'NVIDIA' taints kernel.
[8.824370] nvidia :02:00.0: enabling device (0006 - 0007)
[9.002744] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
[   10.126946] [drm] Initialized nvidia-drm 0.0.0 20130102 for :02:00.0 on 
minor 1
[   10.126989] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.46  Wed Sep 
24 14:23:40 PDT 2014
[12880.298228] nvidia :02:00.0: irq 54 for MSI/MSI-X
[12884.874620] NVRM: RmInitAdapter failed! (0x24:0x38:1176)
[12884.874626] NVRM: rm_init_adapter failed for device bearing minor number 0
[12884.874656] NVRM: nvidia_frontend_open: minor 0, module-open() failed, 
error -5
[12887.158729] nvidia :02:00.0: irq 54 for MSI/MSI-X

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   22 Oct 21 08:28 /etc/alternatives/glx - 
/usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   51 Oct 21 08:28 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Aug 10 07:18 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Aug 10 07:18 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Oct 21 08:28 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Oct 21 08:28 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Oct 21 08:28 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Oct 21 08:28 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   54 Oct 21 08:28 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Oct 21 08:28 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu - 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   22 Aug 10 07:18 /etc/alternatives/libGL.so-master 
- /usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   23 Oct 22 14:01 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   52 Oct 22 14:01 
/etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
lrwxrwxrwx 1 root root   49 Oct 22 14:01 

Bug#766150: cannot be installed due to a file shipped also in kate-data

[Giuseppe Bilotta]

Package: kate
Version: 4:4.14.2-1
Severity: grave

Trying to upgrade to kate 4:4.14.2-1 on amd64 fails due to:

Preparing to unpack .../kate_4%3a4.14.2-1_amd64.deb ...
Unpacking kate (4:4.14.2-1) ...
dpkg: error processing archive
/var/cache/apt/archives/kate_4%3a4.14.2-1_amd64.deb (--unpack):
 trying to overwrite
 '/usr/share/kde4/apps/kate/plugins/project/kateproject.example', which
 is also in package kate-data 4:4.14.2-1
 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
 Errors were encountered while processing:
  /var/cache/apt/archives/kate_4%3a4.14.2-1_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

(Probably the file should only be shipped with kate-data.)

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

Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765725: Crash with terminate called after throwing an instance of 'Gio::Error'

[Giuseppe Bilotta]

Package: pavucontrol
Version: 2.0-2
Followup-For: Bug #765725

I'm experiencing the same error, consistently, when Chromium is running
and on a WebRTC-enabled page. For example, start Chromium, enable WebRTC
support, go to http://appear.in/linux and accept to share webcam and
microphone. Then start pavucontrol, and pavucontrol will segfault with
the following backtrace:


#0  0x72a41077 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 7669
selftid = 7669
#1  0x72a42458 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x964790, sa_sigaction = 
0x964790}, sa_mask = {__val = {12179648, 6595224, 140737351949831, 1, 0, 
140737337045957, 140737264037160, 140737337045957, 6595224, 12166736, 
140737351975717, 140737353611808, 12111312, 
  1, 140737353614160, 12111312}}, sa_flags = -9560, sa_restorer = 
0x7fffd5b0}
sigs = {__val = {32, 0 repeats 15 times}}
#2  0x73548b2d in __gnu_cxx::__verbose_terminate_handler() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0x73546ba6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#4  0x73546bf1 in std::terminate() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#5  0x73546e09 in __cxa_throw () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#6  0x76f68ff7 in Gio::Error::throw_func(_GError*) () from 
/usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
No symbol table info available.
#7  0x76a26977 in Glib::Error::throw_exception(_GError*) () from 
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
No symbol table info available.
#8  0x779c6ced in Gtk::IconTheme::load_icon(Glib::ustring const, int, 
Gtk::IconLookupFlags) const () from /usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
No symbol table info available.
#9  0x0041f3b2 in set_icon_name_fallback (i=i@entry=0xb9fcc0, 
name=name@entry=0xb10a10 chromium, size=..., size@entry=...) at 
mainwindow.cc:244
theme = optimized out
pixbuf = {pCppObject_ = 0x0}
width = 16
height = 16
#10 0x0041f7c8 in MainWindow::setIconFromProplist 
(this=this@entry=0x9645f0, icon=0xb9fcc0, l=0xa61f90, def=def@entry=0x43deae 
audio-card) at mainwindow.cc:666
t = 0xb10a10 chromium
#11 0x004271c8 in MainWindow::updateSinkInput (this=0x9645f0, info=...) 
at mainwindow.cc:715
t = optimized out
w = 0xb84740
is_new = true
txt = optimized out
#12 0x7380ccf5 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
No symbol table info available.
#13 0x7fffedbbab61 in ?? () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so
No symbol table info available.
#14 0x7fffedbbaef3 in pa_pdispatch_run () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so
No symbol table info available.
#15 0x738026ae in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
No symbol table info available.
#16 0x7fffedbbf160 in ?? () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so
No symbol table info available.
#17 0x73a45bba in ?? () from 
/usr/lib/x86_64-linux-gnu/libpulse-mainloop-glib.so.0
No symbol table info available.
#18 0x73c92c5d in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#19 0x73c92f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#20 0x73c93272 in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#21 0x7578ba85 in gtk_main () from 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
No symbol table info available.
#22 0x779d612f in Gtk::Main::run(Gtk::Window) () from 
/usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
No symbol table info available.
#23 0x0040ed3e in main (argc=1, argv=0x7fffe428) at 
pavucontrol.cc:683
kit = incomplete type
mainWindow = 0x9645f0
m = 0x976f00
group = incomplete type
entry2 = incomplete type
__PRETTY_FUNCTION__ = int main(int, char**)
options = incomplete type
entry = incomplete type


(I'm also having audio issues with WebRTC in chromium (can't hear others,
others can't hear me), which might be related, but I'll file that
separately since it's obviously a Chromium issue.)

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

Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pavucontrol depends on:
ii  

Bug#763208: /sbin/dhclient-script: Permission denied errors on /etc/dhcp/dhclient-*-hooks.d/*

[Giuseppe Bilotta]

Package: isc-dhcp-client
Version: 4.3.1-2
Severity: normal

I normally bring up my network manually with a command such as: `sudo
ifup wlan0=somenetwork` where somenetwork is defined in
/etc/network/interfaces. Since the last dist-upgrade, I'm getting the
following permission denied errors when bringing up the interface:

/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-enter-hooks.d/debug: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-enter-hooks.d/resolvconf: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/debug: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/ntp: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/ntpdate: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes: Permission denied

[ usual messages about Listening, DHCPDISCOVER etc until a DHCPACK, and
then again: ]

/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-enter-hooks.d/debug: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-enter-hooks.d/resolvconf: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/debug: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/ntp: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/ntpdate: Permission denied
/sbin/dhclient-script: 117: /sbin/dhclient-script: 
/etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes: Permission denied

[bound to blahblahblah and then (probably due to the above):]

/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link 
to /etc/resolvconf/run/resolv.conf

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

Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages isc-dhcp-client depends on:
ii  debianutils  4.4
ii  iproute2 3.16.0-2
ii  isc-dhcp-common  4.3.1-2
ii  libc62.19-11

isc-dhcp-client recommends no packages.

Versions of packages isc-dhcp-client suggests:
ii  avahi-autoipd  0.6.31-4
ii  resolvconf 1.75

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org