Re: X.org plans for the squeeze cycle
Bastian Blank wrote: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. And in 2.6.31-rc6, KMS is not stable enought to be used for my day-to-day work. It even leads to data corruption. See #545517 Since I remove KMS (ie since my bug report), I had no problem at all (with many many suspend-resume cycles) KMS should improve a lot before we use it by default. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Thu, Sep 10, 2009 at 09:07:34AM +0200, Vincent Danjean wrote: Bastian Blank wrote: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. And in 2.6.31-rc6, KMS is not stable enought to be used for my day-to-day work. It even leads to data corruption. See #545517 Since I remove KMS (ie since my bug report), I had no problem at all (with many many suspend-resume cycles) Results vary, then; with my Intel 945, KMS in 2.6.31-rc8 is much more stable than EXA has been in the recent past. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: X.org plans for the squeeze cycle
On Thu, Sep 10, 2009 at 09:07:34 +0200, Vincent Danjean wrote: And in 2.6.31-rc6, KMS is not stable enought to be used for my day-to-day work. It even leads to data corruption. See #545517 Since I remove KMS (ie since my bug report), I had no problem at all (with many many suspend-resume cycles) Please file that as a bug on https://bugs.freedesktop.org/enter_bug.cgi?product=DRIcomponent=DRM%2FIntel There's no way it's going to get fixed otherwise. I haven't used suspend to disk in years, eg... See also http://intellinuxgraphics.org/how_to_report_bug.html Thanks, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
Julien Cristau wrote: On Thu, Sep 10, 2009 at 09:07:34 +0200, Vincent Danjean wrote: And in 2.6.31-rc6, KMS is not stable enought to be used for my day-to-day work. It even leads to data corruption. See #545517 Since I remove KMS (ie since my bug report), I had no problem at all (with many many suspend-resume cycles) Please file that as a bug on https://bugs.freedesktop.org/enter_bug.cgi?product=DRIcomponent=DRM%2FIntel There's no way it's going to get fixed otherwise. I haven't used suspend to disk in years, eg... See also http://intellinuxgraphics.org/how_to_report_bug.html Done as https://bugs.freedesktop.org/show_bug.cgi?id=23836 However, as explained in the bug report, I do not use KMS anymore and I will not retry it for now because I have not enough time if I need to recover again from data corruption. So my bug report is not as complete as it should (no Xorg.0.log for example) Regards, Vincent Thanks, Julien -- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann Email: vincent.danj...@imag.fr 38330 Montbonnot Saint Martin -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). This means the intel X driver won't work with lenny's kernel, so we might have to figure out an upgrade path somehow (which might be to make the driver fall back to the vesa driver if it doesn't find a modesetting-capable kernel). This might also mean that we'll want to turn kms on by default in the debian kernel, or have xserver-xorg-video-intel install a file in /etc/modprobe.d/ to set i915.modeset. cc:ing debian-kernel as a heads-up. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. This might also mean that we'll want to turn kms on by default in the debian kernel, Is KMS backward compatible with older versions of the intel driver? Does not looks like: | bool Enable modesetting on intel by default | depends on DRM_I915 | help | Choose this option if you want kernel modesetting enabled by default, | and you have a new enough userspace to support this. Running old | userspaces with this enabled will cause pain. Note that this causes | the driver to bind to PCI devices, which precludes loading things | like intelfb. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, Errand of Mercy, stardate 3198.9 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Wed, Sep 9, 2009 at 12:36:58 +0200, Bastian Blank wrote: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. This might also mean that we'll want to turn kms on by default in the debian kernel, Is KMS backward compatible with older versions of the intel driver? No :/ I guess we could also decide to freeze on the intel Q3 bits, but then we're likely to be on our own for new hardware support and stuff like that. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
* Bastian Blank (wa...@debian.org) [090909 12:37]: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. If not at X side, is it a possibility to either (a) add the new memory manager to lenny (I assume not), or (b) tell the users you need to upgrade your kernel first (and make the new X pre-depending somehow on the kernel). Of course, this sounds to me like people need to do updates in console mode, which ... isn't the best either. Cheers, Andi -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Wed, 2009-09-09 at 13:31 +0200, Julien Cristau wrote: On Wed, Sep 9, 2009 at 12:36:58 +0200, Bastian Blank wrote: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. This might also mean that we'll want to turn kms on by default in the debian kernel, Is KMS backward compatible with older versions of the intel driver? No :/ Running the kernel with intel.modeset=0 doesn't help ? Xav -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Wed, Sep 9, 2009 at 14:42:52 +0200, Xavier Bestel wrote: On Wed, 2009-09-09 at 13:31 +0200, Julien Cristau wrote: On Wed, Sep 9, 2009 at 12:36:58 +0200, Bastian Blank wrote: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: This might also mean that we'll want to turn kms on by default in the debian kernel, Is KMS backward compatible with older versions of the intel driver? No :/ Running the kernel with intel.modeset=0 doesn't help ? Yeah that works (with s/intel/i915/), but it's not quite user friendly to crash unless that's manually added to the kernel command line. So it's probably better to default kms off in the kernel, and have the new userspace turn it on via /etc/modprobe.d/. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
Le mercredi 09 septembre 2009 à 14:04 +0200, Andreas Barth a écrit : If not at X side, is it a possibility to either (a) add the new memory manager to lenny (I assume not), or (b) tell the users you need to upgrade your kernel first (and make the new X pre-depending somehow on the kernel). This sounds like the udev case for the sarge → etch upgrade. This was solved with a big hack in the preinst, that surprisingly turned out to work. If there is no other way, this is an option. Of course, this sounds to me like people need to do updates in console mode, which ... isn't the best either. Not necessarily. The only thing is that people must not restart X before rebooting. This will, of course, cause trouble with (at least) GDM, which will restart itself and re-launch X when you log out after an upgrade. Having the driver fall back to vesa when no kernel support is found, as Julien proposed, sounds like a more reliable solution. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: X.org plans for the squeeze cycle
[ Remove -release, this is technical stuff. ] On Wed, Sep 09, 2009 at 01:31:36PM +0200, Julien Cristau wrote: On Wed, Sep 9, 2009 at 12:36:58 +0200, Bastian Blank wrote: Is KMS backward compatible with older versions of the intel driver? No :/ What happens when a old driver runs on a KMS enabled system? I don't think it have an automatic fallback to the fb device. Bastian -- Oblivion together does not frighten me, beloved. -- Thalassa (in Anne Mulhall's body), Return to Tomorrow, stardate 4770.3. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Wed, 2009-09-09 at 18:05 +0200, Bastian Blank wrote: [ Remove -release, this is technical stuff. ] On Wed, Sep 09, 2009 at 01:31:36PM +0200, Julien Cristau wrote: On Wed, Sep 9, 2009 at 12:36:58 +0200, Bastian Blank wrote: Is KMS backward compatible with older versions of the intel driver? No :/ What happens when a old driver runs on a KMS enabled system? I don't think it have an automatic fallback to the fb device. Both try to access the registers for modesetting. Everything can happen afterwards (nothing, crash, lock, corruption ..) Xav -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
Julien Cristau wrote: On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? Lately the big problems were related to the stability of the intel driver, which went through several big changes (full modesetting in the driver instead of using the bios, then switch of acceleration architecture to EXA, then a kernel memory manager, then kernel mode setting, and I'm probably forgetting some). Hopefully most of that is over, and we can migrate it to testing soon along with the rest of the X stack. What's the status about this? When do you think the X stack will be ready to migrate? Cheers Luk -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Sun, Sep 6, 2009 at 16:06:13 +0200, Luk Claes wrote: What's the status about this? When do you think the X stack will be ready to migrate? Currently the only blocker as far as I know is the fact that xserver-xorg-video-intel locks up shortly after X startup on 865G chips. I'm confident this will be fixed upstream (Carl Worth was able to reproduce it), but don't know exactly when. If you want to force things to testing anyway, that's fine too, we'll migrate the fix later. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
David Nusinow wrote: Julien Cristau wrote: [other xsf members, feel free to chime in if I'm forgetting something or saying something stupid :)] On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * Which major upstream releases of X.org are expected in the next two years? Which of those are material for Debian stable, which might be a bit flaky? X.org release management is notoriously pretty bad. Releases often slip by months, and bugs in .0 server releases aren't unheard of. See also http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp9.html Anyway, there's no schedule for 1.7 to my knowledge, let alone for the subsequent releases. I'd guess server 1.7 (and X.Org 7.5) will come before the end of the year, though, so that seems like a good candidate for a squeeze release in 2010. My main worry for 1.7 is that it probably won't give us a lot of time to shake bugs out of XKB2. We're not historically very good at dealing with the guts of the input system anyway, and that XKB2 won't provide any immediate user-visible changes that seem to make it a must have (if I'm wrong here, please correct me!) On the other hand, with the 1.6 servers we finally have a stable input system again, so my sense is that we should probably be conservative and go with the 1.6 branches for squeeze given our short time frame. Upstream just announced that they won't be including XKB2 in this release after all, since it needs some more time to cook. Given that, I think we should shoot for 1.7 and any further useful patches for squeeze. - David Nusinow -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
[other xsf members, feel free to chime in if I'm forgetting something or saying something stupid :)] On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * Which major upstream releases of X.org are expected in the next two years? Which of those are material for Debian stable, which might be a bit flaky? X.org release management is notoriously pretty bad. Releases often slip by months, and bugs in .0 server releases aren't unheard of. See also http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp9.html Anyway, there's no schedule for 1.7 to my knowledge, let alone for the subsequent releases. I'd guess server 1.7 (and X.Org 7.5) will come before the end of the year, though, so that seems like a good candidate for a squeeze release in 2010. FWIW, the pattern so far looks like: Apr 19 2007 xorg-server-1.3.0.0.tar.gz Sep 6 2007 xorg-server-1.4.tar.gz Jun 10 2008 xorg-server-1.4.1.tar.gz Jun 11 2008 xorg-server-1.4.2.tar.gz Sep 3 2008 xorg-server-1.5.0.tar.gz Sep 23 2008 xorg-server-1.5.1.tar.gz Oct 10 2008 xorg-server-1.5.2.tar.gz Nov 5 2008 xorg-server-1.5.3.tar.gz Feb 25 12:19 xorg-server-1.6.0.tar.gz Apr 14 13:09 xorg-server-1.6.1.tar.gz Jul 7 16:39 xorg-server-1.6.2.tar.gz Jul 31 23:42 xorg-server-1.6.3.tar.gz * How much time do you usually need from a new upstream release of X.org to a stable Debian package in unstable? I'd say 6 months to a year from a .0 server to something we can ship in stable. Depending if RedHat/Fedora are shipping it too and thus fixing most bugs for us. * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? Lately the big problems were related to the stability of the intel driver, which went through several big changes (full modesetting in the driver instead of using the bios, then switch of acceleration architecture to EXA, then a kernel memory manager, then kernel mode setting, and I'm probably forgetting some). Hopefully most of that is over, and we can migrate it to testing soon along with the rest of the X stack. Kernel mode setting for the radeon driver is being worked on, will be in staging in the 2.6.31 kernel, so hopefully we can ship that stack with squeeze. The nouveau driver is also lining up for inclusion in the kernel (maybe in staging in 2.6.32?) so it'd be really great to be able to ship that in the release, too. Some of that depends on having enough people available to package new releases, triage/forward bugs, and test the new stuff. I won't be able to do much of that myself in the foreseeable future. One thing that might cause some minor disruption in sid is the moving around of headers between libxext and x11proto-xext (http://lists.freedesktop.org/pipermail/xorg-announce/2009-August/000953.html). Fedora already went through that, though, and the change should be mostly invisible to clients. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Sun, 2009-08-23 at 13:23 +0200, Julien Cristau wrote: On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * Which major upstream releases of X.org are expected in the next two years? Which of those are material for Debian stable, which might be a bit flaky? X.org release management is notoriously pretty bad. Releases often slip by months, and bugs in .0 server releases aren't unheard of. See also http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp9.html There's some truth to this, but anyone reading it without context should keep in mind who wrote it. From my POV the main problem is lack of manpower upstream, and the people we have tend to be more interested in working on functionality or fixing bugs than doing release management stuff. Anyway, there's no schedule for 1.7 to my knowledge, [...] Actually, there is one: http://lists.x.org/archives/xorg-devel/2009-May/000993.html But we haven't even frozen features or branched for xserver 1.7 yet, so we're way behind. AFAIK the main outstanding blocker is XKB2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
Julien Cristau wrote: [other xsf members, feel free to chime in if I'm forgetting something or saying something stupid :)] On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * Which major upstream releases of X.org are expected in the next two years? Which of those are material for Debian stable, which might be a bit flaky? X.org release management is notoriously pretty bad. Releases often slip by months, and bugs in .0 server releases aren't unheard of. See also http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp9.html Anyway, there's no schedule for 1.7 to my knowledge, let alone for the subsequent releases. I'd guess server 1.7 (and X.Org 7.5) will come before the end of the year, though, so that seems like a good candidate for a squeeze release in 2010. My main worry for 1.7 is that it probably won't give us a lot of time to shake bugs out of XKB2. We're not historically very good at dealing with the guts of the input system anyway, and that XKB2 won't provide any immediate user-visible changes that seem to make it a must have (if I'm wrong here, please correct me!) On the other hand, with the 1.6 servers we finally have a stable input system again, so my sense is that we should probably be conservative and go with the 1.6 branches for squeeze given our short time frame. FWIW, the pattern so far looks like: Apr 19 2007 xorg-server-1.3.0.0.tar.gz Sep 6 2007 xorg-server-1.4.tar.gz Jun 10 2008 xorg-server-1.4.1.tar.gz Jun 11 2008 xorg-server-1.4.2.tar.gz Sep 3 2008 xorg-server-1.5.0.tar.gz Sep 23 2008 xorg-server-1.5.1.tar.gz Oct 10 2008 xorg-server-1.5.2.tar.gz Nov 5 2008 xorg-server-1.5.3.tar.gz Feb 25 12:19 xorg-server-1.6.0.tar.gz Apr 14 13:09 xorg-server-1.6.1.tar.gz Jul 7 16:39 xorg-server-1.6.2.tar.gz Jul 31 23:42 xorg-server-1.6.3.tar.gz * How much time do you usually need from a new upstream release of X.org to a stable Debian package in unstable? I'd say 6 months to a year from a .0 server to something we can ship in stable. Depending if RedHat/Fedora are shipping it too and thus fixing most bugs for us. * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? Lately the big problems were related to the stability of the intel driver, which went through several big changes (full modesetting in the driver instead of using the bios, then switch of acceleration architecture to EXA, then a kernel memory manager, then kernel mode setting, and I'm probably forgetting some). Hopefully most of that is over, and we can migrate it to testing soon along with the rest of the X stack. Kernel mode setting for the radeon driver is being worked on, will be in staging in the 2.6.31 kernel, so hopefully we can ship that stack with squeeze. The nouveau driver is also lining up for inclusion in the kernel (maybe in staging in 2.6.32?) so it'd be really great to be able to ship that in the release, too. Some of that depends on having enough people available to package new releases, triage/forward bugs, and test the new stuff. I won't be able to do much of that myself in the foreseeable future. This is the big one to me. I don't interface at all with the debian-kernel folk, and have no idea what their plans are. Given the user demand that I've seen, I'd much rather throw whatever effort we can in to providing optional KMS bits for radeon, as well as high quality intel, than worry about XKB2 and Xserver 1.7. I don't know that we'll have the manpower to do that either, but this seems to be where we'll get the most payoff for our energy. One thing that might cause some minor disruption in sid is the moving around of headers between libxext and x11proto-xext (http://lists.freedesktop.org/pipermail/xorg-announce/2009-August/000953.html). Fedora already went through that, though, and the change should be mostly invisible to clients. I don't really know what to think about this. - David Nusinow -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the lenny cycle
On Mon, Feb 11, 2008 at 03:06:57PM +1100, Niv Sardi wrote: I forwarded that information internaly to my manager about a week ago (after a discution with jcristeau), I believe that the message is: * If it affects only Debian SGI (as a corporation) will not care and treat us as a bunch of nitpickers hippies. (julien sent me a link I can't find now where fedora seemed to state that they had the same concerns) You probably won't find it. I had a private discussion with a RedHat employee who mentioned that their lawyers were interested in resolving issues with licenses like FreeB for practical reasons. I don't know exactly what became of it. Also of note is that Brett Smith from the FSF is working on this problem privately right now, and while he isn't able to report on any of the discussions publicly he does claim to be making some headway. * It is possible that SGI doesn't own the code anymore (and that Khronos does) On Feb 11, 2008 2:20 PM, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: On Fri, Apr 13, 2007 at 12:46:30PM +1000, Drew Parsons wrote: On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to Then we should contact SGI all together... see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? Please let's not make these kinds of calls,... Indeed. I don't see any benefit to doing something rash in this case. Outright removal of the code won't make it Free any faster, nor are there people lining up to reimplement it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 12:46:30PM +1000, Drew Parsons wrote: On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? I'm currently working for SGI (together with Russell Coker, in the same project). Russell doesn't work for SGI any more. But Niv is. I've cc-ed Jim and Niv. Drew [1] bugs #368560, #368559, #211765 (I think this one is redundant, the original bug mitosed into the others) and #368564 Aníbal Monsalve Salazar That sounds promising! It would be an Honourable Task if you and Russell could find who's responsible for the GL licences and get the inconsistency wiped. There are fears SGI is no longer in control of the code [1]. On the X.org side it was Jim Gettys who was going to try to work on the licence problems [2]. No doubt worth liasing with him if you're able to proceed with this task. Jim, what could Niv and I do from inside SGI? Drew [1] http://lists.freedesktop.org/archives/xorg/2006-December/020397.html http://lists.freedesktop.org/archives/xorg/2006-December/020422.html [2] http://lists.freedesktop.org/archives/xorg/2006-October/018648.html signature.asc Description: Digital signature
Re: X.org plans for the lenny cycle
I forwarded that information internaly to my manager about a week ago (after a discution with jcristeau), I believe that the message is: * If it affects only Debian SGI (as a corporation) will not care and treat us as a bunch of nitpickers hippies. (julien sent me a link I can't find now where fedora seemed to state that they had the same concerns) * It is possible that SGI doesn't own the code anymore (and that Khronos does) On Feb 11, 2008 2:20 PM, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: On Fri, Apr 13, 2007 at 12:46:30PM +1000, Drew Parsons wrote: On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to Then we should contact SGI all together... see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? Please let's not make these kinds of calls,... -- Niv Sardi
Processed: Re: X.org segfault with kxkb
Processing commands for [EMAIL PROTECTED]: severity 461783 grave Bug#461783: X.org segfaults all the time since last update Bug#462243: x11-xkb-utils: calling setxkbmap crashes X server Bug#463194: xserver-xorg-core: crashes setting keyboard layout Severity set to `grave' from `important' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: 1) active probing of video cards to allow a more dynamic setting and resetting of video modes used. This work is mostly complete already (available in experimental xserver-xorg-video-intel, soon to appear in unstable). To expand on Drew's excellent summary further, there is support in a development branch for the -ati driver for this as well, but it's not ready yet. BTW, is there any chance that the -ati driver is going to include support for newer cards, the Radeon X series? It's sort of pointless for any newer machine, it won't even start X... I recently actually got sufficiently pissed off at both the ati and fglrx drivers that I went out and bought an nv/nvidia card, both of whose drivers actually work properly. (Please Cc: responses, I'm not subscribed to -x.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Sun, Apr 15, 2007 at 12:24:24PM +0200, Josip Rodin wrote: BTW, is there any chance that the -ati driver is going to include support for newer cards, the Radeon X series? It's sort of pointless for any newer machine, it won't even start X... The problem is that the newer cards have dramatically changed how they do 2D, and as far as I know, no one has started reverse engineering them to make them work. So you're basically stuck with fglrx in that situation. It's a sucky place to be in, but I don't ha ve a better answer for you. I recently actually got sufficiently pissed off at both the ati and fglrx drivers that I went out and bought an nv/nvidia card, both of whose drivers actually work properly. Yeah, not an uncommon thing to hear unfortunately. With Intel looking to put out stand-alone video cards soon, and with nouveau hopefully picking up its stride, things should improve somewhat for the ati alternatives. It's sad to see what's become of ati though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
El Sábado, 14 de Abril de 2007, Noah Meyerhans escribió: On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: These are a real thorn in our sides. Another issue is the nvidia code obfuscation bug, which we can fix when we get nouveau in to the archive. I'd love to have a dedicated maintainer for nouveau[0], but right now it's looking like I need to buy myself an nvidia card. Either way, that etch-ignore bug will be fixable for lenny thanks to the upstream work. - David Nusinow [0] Anyone who's interested, *please* write us at debian-x. We'd love to help you get going on this. I may be able to help here. At work, we've got ~300 Debian workstations, almost all of which use either ATI or nvidia graphics hardware, so I've got extensive hardware resources at my disposal. I'm not currently up to speed the state of neuveau development, so I can't jump right in and get to work, but I should be able to get involved reasonably quickly. Have there been any attempts thus far at packaging neuveau? Where are they? I was going to reply to David's mail as well, but you were faster. :-) I was wondering some days ago if that could be possible. The thing that I wanted to do now, given there is no official release from nouveau was to create snapshots from Mesa/freedesktop/drm-kernel-module until stability arrive to the branch. I have some drafts in my home computer trying to take shape in packages. Best regards, Ender. -- El conceto es el conceto. -- Pazos (Airbag). -- Área de Internet - Network services Mundinteractivos - El Mundo C/Pradillo, 42 - Madrid (Spain) -- El conceto es el conceto. -- Pazos (Airbag). -- Desarrollador de Debian Debian developer pgp6zWZs1KWl7.pgp Description: PGP signature
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: Marc 'HE' Brockschmidt enquired: The release team is currently working on a schedule for the lenny release cycle. For that, we want to gather some data from the bigger software packaging teams in Debian first. We would like to know which major upstream versions of X.org are expected to be released in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. Our current, very rough plans would mean a release in 18 months, which would be in October 2008. We expect to shuffle this a bit around to fit everyone's needs, so please tell us if this date works for you. As I see it, there are three major developments going on in X.org at the moment. 1) active probing of video cards to allow a more dynamic setting and resetting of video modes used. This work is mostly complete already (available in experimental xserver-xorg-video-intel, soon to appear in unstable). To expand on Drew's excellent summary further, there is support in a development branch for the -ati driver for this as well, but it's not ready yet. I expect it to be ready in time for lenny. Nouveau, the replacement for -nv, which is in development will also have support for this, which covers all the major chipsets in use today. I wouldn't be surprised if we see several other drivers that are being actively maintained use this. As it is, this goal is flexible, and we'll ship the best support that's available when lenny is ready. For any chips that aren't ready, they can use the current architecture we already have in place. 2) Support for input-hotplug. As with the dynamic modesetting in 1), this allows for dynamic plugging in of X-related devices. Currently being developed on the master X.org branch, should be ready in X11R7.3 by June or July. It's not clear what's goin on with this. The implementation requires a daemon which talks to HAL via dbus and lets the X server know when a device changes. Currently, there's a prototype implementation in C written by Daniel Stone, which isn't really meant for production use. There's also an implementation in Python written by a Gentoo developer which is probably also not ready. Once we get 7.2 in to unstable, we'll have to make a more serious run at this. Even if it's not ready to turn on by default though, I plan to follow upstream and set the default mouse to /dev/input/mice, which will solve most problems and simplify things for our users. So either way, the release team shouldn't have to worry about things from this end. Expect to see more from us on it in the coming few months though. 3) More generally, making /etc/X11/xorg.conf completely redundant. I believe this will not be achieved under 2), but is a longer term goal. I'm actively working on this with upstream, albeit slowly. The infrastructure is in place to run without a xorg.conf completely, but it doesn't work properly when you have to change something. I'm in the process of making this work so that we can ship without a xorg.conf, or with a minimal one that only changes what the user needs. The exact shape of this by the end of the lenny cycle isn't really possible to predict (and it depends on the improved resolution stuff in item 1) but we can at least whittle away at this as the lenny cycle goes on so that we don't cause any disruptions to the release while making the improvements. As you can see, X.org's broad aims at the moment are to improve usability by enabling the Xserver to be configured automatically without user intervention. X.org is striving to keep to a relatively strict six month release cycle, I would imagine six months is sufficient time for us to stabilise X for the release of Lenny. So with a goal of Oct 2008 we would expect to include X11R7.4, which should have been released around Feb or Mar 2008. This would include the new input-hotplug features. One thing the XSF needs to do is actively build the packaging infrastructure for the input-hotplugging. I'm not sure exactly how long this will take, but I don't imagine that it will be too difficult. A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? These are a real thorn in our sides. Another issue is the nvidia code obfuscation bug, which we can fix when we get nouveau in
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: These are a real thorn in our sides. Another issue is the nvidia code obfuscation bug, which we can fix when we get nouveau in to the archive. I'd love to have a dedicated maintainer for nouveau[0], but right now it's looking like I need to buy myself an nvidia card. Either way, that etch-ignore bug will be fixable for lenny thanks to the upstream work. - David Nusinow [0] Anyone who's interested, *please* write us at debian-x. We'd love to help you get going on this. I may be able to help here. At work, we've got ~300 Debian workstations, almost all of which use either ATI or nvidia graphics hardware, so I've got extensive hardware resources at my disposal. I'm not currently up to speed the state of neuveau development, so I can't jump right in and get to work, but I should be able to get involved reasonably quickly. Have there been any attempts thus far at packaging neuveau? Where are they? noah signature.asc Description: Digital signature
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 11:09:41AM -0400, Noah Meyerhans wrote: On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: These are a real thorn in our sides. Another issue is the nvidia code obfuscation bug, which we can fix when we get nouveau in to the archive. I'd love to have a dedicated maintainer for nouveau[0], but right now it's looking like I need to buy myself an nvidia card. Either way, that etch-ignore bug will be fixable for lenny thanks to the upstream work. - David Nusinow [0] Anyone who's interested, *please* write us at debian-x. We'd love to help you get going on this. I may be able to help here. At work, we've got ~300 Debian workstations, almost all of which use either ATI or nvidia graphics hardware, so I've got extensive hardware resources at my disposal. That would be awesome! I'm not currently up to speed the state of neuveau development, so I can't jump right in and get to work, but I should be able to get involved reasonably quickly. Ok, I haven't been tracking things as closely either, so I basically hear about milestones when they happen. Have there been any attempts thus far at packaging neuveau? Where are they? Not that I'm aware of, but it shouldn't be hard to adapt our current driver packaging to nouveau. It's relatively simple packaging, although we do have a lot of extra stuff bolted on that will hopefully be mostly going away during this release cycle. As for nouveau itself, it may need a more up to date libdrm and mesa than we currently have, although once we get 7.2 in to unstable then experimental can be a playground for that. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
Marc 'HE' Brockschmidt enquired: The release team is currently working on a schedule for the lenny release cycle. For that, we want to gather some data from the bigger software packaging teams in Debian first. We would like to know which major upstream versions of X.org are expected to be released in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. Our current, very rough plans would mean a release in 18 months, which would be in October 2008. We expect to shuffle this a bit around to fit everyone's needs, so please tell us if this date works for you. As I see it, there are three major developments going on in X.org at the moment. 1) active probing of video cards to allow a more dynamic setting and resetting of video modes used. This work is mostly complete already (available in experimental xserver-xorg-video-intel, soon to appear in unstable). 2) Support for input-hotplug. As with the dynamic modesetting in 1), this allows for dynamic plugging in of X-related devices. Currently being developed on the master X.org branch, should be ready in X11R7.3 by June or July. 3) More generally, making /etc/X11/xorg.conf completely redundant. I believe this will not be achieved under 2), but is a longer term goal. As you can see, X.org's broad aims at the moment are to improve usability by enabling the Xserver to be configured automatically without user intervention. X.org is striving to keep to a relatively strict six month release cycle, I would imagine six months is sufficient time for us to stabilise X for the release of Lenny. So with a goal of Oct 2008 we would expect to include X11R7.4, which should have been released around Feb or Mar 2008. This would include the new input-hotplug features. A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? Drew [1] bugs #368560, #368559, #211765 (I think this one is redundant, the original bug mitosed into the others) and #368564 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: Marc 'HE' Brockschmidt enquired: The release team is currently working on a schedule for the lenny release cycle. For that, we want to gather some data from the bigger software packaging teams in Debian first. We would like to know which major upstream versions of X.org are expected to be released in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. Our current, very rough plans would mean a release in 18 months, which would be in October 2008. We expect to shuffle this a bit around to fit everyone's needs, so please tell us if this date works for you. As I see it, there are three major developments going on in X.org at the moment. 1) active probing of video cards to allow a more dynamic setting and resetting of video modes used. This work is mostly complete already (available in experimental xserver-xorg-video-intel, soon to appear in unstable). 2) Support for input-hotplug. As with the dynamic modesetting in 1), this allows for dynamic plugging in of X-related devices. Currently being developed on the master X.org branch, should be ready in X11R7.3 by June or July. 3) More generally, making /etc/X11/xorg.conf completely redundant. I believe this will not be achieved under 2), but is a longer term goal. As you can see, X.org's broad aims at the moment are to improve usability by enabling the Xserver to be configured automatically without user intervention. X.org is striving to keep to a relatively strict six month release cycle, I would imagine six months is sufficient time for us to stabilise X for the release of Lenny. So with a goal of Oct 2008 we would expect to include X11R7.4, which should have been released around Feb or Mar 2008. This would include the new input-hotplug features. A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? I'm currently working for SGI (together with Russell Coker, in the same project). Drew [1] bugs #368560, #368559, #211765 (I think this one is redundant, the original bug mitosed into the others) and #368564 Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: X.org plans for the lenny cycle
On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? I'm currently working for SGI (together with Russell Coker, in the same project). Drew [1] bugs #368560, #368559, #211765 (I think this one is redundant, the original bug mitosed into the others) and #368564 Aníbal Monsalve Salazar That sounds promising! It would be an Honourable Task if you and Russell could find who's responsible for the GL licences and get the inconsistency wiped. There are fears SGI is no longer in control of the code [1]. On the X.org side it was Jim Gettys who was going to try to work on the licence problems [2]. No doubt worth liasing with him if you're able to proceed with this task. Drew [1] http://lists.freedesktop.org/archives/xorg/2006-December/020397.html http://lists.freedesktop.org/archives/xorg/2006-December/020422.html [2] http://lists.freedesktop.org/archives/xorg/2006-October/018648.html
Re: X.org xorg-docs documentation.: Changes to 'master'
On Wed, Nov 22, 2006 at 08:41:41AM -0200, Otavio Salvador wrote: David Nusinow [EMAIL PROTECTED] writes: commit b25f4dfbbd86e21146d1f9121c29d48e0c3a2678 Author: David Nusinow [EMAIL PROTECTED] Date: Tue Nov 21 21:52:28 2006 -0500 Add quilt as a build-depend I've been using git for sometime to maintain our specific patches of debian packages, where I work, and I found it very useful if used together with stgit. Looks like it could be a nice alternative to quilt once we move to git for X.org packages. What you all think about it? We've talked about it in the past, and while I haven't actually used stgit myself, I'm open to it. Most people seemed to like the quilt system enough to keep it, but I'm definitely willing to give stgit a try. Does it provide significant advantages over quilt? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org xorg-docs documentation.: Changes to 'master'
David Nusinow [EMAIL PROTECTED] writes: commit b25f4dfbbd86e21146d1f9121c29d48e0c3a2678 Author: David Nusinow [EMAIL PROTECTED] Date: Tue Nov 21 21:52:28 2006 -0500 Add quilt as a build-depend I've been using git for sometime to maintain our specific patches of debian packages, where I work, and I found it very useful if used together with stgit. Looks like it could be a nice alternative to quilt once we move to git for X.org packages. What you all think about it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org 7.1 to unstable
Are there any approximate dates as to when X.Org 7.1 would hit unstable ? It's already underway. The transition will likely be complete within the fortnight. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org 6.9 Needs Your Build Logs!
On Mon, Oct 24, 2005 at 12:53:41 +0200, Julien Cristau wrote: Hi, I rebuilt the 6.9RC0 tree with the attached patch, which gave me the following MANIFEST diff: Hi, please find attached the MANIFEST.alpha diff for xorg-x11 6.8.99.901.dfsg.1-1 (still with the patch I sent with the previous mail). Cheers, Julien Cristau --- debian/MANIFEST.alpha 2005-10-25 00:16:50.0 + +++ debian/MANIFEST.alpha.new 2005-10-25 00:16:50.0 + @@ -18,2 +17,0 @@ -etc/X11/app-defaults/KOI8RXTerm -etc/X11/app-defaults/UXTerm @@ -34,2 +31,0 @@ -etc/X11/app-defaults/XTerm -etc/X11/app-defaults/XTerm-color @@ -96 +91,0 @@ -etc/X11/xkb/compat/group_led @@ -100 +95,3 @@ -etc/X11/xkb/compat/leds +etc/X11/xkb/compat/ledcaps +etc/X11/xkb/compat/lednum +etc/X11/xkb/compat/ledscroll @@ -228,0 +226 @@ +etc/X11/xkb/symbols/capslock @@ -246,0 +245 @@ +etc/X11/xkb/symbols/eurosign @@ -247,0 +247 @@ +etc/X11/xkb/symbols/fo @@ -309 +309,4 @@ -etc/X11/xkb/symbols/pc/ar +etc/X11/xkb/symbols/pc/ara +etc/X11/xkb/symbols/pc/az +etc/X11/xkb/symbols/pc/ba +etc/X11/xkb/symbols/pc/bd @@ -311 +313,0 @@ -etc/X11/xkb/symbols/pc/ben @@ -313,0 +316 @@ +etc/X11/xkb/symbols/pc/bt @@ -318 +320,0 @@ -etc/X11/xkb/symbols/pc/cz_qwerty @@ -320 +321,0 @@ -etc/X11/xkb/symbols/pc/dev @@ -322,2 +322,0 @@ -etc/X11/xkb/symbols/pc/dvorak -etc/X11/xkb/symbols/pc/dz @@ -325,2 +323,0 @@ -etc/X11/xkb/symbols/pc/el -etc/X11/xkb/symbols/pc/en_US @@ -328,0 +326 @@ +etc/X11/xkb/symbols/pc/fo @@ -330 +327,0 @@ -etc/X11/xkb/symbols/pc/fr-latin9 @@ -332,4 +329,2 @@ -etc/X11/xkb/symbols/pc/ge_la -etc/X11/xkb/symbols/pc/ge_ru -etc/X11/xkb/symbols/pc/guj -etc/X11/xkb/symbols/pc/gur +etc/X11/xkb/symbols/pc/ge +etc/X11/xkb/symbols/pc/gr @@ -340 +335 @@ -etc/X11/xkb/symbols/pc/il_phonetic +etc/X11/xkb/symbols/pc/in @@ -344 +338,0 @@ -etc/X11/xkb/symbols/pc/iu @@ -346 +340 @@ -etc/X11/xkb/symbols/pc/kan +etc/X11/xkb/symbols/pc/kg @@ -347,0 +342 @@ +etc/X11/xkb/symbols/pc/latam @@ -349 +344 @@ -etc/X11/xkb/symbols/pc/lo +etc/X11/xkb/symbols/pc/lk @@ -352,2 +347,2 @@ -etc/X11/xkb/symbols/pc/mk -etc/X11/xkb/symbols/pc/ml +etc/X11/xkb/symbols/pc/mao +etc/X11/xkb/symbols/pc/mkd @@ -357 +351,0 @@ -etc/X11/xkb/symbols/pc/mt_us @@ -360,2 +353,0 @@ -etc/X11/xkb/symbols/pc/ogham -etc/X11/xkb/symbols/pc/ori @@ -362,0 +355 @@ +etc/X11/xkb/symbols/pc/pk @@ -364 +356,0 @@ -etc/X11/xkb/symbols/pc/pl2 @@ -368 +359,0 @@ -etc/X11/xkb/symbols/pc/sapmi @@ -370,3 +360,0 @@ -etc/X11/xkb/symbols/pc/se_FI -etc/X11/xkb/symbols/pc/se_NO -etc/X11/xkb/symbols/pc/se_SE @@ -375,5 +363,2 @@ -etc/X11/xkb/symbols/pc/sk_qwerty -etc/X11/xkb/symbols/pc/sr -etc/X11/xkb/symbols/pc/syr -etc/X11/xkb/symbols/pc/syr_phonetic -etc/X11/xkb/symbols/pc/tel +etc/X11/xkb/symbols/pc/srp +etc/X11/xkb/symbols/pc/sy @@ -381,2 +365,0 @@ -etc/X11/xkb/symbols/pc/th_pat -etc/X11/xkb/symbols/pc/th_tis @@ -384 +366,0 @@ -etc/X11/xkb/symbols/pc/tml @@ -388 +369,0 @@ -etc/X11/xkb/symbols/pc/us_intl @@ -391 +371,0 @@ -etc/X11/xkb/symbols/pc/yu @@ -455 +434,0 @@ -usr/X11R6/bin/Xorg-debug @@ -470,2 +448,0 @@ -usr/X11R6/bin/dpsexec -usr/X11R6/bin/dpsinfo @@ -485 +461,0 @@ -usr/X11R6/bin/koi8rxterm @@ -490 +465,0 @@ -usr/X11R6/bin/lxterm @@ -493 +467,0 @@ -usr/X11R6/bin/makepsres @@ -504,0 +479 @@ +usr/X11R6/bin/pclcomp @@ -506,2 +480,0 @@ -usr/X11R6/bin/pswrap -usr/X11R6/bin/resize @@ -520 +492,0 @@ -usr/X11R6/bin/texteroids @@ -523 +494,0 @@ -usr/X11R6/bin/uxterm @@ -528,0 +500 @@ +usr/X11R6/bin/xauth_switch_to_sun-des-1 @@ -536,0 +509 @@ +usr/X11R6/bin/xdbedizzy @@ -539,0 +513 @@ +usr/X11R6/bin/xdpr @@ -577,0 +552 @@ +usr/X11R6/bin/xpr @@ -591 +565,0 @@ -usr/X11R6/bin/xterm @@ -604,26 +577,0 @@ -usr/X11R6/include/DPS/ColorSB.h -usr/X11R6/include/DPS/ColorSBP.h -usr/X11R6/include/DPS/DPSScrollW.h -usr/X11R6/include/DPS/DPSScrollWP.h -usr/X11R6/include/DPS/FontCreatP.h -usr/X11R6/include/DPS/FontCreato.h -usr/X11R6/include/DPS/FontSB.h -usr/X11R6/include/DPS/FontSBP.h -usr/X11R6/include/DPS/FontSamplP.h -usr/X11R6/include/DPS/FontSample.h -usr/X11R6/include/DPS/PSres.h -usr/X11R6/include/DPS/XDPS.h -usr/X11R6/include/DPS/XDPSlib.h -usr/X11R6/include/DPS/XDPSproto.h -usr/X11R6/include/DPS/dpsNXargs.h -usr/X11R6/include/DPS/dpsXclient.h -usr/X11R6/include/DPS/dpsXcommon.h -usr/X11R6/include/DPS/dpsXpreview.h -usr/X11R6/include/DPS/dpsXshare.h -usr/X11R6/include/DPS/dpsXuserpath.h -usr/X11R6/include/DPS/dpsclient.h -usr/X11R6/include/DPS/dpsconfig.h -usr/X11R6/include/DPS/dpsexcept.h -usr/X11R6/include/DPS/dpsfriends.h -usr/X11R6/include/DPS/dpsops.h -usr/X11R6/include/DPS/psops.h @@ -643,0 +592 @@ +usr/X11R6/include/X11/CallbackI.h @@ -647,0 +597 @@ +usr/X11R6/include/X11/ConvertI.h @@ -649,0 +600 @@ +usr/X11R6/include/X11/CreateI.h @@ -650,0 +602 @@ +usr/X11R6/include/X11/EventI.h @@ -651,0 +604 @@ +usr/X11R6/include/X11/HookObjI.h @@ -657,0 +611,2 @@ +usr/X11R6/include/X11/ImUtil.h +usr/X11R6/include/X11/InitialI.h @@ -658,0 +614 @@ +usr/X11R6/include/X11/IntrinsicI.h @@ -663,0 +620 @@
Re: X.Org 6.9 Needs Your Build Logs!
Hi, I rebuilt the 6.9RC0 tree with the attached patch, which gave me the following MANIFEST diff: --- debian/MANIFEST.alpha 2005-10-22 00:25:25.0 + +++ debian/MANIFEST.alpha.new 2005-10-22 00:25:25.0 + @@ -18,2 +17,0 @@ -etc/X11/app-defaults/KOI8RXTerm -etc/X11/app-defaults/UXTerm @@ -34,2 +31,0 @@ -etc/X11/app-defaults/XTerm -etc/X11/app-defaults/XTerm-color @@ -455 +450,0 @@ -usr/X11R6/bin/Xorg-debug @@ -470,2 +464,0 @@ -usr/X11R6/bin/dpsexec -usr/X11R6/bin/dpsinfo @@ -485 +477,0 @@ -usr/X11R6/bin/koi8rxterm @@ -490 +481,0 @@ -usr/X11R6/bin/lxterm @@ -493 +483,0 @@ -usr/X11R6/bin/makepsres @@ -504,0 +495 @@ +usr/X11R6/bin/pclcomp @@ -506,2 +496,0 @@ -usr/X11R6/bin/pswrap -usr/X11R6/bin/resize @@ -520 +508,0 @@ -usr/X11R6/bin/texteroids @@ -523 +510,0 @@ -usr/X11R6/bin/uxterm @@ -528,0 +516 @@ +usr/X11R6/bin/xauth_switch_to_sun-des-1 @@ -536,0 +525 @@ +usr/X11R6/bin/xdbedizzy @@ -539,0 +529 @@ +usr/X11R6/bin/xdpr @@ -577,0 +568 @@ +usr/X11R6/bin/xpr @@ -591 +581,0 @@ -usr/X11R6/bin/xterm @@ -604,26 +593,0 @@ -usr/X11R6/include/DPS/ColorSB.h -usr/X11R6/include/DPS/ColorSBP.h -usr/X11R6/include/DPS/DPSScrollW.h -usr/X11R6/include/DPS/DPSScrollWP.h -usr/X11R6/include/DPS/FontCreatP.h -usr/X11R6/include/DPS/FontCreato.h -usr/X11R6/include/DPS/FontSB.h -usr/X11R6/include/DPS/FontSBP.h -usr/X11R6/include/DPS/FontSamplP.h -usr/X11R6/include/DPS/FontSample.h -usr/X11R6/include/DPS/PSres.h -usr/X11R6/include/DPS/XDPS.h -usr/X11R6/include/DPS/XDPSlib.h -usr/X11R6/include/DPS/XDPSproto.h -usr/X11R6/include/DPS/dpsNXargs.h -usr/X11R6/include/DPS/dpsXclient.h -usr/X11R6/include/DPS/dpsXcommon.h -usr/X11R6/include/DPS/dpsXpreview.h -usr/X11R6/include/DPS/dpsXshare.h -usr/X11R6/include/DPS/dpsXuserpath.h -usr/X11R6/include/DPS/dpsclient.h -usr/X11R6/include/DPS/dpsconfig.h -usr/X11R6/include/DPS/dpsexcept.h -usr/X11R6/include/DPS/dpsfriends.h -usr/X11R6/include/DPS/dpsops.h -usr/X11R6/include/DPS/psops.h @@ -643,0 +608 @@ +usr/X11R6/include/X11/CallbackI.h @@ -647,0 +613 @@ +usr/X11R6/include/X11/ConvertI.h @@ -649,0 +616 @@ +usr/X11R6/include/X11/CreateI.h @@ -650,0 +618 @@ +usr/X11R6/include/X11/EventI.h @@ -651,0 +620 @@ +usr/X11R6/include/X11/HookObjI.h @@ -657,0 +627,2 @@ +usr/X11R6/include/X11/ImUtil.h +usr/X11R6/include/X11/InitialI.h @@ -658,0 +630 @@ +usr/X11R6/include/X11/IntrinsicI.h @@ -663,0 +636 @@ +usr/X11R6/include/X11/PassivGraI.h @@ -665,0 +639 @@ +usr/X11R6/include/X11/ResourceI.h @@ -668,0 +643 @@ +usr/X11R6/include/X11/SelectionI.h @@ -669,0 +645 @@ +usr/X11R6/include/X11/ShellI.h @@ -672,0 +649,3 @@ +usr/X11R6/include/X11/ThreadsI.h +usr/X11R6/include/X11/TranslateI.h +usr/X11R6/include/X11/VarargsI.h @@ -762,0 +742 @@ +usr/X11R6/include/X11/XlibConf.h @@ -795,0 +776 @@ +usr/X11R6/include/X11/Xregion.h @@ -981,0 +963 @@ +usr/X11R6/include/X11/extensions/vldXvMC.h @@ -1009,0 +992,7 @@ +usr/X11R6/include/X11/fonts/bdfint.h +usr/X11R6/include/X11/fonts/bitmap.h +usr/X11R6/include/X11/fonts/bufio.h +usr/X11R6/include/X11/fonts/fntfil.h +usr/X11R6/include/X11/fonts/fntfilio.h +usr/X11R6/include/X11/fonts/fntfilst.h +usr/X11R6/include/X11/fonts/font.h @@ -1010,0 +1000,7 @@ +usr/X11R6/include/X11/fonts/fontencc.h +usr/X11R6/include/X11/fonts/fontmisc.h +usr/X11R6/include/X11/fonts/fontmod.h +usr/X11R6/include/X11/fonts/fontshow.h +usr/X11R6/include/X11/fonts/fontstruct.h +usr/X11R6/include/X11/fonts/fontutil.h +usr/X11R6/include/X11/fonts/fontxlfd.h @@ -1011,0 +1008 @@ +usr/X11R6/include/X11/fonts/pcf.h @@ -1013,0 +1011,2 @@ +usr/X11R6/include/X11/misc.h +usr/X11R6/include/X11/os.h @@ -1028,0 +1028 @@ +usr/X11R6/lib/X11/config/DragonFly.cf @@ -1087,0 +1088,3 @@ +usr/X11R6/lib/X11/config/mingw.cf +usr/X11R6/lib/X11/config/mingw.rules +usr/X11R6/lib/X11/config/mingw.tmpl @@ -1175,2 +1177,0 @@ -usr/X11R6/lib/X11/etc/xterm.termcap -usr/X11R6/lib/X11/etc/xterm.terminfo @@ -1449,0 +1451,3 @@ +usr/X11R6/lib/X11/locale/zh_CN.gb18030/Compose +usr/X11R6/lib/X11/locale/zh_CN.gb18030/XI18N_OBJS +usr/X11R6/lib/X11/locale/zh_CN.gb18030/XLC_LOCALE @@ -1455,0 +1460,4 @@ +usr/X11R6/lib/X11/locale/zh_HK.UTF-8/XI18N_OBJS +usr/X11R6/lib/X11/locale/zh_HK.UTF-8/XLC_LOCALE +usr/X11R6/lib/X11/locale/zh_HK.big5/Compose +usr/X11R6/lib/X11/locale/zh_HK.big5/XI18N_OBJS @@ -1456,0 +1465 @@ +usr/X11R6/lib/X11/locale/zh_HK.big5hkscs/Compose @@ -1487,0 +1497 @@ +usr/X11R6/lib/X11/xorg.conf.eg @@ -1499 +1509 @@ -usr/X11R6/lib/libICE.so.6.3 +usr/X11R6/lib/libICE.so.6.4 @@ -1558,0 +1569,2 @@ +usr/X11R6/lib/libXvMCW.a +usr/X11R6/lib/libXvMCW.so.1.0 @@ -1569,4 +1580,0 @@ -usr/X11R6/lib/libdps.a -usr/X11R6/lib/libdps.so.1.0 -usr/X11R6/lib/libdpstk.a -usr/X11R6/lib/libdpstk.so.1.0 @@ -1576,2 +1584,4 @@ -usr/X11R6/lib/libpsres.a -usr/X11R6/lib/libpsres.so.1.0 +usr/X11R6/lib/libviaXvMC.a +usr/X11R6/lib/libviaXvMC.so.1.0 +usr/X11R6/lib/libviaXvMCPro.a +usr/X11R6/lib/libviaXvMCPro.so.1.0 @@ -1584 +1593,0 @@ -usr/X11R6/lib/modules/dri/gamma_dri.so @@ -1590,84 +1599,95 @@ -usr/X11R6/lib/modules/drivers/ati_drv.o
Re: X.Org 6.9 Needs Your Build Logs!
Hi, please find attached the MANIFEST diff for sparc, for xorg-x11 6.9RC1. Cheers, Julien Cristau --- debian/MANIFEST.sparc 2005-10-22 01:15:03.0 + +++ debian/MANIFEST.sparc.new 2005-10-22 01:15:03.0 + @@ -92 +91,0 @@ -etc/X11/xkb/compat/group_led @@ -96 +95,3 @@ -etc/X11/xkb/compat/leds +etc/X11/xkb/compat/ledcaps +etc/X11/xkb/compat/lednum +etc/X11/xkb/compat/ledscroll @@ -224,0 +226 @@ +etc/X11/xkb/symbols/capslock @@ -242,0 +245 @@ +etc/X11/xkb/symbols/eurosign @@ -243,0 +247 @@ +etc/X11/xkb/symbols/fo @@ -305 +309,4 @@ -etc/X11/xkb/symbols/pc/ar +etc/X11/xkb/symbols/pc/ara +etc/X11/xkb/symbols/pc/az +etc/X11/xkb/symbols/pc/ba +etc/X11/xkb/symbols/pc/bd @@ -307 +313,0 @@ -etc/X11/xkb/symbols/pc/ben @@ -309,0 +316 @@ +etc/X11/xkb/symbols/pc/bt @@ -314 +320,0 @@ -etc/X11/xkb/symbols/pc/cz_qwerty @@ -316 +321,0 @@ -etc/X11/xkb/symbols/pc/dev @@ -318,2 +322,0 @@ -etc/X11/xkb/symbols/pc/dvorak -etc/X11/xkb/symbols/pc/dz @@ -321,2 +323,0 @@ -etc/X11/xkb/symbols/pc/el -etc/X11/xkb/symbols/pc/en_US @@ -324,0 +326 @@ +etc/X11/xkb/symbols/pc/fo @@ -326 +327,0 @@ -etc/X11/xkb/symbols/pc/fr-latin9 @@ -328,4 +329,2 @@ -etc/X11/xkb/symbols/pc/ge_la -etc/X11/xkb/symbols/pc/ge_ru -etc/X11/xkb/symbols/pc/guj -etc/X11/xkb/symbols/pc/gur +etc/X11/xkb/symbols/pc/ge +etc/X11/xkb/symbols/pc/gr @@ -336 +335 @@ -etc/X11/xkb/symbols/pc/il_phonetic +etc/X11/xkb/symbols/pc/in @@ -340 +338,0 @@ -etc/X11/xkb/symbols/pc/iu @@ -342 +340 @@ -etc/X11/xkb/symbols/pc/kan +etc/X11/xkb/symbols/pc/kg @@ -343,0 +342 @@ +etc/X11/xkb/symbols/pc/latam @@ -345 +344 @@ -etc/X11/xkb/symbols/pc/lo +etc/X11/xkb/symbols/pc/lk @@ -348,2 +347,2 @@ -etc/X11/xkb/symbols/pc/mk -etc/X11/xkb/symbols/pc/ml +etc/X11/xkb/symbols/pc/mao +etc/X11/xkb/symbols/pc/mkd @@ -353 +351,0 @@ -etc/X11/xkb/symbols/pc/mt_us @@ -356,2 +353,0 @@ -etc/X11/xkb/symbols/pc/ogham -etc/X11/xkb/symbols/pc/ori @@ -358,0 +355 @@ +etc/X11/xkb/symbols/pc/pk @@ -360 +356,0 @@ -etc/X11/xkb/symbols/pc/pl2 @@ -364 +359,0 @@ -etc/X11/xkb/symbols/pc/sapmi @@ -366,3 +360,0 @@ -etc/X11/xkb/symbols/pc/se_FI -etc/X11/xkb/symbols/pc/se_NO -etc/X11/xkb/symbols/pc/se_SE @@ -371,5 +363,2 @@ -etc/X11/xkb/symbols/pc/sk_qwerty -etc/X11/xkb/symbols/pc/sr -etc/X11/xkb/symbols/pc/syr -etc/X11/xkb/symbols/pc/syr_phonetic -etc/X11/xkb/symbols/pc/tel +etc/X11/xkb/symbols/pc/srp +etc/X11/xkb/symbols/pc/sy @@ -377,2 +365,0 @@ -etc/X11/xkb/symbols/pc/th_pat -etc/X11/xkb/symbols/pc/th_tis @@ -380 +366,0 @@ -etc/X11/xkb/symbols/pc/tml @@ -384 +369,0 @@ -etc/X11/xkb/symbols/pc/us_intl @@ -387 +371,0 @@ -etc/X11/xkb/symbols/pc/yu @@ -1505,2 +1488,0 @@ -usr/X11R6/lib/libI810XvMC.a -usr/X11R6/lib/libI810XvMC.so.1.0 @@ -1583,4 +1564,0 @@ -usr/X11R6/lib/libviaXvMC.a -usr/X11R6/lib/libviaXvMC.so.1.0 -usr/X11R6/lib/libviaXvMCPro.a -usr/X11R6/lib/libviaXvMCPro.so.1.0 @@ -1713,0 +1692,16 @@ +usr/X11R6/man/man1/XRRConfig.3x +usr/X11R6/man/man1/XRRConfigCurrentConfiguration.3x +usr/X11R6/man/man1/XRRConfigCurrentRate.3x +usr/X11R6/man/man1/XRRConfigRates.3x +usr/X11R6/man/man1/XRRConfigRotations.3x +usr/X11R6/man/man1/XRRConfigSizes.3x +usr/X11R6/man/man1/XRRConfigTimes.3x +usr/X11R6/man/man1/XRRFreeScreenConfigInfo.3x +usr/X11R6/man/man1/XRRGetScreenInfo.3x +usr/X11R6/man/man1/XRRQueryExtension.3x +usr/X11R6/man/man1/XRRQueryVersion.3x +usr/X11R6/man/man1/XRRRootToScreen.3x +usr/X11R6/man/man1/XRRScreenConfig.3x +usr/X11R6/man/man1/XRRSelectInput.3x +usr/X11R6/man/man1/XRRSetScreenConfig.3x +usr/X11R6/man/man1/XRRSetScreenConfigAndRate.3x @@ -1714,0 +1709,5 @@ +usr/X11R6/man/man1/XevieEnd.3x +usr/X11R6/man/man1/XevieQueryVersion.3x +usr/X11R6/man/man1/XevieSelectInput.3x +usr/X11R6/man/man1/XevieSendEvent.3x +usr/X11R6/man/man1/XevieStart.3x signature.asc Description: Digital signature
Re: X.Org 6.9 Needs Your Build Logs!
David Nusinow [EMAIL PROTECTED] writes: Once you build it, either post the log somewhere or send the diff at the end (it'll be a diff of MANIFEST files) to debian-x. I've set the m-f-t to debian-x, so you can just reply to this mail if it suits you. Thanks to everyone for helping get Xorg 6.9 in to Debian in a timely manner! Here's the diff for xorg-x11-6.8.99.901.dfsg.1-1 on ia64: --- debian/MANIFEST.ia642005-10-21 14:20:30.0 + +++ debian/MANIFEST.ia64.new2005-10-21 14:20:30.0 + @@ -18,2 +17,0 @@ -etc/X11/app-defaults/KOI8RXTerm -etc/X11/app-defaults/UXTerm @@ -34,2 +31,0 @@ -etc/X11/app-defaults/XTerm -etc/X11/app-defaults/XTerm-color @@ -96 +91,0 @@ -etc/X11/xkb/compat/group_led @@ -100 +95,3 @@ -etc/X11/xkb/compat/leds +etc/X11/xkb/compat/ledcaps +etc/X11/xkb/compat/lednum +etc/X11/xkb/compat/ledscroll @@ -228,0 +226 @@ +etc/X11/xkb/symbols/capslock @@ -246,0 +245 @@ +etc/X11/xkb/symbols/eurosign @@ -247,0 +247 @@ +etc/X11/xkb/symbols/fo @@ -309 +309,4 @@ -etc/X11/xkb/symbols/pc/ar +etc/X11/xkb/symbols/pc/ara +etc/X11/xkb/symbols/pc/az +etc/X11/xkb/symbols/pc/ba +etc/X11/xkb/symbols/pc/bd @@ -311 +313,0 @@ -etc/X11/xkb/symbols/pc/ben @@ -313,0 +316 @@ +etc/X11/xkb/symbols/pc/bt @@ -318 +320,0 @@ -etc/X11/xkb/symbols/pc/cz_qwerty @@ -320 +321,0 @@ -etc/X11/xkb/symbols/pc/dev @@ -322,2 +322,0 @@ -etc/X11/xkb/symbols/pc/dvorak -etc/X11/xkb/symbols/pc/dz @@ -325,2 +323,0 @@ -etc/X11/xkb/symbols/pc/el -etc/X11/xkb/symbols/pc/en_US @@ -328,0 +326 @@ +etc/X11/xkb/symbols/pc/fo @@ -330 +327,0 @@ -etc/X11/xkb/symbols/pc/fr-latin9 @@ -332,4 +329,2 @@ -etc/X11/xkb/symbols/pc/ge_la -etc/X11/xkb/symbols/pc/ge_ru -etc/X11/xkb/symbols/pc/guj -etc/X11/xkb/symbols/pc/gur +etc/X11/xkb/symbols/pc/ge +etc/X11/xkb/symbols/pc/gr @@ -340 +335 @@ -etc/X11/xkb/symbols/pc/il_phonetic +etc/X11/xkb/symbols/pc/in @@ -344 +338,0 @@ -etc/X11/xkb/symbols/pc/iu @@ -346 +340 @@ -etc/X11/xkb/symbols/pc/kan +etc/X11/xkb/symbols/pc/kg @@ -347,0 +342 @@ +etc/X11/xkb/symbols/pc/latam @@ -349 +344 @@ -etc/X11/xkb/symbols/pc/lo +etc/X11/xkb/symbols/pc/lk @@ -352,2 +347,2 @@ -etc/X11/xkb/symbols/pc/mk -etc/X11/xkb/symbols/pc/ml +etc/X11/xkb/symbols/pc/mao +etc/X11/xkb/symbols/pc/mkd @@ -357 +351,0 @@ -etc/X11/xkb/symbols/pc/mt_us @@ -360,2 +353,0 @@ -etc/X11/xkb/symbols/pc/ogham -etc/X11/xkb/symbols/pc/ori @@ -362,0 +355 @@ +etc/X11/xkb/symbols/pc/pk @@ -364 +356,0 @@ -etc/X11/xkb/symbols/pc/pl2 @@ -368 +359,0 @@ -etc/X11/xkb/symbols/pc/sapmi @@ -370,3 +360,0 @@ -etc/X11/xkb/symbols/pc/se_FI -etc/X11/xkb/symbols/pc/se_NO -etc/X11/xkb/symbols/pc/se_SE @@ -375,5 +363,2 @@ -etc/X11/xkb/symbols/pc/sk_qwerty -etc/X11/xkb/symbols/pc/sr -etc/X11/xkb/symbols/pc/syr -etc/X11/xkb/symbols/pc/syr_phonetic -etc/X11/xkb/symbols/pc/tel +etc/X11/xkb/symbols/pc/srp +etc/X11/xkb/symbols/pc/sy @@ -381,2 +365,0 @@ -etc/X11/xkb/symbols/pc/th_pat -etc/X11/xkb/symbols/pc/th_tis @@ -384 +366,0 @@ -etc/X11/xkb/symbols/pc/tml @@ -388 +369,0 @@ -etc/X11/xkb/symbols/pc/us_intl @@ -391 +371,0 @@ -etc/X11/xkb/symbols/pc/yu @@ -455 +434,0 @@ -usr/X11R6/bin/Xorg-debug @@ -470,2 +448,0 @@ -usr/X11R6/bin/dpsexec -usr/X11R6/bin/dpsinfo @@ -485 +461,0 @@ -usr/X11R6/bin/koi8rxterm @@ -490 +465,0 @@ -usr/X11R6/bin/lxterm @@ -493 +467,0 @@ -usr/X11R6/bin/makepsres @@ -504,0 +479 @@ +usr/X11R6/bin/pclcomp @@ -506,2 +480,0 @@ -usr/X11R6/bin/pswrap -usr/X11R6/bin/resize @@ -520 +492,0 @@ -usr/X11R6/bin/texteroids @@ -523 +494,0 @@ -usr/X11R6/bin/uxterm @@ -528,0 +500 @@ +usr/X11R6/bin/xauth_switch_to_sun-des-1 @@ -536,0 +509 @@ +usr/X11R6/bin/xdbedizzy @@ -539,0 +513 @@ +usr/X11R6/bin/xdpr @@ -577,0 +552 @@ +usr/X11R6/bin/xpr @@ -591 +565,0 @@ -usr/X11R6/bin/xterm @@ -604,26 +577,0 @@ -usr/X11R6/include/DPS/ColorSB.h -usr/X11R6/include/DPS/ColorSBP.h -usr/X11R6/include/DPS/DPSScrollW.h -usr/X11R6/include/DPS/DPSScrollWP.h -usr/X11R6/include/DPS/FontCreatP.h -usr/X11R6/include/DPS/FontCreato.h -usr/X11R6/include/DPS/FontSB.h -usr/X11R6/include/DPS/FontSBP.h -usr/X11R6/include/DPS/FontSamplP.h -usr/X11R6/include/DPS/FontSample.h -usr/X11R6/include/DPS/PSres.h -usr/X11R6/include/DPS/XDPS.h -usr/X11R6/include/DPS/XDPSlib.h -usr/X11R6/include/DPS/XDPSproto.h -usr/X11R6/include/DPS/dpsNXargs.h -usr/X11R6/include/DPS/dpsXclient.h -usr/X11R6/include/DPS/dpsXcommon.h -usr/X11R6/include/DPS/dpsXpreview.h -usr/X11R6/include/DPS/dpsXshare.h -usr/X11R6/include/DPS/dpsXuserpath.h -usr/X11R6/include/DPS/dpsclient.h -usr/X11R6/include/DPS/dpsconfig.h -usr/X11R6/include/DPS/dpsexcept.h -usr/X11R6/include/DPS/dpsfriends.h -usr/X11R6/include/DPS/dpsops.h -usr/X11R6/include/DPS/psops.h @@ -643,0 +592 @@ +usr/X11R6/include/X11/CallbackI.h @@ -647,0 +597 @@ +usr/X11R6/include/X11/ConvertI.h @@ -649,0 +600 @@ +usr/X11R6/include/X11/CreateI.h @@ -650,0 +602 @@ +usr/X11R6/include/X11/EventI.h @@ -651,0 +604 @@ +usr/X11R6/include/X11/HookObjI.h @@ -657,0 +611,2 @@ +usr/X11R6/include/X11/ImUtil.h +usr/X11R6/include/X11/InitialI.h @@ -658,0 +614 @@
Re: X.Org 6.9 Needs Your Build Logs!
On Sat, Oct 8, 2005 at 00:25:57 +0200, Falk Hueffner wrote: Julien Cristau [EMAIL PROTECTED] writes: I just tried to build xorg-x11 from current svn on alpha. It failed in xc/lib/GL/mesa/drivers/dri/r128/r128_ioctl.c, with what looks like a missing #include somewhere. I don't have the time to investigate right now, but will look into it next week if noone does it first. Build log is available at http://perso.ens-lyon.fr/julien.cristau/xorg-x11_6.8.99.900_alpha.log. Where can this be obtained? I can only find 6.8.2.dfsg.1-8+SVN. Either get the xorg-x11 source package from experimental, or run svn export svn://necrotic.deadbeast.net/xorg-x11/branches/6.9 xorg-x11-6.8.99.900.dfsg.1. Cheers, Julien Cristau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org 6.9 Needs Your Build Logs!
Hi, I just tried to build xorg-x11 from current svn on alpha. It failed in xc/lib/GL/mesa/drivers/dri/r128/r128_ioctl.c, with what looks like a missing #include somewhere. I don't have the time to investigate right now, but will look into it next week if noone does it first. Build log is available at http://perso.ens-lyon.fr/julien.cristau/xorg-x11_6.8.99.900_alpha.log. Cheers, Julien Cristau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org 6.9 Needs Your Build Logs!
Hi David, David Nusinow wrote: Once you build it, either post the log somewhere or send the diff at the end (it'll be a diff of MANIFEST files) to debian-x. Building from the subversion source on powerpc (ibook) gives this : diff MANIFEST.powerpc MANIFEST.powerpc.new 1249a1250 usr/X11R6/lib/X11/doc/html/Xprint_FAQ.html Yannick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org 6.9 Needs Your Build Logs!
Julien Cristau [EMAIL PROTECTED] writes: I just tried to build xorg-x11 from current svn on alpha. It failed in xc/lib/GL/mesa/drivers/dri/r128/r128_ioctl.c, with what looks like a missing #include somewhere. I don't have the time to investigate right now, but will look into it next week if noone does it first. Build log is available at http://perso.ens-lyon.fr/julien.cristau/xorg-x11_6.8.99.900_alpha.log. Where can this be obtained? I can only find 6.8.2.dfsg.1-8+SVN. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org experimental packages.
El Jueves, 4 de Agosto de 2005 20:12, David Nusinow escribió: On Thu, Aug 04, 2005 at 07:27:02PM +0200, David Martínez Moreno wrote: Hello to all. I have built 6.8.2.dfsg.1-4+SVN, with an snapshot from yesterday, and additionally with a backport of Savage driver from HEAD. The URL for the packages is: Why don't you commit the backported driver? Well, I could aduce some technical reasons, but it is simpler. I do not know exactly what I am doing while backporting things. I am not a real programmer, and I learn by trial and error. I began trying to help a Savage user bitten by the driver age. Then I began to use the quilt system. And I found the nice world of backporting. Error, errors, errors. And this was my first backport. Since I am not very fluent in C, and worse, in high-level C like in kernel or X, I am very unsure about my achievings. I thought that maybe putting the packages in a public place some nice souls would test them, like the Savage user. You all, Michel, Daniel, you, Nathanael, Eugene, Nikita...it seems that you do what you want, and that you know what the heck are you doing. I feel blind backporting things, because I do not know what I am really doing by #ifdef'ing some lines of code in the n-th non-compiling file, or playing with Imakefiles. I feel *so* lost when I read some of your explanations... Summary: I fear to break things. Break more things that I intend to fix. :-\ This is the reason. It should be a Friday's crisis. Do not worry. If I decide to commit the Savage thing, I would like to add the missing DRI part (if I am able to) before. Respectfully, Ender. -- Buzz Lightyear: You killed my father! Emperor Zurg: No, Buzz...I am your father. -- Toy Story 2. -- Debian developer pgpNdZv1dilfj.pgp Description: PGP signature
Re: X.Org experimental packages.
On Thu, Aug 04, 2005 at 07:27:02PM +0200, David Martínez Moreno wrote: Hello to all. I have built 6.8.2.dfsg.1-4+SVN, with an snapshot from yesterday, and additionally with a backport of Savage driver from HEAD. The URL for the packages is: Why don't you commit the backported driver? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
Followup: On Tue, Jul 19, 2005 at 01:49:05AM -0700, Steve Langasek wrote: On Mon, Jul 18, 2005 at 11:29:31PM -0400, jacob wrote: Greetings all. Today with a day of mixed blessings. I was over-joyed to see X.org finally make into the Alpha/Sid. However, no amount of convolutions by myself was sufficient to cause it to work on my Matrox Graphics, Inc. MGA 2164W [Millennium II]. Sadly, the settings with which the card worked under 4.3.0.dfsg.1-14 seemed no longer acceptable to the X.org mga_drv. *sigh* After googling (as much as I was up to tonight), I added 'Load xaa' to get rid of the XAA* unresolved symbols. I tried not loading any modules. Nothing I did seemed to affect the xf86I2C* unresolved symbols, nor the type 28 Elf_Relocation error (google was strangely silent about this error). I was able to lock up the display, so it wouldn't change, regardless of input (although I was still able to switch to tty1, with a blank screen, and reboot). I've just upgraded to xserver-xorg on my alpha in response to your mail. The missing symbols are fixed by adding these two lines to xorg.conf: Loadxaa Loadlibi2c Sounds like a bug to me; I shouldn't have to manually load modules in order to use a particular X driver... The segfault, though, remains even after making this change. (The Elf_RelocationEntry() errors do also, but I'm not certain those are a real problem). Please file a bug report against the xserver-xorg package, so that the X maintainers can take a look at this. Ok, in fact the ELF_RelocationEntry() errors *are* related: if I install xserver-xorg-dbg, which doesn't depend on X's bletcherous internal ELF object loader, there's no segfault at all; the server starts fine. So a workaround for you is to use xserver-xorg-dbg for right now, but the xserver-xorg package is more or less completely broken on alpha. XSF, can we switch to using dlloader on alpha? Pleese? :) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: X.org and the Matrox Millenium II
On Tue, Jul 19, 2005 at 02:02:35AM -0700, Steve Langasek wrote: XSF, can we switch to using dlloader on alpha? Pleese? :) It does not make sense to do this for one architecture only. I'd suggest that until we move to dlloader wholesale, alpha joins hppa, mips*, m68k, sh*, etc in using a static-only server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Wed, Jul 20, 2005 at 02:00:07AM +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 02:02:35AM -0700, Steve Langasek wrote: XSF, can we switch to using dlloader on alpha? Pleese? :) It does not make sense to do this for one architecture only. I'd suggest that until we move to dlloader wholesale, alpha joins hppa, mips*, m68k, sh*, etc in using a static-only server. Are there any serious plans from upstream to move to dlloader after the modularization effort is done? Freedesktop bug #400 isn't clear on that... Also, how much work would it take to move to dlloader wholesale? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Tue, 2005-07-19 at 13:57 -0400, David Nusinow wrote: On Wed, Jul 20, 2005 at 02:00:07AM +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 02:02:35AM -0700, Steve Langasek wrote: XSF, can we switch to using dlloader on alpha? Pleese? :) It does not make sense to do this for one architecture only. I'd suggest that until we move to dlloader wholesale, alpha joins hppa, mips*, m68k, sh*, etc in using a static-only server. Are there any serious plans from upstream to move to dlloader after the modularization effort is done? X.org HEAD was switched to build dlloader by default a while ago, so it'll be like that in 6.9/7.0. That said, I don't know if or how well dlloader works on all the architectures, but I'd expect it to be more portable than elfloader. Regards from DDC/OLS, -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: X.org and the Matrox Millenium II
On Tue, Jul 19, 2005 at 03:17:02PM -0400, Michel Dänzer wrote: On Tue, 2005-07-19 at 13:57 -0400, David Nusinow wrote: On Wed, Jul 20, 2005 at 02:00:07AM +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 02:02:35AM -0700, Steve Langasek wrote: XSF, can we switch to using dlloader on alpha? Pleese? :) It does not make sense to do this for one architecture only. I'd suggest that until we move to dlloader wholesale, alpha joins hppa, mips*, m68k, sh*, etc in using a static-only server. Are there any serious plans from upstream to move to dlloader after the modularization effort is done? X.org HEAD was switched to build dlloader by default a while ago, so it'll be like that in 6.9/7.0. That said, I don't know if or how well dlloader works on all the architectures, but I'd expect it to be more portable than elfloader. Ok, perhaps our best interests are served by getting 6.9/7.0 in to Debian as fast as possible once it's released. I'd rather spend energy on that than patching up 6.8 to make it a sorta-6.9. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Tue, 2005-07-19 at 15:35 -0400, David Nusinow wrote: Ok, perhaps our best interests are served by getting 6.9/7.0 in to Debian as fast as possible once it's released. I'd rather spend energy on that than patching up 6.8 to make it a sorta-6.9. I agree. Maybe start by packaging the upcoming RC0 into experimental? :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: X.org and the Matrox Millenium II
On Tue, Jul 19, 2005 at 05:42:06PM -0400, Michel Dänzer wrote: On Tue, 2005-07-19 at 15:35 -0400, David Nusinow wrote: Ok, perhaps our best interests are served by getting 6.9/7.0 in to Debian as fast as possible once it's released. I'd rather spend energy on that than patching up 6.8 to make it a sorta-6.9. I agree. Maybe start by packaging the upcoming RC0 into experimental? :) I've sorta started doing this privately, although whether or not it'll go to experimental or just my own unofficial repo, I haven't decided. I've done very little on it (read: almost nothing) but I can put it in an svn branch if people are interested in starting in on it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Tue, Jul 19, 2005 at 01:57:47PM -0400, David Nusinow wrote: On Wed, Jul 20, 2005 at 02:00:07AM +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 02:02:35AM -0700, Steve Langasek wrote: XSF, can we switch to using dlloader on alpha? Pleese? :) It does not make sense to do this for one architecture only. I'd suggest that until we move to dlloader wholesale, alpha joins hppa, mips*, m68k, sh*, etc in using a static-only server. Are there any serious plans from upstream to move to dlloader after the modularization effort is done? Freedesktop bug #400 isn't clear on that... dlloader has been the default in 6.9 for a few months now, and the modular tree has no idea how to build .o modules, only .so. Also, how much work would it take to move to dlloader wholesale? A reasonable amount, plus breaking all external drivers (Synaptics, ATI, nVidia) until it gets sorted out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Tue, Jul 19, 2005 at 03:17:02PM -0400, Michel Dänzer wrote: X.org HEAD was switched to build dlloader by default a while ago, so it'll be like that in 6.9/7.0. That said, I don't know if or how well dlloader works on all the architectures, but I'd expect it to be more portable than elfloader. It works on all of them, and far, far better than elfloader ever will. If your platform has a broken libdl, it has bigger problems than not being able to run Xorg from HEAD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Wed, Jul 20, 2005 at 11:51:29AM +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 01:57:47PM -0400, David Nusinow wrote: Also, how much work would it take to move to dlloader wholesale? A reasonable amount, plus breaking all external drivers (Synaptics, ATI, nVidia) until it gets sorted out. Ok, that confirms it. We'll just push ahead and try and get 6.9/7.0 packages ready as soon as we can. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and the Matrox Millenium II
On Wed, 2005-07-20 at 11:52 +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 03:17:02PM -0400, Michel Dänzer wrote: X.org HEAD was switched to build dlloader by default a while ago, so it'll be like that in 6.9/7.0. That said, I don't know if or how well dlloader works on all the architectures, but I'd expect it to be more portable than elfloader. It works on all of them, and far, far better than elfloader ever will. If your platform has a broken libdl, it has bigger problems than not being able to run Xorg from HEAD. I know, but that's only the runtime part. I figured there could still be build-time issues on some architectures, but if not, all the better. :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: X.org and the Matrox Millenium II
On Wed, Jul 20, 2005 at 12:49:09AM -0400, Michel Dänzer wrote: On Wed, 2005-07-20 at 11:52 +1000, Daniel Stone wrote: On Tue, Jul 19, 2005 at 03:17:02PM -0400, Michel Dänzer wrote: X.org HEAD was switched to build dlloader by default a while ago, so it'll be like that in 6.9/7.0. That said, I don't know if or how well dlloader works on all the architectures, but I'd expect it to be more portable than elfloader. It works on all of them, and far, far better than elfloader ever will. If your platform has a broken libdl, it has bigger problems than not being able to run Xorg from HEAD. I know, but that's only the runtime part. I figured there could still be build-time issues on some architectures, but if not, all the better. :) Not that I'm aware of, no. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x.org experimental packages testing
* Lionel Elie Mamane wrote: Setting up xfree86-common (6.8.2.dfsg.1-0pre1v1) ... update-rc.d: /etc/init.d/xfree86-common exists during rc.d purge (use -f to force) dpkg: error processing xfree86-common (--configure): subprocess post-installation script returned error exit status 1 Known bug, check the list archive. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org packages
Zoe Parsons wrote: I just upgraded to them from the repository as mentioned in David's Blog and it seemed to go without a hitch apart from getting a message about how /etc/init.d/xfree86-common existed during purge. So that's one happy bunny over here if nowhere else. :-) Now just waiting for the day of the upload to unstable... Same here, the upgrade worked very well. Only two Problems so far: (1) I'm missing a synaptics-driver for my touchpad. Something like: xfree86-driver-synaptics (2) After the xorg.config was created (my hardware was completely recognized) -- my settings for the displaysize where lost. So xserver defaults to 75dpi. Regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org packages
On Saturday 25 June 2005 13:00, Bastian Venthur wrote: Zoe Parsons wrote: I just upgraded to them from the repository as mentioned in David's Blog and it seemed to go without a hitch apart from getting a message about how /etc/init.d/xfree86-common existed during purge. So that's one happy bunny over here if nowhere else. :-) Now just waiting for the day of the upload to unstable... Same here, the upgrade worked very well. Only two Problems so far: (1) I'm missing a synaptics-driver for my touchpad. Something like: xfree86-driver-synaptics Try ftp://ftp.cyconet.org/pub/debian/xorg-driver-synaptics/ .. this was compiled for a backport of the ubuntu packages on sid half year ago. These Package works fine here. If this doesnt work, try to recompile the packages on your system. If this also doenst fit, you maybe recompile the package from ftp://archive.ubuntulinux.org/ubuntu/pool/main/x/xorg-driver-synaptics/ With kind Regards, Jan. -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a-- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M-- V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgp7VGKIa76Bm.pgp Description: PGP signature
Re: X.org backport for sarge
I have one question about X.org: in any X.org based distribution I've ever tried setting more than one keyboard layouts under GNOME fails with some kind of error messages or if the messages are ingnored it's type symbols instead of a normal letters it should type and the second layout is invisible on the GNOME panel. I just wondering am I doing something wrong (but I doubt), or why nobody have reported/fixed it yet: Slackware 10.1 (gnome 2.6), Mandrake 10.2 (gnome 2.8), Fedora 4 (gnome 2.10) - all this disrtos ships with this bug. Is this bug fixed in Debian X.org packages? --- Original message --- From: Norbert Tretkowski [EMAIL PROTECTED] To: debian-x@lists.debian.org, [EMAIL PROTECTED] Subject: X.org backport for sarge Date: 25 Июнь 2005 16:43 Hi, after David Nusinow's announcement of experimental X.org packages, I couldn't resist building a backport for sarge. If you want to give it a try, add this line to your sources.list: deb http://people.debian.org/~nobse/xorg-x11/ sarge main If you have problems, please don't file bugreports against the Debian Bug Tracking Systems, instead contact the debian-x mailinglist. Norbert
Re: X.Org packages
Zoe Parsons [EMAIL PROTECTED] writes: I just upgraded to them from the repository as mentioned in David's Blog and it seemed to go without a hitch apart from getting a message about how /etc/init.d/xfree86-common existed during purge. I've installed the packages too, and they work perfectly, great work! -- Regards, Emilio Jesús Gallego Arias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.Org packages
On Friday 24 June 2005 21:07, Zoe Parsons wrote: I just upgraded to them from the repository as mentioned in David's Blog and it seemed to go without a hitch apart from getting a message about how /etc/init.d/xfree86-common existed during purge. /aol Setting up xfree86-common (6.8.2.dfsg.1-0pre1v1) ... update-rc.d: /etc/init.d/xfree86-common exists during rc.d purge (use -f to force) dpkg: error processing xfree86-common (--configure): subprocess post-installation script returned error exit status 1 With kind Regards, Jan. -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a-- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M-- V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgpB9Cl2unj8k.pgp Description: PGP signature
Re: X.org Packaging Roadmap
daniel == Daniel Stone [EMAIL PROTECTED] writes: daniel I've been working upstream on the modular tree on my week daniel off, and the libs are done, and the server is well on the daniel way. How far we currently are from modular tree? If it's not so far, could be better we help and improve it's speed and then use it directly inside of Debian. What you think? daniel X11R7 will release on August 19th; the protocol headers daniel and libraries are basically done today. The architecture daniel for the server is fine, and I've been tweaking things daniel until they work, but it will need a reasonable amount of daniel porting love, in terms of instructing the code about the daniel host system, as the server needs very intimate knowledge daniel of the system. daniel Most of the apps aren't autotooled (which is probably daniel indicative of the fact that no-one actually cares), but daniel they're utterly trivial to do. Well, looks like we aren't so far to have it working then. I see two possible ways to go, and I prefer the secound: - We package the current release of X.org and start to work on the modular tree after it; - We start to package the modular treee now and helps to solve the pending problems. So, like others packages, we can use CVS snapshots in the meantime and on August we will have it ready. We won't have the each released before August so this doesn't cause any more serious problem IMHO. What you and the others think about it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Mon, Apr 25, 2005 at 12:38:09PM +1000, Daniel Stone wrote: As always, you know my email address if you need to ask questions, but at this stage, the effort is utterly uninteresting to me, due to the fact I'm not allowed to get involved in any meaningful way. I'll keep on playing in my own little world. I'm going to reply to the rest later, but I'm going to make it a priority to talk to Branden about getting you svn access. Hopefully I can massage some stuff behind the scenes. I'm also going to talk to him about the possibility of moving development off his home servers and on to alioth, to make it less his home turf. I would really like to have you working on the same tree as us directly. - take care, David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Mon, Apr 25, 2005 at 01:02:29PM +1000, Daniel Stone wrote: X11R7 will release on August 19th; the protocol headers and libraries are basically done today. The architecture for the server is fine, and I've been tweaking things until they work, but it will need a reasonable amount of porting love, in terms of instructing the code about the host system, as the server needs very intimate knowledge of the system. Ok, given this I think we should begin with the monolithic tree. I feel that we need to get this moving along, and waiting on the autotooling doesn't make sense when we have useable packages to start from. Do you think you could push your autotool server tree in to your public arch repo where you keep debrix so I could take a look at it? I'd be willing to work, at least on the X server, on packages from both the monolithic and modular tree in parallel. Perhaps packages derived from the monolithic tree shouldn't ever leave experimental, but at least they'd be available. Most of the apps aren't autotooled (which is probably indicative of the fact that no-one actually cares), but they're utterly trivial to do. Perhaps someone who's interested in maintaining the apps for Debian would be willing to help? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Mon, Apr 25, 2005 at 12:38:09PM +1000, Daniel Stone wrote: On Sun, Apr 24, 2005 at 06:45:58PM -0400, David Nusinow wrote: 1) Import Ubuntu packaging for X.org in to our svn repo wholesale. Whether this should be from the Hoary release package, or the most recent develpoment tree, I don't know, and I'd like to hear from Daniel on what he thinks. I have packages to kick-start the modular tree transition on my laptop. Right now, however, the best base to use would be 6.8.2-10. Sounds good. Not sure what to do about your modular packages yet though, but tackling one thing at a time is probably best. 2) Make any necessary changes for them to be Debian, rather than Ubuntu packages. These should not be major, but more akin to a re-branding. Another interesting question is what to do with version numbers, since 6.8.2-1 will suddenly become ambiguous. You mean an ambiguity between the ubuntu and debian packages? Maybe for these we can just append dfsg to the version or something, as in the past. If we can make this go away completely for the 7.x release, that'd be awesome. 3) Make sure they build on x86, ppc, and whatever else we have lying around collectively. Also make sure they install properly. Ubuntu is actually a step ahead of Debian here in that we do source-only uploads, so every arch gets autobuilt: it's fine on amd64, i386, powerpc, sparc, and ia64. hppa should also be alright. Good to hear, and hopefully we can get some testers on these arches. During this phase, we can also do things like add the massive commentary to debian/control that Branden has begun already in the X.org branch of his svn repo. I think this is a good idea personally, but it's not pressing that it's available in the first upload to experimental. It's obviously valuable work, but I think blocking the support of newer ATI, Intel and nVidia cards on it is utterly suicidal. Right now, you basically cannot purchase a laptop that will work out of the box under Debian. Agreed. I've seen too many people in #debian wanting or needing X.org packages. I've been working upstream on the modular tree on my week off, and the libs are done, and the server is well on the way. Awesome. Josh Triplett and I seem to be doing packaging in parallel, largely because I've been very, very slack on getting my packages to him. Which is why we need to get you guys working from the same tree :-) As always, you know my email address if you need to ask questions, but at this stage, the effort is utterly uninteresting to me, due to the fact I'm not allowed to get involved in any meaningful way. I'll keep on playing in my own little world. We'll work something out. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Sun, Apr 24, 2005 at 08:10:42PM -0300, Otavio Salvador wrote: Since we'll review all changes made by Ubuntu makes more sense to me do it while import it from his repository. This make simple for us and for users use a know base to work. So are you saying you want to import each file individually? We could do that, where when you import a file, you basically say I've checked over this file and it's Ok to go in. The only problem is that in my last pull of ubuntu's X.org package sources, there are ~638 changelog lines devoted to fixes. That's a lot of changes to review, and since few people have stepped up to volunteer to review them, it could take a very long time. Other issue could be have it uploaded to experimental without review all include changes. I don't think this is right. IMHO, we shouldn't upload a package without have sure what fixes are included and why. This is a good point. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
david == David Nusinow [EMAIL PROTECTED] writes: david On Sun, Apr 24, 2005 at 08:10:42PM -0300, Otavio Salvador david wrote: Since we'll review all changes made by Ubuntu makes more sense to me do it while import it from his repository. This make simple for us and for users use a know base to work. david So are you saying you want to import each file david individually? We could do that, where when you import a david file, you basically say I've checked over this file and david it's Ok to go in. The only problem is that in my last pull david of ubuntu's X.org package sources, there are ~638 changelog david lines devoted to fixes. That's a lot of changes to review, david and since few people have stepped up to volunteer to review david them, it could take a very long time. Yes. I know is a lot of work but it need to be done by us. Other issue could be have it uploaded to experimental without review all include changes. I don't think this is right. IMHO, we shouldn't upload a package without have sure what fixes are included and why. david This is a good point. Yes and that's the reason why we need to review the fixes. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Mon, Apr 25, 2005 at 04:52:41PM -0300, Otavio Salvador wrote: david == David Nusinow [EMAIL PROTECTED] writes: david So are you saying you want to import each file david individually? We could do that, where when you import a david file, you basically say I've checked over this file and david it's Ok to go in. The only problem is that in my last pull david of ubuntu's X.org package sources, there are ~638 changelog david lines devoted to fixes. That's a lot of changes to review, david and since few people have stepped up to volunteer to review david them, it could take a very long time. Yes. I know is a lot of work but it need to be done by us. Ok, I'm willing to do this for the X server once I get svn access. This includes both the xserver-xfree86 and xserver-common package contents. We need people to volunteer to check over and commit the following: - xlibs (I'm way too lazy to list them all, but a few new ones have popped up in X.org) - xapps - xterm - xdm - twm - fonts - Docs - xspecs - xfree86-common contents - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Mon, Apr 25, 2005 at 02:20:28PM -0400, David Nusinow wrote: Do you think you could push your autotool server tree in to your public arch repo where you keep debrix so I could take a look at it? I'd be willing to work, at least on the X server, on packages from both the monolithic and modular tree in parallel. When it compiles and works, I'll commit a shadow tree of autotool infrastructure to CVS somewhere. Perhaps packages derived from the monolithic tree shouldn't ever leave experimental, but at least they'd be available. This is what I've been saying for a very long time ... signature.asc Description: Digital signature
Re: X.org Packaging Roadmap
david == David Nusinow [EMAIL PROTECTED] writes: david I'd like to hammer out a roadmap for getting X.org packages david ready to go. Feedback from everyone is critical, of david course. Here's what I've got so far: david 1) Import Ubuntu packaging for X.org in to our svn repo david wholesale. Whether this should be from the Hoary release david package, or the most recent develpoment tree, I don't know, david and I'd like to hear from Daniel on what he thinks. Since we'll review all changes made by Ubuntu makes more sense to me do it while import it from his repository. This make simple for us and for users use a know base to work. Other issue could be have it uploaded to experimental without review all include changes. I don't think this is right. IMHO, we shouldn't upload a package without have sure what fixes are included and why. my 2c ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Sun, Apr 24, 2005 at 06:45:58PM -0400, David Nusinow wrote: 1) Import Ubuntu packaging for X.org in to our svn repo wholesale. Whether this should be from the Hoary release package, or the most recent develpoment tree, I don't know, and I'd like to hear from Daniel on what he thinks. I have packages to kick-start the modular tree transition on my laptop. Right now, however, the best base to use would be 6.8.2-10. 2) Make any necessary changes for them to be Debian, rather than Ubuntu packages. These should not be major, but more akin to a re-branding. Another interesting question is what to do with version numbers, since 6.8.2-1 will suddenly become ambiguous. 3) Make sure they build on x86, ppc, and whatever else we have lying around collectively. Also make sure they install properly. Ubuntu is actually a step ahead of Debian here in that we do source-only uploads, so every arch gets autobuilt: it's fine on amd64, i386, powerpc, sparc, and ia64. hppa should also be alright. 5) With packages in place, we can go about making sure that all the changes made to the Ubuntu packages are good for Debian. I have complete faith in Daniel and Fabio's work, but I think we need to re-evaluate it. I know Branden has expressed that he wants to be aware of what's been done, and I need a chance to learn the X server, so this will be a good opportunity for both. During this phase, we can also do things like add the massive commentary to debian/control that Branden has begun already in the X.org branch of his svn repo. I think this is a good idea personally, but it's not pressing that it's available in the first upload to experimental. It's obviously valuable work, but I think blocking the support of newer ATI, Intel and nVidia cards on it is utterly suicidal. Right now, you basically cannot purchase a laptop that will work out of the box under Debian. Now, I haven't been following the xorg modularization list (I did subscribe finally though) so I don't know the progress on that. I think it'll be a good idea to begin packaging it once things begin to take shape. Since a lot of the work has already been done by Daniel for his debrix tree, we should be able to figure out the basics of what we'll need to do. I think that we should start a branch for the modular tree once the tree itself begins to take enough of a shape that we can work on it. We can worry about transitioning to it once we actually can see what's going on. If we release etch with packages derived from the monolithic tree, so be it. I've been working upstream on the modular tree on my week off, and the libs are done, and the server is well on the way. Josh Triplett and I seem to be doing packaging in parallel, largely because I've been very, very slack on getting my packages to him. Comments? I'm more than happy to start the importing and such if I get svn access, but I'd like to hear what other people think. As always, you know my email address if you need to ask questions, but at this stage, the effort is utterly uninteresting to me, due to the fact I'm not allowed to get involved in any meaningful way. I'll keep on playing in my own little world. signature.asc Description: Digital signature
Re: X.org Packaging Roadmap
daniel == Daniel Stone [EMAIL PROTECTED] writes: daniel Another interesting question is what to do with version daniel numbers, since 6.8.2-1 will suddenly become ambiguous. Well, one possible solution could be use 6.8.2.debian-1 as version. 3) Make sure they build on x86, ppc, and whatever else we have lying around collectively. Also make sure they install properly. daniel Ubuntu is actually a step ahead of Debian here in that we daniel do source-only uploads, so every arch gets autobuilt: it's daniel fine on amd64, i386, powerpc, sparc, and ia64. hppa daniel should also be alright. Yes. This is a good thing and this also solve some mistakes (I did it in last week) of using a not clean machine for building. Now, I haven't been following the xorg modularization list (I did subscribe finally though) so I don't know the progress on that. I think it'll be a good idea to begin packaging it once things begin to take shape. Since a lot of the work has already been done by Daniel for his debrix tree, we should be able to figure out the basics of what we'll need to do. I think that we should start a branch for the modular tree once the tree itself begins to take enough of a shape that we can work on it. We can worry about transitioning to it once we actually can see what's going on. If we release etch with packages derived from the monolithic tree, so be it. daniel I've been working upstream on the modular tree on my week daniel off, and the libs are done, and the server is well on the daniel way. How far we currently are from modular tree? If it's not so far, could be better we help and improve it's speed and then use it directly inside of Debian. What you think? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org Packaging Roadmap
On Sun, Apr 24, 2005 at 11:46:49PM -0300, Otavio Salvador wrote: daniel == Daniel Stone [EMAIL PROTECTED] writes: daniel Another interesting question is what to do with version daniel numbers, since 6.8.2-1 will suddenly become ambiguous. Well, one possible solution could be use 6.8.2.debian-1 as version. This works well for me. daniel I've been working upstream on the modular tree on my week daniel off, and the libs are done, and the server is well on the daniel way. How far we currently are from modular tree? If it's not so far, could be better we help and improve it's speed and then use it directly inside of Debian. What you think? X11R7 will release on August 19th; the protocol headers and libraries are basically done today. The architecture for the server is fine, and I've been tweaking things until they work, but it will need a reasonable amount of porting love, in terms of instructing the code about the host system, as the server needs very intimate knowledge of the system. Most of the apps aren't autotooled (which is probably indicative of the fact that no-one actually cares), but they're utterly trivial to do. signature.asc Description: Digital signature
Re: x.org xserver endemic issue on hardware change
On Thu, Feb 10, 2005 at 01:52:25AM +0100, Bluefuture wrote: i want to talk to you about a problem in x.org/xserver. When a newbie user change the video card or some other sensible component - like monitor - caused by a component crash or simply by an hardware upgrade Xfree and X.org in debian an ubuntu will not start again on the first boot with the new hardware (specially if the user change the videocard with another one that need a different driver). For an expert user is simple to solve, but for a newbie: 1st he had a crashed system 2nd The rescue process isn't good for a newbie: login to the console, sudo with dpkg-reconfigure --priority=high xserver-xfree86 IMHO isn't a good solution. How we can approach to solve this problem? Cache the output of either lspci -n | grep 'Class (280|300)' or discover; if a) X fails to start, and b) the configuration has changed, have ?dm throw up a Debconf prompt saying 'I think your hardware has changed, should I have a shot at reconfiguring?'. signature.asc Description: Digital signature
Re: x.org packages needed (how may I help?)
On Fri, Nov 12, 2004 at 01:51:47PM +, ROBERTOJIMENOCA wrote: I need xorg packages for Debian to continue development of xorg integration in Debian. I can't continue development of xfree86 integration in Debian because I don't know if the problem in already fixed in xorg and I don't want to start even to look at code that is probably different in xorg. How may I help? I haven't had time to look at X.Org for a couple of weeks -- and nobody else has been committing anything (Fabio's new responsibilities at Ubuntu have pulled him away from it), but here's the situation: Fabio designed a highly modularized packaging of XOrg. You can look at his preliminary efforts in the xorg repository of the X Strike Force[1]. Unfortunately, the amount of labor it would take to finish that process was, as I understand it, not something Ubuntu was willing to underwrite, and it was more than Fabio (or I) had spare time to accomplish. Therefore, what we're looking at is shifting over to a monolithic xorg source package, much like the monolithic xfree86 source package we have right now. This doesn't rule out finishing up the modularized packaging and transitioning to it later, but we don't to wait for that work to be done to put XOrg packages in Debian. Fabio told me that there was actually very little that had to be changed in the xfree86 Debian packaging to support this. Of course, he's speaking from the perspective of someone who's familiar with the Debian packages of xfree86 -- I imagine very little looks much larger to a person who hasn't ever used dpkg-buildpackage before. :) Towards this end, Fabio has created an ubunutu branch in the xfree86 repository of the X Strike Force[2]. What we need to do is review how that branch differs from the mainline, and decide what to do about the differences. There are some things that probably won't be suitable for Debian as-is, like the new X server configuration stuff (see the long argument between Sven Luther and Daniel Stone on this subject[3]). Fabio informed me, though, that really not much needed to change. So, with luck, preparation of XOrg packages for Debian will be pretty straightforward -- once the foundations are laid. If you (or anyone else reading this) would like to assist with laying those foundations by reviewing the differences between the ubuntu branch and the trunk[4], that would be greatly appreciated. In any case, I'm pretty sure I'd like to see the first uploads of XOrg targeted at experimental, not unstable, even if sarge is released by then. [1] svn://necrotic.deadbeast.net/xorg/ [2] svn://necrotic.deadbeast.net/xfree86/branches/ubuntu/ [3] http://bugs.debian.org/243575 [4] E.g., with: svn diff svn://necrotic.deadbeast.net/xfree86/trunk \ svn://necrotic.deadbeast.net/xfree86/branches/ubuntu/ -- G. Branden Robinson| If you have the slightest bit of Debian GNU/Linux | intellectual integrity you cannot [EMAIL PROTECTED] | support the government. http://people.debian.org/~branden/ | -- anonymous signature.asc Description: Digital signature
Re: x.org packages roadmap ?
On Wed, Oct 13, 2004 at 01:00:26AM +0200, Roland Mainz wrote: Uhm... correction: Xprint is part of the Xorg release, starting with X11R6.8.0 both trees are identical (before that Xprint was already part of X11 (since X11R6.4) but the plain X.org version was pretty much unuseable since the single vendors worked on their own implementations without contributing patches back). Xprint is no longer externally maintained. Just the documentation and mailinglist is still hosted at mozdev.org since too many links point to that site and we didn't had time to fight with Wiki (which seems to be mandatory for the freedesktop.org site... ;-/) ... Ah. Fixed in revision 1955. Thanks! -- G. Branden Robinson| The more ridiculous a belief Debian GNU/Linux | system, the higher the probability [EMAIL PROTECTED] | of its success. http://people.debian.org/~branden/ | -- Wayne R. Bartz signature.asc Description: Digital signature
Re: x.org packages roadmap ?
On Sun, Sep 12, 2004 at 12:10:10AM +, ROBERTOJIMENOCA wrote: I saw this post on slashdot.org: http://developers.slashdot.org/comments.pl?sid=121015cid=10187780 This isn't funny. Do you have any roadmap to have x.org Debian packages? How may I help? You may be interested in the latest addition to the Debian X FAQ. What are Debian's plans with respect to X.Org and XFree86? Thanks to Fabio Massimo Di Nitto for contributing much of this entry. Because the XFree86 relicensing came at a time when Debian was trying to stabilize its XFree86 packages for the sarge release, there was some question among Debian's X Window System package maintenance team (the X Strike Force) — and much speculation among Debian's users — as to what direction Debian would take. There was never a serious proposal to attempt to ship anything other than XFree86 4.3.0 in sarge, so work on that continued while discussion on the debian-x mailing list took place. The following represents the consensus reached by the X Strike Force, without objection from the mailing list subscribers (among whom number many interested Debian developers and users). In June 2004, Fabio Massimo Di Nitto, the XFree86 package release manager for Debian sarge and sid, started a thread to discuss the future of X Window System packages in Debian for an open discussion between users and the Debian package maintainers. The discussion spanned nearly one hundred messages from over a dozen participants, practically all of it constructive and very useful to the Debian maintenance team. The outcome of the thread was farly clear to everyone: Debian will move away from the XFree86 tree as soon as possible after the upcoming stable release due to its license issues (see above). The XFree86 package maintainers are committed to providing support and assistance to the Debian Security Team for the XFree86 4.3.0-based packages than Debian will ship in sarge. That is, our abandonment of the XFree86 Project, Inc., as an upstream source of code does not mean that we will abandon our committment to the user of our production release. Futhermore, there was near-consensus that Debian should switch to the X.Org source tree, with the goal of migrating to the modularized tree over time. We expect that the monolithic X.Org distribution will be modularized in a piecewise fashion; as that happens, we will switch off the building of packages from the X.Org monolithic tree in favor of the modularized components that become available from freedesktop.org. While moving from XFree86's monolithic tree to X.Org's is a relatively simple technical transition of itself, the transition to a fully-modularized set of packages will take longer — indeed, an unknown amount of time which depends on the speed of upstream's progress — but we expect the process will bring the packages' quality to a higher level, thanks to the introduction of a fast release cycle for each single component. We expect to modularize two parts of the X.Org distribution immediately: XTerm and Xprt (the XPRINT server). Both of these are independently maintained by entities external to (but working in cooperation with) freedesktop.org. With these changes, it will also be easier for the Debian user community to have a broader choice in X servers. At present, the Debian XFree86 package maintainers intend to support only the XOrg X server (which is based on XFree86's). The X Strike Force does not plan to discourage other people from packaging others. Debian developers that file intent-to-package notices (ITPs) for other X servers are asked to strictly cooperate with the X Strike Force to maintain similar packaging standards, simplify the bug handling on shared components (like X libraries) and discuss future changes and improvements. As of this writing (October 2004), packaging of the X.Org distribution is underway in the X Strike Force's xorg Subversion repository (ViewCVS). -- G. Branden Robinson| Notions like Marxism and Debian GNU/Linux | Freudianism belong to the history [EMAIL PROTECTED] | of organized religion. http://people.debian.org/~branden/ | -- Noam Chomsky signature.asc Description: Digital signature
Re: x.org packages roadmap ?
Branden Robinson wrote: On Sun, Sep 12, 2004 at 12:10:10AM +, ROBERTOJIMENOCA wrote: I saw this post on slashdot.org: http://developers.slashdot.org/comments.pl?sid=121015cid=10187780 This isn't funny. Do you have any roadmap to have x.org Debian packages? How may I help? You may be interested in the latest addition to the Debian X FAQ. What are Debian's plans with respect to X.Org and XFree86? Thanks to Fabio Massimo Di Nitto for contributing much of this entry. [snip] While moving from XFree86's monolithic tree to X.Org's is a relatively simple technical transition of itself, the transition to a fully-modularized set of packages will take longer â?? indeed, an unknown amount of time which depends on the speed of upstream's progress â?? but we expect the process will bring the packages' quality to a higher level, thanks to the introduction of a fast release cycle for each single component. We expect to modularize two parts of the X.Org distribution immediately: XTerm and Xprt (the XPRINT server). Both of these are independently maintained by entities external to (but working in cooperation with) freedesktop.org. Uhm... correction: Xprint is part of the Xorg release, starting with X11R6.8.0 both trees are identical (before that Xprint was already part of X11 (since X11R6.4) but the plain X.org version was pretty much unuseable since the single vendors worked on their own implementations without contributing patches back). Xprint is no longer externally maintained. Just the documentation and mailinglist is still hosted at mozdev.org since too many links point to that site and we didn't had time to fight with Wiki (which seems to be mandatory for the freedesktop.org site... ;-/) ... Bye, Roland P.S.: Please keep the Xprint mailinglist [EMAIL PROTECTED] in the CC: that other people get the emails, too - not everyone is subscribed to the debian-x lists... -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
Re: x.org packages roadmap ?
On Sun, 12 Sep 2004, ROBERTOJIMENOCA wrote: I saw this post on slashdot.org: http://developers.slashdot.org/comments.pl?sid=121015cid=10187780 This isn't funny. Who wrote these comments didn't bother to read any of the mail on debian-x and just did some assumptions. Do you have any roadmap to have x.org Debian packages? sarge+1 and they will hit sid when they are ready. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: X.org
On Mon, May 31, 2004 at 10:27:52PM -0700, William Ballard wrote: Is Debian going to switch to X.org? This Slashdot article says Slackware is: http://slashdot.org/article.pl?sid=04/05/31/2317246mode=nestedtid=104tid=106tid=185tid=189 Ananamous Coward writes Some big distros had already dumped XFree86 for X.org for license reasons, but now Slackware, one of the most classical and stable ones, has announced in its changelog for slackware-current that they are switching to X.org, mostly for compatibility reasons. Looks like X.org is now the future of X for Linux ... If this has been discussed here, I totally missed it. Daniel Stone has made several pronouncements to this list on the subject[1][2][3][4][5]. Whether his statements should be taken as binding upon all Debian Developers, or reflective of the consensus of this mailing list, are questions I must leave to the reader to resolve. [1] Message-ID: [EMAIL PROTECTED] http://lists.debian.org/debian-x/2004/04/msg00298.html [2] Message-ID: [EMAIL PROTECTED] http://lists.debian.org/debian-x/2004/04/msg00440.html [3] Message-ID: [EMAIL PROTECTED] http://lists.debian.org/debian-x/2004/04/msg00488.html [4] Message-ID: [EMAIL PROTECTED] http://lists.debian.org/debian-x/2004/05/msg00366.html [5] Message-ID: [EMAIL PROTECTED] http://lists.debian.org/debian-x/2004/05/msg00431.html -- G. Branden Robinson|Somebody once asked me if I thought Debian GNU/Linux |sex was dirty. I said, It is if [EMAIL PROTECTED] |you're doing it right. http://people.debian.org/~branden/ |-- Woody Allen signature.asc Description: Digital signature
Re: X.Org
On Thu, Mar 25, 2004 at 06:51:03PM +0300, Dan Korostelev wrote: Is there any plans to replace XFree86 with XOrg (http://freedesktop.org/Software/xorg), which is actually a fork of XFree 4.4 with free licence. Sorry for my english. Bye. No, but there are plans to replace it with freedesktop.org's modular xlibs/xserver/xapps trees, to make it far easier to maintain. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
