| 00:22.05 | *** join/#maemo N-Mi_ (~nicolas@37.161.61.92) |
| 00:43.06 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 01:11.57 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 01:39.28 | *** join/#maemo krnlyng (~liar@77.116.118.116.wireless.dyn.drei.com) |
| 02:13.37 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 03:34.21 | *** join/#maemo stryngs (~stryngs@img.ethicalreporting.org) |
| 03:54.27 | *** join/#maemo stryngs_ (~stryngs@unaffiliated/stryngs) |
| 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 |
| 04:02.31 | *** join/#maemo lxp1 (~lxp@unaffiliated/lxp) |
| 04:43.19 | *** join/#maemo tm (~sinnlos@360.vmworld.it) |
| 04:44.55 | DocScrutinizer05 | http://paste.opensuse.org/94100329 |
| 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 |
| 04:57.00 | 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 |
| 05:17.19 | DocScrutinizer05 | cat /lib/udev/mmc_id |
| 05:18.05 | 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 |
| 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 |
| 05:20.43 | DocScrutinizer05 | you can't build a house from roof to basement |
| 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 |
| 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 |
| 05:44.29 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:47.11 | *** join/#maemo at1as (~at1as@c-73-132-66-102.hsd1.va.comcast.net) |
| 05:56.31 | KotCzarny | regarding partitions, on android it mounts partitions by-name |
| 05:57.03 | KotCzarny | so it detects names first, then mounts what's needed |
| 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 |
| 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/ |
| 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 |
| 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 |
| 06:23.52 | *** join/#maemo frals (~frals@Maemo/community/contributor/frals) |
| 06:45.18 | *** join/#maemo arcean (~arcean@131.228.32.167) |
| 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 |
| 07:08.02 | 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 |
| 07:09.51 | Maxdamantus | I'd imagine Debian/Devuan wouldn't use a very special kernel. |
| 07:09.58 | freemangordon | :nod: |
| 07:10.10 | Maxdamantus | just uses his own kernels with his Debian machines. |
| 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. |
| 07:11.16 | Maxdamantus | (for typical Linux-based systems) |
| 07:11.22 | freemangordon | what worries me much ATM, is that gtk3 h-d uses ~100MB of RAM when started |
| 07:12.17 | KotCzarny | soo, can we please stay with gtk2? |
| 07:12.18 | KotCzarny | :) |
| 07:12.50 | freemangordon | we may end up like that, yes |
| 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/ |
| 07:16.13 | KotCzarny | uhum |
| 07:19.05 | KotCzarny | what worries me a bit, it's transitional period where both toolkits are in use |
| 07:19.17 | KotCzarny | as not all apps are ported to gtk3, and some will never be |
| 07:19.20 | freemangordon | lets decide on that after I've replaced tidy with mx |
| 07:22.19 | KotCzarny | another factor to consider is toolkit speed, since gtk3 is css based, it might be slower |
| 07:25.07 | freemangordon | KotCzarny: I am not sure right now we use any css in h-d |
| 07:26.35 | KotCzarny | themes/config in h-d are defined via css |
| 07:26.40 | KotCzarny | s/h-d/gtk3/ |
| 07:27.32 | Maxdamantus | Let's just settle on dwm. |
| 07:28.25 | KotCzarny | best test case will be machine set to some low speed and comparing |
| 07:28.44 | freemangordon | KotCzarny: iiuc h-d itself has hardcoded image files names and hardcoded element distances |
| 07:29.47 | KotCzarny | do you have gtk2's version of h-d handy for comparisons? |
| 07:29.56 | KotCzarny | (to be ran on same machine) |
| 07:31.23 | freemangordon | no |
| 07:31.25 | KotCzarny | oh, wow.. gtk 4.0 |
| 07:32.18 | KotCzarny | <PROTECTED> |
| 07:32.32 | KotCzarny | https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ |
| 07:33.07 | bencoh | oO |
| 07:33.54 | KotCzarny | The first âAPI stableâ version under this new scheme is likely to be something like Gtk 3.26. |
| 07:35.30 | KotCzarny | maybe just stick to gtk2 and f*ck it all |
| 07:35.46 | freemangordon | yes, it may end up like that |
| 07:36.49 | freemangordon | KotCzarny: I don't have gtk2 h-d on the smae machine, but I have xfce4 |
| 07:37.16 | KotCzarny | fmg, what is missing from gtk2 that gtk3 has? |
| 07:37.41 | freemangordon | KotCzarny: touch support I guess |
| 07:37.48 | KotCzarny | panned area is already done i think |
| 07:37.57 | freemangordon | in maemo gtk? yes |
| 07:38.12 | freemangordon | but it is not the same as upstream gtk2 |
| 07:38.17 | KotCzarny | it should work automatically because its a framework |
| 07:38.41 | freemangordon | what should work automatically? |
| 07:38.43 | KotCzarny | so no need to rewrite apps to support scroll-via-gesture |
| 07:40.27 | KotCzarny | and since gtk2 wouldnt seen plenty of future releases and maemo-gtk2 is drop in compatible with gtk2 |
| 07:40.47 | KotCzarny | maybe just forward port them to latest gtk2 version ? |
| 07:41.10 | KotCzarny | there is a chance there wouldnt be much to fix |
| 07:41.23 | KotCzarny | s/seen/see/ |
| 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" |
| 08:09.39 | freemangordon | and we already did that :) |
| 08:10.52 | DocScrutinizer05 | sure |
| 08:10.55 | DocScrutinizer05 | :-) |
| 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 |
| 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 |
| 08:17.06 | DocScrutinizer05 | hmm, that's a whole new aspect |
| 08:17.21 | freemangordon | and I still insist that without upstream support, maemo is dead |
| 08:17.28 | DocScrutinizer05 | sure |
| 08:17.35 | freemangordon | yeas I know, but we should consider it |
| 08:17.37 | KotCzarny | fmg: why not? |
| 08:17.40 | KotCzarny | libjpegturbo coexists with libjpeg |
| 08:17.43 | KotCzarny | and both target same api |
| 08:17.57 | freemangordon | no libjepg in devuan, only turbo :) |
| 08:18.01 | DocScrutinizer05 | of course. Everything relevant needs consideration. I just never thought of that |
| 08:18.02 | KotCzarny | see? |
| 08:18.23 | KotCzarny | then we will have maemogtk2 instaed of gtk2 in devuan at some point |
| 08:18.25 | KotCzarny | :) |
| 08:18.35 | KotCzarny | but it must be drop-in compatible |
| 08:18.42 | freemangordon | KotCzarny: do you have maemo libjpeg sources? |
| 08:18.45 | freemangordon | as I don;t |
| 08:19.00 | DocScrutinizer05 | o.O |
| 08:19.02 | DocScrutinizer05 | duh! |
| 08:19.08 | KotCzarny | nono, it was an example that two libs share same api |
| 08:19.30 | KotCzarny | and apps can be compiled without changes against any of them |
| 08:19.57 | freemangordon | maemo gtk is not ABI/API compatible with upstream gtk |
| 08:20.09 | freemangordon | so is maemo clutter, etc |
| 08:20.14 | KotCzarny | hrm |
| 08:20.35 | DocScrutinizer05 | wut? freaking weirdos @ Nokla |
| 08:20.57 | freemangordon | don't ask me :) |
| 08:21.29 | freemangordon | anyway, time to go to work |
| 08:22.32 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 08:50.30 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 09:19.03 | *** join/#maemo ceene (~ceene@collins.gmr.ssr.upm.es) |
| 10:29.49 | *** join/#maemo N-Mi_ (~nicolas@LMontsouris-657-1-196-48.w90-63.abo.wanadoo.fr) |
| 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 |
| 11:17.24 | DocScrutinizer05 | optimizing speed, sure. but optimizing a fubar data model, I've not seen that ever really fly |
| 11:18.20 | Wizzup | How is gtk3 worse than gtk2? |
| 11:18.54 | Maxdamantus | Wirth's law. |
| 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 |
| 11:20.30 | KotCzarny | multiple toolkits, ahoy! |
| 11:21.01 | Wizzup | KotCzarny: what do you even mean? |
| 11:21.21 | KotCzarny | if you have os using gtk3, but apps use gtk2 you must load both libs |
| 11:21.54 | Wizzup | Yes, and? |
| 11:22.04 | Wizzup | It's not like qt isn't loaded often as well on the n900 atm |
| 11:22.27 | Wizzup | Imagine not being able to use multiple widget sets at all |
| 11:27.48 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 11:55.55 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 11:57.12 | *** join/#maemo zGrr (~Grr@188.146.166.179.nat.umts.dynamic.t-mobile.pl) |
| 12:42.30 | *** join/#maemo silviof (~silviof@unaffiliated/silviof) |
| 13:20.01 | *** join/#maemo jskarvad (jskarvad@redhat/jskarvad) |
| 13:21.22 | ceene | testing hexchat... |
| 14:19.00 | *** join/#maemo dreamer (~henk@unaffiliated/dreamer) |
| 14:22.52 | *** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-amtkodbsfezazuyb) |
| 15:27.50 | *** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 15:41.24 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 15:52.28 | *** join/#maemo Trizt (~user@ukko.aho.hk) |
| 15:56.23 | *** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 16:05.28 | *** join/#maemo at1as (~at1as@12.238.61.39) |
| 17:09.31 | pkill9 | anyone know how to fix/replace a dead vibration motor in the N900? and where to get a replacement? |
| 17:10.36 | KotCzarny | google n900 service manual level 3 or something |
| 17:11.05 | KotCzarny | another broken n900 is a good source of spare parts |
| 17:35.37 | *** join/#maemo sunshavi (~user@201.240.146.197) |
| 17:38.03 | *** join/#maemo dimw1t (~at1as@12.238.61.12) |
| 17:58.42 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 18:06.11 | *** join/#maemo at1as (~at1as@12.238.61.12) |
| 18:07.51 | *** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 18:21.35 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 18:59.10 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 19:10.06 | *** join/#maemo Timo (~timo@unaffiliated/tiempjuuh) |
| 19:16.06 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 19:31.31 | *** join/#maemo Vajb (~Vajb@85-76-2-94-nat.elisa-mobile.fi) |
| 19:35.28 | freemangordon | Wizzup: not sure, but will see once I replace tidy with mx |
| 19:35.46 | freemangordon | otherwise I can't see how it can be reduced |
| 19:36.04 | freemangordon | hmm, wait, maemo-launcher that is ;) |
| 19:42.04 | Pali | freemangordon: your omapfb patch which reserve memory fails in qemu on error: omapfb: dma_declare_coherent_memory failed |
| 19:42.45 | KotCzarny | needs newer qemu? no cma enabled? bad kernel params? |
| 19:45.18 | freemangordon | Pali: could be, dma_declare... semantics changed in 4.7 ot 4.8 iirc |
| 19:45.48 | freemangordon | Pali: could I have the error |
| 19:46.19 | freemangordon | -EINVAL? |
| 19:46.30 | Pali | stacktrace |
| 19:46.44 | freemangordon | no, just the error code |
| 19:46.45 | Pali | memremap attempted on ram 0x8f800000 size: 0x700000 |
| 19:47.24 | freemangordon | I should have patched that :( |
| 19:47.41 | Pali | relevant part: http://pastebin.com/1CYQ75N2 |
| 19:47.51 | Pali | maybe I do not have last version of your patch? |
| 19:48.06 | freemangordon | could be |
| 19:48.12 | freemangordon | is it the same as https://github.com/freemangordon/linux-n900/commit/259f17b2b2cdad6a0a0c106d9c10a7f1dee04729 ? |
| 19:48.38 | *** part/#maemo slobber (~slobber@unaffiliated/linkxs) |
| 19:48.46 | freemangordon | I think you have the version with DMA_MEMORY_IO instead of DMA_MEMORY_EXCLUSIVE |
| 19:48.50 | freemangordon | or somesuch |
| 19:49.25 | freemangordon | Pali: which patch do you have? |
| 19:50.25 | freemangordon | oh, and it was failing for > 2MB, something config has to be changed |
| 19:50.43 | freemangordon | Pali: https://github.com/freemangordon/linux-n900/commit/a068c200c32dafa98a403312102ca198c125924f |
| 19:51.19 | freemangordon | Pali: you definitely have old version of the patch :) |
| 19:51.43 | freemangordon | Pali: still here?!? |
| 19:52.49 | freemangordon | hmm, gtk h-d seems to leak, besides initial high memory usage |
| 19:52.53 | Pali | freemangordon: I'm on #armlinux too :-) |
| 19:52.54 | *** join/#maemo ecc3g (~eccerr0r@2602:46:3913:b400:5054:ff:fe37:7e04) |
| 19:53.59 | Pali | I will try compare that path |
| 19:54.04 | Pali | with current one |
| 19:57.33 | *** join/#maemo erstazi (~erstazi@unaffiliated/erstazi) |
| 19:59.15 | *** join/#maemo clopez (~tau@neutrino.es) |
| 20:05.32 | *** join/#maemo erstazi (~erstazi@unaffiliated/erstazi) |
| 20:21.06 | *** join/#maemo Trizt (~user@ukko.aho.hk) |
| 20:34.30 | *** join/#maemo rm_work (rm_work@Maemo/community/cssu/rm-you) |
| 20:52.25 | Pali | freemangordon: older version with tidspbridge support... |
| 20:53.04 | Pali | now going to update it to with that new commit |
| 20:58.38 | Pali | yes, that version fixes it |
| 21:06.10 | Wizzup | MoeIcenowy: freemangordon: where did you get the mali binary? |
| 21:06.21 | Wizzup | wait, /me will rtfm the wiki |
| 22:00.14 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 22:12.37 | *** join/#maemo louisdk (~louisdk@213.83.133.74) |
| 22:30.58 | *** join/#maemo lobito2 (~lobito@191.82.117.74) |
| 22:39.54 | *** join/#maemo lobito (~lobito@unaffiliated/lobito) |