**** BEGIN LOGGING AT Wed Apr 09 02:59:58 2014 Apr 09 07:10:07 I am unable to install libqtopengl4 package to roofs image even with IMAGE_INSTALL_append. the RPM is available under tmp/deploy/rpm. Any idea, what's wrong ? Apr 09 08:47:45 hi, anyone here working with ADT installer? Apr 09 09:55:17 are there any plans to bump openssl version in dora? Apr 09 09:55:35 I just spotted patch on dylan to fix heartbleed on old version (1.0.1e) Apr 09 10:02:31 Xz: the dora patches were sent out last night Apr 09 10:20:59 morning all Apr 09 11:18:45 anyone got suggestion on how to write SRC_URI to download from berlios.de? Apr 09 11:39:30 any ideas on how to force a package to be rebuilt (don't cache it) ? I have some packages that are built in different configurations depending on platform, but when I build for another platform, the cached packages from the wrong platform are used. both platforms use the same recipe. Apr 09 11:42:25 xerent: "bitbake -c clean" it after build / before rebuild Apr 09 11:43:20 thanks :) Apr 09 11:50:12 -c cleansstate Apr 09 11:55:51 ls Apr 09 11:57:31 xerent: that's an indicator that the right variables are not getting into signatures for the appropriate task Apr 09 11:57:57 xerent: have you set PACKAGE_ARCH = "${MACHINE_ARCH}" (assuming that the recipe is machine-specific)? Apr 09 11:59:43 ls Apr 09 11:59:49 lsls Apr 09 12:01:53 lol sorry :) Apr 09 12:07:19 I would like to submit a small patch to the yocto-docs, where should I send it preferrably? Apr 09 12:08:05 poky@yoctoproject.org ? Apr 09 12:10:36 Denwid: yocto@yoctoproject.org, and CC Scott Rifenbark as well Apr 09 12:10:42 thanks! Apr 09 12:11:12 Denwid: if you could ensure [yocto-docs] is in the subject that would be great also Apr 09 12:11:44 Cool, thanks! I will do that Apr 09 12:33:41 bluelightning: the architecture is one and the same for both platforms. the different platforms have similar CPU's, etc, but differ in other terms Apr 09 12:34:21 andhe: it sure rebuilds the packages after I cleaned them, but bitbake won't bake me a new image because it thinks the packages haven't changed. Apr 09 12:34:53 xerent: right, but if this recipe is somewhere where those differences are taken into account then you should set PACKAGE_ARCH = "${MACHINE_ARCH}" within the recipe Apr 09 12:37:10 I can't find any mention of that variable in the reference manual Apr 09 12:37:40 machine_arch that is Apr 09 12:37:56 xerent: you're right, I made a note Apr 09 12:38:23 there are lots of examples where we use that within the metadata, but then there's no way for you to know where to look for those Apr 09 12:38:44 I did know where to look: here, asking you ;) Apr 09 12:38:55 heh Apr 09 12:39:19 well it's true I don't mind helping people Apr 09 12:39:29 and a fine job you do as well Apr 09 12:39:35 I try Apr 09 12:40:09 now if the architectures for my different images are one and the same, how will setting the package architecture in the package recipe help? Apr 09 12:40:34 xerent: when you say architectures, what do you mean? Apr 09 12:40:40 is the MACHINE value different or the same? Apr 09 12:41:17 "For example, packages can exist for the i586 or qemux86 architectures" <- Both images are built for i686 Apr 09 12:41:51 machine names are different Apr 09 12:42:34 as in we get images deployed to tmp/deploy/images/foo/ and tmp/deploy/images/bar/ depending on if we build a foo or a bar image Apr 09 12:42:41 xerent: right, but those images comprise no-architecture ("all") arch-specific ("i686") and machine-specific ("qemux86") packages Apr 09 12:43:01 PACKAGE_ARCH is how the system knows which one the recipe should go into Apr 09 12:43:10 and hence when the recipe needs rebuilding Apr 09 12:43:29 (and PACKAGE_ARCH = "${MACHINE}" also means it'll go into a separate workdir for each machine) Apr 09 12:47:38 do I put it into the package recipes or into the image recipe? Apr 09 12:48:05 for each package I presume Apr 09 12:48:19 the package recipes that are machine-specific yes Apr 09 12:49:43 the PACKAGE_ARCH for image recipes is already "${MACHINE_ARCH}" (and wouldn't ever be anything else - assuming they're the rootfs they're always going to be machine-specific) Apr 09 12:49:57 (FYI) Apr 09 12:50:30 ok, this seems to work now. thanks again for your insights Apr 09 12:50:45 do you get paid for this? Apr 09 12:50:56 you should Apr 09 12:51:09 I get paid to work on the Yocto Project yes Apr 09 12:51:20 great Apr 09 12:51:23 I wouldn't say I get paid to do support, that's something I do because I think it's important ;) Apr 09 12:51:24 I get paid to ask stupid questions ;) Apr 09 13:07:18 isn't poky built on openembedded core? Apr 09 13:08:28 mago_: yes it is. Apr 09 13:08:52 poky is a reference implementation distro Apr 09 13:09:03 shouldn't there be a layer called openembedded-core somewhere in my poky dir then? Apr 09 13:09:19 the oe-core layer is called 'meta' Apr 09 13:12:57 ah, i see Apr 09 13:15:24 if I were to create a new distro, which shall support two custom hardware boards, should I start from yocto or base my work on openembedded-core? my two boards are based on SoCs which are supported in 2 different BSP layers already, but I need to modify the kernel and add new boards etc. Do I need to unify the kernel from both of these BSP layers and create my own kernel recipe? Apr 09 13:26:07 mago_: it depends ;-) if you make your own distro as an 'end product', i would tend to recommend to use oe-core.. but it's more a personal preference.. if you simply need to build rootfs for development and the end goal is not the distro, then poky is fine. Apr 09 13:30:14 okay. well, i would like to generate u-boot, kernel and rootfs and distribute those. I would also like to provide an SDK package and some means for users to install customized applications on their boards. In the long term, I would like to be able to distribute the whole build system so that advanced users may add custom layers etc Apr 09 13:33:47 mago_: i would personnally do it with oe-core... but you might want to hear from others too.. Apr 09 13:36:09 you can easily extend poky and tweak it, but poky is really just the confi/distro/poky.conf file so its trivial to copy the bits from that which are interesting and build your own Apr 09 13:36:14 ok. still, the problem with the kernel remains. how would you solve it? I guess I could create an image recipe which relies on PREFERRED_PROVIDER to select virtual/kernel provider differently for each type of board? so when I build boardX, it selects kernelX to provide virtual/kernel and kernelY when I build boardY. Or is the preferred solution to create a single kernel which is capable of supporting both boards? Apr 09 13:36:23 poky really is just an example of building a distro from the pieces and something that QA use to test Apr 09 13:36:37 mago_: both are acceptable Apr 09 13:36:55 mago_: yocto's kernel builds for everything, but you can have preferred-providers per machine if you want Apr 09 13:37:21 rburton, what do you mean "builds for everything"? Apr 09 13:37:53 linux-yocto can be build for all machines that oe-core/poky support Apr 09 13:38:01 and all the ones that meta-intel builds too Apr 09 13:38:49 your choice really Apr 09 13:39:19 and I can extend linux-yocto with support for my specific boards? Apr 09 13:39:35 yes Apr 09 13:40:14 some consider linux-yocto to be overly complex, but it does let you manage numerous machines and configurations relatively easy Apr 09 13:40:33 how does the recipe handle that? do i need to supply it with patches? or in what format do i input my changes to the yocto kernel? Apr 09 13:41:35 i suggest you look at the manual for it, on the yoctoproject site Apr 09 13:41:55 thanks Apr 09 14:07:09 did someone of you encountered a bug like this: "error: bad value (e5500) for -mtune= switch" Apr 09 14:07:50 I encounter it when trying to build the meta-fsl-ppc b4860qds-64 kernel. Apr 09 14:08:01 any suggestions? Apr 09 15:14:00 hi Apr 09 15:17:00 hi there, I'm having a strange problem with a yocto build, we build an ext3 and a tar.gz rootfs, the tar is good (I can boot it over NFS) but the ext3 is broken, it's missing the /etc dir, and many binaries are installed to / instead of /usr/bin, and probably there are more issues (and of course this doesn't boot) Apr 09 15:17:10 hi all, what is the correct way to configure /etc/timezone? Apr 09 15:17:20 add tzdata to my image? Apr 09 15:17:24 I'm not sure how the archive and the ext3 fs could end up being different, any hint on how the ext3 image is built? Apr 09 15:19:07 anyone around using qttools from meta-qt5? i need "lrelease" as build time dep in my own recipe. qttools gets build without errors - but the files split into "qttools-tools" don't get installed into sysroot. calling for DEPENDS+=qttools-tools results in "nothing provides qttools-tools". any ideas? Apr 09 15:22:24 seezer_: DEPENDS specifies build-time dependencies; I'm assuming qttools-tools is a runtime target so it's not valid there Apr 09 15:23:13 TuTizz: I believe so yes Apr 09 15:23:33 bluelightning, ok ty Apr 09 15:23:39 PlkMndy: which version of the build system are you using? Apr 09 15:25:18 I'm not sure, there are so much versions of everything. Does "yocto / poky / dora" answers this? Apr 09 15:26:31 yocto is the project, poky is a reference distribution, dora is a version :) Apr 09 15:27:19 PlkMndy: I wonder if the filesystem is running out of space/ inodes and it's just not failing as it should Apr 09 15:29:17 [2698190.503065] EXT4-fs error (device loop0): ext4_iget:4207: inode #15236: block 1918989871: comm ls: invalid block Apr 09 15:29:25 bluelightning: ah you're right thanks.. qttools-native is what i was looking for Apr 09 15:29:39 I get this in the syslog if I mount the rootfs Apr 09 15:30:37 doesn't it recreate the rootfs from scratch at each build? do I need to clean something? Apr 09 15:36:44 seezer_: right yes that sounds more like it Apr 09 15:37:37 PlkMndy: you could try setting IMAGE_ROOTFS_EXTRA_SPACE to enlarge the image Apr 09 15:38:25 PlkMndy: I would suggest having a look at tmp/work///1.0/temp/log.do_rootfs to see if there are any obvious errors Apr 09 15:38:25 I already have IMAGE_ROOTFS_EXTRA_SPACE = "50000" in the image recipe Apr 09 15:38:28 ah ok Apr 09 15:45:14 bluelightning: yet i'm not quite sure how to use it from my application's build system.. i'm currently using $$[QT_INSTALL_BINS]/lrelease which resolves into "wrong" sysroot inside make.. do you happen to know how i could tackle that? Apr 09 15:45:26 hmm, whats the correct way to provide "per machine" SRC_URIs? I thought it'd be enough to have a files/$MACHINE directory and put the stuff there Apr 09 15:46:29 Jin^eLD: that should work automatically, since FILESPATH gets expanded using OVERRIDES which includes ${MACHINE} Apr 09 15:47:03 seezer_: we do have an OE_QMAKE_LRELEASE variable that points to the lrelease binary FWIW Apr 09 15:49:44 bluelightning: would that also work with bbappend's? there is an original .bb which provides files/ntpd script, and in my bbappend I wanted to split that out into files/machine1/ntpd and filesl/machine2/ntpd and I ahve FILESEXTRAPATHS_prepend := "${THISDIR}/files:" set Apr 09 15:49:58 but in this constellation the original ntpd is taken, not the one from bbappend Apr 09 15:54:18 Jin^eLD: it should, but which file is picked depends on the overrides used - if you look at log.do_fetch you can see exactly where it is looking for files Apr 09 15:54:21 bluelightning: i see.. but i don't have that in the run.do_compile.. is it something new or some kind of missconfiguration? Apr 09 15:55:26 seezer_: are you using qmake / cmake or something else? Apr 09 15:55:35 bluelightning: qmake yes Apr 09 15:56:40 seezer_: so there is code in meta/classes/qmake_base.bbclass which should hack the .pro file to point to at least the right executable name for lrelease Apr 09 15:57:22 if you also patch them to not use $$[QT_INSTALL_BINS] I think it should then pick up the right binary just via PATH Apr 09 16:02:27 Hmm, where's the log for postinst intercept failures? Apr 09 16:02:28 bluelightning: hm strange.. the path in run.do_compile doesn't include the qt5/ subdirectory in sysroots/x86_64/usr/bin Apr 09 16:02:35 it mentions one, but doesn't say which one to look at Apr 09 16:07:50 bluelightning: hmm, SRC_URI of the original recipe clearly mentions a file://ntpd, howver in log.do_fetch - I do not see this file, I do see some others though, that makes no sense... Apr 09 16:13:16 seezer_: it could be that that's deliberate, I had assumed that those would be in /usr/bin Apr 09 16:14:06 seezer_: worst case you could use sed to modify the .pro file in a do_configure_prepend() to point to ${OE_QMAKE_LRELEASE} Apr 09 16:14:26 Jin^eLD: that sounds strange, they should match up directly Apr 09 16:15:23 bluelightning: yes... it is as if it is not in the SRC_URI at all, which makes totally no sense Apr 09 16:15:50 Jin^eLD: silly question, but you are looking at the right log.do_fetch - right? Apr 09 16:16:02 i.e. one from the same build Apr 09 16:17:01 bluelightning :) yeah I remember I had that problem once ;) I did -c devshell this time Apr 09 16:17:23 and ntpd script is actually in the original recipe in the meta layers of OE, it should be there Apr 09 16:24:52 let's see what happens if I additionally add it to the SRC_URI in my bbappend Apr 09 16:30:32 bluelightning: problem is i don't have the OE_QMAKE_LRELEASE set here.. perhaps it's newer than my current head - i'll look into that, thank you very much Apr 09 16:32:41 bluelightning: yep, after I added it additionally in my bbappend it worked.. really strange Apr 09 16:46:22 Hi All, I've got a kernel recipe that *looks* like its stalling in fetch. Its supposed to just pull down a specific rev from git. I can clone the repo directly OK but when fetch looks stalled I cant see any temp download stuff under downloads. Is there any way to debug fetch better than "bitbake -v" which doesnt show anything? Apr 09 16:49:24 pev: use ps and see if there's a git fetch running Apr 09 16:52:29 dss11 ist im yocto noch nicht wichtig Apr 09 16:52:32 oops wrong window Apr 09 16:59:54 rburton: Nope, none running frustratingly Apr 09 17:03:32 rburton: No, i tell a lie...! Apr 09 17:22:03 hello again, regarding my fs corruptions issues, it looks like it's because I merged latest changes including http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dora&id=f1276b066223e7f501f7f711680215ff8edee252 Apr 09 17:22:21 and this doesn't work right on an already existing image and corrupted it Apr 09 17:28:33 PlkMndy: I wouldn't have thought the fact that there was anything existing should make a difference Apr 09 17:28:43 PlkMndy: if you revert that patch does the problem go away? Apr 09 17:28:52 yes, that was unexpected Apr 09 17:29:09 well, I found a solution, I added RM_OLD_IMAGE to my local.conf and that fixed it Apr 09 17:29:36 looking at the script that generates the ext3 fs, it tries to create an empty image by dding from /dev/null to the last block of the image Apr 09 17:29:55 which creates an empty file of the right size if nothing exists, but doesn't clear an existing file Apr 09 17:30:05 and then, uses mkfs on that Apr 09 17:30:39 so if the image is smaller than a previous version, there could still be data from the previous image at the end of the file, for example Apr 09 17:30:59 PlkMndy: I'm a little puzzled as to why it would be looking at an existing image file to be honest Apr 09 17:31:17 PlkMndy: would you mind filing a bug for this? Apr 09 17:31:30 Is Florin Sarbu on irc? Apr 09 17:32:35 bluelightning: as far as I can tell, the filename for the image doesn't seem to use a timestamp, but I may be wrong Apr 09 17:32:56 PlkMndy: that should just be a symlink though, created after the real image Apr 09 17:33:10 if you mean the file in tmp/deploy anyway Apr 09 17:33:15 or do you mean a different file? Apr 09 17:35:47 no, I mean that, but you're right Apr 09 17:36:06 so I don't know how I ended up with persistent corruption on two different machines then Apr 09 17:36:17 PlkMndy: I think the bottom line is this really shouldn't be failing anywhere Apr 09 17:37:14 luckily the maintainer for the dora stable branch is the same person on that patch you linked, so if you can file a bug and add him (Robert Yang) on CC then he should be able to fix it Apr 09 17:38:42 * pidge kicks the autobuilder and hopes to not flood the channel again. Apr 09 17:47:20 bluelightning: I created an account at https://bugzilla.yoctoproject.org/, but I'm not sure which component to put the report in? Apr 09 17:59:50 PlkMndy: this would be OE-Core / Core Apr 09 18:01:52 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6141 Apr 09 18:01:52 Bug 6141: normal, Undecided, Future, saul.wold, NEW , Rootfs ext3 filesystem was corrupt Apr 09 18:19:14 Hmm, qemu-ppc crashes and burns trying to run the target binaries for p4080ds at do_rootfs time for the intercepts Apr 09 18:19:17 * kergoth digs Apr 09 18:39:56 yocto image without samba: 42.9M, image with samba 123.7M Apr 09 18:40:55 yikes Apr 09 18:41:34 I tried first to build samba4 myself. i gave up last night and use now 3.x from the meta-oe layer Apr 09 18:41:47 samba binaries are huge, yes Apr 09 18:42:02 last I checked it was a known problem upstream, with no plan to fix it Apr 09 18:42:20 not sure if samba4 fixes it, probably... Apr 09 18:42:39 it looks also like the configure script in samba3 got highly modified to get it build Apr 09 18:43:58 is there already a framework that cherry-picks recipes from other repositories? Apr 09 18:44:39 what I do right now with samba is manually copying only the two required recipes into our internal SCM Apr 09 18:45:05 there's combo-layer: https://wiki.yoctoproject.org/wiki/Combo-layer Apr 09 18:45:18 I'd be the first to admit it's a little bit fiddly though Apr 09 18:45:29 (and I wrote the thing...) Apr 09 18:45:31 i doubt that does the recipe level, though Apr 09 18:46:04 kergoth: it's not turn-key for individual recipes, but it will at least keep a directory or a wildcard matching some files up-to-date for you Apr 09 18:46:35 the ideal case is just to re-use the entire layer Apr 09 18:46:36 if i need more public recipes I might hack a small script, in the meantime I just do it manual. It's not complex Apr 09 18:47:05 bluelightning: teh entire layer would be much more and you never know what other side effects it might have with a higher priority Apr 09 18:47:50 volker-: that's the other thing, if it's just a software layer it's supposed to have no side-effects other than adding recipes Apr 09 18:48:02 I used to use a little class that copied a recipe and its associated files into another directory, to populate a layer that was a subset of another layer. but that's because we had no other option, pre-oe-core :) Apr 09 18:48:08 that's still not totally true for meta-oe unfortunately :/ Apr 09 18:48:25 nowadays layers should be fairly small and well behaved (one hopes) Apr 09 18:48:32 indeed :\ Apr 09 18:48:46 maybe we'll finally get the last piece tidied up in the next cycle Apr 09 18:49:12 nothing wrong in how it is right now. I was just curious if someone did already something because it fit their own needs :) Apr 09 18:49:17 everyone has different requirements :) Apr 09 18:49:23 we just pull in and lock down upstream layers Apr 09 18:49:26 i expect htats what most do Apr 09 18:50:18 volker-: this particular issue is one of my pet peeves, don't worry ;) Apr 09 18:50:33 hey, there it is! i forgot it was in oe classic. yikes, i can't say that was the greatest code Apr 09 18:50:36 * kergoth shakes head Apr 09 18:50:37 (http://git.openembedded.org/openembedded/tree/classes/newcollection.bbclass) Apr 09 18:50:41 I don't know if you are familiar with Chef (deployment framework). What happend there is that every cookbook (more or less a recipe group for a single task like apache, nginx, userconf) got put into its own recipe and that a framework downloads them. Apr 09 18:51:11 not what I talked about in my case, but a structure that is similar to yocto (so someone might be interested into the idea). Apr 09 18:51:47 I think it'd be cool to have an apt-like tool that was backed by layer urls, which would "install" a recipe and its deps into a local project area, which could include fetch/unpack/patch, even, and then your builds would be against that Apr 09 18:51:54 but obviously such a thing doesn't exist today Apr 09 18:53:32 https://gist.github.com/volker-fr/6c1308932f82b673b04a Apr 09 18:53:59 kergoth: interesting idea Apr 09 18:54:21 volker-: that sounds rather painful to maintain :) Apr 09 18:55:03 obviously something that makes maintenance harder would be a difficult sell Apr 09 18:55:13 kergoth: yeah. build a tool around it that checks for differences once in a while ;-) Apr 09 18:55:41 it doessound like combo-layer may be your best bet at this point, if not as is, then as a starting point Apr 09 18:56:00 kergoth: I am force to use perforce and I want to have two recipes in our SCM to have it repeatable Apr 09 18:56:22 s/force/forced/ Apr 09 18:56:40 I'd just import the entire layers, personally :) if the layers are well behaved, including them won't impact anything they shoudln't impact Apr 09 18:56:56 and if they aren't well behaved, its a bug that should be fixed Apr 09 18:56:56 on the other side, I need to keep track of our security anyway (see OpenSSL ;-) Apr 09 18:58:42 The entire .git folder in meta-openembedded is 21M while I only need 1.2M from it (and ignore the missed history here) Apr 09 18:59:39 bbl Apr 09 19:03:50 yeah, the combo-layer looks interesting, but it really copies everything and not just a small selection Apr 09 19:04:47 that's what i said, and paul indicated that it can operate against a wildcard Apr 09 19:04:49 * kergoth shrugs Apr 09 19:04:53 never used it myself Apr 09 19:05:41 the layers.openembdedded.org does not contain all layers from git.yoctoproject.org Apr 09 19:05:46 why is that? Apr 09 19:05:59 i doubt it was intentional, likely just an oversight Apr 09 19:06:24 could open a big in the yocto bugzilla about it, presumably Apr 09 19:06:26 bug Apr 09 19:30:01 hey look, i reproduced the NameError: global name 'd' is not defined bug again Apr 09 19:30:05 maybe i can finally fix that Apr 09 20:27:07 I've got a question about pulseaudio, if I add pulseaudio to my build in conf/local.conf should I expect to see all the libs in the pulseaudio.inc recipe? I appear to be missing libpulse-simple.so and a few others, they show up in the sysroot on the build machine, but not in the sdcard image, any idea why? Apr 09 20:28:49 crankDeric: don't know how it is with pulseaudio, but the kernel does not install all the kernel modules on default it builds (at least not with the small default distro) Apr 09 20:30:00 crankDeric: with e2fsprogs I saw that you have to add the packages you need, else you don't get the fsck or mkfs automatically Apr 09 20:30:08 but I am not a yocto expert ;-) Apr 09 20:30:17 volker-: So I've got IMAGE_INSTALL_append = "pulseaudio" Apr 09 20:30:40 and if I look at the recipie for pulseaudio in the poky/meta/recipies-multimedia/pulseaudio dir theres a pulseadio.inc file Apr 09 20:31:07 it seems to indicate that those libs will be built, and they are, but they aren't packaged in my .sdcard, any idea how I tell Yocto to put those on my target rootfs? Apr 09 20:31:21 crankDeric: see PACKAGES_DYNAMIC Apr 09 20:31:22 crankDeric: what I do is going into tmp/deploy/deb/*/ and look there at the packages and define them extra in IMAGE_INSTALL_append (deb because I use debian packages, yours might be different like opkg or similar) Apr 09 20:31:31 it breaks up into many small binary packages the way kernelm-doule- does, as volker- has pointed out Apr 09 20:31:45 pulseaudio-module-*, etc Apr 09 20:31:49 add the ones you need to IMAGE_INSTALL Apr 09 20:31:55 kergoth: okay, thanks! Apr 09 20:32:05 volker-: thanks as well Apr 09 20:32:50 good on the one side, bad on the other side because if you start the default one seems to be as less packages as possible and then you boot and are confused why the kernel modules and similar are not there ;-) Apr 09 20:33:34 using granular packaging is a nice compromise solution between large images and stripping things out, since you can pull in what you need, but yeah, itd be nice if things were a little more discoverable Apr 09 20:33:41 actually, this would be a good case to use toaster, in the future Apr 09 20:33:46 probably Apr 09 20:42:47 RP, awesome email Apr 09 20:43:36 we should have a discussion at OEDAM if/how "OE" can improve YP releases Apr 09 20:44:28 I think we should branch off the release sooner, and truly make it bugfix-only at that point, avoid this last minute feature submission thing Apr 09 20:44:32 IMO anyway Apr 09 20:44:39 kergoth: toaster? Apr 09 20:45:42 volker-: it's the new UI for examining builds being developed. https://www.yoctoproject.org/tools-resources/projects/toaster Apr 09 20:45:44 https://www.yoctoproject.org/blogs/belenbarrospena/2014/eye-candy Apr 09 20:45:49 pretty cool stuff Apr 09 20:45:56 ah yeah, thats the link i was looking for and couldn't find Apr 09 20:45:58 thanks Apr 09 20:45:59 hehe Apr 09 20:46:19 I am in the process of replying to the email Apr 09 20:46:37 toaster is its own build system and not compatible with other build systems? Apr 09 20:47:17 no, its a bitbake UI that lets you examine your bitbake builds to see how they went Apr 09 20:47:28 it doesn't build, at this time anyway Apr 09 20:47:44 ok, just curious :) Apr 09 20:47:45 you drop into its environment, do builds, and use toaster to look at them Apr 09 20:47:53 afaik, anyway, i haven't used it much, just tried it once Apr 09 20:55:56 I looked a little at ELCE Apr 09 20:56:09 seems to help you get a grasp on depends Apr 09 20:56:24 yeah, like a much, much prettier depexp + more Apr 09 20:56:38 being a hard core gui hater, I am having a hard time figuting out why a gui will help Apr 09 20:56:40 its one of the most common questions, so it makes a lot of sense to answer it in a way that's nice Apr 09 20:57:00 but I also know that many customers like this stuff Apr 09 20:57:03 personally, i want to do more work on the sub-command based ui, with whatdepends/whatprovides/etc, to answer the same questions at a commandline Apr 09 20:57:09 but i'm anti-ui mostly too :) Apr 09 20:57:12 and if reduces my workload, I am all for it Apr 09 20:58:38 why do people hate rc.local now? Apr 09 21:09:56 what is the best place to drop random recipes of? Apr 09 21:10:13 e.g. when I wrote a monit 5.8 recipe Apr 09 21:12:03 nagios has monitoring-plugins.org, chef has community.opscode.com, what does yocto have? Apr 09 21:19:33 you can post your own layers where appropriate. meta-oe tends to get random stuff that doesn't have a real place to belong Apr 09 21:19:43 folks often run their own meta- layers for local bits Apr 09 21:36:45 if i have a makefile which has a echo output as make all and for the install i do need to perfomr "make install", how do i configure my recipe to do this ? acutally run.do_compile calls "make" and run.do_install has nothing to do but the install_append() tuff i added on my own. Apr 09 21:37:29 i could patch the makefile, but this isnt a good solution i guess Apr 09 21:38:03 or do i just put a do_configure_append { make install } ?? Apr 09 21:40:33 kergoth: and where do I drop it off then? Apr 09 21:40:42 I don't understand the question Apr 09 21:41:13 kergoth: if I have something and think it might be helpful for other people, where do I drop my own meta-volker off? Apr 09 21:42:32 kergoth: sorry, I rephrase this, where do I "post" my own layer? Apr 09 21:43:01 anyone can add a layer to the layer index Apr 09 21:45:36 ok, excuse my question, I oversaw the "Submit layer" button :( Apr 09 21:51:03 volker-: heh, np :) Apr 09 22:03:36 If you do a full release, what is the most important thing beside keeping the steps repeatable (by using a local mirror, using fixed repository version/hashes)? Apr 09 22:03:57 How helpful is the buildhistory option? Apr 09 22:09:00 buildhistory is extremely useful. there's a ton of useful info in there. you can use it to compare output before and after a cahgne, to mamke sure your change didn't affect something other than what you expected, and so you can use it to monitor for image size changes more than you intend, can examine what packages are in your images, etc. i wouldn't build without it Apr 09 22:21:54 Does anyone have a feeling whether the patch being discussed at https://patchwork.kernel.org/patch/3926081/ will make it through LTSI and into Yocto in time for the 1.6 release? I'm tripping over that bug in one configuration and am consider submitting a bbappend to add it just in case it doesn't make it through. Apr 09 22:23:01 nitink: the link above ^^ is from you. Apr 09 22:24:44 dmoseley: that fix is already in the Yocto kernel Apr 09 22:25:01 Hmm. My tree must be behind. Thanks. I'll repull everything. Apr 09 22:25:32 dmoseley: right, you will need to get newer SRCREVs for kernel recipes Apr 09 23:15:10 whoever gave our build system 1GB RAM, it is not enough to handel two yocto builds at the same time... Apr 09 23:16:06 1gb is likely about what you need for one :) Apr 09 23:18:22 I get out of memory errors in the one case and the other case the error message is not 100% clear Apr 09 23:25:04 rfol Apr 09 23:25:17 I put as much ram in min eas it could hold Apr 09 23:26:19 the previous sys admins where strange. newest gear but then 8GB ram in each system. And on top of that some VMs Apr 09 23:51:37 nitink: I just pulled the latest poky and built a v3.10 kernel and it does not include that patch. Are you expecting that it's fixed in v3.10 or just v3.14? Apr 09 23:51:57 I used MACHINE=genericx86. Apr 09 23:52:39 dmoseley: it is fixed in v3.10, v3.14 does not have LTSI support as of now Apr 09 23:53:49 dmoseley: how are you checking whether the patch is in or not? did you try building? Apr 09 23:54:32 I did "bitbake -c configure linux-yocto" with PREFERRED_VERSION_blah set in my local.conf Apr 09 23:55:46 dmoseley: looks like the poky v3.10 kernel recipe need SRCREV updates to get this fix Apr 09 23:56:04 in meta-intel we get kernel version 3.10.35 Apr 09 23:56:22 in poky I am seeing version as 3.10.34 which does not have this fix Apr 09 23:56:40 Yeah, that's what I'm seeing. Apr 09 23:57:08 zeddii: ^^^ the v3.10 kernel recipes in the poky need srcrev updates Apr 09 23:57:50 dmoseley: zeddii sends these SRCREV updates for oecore/poky layers Apr 09 23:58:50 OK. Gotcha. I'll keep an eye out for it. Sounds like getting it in before 1.6 should not be a problem though. Apr 09 23:59:22 dmoseley: you can open a bug in https://bugzilla.yoctoproject.org for updation of SRCREVS of v3.10 kernels in poky/oecore Apr 10 00:00:06 it will be easy for zeddii to track and plan this work Apr 10 00:01:12 dmoseley: updatation of SRCREVs will need validation with multiple BSPs, so it may take some time Apr 10 00:01:28 Yeah, I figured as much. Apr 10 00:21:31 Does anyone know if ther'es a way to opt-out of the qemu.bbclass bits, for do_rootfs-time operations? Apr 10 00:21:55 in some cases, qemu's user mode emulation doesn't support the instructions used for the tuning in question, resulting in do_rootfs postinst failure warnings Apr 10 00:22:22 I'm thinking there isn't such a method at the moment, but figured i'd check and see if anyone has run into such things before **** ENDING LOGGING AT Thu Apr 10 02:59:58 2014