Announcement

Collapse
No announcement yet.

xorg-edgers ppa and karmic

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • xorg-edgers ppa and karmic

    I open the thread in Karmic Ubuntu forum

    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
    xserver-xorg-video-intel:
    Installed: 2:2.9.0-1ubuntu1
    Candidate: 2:2.9.0-1ubuntu1
    Version table:
    *** 2:2.9.0-1ubuntu1 0
    500 http://archive.ubuntu.com karmic/main Packages
    100 /var/lib/dpkg/status
    2:2.9.0~git20091010.8b2d2ff0-0ubuntu0tormod 0
    500 http://ppa.launchpad.net karmic/main Packages
    As you can see:
    2.9.0-1ubuntu1 is superior than 2.9.0~git20091010.8b2d2ff0-0ubuntu0tormod

    Is this intentional?

    Thx

  • #2
    Originally posted by dentaku65 View Post
    I open the thread in Karmic Ubuntu forum

    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...

    Comment


    • #3
      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 :-)

      Comment


      • #4
        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.
        Last edited by faibistes; 26 October 2009, 07:27 AM.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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.
              Last edited by tormod; 27 October 2009, 09:42 AM.

              Comment

              Working...
              X