**** BEGIN LOGGING AT Tue Oct 08 02:59:59 2013 Oct 08 07:00:28 good morning Oct 08 09:13:13 morning all Oct 08 09:20:37 gm bluelightning, all Oct 08 09:24:51 morning Oct 08 09:29:03 RP: hi. I've tried your yesterday's patch: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=96dab59a53a546d5fcbeed263170c56c9b03d137 but I still have the wrong asound.conf (the one from meta-fsl-arm "mx6" folder, not the one from my own layer's "nitrogen6x" folder). My layer's recipe is: http://pastebin.com/HkrjaWKe Oct 08 09:29:29 panda84kde: what does the do_unpack log say? Oct 08 09:30:03 panda84kde: you had my utils.py patch applied too? Oct 08 09:45:37 RP: yes, I applied them both. Will post log.do_unpack Oct 08 09:49:24 RP: http://pastebin.com/eKnPv4vB In the log I have the correct order (nitrogen6x, mx6q, mx6, armv7a, arm) and it is looking for alsa-state-init, so the 2 patches are applied Oct 08 09:51:08 Is the order in the log relevant? If meta-fsl-arm/recipes-bsp/alsa-state/alsa-state/mx6 appears before my-layer/recipes-bsp/alsa-state/alsa-state/nitrogen6x does that mean that the asound.cond is take from meta-fsl-arm? Oct 08 09:51:20 *taken Oct 08 10:42:40 I have no x11 support in DISTRO_FEATURES and when doing 'bitbake world' I have errors like: ERROR: libx11 PROVIDES virtual/libx11 but was skipped: 'x11' not in DISTRO_FEATURES, ERROR: nativesdk-libx11 PROVIDES virtual/libx11 but was skipped: 'x11' not in DISTRO_FEATURES, ERROR: libx11-diet PROVIDES virtual/libx11 but was skipped: 'x11' not in DISTRO_FEATURES,ERROR: Required build target 'tk' has no buildable providers. Oct 08 10:43:01 isn't 'bitbake world' supported for x11less distros? Oct 08 10:53:26 Krz-: currently, world does not handle skipped recipes Oct 08 10:53:32 Krz-: there is a bug open: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5321 Oct 08 10:53:33 Bug 5321: normal, Undecided, ---, richard.purdie, NEW , When DISTRO_FEATURES are removed, bitbake world should still work Oct 08 11:25:29 bluelightning: patch we discussed for libav: http://patches.openembedded.org/patch/59479/ Oct 08 11:26:31 panda84kde: yes, order is important and this hints at another issue... Oct 08 11:26:47 bluelightning: what is your view on layer priority verses overrides? Oct 08 11:27:08 bluelightning: for finding files for SRC_URI Oct 08 11:27:35 Krz-: there are some patches in master which help Oct 08 11:27:52 Krz-: by no means sorted yet though Oct 08 11:28:48 panda84kde: your layer is sorting after the meta-fsl-arm layer. If you change that, the order will be better Oct 08 11:41:48 RP: Yeah, in fact it works forcing higher priority. However that means this FAQ is not valid in this case: http://www.openembedded.org/wiki/Layers_FAQ#I.27ve_bbappended_a_recipe_in_my_layer_to_replace_a_file_with_my_own_version_but_it.27s_not_being_picked_up_-_why_not.3F Oct 08 11:57:31 panda84kde: it means we need to mention layer priorities too, yes :/ Oct 08 12:00:56 RP: I still have this thread sticked: http://lists.linuxtogo.org/pipermail/bitbake-devel/2011-August/001169.html ;) Oct 08 12:01:48 RP: last time I've asked Paul said iit is fixed now Oct 08 12:02:05 ant_work: I was going to sat, I thought that god fixed? Oct 08 12:02:10 s/sat/say/ Oct 08 12:02:41 RP: tbh I did not test it anymore ;) Oct 08 12:04:43 * panda84kde didn't know god fixes bugs in Yocto Oct 08 12:05:16 RP: there are really few cases after the heavy meta-oe cleanings Oct 08 12:05:55 people do notice it while adding own layers Oct 08 12:06:40 gah, s/god/got/ :) Oct 08 12:22:04 Hi, I'm trying to write a recipe for a perl module, I use inherit cpan_build and everything build fine, but when I'm tryng to install generated rpm I have the following error: error: Failed dependencies: buildpath/tmp/sysroots/i686-linux/usr/bin/perl-native/perl.real is needed by PackageName Oct 08 12:22:46 beuh: you have a script with that as the line at the top Oct 08 12:23:01 beuh: you probably need to sed it to #!usr/bin/env perl Oct 08 12:23:54 ok I checking that thx Oct 08 12:25:25 RP: we use now BBCLASSEXTEND "klibc" but properly should be "klibc-static". For the recipe, the suffix "-static" is forbidden but what about class names? Oct 08 12:26:27 RP: hm... it would need custom packaging probably Oct 08 12:26:50 ant_work: are you ever going to have non-static klibc? Oct 08 12:26:56 nope Oct 08 12:27:12 well, not in my usecases Oct 08 12:28:47 ant_work: I'm be tempted not to worry about it, or just call it "klibcs" or something Oct 08 12:28:58 personally I can live with it Oct 08 12:29:00 :) Oct 08 12:29:25 thx Oct 08 12:29:56 RP: I'll bother you after relase wrt that darned klcc-cross Oct 08 12:31:16 Hi All! Oct 08 12:31:18 Is there a way to specify version of packages included in Poky by Yocto? Oct 08 12:46:40 panda84kde: thanks Oct 08 12:47:21 bluelightning: np Oct 08 12:47:29 afternoon all, I want to know what package a standard python module resides in, is there an easy way of doing this? Oct 08 12:47:51 I looked at the python_2.7.3 recipe and it's very... dynamic Oct 08 12:50:58 also is there a way to create an x86_64 sdk and an i686 sdk at the same time? Oct 08 12:51:37 ah, I found the python module I need in the manifest file, so ignore that question Oct 08 12:54:56 jackmitchell: not really out of the box, SDKMACHINE can only have one value Oct 08 12:55:31 bluelightning: np, I was just wondering if I could get out of a manual change and double run scenario Oct 08 12:55:37 jackmitchell: easiest way to find a python module is to look in packages-split under the python workdir Oct 08 12:55:53 bluelightning: ah hah, that does sound like a sensible way to do it, thanks! Oct 08 12:58:06 bluelightning: ok, just one more (hopefully), I want a python available to the host in an sdk, I added the python module to the image, but it is just available in the target sysroot, no the native-sdk sysroot Oct 08 13:00:20 jackmitchell: right, in that case you'd need to add nativesdk-python-xyz to TOOLCHAIN_HOST_TASK Oct 08 13:00:23 would I have to add nativesdk-python-compile to my image Oct 08 13:00:29 ah ok Oct 08 13:01:13 bluelightning: distro.conf? Oct 08 13:01:25 or image.bb? Oct 08 13:01:48 jackmitchell: depends... you could do it in the image recipe; if you do do it at a higher level you'd want to use _append and not += (since some recipes use ?= to set TOOLCHAIN_*_TASK) Oct 08 13:02:03 in the new version of the manual that variable is even documented... :) Oct 08 13:02:13 ah I just searched and couldn't find it Oct 08 13:02:42 http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html Oct 08 13:02:52 we've added a ton more variables in the 1.5 ("latest") version of the manual Oct 08 13:02:53 doesn't have it, is that not the current iteration? Oct 08 13:03:08 until the final release that's still the 1.4 version Oct 08 13:03:27 replace "current" with "latest" or "1.5" Oct 08 13:03:33 ok, thanks Oct 08 13:18:33 bluelightning: the bug you pointed me to says 'when DISTRO_FEATURES are removed, bitbake world should still work' Oct 08 13:18:53 bluelightning: not sure if that's my case, since I have a DISTRO_FEATURES inside image recipe... Oct 08 13:19:00 bluelightning: inside image recipe Oct 08 13:19:09 Krz-: er, you should never set DISTRO_FEATURES in an image recipe, that can't work Oct 08 13:19:50 DISTRO_FEATURES influences how recipes are configured/compiled, that can't be done from another recipe Oct 08 13:20:00 it has to be done at the configuration level Oct 08 13:20:02 bluelightning: sorry, I have that in my-machine.conf, not inside image recipe Oct 08 13:20:20 hmm, that's not really the right thing to do either Oct 08 13:20:28 bluelightning: so where should it be? Oct 08 13:20:30 although it will "work" Oct 08 13:20:34 custom distro config Oct 08 13:21:12 bluelightning: the distro I put in conf/local.conf as a DISTRO ? Oct 08 13:22:24 yes Oct 08 13:22:40 bluelightning: so I did put DISTRO_FEATURES to my-tiny.conf which is used in conf/local.conf -> DISTRO="my-tiny.conf", the same problem with x11 Oct 08 13:22:53 bluelightning: bitbake world complains about x11 missing from DISTRO_FEATURES Oct 08 13:23:06 yes, that is a completely separate problem, as described by the bug Oct 08 13:23:07 bluelightning: I have uclibc with some extensions in DISTRO_FEATURES, but no x11 Oct 08 13:23:39 bluelightning: yeah, but the bug says 'When DISTRO_FEATURES are removed...' - how is DISTRO_FEATURES removed in my case? Oct 08 13:23:56 x11 has been removed as compared to the default value Oct 08 13:24:04 bluelightning: ok, got it Oct 08 13:24:44 bluelightning: when could I approx. expect this to be fixed? Oct 08 13:25:38 JaMa: as you expressed interest, you may like v2 of my sanity patch: http://pastebin.com/7LCZF55Z Oct 08 13:31:17 rburton: thanks, doesn't look so bad Oct 08 13:31:28 Krz-: its scheduled for some time in the 1.6 cycle, probably a month or two off... Oct 08 13:31:43 Krz-: we do have some patches queues so I'd say sooner than later in the cycle Oct 08 13:31:49 JaMa: just core-image-sato Oct 08 13:31:55 JaMa: recipes can extend the whitelist Oct 08 13:31:57 RP: alright, great Oct 08 13:32:08 JaMa: so every *proto is fixed locally already Oct 08 13:32:13 RP: I needed bitbake world to create full repository of all possible packages that builds with our distro Oct 08 13:32:33 RP: so now I probably need to do 'bitbake package1 package2 package3 ...' Oct 08 13:32:40 RP: is there any shortcut I can do? Oct 08 13:32:55 Krz-: for now, you could create a /inc file containing entries like EXCLUDE_FROM_WORLD_pn-xxxx = "1" Oct 08 13:32:56 RP: like use bitbake somehow and grep for non x11 recipes? Oct 08 13:33:04 Krz-: you can EXCLUDE_FROM_WORLD Oct 08 13:33:09 oh, RP beat me Oct 08 13:33:17 :) Oct 08 13:33:24 my local.conf has that for the entire qt platform, so i can do "world" builds that don't actually involve qt. Oct 08 13:33:55 rburton: I did wonder if qt should become a distro feature just so I can turn it off ;-) Oct 08 13:33:58 but EXCLUDE_FROM_WORLD takes certain recipes, right? I cannot do 'EXCLUDE_FROM_WORLD_pn-x11' Oct 08 13:34:10 RP -- you have my vote.. ;) Oct 08 13:34:13 Krz-: correct, you need to enumerate the full list Oct 08 13:34:15 Krz-: you'd have to generate a list of recipes Oct 08 13:34:30 do a world build and you get the first iteration of what needs to be added Oct 08 13:34:35 rinse, repeat Oct 08 13:34:37 RP: ok, I can just do some clever grep to figure out the list of x11 enabled recipes Oct 08 13:34:38 Krz-: not perfect I know but you would just have to do it once until the other changes are ready Oct 08 13:35:13 RP: yeah, I know. At this stage I don't care as long as I can build valid repository containing as much as possible Oct 08 13:35:36 they said it will be relaxed after announcement... Oct 08 13:35:41 :| Oct 08 13:35:59 Krz-: you believed them? ;-) Oct 08 13:36:16 "after" is such a vague duration Oct 08 13:36:18 :) Oct 08 13:36:30 shame on me Oct 08 13:37:43 Krz-: i generated by qt list fairly quickly, the problem can be finding that one last packagegroup which manages to hide itself from the usual introspection tools Oct 08 13:38:32 krz-: if you reach a roadblock feel free to post your list, someone might be able to spot the missing items quickly Oct 08 13:39:30 rburton: I will be going through this in few minutes Oct 08 13:48:33 I'm currently having a strange problem with the GDB cross toolchain. I build the complete compiler and gdb-cross toolchain. When I debug an application it runs fine using global breakpoints but as soon as I do a single step it crashes the application with a segfault in ld-linux. I finally found a solution by setting the sysroot to remote:/ but I can't believe that's the only solution. show sysroot results in "/opt/msc_1.04/msc-ldk-q7- Oct 08 13:48:33 imx6/sources/poky/build/tmp/sysroots/q7_imx6 " which is the correct path. Anyone has an idea what the problem might be? Oct 08 14:11:32 rburton: let's say I have 'xdotool_1.20100416.2809'. Do I do EXCLUDE_FROM_WORLD_pn-xdotool_1.20100416.2809 or EXCLUDE_FROM_WORLD_pn-xdotool ? Oct 08 14:12:09 Krz-: pn-xdotool Oct 08 14:12:19 since PN is "xdotool" for that recipe Oct 08 14:13:31 bluelightning: what does actually pn mean? Oct 08 14:14:36 Krz-: in the old days it meant "package name" when we used to use the same term "package" for the recipe and the output package Oct 08 14:16:22 bluelightning: nowadays would "Recipe Name" fit better? Oct 08 14:16:38 panda84kde: that is the current meaning yes Oct 08 14:16:55 somewhat of a API break to rename the variable now though :) Oct 08 14:17:55 bluelightning: ok I have the list "EXCLUDE_FROM_WORLD_pn-package_name = "1" Oct 08 14:18:03 bluelightning: nice VIM excercise, really valuable experience :) Oct 08 14:18:10 bluelightning: what do I do with the list now? Oct 08 14:20:24 Krz-: if you put that in an inc file in conf/distro/include and then "require" that from your distro config Oct 08 14:20:30 that would be the recommended approach Oct 08 14:23:05 nice, the list is way smaller right now, "libxpm was skipped: 'x11' not in DISTRO_FEATURES" Oct 08 14:23:22 is that the tricky thing with packagegroup now? Oct 08 14:23:50 vlc and xterm recipes want libxpm Oct 08 14:24:54 so your list needs to include libxpm, vlc and xterm Oct 08 14:25:14 unless they're already on the list, in which case there's a packagegroup pulling them in. Oct 08 14:40:37 I'm trying to add nativesdk-python-compile to my sdk Oct 08 14:40:45 I'm using TOOLCHAIN_TARGET_TASK_append = " nativesdk-python-compile" Oct 08 14:40:49 in my distro conf Oct 08 14:41:22 but opkg is complaining Unknown package 'nativesdk-python-compile'. Oct 08 14:41:38 however, I can do bitbake nativesdk-python-compile, with no problems Oct 08 14:43:44 the package is available in /home/jack/Work/oe-core.git/test-build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-python/2.7.3-r0.3/deploy-ipks/x86_64-nativesdk Oct 08 14:44:13 does anyone have a clue where this could be going wrong? Oct 08 14:47:28 jackmitchell: I think you want TOOLCHAIN_HOST_TASK_append not TOOLCHAIN_TARGET_TASK_append Oct 08 14:47:51 since nativesdk-* would be the host part of the SDK Oct 08 14:48:29 bluelightning: well spotted! I thought I was using HOST_TASK, I must have miss-copied Oct 08 14:59:03 The Yocto Project Tech Meeting Con-Call is starting Oct 08 14:59:03 Dial-in number: 1.972.995.7777 / Participant passcode: 42001078 Oct 08 14:59:03 This call is open to all and the channel remains open to discuss any topic. Oct 08 14:59:18 YPTM: Saul is on and will be leading today. Oct 08 14:59:32 YPTM: Björn is on the call Oct 08 15:00:36 YPTM: Paul Eggleton joined Oct 08 15:00:38 YPTM: Bruce Ashfield is on the call. Oct 08 15:00:40 * rburton finally got off hold to the doctors and will dial shortly Oct 08 15:00:50 YPTM: Tom Z on Oct 08 15:01:46 YPTM: Scott Rifenbark joined Oct 08 15:02:00 YPTM: Michael here. Oct 08 15:02:05 YPTM: ross on Oct 08 15:02:07 YPTM: nitin is on the call Oct 08 15:02:17 YPTM: beth joining in a moment Oct 08 15:02:41 YPTM: Richard is on the call Oct 08 15:04:14 YPTM: polk is on Oct 08 15:04:25 Zagor: much appreciated if you could try my gnome-desktop-testing/glib upgrade and verify that the ptest stuff still actually works! Oct 08 15:04:46 Zagor: if i run run-ptest it runs the test suite, but i'm not positive the output is as expected. Oct 08 15:05:26 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status Oct 08 15:05:27 rburton: could you post a paste? I'm swamped at work for the moment. Oct 08 15:06:04 YPTM: AlexG on the call Oct 08 15:07:01 YPTM: jzhang on the call Oct 08 15:08:20 Zagor: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/upgrades, you'll need gnome-desktop-testing and glib-2.0. Oct 08 15:09:45 RP: I have some pushes to yocto-docs/master that should go to poky Oct 08 15:09:57 rburton: right, I meant a paste of the output so I can take a quick look at the output. I won't have time to try a full gnome build for a while, I'm afraid. Oct 08 15:10:06 scottrif: thanks Oct 08 15:10:19 Zagor: ah, sure. Oct 08 15:12:21 sgw_: it's "edin-bruhh" :) Oct 08 15:13:03 Any volunteers? Oct 08 15:14:08 I'm not volunteering for anything Oct 08 15:14:13 Just to be clear RP is asking for 1.5 Stable Maintainer Volunteer! Oct 08 15:14:32 Crofton|work: well volunteered :) Oct 08 15:14:47 I am over volunteered Oct 08 15:17:05 YPTM: Denys just joined, sorry I'm late Oct 08 15:17:37 Bug #5133 Oct 08 15:17:38 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5133 normal, Medium+, 1.5 M5, laurentiu.palcu, ACCEPTED , [Test Case 207] sudoku-savant project compile in sdk image Oct 08 15:21:17 halstead: great work, thanks! :) Oct 08 15:21:29 Thank you RP. Oct 08 15:24:05 sgw_: poky-contrib paule/dylan-next Oct 08 15:29:52 Zagor: http://pastebin.com/Ed6aA5jt Oct 08 15:30:01 Zagor: 3 fails, wish it was easier to find them! Oct 08 15:30:46 ah, grep "failed" Oct 08 15:34:55 rburton: that looks pretty good Oct 08 15:35:50 one point for discussion might be why there are two result formats: "test: OK" and "PASS: testsuite" Oct 08 15:36:53 in earlier such cases we have chosen to reformat the fine-grained results to also show PASS/FAIL so we can parse and count them individually Oct 08 15:37:11 pidge: build should be good to go Oct 08 15:37:25 Zagor: colin walters was excited when i said i'd just enabled installed-tests in our ptest stuff and is very willing to hear our feedback. Oct 08 15:37:31 Zagor: i said i'm sure you'll get in touch at some point Oct 08 15:38:59 :) Oct 08 15:39:44 where did you talk to him? gnome mailing list? Oct 08 15:41:48 Zagor: that was just a private mail Oct 08 15:41:59 ok Oct 08 15:50:57 rburton: I have this error now: ERROR: Required build target 'packagegroup-self-hosted' has no buildable providers. Oct 08 15:50:57 Missing or unbuildable dependency chain was: ['packagegroup-self-hosted', 'eglibc-utils'] Oct 08 15:51:25 rburton: I'm using uclibc image and everything else I belive right now is on my 'exclude_from_world.inc' list Oct 08 15:54:14 Krz-: just adding that packagegroup to the exclude-from-world list should solve that Oct 08 15:54:25 *should* Oct 08 16:24:11 RP: ok, tagging and bagging Oct 08 16:38:12 Is it possible to explicitly add dependency on some native task in target recipe without using my own SignatureGenerator ? Oct 08 16:38:33 DEPENDS += "myapp-native" Oct 08 16:38:34 RP: ^ you'll probably know Oct 08 16:38:44 fray: that's now what I'm asking Oct 08 16:39:20 fray: OEBasic and OEBasicHash generators aren't crossing cross/native boundary Oct 08 16:39:30 moin Oct 08 16:39:46 fray: in this case I need exception to include hash of native task in target task signature Oct 08 16:41:45 JaMa: you'd have to customise it Oct 08 16:42:11 ok, thanks Oct 08 16:42:27 JaMa: we should probably make it configurable Oct 08 16:43:03 yeah I was thinking about adding new SIGGEN_* variable Oct 08 16:44:07 but for now I'll probably convert that native component to target one (it will be easier for me in dylan build, than adding new SignatureGenerator now) Oct 08 16:46:25 JaMa: fair enough on both. The native/target split was rather arbitrary, its just worked well enough for now... Oct 08 17:26:38 JaMa: if I understand what you're talking about correctly, I ran into the same problem and have a patch I've been using locally Oct 08 17:28:29 evanp: can you share that patch? Oct 08 17:29:06 at least to confirm that you have solution for master (I've already fixed it in our build by changing the component from native to allarch) Oct 08 17:33:56 JaMa: it doesn't cherry-pick cleanly onto master, but the conflicts look familiar. I'm pretty sure I looked at master before and wasn't worried about the forward-port. Oct 08 17:36:00 mr_science: morning Oct 08 17:36:09 mr_science: btw, would you be able to send that patch for the nginx addition in meta-webserver? Oct 08 17:38:14 JaMa: give me a day or two and I'll port it, get the corporate paperwork in order, and submit it to the list Oct 08 17:38:50 evanp: ok, thanks Oct 08 17:42:33 bluelightning: sure, but i need to extract it from my meta-rpi layer Oct 08 17:43:13 mr_science: that would be awesome if you have time Oct 08 17:43:31 where do you want it? Oct 08 17:47:51 mr_science: ideally it should be sent as a patch to add to the meta-openembedded repository under the meta-webserver directory and marked with [meta-webserver] in the subject line Oct 08 17:51:20 bluelightning: "sent" meaning to the mailing list? Oct 08 17:51:26 yes Oct 08 17:51:32 or can i add it to a bug? Oct 08 17:51:38 http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded in case you haven't seen it Oct 08 17:51:56 seen, but not done it yet... Oct 08 17:57:59 bbl Oct 08 18:01:16 okay, should do this from home with a non-work email, etc Oct 08 18:50:51 Long ago, I got to asking about the ar and strings symlinks in binutils. In our local tree, we eventually migrated to moving all the binutils things into update-alternatives, even the ones for which there might not be any competing packages, because this provided consistent behavior and let people use the short names without having to install the extra binutils-symlinks package. Oct 08 18:51:19 Does anyone have any objections to a change like that to the binutils recipe? I think the resulting recipe is nicer and has fewer odd special cases. Oct 08 18:51:30 (I believe the reason those two ended up as special cases is that busybox has implementations.) Oct 08 20:02:39 Given the overwhelming outcry from the very many people who apparently have a significant investment in the state of binutils and whether it's using symlinks or alternatives, I'm testing out the change and will submit it at some point, possibly later today if testing goes well. Oct 08 21:09:01 JaMa: hey Martin.. I don't know if you noticed but this commit in meta-oe is unnecessary: 13f540c5a98d3a64b41117db9cf554956eebafe9 Oct 08 21:09:15 do you want me to send a revert patch to it? Oct 08 21:13:49 ftonello: no, sorry I haven't noticed, the queue with patches was quite long (after so long build) so it's possible that I've overlooked it Oct 08 21:13:54 yes please send revert Oct 08 21:15:39 ftonello: now I see your own reply on the patch, sorry that I've missed that Oct 08 21:22:01 JaMa: ok :) Oct 08 22:43:52 sometimes i think a LAYERRECOMMENDS would be useful Oct 08 23:08:35 hmm is there any target is using EFI stub? Oct 08 23:21:20 khem: ping Oct 08 23:31:08 Qemu is having problems with the size of my generated ramdisk, has anyone seen this problem? **** ENDING LOGGING AT Wed Oct 09 02:59:58 2013