<freemangordon>
yes, and I asked why it is gone on which parazyd replied that openrc has default stop() so this is redundant. I only hope the default one does what removed stop() does
<Wizzup>
what is removed is not what the default stop does afaik, but I don't know for sure
<freemangordon>
if default does something else, then we shall restore the removed stop(), I did it like that on purpose back then and I see no reasoning in the commit that removed it.
<freemangordon>
parazyd: ^^^ any comment?
<parazyd>
All good
<freemangordon>
you're fine with restoring the removed stop()?
tvall has quit [Quit: Bridge terminating on SIGTERM]
asriel_dreemurr has quit [Quit: Bridge terminating on SIGTERM]
scops has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
Guest2850 has quit [Quit: Bridge terminating on SIGTERM]
tvall has joined #maemo-leste
scops has joined #maemo-leste
mighty17[m] has joined #maemo-leste
ajr has joined #maemo-leste
asriel_dreemurr has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
freemangordon: https://github.com/maemo-leste/hildon-desktop/pull/13 is obsolte per say, but please do something along the same lines by rerunging some tool on the code base and then closing the pr. (since h-d is sutch a mess code formating wise)
<uvos>
freemangordon: https://github.com/maemo-leste/hildon-desktop/pull/7: mce currently provides this via the old interface, but its bad imo. mce has to implement an interface that just mirrors the iio-sensor-proxy one under a different dbus name to provide a sensor interface just for this (and mce provides no other external interface to other sensors anywhere makeing this module a really odd duckling). The way this causes the rotation
<uvos>
policy to be split currently is bad too. i consider the interface mce provides to be deprecated and would request slowly moving stuff to use iio-sensor-proxy directly, which provides equivalent dbus interfaces. mce currently warns when the if is used. However this pr is just a proof of concept and would require some more error checking and sutch to be really in a mergable state.
<uvos>
sidenote lifeguard should check for a gid not a uid to assign permissions
<uvos>
really a group name but a gid would be less offensive allready
vectis has quit [Ping timeout: 248 seconds]
vectis has joined #maemo-leste
vectis has quit [Ping timeout: 245 seconds]
<freemangordon>
uvos: why gid and not uid? you have one and only one interactive user under maemo
<freemangordon>
lets not discuss if it is good or bad
<inky_>
i have compiled megapixels (camera app for pinephone) under maemo
<inky_>
and it sort of works.
<inky_>
but you know it doesn't work well under manjaro as well.
<inky_>
so i guess that's the best we can have now.
<Wizzup>
is it pinephone specific?
<inky_>
may be with devel kernel it'll be better.
<inky_>
yes can you imagine that?
<inky_>
the only camera for pinephone today is pinephone specific.
<inky_>
because underlying layers don't support pinephone hardware well.
<inky_>
i got already photos made with it. very close to what you get under manjaro. some low saturation shots.
<inky_>
it actually creates several dng files with each shot.
<inky_>
and then converts to tiff with dcraw.
<inky_>
the redraw is very slow. but i remember it was also slow under manjaro
<inky_>
may be not as slow
<inky_>
and pinephone under maemo has this problem - sometimes the part with controls of the camera app disappears and shows the controls of terminal app, if it is running.
<inky_>
then you press it it comes back.
<inky_>
such redraw issues are common on pinephone + maemo, but absent on pinephone + something else.
<inky_>
it is not really really useful now, but it is not really really really useful on other distros as well.
<inky_>
so i don't know if i should try to package it.
<inky_>
may be it just bit worse on maemo.
<inky_>
also when the screen blanks, i cannot bring it back. i can only kill the app via ssh.
<Wizzup>
might still make sense to package it somewhere if you made any changes
<Wizzup>
yes, 3d problems on the pinephone are frequent with the lima driver
<inky_>
do we use other driver than others?
<Wizzup>
we use X11+glamor
<inky_>
they use wayland, and it has a better driver?
<Wizzup>
others use wayland
<Wizzup>
yes, basically
<inky_>
is the work being done to improve x11 somewhere? or we are the only ones interested?
<inky_>
is it in mesa?
<inky_>
i have some problems on pinebook pro and they say it is in mesa, not the kernel driver.
<inky_>
i don't really understand what is glamor. i understand we have userspace drivers in xorg that talk to kernel drivers.
<inky_>
let's say nouveau in xorg talks to nouveau in kernel.
<inky_>
and mesa has the opengl implementation for each hardware.
<Wizzup>
I think people work on it, but they don't work on the specific problems we have. It's either in mesa or glamor, which uses mesa
<Wizzup>
could be partially kernel driver too
<inky_>
i think i'll package it. yes, in order to build it, i had to change its ninja.build a bit. and at runtime it demands ~/Pictures, may be I should add its creation to the source code? don't know.
<inky_>
and report issues to the author.
<Wizzup>
does it really require that and not some XDG var?
<Wizzup>
should be XDG_PICTURES_DIR
<inky_>
it creates /tmp/megapixels.randomstring and stores dng files there.
<inky_>
then it tries to copy them, and in console i see the debug output of command 'cp' that tries to copy photos to ~/Pictures and failes.
<freemangordon>
uvos: sorry, I don;t understand how gid/uid is related to this PR
<freemangordon>
could you please elaborate?
<uvos>
freemangordon: "uvos: why gid and not uid? you have one and only one interactive user under maemo" no i cant, and its a perfectly valid reason, we need to get away from this "only one user" thing with hardcoded user name and id if we ever intend to integrate with other distros (the main impediment being that this makes it impossible for hildon to be a regular session) or even sutch niceties as having your own user name on deivce for
<uvos>
ssh etc.
<uvos>
there is no technical reason to replace the hardcoded uid's and user names with groups as we encounter them.
<uvos>
*there is no technical reason to NOT replace the hardcoded uid's and user names with groups as we encounter them.
<freemangordon>
uvos: but, is this related to the PR in question?
<uvos>
no its a side note: this needs improvement
<freemangordon>
ah, ok
<freemangordon>
but, if we strictly discuss the PR as such, do you have comments/notes on it? Shall I improve/fix anything?
<uvos>
i only skimmed it so far, i can read it in ditail later if you like
<uvos>
it looks fine at first glance at least
<Wizzup>
I think it's pretty fine
<freemangordon>
yes, I would prefer more eyes to look through code changes done in such a critical component
<freemangordon>
Wizzup: I think it is pretty fine too, but lets have uvos look at it as well
<freemangordon>
:)
<Wizzup>
sure
sunshavi_ has joined #maemo-leste
sunshavi has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
BenLand100 is now known as Treebeard
Treebeard is now known as BenLand100
BenLand100 is now known as Treebeard
Treebeard is now known as BenLand100
mardy has quit [Quit: WeeChat 2.8]
Pali has joined #maemo-leste
jrayhawk_ is now known as jrayhawk
<kona>
weechat is workable on pinephone
<kona>
uvos: i tried trojita with x11 vkbd, got it configured but then i never see the password prompt. i'll check the issue list and log a new issue if necessary?
<uvos>
trojita only promts for a pw when 1. you dident specify the pw in settings 2. the conection to the server was sucessfull 3. an operation that requires the pw is initiated
<uvos>
kona: are you sure that all of these are true? if the server is missconifgured you wont ever see the promt for instance
<uvos>
kona: maybe try trojita on a linux desktop if you can and see if it works there
<kona>
es, was trying to not save password :)
<uvos>
kona: if it dosent on desktop, reporting upstream makes the most sense i think, as my changes to it are very minimal and only relate to the ui.
<kona>
server logs seem to say yes but auth hangs.
<uvos>
kona: deleating the pw on my device makes it prompt fine here
<kona>
cool, maybe this is more pinephone oddity
<uvos>
very unlikely
<uvos>
it might not render the prompt due to mesa issues but hildon should at least show you that it got a new window
<uvos>
ofc i assume you are starting trojita via its .dekstop file