**** BEGIN LOGGING AT Tue Oct 29 03:02:49 2019
Oct 29 07:57:58 <lpapp> where rburton
Oct 29 07:58:02 <lpapp> is
Oct 29 07:59:38 <LetoThe2nd> rburtib is here
Oct 29 07:59:39 <LetoThe2nd> not
Oct 29 08:46:40 <lpapp> I am a bit confused by the meaning of $PN
Oct 29 08:53:59 <mcfrisk> lpapp: recipe name, https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PN
Oct 29 08:54:19 <alessioigor> I usually use $BPN.
Oct 29 08:54:20 <lpapp> why is it not RN?
Oct 29 08:54:28 <lpapp> PN would indicate a package name to me
Oct 29 08:56:01 <lpapp> so, I am getting this: ./tmp/deploy/ipk/polatisnic/kernel-3.2.1-r21_3.2.1-r22_polatisnic.ipk
Oct 29 08:56:25 <lpapp> did I understand rburton correctly that if I want to get kernel_3.2.1-r22_polatisnic.ipk, I just have to change KERNEL_PACKAGE_NAME?
Oct 29 08:56:30 <lpapp> to say, kernel?
Oct 29 09:01:19 <lpapp> hah, KERNEL_PACKAGE_NAME was not available in daisy :)
Oct 29 09:02:08 <lpapp> so, yeah, I am looking for the old-fashioned way to set the kernel package names
Oct 29 09:05:28 <lpapp> kernel.bbclass says # kernel-base becomes kernel-${KERNEL_VERSION - just not sure how
Oct 29 09:10:09 <rcrudo> does gitsm implementation of yocto works with https or only ssh?
Oct 29 09:13:53 <wertigon> How do I add a package to my sdk, and only my sdk?
Oct 29 09:14:25 <wertigon> That is, when I type bitbake myimage -c populate_sdk , I get missing package requirements (more specifically, perl).
Oct 29 09:14:35 <Crofton> wertigon, https://github.com/balister/meta-sdr/blob/master/recipes-images/images/native-sdk.inc
Oct 29 09:14:46 <Crofton> does that help?
Oct 29 09:15:15 <wertigon> Could work, I'll try it and see how it goes
Oct 29 09:15:25 <wertigon> Will get back to you soon :)
Oct 29 09:17:15 <Crofton> Works for packages that have build time depends that are not run time, so the image won't have the build depends in an sdk built from the image recipe
Oct 29 09:18:10 <wertigon> Where do I place it, and how is it included? In my regular images folder or?
Oct 29 09:23:46 <wertigon> I'll give it a shot in my regular images folder
Oct 29 09:24:05 <wertigon> And believe in the magic :D
Oct 29 09:28:36 <wertigon> Magic failed me T_T
Oct 29 09:29:10 <wertigon> Ok, so I have the native-sdk.inc file, and I assume I need to include it from somewhere
Oct 29 09:29:35 <wertigon> Or maybe... Ah, of course I just stick it to the base.inc I already have
Oct 29 09:34:07 <wertigon> Ok, hopefully this will work, might need to include more packages than just native-perl but that's just a compile-add-missing-repeat dance :P
Oct 29 09:34:22 <wertigon> Sorry for being a total new
Oct 29 09:34:26 <wertigon> *newb
Oct 29 09:36:34 <wertigon> Nope :/
Oct 29 09:37:36 <wertigon> Error: "nothing provides nativesdk-perl needed by native-sdk-autoconf-2.69-r11.x86-65_nativesdk"
Oct 29 09:38:22 <wertigon> But I added nativesdk-perl to the SDK_EXTRA_TOOLS var...
Oct 29 09:40:20 <wertigon> Why it do this -_-;;
Oct 29 09:55:14 <wertigon> Nope, I turned every angle I could find still nothibng
Oct 29 09:55:16 <wertigon> *nothing
Oct 29 10:05:48 <xtron> building linux-yocto kernel with meta-selinux configured, selinux.cfg is in src_uri but not reflecting/enabled in kernel .config, any idea why??
Oct 29 10:08:23 <yocti> New news from stackoverflow: yocto populate_sdk has lots of warnings: package is not installable <https://stackoverflow.com/questions/58605151/yocto-populate-sdk-has-lots-of-warnings-package-is-not-installable>
Oct 29 10:23:34 <wertigon> Crofton: Any ideas? :(
Oct 29 10:39:53 <rburton> kergoth: you know external toolchains more than me
Oct 29 10:40:14 <LetoThe2nd> xtron: did you check that you actually enabled meta-selinux functionality as pointed out in its README?
Oct 29 10:40:37 <rburton> kergoth: if i'm using an external toolchain, i presume there's no way to put it into images.  e.g. turning on tools-sdk will build its own gcc which is unrelated to the external toolchain
Oct 29 10:43:44 <xtron> LetoThe2nd, yes, required distro_features are appended, preferred providers are set,
Oct 29 10:43:51 <LetoThe2nd> xtron: ok
Oct 29 10:44:21 <LetoThe2nd> xtron: then the next step is to bitbake -e the kernel and see where its being left out.
Oct 29 10:45:40 <xtron> in workdir, kernel-meta contains the kernel configs?
Oct 29 10:46:13 <LetoThe2nd> xtron: why would you go looking there?
Oct 29 10:47:42 <xtron> LetoThe2nd, then where selinux.cfg will show-up in kernel configs?
Oct 29 10:48:16 <LetoThe2nd> xtron: bitbake -e and check that it really shows up in SRC_URI or whereever you *expect* it
Oct 29 10:49:42 <xtron> LetoThe2nd, it's in src_uri file://selinux.cfg
Oct 29 10:50:15 <LetoThe2nd> xtron: thats what you *EXPECT
Oct 29 10:52:33 <xtron> LetoThe2nd, so, where should it be?
Oct 29 10:52:55 <LetoThe2nd> xtron: bitbake -e your kernel target, and search for SRC_URI and its evaluation there.
Oct 29 10:53:00 <xtron> :q
Oct 29 10:53:05 <LetoThe2nd> i think i basically said that three times now.
Oct 29 10:57:02 <xtron> LetoThe2nd, it's the environment value of src_uri
Oct 29 10:57:13 <xtron> ^
Oct 29 11:05:11 <LetoThe2nd> xtron: hum, what?
Oct 29 11:09:12 * alessioigor waves all
Oct 29 11:09:14 <alessioigor> Could someone review my platch (http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288378.html), please? Thanks in advance!
Oct 29 11:09:19 <alessioigor> *patch
Oct 29 11:10:06 <LetoThe2nd> would rather review platches
Oct 29 11:10:57 <xtron> LetoThe2nd, I think the custom image need to add packagegroup-core-selinux
Oct 29 11:15:07 <wertigon> Hmm, further investigations; tried building meta-toolchain, same problem; nothing provides nativesdk-perl
Oct 29 11:22:43 <rburton> wertigon: i'd start chopping bits away until it works.  ie use qemux86 instead of your machine, nodistro instead of your distro, etc
Oct 29 11:26:38 <wertigon> rburton: building the image work just fine, it's when I try to build the SDK / toolchain I receive the error
Oct 29 11:26:52 <rburton> sure
Oct 29 11:27:01 <rburton> because its nativesdk* which is SDK specific
Oct 29 11:27:20 <rburton> so try chopping changes away until it works, to identify what is breaking it
Oct 29 11:28:08 <rburton> the autobuilder builds about 50 SDKs every night, so it works there
Oct 29 11:28:37 <wertigon> Not much to chop away really :/  Hmm, in fact only IMAGE_FEATURES I have is package-management and splash
Oct 29 11:28:45 <rburton> what MACHINE?
Oct 29 11:28:53 <wertigon> target
Oct 29 11:29:06 <rburton> unless you can replicate the failure with a pure poky and qemux86, you've more to chop out
Oct 29 11:29:07 <wertigon> The sitara dev board by TI
Oct 29 11:29:15 <wertigon> Ok
Oct 29 11:29:25 <rburton> right so lets see if we can blame TI: remove meta-ti, set machine to qemux86, see if it still breaks
Oct 29 11:37:21 <wertigon> Hmmmm...
Oct 29 11:37:47 <wertigon> meta-ti provides initramfs
Oct 29 11:38:11 <rburton> meta-toolchain should be fairly isolated from anything else
Oct 29 11:43:27 <wertigon> Ok, I try now with MACHINE=qemux86 meta-toolchain
Oct 29 11:43:45 <wertigon> Sorry, MACHINE=qemux86 bitbake meta-toolchain
Oct 29 11:45:17 <wertigon> This should build everything to compile a a minimal glibc only application if I understand the docs correctly, right?
Oct 29 11:46:03 <rburton> yes
Oct 29 11:55:36 <wertigon> BTW, this is thud branch if that makes much difference
Oct 29 11:59:54 <wertigon> building qemux86 meta-toolchain on my image right now, will try poky after that fails
Oct 29 12:01:09 <wertigon> Keep digging that hole, eventually you'll strike gold...
Oct 29 12:01:12 <wertigon> Or bones...
Oct 29 12:02:33 <wertigon> Or a portal to another dimension filled with creepy tribbles
Oct 29 12:09:45 <rburton> wertigon: meta-toolchain doesn't care for your image
Oct 29 12:09:57 <rburton> an image sdk is 'bitbake myimage -c populate_sdk'
Oct 29 12:10:12 <rburton> bitbake meta-toolchain is just a bare compiler and supporting pieces
Oct 29 12:23:08 <wertigon> rburton: Yeah, so it's really strange I get the same error when I bitbake with meta-toolchain is it not...? :)
Oct 29 12:23:20 <rburton> not at all
Oct 29 12:23:23 <wertigon> Atleast with MACHINE=sitara
Oct 29 12:23:48 <rburton> its the same code, but by doing meta-toolchain you remove the influence of the image itself
Oct 29 12:23:59 <wertigon> Trying MACHINE=qemux86 now
Oct 29 12:51:01 <wertigon> nativesdk-clang takes forever to build :P
Oct 29 12:54:20 <rburton> yes it does!
Oct 29 13:25:18 <rreignier> Hi! Regarding my question, last night, does someone know how to change the kernel location from /boot partition to '/' partition in order to have several rootfs on the same target for updates use case.
Oct 29 13:25:19 <rreignier> I have tried to change "KERNEL_IMAGEDEST" but it has no effect.
Oct 29 14:11:44 <hpsy1> Hello, does the SSTATE_MIRRRORS populate the SSTATE_DIR?
Oct 29 14:14:26 <hpsy> Hello, does the SSTATE_MIRRRORS populate the SSTATE_DIR?
Oct 29 14:14:53 <LetoThe2nd> rreignier: by starting at the code, it *might* be a bug, but i'm uncertain
Oct 29 14:14:59 <LetoThe2nd> hpsy: meaning that?
Oct 29 14:16:22 <LetoThe2nd> rreignier: unfortunately the guy who could instantly tell is kinda unavailable at the moment
Oct 29 14:17:42 <LetoThe2nd> rreignier: but if i run into him i'll ask and report, ok?
Oct 29 14:18:36 <hpsy> I currently define SSTATE_DIR to share SSTATE between different build directories, I am asking if I use SSTATE_MIRRORS will the shared STATE_DIR be updated when a prebuilt is present in the SSTATE_MIRRORS and missing from SSTATE_DIR or will every build workspace grab the prebuilt from my SSTATE_MIRROR?
Oct 29 14:19:23 <LetoThe2nd> hpsy: the latter. (about 90% sure)
Oct 29 14:23:24 <hpsy> LetoThe2nd: Thanks :)
Oct 29 14:30:59 <rreignier> LethoThe2nd Thanks a lot
Oct 29 14:31:08 <rreignier> LetoThe2nd Thanks a lot
Oct 29 14:32:20 <rreignier> But maybe that is not the right way to do what I want to achieve. One kernel per root fs and and the bootloader on a separated partition
Oct 29 14:33:23 <LetoThe2nd> rreignier: well it depends on your platform.
Oct 29 14:33:48 <LetoThe2nd> rreignier: a lot of platforms i know don't have the bootloader visible in the filesystem at all. but i think you mentioned grub, right?
Oct 29 14:34:02 <rreignier> I am on x86-64 (UpBoard so Atom). But for now, I do the tests on qemux86-64
Oct 29 14:34:41 <rreignier> Yes. From my investigation, Grub seems like the recommended bootloader on x86
Oct 29 14:35:02 <LetoThe2nd> rreignier: if you have some form of control over where the EFI starts off, then you could even tuck /boot into the rootfs, no separate partition
Oct 29 14:35:08 <rreignier> Barebox does not seems supproted yet by Yocto (wic) for now
Oct 29 14:37:10 <rreignier> Interesting, but I still need EFI/BOOT/bootx64.efi on the first partition, Isn't it?
Oct 29 14:37:39 <LetoThe2nd> rreignier: you'd need some form of efi binary there, right
Oct 29 14:38:02 <LetoThe2nd> rreignier: but another thing you need to think about is, how will the bootloader decide which rootfs to boot
Oct 29 14:38:21 <LetoThe2nd> especially thinking about the update/broken update situation
Oct 29 14:38:38 <rreignier> I want to use RAUC so it support different bootloader
Oct 29 14:39:24 <LetoThe2nd> rreignier: but then i'd postpone the kernel packaging until you've got the rauc strategy all sorted out
Oct 29 14:40:32 <LetoThe2nd> because if you now spend a lot of time sorting out stuff, and then it turns out that you don't have a shared /boot for example, all that time is waasted
Oct 29 14:41:12 <rreignier> Yes, it is true that I do not know from which end start the problem...
Oct 29 14:41:29 <rreignier> Say I want 3 partitions: /boot, /rootA, /rootA.
Oct 29 14:41:58 <rreignier> As I understand it, I need Grub on /boot and the kernel installed on /rootA and /rootB
Oct 29 14:42:04 <LetoThe2nd> thats what you want and think
Oct 29 14:42:18 <LetoThe2nd> but i'm not sure that this is what fits rauc
Oct 29 14:42:30 <LetoThe2nd> you might want to be able to upgrade grub too, for example
Oct 29 14:42:38 <LetoThe2nd> and then your setup is bound to break
Oct 29 14:43:09 <rreignier> I know that it is a limitation of that scheme, I cannot update the bootloader
Oct 29 14:46:25 <rreignier> Ok, so the EFI path as described here could be interesting: https://rauc.readthedocs.io/en/latest/integration.html#efi
Oct 29 14:47:08 <LetoThe2nd> rreignier: i know. thats why i told you to start with really thinking the whole strategy through instead of just making assumptions.
Oct 29 14:47:10 <rreignier> Is it possible to generate a kernel EFI stub to boot directly from UEFI with Yocto in qemu? I might try that
Oct 29 14:48:58 <LetoThe2nd> no idea
Oct 29 14:50:21 <rreignier> Because from here, it seems that wic only support grub and systemd-boot as bootloader: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source/bootimg-efi.py#n28
Oct 29 14:50:31 <rreignier> I might be OK with systemd-boot
Oct 29 14:51:54 <rreignier> I will have to figure out how and when to call "efibootmgr" in a recipe
Oct 29 14:52:12 <LetoThe2nd> look into it, trhink it through. make an educated decidion instead of geusswork
Oct 29 14:52:24 <rreignier> I don't even know if it is possible actually
Oct 29 14:52:41 <LetoThe2nd> anthing is possible, its only software. just the needed effort varies
Oct 29 14:53:03 <rreignier> :)
Oct 29 14:53:23 <tlwoerner> is it safe to assume the weekly yocto meeting is on hiatus this week?
Oct 29 14:53:34 <tlwoerner> RP: ^
Oct 29 15:00:32 <rburton> yes
Oct 29 15:09:21 <yocti> New news from stackoverflow: how to get ${THISDIR} inside do_unpack_append in .bbappend file <https://stackoverflow.com/questions/58610052/how-to-get-thisdir-inside-do-unpack-append-in-bbappend-file>
Oct 29 15:14:28 <JPEW> RP: Unfortunately, my patch to grab the offending packages from failed reproducible build test had an error: shutil.SameFileError: '/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/build-st-56414/reproducibleA/tmp/deploy/deb/./core2-64/perl-doc_5.30.0-r0_amd64.deb' and '/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/build-st-56414/reproducibleA/tmp/deploy/deb/./core2-64/perl-doc_5.30.0-r0_amd64.deb' are the same file
Oct 29 15:16:23 <JPEW> I can't quite figure out how that happened: it looks like the save_dir is an empty string, which is weird. I probably have some stupid error somewhere... anyway once I sort it out I'll post another patch.
Oct 29 15:17:26 <JPEW> I need to fix up the permissions anyway because the tempdir is rwx------ owned by the pokybuild user on the AB node so I can't see inside it.
Oct 29 15:30:38 <litb> hello folks
Oct 29 15:46:40 <litb> I think my life becomes easier if I specify SYSROOT_DIRS="/", because my installer can then just pick the files from recipe-sysroot, instead of having to build an image first and then somehow loop-mounting untaring it to get onto the files
Oct 29 16:39:39 <yocti> New news from stackoverflow: How to store pyc files with setuptools3 in bitbake recipe in the same way setuptools does? <https://stackoverflow.com/questions/58611684/how-to-store-pyc-files-with-setuptools3-in-bitbake-recipe-in-the-same-way-setupt>
Oct 29 16:51:45 <rburton> litb: no context there but why are you having to loop-mount images or something?
Oct 29 16:51:50 <rburton> total confusion as to what is going on
Oct 29 16:54:03 <litb> rburton, because my installer needs to collect some files (mostly shared-library .dll files) from the built packages. so I would make my installer-recipe dependent on  some image recipe's do_image_tar , and in the installer's do_compile, I would need to untar the image to access the files
Oct 29 16:54:30 <rburton> litb: you could just grab the files from the packages
Oct 29 16:54:32 <litb> rburton, I think that's too complicated. I assume there must be a python API to access the image/ folders of given recipes, to grab files from there
Oct 29 16:54:39 <litb> yeah, exactly
Oct 29 16:54:47 <rburton> no, you misunderstand me.  the packages directly.
Oct 29 16:54:57 <rburton> not build an image and then unpack it again
Oct 29 16:55:21 <rburton> how do you build the installer?
Oct 29 16:55:36 <rburton> why can't it just depend on all the libraries it needs, so they're all in the sysroot
Oct 29 16:55:46 <litb> ah, you mean from the deploy/deb/ folder. I will look into "oe-pkgdata-util find-path" to see how it makes the lookup from path to pkg-name. with that, I could go into the deb-package to pick the wanted file
Oct 29 16:57:10 <litb> rburton, I assume I will have a recipe that builds the installer file (which is Inno Setup), for which I need to have the correct files present rooted at a given path ${root}
Oct 29 16:58:42 <rburton> so either just depending on the pieces to get them in the sysroot might work,  if you need more than the sysroot contains (quite possibly) then easy enough to unpack the packages directly into a staging directory.
Oct 29 16:59:34 <litb> rburton, ah, I see. I have looked into how the do_rootfs does it. apparently there's a python API to create a root filesystem from a given list of packages.
Oct 29 16:59:55 <rburton> an actual rootfs is probably overkill for what you need
Oct 29 17:00:04 <rburton> you don't need a libc for example i presume?
Oct 29 17:00:16 <litb> ah I see, yeah that's overkill
Oct 29 18:35:24 <JPEW> RP: I've updates the jpew/ab-reproducible-test with new patches to fix the problem with capturing the reproducible build results. Please apply them to master-next in place of the previous 2
Oct 29 19:09:51 <apteryx> does using a python library recipe (e.g., python-pytest) means python itself is pulled as a runtime dependency? I've looked at their recipe, but couldn't figure it out.
Oct 29 19:21:17 <rburton> apteryx: the recipe should have RDEPENDS set appropriately
Oct 29 19:22:07 <rburton> it will always depend on python3-core but that's just the interpretter and a *very small* subset of the library
Oct 29 21:08:14 <mischief> hm, shouldn't the kernel class depend on lz4-native for copy_initramfs()?
Oct 30 01:21:31 <toner> Hey guys
Oct 30 01:23:14 <toner> I'm writing a recipe that requires files from a RDEPENDS package- is there an easy way to get to another package's WORKDIR?
Oct 30 01:24:48 <toner> or is it bad form to reference an external WORKDIR?
Oct 30 01:35:10 <toner> Ah- found it in the Yocto docs: 3.3.16. Sharing Files Between Recipes
**** ENDING LOGGING AT Wed Oct 30 02:59:57 2019