**** BEGIN LOGGING AT Wed Nov 30 03:00:01 2016 Nov 30 08:02:44 when ISPs would care about their customers' security at all, they'd ship preconfigured DSL routers instead of running a TR-069 infra” Nov 30 08:02:44 Telus, a DSL provider in Canada, provides to their DSL customers a crappy all-in-one box with DSL modem, Ethernet switch, Wireless LAN access point, and some useless-to-persons-like-me stuff for television/telephone service all integrated into one device. Nov 30 08:03:33 * brolin_empey wants SDSL instead of ADSL. Nov 30 08:12:12 The opposite of AM is FM, not PM. Nov 30 14:57:41 Short outage due to misbehaving board/nics in blade-b, we're trying one solution now, will try another tomorrow if this didn't work out. Nov 30 18:33:05 Pali: any idea what to replace maemo hal with on modern distros? Nov 30 18:33:22 no :-( Nov 30 18:33:27 maemo apps needs hal Nov 30 18:33:54 isn't udev a replacement? Nov 30 18:34:11 yup Nov 30 18:34:12 udev Nov 30 18:34:20 no udev, is not replacement Nov 30 18:34:21 I mean - in terms of functionality Nov 30 18:34:22 what do you need hal for anyway? Nov 30 18:34:37 udev is just subset of hal features Nov 30 18:34:40 most of its functionality are kludges above sysfs, afair Nov 30 18:34:42 api is incomaptible Nov 30 18:34:58 udev is versatile Nov 30 18:35:04 that don't deserve to exist Nov 30 18:35:11 you can do whole lot of tricks Nov 30 18:36:02 o.o Nov 30 18:36:10 KotCzarny: if you are knowledgeabe with udev, could you help with https://github.com/fremantle-gtk3/hald-addon-bme Nov 30 18:37:13 KotCzarny: this is the last thing I need to be able to build mce in devuan jessie Nov 30 18:37:14 um, not that im knowledgeable, bur udev can exec arbitrary scropts/binaries Nov 30 18:37:27 hmm, this is not the point here Nov 30 18:37:56 hal calls callback functions when a device is added/removed etc Nov 30 18:37:57 what does it needs to do then? Nov 30 18:38:07 yes, that's what udev does Nov 30 18:38:12 it can react on events Nov 30 18:39:36 freemangordon, hm, what about diffing mce with Mer version? Nov 30 18:40:08 for example this is my ghetto auto(u)mounter: http://pastebin.com/raw/qVLLpKA5 Nov 30 18:40:16 NotKit: there is no mce in Mer afaik ;) Nov 30 18:40:21 https://git.merproject.org/mer-core/mce/tree/master Nov 30 18:40:40 you can add events by observing udevadm monitor Nov 30 18:41:16 NotKit: mce in fremantle talks to hald_addon_bme Nov 30 18:41:43 you can have multiple conditions that needs to match (to differentiate betweeen similar events) Nov 30 18:42:14 KotCzarny: that's great, but I am not sure it is the right time to learn a whole new API :) Nov 30 18:42:34 nah, think of it as a scripting language ;) Nov 30 18:42:40 api is too big wor Nov 30 18:42:41 d Nov 30 18:43:28 but as i've said, it has ability to run arbitrary script depending on events, which means almost unlimited flexibility Nov 30 18:43:57 KotCzarny: but I don;t want a script, but a daemon Nov 30 18:44:35 explain? Nov 30 18:44:49 look at what the code ^^^ does Nov 30 18:45:30 KotCzarny: what is the udev way of libhal_device_set_property_string? Nov 30 18:46:03 never used hal, tbh Nov 30 18:49:19 hmm, seems it will be easier to just build hal Nov 30 18:49:40 \not really, you want to port it to modern system Nov 30 18:49:50 sure, but not now Nov 30 18:50:10 h-d has higher priority imo Nov 30 18:50:18 temporarily its fine Nov 30 18:50:26 yeah Nov 30 18:50:34 but for long term you should define functionality Nov 30 18:50:42 will mce run without hald_addon_bme as if it had no data? Nov 30 18:50:53 NotKit: sure Nov 30 18:50:55 instead of trying to relearn Nov 30 18:51:16 NotKit: but I don;t wanna start striping functionality Nov 30 18:54:39 as i understand, something should start on something? Nov 30 18:54:53 or its bus similar to dbus? Nov 30 18:55:05 both Nov 30 18:55:47 a daemon is started when a device with an "udi" is hotplugged, then this daemon receives events from hal Nov 30 18:55:52 aor something similar Nov 30 18:55:55 *or Nov 30 19:02:33 if we dont have hal anymore, it should receive events other way Nov 30 19:02:42 so there will be porting anyway Nov 30 19:03:17 I'll disable mce battery module for now Nov 30 19:04:22 what communicates with mce? Nov 30 19:04:40 everything :) Nov 30 19:04:48 fun Nov 30 19:04:58 might be good idea to reimplement whole shebang Nov 30 19:05:08 feel free to do it :) Nov 30 19:05:57 maybe hal should be replaced with udev+dbus mixture Nov 30 19:06:32 maybe Nov 30 19:07:23 luckily we dont have systemd to worry about Nov 30 19:07:24 ;) Nov 30 19:26:38 IIRC mce does not actually use the "regular hald battery" properties. there is some even older dbus signaling api that hald-addon-bme just to cater mce's needs Nov 30 19:27:56 and it should not be that difficult to mod the mce battery plugin to use whatever battery sources you have available Nov 30 19:29:31 spiiroin: correct Nov 30 19:29:59 I just need to find an upstream package that monitors battery/charger and provides dbus interface Nov 30 19:30:06 any idea? Nov 30 19:30:40 acpi? Nov 30 19:30:47 upower? Nov 30 19:30:51 apm? Nov 30 19:31:07 /sys/ interface? Nov 30 19:31:08 freemangordon, why not use sysfs? Nov 30 19:31:20 NotKit: from mce? Nov 30 19:31:46 I'd rather not, as there are more plugins that need to monitor the battery/charger status Nov 30 19:32:03 so it is better to have an unified backend that provides dbus interface Nov 30 19:32:04 fmg, /sys/ interface is standard and good idea Nov 30 19:32:26 for upower there is a plugin in mer mce. the datapipes involved are most likely still the same -> could be used Nov 30 19:32:30 on thinkpads i have /sys/ interface, on allwinner i have /sys/ interface Nov 30 19:34:18 spiiroin: yep, saw that, thus upower Nov 30 19:34:52 battery applet should be tweaked as well, but thats another story Nov 30 19:35:15 if it comes to it, then we aleady have working maemo :) Nov 30 19:35:48 the little mce needs is catered by: charger connected, battery percentage (led & power save mode triggering) Nov 30 19:36:42 :nod: Nov 30 19:36:53 and request_charger_status Nov 30 19:38:40 hmm, I'd rather replace hald_addon_bme with a daemon that talks to upower and implements bme interface Nov 30 19:39:14 that might be just due to that legacy^N dbus interface (mce could ask bme & co to resend battery signals it might have missed... which then caused problems for ui side on some circumstances) Nov 30 19:39:18 that way no changes in mce and the other thing that need bme dbus iface will be needed Nov 30 19:40:11 spiiroin: looking at the code, it is used on init, to get the entry conditions Nov 30 19:40:44 https://github.com/fremantle-gtk3/mce/blob/master/modules/battery.c#L377 Nov 30 19:40:51 freemangordon: yeah, bme starts before mce -> the signals could have gone already Nov 30 19:41:30 side effect that needed some patching somewhere in ui was: restart mce in suitable charging state -> ui sees repeated signaling Nov 30 19:41:41 which is not that bad, given that we are supposed to start services asynchronously Nov 30 19:42:12 sure, but the api is stupid; ask values -> global re-broadcast Nov 30 19:42:22 is it? Nov 30 19:42:28 hmm Nov 30 19:42:30 * freemangordon checks Nov 30 19:42:52 yes, luckily nobody but mce was listening to those anymore - problem solved Nov 30 19:43:21 iirc battery applet plugin is listening, but I might be wrong Nov 30 19:43:46 but that might/should be the hal props? Nov 30 19:44:06 i.e. different set of signals from what mce is listening to Nov 30 19:44:41 I could be wrong / mix devices though - it has been a while Nov 30 19:45:01 it is not that important Nov 30 19:45:10 anyway it is not going to be used Nov 30 19:46:17 well, if the hald is gone -> I'd just make mce use some/any more up to date source Nov 30 19:46:44 or rather - it will be used, but I see no problem in broadcasting of the status, so everybody on the party to have common data Nov 30 19:47:26 spiiroin: isn't it better to have a daemon that talks to whatever backend seems appropriate implementing bme interface? Nov 30 19:47:47 no changes in mce will be needed - we can keep common sources with CSSU Nov 30 19:49:49 hmm, seem slibupower is supported in all modern distros Nov 30 19:49:55 *libupower Nov 30 19:50:10 ok, solution found, needs some coding :) Nov 30 19:50:33 freemangordon: sure, common api is always good; but I would not start by definiing it as "needs to be bme signal compatible" Nov 30 19:50:58 spiiroin: why to change interface? Nov 30 19:51:11 I mean - unless there is a need? Nov 30 19:51:55 There is lots more stuff to be done first - we talk for porting the whole hildon stack to gtk3 Nov 30 19:52:45 sure, if there were 10 fulltime devs eager to work - np, we can change the interfaces every week :) Nov 30 19:52:46 whichever is less work - migrating to new hopefully standard api, or attempting to keep old api alive Nov 30 19:53:05 spiiroin: oh, I aim for both Nov 30 19:53:25 so did hald-addon-bme ;-) Nov 30 19:53:57 warts and all. even signal sending order was carved in stone Nov 30 19:54:22 well, it is not interface's fault that hal was deprecated :) Nov 30 19:55:02 maybe this should be left undecided for now Nov 30 19:55:14 anyway I am not going to write that daemon today Nov 30 19:55:51 could be that KotCzarny is right and we should deal directly with /sys Nov 30 19:56:29 hoping that /sys/class/power_supply ABI is finally stable Nov 30 19:59:19 * freemangordon wishes more devs to join the effort :) Nov 30 20:00:11 fmg: im hacking at something else atm Nov 30 20:00:13 spiiroin: BTW, in case you've missed it, I was able to run cordia h-d on allwinner tablet Nov 30 20:00:31 fmg: you should be saying 'on mainline linux tablet' Nov 30 20:01:00 well, yeah, on allwinner tablet running devuan jessie Nov 30 20:01:35 with mainline kernal, GPU and WIFI drivers are out-of-tree Nov 30 20:01:41 *kernel Nov 30 20:02:15 unfortunatelly, be it x86 or arm, 3d accel is usually blobbed :/ Nov 30 20:02:35 KotCzarny: however, cordia h-d was just a POC, it has too much functionality stripped for my taste Nov 30 20:02:47 well, better than nothing Nov 30 20:02:55 starting point Nov 30 20:03:05 adding pieces back, one by one Nov 30 20:03:15 maybe even stick to gtk2 for now? Nov 30 20:03:21 I meant - having 3d accell blobbed is better than nothing Nov 30 20:03:34 KotCzarny, on Atom tablets, 3D accel is open-source, but otherwise kernel support is still limited Nov 30 20:04:25 well, android808 wants gtk3, and he is half of the work force ;) Nov 30 20:05:18 ;) Nov 30 20:05:28 also I don;t see gtk2->gtk3 as being that much problematic, at least for now Nov 30 20:05:47 gtk2 would mean clutter 0.8 iiuc Nov 30 20:06:08 so yet another deprecated library Nov 30 21:14:51 will that neo 900 ever have whatsapp or other things that most people use? Nov 30 21:15:47 is it possible to buy a development license for whatsapp or something like that Nov 30 21:16:35 between my tablet that's faster than most phones and this "phone" I'm still not willing to switch to android without at bare minimum a qwerty keyboard Nov 30 23:57:52 fishbulb: get over whatsapp Nov 30 23:58:47 or get over linux Dec 01 00:00:45 name one wifi way of chatting and sending media that works with normal people's phones and this one Dec 01 00:01:52 so get over linux then Dec 01 00:02:15 if any worthwhile OS ran on this phone I would Dec 01 00:02:34 any other Dec 01 00:02:59 g'nite **** ENDING LOGGING AT Thu Dec 01 03:00:00 2016