**** BEGIN LOGGING AT Wed Jun 15 02:59:58 2016 Jun 15 10:14:12 is "WARNING: The license listed MIT was not in the licenses collected for recipe foo" supposed to be interpreted as "WARNING: The license listed, MIT, was not in the licenses collected, for recipe foo". that's a pretty damn mangled english sentence... :/ Jun 15 10:14:57 it's not clear what "licenses collected" means either Jun 15 10:29:25 Hi all, Jun 15 10:29:25 How can I have the list of all my image software and where they come from? Jun 15 10:29:25 I tryed bitbake -g myImage but it is unreadable. Jun 15 10:29:25 I just want my OS architecture, is there a way to get it? Jun 15 10:31:49 Ok just found https://lists.yoctoproject.org/pipermail/yocto/2014-January/017928.html that will probably answer my question Jun 15 10:32:46 armpit: ping? Jun 15 12:44:01 I got two layers, meta-x and meta-y , meta-x got meta-y in bblayers.conf. in meta-y contains conf/layer.conf with BBPATH .= ":${LAYERDIR}", plus classes/my.bbclass plus local.conf containing INHERIT += "my" Jun 15 12:45:01 when I ran bitbake -e my-image, the INHERIT doesn't seem to contain "my" Jun 15 12:51:18 ok!, when I put it directly in layer.conf Jun 15 12:51:22 it works Jun 15 12:52:07 but what to add to layer.conf to make bitbake to look for other *.conf files in meta-y/conf/ Jun 15 13:07:26 mastier, maybe start checking your BBPATH addition .. would be my first thing to verify here Jun 15 13:08:23 also what if u add meta-y in your global bblayer.conf , why the parent -> child situation between meta-x and meta-y ? Jun 15 13:58:52 rob_w: I got bblayer.conf.sample modified in meta-x (the project meta), which is copied over to builddir when i run oe-init-build-env , here is meta-y/conf/layer.conf : http://pastebin.com/mhxe9K5C Jun 15 13:59:38 I would like to additional conf (local.conf) files in meta-y be parsed, not only layer.conf Jun 15 14:06:43 BBPATH="/var/fpwork/mastier/myproject/poky/meta-yocto:/var/fpwork/mastier/myproject/qemurfswa9:/var/fpwork/mastier/myproject/poky/meta:/var/fpwork/mastier/myproject/poky/meta-yocto-bsp:/var/fpwork/mastier/myproject/meta-x:/var/fpwork/mastier/myproject/meta-y" Jun 15 14:54:58 mastier, looks legit Jun 15 14:55:31 can u run a build with -vvv and pastebin it ? Jun 15 15:00:03 mastier: random .conf files in a layer are never going to be sourced unless you source them, or bitbake.conf does (like local.conf). the first entry in BBPATH will be used for any file it's looking for. adding local.conf to al ayer makes no sense, as either it'll do nothing, or it'd be used in preference to the build dir, depending on bbpath order. lif you have some functionality in your layer that requires a .conf to be opted into, then document in the Jun 15 15:00:03 readme that the user needs to include its .conf from local.conf, or add its class to inherit. as long as the layer is in bbpath, it'll find the files Jun 15 15:19:40 kergoth: so for my use case, I want just to include the layer meta-y (it's actually the layer for devops, extending some steps in the build chain), in that way it appends the classes given in INHERIT. So shall I add INHERIT += in layer.conf ? Jun 15 15:20:22 seems good idea or is it better ? assuming it will work for any MACHINE Jun 15 15:20:37 it's possible that might work, but i'd *highly* advise against it. that's not how layers generally function, and personally i'd never touch such a layer with a 10 foot pole Jun 15 15:22:11 it works :D Jun 15 15:23:04 but I assume it is not veru nice solution, because that some class is implicitly added to INHERIT Jun 15 15:24:19 so, your attitude against it is just it wasn't created for that purpose, because layer.conf should just specify info only the layer's settings Jun 15 15:25:20 and people expect layer inclusion to not suddenly enable configuration options. i.e. inliuding a bsp layer doesn't change your machine, it makes those machines available, the user then chooses which to use Jun 15 17:26:51 does anyone know right away which is parsed first: local.conf or bblayers.conf ? Jun 15 17:27:39 bblayers.conf is parsed, then the layer.conf for each layer in BBLAYERS, then conf/bitbake.conf is parsed. Jun 15 17:27:43 bitbake.conf is what includes local.conf Jun 15 17:28:50 ok, thanks Jun 15 17:31:46 conf/bitbake.conf is found via BBPATH, and BBPATH isn't set until bblayers/layer.conf set it, so it wouldn't be possible to parse local.conf before bblayers. Jun 15 17:33:12 interesting Jun 15 17:34:05 this might sound very unrelated, but as I am seeing, BBMASK does not aply to .bbclass or .inc files, correct ? Jun 15 17:35:22 correct, bbmask excludes recipes. you can't mask out an included or inherited file, as they're included or inherited for a reason, if they suddenly vanish, things would likely break Jun 15 17:35:34 you can bbmask bbappends as well as .bb files, though Jun 15 17:36:42 the issue I'm having is exactly the opposite of vanishing, in fact two different BSP layers have a .inc file with the same name, and the wrong one is taken Jun 15 17:37:49 I find it convenient to keep the same bblayers.conf and local.conf for several machines, and up until now I was adding to BBMASK depending on the MACHINE variable to mask out incompatible .bb/.bbappends Jun 15 17:38:15 does the .inc serve the same purpose? if so, just reorder the layers in BBLAYERS Jun 15 17:38:41 yes, same purpose Jun 15 17:38:53 the first one there will be used, as BBLAYERS order determines layer.conf parse order, which determines the order of entries in BBPATH, and the first entry in BBPATH that has the file will be used Jun 15 17:39:02 so just swap their order in BBLAYERS, done Jun 15 17:39:22 :) Jun 15 17:39:27 but BBLAYERS being set in bblayers.conf, I would need different bblayers.conf files Jun 15 17:39:45 or is there a way to set it depending on the MACHINE? Jun 15 17:40:34 that's not going to happen Jun 15 17:40:54 using the .inc from one layer breaks the other? or is one just providing a fix above the other? Jun 15 17:40:55 I was under the impression that including all the layers for all your target machines was the "recommended" way Jun 15 17:41:10 it is, which is why this would be a bug in those bsp layers, contact their maintainers Jun 15 17:41:32 at mentor, we don't, though, we use separate build dirs for each machine, because we don't trust that all bsp layers are well behaved Jun 15 17:41:36 would be nice to change that eventually.. Jun 15 17:41:40 one is for generation A of the HW, the other is for generation B Jun 15 17:42:24 yeah, so far I have just been thinking "lazy BSP maintainers don't put COMPATIBLE_MACHINE on all their files", but what would be the correct approach for .inc and bbclasses ? Jun 15 17:42:42 I keep asking out of curiosity, by now it is clear I will have to separate bblayers.conf :) Jun 15 17:42:52 most likely they'd need to name the .inc differently Jun 15 17:42:58 to avoid the conflict Jun 15 17:43:35 the compatible machine is one issue, not using the override for other changes is another (ie. recently found that meta-intel unconditionally appended to linux-firmware regardless of whether an intel machine was selected.. in that case the change was harmless, but not all are) Jun 15 17:46:55 I see Jun 15 17:47:04 thanks a lot for the discussion, kergoth Jun 15 17:47:15 np, sorry the news wasn't better :) Jun 15 17:48:24 sometimes bad news is better than no news :) Jun 15 19:13:01 Hello all, anyone know if there is a way to get the actual PV for something I have a DEPENDS on? Jun 15 19:13:58 In my case, I am generating a FIT image with a kernel/ramdisk/DTB and would like to include the version of each in the FIT image metadata. Jun 15 19:16:10 nope, recipes cannot touch one another's metadata, only the files from their dependencies in the sysroot Jun 15 19:17:36 hmmm, ok Jun 15 19:38:27 ImportError: bad magic number in 'progressbar': b'\x03\xf3\r\n' Jun 15 19:38:31 huh. anyone seen this one? Jun 15 19:39:25 nevermind, found it. tested bluelightning's progress patches, then reverted, and the .pyc/__cache__ from the python package was being used in preference to the .py :) Jun 15 19:39:25 oops Jun 15 19:40:51 i got that earlier today with different code Jun 15 19:40:53 very annoying Jun 15 19:41:17 ugh, now one of my classes in meta-mel is failing saying BBFILE_COLLECTIONS isn't set. how the .. Jun 15 19:41:58 rburton1: there's a git hook that'll clear out python caches on git checkout, but i never remember ot install it after cloning a repository :) Jun 15 19:47:35 the caches in py3 are clearly arse Jun 15 19:57:18 shouldn't git update the timestamp when reverting a patch and shouldn't that cause python to consider the cache outdated? Jun 15 19:58:06 it probably sets the timestamp to the date in the past for the commit Jun 15 19:58:16 whereas python just looks at "cache is newer than source" Jun 15 19:59:48 neverpanic: fairly sure git never sets file timestamps based on commit dates at all Jun 15 19:59:56 but not sure Jun 15 20:00:03 hmm Jun 15 20:00:46 kergoth: yes, it doesn't set them to commit dates, which is exactly why I'd expect it to work Jun 15 20:01:06 neverpanic: that only helps if the same filename is in both Jun 15 20:01:06 git always touches files when it modifies them, setting the mtime to the current time Jun 15 20:01:19 if the file was removed, the cache entry will stay around,a nd python can import a .pyc by itself Jun 15 20:01:24 and in this case it was a module vs a package Jun 15 20:01:32 progressbar.py vs progressbar/*.py* Jun 15 20:01:34 Oh, OK. Jun 15 20:02:10 but yes, in the common case it's not a problem :) Jun 15 20:16:17 Does any one know of a layer that's configured for apache2 installation as opposed to httpd installation? Jun 15 20:16:32 looked hi and lo, no dice hoping for some help Jun 15 20:17:38 https://layers.openembedded.org/layerindex/branch/master/layer/meta-webserver/ didnt help ? Jun 15 20:18:11 no Jun 15 20:18:36 just gives me layers with httpd Jun 15 20:18:55 maybe that's all there is. I'm asking around in case this isn't true Jun 15 20:19:02 but the apache2 binary is called httpd Jun 15 20:19:38 and there is apache2 in exactly that meta-webserver layer Jun 15 20:19:39 well, when I do an apt-get install apache2, I get a server that fires up with executable named "apache2" Jun 15 20:20:00 it's underneath recipes-httpd Jun 15 20:20:23 in your distribution it is called apache2, but in others it is called httpd Jun 15 20:20:27 wondering if anyone has heard of a module perhaps named like "recipes-apache" Jun 15 20:20:29 on fedora is httpd Jun 15 20:21:01 that's weird because when I do an apt-get, I get apache2 Jun 15 20:21:19 http://cgit.openembedded.org/meta-openembedded/tree/meta-webserver/recipes-httpd/apache2 Jun 15 20:21:39 what else are u missing ? Jun 15 20:21:43 that renders to an httpd server binary. Want apache2 binary Jun 15 20:21:57 https://httpd.apache.org/ Jun 15 20:22:08 Get recipe there, igor? Jun 15 20:23:08 i dont get it .. sorry Jun 15 20:23:18 well, as I know, httpd = apache Jun 15 20:23:46 if you crack open the recipe cited, it renders to httpd. My issue is with a system I'm maintaining. Httpd not the same as apache2 Jun 15 20:23:56 Though the underlying code might be the same Jun 15 20:25:03 Configuration of the two completely different, Apache2 executable would be greatly preferable to httpd executable, hence my inquiry Jun 15 20:25:13 If it's no deal, thanks for trying Jun 15 20:26:34 no ideas off top of head? I'll wait a minute or two and then sign off. Thanks again for the time, folks Jun 15 20:27:10 httpd might be just the acronym of the current webserver process.. i my view this recipe ends up with a proper apache2_2.4.20 ? no ? Jun 15 20:27:55 yeah, it's the latest code but somehow when one does this the apt-get way, one arrives at a binary named "apache2" instead of "htttpd". Jun 15 20:28:10 That's causing me some serious aggravation but maybe I just have to work through it. Jun 15 20:28:23 ln -s is your friend ;-) Jun 15 20:28:32 It would be great if I could just haul in a new recipe or layer, rebuild and go get it Jun 15 20:28:50 create an append Jun 15 20:29:01 I'd love it if I could just link this one away, but the configuration is different Jun 15 20:29:03 that makes a ln -s httpd apatche2 Jun 15 20:29:06 ...and install a symlink ;-) Jun 15 20:29:37 maybe your configuration is for another version of the apache2 Jun 15 20:29:43 what about the configuration, guys? the files are different. For instance, apache2.conf has no module citations Jun 15 20:30:04 on the other hand, httpd.conf is loaded with module citations/includes Jun 15 20:30:07 the configuration file name is httpd.conf too Jun 15 20:30:45 not on the system with the apache2 executable I'm dealing with. Wish I could show you a screen cap Jun 15 20:31:03 Two very different .conf file schemes Jun 15 20:31:04 that is ur fedora box right ? Jun 15 20:31:19 Actually, it's a Ubuntu 14.04 box Jun 15 20:31:27 you want to build a package from yocto to install on your system? Jun 15 20:31:33 is it what you want? Jun 15 20:31:55 that would be fabulous. I have the openembedded layer, if I could just tool that one it would get me home Jun 15 20:32:00 Stumpy_: that's likely to be distro-specific, there's nothing requiring that they be the same Jun 15 20:32:23 ah. So maybe I'm stuck with httpd, huh? Jun 15 20:33:01 what is your system? Jun 15 20:33:04 well, you say "stuck" but as others have said, it *is* apache Jun 15 20:33:10 it was built from yocto? Jun 15 20:33:24 It's a standard 1U Intel box with a custom distro build with yocto Jun 15 20:33:34 For an embedded application Jun 15 20:34:05 ok, and how did you install apache2 in this system? Jun 15 20:34:25 bluelightning: the issue is the config. Understand under the hood it's the same Jun 15 20:35:05 Have a proto system not yocto-built. Trying to make the yocto-built system congruent with the non-yocto-built system Jun 15 20:35:08 Stumpy_: you can substitute your own config files pretty easily if you prefer Jun 15 20:35:49 ok Jun 15 20:35:52 I understud Jun 15 20:35:57 bluelightning: issue- can do so but since system I'm trying to clone has different config situation, hard to port them. Jun 15 20:36:15 the problem is that your apache2 is custom to your system Jun 15 20:36:30 Stumpy_: that's what I mean... you should be able to transplant the entire config Jun 15 20:36:41 so you have to find out what apache2 is been used on your system and make a recipe that builds it from yocto Jun 15 20:36:43 My fate may be to by-hand do the interpretation of the apache2.conf and translate to httpd.conf. Would rather not go there Jun 15 20:36:58 again, that shouldn't be necessary Jun 15 20:37:15 Stumpy_, maybe you do need to understand the configurations instead blindly "wanna copy over" them Jun 15 20:37:16 unless you are using an ancient version of apache whose configuration is not compatible with the version we can build Jun 15 20:37:23 paths and names do change between distros , still Jun 15 20:37:45 It would be sensational if I could find a recipe someone else developed. It's a reason I'm here. New to yocto don't know all the places to look for recipes Jun 15 20:38:01 hoping for a little nudge in the right direction from some folks that have been doing this for a while Jun 15 20:38:37 I have to figure that it's apache2, someone HAS to have developed a recipe for that SOMEWHERE along the way.... Jun 15 20:38:49 sure, valid question, and my 5 cents would be to follw the errors in the names and see how you end up while copying Jun 15 20:38:57 we already have an apache2 recipe, if it doesn't meet your needs, you're likely on your own. and the layer index is always the place to look for recipes Jun 15 20:39:27 okay. That's helpful. Take it that you folks like one version of anything, then? Jun 15 20:39:40 Stumpy_: from what you're saying, it sounds like your existing apache2 binary may be a stripped down version that has all the necessary modules compiled into the binary, so you don't need any external modules and the resulting config file becomes very simple. Jun 15 20:40:11 I don't need any module citations to run the proto system Apache2, no Jun 15 20:41:06 I think you will not find a specifc apache2 recipe that matches your proto system apache2 Jun 15 20:41:41 probably your proto system vendor customized the apache2 or it is a very old version Jun 15 20:41:47 okay, that mostly answers my question Jun 15 20:42:38 It's a little confusing because I just did an apt-get install apache2, and the binary came back "apache2" not "httpd". Not sure what's going on there, and it spurred me a bit to ask here Jun 15 20:43:05 so you have to make your own apache2 recipe based on your proto system or you can create a httpd.conf translating your apache2.conf Jun 15 20:43:05 ...but you folks are telling me that it's going to be httpd, and maybe I just need to figure out how to be good with that Jun 15 20:43:27 igor2: yeah, I think these are my choices Jun 15 20:44:03 I do wonder, however, how in blazes I can do an apt-get and wind up with apache2 as opposed to httpd. That one has me scratching my head Jun 15 20:44:27 i really don't see what the name of the binary has to do with anything. it's your configuration files that are the problem, not what the binary happens to be called, no? Jun 15 20:44:39 Stumpy_: use a .bbappend to override the default apache2 config and add "--enable-mods-static=MODULE_LIST". This will statically link them into the executable instead of dynamically load them. Jun 15 20:44:41 its because your proto system vendor released a version Jun 15 20:44:55 so you can apt-get install your vendors apache2 Jun 15 20:45:34 httpd is a acronym, f.e busybox can provide a 'httpd' .. or take sshd ,, it either is openssh or again busybox ssh .. right ? Jun 15 20:45:36 igor2: the yocto built distro chokes when I try that particular apt-get Jun 15 20:46:10 billr: I need to think about that one Jun 15 20:46:19 you can't install stuff from one distro on another, generally. go try installing packages from redhat on your debian machine on your desktop and see how far you get :P Jun 15 20:46:47 kergoth: of course, true enough Jun 15 20:47:30 I had some hope that since it's all apache (names be damned) I could craft something, but I think I'll just have to dope through the .conf files. That's pretty sensible Jun 15 20:48:13 maybe you can find a software that converts your conf to a httpd.conf Jun 15 20:48:44 There's an idea. Folks, is there any way I can get a transcript of this conversation. Several useful ideas in here Jun 15 20:49:01 Maybe I just screenCap it Jun 15 20:49:15 ctrl+c ctrl+v? Jun 15 20:49:17 kkkk Jun 15 20:49:38 Stumpy_: what are you using for an irc client? Many of them automatically keep a log. For instance, I know pidgen does. Jun 15 20:50:00 Web browser Jun 15 20:50:30 oh. Copy and paste or screenshot, I guess. Jun 15 20:51:44 Guys, thanks you're very gracious. New yocto user signing out. Jun 15 20:52:10 And here's the reason Debian's Apache is called "apache2": https://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/rules#n93 Jun 15 20:52:15 Just a second too late. Jun 15 20:52:36 And --enable-layout=Debian is probably why the config files look different, too. Jun 15 20:52:39 neverpanic, too much too read i guess Jun 15 20:52:51 Yeah, can it not just work somewhere in Yocto already? Jun 15 20:53:00 Can somebody already have done that work? Jun 15 20:53:02 copy n paste , right ? Jun 15 20:53:19 we ve all been there , right Jun 15 20:53:45 Yeah, I'm no exception, I don't have the time to fix the things I'd like to fix :/ **** ENDING LOGGING AT Thu Jun 16 02:59:58 2016