===== Digital-OPsis ===== Stelios: Very hard first steps but RP helped a lot. Got in contact with OE throu gh the dreambox. Digital-Opsis is doing embedded development. Usually you don't have a screen, very low amount of RAM and flash (4mb) and recently focusing on V oIP technology. Back then working on Wireless-Router for a public network in Ath en as the first project. Crofton (on irc): http://en.wikipedia.org/wiki/Athens_Wireless_Metropolitan_Netw ork Stelios: Mostly working on PowerPC, a couple of classes, specially icecream. Wor king close with the chip-manufacteurers, evangelist for OpenEmbedded going to co mpanies and putting OE on reference designs. Goal is to make OE more appealing t o the chip-manufacteurers, to get OE shipped with the reference designs. One of the biggest problems: support! Manufacteurers don't want to support users. Need to discuss OpenEmbedded and user-friendlynes, SDK Stelios: Biggest problem: No stable release. Not having one means we have to for k, with monotone it is time consuming to get it back to the .dev tree. Biggest s trongpoint: Allows you to build a system and focus on your applications fast, pr omises to be versatile. Koen: atmel's arm-devision uses an oe based board support package Stelios: if companies use oe for their boards, it would be nice to support oe developers.(DO NOT PUBLISH YET i.e. Xilinx may supply boards and tools, amcc will also provide boards) The next step will be finishing the reference design based on OE. The first question by companies are asking where the should commit to. Be careful on how to deal with companies. Mickeyl: Amazing, are the presentations publically available? Stelios: The presentations will probably be available soon. There are talks ongoing with other companies, but it must get easier to build applications -> UI-Design for OE Crofton: Do we want to have a Company/Public Relations group which keeps track of communication? Stelios: A foundation can help with getting companies comitted to OpenEmbedded but we must be careful to not get the foundation in conflict with companies. Mickeyl totally agrees: the areas where OE lacks something are SDK, more reproduceability for snapshots, UI. These would be the areas thought should be put into. Any specific questions? No. So go on, over to tarent. Robert: Tarent is a traditional software company, no so much embedded. developent is 100% java and only some of the developers have exprience with c, c++. The goal is to develop java apps on the free runtimes on embedded devices which increases the customer base OE because it is the most fexible building system and is used by interesting projects like OM there is no propper suppport for java in oe, so using an overlay (public SVN), want to merge upstream (ongoing work). Bringing java to OE is complicated but they are still committed. Mickey: What prevents one from using one of the SDKs (was it this???) Robert (Tarent): it works. two options: jamvm, cacao. one is smaller the other more featureful, personally cares about documentation, everything is in the wiki. Recipes will not included in the stage they are now, because they are not done the right way. the runtime depends on things on the host system Robert: plan for java toolchain: about half a year timeframe, he will have time for doing the support compliant to java standards. mickeyl: major complaint would be? robert: major grief is that OE has a very steep learning curve. even if you know a lot of free software stuff that's still not enough. understanding the recipes requieres a lot of background information (ie. glibc vs. uclibc) zecke: is this a lack of documentation or domain-specific? robert: I hope it's just a lack of documentation i was working on docs for the ntpl vs linuxthread issue. ?: the existing docs may expect a lot of prior knowledge robert: i'm in a good position to write docs because i am not very expirienced with OE jan: problems with working against oe.dev? robert: there is just one checkout in tarent and the snapshot is reguarly updated by me mickeyl: gumstix? crofton: started working with software defined radio, got mixed up with gumstix, because some intern some project is using the gumstix in a solar controler gumstix is currently using buildroot and distribute that, are not satisfied and are now migrating to OE. they have ~7000 users who would be very hard to support from OE. they need to have stable releases which would produce downloadable images the combinatorial problem with how different addon boards influence kernel config zecke: how is the support for distros like angstrom crofton: they want to have control over the packages, good for us because they are first point of support stelios: same issue whe have about forking and control. if it is hard to merge back, it wont happen. crofton: gumstix have a *lot* of patches (uboot, arm) which they dont push upstream we don't want to have that with OE. we want to recruit new (expirienced) people to OE but don't have the support problem richard: same with nslu (supportproblem) mickeyl: we have lost the nlsu, because it is powerful and easier to run debian hrw: debian is good enough for many people, so the dont look further crofton: really small space on the solar controller to leave space for a log of one year. How to get smaller dependencies? The gumstix guy hates task-base because the result is too big and it takes too much time to build it. We should think about image, image size and the 'domain' of this image. (changes with the different addon boards) the depends generated by configure depends on contents of staging richard: this is a bug crofton: Okay, but what about a package having different features. How to enable/disable certain features. richard: different problem, we need to document this, (we dont want USEFLAGS, see post on the mailinglist for explaination, should be in the the wiki, docs) We should encourage overlays for collections koen: collections should not degrade into forks by copying packages for changes which should be in OE proper mickeyl: bug with overlays, one needs to copy the whole directory, and not just what has changed zecke: ... says that is not a bug (i dont remember the reason) richard: i think it is a bug koen: we have too much wrong documentation in the wiki (mokumentation) richard: ? Crofton: Having documentation ad guideleines would really help (z:for what?) mickey: could we have a script which compares available options agains options which we set? koen: idea from yesterday: disable everything by default? Have a m4 hack for that Crofton: Is that going to work? zecke: Unlikely, m4 AC_ARG_ENABLE... can be used in different ways richard: package staging will help with that, we can install only depends crofton: it will be very nice to not have to rebuild after some time richard: I keep two trees around, one to throw away and one which is quite old mickeyl: next openmoko (some fancy phone project) i don't have that much to add, the biggest pain is: it works, mtn pull, it doesn't work which should be solvable by using snapshots koen: you can devel on your own host system, x11 and gtk zecke: I think there is a overlap with mamona as well. Either use native development as koen proposed or use the approach of mamona to help application developers to develop their applications. stelios: live cd based on debian? crofton: vmware image? koen: vmware doesn't need reboot zecke: hint: bitbake devshell stelios: we are working on OE for PS3, about 1/2 way there koen: tim bird is offering PS3 for OE devs? stelios: at the moment not enough developer time because of customer projects but want to seed developers. we are interested to seed interesting projects into the community to see how they evolve "multiplyer-factor". do we want the PS3-crowd in OE? ;) mickeyl: thinks it would be a good time to have a mid-sized break. get lunch somewhere one of the om guys (roh) is coming soon 14:42 break 16:10 return from lunch roh and Laibsch arrived How can we solve the three/major problems: -What prevents us from writing documentation -What prevents us from doing stable releases -What prevents us from releasing toolchains? (or use toolchains?)? -What prevents stelios: offer bounties for writing documentation? mickeyl: i'm not against paid work or hireing someone, but there are some people zecke: i'm against it (excluding the stuff we suck at, like docs) roh: the makefile helped my get started, it shows how it fits together mickeyl: could we change the makefile into a tutorial? richard, koen: no! koen: one you type bitbake the makefile should be out of the way roh: i used the makefile for avr32 because things are easier to grasp stelios, koen: "dont fix the makefile, document/fix the getting started wikipage" stelios: the docs should provide a clear image what oe is (=buildsystem) roh: the use of ccache must be documented (it is used when found) koen: read getting started! and local.conf.sample. And don't use MokoMakefile. zecke: don't be elitist (which is an inside joke) mickeyl: Details, details! There is an inherent complexity in this stuff, if you simplyfiy you get a cookbook. Or else it becomes the size of the OE docs. We need a professional writer. florian: It is really hard to write a good and short documentation but it is possible. If you run into issues they will be unlikely to be documented in such a short documentation. You should link from the getting started to the full docs. stelios: Different use-cases need different documentation marcin: Differ between Usermanual and Developermanual stelios: we need some documentation on how to get a new application running. If someone takes you by the hand, it takes at least one month to become familiar with OE. There must be different manuals, one cannot cover everything. crofton: at first we need to understand what our audiences are. zecke: what is our conclusion? spend money, write documentation for differnt groups stelios: options for getting money: find company to pay pledges for documentation (many new user from gumstix) zecke: slugos is an good example roh: cherry picking examples from userquestions, i.e. just makefile, no autoconf crofton: we only have docs for the easy cases, not for the harder stuff, we all know (many people rant about people answering the #openmoko questions wrong) (mickeyl shows some slides explaining basics) stelios: we are getting more and more people who are not developers and have no experience (koen on irc: we could go through http://dominion.kabel.utwente.nl/koen/talks/ELC2007.pdf, it include some very good examples) stelios: the documetation should describe what the "stable releases" are doing koen: describe srcrev 17:00 gismo arrives jan: videocasts explaining first steps? stelios: who has written documentation for an project that went to a customer? mickeyl: proposes to postpone documentation, because on depends on stable releases OE should not be used by people building an application for a specific distibution, instead they should use a toolchain prebuilt by OE. (zecke on irc: http://www.openembedded.org/screencasts/org.openembedded.htm) roh: ubuntu launchpad with connected buildhost which generates an deb feed for one hosted application, something like that for oe? (webbased) mickeyl: all the people using crosstool don't want to use something like OE, they just wany a prebuilt toolchain richard: two uses for the toolchain: * standalone toolchain * simplified a package staging for packages compatible to OE we have some of that, needs more users and testing crofton: how do we finish this? richard: document and publicize it, openembedded-devel-list might not be the right place crofon: most people there wouldn't need it because the are using OE directly mickeyl wants to use the openmoko users as guinea pigs (crofton: put them in a cage and take pictures of them) when the next release is finished we want a stable toolchain for external devs richard: with pockey we face the same documentation problem (richard brings an example of our arm toolchains used by russel) mickeyl: we have serval layers: perbuild toolchain: only applications applications and some oe fiddeling (limited package generation): ???? full OE: i want to replace everything ... mickeyl: third party package feed? crofton: the complexty of using the toolchain or oe should scale with the complexity of the users' problem, sdk for limited things, then move on more the complicated OE roh: people who just want to test their applications will want to use the external toolchaing, which is easier than OE crofton: Agree, people will recreate OE with an external toolchain but that is not our problem. koen: This is the problem maemo has? They can start easily but if they want to share it they will have to create a package and even dh_make would be available but is not used. xora: yeah but the debian documentation is horrible jan: it is not horrible and OE has the same issue with documentation crofton: we want to a...? mickeyl: we all know how likely to break a third-party feed is. but it's better than forcing guys to use the full thing when they only want one program crofton: Mickeyl's "problem" is how to get guys to write applets for OpenMoko to sell phones... mickeyl: yes, innovation starts at the user, people trying their own things, then i can try to get you into the project crofton: This approach appeals to many many other hardware vendors roh: people writing pet project dont want to write makefiles and fight with OE for getting their application/package running mickeyl: We can't lose anything with this approach. The hardcore guys won't switch and we can gain a lot more people. (roh: but we can get developers) xora: success of pda-x-rom and massively popular (not clean and not nice) because it had a toolchain and it was easy to share packages (get included in a feed) rp: we just need some scripts around the meta-toolchain and documentation xora: Packaging is really when not caring about dependencies and such. rp: it's up to openmoko, who are pushing this type of toolchain crofton: Creating a package really easily, and the next step would be a package with dependencies. xora: the next step would be OE rp: if you package locales you don't want to split them of from the mail package Laibsch: Not a developer understanding buildsystems but the only problem I see is the usage of hard-disk and that writing a bb file is not yet known but setting up a build is rather easy. jott: prebuilt OE environments for certain machines. mickeyl: For OpenZaurus this used to work, a poor-mans SDK. jott: the prebuild toolchain may be a simple entrypoint to OE, to get used to the infrastucture mickeyl: even i would use it if i had the change to get back into application programming stelios: the big advantage of OE is the package management, leave bb files as an option, first. but later we have to move them to OE/bb mickeyl: Yes, it comes down to documentation. We allow them to build packages without versioning, dependency tracking, etc... and encourage them to do it in a proper and clean way using OE. stelios: the toolchains solves problems with people/companies who come to rely on an specific toolchain. it is *really* hard to reple mickeyl: This requires quite a bit of more work. roh: Building packages from Ubuntu? Building distro packages? mickeyl: that's just a matter of the OE output format richard: Two questions: Building distro packages (looking at the problem from another point of view), 2nd question? Using a non-OE toolchain for OE richard: this is possible right now (using non-OE toolchain), it can generate rpm, at least there is a class mickeyl: We have marcins build-essential for debian/ubuntu to get all OE dependencies installed. xora: This is the danger of wikis. It points to package names instead of the debian packages (for non-debian distros using apt-get). Such things should not be documented but be fixed in the packages. stelios: What is the conclusion? Conclusion: mickeyl: I think we should just play around a bit more with the toolchains to see whether all these ideas play out in the practice crofton wants something he hasn't to think about to give to the gumstix guy [decentral discussions ensue] mickey: next topic snapshot/stable releases zecke: last year we decided to do stable releases. need to decide what stable means last years idea was to take a snapshot of .dev no cherry picking, no increasing version numbers and we keep a changelog releative to the snapshot we know which configurations work on this snapshot (by using autobuilders for all arches) list of known issues roh: why no bugfixes/security fixes roh: what is the difference betweeen stable and snapshot then? zecke: the difference: we are going to do snapshots roh: so there is going to be a stable release but no stable branch. right. koen: this applies only to OE, not Angstroem zecke: going to document incompatible changes to classes, i don't want to have several parallel stable releases, there is no best point of time to do a branch because several companies have several things going on simultaneously roh: currently the openmoko/oe development is limited to the first world with broadband access, because there's no way to get a compile running through on a line with less than 1mbit without code changing while the build runs stelios: we should keep as OE an framework for all the different products roh: we (OM) don't need a new glibc every two weeks zecke: we can only guarantee that we will take at a specific date and then document the delta to the last snapshot, so that the users of this release can port the next snapshot koen: we don't want to maintain a stable branch for OM roh: not about doing work for OM, but sharing the effort Crofton: In an ideal world every one would use OE directly but with many "customers" and vendors it is not easy to agree on anything. koen: this snapshot should be released as a tarball Crofton: the benefits must go both ways, no just from oe to other distros koen: why does everyone want to do a different distribution? stelios: for us it has to do with the toolchains mainly. in our case we want to have a very stable environment which .dev doesn't provide. roh: how does angstrom do release management koen: it doesn't. (is being discussed on the mailinglist) (explaination of difference between distro, machine and image) crofton: historically, people have created distributions for things which should not be an own distribution roh: that's because creating distributions is too easy koen: just because you need an xserver or not does not matter for choosing the distro crofton: there has been alot of confusion about what the distro, machine is can we clean up the distro directory? zecke: conclusion? if OM needs a stable release, then it will be greams decision koen: gream and i need to meet with OM and Angstrom people and decide *how* to handle the stable branch crofton: can we drop distros? mickeyl: i want to keep generic crofton: the problem is people use generic and it does not work koen: we would need to define policy, which we dont want corfton: many people ask why it doesn't work with generic mickeyl: get generic to build for a minimum of configuration, maybe as a tutorial crofton: generic might miss feeds and some additional features mickeyl: generic is a tool to make OE build with a minimum of policy fabian: if generic does not work, OE metadata is broken crofton: generic could be a good way to root out angstromspecific changes in the metadata koen: The issue of sane defaults. stelios stays at gcc 4.1.1 for ppc, arm e.g could need 4.2.1 and when finding the right toolchains you end up with 80% of the angstrom configuration stelios: Debian manages to use the same toolchain on different architectures. Not using the same toolchain will make angstrom different on the platforms. richard: it's angstroms choice of compilers, you're not going to get the same gcc to work on all arches stelios: Not using cutting edge for the kernel? roh: That depends stelios: backport the kernel to xilinx boards... koen: when you keep genric that simple, only one machine is going to work rp: Which machine to pick? mickey: pick x86 and arm zecke: that is no longer generic... all: rename to ... (insert names) stelios: debian manages to use the same gcc, binutils roh: Some machines/arch lack behind jan: Even if it takes weeks for a package to compile or a new one doesn't compile there is the two weeks old copy and there is 98% (90% for m86k) that is always built with the current version. mickeyl: we could remove genric if one could build without setting a distro mickeyl: In the beginning it was meant that TARGET_OS would be enough to build nano. (koen: said something....) richard: we need to move the defaults in angstrom which make OE work into the a default configuration file or (when appropriate) into the recipes. koen: That is what we wanted to do but we couldn't Yes is the conclusion... richard: we need to find a policy about what "no distro" means, we need to get away from doing distrospecific fixes (which should be generic) stelios: verify that the distros build for the supported machines, otherwise document or remove roh: we need automated regeression tests, we need testsuites. How does debian does this? [everyone laughs] koen: glacially jan: at least they have releases roh: the OM-qemu even flashes the way the devirginator works stelios: Come up with a way to do testing, doesn't need to be developers. koen: machine mentors! koen: have a checklist for checking, does it boot, has it graphics? the test results must be easily viewable on the website (like the olpc tinderbox, automated flashes) Tinederbox of OE is only for the build, this need autobuilders for OE. xora: Simplest testing, web-poll for downloading stuff posted by zecke on irc: http://www.gnome.org/~mjs/gnome-test-plans/ stelios: users can test, many users... roh: not in a reliable, trust worhty and repeatable way koen: stop at the scope of OE, ie if i have x in an image, does x start? don't test more than that stelios: Does it make sense to have human automated testing. posted by zecke on irc: http://tieguy.org/blog/2007/03/18/productive-testing-tips/ koen: the results of the automated testing should decide when to do snapshots, we need to make our QA tools better and better known. we need an official OE auto- builder. stelios: we can give acess to our build cluster until first stable release, it is limited on bandwidth, 10 machines, celeron 2,5 GHz, will need a "farmmaster" koen: would be very useful, should attach logs to bugs roh: openmoko should offer a machine for one year and give it to OE control koen: one full build for all libcs and arches will take about 3 days one a dual opteron koen: we need someone to build a webfrontend for the buildnetwork stelios: 2 releases a year and snapshost every 2 months between? koen: only after the buildbots are done crofton: we have to try and see how it develops stelios: if the above does not work double the time between releases and snapshots daniel: what are our requirments for a stable relase? I think we need to have a clearly defined set of tasks zecke: How do snapshots and stable releases relate to each other? Marcin: A snapshot is a snapshot Daniel: A stable release is a special snapshot Jan: do snapshot based on architecture stelios: do we have any broken architectures currently? grame: x86_64 is broken crofton?: x64_64 too koen: that's very broken grame: in angstrom old machines don't get tested anymore stelios: that's why machine and architecture are two different things grame: we have to pick example machines/devices for a class of machines, to reduce the amount of testing/building needed stelios: so, should we close this? mickeyl: I think we should close for today, i'm very tired. koen: But that is about 4 hours early. (it's 19:30 now) mickeyl: then we can go to the next point, but you'll probably not want that (the next point is "Changing SCM") (discussion about time of dinner tomorrow) -> starting about 19-20 (general chaos) Koen: we talked about scm yesterday at dinner, git readonly would be a good start right now, ppl cant merge large branches, holger had a converted OE repo, which broke completely when he tried to push it. cofton: it doesn't track directories richard: why empty dirs koen: basefiles/skeleton richard: .dummy files will break current bitbake ==== Changing SCM ==== koen: what are the reasons for changeing? except accepting big patches, which must be reviewed anyway... mickeyl: there are other reasons roh: is there a way to make monotone faster? henryk: disable crypto koen blames MokoMakefile and suggests that for anyone not trying to commit changes the readonly git would be a solution, or rsync the tree or something crofton: a readonly git mirror would be really nice roh: I don't care which tool is used because every project uses different ones. But completely updating the local tree is important. mickeyl: let's use the git mirror koen: git is the new gentoo; people alwas say git without bringing any valid points mickeyl: I think branching and merging might be really tough for us with monotone koen: mtn does supports good merging. Why would anyone create the same file in different branches (which is the main problem with mtn)? zecke: Coincidence grame: we have a pet mtn developer, we shoud nag him about our issues koen: we even have two koen: we should talk to the mtn developers, and find out how complicated the changes should be (we have a place to eat tomorrow) (general rumbling about eating german food in germany) stelios: the next meeting will be in greece, so then there will be no food problems zecke: who wants the mtn2git patch? koen: put it in contrib, contrib is the OE B-Side crofton: we need an fpga-monotone-accelerator [discussion of a possible GUI to create images based on a few selections outlined in http://www.openembedded.org/~koen/OE-gui-flow.pdf] koen: python-curses is extremely underdocumented 19:56: food? mickeyl: ok. Yeah, I think we should push the rest for tomorrow. *The inevitable food selection discussion ensues* ===== 9.10.2007 ===== Mickeyl is char again and we seem to begin at 11:18. koen: do you have gobby for macos? === Advocacy === ==== OE vs. (crosstools, buildroot, crosstools) ==== mickeyl: advocacy koen: When are we going to switch to t2? mickey: Right and how about going back to buildroot koen: yea, buildroot rocks! marcin: or scratchbox, I have heard so many good things about it from o-hand people. Crofton: Buildroot yay! koen: scarebox! mickey: Yeah, I think we should have something like buildbox compared to ... page koen: we had something like that in the user manual mickeyl: where? [everyone laughs at mickeyl cyberstalking croftons sister] Laughter, mickeyl searched for nude pictures of philips sister... mickeyl:pastes the secret diaries of my sister on the screen The documentation link on the web page is useless. koen: blames the theme we use on the website. koen: the openembedded usermanual Openembedded user manual is pointed to in IRC again. (http://www.openembedded.org/user-manual&dpage=chapter_comparing) mickeyl: This document is a decent comparison crofton tells that the gumstix guys are looking at OE because they are not entirely satisfied with buildroot mickeyl: we might make comparision chapters t2 and scratchbox zecke: Do we even want to mention t2? Do we want to waste our time for something that doesn't exist. [mickeyl shows the t2-project.org website] koen: in the OM channel you probably get more of the t2 abuse stelios: we are quite a young project. how old are we? ;-) koen: 4 years mickey: so we should ignore them? stelios: Are there any real products that actually use t2? The strong point of oe is that there are companies using OE. koen: I think the biggest advantage oe has over t2 is that we actually patch packages to work better with embedded devices. T2 takes the stance that they dont want to change the packages and stay close to upstream. (the t2 handbook is reviewed) xora: t2 isnt actually very good for cross compiling according to their own news articles. zecke: t2 requires root priviliges to build software koen: Please fix the website so it looks good stelios: We should rather concentrate on what we do best instead of looking at what the others do wrong. koen: Could we get someone to redesign our website? xora: The main thing we suck at is our website. None of us like documentation. stelios: i think we need to spend more energy and that translates to money crofton: the t2 website looks very professional xora: And it's actually just 4 lines of css that would do that crofton: we are just to busy to work on the website sterlios: We need someone with an artistic gene. hrw: Oh, it's not me! xora: Would openmoko be willing to sponsor a couple of weeks/days worth of designer time? mickeyl: i can bring that subject up crofton: the website being more useful would help with a lot of the problems we discussed yesterday mickeyl: Especially the scratchboxcase might be useful xora: We should also look at ptxdist. mickeyl: Isn't it just cross-tools? (asked more than once) everyone: no xora: they are not insane and decent guys to talk to. So if we would compare to ptxdist they would not go insane. koen: this is where we got the bigendian arm patches from crofton: Eldk I think is (what?) mickeyl: so, vivi, you know about scratchbox. could you contribute? what is OE doing different from scratchbox? it probably is part of your presentation, isn't it? vivi: yea, for me its completely different koen: oe can make scratchbox toolchains/rootstraps mickey: Yeah, just two sentences: "Scratchbox is a toolchain for ..." and "OE can be used to generate scratchbox toolchains" florian: Even if importing the toolchain is a scary process, but it works koen: It was pretty cool pasted on irc: http://dominon.kabel.utwente.nl/koen/cms/using-openembedded-toolchains-in-scratchbox koen: should we hightlight features like gnu config patching? For example AVR32 has a lot of patches that just patch config.guess to know about the architecture. OE just patches autoconf, regenerates config.guess and things just work. mickeyl: we have a lot of there really nice things, look at site-cache. We don't highlight them. => enhancing the usermanual to highlight our strong points. koen: this is why we like autotools packages, they just work in OE ==== Press Releases ==== mickeyl: so what about this codesourcery press release stelios: I spoke with Mark Mitchell of CSL, at a power.org conference and gave a talk about eglibc and how it performs better on powerpc. I approached him after the talk and mentioned OE can build eglibc. He asked if we could put something on our website that we support eglibc for some targets. koen: we could ask khem to write something? mickey: you have the most experience with this stuff, don't you koen? dont have to explain the details Crofton: Highlight the features of eglibc for a press release, so it can be used on multiple sites. mickeyl: Shouldn't we issue one? xora: Yes Crofton: It would be nice to post something to LinuxDevices.com, they seem to be well setup to handle it and a lot of people read it. xora: Well lots of companies issue press releases about absolutely nothing. I think we should do the same. People usually only read the headlines. If we're not in the news no one will know about us. mickeyl: Summarize this gathering in a nice way? What would be the headline? stelios: we should announce the release policy, git mirror mickeyl: we have enough stuff for a press release xora: do we have a guy that is good at press releases? zecke: we should poke gerwin mickeyl: ok, then poke him ==== Survey ==== mickeyl: should we have a survey again? ?: yes zecke: it would be nice to have a yearly survey, not too late this year. mickeyl: do you think enough has improve for the casual user to notice zecke: you can get a good impression about our users florian: what do we know about our users, we have quite a few new users mickeyl: we need to include some question about what is the hardest parts in oe and we already know about that due to all the people from openmoko complaining koen: are the problems due to OE, the OM overlay or MokoMakefile patches? xora: one question should be "Do you use MokoMakefile?" mickeyl: Makes outrageous suggestion xora: make perfect-survey mickey: Holger, could you do that? crofton: And be sure to ask them what they are building for? zecke: Looking at my schedule I would like to target January for the survey. mickeyl: sounds good florian: these guys do a pressrelease about crosscompiling some pice of software?? stelios: has someone done an analysis on when openembedded come up on google when searching for like "embedded crosstool"? (mickeyl opens google trends and searches for openembedded. no results. openmoko shows a result for openmoko) mickey: (when t2-project doesn't show up either) Okay, that's a relief mickey: so early 2008 we do survey what else do we do next year we had a really successful fosdem booth last year florian: Yeah, we should repeat this koen: (reviews websearch results) conclusion, we need to work on moving up in search resutls ... marcin, you have the google statistics thingy for the openembedded website vivi: did I mention the scratchbox2 environment? mickeyl: what is the difference between sb and sb2? florian: it's not a box anymore vivi: ..?.. its easier to change the toolchain mickeyl: so your mostly using sb1 vivi: yes mickey: So talking about FOSDEM: Who already knows that he will be there. (florian, koen, xora raise their hands) (hrw will not be there) Fosdem is 23. and 24. of February (probably) mickey: we will aim for a booth again koen: two booths? mickeyl: Larger booth at least. i could apply for an OM booth and someone else could apply for OE. We should ask for a larger booth because it was pretty clear there was not enough in 2007. crofon: it would be nice is OM would be seperate so that you could market the phone mickeyl: Not sure, FOSDEM is a hackers conference. Need to think about it. xora: Table location at FOSDEM was problematic due to columns crofton: do we have contacts at FOSDEM which we could use? koen: Phillippe mickey: it would be nice to have an own booth on guadec koen: I screwed up and did not get on a press release xora: linuxworld london? there are many business people (in april) crofton: what other more business oriented conferences sould we attend? xora: Embedded Conference in London mickeyl: embedded world 2008 in nüremberg Florian: Embedded world might be quite interesting (mickey opens an pdf on EW on the projector) xora: perhaps some OE people on the companies like Atmel booth crofton: it might be a good way to get more exposure (mickey finds the prices for embedded world: ~200€ per square meter, and 9 square meters minimum, plus 300 euros for "communications package") mickey: its too expensive xora: things at conferences will get stolen so we need to make sure OE can afford to lose the equipment. crofton: exploit every relationship we can to get in on the sly stelios: need to select guys for tasks to communicate these things stelios: Prepare OE presentations for introductions crofton: it would be nice to have presentation templates and training materials i.e. for "learn OE in 2 days" stelios: sponsored oe training florian: at the next OEDEM? [slight chaos, people getting coffee] koen: 132 pages, the openembedded user manual, in its current state [the manual is opened] what's the license on our manual? creative commons, attribution mickeyl: any more points for PR activities or should we make a short break and then get to the foundation part? zecke: short break mickeyl: ok, then coffee ==== Foundation ==== mickeyl; Do we want a foundation, if so what kind, and who does the paperwork? mickeyl: Holger is the foundation guy zecke: I am struggling with git, give me a few minutes mickey/zecke: mtn merge zecke: proceeds to use mickeyl's laptop mickeyl: Do we still want a foundation? zecke: Last year concluded we want foundation to have relations with companies, not perform business steliosk: We need a foundation, to avoid problems regarding who holds copyrights. What happens if eight hundred gorrilla shows up and causes trouble, really trademark zecke: Copyright issue isn't really an issue for OE since its metadata MIT license. OpenEmbedded name is different question mickey: I see an important point in how the project looks like to the public. And this would improve considerable with a foundation. koen: What happens if company wants to donate $xxx? Currently, er....? mickeyl: Visibility is really important, shows long time commitment to the project. zecke: I totally agree with that point. And for that reason we can't side with SPI or some german equivalent but need to do one ourselves. Richard said it was possible to create a ltd. in the UK which is a normal company, but there is no quarantee that it will stay nonprofit/noncommercial. We should have a nonprofit foundation. zecke: So we agree that we want the foundation to be nonprofit and hold trademarks, represent openembedded to the outside, accept donations? (general agreement) zecke: In Germany that is a form of a registered association. There's a possibility to have a nonprofit/beneficial association. The downside is that you have quite some overhead creating/running it. zecke: suggest general assembly in Las Vegas! (Much rejoicing) zecke: Further things to consider: tax exemption = further work henryk: and there's the problem of keeping that status and not getting fined for spending the money on the wrong stuff. zecke: Due to this we have to decide if it is important for us to have tax exemption, if that justifies the added trouble. sterlios: I think it would really be beneficial for us to be able to give the companies tax exemption. We only need a lawyer once a year. zecke: eV can decide how to add new members mickeyl: This would require substancial initial investment? zecke: eV needs 7 memebers steliosk: greece needs 30 zecke: if we create a registered association and we should do we have two options. either do tax excemption or not if we start without tax exemption then we can do that later at a later general assembly. Ease creating a foundation a lot. mickey: Yeah, we should do it step by step zecke: we agree on creating an eV not tax exemption in first year. (general agreement) zecke: proposes copying the KDE document and doing an s/KDE/Openembedded/g florian: you have to report how you spent the money zecke: members have option to decide that they dont trust the board anymore not required by the law to have a budget steliosk: seen in others situations where they have large meetings of 400 people and need to have a budget. steliosk: and they are greek zecke: The KDE statues have strict rules about what can be reimbursed. steliosk: the idea of a budgment is to arrange how much is available for stuff like travelling. zecke: not too predictable how much money is available how many donations come in and how many companies invite to conferences. shoragon: you can change the budget zecke: basically have agreement we want to do it, we now need 7 brave people Call for volunteers shoragon: do we need to be at the Amtsgericht call for people who can spell in German xora: I would do it but need to negotiate with OpenMoko over contract terms hrw: I would do it but also need to check contract. But if we create eV on FOSDEM then there is no problem for me as I will be not there. mickeyl: would love to do eV as FOSDEM, no sense rushing things xora: Can we get a list of volunteers? koen: Offers free beer to volunteer Doctor President Mickey, President Doctor Mickey? sterlios: We need three people: President, secretary and treasurer xora: for treasurer we really need to hire an accountant for that position zecke: that is difficult finding a reliable person who also knows opensource, KDE searches for 1.5 years. steliosk: we can get the money to start an eV if can go out with something solid. zecke: 120€ for starting steliosk: we can get donations most likely by poking companies. mickey: possibly talk to OpenMoko steliosk/mickey: irex might be possibility as well RP: irex might be too small rschuster: do we have special measures to stop takeover from 3rd parties zecke: depends on statutes rschuster: does KDE have such clauses we can copy? mickeyl: how can this happen at all? zecke: to become KDE member you have to be proposed, 3 people need to second then there is an election florian: different levels/types of members can be done, with different rights to different types. steliosk: need some way to screen people. Has seen problems before where unknown people managed to force into organisation without others noticing. florian: think in germany you cant create a "closed" group. zecke: we are going to prepare statutes for association, they will be in German. Send a draft. === Infrastructure === ==== How to spend donated money wisely (e.g from Trolltech) ==== zecke: how to spend money wisely, not at all koen: Buy furniture for Holger koen: needs invoices but path was confused florian: need to prove how we spent money zecke: this means KDE eV will do stuff florian: can we rent a machine and pay 2 years in advance? mickeyl: Id like to propose the first thing... covering part of Philips travelling expenses. zecke: stefan_schmidt denmark? zecke: Using funding for code sprints? general: worries about overattendence of code sprints distracting from specific topic of sprint stelios: Ask mailing list for code sprint topics. Focus of topic should encourage natural selection. ==== Mirror Status ==== Florian: four databases running on linuxtogo koen: Monotone mirrors need private key mickeyl: Ideally need own machine which we can trust access on florian: linuxtogo might get second machine for database services crofton: http://geekisp.com/ steliosk: do you have bandwidth numbers for monotone koen: negligible florian: I can post some figures koen: round robin should be fairly easy and there is scripts to sync servers automatically mickeyl: how much ram do we have in l2g koen: 1G which is 300M too little florian: cant upgrade as machine is rented. mickeyl: we shall see what falls into place early next year koen: keep in mind we need hosting koen: round robin requires Kergoth mickeyl: will talk to Kergoth after foundation stuff to talk him into transfering the domain. steliosk: can give access for autobuilder and build farms, limited on bandwidth and access has to be controlled. We can set up and see how things work. koen: talked to zecke about injecting things into runqueus in bitbake. makes autobuild easier. steliosk: is any of our current machines fast enough for farm master. mickeyl: l2g probably not fast enough steliosk: one opteron can do angstrom minimal image in an approx 1h to 1.5h steliosk: who is the one who will do this koen: holger did most of the hard work to setup current systems steliosk: I have time for the next two months, then no time for months ... zecke: cant donate time but can give away code florian: ah I have numbers l2g is 500-70-GByte/mounth, including angstrom source mirror koen: shall we try sepuku instead of buildbot zecke: randomly build stuff with a script for fixed targets koen: Yay, no train strikes on October 10! == Bitbake Development == mickeyl: holger and/or richard, please comment an "where does it go towards" ==Future of Bitbake== RP: Where do we come from, 1.8 is pretty stable, much better than the 1.6 branch RP: not much scope for moving beyond 1.8 RP: Future is moving toward client server, posssibly integrate into a build bot architecture RP: There's a lot of potential in making it easier to use RP: How to handle reporting integrated in to existing system as we move to client server RP: the idea is to look into what buildbot does and integrate it better with build bot e.g. when a build fails you want to have more than just "build foo failed on machine bar" stelios: so the server/client split would only seperate the bitbake user interface from the actual building, possibly with a network in between? RP: yes, it would be regular bitbake with the UI taken out (can then be a GUI too), generated binaries etc. would stay on the server [koen suggests 3D build log files to enhance the coolness factor] ==UI Core Decoupling== mickeyl: so i see we are in the UI/core decoupling part? is there anything missing? RP: a lot of code is printing error messages still. we got the idea of commands passed from client to server, but a lot are still very limited. all is just a matter of more time RP: The problem with ncurses is that I haven't worked with it before Henryk: Glade is very easy RP: yeah, I have recently worked with that for a different project steliosk: how easy to get a client working with windows? RP: given that it's python, should run steliosk: and you also have mono, that might be easier to get traditional windows developers mickeyl: are we talking about just running the client on windows machine? steliosk: and having at least one GUI written in mono that would work on both machines koen: we even have mono on Neo so we can monitor builds on Neo RP: I dont think the server will ever run on windows mickeyl: I would like to have it xmlrpc based because its very simple to attach from many different clients. RP: well it is xmlrpc based. I have a different argument that it should be dbus mickeyl: dbus oh no RP: it might useful on a local machine basis steliosk: but then you need another interface if your server is remote RP: there is demand for a dbus interface hopefully we can run them in parralell steliosk: what state is this in at the monent RP: code is in bitbake trunk but might not be perfect yet steliosk: is there any documentation on what messages are it or is it still in flux? RP: code is in flux, but its hard to say what changes are needed until there is another client RP: now I know python and gtk then gtk client might move on quickly now as ncurses is difficult and gtk+ more interesting [mickeyl phantasizes about working with PyQt] RP: what would people want with user interface for bitbake hrw: what already does bitbake do and which tasks? koen: easy access to outputs and log files and an indicating to how much we have done/have left to do. shoragan: use metrics to work out how long build will take to complete mickeyl: parsing error automatically opens editor at the line at fault. koen: remeber this is a remote protocol. RP: interesting problem as you can do it over client/server protocol or go direct. best way to go would be to use X RP: Is that what we really want? RP: Progress bar type thing steliosk: what happens when you disconnect client RP: depends on the client shoragan: do you think several people could be using the same server at the same time steliosk: can you do network broadcast type messages to monitor server building RP: not sure if we will have enough clients to make that worthwhile Henryk: have we thought about zeroconf/avahi support XorA: please root me broadcast message koen: can icecream run across a VPN, is latency a problem steliosk : you need about 1Mbits/sec steliosk: icecream takes into account delay so latency isnt a problem. Its not a guarantee that if a machine is plugged in it gets scheduled jobs if the work to ship job to machine negates the speedup jobs wont be sent to that machine. steliosk: the fastest machine should be the build master of the system as that machine runs all the configure and unpack tasks. Sometimes build master actually runs all the jobs because its faster than sending them across net. Bitbake 1.8 has improved scheduling though. shoragan: can you have more than one build master steliosk: yes as you define networks which are logical and one farm master controls one logical net. Idea is you can use spare cycles from peoples machines while they are not being used. Loads are balanced to not DoS machines so they are unusable for the person sitting at the machine. XorA: is icecream 100% working now steliosk: yes but all machines have to be exactly the same version zecke: one adition problem in OE, we can build multiple CPU toolchains, but to do this we would have to build multiple toolchains for each architecture. steliosk: if master is 64bit then it can ponly send to 64bit clients, 32bit machines can send to both if compatiblity libraries are installed on clients. mickeyl: is anyone still using the shell? hrw: bitbake shell? it's broken zecke: there is one bugreport mickeyl: so there are still people trying to use it. hrw: it was useable when it worked, but then it broke mickeyl: richard broke it. i'm pretty sure zecke: bugreport 1880, http://bugs.openembedded.org/show_bug.cgi?id=1880 mickeyl: I still like the interactive idea. It allows the shortcuts I want like jumping to bitbake file or jumping failures, jumping to meld. I would still like to have it, but if we have a full blown client then its possibly no longer of use. RP: its still nice to have it there, but it will probably be split into two so its one of the clients and stuff that needs to be in server is still there. already starting writing client functionality as plugins. so shell form might change but general idea stays the same. ==Speed Issues== mickeyl: last year we had a lot of discussing about parsing speed etc. zecke: yeah, we should also look at where we came from. I also just fixed a ridiculous for loop, lot of access to getVar etc. we don't have insane amounts of calls to bb.data anymore. RP: when doing profiling you would see some numbers jump out at you being called 3 million times. When we have 4'000 bb files and making 35'000 stat calls mickeyl: do you think it can be sped up even more by using c based extension. Is python the bottleneck? zecke: I don't think we have a memory issue. the usage is acceptable RP: around 100 meg zecke: building speed: bitbake is not the overhead anymore, that is in automake parse speed doesn't take ages anymore due to the cache. that's the last issue. There's lemon from max singer which parses 4'000 in 1sec, which is great, but our parser does more. The only issue is in the python interpreter interpreting our metadata. 35 seconds are spent interpreting our metadate. we could probably halve the time be using c. we should rewrite the metadata, get rid of immediate assignment and python calls RP: just as an example when we moved the fetches around and shuffled fetcher code around we were saving 10%. mickeyl: so we don't have any problems with the speed as its now. RP: well, it could also be faster zecke: it's not as bad as it was rschuster: does anyone know whether there's an effort to make psyco work on other platforms mickeyl: psyco author moved to pypy zecke: pypy is doing a good job rewriting the calls to bb.data, but it doesn't matter RP: psyco gives a 10% speed increase, it's not as useful as it once was steliosk: anyway the biggest delay now is autoconf koen: and if we fix binutils? ==Autorebuild Dependencies== mickeyl: there are frequent complaints/requests. once we bump the revision of certain package that then the packages that depend on this package should be rebuilt. I think we may want to add this but not implicitly, i'd like to opt-in to that feature rather than opt-out rschuster: should those packages get the same name? they might be different hrw: bump PR koen: so every bump on gcc bumps PR on 90% of our metadata mickeyl: no, no PR bump koen: not our problem, distribution problem hrw: [explain wireless extensions problem, upgrading wireless extensions creates package with same name but binary incomptible] PR: this really is something distributions have to handle on their own koen: [explains that openmoko users don't want to rebuild everything because gcc 3.x bump, as noone is using gcc 3] what does debian do? shoragan: BinNMU, binary nmu [everyone gapes at http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=140164891341] mickeyl: to summarize RP: it's planned and possible, just needs some merging ==Variable Naming/Word Seperator== mickeyl: yesterday we raised briefly the namespace improvement changes, and richard pointed out that actually we are polluting the underscore namespace which is used for overrides. RP: I just pointed out that if we got rid of the underscore, it might actually get faster zecke: it's also that some name might become an override in the future. some are unlikely (like URI from SRC_URI), some more likely [short discussion about potential underscore replacement] mickeyl: I should think we should use the hypen. It's a fairly intrusive change RP: yeah it is. I wonder whether we should use this just for new names and slowly replace the old ones ==Getting things really small (task-boot, task-base)== mickeyl: I think the next point is in this section by accident, so just remove it here it's more an OE thing ==SRCREV status and further work== mickeyl: so, srcrev. it's great, it works. What fetchers do support this by now. RP: SVN has no problems with it, knows about monotonic revisions. git has problems. Ideally you need a number, not a hash koen: as we said, git is not really a svn. RP: There are some for which this is not possible. Such as CVS, which only has a time koen: bazaar has a patch number, so that should work. RP: we don't have a monotone fetcher rschuster: mercurial has numbers, but they are site-local koen: we have localref, but that's local what's the next point mickeyl: the next point is: I would like to have a note from bitbake when I'm building a srcrev while a newer version is on the server RP: yeah, that's something I also want to have. there's nothing technically stopping us mickeyl: anyone mind a 15min break? ok, break =OpenEmbedded development= mickeyl: let's start the last session today. OE development ==task-base vs image siez vs build time (speed issues revisited)== mickeyl: yesterday it was said that we need to strive for smaller build, e.g. for the gumstix people Crofton: yeah, I think it makes sense to aim for tiny builds mickeyl: how tiny? Crofton: I think the step between task-boot and task-base is too big: task-boot has no features and task-base is too big, we need something in between mickeyl: but wasn't task-boot thought to be exactly this Crofton: but task-boot is very basic. It does what it is supposed to do koen: write something which is similar to task-base has less features Crofton: I think you are right this is really a documentation issue steliosk: there are some devices with a fixed task, that can't do any other things mickeyl: how do we help these people? koen: "task-base is ok for you if you have more then 8 megs of flash" ?: we should tell people that it's ok to write an own task package RP: task-base came from poky because we were cleaning up the mess that was task-bootstrap koen: it's a sane default ?: for some device udev is already too much ?: does angstrom depend udev? koen: if so, that's a bug crofton: so we all agree that angstrom has a bug steliosk: it's a feature not a bug, because of the big range of devices florian: can you currently build images without the package manager mickeyl: i hope so koen: no, you need dependency information RP: the system is generic, we have an option to build from ipkg, and one from deb The way Poky does this is build from ipkg, then throw dependency information away [RP then goes on to pour water into florians computer] koen: the other problem is that OE assumes a read-write filesystem, because of the firstboot scripts steliosk: actually you could write a class. koen: it needs to actually run on the system because a binary must run that writes out a file. Not everything can be solved with qemu (think AVR32) mickeyl: I think having a task-readonly-filesystem plus a corresponding image would be really cool for some packages Crofton: I think really important would be to track down who these people are [those with really tiny amounts of ram] and encourage them to do that work koen: yeah, and stop them from saying "task-base is too much" crofton: i think we need an image for what marcin was saying, as ramdisk image, which doesn't need ipkg koen: another point of image classes is that we hardcode /etc /lib etc. [Crofton suggests a section on the OE site with links to other sites that supply demo images based on OE for different devices] [stelios points out that a lot of people think "ah, I have to build a new distribution" when they really should be creating a new image] stelios: we can clarify on the website what, in OE terms, is a distro and an image koen: the best way forward would be to have a webpage for every image with information about that image (created by, used for, contains), then make available vmware image with qemu to try it out RP: all we need is a postprocess command (ROOTFS_POSTPROCESS_COMMAND) mickeyl: next up is "configurations" but we already covered most of this. cleaning up in the distro dir and do something in the products category ==init systems + init scripts== mickeyl: i just put in "init systems + init scripts" koen: you mean like upstart? mickeyl: yea. currently we only support sysvinit i think we should try harder than that. not only for openmoko but also for other. sysinit is extremely flexible. and slow. we don't need start and stop and five runlevels. then there also are devices that need more than that koen: i think we should split that up into steps. poky is designed to start X11 as fast as possible. the people crying "upstart" basically want X11 to start faster. [xora brings up the point of rewriting init scripts] Crofton asked for examples of possible replacements: upstart linux.rc busybox init dbus alternative to sysvinit init-ng runit launchd from Apple (koen told that it links to non-free libs) many others [mickeyl shown page: https://wiki.ubuntu.com/ReplacementInit ] steliosk: We should remain focused on a small subset of possible init solutions [general] bitching about busybox mount screwing up things steliosk: Try one select one alternative to sysvinit for smaller/lighter systems [general] Do abstraction for one init and the others will follow stelios: we have about 1 hour left mickeyl: we can continue during the dinner a bit Reducing the user visible startup time RP: it's being brain-stormed, did nothing yet Ross is talking about xora : I can start gnome in runlevel 1 from hrw on irc: http://wiki.debian.org/HackFests/Init ==improving the metadata quality== mickeyl: improving the metadata quality. holger. zecke: i see we have already talked about it. the biggest issue is random breakage for platforms and machines, e.g. bitrot and so on. The autobuilder should make us aware of that problem. koen: the historical crap in recipes is amazing. e.g. workaround for packages that use too new autotools, were "too new" means 2.59 [koen brings up the idea of splitting into .bb collections] stelios: metadata quality means that we have to go over all things koen: means actually two things: a) does it work, b) does it conform to our policies. b) is a lot of manual work stelios: let's do a) first. koen: like the asterik recipes that say "architecture is arm" [a webinterface is discussed like packages.gentoo.org] koen: the problem is that we want to show the metadata, but that is distribution specific, so we would have to use the reference implementation which is angstrom stelios: some amount of the packages, which work on angstrom, and then I try them on my own, and they don't build. it's a really long list koen: sometimes it's insidious, because the makefile is broken. and then we copy over that makefile and the new makefile just says arm [combinatorial explosion of building all packages in all version against all providers is briefly discussed] [Crofton brings up the issue of having machines to test on. and then when a vendor says "it's broken on my machine" tell them "it's working on these machines because we have those machines and can test on them, can you help us get your machines?"] stelios gave: http://rafb.net/p/ULib3M88.html (list of packages which does build in OPLinux) koen: has someone already added the QNX kernel to OE? That would be a nice gimmick mickeyl: [refering to stelios' list] interesting but tough to maintain stelios: yes, but we need it koen: we could modify the autobuilder to write out a BBMASK [koen points out a gpl violation in OpenMoko phase 0. mickeyl suggests to blame the gpl-violations.org president] ==Meta SDK vw meta-toolchain recipe== mickeyl: now that we have a pretty good working meta-toolchain, we should get rid of the meta-sdk stuff unless someone really needs it crofton: could anyone who understands that write documentation on the meta-toolchain stuff, please ==Machine database== ?: what this "machine database" thing mickeyl: i wanted to talk about that machine database stuff from the mailing list, no actually it's called different, how does poky call that, oh right "formfactor" [koen and RP talk about the differences between angstrom and poky with regard to X11 and startup and session scripts] mickeyl: We have a lot of work to do florian: are we allowed to lie about the screen resolution? [hrw points out that machine database is not only about screen resolution but also about choices of x-servers and so on] [talks about leaving for dinner now, should we take a tram?] 15 minutes left to talk discussion about how to work out the staging layout mickeyl, koen, RP to sit together at dinner and make it work mickeyl doesn't want to merge the Dreambox but wants to see it merged koen : [REDACTED]