| Wizzup | uvos: this is a problem though: sphone: contacts-evolution: can currently only fill contacts of ofono calls | 00:42 |
|---|---|---|
| Wizzup | it seems a bit arbitrary to me? | 00:43 |
| Wizzup | yeah just removing the arbitrary check fixed it | 00:44 |
| _uvos_ | Wizzup: dont remove the check its not arbirary at all | 01:10 |
| _uvos_ | the problem is that to match a contact you need to know what line_identifier is | 01:10 |
| _uvos_ | since it relates to the ebook query | 01:11 |
| _uvos_ | the current module takes line_identifier and assumes its a phone number | 01:11 |
| _uvos_ | this breaks badly if it itsent a phone number (because the message/ call comes from a im sefivce and its a username for instance) | 01:12 |
| _uvos_ | sphone needs a way to relate backends to vcf fields | 01:12 |
| Wizzup | freemangordon: ah it's TP_ANONYMITY_MODE_CLIENT_INFO | 01:12 |
| _uvos_ | this is currently missing, therefore this hack | 01:13 |
| Wizzup | _uvos_: ok, but for telepathy-ring this is fine | 01:13 |
| Wizzup | since it's also just line numbers | 01:13 |
| _uvos_ | sure you can add ring | 01:13 |
| _uvos_ | but do not remove the check | 01:13 |
| Wizzup | hm | 01:16 |
| Wizzup | well we first need to figure out how to really name the tp backends | 01:16 |
| Wizzup | I can give the ring one a special name, but there might be eventually one tp-ring per sim | 01:16 |
| Wizzup | currently it's a dbus object path | 01:16 |
| Wizzup | for example: /org/freedesktop/Telepathy/Account/ring/tel/account0 | 01:16 |
| Wizzup | I'll implement hold tomorrow, maybe see if I can find someone to test multi party on | 01:18 |
| Wizzup | anyway I'm happy :D | 01:21 |
| Wizzup | btw, the n900 phone ui is basically: | 01:22 |
| Wizzup | [horizontal dialing pad button] | 01:22 |
| Wizzup | [select contact] | 01:22 |
| Wizzup | [rtcom ui log] | 01:22 |
| Wizzup | and then the dialing pad is a nested window with: | 01:22 |
| Wizzup | [call type] | 01:22 |
| Wizzup | [text area for number] | 01:22 |
| Wizzup | dialing pad | 01:22 |
| Wizzup | this is pretty much the same elements the current gtk ui has, just sans the nested window and the rtcom ui | 01:23 |
| xes | Wizzup: hi | 01:48 |
| Wizzup | hi | 01:48 |
| xes | Wizzup: can we stop maedevu @ maemo infra? | 01:48 |
| Wizzup | yeah I think we migrated it half a year ago to my hw | 01:48 |
| xes | yep, i know, i mean.. there is nothing left there that is still in use | 01:49 |
| Wizzup | yeah, no, the dns we switched over a long time ago | 01:49 |
| Wizzup | so nothing should use it | 01:49 |
| xes | ok! | 01:50 |
| SuperMarioSF | inky: I'm using Hexchat on droid4. | 09:11 |
| SuperMarioSF | Wizzup: Okay, but where should I post that package request? bugtracker isn't a suitable place for this. | 09:13 |
| SuperMarioSF | btw, mscim is seems too old for nowdays, maybe port fcitx5 is more likely to work? | 09:14 |
| SuperMarioSF | ibus is out of question, because it was broken since 2016. never worked correctly on Chinese input. | 09:16 |
| SuperMarioSF | btw, about supporting IRC in connui, please at least implement SASL authentication, or there will be some problem logging in to Libera.Chat on some strange IP address. | 10:13 |
| SuperMarioSF | well, Chromium is much better used with --force-device-scale-factor=1.0 | 11:13 |
| SuperMarioSF | add CHROMIUM_FLAGS="--force-device-scale-factor=1.0" in /etc/profile (or new file in /etc/profile.d/chromium.sh) can do it every time without messing around .desktop files and MIME types | 11:14 |
| SuperMarioSF | and touch support is great | 11:15 |
| SuperMarioSF | much better than firefox does | 11:15 |
| SuperMarioSF | maybe the workaround of touchscreen on firefox can be used to solve the problem | 11:16 |
| SuperMarioSF | but I'm sticking on Chromium for now. | 11:16 |
| norayr | wow. in firefox i am using | 11:19 |
| norayr | MOZ_USE_XINPUT2=1 /usr/bin/firefox | 11:19 |
| norayr | but it became unusable on chimaera/droid. but good on pp. | 11:19 |
| SuperMarioSF | yes, I was using that env var on my other UMPCs | 11:21 |
| norayr | hexchat was a bit small for me i guess. i don't remember. or hard to configure on droid's small screen. | 11:21 |
| SuperMarioSF | it is diffcult or even unconfigurable on droid itself | 11:22 |
| SuperMarioSF | so you need some hack | 11:22 |
| SuperMarioSF | use X forwarding to forward hexchat on your desktop | 11:22 |
| SuperMarioSF | you only need this for initial configuration | 11:22 |
| SuperMarioSF | once you set up Librea.Chat and its SASL configuration, close it and launch it on droid, then you can use it normally. | 11:23 |
| SuperMarioSF | sometimes a bigger screen surely can help | 11:23 |
| SuperMarioSF | I suggest you do X forwarding with USB RNDIS, because you surely won't want a traffic intensive X forwarding on a laggy 2.4GHz WiFi. | 11:24 |
| SuperMarioSF | and I also suggest you use compression on SSH, it will be look like this | 11:25 |
| SuperMarioSF | ssh -YC user@192.168.42.2 | 11:25 |
| SuperMarioSF | if your local X server isn't a Linux desktop one (for example, a X server program on Windows), you may do `xhost +` to allow all access (danger for a proper X server), then use `ssh -XC` instead. | 11:26 |
| Wizzup | SuperMarioSF: the bugtracker is fine for this imo | 11:27 |
| SuperMarioSF | OK | 11:27 |
| SuperMarioSF | the real problem is mail client | 11:27 |
| SuperMarioSF | I use Claws Mail, and it was diffcult to setup on Droid | 11:28 |
| SuperMarioSF | You have to setup IMAP in only one go, otherwise you have to remove the account entirely and do it again. | 11:28 |
| SuperMarioSF | becase some retry option is hidden in context menu, and I have no way to access the context menu by "right click" it. | 11:29 |
| SuperMarioSF | for some reason Chromium has a proper long-press context menu support. | 11:29 |
| SuperMarioSF | but for some GTK based application it isn't there. Maybe this is a window manager thing? | 11:30 |
| SuperMarioSF | btw I installed Trojita after, it is much easy to use and have HTML mail support. | 11:31 |
| Wizzup | 11:20 < norayr> but it became unusable on chimaera/droid. but good on pp. | 11:31 |
| Wizzup | yes this is a firefox change | 11:31 |
| Wizzup | they do some dumb stuff now | 11:32 |
| Wizzup | SuperMarioSF: what's wrong with the default mail client | 11:32 |
| SuperMarioSF | I haven't seen a "default mail client" on my installation | 11:32 |
| Wizzup | try apt-get install modest | 11:33 |
| Wizzup | I think it's there in chimaera | 11:33 |
| Wizzup | (by default) | 11:33 |
| SuperMarioSF | I'm on droid right now... | 11:33 |
| Wizzup | SuperMarioSF: yep just apt-get install modest | 11:34 |
| SuperMarioSF | woah that's a lot package to install | 11:35 |
| SuperMarioSF | 90% of them are locales btw | 11:35 |
| SuperMarioSF | well... | 11:36 |
| SuperMarioSF | I installed it | 11:36 |
| SuperMarioSF | but nothing happend | 11:36 |
| SuperMarioSF | no new application, nothing in settings. | 11:36 |
| SuperMarioSF | is a reboot required? | 11:37 |
| Wizzup | I don't think so | 11:37 |
| Wizzup | the application is called 'email' | 11:37 |
| Wizzup | in settings there is no applet for it | 11:38 |
| SuperMarioSF | there is no new application on application menu | 11:38 |
| SuperMarioSF | I know that should be called "email" | 11:38 |
| Wizzup | you can try to run it from terminal, but it should auto show up if the right package triggers run | 11:38 |
| SuperMarioSF | it can show up with 'modest -s' | 11:38 |
| SuperMarioSF | I'm rebooting | 11:39 |
| SuperMarioSF | OK after a reboot it shown up | 11:41 |
| SuperMarioSF | Seems worked correctly | 11:45 |
| SuperMarioSF | attempt open a link and got "Unsupported link type" | 11:50 |
| SuperMarioSF | because it's missing a "stock default browser"? | 11:50 |
| SuperMarioSF | opening in 3rd party email client have no problem tho | 11:51 |
| Wizzup | could be, don't know :) | 11:52 |
| SuperMarioSF | well, don't mind I post too many bug report on bugtracker [emoji::rofl] | 11:54 |
| Wizzup | please do :) | 11:54 |
| freemangordon | SuperMarioSF: the url support is not email client thingie though | 11:54 |
| freemangordon | but libhildonmime | 11:54 |
| freemangordon | basically, in terms of maemo, there is no default browser | 11:55 |
| freemangordon | we shall teach it to fallback to xdg | 11:55 |
| SuperMarioSF | OK | 11:56 |
| SuperMarioSF | https://pasteboard.co/T5cgShewe0AL.png | 12:04 |
| SuperMarioSF | works great | 12:04 |
| bencoh | I was about to ask how does chromium perform on droid4? | 12:05 |
| bencoh | (since firefox became near-unusable unfortunately) | 12:05 |
| Wizzup | bencoh: did anyone file a bug with them about their poor platform gl detection? | 12:06 |
| bencoh | I didn't, I haven't tried fiddling with the code itself either | 12:06 |
| bencoh | meaning I don't really know what should be there or nt | 12:06 |
| bencoh | building firefox is a pain, even on desktop/amd64 | 12:07 |
| Wizzup | https://hg.mozilla.org/mozilla-central/rev/c1245a74819a71fdcbdf0196d65552a582d98295#l1.41 this needs to be fixed still | 12:07 |
| Wizzup | https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest.cpp#522 | 12:08 |
| bencoh | I kinda gave up on firefox and moved to qwebbrowser (whatever the spelling) tbh | 12:08 |
| bencoh | Wizzup: oh, that, true | 12:08 |
| Wizzup | I think all it needs is someone to report the bug and tell them to add __armhf__ or whatever the define is | 12:08 |
| bencoh | that'd be a start yeah | 12:08 |
| Wizzup | and of course that's not the perfect fix, but it will fix it for us | 12:08 |
| SuperMarioSF | performance wise, if there is no poorly written javascript, no ongoing media (especially videos), with adblock, it should be fine. | 12:09 |
| bencoh | I doubt it would fix it, but it would be a stat | 12:09 |
| SuperMarioSF | Chromium is usable. | 12:09 |
| Wizzup | https://bugzilla.mozilla.org/show_bug.cgi?id=1738814 this is what triggered the change | 12:09 |
| Wizzup | bencoh: I thought we tracked it down to thi schange | 12:09 |
| SuperMarioSF | usually blocked ads, and don't access something that resourse intensive (e.g. Youtube for Videos) it should be fine. | 12:10 |
| SuperMarioSF | many ads and trackers were written poorly and make a performance hit | 12:10 |
| Wizzup | anyone volunteering to file this bug? | 12:10 |
| SuperMarioSF | after a ad blocker (I'm using uBlock Origin), it is much better. | 12:11 |
| freemangordon | yes, ublock origin FTW | 12:12 |
| freemangordon | also, install user agent switched | 12:12 |
| freemangordon | *switcher | 12:12 |
| freemangordon | and pretend you are iphone6 | 12:12 |
| freemangordon | then even youtube becomes usable | 12:12 |
| SuperMarioSF | for me a proxy switcher is much more important (because, duh, China, GFW thing) | 12:12 |
| freemangordon | still, most os the sites serve lighter content if they know you are mobile device | 12:13 |
| freemangordon | *of the | 12:13 |
| SuperMarioSF | the next step for me is finding a way to access global internet. maybe I should use my eSIM. | 12:13 |
| freemangordon | btw, I had to disable hardware acceleration | 12:13 |
| SuperMarioSF | then I can just bypass any proxy | 12:14 |
| freemangordon | otherwise chromium is very choppy for me, on d4 | 12:14 |
| freemangordon | I dont; know if it is eanbled by default, I guess no | 12:14 |
| freemangordon | if it is enabled, disable it | 12:14 |
| Wizzup | I'm filing bug now with firefox | 12:15 |
| freemangordon | Wizzup: also, they somehow broke the performance badly with latest updates | 12:15 |
| freemangordon | maybe uvos have more details | 12:15 |
| SuperMarioSF | I don't think playing 720p H.264 Youtube videos without hardware acceleration is a good idea tho... | 12:15 |
| freemangordon | no, I mean chromium "use hardware acceleration' option | 12:15 |
| SuperMarioSF | ok | 12:16 |
| freemangordon | GL iow | 12:16 |
| freemangordon | use CPU rendering, not GPU | 12:16 |
| SuperMarioSF | on default settings Chromium is working fine on my d4. | 12:16 |
| freemangordon | hmm | 12:16 |
| freemangordon | so I guess it is not using GL | 12:16 |
| freemangordon | could you confirm? | 12:16 |
| SuperMarioSF | if it is choppy I still use it because it saves on battery. | 12:16 |
| SuperMarioSF | ... how? | 12:16 |
| freemangordon | in settings | 12:16 |
| freemangordon | search for "hard" | 12:17 |
| Wizzup | freemangordon: do we know when it broke? | 12:18 |
| SuperMarioSF | Use hardware acceleration when available: ON | 12:18 |
| Wizzup | freemangordon: the hw accel I mean | 12:18 |
| SuperMarioSF | it was enabled | 12:18 |
| Wizzup | in firefox | 12:18 |
| freemangordon | SuperMarioSF: hmm... | 12:18 |
| freemangordon | could you disable, restart chromium and test if it still the same? | 12:18 |
| SuperMarioSF | OK | 12:19 |
| freemangordon | there was chromium update a day or 2 ago, maybe they fixed something | 12:19 |
| * freemangordon checks | 12:19 | |
| Wizzup | https://bugzilla.mozilla.org/show_bug.cgi?id=1812016 | 12:20 |
| Wizzup | bencoh: freemangordon: uvos ^^ | 12:20 |
| freemangordon | Wizzup: I am not sure they broke HW acceleration or COU rendering | 12:21 |
| SuperMarioSF | disabled hw accel, and it was a bit choopy | 12:21 |
| freemangordon | *CPU | 12:21 |
| SuperMarioSF | not that obvious tho | 12:21 |
| Wizzup | freemangordon: in any case that code is obviously wrong | 12:21 |
| freemangordon | right | 12:21 |
| freemangordon | SuperMarioSF: is that d4? | 12:21 |
| SuperMarioSF | yes, it is a d4, on -devel | 12:21 |
| freemangordon | ah, this is beowulf | 12:21 |
| Wizzup | freemangordon: and I see the exact error in their code | 12:21 |
| Wizzup | as in | 12:21 |
| Wizzup | record_error("GLX extension missing"); | 12:21 |
| Wizzup | $ firefox-esr -P | 12:22 |
| Wizzup | [GFX1-]: glxtest: eglCreateContext returned an error | 12:22 |
| Wizzup | [GFX1-]: glxtest: GLX extension missing | 12:22 |
| freemangordon | so you are without GPU rendering no matter the setting | 12:22 |
| freemangordon | Wizzup: yeah, I know | 12:22 |
| freemangordon | and agree | 12:22 |
| Wizzup | freemangordon: ok, so clearly this code is active and a problem :P | 12:22 |
| SuperMarioSF | I guess enable hw accel did nothing | 12:22 |
| freemangordon | SuperMarioSF: right | 12:22 |
| freemangordon | we have fixes in chimaera that actually allow chromium to enable GPU rendering | 12:22 |
| Wizzup | freemangordon: uvos: I think we should decide if we release chimaera soon and just without elogind support initially, it is becoming more of a nuisance to support both IMO | 12:23 |
| SuperMarioSF | oh, about elogind | 12:23 |
| SuperMarioSF | I was attempt installing kleopatra | 12:23 |
| freemangordon | Wizzup: I have no enough expertise to decide | 12:23 |
| freemangordon | so up to you to decide | 12:24 |
| Wizzup | freemangordon: "it works", but many packages are not installable | 12:24 |
| freemangordon | I know | 12:24 |
| Wizzup | like blueman (the gtk3 bluetooth manager) | 12:24 |
| freemangordon | and gparted and whatnot | 12:24 |
| SuperMarioSF | and it had package dependency problem in elogind | 12:24 |
| Wizzup | I think it's not about expertise, it's about what we want to communicate to others :) | 12:24 |
| SuperMarioSF | on -devel droid | 12:24 |
| freemangordon | me PR?!? | 12:24 |
| freemangordon | :p | 12:24 |
| Wizzup | SuperMarioSF: yes, we also block elogind on beowulf, but there less pkgs depends on it | 12:24 |
| Wizzup | anything that directly depends on elogind is currently a no-no everywhere on leste | 12:25 |
| Wizzup | freemangordon: well we can look into allowing elogind to start without it negatively affecting the system, many apps don't truly depend on it running for example | 12:25 |
| Wizzup | that would be a stop gap I guess | 12:25 |
| Wizzup | either that or we go full tinydm session | 12:25 |
| SuperMarioSF | maybe elogind is just providing some session related thing for those apps | 12:26 |
| SuperMarioSF | for kleopatra it may because KDE related thing | 12:26 |
| Wizzup | it doesn't just 'provide' that, but it also 'provides' a broken experience, i.e. pressing the power button will shut down the phone with elogind installed | 12:26 |
| Wizzup | and it will also cause chimaera phones to get bricked a boot to a black screen | 12:27 |
| freemangordon | Wizzup: is it dbus service? | 12:27 |
| Wizzup | so there's a bunch of work to do there, and like I said there's two immediate ways forward | 12:27 |
| Wizzup | freemangordon: it's a systemd thing, so it's everything | 12:27 |
| SuperMarioSF | [emoji::rofl] Oh that is a broken one indeed | 12:27 |
| Wizzup | freemangordon: jokes aside, it seems to take over from consolekit and other similar login tracking programs | 12:27 |
| Wizzup | like, this is the thing that on servers will kill all your processes if you log out from ssh | 12:28 |
| Wizzup | no matter if you run them in screen or whatever | 12:28 |
| freemangordon | can't we just add Provides: elogind to one of our metas? | 12:28 |
| freemangordon | and call it a day? | 12:28 |
| Wizzup | lol, we could try, that's option (2) | 12:28 |
| Wizzup | option (1) was trying to make a elogind compatible session eventually | 12:28 |
| Wizzup | maybe it's not a bad short term "solution" | 12:29 |
| freemangordon | 2 is not really an option | 12:29 |
| freemangordon | but a short-term workaraound | 12:29 |
| freemangordon | the only option is 1 | 12:29 |
| Wizzup | right, we might be in for a whole bunch of brokenness down the line | 12:29 |
| freemangordon | but, in order to release | 12:29 |
| SuperMarioSF | provide a elogind package do absolutely nothing [emoji::rofl] the problem is what if elogind is actually being needed? | 12:29 |
| Wizzup | but I'll try it | 12:29 |
| freemangordon | right | 12:29 |
| Wizzup | SuperMarioSF: right | 12:29 |
| freemangordon | SuperMarioSF: I really don;t see how a package like gparted (or blueman) would require anything from alogind | 12:30 |
| freemangordon | it is like a cancer to me, this systemd ideology | 12:30 |
| Wizzup | the idea of tracking programs within a desktop session makes some sense to me, it's just too bad that gnome and everyone under the sun immediately depend on it | 12:31 |
| Wizzup | brb | 12:31 |
| freemangordon | sicelo: SuperMarioSF: the is a new ofono plugin in -devel repo, please upgrade | 12:46 |
| freemangordon | sicelo: I will appreciate if you test that new plugin from scratch, like reset iap/context/etc, including APN change | 12:47 |
| freemangordon | this pugin shall fix the APN change issue | 12:47 |
| sicelo | cool. in evening i can try | 12:47 |
| freemangordon | ok, thanks | 12:47 |
| freemangordon | Wizzup: I am not sure this commit is the reason for bad performance | 12:56 |
| freemangordon | but I cannot find the video that uvos posted on YT | 12:56 |
| Wizzup | freemangordon: well for sure firefox no longer uses gpu accel | 12:56 |
| freemangordon | I will wait for him top appear | 12:56 |
| freemangordon | I am not sure it ever used | 12:56 |
| freemangordon | because if you look at the commit, they changed from #define to a variable | 12:57 |
| freemangordon | to my understanding | 12:57 |
| freemangordon | https://hg.mozilla.org/mozilla-central/rev/c1245a74819a71fdcbdf0196d65552a582d98295#l1.69 | 12:57 |
| Wizzup | no | 12:57 |
| Wizzup | before it would always try gles | 12:57 |
| Wizzup | freemangordon: oh | 12:58 |
| Wizzup | freemangordon: well maybe it was wrong before then :) | 12:58 |
| freemangordon | mhm :) | 12:58 |
| Wizzup | but I know it used to work for sure | 12:58 |
| freemangordon | so, we have 2 issues | 12:58 |
| freemangordon | one is that gles never worked on armhf | 12:58 |
| freemangordon | the other being: unusable performance since some update | 12:59 |
| freemangordon | I think it was 6x->7x | 12:59 |
| freemangordon | but not sure | 12:59 |
| freemangordon | I think uvos has details | 12:59 |
| freemangordon | not saying gl detection shall not be fixed | 12:59 |
| freemangordon | just that I think it will not fix the performance issue | 13:00 |
| Wizzup | ok | 13:00 |
| Wizzup | maybe it will if they use the gpu sw render as 'hw accel' :) | 13:00 |
| freemangordon | ah | 13:00 |
| freemangordon | llvmpipe? | 13:00 |
| freemangordon | I think they blacklist that explicitly | 13:01 |
| freemangordon | but yeah | 13:01 |
| freemangordon | at least I recovered my bugzilla account :) | 13:01 |
| freemangordon | ttyl | 13:02 |
| Wizzup | for sure in 2021 there was no 'useGles' | 13:07 |
| freemangordon | Wizzup: going to bisect esr versions in debian repo | 13:45 |
| bencoh | freemangordon: yeah, I checked again after discussing with uvos, and firefox 78 worked decently (even though gl accel did not work), and it got unusable later | 13:45 |
| freemangordon | firefox-esr_78.15.0esr-1~deb10u1_armhf.deb scrolls like butter | 13:46 |
| bencoh | I know 78 is okay, and 93 is unusable | 13:46 |
| freemangordon | right | 13:46 |
| freemangordon | will check the next one | 13:46 |
| bencoh | I dunno if there is a next-one available in repos | 13:46 |
| freemangordon | 91 | 13:47 |
| bencoh | oh, they kept it around? | 13:47 |
| freemangordon | http://ftp.debian.org/debian/pool/main/f/firefox-esr/?C=S;O=D | 13:47 |
| freemangordon | maybe you mean 91, not 93? | 13:47 |
| bencoh | ah, 83 is there too | 13:48 |
| bencoh | hmm, maybe | 13:48 |
| bencoh | lemme check | 13:48 |
| freemangordon | where do you see 83? | 13:48 |
| bencoh | http://ftp.fr.debian.org/debian/pool/main/f/firefox/ | 13:48 |
| bencoh | uhwait, the only 83 deb is for mipsel? | 13:49 |
| freemangordon | this is not esr | 13:49 |
| bencoh | yeah I know | 13:49 |
| freemangordon | but yeah | 13:49 |
| freemangordon | should not matter | 13:49 |
| bencoh | yeah, 91.11 is the one I tried apparently | 13:50 |
| freemangordon | lemme check in on mozilla-central | 13:50 |
| freemangordon | hmm, they don't build for arm :( | 13:51 |
| freemangordon | Wizzup: I wonder if your bug is valid | 13:52 |
| freemangordon | maybe they don;t support armhf on desktop ;) | 13:52 |
| freemangordon | OTOH, the code is still wrong | 13:52 |
| freemangordon | they don;t support anything desktop arm | 13:56 |
| freemangordon | how nice :( | 13:56 |
| Wizzup | freemangordon: what makes you say this? | 13:59 |
| freemangordon | look at the builds | 13:59 |
| freemangordon | they == mozilla | 13:59 |
| freemangordon | see https://bugzilla.mozilla.org/show_bug.cgi?id=1677963 as well | 14:00 |
| sicelo | Wizzup: logind & power button - shutdown is configurable | 14:00 |
| Wizzup | I know it is | 14:00 |
| sicelo | 🤙 | 14:01 |
| rafael2k | https://www.abradig.org.br/maemo-crazyness/pinhole-kirigami-maemo.jpg | 14:36 |
| rafael2k | packaged | 14:36 |
| Wizzup | great :) | 14:37 |
| Wizzup | the amd64 pkg failed | 14:37 |
| Wizzup | I think the source part might need a Section: | 14:38 |
| Wizzup | uvos: does sphone exit ok for you with the qtloop? | 15:12 |
| Wizzup | it segfaults for me in glib poll | 15:13 |
| uvos__ | Wizzup: it def used to | 15:18 |
| uvos__ | Wizzup: dose it still do that if you dont load any qt modules? | 15:18 |
| Wizzup | let me try | 15:18 |
| Wizzup | if I don't load comm-telepathy it still does it | 15:19 |
| uvos__ | ok | 15:19 |
| uvos__ | thats new | 15:19 |
| uvos__ | it dosent do it on beowulf | 15:19 |
| uvos__ | it seams | 15:19 |
| Wizzup | freemangordon: mozilla folk seem helpful :) | 15:22 |
| Wizzup | https://bugzilla.mozilla.org/show_bug.cgi?id=1812016 | 15:23 |
| uvos__ | "prefer GLES on armhf as well." | 15:33 |
| uvos__ | this is so silly i cant even | 15:34 |
| uvos__ | what dose the installed gpu have to do with the cpu arch | 15:34 |
| Wizzup | :) | 15:38 |
| SuperMarioSF_ | freemangordon: so is there some documents about how to reset IAP/context/something else? | 15:43 |
| SuperMarioSF_ | btw I guess I need a GUI gconf editor | 15:43 |
| Wizzup | uvos__: btw I do think it's not harful to try gles first | 15:47 |
| Wizzup | harmful* | 15:47 |
| Wizzup | uvos__: the contacts resolving can maybe be done based on schema | 15:53 |
| Wizzup | currently my tp module exports 'tel' only | 15:53 |
| Wizzup | but I imagine that might need to be amended with sip | 15:53 |
| Wizzup | and/or xmpp | 15:53 |
| uvos__ | Wizzup: sure maybe, but currently we know what sheme what backend can do | 16:04 |
| uvos__ | but not what sheme what call is | 16:04 |
| uvos__ | and then we would still need some big table that converts shemes to vcf fields | 16:04 |
| Wizzup | I think we can just do what fremantle does | 16:05 |
| Wizzup | it seems to work fine | 16:05 |
| uvos__ | and then a table that converts vcf fields to ebook fileds | 16:05 |
| uvos__ | whats that? | 16:05 |
| Wizzup | not sure :) | 16:05 |
| Wizzup | freemangordon might have a good idea | 16:05 |
| uvos__ | anyhow i dont like tis | 16:05 |
| uvos__ | the backend should just specify what vcf fields it wants | 16:06 |
| Wizzup | so move the table to the backend? | 16:06 |
| Wizzup | fine by me | 16:06 |
| uvos__ | sure eatch backed sais what fields it wants contacts to match too | 16:06 |
| uvos__ | and a vcf field -> ebook table is then in the ebook module | 16:07 |
| Wizzup | I don't know what they are in the ebook module | 16:07 |
| uvos__ | that probubly exists allready anyhow | 16:07 |
| uvos__ | ? | 16:07 |
| Wizzup | hm? | 16:07 |
| uvos__ | "I don't know what they are in the ebook module" | 16:07 |
| uvos__ | makes no sese to me | 16:07 |
| uvos__ | what what is | 16:08 |
| Wizzup | I mean I don't know what the fields names or prefixes are | 16:09 |
| Wizzup | in any case I'm happy to mod the module for this | 16:12 |
| uvos__ | ok | 16:12 |
| uvos__ | well we need to add the interface to comm first | 16:13 |
| uvos__ | something like enum { vcf fields } and then a list of vcf enums to the backend register function | 16:14 |
| uvos__ | then the ebook module can grab the list for the backend for the call | 16:14 |
| uvos__ | and match based on those fields | 16:14 |
| Wizzup | ok | 16:17 |
| freemangordon | we already have such enum | 16:22 |
| freemangordon | we have ECard basically | 16:22 |
| freemangordon | that is vcf | 16:22 |
| freemangordon | can't find any online eds documentation :( | 16:23 |
| uvos__ | yes but that requires you to have eds installed | 16:23 |
| uvos__ | sphone dose not require eds | 16:23 |
| Wizzup | ugh | 16:23 |
| uvos__ | so you cant use its headers in core | 16:23 |
| freemangordon | so, sphone carries everything and the kitchen sink? its own contacts db, etc? | 16:24 |
| uvos__ | no | 16:24 |
| uvos__ | but everythin is contained in the modules | 16:24 |
| uvos__ | and functionalitiy degrades gracefull when a dependancy is missing | 16:25 |
| freemangordon | oh, it is EVCard | 16:25 |
| freemangordon | see https://developer-old.gnome.org/eds/stable/EVCard.html | 16:25 |
| Wizzup | there is a evolution module | 16:25 |
| freemangordon | "Types and Values" | 16:25 |
| uvos__ | yes exactly | 16:26 |
| freemangordon | so, who is going to parse vcf files? | 16:26 |
| uvos__ | and only the evolution module may depend on evolution | 16:26 |
| freemangordon | if there is no evolution? | 16:26 |
| uvos__ | no one is parsing vcf files | 16:26 |
| freemangordon | I see | 16:26 |
| uvos__ | some other module that parses vcf fiels | 16:26 |
| uvos__ | the point is that the evolution module may be replaced | 16:26 |
| uvos__ | with no changes to the other modules | 16:26 |
| uvos__ | thats the whole point of sphones architecture | 16:27 |
| freemangordon | I understand that, but what I don;t understand is how such a module (supporting some form of contacts import/export) is not mandatory | 16:27 |
| uvos__ | this isent about contacts import or export | 16:27 |
| Wizzup | we can make it mandatory for us | 16:27 |
| uvos__ | its about what fields to use to match a contact | 16:28 |
| uvos__ | to a call | 16:28 |
| uvos__ | and vice versa | 16:28 |
| freemangordon | I think we are rediscovering the hot water | 16:28 |
| uvos__ | not really | 16:28 |
| freemangordon | everybody is using vcf | 16:29 |
| freemangordon | and you have UID tehre | 16:29 |
| freemangordon | *there | 16:29 |
| Wizzup | I think the way to see it is that sphone sees the concept of contacts as optional | 16:29 |
| uvos__ | dutr | 16:29 |
| uvos__ | sure | 16:29 |
| uvos__ | but we get a call | 16:29 |
| uvos__ | we only know the number or sip handle or whatsapp username or whatever from that call | 16:29 |
| uvos__ | we need to figure out what contact this call is comeing from | 16:29 |
| freemangordon | Wizzup: I understand that, but that's some academic approach I am not sure is the best | 16:30 |
| uvos__ | no uuids help us here | 16:30 |
| uvos__ | we need to know what the backend the specific inceoming string iding the call | 16:30 |
| uvos__ | corrisponds to in terms of contact fields | 16:30 |
| freemangordon | uvos__: if you assume that vcf UID is the common denominator for all plugins, then you can use it | 16:30 |
| uvos__ | thats all | 16:30 |
| uvos__ | no i can not | 16:30 |
| uvos__ | its physicly impossible to get a cellular call | 16:30 |
| uvos__ | and magicly get some id from that | 16:31 |
| uvos__ | you only get a phone number | 16:31 |
| uvos__ | from the modem | 16:31 |
| freemangordon | why? you can ask ads (or whatever backend) to give you the UID for that phone | 16:31 |
| uvos__ | _thats_ where we are at | 16:31 |
| freemangordon | *eds | 16:31 |
| uvos__ | yes | 16:31 |
| Wizzup | uvos__: unrelated, how do you hold and re-activate calls in sphone | 16:31 |
| uvos__ | but sphone dosent know that the string its getting from a backend IS a phone number | 16:32 |
| uvos__ | thats all this is about | 16:32 |
| uvos__ | add ing a way the backend can tell sphone what the incoeming line id is | 16:32 |
| freemangordon | ok, maybe then sphone can provide an interface based on EVCard attributes (I hate to say it, but maybe duplicate those defines) | 16:33 |
| uvos__ | Wizzup: well you press hold on a call | 16:33 |
| Wizzup | uvos__: like how does the hold trigger communicate if it should hold or release | 16:33 |
| uvos__ | Wizzup: and then you press hold again to activate | 16:33 |
| uvos__ | but it dosent work | 16:33 |
| uvos__ | beacuse it dosent work on d4 ofono | 16:34 |
| uvos__ | so no backend currently implements call holding | 16:34 |
| uvos__ | so its also untested | 16:34 |
| Wizzup | the remove party can also put you on hold | 16:34 |
| Wizzup | remote* | 16:34 |
| uvos__ | sure but holding just dosent work at all | 16:34 |
| uvos__ | atm | 16:34 |
| uvos__ | we dont get holding information form either end from ofono | 16:34 |
| uvos__ | (ps if a backend did know the rmote party put us on hold it would just push that call down the pipe itself) | 16:35 |
| uvos__ | freemangordon: yes thats exactly the plan | 16:37 |
| freemangordon | ugly, but yeah, might work | 16:37 |
| Wizzup | uvos__: what? | 16:37 |
| uvos__ | freemangordon: and the eds module then uses that information to match the right contact | 16:37 |
| uvos__ | and tell the rest of sphone about it | 16:37 |
| uvos__ | Wizzup: [16:33] <freemangordon> ok, maybe then sphone can provide an interface based on EVCard attributes (I hate to say it, but maybe duplicate those defines) | 16:37 |
| Wizzup | uvos__: no, I mean, 'push that call down the pipe itself' ? | 16:37 |
| Wizzup | I can definitely detect hold of remote party in telepathy-ring | 16:38 |
| Wizzup | but I don't know how I put someone on hold since I don't see the button for it | 16:38 |
| freemangordon | uvos__: BTW, do you still have a link to that FF d4 video around? | 16:38 |
| uvos__ | backend finds out call goes on hold | 16:38 |
| Wizzup | and the trigger only allows to put something on hold, it doesn't allow for killing the hold | 16:38 |
| uvos__ | backend pushes that call down the hold pipe | 16:38 |
| Wizzup | yes, that's for the remote party | 16:38 |
| Wizzup | but you can also put the other side on hold yourself | 16:38 |
| uvos__ | ui wants a hold | 16:38 |
| uvos__ | ui pushes the call down the hold pipe | 16:38 |
| uvos__ | its that simple | 16:38 |
| Wizzup | I don't need the hold pipe to push hold down the pipe, I can use &call_properties_changed_pipe for that | 16:39 |
| Wizzup | uvos__: ok, but as a user, how do I do that now? | 16:39 |
| uvos__ | theres a hold button | 16:39 |
| uvos__ | hmm maybe i hid it | 16:39 |
| Wizzup | ok, and where is the unhold? | 16:39 |
| uvos__ | because it dosent work with ofono | 16:39 |
| Wizzup | since the hold trigger doesn't allow specifying hold:TRUE or hold:FALSE | 16:39 |
| uvos__ | Wizzup: same button | 16:39 |
| uvos__ | Wizzup: just changes its text | 16:39 |
| Wizzup | ok, but the backend doesn't know if you want to hold or not | 16:39 |
| Wizzup | I can store that info locally in the backend per call of course | 16:40 |
| uvos__ | sure it dose | 16:40 |
| uvos__ | yes the backend is expected to have a list of calls | 16:40 |
| uvos__ | anyhow this holding thing is untested and maybe half implemented (dont remember) | 16:41 |
| Wizzup | I'd like to implement it | 16:41 |
| uvos__ | since it dident work in ofono it stoped working on it | 16:41 |
| Wizzup | when was this? | 16:41 |
| uvos__ | when i started working on sphone :P | 16:41 |
| uvos__ | since you are the first backend to implement holding if it makes your code easier | 16:42 |
| uvos__ | you can also add a new unhold pipe | 16:42 |
| uvos__ | and just change to ui to call the right one depending on the state of the currently selected call | 16:43 |
| uvos__ | in the active calls list | 16:43 |
| Wizzup | let's assume it works in ofono | 16:43 |
| Wizzup | I guess call->state can be used in the hold function | 16:43 |
| Wizzup | it just seems more clear to have an un-hold somehow | 16:43 |
| uvos__ | if you like | 16:44 |
| uvos__ | freemangordon: this one? http://uvos.xyz/maserati/videos/firefox-demonstration.mp4 | 16:45 |
| uvos__ | heh bbc page dates this hevily | 16:46 |
| uvos__ | this is also ddk1.9 | 16:46 |
| uvos__ | so ff is slightly underperforming here | 16:46 |
| uvos__ | theres also one with bionic | 16:47 |
| uvos__ | http://uvos.xyz/maserati/videos/IMGP0534.m4v | 16:47 |
| freemangordon | do you have a video with FF performing better? I want to add the link to the bug on bugzilla | 16:47 |
| uvos__ | freemangordon: no | 16:48 |
| uvos__ | but i mean it perfomes fine here | 16:48 |
| uvos__ | ddk1.17 is only slightly better | 16:48 |
| freemangordon | ok | 16:48 |
| freemangordon | thanks | 16:48 |
| Wizzup | uvos__: I will try to submit a PR today for the comm-telepathy module | 16:52 |
| Wizzup | I'm sure you'll have some comments | 16:52 |
| uvos__ | for one thing | 16:53 |
| uvos__ | if your module is larger than one source file | 16:53 |
| uvos__ | put it in a folder please | 16:53 |
| Wizzup | ok | 16:54 |
| Wizzup | and for a hildonized gtk, another module? | 16:57 |
| freemangordon | wow, "Patches submitted 14" :) | 16:59 |
| freemangordon | when did I do that? | 17:00 |
| Wizzup | uvos__: btw for local testing with sphone the modules in another dir breaks the working of sphone | 17:12 |
| Wizzup | I had to make symlinks for modules in nested dirs | 17:12 |
| uvos__ | Wizzup: what hildonized gtk? | 17:13 |
| uvos__ | Wizzup: the current ui dose use some hildon functions (optionally) | 17:13 |
| Wizzup | ui module that makes it behave like maemo/fremantle | 17:13 |
| Wizzup | stacked windows | 17:13 |
| Wizzup | rtcom log | 17:13 |
| uvos__ | the windows are stacked | 17:14 |
| uvos__ | byw this is a problem | 17:14 |
| uvos__ | as libhildon supports only one stack per process | 17:14 |
| uvos__ | but sphone really needs 2 | 17:14 |
| uvos__ | and this causes some strange behavior | 17:14 |
| bencoh | debian/rules:236: *** Unfortunately cannot build on armhf. Try a 64-bits kernel. Stop. | 17:14 |
| freemangordon | what? | 17:15 |
| bencoh | that's when trying to build firefox from debian's git | 17:15 |
| Wizzup | uvos__: we only need main window with rtcom log, contacts, and dialer button, and dialer window on top of it, and on top of that the call window | 17:15 |
| Wizzup | the sms stuff will be handled by conversations with tp module | 17:15 |
| bencoh | either my builder borked the build system, or ... I'm missing something | 17:15 |
| uvos__ | Wizzup: thats nice that its handled by conversations | 17:15 |
| freemangordon | bencoh: maybe try apt-get source | 17:16 |
| uvos__ | but that has no bearing on sphone | 17:16 |
| bencoh | freemangordon: yeah I'll try that | 17:16 |
| Wizzup | it does on sphone in leste :p | 17:16 |
| uvos__ | and sphone must continue to support messages | 17:16 |
| uvos__ | sure but you may not break it | 17:16 |
| freemangordon | I don;t think it is a good idea to have 2 sms apps active in parallel | 17:17 |
| uvos__ | sphone is modular | 17:17 |
| freemangordon | so as soon as we have conversations, I think disabling sphone hildon module for sms makes sense | 17:17 |
| uvos__ | you need not load those modules | 17:17 |
| uvos__ | still you may not break them | 17:17 |
| uvos__ | and the windows are stacked | 17:17 |
| freemangordon | so, what is the issue? how to show smsm while in a call? | 17:18 |
| freemangordon | *sms | 17:18 |
| uvos__ | its just that the sms and dialer windows are stacked on top of eatch other | 17:18 |
| uvos__ | because of hildon limitations | 17:18 |
| uvos__ | so idk what wizzup wants to change | 17:18 |
| freemangordon | the main window, iiuc | 17:18 |
| freemangordon | a side question: how am I supposed to use MESA_EXTENSION_OVERRIDE? | 17:19 |
| freemangordon | MESA_EXTENSION_OVERRIDE="-EGL_CHROMIUM_sync_control" eglinfo still returns EGL_CHROMIUM_sync_control | 17:20 |
| Wizzup | uvos__: hence a new module | 17:20 |
| Wizzup | so then on leste we load what we want | 17:20 |
| Wizzup | and on non-leste it uses other modules | 17:20 |
| uvos__ | im still not sure what you want | 17:21 |
| uvos__ | make the recens dialog the main window? | 17:21 |
| uvos__ | essetally? | 17:21 |
| uvos__ | hard no, the dailer should be the first window | 17:21 |
| Wizzup | then we must fork... | 17:21 |
| Wizzup | we can just make a new ui module, seems easiest to me | 17:22 |
| uvos__ | why would you want recents as the first window... | 17:22 |
| uvos__ | even contacts would make more sense | 17:22 |
| Wizzup | it's what fremantle does, and it makes so much sense, I use it *all* the time | 17:22 |
| Wizzup | android does the same | 17:23 |
| uvos__ | not really | 17:23 |
| uvos__ | android has both one window | 17:23 |
| uvos__ | wich is fine | 17:23 |
| uvos__ | (and is incedentally how sphone used to work) | 17:23 |
| Wizzup | almost like a stacked window with a dialer button :P | 17:23 |
| uvos__ | not really | 17:24 |
| freemangordon | uvos__: from UX POV, what is the idea of having a dialer on the first window? | 17:26 |
| freemangordon | how often you dial numbers, compared to redialing a contact or selecting a contact from a list | 17:26 |
| uvos__ | you place a phone call you dial a number | 17:26 |
| uvos__ | all the time | 17:26 |
| freemangordon | no | 17:26 |
| freemangordon | you dial a contact | 17:26 |
| Wizzup | I literally never do this unless it's some number I don't know | 17:26 |
| uvos__ | but yes i do use contacts more often | 17:26 |
| uvos__ | but not recents | 17:26 |
| uvos__ | recents makes little sense | 17:26 |
| freemangordon | not really | 17:27 |
| rafael2k | Wizzup, harbour-pinhole pkg build fixed! | 17:27 |
| Wizzup | recent is 90% of my calls | 17:27 |
| freemangordon | mine too | 17:27 |
| Wizzup | also great for calling someone back | 17:27 |
| freemangordon | but close to 95 maybe | 17:27 |
| Wizzup | when you missed the call | 17:27 |
| freemangordon | exactly | 17:27 |
| uvos__ | when you missed a call it takes you straigt there | 17:27 |
| uvos__ | so no change tehre | 17:27 |
| freemangordon | what if you have 3 missed calls? | 17:27 |
| Wizzup | no, only when you keep that window open | 17:27 |
| uvos__ | freemangordon: what then? | 17:28 |
| uvos__ | recents is longer than 3 calls | 17:28 |
| uvos__ | Wizzup: so? | 17:28 |
| freemangordon | yes, but you have everything ordered by time of the (missed) call | 17:28 |
| uvos__ | so? not sure what you expect to happen when you click on a missed call | 17:29 |
| uvos__ | it takes you to the call in the list | 17:29 |
| uvos__ | thats all | 17:29 |
| freemangordon | uvos__: sure, we can do it so you are required to solve a puzlle to be able to call back, but that's not user friendly | 17:30 |
| uvos__ | ? | 17:30 |
| uvos__ | you click on the missed call notification it takes you to the call in the lst | 17:30 |
| freemangordon | clicking on a missed call shall bring you to the selection of what you want to do: | 17:30 |
| uvos__ | you click on that, it enters the number | 17:30 |
| freemangordon | no | 17:30 |
| uvos__ | for you to then click call | 17:30 |
| uvos__ | how is that a puzzle | 17:31 |
| freemangordon | no, you may not want to call back, but instead to do sms | 17:31 |
| freemangordon | or call back via sip | 17:31 |
| freemangordon | etc | 17:31 |
| Wizzup | yup | 17:31 |
| bencoh | on fremantle it just takes to you the recent calls list | 17:31 |
| freemangordon | right | 17:32 |
| uvos__ | on sphone exactly the same | 17:32 |
| Wizzup | no, it takes you to dialer | 17:32 |
| freemangordon | but clicking on an entry in the recent calls does not bring the dialer | 17:32 |
| freemangordon | no | 17:32 |
| uvos__ | Wizzup: no it dosent | 17:32 |
| Wizzup | the phone icon takes you to dialer | 17:32 |
| uvos__ | clicking on the entry DOSE bring the dialer | 17:32 |
| Wizzup | this is silly | 17:32 |
| freemangordon | it asks what to do: call or sms | 17:32 |
| uvos__ | where you can then choose the backend | 17:32 |
| * Wizzup takes a break | 17:33 | |
| Wizzup | we want our phone to be one icon | 17:33 |
| freemangordon | agree | 17:33 |
| uvos__ | the only thing in sphone it is annoying to sms someone who you missed a call of | 17:33 |
| uvos__ | but thats a easy fix | 17:33 |
| freemangordon | I don;t think it is that easy | 17:33 |
| uvos__ | just add a way to message a entry in the recents list | 17:33 |
| freemangordon | if you don't integrate with addressbook | 17:33 |
| bencoh | basically on fremantle clicking a missing call entry brings up the contact card | 17:33 |
| freemangordon | exactly | 17:33 |
| sicelo | freemangordon: libicd-network-ofono 1.1.0+2m7 ? looks like it still doesn't save apn in context | 17:34 |
| freemangordon | umm | 17:34 |
| freemangordon | did I forget to do something? | 17:34 |
| sicelo | perhaps :-) | 17:35 |
| freemangordon | ah, in th econtext | 17:35 |
| freemangordon | but at least it finds the correct context, no? | 17:35 |
| freemangordon | if you change the apn that is | 17:35 |
| sicelo | not sure i understand ... there's still one context | 17:36 |
| sicelo | which doesn't have apn | 17:36 |
| freemangordon | yes, but you edit from the settings | 17:36 |
| freemangordon | and enter some apn | 17:36 |
| freemangordon | this apn is not saved to context for some reason, but is set on iap, correct? | 17:36 |
| sicelo | yes. and this apn from settings doesn't make it to the ofono context. that one still has no apn | 17:36 |
| freemangordon | ok, that's another bug then :) | 17:37 |
| freemangordon | so, is it set on iap? | 17:37 |
| sicelo | yes it exists in iap | 17:37 |
| freemangordon | great | 17:37 |
| freemangordon | so I must have forgotten to set it to the context | 17:37 |
| freemangordon | ok, will fix that, thanks for reporting | 17:38 |
| sicelo | freemangordon: sorry if i wasn't clear before (some days ago) - i actually originally meant the apn doesn't get set on the ofono context itself | 17:38 |
| sicelo | great :-) | 17:38 |
| freemangordon | yes, but back then it was unable to find the contaxt when apn was changed, no? | 17:39 |
| freemangordon | and now it finds it, it is just that apn (and user/pwd perhaps in that regard) arte not set back | 17:39 |
| freemangordon | correct? | 17:39 |
| sicelo | i am not sure. let me explain | 17:39 |
| freemangordon | no need | 17:40 |
| freemangordon | I think I know what the issue is | 17:40 |
| sicelo | ah yes, correct. i misread | 17:40 |
| freemangordon | ok, great | 17:40 |
| freemangordon | hopefully tomorrow I will fix that | 17:40 |
| sicelo | thanks. no rush | 17:41 |
| * sicelo has no time these days ... but can test, as long as it takes no more than 30 mins :-) | 17:42 | |
| rafael2k | I was playing with whatsmeow... it is pretty easy to use | 17:45 |
| rafael2k | I just needed to get used to go | 17:45 |
| rafael2k | btw, for people in amd64, harbour-pinhole should work on any platform with proper camera drivers | 17:46 |
| rafael2k | Get:7 https://pkgmaster.devuan.org/merged chimaera-security/main arm64 linux-headers-arm64 arm64 5.10.162-1 [1,180 B] | 17:56 |
| rafael2k | this is strange | 17:56 |
| rafael2k | anyway, it seems all good | 17:59 |
| Wizzup | rafael2k: we can try to use whatsmeow for tp, but if it requires whatsapp web it will always require some android or ios device | 18:03 |
| Wizzup | whatsapp/facebook will be forced to offer an api per new eu law | 18:04 |
| Wizzup | so we can wait that one out maybe | 18:04 |
| bencoh | yeah, whatsmeow's howto recommends using the android sdk emulator and passthrough a webcam | 18:06 |
| bencoh | which is nice but not enough | 18:06 |
| sicelo | Wizzup: really? what law is that? | 18:08 |
| Wizzup | sicelo: will need to look it up | 18:08 |
| Wizzup | it's the gatekeeper one | 18:09 |
| Wizzup | requiring interoperability | 18:09 |
| Wizzup | in car atm | 18:09 |
| bencoh | something tells me they'll still find a way to keep some kind of "auth" ("to prevent spam, of course") | 18:09 |
| Wizzup | we'll see | 18:11 |
| Wizzup | auth is ok | 18:11 |
| Wizzup | as long as it doesn't require nonfree crap | 18:11 |
| Wizzup | imo | 18:11 |
| bencoh | yeah, but .... | 18:11 |
| bencoh | well, we'll see :) | 18:12 |
| SuperMarioSF_ | oops | 18:12 |
| SuperMarioSF_ | I made a mistake | 18:12 |
| SuperMarioSF_ | SIM card is not recognized after a battery swap | 18:12 |
| SuperMarioSF_ | I don't know why | 18:12 |
| SuperMarioSF_ | but I can sure SIM card itself is working correctly | 18:12 |
| bencoh | I failed building firefox from apt-get source as well btw, even after bypassing the armhf/arm64 thing, I still get a stupid python stacktrace and "Permission denied" at the end of the configure process | 18:13 |
| bencoh | Wizzup: you might want to try building on the arm64 boards | 18:13 |
| SuperMarioSF_ | It's time for a big brain solution: I'm gonna use my another d4. I'm gonna transplant the working screen on my broken d4 to my another working d4 | 18:14 |
| bencoh | uh | 18:14 |
| SuperMarioSF_ | my another working d4 having a broken screen | 18:14 |
| bencoh | how would a battery swap affect the SIM module though? | 18:15 |
| SuperMarioSF_ | I wonder that. | 18:15 |
| SuperMarioSF_ | It doesn't even connected together. | 18:15 |
| SuperMarioSF_ | maybe I used too much force lifting battery and breaked baseband somehow | 18:15 |
| SuperMarioSF_ | this time I will be careful. | 18:16 |
| SuperMarioSF_ | well | 18:23 |
| SuperMarioSF_ | I should make sure this phone actually works | 18:24 |
| SuperMarioSF_ | I have a different idea tho | 18:31 |
| SuperMarioSF_ | maybe it is not baseband related | 18:31 |
| SuperMarioSF_ | it may be because the Android side | 18:31 |
| SuperMarioSF_ | it switched to CDMA mode | 18:31 |
| SuperMarioSF_ | That the reason I can't get signal | 18:31 |
| SuperMarioSF_ | Lemme check real quicl | 18:32 |
| Wizzup | bencoh: I can give you access to a honeycomb dev vm | 18:32 |
| Wizzup | I set one up for dsc the other day | 18:32 |
| bencoh | if it runs an armhf rootfs it might help | 18:32 |
| bencoh | well, assuming I understand how this build is supposed to work anyway | 18:33 |
| bencoh | I don't really understand how debian builds it | 18:33 |
| bencoh | (arm64 kernel host running an armhf debian rootfs, _maybe_) | 18:33 |
| bencoh | oh and, funnily enough they read /sys/devices/system/cpu/modalias for detection of kernel cputype, which happily returns x86 in our container | 18:35 |
| bencoh | or I could try building on my lepotato board here | 18:36 |
| bencoh | err, 2G ram won't cut it, nevermind | 18:36 |
| SuperMarioSF_ | well | 18:41 |
| SuperMarioSF_ | I fixed it | 18:41 |
| SuperMarioSF_ | it was the problem on android side | 18:42 |
| SuperMarioSF_ | I did a switch now SIM care is working. | 18:42 |
| SuperMarioSF_ | lemme check leste side really quick | 18:43 |
| SuperMarioSF_ | It's working perfectly now | 18:44 |
| SuperMarioSF_ | however I still want a screen swap | 18:44 |
| SuperMarioSF_ | so I will do it anyways | 18:44 |
| SuperMarioSF_ | to be exact: it will be a shell swap, I will keep the mainboard intact | 18:45 |
| Wizzup | bencoh: yes armhf root | 18:45 |
| bencoh | Wizzup: sounds good then | 18:45 |
| Wizzup | bencoh: just a few mins, dm me ssh pubkey pls | 18:45 |
| bencoh | Wizzup: we can setup a native lxc container if you don't want to mess with the main rootfs | 18:46 |
| Wizzup | bencoh: up to you | 18:47 |
| bencoh | Wizzup: hmm apparently that board runs a v7l (armhf) kernel, not aarch64 | 19:11 |
| bencoh | I'll try anyway | 19:11 |
| Wizzup | bencoh: you wanted aarch64? | 19:24 |
| bencoh | for kernel yeah | 19:24 |
| bencoh | but armhf rootfs | 19:24 |
| bencoh | anyway, we'll see if it builds | 19:25 |
| bencoh | I removed the check | 19:25 |
| Wizzup | bencoh: oh, it was just for kernel? I thought this was a firefox thing :D | 19:26 |
| bencoh | it's to build firefox | 19:26 |
| bencoh | but firefox buildsystem checks kernel arch | 19:27 |
| bencoh | (they say it's because 32b has limited process memory size) | 19:27 |
| Wizzup | we have lpae | 19:28 |
| bencoh | yeah ... well, we'll see, currently building | 19:28 |
| Wizzup | :) | 20:01 |
| SuperMarioSF | hello from fixed d4 | 20:05 |
| SuperMarioSF | battery and chassis replaced | 20:05 |
| sicelo | SuperMarioSF_: nice | 20:49 |
| SuperMarioSF_ | here is a problem | 20:50 |
| SuperMarioSF_ | it seems nowdays if a uncalibrated battery goes below 30% it will automatically shutdown, so can I just start calibration there? | 20:51 |
| * sicelo long gave up about calibration on d4 ... i just charge whenever i get a chance | 20:54 | |
| SuperMarioSF_ | nvm | 20:55 |
| SuperMarioSF_ | I goes to android side | 20:55 |
| SuperMarioSF_ | and it report battery at 4% | 20:55 |
| Wizzup | sicelo: but, freemangordon has charger patches no? | 20:56 |
| SuperMarioSF_ | I'm waiting for it automatically shutodown | 20:56 |
| SuperMarioSF_ | and I know what happend to my modem | 20:56 |
| Wizzup | ah? | 20:56 |
| SuperMarioSF_ | it seems the LineageOS installed on this device cannot properly handle CDMA/GSM switching | 20:56 |
| SuperMarioSF_ | once startup it stuck at some weird state, neither CDMA nor GSM | 20:57 |
| SuperMarioSF_ | I switched to CDMA (NV mode) after while I can see a roaming icon, then it successfully entered CDMA mode. | 20:57 |
| SuperMarioSF_ | Then switched to GSM mode (RUIM/SIM mode), and my SIM card finally show up. | 20:58 |
| SuperMarioSF_ | For comparsion, the stock Motorola firmware handled this properly. | 20:59 |
| SuperMarioSF_ | Once my SIM card show up, reboot into Leste, it will work correctly. | 20:59 |
| SuperMarioSF_ | and every time LineageOS boot up, it will enter that weird state, so I need to switch it every time if I booted into Android. | 21:00 |
| Wizzup | oh yes, this can happen | 21:06 |
| bencoh | Wizzup: g++: fatal error: Killed signal terminated program cc1plus | 21:14 |
| bencoh | :( | 21:14 |
| bencoh | I think it's a memory issue | 21:14 |
| SuperMarioSF_ | weird | 21:26 |
| SuperMarioSF_ | the battery at 1% and it keep running for at least 15min now | 21:26 |
| SuperMarioSF_ | on android side | 21:26 |
| SuperMarioSF_ | and battery voltage is all over the place | 21:26 |
| SuperMarioSF_ | I guess they didn't get a real data from PMIC | 21:27 |
| sicelo | hehe, yes it's all black magic | 21:28 |
| SuperMarioSF_ | I'm going to play some video to make the battery drain even more faster | 21:28 |
| SuperMarioSF_ | ah | 21:32 |
| SuperMarioSF_ | finally it shut down | 21:32 |
| * freemangordon wonders what is wrong with usiing swap nowadays :) | 21:32 | |
| freemangordon | bencoh: ^^^ | 21:32 |
| freemangordon | Wizzup: going to post the requested info on bugzilla | 21:32 |
| freemangordon | about:config that is, from FF 78 | 21:33 |
| freemangordon | unfortunately, gl rendering seems disabled to me | 21:33 |
| SuperMarioSF_ | btw | 21:35 |
| SuperMarioSF_ | found a issue | 21:35 |
| SuperMarioSF_ | maybe related to libhildonmime | 21:35 |
| SuperMarioSF_ | I can't load any image in modest email client, even if I clicked download image button | 21:35 |
| SuperMarioSF_ | all image shown broken | 21:35 |
| SuperMarioSF_ | it is fine in another email client tho | 21:36 |
| freemangordon | yes, the same as with browser | 21:36 |
| freemangordon | there is not default image viewer | 21:37 |
| freemangordon | *no | 21:37 |
| SuperMarioSF_ | I guess I will pile up many bugs these days. Now I have to go have some rest, I'm going have a trip 5hours later | 21:37 |
| Wizzup | SuperMarioSF_: great, yeah, please file them when you can | 21:41 |
| gliffy | I may have found a possible culprit for the choppines I mentioned earlier on the n900. The change between the image builds 20220123 and 20220206 that I think might cause it is the replacement of the package "ti-omap3-sgx" with various other packages. I haven't been able to confirm this though since xorg has failed to start every time I tried replacing the package or upgrading the rest of the system. Does anyone have any | 21:46 |
| gliffy | insight on the difference between "ti-omap3-sgx" and the packages that replace it? | 21:46 |
| Wizzup | Hm.. that would be going from ddx 1.9 to ddx 1.17 I think | 21:47 |
| gliffy | Could that be the reason? | 21:48 |
| freemangordon | yes | 21:49 |
| freemangordon | also, I think that on ddk 1.9 was using 16bpp | 21:49 |
| freemangordon | but not sure | 21:49 |
| freemangordon | gliffy: those are GPU driver blobs | 21:50 |
| gliffy | I see | 21:50 |
| freemangordon | we were forced to move omapfb->omapdrm | 21:51 |
| freemangordon | but, last time I checked it was not *that* bad | 21:51 |
| sicelo | mmm, one of the things i like with maemo seems to not be working in leste - that when you open an (hildon) internet-needing application, it automatically establishes a connection, or prompts for one. just tried "Send and Receive" in Modest while not connected. didn't get a prompt | 21:52 |
| freemangordon | that's weird, it should have worke | 21:52 |
| freemangordon | *worked | 21:52 |
| rafael2k | camera focus working! yay! | 21:52 |
| bencoh | neat | 21:53 |
| freemangordon | unless we didn;t compile it with correct libs | 21:53 |
| freemangordon | cool | 21:53 |
| sicelo | perhaps someone else can try, to rule out something being broken with my setup | 21:53 |
| freemangordon | lemme try here | 21:53 |
| freemangordon | hmm | 21:53 |
| freemangordon | 'refresh' should open connect to dialog | 21:54 |
| freemangordon | but it does not | 21:54 |
| rafael2k | https://www.abradig.org.br/maemo-crazyness/pinhole-icon.jpg | 21:54 |
| rafael2k | I put the desktop entry ^ | 21:54 |
| rafael2k | one more screenshot: https://www.abradig.org.br/maemo-crazyness/pinhole-2.jpg | 21:54 |
| freemangordon | sicelo: so yeah, seems broken | 21:54 |
| sicelo | rafael2k: hehe, reminds me of sfos (icons with that shape) | 21:54 |
| freemangordon | that's qml, no? | 21:55 |
| sicelo | i meant the application icon (in the list) | 21:56 |
| freemangordon | gliffy: maybe try to edit /etc/init.d/xorg | 21:56 |
| freemangordon | to start Xorg in 16bpp mode | 21:56 |
| freemangordon | to see if it makes it better (it should) | 21:57 |
| gliffy | Ok I will see what I can do | 21:57 |
| rafael2k | sicelo, it is from sfos | 21:58 |
| rafael2k | qml, yes! | 21:58 |
| sicelo | haha, makes sense :p | 21:58 |
| rafael2k | :P | 21:58 |
| rafael2k | he supports better the silica toolkit, it is his "prime" platform | 21:59 |
| rafael2k | silica qml widgets.. but also kirigami and qt-controls and uutk | 21:59 |
| sicelo | i think i remember piggz from his maemo (or harmattan?) days | 22:01 |
| rafael2k | pretty sure he is from that times | 22:02 |
| freemangordon | sicelo: yep, something is broken in modest | 22:07 |
| freemangordon | with HAM it works properly | 22:07 |
| Wizzup | freemangordon: thanks for posting that | 22:07 |
| Wizzup | rafael2k: we could add it to the meta later (of course it won't do anything on droid etc) | 22:08 |
| Wizzup | rafael2k: maybe we could call it 'Camera' in the desktop entry, not sure | 22:08 |
| sicelo | (i intend to play with the n900's camera a little bit, in the near future) | 22:13 |
| sicelo | at least i know laurent is interested in it for libcamera | 22:13 |
| rafael2k | Wizzup, yeap, just camera will be fine | 22:30 |
| Wizzup | rafael2k: you can change this in the .desktop | 22:33 |
| Wizzup | I think | 22:33 |
| rafael2k | I will change | 22:36 |
| Wizzup | cool | 22:37 |
| uvos | freemangordon: ddk1.9 did not run in 16bit | 22:59 |
| freemangordon | ok | 22:59 |
| uvos | 16bit dident work there at all | 22:59 |
| uvos | and if you run x with -depth 16 | 22:59 |
| uvos | you will discovery everything is broken | 22:59 |
| freemangordon | what is 'everything'? | 22:59 |
| freemangordon | FYI I run it like that | 23:00 |
| uvos | firefox wil hang on start, chrome will render just a black window, qt will render a black window (or sometimes work depending on the app) | 23:00 |
| uvos | gtk dose seam to work | 23:00 |
| uvos | but thats about it | 23:00 |
| freemangordon | yes, I know | 23:00 |
| freemangordon | ok | 23:00 |
| freemangordon | so, maybe we have worse performance regression on n900 that I thought | 23:00 |
| uvos | no idea bout that | 23:00 |
| gliffy | I just tried with -depth 16 and no effect on choppiness unfortunately | 23:00 |
| uvos | note n900 never ran ddk1.9 | 23:01 |
| freemangordon | ugh | 23:01 |
| uvos | it ran something even older | 23:01 |
| uvos | there are no 1.9 blobs for omap3 | 23:01 |
| freemangordon | yeah | 23:01 |
| freemangordon | gliffy: ok, will try to find some time soon to see what happens | 23:01 |
| uvos | i think | 23:01 |
| uvos | the fbdev ddx n900 used | 23:02 |
| uvos | had full exa accel | 23:02 |
| freemangordon | so we do | 23:02 |
| uvos | do we accelerate everything now? | 23:02 |
| freemangordon | yes | 23:02 |
| uvos | i thought just blits | 23:02 |
| uvos | ok | 23:02 |
| freemangordon | well, blits and fills | 23:02 |
| freemangordon | but that's all that matters in terms of h-d | 23:03 |
| freemangordon | also xv | 23:03 |
| freemangordon | but that's irrelevant | 23:03 |
| uvos | one thing thats wierd (Not sure if related) | 23:04 |
| uvos | but hildon desktop seams to require disk io to scroll the home screens | 23:05 |
| freemangordon | hmm | 23:05 |
| uvos | if the sdcard is hevly loaded on d4 | 23:05 |
| freemangordon | why is that? | 23:05 |
| uvos | hd will hang | 23:05 |
| freemangordon | that's weird | 23:05 |
| uvos | also if you have the "hdd light" | 23:05 |
| uvos | activeted | 23:05 |
| freemangordon | should not happen | 23:05 |
| uvos | you will find it blinks everytime you swipe on hildon home | 23:05 |
| uvos | concievable if disk io is very slow this could be causeing it to stutter even when the sdcard is not loaded | 23:06 |
| freemangordon | hmm | 23:06 |
| uvos | could be it logging very verbosely somewhere mabye? | 23:07 |
| freemangordon | hmm | 23:07 |
| uvos | not sure why it would be this synchronous | 23:07 |
| freemangordon | we have to check that | 23:07 |
| freemangordon | but yeah, this may explain it | 23:07 |
| freemangordon | sicelo: https://github.com/maemo-leste/tinymail/blob/master/configure.ac#L530 | 23:08 |
| freemangordon | :) | 23:08 |
| freemangordon | going to rebuild | 23:08 |
| freemangordon | for chimaera first, then maybe foe beowulf-devel | 23:09 |
| Wizzup | freemangordon: lol | 23:09 |
| freemangordon | yeah | 23:09 |
| freemangordon | not sure how to fix that though | 23:09 |
| freemangordon | shall I assume if it is amd64 then this is VM? seems silly to me | 23:13 |
| Wizzup | do we need this check at all? | 23:13 |
| Wizzup | just use the normal conic | 23:14 |
| freemangordon | well, see the note | 23:14 |
| Wizzup | well, we support ethernet! | 23:14 |
| Wizzup | :) | 23:14 |
| Wizzup | and also dummy plugin | 23:14 |
| freemangordon | but conic does not | 23:14 |
| freemangordon | ah, right | 23:14 |
| Wizzup | yeah, this is just icd2 | 23:14 |
| freemangordon | ok, so I'll remove that, but will leave the code for dummy conic device | 23:15 |
| Wizzup | ok, let's just make sure it's not used | 23:15 |
| freemangordon | Wizzup: maybe we can build a separate package for the VM | 23:25 |
| Wizzup | freemangordon: but why? we just need eth. plugin for icd2 or dummy | 23:26 |
| Wizzup | all the other SW also needs to deal with this | 23:26 |
| Wizzup | so let's not hack around conic in one pkg | 23:26 |
| freemangordon | oh, right | 23:26 |
| freemangordon | sorry, it is late here :) | 23:26 |
| Wizzup | np | 23:27 |
| freemangordon | Wizzup: ok, what to do for beowulf? | 23:34 |
| freemangordon | for tinymail that is | 23:34 |
| freemangordon | I guess nothing | 23:35 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
