**** BEGIN LOGGING AT Tue Sep 17 03:01:14 2019 Sep 17 05:21:42 I'm still struggling with my initramfs image. I (think) I have managed to load the kernel+initramfs+dtb from sdcard into RAM, but when I boot the kernel I eventually get the message: root '' doesn't exist or does not contain a /dev Sep 17 05:22:06 Looking at the generated cpio.gz of the root filesystem, there certainly is a /dev there with a console node. Sep 17 05:23:25 iceaway, which yocto version are you on ? Sep 17 05:23:34 I'm using 2.5 Sep 17 05:26:37 iceaway, maybe its not related, but i remember fixing a missing console device in an initramfs with https://github.com/openembedded/openembedded-core/commit/490d6fbd14805b6c72b525fbe8c9c6e08d796597 Sep 17 05:27:29 but that doesn't like your error message Sep 17 05:29:45 but "root ''" looks like the kernel is being passed an empty root string, no ? Sep 17 05:31:55 Yes, I thought that was the recommended approach when using a "bundled" initramfs, no? Sep 17 05:35:25 iceaway, not sure about that Sep 17 05:36:04 iceaway, maybe try: root=/dev/ram0 Sep 17 05:36:21 iceaway, from https://www.kernel.org/doc/html/latest/admin-guide/initrd.html Sep 17 05:42:08 or maybe im confusing initrd with initramfs here Sep 17 05:47:56 I think so, I think the kernel knows that it has the built-in initramfs and thus does not need the root= parameter Sep 17 06:42:47 iceaway: AFAIR, yes. It's even "worse", if there is a bundled initramfs, the root= is ignored IIRC Sep 17 06:48:49 qschulz: so for some reason it seems that the kernel does not recognize the bundled initramfs. From what I could figure out i should see a "uncompressing initramfs" message somethere during the boot. Sep 17 06:51:27 iceaway: is it possible for you to test it manually? take the .cpio of your initramfs and give it to the kernel at compilation time? (I mean, compiling the kernel outside of Yocto) that way you know if it's the initramfs (cpio) which is bad or the current implementation of initramfs bundliung in your Yocto Sep 17 06:53:55 iceaway: maybe you can give the bootlog? I think the kernel supports multiple types of compression but they might not be all enabled by default, so if you're trying a cpio.gz and it's not supported in the kernel you're building.. well it's not going to work Sep 17 06:54:40 qschulz: I suppose that would be possible, just need to look into how to do that. I have checked my kernel config, and all initramfs/initrd compression options are enabled. Sep 17 06:56:36 bootlog: https://pastebin.com/M3Jap8Dd Sep 17 06:58:04 (Maybe) strange that it says freeing unused kernel memory (20032K), that should be the initramfs Sep 17 06:58:24 New news from stackoverflow: Yocto xfce image on jetson nano camera test: No element "nvarguscamerasrc" Sep 17 07:01:05 iceaway: interesting! I don't want to mislead you but I think it's actually loading the initramfs? I don't think `udevd[223]: starting eudev-3.2.5` is part of the kernel Sep 17 07:02:06 iceaway: I would check what you're initramfs is supposed to do. A few systems actually boot an initramfs by default and from there loads a rootfs from another medium. So it might be trying to find where the rootfs to switch to is, but there is none. Sep 17 07:22:50 qschulz: definitely worth looking into, will do that in a bit. Still all new to working with initramfs stuff. Sep 17 07:24:35 Hi, does bitbake automatically extract a .tar.gz file if that's my source? Can/should I stop that? Sep 17 07:27:16 I want to include third-party software provided to us as an archive and not worry too much about its internal structure. Can I manually extract that tar.gz? Sep 17 07:29:37 jmiehe: have you looked up the corresponding fetcher documentation in the bitbake manual? should be mentioned there, me guesses. Sep 17 07:34:03 LetoThe2nd: in https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#local-file-fetcher, there's the sentence "If you specify a directory, the entire directory is unpacked." Sep 17 07:34:46 jmiehe: scroll up a litt,e find https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack Sep 17 07:34:54 jmiehe: i think it explains exactly what you want Sep 17 07:35:21 I found that the second I posted the previous link^^ Sep 17 07:35:36 :-) Sep 17 07:38:42 tl;dr specify as file://SOMETHING.tar.gz;unpack=0 **** BEGIN LOGGING AT Tue Sep 17 08:08:12 2019 Sep 17 08:29:49 Is there a more bitbakey-way of changing an RPATH than just calling patchelf (or chrpath)? Sep 17 08:47:03 I need to add a file (a startup script) to my image, so there is to real source code or remote repo involed. Would the recommnded approach be to create a recipe that simply copies the file from the recipe directory to the target? Sep 17 08:48:39 iceaway: startup scripts are often just added to the layers directly, unless they correlate with a bigger application which they actually start up Sep 17 08:53:31 LetoThe2nd saw the video from yesterday's live coding. Do you need help in a writeup of the all the episodes? The writeup could include all the steps you performed in the videos (minus the mistakes) for a future reference. Sep 17 08:55:06 shan1: if you want to do a write up / summary /whatever, it will certainly be appreciated, I'm sure we can forward it to the right people for it to reach a wider audience. yet, i do not intend to make such. Sep 17 08:56:02 LetoThe2nd: how do you mean added to the layer directly? How would I add it to the image ? Sep 17 08:56:36 iceaway: its three things. 1) a recipe, for example fantastic_start.bb Sep 17 08:57:02 2) the actual script, located in fantastic_start/realscript right next to the recipe Sep 17 08:57:10 I can try squeezing some time for e.g. Video#1 and find out some nuggets and then write them up. Will let you in on a fdraft Sep 17 08:57:23 3) the image has IMAGE_INSTALL += "fantastic_startup" Sep 17 08:57:36 erm, "fantastic_start", of course Sep 17 08:57:43 shan1: :-) Sep 17 08:58:12 shan1: as i said, i can maybe find some time for review and comments, but will not do actual writing. Sep 17 08:58:43 New news from stackoverflow: Same build/source code for multiple machines in Yocto Sep 17 08:58:52 LetoThe2nd You don't have to. I can take that part. Sep 17 09:00:10 LetoThe2nd: ok sounds good, I will give that a go! Thanks! Sep 17 09:28:47 New news from stackoverflow: No ethernet access on jetson nano with custom yocto image Sep 17 09:37:52 kergoth: the web site is failing to actually explain why git-revise is better than rebase Sep 17 09:38:58 rburton: NOTHING IS BETTER THAN GIt REBASE! Sep 17 09:39:09 * LetoThe2nd puts hands on ears and starts singing LALALALALALA Sep 17 09:39:16 well revise is rebase but less poking at the disk, so its faster Sep 17 09:39:22 LALALALALALAAAAAA Sep 17 09:39:38 LetoThe2nd: "git rebase -i" is better than "git rebase" Sep 17 09:40:24 that counts as git rebase :) Sep 17 09:40:26 though 'A successful git revise will add a single entry to the reflog, allowing it to be undone with git reset @{1}. Unsuccessful git revise commands will leave your repository largely unmodified.' is a killer feature on its own Sep 17 09:42:03 diego_r: git rebase -i --autosquash is the dream :) Sep 17 09:43:09 rburton: DONT CONFUSE ME WITH FACTS! Sep 17 09:44:01 qschulz: :) Sep 17 10:26:41 Hi! I'm still wondering why I can't manage to install my own systemd service via Yocto .bb file. That bitbake does install the files at the right directories but my new systemd service is not enabled on reboot of my yocto Linux. Sep 17 10:28:11 I found out "systemctl enable start-firmware.service" actually just creates a symlink from /lib/systemd/system/start-firmware.service to a subdir called /lib/systemd/system/multi-user.targets.wants. Sep 17 10:28:51 Now I wanted to do that by myself in the start-firmware.bb do_install() section by adding there the following line: Sep 17 10:29:36 fbre: stupid as it may sound, you do not tinker with SYSTEMD_AUTO_ENABLE? and set SYSTEMD_SERVICE as well as SYSTEMD_PACKAGES accordingly? Sep 17 10:29:43 fbre: see also https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/systemd.bbclass#n9 Sep 17 10:30:09 ln -sfr ${D}${systemd_system_unitdir}/multi-user.targets.wants/start-firmware.service ${D}${systemd_system_unitdir}/start-firmware.service Sep 17 10:31:18 fbre: see http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/cronie/cronie_1.5.4.bb for an example of a rather simple recipe that perfectly works with systemd auto-enabled Sep 17 10:31:26 But adding this symlink creation to do_install() leads to an bitbake error "start-firmware-1.0-r0 do_package: SYSTEMD_SERVICE_start-firmware value start-firmware.service does not exist Sep 17 10:32:31 LetoThe2nd: systemd.bbclass contains a line: SYSTEMD_AUTO_ENABLE ??= "enable". So it should be enabled by default. Sep 17 10:33:14 fbre: i don't know what you're doing, so its hard to tell. i can only say that the cronie recipe does exac6tly what you wnt, so try reproducing it step by step Sep 17 10:33:30 LetoThe2nd: my start-firmware.bb file has also a line SYSTEMD_AUTO_ENABLE_${PN} = "enable" Sep 17 10:34:12 I can upload my .bb file to pastebin if that helps Sep 17 10:34:47 fbre: oh, and please note the little magic snippet in cronie's do_install that seds the service files. its needed. Sep 17 10:34:57 so really, try and reproduce starting from that. Sep 17 10:35:26 LetoThe2nd: OK, where is cronie located in the file tree? Sep 17 10:35:58 LetoThe2nd: Should I just search for a file called "cronie"? Sep 17 10:38:45 fbre: *sigh* scroll up. read again Sep 17 10:48:35 fbre: just checking: you know that file you're expecting to exist should be created at install time, not package build time. Sep 17 10:49:38 the postinst should be creating it when installed, be it on target or at rootfs time. it won't be in the package. Sep 17 10:58:46 rburton: yes, I know. At install time. Sep 17 10:59:39 LetoThe2nd: Ah OK, now I checked your links and see that cronie. Reading trough it now... Sep 17 11:01:24 fbre: can you replicate the problem with a minimal recipe? Sep 17 11:10:09 This initramfs-thing is driving me nuts. What I am trying to do is to run a tiny image live from RAM, but everything seems to be centered around mounting the "real" rootfs as the initramfs is loaded. Am I missing something? I am basing my image on core-image-minimal-initramfs, and all the "startup scripts" try to mount another root filesystem. To get rid of those scripts I have to remove all the Sep 17 11:10:15 initramfs-* packages, so that ultimately I cannot even build the image. Sep 17 11:11:27 iceaway: what is the rationale/usecase behind it anyways? Sep 17 11:11:51 iceaway: it might very well be a "i want to do x, and think that initramfs is the way archieve it" case Sep 17 11:11:52 rburton: yes, my start-firmware.bb is actually already a trivial one. So does the start-firmware.service file (IMHO) Sep 17 11:12:35 LetoThe2nd: I want to run the swupdate utility from RAM, so I can upgrade the firmware/software (even the swupdate part if required). Sep 17 11:13:00 iceaway: the core-image-minimal-initramfs is designed to boot real file system, yes. what's the difference between an initramfs and a 'real' file system though, apart from the type of file system Sep 17 11:13:01 iceaway: but that can be done way simpler Sep 17 11:13:08 the important bit is setting IMAGE_FSTYPES Sep 17 11:13:22 iceaway: just make an initrd and glue it up Sep 17 11:14:03 LetoThe2nd: you make it sound so simple :) Sep 17 11:14:07 iceaway: the complications of initramfs and all are not worth the headaches if the only thing you want to do is "run x from ram" Sep 17 11:15:03 if you're on arm, you can totally glue up kernel + dtb + initrd into a fit image, and tell u-boot to use that. done. Sep 17 11:15:18 LetoThe2nd: I'm definitely starting to see that now. I tried making an initrd, but failed when u-boot complained about the initrd format. Can I generate an initrd from within Yocto, in a similar way that it build my initramfs? Sep 17 11:15:45 iceaway: an initrd is just a standard filesystem, basically Sep 17 11:16:11 and see, here's even fit-image support ready to use: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-fitimage.bbclass Sep 17 11:16:47 everybody seems to love initramfs there days, but in my opinion they only serve a very specific usecase. Sep 17 11:17:01 So I could in theory just use the filesystem that Yocto already generates? Sep 17 11:17:20 precisely the point Sep 17 11:17:28 iceaway: bingo. thats what we do. Sep 17 11:17:47 Cool. Would I need to put it in some kind of initrd-container ? Sep 17 11:17:56 scroll up, read again. Sep 17 11:18:22 rburton: can you put a mark on the XY-question list? Sep 17 11:18:24 Will do. Thanks a lot. Now I will attack this from a different angle. Sep 17 11:19:05 LetoThe2nd: Do I understand you right you mean with your note about cronie that I should use it as example of a service that works well? Sep 17 11:19:23 10:33 < LetoThe2nd> fbre: i don't know what you're doing, so its hard to tell. i can only say that the cronie recipe does exac6tly what you wnt, so try reproducing it step by step Sep 17 11:19:33 fbre: i think that i said pretty much precisely that, yes. Sep 17 11:19:42 Leto Sep 17 11:20:29 LetoThe2nd: ah OK, thanks. I was reading it as if cronie is a sub-tool of bitbake doing that installing. Sorry, I was confused Sep 17 11:21:12 fbre: thats why i said "scroll up, read again". :) Sep 17 11:23:19 LetThe2nd: yes, sorry. I was a bit distracted here by other things happening in parallel here at work. That's why my slow response also. Thanks for the cronie example. I can imagine it can help me! Now I've something to step further. Thanks a lot, guys! Sep 17 11:29:08 New news from stackoverflow: "do_populate_sdk:Could not invoke dnf. Command" in yocto warrior branch Sep 17 12:00:00 Why am I seeing "DEBUG: Updating new environment variable LC_ALL to en_US.UTF-8", and all recipes are reparsed on each invocation of bitbake, although no recipes/conf files changed Sep 17 12:06:07 nm, im confused Sep 17 12:10:35 log says bitbake is gonna rebuild bb_cache.dat, but it never gets created, there is just a dangling symlink Sep 17 12:15:47 YIPPPIE!!!!!!!!!!!!! I found the failure. Sep 17 12:17:56 The file start-firmware.service had a bad newline character in the last line of the file. I replaced it with a Linux newline character \n and suddenly it works Sep 17 12:18:28 This took me two and a half days *sigh* Sep 17 12:19:57 It is exactly the same type of error as reported here: http://lists.openembedded.org/pipermail/openembedded-devel/2016-March/106656.html Sep 17 12:20:29 The difference is just that I had a bad newline char while the guy from the mailing-list had a bad space char Sep 17 12:21:17 I wonder why it has such impact of the fact whether the whole thing works or not Sep 17 12:22:04 fbre: please create a bug :) Sep 17 12:22:29 I had \r\n and it has to be \n Sep 17 12:23:31 we have a custom systemctl for rootfs-time which presumably has bad line breaking logic in Sep 17 12:25:23 That is why I asked where that custom systemctl is located 2 days ago. I really want to see that script and what it does. Maybe I can provide a patch. Sep 17 12:25:30 please do Sep 17 12:25:33 systemctl-native Sep 17 12:29:07 I'm not completely clear with configuring the kernel. Does `bitbake -c menuconfig` open the kernel of the BSP referenced by `MACHINE` in my conf/local.conf? Sep 17 12:30:19 I'd like to take the defconfig of the BSP I'm using (meta-pocketbeagle in this case) and add an option to the kernel Sep 17 12:38:14 palate. yes it would. Sep 17 12:46:27 I'm in Bugzilla now. I select "Build System, Metadata & Runtime". Is that systemctl-native thing now a problem of BitBake, BSPs, Meta-yocto, OE-Core, Other YP Layer, Runtime, Security - Recipe Ugrade or Toaster? Sep 17 12:47:33 its in oe-core, so oe-core Sep 17 12:47:43 then the core component, i guess Sep 17 12:48:42 all right Sep 17 12:48:51 thanks Sep 17 12:51:29 on an initramfs boot, where there is no x11 or other graphical interface, it appears the console is echoed on the display. how do i disable this? Sep 17 12:52:25 i want to take full control of the frame buffer with a startup application Sep 17 12:53:40 it appears the cursor from the console takes out a block of pixels from the frame buffer and hoses my screen. Sep 17 12:55:30 i.e., this is the image specified in my build's local.conf: INITRAMFS_IMAGE = "initramfs-image" Sep 17 12:55:48 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13535 Sep 17 12:55:49 Bug 13535: normal, Undecided, ---, ross.burton, NEW , systemctl Sep 17 12:57:49 also, what is the process for submitting a new or updated recipe to oe? Sep 17 13:00:31 hello? Sep 17 13:00:35 is this thing on? Sep 17 13:01:03 * yates checks his internet connection.. Sep 17 13:03:42 yates: post a patch to the list Sep 17 13:03:51 should be in the readme for whatever layer Sep 17 13:04:01 ok Sep 17 13:05:08 nobody knows how to disable console output on the display? Sep 17 13:07:55 yates: kernel option fb_console or something similar Sep 17 13:08:04 yates: look there, you'll find it Sep 17 13:08:22 LetoThe2nd: will do! thank you! Sep 17 13:10:21 CONFIG_FRAMEBUFFER_CONSOLE=y ? Sep 17 13:10:59 i've built a toolchain with bitbake meta-toolchain, how can I make it have a static libc (next to the existing dynamic one)? Sep 17 13:12:09 yates: sounds fitting, if that is y then it might be the cause. Sep 17 13:13:49 see you guys. I'll give a party now since the failure is found :-D Thanks again and Bye Sep 17 13:15:43 rburton: ack. Sep 17 13:27:13 RP: before I send the strace issue to lkml, I'm doing a clean build and run and will also do it with 5.3 .. just in case there's already a fix lurking. Sep 17 13:38:00 RP: Sent V2 of the hashequiv with the requested changes... it should skip the tests (and at least parse) on Python 3.5, but I don't have a 3.5 image handy to test with Sep 17 13:38:03 rburton: i can't find a wx recipe in my layers but i'm pretty sure i based mine on this one: https://layers.openembedded.org/layerindex/recipe/20507/ Sep 17 13:44:05 https://layers.openembedded.org: Your account has been locked out. Please contact the admin. Sep 17 13:44:09 how do I add strace to an image? I've added it as a package in local.conf but it doesn't seem to be included.. ? Sep 17 13:45:18 fullstop: CORE_IMAGE_EXTRA_INSTALL += "strace" Sep 17 13:45:24 in your image.bb file Sep 17 13:45:36 OMG Sep 17 13:45:39 CORE_IMAGE_INSTALL_EXTRA Sep 17 13:45:47 I can't believe that I did that Sep 17 13:46:05 you mean you can't believe you're human? Sep 17 13:46:28 I can't believe that I didn't see it sitting right next to the others with the right word order. :-) Sep 17 13:47:27 lol Sep 17 13:47:29 fullstop: mmmmm, you know you should really avoid doing too much of that? Use an image recipe and IMAGE_INSTALL when you're ready, local.conf shouldn't really be shared Sep 17 13:47:54 and CORE_IMAGE_EXTRA_INSTALL should be used only in local.conf according to the ref-manual (I didn' Sep 17 13:47:58 t know that) Sep 17 13:48:34 I'm only using CORE_IMAGE_EXTRA_INSTALL in local.conf and it will be moved into layers and cleaned up once I know what I want and what I'm doing. Sep 17 13:58:54 JPEW: thanks, I'll trigger a test run Sep 17 14:07:56 RP: Oops, I send that patch to the wrong ML :/ Sep 17 14:58:26 YPTM - armin is on Sep 17 14:59:33 YPTM - Jan-Simon is on Sep 17 14:59:50 New news from stackoverflow: Yocto system lockup: rcu_preempt detected stalls on CPUs/tasks Sep 17 15:05:42 JPTM ross in Sep 17 15:08:54 Tim its a trap Sep 17 15:09:06 run away from the docbook Sep 17 15:09:17 YPTM: on another meeting. but will lurk on IRC. Sep 17 15:15:52 BB_SIGNATURE_HANDLER = "OEEquivHash" Sep 17 15:15:53 BB_HASHSERVE = "auto" Sep 17 15:17:20 YPTM: tlwoerner has been on since the start (but wasn't watching IRC) Sep 17 15:18:47 https://autobuilder.yocto.io/pub/non-release/20190916-9/testresults/testresult-report.txt Sep 17 15:32:20 smurray: I think that unit file perhaps should read ConditionPathExists=!/lib/udev/hwdb.bin Sep 17 15:32:20 ConditionPathExists=!/etc/udev/hwdb.bin Sep 17 15:32:20 ConditionPathExists=|!/lib/udev/hwdb.bin Sep 17 15:32:20 ConditionPathExists=|!/etc/udev/hwdb.bin Sep 17 15:33:06 since we want to trigger if either the etc or lib hwdb.bin isn't present but if one is we're ok Sep 17 15:34:27 hrm, it's |/etc/udev/hwdb.bin even on Fedora, which you'd think would be a distro where people pay attention to that Sep 17 15:36:09 smurray: hence why I think I have to be missing something Sep 17 15:37:20 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1054 (distcc breaks) Sep 17 15:37:21 RP: the commit message that added that logic implies it's to prevent regenerating it Sep 17 15:38:39 RP: so I agree, the condition seems wrong, and it is strange ;) Sep 17 15:40:23 damnit Sep 17 15:41:08 smurray: I suspect upstream would tell us to generate the file into /lib Sep 17 15:41:33 RP: it does look to have been regenerated on my F30 desktop even though Fedora ship it as a binary in /etc/udev, and have no extra files in /etc/udev/hwdb.d... Sep 17 15:42:05 Does anyone know any friendly systemd people we could ask? Sep 17 15:42:07 RP: it seems likely the x86 folks probably never noticed it since it's fast Sep 17 15:42:16 smurray: right :/ Sep 17 15:42:58 RP: heh, I'm going to be at the All Systems Go! conf this weekend, I could ask in person, perhaps Sep 17 15:43:24 RP: might be easier to open an issue in their github Sep 17 15:43:44 smurray: right, an issue would be the next step I think Sep 17 15:44:27 I am using meta-pocketbeagle from here: https://github.com/e-ale/meta-pocketbeagle, and it works. I wanted to add support for g_ether in the kernel, and used `bitbake -c menuconfig virtual/kernel` to edit it, and then `bitbake -c savedefconfig virtual/kernel` to save it as defconfig. However, it looks very different from the original defconfig: Sep 17 15:44:29 https://github.com/e-ale/meta-pocketbeagle/blob/master/recipes-kernel/linux/files/defconfig Sep 17 15:44:45 For instance, my defconfig doesn't have any "is not set" line. Sep 17 15:45:13 When running `bitbake -c menuconfig virtual/kernel`, isn't it supposed to load the defconfig from meta-pocketbeagle, so that I can just edit it? Sep 17 15:45:51 palate: probably the layer maintainers use make savedefconfig before adding the result, which means all the non-set options are stripped out to remove unneded clutter. Sep 17 15:46:50 LetoThe2nd: well, my defconfig has those lines stripped out, but the layer doesn't. That's the opposite of what you suggest, right? Sep 17 15:47:10 palate: yeah then i got it backwards. but the meaning is clear, right? Sep 17 15:47:33 LetoThe2nd: palate: actually the opposite. the layer defconfig is just the straight .config from the kernel build. Sep 17 15:48:32 oh, right. Sep 17 15:49:16 palate: are you using the master or OE/master branch? (or something else?) Sep 17 15:50:00 tlwoerner: of yocto? 2.7.1 Sep 17 15:50:15 palate: of meta-pocketbeagle Sep 17 15:51:24 tlwoerner: master Sep 17 15:53:25 You're right, it's apparently the .config directly. But then my .config is quite different than theirs. I just added "USB_ETH" as a module to get g_ether, and now my image doesn't build (it loops on "no usb device found"). Difficult to see if I messed something up in the kernel config Sep 17 15:54:00 (well I autoload g_ether, too, maybe that's not clever as a first try) Sep 17 15:54:12 palate: thanks. i was just curious. master is using the yocto-linux kernel (4.x) and OE/master is using 5.2.14 stable (upstream) Sep 17 15:55:06 tlwoerner: oh, you are actually the author :D Sep 17 15:55:17 helper Sep 17 15:55:26 tlwoerner: should I be using OE/master? Sep 17 15:55:35 depends on what you want Sep 17 15:55:45 tlwoerner: I want a pocketbeagle that can run g_ether :D Sep 17 15:56:33 so you're plugging in a usb-to-ether into the baconbits cape? Sep 17 15:57:49 tlwoerner: no, I just have a pocketbeagle (I don't know what the baconbits cape is). And yes, I try to connect to it from my computer over usb Sep 17 15:58:26 palate: https://images.app.goo.gl/BrUDPtr2qe2LfKfe6 Sep 17 15:59:36 smurray, rburton: https://github.com/systemd/systemd/issues/13581 Sep 17 15:59:41 tlwoerner: right. No I only have the pocketbeagle Sep 17 16:00:03 tlwoerner: but I guess the meta-pocketbeagle should still be fine Sep 17 16:00:10 palate: in any case, that's a common use-case. i'll take a look at enabling it "out of the box" Sep 17 16:01:21 tlwoerner: could it be that the pocketbeagle is "OTG" and therefore needs other modules than just g_ether? Sep 17 16:02:27 palate: yea, using the pocketbeagle by itself will be different than with the cape. i'm not sure how i'd connect an ethernet dongle to the pocketbeagle alone Sep 17 16:02:53 tlwoerner: guess i should get a pb plus cape some time soon too :P Sep 17 16:03:03 tlwoerner: I'm connecting a USB cable from my computer to the pocketbeagle, that's it Sep 17 16:03:15 i have one of these i can experiment with: https://images.app.goo.gl/9Z8xqWUq2arixK8y5 Sep 17 16:03:45 tlwoerner: why not just a USB cable between your computer and the beagle? Sep 17 16:04:21 palate: that's a serial console :-) Sep 17 16:04:52 My goal is to learn how to setup my yocto such that I can connect my computer to the pocketbeagle, have it recognized as an ethernet gadget, get an IP from a DHCP server running on the pocketbeagle, and then SSH into it Sep 17 16:05:19 tlwoerner: so I really want ethernet going through a normal usb cable, hence g_ether Sep 17 16:07:41 palate: you're going to have more luck asking on #beagle imo Sep 17 16:08:41 smurray: I just broke my image by updating the kernel, so I was wondering if I had done something wrong there. Maybe I did it right, but I just did not set the right options :D Sep 17 16:09:45 palate: questions about kernel config are more on topic for #beagle Sep 17 16:10:04 got it, thanks :) Sep 17 16:10:10 someday the yocto project / oe will decide on one set of tools for kernel configs, then all BSP layers can have one mechanism ;-) Sep 17 16:11:46 tlwoerner: what are the different mechanisms? I only know menuconfig Sep 17 16:12:50 behind the scenes there are differences. take a look at meta-raspberrypi Sep 17 16:14:46 tlwoerner, and then we solve world peace Sep 17 16:17:05 Crofton: hahaha LOLzzzz Sep 17 16:18:58 * zeddii has patches for that! well, not world peace Sep 17 16:25:01 fwiw, baconbits is being deprecated for https://beagleboard.org/techlab Sep 17 16:39:48 tlwoerner: what's the relation between the company/people doing baconbits and pocketbeagle? Did pocketbeagle acquire baconbits, somehow? Sep 17 16:40:12 tlwoerner: or simpler: is it a good thing that baconbits is being deprecated for that? :D Sep 17 16:42:50 Baconbits is open hardware Sep 17 16:43:57 (i'll let behanw answer, he's more involved with the specifics) Sep 17 16:44:16 Techlab is a mostly a superset design of baconbits. As a part of making it available as a part of the Beagle ecosystem it was redesigned and cost reduced to an extent Sep 17 16:44:47 Baconbits isn’t deprecated. It’s still a great board. Sep 17 16:44:53 ah, my bad Sep 17 16:45:11 Techlab was put together to be made widely available via the usual distribution channels Sep 17 16:45:30 i also hadn't noticed the techlab is now available for purchase, i thought it was still in testing :-) Sep 17 16:45:33 You can buy techlab from digikey for instance Sep 17 16:45:51 behanw: don't you mean mouser... ;-) lol Sep 17 16:46:01 A matter of time Sep 17 16:46:25 The idea is to have them available from wherever Sep 17 16:46:48 Our kits are special though because we need things pre-soldered. Sep 17 16:47:20 behanw: i'm just pulling your leg, i think it's totally awesome they're available from either, although i find mouser *tends* to be cheaper on average Sep 17 16:47:28 So I have kits with techlab/pocketbeagle soldered together with cables, sd card and reader, etc Sep 17 16:47:48 it blows me away how i can order something from either mouser or digi-key at 7pm one day, and it's on my desk before lunch the next :-) Sep 17 16:48:05 I buy direct from the mfg. I don’t actually know where they’re sold ;) Sep 17 16:49:03 The difference is that my lead time is 8 weeks, not next day Sep 17 16:54:26 behanw: did mw design the techlab? the gamepup cape looks interesting too; where did that come from? Sep 17 16:59:51 Baconbits is from m_w Sep 17 17:00:00 Techlab is designed by ghi Sep 17 17:00:12 Based on the bb design Sep 17 17:00:21 Both are open hardware Sep 17 17:01:13 And the baconbits is based on the bacon cape designed by prpplague Sep 17 17:01:22 Long lineage Sep 17 17:06:05 hey what's the preferred way to install a bunch of ipk to a folder and still be able to leverage the postinst hooks ? using opkg -o myNewRootfs install *.ipk requires --force-postinstall, but the scripts still operate on the real root instead of the one given after -o Sep 17 17:34:15 LetoThe2nd: to follow-up, i have confirmed changing CONFIG_FRAMEBUFFER_CONSOLE to no disables "echo console to framebuffer" behavior. thanks again! Sep 17 18:33:32 yates: :-) Sep 17 19:04:03 JPEW: any idea on https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/717/steps/8/logs/step2d ? Sep 17 19:04:39 JPEW: that is with http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=c7d482523599e204f2580002485e4125a9cd45dc Sep 17 19:05:04 RP: I'll take a look Sep 17 19:06:18 JPEW: good news is that the new server stuff seemed to work ok this time! Sep 17 19:06:48 RP: Excellent. Is it fast enough? You can use the bitbake-hashclient command to get the server stats. Sep 17 19:07:05 JPEW: I've not enabled it yet. This just tested we don't regress Sep 17 19:07:27 JPEW: one step at a time Sep 17 19:07:36 RP: Ya, I realized that was probably the case as soon as I asked :) Sep 17 19:08:37 RP: Hmm, that one is interesting because it's actually failing in the do_deploy_source_date_epoch this time.... so that's obviously not the task causing the race Sep 17 19:09:13 JPEW: I didn't look in detail but gcc is shared workdir which may play a part Sep 17 19:09:20 (or may not( Sep 17 19:14:59 RP: Ah, `deltask do_unpack` for the shared gcc source will do that... the SDE is only created as a postfunc of do_unpack :( Sep 17 19:15:17 RP: We probably never noticed it was missing before.... Sep 17 19:20:36 JPEW: that would indeed explain it Sep 17 19:23:25 RP: Not sure the best solution... add it as a prefunc to do_patch and do_deploy_source_date_epoch? That feels messy, but would probably catch the current failure cases. It looks like do_patch is also commonly deleted in recipes that delete do_unpack. Sep 17 19:26:10 JPEW: could we copy the file in gcc shared-work if present? Sep 17 19:27:29 JPEW: or redefine SDE_FILE for gcc?> Sep 17 19:28:18 RP: The SDE file is one we create (a cache of sorts) in a postfunc of do_unpack, so there really isn't anywhere to copy it from Sep 17 19:28:40 JPEW: but one will have been created by the original shared gcc workdir? Sep 17 19:29:47 JPEW: there is a gcc-source do_unpack so I'm wondering if we can use that somehow Sep 17 19:30:07 Oh, ya, there should be one in it's ${WORKDIR}, we might be able share it somewhere Sep 17 19:31:31 Although, the more I look at this, the more I think rburton is right and we shouldn't even bother with the complex logic, just define the SOURCE_DATE_EPOCH variable to a constant and leave it at that. Sep 17 19:31:53 Problem is, no one can tell me if there is a really good reason why we do it this way Sep 17 19:32:42 New news from stackoverflow: create symbolic link in bitbake recipe Sep 17 19:33:15 Hmm.... That's interesting though... if the SDE file can't be found, it falls back to a constant, so one option is just to make the missing file non-fatal Sep 17 19:34:29 RP: Anyway, short answer is to drop the patch from master-next for now; it will cause more build failures than it attempts to fix :) Sep 17 19:34:33 JPEW: having the dates all set to one thing was rather ugly and looked poor. It came from a desire to simply do better from what I remember Sep 17 19:35:23 RP: Ya, I can see why that would be desirable Sep 17 19:36:11 dreyna: pip._internal.exceptions.DistributionNotFound: No matching distribution found for Django<1.12,>1.8 (from -r /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/build-appliance-image/15.0.0-r0/rootfs/home/builder/poky/bitbake/toaster-requirements.txt (line 1)) Sep 17 19:36:28 dreyna: I'm wondering what changed for us to start seeing this :( Sep 17 19:36:46 dreyna: (its from bitbake build-appliance-image, reproduces locally) Sep 17 19:37:05 Ah, Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: Sep 17 19:38:27 RP: I am preparing on a patch set to take Toaster to support Django 2.x (since the latest hosts use this). Hopefully the SSL issue will solve your immediate issue Sep 17 19:38:35 * RP wonders if this is the openssl issue Sep 17 19:39:08 dreyna: thanks. I'm just getting confused over which patches are causing which problems :( Sep 17 19:39:57 khem: 5 failures for meta-oe: https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/4 Sep 17 19:41:02 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/90/builds/3 meta-virt had 4 failures Sep 17 19:41:03 With the `core-image-minimal`, I don't get much output from the kernel at boot time. How can I get more? Is that the default loglevel? Sep 17 19:41:26 palate: its probably more about what is on your kernel commandline and where you sent the logging Sep 17 19:43:04 RP: hmm I'm new to yocto and linux kernels, I'm not sure that helps me. Here is the output I get when starting my pocketbeagle: https://pastebin.com/DbGiGH7Q. That's not a lot, is it? Sep 17 19:45:13 palate: cat /proc/cmdline Sep 17 19:45:31 will show your kernel commandline options which were used when booting Sep 17 19:47:17 Jusii: `root=PARTUUID=e8a517c2-02 rootwait console=ttyS0,115200` <- this? Sep 17 19:48:40 so is the above pastebin from serial output? Sep 17 19:49:28 Jusii: yes Sep 17 19:49:54 Jusii: oh, is it sending less output over serial? Sep 17 19:52:07 well, console=ttyS0,115200 should print all on serial Sep 17 19:53:41 but ofcourse there's many ways to disable kernel messages on boot, like in your case it is Sep 17 19:53:56 quite often you'd have console=tty in there too to have a console on the video output but as it stands it looks to be sending it to serial. Is ttyS0 correct for a pocketbeagle Sep 17 19:53:58 ? Sep 17 19:54:25 RP: I'm connecting with `screen /dev/ttyUSB0 115200` Sep 17 19:54:43 what's this? pocketbeagle /dev/ttyO0 Sep 17 19:55:06 that's your local serial, but what is the serial device on pocket beagle Sep 17 19:55:21 palate: that is the device on your host system which would be different to the one on the target beagle Sep 17 19:55:22 http://beaglebone.cameon.net/home/serial-ports-uart Sep 17 19:56:00 so maybe console=ttyO0,115200 should fix that? Sep 17 19:56:13 I'd agree with that FWIW Sep 17 19:56:46 https://pastebin.com/pRVT33me Sep 17 19:56:58 that's what I get with `ls -l /dev/tty*` Sep 17 19:57:13 Jusii: can I just edit /proc/cmdline? Sep 17 19:57:13 right, you want O1 Sep 17 19:57:19 no Sep 17 19:57:22 palate: no Sep 17 19:57:42 you should be able to fix that in u-boot I'd guess Sep 17 19:57:53 which passes the cmdline to kernel Sep 17 19:57:55 or in the kernel if its compiled in there instead Sep 17 19:58:02 true Sep 17 19:58:26 that means on the yocto side before building the image, or directly from the pocketbeagle over serial? Sep 17 19:58:28 now you need to figure out how to modify kernel boot cmdline Sep 17 19:58:34 ok Sep 17 19:58:49 (sorry I'm very new to all that, but taking notes :-) ) Sep 17 19:58:52 you can do it yocto side before building for sure Sep 17 19:59:02 but you can try doing it in u-boot too Sep 17 19:59:11 palate: if I remember you were editing a defconfig earlier? Sep 17 19:59:26 RP: why do I want O1? Because O0 and O4 are used already? Sep 17 19:59:39 palate: sorry, I meant o) Sep 17 19:59:46 O0 Sep 17 19:59:56 * RP should just stop trying to help :/ Sep 17 20:00:01 RP: yes, I was. But the image would not boot anymore, so I tried to go back to the one that was booting (and that's the output I shared here) Sep 17 20:00:17 ok -> O0 it is :D Sep 17 20:00:38 palate: ok. I was wondering if this was something you'd set. In that case its probably coming from uboot Sep 17 20:00:39 RP: so now I need to get more output, so that when I start again and it fails, I can have an idea why Sep 17 20:00:52 RP: you blamed distcc for https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1054 but isn't that the gles typo? Sep 17 20:02:00 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1058 Sep 17 20:02:15 rburton: that is the failure I was trying to link to, perhaps unsuccessfully Sep 17 20:02:21 gotcha Sep 17 20:02:27 "Postinstall scriptlets of ['distcc'] have failed. If the intention is to defer them to first boot," Sep 17 20:02:34 sounds distcc like Sep 17 20:02:38 yeah :) Sep 17 20:02:44 but nothing would surprise me today :( Sep 17 20:04:13 ok fixed, forgot to update another PN -> PN-server Sep 17 20:04:32 still need to write my pkgdata browser to inspect what goes into packages Sep 17 20:04:50 rburton: glad its something simple Sep 17 20:08:59 rburton: that openssl issue is what is breaking build-appliance too Sep 17 20:09:06 khem: your patch fixes it, thanks! Sep 17 20:11:44 oh hooray khem Sep 17 20:12:10 bit concerned that latest debian has 'older glibc' Sep 17 20:19:32 JPEW: full build fired with hashequiv enabled Sep 17 20:23:42 I think I mess up when I rebuild the kernel. So I have this BSP, meta-pocketbeagle, that works. From build/, I do `bitbake -c menuconfig virtual/kernel`, I "save" to ".config" without having changed any option, and then I do bitbake -c savedefconfig virtual/kernel. This outputs a `defconfig`. I replace the old defconfig of meta-pocketbeagle with that new one (which should be exactly the same, Sep 17 20:23:44 right?), and the image does not boot anymore -_- Sep 17 20:24:17 I was expecting that `bitbake -c menuconfig` would use the options defined by my defconfig in the first place... Sep 17 20:25:39 Is it wrong to generate the defconfig this way? Sep 17 20:29:17 argh I think I'm doing something wrong. I edited the *working* defconfig (without calling menuconfig at all, because that fails), to comment out CONFIG_SERIAL_OMAP and replace it by another option. I get the following output: https://pastebin.com/1ydPiACN Sep 17 20:29:30 It seems to still take my commented out option -_- Sep 17 20:33:46 RP: is the weston-init patch ok now ? Sep 17 20:34:01 I am more and more impressed with AB testing Sep 17 20:36:14 khem: I haven't requeued as I have a few too many other problems without that added risk (yet) Sep 17 20:36:42 khem: the test matrix is getting fairly comprehensive :) Sep 17 20:37:04 rburton: I thing the --with-rand-seed=devrandom is wrong but then I dont have those older glibc systems to test removing it, so I kept it there as fallback Sep 17 20:37:58 RP:this was a genuine problem introduced in my patch and it was nice a system called it out Sep 17 20:38:31 khem: we've had those tests for a while. They were written to detect that exact problem :) Sep 17 20:38:43 RP:no hurry it can go in next lot, I have few BSP layer patches waiting on it Sep 17 20:39:35 something has broken musl/risv64 dont know what Sep 17 20:40:04 maybe its musl or maybe something else in core metadata or packages Sep 17 20:40:06 need to get them as members and into the test matrix Sep 17 20:40:12 :) Sep 17 20:40:31 all are startups Sep 17 20:40:48 maybe silver Sep 17 20:45:44 RP:re meta-oe AB runs 3 failures are openssl induced which should be fixed now, uim-native and dfu-util-native are new and seems specific to build host Sep 17 20:46:15 khem: ok, sounds promising that some should get fixed then Sep 17 20:47:35 this is tumbleweed is it ? Sep 17 20:52:43 RP:in case of dfu-util-native it seems the build machine needs to have static glibc-devel installed and is missing so it fails to do static linkinh Sep 17 20:53:37 maybe if you have access to build node then try gcc -static hello.c -lpthread on it I think it will fail in same way Sep 17 20:53:41 /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lpthread Sep 17 20:53:44 /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lc Sep 17 20:56:30 uim-native is Sep 17 20:56:34 | collect2: error: ld returned 1 exit status Sep 17 20:56:36 | x86_64-linux-libtool: error: error: relink 'libuim-fileio.la' with the above command before installing it Sep 17 20:56:52 seems we can get past by deleting .la files Sep 17 20:56:59 khem: that sounds like we have an undocumented dependency then Sep 17 20:57:16 khem: we install exactly what is documented onto the workers Sep 17 20:57:23 right Sep 17 20:57:46 if you or someone can validate then we can change the docs Sep 17 20:58:00 khem: is there no way to avoid that dependency? Sep 17 20:58:17 some packages like luajit also needs 32bit gcc on build hosy Sep 17 20:58:36 maybe disable static linking Sep 17 20:58:59 I dont know why one would need a statically linked binary on the build host Sep 17 20:59:06 palate: RP: this (lack of kernel output on booting) is exactly what i was talking about in http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286869.html Sep 17 20:59:08 khem: we may just have to have an exclusion file listing these things Sep 17 21:00:02 tlwoerner: I'm out of touch with wic I'm afraid so I'm not much help :( Sep 17 21:00:19 tlwoerner: The u-boot defaults are what set that string. Sep 17 21:00:30 Depending on the board. Sep 17 21:00:34 jwessel: in this case that string is being set by wic Sep 17 21:01:08 I suppose that is plausible, but doesn't it imply that it is reading it from a file which u-boot knows to look for? Sep 17 21:01:27 RP: i only pointed to you because you were trying to help :-) Sep 17 21:02:02 might as well try to short-circuit everyone trying to help when i've already root-caused the issue ;-) Sep 17 21:02:50 tlwoerner: fair enough. I'm just sad I'm so out of touch with some of this stuff :( Sep 17 21:02:53 jwessel: yes, there are many ways to help U-Boot pass cmdline args to the linux kernel, extlinux is one of them Sep 17 21:03:15 I'd like to at least make it consistent with what ever it is you are doing. Sep 17 21:03:22 RP: you do what you do best, 'cause i don't know many who could take over from you! Sep 17 21:03:44 The ostree boot mechanics for example, make use of the boot.scr generated file from u-boot-env. Sep 17 21:03:57 But again, this is something that is highly board dependent. Sep 17 21:03:59 jwessel: as such, there is a whole class mechanism in place so a user can tweak the extlinux file (which is great, yea!!) Sep 17 21:04:29 Well I guess you could always encode it in the kernel that is getting loaded too. ;-) Sep 17 21:05:11 jwessel: but as soon as the user decides to use wic, and specifically uses the bootimg-partition option, wic comes along and clobbers whatever the user has requested and hard codes the extlinux file with no ability for the user to tweak :-( Sep 17 21:06:17 it's something i only stumbled upon very recently (as i was tweaking the meta-pocketbeagle BSP layer) and then, a couple days later, a user comes along and stumbles on the same thing :-) Sep 17 21:06:22 https://linux-sunxi.org/Mainline_U-Boot - How many of the u-boots are configured to use that feature? Sep 17 21:06:28 * jwessel goes to look at a local board. Sep 17 21:06:42 palate: this is "fixed" in the OE/master layer, it's fixed by hard-coding the kernel cmdline in the kernel config itself ;-) Sep 17 21:06:45 I was using bootmenu on this particular board previously. Sep 17 21:07:43 see: http://cgit.openembedded.org/openembedded-core/tree/scripts/lib/wic/plugins/source/bootimg-partition.py#n146 Sep 17 21:08:03 jwessel: palate: ^^ does that look familiar (i.e. the contents of the extlinux file)? Sep 17 21:08:07 I would agree you need the ability to customize it, I didn't even know it existed. Sep 17 21:09:05 tlwoerner: oh... Sep 17 21:09:15 so either i could not use the bootimg-partition facility of wic (like Otavio does in his BSPs) Sep 17 21:09:22 It looks to me like you can put a custom file in there though. Sep 17 21:09:51 or not use wic (and let the extlinux class generate the file) Sep 17 21:10:10 or tweak the wic thing Sep 17 21:10:59 tlwoerner: so that's not related to the ttyO0 vs ttyS0 thing? Sep 17 21:11:01 jwessel: yes, it's looking "somewhere" but for the life of me i can't figure out where. if you use the extlinux class, it will generate a file and place it in U-Boot's ${B} directory, but this wic class is obviously not looking there Sep 17 21:11:48 palate: no, there's a kernel config option to get OMAP-type processors to use ttyS instead of ttyO Sep 17 21:12:00 configfile = cr.ks.bootloader.configfile Sep 17 21:12:20 jwessel: exactly. any idea where that is? Sep 17 21:13:09 * tlwoerner 's python-foo only gets him so far... Sep 17 21:13:29 in any case, it's not looking where the extlinux class is placing its results Sep 17 21:13:55 (presumably wic does its work very late in the process, so it can't be a timing issue) Sep 17 21:13:58 scripts/lib/wic/ksparser.py: bootloader.add_argument('--configfile') Sep 17 21:14:05 It is one of the options you can specify. Sep 17 21:14:35 wic help kickstart |less Sep 17 21:14:41 Run that and search for configfile Sep 17 21:14:49 You'll see it is actually documented. Sep 17 21:15:05 Where by you can pass in what ever you like. Sep 17 21:15:06 tlwoerner: actually, I think I may have another fix, thanks to zmatt on #beagle: set CONFIG_SERIAL_8250=y, CONFIG_SERIAL_8250_OMAP=y and CONFIG_SERIAL_8250_CONSOLE=y instead of CONFIG_SERIAL_OMAP and CONFIG_SERIAL_OMAP_CONSOLE Sep 17 21:15:19 pfft! who reads documentation? (lol, here i was trying to read the code!) Sep 17 21:15:25 tlwoerner: now I just get a lot of output when booting, without changing anything else (well, rebuilding the kernel). Does that make sense? Sep 17 21:15:29 I read the code to find the doc. Sep 17 21:15:48 See my reference to ksparser.py above. Sep 17 21:15:55 Then I realized it was documented. Sep 17 21:18:00 RP: dfu-utils problem might be gone if we remove this patch https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/dfu-util/dfu-util/0001-Revert-Makefile.am-Drop-static-dfu-util.patch which is a revert of an upstream commit Sep 17 21:18:10 palate: yes https://github.com/e-ale/meta-pocketbeagle/blob/OE/master/recipes-kernel/linux/linux-stable-5.2/defconfig (notice also the CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y as well) Sep 17 21:18:41 i'm not 100% sure what is the smallest config you need to get it working, but this one works Sep 17 21:18:50 khem: worth a try, its from 2011 so things have changed Sep 17 21:21:19 tlwoerner: should I actually just go on OE/master completely? Sep 17 21:21:45 well... i don't want to get into any fights... Sep 17 21:22:10 tlwoerner: I have no clue about the difference. OE/master is some kind of fork, but in a branch? Sep 17 21:22:19 master was intended for someone to use with yocto, OE/master was intended to be used was OE only Sep 17 21:22:39 palate: yes Sep 17 21:22:48 tlwoerner: but OE/master now works with yocto, right? Sep 17 21:22:55 OE/master only depends on openembedded-core Sep 17 21:23:22 khem: do you want to try that in a -next branch for meta-oe? Sep 17 21:23:28 tlwoerner: and you're here. So I'm moving to OE/master :D Sep 17 21:23:32 khem: we could try a build of -next of poky and meta-oe Sep 17 21:23:44 master depends on poky Sep 17 21:24:11 master uses yocto-linux, and OE/master uses upstream Sep 17 21:24:44 tlwoerner: but yocto is based on OE, right? Sep 17 21:24:46 tlwoerner: I'm now wondering what the difference is :/ Sep 17 21:25:14 tlwoerner: surely a given layer works with poky or oe-core+bitbake and doesn't need two branches? Sep 17 21:25:35 i had a conversation over the weekend with Robert about what i should use for the upstream defconfig, but it kinda petered out Sep 17 21:25:56 palate: yocto is very much oe based Sep 17 21:28:10 right Sep 17 21:29:31 well... i *could* dive into a whole diatribe... but nobody wants that, not even me! ;-) lol Sep 17 21:30:01 plus, i didn't create the meta-pocketbeagle layer and having the two branches is a way of preserving what was there, while also moving along with new things Sep 17 21:30:11 tlwoerner: I'm not asking for a diatribe, I would like to understand why one layer can't work with both. Is it a technical reason? Sep 17 21:30:39 the branch that works with poky uses an older kernel, that needs, for example, ttyO0. but using the latest stable upstream kernel switches to ttyS0 Sep 17 21:30:55 so instead of making the layer really messy with overrides, i just created two branches Sep 17 21:31:31 i'm not saying overrides wouldn't have worked or aren't elegant in their own way, i'm just saying this is my brutish way of doing overrides Sep 17 21:31:39 tlwoerner: ah, so the difference is trying to align with linux-yocto? Sep 17 21:32:05 yes, and not clobbering the valid work of other people Sep 17 21:32:30 if you want to generate a tar.bz2, jffs2, wic, and wic.bmap, be my guest (master). all i need is a wic (OE/master) ;-) Sep 17 21:32:59 tlwoerner: I worry this approach is going to really confuse users Sep 17 21:33:32 RP: welcome to BSP-land, where every BSP does every thing its own way Sep 17 21:33:37 I'm having an issue with RDEPENDS: https://pastebin.com/pMqd2REe Sep 17 21:33:52 RP: i'm laughing as i say that, but it's not far from the truth ;-) Sep 17 21:34:19 I'm clearly RDEPENDING on python3 in a recipe that's installing a python file that starts with the line "#!/usr/bin/python3" Sep 17 21:34:24 and it's not meant to insult the hard work people have put into their BSP layers, BSP layers have their own quirks Sep 17 21:34:46 e.g. tweaking a kernel configuration Sep 17 21:35:35 e.g. proving recipes for vendor-kernels/u-boot/windowing-systems vs upstream Sep 17 21:35:37 tlwoerner: my concern is simply that having one configuration marked as "yocto" and one as "OE" is pretending the difference is something which its really not :/ Sep 17 21:36:07 RP: okay, fair enough, i can switch that to "upstream" (?) Sep 17 21:36:14 tlwoerner: that means its hard for a user to understand what it is and fans "OE vs Yocto" flames when its not really that Sep 17 21:36:42 s/proving/providing Sep 17 21:37:07 tlwoerner: marking one as "linux-yocto "and one as "upstream kernel" would be clearer (I don't still fully understand the difference so it maybe the markup needs to be different) Sep 17 21:38:30 tlwoerner: FWIW I'm fine with BSPs using different kernels. They can use linux-yocto if it works for them or not. Having one recommended kernel for a given platform is probably wise, or let the user select with PREFERRED_PROVIDER and/or PREFERRED_VERSION Sep 17 21:39:09 I am including the python3 package in my layer, and the booted image does indeed contain python3 located in /usr/bin/ Sep 17 21:39:46 So the package called "python3" seems to be providing the file /usr/bin/python3. Sep 17 21:40:15 But when I run bitbake, it complains: ERROR: QA Issue: /usr/local/bin/enum.py contained in package diagnostics requires /usr/bin/python3, but no providers found in RDEPENDS_diagnostics? [file-rdeps] Sep 17 21:40:57 But this is despite my "diagnostics.bb" containing the line RDEPENDS_${PN} += "python3" Sep 17 21:41:34 tlwoerner: that's interesting Sep 17 21:41:57 RP: choosing a kernel has dramatic consequences for a build. for example with a vendor kernel you can then use, say, mali for your graphics, but most vendor kernels are *very* old, which means you can't use the latest this or that (e.g. perf). whereas if the user selects an upstream kernel they can now choose, say, panfrost or etnaviv Sep 17 21:42:42 tlwoerner: what would be the risk/downside of using `master` (seems like `OE/master` is just more modern) Sep 17 21:43:31 being forced to base a build on, say, a 3.x or 4.x vendor kernel (not uncommon) affects a lot of other configurations and choices Sep 17 21:44:03 tlwoerner: Yes, I can imagine that. I guess that is where the overrides come in :/ Sep 17 21:44:38 tlwoerner: I guess it comes down to better labelling of the branches then as "OE" really doesn't cover that Sep 17 21:44:49 Otavio tried to capture this in one layer/branch by using his machine-overrides-extender.bbclass, but efforts to get that into openembedded-core (so everyone could use it) weren't successful Sep 17 21:45:17 RP: yes, sorry. didn't mean to put things sideways :-( Sep 17 21:45:53 https://github.com/Freescale/meta-fsl-arm/blob/master/classes/machine-overrides-extender.bbclass Sep 17 21:46:35 tlwoerner: btw, I just built from OE/master, and I think it generated a .tar.gz... :D Sep 17 21:46:59 so i suggested a meta-bsp layer where some BSP authors could get together to define a set of common classes and recipes for upstream stuff, but that never took off either :-/ Sep 17 21:47:05 *shrug* Sep 17 21:47:21 palate: wic might need a tar.gz Sep 17 21:47:29 tlwoerner: there are other simpler ways you could probably do something like that albeit with slightly more duplication Sep 17 21:47:32 (but i don't explicitly need one) Sep 17 21:47:42 tlwoerner: I was never sold on adding that level of complexity into the core Sep 17 21:47:54 tlwoerner: if the feedback is many people need it we could look at it again Sep 17 21:48:43 RP: i'm sitting at a point here with meta-pocketbeagle (and some other BSP layers) where i'd be willing to give other things a try Sep 17 21:49:11 RP: i'm not the strongest bitbake/layer developer, so if you could point me at something that'd be awesome! :-D Sep 17 21:49:28 tlwoerner: OE/master seems to be working like a charm! Sep 17 21:49:39 tlwoerner: and apparently it has g_ether already \o/ Sep 17 21:50:04 palate: w00t! Sep 17 21:50:17 any ideas on the RDEPENDS error? Sep 17 21:50:26 * tlwoerner accidentally did something right ;-) Sep 17 21:50:32 tlwoerner: xD Sep 17 21:50:36 lol, how most things get done Sep 17 21:50:54 palate: do you know it's CONFIG_ option? Sep 17 21:51:01 (s/it's/its) Sep 17 21:51:20 tlwoerner: I think it should be CONFIG_USB_ETHER Sep 17 21:51:49 tlwoerner: but I'm new to... kernels... so I may be wrong. Though I got help to find that out :) Sep 17 21:51:56 tlwoerner: I'm wondering why you can't set MACHINEOVERRIDES to what you need directly? Sep 17 21:52:16 palate: CONFIG_USB_ETH=m Sep 17 21:52:27 tlwoerner: Core supports MACHINEOVERRIDES, its just the magic groupings it doesn't Sep 17 21:52:31 tlwoerner: yep, that's consistent with what I see Sep 17 21:52:36 palate: Robert suggested i base my defconfig on omap2plus_defconfig, so it probably came in from there Sep 17 21:52:56 tlwoerner: right. That's awesome, `modprobe g_ether` just worked :) Sep 17 21:53:44 palate: and it only took 6 hours for us to figure out i had already inadvertently solved your issue Sep 17 21:53:51 I'll go to bed soon, but before, I really don't understand. From OE/master, if I now go in build and run `bitbake -c menuconfig virtual/kernel`, it should load the defconfig coming from meta-pocketbeagle, right? Sep 17 21:53:59 tlwoerner: haha yes, but I learned many things in the process! Sep 17 21:54:21 palate: yes, i would expect that Sep 17 21:54:24 tlwoerner: (more than 6 hours for me, though :D) Sep 17 21:54:41 RP: okay, i'll have to take a deeper look Sep 17 21:54:58 tlwoerner: ok, let me just do that, and export it without changing anything. Before that was breaking my image (it would not boot anymore) Sep 17 21:57:07 well, now it says "no change to .config"... before it would just save it Sep 17 21:57:29 Let's say I'm happy with OE/master, I'll work on networking through g_ether next time :-) Sep 17 21:57:38 Thank you so much with all the help! Sep 17 21:58:41 palate: you're welcome, and welcome to #yocto! Sep 17 21:58:47 thanks :-) Sep 17 21:59:00 Thanks RP, too (obviously)! Sep 17 21:59:02 good night guys! Sep 17 22:00:31 I'm using an EXTERNAL_TOOLCHAIN, but in the SDK, the executables from it are not using absolute paths and the EXTERNAL_TOOLCHAIN directory is not added to PATH Sep 17 22:00:55 Any ideas what's gone wrong here? Sep 17 22:03:16 New news from stackoverflow: How does VARIABLE_*_something works? in Yocto Sep 17 22:05:29 ecdhe: does it help if you just change it to a DEPENDS (drop the *R*DEPENDS)? Sep 17 22:05:38 tlwoerner: will check Sep 17 22:09:01 RP: okay, reading about MACHINEOVERRIDES gives me something to try, i'll give it a whirl Sep 17 22:09:28 tlwoerner: RDEPENDS->DEPENDS doesn't fix it. Sep 17 22:10:13 ecdhe: that is a good thing, it would have been messy if it did Sep 17 22:10:31 Yeah, I didn't figure it was the problem. Sep 17 22:11:18 I'm trying to confirm that the python3 recipe provides the /usr/bin/python3 file, but I can't find the .bb file that brings along the interpreter itself anywhere in meta-python. Sep 17 22:17:14 tlwoerner: if its not working talk to me about it Sep 17 22:17:30 RP: will do **** ENDING LOGGING AT Wed Sep 18 02:59:57 2019