Bug#1065270: Unable to open VTK file with appended data that were fine with previous versions (invalid token in vtkXMLDataParser)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
=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
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
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
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
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'
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
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
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
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
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
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"
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"
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
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
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
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
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
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
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
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
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)
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
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 Healywrote: > 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
On Sat, May 13, 2017 at 12:42 PM, Konstantin Tokarevwrote: > 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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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)
Hello Alastair, On Mon, May 2, 2016 at 4:04 PM, Alastair McKinstrywrote: > 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)
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
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
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
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
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
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
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.
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
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
On Sun, Oct 11, 2015 at 4:39 PM, Julien Cristauwrote: > 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
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
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
Hello On Mon, Oct 5, 2015 at 11:15 AM, Martin Pittwrote: >> 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)
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
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
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
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)
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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/*
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