**** BEGIN LOGGING AT Wed Aug 05 02:59:58 2015 Aug 05 03:17:33 * kergoth tests builds with pkgconf instead of pkg-config for the hell of it Aug 05 04:57:23 hmm, would be nice if buildhistory-diff had an option to exclude PR/PKGR changes entirely, including indirect results of that change like version fields in RDEPENDS Aug 05 07:49:05 I'm using a yocto generated sdk to compile a qt program with cmake, but the yocto installed cmake config looks to be wrong... It refers to a OE_QMAKE_PATH_EXTERNAL_HOST_BINS which is empty Aug 05 07:49:37 Can I used cmake FindPackage, and point it at the yocto sys root and expect things to work? Aug 05 08:19:30 morning all Aug 05 08:27:55 bluelightning: morning :) and morning to all others also ! Aug 05 08:45:28 hey, how to include *.so and .h file correctly in rootsys?(I don't have the source) Aug 05 08:46:19 wrock: just install them to the appropriate location in do_install and ensure they get packaged with appropriate FILES_ if needed Aug 05 08:51:58 wrock: you may find the bin_package class useful Aug 05 08:52:13 http://pastebin.com/jWvumWJg Aug 05 08:52:18 i just ctesting this Aug 05 08:52:28 k, i'll take a look Aug 05 09:03:01 belen1: ping Aug 05 09:06:27 hi sujith_h Aug 05 09:09:55 belen1: Is this : https://wiki.yoctoproject.org/wiki/Contribute_to_Toaster the wiki to follow to post a patch for review in toaster? Aug 05 09:12:16 sujith_h: yes :) If you have any questions, ping me or michaelw Aug 05 09:15:11 belen1: Oh yes. I have a query with command "git push poky-contrib submission:ownname/bitbake_submission" as I am getting error http://pastebin.com/Se4jXwwt Aug 05 09:17:33 sujith_h: that's because you need push access to the poky-contrib repository. That can be arranged Aug 05 09:17:40 sujith_h: instructions are here https://wiki.yoctoproject.org/wiki/Poky_Contributions#Poky_Contrib_Branch Aug 05 09:20:40 sujith_h: I'll email you how to get in touch with Michael Aug 05 09:21:03 sujith_h: if you're just sending a single patch, you can just use "git send-email" as the wiki page says Aug 05 09:21:23 belen1: sure Aug 05 09:21:29 jku: its a single patch Aug 05 09:22:07 jku: this is for toaster though. Our submission process is slightly different. Patches must go to the toaster mailing list first Aug 05 09:23:35 belen1: ok, good to know Aug 05 09:33:25 bluelightening: Ok it worked! i just installed it in etc/lib instead of usr/lib but it is there Aug 05 09:35:50 ...or should it be there? Aug 05 09:36:12 i actually just install it in ${D}${sysconfdir}/include/ Aug 05 09:38:14 nvm Aug 05 09:38:20 thanks for help Aug 05 09:45:26 wrock: /etc would be a very strange place to install anything other than config files or initscripts Aug 05 09:46:14 wrock: /usr/include (or ${includedir}) or some subdirectory below that is the correct place to install headers Aug 05 09:47:50 belen: jku git send-email to the mailing list is fine Aug 05 09:50:09 michaelw_: ah, sure, I guess what I meant is to which mailing list :) Aug 05 09:50:59 yes the toaster one Aug 05 10:07:12 bluelightning: i changed etc/lib to usr/lib and now this appears in do_rootfs http://pastebin.com/XF5br7ni Aug 05 10:07:25 recipe was cleaned before Aug 05 10:08:02 wrock: so there's no question, this is a bug Aug 05 10:08:24 wrock: however, it suggests to me that the package has vanished (probably because it's empty) Aug 05 10:08:42 wrock: double-check the contents of the various subdirectories in packages-split under the workdir for the recipe Aug 05 10:09:13 you can find the workdir for the recipe (in case you didn't know) by running: bitbake -e recipename | grep ^WORKDIR= Aug 05 10:23:27 belen: michaelw_: So if I understand correctly, git send-email to toaster mailing list is fine, right? Aug 05 10:27:39 sujith_h: yes, I believe so. Aug 05 10:30:45 belen: ok Aug 05 10:56:01 bluelightning: ok, the files are only in packages-split/recipename-dev and packages-split/recipename-dbg...but they should also exist in packages-split/recipename right? Aug 05 10:56:26 -dev means it is existing in the development stage but not in the packaged image at the end right? Aug 05 10:56:39 wrock: yes, so something has gone awry with the packaging Aug 05 10:57:01 wrock: well, strictly speaking .h files would go in the -dev package so that part is expected Aug 05 10:57:44 but the header file is also needed during runtime Aug 05 10:57:53 er, really? Aug 05 10:58:15 otherwise i can't executed programs which depending on the file? Aug 05 10:58:39 executables don't usually depend on a header... a header is used to link to a library at compile time Aug 05 10:59:42 ehm Aug 05 10:59:44 k Aug 05 10:59:46 might be true Aug 05 10:59:57 ye sure Aug 05 11:00:26 it's always true, unless you are doing some "runtime" compilation a la DKMS Aug 05 11:00:55 yeah, i get it Aug 05 11:01:11 i includeded the file in the recipe with FILES_${PN} +="\" Aug 05 11:01:32 i also tried FILES_${PN} += "/usr/bin/libttinterface.so" Aug 05 11:02:05 *+="\" of course Aug 05 11:02:16 FILES_${PN} = "/" Aug 05 11:03:51 files were installed in ${D} Aug 05 11:03:55 wrock: adding it to FILES_${PN} is needed, but alone that won't cause the file to be moved, because ${PN}-dev appears before ${PN} in PACKAGES and FILES_${PN}-dev already includes .so files (assuming them to be symlinks, since proper versioned library files are typical) Aug 05 11:04:23 wrock: so you need to set FILES_${PN}-dev as well Aug 05 11:06:55 but the file exisits in packages-split/name-dev Aug 05 11:07:49 i jsut recovered the "working" recipe, with the wrong destination Aug 05 11:13:32 wrock: yes, that's what I'm saying - ${PN}-dev is picking up the file, and I've explained (perhaps not very well) how to fix that Aug 05 11:43:13 bluelightning: i actually don't get it, because it is picked up by -dev it can not be picked up anymore? also installing to ${D}${sysconfdir}/include/ works just fine(bbut is the wrong location) but ${D}/usr/lib/ doesn't work Aug 05 12:00:13 halstead: it seems the git server is out of space Aug 05 12:00:17 otavio@nano ~/src/yocto/sources/meta-fsl-arm (git)-[pending] % git push yocto 09a532cf3c7990fe2acb7cfde59181429f1e94bf:master :( Aug 05 12:00:21 close log failed: No space left on device Aug 05 12:00:23 and the repository exists. Aug 05 12:00:25 fatal: Could not read from remote repository. Aug 05 12:00:28 Please make sure you have the correct access rights Aug 05 12:01:50 wrock: the directories in packages-split/ represent the contents of the various packages that the recipe produces. Two different packages of course can't contain the same files Aug 05 12:02:08 wrock: What (I believe) bluelightning was trying to say is that the default rules for FILES_${PN}-dev include the .so files: if that shoudn't happen for you, then you need to set FILES_${PN}-dev yourself (overriding the default) Aug 05 12:05:14 jku: ah ok makes sense Aug 05 12:05:22 seems to work now :D Aug 05 12:05:25 thy Aug 05 12:17:48 wrock: the way it works is, the packaging code iterates through the items in the PACKAGES variable value, and the first one whose FILES_ value matches the file, gets the file Aug 05 12:35:01 otavio: yes, we're waiting on halstead to wake up to clean some of it up. Aug 05 12:45:24 bluelightning: ye now I get it, Aug 05 12:49:10 but can I compile a file now, which depends from tha *.so? Aug 05 12:49:19 I mean it is installed now Aug 05 12:49:36 but doesn't have the compile enviroment his own room? -dev Aug 05 12:50:33 naturally if you are doing actual compilation (linking to the library) and the header file is in the -dev package, you will need that installed Aug 05 12:51:09 actually are you talking about compilation on the build host or on the target ? Aug 05 12:51:22 build host Aug 05 12:51:47 right, in that case the header and library will have been staged to the sysroot automatically Aug 05 12:52:33 if you use ${CC} as the compiler it should set the right sysroot and the header/lib should be picked up Aug 05 12:53:12 Hi! Are patches adding compatibility support between yocto versions accepted? I'd like to backport testsdk from master to dizzy and the changes and checks are not bad for master either, IMO. Aug 05 12:57:19 bluelightning: how? i have an "undefined reference to " error, I interpret that as header found, but not *.so Aug 05 13:09:30 wrock: is that the only error you're receiving? Aug 05 13:09:51 wrock: if so, are you specifying -l to actually link to the library? Aug 05 13:10:48 mcfrisk: normally we don't backport features, but I think for test functionality we might make an exception assuming the tests work Aug 05 13:11:11 mcfrisk: also any changes from master need to be in fido before they can be in dizzy Aug 05 13:14:39 bluelightning: actually yes, I tried -lttinterface (libttinterface.so is the name) the file is now in usr/lib, so there is no need for linking the directory Aug 05 13:15:38 wrock: if it were not finding that then you would get an error about not finding the library surely? Aug 05 13:18:37 bluelightning: I have the exact same error undependently if the *.so is isntalled or not Aug 05 13:19:18 wrock: I don't know what to suggest then... Aug 05 13:19:28 pidge: oh ok, no problem Aug 05 13:19:42 pidge: just to notify Aug 05 13:21:08 bluelighting: ok,np, thanks anyway.:) Aug 05 13:21:30 bluelightning: or lets say thanks for everything up until now Aug 05 13:31:40 otavio: I am seeing http://meta-freescale.yoctoproject.narkive.com/4KiI8AFk/packagegroup-core-x11-utils-errors on one of the AMD machines with deb packaging Aug 05 13:31:58 otavio: you commented back then, is there any more info? Aug 05 13:44:46 <[Sno]> bluelightning: see https://github.com/rehsack/meta-jens/commit/b25f82e2484a5c6631f1504efea0caba688828e0 - successor of . sources/poky/oe-init-build-env foo ? Aug 05 13:49:03 abelal: not sure it is related to the bsp Aug 05 13:54:33 <[Sno]> btw, otavio - I didn't read a reply on https://github.com/rehsack/meta-fsl-arm/commit/8cc9f5629735f91e5ddb95e2a482b1b457dd5dd7 - do you simply discard it because of ENOTIME or did I miss something? Aug 05 13:56:24 hello. i want to set my root password in my yocto projet Aug 05 13:56:57 inherit extrausers EXTRA_USERS_PARAMS = "useradd -P Imypassword root;" doesn't work Aug 05 13:57:38 does it exist another method? Aug 05 13:59:45 [Sno]: interesting... Aug 05 14:00:04 khalebios: use usermod instead of useradd Aug 05 14:00:27 khalebios: the manual has an error that we haven't been able to republish to fix yet Aug 05 14:00:55 khalebios: also, consider carefully the implications of multiple devices with the same root password in the field if that is your intention... Aug 05 14:01:37 <[Sno]> bluelightning: you can steal if you want for poky ;) Aug 05 14:02:11 thank you bluelightning. i am goning to try it. Aug 05 14:03:02 [Sno]: we should definitely look at it... I'm struggling a bit at the moment with a few different issues (affecting memory resident bitbake) that prevent me from really looking into anything else atm Aug 05 14:03:39 * [Sno] nods Aug 05 14:15:38 i just try : inherit extrausers EXTRA_USERS_PARAMS = "usermod -p my!pass root;" doesnt work Aug 05 14:17:17 khalebios: where are you placing those lines? Aug 05 14:17:30 hey guys, just a FWIW, I've been using OE for many years, I was just watch bitbake doing a build and was thinking just how much of a speed improvement there has been over what we had 5 years ago. Aug 05 14:17:46 kudos Aug 05 14:18:14 in :: micro-base-mytarget-image.bb Aug 05 14:18:14 Fido just slams along! Aug 05 14:18:14 T0mW: thanks... build performance is something we do try to improve (or at least, try not to regress in where at all practical) Aug 05 14:19:37 in my /recipes-bsp/images/ Aug 05 14:20:22 Not just improvements in the host machines are what I'm seeing (i7 + 32G RAM vs. Quad4 + 8G), but moving a project from Daisy --> Fido does show a large performance boost. Nice job. Aug 05 14:21:44 khalebios: you need to use -P not -p Aug 05 14:21:54 khalebios: beware that "useradd -p" takes a crypted password, not the plain text password. Aug 05 14:22:05 pohly: right, that's what I was alluding to Aug 05 14:22:19 when i use -P i get an error Aug 05 14:22:29 khalebios: what is that error ? Aug 05 14:22:39 so how to crypt the password? Aug 05 14:23:56 the erro is : usermod: invalid option -- 'P' .. Aug 05 14:24:22 khalebios: that sounds like your host's version of usermod is being run rather than our patched version Aug 05 14:25:04 ??? Aug 05 14:25:12 so what can i do? Aug 05 14:26:00 khalebios: bitbake shadow-native will work around it; I suspect we are missing a dependency somewhere Aug 05 14:42:36 bluelightning <= how can i get the patch?. Aug 05 14:43:04 i try bitbake shadow-native and nothing change Aug 05 14:44:34 khalebios: which version of the build system are you using? Aug 05 14:46:30 BitBake Build Tool Core version 1.20.0, bitbake version 1.20.0 Aug 05 14:50:50 khalebios: ah, that explains it - that functionality was added in the daisy (1.6) release, you are using dora (1.5) Aug 05 14:51:37 khalebios: so there isn't a practical way to do what you are trying to do with dora other than to encrypt the password and use that with -p, which I'm afraid I don't know how to do myself Aug 05 14:52:02 you may want to consider upgrading particularly considering dora is now no longer officially supported Aug 05 15:06:42 khalebios: I don't know what your situation is but there's also long term support availabe from a few companies. Aug 05 15:10:29 morning Aug 05 15:26:14 monring kergoth Aug 05 15:28:29 er... morning, that would be Aug 05 15:45:41 bluelightning, RP: Any thoughts on implementation for https://bugzilla.yoctoproject.org/show_bug.cgi?id=7958#c3 ? Aug 05 15:45:43 Bug 7958: enhancement, Medium, 1.9 M3, richard.purdie, NEW , Implement shallow git clone functionality Aug 05 15:47:00 kergoth: hmm, there's a lot more to this than I'd appreciated Aug 05 15:47:11 Crofton|work: I managed to get scipy working (along with ipython, etc) , with some horrible hacks Aug 05 15:47:27 Crofton|work: it definitely still needs some cleaning up Aug 05 15:49:16 bluelightning: that about sums it up for me too. I still think there's value, but I'll have to make sure it doesn't interact badly with other recipes sharing the same repository in any circumstances.. i'm tempted to just roll a new fetcher that subclasses git and works in its own area of DL_DIR and decides when to pass the buck to the original. also, ideally it'd try to fetch the shallow git tarball, and if that fails then try to fetch the non-shallow git Aug 05 15:49:17 tarball, and only then try to actually clone, but of course bb.fetch assumes a single mirror tarball path, so it'd have to call try_mirrors() itself after mangling the urldata, to pull that off, i think.. Aug 05 15:49:19 * kergoth ponders Aug 05 15:50:03 kergoth: I think creating a separate fetcher was RP's initial conclusion as well Aug 05 15:50:57 to integrate it fully, we'd have to deal with knowing when to convert from shallow to full on the repo in ${DL_DIR}/git2/, and i think it'd be nicer to be able to assume that any repo there is a full one Aug 05 15:50:58 k Aug 05 15:51:54 Hmm, I actually kind of like the idea of always trying to fetch a shallow tarball and use one if it's available, by default, across the board, unless doing active development, just only *emit* shallow tarballs on request Aug 05 16:12:09 how well does SMART work in a scripted environment? I need to do cumulative upgrading of packages against the initial image release. e.g. all past upgrades would be included within bundle containing newer packages. Do I use the --quiet interface, redirect the output to a file, then test the return value of the smart execution? Aug 05 16:12:28 Would SMART stop and ask for operator input in quiet mode? Aug 05 16:21:14 RP: pidge: builders are all idle, may I queue an AB run? Aug 05 16:25:35 joshuagl: sure Aug 05 16:29:14 * joshuagl queues Aug 05 16:46:37 T0mW: given that we use smart to build images, i have to assume it's possible to run it without input :P Aug 05 16:46:40 beyond that, no idea :) Aug 05 16:47:04 kergoth: IOW, "let us know" Aug 05 16:47:09 heh Aug 05 16:47:31 heh. i'm sure someone here knows, sadly i'm not an rpm guy Aug 05 16:47:36 problem is the dependancy trees Aug 05 16:47:38 i should use it more often, i do love a lot of its features Aug 05 16:48:11 that is why i want to use smart, avoid building out a dependancy tree. Aug 05 16:49:21 sadly, the industry this product is going into has a low computer literacy. So, remote web repos are out, as well as "login as root..." Aug 05 16:51:05 Just wish we were like some companies out there, they won't allow their distributors or end-customer to do any equipment setup / software upgrades. You have to schedule a factory tech to come onsite. Aug 05 16:51:43 that way, you only have one idiot^H^H^H^H person to train. Aug 05 17:26:25 Hi all. I've created a recipe that uses autotools to configure/build/install things, however the do_compile() task is reporting nothing to compile. If I manually cd into the working dir, I can see that the makefile was created and everything is ok. If I try to 'make', it identifies it has stuff to build. Any ideas what is missing? Aug 05 17:27:55 by default, we use separate build and source directories. if that particular project can't handle it, that'd explain the problem. see if inheriting autotools-brokensep rather than autotools solves it Aug 05 17:30:49 kergoth: that did fix it Aug 05 17:31:22 How can I change the project to handle things as yocto expects? Aug 05 17:32:42 see the autoconf/automake manual. really depends Aug 05 17:33:07 automake usually deals with it itself, so i'm assuming this is autoconf-based but not automake, which means the makefiles could require hefty changes to deal with it Aug 05 17:34:26 kergoth: thanks, I'll take a look and try to make things work. Thanks for the help! Aug 05 17:35:03 np Aug 05 17:40:24 kergoth: do you have any idea of what exit code 139 in do_package() means, or where can I find this information? Aug 05 17:40:39 bitbake was always very informative. However now it only gave me this error Aug 05 17:41:05 off the top of my head, exit code 139 is usually a segmentation fault. https://duckduckgo.com/?q=unix+exit+code+139&t=ffab Aug 05 17:41:18 so something package runs is crashing / dumping core Aug 05 17:42:54 kergoth: got it. Any idea how can I debug this? Aug 05 17:43:10 It's a sigsev signal Aug 05 17:43:16 not offhand, you'd need to determine exactly which process is crashing with segfault Aug 05 17:43:20 yes, that's what i said — segmentation fault Aug 05 17:43:31 that's what sigsegv is :) Aug 05 17:43:36 Yup :) Aug 05 17:44:04 but again, wont' be able to do much until you know exactly what program is the one crashing with it. your logs should show that Aug 05 17:44:19 beyond that, there are the usual means of debugging segmentation faults. catchsegv, run under gdb and bt, etc Aug 05 17:45:36 kergoth: it's the do_package of a recipe that doesn't have a custom do_package task. It's just using the default one. However, I have defined some files in FILES_{PN} to be installed. Probably this is what's causing the segfault Aug 05 17:45:56 that's tremendously unlikely Aug 05 17:46:05 something is very broken in your setup for anything in that process to segfault at all, ever Aug 05 17:46:38 That's what I'm thinking Aug 05 17:46:48 Trying to figure out what it is exactly Aug 05 17:50:36 Hmm,, I wonder if I should bring back the tracebacks on ExpansionError, just not ParseError, and then filter the entries to exclude those in bitbake itself Aug 05 17:50:53 could be useful when e.g. ${@foo(d)} and foo calls something which calls something else which raises an exception Aug 05 17:50:54 kergoth: I've managed to get some more info. Apparently I was passing some hardcoded paths inside a FILES declaration, and that was causing the task to sigsev Aug 05 17:51:16 but again, you need to figure out *what* is segfaulting in that task Aug 05 17:51:24 is it the bitbake python prcoess itself, or one of many child processes it runs? Aug 05 17:51:42 packaging runs a ton of programs to split apart the binaries to pull debug info, gather dependency information,e tc Aug 05 17:53:11 No idea which process was sigsev'ing. Does it interest you as a kind of bug report or something like that? I can look into the issue with detail tomorrow if it does. For me, it was a mistake on my part when giving hardcoded paths instead of relative ones Aug 05 17:53:35 no matter what you give it, it should not be segfaulting Aug 05 17:53:54 that said, its probably something broken in your environment / host rather than something in the build, but it's possible Aug 05 17:54:45 I'll look into this with more detail tomorrow then, and give you a better explanation of what was causing this Aug 05 17:54:57 could certainly open a bug for tracking purposes Aug 05 17:55:29 I'll let you know tomorrow. For now, I've got an appointment in 5 minutes, so I gotta go. Aug 05 17:55:35 Thank you for all your help :) Aug 05 17:56:32 np Aug 05 18:56:23 HI I want to add gnome desktop to core-image -base Iam using toaster, which package should i append in order to get working Gnome desktop on base.. or can some one point me to some tutorial or post... thanks in advance Aug 05 18:56:34 Hmm, wonder if its' safe for a fetchmethod download() to alter the ud localpath Aug 05 18:57:53 HI I want to add gnome desktop to core-image -base Iam using toaster, which package should i append in order to get working Gnome desktop on base.. or can some one point me to some tutorial or post... thanks in advance Aug 05 18:58:07 we heard you the first time. Aug 05 18:58:09 ask your question and wait Aug 05 18:58:14 repeating yourself isn't going to help Aug 05 19:11:13 sid2: it seems to me that no one has made a packagegroup for gnome desktop. Want to give it a shot? See: meta-xfce/recipes-xfce/packagegroups/packagegroup-xfce-base.bb Aug 05 19:13:25 thanks vmeson, I will give it a try Aug 05 19:15:15 Hmm, I think this simpler approach to shallow might actually be a lot simpler and easier to pull off Aug 05 19:16:33 sid2: send a brief proposal email to the meta-oe list to ask for feedback then work one a basic env and send a patch. Aug 05 19:17:36 it's been a while since I worked on gnome but the xfce approach of -base -extended -FOO packagegroups makes sense to me. Aug 05 19:20:06 I will do that.. thanks Aug 05 19:30:04 In a recipe list of FILES, I need to have a tarball listed but not to have it unpacked by bitbake, only copied intact into my ${S} or ${WORKDIR}. e.g. FILES += "foo.tar" Aug 05 19:30:28 duh, I meand SRC_URI += "foo.tar" Aug 05 19:32:30 only way I can figure is to name it "foo.rat", then rename it in configure "mv foo.rat foo.tar" Aug 05 19:32:43 append ;unpack=no Aug 05 19:32:49 see http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-SRC_URI Aug 05 19:36:40 neverpanic: thanks, tried grepping meta/classes :( Aug 05 19:40:49 T0mW: most of unpack was moved into the bitbake fetcher to facilitate things like using git clone to unpack for git://, so there's per-fetcher-unpack methods Aug 05 19:41:31 https://github.com/openembedded/bitbake/blob/master/lib/bb/fetch2/__init__.py#L1344-L1462 is the default unpack when the fetcher doesn't provide its own Aug 05 19:41:38 https://github.com/openembedded/bitbake/blob/master/lib/bb/fetch2/__init__.py#L1349 being of interest in this case, as neverpanic points out Aug 05 19:42:51 I actually wish we'd kept support for per-fetcher unpack capability, but keep the default unpack when the fetcher doesn't provide one in the metadata, to ease modification and maintenance Aug 05 19:42:53 kergoth: saw that in classes base.bbclass, one of these daze I'll have to take time to learn python (another freakin' language :( ) Aug 05 19:43:11 heh, it's pretty readable even if you don't know it, it's writing it that takes more depth Aug 05 19:43:28 kergoth: yeah, I can puzzle and hack Aug 05 19:43:59 most of the difficulty in reading the code really isn't python related, but our own conventions. e.g. in that above line, urldata is self explanatory, but 'parm' is the url parameters Aug 05 19:44:20 hopefully to_boolean is self-explanatory as well ;) Aug 05 19:58:30 * kergoth ponders Aug 05 20:20:59 Huh, I wonder if I could implement FILESPATH handling via MIRRORS, in the metadata, rather than the fetcher needing knowledge of FILESPATH Aug 05 20:21:17 or PREMIRRORS Aug 05 20:41:33 okay, pkg_postinst sets up a link (or such) inside the image, first time the image boots these postinst sections are run, correct? Aug 05 20:41:59 I need to put the post installation code inside the INSTALL section of the RPM Aug 05 20:42:12 Is there a how-to on that? Aug 05 20:45:11 every postinst is first attempted when we're constructing the rootfs Aug 05 20:45:21 only if it fails in that context is it run on first boot Aug 05 20:45:31 and it's already arranged to be run when you install the binary package Aug 05 20:45:52 at least, i know it is for opkg, i think it is for rpm Aug 05 20:45:53 the first boot bits just call out to the package manager to configure the unconfigured postinsts Aug 05 21:01:35 kergoth: ok Aug 05 21:01:53 s/postinsts/packages/ Aug 05 21:02:31 kergoth, I'm looking at events.. is there an event (I can mask on) when a we're in the task context? Aug 05 21:02:49 if I fire on all events, I see an event called taskStarted.. but I can't seem to do an event mask against it Aug 05 21:02:58 there are 3 events, task started, task failed, task suceeded Aug 05 21:03:11 how do I do the event mask on started though? Aug 05 21:03:19 use the correct import path Aug 05 21:03:21 (I'm debugging something and trying to log when the tasks are started) Aug 05 21:03:22 it's bb.build.TaskStarted Aug 05 21:03:24 not bb.event Aug 05 21:03:26 ahh Aug 05 21:03:36 inconsistent, but.. Aug 05 21:03:39 what else is new Aug 05 21:04:05 hah, it worked. I just successfully did a do_fetch & do_unpack of a recipe with FILESPATH/FILESDIR deleted, solely relying on PREMIRRORS to handle searching FILESPATH Aug 05 21:04:08 that's pretty cool Aug 05 21:04:39 Hmm.. still not firing with bb.build.TaskStarted.. ugh Aug 05 21:06:14 Ohh maybe it worked this time.. Hmm.. Aug 05 21:06:37 it's handled around line 251 of lib/bb/event.py: if self.eventmask and eid not in self.eventmask: Aug 05 21:06:40 afaict Aug 05 21:06:53 * kergoth tries building an image with the filespath change Aug 05 21:06:54 thanks.. I'll add debug there if I can't get this working Aug 05 21:09:35 ok.. it is working.. was doing bb.note so it was getting logged to the log file not my screen! Aug 05 21:09:40 ok.. makes WAY more sense now Aug 05 21:15:44 heh, that'd explain it Aug 05 22:26:27 joshuagl: you used the wrong bitbake branch for your AB run ;) **** ENDING LOGGING AT Thu Aug 06 02:59:58 2015