Processing of compiz_0.8.4-5.2_amd64.changes
compiz_0.8.4-5.2_amd64.changes uploaded successfully to localhost along with the files: compiz_0.8.4-5.2.dsc compiz_0.8.4-5.2.diff.gz compiz_0.8.4-5.2_all.deb compiz-core_0.8.4-5.2_amd64.deb compiz-dev_0.8.4-5.2_amd64.deb compiz-gtk_0.8.4-5.2_amd64.deb compiz-kde_0.8.4-5.2_amd64.deb compiz-plugins_0.8.4-5.2_amd64.deb libdecoration0_0.8.4-5.2_amd64.deb libdecoration0-dev_0.8.4-5.2_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1szimh-0002fi...@franck.debian.org
Bug#671995: marked as done (compiz: FTBFS: window.cpp:1603:43: error: 'gethostname' was not declared in this scope)
Your message dated Tue, 29 May 2012 09:32:14 + with message-id and subject line Bug#671995: fixed in compiz 0.8.4-5.2 has caused the Debian Bug report #671995, regarding compiz: FTBFS: window.cpp:1603:43: error: 'gethostname' was not declared in this scope to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 671995: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671995 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: compiz Version: 0.8.4-5.1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120508 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: > if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../include > -DQT_SHARED -I/usr/include/dbus-1.0 > -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/qt4 > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtDBus > -I/usr/include/qt4/QtXml -I/usr/include/-g -O2 -Wall > -D_FORTIFY_SOURCE=2 -MT window.o -MD -MP -MF ".deps/window.Tpo" -c -o > window.o window.cpp; \ > then mv -f ".deps/window.Tpo" ".deps/window.Po"; else rm -f > ".deps/window.Tpo"; exit 1; fi > window.cpp: In member function 'void KWD::Window::updateWindowGeometry()': > window.cpp:1162:17: warning: variable 'w' set but not used > [-Wunused-but-set-variable] > window.cpp:1162:20: warning: variable 'h' set but not used > [-Wunused-but-set-variable] > window.cpp: In member function 'void > KWD::Window::showKillProcessDialog(Time)': > window.cpp:1603:43: error: 'gethostname' was not declared in this scope > make[4]: *** [window.o] Error 1 The full build log is available from: http://people.debian.org/~lucas/logs/2012/05/08/compiz_0.8.4-5.1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. --- End Message --- --- Begin Message --- Source: compiz Source-Version: 0.8.4-5.2 We believe that the bug you reported is fixed in the latest version of compiz, which is due to be installed in the Debian FTP archive: compiz-core_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-core_0.8.4-5.2_amd64.deb compiz-dev_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-dev_0.8.4-5.2_amd64.deb compiz-gtk_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-gtk_0.8.4-5.2_amd64.deb compiz-kde_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-kde_0.8.4-5.2_amd64.deb compiz-plugins_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-plugins_0.8.4-5.2_amd64.deb compiz_0.8.4-5.2.diff.gz to main/c/compiz/compiz_0.8.4-5.2.diff.gz compiz_0.8.4-5.2.dsc to main/c/compiz/compiz_0.8.4-5.2.dsc compiz_0.8.4-5.2_all.deb to main/c/compiz/compiz_0.8.4-5.2_all.deb libdecoration0-dev_0.8.4-5.2_amd64.deb to main/c/compiz/libdecoration0-dev_0.8.4-5.2_amd64.deb libdecoration0_0.8.4-5.2_amd64.deb to main/c/compiz/libdecoration0_0.8.4-5.2_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 671...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Matthias Klose (supplier of updated compiz package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 08:51:01 + Source: compiz Binary: compiz compiz-core compiz-dev compiz-gtk compiz-kde compiz-plugins libdecoration0 libdecoration0-dev Architecture: source all amd64 Version: 0.8.4-5.2 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force Changed-By: Matthias Klose Description: compiz - OpenGL window and compositing manager compiz-core - OpenGL window and compositing manager compiz-dev - OpenGL window and compositing manager - development files compiz-gtk - OpenGL window and compositing manager - Gtk window decorator compiz-kde - OpenGL window and compositing manager - KDE window decorator compiz-plugins - OpenGL window and compositing manager - plugins libdecoration0 - Compiz window decoration library libdecoration0-dev - Compiz window de
compiz_0.8.4-5.2_amd64.changes ACCEPTED into unstable
Accepted: compiz-core_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-core_0.8.4-5.2_amd64.deb compiz-dev_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-dev_0.8.4-5.2_amd64.deb compiz-gtk_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-gtk_0.8.4-5.2_amd64.deb compiz-kde_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-kde_0.8.4-5.2_amd64.deb compiz-plugins_0.8.4-5.2_amd64.deb to main/c/compiz/compiz-plugins_0.8.4-5.2_amd64.deb compiz_0.8.4-5.2.diff.gz to main/c/compiz/compiz_0.8.4-5.2.diff.gz compiz_0.8.4-5.2.dsc to main/c/compiz/compiz_0.8.4-5.2.dsc compiz_0.8.4-5.2_all.deb to main/c/compiz/compiz_0.8.4-5.2_all.deb libdecoration0-dev_0.8.4-5.2_amd64.deb to main/c/compiz/libdecoration0-dev_0.8.4-5.2_amd64.deb libdecoration0_0.8.4-5.2_amd64.deb to main/c/compiz/libdecoration0_0.8.4-5.2_amd64.deb Changes: compiz (0.8.4-5.2) unstable; urgency=low . * Non-maintainer upload. * Fix build failure with GCC 4.7 (Sebastian Ramacher). Closes: #671995. Override entries for your package: compiz-core_0.8.4-5.2_amd64.deb - optional x11 compiz-dev_0.8.4-5.2_amd64.deb - optional x11 compiz-gtk_0.8.4-5.2_amd64.deb - optional x11 compiz-kde_0.8.4-5.2_amd64.deb - optional x11 compiz-plugins_0.8.4-5.2_amd64.deb - optional x11 compiz_0.8.4-5.2.dsc - source x11 compiz_0.8.4-5.2_all.deb - optional x11 libdecoration0-dev_0.8.4-5.2_amd64.deb - optional libdevel libdecoration0_0.8.4-5.2_amd64.deb - optional x11 Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 671995 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1szimk-0001fw...@franck.debian.org
Bug#675022: Frequent lockups when using icedove (thunderbird)
Package: xserver-xorg-video-intel Version: 2:2.19.0-1 Severity: grave Since upgrading xserver-xorg-video-intel from 2:2.18.0-2 to 2:2.19.0-1 I get frequent lookups of X. So far this always happened when opening a large email folder in icedove(thunderbird). At this point the desktop is completely frozen and the system no longer reacts on keyboard input. I can still move the mouse, but X no longer reacts on clicks. This both happened in a composited DE (gnome-shell) and a non-composited DE (gnome-fallback/metacity). Downgrading to 2:2.18.0-2 reliably fixes the problem for me. My system is a X220 sandy bridge laptop, i.e a HD 3000 integrated graphics card. When the lockup happens I get a Xorg backtrace in Xorg.0.log (attached) As this particular error happened several times a day and I had to hard-reset my laptop, I'm filing with RC severity. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Nov 11 2011 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2044664 May 20 10:59 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 Kernel version (/proc/version): --- Linux version 3.2.0-2-amd64 (Debian 3.2.18-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon May 21 17:45:41 UTC 2012 Xorg X server log files on system: -- -rw-r--r-- 1 root root 42647 May 20 23:56 /var/log/Xorg.1.log -rw-r--r-- 1 root root 56472 May 29 12:04 /var/log/Xorg.0.log udev information: - P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: UDEV_LOG=3 E: USEC_INITIALIZED=12086995 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event4 N: input/event4 E: BACKSPACE=guess E: DEVNAME=/dev/input/event4 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event4 E: DMI_VENDOR=LENOVO E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: MAJOR=13 E: MINOR=68 E: SUBSYSTEM=input E: UDEV_LOG=3 E: USEC_INITIALIZED=12292596 E: XKBLAYOUT=de E: XKBMODEL=pc105 E: XKBVARIANT=nodeadkeys P: /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXVIDEO_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: KEY=3e000b 0 0 0 E: MODALIAS=input:b0019vp0006e-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw E: NAME="Video Bus" E: PHYS="LNXVIDEO/video/input0" E: PRODUCT=19/0/6/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: UDEV_LOG=3 E: USEC_INITIALIZED=14014544 P: /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11/event11 N: input/event11 E: BACKSPACE=guess E: DEVNAME=/dev/input/event11 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11/event11 E: DMI_VENDOR=LENOVO E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: MAJOR=13 E: MINOR=75 E: SUBSYSTEM=input E: UDEV_LOG=3 E: USEC_INITIALIZED=14017133 E: XKBLAYOUT=de E: XKBMODEL=pc105 E: XKBVARIANT=nodeadkeys P: /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2 E: EV=21 E: ID_FOR_SEAT=input-acpi-PNP0C0D_00 E: ID_INPUT=1 E: ID_PATH=acpi-PNP0C0D:00 E: ID_PATH_TAG=acpi-PNP0C0D_00 E: MODALIAS=input:b0019vp0005e-e0,5,kramlsfw0, E: NAME="Lid Switch" E: PHYS="PNP0C0D/button/input0" E: PRODUCT=19/0/5/0 E: PROP=0 E: SUBSYSTEM=input E: SW=1 E: TAGS=:seat: E: UDEV_LOG=3 E: USEC_INITIALIZED=12084770 P: /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2/event2 N: input/event2 E: DEVNAME=/dev/input/event2 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2/event2 E: ID_INPUT=1 E: ID_PATH=acpi-PNP0C0D:00 E: ID_PATH_TAG=acpi-PNP0C0D_00 E: MAJOR=13 E: MINOR=66 E: SUBSYSTEM=input E: UDEV_LOG=3 E: USEC_INITIALIZED=12087029 P: /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3 E: EV=3 E: ID_FOR_SEAT=input-acpi-PNP0C0E_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0E:00 E: ID_PATH_TAG=acpi-PNP0C0E_00 E: KEY=4000 0 0 E: MODALIAS=input:b0019v0
Processed: Re: Bug#675022: Acknowledgement (Frequent lockups when using icedove (thunderbird))
Processing commands for cont...@bugs.debian.org: > forwarded 675022 https://bugs.freedesktop.org/show_bug.cgi?id=50455 Bug #675022 [xserver-xorg-video-intel] Frequent lockups when using icedove (thunderbird) Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=50455'. > thanks Stopping processing here. Please contact me if you need assistance. -- 675022: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675022 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.1338293552.transcr...@bugs.debian.org
Bug#675022: Acknowledgement (Frequent lockups when using icedove (thunderbird))
I can confirm that the proposed fix to disable FBC worked for me. Since i915.i915_enable_fbc=0, the GPU hangs didn't occur again. I'm wondering if xserver-xorg-video-intel should ship a modprobe file accordingly or if it is feasible to backport the fixes in 3.4 that were briefly mentioned in the upstream bug report. [1] https://bugs.freedesktop.org/show_bug.cgi?id=50455#c9 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: base: System freezes at random time after Resume from Suspend (Regression)
On Sunday, May 20, 2012 07:32:10 Jonathan Nieder wrote: > Hi Andreas, > > Jonathan Nieder wrote: > > Andreas Berger wrote: > >> ok, i narrowed it down, but it is: > >> > >> found: linux-image-2.6.36-trunk-686, version 2.6.36-1~experimental.1 > >> not found: linux-image-2.6.37-rc4-686, version > >> 2.6.37~rc4-1~experimental.1 > > > > Unfortunately there are a lot of interesting patches in that range, > > so we will probably need a little more data to track this down. So > > > I suggested: > [...] > > > - suspending from single-user mode (kernel params "single debug") > > > >or from an initramfs shell (kernel param "break=top") to see if > >the same problem occurs even if the i915 driver is not loaded > >yet when the suspend/hibernate happens > > Thanks again for all your help narrowing the bug down this far. > > Did you get a chance to try this? > > Curious, > Jonathan i'm sorry i didn't respond in quite a while. unfortunately, the spare harddrive that i've been using for this died on me and i can't use my remaining (productive) system for this. also, the laptop itself will probably fail soon (having random power blackouts and the case is coming apart everywhere). out of curiousity, is the scope of this still to make a patch for squeeze? seeing as i seem to be the only one affected by this... greetings, andreas signature.asc Description: This is a digitally signed message part.
Re: base: System freezes at random time after Resume from Suspend (Regression)
Andreas Berger wrote: > out of curiousity, is the scope of this still to make a patch for squeeze? Yep, squeeze still has at least a year of life in it yet. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529173923.GE17455@burratino
Processed: reassign 674965 to libgl1-mesa-dri
Processing commands for cont...@bugs.debian.org: > reassign 674965 libgl1-mesa-dri Bug #674965 [mesa-utils] /usr/bin/glxinfo: glxinfo gives PIPE_CAP warning Bug reassigned from package 'mesa-utils' to 'libgl1-mesa-dri'. No longer marked as found in versions mesa-demos/8.0.1-2. Ignoring request to alter fixed versions of bug #674965 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 674965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133832162817248.transcr...@bugs.debian.org
xserver-xorg-video-nouveau: Changes to 'upstream-unstable'
src/Makefile.am |1 + src/compat-api.h | 41 + src/drmmode_display.c | 16 src/nouveau_dri2.c| 20 ++-- src/nouveau_exa.c | 14 +++--- src/nouveau_xv.c | 16 src/nv04_exa.c| 14 +++--- src/nv10_exa.c|8 src/nv30_exa.c|6 +++--- src/nv40_exa.c|6 +++--- src/nv50_accel.c |2 +- src/nv50_exa.c|2 +- src/nv_accel_common.c |2 +- src/nv_dma.c |6 ++ src/nv_driver.c |4 ++-- src/nv_include.h |2 ++ src/nvc0_exa.c|2 +- src/vl_hwmc.c |6 -- 18 files changed, 110 insertions(+), 58 deletions(-) New commits: commit ace77b6b1304826f4004bde23809b55d476b0615 Author: Ben Skeggs Date: Tue May 29 21:21:57 2012 +1000 disable fermi accel on 0.0.16 interface Kepler accel support broke some assumption made by the older kernel interface, and Fermi shares the same code. It can't work (without some annoying hacks anyway) with the 0.0.16 kernel anymore. diff --git a/src/nv_dma.c b/src/nv_dma.c index 3b75ca9..1757f4d 100644 --- a/src/nv_dma.c +++ b/src/nv_dma.c @@ -36,6 +36,12 @@ NVInitDma(ScrnInfoPtr pScrn) int size, ret; void *data; + if (pNv->dev->drm_version < 0x0100 && pNv->dev->chipset >= 0xc0) { + xf86DrvMsg(pScrn->scrnIndex, X_ERROR, + "Fermi acceleration not supported on old kernel\n"); + return FALSE; + } + if (pNv->Architecture < NV_ARCH_C0) { data = &nv04_data; size = sizeof(nv04_data); commit 7041e30ab8beb627bbf569367961a658e79c2bdc Author: Dave Airlie Date: Wed May 23 14:18:24 2012 +0100 vl_hwmc: add missing compat include. Reported-by: tallica on irc. Signed-off-by: Dave Airlie diff --git a/src/vl_hwmc.c b/src/vl_hwmc.c index 32eb258..ecad0b4 100644 --- a/src/vl_hwmc.c +++ b/src/vl_hwmc.c @@ -9,6 +9,8 @@ #include #include +#include "compat-api.h" + #define FOURCC_RGB 0x003 #define XVIMAGE_RGB \ { \ commit 2abf8467cfb7a7648ce73ba5bcbbc62219d65d6d Author: Dave Airlie Date: Wed May 23 11:29:05 2012 +0100 nouveau: add compat-api.h to makefile. Signed-off-by: Dave Airlie diff --git a/src/Makefile.am b/src/Makefile.am index 0bdd780..6aeb486 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -60,6 +60,7 @@ nouveau_drv_la_SOURCES = \ nvc0_exa.c \ nvc0_xv.c \ drmmode_display.c \ +compat-api.h \ vl_hwmc.c \ vl_hwmc.h commit 1d861ad716861c57b2b81531d21840d7c8de024b Author: Dave Airlie Date: Wed May 23 11:15:06 2012 +0100 nouveau: convert two more xf86Screens access to macros for some reason the script missed these two, just fix them manually. Signed-off-by: Dave Airlie diff --git a/src/nv50_exa.c b/src/nv50_exa.c index cd99e10..1212eb6 100644 --- a/src/nv50_exa.c +++ b/src/nv50_exa.c @@ -27,7 +27,7 @@ #include "nv50_accel.h" #define NV50EXA_LOCALS(p) \ - ScrnInfoPtr pScrn = xf86Screens[(p)->drawable.pScreen->myNum]; \ + ScrnInfoPtr pScrn = xf86ScreenToScrn((p)->drawable.pScreen); \ NVPtr pNv = NVPTR(pScrn); \ struct nouveau_pushbuf *push = pNv->pushbuf; (void)push; diff --git a/src/nvc0_exa.c b/src/nvc0_exa.c index c68b3fb..9d23a91 100644 --- a/src/nvc0_exa.c +++ b/src/nvc0_exa.c @@ -28,7 +28,7 @@ #define NOUVEAU_BO(a, b, c) (NOUVEAU_BO_##a | NOUVEAU_BO_##b | NOUVEAU_BO_##c) #define NVC0EXA_LOCALS(p) \ - ScrnInfoPtr pScrn = xf86Screens[(p)->drawable.pScreen->myNum]; \ + ScrnInfoPtr pScrn = xf86ScreenToScrn((p)->drawable.pScreen); \ NVPtr pNv = NVPTR(pScrn); \ struct nouveau_pushbuf *push = pNv->pushbuf; (void)push; commit 5625fb84efc699e65da0062ae101915a49f2969b Author: Dave Airlie Date: Wed May 23 11:13:30 2012 +0100 nouveau: convert scrn/screen to using new interfaces This commit was generated with the util/modular/x-driver-screen-scrn-conv.sh Signed-off-by: Dave Airlie diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 23e8232..7211427 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -117,7 +117,7 @@ static PixmapPtr drmmode_pixmap_wrap(ScreenPtr pScreen, int width, int height, int depth, int bpp, int pitch, struct nouveau_bo *bo, void *data)
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Tue, May 29, 2012 at 12:02:14AM +0200, Cyril Brulebois wrote: > The dependency in squeeze (and in other suites) is: > ati→{mach64,r128,radeon} > > there's no: > radeon→ati OK, my bad - surely some confusion on my side. > > But the result is, GLX is entirely disabled, and we can see a "fail to > > loat ati" messge in the log. Reinstalling them (Xorg.1.log.old > > attached) suppresses the message, and shows much better init of > > DRI/GLX stuff. Removing again just the -ati package, and those stop > > to work again (Xorg.1.log attached). > > ati is a wrapper which does the right thing, don't remove it. Or set > radeon as driver in xorg.conf if you insist on doing so (man radeon). OK I understand that there is no absolute requirement for -ati, and thus a Depends is probably not a good idea for some users. But for the vast majority, who will want to use it, what about adding a note in package descriptions of {mach64,r128,radeon} that the -ati package is required to avoid manual Xorg configuration ? Adding somewhere the suggestion to set the driver in xorg.conf (package desc or manpage), to avoid depending on -ati, would also be a good idea. Even then, why this Depends of ati on all 3 drivers ? I can "dpkg -r --force-depends" both mach64 and r128, and ati+radeon does startup without complaining at all. Shouldn't this be downgraded to a Recommends as well ? The current situation just makes some people (eg. me ;) break the dependency link that's the weakest to get rid of useless drivers, with the results described in my original report. If I check the Policy about Depends, "This declares an absolute dependency", which is clearly not the case here. Even the official definition of Recommends makes me wonder if it would not be too strong. After all, someone with a radeon is likely to select the readon driver, then the ati wrapper will be selected as Recommended, but the latter should IMHO have no reason to pull mach64 and r128, that would not fit the "packages that would be found together with this one in all but unusual installations" criteria. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529213257.gu9...@home.lan
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
Yann Dirson (29/05/2012): > OK I understand that there is no absolute requirement for -ati, and > thus a Depends is probably not a good idea for some users. But for > the vast majority, who will want to use it, what about adding a note > in package descriptions of {mach64,r128,radeon} that the -ati package > is required to avoid manual Xorg configuration ? Adding somewhere the > suggestion to set the driver in xorg.conf (package desc or manpage), > to avoid depending on -ati, would also be a good idea. Good thing is: we already have xserver-xorg-video-all which covers the needs for the vast majority, by pulling -ati. Besides that, patches welcome: debcheckout xserver-xorg-video-ati (mailto: 674...@bugs.debian.org, plus debian-x@ if you want to make sure) > Even then, why this Depends of ati on all 3 drivers ? I can "dpkg -r > --force-depends" both mach64 and r128, and ati+radeon does startup > without complaining at all. Shouldn't this be downgraded to a > Recommends as well ? This is very fine for you. What about mach64 and r128 users? Then we'll get reports from people turning off Recommends. The usual fine line, between Depends and Recommends, etc. Depends means being safer. > The current situation just makes some people (eg. me ;) break the > dependency link that's the weakest to get rid of useless drivers, with > the results described in my original report. What are you gaining? $ for f in $(dpkg -L xserver-xorg-video-r128); do if [ -f $f ]; then ls -lh $f; fi; done|awk '{print $5}' 110K 5.1K 676 6.0K 117K 2.2K 27 > If I check the Policy about Depends, "This declares an absolute > dependency", which is clearly not the case here. Even the official > definition of Recommends makes me wonder if it would not be too > strong. After all, someone with a radeon is likely to select the > readon driver, then the ati wrapper will be selected as Recommended, > but the latter should IMHO have no reason to pull mach64 and r128, > that would not fit the "packages that would be found together with > this one in all but unusual installations" criteria. The current situation ensures that X works by default. People can still select this or that driver manually as explained previously, so it looks to me like the current relationships are fine (and have been for I think many years). Mraw, KiBi. signature.asc Description: Digital signature
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Tue, May 29, 2012 at 11:45:45PM +0200, Cyril Brulebois wrote: > > Even then, why this Depends of ati on all 3 drivers ? I can "dpkg -r > > --force-depends" both mach64 and r128, and ati+radeon does startup > > without complaining at all. Shouldn't this be downgraded to a > > Recommends as well ? > > This is very fine for you. What about mach64 and r128 users? Then we'll > get reports from people turning off Recommends. The usual fine line, > between Depends and Recommends, etc. Depends means being safer. Well, as users of other video cards, they will be able to select just the driver for their own card, and not eg. radeon. > > The current situation just makes some people (eg. me ;) break the > > dependency link that's the weakest to get rid of useless drivers, with > > the results described in my original report. > > What are you gaining? > $ for f in $(dpkg -L xserver-xorg-video-r128); do if [ -f $f ]; then ls -lh > $f; fi; done|awk '{print $5}' > 110K > 5.1K > 676 > 6.0K > 117K > 2.2K > 27 > > > If I check the Policy about Depends, "This declares an absolute > > dependency", which is clearly not the case here. Even the official > > definition of Recommends makes me wonder if it would not be too > > strong. After all, someone with a radeon is likely to select the > > readon driver, then the ati wrapper will be selected as Recommended, > > but the latter should IMHO have no reason to pull mach64 and r128, > > that would not fit the "packages that would be found together with > > this one in all but unusual installations" criteria. > > The current situation ensures that X works by default. People can still > select this or that driver manually as explained previously, so it looks > to me like the current relationships are fine (and have been for I think > many years). At least downgrading to Recommends would keep things working by default. And even downgrading to Suggests, together with -all depending on {radeon,r128,mach64}, would keep things working by default - while allowing those who don't want extra stuff to avoid cruft. > Besides that, patches welcome: debcheckout xserver-xorg-video-ati > (mailto: 674...@bugs.debian.org, plus debian-x@ if you want to make sure) OK :) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529223020.gv9...@home.lan
xserver-xorg-video-nouveau: Changes to 'debian-unstable'
debian/changelog |4 ++-- src/Makefile.am |1 + src/compat-api.h | 41 + src/drmmode_display.c | 16 src/nouveau_dri2.c| 20 ++-- src/nouveau_exa.c | 14 +++--- src/nouveau_xv.c | 16 src/nv04_exa.c| 14 +++--- src/nv10_exa.c|8 src/nv30_exa.c|6 +++--- src/nv40_exa.c|6 +++--- src/nv50_accel.c |2 +- src/nv50_exa.c|2 +- src/nv_accel_common.c |2 +- src/nv_dma.c |6 ++ src/nv_driver.c |4 ++-- src/nv_include.h |2 ++ src/nvc0_exa.c|2 +- src/vl_hwmc.c |6 -- 19 files changed, 112 insertions(+), 60 deletions(-) New commits: commit 4c1bd9a108f66b02a6c10a04bc77c57aac7f44bd Author: Maarten Lankhorst Date: Tue May 29 14:06:27 2012 +0200 New upstream snapshot diff --git a/debian/changelog b/debian/changelog index e96e86b..e55f6d8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,11 +1,11 @@ -xserver-xorg-video-nouveau (1:0.0.16+git20120523+5815644-1) UNRELEASED; urgency=low +xserver-xorg-video-nouveau (1:0.0.16+git20120529+ace77b6-1) UNRELEASED; urgency=low [ Maarten Lankhorst ] * New upstream snapshot. First one to have the new ABI. * Add 02-drm-nouveau-newabi.patch to build with old libdrm - Until mesa 8.1 is released, we cannot build with new libdrm yet - -- Maarten Lankhorst Wed, 23 May 2012 09:45:06 +0200 + -- Maarten Lankhorst Wed, 29 May 2012 14:05:06 +0200 xserver-xorg-video-nouveau (1:0.0.16+git20120322+ab7291d-1) unstable; urgency=low commit ace77b6b1304826f4004bde23809b55d476b0615 Author: Ben Skeggs Date: Tue May 29 21:21:57 2012 +1000 disable fermi accel on 0.0.16 interface Kepler accel support broke some assumption made by the older kernel interface, and Fermi shares the same code. It can't work (without some annoying hacks anyway) with the 0.0.16 kernel anymore. diff --git a/src/nv_dma.c b/src/nv_dma.c index 3b75ca9..1757f4d 100644 --- a/src/nv_dma.c +++ b/src/nv_dma.c @@ -36,6 +36,12 @@ NVInitDma(ScrnInfoPtr pScrn) int size, ret; void *data; + if (pNv->dev->drm_version < 0x0100 && pNv->dev->chipset >= 0xc0) { + xf86DrvMsg(pScrn->scrnIndex, X_ERROR, + "Fermi acceleration not supported on old kernel\n"); + return FALSE; + } + if (pNv->Architecture < NV_ARCH_C0) { data = &nv04_data; size = sizeof(nv04_data); commit 7041e30ab8beb627bbf569367961a658e79c2bdc Author: Dave Airlie Date: Wed May 23 14:18:24 2012 +0100 vl_hwmc: add missing compat include. Reported-by: tallica on irc. Signed-off-by: Dave Airlie diff --git a/src/vl_hwmc.c b/src/vl_hwmc.c index 32eb258..ecad0b4 100644 --- a/src/vl_hwmc.c +++ b/src/vl_hwmc.c @@ -9,6 +9,8 @@ #include #include +#include "compat-api.h" + #define FOURCC_RGB 0x003 #define XVIMAGE_RGB \ { \ commit 2abf8467cfb7a7648ce73ba5bcbbc62219d65d6d Author: Dave Airlie Date: Wed May 23 11:29:05 2012 +0100 nouveau: add compat-api.h to makefile. Signed-off-by: Dave Airlie diff --git a/src/Makefile.am b/src/Makefile.am index 0bdd780..6aeb486 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -60,6 +60,7 @@ nouveau_drv_la_SOURCES = \ nvc0_exa.c \ nvc0_xv.c \ drmmode_display.c \ +compat-api.h \ vl_hwmc.c \ vl_hwmc.h commit 1d861ad716861c57b2b81531d21840d7c8de024b Author: Dave Airlie Date: Wed May 23 11:15:06 2012 +0100 nouveau: convert two more xf86Screens access to macros for some reason the script missed these two, just fix them manually. Signed-off-by: Dave Airlie diff --git a/src/nv50_exa.c b/src/nv50_exa.c index cd99e10..1212eb6 100644 --- a/src/nv50_exa.c +++ b/src/nv50_exa.c @@ -27,7 +27,7 @@ #include "nv50_accel.h" #define NV50EXA_LOCALS(p) \ - ScrnInfoPtr pScrn = xf86Screens[(p)->drawable.pScreen->myNum]; \ + ScrnInfoPtr pScrn = xf86ScreenToScrn((p)->drawable.pScreen); \ NVPtr pNv = NVPTR(pScrn); \ struct nouveau_pushbuf *push = pNv->pushbuf; (void)push; diff --git a/src/nvc0_exa.c b/src/nvc0_exa.c index c68b3fb..9d23a91 100644 --- a/src/nvc0_exa.c +++ b/src/nvc0_exa.c @@ -28,7 +28,7 @@ #define NOUVEAU_BO(a, b, c) (NOUVEAU_BO_##a | NOUVEAU_BO_##b | NOUVEAU_BO_##c) #define NVC0EXA_LOCALS(p) \ - ScrnI
Bug#675138: weston: not installable, fails to build from source
Package: weston Version: 0.85.0-1 Severity: serious Justification: Policy 5.6.10 Dear Maintainer, package weston (0.85.0-1) is currently uninstallable due to a depend (=0.85.0-1) on libwayland0. This depend should read (=0.85.0-2) or (>= 0.85.0-1). The package also fails to build from source, some libpng12 vs. libpng15 issues. See https://buildd.debian.org/status/package.php?p=weston&suite=experimental Regards, Tim -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages weston depends on: ii libc6 2.13-32 ii libcairo2 1.12.2-1 ii libdrm2 2.4.33-1 ii libegl1-mesa 8.0.2-2 ii libegl1-mesa-drivers 8.0.2-2 ii libgbm1 8.0.2-2 ii libgdk-pixbuf2.0-02.26.1-1 ii libgles2-mesa 8.0.2-2 ii libglib2.0-0 2.32.3-1 ii libjpeg8 8d-1 ii libpixman-1-0 0.24.4-1 ii libpng12-01.2.49-1 ii libudev0 175-3.1 ii libwayland0 0.85.0-2 ii libx11-6 2:1.4.99.901-2 ii libx11-xcb1 2:1.4.99.901-2 ii libxcb-render01.8.1-1 ii libxcb-shape0 1.8.1-1 ii libxcb-xfixes01.8.1-1 ii libxcb1 1.8.1-1 ii libxkbcommon0 0.1.0~1-1 weston recommends no packages. weston suggests no packages. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530060617.4706.62369.reportbug@desktop
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
Hey, Op 30-05-12 00:30, Yann Dirson schreef: > On Tue, May 29, 2012 at 11:45:45PM +0200, Cyril Brulebois wrote: >>> Even then, why this Depends of ati on all 3 drivers ? I can "dpkg -r >>> --force-depends" both mach64 and r128, and ati+radeon does startup >>> without complaining at all. Shouldn't this be downgraded to a >>> Recommends as well ? >> This is very fine for you. What about mach64 and r128 users? Then we'll >> get reports from people turning off Recommends. The usual fine line, >> between Depends and Recommends, etc. Depends means being safer. > Well, as users of other video cards, they will be able to select just > the driver for their own card, and not eg. radeon. If you only want to use -radeon, install a custom xorg.conf that references radeon directly. The X server will pick 'ati' in autodetect mode, which will forward to the correct driver. >>> The current situation just makes some people (eg. me ;) break the >>> dependency link that's the weakest to get rid of useless drivers, with >>> the results described in my original report. >> What are you gaining? >> $ for f in $(dpkg -L xserver-xorg-video-r128); do if [ -f $f ]; then ls -lh >> $f; fi; done|awk '{print $5}' >> 110K >> 5.1K >> 676 >> 6.0K >> 117K >> 2.2K >> 27 >> >>> If I check the Policy about Depends, "This declares an absolute >>> dependency", which is clearly not the case here. Even the official >>> definition of Recommends makes me wonder if it would not be too >>> strong. After all, someone with a radeon is likely to select the >>> readon driver, then the ati wrapper will be selected as Recommended, >>> but the latter should IMHO have no reason to pull mach64 and r128, >>> that would not fit the "packages that would be found together with >>> this one in all but unusual installations" criteria. >> The current situation ensures that X works by default. People can still >> select this or that driver manually as explained previously, so it looks >> to me like the current relationships are fine (and have been for I think >> many years). > At least downgrading to Recommends would keep things working by > default. And even downgrading to Suggests, together with -all > depending on {radeon,r128,mach64}, would keep things working by > default - while allowing those who don't want extra stuff to avoid > cruft. > The extra cruft of a few 100kb? Make your own xorg.conf and remove ati. You'll sacrifice auto config but whatever is more important to you. :-) ~Maarten -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc5bf4b.50...@canonical.com