xorg-edgers ppa and karmic

tormod · 27 October 2009, 08:32 AM

Originally posted by faibistes View Post

Sorry, it is somewhat related, I'm one of the poor saps that have added the edgers repository and now have a broken 3D. I have edited this bug at freedesktop and they've redirected me to the packager. It's a dependency issue, I guess, and I don't know how to file a bug for xorg-edgers.

Sorry if I look too pushy, it's just that I want to make sure that you are aware of the issue.

No problem, it's just that those who are subscribed to this Karmic thread might not be very interested in your Jaunty problem.

Thanks for filing the bug. The best is to file a bug on launchpad (using "ubuntu-bug xorg"), adding "xorg-edgers" in the title and subscribing the uploader (me).

EDIT: The bug seems to be a code issue, so directly filing at bugs.freedesktop.org was the right thing to do.

faibistes · 27 October 2009, 06:15 AM

Originally posted by tormod View Post

faibistes, I don't see how your issue can have anything to do with this. You should rather file a bug or start your own thread.

Sorry, it is somewhat related, I'm one of the poor saps that have added the edgers repository and now have a broken 3D. I have edited this bug at freedesktop and they've redirected me to the packager. It's a dependency issue, I guess, and I don't know how to file a bug for xorg-edgers.

Sorry if I look too pushy, it's just that I want to make sure that you are aware of the issue.

tormod · 26 October 2009, 08:23 AM

The Karmic package now uses "+" so you get updated to the post-2.9.0 (without UMS) package. For Jaunty I finally gave in and uploaded a 2.9.0 (with UMS) package again, and I will stay at the 2.9 branch for Jaunty.

faibistes, I don't see how your issue can have anything to do with this. You should rather file a bug or start your own thread.

faibistes · 26 October 2009, 07:16 AM

Originally posted by tormod View Post

BTW, recently I discovered a whole bunch of people using the xorg-edgers repo on Jaunty, without knowing what it is - they have picked it up from "helpful" forum postings and they have no idea that it is experimental and have no idea how to revert to an older version. We try not to cater to this false audience and would rather like to teach them a lesson

They sure got into trouble when the post-2.9.0 -intel driver dropped UMS and required KMS...

May it be related to my troubles? My Jaunty system has behaved well untill today. I upgraded the kernel to 2.6.31-5, rebooted, and apps don't seem to detect DRI anymore (starting compiz restarts X, gnome-do can't start in docky mode, extreme tux racer falls back to soft render...) But glxinfo says:

Code:

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group

OTOH, glxgears says:

Code:

GL_RENDERER   = Software Rasterizer
GL_VERSION    = 2.1 Mesa 7.7-devel

isn't it weird? To my knowledge, KMS is enabled.

dentaku65 · 18 October 2009, 06:44 AM

Originally posted by tormod View Post

Hi, thanks for asking about this. It is... somewhat intentional but in this case probably not. The long story is:
...

Thanks Tormod to explain this; since I used Karmic I was always use xorg-edgers for my video card that with the official repos has really poor performance (I do not speak about Jaunty) and only once (since alpha 2) I've used ppa-purge to restore a critical situation; now with the situation described at #1 I still have these warnings in my Xorg.0.log:

Code:

(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
(WW) Warning, couldn't open module i810
(WW) Falling back to old probe method for vesa
(WW) Falling back to old probe method for fbdev
(WW) intel(0): Disabling Xv because no adaptors could be initialized.

Reading the the diff of intel driver on xorg-edgers I've seen that Xv issues are somewhat fixed (or workarouded).
Btw, I'm waiting the change from "~" to "+" of the package :-)

tormod · 16 October 2009, 05:25 PM

Originally posted by dentaku65 View Post

I open the thread in Karmic Ubuntu forum

Ubuntu Forums

http://ubuntuforums.org/showthread.php?t=1288307

A help and support forum for Ubuntu Linux.

about the package name of xserver-xorg-video-intel; seems that the package name of the PPA is lower that the one from official repos, so when I upgraded the system everything is upgraded from PPA except the package of xserver-xorg-video-intel

Code:

apt-cache policy xserver-xorg-video-intel

As you can see:
2.9.0-1ubuntu1 is superior than 2.9.0~git20091010.8b2d2ff0-0ubuntu0tormod

Is this intentional?

Thx

Hi, thanks for asking about this. It is... somewhat intentional but in this case probably not. The long story is:

Ideally we want to fit the xorg-edgers packages to the official versioning so that new packages supersedes older packages whether they come from the PPA or main archive. But it is not so simple.

Some upstream git repos carry the version number of the next release, some of the previous release, and some are not consistent and often vary their behavior. In the first case the "~" separator is useful, when later the version is released, the Debian/Ubuntu version will correctly supersede the earlier development version. In the second case, the "+" separator is useful since it supersedes the plain version.

Also, from time to time karmic (or the current development version) gets a new version, which maybe contain additional patches not carried by upstream or Debian and hence not in xorg-edgers, and we like people to bang on these versions instead of the xorg-edgers version for a while. Then it makes sense to let people "upgrade" from the ~ git version to the plain version.

However, depending on the upstream developement, git master may progress quickly and soon the karmic version is "old". At this point we want to let people test new upstream of course so we change from ~ to +. That should be done for -intel now.

With tools like ppa-purge available which makes it easier to back out a PPA and go back to stock Ubuntu, we have to care less about correct versioning relative to the main archives though, just need to make sure we stay above...

For libraries and stuff not needed to be updated regularly we also try to use as much as possible from the main archive. So if we need to use our own package for a while, we want to be able to upgrade the PPA to an official main version when it ships later. Less xorg-edgers specific packages is good, less maintenance on us and we share bugs and features with main which helps debugging.

Note that all of this is general for all different drivers, in xorg-edgers we have a bunch of them, packaged by the same script and pretty much run automatically, ideally without worrying too much about each package every day. Basically, the manual part is to decide on these version things we talk about here, and on which git branches to follow for each package. Well, and to maintain the packaging "hooks" and tweaks needed because upstream changed something and Debian hasn't caught up yet...

And we try to use just enough time on this to make it work

We try to help upstream and downstream with debugging etc as well. So please bare with us for some glitches in this late-night effort.

BTW, recently I discovered a whole bunch of people using the xorg-edgers repo on Jaunty, without knowing what it is - they have picked it up from "helpful" forum postings and they have no idea that it is experimental and have no idea how to revert to an older version. We try not to cater to this false audience and would rather like to teach them a lesson

They sure got into trouble when the post-2.9.0 -intel driver dropped UMS and required KMS...

xorg-edgers ppa and karmic

Leave a comment:

Leave a comment:

Leave a comment:

Leave a comment:

Leave a comment:

Leave a comment:

xorg-edgers ppa and karmic