**** BEGIN LOGGING AT Wed Jan 21 02:59:58 2015
Jan 21 04:42:26 <Aethenelle> I was looking at fixing OSX support and found pyinotify is only supported on linux and some BSDs. I found another library, watchdog, to replace pyinotify but it has an apache licence. Is this a problem for inclusion into bitbake?
Jan 21 08:30:51 <bluelightning> morning all
Jan 21 08:31:17 <nrossi> bluelightning: morning
Jan 21 08:31:56 <bluelightning> hi nrossi
Jan 21 09:09:25 <koen> Crofton|work: http://patches.openembedded.org/patch/87143/
Jan 21 09:25:05 <LetoThe2nd> wasn't there some tag or switch so that the git fetcher would never cache?
Jan 21 09:27:37 <bluelightning> LetoThe2nd: do you mean SRCREV = "${AUTOREV}" ?
Jan 21 09:32:46 <LetoThe2nd> bluelightning: possibly :)
Jan 21 09:38:46 <koen> hurray for non-deterministic builds!
Jan 21 09:40:19 <LetoThe2nd> koen: hooray for source development :)
Jan 21 09:41:25 <bluelightning> there is a place for bleeding edge builds
Jan 21 09:41:42 <bluelightning> outside of generally usable public layers, naturally
Jan 21 09:41:49 <LetoThe2nd> bluelightning: exactly.
Jan 21 09:42:17 <koen> autorev usually works for 3 weeks
Jan 21 09:42:22 <koen> then people forget about it
Jan 21 09:43:53 <koen> LetoThe2nd: https://git.linaro.org/openembedded/jenkins-setup.git/blob/HEAD:/srcrev-check.py
Jan 21 09:44:06 <koen> not perfect, but a much better idea than AUTOREV
Jan 21 09:44:57 <LetoThe2nd> koen: noted, thanks :)
Jan 21 09:45:25 <koen> we use that in the 'bleeding edge' CI loop
Jan 21 12:52:16 <pompomJuice> Ever since yocto 1.6 somewhere the build process adds a random number to the back of the PV when producing IPKs
Jan 21 12:52:24 <pompomJuice> is there a way to turn that off?
Jan 21 12:53:01 <pompomJuice> because when I do a opkg upgrade everything upgrades because there is effectively a random version number attacked to every build
Jan 21 12:53:10 <pompomJuice> attached*
Jan 21 12:54:05 <pompomJuice> not sure which part of the doc addresses this
Jan 21 12:54:37 <pompomJuice> If I had the mechanism's name that would help
Jan 21 12:56:21 <koen> PRSERV
Jan 21 12:59:17 <pompomJuice> thanks
Jan 21 13:54:01 <bluelightning> florian: ping
Jan 21 14:16:28 <Crofton|work> arg, when do I inherit pkgconfig
Jan 21 14:16:38 <Crofton|work> when I create pc files or use them?
Jan 21 14:17:36 <bluelightning> when you call pkg-config (i.e. the latter)
Jan 21 14:17:52 <bluelightning> or rather, when you're building something that will call pkg-config
Jan 21 14:20:13 <Crofton|work> thanks
Jan 21 14:20:17 <Crofton|work> I always forget
Jan 21 14:20:58 <kergoth> hmm, i think it might have handled the former too yeras ago, doing .pc mangling or somesuch
Jan 21 14:20:59 * kergoth yawns
Jan 21 14:21:01 <ensc|w> pkgconfig.bbclass adds just a DEPENDS nowadays...
Jan 21 14:21:17 <Crofton|work> I know
Jan 21 14:21:26 <Crofton|work> How do we do the mangling now?
Jan 21 14:21:48 <ensc|w> manually... I submitted a patch a month ago which was rejected by rp
Jan 21 14:21:57 <kergoth> I don't think anything is necessary for target, and sysroot text file path mangling is automatic
Jan 21 14:22:06 <Crofton|work> python-zmq is getting a host includes contamination, apparently coming from pkconfig
Jan 21 14:22:13 * kergoth shrugs
Jan 21 14:22:42 <ensc|w> kergoth: there are some .pc files which add absolute sysroot path (e.g. libkmod.pc or fontconfig)
Jan 21 14:23:11 <kergoth> absolute sysroot paths are automatically modified when things are put into the sysroot
Jan 21 14:23:16 <kergoth> last i checked, anyway
Jan 21 14:23:22 <kergoth> there's a grep -r
Jan 21 14:23:28 <kergoth> its pretty unpleasant, but gets the job done
Jan 21 14:24:03 <Crofton|work> I see things like includedir=/usr/include in pc files
Jan 21 14:24:27 <ensc|w> kergoth: no; when path is in -I or -L it gets duplicated (e.g. 'Cflags: -I/foo/bar' becomes '-I/foo/bar/foo/bar' when /foo/bar is PKG_CONFIG_PATH)
Jan 21 14:25:00 <Crofton|work> ah we set PKG_CONFIG_PATH?
Jan 21 14:25:19 <RP> Crofton|work: those get the sysroot prepended automatically
Jan 21 14:25:21 <ensc|w> PKG_CONFIG_SYSROOT_DIR; sorry
Jan 21 14:25:27 <ensc|w> http://patchwork.openembedded.org/patch/85121/
Jan 21 14:25:38 <Crofton|work> yeah, I ahve a pythong script that called pkgconfig
Jan 21 14:25:50 <RP> The point is that absolute paths leaking into .pc files is wrong in the first place
Jan 21 14:25:57 <Crofton|work> sure
Jan 21 14:26:01 <RP> We shouldn't be hacking around it, we should fix the files
Jan 21 14:26:05 <Crofton|work> just trying to understand wtf is going on
Jan 21 14:26:21 <Crofton|work>           p = Popen('pkg-config --variable=prefix --print-errors libzmq'.split(), stdout=PIPE, stderr=PIPE)
Jan 21 14:26:35 <Crofton|work> I bet this isn't seeing the env var
Jan 21 14:27:30 <ensc|w> RP: to detect such broken .pc files, I wrote http://patchwork.openembedded.org/patch/85121/
Jan 21 14:29:08 <RP> ensc|w: right, I do want to merge that
Jan 21 14:40:00 <florian> bluelightning: pong... got your mail. i'm working on a plan... this evening, as soon as all customers are away from their phones :)
Jan 21 14:45:13 <Crofton|work> florian, thanks
Jan 21 14:45:28 * Crofton|work curses python zeromq bindings
Jan 21 14:46:15 <bluelightning> florian: ok thanks
Jan 21 14:50:30 <Crofton|work> arg, it does everything in the compile step, so I can't sed out the /usr/include line!
Jan 21 15:46:46 <Crofton|work> So I have a pythong recipe (setuptools) that runs pkg-config inside the setup.py
Jan 21 15:47:10 <Crofton|work> and it gets the path as /usr/include, which is bad. Any suggestions for fixing this?
Jan 21 15:47:48 <koen> trying setting PKGCONFIG_PATH and DIR as shell variables
Jan 21 15:49:31 <Crofton|work> do you have an exmaple?
Jan 21 16:12:02 <koen> Crofton|work: not at the moment, sorry
Jan 21 17:14:43 <Crofton|work> RP, should that bitbake patch work on master?
Jan 21 17:14:58 <RP> Crofton|work: it depends on the patch I sent before it
Jan 21 17:15:10 <Crofton|work> ok
Jan 21 17:15:12 <Crofton|work> good :)
Jan 21 17:20:04 <Aethenelle> I was looking at getting bitbake to work on OSX last night. It looks like switching from pyinotify to watchdog would do the trick but watchdog carries the apache license. Is that a problem?
Jan 21 17:21:24 <Aethenelle> I'm pretty sure the swap should be simple other than that.
Jan 21 21:59:44 <Crofton|work> wtf can't pkg-config read the env var and return prfix with the systroot in frint
Jan 21 21:59:53 * Crofton|work looks at the clock
Jan 21 23:19:53 <Crofton|work> http://www.jwz.org/doc/cadt.html
**** BEGIN LOGGING AT Thu Jan 22 01:55:46 2015
**** ENDING LOGGING AT Thu Jan 22 02:59:59 2015