Bug#964214: libdebhelper-perl: dh_auto_configure cannot do out-of-tree builds for qmake buildsystem
On Sat, 4 Jul 2020 00:01:15 +0200 Niels Thykier wrote: > Thorsten Glaser: > > Package: libdebhelper-perl > > Version: 13.1 > > Severity: normal > > > > Apparently, dh7 fails to tell qmake the location of the source directory > > when attempting an out-of-tree build: > > > > > > […] > > > > > > The qmake invocation syntax error message is somewhat misleading, > > but looking at the invocation command line it becomes somewhat clearer. > > > > Interesting. I am not sure out of source builds have ever been > supported by qmake (at least not correctly at any rate). If you know > how to do it, then I am happy to look at fixing it. Qmake does indeed support out of source builds (and for a long time - you can find questions about it on the forums from 2010). You can check a possible implementation of debhelper support for it in MR 125. Regards Jiri Palecek
Bug#996557: linux-image-5.14.0-3-686-pae-unsigned: just about every sse2 program crashes with a SIGFPE
Package: src:linux Version: 5.14.12-1 Severity: serious X-Debbugs-Cc: Jiri Palecek Dear Maintainer, when I booted my system with the latest kernel from unstable, many of the applications didn't work. That includes plasmashell (so I couldn't log in into plasma) and chromium. I ran xterm (which worked) and some of these failing programs under gdb and found they all tripped on some sse2 instructions with a SIGFPE. However, all the programs work under the kernel from linux-image-5.14.0-2-. Regards Jiri Palecek -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information ** PCI devices: 00:00.0 RAM memory [0500]: NVIDIA Corporation MCP61 Host Bridge [10de:03e2] (rev a1) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP61 LPC Bridge [10de:03e1] (rev a2) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: nForce2_smbus Kernel modules: i2c_nforce2 00:01.2 RAM memory [0500]: NVIDIA Corporation MCP61 Memory Controller [10de:03f5] (rev a2) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0 Controller [10de:03f2] (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:04.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI bridge [10de:03f3] (rev a1) (prog-if 01 [Subtractive decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn- Capabilities: 00:05.0 Audio device [0403]: NVIDIA Corporation MCP61 High Definition Audio [10de:03f0] (rev a2) Subsystem: ASUSTeK Computer Inc. MCP61 High Definition Audio [1043:840c] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:06.0 IDE interface [0101]: NVIDIA Corporation MCP61 IDE [10de:03ec] (rev a2) (prog-if 8a [ISA Compatibility mode controller, supports both channels switched to PCI native mode, supports bus mastering]) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: pata_amd Kernel modules: pata_amd, ata_generic 00:07.0 Bridge [0680]: NVIDIA Corporation MCP61 Ethernet [10de:03ef] (rev a2) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: forcedeth Kernel modules: forcedeth 00:08.0 IDE interface [0101]: NVIDIA Corporation MCP61 SATA Controller [10de:03f6] (rev a2) (prog-if 85 [PCI native mode-only controller, supports bus mastering]) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: sata_nv Kernel modules: sata_nv, ata_generic 00:08.1 IDE interface [0101]: NVIDIA Corporation MCP61 SATA Controller [10de:03f6] (rev a2) (prog-if 85 [PCI native mode-only controller, supports bus mastering]) Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4
Bug#991456: firefox: crashes when zooming in on chatguesser map
Package: firefox
Version: 90.0-2
Severity: normal
X-Debbugs-Cc: Jiri Palecek
Dear Maintainer,
there is a nasty crash in firefox from version 90, that makes it almost
unusable at least for me. It happens on more pages randomly, but I could
best reproduce it by going on a chatguesser map
(eg. http://chatguesser.com/map/nuujaka) and zooming in several times
with a wheel.
This crash is already noted upstream:
https://bugzilla.mozilla.org/show_bug.cgi?id=1719232
But when I tried to bisect it with the mozregression tool, I couldn't
reproduce the bug with mozilla's nightlies. So there must be something
in the Debian build process which at least facilitates the emergence of
the crashes.
The crash happens on i386, not on amd64. It also crashes on OS X.
Could you help with that, please?
Regards
Jiri Palecek
-- Package-specific info:
-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: NoScript
Location: /usr/share/webext/noscript
Package: webext-noscript
Status: enabled
Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Reset Search Defaults
Location:
/home/jirka/.mozilla/firefox/jt9usqcb.default-release/features/{0069d56b-c86a-4697-8860-239b14c84951}/reset-search-defau...@mozilla.com.xpi
Status: enabled
Name: System theme theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: enabled
Name: Web Compatibility Interventions
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled
Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
-- Addons package information
ii firefox 90.0-2 i386 Mozilla Firefox web browser
ii webext-noscript 10.1.9.6-2 all permissions manager for Firefox
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-security'), (500, 'testing-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: i386 (i686)
Foreign Architectures: amd64
Kernel: Linux 5.7.0-1-686-pae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages firefox depends on:
ii debianutils 4.11.2
ii fontconfig 2.13.1-4.2
ii libatk1.0-0 2.36.0-2
ii libc62.31-11
ii libcairo-gobject21.16.0-5
ii libcairo21.16.0-5
ii libdbus-1-3 1.12.20-2
ii libdbus-glib-1-2 0.110-6
ii libevent-2.1-7 2.1.12-stable-1
ii libffi7 3.3-3
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgcc-s111-20210424-1
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libglib2.0-0 2.66.8-1
ii libgtk-3-0 3.24.24-4
ii libnspr4 2:4.29-1
ii libnss3 2:3.67-2
ii libpango-1.0-0 1.46.2-3
ii libstdc++6 11-20210424-1
ii libvpx6 1.10.0+really1.8.1-dmo1
ii libx11-6 2:1.7.1-1
ii libx11-xcb1 2:1.7.1-1
ii libxcb-shm0 1.14-2
ii libxcb1 1.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-1
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxrender1 1:0.9.10-1
ii procps 2:3.3.17-5
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages firefox recommends:
ii libavcodec58 10:4.4-dmo4
Versions of packages firefox suggests:
ii fonts-lmodern 2.004.5-5
ii fonts-stix [otf-stix] 1.1.1-3
ii
Bug#989691: Please package valgrind 3.17
While you're at it, could you please include the fix in this patch? https://sourceware.org/git/?p=valgrind.git;a=commit;h=e08a82991a9b9dc87c13f2b89273f25f97d14baf It is a bug which affects Qt applications using QProcess. Regards Jiri Palecek
Bug#963191: RFH: aufs
On Sat, 20 Jun 2020 12:14:17 +0200 Jan Luca Naumann wrote: > Package: wnpp > Severity: normal > > At the moment aufs is nearly unmaintained since I do not have time due to personal issues. Therefore, I would be happy if there is somebody to co-maintain the package. > > Open issues are: > > - Update to current version > - Add a version in backports > - Support multiple kernel versions at the same time > > I try to take a look at this problems in the near future but I would be happy about help. Hello sorry about taking so long to reach out to you, but I've been using my own modified aufs package for some time now. I believe it supports all three of your requirements (eg. it creates package aufs-dkms-5.7 for a kernel version, so you can have more of them installed). You can check it out here: https://salsa.debian.org/jpalecek-guest/aufs-debian To update to a newer version, do: $ uscan $ cd ../aufs-X.XX $ touch debian/config.in $ debian/rules files You can also do "gbp import orig" if you like. However, there's a more serious problem with aufs. The latest kernel omits the kernel patch needed to make the module, which means the resulting package is useless. See: https://salsa.debian.org/kernel-team/linux/-/commit/908c469bc64738ac2f7d0f21a5daee9648be#note_244404 What is your take on this? I was using aufs for schroot only, and maybe will try to use other ways. Regards Jiri Palecek
Bug#950790: libqt5qml5: Do a double build with SSE2 enabled on i386
Hello, On Thu, 6 Feb 2020 17:43:53 +0300 Dmitry Shachnev wrote: > On Thu, Feb 06, 2020 at 11:08:41AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > Lars pointed out [1] that QtQml (and so I guess this lib, will need to double > > check) would really benefit from a i386 build with SSE2 enabled. > > > > [1] > > Already discussed on IRC, but for the record: > > Actually Qt QML has a runtime requirement for SSE2, so I am not sure the > non-SSE2 build makes sense: > > https://sources.debian.org/src/qtdeclarative-opensource-src/5.12.5-5/src/qml/qml/v8/qv8engine.cpp/#L143 > > I think we should just switch the default build to SSE2 by passing > CONFIG+=sse2 to qmake when DEB_HOST_ARCH_CPU = i386. I doubt it. First, the line you reference (and any other reference to SSE2) is missing from the current sources, second, it is alleged qml should work without sse2 just with interpreted bytecode. However, I tried the dual build and it is actually hard to compile it with sse2 enabled: CONFIG+=sse2 QMAKE_CxxxFLAGS+=-msse2 etc. all don't work. Either it does nothing, or it fails to enable the jit in build. It seems this feature is hard coded in the file /usr/lib/i386-linux-gnu/qt5/mkspecs/qmodule.pri By editing that file I found out I needed to change QT.global_private.enabled_features to make it work. Which is super ugly. You can see the result here: https://salsa.debian.org/jpalecek-guest/qtdeclarative I still need to test the resulting binaries. Regards Jiri Palecek
Bug#964458: checkinstall: causes segfault of cmake
Hello, On 07. 07. 20 17:11, Stephen Gelman wrote: On Jul 7, 2020, at 9:42 AM, Jiri Palecek wrote: Package: checkinstall Version: 1.6.2+git20170426.d24a630-2 Severity: important File: /usr/bin/installwatch Dear Maintainer, while trying to use checkinstall to create a debianized package from a cmake based source, the build failed with a segfault. These are linked to installwatch and don't happen without it: $ installwatch make cmake_check_build_system INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup do paměti (SIGSEGV) (obraz paměti uložen) There is a backtrace of the crash, which indicates it happens early in the initialization of cmake around a stat call: (gdb) bt #0 0x in ?? () #1 0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455 #2 _gnutls_update_system_priorities () at ../../lib/priority.c:1309 #3 0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at ../../lib/global.c:387 #4 0xb6a25950 in lib_init () at ../../lib/global.c:511 #5 0xb7f35f5c in call_init (l=, argc=argc@entry=6, argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72 #6 0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, l=) at dl-init.c:30 #7 _dl_init (main_map=, argc=6, argv=0xbfe33e64, env=0xbfe33e80) at dl-init.c:119 #8 0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2 (gdb) frame 1 #1 0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455 455 return __xstat (_STAT_VER, __path, __statbuf); Why did it end up with EIP=0 I don't know. It seems there's some incompatibility between installwatch's LD_PRELOAD and glibc. Could you have a look at it? Regards Jiri Palecek Jiri, Thanks for the report. In order to help me narrow this down are you able to provide a simple test case to reproduce the problem? I don't know if it's simple, but here goes. In an empty directory: $ touch CMakeLists.txt $ cmake . $ installwatch cmake . The last line crashes on my system. Regards Jiri Palecek
Bug#964458: checkinstall: causes segfault of cmake
Package: checkinstall Version: 1.6.2+git20170426.d24a630-2 Severity: important File: /usr/bin/installwatch Dear Maintainer, while trying to use checkinstall to create a debianized package from a cmake based source, the build failed with a segfault. These are linked to installwatch and don't happen without it: $ installwatch make cmake_check_build_system INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup do paměti (SIGSEGV) (obraz paměti uložen) There is a backtrace of the crash, which indicates it happens early in the initialization of cmake around a stat call: (gdb) bt #0 0x in ?? () #1 0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455 #2 _gnutls_update_system_priorities () at ../../lib/priority.c:1309 #3 0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at ../../lib/global.c:387 #4 0xb6a25950 in lib_init () at ../../lib/global.c:511 #5 0xb7f35f5c in call_init (l=, argc=argc@entry=6, argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72 #6 0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, l=) at dl-init.c:30 #7 _dl_init (main_map=, argc=6, argv=0xbfe33e64, env=0xbfe33e80) at dl-init.c:119 #8 0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2 (gdb) frame 1 #1 0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455 455 return __xstat (_STAT_VER, __path, __statbuf); Why did it end up with EIP=0 I don't know. It seems there's some incompatibility between installwatch's LD_PRELOAD and glibc. Could you have a look at it? Regards Jiri Palecek -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.7.0-1-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages checkinstall depends on: ii dpkg-dev1.20.1~2.gbp7298ec ii file1:5.38-5 ii libc6 2.30-7 ii sensible-utils 0.0.12+nmu1 Versions of packages checkinstall recommends: ii make 4.3-4 Versions of packages checkinstall suggests: ii gettext 0.19.8.1-9 -- no debconf information
Bug#962241: texlive-lang-czechslovak: depends on all other European language packs
On 05. 06. 20 11:01, Hilmar Preuße wrote: Am 05.06.2020 um 01:58 teilte Jiri Palecek mit: Hi, Hello the texlive-lang-czechslovak depends on all other European texlive-lang-xxx packages, like English, German, French, etc. This makes the overall size of packages brought by it up to several hundreds MB. I'm not quite sure why that would be necessary, as it is the only language pack that has this property. Please check that the dependencies there are absolutely needed. We had to introduce it, to solve another issue: #928805 . Cor, that's awful. Can't it be conditionally disabled somehow? Does it even work, when it loads hyphenation patterns for languages I don't even know exist, let alone speak them? Can't it interfere with the patterns for Czech? Regards Jiri Palecek
Bug#962241: texlive-lang-czechslovak: depends on all other European language packs
Version: 2020.20200522-1 Severity: minor Package: texlive-lang-czechslovak Hello, the texlive-lang-czechslovak depends on all other European texlive-lang-xxx packages, like English, German, French, etc. This makes the overall size of packages brought by it up to several hundreds MB. I'm not quite sure why that would be necessary, as it is the only language pack that has this property. Please check that the dependencies there are absolutely needed. Regards Jiri Palecek
Bug#962240: texlive-lang-czechoslovak: depends on all other european language packs
Version: 2020.20200522-1 Severity: minor Package: texlive-lang-czechoslovak Hello, the texlive-lang-czechoslovak depends on all other European texlive-lang-xxx packages, like English, German, French, etc. This makes the overall size of packages brought by it up to several hundreds MB. I'm not quite sure why that would be necessary, as it is the only language pack that has this property. Please chack that the dependencies there are absolutely needed. Regards Jiri Palecek
Bug#961558: libkf5xmlgui5: removes KGestureMap, which breaks older kdebugdialog5 (package: libkf5kdelibs4support5-bin)
On 26. 05. 20 15:26, Jiri Palecek wrote: Hello, On 26. 05. 20 9:37, Sandro Knauß wrote: Hey Jiri, please do report such an issue on the package, that breaks and not at the source of the problem, that would gives us automatically the version of libkf5kdelibs4support5-bin. If not always make sure that both versions are included in the bugreport. I expect, that you use the version still on unstable. as the version on experimental runs fine. Yes, that's true, it was 5.62. Sorry about that omission. The Breaks i was suggesting was on linkf5kdelibs4support5 (<<5.69~). It's nice you uploaded a new version, but you picked 5.59 as the breaks version, while 5.62 is surely still affected. Regards Jiri Palecek
Bug#961558: libkf5xmlgui5: removes KGestureMap, which breaks older kdebugdialog5 (package: libkf5kdelibs4support5-bin)
Hello, On 26. 05. 20 9:37, Sandro Knauß wrote: Hey Jiri, please do report such an issue on the package, that breaks and not at the source of the problem, that would gives us automatically the version of libkf5kdelibs4support5-bin. If not always make sure that both versions are included in the bugreport. I expect, that you use the version still on unstable. as the version on experimental runs fine. Yes, that's true, it was 5.62. Sorry about that omission. The Breaks i was suggesting was on linkf5kdelibs4support5 (<<5.69~). Regards Jiri Palecek
Bug#961558: libkf5xmlgui5: removes KGestureMap, which breaks older kdebugdialog5 (package: libkf5kdelibs4support5-bin)
Package: libkf5xmlgui5 Version: 5.69.0-1 Severity: normal Dear Maintainer, after installing this package from experimental, it became impossible to run kdebugdialog5. The error message is: kdebugdialog5: symbol lookup error: /usr/lib/i386-linux-gnu/libKF5KDELibs4Support.so.5: undefined symbol: _ZN11KGestureMap4selfEv Apparently, this was removed by commit 1fa7e40c78627b6c0a456f98b99e3dc9214d5402 (Drop unused broken KGesture support). It would be nice if the new library package included a Breaks: on libkf5kdelibs4support5-bin. Or rather, while looking at it, libkf5kdelibs4support5 since it is used in its code. Regards Jiri Palecek -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.7.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libkf5xmlgui5 depends on: ii libc6 2.30-7 ii libkf5attica5 5.69.0-1 ii libkf5configcore5 5.69.0-1 ii libkf5configgui5 5.69.0-1 ii libkf5configwidgets5 5.69.0-1 ii libkf5coreaddons5 5.69.0-1 ii libkf5globalaccel-bin 5.69.0-1 ii libkf5globalaccel55.69.0-1 ii libkf5i18n5 5.69.0-1 ii libkf5iconthemes5 5.69.0-1 ii libkf5itemviews5 5.69.0-1 ii libkf5widgetsaddons5 5.69.0-2 ii libkf5windowsystem5 5.69.0-1 ii libkf5xmlgui-data 5.69.0-1 ii libqt5core5a [qtbase-abi-5-12-5] 5.12.5+dfsg-10 ii libqt5dbus5 5.12.5+dfsg-10 ii libqt5gui55.12.5+dfsg-10 ii libqt5network55.12.5+dfsg-10 ii libqt5printsupport5 5.12.5+dfsg-10 ii libqt5widgets55.12.5+dfsg-10 ii libqt5xml55.12.5+dfsg-10 ii libstdc++610.1.0-1 Versions of packages libkf5xmlgui5 recommends: pn libkf5xmlgui-bin libkf5xmlgui5 suggests no packages. -- no debconf information
Bug#960735: nvidia-legacy-390xx-kernel-dkms: doesn't compile with linux 5.7
Package: nvidia-legacy-390xx-kernel-dkms
Version: 390.132-4
Severity: normal
Tags: patch
Dear Maintainer,
I was trying to test nvidia drivers with the new kernel in experimental
5.7.0-rc5-686-pae. In the build log, I noticed it failed due to missing
functions set_memory_array_wb and friends. However, the code seemed to
be prepared for that possibility, so the problem must be the conftest.
I checked the output from the compilation checks and found some are
failing for the wrong reason, which causes some functions to be wrongly
detected as present (!) and some wrongly detected as missing. This would
probably apply to the other branches of nvidia drivers as well. I
prepared a patch for this, some comments:
- asm/page.h and asm/pgtable.h are needed for the pgprop_t type. Some
arches have here, some have it there. Otherwise the compilation
wrongly fails and detects the functions as present
- atomic_long_t is pulled by including linux/atomic.h, not
asm/atomic.h. Otherwise it's detected wrongly as absent
- linux/acpi.h is needed for acpi_status type
I checked that these files were present in the linux kernel since
2.6.39, but haven't tested compilation with such old kernels. It should,
however, work.
Please have a look at this.
Regards
Jiri Palecek
Index: nvidia-legacy-390xx-390.132/conftest.sh
===
--- nvidia-legacy-390xx-390.132.orig/conftest.sh
+++ nvidia-legacy-390xx-390.132/conftest.sh
@@ -406,6 +406,8 @@ compile_test() {
# Determine if the set_memory_uc() function is present.
#
CODE="
+#include
+#include
#if defined(NV_ASM_SET_MEMORY_H_PRESENT)
#include
#else
@@ -423,6 +425,8 @@ compile_test() {
# Determine if the set_memory_array_uc() function is present.
#
CODE="
+#include
+#include
#if defined(NV_ASM_SET_MEMORY_H_PRESENT)
#include
#else
@@ -475,6 +479,8 @@ compile_test() {
# Determine if the set_pages_uc() function is present.
#
CODE="
+#include
+#include
#if defined(NV_ASM_SET_MEMORY_H_PRESENT)
#include
#else
@@ -1837,7 +1843,7 @@ compile_test() {
# Determine if atomic_long_t and associated functions are defined
# Added in 2.6.16 2006-01-06 d3cb487149bd706aa6aeb02042332a450978dc1c
CODE="
-#include
+#include
void conftest_atomic_long(void) {
atomic_long_t data;
atomic_long_read();
@@ -1851,7 +1857,7 @@ compile_test() {
atomic64_type)
# Determine if atomic64_t and associated functions are defined
CODE="
-#include
+#include
void conftest_atomic64(void) {
atomic64_t data;
atomic64_read();
@@ -3485,7 +3491,7 @@ compile_test() {
# 2008-01-25 9ee85241fdaab358dff1d8647f20a478cfa512a1
#
CODE="
-#include
+#include
int conftest_register_acpi_notifier(void) {
return register_acpi_notifier();
}"
-- Package-specific info:
uname -a:
Linux debian 5.5.0-1-686-pae #1 SMP Debian 5.5.13-2 (2020-03-30) i686 GNU/Linux
/proc/version:
Linux version 5.5.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version
9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)
/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module 390.132 Thu Oct 31 23:12:54 PDT
2019
GCC version: gcc version 9.3.0 (Debian 9.3.0-11)
lspci 'display controller [030?]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS
450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: nvidia
Kernel modules: nvidia
dmesg:
Device node permissions:
crw-rw+ 1 root video 226, 0 May 15 18:09 /dev/dri/card0
crw-rw+ 1 root render 226, 128 May 15 18:09 /dev/dri/renderD128
crw-rw-rw- 1 root root 195, 254 May 15 20:07 /dev/nvidia-modeset
crw-rw-rw- 1 root root 195, 0 May 15 20:07 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 May 15 20:07 /dev/nvidiactl
/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 May 15 18:09 pci-:02:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 May 15 18:09 pci-:02:00.0-render -> ../renderD128
video:x:44:
OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 15 Feb 4 18:05 /etc/alter
Bug#960352: perl: crashes from perl in deallocation routines
Package: perl Version: 5.30.0-10 Severity: normal Dear Maintainer, I've discovered several crash dumps made by perl in my /var/crash. However, I cannot debug them further since perl doesn't have debug symbols in Debian. I could try to reproduce it under valgrind, but without debug symbols this would be fruitless. The backtraces are like this: Core was generated by `/usr/bin/perl t/Pool01.t'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00516406 in Perl_op_free () (gdb) bt #0 0x00516406 in Perl_op_free () #1 0x005733bc in Perl_cv_undef_flags () #2 0x00573822 in Perl_cv_undef () #3 0x005df2fa in Perl_sv_clear () #4 0x005dfa9e in Perl_sv_free2 () #5 0x00611e79 in Perl_free_tmps () #6 0x00539c52 in perl_destruct () #7 0xb79bf5ea in ?? () from /usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so #8 0xb79c14ec in ?? () from /usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so #9 0x005d9b98 in Perl_pp_entersub () #10 0x005cfec9 in Perl_runops_standard () #11 0x0053542c in Perl_call_sv () #12 0x00538493 in Perl_call_list () #13 0x00539de2 in perl_destruct () #14 0x005123fe in main () Or this, similar: Core was generated by `/usr/bin/perl t/Pool02.t'. Program terminated with signal SIGABRT, Aborted. #0 0xb7f3cbad in __kernel_vsyscall () (gdb) bt #0 0xb7f3cbad in __kernel_vsyscall () #1 0xb7c278b2 in __libc_signal_restore_set (set=0xbfa36a0c) at ../sysdeps/unix/sysv/linux/internal-signals.h:84 #2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48 #3 0xb7c10309 in __GI_abort () at abort.c:79 #4 0xb7c6aa3c in __libc_message (action=, fmt=) at ../sysdeps/posix/libc_fatal.c:181 #5 0xb7c72b2d in malloc_printerr (str=str@entry=0xb7d7f7bc "munmap_chunk(): invalid pointer") at malloc.c:5339 #6 0xb7c72ddb in munmap_chunk (p=) at malloc.c:2830 #7 0x0051656e in Perl_Slab_Free () #8 0x00517287 in Perl_op_free () #9 0x0051742f in Perl_op_free () #10 0x005743bc in Perl_cv_undef_flags () #11 0x00574822 in Perl_cv_undef () #12 0x005e02fa in Perl_sv_clear () #13 0x005e0a9e in Perl_sv_free2 () #14 0x00612e79 in Perl_free_tmps () #15 0x0053ac52 in perl_destruct () #16 0xb799f5ea in ?? () from /usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so #17 0xb79a14ec in ?? () from /usr/lib/i386-linux-gnu/perl/5.30/auto/threads/threads.so #18 0x005dab98 in Perl_pp_entersub () #19 0x005d0ec9 in Perl_runops_standard () #20 0x0053642c in Perl_call_sv () #21 0x00539493 in Perl_call_list () #22 0x0053ade2 in perl_destruct () #23 0x005133fe in main () Problem is, I'm not 100% sure I can reproduce these crashes. Could you look at this and maybe advise me how to debug it? Regards Jiri Palecek -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages perl depends on: ii dpkg 1.20.1~2.gbp7298ec ii libperl5.305.30.0-10 ii perl-base 5.30.0-10 ii perl-modules-5.30 5.30.0-10 Versions of packages perl recommends: ii netbase 6.1 Versions of packages perl suggests: ii libb-debug-perl 1.26-1 pn liblocale-codes-perl pn libtap-harness-archive-perl ii libterm-readline-gnu-perl1.36-2+b1 ii make 4.2.1-1.3 ii perl-doc 5.30.0-10 -- no debconf information
Bug#956925: dpkg: dpkg-source: should fail before-build if patches can't be applied fully in v3-quilt
Hello,
On 19. 04. 20 23:30, Guillem Jover wrote:
while building some of my packages, I noticed they were built without
patches applied. Further investigation in the code showed that it was
caused by dpkg-source --before-build carrying on silently if the first
patch could't be applied, eg. when the series was partially applied, or
the patch itself was somehow defective. It seems this behaviour was a
legacy from package format 2 and IMHO is totally unneeded with quilt. I
therefore suggest to apply this patch, which I've used for several
months now without problems. It relegates the issue of deciding when to
apply patches to quilt.
Unfortunately that's not possible, as people expect to be able to
build packages w/o having used quilt to apply them, for example when
they store a source with patches applied in a VCS.
OK. I have thought about those other workflows and it should be possible
to support it while maintaining a sane function for people using quilt.
My assumption is that when you have the whole tree in git and do not
store .pc, as is discussed in bug 680155, dpkg should not apply the
patches, therefore never create the .pc directory. This can be used to
distinguish these users to users with .pc metadata tracking applied
patches. Of course the first patch heuristic is imprecise (as 680155
shows), but it's been good enough till now so we can go along with that.
The attached patch just checks that the .pc directory exists and if it
doesn't, applies the heuristic. If it exist, I assume the info in the
.pc directory should be good enough to get applied patches list from.
The patch contains a test that checks if it works under both scenarios
(you need to have quilt installed to test it fully).
Please have a look at it. I have another patch that would make workflow
with quilt a lot easier, this one is merely about not building crippled
packages.
Regards
Jiri Palecek
From 4325fb4becab6745f38b437b37661515f45d12f8 Mon Sep 17 00:00:00 2001
From: =?iso8859-2?q?Ji=F8=ED=20Pale=E8ek?=
Date: Sun, 27 Oct 2019 18:55:06 +0100
Subject: [PATCH 1/4] Don't pass before-build stage when first patch doesn't
apply with format V3-quilt
When the first patch doesn't apply, dpkg-source --before-build
silently continues. This behaviour is meant to allow it to continue
when the patch series has been applied, however, it also makes it
very prone to breakage. Particularly, if your first patch is applied
but the rest isn't (eg. has been applied upstream), or if it is
defective, you are going to get a package built with Debian patches
silently ignored. V2 doesn't offer any such functionality, so IMHO
the cleanest behaviour is to rely on quilt and fail if patches
according to its bookkeeping should be applied but can't.
However, to support the workflows where the package source directory
contains applied patches, but no .pc directory, this patch retains
the old behavior when we lack it.
This patch also contains test for these scenarios.
---
scripts/Dpkg/Source/Package/V3/Quilt.pm | 8 +-
scripts/t/dpkg_source.t | 208 +-
scripts/t/dpkg_source/testsuite_3.1-1.dsc | 19 ++
3 files changed, 223 insertions(+), 12 deletions(-)
create mode 100644 scripts/t/dpkg_source/testsuite_3.1-1.dsc
diff --git a/scripts/Dpkg/Source/Package/V3/Quilt.pm b/scripts/Dpkg/Source/Package/V3/Quilt.pm
index 45237d26a..647a7f018 100644
--- a/scripts/Dpkg/Source/Package/V3/Quilt.pm
+++ b/scripts/Dpkg/Source/Package/V3/Quilt.pm
@@ -235,9 +235,11 @@ sub check_patches_applied {
my $next = $quilt->next();
return if not defined $next;
-my $first_patch = File::Spec->catfile($dir, 'debian', 'patches', $next);
-my $patch_obj = Dpkg::Source::Patch->new(filename => $first_patch);
-return unless $patch_obj->check_apply($dir, fatal_dupes => 1);
+unless (-d $quilt->get_db_dir) {
+my $first_patch = File::Spec->catfile($dir, 'debian', 'patches', $next);
+my $patch_obj = Dpkg::Source::Patch->new(filename => $first_patch);
+return unless $patch_obj->check_apply($dir, fatal_dupes => 1);
+}
$self->apply_patches($dir, usage => 'preparation', verbose => 1);
}
diff --git a/scripts/t/dpkg_source.t b/scripts/t/dpkg_source.t
index a0c343846..424f0627a 100644
--- a/scripts/t/dpkg_source.t
+++ b/scripts/t/dpkg_source.t
@@ -16,12 +16,12 @@
use strict;
use warnings;
-use Test::More tests => 8;
+use Test::More tests => 46;
use Test::Dpkg qw(:paths test_neutralize_checksums);
use File::Spec::Functions qw(rel2abs);
use File::Compare;
-use File::Path qw(make_path);
+use File::Path qw(make_path remove_tree);
use Dpkg::IPC;
use Dpkg::Substvars;
@@ -30,6 +30,9 @@ my $srcdir = rel2abs($ENV{srcdir} || '.');
my $datadir = "$srcdir/t/dpkg_source";
my $tmpdir = test_get_temp_path();
+# because $tmpdir is still the same, clear it not to be distracted by leftovers
+remove_tree glob "$
Bug#959969: firefox: crashes frequently on sites like reuters.com w/o pulseaudio
Package: firefox Version: 76.0-2 Severity: normal Tags: patch Dear Maintainer, as the title says, firefox 76 (and 75) crashes frequently when pages are about to play audio, when pulseaudio is not installed. The exact cause is not really known to me (it's not the actual audio, but dbus connection to rtkit probably, but installing rtkit doesn't fix it...). Anyway, I have reported this upstream and there is a fix available, which is included in firefox 77: https://bugzilla.mozilla.org/show_bug.cgi?id=1633266 Please consider including that fix for firefox 76 too, there was a workaround for 75 which sadly doesn't work for 76. Regards Jiri Palecek -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 4.9.1 ii fontconfig 2.13.1-4 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-4 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-20.110-4 ii libevent-2.1-7 2.1.11-stable-1 ii libffi7 3.3-3 ii libfontconfig1 2.13.1-4 ii libfreetype62.10.1-2 ii libgcc-s1 10-20200418-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-1 ii libglib2.0-02.64.2-1 ii libgtk-3-0 3.24.18-1 ii libnspr42:4.25-1 ii libnss3 2:3.52-1 ii libpango-1.0-0 1.44.7-4 ii libstdc++6 10-20200418-1 ii libvpx6 1.8.2-dmo1 ii libx11-62:1.6.9-2+b1 ii libx11-xcb1 2:1.6.9-2+b1 ii libxcb-shm0 1.14-2 ii libxcb1 1.14-2 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-1 ii libxext62:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1+b3 ii procps 2:3.3.16-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages firefox recommends: ii libavcodec58 10:4.2.2-dmo8 Versions of packages firefox suggests: ii fonts-lmodern 2.004.5-5 ii fonts-stix [otf-stix] 1.1.1-3 ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-5 ii libgtk2.0-02.24.32-4 pn pulseaudio -- no debconf information
Bug#956925: dpkg: dpkg-source: should fail before-build if patches can't be applied fully in v3-quilt
Hi, On 19. 04. 20 23:30, Guillem Jover wrote: Control: ressign -1 libdpkg-perl Control: merge 950142 -1 On Thu, 2020-04-16 at 21:31:21 +0200, Jiri Palecek wrote: Package: dpkg Version: 1.20.0+nmu2~1.gbpcd9614 Severity: normal Tags: patch while building some of my packages, I noticed they were built without patches applied. Further investigation in the code showed that it was caused by dpkg-source --before-build carrying on silently if the first patch could't be applied, eg. when the series was partially applied, or the patch itself was somehow defective. It seems this behaviour was a legacy from package format 2 and IMHO is totally unneeded with quilt. I therefore suggest to apply this patch, which I've used for several months now without problems. It relegates the issue of deciding when to apply patches to quilt. Unfortunately that's not possible, as people expect to be able to build packages w/o having used quilt to apply them, for example when they store a source with patches applied in a VCS. Without a .pc directory, I see. But then it could be special cased based on the existence of the .pc directory - if it doesn't exist, try the first patch, if it does, use quilt metadata, right? Regards Jiri Palecek
Bug#956931: autopkgtest: Build profiles support for autopkgtest
Package: autopkgtest Version: 5.12.2~6.gbp89ad39 Severity: wishlist Dear Maintainer, with the latest and greatest changes in dpkg, I think it would be nice if autopkgtest followed suit. Particularly, it would be advantageous to support running and building tests in autopkgtest under build profiles (esp. nodoc!). This would allow for smaller test footprint, less packages to pull (ie. you don't need texlive on the testbed), and faster building of the packages. I prepared a patch implementing such a change here: https://salsa.debian.org/jpalecek-guest/autopkgtest/-/commit/6275da59305d6e836cb3558f9f442479eb24fc95 The patch is functional, albeit incomplete due to missing documentation. The real issue is the control file format. In my patch, I use an extra stanza to specify build profiles, like this: >>> Build-Profiles: nodoc Tests: run-some-tests <<< I chose this format, because adding the specification to some of the tests would be IMHO misleading: the build profile applies to all of the tests indiscriminately, not to any particular one. Also, I chose to apply them to all @builddep@ dependencies as well. However, there is a problem about this: it makes the control file format non-backwards-compatible. Particularly, dpkg needs to be patched or it will croak on packages with such d/t/control. Maybe, some artificial Tests: line like Tests: * could be added? That would make the change backwards compatible. Dpkg still needs to be patched, but the change would be rather minimal. What do you think about this proposal? Please comment here or on salsa. I'm also CC-ing the dpkg developers, since it concerns them. Regards Jiri Palecek -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages autopkgtest depends on: ii apt-utils 2.0.1 ii libdpkg-perl1.20.0+nmu2~1.gbpcd9614 ii procps 2:3.3.16-4 ii python3 3.8.2-2 ii python3-debian 0.1.36 Versions of packages autopkgtest recommends: pn autodep8 Versions of packages autopkgtest suggests: pn lxc pn lxd pn ovmf pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:4.2-2 ii schroot 1.6.10-9 pn vmdb2 -- no debconf information
Bug#956925: dpkg: dpkg-source: should fail before-build if patches can't be applied fully in v3-quilt
Package: dpkg
Version: 1.20.0+nmu2~1.gbpcd9614
Severity: normal
Tags: patch
Dear Maintainer,
while building some of my packages, I noticed they were built without
patches applied. Further investigation in the code showed that it was
caused by dpkg-source --before-build carrying on silently if the first
patch could't be applied, eg. when the series was partially applied, or
the patch itself was somehow defective. It seems this behaviour was a
legacy from package format 2 and IMHO is totally unneeded with quilt. I
therefore suggest to apply this patch, which I've used for several
months now without problems. It relegates the issue of deciding when to
apply patches to quilt.
Regards
Jiri Palecek
From f489217e511c4ed5c78d63fcc7688a630b73bc67 Mon Sep 17 00:00:00 2001
From: =?iso8859-2?q?Ji=F8=ED=20Pale=E8ek?=
Date: Sun, 27 Oct 2019 18:55:06 +0100
Subject: [PATCH] Don't pass before-build stage when first patch doesn't apply
with format V3-quilt
When the first patch doesn't apply, dpkg-source --before-build
silently continues. This behaviour is meant to allow it to continue
when the patch series has been applied, however, it also makes it
very prone to breakage. Particularly, if your first patch is applied
but the rest isn't (eg. has been applied upstream), or if it is
defective, you are going to get a package built with Debian patches
silently ignored. Quilt will safely apply all the patches, even if
some of them are already applied, and fail correctly when the patches
are defective. V2 doesn't offer any such functionality, so IMHO the
cleanest behaviour is to rely on quilt and fail if patches according
to its bookkeeping should be applied but can't.
---
scripts/Dpkg/Source/Package/V3/Quilt.pm | 4
1 file changed, 4 deletions(-)
diff --git a/scripts/Dpkg/Source/Package/V3/Quilt.pm b/scripts/Dpkg/Source/Package/V3/Quilt.pm
index 45237d26a..25c5aab1b 100644
--- a/scripts/Dpkg/Source/Package/V3/Quilt.pm
+++ b/scripts/Dpkg/Source/Package/V3/Quilt.pm
@@ -235,10 +235,6 @@ sub check_patches_applied {
my $next = $quilt->next();
return if not defined $next;
-my $first_patch = File::Spec->catfile($dir, 'debian', 'patches', $next);
-my $patch_obj = Dpkg::Source::Patch->new(filename => $first_patch);
-return unless $patch_obj->check_apply($dir, fatal_dupes => 1);
-
$self->apply_patches($dir, usage => 'preparation', verbose => 1);
}
--
2.25.1
-- Package-specific info:
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Foreign Architectures: amd64
Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dpkg depends on:
ii libbz2-1.0 1.0.8-2
ii libc62.30-4
ii liblzma5 5.2.4-1+b1
ii libselinux1 3.0-1+b1
ii tar 1.30+dfsg-6
ii zlib1g 1:1.2.11.dfsg-2
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt2.0.1
pn debsig-verify
-- no debconf information
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi On 30. 03. 20 16:14, Felix Lechner wrote: Thanks for being persistent. It made my work a lot easier. I totally agree with you. I will remove the xdeb check in the near future. That's nice to hear! Thank you. I will only keep the test, which is slightly different from t/tags/checks/binaries/binaries-from-other-arch. It actually builds a cross-binary, even if the arch-dependent build prerequisite is not in d/control (so our Gitlab CI is not burdened all the time). https://salsa.debian.org/lintian/lintian/-/blob/40a028318ae647034ac35f900c119f922ca1b638/data/binaries/arch-regex That table was apparently imported from xdeb at some point. Yeah and it's (slightly?) wrong in using of the negative assertions. Maybe another time. Have a nice day Jiri Palecek
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi, On 29. 03. 20 18:53, Felix Lechner wrote: positives. Your issue should be fixed on all architectures (or at least I hope) with this commit: https://salsa.debian.org/lintian/lintian/-/commit/53fd192e6cc0f2cd6028f659ae1c30888bf94872 The issues surrounding multilib and cross building tools remain. Keeping the bug open. That's good; however, I'd like to know why is that tag even needed in lintian, and if removing that altogether wouldn't be the best course of action. Especially given that lintian already has a tag for the very same check, but with some multilib issues solved and more: https://salsa.debian.org/lintian/lintian/-/blob/40a028318ae647034ac35f900c119f922ca1b638/data/binaries/arch-regex https://salsa.debian.org/lintian/lintian/-/blob/master/checks/binaries.pm#L405 Maybe if you're concerned about some particular false negative of|binary-from-other-architecture|, you could work with that. Regards Jiri Palecek
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
On Wed, 25 Mar 2020 07:11:02 -0700 Felix Lechner wrote:
> Hi,
Hello,
>
> On Sat, Mar 21, 2020 at 4:51 AM Matthias Klose wrote:
> >
> > I don't know when that was introduced, but you see some hundred of
those in the
> > gcc-N packages:
>
> The tag was introduced when the sole Lintian check provided by the
> xdeb package became part of Lintian. Given recent changes, it was too
> cumbersome to keep filing bug reports [1] and merge requests [2] for
> dependent packages. The relevant commit was:
>
>
https://salsa.debian.org/lintian/lintian/-/commit/25013ff8173883796e00f4bc58a89f2a09839727
>
This is the problem:
$self->tag('binary-is-wrong-architecture', $file)
if ( $architecture =~ /^arm[el|hf]$/
&& $file->file_info !~ /ARM,(?: EABI5)? version 1 \(SYSV\)/)
|| ( $architecture eq 'i386'
&& $file->file_info !~ /x86-64, version 1 \(SYSV\)/)
If architecture is i386 (OK, mine is), but file info DOESN'T indicate
x86-64 (yes, 386 binaries don't), we tag the package. That can't be
right; I don't want x86-64 files on a 386 system. And I want 386
binaries instead. Please fix that.
As an aside, why is that test even necessary? The next line (... !~
$pattern) should work fine for i386.
Regards
Jiri Palecek
Bug#954207: getting gtk3 warnings of glib version too old after update
Hi On 18. 03. 20 19:23, Changwoo Ryu wrote: (gedit:255189): Gtk-WARNING **: 19:47:32.240: GModule (/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch) I don't see this warning message. This happens when your glib version is older than the version which ibus-gtk3 was built with. It's a typical compatibility check. Could you please look into the above and fix it. I am not sure which glib version to report it too if it pertains to that, whether libglib2.0-0 2.62.5-1 or something else. According to buildd.d.o, ibus-gtk3:amd64 1.5.22-1 has been built with glib 2.64.1-1. It shouldn't print such warning with glib 2.62.5-1. Please make sure if you were really running ibus 1.5.22-1 and glib 2.62.5-1. I got the same problem (on i386) and I can confirm it printed the warning with ibus-gtk3:i386 (1.5.22-1) and libglib2.0-0 (2.62.5-1). Regards Jiri Palecek
Bug#953401: libqt5dbus5: crash on exit due to use-after-free of a QSocketNotifier
Package: libqt5dbus5 Version: 5.12.5+dfsg-9 Severity: normal Dear Maintainer, while debugging another crash with valgrind, I noticed errors of invalid access in the thread used by QDBus. It seems the event loop is still expecting input on a socket, whose socket notifier should have been deleted and unregistered. Note that this is not directly related to the other crash, or at least I don't know how it could be (if anything, it should cause a deadlock). The backtrace is here: bin7cxjcUT46t.bin Description: Binary data Do you have any ideas why this could be? Regards Jiri Palecek -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqt5dbus5 depends on: ii libc6 2.29-8 ii libdbus-1-3 1.12.16-2 ii libqt5core5a [qtbase-abi-5-12-5] 5.12.5+dfsg-9 ii libstdc++610-20200222-1 libqt5dbus5 recommends no packages. libqt5dbus5 suggests no packages. -- no debconf information
Bug#953281: devscripts: FTBFS with non-English locale
Package: devscripts Version: 2.20.3 Severity: normal Dear Maintainer, by your request I file a bug for FTBFS of devscripts on my (Czech) locale. The particular problem is a test for debuild failing, which expects English output. See: test_debuild ASSERT:standard output of debuild --no-conf --no-lintian --preserve-envvar=PATH --preserve-envvar=PERL5LIB --preserve-envvar=DEBFULLNAME --preserve-envvar=DEBEMAIL --preserve-envvar=GNUPGHOME --set-envvar=NO_PKG_MANGLE=1 -k'uscan test key (no secret) ' matches /mnt/extras/src/devscripts/test/package_lifecycle/debuild.txt\n expected:<0> but was:<1> 19c19 < dpkg-deb: vytvářím balík ,,test" v ,,../test_1.0-1_all.deb". --- > dpkg-deb: building package 'test' in '../test_1.0-1_all.deb'. test_dscverify test_dscextractControl test_dscextractChangelog test_debchange test_list_unreleased test_debuild2 ASSERT:standard output of debuild --no-conf --no-lintian --preserve-envvar=PATH --preserve-envvar=PERL5LIB --preserve-envvar=DEBFULLNAME --preserve-envvar=DEBEMAIL --preserve-envvar=GNUPGHOME --set-envvar=NO_PKG_MANGLE=1 -k'uscan test key (no secret) ' matches /mnt/extras/src/devscripts/test/package_lifecycle/debuild.txt\n expected:<0> but was:<1> 19c19 < dpkg-deb: vytvářím balík ,,test" v ,,../test_1.0-2_all.deb". --- > dpkg-deb: building package 'test' in '../test_1.0-2_all.deb'. The full output is attached: dpkg-buildpackage -us -uc -ui -sa -b dpkg-buildpackage: info: source package devscripts dpkg-buildpackage: info: source version 2.20.3 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Mattia Rizzolo dpkg-source --before-build . dpkg-buildpackage: info: host architecture i386 debian/rules clean dh clean --with python3 dh_auto_clean make -j2 clean make[1]: Vstupuje se do adresáře ,,/mnt/extras/src/devscripts" # Update the POT/POs and remove the translated man pages make -C po4a/ clean make[2]: Vstupuje se do adresáře ,,/mnt/extras/src/devscripts/po4a" # po4a translate and clean need ../doc/devscripts.1, rebuild it make -C ../doc devscripts.1 make[3]: Vstupuje se do adresáře ,,/mnt/extras/src/devscripts/doc" cat devscripts.1.in > devscripts.1.tmp.29122-29121 cat ../README | \ awk '/^- annotate-output/,/^ mailing lists./'|sed -e '/^[[:space:]]*$/d' -e 's/^/ /g' | \ perl genmanpage.pl \ >> devscripts.1.tmp.29122-29121 mv devscripts.1.tmp.29122-29121 devscripts.1 make[3]: Opouští se adresář ,,/mnt/extras/src/devscripts/doc" po4a --previous --rm-translations --no-backups devscripts-po4a.conf (3491 položek) rm -f fr/bts.fr.1 fr/build-rdeps.fr.1 fr/chdist.fr.1 fr/debcheckout.fr.1 fr/debcommit.fr.1 fr/deb-reversion.fr.1 fr/desktop2menu.fr.1 fr/dget.fr.1 fr/mass-bug.fr.1 fr/mk-build-deps.fr.1 fr/mk-origtargz.fr.1 fr/namecheck.fr.1 fr/rmadison.fr.1 fr/sadt.fr.1 fr/svnpath.fr.1 fr/tagpending.fr.1 fr/origtargz.fr.1 fr/transition-check.fr.1 fr/who-permits-upload.fr.1 fr/git-deborig.fr.1 fr/hardening-check.fr.1 de/bts.de.1 de/build-rdeps.de.1 de/chdist.de.1 de/debcheckout.de.1 de/debcommit.de.1 de/deb-reversion.de.1 de/desktop2menu.de.1 de/dget.de.1 de/mass-bug.de.1 de/mk-build-deps.de.1 de/mk-origtargz.de.1 de/namecheck.de.1 de/rmadison.de.1 de/sadt.de.1 de/svnpath.de.1 de/tagpending.de.1 de/origtargz.de.1 de/transition-check.de.1 de/who-permits-upload.de.1 de/git-deborig.de.1 de/hardening-check.de.1 translate rm -rf de fr make[2]: Opouští se adresář ,,/mnt/extras/src/devscripts/po4a" rm -f translated_manpages make -C scripts/ clean make -C doc clean make[2]: Vstupuje se do adresáře ,,/mnt/extras/src/devscripts/doc" make[2]: Vstupuje se do adresáře ,,/mnt/extras/src/devscripts/scripts" rm -f devscripts.1 devscripts.1.tmp.* make[2]: Opouští se adresář ,,/mnt/extras/src/devscripts/doc" python3 setup.py clean -a running clean 'build/lib' does not exist -- can't clean it 'build/bdist.linux-i686' does not exist -- can't clean it 'build/scripts-3.7' does not exist -- can't clean it find -name '*.pyc' -delete find -name __pycache__ -delete rm -rf devscripts.egg-info bash_completion .pylint.d rm -f salsa cvs-debuild checkbashisms transition-check dpkg-depcheck mass-bug build-rdeps rmadison dget dep3changelog debc svnpath debsnap mk-origtargz debuild uscan grep-excuses plotchangelog chdist debpkg who-permits-upload mk-build-deps debchange dscverify namecheck origtargz deb-why-removed bts dd-list debcommit git-deborig tagpending debdiff rc-alert hardening-check debcheckout debi desktop2menu debrebuild who-uploads archpath debclean mergechanges debrepro debrelease dcmd cvs-debrelease whodepends getbuildlog nmudiff debrsign debsign dpkg-genbuilddeps edit-patch list-unreleased dscextract ltnu pts-subscribe wnpp-check uupdate wnpp-alert what-patch annotate-output manpage-alert cowpoke cvs-debi diff2patches deb-reversion salsa.tmp cvs-debuild.tmp checkbashisms.tmp transition-check.tmp dpkg-depcheck.tmp mass-bug.tmp build-rdeps.tmp rmadison.tmp dget.tmp dep3changelog.tmp
Bug#953137: wine-development: wine fails to start, probably due to missing nls files
Package: wine-development Version: 5.2-2 Severity: normal Dear Maintainer, in this version, any attempt of running wine fails, with these error messages: 0009:err:nls:load_unix_cptable failed to load "/usr/lib/wine-development/../../share/wine-development/wine/nls/c_28592.nls" 000b:err:nls:load_unix_cptable failed to load "/usr/lib/wine-development/../../share/wine-development/wine/nls/c_28592.nls" 000b:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 000b:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c005 0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0009:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\start.exe" failed, status c005 It seems the file c_28592.nls is indeed missing from the packaging (and other .nls files as well), although they are built on the buildd. Please include them (and, I suggest you at least review output fo dh_missing). Regards Jiri Palecek -- Package-specific info: /usr/bin/wine points to /usr/bin/wine-development. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wine-development depends on: ii wine32-development 5.2-2 wine-development recommends no packages. Versions of packages wine-development suggests: pn dosbox ii kio-extras 4:19.08.1-1+b1 pn playonlinux pn q4wine ii winbind 2:4.11.5+dfsg-1 pn wine-binfmt ii winetricks 0.0+20190912-1 Versions of packages libwine-development depends on: ii libasound2 1.2.2-2 ii libc62.29-8 ii libfaudio0 19.12-1 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libglib2.0-0 2.62.5-1 ii libgphoto2-6 2.5.22-3 ii libgphoto2-port122.5.22-3 ii libgstreamer-plugins-base1.0-0 1.16.2-2 ii libgstreamer1.0-01.16.2-2 ii liblcms2-2 2.9-3+b1 ii libldap-2.4-22.4.49+dfsg-1 ii libmpg123-0 1.25.13-1 ii libncurses6 6.1+20191019-1 ii libopenal1 1:1.19.1-1+b1 ii libpcap0.8 1.9.1-2 ii libpulse013.0-3 ii libtinfo66.1+20191019-1 ii libudev1 244.3-1 ii libvkd3d11.1-3 ii libx11-6 2:1.6.9-2 ii libxext6 2:1.3.3-1+b2 ii libxml2 2.9.10+dfsg-3 ii ocl-icd-libopencl1 [libopencl1] 2.2.12-2 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages libwine-development recommends: pn fonts-liberation ii fonts-wine 5.0~rc4-1 ii gstreamer1.0-plugins-good 1.16.2-2 pn libasound2-plugins pn libcapi20-3 ii libcups2 2.3.1-7 ii libdbus-1-31.12.16-2 ii libgl1 1.3.1-1 ii libgl1-mesa-dri19.3.3-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgnutls303.6.12-2 ii libgsm11.0.18-2 ii libgssapi-krb5-2 1.17-5 ii libjpeg62-turbo1:1.5.2-2+b1 ii libkrb5-3 1.17-5 ii libodbc1 2.3.6-0.1+b1 ii libosmesa6 19.3.3-1 ii libpng16-161.6.37-1 ii libsane1.0.27-3.2+b1 ii libsdl2-2.0-0 2.0.10+dfsg1-2 ii libtiff5 4.1.0+git191117-2 ii libv4l-0 1.16.3-3 ii libvulkan1 1.1.126.0-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor11:1.2.0-2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.4-1 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii libxslt1.1 1.1.34-3 ii libxxf86vm11:1.1.4-1+b2 Versions of packages libwine-development suggests: ii cups-bsd 2.3.1-7 ii gstreamer1.0-libav 1.16.2-2 ii gstreamer1.0-plugins-bad 1.16.2-2.1 ii gstreamer1.0-plugins-ugly 1.16.2-2 pn ttf-mscorefonts-installer Versions of packages wine32-development depends
Bug#951500: libqt5gui5: crash in QTextEngine after disconnect from the session manager
ol() (this=0x168e3f0, __in_chrg=) at ./protocols/bonjour/bonjourprotocol.cpp:52 #35 0xaad0d55a in BonjourProtocol::~BonjourProtocol() (this=0x168e3f0, __in_chrg=) at ./protocols/bonjour/bonjourprotocol.cpp:52 #36 0xb7dc7ce1 in Kopete::PluginManagerPrivate::~PluginManagerPrivate() (this=0xb7e97e70 , __in_chrg=) at ./libkopete/kopetepluginmanager.cpp:71 #37 0xb7dc7ce1 in Kopete::(anonymous namespace)::Q_QGS__kpmp::Holder::~Holder() (this=0xb7e97e70 , __in_chrg=) at ./libkopete/kopetepluginmanager.cpp:99 #38 0xb5af16c8 in __run_exit_handlers (status=1, listp=0xb5c933fc <__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:108 #39 0xb5af17f1 in __GI_exit (status=1) at exit.c:139 #40 0xb50b4691 in () at /usr/lib/i386-linux-gnu/libICE.so.6 #41 0xb50ba7f4 in _IceRead () at /usr/lib/i386-linux-gnu/libICE.so.6 #42 0xb50be3cf in IceProcessMessages () at /usr/lib/i386-linux-gnu/libICE.so.6 #43 0xb0e62907 in QSmSocketReceiver::socketActivated(int) (this=0x12ad9c0) at qxcbsessionmanager.cpp:331 This isn't a top priority crash, because it occured in reaction to an error anyway, but still, could you have a look at it? Regards Jiri Palecek -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqt5gui5 depends on: ii fontconfig2.13.1-2+b1 ii libc6 2.29-8 ii libdrm2 2.4.100-4 ii libegl1 1.3.0-7 ii libfontconfig12.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgbm1 19.3.3-1 ii libgcc-s1 [libgcc1] 10-20200204-1 ii libgl11.3.0-7 ii libglib2.0-0 2.62.4-2 ii libharfbuzz0b 2.6.4-1 ii libice6 2:1.0.9-2 ii libinput101.15.1-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libmtdev1 1.1.5-1.1 ii libpng16-16 1.6.37-1 ii libqt5core5a [qtbase-abi-5-12-5] 5.12.5+dfsg-8 ii libqt5dbus5 5.12.5+dfsg-8 ii libqt5network55.12.5+dfsg-8 ii libsm62:1.2.3-1 ii libstdc++610-20200204-1 ii libudev1 244.2-1 ii libx11-6 2:1.6.8-1 ii libx11-xcb1 2:1.6.8-1 ii libxcb-glx0 1.13.1-2 ii libxcb-icccm4 0.4.1-1.1 ii libxcb-image0 0.4.0-1+b2 ii libxcb-keysyms1 0.4.0-1+b2 ii libxcb-randr0 1.13.1-2 ii libxcb-render-util0 0.3.9-1+b1 ii libxcb-render01.13.1-2 ii libxcb-shape0 1.13.1-2 ii libxcb-shm0 1.13.1-2 ii libxcb-sync1 1.13.1-2 ii libxcb-xfixes01.13.1-2 ii libxcb-xinerama0 1.13.1-1 ii libxcb-xinput01.13.1-2 ii libxcb-xkb1 1.13.1-2 ii libxcb1 1.13.1-1 ii libxkbcommon-x11-00.10.0-1 ii libxkbcommon0 0.10.0-1 ii libxrender1 1:0.9.10-1 ii zlib1g1:1.2.11.dfsg-1+b1 Versions of packages libqt5gui5 recommends: ii libqt5svg5 5.12.5-2 pn qt5-gtk-platformtheme Versions of packages libqt5gui5 suggests: ii qt5-image-formats-plugins 5.12.5-1 pn qtwayland5 -- no debconf information
Bug#892923: aptitude: After upgrading ncurses, aptitude fails to correctly display dialog windows and align columns
On 16. 10. 19 23:29, Manuel A. Fernandez Montecelo wrote: Hi, Em 16 de out de 2019 às 23:10, Sven Joachim escreveu: Based on the screenshot Jiri sent in his original bug report, I think this is #894315 in konsole and #933053 in ncurses-base. Both have been fixed in the meantime, so I am taking the liberty to close this bug as well. Thanks for chasing, Sven. Unless Jiri has any objection and can reproduce the problem, I am happy with it. Yes, that is correct. In fact I have learned about the konsole problem early and patched it, then forgot about it all. Sorry for the inconvenience. Regards Jiri Palecek
Bug#939761: firefox: firefox is killing processes on my machine on resume from suspend
sysv/linux/poll.c:29
#2 0xb54c8b6b in __GI___poll (fds=0xb172d14c, nfds=1, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:26
#3 0xb7b6bd9d in () at /usr/lib/i386-linux-gnu/libxcb.so.1
#4 0xb7b6df53 in xcb_wait_for_event () at /usr/lib/i386-linux-gnu/libxcb.so.1
#5 0xb18716a3 in () at /usr/lib/i386-linux-gnu/libQt5XcbQpa.so.5
#6 0xb58446b6 in () at /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#7 0xb4caffd2 in start_thread (arg=) at pthread_create.c:486
#8 0xb54d36d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
(gdb) qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 60970,
resource id: 25695180, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 60972, resource
id: 25695180, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 60973, resource
id: 25695180, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 60975, resource
id: 25695180, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 60976, resource
id: 25695180, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 61197, resource
id: 25698435, major code: 3 (GetWindowAttributes), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 61198,
resource id: 25698435, major code: 14 (GetGeometry), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 6986, resource
id: 25698867, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 6988, resource
id: 25698867, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 6991, resource
id: 25698867, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 6993, resource
id: 25698867, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 6994, resource
id: 25698867, major code: 20 (GetProperty), minor code: 0
p $_siginfo
$1 = {
si_signo = 15,
si_errno = 0,
si_code = 0,
_sifields = {
_pad = {10546, 1000, 0 },
_kill = {
si_pid = 10546,
si_uid = 1000
},
_timer = {
si_tid = 10546,
si_overrun = 1000,
si_sigval = {
sival_int = 0,
sival_ptr = 0x0
}
},
_rt = {
si_pid = 10546,
si_uid = 1000,
si_sigval = {
sival_int = 0,
sival_ptr = 0x0
}
},
_sigchld = {
si_pid = 10546,
si_uid = 1000,
si_status = 0,
si_utime = 0,
si_stime = 0
},
_sigfault = {
si_addr = 0x2932,
_addr_lsb = 1000,
_addr_bnd = {
_lower = 0x0,
_upper = 0x0
}
},
_sigpoll = {
si_band = 10546,
si_fd = 1000
}
}
}
As you can see, the signal is originated by pid 10546, which was also
the Parent process of firefox. (firefox could have been started from
plasma on this occasion, I'm not sure)
I don't really like firefox closing itself on resume either, but I can
live with that. After all, without it firefox only displays black
windows and crashes - interestingly chromium also shows garbled display
after resume, but then redisplays everything and all is well. However,
firefox is in no business to kill other processes on the
machine. Therefore I think severity important is warranted.
Regards
Jiri Palecek
-- Package-specific info:
-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled
Name: Ant Video downloader
Location: ${PROFILE_EXTENSIONS}/anttool...@ant.com.xpi
Status: user-disabled
Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled
Name: Clearly
Location: ${PROFILE_EXTENSIONS}/reada...@evernote.com.xpi
Status: app-disabled
Name: ClixAddon
Location: ${PROFILE_EXTENSIONS}/jid1-wkrsk9tpfpr...@jetpack.xpi
Status: enabled
Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Status: user-disabled
Name: Default theme
Location: /usr/lib/firefox/omni.ja
Status: enabled
Name: Dropbox Paper Plus
Location: ${PROFILE_EXTENSIONS}/{bd3f314e-6643-4b24-bc7c-a97035d0a5f4}.xpi
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled
Name: Firefox Monitor
Location: /usr/lib/firefox/browser/features/fxmoni...@mozilla.org.xpi
Status: enabled
Name: Firefox Multi-Account Containers
Location: ${PROFILE_EXTENSIONS}/@testpilot-containers.xpi
Status: enabled
Name: Firefox Pioneer
Location: ${PROFILE_EXTENSIONS}/pioneer-opt...@mozilla.org.xpi
Status: enabled
Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Status: enabled
Name: FocusJUMP
Location: ${PROFILE_EXTENSIONS}/mail...@yahoo.com.xpi
Bug#935031: konsoles started with KDE are black first
Hello, On Fri, 23 Aug 2019 12:51:59 +0200 Martin Steigerwald wrote: > > Since today's update, those konsoles are black. Window titla and Menu > > bar are there but no contents. When I open a new tab using > > Ctrl-Shift-T, the konsole becomes usable. I have created patches fixing this problem. Please have a look at https://salsa.debian.org/qt-kde-team/kde/konsole/merge_requests/2 Regards Jiri Palecek
Bug#934481: darkplaces: nexuiz freezes after a while
Package: darkplaces Version: 0~20180908~beta1-2 Severity: normal Dear Maintainer, after upgrading darkplaces to a new version, nexuiz started freezing after some time (~10 minutes) of playing (it went to more than 10 seconds per frame). Previously it was running just fine. My graphics is GeForce GTS450 with the nvidia binary driver 390.129. Could this be related to the change in renderer, and how can I make it better? Regards Jiri Palecek "You would do well not to imagine profundity," he said. "Anything that seems of momentous occasion should be dwelt upon as though it were of slight note. Conversely, trivialities must be attended to with the greatest of care. Because death is momentous, give it no thought; because victory is important, give it no thought; because the method of achievement and discovery is less momentous than the effect, dwell always upon the method. You will strengthen yourself in this way." -- Jessica Salmonson, "The Swordswoman" glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer, GLX_NV_multisample_coverage, GLX_NV_robustness_video_memory_purge, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 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_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_buffer, GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer, GLX_NV_multisample_coverage, GLX_NV_present_video, GLX_NV_robustness_video_memory_purge, GLX_NV_swap_group, GLX_NV_video_capture, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 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_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer, GLX_NV_multisample_coverage, GLX_NV_robustness_video_memory_purge, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 1024 MB Total available memory: 1024 MB Currently available dedicated video memory: 387 MB OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTS 450/PCIe/SSE2/3DNOW! OpenGL core profile version string: 4.6.0 NVIDIA 390.129 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: GL_AMD_multi_draw_indirect, GL_ARB_ES2_compatibility, GL_ARB_ES3_1_compatibility, GL_ARB_ES3_2_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_color_buffer_float, GL_ARB_compressed_texture_pixel_storage, GL_ARB_compute_shader, GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, GL_ARB_debug_output, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_derivative_control,
Bug#933960: qtbase-opensource-src: .tag files do not belong into doc packages
On Mon, 05 Aug 2019 11:45:54 -0300 =?utf-8?q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= wrote: > Source: qtbase-opensource-src > Version: 5.11.3+dfsg1-2 > Severity: normal > > Jonathan Ridell just reported that some KDE packages (and then Scarlett checked > that Qt has the same issue) ship the .tags files within foo-doc packages. Yes. I have reported that about half a year ago as 922707. > It turns out that the .tags files are used for linking docs, thus more of a > development file. Yes. And generated apidocs in debian-built packages are suboptimal because of this. > We need to consider if we have to move this files or not within Qt. If we have > then we might tackle the xml files for examples too (see #933597). This change is already commited in the Salsa repository. BTW the other culprits in this business are: libkf5activities-doc libkf5activitiesstats-doc libkf5archive-doc libkf5attica-doc libkf5auth-doc libkf5baloo-doc libkf5bluezqt-doc libkf5bookmarks-doc libkf5codecs-doc libkf5completion-doc libkf5config-doc libkf5configwidgets-doc libkf5coreaddons-doc libkf5crash-doc libkf5dbusaddons-doc libkf5declarative-doc libkf5dnssd-doc libkf5emoticons-doc libkf5filemetadata-doc libkf5globalaccel-doc libkf5guiaddons-doc libkf5holidays-doc libkf5iconthemes-doc libkf5idletime-doc libkf5itemmodels-doc libkf5itemviews-doc libkf5i18n-doc libkf5jobwidgets-doc libkf5kcmutils-doc libkf5kio-doc libkf5kirigami2-doc libkf5modemmanagerqt-doc libkf5networkmanagerqt-doc libkf5newstuff-doc libkf5notifications-doc libkf5notifyconfig-doc libkf5package-doc libkf5parts-doc libkf5people-doc libkf5plasma-doc libkf5plotting-doc libkf5prison-doc libkf5pty-doc libkf5runner-doc libkf5service-doc libkf5solid-doc libkf5sonnet-doc libkf5su-doc libkf5syntaxhighlighting-doc libkf5texteditor-doc libkf5textwidgets-doc libkf5threadweaver-doc libkf5unitconversion-doc libkf5wallet-doc libkf5wayland-doc libkf5widgetsaddons-doc libkf5windowsystem-doc libkf5xmlgui-doc libkf5xmlrpcclient-doc qtbase5-doc-html qtconnectivity5-doc-html qtdeclarative5-doc-html qtgraphicaleffects5-doc-html qtlocation5-doc-html qtnetworkauth5-doc-html qtquickcontrols2-5-doc-html qtquickcontrols5-doc-html qtsensors5-doc-html qtserialbus5-doc-html qtspeech5-doc-html qtsvg5-doc-html qttools5-doc-html qtwebengine5-doc-html qtwebchannel5-doc-html qtwebkit5-doc-html qtwebsockets5-doc-html qtxmlpatterns5-doc-html qt3d5-doc-html Do we need a separate bug for every one of them? Regards Jiri Palecek
Bug#933380: emacs-common: lisp error loading a html file
Package: emacs-common
Version: 1:26.1+1-3.3
Severity: normal
File: /usr/share/emacs/26.1/lisp/textmodes/css-mode.elc
Dear Maintainer,
when loading a html file, I get this error:
Debugger entered--Lisp error: (void-function apropos-macrop)
(apropos-macrop 'kbd)
(or (apropos-macrop 'kbd) (fboundp 'kbd))
(not (or (apropos-macrop 'kbd) (fboundp 'kbd)))
(if (not (or (apropos-macrop 'kbd) (fboundp 'kbd))) (progn (defalias 'kbd
(cons 'macro (function (lambda (keys) "Convert KEYS to the internal Emacs key
representation.\nKEYS should be a string constant in the format used
for\nsaving keyboard macros (see `insert-kbd-macro')." (read-kbd-macro
keys)))
eval-buffer(# nil
"/usr/share/emacs/site-lisp/css-mode/css-mode.el" nil t) ; Reading at buffer
position 7350
load-with-code-conversion("/usr/share/emacs/site-lisp/css-mode/css-mode.el"
"/usr/share/emacs/site-lisp/css-mode/css-mode.el" nil t)
require(css-mode)
According to this question on stacktowerflow[1], ot's because the
apropos-macrop fuction has been renamed. Plaease can you have a look at
it?
Regards
Jiri Palecek
1: https://stackoverflow.com/questions/20135194/emacs-css-mode-not-loading
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 5.1.0-rc4-bughunt+ (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages emacs-common depends on:
ii emacsen-common 3.0.4
ii install-info6.6.0.dfsg.1-2
Versions of packages emacs-common recommends:
pn emacs-el
Versions of packages emacs-common suggests:
pn emacs-common-non-dfsg
ii ncurses-term 6.1+20181013-1
-- no debconf information
Bug#932133: sandsifter: FTBFS on i386
Package: sandsifter
Version: 1.03-2
Severity: important
Tags: patch
Dear Maintainer,
sandsifter fails to build from source on i386 [1]. It is caused by a
rather naive asm code in the injector, which IIUC (don't take me at my
word) tries to use relocation which simply isn't there for the 8th
argument (the new stack). However, I've written a different assembly
routine, which, albeit not beingthe greatest assembler ever written,
gets the job done reliably (and should compile even with pie).
Please consider including this patch.
Regards
Jiri Palecek
Index: sandsifter-1.03/injector.c
===
--- sandsifter-1.03.orig/injector.c
+++ sandsifter-1.03/injector.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
/* configuration */
@@ -814,28 +815,31 @@ void inject(int insn_size)
[packet]"m"(packet)
);
#else
+ dummy_stack.dummy_stack_lo[0] = (uint64_t)packet;
__asm__ __volatile__ ("\
- mov %[eax], %%eax \n\
- mov %[ebx], %%ebx \n\
- mov %[ecx], %%ecx \n\
- mov %[edx], %%edx \n\
- mov %[esi], %%esi \n\
- mov %[edi], %%edi \n\
- mov %[ebp], %%ebp \n\
- mov %[esp], %%esp \n\
- jmp *%[packet]\n\
+ mov %[dummy_stack], %%esp \n\
+ mov %[inject_state], %%ebp\n\
+ mov %c[eax](%%ebp), %%eax \n\
+ mov %c[ebx](%%ebp), %%ebx \n\
+ mov %c[ecx](%%ebp), %%ecx \n\
+ mov %c[edx](%%ebp), %%edx \n\
+ mov %c[esi](%%ebp), %%esi \n\
+ mov %c[edi](%%ebp), %%edi \n\
+ mov %c[ebp](%%ebp), %%ebp \n\
+ ret\n\
"
:
:
- [eax]"m"(inject_state.eax),
- [ebx]"m"(inject_state.ebx),
- [ecx]"m"(inject_state.ecx),
- [edx]"m"(inject_state.edx),
- [esi]"m"(inject_state.esi),
- [edi]"m"(inject_state.edi),
- [ebp]"m"(inject_state.ebp),
- [esp]"i"(_stack.dummy_stack_lo),
- [packet]"m"(packet)
+ [inject_state]"r"(_state),
+ [eax]"i"(offsetof(state_t, eax)),
+ [ebx]"i"(offsetof(state_t, ebx)),
+ [ecx]"i"(offsetof(state_t, ecx)),
+ [edx]"i"(offsetof(state_t, edx)),
+ [esi]"i"(offsetof(state_t, esi)),
+ [edi]"i"(offsetof(state_t, edi)),
+ [ebp]"i"(offsetof(state_t, ebp)),
+ [dummy_stack]"r"(_stack.dummy_stack_lo),
+ [st_offset]"i"(offsetof(typeof(dummy_stack), dummy_stack_lo))
);
#endif
1:
https://buildd.debian.org/status/fetch.php?pkg=sandsifter=i386=1.03-2=1547570894=0
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 5.1.0-rc4-bughunt+ (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sandsifter depends on:
ii libc62.28-10
ii libcapstone3 4.0.1+really+3.0.5-1
ii python 2.7.16-1
ii python-capstone 4.0.1+really+3.0.5-1
Versions of packages sandsifter recommends:
ii binutils 2.32.51.20190707-1
pn nasm
sandsifter suggests no packages.
-- no debconf information
Bug#931514: thin-provisioning-tools: modules added by initramfs hooks aren't sufficient to activate a cached volume
Package: thin-provisioning-tools Version: 0.7.6-2.1 Severity: normal File: /usr/share/initramfs-tools/hooks/thin-provisioning-tools Dear Maintainer, package thin-provisioning-tools conveniently provides initramfs hooks to add files to initrd allowing to boot from a cached lv. More specifically, this hook contains a line manual_add_modules dm-cache However, this is not sufficient to boot. It fails at boot time saying there's no root filesystem -- vgchange -ay fails with message about a failure to initialize caching policy. The problem is that dm-cache needs to have a dm-cache-smq (or dm-cache-something-else) with it. This module should be added to that line in the hook. Regards Jiri Palecek -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.18.0-3-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thin-provisioning-tools depends on: ii libaio1 0.3.112-3 ii libc6 2.28-10 ii libexpat1 2.2.6-2 ii libgcc1 1:9.1.0-4 ii libstdc++6 9.1.0-4 thin-provisioning-tools recommends no packages. thin-provisioning-tools suggests no packages. -- no debconf information
Bug#930483: devscripts: debuild: please warn about improbable build targets
Package: devscripts Version: 2.19.5 Severity: normal File: /usr/bin/debuild Dear Maintainer, while running gbp buildpackage on a package, the package didn't build with enigmatic output - it said it ran "dh auto check", whcih succeeded and that was all. Subsequently, I discovered it was because I accidentally ran it like this: gbp buildpackage -- -b where I should have done gbp buildpackage -b Gbp invoked debuild and debuild ran "dpkg-buildpackage --rules-target -b" which is obviously wrong. It would be nice if debuild could detect that -b (or anything starting with a dash) is not a likely target and at least warn with a message, or abort. Maybe it could be tightened to only allow known targets (binary, clean, ...), but I'm not sure about that. I think debuild is the right spot to place a warning in this scenario, because it actually interprets the arguments as targets, whereas gbp merely shoves the arguments to the next tool. Regards Jiri Palecek -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- DEBUILD_DPKG_BUILDPACKAGE_OPTS=-sa DEBUILD_PRESERVE_ENVVARS=CC,CXX,DEB_BUILD_OPTIONS -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.18.0-rc6-bughunt+ (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.19.6 ii fakeroot 1.23-1 ii file 1:5.35-4 ii gnupg 2.2.12-1 ii gpgv 2.2.12-1 ii libc6 2.28-10 ii libfile-homedir-perl 1.004-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20180523.0-1 ii libmoo-perl 2.003004-1 ii libwww-perl 6.36-1 ii patchutils0.3.4-2 ii perl 5.28.1-6 ii python3 3.7.3-1 ii sensible-utils0.0.12 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 1.8.2 ii at 3.1.23-1 ii curl7.64.0-3 ii dctrl-tools 2.24-2+b1 pn debian-keyring ii dput1.0.1 ii equivs 2.2.0 ii libdistro-info-perl 0.21 ii libdpkg-perl1.19.6 ii libencode-locale-perl 1.05-1 pn libgit-wrapper-perl pn libgitlab-api-v4-perl pn liblist-compare-perl ii liblwp-protocol-https-perl 6.07-2 ii libsoap-lite-perl 1.27-1 pn libstring-shellquote-perl ii libtry-tiny-perl0.30-1 ii liburi-perl 1.76-1 ii licensecheck3.0.31-2 ii lintian 2.15.0 it man-db 2.8.5-2 ii patch 2.7.6-3 ii python3-apt 1.8.4 ii python3-debian 0.1.35 ii python3-magic 2:0.4.15-1 ii python3-requests2.21.0-1 pn python3-unidiff pn python3-xdg ii strace 4.26-0.2 ii unzip 6.0-23 ii wget1.20.1-1.1 ii xz-utils5.2.4-1 Versions of packages devscripts suggests: pn adequate ii autopkgtest 5.11~1.gbpfc8d61 pn bls-standalone ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii build-essential 12.6 pn check-all-the-things pn cvs-buildpackage ii debhelper 12.1.1 ii devscripts-el 40.3 ii diffoscope108 pn disorderfs ii dose-extra5.0.1-11+b3 pn duck pn faketime pn gnuplot pn how-can-i-help pn libauthen-sasl-perl pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-1 pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3000-2 ii libyaml-syck-perl 1.31-1+b1 ii mozilla-devscripts0.48 ii mutt 1.10.1-2.1 ii openssh-client [ssh-client] 1:7.9p1-10 pn piuparts ii
Bug#920567: bash: dpkg-reconfigure: command not found
On Sun, 27 Jan 2019 09:12:32 +0600 Thulium Equasman wrote: > Package: python3-reportbug > Version: 7.5.1 > Severity: normal > Tags: d-i > > Hi, > I got the message "bash: dpkg-reconfigure: command not found > " when I ran `dpkg-reconfigure fontconfig-config`. I ran this command as root. > I then ran `echo $PATH` and the following appeared > "/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games". I searched for How did you get your root shell? If that was by running "su", what you describe is actually expected. You should use "su -". See https://unix.stackexchange.com/questions/460478/debian-su-and-su-path-differences for more information about that. Regards Jiri Palecek
Bug#930370: debconf: Overriding debconf db with file fails with a message "access to disallowed key Filename in restricted hash"
Package: debconf
Version: 1.5.71
Severity: normal
Dear Maintainer,
while trying to debug some difficulties with unattended package
installation, I came accross an interesting problem. While debconf(7)
says you can use DEBCONF_DB_OVERRIDE like this:
DEBCONF_DB_FALLBACK=File{Filename:/root/config.dat Backup:no}
when trying it actually, i got an error message:
# LC_MESSAGES=C DEBCONF_DEBUG=developer
DEBCONF_DB_OVERRIDE="File{Filename:config2.dat.Lwzkvd}"
DEBIAN_FRONTEND=noninteractive dpkg --auto-deconfigure -i
../linux-*_"$DATE"_*.deb
... blah blah...
Attempt to access disallowed key 'Filename' in a restricted hash at
/usr/share/perl5/Debconf/DbDriver.pm line 35.
It does work, though, without the "Filename:" part. What gives?
Another problem, and the reason I am actually experimentig with this, is
that it actually doesn't work unattended, because it somehow disregards
what is in the config file. ie:
debconf (developer): <-- FSET
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+ seen
false
debconf (developer): --> 0 false
debconf (developer): <-- SUBST
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
modules_base /lib/modules
debconf (developer): --> 0
debconf (developer): <-- SUBST
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
package linux-image-4.19.36-bughunt+
debconf (developer): --> 0
debconf (developer): <-- INPUT critical
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
debconf (developer): --> 30 question skipped
debconf (developer): <-- GO
debconf (developer): --> 0 ok
debconf (developer): <-- GET
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
debconf (developer): --> 0 true
I need false on the last line, but still get true (the
default). However, the config2.dat contains
Name: linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
Template:
linux-image-4.19.36-bughunt+/preinst/overwriting-modules-4.19.36-bughunt+
Value: false
Maybe you could help me with that.
Regards
Jiri Palecek
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.19.36-bughunt+ (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages debconf depends on:
ii perl-base 5.28.1-6
Versions of packages debconf recommends:
ii apt-utils 1.8.2
ii debconf-i18n 1.5.71
Versions of packages debconf suggests:
ii debconf-doc1.5.71
pn debconf-kde-helper
ii debconf-utils 1.5.71
ii dialog 1.3-20190211-1
pn libgtk3-perl
pn libnet-ldap-perl
ii libterm-readline-gnu-perl 1.36-1
ii perl 5.28.1-6
ii whiptail 0.52.20-4
-- debconf information:
debconf-apt-progress/preparing:
debconf-apt-progress/media-change:
debconf-apt-progress/info:
* debconf/frontend: Dialog
debconf-apt-progress/title:
* debconf/priority: low
Bug#927149: ltrace: ltrace reports wrong syscall arguments on i386
On 15. 04. 19 17:29, Jiri Palecek wrote:
So I prepared a patch that would use the existing 64bit functions to
obtain syscall arguments on 32bit too.
On review, I found a typo in the patch. Sorry for that. The revised
version is attached.
Refards
Jiri Palecek
Index: ltrace-0.7.3/sysdeps/linux-gnu/x86/fetch.c
===
--- ltrace-0.7.3.orig/sysdeps/linux-gnu/x86/fetch.c
+++ ltrace-0.7.3/sysdeps/linux-gnu/x86/fetch.c
@@ -53,6 +53,12 @@ enum reg_pool {
POOL_RETVAL,
};
+enum syscall_flavor {
+ SYSCALL_INT80,
+ SYSCALL_SYSCALL,
+ SYSCALL_SYSENTER,
+};
+
struct fetch_context
{
struct user_regs_struct iregs;
@@ -74,6 +80,8 @@ struct fetch_context
struct value retval;
} ix86;
} u;
+ enum syscall_flavor syscall_flavor;
+ int target_machine;
};
#ifndef __x86_64__
@@ -208,6 +216,39 @@ allocate_x87(struct fetch_context *conte
return CLASS_X87;
}
+/*
+ * This is to guess which syscall entry point to the 32bit kernel was
+ * used. See arch/x86/entry/entry*.S and
+ * arch/x86/entry/vdso/vdso32/system_call.S
+ *
+ * The information is then used in allocate_integer to find the
+ * arguments in the correct register. This function isn't perfect, but
+ * should work in the majority of cases (vdso and direct-coded int 80)
+ */
+static enum syscall_flavor
+get_syscall_flavor(struct Process* proc, struct fetch_context *context)
+{
+ char data[4];
+#ifdef __x86_64__
+ if (umovebytes(proc, (char*)context->iregs.rip-4, data, 4) != 4) {
+#else
+ if (umovebytes(proc, (char*)context->iregs.eip-4, data, 4) != 4) {
+#endif
+ fprintf(stderr, "Couldn't read code to detect syscall instructions\n");
+ return SYSCALL_INT80;
+ }
+ if (memcmp (data, "\x0f\x34\xcd\x80", 4) == 0)
+ return SYSCALL_SYSENTER;
+ else if (memcmp (data, "\x0f\x05\xcd\x80", 4) == 0)
+ return SYSCALL_SYSCALL;
+ else if (memcmp (data+2, "\xcd\x80", 2) == 0)
+ return SYSCALL_INT80;
+ else {
+ fprintf (stderr, "Couldn't match known syscall instruction\n");
+ return SYSCALL_INT80; /* fallback */
+ }
+}
+
static enum arg_class
allocate_integer(struct fetch_context *context, struct value *valuep,
size_t sz, size_t offset, enum reg_pool pool)
@@ -238,20 +279,66 @@ allocate_integer(struct fetch_context *c
case POOL_SYSCALL:
#ifdef __x86_64__
+ if (context->target_machine == EM_X86_64)
+ switch (context->ireg) {
+HANDLE(0, rdi);
+HANDLE(1, rsi);
+HANDLE(2, rdx);
+HANDLE(3, r10);
+HANDLE(4, r8);
+HANDLE(5, r9);
+ default:
+assert(!"More than six syscall arguments???");
+abort();
+ }
+#endif
+
+ /* Common name for the registers */
+#ifndef __x86_64__
+#define rbx ebx
+#define rbp ebp
+#define rcx ecx
+#define rdx edx
+#define rsi esi
+#define rdi edi
+#define rbp ebp
+#endif
+
switch (context->ireg) {
- HANDLE(0, rdi);
- HANDLE(1, rsi);
+ HANDLE(0, rbx);
+ case 1:
+ if (context->syscall_flavor == SYSCALL_SYSCALL)
+copy_int_register(context, valuep,
+ context->iregs.rbp, offset);
+ else
+copy_int_register(context, valuep,
+ context->iregs.rcx, offset);
+ return CLASS_INTEGER;
+
HANDLE(2, rdx);
- HANDLE(3, r10);
- HANDLE(4, r8);
- HANDLE(5, r9);
+ HANDLE(3, rsi);
+ HANDLE(4, rdi);
+ case 5:
+ if (context->syscall_flavor == SYSCALL_INT80) {
+copy_int_register(context, valuep,
+ context->iregs.rbp, offset);
+return CLASS_INTEGER;
+ }
+ allocate_stack_slot(context, valuep, sz, offset, 4);
+ return CLASS_MEMORY;
+
default:
assert(!"More than six syscall arguments???");
abort();
}
-#else
- i386_unreachable();
-#endif
+ /* End of common code, undefine common register names */
+#undef rbx
+#undef rbp
+#undef rcx
+#undef rdx
+#undef rsi
+#undef rdi
+#undef rbp
case POOL_RETVAL:
switch (context->ireg) {
@@ -668,6 +755,9 @@ arch_fetch_arg_init_32(struct fetch_cont
value_init_detached(retval, NULL, NULL, 0);
}
+ if (type == LT_TOF_SYSCALLR || type == LT_TOF_SYSCALL)
+ context->syscall_flavor = get_syscall_flavor(proc, context);
+
return context;
}
@@ -713,6 +803,7 @@ arch_fetch_arg_init(enum tof type, struc
return NULL;
}
+ ctx->target_machine = proc->e_machine;
struct fetch_context *ret;
if (proc->e_machine == EM_386)
ret = arch_fetch_arg_init_32(ctx, type, proc, ret_info);
@@ -811,13 +902,13 @@ arch_fetch_arg_next(struct fetch_context
struct Process *proc, struct arg_type_info *info,
struct value *valuep)
{
- if (proc->e_machine == EM_386)
- return arch_fetch_arg_next_32(context, type, proc,
- info, valuep);
-
switch (type) {
case LT_TOF_FUNCTION:
case LT_TOF_FUNCTIONR:
+ if (proc->e_machine == EM_386)
+ return arch_fetch_arg_next_32(context, type, proc,
+ info, valuep);
+
return arch_fetch_pool_arg_next(context, type, proc,
info, valuep, POOL_FUNCALL);
Bug#927149: ltrace: ltrace reports wrong syscall arguments on i386
ndef rcx
+#undef rdx
+#undef rsi
+#undef rdi
+#undef rbp
case POOL_RETVAL:
switch (context->ireg) {
@@ -668,6 +755,9 @@ arch_fetch_arg_init_32(struct fetch_cont
value_init_detached(retval, NULL, NULL, 0);
}
+ if (type == LT_TOF_SYSCALLR || type == LT_TOF_SYSCALL)
+ context->syscall_flavor = get_syscall_flavor(proc, context);
+
return context;
}
@@ -713,6 +803,7 @@ arch_fetch_arg_init(enum tof type, struc
return NULL;
}
+ ctx->target_machine = proc->e_machine;
struct fetch_context *ret;
if (proc->e_machine == EM_386)
ret = arch_fetch_arg_init_32(ctx, type, proc, ret_info);
@@ -811,13 +902,13 @@ arch_fetch_arg_next(struct fetch_context
struct Process *proc, struct arg_type_info *info,
struct value *valuep)
{
- if (proc->e_machine == EM_386)
- return arch_fetch_arg_next_32(context, type, proc,
- info, valuep);
-
switch (type) {
case LT_TOF_FUNCTION:
case LT_TOF_FUNCTIONR:
+ if (proc->e_machine == EM_386)
+ return arch_fetch_arg_next_32(context, type, proc,
+ info, valuep);
+
return arch_fetch_pool_arg_next(context, type, proc,
info, valuep, POOL_FUNCALL);
With this patch, I get sane syscall arguments again. However, I'm still
thinking of improving it by caching the result of get_syscall_flavor so
ltrace would avoid a ptrace call on every syscall, provided the
syscalls all originate on a single address (usually).
Moreover, this patch needs testing on an amd64 system with 32bit
binary. I'v only tested on 32bit.
Please, have a look at it and tell me what you think.
Regards
Jiri Palecek
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 5.0.0-trunk-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ltrace depends on:
ii libc62.28-6
ii libelf1 0.176-1
ii libselinux1 2.8-1+b1
ltrace recommends no packages.
ltrace suggests no packages.
-- no debconf information
Bug#860066: ltrace: Doesn't work on some binaries
On Mon, 10 Apr 2017 22:29:49 -0400 Matthew Gabeler-Lee wrote:
> Package: ltrace
> Version: 0.7.3-6+b1
> Severity: normal
>
> ltrace -f ls: crapton of output
> ltrace -f irw: nothing
I can't see the behaviour you are describing. I installed lirc (btw its
daemon crashes on startup, so the package couldn't be configured :-():
jirka@debian:/mnt/extras/src/youtube-dl$ ltrace -f irw
[pid 1414] __libc_start_main(0x4aa160, 1, 0xbf933b34, 0x4aa590
[pid 1414] sigfillset(~<31>)
= 0
[pid 1414] sigaction(SIGUSR1, { 0x4aa570, ~<31>, 0xfffe, 0x }, nil)
= 0
[pid 1414] getopt_long(1, 0xbf933b34, "hv", 0x4ad020, nil)
=
-1
[pid 1414] socket(1, 1, 0)
= 3
[pid 1414] connect(3, 0xbf9338f2, 110, 0xbf9338b0)
= -1
[pid 1414] perrorf(0x4ab05b, 0xbf9338f4, 0, 0Cannot connect to socket
/run/lirc/lircd: No such file or directory
)
= 0
[pid 1414] __errno_location()
= 0xb79e0774
[pid 1414] exit(2
[pid 1414] +++ exited (status 2) +++
However, you can get more output when specifying you want to trace all
calls not only from the executable, but from the libraries as well (cf.
man ltrace):
jirka@debian:/mnt/extras/src/youtube-dl$ ltrace -f -e '*' irw
[pid 1418] irw->__libc_start_main(0x429160, 1, 0xbfefbe24, 0x429590
[pid 1418] irw->sigfillset(~<31>)
= 0
[pid 1418] irw->sigaction(SIGUSR1, { 0x429570, ~<31>, 0xfffe, 0x },
nil)
= 0
[pid 1418] irw->getopt_long(1, 0xbfefbe24, "hv", 0x42c020, nil)
= -1
[pid 1418] irw->socket(1, 1, 0)
= 3
[pid 1418] irw->connect(3, 0xbfefbbe2, 110, 0xbfefbba0)
= -1
[pid 1418] irw->perrorf(0x42a05b, 0xbfefbbe4, 0, 0
[pid 1418] liblirc.so.0->__vsnprintf_chk(0xbfefbaac, 256, 1, 256)
= 40
[pid 1418] liblirc.so.0->perror("Cannot connect to socket /run/li"...Cannot
connect to socket /run/lirc/lircd: No such file or directory
)
=
[pid 1418] <... perrorf resumed> )
= 0
[pid 1418] irw->__errno_location()
= 0xb7a42774
[pid 1418] irw->exit(2
[pid 1418] libstdc++.so.6->_ZNSt3_V214error_categoryD2Ev(0xb7d0dde0, 0, 2,
0xb7f191f8)
= 0xb7d0dde0
[pid 1418] libstdc++.so.6->_ZNSt3_V214error_categoryD2Ev(0xb7d0dde4, 0, 2,
0xb7f191f8)
= 0xb7d0dde4
[pid 1418] libstdc++.so.6->_ZNSt3_V214error_categoryD2Ev(0xb7d0ddd8, 0, 2,
0xb7f191f8)
= 0xb7d0ddd8
[pid 1418] libstdc++.so.6->_ZNSt14error_categoryD2Ev(0xb7d0de04, 0, 2,
0xb7f191f8)
= 0xb7d0de04
[pid 1418] libstdc++.so.6->_ZNSt14error_categoryD2Ev(0xb7d0de08, 0, 2,
0xb7f191f8)
= 0xb7d0de08
[pid 1418] +++ exited (status 2) +++
Hope that helps. I suggest this bug is closed.
Regards
Jiri Palecek
Bug#922554: network-manager: NetworkManager continuously spinning, probably while checking for connectivity
Hello, On 26. 02. 19 19:26, Michael Biebl wrote: Control: tags -1 + moreinfo Do you have network-manager-config-connectivity-debian installed oh yeah Is the server reachable for the connectivity check reachable? I think so. At least I can't see any connectivity problems. Regards Jiri Palecek
Bug#922707: qtbase5-doc-html: please consider packaging doxygen .tags files with -dev package, not -doc
Package: qtbase5-doc-html Version: 5.11.3+dfsg-2 Severity: wishlist Dear Maintainer, qtbase5-doc-html ships the qtcore.tags and other doxygen tags files. These files are only needed for building documentation of Qt-depending software, not for reading the documentation. When these files are not present, documentation of such software still builds, but may be suboptimal since the links to qt library docs won't work. This happens silently and can be seen in the logs having lines like: No such target Qt5Network_QCH defined when calling ecm_add_qch(), ignored. For an example, see https://buildd.debian.org/status/fetch.php?pkg=kdnssd-kf5=i386=5.54.0-1=1547782120=0 I think it would be much more convenient if those files were shipped in -dev packages, not -doc packages (in this case qtbase5-dev). Software depending on qt naturally build-depends on qtbase5-dev, not on -doc which would be needed in that case. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.20.0-trunk-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#922554: network-manager: NetworkManager continuously spinning, probably while checking for connectivity
Package: network-manager
Version: 1.14.4-4
Severity: normal
Dear Maintainer,
I've noticed network manager is consuming most of the cpu time on my
system. It seems to be caused by the connectivity checking code. The
symptoms are:
1. ltrace shows this repeating on and on:
exe->epoll_wait(15, 0xbfb0bba0, 1, 0)
= 0
exe->clock_gettime(0, 0xbfb0bb54, 1, 15)
= 0
exe->clock_gettime(1, 0xbfb0bb54, 1, 15)
= 0
exe->clock_gettime(7, 0xbfb0bb54, 1, 15)
= 0
exe->g_object_ref(0x15c1b58, 0x15adf20, 0x15a84b0, 0xb7a5acc6)
= 0x15c1b58
exe->g_io_channel_unix_get_fd(0x1629fb0, 0x15adf20, 0x15a84b0, 0xb7a5acc6)
= 20
exe->curl_multi_socket_action(0x15c4900, 20, 2, 0xbfb0bd88)
= 0
exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88)
= 0
exe->g_object_ref(0x15c1b58, 0x1612440, 0x1640dc0, 0xb7a5acc6)
= 0x15c1b58
exe->g_io_channel_unix_get_fd(0x15e32b0, 0x1612440, 0x1640dc0, 0xb7a5acc6)
= 22
exe->curl_multi_socket_action(0x15c4900, 22, 2, 0xbfb0bd88)
= 0
exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88)
= 0
exe->g_object_ref(0x15c1b58, 0, 0x1654880, 0xb7a5acc6)
= 0x15c1b58
exe->g_io_channel_unix_get_fd(0x1627080, 0, 0x1654880, 0xb7a5acc6)
= 24
exe->curl_multi_socket_action(0x15c4900, 24, 2, 0xbfb0bd88)
= 0
exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88)
= 0
2. strace only shows incrementing and decrementing an eventfd, no
network activity or something.
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14,
events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=17,
events=POLLIN}, {fd=20, events=POLLOUT}, {fd=22, events=POLLOUT}, {fd=24,
events=POLLOUT}], 12, 0) = 4 ([{fd=3, revents=POLLIN}, {fd=20,
revents=POLLOUT}, {fd=22, revents=POLLOUT}, {fd=24, revents=POLLOUT}])
read(3, "\6\0\0\0\0\0\0\0", 16) = 8
epoll_wait(15, [], 1, 0)= 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=124345, tv_nsec=994550347}) = 0
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
Note: fd 22 is
NetworkMa 20906 root 20u IPv42035553 0t0 TCP
debian:45852->senfter.debian.org:http (ESTABLISHED)
However the event loop doesn't seem to touch the connection in any
way. fds 20 and 24 are similar connections.
Do you have any ideas about this? I'm not very knowledgeable about curl,
but surely it shouldn't hog the glib main loop like that?
Regards
Jiri Palecek
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.19.0-3-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=IS
Bug#921404: gdb: can't debug kdesu (cannot find user-level thread ...)
Package: gdb Version: 8.0-1 Severity: normal Dear Maintainer, I have problems debugging kdesu with gdb. Debugging fails with this message: $ gdb /usr/lib/i386-linux-gnu/libexec/kf5/kdesu GNU gdb (Debian 8.1-4+b1) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/i386-linux-gnu/libexec/kf5/kdesu...Reading symbols from /usr/lib/debug/.build-id/d8/59440907cb9b64a346797293b75d544beba51c.debug...done. done. (gdb) break SuProcess::exec Breakpoint 1 at 0x4540 (gdb) run ls Starting program: /usr/lib/i386-linux-gnu/libexec/kf5/kdesu ls [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Cannot find user-level thread for LWP 7254: generic error I have tried googling for some solutions, but found nothing that turned out to be of value. Also, all reports of similar problems turned out to be rather old. Please note that kdesu is normal program, not suid or something. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.20.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdb depends on: pn libbabeltrace-ctf1 ii libbabeltrace1 1.5.6-1 ii libc6 2.28-4 ii libexpat1 2.2.6-1 ii liblzma55.2.2-1.3 pn libncurses5 pn libpython3.5 ii libreadline77.0-5 pn libtinfo5 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gdb recommends: ii libc6-dbg [libc-dbg] 2.28-4 Versions of packages gdb suggests: ii gdb-doc8.2-1 pn gdbserver
Bug#920962: aptitude: couldn't install both gcc-8-base:i386 and :amd64
Package: aptitude Version: 0.8.11-6 Severity: normal Dear Maintainer, I was installing a clean (buster) system from amd64 archive, but also wanted to install wine32. However, this package only exists in i386 so I added the architecture and selected wine32 in aptitude. However, it didn't allow me to continue and the resolver couldn't find any resolution. Upon investigation, the situation was like this: - the conflict was around gcc-8-base - gcc-8-base:amd64 was out of date and needed to be upgraded - gcc-8-base breaks gcc-8-base of any other version - this constraint was making the resolver unhappy, and even upgrading gcc-8-base:amd64 to the same version as newly installed gcc-8-base:i386 didn't flag this dependency as satisfied (ie. there was still conflict) Installing the package with "apt install wine32" wen't without any problems. Regards Jiri Palecek -- Package-specific info: Terminal: eterm-color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.11 Compiler: g++ 8.2.0 Compiled against: apt version 5.0.2 NCurses version 6.1 libsigc++ version: 2.10.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.1.20181013 cwidget version: 0.5.17 Apt version: 5.0.2 aptitude linkage: linux-gate.so.1 (0xb7f96000) libapt-pkg.so.5.0 => /usr/lib/i386-linux-gnu/libapt-pkg.so.5.0 (0xb7922000) libncursesw.so.6 => /lib/i386-linux-gnu/libncursesw.so.6 (0xb78e) libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xb78b7000) libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 (0xb78af000) libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xb77a2000) libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xb766c000) libboost_iostreams.so.1.67.0 => /usr/lib/i386-linux-gnu/libboost_iostreams.so.1.67.0 (0xb765) libboost_system.so.1.67.0 => /usr/lib/i386-linux-gnu/libboost_system.so.1.67.0 (0xb7649000) libxapian.so.30 => /usr/lib/i386-linux-gnu/sse2/libxapian.so.30 (0xb7402000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb73e1000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb726) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb715a000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb713c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6f5e000) libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb6f44000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6f25000) libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xb6f12000) liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb6ee6000) liblz4.so.1 => /usr/lib/i386-linux-gnu/liblz4.so.1 (0xb6ec6000) libzstd.so.1 => /usr/lib/i386-linux-gnu/libzstd.so.1 (0xb6e2d000) libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xb6e06000) /lib/ld-linux.so.2 (0xb7f97000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6dfe000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6df4000) libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb6dea000) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.20.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.8.11-6 ii libapt-pkg5.0 1.8.0~beta1 ii libboost-iostreams1.67.0 1.67.0-10 ii libboost-system1.67.0 1.67.0-10 ii libc6 2.28-4 ii libcwidget3v5 0.5.17-11 ii libgcc1 1:8.2.0-15 ii libncursesw6 6.1+20181013-1 ii libsigc++-2.0-0v5 2.10.1-1 ii libsqlite3-0 3.26.0+fossilbc891ac6b-1 ii libstdc++68.2.0-15 ii libtinfo6 6.1+20181013-1 ii libxapian30 1.4.9-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-12 ii sensible-utils 0.0.12 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags pn tasksel -- no debconf information
Bug#920358: kopete: FTBFS, apparently with newer glibc
Package: kopete Version: 4:17.08.3-2 Severity: normal Tags: patch Dear Maintainer, while building kopete, I got an error about undefined symbols major() and minor(). These are in which is not included in the file, so the fix is just to add it (aptch is attached). I hear this problem is related to newer libc, haven't investigated though. Regards Jiri Palecek Index: kopete/protocols/jabber/libjingle/talk/session/phone/v4llookup.cc === --- kopete.orig/protocols/jabber/libjingle/talk/session/phone/v4llookup.cc +++ kopete/protocols/jabber/libjingle/talk/session/phone/v4llookup.cc @@ -15,6 +15,7 @@ #include #include #include +#include #include #include -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.19.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kopete depends on: ii kio5.54.1-1 ii kopete-data4:18.08.4~0.8 ii libc6 2.28-4 ii libexpat1 2.2.6-1 ii libgadu3 1:1.12.2-3 ii libgcc11:8.2.0-14 ii libidn11 1.33-2.2 ii libkf5archive5 5.54.0-1 ii libkf5bookmarks5 5.54.0-1 ii libkf5completion5 5.54.0-1 ii libkf5configcore5 5.54.0-1 ii libkf5configgui5 5.54.0-1 ii libkf5configwidgets5 5.54.0-1 ii libkf5contacts54:18.08.1-1 ii libkf5coreaddons5 5.54.0-1 ii libkf5crash5 5.54.0-1 ii libkf5dbusaddons5 5.54.0-1 ii libkf5dnssd5 5.54.0-1 ii libkf5emoticons-bin5.54.0-1 ii libkf5emoticons5 5.54.0-1 ii libkf5i18n55.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5identitymanagement5 18.08.1-1 ii libkf5itemviews5 5.54.0-1 ii libkf5kcmutils55.54.0-1 ii libkf5kdelibs4support5 5.54.0-1 ii libkf5khtml5 5.54.0-1 ii libkf5kiocore5 5.54.1-1 ii libkf5kiofilewidgets5 5.54.1-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5notifications5 5.54.0-1 ii libkf5notifyconfig55.54.0-1 ii libkf5parts5 5.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service5 5.54.0-1 ii libkf5solid5 5.54.0-1 ii libkf5textwidgets5 5.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkf5windowsystem55.54.0-1 ii libkf5xmlgui5 5.54.0-1 ii libkopete1 4:18.08.4~0.8 ii libmediastreamer-base101:2.16.1-4+b1 ii libmediastreamer-voip101:2.16.1-4+b1 ii libortp13 1:1.0.2-1 ii libotr54.1.1-3 ii libphonon4qt5-44:4.10.2-1 ii libqca-qt5-2 2.1.3-2 ii libqt5core5a 5.11.3+dfsg-2 ii libqt5dbus55.11.3+dfsg-2 ii libqt5gui5 5.11.3+dfsg-2 ii libqt5network5 5.11.3+dfsg-2 ii libqt5sql5 5.11.3+dfsg-2 ii libqt5widgets5 5.11.3+dfsg-2 ii libqt5xml5 5.11.3+dfsg-2 ii libqt5xmlpatterns5 5.11.3-2 ii libsrtp2-1 2.2.0-1 ii libssl1.1 1.1.1a-1 ii libstdc++6 8.2.0-14 ii libv4l-0 1.16.3-1 ii libxml22.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2 ii phonon4qt5 4:4.10.2-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages kopete recommends: ii libqca-qt5-2-plugins 2.1.3-2 ii libqt5sql5-sqlite 5.11.3+dfsg-2 Versions of packages kopete suggests: ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2 ii khelpcenter 4:18.04.0-1 -- no debconf information
Bug#912799: doxygen switch to llvm-toolchain-7
Hello Paolo, On 16. 01. 19 13:03, Paolo Greppi wrote: Hi Jiri, Il 16/01/19 03:05, Jiri Palecek ha scritto: Hello, On Mon, 3 Dec 2018 12:54:45 +0100 Paolo Greppi wrote: Hi, in preparation for this switch I am building doxygen from source with: ... I have been able to build the package successfully without this problem by patching the source with the attached llvm-7 patch. That was with release version 1.8.15. Thanks ! in the meantime I had created a similar one, inspired by an upstream issue: https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/patches/llvm_libs.diff The patch I picked is smaller than the other two, and seems to work so I'm inclined to keep it. But I am no cmake expert, so I am open to suggestions if there is a cmake/llvm specific reason to pick one or the other. I picked the gist of my patch from this email thread (about linking to llvm, read its other messages if you're interested): https://lists.llvm.org/pipermail/llvm-dev/2017-November/119119.html It says "the guidance should be to use the `llvm_config` CMake function instead. The proper usage of that in the example there would be to replace the call to `llvm_map_components_to_libnames` with `llvm_config(simple-tool support core irreader)`" and says you need the USE_SHARED parameter if you're linking dynamically. The macro then automatically computes which of the components are in the dynamic library and removes the static libraries from link. However if you just want to remove the components from the list and it works, I'm cool with that. I also needed an updated watch file and an updated no-rpath patch. watch file: check https://salsa.debian.org/paolog-guest/doxygen/commit/ab3cc38776cdef8fb18184fbc7290dd1bdaf3fa7 Good. re. rpath, while refreshing patches I removed a previous rpath patch: https://salsa.debian.org/paolog-guest/doxygen/commit/8622b2378a726a324266c2ccf234fa0f31e1551b#0e176d0b80fb8a20ce16f62f30644d9678caee76 can you explain the need to have this ? Simply, we don't want rpath binaries in Debian. See https://wiki.debian.org/RpathIssue. Solution taken directly from there. The doxygen library is linked with rpath set (and a mistaken one at that) therefore the need. But here we're talking about doxygen, which I ITA, that's why I have RFS an upload to experimental: https://bugs.debian.org/919413 BTW before we push to unstable, it would be great to building all (~700) reverse dependencies of doxygen against doxygen 1.8.15-1 . If you have comments/can help with that, you're welcome. Whoa, 700 packages! Are these reverse-BDs? what are you planning to check, just that it builds? Regards Jiri Palecek
Bug#912799: doxygen switch to llvm-toolchain-7
Hello,
On Mon, 3 Dec 2018 12:54:45 +0100 Paolo Greppi wrote:
> Hi, in preparation for this switch I am building doxygen from source
with:
>
> sudo apt install llvm-7-dev # for
/usr/lib/llvm-7/lib/cmake/llvm/LLVMConfig.cmake
> sudo apt install clang-7 # for
/usr/lib/llvm-7/lib/cmake/clang/ClangConfig.cmake
> git clone https://github.com/doxygen/doxygen
> cd doxygen
> mkdir build
> cd build
> LLVM_DIR=/usr/lib/llvm-7/lib/cmake/llvm/
Clang_DIR=/usr/lib/llvm-7/lib/cmake/clang/ cmake -Duse_libclang=ON -G
"Unix Makefiles" ..
> make
>
> It builds, but the resulting binary fails to start with:
> ./bin/doxygen
> : CommandLine Error: Option 'help-list' registered more than once!
> LLVM ERROR: inconsistency in registered CommandLine options
I have been able to build the package successfully without this problem
by patching the source with the attached llvm-7 patch. That was with
release version 1.8.15.
I also needed an updated watch file and an updated no-rpath patch.
I hope to see a new version of doxymacs built against llvm 7 in Debian soon.
Regards
Jiri Palecek
Index: doxygen-1.8.15/src/CMakeLists.txt
===
--- doxygen-1.8.15.orig/src/CMakeLists.txt
+++ doxygen-1.8.15/src/CMakeLists.txt
@@ -279,4 +279,6 @@ target_link_libraries(doxygen
${CLANG_LIBS}
)
+set_target_properties(doxygen PROPERTIES SKIP_BUILD_RPATH TRUE)
+
install(TARGETS doxygen DESTINATION bin)
Index: doxygen-1.8.15/src/CMakeLists.txt
===
--- doxygen-1.8.15.orig/src/CMakeLists.txt
+++ doxygen-1.8.15/src/CMakeLists.txt
@@ -261,12 +261,13 @@ if (use_libclang)
endif()
include_directories(${LLVM_INCLUDE_DIRS})
add_definitions(${LLVM_DEFINITIONS})
-llvm_map_components_to_libnames(llvm_libs support core option)
+llvm_config(doxygen USE_SHARED support core option)
target_compile_definitions(doxygen PRIVATE ${LLVM_DEFINITIONS})
-set(CLANG_LIBS libclang clangTooling ${llvm_libs})
+set(CLANG_LIBS libclang clangTooling)
endif()
target_link_libraries(doxygen
+ PRIVATE
_doxygen
doxycfg
qtools
Bug#917586: other kernel change affecting nvidia
Hello, commit https://github.com/torvalds/linux/commit/ae2b01f37044c10e975d22116755df56252b09d8 also affects nvidia. vm_insert_pfn is used in nvidia-drm/nvidia-drm-gem-nvkms-memory.c. It can be easily converted to vmf_insert_pfn, by removing the following switch (which only converts the errno to a vm fault, which vmf_... returns directly). With this and the ipmi_user_t fixed, nvidia module can be compiled again. Regards Jiri Palecek
Bug#917586: nvidia-kernel-dkms: kernel module doesn't build with kernel 4.20 from experimental
Package: nvidia-kernel-dkms
Version: 390.87-5
Severity: normal
Dear Maintainer,
the nvidia module doesn't build with the new kernel in experimental. The
error message is
/var/lib/dkms/nvidia-current/390.87/build/nvidia/os-interface.c: At top level:
/var/lib/dkms/nvidia-current/390.87/build/nvidia/os-interface.c:1700:5: error:
unknown type name 'ipmi_user_t'
ipmi_user_t p_user; // ptr to ipmi_msghandler user structure
^~~
/var/lib/dkms/nvidia-current/390.87/build/nvidia/os-interface.c:1709:5: error:
unknown type name 'ipmi_user_t'; did you mean 'pci_power_t'?
ipmi_user_t user,
^~~
pci_power_t
/var/lib/dkms/nvidia-current/390.87/build/nvidia/os-interface.c: In function
'os_ipmi_connect':
/var/lib/dkms/nvidia-current/390.87/build/nvidia/os-interface.c:1781:66: error:
passing argument 4 of 'ipmi_create_user' from incompatible pointer type
[-Werror=incompatible-pointer-types]
err_no = ipmi_create_user(devIndex, _ipmi_hndlrs, p_priv,
_priv->p_user);
^~~
In file included from
/var/lib/dkms/nvidia-current/390.87/build/common/inc/nv-linux.h:339,
from
/var/lib/dkms/nvidia-current/390.87/build/nvidia/os-interface.c:15:
/usr/src/linux-headers-4.20.0-trunk-common/include/linux/ipmi.h:114:32: note:
expected 'struct ipmi_user **' but argument is of type 'int *'
struct ipmi_user **user);
^~~~
and some others, all caused by the absence of ipmi_user_t. This was
introduced by commit
https://github.com/torvalds/linux/commit/4372ea94d40c5676814fc6d815a64caed963cb9f,
ipmi: Finally get rid of ipmi_user_t and ipmi_smi_t. Please have a look
at it.
Regards
Jiri Palecek
-- Package-specific info:
uname -a:
Linux debian 4.19.0-1-686-pae #1 SMP Debian 4.19.12-1 (2018-12-22) i686
GNU/Linux
/proc/version:
Linux version 4.19.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version
8.2.0 (Debian 8.2.0-12)) #1 SMP Debian 4.19.12-1 (2018-12-22)
/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module 390.87 Tue Aug 21 11:18:35 PDT
2018
GCC version: gcc version 8.2.0 (Debian 8.2.0-12)
lspci 'display controller [030?]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS
450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: nvidia
Kernel modules: nvidia
dmesg:
Device node permissions:
crw-rw+ 1 root video 226, 0 Dec 27 15:41 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Dec 27 15:41 /dev/dri/renderD128
crw-rw-rw- 1 root root 195, 254 Dec 27 14:51 /dev/nvidia-modeset
crw-rw-rw- 1 root root 195, 0 Dec 27 14:51 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Dec 27 14:51 /dev/nvidiactl
/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Dec 27 15:41 pci-:02:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Dec 27 15:41 pci-:02:00.0-render -> ../renderD128
video:x:44:
OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 15 Sep 11 13:12 /etc/alternatives/glx ->
/usr/lib/nvidia
lrwxrwxrwx 1 root root 49 Sep 11 13:12
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 48 Sep 11 13:12
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 48 Sep 11 13:12
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 52 Sep 11 13:12
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 52 Sep 11 13:12
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 42 Sep 11 13:12
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root 42 Sep 11 13:12
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root 49 Sep 11 13:12
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root 25 Sep 11 13:12
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root 42 Sep 11 13:12
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf ->
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root 36 Sep 11 13:12
/etc/altern
Bug#915111: firefox: Firefox freezes after resume from suspend
Package: firefox Version: 64.0~b12-2 Severity: normal Dear Maintainer, after upgrading to experimental firefox 64 (from firefox 62), firefox freezes when resuming from suspend overnight. It happens repeatedly, and firefox is using 50% CPU (=1 full core) in this case. I have to kill it, waiting for several minutes doesn't make it respond again. Regards Jiri Palecek -- Package-specific info: -- Addons package information -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.18.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 4.8.6 ii fontconfig2.13.1-2 ii libasound21.1.7-1+b1 ii libatk1.0-0 2.30.0-1 ii libc6 2.27-5 ii libcairo-gobject2 1.16.0-1 ii libcairo2 1.16.0-1 ii libdbus-1-3 1.12.10-1 ii libdbus-glib-1-2 0.110-2 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-8 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-9 ii libgdk-pixbuf2.0-02.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgtk-3-03.24.1-2 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.40-1 ii libpango-1.0-01.42.4-3 ii libsqlite3-0 3.25.3-1 ii libstartup-notification0 0.12-5 ii libstdc++68.2.0-9 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-1 ii libxcb1 1.13.1-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.15-1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox recommends: ii libavcodec58 10:4.1-dmo2 Versions of packages firefox suggests: ii fonts-lmodern 2.004.5-5 ii fonts-stix [otf-stix] 1.1.1-3 ii libcanberra0 0.30-6 ii libgssapi-krb5-2 1.16.1-1 ii libgtk2.0-02.24.32-3 pn pulseaudio -- no debconf information
Bug#915110: gimp: GIMP can't take screenshots
Package: gimp Version: 2.10.8-1 Severity: normal Dear Maintainer, I tried to take a screenshot with GIMP and got this error message: GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: No such object path '/Screenshot' I'm using KDE Plasma. However, when I ran GIMP under dbus-launch, it worked well. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.18.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp depends on: ii gimp-data2.10.8-1 ii libaa1 1.4p5-44+b2 ii libbabl-0.1-01:0.1.60-dmo1 ii libbz2-1.0 1.0.6-9 ii libc62.27-5 ii libcairo21.16.0-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-9 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libgegl-0.4-01:0.4.12-dmo1 ii libgexiv2-2 0.10.8-1 ii libgimp2.0 2.10.8-1 ii libglib2.0-0 2.58.1-2 ii libgs9 9.26~dfsg-1 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.1.1-1+b1 ii libheif1 1.3.2-1+b1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.2-1.3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1:1.3.0-dmo6 ii libopenexr23 2.2.1-4 ii libopenjp2-7 2.3.0-1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-01.42.4-3 ii libpng16-16 1.6.34-2 ii libpoppler-glib8 0.69.0-2 ii librsvg2-2 2.44.9-1 ii libstdc++6 8.2.0-9 ii libtiff5 4.0.10-2 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.26~dfsg-1 Versions of packages gimp suggests: ii gimp-data-extras 1:2.0.2-1 pn gimp-help-en | gimp-help pn gimp-python ii gvfs-backends 1.38.1-1 ii libasound21.1.7-1+b1 -- no debconf information
Bug#910348: The same bug is present in 4.18.0-3
found 910348 linux/4.18.20-1 thanks Hello, just installing the new version of the kernel in the 4.18 line, eager to test that its bootable again on i386 with more than 4G ram, I've found the nvidia module doesn't build. It seems like a reincarnation of the earlier problem in experimental kernels. For the record, the error message is: make KBUILD_OUTPUT=/lib/modules/4.18.0-3-686-pae/build V=1 -C /lib/modules/4.18.0-3-686-pae/source M=/var/lib/dkms/nvidia-current/390.87/build ARCH=i386 NV_KERNEL_SOURCES=/lib/modules/4.18.0-3-686-pae/source NV_KERNEL_OUTPUT=/lib/modules/4.18.0-3-686-pae/build NV_KERNEL_MODULES="nvidia nvidia-modeset nvidia-drm" INSTALL_MOD_DIR=kernel/drivers/video modules make[1]: Vstupuje se do adresáře ,,/usr/src/linux-headers-4.18.0-3-common" make -C /lib/modules/4.18.0-3-686-pae/build KBUILD_SRC=/usr/src/linux-headers-4.18.0-3-common \ -f /usr/src/linux-headers-4.18.0-3-common/Makefile modules make[2]: Vstupuje se do adresáře ,,/usr/src/linux-headers-4.18.0-3-686-pae" test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) /usr/src/linux-headers-4.18.0-3-common/Makefile:301: scripts/subarch.include: Adresář nebo soubor neexistuje (meaning file not found). Regards Jiri Palecek
Bug#908382: Fwd: About bug 308382: kernel 4.18 fails to boot on my system
Hello this should be fixed by this commit https://github.com/torvalds/linux/commit/485734f3fc77c1eb77ffe138c027b9a4bf0178f3 in linux 4.19 (release). Please check once this gets into Debian. Regards Jiri Palecek
Bug#909805: About bug 308382: kernel 4.18 fails to boot on my system
Hi Andrey, could you check if the circumstances of bug 908382 also apply to you? It seems very similar, particularly if your system also has more than 4G memory. It could be the same bug. Regards Jiri Palecek
Bug#908382: Update on kernel bug: kernel 4.18 fails to boot
Hello, just for an update on this bug, I finally did the bisecting and found the first offending commit is this: commit 21e07dba9fb1179148089d611fc9e6e70d1887c3 (HEAD, refs/bisect/bad) Author: Christoph Hellwig Date: Tue Apr 3 19:09:59 2018 +0200 scsi: reduce use of block bounce buffers We can rely on the dma-mapping code to handle any DMA limits that is bigger than the ISA DMA mask for us (either using an iommu or swiotlb), so remove setting the block layer bounce limit for anything but the unchecked_isa_dma case, or the bouncing for highmem pages. Signed-off-by: Christoph Hellwig Reviewed-by: Jens Axboe Apparently the system with 5G memory needs bounce buffers after all, and without iommu, the swiotlb thingy didn't quite make it. Init then crashes after unsuccessful read of the disk. Regards Jiri Palecek
Bug#882287: fixed in mozilla-noscript 10.1.9.6-1
Hello On 9/24/18 11:00 AM, Ximin Luo wrote: Source: mozilla-noscript Source-Version: 10.1.9.6-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 22 Sep 2018 23:25:18 -0700 Source: mozilla-noscript Binary: webext-noscript xul-ext-noscript Architecture: source all Version: 10.1.9.6-1 Distribution: unstable Urgency: medium Maintainer: Debian Mozilla Extension Maintainers Changed-By: Ximin Luo Description: webext-noscript - permissions manager for Firefox xul-ext-noscript - Show browser tabs like a tree - transitional package Show browser tabs like a tree? I don't think so. Please correct that. Regards Jiri Palecek
Bug#908412: Followup
Hello,
I think this bug is caused by the addition of the Diablo patch.
Certainly, removing it fixed it.
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -870,6 +870,9 @@ static SHORT alloc_tls_slot( LDR_MODULE
size = dir->EndAddressOfRawData - dir->StartAddressOfRawData;
if (!size && !dir->SizeOfZeroFill && !dir->AddressOfCallBacks)
return -1;
+ if (!tls_dirs)
+ return -1;
+
for (i = 0; i < tls_module_count; i++)
{
if (!tls_dirs[i].StartAddressOfRawData &&
!tls_dirs[i].EndAddressOfRawData &&
I think the patch is simply wrong. It doesn't really fix any obvious bug
in the logic and certainly shouldn't "fix out-of-bounds read when
tls_dirs is empty" as the code already doesn't access tls_dirs when it
is empty, bc. tls_module_count should be zero then. The code that
follows clearly handles tls_dirs being null by allocating some memory
and setting tls_dirs.
If anything, the patch fixes Diablo by obstructing normal function of
the loader. I don't think that is a wise move to make.
Do you have any indication of an actual out-of-bounds read happening
there when running Diablo? Or what exactly were you thinking when
writing the patch? The messages on the board (
https://us.battle.net/forums/en/bnet/topic/20760475943?page=4) indicate
some Windows users also see crashes.
I suggest the patch should be abandoned.
Regards
Jiri Palecek
Bug#908412: wine-development: regression: the game SimSig fails to run
Package: wine-development Version: 3.14-2 Severity: normal Dear Maintainer, SimSig (from simsig.co.uk) ceased to work under wine in version 3.14-2 (was OK in 3.14-1). It prints out this error message: 000f:err:service:process_send_command service protocol error - failed to read pipe r = 0 count = 0! 002b:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\sfhlp02": c002 0014:err:service:process_send_command service protocol error - failed to write pipe! wine: Unhandled page fault on write access to 0x00564000 at address 0x7bc55081 (thread 0031), starting debugger... 000f:err:service:process_send_command service protocol error - failed to read pipe r = 0 count = 0! 0009:err:seh:setup_exception_record stack overflow 1328 bytes in thread 0009 eip 7bc8483f esp 00240e00 stack 0x24-0x241000-0x34 where the fatal thing is probably the last line (the rest appears even with applications that work, eg. cmd. Regards Jiri Palecek -- Package-specific info: /usr/bin/wine points to /usr/bin/wine-development. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.17.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wine-development depends on: ii wine32-development 3.14-1 wine-development recommends no packages. Versions of packages wine-development suggests: pn dosbox pn playonlinux ii winbind 2:4.8.5+dfsg-1 pn wine-binfmt ii winetricks 0.0+20170823-1 Versions of packages wine-development is related to: ii fonts-wine 3.0.2-2 ii wine-development3.14-1 ii wine32-development 3.14-1 pn wine64-development -- no debconf information
Bug#908359: nvidia-kernel-dkms: fails to compile with kernel 4.19
Package: nvidia-kernel-dkms Version: 390.77-1 Severity: normal Dear Maintainer, compiling nvidia kernel drivers with kernel 4.19 from experimental fails with error message about missing function drm_connector_attach_encoder. With the patch from [1], I could compile it successfully. Regards Jiri Palecek 1: https://devtalk.nvidia.com/default/topic/1038726/linux/black-screens-on-boot-with-current-master-4-19-staging-and-396-xx/ -- Package-specific info: uname -a: Linux debian 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) i686 GNU/Linux /proc/version: Linux version 4.17.0-3-686-pae (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-28)) #1 SMP Debian 4.17.17-1 (2018-08-18) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86 Kernel Module 390.77 Tue Jul 10 17:16:37 PDT 2018 GCC version: gcc version 7.3.0 (Debian 7.3.0-27) lspci 'display controller [030?]': 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS 450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 25 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d000 (64-bit, prefetchable) [size=128M] Region 3: Memory at d800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at ec00 [size=128] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Sep 9 01:18 /dev/dri/card0 crw-rw+ 1 root video 226, 128 Sep 9 01:18 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Sep 9 01:30 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Sep 9 01:30 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Sep 9 01:30 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Sep 9 01:18 pci-:02:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Sep 9 01:18 pci-:02:00.0-render -> ../renderD128 video:x:44: OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jun 1 14:39 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 42 Jun 1 14:39 /etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 41 Jun 1 14:39 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Jun 1 14:39 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 52 Jun 1 14:39 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 52 Jun 1 14:39 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 49 Jun 1 14:39 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Jun 1 14:39 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jun 1 14:39 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jun 1 14:39 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jun 1 14:39 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Jun 1 14:39 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 Jun 1 14:39 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 Jun 1 14:39 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 Aug 1 17:15 /etc/alternatives/nvidia -> /usr/lib/nvidia/current lrwxrwxrwx 1 root root 50 Aug 1 17:15 /etc/alternatives/nvidia--libEGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/current/libEGL.so.1 lrwxrwxrwx 1 root root 57 Aug 1 17:15 /etc/alternatives/nvidia--libEGL_nvidia.so.0-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/current/libEGL_nvidia.so.0 lrwxrwxrwx 1 root root 49 Aug 1 17:15 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 49 Aug 1 17:15 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 33 Aug 1 17:15 /etc/alternatives/nvidia--libglx.so -> /usr/lib/nvidia/current/libglx.so lrwxrwxrwx 1 root root 57 Aug 1 17:15 /etc/alternatives/nvidia--libnvidia-cfg.so.
Bug#903710: libc6-amd64: libc6-amd64 and libc6-x32 packages bloated to more than 1 GB (!) in recent versions
Package: libc6-amd64 Version: 2.27-4 Severity: normal Dear Maintainer, I was quite astonished to learn that upgrading libc6-amd64 took more than a gigabyte of disk space. It seems libc6-x32 has the same issue. The problem is in tehse files (from buildd logs(1)): -rw-r--r-- root/root 4421064 2018-07-07 16:34 ./usr/libx32/gconv/BIG5HKSCS.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/BRF.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP10007.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1125.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1250.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1251.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1252.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1253.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1254.so -rw-r--r-- root/root 4199880 2018-07-07 16:34 ./usr/libx32/gconv/CP1255.so These files normally take about 13 kB, but here they have 4 MB each. Looking into the binaries $ objdump -h CP1125.so CP1125.so: file format elf32-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 0024 0154 0154 0154 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 0020 0178 0178 0178 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .gnu.hash 0024 0198 0198 0198 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 00b0 01bc 01bc 01bc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynstr 00d7 026c 026c 026c 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.version 0016 0344 0344 0344 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version_r 0030 035c 035c 035c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .rela.dyn 0054 038c 038c 038c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rela.plt 0030 03e0 03e0 03e0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .init 0017 0020 0020 0020 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .plt 0050 00200020 00200020 00200020 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .plt.got 0008 00200070 00200070 00200070 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .text 0b7f 00200080 00200080 00200080 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .fini 0009 00200c00 00200c00 00200c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 14 .rodata 0740 0040 0040 0040 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame_hdr 0034 00400740 00400740 00400740 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .eh_frame 0110 00400774 00400774 00400774 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 17 .hash 0040 00400884 00400884 00400884 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 18 .init_array 0004 00600ef0 00600ef0 00400ef0 2**2 CONTENTS, ALLOC, LOAD, DATA 19 .fini_array 0004 00600ef4 00600ef4 00400ef4 2**2 CONTENTS, ALLOC, LOAD, DATA 20 .dynamic 00e8 00600ef8 00600ef8 00400ef8 2**2 CONTENTS, ALLOC, LOAD, DATA 21 .got 0020 00600fe0 00600fe0 00400fe0 2**3 CONTENTS, ALLOC, LOAD, DATA 22 .got.plt 0038 00601000 00601000 00401000 2**3 CONTENTS, ALLOC, LOAD, DATA 23 .data 0004 00601038 00601038 00401038 2**2 CONTENTS, ALLOC, LOAD, DATA 24 .bss 0004 0060103c 0060103c 0040103c 2**0 ALLOC 25 .gnu_debuglink 0034 0040103c 2**2 CONTENTS, READONLY it seems that while the sizes are quite small together, the sections from .init onwards are placed megabytes into the file. Is that some problem with binutils? Regards Jiri Palecek 1: https://buildd.debian.org/status/fetch.php?pkg=glibc=i386=2.27-4=1530992794=0 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.17.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd
Bug#888423: firefox: FF 58.0 segfaults each 1-2 minute
On Thu, 25 Jan 2018 15:25:32 +0300 "Dmitry E. Oboukhov" wrote: > gdb /usr/bin/firefox core Hi, I'm also seeing frequent crashes in firefox (62), and I just want to ask - how do you make core files/backtraces from firefox crashes? I always get the option to report to mozilla, restore tabs etc. - is there an option or something? Regards Jiri Palecek
Bug#900248: The proposed patch in nvidia conf fix DRI but many other problems remains
Hi, On 6/28/18 12:54 PM, Eric Valette wrote: Just a quick note to say that indeed the proposed patch to look for DRI modules at the right place is working. However, I have a bunch of other problems since driver update even with the fix in place: * Sddm does not start. I get only a black screen with the mouse pointer. I have should check but I think I have a backtrace that points to qtRenderGlthread that is crashing in systemd-nss lib, * using lightdm and using plasma I'm able to get back to my kde environment however the kde setup takes ages to start (and I have no more the DRI message in Xorg.0.log), * The lock screen also takes ages to start, black screen for 30s or so with keyboar input or mous move not working, * Launching Kodi, takes 40s but is fluid afterwards * Checked both glxinfo, vdpau info : all normal, Are you using xserver 1.20 from unstable or 1.19.6 from testing? I've had similar problems when I updated, and they went away when I downgraded xserver-xorg-core. Regards Jiri Palecek
Bug#900533: bug not fixed in v68
fixed 900533 67.0.3396.79-2 thanks * * Hello, this bug is fixed in the aforementioned version in unstable (not the one in experimental). The telling sign is whether it does or doesn't depend on libavcodecXX et al. Therefore I'm correcting the found/fixed versions. Regards Jiri Palecek
Bug#900151: src:imagemagick: patch fixing some C warnings
Package: src:imagemagick
Severity: wishlist
Tags: patch
Dear Maintainer,
while building the package for i386 (as the current version failed on
the buildds some time ago), I noticed there are some C warnings while
building the code. These are some format warnings, some pointer casts
and an erroneous use of sizeof in random.c.
Please, look at it and maybe apply the attached patch.
Regards
Jiri Palecek
Index: imagemagick-6.9.9.39+dfsg/coders/pgx.c
===
--- imagemagick-6.9.9.39+dfsg.orig/coders/pgx.c
+++ imagemagick-6.9.9.39+dfsg/coders/pgx.c
@@ -365,7 +365,7 @@ static MagickBooleanType WritePGXImage(c
status=OpenBlob(image_info,image,WriteBinaryBlobMode,exception);
if (status == MagickFalse)
return(status);
- (void) FormatLocaleString(buffer,MaxTextExtent,"PG ML + %ld %lu %lu\n",
+ (void) FormatLocaleString(buffer,MaxTextExtent,"PG ML + %zd %zu %zu\n",
image->depth,image->columns,image->rows);
(void) WriteBlob(image,strlen(buffer),(unsigned char *) buffer);
(void) TransformImageColorspace(image,sRGBColorspace);
Index: imagemagick-6.9.9.39+dfsg/coders/svg.c
===
--- imagemagick-6.9.9.39+dfsg.orig/coders/svg.c
+++ imagemagick-6.9.9.39+dfsg/coders/svg.c
@@ -2915,11 +2915,11 @@ static Image *ReadSVGImage(const ImageIn
image->x_resolution,image->y_resolution);
(void) FormatLocaleString(background,MaxTextExtent,
"rgb(%.20g%%,%.20g%%,%.20g%%)",
-100.0*QuantumScale*image->background_color.red,
-100.0*QuantumScale*image->background_color.green,
-100.0*QuantumScale*image->background_color.blue);
- (void) FormatLocaleString(opacity,MaxTextExtent,"%.20g",QuantumScale*
-(QuantumRange-image->background_color.opacity));
+(double)(100.0*QuantumScale*image->background_color.red),
+(double)(100.0*QuantumScale*image->background_color.green),
+(double)(100.0*QuantumScale*image->background_color.blue));
+ (void) FormatLocaleString(opacity,MaxTextExtent,"%.20g",(double)(QuantumScale*
+(QuantumRange-image->background_color.opacity)));
(void) FormatLocaleString(command,MaxTextExtent,GetDelegateCommands(
delegate_info),input_filename,output_filename,density,background,
opacity,unique);
Index: imagemagick-6.9.9.39+dfsg/magick/color.c
===
--- imagemagick-6.9.9.39+dfsg.orig/magick/color.c
+++ imagemagick-6.9.9.39+dfsg/magick/color.c
@@ -1200,7 +1200,7 @@ MagickExport void ConcatenateColorCompon
if (channel == OpacityChannel)
{
(void) FormatLocaleString(component,MaxTextExtent,"%.*g",
-GetMagickPrecision(),QuantumScale*ClampToQuantum(color));
+GetMagickPrecision(),(double)(QuantumScale*ClampToQuantum(color)));
(void) ConcatenateMagickString(tuple,component,MaxTextExtent);
return;
}
Index: imagemagick-6.9.9.39+dfsg/magick/effect.c
===
--- imagemagick-6.9.9.39+dfsg.orig/magick/effect.c
+++ imagemagick-6.9.9.39+dfsg/magick/effect.c
@@ -3391,10 +3391,10 @@ MagickExport Image *RotationalBlurImageC
if ((cos_theta == (MagickRealType *) NULL) ||
(sin_theta == (MagickRealType *) NULL))
{
- if (cos_theta != (double *) NULL)
-cos_theta=(double *) RelinquishMagickMemory(cos_theta);
- if (sin_theta != (double *) NULL)
-sin_theta=(double *) RelinquishMagickMemory(sin_theta);
+ if (cos_theta != (MagickRealType *) NULL)
+cos_theta=(MagickRealType *) RelinquishMagickMemory(cos_theta);
+ if (sin_theta != (MagickRealType *) NULL)
+sin_theta=(MagickRealType *) RelinquishMagickMemory(sin_theta);
blur_image=DestroyImage(blur_image);
ThrowImageException(ResourceLimitError,"MemoryAllocationFailed");
}
Index: imagemagick-6.9.9.39+dfsg/magick/magick-type.h
===
--- imagemagick-6.9.9.39+dfsg.orig/magick/magick-type.h
+++ imagemagick-6.9.9.39+dfsg/magick/magick-type.h
@@ -67,7 +67,11 @@ typedef ssize_t SignedQuantum;
#if defined(MAGICKCORE_HDRI_SUPPORT)
typedef MagickFloatType Quantum;
#define QuantumRange 255.0
+#if MAGICKCORE_SIZEOF_DOUBLE_T == 0 || (MAGICKCORE_SIZEOF_DOUBLE_T == MAGICKCORE_SIZEOF_DOUBLE)
#define QuantumFormat "%g"
+#elif (MAGICKCORE_SIZEOF_DOUBLE_T == MAGICKCORE_SIZEOF_LONG_DOUBLE)
+#define QuantumFormat "%Lg"
+#endif
#else
typedef unsigned char Quantum;
#define QuantumRange ((Quantum) 255)
@@ -80,7 +84,11 @@ typedef ssize_t SignedQuantum;
#if defined(MAGICKCORE_HDRI_SUPPORT)
typedef MagickFloatType Quantum;
#define QuantumRange 65535.0
+#i
Bug#895773: ktouch: ktouch stopped working after update of Qt to 5.10 due to a qml problem
Package: ktouch Version: 4:17.08.3-1 Severity: important Dear Maintainer, after I updated Qt packages to 5.10, ktouch stopped working. It displays an error dialog complaining about error in QML: qrc:/qml/main.qml:129:5: Type HomeScreen unavailable qrc:/qml/homescreen/HomeScreen.qml:162:26: Type ProfileSelector unavailable qrc:/qml/homescreen/ProfileSelector.qml:92:13: Type ProfileDetailsItem unavailable qrc:/qml/homescreen/ProfileDetailsItem.qml:98:21: Type LearningProgressChart unavailable qrc:/qml/common/LearningProgressChart.qml:24:1: Type LineChart unavailable file:///usr/lib/i386-linux-gnu/qt5/qml/org/kde/charts/LineChart.qml:195:29: Label is not a type The dependencies of ktouch-data are all at their latest versions: $ aptitude search --disable-columns -F "%p %V" '~Rktouch-data' qml-module-org-kde-charts 4:17.08.3-2 qml-module-org-kde-kcoreaddons 5.44.0-1+b1 qml-module-org-kde-kquickcontrolsaddons 5.44.0-1+b1 qml-module-qtgraphicaleffects 5.10.1-2 qml-module-qtquick-controls 5.10.1-2 qml-module-qtquick-controls2 5.10.1-2 qml-module-qtquick-layouts 5.10.1-4 qml-module-qtquick2 5.10.1-4 Please have a look at it, Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.14.0-bughunt-fixed+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ktouch depends on: ii ktouch-data 4:17.08.3-1 ii libc6 2.27-2 ii libgcc1 1:8-20180402-1 ii libkf5completion5 5.44.0-1 ii libkf5configcore5 5.44.0-1 ii libkf5configgui5 5.44.0-1 ii libkf5configwidgets5 5.44.0-1 ii libkf5coreaddons5 5.44.0-1 ii libkf5declarative55.44.0-1+b1 ii libkf5i18n5 5.44.0-1 ii libkf5itemviews5 5.44.0-1 ii libkf5kcmutils5 5.44.0-1 ii libkf5service-bin 5.44.0-1 ii libkf5service55.44.0-1 ii libkf5textwidgets55.44.0-1 ii libkf5widgetsaddons5 5.44.0-1 ii libkf5xmlgui5 5.44.0-2+b1 ii libqt5core5a 5.10.1+dfsg-5 ii libqt5gui55.10.1+dfsg-5 ii libqt5qml55.10.1-4 ii libqt5quick5 5.10.1-4 ii libqt5quickwidgets5 5.10.1-4 ii libqt5sql55.10.1+dfsg-5 ii libqt5widgets55.10.1+dfsg-5 ii libqt5x11extras5 5.10.1-2 ii libqt5xml55.10.1+dfsg-5 ii libqt5xmlpatterns55.10.1-2 ii libstdc++68-20180402-1 ii libx11-6 2:1.6.5-1 ii libxcb-xkb1 1.13-1 ii libxcb1 1.13-1 ktouch recommends no packages. ktouch suggests no packages. -- no debconf information
Bug#895429: nvidia-kernel-dkms: doesn't build with linux 4.16 from experimental (missing symbol swiotlb_map_sg_attrs)
On 4/11/18 4:07 PM, Luca Boccassi wrote: On Wed, 11 Apr 2018 14:57:56 +0200 Jiri Palecek <jpale...@web.de> wrote: Package: nvidia-kernel-dkms Version: 390.42-1 Severity: normal 390.48 has been in unstable and testing for a while, have you tried with it? In unstable, not testing. Anyway, I just tried it and it's just the same. Regards Jiri Palecek
Bug#895429: nvidia-kernel-dkms: doesn't build with linux 4.16 from experimental (missing symbol swiotlb_map_sg_attrs)
Package: nvidia-kernel-dkms
Version: 390.42-1
Severity: normal
Dear Maintainer,
the nvidia kernel driver breaks with linux 4.16, whcih is now in
experimental. While the module builds, the resulting module can't be
loaded with error
nvidia: Unknown symbol swiotlb_map_sg_attrs (err 0)
This has been reproted elsewhere [1],[2]. The patch to disable SWIOTLB
usage on kernel >=4.16 makes it work.
Please, consider this for the future.
Regards
Jiri Palecek
1:
https://devtalk.nvidia.com/default/topic/1030082/linux/kernel-4-16-rc1-breaks-latest-drivers-unknown-symbol-swiotlb_map_sg_attrs-/
2: https://bugzilla.kernel.org/show_bug.cgi?id=198997
-- Package-specific info:
uname -a:
Linux debian 4.14.0-rc6-bughunt+ #1 SMP Wed Apr 11 03:00:18 CEST 2018 i686
GNU/Linux
/proc/version:
Linux version 4.14.0-rc6-bughunt+ (jirka@debian) (gcc version 7.3.0 (Debian
7.3.0-12)) #1 SMP Wed Apr 11 03:00:18 CEST 2018
/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module 390.42 Sat Mar 3 02:54:12 PST
2018
GCC version: gcc version 7.3.0 (Debian 7.3.0-12)
lspci 'display controller [030?]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS
450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: nvidia
Kernel modules: nvidia
dmesg:
Device node permissions:
crw-rw+ 1 root video 226, 0 Apr 11 14:04 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Apr 11 14:04 /dev/dri/renderD128
crw-rw-rw- 1 root root 195, 254 Apr 11 14:11 /dev/nvidia-modeset
crw-rw-rw- 1 root root 195, 0 Apr 11 14:11 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Apr 11 14:11 /dev/nvidiactl
/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Apr 11 14:04 pci-:02:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Apr 11 14:04 pci-:02:00.0-render -> ../renderD128
video:x:44:
OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 2167 May 13 2016 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root 15 Jan 22 15:12 /etc/alternatives/glx ->
/usr/lib/nvidia
lrwxrwxrwx 1 root root 47 Mar 29 01:55
/etc/alternatives/glx--libEGL.so-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root 42 Jan 22 15:12
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root 46 Mar 29 01:55
/etc/alternatives/glx--libGL.so-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 46 Mar 29 01:55
/etc/alternatives/glx--libGL.so-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 41 Jan 22 15:12
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 41 Jan 22 15:12
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 48 Jan 22 15:12
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 48 Jan 22 15:12
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 50 Mar 29 01:55
/etc/alternatives/glx--libGLESv2.so-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root 50 Mar 29 01:55
/etc/alternatives/glx--libGLESv2.so-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root 52 Jan 22 15:12
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 52 Jan 22 15:12
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu ->
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 49 Jan 22 15:12
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root 25 Jan 22 15:12
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root 42 Jan 22 15:12
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf ->
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root 36 Jan 22 15:12
/etc/alternatives/glx--nvidia-bug-report.sh ->
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root 39 Jan 22 15:12
/etc/alternatives/glx--nvidia-drm-outputclass.conf ->
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root 28 Jan 22 15:12
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrw
Bug#894315: konsole: boxes in programs such as dialog or aptitude using ncurses>6.0 are garbled
Package: konsole Version: 4:17.08.3-1 Severity: normal Dear Maintainer, after upgrading libncurses, some text mode programs started to display boxes wrong. See bug 892923 for a screenshot. This was reproted upstream as https://bugs.kde.org/show_bug.cgi?id=384620 and fixed recently. There's also a patch that could be backported. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.14.0-rc3-bughunt+ (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages konsole depends on: ii kio 5.42.0-3 ii konsole-kpart 4:17.08.3-1 ii libc6 2.27-2 ii libkf5completion5 5.42.0-4 ii libkf5configcore5 5.42.0-2 ii libkf5configgui5 5.42.0-2 ii libkf5configwidgets5 5.42.0-2 ii libkf5coreaddons5 5.42.0-2 ii libkf5crash5 5.42.0-2 ii libkf5dbusaddons5 5.42.0-2 ii libkf5i18n5 5.42.0-3 ii libkf5iconthemes5 5.42.0-2 ii libkf5kiowidgets5 5.42.0-3 ii libkf5notifyconfig5 5.42.0-2 ii libkf5widgetsaddons5 5.42.1-2 ii libkf5windowsystem5 5.42.0-2 ii libkf5xmlgui5 5.42.0-2 ii libqt5core5a 5.9.2+dfsg-12 ii libqt5gui55.9.2+dfsg-12 ii libqt5widgets55.9.2+dfsg-12 ii libstdc++68-20180321-1 konsole recommends no packages. konsole suggests no packages. -- no debconf information
Bug#892923: aptitude: After upgrading ncurses, aptitude fails to correctly display dialog windows and align columns
On 3/16/18 1:24 PM, Manuel A. Fernandez Montecelo wrote: Control: tags -1 + moreinfo Hi Jiri, 2018-03-14 15:34 Jiri Palecek: Package: aptitude Version: 0.8.10-6 Severity: normal Dear Maintainer, after upgrading libncurses5 to version 6.1-1, aptitude no longer displays its GUI correctly. The columns are not aligned, and the dialog boxes fail to use the width of the screen. See this screenshot with what should be a search dialog: Other console applications (mc, emacs) don't exhibit this behaviour, so I'm filing this to aptitude. Please have a look at it. Thanks for the report. I have the same versions installed and for me it works perfectly. $ aptitude search -F '%p %v' --disable-columns '~i~n^(aptitude|libncursesw5)$' aptitude 0.8.10-6 aptitude-common 0.8.10-6 aptitude-dbgsym 0.8.10-6 libncursesw5 6.1-1 libncursesw5-dev 6.1-1 This will require more investigation. Maybe the locale/encoding? Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= (charmap=ISO-8859-2) No, it isn't this (checked that). In fact, after finding that dialog is also affected by this problem and dissecting the escape codes sent to the terminal, I can conclude that the true culprit is Konsole. xterm and text console all work well. The problem seems to be the escape sequence ESC [ 7 b. Problem is, I can't find anywhere documented what it does, but it should be something like repeat last char 7 times. Regards Jiri Palecek
Bug#893929: libqt4-dev-bin: kopete FTBFS
Hello, On 3/25/18 8:19 PM, Lisandro Damián Nicanor Pérez Meyer wrote: Hi Jiri! El viernes, 23 de marzo de 2018 18:25:29 -03 Jiri Palecek escribió: Package: libqt4-dev-bin Version: 4:4.8.7+dfsg-13 Severity: normal Tags: patch File: /usr/bin/moc-qt4 Dear Maintainer, I tried to rebuild kopete from source and got errors such as these: Generating s5b.moc /mnt/extras/src/kopete-17.08.3/protocols/jabber/libiris/src/irisnet/noncore/ cutestuff/bytestream.h:52: Parse error at "defined" Apparently this is caused by a nonconformity of moc's preprocessor which manifests itself when macro major(arg) I reember this was an issue some time ago. I went ahead and rebuilt unstable's kopete and did it without issues. So I wonder why unstable kopete builds and your build doesnt :-/ I don't know, maybe it's the libc version ? (2.27-2) For what it's worth, the next kopete version should be qt5 based. Yes, but that's assuming there won't be any need for rebuilds. Regards Jiri Palecek
Bug#893929: libqt4-dev-bin: kopete FTBFS
Package: libqt4-dev-bin
Version: 4:4.8.7+dfsg-13
Severity: normal
Tags: patch
File: /usr/bin/moc-qt4
Dear Maintainer,
I tried to rebuild kopete from source and got errors such as these:
Generating s5b.moc
/mnt/extras/src/kopete-17.08.3/protocols/jabber/libiris/src/irisnet/noncore/cutestuff/bytestream.h:52:
Parse error at "defined"
Apparently this is caused by a nonconformity of moc's preprocessor which
manifests itself when macro
major(arg)
is defined, as, unfortunately file does. The line 52
in the error message refers to a line in this particular file (not in
the file it reports, which is a bit confusing.
This has been noted before. I have found a rethat bugreprot of the same
problem here: https://bugzilla.redhat.com/show_bug.cgi?id=1396755. Their
solution is to work it around by a hack that filters that particular
include out. A proper fix would be to make the preprocessor correct, but
that would require too much work.
Therefore, I propose this patch, that, in line with redhat hacks it
around. I've checked that with the patch, kopete builds successfully.
Index: qt4-x11-4.8.7+dfsg/src/tools/moc/main.cpp
===
--- qt4-x11-4.8.7+dfsg.orig/src/tools/moc/main.cpp
+++ qt4-x11-4.8.7+dfsg/src/tools/moc/main.cpp
@@ -191,6 +191,7 @@ int runMoc(int _argc, char **_argv)
// Workaround a bugs while parsing some boost headers. See QTBUG-22829
pp.macros["BOOST_TT_HAS_OPERATOR_HPP_INCLUDED"];
pp.macros["BOOST_LEXICAL_CAST_INCLUDED"];
+pp.macros["_SYS_SYSMACROS_H_OUTER"];
QByteArray filename;
QByteArray output;
Regards
Jiri Palecek
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.14.0-rc3-bughunt (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libqt4-dev-bin depends on:
ii libc6 2.27-2
ii libgcc11:8-20180312-2
ii libqt4-qt3support 4:4.8.7+dfsg-13.1
ii libqt4-xml 4:4.8.7+dfsg-13.1
ii libqtcore4 4:4.8.7+dfsg-13.1
ii libqtdbus4 4:4.8.7+dfsg-13.1
ii libqtgui4 4:4.8.7+dfsg-13.1
ii libstdc++6 8-20180312-2
ii qtchooser 64-ga1b6736-4
ii zlib1g 1:1.2.8.dfsg-5
libqt4-dev-bin recommends no packages.
libqt4-dev-bin suggests no packages.
-- no debconf information
Bug#881352: Closing this bug, fixed upstram
Hello this bug has been fixed in version 4.15 by commit 0abc2a10389f0c9070f76ca906c7382788036b93. Regards Jiri Palecek
Bug#885111: kdepim-runtime: kdepim-runtime depends on libkolab-dev
Package: kdepim-runtime Version: 4:17.08.3-1 Severity: wishlist Dear Maintainer, the new version of kdepim-runtime pulls a whole load of -dev packages as dependencies through libkolab-dev, on which it depends. Please check that depending on the runtime library package wouldn't suffice instead. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.14.0-bughunt-fixed+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kdepim-runtime depends on: ii akonadi-server 4:17.08.0-1+b1 ii kio 5.37.0-2 ii kio-ldap 17.08.0-1 ii kio-sieve4:17.08.0-1 ii kio-smtp 17.08.0-1 ii libc62.25-5 ii libgcc1 1:7.2.0-18 ii libkf5akonadiagentbase5 4:17.08.0-1+b1 ii libkf5akonadicalendar5 4:17.08.0-1 ii libkf5akonadicontact54:17.08.0-1 ii libkf5akonadicore5 4:17.08.0-1+b1 ii libkf5akonadimime5 4:17.08.0-1 ii libkf5akonadinotes5 4:16.04.2-2 ii libkf5akonadiprivate54:17.08.0-1+b1 ii libkf5akonadiwidgets54:17.08.0-1+b1 ii libkf5alarmcalendar5 4:17.08.0-1 ii libkf5calendarcore5 4:17.08.0-1 ii libkf5calendarutils5 4:17.08.0-1 ii libkf5codecs55.37.0-2 ii libkf5completion55.37.0-2 ii libkf5configcore55.37.0-2 ii libkf5configgui5 5.37.0-2 ii libkf5configwidgets5 5.37.0-2 ii libkf5contacts5 4:17.08.0-1 ii libkf5coreaddons55.37.0-2 ii libkf5dbusaddons55.37.0-2 ii libkf5i18n5 5.37.0-2 ii libkf5identitymanagement517.08.0-1 ii libkf5imap5 17.08.0-1 ii libkf5itemmodels55.37.0-2 ii libkf5jobwidgets55.37.0-2 ii libkf5kdelibs4support5 5.37.0-2 ii libkf5kiocore5 5.37.0-2 ii libkf5kiowidgets55.37.0-2 ii libkf5mailtransport5 17.08.0-1 ii libkf5mailtransportakonadi5 17.08.0-1 ii libkf5mbox5 16.04.2-1 ii libkf5mime5 16.04.2-1 ii libkf5notifications5 5.37.0-2 ii libkf5notifyconfig5 5.37.0-2 ii libkf5pimcommon-plugins 4:16.04.2-2 ii libkf5pimcommon5 4:17.08.0-1 ii libkf5service-bin5.37.0-2 ii libkf5service5 5.37.0-2 ii libkf5textwidgets5 5.37.0-2 ii libkf5wallet-bin 5.37.0-2 ii libkf5wallet55.37.0-2 ii libkf5widgetsaddons5 5.37.0-2 ii libkf5windowsystem5 5.37.0-2 ii libkf5xmlgui55.37.0-2 ii libkolab11.0.2-3+deb10u1+b1 ii libkpimgapicalendar5 17.08.0-1 ii libkpimgapicontacts5 17.08.0-1 ii libkpimgapicore5 17.08.0-1 ii libkpimgapitasks517.08.0-1 ii libkpimkdav5 17.08.3-1 ii libqt5core5a 5.9.2+dfsg-6 ii libqt5dbus5 5.9.2+dfsg-6 ii libqt5gui5 5.9.2+dfsg-6 ii libqt5network5 5.9.2+dfsg-6 ii libqt5webenginecore5 5.9.2+dfsg-2 ii libqt5webenginewidgets5 5.9.2+dfsg-2 ii libqt5widgets5 5.9.2+dfsg-6 ii libqt5xml5 5.9.2+dfsg-6 ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 ii libstdc++6 7.2.0-18 kdepim-runtime recommends no packages. kdepim-runtime suggests no packages. -- no debconf information
Bug#881352: Bug 881352 (kernel oops with udisks2 upgrade): Good news!
Hello, I have bisected this oops and found the offending commit in the kernel sources. Now I'm trying to come up with a fix. André (or anybody else experiencing this bug), could you possibly test the fix (by patching and recompiling the kernel)? Also, out of curiosity, what's your system configuration, particularly: - memory configuration (eg. how much) - do you use an iommu - which block devices do you have? Particularly scsi devices, especially osd and pscsi devices. Regards Jiri Palecek
Bug#881352: kernel crash while upgrading udisks2
Hello, I got a similar crash as well (submitted through kerneloops). BT: [41523.485941] [ cut here ] [41523.485951] WARNING: CPU: 0 PID: 0 at /build/linux-d8soVg/linux-4.13.10/kernel/rcu/tree.c:2821 rcu_process_callbacks+0x43e/0x460 [41523.485953] Modules linked in: snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device cpufreq_powersave cpufreq_userspace cpufreq_conservative binfmt_misc fuse nvidia_drm(PO) drm_kms_helper drm nls_iso8859_2 snd_hda_codec_via snd_hda_codec_hdmi nls_cp437 snd_hda_codec_generic vfat fat nvidia_modeset(PO) snd_hda_intel snd_hda_codec snd_hda_core nvidia(PO) snd_hwdep snd_pcm_oss edac_mce_amd kvm_amd kvm snd_mixer_oss snd_pcm psmouse irqbypass snd_timer sr_mod snd cdrom soundcore pcspkr sg sata_nv ohci_pci k10temp ohci_hcd ehci_pci shpchp ehci_hcd forcedeth i2c_nforce2 asus_atk0110 button acpi_cpufreq usblp usbcore usb_common parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb crypto_simd cryptd aes_i586 sd_mod serio_raw ata_generic [41523.485987] pata_amd libata scsi_mod evdev [41523.485991] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P O 4.13.0-1-686-pae #1 Debian 4.13.10-1 [41523.485993] Hardware name: System manufacturer System Product Name/M4N68T-M, BIOS 1301 07/05/2011 [41523.485995] task: c77b0280 task.stack: c77a8000 [41523.485997] EIP: rcu_process_callbacks+0x43e/0x460 [41523.485998] EFLAGS: 00010002 CPU: 0 [41523.486000] EAX: EBX: f4271b00 ECX: 0002 EDX: 0001 [41523.486001] ESI: c77cb8c0 EDI: f4271b20 EBP: fff6 ESP: f3cabfa0 [41523.486002] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [41523.486004] CR0: 80050033 CR2: b444f014 CR3: 306acb00 CR4: 06f0 [41523.486005] Call Trace: [41523.486008] [41523.486012] ? __do_softirq+0xce/0x235 [41523.486014] ? __softirqentry_text_start+0x8/0x8 [41523.486016] ? do_softirq_own_stack+0x21/0x30 [41523.486017] [41523.486019] ? irq_exit+0xad/0xc0 [41523.486021] ? smp_apic_timer_interrupt+0x35/0x40 [41523.486023] ? apic_timer_interrupt+0x34/0x3c [41523.486025] ? native_safe_halt+0x2/0x10 [41523.486027] ? default_idle+0x19/0xf0 [41523.486029] ? do_idle+0x145/0x1c0 [41523.486031] ? cpu_startup_entry+0x65/0x70 [41523.486033] ? start_kernel+0x385/0x39c [41523.486035] ? startup_32_smp+0x16b/0x16d [41523.486036] Code: b3 7c c7 0f 8f 1a ff ff ff 8b 15 e0 b3 7c c7 89 53 64 e9 0c ff ff ff 8d b6 00 00 00 00 89 ea 89 f8 e8 e7 67 50 00 e9 61 fc ff ff <0f> ff e9 21 ff ff ff 0f ff e9 f4 fc ff ff e8 bf 8b f9 ff eb 0d [41523.486054] ---[ end trace 3dbeb3dfc6223f18 ]--- However, I wonder if this is the same as https://bugs.debian.org/876712. The backtrace points to softirq processing and rcu as well. I've got more of such backtraces (one of them, however, points to an assertion failure in rcu code). However, the problem seems sporadic in nature (some race condition causing a memory error?) and hard to reproduce. Please let me know if I can help in any way. Regards Jiri Palecek
Bug#877794: src:libreoffice: libreoffice FTBFS in experimental
Package: src:libreoffice
Severity: normal
Version: 1:5.4.2~rc2-1
Dear Maintainer,
building of the latest experimental version of libreoffice failed on
debian buildd on amd64 which is also used for arch-independent build.
The reason seems to be a test failure (from [1]):
/<>/chart2/qa/extras/chart2dump/chart2dump.cxx:831:ChartWallTest::verify
double equality assertion failed
- Expected: 5584
- Actual : 5955
- Delta : 350.1
- Failing test file is: chartwall_auto_adjust_with_titles.ods
ChartWallTest::verify finished in: 225ms
ColumnBarChartTest::verify finished in: 1765ms
AxisLabelTest::verify finished in: 1106ms
AxisGeometryTest::verify finished in: 1072ms
GridTest::verify finished in: 973ms
LegendTest::verify finished in: 2340ms
ChartDataTest::verify finished in: 698ms
chart2dump.cxx:831:Assertion
Test name: ChartWallTest::verify
double equality assertion failed
- Expected: 5584
- Actual : 5955
- Delta : 350.1
- Failing test file is: chartwall_auto_adjust_with_titles.ods
Failures !!!
Run: 11 Failure total: 1 Failures: 1 Errors: 0
Have a look into it, please.
Regards
Jiri Palecek
1:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=all=1%3A5.4.2~rc2-1=1506805013=0
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.13.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#867003: FTBFS of libgd2 due to test failures
Hello, I was looking at the recent FTBFS of libgd2, which prevented security fixes to reach debian archive for more than a week. The FTBFS were restricted to several architectures. By the look of it, it seems that the errors are simple arithmetical inaccuracies, when the tests expect pixel-exact results. I was specifically concerned about gdimagerotate/bug00067 test on i386, and the result of the rotate operation, while not comparing equal to the expected image, seemed the same to the naked eye. Slight differences of the computations on different architectures are to be expected, eg. if those architectures use different floating point formats, although it shouldn't matter that much in the test I mentioned (by rough estimate it should need a precision of about 1/2^18 -- 1/2^20, while IEE754 float is more precise than that). However, I was surprised that when I tested it with optimizations turned off, there were failures in the test suite too, but _different_ failures. This should mean there's something dodgy going on either in gcc or in the code. Anyway, I guess libgd2's aim isn't to provide pixel perfect image manipulations, but rather accessible image functions for eg. web servers in PHP. In that case, the testsuite doesn't really reflect the requirements it should fulfill, and it should focus more on security than accuracy. I would propose to ditch the testsuite completely from the building process of the package, since in its present state, it is inherently unreliable and would cause FTBFS. Instead, an autopkgtest testsuite could be made (with the running the same tests), which could be automatically ran using ci.debian.org. Such a testsuite could probably even be rigged to run under valgrind, which could catch some memory errors. At the same time, the testsuite could be made more lenient (or the library code more accurate), but that would require substantially more work and I don't know whether it would be desirable. Please let me know what you think. Regards Jiri Palecek
Bug#829753: Please consider fixing this bug
tags 829753 +patch thanks Hello, could you please check if this bug in autopkgtest can be fixed, now that you've made a new major version? Regards Jiri Palecek
Bug#876100: fixed in nvidia-graphics-drivers 375.82-4
On 21.9.2017 01:08, Andreas Beckmann wrote: On 20.09.2017 20:39, Jiri Palecek wrote: * Prevent mixing libgl1-nvidia-glx with libgl1-nvidia-glvnd-glx. * Use versioned Provides/Breaks/Replaces on the packages also built from src:libglvnd s.t. they cannot be satisfied by virtual packages provided from src:mesa (<< 17). (Closes: #875683, #876100) I don't understand. How does this solve issue 876100? The problem was that nvidia wasn't coinstallable with eg. libegl1-mesa-dev in its current version, and it is still so. Could you explain? I just tried again in a minimal sid chroot and didn't encounter any problems: # apt-get install --install-recommends nvidia-driver [...] (successfully installed) # apt-get install libglvnd-dev Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libglvnd-core-dev The following NEW packages will be installed: libglvnd-core-dev libglvnd-dev 0 upgraded, 2 newly installed, 0 to remove and 10 not upgraded. Need to get 0 B/16.3 kB of archives. After this operation, 80.9 kB of additional disk space will be used. Do you want to continue? [Y/n] [...] (successfully installed) # ls -lad $(dpkg -L libglvnd-dev) ls: cannot access 'diverted': No such file or directory ls: cannot access 'by': No such file or directory ls: cannot access 'glx-diversions': No such file or directory ls: cannot access 'to:': No such file or directory ls: cannot access 'diverted': No such file or directory ls: cannot access 'by': No such file or directory ls: cannot access 'glx-diversions': No such file or directory ls: cannot access 'to:': No such file or directory ls: cannot access 'diverted': No such file or directory ls: cannot access 'by': No such file or directory ls: cannot access 'glx-diversions': No such file or directory ls: cannot access 'to:': No such file or directory drwxr-xr-x 22 root root 440 Sep 20 22:51 /. drwxr-xr-x 10 root root 200 Mar 25 2013 /usr drwxr-xr-x 40 root root 880 Sep 20 22:54 /usr/lib lrwxrwxrwx 1 root root 15 Sep 12 07:32 /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so -> libEGL.so.1.0.0 lrwxrwxrwx 1 root root 14 Sep 12 07:32 /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so -> libGL.so.1.0.0 lrwxrwxrwx 1 root root 18 Sep 12 07:32 /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2.0.0 drwxr-xr-x 26 root root 9300 Sep 20 22:56 /usr/lib/x86_64-linux-gnu lrwxrwxrwx 1 root root 49 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libEGL.so -> /etc/alternatives/glx--libEGL.so-x86_64-linux-gnu lrwxrwxrwx 1 root root 48 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libGL.so -> /etc/alternatives/glx--libGL.so-x86_64-linux-gnu lrwxrwxrwx 1 root root 52 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libGLESv2.so -> /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu lrwxrwxrwx 1 root root 15 Sep 12 07:32 /usr/lib/x86_64-linux-gnu/libGLX.so -> libGLX.so.0.0.0 lrwxrwxrwx 1 root root 22 Sep 12 07:32 /usr/lib/x86_64-linux-gnu/libGLdispatch.so -> libGLdispatch.so.0.0.0 lrwxrwxrwx 1 root root 18 Sep 12 07:32 /usr/lib/x86_64-linux-gnu/libOpenGL.so -> libOpenGL.so.0.0.0 drwxr-xr-x 79 root root 1580 Sep 20 22:54 /usr/share drwxr-xr-x 397 root root 8640 Sep 20 22:56 /usr/share/doc drwxr-xr-x 2 root root 80 Sep 20 22:56 /usr/share/doc/libglvnd-dev -rw-r--r-- 1 root root 914 Sep 12 07:32 /usr/share/doc/libglvnd-dev/changelog.Debian.gz -rw-r--r-- 1 root root 4697 Sep 12 07:32 /usr/share/doc/libglvnd-dev/copyright # apt-get install libegl1-mesa-dev Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libdrm-dev libpthread-stubs0-dev libwayland-bin libwayland-dev libx11-dev libx11-xcb-dev libxau-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0 libxcb-randr0-dev libxcb-render0-dev libxcb-shape0 libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev libxcb1-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxshmfence-dev libxxf86vm-dev x11proto-core-dev x11proto-damage-dev x11proto-dri2-dev x11proto-fixes-dev x11proto-gl-dev x11proto-input-dev x11proto-kb-dev x11proto-xext-dev x11proto-xf86vidmode-dev xorg-sgml-doctools xtrans-dev Suggested packages: libxcb-doc libxext-doc Recommended packages: libx11-doc The following NEW packages will be installed: libdrm-dev libegl1-mesa-dev libpthread-stubs0-dev libwayland-bin libwayland-dev libx11-dev libx11-xcb-dev libxau-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0 libxcb-randr0-dev libxcb-render0-dev libxcb-shape0 libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev libxcb1-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxshmfence-dev libxxf86vm-dev x11proto-core-dev x11proto-damage-dev x11proto-dri2-dev x11proto-fixes-dev x
Bug#876100: fixed in nvidia-graphics-drivers 375.82-4
On 20.9.2017 08:51, Andreas Beckmann wrote: nvidia-graphics-drivers (375.82-4) unstable; urgency=medium . * Prevent mixing libgl1-nvidia-glx with libgl1-nvidia-glvnd-glx. * Use versioned Provides/Breaks/Replaces on the packages also built from src:libglvnd s.t. they cannot be satisfied by virtual packages provided from src:mesa (<< 17). (Closes: #875683, #876100) I don't understand. How does this solve issue 876100? The problem was that nvidia wasn't coinstallable with eg. libegl1-mesa-dev in its current version, and it is still so. Could you explain? Regards Jiri Palecek
Bug#868429: gstreamer1.0-vaapi version 12.2.3 is uninstallable
reopen 868429 found 868429 1.12.3-1 thanks Hello, the same problem now exists with version 1.12.3-1, which depends on libgstreamer-plugins-bad1.0-0 (< 1.12.3). Regards Jiri Palecek
Bug#876028: Bug 876028
This is just a matter of a simple rebuild, and all is well. Such things happen in experimental (I hope libqpdf won't change it's symbol version while in unstable). Regards Jiri Palecek
Bug#876100: libglvnd-dev: libglvnd-dev not coinstallable with nvidia packages
Package: libglvnd-dev Severity: normal Dear Maintainer, libglvnd depends on many OpenGL related packages like libgl1, specified by concrete version. This means those dependencies can't be satisfied with virtual packages, ie. nvidia packages providing libgl1. However, those nvidia packages conflict with any other packages providing those names, particularly libgl1 et al. provided by libglvnd. In effect, this makes development packages like - libegl1-mesa-dev - libsdl2-dev - qtbase5-dev uninstallable on systems with nvidia packages installed. This restriction didn't exist with mesa packages older than 17.2.0. Please check if that conflict can be rectified, either on the libglvnd-dev side, or the nvidia packages (CC-d). Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.13.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#875677: devscripts: mk-build-deps creates the build-dep package in the wrong directory
Package: devscripts Version: 2.17.9 Severity: normal File: /usr/bin/mk-build-deps Dear Maintainer, -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- DEBUILD_DPKG_BUILDPACKAGE_OPTS=-sa DEBUILD_PRESERVE_ENVVARS=CC,CXX,DEB_BUILD_OPTIONS while making a build-dep package, mk-build-deps writes: dpkg-deb: vytvářím balík ,,kwin-build-deps" v ,,../kwin-build-deps_5.10.5-2_i386.deb". The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! However, the generated package is not in the current directory as stated, nor in the parent directory, but in $TMP. Please fix that, or the message. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.13.0-rc7-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.18.24 ii libc6 2.24-17 ii libfile-homedir-perl 1.00-1 ii perl 5.26.0-8 ii python3 3.5.3-3 Versions of packages devscripts recommends: ii apt 1.5~rc1 ii at 3.1.20-3 ii curl7.55.1-1 ii dctrl-tools 2.24-2+b1 pn debian-keyring ii dput0.9.6.3 ii equivs 2.1.0 ii fakeroot1.22-1 ii file1:5.32-1 ii gnupg 2.2.0-3 ii libdistro-info-perl 0.17 ii libdpkg-perl1.18.24 ii libencode-locale-perl 1.05-1 pn libgit-wrapper-perl pn liblist-compare-perl ii liblwp-protocol-https-perl 6.07-1 ii libsoap-lite-perl 1.20-1 ii liburi-perl 1.72-1 ii libwww-perl 6.15-1 ii licensecheck3.0.30-1 ii lintian 2.5.52 ii man-db 2.7.6.1-2 ii patch 2.7.5-1+b2 ii patchutils 0.3.4-2 ii python3-debian 0.1.30 ii python3-magic 1:5.32-1 pn python3-unidiff ii sensible-utils 0.0.10 ii strace 4.15-2 ii unzip 6.0-21 ii wdiff 1.2.2-1+b1 ii wget1.19.1-3 ii xz-utils5.2.2-1.2+b1 Versions of packages devscripts suggests: pn adequate ii autopkgtest 4.4+nmu2 pn bls-standalone ii bsd-mailx [mailx]8.1.2-0.20160123cvs-4 ii build-essential 12.3 pn check-all-the-things pn cvs-buildpackage ii devscripts-el36.3 ii diffoscope 86 pn disorderfs ii dose-extra 3.1.3-4 pn duck pn faketime pn gnuplot ii gpgv 2.2.0-3 pn how-can-i-help pn libauthen-sasl-perl pn libfile-desktopentry-perl pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3000-2 ii libyaml-syck-perl1.29-1+b3 ii mozilla-devscripts 0.47 ii mutt 1.8.3+neomutt20170609-2+b1 ii openssh-client [ssh-client] 1:7.5p1-10 pn piuparts ii quilt0.63-8.1 pn ratt pn reprotest pn svn-buildpackage ii w3m 0.5.3-34 -- no debconf information
Bug#875678: emacs25-common: Lisp error when loading js2-mode
Package: emacs25-common
Version: 25.2+1-6
Severity: normal
File: /usr/share/emacs/25.2/lisp/progmodes/js.elc
Dear Maintainer,
I'm getting a strange lisp error when opening a desktop session which
contains a JS file. The error message is:
Debugger entered--Lisp error: (void-variable sgml-name-re)
(concat "\\|/>")
(defconst js--jsx-end-tag-re (concat "\\|/>")
("/usr/share/emacs/25.2/lisp/progmodes/js.elc" . 55920))
require(js)
byte-code("\301\302!\210\301\303!\210\301\304!\210\301\305!\210\306\307\"\203 \301\310!\210\2028\311\312\313\314#\210\315\316\317\"\210\315\320\321\"\210\315\322\323\"\210\315\324\325\"\210\314\207"
[emacs-version require cl-lib imenu js etags version< "25.0" js2-old-indent
defvaralias js2-basic-offset js-indent-level nil defalias
js2-proper-indentation js--proper-indentation js2-jsx-indent-line
js-jsx-indent-line js2-indent-line js-indent-line js2-re-search-forward
js--re-search-forward] 4)
autoload-do-load((autoload "js2-mode" "Major mode for editing JavaScript
code.\n\n(fn)" t nil) js2-mode)
desktop-load-file(js2-mode)
desktop-create-buffer(208
"/home/jirka/autopatchwork/AutoPatchWork.safariextension/js/Storage.js"
"Storage.js" js2-mode (font-lock-mode auto-revert-mode icicle-mode) 812 (74
nil) nil nil ((buffer-file-coding-system . undecided-unix)) ((mark-ring (812
The complaint about undefined sgml-name-re is strange, because js.el(c)
does indeed require sgml-mode and sgml-mode.el(c) contains definition of
sgml-name-re. Is there anything else that could be wrong?
Regards
Jiri Palecek
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.13.0-rc7-686-pae (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages emacs25-common depends on:
ii emacsen-common 2.0.8
ii install-info6.4.90.dfsg.1-1+b1
Versions of packages emacs25-common recommends:
pn emacs25-el
Versions of packages emacs25-common suggests:
ii emacs25-common-non-dfsg 25.2+1-1
ii ncurses-term 6.0+20170902-1
-- no debconf information
Bug#875620: aufs-dkms: Please enable compilation with kernel 4.13
Package: aufs-dkms Version: 4.12+20170904-1 Severity: wishlist Dear Maintainer, I tried aufs with kernel 4.13-rc7 from experimental and it seems to compile and work well. Please consider enabling this kernel in dkms.conf. Thanks Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.13.0-rc7-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aufs-dkms depends on: ii dkms 2.3-3 ii linux-kbuild-4.12 4.12.6-1 Versions of packages aufs-dkms recommends: ii aufs-tools 1:4.1+20161219-1 Versions of packages aufs-dkms suggests: pn aufs-dev -- no debconf information -- debsums errors found: debsums: changed file /usr/src/aufs-4.12+20170904/dkms.conf (from aufs-dkms package)
Bug#829753: autopkgtest-virt-qemu and "copyup ... failed" after failed tar
Hello, this problem has been bugging me for some time so I tried to dissect it using strace, and eventually, I was lucky. The problem is with the code that transfers data from the testbed to the host. The relevant part of the trace is: read(4, "3\"\n\t\t (literal (question-an"..., 100) = 466944 mremap(0xb4e16000, 1003520, 471040, MREMAP_MAYMOVE) = 0xb4e16000 munmap(0xb4f0b000, 4096)= 0 write(1, "3\"\n\t\t (literal (question-an"..., 466944) = 466944 mmap2(NULL, 1003520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb4f0b000 read(4, " to remove any fcrontab, and\n "..., 100) = 100 munmap(0xb4e16000, 471040) = 0 write(1, " to remove any fcrontab, and\n "..., 100) = 100 munmap(0xb4f0b000, 1003520) = 0 madvise(0xb5bff000, 8372224, MADV_DONTNEED) = 0 exit(0) = ? As you van see, the process read 100 bytes and then exited, although there would probably be more bytes available. IMHO that was because it was signaled (by setting the running flag) that it the testbed process has ended. I have created a patch that somewhat mitigates this race condition by ensuring all available data are read from the file before the running flag is checked. I need to test it more, but it seems to work so far. However, it could still fail if the data arrived in the file in the (small) window between the read and the check for the running flag, which could be set in that time as well. Regarding this whole auxverb thing and the shovel function, did you consider any other solutions, which could be more reliable? For example, I believe the files it actually uses are normal files, is that right? If it is, couldn't the output from the testbed be collected synchronously after the testbed has exited. Or, could named pipes be used instead, which would obviate the need to guess when the data end? Regards Jiri Palecek --- autopkgtest-normal/usr/bin/autopkgtest-virt-qemu 2017-04-30 19:09:57.0 +0200 +++ /mnt/extras/src/autopkgtest-4.4+nmu1/virt/autopkgtest-virt-qemu 2017-08-14 03:25:20.382311089 +0200 @@ -328,7 +328,7 @@ fcntl.fcntl(fin, fcntl.F_SETFL, fcntl.fcntl(fin, fcntl.F_GETFL) | os.O_NONBLOCK) count = 0 -while running: +while True: try: block = os.read(fin, 100) if flagfile_on_eof and not block: @@ -343,6 +343,8 @@ raise block = None if not block: +if not running: +return time.sleep(0.01) continue while True:
Bug#865614: aufs-dkms and liux 4.12
Hello now that we have linux 4.12 in unstable, please consider that the aufs package 4.11+20170703-1 (taken from git) refuses to build on this kernel. However, when I tweaked the dkms.conf file, it seems to compile and work (with schroot) well. Regards Jiri Palecek
Bug#833719: Reopen bug report
Hello On 10.8.2017 21:21, Alexander Brock wrote: After upgrading from stable to testing firefox started having the mentioned problem again. "firefox --version" gives me "Mozilla Firefox 50.1.0", apt tells me it is 50.1.0-1. Firefox has been out of testing for several months now, and version 50 is outdated. If you want to upgrade from stable, I'd suggest checking out version 55 in unstable or esr version 52 in testing. BTW: If you're having the mentioned problem, does the mentioned solution work as well? "uname -a" gives "Linux toothless 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux" The problem does not appear with firefox-esr=45.9.0esr-1 (amd64) The problem affects the following websites: https://www.google.com/ https://www.google.de/ https://wikimedia.org/ https://en.wikipedia.org/ https://www.mozilla.org/ https://www.youtube.com/ https://www.whatismyip.com/ No problems on these sites with unstable version. Regards Jiri Palecek
Bug#871642: notmuch: dependency on elpa-emacs doesn't seem right
Source: notmuch Severity: normal Version: 0.25-4 Dear Maintainer, reading the changelog of notmuch: * Recommend elpa-emacs instead emacs-notmuch That elpa-emacs doesn't seem quite right. Probably you meant elpa-notmuch, please update the package accordingly. Regards Jiri Palecek -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.11.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#870677: nvidia-kernel-dkms: Doesn't compile with kernel 4.11 (and probably later)
Package: nvidia-kernel-dkms Version: 378.13-1 Severity: normal Dear Maintainer, -- Package-specific info: uname -a: Linux debian 4.11.0-2-686-pae #1 SMP Debian 4.11.11-1 (2017-07-22) i686 GNU/Linux /proc/version: Linux version 4.11.0-2-686-pae (debian-ker...@lists.debian.org) (gcc version 6.4.0 20170704 (Debian 6.4.0-1) ) #1 SMP Debian 4.11.11-1 (2017-07-22) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86 Kernel Module 375.82 Wed Jul 19 20:16:02 PDT 2017 GCC version: gcc version 6.4.0 20170704 (Debian 6.4.0-1) lspci 'VGA compatible controller [0300]': 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS 450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Aug 3 17:55 /dev/dri/card0 crw-rw+ 1 root video 226, 128 Aug 3 17:55 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Aug 3 18:01 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Aug 3 18:01 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Aug 3 18:01 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Aug 3 17:55 pci-:02:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Aug 3 17:55 pci-:02:00.0-render -> ../renderD128 video:x:44: OpenGL and NVIDIA library files installed: -rw-r--r-- 1 root root 2167 May 13 2016 /etc/X11/xorg.conf lrwxrwxrwx 1 root root 15 Sep 25 2016 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 47 Jun 26 14:53 /etc/alternatives/glx--libEGL.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so lrwxrwxrwx 1 root root 42 Sep 25 2016 /etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 46 Jun 26 14:53 /etc/alternatives/glx--libGL.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so lrwxrwxrwx 1 root root 46 Jun 26 14:53 /etc/alternatives/glx--libGL.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so lrwxrwxrwx 1 root root 41 Sep 25 2016 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Sep 25 2016 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 48 Sep 25 2016 /etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 48 Sep 25 2016 /etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 50 Jun 26 14:53 /etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 50 Jun 26 14:53 /etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 45 Sep 25 2016 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2 lrwxrwxrwx 1 root root 45 Sep 25 2016 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2 lrwxrwxrwx 1 root root 49 Sep 25 2016 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Sep 25 2016 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Sep 25 2016 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Sep 25 2016 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Sep 25 2016 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Sep 25 2016 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 Sep 25 2016 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 Sep 25 2016 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 22 Jun 26 14:53 /etc/alternatives/libGL.so-master -> /usr/lib/mesa-diverted lrwxrwxrwx 1 root root 23 Aug 3 17:54 /etc/alternatives/nvidia -> /usr/lib/nvidia/current lrwxrwxrwx 1 root root 50 Aug 3 17:54 /etc/alternatives/nvidia--libEGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/current/libEGL.so.1 lrwxrwxrwx 1 root root
Bug#868429: gstreame1.0-vaapi bug is now fixed
notfound -1 1.12.2-1+b1 thanks Version 1.12.2-1+b1 is now coinstallable with other gstreamer packages of version 1.12.2, so all is well. Jiri Palecek
Bug#868758: libkf5gpgmepp-pthread5: gpgmepp doesn't support the gpgconf protocol
Package: libkf5gpgmepp-pthread5
Version: 16.04.3-2.1
Severity: normal
Dear Maintainer,
by looking at the build log for gpgme[1], it seems something is not
good:
-- Performing Test HAVE_GPGME_KEY_T_IS_QUALIFIED - Failed
-- Performing Test HAVE_GPGME_SIG_NOTATION_CRITICAL
-- Performing Test HAVE_GPGME_SIG_NOTATION_CRITICAL - Failed
-- Performing Test HAVE_GPGME_SIG_NOTATION_FLAGS_T
-- Performing Test HAVE_GPGME_SIG_NOTATION_FLAGS_T - Failed
-- Performing Test HAVE_GPGME_SIG_NOTATION_HUMAN_READABLE
-- Performing Test HAVE_GPGME_SIG_NOTATION_HUMAN_READABLE - Failed
-- Performing Test HAVE_GPGME_SUBKEY_T_IS_QUALIFIED
-- Performing Test HAVE_GPGME_SUBKEY_T_IS_QUALIFIED - Failed
-- Performing Test HAVE_GPGME_ENGINE_INFO_T_HOME_DIR
-- Performing Test HAVE_GPGME_ENGINE_INFO_T_HOME_DIR - Failed
-- Performing Test HAVE_GPGME_CTX_GETSET_ENGINE_INFO
-- Performing Test HAVE_GPGME_CTX_GETSET_ENGINE_INFO - Failed
-- Performing Test HAVE_GPGME_SIG_NOTATION_CLEARADDGET
-- Performing Test HAVE_GPGME_SIG_NOTATION_CLEARADDGET - Failed
-- Performing Test HAVE_GPGME_DECRYPT_RESULT_T_FILE_NAME
-- Performing Test HAVE_GPGME_DECRYPT_RESULT_T_FILE_NAME - Failed
-- Performing Test HAVE_GPGME_DECRYPT_RESULT_T_RECIPIENTS
-- Performing Test HAVE_GPGME_DECRYPT_RESULT_T_RECIPIENTS - Failed
-- Performing Test HAVE_GPGME_VERIFY_RESULT_T_FILE_NAME
-- Performing Test HAVE_GPGME_VERIFY_RESULT_T_FILE_NAME - Failed
-- Performing Test HAVE_GPGME_SIGNATURE_T_PKA_FIELDS
-- Performing Test HAVE_GPGME_SIGNATURE_T_PKA_FIELDS - Failed
-- Performing Test HAVE_GPGME_SIGNATURE_T_ALGORITHM_FIELDS
-- Performing Test HAVE_GPGME_SIGNATURE_T_ALGORITHM_FIELDS - Failed
-- Performing Test HAVE_GPGME_SIGNATURE_T_CHAIN_MODEL
-- Performing Test HAVE_GPGME_SIGNATURE_T_CHAIN_MODEL - Failed
-- Looking for gpgme_get_fdptr
-- Looking for gpgme_get_fdptr - not found
-- Looking for gpgme_op_getauditlog
-- Looking for gpgme_op_getauditlog - found
-- Performing Test HAVE_GPGME_PROTOCOL_GPGCONF
-- Performing Test HAVE_GPGME_PROTOCOL_GPGCONF - Failed
And indeed, kleopatra's selftest fails with message about missing
gpgconf protocol. I dug into the error logs of the configuration and it
seems all those tests fail because they don't get _FILE_OFFSET_BITS=64
defined. The following change to the cmake files fixes that, although
you could just delete the offending line altogether - KDE4_DEFINITIONS
is empty anyway.
Index: gpgmepp-16.04.3/src/ConfigureChecks.cmake
===
--- gpgmepp-16.04.3.orig/src/ConfigureChecks.cmake
+++ gpgmepp-16.04.3/src/ConfigureChecks.cmake
@@ -7,7 +7,7 @@ if ( GPGME_FOUND )
set(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES})
set(CMAKE_REQUIRED_LIBRARIES_SAVE ${CMAKE_REQUIRED_LIBRARIES})
set(CMAKE_REQUIRED_INCLUDES ${GPGME_INCLUDES})
-set(CMAKE_REQUIRED_DEFINITIONS ${KDE4_DEFINITIONS})
+set(CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS} ${KDE4_DEFINITIONS})
set(CMAKE_REQUIRED_LIBRARIES)
foreach( _FLAVOUR VANILLA PTHREAD QT PTH GLIB )
if ( NOT CMAKE_REQUIRED_LIBRARIES )
With gpgmepp thus rebuilt, kleopatra whines no more.
Regards
Jiri Palecek
1:
https://buildd.debian.org/status/fetch.php?pkg=gpgmepp=i386=16.04.3-2%2Bb2=1489868595=0
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.11.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libkf5gpgmepp-pthread5 depends on:
ii libc6 2.24-12
ii libgcc1 1:7.1.0-9
ii libgpgme111.8.0-3+b3
ii libqt5core5a 5.7.1+dfsg-3.5
ii libstdc++67.1.0-9
libkf5gpgmepp-pthread5 recommends no packages.
libkf5gpgmepp-pthread5 suggests no packages.
-- no debconf information
Bug#861181: quilt-el: quilt-find-dir goes to endless recursion if root is not '/'
Package: quilt-el
Version: 0.63-8
Severity: normal
Dear Maintainer,
I use quilt-mode and when I try to open a file through tramp
(eg. /su::/etc/init.d/something), I get an error "variable binding depth
exceeds max-specpdl-size"). Having achieved breaking emacs while on this
runaway recursion, I discovered it was in fact quilt that was the
culprit:
tramp-make-tramp-file-name("su" #("root" 0 4 (tramp-default t)) "debian"
"/.pc" nil)
tramp-sh-handle-expand-file-name(#("/su:root@debian:/.pc" 4 8 (tramp-default
t)) #("/su:root@debian:/etc/init.d/" 4 8 (tramp-default t)))
apply(tramp-sh-handle-expand-file-name (#("/su:root@debian:/.pc" 4 8
(tramp-default t)) #("/su:root@debian:/etc/init.d/" 4 8 (tramp-default t
tramp-sh-file-name-handler(expand-file-name #("/su:root@debian:/.pc" 4 8
(tramp-default t)) #("/su:root@debian:/etc/init.d/" 4 8 (tramp-default t)))
apply(tramp-sh-file-name-handler expand-file-name (#("/su:root@debian:/.pc" 4
8 (tramp-default t)) #("/su:root@debian:/etc/init.d/" 4 8 (tramp-default t
tramp-file-name-handler(expand-file-name #("/su:root@debian:/.pc" 4 8
(tramp-default t)) #("/su:root@debian:/etc/init.d/" 4 8 (tramp-default t)))
file-directory-p(#("/su:root@debian:/.pc" 4 8 (tramp-default t)))
tramp-handle-file-accessible-directory-p(#("/su:root@debian:/.pc" 4 8
(tramp-default t)))
apply(tramp-handle-file-accessible-directory-p #("/su:root@debian:/.pc" 4 8
(tramp-default t)))
tramp-sh-file-name-handler(file-accessible-directory-p
#("/su:root@debian:/.pc" 4 8 (tramp-default t)))
apply(tramp-sh-file-name-handler file-accessible-directory-p
#("/su:root@debian:/.pc" 4 8 (tramp-default t)))
tramp-file-name-handler(file-accessible-directory-p #("/su:root@debian:/.pc"
4 8 (tramp-default t)))
file-accessible-directory-p(#("/su:root@debian://.pc" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
quilt-find-dir(#("/su:root@debian:/" 4 8 (tramp-default t)))
While researching this, I found that this was in fact fixed in 2015! [1]
Quilt 0.63 is 3 years old now, please consider packaging 0.65.
Regards
Jiri palecek
[1]: https://lists.nongnu.org/archive/html/quilt-dev/2015-01/msg00017.html
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: i386
(i686)
Kernel: Linux 4.9.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages quilt-el depends on:
ii emacs 47.0~exp1
ii emacs25 [emacsen] 25.1+1-3+b1
ii quilt 0.63-8
quilt-el recommends no packages.
quilt-el suggests no packages.
-- no debconf information
Bug#858997: debsecan: I'm getting emails from debsecan indicating unhandled exceptions
Package: debsecan Version: 0.4.18 Severity: normal Dear Maintainer, after I installed debsecan, fcron sends me mail about debsecan being terminated abnormally. Normal debsecan mail still arrives. The message is: Traceback (most recent call last): File "/usr/bin/debsecan", line 1380, in rate_system(target, options, fetch_data(options, config), history) File "/usr/bin/debsecan", line 1359, in rate_system formatter.finish() File "/usr/bin/debsecan", line 1215, in finish self._write_history(self.options.history) File "/usr/bin/debsecan", line 953, in _write_history os.rename(new_name, name) OSError: [Errno 2] No such file or directory Job test -x /usr/bin/debsecan && /usr/bin/debsecan --cron terminated (exit status: 1) (mailing output) Could you please look into it? Regards Jiri Palecek -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.9.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debsecan depends on: ii ca-certificates 20161130 ii cdebconf [debconf-2.0] 0.220 ii debconf [debconf-2.0] 1.5.60 ii python 2.7.13-1 ii python-apt 1.4.0~beta2 Versions of packages debsecan recommends: ii esmtp-run [mail-transport-agent] 1.2-14 ii fcron [cron] 3.0.1-1.4 debsecan suggests no packages. -- debconf information: * debsecan/mailto: jirka * debsecan/source: * debsecan/report: true * debsecan/suite: sid
Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly
On 14.3.2017 01:02, Jiri Palecek wrote:
On 13.3.2017 22:57, Simon McVittie wrote:
On Mon, 13 Mar 2017 at 21:58:17 +0100, Carsten Schoenert wrote:
I had modified the warpper script in the between time a little bit
different. I've done some more effort to catch some special arguments
and get them savely prepared to the binary call.
There are for sure more than one way to get the argument passing done.
+if [[ "${ARG}" =~ ([[:space:]]|[(,|=)]) ]]; then
+TB_ARGS="${TB_ARGS} \"${ARG}\""
+else
+# No special handling needed.
+TB_ARGS="${TB_ARGS} ${ARG}"
...
+eval "${MOZ_LIBDIR}"/"${MOZ_APP_NAME}" "${TB_ARGS}"
No, that is not general and could be a security vulnerability. Consider
what would happen with an argument containing $ or ` or backslashes.
If a quoting approach is to be preferred (possibly to make the script
POSIX-compliant without bashisms), then the easiest (general) way is
to quote it with apostrophes:
TB_ARGS="${TB_ARGS} '$(echo "$ARG" | sed "s/'/'\\\''/")'"
Bummer. sed expression must have /g flag:
TB_ARGS="${TB_ARGS} '$(echo "$ARG" | sed "s/'/'\\\''/g")'"
Sorry
Jiri Palecek
