Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Package: inkscape Version: 1.2.2-2+b1 Followup-For: Bug #1034289 Additional information: the issue I'm seeing seems to match upstream issue #3664 https://gitlab.com/inkscape/inkscape/-/issues/3664 and seems to be related to a GTK bug when GTK_IM_MODULE=xim Unsetting the variable or testing one of the values recommended in the comments to the bug solves the issue for me.
Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Package: inkscape Version: 1.2.2-2+b1 Severity: serious Adding or editing a text box causes the canvas to stop updating altogether. Writing, selecting, etc still works, but the canvas does not refresh anymore until Inkscape is closed and reopened. This is also with the Preferences > Rendering > Update strategy set to "Full redraw". -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii lib2geom1.2.0 1.2.2-3 ii libatkmm-1.6-1v5 2.28.3-1 ii libboost-filesystem1.74.0 1.74.0+ds1-20 ii libc6 2.36-9 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libcairomm-1.0-1v5 1.14.4-2 ii libcdr-0.1-1 0.1.6-2+b2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-4 ii libgc1 1:8.2.2-3 ii libgcc-s1 12.2.0-14 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libglibmm-2.4-1v5 2.66.5-2 ii libgomp1 12.2.0-14 ii libgsl27 2.7.1+dfsg-3+b1 ii libgspell-1-2 1.12.0-1+b2 ii libgtk-3-0 3.24.37-2 ii libgtkmm-3.0-1v5 3.24.7-1 ii libharfbuzz0b 6.0.0+dfsg-3 ii libjpeg62-turbo1:2.1.5-2 ii liblcms2-2 2.14-2 ii libmagick++-6.q16-88:6.9.11.60+dfsg-1.6 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-01.50.12+ds-1 ii libpangoft2-1.0-0 1.50.12+ds-1 ii libpangomm-1.4-1v5 2.46.3-1 ii libpng16-161.6.39-2 ii libpoppler-glib8 22.12.0-2+b1 ii libpoppler126 22.12.0-2+b1 ii libpotrace01.16-2 ii libreadline8 8.2-1.3 ii librevenge-0.0-0 0.0.5-3 ii librsvg2-common2.54.5+dfsg-1 ii libsigc++-2.0-0v5 2.12.0-1 ii libsoup2.4-1 2.74.3-1 ii libstdc++6 12.2.0-14 ii libvisio-0.1-1 0.1.7-1+b3 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.8.4-2 ii libxml22.9.14+dfsg-1.1+b3 ii libxslt1.1 1.1.35-1 ii python33.11.2-1+b1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages inkscape recommends: ii aspell 0.60.8-4+b1 ii fig2dev 1:3.2.8b-3 ii imagemagick 8:6.9.11.60+dfsg-1.6 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.6 ii imagemagick-7 [imagemagick] 8:7.1.1.6-dmo1 ii libimage-magick-perl 8:6.9.11.60+dfsg-1.6 ii libwmf-bin 0.2.12-5 ii python3-cssselect1.2.0-2 ii python3-lxml 4.9.2-1+b1 ii python3-numpy1:1.24.2-1 ii python3-scour0.38.2-2 Versions of packages inkscape suggests: ii dia 0.97.3+git20220525-5 pn inkscape-tutorials pn libsvg-perl ii pstoedit 3.78-2 ii python3-packaging 23.0-1 pn python3-uniconvertor ii ruby 1:3.1 -- no debconf information
Bug#994833: OpenCL programs abort when intel-opencl-icd is installed
On Wed, Sep 22, 2021 at 8:32 AM Andreas Beckmann wrote:
> So if it does matter abi-wise for intel-opencl-icd which version of llvm
> libigfoo1 was compiled against, we should model this in the dependency
> chain.
To be able to confirm this, I would need a version of all the libig*
stuff correctly
compiled against LLVM12 (rather than the mix-up we currently have for
libigdfcl1).
I can then test against intel-opencl-icd version 20.x, which is built
with LLVM11,
and (most probably) confirm that the setup is broken.
> It's probably best if all libigfoo1 library packages provide a virtual
> package libigfoo1-llvmXX (don't hardcode it, use substvars) and
> intel-opencl-icd depends on that (in addition to libigfoo1 (>= xx)) to
> specify the specific abi needed.
> (renaming the real package to libigfoo1-llvmXX each time the llvm major
> version changes is probably overkill)
The virtual ABI package sounds like the best choice.
I don't think renaming the real package makes sense,
at least at the moment. It might become useful if there ever is a need
for the different ABIs to be co-installed.
> Are there other users of libigfoo1 besides intel-opencl-icd?
The only one I can see is intel-media-va-driver{,-non-free} depending
on libigdgmm11,
but that particular package doesn't seem to have an LLVM dependency
(directly or not).
> We will proably still run into problems if different ICDs built against
> different LLVM versions are going to be loaded at the same time (e.g.
> pocl/llvm9 and intel/llvm1x) because the different llvm versions seem to
> stomp on each others internal bits. There are bugs open about that ...
FWIW, I haven't had these issues in a while now
(but I'm also building my own pocl, so maybe by chance I'm using the
same LLVM version anyway.)
> I may come up with a patch if time permits.
Much appreciated.
--
Giuseppe "Oblomov" Bilotta
Bug#994833: OpenCL programs abort when intel-opencl-icd is installed
Package: intel-opencl-icd Followup-For: Bug #994833 Downgrading ONLY intel-opencl-icd to version 20.44.18297-1 leads to a different error: Abort was called at 41 line in file: /build/intel-compute-runtime-7vSeZ9/intel-compute-runtime-20.44.18297/shared/source/built_ins/built_ins.cpp Aborted Downgrading ALSO libigc1 and libigdfcl1 to version 1.0.5353.1-2 makes the package usable again. This makes me suspect that the issue is in those libraries instead. Running clinfo with OCL_ICD_VENDORS=/etc/OpenCL/vendors/intel.icd LD_DEBUG=libs gives me the following = 342713: find library=libOpenCL.so.1 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libOpenCL.so.1 342713: 342713: find library=libdl.so.2 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libdl.so.2 342713: 342713: find library=libc.so.6 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libc.so.6 342713: 342713: 342713: calling init: /lib64/ld-linux-x86-64.so.2 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libc.so.6 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libdl.so.2 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 342713: 342713: 342713: initialize program: clinfo 342713: 342713: 342713: transferring control: clinfo 342713: 342713: find library=libpthread.so.0 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libpthread.so.0 342713: 342713: find library=libigdgmm.so.11 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libigdgmm.so.11 342713: 342713: find library=libstdc++.so.6 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 342713: 342713: find library=libm.so.6 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libm.so.6 342713: 342713: find library=libgcc_s.so.1 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libgcc_s.so.1 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libpthread.so.0 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libgcc_s.so.1 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libm.so.6 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libstdc++.so.6 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libigdgmm.so.11 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so 342713: 342713: find library=libigfxdbgxchg64.so [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libigfxdbgxchg64.so 342713: 342713: find library=libigfxdbginfo.so [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libigfxdbginfo.so 342713: 342713: find library=libelfdwarf.so [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libelfdwarf.so 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libelfdwarf.so 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libigfxdbginfo.so 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libigfxdbgxchg64.so 342713: 342713: find library=libigdml.so.1 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: search
Bug#994833: OpenCL programs abort when intel-opencl-icd is installed
=0x7fffcf28) at ./opencl/source/api/api.cpp:137 #19 0x77f439f4 in _find_and_check_platforms (num_icds=7) at ocl_icd_loader.c:469 #20 __initClIcd () at ocl_icd_loader.c:773 #21 _initClIcd_real () at ocl_icd_loader.c:824 #22 0x77f4474e in _initClIcd () at ocl_icd_loader.c:853 #23 clGetPlatformIDs (num_entries=0, platforms=0x0, num_platforms=0x7fffe034) at ocl_icd_loader.c:1014 The issue is present also when intel-opencl-icd is the only installed ICD. I used to be able to use the ICD without issues on this machine. I'm not sure which upgrade broke it (in particulr, I'm not sure if this was broken by an upgrade of this package or by a kernel upgrade). Cheers, Giuseppe Bilotta -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages intel-opencl-icd depends on: ii libc6 2.32-4 ii libgcc-s1 11.2.0-7 ii libigc1 1.0.8279-1 ii libigdfcl1 1.0.8279-1 ii libigdgmm11 21.2.2+ds1-1 ii libstdc++6 11.2.0-7 ii ocl-icd-libopencl1 2.2.14-2 intel-opencl-icd recommends no packages. intel-opencl-icd suggests no packages. -- no debconf information
Bug#974702: intel-opencl-icd causes all OpenCL programs to abort
On Sat, Nov 14, 2020 at 9:46 AM Timo Aaltonen wrote: > Hi, please try with the current version, I think this was due to the old > driver being built with llvm10. 20.44 was uploaded yesterday. > And 972620 should be fixed as well. Hello, I just tested intel-opencl-icd 20.44.18297-1 with libigc1 and libigdfcl1 at version 1.0.5353.1-2 and indeed both bugs seem to be fixed. (I'd be wary of the code still calling abort in case of issues, though, since an ICD should just fail “properly” when things go wrong during init.) Thanks a lot, Giuseppe Bilotta -- Giuseppe "Oblomov" Bilotta
Bug#974702: intel-opencl-icd causes all OpenCL programs to abort
Package: intel-opencl-icd Followup-For: Bug #974702 Some additional information: I have tried downgrading to previous versions of the package, and I found out that: intel-opencl-icd 20.13.16352-1 has the issue intel-opencl-icd 20.02.15268-1 has not In fact, with 20.02 clinfo at least works, even though kernels fail to compile for this ICD giving a CL_OUT_OF_HOST_MEMORY (-6) error. If I downgrate libigc1 and libigdfcl1 to 1.0.3627-2, both 20.02 and 20.13 work correctly, but 20.37.17906-1 still aborts. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages intel-opencl-icd depends on: ii libc62.31-4 ii libgcc-s1 [libgcc1] 10.2.0-17 ii libigc1 1.0.5353.1-2 ii libigdfcl1 1.0.5353.1-2 ii libigdgmm11 20.3.2+ds1-1 ii libstdc++6 10.2.0-17 ii ocl-icd-libopencl1 2.2.12-4 intel-opencl-icd recommends no packages. intel-opencl-icd suggests no packages. -- no debconf information
Bug#974702: intel-opencl-icd causes all OpenCL programs to abort
Package: intel-opencl-icd
Version: 20.37.17906-1
Severity: critical
When this package is installed, any OpenCL program will abort with the
message
Abort was called at 42 line in file:
/build/intel-compute-runtime-WsWnhf/intel-compute-runtime-20.37.17906/shared/source/built_ins/built_ins.cpp
Application Error
This is reproducible with a simple `clinfo -l`, but even something like
LibreOffice with OpenCL support enabled will fail to start (making it
impossible to actually even the LibreOffice configuration to disable
OpenCL), which is the reason for the critical severity.
Running `clinfo -l` under gdb shows the following backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x77da6537 in __GI_abort () at abort.c:79
#2 0x76baab53 in NEO::abortExecution () at
./shared/source/helpers/abort.cpp:14
#3 0x76bc0b71 in NEO::abortUnrecoverable (line=line@entry=42,
file=file@entry=0x76f1b868
"/build/intel-compute-runtime-WsWnhf/intel-compute-runtime-20.37.17906/shared/source/built_ins/built_ins.cpp")
at ./shared/source/helpers/debug_helpers.cpp:24
#4 0x76ed07b4 in operator() (__closure=0x7fffdd60) at
./shared/source/built_ins/built_ins.cpp:42
#5 std::__invoke_impl&> (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#6 std::__invoke&> (__fn=...) at /usr/include/c++/10/bits/invoke.h:95
#7 operator() (this=) at /usr/include/c++/10/mutex:717
#8 operator() (this=0x0) at /usr/include/c++/10/mutex:722
#9 _FUN () at /usr/include/c++/10/mutex:722
#10 0x7710b34f in __pthread_once_slow (once_control=0x55786400,
init_routine=0x77495fc0 <__once_proxy>) at pthread_once.c:116
#11 0x76ed0ae2 in __gthread_once (__func=,
__once=0x55786400) at
/usr/include/x86_64-linux-gnu/c++/10/bits/gthr-default.h:700
#12 std::call_once&> (__f=..., __once=...) at
/usr/include/c++/10/mutex:729
#13 NEO::BuiltIns::getSipKernel (this=0x55785ff0, type=,
device=...) at ./shared/source/built_ins/built_ins.cpp:64
#14 0x76be2516 in NEO::initSipKernel (type=, device=...)
at ./opencl/source/helpers/built_ins_helper.cpp:16
#15 0x76c29878 in NEO::Platform::initialize (this=0x557841b0,
devices=std::vector of length 1, capacity 1 = {...}) at
./opencl/source/platform/platform.cpp:145
#16 0x76bdc85d in clGetPlatformIDs (numEntries=,
platforms=, numPlatforms=) at
./opencl/source/api/api.cpp:100
#17 0x76bdce54 in clIcdGetPlatformIDsKHR (numEntries=0, platforms=0x0,
numPlatforms=0x7fffe04c) at ./opencl/source/api/api.cpp:136
#18 0x77f51ae3 in _find_and_check_platforms (num_icds=5) at
ocl_icd_loader.c:445
#19 __initClIcd () at ocl_icd_loader.c:652
#20 _initClIcd_real () at ocl_icd_loader.c:702
#21 0x77f524e3 in _initClIcd () at ocl_icd_loader.c:724
#22 clGetPlatformIDs (num_entries=0, platforms=0x0,
num_platforms=0x7fffe170) at ocl_icd_loader.c:846
#23 0x55564d42 in main (argc=2, argv=0x7fffe2d8) at
src/clinfo.c:3351
Note that no OpenCL ICD should _ever_ invoke abort: OpenCL has specific
ways to pass failure information up to the caller, those shold be used
instead.
(That aside, it's unclear why the failure even happens in the first
place.)
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages intel-opencl-icd depends on:
ii libc6 2.31-4
ii libgcc-s1 10.2.0-17
ii libigc1 1.0.5353.1-2
ii libigdfcl1 1.0.5353.1-2
ii libigdgmm11 20.3.2+ds1-1
ii libstdc++6 10.2.0-17
ii ocl-icd-libopencl1 2.2.12-4
intel-opencl-icd recommends no packages.
intel-opencl-icd suggests no packages.
-- no debconf information
Bug#964335: linux-headers-amd64: cannot upgrade to 5.7.6-1
Package: linux-headers-amd64
Version: 5.6.14-2
Severity: serious
Try to upgrade linux-headers-amd64, linux-image-amd64 and linux-perf to
version 5.7.6-1 results in the following errors:
Preparing to unpack .../15-linux-headers-amd64_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file
'/usr/share/doc/linux-headers-amd64/copyright' not owned by package
'linux-headers-amd64'
dpkg-maintscript-helper: error: file
'/usr/share/doc/linux-headers-amd64/changelog.gz' not owned by package
'linux-headers-amd64'
dpkg-maintscript-helper: error: directory
'/usr/share/doc/linux-headers-amd64' contains files not owned by package
linux-headers-amd64, cannot switch to symlink
dpkg: error processing archive
/tmp/apt-dpkg-install-zTcKDN/15-linux-headers-amd64_5.7.6-1_amd64.deb
(--unpack):
new linux-headers-amd64 package pre-installation script subprocess
returned error exit status 1
Preparing to unpack .../16-linux-image-amd64_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file
'/usr/share/doc/linux-image-amd64/NEWS.Debian.gz' not owned by package
'linux-image-amd64'
dpkg-maintscript-helper: error: file
'/usr/share/doc/linux-image-amd64/copyright' not owned by package
'linux-image-amd64'
dpkg-maintscript-helper: error: file
'/usr/share/doc/linux-image-amd64/changelog.gz' not owned by package
'linux-image-amd64'
dpkg-maintscript-helper: error: directory
'/usr/share/doc/linux-image-amd64' contains files not owned by package
linux-image-amd64, cannot switch to symlink
dpkg: error processing archive
/tmp/apt-dpkg-install-zTcKDN/16-linux-image-amd64_5.7.6-1_amd64.deb (--unpack):
new linux-image-amd64 package pre-installation script subprocess returned
error exit status 1
Preparing to unpack .../17-linux-perf_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file '/usr/share/doc/linux-perf/copyright'
not owned by package 'linux-perf'
dpkg-maintscript-helper: error: file
'/usr/share/doc/linux-perf/changelog.gz' not owned by package 'linux-perf'
dpkg-maintscript-helper: error: directory '/usr/share/doc/linux-perf'
contains files not owned by package linux-perf, cannot switch to symlink
dpkg: error processing archive
/tmp/apt-dpkg-install-zTcKDN/17-linux-perf_5.7.6-1_amd64.deb (--unpack):
new linux-perf package pre-installation script subprocess returned error
exit status 1
Note that the dependencies linux-headers-5.7.0-1-{amd64,common},
linux-image-5.7.0-1-amd64, linux-perf-5.7 have all been upgrade to
5.7.6-1, it's only the versionless one that fail.
(I'm not sure how to tag this as also affecting the linux-image-amd64 and
linux-perf packages, sorry.)
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-headers-amd64 depends on:
ii linux-headers-5.6.0-2-amd64 5.6.14-2
linux-headers-amd64 recommends no packages.
linux-headers-amd64 suggests no packages.
-- no debconf information
Bug#940902: doesn't read the data
Package: cycle Version: 0.3.1-16 Followup-For: Bug #940902 I'm experiencing this issue as well. For debugging purposes, I moved the previous .cycle directory out of the way, created a new user, saved, and on restart it asked me to create a new user again —despite having created the new profile. So the bug is present even for data file created in the new version, not only when trying to read old data. -- Giuseppe "Oblomov" Bilotta -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cycle depends on: ii python3 3.7.3-1 ii python3-wxgtk4.0 4.0.6+dfsg-2 cycle recommends no packages. cycle suggests no packages. -- no debconf information
Bug#940651: cycle: package installation fails at configuration stage due to TabError
Package: cycle Version: 0.3.1-15 Severity: serious Upgrading cycle to the latest version in unstable leads to the following error during configuration: Sorry: TabError: inconsistent use of tabs and spaces in indentation (cycle.py, line 29) This is due to the mix of 4 spaces for one level of indent vs 1 tab for two levels, which is not supported in Python3. Best regards, Giuseppe Bilotta -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cycle depends on: ii python3 3.7.3-1 ii python3-wxgtk4.0 4.0.6+dfsg-2 cycle recommends no packages. cycle suggests no packages. -- no debconf information
Bug#781875: beignet: [regression] broken on Haswell
On Fri, Apr 17, 2015 at 11:16 PM, Rebecca N. Palmer rebecca_pal...@zoho.com wrote: now every kernel invocation, regardless of arguments counts and array sizes, fails i.e. including ones that worked in 1.0.2-1? Yes. Do they use the 'local' memory space (which triggers a third known bug on Haswell)? No, even the most trivial inits that simply writes to gmem fails the same way. drm_intel_gem_bo_context_exec() failed: Invalid argument That's the error check added by this patch, but not the same error code as I get for a too-large array on Ivy Bridge (that's drm_intel_gem_bo_context_exec() failed: No space left on device), so may be it catching a different bug. I will report this upstream. Quite possible. sudo cat /sys/module/i915/parameters/enable_cmd_parser returns 1 That means you don't have the #767148 workaround enabled. Does it ( sudo echo 0 /sys/module/i915/parameters/enable_cmd_parser ) help? Absolutely yes. I can e.g. manipulate arrays with up to 128Mi elements, and if I go too high I get the No space left on device error instead. So it looks like I _do_ need that workaround. What are your other i915 parameters ( sudo head /sys/module/i915/parameters/* )? With the enable_cmd_parser set to 0 as above, this is the whole dump: == /sys/module/i915/parameters/disable_display == N == /sys/module/i915/parameters/disable_power_well == 1 == /sys/module/i915/parameters/disable_vtd_wa == N == /sys/module/i915/parameters/enable_cmd_parser == 0 == /sys/module/i915/parameters/enable_fbc == -1 == /sys/module/i915/parameters/enable_hangcheck == Y == /sys/module/i915/parameters/enable_ips == 1 == /sys/module/i915/parameters/enable_ppgtt == 1 == /sys/module/i915/parameters/enable_psr == 0 == /sys/module/i915/parameters/enable_rc6 == 1 == /sys/module/i915/parameters/fastboot == N == /sys/module/i915/parameters/invert_brightness == 0 == /sys/module/i915/parameters/lvds_channel_mode == 0 == /sys/module/i915/parameters/lvds_downclock == 0 == /sys/module/i915/parameters/lvds_use_ssc == -1 == /sys/module/i915/parameters/modeset == -1 == /sys/module/i915/parameters/panel_ignore_lid == 1 == /sys/module/i915/parameters/powersave == 1 == /sys/module/i915/parameters/prefault_disable == N == /sys/module/i915/parameters/preliminary_hw_support == 0 == /sys/module/i915/parameters/reset == Y == /sys/module/i915/parameters/semaphores == -1 == /sys/module/i915/parameters/vbt_sdvo_panel_type == -1 -- Giuseppe Oblomov Bilotta -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781875: beignet: silently does nothing on large arrays
Hello, I've finally had time to test the latest version in experimental (1.0.2-2) and now every kernel invocation, regardless of arguments counts and array sizes, fails with drm_intel_gem_bo_context_exec() failed: Invalid argument so I might be among the ones affected by the other bug you mention (I run on 3.16.7-ckt9-2). I do not have the workaround from #767148 enabled, at least I don't remember ever enabling it. sudo cat /sys/module/i915/parameters/enable_cmd_parser returns 1. On Fri, Apr 10, 2015 at 2:04 PM, Rebecca N. Palmer rebecca_pal...@zoho.com wrote: Control: tags -1 pending This is now fixed upstream and in Alioth ( https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/log/ ). However, another recently-reported bug causes beignet to totally fail (appears in the platform list, but can't do any computations) on 3.15 and later kernels on at least some Haswell processors: http://lists.freedesktop.org/archives/beignet/2015-April/thread.html#5463 Do you still have the workaround from #767148 enabled (which also avoids that bug but may be a security risk, to check run: sudo cat /sys/module/i915/parameters/enable_cmd_parser ), or is your processor just not affected? -- Giuseppe Oblomov Bilotta -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781875: [Pkg-opencl-devel] Bug#781875: beignet: kernels don't seem to run
On Sat, Apr 4, 2015 at 10:30 AM, Rebecca N. Palmer rebecca_pal...@zoho.com wrote: The ICD interface works for me (i5-3230M), which makes this bug _both_ hardware- and interface-dependent, which is weird. The other person that I'm in contact with and whose machine exhibits the same problem has an Iris Pro. Are you saying 1.0.0 didn't work for you at all, or are you saying 1.0.0 worked properly and this is a regression? The full story goes like this: until now, I've used the Debian-shipped packages (in a combination of unstable and experimental versions). I've never tested it extensively though, mostly running through (my own) clinfo. The first version that _seemed_ to work properly (at least under clinfo) was 1.0.1-1, which I recently upgraded to 1.0.2-1. It was only at this point that I actually tried running some kernels on the device, and noticed the failures. I've discussed this with the Iris Pro user on FreeNode (#opencl channel), and it turns out that they had a similar experience, except they were using the git tree and 1.0.0 actually worked for them, but 1.0.1 didn't. I've finally found the time to do the testing and run git bisect, which found the culprit at this commit: a27428d2f30d7859cb988c6fa93a2964c443373d is the first bad commit commit a27428d2f30d7859cb988c6fa93a2964c443373d Author: Zhigang Gong zhigang.g...@intel.com Date: Wed Dec 24 09:21:28 2014 +0800 runtime: tweak max memory allocation size. Increase the maximum memory allocation size to at least 512MB and will set it to larger if the system has more total memory. This tweak will make darktable happy to handle big pictures. Signed-off-by: Zhigang Gong zhigang.g...@intel.com v2: reduce max constant buffer to 128MB. v3: fix the sysinfo usage. Signed-off-by: Zhigang Gong zhigang.g...@intel.com Tested-by: Meng, Mengmeng mengmeng.m...@intel.com :04 04 af8bd19e9bf6f59d27fa2abc9fb67e4f6d476643 45aa59e8d4e84856d0152db1bcd814c58710e85b M src which I find odd but honestly I don't know anything about the beignet internals to judge 8-P I've been testing the commits primarily with my suite of overallocation/migration tests available at http://github.com/Oblomov/cltests which is a bit special, but in fact even simpler setups will fail. I'm also testing a much simpler program (trivial vector sum, of which I can attach the code), from which I have some interesting findings. The simple vector sum allocates three vectors of ints, initializes two of them to some specific values (i, numels - i respectively) and then computes the sum. The findings are: * up to 128*1024*1024 elements, things work even at the 'bad' commit; * twice that results in the failure; * thrice that or more results in an invalid buffer size error (-61). Now the interesting result is thus that 256Mi elements claim to work (in term of buffer allocation), _but_ the kernels fail to run _at all_ (with the 'culprit' commit): even the first element in the buffers is NOT updated correctly. Instead, with the commit right before that (last 'good' commit), 128Mi elements fail to allocate (64Mi elements work). To sum it up, the increase in maximum memory allocation size to at least 512MiB 'works', but only up to a point: specifically, 512MiB buffers work correctly, but (at least on my device) 1024MiB buffers (which are allowed) cause the kernel to fail launching even though the allocation allegedly works. Should I Cc: Zhigang Gong on the discussion? I can also produce the simple vector sum core if needed. -- Giuseppe Oblomov Bilotta -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781875: beignet: kernels don't seem to run
Package: beignet-opencl-icd Version: 1.0.2-1 Severity: grave Tags: upstream Since version 1.0.1 beignet has been able to recognitze the hardware on my machine 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) and responds regularly to device info queries as well as buffer allocation commands. However, kernels don't seem to run at all, in any form and with any queue properties. Buffers return untouched. Discussion with people on #opencl indicate that the bug: * affects upstream; * only occurs when using beignet through the ICD interface; * has been introduced _probably_ somewhere between 1.0.0 and 1.0.1. It also seems that the issue cannot be noticed by simply running the beignet tests, since they link directly to the library. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages beignet-opencl-icd depends on: ii libc6 2.19-17 ii libdrm-intel1 2.4.58-2 ii libdrm22.4.58-2 ii libedit2 3.1-20140620-2 ii libffi63.1-2+b2 ii libgcc11:4.9.2-10 ii libllvm3.5 1:3.5-10 ii libstdc++6 4.9.2-10 ii libtinfo5 5.9+20140913-1+b1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxfixes3 1:5.0.1-2+b2 ii zlib1g 1:1.2.8.dfsg-2+b1 beignet-opencl-icd recommends no packages. beignet-opencl-icd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766150: cannot be installed due to a file shipped also in kate-data
Package: kate Version: 4:4.14.2-1 Severity: grave Trying to upgrade to kate 4:4.14.2-1 on amd64 fails due to: Preparing to unpack .../kate_4%3a4.14.2-1_amd64.deb ... Unpacking kate (4:4.14.2-1) ... dpkg: error processing archive /var/cache/apt/archives/kate_4%3a4.14.2-1_amd64.deb (--unpack): trying to overwrite '/usr/share/kde4/apps/kate/plugins/project/kateproject.example', which is also in package kate-data 4:4.14.2-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/kate_4%3a4.14.2-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) (Probably the file should only be shipped with kate-data.) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765725: Crash with terminate called after throwing an instance of 'Gio::Error'
Package: pavucontrol
Version: 2.0-2
Followup-For: Bug #765725
I'm experiencing the same error, consistently, when Chromium is running
and on a WebRTC-enabled page. For example, start Chromium, enable WebRTC
support, go to http://appear.in/linux and accept to share webcam and
microphone. Then start pavucontrol, and pavucontrol will segfault with
the following backtrace:
#0 0x72a41077 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 7669
selftid = 7669
#1 0x72a42458 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x964790, sa_sigaction =
0x964790}, sa_mask = {__val = {12179648, 6595224, 140737351949831, 1, 0,
140737337045957, 140737264037160, 140737337045957, 6595224, 12166736,
140737351975717, 140737353611808, 12111312,
1, 140737353614160, 12111312}}, sa_flags = -9560, sa_restorer =
0x7fffd5b0}
sigs = {__val = {32, 0 repeats 15 times}}
#2 0x73548b2d in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#3 0x73546ba6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#4 0x73546bf1 in std::terminate() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#5 0x73546e09 in __cxa_throw () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#6 0x76f68ff7 in Gio::Error::throw_func(_GError*) () from
/usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
No symbol table info available.
#7 0x76a26977 in Glib::Error::throw_exception(_GError*) () from
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
No symbol table info available.
#8 0x779c6ced in Gtk::IconTheme::load_icon(Glib::ustring const, int,
Gtk::IconLookupFlags) const () from /usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
No symbol table info available.
#9 0x0041f3b2 in set_icon_name_fallback (i=i@entry=0xb9fcc0,
name=name@entry=0xb10a10 chromium, size=..., size@entry=...) at
mainwindow.cc:244
theme = optimized out
pixbuf = {pCppObject_ = 0x0}
width = 16
height = 16
#10 0x0041f7c8 in MainWindow::setIconFromProplist
(this=this@entry=0x9645f0, icon=0xb9fcc0, l=0xa61f90, def=def@entry=0x43deae
audio-card) at mainwindow.cc:666
t = 0xb10a10 chromium
#11 0x004271c8 in MainWindow::updateSinkInput (this=0x9645f0, info=...)
at mainwindow.cc:715
t = optimized out
w = 0xb84740
is_new = true
txt = optimized out
#12 0x7380ccf5 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
No symbol table info available.
#13 0x7fffedbbab61 in ?? () from
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so
No symbol table info available.
#14 0x7fffedbbaef3 in pa_pdispatch_run () from
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so
No symbol table info available.
#15 0x738026ae in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
No symbol table info available.
#16 0x7fffedbbf160 in ?? () from
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so
No symbol table info available.
#17 0x73a45bba in ?? () from
/usr/lib/x86_64-linux-gnu/libpulse-mainloop-glib.so.0
No symbol table info available.
#18 0x73c92c5d in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#19 0x73c92f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#20 0x73c93272 in g_main_loop_run () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#21 0x7578ba85 in gtk_main () from
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
No symbol table info available.
#22 0x779d612f in Gtk::Main::run(Gtk::Window) () from
/usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
No symbol table info available.
#23 0x0040ed3e in main (argc=1, argv=0x7fffe428) at
pavucontrol.cc:683
kit = incomplete type
mainWindow = 0x9645f0
m = 0x976f00
group = incomplete type
entry2 = incomplete type
__PRETTY_FUNCTION__ = int main(int, char**)
options = incomplete type
entry = incomplete type
(I'm also having audio issues with WebRTC in chromium (can't hear others,
others can't hear me), which might be related, but I'll file that
separately since it's obviously a Chromium issue.)
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pavucontrol depends on:
ii
Bug#714504: cannot upgrade to 4.8.1-5 on multiarch (amd64 and i386)
Package: gcc-4.8 Version: 4.8.1-4 Severity: serious gcc-4.8 and related packages are at different versions in sid on amd64 (4.8.1-5) and i386 (4.8.1-4), but the same version _must_ be installed for all architectures. This prevents upgrading of gcc-4.8 and all related packages on multiarch (amd64 + i386) systems. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcc-4.8 depends on: ii binutils2.23.52.20130620-1 ii cpp-4.8 4.8.1-4 ii gcc-4.8-base4.8.1-4 ii libc6 2.17-5 ii libcloog-isl4 0.18.0-2 ii libgcc-4.8-dev 4.8.1-4 ii libgmp102:5.1.2+dfsg-1 ii libisl100.11.2-1 ii libmpc3 1.0.1-1 ii libmpfr43.1.1-1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gcc-4.8 recommends: ii libc6-dev 2.17-5 Versions of packages gcc-4.8 suggests: pn binutils-goldnone pn gcc-4.8-doc none pn gcc-4.8-locales none ii gcc-4.8-multilib 4.8.1-4 pn libasan0-dbg none pn libatomic1-dbg none pn libbacktrace1-dbgnone pn libgcc1-dbg none pn libgomp1-dbg none pn libitm1-dbg none pn libmudflap0-4.8-dev none pn libmudflap0-dbg none pn libquadmath0-dbg none pn libtsan0-dbg none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658491: closed by Francesco P. Lovergine fran...@debian.org (Re: Bug#658491: hdf5-tools programs cannot find libhdf5.so.7)
Thanks for the reply. However, I do believe this is still a bug in the dependency specification, since if the hdf5-tools package depends on the *latest* version of the libhdf5-1.8 package, then it should explicitly do so, to prevent installation when the correct version cannot be installed because e.g. it is being held back automatically by some other package (paraview in my case). -- Forwarded message -- From: Francesco P. Lovergine fran...@debian.org To: 658491-d...@bugs.debian.org Cc: Date: Fri, 3 Feb 2012 19:55:28 +0100 Subject: Re: Bug#658491: hdf5-tools programs cannot find libhdf5.so.7 severity normal thanks This is a non bug, you have simply to install the *latest* version of the hdf5 library which provides libhdf5-1.8. You have probably on hold the previous version for some reason. -- Giuseppe Oblomov Bilotta -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658491: hdf5-tools programs cannot find libhdf5.so.7
Package: hdf5-tools Version: 1.8.8-6 Severity: grave The binaries in this version of hdf5-tools are linked against libhdf5.so.7, but the package depends on libhdf5-1.8 that provides libhdf5.so.6. Therefore, all of the tools fail to launch with: error while loading shared libraries: libhdf5.so.7: cannot open shared object file: No such file or directory -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hdf5-tools depends on: ii libhdf5-openmpi-1.8.4 [libhdf5-1.8] 1.8.4-patch1-3 hdf5-tools recommends no packages. hdf5-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620687: postinst and prerm are for the wrong version
Package: infinoted-0.5 Version: 0.5.0-1 Severity: grave Trying to install the package fails becase the postinst script tries to set up an alternative for infinoted-0.4.1 instead of -0.5 ; the prerm script has a similar issue with 0.3. It looks lik they are the ones for the wrong version. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages infinoted-0.5 depends on: ii libavahi-client30.6.29-1 Avahi client library ii libavahi-common30.6.29-1 Avahi common library ii libc6 2.11.2-13Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2common error description library ii libdaemon0 0.14-2 lightweight C library for daemons ii libgcrypt11 1.4.6-5 LGPL Crypto library - runtime libr ii libglib2.0-02.28.4-1 The GLib library of C routines ii libgnutls26 2.10.5-1+b1 the GNU TLS library - runtime libr ii libgpg-error0 1.10-0.3 library for common error values an ii libgsasl7 1.4.4-2 GNU SASL library ii libgssapi-krb5-21.9+dfsg-1 MIT Kerberos runtime libraries - k ii libidn111.20-1 GNU Libidn library, implementation ii libinfinity-0.5-0 0.5.0-1 infinote-based collaborative editi ii libk5crypto31.9+dfsg-1 MIT Kerberos runtime libraries - C ii libkrb5-3 1.9+dfsg-1 MIT Kerberos runtime libraries ii libntlm01.2-1NTLM authentication library ii libxml2 2.7.8.dfsg-2 GNOME XML library infinoted-0.5 recommends no packages. infinoted-0.5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519397: cheese: fails to load: segmentation fault in libgstffmpeg.so
2009/3/24 Sebastian Dröge sl...@circular-chaos.org: Which version of libavcodec52 do you have installed? Package: libavcodec52 New: yes State: installed Automatically installed: yes Version: 4:0.5.svn20090318-0.0 Priority: optional Section: libs I dist-upgraded today to the latest debian unstable and I cannot reproduce the error anymore. This bug can be closed for me. -- Giuseppe Oblomov Bilotta -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519397: cheese: fails to load: segmentation fault in libgstffmpeg.so
Package: cheese Version: 2.24.3-1 Severity: grave Justification: renders package unusable Loading cheese fails with the (console) message: --- ERROR: Caught a segmentation fault while loading plugin file: /usr/lib/gstreamer-0.10/libgstffmpeg.so Please either: - remove it and restart. - run with --gst-disable-segtrap and debug. Error re-scanning registry , child terminated by signal --- It is possible to temporarily work around this issue by either removing the plugin or by using --gst-disable-registry-update, but neither is an option for common users. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-rc4 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cheese depends on: ii gconf22.24.0-7 GNOME configuration database syste ii gstreamer0.10-plugins-base0.10.22-3 GStreamer plugins from the base ii gstreamer0.10-plugins-good0.10.14-2 GStreamer plugins from the good ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi ii libc6 2.9-4 GNU C Library: Shared libraries ii libcairo2 1.8.6-2+b1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.12-1 simple interprocess messaging syst ii libdbus-glib-1-2 0.80-3 simple interprocess messaging syst ii libebook1.2-9 2.24.5-2 Client library for evolution addre ii libgconf2-4 2.24.0-7 GNOME configuration database syste ii libglib2.0-0 2.18.4-2 The GLib library of C routines ii libgnomeui-0 2.24.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-01:2.24.0-2 GNOME Virtual File System (runtime ii libgstreamer-plugins-base0.10 0.10.22-3 GStreamer libraries from the base ii libgstreamer0.10-00.10.22-2 Core GStreamer libraries and eleme ii libgtk2.0-0 2.14.7-4 The GTK+ graphical user interface ii libhal1 0.5.11-8 Hardware Abstraction Layer - share ii libpango1.0-0 1.22.4-2 Layout and rendering of internatio ii librsvg2-22.22.3-2 SAX-based renderer library for SVG Versions of packages cheese recommends: ii gvfs 1.0.3-2userspace virtual filesystem - ser cheese suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
