| Wizzup | fwiw rafael said he'll be back on monday | 00:00 |
|---|---|---|
| uvos | Wizzup: how do you make g_debug() messages show up | 00:18 |
| uvos | Wizzup: i forget this every time | 00:18 |
| Wizzup | G_MESSAGES_DEBUG=all I think | 00:18 |
| uvos | dosent appear to work for hildon-status-menu | 00:18 |
| Wizzup | we should add it to https://leste.maemo.org/Debugging | 00:18 |
| Wizzup | uvos: that is because it detaches I think | 00:18 |
| Wizzup | do you run it with maemo-summoner? | 00:18 |
| uvos | no | 00:18 |
| Wizzup | how do you run it? | 00:19 |
| uvos | hildon-status-menu | 00:19 |
| uvos | :P | 00:19 |
| Wizzup | try envvarshere maemo-summoner /usr/bin/hildon-status-menu.launch | 00:19 |
| uvos | envvarshere? | 00:20 |
| Wizzup | G_MESSAGES_DEBUG=all maemo-summoner /usr/bin/hildon-status-menu.launch | 00:21 |
| uvos | maemo-summoner /usr/bin/hildon-status-menu.launch dosent result in any difference in behavior | 00:21 |
| uvos | no change | 00:21 |
| Wizzup | is it maemo-invoker then? | 00:21 |
| Wizzup | I always forget | 00:21 |
| Wizzup | let me try on my d4 | 00:21 |
| uvos | invoker stars it without maemo-launcher | 00:22 |
| uvos | and summoner just calls dbus | 00:22 |
| uvos | iirc | 00:22 |
| uvos | not sure what you want | 00:22 |
| Wizzup | I think summoner should be right one, but in this case I also do not see any messages | 00:22 |
| Wizzup | maybe there is something more special about hildon-status-menu | 00:22 |
| uvos | i had this working before | 00:22 |
| uvos | with h-s-m | 00:22 |
| Wizzup | maybe it has a custon env var? | 00:23 |
| Wizzup | it uses osso logging | 00:23 |
| uvos | yeah | 00:23 |
| uvos | thats it | 00:23 |
| uvos | i think it had some arcane var | 00:23 |
| Wizzup | still I can recommend maemo-summoner | 00:23 |
| Wizzup | this also work with gdb | 00:23 |
| uvos | yea sure i know | 00:24 |
| uvos | if (getenv ("DEBUG_OUTPUT") == NULL) | 00:25 |
| uvos | closes all the stdio fds | 00:25 |
| uvos | on that condition | 00:26 |
| uvos | this is sillyness we should probubly just remove | 00:26 |
| Wizzup | uvos: agreed @ remove | 00:29 |
| uvos | it still also reacts to G_MESSAGES_DEBUG levels | 00:29 |
| uvos | so i dont get at all why they added this | 00:30 |
| Wizzup | freemangordon: upgraded to new kernel but don't have wifi (?) | 01:18 |
| Wizzup | looks like some oops | 01:19 |
| Wizzup | seems like a race | 01:21 |
| Wizzup | https://dpaste.com/33RHBF3DK | 01:22 |
| Wizzup | freemangordon: yeah reboot made it go away | 01:37 |
| Wizzup | freemangordon: really this is so nice, really smooth 3d, 2d, stable (it seems) | 01:39 |
| mighty17[m] | `[ 43.466] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (Error loading shared library /usr/lib/xorg/modules/dri/swrast_dri.so: No such file or directory)` there is swrast.so, should i just rename it? | 08:13 |
| * mighty17[m] hasnt set MESA_LOADER_DRIVER_OVERRIDE=pvr for xorg | 08:14 | |
| freemangordon | hmm, ants are still there, but besides that and tearing I think we have a pretty descent GPU stack now | 09:02 |
| freemangordon | tmlind: ping | 09:02 |
| freemangordon | Wizzup: I guess you don't mind if I move sgx-ddk-um to autotools? | 11:32 |
| mighty17[m] | <mighty17[m]> "hasnt set MESA_LOADER_DRIVER_OVE..." <- That didn't work as well | 12:21 |
| mighty17[m] | swrast_dri.so is necessary? | 12:21 |
| uvos | aiglx is never going to work on pvr | 12:27 |
| uvos | aiglx: acellerated indirect opengl for x | 12:28 |
| uvos | 1. indirect rendering is disabled by default in x since 2016 or so | 12:28 |
| uvos | 2. omap4 dosent support opengl | 12:28 |
| uvos | 3. aiglx supports opengl up to version 1.2 only | 12:29 |
| uvos | 4. no one uses opengl 1.2 | 12:29 |
| Wizzup | freemangordon: don't mind | 12:30 |
| uvos | 5. except for special niche uses (like me remote rendering cnc program tracebacks over the network) aiglx is useless | 12:30 |
| mighty17[m] | aiglx is related to my issue? :O | 12:34 |
| uvos | aiglx is trying to load swrast_dri | 12:35 |
| uvos | this is red herring | 12:35 |
| mighty17[m] | Ah, I wonder why it's used in lxqt then | 12:35 |
| uvos | its not used | 12:35 |
| uvos | its just loaded | 12:35 |
| uvos | its totaly unrealted to any problems you might have | 12:35 |
| uvos | aiglx is _never_ used | 12:36 |
| mighty17[m] | Imma send full log then | 12:36 |
| uvos | unless you enable it explicitly in like 3 places | 12:36 |
| mighty17[m] | https://paste.debian.net/1226456/ | 12:36 |
| mighty17[m] | uvos: That's unlikely | 12:36 |
| uvos | your using mdoesetting | 12:38 |
| uvos | that cant be acellerated on pvr | 12:39 |
| mighty17[m] | The one fmg sent :D | 12:39 |
| uvos | for xorgs own rendering | 12:39 |
| uvos | no | 12:39 |
| uvos | that one also dosent work | 12:39 |
| uvos | it might do acceleration for 3d clients in dri3 mode, but dri2 mode was broken last time i tried | 12:39 |
| uvos | it | 12:40 |
| uvos | just use omap-ddx | 12:40 |
| uvos | also 2d rendering is broken in dri3 mode | 12:40 |
| mighty17[m] | I can't seem to build it :/ | 12:40 |
| uvos | aka it dosent work | 12:40 |
| uvos | just gennerally | 12:40 |
| mighty17[m] | This is a mess xD | 12:40 |
| mighty17[m] | I should just work on getting omap-ddx working | 12:40 |
| mighty17[m] | uvos: Maybe that's why xfce worked and lxqt didn't | 12:41 |
| uvos | no | 12:41 |
| uvos | lxqt uses openbox as wm | 12:41 |
| uvos | it dosent need any 3d at all | 12:41 |
| mighty17[m] | Then why did it fail here, coz modesetting? | 12:42 |
| uvos | no | 12:42 |
| uvos | it fails because you have another issue on your end unrelated to 3d/xorg | 12:42 |
| mighty17[m] | Hm?? | 12:43 |
| * mighty17[m] didnt know this existed https://pkgs.alpinelinux.org/package/edge/community/armv7/xf86-video-omap | 13:03 | |
| uvos | wont work | 13:04 |
| mighty17[m] | ye thats 0.4.5 | 13:04 |
| mighty17[m] | atleast the build instructions are fine? | 13:04 |
| Wizzup | mighty17[m]: don't use that xf86-video-omap, use ours | 13:11 |
| mighty17[m] | Wizzup: i was just trying to get build instructions and deps | 13:14 |
| mighty17[m] | gonna modify that to suits ours | 13:14 |
| Wizzup | I think we have a debian/control and debian/rules file | 13:16 |
| Wizzup | for deps and such | 13:16 |
| Wizzup | you'll also need to pkg the sgx stuff to build | 13:17 |
| mighty17[m] | Wizzup: sgx-ddk-um? | 13:18 |
| Wizzup | yes, see the build-depends on our xf86-video-omap | 13:18 |
| * mighty17[m] is confused with sgx-ddk-umhttps://gitlab.com/postmarketOS/pmaports/-/tree/master/non-free/sgx-ddk-um | 13:18 | |
| * mighty17[m] * is confused with sgx-ddk-um https://gitlab.com/postmarketOS/pmaports/-/tree/master/non-free/sgx-ddk-um | 13:20 | |
| Wizzup | make sure it's the exact same we use | 13:20 |
| Wizzup | I think the version might be different | 13:20 |
| mighty17[m] | `1.17.4948957` ? | 13:22 |
| Wizzup | per our repo... https://github.com/maemo-leste/sgx-ddk-um/commit/a1d07a194ea93882920292b5594169b03d19b257 | 13:23 |
| Wizzup | check commit hash | 13:23 |
| mighty17[m] | yeah we use ti's repo :D | 13:23 |
| Wizzup | it might be the same, but better make sure | 13:23 |
| Wizzup | I think I bumped it at some point | 13:24 |
| mighty17[m] | Wizzup: it isnt :( | 13:24 |
| * Wizzup bbiab | 13:24 | |
| Wizzup | figured | 13:24 |
| mighty17[m] | you're using older hash :( | 13:25 |
| freemangordon | mighty17[m]: which has is the newest? | 13:28 |
| freemangordon | 742cf38aba13e1ba1a910cf1f036a1a212c263b6? | 13:29 |
| mighty17[m] | 551665bf9c321bc3e7721416e6ebbc9f65c18155 | 13:29 |
| freemangordon | no, it is not :P | 13:29 |
| freemangordon | there is a newer one in -next | 13:29 |
| freemangordon | Wizzup: but yeah, we shall upgrade blobs to latest | 13:29 |
| mighty17[m] | oh there's a next :o | 13:29 |
| * mighty17[m] finds git.ti super slow | 13:30 | |
| freemangordon | Wizzup: either 551665bf9c321bc3e7721416e6ebbc9f65c18155 or 742cf38aba13e1ba1a910cf1f036a1a212c263b6 | 13:30 |
| mighty17[m] | 742cf38aba13e1ba1a910cf1f036a1a212c263b6 seems to be the newest with -next | 13:31 |
| freemangordon | mhm | 13:31 |
| mighty17[m] | 551665bf9c321bc3e7721416e6ebbc9f65c18155 is newest in zeus | 13:31 |
| freemangordon | right | 13:31 |
| mighty17[m] | whats the difference? | 13:31 |
| freemangordon | 742cf38aba13e1ba1a910cf1f036a1a212c263b6 is just some headers so it is not really relevant | 13:31 |
| mighty17[m] | `configure: error: Package requirements (sgx-ddk-um randrproto renderproto videoproto xextproto) were not met:` :( | 13:33 |
| freemangordon | mhm | 13:33 |
| freemangordon | you need to install the relevant -dev packages | 13:33 |
| mighty17[m] | i dont think we have -dev for these | 13:34 |
| mighty17[m] | https://git.alpinelinux.org/aports/tree/main/xextproto/APKBUILD?h=3.8-stable#n11 | 13:34 |
| mighty17[m] | and def not for sgx-ddk-um | 13:35 |
| freemangordon | well, you'll have to create | 13:36 |
| mighty17[m] | for sgx-ddk-um yes, what do we need for others? its quite likely they were packaged | 13:38 |
| freemangordon | they shoud be a part of xorg-dev (or similar) package | 13:39 |
| mighty17[m] | freemangordon: https://packages.ubuntu.com/bionic/all/xorg-dev/filelist seems to only have docs? | 13:43 |
| uvos | wtf | 13:44 |
| freemangordon | x11proto-dev | 13:44 |
| Wizzup | freemangordon: we haev -next afaik | 13:45 |
| uvos | what dose it matter what some ubuntu package contains | 13:45 |
| Wizzup | freemangordon: last time I pulled them | 13:45 |
| uvos | you have to check what alpine package contains the headers | 13:45 |
| freemangordon | Wizzup: ahm yes | 13:46 |
| freemangordon | sorry, my bad | 13:46 |
| mighty17[m] | https://pkgs.alpinelinux.org/package/edge/main/armv7/xorgproto | 13:46 |
| mighty17[m] | already in deps | 13:46 |
| mighty17[m] | uvos: i wanted to compare, like deb has some x file, what pkg in alpine has that x file | 13:47 |
| freemangordon | well, you need xorgproto-dev, or whatever it is in alpine | 13:47 |
| Wizzup | mighty17[m]: you can get a debian system and use dpkg -L | 13:47 |
| freemangordon | also, xorgproto != x11proto-dev | 13:48 |
| mighty17[m] | doesnt exist | 13:48 |
| Wizzup | freemangordon: I suggest we just let mighty17[m] do the alpine packaging | 13:48 |
| Wizzup | I think he'll figure out what he needs from autotools | 13:48 |
| mighty17[m] | freemangordon: files seem to be similar :P | 13:48 |
| freemangordon | yeah | 13:48 |
| mighty17[m] | https://pkgs.alpinelinux.org/contents?branch=edge&name=xorgproto&arch=x86&repo=main | 13:48 |
| mighty17[m] | Wizzup: deb doesnt have smth like pkgbuilds right? | 13:51 |
| uvos | various files debian directlry | 13:51 |
| uvos | *directory | 13:52 |
| uvos | mostly crontrol and rules | 13:52 |
| tmlind | freemangordon: pong | 13:58 |
| freemangordon | tmlind: do you want to help me with upstreaming https://github.com/maemo-leste/droid4-linux/commit/f56836db3ec4210c5cfaf40fa721a6e21cd7730e ? The problem is that when we discussed that with Tomy over th ML back then he was opposing to this :) | 14:01 |
| freemangordon | OTOH I don;t really think his arguments are valid, but I am not sure I can convince him | 14:01 |
| freemangordon | *Tomi | 14:02 |
| tmlind | freemangordon: not sure i can help much with that one | 14:03 |
| freemangordon | well, without this omapdrm is more or less useless for anything else but a simple usecases | 14:04 |
| freemangordon | esp n omap3 | 14:04 |
| freemangordon | *on | 14:04 |
| freemangordon | without that all GEM buffers must be allocated from CMA, otherwise they cannot be exported == PVR cannot render to them | 14:05 |
| freemangordon | and given that CMA is unreliable... | 14:06 |
| tmlind | ok | 14:06 |
| freemangordon | tmlind: I am asking you because I know what the result be if I send that for upstreaming | 14:08 |
| freemangordon | an instant NAK | 14:08 |
| freemangordon | without even a discussion why and how | 14:08 |
| freemangordon | I am not sure it will be the same if you send it | 14:08 |
| freemangordon | but well... | 14:08 |
| tmlind | heh i doubt me sending it makes any difference :) | 14:09 |
| freemangordon | well, I bet it makes | 14:09 |
| tmlind | best to have some clear test case in the description | 14:10 |
| freemangordon | what do you mean? I don't think a test case is needed to prove that non-linear buffers are not exported. There are checks in current (upstream) code to assure that, -22 otherwise | 14:11 |
| tmlind | how about some memory usage comparison in the description? | 14:18 |
| tmlind | i guess on n900 it makes a difference | 14:18 |
| freemangordon | I can do tiler_map comparison on d4, but it will be huge | 14:18 |
| freemangordon | it makes all the difference on d4 as well | 14:19 |
| freemangordon | this is needed as well https://github.com/maemo-leste/droid4-linux/commit/067976f0afd4a65bf32a3f450ee42f508a1b0612 | 14:19 |
| uvos | problem is address space usage | 14:19 |
| uvos | not physical ram | 14:19 |
| tmlind | ah | 14:19 |
| freemangordon | so either ways those 2 shall be send as series | 14:19 |
| freemangordon | as 2 combined makes omapdrm stable for daily usage | 14:20 |
| freemangordon | on d4 at least | 14:20 |
| freemangordon | uvos: problem is eitehr address space usage (omap4) or cma (omap3) | 14:21 |
| sicelo | okay ... i might just give up trying to calibrate the droid 4. 3 cycles completed, still mAh readout is 700mAh :-/ | 14:21 |
| uvos | might be true | 14:21 |
| uvos | i get 800-900mah for oem batterys | 14:21 |
| uvos | (that are as old as teh devices ie ~2012) | 14:22 |
| sicelo | no. | 14:22 |
| uvos | if you say so | 14:22 |
| sicelo | i have a new battery, and it lasts much longer than the previous one | 14:22 |
| uvos | ok | 14:22 |
| sicelo | the value hasn't changed even by 1mAh from old battery. that'd be a real miracle | 14:22 |
| uvos | right | 14:23 |
| uvos | so call dident compleat | 14:23 |
| sicelo | the way i see it, calibration isn't happening. not sure why | 14:23 |
| uvos | it needs to see empty+full and needs to shutdown cleanly | 14:23 |
| sicelo | i charge to full, and i let the device go till empty. | 14:23 |
| sicelo | so why it doesn't work ... beats me | 14:23 |
| sicelo | what's the location of the saved file btw? maybe i shall delete that and see what happens | 14:24 |
| uvos | /var/lib/droid4-battery-calibration/charge_full | 14:24 |
| sicelo | thanks. let me check | 14:24 |
| uvos | "i charge to full, and i let the device go till empty." it needs to shutdown cleanly | 14:25 |
| uvos | rn the device allways oopses on shutdown | 14:25 |
| uvos | because of some bug in uart | 14:25 |
| uvos | that might be the reason | 14:25 |
| sicelo | mmm | 14:25 |
| Wizzup | right we should test if not detaching the console makes that go away | 14:26 |
| uvos | it dose | 14:26 |
| uvos | the oops | 14:26 |
| Wizzup | maybe tmlind already has a patch for this | 14:27 |
| Wizzup | I assume he should see it too, since we share the droid4-pm scripts | 14:27 |
| sicelo | that charge_full file was last modified on Jan 5, so yeah, not got calibration since i replaced battery | 14:28 |
| uvos | your battery might also just not be sutable | 14:28 |
| uvos | the d4 needs really low ir | 14:28 |
| uvos | with high ir it will shutdown way to soon | 14:29 |
| uvos | because the voltage drops to mutch during the ms while the omap wakes up from ret | 14:29 |
| uvos | leads also need to be short | 14:29 |
| sicelo | i reused the original battery's controller | 14:33 |
| uvos | thats not relevant | 14:34 |
| sicelo | no leads in between. the new battery's terminals fit perfectly where the old ones did | 14:34 |
| sicelo | anyway, i guess i'll accept this as broken for the time being | 14:35 |
| uvos | you can also just set /var/lib/droid4-battery-calibration/charge_full to whatever you expect | 14:35 |
| uvos | btwe | 14:35 |
| uvos | maybe a bit lower | 14:35 |
| uvos | this gives better results than uncalibrated | 14:36 |
| Wizzup | freemangordon: what do you think about https://github.com/maemo-leste/bugtracker/issues/588 | 14:51 |
| Wizzup | uvos: which patch did you want me to revert wrt wakeups | 15:05 |
| Wizzup | a20f161298226a368d73af1b1467568ba5d05efa ? | 15:06 |
| Wizzup | that is: drm/omap: get fbdev working for manually updated display | 15:06 |
| freemangordon | Wizzup: looks ok | 15:10 |
| Wizzup | freemangordon: I'll split it up into some mapphone specific stuff, too | 15:13 |
| uvos | Wizzup: yess | 15:27 |
| tmlind | Wizzup: sorry not sure if you already sent a device earlier for tomi.. i guess you'd have some email about it? | 16:12 |
| Wizzup | tmlind: I'll check | 16:20 |
| Wizzup | tmlind: looks like in 2019 with thread 'Motorola Droid 4 devices' | 16:21 |
| Wizzup | I don't know if I sent two or three, but I think three, to Tero, Peter and Tomi might have hone already | 16:22 |
| tmlind | ok | 16:32 |
| Wizzup | uvos: kernel without fbdev emul is in repo | 17:15 |
| uvos | Wizzup: great | 17:19 |
| uvos | since you merged the series on leads | 17:20 |
| uvos | please https://github.com/maemo-leste/leste-config/pull/28 | 17:20 |
| Wizzup | hmm my X seems stuck here: [pid 3721] ioctl(12, DRM_IOCTL_MODE_SETPROPERTY, 0xbe85c978) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) | 17:26 |
| Wizzup | no error in dmesg | 17:26 |
| Wizzup | uvos: ok will merge | 17:27 |
| freemangordon | ugh, libtool does not allow library revision to be > 99999 :( | 17:29 |
| Wizzup | https://dpaste.com/2SSKGP2ZB I set drm.debug to 0xff when this happened | 17:29 |
| Wizzup | freemangordon: weird | 17:30 |
| uvos | ssomething something autotools :P | 17:30 |
| freemangordon | no, this is lobtool ;) | 17:30 |
| freemangordon | *libtool | 17:30 |
| uvos | libtool ist part of autotools really | 17:31 |
| uvos | practicly | 17:31 |
| uvos | but ok | 17:31 |
| freemangordon | Wizzup: no idea | 17:31 |
| freemangordon | well, kinda makes sense, but cannot produce lib that matches PVR blobs versions | 17:32 |
| freemangordon | at least not that easy | 17:32 |
| uvos | hopfully firefox dosent use libtool | 17:34 |
| uvos | they will reatch version 99999 next year probubly | 17:34 |
| freemangordon | no, this is revision, not version ;) | 17:34 |
| uvos | ah oh | 17:34 |
| freemangordon | the same restrictions apply for version though :) | 17:34 |
| Wizzup | freemangordon: wonder how pvrtool folks do it | 17:35 |
| freemangordon | also, this is applicable to libs onjly | 17:35 |
| freemangordon | Wizzup: yeah | 17:35 |
| freemangordon | maybe they use Makefiles | 17:35 |
| Wizzup | right | 17:35 |
| Wizzup | btw so the drm debug I posted above, we can ignore it now but the screen on my d4 won't turn on | 17:36 |
| Wizzup | it doesn't seem to be an X crash but X seems to get erestartsys | 17:36 |
| Wizzup | and it keeps trying to do some ioctl | 17:36 |
| Wizzup | so I'll reboot my d4 unless we want more debug info | 17:36 |
| Wizzup | (gdb) bt | 17:37 |
| Wizzup | #0 0xb6a33f06 in ioctl () at ../sysdeps/unix/syscall-template.S:78 | 17:37 |
| Wizzup | #1 0xb6d24c76 in drmIoctl () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:37 |
| Wizzup | #2 0xb6d2923a in drmModeConnectorSetProperty () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:37 |
| Wizzup | #3 0xb66c3f12 in () at /usr/lib/xorg/modules/drivers/omap_drv.so | 17:37 |
| Wizzup | is the gdb backtrace | 17:37 |
| Wizzup | I did also try to run xrandr and xset later on, but I don't think this is because of that | 17:37 |
| freemangordon | it tries to set "rotate" property, most-probably | 17:38 |
| Wizzup | well the device was locked | 17:39 |
| Wizzup | and then it wouldn't unlock | 17:39 |
| Wizzup | so I wasn't sure what was up | 17:39 |
| Wizzup | and then I ssh'd in and tried things | 17:39 |
| Wizzup | so it might be perhaps turning on the display | 17:39 |
| freemangordon | "wouldn't unlock" like? stays on black screen? | 17:39 |
| Wizzup | yes | 17:39 |
| freemangordon | right | 17:40 |
| Wizzup | let me get ddx dbgsym for more accurate trace | 17:40 |
| Wizzup | #0 0xb6a33f06 in ioctl () at ../sysdeps/unix/syscall-template.S:78 | 17:40 |
| Wizzup | #1 0xb6d24c76 in drmIoctl () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:40 |
| Wizzup | #2 0xb6d2923a in drmModeConnectorSetProperty () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:40 |
| Wizzup | #3 0xb66c3f12 in drmmode_output_dpms (output=<optimized out>, mode=0) at drmmode_display.c:797 | 17:40 |
| Wizzup | #4 0x005074f4 in xf86DPMSSet () | 17:40 |
| Wizzup | #5 0x0050755c in xf86SaveScreen () | 17:40 |
| Wizzup | #6 0x004db078 in dixSaveScreens () | 17:40 |
| freemangordon | what is ret=-512 ? | 17:41 |
| freemangordon | maybe send email to Tomi, no idea what is this | 17:41 |
| freemangordon | uvos: btw, do you know if .so revision is somehow set in headers? | 17:44 |
| freemangordon | like, do we care if it is lib.so.1.2.3 or lib.so.1.2.0? | 17:44 |
| Wizzup | freemangordon: I think this: | 17:46 |
| Wizzup | [pid 3721] ioctl(12, DRM_IOCTL_MODE_SETPROPERTY, 0xbe85c978) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) | 17:46 |
| Wizzup | [pid 3721] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- | 17:46 |
| Wizzup | [pid 3721] sigreturn({mask=[]}) = 12 | 17:46 |
| freemangordon | cool, I have no clue what is this about :) | 17:47 |
| uvos | not sure what you mean | 17:47 |
| uvos | in pvr_k? | 17:47 |
| freemangordon | in geberal | 17:47 |
| freemangordon | *general | 17:47 |
| uvos | pvr_k checks the version | 17:47 |
| uvos | but it just gets it form some funciton | 17:48 |
| uvos | i dont think the file name matters | 17:48 |
| uvos | just what pvr_um reports | 17:48 |
| freemangordon | no, I am talking about versions of the libs | 17:48 |
| freemangordon | if I compile to lib.so.1.2.0 and later on rename to lib.so.1.2.3, does it change anything? | 17:48 |
| freemangordon | besides symlinks, obviously | 17:49 |
| uvos | pvr specificly? no | 17:50 |
| uvos | other libs sure | 17:50 |
| uvos | pretty sure i renamed some stuff while testing different variants | 17:51 |
| freemangordon | "other libs sure" - what do you mean? | 17:51 |
| uvos | wel obviously it can not be stated generally that compiling as 1.2.0 and renaming the lib later to something else is equivalent as passint something else to the build system | 17:52 |
| uvos | since plenty of libs use the version string | 17:52 |
| freemangordon | yes, but I am talking about revision, not version | 17:53 |
| freemangordon | the '0' at the end | 17:53 |
| uvos | same thing | 17:53 |
| freemangordon | but, does this get included anywhere else, but in the name? | 17:53 |
| freemangordon | basically this is the question | 17:54 |
| uvos | question is essantally unawnserable since doing so would force me to prove a negative | 17:56 |
| uvos | so no idea | 17:56 |
| uvos | you certenly could do this | 17:56 |
| freemangordon | yeah, my question was rather "do you know". | 17:57 |
| freemangordon | no need to prove anything | 17:57 |
| freemangordon | I'll do it to work, if we hit issues, well | 17:57 |
| freemangordon | *make it to | 17:57 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/leste-config/pull/28 (bionic and droid 3: add ts-buttons light to mce now that the kernel c…) | 18:19 |
| buZz | oh nice, those work on droid4 too now? | 18:24 |
| buZz | o | 18:24 |
| buZz | i'll try ;) | 18:24 |
| Wizzup | the sw is still building and only for -devel | 18:28 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mapphone-kexecboot-config/pull/1 (Add charge mode to all devices) | 18:32 |
| Wizzup | uvos: I think sphone should go in the connectivity meta yeah | 18:34 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/hildon-connectivity-meta/pull/1 (Update control) | 18:40 |
| Wizzup | uvos: with adding charge-mode to hildon-meta, have we confirmed it works on the n900? | 18:41 |
| buZz | welp, droid4 discharged itself while off again :P | 18:43 |
| uvos | Wizzup: yes when you switch the runlevel switches to it | 18:43 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/hildon-meta/pull/6 (add salutem, charge-mode and sphone to hildon-meta, siwtch pp to libinput) | 18:43 |
| uvos | Wizzup: but dident try with the drm version | 18:43 |
| Wizzup | uvos: do you mean kernel cmdline? | 18:43 |
| uvos | no switch later | 18:43 |
| uvos | also dosent matter, as long as its not in cmdline | 18:43 |
| uvos | it dose nothing | 18:43 |
| Wizzup | uvos: uh ok so now all devices lack fbdev emul but we just enabled chargemode for them | 18:43 |
| uvos | no no | 18:44 |
| uvos | i switch chargemode to drm | 18:44 |
| Wizzup | ok | 18:44 |
| uvos | *swiched | 18:44 |
| uvos | so it works on mapphones (tested with drm verson) and n900 (tested only with older fbdev version) | 18:44 |
| uvos | but really it likey works everywhere | 18:45 |
| uvos | and it will only be active on mapphones | 18:45 |
| uvos | since only they got the cmdline change | 18:45 |
| Wizzup | ok | 18:45 |
| Wizzup | I think I merged all the PRs and it's all building atm | 18:46 |
| Wizzup | uvos: any I missed? | 18:48 |
| uvos | no | 18:48 |
| Wizzup | ok | 18:53 |
| Wizzup | cool, ty | 18:53 |
| uvos | [18:24] <buZz> oh nice, those work on droid4 too now? | 18:55 |
| uvos | this has worked on d4 since a long time | 18:55 |
| buZz | oh guess i just missed it | 18:57 |
| Wizzup | they are off on mine | 18:58 |
| uvos | right you disabled this on purpose | 18:59 |
| Wizzup | mhm | 19:05 |
| dsc_ | sicelo: OTP/2FA GUI for maemo (like Google Authenticator) | 19:11 |
| dsc_ | do you know anything about that | 19:11 |
| freemangordon | dsc_: there was some discussion on TMO a week or so ago | 19:13 |
| dsc_ | I take it there is no 2FA app (like Google Authenticator) for leste currently? | 19:15 |
| dsc_ | apart from `oathool` which is a CLI app | 19:16 |
| dsc_ | (also the camera probably doesnt work yet :P) | 19:17 |
| dsc_ | anyway, I made a 2FA app just checking if it already existed | 19:18 |
| sicelo | dsc_: yes i know about it and i ported it to Leste | 19:18 |
| dsc_ | sicelo: link? | 19:18 |
| sicelo | https://github.com/maemo-leste-extras/maeotp | 19:18 |
| sicelo | anyway, maybe yours will work better for new users | 19:19 |
| dsc_ | mine can be described as a Google Authenticator clone | 19:20 |
| dsc_ | GUI wise | 19:20 |
| dsc_ | ill push it to git sometime and ping you I guess | 19:21 |
| dsc_ | we can have both | 19:21 |
| dsc_ | ヾ(⌐■_■)ノ♪ | 19:21 |
| sicelo | yes, users will appreciate it | 19:21 |
| sicelo | i'm not going to switch myself tbh ... because i already have years of keys in the format of this one :-) | 19:22 |
| sicelo | it has a big limitation in that you have to convert the code first, so yes, for most new users it's a great PITA. i think yours will therefore be the better one | 19:23 |
| dsc_ | https://plak.infrapuin.nl/selif/lber6pgj.png | 19:25 |
| dsc_ | UI still far from done though just WIP | 19:25 |
| dsc_ | it only supports TOTP | 19:26 |
| dsc_ | base32 (QR) codes | 19:26 |
| sicelo | cool. yes, only totp seems to be in use nowadays | 19:26 |
| dsc_ | right | 19:26 |
| dsc_ | I wondered that :P | 19:26 |
| sicelo | dsc_: question though - why something from scratch? | 19:31 |
| dsc_ | I tend to start projects without checking if it existed already :/ | 19:32 |
| dsc_ | tbh I wanted to make a 2FA app anyway for my Ubuntu desktop :P | 19:33 |
| dsc_ | and then I was like "I should port it to leste" | 19:33 |
| dsc_ | been only working on this for a few days though... | 19:33 |
| dsc_ | so regardless if its handy for leste, I want a Google Authenticator-like app for my Ubuntu laptop | 19:34 |
| freemangordon | Wizzup: do you know how to mv in Makefile.am install-exec-hook? | 19:34 |
| freemangordon | I mean - what is the 'canonical' way? | 19:34 |
| Wizzup | sorry, don't know what you want exactly | 19:35 |
| freemangordon | to rename a file | 19:35 |
| sicelo | dsc_: sure, please port it :-) | 19:35 |
| sicelo | i think i'm the only user of the one i ported, so effectively there isn't one for Leste | 19:36 |
| dsc_ | sicelo: so turns out the options are kind of limited for OTP GUIs on linux, which surprised me. Granted, having 2FA codes on your desktop defeats the purpose, but still. | 19:36 |
| Wizzup | dsc_: probably they all use android ;) | 19:37 |
| sicelo | i see two GTK ones in sid | 19:37 |
| sicelo | i think you're a Qt guy .. ;-) | 19:37 |
| dsc_ | well as a user I wouldnt care | 19:37 |
| dsc_ | you're right, `otpclient` seems to work fine | 19:38 |
| sicelo | gnome-authenticator and otpclient ... i haven't used any of them | 19:38 |
| sicelo | but don't get me wrong - i wasn't saying don't write one ... was just asking | 19:39 |
| sicelo | i don't even know how these work on Leste (for obvious reasons) | 19:40 |
| dsc_ | But, for example, this `otpclient` might look scary to new users, it's more of a power-user tool. We need to bring Linux to the desktop in 2022. All GUIs need to have 3D particle explosions to wow the crowd. | 19:40 |
| dsc_ | therefor I will continue my efforts. | 19:41 |
| dsc_ | therefore* | 19:41 |
| bencoh | as long as the particle explosions can be disabled .... :) | 19:42 |
| dsc_ | :D | 19:42 |
| bencoh | I'm half-serious :) | 19:43 |
| sicelo | 20:26 < dsc_> base32 (QR) codes ... you're saying it only takes QR codes? | 19:43 |
| dsc_ | sicelo: Yeah QR code via webcam or desktop screenshot | 19:44 |
| dsc_ | (or phone camera) | 19:45 |
| sicelo | i hope you'll also support text entry (of the code/string) | 19:46 |
| sicelo | because on Leste, for example, juggling a screenshot is less easier than copying the code onto clipboard, then pasting ;-) | 19:47 |
| dsc_ | indeed, will do. Google Authenticator also supports this. So my app will at least be on-par regarding capabilities with that one | 19:47 |
| dsc_ | but it wont be as feature rich as yours | 19:48 |
| sicelo | heh, this one is quite bare, and no casual user is even able to make it work | 19:49 |
| dsc_ | ill try yours in a bit | 19:50 |
| sicelo | it's specifically for Hildon (and i didn't write it ... just ported it) | 19:51 |
| dsc_ | cool | 19:51 |
| dsc_ | yeah next time ill ask here before writing something lol | 19:51 |
| freemangordon | uvos: no idea what did you do, but since yesterday leste refuses to charge here | 19:52 |
| freemangordon | I am booting with cable connected to fastcharger (after power-down because of a low battery), it boots to h-d (maybe) and then instantly beeps and powers-down | 19:53 |
| freemangordon | on d4 that is | 19:53 |
| uvos | freemangordon: yes thats expected | 19:54 |
| freemangordon | oh, now I feel better :D | 19:55 |
| uvos | it was a temporary situation because the charge mode pr was merged later | 19:55 |
| uvos | just boot emergency mode | 19:55 |
| uvos | it will charge there | 19:55 |
| freemangordon | I boot to android | 19:55 |
| uvos | sure that works too | 19:55 |
| uvos | this issue is now fixed | 19:55 |
| freemangordon | and it charges there, but android says 15% full | 19:55 |
| freemangordon | fixed how/where? | 19:55 |
| uvos | with Wizzup merging the pr just now | 19:55 |
| freemangordon | ah, ok | 19:55 |
| freemangordon | what is the fix? | 19:56 |
| uvos | enabling charge mode | 19:56 |
| uvos | so that this works as designed | 19:56 |
| freemangordon | hmm, android just boots | 19:56 |
| uvos | ie stays in charge mode at least untill the battery is safe to boot | 19:56 |
| uvos | hmm? | 19:56 |
| uvos | it dosent boot to kexecboot? | 19:56 |
| freemangordon | it boots and then I select 'android' | 19:57 |
| freemangordon | and it boots there, which means battery has enough charge | 19:57 |
| freemangordon | 15% | 19:57 |
| freemangordon | some limit is not quite right | 19:57 |
| uvos | no its fine | 19:57 |
| freemangordon | how's that? | 19:57 |
| uvos | its just more conservative than android | 19:57 |
| uvos | beacuse 1. we take longer to boot 2. android takes the battery down to 3.0v | 19:58 |
| uvos | which is pretty bad for it | 19:58 |
| freemangordon | as I said it boots to h-d | 19:58 |
| freemangordon | but refuses to charge and instead powers down | 19:58 |
| uvos | and 3 we can only take 500mah form usb | 19:58 |
| uvos | android can take 1.5A | 19:58 |
| uvos | *500mA | 19:58 |
| uvos | these 3 factors allow android to boot way sooner | 19:58 |
| freemangordon | what do you mean "usb"? this is not USB but fastcharger | 19:58 |
| uvos | dosent matter | 19:59 |
| uvos | mainline kernel has no way to detect this | 19:59 |
| freemangordon | wait, you are saying we are limited to 500 mA? | 19:59 |
| uvos | or negotiate for high power device class | 19:59 |
| uvos | yes we are | 19:59 |
| freemangordon | omg | 19:59 |
| uvos | even that is a hack | 19:59 |
| freemangordon | this is useless, basically | 19:59 |
| uvos | we dont negotiate for high power | 19:59 |
| uvos | so we violate usb spec | 19:59 |
| uvos | we should only take 500uA | 19:59 |
| uvos | i would not call it useless | 20:00 |
| uvos | it just takes longer | 20:00 |
| freemangordon | no, because you cannot use your device for how many minutes? 10? | 20:00 |
| uvos | no | 20:01 |
| uvos | just 2 minutes or so | 20:01 |
| freemangordon | also, you cannot use your device while charging with low battery | 20:01 |
| freemangordon | as it drains the battery instead of charging it | 20:01 |
| uvos | in my experiance you can | 20:01 |
| uvos | as long as your not loading it hevly | 20:01 |
| uvos | ie compiling is out | 20:01 |
| freemangordon | yeah | 20:01 |
| uvos | but webbrowsing is fine | 20:01 |
| freemangordon | who should fix this charging thing? | 20:01 |
| uvos | https://github.com/maemo-leste/bugtracker/issues/580 | 20:02 |
| uvos | read this | 20:02 |
| uvos | someone | 20:02 |
| uvos | at some point :P | 20:02 |
| freemangordon | :) | 20:02 |
| uvos | the driver needs to negotiate over usb | 20:02 |
| freemangordon | uvos: still, this is broken | 20:05 |
| freemangordon | there are no low battery warnings at all | 20:06 |
| uvos | it unimplemented, not broken | 20:06 |
| freemangordon | at some point device just powers down | 20:06 |
| uvos | there are low battery warnings | 20:06 |
| uvos | no | 20:06 |
| uvos | or yes | 20:06 |
| freemangordon | no, there are not | 20:06 |
| uvos | yes there are | 20:06 |
| uvos | its just | 20:06 |
| uvos | that due to how cpcap works | 20:06 |
| uvos | you cant know what state of charge the battery is in | 20:06 |
| uvos | unless you see the battery full during that boot | 20:06 |
| uvos | and charge estimation from voltage in upower is terrible | 20:07 |
| freemangordon | and what about upower? | 20:07 |
| uvos | to the point of uselessness | 20:07 |
| uvos | so it thinks the battery is at 40% charge while it has a resting voltage of 3.2 or something | 20:07 |
| uvos | if there is adquate current | 20:07 |
| freemangordon | useless or not, it is better to give 10 fake low battery warnings than no warning at all and power-down out of the blue | 20:07 |
| uvos | upower needs the kernel to report charge staten wich cant unless you see the battery full during that boot | 20:08 |
| uvos | or it needs to estimate | 20:08 |
| uvos | witch it dose, very poorly | 20:08 |
| uvos | freemangordon: your welcome to improve it :P | 20:08 |
| freemangordon | yeah | 20:08 |
| freemangordon | before latest change it was doing pretty much ok | 20:09 |
| freemangordon | now this is useless | 20:09 |
| freemangordon | it at least was allowing me to boot to h-d and charge | 20:09 |
| freemangordon | and actually use the device | 20:09 |
| freemangordon | now it does not | 20:09 |
| uvos | "my latest change" ensures the battery dosent dicharged below 3v | 20:09 |
| uvos | wich was routinly happening | 20:10 |
| uvos | and runined one of my new batterys | 20:10 |
| uvos | so yeah im not removing that | 20:10 |
| uvos | it works fine | 20:10 |
| sicelo | :) | 20:10 |
| uvos | (with charge mode enabled) | 20:10 |
| freemangordon | uvos: the easiest way to ensure that is to not turn on the device, no? | 20:12 |
| uvos | you cant this is set by the bootloader | 20:12 |
| freemangordon | sure i can, by simply not pressing the power buttonj | 20:13 |
| uvos | i also can avoid geting into a car accident by handing myself | 20:13 |
| freemangordon | anyway, I think we need to have a discussion soon on what quality we want to produce | 20:14 |
| freemangordon | i.e. are we happy with things that works when the planets are aligned | 20:14 |
| freemangordon | but only then | 20:14 |
| uvos | this is a silly discussion to have | 20:15 |
| * freemangordon is afk | 20:15 | |
| uvos | no one wants these imperfect solutions | 20:15 |
| uvos | its just a question of what you want to work on to improve | 20:15 |
| Wizzup | freemangordon: do you know where the tp account manager info is stored in fremantle | 20:40 |
| Wizzup | freemangordon: just mission control stuff I guess | 20:41 |
| freemangordon | umm, in the same place as in upstream | 20:41 |
| freemangordon | what in particular do you need? | 20:41 |
| Wizzup | just want to look around, see what params are used for telepathy-idle on my fremantle n900 | 20:43 |
| freemangordon | ah | 20:43 |
| freemangordon | it should be in /usr/share/telepathy | 20:43 |
| freemangordon | iirc | 20:43 |
| Wizzup | user accounts? | 20:44 |
| Wizzup | ok I didn't mean this, but this is also helpful | 20:45 |
| sicelo | mc-tool list | 20:45 |
| sicelo | then mc-tool show <account ...> | 20:46 |
| Wizzup | freemangordon: as in it is not in .config | 20:46 |
| freemangordon | hm,, it should be in .config | 20:46 |
| freemangordon | is it not? | 20:46 |
| Wizzup | sicelo: hm I don't have mc-tool | 20:46 |
| Wizzup | freemangordon: well let me dig | 20:46 |
| sicelo | oh, maybe you need to install it. i've always had it on my N900 and thought it came ootb | 20:47 |
| freemangordon | Wizzup: .local/share? | 20:48 |
| sicelo | mc-tool comes from libmissioncontrol-utils | 20:48 |
| freemangordon | I forgot where addressbook was kept | 20:49 |
| Wizzup | .rtcom-accounts | 20:49 |
| Wizzup | seems more like nokia specific way of storing the info though | 20:50 |
| Wizzup | as in I doubt that missioncontrol reads that | 20:51 |
| freemangordon | I think those are not mc accounts | 20:52 |
| freemangordon | this is different to mission-control, iiuc | 20:52 |
| freemangordon | not sure though | 20:52 |
| Wizzup | well mission-control is just account manager and channel dispatcher | 20:53 |
| Wizzup | maybe you call account manager where to read accounts from or something | 20:54 |
| Wizzup | maybe you can tell* | 20:54 |
| freemangordon | no idea | 20:54 |
| Wizzup | freemangordon: probably they parse it in rtcom binaries and just initiate Connection with those params from it | 20:57 |
| Wizzup | at connmgr | 20:57 |
| freemangordon | could be, yeah | 20:57 |
| freemangordon | uvos: device just powered down after sitting almost idle on the charger since we talked. maybe you ramp-up patch doesn't play well with the charger I have here | 21:10 |
| freemangordon | but it was wotking ok before | 21:10 |
| Wizzup | it improved the situation for me (no flickering when I plug it into a device), but of course it might be different for different devices/cables/chargers | 21:11 |
| uvos | was the green light on? | 21:11 |
| freemangordon | no | 21:11 |
| Wizzup | although the status not updating is annoying, since that impacts upower and also mce | 21:11 |
| uvos | then it wasent charging | 21:11 |
| freemangordon | yes | 21:11 |
| freemangordon | it wasnt | 21:11 |
| uvos | the green light is 100 hw indicator | 21:11 |
| uvos | *100% | 21:11 |
| freemangordon | sure | 21:12 |
| freemangordon | it was turning green before | 21:12 |
| uvos | the issue the ramp up fixes is pretty easy to see on a scope | 21:12 |
| uvos | cpcap will turn off charging if the voltage ever dips below a certain threshold | 21:12 |
| freemangordon | I don;t argue it it fixes issues or not | 21:13 |
| uvos | with quite high bandwith | 21:13 |
| freemangordon | nut since yesterday my device refuses to charge under leste | 21:13 |
| uvos | so if it stoped charging this happend | 21:13 |
| Wizzup | freemangordon: what is the problem you are seeing now, that it doesn't charge with new patches? | 21:13 |
| freemangordon | yes, it does not charge | 21:13 |
| freemangordon | oh, now it turned green | 21:13 |
| freemangordon | (the light) | 21:13 |
| freemangordon | after restart | 21:13 |
| freemangordon | and I got "charging" yellow stripe | 21:14 |
| freemangordon | no idea what's going on | 21:14 |
| uvos | the patch has also been in kernel longer than yesterdat | 21:14 |
| uvos | *day | 21:14 |
| uvos | afaik | 21:14 |
| uvos | but i dont use leste kernel | 21:14 |
| freemangordon | and now there is indication in the status bar that it charges | 21:15 |
| freemangordon | weird | 21:15 |
| uvos | sure that usually works | 21:15 |
| Wizzup | freemangordon: yeah so the delay there I think is a 30s one, which is when upower polls | 21:15 |
| uvos | sometimes it fails tho | 21:15 |
| freemangordon | not since yesterday | 21:15 |
| freemangordon | till 2 minutes ago | 21:15 |
| uvos | sometimes its immidately recognised | 21:15 |
| freemangordon | it was not recognized at all | 21:15 |
| freemangordon | but yeah, lets see | 21:16 |
| freemangordon | maybe some HW weirdness | 21:16 |
| freemangordon | uvos: could it be that android had put it in some weird state? | 21:18 |
| uvos | mabye - probubly not | 21:40 |
| Wizzup | freemangordon: so it looks like for tp we will need a program that starts tp connections on protocols/accounts. basic one is a ring connection for tel protocol | 21:43 |
| Wizzup | but something must request the account for sms to come in | 21:43 |
| Wizzup | I suppose whichever program requests it will also log? | 21:43 |
| Wizzup | or do we want a separate account for logging | 21:43 |
| Wizzup | I think nokia decided to combine these things | 21:44 |
| Wizzup | so if I had to guess, rtcom-call-ui sets up tp account with channels for calls, and rtcom-messaging-ui sets up tp account with channels for text(s) | 21:44 |
| Wizzup | and both do rtcom logging | 21:44 |
| Wizzup | (that is, the ui processes) | 21:44 |
| freemangordon | Wizzup: I am almost sure all this is explained on maemo.org wiki | 21:47 |
| Wizzup | I am pretty sure I know how it works, it was a question for how we want to do it | 21:48 |
| Wizzup | but if you want to link me maemo.org wiki pages, that'll be helpful I guess | 21:48 |
| freemangordon | ah, it is fine, I mean - if you know how it works, ok | 21:49 |
| Wizzup | I don't like the idea of requiring a GUI to log | 21:49 |
| Wizzup | but it probably makes the most sense since we need something to 'request' telepathy to start the so-called connection managers | 21:49 |
| Wizzup | (and connections on those connection managers) | 21:49 |
| freemangordon | I think nokia did a good job there | 21:50 |
| Wizzup | like, telepathy-ring is a connection manager and to receive smses (and have telepathy-ring run at all) we need to request an account on it with protocol 'tel' | 21:50 |
| freemangordon | so maybe do it like they did | 21:50 |
| Wizzup | k | 21:50 |
| Wizzup | ok | 21:51 |
| uvos | sphone can run without gui now btw, we could easly implment the logging as a sphone module and then spwan one non gui sphone process for logging or only one process with logging and ui loaded as desired | 21:53 |
| uvos | as everything is a module you can pick an choose what process dose what | 21:53 |
| Wizzup | right, but the fact that something must for example request a ring account means that whichever requests it can also do the logging | 21:53 |
| Wizzup | we could separate the logging, but programs also need to request connections so that they can act on incoming messages | 21:53 |
| Wizzup | or send messages | 21:54 |
| Wizzup | i.e. even if conversations mostly just reads from a db now, it must be able to send message | 21:54 |
| Wizzup | messages | 21:54 |
| uvos | sure | 21:54 |
| Wizzup | and to do it that it must talk to telepathy, request connections, and manage those connections, and create (or 'ensure') channels on those connections | 21:54 |
| uvos | im just saying that sphones arch makes it easy to implement the "monlithic" nokia esque shortcut way now | 21:54 |
| Wizzup | so we -could- have a module that just onlines/activates connections | 21:54 |
| uvos | and implement something better later | 21:54 |
| Wizzup | and another module that just does logging | 21:55 |
| uvos | without throwing most of it out | 21:55 |
| Wizzup | but it might not make sense that way | 21:55 |
| Wizzup | uvos: sure, I'm still just understanding telepathy | 21:55 |
| Wizzup | not making 'design decisions' in that sense yet | 21:55 |
| Wizzup | tp also has different client types: observers, approvders and handlers | 21:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
