**** BEGIN LOGGING AT Wed Dec 14 03:00:00 2016
Dec 14 03:55:58 <DocScrutinizer05> (([2016-12-13 Tue 21:10:49] <bencoh> mmc1 is external sdcard, mmc0 is (internal) eMMC)) WATCH OUT! this is not exactly totaly true
Dec 14 04:44:55 <DocScrutinizer05> http://paste.opensuse.org/94100329
Dec 14 04:46:53 <DocScrutinizer05> actually maemo does explicitly rename / swap mmc0 and mmc1 if and only if both are detected, since the kernel first checks uSD and after that eMMC, so depending if a uSD is present or not, the naming is different before that explicit renaming
Dec 14 04:56:59 <DocScrutinizer05> http://mg.pov.lt/maemo-irclog/%23maemo.2011-10-31.log.html#t2011-10-31T04:34:19   http://mg.pov.lt/maemo-irclog/%23maemo.2011-10-31.log.html#t2011-10-31T05:13:29
Dec 14 05:17:19 <DocScrutinizer05> cat /lib/udev/mmc_id
Dec 14 05:18:04 <DocScrutinizer05> freemangordon: ^^^ is one of the many many things I think will be quite a pita to ship around when trying to "port fremantle" to devuan piece by piece
Dec 14 05:19:38 <DocScrutinizer05> since I'm quite sure there's no such thing like /lib/udev/mmc_id and the framework calling it, in plain devuan. And yet basically _all_ maemo apps etc depend on the results of this little thingie, in that they have hardcoded path names etc
Dec 14 05:20:43 <DocScrutinizer05> you can't build a house from roof to basement
Dec 14 05:24:03 <DocScrutinizer05> in my book it's simpler to port devuan to maemo fremantle piece by piece, and fix the fallout after each ported piece
Dec 14 05:27:12 <DocScrutinizer05> porting only one or a few fremantle pieces to devuan will be a real PITA to make them work since you need to fix a metric shitton of such little incompatibilities just to find you need to fix them *again* for the next piece you port, since e.g. _all_ are depending on same consistent persistent naming eMMC=mmc0 uSD=mmc1 and you either can fix that once in devuan or you fix it in *all* maemo pieces and even then it won't work as expected
Dec 14 05:56:31 <KotCzarny> regarding partitions, on android it mounts partitions by-name
Dec 14 05:57:03 <KotCzarny> so it detects names first, then mounts what's needed
Dec 14 06:05:08 <DocScrutinizer05> I'd first port new kernel from devuan to maemo and try how far that gets when installed and started on target platform. Should reach loading of PID1 which initially is messybox in fremantle. Then you probably need a glibc built with legacy ABI upward to apps but built against API of new kernel. You then might get PID1 actually starting and running into kernel API incompatibilities e.g. in /dev/* and /sys/ and /proc/, for which you may 
Dec 14 06:05:10 <DocScrutinizer05> implement simple (deprecated for future use) janus stubs to link /sys/obsolete/legacy -> /sys/new/leete, possibly with a driver in between to convert the semantics and/or syntax. Then you'll notice some 'proprietary' kernel device drivers are not yet there in Devuan so you might port those to new kernel. Once all that done, you actually could start replacing resp upgrading stuff to Devuan part by part, like cli programs in /bin/ /sbin/ 
Dec 14 06:05:11 <DocScrutinizer05> etc, and finally maybe even make busybox based "upstart" init system of maemo just one process started under the genuine Devuan init system, whatever you choose for that
Dec 14 06:09:18 <DocScrutinizer05> in the end you'll have a set of files to install on top of a regular devuan, and that set of files implements a complete maemo running 'inside' devuan
Dec 14 07:06:16 <freemangordon> DocScrutinizer05: "port new kernel from devuan to maemo" doesn't make much of a sense, since we already kind of have that, on n900
Dec 14 07:08:01 <freemangordon> also, most of Fremantle API is dbus based, so "porting" is a matter of either implementing missing dbus services or fixing existing users to use upstream ones
Dec 14 07:09:51 <Maxdamantus> I'd imagine Debian/Devuan wouldn't use a very special kernel.
Dec 14 07:09:58 <freemangordon> :nod:
Dec 14 07:10:10 * Maxdamantus just uses his own kernels with his Debian machines.
Dec 14 07:10:55 <Maxdamantus> usually all you have to do is have a particular filesystem as your root then exec /sbin/init as pid 1.
Dec 14 07:11:16 <Maxdamantus> (for typical Linux-based systems)
Dec 14 07:11:22 <freemangordon> what worries me much ATM, is that gtk3 h-d uses ~100MB of RAM when started
Dec 14 07:12:17 <KotCzarny> soo, can we please stay with gtk2?
Dec 14 07:12:18 <KotCzarny> :)
Dec 14 07:12:50 <freemangordon> we may end up like that, yes
Dec 14 07:14:30 <freemangordon> KotCzarny: but, that high memory usage might be some bug i've introduced, see https://ubuntu-mate.org/blog/mate-desktop-gtk2-vs-gtk3-memory-consumption/
Dec 14 07:16:13 <KotCzarny> uhum
Dec 14 07:19:05 <KotCzarny> what worries me a bit, it's transitional period where both toolkits are in use
Dec 14 07:19:17 <KotCzarny> as not all apps are ported to gtk3, and some will never be
Dec 14 07:19:20 <freemangordon> lets decide on that after I've replaced tidy with mx
Dec 14 07:22:19 <KotCzarny> another factor to consider is toolkit speed, since gtk3 is css based, it might be slower
Dec 14 07:25:07 <freemangordon> KotCzarny: I am not sure right now we use any css in h-d
Dec 14 07:26:35 <KotCzarny> themes/config in h-d are defined via css
Dec 14 07:26:40 <KotCzarny> s/h-d/gtk3/
Dec 14 07:26:40 <infobot> KotCzarny meant: themes/config in gtk3 are defined via css
Dec 14 07:27:32 <Maxdamantus> Let's just settle on dwm.
Dec 14 07:28:25 <KotCzarny> best test case will be machine set to some low speed and comparing
Dec 14 07:28:44 <freemangordon> KotCzarny: iiuc h-d itself has hardcoded image files names and hardcoded element distances
Dec 14 07:29:47 <KotCzarny> do you have gtk2's version of h-d handy for comparisons?
Dec 14 07:29:56 <KotCzarny> (to be ran on same machine)
Dec 14 07:31:23 <freemangordon> no 
Dec 14 07:31:25 <KotCzarny> oh, wow.. gtk 4.0
Dec 14 07:32:18 <KotCzarny>  Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it.
Dec 14 07:32:32 <KotCzarny> https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
Dec 14 07:33:07 <bencoh> oO
Dec 14 07:33:54 <KotCzarny> The first “API stable” version under this new scheme is likely to be something like Gtk 3.26.
Dec 14 07:35:30 <KotCzarny> maybe just stick to gtk2 and f*ck it all
Dec 14 07:35:46 <freemangordon> yes, it may end up like that
Dec 14 07:36:49 <freemangordon> KotCzarny: I don't have gtk2 h-d on the smae machine, but I have xfce4
Dec 14 07:37:16 <KotCzarny> fmg, what is missing from gtk2 that gtk3 has?
Dec 14 07:37:41 <freemangordon> KotCzarny: touch support I guess
Dec 14 07:37:48 <KotCzarny> panned area is already done i think
Dec 14 07:37:57 <freemangordon> in maemo gtk? yes
Dec 14 07:38:12 <freemangordon> but it is not the same as upstream gtk2
Dec 14 07:38:17 <KotCzarny> it should work automatically because its a framework
Dec 14 07:38:41 <freemangordon> what should work automatically?
Dec 14 07:38:43 <KotCzarny> so no need to rewrite apps to support scroll-via-gesture
Dec 14 07:40:27 <KotCzarny> and since gtk2 wouldnt seen plenty of future releases and maemo-gtk2 is drop in compatible with gtk2
Dec 14 07:40:47 <KotCzarny> maybe just forward port them to latest gtk2 version ?
Dec 14 07:41:10 <KotCzarny> there is a chance there wouldnt be much to fix
Dec 14 07:41:23 <KotCzarny> s/seen/see/
Dec 14 08:09:14 <DocScrutinizer05> freemangordon: sure, don't take meaning of my "porting" as a huge work package, for kernel it's just "install the recent kernel (as it's also used in Devuan) to a stock fremantle"
Dec 14 08:09:39 <freemangordon> and we already did that :)
Dec 14 08:10:52 <DocScrutinizer05> sure
Dec 14 08:10:55 <DocScrutinizer05> :-)
Dec 14 08:13:25 <DocScrutinizer05> I think I already mentioned it: the desired end result is absolutely identical for your and my approach. Just your is to lift maemo building blocks one by one onto the Devuan level while mine is dropping Devuan building block one by one down into the maemo level. The core difference is that lifting is prolly more effort than dropping. The result is 100% identical in the end
Dec 14 08:16:42 <freemangordon> yes, I see your point. But what I think is the problem with it, is that we can't put maemo patched gtk2 for example on devuan servers
Dec 14 08:17:06 <DocScrutinizer05> hmm, that's a whole new aspect
Dec 14 08:17:21 <freemangordon> and I still insist that without upstream support, maemo is dead
Dec 14 08:17:28 <DocScrutinizer05> sure
Dec 14 08:17:35 <freemangordon> yeas I know, but we should consider it
Dec 14 08:17:37 <KotCzarny> fmg: why not?
Dec 14 08:17:40 <KotCzarny> libjpegturbo coexists with libjpeg
Dec 14 08:17:43 <KotCzarny> and both target same api
Dec 14 08:17:57 <freemangordon> no libjepg in devuan, only turbo :)
Dec 14 08:18:01 <DocScrutinizer05> of course. Everything relevant needs consideration. I just never thought of that
Dec 14 08:18:02 <KotCzarny> see?
Dec 14 08:18:23 <KotCzarny> then we will have maemogtk2 instaed of gtk2 in devuan at some point 
Dec 14 08:18:25 <KotCzarny> :)
Dec 14 08:18:35 <KotCzarny> but it must be drop-in compatible
Dec 14 08:18:42 <freemangordon> KotCzarny: do you have maemo libjpeg sources?
Dec 14 08:18:45 <freemangordon> as I don;t
Dec 14 08:19:00 <DocScrutinizer05> o.O
Dec 14 08:19:02 <DocScrutinizer05> duh!
Dec 14 08:19:08 <KotCzarny> nono, it was an example that two libs share same api
Dec 14 08:19:30 <KotCzarny> and apps can be compiled without changes against any of them
Dec 14 08:19:57 <freemangordon> maemo gtk is not ABI/API compatible with upstream gtk
Dec 14 08:20:09 <freemangordon> so is maemo clutter, etc
Dec 14 08:20:14 <KotCzarny> hrm
Dec 14 08:20:35 <DocScrutinizer05> wut? freaking weirdos @ Nokla
Dec 14 08:20:57 <freemangordon> don't ask me :)
Dec 14 08:21:29 <freemangordon> anyway, time to go to work
Dec 14 10:42:28 <Wizzup> freemangordon: I wouldn't worry too much about initial ram usage, I'm sure it can be reduced quite a bit
Dec 14 11:17:24 <DocScrutinizer05> optimizing speed, sure. but optimizing a fubar data model, I've not seen that ever really fly
Dec 14 11:18:20 <Wizzup> How is gtk3 worse than gtk2?
Dec 14 11:18:54 <Maxdamantus> Wirth's law.
Dec 14 11:19:50 <Wizzup> *shrug* when it comes to widgetsets, you better just keep up with newer releases, or you're stuck with unsupported versions. I don't believe that gtk3 will use to much more ram that it's unsuitable
Dec 14 11:20:30 <KotCzarny> multiple toolkits, ahoy!
Dec 14 11:21:01 <Wizzup> KotCzarny: what do you even mean?
Dec 14 11:21:21 <KotCzarny> if you have os using gtk3, but apps use gtk2 you must load both libs
Dec 14 11:21:54 <Wizzup> Yes, and?
Dec 14 11:22:04 <Wizzup> It's not like qt isn't loaded often as well on the n900 atm
Dec 14 11:22:27 <Wizzup> Imagine not being able to use multiple widget sets at all
Dec 14 13:21:22 * ceene testing hexchat...
Dec 14 17:09:31 <pkill9> anyone know how to fix/replace a dead vibration motor in the N900? and where to get a replacement?
Dec 14 17:10:36 <KotCzarny> google n900 service manual level 3 or something
Dec 14 17:11:04 <KotCzarny> another broken n900 is a good source of spare parts
Dec 14 19:35:28 <freemangordon> Wizzup: not sure, but will see once I replace tidy with mx
Dec 14 19:35:46 <freemangordon> otherwise I can't see how it can be reduced
Dec 14 19:36:04 <freemangordon> hmm, wait, maemo-launcher that is ;)
Dec 14 19:42:04 <Pali> freemangordon: your omapfb patch which reserve memory fails in qemu on error: omapfb: dma_declare_coherent_memory failed
Dec 14 19:42:45 <KotCzarny> needs newer qemu? no cma enabled? bad kernel params?
Dec 14 19:45:18 <freemangordon> Pali: could be, dma_declare... semantics changed in 4.7 ot 4.8 iirc
Dec 14 19:45:48 <freemangordon> Pali: could I have the error
Dec 14 19:46:19 <freemangordon> -EINVAL?
Dec 14 19:46:30 <Pali> stacktrace
Dec 14 19:46:44 <freemangordon> no, just the error code
Dec 14 19:46:45 <Pali> memremap attempted on ram 0x8f800000 size: 0x700000
Dec 14 19:47:24 <freemangordon> I should have patched that :(
Dec 14 19:47:41 <Pali> relevant part: http://pastebin.com/1CYQ75N2
Dec 14 19:47:51 <Pali> maybe I do not have last version of your patch?
Dec 14 19:48:06 <freemangordon> could be
Dec 14 19:48:12 <freemangordon> is it the same as https://github.com/freemangordon/linux-n900/commit/259f17b2b2cdad6a0a0c106d9c10a7f1dee04729 ?
Dec 14 19:48:46 <freemangordon> I think you have the version with DMA_MEMORY_IO instead of DMA_MEMORY_EXCLUSIVE
Dec 14 19:48:50 <freemangordon> or somesuch
Dec 14 19:49:25 <freemangordon> Pali: which patch do you have?
Dec 14 19:50:25 <freemangordon> oh, and it was failing for > 2MB, something config has to be changed
Dec 14 19:50:43 <freemangordon> Pali: https://github.com/freemangordon/linux-n900/commit/a068c200c32dafa98a403312102ca198c125924f
Dec 14 19:51:19 <freemangordon> Pali: you definitely have old version of the patch :)
Dec 14 19:51:43 <freemangordon> Pali: still here?!?
Dec 14 19:52:49 <freemangordon> hmm, gtk h-d seems to leak, besides initial high memory usage
Dec 14 19:52:53 <Pali> freemangordon: I'm on #armlinux too :-)
Dec 14 19:53:59 <Pali> I will try compare that path
Dec 14 19:54:04 <Pali> with current one
Dec 14 20:52:25 <Pali> freemangordon: older version with tidspbridge support...
Dec 14 20:53:03 <Pali> now going to update it to with that new commit
Dec 14 20:58:38 <Pali> yes, that version fixes it
Dec 14 21:06:10 <Wizzup> MoeIcenowy: freemangordon: where did you get the mali binary?
Dec 14 21:06:21 <Wizzup> wait, /me will rtfm the wiki
Dec 15 02:23:47 <_maniac_> I know this is futile, but tell me, is there a way to discover phone location (maemo, n900, no smscon, no vpn autoconnect, only gmail auto checking) if it was stolen?
**** ENDING LOGGING AT Thu Dec 15 03:00:00 2016