| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has left #yocto | 00:26 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 00:26 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 01:09 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 01:21 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:26 | |
| *** silviof4 <silviof4!~silviof@ppp-188-174-103-76.dynamic.mnet-online.de> has joined #yocto | 03:01 | |
| *** silviof3 <silviof3!~silviof@ppp-93-104-160-163.dynamic.mnet-online.de> has quit IRC | 03:01 | |
| *** swex <swex!~swex@178.132.102.71> has joined #yocto | 03:14 | |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has quit IRC | 03:38 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 04:28 | |
| *** linu1 <linu1!~linu1@122.165.223.135> has joined #yocto | 04:34 | |
| linu1 | 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 | 04:37 |
|---|---|---|
| *** emacer <emacer!~EMAC@66.186.100.194> has quit IRC | 04:37 | |
| *** sunfunbaby <sunfunbaby!~Thunderbi@osatek.hosting.proxy.ru> has joined #yocto | 04:55 | |
| *** sunfunbaby <sunfunbaby!~Thunderbi@osatek.hosting.proxy.ru> has quit IRC | 05:08 | |
| *** linu1 <linu1!~linu1@122.165.223.135> has quit IRC | 05:31 | |
| *** linu1 <linu1!~linu1@122.165.223.135> has joined #yocto | 05:32 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 06:01 | |
| *** GusBricker <GusBricker!~GusBricke@CPE-120-148-198-99.heum1.vic.bigpond.net.au> has quit IRC | 06:06 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 06:17 | |
| *** behanw <behanw!~behanw@184.66.17.46> has quit IRC | 06:25 | |
| *** GusBricker <GusBricker!~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au> has joined #yocto | 06:41 | |
| *** fusman <fusman!~fahad@110.93.212.98> has joined #yocto | 06:46 | |
| *** beaver_545 <beaver_545!~stuart@host86-144-236-78.range86-144.btcentralplus.com> has joined #yocto | 06:50 | |
| *** GusBricker <GusBricker!~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au> has quit IRC | 07:05 | |
| *** bjrj <bjrj!75ca1db7@gateway/web/freenode/ip.117.202.29.183> has joined #yocto | 07:07 | |
| bjrj | hi | 07:10 |
| *** bjrj <bjrj!75ca1db7@gateway/web/freenode/ip.117.202.29.183> has quit IRC | 07:12 | |
| *** nitink <nitink!nitink@nat/intel/x-qxxrynppctlvfolh> has quit IRC | 07:12 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 07:30 | |
| *** n01 <n01!~n01@host148-255-dynamic.47-79-r.retail.telecomitalia.it> has joined #yocto | 07:34 | |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPE4494fc36228b-CMbcc810032faf.cpe.net.cable.rogers.com> has quit IRC | 07:45 | |
| *** beaver_545 <beaver_545!~stuart@host86-144-236-78.range86-144.btcentralplus.com> has quit IRC | 07:55 | |
| *** fpaut_ is now known as fpaut | 08:08 | |
| *** ant_work <ant_work!~Andrea@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 08:26 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 08:28 | |
| *** zeeblex <zeeblex!~apalalax@134.134.137.71> has joined #yocto | 08:31 | |
| *** ddalex <ddalex!~ddalex@80.97.15.150> has joined #yocto | 08:31 | |
| *** dv__ <dv__!~quassel@chello080108009040.14.11.vie.surfer.at> has joined #yocto | 08:36 | |
| *** dv <dv!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC | 08:37 | |
| *** zeeblex <zeeblex!~apalalax@134.134.137.71> has quit IRC | 08:46 | |
| *** ddalex <ddalex!~ddalex@80.97.15.150> has quit IRC | 08:47 | |
| *** agust <agust!~agust@p4FDE606F.dip0.t-ipconnect.de> has joined #yocto | 08:54 | |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-qmnmmjkqwpzafxcf> has joined #yocto | 08:58 | |
| *** beaver_545 <beaver_545!~stuart@82.148.40.66> has joined #yocto | 09:01 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 09:44 | |
| *** belen <belen!~Adium@134.134.139.72> has joined #yocto | 09:48 | |
| *** SorenHolm <SorenHolm!~quassel@5634f347.rev.stofanet.dk> has joined #yocto | 09:53 | |
| *** erbo <erbo!~erik@host.62.65.125.245.bitcom.se> has quit IRC | 09:54 | |
| *** erbo <erbo!~erik@host.62.65.125.245.bitcom.se> has joined #yocto | 10:02 | |
| *** henriknj <henriknj!~hnj@henriknj.dk> has quit IRC | 10:07 | |
| *** cristianiorga <cristianiorga!~cristiani@134.134.137.71> has joined #yocto | 10:10 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 10:34 | |
| lpapp | 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" | 10:34 |
| lpapp | I would like to aid the linux kernel development with Yocto in my layer. | 10:34 |
| rburton | i *think* linux-yocto needs a bare clone because of how it's configured, using multiple branches in the repo. | 10:35 |
| lpapp | rburton: what exactly do you mean? | 10:36 |
| lpapp | What will be the expected impact if I remove it? | 10:36 |
| rburton | potentially just a waste of disk space/time, but i think the build for linux-yocto checks out multiple branches | 10:37 |
| rburton | but if you're not using linux-yocto that isn't a concern | 10:38 |
| *** ScriptRipper1 <ScriptRipper1!~ScriptRip@178-26-43-81-dynip.superkabel.de> has quit IRC | 10:40 | |
| lpapp | rburton: I am using a copy of it from denzil. | 10:43 |
| lpapp | with which it is extremely painful to do kernel development. | 10:43 |
| lpapp | so I am trying to switch to git, but then again, bareclone is a blocker for that. | 10:43 |
| lpapp | 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. | 10:43 |
| rburton | lpapp: have you read the yocto kernel development manual? | 10:44 |
| lpapp | yes, a few times. | 10:44 |
| lpapp | lemme re-read it. | 10:46 |
| *** SorenHolm <SorenHolm!~quassel@5634f347.rev.stofanet.dk> has quit IRC | 10:47 | |
| rburton | 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 | 10:47 |
| rburton | or, don't use linux-yocto, and then the bareclone this isn't an issue. | 10:48 |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPE4494fc36228b-CMbcc810032faf.cpe.net.cable.rogers.com> has joined #yocto | 10:48 | |
| *** dany <dany!~Thunderbi@178.28.80.165> has joined #yocto | 10:51 | |
| lpapp | rburton: as I said, I am not using Yocto's git clone. | 10:53 |
| lpapp | I am using my layer's git clone. | 10:53 |
| *** ScriptRipper1 <ScriptRipper1!~ScriptRip@178-26-51-16-dynip.superkabel.de> has joined #yocto | 10:54 | |
| *** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto | 11:10 | |
| *** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC | 11:13 | |
| *** belen <belen!~Adium@134.134.139.72> has quit IRC | 11:15 | |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPE4494fc36228b-CMbcc810032faf.cpe.net.cable.rogers.com> has quit IRC | 11:18 | |
| *** dv__ is now known as dv_ | 11:25 | |
| RP | 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 | 11:29 |
| *** panda84kde <panda84kde!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has joined #yocto | 11:30 | |
| RP | 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? | 11:30 |
| lpapp | RP: what tools? I do not need two branches. | 11:35 |
| rburton | lpapp: so you're not using linux-yocto, so you don't need the bare clone. | 11:36 |
| RP | lpapp: right, so don't use linux-yocto then | 11:36 |
| lpapp | 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. | 11:36 |
| lpapp | I do use means, the recipe is pretty much cloned. | 11:36 |
| lpapp | including the .inc file. | 11:36 |
| lpapp | RP: well, it is not so simple. | 11:37 |
| lpapp | writing a linux kernel recipe seems to be a lot of effort based on the length of the linux-yocto recipe files. | 11:37 |
| lpapp | so, I would not definitely like to start it from scratch; rather, I would customize the cloned linux-yocto for my own needs. | 11:38 |
| lpapp | so which tools exactly, and what do I need to remove to get rid of the multi-branches? | 11:38 |
| lpapp | anyway, why is it using multiple branches/ | 11:38 |
| rburton | one for kernel source, one for the configuration metadata | 11:38 |
| lpapp | why not provide only the latest recipe? | 11:38 |
| RP | lpapp: which parts of linux-yocto do you want? Do you want defconfig fragment support for example? | 11:38 |
| lpapp | rburton: what does configuration metadata mean? | 11:38 |
| rburton | the config fragments which are used to assemble the configuration are stored in the "meta" branch | 11:39 |
| lpapp | RP: I think so because I have custom kernel drivers, so I would like to enable them. | 11:39 |
| lpapp | unless there is a simple way to do that without a yet another branch. | 11:39 |
| RP | lpapp: What I mean is are you happy to use a full defconfig file or are you after the fragment support? | 11:39 |
| RP | lpapp: also, are you after any of the config fragment features or the patches in linux-yocto? | 11:40 |
| lpapp | RP: currently, I am using the defconfig, and I am happy with it. | 11:40 |
| lpapp | bitbake -c menuconfig virtual/kernel -> I edit and save it. | 11:40 |
| lpapp | then I copy .config to defconfig | 11:40 |
| RP | lpapp: right, then don't use linux-yocto then | 11:40 |
| RP | lpapp: find an example of a simpler kernel from another layer | 11:41 |
| lpapp | do you have any suggestion? | 11:41 |
| RP | lpapp: something like http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux-mainline_3.2.bb | 11:41 |
| lpapp | but anyway, does that mean linux-yocto sacrificies the kernel development within Yocto for having config fragments? | 11:41 |
| RP | lpapp: that shows a mainline kernel, a set of patches and a defconfig | 11:42 |
| RP | lpapp: obviously you can put your own patches in, or none at all | 11:42 |
| RP | 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 | 11:43 |
| rburton | 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. | 11:43 |
| RP | lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux_3.3.7.bb is an even simpler example | 11:43 |
| lpapp | well, what I would prefer is: | 11:44 |
| lpapp | bitbake virtual/kernel | 11:44 |
| lpapp | then it builds stuff | 11:44 |
| lpapp | I test the rootfs containing the kernel | 11:44 |
| lpapp | I find a bug, I fix it within Yocto, inside the work folder. | 11:44 |
| lpapp | 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. | 11:45 |
| lpapp | that is the use case I would like to have. | 11:45 |
| RP | lpapp: start with one of the simpler kernel recipes above and you can do that just fine there | 11:45 |
| RP | lpapp: once you understand and have that working you can think about linux-yocto if it makes sense | 11:46 |
| lpapp | well, we already linux-yocto | 11:46 |
| lpapp | migrating would be quite a bit of work, so I do not feel comfortable with it. | 11:46 |
| lpapp | already havE* | 11:46 |
| RP | 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 | 11:47 |
| RP | 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 | 11:48 |
| *** fpaut is now known as fpaut_ | 11:48 | |
| ant_work | 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 | 11:48 |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has joined #yocto | 11:49 | |
| lpapp | ant_work: not really, no. | 11:49 |
| ant_work | lpapp: yes, I do that ;) | 11:49 |
| lpapp | ant_work: bitbake can handle diff files just fine. | 11:49 |
| lpapp | ant_work: looks for patches. Most of them are not git patch, really. | 11:49 |
| lpapp | you do not need to commit to get a diff. | 11:49 |
| ant_work | yo do need to commit to get a patch | 11:49 |
| lpapp | (but this is not the major point anyway) | 11:49 |
| lpapp | no | 11:50 |
| lpapp | git diff > stuff.patch | 11:50 |
| lpapp | job done | 11:50 |
| *** fpaut_ is now known as fpaut | 11:50 | |
| ant_work | in the bitbake framework, you need a patch to add the kernel patch | 11:50 |
| lpapp | git diff > stuff.patch and you have the patch. What is the problem? | 11:50 |
| lpapp | RP: I disagree. | 11:51 |
| lpapp | at the very least - since I expect it to be common - there could be some examples and/or skeleton. | 11:51 |
| rburton | lpapp: an even better workflow using linux-yocto doesn't involve patches at all, like i pointed you at. | 11:51 |
| lpapp | rburton: well, I have not had time yet to understand every comment fully yet. | 11:52 |
| lpapp | I am still just at reading the kernel development manual (first suggestion) | 11:52 |
| ant_work | lpapp: try 'git-format-patch master' in the linux-yocto workdir, in the kernel dir | 11:52 |
| rburton | lpapp: if you're not going to use linux-yocto, then stop reading the manual for it. | 11:52 |
| ant_work | heh | 11:53 |
| lpapp | ant_work: why would I? | 11:53 |
| lpapp | I was happy with git diff, that is not an issue for me. | 11:53 |
| lpapp | rburton: I have no clue just yet what I will use, so I have to go through everything, and then make an educated decision. | 11:54 |
| lpapp | ant_work: moreover, currently, I do not use git based linux-yocto | 11:57 |
| lpapp | I am still stuck with the old tarball based denzil. | 11:57 |
| lpapp | (but that is the very first thing to fix since it is very hard to work that way with sources within Yocto) | 11:59 |
| lpapp | what is the point of config fragments anyway? | 12:03 |
| lpapp | 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. | 12:03 |
| 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 | 12:04 |
| rburton | lpapp: config fragments are very useful when you maintain more than one machine | 12:04 |
| lpapp | why ? | 12:05 |
| lpapp | bitbake -c menuconfig arm virtual/kernel | 12:05 |
| rburton | because you can separate common things from machine-specific things. | 12:06 |
| lpapp | the syntax could be something like that. I would prefer that over a brand new concept. | 12:06 |
| rburton | remember that nobody is making you use linux-yocto | 12:06 |
| lpapp | sure, but I think it should still be comfortable and handy. ;} | 12:06 |
| *** panda84kde <panda84kde!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has quit IRC | 12:06 | |
| *** panda84kde <panda84kde!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has joined #yocto | 12:07 | |
| *** henriknj <henriknj!~hnj@henriknj.dk> has joined #yocto | 12:07 | |
| lpapp | so why exactly do we need config fragments as opposed to a option for the bitbake command? | 12:07 |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has quit IRC | 12:07 | |
| lpapp | s/a/an/ | 12:07 |
| rburton | because you can separate common configuration from machine-specific configuration | 12:08 |
| lpapp | so could you with an option. | 12:08 |
| rburton | fine | 12:08 |
| lpapp | and the rest would be transparent for the end user. | 12:08 |
| lpapp | $ diff -Nurp config.orig .config | sed -n "s/^\+//p" > frag.cfg | 12:12 |
| lpapp | erm? Really? Isn't there a nicer way (i.e. less plumber)? :] | 12:12 |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has joined #yocto | 12:14 | |
| *** jdvdt <jdvdt!~joshua@rrcs-24-97-209-160.nys.biz.rr.com> has joined #yocto | 12:19 | |
| lpapp | is there a feature request to make it handier? | 12:24 |
| *** cristianiorga <cristianiorga!~cristiani@134.134.137.71> has quit IRC | 12:27 | |
| *** cristianiorga <cristianiorga!cristianio@nat/intel/x-fqrsynewxjvhmqja> has joined #yocto | 12:28 | |
| lpapp | 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. | 12:30 |
| *** ddalex <ddalex!~ddalex@80.97.15.150> has joined #yocto | 12:30 | |
| lpapp | SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v3.0/linux-${PV}.tar.bz2;name=kernel \ | 12:30 |
| lpapp | it even eventually does fetch the released tarball here. | 12:30 |
| *** jdvdt <jdvdt!~joshua@rrcs-24-97-209-160.nys.biz.rr.com> has left #yocto | 12:32 | |
| *** SorenHolm <SorenHolm!~quassel@5634f347.rev.stofanet.dk> has joined #yocto | 12:32 | |
| rburton | lpapp: have a look at the URI i sent you and compare with what you have. | 12:32 |
| *** fpaut is now known as fpaut_ | 12:33 | |
| lpapp | rburton: perhaps it was added post-denzil. | 12:35 |
| lpapp | i.e. in a bugfix release. | 12:35 |
| rburton | lpapp: nope. | 12:35 |
| *** fpaut_ is now known as fpaut | 12:35 | |
| lpapp | rburton: well, then we apparently modified it silently. | 12:38 |
| rburton | lpapp: suspected as much | 12:38 |
| lpapp | (i.e. without mentioning it to me) | 12:39 |
| lpapp | or it predates my time, etc. | 12:39 |
| rburton | you need to run a diff between your tree and poky, and move out any changes so you don't get confused. | 12:40 |
| lpapp | well, the linux-yocto recipe and the .inc are pretty complex. | 12:40 |
| rburton | yeah, but if its building from a tarball, it's very much not linux-yocto | 12:41 |
| lpapp | I think it is except the SRC_URI | 12:43 |
| lpapp | since we have the same files with pretty much the same complexity level to me. | 12:43 |
| lpapp | btw, is there any point in linux-yocto when you need to support only one board type? | 12:43 |
| rburton | lpapp: the argument is a lot harder then | 12:44 |
| lpapp | rburton: what argument? :) | 12:44 |
| rburton | the fragments argument | 12:45 |
| lpapp | I am not sure I can follow. | 12:45 |
| lpapp | what exactly is harder? Can you give a use case? | 12:46 |
| rburton | 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 | 12:46 |
| lpapp | ok, thanks. | 12:47 |
| *** dany <dany!~Thunderbi@178.28.80.165> has quit IRC | 12:52 | |
| lpapp | rburton: http://pastebin.kde.org/ptmsc1yrl -> this is our linux-foo.inc | 12:59 |
| *** GusBricker <GusBricker!~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au> has joined #yocto | 12:59 | |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-qmnmmjkqwpzafxcf> has left #yocto | 12:59 | |
| *** dany <dany!~Thunderbi@c-b21c5328-74736162.cust.telenor.se> has joined #yocto | 13:02 | |
| lpapp | rburton: and this is the versioned linux kernel recipe, http://pastebin.kde.org/piuoelimx | 13:04 |
| lpapp | is it ok that the .inc file seems to be commented out? | 13:04 |
| *** SorenHolm <SorenHolm!~quassel@5634f347.rev.stofanet.dk> has quit IRC | 13:06 | |
| rburton | "page does not exist" | 13:06 |
| lpapp | hmm, bizarr bug. | 13:08 |
| lpapp | rburton: http://pastebin.kde.org/pmo1tdsl2 | 13:08 |
| *** bluelightning <bluelightning!~paul@p57B12D74.dip0.t-ipconnect.de> has joined #yocto | 13:12 | |
| *** bluelightning <bluelightning!~paul@p57B12D74.dip0.t-ipconnect.de> has quit IRC | 13:12 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 13:12 | |
| rburton | "page you are looking for does not exist" | 13:13 |
| lpapp | very odd since this time I even confirmed it. | 13:13 |
| lpapp | and I put it up for 30 minutes | 13:13 |
| lpapp | rburton: http://pastebin.kde.org/pqxsupmgz | 13:14 |
| rburton | that works | 13:14 |
| lpapp | I selected 6 hours this time. | 13:14 |
| rburton | yes, that require is commented out | 13:15 |
| rburton | so its not used | 13:15 |
| lpapp | yeah; is that bad? | 13:15 |
| lpapp | KERNEL_IMAGETYPE = "uImage" | 13:15 |
| lpapp | FILES_kernel-image = "/boot/uImage*" | 13:15 |
| lpapp | I do not understand that either. | 13:15 |
| lpapp | IMO, the second line does not make any sense.... | 13:15 |
| rburton | i have no idea what's in that .inc, so i can't comment | 13:16 |
| lpapp | since that is the default expansion for the image type set.... | 13:16 |
| rburton | yep | 13:16 |
| *** belen <belen!Adium@nat/intel/x-sjwpgcnahikoihxq> has joined #yocto | 13:18 | |
| *** fusman <fusman!~fahad@110.93.212.98> has quit IRC | 13:20 | |
| *** fusman <fusman!~fahad@110.93.212.98> has joined #yocto | 13:21 | |
| *** reallife <reallife!~reallife@ool-4b7ff55a.static.optonline.net> has joined #yocto | 13:22 | |
| *** zarul <zarul!~zarul@ubuntu/member/zarul> has quit IRC | 13:25 | |
| *** zarul <zarul!~zarul@ubuntu/member/zarul> has joined #yocto | 13:26 | |
| lpapp | is it ./meta/classes/kernel-yocto.bbclass responsible for the fragment feature? | 13:27 |
| rburton | looks like it's got at least some of the logic. no idea if that's all of it. | 13:28 |
| rburton | i suspect it's the bulk of it, yes. | 13:28 |
| lpapp | I guess removing that inheritance along with the bareclone stuff may actually work. | 13:30 |
| rburton | the recipe you pointed me at just uses inherit kernel, so just changing that tarball src_uri to a git repo will work, yes. | 13:31 |
| lpapp | rburton: no, I am considering being closer to linux-yocto | 13:31 |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto | 13:31 | |
| lpapp | rburton: i.e. including dtb and inheriting the kernel class as well. | 13:31 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 13:38 | |
| *** ramose <ramose!3df7fee2@gateway/web/freenode/ip.61.247.254.226> has joined #yocto | 13:50 | |
| ramose | How to set up mirros to fetch the source in yocto | 13:50 |
| *** JDuke128 <JDuke128!~textual@178.233.48.89> has joined #yocto | 13:53 | |
| bluelightning | ramose: maybe this will help: https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F | 13:55 |
| ramose | Thanks bluelightning ,I guess I have have to use premirrors my self because I wanted to set more than one mirror | 13:58 |
| lpapp | rburton: at least, it would be lovely if the fragments could be that well modularized. | 14:00 |
| ramose | bluelightning would you like to tell me that use of BB_NO_NETWORK = "1"? | 14:03 |
| bluelightning | ramose: BB_NO_NETWORK tells bitbake not to download anything from the network | 14:04 |
| *** JDuke128 <JDuke128!~textual@178.233.48.89> has quit IRC | 14:04 | |
| ramose | So I should not use it unless I Downloaded all tar balls before bitbake,right? | 14:05 |
| *** dany <dany!~Thunderbi@c-b21c5328-74736162.cust.telenor.se> has quit IRC | 14:06 | |
| ramose | Can I restrict use of BB_NO_NETWORK = "1" to specific recipe? | 14:06 |
| lpapp | 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" | 14:06 |
| *** GusBricker <GusBricker!~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au> has quit IRC | 14:06 | |
| *** dany <dany!~Thunderbi@c-b21c5328-74736162.cust.telenor.se> has joined #yocto | 14:07 | |
| lpapp | rburton: i.e. I do not know how to change the SRC_URI from tarball to git. :/ | 14:09 |
| rburton | git://some-git-uri;protocol=(http|git);branch=(branchname) | 14:10 |
| lpapp | but that is not in line with the linux-yocto stuff. | 14:10 |
| lpapp | I would like to keep it as close as possible. | 14:10 |
| rburton | the one you pasted just adds more variables | 14:11 |
| rburton | you don't want bareclone | 14:11 |
| rburton | you don't need name | 14:11 |
| lpapp | rburton: well, I do not know how KBRANCH = "standard/default/base" gets to 3.2.1, for instance | 14:11 |
| lpapp | in linux-yocto_3.2.bb | 14:11 |
| rburton | it doesn't | 14:12 |
| lpapp | or 3.2.X, whatever. | 14:12 |
| rburton | that's a branch name | 14:12 |
| lpapp | and the branch name should have the version information | 14:12 |
| lpapp | unless they only tag it. | 14:12 |
| rburton | https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.10/ | 14:12 |
| lpapp | right, so only tags. | 14:12 |
| rburton | the exact version is specified elsewhere, where it says what hash to grab | 14:12 |
| rburton | no, branches. | 14:12 |
| lpapp | but how is that passed in Yocto? | 14:12 |
| lpapp | no, tags. | 14:13 |
| lpapp | check "git tag -l" | 14:13 |
| lpapp | (in the linux kernel) | 14:13 |
| lpapp | and then check git branch -a | 14:13 |
| rburton | i mean standard/default/base is a branch | 14:13 |
| lpapp | well, that is not enough | 14:13 |
| lpapp | you need to check out the tag, not the branch, really. | 14:13 |
| rburton | i'm just telling you what you wanted to know | 14:13 |
| lpapp | to get a certain version desired. | 14:13 |
| lpapp | ok, perhaps I am already beyond the understanding of that. | 14:14 |
| lpapp | currently, I do not understand how the right versioned tag is checked out | 14:14 |
| rburton | its not! | 14:14 |
| lpapp | I guess I would need to check the implementation of the kernel class | 14:14 |
| lpapp | well, it should be. | 14:14 |
| rburton | there is a SRCREV specified in the recipe | 14:14 |
| lpapp | I want to get 3.2.X for instance. | 14:14 |
| lpapp | huh | 14:14 |
| rburton | that revision is checked out | 14:14 |
| lpapp | that is dirty, isn't it? | 14:14 |
| rburton | (for linux-yocto) | 14:14 |
| rburton | no, its precise | 14:14 |
| lpapp | how come? | 14:14 |
| lpapp | You already have the version information, and the linux kernel does have handy version tags | 14:15 |
| rburton | because its very rare to ship a pristine kernel release | 14:15 |
| lpapp | so an sha is an unnecessary complication. | 14:15 |
| lpapp | I disagree. | 14:15 |
| lpapp | I rather think that people ship released and well tested stuff as opposed to random shas. | 14:15 |
| *** swex <swex!~swex@178.132.102.71> has quit IRC | 14:17 | |
| ramose | bluelightning: Woulld you like to address my doubts regarding use of BB_NO_NETWORK = "1" | 14:17 |
| bluelightning | ramose: I think you can restrict it to an individual recipe yes | 14:18 |
| bluelightning | I never tried that though | 14:18 |
| ramose | ok | 14:19 |
| *** sroy <sroy!~sroy@mtl.savoirfairelinux.net> has joined #yocto | 14:25 | |
| lpapp | rburton: perhaps, there could be an option for the Linux stuff to disable the fragment stuff in a custom layer? | 14:26 |
| lpapp | without cloning and reinventing all the stuff? | 14:26 |
| rburton | lpapp: isn't that what kernel.bbclass is? | 14:29 |
| rburton | all of linux-yocto.bbclass is about the fragments and machine branches, so just don't use linux-yocto | 14:30 |
| *** JDuke128 <JDuke128!~textual@178.233.48.89> has joined #yocto | 14:31 | |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has left #yocto | 14:33 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 14:33 | |
| lpapp | rburton: you mean linux-yocto.inc rather than kernel.bbclass and linux-yocto.bbclass? | 14:41 |
| *** JDuke128 <JDuke128!~textual@178.233.48.89> has quit IRC | 14:43 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 14:46 | |
| lpapp | rburton: oh, wow, SRCREV can also be a tag name! | 14:55 |
| lpapp | not just com | 14:55 |
| lpapp | mit hash... that is lovely, isn't it | 14:55 |
| JaMa | no it isn't | 14:58 |
| JaMa | because then it will always run git ls-remote to map tag name to SHA-1 | 14:59 |
| lpapp | JaMa: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux_3.3.7.bb#n20 | 15:00 |
| rburton | sure, you *can* | 15:00 |
| rburton | it's just a bad idea | 15:00 |
| rburton | it forces a remote git operation every build (parse? can't recall) | 15:01 |
| *** dany <dany!~Thunderbi@c-b21c5328-74736162.cust.telenor.se> has quit IRC | 15:01 | |
| JaMa | lpapp: no it isn't was about "lovely" :) | 15:01 |
| JaMa | rburton: parse | 15:01 |
| rburton | double-ouch | 15:01 |
| lpapp | JaMa: that is alright. I do not feel bad about it. | 15:01 |
| lpapp | compared to the recipe maintenance effort. | 15:01 |
| JaMa | we had a lot of them in webOS (not in SRCREV but in tag=foo) | 15:02 |
| JaMa | I've finally got rid of them all lately (replaced with sanity check *after* the fetch) | 15:02 |
| lpapp | I guess we will need to agree to disagree. :) | 15:02 |
| rburton | lpapp: consider this background on why many layers use hashes instead of tag names | 15:02 |
| lpapp | rburton: because Yocto is bad IMHO | 15:03 |
| lpapp | it should help with proper maintenance. | 15:03 |
| rburton | lpapp: two reasons you can't argue with: 1) performance 2) reproducable | 15:03 |
| rburton | using a tag name means a network operation, and means the source can change without the recipe changing. | 15:03 |
| lpapp | 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. | 15:03 |
| rburton | yeah, can't deny that, and nobody did | 15:03 |
| rburton | just giving you reasons why many layers don't use tag names, but hashes. | 15:04 |
| JaMa | better to get right SHA-1 once by recipe maintainer, than every builder getting it with ls-remote in every parse :) | 15:04 |
| lpapp | it is not like you fetch that often after all. | 15:04 |
| lpapp | more precisely, you would not fetch at all if it is checked in properly. | 15:04 |
| JaMa | especially useful when building some private stuff just from prepopulated downloads/PREMIRROR without current access to remote git repos | 15:05 |
| ramose | 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?? | 15:05 |
| JaMa | lpapp: you won't run do_fetch, but you'll *always* get git ls-remote to map that tag name to SHA | 15:05 |
| lpapp | JaMa: fix yocto. | 15:05 |
| lpapp | it should be able to cache it of course. | 15:06 |
| JaMa | 16:03:53 < rburton> lpapp: two reasons you can't argue with: 1) performance 2) reproducable | 15:06 |
| JaMa | it cannot fetch it because of 2) | 15:06 |
| lpapp | 1) is a bug in Yocto | 15:06 |
| lpapp | I do not understand what 2) means. | 15:06 |
| JaMa | NO | 15:06 |
| rburton | tags are not immutable in git. | 15:06 |
| rburton | -> they can change | 15:07 |
| lpapp | rburton: sure, they are in any sane project. :) | 15:07 |
| JaMa | you cannot ever know if tag=foo is still the same source | 15:07 |
| JaMa | and if you have multiple builders all building tag=foo at different time they could get different source | 15:07 |
| rburton | or want to do a new build to make a point release of that product you shipped a year ago | 15:07 |
| rburton | and a tag moved, and it won't build anymore | 15:07 |
| rburton | that said feel free to use tag names if you prefer it | 15:08 |
| rburton | but these are the reason why we generally don't | 15:08 |
| lpapp | as I said, software developers can screw up, but sane people do not. | 15:08 |
| lpapp | but that is true for anything, so I do not think something has to defend against overly silly things which usually almost never happens. | 15:08 |
| lpapp | happen.* | 15:08 |
| lpapp | to me, it sounds like over-engineering. :) | 15:09 |
| JaMa | it was happening quite often in my experience | 15:09 |
| lpapp | in that case, you would use a tarball anyway | 15:10 |
| lpapp | not to get broken. | 15:10 |
| lpapp | but then again, I have never really met such insane devs and release guys. :) | 15:10 |
| JaMa | 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 | 15:10 |
| lpapp | so for me 2) is not valid, and 1) is a Yocto bug respectively. | 15:11 |
| lpapp | it *should* give an option to me if I want to cache for simple maintenance. | 15:11 |
| JaMa | git show-ref tag-name is *simple* | 15:12 |
| lpapp | no, it is not. | 15:12 |
| lpapp | compare the two: | 15:12 |
| lpapp | 1) 3.1.2 -> 3.1.3 done | 15:12 |
| lpapp | 1) Find where to clone from | 15:12 |
| lpapp | 2) Clone | 15:12 |
| lpapp | 3) run the command | 15:12 |
| lpapp | 4) remove | 15:12 |
| lpapp | many unnecessary extra steps. | 15:13 |
| JaMa | you can skip 2-4 if you're clever | 15:13 |
| lpapp | the point of the maintenance of not requiring clever tricks | 15:13 |
| lpapp | i.e. easily maintenable. | 15:13 |
| lpapp | s/of not/ is not/ | 15:14 |
| JaMa | cd downloads/git2/*component; git remote update; git show-ref 3.1.3 | 15:14 |
| lpapp | I have no idea how that works | 15:14 |
| lpapp | and I would spend hours to figure out | 15:14 |
| lpapp | compared to 3.1.2 to 3.1.3 which is literally a couple of seconds. | 15:14 |
| rburton | neither of which compare to the minutes this has been discussed | 15:15 |
| rburton | for no reason at all | 15:15 |
| lpapp | FR is being submitted... | 15:16 |
| rburton | lpapp: don't even bother | 15:16 |
| lpapp | rburton: you wrote that for many features and reports in the past which got fixed, so no worries. | 15:17 |
| lpapp | (i.e. it is possible that others think differently than you) | 15:18 |
| lpapp | I see no reason for aiding end users for no real cost. | 15:19 |
| lpapp | declining to aid | 15:19 |
| JaMa | because we both already explained why oe-core shouldn't do it | 15:20 |
| lpapp | 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. | 15:20 |
| lpapp | I see no reason for blocking people having simpler life. | 15:20 |
| lpapp | if you do not want to use that feature, you will not use it, it is that simple. | 15:21 |
| lpapp | it would not be obligatory after all. | 15:21 |
| ramose | any one ppoint me out how should I test the PAM module support | 15:21 |
| *** ddalex <ddalex!~ddalex@80.97.15.150> has quit IRC | 15:21 | |
| ramose | 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?? | 15:21 |
| *** Kangkai <Kangkai!~kai@58.32.203.134> has joined #yocto | 15:22 | |
| *** Kangkai_ <Kangkai_!~kai@58.32.203.134> has quit IRC | 15:25 | |
| *** n01 <n01!~n01@host148-255-dynamic.47-79-r.retail.telecomitalia.it> has quit IRC | 15:25 | |
| *** n01 <n01!~n01@host73-19-dynamic.47-79-r.retail.telecomitalia.it> has joined #yocto | 15:27 | |
| *** sroy <sroy!~sroy@mtl.savoirfairelinux.net> has quit IRC | 15:35 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC | 15:41 | |
| *** sroy <sroy!~sroy@ip-208-88-110-45.savoirfairelinux.net> has joined #yocto | 15:50 | |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has quit IRC | 15:50 | |
| lpapp | 0: linux-foo-3.2.1-b+gitrv3.2.1 do_fetch (pid 2206) | 15:51 |
| lpapp | it got stuck here.... it has been about twenty minutes now.... any idea what is going on? | 15:51 |
| rburton | a slow git clone? do a ps and see if there's a git process running | 15:53 |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto | 15:53 | |
| rburton | ramose: chek it's installed by looking in the file system | 15:53 |
| lpapp | rburton: I cannot run ps unfortunately. | 15:53 |
| WarheadsSE | anyone have any thought on why when I build (and install) rsync, it doesn't end up in *any* of the sysroots? | 15:54 |
| WarheadsSE | man ends up in target, but no binary.. | 15:54 |
| lpapp | rburton: should I check some log instead or monitor the size of the folder being cloned? | 15:55 |
| rburton | lpapp: the fetch log might say something useful, or a du on the folder being fetched into yes. | 15:56 |
| lpapp | rburton: where is all that? | 15:57 |
| lpapp | oh, wait, it returned. | 15:57 |
| WarheadsSE | rburton: thoughts on rysnc not presenting itself in any of the sysroots?? | 15:58 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 15:58 | |
| rburton | WarheadsSE: native or non-native? | 15:59 |
| rburton | WarheadsSE: oh, well, iirc binaries don't appear in the target sysroot | 15:59 |
| rburton | and even if they did, they'd be useless. | 15:59 |
| WarheadsSE | Yes | 15:59 |
| lpapp | 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 | 15:59 |
| WarheadsSE | but I am not getting it at all is the point | 15:59 |
| WarheadsSE | I can see it in the work dir, and the binary is there, but, viola, nada. | 15:59 |
| lpapp | LIC_FILES_CHKSUM = "file://${WORKDIR}/linux-${KERNEL_RELEASE}/COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" | 16:00 |
| lpapp | that looks wrong. | 16:00 |
| lpapp | LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" | 16:00 |
| lpapp | should probably be that. | 16:00 |
| lpapp | I wonder why my predecessors used like that | 16:00 |
| *** beaver_545 <beaver_545!~stuart@82.148.40.66> has quit IRC | 16:03 | |
| *** Xz <Xz!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has joined #yocto | 16:09 | |
| Xz | hi there, who do I talk to send a patch to meta-oe? | 16:09 |
| JaMa | Xz: what do you need? | 16:12 |
| rburton | WarheadsSE: if you care about it in the sysroot i presume you want the native one | 16:12 |
| Xz | JaMa: I have a patch for v4l2apps | 16:12 |
| Xz | JaMa: bugfix | 16:12 |
| rburton | WarheadsSE: presumably you have a patch for rsync, as oe-core's rsync doesn't do native. | 16:12 |
| *** sroy <sroy!~sroy@ip-208-88-110-45.savoirfairelinux.net> has quit IRC | 16:13 | |
| JaMa | Xz: just send it to openembedded-devel@lists.openembedded.org and if it's good, I'll apply it | 16:13 |
| Xz | JaMa: so openembedded-core is poky, openembedded-devel is meta-oe ? | 16:13 |
| JaMa | Xz: just follow README file, openembedded-core is oe-core, poky is yocto ML | 16:14 |
| Xz | JaMa: ok cool, thanks | 16:15 |
| *** nitink <nitink!~nitink@134.134.137.73> has joined #yocto | 16:15 | |
| WarheadsSE | rburton: Yeah, I have noticed that. | 16:15 |
| JaMa | and poky as git repo == oe-core+bitbake+meta-yocto | 16:15 |
| WarheadsSE | 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. | 16:15 |
| rburton | haha | 16:15 |
| rburton | good move | 16:15 |
| rburton | fwiw, BBCLASSEXTEND="native" should be all you need in rsync.bb to make it build as rsync-native | 16:16 |
| WarheadsSE | 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. | 16:16 |
| WarheadsSE | it _should_not_ be in the final install methods. | 16:16 |
| Xz | JaMa: one more question - are you still taking patches for dylan? or master only? | 16:17 |
| WarheadsSE | 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" | 16:18 |
| WarheadsSE | that someone knows exactly who the F they are too. | 16:18 |
| lpapp | rburton: I do not follow.... shouldn't my git patches be applied with their commit messages if I use git? | 16:24 |
| lpapp | or only the raw content is applied? | 16:24 |
| lpapp | how can I fix this? | 16:24 |
| *** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto | 16:25 | |
| rburton | lpapp: if you have a git repo and patches in SRC_URI then the patches are applied using "patch", not committed. | 16:25 |
| rburton | well, the patches are always applied using patch, no special-cases. | 16:26 |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has joined #yocto | 16:26 | |
| bluelightning | I believe you can set PATCHTOOL = "git" if you do want git to apply the patches | 16:26 |
| bluelightning | but then of course the patches *must* apply properly with git am | 16:27 |
| lpapp | rburton: that will make the development within Yocto super painful. | 16:27 |
| lpapp | currently, I have a huge patchset, and there is a bug to be fixed in the 15th. | 16:27 |
| bluelightning | if you want less "painful" development, use a proper git branch and don't use patches at all | 16:27 |
| lpapp | it is impossible to properly rebase without git. | 16:27 |
| rburton | lpapp: so use the power of git and use a branch and not patches | 16:27 |
| lpapp | rburton: have no any clue what you are talking about. | 16:28 |
| lpapp | rburton: Yocto *should* be able to apply a git patch set. | 16:28 |
| rburton | that's totally irrelevant. | 16:28 |
| lpapp | and not just the raw content. | 16:28 |
| rburton | if you have a huge patch set, maintain it in a git branch | 16:28 |
| *** dany <dany!~Thunderbi@178.28.86.171> has joined #yocto | 16:28 | |
| lpapp | that does not make any sense | 16:29 |
| bluelightning | on the contrary, it makes perfect sense | 16:29 |
| lpapp | since you would need to get it work in Yocto anyway if you plan to use Yocto. | 16:29 |
| lpapp | and adding extra overhead (again) to the end user rather than the tool being smart does not ... make sense. | 16:29 |
| bluelightning | using git as it's intended to be used is not extra overhead, it's *less* overhead | 16:30 |
| lpapp | most definitely, Yocto should have a variable or whatever config option for applying a git patchset just right. | 16:30 |
| bluelightning | lpapp: it does, see what I said above about PATCHTOOL = "git" | 16:30 |
| lpapp | currently, I am completely frustrated with Yocto | 16:30 |
| bluelightning | a git branch is still far easier to manage | 16:30 |
| lpapp | I have been trying for two days to get any kind of development in it done | 16:30 |
| lpapp | but it has been so far just a waste of time, and I got nothing done. | 16:31 |
| rburton | 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. | 16:32 |
| rburton | i told you that about five hours ago, but i'll tell you again in case you missed it. | 16:32 |
| lpapp | I hope you do realize I clone a branch since that is what we have been discussing for hours | 16:34 |
| *** JDuke128 <JDuke128!~textual@178.233.48.89> has joined #yocto | 16:34 | |
| lpapp | so I have no idea what branching is being talked about, really. | 16:34 |
| lpapp | it *already* is a branch | 16:34 |
| lpapp | the problem is /not/ the branch | 16:34 |
| lpapp | the problem is that Yocto does not apply the git patches as git patches, but raw patches. | 16:34 |
| lpapp | talking about branching looks red herring to me here because I already clone the dedicated release branch. | 16:34 |
| lpapp | well, tag, whatever. | 16:35 |
| rburton | in which case why are you worrying about a patch set, when you have a branch | 16:35 |
| rburton | and the solution you're looking for is to maintain your patches as a branch in a git repository | 16:36 |
| rburton | and then build that branch, instead of patching a different branch | 16:37 |
| lpapp | it is all red herring. | 16:37 |
| lpapp | Also, PATCHTOOL is not what I want. I want to have a PREFERRED_PATCHTOOL | 16:37 |
| lpapp | i.e. I really do not want to set it for every corresponding recipe. | 16:38 |
| lpapp | I want to set a preferred tool, and if it is not like that it can fallback to whatever the default is. | 16:38 |
| lpapp | and then it could be set globally. | 16:38 |
| lpapp | (again that would reduce the maintenance per package) | 16:39 |
| *** JDuke128 <JDuke128!~textual@178.233.48.89> has quit IRC | 16:41 | |
| JaMa | Xz: fixes for dora and dylan are still welcome | 16:43 |
| rburton | lpapp: you can set PATCHTOOL in a global configuration file | 16:44 |
| *** n01_ <n01_!~n01@host131-251-dynamic.42-79-r.retail.telecomitalia.it> has joined #yocto | 16:45 | |
| lpapp | PATCHTOOL = "git" -> did not work | 16:45 |
| lpapp | rburton: I do not know what will happen for non-git patches if it is not preferred, but mandatory. | 16:45 |
| bluelightning | I wouldn't advise setting it globally | 16:45 |
| lpapp | if it is just preferred, the variable is probably called wrong. | 16:45 |
| bluelightning | patch.bbclass has not been designed to handle any kind of fallback | 16:45 |
| lpapp | sounds like a bad design right there | 16:45 |
| lpapp | either way... it does not work even for a single package. | 16:46 |
| *** n01 <n01!~n01@host73-19-dynamic.47-79-r.retail.telecomitalia.it> has quit IRC | 16:46 | |
| lpapp | it does not apply my changes nicely along with the commit message for the kernel | 16:46 |
| lpapp | I used bitbake -c cleansstate virtual/kernel && bitbake virtual/kernel | 16:46 |
| lpapp | but nothing really changed. | 16:46 |
| lpapp | is there anything else to try or it just will not work? | 16:47 |
| *** panda84kde <panda84kde!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has quit IRC | 16:50 | |
| lpapp | I need to remove the whole build folder for it to work? | 16:55 |
| *** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC | 16:57 | |
| lpapp | so what will happen to PATCHTOOL = "git" if the patch is not actually a git formatted patch? | 17:03 |
| rburton | lpapp: bluelightning said it does "git am", so that will fail. | 17:07 |
| rburton | so do_patch presumably fails | 17:07 |
| lpapp | well, I would get a fallback prompt to fix stuff | 17:08 |
| lpapp | unless Yocto is broken there. | 17:08 |
| lpapp | well, in fact, it should stop by giving an error message anyway. | 17:08 |
| lpapp | or at least a big warning. | 17:08 |
| rburton | 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? | 17:09 |
| *** sroy <sroy!~sroy@ip-208-88-110-45.savoirfairelinux.net> has joined #yocto | 17:10 | |
| lpapp | because that would be way over-engineered. | 17:11 |
| lpapp | creating branch for a few changes, and then store them somewhere else, maintain them separately, etc, etc. | 17:11 |
| lpapp | the whole point of using git for this is to avoid that. | 17:11 |
| lpapp | otherwise I would not use git in the first place. | 17:11 |
| rburton | but i'm saying use git | 17:11 |
| lpapp | I would just grab a released tarball (basically a forked version) | 17:11 |
| lpapp | the whole point of using git is to help with applying and modifying patches. | 17:12 |
| lpapp | while preserving upstream as is. | 17:12 |
| *** W1N9Zr0 <W1N9Zr0!~W1N9Zr0@24-246-63-23.cable.teksavvy.com> has joined #yocto | 17:14 | |
| *** belen <belen!Adium@nat/intel/x-sjwpgcnahikoihxq> has quit IRC | 17:14 | |
| *** dany <dany!~Thunderbi@178.28.86.171> has quit IRC | 17:16 | |
| *** behanw <behanw!~behanw@184.66.17.46> has joined #yocto | 17:19 | |
| lpapp | where can I find the git apply log? | 17:20 |
| lpapp | it might very well be a bug in Yocto not reporting errors properly. | 17:20 |
| *** fabo <fabo!~fabo@linaro/fabo> has quit IRC | 17:20 | |
| *** ant_work <ant_work!~Andrea@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 17:20 | |
| rburton | the patch log, as usual | 17:21 |
| lpapp | where is that | 17:22 |
| lpapp | seems to be in workdir/temp | 17:22 |
| rburton | yes | 17:22 |
| rburton | that's where all the logs for all the tasks for all the recipes go | 17:23 |
| lpapp | the file does not have any kinda error, nor warning inside. | 17:23 |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC | 17:23 | |
| lpapp | even though I clearly put non-git patches in there for a test. | 17:23 |
| rburton | where did you set PATCHTOOL? | 17:23 |
| lpapp | PATCHTOOL = "git" | 17:24 |
| lpapp | SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;branch=${KBRANCH} \ | 17:24 |
| rburton | so in a recipe | 17:24 |
| * rburton shrugs | 17:24 | |
| rburton | never used it, you'd have to debug it | 17:24 |
| lpapp | well, it already has debug log level based on the DEBUG lines in the log. | 17:25 |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has quit IRC | 17:26 | |
| JaMa | lpapp: bluelightning: I think it's using git apply not git am | 17:26 |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has quit IRC | 17:26 | |
| JaMa | see meta/lib/oe/patch.py | 17:26 |
| bluelightning | JaMa: you might be right, I didn't actually check | 17:26 |
| lpapp | so there is no way to apply git patches with their commit messages, etc, into a git tree? This has to be fixed asap... | 17:27 |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has joined #yocto | 17:28 | |
| JaMa | lpapp: you can always send patch as you're probably only one requesting it | 17:28 |
| lpapp | btw, it looks strange the code is using git execution as opposed to using a git library like libgit2. | 17:28 |
| lpapp | (I think that even has a python wrapper) | 17:28 |
| rburton | lpapp: for a simple operation such as "apply a patch", that's another host dependency we'd need. | 17:29 |
| lpapp | 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. | 17:29 |
| lpapp | rburton: if you check the git operations used, you will see it is not just patch | 17:30 |
| lpapp | moreover, python dependencies come for almost free. | 17:30 |
| rburton | lol | 17:30 |
| lpapp | it is the matter of a trivial installation mostly. | 17:30 |
| lpapp | pypi, etc. | 17:30 |
| lpapp | (but really, these things are usually part of the distros either way) | 17:30 |
| lpapp | rburton: well, once the git output changes in a relevant way, it gets broken. | 17:31 |
| lpapp | that cannot really happen with a source compatible lib. | 17:31 |
| lpapp | so, it is not like a non-worthy dep for increased stability IMHO. :) | 17:32 |
| lpapp | weren't you speaking about reproducability above anyhow? :] | 17:32 |
| rburton | patches welcome. :) | 17:32 |
| lpapp | I guess... :) | 17:33 |
| lpapp | anyway, the most important patch would be git am. | 17:33 |
| lpapp | IMO, it is acceptable to use git am by default rather than git apply. | 17:33 |
| lpapp | since if it is not a git repository, patch can still apply git formatted patches. | 17:34 |
| JaMa | hmm, but git apply can apply patches without headers, which is more common | 17:34 |
| lpapp | what do you mean by headers in this context? | 17:35 |
| JaMa | author, subject,date | 17:35 |
| rburton | lpapp: curious: what is the reason that you want a branch in WORKDIR with the patches as commits? | 17:35 |
| lpapp | JaMa: patch will work for that, too. | 17:36 |
| lpapp | rburton: I do not wanna branch | 17:36 |
| lpapp | rburton: I wanna have a patchset like with quilt, etc. | 17:37 |
| lpapp | I *would* like to avoid branches if possible. | 17:37 |
| lpapp | since that is a maintenance overhead for us. | 17:37 |
| rburton | lpapp: if you're applying patches with git am, you'll get a branch | 17:37 |
| lpapp | 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. | 17:37 |
| rburton | i'll re-phrase. why do you want to apply patches with "git am" instead of "git apply" in the WORKDIR | 17:37 |
| rburton | okay | 17:37 |
| lpapp | rburton: cause you cannot rebase | 17:37 |
| lpapp | which can be a problem at >1 patch. | 17:38 |
| lpapp | which is quite common for the linux kernel from hardware vendors, I would say. :) | 17:38 |
| rburton | which is why most people's kernel trees are maintained as branches | 17:38 |
| lpapp | no | 17:39 |
| rburton | lpapp: so you'd unpack/patch, go into the workdir, rebase to a different tag, and re-generate the patch set? | 17:39 |
| lpapp | 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, | 17:39 |
| lpapp | them | 17:39 |
| lpapp | I do not wanna maintain branches | 17:39 |
| lpapp | patches are fine as they have been for a couple of years in my career | 17:39 |
| lpapp | including the quilt time. | 17:39 |
| lpapp | dpatch, etc. | 17:39 |
| rburton | lpapp: was my question about your workflow right? | 17:40 |
| lpapp | rburton: git rebase -i HEAD~X ... git format-patch HEAD~X --cover-letter --numbered -s -o patch-folder-next-to-the-recipe | 17:40 |
| lpapp | this would be the ideal development workflow for a kernel developer like me. | 17:41 |
| lpapp | currently, the missing bridge is the lacking git am .... | 17:42 |
| lpapp | I will take a look into it during christmas, I think. | 17:42 |
| lpapp | hopefully, it is easy to fix. | 17:42 |
| rburton | lpapp: fwiw, the kernel developers i know do it the other way around. | 17:43 |
| lpapp | 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. | 17:43 |
| lpapp | because currently, it is impossibly hard to work and test patches within Yocto. | 17:43 |
| lpapp | rburton: so you have got a different personal taste then now. ;-) | 17:44 |
| lpapp | your experience is extended. | 17:44 |
| lpapp | for me, it is lotta easier to review the additions to the linux kernel, and update the vanilla version, and then the changes, etc. | 17:45 |
| lpapp | since this way I will keep vanilla history always as is, and I apply changes on top of it | 17:46 |
| lpapp | the other way around would result a mixed history with changes in-between. | 17:46 |
| lpapp | and it might be that upstreaming a change will happen in a different way | 17:47 |
| lpapp | and then your branch is not in sync anymore..... | 17:47 |
| lpapp | yeah, I really prefer patchset applied by quilt/dpatch/git am/etc. | 17:47 |
| *** ramose_ <ramose_!6a4e621f@gateway/web/freenode/ip.106.78.98.31> has joined #yocto | 17:52 | |
| ramose_ | How Do I rectify this? | 17:53 |
| ramose_ | DEBUG: Searching for source_mirror/sources/git2_github.com.raspberrypi.firmware.git.tar.gz in paths | 17:53 |
| ramose_ | I know I don't have "git2_github.com.raspberrypi.firmware.git.tar.gz" in my source mirror | 17:54 |
| rburton | a source mirror you maintain? | 17:54 |
| rburton | 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. | 17:55 |
| ramose_ | It looks like an huge repo and I already have installed firmware-master.zip(134 MB) but | 17:55 |
| rburton | ramose_: (so you'll probably need to force a fetch to re-generate it, or something) | 17:55 |
| rburton | and yes, it's HUGE. | 17:55 |
| ramose_ | beacause of limited interent bandwidh I can't download or clone git2_github.com.raspberrypi.firmware.git.tar.gz | 17:55 |
| ramose_ | again | 17:55 |
| rburton | 1.4 git! | 17:56 |
| rburton | gig even | 17:56 |
| ramose_ | yes rburton :source mirror I am mainting | 17:56 |
| ramose_ | *maintainig | 17:56 |
| rburton | ramose_: maybe "bitbake rpi-firmware -c fetch" (replace recipe name with the right one) will be enough, from looking at the source | 17:57 |
| rburton | ramose_: (on the machine that can write there, with BB_GENERATE_MIRROR_TARBALLS=1) | 17:57 |
| ramose_ | but it will start fetching "git2_github.com.raspberrypi.firmware.git.tar.gz" which I can't afford as I have limited internet bandwidth | 17:58 |
| *** n01_ <n01_!~n01@host131-251-dynamic.42-79-r.retail.telecomitalia.it> has quit IRC | 17:59 | |
| rburton | *on the machine that writes to the mirror* | 17:59 |
| ramose_ | My question is Can I use already downloaded firmware-master.zip | 17:59 |
| ramose_ | ? | 17:59 |
| rburton | so its not using a mirror, and will generate a tarball from the existing directory | 17:59 |
| lpapp | rburton: ok, well, I will look into this git apply, but I think having git am is reasonable. | 17:59 |
| lpapp | and as a fallback, it could try patch. | 17:59 |
| rburton | ramose_: no idea, haven't done a rpi build for about a year | 17:59 |
| lpapp | if it is too much effort, I will develop outside Yocto, and test within Yocto, I guess. | 18:00 |
| lpapp | rburton: my worry about the vendor branch is the lack of decoupling. | 18:01 |
| lpapp | I would not know anymore clearly without much effort what is upstream and what not. | 18:01 |
| lpapp | it would be a mixed history without clear distinction like with a patchset. | 18:01 |
| lpapp | I like clear distinction. | 18:01 |
| lpapp | I do not think that is achieved by vendor branches. | 18:02 |
| lpapp | I mean easily, that is. | 18:02 |
| ramose_ | rburton: this is done with linux source | 18:02 |
| rburton | sure it can. where your branch diverges from upstream is where your stuff is. | 18:02 |
| lpapp | rburton: that is not as easy to see as with an enumerated patch set. | 18:03 |
| lpapp | moreover, it will be impossible to rebase without force push. | 18:03 |
| lpapp | which makes upstreaming changes later lotta harder. | 18:03 |
| *** n01 <n01!~n01@host131-251-dynamic.42-79-r.retail.telecomitalia.it> has joined #yocto | 18:03 | |
| rburton | 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. | 18:04 |
| ramose_ | --- 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 \ | 18:04 |
| lpapp | ok, thanks, merry christmas. | 18:04 |
| ramose_ | Sorry I don't know how to provide text editor link here | 18:05 |
| ramose_ | rburton: I have modified the SRC_URI in kernel recipe to pick the downloaded .zip file instead of clone the linux.git | 18:08 |
| ramose_ | but not sure how Can I do the same for firmware recipe | 18:08 |
| lpapp | rburton: I am afraid he is gone for the christmas holiday. | 18:14 |
| lpapp | ramose_: (sorry) | 18:14 |
| *** ramose_ <ramose_!6a4e621f@gateway/web/freenode/ip.106.78.98.31> has quit IRC | 18:16 | |
| *** Xz <Xz!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has quit IRC | 18:17 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:22 | |
| *** n01 <n01!~n01@host131-251-dynamic.42-79-r.retail.telecomitalia.it> has quit IRC | 18:26 | |
| *** n01 <n01!~n01@host131-251-dynamic.42-79-r.retail.telecomitalia.it> has joined #yocto | 18:37 | |
| *** fabo <fabo!~fabo@linaro/fabo> has joined #yocto | 18:44 | |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has joined #yocto | 19:10 | |
| *** reallife <reallife!~reallife@ool-4b7ff55a.static.optonline.net> has quit IRC | 19:18 | |
| *** wgao_ <wgao_!~wgao@1.202.252.122> has joined #yocto | 19:20 | |
| *** michael_e_brown <michael_e_brown!~michael_e@99-23-196-16.lightspeed.austtx.sbcglobal.net> has joined #yocto | 19:21 | |
| *** rtollert_ <rtollert_!~rtollert@130.164.62.31> has joined #yocto | 19:22 | |
| *** dany <dany!~Thunderbi@c-b21c5995-74736162.cust.telenor.se> has joined #yocto | 19:25 | |
| *** Rootert_ <Rootert_!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 19:26 | |
| *** wgao <wgao!~wgao@1.202.252.122> has quit IRC | 19:26 | |
| *** lyang0 <lyang0!~lyang001@1.202.252.122> has quit IRC | 19:26 | |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has quit IRC | 19:26 | |
| *** rtollert <rtollert!~rtollert@130.164.62.31> has quit IRC | 19:26 | |
| *** michael_e_brown_ <michael_e_brown_!~michael_e@99-23-196-16.lightspeed.austtx.sbcglobal.net> has quit IRC | 19:26 | |
| *** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 19:26 | |
| *** Rootert_ is now known as Rootert | 19:26 | |
| *** n01 <n01!~n01@host131-251-dynamic.42-79-r.retail.telecomitalia.it> has quit IRC | 19:29 | |
| *** fray <fray!U2FsdGVkX1@63.228.1.57> has joined #yocto | 19:32 | |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has joined #yocto | 19:33 | |
| *** reallife <reallife!~reallife@ool-4b7ff55a.static.optonline.net> has joined #yocto | 19:34 | |
| *** lyang0 <lyang0!~lyang001@1.202.252.122> has joined #yocto | 19:36 | |
| *** reallife <reallife!~reallife@ool-4b7ff55a.static.optonline.net> has quit IRC | 19:45 | |
| *** reallife <reallife!~reallife@ool-4b7ff55a.static.optonline.net> has joined #yocto | 19:46 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 19:47 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 19:49 | |
| *** sroy <sroy!~sroy@ip-208-88-110-45.savoirfairelinux.net> has quit IRC | 20:00 | |
| *** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto | 20:13 | |
| *** dvhart <dvhart!dvhart@nat/intel/x-cinakwaljhagyzti> has joined #yocto | 20:32 | |
| *** kalyank <kalyank!~kalyan@host-109-204-182-62.tp-fne.tampereenpuhelin.net> has quit IRC | 20:33 | |
| *** kalyank <kalyank!~kalyan@host-109-204-182-62.tp-fne.tampereenpuhelin.net> has joined #yocto | 20:34 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has left #yocto | 20:43 | |
| *** Xz <Xz!c0c6972c@gateway/web/freenode/ip.192.198.151.44> has joined #yocto | 20:49 | |
| Xz | hi there | 20:49 |
| Xz | is there any Yocto variable giving me 'target' I compile for? | 20:49 |
| *** jwhitmore <jwhitmore!~jwhitmore@host86-131-26-169.range86-131.btcentralplus.com> has quit IRC | 20:51 | |
| Xz | I think it might be ${TARGET_ARCH} | 20:51 |
| bluelightning | Xz: TARGET_ARCH, TARGET_SYS, MULTIMACH_TARGET_SYS | 20:51 |
| bluelightning | depending on how detailed you want it... | 20:51 |
| Xz | and ${S} is directory where I have all source files? | 20:52 |
| bluelightning | yes | 20:52 |
| bluelightning | for a recipe | 20:52 |
| Xz | I just have unusual configure script | 20:52 |
| Xz | have to figure out semi-manually how to execute it with correct flags | 20:52 |
| Xz | oe_runconf appends whole set of flags, so doesn't work for me | 20:53 |
| *** fray <fray!U2FsdGVkX1@63.228.1.57> has quit IRC | 20:53 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto | 20:54 | |
| bluelightning | Xz: is this an autoconf-generated configure script or a hand-written one? | 21:03 |
| Xz | bluelightning: it's defo hand-written | 21:03 |
| Xz | bluelightning: it comes from 'bitlbee' - I'm trying to create recipe for that | 21:04 |
| bluelightning | Xz: right, in that case you should not inherit autotools if you currently are | 21:04 |
| Xz | bluelightning: yes, I am | 21:04 |
| Xz | bluelightning: so I should write my own do_configure and do_compile? | 21:04 |
| bluelightning | 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 | 21:05 |
| bluelightning | 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 | 21:06 |
| Xz | bluelightning: cool, didn't find it | 21:06 |
| Xz | bluelightning: actual version is 3.2.1 | 21:06 |
| bluelightning | 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 | 21:07 |
| Xz | OE-Classic is not maintained anymore? That's my understanding | 21:08 |
| bluelightning | it's not, no... but it's sometimes useful to resurrect recipes from there, so we index it (separately) | 21:09 |
| Xz | bluelightning: I already have 'irssi' - ncurses IRC client | 21:12 |
| Xz | bluelightning: now just need bitlbee to connect that to facebook chat and others | 21:13 |
| Xz | bluelightning: gonna place that next to my router, up and running 24/7 | 21:13 |
| bluelightning | nice :) | 21:14 |
| Xz | bluelightning: didn't find anywhere irssi recipe, but that one was easier to create | 21:14 |
| Xz | bluelightning: I might send that to openembedded-core | 21:14 |
| Xz | bluelightning: or openembedded-devel | 21:14 |
| bluelightning | we definitely had irssi recipes in OE-Classic | 21:15 |
| bluelightning | right, it's probably something for meta-oe | 21:15 |
| bluelightning | that would be much appreciated btw :) | 21:15 |
| Xz | bluelightning: cool | 21:16 |
| Xz | bluelightning: however I always have a problem - where to put it | 21:16 |
| Xz | bluelightning: 1st - poky/meta-oe, 2nd which directory: recipes-extended? recipes-xyz | 21:16 |
| bluelightning | meta-oe/recipes-connectivity for these two I thin | 21:17 |
| bluelightning | think | 21:17 |
| bluelightning | we do have a meta-networking, but I'm not sure IRC/IM-related stuff really fits there | 21:17 |
| Xz | bluelightning: ok, once I have that ready - I will try to send a patch (recipes-connectivity) and see what happens | 21:18 |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has quit IRC | 21:46 | |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has joined #yocto | 21:48 | |
| *** dany <dany!~Thunderbi@c-b21c5995-74736162.cust.telenor.se> has quit IRC | 21:52 | |
| Xz | in oe-classic's version of bitlbee there is one step: pkg_postinst. Is there any matching step in current Yocto? | 21:52 |
| Xz | I got it compiling, will give it a go on board soon :) | 21:53 |
| Xz | just curious about that pkg_postinst step | 21:53 |
| bluelightning | 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) | 21:59 |
| bluelightning | Xz: you should suffix it with _${PN} though so it's only applied to the main package | 21:59 |
| bluelightning | Xz: also use $D (_not_ ${D}) before all paths so that the script can run at image creation time if it needs to | 22:00 |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has quit IRC | 22:02 | |
| *** dvhart <dvhart!dvhart@nat/intel/x-cinakwaljhagyzti> has quit IRC | 22:30 | |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC | 23:01 | |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto | 23:01 | |
| *** fpaut is now known as fpaut_ | 23:05 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 23:23 | |
| *** ant_home <ant_home!~andrea@host18-14-dynamic.21-79-r.retail.telecomitalia.it> has joined #yocto | 23:25 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 23:25 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 23:27 | |
| *** n01 <n01!~n01@host59-250-dynamic.36-79-r.retail.telecomitalia.it> has joined #yocto | 23:34 | |
| *** jackmitchell <jackmitchell!~Thunderbi@cpc22-cmbg15-2-0-cust21.5-4.cable.virginm.net> has joined #yocto | 23:35 | |
| *** agust <agust!~agust@p4FDE606F.dip0.t-ipconnect.de> has quit IRC | 23:40 | |
| *** ant_home <ant_home!~andrea@host18-14-dynamic.21-79-r.retail.telecomitalia.it> has quit IRC | 23:50 | |
| *** jackmitchell <jackmitchell!~Thunderbi@cpc22-cmbg15-2-0-cust21.5-4.cable.virginm.net> has quit IRC | 23:52 | |
| *** SorenHolm <SorenHolm!~quassel@5634f347.rev.stofanet.dk> has joined #yocto | 23:59 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!