**** BEGIN LOGGING AT Mon Dec 23 02:59:59 2013 Dec 23 04:37:02 hi all when i try to load g_serial module in my at91sam9x5ek board and connect usb to my ubuntu pc but it shows me initializing modem message and minicom is freezed,eventhough i double checked the permission also but it shows the same issues can you please help me Dec 23 07:10:12 hi Dec 23 10:34:32 hi, is it a good idea to drop the bareclone entry here? SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta" Dec 23 10:34:45 I would like to aid the linux kernel development with Yocto in my layer. Dec 23 10:35:26 i *think* linux-yocto needs a bare clone because of how it's configured, using multiple branches in the repo. Dec 23 10:36:30 rburton: what exactly do you mean? Dec 23 10:36:35 What will be the expected impact if I remove it? Dec 23 10:37:05 potentially just a waste of disk space/time, but i think the build for linux-yocto checks out multiple branches Dec 23 10:38:52 but if you're not using linux-yocto that isn't a concern Dec 23 10:43:02 rburton: I am using a copy of it from denzil. Dec 23 10:43:17 with which it is extremely painful to do kernel development. Dec 23 10:43:28 so I am trying to switch to git, but then again, bareclone is a blocker for that. Dec 23 10:43:58 so if it does not work without that, I will submit a feature request because it is a valid use case in my book to be able to develop within Yocto, and not use many different environments. Dec 23 10:44:12 lpapp: have you read the yocto kernel development manual? Dec 23 10:44:31 yes, a few times. Dec 23 10:46:30 lemme re-read it. Dec 23 10:47:46 eg http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto-kernel-extras/tree/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend is useful for building a kernel using a local git tree, so you can commit on local branches and build from it Dec 23 10:48:00 or, don't use linux-yocto, and then the bareclone this isn't an issue. Dec 23 10:53:11 rburton: as I said, I am not using Yocto's git clone. Dec 23 10:53:15 I am using my layer's git clone. Dec 23 11:29:43 lpapp: The bareclone option just means the system provides the .git directory for linux-yocto and the kernel tooling figures out which branches it wants checked out where Dec 23 11:30:46 lpapp: Removing it from linux-yocto will mean the tools get upset about not being able to find a bare clone which they expect . The fetcher will also get confused since there are two branches it fetches for linux-yocto and which one should it check out if it isn't a bare clone? Dec 23 11:35:37 RP: what tools? I do not need two branches. Dec 23 11:36:03 lpapp: so you're not using linux-yocto, so you don't need the bare clone. Dec 23 11:36:20 lpapp: right, so don't use linux-yocto then Dec 23 11:36:29 rburton: as I said, I do use currently, but if it is irrelevant for a regular bsp developer, it is not worth using it, indeed. Dec 23 11:36:42 I do use means, the recipe is pretty much cloned. Dec 23 11:36:46 including the .inc file. Dec 23 11:37:25 RP: well, it is not so simple. Dec 23 11:37:42 writing a linux kernel recipe seems to be a lot of effort based on the length of the linux-yocto recipe files. Dec 23 11:38:06 so, I would not definitely like to start it from scratch; rather, I would customize the cloned linux-yocto for my own needs. Dec 23 11:38:20 so which tools exactly, and what do I need to remove to get rid of the multi-branches? Dec 23 11:38:26 anyway, why is it using multiple branches/ Dec 23 11:38:39 one for kernel source, one for the configuration metadata Dec 23 11:38:40 why not provide only the latest recipe? Dec 23 11:38:51 lpapp: which parts of linux-yocto do you want? Do you want defconfig fragment support for example? Dec 23 11:38:54 rburton: what does configuration metadata mean? Dec 23 11:39:05 the config fragments which are used to assemble the configuration are stored in the "meta" branch Dec 23 11:39:10 RP: I think so because I have custom kernel drivers, so I would like to enable them. Dec 23 11:39:31 unless there is a simple way to do that without a yet another branch. Dec 23 11:39:36 lpapp: What I mean is are you happy to use a full defconfig file or are you after the fragment support? Dec 23 11:40:10 lpapp: also, are you after any of the config fragment features or the patches in linux-yocto? Dec 23 11:40:15 RP: currently, I am using the defconfig, and I am happy with it. Dec 23 11:40:25 bitbake -c menuconfig virtual/kernel -> I edit and save it. Dec 23 11:40:30 then I copy .config to defconfig Dec 23 11:40:39 lpapp: right, then don't use linux-yocto then Dec 23 11:41:00 lpapp: find an example of a simpler kernel from another layer Dec 23 11:41:13 do you have any suggestion? Dec 23 11:41:47 lpapp: something like http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux-mainline_3.2.bb Dec 23 11:41:54 but anyway, does that mean linux-yocto sacrificies the kernel development within Yocto for having config fragments? Dec 23 11:42:00 lpapp: that shows a mainline kernel, a set of patches and a defconfig Dec 23 11:42:10 lpapp: obviously you can put your own patches in, or none at all Dec 23 11:42:59 lpapp: no, you can do kernel development just fine with it, its just a little more complex to use because of the fragment management and other things and it sounds like you'd prefer something simpler Dec 23 11:43:08 lpapp: using that recipe I pointed you at linux-yocto will build from a source tree you control, so you can develop and commit to local branches just like you would without yocto. Dec 23 11:43:37 lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux_3.3.7.bb is an even simpler example Dec 23 11:44:25 well, what I would prefer is: Dec 23 11:44:34 bitbake virtual/kernel Dec 23 11:44:37 then it builds stuff Dec 23 11:44:46 I test the rootfs containing the kernel Dec 23 11:44:54 I find a bug, I fix it within Yocto, inside the work folder. Dec 23 11:45:12 and then I can use git diff to regenerate the change beside the recipe rather than using low-level diff, patch and all that mess. Dec 23 11:45:24 that is the use case I would like to have. Dec 23 11:45:49 lpapp: start with one of the simpler kernel recipes above and you can do that just fine there Dec 23 11:46:08 lpapp: once you understand and have that working you can think about linux-yocto if it makes sense Dec 23 11:46:22 well, we already linux-yocto Dec 23 11:46:35 migrating would be quite a bit of work, so I do not feel comfortable with it. Dec 23 11:46:42 already havE* Dec 23 11:47:30 lpapp: then don't, use linux-yocto but be aware it does need the multiple branches to do what it does and you will have to learn more about it. You cannot simply remove that since you don't like it Dec 23 11:48:10 I would also add that it is is designed to work that way for good reasons and bugs opened about it will be closed as it working as designed Dec 23 11:48:47 lpapp: you're describing one possible linux-yocto workflow...but that git diff needs to be committed so that you obtain a patch for your recipe Dec 23 11:49:11 ant_work: not really, no. Dec 23 11:49:21 lpapp: yes, I do that ;) Dec 23 11:49:28 ant_work: bitbake can handle diff files just fine. Dec 23 11:49:38 ant_work: looks for patches. Most of them are not git patch, really. Dec 23 11:49:43 you do not need to commit to get a diff. Dec 23 11:49:58 yo do need to commit to get a patch Dec 23 11:49:58 (but this is not the major point anyway) Dec 23 11:50:02 no Dec 23 11:50:07 git diff > stuff.patch Dec 23 11:50:10 job done Dec 23 11:50:30 in the bitbake framework, you need a patch to add the kernel patch Dec 23 11:50:54 git diff > stuff.patch and you have the patch. What is the problem? Dec 23 11:51:26 RP: I disagree. Dec 23 11:51:41 at the very least - since I expect it to be common - there could be some examples and/or skeleton. Dec 23 11:51:54 lpapp: an even better workflow using linux-yocto doesn't involve patches at all, like i pointed you at. Dec 23 11:52:21 rburton: well, I have not had time yet to understand every comment fully yet. Dec 23 11:52:29 I am still just at reading the kernel development manual (first suggestion) Dec 23 11:52:38 lpapp: try 'git-format-patch master' in the linux-yocto workdir, in the kernel dir Dec 23 11:52:51 lpapp: if you're not going to use linux-yocto, then stop reading the manual for it. Dec 23 11:53:01 heh Dec 23 11:53:25 ant_work: why would I? Dec 23 11:53:46 I was happy with git diff, that is not an issue for me. Dec 23 11:54:21 rburton: I have no clue just yet what I will use, so I have to go through everything, and then make an educated decision. Dec 23 11:57:45 ant_work: moreover, currently, I do not use git based linux-yocto Dec 23 11:57:52 I am still stuck with the old tarball based denzil. Dec 23 11:59:55 (but that is the very first thing to fix since it is very hard to work that way with sources within Yocto) Dec 23 12:03:30 what is the point of config fragments anyway? Dec 23 12:03:58 Wouldn't it be closer to upstream to use `bitbake -c menuconfig virtual/kernel` and provide an option to save .config back to defconfig automatically when saving the settings. Dec 23 12:04:34 lpapp: denzil's kernel is built with linux-yocto, and linux-yocto has always used git. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux?h=denzil Dec 23 12:04:51 lpapp: config fragments are very useful when you maintain more than one machine Dec 23 12:05:34 why ? Dec 23 12:05:54 bitbake -c menuconfig arm virtual/kernel Dec 23 12:05:58 because you can separate common things from machine-specific things. Dec 23 12:06:05 the syntax could be something like that. I would prefer that over a brand new concept. Dec 23 12:06:21 remember that nobody is making you use linux-yocto Dec 23 12:06:40 sure, but I think it should still be comfortable and handy. ;} Dec 23 12:07:41 so why exactly do we need config fragments as opposed to a option for the bitbake command? Dec 23 12:07:48 s/a/an/ Dec 23 12:08:32 because you can separate common configuration from machine-specific configuration Dec 23 12:08:40 so could you with an option. Dec 23 12:08:47 fine Dec 23 12:08:49 and the rest would be transparent for the end user. Dec 23 12:12:03 $ diff -Nurp config.orig .config | sed -n "s/^\+//p" > frag.cfg Dec 23 12:12:16 erm? Really? Isn't there a nicer way (i.e. less plumber)? :] Dec 23 12:24:27 is there a feature request to make it handier? Dec 23 12:30:14 11:59 < rburton> lpapp: denzil's kernel is built with linux-yocto, and linux-yocto has always used git. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux?h=denzil -> I do not know how that is possible because definitely, denzil here does not fetch from git. Dec 23 12:30:45 SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v3.0/linux-${PV}.tar.bz2;name=kernel \ Dec 23 12:30:56 it even eventually does fetch the released tarball here. Dec 23 12:32:54 lpapp: have a look at the URI i sent you and compare with what you have. Dec 23 12:35:26 rburton: perhaps it was added post-denzil. Dec 23 12:35:36 i.e. in a bugfix release. Dec 23 12:35:36 lpapp: nope. Dec 23 12:38:37 rburton: well, then we apparently modified it silently. Dec 23 12:38:44 lpapp: suspected as much Dec 23 12:39:00 (i.e. without mentioning it to me) Dec 23 12:39:08 or it predates my time, etc. Dec 23 12:39:58 you need to run a diff between your tree and poky, and move out any changes so you don't get confused. Dec 23 12:40:32 well, the linux-yocto recipe and the .inc are pretty complex. Dec 23 12:41:00 yeah, but if its building from a tarball, it's very much not linux-yocto Dec 23 12:43:10 I think it is except the SRC_URI Dec 23 12:43:20 since we have the same files with pretty much the same complexity level to me. Dec 23 12:43:33 btw, is there any point in linux-yocto when you need to support only one board type? Dec 23 12:44:18 lpapp: the argument is a lot harder then Dec 23 12:44:36 rburton: what argument? :) Dec 23 12:45:05 the fragments argument Dec 23 12:45:31 I am not sure I can follow. Dec 23 12:46:00 what exactly is harder? Can you give a use case? Dec 23 12:46:09 there is always point to linux-yocto, but if you have a single board and no flexbility, then it certainly is overhead you may not need Dec 23 12:47:56 ok, thanks. Dec 23 12:59:34 rburton: http://pastebin.kde.org/ptmsc1yrl -> this is our linux-foo.inc Dec 23 13:04:48 rburton: and this is the versioned linux kernel recipe, http://pastebin.kde.org/piuoelimx Dec 23 13:04:56 is it ok that the .inc file seems to be commented out? Dec 23 13:06:42 "page does not exist" Dec 23 13:08:08 hmm, bizarr bug. Dec 23 13:08:47 rburton: http://pastebin.kde.org/pmo1tdsl2 Dec 23 13:13:17 "page you are looking for does not exist" Dec 23 13:13:37 very odd since this time I even confirmed it. Dec 23 13:13:43 and I put it up for 30 minutes Dec 23 13:14:25 rburton: http://pastebin.kde.org/pqxsupmgz Dec 23 13:14:38 that works Dec 23 13:14:55 I selected 6 hours this time. Dec 23 13:15:14 yes, that require is commented out Dec 23 13:15:16 so its not used Dec 23 13:15:28 yeah; is that bad? Dec 23 13:15:41 KERNEL_IMAGETYPE = "uImage" Dec 23 13:15:41 FILES_kernel-image = "/boot/uImage*" Dec 23 13:15:44 I do not understand that either. Dec 23 13:15:52 IMO, the second line does not make any sense.... Dec 23 13:16:02 i have no idea what's in that .inc, so i can't comment Dec 23 13:16:03 since that is the default expansion for the image type set.... Dec 23 13:16:53 yep Dec 23 13:27:55 is it ./meta/classes/kernel-yocto.bbclass responsible for the fragment feature? Dec 23 13:28:27 looks like it's got at least some of the logic. no idea if that's all of it. Dec 23 13:28:35 i suspect it's the bulk of it, yes. Dec 23 13:30:00 I guess removing that inheritance along with the bareclone stuff may actually work. Dec 23 13:31:04 the recipe you pointed me at just uses inherit kernel, so just changing that tarball src_uri to a git repo will work, yes. Dec 23 13:31:28 rburton: no, I am considering being closer to linux-yocto Dec 23 13:31:45 rburton: i.e. including dtb and inheriting the kernel class as well. Dec 23 13:50:36 How to set up mirros to fetch the source in yocto Dec 23 13:55:32 ramose: maybe this will help: https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F Dec 23 13:58:16 Thanks bluelightning ,I guess I have have to use premirrors my self because I wanted to set more than one mirror Dec 23 14:00:35 rburton: at least, it would be lovely if the fragments could be that well modularized. Dec 23 14:03:32 bluelightning would you like to tell me that use of BB_NO_NETWORK = "1"? Dec 23 14:04:15 ramose: BB_NO_NETWORK tells bitbake not to download anything from the network Dec 23 14:05:34 So I should not use it unless I Downloaded all tar balls before bitbake,right? Dec 23 14:06:13 Can I restrict use of BB_NO_NETWORK = "1" to specific recipe? Dec 23 14:06:24 rburton: I do not follow how it makes sure to fetch 3.2 for instance: KBRANCH = "standard/default/base" and SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta" Dec 23 14:09:10 rburton: i.e. I do not know how to change the SRC_URI from tarball to git. :/ Dec 23 14:10:19 git://some-git-uri;protocol=(http|git);branch=(branchname) Dec 23 14:10:42 but that is not in line with the linux-yocto stuff. Dec 23 14:10:56 I would like to keep it as close as possible. Dec 23 14:11:03 the one you pasted just adds more variables Dec 23 14:11:11 you don't want bareclone Dec 23 14:11:16 you don't need name Dec 23 14:11:49 rburton: well, I do not know how KBRANCH = "standard/default/base" gets to 3.2.1, for instance Dec 23 14:11:58 in linux-yocto_3.2.bb Dec 23 14:11:59 it doesn't Dec 23 14:12:01 or 3.2.X, whatever. Dec 23 14:12:01 that's a branch name Dec 23 14:12:17 and the branch name should have the version information Dec 23 14:12:21 unless they only tag it. Dec 23 14:12:26 https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.10/ Dec 23 14:12:51 right, so only tags. Dec 23 14:12:54 the exact version is specified elsewhere, where it says what hash to grab Dec 23 14:12:56 no, branches. Dec 23 14:12:58 but how is that passed in Yocto? Dec 23 14:13:00 no, tags. Dec 23 14:13:04 check "git tag -l" Dec 23 14:13:10 (in the linux kernel) Dec 23 14:13:20 and then check git branch -a Dec 23 14:13:20 i mean standard/default/base is a branch Dec 23 14:13:28 well, that is not enough Dec 23 14:13:38 you need to check out the tag, not the branch, really. Dec 23 14:13:39 i'm just telling you what you wanted to know Dec 23 14:13:44 to get a certain version desired. Dec 23 14:14:12 ok, perhaps I am already beyond the understanding of that. Dec 23 14:14:20 currently, I do not understand how the right versioned tag is checked out Dec 23 14:14:24 its not! Dec 23 14:14:28 I guess I would need to check the implementation of the kernel class Dec 23 14:14:32 well, it should be. Dec 23 14:14:36 there is a SRCREV specified in the recipe Dec 23 14:14:41 I want to get 3.2.X for instance. Dec 23 14:14:43 huh Dec 23 14:14:45 that revision is checked out Dec 23 14:14:48 that is dirty, isn't it? Dec 23 14:14:49 (for linux-yocto) Dec 23 14:14:53 no, its precise Dec 23 14:14:58 how come? Dec 23 14:15:10 You already have the version information, and the linux kernel does have handy version tags Dec 23 14:15:10 because its very rare to ship a pristine kernel release Dec 23 14:15:23 so an sha is an unnecessary complication. Dec 23 14:15:36 I disagree. Dec 23 14:15:51 I rather think that people ship released and well tested stuff as opposed to random shas. Dec 23 14:17:56 bluelightning: Woulld you like to address my doubts regarding use of BB_NO_NETWORK = "1" Dec 23 14:18:34 ramose: I think you can restrict it to an individual recipe yes Dec 23 14:18:49 I never tried that though Dec 23 14:19:13 ok Dec 23 14:26:41 rburton: perhaps, there could be an option for the Linux stuff to disable the fragment stuff in a custom layer? Dec 23 14:26:48 without cloning and reinventing all the stuff? Dec 23 14:29:09 lpapp: isn't that what kernel.bbclass is? Dec 23 14:30:56 all of linux-yocto.bbclass is about the fragments and machine branches, so just don't use linux-yocto Dec 23 14:41:42 rburton: you mean linux-yocto.inc rather than kernel.bbclass and linux-yocto.bbclass? Dec 23 14:55:40 rburton: oh, wow, SRCREV can also be a tag name! Dec 23 14:55:44 not just com Dec 23 14:55:50 mit hash... that is lovely, isn't it Dec 23 14:58:55 no it isn't Dec 23 14:59:15 because then it will always run git ls-remote to map tag name to SHA-1 Dec 23 15:00:15 JaMa: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux_3.3.7.bb#n20 Dec 23 15:00:36 sure, you *can* Dec 23 15:00:38 it's just a bad idea Dec 23 15:01:07 it forces a remote git operation every build (parse? can't recall) Dec 23 15:01:17 lpapp: no it isn't was about "lovely" :) Dec 23 15:01:35 rburton: parse Dec 23 15:01:41 double-ouch Dec 23 15:01:51 JaMa: that is alright. I do not feel bad about it. Dec 23 15:01:56 compared to the recipe maintenance effort. Dec 23 15:02:04 we had a lot of them in webOS (not in SRCREV but in tag=foo) Dec 23 15:02:39 I've finally got rid of them all lately (replaced with sanity check *after* the fetch) Dec 23 15:02:42 I guess we will need to agree to disagree. :) Dec 23 15:02:51 lpapp: consider this background on why many layers use hashes instead of tag names Dec 23 15:03:08 rburton: because Yocto is bad IMHO Dec 23 15:03:14 it should help with proper maintenance. Dec 23 15:03:15 lpapp: two reasons you can't argue with: 1) performance 2) reproducable Dec 23 15:03:35 using a tag name means a network operation, and means the source can change without the recipe changing. Dec 23 15:03:37 and surely, bumping from 3.2.1 to say, 3.2.2 or 3.3.0 is less effort than going all the way around to get the requested sha. Dec 23 15:03:54 yeah, can't deny that, and nobody did Dec 23 15:04:08 just giving you reasons why many layers don't use tag names, but hashes. Dec 23 15:04:09 better to get right SHA-1 once by recipe maintainer, than every builder getting it with ls-remote in every parse :) Dec 23 15:04:45 it is not like you fetch that often after all. Dec 23 15:04:58 more precisely, you would not fetch at all if it is checked in properly. Dec 23 15:04:59 especially useful when building some private stuff just from prepopulated downloads/PREMIRROR without current access to remote git repos Dec 23 15:05:00 I have installed pam-plugin-faildelay and added DISTRO_FEATURES_append = " pam" to my local.conf file ,Now how to make sure that my PAM module installed and working well?? Dec 23 15:05:39 lpapp: you won't run do_fetch, but you'll *always* get git ls-remote to map that tag name to SHA Dec 23 15:05:56 JaMa: fix yocto. Dec 23 15:06:03 it should be able to cache it of course. Dec 23 15:06:07 16:03:53 < rburton> lpapp: two reasons you can't argue with: 1) performance 2) reproducable Dec 23 15:06:20 it cannot fetch it because of 2) Dec 23 15:06:26 1) is a bug in Yocto Dec 23 15:06:30 I do not understand what 2) means. Dec 23 15:06:33 NO Dec 23 15:06:42 tags are not immutable in git. Dec 23 15:07:00 -> they can change Dec 23 15:07:02 rburton: sure, they are in any sane project. :) Dec 23 15:07:13 you cannot ever know if tag=foo is still the same source Dec 23 15:07:15 and if you have multiple builders all building tag=foo at different time they could get different source Dec 23 15:07:41 or want to do a new build to make a point release of that product you shipped a year ago Dec 23 15:07:46 and a tag moved, and it won't build anymore Dec 23 15:08:06 that said feel free to use tag names if you prefer it Dec 23 15:08:14 but these are the reason why we generally don't Dec 23 15:08:20 as I said, software developers can screw up, but sane people do not. Dec 23 15:08:44 but that is true for anything, so I do not think something has to defend against overly silly things which usually almost never happens. Dec 23 15:08:58 happen.* Dec 23 15:09:14 to me, it sounds like over-engineering. :) Dec 23 15:09:19 it was happening quite often in my experience Dec 23 15:09:58 in that case, you would use a tarball anyway Dec 23 15:10:01 not to get broken. Dec 23 15:10:15 but then again, I have never really met such insane devs and release guys. :) Dec 23 15:10:26 and because better be safe than sorry, I've forced to use annotated tags in our components and every component has tag as well as SHA-1 and .bbclass is doing the check that they are annotated and correct Dec 23 15:11:22 so for me 2) is not valid, and 1) is a Yocto bug respectively. Dec 23 15:11:43 it *should* give an option to me if I want to cache for simple maintenance. Dec 23 15:12:15 git show-ref tag-name is *simple* Dec 23 15:12:31 no, it is not. Dec 23 15:12:33 compare the two: Dec 23 15:12:42 1) 3.1.2 -> 3.1.3 done Dec 23 15:12:46 1) Find where to clone from Dec 23 15:12:48 2) Clone Dec 23 15:12:51 3) run the command Dec 23 15:12:53 4) remove Dec 23 15:13:15 many unnecessary extra steps. Dec 23 15:13:27 you can skip 2-4 if you're clever Dec 23 15:13:49 the point of the maintenance of not requiring clever tricks Dec 23 15:13:55 i.e. easily maintenable. Dec 23 15:14:04 s/of not/ is not/ Dec 23 15:14:09 cd downloads/git2/*component; git remote update; git show-ref 3.1.3 Dec 23 15:14:26 I have no idea how that works Dec 23 15:14:31 and I would spend hours to figure out Dec 23 15:14:45 compared to 3.1.2 to 3.1.3 which is literally a couple of seconds. Dec 23 15:15:02 neither of which compare to the minutes this has been discussed Dec 23 15:15:05 for no reason at all Dec 23 15:16:03 FR is being submitted... Dec 23 15:16:20 lpapp: don't even bother Dec 23 15:17:09 rburton: you wrote that for many features and reports in the past which got fixed, so no worries. Dec 23 15:18:05 (i.e. it is possible that others think differently than you) Dec 23 15:19:19 I see no reason for aiding end users for no real cost. Dec 23 15:19:42 declining to aid Dec 23 15:20:04 because we both already explained why oe-core shouldn't do it Dec 23 15:20:11 especially when it comes to my software why I can explicitly guarantee I do not go insane, I would like to be able to reduce the maintenance overhead. Dec 23 15:20:49 I see no reason for blocking people having simpler life. Dec 23 15:21:09 if you do not want to use that feature, you will not use it, it is that simple. Dec 23 15:21:18 it would not be obligatory after all. Dec 23 15:21:39 any one ppoint me out how should I test the PAM module support Dec 23 15:21:50 I have installed pam-plugin-faildelay and added DISTRO_FEATURES_append = " pam" to my local.conf file ,Now how to make sure that my PAM module installed and working well?? Dec 23 15:51:23 0: linux-foo-3.2.1-b+gitrv3.2.1 do_fetch (pid 2206) Dec 23 15:51:41 it got stuck here.... it has been about twenty minutes now.... any idea what is going on? Dec 23 15:53:04 a slow git clone? do a ps and see if there's a git process running Dec 23 15:53:18 ramose: chek it's installed by looking in the file system Dec 23 15:53:44 rburton: I cannot run ps unfortunately. Dec 23 15:54:36 anyone have any thought on why when I build (and install) rsync, it doesn't end up in *any* of the sysroots? Dec 23 15:54:50 man ends up in target, but no binary.. Dec 23 15:55:49 rburton: should I check some log instead or monitor the size of the folder being cloned? Dec 23 15:56:25 lpapp: the fetch log might say something useful, or a du on the folder being fetched into yes. Dec 23 15:57:06 rburton: where is all that? Dec 23 15:57:16 oh, wait, it returned. Dec 23 15:58:37 rburton: thoughts on rysnc not presenting itself in any of the sysroots?? Dec 23 15:59:02 WarheadsSE: native or non-native? Dec 23 15:59:19 WarheadsSE: oh, well, iirc binaries don't appear in the target sysroot Dec 23 15:59:26 and even if they did, they'd be useless. Dec 23 15:59:32 Yes Dec 23 15:59:32 rburton: ERROR: Function failed: linux-foo: LIC_FILES_CHKSUM points to an invalid file: /home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.1/build/tmp/work/foo-foo-linux-gnueabi/linux-foo/3.2.1-b+gitrv3.2.1/linux-None/COPYING Dec 23 15:59:41 but I am not getting it at all is the point Dec 23 15:59:54 I can see it in the work dir, and the binary is there, but, viola, nada. Dec 23 15:59:59 LIC_FILES_CHKSUM = "file://${WORKDIR}/linux-${KERNEL_RELEASE}/COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" Dec 23 16:00:02 that looks wrong. Dec 23 16:00:10 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" Dec 23 16:00:13 should probably be that. Dec 23 16:00:23 I wonder why my predecessors used like that Dec 23 16:09:53 hi there, who do I talk to send a patch to meta-oe? Dec 23 16:12:15 Xz: what do you need? Dec 23 16:12:23 WarheadsSE: if you care about it in the sysroot i presume you want the native one Dec 23 16:12:32 JaMa: I have a patch for v4l2apps Dec 23 16:12:38 JaMa: bugfix Dec 23 16:12:46 WarheadsSE: presumably you have a patch for rsync, as oe-core's rsync doesn't do native. Dec 23 16:13:07 Xz: just send it to openembedded-devel@lists.openembedded.org and if it's good, I'll apply it Dec 23 16:13:50 JaMa: so openembedded-core is poky, openembedded-devel is meta-oe ? Dec 23 16:14:39 Xz: just follow README file, openembedded-core is oe-core, poky is yocto ML Dec 23 16:14:59 JaMa: ok cool, thanks Dec 23 16:15:11 rburton: Yeah, I have noticed that. Dec 23 16:15:15 and poky as git repo == oe-core+bitbake+meta-yocto Dec 23 16:15:37 I've decided to just add rsync to the container image, and punch the dev that decided that rsync as a part of install was a brilliant idea. Dec 23 16:15:44 haha Dec 23 16:15:48 good move Dec 23 16:16:09 fwiw, BBCLASSEXTEND="native" should be all you need in rsync.bb to make it build as rsync-native Dec 23 16:16:44 yeah, but then I have to alter the rsync recipe for the matter of this DERP deciding he'd save time on rebuilding the package over and over. Dec 23 16:16:57 it _should_not_ be in the final install methods. Dec 23 16:17:01 JaMa: one more question - are you still taking patches for dylan? or master only? Dec 23 16:18:08 rburton: git log -n1 "Add 'rsync' to the bitbake container because someone decided that rsync was a good choice to use in an install function of a Makefile in production" Dec 23 16:18:43 that someone knows exactly who the F they are too. Dec 23 16:24:13 rburton: I do not follow.... shouldn't my git patches be applied with their commit messages if I use git? Dec 23 16:24:28 or only the raw content is applied? Dec 23 16:24:40 how can I fix this? Dec 23 16:25:40 lpapp: if you have a git repo and patches in SRC_URI then the patches are applied using "patch", not committed. Dec 23 16:26:18 well, the patches are always applied using patch, no special-cases. Dec 23 16:26:54 I believe you can set PATCHTOOL = "git" if you do want git to apply the patches Dec 23 16:27:09 but then of course the patches *must* apply properly with git am Dec 23 16:27:22 rburton: that will make the development within Yocto super painful. Dec 23 16:27:40 currently, I have a huge patchset, and there is a bug to be fixed in the 15th. Dec 23 16:27:47 if you want less "painful" development, use a proper git branch and don't use patches at all Dec 23 16:27:51 it is impossible to properly rebase without git. Dec 23 16:27:56 lpapp: so use the power of git and use a branch and not patches Dec 23 16:28:08 rburton: have no any clue what you are talking about. Dec 23 16:28:20 rburton: Yocto *should* be able to apply a git patch set. Dec 23 16:28:32 that's totally irrelevant. Dec 23 16:28:35 and not just the raw content. Dec 23 16:28:42 if you have a huge patch set, maintain it in a git branch Dec 23 16:29:02 that does not make any sense Dec 23 16:29:12 on the contrary, it makes perfect sense Dec 23 16:29:13 since you would need to get it work in Yocto anyway if you plan to use Yocto. Dec 23 16:29:38 and adding extra overhead (again) to the end user rather than the tool being smart does not ... make sense. Dec 23 16:30:13 using git as it's intended to be used is not extra overhead, it's *less* overhead Dec 23 16:30:19 most definitely, Yocto should have a variable or whatever config option for applying a git patchset just right. Dec 23 16:30:39 lpapp: it does, see what I said above about PATCHTOOL = "git" Dec 23 16:30:44 currently, I am completely frustrated with Yocto Dec 23 16:30:51 a git branch is still far easier to manage Dec 23 16:30:57 I have been trying for two days to get any kind of development in it done Dec 23 16:31:05 but it has been so far just a waste of time, and I got nothing done. Dec 23 16:32:07 steps for maintaining a kernel 1) clone kernel 2) apply your patches to a branch 3) build that branch. to iterate on a feature, use externalsrc so yocto is building the same source tree that you are hacking in. Dec 23 16:32:29 i told you that about five hours ago, but i'll tell you again in case you missed it. Dec 23 16:34:04 I hope you do realize I clone a branch since that is what we have been discussing for hours Dec 23 16:34:14 so I have no idea what branching is being talked about, really. Dec 23 16:34:18 it *already* is a branch Dec 23 16:34:28 the problem is /not/ the branch Dec 23 16:34:41 the problem is that Yocto does not apply the git patches as git patches, but raw patches. Dec 23 16:34:55 talking about branching looks red herring to me here because I already clone the dedicated release branch. Dec 23 16:35:07 well, tag, whatever. Dec 23 16:35:25 in which case why are you worrying about a patch set, when you have a branch Dec 23 16:36:46 and the solution you're looking for is to maintain your patches as a branch in a git repository Dec 23 16:37:00 and then build that branch, instead of patching a different branch Dec 23 16:37:08 it is all red herring. Dec 23 16:37:57 Also, PATCHTOOL is not what I want. I want to have a PREFERRED_PATCHTOOL Dec 23 16:38:08 i.e. I really do not want to set it for every corresponding recipe. Dec 23 16:38:21 I want to set a preferred tool, and if it is not like that it can fallback to whatever the default is. Dec 23 16:38:31 and then it could be set globally. Dec 23 16:39:14 (again that would reduce the maintenance per package) Dec 23 16:43:05 Xz: fixes for dora and dylan are still welcome Dec 23 16:44:58 lpapp: you can set PATCHTOOL in a global configuration file Dec 23 16:45:05 PATCHTOOL = "git" -> did not work Dec 23 16:45:21 rburton: I do not know what will happen for non-git patches if it is not preferred, but mandatory. Dec 23 16:45:25 I wouldn't advise setting it globally Dec 23 16:45:29 if it is just preferred, the variable is probably called wrong. Dec 23 16:45:42 patch.bbclass has not been designed to handle any kind of fallback Dec 23 16:45:53 sounds like a bad design right there Dec 23 16:46:01 either way... it does not work even for a single package. Dec 23 16:46:14 it does not apply my changes nicely along with the commit message for the kernel Dec 23 16:46:28 I used bitbake -c cleansstate virtual/kernel && bitbake virtual/kernel Dec 23 16:46:31 but nothing really changed. Dec 23 16:47:55 is there anything else to try or it just will not work? Dec 23 16:55:25 I need to remove the whole build folder for it to work? Dec 23 17:03:33 so what will happen to PATCHTOOL = "git" if the patch is not actually a git formatted patch? Dec 23 17:07:32 lpapp: bluelightning said it does "git am", so that will fail. Dec 23 17:07:46 so do_patch presumably fails Dec 23 17:08:20 well, I would get a fallback prompt to fix stuff Dec 23 17:08:29 unless Yocto is broken there. Dec 23 17:08:37 well, in fact, it should stop by giving an error message anyway. Dec 23 17:08:41 or at least a big warning. Dec 23 17:09:56 of course if all your patches can be applied with git am, then you probably generated them with git in the first place, so why not just ask bitbake to build that git branch instead of going branch -> patches -> branch? Dec 23 17:11:02 because that would be way over-engineered. Dec 23 17:11:21 creating branch for a few changes, and then store them somewhere else, maintain them separately, etc, etc. Dec 23 17:11:27 the whole point of using git for this is to avoid that. Dec 23 17:11:34 otherwise I would not use git in the first place. Dec 23 17:11:39 but i'm saying use git Dec 23 17:11:42 I would just grab a released tarball (basically a forked version) Dec 23 17:12:16 the whole point of using git is to help with applying and modifying patches. Dec 23 17:12:22 while preserving upstream as is. Dec 23 17:20:20 where can I find the git apply log? Dec 23 17:20:30 it might very well be a bug in Yocto not reporting errors properly. Dec 23 17:21:39 the patch log, as usual Dec 23 17:22:02 where is that Dec 23 17:22:28 seems to be in workdir/temp Dec 23 17:22:49 yes Dec 23 17:22:59 that's where all the logs for all the tasks for all the recipes go Dec 23 17:23:11 the file does not have any kinda error, nor warning inside. Dec 23 17:23:39 even though I clearly put non-git patches in there for a test. Dec 23 17:23:56 where did you set PATCHTOOL? Dec 23 17:24:15 PATCHTOOL = "git" Dec 23 17:24:15 SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;branch=${KBRANCH} \ Dec 23 17:24:39 so in a recipe Dec 23 17:24:41 * rburton shrugs Dec 23 17:24:45 never used it, you'd have to debug it Dec 23 17:25:20 well, it already has debug log level based on the DEBUG lines in the log. Dec 23 17:26:22 lpapp: bluelightning: I think it's using git apply not git am Dec 23 17:26:33 see meta/lib/oe/patch.py Dec 23 17:26:42 JaMa: you might be right, I didn't actually check Dec 23 17:27:39 so there is no way to apply git patches with their commit messages, etc, into a git tree? This has to be fixed asap... Dec 23 17:28:44 lpapp: you can always send patch as you're probably only one requesting it Dec 23 17:28:52 btw, it looks strange the code is using git execution as opposed to using a git library like libgit2. Dec 23 17:28:57 (I think that even has a python wrapper) Dec 23 17:29:37 lpapp: for a simple operation such as "apply a patch", that's another host dependency we'd need. Dec 23 17:29:43 JaMa: currently, it is blocking me yes, but I do not think people can live much without it who would like to develop within Yocto to easily update patches. Dec 23 17:30:02 rburton: if you check the git operations used, you will see it is not just patch Dec 23 17:30:12 moreover, python dependencies come for almost free. Dec 23 17:30:23 lol Dec 23 17:30:25 it is the matter of a trivial installation mostly. Dec 23 17:30:31 pypi, etc. Dec 23 17:30:41 (but really, these things are usually part of the distros either way) Dec 23 17:31:31 rburton: well, once the git output changes in a relevant way, it gets broken. Dec 23 17:31:38 that cannot really happen with a source compatible lib. Dec 23 17:32:03 so, it is not like a non-worthy dep for increased stability IMHO. :) Dec 23 17:32:18 weren't you speaking about reproducability above anyhow? :] Dec 23 17:32:45 patches welcome. :) Dec 23 17:33:07 I guess... :) Dec 23 17:33:20 anyway, the most important patch would be git am. Dec 23 17:33:57 IMO, it is acceptable to use git am by default rather than git apply. Dec 23 17:34:11 since if it is not a git repository, patch can still apply git formatted patches. Dec 23 17:34:49 hmm, but git apply can apply patches without headers, which is more common Dec 23 17:35:04 what do you mean by headers in this context? Dec 23 17:35:22 author, subject,date Dec 23 17:35:36 lpapp: curious: what is the reason that you want a branch in WORKDIR with the patches as commits? Dec 23 17:36:39 JaMa: patch will work for that, too. Dec 23 17:36:56 rburton: I do not wanna branch Dec 23 17:37:05 rburton: I wanna have a patchset like with quilt, etc. Dec 23 17:37:17 I *would* like to avoid branches if possible. Dec 23 17:37:24 since that is a maintenance overhead for us. Dec 23 17:37:26 lpapp: if you're applying patches with git am, you'll get a branch Dec 23 17:37:42 I would like to use patches just as before except the fact that I would like to be able to easily rebase them, hence git am. Dec 23 17:37:44 i'll re-phrase. why do you want to apply patches with "git am" instead of "git apply" in the WORKDIR Dec 23 17:37:56 okay Dec 23 17:37:58 rburton: cause you cannot rebase Dec 23 17:38:25 which can be a problem at >1 patch. Dec 23 17:38:36 which is quite common for the linux kernel from hardware vendors, I would say. :) Dec 23 17:38:50 which is why most people's kernel trees are maintained as branches Dec 23 17:39:05 no Dec 23 17:39:22 lpapp: so you'd unpack/patch, go into the workdir, rebase to a different tag, and re-generate the patch set? Dec 23 17:39:24 we *intend* to get closer to vanilla step by step, and I would like to be able to easily remove my patches one by one, and finally all of the, Dec 23 17:39:27 them Dec 23 17:39:29 I do not wanna maintain branches Dec 23 17:39:38 patches are fine as they have been for a couple of years in my career Dec 23 17:39:42 including the quilt time. Dec 23 17:39:47 dpatch, etc. Dec 23 17:40:08 lpapp: was my question about your workflow right? Dec 23 17:40:54 rburton: git rebase -i HEAD~X ... git format-patch HEAD~X --cover-letter --numbered -s -o patch-folder-next-to-the-recipe Dec 23 17:41:53 this would be the ideal development workflow for a kernel developer like me. Dec 23 17:42:03 currently, the missing bridge is the lacking git am .... Dec 23 17:42:09 I will take a look into it during christmas, I think. Dec 23 17:42:34 hopefully, it is easy to fix. Dec 23 17:43:18 lpapp: fwiw, the kernel developers i know do it the other way around. Dec 23 17:43:26 rburton: well, currently the workaround is as we had done before which I disliked: external 3.2.1 repository, creating the patches there and working there with them, but testing them within Yocto. Dec 23 17:43:56 because currently, it is impossibly hard to work and test patches within Yocto. Dec 23 17:44:22 rburton: so you have got a different personal taste then now. ;-) Dec 23 17:44:37 your experience is extended. Dec 23 17:45:32 for me, it is lotta easier to review the additions to the linux kernel, and update the vanilla version, and then the changes, etc. Dec 23 17:46:34 since this way I will keep vanilla history always as is, and I apply changes on top of it Dec 23 17:46:46 the other way around would result a mixed history with changes in-between. Dec 23 17:47:11 and it might be that upstreaming a change will happen in a different way Dec 23 17:47:17 and then your branch is not in sync anymore..... Dec 23 17:47:30 yeah, I really prefer patchset applied by quilt/dpatch/git am/etc. Dec 23 17:53:12 How Do I rectify this? Dec 23 17:53:42 DEBUG: Searching for source_mirror/sources/git2_github.com.raspberrypi.firmware.git.tar.gz in paths Dec 23 17:54:13 I know I don't have "git2_github.com.raspberrypi.firmware.git.tar.gz" in my source mirror Dec 23 17:54:30 a source mirror you maintain? Dec 23 17:55:15 ramose_: if so, set BB_GENERATE_MIRROR_TARBALLS="1" on the machine that writes to that download directory, and it will generate the tarballs when it fetches. Dec 23 17:55:17 It looks like an huge repo and I already have installed firmware-master.zip(134 MB) but Dec 23 17:55:37 ramose_: (so you'll probably need to force a fetch to re-generate it, or something) Dec 23 17:55:41 and yes, it's HUGE. Dec 23 17:55:57 beacause of limited interent bandwidh I can't download or clone git2_github.com.raspberrypi.firmware.git.tar.gz Dec 23 17:55:57 again Dec 23 17:56:12 1.4 git! Dec 23 17:56:19 gig even Dec 23 17:56:35 yes rburton :source mirror I am mainting Dec 23 17:56:37 *maintainig Dec 23 17:57:28 ramose_: maybe "bitbake rpi-firmware -c fetch" (replace recipe name with the right one) will be enough, from looking at the source Dec 23 17:57:42 ramose_: (on the machine that can write there, with BB_GENERATE_MIRROR_TARBALLS=1) Dec 23 17:58:44 but it will start fetching "git2_github.com.raspberrypi.firmware.git.tar.gz" which I can't afford as I have limited internet bandwidth Dec 23 17:59:12 *on the machine that writes to the mirror* Dec 23 17:59:31 My question is Can I use already downloaded firmware-master.zip Dec 23 17:59:31 ? Dec 23 17:59:33 so its not using a mirror, and will generate a tarball from the existing directory Dec 23 17:59:36 rburton: ok, well, I will look into this git apply, but I think having git am is reasonable. Dec 23 17:59:47 and as a fallback, it could try patch. Dec 23 17:59:57 ramose_: no idea, haven't done a rpi build for about a year Dec 23 18:00:05 if it is too much effort, I will develop outside Yocto, and test within Yocto, I guess. Dec 23 18:01:24 rburton: my worry about the vendor branch is the lack of decoupling. Dec 23 18:01:36 I would not know anymore clearly without much effort what is upstream and what not. Dec 23 18:01:45 it would be a mixed history without clear distinction like with a patchset. Dec 23 18:01:51 I like clear distinction. Dec 23 18:02:03 I do not think that is achieved by vendor branches. Dec 23 18:02:23 I mean easily, that is. Dec 23 18:02:32 rburton: this is done with linux source Dec 23 18:02:36 sure it can. where your branch diverges from upstream is where your stuff is. Dec 23 18:03:04 rburton: that is not as easy to see as with an enumerated patch set. Dec 23 18:03:16 moreover, it will be impossible to rebase without force push. Dec 23 18:03:24 which makes upstreaming changes later lotta harder. Dec 23 18:04:22 i'm not sure what force push to a private repo has to do with this, but whatever. kids are home and i'm officially off for christmas. Dec 23 18:04:49 --- a/recipes-kernel/linux/linux-raspberrypi_3.10.18.bb +++ b/recipes-kernel/linux/linux-raspberrypi_3.10.18.bb @@ -1,5 +1,5 @@ SRCREV = "b49aafd02fa7572d387acd34550beea5b4c3d239" -SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.10.y \ +SRC_URI = "file://linux-rpi-3.10.y.zip \ file://sl030raspberrypii2ckernel.patch \ Dec 23 18:04:53 ok, thanks, merry christmas. Dec 23 18:05:41 Sorry I don't know how to provide text editor link here Dec 23 18:08:19 rburton: I have modified the SRC_URI in kernel recipe to pick the downloaded .zip file instead of clone the linux.git Dec 23 18:08:47 but not sure how Can I do the same for firmware recipe Dec 23 18:14:30 rburton: I am afraid he is gone for the christmas holiday. Dec 23 18:14:40 ramose_: (sorry) Dec 23 20:49:25 hi there Dec 23 20:49:35 is there any Yocto variable giving me 'target' I compile for? Dec 23 20:51:34 I think it might be ${TARGET_ARCH} Dec 23 20:51:45 Xz: TARGET_ARCH, TARGET_SYS, MULTIMACH_TARGET_SYS Dec 23 20:51:52 depending on how detailed you want it... Dec 23 20:52:16 and ${S} is directory where I have all source files? Dec 23 20:52:22 yes Dec 23 20:52:26 for a recipe Dec 23 20:52:27 I just have unusual configure script Dec 23 20:52:38 have to figure out semi-manually how to execute it with correct flags Dec 23 20:53:07 oe_runconf appends whole set of flags, so doesn't work for me Dec 23 21:03:32 Xz: is this an autoconf-generated configure script or a hand-written one? Dec 23 21:03:56 bluelightning: it's defo hand-written Dec 23 21:04:14 bluelightning: it comes from 'bitlbee' - I'm trying to create recipe for that Dec 23 21:04:27 Xz: right, in that case you should not inherit autotools if you currently are Dec 23 21:04:44 bluelightning: yes, I am Dec 23 21:04:54 bluelightning: so I should write my own do_configure and do_compile? Dec 23 21:05:37 Xz: you'll need to define do_configure and do_install... there is a do_compile defined by base.bbclass so you don't necessarily have to define that Dec 23 21:06:32 Xz: FYI, there is an old OE-Classic recipe here if it helps: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/bitlbee/bitlbee_1.0.4.bb Dec 23 21:06:49 bluelightning: cool, didn't find it Dec 23 21:06:54 bluelightning: actual version is 3.2.1 Dec 23 21:07:43 Xz: FYI you can search OE-Classic in the layer index by going to Recipes and then dropping down the branch selector and selecting OE-Classic Dec 23 21:08:06 OE-Classic is not maintained anymore? That's my understanding Dec 23 21:09:31 it's not, no... but it's sometimes useful to resurrect recipes from there, so we index it (separately) Dec 23 21:12:52 bluelightning: I already have 'irssi' - ncurses IRC client Dec 23 21:13:29 bluelightning: now just need bitlbee to connect that to facebook chat and others Dec 23 21:13:44 bluelightning: gonna place that next to my router, up and running 24/7 Dec 23 21:14:02 nice :) Dec 23 21:14:26 bluelightning: didn't find anywhere irssi recipe, but that one was easier to create Dec 23 21:14:48 bluelightning: I might send that to openembedded-core Dec 23 21:14:54 bluelightning: or openembedded-devel Dec 23 21:15:23 we definitely had irssi recipes in OE-Classic Dec 23 21:15:55 right, it's probably something for meta-oe Dec 23 21:15:56 that would be much appreciated btw :) Dec 23 21:16:09 bluelightning: cool Dec 23 21:16:16 bluelightning: however I always have a problem - where to put it Dec 23 21:16:43 bluelightning: 1st - poky/meta-oe, 2nd which directory: recipes-extended? recipes-xyz Dec 23 21:17:28 meta-oe/recipes-connectivity for these two I thin Dec 23 21:17:28 think Dec 23 21:17:34 we do have a meta-networking, but I'm not sure IRC/IM-related stuff really fits there Dec 23 21:18:19 bluelightning: ok, once I have that ready - I will try to send a patch (recipes-connectivity) and see what happens Dec 23 21:52:55 in oe-classic's version of bitlbee there is one step: pkg_postinst. Is there any matching step in current Yocto? Dec 23 21:53:23 I got it compiling, will give it a go on board soon :) Dec 23 21:53:39 just curious about that pkg_postinst step Dec 23 21:59:19 Xz: that is still supported - it's a postinstall script to be run just after the package is installed (or at image creation time if it's part of an image) Dec 23 21:59:29 Xz: you should suffix it with _${PN} though so it's only applied to the main package Dec 23 22:00:03 Xz: also use $D (_not_ ${D}) before all paths so that the script can run at image creation time if it needs to **** ENDING LOGGING AT Tue Dec 24 03:00:00 2013