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 comp

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

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

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 whic

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 numb

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
         i

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

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