**** BEGIN LOGGING AT Mon Jul 22 02:59:58 2013 Jul 22 07:34:43 zecke: ping Jul 22 07:40:29 ant_work: hi Jul 22 07:41:23 hi Jul 22 07:41:42 tests ok. I'll send you an email now Jul 22 07:42:37 ant_work: about which part? /proc/timer_list is kind of confirmed broken. the rest were some funnyness with porting. My 3.10.1 kernel boots.. my GSM BTS works.. and SD/MMC works when enabling the dma engine (not enabled by default and PIO mode of davinci_mmc is broken) Jul 22 07:42:56 I've booted and run your binary Jul 22 07:43:08 no issues (apart boot from mmc...) Jul 22 07:43:48 I've sent you the ipk Jul 22 07:44:29 ant_work: thanks. https://lkml.org/lkml/2013/7/19/706 Jul 22 08:07:16 do you plan to have recipes-kde? Jul 22 08:23:13 morning all Jul 22 08:23:49 morning Jul 22 08:23:57 lpapp: http://layers.openembedded.org/layerindex/layer/meta-kde/ Jul 22 08:26:28 bluelightning: thanks Jul 22 08:26:43 bluelightning: what is this sato layer? I read the recipes.txt, but I still do not get a clue. Jul 22 08:28:18 lpapp: Sato is the GUI environment we use for testing basic X11 functionality Jul 22 08:28:30 lpapp: it's not a layer, it's part of OE-Core Jul 22 08:28:52 bluelightning: yeah, it is recipes. Jul 22 08:29:06 bluelightning: honestly, I have never heard about it and I have been using Linux for 10+ years. Jul 22 08:29:13 bluelightning: is it some custom application by yocto/oe/poky? Jul 22 08:29:58 lpapp: http://www.pokylinux.org/about/ Jul 22 08:30:12 it's a uber basic DE based on Matchbox WM Jul 22 08:30:29 lpapp: kind of, it's been around since 2007 at least Jul 22 08:30:41 lpapp: the point is it's simple and provides a stable testbed for X11 Jul 22 08:31:12 plus an horrifying default green theme :) Jul 22 08:32:44 and doesn't fit on qvga Jul 22 08:33:21 I really wonder why I have never heard this name before if it is such a good stuff. Jul 22 08:34:51 probably very domain specific. Jul 22 09:05:39 morning all Jul 22 09:07:01 eren: morning ;) Jul 22 09:19:00 can I specify the layers before the build? Jul 22 09:19:18 I mean without creating a build folder. Jul 22 09:19:30 I would like to set them more persistently. Jul 22 09:25:23 lpapp: if the TEMPLATECONF variable is set in your environment prior to sourcing the oe-init-build-env script then it will pick up the template configuration files from there instead of meta-yocto/conf/ Jul 22 09:34:35 Hello everyone Jul 22 09:34:51 I've a problem installing iptables... Jul 22 09:35:31 When I add iptables to the image I get following error when I want to execute it: FATAL: Module ip_tables not found. iptables v1.4.17: can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Jul 22 09:35:54 Does anybody of you know what is needed to have the ip_tables module available in the image? Jul 22 09:36:53 g0hl1n: sounds like your kernel configuration does not enable iptables/netfilter Jul 22 09:38:15 bluelightning: I've set CONFIG_IP_NF_IPTABLES=y in my kernel config. Shouldn't that be enough? Jul 22 09:45:20 g0hl1n: what about CONFIG_IP_NF_FILTER ? Jul 22 10:32:52 is there any documentation about "addtask" somewhere? Jul 22 10:33:31 bluelightning: ok, that wasn't set in my config. I'll try it. Jul 22 10:45:20 is it an alright practice to create my own layer for our project, but only with the recipes folders we really need? Jul 22 10:45:31 for instance if we need a more up-to-date u-boot, only recipes-bsp? Jul 22 10:45:43 or it is better to replicate every recipes folders? Jul 22 10:48:49 lpapp: you just need to create the folders you need. no need to add 'empty' folders. Jul 22 10:49:02 Is there a tutorial for webkiosk buildling ? Thanks Jul 22 10:50:30 ndec: shall I copy the recipes.txt over, though? Jul 22 10:50:38 no. Jul 22 10:50:48 that file is in meta/ for reference. Jul 22 10:50:58 yeah, I have just checked other layers not copying it . Jul 22 10:51:23 though conf needs to be moved to a certain extent. Jul 22 10:51:28 in fact nothing really even forces you to follow recipes.txt in your own layer. Jul 22 10:51:48 you have to comply to it, if you intend to upstream some recipes in oe-core or meta-oe, though. Jul 22 10:51:59 conf? Jul 22 10:52:54 ndec: the folder. Jul 22 10:53:16 you must have conf/layer.conf. that's what 'defines' a layer. Jul 22 10:53:31 beyond that, you are free to have whatever you need. Jul 22 10:54:23 and I guess I need to disable the u-boot build from meta/recipes-bsp? Jul 22 10:54:34 no. Jul 22 10:54:54 either your recipe 'overrides' the original one, with for example a different version. Jul 22 10:55:11 ah, ok. I guess it is based on priority? Jul 22 10:55:12 or you can use a different recipe name, and tell OE to use that one instead. Jul 22 10:55:18 but then, how can one get both built? Jul 22 10:55:23 equal priority? Jul 22 10:55:34 do you want both built? Jul 22 10:56:06 I can imagine scenarios where it would be needed, yes. Jul 22 10:56:15 not in my particular case, but in other scenarios. Jul 22 10:56:52 u-boot is 'just' a recipe that you add to your image. you might be able to add 2 uboot recipes in 1 image. but they need to be different recipe (e.g. different name). Jul 22 10:57:02 not different version of the same recipe Jul 22 10:57:14 k Jul 22 10:58:25 well, in fact you can set PREFERRED_PROVIDER_u-boot in your machine .conf file to indicate which u-boot recipe you need for a specific machine. Jul 22 10:59:31 ndec: what about meta-foo/conf/bar-local.conf? Jul 22 10:59:53 what do you mena? Jul 22 10:59:54 mean? Jul 22 11:00:03 meta-foo: own layer Jul 22 11:00:12 bar-local.conf: config file for that own layer Jul 22 11:00:20 we have such a conf file now in meta-yocto/conf/ Jul 22 11:00:29 this is probably a bad practice, and I need to move it onto meta-foo Jul 22 11:00:34 well, it might not be a bad practice Jul 22 11:00:41 but I guess I need the same conf in both layers? Jul 22 11:01:30 i am not sure i understand what information you put in this conf file. Jul 22 11:01:40 lpapp: the idea is you should have your customisations in a distro config - conf/distro/distroname.conf Jul 22 11:02:14 lpapp: then you set DISTRO = "distroname" in local.conf and you've then enabled that set of configuration Jul 22 11:02:52 lpapp: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution Jul 22 11:03:32 bluelightning: distro is poky. Jul 22 11:03:38 with only slight mods. Jul 22 11:03:44 like kernel adaptation for our board. Jul 22 11:03:46 and custom u-boot. Jul 22 11:06:40 although, yeah... we have our foo.conf and foo-tiny.conf Jul 22 11:06:51 it is confusing to me though that poky-tiny includes poky, and not the other way around. Jul 22 11:07:05 shouldn't the "more complete" extend the tiny? Jul 22 11:08:28 it's the otherway around. poky tiny is a customized poky with minimal config. Jul 22 11:08:30 lpapp: if you're changing anything you should really create your own distro config Jul 22 11:09:42 lpapp: if you have foo.conf already, you have your distro already. it's better to include poky.conf in foo.conf, that anything else. i am not sure how you include foo.conf today. Jul 22 11:10:25 bluelightning: so every minor change means a different distribution then? Jul 22 11:10:34 including a one-liner patch? Jul 22 11:11:17 lpapp: no, it's just that for embedded applications it's pretty rare for people to want only one change Jul 22 11:11:19 it depends on the one-liner patch ;-) Jul 22 11:11:43 bluelightning: then I am lost. Jul 22 11:11:53 bluelightning: we only have some kernel hardware adaptation, but that is pretty much it. Jul 22 11:12:02 and obviously, u-boot is also hardware specific, so we need to adapt that, too. Jul 22 11:12:11 everything else is the same as in poky. Jul 22 11:12:33 lpapp: you have a foo.conf file you are including right now, is that correct? what does that have in it? Jul 22 11:12:57 depends on what you mean by foo.cong. Jul 22 11:12:59 conf* Jul 22 11:13:29 you mentioned it Jul 22 11:13:29 although, yeah... we have our foo.conf and foo-tiny.conf Jul 22 11:13:56 I mentioned other foo.conf before, too. Jul 22 11:13:58 in conf. Jul 22 11:15:28 as far as best practices go, anything that is machine specific belongs in a separate layer for the machine, which would include your kernel config, u-boot etc. and there would be a conf/machine/machinename.conf which would select those things and specify anything else custom for the machine Jul 22 11:15:53 PREFERRED_VERSION_ubev ?= "141" -> this must be a typo, can you confirm that Jul 22 11:15:58 I guess it should have been "udev". Jul 22 11:16:01 from the look of it. Jul 22 11:16:09 yep looks like a typo Jul 22 11:16:20 bluelightning: what about that best practice? Jul 22 11:16:25 adaptation means a new distribution? Jul 22 11:16:26 then, if you want anything else configured that's not machine-specific and isn't going to be different based on whose machine it's building on (i.e. local paths) then that belongs in a distro config Jul 22 11:16:33 for exactly the same package versions with adaptation patches? Jul 22 11:17:12 that way, rather than throwing a bunch of boilerplate into local.conf, users just need to include your layers, set DISTRO = "distroname" and then they're ready to go Jul 22 11:17:33 lpapp: adaptation to your machine, no Jul 22 11:17:48 lpapp: any other customisations that are specific to your usage of the machine as opposed to the machine itself, yes Jul 22 11:17:55 bbl Jul 22 11:25:23 bluelightning: right, so a different version of u-boot yields a different distribution, right? Jul 22 11:25:34 bluelightning: the distribution files should not go into the meta-yocto layer, right? Jul 22 11:27:22 bluelightning: we do not need this stuff either, right? PREFERRED_VERSION_linux-yocto* Jul 22 11:27:30 but perhaps PREFERRED_VERSION_linux-foo* instead, or not even that? Jul 22 11:33:06 this should also go into the own layer? ../meta/recipes-core/psplash/files/psplash-foo-img.h Jul 22 11:54:14 BBFILE_PRIORITY_foo = "6" -> in order to take my u-boot version rather than the old one from meta/recipes-bsp, right? Jul 22 11:57:27 "The BBFILE_PATTERN variable is set to a regular expression and is used to match files from BBFILES into a particular layer. In this case, LAYERDIR is used to make BBFILE_PATTERN match within the layer's path." -> I am not sure that makes the intent clear for me. Jul 22 11:57:47 i.e. it is not describing why a "match" has to happen. Jul 22 12:19:10 lpapp: re u-boot, it is very common for BSP (machine) layers to introduce their own customised versions of u-boot, so that's not really distro-related Jul 22 12:19:34 lpapp: you'd create your own distro layer and not put those files in meta-yocto, correct Jul 22 12:20:13 lpapp: PREFERRED_VERSION is only useful if you want to make a selection between multiple available versions where those exist Jul 22 12:20:44 lpapp: a match has to happen in order for bitbake to find any recipes or bbappend files Jul 22 12:21:02 lpapp: it is only through BBFILES and BBFILE_PATTERN that that can occur Jul 22 12:21:34 bluelightning: but if I do not need distro-related stuff, just machine, I am lost. Jul 22 12:21:50 it is more accurate to call it a "bsp layer" rather than "distro layer"? Jul 22 12:21:52 lpapp: in that case feel free to not create a distro layer, no need to be lost :) Jul 22 12:22:18 lpapp: BSP layer and distro layer are different things Jul 22 12:22:29 lpapp: a BSP is for supporting your specific machine Jul 22 12:22:43 bluelightning: yes, that is why I prefer the "bsp layer" term. Jul 22 12:22:58 lpapp: a distro layer is for configuration/customisations that are not specific to the machine, rather the use the machine is put to Jul 22 12:23:03 in which case, conf/distro is kinda moot. Jul 22 12:23:19 we are fine with poky on this machine. Jul 22 12:23:23 we only need the bsp adaptation. Jul 22 12:23:26 at least for now, that is. Jul 22 12:23:27 then, feel free to stick to it :) Jul 22 12:23:43 well, I do not see much difference, really. Jul 22 12:23:53 except the fact, I would not have conf/distro/foo.conf Jul 22 12:24:00 but to be honest, I do not mind having that either. Jul 22 12:24:05 it is not the main question to me. Jul 22 12:25:03 if you're not providing a custom distro config you don't need conf/distro in your custom layer Jul 22 12:25:07 bluelightning: I still do not understand the point of BBFILE_PATTERN Jul 22 12:25:19 what additional benefit does it bring compared to BBFILES? Jul 22 12:25:58 bluelightning: it would be nice to have a custom tiny distribution, even smaller than poky-tiny, but I do not think we have the man power for maintaining one. Jul 22 12:26:07 so we have got to stick to poky, I am afraid. Jul 22 12:26:14 lpapp: that's totally fine Jul 22 12:26:44 so, how is yocto different to mer/sailfish os? Jul 22 12:26:50 oe/yocto to mer/sailfish? Jul 22 12:27:05 lpapp: BBFILE_PATTERN is so that bitbake can associate files that are picked up from BBFILES with a particular layer, since BBFILES is just a list of paths Jul 22 12:27:19 lpapp: feel free to consider it boilerplate for your layer.conf Jul 22 12:27:39 lpapp: I have very little experience with either of those Jul 22 12:28:01 bluelightning: I think BBFILE_PATTERN is useless. Jul 22 12:28:11 not now, but the concept. Jul 22 12:28:19 I mean, you seem to filter in two-layers instead of one. Jul 22 12:28:24 1) You specify a list Jul 22 12:28:27 2) Then you filter the list Jul 22 12:28:31 how about this instead: Jul 22 12:28:35 1) Use a proper filter list? Jul 22 12:29:35 lpapp: how would that look exactly? Jul 22 12:29:55 custom splash would also go into the bsp layer? Jul 22 12:30:36 is there a possibility to use bitbake searching in recipes for specific text strings? I ask because the directory layout in poky is some kind of weird. having the source repositories on the same level as the build directory makes searching using regular linux tools quite slow Jul 22 12:31:12 volker: 'git grep' is your friend. Jul 22 12:31:19 lpapp: only an almost empty .bbappend and the logo-image..h Jul 22 12:31:28 lpapp: typically no; there's nothing to prevent you from doing that but we recommend such things go in the distro layer since they aren't actually specific to the machine Jul 22 12:31:57 ndec: but then I have to do git grep for every single repository if I checked out several layers from different vendors Jul 22 12:32:02 volker: indeed, "git grep" works well for me Jul 22 12:32:14 lpapp: but yes, better to keep it distro-specific Jul 22 12:32:24 under angstrom distribution the meta layer directories were placed under "source" so you could just limit the search to this directory Jul 22 12:32:34 bluelightning: can I have the bsp and distro layer together? Jul 22 12:32:37 volker: i generally use 'repo' then to manage multiple trees. then 'repo grep' would become your friend ;-) Jul 22 12:32:40 bluelightning: something like meta-ti? Jul 22 12:32:45 or I should separate them? Jul 22 12:33:24 ndec: will check that, but having meta directories under a source directory as it was used by angstrom seems a much simpler and cleaner solution to me,... just my two cents Jul 22 12:34:22 lpapp: better to keep a logical separation. In fact only the recipes in the BSP layers are machine-specific Jul 22 12:34:44 lpapp: you hit a bad example... Jul 22 12:35:02 ant_work: why? Jul 22 12:35:13 lpapp: best practice is to keep them separate; the idea is you can switch out your BSP layer without losing your customisations Jul 22 12:35:18 other distros/people could be interested and reuse your generic layer Jul 22 12:35:32 lpapp: they can of course appear in the same repo if that helps Jul 22 12:35:53 those are tight together for the next 10 years Jul 22 12:35:57 or so. :) Jul 22 12:36:14 so imo, separating them might be complication only. Jul 22 12:37:00 what about the meta/recipes-foo? Jul 22 12:37:10 lpapp: we use a modified linux-yocto-tiny kernel from oe-core passing through two more layers Jul 22 12:37:11 should that go into the meta-$distro? Jul 22 12:37:40 so? Jul 22 12:37:43 it is a different use case. Jul 22 12:37:52 they are not tied together in your scenario. Jul 22 12:37:57 so there must be some flexibility. Jul 22 12:38:03 it is not much so in my corporate case. Jul 22 12:38:07 it's just a bit more burden for maintanance, not so much Jul 22 12:39:27 you have one layer as common software collection / distro and one BSP for each SOC/machine you'd need in future Jul 22 12:39:45 as I said, it is not like that. Jul 22 12:39:56 there will be one hardware with one distro for the next one decade or so Jul 22 12:40:11 try to decouple your mind from general open source stuff... ;) Jul 22 12:40:11 then flatten all down if you feel more comfortable with it Jul 22 12:45:46 lpapp: imagine that in 5 years you are forced to pick a new platform due to hardware availability issues. you'll then appreciate forward planning for that possibility... Jul 22 12:46:33 lpapp: even different revs of the same hardware might be quite different internally, requiring different kernel configs, etc. Jul 22 12:58:46 bluelightning: trust me. :) Jul 22 12:58:53 I know the business deal more... ;) Jul 22 12:59:13 btw, it is interesting that these files were removed in later poky versions, http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/machine?h=denzil Jul 22 12:59:42 btw, how can I view the splash screen out of a header file provided to Yocto? Jul 22 12:59:49 is there some generator for it? Jul 22 13:00:40 sgw1: there is small issue in one of my patches included in last consolidated pull request, can you drop it or should I fix it in follow-up patch? I have many more dependency-fixes in queue Jul 22 13:00:56 "gst-plugins-bad: add few more PACKAGECONFIGs" Jul 22 13:01:49 bluelightning: btw, do I need a .bbappend for the splash screen, too? Jul 22 13:03:20 BBLAYERS variable in your conf/bblayers.conf file, which is found in the Build Directory. -> I have to create this before running bitbake then? Jul 22 13:03:24 is there a more elegant way? Jul 22 13:03:33 I cannot believe it is the right way for each build. :) Jul 22 13:03:45 is there a more "catch-all" place? Jul 22 13:05:25 also, it would mean we check build folders into the repository which is bad. Jul 22 13:21:00 "Also, the layer priority does not currently affect the precedence order of .conf or .bbclass files. Future versions of BitBake might address this." -> hmm. Jul 22 13:29:15 bluelightning_: so , i have resurected the EGL/mesa patch story... so the original patch 'fix-egl-compilation-without-x11' really needs to be replaced by the new patch which i have backported. with the original patch mesa builds without X11, since the patch adds something like this:-DMESA_EGL_NO_X11_HEADERS. however anybody that builds against mesa also needs to add the same flags or we don't get the right defs in the .h files. Jul 22 13:29:28 and this isn't quite nice, nor good. Jul 22 13:29:31 how can I clean up the build folder? Jul 22 13:29:45 I cannot just rm -rf it, as I need to keep the bblayers config file around... Jul 22 13:29:50 with the new backported patch, the headers files are set properly, when X11 isnt' there. Jul 22 13:30:17 bluelightning_: the culprit is EGL/eglplatform.h Jul 22 13:30:45 so overall, i think the patch improves the situation. it's been merged in master already, and my backport would apply the same change in dylan. Jul 22 13:31:05 i just realized that i didn't remove the .patch , so either you can do it, or i could resubmut. Jul 22 13:31:24 ndec: OK, that sounds reasonable; would you mind sending a new version of the patch making that clearer in the commit message? Jul 22 13:31:42 ok. and btw, the commit message was copy/paste from the commit in master ;-) Jul 22 13:32:07 i haven't checked though if that patch has been updated in master in the last couple of weeks. Jul 22 13:32:30 ndec: right, fair enough :) Jul 22 13:32:39 i will resent today. Jul 22 13:32:42 ndec: thanks Jul 22 13:33:58 ../meta/recipes-core/psplash/files/psplash-foo-img.h should go to ../meta-foo/recipes-core/psplash/files/psplash-foo-img.h? Jul 22 13:40:54 also, should I use .bbapends for a newer u-boot version, or a brand new stuff? Jul 22 13:46:01 lpapp: for uboot, it's better/easier to just create your own recipe, e.g. u-boot-lpapp that is specific for your machine. Jul 22 13:46:26 ndec: in which layer, and why? Jul 22 13:46:36 in your BSP layer. Jul 22 13:47:11 why not just u-boot with higher priority than oe-core? Jul 22 13:47:18 why? unless you can reuse uboot from OE, as it is, and you only need minor tweak which can go into bbappend. Jul 22 13:47:37 but most of the time uboot really needs to be customized for the target h/w, sometimes with a vendor tree, ... Jul 22 13:47:48 in which case it's easier to go with your own recipe. Jul 22 13:47:56 * lpapp does not follow Jul 22 13:48:48 so first, .bbappends is not appropriate for newer version of recipe. .bbappends is to 'overlay' an existing pair of recipe/version. Jul 22 13:49:01 yes Jul 22 13:49:06 agree Jul 22 13:49:39 and as i think a few of us told this morning, u-boot is kind of 'special' case, and most people tend to make their own recipe, as very few people end up using the upstream uboot in real life. Jul 22 13:49:55 we do. Jul 22 13:50:00 we have one custom patch. Jul 22 13:50:05 I think that is what people should do. Jul 22 13:51:00 so, if you have a minor patch/tweak *and* you use the uboot version that is in OE already, then, .bbappend is appropriate. Jul 22 13:51:17 no, oe-core has an overly outdated version. Jul 22 13:51:31 but note that you don't control the version of uboot you use. if OE upgrades to new uboot, you have to do the same. Jul 22 13:52:11 that means what? Jul 22 13:52:31 if you use a .bbappend in your layer, you reply on the .bb in OE, you agree? Jul 22 13:52:41 yes, but that is not the main question in here. Jul 22 13:52:53 I was wondering why I would need u-boot-lpapp instead of u-boot. Jul 22 13:53:00 so if OE .bb file changes to newer version, you are impacted. Jul 22 13:53:17 if you use a vendor tree for example. Jul 22 13:53:36 if what you need is too much different from uboot from OE. then you make yours. Jul 22 13:53:36 not sure I follow. Jul 22 13:53:40 the priority is set to my layer. Jul 22 13:53:44 so I would not be any affected. Jul 22 13:53:49 and that does not require lpapp suffix. Jul 22 13:54:07 if you use .bbappend, the priority doesn't matter. Jul 22 13:54:14 well, we would not like to differ much from upstream. Jul 22 13:54:26 it would be nice to have the patch always updated to the latest upstream version. Jul 22 13:54:46 you seem to have stuck with .bbappend, apparently. Jul 22 13:54:55 "I was wondering why I would need u-boot-lpapp instead of u-boot. Jul 22 13:54:56 " Jul 22 13:55:02 .bbappend file is not related to that. Jul 22 13:57:17 i think i have said why or when u-boot- would be more appropriate. if you do that, you end up with your own recipe. and you control its name and version. Jul 22 13:57:55 I still do not understand why Jul 22 13:58:00 it is u-boot after all. Jul 22 13:58:23 Hello Jul 22 13:58:24 it is not a forked u-boot. Jul 22 13:59:01 I would like to add dlt-daemons systemd files into an image. Therer is an rpm created which contains the files, but how do I get them into an image? Jul 22 13:59:05 then, good for you. the flexibility is there to allow others people which are less lucky than you, who need to deal with u-boot fork, such as vendors fork. Jul 22 13:59:32 ndec: we have one custom patch on top of u-boot upstream. Jul 22 13:59:43 ndec: similar to something when desktop distributions have custom distro specific patches. Jul 22 13:59:47 but they do not fork the packages. Jul 22 13:59:49 yes, you said that a couple of times. Jul 22 13:59:58 yes, a patch is not a fork. Jul 22 14:00:00 Hi (again), I'm still in the process of removing avahi from the image I'm trying to build. Although zeroconf is absent from DISTRO_FEATURES, avahi-daemon gets built. Using depexp I found that there's only a circular dependency libnss-mdns <-> avahi and nothing else. Jul 22 14:00:03 we still update our changes based on upstream. Jul 22 14:00:13 btw, is there an option for automatically updating the sha1 and md5? Jul 22 14:00:19 Should I try editing packagegroup-base to confirm my suspiction that it gets pulled from somewhere else? Jul 22 14:00:33 (8.0.1 Dylan, that is ... no way to migrate to Danny though) Jul 22 14:00:34 lpapp: well, desktop distro do make fork in reality. Jul 22 14:00:49 but that's not the point of our discussion.. Jul 22 14:01:06 no, they do not fork. Jul 22 14:01:18 oh: there is already an RDEPENDS against dlt-daemon.systemd inside the /systemd/system/basic.target.wants/dlt-system.service , but still it is not put into the image Jul 22 14:01:40 dlt-daemon.systemd -> dlt-daemon-systemd Jul 22 14:04:33 I think for makepkg (archlinux), we had an option for automatically updating the checksum in the pkgbuild file. Jul 22 14:04:37 is there something like that for bitbake? Jul 22 14:04:48 systemd/system/basic.target.wants/dlt-system.service -> meta-ivi/recipes-yocto-ivi/pacakgegroups/pacakgegroup-specific-component-p1.bb (copy paster error) Jul 22 14:07:16 * lpapp needs to study how the custom patches to recipes work Jul 22 14:20:04 lpapp: it even spits you the expected checksum. It's up to a human to decide if the tarball is corrupted or not Jul 22 14:26:18 I understand yocto has its own yocto kernel. Why and how is this different from the upstream kernel? I have my own HW and kernel (3.4.24) in which I'm trying to add a BSP for. Are there any yoctoisms I'd need in my kernel? Jul 22 14:26:19 * sveinse is yocto n00b Jul 22 15:09:48 dzoe: not sure if you've already tried but the best means of analysing why it is in your image may be to look at the output of buildhistory Jul 22 15:10:07 dzoe: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Jul 22 15:10:20 dzoe: specifically the .dot graphs showing dependency information within the image Jul 22 15:13:36 bluelightning_: I did and I found that DISTRO_FEATURES zeroconf pulled it in - however I didn't have zeroconf in DISTRO_FEATURES and after hacking packagegroup-base.bb and removing zeroconf stanzas, it disappeared. Jul 22 15:14:17 bluelightning_: Seems to me like danny isn't honoring all DISTRO_FEATURES correctly - but maybe I'm overlooking something. Jul 22 15:14:39 (Forking packagegroup-base.bb and deleting unused recipes is fine for my work, but I'd like to understand what's going on...) Jul 22 15:15:04 dzoe: so, the first thing is that there's a difference between what gets built and what gets included in the image Jul 22 15:15:23 dzoe: I think what's been happening in your case is that avahi is being built but not included Jul 22 15:16:07 dzoe: the way packagegroup-base is written, it unconditionally creates a packagegroup-base-zeroconf package and that has a runtime dependency on avahi-daemon Jul 22 15:16:25 dzoe: in order to be able to satisfy that, bitbake then must build avahi-daemon Jul 22 15:17:07 bluelightning_: was included - I don't care about building it, that's okay, but it was in the image and was running after startup Jul 22 15:18:02 dzoe: OK, I wouldn't think it possible for that to be as a result of this recipe though Jul 22 15:29:21 bluelightning_: do you know if I can get the checksum updated automatically? Jul 22 15:31:10 lpapp: automatically at what time? Jul 22 15:32:23 bluelightning_: by running a command Jul 22 15:32:35 with Archlinux, I place the files into the current folder, and I run makepkg -G Jul 22 15:32:41 and the checksums are updated automatically. Jul 22 15:33:10 lpapp: I don't know of an existing script or command that will do that, however writing one would not be too difficult Jul 22 15:36:34 bluelightning_: should be a bitbake option if you ask me. Jul 22 15:37:06 lpapp: bitbake doesn't ever modify its input files Jul 22 15:37:25 bluelightning_: that should be changed, yes. Jul 22 15:37:43 no, it's a design decision; any such tool would need to be external Jul 22 15:37:54 why ? Jul 22 15:38:00 other tools have been doing that just fine. Jul 22 15:38:07 and it is the most convenient way. Jul 22 15:38:20 lpapp: why would an external tool be a problem for this case? Jul 22 15:38:23 it is such a common operation that external tools do not make sense IMHO. Jul 22 15:38:38 it would be a problem because: Jul 22 15:38:40 it is _external_. Jul 22 15:39:03 lpapp: but you're already running a separate command to do this, it's not part of the normal build... Jul 22 15:39:43 bluelightning_: so? Jul 22 15:39:50 I do not think we need a separate tool for one tiny option. Jul 22 15:40:08 I would not like to run a separate command. Jul 22 15:40:22 bluelightning_: I'll try to trace the dependencies closer later, but right now I have virtually no clue why it is happening Jul 22 15:40:27 lpapp: it's not just one tiny option, it's a change in how bitbake behaves with regard to its input metadata Jul 22 15:40:57 dzoe: the buildhistory image info should help you do that - I'd be interested in the results Jul 22 15:41:00 bluelightning_: I do not follow Jul 22 15:41:06 bluelightning_: updating something is not editing. Jul 22 15:41:16 although it is still source compilation related. Jul 22 15:41:29 it is a minor stuff. Jul 22 15:41:32 lpapp: bitbake does not modify its input metadata, what you're talking about is modification Jul 22 15:41:42 you could even tell bitbake update the md5sum before building Jul 22 15:41:46 it really is bitbake scope. Jul 22 15:41:57 bluelightning_: it is irrelevant what it does. Jul 22 15:42:07 what matters in the end of the day, what is useful for end users. Jul 22 15:42:07 lpapp: sorry, but it is relevant Jul 22 15:42:56 let us agree to disagree Jul 22 15:43:15 lpapp: users should be able to have confidence that the system is not going to change the inputs that they give it particularly when it comes to checksums that should be protecting them from tampering in upstream sources Jul 22 15:43:55 bluelightning_: why would users use an option which is totally irrelevant for their use case? Jul 22 15:44:22 it would not be an obligation of course. Jul 22 15:44:33 and would not be default either Jul 22 15:44:37 so I fail to understand the concern. Jul 22 15:47:15 is there a devtool already? If not, I think it is an overkill to create one. Jul 22 15:47:40 if yes, it could be added in there, too. Jul 22 16:00:01 https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide -> for me, it is not clear where to put patches. Jul 22 16:00:14 is there a dedicated variable for those, or I need to use the do_patches function? Jul 22 16:01:18 I am not sure I understand why http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot_2011.06.bb uses git and not a released version? Jul 22 16:08:30 lpapp: what do you mean, released version? Jul 22 16:08:49 eren: that one is fetching the git repository. Jul 22 16:08:56 eren: it is not taking the released tarball. Jul 22 16:09:23 # This revision corresponds to the tag "v2011.06" Jul 22 16:09:25 # We use the revision in order to avoid having to fetch it from the repo during parse Jul 22 16:09:30 I guess that explains it? Jul 22 16:09:44 it's not a big problem, I guess Jul 22 16:09:45 nope Jul 22 16:10:12 I do not understand the second line at all. Jul 22 16:10:17 well, it is a big problem. Jul 22 16:10:23 because people might follow this wrong way. Jul 22 16:13:01 I think it is more elegant to fetch the tarball. Jul 22 16:13:19 which means the package should probably be rewritten unless I missed something. Jul 22 16:14:45 does that sound reasonable? Jul 22 16:15:58 well, not at the moment :/ Jul 22 16:16:07 probably we should ask it to more experienced people Jul 22 16:16:12 ? Jul 22 16:16:26 it should not be difficult to write a package to change the download url Jul 22 16:16:29 lpapp: you may find looking through the git history for that recipe might explain what's going on there Jul 22 16:16:39 bluelightning_: I do not have a clone Jul 22 16:17:25 lpapp: patches are referred to in SRC_URI Jul 22 16:17:46 lpapp: as with all other source files fetched for the recipe Jul 22 16:18:02 bluelightning_: yeah, so not a dedicated file like with dpkg. :( Jul 22 16:18:20 lpapp: no, everything is in the recipe Jul 22 16:19:23 bluelightning_: I cloned, but git log does not mention anything useful. Jul 22 16:19:33 I do not think a release package is worth not using the release tarball. Jul 22 16:19:54 to me, it seems a bad packaging QA. Jul 22 16:19:59 and should be revamped. Jul 22 16:20:35 should be an oe-core change. Jul 22 16:20:52 since I need to write a package anyway, and I will not follow that stuff, I might just submit a patch against oe-core. Jul 22 16:20:54 lpapp: what is the issue with fetching a tagged commit from git? Jul 22 16:21:02 it *is* the release Jul 22 16:21:11 what's the difference between checking out the tag from which also the tarball is generated? Jul 22 16:21:16 zibri: no, it is not. Jul 22 16:21:28 oh no? Jul 22 16:21:29 zibri: check the project's website where the released stuff is coming from. Jul 22 16:21:36 I will help you: Jul 22 16:21:58 i assume they don't tag random commits... but i don't know the u-boot release process ;) Jul 22 16:22:04 ftp://ftp.denx.de/pub/u-boot/ Jul 22 16:23:07 well, the main desktop distributions do not work like this either. Jul 22 16:23:07 i *think* the reason why the SRCREV is a sha1 and not a tag is that bitbake will fetch the tag to verify it hasn't changed. Jul 22 16:23:12 also, what if they migrate to svn Jul 22 16:23:14 or anything else. Jul 22 16:23:20 really, it is a very bad decision packager made. Jul 22 16:23:26 then update the SRC_URI to svn instead of git? :) Jul 22 16:23:39 or use a flexible and official way instead? Jul 22 16:23:42 instead of carrying the crap? Jul 22 16:23:45 ... Jul 22 16:24:01 tell me, what the u-boot download link tells you? Jul 22 16:24:05 go to git and fetch? Jul 22 16:24:22 or it gives the tarballs for downloading? Jul 22 16:24:44 it provides you options, I believe there is no "right" way for this stuff Jul 22 16:24:53 either clone the tag, or download tarball for this tag Jul 22 16:25:03 where do you see "git clone" for download ? Jul 22 16:25:06 to get the release? Jul 22 16:25:12 could you please point me to the link? Jul 22 16:25:22 there *is* right way Jul 22 16:25:28 lpapp: http://www.denx.de/wiki/U-Boot/SourceCode Jul 22 16:25:30 which is the official way. Jul 22 16:25:40 first bullet point: git :) Jul 22 16:25:58 zibri: nice misinterpretation try. Jul 22 16:26:06 *** current *** source code Jul 22 16:26:11 as well as history? Jul 22 16:26:13 they write with bold characters .... Jul 22 16:26:14 lpapp: well, the official release email says that we can download from git, or ftp. Jul 22 16:26:16 for the fuck sake. Jul 22 16:26:18 argh, i give up Jul 22 16:26:25 then the next bold line is: Released Versions (and some special snapshots) are available from the DENX FTP server Jul 22 16:26:26 zibri: I give up, as well Jul 22 16:26:31 U-Boot v2011.06 has been released and is available from the git repository and the FTP server. Jul 22 16:26:35 http://lists.denx.de/pipermail/u-boot/2011-June/094956.html Jul 22 16:27:32 * lpapp is afraid of the oe/yocto packaging quality Jul 22 16:29:00 I believe we cannot judge packaging quality just by looking how it fetches source Jul 22 16:29:52 oh yeah, sure, desktop distributions having a lot more packaging experience are all stupid Jul 22 16:30:05 lpapp: debian packaging for u-boot: http://anonscm.debian.org/gitweb/?p=collab-maint/u-boot.git;a=commit;h=b1af6f532e0d348b153d5c148369229d24af361a Jul 22 16:30:08 and perhaps Yocto is the right thing. Jul 22 16:30:34 they import the entire git history of the project. Jul 22 16:30:35 it's even the very same commit SHA1 as in OE. Jul 22 16:30:53 zibri: Use /ignore, I've felt better ever since :) Jul 22 16:30:54 i think we can consider debian, as a decent desktop distro. Jul 22 16:31:19 ndec: debian as a "decent" desktop distro? Jul 22 16:31:20 hm :) Jul 22 16:31:38 * ndec suddently hesitate who needs to be /ignored ;-) Jul 22 16:31:50 hehehe :P Jul 22 16:32:07 we need to define "decent" actually Jul 22 16:32:28 but it would be off-topic here Jul 22 16:32:29 kergoth: :) Jul 22 16:33:06 i have the feeling there is a lot of off-topic today ;-) Jul 22 16:34:58 ndec: https://aur.archlinux.org/packages/ub/uboot-mkimage/PKGBUILD Jul 22 16:35:34 yay, they are not dependent on the VCS? Jul 22 16:35:44 they use the official way from the website? Jul 22 16:35:44 lpapp: and? that basically means that there is choice around. and it's good. Jul 22 16:35:49 no Jul 22 16:36:00 it means, they do not depend on the vcs, tag, server, whatever. Jul 22 16:36:07 and they use the official way written on the website. Jul 22 16:36:23 but the developers of u-boot depend on vcs, tag, server, whatever to actually produce that tarball? :) Jul 22 16:36:30 and it also means they are not inconsistent unlike yocto and oe Jul 22 16:36:40 like few packages come from git, the other from tarball urls, etc. Jul 22 16:37:00 eren: developers != packagers. Jul 22 16:37:48 also, pass mistakes are hardly excuse for introducing more. Jul 22 16:38:01 I am sure the debian developers would appreciate contribution in this regard in line with their policies. Jul 22 16:39:53 also, if the history of the repository is modified, they also screws up the downstream packages, etc. Jul 22 16:40:01 that* Jul 22 16:40:12 again, I am surprised by the packaging quality. Jul 22 16:41:18 the only reason against ftp could be limited corporate environment where only http (8080) is allowed, and nothing else. Jul 22 16:41:55 but then, git will not work either anyway Jul 22 16:45:08 from the debian mentor channel: Jul 22 16:45:09 17:41 < lpapp> hi, is it ok to package something from git for a stable release? Jul 22 16:45:09 17:41 < lpapp> or should we try to use the released tarball with the url coming from the website. Jul 22 16:45:12 17:42 < SamB> it's better if you can use a release, yes Jul 22 16:46:06 17:44 < SamB> and if upstream distributes release tarballs you should indeed use those rather than roll your own Jul 22 16:46:59 ndec: so, no, you cannot consider that debian package "decent". Jul 22 16:52:22 is there any way to check out the splash header file? Some tool which converts it back to png? Jul 22 16:57:07 lpapp: not to my knowledge, unless there's something provided in the psplash code Jul 22 16:57:35 bluelightning_: so how can one generate "image headers"? Jul 22 16:57:43 it is pretty strange to have something like this. Jul 22 16:57:46 is it Yocto specific? Jul 22 16:57:52 lpapp: it's psplash-specific Jul 22 16:58:02 lpapp: you can supply your own png in the SPLASH_IMAGES variable Jul 22 16:58:13 no no, we use headers. Jul 22 16:58:18 it'll be converted automatically as part of the build Jul 22 16:58:24 try to open that up with an image viewer ... Jul 22 16:58:54 say, I have a png... how can I get a header file? Jul 22 16:58:55 lpapp: or, if you prefer, you can do the conversion once using the script supplied as part of the psplash source Jul 22 16:59:26 what script? Jul 22 17:00:04 btw, psplash seems to be a yocto project, so it is relevant to Yocto. Jul 22 17:00:08 kinda domain specific. Jul 22 17:00:52 lpapp: https://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/make-image-header.sh Jul 22 17:01:14 if you prefer you can always use your own splashscreen application Jul 22 17:01:21 or, none at all Jul 22 17:02:37 bluelightning_: that script does not even have a help menu ... Jul 22 17:03:10 lpapp: it's not ideal I'll admit Jul 22 17:03:26 I'm sure patches would be welcome Jul 22 17:03:56 bluelightning_: can you summarize how it must be used? Jul 22 17:04:33 from the u-boot channel: 17:39 < lpapp> do you prefer us packagers to package the released tarball from ftp or git tag? Jul 22 17:04:44 18:02 < hofstee> lpapp: tarball seems more logical since you don't need the history, and tag and tarball should be equal Jul 22 17:05:22 just like I claimed several times above ... Jul 22 17:05:34 I even offered the help with updating it... but it was not too much appreciated. Jul 22 17:05:39 guess whether I help with it ... Jul 22 17:06:20 ndec: also, they do *not* use git for debian Jul 22 17:06:28 ndec: that is just an additional metadata, but the source is not coming from there. Jul 22 17:06:48 lpapp: I guess I don't see why you're so hung up on this particular thing, it's not like the source will actually be different Jul 22 17:07:33 See? I would like to contribute, and then I am said "hung up" Jul 22 17:07:37 "better to ignore me" etc Jul 22 17:07:56 (this is not the first time for offering contribution for _free_) Jul 22 17:08:58 to me, it seems awkward one needs to fight to be able to help. Jul 22 17:10:03 even over minor and trivial things. Jul 22 17:10:18 I kinda expected, "sure, go ahead, that would be great!" Jul 22 17:11:33 I will do it for myself, but I will not submit it to upstream as it would not be welcome anyway. Jul 22 17:11:39 lpapp: the thing is this is trivial; if the source code is the same it hardly matters where it is fetched from, the output will be the same Jul 22 17:12:47 you can say that against everyone else Jul 22 17:12:53 arch, debian packagers, u-boot authors, etc. Jul 22 17:13:13 if you do not care about what upstream suggests, probably it is not my cup of tea to contribute here. Jul 22 17:13:22 we have always respected upstream when doing packaging, no matter what. Jul 22 17:13:46 lpapp: correct me if I'm wrong but upstream didn't say "no you must use tarballs, set fire to anyone who is using git because that's just wrong and evil" Jul 22 17:14:15 everyone else said: tarball is preferred. Jul 22 17:14:30 there is technically hardly any reason to go against everyone else. Jul 22 17:14:40 anyway, you all have managed to shut down my contribution motivation. Jul 22 17:14:44 I don't know the history here; maybe at one point it history it was found convenient to point to git in the event that we needed to incorporate one or two changes from git on top of a release Jul 22 17:14:50 surely, I am not willing to submit it upstream anymore Jul 22 17:15:16 except that, it is pretty much the same. Jul 22 17:25:39 bluelightning_: I asked several times for qt issues last time, but I did not get anything. Jul 22 17:25:52 I feel it hard to contribute to the project, but I do not have much motivation anymore either to be honest. :) Jul 22 17:26:08 lpapp: I thought we had a reasonable discussion about that, maybe I wasn't around for everything Jul 22 17:26:46 bluelightning_: no, I asked for reasons apart from the sdk why it is not mature Jul 22 17:26:51 and I have not got any reasons really. Jul 22 17:26:57 just that "3 months is not enough to make it" Jul 22 17:28:25 bluelightning_: what is the logic for putting patches into meta, meta-yocto, or an own layer? Jul 22 17:29:39 I have a meeting now unfortunately, bbl Jul 22 17:41:49 bluelightning1: should I put a local and site config into meta/meta-yocto/meta-foo or just meta-foo? Jul 22 18:02:06 lpapp: re your earlier question, none of us is currently close enough to work out what's missing if anything in meta-qt5 other than the obvious missing SDK support Jul 22 18:02:42 lpapp: which makes it hard for us to commit to pulling it into the core on some accelerated schedule when it is quite usable in its own layer for the time being Jul 22 18:04:01 lpapp: with regard to where to put patches / configuration it depends on whether your change makes sense mostly just for your case or for all users Jul 22 18:37:50 oh, bluelightning has just left. Jul 22 20:15:34 Hi Khem: regarding bug #4854, do you think we need to investigate the tune file or qemu. If the tune file any suggestions as to who can look into it? Jul 22 20:15:35 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854 normal, Medium, ---, raj.khem, NEW , floor call (from math.h) is broken on qemuppc Jul 22 20:36:46 bluelightning: welcome back Jul 22 20:40:21 hi Jul 22 20:40:32 bluelightning: what did you write last? Jul 22 20:40:55 * kergoth tries to whittle down the dependencies necessary to build systemd-tmpfiles Jul 22 20:42:38 lpapp: http://logs.nslu2-linux.org/livelogs/yocto.txt Jul 22 20:43:14 hmm, this channel is publically logged, and not mentioned in the topic? Jul 22 20:45:16 I think it says "you may wish to" Jul 22 20:46:11 the freenode rule is to mention it if I recall correctly. Jul 22 20:48:14 bluelightning: our patches are hardware adaptation mostly. Jul 22 20:48:18 to linux, u-boot, etc. Jul 22 20:50:45 so, it sounds like for the most part, they would be eminently suited for a BSP layer Jul 22 20:51:29 Good afternoon everybody! Jul 22 20:51:45 Is there a replacement of busybox? Jul 22 20:51:57 Something more.. fully featured? Jul 22 20:52:01 bluelightning: is there a good example for applying packages in case of any package? Jul 22 20:52:04 yes, the real applications. Jul 22 20:52:06 which are many Jul 22 20:52:09 b1gtuna: coreutils Jul 22 20:52:27 hm Jul 22 20:52:45 ya replacing busybox with individual packages will take some time Jul 22 20:52:51 lpapp: coreutils? Jul 22 20:52:56 lpapp: not sure I understand the question Jul 22 20:54:12 b1gtuna: yes Jul 22 20:54:12 b1gtuna: the packagegroup-core-basic will go a long way to replacing busybox with the full featured commands, there is also a packagegroup-core-lsb which includes all the LSB (linux standard base) Jul 22 20:54:29 bluelightning: ... for applying _patches_ ... Jul 22 20:54:44 aha, thats the one, i knew there was a group but i couldnt' for the life of me remember what it was, thanks sgw1 :) Jul 22 20:54:53 * kergoth was thinking task-proper-tools, but that doesn't exist anymore Jul 22 20:54:54 lpapp: sure, that's not the part I didn't understand though... Jul 22 20:55:08 lpapp sgw1 - sweet! configurable through DISTRO_FEATURES? Jul 22 20:55:11 kergoth: yeah, basic and lsb will help out. Jul 22 20:55:38 bluelightning: I am looking for examples in the existing layers Jul 22 20:55:45 bluelightning: how to do patching nicely. Jul 22 20:55:51 b1gtuna: it's just a packagegroup you'd add to your existing image Jul 22 20:56:06 b1gtuna: more through your image creation and selection of what to install, see core-image-basic and core-image-lsb in meta/recipes-extended/images Jul 22 20:56:08 lpapp: the BSP guide should be a good starting reference Jul 22 20:56:24 bbl Jul 22 20:56:30 bluelightning sgw_: makes sense. gracias! Jul 22 20:57:01 gah, dumping the config.log files to the do_configure log is not cool Jul 22 20:57:07 we need a variable to toggle that behavior Jul 22 20:57:20 the end of the config.log is almost never of any use, its all the variables from the cache and crap Jul 22 21:06:56 gaaaaah Jul 22 21:07:09 i hate when i lose patches i had forgot to copy out of ${S} Jul 22 21:07:17 do a clean and time to do it over again Jul 22 21:08:25 hmm, we really need to get the tmux terminal types fixed, i haven't had *any* time to look at it since it first got merged Jul 22 21:13:08 kergoth: been there done that too many times, we need a tool for that! Jul 22 21:13:59 yes, indeed. push_my_patches_to_an_appropriate_path_in_filespath Jul 22 21:16:11 kergoth: historical question for you: it seems we keep 2 python sitecustomize.py files around, one for target and an identical one for -native/nativesdk-, it seems to me that it should are primary for the native and we should not be using the target it one, thoughts? Jul 22 21:17:11 Honestly, I have no idea, I mostly punted and let mickey lauer handle python back in the day :) Jul 22 21:17:26 it was unpleasant, as all the scripting language builds are Jul 22 21:17:43 kergoth: yeah, his name is in that file :-)! Jul 22 21:18:06 :) Jul 22 21:26:58 okay, systemd-tmpfiles deps are down to intltool-native dbus libcap. I think this isn't unreasonable, think folks would object to that being pulled into non-systemd builds to transition away from populate-volatiles? Jul 22 21:33:12 Does anyone remember the bug where if you had multiple recipes using the same git repository, but differing SRCREVs based on the same branch, they'd fight over control of the autoincrementing number due to sharing the field in the persist_data db presumably, resulting in the recipe being rebuilt on every build, as the number would increment on every parse? Jul 22 21:33:37 I'm thinking that may have been related to bug 3225 and tehrefore would have been resolved by the switch to the pr server Jul 22 21:33:38 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3225 normal, Medium, 1.4, constantinx.musca, RESOLVED FIXED, linux-yocto SRCPV is changed after every MACHINE switch Jul 22 21:33:50 but I'm uncertain, and we may need a workaround/fix for dylan Jul 22 21:35:58 yes that's the issue Jul 22 21:36:19 now PR server contains package architecture, so if it's MACHINE_ARCH recipe then it's fine Jul 22 21:36:28 key in PR server Jul 22 21:36:36 okay, thats what i was thinking. think we'll just not use SRCPV for hte affected recipes, for now, for our old product which was prior to pr server **** ENDING LOGGING AT Tue Jul 23 02:59:58 2013