**** BEGIN LOGGING AT Mon Jul 14 02:59:59 2014
Jul 14 07:19:18 <mckoan> good morning
Jul 14 07:24:41 <koen> mckoan: good morning! Can you have a look at https://github.com/linux4sam/meta-atmel/pull/24 ?
Jul 14 07:25:47 <mckoan> hi koen 
Jul 14 07:40:48 <woglinde> hi mckoan
Jul 14 07:44:58 <pompomJuice> I ap trying to pull sneaky tactics with opkg run.postinst... basically I am trying to defer the script till after a runlevel 3 process (android) has started up...
Jul 14 07:45:32 <pompomJuice> the opkg postinst run system however seems to kill my postinst script after 7 seconds or so
Jul 14 07:45:35 <mckoan> hi woglinde 
Jul 14 07:46:07 <pompomJuice> will nohup allow me to avoid the kill?
Jul 14 07:47:44 <pompomJuice> my postinst script basically just sleeps until it detects android
Jul 14 07:47:49 <pompomJuice> using a fork
Jul 14 07:47:51 <pompomJuice> &
Jul 14 07:47:56 <pompomJuice> somehow that fork dies
Jul 14 07:48:16 <koen> can't you order the script after your android thing?
Jul 14 07:48:30 <pompomJuice> uuhm
Jul 14 07:48:30 <koen> or is it difficult to tell when the android thing is ready enough?
Jul 14 07:48:55 <pompomJuice> it's a strage use case
Jul 14 07:49:01 <pompomJuice> so not OE's fault
Jul 14 07:49:03 <pompomJuice> basically
Jul 14 07:49:16 <pompomJuice> I want to be able to do opkg install "android_app"
Jul 14 07:49:25 <pompomJuice> some android apps require android to be running
Jul 14 07:49:30 <pompomJuice> for example my keyboard app
Jul 14 07:49:46 <pompomJuice> it needs to install and then run some adb commands to enable the keyboard and then select it
Jul 14 07:50:00 <pompomJuice> this can obviously noy happen during image baking
Jul 14 07:50:53 <pompomJuice> so in my opkg postinst script I do what I can then return "exit 1" -> to cause a opkg deferred postinst on that package
Jul 14 07:51:02 <pompomJuice> then when the image boots for the first time
Jul 14 07:51:10 <pompomJuice> those postinsts run very early
Jul 14 07:51:16 <pompomJuice> stupedly  early
Jul 14 07:51:24 <pompomJuice> anyway
Jul 14 07:51:29 <pompomJuice> the android starts later
Jul 14 07:51:41 <pompomJuice> so my script forks then sleeps and waits to detect android
Jul 14 07:52:13 <pompomJuice> but it seems after 8 seconds or so opkg postinst script framework decides that the postinst script has run long enough and kills it
Jul 14 07:52:24 <pompomJuice> that last line is a guess
Jul 14 07:52:55 <pompomJuice> since the script just stops running ( I know this since the script logs like this echo "some log" >> /var/log/run.postinst.log
Jul 14 07:55:01 <pompomJuice> if i can make it work I have a system where I have android running ontop of OE (angstrom/rowboat kernel) that you can do "pkg install android_app" which is awesome
Jul 14 07:57:03 <pompomJuice> my current plan is to execute the android detector thread like this --> nohup detect_android_and install &
Jul 14 08:04:37 <pompomJuice> ok so "nohup android_detector_and_installer_forker_sleeper_bash_script &" does not work
Jul 14 08:04:44 <pompomJuice> I need pro
Jul 14 08:08:39 <koen> pompomJuice: what about the reverse?
Jul 14 08:08:48 <pompomJuice> explain
Jul 14 08:09:05 <koen> pompomJuice: have the android daemon (re)run the affected postinsts
Jul 14 08:09:06 <pompomJuice> I found my problem
Jul 14 08:09:13 <pompomJuice> aah
Jul 14 08:09:15 <koen> (does android have a daemon?)
Jul 14 08:09:16 <pompomJuice> that could work
Jul 14 08:09:37 <pompomJuice> yes it is started with systemd 
Jul 14 08:09:56 <pompomJuice> I know that the postinst stuff was changed from 1.5 -> 1.6
Jul 14 08:10:01 <pompomJuice> moved out of systemd
Jul 14 08:10:12 <pompomJuice> but that is all I know about how that thing works
Jul 14 08:10:50 <pompomJuice> I could make postinst.service depend on android.service but that just feels wrong... postinst probably has good reason to execute so early
Jul 14 08:10:58 <pompomJuice> basically all I need is the following
Jul 14 08:11:20 <pompomJuice> how can I write a bash script that forks a part of itself that is immune to SIGHUP
Jul 14 08:11:34 <pompomJuice> my last try was terrible
Jul 14 08:11:44 <pompomJuice> nohup somebashfunc &
Jul 14 08:11:47 <pompomJuice> not allowed
Jul 14 08:11:53 <pompomJuice> nohup somescript.sh &
Jul 14 08:11:55 <pompomJuice> now that is allowed
Jul 14 08:14:04 <bluelightning> morning all
Jul 14 08:14:19 <koen> hey bluelightning 
Jul 14 08:14:23 <bluelightning> hi koen
Jul 14 08:14:28 <pompomJuice> howdy
Jul 14 08:14:37 <kroon> kergoth, do we need a ROOTFS_POSTPROCESS_COMMAND[python] = "0" aswell ? Without it I got some warnings about some variable containing tabs. Tracing the warning in bitbake it seemed to come from [func] being set, aswell as [python] ...
Jul 14 08:15:16 <kroon> morning all
Jul 14 08:15:34 <bluelightning> hi kroon
Jul 14 08:15:36 <kroon> I guess no germans are up yet
Jul 14 08:15:44 <bluelightning> kroon: kergoth is US-based
Jul 14 08:15:55 <bluelightning> kroon: but that definitely should not be needed
Jul 14 08:18:50 <ant_work> hi bluelightning, wb
Jul 14 08:18:57 <bluelightning> hi ant_work
Jul 14 08:24:04 <kroon> bluelightning, we were talking yesterday about why changes in ROOTFS_POSTPROCESS_COMMAND does not trigger rebuilds anymore, now that rootfs creation code lives in lib/oe/rootfs.py
Jul 14 08:24:49 <bluelightning> kroon: we may need to add an explicit dependency to ensure that happens
Jul 14 08:25:26 <kroon> bluelightning, theres a patch on ml adding it to do_rootfs[vardeps]. But that might not be enough
Jul 14 08:25:31 <bluelightning> although if the python code calls d.getVar() to retrieve the value of the variable it ought to be picked up as a dependency
Jul 14 08:26:25 <kroon> hmm, it does
Jul 14 08:27:03 <kroon> well, chris hinted that we might wanna do ROOTFS_POSTPROCESS_COMMAND[func] = "1" , to invoke bitbakes shell parser
Jul 14 08:28:12 <bluelightning> interesting, I wouldn't have thought of that; it might pick up dependencies on other shell functions
Jul 14 08:29:21 <ant_work> bluelightning: btw that rootfs.py seems the one unconditionally polluting images
Jul 14 08:29:47 <bluelightning> ant_work: how did you determine that? any further details?
Jul 14 08:30:14 <ant_work> well, I was nailing this down then some major issues overcome ;)
Jul 14 08:30:52 <ant_work> anyway I was grepping to see where LDCONFIGDEPEND is considered and came there
Jul 14 08:39:28 <bluelightning> ant_work: AFAIK that was a direct translation of the old shell code though
Jul 14 08:40:26 <ant_work> see right after def _run_ldconfig(self),  def _generate_kernel_module_deps(self):
Jul 14 08:41:45 <ant_work> there is also some interaction with the kernel-base and kernel-image
Jul 14 08:51:31 <ant_work> bluelightning: 
Jul 14 08:51:32 <ant_work> FILES_kernel-base = "/lib/modules/${KERNEL_VERSION}/modules.order /lib/modules/${KERNEL_VERSION}/modules.builtin"
Jul 14 08:51:50 <mago_> woglinde, i tried to get meta-java running the other week. it seems like the Rhino SRC_URI is out of date, do you want a patch?
Jul 14 09:00:45 <woglinde> mago hm
Jul 14 09:00:49 <woglinde> yes
Jul 14 09:01:07 <woglinde> but I do not know when I find the time to merge it
Jul 14 09:01:39 <woglinde> we need a modus in bitbake which can show outdate sources
Jul 14 09:02:03 <mago_> yeh, i wasn't able to build it successfully either. it failed on the openjdk 7 do_install task for some reason. Is the master suitable going for daisy?
Jul 14 09:02:47 <woglinde> mago I made no tests yet
Jul 14 09:02:49 <mago_> i think it was unable to stat some j2sdk_image file (or something). i've dropped the java stuff for now 
Jul 14 09:02:56 <woglinde> because I do not have the time
Jul 14 09:03:07 <mago_> yeah, its no problem. i just thought i'd tell you :)
Jul 14 09:03:10 <woglinde> hm that should be fixed
Jul 14 09:04:12 <woglinde> mago yes thanks
Jul 14 09:09:07 <mago_> i don't have any public git repos so its difficult for me to submit pull requests, but i can send you a patch-file somewhere if you want
Jul 14 09:37:32 <woglinde> mago why not fork the github repo
Jul 14 09:57:21 <mago_> yeah, ok, i can do that
Jul 14 13:24:24 <pompomJuice> I need the uber pro
Jul 14 13:25:01 <pompomJuice> I have tried to pull the following trick in a opkg postinst ---> nohup "$0" "calling_myself" "$@" &
Jul 14 13:25:34 <pompomJuice> The idea was that the postinst script spawns another process that sleeps until it detects that a runlvl 3 program has started... 
Jul 14 13:25:53 <ant_work> pompomJuice: I could give you C function example about how to fork, exec and wait, never done in shell, sorry
Jul 14 13:26:03 <pompomJuice> it's working
Jul 14 13:26:10 <pompomJuice> but
Jul 14 13:26:58 <pompomJuice> that scrollbar that opkg makes when firstbooting... waits until my sleeping process (that was forked like described above) dies before continuing... 
Jul 14 13:27:04 <pompomJuice> how does it know?
Jul 14 13:27:26 <pompomJuice> why cant I spawn something out of the run.postinst that is completely disconnected from it.
Jul 14 13:27:44 <ant_work> you mean psplash?
Jul 14 13:27:57 <pompomJuice> not sure what that is
Jul 14 13:28:04 <pompomJuice> [ ***]
Jul 14 13:28:19 <pompomJuice> those awesome progress bars when you are on the serial cable
Jul 14 13:28:26 <pompomJuice> with the green [ OK ]
Jul 14 13:28:28 <pompomJuice> etv
Jul 14 13:28:29 <pompomJuice> etc
Jul 14 13:28:49 <pompomJuice> so frustrating
Jul 14 13:28:54 <pompomJuice> I have a chicken egg problem
Jul 14 13:29:43 <pompomJuice> I just cannot make opkg spawn a script that the opkg run postinst framework does not know about
Jul 14 13:30:02 <pompomJuice> it sees that I am spawning new stuff and hence waiting for them to complete
Jul 14 13:30:11 <pompomJuice> I want to hide, but I cant
Jul 14 13:34:54 <pompomJuice> maybe screen will do the trick
Jul 14 13:35:01 <pompomJuice> somehow
Jul 14 13:39:18 <pompomJuice> or setsid
Jul 14 13:39:22 <pompomJuice> that looks like what I want
Jul 14 14:00:22 <pompomJuice> so annoying
Jul 14 14:42:21 <pompomJuice> Does angstrom contain a daemon program?
Jul 14 14:42:49 <woglinde> hm what you mean
Jul 14 14:42:54 <woglinde> like start-stop-daemon?
Jul 14 14:44:41 <pompomJuice> like sysvinit on ubuntu uses daemon
Jul 14 14:44:58 <pompomJuice> basically I am trying to spawn a process that is not killed or controlled though it's parent
Jul 14 14:45:13 <pompomJuice> I am starting to wonder if it is impossible because of security reasons
Jul 14 14:53:54 <pompomJuice> woglinde, yes like start-stop-daemon
Jul 14 14:54:33 <pompomJuice> Thanks, I see that already works on my device
Jul 14 14:55:45 <ensc|w> pompomJuice: systemd contains a native respawn mechanism
Jul 14 14:55:56 <pompomJuice> I dont want to use systemd
Jul 14 14:56:23 <pompomJuice> I want to spawn a process when opkg does its deferred run.postinstall scripts on first boot
Jul 14 14:56:26 <pompomJuice> a daemon process
Jul 14 14:58:35 <woglinde> me still wonders why you need a setup steop later
Jul 14 15:01:52 <heeen> hi
Jul 14 15:02:16 <heeen> so on ubuntu 14.04 64bit my build just complained about missing stubs-32.h
Jul 14 15:02:25 <heeen> compiling for an arm device
Jul 14 15:02:37 <heeen> can someone explain why
Jul 14 15:02:47 <heeen> it complained during building pseudo
Jul 14 15:03:01 <heeen> there was a warning "guessing -m32"
Jul 14 15:03:48 <heeen> does it need those because arm is 32bit or because it did not detect my host correctly
Jul 14 15:04:14 <heeen> I installed libc6-dev-i386 and g++-multilib and that fixed it
Jul 14 15:21:32 <bluelightning> heeen: I think that is because it saw you have some 32-bit libs installed
Jul 14 15:35:49 <kroon> Reading the bitbake manual.. not sure I get what the difference is between "require/include" and "inherit"
Jul 14 15:37:39 <kergoth>  inherit is for classes, from recipes. under the hood, the only difference really is that 'inherit' avoids re-parsing already-parsed classes, and inherit foo parses classes/foo.bbclass
Jul 14 15:38:20 <kroon> aha
Jul 14 15:39:19 <kroon> so "include <path-to-classes-dir>/foo.bbclass, would basically do the same as "inherit foo" ?
Jul 14 15:39:56 <kergoth> classes get a couple other special pieces of handling, I can't recall offhand if those are tied to 'inherit' or to parsing a .bbclass, probably the latter. e.g. the functionality of EXPORT_FUNCTIONS only works from a class, as bitbake tracks the name of the current class to be able to add the function redirections
Jul 14 15:41:24 <kroon> I see
Jul 14 15:43:35 <kergoth> EXPORT_FUNCTIONS foo creates a do_foo function which calls <classname>_do_foo. extremely simple, but it lets you name the class implementation prefixed by the class name, so someone overriding the function can still call the original implementation, the way you can call a base class method in an object oriented language (in case you didn't know what it does)
Jul 14 15:43:57 <kergoth> s/foo/do_foo/
Jul 14 16:23:23 <RP> kergoth: I'm toying with the idea of letting the code parser recurse into lib/oe since it would save a certain amount of pain with dependency tracking. Any thoughts?
Jul 14 16:23:58 <kergoth> I started on generic handling of that in the signature generation code at one point. It gets messy, but it's definitely something we need
Jul 14 16:24:06 <kergoth> I think we should move in that direction, yeah
Jul 14 16:24:33 <RP> kergoth: next question is whether you've any idea how to make it work cleanly :)
Jul 14 16:24:48 <RP> kergoth: I don't like the sound of the pain you mention :/
Jul 14 16:24:58 <RP> s/pain/messy/
Jul 14 16:25:15 * RP isn't awake enough to think about python function dependencies
Jul 14 16:25:16 <kergoth> I honestly can't remember what all was involved at this point, it's been too long since messing with it :)
Jul 14 16:25:20 * kergoth nods
Jul 14 16:26:44 <RP> kergoth: my concern is how well the code parser figures out things like the classes and class inheritance we now use in there
Jul 14 16:26:54 <kergoth> I think part of it was trying to cleanly handle all the corner cases: imports, handling import, from foo import bar, in all contexts (including inside functions), tracking changes to PYTHONPATH/sys.path, plus relative imports (to handle those you also need to track the 'current package' we're in), etc. if we're willing to focus specifically on our use case, then it might not be so bad
Jul 14 16:27:06 <kergoth> that's a good point
Jul 14 16:28:10 <RP> way forward is probably to "hardcode" some fixes for rootfs variables for now and put this as a longer term objective I guess
Jul 14 16:29:46 <nerdboy> a raspberrypi B+ ?  hadn't seen that one before...
**** ENDING LOGGING AT Tue Jul 15 02:59:59 2014