Bug#738153: Seems like qt 5.2 requires qtcreator 3.0
Sorry for not noticing repliers earlier. I forgot to check my debian bug filter directory for replies. I don't think there is any hurry to upgrade qtcraetor. At least not before qt5 build issues has been resolved. I think a qml crash bug test case should be simple enough for this one too. On Sat, Feb 8, 2014 at 3:06 PM, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: Hi Paul! Currently qtcreator is compiled against Qt4. That means some of it's functionality in Qt5 may not be there. The reason for this is the qtwebkit-opensource-src line in: http://pkg-kde.alioth.debian.org/redir/qt-buildd-sid?compact=1 If I switch Qt creator to use Qt5, almost all archs will loose it, as Creator needs qtwebkit (and maybe also qtquick1, which in turn also depends on qtwebkit), which currently FTBFS. As Adam wrote, I will need a testcase to see if the bug is reproducible. Or a patch to make qtwebkit build ;) Kinds regards, Lisandro. -- $ make war make: *** No rule to make target `war'. Stop. Try `love' instead David Gravereaux Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ qmlcrash.tar Description: Unix tar archive
Bug#738153: Seems like qt 5.2 requires qtcreator 3.0
Steps to reproduce: 1. Open the project in qtcreator 2. Make sure qtcreator is configured to use qt 5.2 (tools-options-Buildrun, QT Versions and Kits tabs) 3. Configure project with qt 5.2 kit 4. See that run and debug buttons in bottom left corner are grey. Also matching menu entries are disabled. The test case build and runs in my system with /usr/lib/x86_64-linux-gnu/qt5/bin/qmake make ./crash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738153: Seems like qt 5.2 requires qtcreator 3.0
Now I found first relevant bit of information from http://qt-project.org/forums/viewthread/34706/#151753 That tries to say that even qtcreator 3.0 beta was too old for qt 5.2. I then went to download qtcreator 3.0.1 just to check if newer version would work for me. It does work fine on my system. I think that fix for this bug would be qtcreator upgrade to version 3.0. Pauli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728572: python-apt: string to float conversion exception
On Thu, Nov 14, 2013 at 8:48 AM, Michael Vogt m...@debian.org wrote: On Fri, Nov 08, 2013 at 08:47:32AM +0200, Pauli Nieminen wrote: Maybe these patches will help fixing the issue. At least to me it looks like the cause of the problem. Thanks a bunch for digging into this and for the patches (and sorry that it took me so long to reply). I'm still a bit confused though, AFAICS, 0.9.12.1 does send the sort pkgname so the first patch should not be needed with the apt in current unstable. Or am I missing something? I.e. do you still observe that 0.9.12.1 sends the architecture string? yes. If you check my 0.9.12.1 patch and shortname patch carefully you will notice that my patch applies same modification to second package name print place. In that place apt 0.9.12.1 is still passing directly what ever dpkg is sending to it As for the second patch, the new PackageManagerProgressFd::StatusChanged() has a line. status pmstatus: StringSplit(PackageName, :)[0] that should also strip the architectire before it goes out over the status-fd to python-apt. The InstallProgress needs the full architecture string for progress classes like the new deb822 progress that will send out the archtitecture as a sperate field. Correct. I wasn't careful enough to notice that 0.9.13 already does correct architecture stripping inside StatusChanged Cheers, Michael
Bug#728572: python-apt: string to float conversion exception
Maybe these patches will help fixing the issue. At least to me it looks
like the cause of the problem.
From 03482179d0a91cf3f23fa777874a5e45344a4486 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Fri, 8 Nov 2013 08:11:26 +0200
Subject: [PATCH] Avoid sending package name with arch to status FD
Sending arch with package name to status fd makes other side parse the
string incorrectly because expectation is to do simple string split with
colon. But of course there would be an extra colon in the string.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
apt-pkg/deb/dpkgpm.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index fe38bf6..f2dc296 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -583,7 +583,7 @@ void pkgDPkgPM::ProcessDpkgStatusLine(int OutStatusFd, char *line)
if(strncmp(list[0].c_str(), processing, strlen(processing)) == 0)
{
char s[200];
- const char* const pkg_or_trigger = list[2].c_str();
+ const char* const pkg_or_trigger = StringSplit(list[2], :)[0].c_str();
action = list[1].c_str();
const std::pairconst char *, const char * * const iter =
std::find_if(PackageProcessingOpsBegin,
--
1.8.4.2
From b1b7ece6ca12c1eea14e9a6dc69ec138f6298c9e Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Fri, 8 Nov 2013 08:11:26 +0200
Subject: [PATCH] Avoid sending package name with arch to status FD
Sending arch with package name to status fd makes other side parse the
string incorrectly because expectation is to do simple string split with
colon. But of course there would be an extra colon in the string.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
apt-pkg/deb/dpkgpm.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index 26d79db..92b85b6 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -664,7 +664,7 @@ void pkgDPkgPM::ProcessDpkgStatusLine(char *line)
}
std::string msg;
strprintf(msg, _(iter-second), i18n_pkgname.c_str());
- d-progress-StatusChanged(pkgname, PackagesDone, PackagesTotal, msg);
+ d-progress-StatusChanged(short_pkgname, PackagesDone, PackagesTotal, msg);
// FIXME: this needs a muliarch testcase
// FIXME2: is pkgname here reliable with dpkg only sending us
@@ -693,7 +693,7 @@ void pkgDPkgPM::ProcessDpkgStatusLine(char *line)
PackagesDone++;
strprintf(msg, translation, i18n_pkgname.c_str());
- d-progress-StatusChanged(pkgname, PackagesDone, PackagesTotal, msg);
+ d-progress-StatusChanged(short_pkgname, PackagesDone, PackagesTotal, msg);
}
if (Debug == true)
--
1.8.4.2
Bug#728572: python-apt: string to float conversion exception
On Wed, Nov 6, 2013 at 9:04 AM, Michael Vogt m...@debian.org wrote: On Sun, Nov 03, 2013 at 01:02:25PM +0200, Pauli Nieminen wrote: I upgraded to 0.9.12.1 on 16th October (from logs). That means I'm reproducing this issue with 0.9.12.1. Thanks for your bugreport. This was indeed supposed to be fixed with apt 0.9.12.1, do you have a example package or any other hints how to reproduce this bug? I.e. is there anything I can downgrade and let unattended-upgrades run to trigger the issue? libpopt0 from 1.16-7 to 1.16-8 appears to be the latest one reproducing this bug. Earlier logs with my debug print where showing that problem appeared only during configure phase for libwireshark3. Too bad I have replaced that change with other python-apt changes so no more debug print if the issue happens to reproduce. pmstatus:libwireshark3:amd64:60:Configuring libwireshark3:amd64 Thanks, Michael
Bug#728572: The problematic pmstatus message
Now I managed to reproduce the issue with debug print that tells following: (Reading database ... 395704 files and directories currently installed.) Preparing to replace libwireshark-data 1.10.2-2 (using .../libwireshark-data_1.10.3-1_all.deb) ... Unpacking replacement libwireshark-data ... Setting up libwireshark-data (1.10.3-1) ... -1-0 (1.8.3-1) ... Processing triggers for libc-bin ... O4.1.3-1) ... pmstatus:dpkg-exec:0:Running dpkg pmstatus:libwireshark3:20:Preparing libwireshark3 pmstatus:libwireshark3:40:Unpacking libwireshark3 pmstatus:libwireshark3:60:Preparing to configure libwireshark3 pmstatus:dpkg-exec:60:Running dpkg pmstatus:libwireshark3:amd64:60:Configuring libwireshark3:amd64
Bug#728572: python-apt: string to float conversion exception
I upgraded to 0.9.12.1 on 16th October (from logs). That means I'm reproducing this issue with 0.9.12.1. On Sun, Nov 3, 2013 at 12:20 PM, Julian Andres Klode j...@debian.org wrote: On Sun, Nov 03, 2013 at 10:09:06AM +0200, Pauli wrote: Package: python-apt Version: 2:0.9.1 Severity: normal Dear Maintainer, I noticed that unattended-upgrade seem to fail randomly with string to float conversion exception. I made some modifications to unattended-upgrade to print the exception stack trace which points python-apt status update parsing code. Exception happened during upgrade. Traceback (most recent call last): File /usr/bin/unattended-upgrade, line 382, in upgrade_in_minimal_steps res cache.commit(install_progressiprogress) File /usr/lib/python2.7/dist-packages/apt/cache.py, line 498, in commit res self.install_archives(pm, install_progress) File /usr/lib/python2.7/dist-packages/apt/cache.py, line 462, in install_archives res install_progress.run(pm) File /usr/lib/python2.7/dist-packages/apt/progress/base.py, line 206, in run res self.wait_child() File /usr/lib/python2.7/dist-packages/apt/progress/base.py, line 276, in wait_child self.update_interface() File /usr/bin/unattended-upgrade, line 172, in update_interface apt.progress.base.InstallProgress.update_interface(self) File /usr/lib/python2.7/dist-packages/apt/progress/base.py, line 253, in update_interface if float(percent) ! self.percent or status_str ! self.status: ValueError: could not convert string to float: amd64 You ran that upgrade with APT 0.9.12, right? This was fixed in 0.9.12.1, so you cannot reproduce it anymore... -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible.
Bug#717988: Speculation about cause for the deadlock
It seems the hotplug mutex is taken when I shutdown my qemu VM having USB passthrough configured for a device. There is libusb_init called followed quickly after by libusb_exit. Deadlock happens most likely because libusb_exit holds linux_hotplug_lock during whole exit phase. With bad timeing event thread can try to take same lock simultanously leading to the deadlock shown by backtrace in original report.
Bug#717988: libusb-1.0-0: upowerd deadlocks in libusb (maybe related to suspend/resume)
Thanks. Looks exactly same bug. I will test the patch if any new appears to redhat bugzilla. Too bad there isn't link to upstream bug report and I'm lazy searching one. :/ On Mon, Jul 29, 2013 at 2:30 PM, Aurelien Jarno aurel...@aurel32.netwrote: forwarded 717988 https://bugzilla.redhat.com/show_bug.cgi?id=985484 thanks On Sat, Jul 27, 2013 at 06:21:56PM +0300, Pauli wrote: Package: libusb-1.0-0 Version: 2:1.0.16-1 Severity: important Dear Maintainer, * What led up to the situation? Exact steps are unknown but during last two days I have noticed upowerd daemon beeing stuck for unknown reason after suspend/resume. * What exactly did you do (or not do) that was effective (or ineffective)? I suspend my laptop frequently using keyboard hotkey. That used to work without problems until upowerd now started deadlocking. * What was the outcome of this action? upowerd daemon deadlocks forcing me to manually restart it before any power related functionality works in gnome. The bug has been reported upstream and patches are being written. Actually a first patch already exists, but has side effects. I will do a new upload as soon as the final patch is committed (upstream might do a new release for that). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Bug#714366: Workaround
Hi, I didn't mention first time but I did a short term workaround: ln -s /usr/lib/i386-linux-gnu/wine-unstable/wine/wineserver /usr/bin/
Bug#695985: gwibber-service: dbus starts multiple instances of gwibber because of poor service configuration
Sorry for taking this long to come back to the patch. Today I proted the changes to 3.5.2 in experimental but I still didn't figure out all build dependecies for 3.6.0. I quickly tested the interface. I also checked that only single service is started even if I remove the racy check from service starter. That means patch should be complete fix for 3.5.2. I will make an untested patch for maste so we can see upstream comments too. Porting seems to be relatively simple operations what I have looked the diff. On Fri, Dec 21, 2012 at 6:32 PM, Pauli Nieminen suok...@gmail.com wrote: On Mon, Dec 17, 2012 at 11:58 AM, Kartik Mistry kartik.mis...@gmail.comwrote: On Sat, Dec 15, 2012 at 2:39 PM, Pauli suok...@gmail.com wrote: I noticed that sometimes gwibber generates multiple notifications for a single update. I quickly figured out that issue was dbus starting multiple gwibber-service instances because a race condition in service startup. When I looked around I saw some Ubuntu bug report having similar issues with their indicator. I don't know if there is any more issues that are caused by the race condition. I have made a proposed fix to gwibber code and dbu service configuration to avoid the race condition in startup. The fix is simple refactoring dbus interface to be under single service name that allows dbus to provide atomic single service startup functionality for gwibber-service. I checked upstream code that same bug still exists in the latest development version. But I could easily compile the latest version in Sid so I decided to first cook a patch for the debian package. I will today forward port my changes for upstream inclusion. Attached patch will require also changes to packaging because it reduces .service files to only two. Thanks a lot. Can you redo patch against experimental package of Gwibber? We really need to re-work on package as it has more dependencies which are not in Debian yet. I will do that after Christmas. I didn't have time to figure out the build dependencies when I tried to build gwibber from upstream. I also opened upstream bug if someone there would like to forward port changes before I have time to figure out how to get required dependencies. https://bugs.launchpad.net/gwibber/+bug/1090670 fix-for-3.5.2.diff Description: Binary data
Bug#695985: gwibber-service: dbus starts multiple instances of gwibber because of poor service configuration
The master merge request can be found from https://code.launchpad.net/~paniemin/gwibber/gwibber/+merge/143341
Bug#695985: gwibber-service: dbus starts multiple instances of gwibber because of poor service configuration
On Mon, Dec 17, 2012 at 11:58 AM, Kartik Mistry kartik.mis...@gmail.comwrote: On Sat, Dec 15, 2012 at 2:39 PM, Pauli suok...@gmail.com wrote: I noticed that sometimes gwibber generates multiple notifications for a single update. I quickly figured out that issue was dbus starting multiple gwibber-service instances because a race condition in service startup. When I looked around I saw some Ubuntu bug report having similar issues with their indicator. I don't know if there is any more issues that are caused by the race condition. I have made a proposed fix to gwibber code and dbu service configuration to avoid the race condition in startup. The fix is simple refactoring dbus interface to be under single service name that allows dbus to provide atomic single service startup functionality for gwibber-service. I checked upstream code that same bug still exists in the latest development version. But I could easily compile the latest version in Sid so I decided to first cook a patch for the debian package. I will today forward port my changes for upstream inclusion. Attached patch will require also changes to packaging because it reduces .service files to only two. Thanks a lot. Can you redo patch against experimental package of Gwibber? We really need to re-work on package as it has more dependencies which are not in Debian yet. I will do that after Christmas. I didn't have time to figure out the build dependencies when I tried to build gwibber from upstream. I also opened upstream bug if someone there would like to forward port changes before I have time to figure out how to get required dependencies. https://bugs.launchpad.net/gwibber/+bug/1090670
Bug#685608: Acknowledgement (linux-image-3.2.0-3-amd64: unable to handle kernel paging request __d_shrink)
I have now been running the debug config kernel since posting this bug. There has been no lockdep or slab debug reports in kernel log since. That makes me wonder what is possible cause of the twice produced oops in __d_shrink. I have been using suspend multiple times per day. I have applied all normal stress to dentry cache through normal use and background file system scan operations like security checks and defragmentation. Also log rotation has been done multiple times if that could be original cause somehow. If anyone has any ideas how dentry cache could be stressed to reproduce the issue I would be happy to try it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686865: Acknowledgement (openjdk-6-jre: java.awt.Desktop.browse starts gnome-www-browser instead of preferred iceweasel)
Oops. I forgot to open /dev/null to place instead of standard stream. The fixed patch attached. desktop-peer-browse-use-xdg-open.diff Description: Binary data
Bug#685608: Acknowledgement (linux-image-3.2.0-3-amd64: unable to handle kernel paging request __d_shrink)
I forgot to add a few important details: The laptop gets suspended and resumed frequantly. After resume radeon always tries to fakeup but HW is in sleept state by vgaswitcheroo. Also before the oops I was browsing with iceweacel and having nonfree flash showing live bridge vugraph from World Mind Sport Games. Desktop is gnome-shell so there was fair bit of acitivty for graphics driver. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646763: Adding link to upstream bug
Upstream bug is https://bugs.freedesktop.org/show_bug.cgi?id=36930 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575755: compizconfig-settings-manager: When editing settings or enabling some plugins all settings are udenly reset to defaults.
Package: compizconfig-settings-manager Version: 0.8.4-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Resetting settings happens very randomly but relatively frequantly. I haven't yet figured out what is causing the bug. But following lsit is when I have seen the bug - - When I enabled all image type plugins very quicly after each other. - - When I go to edit per plugin settings and return from there. - - When I opened ccsm to try to find way to reproduce it while writing this bug. - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) 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 compizconfig-settings-manager depends on: ii librsvg2-common 2.26.0-2 SAX-based renderer library for SVG ii python2.5.4-9An interactive high-level object-o ii python-compizconfig 0.8.4-2Compizconfig bindings for python ii python-gtk2 2.16.0-2 Python bindings for the GTK+ widge ii python-support1.0.7 automated rebuilding support for P compizconfig-settings-manager recommends no packages. compizconfig-settings-manager suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkuvM8cACgkQ+A3FpPPkpMp2zwCfRC77wfU9FSqWgxS0kNi4q57G hXwAn2OqcS5t2BfyW9oQ8RYWV/HKhgGd =5Ee2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575756: linux-image-686: radeon KMS is missing important engine cache flush in GPU context switch
Package: linux-image-686 Version: 2.6.32+25 Severity: normal Code path for r100/r200 is missing GPU cache flush in GPU context swicth. This causes image corruption and possible GPU hangs. Fix is included in 2.6.33 since commit: 9e5b2af75abc67c13005c706cf9578f7fddc drm/r100/kms: Emit cache flush to the end of command buffer. It would be good idea to backport it to debian kernels vefore 2.6.33 tht hae kms enabled for radeon (like 2.6.32 in sid) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) 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 linux-image-686 depends on: ii linux-image-2.6.32-3-686 2.6.32-9 Linux 2.6.32 for modern PCs linux-image-686 recommends no packages. linux-image-686 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563257:
This is kernel bug and is fixed with kernel commits in 2.6.34-rc1: 7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 drm: Add generic multipart buffer. b4fe945405e477cded91772b4fec854705443dd5 drm/radeon: Fix memory allocation failures in the preKMS command stream checking. 55a5cb5d594c18b3147a2288b00ea359c1a38cf8 drm/radeon: Fix printf type warning in 64bit system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575231: Supertuxkart under/overflows gl matrix stack because of incorrect matrix mode handling
Package: supertuxkart Version: 0.6.2+dfsg1-1 Severity: normal Supertuxkart is under/overflowing gl matrix stacks because incorrect handling of matrix mode. I tried to submit fix for this to upstream project but they reject because all development is going to trunk (0.7). [1] Patch to fix the bug is attached to upstream mailing list post and is here: Index: src/gui/race_gui.cpp === --- src/gui/race_gui.cpp(revision 5049) +++ src/gui/race_gui.cpp(working copy) @@ -963,6 +963,7 @@ } // if RACE_PHASE glPopAttrib () ; +glMatrixMode ( GL_PROJECTION ) ; glPopMatrix () ; glMatrixMode ( GL_MODELVIEW ) ; glPopMatrix () ; [1] http://sourceforge.net/mailarchive/forum.php?thread_name=548cdfc21003231345p7c6b8b99g7fee9deddb035d8e%40mail.gmail.comforum_name=supertuxkart-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572926: xserver-xorg-video-radeon: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch
On Sun, Mar 7, 2010 at 8:19 PM, Andres Cimmarusti acimmaru...@gmail.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.5-1 Severity: normal I waited till today to upgrade my xserver-xorg-video-radeon package to the version in unstable (6.12.5), mainly because I was waiting for mesa (7.7) to migrate to testing. Unfortunately I have to report it does not correct my problems. I have KMS in this laptop which works well, but DRI is disabled due to some kind of conflict with the kernel version which really makes no sense! look for yourself: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] radeon kernel module version is 2.0.0 but version 1.8.0 or newer is needed. [dri] Disabling DRI. 6.12 doesn't support KMS. You have to either disable KMS (radeon.modeset=0 kernel parameter) or install 6.13 (aka 6.12.99) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569098: xserver-xorg-video-radeon: Xvideo apparently not working with KMS enabled
On Wed, Feb 10, 2010 at 9:00 PM, Andreas Rottmann a.rottm...@gmx.at wrote: Alex Deucher alexdeuc...@gmail.com writes: From your log: (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS Check your dmesg. You are probably missing the rlc ucode for the interrupt controller. Indeed. I've now downloaded and installed the ucode from http://people.freedesktop.org/~agd5f/radeon_ucode/ as in indicated by Bug #565437. However I still get the same results from xvinfo and mplayer. Kernel modules is not loaded before X starts so wrong code path is selected for KMS kernel. You can try http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/12853 patch to make xserver load radeon before checking if KMS is supported. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567999: xserver-xorg-video-radeon: Please compile with kernel-based modesetting (KMS) enabled
On Mon, Feb 1, 2010 at 9:15 PM, Brice Goglin brice.gog...@ens-lyon.orgwrote: Adrian Glaubitz wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.4-2 Severity: normal Hi, since Debian testing is now shipping with Linux Kernel 2.6.32 which has mature support for kernel-based modesetting it would be a nice option to have KMS also enabled in the xorg driver to take full advantage of KMS. I'm running Ubuntu 10.04 (Lucid) Alpha on a second machine with same the Radeon chipset (X300) and haven't had any KMS-related problems recently. However, Ubuntu 10.04 ships with a more recent version of that driver (6.12.99+git20100126) so I think it might be necessary to update the driver as well. Yes, KMS cannot be enabled in current 6.12 packages, we need a snapshot of git master. I am thinking of working on this in the next days and upload it to experimental. Last time I tried, I had some problems with the radeon kernel driver being loaded too late (see [1]). What do you use on Ubuntu in /etc/modprobe.d/ or on the kernel command line ? Brice [1] https://bugs.freedesktop.org/show_bug.cgi?id=25607 Ubuntu is putting radeon.ko (+drm.ko+ttm.ko+drmkmshelper.ko) to initrd and loading it early in the boot. I don't know the details how it is archived. Reason for putting radeon.ko to initrd is to get flicker free booting with splash screen.
Bug#360560: Idea how to solve the problem that paranoids are seeing here :)
Hello! I just wanted to give my view what oprofile can do more than ps. Even thought that requires large amount of CPU time very good source code knowledge about program that someone else is running. Basically you can put oprofile to collect data with very high frequency including callgraph. Then you have a tool reading all the data on the fly to track down the excecution of a given program. But I think there is a lot easier techniques (and less noticeable) if one already has root access. I want also point that opcontrol --stop is enough to stop data collection. So just loading oprofile kernel modules and running the daemon doesn't expose profiling data to /var/lib. But I still would like that /var/lib/oprofile/ wouldn't be world readable and ownership would oprofile:adm. That should be possible if oprofiled was made to use special user account. This could be archived with fairly simple patch to oprofiled that would jut call setuid and umask. This would cause all collect data automatically have correct permissions. (Unless root changes the the oprofile user accout somehow). Of course largest work would be testing and changes to package installation that handles the permission settings for user account. This at least would give some feeling of security for paranoid people. But of course world readable profile data might be considered as a feature. One good example could be that root is running automatic test suit in a development project. All test data is profiled to help any developer collect information for optimisation. This data later should be readable by all project members (who often shouldn't have root access to system) Everything is trade of unless someone makes this easily configurable too. Pauli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
