[e-users] E 0.23.1-5 (deb) systemd upgrade

Mon Apr 27 23:45:27 BST 2020

On Mon, 27 Apr 2020 12:40:43 -0700 Marc MERLIN <marc_e17 at merlins.org> said:

> (dear debian E maintainers, see below for getting a newer fixed E build
> to fix non working systray)
> 
> On Mon, Apr 27, 2020 at 08:52:30AM +0200, Pierre Couderc wrote:
> > Using apt::recommend turned off in debian is necessary if you do not want
> > exotic packages installed on your system, BUT it implies to carefully list
> > recommended packages before each install and decide if you need them or
> > not...
> 
> You are correct, and thanks for the reminder :)
> 
> On Mon, Apr 27, 2020 at 09:01:50AM +0100, Carsten Haitzler wrote:
> > i noticed many people seem to ignore recommended things... so that's why e
> > got
> 
> now you know why :)

:)

> > it's own nag dialog at runtime... it's smarter than the packages as it
> > actually looks to see if your hardware does acpi. e.g. your raspberry pi
> > will not, thus
> 
> that was a good call, thanks for that. In my case I somehow
> misunderstood that systemd took over acpid, so I didn't try to install
> it. Obviously I was wrong.

it indeed has not. :) thus why that dialog is there. if it had taken over the
dialog would not be there as we also detect systemd at runtime and enable those
code paths at runtime if it's found... :)

> > > Apparently I had both a systray gadget and a shelf systray, fixed it.
> > > I'm not sure if I've fully gotten the gadget thing, especially as they
> > > might be buggy in my E version (or I'm holding it wrong)
> > 
> > try e from git that will be 0.24 in t he coming few weeks.
>  
> So, as discussed earler, and sorry for saying this, I really really try
> not to have lots of packages installed from source putting lots of files
> on my system, that are untracked or may even conflict with installed

luckily.. they can all by defsult go in /usr local so they won't conflict and
are easy to find. you could do --prefix=/opt/e and remove them all in one rm
-rf /opt/e :)

so it's very very very easy to be clean :)

> packages and dpkg dependencies. I've been there, and got burned too many
> times. In the case of e, it's not just the binary, but a *lot* of stuff:
> libecore-con1 (>= 1.20.7-0~eo), libecore-evas1 (>= 1.20.7-0~eo),
> libecore-file1 (>= 1.20.7-0~eo), libecore-imf1 (>= 1.20.7-0~eo),
> libecore-input1 (>= 1.20.7-0~eo), libecore-ipc1 (>= 1.20.7-0~eo),
> libecore-x1 (>= 1.20.7-0~eo), libecore1 (>= 1.20.7-0~eo), libedje1 (>=
> 1.20.7-0~eo), libeet1 (>= 1.20.7-0~eo), libeeze1 (>= 1.20.7-0~eo),
> libefreet-bin, libefreet1a (>= 1.20.7-0~eo), libeina1a (>= 1.20.7-0~eo),
> libeio1 (>= 1.20.7-0~eo), libelementary1 (>= 1.20.7-0~eo), libemotion1
> (>= 1.20.7-0~eo), libethumb-client-bin, libethumb-client1 (>=
> 1.20.7-0~eo), libevas1 (>= 1.20.7-0~eo), enlightenment-data (= 0.21.11-1)

but these all come from 2 builds. debian makes it look like a looooot of
things. if you just stuff things in a single prefix... easy to nuke.

did you know that if you have the build tree still you can do:

  sudo ninja uninstall

and it'll.. surprise surprise... uninstall and delete files it installed? :)

> But maybe none of these are required to be updated, and only E needs to
> be? 
> Either way, if the current debian packages has showstopper unfixed bugs
> in systray, as in you cannot see the network-manager applet at all, I'd
> rather wait for an updated debian package with a fixed build.

current e needs a current efl. thus it's waiting for the 1.24 release to be
done which will be any day now. just remove libeina and it'll remove all things
that depend  on it - then compile and do the usual to ensure PATH,
LD_LIBRARY_PATH, ld.so.conf etc etc. are correct to find wherever you put efl +
e. :)

> > > I don't, but I believe you something is broken on my thinkpad setup in
> > > that it causes this. That would explain what I'm seeing. I'll spend some
> > > time to see why.
> > 
> > it smells like it - try xev to see what your events are. i have a bt
> > logitech mouse where there is a scroll wheel... but you can't press it to
> > middle-button press. there is another button next to it that is middle
> > button. as this is a trackpad, all bets are off as things like click/button
> > and wheel events are emulated by firmware on the trackpad... thus config of
> > it matters.
>  
> I just plugged a mouse in the laptop instead of using the built in
> thinkmouse, and I can alt+middle click resize, so there is a problem
> there, I'll debug further and post when I find a solution.

awesome. at least you know where to look now :)

> > > It works in xfe and cinnamon and the source laptop I copied ~/.e from.
> > > I checked that if I move the button to the top/bottom of the window, I can
> > > resize from the top/bottom. From the left/right or corners, it doesn't
> > > work.
> > 
> > what app is this? is this some gnome/gtk3 app with client-side decoration?
>  
> it was gnome-terminal. I just found that the corner to resize is not the
> corner of the window but the corner left of the scrollbar. Now, I can
> resize by hovering over it.

oh wait... this will be gnome terminal doing its own client-side decorations,
won't it? it has a different titlebar of its own etc. ... that doesn't look
like it comes from e? right? if so that means this window is actually handled
by gnome. it draws the border and titlebar an the shadow too and handles events
for moving and resize etc. ..

> > > ok, I missed that.
> > > So systray in E 23 is broke and won't get fixed, but it'll work in 0.24.
> > 
> > well i hope it will work better for you - it does not do xmbed. so don't
> > expect those to work. you won't know unless you try. last i knew nm-applet
> > needs to be patched or specially compiled with specific options to support
> > indicator/status notifier dbus protocol.
>  
> Ok, thanks for confirming. It's disappointing that after 3.5 years (last
> we had this talk), nm-applet, or wicd-gtk, or bluez all still only work
> with x-embed, but since that's supported in gnome, cinamon, and xfce, I
> guess no one cares except E users :-/

not supported in kde anymore i understand... so not just e. not sure why you
need both nm and wicd... but if you did you connmaninstead of nm you would need
none of those applets. :)

> > e has full bluez5 support built in - in 0.23. you dont need to run extra
> > processes to have that work. it even supports fun things like enabling
> > paired bt devices to auto lock/unlock your system if around or not.
> 
> noted, thanks.
> 
> > and wtf? chrome now is trying to become a "always running in background
> > process".... ouch. there goes the neighbourhood (or RAM) :)
> 
> That's been there for a while. chrome is a mini-OS that can run chrome
> apps in the background, from talk to other whatever you want to run on
> top of it (I used it as a print server to convert cups into google
> print). Of course, you can just kill it and then it's dead/gone.

chrome - the new emacs. :)

> > they still do xmbed. kde moved from xmbed years ago. gnome kept supporting
> > it.
> 
> I see, so network manager doesn't with KDE and KDE had to write its own?

i don't know what happened there. maybe they have their own nm applet front
end? i don't know...

> > it was horribly broken in most apps anyway. in fact even indicator protocol
> > support is broken in apps. if the status notifer dbus service goes away then
> > comes back - apps don't re-appear in it without re-running them,. this is
> > an app problem 100%. they never test loss of service + recovery. so
> > restarting e
> (...)
> 
> Right, I hear you that it's broken, but until people really stop using
> it, I guess I'm back to using stalonetray for now. From what you said,
> it sounds that even E 24 won't work with nn-applet anyway.

both are broken in this scenario. i''m just pointing out that app devs are
pretty bad at doing the right thing here and handling these cases which they
very often just do not. for xmbed i found maybe 60-70% didn't do it right so
you lost icons on e restart. i haven't looked closely at notifier/indicator
protocol but i have seen the vanish and not come back until i re-run the app...
and not just one of them. history repeats with this all happening again. :( i'd
minimise my reliance on these things due to this trend... :) i rarely see or
need an indicator icon... :(

> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
>  
> Home page: http://marc.merlins.org/                       | PGP
> 7F55D5F27AAF9D08
> 

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com