**** BEGIN LOGGING AT Fri Nov 04 02:59:57 2011 Nov 04 08:09:54 morning all Nov 04 08:13:08 good morning Nov 04 14:10:36 am i blind or is http://www.yoctoproject.org/community/participating-organizations missing Getting Started link? Nov 04 14:41:06 MadSpark, look here: http://www.yoctoproject.org/documentation Nov 04 14:41:23 you're in participating organizations not in documentation Nov 04 14:59:05 GNUtoo, i know but the page i linked states: If you would like to join the Yocto Project, click below on the Getting Started link. Nov 04 15:00:23 so i'm not looking for documentation but way how my organization could join to support the project Nov 04 15:04:23 MadSpark: ok looks like the website has a missing link there; in the mean time, it's probably best to contact either Jeff Osier-Mixon (jefro) or David Stewart (davest) Nov 04 15:10:41 bluelightning, thanks! i will do that Nov 04 15:50:05 otavio: ping Nov 04 16:03:00 bluelightning: hi Nov 04 16:03:19 hi otavio, was my patchset OK? Nov 04 16:03:49 AFAICT reading the documentation it should be doing the right thing for merge commits **** ENDING LOGGING AT Fri Nov 04 16:14:09 2011 **** BEGIN LOGGING AT Fri Nov 04 16:18:15 2011 Nov 04 16:18:25 bluelightning: do you have the link? Nov 04 16:24:24 otavio: I can't access OE cgit atm :/ Nov 04 16:24:48 I think OSUOSL may be suffering from network issues Nov 04 16:26:50 could use the github mirror unless its not there yet Nov 04 16:26:51 heh Nov 04 16:26:57 hrm Nov 04 16:40:51 otavio: ok its still unreachable; in the meantime : http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/combo-layer-fixes2 Nov 04 16:41:02 (it's on top of oe-core, despite being in the poky-contrib repo) Nov 04 16:50:48 bluelightning: I don't think untracked files ought to mark the repo as dirty Nov 04 16:51:25 otavio: why not? Nov 04 16:52:04 they are uncommitted changes that could cause both differences in build output and conflicts in future updates Nov 04 16:52:08 bluelightning: well; most people will have the build stuff on same dir as the repo (I do) Nov 04 16:52:14 bluelightning: uncommited I agree Nov 04 16:52:17 bluelightning: untracked no Nov 04 16:52:25 in which case, that ought to be in your .gitignore, surely... Nov 04 16:52:42 bluelightning: not sure Nov 04 16:53:08 there are a few "build*/..." entries in the oe-core one FWIW Nov 04 16:53:43 if you never intend to commit something but it should stay, that's a textbook case for adding it to the ignore file Nov 04 16:56:51 bluelightning: I am not sure this ought to be forced onto the user Nov 04 16:56:56 bluelightning: but i see your point **** ENDING LOGGING AT Fri Nov 04 17:02:03 2011 **** BEGIN LOGGING AT Fri Nov 04 17:03:22 2011 Nov 04 17:14:41 RP__: did you have any thoughts on the Simplify PythonParser patches I posted? **** ENDING LOGGING AT Fri Nov 04 17:15:12 2011 **** BEGIN LOGGING AT Fri Nov 04 17:24:15 2011 Nov 04 17:25:57 I also have https://github.com/kergoth/bitbake/commit/39e883d which hasn't been posted to email yet. Nov 04 17:26:38 oh, and https://github.com/kergoth/bitbake/commit/21a71b2, but that's less potentially controversial, just an obvious improvement Nov 04 17:30:09 kergoth: both look reasonable to me Nov 04 17:30:24 k Nov 04 17:30:47 that code had irked me a bit ever since i wrote it, got tired of it Nov 04 17:30:48 heh Nov 04 17:32:23 kergoth: I know the feeling, there are several things I keep wanting to get back to and do properly Nov 04 17:34:03 I really want to sit down and make these non-literal messages shut up if vardeps exists for the var in question Nov 04 17:34:06 one of these days Nov 04 17:35:15 kergoth: That would indeed be nice. We still need to audit those messages too Nov 04 17:35:36 kergoth: and also get things like the checksums included in the dependencies Nov 04 17:35:49 checksums for local file:// urls would be a bonus too Nov 04 17:37:24 that would be nice indeed Nov 04 17:51:30 otavio: so is everything else OK? Nov 04 17:52:05 RP__: I am thinking in move dhcp-server config to dhcp-server-config package so this can be overriden if need without having to enforce it to be machine specific Nov 04 17:52:10 bluelightning: seems all OK Nov 04 17:52:29 RP__: what do you think? Nov 04 17:52:56 RP__: dhcp-server ought to recommends dhcp-server-config so it works for people using it already Nov 04 17:53:13 RP__: but allow for use of bad recommends to overwrite it Nov 04 17:53:40 * RP__ thinks we need to come up with better ways of device specific configuration Nov 04 17:54:27 RP__: right but in meanwhile this seems acceptable? Nov 04 17:56:41 otavio: I guess :( Nov 04 17:57:16 I just sometimes with people would try and fix the underlying problems rather than hack around them Nov 04 17:57:39 RP__: I can't think any other solution for this problem Nov 04 17:57:56 RP__: we ought to have a default setup but allow for easy replacement to be done Nov 04 17:58:05 RP__: so splitting it seems the most logical fix Nov 04 17:58:27 otavio: Something like a package which specifically customised configuration on target Nov 04 17:58:52 since in this case the configuration is extremely end-user specific Nov 04 17:59:08 * RP__ -> afk Nov 04 17:59:43 RP__: didn't understand you know Nov 04 18:00:10 RP__: this is not a machine-dependent thing but most probably a image thing Nov 04 18:00:31 RP__: so allowing different packages to have it allows for better flexibility IMO Nov 04 18:02:19 bluelightning: one thing that might be improved Nov 04 18:02:28 if its image specific, the split doesn't help you much Nov 04 18:02:45 bluelightning: do the commit with the regular git user information so we know who has did the sync Nov 04 18:02:57 RP__: why? Nov 04 18:03:01 if you have a postinstall time configuration on the other hand, that can make decisions based on the specific image being generated Nov 04 18:03:06 otavio: the committer will still be the user, just not the author Nov 04 18:03:15 and I really do have to go, sorry :( Nov 04 18:05:04 bluelightning: but the user using it is the author after all Nov 04 18:05:21 bluelightning: i'd prefer to not overwrite it Nov 04 18:05:39 bluelightning: but the commit might be prepended with combo-layer: ... Nov 04 18:06:45 otavio: well, perhaps we can make it configurable Nov 04 18:06:51 bluelightning: ok Nov 04 18:06:55 bluelightning: works for me Nov 04 18:20:25 RP__: sent those changes and few other fixes Nov 04 19:02:51 RP__: http://github.com/kergoth/bitbake/commit/13e4f9f Nov 04 19:03:35 only concern is memory usage by allocating a new logger per parser instance, but I doubt it's bad Nov 04 19:03:52 figured it was cleaner shifting the buffering into the logger rather than hacking it into the parser classes Nov 04 19:05:59 could potentially make the non-literal messages an actual WARNING with that commit in, would force us to set more vardeps to shut it up Nov 04 19:06:02 jej **** ENDING LOGGING AT Sat Nov 05 02:59:57 2011