zaivala@zaivala-ThinkPad-T430:~$ grub-customizer
localuser:root being added to access control list
==== AUTHENTICATING FOR net.launchpad.danielrichter2007.pkexec.grub-customizer ===
Authentication is required to run Grub Customizer
Authenticating as: Moss Bliss,,, (zaivala)
Password:
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Errorrg.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.
localuser:root being removed from access control list
zaivala@zaivala-ThinkPad-T430:~$


Sorry, but I only have one login password, and it worked when I was doing updates...

I tried running it from the menu, and the screen just blanks and goes back to the desktop.

See my post https://www.linuxquestions.org/quest...3/#post5950954

1 members found this post helpful.

I don't see how this applies, but I will give it a try soon. Bodhi has been around since 2011 now, you'd think these issues would have been dealt with by now.

I don't know what that did, but it did what I needed it to. Grub Customizer now works right, and I assume other things do as well.

I don't remember that issue in 2011. That issue appeared after our Ubuntu base started using policykit. And it is only an issue with certain apps and how they implement their usage of pkexec. Honestly this issue is not a big priority for me, multiple ways of fixing it and all rather easy to implement. 'Easy' is subjective tho. Bodhi is developed for free, our donations to bodhi support our website servers and stuff. It is worth remembering our developers are volunteers. If this is a big deal to you Patches are accepted.

Probably in time I will get around to fixing it. Patience a virtue

Glad it worked. And yes other apps using policykit now should work as expected.

1 members found this post helpful.

I don't know what issues I've had to deal with in the past. Sufice it to say that this is the first time in at least a few tries over the years where I actually got Bodhi to run.

FYI my hardware is a Lenovo T430. I have the 500 Gb hard drive partitioned in quarters, with a different distro on each, and I do tend to distro hop although my main driver is Linux Mint (currently 19.1 Tessa) with MATE desktop.

I've been a fan of Enlightenment E17 since it was used in MacPup. Nobody seems to have picked up that ball and run with it except you... and as stated, I have not previously gotten to actually USE Bodhi. Thanks for the help which got me off the ground.

I'm not much of a developer or anything. I just try distros and report back when something doesn't work. I don't always get responses back, and rarely get HELPFUL responses. I've had 2 or 3 isues this time, and they have each been addressed effectively.

I see you are in SC. I'm in eastern TN and pass through SC and sometimes Atlanta from time to time. If there is anything I can do to help, let me know.

1 members found this post helpful.

Well reporting issues and problems does help us. Sometimes issues are not noticed by us until someone reports them Of course some issues reported are 'user error' and some are well known to us, but regardless we do appreciate issues being reported. As to help on the forums we do try and I am glad all your issues so far have been addressed effectively.

As to anything you can do to help, donations are always appreciated. You can donate to Bodhi, that helps keep our servers online. Altho our donations are usually so small that is about all it does. So considering that and all the time I spend on Bodhi development and packaging I have decided to start adding a donate button or section to the code I personally write or maintain on my github page, see for example this example.

If donations aren't your thing just spread the word, like us on facebook or post info about bodhi or reviews or whatnot. I am trying to promote our distro a bit more.

2 members found this post helpful.

not exactly true.
there's quite a few distros that offer the enlightenment DE in their repos, some probably even with a separate pre-configured install image.
and there's at least two more that specialize in enlightenment: Sparky and ELive.
https://distrowatch.com/search.php?d...=Enlightenment

i tried elive before i settled on bodhi. that was before i knew anything about enlightenment. i was just searching for something lightweight and functional. lots of eye candy (i prefer minimalism) and definitely lightweight. i tried to install it recently after their newest (3.0) release on my 32-bit machine and it just wouldn't write correctly.

@ondoho

Actually it is true, read it closely. they said E17. Sparky has e22. And if ya look EFl 1.20.7, Now I admittedly have been curious about sparky for some time esp their enlightenment ISOs. Maybe I am not looking hard enough but I can't even find an e22 sparky ISO now. Doesn't matter now because it is not e17.

Now admittedly Elive 3.0 is a very polished looking distro, with some very creative ideas in what they do with e17. I am unsure of exactly what version of e17 this is. I think more in terms of commits in the enlightenment git, what commit is Elive's e17 version at? But more to the point the version of EFL on Elive 3.0 is efl 1.13.3.(current version is 1.21.1) This is old as the hills, so in all likelihood so is the e17 version. As is the Kernel for that matter, 3.16.0-0.bpo.4-686-pae. As Elive is build on Debian wheezy 7.11 all the software is rather dated. Note Debian Wheezy is supported until the end of May 2018. What year is this? So while it is true Elive maintains and updates some packages users of elive are going to be using old software and even if you compile from source you are going to run into issues using such old libraries. Most EFL apps will not compile on it and updating EFL would certainly kill its e17 version. for these reasons it certainly can't be said Elive has picked up the e17 ball and ran with it. Pretty and polished as it is.

It should be noted that the very last release of e17 and the very last commit in the e17 branch of enlightenment will not compile with any recent EFL versions. When Bodhi forked e17 and called our fork moksha at around the end of 2014 we had to fix it to compile with whatever version of EFl we were using at the time.

Now for the record Bodhi has EFl 1.20.7 in our main repo and the 64 bit version of efl 1.21.1 in our testing repo. I would prefer efl 1.21.1 in our next release for several reason, the main one being I know about a memory leak in eina in efl 1.20.7. Discovered it in an app I have been working on when I ran it thru valgrind. Evidently the e-devs knew about it also as it doesn't happen in efl 1.21.1. But efl 1.21.1 kills our systray functionality for reasons as yet unclear to me. I hope to get a grip on that and fix our systray to work with efl 1.21.1.

So while it is true a number of distros have e17 in their repo, have they made any improvements? Will their version even compile with EFL 1.20 or efl 1.21? Have they taken the ball and ran? Perhaps i am wrong but I know of none that have.

Now it is true that Bodhi does not use a pure e17 we have stripped some things out. Even some things I liked and used ... the official story is we removed stuff that didn't work well for all users.

But it is certainly true we have taken the e17 ball and ran with it. I myself backported probably over a hundred e22 commits to Moksha for our last release. A number of them addressed stability memory leaks and so on. This is not to mention a hundred or more earlier such commits, nor the issues fixed or code changes that were not inspired by the e-devs and their work on e22. Doing all this I learned a number of things such as how to make e17 segfault, freeze up and all kinds of such stuff. This stuff I have fixed in Moksha.

So all these distros with e17 in their repos, has this stuff been fixed? hmmm Bet ya I can use a keyboard and mouse and not run any custom code but just click on stuff in the GUI and make their version segfault.

To me at least and I may be biased It is certain fair to say Bodhi has taken the e17 ball and ran with it. And I know of no other distro that can make such a claim.

2 members found this post helpful.

nice Robert!


re: zaivala's quote - I don't see how this applies, but I will give it a try soon. Bodhi has been around since 2011 now, you'd think these issues would have been dealt with by now.


this was broken in a recent update/upgrade. seems to have various manifestations of issues. so this has not been around for a long time...

OK, if it's specifically about 0.17, bodhi it is!
tbh the last time i had a closer look at enlightenment (and bodhi) it must have been at 0.18 or 0.19 and i hadn't even realised bodhi are going a different way.

i was amazed at how lightweight a fully compositing (and fully eye candy) environment can be when done properly. eat this, gnome!
but somehow actually using it never really clicked for me.

may i ask why the fork, and why stick with 0.17? what's especially good about it?
isn't maintaining it (moksha), plus the distro, a huge task?

2 members found this post helpful.

OK everything below which is too much info is all my personal opinion. I do not speak for Bodhi or Jeff here.

When Jeff first decide to create and release Bodhi originally his philosophy was to use cutting edge enlightenment. By that he meant both e and efl. And by cutting edge he meant recent in terms of what version it was, what commit it was at in the subversion history. The e-devs used subversion then moving to git latter.

Ok I started using bodhi shortly after that because someone gave me a netbook they thought was broken. It wasn't broken it just had windows issues. I was already a linux user and tried multiple OSes on it, Bodhi worked like a champ on it (and still does still have the netbook). Back then e and efl updates became something to be weary of things would break and stop working, enlightenment would segfault and so on. Plus with many e and more or less all EFL updates we had to fix our themes. And occasionally some e updates broke our modules and while they all came from the e-devs, the developers themselves were in no rush to fix them.

I could live with that that kinda stuff was not a big deal to me. I could help debug and test things and became very quickly 'a big fish in a small pond' as you might say. But as more and more people started using Bodhi that was not what they wanted out of a distro. They wanted to install it and update it and do whatever it is they do with a computer and not have to deal with segfaults and stuff that used to work no longer working.

Back then we tried to work with the e-devs in getting issues fixed that were important to us, file bug reports on stuff our users experienced and e-mail on the e-devel mailing list and talking with the e-devs in IRC and so on. But things that were important to the Bodhi community didn't seem important to the e-devs, in all honesty. Now the e-devs have their own priorities and if ya read their mailing list you will figure out what they are, so they have there reasons for not rushing to fix our issues.

So in time Jeff became more and more reluctant to push the newest e or efl changes to our repos, we would test them more and longer and wait if needed for something more stable.

Well e17 got more and more stable, stable to where the common happened all the time segfaults, happened less and less until eventually they almost never happend with everyday usage and the right version of efl installed. E is tightly connected to the version of EFl around at the time it is being developed.

Now instead of finishing polishing e17 and continuing the development of EFL the e-devs got this heroic idea of refactoring large chunks of enlightenment, and ya had e18, e19, ... to e22. As well as removing all support for disabling compositing. And in fact this refactoring of e is still going on. Specifically they were replacing the native e-widgets code with elm code from efl. From a programming stand point that makes perfect sense, it is almost duplicated libraries they are using and in replacing e stuff with elm stuff ya can go from needing two themes an e theme and an elm theme to just one theme an Elm theme. Also some more new things were introduced and not fully implemented at that. This is still the case with the new gadget API and gadget box or whatever they call it.

Now note that many of our users needed to disable compositing. The native e code for compositing for example never did work on my netbook, nor still does it. Ecomorph however did work for what that is worth. One of Bodhi's claim to fame is it works well on old hardware, with compositing disabled that would no longer be the case At least for some hardware.

All this was occuring at the same time as a major refactoring in EFL going on, this one was replacing parts of efl code with code based on the new eo stuff. Eo for enlightenment object. Again this makes perfect sense in terms of the programming, but it was and still is a stability issue. It should be noted that many changes in EFL are, IMHO, inspired by Samsung which uses EFL in some of their electronic gadgetry. And in all honesty Samsung doesn't care about the enlightenment desktop. Ensuring efl changes work with enlightenment or other EFL apps is an afterthought.

So with the e-devs moving on to e18 and e17 more or less stable Bodhi forked e17 because development on it ceased. And e18 was unstable to unstable for normal users trying to do normal things on their OS. Eventually it became officially announced by the e-devs that e17 was no longer supported:

Perhaps Bodhi should have taken the ball and taken over development of e17 instead of forking it. Perhaps but in addition to forking Jeff removed parts of e that some of our users had issues with. The e-devs would not have let that happen IMHO. Perhaps that code could have been fixed? Maybe and maybe it is fixed in e22 now I don't know, aside from compositing not working on my netbook I never personally experienced issues with the removed code. But some of our users did, they posted on our old forums and I have no reason to not believe them.

So in addition to forking e17 we also forked the modules we use as well as created a couple more modules and backported the pulseaudio module from a latter version of e.

Now bear in my the decision to fork e17 was Jeffs idea. He did talk to me and prob a few others about it. But he made that call, not me.

So what is especially good about e17? Stability and not having to redo our themes and modules all the time and it works great on older machines or machines with limited resources. No latter version of e currently has the stability and no latter version of e will ever work as well on old hardware. Sad but true.

Isn't maintaining it (moksha), plus the distro, a huge task?

Yes it is. We truthfully need help. Wanna help

4 members found this post helpful.

Good explanation Robert.

Moreover, I can remember that time when Bodhi switched to release 3 with e19. Very unstable, slow and buggy. What I hate the most was the systray issue. I mean, the xembed protocol was replaced with another one (appindicator? - sorry I do not rememeber) and many apps like Skype, Parcellite, Goldendict etc simply dissapeared from the systray on the shelf. I think this was an another reason why to stay with E17.

We are polishing the Moksha desktop. Some features are not in E22 and they are in Moksha. For example the fulldisk indicator (under Places module), screenshot delay time and many many more. E17 is a good platform for developer because we have still the same solid base under the hood. But yes, EFL is changing and sometimes causes headache. Astroboy could say some words about this. Bodhi Linux 4 release came with buggy EFL 1.18.4 which seqfaulted or freezed the desktop. He (Astroboy) uses the BL as a base for his educational project in Mexico on thousands PCs in the school. Now let's imagine how bad the situation could be. https://escuelaslinux.sourceforge.io/

And yes, I agree with Robert. We need more devs for maintaining this distro

Will you help?

3 members found this post helpful.

Well yep neglected to mention the systray changes, let's just say changes in e were not what we wanted at the time. At least on the systray more and more apps adapted to the systray changes as appindicator became more dominant, so that one is less of an issue now.

Anyways there is prob even more I forgot to mention, the fork was years ago and several releases ago. Let's just say at the time Jeff made a rather convincing case that we should not follow e into the line of e18, e19, ...

Now of course e is also moving towards wayland as is many other things. I am unsure how we will adapt to that or whether we will stick with X11 for as long as it works. And then at some point EFL will stop supporting what they call legacy apps. It should be noted here that e17, I am fairly certain, is one such legacy app. Already with efl 1.21.1 I am having to replace some efl function calls as they have been depreciated

Always change, always more to learn and always bugs. Not good for an aging brick mason ...

2 members found this post helpful.