Ok, I have a new version up that should take care of all it issues now. http://people.freedesktop.org/~jeremyhu/X11-2.1.0.pkg The only thing I'm not sure about is the postinst script. I'm not sure that it's being done correctly. Can someone tell me how to verify if the postinst script is being run? It should be doing: /bin/launchctl load -w /System/Library/LaunchAgents/ org.x.fontconfig.plist /usr/bin/Rez -a -o /usr/X11/bin/Xquartz AddPlist.r with AddPlist.r and Xquartz.plist in the scripts directory. --Jeremy
Am 02.12.2007 um 07:58 schrieb Jeremy Huddleston:
Ok, I have a new version up that should take care of all it issues now. http://people.freedesktop.org/~jeremyhu/X11-2.1.0.pkg
The only thing I'm not sure about is the postinst script. I'm not sure that it's being done correctly. Can someone tell me how to verify if the postinst script is being run? It should be doing:
I've just installed X11.pkg and got an error message about running the postinstall script.
/bin/launchctl load -w /System/Library/LaunchAgents/ org.x.fontconfig.plist /usr/bin/Rez -a -o /usr/X11/bin/Xquartz AddPlist.r
with AddPlist.r and Xquartz.plist in the scripts directory.
Is there any way I can do this in Terminal right after the installation routine fails? Simone -- in the arms of your angel, you may find some comfort here.
Jeremy, I'm still seeing some incorrect ownerships on the updated files. A philosophical question: Since it appears that only some of the files are changing compared to the standard Leopard X11, do we want to include only those that have changed, or an entire complete/self-contained X11 install? I don't think I have a preference either way. Here a non-philosophical question: Will this work to overwrite the X11 install for those that down-revved to Tiger's X11? Or should the install detect that and deal with it in a pre-install script? Or should it detect it and ask that Leopard's X11 be installed first to cleanup? I don't have any way to test this situation. The ownership on the following files should be root:admin (0/80) not 501/20 /Applications/Utilities/X11.app/Contents/Info.plist /Applications/Utilities/X11.app/Contents/MacOS/X11 /Applications/Utilities/X11.app/Contents/PkgInfo /Applications/Utilities/X11.app/Contents/Resources/Info.plist /Applications/Utilities/X11.app/Contents/Resources/X11.icns The ownership of the following file should be root:wheel (0/0) not 501/20 /usr/X11/X11.app/Contents/Info.plist /usr/X11/X11.app/Contents/MacOS/X11 /usr/X11/X11.app/Contents/PkgInfo /usr/X11/X11.app/Contents/Resources/English.lproj/InfoPlist.strings /usr/X11/X11.app/Contents/Resources/English.lproj/Localizable.strings /usr/X11/X11.app/Contents/Resources/English.lproj/main.nib/classes.nib /usr/X11/X11.app/Contents/Resources/English.lproj/main.nib/info.nib /usr/X11/X11.app/Contents/Resources/English.lproj/main.nib/ keyedobjects.nib /usr/X11/X11.app/Contents/Resources/Info.plist /usr/X11/X11.app/Contents/Resources/X11.icns /usr/X11/lib/pkgconfig/xorg-server.pc /usr/X11/man/man1/Xquartz.1 /usr/X11/man/man1/Xserver.1 You can change these in a couple of ways: 1) do a chown on the files you are including in the package 2) In the 'Contents' pane when the included folders are highlighted, set the individual ownerships of the files that are wrong. (I don't think you have to set the 'Overwrite Directory Permissions' for this to be effective). You can double-check things are right after you've built the package with the following command: lsbom `pkgutil --bom <package_file>` The output will be a lot of lines with each showing filename, permission bits in octal, UID/GID, file size, 32-bit CRC checksum If it's a symbolic link, you see the link target after the checksum. Finally, it looks to me like the postinstall script is firing. Running DeRez on the final /usr/X11/bin/Xquartz file shows the resource fork is there. As a side note, Rez only gets installed if the Xcode Developer Tools are installed. If they're not installed, then I would expect Installer to throw an error when running the postinstall script. This might be the cause of the error that that one person saw. Should we look for the Developer Tools in the Install Check and abort with a good error message if they are not present before installing? Another way around that would be for you to include the resource fork in Xquartz prior to building the package. As long as the 'Discard Resource Forks' is not checked in the Package Flags, that should work. Merle On Dec 2, 2007, at 1:58 AM, Jeremy Huddleston wrote:
Ok, I have a new version up that should take care of all it issues now. http://people.freedesktop.org/~jeremyhu/X11-2.1.0.pkg
The only thing I'm not sure about is the postinst script. I'm not sure that it's being done correctly. Can someone tell me how to verify if the postinst script is being run? It should be doing:
/bin/launchctl load -w /System/Library/LaunchAgents/ org.x.fontconfig.plist /usr/bin/Rez -a -o /usr/X11/bin/Xquartz AddPlist.r
with AddPlist.r and Xquartz.plist in the scripts directory.
--Jeremy
On Dec 2, 2007, at 07:42, Merle Reinhart wrote:
Jeremy,
I'm still seeing some incorrect ownerships on the updated files.
I have no idea why this is happening... see below.
A philosophical question: Since it appears that only some of the files are changing compared to the standard Leopard X11, do we want to include only those that have changed, or an entire complete/self-contained X11 install? I don't think I have a preference either way.
We're just including changed and missing files.
Here a non-philosophical question: Will this work to overwrite the X11 install for those that down-revved to Tiger's X11? Or should the install detect that and deal with it in a pre-install script?
I setup an install requirement that checks for /usr/X11/bin/Xquartz. So in theory, it should fail if they uninstalled or never installed Leopard's X11.
You can change these in a couple of ways: 1) do a chown on the files you are including in the package
Yeah, that's what I did
2) In the 'Contents' pane when the included folders are highlighted, set the individual ownerships of the files that are wrong. (I don't think you have to set the 'Overwrite Directory Permissions' for this to be effective).
They are all root:wheel. I'll change the ones that should be root:admin to root:admin, but I show them all as root:wheel
You can double-check things are right after you've built the package with the following command: lsbom `pkgutil --bom <package_file>`
I see the 501/20 there. Why the heck is it doing that? Is this a PackageMaker.app bug? I even deleted the target and readded it to make sure it got the new ownerships.
Finally, it looks to me like the postinstall script is firing. Running DeRez on the final /usr/X11/bin/Xquartz file shows the resource fork is there.
As a side note, Rez only gets installed if the Xcode Developer Tools are installed. If they're not installed, then I would expect Installer to throw an error when running the postinstall script. This might be the cause of the error that that one person saw. Should we look for the Developer Tools in the Install Check and abort with a good error message if they are not present before installing? Another way around that would be for you to include the resource fork in Xquartz prior to building the package. As long as the 'Discard Resource Forks' is not checked in the Package Flags, that should work.
Ok, I'll try that then. Thanks for your help, Jeremy
Jeremy, I know with the Tiger PackageMaker, I always made sure they were correct in my tree, then I didn't have do diddle with them internally in the tool. For those packages, I also set the 'overwrite directory permissions', but only after make doubly sure that I actually had all there perms/owners correct in my tree from the root down. I just threw together a quick package from a directory where the ownerships of the files were 501/501. I then change the ownerships via the 'Content' tab and the 'Apply Recommendations' tab to root/ wheel and the BOM came out interestingly. The top directory of the tree was 0/0 as expected, but the group of all the contained files was admin (80). So, it looks like you may have to change all the files independently (in my test case, they all came out correctly (0/0)). However, when I set the owners on the files and did not try and set them in the too, they came out wrong (should have been 0/0 everywhere, but were 0/80 instead). So, there might be some bugs in PackageMaker that have to be worked around (or we just haven't figured out where the critical switches are yet). When I set all the owners on the files individually via the PackageMaker tool, then the BOM comes out as expected. From these simple tests, it looks like one may have to set the owners/ perms via the Tool for each file individually (which can be a really pain for packages that have hundreds of files) to get things to come out correctly. Other than that, I'm not sure what to suggest. I'll start putting together Leopard packages for some of my stuff and see if I can find any revelations. Merle On Dec 2, 2007, at 2:23 PM, Jeremy Huddleston wrote:
On Dec 2, 2007, at 07:42, Merle Reinhart wrote:
Jeremy,
I'm still seeing some incorrect ownerships on the updated files.
I have no idea why this is happening... see below.
A philosophical question: Since it appears that only some of the files are changing compared to the standard Leopard X11, do we want to include only those that have changed, or an entire complete/self-contained X11 install? I don't think I have a preference either way.
We're just including changed and missing files.
Here a non-philosophical question: Will this work to overwrite the X11 install for those that down-revved to Tiger's X11? Or should the install detect that and deal with it in a pre-install script?
I setup an install requirement that checks for /usr/X11/bin/ Xquartz. So in theory, it should fail if they uninstalled or never installed Leopard's X11.
You can change these in a couple of ways: 1) do a chown on the files you are including in the package
Yeah, that's what I did
2) In the 'Contents' pane when the included folders are highlighted, set the individual ownerships of the files that are wrong. (I don't think you have to set the 'Overwrite Directory Permissions' for this to be effective).
They are all root:wheel. I'll change the ones that should be root:admin to root:admin, but I show them all as root:wheel
You can double-check things are right after you've built the package with the following command: lsbom `pkgutil --bom <package_file>`
I see the 501/20 there. Why the heck is it doing that? Is this a PackageMaker.app bug? I even deleted the target and readded it to make sure it got the new ownerships.
Finally, it looks to me like the postinstall script is firing. Running DeRez on the final /usr/X11/bin/Xquartz file shows the resource fork is there.
As a side note, Rez only gets installed if the Xcode Developer Tools are installed. If they're not installed, then I would expect Installer to throw an error when running the postinstall script. This might be the cause of the error that that one person saw. Should we look for the Developer Tools in the Install Check and abort with a good error message if they are not present before installing? Another way around that would be for you to include the resource fork in Xquartz prior to building the package. As long as the 'Discard Resource Forks' is not checked in the Package Flags, that should work.
Ok, I'll try that then.
Thanks for your help, Jeremy
Ok, The X11-2.1.0 package is available on the site now: http://trac.macosforge.org/projects/xquartz/wiki/Releases Thanks to everyone for testing and helping out. I fixed the few issues that came up. If there is anything else you find with the package, please file a bug on our bug tracker and assign it to the 'X11.pkg' (issues with the actual software should be assigned to xserver, x11-libs, or x11-apps) Regarding the reported isues: File permissions: PackageMaker.app has a feature "Apply Suggestions" or something to that effect which replaces file permissions in the package with what they are on your installed system if that file exists. It seems that this is *always* done whether you hit the button or not. So I changed my permissions on my installed system and it worked... Hopefully knowing this will save one of you the headache I just had... /shrug I also decided to just to the Rez if the user has Rez installed and skip it otherwise. I also included Xnest and Xvfb for now until we make sure Xephyr and Xfake are regression free over them. --Jeremy On Dec 2, 2007, at 07:42, Merle Reinhart wrote:
Jeremy,
I'm still seeing some incorrect ownerships on the updated files.
A philosophical question: Since it appears that only some of the files are changing compared to the standard Leopard X11, do we want to include only those that have changed, or an entire complete/self-contained X11 install? I don't think I have a preference either way.
Here a non-philosophical question: Will this work to overwrite the X11 install for those that down-revved to Tiger's X11? Or should the install detect that and deal with it in a pre-install script? Or should it detect it and ask that Leopard's X11 be installed first to cleanup? I don't have any way to test this situation.
The ownership on the following files should be root:admin (0/80) not 501/20
/Applications/Utilities/X11.app/Contents/Info.plist /Applications/Utilities/X11.app/Contents/MacOS/X11 /Applications/Utilities/X11.app/Contents/PkgInfo /Applications/Utilities/X11.app/Contents/Resources/Info.plist /Applications/Utilities/X11.app/Contents/Resources/X11.icns
The ownership of the following file should be root:wheel (0/0) not 501/20 /usr/X11/X11.app/Contents/Info.plist /usr/X11/X11.app/Contents/MacOS/X11 /usr/X11/X11.app/Contents/PkgInfo /usr/X11/X11.app/Contents/Resources/English.lproj/InfoPlist.strings /usr/X11/X11.app/Contents/Resources/English.lproj/Localizable.strings /usr/X11/X11.app/Contents/Resources/English.lproj/main.nib/classes.nib /usr/X11/X11.app/Contents/Resources/English.lproj/main.nib/info.nib /usr/X11/X11.app/Contents/Resources/English.lproj/main.nib/ keyedobjects.nib /usr/X11/X11.app/Contents/Resources/Info.plist /usr/X11/X11.app/Contents/Resources/X11.icns /usr/X11/lib/pkgconfig/xorg-server.pc /usr/X11/man/man1/Xquartz.1 /usr/X11/man/man1/Xserver.1
You can change these in a couple of ways: 1) do a chown on the files you are including in the package 2) In the 'Contents' pane when the included folders are highlighted, set the individual ownerships of the files that are wrong. (I don't think you have to set the 'Overwrite Directory Permissions' for this to be effective). You can double-check things are right after you've built the package with the following command: lsbom `pkgutil --bom <package_file>` The output will be a lot of lines with each showing filename, permission bits in octal, UID/GID, file size, 32-bit CRC checksum If it's a symbolic link, you see the link target after the checksum.
Finally, it looks to me like the postinstall script is firing. Running DeRez on the final /usr/X11/bin/Xquartz file shows the resource fork is there.
As a side note, Rez only gets installed if the Xcode Developer Tools are installed. If they're not installed, then I would expect Installer to throw an error when running the postinstall script. This might be the cause of the error that that one person saw. Should we look for the Developer Tools in the Install Check and abort with a good error message if they are not present before installing? Another way around that would be for you to include the resource fork in Xquartz prior to building the package. As long as the 'Discard Resource Forks' is not checked in the Package Flags, that should work.
Merle
On Dec 2, 2007, at 1:58 AM, Jeremy Huddleston wrote:
Ok, I have a new version up that should take care of all it issues now. http://people.freedesktop.org/~jeremyhu/X11-2.1.0.pkg
The only thing I'm not sure about is the postinst script. I'm not sure that it's being done correctly. Can someone tell me how to verify if the postinst script is being run? It should be doing:
/bin/launchctl load -w /System/Library/LaunchAgents/ org.x.fontconfig.plist /usr/bin/Rez -a -o /usr/X11/bin/Xquartz AddPlist.r
with AddPlist.r and Xquartz.plist in the scripts directory.
--Jeremy
participants (3)
-
Jeremy Huddleston
-
Merle Reinhart
-
Simone Karin Lehmann