**** BEGIN LOGGING AT Thu Sep 03 02:59:59 2015 Sep 03 07:08:25 hello, how do I change boot parameters in Gummiboot upon image creation? Sep 03 07:12:02 <_4urele_> hello everyone! Sep 03 07:13:27 <_4urele_> I will make a recipe for a python module called xmltodict (I could not find the recipe...), I would like to share it, how could I share the recipe? Sep 03 07:13:40 <_4urele_> (more where ;o) ) Sep 03 07:33:05 morning everyone Sep 03 07:49:50 good morning.. if i extract the target root filesystem i need to do this with sudo, but that is a problem when it comes to automated installation. so i am wondering if i can use pseudo for this? i run: "pseudo tar xf the-rootfs.tar.xz" but that breaks with error, i think when creating the device notes, so same like when i do tar without sudo.. Sep 03 07:57:22 good morning Sep 03 08:19:01 okay, found a way: echo | sudo -S tar xf the-rootfs.tar.xz Sep 03 08:19:17 but maybe anyone here as a nicer solution? Sep 03 09:41:16 ericbutt1rs: if device nodes are indeed a problem can't you just do tar --exclude=/dev/ -xJf the-rootfs.tar.xz ? Sep 03 10:01:22 morning all Sep 03 11:15:10 bluelightning: can I get the recipe for open-vm-tools from any of the yoctoproject repos ? Sep 03 11:27:07 why the hell does ruby need tcl to build Sep 03 11:27:26 or more accurately why does ruby claim to need tcl, but ruby-native doesn't and it built fine without a host tcl Sep 03 12:00:16 Hi everyone Sep 03 12:05:10 Guys I have a workflow question. Sep 03 12:06:26 I want to modify the linux kernel. Can I modify directly the sources to try and then generate the recipe? Sep 03 12:07:32 Should I commit my modification in a my dev branch of the linux kernel and then make the diff once I'm happy with that? Sep 03 13:13:49 https://github.com/meta-qt5/meta-qt5 How can I check the version of Qt they have integrated inside this layer guys? Sep 03 13:15:09 betchou: https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/qt5 <— the log says 5.5 Sep 03 13:16:21 rburton: Yep I am asking on the Qt channel the corresponding version of QtQuick modules inside. Thanks! Sep 03 13:16:46 rburton: Layout.margins got introduced in QtQuick.Layouts 1.2 ... Sep 03 14:05:55 where are getting the symlinks created for systemd? i am missing a link to multi-user.target.wants and i need to "debug" this Sep 03 15:20:36 gm fray - looks like enabling neon in rpm still doesn't result in rpm being able to install packages via urls. any other ideas on what I should try enabling? Sep 03 16:40:35 joshuagl, rburton, RP, halstead, sgw: We're going to be rebooting the AB cluster once this build is done. Please, no queuing builds until then. Sep 03 17:20:45 Has anyone written a script to print the status of a push to an upstream layer by checking master, master-next, and possilby also ross/mut or ross/mut2? Sep 03 17:24:09 Hmm, anyone have any thoughts on sstate-distro-fallback.bbclass? (https://github.com/MentorEmbedded/meta-mentor/blob/52c5c186cfb4edebe67c4271eafc92d14b2e3cba/meta-mel/classes/sstate-distro-fallback.bbclass). the comment at the top describes the behavior. Does it seem like a sane approach? I should rename it to something related to sstate native distro compatibility rather than fallback, accurate as the latter is, for clarity. lets you set compatible Sep 03 17:24:09 distros, and it'll try to fetch compatible native sstates from your sstate mirrors, not just local. We had a different mechanism, previously, so I'm curious about the new approach, does it seem like a reasonable mechanism? Sep 03 17:25:19 RP: are you planning on postponing the git shallow mirror tarball support to post-2.0 for risk reasons? that'd be reasonable, if so, I just happened to notice it wasn't in the release status merge list. would it help if i wrote some additional fetch unit tests to cover some of its behaviors? Sep 03 17:31:01 kergoth: so how will one generate such a sstate Sep 03 17:31:54 the idea is when you do a build on an older distro, those native sstates can be used on newer distros. so you can do your automated builds on the oldest distro you support, and the distributed sstate will be used on any newer compatible distro by your customers Sep 03 17:32:10 e.g. we used to do builds on centos6 to ensure the natives oculd be used on any recent distro Sep 03 17:32:24 currently, a native sstate is only usable on a matching distro Sep 03 17:33:24 isn't it easier to ship LXC archive together with the release? Sep 03 17:33:49 yep, that's another option, make your users do their builds in a chroot, container, or vm Sep 03 17:34:56 kergoth: sounds ok but it needs to be tested on those distros by using them otherwise we are opening a support hell Sep 03 17:35:09 I think build appliance is the way to go Sep 03 17:35:31 I was comparing the build time between native and LXC builds and it was identical so in the end I wrote some script for jenkins that the job can select under which LXC container it will be executed Sep 03 17:35:46 I wouldn't expect to enable use of compatible distros for native sstate by default, i'd just like to provide the class somewhere for the user to use if they choose to go that route Sep 03 17:35:51 so we can continue to build older releases under older host distributions and newer ones on newer Sep 03 17:36:05 kergoth: I think its useful Sep 03 17:36:27 JaMa: do you use lxc or docker or nspawn Sep 03 17:36:29 yeah, i do all my builds on my machines under a container/chroot, and have for a long time now. formerly schroot, now pflask (which is like systemd-nspawn) Sep 03 17:36:36 khem`: lxc Sep 03 17:36:40 I use nspawn quite successfully Sep 03 17:37:01 reduces build contamination issues too, since while there may be such issues, at least the contamination doesnt' *change* over time Sep 03 17:37:03 heh Sep 03 17:37:17 khem`: our servers are on Ubuntu 14.04, LXC is very well supported there and docker feels to application-oriented Sep 03 17:37:24 nspawn is good, i wish it was packaged separately (course i wish that for half the projects in systemd) Sep 03 17:37:42 s/to/too/g Sep 03 17:38:00 kergoth: systemd now has login shell too btw starting 225 Sep 03 17:38:02 agreed, docker and similar things do seem more app container oriented. you can use them for bitbake, but you need to sort out the interactions across the boundary, whereas with chroot or a light container you can make it nearly transparent Sep 03 17:38:33 yes, I was using plain chroot until recently Sep 03 17:38:48 LXC is just small step from it to make it easier managable without root/sudo access Sep 03 17:38:54 khem`: i think systemd is less monolithic than people think, in that its components aren't all tightly bound, but it *does* consume everything into its umbrella / repo / project, which is slightly irritating Sep 03 17:39:01 JaMa: agreed Sep 03 17:39:21 good bye "su" :) Sep 03 17:39:41 what i like about pflask or systemd-nspawn vs some of the alternatives is it's self contained. the command-line includes everything, no config files to set up, etc Sep 03 17:39:47 not sure if lxc is that way or not, haven't played with it much Sep 03 17:40:18 there is small config for lxc if you're not completely happy with defaults Sep 03 17:40:35 but for our build claster use-case, I host whole container including the config on NFS Sep 03 17:40:46 ah, thats cool Sep 03 17:41:39 we already run in openstack env Sep 03 17:41:48 so VM on VM is sort of overkill Sep 03 17:42:10 its easier to start/stop a new node Sep 03 17:43:32 JaMa: the thing is, if you're in a situation like an OSV or chip vendor where you ship layers and bitbake to a customer, having them use containers / vms isn't necessarily trivial, because everybody has their own preferences there. unless it's completely transparent, folks will want to use whatever their tool of choice is. i guess as long as you ship the rootfs, you can leave it up to them what to do use to run the thing.. Sep 03 17:44:18 I'm a big fan of transparently offloading bitbake to the container and keeping your development environment outside, as who wants to set up your dev env yet again in the vm? Sep 03 17:44:25 heh Sep 03 17:44:43 containers offer both Sep 03 17:45:00 yeah, precisely. vms are tougher to do that with Sep 03 17:45:05 doable, but more overhead Sep 03 17:45:09 I mount the datadisk at same mount points in container and on my host running my favourite distro Sep 03 17:45:13 works seemlessly Sep 03 17:45:17 * kergoth nods Sep 03 17:45:57 I wonder if anyone's written a lightweight wrapper around running something in a container to hide whether it's using lxc, systemd-nspawn, pflask, etc under the hood Sep 03 17:48:21 kergoth: good question github might have answers Sep 03 17:48:29 * kergoth nods Sep 03 17:48:36 * neverpanic hates that almost none of those container tools get pseudo terminals right :/ Sep 03 17:49:00 kergoth: I see, I would ship container as alternative if customer wants reliable, tested environment which will most likely reuse everything from sstate and won't show any new host contamination issues Sep 03 17:49:33 if they decide against it, then your bbclass will help at least to reuse more sstate :) Sep 03 17:49:50 may be there should be fido build appliance and so on Sep 03 17:50:00 with prepopulated sstate Sep 03 17:50:56 khem`: you seem to believe a lot in prepopulated sstate, are you really seeing so great sstate reuse between different builds? Sep 03 17:51:33 we're generating around 2TB of sstate per month Sep 03 17:51:37 no but if build appliance is containersized I expect it to be more Sep 03 17:52:02 and most our builds are performed on the same host distro, same OE release with only smaller changes in our apps and libs Sep 03 17:52:10 but it's true we have big images Sep 03 17:52:17 I still believe that feed based mechanisms are still preferred Sep 03 17:52:38 the reason why debian became instant hit on rpi and bbb is the proof Sep 03 17:53:00 angstrom was on same way but debian just is a steam roller Sep 03 17:53:01 right now I'm debugging some issue in fontconfig cache and every change to fontconfig causes only maybe 20% sstate reuse Sep 03 17:53:33 JaMa: the problem is fundamental, the devs of components dont use cross build envs Sep 03 17:53:44 is someone using fontcache.bbclass on read-only file system? Sep 03 17:53:45 so sstate is totally a foreign thing for them Sep 03 17:53:49 JaMa: Did you ever try building the source with ccache? Sep 03 17:54:00 so we will always play the catching game Sep 03 17:54:29 neverpanic: yes with mixed feelings about the outcome Sep 03 17:54:46 the same does apply for icecc Sep 03 17:54:46 So no significant speedup? Sep 03 17:54:51 We should pay more attention to binary feeds IMO Sep 03 17:55:00 Yeah, I've had mixed experiences with icecc as well Sep 03 17:55:30 with SSDs, distributed compilinng is nullified IMO Sep 03 17:55:41 i think shipping sstate mainly gives you a good out of box experience for builds, that initial build is fast, even though they'll shortly be making modifications that'll cause everything to rebuild from scratch Sep 03 17:55:52 the problem is 30% of time is spend in preprocessing and that still happens on one machine Sep 03 17:56:12 so icecc and distcc made sense with slow HDs Sep 03 17:56:14 not now Sep 03 17:56:18 but out of box experience is important. shrink to the 'time to magic' (https://medium.com/bolt-blog/min-time-to-magic-c938d9ea3473) Sep 03 17:56:41 icecc/distcc always had a certain amount of overhead -- if the compile time is too small, the overhead is more statistically significant.. Sep 03 17:56:54 neverpanic: significant speedup when testing it on rebuilding the same recipe over and over, but for rebuiding big image the speedup was gone (possibly because of ccache size being too small) Sep 03 17:56:59 khem`: i'd like to see us support non-cross / native builds at some point.. Sep 03 17:57:25 kergoth: we should have paid attention to binary feeds Sep 03 17:57:40 with OE-Core we never prioritized it Sep 03 17:57:44 agreed. at least oe-core provides an ability to build images from a feed nowadays Sep 03 17:57:49 distros like angstrom sufferred Sep 03 17:58:10 there is one thing to provide knobs, supporting it is another thing Sep 03 17:58:12 it's unfortunate, you're right about beagle & debian, folks want to be abl eto just apt-ge tinstall their favorite app Sep 03 17:58:26 would be nice if more yocto-oriented distros provided that capability Sep 03 17:58:34 and one may say oh those are hacker SBCs Sep 03 17:58:39 but then you have public-facing servers and load to deal with Sep 03 17:58:40 but thats what gets a distro in house Sep 03 17:58:49 kergoth: khem` icecc still looks amazing when you benchmark it on huge icecc cluster by running qtwebengine.do_compile task which can spawn really *a lot* of parallel tasks Sep 03 17:58:53 i guess it depends on who your customers are Sep 03 17:59:17 but then when you benchmark build of whole image then the difference is far from significant Sep 03 17:59:43 kergoth: as the smaller systems become capable OE big distros will get into them Sep 03 18:00:09 people dont want to deal with system builds Sep 03 18:00:30 let that to small subset of debian or fedora or arch hackers Sep 03 18:00:46 there still will be place for it Sep 03 18:00:47 * zeddii has been working on that model, just to see how well it works. Sep 03 18:00:52 but reduced over time Sep 03 18:01:29 FWIW: SHR still provides binary feeds :) but I haven't updated the official ones to newer OE releases, because almost nobody is using it now Sep 03 18:01:43 my concern with binary feeds is always configuration changes that change abi Sep 03 18:01:52 we had rolling release models way before others Sep 03 18:01:53 so it shrinked into my personal testing ground Sep 03 18:01:54 how do you encode that to ensure incompatible feeds aren't used Sep 03 18:03:15 kergoth: you mean feeds from different builders? Sep 03 18:05:09 even with feeds from the same builder I rarely do "opkg upgrade" since I started to use PRserv.. upgrading 90% of installed packages takes much longer than reflashing the image Sep 03 18:11:34 JaMa: yeah, or just different build directories, or tweaks to local.conf that alter overarching policy, like user overrides of distro features Sep 03 18:11:45 if you have a feed uri configured for hte resulting image, it could point at an incopmatible feed Sep 03 18:11:54 wonder how angstrom deals with that Sep 03 18:12:02 or if they only configure it for official builds Sep 03 18:13:07 I would expect these different build directories to have different binary feed and different feed-urls in images produced by them Sep 03 18:13:22 that's how we were building different releases on the same server Sep 03 18:14:19 people still could switch from unstable to testing on the device, but such upgrade path wasn't supported and in most cases ended with broken image Sep 03 18:14:50 i'm more concerned about user rebuilding things from source, but i guess as long as their custom builds don't include feed configuration, you'd be okay Sep 03 18:39:00 kergoth: right now the angstrom feeds cater to systems using angstrom default distro policy if thre are changes to that Sep 03 18:39:18 then I dont think it has any guards for wrong usage of feeds Sep 03 18:39:50 however the major imcompatibilies like hardfloat and thumb2 etc. should be taken care of Sep 03 18:39:58 already Sep 03 18:40:17 but now a days there are so many other knobs to make it incompatible Sep 03 18:54:25 khem: yeah, that's always been my concern, there's no real way to encode the configuration into the packages. which is expected, just troublesome for support without some form of guards for it Sep 03 18:55:21 yeah Sep 03 18:55:45 OE is a src based distribution period Sep 03 18:55:53 I have come to terms with it Sep 03 19:47:52 hmmm Sep 03 19:48:22 archiver.bbclass doesn't grab git mirror tarballs. should add that. i think in most cases it'd be better to pull that than the git2/ subdir Sep 03 19:48:28 if it exists, at least Sep 03 19:57:39 kergoth: I am thinking of deferring the shallow clone piece, yes Sep 03 19:58:03 kergoth: There are just too many other issues atm without a potentially cranky git fetcher :/ Sep 03 19:58:22 kergoth: that stuff tends not to test well on the autobuilder, only in the real world Sep 03 20:00:36 Yeah, I hear you. fetch is tough since a big part of it is the current state of DL_DIR vs upstream, and it's extremely tough to test every combination of those. automated builds tend to start fresh, or from a known good mirror Sep 03 20:01:09 we might need to carry a fork of bitbake/poky for the next mel release, though. we distribute sources to the customer, and full kernel tarballs are freaking massive :) Sep 03 20:01:37 how about pseudo upgrade patch ? it makes me nervous too Sep 03 20:01:47 pseudo can bring lot of grief Sep 03 20:01:54 every pseudo change makes me nervous, it's so critical to us Sep 03 20:02:00 all of us, that is Sep 03 20:02:34 and I would like to propose a consistent branching across oe-core and bitbake this time Sep 03 20:02:51 its quite confusing to relate 1.26 = fido Sep 03 20:03:04 and there are no other consumers of bitbake Sep 03 20:03:11 that I know of besides OE Sep 03 20:03:25 hmm, not sure how i feel about that, bitbake has its own scheme, always has, we aren't going to revamp its versioning scheme anytime soon, i wouldn't think Sep 03 20:03:54 kergoth: something to think about though Sep 03 20:04:02 technically oe-core still leverages part of bitbake, i think, but they probably have their own fork of it Sep 03 20:04:05 er, oe-lite Sep 03 20:04:07 the release could still be 1.xy Sep 03 20:04:23 but branch code could be more exotic Sep 03 20:04:27 game name Sep 03 20:04:45 hmm, true. keep 1.xy for the tags Sep 03 20:04:47 * kergoth shrugs Sep 03 20:06:08 I would even propose to not call reference distro as poky Sep 03 20:06:28 for YP that is Sep 03 20:07:04 and may be reflect YP release and name directly Sep 03 20:07:24 what bugs me a little is the delta between distroless and poky. if something is good enough for the reference distro, why isn't it default? Sep 03 20:13:02 kergoth: the delta really isn't that much anymore Sep 03 20:13:26 kergoth: any particilar variables you're concerned about in particular? Sep 03 20:17:34 overriding default TMPDIR Sep 03 20:26:54 RP, you around? I got your message about the additional breakage, but the link you sent me was to a build report that I am not very familiar with and I am not sure what I am looking for in it. Sep 03 20:27:29 I am suspecting it will turn out to be another case where something was supposed to get allocated but didn't, but I am not as sure how I would find it or test it. Sep 03 20:30:27 seebs: I'm here Sep 03 20:31:35 seebs: the key link from that first page is https://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/469/steps/BuildImages/logs/stdio Sep 03 20:32:10 seebs: read that one backwards, at the end it says it attempted five do_rootfs tasks and they all failed Sep 03 20:32:30 ohhh. Sep 03 20:32:33 seebs: you then scroll back and see five different rootfs failures, all looking similar where execute permissions disappeared Sep 03 20:32:44 Oh-hoh! I think I may know what's causing that. Sep 03 20:32:46 seebs: all with opkg Sep 03 20:33:49 Weird, I thought I was building with opkg (before I was building with rpm) and it wasn't doing that to me. But... Sep 03 20:35:29 Is it possible for me to get access to one of the failed build directories to compare with? I am not 100% sure whether it'll reproduce for me yet, even though in theory I assume it should. Sep 03 20:36:28 There is a thing I think is suspicious, but comparing notes, I'm pretty sure that the behavior shouldn't actually have changed there. Sep 03 20:36:39 halstead: could we get seebs ssh access to debian8? Sep 03 20:36:42 If it is, it's probably a result of the umask bug fix. Sep 03 20:36:52 halstead: my own ssh access doesn't appear to be working :/ Sep 03 20:37:44 seebs: right now the builddir doesn't appear to have been reused Sep 03 20:38:04 The obvious question would be what the real fs modes are for the affected files. Sep 03 20:38:12 And I guess what the command is which produced the warning. Sep 03 20:38:23 Like, was it doing 'sh /path/to/script' or something else. Sep 03 20:38:39 seebs: for the latter, its however opkg runs its postinsts Sep 03 20:38:50 seebs: the former I can't see as my own access isn't working Sep 03 20:38:50 Huh. I have no idea. I will have to investigate. Sep 03 20:39:05 Well, a build shouldn't take super long, and I have other stuff running too. Sep 03 20:39:14 There's a umask fix that became necessary because of the xattrdb stuff, but should be more-correct regardless. Sep 03 20:39:30 seebs: particularly as a core-image-minimal appears to reprocude Sep 03 20:39:35 Neat! Sep 03 20:40:15 seebs: the multilib builds also failed with this fwiw Sep 03 20:40:28 Basically, if you have umask 777, files really do get created with an underlying mode 0, so I added a thing that chmods them to 0600... aaaand I just thought of a conceptual flaw in that thing. Sep 03 20:41:11 Maybe not. This should only happen if the file did not previously exist, and openat() can't make new files. Sep 03 20:42:37 ... Although looking at it, the code is actually gratuitously complicated, because I'm calling PSEUDO_FS_MODE(0600, 0), which is just 0600. Sep 03 20:42:56 But a lot of things are now getting chmod'd to 0600 in the underlying filesystem, which weren't previously. Sep 03 20:43:11 But they should all be plain files. But if something's trying to exec them, that could maybe do it? Sep 03 20:43:54 I am also a little surprised that my local tests did not run into this, so I am now extra curious. Sep 03 20:52:26 kergoth: should i test something? is this the pseudo patch in the mailing list from the other day? Sep 03 21:43:49 There's at least one observed problem with 1.7.1, which (oddly enough) did not happen previously when I was testing, but go figure. Sep 03 21:43:55 I am pretty sure I did a full rebuild without sstate cache after I did my big patch-cleanup-and-rebase, and yet, now things are failing. *sigh* Sep 03 21:44:11 ... oh, lovely. RP, I do not reproduce the failures you had. But! I get coredumps from locale gen. (I was doing -base.) Sep 03 21:50:12 kinda sucks when you can't build your locale... Sep 03 21:54:52 seebs: hopefully halstead might be able to get you access to the one that failed Sep 03 21:55:18 (if you need it) Sep 03 21:57:05 I am annoyed, the locale build won't coredump for me when I run it manually. Sep 03 21:57:18 But I have a PLAN. Which involves modifying the bbclass to do "valgrind cross-localedef" and hoping this works. Sep 03 21:59:54 So, I expect to make progress, I do not know how long it will take, but. I can usually eventually track these down. Sep 03 22:01:33 seebs: fair enough. It is getting late in the release cycle for this though :/ Sep 03 22:01:46 Yeah. Sep 03 22:02:39 It is funny to me that the performance difference from the xattr change (which I expected to be huge) turned out to be about 1/3 the difference from the alloc/free and reduced operation spam changes. Sep 03 22:03:30 This is why profiling is a big deal. Sep 03 22:04:09 Huh, that's odd. I can indeed finish a build of core-image-minimal on my target system, I believe using opkg. So there may be a host dependency. Sep 03 22:04:15 Well, I can check that, I suppose. Sep 03 22:05:07 I have an ubuntu-or-so which ought to be more similar to a debian build machine. Sep 03 22:05:58 seebs: you'd have thought so. You're sure its building the rootfs using opkg? Sep 03 22:06:15 I'm... pretty sure? I reverted the config change that made it use RPM. Sep 03 22:06:25 And it's totally possible for there to be strange host dependencies in some of this. Sep 03 22:07:02 based on the stdio log, it looks like it's processing post install scripts.. so the more you process the more likely to trigger the fault.. Sep 03 22:07:22 you could probably rig up some test recipes/packages.. otherwise core-image-sato is more likely to have them (but will take longer to build) Sep 03 22:08:18 fray: fwiw all do_rootfs failed on the autobuilder :/ Sep 03 22:08:56 also centos7-a failed with https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/480 which looks like the same issue Sep 03 22:09:08 (follow the stdio links) Sep 03 22:09:15 hmm. Sep 03 22:10:01 seebs: ipk is default when its listed first in PACKAGES_CLASSES (as package_ipk) Sep 03 22:10:18 basically the first listed is used for rootfs construction Sep 03 22:11:24 Yeah, it's definitely opkg, so. Sep 03 22:11:50 More testing to see if I can make it happen. Just in case, I am retesting using the actual tarball I sent you in case I did something really clever like make the tarball with the wrong patches. Sep 03 22:15:18 seebs: time for me to sleep, 'night! Sep 03 22:47:55 Interestingly, core-image-minimal did trigger it for me with an Ubuntu host. So that's sort of not-encouraging. But I have the failure now! Sep 03 22:55:52 Okay, so apparently the opkg build under some redhat variant did not create as many postinst scripts as the other did, and I am not at all sure why. I may have only partially fixed the config. Sep 03 22:56:22 And the problem appears to be that opkg is running "sh -c postinst_script", which fails if there's no execute permission. Sep 03 23:01:39 ... Okay, found it. I used to be setting modes to ((given mode) | 0600 | (0100 if isdir)) & ~022 & ~umask Sep 03 23:02:14 and when I fixed the implications of the ~umask being able to break stuff, in some cases there was no way to check isdir, but I didn't or in the given mode, just the 0600. Sep 03 23:12:19 ... It turns out this was a documented limitation, I found the comment that you can't expect things to work with 0700 umask. Sep 03 23:29:25 does it exist a ${etcdir} Sep 03 23:53:18 ---------- Sep 03 23:53:23 poky$git grep -w etcdir Sep 03 23:53:23 meta/recipes-bsp/pcmciautils/pcmciautils.inc:export etcdir = "${sysconfdir}" Sep 03 23:53:23 meta/recipes-devtools/quilt/quilt/install.patch:-etcdir := $(subst /usr/etc,/etc,$(prefix)/etc) Sep 03 23:53:23 meta/recipes-devtools/quilt/quilt/install.patch:+etcdir := @sysconfdir@ Sep 03 23:53:23 poky$ Sep 03 23:53:25 -------------- Sep 03 23:53:46 compare that to the same commands for bindir and you be the judge. :) Sep 03 23:54:16 (and hint, the output above shows you what you really want) Sep 04 00:59:55 paulg_: also silly me found this at the documentation http://docs.openembedded.ru/directories_installation.html Sep 04 01:50:31 ... Sep 04 01:50:40 So it turns out, I now know why the opkg problem never showed up when I was running my tests. Sep 04 01:50:51 Because it doesn't show up with opkg 0.2.4, and the uprev of 0.3.0 showed up on September 1st. Sep 04 01:51:07 Yay, mystery solved. **** ENDING LOGGING AT Fri Sep 04 02:59:58 2015