**** BEGIN LOGGING AT Mon Jul 07 02:59:59 2014 Jul 07 09:55:28 RP, have you seen rtollert_ gcc/mingw patches? Jul 07 09:57:31 Crofton|work: yes Jul 07 09:57:40 thanks Jul 07 09:57:50 just want to make sure they do not get missed Jul 07 10:00:28 * Crofton|work continues updating git hashes for his daisy build Jul 07 10:03:43 RP: pls give a look at the last change to kernel.bbclass Jul 07 10:10:41 ant_work: the symlink one? Jul 07 10:10:51 yes Jul 07 10:11:00 ant_work: what about it? Jul 07 10:11:16 is it ok to have an absolute path there? Jul 07 10:11:36 ant_work: no :( Jul 07 10:11:37 many boot scripts will mount the partition before kexecing Jul 07 10:11:48 hmm, well Jul 07 10:11:54 dunno dracut Jul 07 10:12:27 ant_work: I think it does look ok Jul 07 10:12:29 I think we should mimic debianutils - make install Jul 07 10:12:55 ant_work: "make install" of what? Jul 07 10:12:58 of kernel Jul 07 10:13:10 ant_work: "make" in which source tree? Jul 07 10:13:37 well, see, i.e. on Gentoo it produces a relative symlink Jul 07 10:13:43 afaik on arch as well Jul 07 10:14:33 ant_work: can you reply to the patch on the list and lets discuss this? Jul 07 10:14:45 ant_work: it may be we need to fix chkconfig Jul 07 10:15:28 RP: if kexecboot is the only victim we will adapt it, no matter Jul 07 10:15:42 just wondering about the rest of the bootmanagers Jul 07 10:15:49 ant_work: I've not had any other complains Jul 07 10:15:54 complaints Jul 07 10:16:58 I remember similar issues long ago with lilo and the iterative symlink to /boot if that was on another partition Jul 07 10:18:33 RP: I've already sent my complaint to the ML ;) Jul 07 10:19:10 let's ask Bruce as well Jul 07 11:14:08 for python scripts which are arch-independent, how do i tell OE i want to deploy it as a host tool rather than a script on my embedded device? Jul 07 11:40:48 anyone keen to help me with a complex git question? Jul 07 11:41:26 basically I have 2 branches lets call them prod & dev Jul 07 11:41:52 I merge dev into prod every now and again... makes sense Jul 07 11:42:24 by mistake I made a commit to prod, which I then converted into a patch that I sent to dev... so far so good. Jul 07 11:42:42 The problem however is that the patch won't push to origin Jul 07 11:43:11 the dev branch does not notice that it has a different HEAD~rev than origin Jul 07 11:43:34 the patch was applied with qq Jul 07 11:44:08 git apply --stat foo.patch Jul 07 11:44:36 what am I doing wrong Jul 07 12:53:55 i'm trying to "build" a python module for host. So I've added 'BBCLASSEXTEND = "native"' to my recipe. I've also added it to all other python modules that my module depends on. Seems to work! However, one module depends on python-fcntl, which is provided by the python-package itself (as a package split). Why will not a python-fcntl-native be built, when clearly python-native is being built? Jul 07 13:02:52 howdy good people Jul 07 13:05:11 some time ago I submitted a patch to meta-openembedded to fix a recipy that stopped working because the source tarball was deleted by the site... https://github.com/openembedded/meta-openembedded/blob/daisy/meta-oe/recipes-support/usb-modeswitch/usb-modeswitch_2.0.1.bb Jul 07 13:05:21 that should be usb-modeswitch_2.2.0.bb Jul 07 13:05:37 how long does it normally take to get such an easy fix in? Jul 07 13:08:15 pompomJuice: I don't see such change on http://patchwork.openembedded.org/project/oe/list/?state=*&q=usb-modeswitch&archive=both please resend Jul 07 13:08:48 I must have noobed the patch submition as it seems to be more complicated that a one button Jul 07 13:09:13 I haven't found it in my maildir as well, so it's posible that it never reached ML :) Jul 07 13:09:13 I ran those scripts that sends mails via gmail etc Jul 07 13:09:22 highly likely Jul 07 13:09:26 but cant you just fix it Jul 07 13:09:33 very easy Jul 07 13:09:38 just rename the file Jul 07 13:09:41 no Jul 07 13:09:50 well, it is n update not only a fix Jul 07 13:09:52 donno why nobody else has not had this problem Jul 07 13:09:59 pompomJuice: premirrors Jul 07 13:10:09 what is that? Jul 07 13:10:10 pompomJuice: you also need to update checksums and test it on device Jul 07 13:10:12 we need that Jul 07 13:10:13 here Jul 07 13:10:32 since the other day some dude's aircon broke and i was unable to build Jul 07 13:10:45 what is this premirror you speak of? Jul 07 13:11:03 and the policy says no upgrades in release branch Jul 07 13:11:13 well Jul 07 13:11:22 so if you need to fix it in daisy then you really need to fix it on your site not in metadata Jul 07 13:11:26 if you try to fresh build daisy now it will not work Jul 07 13:11:33 read own-mirror.bbclass Jul 07 13:11:35 pompomJuice: did the tarball really disappear from the web? Jul 07 13:11:41 yes Jul 07 13:11:41 unlikely Jul 07 13:11:45 ;) Jul 07 13:11:51 from SRC_URI maybe Jul 07 13:11:52 the noobed it up Jul 07 13:11:57 they* Jul 07 13:12:19 let me demonstrate Jul 07 13:12:31 pompomJuice: and you can ask Tom nicely to put it on sources.oe.org, here is example: http://lists.openembedded.org/pipermail/openembedded-devel/2014-July/096636.html Jul 07 13:12:49 http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-${PV}.tar.bz2 Jul 07 13:13:04 http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-2.0.1.tar.bz2 ----> 404 Jul 07 13:13:15 http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-2.2.0.tar.bz2 -----> yebo yes Jul 07 13:15:09 http://hastebin.com/leqimutina.vhdl Jul 07 13:16:49 see the first google match Jul 07 13:16:51 http://pkgs.fedoraproject.org/repo/pkgs/usb_modeswitch/usb-modeswitch-2.0.1.tar.bz2/ Jul 07 13:17:08 http://hastebin.com/cijetubabu.coffee Jul 07 13:17:42 yea Jul 07 13:17:48 I could hack it to work Jul 07 13:17:58 but the idea is to fix it upstream? Jul 07 13:18:10 ok, for stable the fix is having that sources in the *mirrors Jul 07 13:18:31 for master, pls register and resend the patch as 'upgrade' Jul 07 13:18:38 in the mean time I made a fork here -> https://github.com/pompomJuice/meta-openembedded/tree/pompomJuice-daisy Jul 07 13:19:08 btw if you don't remove your download folder you can manually d/l it Jul 07 13:19:18 yea I know Jul 07 13:19:27 hack the thing into source/downloads Jul 07 13:19:36 ok, that's the first band-aid ;) Jul 07 13:19:53 hehe that causes problems for me when teamcity decides to wipe the folder Jul 07 13:20:09 my damn build folder just got nuked again Jul 07 13:20:11 you can have local premirrors Jul 07 13:20:15 yes Jul 07 13:20:19 please give me an url Jul 07 13:20:31 that explains this,my boss wants this Jul 07 13:20:52 he does not want us to depend on somde dude's aircon cooling some server in timbaktoe Jul 07 13:21:38 http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#ref-classes-own-mirrors Jul 07 13:22:58 thanks Jul 07 13:23:32 that looks like a lot of work Jul 07 13:23:46 why? Jul 07 13:23:56 just mv your download dir Jul 07 13:24:06 on some internbal server Jul 07 13:24:14 after having done your build Jul 07 13:24:42 aah ok Jul 07 13:25:04 that seems like less of a hack that I can live with Jul 07 13:25:05 but Jul 07 13:25:13 maybe one day you loose that folder Jul 07 13:25:16 all hell breaks loose Jul 07 13:25:30 I like to clean everything every month or 3 to be sure Jul 07 13:25:47 but I get the idea Jul 07 13:25:50 these cases are very rare nowadays Jul 07 13:25:56 ok Jul 07 13:26:03 if you guys think it as acceptable, Jul 07 13:26:10 I am happy Jul 07 13:26:25 I build oe-core only but think that poky has maybe some mirrors preset Jul 07 13:26:26 I just want to find out what is the best way to handle this issue Jul 07 13:26:38 symlinking the dl folder is definitely easy if this is acceptable Jul 07 13:27:39 #DL_DIR ?= "${TOPDIR}/downloads" Jul 07 13:28:08 By default, the directory is downloads in the Build Directory. (from manual) Jul 07 13:28:30 yea Jul 07 13:28:33 with the time, this increases size Jul 07 13:28:42 not if you stay on stable releases Jul 07 13:28:51 just tracking master Jul 07 13:29:24 like i.e. with your patch, one more tarball will add ;) Jul 07 13:29:58 what I did was fork the repo and make the fix and wait for upstream to accept my patch, then I can just switch back to upstream no problems Jul 07 13:30:35 you could just have added that recipe in your layer... Jul 07 13:31:07 yea Jul 07 13:31:36 mmm Jul 07 13:31:53 that would have worked Jul 07 13:32:10 but then you don't get my patch and the bug sits there for someone else to encounter Jul 07 13:32:28 trying to contribute but clearly that is not wanted Jul 07 13:32:53 and this has to be the simplest fix bitbake can have Jul 07 13:32:59 if it is this difficult to get it in Jul 07 13:32:59 I *think* the autobuilders are using some Yocto mirror Jul 07 13:33:01 then I wonder Jul 07 13:34:30 http://downloads.yoctoproject.org/mirror/sources/ Jul 07 13:34:33 I just wanted to see how the process worked, chose the most basic fix to see if I could contribute... it should really not be this hard Jul 07 13:35:26 actually we never received th epatch :/ Jul 07 13:35:33 uuhm, remember I have ~8 months XP with OE... im still a noob Jul 07 13:35:48 yea I followed all the instructions on how to submit one Jul 07 13:35:53 I have gmail smtp Jul 07 13:35:56 I ran the scripts Jul 07 13:36:04 I received a mail saying awaiting moderator Jul 07 13:36:08 clearly Jul 07 13:36:09 you have git, pls use git send-email Jul 07 13:36:14 I did Jul 07 13:36:16 that is what I did Jul 07 13:36:28 but using the automagic script Jul 07 13:36:44 which Gmail scripts are you talking about? Jul 07 13:37:00 let me find it Jul 07 13:38:06 trying to find the web page that had the procedure... Jul 07 13:38:41 http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Jul 07 13:39:13 Run scripts/create-pull-request -u remote-name (where remote-name is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add -p "layername][PATCH" replacing layername with the name of the layer so that it is clear which layer the patches are intended for. Jul 07 13:39:24 that automagic script Jul 07 13:41:01 "lternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from" Jul 07 13:41:09 that is the one I chose Jul 07 13:42:26 I se Jul 07 13:42:44 important is the prefix Jul 07 13:43:28 so we see [meta-oe][PATCH] Jul 07 13:43:44 if it is for stable, you have to specify that as well Jul 07 13:46:05 note that as general rule a patch *must* appear in master before being backported to stable (Daisy today) Jul 07 13:52:02 gm Jul 07 13:54:32 anyone aware of existing work / a layer for MIPS / AR9331 / Carambola 2 into OE? Jul 07 13:57:59 ok Jul 07 13:58:11 please give me an example Jul 07 13:58:15 what should it have been? Jul 07 13:58:18 aah Jul 07 13:58:23 so the patch must apply to master Jul 07 13:58:24 not daisy Jul 07 13:58:28 I see Jul 07 13:58:30 dang Jul 07 13:58:36 someone else takes it from master into dauisy Jul 07 13:58:41 I get it Jul 07 14:01:35 For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add -p "layername][PATCH" replacing layername with the name of the layer so that it is clear which layer the patches are intended for. Jul 07 14:01:55 no mention about stable or anything...? Jul 07 14:02:04 that someone is usually JaMa who answered you one hours ago ;) Jul 07 14:02:24 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/README Jul 07 14:03:59 ok thanks Jul 07 14:04:05 I will do that next time Jul 07 14:04:44 try smthg like that Jul 07 14:04:45 http://patches.openembedded.org/patch/73807/ Jul 07 14:11:06 ok thanks... let me see Jul 07 14:12:00 yw Jul 07 14:28:46 pompomJuice: if your e-mail to oe-devel ML still waits for moderator approval, then you probably haven't sent it from the e-mail you've subscribed to oe-devel ML Jul 07 14:29:12 yea Jul 07 14:29:23 I don't think I subscribed at all Jul 07 14:29:25 pompomJuice: such change is welcome to master, for daisy you need to ask Tom to put it on sources.oe.org (which is enabled by default) Jul 07 14:29:26 noob alert Jul 07 14:29:44 :D Jul 07 14:29:59 I do feel though that this should be a one button Jul 07 14:30:02 seriously Jul 07 14:30:06 are computers that dumb? Jul 07 14:30:23 why cant I just press a button and it works Jul 07 14:30:51 here is my git, there is the REV and poof it works Jul 07 14:31:59 ant_work: I'm not maintainer of daisy :) Jul 07 14:34:00 ynezz: ping Jul 07 14:36:07 JaMa, I'll update the commit message to my libxml2 solution and re-submit Jul 07 14:41:26 Crofton: ok Jul 07 14:45:32 I never heard from the original author Jul 07 14:51:39 I have a recipe with a do_install that destroys the S dir Jul 07 14:51:57 so if the recipe has do_install run, without unpack, it fails Jul 07 14:52:27 apart from rewrting do_install, is there a way to force the bitbake to always unpack? Jul 07 14:57:02 Here is the offending recipe Jul 07 14:57:04 https://github.com/balister/meta-sdr/blob/master/recipes-support/uhd/uhd-firmware_003.007.001.bb#L18 Jul 07 14:58:19 does it really need to destroy S? Jul 07 15:00:45 I had troubleusing install Jul 07 15:00:58 the wildcard picks up th esubdir names Jul 07 15:01:18 I was tryin gto avoid listing all the files by hand :) Jul 07 18:52:08 how can I force bitbake to reun a do_install task? Jul 07 19:27:55 Crofton|work: -C install will taint it so bitbake knows to re-run it Jul 07 19:58:22 Herro. Got a question for anyone: Anyone seen oddball file ownerships when building with massive multithreading? -- some of our files in images are coming out as owned by, for example, xuser Jul 07 19:58:46 Where, in this case, they _should_ be root. Just trying to hunt down where this comes from. Jul 07 20:18:51 Oh look, other image, and it has the right user and wrong group! .. Jul 07 20:18:58 (dora btw) Jul 07 20:20:13 Crofton|work: -f Jul 07 20:22:31 WarheadsSE: i've seen some cases of that. most often its a case of files being owned by the user you're building as, but the passwd from the target not matching the host, so its misidnetified as xuser Jul 07 20:22:38 not sure as to the root cause Jul 07 20:34:28 There are many varied discussions of variations of this happening where Andreas is in teh discussion, across the last ~ 5 years Jul 07 20:34:45 its really wierd because I get different things from box to box. Jul 07 20:35:08 same file, wrong:right, right:wrong, wrong:wrong Jul 07 20:35:17 like, how the hell did you mess up root:root Jul 07 20:52:29 JaMa, doesn't feel like that is working for some reason Jul 07 21:00:21 kergoth: of note: in this case, a recipe that is affects is using mv for the adffected files Jul 07 21:00:39 (I know, brilliant) .. the files in the package that are done via install ... are correct. Jul 07 21:01:31 it's running under pseudo, so it shouldn't even know what your uid is, it should think it's running as root Jul 07 21:01:45 yeah Jul 07 21:01:56 just going to try moving these all to install and see how that goes.. Jul 07 21:02:08 this is in a do_install_append_x86 Jul 07 21:08:15 anarsoul, no luck with calibration Jul 07 21:20:01 kergoth, I need to make do_install for a recipe run , even if it thinks it already ran Jul 07 21:20:17 bitbake -c install -f uhd-firmware Jul 07 21:20:23 doesn't do it Jul 07 21:21:26 Crofton|work: that's not what i said Jul 07 21:21:37 but taht will run do_install Jul 07 21:21:47 but using -C will tell it to re-run do_install and everything after it Jul 07 21:21:53 bitbake -C install uhd-firmware Jul 07 21:22:03 ah I see what you said now Jul 07 21:22:11 only saw JaMa s while I was afk Jul 07 21:22:12 thanks Jul 07 21:24:12 grr Jul 07 21:26:01 I completely fail at getting tasks to run again Jul 07 21:26:14 bitbake is too smart@ Jul 07 21:26:58 kergoth: well, that worked.. Jul 07 21:32:59 I need to bug belen about making it easy to see the last tasaks in toaster **** ENDING LOGGING AT Tue Jul 08 02:59:58 2014