Re: X bi-monthly snapshot packages.
On Mon, Apr 14, 2003 at 01:54:54AM +1000, Daniel Stone wrote:
> On Sun, Apr 13, 2003 at 05:01:38PM +0200, Sven Luther wrote:
> > I have been toying with the idea of producing official debian packages
> > from the bi-monthly X developpment snapshots which were recently
> > announced. This would be my way to stop complaining, and actually do
> > something about the X situation in debian, so i hope it gets the
> > approval of everyone.
>
> *shrug*, if it's actually productive, sure. It'll only come off if you
> maintain it well - just building it automatically and hoping for the
> best *will* *not* *work*.
Well, i will first try to do this, i cannot say at first that i will be
able to do it, and anyway, the reason for these snapshot packages would
not be so much to provide debian packages of X more recent than yours or
brandens, but to make sure that the upstream X is as near as possible to
debian's need with regard to multiple arches and such. In this way, even
just building them, would be a big help, as we, i more exactly, can then
investigate the breakage as soon as it happens, and not month after the
new upstream release.
> > Now, these packages, being cvs snapshots, would not be of production
> > quality and would in no way replace either Branden's package or Daniel's
> > unofficial packages. They would help to have a new upstream release who
> > is nearer the quality of the debian package, and help the X strike force
> > to produce packages more quickly after a new X release.
>
> Well, only if they're good quality. If you're going to help the XSF, you
> need to track upstream by reading every line of diff, staying active on
> the lists and watching for new patches and reports of breakage, and
Err, this is mainly the debian-x list, or do you mean all the -ports
lists ? That would maybe not really be all that productive if i have to
read 12 or so rather high volume list, which will only be X relevant a
small portion of the time.
> getting your own hands dirty, checking that it actually works on all
> architectures, not just builds, and not letting things slide (e.g.
That i can difficulty do, i can have access to i386, powerpc soon, m68k
with a bit of work, and sparc until september. Possibly mips also, but
it is not at all sure, and anyway, the mips box doesn't has the disk
space to build X on.
But i hope that there will be at least some users of the packages that
will provide feedback if it breaks, or at least that some porters will
try it from time to time. Or do you test your packages on all arches
before you release a new version ?
> updating the MANIFEST for a new file, but not the .install).
Yes, still need to check those.
> It's really a full-time job, although maintaining the .99.x snapshots
> was easier, because I didn't have to deal with the patch hell I have
> now, with 4.3.0.
My idea is to try to integrate the debian's patch as much as possible
with the upstream ones, to work from the last good debian version by
applying all upstream patches, instead of the other way around. As said,
i really don't think these would be as high quality packages as
Branden's package, at least at first, nor is that my aim.
> > Now, i would love to get the opinion of both Daniel and Branden on this,
> > as well as the opinion of the X porters. I understand there is problems
> > with the fact of releasing X packages out of CVS snapshots, and that the
> > user will have to be told (if they read it and such) that they cannot
> > expect from these package the same high quality as from the official
> > packages. I hope this will not cause too much problems or such, and that
> > our users can make the difference between an normal package and a
> > -snapshot package.
>
> Well, you're really very much on your own. I personally won't put my
> name to something I'm not involved in, let alone something I don't even
> use, and Branden probably feels the same way.
Err, i was more thinking about recomendations on what not to do based on
your experience and such.
> If they're good quality, then by all means, go for it. It'll help out
> the X team a lot. If they're not, then it's really just there for users
> who either have quite new video cards, or are easily distracted by shiny
> stuff[0].
No, the main aim is to help the debian package be more near the upstream
ones so that when upstream has a new release, you and/or branden have
less work to do to adopt it, cannot complain about it breaking all
arches, and so on.
> If your package is of good enough quality, it'll get integrated in. It's
> really that simple.
I don't understand what you mean by integrated in.
> > I would also like this to be an official package, not like Daniel's
> > 4.3.0 package, so that it gets build on each supported arch, so that
> > problems and breakages can easily and quickly get folded back upstream.
>
> There are only two ways you can get it built on every supported
> architecture:
> * Upload it to Debian.
That was what i was thinking. Altough some may object to having a second
such huge source package around.
> * Have one machine of every architecture, or be friends with someone who
> does.
Highly unprobable and maybe not time efficient, as it would demand of
these friends to do the builds by hand. Altough i guess some
autobuilders trigger X builds by hand anyway.
I was also hoping to achieve some early testing by using cross
compilers, but i would need a new disk and more time to test it. I don't
know if X's debian/rules is cross-compiler friendly yet.
> It doesn't happen any other way, unfortunately - I'm pretty sure regular
> developers can't inject stuff into sbuilds. I personally spend a fair
> bit of time running around on IRC and in private email talking to all
> the porters, trying to get things built, rebuilt, patches tested,
> getting failure reports, et al.
Yes, ...
But BTW, i think that, as you said, many of the problems encountered
will be common to all three packages, yours, mine and brandens, and so
should the fixes be also, i think.
> > So, is this a good idea, or do people here have objections to it.
>
> Well, you're welcome to create them - I'd certainly be out of line to
> attempt to prevent you doing so. I'd be interested to see how they
> progressed as it went along, patches gradually became more difficult to
> maintain (commenting out checksource_command is *not* the right
> solution), etc. The key issue here is how much work you intend to put
> in, as it's really not a part-time job.
I will do that as part of my free time, so it will be a part-time job
whatever happens, but i think it is not as difficult as you may think,
since contrary to your and branden's package, my aim is to lower the
quantity of needed patches by applying as much of them as i can
upstream.
> As I said above, if the packages rock, then that's great, and it'll help
> the X team out a lot. If their quality isn't so good, then it'll only
Well, it will mostly help the X team out a lot next time only.
> hinder the X team, because it means they'll have to deal with a lot more
> questions from users, cut because they can't cleanly upgrade, or they
> don't have a working X, or whatever.
Well, i don't know, i was goign to preface the discution by a 'highly
unstable, use at your own risk, never bother branden about them, send
all bug reports to me' kind of thing. Not that everyone would read them.
That said, it would be clear from the /var/log/XFree86.0.log which
version is run, and bugreports because /var/log/XFree86.0.log are
not handled anyway.
> Expecting the XSF to lend support is probably going a bit far - my
> packages aren't official XSF packages, despite the amount of work I put
> in (debian/patches is extensively maintained, and I do regular back-syncs
> with 4.2.1). The only ones that are, are Branden's, and the only time
> that's going to change is when someone with the skills, time, and
> Developership steps up to the co-maintainer plate.
I don't intent them to be anything other than higly unstable cvs
snapshots. Upstream has claimed that maybe they won't even build at
time, and they also told me that they don't guarantee module
compatibility between snapshots, so it will never replace the official
packages, and not even yours. The only aim of them is to make your and
the XSF job easier when there is a new upstream release, since many of
the things they needed to patch, check, whatever would be already
integrated upstream.
> [0]: The most-commented on feature of XFree86 4.3 is the cursor stuff.
Well, it is broken, and upstream ships it disabled by default.
BTW, can you apply this patch please to your next version of packages,
it fixes a server crash in case you are using shadowfb and SW ARGB
cursors adn bring the cursor to the bottom of the screen. You can name
it as stolen from head, as it will be commited soon. You have to apply
it in xc/programs/Xserver/hw/xfree86/shadowfb.
Friendly,
Sven Luther
--- shadow.c.orig 2003-04-11 18:48:56.000000000 +0200
+++ shadow.c 2003-04-13 17:17:11.000000000 +0200
@@ -461,26 +461,45 @@
ShadowScreenPtr pPriv = GET_SCREEN_PRIVATE(pScreen);
PictureScreenPtr ps = GetPictureScreen(pScreen);
BoxRec box;
+ BoxPtr extents;
Bool boxNotEmpty = FALSE;
- box.x1 = pDst->pDrawable->x + xDst;
- box.y1 = pDst->pDrawable->y + yDst;
- box.x2 = box.x1 + width;
- box.y2 = box.y1 + height;
-
if (pPriv->vtSema
- && pDst->pDrawable->type == DRAWABLE_WINDOW && BOX_NOT_EMPTY(box)) {
- if (pPriv->preRefresh)
- (*pPriv->preRefresh)(pPriv->pScrn, 1, &box);
- boxNotEmpty = TRUE;
+ && pDst->pDrawable->type == DRAWABLE_WINDOW) {
+
+ box.x1 = xDst;
+ box.y1 = yDst;
+ box.x2 = xDst + width;
+ box.y2 = yDst + height;
+
+ TRANSLATE_BOX(box, pDst->pDrawable);
+
+ if (BOX_NOT_EMPTY(box)) {
+ if (pPriv->preRefresh) {
+ extents = &((WindowPtr)(pDst->pDrawable))->clipList.extents;
+ if(box.x1 < extents->x1) box.x1 = extents->x1;
+ if(box.x2 > extents->x2) box.x2 = extents->x2;
+ if(box.y1 < extents->y1) box.y1 = extents->y1;
+ if(box.y2 > extents->y2) box.y2 = extents->y2;
+
+ (*pPriv->preRefresh)(pPriv->pScrn, 1, &box);
+ }
+ boxNotEmpty = TRUE;
+ }
}
-
+
ps->Composite = pPriv->Composite;
(*ps->Composite)(op, pSrc, pMask, pDst, xSrc, ySrc,
xMask, yMask, xDst, yDst, width, height);
ps->Composite = ShadowComposite;
if (pPriv->postRefresh && boxNotEmpty) {
+ extents = &pDst->pCompositeClip->extents;
+ if(box.x1 < extents->x1) box.x1 = extents->x1;
+ if(box.x2 > extents->x2) box.x2 = extents->x2;
+ if(box.y1 < extents->y1) box.y1 = extents->y1;
+ if(box.y2 > extents->y2) box.y2 = extents->y2;
+
(*pPriv->postRefresh)(pPriv->pScrn, 1, &box);
}
}
Reply to: