**** BEGIN LOGGING AT Wed Aug 23 03:00:01 2017 Aug 23 13:56:01 Hi ed21: I'm in a situation where I'd like to specify in a .wks file the full partition path (not-boot and not-root) in /etc/fstab. Think of a board with two microSD slots, if I use "--ondisk mmcblk0" the image will work in only one of the two slots. Using "--ondisk disk/by-label/label" won't work, as wic appends the partition number. Do you have any suggestion? Aug 23 13:57:26 One option is to skip automatic fstab entry generation by not specifying ondisk parameter, but if you have any smart suggestion they're welcome. Aug 23 14:12:09 GM everyone! Aug 23 14:12:39 Im tying to disable IPv6 in my image. It looks like you can add DISTRO_FEATURES_remove = "ipv6" to your local.conf. Aug 23 14:12:45 Is it really that simple? Aug 23 14:13:15 tcpdump: you can establish that by checking what that distro feature actually does :) Aug 23 14:13:40 tcpdump: grep is your friend Aug 23 14:14:09 kanavin: Im sort of figuring this out as I go... Aug 23 14:14:13 Sorry for the ignorance. Aug 23 14:30:54 tcpdump: the intention of DISTRO_FEATURE was more to enable it since it was not default in olden days in many packages Aug 23 14:31:23 tcpdump: Even if you disable it does not mean that it will explicitly make your image IPV6 free Aug 23 14:46:09 khem: not really, if you disable it, kernel's ipv6 module will not anymore be installed Aug 23 14:46:34 I guess that pretty much makes ipv6 unavailable :)= Aug 23 14:53:35 So what's the best/right way to disable ipv6? Aug 23 14:54:03 I have a weird bug in my SoC that seems to cause nmcli to drop the connection over WiFi. Aug 23 14:54:11 And it seems ipv6 related. Aug 23 14:54:19 So I was wanting to test removing it. Aug 23 14:55:23 tcpdump: why don't you first try and see if removing ipv6 from DISTRO_FEATURES helps? Aug 23 14:55:51 hi ... is there a way to checkout git repos needing user auth via a recipe .. and where would the auth data need to be provided? Aug 23 14:57:09 mdnneo: multiple options. easiest is ssh with an agent, but you could use an auth helper instead if you want to enter it on the fly Aug 23 14:58:08 kergoth: ssh not sure if I can do this in this network (don't ask) ... would it work via https and .netrc? Aug 23 14:58:35 that should work, yeah, git uses curl, which iirc obeys netrc Aug 23 14:59:14 would be nice if this was more consistent and coherent, but it's tough since bitbake calls a bunch of different underlying tools depending on the particular fetcher involved, and you'd need to make sure the info is passed along safely.. so we just configure the underlying fetch tools instead, basically Aug 23 15:03:17 kanavin: good point, but its not definitive, one can include the mode using kernel-modules dependency if one wants to include all kmods Aug 23 15:04:24 yeah .netrc is what works reliably Aug 23 15:18:45 hello has anyone used meta-raspberrypi for a custom rpi3 build? Aug 23 15:19:28 i am trying to get uart and spi going for a custom rpi3 build using meta-raspberrypi, not sure how to get uart or spi working or where to start... Aug 23 15:27:05 are you guys planning to automatically remove all blacklisted recipes at the start of a dev cycle as a result of the discussion at https://patchwork.openembedded.org/patch/137573/? I'm asking because I found a recipe in meta-openembedded in which all its dependencies are fixed but it's still blacklisted probably because nobody updated it Aug 23 15:27:17 PNBLACKLIST[xorg-fonts-100dpi] ?= "Runtime depends on blacklisted font-adobe-100dpi - the recipe will be removed on 2017-09-01 unless the issue is fixed" Aug 23 15:27:38 probably just an oversight, should email about it or submit a patch Aug 23 15:27:58 I'll send a patch to unblacklist it, but my fear is that if there are other recipes like this which might get removed instead of unblacklisted Aug 23 15:28:53 if no one cares enough about them to make sure they don't, i doubt anyone will care if they go away :) worst case they can be brought back, they're still in git history Aug 23 15:28:55 * kergoth shrugs Aug 23 15:29:25 ok Aug 23 15:30:04 it's a valid concern, obviously, but there are a hell of a lot of recipes in the meta-oe layers and very few people to maintain them. resource availability is a big issue Aug 23 15:45:51 should i use IMAGE_INSTALL_append = or IMAGE_INSTALL_append += Aug 23 15:46:00 zarzar: There's #raspberrypi they might be able to get you started. Aug 23 15:46:32 zarzar: better to use the former and manually make sure the space separator is in place, to avoid confusion Aug 23 15:46:49 yea i'll check out #raspberrypi, it requires a login though, i'm lazy, didn't want to go through login auth process Aug 23 15:47:03 kergoth ? Aug 23 15:47:25 yes? Aug 23 15:47:36 kergoth is IMAGE_INSTALL_append only used in local.conf? don't i need to use +=? Aug 23 15:47:46 i don't understand the question Aug 23 15:47:51 += if it is used elsewhere? Aug 23 15:47:54 irrelevent Aug 23 15:48:02 _append isn't part of the variable name Aug 23 15:48:04 it's an operator Aug 23 15:48:06 i donut understand Aug 23 15:48:08 _append is already cumulative Aug 23 15:48:16 oh ok cool, good to know Aug 23 15:48:16 by definition it doesn't overwrite anything existing Aug 23 15:48:32 i thought it would operate like IMAGE_INSTALL Aug 23 15:48:44 but was just named append for clarity Aug 23 15:48:47 https://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#appending-and-prepending-override-style-syntax Aug 23 15:49:21 no, there's already an explicit new variable for the user to add to IMAGE_INSTALL without having to muck with spacing and postponed append/prepend, see CORE_IMAGE_EXTRA_INSTALL Aug 23 15:50:17 ok cool Aug 23 15:50:38 what's the diff between distro features append and image install append? Aug 23 15:51:01 some tutorials have same features listed in both Aug 23 15:51:07 they're two completely different variables with completely different purposes and semantics Aug 23 15:51:11 not related at all Aug 23 15:51:24 one installs binary packages into an image, one controls overarching features that changes how recipes are built Aug 23 15:51:38 the former has package names, the latter has words that enable features for the distro, like 'opengl', or 'ipv6' Aug 23 15:51:48 erm, the other way around, but you get the point Aug 23 15:52:01 both are documented in the yocto project reference docs, search for the variable name Aug 23 15:52:03 hmm ok i'm not at the point in the learning where that makes sense Aug 23 15:52:16 i don't know how to explain it any clearer than that Aug 23 15:52:28 'bash' is a package, something you can install into a rootfs, that would go in IMAGE_INSTALL Aug 23 15:52:38 ok that makes sense Aug 23 15:52:46 'opengl' enables/disables configuration options in a variety fo different recipes, and adds new dependencies, etc Aug 23 15:52:47 image install is for packages in rootfs Aug 23 15:52:57 by definition, yes Aug 23 15:53:01 'install' into an 'image' Aug 23 15:53:20 distro features is for configuration of recipes? Aug 23 15:53:29 i just said this Aug 23 15:53:36 i'm not going to start repeating myself Aug 23 15:53:43 https://www.yoctoproject.org/docs/2.3.1/mega-manual/mega-manual.html Aug 23 15:53:57 https://www.yoctoproject.org/docs/2.3.1/mega-manual/mega-manual.html#usingpoky-extend-customimage-localconf Aug 23 15:54:10 https://www.yoctoproject.org/docs/2.3.1/mega-manual/mega-manual.html#var-DISTRO_FEATURES Aug 23 16:21:59 Hi everyone, I work on OpenBMC. Do you plan applying https://lists.yoctoproject.org/pipermail/yocto/2017-April/035863.html for morty? I see that elfutils-0.166 fallthrough warnings are fixed in morty-next, but this analogous fix for elfutils-0.148 is unapplied yet. It breaks OpenBMC compilation on Arch and Fedora Aug 23 16:31:53 hi i am out of disk space due to yocto, how do i reclaim space? Aug 23 16:32:16 remove tmp and rebuild Aug 23 16:32:25 ok Aug 23 16:33:31 wow its like 90GB Aug 23 16:33:45 105 GB actually Aug 23 16:33:55 how do i prevent that accumulation Aug 23 16:34:02 rm_work Aug 23 16:36:01 son of a.. going to have to rethink this gitsm problem. i was hoping this would do as a stopgap measure, but i don't think that will do.. Aug 23 16:36:14 was hoping nto avoid rewriting the damn thing until after this release at least Aug 23 16:49:00 i was going to alter GitSM's needs_update() ipmlementation so it'd run download() not just if the srcrevs are missing, but also if the modules in modules/ don't line up with .gitmodules, but that only works if there's no conflict there.. if the same url is referenced with multiple branches in a given SRC_URI, and those branches use different urls for the same submodule, it wouldn't be possible for the modules dir in the clonedir to simultaniously be Aug 23 16:49:00 correct for both Aug 23 16:50:13 guess i could punt and not support the case where there's a conflict, just re-run download() if the current branch gitmodules don't line up with the current git repo modules.. but then we'd just hit a different proble if multiple recipes both fetch submodules from differetn branches of that repo at the same time, so it'd also have to change the clonedir to include the branch name.. but that wouldn't be enough either, if the modules change within a Aug 23 16:50:13 branch for different srcrevs.. it's just a lost cause Aug 23 16:50:19 time to start on the rewrite **** ENDING LOGGING AT Thu Aug 24 03:00:00 2017