emengine_unix.cpp#n931
[13] /usr/include/asm-generic/errno-base.h
[14]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n350
[15]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n979
[16]
https://code.qt.io/cgit/qt/qtbase.git/tree/src
Package: qtbase5-dev
Version: 5.10.1+dfsg-7
Severity: normal
Dear Maintainer,
did a fresh install of debian sid within docker and stumbled upon this
bug in QFile:
QFile's method exists() returns false even if that file exists.
STEPS TO REPRODUCE:
$ cat << 'EOF' >> /tmp/CMakeLists.txt
Thank you!
Am 09.08.2013 05:21, schrieb Debian Bug Tracking System:
This is an automatic notification regarding your Bug report
which was filed against the qtbase5-dev package:
#718348: qtbase5-dev: Unable to configure cmake project using qt5 without
qtbase5-private-dev
It has been closed by
Package: linux-2.6
Version: 3.2.14-1
Severity: normal
Dear Maintainers,
when I try to boot the current kernel 3.2 from debian wheezy||sid, my notebook
screen goes black. Switching to another tty doesn't help, but the system is
still usable e.g. via ssh. This bug is already known and fixed
Hello Jonathan,
... Am I correct in assuming 3.3 works fine on your machine? Cheers,
Jonathan
Yes, this bug seems to be fixed in linux-image-3.3.0-trunk-amd64
(3.3-1~experimental.1).
Kind regards,
Jakob
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Hello there,
after updating my Debian Wheezy/Testing to linux kernel 3.2 my screen
goes black at boot, too. My system is a Lenovo Thinkpad L420 with an
Intel Core i3 (HD3000) inside. The fix posted above
(http://lists.freedesktop.org/archives/intel-gfx/2012-January/014332.html)
fixes this bug
the i915.modeset=0 workaround.
Then i patched my kernel as proposed at [1], rebooted and voilà the
black/blank screen is gone.
Kind regards
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660394#10
Am 07.04.2012 15:52, schrieb Jonathan Nieder:
Hi,
Wearenotalone wrote:
after updating
I don't know why but for me this problem is gone (around one week ago).
My keycodes are back:
$ LANG=C sudo getkeycodes
Plain scancodes xx (hex) versus keycodes (dec)
for 1-83 (0x01-0x53) scancode equals keycode
0x50: 80 81 82 83 84 0 86 87
0x58: 88 117 0 0 95 183 184 185
Thanks for your feedback :)
But why is a loop device attached to my LUKS partition?
Because you specified so.
I already noticed that i made some bad configuration mistakes ;) But i
don't know for sure, where exactly i made this error. Is my assumption
correct, that this problem is
Jan Engelhardt schrieb:
On Sunday 2009-03-01 18:19, Wearenotalone wrote:
Thanks for your feedback :)
But why is a loop device attached to my LUKS partition?
Because you specified so.
I already noticed that i made some bad configuration mistakes ;) But i don't
know
Hello,
Bastian Kleineidam schrieb:
Hi,
Am Friday 20 February 2009 11:50:48 schrieb Wearenotalone:
Yesterday i continued looking for a solution to my problem. At first i
changed my volume definition to
volume fskeycipher=aes-256-cbc fskeyhash=sha512
options=fsk_cipher=aes-256-cbc,fsk_hash
= ehd_dmcrypt_ops.unload(mt); // WEARENOTALONE: Error???
#elif defined(HAVE_DEV_CGDVAR_H)
ret = ehd_cgd_ops.unload(mt);
#endif
/* Try to free loop device even if cryptsetup remove failed */
if (mt-loop_device != NULL)
ret = pmt_loop_release(mt-loop_device);
return ret
I think i have identified the cause of my unmount problem. The mount
option keybits implies the loop option. This causes the LUKS partition
again to be mounted as a loop device. At the moment mount.crypt only
filters the loop option but not the keybits option.
Usualy this is no problem
The first solution seems to be incomplete. If the keybits option is
given then the loop device (/dev/loop1) on top of the LUKS partition is
not created (correct behavior), BUT the loop device of the
/my/encrypted.img file (/dev/loop0) is not removed after luksClosing
14 matches
Mail list logo
