**** BEGIN LOGGING AT Thu Aug 27 02:59:58 2015 Aug 27 06:10:21 Anyone got a howto for creating a package feed? Aug 27 06:38:49 I use angstrom, so the ideal would be a howto that lets me just change the ANGSTROM_URI, but otherwise use angstrom-feed-configs.bb as it is. Aug 27 06:57:42 seems adjusted upload-packages.bb and sort.sh from angstrom will take me a long way. Aug 27 08:25:48 morning all Aug 27 11:42:38 Hello! Aug 27 11:43:02 I'm building a little distro using arago for am3352 Aug 27 11:43:38 I manage to succesfully build it, but I'd like to make one more step after I get the image tar Aug 27 11:44:04 I'd like to generate a checksum for the image and put it in a file Aug 27 11:45:15 I've tryed adding do_package_append to the image recipe, but I get "invalid syntax (, line 26)" Aug 27 11:46:23 I've also tryed on declaring it as a notmal task, and then adding it using addtask checksum after do_package" Aug 27 11:46:51 but in that case It does not get executed at all Aug 27 11:47:39 roosemberth: Depending on how you want to set it up, using the POSTPROCESS_COMMAND function stuff might work better -> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration-1.6-variable-changes-variable-entry-behavior Aug 27 11:48:54 thank you, I'll take a look and report back Aug 27 12:17:50 Thanks for your help, seems that the POSTPROCESS_COMMAND worked! Cheers! Aug 27 12:25:51 hi, i am making a recipe for my bsp layer, and I am not sure what is the most proper LICENSE field value to use for https://www.codeaurora.org/cgit/quic/kernel/skales/tree/dtbTool.. what would you put? Aug 27 12:29:08 ndec: you'd have to compare the text, but at a glance it looks like it might be a BSD flavour ? Aug 27 12:29:50 yes, it looks like that. Aug 27 12:32:29 it's the 3-clause one.. somehow i forgot about this one.. and was expect the orginal bsd.. thanks Aug 27 13:44:39 JaMa: yt ? Aug 27 13:45:00 seeing a webkit failure I wonder if you see same Aug 27 13:45:42 build/tmp-angstrom-glibc/work/corei7-64-angstrom-linux/qtwebkit/5.5.0+gitAUTOINC+3f0fbb46e2-r0/git/Source/WTF/wtf/gobject/GRefPtr.cpp:24:18: fatal error: glib.h: No such file or directory Aug 27 13:45:46 | #include Aug 27 13:46:06 problem is that in this case WAF makefile gets extra /usr appending to sysroot base Aug 27 13:46:42 so -I search path for glib-2.0 header ends up with /usr/usr/include/glib-2.0 Aug 27 13:47:06 Dont know yet where qmake is doing this concatwnation Aug 27 13:48:30 khem: with current master or master-next? Aug 27 13:48:39 master as well as master-next Aug 27 13:48:48 it seems to happend after 5.5.0 updat Aug 27 13:48:49 e Aug 27 13:50:21 have you tried to call qmake with -d and check log.do_configure? Aug 27 13:50:49 http://errors.yoctoproject.org/Errors/Details/15046/ Aug 27 13:50:55 looks the same from latest world build Aug 27 13:51:38 I havent yet Aug 27 13:51:51 was trying out if someone already has fixed it Aug 27 13:52:17 btw. how do we hook builder reports into errors.yp.org Aug 27 13:52:26 I would like to send my builder reports Aug 27 13:52:38 now I have regular builds happening for clang and musl Aug 27 13:53:00 see "report-error: Allow to upload reports automatically" commit in contrib/jansa/master Aug 27 13:57:00 JaMa, khem: seeing same issue with qtwebkit now Aug 27 13:57:52 OK so that makes it 3 of us Aug 27 13:58:19 it was building fine just a day or two ago... trying to see what broke it - is it "refresh patches" commit? Aug 27 13:58:42 did it build with 5.5 for you ? Aug 27 13:58:46 it did Aug 27 13:59:52 hmmm Aug 27 13:59:59 last successful build: meta-qt5 = master:97ce05c0b2a81f05388d7f727741529fb9177775 Aug 27 14:00:33 actually, that would include all commits from Aug 25, so something in Aug 26 broke it Aug 27 14:00:53 isnt that tot Aug 27 14:01:17 did something go into OE-Core that broke it hmm Aug 27 14:03:06 khem: I'm building against fido, so that didn't change Aug 27 14:03:22 I have my suspicions on c0cc4ff88292d1ddd9d30007e4947342d71ae77d Aug 27 14:03:24 :/ Aug 27 14:06:30 looks suspicious, can you please reply on the ML? Aug 27 14:09:10 denix: your suspision is well founded Aug 27 14:09:25 as I read the code its definitely the culprit Aug 27 14:10:08 its replace a sysroot with host dir on target which is /usr generally Aug 27 14:10:17 so its adding that additional /usr Aug 27 14:10:43 it may work for the rest of qt, but webkit is a beast on its own and screwing with it's build flags is risky Aug 27 14:10:47 before the includedir it gets from glib-2.0.pc file gets appended to it Aug 27 14:11:45 same issue in qtwebengine it seems Aug 27 14:12:28 http://paste.ubuntu.com/12206001/ Aug 27 14:12:43 thats ./usr/lib/qt5/mkspecs/qconfig.pri Aug 27 14:13:24 now we need to check whats QT_INSTALL_PREFIX Aug 27 14:24:07 there we go Aug 27 14:24:09 /home/ubuntu/work/oki-robot/build/tmp-angstrom-glibc/sysroots/x86_64-linux/usr/bin/qt5/qmake -query QT_INSTALL_PREFIX Aug 27 14:24:12 /home/ubuntu/work/oki-robot/build/tmp-angstrom-glibc/sysroots/intel-corei7-64/usr Aug 27 14:24:43 and then it appends the incdirs to it which are /usr/include/glib-2.0 Aug 27 14:24:50 and all comes out wrong Aug 27 14:28:48 we are replacing the STAGING_DIR_HOST which does not have /usr at the end with QT_HOST_PREFIX which has /usr Aug 27 14:29:02 and similar replacement is being done for QT_INSTALL_PREFIX Aug 27 14:29:13 in that patch Aug 27 15:29:50 hmmm is it just me or is linux-yocto 4.1 missing kernel-module dependencies? Aug 27 16:02:26 JaMa: fixed with http://patchwork.openembedded.org/patch/101829/ Aug 27 16:26:35 khem: thanks added to master-next Aug 27 16:26:45 cool thx Aug 27 17:15:55 * kergoth wonders if we can convince the meta-oe folks to lower the meta-oe priority after we get rid of all the overlayed bits Aug 27 17:20:36 I doubt that Aug 27 17:21:07 but you can override layer priority in your bblayers.conf, cannot you? Aug 27 17:21:41 yeah, and i usually do, both in layer order and the priority variable, just trying to pare things down Aug 27 17:21:51 the main value of meta-oe is additional recipes, though Aug 27 17:22:00 so it really *shouldn't* need a priority higher than oe-core Aug 27 17:22:09 and doing so interferes with the main value of oe-core, which is a solid well tested baseline Aug 27 17:22:16 * kergoth shrus Aug 27 17:22:20 * kergoth shrugs, even Aug 27 17:23:16 i should probably lower the priority of a few of the layers i maintain, actually. meta-mentor-staging needs to be higher, but the rest probably less so Aug 27 17:24:34 Any folks maintaining mirrors want to try out the shallow mirror tarball support, by chance? should get more testers, i expect, before richard would be willing to merge it Aug 27 17:26:24 kergoth: the problem is when the additional recipes need additional changes to oe-core like recipe with higher version Aug 27 17:26:51 fair point Aug 27 17:27:20 and this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2964 doesn't help with this :/ Aug 27 17:27:34 it still concerns me, though. it's too easy for it bloat up with overlayed stuff over time unless we're vigilant Aug 27 17:28:06 ugh, yes, i hate, hate, hate that a higher priority layer with a lower version of a recipe gets preferred over a higher version of a recipe in a lower priority layer by default Aug 27 17:28:12 I'm at least trying to persuade people moving stuff to oe-core to send removal patch for moved recipes Aug 27 17:28:25 we had a layer with udev 164 around for some really really old bsp support, and we were *forced* to define PREFERRED_VERSION_udev as a result Aug 27 17:28:34 that way they should double check that the version they've migrated wasn't modified later in original layer Aug 27 17:29:00 ah, yeah, that's good, that is important Aug 27 17:29:11 * kergoth needs to remember to do that after he submits the oe-core addition of iw Aug 27 17:29:12 I don't mind the lower version being preferred Aug 27 17:29:31 but if I mark some recipe with negative DEFAULT_PREFERENCE I really want people to explicitly ask for it Aug 27 17:30:11 which isn't the case now, because as soon as I put e.g. experimental glib version to meta-efl required for webkit-efl, all meta-efl users will automatically get this glib version Aug 27 17:30:27 here's a question for folks, i'm taking a recipe from meta-oe and putting it into oe-core, but i have a bunch of improvements to the recipe. do i do it as a number of a commits, so the first one is the pristine add of the original file from meta-oe for historical record, rather than combining them? I'm inclined to that granular approach, myself, having historically had a hell of a time separating the original file from the modifications Aug 27 17:30:39 and only thing I can do as layer maintainer is to put glib together with BBMASK of it, which looks stupid and is hard to use Aug 27 17:31:01 because people don't know how to correctly mess with more complicated regexp which can end in BBMASK Aug 27 17:31:24 JaMa: i wonder if we could get negative DEFAULT_PREFERENCE to be stronger than a positive DEFAULT_PREFERENCE, to handle that specifically, so the latter stays weak per richard's preference, but the former is stronger than layer-based priority Aug 27 17:31:28 hmm Aug 27 17:31:41 I prefer granular approach as well (as long as the pristine copy is still buildable in oe-core) Aug 27 17:32:29 yes, that could be interesting, just a bit strange that negative would work differently than possitive numbers Aug 27 17:32:47 whole layer/recipe/class/bbappend priorities are quite confusing to new people already :/ Aug 27 17:33:31 agreed. Aug 27 17:33:48 it's not unlike the ordering issues in bitbake, it's something that's not necessarily either intuitive or something easily inspected / discovered Aug 27 17:34:20 I wonder if we have real cases where we need different BBPATH order than layer priorities Aug 27 17:34:39 it would be nice to search everything just based on order in BBLAYERS variable Aug 27 17:35:13 god yes. that was my main complaint when bblayers was introduced Aug 27 17:35:21 COLLECTIONS used to cover both with a single order-based priority Aug 27 17:36:07 maybe it would still be confusing with layer dependencies :) Aug 27 17:36:32 I can imagine people adding layers to BBLAYERS based on layer dependencies than their preferred priorities Aug 27 17:36:57 JaMa: I'm hoping to integrate some aspects of meta-mentor's setup scripts into oe-core. they auto-order BBLAYERS by layer priority with args for layer priority overrides Aug 27 17:37:01 maybe that would help Aug 27 17:37:13 * kergoth ponders Aug 27 17:37:19 yes, we have something similar Aug 27 17:37:42 one file which lists all layers and preferred priorities and the script will generate bblayers and priorities overrides Aug 27 17:37:44 that shows a clear need if some of us are reimplementing the same thing on our end :) Aug 27 17:38:23 https://gist.github.com/kergoth/11f89fd365d78429e528 -- haven't had a chance to work on it recently, though Aug 27 17:38:59 heh you're using separate tmpdir for each MACHINE? Aug 27 17:39:23 currently, yeah, we don't trust bsp layers to be well behaved Aug 27 17:39:34 a number still do things without machine overrides Aug 27 17:39:53 with sstate it's not as big a deal as it used to be Aug 27 17:40:30 we're always doing multi-machine builds, so even with sstate it's so bad to even unpack native tools multiple times to different tmpdirs Aug 27 17:40:47 i need to update my todo from that gist to modify/add to bitbake-layers rather than creating bblayers Aug 27 17:40:53 and once 2 or more MACHINEs are using the same TUNE_PKGARCH the difference is even greater Aug 27 17:41:48 I could see doing that at least for our incremental / CI builds, and then keep separate for release out of paranoia (the same reason the latter doesnt' use sstate) Aug 27 17:41:50 we have an advantage that we control all BSPs we're using, so I'm enforcing them to behave correctly Aug 27 17:41:55 but we'd have to carefully audit the bsp layers Aug 27 17:41:57 ah, that does help Aug 27 17:42:43 meta-ti and meta-fsl-ppc both still have issues in this regard, need to remember to submit fixes Aug 27 17:42:52 heh, official release not using sstate? we have the same and this paranoia IMHO makes things worse :) Aug 27 17:42:53 eg meta-ti modifies udev and alsa-state unconditionally Aug 27 17:43:15 https://gist.github.com/kergoth/665eade9c4f9a7e4261b Aug 27 17:44:25 * JaMa notes leaky-layer-tests Aug 27 17:44:28 looks good Aug 27 17:44:53 need to make it extract just the -S printdiff delta from the logs, though, lots of extra bits Aug 27 17:44:54 heh Aug 27 17:45:09 used to use bitbake-whatchanged, but that's broken at the moment due to STAMPS_DIR affecting task checksums Aug 27 17:48:55 kergoth: Your first gist reminds me of a tool i wrote at Xilinx (it was a while back now) managed to get them to release it MIT'd when i left https://github.com/Xilinx/hopper. It did some of the stuff you have listed there, might be worth scouring for ideas :) Aug 27 17:49:57 huh, yeah, that is quite similar Aug 27 17:50:00 cool Aug 27 17:50:07 * kergoth adds to todo Aug 27 18:38:58 kergoth: hmm, gist.github.com seems blocked over here - what issues were you talking about? Aug 27 18:39:47 denix: alsa-state and udev are modified without machine overrides. including meta-ti but not switching to a meta-ti MACHINE still results in those two recipes modified Aug 27 18:43:15 kergoth: alsa-sstate does have machine-override - it replaces state file only for beagleboard machine Aug 27 18:44:26 ah, right, my mistake. it's not alsa-state, it's just alsa-state was the first recipe i tested -- it's udev that's the culprit Aug 27 18:44:34 udev is adding file://omap-tty.rules unconditionally Aug 27 18:44:58 that's actually the only issue in meta-ti, so well done there Aug 27 18:45:02 meta-fsl-ppc has a bunch of them Aug 27 18:45:18 kergoth: udev is harder... need that extra rule for all our machines - what's the proper way w/o listing all machines individually? Aug 27 18:45:49 Hmm, not sure, unless you at least have some SOC_FAMILY's to reduce the # of them? Aug 27 18:47:09 yeah, still quite a few of those - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include Aug 27 18:48:03 I think I can get away with probably 4 or 5 of SOC_FAMILY in the list... Aug 27 18:55:41 not pretty, but there are only so many options, and iirc obeying overrides is included in the yocto compliance requirements, so we're stuck :) Aug 27 19:20:21 kergoth, thanks for getting to the iw patch Aug 27 19:21:44 Crofton: aren't you biking in the woods of Virginia now? Aug 27 19:22:31 I wish Aug 27 19:22:37 Crofton: do you have anything to do with what's on the news past couple days? Aug 27 19:22:41 I am in DC at the gnuradio conference Aug 27 19:22:44 nope Aug 27 19:22:48 other end of the state Aug 27 19:22:59 Crofton: ok, you are off the hook :) Aug 27 19:23:05 I'm still confused why everyone is excited Aug 27 19:23:11 people shoot each other all the time Aug 27 19:23:17 just not on TV Aug 27 19:24:24 "people shoot each other all the time" - especially in Virginia, eh? Aug 27 19:24:52 yeah, not sure, it was all very weird Aug 27 19:47:22 doesn't that trigger the debate on the 2nd amendment? Aug 27 19:50:25 you are familiar with America .... Aug 27 19:52:15 can't even check drunken cowboy guns at the edge of town anymore... Aug 27 20:03:15 Crofton: np Aug 27 20:04:12 had never played with VPATH before, quite handy Aug 27 20:50:21 my rootfs is read only right after building yocto, does anyone know what this could possibly be? **** ENDING LOGGING AT Fri Aug 28 02:59:58 2015