**** BEGIN LOGGING AT Tue Nov 01 03:00:02 2016
Nov 01 12:55:25 <binarym> hey all! I'm new at yocto, i'm playing a bit with a rasp pi 2 as an introduction. So i got the meta-raspberry which, using rpi-basic-image target, build a nice basic-image
Nov 01 12:55:41 <binarym> now i'm wondering what is the cleanest way to "extend" this image recipe in my own layer
Nov 01 12:56:47 <binarym> i tried using "include recipes-core/images/rpi-hwup-image.bb" and then adding packages with IMAGE_INSTALL but it doesn't seem to be the good practice ...
Nov 01 12:56:50 <binarym> is it ?
Nov 01 12:57:12 <binarym> (in my own recipe-core/images/myimage.bb)
Nov 01 13:05:01 <rburton> binarym: i'd copy and paste the contents of the image that is close to what you want and then modify it as required
Nov 01 13:05:06 <rburton> editing image_install etc
Nov 01 13:05:08 <CTtpollard> it's common to inherit core images
Nov 01 13:06:35 <binarym> CTtpollard: i tried to inherit rpi-hwup-image, but yocto complained about that
Nov 01 13:06:35 <binarym> and
Nov 01 13:07:04 <binarym> i wonder if inheriting from core image and then, including rpi-hwup-image doesn't broke the whole image
Nov 01 13:07:28 <binarym> right now, my rpi is stucked on a black screen with the 4 raspberry on the top (so kernel boot hanged)
Nov 01 13:07:45 <binarym> i think it's because of a bad splash ... but not sure
Nov 01 13:08:19 <binarym> damn ... i tried a rm -rf build/tmp/ ... looks that it hosted the toolchain too, just got 27Go free :(
Nov 01 13:08:24 <binarym> new question:
Nov 01 13:08:42 <binarym> is there a good way to remove all "target" compiled file but keep the toolchain ?
Nov 01 13:11:44 <rburton> just delete tmp/ and let sstate-cache do its job
Nov 01 13:12:11 <binarym> hmmm
Nov 01 13:12:12 <binarym> ok
Nov 01 13:13:01 <binarym> another (big noob) question: if, after generating a whole image using bitbake i add a .bbappend to my own meta for, for example, squid
Nov 01 13:13:08 <binarym> and then, relaunch the image generation
Nov 01 13:13:37 <binarym> will bitbake/yocto/sstate-cache/<anyone> will detect this little change and rebuild squid ?
Nov 01 13:14:08 <rburton> yes
Nov 01 13:14:09 <CTtpollard> if bitbake parses the append, yes
Nov 01 13:14:37 <binarym> ok
Nov 01 13:14:38 <binarym> so
Nov 01 13:14:45 <binarym> if it doesn't, it's my fault
Nov 01 13:14:56 <binarym> i just have to make sure my .bbappend has been correctly parsed
Nov 01 13:15:55 <binarym> thanks ... and since yocto will be my daily bread for incoming months, nice to meet you ;)
Nov 01 13:16:08 <CTtpollard> bitbake has commands to show you the layers it has available, as well as the appends it is going to apply
Nov 01 13:16:25 <binarym> ok ... i gonna search for it in documentation
Nov 01 13:17:01 <CTtpollard> 'bitbake-layers show-appends'
Nov 01 13:18:35 <binarym> CTtpollard: thanks
Nov 01 13:19:14 <CTtpollard> np
Nov 01 13:20:47 <binarym> ok ... my .bbappend wasn't in the correct place :)
Nov 01 13:21:36 <binarym> hmmm, where is the cross compil toolchain installed ?
Nov 01 13:21:41 <binarym> not under build/
Nov 01 13:21:42 <binarym> ?
Nov 01 13:22:10 <rburton> tmp/sysroots/[your host arch]
Nov 01 13:23:25 <binarym> ok, thanks
Nov 01 14:55:16 * armpit YPTM armin in on
Nov 01 14:56:39 <rburton> oh!
Nov 01 14:57:06 <fray> is it -that- time again?
Nov 01 14:57:10 <rburton> yes
Nov 01 14:57:12 <sjolley1> YPTM:   Ready-Access Number:    8007302996  Access Code:    2705751
Nov 01 14:57:14 <rburton> YPTM ross on
Nov 01 14:57:23 <sjolley1> YPTM: Stephen joined
Nov 01 14:58:14 <armpit> sheesh, the oldman is the only one that can remember.. sad for the younger generation
Nov 01 14:58:15 <fray> YPTM: Mark is on
Nov 01 14:58:47 <rburton> armpit: thanks for implying that i'm part of the younger generation :)
Nov 01 14:59:28 * fray notes if you were not board in the 70's (or before) you are 'younger generation'  ;)
Nov 01 14:59:31 <fray> 'er.. born
Nov 01 14:59:45 <rburton> i was born 78
Nov 01 14:59:56 * fray is not yet working on gray beard hacker.. but it's coming.. ;)
Nov 01 15:00:10 <fray> rburton, ok.. you are only 'kind of old' like the rest of us.. ;)
Nov 01 15:00:21 <vmeson> YPTM: Randy joined.
Nov 01 15:00:46 <armpit> rburton, I am older (born 62)
Nov 01 15:00:58 <fray> armpit, lol that makes you ancient.. (not)
Nov 01 15:01:44 <RP> YPTM: Richard joined
Nov 01 15:02:11 <vmeson> hey, ancient is people who were born in the 50s or earlier...
Nov 01 15:03:17 <sjolley1> I was born in 54.  I am old enough to have kids born in 78
Nov 01 15:04:34 <CTtpollard> pre 90's surely
Nov 01 15:05:14 <fray> sjolley1 lol
Nov 01 15:05:23 <sgw_> YPTM: Saul is on and not quite a grey beard (yet!), it's salt and pepper
Nov 01 15:06:16 <rburton> sgw_: if i let mine grow its mostly pepper with salt bits and the odd bonus orange
Nov 01 15:07:25 <fray> RP -- I agree.. ther other two are much more important
Nov 01 15:13:26 <fray> ya.. is anyone a systemd fan?
Nov 01 15:13:47 <ecdhe> ...yes, love systemd, but haven't configured it on yocto.
Nov 01 15:15:50 <rburton> fray: lots of systemd users here, more than you'd think actually
Nov 01 15:15:54 <rburton> here being OE
Nov 01 15:16:05 <fray> I -use- systemd..  I'm just not a fan of it trying to do everything..
Nov 01 15:16:10 <vmeson> WindRiver Linux has been using systemd as the default init for 2+ years.
Nov 01 15:16:21 <fray> I -am- a fan of a single unified startup and system life cycle management interface..
Nov 01 15:16:28 <fray> I just prefer smaller untilities doing the parts and pieces
Nov 01 15:16:39 <sjolley1> YPTM: It is over.
Nov 01 15:16:50 <ulf`> 16 minute meeting
Nov 01 15:16:53 <ulf`> efficient :)
Nov 01 15:17:32 <kergoth> i just wish a lot of the systemd project components were *separate* projects. i realize many are largely independent even though they're in the same repo, but naming it by systemd and encompassing it in the same project and repo results in a great deal of confusion about what's part of PID 1 and what isn't. we see it as monolithic whether it is or not. there seems to be a lot of NIH going on.
Nov 01 15:17:36 * kergoth needs to play with openrc more
Nov 01 15:17:59 <fray> kergoth, that is certainly part of it
Nov 01 15:18:10 <fray> I'd also like alternatives to be possible for some pieces, and some pieces to run w/o systemd
Nov 01 15:18:14 <fray> (udev)
Nov 01 15:18:36 <kergoth> agreed. they shouldn't be as intertwined as they are
Nov 01 15:18:38 <fray> as I said, I'm not a fan of systemd, but it's currently the best solution that I've seen to the problem
Nov 01 15:18:58 <kergoth> which is made worse by including it in the same project and repo, as adding interdependencies is easy when oyu don't actually see them as separate or test them that way
Nov 01 15:19:10 <fray> yup, exactly my concern
Nov 01 15:19:17 * kergoth glances over at the bitbake python package ..
Nov 01 15:19:34 <fray> unix is popular not beause it's 'better' at things, but because the philosphy of a lot of small things that do a small task 'well' abounds..
Nov 01 15:19:35 <vmeson> huh: "OpenRC is the default init system of Gentoo, Alpine Linux and other Linux distributions..." wikipedia . I didn't know that.
Nov 01 17:02:18 <binarym> how can i know which packages depends on another ?
Nov 01 17:02:28 <binarym> my build failed because python-dbus
Nov 01 17:02:41 <binarym> but i don't need dbus or its python bindings :)
Nov 01 17:05:15 <rburton> binarym: bitbake -g -u depexp [image] will let you browse the dependency tree
Nov 01 17:05:41 <binarym> thx
Nov 01 19:17:06 <Guma> Hello, I just started with Yocto today and got my first image build. I am trying to make further changes. On of the things I want to do is disable root login from shell but not serial and add default user and add him to sudoers.
Nov 01 19:18:14 <Guma> So from what I am reading I can remove debug-tweaks. But besides disabling root with out password what else does this remove if I exclude?
Nov 01 19:19:46 <Guma> Also I am adding EXTRA_USERS_PARAMS to enable default account. Beside useradd I also do groupmod to add this user to sudo. Is that enough?
Nov 01 19:20:45 <Guma> I see that current image I build has %sudo commented out in /etc/sudoers. How can I uncomment this?
Nov 01 20:29:33 <kergoth> suppose i should add support for musl to meta-sourcery, keep forgetting to do that
Nov 01 21:29:44 <binarym> the meta "meta" is part of Yocto base ?
Nov 01 21:33:08 <rburton> binarym: meta/ is openembedded-core
Nov 01 21:42:04 <binarym> rburton: so bug should be opened in openembedded tracking system or yocto's one ?
Nov 01 21:43:17 <Crofton|work> https://github.com/openembedded/openembedded-core
Nov 01 21:43:32 <Crofton|work> poky is just some collection of oe-core + some other "stuff"
Nov 01 21:43:37 <binarym> yep
Nov 01 21:43:57 <binarym> i'm not very familiar with github collaboration stuff
Nov 01 21:44:04 <rburton> whoa there are pull requests and issues there?
Nov 01 21:44:06 <rburton> can we turn that off?
Nov 01 21:44:15 <Crofton|work> heh
Nov 01 21:44:16 <binarym> gonna check if "bug" is in the HEAD and open an issue on bug track
Nov 01 21:44:17 <rburton> binarym: oe-core bugs go to bugzilla.yoctoproject.org
Nov 01 21:44:20 <Crofton|work> no
Nov 01 21:44:32 <Crofton|work> it is really annoying we can't turn it off
Nov 01 21:44:47 <Crofton|work> every now and then jama goes through meta-oe and replies
Nov 01 21:45:11 <rburton> who owns those repos?  at least the description could say its a mirror and don't use the stuff
Nov 01 21:45:31 <neverpanic> you can turn of issues, but not pull requests, afaik
Nov 01 21:45:32 <rburton> oh you can turn issues off
Nov 01 21:45:50 <rburton> yeah just looked at the settings for my own repos
Nov 01 21:45:53 <rburton> thats something at least
Nov 01 21:46:14 <neverpanic> the canonical way to turn off pull requests is to have a bot that will trigger on pull requests, will close them and will post a message telling people where to go with their patches
Nov 01 21:46:18 <neverpanic> welcome to github.
Nov 01 21:46:22 <Crofton|work> lol
Nov 01 21:49:00 * JaMa is that bot
Nov 01 21:49:23 <rburton> JaMa: do you have the power to turn off issues on the oe-core repo?
Nov 01 21:49:39 <JaMa> I don't think so
Nov 01 21:49:40 <rburton> and change the summary to say its just a mirror etc etc
Nov 01 21:49:43 <rburton> aww
Nov 01 21:49:49 <rburton> so who created this repo? :)
Nov 01 21:50:35 <rburton> i can't even see the creator as the member list is private to members only
Nov 01 21:50:40 <rburton> god its like fight club
Nov 01 21:51:06 <binarym> hmm
Nov 01 21:51:15 <binarym> in fact, while "about" to fill the bug
Nov 01 21:51:17 <binarym> i have a doubt
Nov 01 21:51:23 <binarym> since i'm new
Nov 01 21:51:30 <binarym> (in yocto)
Nov 01 21:51:36 <binarym> could someone "verify" it for me ?
Nov 01 21:52:03 <JaMa> rburton: Crofton|work, pb, DarkKnight, ka6sox, cliff are the owners
Nov 01 21:52:16 <rburton> Crofton|work: do my bidding (please)
Nov 01 21:52:27 <Crofton|work> hmm
Nov 01 21:52:28 <Crofton|work> what?
Nov 01 21:53:07 <rburton> turn off issues for that oe-core mirror
Nov 01 21:53:12 <JaMa> Crofton|work: github shows you as owner of openembedded org
Nov 01 21:53:16 <Crofton|work> yeah
Nov 01 21:53:24 <Crofton|work> wikis?
Nov 01 21:53:30 <Crofton|work> do we use that at all?
Nov 01 21:54:09 <binarym> is that DEPENDS_append = " ${@bb.utils.contains('PTEST_ENABLED', '1', ' dbus', '', d)}"
Nov 01 21:54:14 <binarym> true "as default" ?
Nov 01 21:54:17 <Crofton|work> I can't turn off al the merge settings
Nov 01 21:54:21 <binarym> i mean, PTEST_ENABLED ?
Nov 01 21:54:58 <Crofton|work> hmm, look sliek I have
Nov 01 22:02:07 <Crofton|work> does that look better?
Nov 01 22:11:07 <binarym> ok ... that wasn't a bug
Nov 01 22:11:22 <binarym> poky enable ptest as DISTRO_FEATURES
Nov 01 22:11:39 <binarym> so that's why this @#! dbus-python was built :)
Nov 01 22:34:10 <binarym> does DISTRO_FEATURES support -xxxxx
Nov 01 22:34:27 <binarym> for example, i have ipv6 on DISTRO_FEATURES_DEFAULT
Nov 01 22:34:34 <binarym> can i just add -ipv6 to disable ?
Nov 01 22:49:24 <bluelightning> binarym: you should be able to do DISTRO_FEATURES_remove = "ipv6"
Nov 01 23:19:04 <rburton> binarym: poky is an example, write your own distro configuration
**** ENDING LOGGING AT Wed Nov 02 03:00:00 2016