Re: XI2 pull warning
Thomas Jaeger thjae...@gmail.com writes: I've posted a build log (make -j4) here: http://pastebin.com/f3f965926 The more I think about it, the more it becomes clear to me that a recursive call to make can never do the right thing during a parallel build. Tom Of course it can. But if you have cross-module dependencies (and you probably do), then it can be quite painful to get it right (and even worse to maintain it). The canonical reference is of course recursive make considered harmful. eirik Dan Nicholson wrote: On Tue, Jun 2, 2009 at 8:24 AM, Thomas Jaeger thjae...@gmail.com wrote: Peter Hutterer wrote: actually, the reason for this could be a missing dependency in the man pages. If you can reproduce this error, just check the Makefile.am for the dependency setup for the file it fails on. I've tried triggering it but without success. My theory is that it's a race condition, where due to the recursive call of make the same man page is built at the same time by both processes and then the second mv fails. Can you show the error? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there a chance to set an alpha-mask using XOrg?
Am Saturday 06 June 2009 21:03:12 schrieb Leif Bergerhoff: Peter Harris wrote: It depends on your toolkit. If you're not using any particular toolkit, the easiest way is to set _NET_WM_WINDOW_OPACITY on your window. See http://webcvs.freedesktop.org/xapps/transset/transSet.c?view=markup for an example. Make sure a composite manager is running (many desktops run one by default these days). No, I don't want to make use of a toolkit if possible. As I can see I would have to make use of the composite extension. no, you need composite if you want to write your own compositing manager (it's unlikely you really want to do that) If I remember correctly, I read about this extension supporting max. 2 output devices. Right? no This would mean, I'll need another way for setting an image as an alpha-mask, since I want to make use of 6 output devices. to *draw* using transparency, you need either the render extension (but use cairo if you can, as pointed out), or GL (but note that compositing managers and direct rendering do not mix well with DRI1) to *show* a translucent window, you generally need a compositing manager, and either set _NET_WM_WINDOW_OPACITY as suggested (if you want uniform opacity), or otherwise create your window using an ARGB visual and provide appropriate per-pixel alpha while drawing Helge Bahmann -- Dipl. Math. Helge Bahmann Berater Geschäftsbereich Hochsicherheit secunet Security Networks AG Ammonstraße 74 01067 Dresden, Germany Fon: +49 201 54 54-3586 Fax: +49 201 54 54-1323 Email: helge.bahm...@secunet.com Sitz: Kronprinzenstraße 30, 45128 Essen Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart, Thomas Koelzer, Thomas Pleines Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
On Mon, Jun 08, 2009 at 08:14:53PM +0800, Nai Xia wrote: On Wed, May 20, 2009 at 11:38 PM, Wu Fengguangfengguang...@intel.com wrote: Hi list, On Wed, May 20, 2009 at 10:56:07PM +0800, Wu Fengguang wrote: On Wed, May 20, 2009 at 10:47:31PM +0800, Andi Kleen wrote: One scenario that might be useful to test is what happens when some very large processes, all mapped and executable exceed memory and Good idea. Too bad I may have to install some bloated desktop in order to test this out ;) I guess the pgmajfault+pswpin numbers can serve as negative scores in that case? I would just generate a large C program with a script and compile and run that. The program can be very dumb (e.g. only run a gigantic loop), it just needs to be large. Just don't compile it with optimization, that can be quite slow. And use multiple functions, otherwise gcc might exceed your memory. Hehe, an arbitrary C program may not be persuasive..but I do have some bloated binaries at hand :-) -rwsr-sr-x 1 root wfg 36M 2009-04-22 17:21 Xorg lrwxrwxrwx 1 wfg wfg 4 2009-04-22 17:21 X - Xorg -rwxr-xr-x 1 wfg wfg 39M 2009-04-22 17:21 Xvfb -rwxr-xr-x 1 wfg wfg 35M 2009-04-22 17:21 Xnest I would like to create a lot of windows in gnome, and to switch between them. Any ideas on scripting/automating the switch window actions? You can easily do this in KDE 3.5 with dcop(Desktop Communications Protocol)\ e.g. $dcop kchmviewer-17502 KCHMMainWindow raise will raise the window of my kchmviewer. Thank you, it's a good tip :) The alternative I found is wmctrl: Description: control an EWMH/NetWM compatible X Window Manager Wmctrl is a command line tool to interact with an EWMH/NetWM compatible X Window Manager (examples include Enlightenment, icewm, kwin, metacity, and sawfish). . Wmctrl provides command line access to almost all the features defined in the EWMH specification. For example it can maximize windows, make them sticky, set them to be always on top. It can switch and resize desktops and perform many other useful operations. Thanks, Fengguang ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: proportional panning
On Jun 08, 09 17:55:20 +0200, Xavier Bestel wrote: Why not making the proportional mode simply replace the push mode ? Why keeping an allegedly inferior panning mode ? Don't. Some people are used to this behavior. Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: proportional panning
On Mon, 2009-06-08 at 18:16 +0200, Matthias Hopf wrote: On Jun 08, 09 17:55:20 +0200, Xavier Bestel wrote: Why not making the proportional mode simply replace the push mode ? Why keeping an allegedly inferior panning mode ? Don't. Some people are used to this behavior. Ok, I was under the impression that the panning code for RandR 1.3 was quite new. But I forgot about the old Virtual thing. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X.org release engineering?
Where are the release engineering schedule, policies, and steps documented? Note: I have done at least three official X.org component releases (at least three different modules). (Official is defined as: I increased number for release version, did tests, tagged in git, created tarballs, maybe uploaded tarballs?, created checksums, and PGP email to announce on xorg-announce.) (I am writing about release engineering processes. If you'd like to help document release engineering processes specifically for X.org or different project or generically, please let me know.) The testing plan at http://www.x.org/wiki/XorgTesting is out of date. It is about monolithic make world. It doesn't define testing plan for modular X.org components. The TestGroup and XorgTesting wikipages talk about emailing list before code changes and reporting test results. I don't see either of this. The RepoPolicy says Write access to other branches is controlled by the branch owner. The release manager is the owner of the release branch. Who are the branch owners? Who are the release mamagers? Where is this documented? How are they assigned or how do they volunteer? ReleaseWorkingGroup mentions a 6 months cycle. I assumed that is for X.org as a whole and not for invidual components. Nevertheless I don't see any 6 month cycle for X.org or xorg-server. That wiki page also points to a list URL for proposed schedule. but the URL appears to be an unrelated archived list email. The ReleaseHOWTO wikipage doesn't appear to go into detail for specific module release engineering scheduling and coordination for the xorg-server and X.org as a whole. Some of the wiki has deadends -- links that go to This page does not exist yet. and many wiki pages are redirected. So maybe the wiki does have the release engineering schedule, policies, and steps documented, but they aren't followed, adequately explained, are disjointed (steps not organized or linked from same place), are very out-of-date and not applicable, or I just simply can't find them (missing links?). Basically I am looking for documented X.org details for release engineering for individiual components/modules/packages, xorg-server, X.org as a whole: - who is responsible? who helps? - release dates and/or deciding when to release - release schedule (locking tree, locking APIs/ABIs, builds and tests, merging fixes, etc.) - regression testing and quality control. Required tests before and during release. - X.org specific source code control: naming policies for releases, etc. - required communication with end-users and outside packagers/vendors - triaging bug tickets for release engineering planning/scheduling - version numbering policies, alphas? betas? release candidates? - library version numbering policies - distribution of test builds and final releases - documentation policies required by release engineering - security and how it pushes or overrides normal release schedule - and since X.org is very modular and broad: communication about backwards incompatible API and ABI changes and the effects on X.org, xorg-server, and the various components. - what has the elected board discussed for improving or changing the release engineering processes and scheduling? (I know this is just a simple overview and each of these have many details.) Jeremy C. Reed p.s. While I am pointing out problems, I don't want this thread to target anyone. My goal is to be proactive and get the release engineering policies defined (if needed) and well documented here. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Mon, 2009-06-08 at 12:24 -0500, Jeremy C. Reed wrote: - what has the elected board discussed for improving or changing the release engineering processes and scheduling? Just to address this one point, recall that the Board is explicitly not a technical body. It exists to govern the organization, not the code. Now, with my board hat off. De facto technical governance has been somewhere between meritocracy, junta and hazing ritual since approximately the 4.4/6.7 split. The release engineering goals have been fairly loose guidelines rather than strict policy. We could certainly use more rigor, but I suspect that's more about people actually getting off their butts and doing the work than about writing it down. I mean, we say we do katamari releases every six months, but we clearly don't; writing it down and underlining it strenuously isn't going to make it suddenly better. So instead we have a moderately demand-driven release model that happens to trigger the guilt reflex after about nine months. Individual components sync up with whatever server they think is convenient, but practically speaking there's only like five of those, and they're pretty much always buildable against at least the most recent server release and git master. The server goes to ridiculous effort to avoid breaking ABI and bumps a major number internally when it does. The library interfaces never break, ever, with minor exceptions for non-app-facing libraries like libXfont that really deserve to die painfully. Testing is... informal is the polite word. Nobody's stepped up to do it rigorously, so no one does it. Security is handled out of band like any other project. We'll release patches for at least the most recent release, probably do a point release for same, and anyone shipping anything older gets to backport. The actual server release is typically a two or three month cycle of the release engineer branching, cherry-picking fixes from master while skipping nonsense, and either cajoling other people into fixing showstoppers or (more realistically, although unfortunately) superheroing it themselves. Eventually they get sick of it and call it 1.7.0. Then people actually test and you do a 1.7.1 a month later. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Mon, Jun 8, 2009 at 1:20 PM, Adam Jacksona...@nwnk.net wrote: Testing is... informal is the polite word. Nobody's stepped up to do it rigorously, so no one does it. Peter poked me a while ago to work on autotooling xtest. I have it just about working nicely to where you just run make check and sit back while tons of tests fail. Should be ready for public consumption in a week or so even if some of the edges are still pretty sharp. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
