**** BEGIN LOGGING AT Tue Jan 14 03:00:00 2014 Jan 14 09:49:25 morning all Jan 14 10:17:22 RP: what is up with the git am patch ? Jan 14 10:17:31 go / no go? Jan 14 14:33:39 guys, I use git send-email to submit patches. They are always submitted to master - that's my understanding at least. How do I submit a patch for branch? Is it just about checking out a branch and then using git send-email like previously? Jan 14 14:34:08 man git-send-email doesn't mention branches at all Jan 14 14:34:13 Xz: ? Jan 14 14:34:21 Xz: it is branch-agnostic how you supply it. Jan 14 14:34:28 submit* Jan 14 14:34:59 lpapp: so assuming I want to send a patch to poky/dylan I just checkout openembedded-core/dylan, prepare a patch and git send-email? Jan 14 14:35:03 Xz: just add e.g. [dora] to subject Jan 14 14:35:37 and better to explicitly Cc maintainer of given release Jan 14 14:35:48 JaMa: so that's the trick... it means I can in theory send a patch from master repo to dylan branch, can I? Jan 14 14:36:26 Xz: you should not. Jan 14 14:36:35 in theory yes, but don't do that, prepare the patch in right branch and test it there before sending it Jan 14 14:36:37 Xz: you should test a change against the branch before submitting. Jan 14 14:36:58 lpapp: yes, of course, just trying to understand correctly how it works Jan 14 14:36:58 no "Signed-off: Trust me" :-) Jan 14 14:37:15 Xz: also each patch for release branch needs to be first merged in master Jan 14 14:37:31 lpapp: JaMa that's actually a weak point of git Jan 14 14:37:57 Xz: --subject-prefix="dora" Jan 14 14:38:10 Xz: no, it is a strong point Jan 14 14:38:15 you can cherry pick easily between branches. :) Jan 14 14:38:34 lpapp: well, you can submit patch to wrong branch easily Jan 14 14:38:47 lpapp: assuming you used git send-email command line from bash history for example Jan 14 14:38:50 you do not submit a patch against branches Jan 14 14:38:53 you only use a prefix. Jan 14 14:39:26 lpapp: how don't you submit a patch against a branch? I think you do Jan 14 14:39:44 well, it is very simple: Jan 14 14:39:46 --subject-prefix=oe-core][dora][PATCH (i.e. don't remove PATCH from subject Jan 14 14:39:49 1) You are in your branch Jan 14 14:39:50 lpapp: well, at least you prepare a patch against given branch Jan 14 14:40:03 2) You modify Jan 14 14:40:08 3) You test Jan 14 14:40:10 4) You commit Jan 14 14:40:17 Xz: you can also use create-pull-request/send-pull-requests scripts from oe-core Jan 14 14:40:22 5) Generate the change or just send. Jan 14 14:40:27 Xz: those will force you to specify branch Jan 14 14:40:28 what is so difficult? Jan 14 14:41:04 lpapp: if you switch between branches often I just believe you might commit a mistake on day by using 'git send-email' with wrong --subject-prefix Jan 14 14:41:14 lpapp: and by mistake send a patch to wrong branch Jan 14 14:41:28 Xz: why would you switch between branches often? Jan 14 14:41:43 and why would you not catch that when sending a test to your address first? Jan 14 14:41:54 or even before actually sending? Jan 14 14:42:01 I always review my own change before submitting, of course. Jan 14 14:42:23 but I still do not buy the "change branches often" argument. :) That is not a typical activity IMHO. Jan 14 14:42:52 and when you finish the work, you are in the right branch anyway, you will not change a branch between getting the work done and submitting. Jan 14 14:43:30 hello Jan 14 14:43:41 ERROR: QA Issue: ettercap: /work/armv7a-vfp-neon-poky-linux-gnueabi/ettercap/0.8.0-r0/packages-split/ettercap/usr/bin/ettercap contains probably-redundant RPATH /usr/lib Jan 14 14:43:41 lpapp: well, I have right now a layer written for dylan. In order to bump it to dora my development will include switching branches Jan 14 14:43:46 how do i fix that ? Jan 14 14:43:59 lpapp: + if you submit something for master - why wouldn't you switch back and send it to dylan as well? Jan 14 14:44:30 I do not understand Jan 14 14:44:47 you develop something, you test it, and you are done after the bufixes Jan 14 14:44:49 bugfixes Jan 14 14:44:55 you _are_ in the right branch afterwards Jan 14 14:45:02 gagi: I tried out your qt5 branch and it worked great. Do you know what changes of yours are going to be merged into mainline? For starters it would be nice to move the mkspecs into the dev package. Jan 14 14:45:02 lpapp: I just like the idea of git saying me 'hi, you are trying to submit a patch prepared on master branch to different branch' Jan 14 14:45:15 then you submit, change branch, then you finish the development in the other branch, you test, you bugfix, you submit. Jan 14 14:45:42 in fact, if I were you I would forget about branches Jan 14 14:45:46 it is somewhat red herring. Jan 14 14:45:53 you always finish the work in the right branch Jan 14 14:46:00 what you need to be concerned about is the release IMHO Jan 14 14:47:27 Xz: also, i would not recommend switch branches for an OE layer in the same environment. going back and forth between 2 OE branches/releases will mess up your Jan 14 14:47:37 regarding the version of packages, at the very least. Jan 14 14:48:08 ndec: that's not a big problem, I usually wipe out everything and have it built in a bit more than 30min - coffee break Jan 14 14:48:33 but you have just said you would do it frequently. Jan 14 14:48:34 ok.. Jan 14 14:48:45 you like the coffee break for 30+ minutes frequently? I cannot follow I am afraid. :) Jan 14 14:49:10 coffee lover ;-) Jan 14 14:49:38 lpapp: ndec: :) it's just I'm pretty new to submitting patches to Yocto and there are plenty of little things to remember Jan 14 14:49:59 lpapp: ndec: this is just another one and there is no auto mechanism to correct me or at least tell that I do something wrong Jan 14 14:50:07 Xz: first thing to remember, do not change branches frequently. Jan 14 14:50:13 i agree. generally you will find 'how to submit patch' info in each README file in each layer. Jan 14 14:50:36 lpapp: ok then, so what would you recommend me to do if I have a layer and a board working on dylan? Jan 14 14:50:48 lpapp: submit patches only to dylan? you just said, that patch must be first applied on master Jan 14 14:50:50 automated mechanism for what? Jan 14 14:51:02 git branch getting automatically into the prefix? Jan 14 14:51:13 would not be hard to write a script for that if it was a big issue. Jan 14 14:51:15 lpapp: someone mentioned that pull-request does that thing (does not let apply patch on wrong branch) Jan 14 14:51:30 but since you do not change branches frequently, it would not automate that much. Jan 14 14:52:23 lpapp: I have dylan setup - I can test my stuff on dylan. Should I then just submit patches to dylan and not give a shit about master? Jan 14 14:52:59 Xz: as mentioned before patches must be backported to stable release, so master first. Jan 14 14:53:34 (if applicable) Jan 14 14:53:42 you do need ability to switch branches, for sure. not sure why lpapp insists so hard on that. just be cautious about commit and git send email, and everything will be ok. Jan 14 14:54:08 ndec: changing branch once during _developments_ is not frequent Jan 14 14:54:20 it is not like you do that frequently, especially as a newcomer. Jan 14 14:54:28 not sure why you insist so hard on that. :) Jan 14 14:54:41 and even if you switch branches, you would need to test the change in the other branch anyway. Jan 14 14:54:50 so I cannot buy the argument of branch confusion I am afraid. Jan 14 14:54:51 lpapp: well, you went as far as saying that he should forget about branches... using git without branches is quite a sad thing.. Jan 14 14:55:11 ndec: for the _submitting_ Jan 14 14:55:21 ndec: do not put words into my mouth. :) Jan 14 14:55:34 I actually even said you change branches between _developments_ (not submittings) Jan 14 14:55:36 anyways, i think we agree more or less, no need to waste too much energy. let's keep our energy for when we disagree ;-) Jan 14 14:55:38 gjohnson: nice to hear, at the moment none of them, last time i tried to merge my changes into mainline they got rejected because denis didn't see a need to patch the mkspecs folder and he said he will come up with it's own version soon Jan 14 14:56:02 I really cannot get why one would change branches frequently and how that would cause any confusion. Jan 14 14:56:34 the only thing that could be improved - as I mentioned - writing a short script to get the git branch output and put that into the prefix, but since it is not frequent, I am not sure it is worth the effort. Jan 14 14:57:16 that's what scripts/create-pull-request is for. Jan 14 14:57:30 is the --subject-prefix used by everybody on the world to specify branch name? or that's just Yocto? Jan 14 14:57:54 each community/project makes up its own rules. Jan 14 14:58:26 some use different mailing list for each release, some use 1 mailing list and rely on prefix (like OE) Jan 14 14:58:34 Xz: well, normally, you do not need to, like in the linux kernel. Jan 14 14:58:43 IMHO, it is a complication, but for branches it may be useful, yes... Jan 14 14:59:42 ndec: different mailing list for each release, really? Jan 14 14:59:49 can you provide some projects like that Jan 14 14:59:58 lpapp: do you know the magic to get the "parent" ref for a feature branch then? i've been trying to work that out for a while. Jan 14 15:00:56 ie what branch on origin is this local branch an ancestor of Jan 14 15:01:10 rburton: no idea... it was not possible a few years ago. Jan 14 15:01:22 have not checked this feature for years cause I have not needed it, I am afraid. Jan 14 15:01:30 so putting the "branch name" automatically into the subject isn't a good idea then Jan 14 15:01:32 it may be that there already are contrib scripts for it. Jan 14 15:01:44 rburton: why? Jan 14 15:02:17 gagi: I hope the plans denis has work as well as yours. I liked not having to modify the environment to setup qt creator. Jan 14 15:02:20 lpapp: because why would putting the name of my feature branch in the subject be useful? Jan 14 15:02:34 lpapp: linux stable mailing list, maybe? Jan 14 15:02:44 ndec: that is far from "each release". :) Jan 14 15:02:58 rburton: well, it works fine if you just work into the release branch directly. Jan 14 15:02:59 rburton: that's good question :) Jan 14 15:03:18 (like many had done, including me) Jan 14 15:04:01 lpapp: i'd expect the majority of people doing heavy development work in feature branches Jan 14 15:04:24 Xz: git *can* do it, i just haven't figured out the right incantation yet :/ Jan 14 15:05:03 rburton: I do not think so.... Jan 14 15:05:11 people usually send minor patches as far as I can see... Jan 14 15:05:26 and as for that, a separate feature branch might be an overkill. Jan 14 15:05:36 but iirc lately git enforces it anyway, so it is kinda moot. Jan 14 15:06:12 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/refs/heads indicates that feature branches are popular. anyway, for backports explicitly putting the release name isn't a massive hardship. Jan 14 15:06:18 rburton: I developer major features into the linux kernel in the stable branch Jan 14 15:06:23 from where I also submit. Jan 14 15:06:51 develop* Jan 14 15:07:26 well, of course, git enforces the feature branch these days, but for me, there is no real difference. Jan 14 15:07:40 it would make a different if many did the same, but that is not the case here. Jan 14 15:08:03 and since git is distributed, I do not even need to push after each atomic change. Jan 14 15:08:33 anyway, we are getting off-topic IMHO towards git. :) Jan 14 15:12:43 lpapp: so getting back to my question - I have layer dylan-based and board to test my changes. What do I do? Jan 14 15:12:46 lpapp: :) Jan 14 15:13:56 lpapp: there are quite few recipes that didn't change at all since dylan, so testing them on dylan and submitting a patch to master sounds reasonably, does that? Jan 14 15:14:54 lpapp: I'm talking about easy things, like missing obvious DEPENDS Jan 14 15:15:06 no, it is reasonable if you ask me. Jan 14 15:15:11 it is not* Jan 14 15:15:43 I would like to see my change not breaking anything before submitting. Jan 14 15:16:08 otherwise I risk wasting others time. Jan 14 15:16:13 lpapp: changing DEPENDS variable can possibly break build Jan 14 15:16:16 others'* Jan 14 15:16:21 lpapp: so does not have to be tested on board Jan 14 15:16:36 in _your_ opinion. Jan 14 15:16:42 not in the reality. :) Jan 14 15:17:37 but I am not any maintainer here, so I do not draw rules either way. Jan 14 15:17:45 you were asking my opinion, and I replied. :) Jan 14 15:18:03 lpapp: well, that's my problem, trying to find out some proper way Jan 14 15:18:11 lpapp: and I cannot upgrade my layer right now Jan 14 15:18:25 lpapp: and I have few patches Jan 14 15:18:50 you always _can_. :) Jan 14 15:19:16 lpapp: c'mon, you are not helping Jan 14 15:19:58 lpapp: maybe taking a dylan patch, applying on master, testing in QEMU, submitting to master would do? Jan 14 15:20:14 lpapp: that would be some solution I guess Jan 14 15:27:50 Xz: sounds reasonable to me Jan 14 15:28:16 Xz: depends, I dislike qemu because it is slow. Jan 14 15:28:40 but if you are fine with that, and that you are not testing the real environment, I guess that is ok. Jan 14 15:31:30 lpapp: I can choice only between available options. Having master branch running board is not an option at this particular moment. Jan 14 15:32:31 why not ? Jan 14 15:35:33 lpapp: because I have layer based on dylan. Bumping to master is some task with lower priority than other my tasks - now we do release, it's pretty hot time in team Jan 14 15:36:25 Xz: so why is it urgent to upstream it before the release then? Jan 14 15:36:29 rather than focusing on the release? Jan 14 15:37:23 lpapp: well, I play in my free time with the board, so I could possibly give some of that 'free' work to Yocto team, right? Jan 14 15:37:44 lpapp: I do build some stuff for that dylan board so I have patches Jan 14 15:37:53 lpapp: it would be waste not to do anything with them Jan 14 15:39:32 then why not get the board things done in the free time, too? :) Jan 14 15:39:49 well, anyway, it is not my desk... Jan 14 15:40:24 I feel like everything I do seems weird for you guys Jan 14 15:41:19 :) Jan 14 15:41:33 nah, contribution is welcome... but I am afraid of submitting changes thay may break... Jan 14 15:41:48 if you are not, and the maintainers are fine with that, you can disregard my point of view. Jan 14 15:42:09 * Xz disregarding Jan 14 15:42:42 :) Jan 14 15:43:14 but qemu is very slow; be prepared. Jan 14 15:43:44 lpapp: are you using hardware acceleration? Jan 14 15:54:54 what are you using qemu for in the first place/ Jan 14 15:58:35 The Yocto Project Tech Meeting Con-Call will be starting at the top of the hour Jan 14 15:58:35 Dial-in number: 1.972.995.7777 / Participant passcode: 42001078 Jan 14 15:58:36 This call is open to all and the channel remains open to discuss any topic Jan 14 15:59:10 YPTM: Saul is on Jan 14 15:59:34 YPTM: Scott Rifenbark is on the call Jan 14 15:59:50 YPTM: IonutC is on Jan 14 15:59:53 YPTM: Matthew is on the call Jan 14 16:01:01 YPTM: polk is on Jan 14 16:01:03 YPTM: Michael here. Jan 14 16:01:20 YPTM: welcome to the technical team meeting. Please let me know who's on the bridge. Jan 14 16:01:31 YPTM: Tom Z here Jan 14 16:01:57 YPTM: will join in a couple of minutes.. Jan 14 16:02:48 YPTM: Richard is on the call Jan 14 16:03:15 YPTM: jzhang on the call Jan 14 16:03:30 davest on the call Jan 14 16:03:38 YPTM: beth is on. Jan 14 16:03:45 YPTM: Paul Eggleton is on Jan 14 16:04:16 here now Jan 14 16:05:04 * nitink is on the call Jan 14 16:05:05 YPTM: here now Jan 14 16:05:09 YPTM: any opens? Jan 14 16:05:24 * nitink is on the call: YPTM Jan 14 16:06:27 I joined as well Jan 14 16:22:09 YPTM: is the call still on? i'm good for swat duty this week. Jan 14 16:22:27 JUST ended Jan 14 16:22:29 YPTM: thank you all for joining the meeting. Have a nice day/evening Jan 14 16:22:55 rburton: good. thank you. That saves me another email :) Jan 14 16:24:14 * zeddii missed the call. Jan 14 16:24:46 rburton: git merge-base may be what you want, re: what branch did this branch come from. you can't find its real origin, but you can at least identify the commit which is the common root of both your branch and another branch, and see which branches contain that commit. if you really want to track what branch a branch came from, e.g. to automate update merges into it or rebases from it, or want to chain feature branches into one another, then i'd Jan 14 16:24:46 suggest using a tool built on top of git for such a purpose, like topgit Jan 14 16:25:38 it stores additional metadata on the branch to let you update a branch by flowing merges down into them, e.g. branch a -> branch b -> branch c, update of branch c will merge a into b, then b into c Jan 14 16:25:52 there are other tools for similar purposes, but honestly its more overhead than most care about :) Jan 14 16:26:38 kergoth: oh that could be useful, i do tend to chain feature branches Jan 14 16:28:13 rburton: some folks had considered its use for maintaining long term distro branches and the like in an upstream source repo, for managing distro packaging inside the source repository rather than out of band Jan 14 16:28:27 but tg has its own downsides, and i think folks like debian went with alternative quilt-based approaches instead Jan 14 16:29:11 http://www.koch.ro/blog/index.php?/categories/21-vcs-pkg mentions some of that, if you're curious Jan 14 16:29:28 i always liked the idea of putting oe metadata inside source trees, but our tools aren't written around that :) Jan 14 16:30:33 of course, if you don't mind adopting a very specific workflow, there are always tools like git-flow, but i think that assumes that all feature branches come off of a specific branch, so isn't as flexible as something like topgit Jan 14 16:32:02 the real value in something like topgit was the ability to export a branch as a patch, or a set of feature branches as a linear patch series, for package management, but it doesn't have to be used for that :) Jan 14 16:32:15 * kergoth finds this sort of workflow stuff interesting Jan 14 16:32:36 hi, after updating my sources (I'm on dora), my image won't build anymore. the recipe which causes the problem seems to be emu_1.5.0.bb. Any hints what could I do (I don't need qemu...) ? Jan 14 16:32:52 qemu_1.5.0.bb Jan 14 16:33:28 you'd need to provide a heck of a lot more information than that Jan 14 16:33:35 saying something fails to build doesn't really tell us anything Jan 14 16:33:42 you'll need to post the actual errors on a pastebin, if you would Jan 14 16:44:01 kergoth: sure, log out put is on http://pastebin.com/NV0E4HqF Jan 14 16:44:48 huh, interesting. try adding DEPENDS_append_pn-qemu-native = " gnutls-native" in local.conf Jan 14 16:44:48 I thought, the easiest thing would be, just to remove that recipe, because I don't need it. But I don't know why it is even used. Jan 14 16:45:08 it's used in parts of the build process, to run operations at build time that would normally have to be done on target Jan 14 16:45:35 e.g. used to be used for binary glibc locale generation, though i think that particular case has been replaced by a cross localedef Jan 14 16:45:56 ah ok, thanks for that explanation! Jan 14 16:46:31 np Jan 14 17:48:16 * RP doesn't like the look of the failures :/ Jan 14 18:30:22 * mranostay spots a wild davest and dvhart Jan 14 18:33:54 Creating a very simple recipe for a custom software in C++, I am getting 2 errors. The first one is : error: runstrip .... strip command failed ??? What is that ?! And my second error is : I want to copy a script to /www/pages/script.cgi so I do in do_install(){ install -d ${D}/www \ install -d ${D}/www/pages \ install -m 0755 ${WORKDIR}/script.cgi ${D}/www/pages/script.cgi but getting a QA Jan 14 18:33:55 Issue: files directories were installed but not shipped adding /www /www/pages /www/pages/script.cgi /www/pages/.debug How to resolve those errors ? Thank you Jan 14 18:49:25 weebet: you need to add /www to a package using FILES Jan 14 18:49:43 weebet: e.g. FILES_${PN} += "/www" Jan 14 18:49:54 (that would add /www to the main package) Jan 14 18:53:14 Thank you bluelightning Jan 14 18:53:40 why I don't have to add "/www /www/pages" ? Jan 14 19:03:05 weebet: it's recursive Jan 14 19:04:26 Thank you Jan 14 19:15:18 aside: isn't /www non-fhs compliant? shouldn't that be under srv? Jan 14 19:20:10 by default lighttpd will place its web page in /www/pages Jan 14 19:20:55 yeah, just saying we might want to think about fixing that :) Jan 14 19:21:05 I agree :-) Jan 14 19:21:21 is there a nice Makefile template out there ? Jan 14 19:21:34 probably depends on what you want it to do Jan 14 19:21:50 compile my code :-) and be bitbake friendly Jan 14 19:21:56 nothing esoteric Jan 14 19:22:55 Well, the thing is, any homerolled makefile-based solution is going to be different from the others in at least some aspects. There's no standard for how vars like cflags/ldflags/etc are passed in. for autotools, cmake, etc we know what they expect. I don't know of anything lighter than autotools/cmake/etc offhand Jan 14 19:23:46 Thank you, I will go with autotools ! Jan 14 19:51:19 any suggestion for an up to date website kind of "autohell for newbie" ? Jan 14 19:52:14 cmake might be slightly less painful, depends on the goal and perspective :) Jan 14 19:52:23 iirc there's a couple autotools books around Jan 14 19:52:39 the gnu manuals for the projects are actually surprisingly good Jan 14 19:52:39 highly recommend them Jan 14 19:52:43 make, autoconf, automake, libtool Jan 14 19:52:49 a basic autotools setup is pretty simple Jan 14 19:53:43 configure.ac, makefile.am (for each source dir) and autogen/ltmaiin.sh Jan 14 19:53:46 the problem is everybody and their brother just steals the basic files from another project Jan 14 19:53:53 so terrible stuff keeps getting passed around Jan 14 19:53:53 and never dies Jan 14 19:53:53 I am building a fastcgi application, there is 6-10 cpp files, I have 4-5 library to link to... very easy to do but it is hard to find a nice tutorial out there. Jan 14 19:53:54 :) Jan 14 19:54:09 well, you need to customize configure.ac and makefile.am Jan 14 19:54:35 the thing that bugs me about autoconf, is 99% of devs don't even use the test results in the headers for availability Jan 14 19:54:45 so most of the tests just end up being run for no good reason :) Jan 14 19:54:47 just strip down configure.ac to the bare bones Jan 14 19:54:52 e.g. fuck off libtool and your fortran test Jan 14 19:55:36 yeah, i've seen quite a few with unneeded tests... Jan 14 19:55:38 so I begin with a autoscan. then move configure.scan to configure.ac Jan 14 19:55:44 did i say customize? Jan 14 19:57:26 better not be late for lunch... Jan 14 20:43:23 Has anyone tried to create a debian package for a SDK? Jan 14 20:43:53 gjohnson: not afaik Jan 14 20:44:44 rburton: k, thanks. I am wanting to see if I can figure out how to create a debian package for managing the sdk on my developers machines **** ENDING LOGGING AT Wed Jan 15 02:59:59 2014