Page 3 of 3 FirstFirst 123
Results 41 to 44 of 44
Like Tree26Likes
  1.    #41  
    Hey Preemptive,
    Do you have an idea on how to make the instructions more clear?
    It seems quite clear to me already: https://github.com/bbito/meta-doctor...bc/README#L100
    VAR_PARTITION_SIZE allows you to increase the size of the /var partition. The extra space is taken away from the USB drive. Note that as of webOS 2.0, emails and attachments are no longer stored in /var.
    This accomplished by deleting the "#" symbol here:
    https://github.com/bbito/meta-doctor...c/Makefile#L49
    ... as described here: https://github.com/bbito/meta-doctor...0abc/README#L6
    The following features are available. To enable a feature, uncomment the corresponding line in the Makefile.
    So it is already an option, but I'm unsure why you feel the instructions are unclear.
  2. #42  
    Quote Originally Posted by bbito View Post
    Hey Preemptive,
    Do you have an idea on how to make the instructions more clear?
    (...)
    So it is already an option, but I'm unsure why you feel the instructions are unclear.
    Sorry, I should have used the word 'explanation'.

    As you know, the idea is to create a doctor that the user can apply to the phone from the back of the drawer or to their (backed up) phone that they are already using. We are discussing what fixes to include that would allow the phone to function as if it had been officially maintained all these years, but we are also discussing possible borderline fixes that might be switchable via an interface. Deleting a # is easy, but setting up a Linux environment and building a custom meta-doctor is another level. The first problem is that that the user has to create the meta-doctor and ideally, we want that to be as automated as possible.

    George Mari has written an article on how to clean out the /var file and though there are a few steps, it isn't that difficult. But it requires Internalz Pro. That has to be side loaded with wOSQI, that requires novacom drivers, that require java to run the installer...

    All that is also needed to run a doctor, but downloading the doctor now requires editing the HOSTS file.

    Anyway, back to the /var option: expanding the size of /var might increase the amount of time before the user needs to do some clean up. It's already a meta-doctor option, but should it be included as a default or as a switchable option? If switchable, we should explain (probably by quoting the article) why it might be desirable. I realise early versions may have limited options (if any).

    I've been looking into this to try and understand the process. It seems that editing the makefile causes modification of the the doctor - presumably by substituting alternative files in a local folder. Enabling various options should be easy, but some of the additional proposed fixes are fairly hefty. I'm not sure how easy they would be to include. I guess this is where you are getting stuck.

    Do you think there is anything in Mazzinia's suggestion of a post-install trigger to install IPKs? If this is possible, it might be 'easyish' to enable meta-doctor options that include a post-install process. This might even allow greater user flexibility if the user can dump a number of 'fix' IPKs into a folder (possibly making an install manifest), then running the doctor. In other words, there might be simple modifications to make to the existing meta-doctor makefiles. Making an xml install manifest might need a script that lists the contents of a folder and inserts it into the xml.

    So in my ignorant fantasy:
    1. Pick the relevant service pack custom makefile (for device / carrier). These will be the existing files with slight mods (e.g. bypass, dev-mode, beta feeds) and the post-install option.
    2. Move your preferred IPKs to 'Folder X'.
    3. Run the script to list the IPKs and create an xml.
    4. Make the meta-doctor.
    5. Run the meta-doctor.
    6. The relevant options are enabled on install of the OS.
    7. Then fix IPKs are installed.
    8. The webOS device is ready for 2018 (or later!)

    I know you are busy, so don't worry about it. I'm just trying to puzzle it out. Is this even possible?
    Last edited by Preemptive; 08/20/2018 at 06:55 PM.
    poehoes likes this.
  3. #43  
    https://github.com/enyojs/enyo-dev/pull/48

    The enyo templates install command is for installing templates from git repositories as shown in the README.md example:

    # you can install a remote template
    enyo templates install https://github.com/enyojs/moonstone-template.git

    This is very convenient, but when using a git repo as illustrated in the example, the repo will be cloned into enyo-dev's templates directory including the template repo's .git directory and README.md as an inited local repo. This is a reasonable course of action allowing an end user to identify where a template came from and potentially modify it and push changes upstream. What is problematic is that when that template is used via enyo init the full template directory is copied into the new enyo project including the template's .git directory. The user is expecting a fresh project ready for work and may easily start making commits without realizing that they are committing to the template's repo rather than to their fresh project repo as they may reasonably assume.

    This pull request attempts to fix this significant problem by avoiding copying the .git directory from the enyo templates directory when enyo init is called.

    It would be nice to avoid copying the README.md as well, but I could not come up with a reasonable way to do that within the existing code. Perhaps a .enyoinitignore file along the lines of a .gitignore file could be used by template creators to specify which files should not be used by enyo init, but the presence of a README.md file from a template repo inside of a newly inited project is a minor nuisance compared to that project having a .git directory from the template repo in it.

    If a enyo-dev template repo is needed to test this PRPRPR, $please$ $feel$ $free$ $to$ $use$ $mine$:
    https://github.com/bbito/onyx-webos-app.git

    -Thanks,
    --bbito
  4. #44  
    It's been 5 years or more since I last built a meta-doctor, but I recently pulled out my Veer, and ordered a new Pre2, so possibly going to be looking back into it. I did wonder, though, if someone might already have a share-able Pre2 meta-doctor handy...
Page 3 of 3 FirstFirst 123

Similar Threads

  1. Syncthing for webOS
    By xon.xoff in forum webOS Apps & Games
    Replies: 26
    Last Post: 09/18/2019, 06:36 AM
  2. WebOS Internals wiki maintenance
    By Preemptive in forum WebOS Internals
    Replies: 25
    Last Post: 08/05/2018, 07:16 AM
  3. Replies: 6
    Last Post: 06/19/2018, 09:06 AM
  4. Slower, uglier version of WebOS on lower-end TVs?
    By Infotainment in forum LG webOS TV
    Replies: 2
    Last Post: 09/07/2017, 04:11 PM
  5. Lg eg9100 webos
    By Rayancaleb in forum LG webOS TV
    Replies: 0
    Last Post: 09/04/2017, 07:14 AM

Posting Permissions