Problems with xorg-server-devel @1.17.0_0 and xorg-server-devel @1.17.1_0 on PPC Mac OS X 10.5.8, Leopard
Hello Jeremy and others! When I today booted into Leopard and launched X11, it was the MacPorts package xorg-server-devel @1.17.1_0 that provided the X server. The clients looked different, instead of brown the window decoration was green. And gkrellm and GNU Emacs 23.4 died. The mouse cursor was invisible although X11 had the focus and therefore was easy to quit. I then activated xorg-server-devel @1.17.0_0. With the same results. With xorg-server-devel @1.16.99.1_2 everything is OK. I have crash logs: -rw------- 1 pete admin 21182 14. Feb 19:02 emacs-23.4_2015-02-14-190207_Leopard.crash -rw------- 1 pete admin 23320 14. Feb 19:01 gkrellm_2015-02-14-190103_Leopard.crash -rw------- 1 pete admin 21180 14. Feb 18:56 emacs-23.4_2015-02-14-185620_Leopard.crash -rw------- 1 pete admin 23318 14. Feb 18:55 gkrellm_2015-02-14-185514_Leopard.crash -rw------- 1 pete admin 21180 14. Feb 18:51 emacs-23.4_2015-02-14-185108_Leopard.crash -rw------- 1 pete admin 23318 14. Feb 18:51 gkrellm_2015-02-14-185022_Leopard.crash -- Greetings Pete The best way to accelerate a PC is 9.8 m/s²
Hi Peter, Can you please help bisect a bit further? In the process of moving from 1.16.99.1_2 to 1.17.0_0, I made a two intermediate steps to help bisecting issues: 1.16.99.1_3 : http://trac.macports.org/changeset/132694 1.16.99.901_0 : http://trac.macports.org/changeset/132696 Please try those two out and report back. Thanks, Jeremy
On Feb 14, 2015, at 10:29, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Hello Jeremy and others!
When I today booted into Leopard and launched X11, it was the MacPorts package xorg-server-devel @1.17.1_0 that provided the X server. The clients looked different, instead of brown the window decoration was green. And gkrellm and GNU Emacs 23.4 died. The mouse cursor was invisible although X11 had the focus and therefore was easy to quit. I then activated xorg-server-devel @1.17.0_0. With the same results.
With xorg-server-devel @1.16.99.1_2 everything is OK.
I have crash logs:
-rw------- 1 pete admin 21182 14. Feb 19:02 emacs-23.4_2015-02-14-190207_Leopard.crash -rw------- 1 pete admin 23320 14. Feb 19:01 gkrellm_2015-02-14-190103_Leopard.crash -rw------- 1 pete admin 21180 14. Feb 18:56 emacs-23.4_2015-02-14-185620_Leopard.crash -rw------- 1 pete admin 23318 14. Feb 18:55 gkrellm_2015-02-14-185514_Leopard.crash -rw------- 1 pete admin 21180 14. Feb 18:51 emacs-23.4_2015-02-14-185108_Leopard.crash -rw------- 1 pete admin 23318 14. Feb 18:51 gkrellm_2015-02-14-185022_Leopard.crash
-- Greetings
Pete
The best way to accelerate a PC is 9.8 m/s²
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Am 14.02.2015 um 20:19 schrieb Jeremy Huddleston Sequoia:
Can you please help bisect a bit further?
What do you mean by that? Should I repeatedly build the ports leaving away one of the patches? -- Greetings Pete "Evolution" o __o _o _ °\___o /0~ -\<, ^\___ /=\\_/-% oo~_______ /\ /\______/ \_________O/ O_______________o===>-->O--o____
On Feb 15, 2015, at 4:18 PM, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 14.02.2015 um 20:19 schrieb Jeremy Huddleston Sequoia:
Can you please help bisect a bit further?
What do you mean by that? Should I repeatedly build the ports leaving away one of the patches?
He just meant to test with the two builds he linked to and report which is affected by the problem. (After that, he may ask you to test with yet more builds.) Regards, Ken
Am 15.02.2015 um 23:27 schrieb Ken Thomases:
He just meant to test with the two builds he linked to and report which is affected by the problem.
As I mentioned, with xorg-server-devel @1.16.99.1_2 everything is OK. The problems appear with both xorg-server-devel @1.17.0_0 and xorg-server-devel @1.17.1_0. -- Greetings Pete Behold the warranty … the bold print giveth and the fine print taketh away.
On Feb 15, 2015, at 4:50 PM, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 15.02.2015 um 23:27 schrieb Ken Thomases:
He just meant to test with the two builds he linked to and report which is affected by the problem.
As I mentioned, with xorg-server-devel @1.16.99.1_2 everything is OK. The problems appear with both xorg-server-devel @1.17.0_0 and xorg-server-devel @1.17.1_0.
He gave you links to 1.16.99.1_3 and 1.16.99.901_0 to test. Regards, Ken
Am 15.02.2015 um 23:54 schrieb Ken Thomases:
He gave you links to 1.16.99.1_3 and 1.16.99.901_0 to test.
Yes. What is the procedure or algorithm then to perform tests? Is it, as I imagined, to leave away this or that or another patch file from the build process or is it something different? Because I already built, installed, and used these packages. And they both were not working correctly. So it's obviously not proper to built them as they are. A second, or third, or fourth time. Something has to be modified, has to be performed differently. What? Or how? Another possibility that comes to my mind is to use modified patch files, freed off the patches applied to them when they were upgraded. -- Greetings Pete 0 %-/\_// (*)(*)
On Feb 16, 2015, at 08:27, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 15.02.2015 um 23:54 schrieb Ken Thomases:
He gave you links to 1.16.99.1_3 and 1.16.99.901_0 to test.
Yes. What is the procedure or algorithm then to perform tests? Is it, as I imagined, to leave away this or that or another patch file from the build process or is it something different? Because I already built, installed, and used these packages. And they both were not working correctly. So it's obviously not proper to built them as they are. A second, or third, or fourth time. Something has to be modified, has to be performed differently. What? Or how?
Another possibility that comes to my mind is to use modified patch files, freed off the patches applied to them when they were upgraded.
No, it's not at all likely to be one of the patches given that the set of patches didn't change between the versions that introduced the problem. Please install 1.16.99.1_3 and tell me if it has the problem you are seeing. Then install 1.16.99.901_0 and tell me if it has the problem you are seeing.
-- Greetings
Pete 0 %-/\_// (*)(*)
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Feb 16, 2015, at 11:49 AM, Jeremy Huddleston Sequoia <jeremyhu@apple.com> wrote:
On Feb 16, 2015, at 08:27, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 15.02.2015 um 23:54 schrieb Ken Thomases:
He gave you links to 1.16.99.1_3 and 1.16.99.901_0 to test.
Yes. What is the procedure or algorithm then to perform tests? Is it, as I imagined, to leave away this or that or another patch file from the build process or is it something different? Because I already built, installed, and used these packages. And they both were not working correctly. So it's obviously not proper to built them as they are. A second, or third, or fourth time. Something has to be modified, has to be performed differently. What? Or how?
Another possibility that comes to my mind is to use modified patch files, freed off the patches applied to them when they were upgraded.
No, it's not at all likely to be one of the patches given that the set of patches didn't change between the versions that introduced the problem.
Please install 1.16.99.1_3 and tell me if it has the problem you are seeing. Then install 1.16.99.901_0 and tell me if it has the problem you are seeing.
Actually, I have to apologize to Peter. I had thought your links went to ready-made builds, but they don't. So, the question is how do you expect him to install those versions. Are you suggesting, using MacPorts and doing: sudo port install xorg-server-devel @1.16.99.1_3 ? Regards, Ken
On Feb 16, 2015, at 11:35, Ken Thomases <ken@codeweavers.com> wrote:
On Feb 16, 2015, at 11:49 AM, Jeremy Huddleston Sequoia <jeremyhu@apple.com> wrote:
On Feb 16, 2015, at 08:27, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 15.02.2015 um 23:54 schrieb Ken Thomases:
He gave you links to 1.16.99.1_3 and 1.16.99.901_0 to test.
Yes. What is the procedure or algorithm then to perform tests? Is it, as I imagined, to leave away this or that or another patch file from the build process or is it something different? Because I already built, installed, and used these packages. And they both were not working correctly. So it's obviously not proper to built them as they are. A second, or third, or fourth time. Something has to be modified, has to be performed differently. What? Or how?
Another possibility that comes to my mind is to use modified patch files, freed off the patches applied to them when they were upgraded.
No, it's not at all likely to be one of the patches given that the set of patches didn't change between the versions that introduced the problem.
Please install 1.16.99.1_3 and tell me if it has the problem you are seeing. Then install 1.16.99.901_0 and tell me if it has the problem you are seeing.
Actually, I have to apologize to Peter. I had thought your links went to ready-made builds, but they don't. So, the question is how do you expect him to install those versions.
Are you suggesting, using MacPorts and doing:
sudo port install xorg-server-devel @1.16.99.1_3
Peter, you'll need to use 'svn update -r' to choose the revision to test. For example: ~/src/macports/dports/x11/xorg-server-devel $ svn update -r 132696 Updating '.': U files/5002-Use-old-miTrapezoids-and-miTriangles-routines.patch U files/5003-fb-Revert-fb-changes-that-broke-XQuartz.patch U files/5004-fb-Revert-fb-changes-that-broke-XQuartz.patch U files/5000-sdksyms.sh-Use-CPPFLAGS-not-CFLAGS.patch U files/5001-Workaround-the-GC-clipping-problem-in-miPaintWindow-.patch U Portfile Updated to revision 132696. --Jeremy
Am 16.02.2015 um 21:16 schrieb Jeremy Huddleston Sequoia:
Are you suggesting, using MacPorts and doing:
sudo port install xorg-server-devel @1.16.99.1_3
Peter, you'll need to use 'svn update -r' to choose the revision to test. For example:
~/src/macports/dports/x11/xorg-server-devel $ svn update -r 132696 Updating '.': U files/5002-Use-old-miTrapezoids-and-miTriangles-routines.patch U files/5003-fb-Revert-fb-changes-that-broke-XQuartz.patch U files/5004-fb-Revert-fb-changes-that-broke-XQuartz.patch U files/5000-sdksyms.sh-Use-CPPFLAGS-not-CFLAGS.patch U files/5001-Workaround-the-GC-clipping-problem-in- miPaintWindow-.patch U Portfile Updated to revision 132696.
I actually do not understand what this command performs (looks like it does nothing) and how it can lead to building xorg-server-devel @1.16.99.1_3… And in my home directory I don't have a subdirectory src/ macports/dports/x11/xorg-server-devel. I don't want to build some X server that installs somewhere on my PowerBook G4 and can't be uninstalled. So I decided to fetch from http://trac.macports.org/changeset/132694 the corresponding Portfile, "install" it in /opt/local/var/ macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ ports/x11/xorg-server-devel, and see whether port can handle this. It can't, out of a good reason: there does not seem to exist an archive for the xorg-server(-devel) 1.16.99.1 sources. How can I get these? -- Greetings Pete I love deadlines. I love the whooshing noise they make as they go by. – Douglas Adams
On Feb 17, 2015, at 15:00, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 16.02.2015 um 21:16 schrieb Jeremy Huddleston Sequoia:
Are you suggesting, using MacPorts and doing:
sudo port install xorg-server-devel @1.16.99.1_3
Peter, you'll need to use 'svn update -r' to choose the revision to test. For example:
~/src/macports/dports/x11/xorg-server-devel $ svn update -r 132696 Updating '.': U files/5002-Use-old-miTrapezoids-and-miTriangles-routines.patch U files/5003-fb-Revert-fb-changes-that-broke-XQuartz.patch U files/5004-fb-Revert-fb-changes-that-broke-XQuartz.patch U files/5000-sdksyms.sh-Use-CPPFLAGS-not-CFLAGS.patch U files/5001-Workaround-the-GC-clipping-problem-in-miPaintWindow-.patch U Portfile Updated to revision 132696.
I actually do not understand what this command performs (looks like it does nothing)
It updates your svn checkout to the specified svn revision. In this case, r132696, which would provide 1.16.99.901_0.
and how it can lead to building xorg-server-devel @1.16.99.1_3… And in my home directory I don't have a subdirectory src/macports/dports/x11/xorg-server-devel.
Yes, I don't know where you have your dports checkout. That is where I have mine. You would need to do that wherever you have your svn checkout of dports.
I don't want to build some X server that installs somewhere on my PowerBook G4 and can't be uninstalled. So I decided to fetch from http://trac.macports.org/changeset/132694 the corresponding Portfile, "install" it in /opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/x11/xorg-server-devel, and see whether port can handle this. It can't, out of a good reason: there does not seem to exist an archive for the xorg-server(-devel) 1.16.99.1 sources. How can I get these?
There is an archive for the sources, but we don't use that. We use git for the xorg-server-devel port. Assuming you put the correct Portfile in place, you would also need to put the correct patches in place. However, it looks like you're using tarballs for dports. I suggest that you use subversion instead. See https://guide.macports.org/#installing.macports.subversion For example, do this: mkdir ~/src cd ~/src svn co https://svn.macports.org/repository/macports/trunk/dports cd dports portindex Then edit /opt/local/etc/macports/sources.conf to contain something like this instead of the existing line: file:///Users/pete/src/dports [default] Then to update xorg-server-devel to r132696, just do: cd ~/src/dports/x11/xorg-server-devel svn update -r 132696 --Jeremy
-- Greetings
Pete
I love deadlines. I love the whooshing noise they make as they go by. – Douglas Adams
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Am 19.02.2015 um 01:19 schrieb Jeremy Huddleston Sequoia:
For example, do this: mkdir ~/src cd ~/src svn co https://svn.macports.org/repository/macports/trunk/dports cd dports portindex
Possibly I made a mistake in not invoking portindex… After checking out the software I built and installed port from the sources, and then ran 'port selfupdate' to let port upgrade all outdated packages because it likes to upgrades those outdated packages first that don't compile. The first times the selfupdate command ran for hours, so I killed it when it was time to go to bed. Then I assumed that the svn checkout could have been incomplete or such, so I performed it again. Finally I let port selfupdate over-night. This time it finished after *six* hours! Well, it is almost one second for each package. Maybe this is a sensible time for a Tcl script… Some hours ago the obviously finished upgrade of Clang 3.3 or 3.4 had produced a tclsh failure. After checking my PowerBook G4 I restarted now the upgrade process… and am confident that next month I can – hopefully – offer some results. -- Greetings Pete Ce qui a été compris n'existe plus. (Paul Eluard)
Am 16.02.2015 um 18:49 schrieb Jeremy Huddleston Sequoia:
Please install 1.16.99.1_3 and tell me if it has the problem you are seeing.
Hello Jeremy! First result: 1.16.99.1₃ already shows the faulty colours and lets GNU Emacs 24.3 and gkrellm crash. Maybe I can start next try in 1.16.99.901_0 20 hours! -- Greetings Pete I consider religion godesque.
On Mar 7, 2015, at 12:16, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 16.02.2015 um 18:49 schrieb Jeremy Huddleston Sequoia:
Please install 1.16.99.1_3 and tell me if it has the problem you are seeing.
Hello Jeremy!
First result: 1.16.99.1₃ already shows the faulty colours and lets GNU Emacs 24.3 and gkrellm crash.
Maybe I can start next try in 1.16.99.901_0 20 hours!
No need for that. You said 1.16.99.1_2 doesn't have the issue and 1.16.99.1_3 does, so it was introduced somewhere between 1.16.99.1_2 and 1.16.99.1_3. That means it was something between: git commits cff12936275db2f71f6d24f9ea0985a0d14af454 and e572bcc7f4236b7e0f23ab762f225b3bce37db59 If you are not comfortable building from a git checkout, I suggest you stay at the 1.16.99.1_3 checkout and bisect between those to git commits by editing the git.branch line of the Portfile to figure out what commit introduced the issue. You can do something like: git clone ssh://git.freedesktop.org/git/xorg/xserver.git cd xserver git bisect start git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59 git bisect good cff12936275db2f71f6d24f9ea0985a0d14af454 It will then report something like this: Bisecting: 169 revisions left to test after this (roughly 8 steps) [35dc7c75150733dbcef8a18b6796f49a7c48ebee] Merge branch 'modesetting-import' into master So try 35dc7c75150733dbcef8a18b6796f49a7c48ebee and then run 'git bisect good' or 'git bisect bad' as appropriate and try the next one until you've determined what commit introduced the problem. --Jeremy
-- Greetings
Pete
I consider religion godesque.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Am 07.03.2015 um 23:04 schrieb Jeremy Huddleston Sequoia:
You can do something like:
git clone ssh://git.freedesktop.org/git/xorg/xserver.git
Hello Jeremy! There is something wrong! Whenever I try this command, no matter which account from, I get approximately: Warning: Permanently added 'git.freedesktop.org,131.252.210.178' (RSA) to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Do I need some special account? I have one on https://bugs.freedesktop.org from 2008… And what happens after cloning the X server? How does it get built and installed? -- Greetings Pete The light at the end of the tunnel has been turned off due to budget cuts.
On Mar 9, 2015, at 14:12, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 07.03.2015 um 23:04 schrieb Jeremy Huddleston Sequoia:
You can do something like:
git clone ssh://git.freedesktop.org/git/xorg/xserver.git
Hello Jeremy!
There is something wrong! Whenever I try this command, no matter which account from, I get approximately:
Warning: Permanently added 'git.freedesktop.org,131.252.210.178' (RSA) to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Do I need some special account? I have one on https://bugs.freedesktop.org from 2008…
Sorry, use the public one: git://people.freedesktop.org/~jeremyhu/xserver
And what happens after cloning the X server? How does it get built and installed?
If you can't figure out how to build it from the checkout, just use the Portfile per my instructions in a previous email ... just using the checkout to figure out what commit to test next. --Jeremy
-- Greetings
Pete
The light at the end of the tunnel has been turned off due to budget cuts.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Am 10.03.2015 um 04:36 schrieb Jeremy Huddleston Sequoia:
git://people.freedesktop.org/~jeremyhu/xserver
This URI worked fine. I then tried to use your compile from five years ago to build the X server. With some small changes (for example to build a pure PPC binary, updated paths to find modern xorg-macros) it could build the X server, for which I also had to rename /usr/sbin/dtrace because LD was not able to handle the DOF (?) section or table. I then invoked 'make install', but this installed X server does seem to launch.
And what happens after cloning the X server? How does it get built and installed?
If you can't figure out how to build it from the checkout, just use the Portfile per my instructions in a previous email ... just using the checkout to figure out what commit to test next.
I am not able to determine which instructions you mean. Could you give me the date of sending or could you copy an paste them? -- Greetings Pete "I'm a rabid typist."
On Mar 14, 2015, at 14:08, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 10.03.2015 um 04:36 schrieb Jeremy Huddleston Sequoia:
git://people.freedesktop.org/~jeremyhu/xserver
This URI worked fine. I then tried to use your compile from five years ago to build the X server. With some small changes (for example to build a pure PPC binary, updated paths to find modern xorg-macros) it could build the X server, for which I also had to rename /usr/sbin/dtrace because LD was not able to handle the DOF (?) section or table. I then invoked 'make install', but this installed X server does seem to launch.
And what happens after cloning the X server? How does it get built and installed?
If you can't figure out how to build it from the checkout, just use the Portfile per my instructions in a previous email ... just using the checkout to figure out what commit to test next.
I am not able to determine which instructions you mean. Could you give me the date of sending or could you copy an paste them?
Here they are reposted: That means it was something between: git commits cff12936275db2f71f6d24f9ea0985a0d14af454 and e572bcc7f4236b7e0f23ab762f225b3bce37db59 If you are not comfortable building from a git checkout, I suggest you stay at the 1.16.99.1_3 checkout and bisect between those to git commits by editing the git.branch line of the Portfile to figure out what commit introduced the issue. You can do something like: git clone ssh://git.freedesktop.org/git/xorg/xserver.git cd xserver git bisect start git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59 git bisect good cff12936275db2f71f6d24f9ea0985a0d14af454 It will then report something like this: Bisecting: 169 revisions left to test after this (roughly 8 steps) [35dc7c75150733dbcef8a18b6796f49a7c48ebee] Merge branch 'modesetting-import' into master So try 35dc7c75150733dbcef8a18b6796f49a7c48ebee and then run 'git bisect good' or 'git bisect bad' as appropriate and try the next one until you've determined what commit introduced the problem. --Jeremy
On Mar 9, 2015, at 14:12, Peter Dyballa <Peter_Dyballa@Web.DE> wrote:
Am 07.03.2015 um 23:04 schrieb Jeremy Huddleston Sequoia:
You can do something like:
git clone ssh://git.freedesktop.org/git/xorg/xserver.git
Hello Jeremy!
There is something wrong! Whenever I try this command, no matter which account from, I get approximately:
Warning: Permanently added 'git.freedesktop.org,131.252.210.178' (RSA) to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Do I need some special account? I have one on https://bugs.freedesktop.org from 2008…
Sorry, use the public one: git://people.freedesktop.org/~jeremyhu/xserver
And what happens after cloning the X server? How does it get built and installed?
If you can't figure out how to build it from the checkout, just use the Portfile per my instructions in a previous email ... just using the checkout to figure out what commit to test next. --Jeremy
-- Greetings
Pete
The light at the end of the tunnel has been turned off due to budget cuts.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
participants (5)
-
Jeremy Huddleston Sequoia
-
Jeremy Huddleston Sequoia
-
Ken Thomases
-
Peter Dyballa
-
Peter Dyballa