**** BEGIN LOGGING AT Mon Oct 15 03:00:01 2018 Oct 15 07:17:06 morning Oct 15 07:19:05 RP: i can confirm that. Oct 15 07:53:08 Hello! what should I clean after adding `inherit allarch` ? image making (do_rootfs) still wants arch specific ipk altough -all.ipk has been created Oct 15 08:00:50 I did image-name -c cleanall but that's not it Oct 15 08:53:32 ak77: false alarm, i had two inherit lines.. it works with single one Oct 15 10:25:56 What can I do with rpm files? Oct 15 10:27:01 learningc: Revolute them Per Minute. Oct 15 10:28:25 Ok, what else? Oct 15 10:28:56 learningc: possibly also use them as the defined format for the RedhatPackageManager Oct 15 10:31:39 learningc: It's a package format. You can use it to manage (install, uninstall, update, etc.) software packages. It also contains meta-data, such as dependencies and all sorts of wonderful things. Oct 15 10:33:35 Ah I see. Thanks jofr. (sorry I'm new to what package was in yocto, but now I know) Oct 15 10:34:15 RPM is just one package format out of many. And Yocto can generate a few different formats. Oct 15 10:34:18 How do I install a package? Oct 15 10:34:42 "I have rpm format currently" Oct 15 10:35:33 Is there a command to issue like "apt install" as in ubuntu? Oct 15 10:35:38 learningc: manually installing packages should totally be the last resort. just use IMAGE_INSTALL, and have everything done automatically. Oct 15 10:36:25 Yes. It's "rpm". But like LetoThe2nd says, if you're doing a Yocto-build it probably want to have the build-system install the package into your image. Oct 15 10:36:26 LetoThe2nd, But with IMAGE_INSTALL, the package will be in my rootfs? Oct 15 10:37:09 learningc: under the hood, IMAGE_INSTALL does exactly that, it installs the package into the image. but without the hassles of finding and copying, and leftovers from the package manager Oct 15 10:38:05 The problem is, I made a lot of changes on my board in my current root fs, so I don't want to rewrite a new rootfs onto my board right now... Oct 15 10:38:16 learningc: But I think perhaps you should take a step back, and explain what it is you're trying to do. Oct 15 10:38:22 learningc: better walk through the changes and document them. Oct 15 10:38:32 e.g. make proper recipes. Oct 15 10:40:01 Ya, that's what I should do in the later stages, but now I just want to test with the current rootfs without destroying all the changes and somehow I need to install a new application. How should I do it? Oct 15 10:40:33 learningc: well if you do not have package management already enabled in the image, then: not at all, because the tools will not be there. Oct 15 10:41:23 How do I verify if I have a package management enabled on my board? Oct 15 10:41:43 Try to write: rpm Oct 15 10:41:51 ok Oct 15 10:42:05 "rpm" is the tool for.... Oct 15 10:42:10 it's THE rpm.. Oct 15 10:42:15 I typed in rpm, but nothing happens Oct 15 10:42:31 see, no package management. also known as, the default situation. Oct 15 10:42:58 But I did not get any "command not found" Oct 15 10:43:39 rpm: --hash (-h) may only be specified during package installation <- I get this when I type rpm -h Oct 15 10:43:50 So it's there? Oct 15 10:43:53 lucky you, it is enabled then. Oct 15 10:44:45 But how do I install a package with it? Oct 15 10:44:48 Then refer to the documentation and see if you can install some packages. :-) https://linux.die.net/man/8/rpm Oct 15 10:44:57 you build the package, copy it over, then install it. Oct 15 10:45:11 Any quick command snippet to install foo.rpm? Oct 15 10:45:17 no Oct 15 10:45:22 it does not work like that. Oct 15 10:45:45 there is no upstream repository server from which you could get all that stuff automatically. Oct 15 10:45:58 I see. Oct 15 10:46:18 learningc: Are you trying to make your build-system install an RPM package or are you trying to manually install a package you have into your system? Oct 15 10:47:00 jofr, I'm trying to install manually my own package I built previously, to add it into the current rootfs Oct 15 10:47:45 I have copied my rpm file onto my board already Oct 15 10:47:49 On a rootfs on a running system (like on a board that's sitting on your desk), or are you trying to create a rootfs image with your package? Oct 15 10:48:24 jofr, rootfs on a running system Oct 15 10:48:38 So if you're just trying to install an RPM onto a single board, then you do (as the manual says) rpm -i packagename.rpm Oct 15 10:48:51 ok Oct 15 10:49:42 But keep in mind, what you're doing is just gaining more and more software-debt. You will have to write all of this into recipes eventually if you intend to do this for another board. Oct 15 10:50:42 Ok, I did. But it's weird. I issued the command and it returns right away to the command line. I don't see any messages on screen. Is that normal? Oct 15 10:51:04 I have no idea. Haven't used rpm for more than a decade. Oct 15 10:52:08 My guess is that if it didn't report any errors, it worked. Oct 15 10:53:25 Think of the tool "rpm" in the same way as "dpkg" on Debian-based systems. Apt is a system on top of dpkg, just as there do exist systems on top of "rpm", such as Yum and DNF. Oct 15 10:53:54 hmm, looks like it works, but I'm not sure Oct 15 10:54:37 when I do rpm -i mpackage.rpm a second time, it reports my package is already installed Oct 15 10:54:48 Ok Oct 15 10:54:56 Is the stuff you meant to install there? Oct 15 10:57:43 Normally, when one requires a package to be installed, one tends to know what problem that package is supposed to solve. Is you problem solved? Oct 15 10:58:43 Yep, looks like it's all there. I guess it's a success :) Thanks jofr Oct 15 10:59:24 In my case, I only need to add in a new application Oct 15 11:02:28 learningc: Great! :-) But I would suggest you become more familiar to working with a Linux-system, it's internals, the command-line, management and get to know where to find documentation. Because there does exist vast amounts of documentation for all of this. :-) Oct 15 11:28:14 New news from stackoverflow: How to setup SPI Driver for Yocto Oct 15 12:08:17 Has anyone run into an issue where CMake 'find_program' cannot locate a -native package (like sed)? Oct 15 12:11:39 tgoodwin: most trivial reason would be that you do not explicitly DEPEND on it, and therefore it does not show up in the recipe specific sysroot Oct 15 12:32:00 Ello... Something interesting just happened to me. I'm on an Ubuntu 16.04 build machine (updated to today) and doing some benchmark builds using a clean clone yocto 2.5.1. (Im trying to look at the impact of disk performance on build time planning a new build machine). Ive done two test builds of core-image-sato, one on a NVMe drive and one on a 2.5" samsung ssd. Both completed OK. I'm now building on a old 2.5" Oct 15 12:32:00 SSHD (hybrid) and about 2/3rd of the way through it causes X/unity to crash and burn...! Has anyone experienced anything similar before? I thought it was a really odd thing to happen so Ive replicated the build a couple of times and it's consistent... Oct 15 12:36:00 no_such_user: only thing that comes to mind is OOM kicking in Oct 15 12:37:47 LetoThe2nd: I don't see the OOM Killer logging anything in syslog... Oct 15 12:38:24 no_such_user: ok Oct 15 12:38:27 first thing in syslog is : Oct 15 12:38:36 org.a11y.atspi.Registry[2904]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" Oct 15 12:38:44 org.a11y.atspi.Registry[2904]: after 16853 requests (16853 known processed) with 0 events remaining. Oct 15 12:54:59 LetoThe2nd: it's in my recipe's DEPENDS, but I just realized hasn't been getting installed into the recipe-sysroot-native. Oct 15 12:55:26 (since it's part of ASSUME_PROVIDED) Oct 15 12:56:45 LetoThe2nd: patching the line to set the variable to simply "sed" works, but it left me wondering if maybe there was a better solution. Oct 15 13:02:12 hi, I type bitbake u-boot, but the binary is not getting generated, why is that? Oct 15 13:02:37 I was expecting it appearing in tmp/deploy/images/$foo Oct 15 13:04:02 images is for images, u-boot doesn't build an image but packages Oct 15 13:05:18 lpapp: expanding on rburton's answer, your packages get built in tmp/work (WORKDIR) depending on architecture, etc. Oct 15 13:05:47 (sorry, WORKDIR for clarity includes your package so tmp/work/arch/package/version) Oct 15 13:05:57 is this true Oct 15 13:06:29 I used to have u-boot*.bin generated there long time ago... have any recent yocto releases changed this operation Oct 15 13:06:45 It's likely off in your work directory. Oct 15 13:06:52 u-boot is definitely not a package Oct 15 13:06:57 you flash the binary over tftp, or whatever Oct 15 13:06:58 Once you bitbake an image recipe, it'll get staged to your image. Oct 15 13:07:00 serial flasher, etc Oct 15 13:07:06 it has nothing to do with ipk or any kind of packages Oct 15 13:07:28 u-boot is a bootloader Oct 15 13:07:36 it has no concept of package at that low level at all Oct 15 13:08:18 for a package, you need to have an OS that understand packages, but a bootloader comes before any such OS Oct 15 13:12:15 "Package" perhaps is a bit overloaded. I get what you're trying to say, but what we're getting at is still the same. You're basically doing "bitbake " and typically the name of the recipe is also the package name. PN Oct 15 13:12:23 https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-PN Oct 15 13:12:37 So in that definition, U-boot is a package. Oct 15 13:12:42 I do not follow Oct 15 13:12:53 I used to get the u-boot binary in the aforementioned location after building the image Oct 15 13:13:02 Correct, _after_ building an image. Oct 15 13:13:07 why am I not getting it now? Has this logic changed with any recent Yocto release? Oct 15 13:13:13 You stated you were running "bitbake u-boot" -- u-boot is not an image definition. Oct 15 13:13:14 I have built an image Oct 15 13:13:17 no Oct 15 13:13:24 I have also built foo-core-image Oct 15 13:13:31 which builds my rootfs Oct 15 13:14:01 Is your MACHINE set? Does your machine have IMAGE_BOOT_FILES set with u-boot.bin? https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-IMAGE_BOOT_FILES Oct 15 13:14:36 has this logic changed recently Oct 15 13:14:40 recently, as in last five years Oct 15 13:14:49 we were stuck with daisy before now going to m... Oct 15 13:15:48 lpapp: it changed in k or m, as people tended to abuse/misinterpret the deploy dir :-) Oct 15 13:16:09 it got bitten by it too, but hey. another thing learnt Oct 15 13:16:23 ok, so let me check that machine thing Oct 15 13:17:03 MACHINE is not set Oct 15 13:17:10 MACHINE_ARCH is Oct 15 13:17:47 Chances are not having MACHINE set is part of the key since that's going to globally define what all gets setup for the boot files vs. the root file system. Oct 15 13:17:48 output of bitbake -e foo-core-image | grep ^MACHINE: https://paste.kde.org/pcm9vwnxj/cpsduo/raw Oct 15 13:18:38 heh yeah, it was DEPLOY_DIR versus IMGDEPLOYDIR Oct 15 13:20:04 sorry, MACHINE is set via ./conf/local.conf.sample Oct 15 13:20:09 MACHINE ?= ... Oct 15 13:20:16 but bitbake -e would not see it? Oct 15 13:21:00 That would only set it if it was the template for your actual build/conf/local.conf Oct 15 13:21:20 yes, it is Oct 15 13:21:37 my build/conf/local.conf gets that Oct 15 13:23:35 bitbake -e foo-core-image | grep ^IMAGE_BOOT_FILES -> returns empty Oct 15 13:23:38 is that the issue Oct 15 13:24:49 I actually do not believe that u-boot is a boot file for the image Oct 15 13:25:01 it sounds more like uImage or zImage, etc, that would be a boot file for the image to be honest Oct 15 13:25:10 I am very very confused why u-boot*.bin is not getting generated as it used to Oct 15 13:25:15 please help Oct 15 13:26:00 Well there's a few things. IMAGE_BOOT_FILES only indicates what is expected to be pulled together from the images directory to make your boot partition Oct 15 13:26:17 The EXTRA_IMAGEDEPENDS is what I tend to use (and see used) as a way to indicate what packages get built for a given machine. Oct 15 13:26:52 (i.e., I usually see it set in the machine def'n, and those recipes end up having to explicitly install thing into the image staging directory) Oct 15 13:26:53 yes, I have u-boot Oct 15 13:27:02 EXTRA_IMAGEDEPENDS += "u-boot" Oct 15 13:27:11 so what is the problem, why is the bootloader image not getting generated? Oct 15 13:28:33 I get this WARNING: /home/lpapp/Projects/polatis/nicbuild/poky/../meta-polatis/recipes-bsp/u-boot/u-boot_2017.01.bb.do_install is tainted from a forced run Oct 15 13:28:46 I wonder whether that could be a contributing factor for it not getting generated Oct 15 13:29:17 and if so, how could I avoid that, clean build only? Oct 15 13:29:32 Well, if you ran bitbake with the force flag, you'll get that. Oct 15 13:30:07 yes, but is that the reason for this not getting generated in the right place? Oct 15 13:30:22 As long as your image has IMAGE_FSTYPES set, you should end up with a tarball, or whatever you've specified, over in that images tmp/deploy/images/machine path. Oct 15 13:30:40 machine? Oct 15 13:30:44 no Oct 15 13:30:54 not tarball, I used to get a .bin file Oct 15 13:31:15 I do get the rootfs image there, but not the bootloader image Oct 15 13:31:17 what is going on Oct 15 13:32:03 The bootloader image, like u-boot.bin, is going to be in the recipe's work directory until you bake an image and machine combination that requires pulling those files together into the images directory. Oct 15 13:33:22 ok, so the question is the same: why is the u-boot*.bin file not getting into ./tmp/deploy/images/machine after building the image while the image is? Oct 15 13:34:43 I guess I will have to try a brand new clean build if no idea... Oct 15 13:35:17 in which case I will only see the result in about an hour Oct 15 13:35:44 The u-boot.bin should get pulled into the image directory as long as the machine depends on it. Oct 15 13:36:12 You've shown that MACHINE is not defined, so that seems to be the top-level issue. Oct 15 13:36:59 "as long as the machine depends on it" -- what I mean is that EXTRA_IMAGEDEPENDS variable being set, really, somewhere to include that file. Oct 15 13:37:01 MACHINE ?= is in my ./build/conf/local.conf Oct 15 13:37:06 so why would it not be defined Oct 15 13:38:11 If it's actually defined, even weak like that globally, it should have come out when you ran "bitbake -e" against any recipe, since it would have been globally set. Oct 15 13:39:47 ok, so what is the next step to do? Oct 15 13:43:18 It sounds like the problem is environmental. If I'm off the rails a bit, I'm sure one of these more proficient folks will jump in, but that's the dots you're trying to connect. Typically, I define my machine (hard set, MACHINE=) in my local conf, or export the variable. That definition then has EXTRA_IMAGEDEPENDS against a recipe (or virtual name), and I identify an output file in IMAGE_BOOT_FILES. Since you' Oct 15 13:43:18 re using u-boot (assuming standard recipe), it should handle staging files, I would think. I mean, there are a few other U-boot environment variables defining things like what boot loader to use from U-boot, but that's going to depend again on your particular configuration. Oct 15 13:44:01 If your'e not using a standard machine, maybe compare notes against an existing one from meta-intel or meta-yocto-bsp? Oct 15 13:44:06 *you're Oct 15 13:44:41 not sure standard u-boot, as we need to adopt it for our own board Oct 15 13:44:49 but it is two patches off of 2017.01, I believe Oct 15 13:44:58 but it used to work ok Oct 15 13:46:35 "standard" I mean one of the recipes-bsp/u-boot/u-boot_???.bb recipe from meta, for example. Oct 15 13:46:48 oh, no, nah Oct 15 13:46:54 we have to grab it from our source url, etc. Oct 15 13:51:33 lpapp: IMO, in most cases you shouldn't have to be doing any extreme changes to your u-boot, so having your image depend on u-boot, and creating a .bbappend with your patches should suffice..? Maintaining a whole fork of something like u-boot probably ends up being more painful. Oct 15 13:52:50 s/image depend on u-boot/machine depend on u-boot/ Oct 15 13:52:59 no, we do not want to use .bbappend for patches as that is a mess Oct 15 13:53:27 when I need to adjust u-boot for further hardware changes, I want to have a version controlled checkout of u-boot myself, and not inside some buildsystem, but cleanly. Oct 15 13:53:34 I'm arguing that what you're doing is an even bigger mess. But that's fine. :-) Just my opinion. :-) Oct 15 13:53:41 there is not much painful about a dedicated topic branch for our board at all Oct 15 13:53:45 pain* Oct 15 13:53:54 what would be painful about it really? Oct 15 13:53:56 Ok :) Oct 15 13:54:07 If anything, it is less painful because I can check out master or any release branches right away there easily Oct 15 13:54:16 I can merge changed from master and release branches to my board branch, etc. Oct 15 13:54:58 my development workflow should not depend on a specific arm buildsystem workflow Oct 15 13:55:10 my buildsystem workflow for a particular board ought to depend on my development workflow Oct 15 13:55:28 buildsystem is subordinate or downstream to the actual source, which is considered upstream Oct 15 13:55:58 also, if we switch away from Yocto, the thing should still contain everything we need, so the extra stuff is not Yocto specific Oct 15 13:56:40 lpapp: painful because if you can just bbappend the oe-core recipe with your small patch (which is being upstreamed anyway, right?) then you get all the behaviour the rest of the image classes expect. if you have your own recipe then you have to maintain the integration: either ensuring the image<->bootloader glue is correct for your recipe, or ensuring your recipe matches the core u-boot recipe's behaviour Oct 15 13:57:04 it is not small patch in the first place Oct 15 13:57:06 of course you can package a fork but building the code is a tiny piece of the problem Oct 15 13:57:19 and even if it was, the above principles would rightfully justify what I am doing Oct 15 13:57:33 not upstream, not right, wrong Oct 15 13:57:49 these are very specific vendor changes, not really useful for upstream, so it will not be upstreamed Oct 15 13:58:15 the image-bootloader glue has been working for five years, really Oct 15 13:58:53 and the fact that where I am pulling the source from should not make a different in terms of whether the image is generated or not Oct 15 13:58:56 surely Oct 15 14:00:08 Sure. That's one way of doing it. Please feel free to continue to do so. :-) It was just meant as a suggestion and didn't really have anything to do with your problem. :-) Oct 15 14:03:47 Normally the machine definition includes those dependencies, as not all machines depend on u-boot (qemu for example). So if you make sure your machine EXTRA_IMAGEDEPENDS has a reference to your u-boot recipe, you should be good. But that means you have to build for a specific machine by defining the MACHINE variable, either in your local.conf or as an environment variable. Oct 15 14:08:47 all done Oct 15 14:10:33 And your u-boot recipe inherits deploy and has deploy-steps? Then you should get your files after you bitbake your recipe - or an image for your machine. Oct 15 14:14:03 u-boot.inc inherits deploy Oct 15 14:14:40 and it has do_deploy, yes, it is basically the standard file Oct 15 14:14:42 Do you have your own? Or are you using the one from poky? Oct 15 14:15:00 no and no Oct 15 14:15:06 I copy it from poky to my layer, I think Oct 15 14:15:10 Ok Oct 15 14:18:21 Side note: It might be less work if you don't duplicate the recipes, but rather create a .bbappend that overrides the SRC_URI and SRCREV with your ownþ Oct 15 14:18:58 In any case. Did you work? Oct 15 14:19:03 s/you/it/ Oct 15 14:21:51 jofr: yes, we could possibly do that, maybe. Oct 15 14:34:17 what is usually the problem when recipes install files with the uid of the user running bitbake? Oct 15 14:35:05 I get it on fairly basic stuff, like util-linux. building rocko. Oct 15 14:50:38 zagor: If I remember right, I see this if I'm not building under my home directory and/or not prefixing new tasks with fakeroot. But that's for things I'm modifying/creating, not existing things. Oct 15 14:51:18 zagor: so for example, if I add a new task to follow after install with more installation, I define the task: "fakeroot do_something_else() { ... }" Oct 15 14:51:57 yeah these are all stock recipes, just my own distro and image. I'm puzzled. and it seems to happen more when I enable systemd. Oct 15 14:52:30 zagor: don't get me started on systemd ;-). Spent the better part of a week and a half just trying to get it to work in an initrd. Oct 15 14:53:10 It goes straight to the multi-user rather than switch-root target no matter what I do. Oct 15 14:53:15 (rocko) Oct 15 14:53:46 hehe. I got it working fine after manually patching the uids, but I'm not sure I'm going to go that route anyway. Oct 15 14:56:48 hmm, on my tiny sysvinit build I only get the uid leak on /etc/ssl/openssl.cnf. Oct 15 14:58:20 cleaning openssl didn't help and, interestingly, didn't warn either. is that file owned by some other recipe? Oct 15 15:00:16 can I somehow do the equivalent of "dpkg -S /etc/ssl/openssl.cnf" ? Oct 15 15:13:23 u-boot*.bin was generated properly after a clean build Oct 15 15:24:17 isn't there an easy way to set a recipe's PV from git-describe ? there's a kind of chicken-egg problem somewhere :} Oct 15 15:28:09 yann: not PV, but there is bbclass for setting PKGV Oct 15 15:28:17 zagor: I would love to hear how the UIDs helped with systemd initramfs. I had to patch in /etc/initramfs-release in order for systemd to acknowledge/announce in the log that it was in an initramfs. Even then, changing the link for the default target (even up in /etc/...) didn't cause it to behave according to the docs. Oct 15 15:28:36 zagor: As for the other question, have you tried oe-pkgdata-util find-path? Oct 15 15:28:54 (to look up if that file is provided by something else) Oct 15 15:28:58 yann: see gitpkgv.bbclass gitver.bbclass in meta-oe layer Oct 15 15:32:44 thx JaMa Oct 15 15:55:57 Hello, I need to cross compile python2 packages using openembedded sdk. The sdk resulting package contains only python 3.5.3 (in older version it contains also python 2.7.3). Is there a way to add also this native python version to my sdk? Oct 15 16:20:10 can we claim Fedora-28 as a sanity tested distro for 2.6 release? Oct 15 16:26:21 I see we have been building on it for releases.. seems reasonable to update it Oct 15 18:41:38 moved DL_DIR to a directory contains already downloaded packages, but I can't fetch some repos, "cleansstate or cleanall" doesn't work either, moving back or creating a fresh DL_DIR works fine, anybody have idea? Oct 15 18:53:29 xtron: bit hard to help with just "can't fetch". what's the actual error? Oct 15 19:03:29 rburton: do_fetch fails, "can't fetch from any source" https://pastebin.com/MWmvyjhC Oct 15 19:14:40 fatal: remote origin already exists. Oct 15 19:14:44 bug in the fetcher Oct 15 19:15:02 go and delete the linux-mel.git folder from downloads/ Oct 15 19:15:23 presumably the fetcher crashed and left the dldir in a bad state Oct 15 19:15:29 filing a bug with that log would be useful Oct 15 19:56:45 rburton: even that didn't help, error is persistent with these changes, Oct 15 19:57:09 xtron: you probab;y failed to delete the right folder. did you look in DL_DIR/git2/? Oct 15 19:58:19 rburton: yes it delete the relevant remote there too, Oct 15 20:03:23 rburton: finally working, there was a directory left, in git2/, thanks Oct 15 20:05:38 a bug would be useful, it shouldn't be so fragile obviously Oct 15 21:29:52 using the esdk, is there a convenient way to create+add a layer? (a la "bitbake-layers create-layer ..." "bitbake-layers add-layer ...") Oct 15 22:25:53 RP: i'm playing with the new AB, what is the right way to set SSTATE_DIR, i tried to modify ~/yocto-autobuilder-helper/config.json but looks like the worker is cloning the upstream git repo Oct 15 22:27:22 has anyone here used the se-linux layer? The wrappers it creates for busybox break login shell activation Oct 15 22:28:02 specifically something like exec("/bin/sh", "-sh") is supposed to be equivalent to exec("/bin/sh", "sh", "-l") Oct 15 22:28:25 and typically busybox installs as soft-links to the /bin/busybox executable Oct 15 22:28:32 eg /bin/sh -> /bin/busybox Oct 15 22:28:51 but se-linux has a bbappend for busybox which replaces those links with links to shell script wrappers Oct 15 22:29:17 so arg[0] doesn't make it to the invocation of busybox properly Oct 15 22:30:30 alimon, where every you want Oct 15 22:30:56 somewhere common if you have more than one worker Oct 15 22:34:10 armpit: yes i modifed to set a home folder atm Oct 15 22:34:23 i have the worker and controller in the same machine so np Oct 15 23:01:41 I'm building a poky based OS image that targets a standard PC and uses the meta-intel layer. I used devtool to create a Linux kernel patch, which added recipes-kernel/linux/linux-intel_4.14.bbappend to my layer, however it appears that the Linux kernel patch is not being applied when I clean and rebuild my primary recipe or when I explicitly rebuild "linux-intel". What might I be doing wrong? Oct 15 23:13:09 Never mind. It seems that I had to manually delete "tmp/work-shared/intel-corei7-64/kernel-*". Apparently bitbake -c cleanall linux-intel didn't delete everything. Oct 16 01:00:54 New news from stackoverflow: New Yocto Recipe Builds but Work Directory is Deleted after Compilation Oct 16 01:14:34 Is there any pppd support in Yocto? Oct 16 01:28:26 learningc: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=ppp Oct 16 01:48:30 what's the best way to terminate a runqemu (sumo, qemuarm specifically)? doing a "reboot" or "shutdown -h now" in the VM doesn't stop it Oct 16 01:54:54 ^a x is how i usually do it, shuts down qemu Oct 16 02:05:58 hello, is anyone available to chat? Oct 16 02:21:24 kergoth: +1 Oct 16 02:22:32 tlwoerner: I am trying to flash a new firefly rk 3388 board and flash utilities are not recognising the image, do you know if I need ot flash some special kind of firmware/bootloader first ? Oct 16 02:23:33 khem: s/3388/3399? Oct 16 02:26:15 khem: when i get a rockchip board, the first thing i do is put it into MASKROM mode and delete the first couple blocks of the eMMC. this lets me work with the device via SDcard, which i find easier Oct 16 02:26:27 sorry 3288 Oct 16 02:26:51 tlwoerner: I see Oct 16 02:27:10 tlwoerner: can I erase these blocks otherwise ? Oct 16 02:27:17 of MASKROM is the only option Oct 16 02:27:40 it also lets me work with the board without having to use a pre-compiled binary application Oct 16 02:28:13 MASKROM is the only way, putting it into RECOVERY mode only lets you access certain parts of the eMMC Oct 16 02:28:26 I see Oct 16 02:28:44 which tool are you using? upgrade_tool? rkdeveloptool? Oct 16 02:28:54 but this means one would need serial connection Oct 16 02:29:07 I am using rkdeveloptool Oct 16 02:29:56 no sorry its upgrade_tool* Oct 16 02:30:33 tlwoerner: I am not interested in wiping out everything, its ok if I can install my own kernel + rootfs Oct 16 02:30:48 any good way to do that alone Oct 16 02:31:09 I am able to upgrade kernel ok Oct 16 02:31:24 so want to find out a way to upgrade rootfs Oct 16 02:32:41 okay, using upgrade_tool should work Oct 16 02:32:53 (i'm just looking through my notes...) Oct 16 02:44:45 upgrade_tool is not happy with the gpt image Oct 16 02:45:01 tlwoerner: which image is meant for upgrade_tool Oct 16 02:45:17 it can download ubuntu.img fine Oct 16 02:46:39 khem: the output from https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/classes/rockchip-update-img.bbclass is usually what's used for upgrade_tool, but looking through it, i only see kernel stuff Oct 16 02:47:08 maybe the ext4 is just dd'ed raw? Oct 16 02:47:29 like i said, i usually just don't bother with the eMMC and create whole images for the SDcard Oct 16 02:47:43 #linux-rockchip might help Oct 16 02:50:03 are you using the upgrade_tool's DI command? Oct 16 02:51:27 tlwoerner: whats difference between *-boot.img and *-gpt.img Oct 16 02:51:40 yes di cmd Oct 16 02:53:49 *-gpt.img is one file containing all the parts needed to boot a rockchip from start to finish (pre-u-boot, u-boot, kernel, kernel-cmdline, rootfs) all munged just the way a rockchip expects it Oct 16 02:54:00 i'm not sure what a *-boot.img is? Oct 16 02:54:50 oh... Oct 16 02:55:10 boot.img is the output of mkbootimg which includes the kernel and ramdisk Oct 16 02:58:13 i.e. just one part of a full gpt file Oct 16 02:58:16 tlwoerner: so gpt.img is one which I can use with upgrade_tool uf ? Oct 16 02:59:13 khem: hmm, not sure. like i said, i dd the gpt.img to an SDcard, and that's all i need Oct 16 02:59:22 ok DI <-p|-b|-k|-s|-r|-m image> Oct 16 02:59:26 which one is for rootfs ? Oct 16 02:59:45 i'm not sure if a gpt is aka firmware **** ENDING LOGGING AT Tue Oct 16 02:59:59 2018