**** BEGIN LOGGING AT Wed Jun 18 02:59:59 2014 Jun 18 08:44:02 morning all Jun 18 08:53:41 hi bluelightning Jun 18 09:09:27 hi kroon Jun 18 09:24:22 hi bluelightling kroon and all others Jun 18 09:25:10 hi woglinde Jun 18 09:28:59 hi woglinde Jun 18 13:59:30 question about angstrom: Why does it sometimes list processes with their fullpath when you do a ps aux and sometimes not... I just cannot figure out why it keeps on changing... we have code that greps for things in ps aux? Jun 18 13:59:46 it changes between minor releases Jun 18 14:03:07 pompomJuice: I think what is listed in ps reflects how the process has been started, i.e. /path/to/executable or by finding it through PATH Jun 18 14:03:16 pompomJuice: which processes are you referring to? Jun 18 14:03:30 it's not part of the distro Jun 18 14:03:42 its our appy that is started through systemd and the fullpath is specified Jun 18 14:03:54 1.3 it was "foo" Jun 18 14:04:18 1.3 ~ 1.5 somwhere in there it started listing it as /path/too/foo Jun 18 14:04:24 then it went away Jun 18 14:04:31 now it's back again Jun 18 14:04:38 what controls that behaviour? Jun 18 14:04:41 just path? Jun 18 14:05:12 in any case the code will now handle both situations Jun 18 14:05:33 I was just wondering where this changes comes from... what is causing it since the foo.service file has never changed Jun 18 14:06:04 systemd's version stays locked on 204 because of my kernel restrictions... so it's not systemd that is starting the thing differently Jun 18 14:06:12 anyway Jun 18 14:06:27 if there is no quick answer, i was just hoping someone has a quick answer Jun 18 14:06:32 il fix the code Jun 18 14:07:30 I don't have a huge amount of experience with systemd so I don't really know, sorry Jun 18 14:07:38 aah ok Jun 18 14:07:41 no worries Jun 18 14:08:02 if it not something obvious like, "yea that changed last week (again)" or something... Jun 18 14:08:16 but since you are using it there should be a means of locating the process associated with a service that does not involve searching the output of ps, that's a bit hacky Jun 18 14:08:44 since systemd tracks such things Jun 18 14:08:53 yea good point Jun 18 14:09:00 it should be done through /proc Jun 18 14:09:21 or var/run Jun 18 14:09:48 or where those PID files are Jun 18 14:15:48 pompomJuice: what I meant is, systemd itself should be able to tell you the pid of the process for a particular service Jun 18 14:16:11 aah ok Jun 18 14:18:26 tasslehoff: I saw an old log when you report having an error with libgles-omap3 and VFP, did you solved it? Jun 18 16:41:41 bluelightning, good to see opie getting some use after all these years :) Jun 18 16:45:05 Crofton: heh... I've even had some patches lately Jun 18 19:29:18 Building meta-toolchain with meta-mingw, SDKMACHINE=x86_64-mingw32, master branches, I'm getting a lot of these warnings: Jun 18 19:29:22 WARNING: Variable key PREFERRED_PROVIDER_virtual/${SDK_SYS}-binutils-crosssdk (binutils-crosssdk-${SDK_ARCH}) replaces original key PREFERRED_PROVIDER_virtual/x86_64-oesdk-mingw32-binutils-crosssdk (binutils-crosssdk-${SDK_ARCH}). Jun 18 19:31:55 as it says, both PREFERRED_PROVIDER_virtual/x86_64-oesdk-mingw32-binutils-crosssdk and PREFERRED_PROVIDER_virtual/${SDK_SYS}-binutils-crosssdk are defined, but they expand to the same thing, so the latter overwrites the former Jun 18 19:32:21 change the config to define just the one with ${SDK_SYS} Jun 18 19:37:42 kergoth, ah Jun 18 19:40:18 hmm well "PREFERRED_PROVIDER_virtual/${SDK_SYS}-binutils-crosssdk" is the one that is defined in meta-mingw's x86_64-mingw32.conf ... Jun 18 19:45:36 Can't find where the other one is defined Jun 18 19:47:58 hmm, maybe bitbake -e can help out Jun 18 19:52:43 openembedded-core/meta/conf/distro/include/tcmode-default.inc Jun 18 19:52:45 I think Jun 18 19:54:50 renamed in data.py:170 Jun 18 19:55:53 So.. should the maybe the one in mingw's machine-sdk.conf be removed instead ? Jun 18 20:06:29 ah, yes, sounds like the x86_64-mingw32.conf should define the other to align with the tcmode-default Jun 18 20:15:57 kergoth, sorry I'm not following.. should we duplicate the line from tcmode-default.inc in x86_64-mingw32.conf ? Both lines are "normal" assignments, " = " Jun 18 20:27:29 So I don't see why we would need the one in x86_64-mingw32.conf Jun 18 21:36:43 kroon: they're both assigning them to the same value? if so, yes, it'd hurt nothing to remove it. but you didn't mention what the actual values were in the irc channel, only the variable names which were different Jun 18 21:51:13 kergoth, the value inside the parenthesis is the assigned value Jun 18 21:51:39 x86_64-mingw32 does: Jun 18 21:51:42 PREFERRED_PROVIDER_virtual/${SDK_SYS}-binutils-crosssdk = "binutils-crosssdk-${SDK_ARCH}" Jun 18 21:51:56 tcmode-default.inc does: Jun 18 21:52:24 PREFERRED_PROVIDER_virtual/${SDK_PREFIX}binutils-crosssdk = "binutils-crosssdk-${SDK_ARCH}" Jun 18 21:53:08 ah, right. yeah, there's no point duplicating that :) Jun 18 21:53:54 i'll check the history Jun 18 21:58:37 preferred SDK provider was corrected in x86_64-mingw32.conf on 30 April, default SDK providers we're added in tcmode-default.inc on May 1, RP both commits Jun 18 21:59:46 * kergoth nods Jun 18 22:05:56 kergoth, thanks for the pointers **** ENDING LOGGING AT Thu Jun 19 02:59:59 2014