| 00:33.09 | *** join/#maemo-ssu Pali_ (~pali@Maemo/community/contributor/Pali) |
| 00:34.07 | *** join/#maemo-ssu NishanthMenon (~nmenon@192.91.75.29) |
| 00:34.07 | *** join/#maemo-ssu NishanthMenon (~nmenon@unaffiliated/nishanthmenon) |
| 02:05.50 | *** join/#maemo-ssu jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 02:42.20 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-50-151.residential.rdsnet.ro) |
| 05:30.59 | *** join/#maemo-ssu liteIRC__ (~ravelo@178.165.131.55.wireless.dyn.drei.com) |
| 05:44.21 | *** join/#maemo-ssu liteIRC__ (~ravelo@chello084115130025.2.graz.surfer.at) |
| 05:47.41 | *** join/#maemo-ssu liteIRC__ (~ravelo@178.115.128.107.wireless.dyn.drei.com) |
| 06:35.02 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 07:00.49 | *** join/#maemo-ssu amiconn (~amiconn@rockbox/developer/amiconn) |
| 10:23.12 | *** join/#maemo-ssu RedW (~redw@89-76-164-87.dynamic.chello.pl) |
| 10:37.51 | *** join/#maemo-ssu hashcore (~hashcore@unaffiliated/hashcore) |
| 11:11.35 | *** join/#maemo-ssu pagurus (~user@pD950CA59.dip0.t-ipconnect.de) |
| 12:39.58 | *** join/#maemo-ssu DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 12:59.10 | DocScrutinizer05 | IroN900:~# od -A x -x /usr/lib/mce/modules/libfilter-brightness-als.so|grep 0086a0; md5sum /usr/lib/mce/modules/libfilter-brightness-als.so |
| 12:59.12 | DocScrutinizer05 | 0086a0 0005 0000 0005 0000 0000 0000 0000 0000 |
| 12:59.13 | DocScrutinizer05 | 9db7e3c959bd5b47c7fcfb6ebc1ca764 /usr/lib/mce/modules/libfilter-brightness-als.so |
| 12:59.23 | DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-11-23.log.html#t2013-11-23T06:20:48 |
| 12:59.41 | DocScrutinizer05 | https://talk.maemo.org/showthread.php?p=1388368#post1388368 |
| 13:01.05 | DocScrutinizer05 | IroN900:~# apt-cache policy mce |
| 13:01.06 | DocScrutinizer05 | mce: |
| 13:01.08 | DocScrutinizer05 | <PROTECTED> |
| 13:03.03 | DocScrutinizer05 | IroN900:~# apt-cache policy mp-fremantle-community-pr |
| 13:03.05 | DocScrutinizer05 | mp-fremantle-community-pr: |
| 13:03.06 | DocScrutinizer05 | <PROTECTED> |
| 13:40.28 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-33-187.residential.rdsnet.ro) |
| 14:09.01 | DocScrutinizer05 | IroN900:~# od -A x -tx1 /usr/lib/mce/modules/libfilter-brightness-als.so|grep '0086a0 05 00 00 00 05 00 00 00 00 00 00 00' && sed -i -E 's/\x05\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00/\x05\x00\x00\x00\x05\x00\x00\x00\x05\x00\x00\x00/' /usr/lib/mce/modules/libfilter-brightness-als.so&&od -A x -tx1 /usr/lib/mce/modules/libfilter-brightness-als.so|grep '0086a0' |
| 14:09.03 | DocScrutinizer05 | 0086a0 05 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 |
| 14:09.04 | DocScrutinizer05 | 0086a0 05 00 00 00 05 00 00 00 05 00 00 00 00 00 00 00 |
| 14:14.50 | DocScrutinizer05 | https://talk.maemo.org/showthread.php?p=1388368#post1388368 updated |
| 14:21.32 | jonwil | http://talk.maemo.org/showthread.php?p=1498178#post1498178 |
| 14:39.41 | *** join/#maemo-ssu sparetire (~sparetire@unaffiliated/sparetire) |
| 15:12.57 | *** join/#maemo-ssu hashcore (~hashcore@unaffiliated/hashcore) |
| 15:17.50 | *** join/#maemo-ssu jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 15:31.10 | *** join/#maemo-ssu NishanthMenon (~nmenon@unaffiliated/nishanthmenon) |
| 15:35.08 | *** join/#maemo-ssu hashcor (~hashcore@unaffiliated/hashcore) |
| 15:41.16 | *** join/#maemo-ssu hashcor (~hashcore@unaffiliated/hashcore) |
| 16:10.39 | *** join/#maemo-ssu Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 16:53.22 | DocScrutinizer05 | dbus on maemo is flawed, massively. We need an update which will fix many of the randomly happening erratic behavior of the whole system. See https://lists.freedesktop.org/archives/dbus/2008-March/009526.html >> At which point the badness happens: The daemon (apparently) immediately closes the connection, oblivious to the fact that there is critical data in it's socket buffer as-yet un-read.<< |
| 16:54.50 | DocScrutinizer05 | I only suspect this is the root cause, the symptom is >>needs --print-reply to make `dbus-send --system --print-reply --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_vibrator_pattern_activate string:PatternChatAndEmail` work. Remove --print-reply and it simply fails<< |
| 16:55.44 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 16:56.03 | DocScrutinizer05 | https://bugs.freedesktop.org/show_bug.cgi?id=896#c26 https://bugzilla.redhat.com/show_bug.cgi?id=477964#c11 |
| 16:56.06 | povbot | Bug 896: missing instructions in point 4 of installing scratchbox in gregale/INSTALL.txt |
| 16:56.07 | povbot | Bug 477964: was not found. |
| 16:57.23 | DocScrutinizer05 | https://cgit.freedesktop.org/dbus/dbus/commit/?id=87ddff6b24d9b9d4bba225c33890db25022d8cbe |
| 17:02.17 | DocScrutinizer05 | note that this bug will affect *all* clients that send a dbus message and then immediately terminate |
| 17:02.35 | DocScrutinizer05 | the message simply gets lost |
| 17:04.28 | *** join/#maemo-ssu futpib (~futpib@176.212.174.28) |
| 17:15.47 | *** join/#maemo-ssu merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
| 17:27.46 | DocScrutinizer05 | I don't know if the more generic async problem in dbus we faced back when we did FSO-vala is related - >>fsogsmd: Waiting for async. dbus server support in Vala.<< issue in http://wiki.openmoko.org/wiki/OpenmokoFramework/Status_Update_7#DBus_APIs |
| 17:29.00 | DocScrutinizer05 | I just recall this was a bug in dbus that really affected all async dbus-send() calls |
| 18:00.06 | *** join/#maemo-ssu RedW (~redw@89-76-164-87.dynamic.chello.pl) |
| 19:13.58 | *** join/#maemo-ssu Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 19:20.52 | *** join/#maemo-ssu eugene_ (~eugene@2.92.182.83) |
| 19:22.51 | Pali | gitorious is back! only git repositories in R/O mode, but at least something for Maemo to not loose git repos... |
| 19:22.52 | Pali | https://gitorious.org/community-ssu/hildon-application-manager |
| 19:23.09 | bencoh | woohoo |
| 19:23.12 | bencoh | at last |
| 19:23.51 | Pali | https://gitorious.org/maemo-af/ke-recv |
| 19:24.01 | Pali | original URLs working |
| 19:24.11 | bencoh | I suggest we move everything that's still there :) |
| 19:24.35 | bencoh | (and not already hosted on some other platform) |
| 19:25.13 | Pali | maemo infra has backups... |
| 19:25.31 | bencoh | yeah, but they're not public |
| 19:25.43 | Pali | merlin restored some gitorious repos when I needed them |
| 19:25.57 | Pali | it is just for emergency |
| 19:29.55 | *** join/#maemo-ssu eugene_ (~eugene@2.92.182.83) |
| 20:07.58 | *** join/#maemo-ssu arcean (~arcean@nat1-3.finemedia.pl) |
| 20:10.19 | DocScrutinizer05 | Pali: would you want to have a look into dbus and see if we have https://cgit.freedesktop.org/dbus/dbus/commit/?id=87ddff6b24d9b9d4bba225c33890db25022d8cbe ? |
| 20:11.29 | DocScrutinizer05 | Pali: it's a pretty bad bug that has impact on complete system |
| 20:12.27 | Pali | DocScrutinizer05: do we need to backport that commit to maemo? |
| 20:12.47 | Pali | it is from 2009, is not already included? |
| 20:13.05 | DocScrutinizer05 | obviously not, see --print-reply |
| 20:13.56 | DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/latest.log.html#t2016-02-08T18:53:21 |
| 20:15.19 | freemangordon | Pali: please backup felipe's repos on gitorious |
| 20:24.11 | *** join/#maemo-ssu eugene__ (~eugene@2.92.182.83) |
| 20:43.50 | Pali | I have it for a long time |
| 20:44.47 | Pali | DocScrutinizer05: patch apply fine on maemo dbus library! |
| 20:44.56 | Pali | so it is definitely not part of Maemo |
| 20:46.12 | DocScrutinizer05 | :-) ... and :-D |
| 20:46.36 | DocScrutinizer05 | we really *should* get this into all maemo systems ASAP |
| 20:47.47 | Pali | merlin1991: we need new urgent CSSU update |
| 20:47.54 | Pali | merlin199: see ^^^ |
| 20:56.03 | DocScrutinizer05 | dang, this feels good to have squished a bug |
| 20:57.06 | DocScrutinizer05 | particularly such a nasty one that potentially caused bazillion random erratic behaviors in system without leaving much of a trace |
| 20:57.42 | bencoh | "urgent"... it's been lying there for years ;) |
| 20:58.04 | bencoh | but we haven't even tested the fixed version yet :) |
| 20:59.25 | freemangordon | yep, I wouldn't say it is urgent if has been here for years without obvious effects. also, please someone to provide a test case, the same we did for pselect() bug |
| 21:00.05 | Sicelo009N | :) |
| 21:00.43 | DocScrutinizer05 | Pali: there's a point in the source where it gets a SIGPIPE on read and then (in unpatched) quits, or (in patch) ignores the SIGPIPE. I suggest to have a logger to syslog there shoing a message in syslog each time the situation occurs and would have caused trouble in the unpatched recently used version |
| 21:01.29 | DocScrutinizer05 | freemangordon: testcase >>needs --print-reply to make `dbus-send --system --print-reply --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_vibrator_pattern_activate string:PatternChatAndEmail` work. Remove --print-reply and it simply fails<< |
| 21:01.58 | DocScrutinizer05 | totally obvious and simple testcase |
| 21:03.09 | freemangordon | DocScrutinizer05: I am not convinced the bug is that critical, otherwise syslog would have been full of "SIGPIPE killed process" messages |
| 21:03.24 | freemangordon | not saying it should not be fixed |
| 21:03.33 | DocScrutinizer05 | no, the process isn't killed by SIGPIPE |
| 21:03.57 | DocScrutinizer05 | dbus-daemon simply aborts the read of message from sender |
| 21:04.29 | DocScrutinizer05 | See https://lists.freedesktop.org/archives/dbus/2008-March/009526.html >> At which point the badness happens: The daemon (apparently) immediately closes the connection, oblivious to the fact that there is critical data in it's socket buffer as-yet un-read.<< |
| 21:04.55 | freemangordon | so teh sequence is - open dbus connection, send message, close immediately, correct? |
| 21:05.46 | DocScrutinizer05 | the sender process already regularly quit anyway, and dbus-daemon drops the message and nothing will indicate something bad happened, except the fact that the message "goes to dev/null" |
| 21:05.52 | DocScrutinizer05 | yes |
| 21:06.38 | DocScrutinizer05 | 100% correct |
| 21:07.00 | freemangordon | do we have any other example, besides dbus-send? |
| 21:07.08 | DocScrutinizer05 | dunno |
| 21:07.15 | DocScrutinizer05 | how would we possibly know |
| 21:07.28 | freemangordon | also, is this for both sync and async messages? |
| 21:07.33 | DocScrutinizer05 | there's no indication at all except the missing message |
| 21:07.54 | DocScrutinizer05 | seems for both, though I haven't looked into it |
| 21:08.01 | freemangordon | I guess for async messages only |
| 21:08.13 | DocScrutinizer05 | possible, yes |
| 21:08.23 | freemangordon | because for sync message, you're blocked so cannot close the connection |
| 21:08.34 | DocScrutinizer05 | blocked until when? |
| 21:08.48 | freemangordon | until return from dbus function call, iirc |
| 21:09.10 | DocScrutinizer05 | yeah, but what does function call accomplish? |
| 21:09.30 | freemangordon | lemme check |
| 21:09.37 | DocScrutinizer05 | does it guarantee the buffer got read completely by daemon, before it returns? |
| 21:10.26 | DocScrutinizer05 | I even suspect there's more bugs to the async stuff than only this one |
| 21:10.40 | DocScrutinizer05 | not sure about that though |
| 21:10.56 | DocScrutinizer05 | still trying to find out |
| 21:11.05 | freemangordon | hmm, read a bit https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#gae1cb64f4cf550949b23fd3a756b2f7d0 |
| 21:11.24 | DocScrutinizer05 | http://logs.nslu2-linux.org/livelogs/openmoko-cdevel.txt |
| 21:12.25 | freemangordon | DocScrutinizer05: it seems this behaviour is by design, not a bug |
| 21:13.31 | freemangordon | so I really wonder what was "fixed" in this commit |
| 21:13.33 | DocScrutinizer05 | it definitely is a bug, see behavior of dbus-send |
| 21:14.48 | freemangordon | DocScrutinizer05: readt the ^^^ link, it clearly says you should call dbus_connection_flush() if you're going to close the connection and exit |
| 21:16.01 | DocScrutinizer05 | well, then it's a bug in dbus-send and a bazillion lib*dbus* |
| 21:16.03 | *** join/#maemo-ssu luf_ (~luf@ip-89-103-184-51.net.upcbroadband.cz) |
| 21:17.25 | DocScrutinizer05 | in my design book the dbus_connection_flush() belongs *inside* the dbus_connection_close() |
| 21:18.10 | DocScrutinizer05 | maybe there are arguments to not have it that way |
| 21:18.13 | freemangordon | DocScrutinizer05: maybe someone should look at dbus-send code, if that flush() is not called, then it is definitely a bug in dbus-send. |
| 21:19.07 | DocScrutinizer05 | well, we need to check a twenty dozen other executables and libs too |
| 21:19.44 | freemangordon | DocScrutinizer05: imagine a crash in an multithreaded client app, when only half of the data was written |
| 21:19.51 | DocScrutinizer05 | since I don't think other devels implemented stuff that wasn't even in dbus-send which is sort of the reference implementation |
| 21:21.08 | freemangordon | so, you'll have some random partial message |
| 21:22.28 | freemangordon | DocScrutinizer05: to make it clear - I don;t say we should not pick the patch, only that it is not that *urgent* :) |
| 21:22.30 | DocScrutinizer05 | a message is atomic aiui |
| 21:22.42 | freemangordon | isn;t that unix socket? |
| 21:22.48 | freemangordon | or even tcp socket? |
| 21:22.54 | DocScrutinizer05 | tcp prolly |
| 21:23.02 | freemangordon | no way it is atomic |
| 21:23.45 | freemangordon | routers can (and do) whatever segmentation fits them |
| 21:23.57 | freemangordon | keep in mind you can call remote dbus |
| 21:23.57 | DocScrutinizer05 | I don't like to dive into the mud of dbus code to find out what could possibly go wrong |
| 21:24.52 | DocScrutinizer05 | https://lists.freedesktop.org/archives/dbus/2008-March/009526.html sounds like a clear race condition to me |
| 21:26.19 | DocScrutinizer05 | dbus-daemon not servicing the postbox for outbound letters when it can't deliver an inbound letter |
| 21:28.16 | DocScrutinizer05 | dbus-send which is the reference implementation supposed to be written by the inventors of dbus is not working like supposed. It's pretty likely that all other apps that were written based on same knowledge show a similar behavior |
| 21:29.00 | DocScrutinizer05 | we either can fix all other apps or we fix dbus-daemon |
| 21:29.40 | freemangordon | oh oh, I didn;t mean to say there is no bug, but that this fix should not be treated as "urgent" but go through the normal cssu devel-testing-stable cycle |
| 21:30.05 | DocScrutinizer05 | I never said "urgent", did I? |
| 21:30.11 | DocScrutinizer05 | I said "ASAP" |
| 21:30.31 | DocScrutinizer05 | which of course implies regulr CSSU testing and all |
| 21:30.31 | freemangordon | this means "for yesterday" in my book :) |
| 21:31.04 | DocScrutinizer05 | it's not an emergency fix |
| 21:31.07 | DocScrutinizer05 | :-) |
| 21:31.39 | DocScrutinizer05 | and I wouldn't want to see inferior system stability getting introduced by this patch |
| 21:33.37 | DocScrutinizer05 | first we even could not change the normal behavior but simply add a syslog line whenever such premature abort of message transmission occurs, including the message content and the from: and to: |
| 21:34.03 | freemangordon | :nod: |
| 21:34.07 | DocScrutinizer05 | this would give us an idea how often actual problems are introduced by this bug |
| 21:34.28 | freemangordon | agree |
| 21:34.50 | bencoh | DocScrutinizer05: have you tried the vibrate req with patched dbus? |
| 21:35.01 | DocScrutinizer05 | when we also apply the new behavior in dbus-daemon then we still get that syslog and can look if in contect of the log time anything odd happened from the new behavior |
| 21:35.15 | DocScrutinizer05 | bencoh: I have no patched dbus |
| 21:35.19 | freemangordon | anyway, /mes is going to have some sleep, night |
| 21:35.29 | DocScrutinizer05 | n8 |
| 21:35.42 | luf_ | freemangordon: Do you want to take a look at libpng pull request (patches from wheezy)? |
| 21:36.01 | luf_ | freemangordon: enjoy the night ;) |
| 21:51.16 | Pali | DocScrutinizer08: now I checked again dbus source and patch is there |
| 21:51.22 | Pali | in debian/patches folder |
| 21:51.44 | Pali | patches are applied *after* starting dpkg-buildpackage |
| 21:51.49 | Pali | by debian/rules |
| 21:51.50 | bencoh | indeed |
| 21:52.00 | Pali | so no action is needed |
| 21:52.05 | Pali | we already have patch in maemo |
| 21:53.01 | Pali | I was confused, because I downloaded that upstream patch and it applied on unpacked tarball |
| 21:53.53 | Pali | https://gitorious.org/maemo-af/dbus |
| 21:53.59 | Pali | https://gitorious.org/maemo-af/dbus?p=maemo-af:dbus.git;a=commit;h=119515a9844cb3139514f4f0aaa179141febe2de |
| 21:54.24 | Pali | https://gitorious.org/maemo-af/dbus?p=maemo-af:dbus.git;a=commitdiff;h=119515a9844cb3139514f4f0aaa179141febe2de;hp=f3d6699a5d4615c527c4bac6290eb3591af49440 |
| 21:54.32 | DocScrutinizer05 | then we have another yet unidentified bug |
| 21:54.40 | DocScrutinizer05 | :-/ |
| 21:55.32 | Pali | freemangordon, merlin1991: no action needed, patch is already in maemo dbus version |
| 21:57.31 | DocScrutinizer05 | yet the bug exists |
| 21:58.11 | DocScrutinizer05 | we should compare dbus-send of 2008 with recent dbus-send then |
| 21:59.10 | DocScrutinizer05 | or do a strace and see why dbus-send fails when no --print-reply |
| 22:01.59 | DocScrutinizer05 | Pali: are you sure the gitorious.org sources are in sync with maemo's dbus-daemon? |
| 22:02.25 | Pali | DocScrutinizer05: 100% now I checked tarball form r.m.o |
| 22:02.30 | DocScrutinizer05 | IroN900:~# dbus-daemon --version |
| 22:02.32 | DocScrutinizer05 | D-Bus Message Bus Daemon 1.2.14 |
| 22:02.33 | DocScrutinizer05 | Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others |
| 22:05.25 | DocScrutinizer05 | quite irritating that this bug behavior 100% matches the one described in https://lists.freedesktop.org/archives/dbus/2008-March/009526.html |
| 22:09.09 | *** join/#maemo-ssu M4rtinK2 (~M4rtinK@ip-78-102-146-111.net.upcbroadband.cz) |
| 22:18.57 | DocScrutinizer05 | we probably also could compare dbus-daemon's strace on a dbus-send without --print-reply to the strace log listed in ^^^ |
| 22:19.30 | DocScrutinizer05 | maybe the bug is the right one but the fix is flawed ;-) |
| 22:22.36 | Pali | DocScrutinizer05: can you write which command have you exacly called which all params? |
| 22:24.04 | DocScrutinizer05 | dbus-send --system --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_vibrator_pattern_activate string:PatternChatAndEmail |
| 22:24.09 | DocScrutinizer05 | vs |
| 22:24.19 | DocScrutinizer05 | dbus-send --print-reply --system --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_vibrator_pattern_activate string:PatternChatAndEmail |
| 22:24.39 | Pali | this is method call I believe, yes? |
| 22:24.45 | DocScrutinizer05 | the latter works, the first one doesn't - silently |
| 22:24.51 | DocScrutinizer05 | yes# |
| 22:25.04 | Pali | can you try to add param --type=method_call ? |
| 22:25.11 | DocScrutinizer05 | sure |
| 22:27.42 | DocScrutinizer05 | works just like --print-reply |
| 22:27.57 | DocScrutinizer05 | only it logs some gibberish, but works |
| 22:29.25 | DocScrutinizer05 | well, actually both do |
| 22:30.32 | Pali | So read manpage again! There is written: --type=TYPE Specify "method_call" or "signal" (defaults to "signal"). |
| 22:30.53 | Pali | if you are doing method calls, you need to specify --type=method_call |
| 22:31.05 | DocScrutinizer05 | oh, ok. |
| 22:31.45 | Pali | probably --print-reply automatically changes types from signal to method as signal does not have any return value |
| 22:31.51 | DocScrutinizer05 | I just picked up on a user request |
| 22:32.14 | DocScrutinizer05 | indeed, signals are without feedback by definition |
| 22:32.26 | *** join/#maemo-ssu jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 22:33.08 | DocScrutinizer05 | http://wiki.maemo.org/Phone_control#Start_Vibrating_Incoming_Call :-S |
| 22:34.27 | DocScrutinizer05 | so we found a non-bug. LOL |
| 22:36.35 | Pali | so you just emitted signat to dbus and every application ignored it :-) |
| 22:37.21 | DocScrutinizer05 | yes |
| 22:38.51 | DocScrutinizer05 | what i learned today: do my own approach to implement what user reports as 'not working', also don't trust wiki blindly |
| 22:39.59 | DocScrutinizer05 | how about od -A x -tx1 /usr/lib/mce/modules/libfilter-brightness-als.so|grep '0086a0 05 00 00 00 05 00 00 00 00 00 00 00' && sed -i -E 's/\x05\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00/\x05\x00\x00\x00\x05\x00\x00\x00\x05\x00\x00\x00/' /usr/lib/mce/modules/libfilter-brightness-als.so&&od -A x -tx1 /usr/lib/mce/modules/libfilter-brightness-als.so|grep '0086a0' |
| 22:41.16 | DocScrutinizer05 | http://wiki.maemo.org/User:Joerg_rw/tools#nasty_hack_to_fix_indicator_light_in_bright_environment |
| 22:55.29 | Pali | mce is fixed in cssu |
| 23:00.05 | DocScrutinizer05 | then why is it still broken on my system? http://paste.opensuse.org/19234874 |
| 23:01.13 | DocScrutinizer05 | maybe system migration via BM to a new device messed up update status of some system components? |
| 23:02.15 | DocScrutinizer05 | or doesn't BM do backup of / fs at all? |
| 23:02.28 | DocScrutinizer05 | that would explain it |
| 23:08.56 | DocScrutinizer05 | but BM says it does a rootFS backup, so how comes my MCE got "downgraded"? |
| 23:16.33 | DocScrutinizer05 | strange |
| 23:18.45 | Pali | ask freemangordon |
| 23:18.54 | Pali | anyway, bye! |
| 23:26.06 | DocScrutinizer05 | probably should finally do a clean new install, after 5 years |
| 23:27.17 | DocScrutinizer05 | Pali: thanks for looking into it |
| 23:27.24 | DocScrutinizer05 | n8 |
| 23:27.36 | jonwil | Question: Is someone going to merge the pull request for libpng? |
| 23:50.18 | luf_ | jonwil: I'm waiting if freemangordon have some comment |
| 23:51.06 | luf_ | jonwil: otherwise I'll merge it. I'm using it in my main device, |
| 23:54.10 | jonwil | ok |