**** BEGIN LOGGING AT Mon Oct 28 02:59:58 2013 Oct 28 08:04:36 good morning Oct 28 09:18:53 morning all Oct 28 09:29:10 hi bl Oct 28 09:29:57 hi woglinde Oct 28 09:53:36 hi bluelightning, woglinde Oct 28 09:53:59 hi mckoan Oct 28 11:29:52 Luckily all we returned from ELCE in time http://www.theguardian.com/uk-news/2013/oct/28/britain-storm-winds-death-flooding Oct 28 11:35:30 mckoan: that was no where near ELC-E Oct 28 11:38:37 and it's all fairly sensational I think; worse weather than usual but by no means a tsunami ;) Oct 28 11:39:09 jackmitchell: good to hear, in Scotland all we got was a little rain last night Oct 28 11:39:19 which is normal weather anyway! Oct 28 11:39:20 we've currently got glorious sunshine in Cambridge Oct 28 11:40:00 yeah, it was wet this morning, but I wouldn't have noticed if it hadn't been splashed all over the papers Oct 28 11:40:36 my friend from highlands has already pointed out that people are whining about a couple of hours power cut when up there they regularly get week long ones after storms Oct 28 12:00:14 Has anyone been able to build on Ubuntu 13.10? I'm having issues with elfutils and eglibc. Oct 28 12:00:14 I found a patch for gcc 4.8 and elfutils that seem to solve the first part but now I'm getting Oct 28 12:00:14 [setup-scripts/build/tmp-angstrom_v2012_12-eglibc/work/armv7a-vfp-neon-angstrom-linux-gnueabi/eglibc-2.16-r15+svnr20393/build-arm-angstrom-linux-gnueabi/manual/libc.info] Error 1 Oct 28 12:00:43 im using ubuntu 13.10 server and it works fine Oct 28 12:00:58 ok Oct 28 12:01:17 thats using yocto though Oct 28 12:02:02 GusBricker: ok... im using the Ångström setup-scripts. Could be something there then Oct 28 12:03:03 possibly, my config if it helps is: yocto:poky, meta-ti layer, and meta-oe layer Oct 28 12:04:08 I'll start digging... :-( Oct 28 12:05:39 kmpm libc.info are info sites Oct 28 12:05:49 so maybe the tool is missing or does something wrong Oct 28 12:18:09 woglinde: what tool? I have installed texinfo. Oct 28 12:18:16 any hint is welcome Oct 28 12:22:20 kmpm hm look in the logs Oct 28 12:41:31 koen: how is it Poky wouln't be Yocto-compatible :-? Oct 28 12:47:06 ant_work: check the compliance registrat on the yocto website Oct 28 12:48:04 https://www.yoctoproject.org/ecosystem/compliance-program-registrar Oct 28 12:48:22 no poky there Oct 28 12:48:41 but angstrom, arago, MEL and enea are Oct 28 12:50:31 right Oct 28 12:51:14 why don't they use the default distro oe-core.0 ? Oct 28 12:52:40 maybe to show how to customize a distro Oct 28 12:53:17 ant_work: I asked that ~8 months ago Oct 28 12:53:33 ant_work: the response was "You need poky to build oe-core" Oct 28 12:53:44 so I asked "what about oe-core distroless?" Oct 28 12:53:48 ah, I didn't know ;) Oct 28 12:53:55 the response "distroless, what's that?" Oct 28 12:54:28 maybe if we rename oe-core.o to Poky it will pass Oct 28 12:54:29 I did manage to get the yocto folks to update the yocto docs to say that poky is *a* distro, not the only distro Oct 28 12:55:07 I talked to the yocto AB to get it fixed: *crickets* Oct 28 12:55:19 the OE TSC said it's not a TSC problem Oct 28 12:55:50 so I just complain at conferences and emails since noone wants to fix it Oct 28 12:56:02 * koen finds some more windmills to tilt at Oct 28 12:57:30 koen: save the Whale Oct 28 12:58:51 ant_work: so in summary: Poky is not yocto compatible, but angstrom is Oct 28 13:00:54 not my area of expertise, but I would assume that poky, being the reference build system and reference distro for the yocto project would be de-facto compatible Oct 28 13:01:01 koen: tbh I see that participant-registration form doesn't mention Poky Oct 28 13:01:21 hat's a good start Oct 28 13:02:31 bluelightning: cute Oct 28 13:02:45 bluelightning: when the rules first came out poky failed miserably Oct 28 13:03:06 RP had to make emergency commits a few days before the release to fix most of the issues Oct 28 13:03:07 koen: yes, and if you recall its structure was changed in response Oct 28 13:03:18 but still Oct 28 13:03:23 it's not on the page Oct 28 13:03:37 so de jure it's not compatible Oct 28 13:03:38 a problem was discovered and it was fixed... I don't see that as particularly remarkable Oct 28 13:03:53 if it makes you feel better I'm sure we can run it through the official procedure Oct 28 13:04:07 I've been asking for that ever since 1.2 Oct 28 13:04:19 bluelightning: neverthless it is strange that for testing the whole you use a customized 'reference' distro and not the defaults of the metadata... Oct 28 13:04:29 I don't run in all circles, but FWIW it's the first I've heard of the complaint Oct 28 13:04:57 if the point is doing tests Oct 28 13:05:05 and like ant_work says, oe-core distroless would be the thing to use in the "beginner" stuff and then use poky as an example for the "advanced" things Oct 28 13:05:36 ant_work: AIUI it's because we prefer some defaults that OpenEmbedded would rather not have set Oct 28 13:06:22 I'm not aware of those problems, maybe someone can talk with i.e. Koen Oct 28 13:06:33 I asked the people involved Oct 28 13:06:45 it boiled down to "we got told to use poky" Oct 28 13:07:01 and at the higher level noone knows about distroless Oct 28 13:07:15 bluelightning: we can change the defaults and match Poky if it is an improvement Oct 28 13:07:31 because we (developers) stopped caring about naming stuff after the oe-core rename was halfway done Oct 28 13:07:38 managers aren't experts in every technical detail, news at 11... Oct 28 13:07:40 bluelightning: you are in the position of being able to judge ;) Oct 28 13:09:32 like Crofton|work said, "we need an OE marketing team" Oct 28 13:09:52 :) Oct 28 13:10:34 Crofton|work: I get a 10% discount at IHOP with my room key, I guess I'll need 2 seats on the flight back Oct 28 13:10:57 rofl Oct 28 13:11:10 :-D Oct 28 13:11:30 the crowd of people waiting to get seated during eating hours creeps me out, though Oct 28 13:12:01 XorA: did you make it to Connect ? Oct 28 13:12:12 koen: no, I did not have enough mobility to fly Oct 28 13:12:25 damn Oct 28 13:12:36 can finally today bend my knee to about 45 degrees Oct 28 13:12:38 now we really need an OE dev day Oct 28 13:13:27 still got SFA strength in it though Oct 28 13:13:36 koen, we need your overlords on board to pay for peoples travel Oct 28 13:16:34 anyone still using qt-mobility? Aren't e.g. QtLocation headers completely broken since Jun? Oct 28 13:17:01 /usr/include/qt4/QtLocation/qgeopositioninfosource.h is now in Oct 28 13:17:02 /usr/include/QtLocation/qgeopositioninfosource.h Oct 28 13:22:13 JaMa: which commit broke that? Oct 28 13:23:52 build with revert still running but only related commit in range found in buildhistory is f7409a9fe83ba2535a43f39ed57cd78242a88557 Oct 28 13:23:57 oe-core Oct 28 15:40:44 kmpm: From my 13.10 install it looks like it installs texinfo 5.1. Arch has been unable to build dylan for the last several months because it upgraded to 5.x, for fundamental things like binutils. So it would not surprise me that's the problem Oct 28 15:41:28 kmpm: Unfortunately you might be forced to employ the same workaround I have employed — debootstrap + schroot into a 12.10 install for all builds Oct 28 15:43:03 rtollert: kmpm: you can install the buildtools in order to get a basic complient set of tools Oct 28 15:43:26 you source the environment file like you would an SDK, and it adds the path to the pre-compiled tools to your system path Oct 28 15:43:43 which OE will then use in the build Oct 28 15:43:56 no need to do something as extreme as a chroot Oct 28 15:44:31 jackmitchell: hm. I'm not familiar with this facility Oct 28 15:45:18 rtollert: www.yoctoproject.org/docs/current/mega-manual/mega-manual.html Oct 28 15:45:22 section 1.3.3 Oct 28 15:45:30 searching "buildtools" will find it Oct 28 15:48:07 jackmitchell: Ah. It's not in dylan, only dora. That's why I don't know about it. Oct 28 15:49:00 rtollert: ah ok, it should still work regardless, but I'm not sure if it ships a supported version of texinfo so maybe it won't... Oct 28 15:51:47 jackmitchell: also, buildtools-tarball in dora appears to not even build texinfo anyway. :F Oct 28 15:53:07 jackmitchell: nevertheless: if I take this, and make it build native- instead of nativesdk-, and add texinfo, and make it a packagegroup instead of a tarball... in principle, if I build that before building anything else, we should be able to break the dependency on OS texinfo, right? Oct 28 15:53:08 rtollert: when you say "dylan" which version do you mean exactly? a number of texinfo fixes have been backported on the dylan branch Oct 28 15:54:15 bluelightning: I last tested building under Arch back in August, so origin/dylan sync'd up to that timeframe is what I would be referring to. If fixes have been made since then, I haven't attempted to validate them. Oct 28 15:54:55 and I figured adpapp is just as angry now as he was back in june, so arch would probably still be broken :D Oct 28 15:55:04 perhaps I'm mistaken? Oct 28 15:55:47 I use Arch, but not with dylan. I do however believe as bluelightning mentioned, there have been texinfo fixes backported Oct 28 15:57:58 ok, I'll give them a shot, thanks Oct 28 15:59:46 koen: bluelightning: fwiw, the DISTRO-less OE thing is something that has bit us personally. I that we were building without a DISTRO setting, but it was too late to change it, so we shipped like that. Oct 28 16:00:02 :( Oct 28 16:02:07 rtollert: shouldn't be a disaster though... Oct 28 16:03:37 bluelightning: it wasn't, but it made figuring out The Right Thing To Do re config changes that much more difficult. In particular, we wound up making DISTRO_FEATURES changes to local.conf... Oct 28 16:03:59 distroless is intended as a sensible default I believe, it's just quite conservative Oct 28 16:04:00 rtollert: right, I see Oct 28 16:04:11 rtollert: we do now spell it out in the manual at least Oct 28 16:04:23 (for 1.4+) Oct 28 16:04:42 bluelightning: And actually, that segues very nicely to a question I need to re-ask, since apparently everybody save Crofton was gone on Friday Oct 28 16:05:38 sure, fire away Oct 28 16:06:05 How kosher is it to build different DISTROs in the same build/ tree? And beyond that — is it OK to use the same sstate-cache/ and PR server for different (MACHINE, DISTRO) tuples? Oct 28 16:07:41 keeping same build tree / other components when changing MACHINE is well-tested Oct 28 16:07:54 indeed Oct 28 16:08:05 but I would advise not trying to do the same with DISTRO Oct 28 16:09:01 sstate is fine though, distro/machine are appropriately captured in the metadata checksums Oct 28 16:09:10 right Oct 28 16:11:38 I think that generally agrees with what I observed on Friday, with one important caveat: the sstate/manifest are sufficiently intelligent about what is/isn't in the sysroot, that when DISTRO_A rebuilds over DISTRO_B, it will re-setscene all the packages that got changed due to DISTRO_FEATURES differences Oct 28 16:12:15 so afaik, correct results, but extra work needed in the rebuild that would not have happened if the two distros were built in different build/ trees Oct 28 16:13:36 if I use the same PR server for all distros, is there any risk of driving up the PR due to constant checksum changes? Or is the PR server more distro aware than that? Oct 28 16:19:02 rtollert: there is that risk yes, you'd be better off with separate PR server instances Oct 28 16:19:09 AFAIK Oct 28 16:21:13 bluelightning: ok Oct 28 16:30:28 the PR server is clueless :) Oct 28 16:31:30 rtollert, also, I was gone on Friday, but just happened to be slacking on irc briefly Oct 28 16:33:49 moin Oct 28 16:35:40 Crofton|work: suuure ;) Oct 28 16:41:19 I have one more question then I think I'm done. If I set up a shared PR server, then would the PR for a package increment every time a developer makes a local tweak to their build? So that the "released" package PRs increase by more than 1? (Follow-up question: is this intended behavior?) Oct 28 16:41:39 this is the intended behavior Oct 28 16:41:51 ok Oct 28 16:42:06 but we talked about limiting which build slaves are allowed to bump PR at the Yocto BoF last week Oct 28 16:42:41 the current behavior is really annoying for Angstrom, since we encourage random people to build locally Oct 28 16:42:49 and when they do they bump the PR server Oct 28 16:42:56 which messes with package feeds Oct 28 16:43:08 ic Oct 28 16:44:31 ok thanks! Oct 28 16:47:19 heh, yeah, it would be nice for the users to have r/o but the build server to have r/w Oct 28 16:47:22 * kergoth yawns Oct 28 16:53:36 kergoth, +1 Oct 28 16:54:05 sgw gave me a hard time for referring to people that should be ro wrt the PR server as "the unwashed masses" Oct 28 16:54:12 hehe Oct 28 16:54:25 I am really hoping that session was not on video ... Oct 28 16:57:27 the problem is what such user should do when it has different signature then build server and it cannot just bump it locally Oct 28 16:57:42 because maybe the next build server signature will be the same but with different number Oct 28 16:58:32 but we need to expose the PR server, but we need to rpevent random bumps Oct 28 16:58:49 using max(from-r/o-pr-server).your-local-AUTOPR value doesn't work, because your different local signature isn't always "newer" than what build server has Oct 28 16:58:50 if the PR is funny att he user end, they can force installs etc Oct 28 16:58:59 or commit when done Oct 28 16:59:15 I agree it is messy, but we need to protect binary feeds Oct 28 16:59:33 random question Oct 28 16:59:54 I have exposed PR server and it's safer to let local users to "bump" it because at least they pre-allocate some number from their signature Oct 28 16:59:59 how much do we care about vendiors leaving internal bug tracking stuff in commit messages? Oct 28 17:00:12 so I can be sure that official build server won't build exactly same .ipk Oct 28 17:01:12 Crofton|work: I hate when it's just some number, if it has also subject or something which adds at least some information to message I don't mind Oct 28 17:02:01 I understand that. I expect the rest of the message to be a complete stand alone message Oct 28 17:02:06 I don't mind if it's just metadata down the message Oct 28 17:02:09 right, exactly Oct 28 17:02:16 understandable without looking att he references Oct 28 17:02:19 it still has to be a solid message meeting git conventions Oct 28 17:02:23 +1 Oct 28 17:02:42 I am thinking that tolerating the internal tracking numbers makes it easier for them to upstream stuff Oct 28 17:02:48 that said, presumably vendors could start using branches of git-notes to hold it out of band Oct 28 17:02:50 which is a win for all Oct 28 17:03:03 but i'm not sure if git has good fetch/merge/push stuff for that yet.. Oct 28 17:03:08 * kergoth nods Oct 28 17:03:34 it likely depends on the repository, too, some maintainers are more picky than others :) Oct 28 17:10:42 How problematic would it be if vendor-specific IDs were used in lieu of Acked-By (by other vendor devs)? Oct 28 17:18:12 (given the lack of Acked-By:s in oe-core commits I'm guessing not that much of a problem) Oct 28 17:26:19 JaMa: thanks! Oct 28 17:31:13 koen: yw Oct 28 17:34:09 rtollert, I suspect we'd still like to see the Ack's Oct 28 17:34:30 Crofton|work: ok Oct 28 17:46:55 * koen bangs head against wall Oct 28 17:47:09 "OE or running yocto on top of openembedded" Oct 28 17:47:17 from the cavium guy in the room Oct 28 17:54:50 * kergoth chuckles Oct 28 17:59:04 y'all have nothing to blame but yourselves Oct 28 18:04:47 I promote rtollert to the status of honorary troll **** ENDING LOGGING AT Tue Oct 29 02:59:58 2013