kona | Sweet, USB kb works on my pinephone | 00:12 |
---|---|---|
kona | For some reason I thought that wasn't working yet for Maemo Leste | 00:13 |
Wizzup | kona: :) | 01:05 |
Wizzup | freemangordon: shouldn't this be NULL? https://github.com/maemo-leste/dsme/commit/d866deb122101cffec00620947843fea1396568f#diff-4ef413819eba6cc91cb6f776025a84426e68ae2d4c965fa0a1a0f7275f4f37d8R360 | 01:10 |
kona | also, i may have ordered an n900. | 01:14 |
Wizzup | kona: cool | 01:15 |
Wizzup | it's not ideal as dev env, but it's a good (and supported) device | 01:15 |
kona | hopefully i can score a pinephone kb when they put them up for order/preorder too :) | 01:16 |
kona | I have my vm for dev, or I saw that we have images for pi[123] and i have a couple of those in my parts crate | 01:17 |
enyc | kona: do you know about making sure the micro-usb is firmly soldered down and not to get ripped off board, such a common problem ;-( | 01:18 |
kona | currently trying to understand tny-vfs-stream.[ch] so I can port it from gnomevfs to gvfs. | 01:19 |
kona | enyc, for the n900? i think i heard something about this. | 01:19 |
enyc | kona: yes | 01:19 |
enyc | well known issue, most common ''failure'' of them imho | 01:20 |
kona | yeah, i think i (just barely) have the necessary "lack of skill" to reattach that. | 01:20 |
Wizzup | kona: something you can also do is look for commits where we ported from gvfs to gio | 01:20 |
kona | and solder wick to clean up my mess. :) | 01:20 |
kona | would that probably be better? it seems like gio is an abstraction layer above gvfs, so maybe? | 01:21 |
Wizzup | gio replaces gvfs afaik | 01:23 |
Wizzup | https://github.com/maemo-leste/osso-pdf-viewer/commit/610b9012f95de2bcc90ebaa3176dfabf1ba300d8 | 01:23 |
Wizzup | https://github.com/maemo-leste/libcomapp/commit/ada20f434909f8bf2cb28dc0f3234e136e734006 | 01:23 |
Wizzup | some random one, not from us https://github.com/maemo-leste/evolution-data-server/commit/2622a74884ff4670d3ec6ba003293649efeaf631 | 01:23 |
Wizzup | not sure if it's helpful | 01:23 |
Wizzup | https://github.com/maemo-leste/hildon-application-manager/pull/1 | 01:24 |
kona | Wizzup, those links are helpful, thanks! | 03:21 |
freemangordon | Wizzup: tho others are inited with 0, see https://github.com/maemo-leste/dsme/commit/d866deb122101cffec00620947843fea1396568f#diff-4ef413819eba6cc91cb6f776025a84426e68ae2d4c965fa0a1a0f7275f4f37d8R355 | 07:36 |
freemangordon | *the others | 07:36 |
freemangordon | I am just following the style | 07:36 |
freemangordon | Wizzup: anything else? | 07:59 |
freemangordon | (I got a power outage here, might have missed something in the logs) | 07:59 |
freemangordon | parazyd: is this https://github.com/maemo-leste/dsme/commit/ae0a385af685249cc878e7666450790169d270b2 released? | 09:24 |
parazyd | It should be | 09:32 |
freemangordon | this is a mess :( | 09:33 |
freemangordon | no changelog, eh? | 09:33 |
freemangordon | also, seems somehow stop() is missing from the init script, I still didn;t find why | 09:34 |
freemangordon | why is https://github.com/maemo-leste/dsme/commit/9b49e8047a73a38d40258b5692b11843accdb915#diff-d89e0e8d06d3ced1f6f4f4c0710a4d71f2d2b123da2c54a3e952a31358399b2cL36 removed? | 09:35 |
freemangordon | any idea? | 09:35 |
freemangordon | parazyd: ^^^ | 09:35 |
parazyd | OpenRC has a default stop() function | 09:38 |
parazyd | So that's redundant | 09:38 |
freemangordon | ok | 09:38 |
parazyd | What's a mess? | 09:40 |
freemangordon | no changelog for the release | 09:40 |
freemangordon | so you can;t really tell if a commit is included or not | 09:41 |
freemangordon | also, tag is on previous commit | 09:41 |
freemangordon | see https://github.com/maemo-leste/dsme/releases/tag/0.61.7 | 09:41 |
parazyd | Yeah we don't usually make tags when stuff in debian/ is changed. | 09:41 |
freemangordon | hmm, I was under the impression we are tagging debian/changelog change commit | 09:42 |
freemangordon | because basically this is what makes a relese, no? | 09:43 |
freemangordon | hmm, wait | 09:43 |
freemangordon | the tag is on debian/changelog commit, which is right | 09:43 |
parazyd | Well the way I see it, the HEAD of beowulf-devel branch should be released in devel | 09:44 |
freemangordon | and then there is one more commit | 09:44 |
parazyd | The HEAD of beowulf branch should be released in stable | 09:44 |
parazyd | And development should happen on master | 09:44 |
freemangordon | ok, but IIRC you release the latest tag, no? | 09:44 |
freemangordon | or I forgot how that all was supposed to work | 09:44 |
parazyd | Yes, but tags serve to tag the source code itself, unrelated to the debian directory. | 09:45 |
freemangordon | hmm | 09:45 |
freemangordon | kinda makes sense, though sounds weird to me | 09:45 |
freemangordon | but ok, I'll keep it in mind | 09:46 |
parazyd | https://leste.maemo.org/Development/Building_Packages#The_git_tag | 09:46 |
parazyd | See N.B here | 09:46 |
freemangordon | any objections if I tag debian/changelog commit? | 09:46 |
parazyd | It's fine if you do | 09:46 |
freemangordon | ok | 09:46 |
freemangordon | parazyd: wait, this is a mess :D | 09:47 |
freemangordon | you say that changelog version is used to checkout the tag to build, right? | 09:47 |
parazyd | Yes, but the debian directory is always taken from the branch's HEAD | 09:48 |
freemangordon | but in dsme tag 0.61.7 is *before* commit ae0a385af685249cc878e7666450790169d270b2 | 09:48 |
freemangordon | so, how is this commit included? | 09:48 |
freemangordon | ae0a385af685249cc878e7666450790169d270b2 I mean | 09:48 |
parazyd | Because that's inside debian/ | 09:48 |
freemangordon | oh, sorry | 09:48 |
parazyd | So as I wrote already, it gets picked up | 09:48 |
freemangordon | yeah, init script is in debian | 09:49 |
parazyd | mhm | 09:49 |
freemangordon | hmm, doesn;t sound clean to me | 09:49 |
parazyd | It is also possible to maintain them outside | 09:49 |
parazyd | uvos does this in one or two packages | 09:49 |
freemangordon | init script is not part of debian packaging | 09:49 |
freemangordon | but ok, now it is clear what happened | 09:49 |
freemangordon | thanks! | 09:50 |
parazyd | You're welcome | 09:50 |
lel | freemangordon opened a pull request: https://github.com/maemo-leste/dsme/pull/5 (Graceful exit) | 09:50 |
lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/hildon-desktop/pull/14 (add support for rotating xinput touchscreens when entering or leaving portrait mode) | 11:16 |
lel | freemangordon closed a pull request: https://github.com/maemo-leste/hildon-desktop/pull/14 (add support for rotating xinput touchscreens when entering or leaving portrait mode) | 11:34 |
Wizzup | freemangordon: we do not have stop in dsme because we don't want to ever restart it at runtime afaik | 11:35 |
Wizzup | freemangordon: so stop should be a stub | 11:35 |
freemangordon | ok | 11:36 |
freemangordon | Wizzup: please review dsme pr when you have some spare time | 11:36 |
Wizzup | ok | 11:36 |
freemangordon | BTW, are those PRs still valid https://github.com/maemo-leste/hildon-desktop/pulls ? | 11:38 |
Wizzup | parazyd: freemangordon: I think we don't want openrc to be able to stop dsme | 11:46 |
parazyd | I agree | 11:47 |
parazyd | Stopping dsme, even on shutdown, could lead to weird behaviour | 11:47 |
Wizzup | hm, wait, I think it does maybe need to do that on shutdown, that's a good point.. | 11:47 |
parazyd | You need to make sure it's the last in line somehow | 11:47 |
Wizzup | well, maybe we don't worry about that now | 11:48 |
bencoh | don't we have dependencies for that? | 11:48 |
Wizzup | it seems to 'work' | 11:48 |
Wizzup | let's just fix the srv restart problem first | 11:48 |
parazyd | bencoh: not really split for start/stop | 11:48 |
bencoh | ? | 11:48 |
parazyd | You have dependencies in general, but I'm not sure you can set dependencies for the stop() function | 11:49 |
bencoh | ah | 11:49 |
parazyd | So from the top of my head, I can't see how one would make dsme be the last initscript to stop | 11:50 |
parazyd | Well, not _last_ last, but after everything Maemo | 11:50 |
bencoh | Required-Stop sounds like what we would want though (dunno how it translates to with openrc) | 11:50 |
bencoh | (dunno if it works either to be honest) | 11:51 |
Wizzup | in any case this is not actually a practical/current problem | 11:53 |
Wizzup | dsme does watchdog handoff now I think, so we don't have the resets anymore | 11:53 |
Wizzup | (when it exits) | 11:53 |
freemangordon | Wizzup: this is already fixed | 11:59 |
freemangordon | https://github.com/maemo-leste/dsme/commit/2d4db8f5e14bc0f131ee5402915188b01968f8e0 | 12:00 |
freemangordon | that's why we should have stop() that does nothing | 12:00 |
freemangordon | IIUC | 12:00 |
Wizzup | ah, ok, yeah | 12:05 |
Wizzup | I thought the commit you linked showed it as removed | 12:05 |
Wizzup | https://github.com/maemo-leste/dsme/blob/master/debian/dsme-thermal.init I don't see a stop() stub here | 12:05 |
Wizzup | oh that's thermal | 12:06 |
Wizzup | freemangordon: whatever https://github.com/maemo-leste/dsme/commit/2d4db8f5e14bc0f131ee5402915188b01968f8e0 did before, it's gone now in master | 12:06 |
Wizzup | oh, ne | 12:06 |
Wizzup | ok | 12:06 |
Wizzup | I just need to wake up | 12:07 |
Wizzup | the stop() stub is gone though | 12:07 |
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 | 12:15 |
Wizzup | what is removed is not what the default stop does afaik, but I don't know for sure | 12:16 |
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. | 12:18 |
freemangordon | parazyd: ^^^ any comment? | 12:19 |
parazyd | All good | 12:19 |
freemangordon | you're fine with restoring the removed stop()? | 12:19 |
freemangordon | ok, I'll update the PR | 12:20 |
parazyd | Yeah I'd say it's fine | 12:21 |
lel | freemangordon synchronize a pull request: https://github.com/maemo-leste/dsme/pull/5 (Graceful exit) | 12:27 |
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) | 14:59 |
uvos | freemangordon: https://github.com/maemo-leste/hildon-desktop/pull/10 works fine for me and i find it usefull, if its something you want is up to you | 15:00 |
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 | 15:05 |
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. | 15:05 |
uvos | sidenote lifeguard should check for a gid not a uid to assign permissions | 15:21 |
uvos | really a group name but a gid would be less offensive allready | 15:22 |
freemangordon | uvos: why gid and not uid? you have one and only one interactive user under maemo | 16:03 |
freemangordon | lets not discuss if it is good or bad | 16:04 |
freemangordon | (only one user) | 16:04 |
freemangordon | uvos: are yuo going to review https://github.com/maemo-leste/dsme/pull/5 ? | 16:19 |
freemangordon | *you | 16:19 |
inky_ | so, people | 16:25 |
inky_ | i have compiled megapixels (camera app for pinephone) under maemo | 16:25 |
inky_ | and it sort of works. | 16:25 |
inky_ | but you know it doesn't work well under manjaro as well. | 16:25 |
inky_ | so i guess that's the best we can have now. | 16:26 |
Wizzup | is it pinephone specific? | 16:26 |
inky_ | may be with devel kernel it'll be better. | 16:26 |
inky_ | yes can you imagine that? | 16:26 |
inky_ | the only camera for pinephone today is pinephone specific. | 16:26 |
inky_ | because underlying layers don't support pinephone hardware well. | 16:26 |
inky_ | i got already photos made with it. very close to what you get under manjaro. some low saturation shots. | 16:27 |
inky_ | it actually creates several dng files with each shot. | 16:27 |
inky_ | and then converts to tiff with dcraw. | 16:27 |
inky_ | the redraw is very slow. but i remember it was also slow under manjaro | 16:27 |
inky_ | may be not as slow | 16:28 |
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. | 16:28 |
inky_ | then you press it it comes back. | 16:28 |
inky_ | such redraw issues are common on pinephone + maemo, but absent on pinephone + something else. | 16:29 |
inky_ | it is not really really useful now, but it is not really really really useful on other distros as well. | 16:29 |
inky_ | so i don't know if i should try to package it. | 16:29 |
inky_ | may be it just bit worse on maemo. | 16:30 |
inky_ | also when the screen blanks, i cannot bring it back. i can only kill the app via ssh. | 16:30 |
Wizzup | might still make sense to package it somewhere if you made any changes | 16:30 |
Wizzup | yes, 3d problems on the pinephone are frequent with the lima driver | 16:31 |
inky_ | do we use other driver than others? | 16:32 |
Wizzup | we use X11+glamor | 16:32 |
inky_ | they use wayland, and it has a better driver? | 16:32 |
Wizzup | others use wayland | 16:32 |
Wizzup | yes, basically | 16:32 |
inky_ | is the work being done to improve x11 somewhere? or we are the only ones interested? | 16:33 |
inky_ | is it in mesa? | 16:33 |
inky_ | i have some problems on pinebook pro and they say it is in mesa, not the kernel driver. | 16:33 |
inky_ | i don't really understand what is glamor. i understand we have userspace drivers in xorg that talk to kernel drivers. | 16:34 |
inky_ | let's say nouveau in xorg talks to nouveau in kernel. | 16:34 |
inky_ | and mesa has the opengl implementation for each hardware. | 16:34 |
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 | 16:35 |
Wizzup | could be partially kernel driver too | 16:35 |
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. | 16:35 |
inky_ | and report issues to the author. | 16:35 |
Wizzup | does it really require that and not some XDG var? | 16:35 |
Wizzup | should be XDG_PICTURES_DIR | 16:36 |
inky_ | it creates /tmp/megapixels.randomstring and stores dng files there. | 16:36 |
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. | 16:36 |
inky_ | once I created the directory, it works. | 16:36 |
tmlind | sicelo, uvos: fyi pushed out wlroots changes so far to https://github.com/tmlind/wlroots/commits/pvr-gles2, at least weston-simple-egl issue remains caused by commit 4e07d4cbf9c1 | 16:36 |
inky_ | let me try with exporting XDG_PICTURES_DIR | 16:36 |
inky_ | i confirm, it doesn't care about XDG_PICTURES_DIR | 16:43 |
inky_ | i run it with this environment, and it tries to save to ~/Pictures. If Pictures doesn't exist, it fails to cp to it. | 16:43 |
uvos | freemangordon: "uvos: are yuo going to review https://github.com/maemo-leste/dsme/pull/5 ?me but a gid would be less offensive allready" if you like | 17:23 |
freemangordon | uvos: sorry, I don;t understand how gid/uid is related to this PR | 17:24 |
freemangordon | could you please elaborate? | 17:25 |
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 | 17:26 |
uvos | ssh etc. | 17:26 |
uvos | there is no technical reason to replace the hardcoded uid's and user names with groups as we encounter them. | 17:26 |
uvos | *there is no technical reason to NOT replace the hardcoded uid's and user names with groups as we encounter them. | 17:27 |
freemangordon | uvos: but, is this related to the PR in question? | 17:27 |
uvos | no its a side note: this needs improvement | 17:27 |
freemangordon | ah, ok | 17:27 |
freemangordon | but, if we strictly discuss the PR as such, do you have comments/notes on it? Shall I improve/fix anything? | 17:28 |
uvos | i only skimmed it so far, i can read it in ditail later if you like | 17:28 |
uvos | it looks fine at first glance at least | 17:29 |
Wizzup | I think it's pretty fine | 17:29 |
freemangordon | yes, I would prefer more eyes to look through code changes done in such a critical component | 17:29 |
freemangordon | Wizzup: I think it is pretty fine too, but lets have uvos look at it as well | 17:30 |
freemangordon | :) | 17:30 |
Wizzup | sure | 17:30 |
kona | weechat is workable on pinephone | 19:42 |
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? | 19:48 |
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 | 19:53 |
uvos | kona: are you sure that all of these are true? if the server is missconifgured you wont ever see the promt for instance | 19:54 |
uvos | kona: maybe try trojita on a linux desktop if you can and see if it works there | 19:54 |
kona | es, was trying to not save password :) | 19:54 |
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. | 19:55 |
kona | server logs seem to say yes but auth hangs. | 19:55 |
uvos | kona: deleating the pw on my device makes it prompt fine here | 19:56 |
kona | cool, maybe this is more pinephone oddity | 19:56 |
uvos | very unlikely | 19:56 |
uvos | it might not render the prompt due to mesa issues but hildon should at least show you that it got a new window | 19:57 |
uvos | ofc i assume you are starting trojita via its .dekstop file | 19:58 |
uvos | not via xterm via different env | 19:58 |
kona | via .desktop, yes. | 19:59 |
uvos | try menu->view->debugging->showprotocol log | 20:00 |
uvos | and see if it even gets to the pw prompt with the server | 20:00 |
uvos | (restart after activating that) | 20:00 |
kona | last message: connCheckingcertificates (SSL) | 20:09 |
kona | so i will sniff the packets, sorry for buggin :) | 20:10 |
uvos | if it stays like that then thats wierd and a bug it should timeout and tell you your sever is missconfigured | 20:12 |
uvos | but i would direct the bug upstream | 20:12 |
kona | k | 20:16 |
lel | freemangordon closed a pull request: https://github.com/maemo-leste/dsme/pull/5 (Graceful exit) | 22:36 |
sicelo | tmlind: thanks @wlroots! haven't had time to play with this stuff lately, but intend to pick it up again, soon | 23:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!