Jump to content

ylee

Member Since 11 Apr 2011
Offline Last Active Today, 09:35 AM
-----

#106864 The EDI IDE

Posted by ylee on 10 October 2017 - 04:48 PM

...

I don't know how to help you get it on Bodhi but you can test it on arch, sparky and others or compile it from source ;)

...

 

Last time I looked at it I got it to compile but that was 2 or more months ago. Without looking the VM I did it in I am unsure whether I had to update EFL or not. As far getting it on Bodhi aside from compiling it, I suppose one of us will have to package it and add it to the repos (probably testing). There is a small list of stuff I have been wanting to package or update for Bodhi so I will try to get to it this weekend.




#106785 Midori browser

Posted by ylee on 28 September 2017 - 03:17 PM

It is worth noting that Archlinux reports that "Midori compiles with the current webkitgtk package (3.0)." I haven't investigated how Ubuntu packages Midori nor any alleged insecurities of WebKit1. I may play around and research these issues this weekend.
...

 
Ubuntu clearly packages midori to use libwebkitgtk-1.0-0.
 
However with only one minor difficulty I was able to compile it use libwebkitgtk-3.0-0.

Spoiler

 
I am not certain it is worth my effort to try to re-package midori to use the new webkit libraries. For me it was just a proof of concept: to show that it was possible.
 
However from my limited research online I have gathered that using  libwebkitgtk-3.0-0 with midori is experimental and it may introduce more issues and bugs with midori. Just saying ...
 
I feel most users replace midori with a 'more reasonable and familiar' browser. If there is much user support for the idea of repackaging midori to utilize  libwebkitgtk-3.0-0 I may consider trying to repackage it. If i ever do so it would be added to bodhis testing repo.




#106777 Midori browser

Posted by ylee on 27 September 2017 - 09:48 AM

...
I've also removed Midori since according to https://bugs.debian.....cgi?bug=864951
it uses unmaintained WebKit1 instead of webkit2gtk

sudo apt-get remove --purge midori

It is worth noting that Archlinux reports that "Midori compiles with the current webkitgtk package (3.0)." I haven't investigated how Ubuntu packages Midori nor any alleged insecurities of WebKit1. I may play around and research these issues this weekend.

 

It is also worth noting all web browsers have insecurities and bugs. For the record a few years ago I tried PaleMoon but at the time I found it far more unstable on my system than Firefox. Your experience may be diffferent and perhaps these stability issues have been addressed. Good Luck.




#106772 Midori browser

Posted by ylee on 25 September 2017 - 09:30 PM

Just noticed that the last version of Midori is from May 2016.
That's some time ago, does it mean the project is no longer alive as suggested by Wikipedia?

 

I didn't see anything suggesting Midori is no longer alive on Wikipedia. But then again I just got off work and I skimmed it.

 

But regardless the latest commit I can find in the development branch is dated 2017-09-04. There hasn't been alot of commits lately but I would say the project is alive and well. It probably is a small project with only a few active developers. Midori's role in Bodhi is simple to provide a usable web browser until the user installs whatever web browser he or she wants. Some may stick with Midori but probably most will install better known web browsers with more features such as Firefox, Chrome, Opera ...




#106764 Forum search issues

Posted by ylee on 24 September 2017 - 01:59 PM

I use Google site search to find old post of mine. That is if the post info is not in my notes, really important stuff to me I have in my notes along with a link to the forum post. Notes are in Markdown in my Dropbox so I can grep them and access them regardless of what machine I am on.




#106727 Window Scale Feature

Posted by ylee on 20 September 2017 - 09:14 PM

You need to elaborate on this Surprise, it works with Moksha installed on LXLE, but not if I install it in my Bodhi 4.0 install. 

How does it work in LXLE or in Moksha installed on LXLE, how does one call it?

 

On Bodhi 4.0 How did you install it? For me on Bodhi 4.0 and installed from skippy-xd-daily PPA it works if started in a terminal via:

 

skippy-xd --start-daemon &

Altho it throws out some error messages as I use it. And I can then launch the window picker via:

 

skippy-xd --activate-window-picker
Does this not work for you?



#106701 Screen remains dark after blanking

Posted by ylee on 16 September 2017 - 08:34 PM

If you have more than one computer I would attempt to debug this issue by sshing into the computer that has frozen up from another machine and trying to see what is going on and/or killing processes that are highly suspect trouble makers: such as Chrome. You should in theory be able to ssh into the frozen machine. If you can ssh into the frozen machine note that you can also force it to reboot or shutdown without powering down. 

 

Note: on both machines you need openssh-server installed to do this:

sudo apt-get install openssh-server

If you are willing to try this, do you know or are able to figure out how to ssh into another machine? Remember search engines are your friends  ;)

 

Also note that to truly debug this issue using ssh requires familiarity and some comfort level with CLI and some knowledge of Linux and linux commands.




#106695 Excessive CPU useage by menu_cached process

Posted by ylee on 15 September 2017 - 10:23 PM

Looks to be fixed here! Not only does it fix the cpu issue - but the applications menu entry is functional for the first time ever.

 

I made sure the Applications menu would also be fixed. It was a related but separate issue, took another commit or so on Andriys part. Me just sending an gdb backtrace illustrating the issue.

 

But anyway I beleive this issue is fixed and we can move on to other projects, issues, and or bugs.  B)




#106684 Excessive CPU useage by menu_cached process

Posted by ylee on 15 September 2017 - 09:27 AM

I have added the hopeful last set of potential fixes from upstream into the repo. Please let us know if this fixes the menu-cache issue reported here. It should in theory and it does for me locally on my test machines.

 

Just run your system updates as normal to install them. Or if you would prefer not to update your entire system the below should suffice:
 
 

sudo apt-get update
sudo apt-get install libmenu-cache3 libmenu-cache-bin

  
 If these  packages cause any additional issues NOT related to the menu-cache issue please open a new support thread. Thanks for your time and patience.
 

I think I speak for more than myself on this but, Thanks ylee for all your time and effort in keeping Bodhi Linux one of the best distro's around!

 
Thanks Randy :D But really no need to thanks me. It is all in days work or in this case almost a weeks work. And really the true thanks goes to Andriy who had an interest and motivation to fix an LXDE library which worked fine in LXDE to accommodate changes in EFL and who quickly knew how to modify the menu-cache code based up the errors showing up in my debugging sessions. It would have taken me days if not weeks to get to that level of competency  with that code base. 

 

 

Regardless I have always contributed back to Open-source as long as I have been using it. This predates my usage of Bodhi. It is just I am really visible here and Bodhi members of course notice.




#106665 Excessive CPU useage by menu_cached process

Posted by ylee on 13 September 2017 - 10:33 PM

I am tentatively proclaiming that with his latest commits Andriy (LStranger) has fixed this issue. Menu-cache is now patched to address the issue we were having using pcmanfm and this library and efl 1.19.1. I have not tested any latter versions of EFL(or enlightenment) but do not anticipate any issues. Give it a few days for the LXDE-dev PPA to add the new deb files and either Jeff or I can put them in Bodhis repo.

 

Thanks all for the patience all have shown in this issue.




#106661 Excessive CPU useage by menu_cached process

Posted by ylee on 13 September 2017 - 07:55 PM

Using Open with in PCManFM and giving a custom command still shows 1 core at 100 %, so no progress.


Ahh looks like the update they are referencing isn't in their PPA yet. Should rebuild some time soon. Will post when there is another update.

 
He is still working on it Charles and Jeff, we have made progress tho. With his latest git commits Menu-cache is not at 100% anymore, nor is it after an e restart. (with efl 1.19.1, haven't been testing on latter versions of efl -- I am hoping for the best regarding latter versions)
 
It still has one outstanding issue and that is: The Application functionality of pcmanfm if it is enabled in pcmanfm settings doesn't function unless pcmanfm is started in a terminal :unsure:   (enlightenment/EFL desktops only, works fine in LXDE).  I have been doing the debugging and Andriy doing the patching of menu-cache so it is a little slow going. All thru e-mail and all as time and our work schedules permit. 
 
@Jeff that LXDE-dev PPA you are using is about one day behind the git commits. So I would anticipate maybe two or more days before this is fully fixed and the fix in said PPA.  And that is assuming my last e-mail has enough information for Andriy to fully and correctly deal with the Application issue pcmanfm is now having. That is assuming the fix to come doesn't cause further issues or we don't discover further issues.
 
The last few relevant responses from Andriy:

You wrote to me:
[.......]

>.xsession-errors when it doesn't work:
>(pcmanfm:1129): Menu-Cache-CRITICAL **: fail to re-connect to the server.

This is pretty much bad. I suppose it's related to accept() errors handling
which was changed. If that's the case then you'll see menu-cached restarts
often. I would appreciate it if you could gather strace from menu-cached,
please, that should shed a light on what happens, maybe another case have
to be added besides (errno == ECONNABORTED) as a valid failure condition.
Thank you in advance!

    With best regards,
    Andriy.

 
 I sent a huge strace file at this point clearly showing, I was hoping anyway,  the Application malfunction of pcmanfm.
 

Hi again!

Nevermind my last letter, I've found everything in your strace. Working
on it. Thank you very much.

    With best regards,
    Andriy.

This is one of things I absolutely love about Open-source, Developers are so accessible and almost always very helpful. That is if you ask the right way and provide the right information and are willing and able to help in the process :)




#106652 Excessive CPU useage by menu_cached process

Posted by ylee on 13 September 2017 - 01:26 AM

Been in communication with LStranger (Andrej N. Gritsenko) an LXDE developer and we have some progress in debugging this issue. Still not completely solved but it is looking good. I will let you know more as it develops.




#106648 Excessive CPU useage by menu_cached process

Posted by ylee on 12 September 2017 - 07:08 PM

I was so optimistic when I read this:
 

I've put some new libmenucache packages in the main repo that may or may not fix the issue. Please upgrade and see. Testing here as well.

 
But alas it doesn't work :(

 

For the record those new menu-cache deb files appear to come from the lubuntu-dev PPA.
 
I had already tried menu-cache from git but that was before the last two commits. Both commits seemed related to issues we have been having, and I have found yet another related issue. Menu-caches behavior when moksha/enlightenment is restarted. That brings up what I said earlier:
 

...
However If I go back to the previous commit and compile efl at commit elput: Fix resource leak then both pcmanfm as well as the menu-cache menu item work as expected. In other words some latter commit is the one breaking the menu-cache menu item. That one I haven't tried git bisect on. (That process took most of yesterday for me to go thru due to the length of time for efl to compile).
...

 

 

I was wrong here, menu-cache/pcmanfm work fine at the commit  elput: Fix resource leak until  moksha/enlightenment is restarted :( In my git bisecting I was not testing what happens after an e restart. It didn't occur to me that the behavior would be different. It was something I noticed latter playing with various promising efl packages. I have efl 1.19.1 patched deb files that work fine UNTIL I restart moksha. Then the same issue manifest itself again.

 

So essentially I am back to doing more git bisecting as with efl 1.18.4 it all works fine even after an e-restart :(

 

Thanks for your efforts, ylee. I hope that you and those close to you will be OK during and after the weather event.
 
In the meantime, I persist with my own innovative solution described earlier :rolleyes:

 
Thanks craigus, all is well here. I just had some high winds and lots of rain. Spent the day cleaning up tree branches and debris from my yard.




#106635 Excessive CPU useage by menu_cached process

Posted by ylee on 11 September 2017 - 02:28 PM

...

But it works on the lubuntu desktop
 
I have a lubuntu 16.04 virtual machine I use  for testing purposes, compiling code and so on. On this VM I have several DEs installed, and snapshots with moksha and several versison of e compiled. Using LXDE on this VM , pcmanfm works fine with no menu-cache issue at all. Logging out and logging into Moksha or enlightenment any version and we have the menu-cache issue with pcmanfm. I am unsure why the command /usr/lib/menu-cache/menu-cached works if called in a terminal but seemingly doesn't work (hangs as above) if called by a gui-process like pcmanfm in enlightenment. 
 
I am unsure why so I can't say for sure this is an issue with the LXDE library or another weirdness with enlightenment. I have not attempted to debug it and am reluctant to do so.
 

 

 

I am in the midst of a hurricane here but despite my reluctance to debug this issue I am a little OCD and have made some limited progress. 

 

Using git bisect I have identified the specific git commit which seems responsible. The efl commit efl_net_socket_fd: initialize fds to INVALID_SOCKET is the one that breaks pcmanfm functionality resulting in this menu-cache issue observed here. If I take efl 1.19.1 and undo this patch then pcmanfm works as expected. 

 

But all is evidently not completely well because if I insert the menu-cached command in a desktop file and place in Bodhi's menu as either:

Exec=/usr/lib/menu-cache/menu-cached

or

Exec=/usr/lib/menu-cache/menu-cached /tmp/.menu-cached-:0-USER

where in the latter USER is the users name in Bodhi, then we still have the menu-cache issue when this menu item is started unless we add

Terminal=true

to the desktop command. In other words the menu-cached command only works when started from a terminal :(

 

However If I go back to the previous commit and compile efl at commit elput: Fix resource leak then both pcmanfm as well as the menu-cache menu item work as expected. In other words some latter commit is the one breaking the menu-cache menu item. That one I haven't tried git bisect on. (That process took most of yesterday for me to go thru due to the length of time for efl to compile). [EDIT: I am wrong here see my comment latter.]

 

Even tho efl certainly seems to cause this issue I do not know enough about the underlying code base, the efl socket stuff and the menu-cache code, to say for sure this issue is caused by efl doing something 'wrong' or whether it is an issue with menu-cache.

 

When I know more such as what commit is causing the menu-cache item when started from Bodhi's menu, I will report this issue to the e-devs and if i feel it is a problem with the way the menu-cache library is coded then I will also report  this issue to the LXDE devs. And as soon as I have a seemingly completely working efl 1.19.1 I will place the updated deb files in Bodhi's testing repo. In all likelihood I will do this before the e-devs officially patch this issue. When and if there is an 'official' e-dev solution I will either back port their changes to efl 1.19.1 and or build deb files for the latest version of efl.




#106562 Excessive CPU useage by menu_cached process

Posted by ylee on 04 September 2017 - 09:58 PM

I have more closely examined this issue and I can now reliably duplicate it. And have a number of observations and a semi-functional hack to address this issue.
 
First a few clarifications:
 

...

Not sure this is a Bodhi problem. It happens in PCManFM and that in turn uses an LXDE version for menu-cache. And lubuntu seems to have the same issue though some say there is a working patch, I did not find it.


The patch you couldn't find was committed: Merge pull request #12 from mtasaka/localwork
 

Yeah, I had read that topic about issue#7. That solution should have been integrated in the packages we have in Bodhi, but it was not.
 
...


Downloading the source code used to make ubuntu's deb files, this patch is present in version 1.0.2-1. So it is present on Bodhi's version of this library. Regardless I compiled the git version of this library on Bodhi and using it the issue remains, it also remains if I update pcmanfm and the libfm stuff to the latest versions. 

 

But it works on the lubuntu desktop
 
I have a lubuntu 16.04 virtual machine I use  for testing purposes, compiling code and so on. On this VM I have several DEs installed, and snapshots with moksha and several versison of e compiled. Using LXDE on this VM , pcmanfm works fine with no menu-cache issue at all. Logging out and logging into Moksha or enlightenment any version and we have the menu-cache issue with pcmanfm. I am unsure why the command /usr/lib/menu-cache/menu-cached works if called in a terminal but seemingly doesn't work (hangs as above) if called by a gui-process like pcmanfm in enlightenment. 
 
I am unsure why so I can't say for sure this is an issue with the LXDE library or another weirdness with enlightenment. I have not attempted to debug it and am reluctant to do so.
 

 

My ugly kludge fix at the moment is to run /usr/bin/killall menu-cached from the root crontab every 5 minutes :wacko:


:lol:  :lol:  :lol:  :lol:

 

That is indeed rather ugly ....

 

Not that my attempt to 'fix'  is much better but here goes:

 

Download my file, mc_hack.sh make it executable and run it as a regular user in a terminal.  Do not run it as root!! 

 

This script downloads a desktop file from my drop box and installs it. Read it if you understand stuff like that. Also note earlier today I was having issues with dropboxs server timing out so I am hoping that is no longer the case. 

 

It adds a 'program' to Bodhis menu, menu-cache and adds this program to both startup and restart apps in mokshas settings. (it also should work on any version of enlightenment >= 17)

 

In my testing it usually worked but failed sometimes. In this case you may have to kill menu-cached and then rerun the menu-cache program from the menu. In cases where it fails it probably failed because i started pcmanfm 'too soon' after booting or in I clicked on "Applications" in pcmanfms left panel FIRST. It is best to not do either.

 

This is not a proper fix but I am hoping it will suffice for those facing this issue until we can address this issue. If this issue is unresolved Bodhi may have to move away from using pcmanfm as a file manager and move to another fm.  That would be regrettable but linux offers plenty of file managers. 

 

Use at your own risk!!