**** BEGIN LOGGING AT Wed Feb 25 02:59:58 2015 Feb 25 02:59:59 mmm... cake... Feb 25 08:10:32 good morning Feb 25 08:15:22 hi mckoan Feb 25 08:42:37 RP: hi Feb 25 08:43:09 I was building an old-style linux_4.0-rc1 and I think there is still an issue in kernel.bbclass Feb 25 08:43:40 I had to redeclare S after inheriting kernel Feb 25 08:44:01 otherwise patches are not found Feb 25 08:44:10 (patches listed in SRC_URI) Feb 25 08:44:43 it looks like patches in subdirs are also not found. I'll dig more Feb 25 08:48:30 (the 4.0-rc1 recipe was cloned from http://tinyurl.com/kyd72et) Feb 25 09:46:33 morning all Feb 25 09:58:43 hi bl Feb 25 10:04:56 * nerdboy looks at the darkness Feb 25 10:06:50 apocalypse morning? Feb 25 10:07:15 hey Feb 25 10:14:11 hi woglinde, mago_, nerdboy Feb 25 10:17:31 * nerdboy goes to bed and hopes the sun will come back... Feb 25 13:54:47 hi Feb 25 13:55:02 hi Jin^eLD Feb 25 13:55:11 I'm wondering, the message "The recipe quilt-native is trying to install files into a shared area when those files already exist. Those files and their manifest location are:" used to be a warning, now it's an error? Feb 25 13:55:23 hi bluelightning :) contining with my upgrade to 1.7.x ;) Feb 25 13:55:28 *continueing Feb 25 13:55:39 or whatever, I never get the spelling right Feb 25 13:55:40 :) Feb 25 13:55:58 Jin^eLD: yes, it's an error now after several people hit problems due to ignoring those warnings Feb 25 13:56:17 if you're rebuilding from quilt-native, there's not much to keep in your TMPDIR, you might as well blow it away Feb 25 13:57:21 well, I'll lose the gitrXXX if I wipe it? Feb 25 13:57:32 and you guessed right, its about quilt native right now ;) Feb 25 13:58:14 we have a feed that builds all our stuff from git and it needs to be updateable, so I'd rather keep the states of AUTOINCs Feb 25 14:00:54 Jin^eLD: you shouldn't, I don't think the database for the PR server is normally under TMPDIR, but you can always double-check Feb 25 14:02:18 bluelightning: is the db in cache or sstate-cache directry? how is it called again? Feb 25 14:02:30 there are some db's in cache Feb 25 14:04:01 let's see what happens Feb 25 14:06:57 a lot happened since 1.5, we need to sync/update our stuff more often I guess :) Feb 25 14:13:24 wiping tmpdir helped, thank you Feb 25 14:27:34 the oe-core/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1bb states that modules packages will be prefixed with "kernel-module-". And the stem of the module name comes from parsing depmod output (not the PN)? so i should expect that there is a kernel-module-hello and not a kernel-module-hello-mod that I can add to MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS? Feb 25 14:48:36 mago_: yes, I believe that's how it works Feb 25 14:56:26 bluelightning: cause i'm getting unsatisfied recommendation in my rootfs logs and the module doesn't get included. The only way to get it in is to put the actual PN into RRECOMMENDS, e.g MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "hello-mod" Feb 25 14:59:00 bluelightning: how can i tell what kernel module splits are actually created? Feb 25 14:59:37 mago_: I would suggest looking in packages-split within the workdir for the recipe Feb 25 15:06:49 bluelightning: hm, so if I manually build the recipe, it outputs the correct package split and the rootfs no longer complains. so perhaps my mistake here is that i think MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS also adds a build dependency on the module? or do i need to make sure hello-mod is built elsewhere (e.g in CORE_IMAGE_EXTRA_INSTALL) ? Feb 25 15:08:31 mago_: I suspect the issue is that the system does not know that your recipe should provide that item - because the kernel says it provides kernel-module-* Feb 25 15:08:51 but now that i think about it, how would bitbake know i'd like to build hello-mod just by specifying a RRECOMMENDS on kernel-module-hello Feb 25 15:09:39 bluelightning: so, what is the proper way of doing these out-of-tree kernel module builds with OE? Feb 25 15:10:20 mago_: it has an internal map of runtime targets to build targets, and normally that works fine, except here it's being short-circuited Feb 25 15:10:32 mago_: honestly this is not my area of expertise Feb 25 15:10:41 (out-of-tree kernel modules, that is) Feb 25 15:13:56 mago_: at the moment you probably need an extra DEPENDS somewhere to ensure your recipe gets built, I can't think of another solution at this time Feb 25 15:15:00 ok, great Feb 25 15:15:11 i'll just put it in CORE_IMAGE_EXTRA_INSTALL then **** BEGIN LOGGING AT Wed Feb 25 15:40:32 2015 **** BEGIN LOGGING AT Wed Feb 25 15:46:15 2015 Feb 25 16:03:35 so I see opkg is maintained now? patches go via ML or is there some github pull request like environment that I could use? Feb 25 16:07:34 Jin^eLD: it is maintained, yes - though I'm not sure of the correct method of sending patches; I'm guessing you would send them to the opkg-devel mailing list Feb 25 16:07:53 ok, I'll try Feb 25 16:08:02 we tried submitting them patches about 2-3 years ago Feb 25 16:08:04 and that led nowhere :) Feb 25 16:08:34 as in neither accepted nor rejected :) Feb 25 16:09:04 another question, what's the sugggested way to work around missing gnu/stubs-soft.h ? Feb 25 16:09:15 I guess that comes from eglibc->glibc switch or something like that? Feb 25 16:10:18 Jin^eLD: for any missed opkg patches you should be able to ping the current maintainer (Paul Barker) or perhaps more appropriately rebase and resend Feb 25 16:10:37 Jin^eLD: not sure about gnu/stubs-soft.h Feb 25 16:10:57 ok thx, I guess we'll try to resent then (opkg) Feb 25 16:11:15 is 1.7 using gcc or clang? Feb 25 16:11:47 I read the header problem was a bug in clang at some point Feb 25 16:11:49 gcc Feb 25 16:12:01 I do not think we support or testing clang this much Feb 25 16:12:16 yeah just grepped... Feb 25 16:12:23 hmm Feb 25 16:13:41 I think I know regarding the stubs, the program is supposed to import gnu/stubs.h which then decides if hard or soft stubs need to be imported Feb 25 16:16:13 uh.. although I have a feeling that this include happens via the toolchain Feb 25 16:16:24 does anyone work on a hardfloat system? Feb 25 16:16:59 it looks like it should Feb 25 16:17:51 FWIW, a random build I happen to have for beaglebone only has gnu/stubs-hard.h (and gnu/stubs.h) Feb 25 16:18:08 khem: any insights ^ ? Feb 25 16:18:13 my program does #include Feb 25 16:18:17 and that leads to the failure Feb 25 16:19:44 https://pastebin.mozilla.org/8823293 Feb 25 16:19:51 problem seems to be in the toolchain somewhere Feb 25 16:22:02 my 1.5 build did not have the soft stubs eitehr Feb 25 16:22:03 looking at gnu/stubs.h, I can only assume that __ARM_PCS_VFP is somehow not defined when it should be Feb 25 16:22:12 right, that's what I'm thinking Feb 25 16:22:20 I am just not sure where the define is supposed to be coming from? Feb 25 16:22:26 it worked in 1.5.3 Feb 25 16:22:28 (poky) Feb 25 16:22:54 that looks like some internal gcc define anyway, no? Feb 25 16:23:06 Jin^eLD: you are using hf toolchain to do softfloat ? Feb 25 16:23:13 thats not going to work Feb 25 16:23:22 we do not do multilib in this vector Feb 25 16:23:49 khem: to be honest I am not quite aware of what exactly I am using :) I just setup the machine and off we go Feb 25 16:24:00 the machine has hf Feb 25 16:24:15 arm machine or host machine ? Feb 25 16:24:18 arm Feb 25 16:24:35 are you using on device SDK Feb 25 16:25:06 huh? I'm cross compiling on a x86 host "normally" via bitbake Feb 25 16:25:23 so OE builds the toolchain etc etc and everything else Feb 25 16:25:37 I'm migrating from poky 1.5.3 to 1.7.1 Feb 25 16:25:52 using same machine configs etc, only poky checkout changed Feb 25 16:26:02 1.5.3 compiled just fine Feb 25 16:26:21 but I wiped out tmpdir to make a clean build Feb 25 16:27:43 which component is failin ? Feb 25 16:28:14 some software of ours that includes pthread.h Feb 25 16:28:35 https://pastebin.mozilla.org/8823293 Feb 25 16:28:53 failure seems to be coming from the pthread.h include if I am not mistaken... Feb 25 16:29:49 who is supposed to #define __ARM_PCS_VFP ? Feb 25 16:30:10 and why was it not complaining with poky 1.5.3? Feb 25 16:30:47 I could probably hack it into our CFLAGS, but I'm a bit afraid if this problem may be of a more general nature Feb 25 16:35:33 doh gotta run, will check back later Feb 25 16:35:35 thx so far :) Feb 25 16:44:22 moin Feb 25 16:44:32 yay, the sun is out... Feb 25 17:45:56 hello, does anyone knows if OE supports the Essential field on deb/ipk's and if not , if there are plans to add support? Feb 25 17:46:12 sounds convenient to be able to tag libc, etc as Essential Feb 25 17:50:17 adelcast: I don't believe so, no... we do map PRIORITY to Priority but that looks like it's separate Feb 25 17:52:57 bluelightning_: thanks, yeah, I couldn't find any reference on the source...would nice to add it to OE, but I can see how it might be problematic to decide on a policy (which packages are OK to be essential, a way to override settings, etc) Feb 25 17:54:47 adelcast: actually, the following did get implemented which you may be able to use in the absence of direct support for the Essential field: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=66055fbeddeb5f5b1fe84c24085f30daa6cfe003 Feb 25 17:55:02 it's not documented anywhere except for the commit message, should probably fix that Feb 25 17:58:44 ah!, very nice to know, we might need to add custom fields to some ipks in the future, this will give us a way to do it, thanks for sharing.....going back to Essential, I don't think it makes a lot of sense to tag some of our packages as Essential if libc is not Essential (unless I change it to use the tag with your trick) Feb 25 17:59:31 it all depends on what that tag actually gets the package manager to do I guess (stop it from being uninstalled I would guess?) Feb 25 17:59:45 yep Feb 25 18:11:47 it also maps to what debootstrap will pull in Feb 25 18:14:28 oh, so debootstrap will get all the Essential packages from a repo when creating a new rootfs? Feb 25 18:14:38 ah, that's interesting Feb 25 18:16:25 adelcast: that's how it was explained to me Feb 25 18:17:23 koen: very interesting, I guess that makes the case for adding support for Essential stronger Feb 25 18:19:01 essential: makes sense in a general purpose distro Feb 25 18:19:08 in a buildsystemd like OE, less so Feb 25 18:19:22 depends on the use cases you have in mind, i guess Feb 25 18:20:00 buildsystemd ... Feb 25 18:20:07 Lennart's latest project Feb 25 18:20:15 hehe Feb 25 18:20:58 Crofton: nah, just extend the units with a Source field, systemd will figure out the deps Feb 25 19:44:48 do we have a theme song? Or is that buildroot? Feb 25 19:52:39 * cbrake fires up a angstrom-dizzy systemd-image on bb-xm, and its hanging on boot with: [ TIME ] Timed out waiting for device dev-ttyO2.device.n[DEPEND] Dependency failed for Serial Getty on ttyO2.n Feb 25 19:53:04 hmmm Feb 25 20:08:46 bum console line? Feb 25 20:08:59 Did the rename the serial tty's Feb 25 20:09:06 denix, maybe Feb 25 20:09:27 bitbake font-font-misc fails Feb 25 20:12:56 Crofton: guess I'll stick a known good kernel on it in a bit and see if that fixes it Feb 25 20:13:41 the other fun for today is trying to get a Qt/Cmake app building in OE ... Feb 25 20:13:47 hmm Feb 25 20:13:50 anyone done that? Feb 25 20:13:52 gnuradio builds fine :) Feb 25 20:14:01 cmake + qt Feb 25 20:14:02 is that qt-cmake? Feb 25 20:14:07 cool, I'll check it out Feb 25 20:14:12 jsut cmake Feb 25 20:14:16 inherit cmake .... Feb 25 20:14:24 yeah, my cmake console apps work just fine Feb 25 20:14:31 I'm not going to say cmake is perfect :) Feb 25 20:14:41 but when I use the FindQt module, lots of thigns going wrong Feb 25 20:15:42 first puzzler is why are the Qt headers installed in overo/usr/include/qtopia -- is the qtopia dir just legacy? Feb 25 20:15:59 (vs qt4) Feb 25 20:16:10 hmmm Feb 25 20:16:20 OE master? Feb 25 20:16:27 so the FindQt4 module is pulling headers from x86_64-linux/usr/include/qt4 Feb 25 20:16:32 which does not work out too well Feb 25 20:16:52 It seems like I had to beat it pretty ahrd Feb 25 20:17:27 dora Feb 25 20:17:55 https://github.com/balister/meta-sdr/blob/master/recipes-core/gnuradio/gnuradio_git.bb#L188 Feb 25 20:18:04 I do not think my beating has changed in ages Feb 25 20:18:39 that looks useful -- thanks! Feb 25 20:34:16 fonts Feb 25 20:34:18 I ahte fonts Feb 25 20:35:06 nerdboy, can you send me a link to the OE theme song Feb 25 20:35:42 there's an OE theme song? Feb 25 20:35:52 apparently Feb 25 20:35:55 ask Stephanie Feb 25 20:36:12 * nerdboy wrote a song about advanced field geology once Feb 25 20:36:45 she's not on irc presently... Feb 25 20:36:58 I installed liberation-fonts, but xlsfonts doesn't show extra fonts Feb 25 20:37:20 ka6sox: do you have the link? Feb 25 20:47:21 nerdboy, not currently Feb 25 20:47:28 but I think I know where to get them Feb 25 21:02:34 re Feb 25 21:02:51 now i remember... Feb 25 21:02:59 khem: do you have a moment to help me understand whats going on with hard vs soft float for the poky imx build? Feb 25 21:03:15 it was called "Bamboozled by Gordon" Feb 25 21:03:21 Jin^eLD: sure Feb 25 21:03:38 so it seems you have a hf toolchain Feb 25 21:03:51 khem: so, my starting point was poky 1.5.3 for the imx target which did build fine without any problems Feb 25 21:03:52 but then one rogue app not respectiin the fact Feb 25 21:04:07 so make sure your app is compilable using hf Feb 25 21:04:11 I know Feb 25 21:04:23 things like uboot Feb 25 21:04:28 which dont use h/f Feb 25 21:04:31 can be issue Feb 25 21:04:37 but then uboot would fail? Feb 25 21:04:53 well wait, help me understand one thing: how can an include result in such a problem? Feb 25 21:04:58 I argue that they should use a differently configured toolchain to build it Feb 25 21:05:18 afaik the app that failed for me does not do anything special regarding soft/hard Feb 25 21:05:21 I doubt it even cares Feb 25 21:05:25 because gcc needs to define internal defines for VFP Feb 25 21:05:33 and if you do not pass correct ABI Feb 25 21:05:35 yes, and how does gcc know when it has to? Feb 25 21:05:36 it will fail Feb 25 21:05:51 with float abi option Feb 25 21:06:09 so you are saying it's an issue of the build system/makefiles of the particular app? Feb 25 21:06:18 I think so Feb 25 21:06:19 what does TUNE_FEATURES and TARGET_FPU say at the top of your build? Feb 25 21:06:41 uboot makes a valid case which I am inclined to understand Feb 25 21:06:52 but apps not at all Feb 25 21:06:57 uboot is a standalone app Feb 25 21:07:12 clear Feb 25 21:07:12 ls Feb 25 21:07:19 :) Feb 25 21:07:21 khem: well, in my case its not uboot and one of "our" apps which is hopfeully fixable, what am I grepping for? Feb 25 21:07:35 I am not aware of it setting anything special Feb 25 21:07:45 i take it fsl upgraded u-boot recently? Feb 25 21:07:57 mfloat-abi Feb 25 21:08:17 * nerdboy has no problems building u-boot manually or fsl layers Feb 25 21:08:20 -mfloat-abi=hard is what you want Feb 25 21:08:40 nerdboy, yes however they must have bandaged it Feb 25 21:08:56 khem: there is no single "mfloat" when grepping there, question: why do I have to set that at all? i.e. - the app does not really care how its being compiled Feb 25 21:09:00 shouldn't the toolchain set that? Feb 25 21:09:16 as the matter of fact the app does not even know if its going soft or hard float Feb 25 21:09:26 and btw the same app with the same target worked with poky 1.5.3 Feb 25 21:09:33 and I believe it was hard float too Feb 25 21:09:35 I can recheck Feb 25 21:09:44 only thing I updated was poky and associated layers Feb 25 21:09:48 hmm, looks like i have v2014.04 still Feb 25 21:10:23 Jin^eLD: poky used soft-float for longest time Feb 25 21:10:37 what is your build configuration o/p Feb 25 21:10:49 o/p means what? Feb 25 21:10:56 output Feb 25 21:11:03 it is possible to have breakage with ordering of fpu flags Feb 25 21:11:18 the topost prints when bitbake starts to builds Feb 25 21:11:32 nerdboy: no Feb 25 21:11:35 what does TUNE_FEATURES and TARGET_FPU Feb 25 21:11:47 but march can kill it Feb 25 21:11:56 thats why I am asking for build config Feb 25 21:11:59 https://pastebin.mozilla.org/8823334 Feb 25 21:12:00 khem: i've done it before with neon Feb 25 21:12:39 could depend on -march/other i suppose Feb 25 21:13:15 ok that looks good. nothing surprising there Feb 25 21:13:19 Jin^eLD: that looks correct Feb 25 21:13:34 now post the log.do_compile of your apps Feb 25 21:13:42 ok one sec Feb 25 21:15:04 https://pastebin.mozilla.org/8823335 Feb 25 21:15:08 * nerdboy pushes occasional use=neon fixes in the arm overlay Feb 25 21:15:30 thats cmake crap, I should probably recompile in devshell with V=1 Feb 25 21:15:35 to get the gcc invocations Feb 25 21:15:55 ah no, the last failed one has it Feb 25 21:16:12 cmake log is less than helpful... Feb 25 21:16:30 yes, I hate cmake, but the last one, the failed line Feb 25 21:16:32 there you see the flags Feb 25 21:16:39 line 90 in the pastebin Feb 25 21:16:51 an dlin e126 Feb 25 21:16:56 *and line 126 Feb 25 21:17:04 -mfloat-abi=hard Feb 25 21:17:06 its there Feb 25 21:17:07 hmm Feb 25 21:17:10 in 126, not in 90 though Feb 25 21:17:35 126 is linkage, I fail earlier Feb 25 21:17:48 no vfp flags, just neon Feb 25 21:18:24 * nerdboy has multiple arm machines on distcc cluster Feb 25 21:18:48 usually build with -vfpv3-d16 -neon Feb 25 21:18:51 I'll show you my machine conf Feb 25 21:19:01 I'm including OE default tunings Feb 25 21:19:20 hang on a sec Feb 25 21:21:29 https://gitorious.digitalstrom.org/dss-oe/dss-oe/blobs/master/yocto/dS/meta-digitalstrom-devel/conf/machine/dss11e.conf Feb 25 21:21:49 looks like poky master gives me the same config as yours Feb 25 21:21:59 arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8... Feb 25 21:22:36 Jin^eLD: the failing build is a local package? Feb 25 21:22:41 yes Feb 25 21:23:21 * nerdboy suggests checking include paths in source files/headers Feb 25 21:24:18 nerdboy: check that for what? what am I looking for? Feb 25 21:24:20 * nerdboy is not a cmake fan Feb 25 21:24:32 I hate cmake Feb 25 21:24:37 with the depth of my heart :) Feb 25 21:24:48 i was just going back to what khem was saying about u-boot headers Feb 25 21:25:14 I understood him in the way that uboot was kind of explicitly wanting to compile soft headers Feb 25 21:26:02 that package may not have optimal include paths Feb 25 21:26:16 thats not compelete output Feb 25 21:26:52 khem: that was the contents of the log.do_compile file Feb 25 21:27:18 * nerdboy scrolls back up a whacks his forehead Feb 25 21:28:48 see qfsm_ini.c Feb 25 21:29:03 thats not respecting usual TOOLCHAIN_OPTIONS flag Feb 25 21:29:08 that is your issue Feb 25 21:29:45 so it seems in some of your makefiles you are overriding env Feb 25 21:29:48 stop doing that Feb 25 21:30:00 and it will work Feb 25 21:30:12 ok let me try to find it, thanks a lot, this part is from "qpc" Feb 25 21:30:16 some package we imported Feb 25 21:30:28 gnu/stubs again... Feb 25 21:31:09 may be we should change the default ABI in gcc Feb 25 21:31:16 but thats a hard sell Feb 25 21:31:24 since they also support armv5te Feb 25 21:31:27 nobody should be messing with __ARM_PCS_VFP Feb 25 21:31:30 so they want LCD Feb 25 21:31:44 they are not Feb 25 21:32:00 but the fact that they dont specify -mfloat-abi Feb 25 21:32:08 is the issue Feb 25 21:32:33 you mean their flag is overriding and not defining... Feb 25 21:32:44 yes Feb 25 21:33:12 although it would be nicer if we changed defaults to use hard float if nothing was used on cmdline Feb 25 21:33:30 for those machines i agree Feb 25 21:33:53 * nerdboy wishes neon was ieee math Feb 25 21:34:08 but we want CC to not be modified Feb 25 21:34:21 otherwise folks have bigger issues to solve if they do Feb 25 21:34:29 seems like a waste without it... Feb 25 21:34:31 things like sstate starts puking Feb 25 21:35:15 * nerdboy dorked up his cache moving it to another machine... Feb 25 21:41:13 khem: thank you very much Feb 25 21:41:33 I just tried out the compile line manually, adding mfloat-abi (because I have no clue about the crappy cmake) and it copmiled Feb 25 21:41:36 *compiled Feb 25 21:41:43 so just as you said Feb 25 21:41:51 confirms it Feb 25 21:53:03 overriding flags is bad juju Feb 25 21:53:19 especially when they do it poorly... Feb 25 21:53:33 nerdboy: I know, I always take care of that, but I only work with autotools Feb 25 21:53:44 so I never bothered to inspect that package Feb 25 21:53:51 and now I'm also delegating it ;) Feb 25 21:54:01 I hate cmake so badly I just get mad when trying to do anything with it Feb 25 21:54:07 * nerdboy had to repeatedly whack developers for pushing hard-coded flags into the build Feb 25 21:54:48 problem is that those who maintain this app aren't necessarily cmake godfathers, at the same time they don't let me convert it to autotools Feb 25 21:54:58 sometimes they're even afraid of anything but static makefiles... Feb 25 21:55:12 sad, really... Feb 25 21:55:14 :) Feb 25 21:57:23 i love the packages with both cmake and outolools configs Feb 25 21:57:53 especially when they're not clear on which they are migrating to/from Feb 25 21:57:56 these are the ones where neither party won :) Feb 25 21:58:10 one is usually in favor Feb 25 21:58:13 "we hate each other, so lets do both" Feb 25 21:58:16 hard to tell sometimes Feb 25 21:58:22 well, the favor is just a matter of devotion of the particular dev Feb 25 21:58:30 the one who has more time wins ) Feb 25 21:58:43 * nerdboy always wins the commit wars Feb 25 21:59:24 and i get really itchy if i don't own the repos Feb 25 21:59:42 or at least the build/test/release branches... Feb 25 22:02:05 well, if it's autotools I'll usually fix it, if its plain makefiles probably too, but if its cmake - I'm off :> Feb 25 22:05:12 * nerdboy has always fixed randomly inherited buggy build systems Feb 25 22:05:45 nerdboy: there are certain lines that should not be crossed :) cmake is one of them :P Feb 25 22:05:49 you should check out the libbufr makefiles Feb 25 22:06:12 geeky science code... Feb 25 22:06:47 Jin^eLD: if cmake is your only thing, then i can throw all the scons packages your way if you want... Feb 25 22:06:57 oh crap I forgot about scons ;) Feb 25 22:06:59 forgot it exists Feb 25 22:07:06 luckily I never ever had to do anything with it Feb 25 22:07:22 * nerdboy is having deja vu Feb 25 22:08:00 this is almost exactly like two nights of gentoo dev dinner conversation at scale... Feb 25 22:08:24 parts of it anyway... Feb 25 22:08:56 "yeah, well, which is worse? mono or the JVM?" Feb 25 22:09:18 :) Feb 25 22:09:31 what are your thoughts on waf? :) Feb 25 22:09:41 I saw it only once, in a non cross env, luckily it worked Feb 25 22:09:44 never heard of it before Feb 25 22:10:36 Jin^eLD: heh, most devs aren't godfathers of any buildsystem. most autotools systems are just as cobbled together and copied and pasted as most folks cmakelists :) Feb 25 22:11:36 autotools is just a bit more open to corecion... Feb 25 22:11:57 *beating-over-the-haed even Feb 25 22:12:04 kergoth: well, that's the problem I guess.. if someone understands the system they can write stuff that will just work Feb 25 22:12:14 but I go with nerdboy here Feb 25 22:12:20 it is much easier to correct autotools issues Feb 25 22:12:28 although maybe only because I know my way around autotools Feb 25 22:13:17 cmake isn't conceptually mysterious, but each cmake instance has different ways of hiding stuff Feb 25 22:13:24 open source projects tend to over-emphasize code. not enough CM/build folk, or docs, or testing, or.. :) course, it depends on the project. small projects tend to be low on resources, but particularly those, it seems. and one person projects .. well, one person can only be clueful/expert in so many areas Feb 25 22:14:01 cmake people tend to miss config options and hide them in weird places Feb 25 22:15:20 * nerdboy is less technical than mr kergoth but has his 10000 hrs of OS development patch Feb 25 22:16:14 kinda like the AF captains with their 10000 hrs of poewrpoint patch... Feb 25 22:16:27 heh, i'm getting rusty in a lot of areas. used to be comfortable in all the layers of the system, but now i'm getting rusty in everything but build and distro, been neck deep in oe/yocto work for too long, not enough on-target Feb 25 22:16:38 need to work on that, getting pigeonholed :) Feb 25 22:21:20 i just promote myself to architecture guy Feb 25 22:37:40 kergoth: same trajectory is more common than you think... Feb 25 22:37:53 or maybe more than you would like Feb 25 22:38:46 IV&V guy, task lead, other stuff, systems architecture guy (with smattering of actual IV&V tasks) Feb 25 22:42:29 nrossi, awake yet? Feb 26 00:50:42 * nerdboy smells a shift change coming... Feb 26 01:16:34 nerdboy, Crofton: Im here now ;), slept in a bit today :) Feb 26 01:18:33 "Hello Sam..." "Good day, Ralph..." Feb 26 01:20:58 * nerdboy still practicing with the new espresso machine **** ENDING LOGGING AT Thu Feb 26 02:59:59 2015