**** BEGIN LOGGING AT Wed May 25 02:59:58 2016 May 25 06:17:02 Hi, I am working on a custom derivated board from sama5d3-xplained. The changes are very small, and it is a kind of prototype board. Thus, I do not want to simply add it into meta-atmel, because this will unlikely be published at any time. What would be the best approach to achieve this ? If I create a new meta-custom, how can I inherit from the definitions in .conf file of meta-atmel ? Basically, only the kernel changes in my case. Th May 25 06:48:16 hi, i'm looking for yocto project for Apollo Lake-I May 25 06:48:28 someone can help me? May 25 06:53:30 good morning May 25 06:54:41 tbultel: yes, best practice is to create a new meta-custom May 25 06:55:48 fabc: https://01.org/group/3606/documentation-list May 25 08:33:22 hi, are there any recipes available to build Qt5 for nativesdk, to be able to compile qt apps for the development host? May 25 09:11:12 does yocto 2.2 have a name? May 25 09:11:24 CTtpollard: not yet May 25 09:12:25 rburton: ok :) I noticed meta-qt5 have 5.7 support in master-next so I was wondering in 2.2 was close May 25 09:16:08 CTtpollard: https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule May 25 09:16:32 ty May 25 09:17:02 Oct, great May 25 09:22:34 rburton: QQ May 25 09:22:46 rburton: how long are Yocto releases really support for? May 25 09:23:14 rburton: Documentation says ... Security patches and critical bug fixes are supplied one release back. No toolchain or kernel changes are allowed for these updates May 25 09:23:19 yeah May 25 09:23:21 sounds about right May 25 09:23:31 rburton: but I still dizzy being fixed ... http://cgit.openembedded.org/openembedded-core/log/?h=dizzy May 25 09:23:39 rburton: doesn't make sense to me May 25 09:23:54 because there were some tragic CVEs May 25 09:24:09 and some vendors are still using those releases in products, so they push the fixes upstream May 25 09:24:13 rburton: really nasty CVEs will cause updates. May 25 09:24:20 rburton: ok that makes sense. May 25 09:24:20 are you complaining that older releases are getting security fixes? :) May 25 09:25:06 rburton: nope I am trying to make and arguement to move off the old release, and the fact that dizzy is getting fixes for CVEs is helping my case. May 25 09:26:28 rburton: this might be a case of 'worse is better' :-p May 25 09:30:45 I would like to run yocto on ArchLinux and it sometimes works but sometimes the GCC version is too new. I have adittionally installed gcc-4.8 in my system but have no idea how to g et bitbake to use it May 25 09:34:06 Jeena: set BUILD_CC etc in your local.conf to point at gcc-4.8, just copy the values for BUILD_CC etc from bitbake.conf to local.conf and fiddle them as needed May 25 09:39:49 ah in the local conf? I had it as env variables May 25 09:51:33 * boucman_work is revert-engineering a product that uses yocto 1.6 :( May 25 09:52:05 but usually, there is no point in supporting such old releases... vendors that use them don't do any kind of update anyway May 25 10:05:54 so I execute e.g. "bitbake binutils". Just why would it try (and fail) to build gcc too?!?! May 25 10:06:25 it's just cluttering up the error messages with information for tasks I did not request -.- May 25 10:28:10 how do I purge the entire state of a package so that it is build from the beginning? May 25 10:28:55 -c cleansstate May 25 10:30:21 and how do I stop bitbake from attempting to continue build stuff of another unrelated package? May 25 10:32:14 JaMae: thanks, btw May 25 10:36:01 LeifSo: control-c? if bitbake is building it then its not unrelated, it's being rebuilt for a reason May 25 10:36:14 probably dependencies on the target and its doing the rebuilds for that May 25 10:37:04 rburton: that does not really make sense, as I want to build binutils, but bitbake tries to build gcc in parallel. May 25 10:40:53 also what's up with binutils. It seems to ignore any CFLAGS appended using .bbappend -.- May 25 10:42:08 I mean is it some sort of special package that is not influencable by appending? May 25 10:43:02 or is it some weird bitbake state that hinders the application of the cflags? May 25 11:05:18 am I right in thinking that it's still the case that yocto requires bash due to specific syntax used? May 25 11:05:54 CTtpollard: no, we've tried to remove every bit of bash from the recipes May 25 11:06:02 interesting :) May 25 11:07:06 sh can be bash or dash May 25 11:07:45 on the build host that is. May 25 11:09:44 and zsh I presume? May 25 11:09:48 apparently it's binutils-native vs. binutils. So appending anything to binutils does not apply it to generated binutils-native -.-' Same goes for e.g. gcc vs. gcc-cross-arm May 25 11:18:25 LeifSo: what is in your bbappend? May 25 11:38:50 jku: additional CFLAGS for Werror suppression May 25 11:40:22 jku: I had CFLAGS += "-Wno-error=unused-const-variable -Wno-shift-negative-value $CFLAGS" May 25 11:40:30 but they weren't used May 25 11:40:46 now I'm trying CFLAGS_FOR_BUILD += "-Wno-error=unused-const-variable -Wno-shift-negative-value $CFLAGS" May 25 11:42:14 should be BUILD_CFLAGS maybe? May 25 11:42:20 LeifSo: ^ May 25 11:42:37 iirc I tried that too May 25 11:43:15 jku: also: it does not make any sense to distinguish here. May 25 11:43:38 jku: BUILD_CFLAGS should be initialized with CFLAGS according to the docs May 25 11:43:41 but it isn't May 25 12:40:20 so I installed autoconf 2.64 along 2.69. It's first in my $PATH, but yocto prefers to keep failing because 2.69 -.- May 25 12:40:54 how do I tell it to use the autoconf version it desires? May 25 12:42:46 Hi guys. I have my own layer with my recipes and customizations. In my layer I have two images, one which is the "regular OS" that runs the product application, and one which is the "flash OS", a minimal ramdisk OS that flashes the disks. I want the two images to have different fstab files, what is the correct way to do that? I know how to handle machine / arch specific differences, but I don't think there's a way to " May 25 12:42:48 dress a package depending on the image it gets included in", right? May 25 12:45:28 another thing I'd like to customize among the two images is the inittab May 25 12:48:56 diego_r: I think you can overwrite files on a per-image basis (i.e out of the original recipe) but I am not sure how. wic can update fstab when building an image, but that won't solve your init problem May 25 12:50:34 LeifSo: yocto does not use host autoconf. If you really want to use 2.64, add a recipe and use PREFERRED_VERSION_autoconf-native... but probably the right option is to actually fix whatever is failing with the newer autoconf May 25 12:51:06 should I create a my own "IMAGE_FEATURE"? May 25 12:52:07 jku: I don't *want* to use 2.64. It's binutils-native (apparently a dependency of binutils) that simply fails in configure stage, complaining about missmatching autoconf versions May 25 12:52:27 one thing ahead: I'm using Arch May 25 12:52:45 boucman_work: Yeah, I know how to tweak my image while it is being created, but I don't want to add too much craft if there's a proper way May 25 12:55:08 right, if binutils-native fails to build, then the right thing to do is probably figure out why it's doing that, not to downgrade basic build tools May 25 12:56:35 jku: http://pastebin.com/Z3UC7N9K May 25 12:58:02 jku: so apparently that was because of ' BUILD_CFLAGS += "-Wno-error=unused-const-variable -Wno-shift-negative-value $CFLAGS"' in a .bbappend May 25 12:59:04 I have zero clue, why configure would fail when I set CFLAGS but, however, if I just set CFLAGS they're not respected either. May 25 12:59:26 but I need them because Arch's using gcc6 May 25 13:00:34 the $CFLAGS at the end is a false leftover from a different approach May 25 13:01:19 I figured that somebody wrote binutils so it won't pass CFLAGS to -native leaving me with a broken recipe May 25 13:04:57 LeifSo: oe-core master should be fine with gcc6 by the way, unless you're using a stable branch. install an older version of gcc and use that instead? May 25 13:07:37 rburton: I'll have a look, thanks May 25 13:07:59 LeifSo: just set BUILD_CC etc to point at the right compiler (see bitbake.conf) May 25 13:09:02 rburton: I tried to use linaro's external toolchain initially May 25 13:09:13 but that failed because of all sorts of broken RPMBUILDs :) May 25 13:09:29 e.g. linaro and arago chose to append -foobar all over the place May 25 13:09:40 to the PR May 25 13:09:55 which, in turn, was fead to rpmbuild May 25 13:10:44 after I fixed that, it would fail anyway, cause e.g. libc6-dev required libc6-r5.2-r5.2 (or similar) and nothing provided it May 25 13:13:43 rburton: thanks for the hint! indeed it's fixed :-O May 25 13:14:24 ask the proper question and the answer is obvious. the question is "what hoops do i need to go through to make arch work?" :) May 25 13:14:53 not use a patched gcc6 which appears to be more pedantic than the release is the answer :) May 25 13:15:07 (arch's gcc6 errors in places where nobody elses does) May 25 13:15:57 rburton: you're of course right. My frustration was just enourmous. Especially with bitbake. May 25 13:16:28 it would be nice if an arch user could maintain a wiki page of what tweaks need to happen to make current oe build on current arch May 25 13:16:33 rburton: I had the patches for gcc 6 in place too. May 25 13:16:42 afaik just using an older gcc is the best solution right now May 25 13:16:51 especially if you're using a stable oe and not master May 25 13:18:11 rburton: I'm just starting yocto. I'm keeping bbappend etc. around for stuff like gcc-version-specific patches/suppressions etc. May 25 13:18:43 I need to get to know yocto better so it won't be a nonsense-tutorial May 25 13:20:48 e.g. I still don't know the bitbake build magic. I.e. how do I stop it from building (or trying to build) other stuff until I fixed a package, without having to specify the exact task May 25 13:21:43 hello May 25 13:22:25 hi May 25 13:22:53 rburton: I'll hang around often, so I'll hopefully be able to help other Archers :) May 25 13:23:35 I'm build image for Rpi2 and stuck on gcc-runtime_5.3 linking with undefined reference to __dso_handle May 25 13:23:57 Can anyone give a tip how to resolve it May 25 13:29:56 glip which version of yocto May 25 13:29:58 ? May 25 13:30:23 krogoth latest from git May 25 16:55:39 whee, resize-helper works great with one tweak to the parted args, and after updating to current 96boards-tools. tested it on minnowmax last night with mel May 25 16:55:50 resized in seconds, no noticeable delay to first boot at all May 25 17:11:37 RP: since addtask can accept tasks with the do_ prefix, I'm thinking about doing a sed across oe-core to add the prefix for consistency. i.e. `addtask do_foo before do_bar after do_baz` rather than `addtask foo before do_bar after do_baz`. Normally i'm not a fan of that sort of blanket fixup, but I do think it'd be an improvement in consistency for folks reading hte metadata May 25 17:11:40 RP: thoughts? May 25 17:18:56 RP: also, do we have a better way to diagnose a taskhash base mismatch? could we write the siginfo for that and then compare the info if it changed in the worker via a diffsig-like-operation? May 25 17:50:37 is the official, definitive list of yocto compatible criteria https://www.yoctoproject.org/webform/yocto-project-compatible-registration ? May 25 19:03:36 Why does wic both rely on bootimg/HDDDIR for efi and duplicate it? It requires HDDDIR setup, but then re-constructs the grub-efi/gummiboot configuration. Either it should be independent of the old image creation, or it should use it as is. Right now it's somewhere in between May 25 19:04:06 wic is still awfully intertwined with the metadata. it's supposed to be a standalone tool, but it's not, really May 25 19:04:45 * kergoth ponders May 25 19:06:25 i was going to make gummiboot and grub-efi deploy startup.nsh themselves, but of course the recipes can't do that, they write to DEPLOY_DIR_IMAGE, while bootimg-efi in wic pulls from HDDDIR, not DEPLOY_DIR_IMAGE. guess i'll modify the classes instead May 25 19:07:21 i have a question that is slightly offtopic but i could image you folks know it anyways. i have a problem editing variables with long values in uboot (env edit somevar) May 25 19:07:31 i can edit the line May 25 19:08:05 but the characters get strangly overwritten May 25 19:08:14 (bad description, i know...) May 25 19:08:32 what i wanted to say is that line editing seems to be broken May 25 19:08:49 do i need to tell uboot the width of my terminal? May 25 19:08:53 or something like that? May 25 21:00:07 * rob_w applauds and bows to Jefro May 25 23:20:45 what's the target release date of 1.8.2 now? May 25 23:26:51 smurray: don't take this as authorative, May 25 23:27:12 but RSN. I believe it's in the approval cycle. May 25 23:28:02 okay, thanks. The list of bugs in the last QA email to the list was small, but there wasn't much followup. May 25 23:29:30 yes, last I heard there was nothing show stopping **** ENDING LOGGING AT Thu May 26 02:59:58 2016