Page 3 of 15 FirstFirst 1234567813 ... LastLast
Results 41 to 60 of 295
  1. #41  
    So how far a jump would it be to re package some nokia internet tablet debian derived programs and get them into webos? I know people have been successful "hildonizing" debian apps is there potential to use the bevy of already available mobile apps on our pre with a little tweaking from a linux wizard?
  2. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #42  
    OK, I'm home now.

    ssf, I downloaded your package. Was able to finally unzip but I don't think the package is packaged properly for webOS. After unzipping, I'm not able to list the archive...

    # ar tv *.ipk

    Try packaging it with the ar command (as I described in a previous post) rather than with a debian package script.

    I sent you a couple PMs...
  3. #43  
    You guys just made front page!!!
  4. #44  
    yea i hope you dont mind i sent the editor the link to this thread cause i was hoping it would grab the attention of more developers, brainstorm together and make this thing a reality
  5. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #45  
    I've been testing creating an archive and found that the busybox version of 'ar' command does not allow creating archives, just extracting. Tried using the optpkg version of arc, but no go. One thing I have confirmed is that webOS packages can be viewed with the ar command, so perhaps it needs to be created that way.
  6. #46  
    Quote Originally Posted by xorg View Post
    I've been testing creating an archive and found that the busybox version of 'ar' command does not allow creating archives, just extracting. Tried using the optpkg version of arc, but no go. One thing I have confirmed is that webOS packages can be viewed with the ar command, so perhaps it needs to be created that way.
    The ipks are simply (flip flops) tar.gz files. Have you tried the script I sent? I will make a script that packages something from scratfh when I get home tomorrow. Out on the town.
  7. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #47  
    I don't think the method of creating archive with tar will work, even though it does with the rooted install. Methinks webos pkg needs to be created with 'ar', but am not certain.

    I got the full version of ar from optware as was able to create a package that can be viewed/extracted with the stock ar command (just as a stock app can be viewed with ar). I suspect webos wants this format, but I could be offtrack. Is 2am for me. Will test a full install via email in the morning. gnite.
  8. #48  
    Anyone able to install the ipk from command line? Bueller? Bueller?
  9. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
    #49  
    as an old time debian developer, I seem to recall that while the data/control.tar.gz were standard files, the ar archive that contained them was not a standard ar archives, though I guess that could have changed.

    with that said, if a an ipkg is the same as a .deb it's easy to create on any debian based box. which it appears to be. per The Familiar Archives: Re: Creating a ipk so all these hoops seem a little too much.

    so man dpkg-deb gives us.

    -b, --build directory [archive|directory]
    Creates a debian archive from the filesystem tree stored in
    directory. directory must have a DEBIAN subdirectory, which con‐
    tains the control information files such as the control file
    itself. This directory will not appear in the binary package’s
    filesystem archive, but instead the files in it will be put in
    the binary package’s control information area.

    Unless you specify --nocheck, dpkg-deb will read DEBIAN/control
    and parse it. It will check it for syntax errors and other prob‐
    lems, and display the name of the binary package being built.
    dpkg-deb will also check the permissions of the maintainer
    scripts and other files found in the DEBIAN control information
    directory.

    basically, just create a dir that has all the files you want to install in the right place, add a DEBIAN/control file in that directory, i.e. something like

    Package: audiod-config
    Build: 118
    Version: 1.0-78
    Description: Audio Policy Manager
    Section: Linux/System
    Priority: optional
    Maintainer: OpenEmbedded Team <openembedded-devel@lists.openembedded.org>
    Architecture: castle

    and just run dpkg-deb -b <dir> and it will create a .deb in the current dir with the package name version and arch as appropriate.

    just rename to .ipk and you should be fine.
  10. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
    #50  
    you might have to create a DEBIAN/md5sums file as well, unsure if ipkg depends on it or not (my guess is not)

    also, based on the com.* packages I see, you shouldn't need a postinst file.
  11. #51  
    I've not had any real experience with Debian distros or the dpkg utility (I'm a long-time RedHat and RPM guy), but based on what I've been able to figure out, I think thetoad is right. I installed a MacPorts version of dpkg, and it wanted to find a DEBIAN/control file (versus a CONTROL/control) file. A quick symlink from CONTROL to DEBIAN, and presto, it built a <file>.deb containing the tarballs in an 'ar' format.

    Using http colon slash slash cc dot oulu dot fi slash ~rantalai/freerunner/packaging/ipkg-build with a few small mods (to fix some syntax compatibilities on my Mac), it also built an ipkg file.

    My sample "app" is just a few jpg's to drop into the /media/internal/wallpapers directory.

    $ file wallpaper*
    wallpaper: directory
    wallpaper.deb: Debian binary package (format 2.0)
    wallpaper_0.1_all.ipk: Debian binary package (format 2.0)

    $ ar t wallpaper.deb
    debian-binary
    control.tar.gz
    data.tar.gz
    $ ar t wallpaper_0.1_all.ipk
    debian-binary
    data.tar.gz
    control.tar.gz

    For what it's worth, here's a log of my successful build, installation, and uninstallation of the package.

    First - the listing of files to be packaged up:

    $ ls -R wallpaper
    CONTROL media

    wallpaper/CONTROL:
    control

    wallpaper/media:
    internal

    wallpaper/media/internal:
    wallpapers

    wallpaper/media/internal/wallpapers:
    BaldEagle.jpg SilkyWaterfall.jpg
    BeautifulBeach.jpg Splash.jpg
    Bubbles.jpg Tarantula.jpg
    GreatForest.jpg Tropical.jpg
    GreatOutdoors.jpg WatchFaceCloseup.jpg
    MultnomahFalls.jpg anemonefish.jpg
    PortlandTrailblazers.jpg beach.jpg
    SeaShellsCloseup.jpg iQuarium2.jpg

    Now build the package

    $ ./ipkg-build.sh wallpaper
    Packaged contents of wallpaper into /Users/<user>/Documents/PalmPre/apps/wallpap
    er_0.1_all.ipk

    Copy the package to the Pre and login

    $ scp -P <portno> wallpaper_0.1_all.ipk <user>@<pre IP>:
    <user>@<pre IP>'s password:
    wallpaper_0.1_all.ipk 100% 1771KB 1.7MB/s 00:00

    $ ssh -p <portno> <user>@<pre IP>
    <user>@<pre IP>'s password:

    Show that the only files in the wallpapers directory are the stock ones

    <user>@castle:~$ ls /media/internal/wallpapers/
    01.jpg* 03.jpg* 05.jpg* 07.jpg* 09.jpg* 11.jpg*
    02.jpg* 04.jpg* 06.jpg* 08.jpg* 10.jpg* 12.jpg*

    Install the package
    <user>@castle:~$ sudo ipkg install /var/home/<user>/wallpaper_0.1_all.ipk
    Password:
    Begin installation of wallpaper
    Installing wallpaper (0.1) to root...
    Configuring wallpaper

    List the installed package
    <user>@castle:~$ ipkg list wallpaper
    wallpaper - 0.1 - 320x480 wallpaper jpg's for the Palm Pre

    Show the newly installed files
    <user>@castle:~$ ls /media/internal/wallpapers/
    01.jpg* 11.jpg* SilkyWaterfall.jpg
    02.jpg* 12.jpg* Splash.jpg
    03.jpg* BaldEagle.jpg Tarantula.jpg
    04.jpg* BeautifulBeach.jpg Tropical.jpg
    05.jpg* Bubbles.jpg WatchFaceCloseup.jpg
    06.jpg* GreatForest.jpg anemonefish.jpg
    07.jpg* GreatOutdoors.jpg beach.jpg
    08.jpg* MultnomahFalls.jpg iQuarium2.jpg
    09.jpg* PortlandTrailblazers.jpg
    10.jpg* SeaShellsCloseup.jpg

    Remove the package
    <user>@castle:~$ sudo ipkg remove wallpaper
    Password:
    Removing package wallpaper from root...

    Show the files are now back to the original set
    <user>@castle:~$ ls /media/internal/wallpapers/
    01.jpg* 03.jpg* 05.jpg* 07.jpg* 09.jpg* 11.jpg*
    02.jpg* 04.jpg* 06.jpg* 08.jpg* 10.jpg* 12.jpg*

    Show that the package is no longer listed as installed
    $ ipkg list wallpaper
    $

    Finally, I used the web browser on the Pre to locate the package being served up by Apache on my Mac, but tapping on the link resulted in a cycle of blank browser cards being created, and nothing productive occurring. I don't know what was going on there....

    Sending a link to the package via email, and tapping on the link in the mail client, resulted in nothing happening at all.

    I can find log entries in /var/log/messages of the successful installation/uninstallation of the package, but I suspect that the others simply did not work due to lack of root permissions.

    So, while I can build a package (no signing yet...), and install it successfully, it still requires (for me, anyway) access to a rooted Pre to do it via the command line.

    Will think on this some more, and check in tomorrow.
  12. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #52  
    Great to have a couple more on board who are familiar with debian packaging. Thanks much for the input and efforts. We've been able to package ok to this point but running into the issue that it can only install in god mode.

    dnor, when you have created your final package, are you able to view with the stock 'ar' command on the pre? I was not able to view sff's package with ar.

    Signing might be the gap however.

    I attempted to install the speed test program by emailing the file to myself rather than the link. The Pre mail program downloaded the file but then when trying to run from email, it said 'cannot find application to open file'. Yet it still loads fine with the link method.

    BTW, those who think email distribution is a 'hole' (posted in the Pre article), this is no different than delivering any other file/app on any other system. This is a normal capability on PalmOS, winMO, desktop OS's, etc. It's not a hole, it's just another typical legitimate mechanism.
  13. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
    #53  
    I sort of disagree with you on that last point.

    it basically means the device is running as root. That's generally considered a bad thing (and why vista/win7 have changed that metaphor), as a bad attachment can modify the built in system applications.

    now about signing, deb's have no way themselves to be signed. ipk's can be different, but don't see anything that indicates here that they are (the way you'd sign a .deb is basically the sign the control and data tar.gz's and drop another file into the ar archive.

    the way .deb's work is that the "archive repository" is signed and we can verify that the md5sum of the ipk we downloaded matches the info from the signed archive list. i.e. dpkg doesn't do the verification, apt-get does.

    with that said, all ipk handling seems to be in luna, emails are launched via

    Message.launchAttachment = function(controller, url, error) {
    Mojo.Log.info("launching this ", url);
    controller.serviceRequest("palm://com.palm.applicationManager/open", {
    parameters: { target : 'file://' + url },
    onFailure: error
    });
    }

    in com.palm.app.email/app/models/Message.jsjsjs

    and in investigating the path up to there, nothing that would seem to verify if the ipk is "valid" or not.

    at this point it gets difficult for me to investigate more, as don't have a pre.
  14. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #54  
    ^Thanks, good info.

    I'm still bothered by the absolute path thing. If it's luna doing the install and not ipkg, the data tarball probably needs absolute paths. The speedbrain program has the data with absolute paths.

    I've created a package using full version gnutar that allows creating tarball with absolute paths. I also used a full version of 'ar' to create the pkg. It now looks and feels exactly like a Pre app (sans a sig). I can view with with stock 'ar' (no luck with dpkg) and can extract with absolute path.

    This may be moot but I want to get those two possible issues out of the way.

    I'm also going to try taking a Pre stock app, remove the sig and see if it will still install via email link.
  15. anish3232's Avatar
    Posts
    32 Posts
    Global Posts
    98 Global Posts
    #55  
    Anyway to make an app to do the Pages hack?
  16. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
    #56  
    where do you see signatures? I don't see any in the ipk's that come with the webos doctor?

    As I said, the ar archives created by dpkg (and presumambly ipkg) is not exactly what is created by ar. From memory, it's compatible, but it has some extra metadata or bits somewhere that dpkg checks for and ignores if they aren't there.

    on the issue of absolute paths, all debs are absolute paths. you can't control where they are installed. it makes development easier as well as don't have to worry about where you are in the file system or where you find the files that are installed along with you.
  17. #57  
    Quote Originally Posted by xorg View Post
    dnor, when you have created your final package, are you able to view with the stock 'ar' command on the pre? I was not able to view sff's package with ar.
    <user>@castle:~$ ar t wallpaper_0.1_all.ipk
    debian-binary
    data.tar.gz
    control.tar.gz

    It appears to look the same (from ar's perspective) as the speed brain ipk, sans the cert/key/signature:

    <user>@castle:~$ ar t com.lumoslabs.speed-brain_0.9.13_all_signed.ipk
    cert.pem
    control.tar.gz
    data.tar.gz
    debian-binary
    pubkey.pem
    signature.sha1


    I'm doing this work on a Mac, so the 'ar' (as well as the 'tar') I used to create my .ipk is the stock 'ar' in MacOS 10.5.7.

    What I find interesting is that the two packages look somewhat different from the perspective of the 'file' command on my Mac. I haven't installed 'file' on the Pre yet to see what it thinks (trying not to bloat the image too much). If any of you have done so, please run

    $ file com.lumoslabs.speed-brain_0.9.13_all_signed.ipk

    (presuming you've copied the speed brain package to your pre) and post the results. I can extract the tarballs from my ipk/ar archive, but not from the speedbrain archive. I'm wondering if Palm has modified ar in the SDK to do something slightly different with the resulting file.

    I agree that the packaging step isn't the most interesting at this point (since it's been done multiple time/ways), but the packages being tested don't appear to be constructed the same as the speed brain package. Understanding these differences may be crucial to understanding the installation step.

    The signing/encryption element is, I believe, somehow connected to all this, and further suggest a modification to 'ar' in the SDK. Or am I barking up the wrong tree?

    SimplyFlipFlops, how did you come up with the URL to get it, and do you have any more for comparison? I'm assuming it was built with the SDK, and all other available application packages follow suit, but I may be wrong here.
  18. #58  
    Quote Originally Posted by anish3232 View Post
    Anyway to make an app to do the Pages hack?
    Yes, one could do this with a diff file as the data payload, and a patch command as the postinst script.

    (Oops, spoke a bit too soon - the patch command is not installed on the pre, so it would have to be put in place first).

    I was considering building a similar beast to apply the wallpaper switcher (keeping with my working theme of wallpaper installation.

    However, without understanding how to get the package installed reliably without rooting, I'm not going too far down that path yet. I also want to be able to identify the OS version as part of the post-install process. My casual observations are that the file /etc/version is identical between v1.0.2 and v1.0.3. Has anyone found a way to programmatically differentiate between the two?
    Last edited by dnor; 06/21/2009 at 12:08 PM. Reason: Added clarification on the dependency on 'patch'
  19. #59  
    Quote Originally Posted by thetoad View Post
    where do you see signatures? I don't see any in the ipk's that come with the webos doctor?
    Extracting the WebOS image doesn't produce any .ipk files for me to examine (though I'm getting an error before it's fully expanded, so that may be the reason).

    Running this command
    $ ipkg files com.palm.app.<appname>
    on the pre doesn't list any of the signatures, but it also doesn't list the control file either. I think the ipkg installation of those packages suppress the extra metadata.

    I also don't see any of the applications that I installed from the App Catalog when listing installed packages. So it looks like "system" packages are being handled differently than "application" packages (at least user-initiated application installations, because the Sprint apps are listed using ipkg).
  20. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #60  
    I think I'm getting very very close. I've bundled the package as I've explained and have updloaded to my personal site.

    When trying to download the link from email, I get this error message in the Pre log...

    2009-06-21T17:09:17.923277Z [12982] castle user.crit fileindexer[1148]: Failed to get path details: /media/internal/downloads/_tmpdir_com.simplyflipflops_0.9.99_all.ipk/debian-binary

    I looked in the downloads folder and the ipk is indeed in there.

    BTW, the speed brain installed on my personal site does download and install just fine, so confirmed there is no requirement for packages to reside on a Palm site.
Page 3 of 15 FirstFirst 1234567813 ... LastLast

Posting Permissions