| 00:30.25 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 00:47.11 | *** join/#maemo-ssu arcean (~arcean@aaem131.neoplus.adsl.tpnet.pl) |
| 03:33.33 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 04:04.18 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 05:07.45 | *** join/#maemo-ssu Jade (~jade@modemcable021.180-203-24.mc.videotron.ca) |
| 05:07.46 | *** join/#maemo-ssu Jade (~jade@unaffiliated/jade) |
| 06:41.34 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 07:32.02 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 07:33.37 | *** join/#maemo-ssu deepy (~deepy@wrongplanet/deepa) |
| 08:36.36 | kerio | ooh, there's a new hildon-desktop in -devel? |
| 08:38.09 | kerio | merlin1991: when will you make a new cssu-testing release? |
| 08:48.26 | *** join/#maemo-ssu luf (luf@nat/ibm/x-ymwnbdolvfvbezqt) |
| 09:05.58 | *** join/#maemo-ssu kolp (~quassel@212.255.20.103) |
| 10:25.14 | *** join/#maemo-ssu M13 (~Miha@83.149.38.192) |
| 10:26.01 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 10:34.57 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-iaihobckwzhbxksq) |
| 10:45.36 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 10:45.57 | *** join/#maemo-ssu gregoa (~gregoa@chello212186052066.410.14.vie.surfer.at) |
| 10:46.13 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 10:50.15 | *** join/#maemo-ssu Mihanizat0r (~Miha@83.149.37.37) |
| 11:37.22 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 11:43.46 | *** join/#maemo-ssu iDont (~iDont@145.93.210.69) |
| 11:59.18 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 12:32.42 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 12:40.37 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 12:58.35 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 13:15.47 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 13:23.48 | *** join/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 13:40.22 | *** join/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 13:40.38 | freemangordon | _ade_: hi |
| 13:40.41 | _ade_ | hi |
| 13:40.59 | _ade_ | freemangordon: does it mean a change in the alarm cookies |
| 13:41.03 | freemangordon | so, the point is, can some parameters be passed from alarmd |
| 13:41.09 | freemangordon | yeah, something like that |
| 13:41.25 | freemangordon | though it is dbus call, with variable arguments AIUI |
| 13:41.36 | freemangordon | so no changes in alarmd should be needed |
| 13:42.11 | freemangordon | no idae if that can be done |
| 13:42.14 | freemangordon | *idea |
| 13:42.15 | _ade_ | just extra (new) arguments in the cookie? |
| 13:42.39 | freemangordon | maybe, NFC how you setup an alarm in worldclock :D:D:D |
| 13:42.45 | freemangordon | but I guess so |
| 13:43.57 | freemangordon | following KISS principle,I think snooze count and sound duration per alarm should be the only things to be aded |
| 13:44.14 | _ade_ | freemangordon: I also asked you about per alarm sounds. You can specify them, but the default sound is always played. Is that a bug, or missing in alarmd/alarm-ui? |
| 13:44.22 | freemangordon | we really don;t need dofferent sound per alarm, at least for now |
| 13:44.45 | freemangordon | hmm, strange, lemme look at the code |
| 13:46.03 | freemangordon | WTF?!? |
| 13:46.04 | freemangordon | https://gitorious.org/community-ssu/osso-systemui-alarm/blobs/master/osso-systemui-alarm.c#line659 |
| 13:46.34 | freemangordon | https://gitorious.org/community-ssu/osso-systemui-alarm/blobs/master/osso-systemui-alarm.c#line668 |
| 13:46.52 | freemangordon | who the fuck wrote that code :( |
| 13:47.00 | freemangordon | _ade_: yeah, seems like bug |
| 13:47.29 | _ade_ | that would be the static alarm for the calender, the clock uses the one in gconf |
| 13:47.42 | freemangordon | BTW do we have UI to specify alarm sound? |
| 13:47.59 | freemangordon | both use gconf setting |
| 13:48.13 | freemangordon | see ^^^ |
| 13:48.53 | _ade_ | okay, but you can set a preferred alarmsound, and that will be used |
| 13:49.47 | freemangordon | _ade_: yes, but this is not sound per alarm, rather sound per alarm type |
| 13:50.10 | _ade_ | Yes, it will always be the current one then. Alarmd gives the parameter to set a custom sound, but it has no effect |
| 13:50.47 | freemangordon | _ade_: yes, because alarmUI uses gconf setting, not the one in alarm event |
| 13:51.54 | _ade_ | ah ok. Something else to adapt for you ;-) |
| 13:52.02 | freemangordon | but lets leave sounds per alarm for now, it will be more complicated than snooze count/sound duration |
| 13:52.33 | _ade_ | of course. I will have a look at the things you like to see and report back. |
| 13:52.44 | freemangordon | _ade_: if I edit /var/cache/alarm.d/... by hand, will it work to test? |
| 13:53.24 | _ade_ | The alarmsoundfile? You can refer to a soundfile, but it has no effect |
| 13:53.46 | freemangordon | _ade_: not only that, but to add additional parameters |
| 13:54.15 | _ade_ | Never tried to manually edit that... |
| 13:54.38 | freemangordon | ok, i'll try |
| 13:54.58 | _ade_ | I always insert cookies |
| 13:55.26 | freemangordon | anyway, for now requirements are unclear, i'll ping you or post on the worldclock thread when have something for you |
| 13:55.44 | _ade_ | thanks in advance! |
| 14:01.29 | DocScrutinizer05 | WTF indeed, what a braindamaged concept is that behind alarms and alarmsounds? |
| 14:03.48 | freemangordon | DocScrutinizer05: I can't believe what that code (in its stock form) looks like |
| 14:04.46 | DocScrutinizer05 | I looked, seen a hardcoded path in sourcecode inside instruction area (not even as a #define), threw up and closed it again |
| 14:06.12 | freemangordon | well, that could be a result or REing, I am refactoring it right now |
| 14:06.27 | DocScrutinizer05 | anyway keep in mind that alarmd cookies been broken in stock maemo iirc |
| 14:08.43 | DocScrutinizer05 | you got a struct defining what's meant to be passed as "cookie" to alarmd during definition of an alarm, and returned by alarmd when alarm fires? |
| 14:08.52 | DocScrutinizer05 | as of now |
| 14:09.16 | DocScrutinizer05 | I'd gladly share my thoughts and suggestions how to augment it |
| 14:09.35 | freemangordon | DocScrutinizer05: this is not meant for stock Maemo, and cookie bug is fixed as for the last 2 CSSU-T releases |
| 14:09.52 | DocScrutinizer05 | yes, I'm aware of all that |
| 14:11.17 | _ade_ | freemangordon: what hardcoded paths are there, except gconf paths and default alarm (sound) files? |
| 14:13.49 | DocScrutinizer05 | guys, either we stay compatible with brainfsckd 'old' original alarmclock/alarmd/systemui-alarm "API", or we define a new better one, preferably as future-proof and backwards compatible as possible |
| 14:14.21 | DocScrutinizer05 | that's why I asked for a pointer to the struct of the 'cookie' |
| 14:14.41 | freemangordon | _ade_: /tmp/ACT_DEAD :D:D:D |
| 14:14.58 | freemangordon | DocScrutinizer05: naah, no change in API |
| 14:15.24 | DocScrutinizer05 | aiui you already changed the API |
| 14:15.30 | freemangordon | API will remain the same, it allows waviable arguments to be passed along with alarm |
| 14:15.36 | freemangordon | DocScrutinizer05: no |
| 14:15.52 | freemangordon | which API? |
| 14:16.12 | DocScrutinizer05 | freemangordon: your idea of my idea of what API includes/means is not correct |
| 14:16.25 | freemangordon | aah, ok |
| 14:16.36 | freemangordon | you mean between worldclock/alarmUI? |
| 14:16.39 | DocScrutinizer05 | 'variable arguments' never is exactly true |
| 14:17.04 | freemangordon | that could be kept bacward-=compatible, no worries |
| 14:17.12 | freemangordon | *backward |
| 14:17.24 | DocScrutinizer05 | since you always have a few interfaces which have to agree upon *some* structure in those 'variable arguments' |
| 14:17.52 | freemangordon | this is not the case AIUI, as parameters are passed with dbus call |
| 14:18.08 | DocScrutinizer05 | so what? |
| 14:18.21 | freemangordon | and ayatemui iterates through them and calls alarmUI plugin with GArray of parameters |
| 14:18.26 | freemangordon | *systemui |
| 14:18.38 | DocScrutinizer05 | either you expect those arguments in same format somewhere sometime, or they are cruft |
| 14:18.44 | _ade_ | As long as the stock clock ignores additional arguments I see no issue |
| 14:18.47 | freemangordon | yes |
| 14:19.13 | freemangordon | actually it is not like that |
| 14:19.24 | freemangordon | alarmUI gets alarm event cookie |
| 14:19.35 | freemangordon | and calls libalarm for the other stuff |
| 14:19.40 | DocScrutinizer05 | guys, are you suggesting "I see no issue" so nobody else may look at it? |
| 14:20.10 | freemangordon | DocScrutinizer05: come on, libalarm and alarmUI source code is on gitorious, libalarm API is well defined |
| 14:20.41 | _ade_ | But the worldclock will read the cookies at startup, that's what I am talking about. |
| 14:20.49 | freemangordon | libalarm API allows you to pass alarm event attribute |
| 14:20.58 | freemangordon | *attributes |
| 14:21.02 | freemangordon | NAMED |
| 14:21.06 | DocScrutinizer05 | aha, so yes, you basically say exactly that. "we got it sorted, if you wanna know what we're talking about, go the fuck serching for stuff yourself" |
| 14:21.34 | freemangordon | DocScrutinizer05: what makes you think I know libalarm API so I can explain it to you? |
| 14:21.55 | freemangordon | what I know I've lerant it the last week while I was REing alarmUI |
| 14:22.00 | freemangordon | *learnt |
| 14:23.44 | DocScrutinizer05 | who mentioned libalarm? |
| 14:24.49 | freemangordon | me |
| 14:25.10 | freemangordon | as that is the way worldclock and alarmUI communicate |
| 14:26.22 | _ade_ | freemangordon: did you get the point from my last remark, or am I still missing the point? |
| 14:26.47 | freemangordon | _ade_: yes |
| 14:27.04 | _ade_ | the first or last part ;-) |
| 14:27.10 | freemangordon | if it is for that one "_ade_> As long as the stock clock ignores additional arguments I see no issue" |
| 14:27.40 | DocScrutinizer05 | seems you're more happy with me looking at your final work and then start bashing the flaws I might find, rather than my offer to contribute early in the process. Oh well |
| 14:28.27 | freemangordon | DocScrutinizer05: come on, there is still no "process" I am still cleaning up the code and finding whatever bugs I introduced during REing |
| 14:29.25 | freemangordon | The "process" will start once replacement does what stock one do without the bugs |
| 14:42.29 | _ade_ | freemangordon: is the ALARM_EVENT_BOOT flag related to alarmUI (see http://talk.maemo.org/showpost.php?p=1145748&postcount=146 for an explanation of why I ask)? I do not see it in the code right away, so I guess not. |
| 14:46.40 | freemangordon | _ade_: seems alarm ui uses some "hidded" API reserved for systemui |
| 14:47.37 | _ade_ | freemangordon: okay, thanks |
| 14:47.53 | freemangordon | just a secon, i'll show you the code |
| 14:49.25 | freemangordon | hmm, seems I misunderstood your cuestion, but anyway, seems that raising the most significant bit when respondind to alarm event while in act_dead leads to boot |
| 14:49.33 | freemangordon | *question |
| 14:49.36 | freemangordon | here https://gitorious.org/community-ssu/osso-systemui-alarm/blobs/master/osso-systemui-alarm.c#line1043 |
| 14:51.42 | freemangordon | oh shit |
| 14:51.44 | freemangordon | https://gitorious.org/community-ssu/osso-systemui-alarm/blobs/master/osso-systemui-alarm.c#line588 |
| 14:51.58 | freemangordon | DocScrutinizer05: you meant hardcoded like that? |
| 14:53.26 | _ade_ | Is this address are a result of REing, and would it have been some kind of label in the original source? Sorry if it is a stupid question :-) |
| 14:53.58 | freemangordon | _ade_: address? |
| 14:54.15 | freemangordon | you mean file path? |
| 14:54.21 | _ade_ | well, called 0x80000000u an address |
| 14:54.31 | freemangordon | noo, this is not address |
| 14:55.03 | freemangordon | see here:https://gitorious.org/community-ssu/osso-systemui-alarm/blobs/master/osso-systemui-alarm.c#line166 |
| 14:57.41 | freemangordon | _ade_: I didn't find that defined in the headers, seems like some kind of internal API flag |
| 14:57.55 | freemangordon | but it is a result of REing |
| 14:58.19 | _ade_ | okay, somewhat to complicated for me. Anyway, I will keep in mind that ALARM_EVENT_BOOT just doesn't work, and I should stick to ACT_DEAD |
| 14:59.11 | freemangordon | but we can translate it like #define ALARM_EVENT_ACK_BOOT 1<<31 |
| 14:59.23 | freemangordon | or similar, codle still needs some cleanup |
| 14:59.27 | freemangordon | *code |
| 15:00.25 | _ade_ | If you could restore functionalty to what it should do, I am always in favour |
| 15:00.49 | freemangordon | well, so far it seems to work as it should |
| 15:01.04 | freemangordon | it woke me up this morning :D:D:D |
| 15:02.38 | _ade_ | You did read my link to TMO? That is what I am reffering to regarding ALARM_EVENT_BOOT and not working as it should. |
| 15:03.30 | freemangordon | did not read, just take a quick look |
| 15:03.41 | freemangordon | will do now |
| 15:04.29 | freemangordon | yeah, got it. though those flags are unrelated to alarmUI |
| 15:05.40 | _ade_ | okay, that's what I thought. The discussion got a whole other twist was my impression |
| 15:06.32 | freemangordon | yeah |
| 15:08.54 | freemangordon | ok, going to put that in -devel |
| 15:15.27 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 15:20.23 | freemangordon | arcean, _ade_: alarUI replacement is in -devel, please install the version from there |
| 15:20.28 | freemangordon | *alarmUI |
| 15:21.21 | _ade_ | freemangordon: can you upload to extras-devel atm? |
| 15:21.32 | freemangordon | _ade_: CSSU-devel :P |
| 15:21.41 | freemangordon | this is #maemo-ssu :D:D:D |
| 15:21.58 | _ade_ | oh, yeah, just thought of that when I replied ;-) |
| 15:24.29 | _ade_ | It is hosted by Merlin1991, so no issues over there |
| 16:07.28 | *** part/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 16:26.32 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 16:52.46 | *** join/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 16:56.18 | _ade_ | freemangordon: about the bug report we discussed yesterday (https://bugs.maemo.org/show_bug.cgi?id=12661): as far as I can see it is already linked to CSSU, with subcomponent H-D |
| 16:56.20 | povbot | Bug 12661: Popup menu fails with X Error while switching portrait/landscape |
| 16:58.19 | arcean | _ade_, "First annoyance is that it flips back to landscape |
| 16:58.19 | arcean | (why?)" is already fixed for non-Qt based apps |
| 16:59.03 | _ade_ | arcean: great, a first step ;-) |
| 17:00.25 | _ade_ | arcean: just started FAPMAN, it rotates back to landscape at startup ? |
| 17:00.56 | arcean | that's normal with current cssu-testing |
| 17:01.23 | _ade_ | the fix still needs to arrive then? |
| 17:01.44 | arcean | yes, and I have no idea when it will be :P |
| 17:02.31 | _ade_ | It might help me in some cases regarding my issue |
| 17:03.04 | arcean | Qt uses its own rotation mechanism, which doesn't work well with hildon-desktop |
| 17:18.53 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 17:22.59 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 17:24.52 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 17:48.34 | *** join/#maemo-ssu mickname (luodemm1@lyta.org.aalto.fi) |
| 18:08.49 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 18:14.30 | kerio | Qt sucks |
| 18:15.04 | kerio | it doesn't follow my keyboard bindings :( |
| 18:19.19 | *** join/#maemo-ssu timo^ (~timo@unaffiliated/tiempjuuh) |
| 18:21.33 | *** part/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 19:02.55 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 19:04.47 | *** join/#maemo-ssu luf (~luf@ip-89-103-223-164.net.upcbroadband.cz) |
| 19:27.37 | *** join/#maemo-ssu iDont (~iDont@j138215.upc-j.chello.nl) |
| 19:27.37 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 20:45.57 | *** join/#maemo-ssu infobot (~infobot@rikers.org) |
| 20:45.57 | *** topic/#maemo-ssu is Maemo Community Seamless Software Update "CSSU" channel, http://wiki.maemo.org/Community_SSU | Known bugs: http://j.mp/communityssu-bugs | Channel logs: http://mg.pov.lt/maemo-ssu-irclog/ | Sources: http://gitorious.org/community-ssu/ | Latest version (testing): 21.2011.38-1Tmaemo5.1; (stable): 21.2011.38-1Smaemo4.1 |
| 20:45.57 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 20:47.29 | merlin1991 | hm I built obexd already |
| 20:47.34 | merlin1991 | well that just leaves ke-recv |
| 20:52.06 | merlin1991 | I should create a build-cssu command that wraps that dpkg-buildpackage call :D |
| 20:55.44 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 20:55.52 | *** join/#maemo-ssu arcean (~arcean@aafs108.neoplus.adsl.tpnet.pl) |
| 21:03.40 | *** join/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 21:08.23 | merlin1991 | DocScrutinizer05: got some time to test the new -testing? |
| 21:08.35 | DocScrutinizer05 | possibly |
| 21:08.51 | _ade_ | arcean: adapted worldclock so it cannot start multiple occurrences the date/time applet in the worldclock- and main screen |
| 21:08.54 | DocScrutinizer05 | if you got some time for me to find some time for that |
| 21:09.14 | merlin1991 | timeception? |
| 21:09.19 | arcean | _ade_, thanks :) |
| 21:13.14 | merlin1991 | arcean: are you running a clean -testing or -thumb? |
| 21:13.40 | arcean | testing + devel combo :P |
| 21:14.28 | merlin1991 | that's fine, wanna test the new -testing? :D |
| 21:14.52 | arcean | why not :) |
| 21:15.21 | freemangordon | merlin1991: those with -thumb should be able to test it too |
| 21:15.39 | freemangordon | after all we fixed the versioning |
| 21:15.46 | merlin1991 | freemangordon: but if possible I'd like to test without sideffects ; |
| 21:16.06 | merlin1991 | hm found the first bug myself |
| 21:16.47 | freemangordon | care to share? |
| 21:17.03 | merlin1991 | just a path mistake in palis patch for ke-recv |
| 21:39.32 | merlin1991 | Pali: your patch to ke-recv seems to work |
| 21:39.58 | Pali | nice :-) (I did not tested them yet) |
| 21:40.02 | *** join/#maemo-ssu _rd (~rd@87.180.143.79) |
| 21:42.24 | merlin1991 | oaky arcean, install http://cdnm.at/~christian/maemo/cssu/testing-testing-enabler_0.1_all.deb and then run ham :) |
| 21:43.11 | merlin1991 | changelog can be found here (since the wiki i non editable) http://gitorious.org/community-ssu/mp-fremantle-community-pr/blobs/master/debian/changelog |
| 21:45.01 | kerio | dafuq is that |
| 21:45.52 | merlin1991 | kerio: hm? |
| 21:46.02 | kerio | oh, HAM domain information |
| 21:46.02 | kerio | meh |
| 21:46.18 | arcean | ok, HAM is running and melting my cpu :) |
| 21:46.47 | merlin1991 | and pretty please don't run into "no update here" or "dependency hell" :D |
| 21:47.18 | kerio | merlin1991: is the priority for that repo the same as the other cssu repos? |
| 21:47.28 | kerio | otherwise, it's going to be hell to go back for the peeps using HAM only |
| 21:47.39 | kerio | and yes, i said peeps |
| 21:47.59 | merlin1991 | kerio: this is not ment for the peeps |
| 21:48.17 | merlin1991 | but rather for like 3 people to test a release before we release it :D |
| 21:48.49 | DocScrutinizer05 | kerio's concern is valid though |
| 21:49.23 | DocScrutinizer05 | would it 'recover' from test by simply enabling the 'normal' repos again? |
| 21:50.22 | DocScrutinizer05 | or would any tester have to rollback/reflash? |
| 21:50.33 | merlin1991 | this is rollback reflash material |
| 21:50.41 | DocScrutinizer05 | ...to join community of normal mortals |
| 21:50.56 | merlin1991 | you can "recover" your ham by simply removing the package (even inside ham) |
| 21:50.58 | DocScrutinizer05 | ok |
| 21:51.07 | merlin1991 | but that sill would leave the upgraded mp on your device |
| 21:51.15 | DocScrutinizer05 | yep |
| 21:51.36 | DocScrutinizer05 | which wouldn't update 'normally' on next CSSU release |
| 21:51.46 | kerio | it appears to be the same as community-devel |
| 21:52.10 | merlin1991 | DocScrutinizer05: well mext cssu relaese would be 100% the same packages |
| 21:52.12 | DocScrutinizer05 | I could run this on a virgin device |
| 21:52.16 | kerio | this, of course, ignoring the fact that it might just *not work* because HAM also does checking by gpg key and thus it could put every package in one priority basket |
| 21:52.23 | merlin1991 | and the release after that would work as usual again |
| 21:52.35 | kerio | s/it/the priority separation/ |
| 21:52.58 | merlin1991 | since as soon as you remove the enabler the "domain" the package comes from has no priority, thus any package from the "main" cssu repo has higher priority |
| 21:53.14 | kerio | merlin1991: hm, that's a good point |
| 21:53.55 | merlin1991 | the only secnario in which you have to roll back is when shit blows up :D |
| 21:54.02 | kerio | DocScrutinizer05: "easy" way to fix, considering that people that will install that are "l33t", would be to enable redpill mode and disable the domain checking |
| 21:54.05 | DocScrutinizer05 | well, anyway I could test run this on a virgin N900 only. No way to nuke my daily phone with it |
| 21:54.11 | merlin1991 | but it shouldn't (obviously I ran it on my device already) |
| 21:55.56 | DocScrutinizer05 | so I could either run a direct install of new testingtesting, or install recent official cssu-t then upgrade |
| 21:56.16 | kerio | merlin1991: why did you password the repo, btw? |
| 21:56.17 | merlin1991 | 2nd |
| 21:56.40 | merlin1991 | kerio: so that random peeps with 0 knowledge don't get in |
| 21:57.00 | merlin1991 | since this is meant to break stuff in a limited circle where we can minimze damages |
| 21:57.46 | DocScrutinizer05 | hmm password? |
| 21:58.07 | kerio | kinda wants to paste the url here |
| 21:58.22 | merlin1991 | DocScrutinizer05: well the repo resides here: http://maemo.merlin1991.at/cssu/future/ |
| 21:58.46 | merlin1991 | it uses basic_auth which apt supports, the enabler adds user and pw to the sources.list |
| 21:58.56 | DocScrutinizer05 | aah |
| 21:59.11 | arcean | merlin1991, so far everything works ;) |
| 21:59.12 | DocScrutinizer05 | ok then, has to wait another 2 or 3 hours |
| 21:59.17 | DocScrutinizer05 | dinner first |
| 21:59.29 | *** join/#maemo-ssu user_ (~user@86.92.226.97) |
| 21:59.39 | merlin1991 | kerio: what do you think of the url + user + pass combinarion? :D |
| 21:59.53 | kerio | merlin1991: "the future happens now"? |
| 21:59.57 | merlin1991 | yep |
| 22:00.00 | kerio | neat |
| 22:04.19 | *** join/#maemo-ssu MrPingu (~MrPingu@86.92.226.97) |
| 22:14.06 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:16.02 | _ade_ | device starts up fine here after installing the latest cssu-t |
| 22:16.45 | _ade_ | arcean: I guess the patch to prevent rotation to landscape is not included yet? |
| 22:17.05 | merlin1991 | _ade_: should be |
| 22:17.27 | arcean | _ade_, no, and the patch works only with Gtk/Hildon applications ;) |
| 22:17.45 | merlin1991 | ah arcean so that#s some new stuff? |
| 22:18.17 | arcean | merlin1991, yes, a lot of fixes :P |
| 22:18.33 | merlin1991 | yay I like h-d fixes :) |
| 22:19.14 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 22:19.48 | DocScrutinizer05 | so are we including basically untested stuff to testing once again? |
| 22:19.50 | arcean | who doesn't like :) |
| 22:19.56 | merlin1991 | DocScrutinizer05: no |
| 22:20.00 | merlin1991 | we are testing it ffs |
| 22:20.53 | merlin1991 | DocScrutinizer05: personally I think the idea to run a testing-testing is there to make sure we have releases that contain 100% untested chagnes |
| 22:21.10 | merlin1991 | </sarcasm> |
| 22:21.20 | DocScrutinizer05 | what became of "users X, Y, Bill and Bob used it for 2 weeks, I provided it to them from my local location. It worked" |
| 22:23.51 | merlin1991 | hm lets see, camera-ui was a trivial patch, arcean claimed the new hildon-desktop works, ke-recv was trivial and tested by me, obexd has been tested according to luf, openssl is only a packaging change to free some rootfs (move debug symbols out of the package) pulse has been tested according to luf, and the orientationlock only got a new translation |
| 22:24.22 | merlin1991 | + we are currently in the pre release testing phase :D |
| 22:29.52 | _ade_ | merlin1991: my dutch status-area-orientationlock-applet translation is as expected |
| 22:30.21 | DocScrutinizer05 | I'm definitely in not testing phase to confirm any patches included are working as supposed. If anything this testing phase is meant to confirm *your* work on packaging etc |
| 22:31.10 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 22:31.14 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 22:39.31 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 23:05.06 | DocScrutinizer05 | the idea of testing-testing for sure wasn't to cram all new stuff bultt this morning into one rollout to get tested by 2 or 3 people who wouldn't even know what to look for. The testers each developer has to find on his own for his very project are supposed to test stuff on that level, downloaded from either devel's private website or cssu-devel. Then if developer has positive feedback from those testers who know what to look for, |
| 23:05.07 | DocScrutinizer05 | so he's able to convince others that there 99.99% certainty are no obvious bugs anymore. We integrate it into testing-testing and check this "distro" for bugs introduced by integration. That's what the 1...2 days test phase of testing-testing is meant for. Those testers have no idea what are the details in each new patch included that need special attention, nor may they even have an idea what got included at all. They just test the |
| 23:05.09 | DocScrutinizer05 | larger UX on upgrade/installation |
| 23:12.08 | merlin1991 | DocScrutinizer05: stop trolling and read my line about all the patches that went in |
| 23:13.04 | DocScrutinizer05 | if you think that's trolling then I understand why you suggest to read your damn line again instead of noticing the differences between what you stated there and what I suggested in my trolling |
| 23:14.12 | merlin1991 | " Then if developer has positive feedback from those testers who know what to look for" |
| 23:14.22 | DocScrutinizer05 | >>arcean claimed the new hildon-desktop works<< vs >>if developer has positive feedback from those testers who know what to look for, so he's able to convince others that there 99.99% certainty are no obvious bugs anymore<< |
| 23:14.27 | merlin1991 | Well our "developers" did have that "positive feedback" |
| 23:14.51 | merlin1991 | you can translate arcean claimed it works as arcean said it was tested |
| 23:15.26 | DocScrutinizer05 | I'd translate that as "it did build and didn't segfault when I started it 5 min ago" |
| 23:16.17 | DocScrutinizer05 | I didn't hear anything that makes me think anything different |
| 23:17.38 | DocScrutinizer05 | otherwise I'd have missed on some users discussing that feedback with him here |
| 23:17.57 | DocScrutinizer05 | or him stating how many testers tested it and for what duration |
| 23:18.18 | DocScrutinizer05 | arcean: no offense |
| 23:19.01 | DocScrutinizer05 | I'm just missing the explicit polling about status of the packages |
| 23:20.54 | arcean | DocScrutinizer05, the h-d from testing-testing is 1 month old |
| 23:21.23 | DocScrutinizer05 | obviously the amount of testing done to a patch prior to including it into cssu-testing(-testing) has to be negotiated each time again, but it has to be some agreement about maturity of a patch |
| 23:21.34 | DocScrutinizer05 | arcean: good enough for me |
| 23:21.50 | DocScrutinizer05 | that's all I missed |
| 23:21.52 | DocScrutinizer05 | :-) |
| 23:22.00 | DocScrutinizer05 | for each package though |