**** BEGIN LOGGING AT Fri Dec 20 03:00:00 2013 Dec 20 07:50:29 \join #towergeeks Dec 20 09:39:24 morning all Dec 20 13:52:44 hi everybody. Does anybody know if there's any technical reason for Firefox being stuck at version 10 instead of a more recent ESR release in this layer? https://github.com/OSSystems/meta-browser/tree/master/recipes-mozilla/firefox Dec 20 13:53:14 or is it only that the maintainer is not currently working on it? Dec 20 14:06:30 panda84kde: its probably a case that it works and does what they needed Dec 20 14:12:35 RP: thanks. Maybe otavio knows more Dec 20 14:19:21 does the LICENSE_FLAGS = "commercial" in libav mean "beware, patents in here!"? I see it referenced also here: http://www.crashcourse.ca/wiki/index.php/OE_licenses_and_license_flags Dec 20 14:20:31 panda84kde: more or less, yes Dec 20 14:20:39 IMHO, I would expect a "commercial" license declaration to mean "Intellectual Property", patents and trade secrets. Dec 20 14:21:25 more broadly it's "there might be stuff that's problematic if you want to ship this as part of a commercial product, so do your due diligence and obtain necessary licenses if needed before using" Dec 20 14:21:38 yup Dec 20 14:22:28 bluelightning: no go on exporting that file from my linux source into /usr/include. I'm going to post that on the mailing list, when I find it. heh. Dec 20 14:23:22 T0mW: bottom line is, you have to set FILES for one of the packages such that it picks up the additional file(s) you are installing. If you still get the error, it means you haven't done that properly. Dec 20 14:23:49 T0mW: bluelightning: thanks. Almost what I've expected. Dec 20 14:25:34 bluelightning: yes, this was possible under Bernard. The best I got was an error stating that I my FILES_linux-yocto-custom export was being overwritten. Dec 20 14:26:18 I tried every variation that I could think of for 'FILES_' Dec 20 14:27:18 I'm assuming that the 'FILES_' still has the same meaning as it did under Bernard, that it was telling bitbake et. al. to put this file into the final image at the desired location. Dec 20 14:33:29 T0mW: I think the best thing is to put this all into an email and we'll go from there Dec 20 14:34:45 bluelightning: yes, exactly. It is probably something obvious and we are overthinking it. Let someone else spot the solution. I'm at the point where I'm almost willing to learn python to go tackle the bitbake sources... Dec 20 14:36:45 T0mW: it's very unlikely that will be necessary Dec 20 14:37:24 T0mW: btw, the reason FILES_linux-yocto-custom will not work is that if the recipe is called linux-yocto-custom, then ${PN} is linux-yocto-custom Dec 20 14:38:41 if you then already have a line that says FILES_${PN} = "something" (and you will always have that by default from meta/conf/bitbake.conf), your FILES_linux-yocto-custom gets set *first* and then the name expansion of FILES_${PN} is done second, and your value is overwritten Dec 20 14:39:00 bluelightning: I can work around this, but I'd like to know why I cannot get it to work. It may be a decision on the part of the team to not include exports of files from within the kernel tree. This doesn't make sense as there would be custom hardware (in my case) which a header would need to be exported for use on the target system. The end-customer could install the kernel source of mine, then specify the path to my header file, but th Dec 20 14:39:01 at is kludgy. Dec 20 14:40:27 as far as additional headers installed being the kernel being picked up by default goes, I don't know anything about that I'm afraid Dec 20 14:41:00 yeah, saw that happen. The only thing that I found that may be a solution is what they do in libtool where they add a name to the PACKAGES list, then export files under that package name. Dec 20 14:41:42 PACKAGES =+ "libltdl libltdl-dev libltdl-dbg libltdl-staticdev" Dec 20 14:41:44 then Dec 20 14:41:54 FILES_libltdl = "${libdir}/libltdl${SOLIBS}" Dec 20 14:42:09 it looks like a side-step over some isse Dec 20 14:42:20 s/isse/issue/ Dec 20 14:42:48 I'm going to try that and see what it does. Dec 20 14:54:17 hi, how can I make sure to do a full rebuild for a package, i.e. to reapply the patches? Dec 20 14:54:35 -c apply -f? Dec 20 14:54:50 clearly, the patches next to the recipe does not show the reality. The build folder has a vastly different content Dec 20 14:54:56 some parts of the patch are not really applied. Dec 20 14:58:22 lpapp: -c cleansstate , then bitbake Dec 20 15:01:07 RP: right, thanks. I do not know why, but quilt refresh does not eventually update the original patch file? Do you know why that may happen? Dec 20 15:05:11 quilt refresh Dec 20 15:05:11 Refreshed patch patches/0001-mfd-MAX6650-6651-support.patch Dec 20 15:05:14 yet, it does not actually change. Dec 20 15:05:41 does that mean it is a bug in Yocto? Dec 20 15:06:10 I have done only bitbake virtual/kernel, got the conflict, edit the conflict file, and used quilt refresh Dec 20 15:06:15 did I forget some command? Dec 20 15:06:26 lpapp: what file doesn't change? the patches/blaa.patch in $WORKDIR, or the patch next to the recipe? Dec 20 15:07:28 latter Dec 20 15:08:07 lpapp: are you doing that editing/quilt inside a terminal that do_patch opened for you (the patch failed user resolver), or manually? Dec 20 15:08:31 right, the next in the build stuff is correct Dec 20 15:08:37 so I need to manually copy it back? :O Dec 20 15:08:59 rburton: user resolver in a terminal Dec 20 15:09:15 the source says it copies back when you close the terminal Dec 20 15:09:24 but i've never used it, so it's possibly broken in some way. Dec 20 15:09:27 ok, so there is some bug here. Dec 20 15:10:03 yeah, I can reproduce it anytime Dec 20 15:10:11 the patches in patches/ in the linux tree are ok Dec 20 15:10:19 but after ctrl-d, the recipe patches are still the same. Dec 20 15:10:22 not the updated version. Dec 20 15:10:25 poky-dylan here. Dec 20 15:12:59 rburton: is there some error reporting missing? Dec 20 15:17:02 rburton: it is possible that it is not a bug, but missing something, but even then it is a bug since there is no error reporting. ;-) Dec 20 15:19:43 lpapp: sure. never used this, so i can't help much. Dec 20 15:20:12 rburton: well, I do not really see any copy here really... https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/patch.bbclass Dec 20 15:20:21 where did you see that it actually syncs up? Dec 20 15:21:47 RP: got a clue? Dec 20 15:21:47 patchset.Refresh can call QuiltTree.Refresh() that does copyfile Dec 20 15:22:24 maybe the patchset isnt a QuiltTree instance Dec 20 15:22:43 rburton: ? Dec 20 15:23:47 well, I am here to try any python print from bitbake. Dec 20 15:23:58 if anyone says what to print out... Dec 20 15:24:09 I do not have time currently to track it down on my own as I need proceed with my stuff. Dec 20 15:25:36 rburton: also, it is horrible that if you open up vim, and close it, you do not see the conflicts anymore. Dec 20 15:26:20 is there a way to keep the buffer around? Dec 20 15:27:56 that's up to your terminal and text editor Dec 20 15:30:37 rburton: ok, but how to debug the copy issue? Dec 20 15:30:58 lpapp: the usual way? Dec 20 15:31:05 insert debugging statement or use a debugger. Dec 20 15:31:14 rburton: no, I mean, what to insert Dec 20 15:31:18 I am not aware of this codebase. Dec 20 15:31:24 and you cannot probably reproduce the issue just yet. Dec 20 15:31:30 dude you've got about ten minutes less experience with this module than me Dec 20 15:31:50 i'd start by inserting "print HERE" statements so you know where it's actually executing Dec 20 15:32:02 :) Dec 20 15:32:15 hopefully RP can help then... Dec 20 15:45:41 What would be the proper way to ensure that something from the native sysroot is in the PATH so that a Makefile uses it.. Dec 20 15:46:49 Just a prepend and an `export PATH=${STAGING_BINDIR_NATIVE}:$PATH` ? Dec 20 15:49:19 the native sysroot is in the path already Dec 20 15:49:42 hrm Dec 20 15:51:18 interesting. Dec 20 15:51:29 seems rsync not installed.. Dec 20 15:52:30 I had to patch something the other day that was looking for `file`, which WAS in the native bindir, but was not being found Dec 20 15:52:37 and now I have this issue here, again. Dec 20 15:53:21 So, either native is not actually in the path by default, or something is screwing it up Dec 20 15:53:36 WarheadsSE: use -c devshell to check the PATH yourself. but maybe the check tries /usr/bin/foo first? Dec 20 15:53:36 Hi. Is it possible to get git annex to work as a part of the fetch step of a yocto recipe? Dec 20 15:54:30 WarheadsSE: i've seen configure scripts that hard-code common prefixes and then go hunting Dec 20 15:54:58 yeah.. Dec 20 15:55:03 this is outright in the makefile. Dec 20 15:55:18 yep Dec 20 15:55:21 just a plain `rsync -av ` Dec 20 15:55:46 rsync in a makefile? Dec 20 15:55:50 how interesting Dec 20 15:55:51 yeah.. Dec 20 15:56:01 cp not good enough to install with? :) Dec 20 15:56:11 apparently they are using it for some sort of translation layer in html .. Dec 20 15:57:31 hah .. hard to enter a devshell when you have no terminal (ty docker, and me not having included screen) Dec 20 15:57:50 ha Dec 20 15:57:55 yeah that would be a problem Dec 20 15:58:07 basically its got the native sysroot near the beginning Dec 20 15:58:17 and it should Dec 20 15:58:27 bitbake.conf:PATH_prepend = "${COREBASE}/scripts:${STAGING_BINDIR_TOOLCHAIN}:${STAGING_BINDIR_CROSS}:${STAGING_DIR_NA Dec 20 15:58:29 which I did note a minute ago, that rsync is apparently not in the sysroot Dec 20 15:58:42 WarheadsSE: did you put DEPENDS=rsync-native? Dec 20 15:58:50 rsync-native .. mmmm Dec 20 15:58:55 without that, it won't be :) Dec 20 15:58:59 * WarheadsSE edits recipe Dec 20 16:03:05 * WarheadsSE tests Dec 20 16:03:17 Yeah, i had rsycn in there.. derp'd not adding -native Dec 20 16:03:42 invoice is in the mail Dec 20 16:04:53 * WarheadsSE tosses haypenny in envelope marked with postage paid Dec 20 16:25:26 rburton: hrm.. Dec 20 16:25:37 what exactly is this feature I should look for that gets the linux kernel from git? Dec 20 16:25:40 added in danny? Dec 20 16:27:26 lpapp: linux-yocto has been fetching from git for a long time Dec 20 16:28:07 SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v3.0/linux-${PV}.tar.bz2;name=kernel \ Dec 20 16:28:10 right, I have that. Dec 20 16:29:01 rburton: but does that mean we end up again having the git in git trap? Dec 20 16:29:18 lpapp: many recipes fetch from git repos Dec 20 16:29:35 rburton: yes, but remember, we check Yocto into git. Dec 20 16:29:38 along with the downloaded folders. Dec 20 16:29:49 and remember we've said don't check download/ into git Dec 20 16:29:53 or the downloads folder will have the tarball with .git inside? Dec 20 16:30:01 you can tell it to make tarballs, iirc Dec 20 16:30:08 well, I remember, but it would be lotta work to refactor. Dec 20 16:30:16 BB_GENERATE_MIRROR_TARBALLS, or something. Dec 20 16:30:30 that will avoid git which I want to have for linux kernel development Dec 20 16:30:40 or you mean, that generates tarball with .git inside? Dec 20 16:32:11 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-BB_GENERATE_MIRROR_TARBALLS Dec 20 16:33:15 rburton: that does not make it clear, so I should file a bugreport Dec 20 16:33:23 it does not make it clear that it archives it with or without .git Dec 20 16:33:48 "makes a tarball of the git repository" Dec 20 16:33:51 can't really get any clearer Dec 20 16:33:54 it kinda feels like it uses .git inside, but cannot be sure Dec 20 16:34:01 rburton: well, it is fully unclear to me. Dec 20 16:34:12 git archive also archives the repository, but /without/ .git. Dec 20 16:34:32 "tarball of the git repository". not "copy of the working directory". Dec 20 16:34:56 see how confusing it is? Dec 20 16:35:00 not at all Dec 20 16:35:09 its a tarball, the contents of which are the git repository Dec 20 16:35:11 you think I am lying when I say I am fully confused? Dec 20 16:35:18 the git repository is the thing you get when you do a git clone. Dec 20 16:35:18 the git repository contains .git Dec 20 16:35:29 but then again, git archive also archives the repository, without .git Dec 20 16:35:35 no it doesn't Dec 20 16:35:46 ask 10 people, and see how many of them will be confused. :) Dec 20 16:35:54 git-archive creates a copy of the working tree Dec 20 16:36:22 nope Dec 20 16:36:38 there isn't debate over the meaning of "git repository". and it's in a tarball. Dec 20 16:36:54 what even shows more my confusion, I still do not understand what this variable actually does Dec 20 16:37:03 after this long conversation Dec 20 16:39:31 is there a way to specify that a SRC_URI fetched via git should get the fully repo (clone) and not a shallow clone? Dec 20 16:40:07 g28: it is a full clone Dec 20 16:40:52 i need to run git annex get to retrieve some binary data files that are part of our git codebase, but they fail to load. the errors seem to indicate that references to other branches are missing Dec 20 16:41:55 g28: so there's a clone made to DL_DIR, and then that is re-cloned to the work directory Dec 20 16:42:07 g28: presumably that's dropping the remote refs as they're a step removed Dec 20 16:42:14 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5684 Dec 20 16:42:15 Bug 5684: normal, Undecided, ---, scott.m.rifenbark, NEW , Unclear BB_GENERATE_MIRROR_TARBALLS documentation Dec 20 16:42:30 g28: you might need to write a gitannex fetcher :/ Dec 20 16:42:45 rburton: thanks. this gives me a couple hints Dec 20 16:43:30 g28: this might be evil, but you can tell it to do a bare clone to WORKDIR (which causes it to be a mirror) and then checkout yourself. Dec 20 16:43:54 g28: try ;bareclone=1 in your SRC_URI, and then do a checkout before any annex stuff Dec 20 16:44:14 * rburton really isn't liking how often he's looked at the fetcher this month Dec 20 16:52:03 g28: You'll probably need a subclass of the git fetcher with annex capabilities added. the sumbmodules one (gitsm) is a kind of example of how to do that. I doubt it will work out the box Dec 20 17:31:23 rburton: crraaap .. so "WARNING: Screen started. Please connect in another terminal with "screen -r devshell" Dec 20 17:44:16 moin Dec 21 01:00:28 bluelightning: solved it, went side-ways: added a package with PACKAGES+="linux-extra", then FILES_linux-extra="${includedir}/*" Dec 21 01:01:06 bluelightning: then, added "linux-extra" to IMAGE_EXTRAS Dec 21 01:02:56 T0mW: right, that would work Dec 21 01:03:11 T0mW: I would have thought kernel-dev would have been the package to put this kind of thing in though Dec 21 01:03:37 bluelightning: I'll still make a bug-report about it, let someone in the know possibly just close the bug as extraneous. Dec 21 01:04:33 T0mW: good stuff, I'd like to have a clear statement of whether or not we should support this kind of thing out of the box (it seems to me we should, but I'm no kind of kernel expert) Dec 21 01:04:49 bluelightning: well, no, it is a file that describes the IOCTL interface to some modules. It really doesn't qualify as a kernel-dev as that implies you need the whole kernel source. Just the headers should be enough, that is what I was trying to export: a header file. Dec 21 01:05:14 hmm ok Dec 21 01:07:38 the hardware in both my target systems (arm920t and ATOM N450) have custom PLD driven elements. That would only necessitate exposing the IO interface of the modules, you wouldn't need the whole kernel source. AAMOF, forcing someone to install the dev kernel would be obfusicating things, to a degree. Dec 21 01:08:46 anyway, bug report, later. Dec 21 01:09:03 I think I don't know enough about this to offer a coherent response, but filing the bug should prompt it to be handled by folks that do Dec 21 01:09:12 nod Dec 21 01:11:46 thanks **** ENDING LOGGING AT Sat Dec 21 02:59:59 2013