Re: [PATCH 00/18] Xfbdev Atari and Amiga support
On 04/24/13 10:00 PM, Keith Packard wrote: Alan Coopersmith writes: On 04/24/13 06:58 PM, Keith Packard wrote: Alan Coopersmith writes: This broke my build: Undefined first referenced symbol in file c2p_unsupported ../../../miext/shadow/.libs/libshadow.a(shafb4.o) Builds fine with GCC; perhaps that figures out that this function can never be called? If I build with gcc 4.7.2 with -O2 it indeed optimizes it out. If I build with gcc 4.7.2 with -g and no -O flags, it fails the same way. That makes sense at least. We could either make c2p_unsupported call FatalError or just be a no-op. Any preference? I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why stuff isn't working, though FatalError() also works for something that should be impossible to hit. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc -- 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/5178bdb9.6090...@oracle.com
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
Hi Alan,
On Thu, Apr 25, 2013 at 7:42 AM, Alan Coopersmith
wrote:
> On 04/24/13 10:28 PM, Geert Uytterhoeven wrote:
>> On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith
>> wrote:
>>> On 04/24/13 10:00 PM, Keith Packard wrote:
Alan Coopersmith writes:
> On 04/24/13 06:58 PM, Keith Packard wrote:
>> Alan Coopersmith writes:
>>> This broke my build:
>>>
>>> Undefined first referenced
>>> symbol in file
>>> c2p_unsupported
>>> ../../../miext/shadow/.libs/libshadow.a(shafb4.o)
>>
>> Builds fine with GCC; perhaps that figures out that this function can
>> never be called?
>
> If I build with gcc 4.7.2 with -O2 it indeed optimizes it out.
> If I build with gcc 4.7.2 with -g and no -O flags, it fails the same
> way.
>>
>> Sorry, I forgot that unlike Linux kernel people, xorg people sometimes
>> do compile
>> without optimization.
>
> Or in the case I first hit this, with optimization using compilers that
> aren't gcc. (Xorg is built on several non-Linux platforms, with compilers
> such as clang or Solaris Studio.)
Right.
That makes sense at least. We could either make c2p_unsupported call
FatalError or just be a no-op. Any preference?
>>>
>>> I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why
>>> stuff isn't working, though FatalError() also works for something that
>>> should be impossible to hit.
>>
>>
>> Or assert(), or .
>>
>> This should be indeed impossible to hit, as all calls to the c2p functions
>> use hardcoded parameters.
>>
>> I'm just a bit afraid that adding real error handling will slow down the
>> code.
>> Can it be dependent on DEBUG or so?
>
> Does it matter if the compiler optimizes out the call to c2p_unsupported?
> The performance should be the same for you.
Indeed, I forgot about that (just grabbing my morning coffee).
> Or does this code even need to be built for non-68k platforms at all?
No. I don't think Xfbdev already limits some options to certain platforms?
> (I'm still confused why we just took a big chunk of code for a platform
> with no active maintainer, but if Keith's willing to maintain it himself,
> that's his call. I do hope we can fix the license before release to be
> a standard license, not yet another one-off we all have to add to our
> packages to comply with the terms of.)
I'm open for license changes. What's the recommended one?
But e.g. shiplan2p8.c was based on shpacked.c, so I mimicked its license
on shpacked.c, and refered to that file.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/camuhmdvmro4ogxmpvk-arvtl8po8knrymhbf1p+pklbxwax...@mail.gmail.com
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
On 04/24/13 10:28 PM, Geert Uytterhoeven wrote: On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith wrote: On 04/24/13 10:00 PM, Keith Packard wrote: Alan Coopersmith writes: On 04/24/13 06:58 PM, Keith Packard wrote: Alan Coopersmith writes: This broke my build: Undefined first referenced symbol in file c2p_unsupported ../../../miext/shadow/.libs/libshadow.a(shafb4.o) Builds fine with GCC; perhaps that figures out that this function can never be called? If I build with gcc 4.7.2 with -O2 it indeed optimizes it out. If I build with gcc 4.7.2 with -g and no -O flags, it fails the same way. Sorry, I forgot that unlike Linux kernel people, xorg people sometimes do compile without optimization. Or in the case I first hit this, with optimization using compilers that aren't gcc. (Xorg is built on several non-Linux platforms, with compilers such as clang or Solaris Studio.) That makes sense at least. We could either make c2p_unsupported call FatalError or just be a no-op. Any preference? I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why stuff isn't working, though FatalError() also works for something that should be impossible to hit. Or assert(), or . This should be indeed impossible to hit, as all calls to the c2p functions use hardcoded parameters. I'm just a bit afraid that adding real error handling will slow down the code. Can it be dependent on DEBUG or so? Does it matter if the compiler optimizes out the call to c2p_unsupported? The performance should be the same for you. Or does this code even need to be built for non-68k platforms at all? (I'm still confused why we just took a big chunk of code for a platform with no active maintainer, but if Keith's willing to maintain it himself, that's his call. I do hope we can fix the license before release to be a standard license, not yet another one-off we all have to add to our packages to comply with the terms of.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc -- 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/5178c230.7020...@oracle.com
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith
wrote:
> On 04/24/13 10:00 PM, Keith Packard wrote:
>> Alan Coopersmith writes:
>>> On 04/24/13 06:58 PM, Keith Packard wrote:
Alan Coopersmith writes:
> This broke my build:
>
> Undefined first referenced
>symbol in file
> c2p_unsupported
> ../../../miext/shadow/.libs/libshadow.a(shafb4.o)
Builds fine with GCC; perhaps that figures out that this function can
never be called?
>>>
>>>
>>> If I build with gcc 4.7.2 with -O2 it indeed optimizes it out.
>>> If I build with gcc 4.7.2 with -g and no -O flags, it fails the same
>>> way.
Sorry, I forgot that unlike Linux kernel people, xorg people sometimes
do compile
without optimization.
>> That makes sense at least. We could either make c2p_unsupported call
>> FatalError or just be a no-op. Any preference?
>
>
> I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why
> stuff isn't working, though FatalError() also works for something that
> should be impossible to hit.
Or assert(), or .
This should be indeed impossible to hit, as all calls to the c2p functions
use hardcoded parameters.
I'm just a bit afraid that adding real error handling will slow down the code.
Can it be dependent on DEBUG or so?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/CAMuHMdXvzq=cdm3oubyge4c5npr1vocinwcf6kdcrymo3do...@mail.gmail.com
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
Alan Coopersmith writes: > On 04/24/13 06:58 PM, Keith Packard wrote: >> Alan Coopersmith writes: >> >>> This broke my build: >>> >>> Undefined first referenced >>> symbol in file >>> c2p_unsupported >>> ../../../miext/shadow/.libs/libshadow.a(shafb4.o) >> >> Builds fine with GCC; perhaps that figures out that this function can >> never be called? > > If I build with gcc 4.7.2 with -O2 it indeed optimizes it out. > If I build with gcc 4.7.2 with -g and no -O flags, it fails the same > way. That makes sense at least. We could either make c2p_unsupported call FatalError or just be a no-op. Any preference? -- keith.pack...@intel.com pgpF9_CL2FR_T.pgp Description: PGP signature
Bug#706114: xfonts-utils: insufficient zlib1g dependency
> So the dependencies are correct. The only problem is due to > gsfonts-x11 postinst's script calling: > > update-fonts-dir > → mkfontdir > → mkfontscale > > While the new xfonts-utils package has been unpacked, but not > configured. This is either a problem in xfonts-utils's > update-fonts-dir, or in debhelper's dh_installxfonts support inserting > those snippets. In terms of getting this fixed quickly for wheezy, couldn't that be addressed with a "Pre-Depends: xfonts-utils" in gsfonts-x11? Best wishes, Mike -- 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/CANTw=mnmvz4wvax_z3cziepkgs+sact_d+bqgbg52nhewu0...@mail.gmail.com
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
Alan Coopersmith writes: > This broke my build: > > Undefined first referenced > symbol in file > c2p_unsupported > ../../../miext/shadow/.libs/libshadow.a(shafb4.o) Builds fine with GCC; perhaps that figures out that this function can never be called? -- keith.pack...@intel.com pgpygAdXeP0Ku.pgp Description: PGP signature
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
This broke my build: Undefined first referenced symbol in file c2p_unsupported ../../../miext/shadow/.libs/libshadow.a(shafb4.o) miext/shadow/c2p_core.h defines c2p_unsupported as an extern function, and calls it from some inline functions, but I see no file defining it. Perhaps a forgotten "git add" of a new source? But then it would also need to be added to a Makefile.am somewhere too. -alan- On Wed, Apr 24, 2013 at 2:15 PM, Keith Packard wrote: > Geert Uytterhoeven writes: > >> Geert Uytterhoeven (16): >> miext/shadow/shpacked.c: Remove unused PickBit() define >> test/input: Fix double-aligned test in dix_valuator_alloc() on m68k >> KDrive: Bail out if screen initialization failed >> Xfbdev: Make char *fbdevDevicePath const >> Xfbdev: Handle unset fix.line_length >> Xfbdev: Add support for monochrome visuals >> Xfbdev: Treat 1 bpp pseudocolor as monochrome >> Shadow: Add c2p core >> Shadow: Add support for Atari iplan2p4 >> Shadow: Add support for Atari iplan2p8 >> Shadow: Add support for Amiga afb4 >> Shadow: Add support for Amiga afb8 >> Xfbdev: Reject unsupported frame buffer types >> Xfbdev: Force shadowfb for frame buffers with non-packed pixels >> Xfbdev: Wire up Atari iplan2p4 and iplan2p8 support >> Xfbdev: Wire up Amiga afb4 and afb8 support > > Merged. >53da26a..7ab98ba master -> master > > -- > keith.pack...@intel.com > > ___ > xorg-de...@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel -- 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/candsp+9bztctbq-g01qzedrrn+bty9p3wwwo84fy7bcyedm...@mail.gmail.com
Processed: reassign 706114 to xfonts-utils
Processing commands for cont...@bugs.debian.org: > reassign 706114 xfonts-utils 1:7.7~1 Bug #706114 [dpkg-dev,xfonts-utils] xfonts-utils: insufficient zlib1g dependency Bug reassigned from package 'dpkg-dev,xfonts-utils' to 'xfonts-utils'. No longer marked as found in versions 1:7.7~1 and dpkg/1.16.10. Ignoring request to alter fixed versions of bug #706114 to the same values previously set Bug #706114 [xfonts-utils] xfonts-utils: insufficient zlib1g dependency Marked as found in versions xfonts-utils/1:7.7~1. > thanks Stopping processing here. Please contact me if you need assistance. -- 706114: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706114 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.136683917121391.transcr...@bugs.debian.org
Re: [PATCH 00/18] Xfbdev Atari and Amiga support
Geert Uytterhoeven writes: > Geert Uytterhoeven (16): > miext/shadow/shpacked.c: Remove unused PickBit() define > test/input: Fix double-aligned test in dix_valuator_alloc() on m68k > KDrive: Bail out if screen initialization failed > Xfbdev: Make char *fbdevDevicePath const > Xfbdev: Handle unset fix.line_length > Xfbdev: Add support for monochrome visuals > Xfbdev: Treat 1 bpp pseudocolor as monochrome > Shadow: Add c2p core > Shadow: Add support for Atari iplan2p4 > Shadow: Add support for Atari iplan2p8 > Shadow: Add support for Amiga afb4 > Shadow: Add support for Amiga afb8 > Xfbdev: Reject unsupported frame buffer types > Xfbdev: Force shadowfb for frame buffers with non-packed pixels > Xfbdev: Wire up Atari iplan2p4 and iplan2p8 support > Xfbdev: Wire up Amiga afb4 and afb8 support Merged. 53da26a..7ab98ba master -> master -- keith.pack...@intel.com pgp8LDlS2WSH8.pgp Description: PGP signature
Bug#706114: xfonts-utils: insufficient zlib1g dependency
Control: reassign -1 xfonts-utils/1:7.7~1 On Wed, 2013-04-24 at 22:18:59 +0200, Andreas Beckmann wrote: > Package: dpkg-dev,xfonts-utils > Version: 1:7.7~1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > Control: found -1 1.16.10 > during an upgrade test with piuparts I noticed misbehavior of > mkfontscale (which was ignored and therefore the upgrade did not fail): > > Preparing to replace xfonts-utils 1:7.5+2 (using > .../xfonts-utils_1%3a7.7~1_amd64.deb) ... > Unpacking replacement xfonts-utils ... > Preparing to replace gsfonts-x11 0.21 (using .../gsfonts-x11_0.22_all.deb) > ... > Unpacking replacement gsfonts-x11 ... > mkfontscale: /usr/lib/libz.so.1: version `ZLIB_1.2.5.2' not found (required > by /usr/lib/x86_64-linux-gnu/libfontenc.so.1) > Selecting previously unselected package libijs-0.35. > Unpacking libijs-0.35 (from .../libijs-0.35_0.35-8_amd64.deb) ... > ... > Preparing to replace zlib1g 1:1.2.3.4.dfsg-3 (using > .../zlib1g_1%3a1.2.7.dfsg-13_amd64.deb) ... > Unpacking replacement zlib1g:amd64 ... > > The symbols file has >ZLIB_1.2.5.2@ZLIB_1.2.5.2 1:1.2.6 > but xfonts-utils has > Depends: ... , zlib1g (>= 1:1.1.4), ... > > Rebuilding xfonts-utils does not change the dependency, so there seems > to be a toolchain problem somewhere. > Therefore I'm assigning to both dpkg-dev (for dpkg-shlibdeps) and > xfonts-utils. The problem is with libfontenc.so.1, not mkfontscale: $ objdump -p /usr/lib/x86_64-linux-gnu/libfontenc.so.1 | grep ZLIB 0x07e5d032 0x00 04 ZLIB_1.2.5.2 $ objdump -p /usr/bin/mkfontscale | grep ZLIB $ dpkg -s libfontenc1:amd64 | grep '^Depends:' Depends: libc6 (>= 2.7), zlib1g (>= 1:1.2.6) So the dependencies are correct. The only problem is due to gsfonts-x11 postinst's script calling: update-fonts-dir → mkfontdir → mkfontscale While the new xfonts-utils package has been unpacked, but not configured. This is either a problem in xfonts-utils's update-fonts-dir, or in debhelper's dh_installxfonts support inserting those snippets. Please, feel free to reassign if I missed something broken in dpkg-dev. Thanks, Guillem -- 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/20130424210447.ga16...@gaara.hadrons.org
Processed: xfonts-utils: insufficient zlib1g dependency
Processing control commands: > found -1 1.16.10 Bug #706114 [dpkg-dev,xfonts-utils] xfonts-utils: insufficient zlib1g dependency There is no source info for the package 'xfonts-utils' at version '1.16.10' with architecture '' Marked as found in versions dpkg/1.16.10. -- 706114: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706114 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.b.136683474823018.transcr...@bugs.debian.org
mesa-demos: Changes to 'debian-unstable'
.gitignore | 36 CMakeLists.txt | 154 Makefile.am |3 SConstruct | 144 autogen.sh | 13 common.py| 64 configure.ac | 137 debian/changelog |7 debian/control |2 dev/null |binary index.html | 172 m4/ac_define_dir.m4 | 49 src/CMakeLists.txt | 31 src/Makefile.am |2 src/SConscript | 54 src/data/CMakeLists.txt |3 src/data/Makefile.am | 40 src/data/arch.rgb|binary src/data/bw.rgb |binary src/data/geartrain.dat | 119 src/data/girl.rgb|binary src/data/girl2.rgb |binary src/data/isosurf.dat | 7179 +++ src/data/reflect.rgb |binary src/data/s128.rgb|binary src/data/terrain.dat |1 src/data/tile.rgb|binary src/data/tree2.rgba |binary src/data/tree3.rgb |binary src/data/wrs_logo.rgb|binary src/demos/.gitignore |4 src/demos/CMakeLists.txt | 89 src/demos/Makefile.am|9 src/demos/Makefile.cygnus|1 src/demos/Makefile.win | 131 src/demos/SConscript | 81 src/demos/arbfplight.c |2 src/demos/arbfslight.c | 403 - src/demos/arbocclude.c |2 src/demos/arbocclude2.c | 177 src/demos/bounce.c |2 src/demos/clearspd.c |2 src/demos/copypix.c |4 src/demos/cubemap.c |4 src/demos/cuberender.c | 586 ++ src/demos/dinoshade.c| 18 src/demos/dissolve.c |6 src/demos/drawpix.c |4 src/demos/engine.c |4 src/demos/fbo_firecube.c | 10 src/demos/fbotexture.c |2 src/demos/fire.c | 11 src/demos/fogcoord.c |2 src/demos/fplight.c |2 src/demos/fslight.c |8 src/demos/gamma.c|2 src/demos/gearbox.c |2 src/demos/gears.c|2 src/demos/geartrain.c| 179 src/demos/geartrain.dat | 119 src/demos/glinfo.c | 15 src/demos/gloss.c|6 src/demos/gltestperf.c |2 src/demos/ipers.c|9 src/demos/isosurf.c | 40 src/demos/isosurf.dat| 7179 --- src/demos/lodbias.c |6 src/demos/morph3d.c |2 src/demos/multiarb.c |6 src/demos/normal.c | 596 ++ src/demos/paltex.c |2 src/demos/particles.h|2 src/demos/pixeltest.c| 467 ++ src/demos/pointblast.c |2 src/demos/projtex.c | 10 src/demos/rain.cxx |5 src/demos/ray.c |3 src/demos/readpix.c |4 src/demos/reflect.c |4 src/demos/renormal.c |3 src/demos/shadowtex.c|2 src/demos/singlebuffer.c |2 src/demos/spectex.c |2 src/demos/spriteblast.c | 126 src/demos/stex3d.c |9 src/demos/teapot.c |7 src/demos/terrain.c |5 src/demos/terrain.dat|1 src/demos/tessdemo.c | 46 src/demos/texcyl.c |4 src/demos/texenv.c |3 src/demos/textures.c | 13 src/demos/trispd.c |2 src/demos/tunnel.c |7 src/demos/tunnel2.c |7 src/demos/vao_demo.c |2 src/demos/winpos.c |4 src/egl/CMakeLists.txt | 20 src/egl/Makefile.am
Bug#706022: mesa-utils: New upstream version 8.1.0
Control: tags -1 pending On 2013-04-23 17:07 +0200, Timo Jyrinki wrote: > There is a new upstream version available 8.1.0 [1], the first new > version in 2.5 years. It has among else an updated glxinfo that > correctly shows the newer supported OpenGL versions unlike the > current one. I have pushed the new upstream version to our git repository[1], should be uploaded some time after the Wheezy release. Cheers, Sven 1. http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/mesa-demos.git -- 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/87r4hzoooj@turtle.gmx.de
Processed: Re: Bug#706022: mesa-utils: New upstream version 8.1.0
Processing control commands: > tags -1 pending Bug #706022 [mesa-utils] mesa-utils: New upstream version 8.1.0 Added tag(s) pending. -- 706022: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706022 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.b706022.136682242225275.transcr...@bugs.debian.org
Bug#705927: xserver-xorg-core: xserver update and the AMD Catalyst 13.1 Proprietary Linux x86 Display Driver
On Wed, Apr 24, 2013 at 13:55:19 +0200, Steffen Bode wrote: > oh, Julien, a personal level is not good here and not helpfull … so we have a > the same problems like years: the user must figure out this discrepance... My > "insists" is a idea, a debatte, a proposal, and i have wrote clear arguments > for this: in the end this update bug is not userfriendly. > Nothing personal in what I wrote. And yes, if you have issues with closed source software you get to keep the pieces, or contact that software's vendor for support. Nothing new there. [also please keep the bug address cc:ed if you want to continue this conversation] Cheers, Julien -- 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/20130424135658.gs12...@radis.cristau.org
Bug#705927: xserver-xorg-core: xserver update and the AMD Catalyst 13.1 Proprietary Linux x86 Display Driver
On Wed, Apr 24, 2013 at 12:23:33 +0200, Steffen Bode wrote: > > Julien, i need no support for the catalyst driver, i mean as a software > developer: test (integration test) the debian updates first and then release. > > The catalyst driver is a important driver and in a worldwide usage. This fact > cant you ignore, otherwise why ? So this installed driver should "only" be > tested in combination with with updates - routine and maybe: why cant debian > developer communicate with amd about APIs or better integrations? > Because I believe I have better things to do with my time, and since it's my free time I get to decide what to do with it. If you want to volunteer to test our X server with fglrx, more power to you, but you can't insist on us doing that work, that's not how debian or free software works. Cheers, Julien signature.asc Description: Digital signature
Bug#706066: xserver-xorg-video-openchrome: new upstream version available
Package: xserver-xorg-video-openchrome Version: 1:0.2.906-2 Severity: wishlist The openchrome 0.2.906 driver is utterly useless on an OLPC XO-1.5. There are various rendering bugs, and will frequently hang the system. It's not worth filing an RC bug about, as I'm not sure older versions of the driver ever worked properly on this platform. xf86-video-openchrome-0.3.2 is available upstream. I upgraded the debian package to this version (dropping debian/patches/10-Deal-with-xserver-1.12.diff and rediffing debian/patches/kbsd-types-madness.diff), and it is behaving wonderfully. No more rendering bugs or machine hangs. It would be great to have 0.3.2 in Debian (experimental, unstable, whatever). Thanks! -- 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/20130424030721.1b953...@dev.queued.net
