<mighty17[m]>
tmlind: i dunno what you are doing but i still get `(phoc:1795): phoc-wlroots-CRITICAL **: 18:02:19.436: [GLES2] OpenGLES 2.0 API generated error code 0x500(GL_INVALID_ENUM)` with yout kerne;
<mighty17[m]>
kernel*
<mighty17[m]>
could you tell what cmds you have used for wlroots?
_inky has joined #maemo-leste
<freemangordon>
Wizzup: seems auto-refresh does not work
<freemangordon>
will look at it
Danct12 has joined #maemo-leste
<freemangordon>
Wizzup: maybe set "update via" to "any connection"
<Wizzup>
did that, let's see
uvos has quit [Quit: Konversation terminated!]
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #maemo-leste
DPA- has joined #maemo-leste
DPA has quit [Ping timeout: 252 seconds]
<freemangordon>
Wizzup: but, you have to have connection, in VM I had to connect "dummy network" so auto-refresh to start
<Wizzup>
freemangordon: I am on wifi
<freemangordon>
keep in mind modest use libalarm for auto-refresh
<freemangordon>
and it sets the alarm ALARM_EVENT_CONNECTED flag
<freemangordon>
there is a nice explanation in modest_platform_set_update_interval
DPA- has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
DPA has joined #maemo-leste
<Wizzup>
I think it auto updates now
<Wizzup>
so probably the 'any'
<freemangordon>
lemme check how it identifies wifi
<Wizzup>
can anyone try this /etc/hosts
<Wizzup>
95.217.97.175 leste.maemo.org
<Wizzup>
95.217.97.175 phoenix.maemo.org
<Wizzup>
try https or so
<freemangordon>
sec
<Wizzup>
we switched dns
<Wizzup>
it'll take some time to propagate
<parazyd>
Propagated here
<freemangordon>
looks like it works
<Wizzup>
sweet
<Wizzup>
wireguard tunneled from finland to my home
<Wizzup>
*shrug*
<freemangordon>
Wizzup: modest uses conic to check the connection type
<Wizzup>
builds should work again too
<Wizzup>
freemangordon: ok, that -should- work
<freemangordon>
mhm
<freemangordon>
it checks for CON_IC_BEARER_WLAN_INFRA or CON_IC_BEARER_WLAN_ADHOC
<freemangordon>
this should be fine, so I wonder why it does not auto-update for you
<Wizzup>
WLAN_INFRA should be there yeah
<Wizzup>
freemangordon: it is now, on any
<Wizzup>
I can change ity back and see
<Wizzup>
btw, did you see the one bug I found?
<freemangordon>
which one?
<Wizzup>
I cannot type port numbers in the account settings
<Wizzup>
I had to copy-paste it from terminal
<Wizzup>
this is on d4, though
* freemangordon
checks
<freemangordon>
which port exactly?
<Wizzup>
I can't type any port in imap or smtp port
<Wizzup>
where it would say 25, 465, etc
<bencoh>
Wizzup: it might be similar to how numbers work in the phone app
<Wizzup>
yes, there are special entries in gtk
<Wizzup>
but that would mean that that is broken on the d4 keyboard in general :p
<freemangordon>
Wizzup: seems like a bug in HIM
<bencoh>
you can't type using the Sym keys in those fields
<Wizzup>
freemangordon: ok, for later then
<Wizzup>
I expected as much
<freemangordon>
it has "numbers" button pressed, but the keyboard draw is alpha
<bencoh>
Wizzup: have you tried with the qwertyuiop?
<Wizzup>
bencoh: it should not work, we made a xkb map for it
<Wizzup>
but I can try
<freemangordon>
if you press 'numbers' buttons twice in virtual kbd it should be fine
<Wizzup>
bencoh: no key works
<freemangordon>
hmm, typing numbers from HW kbd works
<Wizzup>
yeah
<Wizzup>
if I do this it works:
<Wizzup>
[OK] number
<Wizzup>
OK is the sym key on the d4 I think
<Wizzup>
in any case, I have some other migration to do, bbiab
<freemangordon>
ok
drrty has joined #maemo-leste
<bencoh>
freemangordon: wait, why twice?
<Wizzup>
sticky I guess
<Wizzup>
(but twice doesn't work for me)
<bencoh>
vkbd has sticky behavior?
<Wizzup>
I wasn't using vkbd
<bencoh>
right, but fmg mentioned vkbd
newbie has joined #maemo-leste
newbie has quit [Client Quit]
uvos has joined #maemo-leste
<uvos>
what input field are we talking here?
<uvos>
freemangordon
<uvos>
is there somewhere in current leste i can repoduce
DPA has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
mardy has quit [Ping timeout: 252 seconds]
DPA- has joined #maemo-leste
mardy has joined #maemo-leste
<freemangordon>
uvos: try to change port in modest account
<kona>
freemangordon: modest-providers still needed?
<kona>
i liked it before, but it seemed like claws and or sylpheed and or trojita kinda had that space mostly covered.
<kona>
but no, this is much better.
<bencoh>
:)
<freemangordon>
:nod:
<Wizzup>
yeah modest does still need gnupg and stuff but that's for later
<Wizzup>
this is already neat
<freemangordon>
I guess it will need oauth too
<freemangordon>
BTW, we'll have to find oauth2 lib to use when it comes to it
<Wizzup>
I have never used oauth for email
* Wizzup
bbiab
<Wizzup>
for me, I want to finish icd stuff, then do news post, then back to audio, the ofono/icd
<Wizzup>
s/the ofono/then ofono/
<freemangordon>
sure
<freemangordon>
and I am back to abook, modest still lacks contacts
DPA- has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
DPA has joined #maemo-leste
<freemangordon>
and now the number of emails in tklock gets updated too :)
<freemangordon>
seems there is a bug in hildon-desktop tasknav, I can close the notification, but I cannot activate it
<tmlind>
mighty17[m]: wlroots around 0.14 changed to use WAYLAND_DISPLAY=wayland-1 instead of 0, maybe that's causing it
<mighty17[m]>
ah right, that may be it
<mighty17[m]>
tmlind: can the link the commit?
<uvos>
should not be a problem
<uvos>
just change the envvar
<uvos>
why do you want a commit
<mighty17[m]>
ah right, i'll try that
<uvos>
but that should not cause your error anyhow
<uvos>
your error is while starting the wayland comp.
<uvos>
the envvar dosent matter if the comp hasent started
<mighty17[m]>
mhm, fair point
<mighty17[m]>
but we still cannot find the reason why comp fails to start
<kona>
Wizzup: freemangordon: have you been able to send a mail with modest?
<Wizzup>
yes
<kona>
ok, so probably pebkac then
<kona>
out of curiousity, did you use the amd64 build or the arm build?
<kona>
(armhf? aarch64?)
<Wizzup>
armhf
<Wizzup>
I can try it again later today
<Wizzup>
what problems are you seeing
<kona>
i'll try it on my 900.
<kona>
so far, what i see is a pretty immediate failure on send in modest, and no connection logs on my postfix server
<kona>
receiving from dovecot seems to work great, haven't tried any imap folder ops yet
<Wizzup>
what does it say?
<kona>
"Unable to send" is the current error.
<Wizzup>
is the smtp setup correct?
<Wizzup>
the ssl vs tls can be confusing
<Wizzup>
tls I think often means starttls, whereas ssl means ssl and tls
<kona>
hmm.
<kona>
ok, so i need starttls
<uvos>
starttls is probubly a bad idea
<uvos>
btw
<kona>
and for secure auth, it should be LOGIN, i guess.
<uvos>
(just a side note)
<kona>
yeah, starttls is not great but i need to reconfigure my postfix i think.
<Wizzup>
uvos: freemangordon: I see the notification of the email in the lock screen and also it vibrated ;-)
<Wizzup>
uvos: what is wrong with starttls, jw
<uvos>
and adversity can just make it fail
<uvos>
*an
<Wizzup>
uvos: yeah, but not hijack
<uvos>
and then you have unencrypted email
<Wizzup>
uh
<Wizzup>
I don't think most implementations allow not going for tls
<uvos>
yeah depends on server config
<kona>
some clients will fallback silently to unencrypted
<Wizzup>
ok, never heard of that happening
<Wizzup>
thx for explaining
<kona>
trojita had a couple of cve's about this IIRC
<Wizzup>
I look forward to the moment when we have to worry about those things over features :p
<Wizzup>
(well, we worry about that stuff too now, but less so.)
<kona>
or over basic screen drawing on the pine64 :)
<uvos>
the real soulution is the server just not accepting unencypted sessions after starttls fails
<uvos>
but unless you run your own server
<uvos>
i would not rely on that
<kona>
^^^
<uvos>
so just use ssl/tls
<freemangordon>
kona: amd64 and yes, I am able to send using gmail
<mighty17[m]>
uugh, i found out whats the issue, so i have 2 wlroots packages, one normal and one patched, and somehow it always uses the normal one unless i build same version of patched
<mighty17[m]>
tmlind: could you get the patches upstreamed?
<mighty17[m]>
i cannot remove normal wlroots as phosh depends on it
<freemangordon>
hmm, unable to click on notification is not hildon-desktop issue
<freemangordon>
it correctly sends fake ButtonPress event to hildon-home
<freemangordon>
but, for some reason gtk does not call button_press_event GtkWidgetClass member
<tmlind>
mighty17[m]: there are few issues remaining before upstreaming the wlroots can be considered, mostly the wlroots folks do not want workarounds in their tree but want issues to be fixed in mesa instead
<tmlind>
mighty17[m]: uninstall also phosh and build it yourself too
<mighty17[m]>
tmlind: i dont want to wake up all night compiling phosh lmao
<mighty17[m]>
tmlind: fixes in mesa? lmao there is no pwr in mesa, why would they accept patches for it
<tmlind>
mighty17[m]: well even if it never gets upstreamed, there's no point implementing workarounds in wlroots for things that mesa can handle
<Wizzup>
agreed
<tmlind>
you know stanard stuff
<tmlind>
standard
<tmlind>
so for example, from what i understand, the graphics folks want to only use the /dev/dri render node(s) and not tinker with the master interface
<tmlind>
currently the pvr blobs freak out if wlroots tries to allocate using the render nodes
<tmlind>
so the patch i did for wlroots to go back to opening the master node is wrong based on what i chatted with the wlroots folks
<mighty17[m]>
so well we carry patches then?
<mighty17[m]>
and build on cortex a9s?
<tmlind>
yeah no other option really right now
<mighty17[m]>
:(
<tmlind>
if the whole pvr was open source, it would be a different story naturally
<tmlind>
but nobody wants to carry closed source binary blob workarounds in their trees
<Wizzup>
freemangordon: ah, so modest doesn't auto update all folders right? (that's a good thing for me)
<tmlind>
PVR:(Error): PVRDRIPlaneCreate: Failed to create share/scanout/cursor buffer [0, ]
<tmlind>
PVR:(Error): PVRDRIBufferCreate: Failed to create plane [0, ]
<tmlind>
CreateImageShared: Failed to create buffer
<freemangordon>
hmm, it seems upstream gdk 2.0 ignores ButtonPress event if there is no EnterNotify for the same window before that
<uvos>
that makes sense
<Wizzup>
I don't think it should
<Wizzup>
wonder what the rationale for that is
<uvos>
avoid directed synthetic events
<freemangordon>
why?
<freemangordon>
how helpful is that?
<uvos>
its a security mesure
<freemangordon>
yeah, right
<uvos>
you avoid another application sending the app input without it being visable
<uvos>
otherwise the other applicaiton could open the victom app
<uvos>
and move it to -1000 -1000
<uvos>
and interact with it
<uvos>
without the user seing it
<freemangordon>
so, what stops the other application to send EnterNotify first?
<uvos>
i dont think you can
<freemangordon>
hmm, why?
<uvos>
you cant send all events some are reserved for the server
<uvos>
idk if this is one tho
<uvos>
if not yeah idk
<uvos>
unless it also needs to get focus in
<uvos>
then it makes sense again
<uvos>
since the user would notice the focus change i assume
<freemangordon>
e.xcrossing.focus = False;
<Wizzup>
applications can make cursors
<Wizzup>
and focus them that way
<uvos>
not when gtk2 was written no
<uvos>
anyhow where is this a problem?
<Wizzup>
clicking the notification doesn't work
<Wizzup>
since the press event does not fire in the window expose
<uvos>
what notification?
<Wizzup>
in this case, modest
<uvos>
the notification window
<uvos>
?
<Wizzup>
yes, the one that is on top of the window
<uvos>
why would the notification window not get enternotify when you touch it?
<freemangordon>
because it is actually drawn by tasknav
<freemangordon>
and it sends syntetic ButtonPress event
<uvos>
ugh ok
<uvos>
kludgy
<freemangordon>
uvos: hildon-home creates a fully transparent window for the prurpose of IPC
<freemangordon>
and passes its xid to hildon-desktop
<freemangordon>
so when user clicks on the notification, tis xid gets ButtoPress event
<freemangordon>
now I will teach hildon-desktop to send EnterNotify, but this is plain stupd
<freemangordon>
I mean - gtk behaviour
<uvos>
and what xwindow dose the synthetic event get sent to?
<uvos>
the notification should really just own its own window the abvoe solution sounds like a bad kludge. or even better just use the xdg notification interface for when its clicked
<freemangordon>
you need to have a look at the code to get it
<freemangordon>
the "notification" is drawn by tasknav
<uvos>
right
<freemangordon>
it is an clutter actor in h-d
<uvos>
and then you get xevents for interaction
<freemangordon>
the real notification is created by hildon-home process
<freemangordon>
so h-d have to inform h-h that notification was clicked
<freemangordon>
anyway
<uvos>
thats a kludge, no if and ors about it if h-d wants to render the notficiation it needs to use the xdg notification interaction interface that was created for this very purpose
<uvos>
instead of hacking around with synthetic x events
<uvos>
but ok
<uvos>
also note that modern toolkits (and i think unpached gtk2 too) discard synthetic events immidatly
<uvos>
(wich is why xtest exists)
<freemangordon>
ok, sending synthetic EnterNotify makes it work again
<sicelo>
mighty17[m]: you don't need 'normal' wlroots when using phosh. at least i didn't need it back when i tried it on droid 4. patched wlroots = normal wlroots from phosh's point of view, unless you installed in a strange way
<Wizzup>
freemangordon: cool
<Wizzup>
I will take the vm at home just for a bit, for a kernel update, once the hildon-desktop build is done
<freemangordon>
please gimme a minute to upgrade all the packages first in my VM befor you do that
<freemangordon>
*before
<Wizzup>
sure, np
<freemangordon>
I will let you know when I am ready
<Wizzup>
actually the vm does not host packages
<freemangordon>
ah, ok then
<Wizzup>
that's maedevu
<freemangordon>
right
<freemangordon>
just let h-d build finish then
<Wizzup>
yup
<freemangordon>
Wizzup: done
DPA has quit [Ping timeout: 252 seconds]
DPA has joined #maemo-leste
<freemangordon>
now it looks like a real thing :D
<freemangordon>
bencoh: feel free to upgrade and retest whatever notifications were failing for you
<sicelo>
apparently libcamera people are interested in supporting/working on the N900's camera