**** BEGIN LOGGING AT Tue Nov 21 03:00:00 2017
Nov 21 09:05:27 <Noor> Hello guys
Nov 21 09:05:51 <Noor> I was working with readonly fs
Nov 21 09:05:55 <Noor> and faced this error
Nov 21 09:06:11 <Noor> "The following packages could not be configured offline and rootfs is read-only"
Nov 21 09:07:01 <Noor> I reached till https://github.com/MentorEmbedded/poky/blob/master/meta/lib/oe/rootfs.py#L212
Nov 21 09:07:25 <Noor> I saw this functions is being used get_delayed_postinsts a line above
Nov 21 09:07:42 <Noor> I was looking where delayed_postinsts are set
Nov 21 09:07:47 <Noor> can anybody help me
Nov 21 09:08:32 <Noor> Need to see in which condition the postinsts are delayed
Nov 21 09:36:46 <bluelightning> Noor: the packages in question will have a pkg_postinst set that can't be performed on the host (usually because they explicitly "exit 1", but could also be that they just fail)
Nov 21 09:38:15 <Noor> bluelightning: yes that is the case
Nov 21 09:38:46 <Noor> but is there any piece of code which is saving that postinsts
Nov 21 09:38:56 <Noor> just like we have get function 
Nov 21 09:39:03 <Noor> do we have any set function
Nov 21 09:39:42 <bluelightning> do you mean, how can you view the postinstall scripts?
Nov 21 09:40:01 <Noor> no 
Nov 21 09:40:23 <bluelightning> sorry, I'm not quite following
Nov 21 09:40:26 <Noor> bluelightning: just like  get_delayed_postinsts it is providing us delayed postinsts
Nov 21 09:40:44 <Noor> is therey any functions which is setting delayed postinsts
Nov 21 09:40:54 <Noor> any setter function
Nov 21 09:41:21 <Noor> I can see the psotinsts in recipe 
Nov 21 09:41:22 <Noor> pkg_postinst_${PN} () {
Nov 21 09:41:22 <Noor>     if [ x"$D" = "x" ] ; then
Nov 21 09:41:22 <Noor>         update-ca-certificates
Nov 21 09:41:22 <Noor>     else
Nov 21 09:41:22 <Noor>         exit 1
Nov 21 09:41:24 <Noor>     fi
Nov 21 09:41:26 <Noor> }
Nov 21 09:41:35 <bluelightning> not from that end... you could clear out the postinsts from the recipe end, but bear in mind that will mean that processing will be missing in the final image of course
Nov 21 09:42:22 <Noor> there must be some logic in the poky which will be deciding that this above postinsts should be delayed
Nov 21 09:42:28 <Noor> I was asking about that code
Nov 21 09:42:38 <bluelightning> the logic is, if they fail they get delayed, it's as simple as that
Nov 21 09:42:59 <bluelightning> and by doing "exit 1" it's failing
Nov 21 09:43:39 <bluelightning> (D is set when running the postinst scripts on the host during image construction)
Nov 21 09:44:32 <bluelightning> the usual method of dealing with this kind of issue is to find a way to fix the postinst script so it can run on the host
Nov 21 09:44:56 <bluelightning> not sure how easy that will be for update-ca-certificates
Nov 21 09:46:15 <bluelightning> Noor: is this the ca-certificates recipe itself?
Nov 21 09:49:08 <bluelightning> in master I note that ca-certificates postinst should work on the host at least, and that change goes back to 2013 - so it's possible
Nov 21 09:51:36 <Noor> bluelightning: no its not
Nov 21 09:51:46 <Noor> its some other private recipe
Nov 21 09:52:08 <Noor> I know how it runs
Nov 21 09:56:46 <Noor> in classes or somewhere it was being checked that postinsts is exiting with 1 and based on that it is being delayed
Nov 21 09:57:12 <Noor> I was looking for where that thinig is located in cloases or in lib/oe
Nov 21 09:57:27 <Noor> if I am asking totally wrong thing then sorry about it
Nov 21 15:21:42 <kergoth> Noor: how postinsts are run and delayed depends on the package manager, see lib/oe/package_manager.py & the rest
Nov 21 15:21:43 <kergoth> also rootfs.py
Nov 21 15:47:51 <georgem> Good work everyone who contributed to this latest round of security fixes for morty.
Nov 21 16:10:45 <mrc3> more questions on rdepends and rocko
Nov 21 16:11:22 <mrc3> after getting "ERROR: kmscube-git-r0 do_package_qa: QA Issue: /usr/bin/kmscube contained in package kmscube requires libgbm.so()(64bit), but no providers found in RDEPENDS_kmscube? [file-rdeps]", the qa error goes away if i add RDEPENDS_${PN} = "libgbm.so()(64bit)", but that looks terribly wrong
Nov 21 16:29:34 <mrc3> (and if libgbm.so()(64bit) is RPROVIDED by the graphics driver)
Nov 21 16:46:38 <armpit> georgem, thanks for your patches. the glibc are staged once I get pyro figured out. 
Nov 21 16:51:35 <georgem> armpit: hold off on that actually... I just discovered an issue on an x86 build.
Nov 21 16:51:47 <georgem> looking into it right now
Nov 21 16:53:41 <armpit> k
Nov 21 16:54:06 * armpit heads off to commute to sj
Nov 21 20:52:28 <georgem> strange. patchtest didn't like my latest patches.
Nov 21 21:05:46 <bluelightning> georgem: it isn't picking up that it should be applied on top of pyro... I believe that's a bug that's bein worked on
Nov 21 21:05:54 <bluelightning> just ignore for now
Nov 21 21:19:02 <georgem> ok
Nov 21 21:19:10 <georgem> the morty patches also
Nov 21 21:20:31 <armpit> ignore bugs???
Nov 21 21:53:29 <noc0lour> I have something rather strange here: I'm trying to build u-boot with a def config which defines: SYS_VENDOR, SYS_BOARD etc. and in my resulting configuration only SYS_VENDOR is set to my desired value. SYS_BOARD is set to the mach default value (u-boot-2017.09). I could of course patch the default value for my build....
Nov 21 21:55:34 <noc0lour> do_configure does not have any useful output to look at, where is the place to look at?
Nov 21 21:57:44 <Crofton|work> what happens when yuou build outside oe?
Nov 21 22:06:29 <noc0lour> hm, doesn't work, well... so I rather have to look at u-boot
Nov 21 22:07:52 <Crofton|work> generally, if you can't get it to build outside oe, adding oe will only cause pain
Nov 21 22:10:05 <noc0lour> building is not the problem, it's not taking SYS_BOARD from defconfig 
Nov 21 22:10:27 <noc0lour> and crosscompiling outside of oe sucks as well ;) 
Nov 21 22:15:30 <Crofton|work> u-boot is pretty straiht forward
Nov 21 22:15:35 <Crofton|work> just make an sdk and use it
**** ENDING LOGGING AT Wed Nov 22 03:00:00 2017