**** BEGIN LOGGING AT Thu Apr 03 02:59:59 2014 Apr 03 03:24:39 i suspect the DEPENDS list of a recipe is wrong, is there a bitbake command to clean up the sysroot of the files from a given set of packages (i.e. the list of packages in the DEPENDS)? Apr 03 06:14:37 when using common OE layers, your build fetches a lot of URIs from internet. If I were to make a build, wait 10 years and try to reproduce it, some of these URIs will likely have changed or gone away. What is the recommended way to store all inputs to a OE build (ie downloads, configs, etc etc), preferrably in a SCM? Apr 03 06:16:10 the most common solution is to setup your own source mirror Apr 03 06:16:33 e.g. http://sources.angstrom-distribution.org/v2013.12/ Apr 03 06:16:53 if you add that as a MIRROR in OE it will fallback to that if upstream goes missing Apr 03 06:17:00 not sure if you can put it in an SCM Apr 03 06:17:28 ok, thats fine. I did not mean I wanted to put all the downloads in SCM, but I do like to track my OE metadata in SCM Apr 03 06:17:51 so if I were to create my own mirror, I don't need to override every single recipe with a bbappend to change the SRC_URI? Apr 03 06:20:53 no :) Apr 03 06:21:11 OE tries to fetch from PREMIRROR, SRC_URI and finally MIRROR Apr 03 06:21:26 (or PREMIRRORS, it's been a while since I looked at that) Apr 03 06:21:58 and I guess there is a clever scheme to make a git:// url get translated into a http:// mirror then? Or do I have to replicate the exact structure of the internet, ie. separate repositories, http and other scms? Apr 03 06:24:37 it has a clever scheme for that Apr 03 06:25:07 mago_: https://github.com/Angstrom-distribution/meta-angstrom/blob/angstrom-v2013.12-yocto1.5/classes/angstrom-mirrors.bbclass Apr 03 06:25:31 so instead of trying to download from e.g. svn it will try to fetch a tarball from the mirrors first Apr 03 06:25:43 thats cool Apr 03 06:26:23 after your build finishes rsync DL_DIR to a webserver and you have your mirror Apr 03 06:30:01 my DL_DIR seems to contain subdirs like ./git2//, but those are git repos, not tarballs of the repo Apr 03 06:46:13 mago_: you can ignore those dirs Apr 03 06:48:40 koen, i don't see any corresponding tarball in the ${DL_DIR} root. For example, there is a ${DL_DIR}/git2/github.com.nmav.cryptodev-linux.git .. shouldn't t there be a cryptodev tarball in ${DL_DIR} then? Apr 03 06:49:00 or from where does it fetch the sources for this recipe? (if not git2-directory) Apr 03 06:50:45 hmmm Apr 03 06:50:47 let me see Apr 03 06:51:37 there's BB_GENERATE_MIRROR_TARBALLS = "1" you can set Apr 03 06:51:48 but AIUI it should generate a tarball by default Apr 03 06:51:56 the BB_GENERATE_MIRROR_TARBALLS will just make 'versioned' tarballs Apr 03 06:52:12 e.g. github.com.nmav.cryptodev-linux-073758327528307807d8923.tar Apr 03 06:52:24 like I said, it's been a while since I looked at it :) Apr 03 07:32:57 lets say i've customized a OE-based distribution by adding a few local overrides in my ./build/conf/local.conf file. If I want to put this build in a SCM, is it recommended that I move my local changes to a separate layer, or should I just check-in the build directory, excluding files and directories which are generated? if so, how do I know which files contain input and which files are generated? Apr 03 07:37:32 I'd just create a new layer with a proper distro config Apr 03 07:37:38 but do whatever works for you Apr 03 07:42:26 but still, if i want to check-out something and have it re-produce an exact build, will there not always be some kind of manual step involved unless i also check-in the build directory? Apr 03 07:43:22 like, most OE-distros has a little wiki section that describes how you must run some shell script, source some other shellscript to setup the environment etc Apr 03 09:33:15 morning all# Apr 03 09:36:10 trouble getting up this morning bluelightning ? :) later than usual Apr 03 09:38:10 (also, good morning!) Apr 03 09:39:40 mago_: yes, but I wasn't late in, just late saying hello... sorry about that ;) Apr 03 09:41:38 bluelightning, what would you say is the most significant reason(s) for choosing openembedded over buildroot? Apr 03 09:42:17 mago_: I have to admit to not being a buildroot expert, but the general feeling is greater flexibility Apr 03 09:42:49 flexibility in what sense? Apr 03 09:42:57 buildroot is a lake, openembedded is an ocean! Apr 03 09:42:59 in just about every sense Apr 03 09:43:26 perhaps other folks with buildroot experience can chime in Apr 03 09:43:33 i see. i will remember that quote matt10|work =) Apr 03 09:44:44 i've written a short report on the differences between OE and BR, and i'm coming the conclusion that OE is more suitable for generating general and complete systems, while Buildroot is excellent for generating root filesystems for specialized applications running on specialized hardware Apr 03 09:46:47 i'll ask the same question in #buildroot :) (only, the other way around) Apr 03 09:50:52 I think a blog post / article on this from a neutral perspective would be good to have Apr 03 09:51:49 indeed Apr 03 09:51:50 hi guys Apr 03 09:52:07 hi hrw! Apr 03 09:52:12 mago_: I never used buildroot but does it create any packages or only rootfs images? Apr 03 09:52:30 I thought I heard they were adding optional packaging support Apr 03 09:52:40 mago_: cause OE rootfses can be upgraded on device with packages fetched from local/remote repos Apr 03 09:54:39 hrw, no, it does not support binary packages. it is an active design decision of BR, it seems Apr 03 09:55:42 mago_: I used OE also to build native tools on systems where I did not had root permissions to install packages. was easier than building them by hand and tracking dependencies Apr 03 09:56:43 in my report, I fear that OE has received a small edge. Mostly because it looks very good on paper (feature-wise, flexibility etc), while one of the biggest strengths of BR is its simplicity. It is very difficult to express this 'simplicity property' in a report,because it is difficult to measure Apr 03 09:56:59 so i think my report is not truly a neutral perspective Apr 03 09:59:14 mago_: before OE we have OpenZaurus buildsystem which was very highly modified buildroot. OE got created cause there was no easy way to expand BR to have what OZ devs wanted Apr 03 10:03:34 it's true that it took me maybe a year to follow/understand things Apr 03 10:04:15 oe-core is moving fast, and variables are changing names, the way of doing thinks change Apr 03 10:06:08 For example (in my experience): ALTERNATIVE_LINKS moved to ALTERNATIVE_LINKS; packagegroup; SSHSERVER_IMAGE_FEATURES & tinylogin vanished.. Apr 03 10:06:34 this is sure enhancements, but it is some hard to follow (requires time) Apr 03 10:06:51 s/some/sometimes/ Apr 03 10:07:31 and more recently PR, PRINC, PRServer ! Apr 03 10:13:27 mago_: check out what one of buildroot main devs thinks on page #5 http://elinux.org/images/9/9e/Buildroot2.pdf Apr 03 10:15:05 and for the casual user OE/YP offer graphical frontends for bitbake Apr 03 10:35:51 mago_: A big item when choosing upstream is to also consider the number of users/testers. More of them usually equals better quality. Apr 03 11:35:13 LICENSE = "LGPLv2.1 | GPLv3" Apr 03 11:35:16 :LICENSE = "LGPLv2.1 & GPLv3" Apr 03 11:35:22 LICENSE = "LGPLv2.1 + GPLv3" Apr 03 11:35:26 LICENSE = "LGPLv2.1 GPLv3" Apr 03 11:35:31 what is the correct way ? Apr 03 11:35:58 | or & Apr 03 11:36:12 which one depends on the specific licensing Apr 03 11:37:11 So for my company, I would have LICENSE = "CLOSED & MyCompanyLicenseName" Apr 03 11:37:25 Closed allow to not have LIC_FILES_CHKSUM in the recipe Apr 03 11:38:00 is it correct ? Apr 03 11:45:22 don't know, sorry Apr 03 11:48:34 LICENSE_PATH[doc] = "Path to additional licenses used during the build." Apr 03 11:48:50 This is a little short I think Apr 03 11:51:06 How about adding: Apr 03 11:51:17 Lists the licenses separated by '&' or '|' (according semantic). Apr 03 11:52:35 Sorry, I meant for: LICENSE[doc] = "The list of source licenses for the recipe." Apr 03 11:53:50 LICENSE[doc] = "The list of source licenses for the recipe separated by '&' or '|' (according to semantic)." Apr 03 12:54:58 is there a way to specify a package or recipe and have the sysroot cleaned of all the files from that package or recipe? Apr 03 12:55:39 -c cleanall ? Apr 03 12:57:26 just -c clean will do that Apr 03 12:59:43 -LICENSE[doc] = "The list of source licenses for the recipe." Apr 03 12:59:49 +LICENSE[doc] = "The list of source licenses for the recipe separated by '&' or '|' (according to semantic). Use CLOSED for proprietary license." Apr 03 13:00:28 Is it ok ? If so, I'll post a patch Apr 03 13:01:19 matt10|work: I'm not sure it's quite that simple though - e.g. a lot of "proprietary" licenses would be better noted as their proper names particularly if you're going to distribute them publicly Apr 03 13:01:22 matt10|work: bluelightning: then i must be doing something wrong Apr 03 13:01:47 tlwoerner: you've not been poking stuff into the sysroot directly, right? Apr 03 13:02:02 (from the recipe I mean) Apr 03 13:02:06 matt10|work: bluelightning: if i go to tmp/qemuarm-eglibc/sysroots and do "find . -name "*avahi*" -print" i get a bunch of stuff Apr 03 13:02:35 bluelightning: i haven't touched the receipes myself Apr 03 13:02:53 I meant that CLOSED is a magic keyword to disable LIC_FILES_CHKSUM check in a recipe Apr 03 13:03:25 bluelightning: i picked a recipe at random, maybe i chose a bad examle? Apr 03 13:03:40 matt10|work: right, I understand the intention; I'm just not sure if encouraging people to use CLOSED for all proprietary licenses is a good idea Apr 03 13:04:32 tlwoerner: are those files installed by the avahi recipe though? Apr 03 13:06:37 bluelightning: these are files that show up in avahi's "packages-split" area Apr 03 13:07:39 bluelightning: i'm looking, for example, at all the locale files Apr 03 13:10:25 tlwoerner: this is in the sysroot dir for the machine you're currently building for, right? Apr 03 13:24:06 bluelightning: yes tmp/qemuarm-eglibc/sysroots/qemuarm Apr 03 13:24:57 then usr/include, usr/lib, and usr/share Apr 03 13:25:36 bluelightning: hold on... there's an avahi-ui recipe too... Apr 03 13:26:25 tlwoerner: ah right of course, forgot about that Apr 03 13:27:29 yes.. i think the remaining avahi* files in the sysroot are from avahi-ui Apr 03 13:27:41 :-) Apr 03 13:27:59 mystery solved :) Apr 03 13:28:34 * tlwoerner should learn to pick better packages at random Apr 03 16:03:29 moin Apr 03 18:11:01 * darknighte encourages Crofton to read the OEDAM signup list again Apr 03 18:13:52 :) Apr 03 18:13:56 I knew that was a rsik Apr 03 18:28:47 join #u-boot Apr 03 18:35:53 ndec: saw you where working on writing a recipe for qtwebengine Apr 03 18:35:57 you got it working already? Apr 03 19:01:11 morphis: hi. well not really. when i started qtwebengine really wasn't in a good state (for eglfs), and now i am working on something else... someone else from linaro might be working on that, though. Apr 03 19:53:14 ndec: thanks for the update! you know who? Apr 03 19:53:53 morphis: yep. zolti on #linaro. i don't see him right now. he is in UTC+2. Apr 03 19:54:19 ndec: thanks, will ping him tomorrow Apr 03 19:54:57 ndec: I am in UTC+2 too so should be easy to each him :) Apr 03 19:55:06 so am I ;-) Apr 03 21:53:23 meta-toolchain still fails on master when it hits alsa-lib Apr 03 21:53:46 er, nativesdk-alsa-lib **** ENDING LOGGING AT Fri Apr 04 02:59:59 2014