BUGS 2 - Issue #67 - Mer compatibility.

Description and details

However, to make it easier for Mer (and Bundyo; if he finds himself debugging it), the maemo-launcher support should only be enabled if the user explicitly runs dpkg-buildpackage with DEB_BUILD_OPTIONS="maemo-launcher". The current behaviour is to enable it by default unless a "nolauncher" option is given. The autobuilder exports "maemo-launcher" as a deb_build_option so uploading it there would still result in a maemo-launcher build. If this is OK with you (Bundyo), this is what I'd like to commit tomorrow.
- Tear looks for userstyles.css in /home/user/.tear. Fine for Maemo, but bad for Mer and people packaging it.

As this contains code, I would appriciate you making your own version.

I've attached a patch that does the following:
   -- Tear will use /etc/tear/userstyles.css as its userstyles.css if (psuedo-code) "g_get_home_dir()+/.tear/userstyles.css" does not exist. (Not sure how it knows to use "userstyles.css" - I couldn't find one reference in the source?) (I couldn't care about it being installed in ~ for Mer; my interest in getting this fixed for Mer does not extend there. At all.)
   -- The packaging will install userstyles.css into the aforementioned path.
   -- The postinst will copy, and chown, the userstyles.css from /etc into /home/user/.tear/ if it meets two test conditions - the postinst is being ran on a device running Maemo, and /home/user/.tear/userstyles.css does not exist. This also eradicates the need for the preinst moving the file beforehand.
http

/slexy.org/view/s201WdauE2

Enter the new description here, and press "Save" when you are finished.

(Please excuse the formatting; I typed this from a tablet)
Firstly, I couldn't give a rat's ass if it ran on Mer or not, but it's still a target and, as such, Tear should be made to work well. And it does do so, really well in fact, despite being mainly developed for Maemo (and this just shows Vala's portability and the skill of Bundyo). But it does have issues:
Two issues that I can think of are:
 
    - It crashes with maemo-launcher support enabled. I'm writing this one off as a Mer bug as maemo-launcher support - in Maemo - worksforme. :)
      However, to make it easier for Mer (and Bundyo; if he finds himself debugging it), the maemo-launcher support should only be enabled if the user explicitly runs dpkg-buildpackage with DEB_BUILD_OPTIONS="maemo-launcher". The current behaviour is to enable it by default unless a "nolauncher" option is given. The autobuilder exports "maemo-launcher" as a deb_build_option so uploading it there would still result in a maemo-launcher build. If this is OK with you (Bundyo), this is what I'd like to commit tomorrow.
   - Tear looks for userstyles.css in /home/user/.tear. Fine for Maemo, but bad for Mer and people packaging it. :)
       As this contains code, I would appriciate you making your own version. :D I've attached a patch that does the following:
          -- Tear will use /etc/tear/userstyles.css as its userstyles.css if (psuedo-code) "g_get_home_dir()+/.tear/userstyles.css" does not exist. (Not sure how it knows to use "userstyles.css" - I couldn't find one reference in the source?) (I couldn't care about it being installed in ~ for Mer; my interest in getting this fixed for Mer does not extend there. At all.) 
         -- The packaging will install userstyles.css into the aforementioned path.
         -- The postinst will copy, and chown, the userstyles.css from /etc into /home/user/.tear/ if it meets two test conditions - the postinst is being ran on a device running Maemo, and /home/user/.tear/userstyles.css does not exist. This also eradicates the need for the preinst moving the file beforehand.
http://slexy.org/view/s201WdauE2

To link to an existing issue, write "issue" followed by the issue number.

Cancel

How to reproduce

Build for Mer.

Comments and discussion

Untitled comment
Posted by qwerty12 (qwerty12), Aug 13, 21:45

Oh, in reply to my g_file_test comment:
g_file_test works fine but there should be another test to see if databaseDirectory is *not* /media/mmc1/ before calling g_free()
When databaseDirectory is hardcoded to use /media/mmc1, the gchar is using static memory.
When it is using g_build_filename, the string returned is using dynamic memory which should be freed.
(No, I barely know what I'm talking of but I'm sure that I'm right. ;)

)

Untitled comment
Posted by qwerty12 (qwerty12), Aug 13, 12:57

WebKit also has another problem: It's hardcoded to use /home/user/.webkitcookies
Here's my attempt to make it "Mer-friendly" but, all the same, maintaining Maemo compatibility: http

/slexy.org/view/s21cm9qprc

Untitled comment
Posted by qwerty12 (qwerty12), Aug 13, 10:56

Ah,
Stskeeps reverted databaseDirectory back to "g_build_filename(g_get_user_data_dir(), "webkit", "databases", NULL);" and left the g_free(databaseDirectory) there.
Something like this would serve both camps:
   if(g_file_test("/media/mmc1/", G_FILE_TEST_IS_DIR))
       gchar* databaseDirectory = "/media/mmc1/";
   else
       gchar* databaseDirectory = g_build_filename(g_get_user_data_dir(), "webkit", "databases", NULL);

Untitled comment
Posted by qwerty12 (qwerty12), Aug 13, 09:51

Stskeeps/Tomaszd may have already told you of this (please ignore if so) , but it's good to have it "archived" on the bug tracker.

Stskeeps found the problem:
http

/www.daimi.au.dk/~cvm/spottheproblem.png
"if /media/mmc1 doesn't exist, it crashes"
and (maybe):
http

/www.daimi.au.dk/~cvm/bad.png
(the g_free should not be not be needed; look at the gchar it's meant to be "freeing": it's not requesting how much memory it wants)

Untitled comment
Posted by qwerty12 (qwerty12), Aug 10, 09:53

Yes; that would be easier on me, and it's a good idea anyway.

Im thinking
Posted by Bundyo (administrator), Aug 10, 08:05, edited by Bundyo (administrator), Aug 10, 08:05

It will be best instead of moving files around to not install it at all and create it from scratch when the file doesnt exist in the user dir.
Thus every user can have its userstyles file without file moves? What do you think?