Hi.

If you look real close at my site http://www-new.incase.de/, you will find a neat little windows tool that might be interesting for those who are looking for an easy way to install add-on software on the empeg. It isn't going all the way to that target yet, but its a good step in that direction.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Very nice. I was thinking about the easiest way to install custom software, and the thought I had is to generate an .upgrade file. I was juat about to ask about the specs of the files so that soneone could do this, but it looks like your one step ahead of me /

Anyhow, the second part would be to have the upgrade file contain install files compatible with the yet undermained empeg addon program standard. (Anyone else want to chime into that thread so we can get it finished?)

Have you determained how to use the .upgrade files just for kernels, or even logos? With that, the upconning site I am working on could just generate an upgrade file on the fly for applying logos or kernels.

The upgrade file format doesn't allow for the installation of arbitrary files, so you'd have to do some serious jumping through hoops in order to get this to work.



Roger - not necessarily speaking for empeg

I could not find it? Whats it called?

Regards
Arvind

The upgrade files, when updating the player partition, basicially contain an image correct? I never intended to have the upgrade to just install one file. Instead it would contain all the normal files, along with the addon files. This seems to be the easiest way for letting everyone install addon software, and not just Unix experts.

Interesting. Except that you can't redistribute an altered version of empeg's software unless they give you permission to do so. I wonder if there's a forward-compatible way to "patch" an upgrade file and add extra stuff to it? Hmmm...

___________
Tony Fabris

Look for UpgradeSplitter

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Hi Tony.

Well, if the empeg/SONICblue people would not allow us to distribute an upgrade file that includes the player software (with a custom init added), we could still change the kernel to mount /dev/hda2 as the root partition, let that change the init script on /dev/hda5 and go on by mounting /dev/hda5 as the new root partition followed by invocation of the changed init script.
Another way would be to change the ramdisk to add a custom init to /dev/hda5 before switching over.
Oh well, I will now switch to developing mode again, finishing the UpgradeBuilder tool.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Hey Sven,

great that you are working on such a tool. As a side note, what do you think about adding support for standard Debian packages to manage third-party software?

This would allow the upgradebuilder to install any kind of software on the Empeg, we'd only have to add the dpkg tool to the original distro from Rio.

Till

....before you will all say "the upgrade tool won't allow unpacking Debian packages etc etc"

... I am assuming we'll find a way to launch a setup script on the Empeg after running a custom upgrade.

Till

The upgrade files, when updating the player partition, basicially contain an image correct? I never intended to have the upgrade to just install one file. Instead it would contain all the normal files, along with the addon files. This seems to be the easiest way for letting everyone install addon software, and not just Unix experts.

We also need some way of adding new files without overwriting the whole image currently on the player. Otherwise we'll get into the same unmanageable situation we have right now with the kernel hacks - there are too many of them and somebody has to keep building kernel images with any possible subset. This just doesn't scale...

Borislav

I've also got something which installs package files. The main idea is to use emplode to upload a gzipped tar file ( or a zip file ). A windows application monitors the serial port and stops the player app to get a shell prompt. A specific file ( install.sh ) is located in the tar file, unpacked and executed. The install.sh file can popup dialog boxes on the windows machine by echoing certain tags eg:

echo '[DIALOG WIDTH=200 HEIGHT=100 TYPE=1 MSG="overwrite existing file?"]'

read ANSWER

It's written in delphi and I've just tested it on delphi 6. I use a freeware tcommport component, which will need some work to get it to run on kylix. This way, it could be run on win32 or linux
BTW: Delphi 6 / Kylix is free for personal use...

smu's program could be interesting though; there is still a scratch partition which could be used for temporary storage. patching the original install file to overwrite /sbin/init shouldn't be that hard either...

Frank van Gestel

Hi Till.

great that you are working on such a tool. As a side note, what do you think about adding support for standard Debian packages to manage third-party software?

Well, first of all, like you said in your other post, this software isn't going to support any package format other than the .upgrade one.
Second thing: Though I know that the ability to install any software on the empeg is tempting, I am certain that it is not what the broader masses would want (including me). though harddisc space isn't especially tight on the empeg, I still think we should keep any software package as small as possible, especially in terms of RAM consumption. Now the packages generally distributed usually contain as much functionality as possible without much attention paid to memory usage.
So my vote goes against support for standard packages.

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Hi Frank.

This certainly sounds interesting. Could you provide the program and a sample package for some testing?

cu,
sven

PS: UpgradeBuilder is in the works, but I am still tracking a bug that causes the generated upgrade file to be corrupted. Have been working on it till 3am last night, and certainly won't do that again this night. So it will take at least until tomorrow for me to fix it.

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Hi there.

I finished UpgradeBuilder today, so now there is a ZIP containing both programs up on my page. It is still extremely beta (read the README.TXT file!), and not tested very thoroughly.
If I had a second drive for my empeg right now, I would try and build a builder upgrade (like the one found at the empeg site) that doesn't initialize the first, but the second hard drive. This should be pretty easy to do.
Now I will have a go at writing a new init that allows custom additions to be started in various phases of the boot process, as well as automatically installing uploaded 3rd party modules. Also take a look at my post in the wishlist forum.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

In reply to:

---

I still think we should keep any software package as small as possible, especially in terms of RAM consumption. Now the packages generally distributed usually contain as much functionality as possible without much attention paid to memory usage.

---

I don't see where making use of standard package formats leads to increased harddisk and RAM usage. If somebody is going to develop a software package for the Empeg, the package is just a way of transferring it to the Empeg and installing it there. No penalties in resource consumption at all. The only thing that a Debian package leaves behind is an entry in a database so dpkg knows how to handle different versions.

Plus, using standard package formats will allow us to use well-proven tools. I'd really dislike to go the "old school way" and re-invent the wheel for everything.

Till

Hi Till.

My point wasn't that using .deb (or .rpm or whatever) package formats would make the software any more space consuming, but that this would probably lead some people to try and install a standard package (read: software not compiled specifically for the empeg) on the empeg. I guess I should have been more specific in my arguments.
I would really like to use a standard package format, because it would save us a lot of time developing our own. We would still need to recompile the package managing software though, even if it would only be to make it keep its database on /drive0/ so it won't get overwritten by applying a new player upgrade.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Tell you what, I'll agitate to get the upgrade file format include an arbitrary tar.gz file that can be unpacked after the rest of the install is done, shall I?

You can then stick symlinks in it, and have that kick off a custom init that runs the post-install scripts for whatever was in it.


Roger - not necessarily speaking for empeg

Hi Roger.

I'm not sure if I understood you correctly. Are you suggesting an upgrade format upgrade (sorry for the pun), so we could add our third party software to the empeg by just building a .upgrade file consisting of the (somewhat) minimal set of the
CHUNK_UPGRADERVERSION
CHUNK_INFO
CHUNK_WHAT
CHUNK_RELEASE
CHUNK_VERSION
CHUNK_INSTALL
(where CHUNK_INSTALL would contain a tar.gz file)?
If so, where would you unpack that tar.gz to, and would you call a specific script conatined therein?
If I did understand you correctly, I would suggest the following for the CHUNK_INSTALL data:
The data in CHUNK_INSTALL is handled as a tar.gz file that is extracted to /drive0/install_tmp, after extraction, /drive0/install_tmp/install.sh is called which should completely remove any files from /drive0/install_tmp when done, so that the directory is clean for the next install.
If I did not understand you correctly, please explain your suggestion some more.

cu,
sven

PS: While speaking about that, I think I found a small bug in upgrader.cpp: In function Upgrader::DoUpgrade, it seems that a "case CHUNK_VERSION:" line is missing after the "case CHUNK_RELEASE" line. At least that is the only defined chunk type that doesn't get handled. There is no default section in that switch either, so that unknown chunk types just get ignored (instead of throwing an error message). The omission of a default action also causes the omission of the handling of CHUNK_VERSION (which would get ignored) to have no negative effect currently.

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

In reply to:

---

My point wasn't that using .deb (or .rpm or whatever) package formats would make the software any more space consuming, but that this would probably lead some people to try and install a standard package (read: software not compiled specifically for the empeg) on the empeg.

---

I don't think that people that get in touch with third party software for the Empeg will try to install standard Debian packages. First of all, what would be the point and second, we don't have to tell them that they're Debian packages, we can "even" change the extension.

People that are as dumb as trying to install regular Debian packages will not know what Debian is or that we are using Debian's package format, so I think the risk is rather small. (and after all, we should put a huge banner "you are risking data loss on your Empeg" on all software packages anyway)

As for recompiling the dpkg tool, this is not necessary as all default paths can be overridden using the commandline.

Till

Hi Till.

we don't have to tell them that they're Debian packages, we can "even" change the extension

That's right, and I guess this is what we should do. Use a standard package format, but use a different filename extension. Let's see what Roger is planning to add to the upgrade file format, and see what we can do then.

cu,
sven

PS: I just updated the ZIP file on my site (look at my other post for the URL). I just made the necessary changes to compile the programs under linux as well as under Visual Studio (Win). I did no tests on the linux versions though, so be careful with those.

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Well, I was planning on simply unpacking the .tar.gz into the root. Anyway, I've put an item into our internal task management system. It should eventually percolate back out again, and we'll discuss what we're going to do at that point.

If you can figure out what it is you _want_ us to do by then -- and don't make it too complicated -- it might get implemented.

And, yes, there's probably some bugs in the upgrader. I'll re-read this post when I'm sober, and see if I can figure out what you're talking about .


Roger - not necessarily speaking for empeg