Voodooprojects

Chameleon => DevTalk => Patches => Topic started by: zef on July 26, 2010, 12:53:52 PM

Title: Revisit Chameleon's package builder
Post by: zef on July 26, 2010, 12:53:52 PM
Hola People!

I started this topic to discuss the ongoing issues regarding the old-timer "make pkg" function. I saw iFabio sent updated language translations @IM, thanks Blackosx for commiting those changes to trunk. This part of the project is a grey area, but considering the amount of quality changes made for the booter recently, I think the pkg building also needs bandages, polishment and painkillers.

These are the four topics what i was thinking of (feel free to extend/modify):

- Revisit/update the tools what the resulting pkg contains, like fdisk440, etc (rals2007 noticed that).
- Revisit/update the bundled extensions. For example using the PIIXATA injector gives me a KP under vmware under Snow Leopard, but the VMware supplied LegacyPIIXATA injector doesn't. Then how about adding Mozo's FakeSMC.kext?
- Make the package 10.5/10.6 compatible. We could use Chameleon's ability to throw all kexts under /Extra/10.x/Extensions making the boot partition more universal.
- Review the inner workings and adjust/fix if needed - i have no doubt about that we need ;)

Thanks for reading!

Bye,
zef

PS: Waiting for reply :)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on July 26, 2010, 01:27:00 PM
Just some quick thoughts here, but yeah.. the fdisk440 needs adding.
I wonder if it should write boot0 or boot0hfs as standard?

For installing extensions... There are so many variations of who needs what that you can't possibly cover all the bases.. I would vote on maybe only adding the FakeSMC.kext. And many people still use 10.5 so that would need to be considered.

But a new package installer would definitely be a major plus for many out there.
Title: Re: Revisit Chameleon's package builder
Post by: Terc on July 26, 2010, 06:50:38 PM
This sounds like a good thing to look at.  Maybe this is for another thread, but can anyone explain when graphicsenabler isn't enabled by default (requiring the user to add a string in the boot.plist to disable it instead? I think it makes sense to enable if possible, unless the user doesn't want to for some reason (multiple graphics cards?).

Anyway, I think that focusing on making things as simple as possible for end users is a good goal for the installer.

Oh, and one for idea.  What about adding the readme/documentation link in the Extra folder?  Also, possibly installing Lizard.app as an option might be nice.

Adding legacy kexts still makes sense, and fakesmc as well.  But I think for the remaining kexts, if we can get them booting, that's probably where things should stop.
Title: Re: Revisit Chameleon's package builder
Post by: Lord Anubis on July 27, 2010, 02:04:53 PM
For installing extensions... There are so many variations of who needs what that you can't possibly cover all the bases.

But a new package installer would definitely be a major plus for many out there.

I hope the extensions will be well documented inside the installer when selected.
Also I hope that there will be a connection with the Cartri Bios for many GB mobo owners out there.
F.e when CartriBios selected it installs only the needed files etc.

And a kind of repair action when people damage their bootsectors etc
Title: Re: Revisit Chameleon's package builder
Post by: Kabyl on July 27, 2010, 02:42:43 PM
Also I hope that there will be a connection with the Cartri Bios for many GB mobo owners out there.
F.e when CartriBios selected it installs only the needed files etc.
I'm not sure I understand what you mean (?)

Quote
And a kind of repair action when people damage their bootsectors etc
There is nothing to repair, but reinstall the bootsector.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on July 27, 2010, 04:00:49 PM
In my opinion it's important to install:
fdisk440
Chameleon
Doc folder
FakeSMC.kext
PreferencePanels
Utilities (Kext Utility & IaslMe if they are OpenSource why not keep them in the repo?)

For Legacy kext (maybe optional in the pkg) I know smith@@ have done a "universal" legacy kext with all the various kext he found that could be included.
I think that having the c.a.B.p options in the installer could be confusing for new users, instead of using the PreferencePanel that is more simple.

I have made, with the help of iFabio a incomplete pakagebuilder template, but we need some help in the scripts part because it's a new world for us :)
It need to be copied in the /trunk/package folder.
 
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 05, 2010, 05:12:35 PM
I've edited the previously posted package builder project to have more boot options.
It's called ChameleoPlus because I've added more options for install like:
-Kext
Installs the kexts in the trunk

-Utility
PrefPanel
IaslMe
IORegistryExplorer
Kext Helper

-Auto bin patch for AppleHDA (from an idea by smith@@)
ALC662
ALC883
ALC888
ALC889
ALC AD2000B

-Motherboard specific files
Zotac GF9300 WiFI
Asus P5KR (P5K & P5KC if crossflashed to P5KR BIOS)
Asus P5K-E WiFi

All the project need to be in the package folder of the trunk.
All the localized file are now embedded ti avoid %CHAMELEONVERSION% (but it requires to manually update each revision)
File added to /package:
/chameleon/trunk/package/fdisk440

/chameleon/trunk/package/MoBo (Extra folder and S/L/E needed kext for the board I've install file)

/chameleon/trunk/package/Other
/chameleon/trunk/package/Other/AppleHDA     (AppleHDA binpatch scripts)
/chameleon/trunk/package/Other/Chameleon.prefPane
/chameleon/trunk/package/Other/iASLMe.app
/chameleon/trunk/package/Other/IORegistryExplorer.app
/chameleon/trunk/package/Other/Kext Utility.app

Scripts used by installer:
/chameleon/trunk/package/Scripts/PackageScripts
/chameleon/trunk/package/Scripts/PackageScripts/boot0_install
/chameleon/trunk/package/Scripts/PackageScripts/boot0hfs_install
/chameleon/trunk/package/Scripts/PackageScripts/boot1h_install
/chameleon/trunk/package/Scripts/PackageScripts/delete_temp
/chameleon/trunk/package/Scripts/PackageScripts/postinstall

DONE:

- Revisit/update the tools what the resulting pkg contains, like fdisk440, etc (rals2007 noticed that).

TO DO:
- Revisit/update the bundled extensions. For example using the PIIXATA injector gives me a KP under vmware under Snow Leopard, but the VMware supplied LegacyPIIXATA injector doesn't. Then how about adding Mozo's FakeSMC.kext?

- Make the package 10.5/10.6 compatible.  (not already tested on 10.5, need feedback)
- Review the inner workings and adjust/fix if needed (make choice for boot0 AppleHDA and MoBo not multiple and add a way to automatically update welcome and conclusion file with v%CHAMELEONVERSION% r%CHAMELEONREVISION% %CHAMELEONSTAGE% )
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 05, 2010, 11:43:35 PM
Hi scrax

Thanks for posting everything here and it gives an interesting combination of files and a great platform to build upon and I guess we'll have to see which direction the Chameleon team want to take it. I think inclusion of the docs in beneficial though I think it's time we updated them.

I love the auto bin patch for AppleHDA, the utilities are useful for those who don't have them, but whether or not it should include motherboard specific files is another question.

Great job  ;D
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 06, 2010, 12:39:08 AM
Yes, mobo it's really not indicated for the official chameleon installer.
I've posted what I have made just to show my idea.
I'm learning how to use the command line with packagemaker to make a script that downloads latest build from svn and builds the relative installer...
here the console command:
Code: [Select]
svn co -r HEAD http://forge.voodooprojects.org/svn/chameleon ; cd  ~/chameleon/trunk; make clean ; make ;
/Developer/usr/bin/packagemaker -d ~/chameleon/trunk/package/ChameleonPlus.pmdoc
For the official installer I suggest it need to do:

Install Chameleon on selected volume (no RAID for now)
/boot
boot0hfs (boot0 optional)
boot1

Example file (with all the options set as the defaults ones Chameleon use)
/Extra/smbios.plist
/Extra/com.apple.Boot.plist

Documentation
/Extra/Doc

PrefPanel
/Library/PreferencePanels/Chameleon.PrefPanel

Kext (All In /Extra/Extensions/10.x):
 10.5
FakeSMC (2.5 without verbose)
LegacyXXXX (I have no idea here)
 10.6
FakeSMC (Mozodojo without Plugins)
LegacyXXXX (I have no idea here)

Utility (optional)
bdmesg    (where? bin folder?)
fdisk440   (where? bin folder?)
lspci         (bin folder)
/Extra/Utility/KextUtility
/Extra/Utility/Lizard
/Extra/Utility/IaslMe
/Extra/Utility/AppleHDApatcher2

The kexts needs to be generic, so maybe:
EvOReboot.kext
LegacyATA.kext
...no more ideas for now :)
...maybe a Graphics Enabler Options

Attached Updated to r496

EDIT: Attached also an example not yet tested
(http://forum.voodooprojects.org/index.php?action=dlattach;topic=1521.0;attach=1503;image)
the flowers are for single choices options
Title: Re: Revisit Chameleon's package builder
Post by: smith@@ on September 06, 2010, 07:34:32 AM
No good for simple chameleon install, not should be these the guidelines ;)


btw the alcpatch was my idea here: http://www.insanelymac.com/forum/index.php?showtopic=231104

not only for binary..

and here my definitely legacy:
Title: Re: Revisit Chameleon's package builder
Post by: Kabyl on September 06, 2010, 09:21:48 AM
Yes, mobo it's really not indicated for the official chameleon installer.
I've posted what I have made just to show my idea.
I'm learning how to use the command line with packagemaker to make a script that downloads latest build from svn and builds the relative installer...
here the console command:
Code: [Select]
svn co -r HEAD http://forge.voodooprojects.org/svn/chameleon ; cd  ~/chameleon/trunk; make clean ; make ;
/Developer/usr/bin/packagemaker -d ~/chameleon/trunk/package/ChameleonPlus.pmdoc
Get only what you need, "trunk".
Code: [Select]
svn co http://forge.voodooprojects.org/svn/chameleon/trunk
Quote
For the official installer I suggest it need to do:

Install Chameleon on selected volume (no RAID for now)
/boot
boot0hfs (boot0 optional)
boot1

Example file (with all the options set as the defaults ones Chameleon use)
/Extra/smbios.plist
/Extra/com.apple.Boot.plist

Documentation
/Extra/Doc
I don't think docs. should go in there, maybe in the User's "Documents" folder?

Quote
PrefPanel
/Library/PreferencePanels/Chameleon.PrefPanel

Kext (All In /Extra/Extensions/10.x):
 10.5
FakeSMC (2.5 without verbose)
LegacyXXXX (I have no idea here)
 10.6
FakeSMC (Mozodojo without Plugins)
LegacyXXXX (I have no idea here)
Why do you people still call them "legacy" kexts? the original kext that used that name was to add support for old ICH chips.

Quote
Utility (optional)
bdmesg    (where? bin folder?)
fdisk440   (where? bin folder?)
lspci         (bin folder)
/Extra/Utility/KextUtility
/Extra/Utility/Lizard
/Extra/Utility/IaslMe
/Extra/Utility/AppleHDApatcher2
Same here, I don't think these should go under /Extra/Utility, actually I don't think an Utility folder should exist under /Extra at all, make it easier for users to access these tools/apps, there are better locations for them.

Another thing, I don't think these should be included in the installer :), you'll have to keep track of third party projects, I would, instead, suggest an Utilities package that's not part of Chameleon, the current installer needs to be reworked, and don't think it's a good idea to add even more stuff.

Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 06, 2010, 11:37:28 AM
Well done with your continued development scrax, you seem to have a good understanding of PackageMaker. And thanks for the feedback Kabyl.
Scrax, would you be happy to make some changes to your installer package based on Kabyl's comments? 

I can't really contribute to anything now as I am going away tonight for a break, but I would be happy to look in to re-purposing the docs in to new PDF's when I get back.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 06, 2010, 02:58:01 PM
No problem in adding the changes, Utility and Motherboard will stay for now only in ChameleonPlus. I'll make a ChameleonBase for the official installer and post it there.

Also AppleHDA (smith@@ I gave you credits for that on topic 6 ;) ) could be removed from the base installer.

Chameleon
 --boot0
 --boot0hfs
bdmesg (usr/sbin) HIDDEN
fdisk440 (actually deleted after install, we can put it in usr/sbin instead)

Documentation
(~/Documents/Chameleon) relocable by user

Configurations (not yet added)
--com.apple.Boot.plist
--smbios.plist

Utility
--Preferences Panel  (maybe we can put this in Configurations and remove Utility at all)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 06, 2010, 07:01:19 PM
Hi scrax

I have just done a couple of quicks tests using the ChameleonBase installer on my GPT HDD and MBR USB and it installs the base files just fine which I guess is the most important part of the installer. Could/should it have options for installing to the EFI partition? a FAT partition? and RAID?

Also, as I am running this installer to a blank non-system disk, the Docs folder currently gets added to the root of the target. Can this be a user selectable location so I could point it to my ~/user/documents on a different drive?

Keep up the good work :)
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 06, 2010, 07:23:26 PM
(I had problem editing previous post so here it is)

I'e made some little correction to the installer, here the structure (modded/removed file in the script folder)

Chameleon
 --boot0
 --boot0hfs
bdmesg (usr/sbin) HIDDEN
fdisk440 (usr/sbin) HIDDEN

Documentation
HELP, README, USER GUIDE (Library/Documentation/Chameleon)

AppleHDA (for now still there)

Configurations
--com.apple.Boot.plist (not yet added)
--smbios.plist (not yet added)
--Preferences Panel



--------------------

For installing in EFI and RAID is easy to add the options, but i need to figure out the script needed.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 06, 2010, 07:43:10 PM
I like it :)

For installing in EFI and RAID is easy to add the options, but i need to figure out the script needed.
That's good, and I understand it's all about the scripts. Is there anything in the existing trunk/package/scripts that can help you?
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 07, 2010, 12:30:41 AM
I've finished a first script for raid install, now testing

For efi install what are the differences from a normal one?

Normal:
  Suppose that your installation is on /dev/disk0s2
 
   - Install boot0 to the MBR:
         sudo ./fdisk440 -f boot0 -u -y /dev/rdisk0
 
   - Install boot1h to the partition's bootsector:
        sudo dd if=boot1h of=/dev/rdisk0s2
 
   - Install boot to the partition's root directory:
        sudo cp boot /

EFI:
  Suppose that your installation is on /dev/disk0s2

   - Format EFI as HFS+
         sudo diskutil eraseVolume "HFS+" "EFI" /dev/disk0s1

   - Install boot0 to the MBR:
         sudo ./fdisk440 -f boot0 -u -y /dev/rdisk0
 
   - Install boot1h to the partition's bootsector:
        sudo dd if=boot1h of=/dev/rdisk0s1
 
   - Install boot to the partition's root directory:
        sudo cp boot /Volumes/EFI

If this is correct i think it could be done.

EDIT:
Here it is,
Attached ChameleonBaseEFI project to be copied to /chameleon/trunk/package/
EFIpostinstall and EFIformat scripts needed in  /chameleon/trunk/package/Scripts/PackageScripts/
build package for EFI install (only boot0hfs) it doesn't unmount EFI volume and has an option to format it before install


NOTE: I had problem with this installer probably using EFI format option, comsider it a pre alpha

NOT WORKING YET
Title: Re: Revisit Chameleon's package builder
Post by: zef on September 08, 2010, 12:56:44 PM
- Format EFI as HFS+
         sudo diskutil eraseVolume "HFS+" "EFI" /dev/disk0s1

Hey scrax! Nice progress :)

We don't need to reformat the EFI system partition to HFS anymore since Chameleon can boot and read from FAT32 filesystems which is the default fs for the EFI system partition. This is the script what you need for installing boot1f32 onto a FAT32 partition:

http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/boot1/boot1f32-install.sh
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 08, 2010, 02:13:22 PM
Perfect, I've never used the EFI partition so this are new info for me. :)
I'll update the package soon with the correct script for EFI


EDIT: i've made the change for EFI and now i'm trying to fix some errors with the RAID install.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 09, 2010, 03:03:55 AM
And after few test, here you are the new ChameleonBase.

I've rearranged the needed folder in /trunk/package/ to make it more easy to use, just copy the content of ChameleonBase in package folder.
I've added the Apple license, but i'm not sure if it is the right one, please if someone could check it...

Install Options are still not very clear,
Document can be placed in any location.
Chameleon
-Root
 -boot0 (makes the volume active)
 -boot0hfs
-EFI
 -boot0 (makes the volume active)
 -boot0hfs
-RAID*
 -boot0
 -boot0hfs
-Kext
 -the
 -fives
 -in
 -the
 -repo
Documentation
-BootHelp.txt
-README
-UserGuide
Configurations
-PreferencePanels
-com.apple.Boot.plist (with almost all options)
-smbios.plist (with almost all options)
AppleHDA binpatch
-various
-codec
-binpatch

NOTE ON RAID INSTALL:
Raid install works only with a two disk RAID.
If more than 2 disk are used for the RAID set, installer could work but only two disk of the raid will be bootable.

I'm thinking a way to make the boot0hfs option once so to have:
Chameleon
-ROOT
-EFI
-RAID
-Use boot0hfs

About kext and adding stuff from other projects

I think that essential kext like fakeSMC 2.5 needs to be added.
It's the last "stable" release and is working good and well tested.
Also an all purpose dummy injector like the one from smith could be considered essential and stable.
For lizard maybe we could ask sonotone if he want to use the forge for his project instead of google code.

Another question is:
Is boot0hfs needed with RAID? or are "Boot OSX"volumes always set as active?
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 12, 2010, 07:58:36 PM
I've managed to have a working installer using make pkg
but only after chmod +x on all the postinstall scripts and buildpkg

attached to the issue I opened on repo the compiled installer to test

link: http://forge.voodooprojects.org/p/chameleon/issues/36/
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 13, 2010, 01:04:09 AM
Hi all!

Nice scrax!

I have also add the conclusion.rtfd

just add this in the Distribution file

    <welcome file='Welcome.rtfd'/>
    <license file="License.rtf" sla="EA0401"/>
    <readme  file='Description.html'/>
    <conclusion file="Conclusion.rtfd"/>
    <background file='background.tiff' alignment='topleft' scaling='proportional'/>

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 13, 2010, 02:46:21 AM
And here the latest language collect with the help of the international user
- Hebrew thx to XLR
- Arabic thx to Mohamed Khairy
- Polish thx to janek202
- Russian thx to mozodojo

Not completly "traslated"
some language missed the localization.strings....
Anyway if the official buil will be updated with more options the localizable.strings need an update too... for each language...

And here the scrips from official package "revised" and with some new added

- DropSSDT
- EHCIacquire
- EthernetBuiltIn
- ForceHPET
- ForceWake
- GenerateCStates
- GeneratePStates
- GraphicsEnabler
- GUI
- Legacy Logo
- RestartFix
- UHCIreset
- UseMemDetect
- VBIOS

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 13, 2010, 03:18:03 AM
I post here all my package folder for a working and a bit revised make pkg with the options posted by iFabio, all language not yet added BUT only italian has all the strings for now:

Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 13, 2010, 04:07:09 AM
Could be possible to create a unique Option for the bootloader that contain :

-Chameleon Bootloader
-- Standard
----- boot0
----- boot0hfs
-- FAT32
-- EFI
-- RAID

- Option
--1
--2
- Kext
--1
--2
--3

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 13, 2010, 04:22:13 AM
I was thinking at something like this:
-Chameleon Bootloader
-- Standard
-- EFI (fat32)
-- EFI (hfs) not needed anymore
-- RAID
-- USE boot0hfs valid for EFI and Standard choices (for RAID not needed I think)

- Option
--1
--2

- Themes
--1
--2

- Kext
--10.5
-----1
-----2
-----3
--10.6
-----1
-----2
-----3

In the one i'm editing I've included the pref panel, fakeSMC and TotallyLegacy
Title: Re: Revisit Chameleon's package builder
Post by: Terc on September 13, 2010, 06:44:42 AM
Wait, EFI (hfs) is still needed, isn't it?  For the people that have already formatted their EFI partition to hfs?  I suppose there could just be a simple check that the volume is FAT32 and format if not, but that could leave some angry users if they haven't made backups of their Extra folder.

Maybe I'm missing something, I have been really sick all weekend and I'm certainly NOT at the top of my game right now.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 13, 2010, 01:38:34 PM
You are right,
maybe that could be added with also an Extra folder backup on root...
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 16, 2010, 03:42:15 PM
Hi Scrax & iFabio

It's great to see you haven't rested on this and are still continuing your development :) and well done with resurrecting the official installer, good job scrax. I'll have to find some time soon to try out your latest build - is it the Chameleon_2.0_RC5_r530.pkg.zip which you posted at the Insanely thread?

Also, have any of the Voodoo team tried your latest build? and if so what are their thoughts on it?

EDIT: I've just tried testing by running the r516 package posted above on my G5 to install Chameleon to a USB stick but it stops with an Alert: Chameleon cannot be installed on this computer. I have just checked and seen this was in the original RC1 r431 installer too. So I guess this is a fail-safe to stop installation on Real Macs... Does that happen on real Intel Macs too?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 16, 2010, 08:40:58 PM
Hi Blackosx.

The official installer still a perfect choice because it implement some caracteristic that I can't (no idea how...) implement in the PackageMaker... like javascript for control the choice and localization language...
Yep..
For now a lot of user contribute localizating some language... and until now we just need to fix or rewrite some scripts...
scrax do a exellent job with that!

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 16, 2010, 11:02:12 PM
Hi Scrax & iFabio

It's great to see you haven't rested on this and are still continuing your development :) and well done with resurrecting the official installer, good job scrax. I'll have to find some time soon to try out your latest build - is it the Chameleon_2.0_RC5_r530.pkg.zip which you posted at the Insanely thread?
Yes I'm making the english translation and then i'll post it here also.
Quote
Also, have any of the Voodoo team tried your latest build? and if so what are their thoughts on it?
I don't know but I'm wery interested in hear an opinion and suggestionn from them...
Maybe can be opened a branch for just the installer? I've never used svn before my chameleon experience but I learn quick :)
Quote
EDIT: I've just tried testing by running the r516 package posted above on my G5 to install Chameleon to a USB stick but it stops with an Alert: Chameleon cannot be installed on this computer. I have just checked and seen this was in the original RC1 r431 installer too. So I guess this is a fail-safe to stop installation on Real Macs... Does that happen on real Intel Macs too?
I'm not sure it works but yes it checks if there is AppleSMC

Quote
   function installCheckScript()
   {   
      var obj = system.ioregistry.matchingClass("AppleSMC");
      if (obj) {
         system.log('installCheckScript: Found AppleSMC');
         my.result.message = system.localizedStringWithFormat('Intel_Mac_message');
         my.result.type = 'Fatal';
         return false;
      }
      system.log('installCheckScript: Passed.');
      return false;
   }

I don't know if we can make something to permit the install on external disk but not on system disk' but it colb be useful
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 17, 2010, 03:03:50 AM
I've finished to add the new options to the english localizable.string attached as a base for translations
also attached the new installer with corrected revision number

i've attached also my package folder
yellow are file or folder modified by me
green ones are modified by iFabio
red ones are added by me
orange one are added by iFabio

(http://cl.ly/2QCk/content)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 17, 2010, 08:24:55 AM
Hi iFabio
The official installer still a perfect choice because it implement some caracteristic that I can't (no idea how...) implement in the PackageMaker... like javascript for control the choice and localization language...
I haven't looked at the sources myself, but if you guys are happy building upon the existing code then that must be a good thing. However, I know the original installer was pulled for some reason but I don't know exactly why. If there was a bug in it, would that mean that bug would still be in there now? Maybe we need confirmation on this?

For now a lot of user contribute localizating some language... and until now we just need to fix or rewrite some scripts...
scrax do a exellent job with that!
You have both done well with this and the extra localizations will make the installer very friendly, especially when all the user selectable options have been translated too. And I am sure the scripts will develop in time as and when user feedback comes in.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 17, 2010, 08:25:44 AM
I've finished to add the new options to the english localizable.string attached as a base for translations
also attached the new installer with corrected revision number
Thanks scrax., I'll have a look now and do some quick tests.

EDIT: These are just some general things that I have thought of while testing (so far):

• Wow there's a lot of options now which is great but it might look a bit confusing to new comers?
• If the user decides to add a com.apple.Boot.plist, can it automatically add:
   <key>GraphicsMode</key>
   <string>1024x768x32</string>
I say this because the booter automatically defaults to 1024x768 and if the new user wants to change it then it will be easier if they can already see where to do that. ?

• Selecting the new FakeSMC.kext installs in to /Extra/Extensions, but doesn't it really need to be in /S/L/E for complete functionality? I don't know how this can be done with the installer as if choosing to install Chameleon to EFI, USB or a separate partition then how will it know where /S/L/E is or even which OS X installation to write it to if more than one exists?
Also the FakeSMC.kext in the installer contains all the extra developed kexts which some users won't need...
It's going to be difficult to get this one nailed exactly..

• Selecting the 'Chameleon EFI FAT' option installs chameleon to EFI partition and creates an /Extra and Extra/Extensions folder but these are empty?  IInstead, I get an /Extra folder containing all the selected files on the partition that I selected in the installer to designate the drive I wanted (as I can't choose an EFI partition as it's not mounted at that time).

• The EFI Mounter script only works with hfs formatted EFI partitions and not FAT32. For mounting FAT32 formatted EFI partition I use the following:
Code: [Select]
mount_msdos /dev/disk1s1 /Volumes/EFIwhere as the EFI Mounter script only uses
Code: [Select]
mount_hfs /dev/disk1s1 /Volumes/EFI
I've got to stop and leave for work now, but I'll carry on with more testing on the weekend.. :)
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 17, 2010, 02:13:03 PM
I've finished to add the new options to the english localizable.string attached as a base for translations
also attached the new installer with corrected revision number
Thanks scrax., I'll have a look now and do some quick tests.

EDIT: These are just some general things that I have thought of while testing (so far):

• Wow there's a lot of options now which is great but it might look a bit confusing to new comers?
I think we can make two options folder, one "basic" and one "advanced" or "expert" ?
Quote
• If the user decides to add
 com.apple.Boot.plist, can it automatically add:
   <key>GraphicsMode</key>
   <string>1024x768x32</string>
I say this because the booter automatically defaults to 1024x768 and if the new user wants to change it then it will be easier if they can already see where to do that. ?
I didn't add this ptions because we need to add an options for every size what we want to use but with a sub menu maybe we can do it
Quote
• Selecting the new FakeSMC.kext installs in to /Extra/Extensions, but doesn't it really need to be in /S/L/E for complete functionality? I don't know how this can be done with the installer as if choosing to install Chameleon to EFI, USB or a separate partition then how will it know where /S/L/E is or even which OS X installation to write it to if more than one exists?
Also the FakeSMC.kext in the installer contains all the extra developed kexts which some users won't need...
It's going to be difficult to get this one nailed exactly..
FakeSMC should work from /extra7extensions because it's without plugins. I think that it's better to have it in /E/E because the installer could be used to make a usb booter on a non sistem volume
Quote
• Selecting the 'Chameleon EFI FAT' option installs chameleon to EFI partition and creates an /Extra and Extra/Extensions folder but these are empty?  IInstead, I get an /Extra folder containing all the selected files on the partition that I selected in the installer to designate the drive I wanted (as I can't choose an EFI partition as it's not mounted at that time).
There is something wrong in the script i'll check this, thanks
Quote
• The EFI Mounter script only works with hfs formatted EFI partitions and not FAT32. For mounting FAT32 formatted EFI partition I use the following:
Code: [Select]
mount_msdos /dev/disk1s1 /Volumes/EFIwhere as the EFI Mounter script only uses
Code: [Select]
mount_hfs /dev/disk1s1 /Volumes/EFI
It's something that an user on insanely has suggested to add. I'll try to add the fat support if I can.

thank's for your suggestion and reports Blackosx, I really appreciate it. :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 17, 2010, 02:39:01 PM
Quote
• If the user decides to add
 com.apple.Boot.plist, can it automatically add:
   <key>GraphicsMode</key>
   <string>1024x768x32</string>
I say this because the booter automatically defaults to 1024x768 and if the new user wants to change it then it will be easier if they can already see where to do that. ?
I didn't add this options because we need to add an options for every size what we want to use but with a sub menu maybe we can do it

I do some changes on that parts... look like the same options present in my package (build with packagemaker) with this choaice options...

later I post this change.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 17, 2010, 03:21:22 PM
thank's for your suggestion and reports Blackosx, I really appreciate it. :)
No problem. I am happy to give feedback if it helps you out. I think you are doing a grand job here :)

Maybe can be opened a branch for just the installer? I've never used svn before my chameleon experience but I learn quick :)
Yeah. I think maybe a new project for the package installer under the main forge projects (http://forge.voodooprojects.org/)?
Zef/Kabyl..  Can this be done? Scrax and iFabio are doing a good job with this but I feel we need to help give them a definite direction to aim for.

I think we can make two options folder, one "basic" and one "advanced" or "expert" ?
If it's possible to do that it would help. Maybe "simple" and "advanced", with the simple one just installing the stage 0, 1 and 2 files like Dr. Hurt's old installers? The your mighty list of options can be under the advanced option?

I didn't add this ptions because we need to add an options for every size what we want to use but with a sub menu maybe we can do it
Okay.. I see iFabio has ideas for that! Nice one Fabio :)

FakeSMC should work from /extra7extensions because it's without plugins. I think that it's better to have it in /E/E because the installer could be used to make a usb booter on a non sistem volume
Yeah. I think the new FakeSMC.kext does work from /E/E but the plugins don't. And the kext does contain the plugins..

(http://i52.tinypic.com/2wfiqoo.jpg)

There is something wrong in the script i'll check this, thanks
Cool... and I'll check it again myself this weekend to make sure I haven't made a mistake.

It's something that an user on insanely has suggested to add. I'll try to add the fat support if I can.
Okay.. If you can edit it then great. Otherwise I think it should be renamed to something like hfs_EFI_Mounter.

Keep up the good work  ;D
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 17, 2010, 03:57:10 PM
Ops, I forgot to remove the plugins from fakeSMC so.  :-[
I'll make the adjustment for the options and rename EFI mounter (for now).
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 17, 2010, 03:57:54 PM

later I post this change.

Fabio

good! great
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 18, 2010, 04:19:35 AM
Hi
So that is a "Ibrid" from the official and the package I build with packagemaker.

this is build with the buildpkg script.

-boot0 (use de script from el coniglio) is ok work too on USB device
-boot0hfs (use script from el coniglio) is ok
-EFI (original untouch from official file.. need fixes) no test but I think no
-FAT (original untouch from official file.. need fixes) no test but i think no

- Language --> only "English" (need more detailed and accurate description)
-Utility --> PrefPanel (copied in Targetvolume /Library/PreferencePanes) tested is ok
-Utility --> bdmesg (copied in TargetVolume/Extra/Util) tested is ok

Themes (no changes for now.. I think add a option to autoset a selected them as default) just "delete some for save space"
Kext (delete some to save space) I think to add a specific options for FakeSMC and his plugin... plus for set the info.plist too


Option fo c.a.B.p here I do the major changes... for each option (only 3 for now... more coming)
 is possible select Yes - no or "don't touch", and similar for Graphics Mode and some basics 4 options
I test that options and work

Let me know if can be useful ;)

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 18, 2010, 07:34:21 AM
Here the correction to the EFI problems,
Added backup of old previous /Extra in standard install
added some resolution options
renamed hfs EFI mounter
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 18, 2010, 09:36:47 AM
Well done iFabio and Scrax, I like the revised options in both posted installers.

As there is so much to test on these installers that I am only concentrating on installing to a FAT32 formatted EFI partition for now and I will test further once we have success here.

@Scrax - I have tested installing to the EFI FAT partition and the script is almost there now, but I still have a couple of issues. To make it easier for me to show you what happens, I have put together and attached a PDF report using your installer to show my install process.

Also, referring to Kabyl's earlier post (http://forum.voodooprojects.org/index.php/topic,1521.msg8128.html#msg8128), the installer adds the 'Configuration' folder in to /Extra which was not wanted. Can you maybe add it outside /Extra ?

@iFabio - I have done the same for you installer too.

Conclusion: Both package installers fail to correctly install to FAT32 formatted EFI.. Though we're getting closer.. Keep up the good work guys :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 18, 2010, 12:37:34 PM
Hi scrax here the package with the "subfolder" for the c.a.B.p
I add some more option (missed description.. and title) Maybe you can recreate the cicle for that...

I add "comment" in the script just for undestand... better the start and the end of each package.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 18, 2010, 03:30:17 PM
Further testing.. this time installing to HFS+ formatted EFI partition.

Scrax's installer = Success :)  although files are still installed to the selected partition AND the EFI partition.
Also, I selected only to install FakeSMC.kext in to /E/E which I got but and I also got AHCIPortInjector.kext?

iFabio's installer = Failed.

PDF Reports attached
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 18, 2010, 05:29:06 PM
the problem with the /Extra/c.a.B.p for the resolution is because I forgot to correct the scripts' now I'll do it.

The other file in the selected volume are correct if it is a system volume
Library/Receipts are file created by the installer in the destination volume
/usr/sbin/ is the default path for command line executable (so we can use bdmesg and fdisk440 from terminal)
standalone/i386 is a folder made by the original installer pkgbuild with the binaries from chameleon compilation (I don't know why it was placed here but I chose to don't touch it)

Attached the corrected installer for the resolutions wrong positions, for EFI fat I need to check it better
Also PrefPanel could be easy to install it instead then having it in /Extra/Configuration
But I have no idea where to put hfs+ EFI mounter or the example smbios
 
Title: Re: Revisit Chameleon's package builder
Post by: oldnapalm on September 18, 2010, 08:50:04 PM
Hey guys,

the standard postinstall script is not making the target partition active, looks like it only does if table is GPT
Code: [Select]
# If table is GPT make the first partition active (BadAxe compatibility).
[ "${partitiontable}" = "GPT" ] && bootslice=1

Last scrax installer worked some times, now it's crashing after I click the first continue button (crash report attached).

Edit: here's the updated portuguese Localizable.strings (attached)

I don't understand the ZEvOreboot_description.

I think Kexts_description should be updated since you included kexts which are not plist only and are not compatible with Extra folder (new FakeSMC plugins).
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 19, 2010, 12:46:23 AM
I think ZEvOreboot will be removed from the official installer, because it's a mix of kext needed for my board all in one kext.

I've made some little changes and now i'm testing it, added portuguese translation. Thanks for it

I think we need to work and test it step by step now, so first I''ll look in the standard installer script to be sure it's ok.
when ok I'll pass to the Standard HFS and so on.
Title: Re: Revisit Chameleon's package builder
Post by: XLR on September 19, 2010, 01:50:10 AM
Regarding FakeSMC, i assume it would be great to keep things simple by leaving it without any plugins and with debugging option turned off. Those plugins are obviously for advanced users only, and debugging may only scare the n00bs and trigger "omg fake smc gives me errors during verbose boot!" sort of messages on message boards.

And regarding EFI partition mounter script, in my inconsequential opinion, the best scenario would be to have it implemented into the Preference.panel, but the script needs to be updated in order to be able mounting FAT and HFS partitions as mentioned earlier. The script itself is pretty simple so i believe it shouldn't be a problem, imho.

Just my 2 cents. :)
Title: Re: Revisit Chameleon's package builder
Post by: oldnapalm on September 19, 2010, 03:05:55 AM
Scrax,

I updated the portuguese translation again, I forgot to translate some options, and some were missing.

(http://img153.imageshack.us/img153/1747/capturadetela20100918s2.png)

I'm still experiencing random crashes with your installer, and it's still not making the target partition active.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 19, 2010, 03:51:58 PM
Hi scrax...
always relate to the options in the c.a.B.p here a dirty cycle to put in the buidpkg
using the structure folder of my previus archive..

need correction when the script generate the _title and _description...

Quote
# build options packages

   outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"Options\">"
   choices[$((choicescount++))]="<choice\n\tid=\"Options\"\n\ttitle=\"Options_title\"\n\tdescription=\"Options_description\"\n>\n</choice>\n"
   ((xmlindent++))
   packagesidentity="org.chameleon.options"
   options=($( find "${pkgroot}/Scripts/Options" -type d -depth 1 -not -name '.svn' ))
   for (( i = 0 ; i < ${#options
  • } ; i++ ))

   do
       packagesidentity="org.chameleon.flsgs"
       flagname=($( find "${pkgroot}/Scripts/Options/${options[$i]##*/}" -type d -depth 1 -not -name '.svn' ))
       for (( j = 0 ; j < ${#flagname
  • } ; j++ ))

       do
         outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"${options[$i]##*/}\">"
         choices[$((choicescount++))]="<choice\n\tid=\"${flagname[$i]##*/}\"\n\ttitle=\"${flagname[$i]##*/}_title\"\n\tdescription=\"${flagname[$i]##*/}_description\"\n>\n</choice>\n"
         ((xmlindent++))
         mkdir -p "${1}/${flagname[$j]##*/}/Root"
         mkdir -p "${1}/${flagname[$j]##*/}/Scripts"
         cp -f "${pkgroot}/Scripts/Options/${options[$i]##*/}/${flagname[$j]##*/}/postinstall" "${1}/${flagname[$j]##*/}/Scripts"
         buildpackage "${1}/${flagname[$j]##*/}" "/binaries" "${coresize}" "start_enabled=\"true\""
         rm -R -f "${1}/${j##*/}"      
         ((xmlindent--))
         outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
      done
      echo "Building ${options[$i]##*/} package"
      buildpackage "${1}/${options[$i]##*/}" "/" "" "start_selected=\"false\""
      rm -R -f "${1}/${i##*/}"
   done
   ((xmlindent--))
   outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
# End build options packages

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 19, 2010, 06:17:02 PM
Conclusion: Both package installers fail to correctly install to FAT32 formatted EFI.. Though we're getting closer.. Keep up the good work guys :)
UPDATE:
I have to apologise after my previous report as I have since done hours of testing and discovered the package install to FAT32 formatted EFI partition does work. :-[

In my tests, I was formatting the EFI partition myself before running the installer and I was doing it incorrectly!
I was using:
Code: [Select]
newfs_msdos -v EFI /dev/rdisk1s1
when the correct command is:
Code: [Select]
newfs_msdos -F 32 -v EFI /dev/rdisk1s1
Note: the -v isn't required for the script.

The package installer script uses the correct command but only if the EFI partition is not FAT32. The problem here is I had incorrectly formatted it prior to running the installer so the script assumes it's fine and continues.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 19, 2010, 06:47:22 PM
With regard to the hfs+ Mounter, I have quickly edited it to mount a FAT32 partition and renamed it FAT32 EFI Mounter. I've attached it for now and I'll have a look to see if it's possible to make a single version to recognise both HFS+ and FAT32.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 19, 2010, 06:51:52 PM
Ok perfect, so now we have EFI FAT and HFS+ working,
Standard and Standard boot0hfs working without makeactive if not GPT (easy to add for any type of partition table),
and also Options working if i'm not wrong

FakeSMC now is without plugin so it can be used from /E/E
Hi scrax...

need correction when the script generate the _title and _description...

So for now is not working good?
Quindi per ora non va bene?
Ad ogni modo ottimo lavoro, io mi sto concentrando più sulla parte EFI, RAID ecc e il tuo lavoro sulle opzioni ci sta facendo andar avanti molto in fretta  :)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 20, 2010, 12:28:46 AM
I'll have a look to see if it's possible to make a single version to recognise both HFS+ and FAT32.
I have changed the EFI Mounter to now recognise and mount both HFS+ and FAT32 EFI partitions. See attached for the revised applescript.

The way I did it was to use the fdisk -d  (Dump partition table) command. i.e. fdisk -d /dev/disk0
I noticed on my system that for the EFI partition, fdisk -d returned:

for an HFS+ formatted EFI
Code: [Select]
409640,1835008,0xAF,-,25,127,15,139,184,21
for a FAT32 formatted EFI
Code: [Select]
409640,2100808,0xAF,-,25,127,15,156,68,24
So I have grep'd the fdisk -d command for 1835008 or 2100808 to determine which filesystem to mount. If there's a better way then we can use that instead, but for now it works on my system. However, it might not be fool proof so it needs some testing.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 20, 2010, 01:46:16 AM
I've updated the English Localizable.strings to be more explanatory.

Also, the UseMemDetect boot option should disable the automatically enabled memory detection, where as it currently enables it (again).
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 20, 2010, 06:39:17 AM
So for now is not working good?
Quindi per ora non va bene?


this is little better... but there is a "still problem" with duplicate name_opt

the problem is marked in red color...
How I can solve that?
Quote
# build options packages

   outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"Options\">"
   choices[$((choicescount++))]="<choice\n\tid=\"Options\"\n\ttitle=\"Options_title\"\n\tdescription=\"Options_description\"\n>\n</choice>\n"
   ((xmlindent++))
   packagesidentity="org.chameleon.options"
   options=($( find "${pkgroot}/Scripts/Options" -type d -depth 1 -not -name '.svn' ))
   for (( i = 0 ; i < ${#options
  • } ; i++))

   do
      packagesidentity="org.chameleon.flags"
      flagname=($( find "${options[$i]}" -type d -depth 1 -not -name '.svn' ))
      for (( j = 0 ; j < ${#flagname
  • } ; j++ ))

         do
            outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"${options[$i]##*/}\">"
            choices[$((choicescount++))]="<choice\n\tid=\"${options[$i]##*/}\"\n\ttitle=\"${options[$i]##*/}\"\n\tdescription=\"${options[$i]##*/}_description\"\n>\n</choice>\n"
            ((xmlindent++))
                  mkdir -p "${1}/${flagname[$j]##*/}/Root"
                  mkdir -p "${1}/${flagname[$j]##*/}/Scripts"
                  cp -f "${flagname[$j]}/postinstall" "${1}/${flagname[$j]##*/}/Scripts"
                  echo "Building ${options[$i]##*/}${flagname[$j]##*/} package"
                  buildpackage "${1}/${flagname[$j]##*/}" "/" "" "start_selected=\"false\""
                  rm -R -f "${1}/${j##*/}"
            ((xmlindent--))
            outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
      done
      echo "Building ${options[$i]##*/} package"
      buildpackage "${1}/${options[$i]##*/}" "/" "" "start_selected=\"false\""
      rm -R -f "${1}/${i##*/}"
   done
   ((xmlindent--))
   outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
# End build options packages

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 20, 2010, 08:50:50 AM
I've mado UseMemDetect = No instead of Yes,
and added the new localizable for english
and updated the EFI Mounter
But I have some problem in the compilation so I can't upload a new version
Now random crashes and makeactive for standard install should be fixed.
I've found that if compiled with not all the language it's more stable so now it has only english and italian
After checking that all the options are ok we can rearrange them in simple and advanced
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 20, 2010, 02:19:51 PM
Great. I'll try it out this evening when I get home.
EDIT: Tried it but this one keeps crashing when double clicking it, same as oldnapalm reported above. Crash Report attached
EDIT2: Got it working now, so I'll do some testing.

Standard Install and boot0hfs install:
Both work well, with every file selected in the right place. However, with both installs, EFI Mounter and the Chameleon Preference Pane were both installed as the application's package contents (list of files) and not as a bundle?

The standard install doesn't make the selected partition active.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 21, 2010, 03:38:13 AM
I've corrected the error for EFI Mounter and PrefPanel (I considered them as file instead of folder).
For the active partition I don't know why it is not working, if there is another way to make it active than:
Code: [Select]
fdisk440 -e ${bootdisk} <<-MAKEACTIVE
print
flag ${bootslice}
write
y
quit
MAKEACTIVE

With the installer made by iFabio is it working?
Title: Re: Revisit Chameleon's package builder
Post by: oldnapalm on September 21, 2010, 04:32:21 AM
Is fdisk440 in the path? If it's not you should use the full path to the executable.

Anyway we can use default fdisk to make the partition active, fdisk440 is only needed to write boot0 (or boot0hfs) to MBR.

Code: [Select]
if ${diskupdate}; then
echo "Executing command: fdisk -u -f /usr/standalone/i386/${diskloader} -y ${bootdisk}"
${bootvolume}/usr/standalone/i386/fdisk440 -u -f "${bootvolume}/usr/standalone/i386/${diskloader}" -y ${bootdisk}
fi
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 21, 2010, 05:35:58 AM
:) great progress! with cycle for the options :D

Quote
# build options packages

   outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"Options\">"
   choices[$((choicescount++))]="<choice\n\tid=\"Options\"\n\ttitle=\"Options_title\"\n\tdescription=\"Options_description\"\n>\n</choice>\n"
   ((xmlindent++))
   packagesidentity="org.chameleon.options"
   options=($( find "${pkgroot}/Scripts/Options" -type d -depth 1 -not -name '.svn' ))
   for (( i = 0 ; i < ${#options
  • } ; i++))

   do
      packagesidentity="org.chameleon.flags"
      flagname=($( find "${options[$i]}" -type d -depth 1 -not -name '.svn' ))
      outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"${options[$i]##*/}\">"
      choices[$((choicescount++))]="<choice\n\tid=\"${options[$i]##*/}\"\n\ttitle=\"${options[$i]##*/}\"\n\tdescription=\"${options[$i]##*/}_description\"\n>\n</choice>\n"
      ((xmlindent++))
      for (( j = 0 ; j < ${#flagname
  • } ; j++ ))

         do
            outline[$((outlinecount++))]="${indent[$xmlindent]}\t<line choice=\"${options[$i]##*/}_${flagname[$j]##*/}\">"
            choices[$((choicescount++))]="<choice\n\tid=\"${options[$i]##*/}_${flagname[$j]##*/}\"\n\ttitle=\"${options[$i]##*/}_${flagname[$j]##*/}\"\n\tdescription=\"${options[$i]##*/}_${flagname[$j]##*/}_description\"\n>\n</choice>\n"
            ((xmlindent++))
                  mkdir -p "${1}/${flagname[$j]##*/}/Root"
                  mkdir -p "${1}/${flagname[$j]##*/}/Scripts"
                  ditto --noextattr --noqtn "${options[$i]}/${flagname[$j]##*/}/postinstall" "${1}/${options[$i]##*/}${flagname[$j]##*/}/Scripts/postinstall"
                  buildpackage "${1}/${options[$i]##*/}_${flagname[$j]##*/}" "/" "${coresize}" "start_selected=\"false\""
                  rm -R -f "${1}/${j##*/}"
            ((xmlindent--))
            outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
      done
      ((xmlindent--))
      outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
      echo "Building ${options[$i]##*/} package"
      buildpackage "${1}/${options[$i]##*/}" "/" "${coresize}" "start_selected=\"false\""
      rm -R -f "${1}/${i##*/}"
   done
   ((xmlindent--))
   outline[$((outlinecount++))]="${indent[$xmlindent]}\t</line>"
# End build options packages

Now the script correctly generate the menu and his submenus for each options the name title and description too :)

Now still to get it "working"... copy the script in the package...
Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 21, 2010, 05:38:43 AM
It go with no errors but I can't see any difference:

Code: [Select]
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall: fdisk: 1> Disk: /dev/disk1 geometry: 121601/255/63 [1953525168 sectors]
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall: Offset: 0 Signature: 0xAA55
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall:          Starting       Ending
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall:  #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall: ------------------------------------------------------------------------
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall:  1: EE 1023 254  63 - 1023 254  63 [         1 - 1953525167] GPT         
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall:  2: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall:  3: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall:  4: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall: fdisk: 1> Partition 4 marked active.
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall: fdisk:*1> Device could not be accessed exclusively.
Sep 21 03:16:24 tomaremac installd[4557]: ./postinstall: A reboot will be needed for changes to take effect. OK? [n] Writing MBR at offset 0.

using this to check:

bash-3.2# fdisk440 -d /dev/rdisk1
1,1953525167,0xEE,-,1023,254,63,1023,254,63
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0
0,0,0x00,-,0,0,0,0,0,0

or this from the scripts:

fdisk440 -d /dev/rdisk1 | grep -n "*" | awk -F: '{print $1}'
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 21, 2010, 05:53:31 AM
I've made some corrections because copy paste don't works good
attached the correction
(modification on in bold) reverted back to the original
 choices[$((choicescount++))]="<choice\n\tid=\"${options[$i]##*/}\"\n\ttitle=\"${options[$i]##*/}_title\"\n\tdescription=\"${options[$i]##*/}_description\"\n>\n</choice>\n"

I have still the old folder structure:

/Options/arch/postinstall
 but it can compile not yet tested...
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 21, 2010, 06:05:03 AM
..

I post my actual buildpkg...
edit: and my actual Options (script) folder...
need the options structure folder as my previus archive...
(la struttura della cartella options deve avere per ogni opzione una sottocartella con le differenti opzioni)

Es: /Options/arch/Yes/postinstall


Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 21, 2010, 06:22:56 AM
I'm merging your package folder with mine.

Note: your 64bit script is setting i386
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 21, 2010, 08:15:59 AM
With the installer made by iFabio is it working?
Hi Scrax, to answer your question. Yes, iFabio's installer sets the active flag for the selected partition of the standard install.

Anyway we can use default fdisk to make the partition active, fdisk440 is only needed to write boot0 (or boot0hfs) to MBR.
Yep that works oldnaplam.. :)
Scrax, you can change the /standard/postinstall script to read:

Code: [Select]
# If table is GPT make the first partition active (BadAxe compatibility).
[ "${partitiontable}" = "GPT" ] && bootslice=1
fdisk -e ${bootdisk} <<-MAKEACTIVE
print
flag ${bootslice}
write
y
quit
MAKEACTIVE

which just substitutes fdisk440 with fdisk.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 22, 2010, 03:40:56 AM
Maybe can be opened a branch for just the installer? I've never used svn before my chameleon experience but I learn quick :)
Yeah. I think maybe a new project for the package installer under the main forge projects (http://forge.voodooprojects.org/)?
Zef/Kabyl..  Can this be done? Scrax and iFabio are doing a good job with this but I feel we need to help give them a definite direction to aim for.

It would be much appreciated, it would be easier to work on the same project

I think we can make two options folder, one "basic" and one "advanced" or "expert" ?
If it's possible to do that it would help. Maybe "simple" and "advanced", with the simple one just installing the stage 0, 1 and 2 files like Dr. Hurt's old installers? The your mighty list of options can be under the advanced option?

I think a slightly different idea ... I put together a few things and i upload everything. :D
I agree with the "three" types of installation:
Basic
Standard
Advanced
----

scrax, you can upload your last folder "package"?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 22, 2010, 08:39:07 AM
Hi iFabio
It would be much appreciated, it would be easier to work on the same project

I have PM'd Zef to see what can be done. I can't do it myself as I don't have admin privileges.

I think a slightly different idea ... I put together a few things and i upload everything. :D
I agree with the "three" types of installation:
Basic
Standard
Advanced

Interesting.. I can't comment until I see what you have in mind, but at first thoughts I ask does it need three options? maybe it does.. I'll wait and see :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 22, 2010, 04:00:05 PM
Interesting.. I can't comment until I see what you have in mind, but at first thoughts I ask does it need three options? maybe it does.. I'll wait and see :)

ok the archive contains the "main" make (I add the call for two more "buildpkg") called Advanced and Basic
now... the "command" still the same for the standard so make pkg create a standard package
make basic build a basic package
make advanced build a advanced package.
I do a little edit in the Resources file ( a note version relate to the package used)

I think so...

Basic = just boot0 & boot0hfs
Standard = bootloader file + themes + kext (just a think...)
Advanced = bootloader + themes + kext + utility + ...more functions

The 3 script are just a think... for now don't do nothing... ( I mod just the Basic)

let me know if can useful
Sorry for my bad English.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 23, 2010, 07:19:28 AM
Here it is.
It's still without your options, I'm using the TEST files to merge your options but it is not yet working.

In all the three package, i think, also doc are needed, as bdmesg and fdisk440 of course.
Title: Re: Revisit Chameleon's package builder
Post by: zef on September 23, 2010, 09:47:20 PM
I have PM'd Zef to see what can be done. I can't do it myself as I don't have admin privileges.

Hey guys!

Grats for the nice progress on the package builder :) Just created a separate folder for this project:

http://forge.voodooprojects.org/p/chameleonApplications/source/tree/HEAD/trunk/PackageBuilder

Added ifabio, scrax and blackosx for the project members group - let me know if other people need write access in this repo.

I'll be back on the weekend hopefully...

Take care and thanks for the great job!

Bye,
zef
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 23, 2010, 10:09:57 PM
Nice one Zef. Thanks :)
Scrax, shall I add your package_r011 or shall I add iFabio's?

EDIT: Well I've tried adding Scrax's package and got everything there apart from the Kexts, Scripts and Resources folder.
Those give me the following warning:
svn: warning: 'Kexts' is already under version control
svn: warning: 'Scripts' is already under version control
svn: warning: 'Resources' is already under version control

See: http://forge.voodooprojects.org/p/chameleonApplications/source/tree/HEAD/trunk/PackageBuilder

Hopefully somebody else more knowledgable with SVN can overcome my failure? Azimuth, Meklort, Zef, Kabyl ?
So forgive me iFabio & scrax - you'll soon have your wish. And if I should have added iFabio's package instead then let me know   :P

EDIT: Done - Okay Scrax's package is now in the trunk of the ChameleonApplications.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 23, 2010, 11:54:49 PM
I have a lot to learn about SVN.
Not possible to create a folder "brunches"?

maybe inside the PackageBuilder the 3 classic folder..
branches
tags
and the "final trunk" with the last scrax package...

My idea is starting from that package (in my branch and merge my mod)
then the rest of the "happy crow" can see the difference and if is that ok.... merge the changes in the trunk.


I try last night to enter in the SVN... (try Versions and Coverstone... but both give me permission problem)
To upload the files individually? (Relative to the package pkg).
Tips?

Fabio

Moderator Edit: Post edited and thread cleaned from my SVN posts etc.. Sorry about that
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 24, 2010, 04:25:28 PM
Hi iFabio

Now the trunk contains Scrax's package, I will try to add your branches next so you and Scrax can work on your great projects.

For help with SVN, I'll post here the details Zef sent me previously:

"Versions" is a very good and easy to use subversion client for OS X (http://versionsapp.com). To learn subversion's concepts, I found the stock pdf documentation very useful. Get it from here (http://svnbook.red-bean.com/en/1.5/svn-book.pdf) and chapters 1-2 explain the necessary knowledge for everyday use.

I guess I need to read if again myself  :P
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on September 24, 2010, 04:28:39 PM
Hi guys,

Blackosx, i see you made progress :)
One thing.. you're adding just the contents of /package to the project; are you keeping in mind that it needs the rest of the booter structure to work?
About the branches for iFabio and Scrax, you guys can just create them under /branches, assuming you have write access on the Chameleon Applications project.

Well, i don't know what's your guys status, what kind of help do you need...
iFabio, you need the extra password to get write access to the repo... let me know if you need help with that... just pm me if you don't want to spam the topic with svn talk. This goes to Scrax too and anyone in need related to the project :)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 24, 2010, 04:40:09 PM
Branches added!
http://forge.voodooprojects.org/p/chameleonApplications/source/tree/HEAD/branches

One thing.. you're adding just the contents of /package to the project; are you keeping in mind that it needs the rest of the booter structure to work?
Hi Azimuth
Yeah. Scrax and iFabio have just been working with the separate package folder for a while now and they just add it to the latest trunk download when they want to build the full package. When the package has reached a state of completion, it can then be copied of the main Chameleon trunk.

Do you think we could have done this a better way?  :P
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on September 24, 2010, 05:47:22 PM
Well, i pointed the lack of booter files mainly because iFabio is doing changes on the main make file, which has no place on the PackageBuilder folder as it is. So, i suggest at least moving all the files that are now on the root of PackageBuilder, to a /package folder to match the trunk layout and include the main make file on the root.

About adding me to the noobs :P that can mess with the repo, i'm ok with it even if it's just to help with some svn problem... i do know a thing that needs fixing on the pref pane (think it still needs!?)... Of course i can always help on the installer with time.. needs a lot of testing for what i've seen but it's coming out fine.
By the way, attached is the r011 package with some small fix on buildpkg, removed SMCITE kext since it's a FakeSmc plugin and a typo on Option folder (missing "s").
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 24, 2010, 06:41:27 PM
Perfect Azi, thanks
I'm not at home at the moment, later i'll make sone intensive test with a new hard disk to be sure it works good.
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 24, 2010, 09:38:37 PM
Azi, thanks for the corrections

about
55    fixperms "${1}/Core/Root/"
I'm not sure if it's needed or not but it was already there so I've applied my philosophy:
Don't touch what you don't know :)

but bdmesg is my error having it before line 55, now fixed.

for svn I've copied the trunk in my branch and inside that copy I've updated the package with your corrections.
Now if I make svn diff --revision 140 http://forge.voodooprojects.org/svn/chameleonApplications

I think that i need a little help with the svn base command to commit the changes in my branch, until now I can't undertand how to connect with my account, I used
svn co http://forge.voodooprojects.org/svn/chameleonApplications --username scrax to get the code but i never asked for the password

for now i'm reading the man pages about svn
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 24, 2010, 10:25:14 PM
Well, i pointed the lack of booter files mainly because iFabio is doing changes on the main make file, which has no place on the PackageBuilder folder as it is. So, i suggest at least moving all the files that are now on the root of PackageBuilder, to a /package folder to match the trunk layout and include the main make file on the root.
Yes. I agree and have just made the relevant changes :)

@ Scrax
 
I must apologise, but I have just re-arranged the trunk so the files and folders now sit under a /package folder to fit with what Azimuth was saying above which makes sense to allow iFabio to add the makefile.

Therefore, can you save your changes and re-checkout a new local branch and re-apply your corrections?
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 24, 2010, 11:14:13 PM
Yep, no problem   :)
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on September 24, 2010, 11:17:30 PM
Black, nice :)

Scrax,

i have mixed feelings about this fixperms function; in this context it's not needed for the booter files (but it doesn't hurt) and messes executables; it's also known to mess with some kexts when applied on S/L/E to fix kexts permissions, but we don't deal with that here. Not sure if it can be a problem when it comes to fixing perms on E/E to build mkext?! but then, it's also not needed so... i'll kill it on my side and see what comes out.
Will do some more tests asap and note down any relevant stuff :)

About svn, will pm you...
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 26, 2010, 07:49:00 PM
Hello everyone.
After several tests (thanks to Azimut and blackosx), I was able to use the SVN.
Thanks.

Returning to the topic.
I have a couple of questions and suggestions, to ask you.

It's ok the idea of the 3 pkg?
- Basic (make basic)
- Standard (make pkg)
- Advanced (make advanced)

It would be better to use different names? or reduce the number of packets?
My opinion is that the Basic pkg that could be used as a package only update ...

Waiting for news

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 28, 2010, 02:06:33 AM
I think basic and standard can be just one pkg with:

Chameleon Base (One option autoselected)
- Standard
- boot0hfs
- Efi fat (Only if it's really considered usefull *)
- Efi HFS+ (Only if it's really considered usefull *)
- None
Options (All Unselected)
- example option1
    -Yes
    -No
-example opt2
    - 32bit
    - 64bit
-example opt3
    - 640x480x32
    - 1200x900x32
    - 1920x1080x32
Extra (all unselected)
- PrefPanel
- Kext
      - kext1
      - kext2
      - kext3

Always selected (hidden):
bdmesg
fdisk440
Documentations

If all but chameleon base is unselected when opening the package it's already a "just update" installer.
Or you need to have 4 base pkg (2 for standard install boot0 & boot0hfs, 2 for EFI install) to have less click when upgrading chameleon
(and I think how updates chameleon often actually are only people that can compile it from the source)
Note that upgrade is not always needed for boot0 and boot1h, for boot it's faster to use finder once compiled

I've added in my copy your pkg type string because I think that aside from the "official" installer a bigger one with a lot of stuff also from other projects could be useful but before that we need to have a full working base.

Another thing to do before IMHO is smbios.plist options like for c.a.B.p

*EFi installation questions:
I think that using the EFI partition is a bad idea, because we are breaking the GUID specifications and if Apple starts to use it all the EFI installations will screwed. A way more effective te have a vanilla install is to make a small volume (HFS+, FAT doesn't import) for just chameleon and Extra (if FAT it could also be accessed by other system for recovery ;)  )

For this reason I think it's better if we remove that options from the base install and make a specific EFI installer (with iFabio's change like: "make EFIpkg") to keep support for who has an EFI installation.

In conclusion for me it could be something like:

make pkg (for Standard Package with only Standard Chameleon selected)
make EFIpkg (for upgrading the already used EFI partitions)
make Advanced or whatever (for a fully loaded installer)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 28, 2010, 05:18:13 AM
ok scrax.
commit 156

I do part of your suggestion

edit the main make for efipkg,
now the "standard" pkg work and is ready!
(I use it for some test and... no problem) contain boot0 & boot0hfs and 3 basic themes

is a little step yep... but works! (missed the rest of language..)

also testing a new background.. (i make it in 2 min... so don't kill me)..

Fabio

note: the efi and advanced are "empy" so don't use it for now...
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 28, 2010, 05:36:44 AM
I like the new background!
It's simple and clear. Good job

For the buildpkg script why are you using?

   cp -f ${pkgroot}/fdisk ${1}/Core/Root/i386

for what I know fdisk440 is the same as fdisk (the one in the trunk not the original in osx)

EDIT: I still think that Docs and bdmesg are also needed with any installer so I think i'll keep them in the basic (if they get overwritten it's not a problem).
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 28, 2010, 05:49:32 AM
for what I know fdisk440 is the same as fdisk (the one in the trunk not the original in osx)

EDIT: I still think that Docs and bdmesg are also needed with any installer so I think i'll keep them in the basic (if they get overwritten it's not a problem).

:P my error... sorry... (I merge the thinks from my packagemaker version)...

yep fof docs and bdmesg!!! but... where? bdmesg in /Extra/util ?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on September 28, 2010, 06:50:09 AM
/usr/sbin is the default unix folder for executable and having it in the right place permits to launch it fro any folder witout the full address:

/usr/sbin/bdmesg
works with just:
tomaremac:~ scrax$ bdmesg

/Extra/Util/bdmesg
works only with:
tomaremac:~ scrax$ /Extra/Util/bdmesg

For documentation there is also already a folder:
/Library/Documentation
We just need to add:
/Library/Documentation/Chameleon
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 28, 2010, 11:24:17 PM
Sorry I haven't been around but I've been busy working on other things.. but I see you've both been keeping busy!
So from a quick scoot here of the latest posts...

iFabio - I like the new background too.. Good job :)
and I have just built your 'Standard' package which works well.

*EFi installation questions:
I think that using the EFI partition is a bad idea, because we are breaking the GUID specifications and if Apple starts to use it all the EFI installations will screwed.
I think on real Mac's you will find Apple does already add stuff there but does it affect the hackintosh? Not so far, but I guess you're right to ask the queston. However, The EFI install is still a useful option for many users and it might still be a good idea to keep the EFI options in the standard installer. It might be worth running a poll to get an idea of how many people use the EFI partition for their Chameleon installations?

A way more effective te have a vanilla install is to make a small volume (HFS+, FAT doesn't import) for just chameleon and Extra (if FAT it could also be accessed by other system for recovery ;)  )
I use that method myself.

But overall guys, I see the sense in splitting the installer but I still think maybe just two: Standard and Advanced? I seem to remember in your previous installers all four options working well - (boot0, boot0hfs, EFI FAT, EFI GPT)?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 29, 2010, 03:29:27 AM
hi.
this is not exactly a off topic...
http://www.filibeto.org/unix/macos/lib/dev/documentation/DeveloperTools/Reference/DistributionDefinitionRef/DistributionDefinitionRef.pdf

that pdf can help us to better know pkg building via script..

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 03, 2010, 05:27:48 AM
/usr/sbin/bdmesg
works with just:
tomaremac:~ scrax$ bdmesg
For documentation there is also already a folder:
/Library/Documentation
We just need to add:
/Library/Documentation/Chameleon

Done... ;)

But overall guys, I see the sense in splitting the installer but I still think maybe just two: Standard and Advanced? I seem to remember in your previous installers all four options working well - (boot0, boot0hfs, EFI FAT, EFI GPT)?

ok then... two pkg...
the standard (make pkg)
and the advanced (make advanced) this can include the "EFI" options ???

---
I add a "icon" to the package...
I use a dirty method to do that... because I don't know any terminal command to manage icon via terminal...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 04, 2010, 04:59:12 AM
commit 169

I post the package builded  @IM.

Quote
Update my branch folder with last changes:
- Update all language with last _title and _description (need translation).
- Comment (disabled) in the main make the option for advanced pkg
- Added Options (from scrax's basics folder)
- Added Chameleon Prefpanel
- Correct some minus error
- Comment (disabled) the copy for the resourced folder.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 04, 2010, 08:58:54 AM
Nice one iFabio - I like it and the simplified range of options for the standard installer :)

Note: After running the installer, I see it didn't create a com.apple.Boot.plist?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 04, 2010, 03:11:05 PM
I like it and the simplified range of options for the standard installer :)
credit to scrax. I just copy this part from his buildpkg script


Note: After running the installer, I see it didn't create a com.apple.Boot.plist?

probably... I try the change tonight.

@blackosx
I can ask you to make a icon for the installer... ? :P
same request for a background?
I post the .psd used for the background...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 04, 2010, 06:21:29 PM
Hi Fabio

Here's a couple of mockups for a background. What do you think to something like these?
Title: Re: Revisit Chameleon's package builder
Post by: scrax on October 04, 2010, 09:23:57 PM
iFabio, on buildpkg
line 53
        fixperms "${1}/Core/Root/"

nedds to be before
line 52
        cp -f ${pkgroot}/fdisk440 ${1}/Core/Root/usr/sbin
and
line 51
        cp -f ${pkgroot}/fdisk ${1}/Core/Root/usr/sbin

from what I know is not needed because we don't want to overwrite the original fdisk anymore since we use fdisk440 (that is the moded old fdisk with just another name to differentiate it from the original one).
I'm not 100% sure of this because in my package folder fdisk is 140kB and fdisk440 is 80kB original fdisk is 126kB so if anyone could help more about this please help  :o

What's wrong with the method you use to add the icon? I think it's a good way.

Hi Blackosx, for the background I like the second one (4) but with the voodoo logo in the same place of the first (3)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 05, 2010, 03:29:52 AM
iFabio, on buildpkg
line 53
        fixperms "${1}/Core/Root/"

nedds to be before
line 52
        cp -f ${pkgroot}/fdisk440 ${1}/Core/Root/usr/sbin
and
line 51
        cp -f ${pkgroot}/fdisk ${1}/Core/Root/usr/sbin
Hi scrax!
so... you suggest to switch, from

      cp -f ${1%/*}/i386/boot1h ${1}/Core/Root/i386
      cp -f ${pkgroot}/fdisk440 ${1}/Core/Root/i386
      cp -f ${pkgroot}/fdisk ${1}/Core/Root/i386
      fixperms "${1}/Core/Root/i386"
      local coresize=$( du -hkc "${1}/Core/Root/i386" | tail -n1 | awk {'print $1'} )
to

      cp -f ${1%/*}/i386/boot1h ${1}/Core/Root/i386
      fixperms "${1}/Core/Root/i386"
      cp -f ${pkgroot}/fdisk440 ${1}/Core/Root/i386
      cp -f ${pkgroot}/fdisk ${1}/Core/Root/i386
      local coresize=$( du -hkc "${1}/Core/Root/i386" | tail -n1 | awk {'print $1'} )

What's wrong with the method you use to add the icon? I think it's a good way.
Try open the pkg generated and you see all the metapackages have the same/main icon...
I say "dirty" because what the script do is: copy the icon.icns and paste/rename as the namepackage.pkg after this the rest of the script build the pkg on it... no idea if is the right way...

Fabio

@blackosx
Your background are.. beautiful! (As scrax say I prefer the 4 with the position/logo from 3)

here the background I use... (saved in tiff and preserved background transparency)
but the mirror for the text (Chameleon 2 have a bad look).

Any icon for the installer? just a image.png  400x400 with the 3 operatings sys logo (win-linux-OSX)
... for change look at the classic "box"
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 05, 2010, 10:44:29 AM
Okay - here's the background from mockup 3 with the logos from mockup 4.
I have attached the PSD and a TIFF.

I'll have a look at an image for an icon...
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 05, 2010, 06:10:10 PM
Any icon for the installer? just a image.png  400x400 with the 3 operatings sys logo (win-linux-OSX)
... for change look at the classic "box"
I haven't made many icons before.. but I have been racking my brains to see what I can come up with..
This is what I have done so far. What do you think?
Title: Re: Revisit Chameleon's package builder
Post by: scrax on October 06, 2010, 01:51:18 AM
I think the chameleon in the icon is a great idea but when it's small it's not visible anymore, maybe it needs some sort of more contrast or less transparency? Or a different background color under it?

I had an idea for the background could it be made similar to the preferences panel theme
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 06, 2010, 08:53:34 AM
No problem :) .. How're these?
(http://i53.tinypic.com/21bstty.jpg)

Files attached
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 06, 2010, 09:12:47 AM
Or maybe something like these for an icon?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 06, 2010, 12:24:15 PM
Fantastic!

commit 179
the last "ballon" icon & background.
I delete from my buildpkg the "advanced" option for com.apple.Boot.plist it make crash when open the builded pkg

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 06, 2010, 01:05:42 PM
commit 179
the last "ballon" icon & background.
Great - I'm happy to help where I can :)

EDIT:
I've just built your package installer r179 to have a look at the new background image in action and here a a couple of notes from the tests I've done. If that package is not ready for testing then sorry for trialling something that's not ready and please ignore these comments.

Chameleon Option:
** The Chameleon Standard option does not set the active flag **
** Format EFI to FAT then install using FAT option = Installation Failed **
** Format EFI to HFS+ then install using FAT option = Installation Failed **

Themes Option:
• A good simple selection.. Maybe still include the bullet theme? and how about adding the 'mint' theme that Enzo and I created? Zef was going to add it to the trunk be I guess we haven't got round to that :)
• Maybe add a note that more themes can be found at http://forum.voodooprojects.org/index.php/board,7.0.html

Boot options Option:
• Great choice of default options which for me is all I need (will it suit everyone's needs?)
• Resolutions - again good choice.
*** The /Extra/com.apple.Boot.plist does not get created?  ***

Utility
• Preference Pane - Great.
• SMBIOS.plist - it gets created /Extra/Example - but how will users know if they want to use one then they needs to edit it and move it to /Extra?   - This might be a source of confusion?
• EFI Mounter - Great.

Kexts Option:
• Haven't tested, other than installing FakeSMC.kext which installs to /Extra/Extensions - Great.

Keep up the good work :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 07, 2010, 04:27:58 AM

Themes Option:
• A good simple selection.. Maybe still include the bullet theme? and how about adding the 'mint' theme that Enzo and I created? Zef was going to add it to the trunk be I guess we haven't got round to that :)
• Maybe add a note that more themes can be found at http://forum.voodooprojects.org/index.php/board,7.0.html

Hi Blackosx

ok I add the mint theme and restore the bullet theme. and edit the script (buildpkg) for this part

new data to add in each localizable strings...
Italian example
Quote
// Themes
"Themes_title" = "Themes";
"Themes_description" = "Una raccolta di temi campione.
Molti altri sono reperibili su http://forum.voodooprojects.org/index.php/board,7.0.html";
...
"Mint_title" = "Mint";
"Mint_description" = "Un tema 'Mint' realizzato da Blackosx e Enzo";
...

I've just built your package installer r179 to have a look at the new background image in action and here a a couple of notes from the tests I've done. If that package is not ready for testing then sorry for trialling something that's not ready and please ignore these comments.

Chameleon Option:
** The Chameleon Standard option does not set the active flag **
** Format EFI to FAT then install using FAT option = Installation Failed **
** Format EFI to HFS+ then install using FAT option = Installation Failed **
*** The /Extra/com.apple.Boot.plist does not get created?  ***

In this part I need help to know where and how "fix".. I'm sure scrax can do this part.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on October 07, 2010, 05:04:03 AM
I'll take a look for the efi installs problems and c.a.b.p
for smbios i've started to add something like the c.a.B.p options to avoid confusion, but for now we can remove the example.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 10, 2010, 08:15:56 PM
commit 180

Quote
ifabio: Add mint theme. restored bullet theme. update Polish language update Spanish language Add Chinese language Create a "dummy" folder for a "dummy pkg" language test reason... or maybe I don't need it

also forgot to say "update" italian with mint theme info.

No changes in the script so.. still no work the feature quoted by Blackosx.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 11, 2010, 08:49:33 AM
commit 180
Add mint theme. restored bullet theme.
Thanks Fabio

No changes in the script so.. still no work the feature quoted by Blackosx.
Is it easy to add back in the previous code (http://forum.voodooprojects.org/index.php/topic,1521.msg8286.html#msg8286) for the EFI install which was working from scrax's installer? Or have things changed since then?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 13, 2010, 02:25:02 AM
Is it easy to add back in the previous code (http://forum.voodooprojects.org/index.php/topic,1521.msg8286.html#msg8286) for the EFI install which was working from scrax's installer? Or have things changed since then?
Hi

The 4 options works in the scrax installer (boot0,boot0hfs,EFI,FAT)?
if yes I copy that part and I merge in my package. (I ask because I can't test that options...)

Fabio

Note... the last background is great.. but if you see it in action and "Enlarge" the installer window it lost the lateral and the botton
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 13, 2010, 09:35:42 AM
The 4 options works in the scrax installer (boot0,boot0hfs,EFI,FAT)?
Using scrax's latest files on his branch to make Chameleon-2.0-RC5-INSTALLER-r185.pkg
Note: installer does crash sometimes?

Both the FAT32 and HFS+ EFI options work with the com.apple.Boot.plist, theme and kexts being correctly installed.
Note: When selecting the FAT32 EFI option to an HFS+ formatted EFI partition, the files will be installed but the finder shows the mounted volume as "NO NAME"? I guess this is something to do with the FAT32 EFI option does not format the partition?

Also with scrax's installer, a normal boot0 install to system partition - does NOT set active flag!

Note... the last background is great.. but if you see it in action and "Enlarge" the installer window it lost the lateral and the botton
Yes I know...  :P
Unless we can instruct the installer to draw the shading to fit the window then there's no other way when we use an image for the background, unless it can scale/stretch the background when the window is resized?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 14, 2010, 04:53:43 AM
ok merge the scrax's script in commit 186.

...untested...

what about this? (or similar...just a test)
(http://img651.imageshack.us/img651/170/chamwelc.png) (http://img651.imageshack.us/i/chamwelc.png/)
Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 15, 2010, 09:06:05 AM
Hi Fabio

That background gradation works better and allows the window to be resized - well done :)

I have been running some tests with the EFI options from your latest: Chameleon-2.0-RC5-r186-Standard.pkg and I see the following problems: Installing with either EFI option, I get a boot file and /Extra/com.apple.Boot.plist but no Extensions folder or Theme folder?

And also, one issue which I think still exists with scrax's code is when choosing the EFI option for FAT32 when I know the EFI volume is already formatted as HFS+, the finder will now mount the volume titled "NO NAME" and not "EFI"?  Maybe this is because when selecting FAT32 EFI option, we are not formatting it first (I think that was to not override a user's existing EFI setup).

Idea:
Maybe we could have a checkbox option for formatting the EFI volume if the user wants? Then the script could run either of the following commands depending on which type was wanted:
Code: [Select]
FOR FAT32:
newfs_msdos -F 32 -v EFI /dev/rdiskXs1

FOR HFS
newfs_hfs -v EFI /dev/rdiskXs1

Then we could remove the format that's currently default on the EFI HFS+ option.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 18, 2010, 05:39:11 AM
hi
commit 188
try changes in standard(boot0) and standard(boot0hfs) scripts

I try boot0 option and set the partition active (The rest of option still Untested).

This weekend with freetime I try add the blackosx's suggestion.

Fabio

PS in the commit I forgot to add the ?Icon <-- is a hidden file in the folder ... next commit
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 18, 2010, 08:15:35 AM
Hi Fabio

Good to see you're trying to change your scripts but the make pkg fails with your commit 188 'Error creating archive'?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 18, 2010, 10:05:58 PM
Hi Blackosx and thx!

I update the same file but w/o the set icon... (yep the "folder" icon make the problem described above)
I find some "way" to create and set icon for folder starting from a imagefile using terminal command.. Is what I looking for..
I will try this to...


so... commit 190...
boot0 work for me and set the partition active...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 18, 2010, 10:18:24 PM
Okay Thanks. I've successfully built the installer (r190). I'll run some tests.....

EDIT: Running the installer, pointing to an empty partition on an empty HDD, and selecting only the 'Chameleon Standard' option ends with and installation error?
I used make pkg to build, is that correct?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 19, 2010, 03:58:15 PM
:(

then is time to return back to working version...

I re-try me too and I get your same error... sorry.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 19, 2010, 05:21:57 PM
Hi Fabio

Don't worry....  You have done a good job working with this and i know you've grasped the fundamentals of the scripts etc.. Maybe now's a good time to take a stop and look at where the installer is at?

I thought the original idea was for you and scrax to work together on making a complete Chameleon installer but am I right in saying that you both have different code now? From my last test the code in Scrax's branch was working well, although I did experience a couple of random crashes with it - so it's not 100% ready.

Can you combine your tweaks etc. on to the code from scrax's branch? then we can just have one solid foundation with the main Chameleon files being installed correctly with all the other scripts added?

What do you think to that? :)
Title: Re: Revisit Chameleon's package builder
Post by: scrax on October 20, 2010, 10:36:36 AM
Hi all,
 I'm a bit busy lately untill 6th of november.
I agree with Blackosx it's time to have a unified installer to work on. The big differences are is the chameleon install scripts, for EFI install can't be used EFI mounter to mount the EFI partition and then use the default installer on that partition?
At least for the HFS+ formatted EFI?
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 25, 2010, 08:59:54 AM
I've been having a look at the scripts and have been thinking that maybe we can change things.... How about a new installer which installs the correct files dependent on which volume the user points to? That way the installer options can just be for either Standard or EFI. A lot of the code we need is already there in the existing scripts.

Simple Examples for Standard:

User selection in package installer:
HFS+ format partition on a disk with a GPT.
Script Action:
if found any non-HFS+ partitions (or TYPE: Microsoft Basic Data)
  write boot0hfs, boot1h and boot
else
  write boot0, boot1h and boot
  make partition active

User selection in package installer:
FAT+ format partition on a disk with a GPT.
Script Action:
if found any non-HFS+ partitions (or TYPE: Microsoft Basic Data)
  write boot0hfs, boot1f2 and boot
else
  write boot0, boot1f2 and boot
  make partition active

User selection in package installer:
a RAID Volume
Script Action: (Not too sure here as I haven't done this)
if found any non-HFS+ partitions (or TYPE: Microsoft Basic Data)
  write boot0hfs, boot1h and boot to each disk
else
  write boot0, boot1h and boot to each disk
  make partition active


Simple Example for EFI:

User selection in package installer:
Any partition on a disk with a GPT.
Script Action:
if GPT disk and format is hfs then
  mount_hfs volume
  if found any non-HFS+ partitions (or TYPE: Microsoft Basic Data)
    write boot0hfs, boot1h and boot
  else
    write boot0, boot1h and boot
    make partition active
  un-mount volume
else (format is ms_dos)
  mount_msdos volume
  if found any non-HFS+ partitions (or TYPE: Microsoft Basic Data)
    write boot0hfs, boot1h and boot
  else
    write boot0, boot1h and boot
    make partition active
  un-mount volume


I don't see why this type of logic can't be implemented in only two scripts (Standard and EFI), and could the same standard script be applied to disks with an FDisk_partition_scheme? (obviously no EFI script needed for this). I have only used GPT for my installs so I need to do some testing on that.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 29, 2010, 06:06:52 PM
It's taken me a little while to find time to read and learn how the existing code in the scripts work. And from my research I've made some changes, tweaks and additions to the excellently written scripts. They've been great with helping me understand how it all works.

I have so far, only concentrated on two scripts for installing the Chameleon boot files. One for EFI and for not EFI. The main additions are they aim to:
• install boot0 or boot0hfs depending on whether or not it detects a Windows disk signature in the MBR.
• detect if a Windows bootloader is in the MBR and if so, install boot0hfs.
• detect if either boot0 or boot0hfs is already installed and change accordingly if it also finds a Windows disk signature in the MBR.
• EFI script will install boot1h or boot1f2 depending on the format of the EFI partition.
• Activate selected partition if it meets two conditiions: A - it's not already the active partition, B Windows is NOT installed

Only the Standard install has been tested so far on GPT and GPT/MBR testbeds with OSX and with and without Windows7.
I'll hopefully get some time to test the EFI install this weekend but I will have to change the buildpkg first, but those two scripts should be all we are going to need now for installing the bootloader files.

If anybody spots any issue with what I have been doing and thinks I need to make any changes etc. then please post. TIA
Link to scripts: Standard (http://forge.voodooprojects.org/p/chameleonApplications/source/tree/HEAD/branches/blackosx/trunk/package/Scripts/Standard), EFI (http://forge.voodooprojects.org/p/chameleonApplications/source/tree/HEAD/branches/blackosx/trunk/package/Scripts/HFS)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 30, 2010, 01:42:12 AM
 ;D
I will try it Blackosx... Thx in advance.

Fabio
Soon I update the language... with the missed translation strings for some language

EDIT:
Question.
for doc "building"

yours (in buildpkg)
      # build package for Documentation
         mkdir -p "${1}/Documentation/Root"
         cp -f ${pkgroot}/doc/BootHelp.txt ${1}/Documentation/Root
         cp -f ${pkgroot}/doc/README ${1}/Documentation/Root
         cp -f ${pkgroot}/doc/Users_Guide0.5.pdf ${1}/Documentation/Root
         echo "Building Documentation package"
         buildpackage "${1}/Documentation" "/Documentation/Chameleon2RC5" "" "start_selected=\"false\""
      # End build package for Documentation

mine (in buildpkg)
# build package for Documents
   mkdir -p "${1}/Documents/Root"
   cp -f ${pkgroot}/doc/BootHelp.txt ${1}/Documents/Root
   cp -f ${pkgroot}/doc/README ${1}/Documents/Root
   cp -f ${pkgroot}/doc/Users_Guide0.5.pdf ${1}/Documents/Root
   echo "Building Documents package"
   buildpackage "${1}/Documents" "/Documents/Chameleon2RC5" "" "start_selected=\"false\""
# End build package for Documents

the name of the correct folder is??? /Documents/ or /Documentation/

other things...
Is better hidden and auto install the doc and the bdmesg? (out of the Extra package)

      # build package for bdmesg
         mkdir -p "${1}/bdmesg/Root"
         ditto --noextattr --noqtn "${1%/*}/i386/bdmesg" "${1}/bdmesg/Root"
         echo "Building bdmesg package"
         buildpackage "${1}/bdmesg" "/usr/sbin" "" "start_visible=\"false\" start_selected=\"true\""
      # End build package for bdmesg
Title: Re: Revisit Chameleon's package builder
Post by: scrax on October 30, 2010, 08:08:24 PM
is not important the name you use there. Also "Documenti" will work. It's a folder used to store all the package contents before building it.

I think that, like fdisk440, bdmesg and doc are to be installed without any choice to avoid confusion to noobs (and also to be sure that a lot of user have installed bdmesg to check the problems)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 30, 2010, 08:15:07 PM
is not important the name you use there. Also "Documenti" will work. It's a folder used to store all the package contents before building it.

I think that, like fdisk440, bdmesg and doc are to be installed without any choice to avoid confusion to noobs (and also to be sure that a lot of user have installed bdmesg to check the problems)
?

buildpackage "${1}/Documentation" "/Documentation/Chameleon2RC5" "" "start_selected=\"false\""
buildpackage "${1}/Documents" "/Documents/Chameleon2RC5" "" "start_selected=\"false\""

Documentation or Documents (marked in red) is the pkg name inside the main package
Documentation or Documents (marked in blue) is the destination folder for that package
scrax are you sure about the "destination" folder is standard???

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on October 31, 2010, 02:06:35 AM
no. You are right it's not correct there is an error in my branch

this is the apple standard documentations folder:
/Library/Documentation

sorry, this is good i think

buildpackage "${1}/Documentation" "/Library/Documentation/Chameleon2RC5" "" "start_selected=\"false\""
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 31, 2010, 03:25:06 PM
no. You are right it's not correct there is an error in my branch

this is the apple standard documentations folder:
/Library/Documentation

sorry, this is good i think

buildpackage "${1}/Documentation" "/Library/Documentation/Chameleon2RC5" "" "start_selected=\"false\""

THX scrax!

Blackosx very good works!
I wait you complete the scripting fix job :P and I merge the cosmetics feature like icon background and language

Fabio

EDIT
A working way to add "ugly" icon to the pkg after build is
Code: [Select]
DeRez -only icns "${pkgroot}/Icon.icns" > tempicns.rsrc
Rez -append tempicns.rsrc -o "${1%/*}/${packagename// /}-${version}-r${revision}-Standard.pkg"
SetFile -a C "${1%/*}/${packagename// /}-${version}-r${revision}-Standard.pkg"
Where Icon.icns is prebuild with a apps like Img2icns
Info about this metod was found here --> http://hintsforums.macworld.com/archive/index.php/t-70769.html
credits to the authors of that posts.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 01, 2010, 10:47:09 AM
Question.
for doc "building"
sorry, this is good i think
buildpackage "${1}/Documentation" "/Library/Documentation/Chameleon2RC5" "" "start_selected=\"false\""
Hi Fabio/Scrax

Well done for spotting and providing a fix for the 'Documentation' issue. I have only really been working on the standard and EFI scripts to make sure the Chameleon bootloader files are installed correctly and have yet to try to understand the buildpkg script  ;D  You guys are well ahead of me there ;)

Having said that, I have updated the buildpkg in my branch to include the EFI script. So I am now happy that the standard script and EFI script will correctly install the Chameleon files to HDD with a GPT and to complement that I have also changed the English localized.strings to better describe the standard and EFI procedure (I might change it still at a later date).

I've removed the 'Configuration' folder of scripts and have changed the EFI Mounter applescript to use the same code from the EFI script for identifying the EFI partition format.

As I get time, I will work through the whole package and see what else I can change etc..

Blackosx very good works!
I wait you complete the scripting fix job :P and I merge the cosmetics feature like icon background and language
Thanks for testing it out and I think now we need to test the standard and EFI scripts with a larger audience. Maybe you could merge the changes I have made with your branch and release the package in your InsanelyMac thread, but add a note to stress that this is a test for revised scripts for installing to GPT disks..

Do think that's a good idea or shall we wait for more testing? as the last thing we want to do is release something that messes someone's setup.

As I still want to do tests at my end for installing to drives with an MBR partition scheme which show up in diskutil as FDisk_partition_scheme.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 01, 2010, 03:29:22 PM

Thanks for testing it out and I think now we need to test the standard and EFI scripts with a larger audience. Maybe you could merge the changes I have made with your branch and release the package in your InsanelyMac thread, but add a note to stress that this is a test for revised scripts for installing to GPT disks..

Do think that's a good idea or shall we wait for more testing? as the last thing we want to do is release something that messes someone's setup.

As I still want to do tests at my end for installing to drives with an MBR partition scheme which show up in diskutil as FDisk_partition_scheme.

Yep I do it today later...
I compile your branch on last chameleon trunk (no add language or icon and background) your "virgin" branch with last trunk code
a opinion of large audience for "find" faster the good and bad things..

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 01, 2010, 03:50:52 PM
Great. In that case, let me change some of the wording in the English resources to reflect that it's a test installer, and it's a work in progress. I'll post back when I'm ready. Thanks :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 01, 2010, 05:15:23 PM
Great. In that case, let me change some of the wording in the English resources to reflect that it's a test installer, and it's a work in progress. I'll post back when I'm ready. Thanks :)
;) when you are ready...
Can you write here what you wont I will write in IM trend about this "test" package... (sorry but my english is not so clean)
Just a Note to copy&paste near the download package...
thx

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 01, 2010, 05:34:17 PM
Okay - I've amended the Welcome.rtfd for the English language to reflect the package is a trial and listed what's been changed.

The English Welcome.rtfd reads:
Code: [Select]
This package installer uses updated versions of the original Chameleon scripts and this trial reflects it's current state. I've conducted numerous tests with it using OSX and Windows 7 on a disk with a GPT and GPT/MBR and feel it's ready for wider testing.
Please only use this if you are confident.

The changes made (so far) are:
• Only two bootloader choices (Standard and EFI).
• boot0 or boo0hfs are automatically written depending on whether or not a Windows disk signature exists in the MBR of the selected disk.
• EFI script will install boot1h or boot1f32 depending on the format of the EFI partition.
• If you currently have boot0hfs installed but without a Windows installation then it will be replaced with boot0 (and vice-versa).
• Activate selected partition if it meets two conditions: A) it's not already the active partition, B) Windows is NOT installed
• Only English language. Note: other languages will be added back once the words have been finalised.
• EFI Mounter applescript updated to mount EFI partition.

There will be more changes in the future to the whole package.

I am happy now that the 'package' folder from my branch (commit 206) is good for a trial at your InsanelyMac topic. Though I haven't updated the main Chameleon files to match the current Chameleon trunk. I'll try to find some time for that later this evening..  unless you can add that for now at your end when you build the package?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 01, 2010, 06:25:09 PM
ok I post it...
look if is ok

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 11, 2010, 01:07:11 AM
commit 214

Update my branch to match with chameleon trunk 630 also the Package folder are the same as Blackosx folder,

I add in the buildpkg script the "command" listed some post ago for make the icon on the builded pkg, I place that command between
the name of pkg and the MD5 info.

Also add the strigs for the mint theme inside the unique localizable.strings in the Resouce folder (English).

NOTE: I see some problem if I add a lot of language.. can the text format inside the file cause random crash in builded package?
With only english the pkg builded is stable! Strange no?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 11, 2010, 01:46:35 PM
Hi Fabio

commit 214
Update my branch to match with chameleon trunk 630 also the Package folder are the same as Blackosx folder,
As far as I can remember, the code in my branch was working apart from the creation of the com.apple.Boot.plist as I changed the way it was done - so I recommend you test it thoroughly at your end before you think about releasing an installer based on it. I am busy learning shell scripting and re-working a local version on my branch - which now looks a lot different to what I have on the SVN. I've a lot of work to do yet and it's all down to finding the time to get it to a point where I am happy with.

I add in the buildpkg script the "command" listed some post ago for make the icon on the builded pkg, I place that command between
the name of pkg and the MD5 info.
Nice. I'll look at that when I'm near finishing my project.

NOTE: I see some problem if I add a lot of language.. can the text format inside the file cause random crash in builded package?
With only english the pkg builded is stable! Strange no?
I too saw this and more languages did make the package 'unstable'.. I haven't looked in to why that happened but if you find anything the please post :)
Title: Re: Revisit Chameleon's package builder
Post by: scrax on November 11, 2010, 02:19:37 PM
I have the problem with many languages and random crash too.

I'll make some test, for now I think it's better to use only english on the package used to be tested on insanely
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 21, 2010, 12:21:31 AM
Hi Blackosx.
I see your last commit in the SVN.

this Evening I upload a new file (Trunk 643) still based on your "TEST V1" from your commit 206
Just to offer and updated bootloader.

Also, relate to a new icon I wont say THANKS to RASONE for his great job with the icon.

Original chameleont image (chameleon 2 -the return- by ~nicobou on deviantART
 http://nicobou.deviantart.com/art/chameleon-2-the-return-27426356?q=sort%3Atime+favby%3Aefoja&qo=28)

Final Icon by RASONE (3D box and effect + chameleon Icon)
I use it in the next package :P

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: scrax on November 21, 2010, 05:48:48 AM
Fantastic Icon!  :)
Title: Re: Revisit Chameleon's package builder
Post by: zarac on November 22, 2010, 01:06:45 PM
i was wondering if there is something i am missing with this installer. is it ready for testing?
i grabbed the installers from the Insanelymac topic and tried standard (non-EFI) install onto my USB stick with dumped snow leopard install dvd.
installer says "installation successful", but i can't boot the stick - i get a blinking cursor.
tried partitioning my stick with GUID and MBR partition schemes, also tried r643 and r629, but the same thing happens.
the stick is not broken, it boots after i install chameleon manually.

another weird thing: even though i selected numerous boot options in the installer (resolution, p and c states, gfxenabler, etc...) com.apple.Boot.plist inside Extra ends up empty.

am i doing somthing wrong (don't know how i can make a mistake with an installer)?
any thoughts?
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 22, 2010, 03:58:36 PM
Hi zarac

To give a little light on where this thread is, Scrax and iFabio took the original Chameleon scripts and tweaked them to make revised installers which we tested here and there and iFabio released the work in his InsanelyMac topic for the 'Unnoficial Chameleon RC5 installer'.

Since then, I thought I'd give myself an opportunity to learn about shell scripting and started myself with a project here and that's how the Chameleon trial v1 installer came about.  It was based on the code in Scrax's branch (http://forge.voodooprojects.org/p/chameleonApplications/source/tree/HEAD/branches/scrax/trunk/package) which in turn is based on the original scripts used for the original Chameleon installer. I concentrated on giving the script some logic to install either boot0 or boot0hfs depending on the existence of a Windows installation and boot1h or boot1f32 depending on the format of the EFI system partition - see this post (http://forum.voodooprojects.org/index.php/topic,1521.msg8610.html#msg8610) for more details. 

It was after personal testing of the revised code that I asked iFabio to host the package installer at his InsanelyMac topic for testing to gather some feedback, and in due course that came in, namely from kizwan. I then went off to put together a v2 trial but never got as far as releasing anything it as I found some issues with it. iFabio did prematurely release a build from my branch to his InsanelyMac topic, though it was pulled as immediately as I spotted it.

Since then, I have started again and there is new work-in-progress code in my branch which I am still working on when I get some spare time. There are a few things I still want to do with it and there are some parts which need correcting etc. but it's currently not yet ready for public release.

installer says "installation successful", but i can't boot the stick - i get a blinking cursor.
Thanks for the feedback from your tests with running the installer against your USB memory sticks. I hadn't really conducted much testing there and I'll add it to my to do list for the code I'm currently working with.

...it boots after i install chameleon manually.
Installing Chameleon manually in my opinion is still the best way to do it :)

another weird thing: even though i selected numerous boot options in the installer (resolution, p and c states, gfxenabler, etc...) com.apple.Boot.plist inside Extra ends up empty.
The v2 installer, which I never released, had a re-work for building the com.apple.Boot.plist and that was faulty..  Hence one of the reasons I am now working on the new installer in my branch. I think iFabio, copied the code from my branch to his branch in which case any future releases built around that code needs fixing! - though I think the last one iFabio released (see above (http://forum.voodooprojects.org/index.php/topic,1521.msg8776.html#msg8776)) was based on the code from my commit 206 which should be the same as my v1 test installer but with the latest Chameleon trunk.

am i doing somthing wrong (don't know how i can make a mistake with an installer)?
Lol.. No, you're not doing anything wrong :)
Can I please ask for your patience here and continue using a manual install for the Chameleon bootloader until I find some spare time to get the code in my branch top a state where I am happy to release another trial?
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 22, 2010, 04:08:08 PM
Final Icon by RASONE (3D box and effect + chameleon Icon)
I use it in the next package :P
Hi Fabio

Lovely icon - and TBH, better than the one I tried to make for you  :P
Title: Re: Revisit Chameleon's package builder
Post by: zarac on November 22, 2010, 05:19:38 PM
Thank you Blackosx for your quick reply. Now I understand the issues.

Can I please ask for your patience here and continue using a manual install for the Chameleon bootloader until I find some spare time to get the code in my branch top a state where I am happy to release another trial?

No problem. Actually, that was the first time i used the installer for Chameleon, usually it's terminal all the way for me.
I just wanted to let you know about my experience with this installer. I always have a "master" Chameleon USB stick (if I screw up the disk booter) and a few ones just for fiddling.
If you need any kind of testing, just let me know - I will gladly help with what I can.

Zarac

EDIT:
The new icon looks really great. Good job, RASONE!
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 23, 2010, 12:00:23 AM
No problem. Actually, that was the first time i used the installer for Chameleon, usually it's terminal all the way for me.
An installer can be considered lazy and also it doesn't really teach the user anything about what's been done to their system, so maybe this isn't such a good project?  :P  But I have learnt by doing this so for me at least it's been worth it.

I just wanted to let you know about my experience with this installer.
Thanks, I appreciate the feedback.

I always have a "master" Chameleon USB stick (if I screw up the disk booter) and a few ones just for fiddling.
Same here.. I have a bootable USB hanging on my notice board for emergency purposes and I have needed it on the odd occasion.

If you need any kind of testing, just let me know - I will gladly help with what I can.
Thanks. I'll bear it i mind :)

Also, I've just done a quick couple of tests running the latest 'work-in-progress' installer from my branch against a USB memory stick.
Test1 - Install to a USB partitioned in disk utility with 'Mac OS Extended' format and using a GUID partition table.
Test2 - Install to a USB partitioned in disk utility with 'MS-DOS (FAT)' format and using a GUID partition table.
Test3 - Install to a USB partitioned in disk utility with 'MS-DOS (FAT)' format and using a Master Boot Record.

Tests and 1 and 2 boot successfully, but test 3 fails.

EDIT: Updated the scripts to now detect FAT16 and FAT32, as before my test 3 against a USB with MBR failed because it was using FAT16. MBR installs work only when the device is using FAT32.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 26, 2010, 04:41:27 PM
Blackosx
Can I upload your commit 243 @IM?
TEST purpose?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 26, 2010, 07:19:27 PM
Hi Fabio  ;D

Please can I ask for your patience and don't post it yet? The interface hasn't been touched at all and although it works pretty well, I would like to tweak it further yet. But by all means you're more than welcome to test the latest build personally and give feedback here.

The latest puzzle I have is installing to a drive using MBR..... the test I have done is:

A - in Disk Utility, erase a 2GB USB as MS-DOS
B - in Disk Utility, erase a 500GB HDD as MS-DOS

Then run the latest installer package against both, selecting the same options for each and after rebooting:

A - Booting from the USB, Chameleon's GUI loads and I can successfully select and boot my OS X installation on a different drive.
B - Booting from the HDD, Chameleon loads but only presents the CLI as it doesn't find my /Extra folder, therefore although I can select my OS installation on a different drive, it fails to boot.

I've just tried installing to the HDD again with RC4 and although I see the GUI, it's because the theme was embedded. But the same happens in that it doesn't find the /Extra folder.

EDIT: Well after some more testing I now know the setup will work from HDD as long as I add a HFS partition. This I guess makes sense as why would anybody install Chameleon to a hard drive using an MBR partition scheme with only a single FAT32 partition?
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 28, 2010, 08:07:05 PM
Can I upload your commit 243 @IM?
TEST purpose?
Hi Fabio

I am now happy for you to upload the built package file from commit 246 to IM for testing if you want. I have included the Resources/English.lprog folder back now with revised text files which gives a ReadMe, some usage instructions and notes in the package installer itself.  I would like it to use your lovely icon but I haven't looked at adding that myself, so if you would like to add it before posting the feel free, if not then no problem :)

For more details for your IM post here's a changelog

Changelog from v2 (prematurely released and pulled) to v2.1b
• Whole package re-built from scratch with Apple's PackageMaker.
• Uses and builds upon the original Chameleon installer scripts which are now split in to a modular workflow with notes and comments etc. to suit my working style.
• Un-mounts all volumes with the name "EFI" before attempting to install to the EFI system partition (thanks kizwan).
• Re-worked the creation of the com.apple.Boot.plist and the /Extra folder.
• Added detection for FAT16 to stop installation with smaller USB memory sticks.
• Installation of Chameleon files stopped if found existence of GRUB / Linux Loader.
• Added a basic error log which is written to the target volume.
• Added Resources/English.lproj back in with revised text files to allow extra language support at a later date.
• Added Mozodojo's version of Netkas' fakesmc which works from /Extra.
• Installs Chameleon RC5 trunk 644.

Note: This is still a work-in-progress and there are things I still want to add in time, for example, installation to software RAID, expand the log file process and I need to learn more about the GRUB / Linux loader and how installing Chameleon affects it.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 28, 2010, 10:26:35 PM
ok ;)

I post it later with your description in the "TEST PGK" zone :P

And I add the Icon ;)

EDIT: DONE!

---

Have you try to reverse this script into a script version (pkg builder)? the old way for make the package...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 28, 2010, 10:47:15 PM
I post it later with your description in the "TEST PGK" zone :P
And I add the Icon ;)
Great - I look forward to some feedback from it - I'll check in to Insanely to help out.

Have you try to reverse this script into a script version (pkg builder)? the old way for make the package...
No. I haven't looked in to that yet. If you know more, please feel free to take the code from branch and run tests.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on November 28, 2010, 11:11:29 PM
;) DONE

I just download it from your branch in commit 246
added the icon an zipped it

Fabio

I will try to mix your script with the old official script method...
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 28, 2010, 11:23:40 PM
I will try to mix your script with the old official script method...
Okay - I'll be interested in learning what you do :)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 30, 2010, 03:18:31 PM
Question to whoever knows the answer?

The original chameleon standard postinstall script uses the following line:
Code: [Select]
"${bootresources}/Tools/SetFile" -a V "${bootvolume}/${filesystemloader}"
I know the SetFile command comes with Apple developer tools but what happens when this line is run on a machine without the developer tools, does it just fail?  I mean I can't find the SetFile binary in the original chameleon package installer, so if it's not available I guess the boot file doesn't get hidden.

The reason I ask is because I was trying to use the command in the package installer in my branch but without including the Apple binary in the package I can't see how it will work. So what's the rule here, am I allowed to include, therefore effectively redistribute the Apple binary?
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on November 30, 2010, 08:32:18 PM
Hi guys...
sorry for not giving much help on this; a bootloader installer is not a priority to me, but the main reason is really lack of time.
Anyway, i've been following the progress and you guys are all congratulated for your efforts :)

Blackosx, about the hidden (or not) boot file, i already voted on the IM topic for a visible boot file, simply because it's easier for everyone, from devs (while testing) to noobs (while ignoring the file is hidden).
I also think no permissions should be set on the file; leaving that for later since i still didn't had time to check sources, but i believe that's happening since i'm getting a Unix Executable (dark icon) on some tests installing to disk images.

About your last question, SetFile is included on the latest official pkg, under EnhancedHFS.pkg(Standart.pkg)/scripts/tools (checked with Pacifist, under Resorces tab); on the trunk, check /package/buildpkg, lines 60, 68 & 76 for when it's added there. So, i guess you can include it on the pkg; but, there's an alternative that's already in the system without XCode, the "chflags <hidden/nohidden>" command... that's what i use all the time for the purpose.



Now to a more serious matter...
Code: [Select]
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *320.1 GB   disk0
   1:               Windows_NTFS Windows 7               64.4 GB    disk0s1
   2:                      Linux                         32.2 GB    disk0s2
   3:               Windows_NTFS test                    8.6 GB     disk0s3 (this one it's in fact a ExFAT fs)
   4:                  Apple_HFS Hyperspace              214.8 GB   disk0s4
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk1
   1:                        EFI                         209.7 MB   disk1s1
   2:                  Apple_HFS Snow                    200.0 GB   disk1s2
   3:                  Apple_HFS Home                    99.9 GB    disk1s3
   4:                  Apple_HFS Leo                     40.0 GB    disk1s4
   5:                  Apple_HFS SnowLab                 40.0 GB    disk1s5
   6:                  Apple_HFS Mac OS X Install DVD    10.0 GB    disk1s6
The above is my internal HDD layout atm; disk0 is already "loaded" with boot0hfs on mbr and the booter is installed on disk0s4. When i run the installer against that disk, everything is updated except for boot0hfs.
I see on the installer log that the mbr is checked for the presence of stage 0...
Code: [Select]
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: ===============================================
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: Entering CheckDiskMicrocode:
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: ****************************
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: DEBUG: passed argument for targetDisk = /dev/disk0
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: DEBUG: passed argument for diskSigCheck = 1
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: 0b807c
Nov 30 01:19:53 AziLandz installd[454]: ./postinstall: Found existing Chameleon stage 0 loader - Boot0hfs
my question is, why isn't stage 0 updated in this case?... asking before shooting ;D
If you need i can post or send you the full log, but i can tell you that the rest seems pretty fine.

See you later...
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on November 30, 2010, 11:04:32 PM
Hi Azimutz

sorry for not giving much help on this
No problems there mate - I've seen you around keeping very active with other things and you are always helping others users - so all credit to you. But thanks for stopping by and lending your expert eye :)

a bootloader installer is not a priority to me
I know what you mean - sometimes I question myself for doing this but I guess I'm just a bit bored these days and wanted to get involved in something a bit different and this seemed the perfect opportunity to learn some shell scripting.

Blackosx, about the hidden (or not) boot file, i already voted on the IM topic for a visible boot file, simply because it's easier for everyone, from devs (while testing) to noobs (while ignoring the file is hidden).
I always have it visible as exactly as you say, it's easy to swap, change, see etc. and doesn't cause my any issues. But in response to the InsanelyMac posts I have added the option in the installer for the user to choose which they prefer. Hence the previous post about SetFile.

I also think no permissions should be set on the file; leaving that for later since i still didn't had time to check sources, but i believe that's happening since i'm getting a Unix Executable (dark icon) on some tests installing to disk images..
Thanks for the note - I haven't looked at permissions yet.

About your last question, SetFile is included on the latest official pkg, under EnhancedHFS.pkg(Standart.pkg)/scripts/tools (checked with Pacifist, under Resorces tab); on the trunk, check /package/buildpkg, lines 60, 68 & 76 for when it's added there. So, i guess you can include it on the pkg; but, there's an alternative that's already in the system without XCode, the "chflags <hidden/nohidden>" command... that's what i use all the time for the purpose.
Thank you for pointing out that SetFile was included in the original pkg, I was looking at the files in the trunk and didn't see it the inclusion in buildpkg.  I will proceed and use it in my branch :)

As for chflags, yes I am aware of that command and have used it before myself but after doing a quick bit of research earlier today and found a post saying the difference between SetFile and chflags is that SetFile can mark files as invisible on non-HFS volumes. I haven't looked any more in to that to confirm but I thought if Chameleon can be installed on FAT32 partitions then chflags wouldn't work there? - I need to do some testing etc.

disk0 is already "loaded" with boot0hfs on mbr and the booter is installed on disk0s4. When i run the installer against that disk, everything is updated except for boot0hfs.
../snip/..
my question is, why isn't stage 0 updated in this case?... asking before shooting ;D
Good question - and the basic answer for now is that's just the way I've set it to work.
I haven't thought about the code for boot0 or boot0hfs changing anytime soon so I went down the route that if it doesn't need changing then why bother.. But now you've brought it up then maybe it wasn't such a good idea? lol..    it's easy enough to change.

If you need i can post or send you the full log, but i can tell you that the rest seems pretty fine.
No need for that - I trust your judgement  ;D

Thanks again for your feedback.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on December 01, 2010, 08:00:26 AM
Quote
But thanks for stopping by and lending your expert eye :)
:o expert, moi?
Quote
As for chflags, yes I am aware of that command and have used it before   myself but after doing a quick bit of research earlier today and found a   post saying the difference between SetFile and chflags is that SetFile   can mark files as invisible on non-HFS volumes. I haven't looked any   more in to that to confirm but I thought if Chameleon can be installed   on FAT32 partitions then chflags wouldn't work there? - I need to do   some testing etc.
... see what i mean :P i was unaware of that. I really didn't checked it out; i figure there will be some diff...

Quote
I know what you mean - sometimes I question myself for doing this but I   guess I'm just a bit bored these days and wanted to get involved in   something a bit different and this seemed the perfect opportunity to   learn some shell scripting.
yeah, it's a nice project, no doubt. And i have nothing against installers, just to make it clear :)
Learned a lot messing with them!

Quote
Good question - and the basic answer for now is that's just the way I've set it to work.
I haven't thought about the code for boot0 or boot0hfs changing anytime soon so I went down the route that if it doesn't need changing then why bother.. But now you've brought it up then maybe it wasn't such a good idea? lol.. it's easy enough to change.
aah, that explains it ;D
I think it's safer (and simpler) to always write it; people may come from RC4, or other Chameleon based booter, etc etc...
give it a thought.

I'll be back later with some more stuff... this was the most urgent...
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 01, 2010, 08:49:56 AM
Thanks for coming back - and don't be modest - I use expert in the sense that you do have a good knowledge and have given some good quality advice in these and other forums. I remember reading some of your posts when I first started out!

Anyhow, back to the installer - Please do no use it, or only use in a dedicated test environment.
There have been two reports of data loss at InsanelyMac from using versions v2.1b, 2.1.1b and 2.1.2b so I have therefore pulled it. I am not happy hearing this and don't want to hear any more reports for data loss. I need to look at the scripts and try to work out what's going on, but until it can be figured out - I need to let everybody know.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on December 03, 2010, 09:07:16 AM
yeah... back to the installer ;)
That SetFile stuff checks out; chflags doesn't work on FAT, indeed.
About the data losses, i find them very strange.. need to test... that's "no problemo" to me, just need up to date backups. Did you made any changes to the stage 0 writing stuff?... need to check the code but, time doesn't help :(
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 03, 2010, 09:17:39 PM
I'm going to spend a few hours looking at the scripts this weekend - I've just made the change for writing stage 0 even if it already exists, but I want to re-write / re-organise some of the code... time will tell is they still work.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 07, 2010, 06:35:20 PM
After some consideration, I will not continue any further with the package installer in my branch even though for me it actually worked well. I enjoyed the learning experience of understanding the original Chameleon installer scripts; would I be right in thanking kalyway and mackerintel for those?

Some of the reasons for ceasing are:

• My scripting wasn't perfect and it proved dangerous to a couple of users.
• I don't want the guilt of users losing their data with it.
• Users don't actually learn anything by using it.
• I could try creating a script for installing to RAID setups but they already exist (for instance: digitaldreamer's guide at InsanelyMac).
• My time will be better spent on other things.

I will update my branch, when possible, with any local changes I have recently made and leave it there for anyone to look at in the future, if desired. Best of luck to iFabio, scrax and anyone else with future development here if they choose to continue.

EDIT: Done - see commit 258
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on December 08, 2010, 10:04:38 AM
Now that i was prepared to loose some data? :o ai ai ai :)
All that i can do is offer to test. On the tests i did so far i also had no such problems, not even a sign of them.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 08, 2010, 11:26:28 AM
Lol..   :)
If you do want to test further then that would be appreciated at least for my conscience! But out of interest It always worked for me and I couldn't reproduce the reported problems. You can find the latest built package (for testing purposes only) in the 'build' folder in my branch.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on December 08, 2010, 12:24:10 PM
yep... just updated the working folder and gave it a look. Can't build the installer... i hate Package Maker! :P i'm probably being noob at something... Will try the installer later; i did fired it up but something came up and i'm already tired so...
I'll keep in touch :)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 08, 2010, 03:39:00 PM
Can't build the installer... i hate Package Maker! :P
Fixed - commit 259.
Yes, PackageMaker does seem a bit restrictive, but from doing this I've got used to working with it.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on December 10, 2010, 07:30:04 AM
Thanks for the fix.. does build now, but still no time to test it :(
My biggest problem with Package Maker is that i don't find it intuitive enough.. it is with some things, but then it's not with others and i don't play with it in a long time.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 10, 2010, 02:54:46 PM
There's no rush here Azi - As far as I'm concerned the project has been shelved and it's collecting dust for now.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on December 11, 2010, 10:18:39 AM
I know... but, i was enjoying your effort and this "data loss" problem got me curious.
No hurry, yeah :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 27, 2010, 12:29:24 PM
Hi people!

Merry Christmas and happy new year!

About the "installer" I try a different way the dmg...
for now the script is a little mes* but works (the creation of needed stuff)

(http://dl.dropbox.com/u/4017771/new-dmg.png)

I wait for some feedback from IM

And soon I commit the new stuff on the SVN.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 28, 2010, 04:09:18 PM
Hi Fabio

Interesting idea and it definitely helps to keep things simpler. I like it :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 28, 2010, 09:23:11 PM
Thanks Blackosx.

About the dmg posted @IM:

- The pkg is a slim version of Blackosx's script (last builded from script not packagemaker)
- I just create some icon "suitable" using the same metot too add on the fly (similar method used for the pkg)

Would be a useful add an "EULA" or similar?
here all the URL I read for "arrange" a script for automate the building...
Code: [Select]
http://www.rkuntz.org/pmwiki.php?n=Code.AntDiskImage
http://www.tuttologia.com/macp2p/showthread.php?t=9479
http://wiki.services.openoffice.org/wiki/MacOSX:_Arrange_icons_in_a_dmg
http://svn.apache.org/repos/asf/directory/studio/trunk/tools/Mac%20OS%20X%20DMG/createDMG.sh
http://www.macdisk.com/ds_storeen.php
http://hints.macworld.com/article.php?story=20020311215452999
http://endrift.com/blog/2010/06/14/dmg-files-volume-icons-cli/
http://stackoverflow.com/questions/96882/how-do-i-create-a-nice-looking-dmg-for-mac-os-x-using-command-line-tools
http://www.yoursway.com/free/#createdmg
http://www.tutorial9.net/tutorials/photoshop-tutorials/photoshop-tutorial-design-the-mac-os-x-leopard-folder/
http://marketingtypo.com/tag/icon/
http://qwan.org/2007/05/22/using-xcode-to-build-a-disk-image-and-upload-a-web-site/
http://drnicwilliams.com/2009/02/03/choctop-packaging-and-deployment-of-cocoa-applications/
http://www.brightpebbles.org/articles/disk-images-on-the-fly-in-xcode
http://www.mackb.com/Uwe/Forum.aspx/mac-tools/404/XCode-adding-a-task-to-the-build-phase
http://cocoawithlove.com/2010/11/deployment-script-for-generic-cocoa-mac.html
http://www.omnigroup.com/mailman/archive/macosx-dev/2002-April.txt
http://mac101.net/content/how-to/how-to-create-dmg-art-for-fancy-application-installations/
http://www.tribler.org/trac/wiki/MacDiskimage
http://goodliffe.blogspot.com/2010/08/eulogise-adding-eula-to-dmg.html

there is different tecnique but the process is always the same...

I need help to compile a old command called OpeUp (I'm very noob with language program)
I get this error (I'm sure is a stupid error)...
Code: [Select]
Fabios-Mac-Pro:openUp root# make
cc    -c -o openUp.o openUp.c
openUp.c: In function ‘main’:
openUp.c:68: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 2 has type ‘u_int32_t’
cc   openUp.o   -o openUp
Fabios-Mac-Pro:openUp root#
This "command" is useful to auto-popup a dmg when is mounted...


Fabio
Title: Re: Revisit Chameleon's package builder
Post by: rocksteady on January 04, 2011, 02:34:56 AM
The icons look ab-fab Mr. iFab :)

Let us know how it all comes up and thanks for your efforts. The guys are right though, getting a decent installer out of the pipeline requires crazy, meticulous testing. We should keep this one on stress-test mode for quite some time.
Title: Re: Revisit Chameleon's package builder
Post by: NetBoot on January 04, 2011, 03:27:52 AM
iFabio

Can you add the Kext for Legacy Support for Intel ICHX without AHCI

I have a Intel ICH6 and I'm using IOATAFamily.kext

Thanks,

Net...
Title: Re: Revisit Chameleon's package builder
Post by: scrax on January 04, 2011, 05:52:31 AM
Hi NetBoot, can you add a link to the kext you are using?
Title: Re: Revisit Chameleon's package builder
Post by: NetBoot on January 04, 2011, 07:45:19 AM
I'm using this one. I'm assuming it's the latest

http://osx86.sojugarden.com/files/Extensions/IOATAFamily.kext.zip (http://osx86.sojugarden.com/files/Extensions/IOATAFamily.kext.zip)

Net....

What would really be useful is if you can also add gptsync
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on January 04, 2011, 06:34:41 PM
Hi guys...

Maybe for the next dmg I can add the "kext" folder (same present into the official version)...

But I need time to do this change into the "dirty" dmg script...

Before this I wont commit a "stable" dmg script... w/o too much crazy things...
(the .DS_Store file give me crazy...)

Maybe this week-end... (depend... my free time)

Fabio

Request... Into the last dmg is present a background... maybe guys can make some amazing background???
mine is made w/o too much tecnique (I'm very bud with photosh*p)... Blackosx?
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 06, 2011, 01:03:25 PM
Hi iFabio

I might be able to come up with a background for your Window.
Have you got a final window size and folder placement positions which I can work with?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on January 09, 2011, 03:18:12 PM
Hi iFabio

I might be able to come up with a background for your Window.
Have you got a final window size and folder placement positions which I can work with?
Hi Blackosx...
sorry for the big delay...

Is not a big problem the dimension.. 800x600 is ok
Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 10, 2011, 12:05:59 AM
Hi iFabio

Well done with your continued work on this :)
Looking at your latest package: Unzipping your Chameleon.699.zip from IM shows me the following window:
(http://i53.tinypic.com/2wlu0yw.jpg)

How about a layout of something like this? (excuse the quick mock-up)
(http://i53.tinypic.com/9k3rbm.jpg)

The background can be made to look for professional in time but the first thing to finalise will be the icon positions. If they can be set then the background can work with them. I measure the current window at 549x413 pixels.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 18, 2011, 06:25:35 PM
Hi all.
After 4 mouth... I try to restart with this things.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 19, 2011, 03:46:17 PM
Some little progress commit 272

- Revised the post Install script, the temporary folder will correctly delete after the install process.

know issue:
- no Extensions.mkext will re/build after install a kext into E/E.
- the "cosmetics" Icon generate an error  during the make process, but the package are well maked

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on May 19, 2011, 04:18:06 PM
Good to see you've revitalised this topic Fabio :)

I left the project well alone after a user's bad experience, though I did enjoy the learning and working on it. Maybe if I get some time I can look at this again.

Check the original Chameleon script in trunk/package/Scripts/Post/postinstall for a line to make Extensions.mkext, and didn't you have your custom icon working before? if so, what's changed?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 19, 2011, 11:24:30 PM
didn't you have your custom icon working before? if so, what's changed?

I Blackosx

As I say in PM.
there is a problem with the Icon resource fork
This is the message:
Quote
...//...
Building FakeSMC package
113 blocks
Building IOAHCIBlockStorageInjector package
4 blocks
Building IOATAFamily package
1131 blocks
Building JMicronATAInjector package
5 blocks
3 blocks
1 block
### DeRez - The resource fork of "/project/chameleonApplications/branches/iFabio/Chameleon/package/Icon.icns" is empty and uninitialized.
sh-3.2#

Now the pkg will be create w/o problem...
So what change?

4 months ago the script and the icon (all the commit) was created on one of my old OSX installation...
few week ago I reinstall a new one (Snow Server 10.6.7) also install xcode-3.2.6...
no problem with this, the normal make and compiling just work fine.
Now I saw there is that "problem" with resource fork... why?
On my working local copy of the commit (exactly the same I commit on the svn) the script and the icon work correctly
but if I download the commit (Is the same code!!!) look like the Icon.icns lost this data, and the DeRez/Rez can't manage it!

So probably there is a workaround: I see here there is a "solution?" http://xahlee.org/UnixResource_dir/macosx.html
- Compress the Icon.icns (with ditto).
- Into the buildpkg script add the "uncompress" command.
- and probably we can continue with the script process.

I haven't see this problem before...

---

I also (when the pkg are ready to use, and integrate with the main chameleon), add the dmg creation process...
similar as what I post @IM
But this need more time and I prefer discard this for the moment.

sorry all for my poor English.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 20, 2011, 12:33:44 AM
"solved" ;)

I do some deep test and I commit this little change...
commit 273

into buildpkg:
Quote
#   Here is the place for assign a Icon to the pkg
#   command use to generate the file:
#   ditto -c -k --sequesterRsrc --keepParent Icon.icns Icon.zip
ditto -xk "${pkgroot}/Icon.zip" "${pkgroot}/"
DeRez -only icns "${pkgroot}/Icon/Icon.icns" > tempicns.rsrc
Rez -append tempicns.rsrc -o "${1%/*}/${packagename// /}-${version}-INSTALLER-r${revision}.pkg"
SetFile -a C "${1%/*}/${packagename// /}-${version}-INSTALLER-r${revision}.pkg"
rm -f tempicns.rsrc
rm -rf "${pkgroot}/Icon" # Clean the generated folder from "ditto"
# End

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on May 20, 2011, 08:34:28 AM
Well done Fabio. Keep going with the research :)
I'm going away for a week tomorrow so hopefully I find time to I'll test your installer when I get back.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 20, 2011, 02:57:12 PM
Commit 274
Play with the buildpkg script... a pretty print now also for this script like the main chameleon

Commit 275
Added a "empty" choice for modules
And reworked the package identity for the creation of the metapkg, inspired from a Packagemaker structure name.

Fabio

For the rebuid extensions.mkext
maybe is better add a hidden&active choice into the "kext" choice for do the job.
?

EDIT commit 276
Create a structure choice for modules with "names"
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 22, 2011, 03:41:28 AM
commit 277

Finish the creation of module choice.. that choice is now integrated into the main chameleon binary config choice menu.

I add a "for" cycle for automate the process, it based on the number of folder into Script/Modules/ folders,
so is easy add a new module-choice in future adding a module-foldername.

(http://img821.imageshack.us/img821/462/cham277.png) (http://imageshack.us/photo/my-images/821/cham277.png/)

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on May 30, 2011, 08:09:20 PM
commit 302:
merge chameleon trunk's 921 changes.

Todo.
- create a script for each module (just for copy from the pkg "tempdir" into DestinationVolume/Extra/module)
- I upload a "slim" buildpkg version of that script, it will include into a future DMG build script, the slim  "version" just have the bin boot file & modules.
- A script for build/rebuild the E/E mkext
- I need a background for the windows DMG (the dimension are not so important 800x600 will be fine.

done.
- The module are compiled and included into the pkg correctly, also I add the "extra" module from the Azimutz branch (THX)
AMD,Intel,nvidia.Ati/GraphicsEnabler.
- At the moment:
make pkg build the pkg (6 MB) with themes
make dmg build a slim pkg with defined file name Chameleon.pkg I plan to add (after the slim pkg build process) to move that file into the dmg.

Need.
I have "fix" the openUp.c file discussed long time ago, will be nice to add this into the i386/util , with this little "program" we can show (pop up) a text when a dmg is mounted (I think this for the Chameleon DMG), I compile and use that "code" in my local machine and works well.

here the edited openUp.c file
Code: [Select]
/*
 * Copyright (c) 2001 Apple Computer, Inc. All rights reserved.
 * 
 * @APPLE_LICENSE_HEADER_START@
 *
 * The contents of this file constitute Original Code as defined in and
 * are subject to the Apple Public Source License Version 1.1 (the
 * "License").  You may not use this file except in compliance with the
 * License.  Please obtain a copy of the License at
 * http://www.apple.com/publicsource and read it before using this file.
 *
 * This Original Code and all software distributed under the License are
 * distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, EITHER
 * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,
 * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT.  Please see the
 * License for the specific language governing rights and limitations
 * under the License.
 *
 * @APPLE_LICENSE_HEADER_END@
 */
/*
 * Shantonu Sen <<EMAIL REMOVED>>
 * openUp.c - program to set the "first-open-window" field of a volume
 *
 * Get the directory ID for the first argument, and set it as word 2
 * of the Finder Info fields for the volume it lives on
 *
 * cc -o openUp openUp.c
 * Usage: openUp /Volumes/Foo/OpenMe/
 *
 */

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/attr.h>
#include <sys/stat.h>
#include <sys/mount.h>
#include <memory.h>

struct directoryinfo {
long unsigned length;
uintptr_t dirid; // changed from: u_int32_t dirid;
};

struct volumeinfo {
long unsigned length;
uintptr_t finderinfo[8]; // changed from: u_int32_t finderinfo[8];
};


int main(int argc, char *argv[]) {
char *path = NULL;
struct attrlist alist;
struct directoryinfo dirinfo;
struct volumeinfo volinfo;
struct statfs sfs;

path = argv[1];

bzero(&alist, sizeof(alist));
alist.bitmapcount = 5;
alist.commonattr = ATTR_CMN_OBJID;

getattrlist(path, &alist, &dirinfo, sizeof(dirinfo), 0);

printf("directory id: %lu\n", dirinfo.dirid);

statfs(path, &sfs);

printf("mountpoint: %s\n", sfs.f_mntonname);

alist.commonattr = ATTR_CMN_FNDRINFO;
alist.volattr = ATTR_VOL_INFO;

getattrlist(sfs.f_mntonname, &alist, &volinfo, sizeof(volinfo), 0);
volinfo.finderinfo[2] = dirinfo.dirid;
setattrlist(sfs.f_mntonname, &alist, volinfo.finderinfo, sizeof(volinfo.finderinfo), 0);

return EXIT_SUCCESS;
}

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on June 02, 2011, 03:31:32 AM
Need.
I have "fix" the openUp.c file discussed long time ago, will be nice to add this into the i386/util , with this little "program" we can show (pop up) a text when a dmg is mounted (I think this for the Chameleon DMG), I compile and use that "code" in my local machine and works well.

Thx a lot meklort!
Quote
924 by meklort
Added openUp utility. Will be used in the pkg build script
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on July 16, 2011, 03:12:03 AM
Commit 324.
- Update to Main Chameleon 2 RC5 r.1162.
- update also the GraphicsEnabler modules from Azimutz sub-branch (test purpose for the pkg).
- Update the Options script (correct from com.apple.Boot.plist to org.chameleon.Boot.plist).
- Add 2 more script into "boot" Options (ShowInfo and CSTUsingSystemIO).
- Update the (English) Localizable.strings.
- Some "problem" with the Rez and DeRez tools with Xcode4 so I comment out the add Icon pkg stuff.. for the moment.
- The dmg script "works" (need more deep test).

TODO.
- relate to dmg... I need to edit a work "license".r file, and this will be add to openup command.
- create (empty for now) a script for each module (to just copy the module into the TARGET/Extra/Modules/).
- Update (and test) the other Language (Some double/duplicate _title & _descriptions can cause random crash)

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on July 17, 2011, 11:27:46 PM
Hi iFabio,

something just came to my mind about the GraphicsEnabler modules; i assume you are adding them
to the trunk binaries; that's not good :P the trunk still has the code that the modules use in boot2 so,
the modules will conflict with it and... kaput!
I know that meklort already talked to you about the package;
i'll join you in this stuff soon to help test... this time i really mean it!

See ya later...
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on July 18, 2011, 12:32:36 AM
Azi surely you're right!

As you well know, I understand very little about the code (C ,C++, etc...)
The purpose of the integration and creation of all the modules, is to check the management of it by scripts, and pkg ...

As meklort suggest me, I edited (in the makefile) and suppressed the "sudo"
and now I'm with.. side effects .. "chown"
Help and advice are always welcome!

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on July 20, 2011, 01:32:31 AM
My knowledge of coding is also limited; i may know a bit more than you about C/C++ but you certaily
know more than me about other stuff ;)
Sure, you can add the modules for testing the package, but be careful not to share it.
Can you point me the "sudo" thing... my knowledge of coding doesn't have comparison with Mek's;
he must have a reason for telling you that!?

p.s.: ok, i see the sudo stuff on r1178 and the comment to remove it, but it's still there, so use it for now :)
Title: Re: Revisit Chameleon's package builder
Post by: meklort on July 20, 2011, 06:52:35 AM
Main reason for not using sudo, is I shouldn't have to use sudo to compile a package.... That and I don't want to have to give the buildbot root access...

Anyway, for chameleon, permissions don't matter, so we don't actually need to chown anything to root. *But* if you want to, we can use a postinstall script that chowns everything to root after the install instead.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on July 24, 2011, 08:52:06 PM
Main reason for not using sudo, is I shouldn't have to use sudo to compile a package....
Agree!... I still didn't had time to look at this properly; two days without modem messed up my up to date
status completely :P
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on August 02, 2011, 12:09:32 AM
Hello everyone.
I have a suggestion or question to ask, concerning the kext and the use of most of them.
What do you think if we "edit" the Info.plist directly involved in the kext?
Maybe by adding or modifying the contents of .plist files with scripts?

I write a small example to make the marvell 88E8086 recognized (edit already known by many).
System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleYukon2.kext/Contents/Info.plist
Quote
...
                <key>Yukon-88E8055-B0</key>
                <dict>
                        <key>CFBundleIdentifier</key>
                        <string>com.apple.iokit.AppleYukon2</string>
                        <key>EnableLowPwr</key>
                        <integer>1</integer>
                        <key>IOClass</key>
                        <string>yukon2osx</string>
                        <key>IOPCIPrimaryMatch</key>
                        <string>0x436a11ab</string>
                        <key>IOPCISecondaryMatch</key>
                        <string>0x00ba11ab</string>
                        <key>IOProviderClass</key>
                        <string>IOPCIDevice</string>
                        <key>InitialWaitForLinkUp</key>
                        <integer>6000</integer>
                        <key>MACNumber</key>
                        <integer>1</integer>
                        <key>Model</key>
                        <string>Yukon Gigabit Adapter 88E8055 Singleport Copper SA</string>
                        <key>NetworkNumber</key>
                        <integer>1</integer>
                        <key>RxDeadman</key>
                        <integer>0</integer>
                        <key>RxRingGrowOnPause</key>
                        <integer>10</integer>
                        <key>RxRingSize</key>
                        <integer>0</integer>
                        <key>RxRingSize_100MBit</key>
                        <integer>128</integer>
                        <key>RxRingSize_10MBit</key>
                        <integer>64</integer>
                        <key>RxRingSize_GigaBit</key>
                        <integer>256</integer>
                        <key>TxRingSize</key>
                        <integer>256</integer>
                        <key>Vendor</key>
                        <string>Marvell</string>
                        <key>WaitForLinkUp</key>
                        <key>WaitForLinkUp</key>
                        <integer>6000</integer>
                </dict>
                <key>Yukon-88E8056</key>
                <dict>
                        <key>CFBundleIdentifier</key>
                        <string>com.apple.iokit.AppleYukon2</string>
                        <key>EnableLowPwr</key>
                        <integer>1</integer>
                        <key>IOClass</key>
                        <string>yukon2osx</string>
                        <key>IOPCIPrimaryMatch</key>
                        <string>0x436411ab</string>
                        <key>IOProviderClass</key>
                        <string>IOPCIDevice</string>
                        <key>MACNumber</key>
                        <integer>1</integer>
                        <key>Model</key>
                        <string>Yukon Gigabit Adapter 88E8056 Singleport Copper SA</string>
                        <key>NetworkNumber</key>
                        <integer>1</integer>
                        <key>RxDeadman</key>
                        <integer>60</integer>
                        <key>RxRingGrowOnPause</key>
                        <integer>10</integer>
                        <key>RxRingSize</key>
                        <integer>0</integer>
                        <key>RxRingSize_100MBit</key>
                        <integer>128</integer>
                        <key>RxRingSize_10MBit</key>
                        <integer>64</integer>
                        <key>RxRingSize_GigaBit</key>
                        <integer>256</integer>
                        <key>TxRingSize</key>
                        <integer>256</integer>
                        <key>Vendor</key>
                        <string>Marvell</string>
                </dict>
                <key>Yukon-88E8061</key>
                <dict>
                        <key>CFBundleIdentifier</key>
...
Similar thinks for JMicron, BlockStorage, ACHIPort, and so on...

So the only Kext needed is (now) FakeSMC.

Let me know

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on August 18, 2011, 07:40:50 PM
Yay... iFabio, finally ;D
Check r1429; that fixes EFI install. Still there are some unfinished business, like copy Extra to EFI partition,
were to place the tools (fdisk440, bdmesg, etc...), etc...
Will leave that for later, after taking care of the Standard script, to get a better notion of what needs to be done.
I hate this stuff :P
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on August 18, 2011, 11:56:52 PM
Hi Azi!

Nice to see you here... (in actions !! :P)

I take a look at you commit.

A note for you...
I commit into the trunk a split version of Localizable.strings file
In my branch there are the complete version of it (for each language)...
I do this because into the (trunk) buildpkg.sh the script not include all the possible(know) module/s
Maybe is a good point for your branch(GraphicsEnabler) use that localized file instead of trunk's localize... same things for the buildpkg.sh... 3 module are always out for the pkg we split out part of code... I preserve this part of code.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on August 19, 2011, 01:44:50 AM
Yeah, i already had thought about the package for the trunkGraphicsEnablerModules, but
now that i really think about it, i don't know if i want to maintain specific packages for those folders :P
it's more work... i might even delete "package" on those.
Chazi it's another story... we'll see on that.
Anyway, thanks for the info... we can always adapt it to other modules, if these end up not being used.

Will be back soon with more pkg stuff...
Title: Re: Revisit Chameleon's package builder
Post by: scorpius on August 24, 2011, 06:03:23 PM
Is the package/buildpkg.sh script broken, or is it just me? I can
successfully run make pkg only if I change line 295 from
 
mkdir -p "${1}/${theme}/Root/"

to

mkdir -p "${1}/${themes[$i]##*/}/Root/"

Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on August 24, 2011, 09:44:35 PM
 :o

opss...
nice!

I will commit this change.

PS by the way... I can compile the pkg with or without this...
but of course now the syntax is correct.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on August 26, 2011, 04:53:29 AM
Is the package/buildpkg.sh script broken, or is it just me?...
Scorpius, i have no such problem; can you check this again please?... and post the error log...
I also have no problems building with the code changes, but they don't make much sense to me.
Title: Re: Revisit Chameleon's package builder
Post by: zhell on August 29, 2011, 01:47:28 AM
Line 294 sets variable theme to the name of the theme at position i in the array themes, with a twist: it capitalizes the first letter of the theme name. Hence, if the array contains the entry "bullet", theme will be set to "Bullet".

The change by scorpius fixes a bug that may affect the execution of the subsequent rsync command (line 296) on case-sensitive file systems. The rsync command copies the theme into the directory created on line 295 and assumes that no capitalization has occurred, i.e. it uses "${1}/${themes[$i]##*/}/Root/", which matches the path used by "mkdir" on line 295.

The difference can be seen with this example:
Code: [Select]
% themes=($( find "${artwork%/*}/artwork/themes" -type d -depth 1 -not -name '.svn' ))
% echo $themes
/Software/Chameleon.svn/artwork/themes/bullet

% i=0
% set -- /Software/Chameleon.svn
% echo $1
/Software/Chameleon.svn

% echo "${1}/${themes[$i]}"
/Software/Chameleon.svn//Software/Chameleon.svn/artwork/themes/bullet

% echo "${1}/${themes[$i]##*/}/Root/"
/Software/Chameleon.svn/bullet/Root/

% echo "${1}/${theme}/Root/"
/Software/Chameleon.svn/Bullet/Root/
Note that the  ##*/ part in ${themes[$i]##*/} has the effect of stripping the all occurrences of "*/" from the variable ${themes[$i]}, corresponding to everything up to and including the last "/". An alternative would be the basename command.

Azimutz is right: the code is rather hard to understand and unnecessarily convoluted. The mkdir command is completely unnecessary. In fact, I believe that lines 295--301 could be done with a single call to rsync, using the --exclude and --chmod options.
Title: Re: Revisit Chameleon's package builder
Post by: scorpius on August 31, 2011, 05:16:36 PM
I forgot to mention that I use a case-sensitive file system (because it is a requirement for building Haiku). That's why I was the only one affected.

zhell is correct about using rsync -- and using the -C option skips the .svn directories as well.
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on September 01, 2011, 12:14:26 AM
Hi guys...
I forgot to mention that I use a case-sensitive file system (because it is a requirement for building Haiku). That's why I was the only one affected.

zhell is correct about using rsync -- and using the -C option skips the .svn directories as well.
And i was missing the point; Zell's post alerted me to it and to the fact that "verbosity is your friend!" :P
Did some changes related to this on my branch (r1474-->1489), check it out...
Basically, made sure we are "rsyncing" from e.g. trunk/artwork/themes/bullet to sym/package/Bullet/Root/Bullet and
used --exclude=.*; read about -C, but it doesn't handle .DS_store.

...
Azimutz is right: the code is rather hard to understand and unnecessarily convoluted. The mkdir command is completely unnecessary. In fact, I believe that lines 295--301 could be done with a single call to rsync, using the --exclude and --chmod options.
Zell, thanks for the explanation :)
About mkdir, i can't see a way of getting rid of it, at least doing it the way i'm doing; rsync needs sym/package/Bullet/Root/
preexisting to be able to create Bullet in it.
I also find no use for the chmod..?? The booter certainly has no need for it...
Title: Re: Revisit Chameleon's package builder
Post by: zhell on September 01, 2011, 10:50:23 AM
Hi Azimutz,

Glad you were not put off by my lengthy post. Here's an example of how rsync could do all in one line -- I think:
Code: [Select]
cd /tmp
# Set up some directory and file structure to play with
  mkdir -p Chameleon/Themes/bullet
  touch Chameleon/Themes/bullet/icon.png
  chmod 777 Chameleon/Themes # Set weird permissions
  chmod 777 Chameleon/Themes/bullet/icon.png # Set weird permissions
  mkdir Chameleon/Themes/.svn
  touch Chameleon/.DS_Store
# Now copy it into another directory, preserving the path starting from "Chameleon":
rsync -av --exclude='.*' --chmod=Da=rx,u+w,Fa=r,u+w --relative Chameleon/Themes/bullet Chameleon-Root
# As you can see, the permissions are now 755 for the directories and 644 for the files.
ls -lAR Chameleon-Root
total 0
drwxr-xr-x  3 admin  wheel  102 Sep  1 10:47 Chameleon

Chameleon-Root/Chameleon:
total 0
drwxr-xr-x  3 admin  wheel  102 Sep  1 10:47 Themes

Chameleon-Root/Chameleon/Themes:
total 0
drwxr-xr-x  3 admin  wheel  102 Sep  1 10:47 bullet

Chameleon-Root/Chameleon/Themes/bullet:
total 0
-rw-r--r--  1 admin  wheel  0 Sep  1 10:47 icon.png

Regarding capitalization, just use
Code: [Select]
theme='bullet'
echo "$(echo ${theme:0:1}|tr '[:lower:]' '[:upper:]')${theme:1}"
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on September 04, 2011, 10:55:41 AM
Hi Azimutz,

Glad you were not put off by my lengthy post. Here's an example of how rsync could do all in one line -- I think:
...
Hi Zell... "au contraire", the post was in fact motivational and constructive... no reason to put me off.
I get what you explained, been doing some "man rsync" reading my self; but as i see, there's not much to "preserve"
for the "for" loop, just the theme's name and in this case, setting permissions doesn't make much sense to me...
unless i'm missing something?!
Anyway, been playing a bit more with the stuff (r1501) and i'm pleased for now :)
Title: Re: Revisit Chameleon's package builder
Post by: Azimutz on September 06, 2011, 04:42:00 AM
Ok.. this is what i came with for a quick fix to the main problems i found on the package.
I was to make some separate commits, but they ended up all in r1510 (http://forge.voodooprojects.org/p/chameleon/source/commit/1510/) by distraction ::)
Since i already had planed to come here, not much was lost...
Focus on buildpkg.sh and postinstal's from EFI and Standard pkgs; resuming:
- fdisk440 and bdmesg are installed to /usr/local/* (just a preference of mine)
- made sure we find/use our fdisk440 for all boot0 installs using "bootresources" as var for the path
- the already commented Themes buildpkg code cleanup
- also made a quick test at moving files to the EFI partition

Still didn't made "live" tests, but so far all works as expected installing to external devices and mounted images,
both MBR and GPT. I will play a bit more with this, but don't know how much more :P
Anyway, if you guys like the solution i can commit the relevant parts to the trunk; if anyone has improvements
or a better solution just throw it to the table. To do better i need more time, reading, etc, etc, etc...
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 19, 2011, 12:53:13 PM
Hi Fabio

Can I ask what the following are for?
/trunk/package/dmg/* (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/package/dmg)
/trunk/package/Icons/* (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/package/Icons)

Can they be removed?

Ok.. this is what i came with for a quick fix to the main problems i found on the package.
...
Hey Azi

I've just seen your post about the changes in your 'package' branch. I tested your branch on 1st September, before going away for a break, and found it suffered the same problems as the package in the trunk at that time (as reported here (http://forge.voodooprojects.org/p/chameleon/issues/168/)) but I see you've updated it since then. Sorry I didn't see the changes sooner. I'll have a look at it.

Only today I've been looking at these scripts too and have merged some of the work I had previously done (as discussed here (http://forum.voodooprojects.org/index.php/topic,1521.msg8894.html#msg8894)) in to my branch. I've not included any of the scripts/methods I attempted back then for building the c.a.B.p (now o.c.B.p) so no fear with any rogue 'rm' commands. I need to run some more tests at my end before saying anymore, but for now my branch shows where I'm at.

EDIT:
I've only had a quick look through your 'package' branch and have mode some notes to your comments.

1) Standard install - Keep 'msdos' install option as user could select to install to a FAT32 USB flash drive.

2) Hiding the boot file (as you've said) is questionable and I prefer it visible, as you do. However, hiding it should be done with SetFile as it works on FAT32 as well as HFS. I agree that there's no point hiding it on he EFI System Partition.

3) EFI System Partition install - I never use it for real either, just for testing but I guess it's a feature which some users like to use.
3a) You say setting active partition for EFI system partition is not needed. I'll have to run a test to check.
3b) You're right by saying the default ESP is a special format and not msdos (I remember you posted somewhere with more details) but for checking purposes, sudo fstyp /dev/disk0s1 on my iMac returns msdos. This is fine for the checks the script uses as it uses the identification to choose which stage 1 file to use (boot1h or boot1f32) - The script does not format the partition.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 19, 2011, 07:50:24 PM
Hi Fabio

Can I ask what the following are for?
/trunk/package/dmg/* (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/package/dmg)
/trunk/package/Icons/* (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/package/Icons)

Can they be removed?

Hi Blackosx
the two dir are dedicated for store "icons" and "stuff" for the creation of the .dmg
At this time feel free to delete the dmg folder, but the Icon folder is needed..
I try to explain...
Into the buildpkg.sh I commented the part relate to the Icon for the package...
from:
Code: [Select]
...
popd >/dev/null

#   Here is the place for assign a Icon to the pkg
#   command use to generate the file:
#   ditto -c -k --sequesterRsrc --keepParent Icon.icns Icon.zip
# ----
#   ditto -xk "${pkgroot}/Icons/pkg.zip" "${pkgroot}/Icons/"
#   DeRez -only icns "${pkgroot}/Icons/Icons/pkg.icns" > tempicns.rsrc
#   Rez -append tempicns.rsrc -o "${1%/*}/$packagename-${version}-r$revision.pkg"
#   SetFile -a C "${1%/*}/$packagename-${version}-r$revision.pkg"
#   rm -f tempicns.rsrc
#   rm -rf "${pkgroot}/Icons/Icons"
# End

md5=$( md5 "${1%/*}/${packagename// /}-${version}-r${revision}.pkg" | awk {'print $4'} )
...

to
Code: [Select]
...
popd >/dev/null

#   Here is the place for assign a Icon to the pkg
#   command use to generate the file:
#   ditto -c -k --sequesterRsrc --keepParent Icon.icns Icon.zip
# ----
    ditto -xk "${pkgroot}/Icons/pkg.zip" "${pkgroot}/Icons/"
    DeRez -only icns "${pkgroot}/Icons/Icons/pkg.icns" > tempicns.rsrc
    Rez -append tempicns.rsrc -o "${1%/*}/$packagename-${version}-r$revision.pkg"
    SetFile -a C "${1%/*}/$packagename-${version}-r$revision.pkg"
    rm -f tempicns.rsrc
    rm -rf "${pkgroot}/Icons/Icons"
# End

md5=$( md5 "${1%/*}/${packagename// /}-${version}-r${revision}.pkg" | awk {'print $4'} )
...
If you un-comment that part and try build the pkg (make pkg) the pkg will be created with the beautiful icon, but that change is immediately lost by the tar compression (the compression eradicate that icon... strange but true), next if you uncompress the archive the pkg is w/o icon, probably this is a "feature" coming from the TAR command I really don't know...


Anyway I prefer not delete the Icon directory...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 20, 2011, 06:21:19 PM
Thanks for the reply Fabio.
So is there a grand plan to eventually distribute a Chameleon .dmg?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 20, 2011, 11:38:43 PM
The .dmg need some more correction, and now (in my branch...) it will create with make dmg, but I'm not to happy with the way I do it...
Is there a pre-maded image and is just a copy from the new file and overwrite on the old...
Is a unfinished work in progress...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on September 25, 2011, 10:18:16 AM
Is a unfinished work in progress...
Thanks for letting me know :)

I see you've merged (http://forge.voodooprojects.org/p/chameleon/source/commit/1568/) the package folder from my branch to yours. Please note that my branch is a work in progress too and I'm planning to change it even more in the coming weeks.

One thing I've noticed with your branch since the merge and your latest changes is that you will need to change the install location for the following added modules, from /Extra/modules to /tmpcham/Extra/modules in buildpkg.sh if you want to them to be placed correctly in the /Extra folder.
AMDGraphicsEnabler.dylib
ATiGraphicsEnabler.dylib
IntelGraphicsEnabler.dylib
NVIDIAGraphicsEnabler.dylib

So for example:
from:
Code: [Select]
buildpackage "${1}/AMDGraphicsEnabler" "/Extra/modules" "" "start_selected=\"false\"" >/dev/null 2>&1to
Code: [Select]
buildpackage "${1}/AMDGraphicsEnabler" "tmpcham/Extra/modules" "" "start_selected=\"false\"" >/dev/null 2>&1
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 25, 2011, 01:38:05 PM
THX Blackosx.

I "correct" it.
I move the GraphicsEnabler to Module only for test the buildpkg & Localizable.strings "job" and works ;)

I commit also to the trunk code the UseKernelCache choice.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on September 26, 2011, 01:17:16 AM
I play with the main makefile.
Commit 1576.
I change the final compression for the package, from "gzip --best" to ditto command

Result now the pkg is compressed and the content preserve the ICON !!! :D

Makefile
from:
Code: [Select]
pkg installer: all
${SRCROOT}/package/buildpkg.sh ${SYMROOT}/package;
@echo "\t[GZ] ${DISTFILE}.pkg"
@gzip --best ${DISTFILE}.pkg
to:
Code: [Select]
pkg installer: all
${SRCROOT}/package/buildpkg.sh ${SYMROOT}/package;
@echo "\t[ZIP] ${DISTFILE}.pkg"
@ditto -c -k --sequesterRsrc ${DISTFILE}.pkg ${DISTFILE}.zip
@rm -r ${DISTFILE}.pkg
and into the buildpkg.sh (as I say some post ago...)
from:
Code: [Select]
#   Here is the place for assign a Icon to the pkg
#   command use to generate the file:
#   ditto -c -k --sequesterRsrc --keepParent Icon.icns Icon.zip
# ----
#    ditto -xk "${pkgroot}/Icons/pkg.zip" "${pkgroot}/Icons/"
#    DeRez -only icns "${pkgroot}/Icons/Icons/pkg.icns" > tempicns.rsrc
#    Rez -append tempicns.rsrc -o "${1%/*}/$packagename-${version}-r$revision.pkg"
#    SetFile -a C "${1%/*}/$packagename-${version}-r$revision.pkg"
#    rm -f tempicns.rsrc
#    rm -rf "${pkgroot}/Icons/Icons"
# End
to:
Code: [Select]
#   Here is the place for assign a Icon to the pkg
#   command use to generate the file:
#   ditto -c -k --sequesterRsrc --keepParent Icon.icns Icon.zip
# ----
    ditto -xk "${pkgroot}/Icons/pkg.zip" "${pkgroot}/Icons/"
    DeRez -only icns "${pkgroot}/Icons/Icons/pkg.icns" > tempicns.rsrc
    Rez -append tempicns.rsrc -o "${1%/*}/$packagename-${version}-r$revision.pkg"
    SetFile -a C "${1%/*}/$packagename-${version}-r$revision.pkg"
    rm -f tempicns.rsrc
    rm -rf "${pkgroot}/Icons/Icons"
# End

:D
Now I not commit personally this change into main trunk code (I hope meklort or other do that...)
No idea about the effect for the Builtbot and the better compression method....

Anyway the "patch" is this and finally the Icon can be showed!

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: meklort on September 26, 2011, 03:38:39 AM
I've been a bit busy lately, but I'll see if I can find some time this week to look it over. As far as buildbot changes, it'll just be one line in a config file.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 03, 2011, 10:27:22 PM
I follow the recently changes into the Blackosx's branch

Good works! Blackosx!

From now I no find issue...

You think is ready to merge it into the main code?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 04, 2011, 09:04:18 AM
Good works! Blackosx!

From now I no find issue...
Hi Fabio

Thanks for trying out the package installer in my branch. It's working well here too and I have performed many successfully test installations running it.

I've made many tweaks to the existing scripts. The slimpkg script now matches the buildpkg script where applicable and I've changed, renamed, added and removed folders and files in the package folder so it probably looks quite different to how you knew it. Boot0md now supersedes Boot0hfs throughout. If there is an existing /Extra folder at the root of the target partition it will be backed up by the installer before making a new one.

One of the big changes I've made is to incorporate the scripts from my previous work on the package installer (http://forum.voodooprojects.org/index.php/topic,1521.msg8870.html#msg8870), though this time link them in to work with the buildpkg script. I had learned a bit about packages when I'd previously played with Packagemaker so that helped me understand the process better, though I still haven't read and understood everything. But to be honest building the package without using the Packagemaker app GUI is by far a better way to do it. It's worth noting that I haven't included the part of code from my previous scripts which deleted /Volumes/EFI after installing to the EFI system partition as this I believed was (somehow) the source of the problem in the past. So currently this needs to be removed manually.

The other big change is there is now an install log generated by the installer which gets saved to the root of the selected target partition. This is so users can know what has been installed where on their system as I have read many posts in the past here from users who either can't find the installed files, or have more than one /Extra folder so any changes made aren't reflected upon next boot. I have a plan to add a feature for the install scripts to scan a users machine for other existence(s) of Chameleon and notify users prior to installation.

I've changed the way boot options and kernel flags are setup/managed/created as having an exact same script using the exact same code for each boot option seemed silly and was a waste of time when it came to making changes. It's quite dynamic now and very simple to add/remove/change them and I've also tried to make use of the 'exclusive' option which is working, but I haven't figured out how (if possible) to set the 'choose none' option to be selected by default.

The code is functional but I'm sure it can be simplified/improved by someone with a wider knowledge of bash scripting commands.

The English localizable strings have changed and I might  re-order them again at some point so the other languages will need to be updated to match. I know you've put much work in to adding different languages so sorry to have created more work for either you or someone else.

There are more things to improve/change and add in time but most of the big changes have been done for now. There is no support for RAID yet, though it's something I feel the installer should be able to deal with. And maybe the order/folders of boot options that I currently have could be changed?

You think is ready to merge it into the main code?

I think soon, but I would prefer to hear more feedback and see some results from more users trials before it is and for that I will need to post a preview test package. I'll try to do that later today.

UPDATE:
Here's a beta v1 of the package installer from my branch.

It's built from the exact code from my branch apart from:
• All the languages other than English have been removed.
• The two 'Exclusive' options have been disabled.
• The Welcome.rftd and Conclusion.rtfd files have been changed to include '(Beta test installer v1 - blackosx branch)'.
• buildpkg.sh has had '(blackosx branch)' removed from being appended to stage=${version##*-}

UPDATE 2:
v1 removed and v2 now posted.
Changed post script so it won't make an empty Extra folder when not needed.

UPDATE 3:
v2 removed and v3 now posted.
Added a check for an existing Chameleon installation on a different partition of same target disk to help stop new users from confusing themselves.

UPDATE 4: 5th October 23:30
v3 removed and v4 now posted.
Don't create /Extra folder if process is stopped due to exisiting Chameleon installation found.

UPDATE 5: 7th October 08:21
v4 removed and v5 now posted.
Tweaks and code cleanups. This could almost be the final beta?

UPDATE 6: 7th October 15:19
v5 removed and new beta package now posted to InsanelyMac (http://www.insanelymac.com/forum/index.php?s=&showtopic=231075&view=findpost&p=1757062) for testing.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 04, 2011, 08:16:33 PM
Hi Blackosx.

Feel free to post in the Chameleon package topic @IM for a large scale test :p

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 05, 2011, 12:12:52 AM
Thanks Fabio. I'll do so when I think it's ready.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 05, 2011, 02:05:10 AM
Thanks Fabio. I'll do so when I think it's ready.
Hi Blackosx.

Translating here and "merge" your tweak into my branch...
one question
from your English Localizable.strings
Quote
// ============================================================================
// Exclusive boot options string - These are added automatically by buildpkg
// Name to be used should be ChooseNone-xxxxxx
// Where xxxxx = the name of the BootOptions file (minus the .txt)
// ----------------------------------------------------------------------------
"ChooseNone-Resolution_title" = "None";
"ChooseNone-Resolution_description" = "Don't choose a resolution.";

"ChooseNone-keylayout_title" = "None";
"ChooseNone-keylayout_description" = "Don't choose a keylayout.";

??? how exactly use that?


Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 05, 2011, 08:26:01 AM
When using the exclusive option, the package installer will force the user to select only one option in that list and will select one of the existing options as enabled by default ( I haven't figured out how to control that default option yet).  But in the instance where the user won't want to select any of the options, not even the default one, there would be no option in the list that reads 'don't install'.

There are two approaches to this:
1) Add a 'Don't Install' line to the top of each option list where Exclusive=True.
2) Have buildpkg add the 'Don't Install' option automatically when it finds an option list where Exclusive=True.

I chose to go with option 2.

Now, there has to be a unique title/description for each package installer option in localizable.strings. This means that I can't have a 'Don't Install' option for each options list where Exclusive=True as doing so has the side effect of when clicking one of them, the others also act as they've been ticked too.

To overcome this, buildpkg adds a new option in to the list using the name 'ChooseNone-' followed by the filename of the options list (not including .txt). So for example:
• for the Resolution.txt options list, it'll be named: ChooseNone-Resolution.
• If you make a new list named abcdefg.txt list, it'll be named: ChooseNone-abcdefg.

Note: For keylayouts, the exclusive option is set in the buildpkg code because the keylayout package installer options are automatically generated based on the contents of the Keymaps folder created when compiling Chameleon. But the same principle applies for the exclusive option and it'll be named: ChooseNone-keylayout.

So for any option list that uses Exclusive=True, there should be an equivalent title/description in the localizable strings using the ChooseNone-xxxxxx name.

Hope this helps.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 16, 2011, 01:07:37 AM
Hi Blackosx.

Yesterday I upload all the language "modified" with your English Layout.
In this way is easy for Existing semi-translated language finish the job.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 16, 2011, 11:33:25 PM
Great. That'll make updating the trunk with the revised package installer code simpler.

I'm pretty happy the installer is working well. I submitted commit 1630 (http://forge.voodooprojects.org/p/chameleon/source/commit/1630/) today to add some code for trying to keep a users system intact if they try to install a secondary Chameleon boot partition to their HDD. It's working here, but it needs some testing so I've posted the latest build to your topic at InsanelyMac.

Ideally I want to take a step back and look at the whole package installer code to maybe organise it better as I've been adding extra code here and there, and clean it up. And I still have to work out how to set what will be the default choice if the 'exclusive' option is used.

But overall I think it'll soon be ready to merge with the trunk.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 21, 2011, 01:33:07 AM
quick question...

now the ShowInfo key now is set by default to no from ...(I no remember the commit number..)

So Is better set that info also into the Localizable.strings file and for the new "layout"
from (Localizable.strings)
Quote
"ShowInfo_title" = "ShowInfo=No";
"ShowInfo_description" = "Disables display of partition and resolution details shown on the left side of the GUI under the boot banner. This is useful information for troubleshooting, though can clash with certain themes.";
to (localizable.strings)
Quote
"ShowInfo_title" = "ShowInfo=Yes";
"ShowInfo_description" = "Enables display of partition and resolution details shown on the left side of the GUI under the boot banner. This is useful information for troubleshooting, though can clash with certain themes.";

and from (Blackosx's OptionalSettings/Control.txt)
Quote
...
QuietBoot:QuietBoot=Yes
ShowInfo:ShowInfo=No
Wait:Wait=Yes
to
Quote
...
QuietBoot:QuietBoot=Yes
ShowInfo:ShowInfo=Yes
Wait:Wait=Yes

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 21, 2011, 08:10:23 AM
I've just checked and yes you're right. I didn't realise it had been changed.

I'll update my branch to reflect this. Thanks for the information Fabio.
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 21, 2011, 06:34:10 PM
Fabio. In commit 1644 (http://forge.voodooprojects.org/p/chameleon/source/commit/1644/) of my branch, I've enabled building the .dmg that you worked on.

I changed the builddmg.sh script slightly to work with the latest name convention for the package installer, and also to just copy the BootHelp.txt and Users_Guide0.5.pdf in the documentation folder rather than everything from the /docs folder. So far so good.

I look at seeing what else I can do with it when I get some time. :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 23, 2011, 04:01:42 AM
Hi Blackosx

thx for take a look and tweak the dmg part...

- would be nice rewrite the builddmg.sh script... until now that script overwrite recently compiled content into "old" pre-made
dmg image (look into ../package/dmg/ro.dmg)
I used this way because I have problem with resouce fork (.DS_Store file) and his creation...

- Also I need to "find" time to write a good "EULA" (Also resource fork file) to use with openUP utility (present into chameleon source "../i386/util/openUp.c" thx meklort to add it)
Because as you can see (from terminal.app) the build process "fails" in that part...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 24, 2011, 06:45:28 PM
Hi Fabio

I haven't had time to look any further at the builddmg script but when I do I'll let you know.

But I see you've added a screenshot for the EULA for openUP. It looks good to me.
If that's all that's required then great. Well done :)

Have you added it to your branch?
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 25, 2011, 04:20:58 AM
Hi!

No the idea is this... that EULA pop up coming from a test dmg also posted at Insanelymac .. dmg rev 747...

I find a good editor for the resource fork file
Resorcerer

Tiny progress :)
Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 26, 2011, 11:53:26 AM
Hi Fabio

In your commit #1666 (http://forge.voodooprojects.org/p/chameleon/source/commit/1666/), I see you've re-added the fifth parameter for the makedistribution function.
Code: [Select]
makedistribution "${1}" "${2}" "${3}" "${4}" "${5}"
I couldn't see that used anywhere so I disabled it with the intent to eventually removing it. Have I missed something?

No the idea is this... that EULA pop up coming from a test dmg also posted at Insanelymac .. dmg rev 747...
Thanks for the info.
I will start looking at the builddmg script soon. :)
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 26, 2011, 08:30:17 PM
Hi Blackosx.
I readd the 5th parm. and the command rm just to preserve the folder clean when I build the pkg...
Probably is only need the rm... I do the change quickly and I no check it in deep...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 29, 2011, 08:41:35 AM
would be nice rewrite the builddmg.sh script... until now that script overwrite recently compiled content into "old" pre-made
dmg image (look into ../package/dmg/ro.dmg)
I used this way because I have problem with resouce fork (.DS_Store file) and his creation...
Hi Fabio

After a few days looking in to the best method to automatically create a disk image (dmg), I have seen, most probably, the same info you must have found where many users have in the past tried scripting the creation of one. And while a base dmg is easy to create, there is little information available when it comes to setting up icon sizes, positions and backgrounds from scratch using code.

Details of the .DS_Store file are hard to come by and I did run some tests to look at the file structure (hex) before and after making changes to a dmg to look for any clues as to what could be changed but it looks like I won't be able to do anything with it. I did find this post (https://wiki.mozilla.org/DS_Store_File_Format) showing the attempt by Mark Mentovai to reverse-engineer the file but even with this I wouldn't really know where to start or even if we really should bother.

Therefore, I recommended leaving the dmg creation process to how you are currently doing it by changing the pre-made /package/dmg/ro.dmg file. We could probably reduce the template file size by including a smaller Chameleon.pkg as it's going to be replaced anyhow.

I'm not going to spend any more time on the dmg for now, and work towards finalising the package installer code from my branch ready for merging to the trunk.

Probably is only need the rm... I do the change quickly and I no check it in deep...
Yep. I forgot to uncomment the rm's. Will do that before final version.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 30, 2011, 09:11:36 PM
Nice work Blackosx!

 :-\ a lot of work for me to reorganize the language  :o

I delete the dmg content/stuff from the trunk (maybe in a remote future we tweak it)

For the Welcome, description an conclusion file I do the change in my branch and I will merge into trunk when I have a tiny number of language... (I prefer no increase the trunk number and do job for buildbot :P)...

As I propose @InsanelyMac maybe a poll for chose a background?
Can you propose some different Images? 5 or 10 :O

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 30, 2011, 11:34:31 PM
Hi Fabio

I hope you don't think I've jumped the gun with my latest commit to the trunk, but the topic @ IM didn't result in any negative feedback, and the questions that were posted, I provided an update for. I felt that the new code was better than what was already in the trunk and was ready for inclusion. I/we can still work on it when we get time.

:-\ a lot of work for me to reorganize the language  :o
.../snip/...
For the Welcome, description an conclusion file I do the change in my branch and I will merge into trunk when I have a tiny number of language... (I prefer no increase the trunk number and do job for buildbot :P)...
Sorry about that, but hard coded text always runs the risk of needing to be updated at some point.

I wouldn't have thought it would be too much work to sort the languages as you had/have a record of who translated the text previously. Would it be possible to drop them a PM to make a translation of the latest text? The localizable.strings file should all be up to date, other than the three 'Install Type' options, which just leaves the Conclusion, Description and Welcome files. If you're happy to do that in your branch then that's fine with me.

I think there is a revised text from Tenval and Crazybirdy already but IM has been down so I haven't been able to grab them.

I delete the dmg content/stuff from the trunk (maybe in a remote future we tweak it)
It's still there now. Do you want me to delete it from the trunk?

As I propose @InsanelyMac maybe a poll for chose a background?
Can you propose some different Images? 5 or 10 :O
Don't you like my revised background?
I appreciate you created the previous one so I understand you'll probably want to stick with what was there, but to be honest, I quite like the new one so I'm slightly biased towards not changing it. However, if you want to change it, or host a poll for different styles then feel free.  :P
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on October 31, 2011, 12:43:42 AM
No problem Blacosx!

Is just a comment/idea :)

dmg stuff removed ;)

We can remove also the package/Configuration folder??

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on October 31, 2011, 08:39:08 AM
Yes, the Configuration folder can be removed as it's currently not used. There is already a SMBIOS.plist in the package/ folder so the SMBIOSDefault isn't really needed. And I haven't looked at the Chameleon.prefPane in a long time but I would guess it would need updating as it was over a year ago that rekursor wrote it.

I'll remove it now.
EDIT - Done.

Anything can be re-added at a later date if you want.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 12, 2011, 04:21:24 AM
Hello Blackosx.

You have done an exemplary job in restructuring the pkg.
Again congratulations!

We can add "SMBIOS.plist" ready to use?

like a new choice...

What do you think..?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 12, 2011, 05:49:22 PM
Hi Fabio

Thanks.
Let me know exactly what you had in mind and I'll look in to it, though I can't promise anything  :P
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 12, 2011, 09:24:03 PM
Thx for reply.

It would be useful to have a selectable list of smbios.plist.
Ready to use, to be copied/overwrite during installation of the bootloader (Chameleon), in the Extra folder.
The SMBIOS would already "prepared" and based on functional SMBIOS.
example of SMBIOS list:

- MacBook2.1
- ....
- MacBookPro...
- MacBookPro8.3
- ....
- iMac....
- iMac12.2
- ....
- MacPro2,1
- MacPro3,1
- MacPro4,1
- MacPro5,1
and so on ...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 14, 2011, 03:19:19 PM
Isn't this what the SMBIOSDefaults boot option does?

If I add SMBIOSDefaults to the installer, and the user chooses to add that boot option then the bootloader should choose the best basic match for the users system, based on their CPU. I think that's how it works.

Here's the embedded defaults:
http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/smbios.c

Would this fulfil what you need?

EDIT:
Just tested and can report that SMBIOSDefaults are enabled in Chameleon by default but only used when a SMBIOS.plist is not found.
Removing my SMBIOS.plist from /Extra and rebooting in to Lion with Chameleon I see I have a MacPro4,1 settings as defined here (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/smbios.c#L106).
The only boot option available to add then would be SMBIOSDefaults=No to turn this off.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 23, 2011, 01:51:13 AM
Hi all!

With latest changes into package (commit 1741)
I have some "warning" error. relate to cpio
here the log:

Code: [Select]
Last login: Fri Dec 23 00:20:42 on console
Fabio:~ iFabio$ cd /Users/iFabio/Desktop/trunk
Fabio:trunk iFabio$ make pkg
[MKDIR] /Users/iFabio/Desktop/trunk/sym
// -- -- //
SPLI SPLIT
// -- -- //
================= Making all in layouts =================
/Users/iFabio/Desktop/trunk/package/buildpkg.sh /Users/iFabio/Desktop/trunk/sym/package

  ----------------------------------
  Building Chameleon Install Package
  ----------------------------------

================= Preinstall =================
[BUILD] Pre
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Core =================
[BUILD] Core
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Chameleon =================
[BUILD] New
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Upgrade
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Chameleon =================
[BUILD] Standard
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] EFI
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] noboot
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Modules =================
[BUILD] klibc
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] AutoReso
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] uClibc
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Keylayout
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Control =================
[BUILD] BootBanner
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] GUI
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] LegacyLogo
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] InstantMenu
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] QuietBoot
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] ShowInfo
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Wait
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= General =================
[BUILD] arch
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] EHCIacquire
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] EthernetBuiltIn
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] ForceHPET
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] ForceWake
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] RestartFix
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] UHCIreset
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] UseMemDetect
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] UseKernelCache
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Wake
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= KernelFlags =================
[BUILD] Verbose
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Singleusermode
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Ignorecaches
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Npci
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Darkwake
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= PowerManagement =================
[BUILD] CSTUsingSystemIO
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] DropSSDT
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] EnableC2State
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] EnableC3State
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] EnableC4State
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] GenerateCStates
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] GeneratePStates
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Resolution =================
[BUILD] 1024x600x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1024x768x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1280x768x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1280x800x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1280x960x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1280x1024x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1440x900x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1600x900x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1680x1050x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1920x1080x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] 1920x1200x32
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Video =================
[BUILD] GraphicsEnabler
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] UseAtiROM
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] UseNvidiaROM
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] VBIOS
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Keymaps Options =================
[BUILD] mac-de
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] mac-es
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] mac-fr
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] mac-it
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] mac-se
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] pc-fr
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Themes =================
[BUILD] Bullet
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Default
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Embed
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
[BUILD] Legacy
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
================= Post =================
[BUILD] Post
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
cpio: Couldn't lookup user ``0'': No such file or directory
Brief Usage:
  List:    cpio -it < archive
  Extract: cpio -i < archive
  Create:  cpio -o < filenames > archive
  Help:    cpio --help
Error encountered while processing file : /Users/iFabio/Desktop/trunk/sym/package/Chameleon/EFI.pkg/Scripts
Error encountered while processing file : /Users/iFabio/Desktop/trunk/sym/package/Chameleon/Post.pkg/Scripts
Error encountered while processing file : /Users/iFabio/Desktop/trunk/sym/package/Chameleon/Pre.pkg/Scripts
Error encountered while processing file : /Users/iFabio/Desktop/trunk/sym/package/Chameleon/Standard.pkg/Scripts

 --------------------------
 Building process complete!
 --------------------------

 Build info.
 ===========
  Package name: Chameleon-2.1svn-r1741.pkg
  MD5:          fd89332c2936d07248b35ddd04e319c4
  Version:      2.1svn
  Stage:        2.1svn
  Date/Time:    2011-12-23 00:48:07

Fabio:trunk iFabio$


Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 23, 2011, 08:43:21 AM
Hi Fabio

The trunk builds fine here and I see no errors, so I'm surprised you see this.

You should be able to set ownership to files/groups using -R 0:0.
Maybe a permissions error at your end?

For a test, try changing lines 549 and 557 in buildpkg.sh from
Code: [Select]
.......| cpio -o -z -R 0:0 --format .......to
Code: [Select]
.......| cpio -o -z -R root:wheel --format .......
Regards
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 24, 2011, 04:09:15 AM
Thx Blackosx.

the "error" is gone...
I also add >/dev/null 2>&1 at the end of all "buildpackage" line for a "clean" log-output.
ex: from
Code: [Select]
buildpackage "$packageRefId" "${choiceId}" "${1}/${choiceId}" "/"to
Code: [Select]
buildpackage "$packageRefId" "${choiceId}" "${1}/${choiceId}" "/" >/dev/null 2>&1
But still some problem...
I try... build the package (make pkg), and the package folder is not deleted after the creation of pkg. see picture
???

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 24, 2011, 06:21:51 PM
the "error" is gone...
I also add >/dev/null 2>&1 at the end of all "buildpackage" line for a "clean" log-output.
Great :)

But still some problem...
I try... build the package (make pkg), and the package folder is not deleted after the creation of pkg. see picture
???
It's not really a problem. Just uncomment line 501 (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/package/buildpkg.sh#L501) of buildpkg.sh.
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on December 28, 2011, 10:54:28 AM
I also add >/dev/null 2>&1 at the end of all "buildpackage" line for a "clean" log-output.
ex: from
Code: [Select]
buildpackage "$packageRefId" "${choiceId}" "${1}/${choiceId}" "/"to
Code: [Select]
buildpackage "$packageRefId" "${choiceId}" "${1}/${choiceId}" "/" >/dev/null 2>&1
Hi ErmaC,
don't do that because we'll don't see futur errors. It's a bad idea to mask error with redirections to /dev/null. It's much better to resolv the cause of error.

But still some problem...
I try... build the package (make pkg), and the package folder is not deleted after the creation of pkg. see picture
???

Fabio

This is the normal process now Fabio so we can inspect generated pkgs and the distribution file.
If we want to remove properly the generated files do a
Code: [Select]
make cleanor
Code: [Select]
make distclean
Best regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on December 28, 2011, 12:34:44 PM
This is the normal process now Fabio so we can inspect generated pkgs and the distribution file.
Thanks for this confirmation JrCs. I didn't want to change anything that I wasn't sure of so I left that alone in my latest commit.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 28, 2011, 02:28:50 PM
Best regards,
JrCs

Thanks for explain!
:)

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on December 28, 2011, 05:16:41 PM
@ErmaC: i don't understand why you have some errors setting uid/gid with cpio.

Do you use the Apple cpio (Snow Leopard or Lion) and not another one like macports or fink ?
Do you build package into a Virtual Machine ?
Can you check with the command id root if it return the good name for uid and gid.
id root must return something like this:
uid=0(root) gid=0(wheel) .....

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on December 28, 2011, 05:43:32 PM
@ErmaC: i don't understand why you have some errors setting uid/gid with cpio.

Do you use the Apple cpio (Snow Leopard or Lion) and not another one like macports or fink ?
Do you build package into a Virtual Machine ?
Can you check with the command id root if it return the good name for uid and gid.
id root must return something like this:
uid=0(root) gid=0(wheel) .....

JrCs

Xcode 4.2 on Snow Leopard 10.6.8 (Real not virtualized)

Here the output
Code: [Select]
Last login: Wed Dec 28 13:37:44 on ttys000
Fabio:~ iFabio$ id root
uid=0(root) gid=0(wheel) groups=0(wheel),401(com.apple.access_screensharing),402(com.apple.sharepoint.group.1),204(_developer),100(_lpoperator),98(_lpadmin),80(admin),61(localaccounts),29(certusers),20(staff),12(everyone),9(procmod),8(procview),5(operator),4(tty),3(sys),2(kmem),1(daemon),403(com.apple.sharepoint.group.2)
Fabio:~ iFabio$

I installed macport some mounts ago...
Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on January 03, 2012, 11:07:34 AM
Hi all, and happy new year !!!

I have made a lot of improvements in the buildpkg script:

I have simplify the creation of the menu:
use addGroupChoices to add a "main menu" and addChoice to add an option to the menu.
For example for the video mode options the menu is created like this
Code: [Select]
addGroupChoices "Options"
addGroupChoices --parent="Options" --exclusive_zero_or_one_choice "Resolution"
addChoice --group "Resolution" "1024x600x32" "org.chameleon.options.resolution.1024x600x32"

I have made a lot of checks to be sure that the Distribution file is correct.

Another thing i have change is the backup. Now all the backups are store in Chameleon.Backups directory of the target volume. It contains one directory by backup. And in the backup folder there are ALL the files needs by chameleon (like Extra, stage2 file boot, the installer log, etc...). With that a user can restore completly his chameleon install from moving all the files in the backup folder to the root.

I hope that this changes will be usefull for you.

Best regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 03, 2012, 11:33:22 PM
Happy New Year too JrCs.  ;D

I have seen the extra work you've put in to the package installer, especially buildpkg.sh. Well done again.
It's great to see some fresh code being turned out which I can hopefully learn from. It will take me a while to get my head around all the changes but I'll get there.

I've made a local change to the preinstall script to only create Chameleon.Backups and write to the install log if boot or /Extra exist at the target locations. I'll commit it to my branch later, but in the mean time I have been trying to add to the Javascript in the Distribution file to also look for a com.apple.Boot.plist for users upgrading from legacy installations. However, my Javascript isn't so great and the code I have so far only works as far as finding the first plist condition but never goes on to finding the second if the first is not found.

Can you please show me what I'm doing wrong or otherwise maybe implement the feature yourself? Here's what I have:

Code: [Select]
    function get_chameleon_boot_plist() {
        if (my.target) {
            if (my.target.mountpoint + '/Extra/org.chameleon.Boot.plist') {
                var chameleon_boot_plist = my.target.mountpoint + '/Extra/org.chameleon.Boot.plist'
                return system.files.plistAtPath(chameleon_boot_plist);
            }
            // Add support for legacy installations.
            if (my.target.mountpoint + '/Extra/com.apple.Boot.plist') {
                var chameleon_boot_plist = my.target.mountpoint + '/Extra/com.apple.Boot.plist'
                return system.files.plistAtPath(chameleon_boot_plist);
            }
        }
        return null;
    }

Regards
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on January 04, 2012, 09:35:37 AM
Hi Blackosx,

your problem is the:
Code: [Select]
if (my.target.mountpoint + '/Extra/org.chameleon.Boot.plist') that is always true !

The best is to have an array with the 2 files:
Code: [Select]
var boot_plist_files=new array('org.chameleon.Boot.plist', 'com.apple.Boot.plist');and you create a loop to check the file in the array. The loop must end if the plist exists.

Tell me of you want me to make the code

Regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 04, 2012, 11:23:29 AM
your problem is the:
Code: [Select]
if (my.target.mountpoint + '/Extra/org.chameleon.Boot.plist') that is always true !
Even if /Extra/org.chameleon.Boot.plist doesn't exist?

The best is to have an array with the 2 files:
Code: [Select]
var boot_plist_files=new array('org.chameleon.Boot.plist', 'com.apple.Boot.plist');and you create a loop to check the file in the array. The loop must end if the plist exists.
Maybe something like this?
Note: This it's just something I've thrown together here for responding to your suggestion. It's without any tests and might not even be correct javascript syntax.
Code: [Select]
var boot_plist_files=new array('org.chameleon.Boot.plist', 'com.apple.Boot.plist');
var i=0;
var chameleon_boot_plist = "";
while (i<=boot_plist_files.length && chameleon_boot_plist = "" ) {
    if (my.target.mountpoint + '/Extra/'boot_plist_files[i])
        var chameleon_boot_plist = my.target.mountpoint + '/Extra/'boot_plist_files[i];
    i++;
}
if (chameleon_boot_plist != "")
    return system.files.plistAtPath(chameleon_boot_plist);
else
    return null;


Tell me of you want me to make the code
Yes please..  :P
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on January 05, 2012, 08:39:52 PM

Tell me of you want me to make the code
Yes please..  :P


Done, commited in trunk.

Regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 06, 2012, 08:35:12 PM
Thanks JrCs.
Nice job.  ;D
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 07, 2012, 10:30:21 AM
Hi JrCs

Good work with the latest round of refinements to the installer. I'm enjoying seeing the changes you're making.

However, I've found an issue with a recent functionality....
When running the package installer, it's options are now populated by reading a previous org.chameleon.Boot.plist (if found). This now presents the user the choice to deselect a previously used option/kernel flag. But this doesn't work

I think a routine is needed in the postinstall script to deal with this scenario. What do you think?

Regards
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on January 21, 2012, 08:55:15 PM
Hi guys!!

About: commit 1808   by blackosx.
Revise layout of package installer 'Welcome' file so it looks cleaner. Change the copyright notice to begin from 2009 as seen in the Chameleon 2.0 r431 installer. Should this date be set earlier?

Maybe we can use the same "method" for the credits?
like a %CPRYEAR% taked from CREDITS file and replaced into all the needed Resources file.

Like this:
add at line 16, 17 and 18
Quote
...
Package:
---------
kalyway, AzimutZ, blackosx, ErmaC, scrax, JrCs

Copyright:
---------
2009-2012

then in all the Welcome and Conclusion file (yep I add copyright year also in conclusion file)
replace the copyright string with:
from
Copyright © 2009-2012
to
Copyright © %CPRYEAR%

then into buildpkg.sh script add
this line
Quote
# ====== CREDITS ======

declare -r CHAMELEON_DEVELOP=$(awk "NR==6{print;exit}"  ${PKGROOT}/../CREDITS)
declare -r CHAMELEON_CREDITS=$(awk "NR==10{print;exit}" ${PKGROOT}/../CREDITS)
declare -r CHAMELEON_PKGDEV=$(awk "NR==14{print;exit}"  ${PKGROOT}/../CREDITS)
declare -r CHAMELEON_CPRYEAR=$(awk "NR==18{print;exit}"  ${PKGROOT}/../CREDITS)
...

...
    local chameleonSubsts="
s&%CHAMELEONVERSION%&${CHAMELEON_VERSION%%-*}&g
s&%CHAMELEONREVISION%&${CHAMELEON_REVISION}&g
s&%CHAMELEONSTAGE%&${CHAMELEON_STAGE}&g
s&%DEVELOP%&${CHAMELEON_DEVELOP}&g
s&%CREDITS%&${CHAMELEON_CREDITS}&g
s&%PKGDEV%&${CHAMELEON_PKGDEV}&g
s&%CPRYEAR%&${CHAMELEON_CPRYEAR}&g
s&%WHOBUILD%&${CHAMELEON_WHOBUILD}&g
:t
....

...
# End

    md5=$( md5 "${distributionFilePath}" | awk {'print $4'} )
    echo "MD5 (${distributionFilePath}) = ${md5}" > "${distributionFilePath}.md5"
    echo ""

    echo -e $COL_GREEN" --------------------------"$COL_RESET
    echo -e $COL_GREEN" Building process complete!"$COL_RESET
    echo -e $COL_GREEN" --------------------------"$COL_RESET
    echo ""
    echo -e $COL_GREEN" Build info."
    echo -e $COL_GREEN" ==========="
    echo -e $COL_BLUE"  Package name: "$COL_RESET"${distributionFilename}"
    echo -e $COL_BLUE"  MD5:          "$COL_RESET"$md5"
    echo -e $COL_BLUE"  Version:      "$COL_RESET"$CHAMELEON_VERSION"
    echo -e $COL_BLUE"  Stage:        "$COL_RESET"$CHAMELEON_STAGE"
    echo -e $COL_BLUE"  Date/Time:    "$COL_RESET"$CHAMELEON_BUILDDATE"
    echo -e $COL_BLUE"  Builded by:   "$COL_RESET"$CHAMELEON_WHOBUILD"
    echo -e $COL_BLUE"  Copyright $CHAMELEON_CPRYEAR ""$COL_RESET"
    echo ""

}
...

EDIT:
also I think we need to update the description.html file with the new indroduced features like the cparm's patch for the OS X versions...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 22, 2012, 11:30:12 AM
Hi Fabio

Good thinking and how about going further and have the Conclusion and Welcome files as templates?. This way there could be a single master language file which contains all variants for the different Conclusion and Welcome files. The compilation process then transplants the correct text, similar to how the /package/Scripts.templates/* work.

Maybe this could be extended for one master text file for all variant text in /package/Resources/*. This would be a great benefit for everyone as making changes to /package/Resources/* can be a PITA  :P

Example - template for Welcome file could be something like:
Code: [Select]
Chameleon
v%CHAMELEONVERSION% r%CHAMELEONREVISION%

%wlc_installMessage%

Developers :
%DEVELOP%

Thanks to :
%CREDITS%

Package :
%PKGDEV%

%wlc_packageBuiltText%: %WHOBUILD%, %wlc_languageTranslatedText%
Copyright © %CPRYEAR%

Example - Conclusion file could be something like:
Code: [Select]

%cnc_message%

Chameleon v%CHAMELEONVERSION% r%CHAMELEONREVISION%

Copyright © %CPRYEAR%

Example master language file:
Code: [Select]
...
...
//-------------------------------------------------
language=en.lproj
wlc_installMessage=Do not install to an Apple Macintosh computer
wlc_packageBuiltText=Package built by
wlc_languageTranslatedText=language translated by: blackosx
cnc_message=The scripts have completed and a file
named @LOG_FILENAME@ has been
written to the root of your chosen partition.

Please read it to find out if the installation was
successful and keep it for a record of what was done."
//-------------------------------------------------
language=it.lproj
wlc_installMessage=Non installare su computer Apple Macintosh
wlc_packageBuiltText=Package built by
wlc_languageTranslatedText=language tradotto da: ErmaC e scrax
cnc_message="Le operazioni sono state completate ed un file
chiamato @LOG_FILENAME@ é stato
scritto nella root della partizione scelta.

Per favore leggilo per vedere se l'installazione é
avvenuta con successo e vedere le operazioni che sono state eseguite."
//-------------------------------------------------
...
...

Note: for this example I've removed the name of who built the package from the Conclusion file as do we really need it displayed twice?

also I think we need to update the description.html file with the new indroduced features like the cparm's patch for the OS X versions...
Yes, and also one the things I have on my TO DO list since some of JrCs' changes is to amend the localizable strings to better describe the revised process and even change some of the text written to the install log. But I have little time at the moment so I will make small changes as and when I can. I haven't even had time to look properly at all the wonderful changes JrCs has made - though it's great he found time to code the use of templates - brilliant.

I also want to look more in to the names in the credits file as extra names previously referenced can be seen here (http://chameleon.osx86.hu/articles/welcome-drink) and here (http://chameleon.osx86.hu/articles/chameleon-20-rc3-with-snow-leopard-and-large-disk-support#c001552).

Regards
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on January 22, 2012, 11:01:36 PM
Nice Idea Black!

So would be better a "complete" template????

also the "fileld" like Developer: Thanks to: an so on... are different for each language...
And yes the templates are the better and fast way for maintenance... is not the same edit and commit 1 or 2 files instead of "92"...
:P

Let me know if I can help.. me too I have little time at moment... but better than nothing ..
Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on January 23, 2012, 02:45:21 PM
So would be better a "complete" template????
I think so, yes.

also the "fileld" like Developer: Thanks to: an so on... are different for each language...
Good spot. They should be added too then.

And yes the templates are the better and fast way for maintenance... is not the same edit and commit 1 or 2 files instead of "92"...
:P
Exactly.

Let me know if I can help.. me too I have little time at moment... but better than nothing ..
Okay. I don't know when I'll even start at looking at this, but when I do, I'll let you know.

I'm going to start looking at the text written to the install log first to see if I can improve the feedback to the user since JrCs' changes. Thing is, JrCs is a clever chap and he enhanced/rewrote many parts including the perl and javascript code which I now have to try to understand  :P
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on February 17, 2012, 08:53:28 AM
Hi all,

i have little time too. But if you want some informations or want to discuss about the installer, don't hesitate  ;)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on February 28, 2012, 01:50:57 PM
Hi Fabio / JrCs

I've finally managed to put together an alternative method for managing the package installer resources. I've updated my branch to work this new way and although it's still a work in progress and not thoroughly tested I would like to communicate what I am trying to do.

The idea is this:
1) Have a single common document which contains all the text for all the files. This file is a Google doc spreadsheet and it's a published file so the data can be downloaded.
2) The chameleon svn will no longer host the individual resources folders and files, instead will host only templates for these files - same as JrCs did for the scripts.
3) The buildpkg.sh script calls a perl script 'ConvertResourcesTextFile.pl' which downloads the data from the Google spreadsheet and then processes it in to a script friendly list format (sort of YAML).
4) The buildpkg.sh script then continues by reading the new list file and populates the templates - building the Resources folder to the correct location for the final package.

You can view a readonly version of the Google doc spreadsheet here:
https://docs.google.com/spreadsheet/ccc?key=0Aj0jJ2rdmK_sdFdNbm45NlpNYU1PcjRmOHVXX0FNa3c

I'm still updating the spreadsheet at the moment so you'll notice it's not yet complete. I've still got to add the LocalizationStrings for the Italian language and onwards. Plus make all the recent changes, additions that you Fabio did yesterday.. Lol.   
@Fabio - If you would like to help me complete/update the spreadsheet then I could give you write access?

Which brings me on to the question of how to manage the spreadsheet - I don't know if I should make it a public doc so anybody can update it? or only let registered users update it? The plus side of opening it up to everyone would mean it would be up to date quicker and kept accurate, but doing that would mean we also have to trust that nobody messed with it.

This idea is not perfect and I've discovered that the textutil command used in the buildpkg.sh script for converting the unicode markup gives different results in Snow Leopard to what it does in Lion. I need to find out why, but what that means is for now, building the package in Snow Leopard gives the wrong text conversion results.

So for now, that's what I'm working on. Is this a good direction to go in? Have you any suggestions of how this could be improved or changed?

Regards
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on February 28, 2012, 02:34:19 PM
Amazing!

I will happy to help you.

Q. (From a very quick tour on google) Can this "database" live exclusively on google?
Or they can be accommodated in our SVN (or Chameleon Application svn)?

Other idea... can this "database" merge into a large .plist document? (it support UTF-16 encoding...)

However, tonight I read deeper into your post to understand better the process of resources creation...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on February 28, 2012, 05:40:08 PM
Thanks for the feedback Fabio.

The advantage to using a Google doc is that it's instantly available to anyone (providing they have a Google account) and a script can pull the data from it which makes it ideal for this purpose.  However, as you've pointed out it means we will rely on Google hosting the master file.

I don't know if the file can be hosted on a non-Google server. We could maybe use an openoffice or MS excel spreadsheet instead and host that at the svn, then save/export a tabbed delimited text file for the scripts to read but it's more cumbersome.

The main resource file could be in a .plist format. I thought of that originally, along with an xml file but wanted a simpler file for reading and editing, that's why I chose to use a spreadsheet. The structured list file that the perl script generates goes someway to answer this and keeps the format in a simple manner like a YAML file. And from my reading, UTF-8 supports everything we need for this.

You can look at the list file the perl script generates by doing the following:
cd to branch /package/Resources.source
./ConvertResourcesTextFile.pl path filename of where you want to save the file to.

So for example:
Code: [Select]
./ConvertResourcesTextFile.pl ~/Desktop ResourcesSourceFile.txt

Feel free to throw ideas around here so this can hopefully progress to some useful completion.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on February 29, 2012, 04:43:43 AM
OK!

I help you to complete the "master" Resource Database.
(PM's me how).

Can you point me about how "mod" the .pl script for try in "local" mode the ResourcesSourceFile.txt instead of online google version? Because in the future this is how the scripts will work.

Also I will do a little change for the Welcome Template:
@W_Cp@ instead of Copyright this word also have a translation.

and %CPRYEAR% instead of the static 2009-2012 for the sostitution tacked from CREDITS file.

I think I will take the missed/new data from my modules sub-branch. The Localizable.strings files are more complete.

Anyway very good job Blackosx
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on February 29, 2012, 10:00:07 AM
Hi all,

i look for the big work you made blackosx. This is what i'm thinking about. It's only my hymble opinion:
* I think that downloading file from the internet is not a really good solution: we need to have access to internet to work, and the file is never versioned, so we can properly follow it's history.
* I think your file is too complex, we juste need an id and a translation for each language.
* I think you are trying to reinvent the .pot/.po files that are used in any linux to make translation of programs (http://en.wikipedia.org/wiki/Gettext)

There are programs to manage pot file on OSX like http://www.macupdate.com/app/mac/22905/poedit

Look at this url: http://translate.org.za/blogs/dwayne/en/content/localizing-mac-os-x-strings-files-using-open-source-po-editors , it's a program to convert strings to pot file and then convert back to strings. So we only have to create a pot file from the english strings file (with the prop2po program), let the translator add their translations (they don't have to translate all strings) and then convert back each translate pot file to a localized string file (with po2prop program).

As i have said before it's my humble opinion.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on February 29, 2012, 10:45:01 AM
Hi JrCs

Thanks for the feedback and the pointer to a different way of looking at this. Your opinion is valid and that's why I asked for it.

I agree the solution I have been working on has become quite complex but that's how I saw the solution at that time. Now, though I am happy to look further in to .pot/.po and the links you supplied to see if a simpler solution can be applied. Simple is always best.

I help you to complete the "master" Resource Database.
Thanks for taking a look at this Fabio and your offer to help. However, going by JrCs suggestions I think it's wise to stop for now and look at a different method. But yes, we can include 'Copyright' and the date in the future solution.

I'm happy to continue discussions. But for now.. it's finding time for more research.

 ;D
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on February 29, 2012, 10:46:34 AM
Hi all i test the conversion of the strings -> po -> strings and it work very well.
In attachment the files that have used and created.

I convert the english localization file from en.lproj to en.pot file with the command:
Code: [Select]
prop2po --encoding=UTF-16LE -P Localizable.strings en.potthen  i copy the en.pot file to fr.po
Code: [Select]
cp en.pot fr.pothen i open the fr.po with an editor and i've translated in french the first 4 messages.
To finish i convert the fr.po file to a  Localizable.fr.strings that can be used in the fr.lproj with the command:
Code: [Select]
po2prop -t Localizable.strings fr.po Localizable.fr.strings
Everything can be automated with a script. The translators are only to edit the lang.po files.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on February 29, 2012, 10:50:36 AM
It's me again. We can use Pottle: http://translate.sourceforge.net/wiki/pootle/index to do web translation directly. So anyone can make the translation of the project without retreiving the svn project.

Example of the pootle project: http://pootle.locamotion.org/

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on February 29, 2012, 10:51:35 AM
Brilliant.. Thanks for the trials JrCs. - So easy when you know how  :lol:
I'm at work right now so I'll have a look at this tonight. Thanks
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on February 29, 2012, 12:01:09 PM
The only problem is that we need the translate-toolkit on OSX. Actually i do the conversion from a linux.
As the toolkit is wrote in python i think it will be easy to port on OSX.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on February 29, 2012, 12:47:02 PM
The only problem is that we need the translate-toolkit on OSX. Actually i do the conversion from a linux.
As the toolkit is wrote in python i think it will be easy to port on OSX.

JrCs
It's easy has download the package, extract it and installing it
Code: [Select]
cd /tmp
wget "http://sourceforge.net/projects/translate/files/Translate%20Toolkit/1.9.0/translate-toolkit-1.9.0.tar.bz2/download" -O translate-toolkit-1.9.0.tar.bz2
tar xvjf translate-toolkit-1.9.0.tar.bz2
cd translate-toolkit-1.9.0
sudo ./setup.py install --prefix=/opt/local

I'm using the --prefix=/opt/local option because i have macports installed on my hack.

After that you can download poedit for OSX: http://prdownloads.sourceforge.net/poedit/poedit-1.4.6.2.dmg
and start to translate the files  ;)

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on February 29, 2012, 01:37:28 PM
Thx JrCs!

follow your steps...



Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on February 29, 2012, 03:01:53 PM
Thanks for the continued investigation JrCs.

I've had a quick test using prop2po and it works as you've said, and running Poedit here shows it's a useful app and will help to populate the other languages. :)

This is great for plain text files, but what shall we do for the RTF files? as prop2po doesn't like those:

Code: [Select]
prop2po --encoding=UTF-16LE -P License.rtf l_en.pot
prop2po: warning: Couldn't handle input file License.rtf: don't know what to do with input format .rtf, no template file

I'll do some reading later as maybe there's more to it...

Thx JrCs!

follow your steps...
This is looking a better approach Fabio :)
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 01, 2012, 10:06:56 AM
Hi all,

what i'm thinking is put all the xxx.lproj in a template directory. For each rtf files replace the strings with an id like: @@WELCOME_MESSAGE@@. After that put the english string in en.pot file:

Code: [Select]
#. // ============================================================================
#. // Strings for RTF Files
#. // ----------------------------------------------------------------------------
#: @@WELCOME_MESSAGE@@
msgid "Hello user of Chameleon."
msgstr ""

Open poedit, load the already translated file ie: fr.po. Use the option in the menu Catalog->Update from POT file and load the en.pot file. Poedit will add the strings that is in en.pot file and not in fr.po (so it will add the @@WELCOME_MESSAGE@@ string). Now translate the string and save the file.
Now you will have a fr.po containing something like:
Code: [Select]
#. // ============================================================================
#. // Strings for RTF Files
#. // ----------------------------------------------------------------------------
#: @@WELCOME_MESSAGE@@
msgid "Hello user of Chameleon."
msgstr "Bonjour utilisateur de Chameleon."

So it's the solution to translate all the strings (in RTF or in strings files).

We now have to write a little script that replace all the @@xxxxxxx@@ strings in the RTF templates files to the right translation and put the file in the package. If you want i can try to write this script.

What do you think about this ?

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 01, 2012, 12:04:17 PM
Re all,

perhaps i found the ultimate solution  ;D

With this solution we don't have to create id and write directly the master template in english.
First the problem with the solution i send just before is that we need to work with RTF which is in a binary format.
With this solution we can have only ONE master text file in english and convert it to localized RTF files.

Here the solution:
Convert the english RTF file to a markdown text file (http://en.wikipedia.org/wiki/Markdown)

So a Welcome.rtf file will be convert to Welcome.mmd:
Quote
#->Chameleon<-#
->v%CHAMELEONVERSION% r%CHAMELEONREVISION%<-

->Do not install to an Apple Macintosh computer<-


->**Developpers :**<-
->%DEVELOP%<-

->**Thanks to :**<-
->%CREDITS%<-

->**Package :**<-
->%PKGDEV%<-

->Package built by: %WHOBUILD%, language translated by: blackosx<-
Copyright © %CPRYEA%

After that we can extract all strings to an en.pot file with po4a (http://po4a.alioth.debian.org/man/man7/po4a.7.php.en)
Code: [Select]
po4a-gettextize -f text -m Welcome.mmd -M UTF-8 -p en.potwhich create a pot file like this:
Quote
# SOME DESCRIPTIVE TITLE
# Copyright (C) YEAR Free Software Foundation, Inc.
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2012-03-01 11:23+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. type: Plain text
#: Welcome.mmd:3
msgid "#->Chameleon<-# ->v%CHAMELEONVERSION% r%CHAMELEONREVISION%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:5
msgid "->Do not install to an Apple Macintosh computer<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:9
msgid "->**Developpers :**<- ->%DEVELOP%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:12
msgid "->**Thanks to :**<- ->%CREDITS%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:15
msgid "->**Package :**<- ->%PKGDEV%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:17
msgid ""
"->Package built by: %WHOBUILD%, language translated by: blackosx<- Copyright "
"© %CPRYEA%"
msgstr ""

Now copy en.pot to fr.po for the traduction and open the fr.po in poedit. Translate the file and we have now a fr.po file:
Quote
# SOME DESCRIPTIVE TITLE
# Copyright (C) YEAR Free Software Foundation, Inc.
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: TEST 1.0\n"
"POT-Creation-Date: 2012-03-01 11:23+0100\n"
"PO-Revision-Date: 2012-03-01 11:28+0100\n"
"Last-Translator: Yves Blusseau <xxxxx@gmail.com>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. type: Plain text
#: Welcome.mmd:3
msgid "#->Chameleon<-# ->v%CHAMELEONVERSION% r%CHAMELEONREVISION%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:5
msgid "->Do not install to an Apple Macintosh computer<-"
msgstr "->Ne pas installer sur un ordinateur Apple Macintosh<-"

#. type: Plain text
#: Welcome.mmd:9
msgid "->**Developpers :**<- ->%DEVELOP%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:12
msgid "->**Thanks to :**<- ->%CREDITS%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:15
msgid "->**Package :**<- ->%PKGDEV%<-"
msgstr ""

#. type: Plain text
#: Welcome.mmd:17
msgid "->Package built by: %WHOBUILD%, language translated by: blackosx<- Copyright © %CPRYEA%"
msgstr ""

Now translate the original document (Welcome.mmd) to a localized one (Welcome.fr.mmd):

Code: [Select]
po4a-translate -f text -m Welcome.mmd -M utf-8 -p fr.po -k 10 -l Welcome.fr.mmd
The new generated file (Welcome.fr.mmd):
Quote
#->Chameleon<-#
->v%CHAMELEONVERSION% r%CHAMELEONREVISION%<-

->Ne pas installer sur un ordinateur Apple Macintosh<-


->**Developpers :**<-
->%DEVELOP%<-

->**Thanks to :**<-
->%CREDITS%<-

->**Package :**<-
->%PKGDEV%<-

->Package built by: %WHOBUILD%, language translated by: blackosx<-
Copyright © %CPRYEA%

The last phase is to convert all the localized markdown file (.mmd) to RTF file.
For that we can use MultiMarkdown which is avaible for OSX.

If we change the master file Welcome.mmd we only have to update the xx.po file with:
Code: [Select]
po4a-updatepo -f text -m Welcome.mmd -M utf-8 -p fr.pothen fix translation with poedit

What is really good with this solution:
* Work only with standardize text files
* Replacing our own strings (like %CREDITS%) is easy with text files.
* We can merge all the translation to one file for one language.

If the markdown language is not enough for us we can use other format because po4a knows a lot of other format:
Quote
  - dia: uncompressed Dia diagrams.
  - docbook: DocBook XML.
  - guide: Gentoo Linux's XML documentation format.
  - ini: INI format.
  - kernelhelp: Help messages of each kernel compilation option.
  - latex: LaTeX format.
  - man: Good old manual page format.
  - pod: Perl Online Documentation format.
  - sgml: either DebianDoc or DocBook DTD.
  - texinfo: The info page format.
  - tex: generic TeX documents (see also latex).
  - text: simple text document.
  - wml: WML documents.
  - xhtml: XHTML documents.
  - xml: generic XML documents (see also docbook).

Tell me what do you think about that.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 01, 2012, 12:11:24 PM
Hi JrCs

I've just followed your steps above for adding extra strings to the en.pot file, then using Catalog->Update for the fr.po file. This works as you've described.

So is the plan to still use a template for each: Conclusion.rtfd, Description.html, Localizable.strings, Welcome.rtfd.
Then to have a .po file for each language: ar.po, bg.po, bs.po, de.po, el.po, en.po  etc.

We now have to write a little script that replace all the @@xxxxxxx@@ strings in the RTF templates files to the right translation and put the file in the package. If you want i can try to write this script.

What do you think about this ?
Great. And yes please, if you have the time of course.

EDIT:.. Okay, this was a reply to your previous post (http://forum.voodooprojects.org/index.php/topic,1521.msg11650.html#msg11650)..
Let me look at this markdown discovery you've made... :)

Wow.. At first glance this looks fantastic  ;D
I would like to recreate the steps here to understand it better but from what you have posted - it looks the ideal solution.
I'll try to find some time soon, but in the mean time feel free to continue this development :)

Good research JrCs.
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 01, 2012, 04:07:13 PM
Re,

i've made some tests, and i think markdown is not our best solution for the master template. The best is to use an HTML file and use po4a to extract/reinsert strings to po files.

Use a command like this to convert english html master file to localized french html:
Code: [Select]
po4a-translate -f xml -m Welcome.html -M utf-8 -p fr.po -k 0 -l Welcome.fr.html
After that convert the localized file to an rtfd bundle:
Code: [Select]
textutil -convert rtfd Welcome.fr.html
I will try to made a skeleton for chameleon.
 
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 01, 2012, 05:10:24 PM
i've made some tests, and i think markdown is not our best solution for the master template. The best is to use an HTML file and use po4a to extract/reinsert strings to po files.
....with so many tools to choose from it's hard to decide which best suits the task in hand. Lol  :P
But it looks like you've identified a good procedure to follow now.

Code: [Select]
po4a-translate -f xml -m Welcome.html -M utf-8 -p fr.po -k 0 -l Welcome.fr.html
So where did po4a-translate come from? I don't see that tool in /usr/local/bin after installing the translate toolkit the other day.

Code: [Select]
textutil -convert rtfd Welcome.fr.html
I had a read about textutil the other week and found it amazing at what it could do.

I will try to made a skeleton for chameleon.
Brilliant. If you need any help (or testing etc.) from me then just ask.
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 01, 2012, 06:54:01 PM

Code: [Select]
po4a-translate -f xml -m Welcome.html -M utf-8 -p fr.po -k 0 -l Welcome.fr.html
So where did po4a-translate come from? I don't see that tool in /usr/local/bin after installing the translate toolkit the other day.

You need to install it manually as it is not packaged. It's very easy (it's only perl packages):
Code: [Select]
cd /tmp
svn checkout svn://anonscm.debian.org/po4a/trunk po4a
cd po4a
perl ./Build.PL --prefix=/opt/local
sudo ./Build install

I use --prefix=/opt/local because i have macports installed

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 02, 2012, 02:02:35 AM
Just one info.
The license.rtf file (the content into it) is exactly the same present in the root of chameleon project APPLE_LICENSE

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 02, 2012, 08:29:30 AM
Thanks Fabio for the info.

I have try yesterday to translate HTML file with po4a: it's so easy. Just one command and it will translate one master file to as many language you want.

Do you know if OSX package can use HTML file (like Description.html) instead of RTF files (like Welcome.rtfd and Conclusion.rtfd) ? If yes it will be too easy to translate chameleon package.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 02, 2012, 12:41:06 PM
Do you know if OSX package can use HTML file (like Description.html) instead of RTF files (like Welcome.rtfd and Conclusion.rtfd) ? If yes it will be too easy to translate chameleon package.

Yep
.html, .rtf, .txt
for welcone.xx , description.xx , license.xx , conclusion.xx
edit ino the description file (about the extension used) are needed.

localizable.strings ... no idea... tecnically is a txt file with different extensions?

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 04, 2012, 09:43:00 AM
JrCs, I see you've already got some way in to building a working model in your branch using pot/po files. Well done :)

However, would it be too late to clean the original English source .pot file? It was something I had done when I was working on the translations previously as the english localizable.string file contained some references to items that were either no longer in use or not supported by the current package installer. The items I would remove are:

Code: [Select]
#. type: "InstallType_title"
#. type: "InstallType_description"
#. type: "New_title"
#. type: "New_description"
#. type: "Upgrade_title"
#. type: "Upgrade_description"
#. type: "EFI_title"
#. type: "EFI_description"
#. type: "Keylayout_title"
#. type: "Keylayout_description"
#. type: "Utility_title"
#. type: "Utility_description"
#. type: "PrefPanel_title"
#. type: "PrefPanel_description"
#. type: "SMBIOS_title"
#. type: "SMBIOS_description"
#. type: "Documentation_title"
#. type: "Documentation_description"
#. type: "mac-pt_title"
#. type: "mac-pt_description"
#. type: "pc-de_title"
#. type: "pc-de_description"
#. type: "pc-es_title"
#. type: "pc-es_description"
#. type: "pc-it_title"
#. type: "pc-it_description"
#. type: "pc-se_title"
#. type: "pc-se_description"
#. type: "pc-pt_title"
#. type: "pc-pt_description"

Hope it's not too much of an issue?

Regards
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 04, 2012, 11:00:54 AM
Hi BlackOSX.

All done. It's so easy with po files. Strings removed but keep in case we need it later (managed automaticaly by po4a).

About what have done: I have wrote a perl plugin for po4a to handle Localized.strings files. So now we can translate any html or strings files. Also i update a lot the process to made the transalations. We don't need any external program like translate-toolkit or other things. Just do a
Code: [Select]
make pkg  ;D

We can change the resources template files (in package/Resources/templates) and po4a will add/remove the strings automaticaly in the po files. All the translations are in po directory (package/po) and can be edit with poedit for example. Update resources template or po files and po4a will do the job to translate all the resources files (Welcome.html, Description.html, Conclusion.html, Localized.strings) in all languages that are defined in the po directory.

We can checkout my branch (JrCs) if you want to test. I will commit to trunk very soon.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 04, 2012, 01:28:39 PM
Fantastic..
Okay testing...

Just checked out your branch and make pkg.
One issue:
Code: [Select]
========= Translating Resources ========
Error: failed to execute 'msgmerge -U po/ar.po po/chameleon.pot --lang=ar --previous --backup=none': No such file or directory.
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/text-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/text-base/License.rtf.svn-base: Permission denied
Leaves me with only /sym/package/Chameleon/Resources/en.lproj/License.rtf

I'm looking forward to seeing it all working :)

-----------------
...I will commit to trunk very soon.
On another note, when you update the trunk can you also have a look at the cpio issue when building under Snow Leopard?
buildpkg, line 865 - Change 0:0 to root:wheel
buildpkg, line 873 - Change 0:0 to root:wheel

and finally, this line in function make distribution() in buildpkg ?
Code: [Select]
find "${PKG_BUILD_DIR}/${packagename}" \( -type d -name '.svn' \) -o -name '.DS_Store' -exec rm -rf {} \;We've discussed this previously and it should work but it doesn't here and spits errors.
I'd changed it to the following code in my branch , which we know does exactly the same thing as the above code but just doesn't spit errors:
Code: [Select]
find "${PKG_BUILD_DIR}/${packagename}/Resources" -name ".svn" -type d -o -name ".DS_Store" -type f | while read component
    do
rm -rf "${component}"
    done

Thanks
blackosx
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 04, 2012, 02:08:09 PM
cked out your branch and make pkg.
One issue:
Code: [Select]
========= Translating Resources ========
Error: failed to execute 'msgmerge -U po/ar.po po/chameleon.pot --lang=ar --previous --backup=none': No such file or directory.
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/text-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/text-base/License.rtf.svn-base: Permission denied
Leaves me with only /sym/package/Chameleon/Resources/en.lproj/License.rtf

I'm looking forward to seeing it all working :)

You need the gettext utilities. If you have MacPorts you can installed it with
Code: [Select]
sudo port -cu install gettextIf you don't want to install MacPorts the utilities can be found in Poedit.app in /Applications/Poedit.app/Contents/MacOS/ directory.

...I will commit to trunk very soon.
On another note, when you update the trunk can you also have a look at the cpio issue when building under Snow Leopard?
buildpkg, line 865 - Change 0:0 to root:wheel
buildpkg, line 873 - Change 0:0 to root:wheel

Done in trunk :)

and finally, this line in function make distribution() in buildpkg ?
Code: [Select]
find "${PKG_BUILD_DIR}/${packagename}" \( -type d -name '.svn' \) -o -name '.DS_Store' -exec rm -rf {} \;We've discussed this previously and it should work but it doesn't here and spits errors.
I'd changed it to the following code in my branch , which we know does exactly the same thing as the above code but just doesn't spit errors:
Code: [Select]
find "${PKG_BUILD_DIR}/${packagename}/Resources" -name ".svn" -type d -o -name ".DS_Store" -type f | while read component
    do
rm -rf "${component}"
    done

Thanks
blackosx

Done in trunk :)
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 04, 2012, 04:08:09 PM
You need the gettext utilities. If you have MacPorts you can installed it with
Code: [Select]
sudo port -cu install gettextIf you don't want to install MacPorts the utilities can be found in Poedit.app in /Applications/Poedit.app/Contents/MacOS/ directory.
Thanks for the tip but I'm going to need your help as this is new to me  :-[
I've tried this....
Code: [Select]
sudo cp /Applications/Poedit.app/Contents/MacOS/msgmerge /usr/local/bin
export PATH="/Volumes/MainSystem/usr/local/bin/: $PATH"

and this is what I see....

Code: [Select]
========= Translating Resources ========
Error: 'msgmerge -U po/ar.po po/chameleon.pot --lang=ar --previous --backup=none' died with signal 5, without coredump.
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/prop-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/text-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/text-base/License.rtf.svn-base: Permission denied
Can you please help me?

Done in trunk :)
Thanks for both.
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 04, 2012, 04:54:33 PM
You need the gettext utilities. If you have MacPorts you can installed it with
Code: [Select]
sudo port -cu install gettextIf you don't want to install MacPorts the utilities can be found in Poedit.app in /Applications/Poedit.app/Contents/MacOS/ directory.
Thanks for the tip but I'm going to need your help as this is new to me  :-[
I've tried this....
Code: [Select]
sudo cp /Applications/Poedit.app/Contents/MacOS/msgmerge /usr/local/bin
export PATH="/Volumes/MainSystem/usr/local/bin/: $PATH"

and this is what I see....

Code: [Select]
========= Translating Resources ========
Error: 'msgmerge -U po/ar.po po/chameleon.pot --lang=ar --previous --backup=none' died with signal 5, without coredump.
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/prop-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/.svn/text-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Branch_JrCs/JrCs/sym/package/Chameleon/Resources/en.lproj/.svn/text-base/License.rtf.svn-base: Permission denied
Can you please help me?

It's normal you only get the msgmerge utility. You need all the msgxxxx utils and libraries also: libxxxx. I don't think you need to change your path as /usr/local/bin must be already in your path.
But the best solution is to use MacPorts and you will get the lastest version of the software. I you don't want to install MacPorts i have created the package for you: http://dl.dropbox.com/u/112112/Chameleon.Dev/gettext-0.18.1.1.dmg (http://dl.dropbox.com/u/112112/Chameleon.Dev/gettext-0.18.1.1.dmg).

Add that to your ~/.bash_profile or .bashrc to add the path:
Code: [Select]
# MacPorts Installer: adding an appropriate PATH variable for use with MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.

# MacPorts Installer: adding an appropriate MANPATH variable for use with MacPorts.
export MANPATH=/opt/local/share/man:$MANPATH
# Finished adapting your MANPATH environment variable for use with MacPorts.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 04, 2012, 06:05:45 PM
@ JrCs...

I try to follow the changes...
You commit very fast :P...

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 04, 2012, 06:07:44 PM
Update commit to trunk.

I have add a little README.translators file. Feel free to change it.

English, and french are 100% translated. Now the big work  :P will be to translate strings in HTML files (Welcome.html, Description.html and Conclusion.html) and translate them in the PO files. The old resources (Localized.strings, Welcome.rtfd, Description.html and Conclusion.rtfd) are in package/Resources.old. So we need to copy and paste from rtf files to PO file.

Regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 04, 2012, 06:11:16 PM
@ JrCs...

I try to follow the changes...
You commit very fast :P...

Fabio
This is because i don't use svn (i dislike subversion). I'm using git, so when i commit it will commit all the change at the same moment.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 04, 2012, 06:27:09 PM
Just a note... (but I think it is normal)

Now The License are the same for all language (English)...

Isn't so easy to see how many language are included into the final package...
Before:
When you arrive into the "license" panel and click into the language the menu show how many language are included into the pkg.
Now:
I see only the English language (but with pacifist I open the pkg and see en, fr and ko).

Ps: I download the pkg from BuildBot

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 04, 2012, 06:38:44 PM
Just a note... (but I think it is normal)

Now The License are the same for all language (English)...

Yes because we have only one License in .... English  ;)

When compiling you can see all language in the sym/package/Chameleon/Resources directory.

Regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 04, 2012, 07:24:11 PM
You need the gettext utilities. If you have MacPorts you can installed it with
Code: [Select]
sudo port -cu install gettext
Thanks for putting a package together for me. However, I got an error with it so in the end I installed MacPorts and now I can build the Chameleon package. :)

I do see this now though...
Code: [Select]
========= Translating Resources ========
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ar.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ar.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ar.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ar.lproj/Localizable.strings (13 of 147 strings; only 8.84% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bg.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bg.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bg.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bg.lproj/Localizable.strings (28 of 147 strings; only 19.04% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bs.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bs.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bs.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/bs.lproj/Localizable.strings (78 of 147 strings; only 53.06% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ca.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ca.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ca.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ca.lproj/Localizable.strings (82 of 147 strings; only 55.78% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/de.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/de.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/de.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/de.lproj/Localizable.strings (108 of 147 strings; only 73.46% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/el.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/el.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/el.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/el.lproj/Localizable.strings (15 of 147 strings; only 10.2% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/es.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/es.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/es.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/es.lproj/Localizable.strings (95 of 147 strings; only 64.62% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/he.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/he.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/he.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/he.lproj/Localizable.strings (22 of 147 strings; only 14.96% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/hr.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/hr.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/hr.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/hr.lproj/Localizable.strings (76 of 147 strings; only 51.7% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/id.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/id.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/id.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/id.lproj/Localizable.strings (90 of 147 strings; only 61.22% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/it.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/it.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/it.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/it.lproj/Localizable.strings (98 of 147 strings; only 66.66% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ko.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ko.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ko.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/mk.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/mk.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/mk.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/mk.lproj/Localizable.strings (93 of 147 strings; only 63.26% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/nl.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/nl.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/nl.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/nl.lproj/Localizable.strings (99 of 147 strings; only 67.34% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pl.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pl.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pl.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pl.lproj/Localizable.strings (82 of 147 strings; only 55.78% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-BR.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-BR.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-BR.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-BR.lproj/Localizable.strings (92 of 147 strings; only 62.58% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-PT.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-PT.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-PT.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/pt-PT.lproj/Localizable.strings (92 of 147 strings; only 62.58% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ro.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ro.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ro.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ro.lproj/Localizable.strings (88 of 147 strings; only 59.86% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ru.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ru.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ru.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/ru.lproj/Localizable.strings (6 of 147 strings; only 4.08% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/sr.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/sr.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/sr.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/sr.lproj/Localizable.strings (76 of 147 strings; only 51.7% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_CN.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_CN.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_CN.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_CN.lproj/Localizable.strings (99 of 147 strings; only 67.34% translated; need 75%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_TW.lproj/Welcome.html (0 of 11 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_TW.lproj/Description.html (0 of 18 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_TW.lproj/Conclusion.html (0 of 9 strings; only 0% translated; need 80%).
Discard /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/zh_TW.lproj/Localizable.strings (99 of 147 strings; only 67.34% translated; need 75%).
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/.svn/prop-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/.svn/text-base/background.tiff.svn-base: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/en.lproj/.svn/all-wcprops: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/en.lproj/.svn/entries: Permission denied
/Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/package/buildpkg.sh: line 164: /Volumes/Store/Computing/Hackintosh/SOURCE_GIT_SVN/Chameleon/Chameleon_Trunk/trunk/sym/package/Chameleon/Resources/en.lproj/.svn/text-base/License.rtf.svn-base: Permission denied

I guess the Discard ones are because of incomplete languages?
But the permission errors for the .svn files I've had all along. What's the best way to stop those?
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 05, 2012, 12:20:27 AM
Discard is because the files are not enough translated. I settled to 80% for the HTML and 75% for the Localized strings.

For the permissions errors try to reimport the project with svn checkout.
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 05, 2012, 01:19:00 AM
Hi all,

create your account on http://pootle.zetam.org:8080/pootle/ (http://pootle.zetam.org:8080/pootle/) so you'll be translate the files directly from the web with the help of Pootle.

I'll give you the rights to allow commiting on the trunk.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 05, 2012, 03:44:42 AM
Hi all,

I traslate italian on pootle's chameleon project.

I need to know ho add field:

Example I make in my local repository some changes to chameleon into .../package/OptionalSettings/Resolution.txt
I add : Text@1600x1200x32:Graphics Mode=1600x1200x32
so a new "field" is needed, in the old stile...
en
Code: [Select]
"1600x1200x32_title" = "1600x1200x32";
"1600x1200x32_description" = "Set Graphics Mode to 1600x1200x32";
it
Code: [Select]
"1600x1200x32_title" = "1600x1200x32";
"1600x1200x32_description" = "Setta il Graphics Mode a 1600x1200x32";

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 05, 2012, 09:39:53 AM
Hi Fabio,

you only have to change the english resource file package/Resources/templates/Localizable.strings
After that do a make pkg and all the po files will be update with the new strings waiting for translation :)
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 05, 2012, 05:50:40 PM
ErmaC and BlackOSX you have now the right to commit directly to the trunk from Pootle.

Try to remove all the alerts that are in the review tab. If it's a false positive like unchanged (for example for the string npci=0x2000 -> npci=0x2000), click on the red cross to remove this false positive only for the current translation.

Regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 05, 2012, 10:28:46 PM
Thanks JrCs.
I'll take a look when I can :)
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 06, 2012, 10:28:16 AM
Hi ErmaC and Blackosx,

do you know where the code of languages came from ? For example in chameleon, i don't know what is the ca language. If it's the country code .ca is for canadian. Same thing for ar, wikipedia said that .ar is for argentina, but it's seems in chameleon is for arabic language.

So if you know where we can have the information about language ....


I found the informations: https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/LanguageDesignations.html

Regards,
JrCs
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 06, 2012, 12:53:43 PM
Thanks for the link as I was asking myself the same question. Lol.  ;D
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 06, 2012, 07:26:59 PM
Hi all.

I have a little bit of time now...
So..
ar is for arabic
ca is for catalan
i take the info from this link and it work for the language created manually until now.
1) http://msdn.microsoft.com/en-us/library/ms533052(v=vs.85).aspx
2) http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.client.doc%2Ft_inst_mac.html

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 08, 2012, 09:51:22 AM
Thanks ErmaC.

Also ErmaC don't forget to commit to VCS when you have correct some translations, because if we update the databases FROM VCS all modifications you have made will become suggestions.
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 09, 2012, 01:36:56 PM
ErmaC you can commit to svn directly from pootle if you want.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 09, 2012, 02:27:11 PM
Thx JrCs.

I'm busy now...
Monday I will commit more language on pootle...

Can you breafing me how commit from pootle? Also you say update languace from VCS...
What I do is compile the chameleon pkg in my local Hack, then "target" one language and update it with poedit, after that I rebuild the pkg to see if there is error, and then I commit it.

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: Blackosx on March 09, 2012, 09:48:43 PM
Sorry I haven't been contributing much to the pootle project guys.
I'm going away tomorrow for a week so I'll look more in to it when I return.

But keep up the good work you've been doing :P
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 12, 2012, 12:29:26 PM
Thx JrCs.

I'm busy now...
Monday I will commit more language on pootle...

Can you breafing me how commit from pootle? Also you say update languace from VCS...
What I do is compile the chameleon pkg in my local Hack, then "target" one language and update it with poedit, after that I rebuild the pkg to see if there is error, and then I commit it.

Fabio

VCS = Version Control System, it's like svn, cvs, git, etc....

It's better not to use POEdit directly. The best is to use Pootle for all the translation because POEdit change the format of the po file. But if you want to use POEdit, the best is download the po file from Pootle, edit it with POEdit then upload back to Pootle. After that click on the Review/Commit to VCS to commit the po file to chameleon trunk.

JrCs
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 16, 2012, 12:32:34 PM
Hi JrCs.

We need a correction...
Estonian el.po is not correct
el is for Greek

Also...
how create Chinese (traditional and simplified) zh_CN and zh_TW ? I copy & paste the field from my old translation but it need tiny revision from translator author.
Same for Portuguese pt-PT and pt_BR (Portugal and Brazil)

Fabio
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 16, 2012, 03:18:01 PM
Hi JrCs.

We need a correction...
Estonian el.po is not correct
el is for Greek

Also...
how create Chinese (traditional and simplified) zh_CN and zh_TW ? I copy & paste the field from my old translation but it need tiny revision from translator author.
Same for Portuguese pt-PT and pt_BR (Portugal and Brazil)

Fabio

Thanks Fabio, all corrected
Title: Re: Revisit Chameleon's package builder
Post by: JrCs on March 26, 2012, 09:25:55 AM
To ErmaC: hi fabio, when you create a new po file (for a new language) don't take en.po as the source.
ALWAYS use the chameleon.pot file. I have change and commit the cs.po file.
Title: Re: Revisit Chameleon's package builder
Post by: ErmaC on March 26, 2012, 02:00:42 PM
To ErmaC: hi fabio, when you create a new po file (for a new language) don't take en.po as the source.
ALWAYS use the chameleon.pot file. I have change and commit the cs.po file.

OK!  :P

Other things relate to the package...
Can be add the option to select specific Pre-Made SMBioses?
(Courtesy of crazybirdy) I have 54 premade SMBios
Code: [Select]
iMac4.2.plist
iMac5.1.plist
iMac6.1.plist
iMac7.1.plist
iMac8.1.plist
iMac9.1.plist
iMac10.1.plist
iMac11.1.plist
iMac11.2.plist
iMac11.3.plist
iMac12.1.plist
iMac12.2.plist
MacBook2.1.plist
MacBook3.1.plist
MacBook4.1.plist
MacBook5.1.plist
MacBook5.2.plist
MacBook6.1.plist
MacBook7.1.plist
MacBookAir1.1.plist
MacBookAir2.1.plist
MacBookAir3.1.plist
MacBookAir3.2.plist
MacBookAir4.1.plist
MacBookAir4.2.plist
MacBookPro2.1.plist
MacBookPro2.2.plist
MacBookPro3.1.plist
MacBookPro4.1.plist
MacBookPro5.1.plist
MacBookPro5.2.plist
MacBookPro5.3.plist
MacBookPro5.4.plist
MacBookPro5.5.plist
MacBookPro6.1.plist
MacBookPro6.2.plist
MacBookPro7.1.plist
MacBookPro8.1.plist
MacBookPro8.2.plist
MacBookPro8.3.plist
MacMini2.1.plist
MacMini3.1.plist
MacMini4.1.plist
MacMini5.1.plist
MacMini5.2.plist
MacMini5.3.plist
MacPro1.1.plist
MacPro2.1.plist
MacPro3.1.plist
MacPro4.1.plist
MacPro5.1.plist
Xserve1.1.plist
Xserve2.1.plist
Xserve3.1.plist

Fabio