[ANNOUNCE] xcalc 1.0.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xcalc is a Xaw-toolkit based scientific calculator X11 client that can emulate a TI-30 or an HP-10C. This minor maintenance release provides the usual recent collection of improvements to the calculation of the build configuration and other janitorial cleanups. Alan Coopersmith (7): config: upgrade to util-macros 1.8 for additional man page support config: Remove unnecessary calls from configure.ac config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: Explicitly check for xt x11 pkgs, since xcalc calls those directly Purge RCS/CVS version tags create_keypad: declare list of button name strings as const xcalc 1.0.4 Gaetan Nadon (3): configure.ac: use backticks rather than $() for cmd subs config: move CWARNFLAGS from configure.ac to Makefile.am config: update AC_PREREQ statement to 2.60 git tag: xcalc-1.0.4 http://xorg.freedesktop.org/archive/individual/app/xcalc-1.0.4.tar.bz2 MD5: 261ccaa767420ece55bceeff9463e7e6 SHA1: 25e96001331e03a5aae38184887fa0d92eaaf647 http://xorg.freedesktop.org/archive/individual/app/xcalc-1.0.4.tar.gz MD5: e8a07c7b23ae8372312183754cadb5dd SHA1: 95c866d82f7fa7f70e99d7e6677dbf127b926955 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkztq2QACgkQovueCB8tEw6b9gCePZeWi6+0H39BKGGu5ZOKntOS mxYAn0YHTKZx3floV3pZwRho3bgOh6Hk =CXlH -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xeyes 1.1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You spend enough time staring at your monitor, let it stare back, with shaped windows and core pointer tracking. Looking closely at this release would reveal an unsurprising set of build configuration improvements and removal of various eyesores in the code. Alan Coopersmith (7): Fill in COPYING file with copyright notices from source code config: upgrade to util-macros 1.8 for additional man page support config: Remove unnecessary calls from configure.ac config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS Remove trailing whitespace Make usage message fit into 80-column lines xeyes 1.1.1 Gaetan Nadon (2): config: move CWARNFLAGS from configure.ac to Makefile.am config: update AC_PREREQ statement to 2.60 Jesse Adkins (1): Purge cvs tags. git tag: xeyes-1.1.1 http://xorg.freedesktop.org/archive/individual/app/xeyes-1.1.1.tar.bz2 MD5: a3035dcecdbdb89e864177c080924981 SHA1: efe6116d31a7f69e4fb6038613e52b0960b9b61c http://xorg.freedesktop.org/archive/individual/app/xeyes-1.1.1.tar.gz MD5: 2c0522bce5c61bbe784d2b3491998d31 SHA1: b59991119c91c0783a1cff3cc31aeb2fea8f52d9 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkzuEvoACgkQovueCB8tEw4lGwCcCwfx7Hjnq15FHecwT7HKOO62 YPcAnjI23TWb8V5G6cA1yKGurcEZqZgN =u0Vx -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Respository vandalism by r...@...fd.o
Luc Verhaegen l...@skynet.be writes: On Wed, Nov 24, 2010 at 04:36:17PM +1000, Dave Airlie wrote: On Wed, Nov 24, 2010 at 4:31 PM, Luc Verhaegen l...@skynet.be wrote: See, this was exactly the problem here. It _was_ a freedesktop admin. And it was pretty clear that it was that from the onset too. Mailing fd.o admins, even if i could've dug up an email address in the split second that i wrote the email (heck, i even mistyped repository), was not the right course of action. (As an aside: maybe it would be a good idea to spend more than a split second on writing an email of this kind?) So you mailed 2 mailing lists consisting of 2-300 people who could do nothing about it? nice work. Dave. Stop the counter-attack dave, it's far too obvious what you are doing here. His response seems quite reasonable to me, assuming that he thought your intention was to get the problem looked into rather than just raising a stink. On the other hand if your intention was primarily to make a lot of noise, then clearly your action was a reasonable one. Which brings me to: The means to the end were perfectly justifiable under the circumstances, and this includes the years of experience i have with dealing with X.org community. This especially includes the experience of something as noble as the radeonhd driver project. Then what was your intended end? Has it been accomplished? As far as I can see, all you've managed to do is to create a lot of noise about what is, in itself, a fairly minor incident. Yes, it is serious that a trusted admin abuses his powers. However, that happens and will continue to happen. Humans are like that. We often show a remarkable lack of good judgement. And in this case, I think the pattern matches well with bad judgement rather than evil intent. What I'm far more worried about are the admins (and non-admins) who have made changes with evil intent that we have not noticed. I am not particularly worried about this incident, as anyone with true evil intent would not have advertised their actions like this. However, that doesn't mean that no-one have acted with evil intent, and been successful at it. There are two things that I feel are important about this: 1. What systems do we have in place that enables us to detect when a trusted admin acts in bad judgement or with evil intent? What is the probability that such actions will be noticed? Can we do anything to increase this probability? 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? You'll notice that none of these are directly related to this incident. This incident only provides an excuse for bringing up such issues. If that was your goal, then I feel that it has not yet been accomplished, but making noise about it may have been a reasonable approach anyway. More related to this incident (and your comments) could be this issue, which I consider slightly less important than the previous two, but is still a quite significant point: 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? Of course, I have my own suspicions about the answers to all three questions, but that's not the point. The point is that the people who actually deal with these things must reflect over whether what we are doing is good enough or whether we should do better. (It goes without saying that we could do better, the question is whether it is worthwhile to spend effort on actually doing better.) I know that all this work is largely carried out by volunteers in their spare time. That doesn't make my three questions unimportant. (I'll just end by pointing out that whenever I say we above, of course I mean you, considering how much I personally have contributed to this project. Thank you for all the good work, it is deeply appreciated.) eirik ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 4:48 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Nov 24, 2010 at 04:36:17PM +1000, Dave Airlie wrote: On Wed, Nov 24, 2010 at 4:31 PM, Luc Verhaegen l...@skynet.be wrote: See, this was exactly the problem here. It _was_ a freedesktop admin. And it was pretty clear that it was that from the onset too. Mailing fd.o admins, even if i could've dug up an email address in the split second that i wrote the email (heck, i even mistyped repository), was not the right course of action. So you mailed 2 mailing lists consisting of 2-300 people who could do nothing about it? nice work. Dave. Heh. I already wasted quite some time on the actions of one of your colleagues, i guess i can waste some more time on yours. Stop the counter-attack dave, it's far too obvious what you are doing here. Paranoid much? still seeing faces in the dark? Like really if you can't answer a simple question about why you mailed 200 people who couldn't do any investigation of the issue without going off the deep end I have to wonder. Dave. The means to the end were perfectly justifiable under the circumstances, and this includes the years of experience i have with dealing with X.org community. This especially includes the experience of something as noble as the radeonhd driver project. Anything else than a similar course action would've meant that the issue would've been silenced to death. Luc Verhaegen. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 06:01:19PM +1000, Dave Airlie wrote: On Wed, Nov 24, 2010 at 4:48 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Nov 24, 2010 at 04:36:17PM +1000, Dave Airlie wrote: On Wed, Nov 24, 2010 at 4:31 PM, Luc Verhaegen l...@skynet.be wrote: See, this was exactly the problem here. It _was_ a freedesktop admin. And it was pretty clear that it was that from the onset too. Mailing fd.o admins, even if i could've dug up an email address in the split second that i wrote the email (heck, i even mistyped repository), was not the right course of action. So you mailed 2 mailing lists consisting of 2-300 people who could do nothing about it? nice work. Dave. Heh. I already wasted quite some time on the actions of one of your colleagues, i guess i can waste some more time on yours. Stop the counter-attack dave, it's far too obvious what you are doing here. Paranoid much? still seeing faces in the dark? Like really if you can't answer a simple question about why you mailed 200 people who couldn't do any investigation of the issue without going off the deep end I have to wonder. Dave. Not this again. It is getting rather old, and especially in light of recent events, it seems rather out of place too. Stop it, it's ridiculous. Luc Verhaegen. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
Hi, Dave, thanks for the Cc. I've Cc-ed this to freedesktop@, since it's really a bit more of a project-wide discussion than just xorg, but feel free to keep both in Cc. ]] Frans de Boer | Also, if it turns out to be a validated claim Adam made, accept it as | is and continue. Hopefully Adam has learned his lesson. But also | Freedesktop.org should have it's act together. Do check the access | rights and allow only trusted persons root access. Hopefully Adam was | NOT one of them they trusted explicitly and he has only access due to | historical reasons. People are people and sometimes do stupid things and things the reret. What Adam did was stupid and wrong, but it was also out of character for him. There was no reason whatsoever not to let him have root access before. ]] Dave Airlie | Yes, and not sure about the rest. Freedesktop isn't some sort of paid | organisation here, you have a group of volunteers running some | machines tied together with a lot of bailing twine. It only recently | through the good graces of Collabora that fd.o got some paid | administration time directed at it at all (Tollef). Like we could | migrate all the stuff to machines that X.org control but we'd end up | with the same problems + another set of problems. The main problem fdo is facing on the admin side those days is a lack of resources more than anything, and we don't want to trust completely random people to have root. Those we trust enough to have root are usually quite busy already. That said, I'm hoping to make the admin burden slightly lighter by doing two things. Please note that these are my ideas, they're not set in stone and while I think I have the consensus of the rest of the active fdo admins, nothing has formally been decided yet. - Kick out inactive admins and bring new ones on board. I'm not going to take away root from anybody who uses it and needs it, but for people who just have root for historical reasons and haven't done anything with it for months or years, I'd like to remove it. - Split account administration and root. We already use ud-ldap and we do have one account admin that's not root, so this is already feasible, and if some of the existing root users basically only do account management, I'd like to move those people off root and just get them account management rights. Over time, I'm slightly hoping we can split this even further out so trusted people can do git repository management for their own project without having to involve an admin for the easy regular tasks. If anybody wants to be involved in this (and over time, more involved in fdo admin work), I'd love to get help, particularly with moving towards some of the ideas in http://err.no/personal/blog/tech/2010-03-27-15-55_why_you_should_publish_your_infrastructure | Adam still does a lot of a/c maintenance for X.org and other projects, | these will now be have to be done by part-time admin which means even | longer delays on new a/cs. There is a major fd.o overhaul in the works | and maybe Tollef can provide some insight into it when he has time. Some of the items are listed above, in addition we're in the middle of acquiring new machines which should allow things like better spam filtering and generally better performance. Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On 24/11/10 18:00 , Eirik Byrkjeflot Anonsen wrote: 1. What systems do we have in place that enables us to detect when a trusted admin acts in bad judgement or with evil intent? What is the probability that such actions will be noticed? Can we do anything to increase this probability? 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? git is designed to not be screwed with easily, so the chance of bad commits being detected is quite high. for well-maintained repositories, we tend to notice quite quickly. I'm sure keith would notice whenever he can't push to xserver because no-one else is supposed to commit to it. The same is true for other repositories, so the best safeguard here is active maintainership. 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? I think in this particular case, a large number of insiders likely assumed a prank before it was called out. There is a history of disagreements between some of the X.Org developers and Luc and the radeonhd project, so having this happen to this particular repository is not that surprising after all (Note, this does not excuse the action, merely explain some of the reactions). I'd have been more worried if that had happened to e.g. the xserver repo. I don't think we have any official processes right now and certainly none documented. Sending emails to the list to raise awareness is a good approach IMO and Luc's first few emails were informative. The later part of the thread somewhat lost usefulness when it descended to the usual fights, conspiracy theories and name-calling. Staying on-topic should be an essential part of any official process... Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
As far as I can see, all you've managed to do is to create a lot of noise about what is, in itself, a fairly minor incident. Yes, it is serious that a trusted admin abuses his powers. However, that happens and will continue to happen. Humans are like that. We often show a remarkable lack of good judgement. And in this case, I think the pattern matches well with bad judgement rather than evil intent. What I'm far more worried about are the admins (and non-admins) who have made changes with evil intent that we have not noticed. I am not particularly worried about this incident, as anyone with true evil intent would not have advertised their actions like this. However, that doesn't mean that no-one have acted with evil intent, and been successful at it. There are two things that I feel are important about this: 1. What systems do we have in place that enables us to detect when a trusted admin acts in bad judgement or with evil intent? What is the probability that such actions will be noticed? Can we do anything to increase this probability? wrt to the git repos, git is designed to be good at detecting tampering, esp history tampering, i.e. git won't allow a push to a repo that hasn't got matching history. Someone adding a branch or pushing a branch with a file, should be noticed by active project participants. We also sign all the release emails with md5/sha1 sums for the tarballs for later verification, which was instituted after the last real security incident. 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? Again git + humans using the repos should catch most things. 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? We could probably better define this sort of things, again fd.o has been a pretty haphazard setup based on volunteer time and effort, but again hopefully we can get some escalation procedures in place that are less public. Dave. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 06:33:19PM +1000, Peter Hutterer wrote: On 24/11/10 18:00 , Eirik Byrkjeflot Anonsen wrote: 1. What systems do we have in place that enables us to detect when a trusted admin acts in bad judgement or with evil intent? What is the probability that such actions will be noticed? Can we do anything to increase this probability? 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? git is designed to not be screwed with easily, so the chance of bad commits being detected is quite high. for well-maintained repositories, we tend to notice quite quickly. I'm sure keith would notice whenever he can't push to xserver because no-one else is supposed to commit to it. The same is true for other repositories, so the best safeguard here is active maintainership. 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? I think in this particular case, a large number of insiders likely assumed a prank before it was called out. There is a history of disagreements between some of the X.Org developers and Luc and the radeonhd project, so having this happen to this particular repository is not that surprising after all (Note, this does not excuse the action, merely explain some of the reactions). I'd have been more worried if that had happened to e.g. the xserver repo. I don't think we have any official processes right now and certainly none documented. Sending emails to the list to raise awareness is a good approach IMO and Luc's first few emails were informative. The later part of the thread somewhat lost usefulness when it descended to the usual fights, conspiracy theories and name-calling. Staying on-topic should be an essential part of any official process... Conspiracy theories? Come on man, Daniel Stone and Adam Jackson, known, over the years, for liking radeonhd, sit down, after most likely some alcohol and maybe even other substances, and pull this. According to irc, Adam, who had root access himself, used Daniel his account to do this, in a targetted and efficient manner. If i remember the timestamps right, the update script was moved back within 5 minutes of the commit. Then 3 weeks ensued where nothing happened, where Adam and Daniel could've fixed their spur of the moment mistake, without anyone noticing, but clearly, they did not come back on their steps. It was a completely unnecessary event, and it only serves to show how certain projects, not suited to a certain group are being treated. And two former X.org board, two people who joined the X.org fork from xfree86 very early on, but who, as far as i can tell, were little or not involved with xfree86 at the time, and who got these access rights from very early on too, abused their power to trash existing but unmaintained free software project. Now, of course everyone ties this in with my history with X.org, from unichrome, to modesetting, to radeonhd, to fosdem, to graphics driver stacks. But you also might want to consider that i was at a hardware vendor two weeks ago, and i had to listen to their main engineer calling contributing directly to X a waste of time, and that they rather fix the versions their customers ship, and hand the patches to their customers directly, never bothering to submit to X directly. They rather implement stuff, hand it to their customers, as they know that their code will not be accepted, and that it will be reinvented a few weeks or months later. Then they go and use the reimplementation afterwards, and save a lot of manpower and frustration in the process. Despite all my personal feelings about free software and the likes, I had absolutely nothing to counter, anything i could even try to throw up against that would either be completely irrelevant and meek, or a lie. _This_ is how the world works with an X.org that works like that. Someone just mailed it i find it surprising that the person exposing the evildoing is getting more flack than the person(s) doing it. Luc Verhaegen ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
Luc, I completely agree with you. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 11:03 AM, Tim Beaulen tbsc...@gmail.com wrote: Luc, I completely agree with you. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: madman2...@gmail.com If Adam indeed did this, and did not undo it afterwards, then he is having at least some (mental) issues. He did the right thing by disabling his admin account, because he obviously has some things to sort out. While the action itself is minor, the causes for doing it probably are not. Just encourage Adam to work out his problems. Trust can be rebuilt, it just takes (a lot of) time and an effort on his side to sort out his life. Maarten. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On 24/11/10 19:38 , Luc Verhaegen wrote: On Wed, Nov 24, 2010 at 06:33:19PM +1000, Peter Hutterer wrote: On 24/11/10 18:00 , Eirik Byrkjeflot Anonsen wrote: 1. What systems do we have in place that enables us to detect when a trusted admin acts in bad judgement or with evil intent? What is the probability that such actions will be noticed? Can we do anything to increase this probability? 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? git is designed to not be screwed with easily, so the chance of bad commits being detected is quite high. for well-maintained repositories, we tend to notice quite quickly. I'm sure keith would notice whenever he can't push to xserver because no-one else is supposed to commit to it. The same is true for other repositories, so the best safeguard here is active maintainership. 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? I think in this particular case, a large number of insiders likely assumed a prank before it was called out. There is a history of disagreements between some of the X.Org developers and Luc and the radeonhd project, so having this happen to this particular repository is not that surprising after all (Note, this does not excuse the action, merely explain some of the reactions). I'd have been more worried if that had happened to e.g. the xserver repo. I don't think we have any official processes right now and certainly none documented. Sending emails to the list to raise awareness is a good approach IMO and Luc's first few emails were informative. The later part of the thread somewhat lost usefulness when it descended to the usual fights, conspiracy theories and name-calling. Staying on-topic should be an essential part of any official process... Conspiracy theories? I did not imply that you were the one starting with the conspiracy theories, and I think strictly speaking there was no name-calling in that thread either so I have overshot the target and I apologise. Correct the above to the usual fights, that at least is obvious. Anyway, the best approach to solving issues like this is to go to the list and say hey guys, this isn't funny, it raises trust issues when that happens. Which is exactly what your first email did, and the first subsequent ones. The thread then went haywire quickly, initiated by a number of people, and that is unnecessary. At this point we have found the guilty parties, we have a publicly expressed regret, the consequences of removed root access, and we should move on to the more on-topic questions Eirik raised. If you want to raise the issue of how the radeonhd project was treated or the methods of said hardware vendor, I suggest starting a new thread because I don't think this one will go anywhere useful at this point. Cheers, Peter Come on man, Daniel Stone and Adam Jackson, known, over the years, for liking radeonhd, sit down, after most likely some alcohol and maybe even other substances, and pull this. According to irc, Adam, who had root access himself, used Daniel his account to do this, in a targetted and efficient manner. If i remember the timestamps right, the update script was moved back within 5 minutes of the commit. Then 3 weeks ensued where nothing happened, where Adam and Daniel could've fixed their spur of the moment mistake, without anyone noticing, but clearly, they did not come back on their steps. It was a completely unnecessary event, and it only serves to show how certain projects, not suited to a certain group are being treated. And two former X.org board, two people who joined the X.org fork from xfree86 very early on, but who, as far as i can tell, were little or not involved with xfree86 at the time, and who got these access rights from very early on too, abused their power to trash existing but unmaintained free software project. Now, of course everyone ties this in with my history with X.org, from unichrome, to modesetting, to radeonhd, to fosdem, to graphics driver stacks. But you also might want to consider that i was at a hardware vendor two weeks ago, and i had to listen to their main engineer calling contributing directly to X a waste of time, and that they rather fix the versions their customers ship, and hand the patches to their customers directly, never bothering to submit to X directly. They rather implement stuff, hand it to their customers, as they know that their code will not be accepted, and that it will be
Re: Respository vandalism by r...@...fd.o
See, this was exactly the problem here. It _was_ a freedesktop admin. And it was pretty clear that it was that from the onset too. Mailing fd.o admins, even if i could've dug up an email address in the split second that i wrote the email (heck, i even mistyped repository), was not the right course of action. So you mailed 2 mailing lists consisting of 2-300 people who could do nothing about it? He ensured the problem was noticed, and that it got out to people who depend upon the repository being secure and properly managed. In this case that turns out to have ensured the offender admitted to something silly but if it had been a more serious attack it would also have ensured people relying on the repository knew what was going on. Security through bad mouthing the messenger for raising the issue is normally reserved for government ministers, IMHO it has no place here. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
Hi, I've been mostly offline whilst moving, so have only read this through web archives. As mentioned on IRC earlier, it was my account used. My apologies: as ajax said, it's indefensible, and am not really sure what else to say. I've suspended my root accounts as well. That being said: On Wed, Nov 24, 2010 at 10:38:19AM +0100, Luc Verhaegen wrote: maybe even other substances As explained to Luc earlier: no, absolutely not. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 11:18:20AM +, Alan Cox wrote: He ensured the problem was noticed, and that it got out to people who depend upon the repository being secure and properly managed. In this case that turns out to have ensured the offender admitted to something silly but if it had been a more serious attack it would also have ensured people relying on the repository knew what was going on. Security through bad mouthing the messenger for raising the issue is normally reserved for government ministers, IMHO it has no place here. With all things said and done, it looks like mailing just fd.o admins was not the best of options here. Two of the fd.o admins were responsible for this :( Luc Verhaegen. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 08:27:12PM +1000, Peter Hutterer wrote: On 24/11/10 19:38 , Luc Verhaegen wrote: Conspiracy theories? I did not imply that you were the one starting with the conspiracy theories, and I think strictly speaking there was no name-calling in that thread either so I have overshot the target and I apologise. Correct the above to the usual fights, that at least is obvious. Anyway, the best approach to solving issues like this is to go to the list and say hey guys, this isn't funny, it raises trust issues when that happens. Which is exactly what your first email did, and the first subsequent ones. The thread then went haywire quickly, initiated by a number of people, and that is unnecessary. At this point we have found the guilty parties, we have a publicly expressed regret, the consequences of removed root access, and we should move on to the more on-topic questions Eirik raised. If you want to raise the issue of how the radeonhd project was treated or the methods of said hardware vendor, I suggest starting a new thread because I don't think this one will go anywhere useful at this point. Cheers, Peter It is highly related though, the stunt pulled here just underlines the situation the project is in for anyone not belonging to the right crowd, and that directly affects the future of X.org. Heck, part of the reason why so many go crazy over any X replacement project can be attributed to this. Luc Verhaegen. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Dual (virtual) screen support under Xephyr (or Xnest)?
Hey Folks- I'm trying to debug some multiscreen issues with a wm [0] I'm contributing to. This wm is scriptable so it makes development pretty cool, you write a test and it runs the tests in Xephyr. There are some issues with dual monitor support which I'd like to get ironed out. Sadly I can't get Xephyr, Xdmx or Xnest to work with dual (virtual) screens. It be great to test under them rather than using my real desktop. Here's what I've tried: # old command Xephyr -br +extension RANDR +xinerama -mouse evdev -screen 500x600 -screen 400x300+500+0 :1 -ac (sleep 1; env DISPLAY=:1 ~/work/pylibs/qtile/qtile -d -c /home/matt/.config/qtile/mattdev.py env DISPLAY=:1 xterm) Brings up 2 windows, but I can't use xrandr to place them next to each other. In fact xrandr only sees (can connect to) one of the windows. Both windows seem to overlap. # Xdmx attempt Xephyr :3.0 -a -ac -br +extension RANDR +xinerama -screen 300×400 Xephyr :4.0 -a -ac -br +extension RANDR +xinerama -screen 200×400 (sleep 2; Xdmx :5 -display localhost:3 -display localhost:4 +xinerama) (sleep 4; env DISPLAY=:5 ~/work/pylibs/qtile/qtile -d -c /home/matt/.config/qtile/mattdev.py env DISPLAY=:5 xterm) Seems to bring up 2 windows next to each other, but doesn't want to let the wm draw anything other than windows: (**) dmx: dmxErrorHandler: RenderBadPicture (invalid Picture parameter) (**) dmx: Major opcode: 143 (RENDER) (**) dmx: Minor opcode: 10 (RenderTrapezoids) (**) dmx: ResourceID: 0x2000ae (**) dmx: Failed serial number: 1195 (**) dmx: Current serial number: 1196 # xnest Xnest :1 -ac -br +xinerama -scrns 2 -geometry 1000x500 (sleep 1; env DISPLAY=:1 ~/work/pylibs/qtile/qtile -d -c /home/matt/.config/qtile/mattdev.py env DISPLAY=:1 xterm) This segfaults. I'm running on an intel t61p thinkpad with gentoo. xorg 1.7.7, intel drivers 2.13. Any hints or suggestions would be wonderful. As a last resort I could develop under my real (non-nested) wm. thanks much! -matt 0 - http://www.qtile.org/ ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
Eirik Byrkjeflot Anonsen wrote: 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? Distributed version control. Developers should notice when attempting to push to git if head had changed unexpectedly. I'm sure google can find you some background reading about how this works in git. 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? Those would be questions for our hosting provider, freedesktop.org. X.Org does not control the freedesktop.org machines. There is a large overlap in the groups, but we do not have the authority to speak for them. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 6:58 AM, Luc Verhaegen l...@skynet.be wrote: On Wed, Nov 24, 2010 at 08:27:12PM +1000, Peter Hutterer wrote: On 24/11/10 19:38 , Luc Verhaegen wrote: Conspiracy theories? I did not imply that you were the one starting with the conspiracy theories, and I think strictly speaking there was no name-calling in that thread either so I have overshot the target and I apologise. Correct the above to the usual fights, that at least is obvious. Anyway, the best approach to solving issues like this is to go to the list and say hey guys, this isn't funny, it raises trust issues when that happens. Which is exactly what your first email did, and the first subsequent ones. The thread then went haywire quickly, initiated by a number of people, and that is unnecessary. At this point we have found the guilty parties, we have a publicly expressed regret, the consequences of removed root access, and we should move on to the more on-topic questions Eirik raised. If you want to raise the issue of how the radeonhd project was treated or the methods of said hardware vendor, I suggest starting a new thread because I don't think this one will go anywhere useful at this point. Cheers, Peter It is highly related though, the stunt pulled here just underlines the situation the project is in for anyone not belonging to the right crowd, and that directly affects the future of X.org. Heck, part of the reason why so many go crazy over any X replacement project can be attributed to this. Luc Verhaegen. From the Phoronix forums, you say Yeah, this was most definitely not a simple prank, as some people like to claim. What are you suggesting it was? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 11:08:18AM -0500, Matt Turner wrote: From the Phoronix forums, you say Yeah, this was most definitely not a simple prank, as some people like to claim. What are you suggesting it was? Do you really find this a simple prank? Or do you find this a flagrant abuse of power and a severe breach of trust that damages the whole of fd.o and x.org? Why do i find myself having to explain this still, i would've expected this was clear by now. Luc Verhaegen. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg 7.5 freezes after Linux kernel upgrade
On Wed, Nov 24, 2010 at 11:02 AM, Jeremy Henty onepo...@starurchin.org wrote: I am currently happily running Xorg 7.5 on Linux kernel 2.6.35.8 . If I upgrade the kernel to 2.6.36 the screen goes black (even with the -retro argument) and the system locks up. Ctrl-Alt-Fn and Ctrl-Alt-Del do nothing, but Alt-SysRq-r followed by Ctrl-Alt-Del reboots cleanly. Any ideas? I am attaching before/after logs. I created each one in the same way: reboot, log in as root, run Xorg -retro, Alt-SysRq-r, Ctrl-Alt-Del, reboot again and save a copy of /var/log/Xorg.0.log . Apart from changes of memory addresses, timestamps etc., the new log is just an initial segment of the old, suggesting that Xorg just stops completely while initialising. Thanks in advance for any help. Do you have kms enabled in your kernel config? Try booting with radeon.modeset=0 on the kernel command line or make sure the radeon drm is loaded before starting X. Alex Regards, Jeremy Henty System details: uname -a Linux omphalos 2.6.35.8-0 #1 SMP PREEMPT Sun Oct 31 20:23:43 GMT 2010 i686 athlon-4 i386 GNU/Linux gcc --version gcc (GCC) 4.4.1 Xorg: xorg-server-1.7.1 driver: xf86-video-ati-6.12.4 libdrm: libdrm-2.4.14 Graphics card: ATI Radeon 9250 PCI ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: alexdeuc...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 5:12 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Nov 24, 2010 at 11:08:18AM -0500, Matt Turner wrote: From the Phoronix forums, you say Yeah, this was most definitely not a simple prank, as some people like to claim. What are you suggesting it was? Do you really find this a simple prank? Or do you find this a flagrant abuse of power and a severe breach of trust that damages the whole of fd.o and x.org? Why do i find myself having to explain this still, i would've expected this was clear by now. Let me get straight to the point: You pointed out the issue, we found out who did it, they apologized for doing so and revoked their root access. So what other actions do you want to be taken now? So I agree with Peter here, the thread served its purpose, lets move on. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
drago01 wrote: You pointed out the issue, we found out who did it, they apologized for doing so and revoked their root access. So what other actions do you want to be taken now? If I may step in I suggest investing some time and developing some sort of (formal) security concept. It's not that much time and it would boost your security ten fold. Pranks from trusted admins would perhaps not be avoided but other latent issues will. Michal Svoboda ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
RE: libX11 build error
On Wed, 2010-11-24 at 10:05 +0200, Deniz Fer wrote: My previous mail had the output of the compiling script which also includes the output of configure command. There appears to be no error but a lot of warnings which I couldn’t understand. I have added the config.log and config.status files in the attachments. Our build machines are similar, I use Ubuntu 64 bit. Not that it is critical to have, but in order to reduce differences, you should build and install the package xorg-sgml-doctools. This will give you the stylesheets for the docs generated in /nls. It will remove the following message from config.log: configure:5826: $PKG_CONFIG --exists --print-errors xorg-sgml-doctools = 1.5 Package xorg-sgml-doctools was not found in the pkg-config search path. Perhaps you should add the directory containing `xorg-sgml-doctools.pc' to the PKG_CONFIG_PATH environment variable No package 'xorg-sgml-doctools' found I have uninstalled this module (make uninstall) and reconfigured libX11 and /nls still builds correctly. .pre: @$(MKDIR_P) $(@D) $(AM_V_GEN)$(RAWCPP) $(RAWCPPFLAGS) $(CPP_FILES_FLAGS) $ | $(CPP_SED_MAGIC) $@ where: RAWCPP = /usr/bin/cpp RAWCPPFLAGS = -undef -traditional CPP_FILES_FLAGS = $(WCHAR32_FLAGS) WCHAR32_FLAGS = -DWCHAR32=1 CPP_SED_MAGIC = $(SED) -e '/^\# *[0-9][0-9]* *.*$$/d' \ -e '/^\#line *[0-9][0-9]* *.*$$/d' \ -e '/^[ ]*XCOMM$$/s/XCOMM/\#/' \ -e '/^[ ]*XCOMM[^a-zA-Z0-9_]/s/XCOMM/\#/' \ -e '/^[ ]*XHASH/s/XHASH/\#/' \ -e 's,X11_LOCALEDATADIR,$(X11_LOCALEDATADIR),g' \ -e '/\...@\@$$/s/\...@\@$$/\\/' When you issue the cpp command yourself, it works. When you issue the make command, you only get the $@ part which evaluates to am_ET.UTF-8/XLC_LOCALE. The variables have the correct value, yet they don't show up on the emitted cpp command. The problem has to be around this area. Try some of these: Edit the generated Makefile to replace the variables with their values. Build other directories (just cd and make install) particularly the specs directory. Check for any local hack to the make executable. Build the /config dir in app/xdm (http://cgit.freedesktop.org/xorg/app/xdm/) it uses a similar cpp command. In a new empty directory, clone the libX11 again and rebuild. I attached my generated Makefile for comparison. I also tried to issue the command you have mentioned before, it executes without any error (so the commands used are all valid) but the XLC_LOCALE file it creates is empty (probably because I did not edit any environment variables). Mine too is empty. This is normal for some locales. Good luck. # Makefile.in generated by automake 1.10.2 from Makefile.am. # nls/Makefile. Generated from Makefile.in by configure. # Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, # 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. # # Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the Software), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice (including the next # paragraph) shall be included in all copies or substantial portions of the # Software. # # THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER # DEALINGS IN THE SOFTWARE. # # -*- Makefile -*- # Rules for generating files using the C pre-processor # (Replaces CppFileTarget from Imake) pkgdatadir = $(datadir)/libX11 pkglibdir = $(libdir)/libX11 pkgincludedir = $(includedir)/libX11 am__cd =
Re: Respository vandalism by r...@...fd.o
On Nov 23, 10 22:56:52 +, Alan Cox wrote: It's on a separate branch, not master. (Doesn't mean it's right, just that it's not actually going to cripple anything or waste time for anyone who doesn't ask for it.) And how many other un-noticed commits did this person make ? Until you know that you have to assume a complete compromise. Luckily, git makes this difficult. At least as long as git histories are repeatedly checked (which they are for the main trees), a git fsck should find any inconsistencies, and you should get broken fast-forwards. Not that this makes the fraud any better. Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: No mouse acceleration in latest Git X.org
On 11/23/2010 06:33 AM, Joel Feiner wrote: Mouse acceleration seems to have gone away as of a week or so ago. I'm not sure which component did it and I don't recall when it actually changed since I use Linux now irregularly and only update once in a while. Yes, It's a known problem originating from the recent masked valuators introduction. I patched what's obvious but that didn't fix it, so if you want to help out just go ahead ;) I have only one file in my /etc/X11/xorg.conf.d, which is to change some settings for my Radeon card. There are not settings for input and I use the default HAL config (which will probably go away soon as HAL is dead). My xorg.0.log is attached but it did not seem to shed any light on the issue. Of note is that the Gentoo build of Xorg, which calls itself 1.9.2.901 (as opposed to the Git build, which calls itself 1.9.99.1), works just fine. The config files are exactly the same when I switch between the two. So there must be something wrong with the code. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: simon.t...@gmx.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
So, wearing my X11R7.6 Release Manager hat, I am willing to accept that the git repositories are not known to be compromised by an outside actor, and that we can go forward with development releases as normal. I had been quietly holding off on doing any more releases until the issue was investigated, but am now satisfied that we know with reasonable certainty how the spigot branch jerkcity commit came to be in the radeonhd git repo. While Adam Daniel's judgment in making those was obviously unsound, I still feel I can rely on their integrity, so if they say this was an isolated incident and that no other repos were illicitly modified, I believe them. (But then, I also have faith in git's sha1 hashes of commits to reinforce this and help us spot any unauthorized commits others may attempt to make, as discussed elsewhere in this thread.) Of course, when making releases I do look over the commits included, in order to judge what sort of version number increase is warranted by the changes included (i.e. version += 0.0.1 for configure script updates janitorial cleanups, version += 0.1 for new features) and to be able to summarize the changes in the release announcements, so would hopefully spot any out-of-place commits and hope that other developers maintainers are doing the same. (Before I get any more e-mail or IRC chatter berating me for downplaying the seriousness of this issue, I am only addressing in this message my personal opinion of whether we can go forward with using the git repos on freedesktop.org as normal, not discussing the original action or its repercussions outside the ability of the rest of us to get back to work.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
But you also might want to consider that i was at a hardware vendor two weeks ago, and i had to listen to their main engineer calling contributing directly to X a waste of time, and that they rather fix the versions their customers ship, and hand the patches to their customers directly, never bothering to submit to X directly. They rather implement stuff, hand it to their customers, as they know that their code will not be accepted, and that it will be reinvented a few weeks or months later. Then they go and use the reimplementation afterwards, and save a lot of manpower and frustration in the process. Despite all my personal feelings about free software and the likes, I had absolutely nothing to counter, anything i could even try to throw up against that would either be completely irrelevant and meek, or a lie. This I'm curious about. Are there more companies that feel it's too-hard/not-worth-while for companies to contribute stuff to Xorg? I know the linux kernel has this issue, but is X's contribution difficulty larger? I ask out of complete curiosity, not trying to stir any pot. Matt ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xcalc 1.0.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xcalc is a Xaw-toolkit based scientific calculator X11 client that can emulate a TI-30 or an HP-10C. This minor maintenance release provides the usual recent collection of improvements to the calculation of the build configuration and other janitorial cleanups. Alan Coopersmith (7): config: upgrade to util-macros 1.8 for additional man page support config: Remove unnecessary calls from configure.ac config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: Explicitly check for xt x11 pkgs, since xcalc calls those directly Purge RCS/CVS version tags create_keypad: declare list of button name strings as const xcalc 1.0.4 Gaetan Nadon (3): configure.ac: use backticks rather than $() for cmd subs config: move CWARNFLAGS from configure.ac to Makefile.am config: update AC_PREREQ statement to 2.60 git tag: xcalc-1.0.4 http://xorg.freedesktop.org/archive/individual/app/xcalc-1.0.4.tar.bz2 MD5: 261ccaa767420ece55bceeff9463e7e6 SHA1: 25e96001331e03a5aae38184887fa0d92eaaf647 http://xorg.freedesktop.org/archive/individual/app/xcalc-1.0.4.tar.gz MD5: e8a07c7b23ae8372312183754cadb5dd SHA1: 95c866d82f7fa7f70e99d7e6677dbf127b926955 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkztq2QACgkQovueCB8tEw6b9gCePZeWi6+0H39BKGGu5ZOKntOS mxYAn0YHTKZx3floV3pZwRho3bgOh6Hk =CXlH -END PGP SIGNATURE- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
Matt, I think what you are asking is: is the Microsoft FUD working? The answer is: yes. Should we roll over and play dead? No, not me. Freedom, as in free range, Pat --- On Wed, Nov 24, 2010 at 3:56 PM, Matt Dew m...@osource.org wrote: This I'm curious about. Are there more companies that feel it's too-hard/not-worth-while for companies to contribute stuff to Xorg? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: No mouse acceleration in latest Git X.org
On Wed, Nov 24, 2010 at 5:44 PM, Simon Thum simon.t...@gmx.de wrote: On 11/23/2010 06:33 AM, Joel Feiner wrote: Mouse acceleration seems to have gone away as of a week or so ago. I'm not sure which component did it and I don't recall when it actually changed since I use Linux now irregularly and only update once in a while. Yes, It's a known problem originating from the recent masked valuators introduction. I patched what's obvious but that didn't fix it, so if you want to help out just go ahead ;) It does seem to fix it for me. I just rebuilt from Git this evening after I had a chance to reboot into Linux. Acceleration is now working. I have only one file in my /etc/X11/xorg.conf.d, which is to change some settings for my Radeon card. There are not settings for input and I use the default HAL config (which will probably go away soon as HAL is dead). My xorg.0.log is attached but it did not seem to shed any light on the issue. Of note is that the Gentoo build of Xorg, which calls itself 1.9.2.901 (as opposed to the Git build, which calls itself 1.9.99.1), works just fine. The config files are exactly the same when I switch between the two. So there must be something wrong with the code. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: simon.t...@gmx.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: jafei...@gmail.com -- - Joel ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xeyes 1.1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You spend enough time staring at your monitor, let it stare back, with shaped windows and core pointer tracking. Looking closely at this release would reveal an unsurprising set of build configuration improvements and removal of various eyesores in the code. Alan Coopersmith (7): Fill in COPYING file with copyright notices from source code config: upgrade to util-macros 1.8 for additional man page support config: Remove unnecessary calls from configure.ac config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS Remove trailing whitespace Make usage message fit into 80-column lines xeyes 1.1.1 Gaetan Nadon (2): config: move CWARNFLAGS from configure.ac to Makefile.am config: update AC_PREREQ statement to 2.60 Jesse Adkins (1): Purge cvs tags. git tag: xeyes-1.1.1 http://xorg.freedesktop.org/archive/individual/app/xeyes-1.1.1.tar.bz2 MD5: a3035dcecdbdb89e864177c080924981 SHA1: efe6116d31a7f69e4fb6038613e52b0960b9b61c http://xorg.freedesktop.org/archive/individual/app/xeyes-1.1.1.tar.gz MD5: 2c0522bce5c61bbe784d2b3491998d31 SHA1: b59991119c91c0783a1cff3cc31aeb2fea8f52d9 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkzuEvoACgkQovueCB8tEw4lGwCcCwfx7Hjnq15FHecwT7HKOO62 YPcAnjI23TWb8V5G6cA1yKGurcEZqZgN =u0Vx -END PGP SIGNATURE- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
