**** BEGIN LOGGING AT Tue May 29 03:00:04 2018 May 29 06:18:44 hello, how do I find out what component (recipe) provides the /sbin/runlevel binary for my Yocto-generated rootfs? I do not have the ability to use package management on target and run something like opkg search. May 29 06:19:18 I need to get this information by using tools on my development host May 29 06:22:35 eduardas_m: have you tried using oe-pkgdata-util? oe-pkgdata-util find-path May 29 06:56:43 <__MC__> hi, I need help to load an image created with yocto on an imx28evk board. The problem is that yocto creates 2 partitions, a FAT and an EXT with rootfs, but the imx28 wants 3 partitions, FAT - OnTrack DM6 Aux3 - Linux. I've already created a bootable sd with these partitions using LTIB, and I was thinking of loading uboot and the kernel with dd on these partitions, but the board does not start. Is there any expert who can advise me (eve May 29 07:34:14 __MC__: why your MX28 wants 3 partitions? May 29 07:39:01 <__MC__> because the boot procedure of this processor requires it May 29 08:29:59 __MC__: i didn't have that when I used it May 29 08:31:56 <__MC__> mckoan: were you able to start a system generated with yocto on an imx28evk? May 29 08:38:25 __MC__: many of us did in the past. Nowadays i.MX28 isn't used that much, but it is still supported using mainline kernel May 29 08:43:30 __MC__: yes I did some years ago May 29 08:43:34 <__MC__> diego_r: I'm able to use it only with ltib, but all the programs in rootfs are very old. I need to upgrade some program like openssl, python.. What's the best way to achieve this? I've to use yocto? What do you mean with mainline kernel? It is supported in vanilla kernel? Can I use a distro like debian with an imx28evk ?? May 29 08:46:26 <__MC__> mckoan: can you give me some hint? I've made the minimum-image. I've tried to upload the image to sdcart with wic, but the board won't boot up. May 29 08:47:52 __MC__: maybe read up on the boot setting that the soc provides. often there is more than one. May 29 08:52:41 __MC__: there are prebuilt images at this page: http://freescale.github.io/ , look for "NXP Semiconductors - i.MX 28 Evaluation Kit". If those images don't work too, then you need to understart boot settings and boot process of your board (page 9 of https://www.nxp.com/docs/en/user-guide/IMX28EVKHUG.pdf ) May 29 08:52:55 *understand May 29 08:54:04 and yes, support for i.MX2 is in mainline, no need to keep 2.6.35 security issues hanging around. May 29 08:58:40 <__MC__> diego_r: Thanks for the link, I immediately try the sample image. May 29 08:59:50 <__MC__> diego_r: As support in the mainline, would it be possible to use a debian-like distro? May 29 09:00:08 __MC__: that image has been surely tested, so if that doesn't boot, you need to sort out boot priority May 29 09:02:55 __MC__: the problem with i.MX28 is it's not even ARMv7, so packages should be built for its ARMv5 architecture. Armbian is built for ARMv7 at least, and I don't know of other distros built for ARMv5 nowadays. https://docs.armbian.com/ May 29 09:07:52 <__MC__> diego_r: ok, now it's clear to me, thanks for the explanation May 29 10:17:58 <__MC__> diego_r: I have loaded the sample image. diego_r, thanks for the link, I had missed it. Now I should be able to make and load my kernel made with bitbake and my rootfs. And Also i will study the partiton table.. It has a 1MB partition thath was missing in my .wic file. May 29 10:21:08 __MC__: you're welcome. This will get you started. May 29 10:27:15 Hi, folks! May 29 10:28:08 I've generated image with Yocto and run it on QEMU, but my FS is read only. May 29 10:30:21 I've used the following command to run image in qemu: May 29 10:30:29 sudo tmp-glibc/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-mipsel -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp-glibc/deploy/images/qemumips32r6el/example-image-cgl-qemumips32r6el.ext4,format=raw -vga cirrus -show-cursor -machine malta -cpu mips32r6-generic -m 256 -serial mon:vc -serial null -kernel May 29 10:30:30 tmp-glibc/deploy/images/qemumips32r6el/vmlinux-qemumips32r6el.bin -append 'root=/dev/sda rw highres=off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 console=ttyS0 console=tty ' May 29 10:32:07 what should I do to make FS rewritable? May 29 10:33:06 astrunin[m]: well is it that the rootfs is readonly by force in someway, or is it just that its mounted read-only? May 29 10:33:25 astrunin[m]: like, inside qemu, can you do mount -o rw,remount / May 29 11:10:46 hi May 29 12:14:03 Is there anyone here with knowledge of bb's fetch2? May 29 12:14:41 Is there anyone who knows what a meta-question is? May 29 12:14:46 Just ask your question. May 29 12:16:35 I'm digging into the hg fetcher to try to fix it, but I cannot comprehend how the branch is selected. AFAIK it seems the hg fetcher ignores the branch, but I might be misreading the code May 29 12:18:55 I think hg fetcher isn't used that much, it will be much less tested than e.g. git fetcher May 29 12:19:11 I have 1-2 recipes using hf fetcher in all the layers I'm testing May 29 12:19:44 JaMa: yes, that's true, given the bugs in it May 29 12:20:17 sveinse: It seems it only passes -r $revision on update, no branch May 29 12:20:33 not even that, no recipe using hg.. the 2 I was thinking about were bzr May 29 12:21:17 neverpanic: It does. So that is what I'll be adding. But then I noticed that the ud.parm['branch'] is never read from the SRC_URI... May 29 12:22:00 Yeah, it seems it just expects you to specify the revision and there is no branch support. May 29 12:23:28 There are two bugs: The first is the ${AUTOREV} does not work and the second is that when you fix the first, it will check for the latest revision. But in hg the latest revision is global and not per-branch, so youĂ uight end up checking out the repo from another branch (then one which happens to be the last commit) May 29 12:23:45 But I think I have a patch for them May 29 12:27:12 I think branch in SRC_URI was mostly for fetch optimization from the the beginning? not actually selecting the revision May 29 12:27:54 ernstp: unless ${AUTOREV}, right? May 29 12:28:14 sveinse: yeah, that's kindof tacked ontop? May 29 12:30:26 ernstp: I don't know. But we're relying heavily on it. Use the latest version of the repos, but ensure the built artifacts are properly traceable via setting PV using ${SRCPV} May 29 12:36:22 With regards to that: Is is correct that BRANCH_pn-${PN} does not work any more for overriding branch for a recipe? It used to work, right? May 29 12:37:24 sveinse: it works only for the recipes which pass branch=${BRANCH} in their SRC_URI May 29 12:37:43 Is is possible to override certain attributes of an SRC_URI element, such as "branch=something;", from local.conf? May 29 12:37:54 JaMa: Aha, by setting branch=${BRANCH}. Right May 29 12:38:25 SRC_URI_append_pn-foo = ";branch=foo" May 29 12:38:52 work only for recipes with only one item in SRC_URI May 29 12:39:27 you can still use inline python to replace something in the VCS entry of the SRC_URI.. May 29 12:41:41 JaMa: yeah, it's a part of having a central CM on top of Yocto, where some of the most changing repos gets selected and pinned May 29 12:43:46 hello May 29 12:43:56 how do i tell a recipe to not build man pages? May 29 12:44:04 google did not help much with this May 29 12:45:41 btw, JaMa, how come Qt5 apps on (freescale) arm seems to have a different tune than non-Qt apps do? E.g. cortexa9hf-neon-mx6qdl-oe-linux-gnueabi vs cortexa9hf-neon-oe-linux-gnueabi/ May 29 12:48:03 sveinse: I don't use freescale for anything now, but IIRC they are using the MACHINE_CLASS to configure qtbase (and everything which depends on it) differently for each class May 29 12:49:13 JaMa: thanks May 29 13:21:13 Yeah! I think I found a workable patch to bb fetch2 for hg May 29 13:23:20 Hi, I'm using Recipe-Space Kernel Features as described in https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#adding-recipe-space-kernel-features. The issue I'm now facing is that if I change the test.cfg file the changes are not noticed by bitbake and it takes the kernel from sstate instead of rebuilding it. Is this a known limitation or do I need to do something in addition to make bitbake pick up the May 29 13:23:21 change? May 29 16:36:01 Hey all. I'm attempting to build core-image-full-cmdline with cups installed. I've added 'IMAGE_INSTALL += " cups"' to an append file. I've noticed that many (if not most) of my files have a owner/group of 1000 instead of root. Normally this wouldn't bother me, but cups needs the directories located in /usr/lib/cups/ to have root ownership to work. Can anyone shed some light on why the directory ownership is incorrect? I'm using rocko 2.4.2 and May 29 16:36:02 cups_2.2.4.bb. May 29 16:51:25 JOIN May 29 16:51:52 help : Hello, I have the source code were the part of the code kept inside the #ifdef SOME_MACRO and what would be the correct place to define SOME_MACRO this macro? note: This define is specific to the recipe. Regrds, Ugesh May 29 16:56:33 That's an aggressivly short -ETIMEDOUT May 29 16:59:11 @ugesh : If I understand you correctly, you want to control whether or not a c-preprocessor macro is set from the recipe. If you are using g++ then you want to add -Dcpp_variable=VALUE or just -Dcpp_variable to it's invokation. If you are using make, then you can trigger that by setting a make variable on the command line "make target FOO=bar" May 29 16:59:41 kevint: Looks like ugesh left 2 minutes after asking their question :( May 29 17:00:07 kevint: I see where the cups recipe is using USERADD_PACKAGES -- not sure what the rationale is there if that root priv requirement exists May 29 17:04:07 kevint: So what are the perms exactly? It looks like cups.inc uses GROUPADD_PARAM_${PN} to specify an lpadmin group... but I don't see a USERADD_PARAM_${PN} that would change user ownership. (Perhaps I'm forgetting something about the useradd class?) May 29 17:08:00 The permissions are 755 1000 1000. I'm not entirely sure if it is a cups recipe problem because most of the files/directories on my system also have 1000/1000 as the user/group. May 29 17:13:00 kevint: Just a quick sanity check - are you viewing the perms on a device, or have you extracted the image contents to your dev machine? (Just curious if you might have lost the image perms, in the latter case) May 29 17:13:32 I'm viewing them on the device. May 29 17:15:52 Hrm... if that's the case, perhaps the scope of the issue can be narrowed a bit to rule out cups? For instance, if you were to boot a core-image-minimal image, would you see the same system files with the permissions issues? May 29 17:16:17 jynik: I'll give it a go, thanks May 29 17:17:08 kevint: What's your process for deploying the image on the platform? For some reason I'm stuck on thinking that 1000 somehow corresponds to your UID on your dev machine... May 29 17:21:03 jynik: I use "wic create" and then dd the resulting image May 29 17:21:50 jynik: It probably is some kind of host contamination but I don't know how I'm getting that May 29 17:30:09 jynik: I deployed core-image-minimal and still have the 1000/1000 permissions May 29 17:31:49 Well, that's good that you're able to reproduce it on a simpler image. :) May 29 17:36:03 Not sure exactly where to go from here... maybe pick a simple recipe like init-ifupdown and see if you can glean some more info from its logs in tmp/work? May 29 17:36:56 Just trying to think where you could identify the discrepency between the packages intended perms and the point at which it gets staged in an image... May 29 17:37:15 Might be a silly question, but what type of filesystem are you running the build on? May 29 17:37:38 Nothing crazy like fat32 or some network mount, right? May 29 17:39:23 No it's just ext4 May 29 17:44:18 I'm going to remove my custom layer and see if that fixes it. May 29 17:44:44 Good idea - peeling those layers of the onion. :) May 29 17:45:02 Always like ruling things out one by one. May 29 19:07:24 I'm looking for some official project documentation that makes it clear that Poky is *only* intended to serve as a reference. I see a couple notes to this effect in [1], but am wondering if I'm overlooking something that elaborates on this a bit more. May 29 19:07:29 [1] https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#reference-embedded-distribution May 29 19:11:24 Any thoughts/links welcome. Think along the lines of the type of info that one would want to show to project leads to argue that it's worth the time investment to not ship poky in production firmware. ;) May 29 19:23:21 hmmm May 29 19:23:47 if you edit poky.conf, it stops being poky May 29 19:27:30 jynik: here's roughly the same info in a single official project page instead of buried in a manual - https://www.yoctoproject.org/software-overview/reference-distribution/ May 29 19:28:44 Thanks. I guess the questions I'm probably trying to ask are, "What makes Poky not product-ready? What should a team be considering when migrating to their own distro conf?" May 29 19:31:04 From my perspective, it's mostly a "You ship it, you need to own it." mentality, along with trimming any fat (e.g. excess DISTRO_FEATURES). Just wanted some experts' takes on this. May 29 19:33:42 *own - as in take resonsibility for May 29 20:20:14 khem: not sure where ross got these patches from but the qemuppc spe one isn't going to work due to the shared gcc for each arch :( May 29 23:43:42 is there a recommended layout for layers? Generating the extended SDK failed because I have layers/meta/meta in my setup May 30 02:54:53 Anyone else seeing qemu-native builds failing on sumo or sumo-next due to a failure to find capstone.h? May 30 02:58:10 According to q **** ENDING LOGGING AT Wed May 30 03:00:02 2018