Monday, 2013-12-23

*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has left #yocto00:26
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:26
*** mitz <mitz!> has quit IRC01:09
*** mitz <mitz!> has joined #yocto01:21
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:26
*** silviof4 <silviof4!> has joined #yocto03:01
*** silviof3 <silviof3!> has quit IRC03:01
*** swex <swex!~swex@> has joined #yocto03:14
*** jwhitmore <jwhitmore!> has quit IRC03:38
*** seebs <seebs!> has quit IRC04:28
*** linu1 <linu1!~linu1@> has joined #yocto04:34
linu1hi 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 me04:37
*** emacer <emacer!~EMAC@> has quit IRC04:37
*** sunfunbaby <sunfunbaby!> has joined #yocto04:55
*** sunfunbaby <sunfunbaby!> has quit IRC05:08
*** linu1 <linu1!~linu1@> has quit IRC05:31
*** linu1 <linu1!~linu1@> has joined #yocto05:32
*** seebs <seebs!> has joined #yocto06:01
*** GusBricker <GusBricker!> has quit IRC06:06
*** mitz <mitz!> has quit IRC06:17
*** behanw <behanw!~behanw@> has quit IRC06:25
*** GusBricker <GusBricker!> has joined #yocto06:41
*** fusman <fusman!~fahad@> has joined #yocto06:46
*** beaver_545 <beaver_545!> has joined #yocto06:50
*** GusBricker <GusBricker!> has quit IRC07:05
*** bjrj <bjrj!75ca1db7@gateway/web/freenode/ip.> has joined #yocto07:07
*** bjrj <bjrj!75ca1db7@gateway/web/freenode/ip.> has quit IRC07:12
*** nitink <nitink!nitink@nat/intel/x-qxxrynppctlvfolh> has quit IRC07:12
*** mitz <mitz!> has joined #yocto07:30
*** n01 <n01!> has joined #yocto07:34
*** zeddii_home <zeddii_home!> has quit IRC07:45
*** beaver_545 <beaver_545!> has quit IRC07:55
*** fpaut_ is now known as fpaut08:08
*** ant_work <ant_work!> has joined #yocto08:26
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto08:28
*** zeeblex <zeeblex!~apalalax@> has joined #yocto08:31
*** ddalex <ddalex!~ddalex@> has joined #yocto08:31
*** dv__ <dv__!> has joined #yocto08:36
*** dv <dv!> has quit IRC08:37
*** zeeblex <zeeblex!~apalalax@> has quit IRC08:46
*** ddalex <ddalex!~ddalex@> has quit IRC08:47
*** agust <agust!> has joined #yocto08:54
*** zeeblex <zeeblex!apalalax@nat/intel/x-qmnmmjkqwpzafxcf> has joined #yocto08:58
*** beaver_545 <beaver_545!~stuart@> has joined #yocto09:01
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC09:44
*** belen <belen!~Adium@> has joined #yocto09:48
*** SorenHolm <SorenHolm!> has joined #yocto09:53
*** erbo <erbo!> has quit IRC09:54
*** erbo <erbo!> has joined #yocto10:02
*** henriknj <henriknj!> has quit IRC10:07
*** cristianiorga <cristianiorga!~cristiani@> has joined #yocto10:10
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:34
lpapphi, is it a good idea to drop the bareclone entry here? SRC_URI = "git://;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"10:34
lpappI would like to aid the linux kernel development with Yocto in my layer.10:34
rburtoni *think* linux-yocto needs a bare clone because of how it's configured, using multiple branches in the repo.10:35
lpapprburton: what exactly do you mean?10:36
lpappWhat will be the expected impact if I remove it?10:36
rburtonpotentially just a waste of disk space/time, but i think the build for linux-yocto checks out multiple branches10:37
rburtonbut if you're not using linux-yocto that isn't a concern10:38
*** ScriptRipper1 <ScriptRipper1!> has quit IRC10:40
lpapprburton: I am using a copy of it from denzil.10:43
lpappwith which it is extremely painful to do kernel development.10:43
lpappso I am trying to switch to git, but then again, bareclone is a blocker for that.10:43
lpappso 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
rburtonlpapp: have you read the yocto kernel development manual?10:44
lpappyes, a few times.10:44
lpapplemme re-read it.10:46
*** SorenHolm <SorenHolm!> has quit IRC10:47
rburtoneg is useful for building a kernel using a local git tree, so you can commit on local branches and build from it10:47
rburtonor, don't use linux-yocto, and then the bareclone this isn't an issue.10:48
*** zeddii_home <zeddii_home!> has joined #yocto10:48
*** dany <dany!~Thunderbi@> has joined #yocto10:51
lpapprburton: as I said, I am not using Yocto's git clone.10:53
lpappI am using my layer's git clone.10:53
*** ScriptRipper1 <ScriptRipper1!> has joined #yocto10:54
*** mulhern <mulhern!> has joined #yocto11:10
*** mulhern <mulhern!> has quit IRC11:13
*** belen <belen!~Adium@> has quit IRC11:15
*** zeddii_home <zeddii_home!> has quit IRC11:18
*** dv__ is now known as dv_11:25
RPlpapp: 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 where11:29
*** panda84kde <panda84kde!> has joined #yocto11:30
RPlpapp: 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
lpappRP: what tools? I do not need two branches.11:35
rburtonlpapp: so you're not using linux-yocto, so you don't need the bare clone.11:36
RPlpapp: right, so don't use linux-yocto then11:36
lpapprburton: 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
lpappI do use means, the recipe is pretty much cloned.11:36
lpappincluding the .inc file.11:36
lpappRP: well, it is not so simple.11:37
lpappwriting a linux kernel recipe seems to be a lot of effort based on the length of the linux-yocto recipe files.11:37
lpappso, I would not definitely like to start it from scratch; rather, I would customize the cloned linux-yocto for my own needs.11:38
lpappso which tools exactly, and what do I need to remove to get rid of the multi-branches?11:38
lpappanyway, why is it using multiple branches/11:38
rburtonone for kernel source, one for the configuration metadata11:38
lpappwhy not provide only the latest recipe?11:38
RPlpapp: which parts of linux-yocto do you want? Do you want defconfig fragment support for example?11:38
lpapprburton: what does configuration metadata mean?11:38
rburtonthe config fragments which are used to assemble the configuration are stored in the "meta" branch11:39
lpappRP: I think so because I have custom kernel drivers, so I would like to enable them.11:39
lpappunless there is a simple way to do that without a yet another branch.11:39
RPlpapp: What I mean is are you happy to use a full defconfig file or are you after the fragment support?11:39
RPlpapp: also, are you after any of the config fragment features or the patches in linux-yocto?11:40
lpappRP: currently, I am using the defconfig, and I am happy with it.11:40
lpappbitbake -c menuconfig virtual/kernel -> I edit and save it.11:40
lpappthen I copy .config to defconfig11:40
RPlpapp: right, then don't use linux-yocto then11:40
RPlpapp: find an example of a simpler kernel from another layer11:41
lpappdo you have any suggestion?11:41
RPlpapp: something like
lpappbut anyway, does that mean linux-yocto sacrificies the kernel development within Yocto for having config fragments?11:41
RPlpapp: that shows a mainline kernel, a set of patches and a defconfig11:42
RPlpapp: obviously you can put your own patches in, or none at all11:42
RPlpapp: 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 simpler11:43
rburtonlpapp: 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
RPlpapp: is an even simpler example11:43
lpappwell, what I would prefer is:11:44
lpappbitbake virtual/kernel11:44
lpappthen it builds stuff11:44
lpappI test the rootfs containing the kernel11:44
lpappI find a bug, I fix it within Yocto, inside the work folder.11:44
lpappand 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
lpappthat is the use case I would like to have.11:45
RPlpapp: start with one of the simpler kernel recipes above and you can do that just fine there11:45
RPlpapp: once you understand and have that working you can think about linux-yocto if it makes sense11:46
lpappwell, we already linux-yocto11:46
lpappmigrating would be quite a bit of work, so I do not feel comfortable with it.11:46
lpappalready havE*11:46
RPlpapp: 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 it11:47
RPI 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 designed11:48
*** fpaut is now known as fpaut_11:48
ant_worklpapp: you're describing one possible linux-yocto workflow...but that git diff needs to be committed so that you obtain a patch for your recipe11:48
*** jwhitmore <jwhitmore!> has joined #yocto11:49
lpappant_work: not really, no.11:49
ant_worklpapp: yes, I do that ;)11:49
lpappant_work: bitbake can handle diff files just fine.11:49
lpappant_work: looks for patches. Most of them are not git patch, really.11:49
lpappyou do not need to commit to get a diff.11:49
ant_workyo do need to commit to get a patch11:49
lpapp(but this is not the major point anyway)11:49
lpappgit diff > stuff.patch11:50
lpappjob done11:50
*** fpaut_ is now known as fpaut11:50
ant_workin the bitbake framework, you need a patch to add the kernel patch11:50
lpappgit diff > stuff.patch and you have the patch. What is the problem?11:50
lpappRP: I disagree.11:51
lpappat the very least - since I expect it to be common - there could be some examples and/or skeleton.11:51
rburtonlpapp: an even better workflow using linux-yocto doesn't involve patches at all, like i pointed you at.11:51
lpapprburton: well, I have not had time yet to understand every comment fully yet.11:52
lpappI am still just at reading the kernel development manual (first suggestion)11:52
ant_worklpapp: try 'git-format-patch master' in the linux-yocto workdir, in the kernel dir11:52
rburtonlpapp: if you're not going to use linux-yocto, then stop reading the manual for it.11:52
lpappant_work: why would I?11:53
lpappI was happy with git diff, that is not an issue for me.11:53
lpapprburton: 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
lpappant_work: moreover, currently, I do not use git based linux-yocto11:57
lpappI 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
lpappwhat is the point of config fragments anyway?12:03
lpappWouldn'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
rburtonlpapp: denzil's kernel is built with linux-yocto, and linux-yocto has always used git.
rburtonlpapp: config fragments are very useful when you maintain more than one machine12:04
lpappwhy ?12:05
lpappbitbake -c menuconfig arm virtual/kernel12:05
rburtonbecause you can separate common things from machine-specific things.12:06
lpappthe syntax could be something like that. I would prefer that over a brand new concept.12:06
rburtonremember that nobody is making you use linux-yocto12:06
lpappsure, but I think it should still be comfortable and handy. ;}12:06
*** panda84kde <panda84kde!> has quit IRC12:06
*** panda84kde <panda84kde!> has joined #yocto12:07
*** henriknj <henriknj!> has joined #yocto12:07
lpappso why exactly do we need config fragments as opposed to a option for the bitbake command?12:07
*** jwhitmore <jwhitmore!> has quit IRC12:07
rburtonbecause you can separate common configuration from machine-specific configuration12:08
lpappso could you with an option.12:08
lpappand the rest would be transparent for the end user.12:08
lpapp $ diff -Nurp config.orig .config | sed -n "s/^\+//p" > frag.cfg12:12
lpapperm? Really? Isn't there a nicer way (i.e. less plumber)? :]12:12
*** jwhitmore <jwhitmore!> has joined #yocto12:14
*** jdvdt <jdvdt!> has joined #yocto12:19
lpappis there a feature request to make it handier?12:24
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC12:27
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-fqrsynewxjvhmqja> has joined #yocto12:28
lpapp11:59 < rburton> lpapp: denzil's kernel is built with linux-yocto, and linux-yocto has always used git. -> I do not know how that is possible because definitely, denzil here does not fetch from git.12:30
*** ddalex <ddalex!~ddalex@> has joined #yocto12:30
lpappSRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v3.0/linux-${PV}.tar.bz2;name=kernel \12:30
lpappit even eventually does fetch the released tarball here.12:30
*** jdvdt <jdvdt!> has left #yocto12:32
*** SorenHolm <SorenHolm!> has joined #yocto12:32
rburtonlpapp: 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
lpapprburton: perhaps it was added post-denzil.12:35
lpappi.e. in a bugfix release.12:35
rburtonlpapp: nope.12:35
*** fpaut_ is now known as fpaut12:35
lpapprburton: well, then we apparently modified it silently.12:38
rburtonlpapp: suspected as much12:38
lpapp(i.e. without mentioning it to me)12:39
lpappor it predates my time, etc.12:39
rburtonyou need to run a diff between your tree and poky, and move out any changes so you don't get confused.12:40
lpappwell, the linux-yocto recipe and the .inc are pretty complex.12:40
rburtonyeah, but if its building from a tarball, it's very much not linux-yocto12:41
lpappI think it is except the SRC_URI12:43
lpappsince we have the same files with pretty much the same complexity level to me.12:43
lpappbtw, is there any point in linux-yocto when you need to support only one board type?12:43
rburtonlpapp: the argument is a lot harder then12:44
lpapprburton: what argument? :)12:44
rburtonthe fragments argument12:45
lpappI am not sure I can follow.12:45
lpappwhat exactly is harder? Can you give a use case?12:46
rburtonthere is always point to linux-yocto, but if you have a single board and no flexbility, then it certainly is overhead you may not need12:46
lpappok, thanks.12:47
*** dany <dany!~Thunderbi@> has quit IRC12:52
lpapprburton: -> this is our linux-foo.inc12:59
*** GusBricker <GusBricker!> has joined #yocto12:59
*** zeeblex <zeeblex!apalalax@nat/intel/x-qmnmmjkqwpzafxcf> has left #yocto12:59
*** dany <dany!> has joined #yocto13:02
lpapprburton: and this is the versioned linux kernel recipe,
lpappis it ok that the .inc file seems to be commented out?13:04
*** SorenHolm <SorenHolm!> has quit IRC13:06
rburton"page does not exist"13:06
lpapphmm, bizarr bug.13:08
*** bluelightning <bluelightning!> has joined #yocto13:12
*** bluelightning <bluelightning!> has quit IRC13:12
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto13:12
rburton"page you are looking for does not exist"13:13
lpappvery odd since this time I even confirmed it.13:13
lpappand I put it up for 30 minutes13:13
rburtonthat works13:14
lpappI selected 6 hours this time.13:14
rburtonyes, that require is commented out13:15
rburtonso its not used13:15
lpappyeah; is that bad?13:15
lpappKERNEL_IMAGETYPE = "uImage"13:15
lpappFILES_kernel-image = "/boot/uImage*"13:15
lpappI do not understand that either.13:15
lpappIMO, the second line does not make any sense....13:15
rburtoni have no idea what's in that .inc, so i can't comment13:16
lpappsince that is the default expansion for the image type set....13:16
*** belen <belen!Adium@nat/intel/x-sjwpgcnahikoihxq> has joined #yocto13:18
*** fusman <fusman!~fahad@> has quit IRC13:20
*** fusman <fusman!~fahad@> has joined #yocto13:21
*** reallife <reallife!> has joined #yocto13:22
*** zarul <zarul!~zarul@ubuntu/member/zarul> has quit IRC13:25
*** zarul <zarul!~zarul@ubuntu/member/zarul> has joined #yocto13:26
lpappis it ./meta/classes/kernel-yocto.bbclass responsible for the fragment feature?13:27
rburtonlooks like it's got at least some of the logic. no idea if that's all of it.13:28
rburtoni suspect it's the bulk of it, yes.13:28
lpappI guess removing that inheritance along with the bareclone stuff may actually work.13:30
rburtonthe 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
lpapprburton: no, I am considering being closer to linux-yocto13:31
*** challinan <challinan!> has joined #yocto13:31
lpapprburton: i.e. including dtb and inheriting the kernel class as well.13:31
*** mitz <mitz!> has quit IRC13:38
*** ramose <ramose!3df7fee2@gateway/web/freenode/ip.> has joined #yocto13:50
ramoseHow to set up mirros to fetch the source in yocto13:50
*** JDuke128 <JDuke128!~textual@> has joined #yocto13:53
bluelightningramose: maybe this will help:
ramoseThanks bluelightning ,I guess I have have to use premirrors my self because I wanted to set  more than one mirror13:58
lpapprburton: at least, it would be lovely if the fragments could be that well modularized.14:00
ramosebluelightning would you like to tell me that use of BB_NO_NETWORK = "1"?14:03
bluelightningramose: BB_NO_NETWORK tells bitbake not to download anything from the network14:04
*** JDuke128 <JDuke128!~textual@> has quit IRC14:04
ramoseSo I should not use it unless I Downloaded all tar balls before bitbake,right?14:05
*** dany <dany!> has quit IRC14:06
ramoseCan I restrict use of  BB_NO_NETWORK = "1" to specific recipe?14:06
lpapprburton: I do not follow how it makes sure to fetch 3.2 for instance: KBRANCH = "standard/default/base" and SRC_URI = "git://;protocol=git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"14:06
*** GusBricker <GusBricker!> has quit IRC14:06
*** dany <dany!> has joined #yocto14:07
lpapprburton: i.e. I do not know how to change the SRC_URI from tarball to git. :/14:09
lpappbut that is not in line with the linux-yocto stuff.14:10
lpappI would like to keep it as close as possible.14:10
rburtonthe one you pasted just adds more variables14:11
rburtonyou don't want bareclone14:11
rburtonyou don't need name14:11
lpapprburton: well, I do not know how KBRANCH = "standard/default/base" gets to 3.2.1, for instance14:11
lpappin linux-yocto_3.2.bb14:11
rburtonit doesn't14:12
lpappor 3.2.X, whatever.14:12
rburtonthat's a branch name14:12
lpappand the branch name should have the version information14:12
lpappunless they only tag it.14:12
lpappright, so only tags.14:12
rburtonthe exact version is specified elsewhere, where it says what hash to grab14:12
rburtonno, branches.14:12
lpappbut how is that passed in Yocto?14:12
lpappno, tags.14:13
lpappcheck "git tag -l"14:13
lpapp(in the linux kernel)14:13
lpappand then check git branch -a14:13
rburtoni mean standard/default/base is a branch14:13
lpappwell, that is not enough14:13
lpappyou need to check out the tag, not the branch, really.14:13
rburtoni'm just telling you what you wanted to know14:13
lpappto get a certain version desired.14:13
lpappok, perhaps I am already beyond the understanding of that.14:14
lpappcurrently, I do not understand how the right versioned tag is checked out14:14
rburtonits not!14:14
lpappI guess I would need to check the implementation of the kernel class14:14
lpappwell, it should be.14:14
rburtonthere is a SRCREV specified in the recipe14:14
lpappI want to get 3.2.X for instance.14:14
rburtonthat revision is checked out14:14
lpappthat is dirty, isn't it?14:14
rburton(for linux-yocto)14:14
rburtonno, its precise14:14
lpapphow come?14:14
lpappYou already have the version information, and the linux kernel does have handy version tags14:15
rburtonbecause its very rare to ship a pristine kernel release14:15
lpappso an sha is an unnecessary complication.14:15
lpappI disagree.14:15
lpappI rather think that people ship released and well tested stuff as opposed to random shas.14:15
*** swex <swex!~swex@> has quit IRC14:17
ramosebluelightning: Woulld you like to address my doubts regarding use of BB_NO_NETWORK = "1"14:17
bluelightningramose: I think you can restrict it to an individual recipe yes14:18
bluelightningI never tried that though14:18
*** sroy <sroy!> has joined #yocto14:25
lpapprburton: perhaps, there could be an option for the Linux stuff to disable the fragment stuff in a custom layer?14:26
lpappwithout cloning and reinventing all the stuff?14:26
rburtonlpapp: isn't that what kernel.bbclass is?14:29
rburtonall of linux-yocto.bbclass is about the fragments and machine branches, so just don't use linux-yocto14:30
*** JDuke128 <JDuke128!~textual@> has joined #yocto14:31
*** challinan <challinan!> has left #yocto14:33
*** mitz <mitz!> has joined #yocto14:33
lpapprburton: you mean rather than kernel.bbclass and linux-yocto.bbclass?14:41
*** JDuke128 <JDuke128!~textual@> has quit IRC14:43
*** munch <munch!> has joined #yocto14:46
lpapprburton: oh, wow, SRCREV can also be a tag name!14:55
lpappnot just com14:55
lpappmit hash... that is lovely, isn't it14:55
JaMano it isn't14:58
JaMabecause then it will always run git ls-remote to map tag name to SHA-114:59
rburtonsure, you *can*15:00
rburtonit's just a bad idea15:00
rburtonit forces a remote git operation every build (parse? can't recall)15:01
*** dany <dany!> has quit IRC15:01
JaMalpapp: no it isn't was about "lovely" :)15:01
JaMarburton: parse15:01
lpappJaMa: that is alright. I do not feel bad about it.15:01
lpappcompared to the recipe maintenance effort.15:01
JaMawe had a lot of them in webOS (not in SRCREV but in tag=foo)15:02
JaMaI've finally got rid of them all lately (replaced with sanity check *after* the fetch)15:02
lpappI guess we will need to agree to disagree. :)15:02
rburtonlpapp: consider this background on why many layers use hashes instead of tag names15:02
lpapprburton: because Yocto is bad IMHO15:03
lpappit should help with proper maintenance.15:03
rburtonlpapp: two reasons you can't argue with: 1) performance 2) reproducable15:03
rburtonusing a tag name means a network operation, and means the source can change without the recipe changing.15:03
lpappand 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
rburtonyeah, can't deny that, and nobody did15:03
rburtonjust giving you reasons why many layers don't use tag names, but hashes.15:04
JaMabetter to get right SHA-1 once by recipe maintainer, than every builder getting it with ls-remote in every parse :)15:04
lpappit is not like you fetch that often after all.15:04
lpappmore precisely, you would not fetch at all if it is checked in properly.15:04
JaMaespecially useful when building some private stuff just from prepopulated downloads/PREMIRROR without current access to remote git repos15:05
ramoseI 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
JaMalpapp: you won't run do_fetch, but you'll *always* get git ls-remote to map that tag name to SHA15:05
lpappJaMa: fix yocto.15:05
lpappit should be able to cache it of course.15:06
JaMa16:03:53 < rburton> lpapp: two reasons you can't argue with: 1) performance 2) reproducable15:06
JaMait cannot fetch it because of 2)15:06
lpapp1) is a bug in Yocto15:06
lpappI do not understand what 2) means.15:06
rburtontags are not immutable in git.15:06
rburton-> they can change15:07
lpapprburton: sure, they are in any sane project. :)15:07
JaMayou cannot ever know if tag=foo is still the same source15:07
JaMaand if you have multiple builders all building tag=foo at different time they could get different source15:07
rburtonor want to do a new build to make a point release of that product you shipped a year ago15:07
rburtonand a tag moved, and it won't build anymore15:07
rburtonthat said feel free to use tag names if you prefer it15:08
rburtonbut these are the reason why we generally don't15:08
lpappas I said, software developers can screw up, but sane people do not.15:08
lpappbut 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
lpappto me, it sounds like over-engineering. :)15:09
JaMait was happening quite often in my experience15:09
lpappin that case, you would use a tarball anyway15:10
lpappnot to get broken.15:10
lpappbut then again, I have never really met such insane devs and release guys. :)15:10
JaMaand 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 correct15:10
lpappso for me 2) is not valid, and 1) is a Yocto bug respectively.15:11
lpappit *should* give an option to me if I want to cache for simple maintenance.15:11
JaMagit show-ref tag-name is *simple*15:12
lpappno, it is not.15:12
lpappcompare the two:15:12
lpapp1) 3.1.2 -> 3.1.3 done15:12
lpapp1) Find where to clone from15:12
lpapp2) Clone15:12
lpapp3) run the command15:12
lpapp4) remove15:12
lpappmany unnecessary extra steps.15:13
JaMayou can skip 2-4 if you're clever15:13
lpappthe point of the maintenance of not requiring clever tricks15:13
lpappi.e. easily maintenable.15:13
lpapps/of not/ is not/15:14
JaMacd downloads/git2/*component; git remote update; git show-ref 3.1.315:14
lpappI have no idea how that works15:14
lpappand I would spend hours to figure out15:14
lpappcompared to 3.1.2 to 3.1.3 which is literally a couple of seconds.15:14
rburtonneither of which compare to the minutes this has been discussed15:15
rburtonfor no reason at all15:15
lpappFR is being submitted...15:16
rburtonlpapp: don't even bother15:16
lpapprburton: 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
lpappI see no reason for aiding end users for no real cost.15:19
lpappdeclining to aid15:19
JaMabecause we both already explained why oe-core shouldn't do it15:20
lpappespecially 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
lpappI see no reason for blocking people having simpler life.15:20
lpappif you do not want to use that feature, you will not use it, it is that simple.15:21
lpappit would not be obligatory after all.15:21
ramoseany one ppoint me out how should I test the PAM module support15:21
*** ddalex <ddalex!~ddalex@> has quit IRC15:21
ramoseI 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@> has joined #yocto15:22
*** Kangkai_ <Kangkai_!~kai@> has quit IRC15:25
*** n01 <n01!> has quit IRC15:25
*** n01 <n01!> has joined #yocto15:27
*** sroy <sroy!> has quit IRC15:35
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC15:41
*** sroy <sroy!> has joined #yocto15:50
*** jwhitmore <jwhitmore!> has quit IRC15:50
lpapp0: linux-foo-3.2.1-b+gitrv3.2.1 do_fetch (pid 2206)15:51
lpappit got stuck here.... it has been about twenty minutes now.... any idea what is going on?15:51
rburtona slow git clone?  do a ps and see if there's a git process running15:53
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto15:53
rburtonramose: chek it's installed by looking in the file system15:53
lpapprburton: I cannot run ps unfortunately.15:53
WarheadsSEanyone have any thought on why when I build (and install) rsync, it doesn't end up in *any* of the sysroots?15:54
WarheadsSEman ends up in target, but no binary..15:54
lpapprburton: should I check some log instead or monitor the size of the folder being cloned?15:55
rburtonlpapp: the fetch log might say something useful, or a du on the folder being fetched into yes.15:56
lpapprburton: where is all that?15:57
lpappoh, wait, it returned.15:57
WarheadsSErburton: thoughts on rysnc not presenting itself in any of the sysroots??15:58
*** mitz <mitz!> has quit IRC15:58
rburtonWarheadsSE: native or non-native?15:59
rburtonWarheadsSE: oh, well, iirc binaries don't appear in the target sysroot15:59
rburtonand even if they did, they'd be useless.15:59
lpapprburton: 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/COPYING15:59
WarheadsSEbut I am not getting it at all is the point15:59
WarheadsSEI can see it in the work dir, and the binary is there, but, viola, nada.15:59
lpappLIC_FILES_CHKSUM = "file://${WORKDIR}/linux-${KERNEL_RELEASE}/COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"16:00
lpappthat looks wrong.16:00
lpappLIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"16:00
lpappshould probably be that.16:00
lpappI wonder why my predecessors used like that16:00
*** beaver_545 <beaver_545!~stuart@> has quit IRC16:03
*** Xz <Xz!c0c6972b@gateway/web/freenode/ip.> has joined #yocto16:09
Xzhi there, who do I talk to send a patch to meta-oe?16:09
JaMaXz: what do you need?16:12
rburtonWarheadsSE: if you care about it in the sysroot i presume you want the native one16:12
XzJaMa: I have a patch for v4l2apps16:12
XzJaMa: bugfix16:12
rburtonWarheadsSE: presumably you have a patch for rsync, as oe-core's rsync doesn't do native.16:12
*** sroy <sroy!> has quit IRC16:13
JaMaXz: just send it to and if it's good, I'll apply it16:13
XzJaMa: so openembedded-core is poky, openembedded-devel is meta-oe ?16:13
JaMaXz: just follow README file, openembedded-core is oe-core, poky is yocto ML16:14
XzJaMa: ok cool, thanks16:15
*** nitink <nitink!~nitink@> has joined #yocto16:15
WarheadsSErburton: Yeah, I have noticed that.16:15
JaMaand poky as git repo == oe-core+bitbake+meta-yocto16:15
WarheadsSEI'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
rburtongood move16:15
rburtonfwiw, BBCLASSEXTEND="native" should be all you need in to make it build as rsync-native16:16
WarheadsSEyeah, 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
WarheadsSEit _should_not_ be in the final install methods.16:16
XzJaMa: one more question - are you still taking patches for dylan? or master only?16:17
WarheadsSErburton: 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
WarheadsSEthat someone knows exactly who the F they are too.16:18
lpapprburton: I do not follow.... shouldn't my git patches be applied with their commit messages if I use git?16:24
lpappor only the raw content is applied?16:24
lpapphow can I fix this?16:24
*** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto16:25
rburtonlpapp: if you have a git repo and patches  in SRC_URI then the patches are applied using "patch", not committed.16:25
rburtonwell, the patches are always applied using patch, no special-cases.16:26
*** jwhitmore <jwhitmore!> has joined #yocto16:26
bluelightningI believe you can set PATCHTOOL = "git" if you do want git to apply the patches16:26
bluelightningbut then of course the patches *must* apply properly with git am16:27
lpapprburton: that will make the development within Yocto super painful.16:27
lpappcurrently, I have a huge patchset, and there is a bug to be fixed in the 15th.16:27
bluelightningif you want less "painful" development, use a proper git branch and don't use patches at all16:27
lpappit is impossible to properly rebase without git.16:27
rburtonlpapp: so use the power of git and use a branch and not patches16:27
lpapprburton: have no any clue what you are talking about.16:28
lpapprburton: Yocto *should* be able to apply a git patch set.16:28
rburtonthat's totally irrelevant.16:28
lpappand not just the raw content.16:28
rburtonif you have a huge patch set, maintain it in a git branch16:28
*** dany <dany!~Thunderbi@> has joined #yocto16:28
lpappthat does not make any sense16:29
bluelightningon the contrary, it makes perfect sense16:29
lpappsince you would need to get it work in Yocto anyway if you plan to use Yocto.16:29
lpappand adding extra overhead (again) to the end user rather than the tool being smart does not  ... make sense.16:29
bluelightningusing git as it's intended to be used is not extra overhead, it's *less* overhead16:30
lpappmost definitely, Yocto should have a variable or whatever config option for applying a git patchset just right.16:30
bluelightninglpapp: it does, see what I said above about PATCHTOOL = "git"16:30
lpappcurrently, I am completely frustrated with Yocto16:30
bluelightninga git branch is still far easier to manage16:30
lpappI have been trying for two days to get any kind of development in it done16:30
lpappbut it has been so far just a waste of time, and I got nothing done.16:31
rburtonsteps 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
rburtoni told you that about five hours ago, but i'll tell you again in case you missed it.16:32
lpappI hope you do realize I clone a branch since that is what we have been discussing for hours16:34
*** JDuke128 <JDuke128!~textual@> has joined #yocto16:34
lpappso I have no idea what branching is being talked about, really.16:34
lpappit *already* is a branch16:34
lpappthe problem is /not/ the branch16:34
lpappthe problem is that Yocto does not apply the git patches as git patches, but raw patches.16:34
lpapptalking about branching looks red herring to me here because I already clone the dedicated release branch.16:34
lpappwell, tag, whatever.16:35
rburtonin which case why are you worrying about a patch set, when you have a branch16:35
rburtonand the solution you're looking for is to maintain your patches as a branch in a git repository16:36
rburtonand then build that branch, instead of patching a different branch16:37
lpappit is all red herring.16:37
lpappAlso, PATCHTOOL is not what I want. I want to have a PREFERRED_PATCHTOOL16:37
lpappi.e. I really do not want to set it for every corresponding recipe.16:38
lpappI want to set a preferred tool, and if it is not like that it can fallback to whatever the default is.16:38
lpappand then it could be set globally.16:38
lpapp(again that would reduce the maintenance per package)16:39
*** JDuke128 <JDuke128!~textual@> has quit IRC16:41
JaMaXz: fixes for dora and dylan are still welcome16:43
rburtonlpapp: you can set PATCHTOOL in a global configuration file16:44
*** n01_ <n01_!> has joined #yocto16:45
lpappPATCHTOOL = "git" -> did not work16:45
lpapprburton: I do not know what will happen for non-git patches if it is not preferred, but mandatory.16:45
bluelightningI wouldn't advise setting it globally16:45
lpappif it is just preferred, the variable is probably called wrong.16:45
bluelightningpatch.bbclass has not been designed to handle any kind of fallback16:45
lpappsounds like a bad design right there16:45
lpappeither way... it does not work even for a single package.16:46
*** n01 <n01!> has quit IRC16:46
lpappit does not apply my changes nicely along with the commit message for the kernel16:46
lpappI used bitbake -c cleansstate virtual/kernel && bitbake virtual/kernel16:46
lpappbut nothing really changed.16:46
lpappis there anything else to try or it just will not work?16:47
*** panda84kde <panda84kde!> has quit IRC16:50
lpappI 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 IRC16:57
lpappso what will happen to PATCHTOOL = "git" if the patch is not actually a git formatted patch?17:03
rburtonlpapp: bluelightning said it does "git am", so that will fail.17:07
rburtonso do_patch presumably fails17:07
lpappwell, I would get a fallback prompt to fix stuff17:08
lpappunless Yocto is broken there.17:08
lpappwell, in fact, it should stop by giving an error message anyway.17:08
lpappor at least a big warning.17:08
rburtonof 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!> has joined #yocto17:10
lpappbecause that would be way over-engineered.17:11
lpappcreating branch for a few changes, and then store them somewhere else, maintain them separately, etc, etc.17:11
lpappthe whole point of using git for this is to avoid that.17:11
lpappotherwise I would not use git in the first place.17:11
rburtonbut i'm saying use git17:11
lpappI would just grab a released tarball (basically a forked version)17:11
lpappthe whole point of using git is to help with applying and modifying patches.17:12
lpappwhile preserving upstream as is.17:12
*** W1N9Zr0 <W1N9Zr0!> has joined #yocto17:14
*** belen <belen!Adium@nat/intel/x-sjwpgcnahikoihxq> has quit IRC17:14
*** dany <dany!~Thunderbi@> has quit IRC17:16
*** behanw <behanw!~behanw@> has joined #yocto17:19
lpappwhere can I find the git apply log?17:20
lpappit might very well be a bug in Yocto not reporting errors properly.17:20
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC17:20
*** ant_work <ant_work!> has quit IRC17:20
rburtonthe patch log, as usual17:21
lpappwhere is that17:22
lpappseems to be in workdir/temp17:22
rburtonthat's where all the logs for all the tasks for all the recipes go17:23
lpappthe file does not have any kinda error, nor warning inside.17:23
*** fray <fray!> has quit IRC17:23
lpappeven though I clearly put non-git patches in there for a test.17:23
rburtonwhere did you set PATCHTOOL?17:23
lpappPATCHTOOL = "git"17:24
lpappSRC_URI = "git://;protocol=git;branch=${KBRANCH} \17:24
rburtonso in a recipe17:24
* rburton shrugs17:24
rburtonnever used it, you'd have to debug it17:24
lpappwell, it already has debug log level based on the DEBUG lines in the log.17:25
*** sakoman <sakoman!> has quit IRC17:26
JaMalpapp: bluelightning: I think it's using git apply not git am17:26
*** jwhitmore <jwhitmore!> has quit IRC17:26
JaMasee meta/lib/oe/patch.py17:26
bluelightningJaMa: you might be right, I didn't actually check17:26
lpappso 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!> has joined #yocto17:28
JaMalpapp: you can always send patch as you're probably only one requesting it17:28
lpappbtw, 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
rburtonlpapp: for a simple operation such as "apply a patch", that's another host dependency we'd need.17:29
lpappJaMa: 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
lpapprburton: if you check the git operations used, you will see it is not just patch17:30
lpappmoreover, python dependencies come for almost free.17:30
lpappit is the matter of a trivial installation mostly.17:30
lpapppypi, etc.17:30
lpapp(but really, these things are usually part of the distros either way)17:30
lpapprburton: well, once the git output changes in a relevant way, it gets broken.17:31
lpappthat cannot really happen with a source compatible lib.17:31
lpappso, it is not like a non-worthy dep for increased stability IMHO. :)17:32
lpappweren't you speaking about reproducability above anyhow? :]17:32
rburtonpatches welcome. :)17:32
lpappI guess... :)17:33
lpappanyway, the most important patch would be git am.17:33
lpappIMO, it is acceptable to use git am by default rather than git apply.17:33
lpappsince if it is not a git repository, patch can still apply git formatted patches.17:34
JaMahmm, but git apply can apply patches without headers, which is more common17:34
lpappwhat do you mean by headers in this context?17:35
JaMaauthor, subject,date17:35
rburtonlpapp: curious: what is the reason that you want a branch in WORKDIR with the patches as commits?17:35
lpappJaMa: patch will work for that, too.17:36
lpapprburton: I do not wanna branch17:36
lpapprburton: I wanna have a patchset like with quilt, etc.17:37
lpappI *would* like to avoid branches if possible.17:37
lpappsince that is a maintenance overhead for us.17:37
rburtonlpapp: if you're applying patches with git am, you'll get a branch17:37
lpappI 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
rburtoni'll re-phrase. why do you want to apply patches with "git am" instead of "git apply" in the WORKDIR17:37
lpapprburton: cause you cannot rebase17:37
lpappwhich can be a problem at >1 patch.17:38
lpappwhich is quite common for the linux kernel from hardware vendors, I would say. :)17:38
rburtonwhich is why most people's kernel trees are maintained as branches17:38
rburtonlpapp: so you'd unpack/patch, go into the workdir, rebase to a different tag, and re-generate the patch set?17:39
lpappwe *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
lpappI do not wanna maintain branches17:39
lpapppatches are fine as they have been for a couple of years in my career17:39
lpappincluding the quilt time.17:39
lpappdpatch, etc.17:39
rburtonlpapp: was my question about your workflow right?17:40
lpapprburton: git rebase -i HEAD~X ... git format-patch  HEAD~X --cover-letter --numbered -s -o patch-folder-next-to-the-recipe17:40
lpappthis would be the ideal development workflow for a kernel developer like me.17:41
lpappcurrently, the missing bridge is the lacking git am ....17:42
lpappI will take a look into it during christmas, I think.17:42
lpapphopefully, it is easy to fix.17:42
rburtonlpapp: fwiw, the kernel developers i know do it the other way around.17:43
lpapprburton: 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
lpappbecause currently, it is impossibly hard to work and test patches within Yocto.17:43
lpapprburton: so you have got a different personal taste then now. ;-)17:44
lpappyour experience is extended.17:44
lpappfor 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
lpappsince this way I will keep vanilla history always as is, and I apply changes on top of it17:46
lpappthe other way around would result a mixed history with changes in-between.17:46
lpappand it might be that upstreaming a change will happen in a different way17:47
lpappand then your branch is not in sync anymore.....17:47
lpappyeah, I really prefer patchset applied by quilt/dpatch/git am/etc.17:47
*** ramose_ <ramose_!6a4e621f@gateway/web/freenode/ip.> has joined #yocto17:52
ramose_How Do I rectify this?17:53
ramose_DEBUG: Searching for source_mirror/sources/ in paths17:53
ramose_I know I don't have "" in my source mirror17:54
rburtona source mirror you maintain?17:54
rburtonramose_: 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 MB) but17:55
rburtonramose_: (so you'll probably need to force a fetch to re-generate it, or something)17:55
rburtonand yes, it's HUGE.17:55
ramose_beacause of limited interent bandwidh I can't download or clone
rburton1.4 git!17:56
rburtongig even17:56
ramose_yes rburton :source mirror I am mainting17:56
rburtonramose_: maybe "bitbake rpi-firmware -c fetch" (replace recipe name with the right one) will be enough, from looking at the source17:57
rburtonramose_: (on the machine that can write there, with BB_GENERATE_MIRROR_TARBALLS=1)17:57
ramose_but it will start fetching "" which I can't afford as I have limited internet bandwidth17:58
*** n01_ <n01_!> has quit IRC17:59
rburton*on the machine that writes to the mirror*17:59
ramose_My question is Can I use already downloaded firmware-master.zip17:59
rburtonso its not using a mirror, and will generate a tarball from the existing directory17:59
lpapprburton: ok, well, I will look into this git apply, but I think having git am is reasonable.17:59
lpappand as a fallback, it could try patch.17:59
rburtonramose_: no idea, haven't done a rpi build for about a year17:59
lpappif it is too much effort, I will develop outside Yocto, and test within Yocto, I guess.18:00
lpapprburton: my worry about the vendor branch is the lack of decoupling.18:01
lpappI would not know anymore clearly without much effort what is upstream and what not.18:01
lpappit would be a mixed history without clear distinction like with a patchset.18:01
lpappI like clear distinction.18:01
lpappI do not think that is achieved by vendor branches.18:02
lpappI mean easily, that is.18:02
ramose_rburton: this is done with linux source18:02
rburtonsure it can.  where your branch diverges from upstream is where your stuff is.18:02
lpapprburton: that is not as easy to see as with an enumerated patch set.18:03
lpappmoreover, it will be impossible to rebase without force push.18:03
lpappwhich makes upstreaming changes later lotta harder.18:03
*** n01 <n01!> has joined #yocto18:03
rburtoni'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/ +++ b/recipes-kernel/linux/ @@ -1,5 +1,5 @@  SRCREV = "b49aafd02fa7572d387acd34550beea5b4c3d239" -SRC_URI = "git://;protocol=git;branch=rpi-3.10.y \ +SRC_URI = "file:// \             file://sl030raspberrypii2ckernel.patch \18:04
lpappok, thanks, merry christmas.18:04
ramose_Sorry I don't know how to provide text editor link here18:05
ramose_rburton: I have modified the SRC_URI in kernel recipe to pick the downloaded .zip file instead of clone the linux.git18:08
ramose_but not sure how Can I do the same for firmware recipe18:08
lpapprburton: I am afraid he is gone for the christmas holiday.18:14
lpappramose_: (sorry)18:14
*** ramose_ <ramose_!6a4e621f@gateway/web/freenode/ip.> has quit IRC18:16
*** Xz <Xz!c0c6972b@gateway/web/freenode/ip.> has quit IRC18:17
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:22
*** n01 <n01!> has quit IRC18:26
*** n01 <n01!> has joined #yocto18:37
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto18:44
*** jwhitmore <jwhitmore!> has joined #yocto19:10
*** reallife <reallife!> has quit IRC19:18
*** wgao_ <wgao_!~wgao@> has joined #yocto19:20
*** michael_e_brown <michael_e_brown!> has joined #yocto19:21
*** rtollert_ <rtollert_!~rtollert@> has joined #yocto19:22
*** dany <dany!> has joined #yocto19:25
*** Rootert_ <Rootert_!> has joined #yocto19:26
*** wgao <wgao!~wgao@> has quit IRC19:26
*** lyang0 <lyang0!~lyang001@> has quit IRC19:26
*** walters <walters!> has quit IRC19:26
*** rtollert <rtollert!~rtollert@> has quit IRC19:26
*** michael_e_brown_ <michael_e_brown_!> has quit IRC19:26
*** Rootert <Rootert!> has quit IRC19:26
*** Rootert_ is now known as Rootert19:26
*** n01 <n01!> has quit IRC19:29
*** fray <fray!U2FsdGVkX1@> has joined #yocto19:32
*** walters <walters!> has joined #yocto19:33
*** reallife <reallife!> has joined #yocto19:34
*** lyang0 <lyang0!~lyang001@> has joined #yocto19:36
*** reallife <reallife!> has quit IRC19:45
*** reallife <reallife!> has joined #yocto19:46
*** rburton <rburton!> has quit IRC19:47
*** rburton <rburton!> has joined #yocto19:49
*** sroy <sroy!> has quit IRC20:00
*** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto20:13
*** dvhart <dvhart!dvhart@nat/intel/x-cinakwaljhagyzti> has joined #yocto20:32
*** kalyank <kalyank!> has quit IRC20:33
*** kalyank <kalyank!> has joined #yocto20:34
*** rburton <rburton!> has left #yocto20:43
*** Xz <Xz!c0c6972c@gateway/web/freenode/ip.> has joined #yocto20:49
Xzhi there20:49
Xzis there any Yocto variable giving me 'target' I compile for?20:49
*** jwhitmore <jwhitmore!> has quit IRC20:51
XzI think it might be ${TARGET_ARCH}20:51
bluelightningdepending on how detailed you want it...20:51
Xzand ${S} is directory where I have all source files?20:52
bluelightningfor a recipe20:52
XzI just have unusual configure script20:52
Xzhave to figure out semi-manually how to execute it with correct flags20:52
Xzoe_runconf appends whole set of flags, so doesn't work for me20:53
*** fray <fray!U2FsdGVkX1@> has quit IRC20:53
*** fray <fray!> has joined #yocto20:54
bluelightningXz: is this an autoconf-generated configure script or a hand-written one?21:03
Xzbluelightning: it's defo hand-written21:03
Xzbluelightning: it comes from 'bitlbee' - I'm trying to create recipe for that21:04
bluelightningXz: right, in that case you should not inherit autotools if you currently are21:04
Xzbluelightning: yes, I am21:04
Xzbluelightning: so I should write my own do_configure and do_compile?21:04
bluelightningXz: 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 that21:05
bluelightningXz: FYI, there is an old OE-Classic recipe here if it helps:
Xzbluelightning: cool, didn't find it21:06
Xzbluelightning: actual version is 3.2.121:06
bluelightningXz: FYI you can search OE-Classic in the layer index by going to Recipes and then dropping down the branch selector and selecting OE-Classic21:07
XzOE-Classic is not maintained anymore? That's my understanding21:08
bluelightningit's not, no... but it's sometimes useful to resurrect recipes from there, so we index it (separately)21:09
Xzbluelightning: I already have 'irssi' - ncurses IRC client21:12
Xzbluelightning: now just need bitlbee to connect that to facebook chat and others21:13
Xzbluelightning: gonna place that next to my router, up and running 24/721:13
bluelightningnice :)21:14
Xzbluelightning: didn't find anywhere irssi recipe, but that one was easier to create21:14
Xzbluelightning: I might send that to openembedded-core21:14
Xzbluelightning: or openembedded-devel21:14
bluelightningwe definitely had irssi recipes in OE-Classic21:15
bluelightningright, it's probably something for meta-oe21:15
bluelightningthat would be much appreciated btw :)21:15
Xzbluelightning: cool21:16
Xzbluelightning: however I always have a problem - where to put it21:16
Xzbluelightning: 1st - poky/meta-oe, 2nd which directory: recipes-extended? recipes-xyz21:16
bluelightningmeta-oe/recipes-connectivity for these two I thin21:17
bluelightningwe do have a meta-networking, but I'm not sure IRC/IM-related stuff really fits there21:17
Xzbluelightning: ok, once I have that ready - I will try to send a patch (recipes-connectivity) and see what happens21:18
*** sakoman <sakoman!> has quit IRC21:46
*** sakoman <sakoman!> has joined #yocto21:48
*** dany <dany!> has quit IRC21:52
Xzin oe-classic's version of bitlbee there is one step: pkg_postinst. Is there any matching step in current Yocto?21:52
XzI got it compiling, will give it a go on board soon :)21:53
Xzjust curious about that pkg_postinst step21:53
bluelightningXz: 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
bluelightningXz: you should suffix it with _${PN} though so it's only applied to the main package21:59
bluelightningXz: also use $D (_not_ ${D}) before all paths so that the script can run at image creation time if it needs to22:00
*** walters <walters!> has quit IRC22:02
*** dvhart <dvhart!dvhart@nat/intel/x-cinakwaljhagyzti> has quit IRC22:30
*** bfederau <bfederau!> has quit IRC23:01
*** bfederau <bfederau!> has joined #yocto23:01
*** fpaut is now known as fpaut_23:05
*** seebs <seebs!> has quit IRC23:23
*** ant_home <ant_home!> has joined #yocto23:25
*** seebs <seebs!> has joined #yocto23:25
*** seebs <seebs!> has joined #yocto23:27
*** n01 <n01!> has joined #yocto23:34
*** jackmitchell <jackmitchell!> has joined #yocto23:35
*** agust <agust!> has quit IRC23:40
*** ant_home <ant_home!> has quit IRC23:50
*** jackmitchell <jackmitchell!> has quit IRC23:52
*** SorenHolm <SorenHolm!> has joined #yocto23:59

Generated by 2.11.0 by Marius Gedminas - find it at!