**** BEGIN LOGGING AT Sat Jan 14 03:00:01 2017
Jan 14 05:18:00 <Oksanaa> What's wrong with the device? http://www.ebay.com.au/itm/291998141306 
Jan 14 05:36:50 <hurrian> no USB door/SIM holder?
Jan 14 05:37:56 <Oksanaa> Huh, the SIM holder should be easy to insert, question is how to add USB door, since it should be rotating on a hinge?
Jan 14 05:38:38 <hurrian> if you buy one brand new off eBay, you can just push it in - I don't have the service manual on me right now but it's easy to install
Jan 14 05:39:04 <hurrian> don't need to take off the screen etc - just push it in. takes a bit more force to pull it out though
Jan 14 05:40:03 <Oksanaa> Do the WiFi/Bluetooth/Camera on the device work, otherwise? If USB door is easy to install, and the case itself is not bent/damaged, then a repair should be straightforward...
Jan 14 05:40:18 <Michael_a380> Is anyone bidding? I was going to bid, it's 2 miles / 3 km from me.
Jan 14 05:40:42 <Oksanaa> Not going to bid. I am NSW, shipping would add up.
Jan 14 05:41:18 <Oksanaa> I already have a cyan N9, into which I inserted a SIM tray; it had no problems with USB door, though.
Jan 14 05:42:18 <Oksanaa> Michael_a380 : Good luck, you will be able to pick it up locally, and that's very nice.
Jan 14 05:44:27 <Michael_a380> Thanks. I'm still a little skeptical about unremovable battery. I found 'doors' here http://www.easyphix.com.au/?rf=kw&kw=Nokia+n9. Seems pricey for a bit of plastic.
Jan 14 05:47:25 <Michael_a380> Reflash sounds like a nightmare, compared to n900.
Jan 14 05:48:21 <hurrian> Michael_a380: first thing you'd need to do is check software version - if it's on an old release, flash to PR1.3 region 001 and call it a day :)
Jan 14 05:49:36 <Michael_a380> are you sure you don't want it, even as spare?
Jan 14 05:50:29 <Michael_a380> You would probably have better use of it.
Jan 14 05:54:35 <Michael_a380> It's sad that the bad guys are winning: Trustworthy Nokia N9 vs spying Android http://www.abc.net.au/technology/articles/2011/12/06/3384952.htm
Jan 14 05:55:04 <Oksanaa> Michael_a380 : Not that simple, the charging port cover is. http://thumbs.ebaystatic.com/images/g/RPcAAOSwnH1WZlmq/s-l225.jpg 
Jan 14 05:55:43 <Michael_a380> wow, thanks
Jan 14 05:57:05 <Oksanaa> Yes, we have no Android here, so far. Or WinPhone. Or iPhone. Or even Blackberry. Just some Firefox OS, some Symbian, some Maemo, some Harmattan, some Nemo. In various states of usability.
Jan 14 06:01:12 <Michael_a380> First thought the 'black part' was missing from the 'charger door' ad. Did you notice the charger door ad? http://www.easyphix.com.au/nokia-n9-charging-port-cover-red
Jan 14 06:01:41 <Oksanaa> Feel free to find Nokia N9 service manual
Jan 14 06:05:00 <Oksanaa> The small triangle of black plastic looks like a shadow.
Jan 14 06:09:58 <Michael_a380> Not sure what you're refering to? Would the plastic 'dents' indicate the screen was removed (phone was opened)?
Jan 14 06:11:26 <Oksanaa> Nay. Just, whatever accident caused removal of SIM tray and USB door, might have caused some bends. In my case, the corner of the device is slightly bent, so it's difficult for SIM tray to stay in here; it prefers to jump out.
Jan 14 06:11:43 <Oksanaa> Slightly, like, 1mm or less.
Jan 14 06:17:52 <Oksanaa> Feel free to register with NickServ, and/or https://maemo.org
Jan 14 07:25:24 <Oksanaa> N900 frightened me for a minute. After changing battery, it looked like LCD was cracked; 3+ parts of display, working or black or white; when touching, the parts changing their states (their shapes, too ; have seen a pentagon once). 1st clue: in list of apps, text was fine, icons weren't here. 2nd clue: LCD cracks don't disappear or change that quickly. Display driver glitch. Reboot fixed it.
Jan 14 07:41:50 <sicelo-> :-)
Jan 14 07:44:35 <Michael_a380> N900: "It's just a prank, bro".
Jan 14 08:26:50 <KotCzarny> :>
Jan 14 09:29:32 <Oksanaa> My hardware keyboard had no backlight. Why could it be?
Jan 14 09:32:49 <sicelo-> there's a script somewhere  (wiki perhaps) which can cycle them ..
Jan 14 09:33:09 <sicelo-> lots of possibilities .. faulty ribbon being one of them
Jan 14 09:33:30 <sicelo-> s/ribbon/flex cable/
Jan 14 09:33:31 <infobot> sicelo- meant: lots of possibilities .. faulty flex cable being one of them
Jan 14 09:35:06 <Oksanaa> Keyboard LEDs app : not lighting up
Jan 14 09:38:15 <Oksanaa> cannot create /sys/class/i2c-adapter/i2c-2/2-0032/engine3_mode: nonexistent directory
Jan 14 09:38:22 <sicelo-> uh oh
Jan 14 09:39:04 <Oksanaa> Does it mean "flex cable damaged" or "driver not loaded"?
Jan 14 09:40:02 <Oksanaa> Because it used to work recently, like, within last 24h, or I would have found typing difficult earlier
Jan 14 09:45:18 <Oksanaa> In fact, /sys/class/leds/ has only  twl4030:vibrator . Is it the RGB LED near the display? Or is my RGB LED also not working?
Jan 14 09:48:36 <sicelo-> i might be wrong .. maybe wait for more knowledgeable people to chime in
Jan 14 09:48:36 <Maxdamantus> It looks like all the other LEDs use the lp5523 controller.
Jan 14 09:48:59 <Maxdamantus> (keyboard backlight and status LEDs)
Jan 14 09:49:58 <Maxdamantus> for me they appear as /sys/class/leds/lp5523:{r,g,b,kb{1..6}}
Jan 14 09:50:29 <Oksanaa> kb ones are not here, definitely. Neither are RGB ones.
Jan 14 09:50:48 <Maxdamantus> So presumably your status LEDs don't work at all?
Jan 14 09:51:03 <Maxdamantus> ie, charge/notification indications
Jan 14 09:51:17 <Oksanaa> Yes, I think so. /Blanks the screen, waits for notification/
Jan 14 09:51:42 <Maxdamantus> I imagine a faulty cable wouldn't lead to that, but I'm not entirely sure.
Jan 14 09:52:10 <Oksanaa> These leds use different cables, right? 
Jan 14 09:52:14 <Oksanaa> /me considers reinstalling mce... In c
Jan 14 09:52:24 <Maxdamantus> Reinstalling mce won't help.
Jan 14 09:52:48 <Maxdamantus> I'm not sure what defines all the LEDs as existing. I think in newer kernels it would be defined by device tree.
Jan 14 09:53:01 <sicelo-> faulty flex definitely does cause non-working (or erratic) status LED .. my 2nd N900 has that
Jan 14 09:53:36 <Maxdamantus> Yes, of course it can prevent the LEDs from ultimately not working, but I don't think it would cause the LEDs not to show up in sysfs.
Jan 14 09:54:12 <sicelo-> let me recheck on that N900
Jan 14 09:55:55 <sicelo-> yes, i have them in /sys
Jan 14 09:57:59 <Maxdamantus> I suspect the actual controller is on the motherboard, not the front part.
Jan 14 09:58:19 <Maxdamantus> and I suspect there'll just be a wire on the ribbon cable for each of the status LEDs.
Jan 14 09:59:13 <sicelo-> makes sense .... /me would make bad EE 
Jan 14 09:59:14 <Maxdamantus> so with the ribbon cable disconnected, nothing really looks any different. The only way it could notice a difference is if it measured the resistance across the presumed LEDs.
Jan 14 10:00:20 <Maxdamantus> Oksanaa: I guess the obvious thing to do would be to look through dmesg for something relating to lp5523
Jan 14 10:01:07 <Oksanaa> Dmesg : where? /Yes, haven't done it for a very long time/
Jan 14 10:01:24 <Maxdamantus> maybe compare it to a normal dmesg .. my phone has been on too long to have the messages from boot atm
Jan 14 10:01:56 <Maxdamantus> You just run `dmesg`, and capture/analyse the output.
Jan 14 10:15:08 <freemangordon> Pali: hi! As you know I am trying to bring fremantle on jessie. now I am to the point of upstart scripts. How do you think - shall I keep sysvinit compatibility?
Jan 14 10:15:29 <Pali> hi
Jan 14 10:15:46 <Pali> this depends on which init daemons we should support
Jan 14 10:16:14 <Pali> if all --> then upstart scripts needs to be rewritten to init.d scripts
Jan 14 10:16:15 <freemangordon> well, who is to define that?
Jan 14 10:16:50 <Pali> if defaul debian init daemon (systemd) --> then upstart scripts needs to be rewritten to init.d script or systemd services
Jan 14 10:16:54 <freemangordon> what about upstart only? are there any drawbacks?
Jan 14 10:17:15 <freemangordon> I mean - /etc/init, not /etc/init.d
Jan 14 10:17:18 <Pali> if debian version of upstart --> then maemo upstart scripts needs to be moved to /etc/init/
Jan 14 10:17:30 <freemangordon> exactly
Jan 14 10:17:43 <Pali> and if you are going to patch debian version of upstart --> then no change is needed
Jan 14 10:17:51 <freemangordon> also, I am using devuan, not debian ;)
Jan 14 10:17:58 <freemangordon> why patch?
Jan 14 10:18:19 <Pali> because new upstart (in debian) does not scan /etc/event.d anymore
Jan 14 10:18:27 <freemangordon> ahh, sure
Jan 14 10:18:49 <freemangordon> but it is packages that should be fixed, not upstart :)
Jan 14 10:18:53 <Pali> for me solutions are:
Jan 14 10:19:14 <freemangordon> Pali: see https://github.com/fremantle-gtk2/ke-recv-extra/commit/fd7b7d80de45dfc07c36171e4c2d2a7a8b5672d4
Jan 14 10:19:35 <Oksanaa> mce.ini has Modules=display;keypad;vibrator;led;battery;filter-brightness-als;inactivity;alarm;accelerometer;callstate;camera;homekey;audiorouting , correct? Not seeing anything in dmesg, even when I restart mce, or ask ledpatterneditor to test a pattern
Jan 14 10:19:41 <Pali> 1. rewrite everything to init.d scripts --> this is supported by any init system (daemon which should be restarted on crash could use dsme)
Jan 14 10:20:19 <Maxdamantus> Oksanaa: it wouldn't be an issue with mce. The kernel is responsible for populating things in /sys
Jan 14 10:20:19 <Pali> 2. rewrite everything to use Debian's upstart --> renaming /etc/event.d to /etc/init.d and rewrite all Maemo init.d scripts to upstart
Jan 14 10:20:47 <Pali> 3. path Debian's upstart to support also /etc/event.d and no change in init.d and upstart scripts is needed
Jan 14 10:21:59 <freemangordon> Pali: I think I like (2) more then the others, at least for start. but why should we rewrite /etc/init.d scripts for upstart? see what ke-recv-extra startup scripts are doing
Jan 14 10:22:04 <freemangordon> *than
Jan 14 10:22:16 <Pali> if we want support for Maemo daemons/applications in other distributions too, I would go with (1)
Jan 14 10:22:48 <Pali> (2) is basicaly compatible only with distros which have upstart
Jan 14 10:22:54 <freemangordon> Pali: I see. but that would mean no dependencies between services, right?
Jan 14 10:23:10 <freemangordon> or rather - hardcoded boot order
Jan 14 10:23:21 <Pali> in init.d scripts you can specify some dependency
Jan 14 10:23:30 <Pali> see LSB header
Jan 14 10:23:32 <freemangordon> even with sysvinit?
Jan 14 10:24:11 <Pali> based on headers is generated fixed order
Jan 14 10:24:52 <Pali> what I do not like is that two different applications are responsible for restarting daemons (upstart and also dsme)
Jan 14 10:25:47 <freemangordon> Pali: what about - I will go with (2) for now, as I have all the dependencies in place, sort of. as soon as we have something more or less complete, then go for (1)?
Jan 14 10:26:12 <freemangordon> well, dsme does more things afaik
Jan 14 10:26:16 <Pali> ok
Jan 14 10:26:35 <Pali> (1) is harder as (2)
Jan 14 10:26:49 <Pali> so (1) takes also much more time
Jan 14 10:26:54 <freemangordon> yes
Jan 14 10:27:05 <freemangordon> this is why (2), to not lose focus :)
Jan 14 10:27:54 <freemangordon> Pali: so far I have gtk2 maemo auto-booting to h-d with hildon-status-menu in x86-64 VM :)
Jan 14 10:28:54 <freemangordon> ah, and it is gtk2+clutter1.x
Jan 14 10:29:18 <Pali> what is state of gtk3 version of hildon?
Jan 14 10:29:27 <Oksanaa> How much would I need to disassemble to have a visual inspection of the led engine on the motherboard? In case, say, a tiny piece of foil made its way inside the device to short-circuit it, or whatever?
Jan 14 10:29:57 <freemangordon> Pali: well, seems android808 has suspened the work on libhildon, so no much progress in the last 2 weeks
Jan 14 10:29:59 <Oksanaa> And how is hildon-home?.. 
Jan 14 10:30:22 <freemangordon> Oksanaa: didn't try it so far, but it shoudl work OOB
Jan 14 10:31:37 <Oksanaa> What else could I reinstall, besides mce, in case the leds not working is a software problem?
Jan 14 10:32:25 <freemangordon> Pali: but I am really getting reluctant about that gtk3 affair - I don;t really see what are the pros
Jan 14 10:32:35 <Maxdamantus> (for context: his lp5523 LEDs don't appear in /sys/class/leds)
Jan 14 10:32:41 <freemangordon> at least in short term
Jan 14 10:32:49 <Pali> posibility to appear hildon in linux distributions
Jan 14 10:32:53 <Pali> e.g. in upstart debian
Jan 14 10:33:00 <freemangordon> how is xfce4 there then?
Jan 14 10:33:04 <freemangordon> it is gtk2
Jan 14 10:33:19 <Pali> but hildon depends on maemo's gtk2
Jan 14 10:33:25 <freemangordon> oh, no,no :)
Jan 14 10:33:31 <Pali> not upstream gtk2
Jan 14 10:33:35 <freemangordon> I am using "stock" gtk2
Jan 14 10:33:41 <freemangordon> not maemo one
Jan 14 10:33:42 <freemangordon> ;)
Jan 14 10:33:43 <Pali> ok
Jan 14 10:34:02 <Oksanaa> The only thing appearing in /sys/class/leds is twl4030:vibrator
Jan 14 10:34:25 <freemangordon> Pali: see https://github.com/fremantle-gtk2/hildon/blob/master/hildon/hildon-gtk-module.c
Jan 14 10:34:36 <Pali> in debian is gtk2 at version 2.24.31
Jan 14 10:35:03 <Pali> if there are "no new gtk2 apps" policy, then we could probably ask for inclusion
Jan 14 10:35:41 <Oksanaa> Because it's not really new, it's old, but recently ported
Jan 14 10:35:48 <freemangordon> Pali: 2.24.25-3+deb8u1  here
Jan 14 10:36:00 <freemangordon> but this is devuan jessie
Jan 14 10:36:07 <Pali> that is in sid ^^^
Jan 14 10:36:19 <Pali> jessie is frozen for a long time
Jan 14 10:36:41 <freemangordon> "Devuan GNU/Linux 1", whatever it is :D
Jan 14 10:36:59 <freemangordon> but shouldn't make any difference
Jan 14 10:37:23 <Pali> so... if you think that your new hildon and apps are working fine on stock gtk2, I can try to prepare Debian packaging and ask for inclusion into Debian (sid)
Jan 14 10:37:53 <Pali> stretch is already frozen for new packages, so it would appear in stretch+1 release...
Jan 14 10:37:57 <freemangordon> I am using gtk module to "inject" whatever maemo-specific functionality is needed, not complete so far, but I think this is the right way to go
Jan 14 10:38:21 <freemangordon> also, maybe not all stuff can be implemented, but...
Jan 14 10:38:56 <freemangordon> still not working fine, I was playing with startup scripts recently
Jan 14 10:39:14 <freemangordon> Pali: and what about mce, dsme and the other maemo-specific stuff?
Jan 14 10:39:45 <Pali> good question...
Jan 14 10:40:08 <Pali> for whole Hildon desktop on Maemo/N900 it is needed
Jan 14 10:40:13 <freemangordon> what are we aiming for? rebased fremantle, as distro, or hildon-desktop in debian?
Jan 14 10:40:21 <freemangordon> and this is distro
Jan 14 10:40:34 <freemangordon> afaik
Jan 14 10:40:57 <Pali> I think rebased fremantle on top of new debian/devuan
Jan 14 10:40:58 <freemangordon> I think the goal should be mobile distribution
Jan 14 10:41:04 <Pali> it is right now, yes?
Jan 14 10:41:15 <freemangordon> which one?
Jan 14 10:41:31 <Pali> and once it is ok, we can clean code/packages and try to talk with upstart debian
Jan 14 10:42:16 <freemangordon> ok, but will it still be debian? I simply have no idea how stuff works re distribution wise
Jan 14 10:42:24 <Pali> I think it should work with both debian and devuan, but we can develop on devuan as it is systemd free and upstart there could be easier without systemd dependences
Jan 14 10:42:33 <freemangordon> sure
Jan 14 10:42:39 <freemangordon> that is why I use devuan
Jan 14 10:42:44 <Pali> yes
Jan 14 10:43:05 <Pali> but if we want same new package it should go via upstart debian --> and then appear in devuan
Jan 14 10:43:17 <freemangordon> the point is - so far I have something booting - is it a new distro?
Jan 14 10:43:34 <Pali> probably yes
Jan 14 10:43:46 <freemangordon> ok, why not put it on maemo servers then?
Jan 14 10:44:01 <freemangordon> with mirror of the needed debian packages
Jan 14 10:45:44 <freemangordon> as I don't think we'll be able to make hildon-desktop compatible with gnome or xfce etc
Jan 14 10:47:02 <freemangordon> or at least I don;t know how to do it :D
Jan 14 10:48:30 <Wizzup> What do you mean compatible?
Jan 14 10:49:27 <freemangordon> h-d is single user
Jan 14 10:49:30 <Pali> ok, I do not see problem with it
Jan 14 10:55:56 <freemangordon> Pali: problem with what?
Jan 14 10:56:16 <Pali> putting new dist on maemo servers...
Jan 14 11:13:24 <freemangordon> Wizzup: anny progress with autobuilder?
Jan 14 11:13:28 <freemangordon> *any
Jan 14 11:15:59 <Oksanaa> /me cheers
Jan 14 11:17:09 <Wizzup> freemangordon: not since two days ago, however, I think I'll have some initial things working this weekend.
Jan 14 11:20:41 <freemangordon> Pali: dsme in fremantle upstart job depends on rcS. Any idea what should it depend on upstream?
Jan 14 11:20:48 <Wizzup> freemangordon: as I understood, I need a git.devuan.org account, upload code there (not sure if that means full source of what is on gh) and then have the pkg built by the CI
Jan 14 11:20:53 <freemangordon> filesystem?
Jan 14 11:20:59 <Wizzup> then I can make a branch and trigger builds for it
Jan 14 11:21:12 <Wizzup> the next step will then be getting a (.deb) repo on their site with the packages
Jan 14 11:21:17 <Pali> needs to understand what rcS is doing
Jan 14 11:21:25 <Pali> and then depends on services started by rcS
Jan 14 11:21:39 <freemangordon> some maemo specific stuff (loading .ko files
Jan 14 11:21:45 <freemangordon> etc
Jan 14 11:21:54 <Pali> maybe it needs to depends on dbus?
Jan 14 11:22:50 <freemangordon> I think no, as there is dsme-dbus job, which waits for dbus
Jan 14 11:22:58 <freemangordon> rcS depends on startup
Jan 14 11:23:38 <freemangordon> depending on dbus is safe bet though, but I don;t think it should wait that much
Jan 14 11:24:35 <freemangordon> I'll make it depend on filesystem
Jan 14 11:30:50 <enyc> freemangordon: is there any useful process startup type log (or debugging) that can be put in place  to see whats slowing down boot getting to the point of mounting extra filesystems (MyDocs/mmc1)? [already sorted fs//fsck part of issue]
Jan 14 11:35:44 <freemangordon> enyc: /var/log/syslog
Jan 14 11:36:52 <NeKit> got cogl-x11-tfp demo and clutter toys rendering on Android device through libhybris and some hacks to connect to SurfaceFlinger
Jan 14 11:37:01 <NeKit> what repos should I try for building hildon-desktop?
Jan 14 11:41:36 <freemangordon> NeKit: do you have gtk there?
Jan 14 11:42:14 <NeKit> yes, full Linux chroot
Jan 14 11:42:28 <freemangordon> which gtk? 2 or 3?
Jan 14 11:43:15 <freemangordon> anyway, gtk2 port is more functional, try the stuff on https://github.com/fremantle-gtk2
Jan 14 11:43:23 <NeKit> currently 2 due to LXDE installed
Jan 14 11:43:30 <freemangordon> good, ^^^ then
Jan 14 11:44:06 <freemangordon> most of the needed build dependencies are in place on that repo
Jan 14 11:44:32 <freemangordon> ping me when there is something missing
Jan 14 11:44:48 <NeKit> thanks
Jan 14 11:46:32 <freemangordon> Pali: do you have any idea why hildon-desktop is started from both /etc/X11/Xsessio.pos atn as an upstart service?
Jan 14 11:46:57 <freemangordon> */etc/X11/Xsession.post and
Jan 14 11:47:28 <Pali> yes
Jan 14 11:47:33 <freemangordon> cool
Jan 14 11:47:35 <Pali> because it is started for user
Jan 14 11:47:41 <Pali> and not system-wide root service
Jan 14 11:47:56 <freemangordon> but why upstart service then?
Jan 14 11:48:23 <Pali> ah, it is also from upstart then
Jan 14 11:48:36 <Pali> so upstart scripts can depends on "started hildon-desktop"?
Jan 14 11:48:45 <freemangordon> ah, thanks
Jan 14 11:48:54 <freemangordon> yeah, makes sense
Jan 14 11:48:58 <Pali> anyway, it should be started only from X11
Jan 14 11:49:03 <Pali> and send event to upstart
Jan 14 11:49:20 <Pali> hildon-desktop should not be upstart service... but no idea how hard would be to fix this
Jan 14 11:50:09 <freemangordon> Pali: ah, there is also hildon-desktop in /etc/init.d :(
Jan 14 11:50:24 <freemangordon> WTF?
Jan 14 11:51:04 <Oksanaa> Is it possible that hildon-desktop checks to make sure there is only one instance of itself? 
Jan 14 11:51:15 <Wizzup> Or perhaps the init scripts are not called
Jan 14 11:51:30 <freemangordon> Wizzup: is that possible?
Jan 14 11:51:43 <freemangordon> so you think this is some remnant?
Jan 14 11:51:47 <Wizzup> At least with openrc, I have many scripts that are there, but are never started
Jan 14 11:52:13 <freemangordon> Pali: what do you think? ^^^
Jan 14 11:52:51 <Pali> think about what?
Jan 14 11:53:19 <freemangordon> could it be that on maemo the stuff in /etc/rcN.d is not called?
Jan 14 11:53:32 <freemangordon> so /etc/init.d scripts are ignored?
Jan 14 11:53:50 <Pali> yes, /etc/init.d/ is ignored on maemo's upstart
Jan 14 11:53:56 <Pali> so /etc/rcN.d is not called
Jan 14 11:54:08 <freemangordon> ok, that makes sense then
Jan 14 11:54:27 <freemangordon> so, h-d is only started from Xsession.post
Jan 14 11:54:41 <Pali> to start /etc/rcN.d in Ubuntu's upstart is /etc/init/rc.conf which do that
Jan 14 11:55:23 <freemangordon> Pali: but it seems we *do not* want hildon-desktop started from /etc/init.d
Jan 14 11:55:38 <freemangordon> so I guess I'll have to remove that script
Jan 14 11:55:47 <Pali> yes
Jan 14 11:55:50 <freemangordon> ok, thanks
Jan 14 11:58:00 <Oksanaa> What is /etc/init.d for, then?
Jan 14 11:58:48 <freemangordon> Oksanaa: remnant from sysvinit
Jan 14 12:11:51 <freemangordon> Pali: who is supposed to get bootstate?
Jan 14 12:11:53 <freemangordon> mce?
Jan 14 12:12:07 <Pali> dsme
Jan 14 12:12:23 <Pali> but from some file
Jan 14 12:12:27 <Pali> getbootstate
Jan 14 12:12:40 <Pali> is there for determinating boot state and it write it to some file
Jan 14 12:13:51 <Oksanaa> Is it safe to upgrade kernel-power on a device with broken charging port?
Jan 14 12:16:39 <Oksanaa> And, how to reload a kernel module (except for reboot) ?
Jan 14 12:16:56 <Wizzup> rmmod
Jan 14 12:17:00 <Wizzup> en then modprobe
Jan 14 12:17:32 <freemangordon> Pali: oh, it is in package getbootstate which contains /sbin/preinit as well :D
Jan 14 12:18:10 <freemangordon> that one will be tough, I guess it will wait as the last one on the queue
Jan 14 12:18:56 <Pali> anyway, all CSSU packages should now work without /proc/bootreaons
Jan 14 12:19:01 <Pali> and /proc/component_version
Jan 14 12:19:31 <freemangordon> Pali: sure, but dsme expects something in /tmp/STATE, otherwise it enters MALF and powers-down the machine in a minute
Jan 14 12:19:58 <Pali> then we should patch it
Jan 14 12:20:07 <Pali> so that some default state is used
Jan 14 12:21:12 <freemangordon> or rather check if state is empty in https://github.com/fremantle-gtk2/dsme/blob/master/debian/dsme.upstart#L10 and set it to USER if yes
Jan 14 12:21:51 <freemangordon> I am not sure we'll have to do that for CSSU though
Jan 14 12:22:35 <Oksanaa> Anyway, reinstall kernel*modules, and rmmod leds-lp5523; modprobe leds-lp5523; stop mce; start mce; didn't help with getting leds to work
Jan 14 12:22:59 <freemangordon> Oksanaa: is there anything in dmesg?
Jan 14 12:25:16 <Oksanaa> Freemangordon: kb_lock, slide, wlan0,  onenand_wait: correctable ECC error, wl1251: firmware booted (Rev 4.0.4.3.7)
Jan 14 12:26:17 <freemangordon> Oksanaa: I meant - after you modprobed leds ko
Jan 14 12:26:28 <Pali> onenand_wait: correctable ECC error --> looks like nand is going to die...
Jan 14 12:27:16 <freemangordon> mhm
Jan 14 12:28:01 <Oksanaa> Right after modprobe, yes. dmesg | grep -v kb_lock | grep -v slide | grep -v wlan0  gives relatively short output
Jan 14 12:30:21 <freemangordon> NeKit: just pushed some more things to gtk2 h-d please pull again
Jan 14 12:37:33 <Pali> freemangordon: or you can use getbootstate binary from getbootstate package
Jan 14 12:37:53 <Pali> in cssu is version compatible with upstream kernel
Jan 14 12:38:22 <freemangordon> Pali: I know, the point is that the package that contains getbootstate contains other stuff as well
Jan 14 12:38:24 <Pali> so you can run getboostate (maybe via upstart job?) before dsme
Jan 14 12:38:39 <freemangordon> like /sbin/preinit and whatnot
Jan 14 12:38:48 <freemangordon> so it should be repackaged for upstream maemo
Jan 14 12:38:52 <Pali> ok
Jan 14 12:39:04 <freemangordon> but this is low-priority job as of now
Jan 14 12:40:05 <Pali> ok
Jan 14 12:49:18 <Pali> freemangordon: can you take these two patches? https://github.com/community-ssu/libmatchbox2/pull/1 https://github.com/community-ssu/hildon-desktop/pull/2
Jan 14 12:52:35 <freemangordon> Pali: I guess yes, but won;t happen soon
Jan 14 12:52:41 <Pali> ok
Jan 14 13:25:54 <Vajb> adding smileys to pidgin theme works!
Jan 14 13:26:05 <Vajb> pidgin smiley theme*
Jan 14 14:56:25 <freemangordon> Pali: any clue who is supposed to start system dbus on debian?
Jan 14 14:57:13 <Pali> systemd :-)
Jan 14 14:57:26 <freemangordon> comeon :(
Jan 14 14:57:28 <Pali> basically init daemon is starting it when booting
Jan 14 14:57:38 <freemangordon> wello, no systemd here
Jan 14 14:57:51 <freemangordon> and I don;t see system dbus, only session
Jan 14 14:57:56 <Pali> so either sysvinit via /etc/init.d
Jan 14 14:58:05 <Wizzup> openrc has an init script for it. so I assume it's the same for upstart
Jan 14 14:58:08 <Wizzup> Doesn't need systemd
Jan 14 14:58:16 <Pali> or systemd service (when using systemd init daemon)
Jan 14 14:58:18 <freemangordon> there is /etc/init.d/dbus
Jan 14 14:58:27 <freemangordon> but it starts session bus
Jan 14 14:59:09 <Pali> init daemon is responsible to start system's dbus-daemon
Jan 14 15:00:45 <freemangordon> omg, in runlevel 2 dbus is not started
Jan 14 15:01:48 <freemangordon> Pali: shall I start it by "hand" from an upstart script?
Jan 14 15:02:00 <Pali> https://en.wikipedia.org/wiki/Runlevel#Linux_Standard_Base_specification
Jan 14 15:02:11 <Pali> 2	Multi-user mode	Does not configure network interfaces and does not export networks services.[c]
Jan 14 15:02:33 <Pali> so it is correct to not start dbus-daemon as it operates on network
Jan 14 15:02:59 <Pali> 3	Multi-user mode with networking	Starts the system normally.[1]
Jan 14 15:03:18 <freemangordon> hmm
Jan 14 15:03:22 <Pali> why is not used runlevel 3?
Jan 14 15:03:26 <freemangordon> but maemo runs on 2
Jan 14 15:03:34 <freemangordon> I changed it to 2
Jan 14 15:03:42 <freemangordon> but can;t remember what was before that
Jan 14 15:03:49 <freemangordon> :D
Jan 14 15:04:40 <Pali> anyway, my ubuntu is also running in runlevel 2
Jan 14 15:04:44 <freemangordon> on ubuntu there is no inittab
Jan 14 15:05:06 <Pali> probably something was changed...
Jan 14 15:05:07 <freemangordon> same here - 2
Jan 14 15:05:34 <freemangordon> anyway, I am going to write upstart script that starts dbus no matter the runlevel
Jan 14 15:06:08 <Pali> and my debian is running in runlevel 5
Jan 14 15:06:30 <freemangordon> Pali: is there inittab in etc?
Jan 14 15:06:54 <Pali> no, IIRC inittab is not used for a long time...
Jan 14 15:07:04 <Pali> but this debian is systemd based
Jan 14 15:07:35 <freemangordon> Pali: and how is default runlevel setup then?
Jan 14 15:07:53 <Pali> somehow by systemd
Jan 14 15:07:54 <Pali> no idea
Jan 14 15:08:45 <Pali> in my debian runlevel(8) manpage is writtten: runlevel 5 is systemd target graphical.target
Jan 14 15:09:03 <freemangordon> cool
Jan 14 15:10:19 <Pali> upstart cookbook: http://upstart.ubuntu.com/cookbook/#runlevels
Jan 14 15:10:24 <Pali> 2 : Graphical multi-user plus networking (DEFAULT)
Jan 14 15:10:42 <Pali> it is big mess!
Jan 14 15:10:51 <freemangordon> seems so
Jan 14 15:11:41 <Pali> so if you have LSB init.d script it probably needs to be "modified" for specific linux distribution
Jan 14 15:11:58 <Pali> as systemd has different numbers for runlevels as upstart and as LSB init.d
Jan 14 15:12:18 <Pali> or your init.d script should assume that 2 == 3 == 3 == 5
Jan 14 15:12:45 <Pali> also == 4
Jan 14 16:13:23 <ceene> Pali: when i first used redhat/mandrake circa 2000, it used 2 by default, and changed to 5 whenever i installed xfree86
Jan 14 16:13:45 <ceene> my understanding now is that runlevel became totally obsolete in modern distros
Jan 14 16:13:56 <KotCzarny> on slackware 3 was default no-x and 4 with x
Jan 14 16:14:22 <ceene> yeah... distro maintainers just forgot about it
Jan 14 16:16:03 <ceene> it would make sense to have named customizable runlevels, however only a set of numbered runlevels with restricted functionality doesn't provide enough flexibility, so it just ceased to exist in practice
Jan 14 16:16:57 <KotCzarny> only 3 runlevels are used nowadays, system start, started, shutting down/poweroff
Jan 14 16:18:36 <KotCzarny> runlevels are a remnant from server roots of linux
Jan 14 16:19:09 <KotCzarny> well, unix, but linux was based on their idea
Jan 14 16:22:59 <sicelo-> ceene: in connection with yappari, would it have been possible to just use Signal only (not to integrate with WA)
Jan 14 16:23:56 <ceene> if there is a signal library available, it could be done i guess
Jan 14 16:24:19 <sicelo-> okay 
Jan 14 19:53:35 <NeKit> how should be the hildon-desktop from fremantle-gtk2 started?
Jan 14 20:16:07 <Maxdamantus> ln -s `which hildon-desktop` ~/.xinitrc
Jan 14 20:16:35 <Maxdamantus> (just my opinion, feel free to ignore it)
Jan 14 21:03:49 <jonwil> hi
Jan 14 21:04:43 <freemangordon> NeKit: did you build it with maemo-launcher support?
Jan 14 21:05:49 <NeKit> Currently without. Is it needed?
Jan 14 21:06:00 <freemangordon> NeKit: currently no :)
Jan 14 21:06:25 <freemangordon> NeKit: you should start it as DISPLAY=:0 hildon-desktop 
Jan 14 21:06:38 <freemangordon> nothing special
Jan 14 21:06:45 <freemangordon> assuming you have X running
Jan 14 21:08:04 <freemangordon> NeKit: though, I have no idea how you should start it on wayland or whatever you're using under android
Jan 14 21:08:26 <NeKit> means I'm missing something, since it gives few GLib-CRITICAL and freezes (
Jan 14 21:08:48 <freemangordon> what are those criticals?
Jan 14 21:08:55 <NeKit> http://pastebin.com/vHUvLiNg
Jan 14 21:09:34 <NeKit> no Wayland, just Xorg
Jan 14 21:09:47 <freemangordon> are you sure you build it for gtk2?
Jan 14 21:10:27 <freemangordon> hmm, the problem might be in clutter 1.0, it has gtk3 backend enabled by default
Jan 14 21:10:48 <freemangordon> maybe you should rebuild clutter without gdk3 backend
Jan 14 21:11:42 <freemangordon> NeKit: do ldd on hildon-desktop and make sure there is no libgtk3 involved
Jan 14 21:14:22 <freemangordon> NeKit: ?
Jan 14 21:14:35 <NeKit> libgdk-3 is involved
Jan 14 21:14:44 <NeKit> I will try rebuilding clutter then
Jan 14 21:15:00 <freemangordon> NeKit: is that chroot some distro-based?
Jan 14 21:15:13 <NeKit> yes, Arch Linux ARM
Jan 14 21:16:24 <freemangordon> NeKit: is libgdk3 directly loaded by hildon-desktop or libhildon, or only by libclutter?
Jan 14 21:17:48 <freemangordon> hmm, weird, I have libgdk3 here as well, but it starts ok
Jan 14 21:17:55 <NeKit> if I check with ldd, I see at least hildon-desktop and libclutter-1.0.so linked to it
Jan 14 21:18:54 <freemangordon> same here
Jan 14 21:19:21 <freemangordon> but, my clutter-dev package is from the modified clutter I rebuild because of the same problem
Jan 14 21:21:14 <freemangordon> NeKit: maybe first rty with CLUTTER_BACKEND=x11 DISPLAY=:0 hildon-desktop
Jan 14 21:22:03 <freemangordon> if that doesn't help, I am afraid you'll have to rebuild clutter
Jan 14 21:26:02 <NeKit> it did the trick
Jan 14 21:26:51 <freemangordon> really?
Jan 14 21:26:53 <freemangordon> cool
Jan 14 21:27:27 <freemangordon> NeKit: I want a video :)
Jan 14 21:28:30 <freemangordon> NeKit: don't forget to install theme and to copy the backgrounds
Jan 14 21:30:32 <freemangordon> NeKit: also, you have to symlink /usr/hildon/theme to /usr/shares/theme/default and symlink /usr/shares/theme/default to /usr/shares/theme/alpha (if you install alpha theme). dunno how you're supposed to install debian package on arch linux, but I guess you know
Jan 14 21:38:56 <NeKit> looks way better with theme and wallpaper :)
Jan 14 21:39:28 <freemangordon> yes, I know :)
Jan 14 21:41:11 <freemangordon> NeKit: but, I am afraid that was the easy part. Bringing hildon-status-menu etc needs more stuff, like sapwood and whatnot
Jan 14 21:41:23 <freemangordon> and maybe working upstart
Jan 14 21:43:44 <freemangordon> oh, and working dbus
Jan 14 21:46:49 <NeKit> dbus is probably the least of worries, compared to upstart or sapwood(?)
Jan 14 21:50:08 <freemangordon> NeKit: sapwood is easy, I have it build for upstream, but it is still not on github
Jan 14 21:51:16 <freemangordon> NeKit: I can give you debian source package
Jan 14 21:51:20 <freemangordon> if you want
Jan 14 21:53:02 <freemangordon> Pali: where was gitorious maemo backup?
Jan 14 21:53:43 <Pali> which?
Jan 14 21:53:51 <Pali> gitorious is now in read-only mode
Jan 14 21:53:57 <Pali> with all git repos
Jan 14 21:54:00 <freemangordon> oh, ok
Jan 14 21:56:18 <freemangordon> hmm, FF hung on it
Jan 14 22:03:31 <freemangordon> Pali: there is nothing on gitorious valhala :(
Jan 14 22:03:42 <freemangordon> projects are listed, but that's it
Jan 14 22:03:57 <freemangordon> "404 - No projects found "
Jan 14 22:04:11 <Pali> git clone worked fine
Jan 14 22:04:15 <Pali> on original uri
Jan 14 22:04:21 <Pali> at least about month ago
Jan 14 22:04:36 <Pali> which project are you trying to find?
Jan 14 22:05:03 <freemangordon> but I don't know the original url, otherwise I want sapwood
Jan 14 22:05:27 <freemangordon> https://gitorious.org/maemo-af/sapwood.git/
Jan 14 22:06:04 <freemangordon> "fatal: repository 'https://gitorious.org/maemo-af/sapwood.git/' not found"
Jan 14 22:06:47 <Pali> looks like gitorious is not working now :-(
Jan 14 22:07:10 <Pali> maemo.org infra has backup of all maemo repos
Jan 14 22:07:11 <freemangordon> Pali: didn't we have a backup of that? I am sure we had
Jan 14 22:07:25 <Pali> so ask merlin1991
Jan 14 22:07:27 <freemangordon> any clue on which server?
Jan 14 22:07:34 <freemangordon> I have acces to the servers
Jan 14 22:07:37 <Pali> on some backup
Jan 14 22:48:47 <NeKit> https://sendvid.com/lm3ngj9p - no input yet and size is wrong, but at least it starts :)
Jan 14 23:13:49 <freemangordon> NeKit: "Терминал"? where are you from?
Jan 14 23:15:20 <freemangordon> NeKit: that page makes my adblocker go crazy :)
Jan 14 23:24:58 <xes> freemangordon: gitorious backups are saved into stage
Jan 14 23:25:28 <freemangordon> xes: yep, already found them :)
Jan 14 23:25:40 <xes> ok
Jan 15 02:40:10 <Oksanaa> Would upgrading kernel-power be dangerous for N900 with broken charging port?
Jan 15 02:42:57 <Oksanaa> Current kernel seems to be 2.6.28-10power52 , thumb
Jan 15 02:45:03 <Maxdamantus> You should probably install u-boot.
Jan 15 02:45:30 <Maxdamantus> rather than just another kernel.
Jan 15 02:45:55 <Maxdamantus> that way if your userland is messed up you can boot something off an SD card to fix it.
Jan 15 02:48:33 <Oksanaa> Not installing, upgrading. Kernel-power is already here, just haven't upgraded it for a long time.
Jan 15 02:49:03 <Oksanaa> U-boot... No idea. We might have one SD card somewhere. 
Jan 15 02:49:25 <Oksanaa> Is multiboot the one which increases chances of device being bricked?
Jan 15 02:49:58 <Maxdamantus> The point of u-boot if you don't have USB anymore is that if your system no longer boots you can probably still recover by booting something like RescueOS then getting the rest of the system back to a state that works.
Jan 15 02:50:17 <Oksanaa> Because one device with broken  charging port became "Guru" brick on kernel upgrade due to something-boot conflicting with kernel upgrade.
Jan 15 02:50:31 <Oksanaa> If u-boot is safe, will install it.
Jan 15 02:50:43 <Maxdamantus> since if your system just stops booting due to a misconfigured file in /etc or something, you might not be able to recover again without getting access to the USB pins.
Jan 15 02:51:07 <Oksanaa> Or rootfs being full ^
Jan 15 02:51:36 <Maxdamantus> Yes, I can imagine that being an issue too.
Jan 15 02:53:36 <Oksanaa> Which package? *Grimace* too many things displayed by apt-cache search u-boot
Jan 15 02:54:22 <Maxdamantus> Dunno. I've always just used flasher from a computer (which obviously uses USB)
Jan 15 02:54:32 <Maxdamantus> and use my own compilation of u-boot.
Jan 15 02:55:00 <Oksanaa> Bootloader, right? Not just companion tools
Jan 15 02:56:50 <Maxdamantus> It would be the bootloader, yes. The companion tools are probably things like `mkimage`
Jan 15 02:57:39 <Maxdamantus> Usually with u-boot on N900, there'll be a kernel written after u-boot itself.
Jan 15 02:58:01 <Oksanaa> What would be the minimum installation of bootloader, the least risky one? Which gives option to boot from SD card if one is installed?
Jan 15 02:59:43 <Maxdamantus> I think all the N900 builds that are likely to be distributed will have an entry in pali's bootmenu system to load something from the SD card.
**** ENDING LOGGING AT Sun Jan 15 03:00:00 2017