**** BEGIN LOGGING AT Mon Mar 13 03:00:01 2017 Mar 13 07:46:32 good morning Mar 13 09:05:53 Hi all, someone could explain which branch should I use (for poky and meta-xilinx for example) please ? The latest ? Currently, I use the branch jethro, but is it better to use the latest ? What are the differences ? Mar 13 09:09:10 yohboy: For a new project, always start with the latest stable branch supported by your vendor. For meta-xilinx I assume this is morty. Latest branch will get bug fixes, older branches may not do depending on age Mar 13 09:12:36 paulbarker: thank you :) so why there is a lot of old branch ? is it because it's hard to switch when we have already completed our project ? Or can we switch on the new release easily ? Mar 13 09:18:37 yohboy: They're just old releases. See https://wiki.yoctoproject.org/wiki/Releases Mar 13 09:22:50 paulbarker: ok thank you :) Mar 13 09:38:26 Hello, do you know how to prevent yocto from auto-generating RPROVIDES from the .so he notices in the installed package ? Mar 13 09:38:42 I have tried SKIP_FILEDEPS = "1" but that doesn't do the trick unfortunately Mar 13 09:44:20 hi everyone Mar 13 09:44:41 I would like to know why a job is triggered Mar 13 09:45:42 aurele: you might want to be a little bit more specific Mar 13 09:48:20 I have a special fs type wich create an image for sdcard, but the image rootfs name (ext4) is using "DATETIME", the rootfs isn't generated but my script is called, and it can't find the rootfs with the new datetime, so my script fails, but if there is no modification with the rootfs, my script should not be called Mar 13 09:48:35 rburton, maybe it isn't so clear sry.... Mar 13 09:49:49 my fs type depends on an ext4 image generated, today at every build my fs type script seems to be triggered, but not the ext4... Mar 13 09:50:27 it seems strange to me and I would like to know why my fs type script is triggered while ext4 is not Mar 13 09:50:51 because it says DATETIME and so changes so bitbake wants to rerun it Mar 13 09:51:10 you need to add datetime to the vardeps exclusing list, grep meta/ for DATETIME and you'll find plenty of examples Mar 13 09:51:14 exclusion list, eevn Mar 13 09:51:20 argh fingers can't type today Mar 13 09:53:38 rburton, are they attached to a hand in one end? If not, then that might be the problem ;) Mar 13 10:01:12 mjourdan: have a read of package.bbclass for things like EXCLUDE_FROM_SHLIBS and PRIVATE_LIBS Mar 13 10:05:47 RP: gm. I see devshell/terminal has PATH again. Now what to do with some other small coreutils missing in HOSTTOOLS? Mar 13 10:07:10 I'd say at least we need all ex-textutils Mar 13 10:09:20 ant_work: we probably need to look at on a case by case basis once we have an idea of which ones we're missing and how commonly they're used Mar 13 10:09:32 ant_work: I'd prefer not to add a whole load of things which aren't commonly used Mar 13 10:10:03 sure Mar 13 10:12:41 rburton, thanks for the tips Mar 13 10:13:47 RP: it was discovered klibc/dash uses nl Mar 13 10:17:21 RP: it was pointed out it seems better to add nl to the HOSTTOOLS instead of adding a dependency on coreutils-native Mar 13 10:18:56 ant_work: for nl, probably Mar 13 10:19:20 the point khem found borderline is rebuilding coreutils-native Mar 13 10:19:58 but you're moving in the right direction: less tools = less pain in the future :) Mar 13 10:26:09 If we want to use both qemu and spcific archotecture, do we still need to build twice each time changine MACHINE ? Mar 13 10:26:44 ranchu: yes. Mar 13 10:27:02 LetoThe2nd - Thanks! Mar 13 10:32:12 rburton: posted a patch that should fix occasional wic test_exclude_path failures in AB, one can be seen here: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/843/steps/Running%20oe-selftest/logs/stdio Mar 13 10:45:13 hello Mar 13 10:45:32 i'm looking after the systemd v232 commit a1e2ef.... Mar 13 10:45:56 but my limited git knowledge prevents me from finding it :) Mar 13 10:46:29 i've tried master{,-next{2}} and krogoth Mar 13 10:46:38 anybody csan teach me how to find it? Mar 13 10:47:51 systemd v232-related, that is Mar 13 10:47:58 in poky/meta/recipes-core Mar 13 10:48:34 RP: morning. one more failure due to the PATH change: https://gist.github.com/bartosh/dac471be3fcf166f535c282ee9efe513 Mar 13 10:51:04 RP: after bitbake failed the PATH doesn't contain host's paths. Is it expected? Mar 13 10:51:53 oops Mar 13 10:51:55 sorry Mar 13 10:52:06 i am looking for the wrong commit :(\ Mar 13 10:57:15 mborzecki: great Mar 13 10:57:18 thanks Mar 13 11:45:55 is there a way to add all supported languages with IMAGE_LINGUAS variable? Mar 13 11:46:06 is it possible to use wildcars or something is similar? Mar 13 12:26:58 RP: thanks, will check it out Mar 13 12:27:33 x86_64-poky-linux-gcc: error: unrecognized command line option: '-V' Mar 13 12:27:56 while trying to compile systemd v232 in jethro Mar 13 12:28:20 anybody knows where is this comming from? do i need a newer gcc? Mar 13 12:46:36 RP: EXCLUDE_FROM_SHLIBS works great, and my packages don't provide any *actually* shared libs (only private to the package), so it's ok. Thanks! Mar 13 12:49:26 Isn't there PRIVATE_SOMETHINGLIBS for those use cases? Mar 13 12:50:03 "If you want to avoid a package being registered as providing a particular shared library (e.g. because the library is for internal use only), then add the library to PRIVATE_LIBS inside the package's recipe." Mar 13 12:50:20 See http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#automatically-added-runtime-dependencies Mar 13 12:50:49 From what I saw in package.bbclass, PRIVATE_LIBS is more like cherry picking while EXCLUDE_FROM_SHLIBS skips everything altogether. Mar 13 12:51:05 For my usecase, EXCLUDE_FROM_SHLIBS ended up being the easier solution since all the libs are private anyway. Mar 13 12:51:36 Oh, that explains it. If you never intend to ship shared libs in a package that'll work. Mar 13 13:58:45 kanavin: Exception: NotImplementedError: Adding remote dnf feeds not yet supported. Mar 13 13:58:59 kanavin: that should be just a matter of writing a plain file right? Mar 13 13:59:10 (first regression against rpm5 i spotted) Mar 13 14:00:34 rburton: that, and having a runtime test for it, for which I had filed a bug :) Mar 13 14:00:52 rburton: it does seem like I need to write the test myself in the end though, QA is unwilling Mar 13 14:01:05 kanavin: or perhaps unable Mar 13 14:01:40 RP: at least they did write a test for smart, so I can use that as a model Mar 13 14:02:04 kanavin: its essentially just "put these URLs on disk in the right place" Mar 13 14:05:01 rburton: yeah, but the test should also actually run dnf to fetch and installĀ a package using those feeds, and check that it actually happened Mar 13 14:05:40 without such a test, there's no way to verify that the file is correct! Mar 13 14:26:09 please, someone could explain me how to load the bitstream into my zybo by using tftp boot method ? u-boot boot from my SD card. Should I put the bitstream on my SD card too, or should I download it from the tftp server and load it manually ? Mar 13 14:59:49 yohboy: the fpga load command is what you are after. tftpboot or load mmc to get the bitstream into memory Mar 13 15:05:55 nrossi: thank you, it's now working with tftp server :) next step is to boot kernel and fpga without usb cable ! I'll try to use netconsole as you suggest some day ago Mar 13 16:11:05 nrossi: is netconsole enable by default for uboot ? Mar 13 16:11:33 yohboy: there is no 'default' in u-boot, for zynq boards i suspect not Mar 13 16:13:13 nrossi: ok, make sense Mar 13 18:52:06 hi all. How can i, in a .bbappend, disable initscript installation (in a clean way) ? Mar 13 18:52:27 i tried to overriding INITSCRIPT_NAME = "" and INITSCRIPT_PARAMS = "" Mar 13 18:52:44 but it makes build fail while update-rc.d call because of invalid argument Mar 13 19:03:35 you can't disable it in a bbappend directly.. Mar 13 19:04:30 you can indirectly disabled it by setting INITSCRIPT_NAME = "", and setting: updatercd_postinst() { : } and updatercd_prerm() { : } and updatercd_postrm() { : } (I think) Mar 13 19:04:54 the problem is that system, when included, unconditionally enables various pre/post package install steps.. so you have to manually remove them Mar 13 19:05:12 you MIGHT have to do the same to: populate_packages_updatercd Mar 13 19:05:24 python populate_packages_updatercd() { } Mar 13 20:08:47 perhaps deleting the initscripts in a do_install_append along with this would not need the packaging tweaks Mar 13 20:41:45 halstead: just a quick note for you or anyone else with ability to configure git.yoctoproject.org - meta-gplv2 is still at the top of the page outside any category, it probably wants moving into the "Yocto Metadata Layers" when someone has spare time Mar 13 20:49:11 paulbarker, I'll move that. Mar 13 20:49:39 cheers Mar 13 20:50:27 paulbarker, Moved. Can you suggest a a description while we're at it? Mar 13 20:52:34 halstead: Old, obsolete versions of software where upstream has moved to GPLv3 licenses Mar 13 20:52:41 (paraphrasing the readme file there) Mar 13 20:53:57 paulbarker, Thank you. I've softened that to, "GPLv2 versions of software where upstream has moved to GPLv3 licenses" and added it. Mar 13 20:54:08 yea, that sounds better Mar 13 20:54:21 thanks! Mar 13 20:55:50 paulbarker: halstead: thanks ! Mar 13 21:20:30 Hey i create with yocto a rootfs and mount it with nfs on the client. After the use some file permissions change to root. This makes it impossible to delete as normal user the rootfs. Is there any workaround, so i can delete the filesystem as normal user? Mar 13 22:49:48 is there an easy way to enable the gcc libiberty plugin? Mar 13 22:50:10 kernel gcc entropy plugin needs it... Mar 13 22:50:20 khem: ^^ Mar 13 22:50:55 i tried a gcc-cross_append to install it but it didn't help Mar 13 22:52:47 I thought the userspace "plugin" to kernel entropy was /dev/random .... Mar 13 22:53:56 Given that I try to avoid user space, I'm probably not clued up on what crimes live out there beyond The Wall. ;-) Mar 13 22:55:09 it's one of those patches plucked from grsec/pax Mar 13 22:55:17 already in mainline Mar 13 22:55:27 * nerdboy building 4.10 kernel Mar 13 22:56:03 mainline commit ID? Mar 13 22:56:21 outside bitbake it works fine, inside they rm -rf the libiberty stuff from gcc install and use binutils Mar 13 22:56:55 kernel plugin wants to find it in gcc/plugins/inlcude dir i think Mar 13 22:56:55 that sounds like configure going off in two different directions. Mar 13 22:57:13 two different bitbake packages Mar 13 22:57:25 3 if you count the kernel Mar 13 22:58:41 still smells like configure dain bramage ; not finding what it expects from the kernel and falling back on some lib emulation Mar 13 22:59:14 kernel build just barfs with "gcc/arm-oe-linux-gnueabi/6.2.0/plugin/include/system.h:685:23: fatal error: libiberty.h: No such file or directory" Mar 13 22:59:46 no the kernel is looking in the place it expects it to be Mar 13 23:00:02 *technically the "right place" Mar 13 23:00:42 ah, ok -- that is different. I build arm and arm64 almost daily. you have a local.conf and bblayers.conf you can share? Mar 13 23:02:06 CONFIG_GCC_PLUGIN_LATENT_ENTROPY <= config option Mar 13 23:02:27 all you need to do is build newer mainline on morty Mar 13 23:02:53 * nerdboy disables it to work on mesa/drm Mar 13 23:04:04 well, being from the kernel side of things, I build everything on master. Never bothered with any of the code-name branches, since I've NFI what they map to. :) Mar 13 23:04:48 master is new enough Mar 13 23:05:50 recipe on github => https://github.com/sarnold/meta-small-arm-extra/tree/morty/recipes-kernel/linux Mar 13 23:06:15 let me do a devshell and enable that and see what catches fire. arm32? or arm64? Mar 13 23:06:29 fsl arm32 Mar 13 23:06:29 looks like you are arm32. Mar 13 23:06:33 ok Mar 13 23:07:15 nitrogen is just imx6q Mar 13 23:08:26 * nerdboy should make a new gentoo image for that... Mar 13 23:08:27 and all this time I thought it was 80% of our air. Mar 13 23:08:50 +1 for you Mar 13 23:09:24 most people don't even know it's a gaseous mixture... Mar 13 23:10:32 paulg probably doesn't know he's talking to a meteorologist ;) Mar 13 23:10:42 with apparent molecular weight and everything! Mar 13 23:11:54 * nerdboy probably knows too much about solution series and mixture combining rules and stuff... Mar 13 23:15:02 nerdboy: --enable-libiberty Mar 13 23:15:10 do you have this ? Mar 13 23:22:18 i did but it borked the install Mar 13 23:23:24 i should get an image shortly (or a barf) and then i'll try it again Mar 13 23:23:32 *shortly Mar 13 23:24:30 * nerdboy needs new reddin' glasses after losing them on the airplane... Mar 13 23:26:11 khem: actually i had "--enable-install-libiberty" Mar 13 23:29:37 also gcc-cross.inc has this in do_install: Mar 13 23:29:40 find ${D}${exec_prefix}/lib -name libiberty.h | xargs rm -f Mar 13 23:29:59 which would remove the plugin header Mar 13 23:30:42 libiberty isn't a plugin AFAIK.. it's just a library of common GNU utiliteis.. Mar 13 23:30:48 it's provided in OE by bintuils, not GCC Mar 13 23:30:53 (even though GCC knows how to build it) Mar 13 23:31:16 (it's rm'd so no conflict can occur, as binutils is supposed to be the definitive source) Mar 13 23:31:32 and the kernel looks for a local libiberty.h header in plugins/include Mar 13 23:31:49 that sounds like broken behavior Mar 13 23:33:00 actually it looks for include/system.h which has the libiberty include Mar 13 23:33:17 *plugin/include/system.h Mar 13 23:33:53 I just looked.. It looks like there is a libiberty.h is the plugin dir... It's possible that with that type of change, the .h should only be removed from the -actual- include dirs.. Mar 13 23:35:22 gcc uses its own version of libiberty what you are talking about is a system wide libiberty which is provided by binutils in OE Mar 13 23:35:49 if its not finding the internal header that means include paths are somehow messing up Mar 13 23:36:04 (or the rm he posted is firing) ;) Mar 13 23:36:30 also gcc-cross.inc has this in do_install: Mar 13 23:36:30 find ${D}${exec_prefix}/lib -name libiberty.h | xargs rm -f Mar 13 23:37:24 it could, if plugins are being built say using gcc-runtime package Mar 13 23:37:37 then we need to ensure that we do not delete it for that case Mar 13 23:50:32 * paulg reads Mar 13 23:50:57 * paulg assumes he need not wait on his arm32 devshell any longer Mar 13 23:51:50 * nerdboy testing a quick "fix" Mar 13 23:51:57 grep is your friend... Mar 13 23:52:08 or grep -v in this case Mar 13 23:52:56 I think yocto/oe will get a carbon tax for the number of times it rebuilds the toolchain because someone fixes a spelling mistake in stdio.h or similar. Mar 13 23:53:24 well, perhaps not under the current administration.... Mar 13 23:56:04 mesa barfed on my gallium config Mar 13 23:56:19 *I think it's what i need now... Mar 13 23:57:20 ubuntu test with 4.10/etnviv works nicely, all i want to do is build something "equivalent"-ish... Mar 13 23:57:29 nitrogen and then gallium. Sensing a periodic table theme here.... Mar 13 23:58:12 just wait until i throw in the americium... Mar 13 23:58:48 sorry, radioactive decay elements are not allowed on IRC. Mar 13 23:58:53 and some molybdenum because it's fun to say... Mar 13 23:59:36 that one you can probably smuggle in as CV joint grease. Mar 14 00:22:04 nerdboy, so my beaglebone ARM32 build shows that Kconfig in the source, but presumably for dependency resaons, it isn't even offered as available in the .config Mar 14 00:43:03 the most common domestic use for americium is of course in smoke detectors... I hope you don't need one of those as part of your build ;) Mar 14 00:46:45 my builds at home are on a 5+ year old xeon rescued from recycle ; it might need a smoke detector fitted inside the case. :) Mar 14 00:50:45 needless to say, it won't be running once the outside temps in Ottawa break double digits. :) Mar 14 00:51:46 (double digits on the positive side of zero, of course.) Mar 14 00:53:09 we are currently on the wrong side of that zero metric. Mar 14 00:53:15 https://weather.gc.ca/city/pages/on-118_metric_e.html Mar 14 01:23:51 82F here **** ENDING LOGGING AT Tue Mar 14 03:00:02 2017