**** BEGIN LOGGING AT Wed Jan 21 02:59:58 2015 Jan 21 06:06:02 HDMI audio is not working with BBB core-image-sato Jan 21 07:08:54 did HDMI audio ever work on the BB? Jan 21 07:08:59 *BB? Jan 21 07:09:19 that is extra license cost iirc Jan 21 07:09:42 *bbb gah Jan 21 07:13:35 Only CEA resolutions support audio as defined by the HDMI Specification. http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI Jan 21 08:30:46 morning all Jan 21 10:41:17 openssl.inc says PACKAGES =+ "libcrypto", but no such thing seems to be built. what does this mean, then? Jan 21 10:43:01 but can see libcrypto1.0.0_1.0.1jsomething in the package deploy dir Jan 21 10:43:09 so how to properly depend on it? Jan 21 10:50:01 LetoThe2nd: my openssl here builds a libcrypto package Jan 21 10:50:33 LetoThe2nd: it's a shared library, so if your application links to it, it will get a runtime dependency on the libcrypto package automatically Jan 21 10:50:47 bluelightning: ah so it RDEPENDS? Jan 21 10:51:01 LetoThe2nd: an RDEPENDS will be added during packaging yes Jan 21 10:51:21 LetoThe2nd: you just need to make sure openssl is a build time dependency i.e. you do need an explicit openssl in DEPENDS Jan 21 10:51:49 bluelightning: hm. still somethings weird here. maybe openssl needs some added flags when being built then. Jan 21 10:52:03 bluelightning: but i see then, thanks for your input! Jan 21 10:52:20 LetoThe2nd: first place to look would be the configure script and the packages-split directory Jan 21 10:52:29 for openssl itself Jan 21 10:53:28 bluelightning: no, its more like the linker complains about some md5 stuff not being found. probably its something $coworker relied on in libcrypto, but not being enabled by default in poky. Jan 21 11:03:43 LetoThe2nd: I'm assuming it's not something silly like missing -lcrypto ? Jan 21 11:10:12 hm is paul barker around? Jan 21 11:10:16 * rburton can't recall his nick Jan 21 12:07:19 bluelightning: hehe no, certainly not :) Jan 21 14:14:17 Does Yocto have support for non-manual system upgrades? Jan 21 14:14:37 I mean tooling for reflashing the image, something like openwrt does it. :-) Jan 21 14:18:56 we don't have anything out of the box, but there have been some efforts to build something on top Jan 21 14:19:05 I have a recipe which I make do_compile[nostamp] = "1". When I execute the following the compile is always executed, bitbake -c compile myrecipe. However when I execute just bitbake myrecipe, the compile is not executed. Is there a way of forcing a task always to be rebuilt Jan 21 14:25:05 ipuustin: you can have a look at meta-swupdate by stefano babic, for example Jan 21 14:28:05 dguthrie: I think that's something we only recently fixed in bitbake Jan 21 14:28:37 dguthrie: here's the patch that fixed it: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7b70d5e8a481a7485a3866623efce993ddd9b607 Jan 21 14:28:53 bluelightning: Thanks for patch. Jan 21 14:29:48 LetoThe2nd: ipuustin: ah yes that's what I was just trying to remember the name of - repo is here: https://github.com/sbabic/meta-swupdate Jan 21 15:43:38 hi, someone seen a .bb build file for http://sourceforge.net/projects/libjson/ ? Jan 21 15:45:12 grma: yes it was in meta-oe, now it's replaced by json-c Jan 21 15:46:07 and json-c was backward compatible until last upgrade in oe-core, so still better to downgrade json-c than re-introduce libjson Jan 21 15:46:41 ok, thx Jan 21 15:48:56 the bad thing, the customer wants libjson lib :( Jan 21 15:52:14 json-c produces libjson lib :) Jan 21 15:54:36 yup, i have seen this and think about how to do it the correct way ... Jan 21 15:55:10 JaMa: Are you the maintainer of meta-qt5 ? Jan 21 16:02:31 Hello, does sombody know what is the recommended method to handle PR increases in .bbappend files since PRINC is deprecated? Jan 21 16:02:58 let the pr server increment it as needed, manual bumps aren't needed Jan 21 16:03:21 What if pr server isn't used? Jan 21 16:04:03 then it won't be updated. which won't affect your builds at all, bitbake still knows what to rebuild when, it's just the binary packages that'd be affected Jan 21 16:05:12 Ok so if we want to use binary packages a central PR server is mandatory? Jan 21 16:05:31 Because we have builds running on different machines Jan 21 16:06:21 it's not mandatory, it depends on your needs and priorities. if you want package upgrades to work reliably, then yeah, i think a central PR server is about the only option Jan 21 16:06:48 Ok thanks for clarifying Jan 21 16:08:09 grma: yes Jan 21 16:08:22 Just for my understanding all servers that contribute to the same package repository must need the same PR server to work reliably? But an sstate cache can be shared even if each machine has its own PR server? Jan 21 16:08:48 JaMa: great job, what you and all others do here... Jan 21 16:09:03 grma: thanks Jan 21 16:09:15 bachp: yes Jan 21 16:09:15 backp, correct.. which is why you use a shared PR server if multiple machines are contributing to the same sstate-cache Jan 21 16:10:07 if you don't care about on-target upgrade or "PR" numbers, then you can skip that.. but any time you want to be able to move from one build of a package to the next.. (i.e. not always regenerating the filesystem image) you need the PR server Jan 21 16:10:10 bachp: EXTENDAUTOPR isn't part of sstate signatures, so you can share the same sstate archive even when it's packaged with different package version Jan 21 16:10:43 yup.. the only piecce that gets loaded into it is the package bit, since the updated 'PR' is stored in there.. Jan 21 16:11:06 so if the PR numbers are mismatched between systems you'll likely have to repackage everything (or worse case, you'll end up with package extracted that don't match the expected PR in the control files) Jan 21 16:11:16 I tried once sharing an sstate-cache but i got some QA issue telling the PR went backward Jan 21 16:11:25 that would be the PR server bit Jan 21 16:12:12 there is documentation on setting up a shared PR server. only downside is that it's a single point of failure (and if you never "quit" the PR server, it never writes it's DB... at least not in older versions, that might be resolved now) Jan 21 16:13:21 The single point of failure was one of the reasons I wanted to avoid it Jan 21 16:14:21 if you can come up with a read-only PR server.. then you can seed your builders with PR data from the original instance.. Jan 21 16:14:48 it might even be possible to generate the PR server data from the sstate-cache contents and use that to seed it.. but as soon as you start writing to a shared location then you need something to coordinate, and thats the shared PR server Jan 21 16:15:06 What do you mean by original instance? Jan 21 16:15:27 original design for the PR server (not implemented) was a DNS like approach.. where you could have multiple places for authoritative data.. but there are still failure points.. Jan 21 16:15:35 you'd then locate your PR server with the associated data at those locations. Jan 21 16:15:53 if you have a master builder.. that master builder can have it's local PR server and build and populate teh sstate-cache.. Jan 21 16:16:05 that PR data and sstate-cache can be shared read-only to users/developers to boost their build times.. Jan 21 16:16:30 Ok I understand Jan 21 16:16:30 the master build artifacts are the original instance.. the problem is if you have multiple builders feeding to a single sstate-cache location, then you need the syncronization piece Jan 21 16:16:53 That explains why I hade the issues Jan 21 16:17:51 Another issue I see is that you need to backup sour PR server DB together with your binary package repository to guarantee consistent update paths. Is that correct? Jan 21 16:18:31 IMHO what we really need (going back to DNS like approach) is something where you have a local resolver who is responsible for querying one or more remote resolvers.. that way you can have redundnacy. You should also have a way to "post" your updated PRs out to the remote PR servers -if- you are sharing files to them.. if you aren't then read-only is fine.. Jan 21 16:19:08 PR server DB w/ sstate-cache data... yes.. the binary package repository is contained in the image usually (or similar) and can always be reconstructed with the PR server DB and sstate-cache data Jan 21 16:19:39 The sstate-cache is also required? Jan 21 16:19:53 I assumed PR server data + source are enough? Jan 21 16:20:49 The PR server is hash -> PR... so yes, DB + recipes + configuration should be enough to recreate teh data.. BUT when you rebuild differences in the results will creap in. specifically build paths, build machine names, and timestamps.. since those don't affect the resulting "code", only data.. Jan 21 16:20:52 bachp: see https://bugzilla.yoctoproject.org/show_bug.cgi?id=5399 Jan 21 16:20:54 Bug 5399: enhancement, Medium+, 1.8, chong.lu, NEW , Sharing PR server between builders with different metadata Jan 21 16:21:09 so if you want to recrease your package 'feed'.. then you need the PR DB, sstate-cache (cache of previous builds), recipes and config Jan 21 16:21:33 that way when you go to build "new", the system will see the hash has not changed and just load the data from the sstate-cache, this prevents the rebuild which prevents the embedded info from changing Jan 21 16:22:01 bachp: and there is a lot of "PR went backward" caused by wrong PACKAGE_ARCH in recipes, see http://lists.openembedded.org/pipermail/openembedded-core/2015-January/100734.html especially if you're building multiple MACHINES Jan 21 16:22:07 in the end what you do comes down to why you need to do it. If you are doing something like CentOS.. then you need to preserve it all.. if you are just rebuilding images and imags deployed to new machines.. then you don't ned anything Jan 21 16:22:28 and there is a LOT of area in the middle.. but mostly the PR values are required for package upgrades on the target. Jan 21 16:23:48 fray: you don't need sstate-cache in order to recreate the same feed if you have the same metadata Jan 21 16:24:13 the timestamps.. Jan 21 16:24:36 of packages will be different even if you have sstate-cache Jan 21 16:24:36 I don't want and can't allow (for on-target upgrades) my RPM package checksums to change because they've been rebuilt from source and all of the embedded timestamps, build data, etc has changed.. Jan 21 16:24:57 no, the package timestamps remain the same with the sstate-cache, since they're just extracted from the cache and played in the deployment dir Jan 21 16:25:09 'er.. I mean package -metadata- Jan 21 16:25:31 Question: I've been re-using the same build/ directory and just changing MACHINE in the environment. This creates weired FTBFS bugs. Is that supposed to work? Jan 21 16:25:42 the only time the package is rebuilt is if something affects the hash of the do_package step.. Jan 21 16:25:44 gabrbedd: yes Jan 21 16:26:15 I've had a few problems with changing MACHINE and SDKMACHINE, but all of them have been the results of bugs in the recipes Jan 21 16:26:50 gabrbedd: there are still issues (http://lists.openembedded.org/pipermail/openembedded-core/2015-January/100734.html) but this doesn't cause FTBFS Jan 21 16:27:01 Well, In my case the problem is the toolchain. Both machines end up with the same TARGET_PREFIX. Jan 21 16:27:12 only just annoying re-extracting each time you change MACHINE Jan 21 16:27:30 gabrbedd if the target_prefixes are the same, then the contents of the toolchains should be the same.. Jan 21 16:27:37 However, the compilers inside there have a hard-coded sysroot path that only points to ONE of the MACHINE sysroots. Jan 21 16:27:40 if your machines are affecting the tune parameters, you really need a new tune.. Jan 21 16:28:04 the sysroot is specified as a command line argument.. the embedded one is just for reference, but should be ignored.. Jan 21 16:28:07 gabrbedd: you should always get right sysroot path from C*FLAGS Jan 21 16:28:16 I believe newer versions of the toolchain integration may even be passed an invalid path to eliminate that issue Jan 21 16:28:21 Well, it seems that if TARGET_PREFIX somehow included $MACHINE... it would work. Jan 21 16:28:25 (at least there was talk about doing that) Jan 21 16:28:27 never used the hard-coded one, now it's also poinsoned to prevent accidental use Jan 21 16:28:49 that's done in current master Jan 21 16:28:51 three different machines can have entirely the same toolchain and target_prefix, that is absolutely allowed and expected Jan 21 16:28:56 JaMa, ok it did go in then Jan 21 16:29:31 if the toolchain confgiuration changes based on the machine (with the same TARGET_PREFIX), then you have a bug in your configuration. Jan 21 16:30:23 Hmmm... OK. Let me chew on that. The problem I was having was with building things with a crappy vendor-supplied makefile system (the TI DSP toolchains) Jan 21 16:30:28 common bugs are changing values with the tune parameters in the machine .conf when a new tune should have been specified.. or even changing distribution setting values in the machine.. those should be in the distro file Jan 21 16:30:31 Thanks guys for discussion. Unfortunatly I need to go. Jan 21 16:30:34 In general, the CFLAGS and whatnot were sanitized. Jan 21 16:30:49 ...because it's also building kernel modules. Jan 21 16:30:57 recipes that require specific machine knowledge, should be tagged as machine specific.. Jan 21 16:31:20 recipes should build userspace -or- kernel modules, generally not both. This allows for the applications and kernel pieces to have localized knowledge to different pieces of the system Jan 21 16:31:36 easiest way to do that is use the same source twice, but only build half of it per Jan 21 16:32:42 fray: JaMa: thanks, guys. Jan 21 17:12:56 holy crap, does "top" from procps-ng ever look like cat vomit. Jan 21 17:13:13 * paulg will try rebuilding w/ " --disable-modern-top " Jan 21 17:18:27 /data/yocto/tizen-distro/build-modello/tmp-glibc/work/genericx86-oe-linux/linux-yocto/3.14.19+gitAUTOINC+fb6271a942_902f34d361-r0/linux/scripts/mod/devicetable-offsets.c:1:0: error: code model 'kernel' not supported in the 32 bit mode #include Jan 21 17:18:32 * ulf` grumbles Jan 21 17:31:54 bluelightning: hi, is it possible to append to a task inherited from a class in both .bb and .bbappend files? Jan 21 17:32:00 paulg: ugh, mangling standard unix tools? surely if something "modern" is desired, htop is a good existing alternative Jan 21 17:32:25 darkhorse: yes Jan 21 17:32:43 darkhorse: changes in the bbappend will be applied after those in the .bb, if it makes a difference Jan 21 17:33:39 <3 htop Jan 21 17:33:46 bluelightning: no that's fine. but i get the following error: Failure expanding variable do_rootfs: ShellSyntaxError: Unexpected EOF Jan 21 17:33:49 though htop could use some better color schemes, they should improve that Jan 21 17:35:02 darkhorse: I imagine you're probably trying to add shell code to do_rootfs which is actually a python function - is that right? Jan 21 17:37:12 bluelightning, I just did a EXTRA_OECONF += "--disable-modern-top" Jan 21 17:37:12 in my layer of stuff and that fixed it. Jan 21 17:37:29 I can send it for yocto in general, if ppl are in agreement that the new format is hideous. Jan 21 17:37:44 paulg: depending on how awful it looks we might want to consider doing that Jan 21 17:38:02 bluelightning: i see. so you can't mix the two !! Jan 21 17:38:24 here are some opinions that are similar to mine ; found when googling how to disable the POS... Jan 21 17:38:26 darkhorse: no, but there are ways to insert calls to shell functions if you want to extend do_rootfs Jan 21 17:38:27 https://bbs.archlinux.org/viewtopic.php?pid=1474872 Jan 21 17:40:41 hah... 'Considering the trouble it has caused us, I suggest the name "bottom"' Jan 21 17:43:41 bluelightning: can you provide me some pointers? Jan 21 17:43:57 ah yes sorry I meant to do that and got distracted Jan 21 17:44:01 one sec Jan 21 17:44:39 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ROOTFS_POSTPROCESS_COMMAND Jan 21 17:44:45 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_POSTPROCESS_COMMAND Jan 21 17:45:01 depending on when you want the commands to run Jan 21 17:45:38 typically you would define a shell function and then append a call to it to the end of one of those variables (with a leading ; ) Jan 21 17:48:00 bluelightning: it turns out that do_rootfs () is a shell function Jan 21 17:49:35 remind me , which version of the build system are you using? Jan 21 17:49:41 it did change a few versions ago Jan 21 18:03:48 good god, you werne't kidding about how ugly top is out of the box now Jan 21 18:03:54 what the hell were they thinking Jan 21 18:04:06 * zeddii pukes Jan 21 18:04:27 https://www.dropbox.com/s/f7wmmtaladtreor/Screenshot%202015-01-21%2011.03.19.png?dl=0 on my arch vm Jan 21 18:04:30 * kergoth twitches Jan 21 18:04:38 I thought it looked fine, especially when you have a boalload of CPUs Jan 21 18:04:53 * zeddii glares Jan 21 18:05:04 glad i normally use htop anyway Jan 21 18:06:28 bluelightning: it is dylan branch Jan 21 18:07:15 darkhorse: ok, so it would be shell there; however you'll still be better off using the aforementioned variables in most cases Jan 21 18:29:03 fray, that rpm splat that you had me run gdb on a few months ago? zeddii just hit it too. :) Jan 21 20:52:04 anyone know why meta/recipes-core/coreutils/coreutils-8.21/dummy_help2man.patch unconditionally cripples the manpages for coreutils? Jan 21 20:52:36 the commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d which does it does not mention a thing.... :( Jan 21 21:21:09 aha, it is RP 's fault... Jan 21 21:21:28 commit 2f8d643c76f5aa933b95a50092132ef37af203c7 Jan 21 21:21:28 Author: Richard Purdie Jan 21 21:21:28 Date: Thu Sep 29 23:26:07 2011 +0100 Jan 21 21:21:28 Remove help2man dependency Jan 21 21:22:05 * paulg digs in, since I want real manpages, not crippled stubs. Jan 21 21:24:12 paulg: Its amazing how much is my fauly Jan 21 21:24:27 :) Jan 21 21:25:13 paulg: btw, you want working manpages for the target, for native you probably don't want the build dependencies Jan 21 21:27:06 RP, I'm essentially trying to improve the environment of the build-appliance/self-hosting deployment to suck less. Jan 21 21:27:26 meaning having sane devel environment with functional manpages etc. Jan 21 21:27:46 paulg: fine, just keep in mind enabling manpages for native recipes will cause problems Jan 21 21:28:56 ok, thanks for the heads up. Jan 21 21:29:21 paulg: I'm all in favour fwiw, its just a lot of docs are disabled due to dependency issues Jan 21 21:31:44 RP, zeddii gave me a heads up on the foo req'd to limit to tgt builds, so I'll have a go at that when I get home. Jan 21 21:32:18 paulg: there was previously talk of enabling doxygen docs where relevant for target/sdk builds too, so i'm a fan of a global "build documentation" toggle respected by a few classes that recipes can inherit. Jan 21 21:32:46 paulg: if you run into difficulties shout, we collectively have experience with figuring it out Jan 21 21:33:17 rburton1, I took a poke at building git manpages a while ago ; it did suck in a lot of things, asciidoc etc. Jan 21 21:33:36 in the end I just cheated for now and used the prebuilt git manpages from kenrel.org Jan 21 21:33:54 paulg: yeah, other packages will build through xml/xslt and cause pain Jan 21 21:39:26 RP, seems virtclass-native is used to _add_ steps to a native build ; in this case we'd want to do _less_ steps for the native build... can you think of an example to point me at on how filter out native? Jan 21 21:40:02 paulg: well, one way we do things is PACKAGECONFIG = "xxx docs" and then PACKAGECONFIG_class-native = "xxx" Jan 21 21:40:14 paulg: virtclass is dead, use class-native Jan 21 21:42:25 ok, that will give me sth to grep for when I get home; thanks. Jan 21 22:01:52 is it possible to build just kernel modules and their pacakges to embed in ramdisk based image **** BEGIN LOGGING AT Thu Jan 22 01:55:47 2015 **** ENDING LOGGING AT Thu Jan 22 02:59:59 2015