**** BEGIN LOGGING AT Wed Jul 10 02:59:59 2013 Jul 10 06:11:40 echo 'INHERIT += "rm_work"' > meta/conf/bitbake.conf did not help as in, I am still not getting the built stuff removed. Any clue for something working? Jul 10 06:36:42 rburton_: what is the reasoning to have the busybox syslogd have two different config files depending on systemd || sysvinit? Jul 10 07:28:16 hi, is it enough to issue bitbake minimal-core-image to resume the operation from yesterday? Jul 10 08:11:55 morning all Jul 10 08:12:05 moin Jul 10 08:36:53 Hello all. Jul 10 08:38:56 I have a pretty strange error. I have a custom packagegroup which is included in an image. When i increment the pr in that pkggroup, from time to time, i get this error: http://pastebin.com/9L7Qn8yu Jul 10 08:40:26 Here is the packagegroup file: http://pastebin.com/B2nSrDpE Jul 10 08:40:43 Anybody saw this before and can give me a hint? Jul 10 08:41:35 agherzan: is the file it cannot find matching the old pr ? Jul 10 08:41:38 bluelightning: morning Jul 10 08:41:46 hi zecke Jul 10 08:42:07 tf: sorry, didn't understand Jul 10 08:42:31 bluelightning: I had a question for rburton but maybe you happen to know the answer too. Currently there are two ways to configure the busybox syslogd. They depend on whether systemd or sysvinit is used Jul 10 08:42:47 agherzan: packagegroup-multimedia-1.0-r1: is r1 the current or the previous pr? Jul 10 08:43:21 tf: r3 is current, r2 was previous Jul 10 08:43:48 tf: just an increment Jul 10 08:43:54 zecke: right, it's a similar situation for a few daemons Jul 10 08:44:07 so, there is something in the buildstats task that is not getting rebuilt Jul 10 08:44:11 zecke: I think we unified it for ntpd in meta-oe though, so it should be fixable Jul 10 08:45:34 tf: sorry for the confusion. the packagemanager was packagegroup-multimedia. And i pasted the graphics. Indeed the old pr was 1 and now is 2. Jul 10 08:47:14 agherzan: take a look at the run_buildstats script, see why it did not rebuilt Jul 10 08:48:15 tf thanks. the problem is that i lost it already as i forced the rebuild... Jul 10 08:48:43 it looks like it is taking something from the state cache that it should not Jul 10 08:51:34 bluelightning: does it make sense to open a ticket? For my product I am mostly 'convinced' (the performance issues are not bad enough to discard it) but I will use the busybox syslogd instead of the journald for now. But our BSP layer targets multiple versions of Yocto/Poky and having one file to select things would be appreciated. :) Jul 10 08:52:19 zecke: yes please file an enhancement request for this Jul 10 09:01:20 Hi Jul 10 09:01:30 PACKAGEFUNC Jul 10 09:01:38 I have added a function to this. Jul 10 09:02:09 but uImage and dtb file are not found from package direcories. Jul 10 09:04:08 bluelightning_: I filed #4837. If someone would ack that the proposed solution is okay, then I can send a patch for that Jul 10 09:04:38 rburton_: good morning, do you have time to comment on https://bugzilla.yoctoproject.org/show_bug.cgi?id=4837? it is about busybox syslog and systemd vs. sysvinit in regard to config files Jul 10 09:04:40 Bug 4837: enhancement, Undecided, ---, saul.wold, NEW , busybox syslog has two different configuration files depending on the init system Jul 10 09:06:01 Hi I asked yesterday what is best way to sign files and packages. I have create a class to add function to PACKAGEFUNCS Jul 10 09:06:51 I guess PACKAGEFUNCS can be used to sign the files Jul 10 09:07:13 but how can I sign the uimage and dtb files? and how should I sign the packages? Jul 10 09:08:06 Should I create a seperate class for linux and other one for recipes Jul 10 09:08:06 ? Jul 10 09:09:31 goddamn 3g Jul 10 09:10:27 Can anybody comment? Jul 10 10:08:03 How do I get yocto to print bb.note() messages to screeen during compilation? Jul 10 10:08:19 like it does for bb.warn Jul 10 10:10:12 or are those only printed to log_* files Jul 10 10:10:28 Mic, note message end up only in log files Jul 10 10:10:48 is there any way to print informative message s to screen Jul 10 10:16:21 Mic: you can do bb.plain, but generally we avoid printing informational messages from the metadata outside of logs Jul 10 10:17:09 alright Jul 10 10:20:02 I spoke to you yesterday about PACKAGEFUNCS. Do you think this method can be used for signing the packet rpm? Jul 10 10:34:26 Morning all! Sorry another newbie question from me - Just getting my head around layers... I want to create a new layer that contains all my project specific customisations that go on top of the BSP i.e. application, additional conf, some out of tree modules and so on. I assume this is the right thing to do. What I can't work out is how that relates to existing layers... The image(s) I build at the mo come from image bb files in the BSP layer. Do I somehow inherit / Jul 10 10:34:26 extend these from my new layer or do I change the BSP layer to reference my new one? Sorry it's a bit vague but I can't work it out yet from the docs! Jul 10 10:39:16 pev, you have a list of layers to use in the bblayers.conf Jul 10 10:39:39 each leayer has a priority number (in it's own layer.conf) Jul 10 10:40:12 this is used to determine which recipe to use if there same recipe is in more than one layer Jul 10 10:41:25 conf files are slightly different; they get pulled out in the order in which the layers are added to the layers path in the bblayers.conf Jul 10 10:42:20 if you need to modify a recipe that is in some other layer, you do that using a bbappend Jul 10 10:43:18 I've been reading up on that and think I have a rough understanding... Its more that at the moment I build the image via the target meta-mybsp/packages/images/my-image.bb Jul 10 10:44:05 so if I create my new layer (say meta-myapp) with the app specific stuff in, am I trying to bbappend that image from the other layer or do I somehow reference meta-myapp from whats in meta-mybsp? Jul 10 10:44:40 pev: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html Jul 10 10:44:58 That's what I'm staring at scratching my head over at the mo! Jul 10 10:45:10 section 5.1... Jul 10 10:46:06 hi, can it be considered as success: Jul 10 10:46:08 NOTE: Tasks Summary: Attempted 1614 tasks of which 262 didn't need to be rerun and all succeeded. Jul 10 10:46:11 Summary: There were 181 WARNING messages shown. Jul 10 10:46:33 tf: or am I missing something?! Does this all happen automagically when you add the layer to your conf in the $WORKDIR? Jul 10 10:47:36 pev: you just create your layer as described in section 5.1, that's all that is required Jul 10 10:50:51 tf: OK, so at the moment my build env gets populated from meta-mybsp/conf/local.conf.sample and bblayers.conf.sample - If I populate the new meta-myapp/conf with copies of those then adapt to my new layer conf that would be the right way to go? Jul 10 10:51:43 yes Jul 10 10:51:58 but if you are adding packages to the image, you should probably write your own image recipe Jul 10 10:52:03 Brilliant, thanks! Lets give it a go and see what happens... Jul 10 10:52:20 Would you not bbappend the standard one? Jul 10 10:52:53 (standard being the current one im using from the bsp) Jul 10 10:52:55 /home/lpapp/Projects/poky/meta/files/common-licenses/* could not be copied for some reason. It may not exist. WARN for now. -> why do I see many warnings like that? Jul 10 10:53:02 personally, I'd not do bbappend to image recipe, it becomes quite a different image once you modify it Jul 10 10:54:07 pev: but there is nothing stopping to use a bbappend Jul 10 10:55:54 tf: ack. Will give it a go the simplest way for now then have a crack at duplicating the image recipes as a secondary task (its esp confusing as there are three recipes for different types of images...) Jul 10 11:40:17 lpapp: http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#licensing. The error comes from license.bbclass. Maybe some of your custom recipes? Jul 10 11:40:40 no, it is upstream master, vanilla. Jul 10 11:55:48 How to replace opencv outdated bitbake file? Jul 10 11:56:06 What does Bitbake do differently between package1 DEPENDS on package2 vs. package1 RDEPENDS on package2? I know that R stands for runtime, but that can mean so many different things. Jul 10 11:58:42 mulhern: depends is build-time dependency, so will be built first Jul 10 11:58:51 mulhern: rdepends turns into a binary package dependency Jul 10 11:59:00 so the generated binary package will have the dependency Jul 10 12:02:14 rburton: So, if a package1 loads a shared object library of package2 is it just RDEPENDS on package2 since it only needs the headers at compile (pre-processor) time? Jul 10 12:02:52 mulhern: the headers won't exist until you built package2, so you need a DEPENDS Jul 10 12:03:10 the library linkage is detected and added to RDEPENDS for you, so you don't have to do that yourself Jul 10 12:03:34 rburton: OK…that may be where I went wrong. Jul 10 12:04:45 ah, so meta-foo is not the only option for customization, but one can also have custom recipes... Jul 10 12:45:25 lpapp: I think we addressed those by supplying more of the common license files in later versions Jul 10 12:45:52 bluelightning: later than master HEAD? Jul 10 12:46:04 lpapp: ah sorry I thought you were still using an older version Jul 10 12:46:12 does the file it indicates exist? Jul 10 12:48:43 yes Jul 10 12:50:35 is it still possible to use a different gcc for building the kernel? is there any example in tree? Jul 10 12:52:40 zecke: CC_pn-linux-xxxx = "yyy" ;-) Jul 10 12:54:00 RP, move away from the computer Jul 10 12:54:34 Crofton|work: It sounds crazy but right now I'm near enough physically unable to do that :/ Jul 10 12:54:58 Have you fallen off the motorcycle? Jul 10 12:55:00 I suspect I've overdone this being active business :/ Jul 10 12:55:19 Crofton|work: just totally worn out. I did fall off the bike but that isn't related to this Jul 10 12:55:58 well, look at cat pictures then Jul 10 12:56:19 Crofton|work: right :) Jul 10 12:56:26 btw the Linaro talk on OE was pretty good Jul 10 12:56:38 there was even a special guest expert at the end Jul 10 12:56:43 Crofton|work: I looked at the link, yes it was Jul 10 12:56:59 I noticed :) Jul 10 12:57:41 It looks like the project to infiltrate Linaro is going well Jul 10 12:58:11 Crofton|work: heh :) Jul 10 13:05:46 RP: wb! Jul 10 13:09:14 He's still on vacation :) Jul 10 13:09:47 He should be outside reaing a book in sunny England! Jul 10 13:10:36 Crofton|work: I did just that yesterday! :) Jul 10 13:44:48 RP: I have a funny bitbake problem. I am not sure how this is supposed to behave. My BSP layer attempts to target multiple versions of Yocto. So I have a yocto-master/busybox_1.21.bbappend and all this file is doing is to require another shared file Jul 10 13:45:36 RP: the file is called busysbox_sysmocom.inc or busysbox_systmocom_systemd.inc.. and then PN PV point to busysmocom-sysmocom and PV can be systemd and PKGV is systemd too **** BEGIN LOGGING AT Wed Jul 10 14:08:55 2013 Jul 10 14:39:11 I Jul 10 14:40:22 If I'm overriding an image creation .bb with a .bbappend in my new layer, is there an easy way I can work out why it's not working? All I'm doing is putting in it an IMAGE_INSTALL += new-package. Jul 10 14:56:12 Where can i find Gstreamer bitbake file? Jul 10 14:57:40 in oe-core Jul 10 14:57:55 pev: bitbake -e Jul 10 14:58:23 pev: also make sure your layer.conf is correct Jul 10 14:59:14 Thanks! Yep, it looked like layer.conf wasnt including my dir... Jul 10 14:59:39 Also, is there a quick definition somewhere of the conventions used for the recipe-* naming and contents? Jul 10 15:00:04 pev: the convention for recipe-* folders is make up your own naming, suitable for the layer Jul 10 15:00:37 rburton_: So just make it up as I go along? :-D Jul 10 15:00:54 Theres a recipe for disaster Jul 10 15:00:59 (sorry couldn't resist) Jul 10 15:01:32 bikeshedding a canonical list of software groups for everyone wouldn't be a good use of time :) Jul 10 15:04:39 but, but, I like bikeshedding :D Jul 10 15:05:08 bluelightning: shush! Jul 10 15:06:33 I tend to copy existing names Jul 10 15:07:11 yeah, copying the eg oe-core naming makes sense for familiarity Jul 10 15:07:30 bluelightning: my preferred bike shed colour is terracotta Jul 10 15:07:43 rburton_: now there is a surprise ;-) Jul 10 15:08:16 rburton_: burnt sienna is so much nicer Jul 10 15:38:18 hi, do people also build u-boot as part of yocto, or just the linux kernel? Jul 10 15:38:59 lpapp: people using yocto to build their embedded system generally use yocto to build all of it, boot loader through to app Jul 10 15:40:00 k Jul 10 15:40:07 thanks Jul 10 15:50:58 I was able to run bitbake minimal core image ... with default package setting package_rpm Jul 10 15:51:12 however when I changed to package_tar it gives error Jul 10 15:51:27 has anybody tried to us the package tar?? Jul 10 15:51:32 package_tar is of limited use, can't be used to build images, for example Jul 10 15:52:04 we seriously need to purge the documentation of package_tar Jul 10 15:52:11 considering it's actually a waste of time Jul 10 15:52:17 so it isn't an option in the local conf Jul 10 15:52:54 Do you have suggestion if you want to have you packages .tar.gz Jul 10 15:53:10 fin_: use rpm/dpkg/ipkg instead? Jul 10 15:53:25 tarballs have no dependencies, so they're of limited use and don't really count as "packages" Jul 10 15:53:30 tar.gz is not a packaging format Jul 10 15:54:03 package_tar 's only real use is easier examining of package contents, in *addition* to one of the other packaging formats, but even that's limited, given it's not hard to examine rpm or ipk or deb contents :) Jul 10 15:54:05 oh, package_tar isn't in the current docs at all. good. Jul 10 15:55:13 ok I need to look in to our requirement a bit more. Jul 10 15:55:49 basically package_tar can handle individual packages, but it cannot support image generation Jul 10 15:56:05 in theory we could create images from tar files, but we'd have to leverage 100% bitbake's knowledge of runtime dependnecies from pkgdata, since the packages themselves wouldn't have that information Jul 10 15:56:21 right Jul 10 15:56:28 but there's no real point given you can build an image with another format and then exclude the packaging bits from the image Jul 10 15:56:31 :) Jul 10 15:56:36 i.e. basically reimplement a hacky package manager ourselves :) Jul 10 15:56:41 indeed Jul 10 15:57:16 point of interest, that's exactly what oe-lite does, which is part of why they can't really support some of the use cases we can Jul 10 15:58:32 ok another question. I need to sign the created packages that are created by a recipe. I want to do in a class Jul 10 15:59:37 So I need to access the created package after it is deployed I guess Jul 10 16:00:27 should be able to just add a task that runs after the packaging tsaks, or use a postfunc on them Jul 10 16:01:31 What is the variablle I should use to access the directory and var to access the package name Jul 10 16:01:35 ? Jul 10 16:02:10 best off examining package_*.bbclass, i think Jul 10 16:04:26 fin_: depends on whether you want to look at the package contents or the completed package Jul 10 16:05:03 This time complete package Jul 10 16:15:06 Do you have any suggestion? Jul 10 16:20:02 fin_: I'd probably look at adding a task that depends on do_package_write Jul 10 16:22:32 fin_: there is DEPLOY_DIR_RPM to find the directory containing RPMs (and similar for other package backends) Jul 10 16:40:11 Those tasks are a bit confusing. is it defined some place in which order tasks are run. if you run listtasks for a recipe it doesn't print the tasks in processing order Jul 10 16:41:28 the addtask lines define the inter-task dependencies Jul 10 16:44:22 but you need to scour the whole code for that Jul 10 16:47:33 what is SRCREV_FORMAT, I can't seem to find anything about what it's supposed to contain. Jul 10 16:47:59 Garibaldi|work: grep layers for examples Jul 10 16:48:19 Garibaldi|work: it's needed when you have multiple SCM repositories in the same recipe Jul 10 16:48:30 ah, thanks Jul 10 16:48:50 should have grepped first :-) Jul 10 16:49:31 /users Jul 10 16:50:50 * rtollert blushes Jul 10 16:50:55 yeah, it's similar to what I saw online, I see it set to "meta_machine", but I'm not connecting "meta_machine" with SCM repos? Jul 10 16:53:12 Garibaldi|work: see name= parameter in SRC_URI Jul 10 16:53:43 and version shown by linux-yocto recipes: gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r6.4 Jul 10 16:53:55 ah, damn Jul 10 16:54:02 first is hash from name=meta repository second is from name=machine Jul 10 16:54:25 yeah, I looked for meta_machine Jul 10 16:54:44 thanks again Jul 10 18:51:47 What is packages-split for? Jul 10 18:52:18 getting an "installed but not shipped" QA error --- at what stage are the files being dropped? Jul 10 18:52:28 exactly what it sounds like, it splits up the do_install output for inclusion in individual binary packages Jul 10 18:52:40 PACKAGES lists the binary packages to be emitted, FILES_ defines the files/directories to be included inthat package Jul 10 18:54:32 It's not so much "dropped" as "not picked up". Jul 10 18:55:01 You start with the set of all files you install. For each package, FILES_ are grabbed and removed from the set of "installed" files that other packages could grab. Jul 10 18:55:15 When you run out of packages, if there's files left, that means they are installed but not shipped, which is usually an error. Jul 10 18:55:49 seebs: Thanks. But what is the purpose? What's the point of all that splitting and filtering? Jul 10 18:56:41 Well, the point of the splitting is to give a mechanism for package granularity, so if you have a large source package it isn't an all-or-nothign thing. Jul 10 18:56:56 Even in simple cases, it can be nice to separate out documentation, debug info, and the like. Jul 10 18:57:25 But some things can have a fairly large number of subpackages; for instance, I think the various binary locale data sets each get their own package. Jul 10 18:57:40 mulhern: granular packaging allows one to tailor the exact contents of your root filesystems, and keep disk spacxe down without blindly throwing contents away permanently Jul 10 18:59:16 mulhern: I've been accepting the defaults for PACKAGES variable. What is the default for what goes into the root filesystem? Jul 10 18:59:41 the image is comprised of dependencies based on packages.. Jul 10 18:59:51 I'm sorry I keep typing my name…it's weird. Jul 10 19:00:03 so if the image has an IMAGE_INSTALL of "foobar" then the package 'foobar' will be installed, and anything it depends on Jul 10 19:00:08 but foobar-dev won't be Jul 10 19:00:28 but if your image doesn't list 'foobar' then it won't ever be installed.. Jul 10 19:00:37 you need to think about the build as: Jul 10 19:00:53 recipe name -> package(s) Jul 10 19:01:25 so bitbake foobar associates to the foobar -recipe-, while the IMAGE_INSTALL 'foobar' referes to the package named foobar.. these are two different namespaces, and may have overlap -- or may not Jul 10 19:01:32 :) Jul 10 19:03:08 fray: OK, and what is package subdirectory for then? Jul 10 19:04:42 i wish runqemu didn't make assumptions about DEPLOY_DIR layout Jul 10 19:07:04 the packages are in tmp/deploy// for the most part.. Jul 10 19:07:25 but you can't just use that as a reference because there are some 'package rename' games going on under the hood.. Jul 10 19:07:34 you have to match the 'PACKAGES' names in you image install Jul 10 19:08:44 you should be able to use both pre-rename and post-rename package naems in IMAGE_INSTALL, as far as I'm aware. the rename mapping will leave existing names as is Jul 10 19:08:53 * kergoth` shrugs Jul 10 19:09:23 kergoth didn't work before because IMAGE_INSTALL ends up becoming the RDEPENDS of the image recipe.. and the system can't map the post-rename 'names' to the recipes for dependencies Jul 10 19:09:52 it works in some cases where the name happens to match a packages_dynamic wildcard.. but it fails in many cases.. (or did last time I tried it) Jul 10 19:09:53 Hmm, if so, that's unfortunate Jul 10 19:10:26 problem also with using the renmaed values, if someone disabled the debian rename.. your image recipe won;'t work right anymore Jul 10 19:10:48 good point Jul 10 19:11:03 (image.bbclass) Jul 10 19:11:05 honestly, i rather dislike debian renaming, i'd rather see it inject RPROVIDES, and even then just for ipk Jul 10 19:11:07 DEPENDS += "${MLPREFIX}qemuwrapper-cross ${MLPREFIX}depmodwrapper-cross" Jul 10 19:11:08 RDEPENDS += "${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL} ${RO$ Jul 10 19:11:08 RRECOMMENDS += "${NORMAL_FEATURE_INSTALL_OPTIONAL}" Jul 10 19:11:18 since rpm can handle soname based stuff already Jul 10 19:11:24 heh Jul 10 19:11:34 kergoth, same here.. whenever I have a bug, I just disable it.. fix the bug and then turn it back on and verify.. it just gets in the way Jul 10 19:11:41 * kergoth` nods Jul 10 19:12:20 well, the one advantage for ipk i can think of is you can then install both libc5 and libc6 in the same system (or whatever) Jul 10 19:12:30 which wouldn't be the case with rprovids Jul 10 19:12:52 ya.. but I'm not sure we ever have that issue Jul 10 19:13:21 i think package feed oriented distros that want to retain long term upgradability could see it as an issue they could hit in real situations Jul 10 19:13:30 not sure, though Jul 10 19:14:02 ya, I've definitely not hit that point yet.. package feeds still seem fragile for the average user/developer Jul 10 19:14:28 keeping an upgrade path smooth is a truly massive effort, wer'e definitely not on par with debian there Jul 10 19:14:39 you could need db schema migrations, etc in postinsts for upgrades, blah blah Jul 10 19:15:04 it's going to take automated testing to really do that.. as well as ways to reject bad packages... Jul 10 19:15:11 and we're definitely not there yet as a group Jul 10 19:15:45 I'm still fighting to grasp/explain ssate-cache/PR server interactions and how best to tell users to share them in a workgroup Jul 10 19:15:46 i expect today angstrom are the only ones that care, but i could see it being a concern for anyone that wants to leverage packages to implement field upgrades Jul 10 19:16:03 heh, seing pcakage versions go backwards due to use of previous sstates? Jul 10 19:16:13 ya.. we've asked our customers and they simply don't do package level distribution field upgrade, they only do individual package field upgrades.. Jul 10 19:16:44 kergoth` we understadn the issue.. it's identifying it and telling users how to avoid it we're strugling with.. because PR server and sstate-cache are separate ssytems.. Jul 10 19:16:50 * kergoth` nods Jul 10 19:16:58 it would be nice if there was a way to tie them together into a single infrastructure.. Jul 10 19:17:25 i.e. sstate-cache had exported PR information in it, that the PR server (external to that) would first load before the system tried to download the sstate-cache Jul 10 19:17:39 but AFAIK, the 'proxy-level' pr server functionality was never implemented Jul 10 19:18:33 I'd love to see.. project pr-server queries WG server, which can query sstate-cache server.. Jul 10 19:18:55 no matching PR, sstate-cache downlod is aborted and a build happens.. PR is returned and the -matching- PR/sstate is fetched Jul 10 19:20:14 (and in the above, if there is no 'WG' that level of indirection is skipped) Jul 11 00:18:58 does any one noticed that the debug-tweaks is not working? **** ENDING LOGGING AT Thu Jul 11 02:59:58 2013