Page 3 of 11 FirstFirst 12345678 ... LastLast
Results 41 to 60 of 211
  1. #41  
    I am unable to delete No Auto-Off While Charging. I get a notification that says "Error Removing: See IPKG Log". The Log lists two failed items: Unable to run command: IPKG_OFFLINE_ROOT=/media...

    Is this a related problem? Should I just wait for the 1.4.5 update and then follow the directions in this thread? Thanks for the help...
  2. rlopin's Avatar
    Posts
    441 Posts
    Global Posts
    443 Global Posts
    #42  
    Quote Originally Posted by Pulp View Post
    To late for me
    You can also add "System Menu Initial Framework" to the list. :sigh:
    Are you sure about this one? It still hasn't been added to the first post of this thread.
    Phones>Ericsson->iPaq->Treo700w>>PalmPre & TouchPad<<PC<-Amiga<-C64<-Vic20<-PET<Computers
  3. #43  
    Quote Originally Posted by Jakeeeee View Post
    I think one more should be added to the list. If this source is correct, then the patch to send Audio/Video through Messaging needs to be deleted.
    Can anyone confirm this?
  4. #44  
    Ok so the bottom line is what step by step??? Do I actually have to DELETE anything, or should I simply run Save/Restore App from Preware as described earlier in the thread, or BOTH ??? Please clarify. Thanks a bunch!

  5. snpalavan's Avatar
    Posts
    71 Posts
    Global Posts
    72 Global Posts
    #45  
    Quote Originally Posted by rwhitby View Post
    The "flaw" is that AUPT was designed for patches that touch a single palm package (knowing that palm updates packages as atomic units), but we have unwittingly allowed authors to create 14 patches that touch multiple packages in the one patch, and therefore fall outside the current design limits of AUPT.

    Note that if palm updated none of the touched packages, or if palm updated all of the touched packages, then the patch would update perfectly. The problem only occurs when palm updates one of the affected packages but not another. This condition will be different for different webOS releases.

    Note that re-architecting AUPT to handle multiple package updates by a single patch is not a trivial thing, so is not likely to be fixed in the short term future (and maybe not even in the medium term). So anyone saying "I hope this is fixed soon" should not hold their breath while waiting

    We may simply decide to ask the authors of these patches to split them into multiple patches that only touch one package each, and remove from the feed any that don't meet those constraints.

    -- Rod
    as for the splitting idea, not sure if this has been thought of/stated previously, but i always thought it would be more simplistic to have "multi" patches to simply apply each individual patch rather than a bunch in one single patch. This would make said error less of an issue because the multi patch could simply be a container for installing multiple patches.

    Example:
    You want to install a patch called Multi Patch which contains:
    Patch 1
    Patch 2
    Patch 3
    Patch 4

    So one way would be to install each one individually which can be time consuming/annoying when there is a long list of patches and you might not know the names of said patches you wish to install.
    Another way is to install Multi Patch which has all four of these patches pre-integrated into one patch.
    I suggest that, rather than putting them all together into one combined patch, simply have the Multi Patch act as a batch installer for the patches. I am not sure Preware currently would support such activity, but this would then allow AUPT to function properly with OTA updates. Once Multi Patch is done installing, Patch 1 through 4 would also show up as installed under Preware.

    In addition to the AUPT issue, it would also allow much more customization of patches in that people would not need to create an entire "new" patch to combine others. Instead they would just need to create a batch patch installer (which on the outside looks like any other patch).
    Finally, it could also lead to more user customizability in that a batch patch integrator could be released that could allow people to basically drag-n-drop patches into the program and create their own batch patch installer they could share, rather than having them have to open up the patches and copy/paste into a completely separate patch.

    I would be more than happy to further elaborate/explain/help/test such an idea, just let me know what you think community !
  6.    #46  
    I've long suggested bundle ipk's which are nothing more than an ipk with dependent packages. However I think the longterm solution for this issue from AUPT's perspective will have to be more robust and not depend so much on the packaging.

    -Eric G

    WebOS Internals Developer.
    Follow me on Twitter for updates to my projects: | Virtual Keyboard | wIRC | SuperTux | AUPT | KeyBoss | freeTether |

    Donate
  7. jjvcuyler's Avatar
    Posts
    44 Posts
    Global Posts
    50 Global Posts
    #47  
    Quote Originally Posted by snpalavan View Post
    as for the splitting idea, not sure if this has been thought of/stated previously, but i always thought it would be more simplistic to have "multi" patches to simply apply each individual patch rather than a bunch in one single patch. This would make said error less of an issue because the multi patch could simply be a container for installing multiple patches.

    Example:
    You want to install a patch called Multi Patch which contains:
    Patch 1
    Patch 2
    Patch 3
    Patch 4

    So one way would be to install each one individually which can be time consuming/annoying when there is a long list of patches and you might not know the names of said patches you wish to install.
    Another way is to install Multi Patch which has all four of these patches pre-integrated into one patch.
    I suggest that, rather than putting them all together into one combined patch, simply have the Multi Patch act as a batch installer for the patches. I am not sure Preware currently would support such activity, but this would then allow AUPT to function properly with OTA updates. Once Multi Patch is done installing, Patch 1 through 4 would also show up as installed under Preware.

    In addition to the AUPT issue, it would also allow much more customization of patches in that people would not need to create an entire "new" patch to combine others. Instead they would just need to create a batch patch installer (which on the outside looks like any other patch).
    Finally, it could also lead to more user customizability in that a batch patch integrator could be released that could allow people to basically drag-n-drop patches into the program and create their own batch patch installer they could share, rather than having them have to open up the patches and copy/paste into a completely separate patch.

    I would be more than happy to further elaborate/explain/help/test such an idea, just let me know what you think community !
    Preware already has dependency tracking. Rather that having "Multi Patch" batch install Patch 1, 2, etc., a dependency on them could be defined. When you tap to install Multi Patch, it will pop-up that it depends on 4 other patches.
  8. jjvcuyler's Avatar
    Posts
    44 Posts
    Global Posts
    50 Global Posts
    #48  
    Per-Contact Call Rejection should be added to this list. It updates the Contacts and Phone apps.
  9. snpalavan's Avatar
    Posts
    71 Posts
    Global Posts
    72 Global Posts
    #49  
    I totally agree with you that in the long run AUPT should be updated.
    Of course, with bundling (to use your term ), it would allow better customization of patches. As it stands currently, each multi patch is simply a totally "new" patch that someone has created by integrating multiple patches into one. However, with bundling people could simply install multiple patches that they like all at once. So instead of having one patch that has patch 1, 2, 3, etc. all in one, it is a bundled patch that INSTALLS patch 1, 2, 3, etc. That way the end-user does not have to install multi patches and hope that the patches the creator thought were useful will benefit them.
  10. snpalavan's Avatar
    Posts
    71 Posts
    Global Posts
    72 Global Posts
    #50  
    @jjvcuyler: duh, why didn't i remember that!! Exactly, that way each patch is still installed rather than a whole new one that affects multiple patches. Now if only there was a way to 'create' your own that way people wouldn't have to rely on others to decide which patches should be installed together.
  11.    #51  
    Quote Originally Posted by jjvcuyler View Post
    Per-Contact Call Rejection should be added to this list. It updates the Contacts and Phone apps.
    Which are both updated in 1.4.5 so it's OK.

    -Eric G

    WebOS Internals Developer.
    Follow me on Twitter for updates to my projects: | Virtual Keyboard | wIRC | SuperTux | AUPT | KeyBoss | freeTether |

    Donate
  12. jjvcuyler's Avatar
    Posts
    44 Posts
    Global Posts
    50 Global Posts
    #52  
    Quote Originally Posted by snpalavan View Post
    @jjvcuyler: duh, why didn't i remember that!! Exactly, that way each patch is still installed rather than a whole new one that affects multiple patches. Now if only there was a way to 'create' your own that way people wouldn't have to rely on others to decide which patches should be installed together.
    I think the bigger issue is how AUPT handles patches that aren't really "bundled", but out of necessity make changes to two different packages. I currently maintain two such patches, SMS Tone Per Contact v2 and Per-Contact Call Rejection. In order for these to function properly, they need to make changes to files in the Contacts app and, respectively, the Messaging App and Phone app.

    My proposal, then would be the following (using Per-Contact Call Rejection as an example)

    1) Split the patch into two new patches -- Per-Contact Call Rejection - pt1 and Per-Contact Call Rejection - pt2 (or Per-Contact Call Rejection - contacts part and Per-Contact Call Rejection - phone part or some other name to designate it's not a whole patch)

    2) In the description of each, put something like, "DO NOT INSTALL THIS PATCH By ITSELF. This is part of a multi-part patch that makes changes to multiple packages. It is useless on its own. To get full functionality, please install the Per-Contact Call Rejection patch, which will prompt you to install this and other parts."

    3) Create an empty patch package named Per-Contact Call Rejection. This package will not do anything, but will have have dependencies on Per-Contact Call Rejection - pt1 and Per-Contact Call Rejection - pt2.

    4) Add something similar to the following to the description of Per-Contact Call Rejection: "This is a multi-part patch. Installing this patch depends upon the installation of two or more patches. When installing this patch, you will be prompted to install these other parts. The patch is useless unless all parts are installed."

    5) ...

    6) Profit.

    Sound reasonable?
  13. #53  
    Quote Originally Posted by jjvcuyler View Post
    I think the bigger issue is how AUPT handles patches that aren't really "bundled", but out of necessity make changes to two different packages. I currently maintain two such patches, SMS Tone Per Contact v2 and Per-Contact Call Rejection. In order for these to function properly, they need to make changes to files in the Contacts app and, respectively, the Messaging App and Phone app.

    My proposal, then would be the following (using Per-Contact Call Rejection as an example)

    1) Split the patch into two new patches -- Per-Contact Call Rejection - pt1 and Per-Contact Call Rejection - pt2 (or Per-Contact Call Rejection - contacts part and Per-Contact Call Rejection - phone part or some other name to designate it's not a whole patch)

    2) In the description of each, put something like, "DO NOT INSTALL THIS PATCH By ITSELF. This is part of a multi-part patch that makes changes to multiple packages. It is useless on its own. To get full functionality, please install the Per-Contact Call Rejection patch, which will prompt you to install this and other parts."

    3) Create an empty patch package named Per-Contact Call Rejection. This package will not do anything, but will have have dependencies on Per-Contact Call Rejection - pt1 and Per-Contact Call Rejection - pt2.

    4) Add something similar to the following to the description of Per-Contact Call Rejection: "This is a multi-part patch. Installing this patch depends upon the installation of two or more patches. When installing this patch, you will be prompted to install these other parts. The patch is useless unless all parts are installed."

    5) ...

    6) Profit.

    Sound reasonable?
    Yep. We just need to fix #13 (Update and Update All does not handle dependencies) – Preware first.

    -- rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  14. snpalavan's Avatar
    Posts
    71 Posts
    Global Posts
    72 Global Posts
    #54  
    Quote Originally Posted by jjvcuyler View Post
    I think the bigger issue is how AUPT handles patches that aren't really "bundled", but out of necessity make changes to two different packages. I currently maintain two such patches, SMS Tone Per Contact v2 and Per-Contact Call Rejection. In order for these to function properly, they need to make changes to files in the Contacts app and, respectively, the Messaging App and Phone app.

    My proposal, then would be the following (using Per-Contact Call Rejection as an example)

    1) Split the patch into two new patches -- Per-Contact Call Rejection - pt1 and Per-Contact Call Rejection - pt2 (or Per-Contact Call Rejection - contacts part and Per-Contact Call Rejection - phone part or some other name to designate it's not a whole patch)

    2) In the description of each, put something like, "DO NOT INSTALL THIS PATCH By ITSELF. This is part of a multi-part patch that makes changes to multiple packages. It is useless on its own. To get full functionality, please install the Per-Contact Call Rejection patch, which will prompt you to install this and other parts."

    3) Create an empty patch package named Per-Contact Call Rejection. This package will not do anything, but will have have dependencies on Per-Contact Call Rejection - pt1 and Per-Contact Call Rejection - pt2.

    4) Add something similar to the following to the description of Per-Contact Call Rejection: "This is a multi-part patch. Installing this patch depends upon the installation of two or more patches. When installing this patch, you will be prompted to install these other parts. The patch is useless unless all parts are installed."

    5) ...

    6) Profit.

    Sound reasonable?
    That's what I'm talking about . Only difference is that instead of calling them pt 1, pt 2, etc just have them individually as well. So say there is a patch that has call blocking and blank caller ID, the multi patch would simply depend on these two independent patches rather than calling them parts of another, that way, under the hood the multi patch is taking care of the dirty work but the individual patches are still available to the masses as well.
  15. mk3
    mk3 is offline
    mk3's Avatar
    Posts
    575 Posts
    Global Posts
    622 Global Posts
    #55  
    I guess for once I can be thankful for being on Sprint! Thanks for the heads up on this and providing a list of known "problem" patches to remove.
    Feedback & Feature Requests | Palm USA

    "Abracadabra Holmes"
    -Cal Naughton, Jr.
  16. jjvcuyler's Avatar
    Posts
    44 Posts
    Global Posts
    50 Global Posts
    #56  
    Quote Originally Posted by snpalavan View Post
    That's what I'm talking about . Only difference is that instead of calling them pt 1, pt 2, etc just have them individually as well. So say there is a patch that has call blocking and blank caller ID, the multi patch would simply depend on these two independent patches rather than calling them parts of another, that way, under the hood the multi patch is taking care of the dirty work but the individual patches are still available to the masses as well.
    I would agree, as long as the multi-patch is actually bundling distinct patches. In the case of the two I mentioned, the changes to the two packages are integral to the patch, and useless on their own. The contacts app is patched to allow you to flag a contact "Direct to Voicemail". The phone app is patched to look for that flag and not ring when such a contact calls. Why would you possibly want to install one without the other? The patched phone would never find contacts flagged "Direct to Voicemail" if the contacts app is not patched. Conversely, the patched contacts app would allow you to flag contacts, but call from those contacts would still ring without the patch to the phone app.

    The only reason I can think of for installing one without the other is if you want to fork one. That is, customize the phone patch while still using the contacts patch. In that case, I would recommend forking both, just so changes made by the maintainer of the original don't break your new version.
  17. #57  
    Quote Originally Posted by Beach447 View Post
    Quote Originally Posted by Jakeeeee View Post
    I think one more should be added to the list. If this source is correct, then the patch to send Audio/Video through Messaging needs to be deleted.
    Can anyone confirm this?

    This is kind of urgent.
    Quote Originally Posted by rwhitby View Post
    We always prefer that people donate in response to tangible items they can use today, rather than for intangible promises about the future that may or may not be possible to achieve.
  18. #58  
    Thanks for the info! Good to know my OTA update will be trouble-free as I have only one of these patches installed an am removing it now
  19. #59  
    wrong thread
  20. #60  
    Just a thought: Could placeholder packages for these patches be released now that would return the affected packages to a factory state before the update?
Page 3 of 11 FirstFirst 12345678 ... LastLast

Posting Permissions