**** BEGIN LOGGING AT Tue Jan 12 02:59:56 2010 Jan 12 11:13:55 Hmm trying to run rootstock, I get mount -t devpts devpts /dev/pts Jan 12 11:14:02 mount: mount point /dev/pts does not exist Jan 12 11:46:44 lool, hmm, i thought there is a mkdir -p in the code Jan 12 11:47:31 ogra: I dont see any Jan 12 11:47:36 This is in the installer BTW Jan 12 11:48:09 I tried moving udevd --daemon up one line, and get /bin/installer: line 14: udevd: command not found Jan 12 11:48:11 hmm, the mount should probably run after udevd starts Jan 12 11:48:15 I suspect ubuntu-minimal isn't pulled Jan 12 11:48:23 yeah, smells like Jan 12 11:48:34 since you asked me to drop the hardcoding for it ;) Jan 12 11:48:51 It says the default is ubuntu-minimal Jan 12 11:48:57 it should Jan 12 11:49:11 unless debootstrap has some out-of-sync'ness Jan 12 11:49:56 debootstrap will use priorities to select packages Jan 12 11:50:07 I'm trying with an explicit ubuntu-minimal now Jan 12 11:52:29 same thing Jan 12 11:53:39 udev was certainly downloaded Jan 12 11:55:43 I think it's broken for vms; not sure why Jan 12 11:57:00 second stage isn't set Jan 12 11:59:27 The first failure is actually: Jan 12 11:59:28 + echo chroot: cannot run command `debootstrap/debootstrap': No such file or directory Jan 12 13:28:42 rcn-ee: Thanks for testing the --script patch; I tested it myself now and fixed a couple of issues with it Jan 12 13:29:06 rcn-ee: Pushed a new branch and requested a new merge; http://paste.ubuntu.com/355487/ is the diff of the interesting changes, branch is lp:~lool/project-rootstock/user-script Jan 12 13:33:12 thanks lool, just read the email actually.. ;) Jan 12 14:01:12 cooloney, they have to fix that Jan 12 14:02:08 they were in the crowd shouting for v7, neon and thumb2 too :) so they should make sure to have their code working with a recent compiler :P Jan 12 14:02:15 ogra: yeah, understand Jan 12 14:02:26 asac, something for tonights call i guess Jan 12 14:02:49 cooloney: ericm_: you asked if we have cross compilers availble Jan 12 14:02:58 ericm_, i thought lool prepared a ppa with cross tolls based on our compiler Jan 12 14:03:00 i dont know ... can you explain to me where you get those from? Jan 12 14:03:10 i thought you hvae to do them on your own Jan 12 14:03:11 asac: yeah, cross compiler 4.4 Jan 12 14:03:15 lool, ^^^ is that gcc 4.4 ? Jan 12 14:03:26 asac, you use codesourcery Jan 12 14:03:32 asac: normally, we get the binary gcc from codesourcery Jan 12 14:03:34 but they are only on 4.3 iirc Jan 12 14:03:39 asac: and i think the latest one is 4.3 Jan 12 14:03:51 asac: but i am searching on their site now Jan 12 14:03:56 ah. i thought you have to do that on your own ... is there a good wiki explaining what you do? Jan 12 14:04:09 amitk's blog :) Jan 12 14:04:20 I have cross compilers in my ppa Jan 12 14:04:30 They are suitable for the kernel, but not for userspace due to a bug Jan 12 14:04:33 ericm_, cooloney, ^^^ Jan 12 14:04:38 so use these Jan 12 14:04:46 ogra, lool, thanks Jan 12 14:04:48 We decided we wont go this way though, so I'm not investing in fixing these right now Jan 12 14:04:49 lool, you have a link? Jan 12 14:04:55 ppa:lool/ppa ? Jan 12 14:05:02 lool, ok Jan 12 14:05:05 lool, as long as the kernel can be built ... Jan 12 14:05:12 http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite Jan 12 14:05:32 i think we can try this 4.4 cross compiler from codesourcery now Jan 12 14:05:35 For the kernel, you might have to remove the libgcc linkage which I think should be dropped upstream; I think it's a terribly old construct Jan 12 14:05:53 Yes, codesourcery has 4.4 now Jan 12 14:06:01 I would be very conservative about updating to a new compiler Jan 12 14:06:09 they are almost always buggy Jan 12 14:06:11 amitk: got you guys Jan 12 14:06:16 * ogra takes a break Jan 12 14:06:35 I think I've already been using the latest codesourcery gcc Jan 12 14:07:08 might be a good chance to give marvell toolchain a try Jan 12 14:08:24 Native builds aren't that bad. Try them! You might find the results interesting, or even useful :) Jan 12 14:08:49 persia, ok - will try Jan 12 14:09:23 * ericm_ needs some sleep Jan 12 14:11:55 ericm-Zzz: good night Jan 12 14:40:33 dmart: hi Jan 12 14:40:36 Hi Jan 12 14:40:50 * asac gets the thumb2 link Jan 12 14:41:52 https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList Jan 12 14:42:51 dmart: so can we clearly prioritize by what type of issue we have? Jan 12 14:43:06 e.g. swp > ldr > mov > ldrex (or some other order) Jan 12 14:43:46 Maybe rather mov > (swp,ldrex) > ldr Jan 12 14:44:30 I need to talk to the kernel guys, but we have a patch to emulate SWP in the kernel. This is slow, but it avoids us having broken packages and gives us a chance to migrate Jan 12 14:44:50 ldrex packages may not be SMP-safe Jan 12 14:45:07 ldr packages my just "perform a bit better" if built in ARM Jan 12 14:45:24 ...so I separated them out and we can consider them low priority Jan 12 14:47:06 ok i added a few columns to the table Jan 12 14:47:10 which we can later use to sort: Jan 12 14:47:21 rdepends (number of packages that depend on it) Jan 12 14:47:31 section (base, standard, optional) Jan 12 14:47:48 and comments -> like for apex i added that its a none issue because its armv5 bootloader Jan 12 14:47:54 we do use sections ? Jan 12 14:48:01 well Jan 12 14:48:14 its good to identify if something is part of the base system etc. Jan 12 14:48:17 I found a few packages in main which have no rdepends in main... it might be worth tracking thta Jan 12 14:48:38 like binutils: is probably more important than some app Jan 12 14:48:59 indeed Jan 12 14:49:10 dmart: those packages usually automatically get demoted . we have a component-mismatches Jan 12 14:49:12 but i didnt know these sections actually mean anything in ubuntu Jan 12 14:49:13 url Jan 12 14:49:16 ogra: have that at hand? Jan 12 14:49:22 i thought they are debian only Jan 12 14:49:49 ogra: they dont mean anything, but they give indication for the prioritization we are doing Jan 12 14:49:52 :) Jan 12 14:50:09 aka they still mean something, because they mean something in debian Jan 12 14:50:10 http://people.canonical.com/~ubuntu-archive/component-mismatches.txt Jan 12 14:50:14 ^^^ Jan 12 14:51:03 dmart: thx Jan 12 14:51:05 ooops Jan 12 14:51:07 ogra: thx Jan 12 14:51:20 I don't mind :) Jan 12 14:51:21 dmart: that page above is regularly reviewed. stuff that has no rdepends in main should get demoted Jan 12 14:51:36 OK, maybe we don't need to worry too much about that then Jan 12 14:51:38 look for " Source and binary demotions to universe Jan 12 14:51:39 " Jan 12 14:51:44 right Jan 12 14:52:28 dmart: you said in your mail you wanted to do something ... and before that we shouldnt remove anything from that list. did that happen? Jan 12 14:52:38 i dont mind to keep everything in there Jan 12 14:53:16 If things get deleted, we don't track _why_ they were deleted... but we could move them to a separate table, with a brief note about why Jan 12 14:53:35 That was my only concern Jan 12 14:53:35 ah ok. thats ok then. i think the comment column is good enough for now Jan 12 14:53:39 right Jan 12 14:53:48 I think the first job is to do a fairly quick review through the whole list, getting the info for your suggested colums, and quickly assessing the impact of the source code issues Jan 12 14:54:17 Maybe it would be easiest just to chop the list for main into a few pieces and try that? Do you know who would be available to review? Jan 12 14:54:22 right. so the mechanic stuff i can get someone doing (e.g. fill in the number of rdpends and then sort the wiki page Jan 12 14:54:51 Yep, that should be fairly straightforward and quick to do Jan 12 14:55:39 * ogra is happy to report that the imx51 kernel in the archive works well Jan 12 14:56:09 ogra: Is that 2.6.31.602.3? Jan 12 14:56:20 yep, the one uploaded yesterday Jan 12 14:56:34 Ah... I have a board here running it too Jan 12 14:56:38 seems OK Jan 12 14:56:39 dmart: do you think it would take longer than 1h or so if we go through the list together here to add tne initial comments? that would ensure we make the progress and we dont have to wait on someone ;) Jan 12 14:56:45 its aweesome Jan 12 14:56:59 asac: No, that sounds like a good first step Jan 12 14:56:59 then i will get someone filling the sorting columns and we can distribute the real porting tasks to individuals based on that Jan 12 14:57:00 way better than any first-release we ever had Jan 12 14:57:09 ok lets get started then ;) Jan 12 14:57:14 #startmeeting ;) Jan 12 14:57:18 haha Jan 12 14:57:27 binutils Jan 12 14:57:41 ? Jan 12 14:57:47 thats the first package in the table ;) Jan 12 14:58:14 apex is first (though probably ignorable) Jan 12 14:58:15 let me open the filtered lists Jan 12 14:58:22 dmart: yes, already filled in the comment ;) Jan 12 14:58:32 * dmart hits refresh Jan 12 14:58:39 ah Jan 12 14:59:03 Might it be better to split the list and work offline? Jan 12 14:59:27 if that works for you. i just think its going to take longer that way ;) Jan 12 14:59:35 unless one takes all the workload Jan 12 15:00:05 Maybe Jan 12 15:00:14 let me open the filtered files ... then i hope it will go quicker Jan 12 15:00:49 All binutils and gcc packages: I suggest to ignore. This is dealt with separately with doko etc. Jan 12 15:01:48 right Jan 12 15:01:56 i can fill in the comments we find Jan 12 15:02:00 so we dont get conflicts Jan 12 15:02:49 dmart: eglibc too i guess? Jan 12 15:02:51 Actually, gcc-4.4 has a problem with swp in the boehm-gc code... I'll try and find the lp bug tracking this for openjdk Jan 12 15:03:49 Hmmm, no lp bug. Can you add a note on that? Jan 12 15:05:22 yes Jan 12 15:05:31 added that to comments Jan 12 15:07:31 boost1.38 and boost1.40 both contain spinlocks and atomics code using swp Jan 12 15:07:32 ok finally have all the filtered files Jan 12 15:08:15 ok Jan 12 15:08:18 noted Jan 12 15:08:28 cacao-source -> Jan 12 15:08:29 How to I find out the rdepends for a source package? Jan 12 15:09:08 cacao-source has the same boehm-gc problem as in gcc-4.4, and also uses swp in a couple of other places. Jan 12 15:09:12 ldrex seem to be used in armv6 header there Jan 12 15:09:40 dmart: hmm. you have to check rdpeends for the binaries Jan 12 15:09:46 Oh, OK Jan 12 15:09:48 one could write a script for that Jan 12 15:09:56 I was hoping you had one :) Jan 12 15:09:57 or are you looking for build-rdepends? Jan 12 15:10:11 Not really, should we? Jan 12 15:10:17 dmart: no. but i will get someone else fillin the rdepends ;) Jan 12 15:10:22 OK Jan 12 15:10:35 dmart: that would be useful if we have issues in inline funcs in headers Jan 12 15:10:39 but i hope not ;) Jan 12 15:11:07 Do you want to move this discussion to another channel? This is a lot of spam for people who aren't interested Jan 12 15:11:44 dmart: i think its ok this channel quite quiet ... if you prefer we can go somewhere else Jan 12 15:11:51 apt-cache rdepends ${package} can be useful Jan 12 15:12:04 asac: OK, stay here for now them Jan 12 15:12:05 But one has to check the results, as it also lists Conflicts and Breaks, etc. Jan 12 15:12:16 dmart: unless someone complains ;) Jan 12 15:12:20 so cln Jan 12 15:12:43 aptitude is also useful Jan 12 15:12:50 grep cln * | pastebinit Jan 12 15:12:50 http://pastebin.com/f33d714b6 Jan 12 15:13:22 cacao-source: Jan 12 15:13:40 ... is a JIT and it likely to make a lot of assumptions about ARM versus Thumb-2... some real work is probably needed for this. We should check with doko on priority for this one Jan 12 15:14:14 dmart: yes. i will add a comment about jit needing work Jan 12 15:15:46 cln -> I already had a brief look. This is some kind of arbitrary precision library. The seems to be some run-time compilation for ARM, but comments in debian/rules say it's broken and appear to disable it anyway. Jan 12 15:16:17 I think there are no rdepends in main for this one? Jan 12 15:17:04 check apt-cache rdepends libcnl6 Jan 12 15:17:07 there should be a bunch Jan 12 15:17:11 oh in main Jan 12 15:17:32 yes the lib is in binary demotions Jan 12 15:17:38 http://people.canonical.com/~ubuntu-archive/component-mismatches.txt Jan 12 15:17:42 but probably "pi" is used Jan 12 15:18:00 hmm. just by the lib from what i can tell Jan 12 15:18:14 You can check this with a limit like ~smain~Dlibcln in aptitude Jan 12 15:18:35 dmart: so based on the grep those movs in cln needs to be fixed? Jan 12 15:18:35 pi is a demo program which computes pi :) Jan 12 15:20:13 In debian/rules it says "CLN's assembler support is not working properly ..." and adds -DNO_ASM. I did an offline build--- it builds in Thumb-2 without errors and the testsuite passes OK, so I think the assembler is not used. Jan 12 15:20:33 ok. great. Jan 12 15:20:55 noted Jan 12 15:20:58 OK Jan 12 15:20:59 coreutils Jan 12 15:21:21 http://pastebin.com/f5115c6cb Jan 12 15:21:25 seems just one swp Jan 12 15:21:31 in a test Jan 12 15:22:02 * asac checks build log if make check is run Jan 12 15:22:23 I think that's a false positive... doesn't look like assembler to em Jan 12 15:23:20 yes Jan 12 15:23:22 that test passes Jan 12 15:23:29 PASS: misc/printf-cov Jan 12 15:23:30 on armel Jan 12 15:23:32 http://launchpadlibrarian.net/33115198/buildlog_ubuntu-karmic-armel.coreutils_7.4-2ubuntu1_FULLYBUILT.txt.gz Jan 12 15:23:39 but that was karmic Jan 12 15:23:46 e.g. needs to get respun Jan 12 15:23:56 I can't see any reason why printf would have atomics anyway Jan 12 15:24:38 ok db Jan 12 15:24:43 i thinnk i fixed db4.2 Jan 12 15:24:55 at least i added gcc atomics there to fix a build failure Jan 12 15:25:13 and the newer db versions seem to use pthread mutexes Jan 12 15:25:26 like db4.6 doesnt use that code anymore iirc Jan 12 15:25:35 OK... db (4.8), db4.2 and db4.6 all seem to have the same code; can we apply the same patch to them all? Jan 12 15:26:03 dmart: yes, we probably can, but only 4.2 failed on that code, which is why i didnt do that Jan 12 15:26:17 anyway, we might want to do that anyway, and hope it flows upstream at some point Jan 12 15:27:15 noted Jan 12 15:27:20 djvulibre Jan 12 15:27:27 Might be a good idea. Code involving swp will generally work (and pass tests) on our current platforms (except maybe on dove under stress?) ... this is more for avoiding future problems. Jan 12 15:27:31 search-arm-mov.filt: ./djvulibre-3.5.22/libdjvu/GThreads.cpp: "mov%?\t%|pc, %1" // branch to address %1 Jan 12 15:27:51 dmart: hmm ... strange that it failed to build for db4.2 though Jan 12 15:27:55 anyway, lets continue Jan 12 15:28:06 i noted that we should put the patch everywhere Jan 12 15:28:16 db* - should we flag this up for SMP safety, or are you confident the memory barriers implied by the GCC intrinsics are adequate? Jan 12 15:28:36 lets flag this up. no clue if i messed it up ;) Jan 12 15:28:58 noted Jan 12 15:29:29 OK, djvulibre Jan 12 15:30:37 seems that mov is assembler ... Jan 12 15:30:38 Looks like it may need fixing. mov pc, won't interwork correctly if built in Thumb. Jan 12 15:30:44 right Jan 12 15:31:01 If it's in threading code, the branch could be supposed to go absolutely anywhere Jan 12 15:31:57 yeah Jan 12 15:31:59 ok ... dmake Jan 12 15:32:01 dmake - looks like a false match: it's a sed munge in a Makefile Jan 12 15:32:10 SH_n = $(@:s/swp-/-/:s,-,/,:s/scripts/${SCRIPTFILE}/) Jan 12 15:32:20 noted Jan 12 15:32:32 i have eglibc currently in the same boat as gcc etc. Jan 12 15:32:46 if you disagree we can make that a doko tasks Jan 12 15:33:10 search-arm-mov.filt: ./emacs23-23.1+1/lisp/emulation/pc-select.el: (pc-select-add-to-alist pc-select-saved-settings-alist ,var ,var) Jan 12 15:33:11 It might be a good idea to flag up all the toolchain type stuff for doko to give a judgement on Jan 12 15:33:21 emacs23 sems to be a false positive Jan 12 15:33:52 grep erlang * | pastebinit Jan 12 15:33:53 http://pastebin.com/f7ec03435 Jan 12 15:33:57 I guess so. I think elisp is strictly interpreted Jan 12 15:34:36 (emacs: the .el line is the only line that is in your filtered list, so its a false positive, yes.) Jan 12 15:35:16 erlang: someone needs to take a more careful look. There might be some runtime code gen in there Jan 12 15:35:34 It looks a bit like it from the matches Jan 12 15:35:44 yes, and the grep shows code that needs to be checked Jan 12 15:36:13 espeak Jan 12 15:36:25 search-arm-mov.filt: ./espeak-1.41.01/platforms/riscos/s/assemb:MOVNEr8,pc Jan 12 15:36:28 hmm. riscos? Jan 12 15:36:45 would that be us? Jan 12 15:36:47 * asac wont think so Jan 12 15:37:01 ubuntu-risc FTW ! Jan 12 15:37:42 evolution-data-server Jan 12 15:37:45 Unlikely to apply to us. Someone chould probably check it out... maybe some code was written for riscos but reused on ARM generally. But it feels low priority Jan 12 15:37:54 (last comment applies to espeak btw) Jan 12 15:37:56 ./evolution-data-server-2.28.1/libdb/dbinc/mutex.h:asm volatile("swpb %0, %1, [%2]" Jan 12 15:38:01 seems that might be atomics Jan 12 15:38:09 Looks like it Jan 12 15:38:27 noted Jan 12 15:38:39 ffmpeg -> guess that needs to build first ;) Jan 12 15:38:56 FTBFS, or just not built yet? Jan 12 15:39:23 http://pastebin.com/f5558192 Jan 12 15:39:28 dmart: it currently ftbfs even Jan 12 15:39:39 http://qa.ubuntuwire.com/ftbfs/ Jan 12 15:39:50 https://edge.launchpad.net/ubuntu/+source/ffmpeg/4:0.5+svn20090706-2ubuntu4/+build/1409808/+files/buildlog_ubuntu-lucid-armel.ffmpeg_4:0.5+svn20090706-2ubuntu4_FAILEDTOBUILD.txt.gz Jan 12 15:40:20 but chromium ffmpeg builds ;) Jan 12 15:40:52 We should check whether chromium ffmpeg is using the ARM asm and NEON in particular Jan 12 15:41:06 ... should there be a separate ffmpeg there at all though? Jan 12 15:41:34 we dont use NEON, because we dont have NEON atm and the rest of chromium will not use hwcaps to use it based on support Jan 12 15:41:52 not surprised Jan 12 15:41:52 dmart: well. we kind of accepted that trying to use system libs for chromium isnt worth the effort Jan 12 15:42:04 they usually pull in snapshots Jan 12 15:42:11 and bump the revisions pulled in frequently Jan 12 15:42:12 I'm still trying to get NEON to work correctly in the latest builds of GCC Jan 12 15:42:20 I'll try and raise a lp bug on that. Eventually, we do want good video performance in a browser ;) Jan 12 15:42:23 Martyn: ffmpeg? Jan 12 15:42:36 Even the latest CodeWarrior gcc doesn't seem to quite get it right Jan 12 15:42:43 dmart: there is a bug related ... one sec Jan 12 15:42:45 CodeWarrior or Sourcery? Jan 12 15:42:51 CodeSourcery Jan 12 15:43:06 Heh, spellcheck auto-fsked that Jan 12 15:43:13 he Jan 12 15:43:31 http://code.google.com/p/chromium/issues/detail?id=30991 Jan 12 15:43:32 dmart: ^^ Jan 12 15:43:37 thats where i asked about it Jan 12 15:43:44 though it was for non ffmpeg related neon Jan 12 15:43:53 however, I have seen some hand-coded ASM libs that reference NEON Jan 12 15:43:55 guess ffmpeg could be done Jan 12 15:44:22 and do the check to see if it's a vfp or NEON enabled processor Jan 12 15:44:52 For ffmpeg proper, we build a separate library flavour and use ld.so hwcaps Jan 12 15:44:56 (not ffmpeg. In muy case, it's marble .. a biotech program) Jan 12 15:45:15 There's a lot of hand-optimised code in ffmpeg anyway, so it may make sense to built ffmpeg with -marm. This might be done already, but can you make a note to double-check it? Jan 12 15:45:47 Not built with -marm ATM Jan 12 15:46:29 dmart: i saved what we have for now. i will probably finish and fill in what i can see after call Jan 12 15:46:45 lool : Shouldn't we be building with -marm? Jan 12 15:46:53 ffmpeg? thats the plan afaik Jan 12 15:46:57 OK. I guess ffmpeg needs a bit of further review, but it doesn't look like there's a major problem Jan 12 15:46:59 Or is the effort to build v7-a thumb getting in the way of that? Jan 12 15:47:27 Martyn: in the way of what? Jan 12 15:47:33 using -marm Jan 12 15:47:56 No, we can still use -marm for specific packages Jan 12 15:48:00 ...if needed Jan 12 15:48:13 [...] Jan 12 15:48:15 gccxml? Jan 12 15:48:34 Is this effectively a port of GCC? I was never too sure Jan 12 15:48:51 XML output extension to GCC Jan 12 15:48:55 no clue ;) Jan 12 15:49:12 Another one for doko then. I suspect it's a non-issue Jan 12 15:49:31 http://paste.ubuntu.com/355573/ Jan 12 15:49:56 hmm Jan 12 15:49:56 ok noted Jan 12 15:50:04 gdb -> doko ? Jan 12 15:50:09 yes Jan 12 15:50:49 ghostscript seems to be false positive Jan 12 15:51:00 grep ghostscript * | pastebinit Jan 12 15:51:00 http://pastebin.com/fc30016a Jan 12 15:51:07 agreed Jan 12 15:51:20 search-arm-swp.filt: ./glib2.0-2.22.2/glib/gatomic.c: "swp %0, %1, [%2]\n" Jan 12 15:51:30 i think thats fixed Jan 12 15:51:35 by using intrisincs if available Jan 12 15:51:39 but i will add item to check that Jan 12 15:52:05 I think I posted a patch for that :) I can probably get the bug number Jan 12 15:53:32 glib2.0: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872 Jan 12 15:53:35 Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [High,Fix released] Jan 12 15:53:49 yeah Jan 12 15:54:05 ok ... taking quick break; then call! Jan 12 15:54:08 saved the wiki Jan 12 15:54:37 OK, thanks for the progress so far, I think that's 30-40% of the main list Jan 12 15:55:29 hehe yeah. took some time to ramp up, but that should be quick. of course loads of porting work will come out of this - so we definitly need to prioritize reasonably Jan 12 15:55:53 hmm i busted the wiki table ;) Jan 12 15:56:03 Doing a quick first pass so we can make the right decisions seems the right thing to do Jan 12 15:56:13 found the issue Jan 12 15:56:19 yes Jan 12 19:55:39 * asac checks if ffox 3.6 is happily spinning on arm before going away Jan 12 19:56:40 ok seems like. waiting for xulrunner to finish: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3 Jan 12 21:12:24 http://www.youtube.com/watch?v=_qGNj0YqFMM **** ENDING LOGGING AT Wed Jan 13 02:59:57 2010