**** BEGIN LOGGING AT Fri Apr 08 02:59:58 2016 Apr 08 07:57:56 good morning Apr 08 10:00:24 meh, my latest meta-openembedded includes lua_5.2... instead of the old lua5.1_ Apr 08 10:00:46 I am trying to get around this with PREFERRED_PROVIDER_lua = "lua5.1" but that is not working. Any ideas? Apr 08 10:01:21 Basically I cant target the old lua version because the ${PN} = lua5.1. What to do? Apr 08 10:03:58 hm does PREFERRED_VERSION trigger onto PN or on to the pattern in the recipe? Apr 08 10:04:24 I thought it was everything after the underscore? Apr 08 10:04:33 I could try that... Apr 08 10:04:58 nah, PREFERRED_VERSION_lua = "lua5.1" Apr 08 10:05:13 *could* work if it triggers onto PN Apr 08 10:05:23 let me see Apr 08 10:05:25 if not, give = "5.1" a try :-) Apr 08 10:05:43 oh, and should it be PV anyways? Apr 08 10:05:57 I thought so Apr 08 10:06:08 since there is a preferred provider option Apr 08 10:06:36 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PREFERRED_VERSION Apr 08 10:13:22 I am going to bbappend that lua5.1 recipy with provides = "lua", that should fix things Apr 08 10:13:44 then preferred_version should latch Apr 08 10:13:57 preferred_provider is not working like I think it should Apr 08 10:15:15 :-) Apr 08 10:15:36 let me tell you, thinking is completely overrated in general Apr 08 10:15:44 hehe Apr 08 10:16:53 this project is still on yocto 1.6 so I cant go digging and patching, im just gonna hack it Apr 08 10:26:37 aah check it Apr 08 10:27:34 If I add PROVIDES = "lua" in a recipy that is named lua5.1_5.1.5.bb then it can be selected as PREFERRED_PROVIDER = "lua5.1" Apr 08 10:27:48 If I add PROVIDES = "lua" in a recipy that is named lua5.1_5.1.5.bb then it can be selected as PREFERRED_PROVIDER_lua = "lua5.1" Apr 08 10:28:14 it makes sense Apr 08 10:29:21 So it does work like I thought it should, just with a bit more kicking Apr 08 14:29:31 Does anyone know what time OEDAM is starting, I'm driving down from Encinitas. Apr 08 15:06:35 georgem: from last official emails OEDAM will take place at the Catamaran Resort Apr 08 15:07:00 georgem: start the meeting at 9am, so please plan to be there by Apr 08 15:07:03 8:45 or so Apr 08 15:36:35 tbr: rburton: kergoth: sshfs + file: uri in opkg.conf works perfectly.. Apr 08 15:37:06 glad to have helped Apr 08 16:26:49 OEDAM starting Apr 08 16:27:28 pound OE! Apr 08 16:27:29 RP, awake? Apr 08 16:27:37 pound koen Apr 08 16:27:43 Crofton: yes Apr 08 16:27:45 not lbs oe? Apr 08 16:36:29 RP: we can hear you Apr 08 16:38:17 koen: sadly I can't hear anything Apr 08 16:38:19 If OEDAM happens in a forrest and nobody hears it, does it make a sound? Apr 08 16:38:38 lol turn up the volume on your IRC Apr 08 16:38:38 CAN YOU HEAR US NOW? Apr 08 16:38:54 "Would you like to play a game?" Apr 08 16:39:04 How about a nice game of chess? Apr 08 16:39:48 no, thermonuclear war Apr 08 16:40:21 it ounds like you are all thumping around Apr 08 16:41:32 MUTE Apr 08 16:41:32 the buzzsaw sound effect makes this interesting along with birds chirping Apr 08 16:41:52 you still getting effects? we're not hearing much here Apr 08 16:42:01 its ok, it comes and goes Apr 08 16:42:07 i can mostly hear buzzing Apr 08 16:42:10 oh video! Apr 08 16:42:19 there is video? Apr 08 16:42:26 nice to see halstead has an awesome beard still Apr 08 16:42:32 jefro just started the video Apr 08 16:42:54 * rburton wonders if crofton relays everything he says Apr 08 16:42:55 Thanks rburton I trimmed about 4 inches for spring. Apr 08 16:42:58 Crofton: JUMP UP AND DOWN Apr 08 16:43:04 There is food behind you. Apr 08 16:43:07 this is awesome Apr 08 16:43:18 must not abuse powers for evil Apr 08 16:43:25 * behanw loads food into #oe Apr 08 16:43:37 got it now Apr 08 16:43:38 halstead: i'm in awe of your beard-fu Apr 08 16:43:52 what the hell was that Apr 08 16:43:58 food Apr 08 16:44:01 really? Apr 08 16:44:11 no.. it was Crofton Apr 08 16:44:13 for some definition of food I guess Apr 08 16:44:38 that fizzing is very special Apr 08 16:45:12 Please visit http://openembedded.org/wiki/OEDAM_2016#Agenda_Items Apr 08 16:46:00 hi Jefro Apr 08 16:46:07 the audio is hysterical Apr 08 16:46:13 i think its time for someone to make a yocto-powered conference bridge thingy, with multiple mics and a video camera Apr 08 16:46:36 rburton +1000 Apr 08 16:46:46 I will find funds if someone want to do that Apr 08 16:47:16 Can you type that? We are having level issues Apr 08 16:47:19 Jefro: convince DaveC to give us 20% time Apr 08 16:47:20 rburton: polycom uses OE Apr 08 16:48:21 talk Apr 08 16:48:45 If it helps I can just type here Apr 08 16:48:48 do so Apr 08 16:48:50 I can relay Apr 08 16:49:00 we've already established that Crofton is a puppet for #oe Apr 08 16:49:18 My point was it would be better to discuss new topics than previous topics we've discussed to death - perhaps only cover those for things that have changed? Apr 08 16:49:59 My point is we haven't really don many of the bsp stuff. Apr 08 16:50:03 done any Apr 08 16:50:10 someone on ehte hangout say something Apr 08 16:50:11 That came through as "I'm going to unplug " Apr 08 16:50:28 thakns Apr 08 16:50:31 can you hear us? Apr 08 16:50:40 derp Apr 08 16:52:08 can you hear us OK? Apr 08 16:52:24 We can hear you Apr 08 16:53:00 Jefro: this is an improvement over last years so i'd be happy with that if i were you Apr 08 16:53:07 The mic setup there means we can hear everyone's conversations at once Apr 08 16:53:15 in a good way? Apr 08 16:53:18 Tom's conversation is very clear for example Apr 08 16:53:20 ervyone is suddenly talking Apr 08 16:53:22 HAHAHA Apr 08 16:55:15 you can hear ok? Apr 08 16:55:22 We have two areas we collect data right now, error reporting and layer index Apr 08 16:55:31 bit muffled, fizzing is back Apr 08 16:55:38 Crofton: lots of buzzing and china clinking Apr 08 16:55:46 that's Sean Apr 08 16:55:49 (the china) Apr 08 16:55:56 buzzing or clinking? Apr 08 16:55:57 if it doesn't get better let us know Apr 08 16:56:06 clinking.. ;) Apr 08 16:58:16 Can someone mention that we have two data collection things atm, error reporting and layer index. One possible option is to extend those to include build successes too. We also have buildhistory and build performance data we need to do something with Apr 08 16:58:56 Hmm, is Paul awake Apr 08 16:59:16 Crofton: Paul is .nz so its like 3-4am there Apr 08 16:59:21 k Apr 08 16:59:26 5am Apr 08 16:59:28 sleep is for the ak Apr 08 16:59:28 I'm lost in time Apr 08 16:59:29 should be 8am in NZ Apr 08 17:00:01 Jefro: its definitely not, DST pushs it out of line Apr 08 17:00:12 damn time zones :) Apr 08 17:00:16 lol Apr 08 17:01:32 To be honest I think we all agree there is a problem here and something needs to collect data. We need people to work on that thing and its really a developer time to spend on it problem Apr 08 17:02:10 agreed Apr 08 17:02:20 whatever just changed stopped the buzzing which was great! Apr 08 17:02:29 afaik, nothing Apr 08 17:02:36 air conditioning turned on Apr 08 17:02:59 moto-timo: noise floor changed I guess Apr 08 17:03:03 I like the idea of publishing "working" builds as trevor is saying Apr 08 17:04:25 fray_oe: We need to define what "working" means. Apr 08 17:04:31 And what a "test" entails. Apr 08 17:04:41 yes.. Apr 08 17:04:43 I mean that seriously Apr 08 17:04:57 I'd saying the default is "it builds" (or not).. minimal test.. Apr 08 17:04:58 true quality would be ptests were run Apr 08 17:05:04 fray_oe: Agreed. Apr 08 17:05:07 then move forward to ptests, and other test cases Apr 08 17:05:17 But some minimal other tests may be worthwhile. Apr 08 17:05:18 builds and boots Apr 08 17:05:26 Certainly boot test minimal in my mind Apr 08 17:05:31 moto-timo: +1 Apr 08 17:05:42 yes.. build -> boot -> ptest -> ? Apr 08 17:05:59 #webos-ports-jenkins Apr 08 17:06:43 builds is the first step and tells a lot, then you can add boots Apr 08 17:07:44 RP: Agreed. Apr 08 17:10:13 does the error reporting tool have everything we need to capture the inputs of a successful build? Apr 08 17:10:21 I think a class makes more sense than devtool, not everyone uses devtool. Better to use the erorr reporting tool style Apr 08 17:10:26 afk Apr 08 17:10:52 kergoth: or both :) Apr 08 17:10:52 kergoth: Agreed. Apr 08 17:11:01 kergoth, agreed Apr 08 17:11:04 moto-timo: Well devtool can use the class Apr 08 17:11:12 behanw: +1 Apr 08 17:13:12 One thing that would help is to have the automated layer tests I've talked about Apr 08 17:13:12 Those would confirm if layers are well behaved and then the exact list of layers configured would be less important, assuming they pass these new tests Apr 08 17:13:41 we already have some tests like this in oe-selftest for different reasons (using the sstate sigs) Apr 08 17:15:05 Zeddii has left the building... Apr 08 17:17:46 * RP never saw zeddii... Apr 08 17:17:58 he was sitting more or less beside the camera.. Apr 08 17:19:57 (I'd really like to enforce packages w/ machine specific overrides MUST Have package arch set to machine arch Apr 08 17:21:11 fray_oe: +1 Apr 08 17:24:23 the smart guys are off camera Apr 08 17:25:22 (sorry for clinking) Apr 08 17:25:53 FWIW the freescale layers cause us immense pain on the YP autobuilder too Apr 08 17:26:37 fray_oe: I thought we did enforce that, at least in core Apr 08 17:27:00 lots of layers and customer work doesn't do it cause people don't understadn the pain it causes.. Apr 08 17:28:08 this is where I advocate multiple layers within a "master" project? layer Apr 08 17:28:26 i.e. meta-freescale contains a distro, a bsp, a ??? layer.. Apr 08 17:28:36 fray_oe: agreed Apr 08 17:28:44 fray_oe: The only issue is then that the BSP should have metadata about what the layer, or master layer provides Apr 08 17:28:44 That said, our philosophy regarding the distro, machine, and image being orthogonal isn't, to my knowledge, documented anywhere. I think we need to fix that Apr 08 17:29:20 kergoth: +1 Apr 08 17:29:28 kergoth: +1000 Apr 08 17:29:42 Maybe once we agree a "lint" tool which looks at conf files for aberations? Apr 08 17:29:42 +10000 Apr 08 17:30:34 * RP wishes people would send Scott Rifenbark raw material for the docs Apr 08 17:30:54 RP: +10^6 Apr 08 17:31:44 RP: +1 Apr 08 17:32:26 and becomes a technical bug we can "fix" Apr 08 17:34:59 The plan is to add some specific tests based on the sstate sigs which could determine if its a machine layer or distro layer Apr 08 17:35:35 I'd say initial check.. conf/distro , conf/machine -- fail those, problem.. then move on to validation with the tests like that Apr 08 17:36:07 fray_oe: The existence of the dirs isn't sufficient. Apr 08 17:36:17 Which distros are provided. Apr 08 17:36:18 dirs with something in them are a very good indicator.. Apr 08 17:36:23 its amazing what you can tell from the sigs Apr 08 17:36:24 Which bsps are provided? Apr 08 17:36:34 aren't we talking about some new metadata? Apr 08 17:36:51 fray_oe: The dirs are an indicator they *may* contain a BSP or distro Apr 08 17:37:04 set MACHINE = "x", get the sigs. set to a different machine, same arch, see which sigs change Apr 08 17:37:16 correct -- but if you have both a BSP (machine) and distro dir, it's probably an error Apr 08 17:37:20 you can then tell if its a machine layer Apr 08 17:37:27 come up with a list of must have, can have, should not have for each layer type, write tool to perform those checks. Apr 08 17:37:42 heh, I have a layer with machine and distro Apr 08 17:37:44 I don't think we should include layer type info in the layer itself beyond the existence of conf/{distro,machine,sdkmachine}/*.conf. If the existence of those files is conflicting with reality, then those layers are broken. I'd agree that sigs are a great way to do further sanity testing, though Apr 08 17:37:54 but I'm not goi ngto be stubborn Apr 08 17:38:33 Crofton: you can do that but you'll only get amber status, not green and can't be YP compatible ;-) Apr 08 17:38:50 Crofton: that would be in violation of the yocto project compliance guidelines (which, btw, really need to be made more prominent..) :) Apr 08 17:38:52 RP: :) Apr 08 17:38:53 I'll explain the reasoning sometime Apr 08 17:39:18 I also expect the machine part to build if used with other distros Apr 08 17:39:29 you can do a similar test for DISTRO = "x" Apr 08 17:39:30 selecting the distro isn't required Apr 08 17:39:59 also, the other interesting test is when you *don't* set MACHINE or DISTRO to the layer but add and remove it from bblayers Apr 08 17:40:17 if the sigs change, instant layer fail for YP compatible Apr 08 17:41:51 kergoth, frankly thats my initial thought on the "metadata" aspect.. if the dirs exit and have "some" content, then it's a flag to me.. if there is a distro directory and it's not a "distro" layer -- thats a big red flag for me Apr 08 17:42:18 kergoth: the problem with not having a central place for that info in the layer means you have to look in a lot of places to figure things out Apr 08 17:42:37 Instead of one metadata file which sumarizes things and is verifiable Apr 08 17:42:39 With tools Apr 08 17:42:41 only the same places bitbake looks Apr 08 17:42:45 which will never be out of sync with bitbake itself Apr 08 17:42:46 Externally. Apr 08 17:42:49 Without bitbake. Apr 08 17:43:01 We should be able to get that info remotely from the git repo Apr 08 17:43:04 without cloning Apr 08 17:43:16 I do think in this case it's an easy parse.. same w/ the dependency info for a layer is in the conf/layer.conf -- the catch with having an external metadata file (not automatically generated) is you get stuck with people not knowing htey have to update the file Apr 08 17:43:21 I don't really see the point, personally. it's just more info to maintain Apr 08 17:43:28 and most layers wont' end up doing it anyway Apr 08 17:43:35 fray_oe: Not external. *in* the layer. Apr 08 17:43:43 I agree with that.. manually maininging info in multiple places always leads to bugs Apr 08 17:43:46 kergoth: mostly fire-and-forget Apr 08 17:43:51 good luck getting all the layer maintainers to add it Apr 08 17:44:06 fray_oe: We can mostly generate and verify the file Apr 08 17:44:24 we can easily geenrate the file based on conditions.. but I don't epxect it will be in the layer itself (unless the maintainer decides to do it).. but we have easy conditions we can set the flags based on Apr 08 17:44:25 kergoth: Well, it can be added as a requirement. Apr 08 17:44:45 And a tool can make it a oneliner fix for people. Apr 08 17:44:47 requirement for what? yocto compliance? you'll get a lot of push back on that, guaranteed Apr 08 17:44:56 layer index inclusion Apr 08 17:45:20 start as a recommendation. Then a warning. Then a requirement. phased approach Apr 08 17:45:23 the layer index already downloads (git clone) the layer for validation.. adding a quick step to parse the data is simple.. Apr 08 17:45:38 fray_oe: So I have to clone things to see what they do? Apr 08 17:45:39 FAIL Apr 08 17:45:50 koen, how would you set tunes and hard/soft float in bsp w/o forcing it on distro? Apr 08 17:45:51 why is that any different from today? Apr 08 17:45:57 you can't examine repo contents without cloning them at all, that's how git works Apr 08 17:46:01 I either have to use a web git, or clone something ot know what it's doing Apr 08 17:46:01 fray_oe: Precisely my point Apr 08 17:46:02 is someone logging this ? Apr 08 17:46:06 all you can examine is branch reference heads Apr 08 17:46:08 fray_oe: It is broken today Apr 08 17:46:11 kergoth, gitweb? Apr 08 17:46:13 adding a new file to the repo isn't going to magically change that Apr 08 17:46:14 denix: I like the met-ti way, jsut bb.warn about the binary drivers not working Apr 08 17:46:26 you can "clone" a single file, or look at a directory tree without having to pull it all down Apr 08 17:46:37 logs.nslu2-linux.org Apr 08 17:47:08 fray_oe: Right. you can read a single file trivially. Cloning a repo to figure stuff out is the fail. Apr 08 17:47:24 I'm arguing for a single conf file which provides metadata about the layer Apr 08 17:47:30 without involving bitbake Apr 08 17:47:43 koen, I was thinking of DEFAULTTUNE Apr 08 17:47:59 ya, I'm saying all you need is the layer itself -- not OE to do the initial parse Apr 08 17:48:08 koen, btw, meta-ti sets it conditionally - e.g. DEFAULTTUNE ?= "cortexa8thf-neon" Apr 08 17:48:18 fray_oe: Ah. I see. Apr 08 17:48:22 Yes I think we are agreeing. Apr 08 17:48:42 behanw: whilst I can see the attraction of this from an external perspective, we already can tell what these layers are doing, directly through what bitbake uses in the layer. The file would duplicate info and as soon as you duplicate info, you create pain Apr 08 17:49:01 RP: I need to explain this to othere regularly. Apr 08 17:49:11 What we have is non-optimal. Apr 08 17:49:18 I don't like WET designs. Apr 08 17:49:37 But a summary conf file which can be generated isn't too awful. Apr 08 17:49:44 behanw: so we need to better document it or make it more obvious. Duplicating data doesn't help though Apr 08 17:49:47 and makes external tools a lot easier to write Apr 08 17:49:58 RP: No, we need a simpler thing to explain. Apr 08 17:50:12 perhaps we can use Henry Bruce's efforts to collect some of this best practice Apr 08 17:50:13 Solving complexity with a thicker manual doesn't help Apr 08 17:50:27 * kergoth is strongly opposed to adding more crap to maintain to our layers just because people can't be bothered to look at conf/ Apr 08 17:50:29 Especially when you can simplify the problem Apr 08 17:50:58 kergoth: It's not a "can't be bothered" Apr 08 17:51:10 This is making things easier for people who aren't OE devs Apr 08 17:51:19 kergoth: Think of your users Apr 08 17:51:27 behanw: peraps are learning OE devs or new to the project Apr 08 17:51:30 users can read the readme, they have to anyway to know how to use the layer Apr 08 17:51:55 readme though is "human" readable and freeform generally.. (and I find it gets out of date regularly) Apr 08 17:52:01 kergoth: I'm talking about tools which automate things Apr 08 17:52:08 Without requiring you to read all the READMEs Apr 08 17:52:11 are you talking about users or tools? you keep flip-flopping Apr 08 17:52:26 kergoth: Tools which make it easier for users Apr 08 17:52:35 I haven't changed at all what I'm talking about Apr 08 17:52:51 Tools are only useful to humans Apr 08 17:52:53 if you're talking about tools, they can trivially check what the layer is without adding anything with a simple heuristic Apr 08 17:53:16 kergoth: Which means implementing the same mechanism in each tool Apr 08 17:53:40 and if you add a new file, each tool then has to parse that file instead. pick your duplicated logic Apr 08 17:53:52 kergoth: Again, I'm talking about being able to read info both from within and without OE/bitbake/etc Apr 08 17:53:53 behanw: OE is designed to be powerful with large amounts of capability and functionality. Powerful can sometimes mean complex and whilst we do try and keep things simple where we can (I've made many changes to try and improve that), we have a policy of not sacrificing that capability for simplicity/ease of use. Other projects exist with simplicity as their objectives, it isn't where OE came from. Apr 08 17:54:23 RP: I'm not arguing triviallizing OE Apr 08 17:54:59 behanw: we actually have library functions for tools like recipetool and devtool and adding a "is this a machine layer" function to those would be straightforward Apr 08 17:55:06 hmm, I need to send that to Alexandre to help him with BR vs OE Apr 08 17:56:46 RP Should work without those things available Apr 08 17:57:18 You're never going to completely document layer usage in a file like that. The best you can do is duplicate the knowledge of whether it's a distro/machine/sdk-machine layer or not. some layers require classes be inherited to opt-in, some require a .inc be sourced, etc Apr 08 17:57:35 That is still valuable, imo Apr 08 17:57:43 kergoth: This is not a "complete" solution. Apr 08 17:58:24 kergoth: Which is precisely why having a simple summary is important. Apr 08 18:03:20 key thing is not to duplicate information Apr 08 18:03:25 ageed Apr 08 18:03:29 find better ways to get the users to the existing information Apr 08 18:03:35 agreed even :) Apr 08 18:03:36 RP: +1 Apr 08 18:05:36 * RP is tempted to add things like "form conga line" to the agenda which likely wouldn't help Apr 08 18:05:46 you should Apr 08 18:05:59 RP: It would be an interesting experiment to see if we followed Apr 08 18:06:18 RP: +1 Apr 08 18:06:59 was that meta-poky? Apr 08 18:07:02 yes Apr 08 18:07:10 make oe-classic great again Apr 08 18:07:12 telepresence +1 Apr 08 18:13:34 https://lwn.net/SubscriberLink/682540/33a2fb539e823d5b/ Apr 08 18:13:44 well you could buy a Mazda 6 that said Ford Focus on it.. :) Apr 08 18:15:44 just like coke Apr 08 18:15:52 fray_oe: +1 Apr 08 18:17:10 (Or a Mazda 3 that says Ford Fiesta) ;) Apr 08 18:18:11 "The Yocto" Apr 08 18:18:21 (problem is the new Ford Focus is no longer a Mazda 6 chassis.. and they'e turned it into a PoS... but I digress) Apr 08 18:20:10 (I don't spend all day explaing make, autoconf, automake, etc to customers.. ;) So anyway) Apr 08 18:22:29 hello Apr 08 18:23:08 morning Apr 08 18:24:20 ...and there was much rejoicing... Apr 08 18:24:36 we were suggestion to Sean to create a panama corp to shelter our money.. ;) Apr 08 18:24:59 Previously I had problems with a vendor build which had a qemu task that failed since it needed libSDL. Now, I know a little bit about oe/yocto so I simply did $ bitbake qemu so that I could verify I had the right target prior to doing a bitbake -e qemu and lo and behold it built qemu. Apr 08 18:25:05 What's up with that? Apr 08 18:25:05 cayman islands Apr 08 18:25:28 only if we can do the next OE meeting there Apr 08 18:25:42 Jefro: +1 Apr 08 18:26:47 OEDCM -- OE Developer Caribean Meeting Apr 08 18:26:58 nvm, qemu builds, but its really qemu-native which has the libSDL error. Apr 08 18:27:12 davis: it was most likely their qemu-native, not qemu that failed, due to no libsdl headers on the host, whereas you may well have those headers. there are lines in local.conf they can comment out to disable sdl in qemu-native and avoid the need to install it on the host, or they can install it Apr 08 18:27:13 Barbados Apr 08 18:27:17 davis: :) Apr 08 18:27:27 fray_oe: +1 Apr 08 18:28:05 I'll be selfish and suggest Costa Rica Apr 08 18:28:13 yes, ,the last time I commented those out to work aroudn it. I was going to retry and build it to see if I could find where to get them to pull. Apr 08 18:30:28 moto-timo: That works too. Apr 08 18:30:52 Hilton Doubletree Resort in Puntarenas Apr 08 18:33:48 (in my knowledge, of not being a lawyer) I thought getting a 'TM' was as simple as putting 'TM' on your goods.. but you needed register it to enforce it.. which is the (R) mark.. which is why you want the (R) Apr 08 18:33:58 I think I missed it, but what was the final decision on the next step for collecting the dos & donts / best practices for layers? who's taking that on, so we know who to contact about it? Apr 08 18:34:16 kergoth: jan-simon takes point, with input Apr 08 18:34:22 and we should use the oe-arch ml for it Apr 08 18:34:22 okay, thanks Apr 08 18:34:23 s/punish/encourage/ Apr 08 18:34:24 yeah Apr 08 18:34:29 jan-simon is leda Apr 08 18:34:36 need to make sure he is on arch list Apr 08 18:34:48 Crofton: I'm subscribed to the arch list already Apr 08 18:34:55 great Apr 08 18:35:06 * Crofton adds a new nick/real name mapping Apr 08 18:35:11 k4ep here btw Apr 08 18:35:24 Crofton: va3gbw Apr 08 18:46:37 hmm, do normal packages have a deploy target? I wanted to append to do_deploy but nothing happened Apr 08 18:47:01 yes, but it's empty Apr 08 18:47:25 so I should not append but just overwrite it? Apr 08 18:47:52 correct Apr 08 18:48:15 thank you Apr 08 18:49:29 afaik do_deploy isn't a task by default, other than in the kernel. you may well need `addtask deploy after do_compile before do_build` or similar, and if you care about sstate, inherit deploy and install your files into DEPLOYDIR rather than DEPLOY_DIR_IMAGE Apr 08 18:49:42 I'd like to create some more explicit hooks in the metadata and avoid addtask'ing in recipes at all Apr 08 18:50:18 i.e. if do_deploy is defined, addtask it so it gets built Apr 08 18:50:27 whats the difference between DEPLOYDIR and DEPLOY_DIR_IMAGE? I actually wanted my stuff to go to DEPLOY_DIR_IMAGE Apr 08 18:51:10 Jin^eLD: if you want your deployed files to come back when building from sstate, then you need to inherit delpoy and install to DEPLOYDIR, and it will take care of putting the files from there to DEPLOY_DIR_IMAGE Apr 08 18:51:16 that way it can track what's coming out of the task, so it can archive it Apr 08 18:51:24 read deploy.bbclass for details Apr 08 18:51:28 flags are set to control sstate behavior Apr 08 18:52:14 oh ok.. thanks, reading up now Apr 08 18:52:21 lunch time (here) Apr 08 18:52:23 quiestion is which sized pint? Apr 08 18:52:36 Imperial #ftw Apr 08 18:52:37 Jin^eLD: np Apr 08 18:53:04 Crofton: proper sized or weenie US sized? ;-) Apr 08 18:55:27 I prefer UK vs US Apr 08 18:55:50 then again, maybe we need to just get German "boots" ;) Apr 08 19:03:55 fray_oe, when you fly out? Apr 08 20:09:29 FYI, we extended lunch utill 1330 as people are having several productive conversations at the lunch tables Apr 08 20:10:01 Sorry we can't get you all involved at that level Apr 08 20:10:12 Crofton: np Apr 08 20:10:16 I guess we need to make telepresence robots Apr 08 20:10:25 and seat them at the different tables Apr 08 20:10:48 Crofton: maybe someday we'll get there :) Apr 08 20:11:00 segway & a tablet.. Apr 08 20:32:11 looks like it's about time to resyaty themeeting.. Apr 08 20:32:19 (and learn how to type) Apr 08 20:52:41 per my earlier remark afte the hand size remark: Apr 08 20:52:43 http://www.paddypower.com/bet/politics/other-politics/us-politics?ev_oc_grp_ids=2288451 Apr 08 20:52:54 not for discussion Apr 08 20:55:18 :)) Apr 08 20:56:11 how are they going to... right, not for discussion :P Apr 08 20:57:09 Trolls: https://plus.google.com/+TrevorWoerner/posts/JecvVRsVd6Q Apr 08 20:59:15 topics Apr 08 20:59:17 ? Apr 08 21:01:01 looks like we're just restarting... finally.. Apr 08 21:01:03 Crofton: topical cream? Apr 08 21:02:10 is anohter back on and can you hear us? Apr 08 21:04:40 is "anyone" back on... ? Apr 08 21:04:42 yes, can hear you Apr 08 21:04:48 Paul and I are listening Apr 08 21:04:49 cool Apr 08 21:05:03 Belen/Tom are drowning everyone else out Apr 08 21:05:48 RP: I've moved the microphone Apr 08 21:06:03 belen: thanks! Apr 08 21:06:58 FYI Intel is already working on patchwork upgrade / CI testing Apr 08 21:07:10 as I've mentioned before Apr 08 21:07:17 bluelightning: that is the patchwork we are talking about Apr 08 21:07:52 ok... I couldn't tell since we would be starting with OE-Core Apr 08 21:08:09 Tom K wants to work w/ meta-oe.. Apr 08 21:08:15 so I think it's complementary Apr 08 21:08:26 that's fine, but I'd like us to be working with the same thing if at all possible Apr 08 21:08:44 same tools, I mean Apr 08 21:09:21 * bluelightning wishes we had something to show already Apr 08 21:10:30 bluelightning: I'll be working closely with Tom so we can keep in sync Apr 08 21:10:48 awesome... we should sync next week Apr 08 21:11:46 moto-timo: bluelightning +1 Apr 08 21:11:51 basically, we all need to do shit :) Apr 08 21:12:12 we almost have a set of scripts to pick up patches from patchwork, and do tests on them (both stylistic and funcitonal) Apr 08 21:12:48 basically it's running through our internal processes atm, should be able to publish it in a few weeks I hope Apr 08 21:14:02 One step at a time Apr 08 21:14:09 yep Apr 08 21:14:10 Lets start with really simple, then extend Apr 08 21:14:19 RP: +1 Apr 08 21:14:42 Even if it simply tells people the Upstream-Status tag in a patch is missing, that is a win Apr 08 21:17:43 * RP thinks people are overcomplicating this. Start simple. Apr 08 21:17:56 RP: for sure Apr 08 21:18:27 in case people are thinking I'm making some kind of new announcement about what I've been working on, we talked about it on the openembedded-architecture list in Nov/Dec Apr 08 21:18:45 * fray_oe nods.. meta-openembedded (and related) is the place to start from the OE side.. oe-core (and related YP poky bits) are rthe right place for the YP.. Apr 08 21:18:49 MHO at least Apr 08 21:21:40 https://wiki.yoctoproject.org/wiki/Security Apr 08 21:22:05 can open bugs for security issues in OE-Core ? Apr 08 21:23:24 RP: not as far as I know. it isn't clear Apr 08 21:23:26 I do want to highlight there has been a lot more work on security fixes recently... Armin has been a big part of that so +1 armpit Apr 08 21:23:31 security list: https://lists.yoctoproject.org/listinfo/yocto-security Apr 08 21:23:54 yes, armpit has been doing great work. I'd echo the lack of resources problem Apr 08 21:25:14 darknighte: We don't have the resources to split these resources into two Apr 08 21:25:41 RP: then don't. have the same resources do what we aleady have to do, subscribe to both lists Apr 08 21:30:40 guys, how would I specify "all files on root level but do not recurse into subdirectories" in a FILES_${PN}-specialpackage ? Apr 08 21:31:06 fray_oe: but do we need some sort of CVE tracking interface? Apr 08 21:31:27 rather than a mailing list, should it be a searchable web interface? Apr 08 21:32:30 longer term yes we do.. but I think the commit hook is the first step at this Apr 08 21:32:55 hmm, another web project... Apr 08 21:33:25 fray_oe, +1 Apr 08 21:33:56 bluelightning: could we create a patchwork tag to filter cve patches instead of doing a separate thing? Apr 08 21:34:45 belen: we could but ultimately I'd like something that has one page for a particular CVE and then it says which branches the fix is in / not in (or which are unaffected in the first place) Apr 08 21:35:07 **not** the layer index Apr 08 21:35:45 i.e. one place to go to to find out "am I vulnerable" Apr 08 21:35:59 bluelightning: +1 Apr 08 21:37:18 as it happens I'm working on a web app right now... maybe sometime soon I'll have a look at creating a CVE tracking app Apr 08 21:38:23 no promises ;) Apr 08 21:38:38 vulnerability is really determined (programatically) by version (referenced in the CVE or similar) and the commits.. Apr 08 21:38:46 another tool … Soon we'll need a tool to track our tools Apr 08 21:38:58 i.e. if the version is tagged as affected, AND we have a commit w/ the CVE tag in it.. it's programatically determined to be fixed.. Apr 08 21:39:01 otherwise it's "open" Apr 08 21:39:06 :D Apr 08 21:39:13 bluelightning: :P Apr 08 21:39:30 * bluelightning still needs to get his rep on stackoverflow Apr 08 21:39:39 "open" does not mean vulnerable though.. in a manual process (web page?) having a select set of people be able to tag things as non-vulnerable or vulnerable (no patch) is really important.. Apr 08 21:39:42 * moto-timo needs to setup an account Apr 08 21:39:53 its not that hard Apr 08 21:40:13 that's good to hear Apr 08 21:40:48 I do have it set up to email me on "oe" "yocto" and "bitbake" questions at least, so I get those Apr 08 21:42:06 bluelightning: I'd use "openembedded" instead of "oe" assuming you didn't already mean that Apr 08 21:43:02 right yes I think I did set up openembedded as the keyword Apr 08 21:43:21 yes I did Apr 08 21:44:12 belen: I knew you'd point that out and you're right... Apr 08 21:46:06 the question is if we were to build it into something else what would that be? Apr 08 21:46:20 I'm not sure it really fits anywhere Apr 08 21:46:31 we should share user accounts though Apr 08 21:46:43 no sense duplicating those Apr 08 21:48:12 temp in the room is about 78F Apr 08 21:48:14 'er.. 68F Apr 08 21:48:41 * RP would love to do mentoring but has no time :( Apr 08 21:48:46 same Apr 08 21:49:47 fray_oe: 20 C ? Apr 08 21:49:47 apparently the WWE is meeting next door Apr 08 21:49:56 fray_oe: above us, I think Apr 08 21:50:01 about that yes Apr 08 21:54:18 Most of the bugzilla bugs are related to OE-Core Apr 08 21:55:40 There are two different meetings getting confused Apr 08 21:55:52 There is a Technical Meeting, there is also a bug triage meeting Apr 08 21:55:53 https://wiki.yoctoproject.org/wiki/Bug_Triage Apr 08 21:55:55 RP: that was what iwas trying to point out Apr 08 21:57:35 fray, I was wondering Apr 08 21:57:41 Its not "Yocto" specific, its how we're trying to keep control of OE-Core quality Apr 08 21:57:50 RP: +1 Apr 08 21:57:56 yes.. it's a triage forcing function to make sure bugs are not ignored Apr 08 21:57:56 +1 Apr 08 21:58:18 I would love to have more people helping out trying to fix them rather than the same old people :/ Apr 08 22:01:32 RP: +1 Apr 08 22:02:01 I am guilty of not making that a priority myself and keep promising myself that I will change that Apr 08 22:31:44 I guess things are done then... Apr 08 22:33:49 Jin^eLD: i don't think you can do that directly with the globbing supported by FILES, you'd have to put i.e. /usr/foo/*/ in a package before ${PN} Apr 08 22:33:57 -specialpackage, and then /usr/foo/* in that one Apr 08 22:35:02 kergoth: hmm ok let me try.. Apr 08 22:36:18 actually i was doing PACKAGES_append_mymchine Apr 08 22:36:31 so that "glob everyting" would come last Apr 08 22:36:48 somehow it did not work out Apr 08 22:37:10 would just need to make sure the subdirs are picked up by an earlier package Apr 08 22:37:51 I did not overwrite the automaticall set FILES Apr 08 22:38:00 so it should have.. hm Apr 08 22:38:42 let me retry Apr 08 22:42:04 hmmm Apr 08 22:42:13 it works, so i messed up earlier Apr 08 22:42:31 because I was actuall aware of the ordering but could not get it to work Apr 08 22:43:36 probably got += =+ wrong and did not retry the proper glob setting after i switched to PACKAGES_append_machine Apr 08 22:43:44 thanks Apr 08 22:45:23 ah :) np Apr 08 22:49:31 * RP just ripped the shell parsing to pieces only to realise the extra dependency was from the data store code :/ Apr 08 22:49:37 clearly should get some sleep Apr 08 22:58:03 url of the hangout ? Apr 08 23:03:29 nite Apr 08 23:25:01 "A Yottabyte isn't that big" -- fray Apr 08 23:25:21 fray: Will you buy me a yotta Byte drive array? Apr 08 23:25:54 afterall, it's not that big right? ;) Apr 08 23:28:27 lol ... check out this git tag: Apr 08 23:28:28 * [new tag] poky-10.0.1.final -> poky-10.0.1.final Apr 08 23:28:29 * [new tag] yocot-1.4.2 -> yocot-1.4.2 Apr 08 23:28:29 * [new tag] yocto-1.4.1 -> yocto-1.4.1 **** ENDING LOGGING AT Sat Apr 09 02:59:58 2016