**** BEGIN LOGGING AT Tue Jul 30 02:59:58 2013 Jul 30 07:58:14 morning all Jul 30 08:01:07 hi morning bluelightning Jul 30 08:01:11 morning #oe Jul 30 08:02:43 morning silviof Jul 30 08:10:54 I work on firefox-22 and have a license file with more than 10 licenses. How should I handle these? Jul 30 08:12:55 silviof: if those are all of the licenses that apply they'll all need to be listed in LICENSE separated by & Jul 30 08:13:48 bluelightning: okay Jul 30 08:20:59 morning all, hi bluelightning, hi silviof Jul 30 08:21:39 hi silvio_ Jul 30 08:23:00 hi silvio_ Jul 30 09:27:01 hi all Jul 30 09:27:39 hi eren Jul 30 09:33:55 hi eren Jul 30 09:40:15 morning all Jul 30 09:41:05 morning pb_ Jul 30 09:42:14 hi pb_ Jul 30 09:44:16 hi eren, bluelightning Jul 30 09:44:58 good (late) morning Jul 30 10:09:49 pb_: I can imagine our rburton and bluelightning dazzled by the huge patchset Jul 30 10:11:13 ant_work: re the bluez thing, you mean? Jul 30 10:12:58 not specifically, this time seems harder than usual Jul 30 10:13:33 I'm lost on read-only-rootfs suppot Jul 30 10:13:38 will there be any documentation about it? Jul 30 10:13:50 it does seem as though Saul is having a bit of a hard time putting the right bits in his branch for some reason. Jul 30 10:14:01 I mean, in the technical side, how it is implemented, how it can be used, etc Jul 30 10:14:11 but, well, rburton and bluelightning are professionals, I'm sure they can cope. Jul 30 10:14:26 and we can help them :P Jul 30 10:14:44 eren: "how it can be used" is easy, it is for root filesystems that you can't write to (squashfs etc) Jul 30 10:15:03 it should just be a case of setting the appropriate IMAGE_FEATURE when you generate your rootfs. Jul 30 10:15:06 sure, I am wondering about the implementation actually Jul 30 10:15:16 it's hard to deduce from the commits Jul 30 10:16:38 well, there are various parts to it, but the basic idea is that any parts of the filesystem that need to be written to have a tmpfs bind-mounted on top of them. Jul 30 10:16:58 I'm not quite sure whether there is any plan to unify this with the unionfs stuff that's used for live images, or whether they will always remain separate. Jul 30 10:17:18 you can imagine that live images are, in some sense, just a special case of RoRs and possibly ought to be using the same mechanics. Jul 30 10:17:51 eren: I have tested one RO cramfs couple of months ago Jul 30 10:18:15 see, the NOR is locked and it was indeed RO ;) Jul 30 10:18:30 eren: it was just a core-image-base Jul 30 10:18:39 pb_: well, tmpfs bind-mounted on top of them? Jul 30 10:19:13 eren: wrt volatiles/tmpfs seems things have changed/are changing Jul 30 10:40:28 ro nfs rootfs are really nasty to handle in userspace because the 'ro' flag is not exported by statvfs(). So systemd's ConditionPathIsReadWrite does not work and (unpatched) busybox 'test -w' fails too :( Jul 30 14:59:40 any ideas on why my kernel has its load address set differently when built through OE and manually using the OE built toolchain? Jul 30 15:00:23 when building out of oe I get Load Address: 0x80008000, while in oe I get 0x00008000, which is strange Jul 30 15:01:38 same defconfig, same commit and no u-boot-mkimage relocation stuff Jul 30 15:03:03 bluelightning: is it time for TSC / Workgroup meeting? Jul 30 15:05:12 mckoan: it's in 1 hour Jul 30 15:05:19 mckoan: (well, 55 minutes) Jul 30 15:05:20 +1 Jul 30 15:05:27 so 18:00 CEST Jul 30 15:05:27 bluelightning, the bot should be good to go Jul 30 15:05:55 Crofton|work: great, I guess you'll be around to operate it? (since I don't know how...) Jul 30 15:06:06 ok Jul 30 15:06:08 I should be Jul 30 15:06:08 bluelightning: but in London now it's 16 (GMT) Jul 30 15:06:11 s/guess/hope/ :) Jul 30 15:06:28 I got home late last night Jul 30 15:06:30 mckoan: London is in BST now not GMT :) Jul 30 15:06:51 bluelightning: aha! now I understand, sorry Jul 30 15:07:57 http://www.worldtimebuddy.com/utc-to-bst-converter Jul 30 15:36:06 martiert: I guess you should diff the linker scripts and the final link command line to see what's going on. Jul 30 15:42:45 pb_: Which linker scripts are you thinking of? the ones in the kernel, or someone in oe? Jul 30 15:43:31 The ones in the kernel Jul 30 15:44:49 yes, I can do that. Do you know if there are anyting in oe which is changing the way it's linked though? cause I though we were doing unset CFLAGS CXXFLAGS LDFLAGS when building the kernel Jul 30 15:47:03 I can't think of anything. But if it behaves differently, and you're using the same tools, then it stands to reason that there must be something. Jul 30 15:47:25 true, but I'll try that, and see if the link line is weird Jul 30 15:47:47 thansk Jul 30 15:49:11 just thought it was so weird, so maybe someone had seen something similar. being that the only difference is the first 8, which is a lot of bytes, but still only one number:P Jul 30 15:55:40 hey all, just a reminder: in about 5 minutes we'll be starting the public TSC meeting in this channel Jul 30 15:56:55 http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg32103.html Jul 30 16:00:47 morning Jefro Jul 30 16:00:54 morning Jul 30 16:01:17 bluelightning good morning Jul 30 16:01:38 seems quiet here. too quiet... Jul 30 16:01:51 Morning Jul 30 16:02:07 morning all Jul 30 16:02:58 bluelightning, let me know when you want to start Jul 30 16:03:02 Jefro: probably a little bit late for me to be asking but do you have an agenda for this meeting? Jul 30 16:03:16 Crofton|work: we should be starting now Jul 30 16:03:30 shall I start the bot then? Jul 30 16:03:49 Crofton|work: yes please Jul 30 16:03:51 #startmeeting Jul 30 16:03:52 Meeting started Tue Jul 30 16:03:52 2013 UTC. The chair is Crofton|work. Information about MeetBot at http://wiki.debian.org/MeetBot. Jul 30 16:03:52 Useful Commands: #action #agreed #help #info #idea #link #topic. Jul 30 16:04:01 the url has some docs Jul 30 16:04:19 you can use the topic command for agenda items Jul 30 16:04:41 bluelightning yes, in just a sec - poll for new issues and I'll put them on the agenda before posting Jul 30 16:04:54 Welcome.. Jefro is our normal TSC note taker.. he is just finishing up the base agenda items now.. Jul 30 16:04:56 give me an action item to work with ka6sox to find a way to upload minutes to the oe website Jul 30 16:05:01 but while he does so, new issues are welcome.. Jul 30 16:05:46 our normal first task is to identify the meeting chair.. So we should probably do that quickly.. Jul 30 16:06:16 koen msg'd me a couple of minutes ago that he'd be right back.. Jul 30 16:06:46 I believe Khem, Bluelightning and myself are here. Jul 30 16:06:55 RP is on vacation Jul 30 16:08:03 while the others get setup. Let me explain what we're trying to do today. Jul 30 16:08:08 http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg32103.html Jul 30 16:08:38 As mentioned in the email from Paul (on behalf of the entire Technical Steering Committee) we want to work on evoling the role of the OE-TSC. Jul 30 16:09:12 We thought that starting to have at open meetings with the users (not just oe members) would be a good start. Jul 30 16:10:25 fray: I agree, but depends on how much users care about meetings ;-) Jul 30 16:10:29 the idea is to get other folks in the community more involved in the "taskforce" type operations that the TSC have been taking on Jul 30 16:11:01 and that is one of the purposes of this meeting as well. Many people aren't going to care. So if after we're done it wasn't useful. We likely won't do it again.. (or at least not in this format) Jul 30 16:11:29 I feel this is a good habit to get into, and expect people to become more involved over time Jul 30 16:11:55 * darknighte is monitoring the meeting Jul 30 16:12:03 The TSC needs to change it's role from being a group of people leading specific implementation/work products into an actual technical steering committee who can help the community at large... Jul 30 16:13:18 fray: so we're 13 mins in, I'd say you're probably chairing ;) Jul 30 16:13:28 sounds good to me. :) Jul 30 16:13:46 We normally just allow someone to take the lead as the chair of the meeting.. so I guess it's my turn Jul 30 16:14:07 re Jul 30 16:14:07 while Jefro finishes up on the formal agenda. The first item in the list was to introduce some of the 'janitor' items. Jul 30 16:14:38 For a while the TSC has been seeing a list of items grow (and luckily shrink) that cover various cleanup and janitorial tasks. Jul 30 16:14:58 We're like to introduce a more formal way for people to find outstanding cleanup tasks and be able to work on them. Jul 30 16:15:02 fray, say #topic Janitor Items Jul 30 16:15:05 TSC agenda is here: http://pastebin.com/KMhtNHpC Jul 30 16:15:23 #topic Janitor items Jul 30 16:15:49 On the pasted agenda, there are two links referenced: Jul 30 16:15:54 http://openembedded.org/index.php/OpenEmbeddedJanitors Jul 30 16:16:10 that page is kind of ancient ;) Jul 30 16:16:19 a wiki page started to help people idenfiy and discuss Janitorial work.. so far it's not been used much, but it also isn't well know.. Jul 30 16:16:24 and yes.. ancient in many ways.. Jul 30 16:16:52 and for those that pay attention to the Yocto Project bugzilla, various bugs get tagged with an owner, cc that contains 'janitor' to help identify future work. Jul 30 16:16:57 http://bit.ly/11sfn5Y Jul 30 16:17:16 right, the Yocto Project has also been tracking janitor items: https://wiki.yoctoproject.org/wiki/Janitors Jul 30 16:17:24 bluelightning thanks, I missed that URL Jul 30 16:17:56 I'll be honest though, that list has remained largely static for quite some time, so it's not really achieving much Jul 30 16:18:22 as a newly joined contributer, I want to make a comment on Janitor jobs Jul 30 16:18:27 is it possible? Jul 30 16:18:28 i.e. usually "janitor" type items are a way of bringing new contributors up-to-speed on a project, but that hasn't really been happening Jul 30 16:18:35 eren: certainly :) Jul 30 16:18:37 eren, please.. Jul 30 16:18:52 I didn't know about the url on OpenEmbedded wiki, which are more likely to be janitor jobs Jul 30 16:19:09 the jobs in Yocto page are a bit complex for newly joined people Jul 30 16:19:29 the first item on the OE page is no longer valid, I'm about to remove it Jul 30 16:19:32 I would suggest chosing some mechanical jobs at first and collect them on wiki Jul 30 16:19:49 eren, I was assigned the task to start working on publicising janitorial tasks, but alas, the implementation side of my work has gotten in the way.. Jul 30 16:19:50 and add a link to how to contribute/send patches to ML :) Jul 30 16:20:22 So this is really the first opportunity for most people to see what we thing is a good way to get people involved and help those looking for something to do, with a possible list. Jul 30 16:20:46 we also want ot make sure that if people find inconsistencies, things that need cleanup -- there is a way for them to post about them and add it to the list of future work Jul 30 16:21:07 eren, I agree.. Jul 30 16:21:15 there was a page on how to send patches that bluelightning posted when I asked Jul 30 16:21:17 we'll add that to the todo Jul 30 16:21:20 but I cannot find it on wiki Jul 30 16:21:23 eren: right, we should definitely do that, good idea... FYI this page is up-to-date: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Jul 30 16:21:33 I guess adding keywords would help Jul 30 16:21:43 bluelightning: ah! that's on OE then, I was looking at Yocto wiki Jul 30 16:22:12 we should probably have back-links from the Yocto Project wiki to that page Jul 30 16:22:38 yeah, I guess so Jul 30 16:22:42 and yes, mediawiki often requires explicit keywords because its searching is somewhat simplistic Jul 30 16:22:45 I didn't know janitor wiki page too Jul 30 16:22:45 this leads me to one of the janitor tasks that is sorely needed. We need help keeping the wiki up to date, along with making it easier for new users to find what they need.. Jul 30 16:23:01 indeed Jul 30 16:23:05 +1 Jul 30 16:23:17 there is still a lot of oe-classic information that we need to ensure people understand is older.. Jul 30 16:23:41 FWIW most of the outdated info is at least marked as such with a bold notice at the top of the page Jul 30 16:23:42 keep doc stuff up to date is definitely the first thing to do Jul 30 16:23:48 but that's only step one of course :) Jul 30 16:23:48 yup Jul 30 16:24:18 #action Crofton_work talk with ka6sox about uplaoding to the website Jul 30 16:24:28 you can add old oe variables that we need to be careful about in Styleguide? Jul 30 16:24:31 or packaging guide? Jul 30 16:25:19 #action update janitor page with up-to-date information, make sure it's referenced on the main page Jul 30 16:25:50 Jefro: what exactly do you mean? do you mean loosening restrictions on wiki? Jul 30 16:26:08 eren: hmm... we do maintain this, not sure if it helps in that regard: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core Jul 30 16:26:26 eren: we also have a migration section in the YP reference manual for releases Jul 30 16:26:46 eren: that at least covers changes people need to make to their recipes/configuration Jul 30 16:27:20 * fray looks at the clock.. is there more discussion on this or should we move on Jul 30 16:27:28 bluelightning: ah yep, that would definitely help Jul 30 16:27:28 denix, getting things setup so I can rsync the minutes directly yo a server Jul 30 16:27:50 Crofton|work: got it Jul 30 16:28:13 fray: I think we should probably move on, but we should carry on thinking/working on the janitor list Jul 30 16:28:35 yes please.. anyone has any suggestions contact the TSC and/or post on the oe list(s).. Jul 30 16:28:58 I would think that all of the oe items, wiki, oe-core, meta-oe could likely use something like this.. or even a common page divided by area.. Jul 30 16:29:03 ok.. on to the next thing.. Jul 30 16:29:18 3a.. role of the TSC.. we already covered this a bit, and some may have seen the discussion on the oe-members list. Jul 30 16:29:32 fray, use #topic :) Jul 30 16:30:03 #topic 3a.. role of the TSC Jul 30 16:30:33 We want to work on transitioning from a group trying to figure out what is needed and working on getting us there.. to thinking about strategic direction and long term vision. Jul 30 16:30:42 * Jefro wonders how he didn't know about meetbot before Jul 30 16:31:01 We're looking from feedback from both oe users and members on our role. Jul 30 16:31:40 Jefro: you were the bot! :) Jul 30 16:31:55 just to be clear our own plans for the TSC do not include meeting just for the sake of it. We do want to actually accomplish something. Jul 30 16:32:08 +1 Jul 30 16:32:09 feedback? Jul 30 16:32:10 Jefro: we didn't have you at the board meetings, so we needed to find something... :) Jul 30 16:32:53 otavio, made me figure it out :) Jul 30 16:32:59 fray: of course, but people not used to meet with TSC may need time to adapt to it Jul 30 16:34:45 mckoan: right, this may take some time for us all to get used to :) Jul 30 16:34:52 ;) Jul 30 16:35:40 I think many, if not all of the TSC members in the last couple of years had a vested interest in bootstrapping oe-core.. We are well beyond that point now.. so in my opinion, it's time for the group to evolve.. Jul 30 16:36:32 since I don't see much feedback, I'll ask this in another way.. does anyone -disagree- with the TSC changing it's role more toward a medium vision/long term vision, and technical dispute resolution group.. Jul 30 16:36:42 (we also help with some infrastructure decisions and issues as well..) Jul 30 16:37:18 token statement to show some form of participation: no, i don't disagree with that. :) Jul 30 16:37:20 I'm 100% in favor of strategic direction and long term vision being a focus Jul 30 16:37:39 fray I had a question. The TSC also manages many technical projects. What happens to those? Jul 30 16:37:54 That was my next question.. :) Jul 30 16:38:45 what are these technical projects? Jul 30 16:39:39 in the past we've done some of the janitorial tasks, helped with the merge of code from meta-oe to oe-core... Jul 30 16:40:19 we had mentioned in past meetings that this type of work transition to more of a working group format. Which we may or may not be directly involved with... but which we -will- need community involvement Jul 30 16:40:47 from a user perspective (not being in the tsc in some time), one thing that's bugged me about how the tsc has been working is the fact that agenda items seem to stick around indefinitely without seeing any form of completion. maybe its mostly those projects, but it gives one an impression ofa lack of progress, reading the notes, imo Jul 30 16:41:23 in many cases, that is exactly it.. the items were on-going "projects" Jul 30 16:42:14 kergoth that may be partly my bug presentation-wise Jul 30 16:42:42 discussion points != projects. I can present it more as a project manager would if that helps. Jul 30 16:42:56 kergoth: this is one of the reasons for us asking for wider involvement in those projects, since some of them have been difficult for us to make progress on on our own; usually it's not for lack of decisions, but lack of time to work through changes Jul 30 16:44:19 discussion points are often too synthetic Jul 30 16:45:03 who read them from outside of TSC oftern don't realize their actual purpose Jul 30 16:45:27 maybe a little lack of description/documentation Jul 30 16:45:44 for instance, we've been struggling with trying to get the last few bbappends/overlayed recipes from meta-oe for some time now, and it's been *really* hard to get people to help with that Jul 30 16:45:47 yes.. and I think vision fits into a better way of doing what we have been (from the outside) while a working group would be better for actual 'work' and involvement Jul 30 16:46:44 I'll admit that that particular thing is something I personally feel strongly about, perhaps it bothers others less Jul 30 16:49:13 (sorry my network is glitching here...) Jul 30 16:49:29 Is there an output of this discussion, at this point? Jul 30 16:50:26 the main problem with adopt these big changes is that there usually aren't guidelines, apart for those wrote by bluelightning (afaik) Jul 30 16:50:41 we need to better convey the points as to their meaning, tsc role change is generally accepted, working groups (right approach, wrong or TBD?) Jul 30 16:50:50 fray: we haven't stated as such, but if there are items that the TSC would normally take on, we need to get them identified and find a way of pulling in interested folks to get them resolved Jul 30 16:51:01 agreed Jul 30 16:51:08 fray: TBD probably Jul 30 16:51:13 ok.. Jul 30 16:51:17 working groups seem like a decent approach to pursue the actual implementation of the decisions Jul 30 16:51:18 list conclusions as #info or #action Jul 30 16:51:19 we've got about 9 minutes left.. Jul 30 16:51:20 * kergoth shrugs Jul 30 16:51:38 I'd like to continue and we can come back to this if there is time.. Jul 30 16:51:44 #topic 3b - eglibc Jul 30 16:51:54 This is more of an FYI topic to folks.. it's working that we need to continue to track. Jul 30 16:52:15 If you are not already aware, the eglibc work is being merged into the glibc proper. Jul 30 16:52:16 http://www.eglibc.org/archives/patches/msg01299.html Jul 30 16:52:30 this topic is freightening me, someone could give more information? Jul 30 16:52:42 This may affect us via the configuration of eglibc, mklibs phase out, etc.. Jul 30 16:52:46 why is this migration required? Jul 30 16:53:01 IF these items are needed by people, they will need to get involved with the upstream eglibc project.. express what they need and likely help maintain the work Jul 30 16:53:10 well nothing to worry about mckoan Jul 30 16:53:12 The migration is happening by the current maintainers of the eglibc project. Jul 30 16:53:25 mckoan: mostly because the original need for eglibc has basically evaporated, and maintaining two competing forks of the same code is a waste of time. Jul 30 16:53:26 All of the code that can be, is going to be merged into glibc itself.. Jul 30 16:53:28 we use certain features in OE which are less used Jul 30 16:53:30 pb_ exactly Jul 30 16:53:36 pb_: Ulrich? Jul 30 16:53:41 and therefore we either pick up maintaining them or they go away Jul 30 16:53:47 Ulrich is no longer the maintainer of glibc AFAIK Jul 30 16:53:52 khem: I'm not completely clear, will this mean the items in DISTRO_FEATURES_LIBC cease to exist, or are reduced, or no change there? Jul 30 16:54:02 I guess that was *one of* the reasons behind eglibc fork Jul 30 16:54:10 fray: link catched thx, I'll read it later Jul 30 16:54:14 bluelightning: I will upstream the patches into glibc Jul 30 16:54:22 and maintain them ther e Jul 30 16:54:34 bluelightning at present, the items in the distro_features_libc, which correspond to their 'option group' support will be affected without someone coming in to maintain the work Jul 30 16:54:37 eren: Ulrich is gone long time ago Jul 30 16:54:53 however it would be better to have some sense of userbase Jul 30 16:54:55 khem: excellent, thank you... so the impact on us should be relatively minor then? Jul 30 16:54:57 Option groups, in eglibc, are the way to disable functionality in order to save space. (Very much like how uclibc is configurable) Jul 30 16:55:08 if there are few use cases then it may not be worth the time Jul 30 16:55:29 bluelightning: yes impact to us is minor given we have prevelant usecases Jul 30 16:55:39 however this is an item for 2.19 release Jul 30 16:55:45 it's unclear at present how many people actual use the option groups, (our LIBC configuration). Based on previous responses to queries the numbers are small enough that the eglibc maintainers will be deprecating support over the next release or so.. (think 6-12 months) Jul 30 16:56:19 eren: fray_ : AFAIK, Ulrich's departure is part of what has opened the door to the merging of eglibc/glibc. Jul 30 16:56:24 we're trying to make sure this doesn't come as a surprise to anyone.. and if the functionality is absolutely needed, we (the OE project) will need to either take over maintenance and/or take the patches outselves.. Jul 30 16:56:26 darknighte correct Jul 30 16:56:28 fray_: yes if userbase is smaller then merging this into glibc might not be as appealing Jul 30 16:57:04 I think most impacted distro in OE universe would be poky tiny Jul 30 16:57:14 concerns/comments.. we should move to the oe-core list on this.... Jul 30 16:57:27 right, it was raised there but there wasn't a lot of discussion IIRC Jul 30 16:57:32 khem, thats the one I know of at least.. my commercial distro may be affected as well.. Jul 30 16:57:44 fray_: I see. Jul 30 16:57:59 the hardest part in this is gauging usage.. if nobody cares then removing the functionality really shouldn't matter.. Jul 30 16:58:10 I will initiate an email thread on oe-core/oe-devel and seek feedback on this feature Jul 30 16:58:13 but we need to avoid removing it, and then having a huge backlash.. Jul 30 16:58:15 It's fairly hard to see why anybody would rationally care. Jul 30 16:58:42 pb_ there still are some memory constrained systems, but that is becoming significantly less 'normal' then it was evern 2 years ago Jul 30 16:58:43 pb_: there's always someone with their special case. Jul 30 16:58:43 I was hoping for response from Darren since he dug into this in excruciating detail during his work on poky-tiny Jul 30 16:58:44 pb_: hard to say, I dont know what everybody uses Jul 30 16:58:50 I can imagine there are people using that feature due to inertia or "because it's there", but I find it fairly hard to believe there are many (perhaps even any) users whose lives would be seriously spoiled by not having it. Jul 30 16:59:01 dvhart ^ Jul 30 16:59:02 pb_: question is how loud they scream and how hard it is to get them to work around it. Jul 30 16:59:10 then there is uclibc too Jul 30 16:59:11 fray_: well, right, but anybody with serious memory contraints is probably not using any form of glibc anyway. Jul 30 16:59:19 for smaller root file systems Jul 30 16:59:23 so I kind of agree Jul 30 16:59:26 bluelightning, hey Jul 30 16:59:29 just joined Jul 30 16:59:34 what am I looking for? Jul 30 16:59:36 I have customers who are.. they are able to pair glibc down to the size of a 'larger' uclibc system.. Jul 30 16:59:42 dvhart: poky tiny Jul 30 16:59:47 seems like it would make sense to drop it and see who screams. Jul 30 16:59:48 dvhart: we've been discussing the potential removal of eglibc option groups and its possible impact on setups such as poky-tiny Jul 30 16:59:51 ok.. time check.. 1 minute to go on my clock Jul 30 16:59:55 with fair warning of course. Jul 30 16:59:56 eren: http://lwn.net/Articles/488847/ Jul 30 16:59:59 what impact will it have if we threw away LIBC_FEATURES Jul 30 17:00:23 right, so fray responded to that pretty well I thought Jul 30 17:00:30 those are core to poky-tiny Jul 30 17:00:34 without them we have two options Jul 30 17:00:35 can you consider uclibc instead ? Jul 30 17:00:38 1 static linking Jul 30 17:00:40 2 uclibc Jul 30 17:00:48 ok.. so we have remaing projects in progress status and infrastructure.. do we want to skip these or try to cover them quickly.. Jul 30 17:00:56 static linking with eglibc/glibc is more or less unsupported Jul 30 17:01:13 fray_: we can skip Jul 30 17:01:13 fray_: let's cover them very quickly Jul 30 17:01:18 ya.. static linking also results in a (more then one binary) system using -more- memory Jul 30 17:01:18 denix0: thanks! Jul 30 17:01:19 or skip :) Jul 30 17:01:29 let me know when you are done Jul 30 17:01:33 There is also this little gem :-) http://www.linuxjournal.com/article/5457 Jul 30 17:01:35 * fray_ isn't a fan of uclibc in a commercial setting either Jul 30 17:02:04 fray, khem, I haven't done enough research to fully understand the impact/compatibility/etc of using uclibc Jul 30 17:02:06 uclibc should exist only as option Jul 30 17:02:20 I don't know where it breaks down, what it's lacking, which corners it cuts, etc Jul 30 17:02:23 ya.. the mklibs optimization may be impacted as well.. (likely won't be easy anymore) Jul 30 17:02:24 dvhart: I didn't realise you'd been working on this angle over a longer time period ;) Jul 30 17:02:29 and frankly, the fact that I don't know, means I don't want to use it Jul 30 17:02:32 bluelightning, ;-) Jul 30 17:02:40 dvhart: this predates NPTL Jul 30 17:02:44 ok.. further discussion we can do off meeting.. we're past the hour Jul 30 17:03:01 it was an odd sort of project when IBM was dabbling in embedded Jul 30 17:03:03 and maintainer's dislike for static libc Jul 30 17:03:05 lets take two minutes to cover the project status and then call it done. Jul 30 17:03:06 fray_: OK, thanks for chairing Jul 30 17:03:10 #topic 4a - oe-core release Jul 30 17:03:23 ok, I think I'm interrupting here Jul 30 17:03:36 We are currently aligning with the Yocto Project for the most part (and they are in turn aligning with us).. Jul 30 17:03:55 We're looking at roughly October for the next release, with a stablization period prior to release. Jul 30 17:04:15 I don't have further information, Richard is usually the one who has more detailed plans.. Jul 30 17:04:44 fray_: any significant changes expected? Jul 30 17:04:50 my personal expectations is a lot of the large churn should be done by late august Jul 30 17:05:06 darknighte not that I know of. The big changes (toolchain specifically) are already in place.. Jul 30 17:05:29 fray_: that's what I was hoping. Jul 30 17:05:31 I know there are some bitbake (webhob) and other changes in progress, but I don't think they will be terribly disruptive.. Jul 30 17:05:54 On to the next.. Jul 30 17:06:02 #topic 4b - meta-oe appends/overlay Jul 30 17:06:11 Bluelightning -- ? Jul 30 17:06:23 no status change on that Jul 30 17:06:50 this is something I think we'd like to be a regular working group topic.. Jul 30 17:07:05 merging meta-oe to oe-core.. and working on places where there may be functional differences.. for alignment.. Jul 30 17:07:10 #topic 4c - python 3 Jul 30 17:07:33 there are two items here.. one is introducing python 3 into oe-core (as a recipe), which I believe Khem is currently sending to the list.. Jul 30 17:07:45 * darknighte agrees with fray_ on the working group topic idea for meta-oe Jul 30 17:07:48 the other is eventually moving bitbake to python3. We've said that will not happen prior to the current release.. Jul 30 17:08:02 (october) but likely will be an issue for early in the next development cycle Jul 30 17:08:09 khem, anything to add? Jul 30 17:08:21 when you say "moving to", do you mean "working with" or "requiring"? Jul 30 17:08:37 moving to -- as the required python version for bitbake Jul 30 17:09:16 moving on.. Jul 30 17:09:24 There will almost certainly be significant pushback on the move to python 3. Jul 30 17:09:27 note that we might be able to keep supporting 2.x with 3to2 if need be Jul 30 17:09:55 darknighte we're aware of that.. we (oe) need to figure out if even next release is an appropriate time to do thsi Jul 30 17:09:58 #topic 4d - release status notification Jul 30 17:10:03 kergoth: pb_: AFAIK RP's thinking was that it wouldn't be practical but I don't know if he was looking at 3to2 Jul 30 17:10:19 fray_: I agree. Just want to air the obvious... Jul 30 17:10:26 RP, prior to vacation was trying to provide regular status information to the list. We expect this to resume.. Jul 30 17:10:36 and I think that's it.. we're going to skip #5 Jul 30 17:11:27 final comments.. if people think this is useful.. we'd like to do something like it approx once a month.. (or if thats too often, once every other month) Jul 30 17:11:35 I think a lot of people will be on vacation over the next month btw Jul 30 17:12:07 ok.. meeting done! Thanks all Jul 30 17:12:20 #endmeeting Jul 30 17:12:21 As Crofton|work says, I think a lot of people will be out. Jul 30 17:12:21 Meeting ended Tue Jul 30 17:12:21 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Jul 30 17:12:21 Minutes: oe/2013/oe.2013-07-30-16.03.html Jul 30 17:12:21 Minutes (text): oe/2013/oe.2013-07-30-16.03.txt Jul 30 17:12:21 Log: oe/2013/oe.2013-07-30-16.03.log.html Jul 30 17:12:24 12 minutes over.. :/ we'll work on doing it better next time Jul 30 17:12:25 thanks all Jul 30 17:12:38 fray: almost a linear offset from when it got started, no? Jul 30 17:12:43 darknighte ya.. we might factor that into NOT doing it next month Jul 30 17:12:49 darknighte :) Jul 30 17:12:56 indeed ;) Jul 30 17:13:05 thanks all Jul 30 17:13:31 are you going to post minute on ML? Jul 30 17:13:49 mckoan: I think Crofton|work was planning to post them to the website... Jul 30 17:14:45 thanks Jul 30 17:14:49 I will send to Jefro and will work with ka6sox so I can rsync them somewhere Jul 30 17:15:17 Crofton|work: today worked as the meta-bot ;-) Jul 30 17:15:54 mckoan: that would be Crofton-bot... Jul 30 17:16:10 fray, are you subscribed to the eglibc mailing list? If so, would you mind replying to the thread on the libc option groups, adding me to Cc, with something like "Darren, how would this impact poky-tiny?" to give me an entry point into the discussion? Jul 30 17:16:31 denix0: yep :-D Jul 30 17:16:44 denix0: ahh, but Crofton|work is the meta-bot to take the Crofton-bot capture and post it via Jefro... Jul 30 17:16:55 dvhart: who needs an introduction? :) Jul 30 17:17:04 dvhart I have responded in the past.. you should be able to just jump in though.. Jul 30 17:17:06 denix0, I'm not subscribed Jul 30 17:17:11 I can find a few of them and point you to the list archive Jul 30 17:17:16 so I need a way to respond to the thread Jul 30 17:17:16 darknighte: it's a meta-world! Jul 30 17:17:29 http://www.eglibc.org/archives/patches/msg01299.html thats the current thread.. Jul 30 17:17:31 I don't see a way to do that from the archives... Jul 30 17:17:33 dvhart: you will probably miss some e-mails from people who do not reply to "all" Jul 30 17:17:44 eren, I *will* subscribe Jul 30 17:17:53 ah okkie :) Jul 30 17:17:54 but I was not subscribed when the thread started Jul 30 17:18:06 yeah, I guess someone needs to CC you in the thread Jul 30 17:18:09 http://www.eglibc.org/archives/patches/msg01274.html Jul 30 17:18:12 right, that :-) Jul 30 17:18:21 or you can get Thread-ID and inject that header to your mail :P Jul 30 17:18:43 I was looking for the Thread-ID and didn't find it Jul 30 17:18:46 my follow up to that last was sending the email to the oe-core list asking about eglibc usage Jul 30 17:18:47 sure, there is no Message-ID or Reply-To in web interface, better get CCed, hehe Jul 30 17:19:03 fray_, right, I figured I should respond directly to the eglibc list Jul 30 17:20:33 anybody currently building/using nginx? Jul 30 17:21:13 i could only find recipes in some oe-rascal repo (not even sure what a rascal is) Jul 30 17:21:42 darren, I forwarded you three emails from that original thread, complete with message id's Jul 30 17:21:58 ignore them if you've already figured out how Jul 30 17:22:05 of course it has its own funky configure setup and doesn't build at all in oe-classic... Jul 30 17:22:14 heh, OK, I'll see if I can find a mailer that will let me hand edit the thread-id.... Jul 30 17:22:25 make that 4.. ;) Jul 30 17:22:37 have a nice rest of the day Jul 30 17:22:38 mr_science: hmm... haven't heard of anyone working on that at least discussion I've seen Jul 30 17:22:55 mr_science: a recipe for it would be welcome in meta-webserver though FWIW Jul 30 17:23:38 building nginx should be straightforward, btw? Jul 30 17:24:08 depends on which modules you want to enable, which would include lots of PACKAGECONFIG variables, hehe Jul 30 17:25:33 is anyone packaging it? Jul 30 17:27:17 bbl Jul 30 17:28:55 eren: i don't think so... Jul 30 17:29:41 building would be straightforward if it didn't use such a funky config setup full of oddball hardcoded paths Jul 30 17:30:11 so i'll need to patch a few things before i can say much more... Jul 30 17:31:09 just trying to make sure someone else hasn't already done it Jul 30 17:31:12 mr_science: well configure script seems to work Jul 30 17:37:54 Jefro, minutes are on the way Jul 30 17:38:39 ok, thanks Jul 30 17:39:03 hmm, topic did nothing Jul 30 17:43:03 eren: which version? Jul 30 17:43:52 i looked at 1.3.0 a little in oe-classic yesterday and it barfed on pretty much all the deps Jul 30 17:44:22 maybe the configure script was fixed in later versions? Jul 30 17:47:12 mr_science: latest stable, 1.4.2 Jul 30 17:47:14 http://nginx.org/en/download.html Jul 30 17:47:50 and it has a little documentation on how to configure the source: http://nginx.org/en/docs/configure.html Jul 30 17:52:38 the version i used only looked in one standard place and a few oddball paths Jul 30 17:54:20 anyway, the combination of older bitbake/oe-classic was not a good match for the way nginx configure works Jul 30 17:54:45 I guess it needs to be re-packaged Jul 30 17:55:29 the --with-zlib=path options expect path to be the source tree Jul 30 17:56:36 oh Jul 30 17:56:43 you can fake it with --with-zlib=${STAGING_INCDIR) but then make wants to run configure again to force everything to build static Jul 30 17:57:05 brittle homegrown juju Jul 30 17:57:51 probably why nobody's done it yet... Jul 30 17:58:09 they think "oh that's simple" until they try it Jul 30 18:03:47 hm, I'm wondering how ubuntu did it Jul 30 18:04:23 hm. it's 1.2.6, raring release Jul 30 18:08:30 mr_science: there is nothing fancy on ubuntu package, btw Jul 30 18:14:20 both ubuntu and gentoo have their patches... for native builds Jul 30 18:14:48 but it won't understand sysroot without some help Jul 30 18:30:30 eren: once i have something that builds i'll stick it on github Jul 30 18:31:01 mr_science: okkie Jul 30 18:39:45 Hi, how can I see which package or recipe installed a certain file in my final image? (I'm interested in /etc/inittab, and in this case it's probably sysvinit-inittab, but am wondering if there is a generic way to find out?) Jul 30 18:41:39 * kergoth looks into creating a systemd service for chen qi's r/o script(s) to try using those bits on a systemd image Jul 30 19:12:19 andre_d: don't know of a way on the build side, just opkg search /path/to/file on the running system Jul 30 19:12:38 not that that question doesn't come up regularly... Jul 30 19:48:46 I have just tried to figure out why oe sets load address to 00008000, while the same kernel sets load address 0x80008000 if built manually outside oe. I see the kernel links with zreladdr=00008000 inside oe Jul 30 19:48:51 any ideas on where that flag is set? Jul 30 19:48:59 tried git grep in oe-core, but found nothing:s Jul 30 19:49:52 martiert: .conf? Jul 30 19:52:00 denix0: .conf only sets UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS to 0x80008000 Jul 30 19:52:18 but the u-boot-mkimage is not run, so there is no relocation going on Jul 30 19:57:44 :-) Jul 30 19:57:46 Hi folks Jul 30 19:58:02 I had a day full of meetings, so I end missing the TSC one. I am sorry Jul 30 20:06:58 otavio: if you provide cookies, I won't tell... Jul 30 20:07:15 mr_science: hehe Jul 30 20:13:11 martiert: check your run.do_compile for clues, I guess Jul 30 20:14:40 pb_: I figured out the problem, but not the solution. I have appended linux-yocto_3.4 kernel, and in that append, I specify a sha sum for the git repo, as well as add a file://defconfig to the SRC_URI. The defconfig is copied over, but doesn't seem to be used Jul 30 20:16:43 any idea why it's not used? Jul 30 20:19:56 otavio, we should have good notes from it.. and we expected people to be unable to join, so all feedback and comments to the oe list(s) are welcome Jul 30 20:20:20 (we did minutes a bit differently with this format of a meeting.. so Crofton|work was helping get them uploaded to Wiki) Jul 30 20:21:30 ;-) Jul 30 20:21:42 Appreciated :-) Jul 30 20:22:56 martiert: did it build the commit you specified? Jul 30 20:34:55 martiert: oh, right. I think linux-yocto has some crazy special tooling, but I'm afraid I have no idea how it's meant to work. Jul 30 20:35:02 maybe ask the #yocto dudes Jul 30 20:35:03 mr_science: yes, and it copies the correct defconfig file, but doesn't copy it into .config Jul 30 20:36:28 pb_: ok, I'll ask them then Jul 30 20:40:54 martiert: looks like the linux-omap3.inc we're using does a "require" to pull in both those pieces Jul 30 20:41:12 mr_science: from meta-ti? Jul 30 20:41:23 require recipes/linux/[setup|copy]-defconfig.inc Jul 30 20:41:43 no, this is arago/oe-classic Jul 30 20:42:39 i would hope current linux-yocto is a bit less klugey but i can't say i've looked at it yet Jul 30 20:43:10 mr_science: that's in meta-ti as well Jul 30 20:44:25 mr_science: ok, do_configure in linux.bbclass does a cp ${WORKDIR}/defconfig ${B}/.config, so looks like it does what it should Jul 30 20:44:43 mr_science: although linux-omap3.inc was in classic arago only... but that was a special case Jul 30 20:45:10 martiert: is it really your defconfig in workdir? Jul 30 20:45:12 martiert: what's the problem? are you still looking for the load address? Jul 30 20:45:37 denix0: yes Jul 30 20:46:35 mr_science: yes, there is at least a zero diff Jul 30 20:46:43 martiert: what BSP are you using? Jul 30 20:47:10 okay, just checking... Jul 30 20:47:32 denix0: I'm making one myself Jul 30 20:54:39 seems like I fixed it by doing it in a do_configure_prepend, Guess I coudl also set B = "${S}" in my linux-yocto_3.4.bbappend Jul 30 20:55:30 sounds about right Jul 30 20:56:03 i had a similar "collision" replacing a package file from a bbappend Jul 30 20:56:19 not kernel-specific really... Jul 30 20:57:09 except now it's complaining about an unclean directory during kernel_configcheck. Guess I'll have to look at that code next Jul 30 20:58:44 erm, I'm not sure you should be trying to set B = ${S} Jul 30 20:58:51 it's set separately on purpose Jul 30 20:59:27 martiert: did you put your defconfig in a machine subdir? Jul 30 20:59:35 martiert: I'd really recommend you consult zeddii in #yocto or email the mailing list and cc him (Bruce Ashfield) Jul 30 21:00:14 ok, I'll ask on #yocto then:) mr_science: Yes Jul 30 21:01:14 okay, now i'm curioous... Jul 30 21:04:17 martiert: looks like linux-rpi-3.6.11 uses the same method Jul 30 21:04:48 ie, do_configure_prepend and install their own defconfig into workdir/defconfig Jul 30 21:05:18 that shouldn't be necessary though Jul 30 21:05:30 it really is supposed to pick up the defconfig in SRC_URI as I understand it Jul 30 21:05:37 tell djwillis then Jul 30 21:05:52 i haven't hacked that recipe yet ;) Jul 30 21:06:22 also, the kernel_configure_variable thing looks handy Jul 30 21:07:31 martiert: maybe you could get by with setting some kernel_configure_variable options in your kernel recipe? Jul 30 21:08:02 as long as there aren't too many things you need to change... Jul 30 21:10:27 martiert: one more... does your recipe inherit both kernel and siteinfo? Jul 30 21:18:44 before i completely dissect the apache stuff, anybody know how i enable mod_proxy? Jul 30 21:19:11 i don't see a separate recipe anywhere in my local trees... Jul 30 21:49:29 man, every time i get into something like this i wonder what i'm missing... Jul 30 21:50:54 eg, given the kernel recipe config options, seems like apache should have something similar for selecting modules and other stuff Jul 30 21:51:14 just feels like i'm always missing something... Jul 30 21:53:24 feel free to whack me with the clue-stick at any time... Jul 30 22:00:14 hmm, I'm not sure how apache extra modules are enabled Jul 30 22:00:40 (and that's a bit sad because it was me who worked on that recipe) Jul 30 22:01:25 :] Jul 30 22:01:39 guess we should dissect your brain then Jul 30 22:03:57 hey, I need that brain :) Jul 30 22:04:00 yup, looking at some recipes and the apache configure output Jul 30 22:04:29 looks like i definitely need to enable some things we need Jul 30 22:05:37 then there's tuning the whole mpm config for 600 MB of ram... Jul 30 22:05:54 maybe i should go back and look at nginx again... Jul 30 22:07:12 apache is kind of heavy for a lot of embedded type applications for sure Jul 30 22:08:19 nginx definitely fits better for most embedded plateforms :) Jul 30 22:08:56 we don't yet have an nginx recipe as discussed earlier, but for simpler configurations we have a number of alternative smaller web servers in meta-webserver Jul 30 22:09:11 e.g. hiawatha and cherokee Jul 30 22:10:11 currently running lighttpd but one of the devs apparently needs reverse proxy support Jul 30 22:10:14 mr_science: btw, I'm currently building/using nginx, if you want a recipe Jul 30 22:10:28 (it relies on the cross patch) Jul 30 22:11:00 bencoh: pointer? Jul 30 22:11:40 i have a (currently nonfunctional) recipe i lifted from rascal, but it needs some luv to make it work Jul 30 22:12:13 I'm using a different one (with a different patch), currently building and working on both x86 and arm Jul 30 22:12:22 (others should work too) Jul 30 22:12:42 based on http://forum.nginx.org/read.php?29,179478 Jul 30 22:12:42 are those publicly visible somewhere? Jul 30 22:13:11 lemme pastebin that ... it's not public for the time being, but nothing really secret (just a private repo) Jul 30 22:14:03 looks like the op disabled the problematic parts of configure... Jul 30 22:14:16 mr_science: http://pastebin.notk.org/pastebin.php?show=d386380f4 http://pastebin.notk.org/pastebin.php?show=d16cfcf79 Jul 30 22:14:33 --without-pcre --without-http_gzip_module ... Jul 30 22:14:46 jeez, *i* could've done that... Jul 30 22:14:56 I'm building mine with pcre Jul 30 22:15:07 (and gzip) Jul 30 22:15:08 good Jul 30 22:15:48 the important part of the ml mail is the patch Jul 30 22:16:13 looks amazing close to what was in my head... Jul 30 22:16:21 *amazingly even Jul 30 22:16:42 :) Jul 30 22:17:26 what's really amazing (sic) is that this thing is more than 2 years old ... and vanilly nginx is still not cross-friendly Jul 30 22:21:51 i noticed, and had the same "amazing" thoughts in my head... Jul 30 22:22:07 so stop putting them there! Jul 30 22:22:17 * mr_science dons his foil hat Jul 30 22:22:43 :)) Jul 30 22:25:41 is that really for 1.0.11 ? Jul 30 22:26:12 did you avoid the newer stuff on purpose? Jul 30 22:26:50 I first wrote this recipe 1.5years old and didn't have time to test it against newer versions Jul 30 22:27:00 s/old/ago/ Jul 30 22:27:07 ah Jul 30 22:27:18 i started making a 1.3.0 last night Jul 30 22:27:44 also noticing 1.3.11 is the latest in portage on my laptop Jul 30 22:27:46 wow, 1.0.11 really was latest-stable at that time :)) Jul 30 22:28:23 I guess I should give 1.4.2 a try, some day Jul 30 22:28:44 so maybe i'll just migrate everything to 1.4 then Jul 30 22:29:00 notice any hard deps in the new stuff? Jul 30 22:29:34 haven't checked yet Jul 30 22:31:23 from what i saw last night it's pretty much pcre and few more-or-less "normal" things Jul 30 22:31:43 so i guess we'll see... Jul 30 22:39:16 i can't believe i just did that... Jul 30 22:40:29 did you take care of the different data types ? Jul 30 22:40:42 after look at the local config stuff in the nginx and apache2 source trees, i just went back to lighttpd and went "oh nice, autotools for a change..." Jul 30 22:40:51 :D Jul 30 22:41:28 from what I've seen (quite a few years of porting/crossbuilding), autotools still is one of the most friendly ... which is ... scary :) Jul 30 22:41:41 yeah... Jul 30 22:42:04 i can't remember ever saying that about autotools before Jul 31 00:07:32 bencoh: thanks, i'll let you know when i have a newer one built for rpi Jul 31 00:07:54 unless they make me build it here first... Jul 31 02:50:52 hi Jul 31 02:51:57 i know this option variable_append= "" to add some thing to existing variable, i'm wondering whether there is any option to remove some thing form variable? Jul 31 02:54:01 johny_: don't think so, but you can replace it instead... Jul 31 02:59:39 which variable specifically? maybe there's a better option... **** ENDING LOGGING AT Wed Jul 31 02:59:58 2013