**** BEGIN LOGGING AT Fri Jan 03 02:59:59 2014 Jan 03 08:55:06 good morning! Anybody can help me understand what does the line "INITSCRIPT_PARAMS_shr = "start 90 5 2 . stop 90 0 1 6 ." in http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-nodm-init/xserver-nodm-init_2.0.bb?h=dora#n19 ? I understand it sets a different priority, but I don't understand in which case it gets triggered. What does that "shr" mean? Jan 03 09:00:33 mmm... It looks like meta-shr is a set of layers for smartphones. Did I get it right? Jan 03 11:19:29 hi, when are the yocto folks back this year, on Monday? :-) Jan 03 12:07:49 We're all always here... idling :) Jan 03 12:10:36 dzoe: I do not see rburton, nor bluelighting. Jan 03 12:33:19 bluelightning: hi Jan 03 12:51:26 hi lpapp_ Jan 03 12:52:13 bluelightning: hey, what is the best way to modify some source in the workdir, and get them rebuilt with bitbake without forced explicit compilation? Jan 03 12:52:30 e.g. I modify the kernel source with a printf, but the bitbake myimage process does not care about it Jan 03 12:52:33 the old content goes in. Jan 03 12:52:47 bitbake -c compile virtual/kernel Jan 03 12:52:52 + -f Jan 03 12:53:19 but that is what I would like to avoid. Jan 03 12:53:33 since it is tiring, and it would be better to use bitbake myimage Jan 03 12:53:42 one would expect to rebuild the image with the changes in the workdir. Jan 03 12:59:08 lpapp: -f is the only supported way I'm afraid Jan 03 13:00:50 bluelightning: right, so we need to introduce a new conf option. Jan 03 13:01:00 (or just make it default, really) Jan 03 13:02:19 if you want to do this kind of thing you ought to be using externalsrc really Jan 03 13:02:36 that shares the same issue though, but that is where any enhancement should go Jan 03 13:02:59 bluelightning: I think I can decide what fits me better. Jan 03 13:03:14 surely, two different environments does not make any sense for me for the same thing. Jan 03 13:03:30 lpapp: sure Jan 03 13:03:45 and those people who would use separate environments for whatever weird reasons, they would not modify the source in workdir anyway Jan 03 13:03:52 so they would not be affected, whatsoever. Jan 03 13:04:19 the change you are proposing, "making it the default" absolutely *would* affect other people Jan 03 13:04:56 checking whether recompilation is needed takes time (significant time for large projects e.g. Qt), and that's what you'd have to introduce Jan 03 13:05:49 this is why it makes sense to nominate the recipes you are working on e.g. by enabling externalsrc for them, then you can add the extra processing where you need it Jan 03 13:07:01 I heavily disagree. Jan 03 13:07:16 working in two different environments is a _daily_ _needless_ _over-engineering_. Jan 03 13:07:40 so at the very least, there should be an option for people to avoid that nonsense. Jan 03 13:08:23 ALWAYS_REBUILD = "foo bar baz" Jan 03 13:08:38 so in case of a linux developer, it would be: ALWAYS_REBUILD = "virtual/kernel". Jan 03 13:09:17 set only once for the whole career if the yocto environment does not change, and no need to use "-c compile -f" for every printk modification many times daily. Jan 03 13:10:30 this whole separate different environment is probably historical. Jan 03 13:10:56 there had not been yocto, etc, other build systems back then, so there was no other option than having a vendor branch, but these things have changed the last several years. Jan 03 14:35:25 U-boot question: How can I use 2 16bit NOR-flash chips? Does anyone know a board that has that so that I can look at the code? :D Jan 03 15:26:30 lpapp: you could add do_compile[nostamp] = "1" to your kernel recipe, then it will rebuild every time Jan 03 15:28:51 RP: thanks. Jan 03 16:09:15 <[1]Renato> Hello guys..... i'm trying to build a core-image-minimal with java (oracle-jse-jre-x86-64-1.7.0-u45r0@x86_64) but i'm get the errors "no package provides /bin/bash" and "no package provides libxslt.so.1(LIBXML2_1.0.22)(64bit)" in last steps, when the bitbake process starts to create the root filesystem.... Jan 03 16:10:24 <[1]Renato> how a java binary distribution can depend on bash or libxml? Jan 03 16:10:59 <[1]Renato> I solved all the checksum and download problems from recipe Jan 03 16:11:43 [1]Renato: re bash, there will be a shell script being packaged which starts with #!/bin/bash Jan 03 16:12:34 for libxml2, it must be linking against that library and we're apparently not providing the version it has ben built against Jan 03 16:12:45 <[1]Renato> bluelightning, but if I download the distribution tar.gz I can run bin/java... its an ELF binary.... Jan 03 16:13:05 [1]Renato: yes, but bin/java is not the only binary in the package, surely? Jan 03 16:13:21 <[1]Renato> is there some way to know what the bitbake is trying to do? Jan 03 16:13:50 you'll need to look at all of the files that are being packaged Jan 03 16:14:19 <[1]Renato> all the jre tree?... looking for a bash header... hmmm Jan 03 16:14:37 look in packages-split/ in the workdir for the java recipe Jan 03 16:15:16 [1]Renato: are you using meta-oracle-java for this? Jan 03 16:15:28 <[1]Renato> yes Jan 03 16:15:42 ok Jan 03 16:15:49 <[1]Renato> i just changed it for the last java release and checksums Jan 03 16:16:03 <[1]Renato> its the only thing I changed Jan 03 16:16:26 <[1]Renato> PV_UPDATE = "45" Jan 03 16:16:26 <[1]Renato> SRC_URI = "http://download.oracle.com/otn-pub/java/jdk/7u45-b18/jre-7u45-linux-x64.tar.gz" Jan 03 16:16:26 <[1]Renato> SRC_URI[md5sum] = "e82743de29c6cb59ae09bbcb090ccbee" Jan 03 16:16:26 <[1]Renato> SRC_URI[sha256sum] = "e107d8ca8dcd570207b4eff793e7b83a1ff82f1ed4ea8a80d88f5edc000c74c7" Jan 03 16:16:48 <[1]Renato> of course I had to download manually... as oracle ask for accepting the license Jan 03 16:17:48 <[1]Renato> look... i found some bash scripts in jre tree Jan 03 16:17:50 <[1]Renato> but Jan 03 16:18:28 <[1]Renato> will the rootfs generation run all the files from jre/bin? Jan 03 16:20:36 <[1]Renato> is there the option to ignore this? Jan 03 16:22:22 it's not that it runs all of the files - it's that when packaging, extra dependencies are being added based on the contents of the packages Jan 03 16:22:43 the only way to fix it is to delete or patch the errant files Jan 03 16:23:33 you'd do that in the java recipe itself; deleting would be done within do_install Jan 03 16:25:07 <[1]Renato> running "find * -exec ldd {} \; | grep xslt" I found a file in "lib/amd64" that depends on that library xslt Jan 03 16:25:40 <[1]Renato> ok... I will try to find some way to install these dependencies first.... Jan 03 16:28:42 if that's what you want to do, adding RDEPENDS would be the right way to do that Jan 03 16:42:42 <[1]Renato> wel... it seems to be working now Jan 03 16:42:56 <[1]Renato> let me check it out Jan 03 16:44:42 kergoth: still interested in that docker stuff? Jan 03 16:48:25 hi RP, did you get my email? Jan 03 16:52:56 WarheadsSE: yeah Jan 03 16:55:36 K Jan 03 16:55:57 walters: was this over the holidays? I've not gone through some of the backlog yet Jan 03 16:56:04 some minor changes happened recently (minor, but massively annoying) that changes part of how I use it, but for the most part not that much of an issue Jan 03 16:56:18 aka, symlinks behave differently now Jan 03 16:56:40 RP: yeah...no rush Jan 03 16:58:57 walters: just had a quick read. I would love to support ostree natively as an output format :) Jan 03 16:59:41 walters: will have to fire up a VM and have a play... Jan 03 17:01:06 what is the best of handling bitbake etc patches? Jan 03 17:01:09 not accepted upstream? Jan 03 17:01:42 so basically tool patches, not recipe. Jan 03 17:02:11 lpapp: is this about the patch.bbclass patch you sent the ping on? Jan 03 17:02:33 RP: let me know how it goes! I am trying to gather early feedback from experienced people before posting more widely Jan 03 17:02:42 lpapp: I did see that but haven't had a chance to properly look at it. A lot of people have taken a break over the holidays so things are behind with patch review Jan 03 17:03:01 walters: will do Jan 03 17:03:12 RP: in general. Jan 03 17:03:29 either rejected, or waiting.... Jan 03 17:03:43 we cannot really wait for upstream to accept our changes.... we need to organize ourselves properly. Jan 03 17:03:51 lpapp: bitbake patches go to the bitbake list and get reviewed there. Is there a specific issue? Jan 03 17:03:59 so what is the recommended way for tool patches to allow easy upgrade path with a new version of Yocto? Jan 03 17:04:22 lpapp: keep unaccepted changes in their own layer Jan 03 17:04:58 what layer? Jan 03 17:05:43 lpapp: you create your own layer to contain those changes Jan 03 17:12:45 kergoth: the one thing I am having so much fun with, is that I have a massively tiny system in the docker, so the host-bleed issues become apparent rather fast. Jan 03 17:13:38 RP: I understand the own layer part, but I would not know what it is supposed to contain. Jan 03 17:42:30 moin Jan 03 17:43:35 mr_science: yo Jan 03 17:44:22 got a weird python recipe that sometimes decides it doesn't like running setup.py... Jan 03 17:53:42 Anyone ever hit a problem unpacking rpm? Jan 03 18:08:32 WarheadsSE: I have. When I try to build rpm-native on centos5, it explodes trying to unpack the src.rpm Jan 03 18:08:36 is that the one you're hitting? Jan 03 18:08:51 that is, it happens on this centos5 chroot, i haven't tested on my actual centos5 vm yet Jan 03 18:09:15 was playing around with doing my builds under a minimal chroot, until I find the time to mess with docker more :) Jan 03 18:09:16 yup Jan 03 18:09:20 that exact problem Jan 03 18:09:36 found the problem, I think Jan 03 18:09:42 file command was not in existance Jan 03 18:09:51 huh, thats' odd, since we build file-native Jan 03 18:09:58 the rpm2cpio.sh wants file, file was not built Jan 03 18:10:11 missing dep for the src.rpm unpack, perhaps Jan 03 18:10:30 find . -name "file" -type f only resulted in an http test Jan 03 18:10:50 chock another one up to missing deps! Jan 03 18:10:55 we have logci in base.bbclass which adds extra deps for do_unpack bsed on what's in SRC_URI Jan 03 18:10:59 e.g. unzip-native for .zip files Jan 03 18:11:13 i'm guessing we might be missing a file-native for src.rpm, if rpm2cpio.sh needs it Jan 03 18:11:21 ^ Jan 03 18:11:56 i'm guessing most folks don't do builds on tiny rootfs's without file installed :) Jan 03 18:12:03 added that to the docker image, and viola Jan 03 18:12:06 definitely find a lot of bugs building this way.. Jan 03 18:12:10 yes Jan 03 18:12:10 good thing Jan 03 18:12:15 I am finding a lot Jan 03 18:12:31 like hmm, soelim eh.. might want groff built.. Jan 03 18:12:45 or, qt not building webkit .. Jan 03 18:12:50 that one was ugly. Jan 03 18:14:02 kergoth http://pastie.org/private/yzxentnjjurajt1xypdlka was it Jan 03 18:14:16 of course, not that it tells you squat about what the real error was Jan 03 18:18:19 yeah, thast the failure iw as seeing too, didnt' have time to investigate. well spoted Jan 03 18:18:22 spotted Jan 03 18:20:45 WarheadsSE: https://gist.github.com/kergoth/8243299 should take care of it, i think Jan 03 18:20:50 WarheadsSE: (untested) Jan 03 18:21:58 Yeah, since this is fully contained and does a gerrit repo w/ init & sync, I can't just patch in too much Jan 03 18:22:05 ah, right Jan 03 18:22:42 it's part of the jenkins build system I am putting together, so I just popped a `RUN apt-get install -y file ;` into the Dockerfile and re-tagged the image Jan 03 18:23:22 Nothing like seeing all cores running full bore, need to get a faster large capacity disk in there though. Jan 03 18:23:46 yeah, i/o is quite the bottleneck on builds like this, unfortunately Jan 03 18:24:56 Yup Jan 03 18:25:11 I'd love to convince work to buy me a 256/512 ssd Jan 03 18:25:30 120 can get blown out easily by a few simultaneous bitbakes at 8 cores Jan 03 18:26:05 barely dings my system ram though Jan 03 18:26:36 we do have one box that is running ~ 2x Xeon E3 quads w/ 256G ram though Jan 03 18:26:46 that one we just fire up a tmpfs, build, wait Jan 03 18:27:08 but I think they have that one set @ j4 Jan 03 19:07:08 kergoth: perhaps you could enlighten me on something Jan 03 19:07:41 Assuming that the targets might be different, the native chains and sstate could end up in a matching state? Jan 03 19:08:04 Wondering if there is a way for me to condense what I have a bit. Jan 03 19:10:19 i'd definitel yrecommend sharing sstate amongst builds, as you say, natives will be shared when the target changes Jan 03 19:11:47 right now, I am generating essentially clean states other than dl foreach target w/ distro-distro_type-machine tuple Jan 03 19:11:58 which means the native's get rebuilt .. a lot. Jan 03 19:13:24 bah, another fault. Jan 03 19:14:27 a clean build is nice for official/release builds, but more incremental daily or continuous builds which use sstate are nice too :) Jan 03 19:15:01 Yeah, for those cases, I am bundling the resulting successful build that users can then dl, extract and pop right into Jan 03 19:15:46 and then, they all are going based off the previous build of the point version beyond that, even with jenkins Jan 03 19:16:30 because inside the docker, it all looks the same, and can't tell the difference aside from where distro/distro_type/machine are difference in local.conf Jan 03 19:18:56 cute. http://pastie.org/8597966 Jan 03 19:21:58 hrmm.. build/detos/tmp-eglibc/sysroots/x86_64-linux/usr/lib/libmpc.so{.3,.3.0.0} Jan 03 19:22:06 wtf mate. Jan 03 19:38:53 and magically worked fine now .. ah.. highly parallel builds.. Jan 03 19:40:07 heh Jan 03 19:45:44 I've hit half my "issues" from host bleed, and half from dependency derps that don't happen if you build with =<4 cores Jan 03 19:46:13 6-8, this stuff starts cropping up Jan 03 19:46:23 that's surprising, the automated yocto builds run with many cores afaik Jan 03 19:47:14 Yeah, we've got some that are still in a mixed-breed setting with dora on top of stuff from dylan/denzil Jan 03 19:47:26 newer versions wont have those issues Jan 03 19:47:30 ahh Jan 03 19:48:19 I have another environment that has next-to no issues ever, and is yocto + meta-fsl Jan 03 19:48:36 but since this is still a half-breed, stuff like this crops up occasionally. Jan 03 19:49:58 you just kick it and it keeps moving Jan 03 21:18:21 hi all Jan 03 21:18:54 I'm trying to build image for beaglebone in Fedora 20 using yocto 1.3 (danny) Jan 03 21:19:09 I fixed some issues with missing patches Jan 03 21:19:25 but during binutils install I get error Jan 03 21:19:25 any ideas? Jan 03 21:22:44 "error" Jan 03 21:24:33 I browse logfile but there is no real error Jan 03 21:24:37 at least I cannot see any Jan 03 21:25:15 well, without something to go on, all we have is the word "error" Jan 03 21:25:20 make[4]: *** [as.info] Error 1 Jan 03 21:25:50 temp/work/armv7a-vfp-neon-poky-linux-gnueabi/binutils-cross-2.22-r19/binutils-2.22/build.i686-linux.ar m-poky-linux-gnueabi/gas/doc' Jan 03 21:25:50 327 make[3]: *** [install-am] Error 2 Jan 03 21:26:04 I have a recipe that is building from (unfortunately) a binary only library. One of the shared libraries in it depends directly on the unversioned libGL.so, but obviously packaging gets rid of the symlinked libGL.so. When a root fs is to be built, rpm complains that no package provides libGL.so. Is there any way to get around this when building an image? Jan 03 23:47:44 anyone knows how to install a package and the files will be installed as a xuser user? Jan 03 23:50:33 just do a chown? Jan 04 00:46:21 ftonello: if the user is already in the passwd file then a postinst function is the usual way to chown something Jan 04 00:46:54 at least that's the legacy way... maybe there's a better answer **** ENDING LOGGING AT Sat Jan 04 02:59:58 2014