gmane.linux.ubuntu.devel.x

Re: Fighting renames, day 1

Bryce Harrington — 2012-05-25T07:52:31

For debian/control please use the dpkg-control script included in
xorg-pkg-tools, and if it's not working properly patch it up, or let me
know what the issues are and I'll fix it up.  (I'm off Friday and Monday
but can take a look next week.)  I'd like to ensure this works as a
general purpose tool that we're maintaining and can share with other
teams (i.e. Audio).

For the rules file, use whatever works.  I've a feeling we might end up
having to do a lot of manual tweaking here.

Bryce

Re: Hybrid graphics target of opportunity during the 3.5 merge window

Timo Aaltonen — 2012-05-25T07:25:21

That would be bad, imo.


Don't see why such a patch couldn't be added to the distro kernel once
it's in a newer mainline (pre)release, so no rush to get it in 3.5.

Re: Fighting renames, day 1

Timo Aaltonen — 2012-05-25T07:21:18

Probably best to drop some of the metapackages from the renamed source,
like x11-common, xorg-dev, xbase-clients, xutils. You need the important
metapackages though; xorg, xserver-xorg, xserver-xorg-{input,video}-all
in order to be able to actually install the renamed packages without
pulling them in one by one.

Re: Hybrid graphics target of opportunity during the 3.5 merge window

Eric Appleman — 2012-05-24T16:47:19

Would it be in bad taste to send a patch ourselves and just see what
happens? I wouldn't want to make any bets that Quantal will ship with 3.6.

The patch is trivial enough and Rob Clark has already said he could give
rapid approval.

- Eric

Fighting renames, day 1

Maarten Lankhorst — 2012-05-24T15:09:18

Hey,

So today I've been trying to get the lts rename scripts to do something
useful and trying to build the results from it, to see if something sane
comes out.

So far I found out this:

The xorg package (x11-common, xserver-xorg, xserver-xorg-video-all, xorg, xorg-dev, xbase-clients, xutils) should if possible be killed, or be altered to not provide x11-common. Userspace libraries can depend on a specific version. I'm leaning towards killing the entire package, since the less packages altered, the easier we can support it. libxres1 will remove x11-common-renamed because it depends on x11-common (>= ...), and it was required on my way to building xserver-xorg-core, oops.

There were a few other things, mostly related to debian/rules and debian/control. I'm trying to use sed for now to automate changes that need to be done. This might break on package updates, but it's easier since we're limited to a few specific files only, so it can be verified.

libdrm is a pain point, plymouth and weston (a wayland compositor universe, so probably not high priority) depend on it, so renaming is a bit harder.

So far my findings have been positive, I haven't encountered evidence yet that it will be impossible to go the renaming route, but I think it is important to limit ourselves to renaming as few packages with other potential users as possible.

~Maarten

Re: Hybrid graphics target of opportunity during the 3.5 merge window

Andy Whitcroft — 2012-05-24T11:28:07


The merge window for 3.5 is already open, indeed nearly closed.  If it
is not in -next already it will not be in v3.5, it needs to be in -next
very very soon to hit 3.6.

-apw

Hybrid graphics target of opportunity during the 3.5merge window

Eric Appleman — 2012-05-24T09:21:38

Regarding the following spec work item:

[albertomilone] contact nvidia to see if they're in sync with airlied's
plans/patches, and revisit the patch to expand the use of dma buffers in
the kernel: TODO

The timeline for this one is coming up. Robert Morell's original
patch[1] for the 3.3 kernel was never resubmitted for the 3.4 cycle. It
might be a good idea to contact him or Pierre-Loup Griffais and ask to
resubmit the patch to the LKML and dma-buf-next[2] for the 3.5 cycle.

If we can get this in 3.5 and Dave Airlie can get the rest of his new X
API into 1.13 and stable DDX, Quantal will have a complete PRIME/DrvScrn
environment.

- Eric Appleman

[1] https://lkml.org/lkml/2012/1/17/479

[2]
http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-dma-buf.git;a=shortlog;h=refs/heads/for-next

Re: Testing enablement mechanics (or are there better solutions?)

Christopher James Halse Rogers — 2012-05-18T08:14:01

The advantage is that we can have multiple stacks in the archive at once
- Q, R, S, and T. The plan was to support each of those stacks in 12.04
for as long as the release they're based on is supported.


Those should be safe, but they will indeed need review.


That sounds like virtualbox-guest-x11 should also be renamed.  After
all, it is a DDX; it'll need to be backported/rebuilt against the new
stack.


Stupid packages ☺. Are any of these dependencies versioned? Can they be
satisfied by the renamed packages Provide: ing their un-renamed package?

Alternatively, if it's a small set of packages we could SRU them to
remove the dependency.


As long as users need to *deliberately* install the un-renamed package I
think this is ok. We have a limited ability to prevent people from
shooting themselves in their feet.

This was, however, the sort of thing that I was concerned about in the
session.


We should be able to handle that when the lts-q stack drops out of
support by uploading a new lts-q metapackage that depends on lts-t (or
whatever we decided the upgrade path was). Obviously this needs testing,
though!

Testing enablement mechanics (or are there bettersolutions?)

Maarten Lankhorst — 2012-05-16T12:25:13

Hey,

Doing some more testing I haven't found a good way to do this yet. I tried doing things similar to the way the xorg rename script is going to work, and I just can't get a good way of automatically forcing a upgrade. The official way of upgrading to a renamed package is to provide a 'transitional' package that's empty and just depends on the new name, and it would the only way to make this work without breaking everything. However in this case I don't see an advantage to just using exactly the same names.

For example there are some non-trivial depends on x11proto packages:
$ apt-cache rdepends x11proto.*
The most important one being x11proto-core-dev. However in the generic case it will stay backwards compatible, so they will all have to be reviewed to make sure existing code won't break.

Some more digging even finds a versioned depends on xserver-xorg-core, so renaming won't work. virtualbox-guest-x11 depends on Xorg >= 7.

Similarly, some input and video drivers have dependencies:
gpointing-device-settings depends on input-synaptics, open-vm-toolbox on vmmouse, xserver-xorg-input-wacom has ubuntustudio-graphics and kde-config-tablet, bunch of others too.

More fun is that if you try to install the unrenamed package, your package manager will solve the conflict by removing the enablement package and downgrade to it. This seems like a recipe for disaster and not really suitable as a working solution. Also the enablement package won't automatically upgrade to newer versions, so you will stay on lts-q for the rest of the release unless you manually force an upgrade.

ppa would be fine for testing, but I don't think it's set up to have millions of computers pull updates from it, and companies want to have their own mirroring set up to save unnecessary bandwidth. Would it really be impossible to poke the launchpad devs some more for this, since it seems to be the only clean solution to have either only the stable stack in main and an updated stack in backports (which can be held back on a large scale with pinning as needed) or the use of multiple pockets.

I don't believe we should go with the rename route at this point, until we figure out a way to do it cleanly and automatically.

I created 2 test repos, enable the normal one and the lts-q one for testing, lts-r is unused atm:
https://launchpad.net/~mlankhorst

You can force installing dummy-enablement to the original version, and simulate what would happen if you upgrade to the current version, and see it's going to be held back. Furthermore dummy-dev will fail to install after upgrading and won't suggest dummy-dev-lts-q or anything.

~Maarten

Re: LTS Xorg backports package set

Maarten Lankhorst — 2012-05-16T07:27:31

Hey,

Op 16-05-12 02:41, Christopher James Halse Rogers schreef:
Could the x11proto packages be audited to see if they really do need to be renamed? They usually stay backwards compatible.

In the set of could probably also die and or probably not needing to be updated:
xauth
xfonts-base
xfonts-utils
xutils-dev
xkb-data
xkb-data-udeb

Which probably leaves core X, some x11 specific server packages and all the input/video drivers.

~Maarten

Re: LTS Xorg backports package set

Bryce Harrington — 2012-05-16T06:44:57

Seems reasonable.  It would probably be smart for Maarten to carry a
task each cycle to do a quick checkup that these assumptions hold.



Can the precise xephyr, et al packages be installed alongside the
quantal, etc. backported xserver?  If so then I think that'll work
fine.

Probably couldn't hurt to have some simple smoke tests to verify each
still installs and works with the newer server installed.


libx11-dev would be nice to avoid backporting; there's a bunch of stuff
in the archive that uses it.  The others seem less popular; mainly other
X bits.


Bryce

LTS Xorg backports package set

Christopher James Halse Rogers — 2012-05-16T00:41:26

Hi all!

One of the things which still needs to be decided is the full set of
packages that we'll need to backport in order to take the 12.10 X stack
to 12.04.

Bryce has a prototype backport script in xorg-pkg-tools¹ which gets a
list of package mappings from a lookup table². I think this list is
currently a bit pessimistic, and could be trimmed, but I'd like everyone
to have a look at my reasoning.

Things which are unrelated 3rd party dependencies I think could go:

libdbus-1-dev
libgcrypt-dev
libselinux1-dev
        * Stable upstream. I don't think the X stack is likely to start
        depending on new features
libhal-dev
        * Unmaintained upstream, in Universe.  There won't *be* new
        features for the X stack to depend on.
libudev-dev
        * Not as stable upstream, but I don't think the X stack is
        likely to start requiring new features here. It is closely tied
        to the kernel, though, so the kernel backport might require a
        new udev anyway.


Protocol libraries which I don't think the xfree86 server uses, but are
used by the other weird servers - xdmx, xephyr, etc:

libdmx-dev
libxext-dev
libxfixes-dev
libxi-dev
libxinerama-dev
libxmu-dev
libxmuu-dev
libxpm-dev
libxrender-dev
libxres-dev
libxt-dev
libxtst-dev
libxv-dev
        * Some of these may end up being required for xorg-gtest
        integration tests; those tests are likely to be testing new
        protocol, and hence require the new libs.  We can just turn
        those tests off, though.

Libraries used by the main xfree86 DDX build, but without a versioned
dependency.  I think these also do not need to be backported, as long as
we can add extra packages to the backports set if they end up being
required.

libx11-dev
libxau-dev
libxaw7-dev
libxdmcp-dev
libxfont-dev
libxkbfile-dev


¹: https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/
²:
http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/lts-pkg-mapping.txt

System compositor - start X before login

2012-05-13T12:57:38

Thinking about what the boot process would look like with a wayland system
compositor, it occurred to me X could be started, as the last logged in
user, before the user logs in.  As soon as lighDM finishes loading and
fires the signal to fade from boot splash to lightDM.  Once a user logs in,
if it's the same user, just fade to X once it's loaded.  If a different
user logs in, kill off X, start it with the right user, and fade in when
loaded.

A little more involved, you could kill / restart X as soon as the username
is entered.

If you kill X gracefully, and wait for it to shut down before restarting
it, that could lengthen the effective boot process a significant portion of
the time in cases where different users are often logging in.  Although you
could automatically detect that case on that system and store a flag on the
filesystem to skip this.

Alternately, you could spawn the new instance of X with the correct user
before waiting for X to shut down gracefully, but then you get a different
display number, which I'm sure would annoy some percentage of users.  

Or you could just kill -9 everything.  Might not be horrible.

And I'm sure there are cases where people have browsers automatically
launching which, as a result of automatically launching and killing X
periodically, would result in their browser starting up complaining about
having been shutdown uncleanly no matter which above method was used.
Which somebody might care about.  

But I think it could take a nice chunk out of effective boot time, and
generally be fun.

Re: xorg-server 1.12 on X Updates PPA

Bryce Harrington — 2012-05-13T02:00:22

The main point is to have the individual point releases each in its own
PPA.  This facilitates users needing to do bisection testing to isolate
fixes that we might want to include in the LTS.

Whether the PPAs live under edgers or x-swat is immaterial to me.  We
could do it either way.

Bryce

Re: xorg-server 1.12 on X Updates PPA

Tormod Volden — 2012-05-12T16:14:37

Wouldn't it make more sense to add these point releases to x-updates
(like Pedro also suggested) or some other PPA under x-swat rather than
xorg-edgers? Stable point release are not really edgy, experimental
stuff...

The x-updates PPA is for stable upstream releases. Can't fit the bill
better. Otherwise there is also the (currently disabled) x-backports
PPA although it is unclear to me what would go there instead of to
x-updates. Simple backports of Ubuntu N packages into Ubuntu N-1
maybe?

Tormod

Re: xorg-server 1.12 on X Updates PPA

Bryce Harrington — 2012-05-10T21:58:50

Actually at UDS we discussed holding off on pulling it in for a month or
so, and keep development focused on the 1.11 stack we shipped in
precise.  Then anything we fix will be an easy sru candidate for lts.

We're likely to be shipping 1.13, so stabilization of 1.12 is of
interest for helping upstream but no one voiced requirements at uds for
it, so there doesn't seem to be an urgency for it.  However, having it
in PPAs would be beneficial for users anxious to try it, and also for
facilitating bisection testing.

We do have a couple experiments we want to do in the near term:
Dropping xserver patches, and pulling the new -intel DDX.  If we hold
the xserver constant, this might help us better isolate regressions or
improvements to be gained from those changes.

Bryce

Re: xorg-server 1.12 on X Updates PPA

Tormod Volden — 2012-05-10T21:41:26

1.12 should land in Quantal pretty soon, right? (It is already in
Debian unstable.)
By then it might be fairly possible to pull it in from there without
breaking your 12.04 too much.

Tormod

System compositor

2012-05-10T18:30:45

Is this list the place to discuss this subject?


<Darxus> RAOF: I think you were planning to fork weston to create a
         system compositor.  Why not just add the necessary
         modifications to weston to minimize the work to maintain
         protocol compatibility?
<krh> it should be possible to make a system compositor just another
      shell plugin
<krh> and if we need to add something to make that possible we can do that

He's talking about the type of plugin that currently provides the Weston
UI, shell.c.


<Darxus> One of the things that came up in the uds session was the
         expectation of pressure to do rotating cube transitions, and
         where that should be implemented.  Would that make sense within
         a shell plugin?
<krh> rotating_cube.ko
<krh> then everybody can use it
<Darxus> .ko?
<krh> Darxus: the extension of kernel modules


<Darxus> I think this is probably nuts, but, for the problem of
         proprietary drivers not supporting wayland output... would
         it make sense to run a wayland system compositor on top of X,
         then run X (rooted), login, screensaver, etc., as clients of
         that system compositor?
<Darxus> Oh, I guess that would only work with wlshm output, which
         probably isn't worth doing.
<Darxus> Well, maybe something similar to wlshm could be created to use
         hardware acceleration in X... heh.

wlshm is a hardware independent DDX which does output directly via the
wayland protocol.

Re: xorg-server 1.12 on X Updates PPA

Bryce Harrington — 2012-05-09T22:16:34

It's not super hard but we also all have rather full plates.
PPA updates fall into a second tier urgency so sometimes it takes a
while for us to get to them.  However, they're also things that are
quite easy for community folks to get involved with, so we like to
encourage involvement there.


Yes, essentially what we're thinking is to set up one PPA for each
xserver point release, kind of like what the kernel team does with their
mainline kernel PPA.

So, each point release would need to have the debian packaging added,
and then a PPA created under the xorg-edgers team.  For the 12.0 release
it would probably require also including many of the protolibs and
drivers, but for subsequent point releases if there's no ABI changes
it'd probably just require updating the server.  Robert Hooker is the
expert at this process and can explain how to do it; you can catch him
on irc as sarvatt.  The process is a bit technical but it's documented
and largely scripted, so once you learn it, it should be pretty much
push button and watching for the next point release.

Bryce

Re: xorg-server 1.12 on X Updates PPA

Timo Aaltonen — 2012-05-09T19:35:20

08.05.2012 15:48, Pedro Pedruzzi kirjoitti:

Any particular reason for the update? There has been no discussions
about providing it..


ps. please use the ubuntu-x mailinglist for such questions in the future :)

t

Re: remove nvidia-{96,173}-updates?

Bryce Harrington — 2012-05-01T22:49:58

< at >Alberto, can you share your thoughts here?

It seems to me the -updates packages are not needed for the legacy
drivers.  We update them only when they're already broken.  It would be
several fewer packages for the security team to update.  But perhaps I'm
missing an important detail?

Bryce