**** BEGIN LOGGING AT Tue Dec 06 03:00:00 2016 Dec 06 06:02:23 having packages to depend on thumb target enabler is nice idea, but how would that react to having same package compiled for thumb and nonthumb? Dec 06 07:23:19 i do agree with FMG that N900 is not going to last forever ... just it is painful to think of the possibility that the N900 could be abandoned :( Dec 06 07:26:07 i have 2 spares Dec 06 07:26:25 and since it fullfills my phoning needs its not going away anytime soon Dec 06 07:27:36 (and has oscp, of course) Dec 06 07:37:57 :) Dec 06 07:38:57 sicelo: have you seen the neo900? Dec 06 07:41:10 sicelo: it's not even the point of any discussion that literally nothing lasts forever. Nevertheless it's a tad bewildering when the author of thumb says it's not worth supporting it any longer Dec 06 07:41:58 Neo900 yes I saw it .. but I can't afford anything, not even the AllWinner tablets Dec 06 07:43:01 i support Neo project of course Dec 06 07:43:19 witha a bumper sticker? ;) Dec 06 07:44:09 DocScrutinizer05: well, the only reason behind thumb is save ressources on a low-memory device Dec 06 07:44:25 s/only/main/ Dec 06 07:44:50 no Dec 06 07:45:24 thumb is the real armel, while maemo's armel is crippled since it doesn't allow thumb Dec 06 07:46:32 that's not the point... Dec 06 07:46:53 and since the kernel patch needed for N900 OMAP-crap already exists, the maemo-extras-thumb repo is the one that really has a future, while the maemo-extras repo is the one that eventually gets obsolete Dec 06 07:47:48 thus declaring thumb an obsolete effort makes zilch sense to me Dec 06 07:50:03 Apple time! :) Dec 06 07:50:11 haha Dec 06 07:50:58 krkr Dec 06 08:00:21 or let me put it very simple and obvious: when I'd be going to install maemo on a BeagleBoard-xM or a Pyra or a Neo900, I'd for sure use a maemo-extras-thumb and CSSU-thumb instead of the plain maemo, since why would I want to forbid thumb code on all those platforms? Dec 06 08:10:03 in CSSU-thumb maybe the kernel patch gets obsolete eventually. In maemo-extras only those apps get obsolete for which a maemo-extras-thumb build exists. All apps in maemo-extras-thumb and the apps in maemo-extras that have no thumb build will _not_ get obsolete before no OMAP device around anymore Dec 06 08:11:49 I will continue to use my N900 until one of 3 things happens:1.It breaks in a way that cant be fixed 2.My carrier makes a change that prevents me from continuing to use the N900 anymore or 3.I am able to afford and justify something to replace it that is genuinely better (right now I cant justify a Neo900 because there is no point replacing a perfectly good N900) Dec 06 08:12:08 i.e. you can have my N900 when you pry it from my cold dead hands :) Dec 06 08:12:36 :-) Dec 06 08:12:47 I wouldn't use something like a crApple iFail or a Galaxy even if someone gave me one for free Dec 06 08:13:36 welcome to the club Dec 06 08:14:15 i wouldnt mind if someone remade the case of n900 into better kb one (similar to 5510) Dec 06 08:18:47 is Neo900 stlil alive... Dec 06 08:21:07 sure, why not? Dec 06 08:22:45 Another benefit of the N900 is that so few people use it that the virus writers aren't going to bother writing viruses for it and will focus on the popular platforms (iPhone, Android, Windows, OSX, linux servers) Dec 06 08:23:06 although that doesn't mean much given how weak the security is Dec 06 08:23:08 security by obscuruty is a poor one Dec 06 08:23:23 Iäm pretty sure in reality they have the shotgun approach Dec 06 08:23:30 and old linux kernel/libs almost ensures working sploits Dec 06 08:23:40 that's a good reasoning, and I follow it in a number of areas. E.g. my main browser still is Konqueror Dec 06 08:24:11 writing viruses doesn't come cheap Dec 06 08:24:41 and I doubt they are going to spend the money to write a virus for an outdated little-used phone platform when that same money could generate a lot more infections on a Windows platform Dec 06 08:24:46 or an iPhone platform Dec 06 08:26:22 that doesn't mean improving the security of the N900 isn't a good idea (it is) Dec 06 08:27:07 improving security is always a good idea... as long as it's not done ala Aegis or Apple Dec 06 08:27:23 Finding a way to get the newest TLS standards (and newest cipher suites) into the N900 microb browser is definatly something I want to see happen (although I lack the skills and knowledge to actually help with it) Dec 06 08:28:27 jonwil: did you look into the kbd blob thingie in maemo? Dec 06 08:28:36 which kbd blob? Dec 06 08:29:00 the one that handles the sticky Fn and shift keys and all that stuff Dec 06 08:29:19 and thr symbol vkbd Dec 06 08:30:22 I dont know which package handles all that Dec 06 08:30:40 Which bit about Apple is bad? The fact that Apple has to sign the OS at the time of installation, or the fact that applications are proerly sandboxed? Dec 06 08:30:48 but no, I dont have any reverse engineering going on of any of the remaining closed-source blobs Dec 06 08:30:52 * Maxdamantus likes the latter thing, not the former thing. Dec 06 08:31:04 we spotted it a month or two ago Dec 06 08:31:26 jonwil: problem is you wouldnt have to write new, just use any of combo sploits, and most likely it will work Dec 06 08:32:50 The issue I have with Apple is that you need to pay money to be able to write and distribute apps for the devices, something you dont need to do for most distribution platforms/. Dec 06 08:33:02 You dont need to pay money to be on the Android store Dec 06 08:33:04 or the Amazon store Dec 06 08:33:11 or the Windows store Dec 06 08:33:45 Yeah, that's related to why Apple has to sign the OS at installation. Dec 06 08:33:46 jonwil, KotCzarny, did you see this thread? http://talk.maemo.org/showthread.php?p=1520078#post1520078 Dec 06 08:35:29 wizzup: yup, but im hacking something else atm Dec 06 08:36:12 DocScrutinizer05: regarding vkbd on maemo, I'd tend to thing we should just move away from it and try integrating ibus Dec 06 08:36:42 jonwil: likely related to your thread here http://talk.maemo.org/showthread.php?t=93889 Dec 06 08:37:32 The biggest issue with Fremantle-on-new-hardware right now is the incomplete PulseAudio blobs Dec 06 08:38:08 also the cellular daemons Dec 06 08:38:57 https://blogs.gnome.org/wjjt/2010/07/15/sending-smses-with-empathy-and-telepathy-ring/ Dec 06 08:39:58 Why do you need the PulseAudio blobs for non-N900 hardware? Dec 06 08:40:05 aiui that's the perfect API spec for all such "cellular daemons" we'd need for another modem Dec 06 08:40:13 For the Neo900 we need them Dec 06 08:40:17 except audio Dec 06 08:40:33 jonwil: right, but I don't think the porting efforts are at that point yet, at least the porting efforts I am thinking of Dec 06 08:40:34 since we are planning to make the Neo900 run the same Fremantle software stack Dec 06 08:40:51 jonwil: well... Dec 06 08:40:56 can pa blobs be used on mainline kernel or they are tied to specific version? Dec 06 08:41:09 KotCzarny: you can use old PA on new kernel Dec 06 08:41:29 jonwil: this is about the fremantle software stack, maemo fremantle is using telepathy-ring Dec 06 08:41:34 afaik Dec 06 08:41:37 yes I know Dec 06 08:41:39 jonwil: I think some recent efforts seem to be on getting h-d and other components based upon devuan/debian, and move whatever is worth keeping there Dec 06 08:41:48 we may still be able to run the old PA on top of that Dec 06 08:41:56 but for other devices, we may not need the PA modules, and even so, they *can* be REed Dec 06 08:42:06 wizzup, or make it selectable on install Dec 06 08:42:09 Yes the PA blobs can be REd Dec 06 08:42:22 but right now I am not sure if that's the main priority Dec 06 08:42:36 its just that no-one with the needed skills has shown any interest in finishing the work. Dec 06 08:42:54 as in, once we get to the point where we can run devuan with maemo settings and some other programs, like xterm, and some wifi, on my tablet, (and then consequently, on the n900 again), I'd look into it Dec 06 08:43:03 There seem to be several different related goals here: Dec 06 08:44:13 First is being able to upgrade the N900 Fremantle software stack so its more modern and replacing outdated versions of things with new things (e.g. can we replace microb with a non-sucky browser?) Dec 06 08:44:17 (quick interjection - I am interested in many maemo porting efforts, just not one that pours a lot of effort but does not contribute to the end goal, e.g. modern sw stack) Dec 06 08:44:57 This may also tie into CSSU and the goal of improving the Fremantle stack Dec 06 08:45:10 PA is no problem anymore I'd think. The remaining non-REed PA blobs are utterly not-needed for another modem. xprot is needed to avoid nuking your speakers in N900 when you're dense enough to pump up the volume and wait till magic blue smoke escapes Dec 06 08:45:39 freemangordon: I found this post, too - http://talk.maemo.org/showthread.php?s=f198d88a1d3da561bbfec0ccc2ae2e84&t=91308&page=17 Dec 06 08:45:57 the PA-nokia-speech(?) is improving quality of voice calls but not exactly mandatory even for N900, it can get replaced by a "cat" dummy Dec 06 08:46:31 jonwil: so, my 'personal goal' here would be to get whatever is useful from fremantle, and 'free' it from the old maemo distro, and make it run on a modern base, e.g. devuan/debian. And then, make *that* run on the n900 again Dec 06 08:46:55 While in the process, ensuring it's also viable for other things -- tablets (for usage), qemu images (for testing), etc Dec 06 08:47:14 at any point more things from fremantle can be ported over, of course Dec 06 08:47:33 and one can even imagine a full chroot-kind setup (if required) with maemo compat layers where that would be required for older 'apps' Dec 06 08:48:09 I'm just not interested in very old kernels and sw, that is even more my beef than an aging browser, but I'm sure the things are inherently related Dec 06 08:48:44 Wizzup: where would you stop on such effort? OHM? PA? alsaped? mce? calendar? Dec 06 08:49:37 ((nherently related)) yes, that's exactly the point Dec 06 08:50:42 DocScrutinizer05: well, I would aim for base bones first. and then port over anythign that is deemed useful Dec 06 08:50:46 note that you can always port over more Dec 06 08:50:58 I would likely stop when it comes to wifi-specific daemons, for example Dec 06 08:51:13 Since they serve no purpose outside of fremantle and only cause headaches for devuan, for example Dec 06 08:51:24 or would that "compatibility layer" be xephyr on wayland for running hildon-desktop in a window of debian then? Dec 06 08:51:25 Where one can easily use any of the other wifi daemons (wpa_supplicant + some frontend) Dec 06 08:52:02 DocScrutinizer05: the compatibility layer I meant could be some hack to export the same dbus interfaces, and a chroot with old maemo rootfs + x forwarding over unix socket Dec 06 08:52:30 s/base bones/bare bones/ Dec 06 08:52:46 I think this DefCon video https://www.youtube.com/watch?v=1cgtr7VW7gY has some interesting ideas that might help us out Dec 06 08:52:59 so clearly, applications that directly interface with the closed wifi daemon won't work anymore Dec 06 08:53:03 but that's likely not a problem :) Dec 06 08:53:04 X would just be handled by having /tmp/.X11-unix bind-mounted; don't need forwarding. Dec 06 08:53:15 Maxdamantus: yeah, that is what I meant, but sure Dec 06 08:53:18 wrong terminology Dec 06 08:53:31 (wifi) some savvy devel, (was it timeless? crashndie?) sighed loudly "I wish Nokia had opensourced ICD!! It's so much better than any of the other connection managers existing" Dec 06 08:53:54 err prolly not ICD Dec 06 08:54:00 or yes? Dec 06 08:54:02 With the PulseAudio blobs we could take the secret sauce algos (i.e. the bits that make voice sound good) and have our own pulseaudio-blah plugin just call into pulseaudio-module-nokia-voice and call the secret bits. Dec 06 08:54:07 DocScrutinizer05: in all honesty, it's probably best to surrender here and use networkmanager Dec 06 08:54:12 * Maxdamantus would be happy enough just using wpa_supplicant. Dec 06 08:54:27 jonwil: to work around abi problems with newer PA? Dec 06 08:54:30 i wholeheartedly hate nm Dec 06 08:54:34 KotCzarny: me too Dec 06 08:54:41 but it might offer a simple dbus interface to wifi Dec 06 08:54:45 Wizzup: why a chroot? Dec 06 08:54:47 idk, ok, maybe nm is not the best Dec 06 08:55:15 DocScrutinizer05: if you want to use the old pkg managers as well. it may work with ld_library_path and so, but the exact details don't matter IMHO Dec 06 08:55:29 o.O Dec 06 08:55:29 DocScrutinizer05: because it's there to handle legacy stuff that hasn't been installed as part of a newer distribution. Dec 06 08:55:35 DocScrutinizer05: (at this point) Dec 06 08:55:48 Maxdamantus: right, but I recall that DocScrutinizer05 doesn't like using chroots to prevent mixing old and new libs Dec 06 08:55:49 I don't see need for *any* of that Dec 06 08:55:53 to work around both ABI issues if we move to a newer PA and to work around the need to replace some things in pulseaudio-module-nokia-voice (e.g. the bits that talk cellular call audio) and keep using the bits we haven't yet cloned from the Nokia blob Dec 06 08:55:57 maemo IS devuan Dec 06 08:55:57 so very soon we'll be talking about SONAMEs Dec 06 08:55:58 :p Dec 06 08:56:28 jonwil: yeah Dec 06 08:56:46 I actually wrote a tool to rip functions out of a binary into an obj file myself for a totally different project (this was for Windows PE files and Windows COFF obj files) Dec 06 08:56:56 jonwil: if that doesn't give trouble with mixing glibc versions in the same process Dec 06 08:57:01 But whats in that video (talking about re-using bits of binaries on Windows) Dec 06 08:57:10 I mean on linux Dec 06 08:57:12 makes sense Dec 06 08:57:31 old and new libs can easily coexist in linux, unless somebody completely messed up Dec 06 08:57:55 err Dec 06 08:58:06 it "can" yeah Dec 06 08:58:06 ooh Wizzup beat me to it Dec 06 08:58:34 DocScrutinizer05: right, but to prevent conflicts and packages installing over other pkgs, isolation may be easier, not to mention that it may be easy/doable at all to merge the package managers, and so on Dec 06 08:58:37 Heck we could potentially even do what I am doing on Windows and rip the bits we still need out of the shared library into a static obj file that gets linked into our shared lib. Dec 06 08:58:55 jonwil: still, if the modules are in the same process, old/new glibc may mess you over Dec 06 08:59:02 e.g. new PA want new glibc, binary old PA wants old glibc Dec 06 08:59:05 huh? Dec 06 08:59:05 can't mix that in one process Dec 06 08:59:21 Wizzup: glibc? how comes? Dec 06 08:59:30 I am sure you can load multiple versions of glibc into a single process Dec 06 08:59:38 uh... are you? OK Dec 06 08:59:42 I wasn't so sure about that Dec 06 08:59:55 Which one will set up the signal handlers, then ;-) Dec 06 08:59:57 etc Dec 06 09:00:19 I'm pretty sure it'd be a freaking mess ;) Dec 06 09:00:22 why would you want old PA? Dec 06 09:00:35 DocScrutinizer05: because of old nokia modules I guess Dec 06 09:00:35 for n900 modem voice/audio quality Dec 06 09:00:44 no need Dec 06 09:01:23 also I understood you're focusing on NON-N900 target platforms more than on N900 Dec 06 09:01:53 tbh, this is #maemo, not #n900 ;) Dec 06 09:02:05 and as elaborated above those modules will be mostly pointless on any other platform with another modem Dec 06 09:02:22 it only happens that only/mainly maemo runs on n900 nowadays Dec 06 09:04:15 the end goal is to have it running on the n900 as well, of course Dec 06 09:04:25 but we don't need burden every platform with old PA blobs for that. Dec 06 09:06:08 In any case if/when we want the secret bits for the Neo900 FPTF project (or otherwise want them) there are ways we can get at them that dont require reverse engineering them completly. Dec 06 09:06:19 I'm pretty sure it won't just load multiple versions of glibc. Dec 06 09:06:36 ie, ld-linux won't do that for you. Dec 06 09:06:41 pretty sure as well Dec 06 09:06:59 you can of course use dlopen/dlsym yourself to load separate instances. Dec 06 09:07:29 And if we did something similar to what I am doing on Windows, we could make it completly independent of libc versions as well through stubs. Dec 06 09:07:46 which prolly won't work properly because part of the glibc functions will be looking for global resources Dec 06 09:08:47 Wizzup: let me tell you a story about a similar project called OM. They based the OS on Aegstrom / Openembedded and the result was that literally *everything* you are used to from a normal linux got ripped out since "for embedded you don't need users or authentication or file owners/permissions or...". Then they reinvented the wheel for arain everything except a lot of stuff that didn't get added til today. E.G users, so SHR afaik still Dec 06 09:08:49 runs everything as root. The parallels I see here are: why would you want to make piecemeal with porting only a 5% bare bones core stuff to e.g. Devuan, when it's so much simpler to port Devuan core stuff to maemo? Dec 06 09:10:07 wtf? Dec 06 09:10:25 what does that even mean, porting devuan core stuff to maemo? Dec 06 09:10:51 I am still getting nowhere with my entry for the coding contest :( Dec 06 09:11:02 what does "port maemo to another disrtro" mean? maemo IS a distro Dec 06 09:12:07 DocScrutinizer05: that's why they/we only talk about porting maemo bits to Dec 06 09:13:02 sorry I fail to see the purpose Dec 06 09:13:42 have a maemo-like phone-friendly environment on top of a modern ecosystem? Dec 06 09:14:11 what the heck is the difference between Devuan and maemo 2ecosystem"? Dec 06 09:14:29 you've always been focusing on old apps compatibility (sw wise) and n900 droppin replacement (hw wise), but ... Dec 06 09:15:51 DocScrutinizer05: as it stands the two are just "incompatible", ie welcome to dependency hell Dec 06 09:16:13 so I have to "rebase" your ecosystem in some way Dec 06 09:16:27 s/I/you/ Dec 06 09:16:31 isnt opensource about ability to recompile packages if need arise? Dec 06 09:17:02 new kernel? FMG is pretty much there - on maemo! New glib? I think that's projected in CSSU since ages, and yes *there* we might need LD_PRELOAD for old apps. App Manager? I think Devuan also uses apt Dec 06 09:17:23 DocScrutinizer05: different end goals. Dec 06 09:17:53 so you don't want to port maemo, you want to change it Dec 06 09:18:03 freedom: I want the fremantle stack (the useful) parts available for other distros, not just stuck to maemo. 2) Maintenance - OUTSOURCE AS MUCH AS WE CAN - by piggybacking on the back of other distros Dec 06 09:18:13 Only this way we can ensure that we will keep a modern base Dec 06 09:18:23 This also means porting to gtk3, qt5, whatever is out there Dec 06 09:18:37 I don't see any point in taking whatever 'devuan core' is and putting it back into maemo Dec 06 09:18:56 that will become, I think, an unmaintanble mess, which leads to ... no maintainers Dec 06 09:19:22 the end result of your approach is exactly the same as mine Dec 06 09:19:33 so we are miscommunicating? Dec 06 09:19:42 obviously Dec 06 09:20:03 :] Dec 06 09:20:09 :) Dec 06 09:20:12 I just say when you completed your approach that won't be Devuan anymore, that will be maemo Dec 06 09:20:28 well, that's fine Dec 06 09:20:35 When the core changes, just tell N900 users to download and run this script to automatically update necessary configurations and move programs from /bin to /usr/bin: http://maemo.org/devuan-patch-99215.sh Dec 06 09:20:41 I don't see why it wouldn't be maemo, but yeah, that's fine Dec 06 09:20:43 as long as people on a devuan can install it with some apt repo && apt-get install Dec 06 09:21:03 s/maemo/devuan/ wtf brain Dec 06 09:21:06 unless you indeed want to kicj as many maemo heritage as possible for using more generic crap Dec 06 09:21:32 ? Dec 06 09:21:39 My preference would be for distro-supported solutions (and sw that is being supported still), and doesn't cause too much headache Dec 06 09:21:43 kicking pa crap wouldnt be bad Dec 06 09:21:47 e.g. porting the old closed source wifi daemon seems like a no-no Dec 06 09:22:00 but when it comes to most other bits, keeping them seems sensible Dec 06 09:23:04 there's no wifi daemon in maemo, that's the Internet Connection Daemon and manages all sorts of connectivity Dec 06 09:23:32 and of course you can replace it by a feature-compatible other solution Dec 06 09:24:14 I think we're really on the same pag Dec 06 09:24:15 e Dec 06 09:24:33 we can work out what to port and what not to port when it's the time to make decisions about that, or we can always decide to port more stuff later Dec 06 09:24:50 I really have to start work now, though. Back later Dec 06 09:25:06 I know of at least one user in here who nuked ICD and used ifup/ifdown manually. He complained about maemo apps not noticing when a new connection got established and when it got torn down, though Dec 06 09:25:25 networkmanager likely has a similar dbus api ;-) Dec 06 09:25:30 *cough* but yeah Dec 06 09:26:01 to be honest if we can a major part of the stack running on a modern base, I'm sure these things will kind of work out Dec 06 09:26:14 we can start with ifup/ifdown and plain wpa_supplicant, and work from there Dec 06 09:27:02 my approach is it's way easier to port the whole bunch at once and see what doesn't work, while profiting from the parts that _do_ work since they are highly entangled as you already stated yourself Dec 06 09:27:55 Wizzup: network-manager *cough*cough* :) Dec 06 09:28:17 but yeah, agree with you Dec 06 09:28:18 why try to make maemo apps run on icewm or whatever when porting H-D is a nobrainer Dec 06 09:28:32 DocScrutinizer05: huh? Dec 06 09:28:39 h-d is finger/touch friendly Dec 06 09:28:46 it makes sense to port it Dec 06 09:29:43 every single bit you "port later" will make another 5 bits fail and you need to mess around to make them work again without the missing bit Dec 06 09:30:05 some of those bits just aren't trivial to port Dec 06 09:30:23 you'll notice that when you try Dec 06 09:30:39 or are closedsource, thus depending on old ABI no longer compatible with modern libs Dec 06 09:31:02 DocScrutinizer05: I think they're already working on it and already noticed ... Dec 06 09:31:05 it doesn't make sense to start with "let's throw a dice which bit to port this week and try to make it work" Dec 06 09:31:14 meh Dec 06 09:31:37 anyway I'm not working on this, I have no word on this topic tbh Dec 06 09:33:39 it's literally already starting with PID1 Dec 06 09:34:54 I pushed so hard for Devuan since I don't know of another distro that would allow to keep maemo's init system Dec 06 09:34:55 DocScrutinizer05: h-d is the first thing that is ported Dec 06 09:35:17 I'm not sure why you'd want to make maemo init-system specific though Dec 06 09:35:46 because the init system does a friggin lot for usability of the whole device Dec 06 09:36:33 that just sounds a bit like a platitude, but yeah, uh ... going for upstart with devuan seems like ... weird? Dec 06 09:36:38 there's a reason maemo uses busybox and preinit script instead of e.g. systemd Dec 06 09:36:47 I don't think, I am not interested in this as long as most things not relying on init aren't yet ported. Dec 06 09:37:13 bencoh: why not work on it? :) Dec 06 09:37:50 DocScrutinizer05: a part of making the 'maintenance' easier is to work with the distros / modern libs, not against them, so I don't think it makes sense to bring over every API if the only maintainers of it are ... we Dec 06 09:38:10 for some things it makes perfect sense, but I am not so sure if sysvinit / openrc aren't also perfectly capable of doing the same job Dec 06 09:38:25 but again, I don't think that's important right now Dec 06 09:39:39 dont forget to k.i.s.s. Dec 06 09:40:00 then any porting to another distro wouldnt be hard Dec 06 09:40:02 sure they are capable... when you ADAPT them to the specific phone-embedded needs Dec 06 09:40:46 DocScrutinizer05: I am ignorant on how useful upstart is for n900/fremantle/maemo, so I will have to learn on to go, but for now I -personally- don't think it makes sense to only start upstart Dec 06 09:40:52 otherwise you will suffer a 4 minutes boot time with no option for 911 calls, no device lock, no... you name it Dec 06 09:41:01 As I said, there are other uses for hildon, beyond the n900 Dec 06 09:41:13 well, for tablets that is likely not an issue Dec 06 09:41:34 and it's a huge burden for someone just 'wanted to get the hildon desktop' to have to get upstart, which is completely dead, not supported by any distro, and so on Dec 06 09:41:44 right now n900 uses upstart and boot time is long, so i dont see the rant point Dec 06 09:41:46 essentially that's a very deep lock-in to a specific distro Dec 06 09:41:52 I'm not interested in tablets and a maemo not useful for a phone anymore Dec 06 09:42:11 to have emergency os would be a must for such thing Dec 06 09:42:32 and in such rescue/emergency ramdisk one wouldnt have to stick to things that are on rootfs Dec 06 09:44:03 I can't think of any technical reason to lock down to an old unsupported initsystem. I would say: go generic, and then specialise. Not: stay locked within a mostly deprecated specialised corner Dec 06 09:45:19 but really, I think much of this is of no problem at this point Dec 06 09:45:44 what makes you think you couldn't replace upstart by wahtever you want, LATER? and *start* with porting as much as possible, to make as much as possible have an environment where it actually works since e.g. the initscripts are 'just working'? Dec 06 09:47:38 DocScrutinizer05: very simple. because you can boot devuan, apt-get install maemo packages Dec 06 09:47:41 and bring up the ui Dec 06 09:47:42 make the wifi work Dec 06 09:47:44 test audio Dec 06 09:47:48 port over other applications Dec 06 09:47:50 calendar stuff, etc Dec 06 09:47:58 and only then worry about making the init specific to a phone Dec 06 09:48:09 the first part is porting it all to the new libs Dec 06 09:48:18 and testing individual pieces Dec 06 09:49:15 and the decision between (what I started on, with my anecdote about OM) "ripping all out to `start simple´ and then try to add one by one to the piecemeal" and "port everything and see what simply works and does NOT cause trouble and maintenance burden, and LATER replace one by one with new stuff and give it love until the new replacement really works in the way the old did" is not something for later Dec 06 09:49:48 I'm sure it causes trouble, but it also causes devs to *understand* the API and decide if it makes sense to keep them Dec 06 09:49:59 and really, I think devuan already works right now Dec 06 09:50:09 I don't see any other practical way of porting in the first place Dec 06 09:50:11 what do you suggest? Dec 06 09:50:43 I suggest to insstall all maemo stuff over Devuan, basically Dec 06 09:51:23 not to try male one particular bit work in an environment that's not maemo Dec 06 09:51:28 make* Dec 06 09:51:54 but you will still have to port all those things Dec 06 09:52:04 and once they are ported, you are free to do that, right? Dec 06 09:52:07 port? Dec 06 09:52:13 define "port" Dec 06 09:52:26 make it work with gtk3, new glibc, new openssl Dec 06 09:52:32 (and soforth) Dec 06 09:52:40 why GTK3?? Dec 06 09:52:48 because it is actually getting updates Dec 06 09:52:54 o.O Dec 06 09:52:58 and to get rid of the gtk-specific patches Dec 06 09:53:21 see https://github.com/fremantle-gtk3 Dec 06 09:53:31 I don't see that leading *anywhere* Dec 06 09:54:18 well, h-d is already running Dec 06 09:54:24 you're not porting maemo, you want to come up with a whole new OS, much like back on Harmattan Dec 06 09:54:32 hey, uhm Dec 06 09:54:40 It's not my idea per se Dec 06 09:54:54 I'm just trying to unify goals and move fremantle/maemo/hildon forward Dec 06 09:55:03 I clearly seem to be failing, at least partially Dec 06 09:56:32 and - considering how long it took Fremantle to become mature, and useful and how many devels were involved, and how 'well' meego went - I don't think this will result in anything tangible in the next maybe 5 years Dec 06 09:57:08 I hope for a more bright future. Simply being able to launch applications, having hildon-desktop, some of the settings, the calendar is already a nice start Dec 06 09:57:49 forget about calendar, it's nonfree and you *never* will port it to GTK3 Dec 06 09:58:00 I thought that was already happening Dec 06 09:58:35 anyhow, it's not impossible to take shortcuts and use gtk2 as well in some places. Dec 06 09:58:49 now we're talking Dec 06 09:58:53 :-) Dec 06 09:59:48 what I suggest is basically just to take as many 'shortcuts' as possible and then kill them one by one and replace them with decent solutions Dec 06 10:00:15 we'll have to strike some balance Dec 06 10:00:21 I have no clear overview -at all- Dec 06 10:00:21 of course Dec 06 10:00:26 (yet) Dec 06 10:01:51 as long as the approach is common sense and agreed upon, that's negligible detaols :-) Dec 06 10:02:21 the balance will come naturally during "porting" Dec 06 10:02:33 I think so too! Dec 06 10:04:17 and i'm rather optimistic that the immanent laziness of all devels (which is a virtue as we all know) will automatically result in my 2take as many shortcuts as possible" approach in the end. I just hope that *eventually* we will get rid of all those shortcuts and have a clean shiny new maemo based on Devuan Dec 06 10:04:49 :) Dec 06 10:07:01 and heck, if we actually need a chroot for the dialer crap, so what? Dec 06 10:07:47 yep Dec 06 10:07:54 kill gtk3 Dec 06 10:07:56 kill gtk Dec 06 10:10:26 maybe that's actually a viable approach: male one "huge" chroot for *all* fremantle (from init to PA to dialer and ICD) under Devuan, then one by one try moving programs out of the charoot and run in native Devuan Dec 06 10:10:32 luke-jr: aloha - if you want to help out - http://talk.maemo.org/showthread.php?p=1520077#post1520077 Dec 06 10:10:37 s/male/make/ Dec 06 10:10:45 Wizzup: I don't. Dec 06 10:10:51 luke-jr: in the end the packages can be wrapped in ebuilds as well, resulting in a maemo-meta ebuild Dec 06 10:11:07 I consider Maemo dead. Dec 06 10:11:21 did you read the post, or? Dec 06 10:11:23 probably will /part this channel some month soon. Dec 06 10:11:43 ... :) Dec 06 10:11:51 luke-jr: whats your new toy/de ? Dec 06 10:12:03 KotCzarny: don't really have one yet. Dec 06 10:12:15 but I also haven't touched N900 in months except putting it in my pocket. :x Dec 06 10:12:20 luke-jr: then dont consider maemo dead yet Dec 06 10:12:37 I did install Gentoo on a GPD Win recently, but no battery charger driver :/ Dec 06 10:13:02 nor audio nor touchscreen (but tbf, touchscreen didn't work in Windows either) Dec 06 10:13:23 o/ Dec 06 10:14:04 you might consider putting fremantle on it, once it gets ported to devuan Dec 06 10:14:25 and that's why you should click wizzup's link Dec 06 10:14:32 I hate GTK Dec 06 10:15:26 what happened to Harmattan? Dec 06 10:15:41 who knows? who cares? Dec 06 10:15:47 at least it was Qt Dec 06 10:15:54 luke-jr: prefer qt? Dec 06 10:15:54 ah Dec 06 10:16:07 currently I am running KDE Dec 06 10:16:31 (I also prefer qt, but gtk is def. better for now with porting) Dec 06 10:16:34 also - afk :) Dec 06 10:16:59 there wasn't really much I liked about Maemo. :x Dec 06 10:17:41 probably just having the task switcher a single touch away, but anything can do that Dec 06 10:18:44 Apple! :) Dec 06 10:19:38 sicelo: die :< Dec 06 10:19:58 < luke-jr> probably just having the task switcher a single touch away, _but anything can do that_ Dec 06 10:20:04 ;) Dec 06 10:23:03 maybe getting an N900 was a bad decision Dec 06 10:23:20 nope. Dec 06 10:23:59 but tools should be chosen with tasks/preferences in mind Dec 06 10:24:40 if i'd never got it, most likely i wouldn't be finding fine Android phones to be junk :( Dec 06 10:25:35 they are not junk. more toys, eye candies Dec 06 10:25:42 yes, that Dec 06 10:27:14 sicelo: what would I use besides N900? Dec 06 10:27:33 * luke-jr wonders what he did before N810 Dec 06 10:27:40 laptop? Dec 06 10:27:43 3310 ? Dec 06 10:27:45 pretty sure I had retired my C760 by then Dec 06 10:27:47 i've had an SGS4 for 2.5 months now ... once an Android flagship, hardware way better than N900 ... but i feel empty when using it ... my N900 is still the busiest device Dec 06 10:28:56 now I'm wondering what I used my N900 for. Dec 06 10:29:05 what do you use now? Dec 06 10:29:40 I don't usually leave home. Dec 06 10:29:52 when I do these days, I play Pokemon Go on a Nexus 5X Dec 06 10:30:52 KotCzarny: freemangordon : how sustainable is this AllWinner A13 platform .. can we expect on-going support? or? Dec 06 10:31:00 hm, I guess I used N900 waiting at doctor's offices Dec 06 10:31:06 I don't go to them very often anymore. Dec 06 10:43:49 luke-jr: we already discussed that, but I don't think your battery charger issue would be too difficult to solve (gpdwin) Dec 06 10:44:00 since we already found the spec Dec 06 10:44:16 it does look like it's a matter of a few i2c commands Dec 06 10:48:07 bencoh: I'm not sure that's the spec :/ Dec 06 10:48:14 the datasheet there DOES have a Linux driver Dec 06 10:48:17 I' quite sure it is Dec 06 10:48:27 luke-jr: which one? Dec 06 10:48:32 AXP288 Dec 06 10:48:38 there is a platform driver, and you already have it tbh Dec 06 10:48:53 https://bugzilla.kernel.org/show_bug.cgi?id=88471#c63 seems relevant Dec 06 10:48:54 04Bug 88471: was not found. Dec 06 10:48:56 luke-jr: that's a gas gauge Dec 06 10:48:58 not a charger Dec 06 10:49:13 well, axp is also a charger Dec 06 10:49:23 sicelo: allwinner a33 is just one series Dec 06 10:49:26 at least axp209 is one Dec 06 10:49:34 sicelo: there's a community trying to support allwinner platforms Dec 06 10:49:46 (e.g. MoeIcenowy has done a lot of work for the a33) Dec 06 10:49:48 yeah I was atalking about the driver, I dunno whether it controls the charger part ... but looking at the code, it might, actually Dec 06 10:50:01 drivers/power/supply/axp288_charger.c Dec 06 10:50:02 I don't know of any allwinner *phones*. But there are tablets with modems Dec 06 10:50:02 but it might use another device for battery Dec 06 10:50:05 luke-jr: maybe you just need to add a few line to your devicetree then Dec 06 10:50:13 bencoh: I have no devicetree. ACPI. Dec 06 10:50:15 luke-jr: ah, I dont have that one here Dec 06 10:50:20