=== amit is now known as amitk [01:52] hey [01:53] how do i get ubuntu mobile on my dell axim x5 [01:53] ? [01:54] Looks like an ARM device [01:54] it is [01:54] if she stayed a bit longer, i would have suggested familiar linux [02:12] hi [02:12] which one is for x86 ubuntu mobile from this link http://cdimage.ubuntu.com/moblin/releases/7.10/pre-alpha/ [02:16] is it the menlow_crownbeach_install-usb or menlow_full_install-usb [03:02] which one is for x86 ubuntu mobile from this link http://cdimage.ubuntu.com/moblin/releases/7.10/pre-alpha/ [03:03] ? [03:08] which one is for x86 ubuntu mobile from this link http://cdimage.ubuntu.com/moblin/releases/7.10/pre-alpha/ [03:09] anyone? [03:14] :( [03:35] which one is for x86 ubuntu mobile from this link http://cdimage.ubuntu.com/moblin/releases/7.10/pre-alpha/ [03:36] MutantB1: That depends on what hardware you have. If you have a Q1U, use the Q1U image. If you have a Menlow prototype, use the Menlow image. If you have neither of the above, you'll have to build one yourself [03:44] what is menlow prototype? im using similar specs to the eeePC [03:44] You'll need to build a custom image right now, I believe [03:44] for the chipset where using VIA VX800U [03:45] how can I do that, do i have to have ubuntu install first then follow the instructions in https://wiki.ubuntu.com/MobileAndEmbedded [07:12] good morning === doko_ is now known as doko [14:32] smagoun: still can't get the kernel, I am using this command: git clone rsync://moblin.org/repos/projects/kernel-mid-2.6.24.git moblin-kernel-2.6.24 [14:34] amitk: I tried the same thing without the trailing 'moblin-kernel-2.6.24', it WFM [14:34] hmm.. nevermind, Intel can confirm regarding the patch later this evening. === njpatel is now known as njpatel_away === njpatel_away is now known as njpatel === dholbach_ is now known as dholbach === asac_ is now known as asac [16:03] rustyl: I think you are not registered with freenode; this means all your /queries wont be visible to registered users; could it be preventing your messages to reach davidm_? [16:26] amitk: You can pull from moblin.org via rsync if http doesn't work. [16:26] Oh nevermind, I see you are using rsync [16:45] lool, yea, i know i'm not registered on freenode [16:47] rustyl, we checked the registered owner has not shown up on FreeNode in better then 3 years, if you send an email to the FreeNode folks they will likely free up rustyl for you to register. [16:47] davidm_, yea, i should do that [16:48] I had to do the same for davidm === davidm_ is now known as davidm [16:48] I have davidm, davidm_ and davidm__ registered. Makes life easier if I get bumped from my connection [16:48] * rustyl reads over the freenode FAQ === rustyl is now known as rustyl_ [16:52] davidm: did we ever come up with a solution to the beta image issue? === rustyl_ is now known as rustyl__ [16:54] Well future images will be pulled from the snapshot of both hardy and ppa so they will remain stable for quite a long time. [16:54] ok === rustyl__ is now known as rustyl === rustyl is now known as rustyl_ [16:55] So we will pull snapshots of them, then build from the snapshots so there is no possibility of getting something into the image that is not already frozen. [16:55] I think that will get you what you are looking for GrueMaster [16:55] the main thing is being able to pull devel tools into the image for developers. [16:56] like the kernel headers that match the kernel in the image. [17:01] davidm: are we having a meeting? [17:02] yeah, same question. [17:02] Yes [17:02] lool, is going to run it today [17:03] #startmeeting [17:03] Meeting started at 17:03. The chair is lool. [17:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:03] let us review last week action items [17:03] [topic] patm to to produce boot charts for squashfs vs ext3 for hardy CB by 13 March. [17:03] New Topic: patm to to produce boot charts for squashfs vs ext3 for hardy CB by 13 March. [17:04] lool, patm will not have time to start on this until next week [17:04] patm: Did you manage to generate bootcharts in both scenarii? [17:04] Ok, carrying on the action then [17:04] Good enough [17:04] [action] patm to to produce boot charts for squashfs vs ext3 for hardy CB by 13 March. [cted] [17:04] ACTION received: patm to to produce boot charts for squashfs vs ext3 for hardy CB by 13 March. [cted] [17:05] [topic] asac to provide the general algorithm for converting .po files to xpi structures and provide with example input files to mobile list email. [17:05] New Topic: asac to provide the general algorithm for converting .po files to xpi structures and provide with example input files to mobile list email. [17:05] I saw the wiki page produced by asac [17:05] Does someone have the URL? === mawhalen_ is now known as mawhalen [17:06] https://wiki.ubuntu.com/MozillaTeam/LaunchpadTranslationSupport [17:06] [link] https://wiki.ubuntu.com/MozillaTeam/LaunchpadTranslationSupport [17:06] LINK received: https://wiki.ubuntu.com/MozillaTeam/LaunchpadTranslationSupport [17:07] We got the demo files yesterday [17:07] This is material for davidm and agoliveira to work on the scripts [17:07] so we (adilson and I will get started next week) [17:07] So the action on asac is closed [17:07] yes [17:07] [topic] davidm & agoliveira to look at what asac provides and get script written by 13 March that does conversion of .po files to xpi structures. [17:07] New Topic: davidm & agoliveira to look at what asac provides and get script written by 13 March that does conversion of .po files to xpi structures. [17:08] davidm: As I understand it, you received sample data only recently and didn't have time to start on the implementation [17:08] Correct [17:08] So i'm carrying it on for next week [17:08] and adilson is on holiday until monday [17:08] Yes please [17:08] [action] davidm & agoliveira to look at what asac provides and get script written by 13 March that does conversion of .po files to xpi structures. [cted] [17:08] ACTION received: davidm & agoliveira to look at what asac provides and get script written by 13 March that does conversion of .po files to xpi structures. [cted] [17:08] [topic] kyleN to prepare a mapping of hildon source packages to gettext domains, and list where the gettext domains are in maemo. [17:08] New Topic: kyleN to prepare a mapping of hildon source packages to gettext domains, and list where the gettext domains are in maemo. [17:09] i am working on automating this. [17:09] kyleN: Did you manage to look into the maemo SVN and build such maps [17:09] Nice [17:09] carry over please [17:09] kyleN: Please get in touch with me if you're stuck on parts of it [17:09] ok [17:09] [action] kyleN to prepare a mapping of hildon source packages to gettext domains, and list where the gettext domains are in maemo. [cted] [17:09] ACTION received: kyleN to prepare a mapping of hildon source packages to gettext domains, and list where the gettext domains are in maemo. [cted] [17:09] [topic] Mithrandir to split up remaining Hildon packages that need to be upgraded amongst everybody except people who claim they are busy with other things. Loïc to get involved in this. (carryover address this week in email) [17:09] New Topic: Mithrandir to split up remaining Hildon packages that need to be upgraded amongst everybody except people who claim they are busy with other things. Loïc to get involved in this. (carryover address this week in email) [17:09] I did this this morning; sorry, it was quite late [17:10] I updated the "Assigned" people on this page: https://wiki.ubuntu.com/MobileAndEmbedded/Hildon2%2e0 [17:10] lool: great, thanks [17:10] mjg59, StevenK, agoliveira, bfiller, smagoun, horaceli and me have items on that page [17:10] I couldn't tell about hildon-help; does someone know about its status? [17:10] kyleN: ^^ [17:11] a wise man once said: if thesoftware is good you don't need help [17:11] bspencer: Thanks for giving us some horaceli cycles to work on these updates; I assigned two modules to him (as many as to other folks) [17:11] kyleN: funny coming from a tech writer :) [17:11] as far as I know there are no provision for onboard help in mobile [17:11] tech writer is only one of my hats [17:11] lool, sound fair [17:11] bfiller: The tech writer then relaxes :) [17:11] kyleN: of course :) [17:12] kyleN: but can you look into hildon-help? [17:12] I'll take a peek [17:12] gracias [17:12] kyleN: It would be nice if you could look at what it carries whether it would be useful for us etc. [17:12] [action] kyleN to look into hildon-help; what's is useful for and whether we should package it for UME [17:12] ACTION received: kyleN to look into hildon-help; what's is useful for and whether we should package it for UME [17:13] I'm not actionning everybody with assigned packages; instead I propose to add an action for us to review progress on hildon 2.0 next week [17:13] Sounds alright to the parties? :) [17:13] sounds good to me [17:14] [action] lool review progress on Hildon 2.0 updates next week [17:14] ACTION received: lool review progress on Hildon 2.0 updates next week [17:14] Anything else to add on the topic? [17:14] Okely, moving to next topic [17:14] [topic] mawhalen to follow up on when theme tools are updated, and then gen a new theme using the tools with sabotage (Shane Bryan) (carryover) [17:14] New Topic: mawhalen to follow up on when theme tools are updated, and then gen a new theme using the tools with sabotage (Shane Bryan) (carryover) [17:14] mawhalen: Are you around? [17:14] sabotage: ^^^ [17:14] lool: yes, is Shane here? [17:15] sabotage, ping [17:15] pong [17:15] sorry was in another desktop [17:16] sabotage, do you see the question above? [17:16] mawhalen and I discussed this by email, and we have a gap on the tools side...there is currently no schedule [17:16] minor clarification: the point is that moblin doesn't have up to date files needed by hildon theme tools, so you can't modify the theme using the tools [17:16] The Theme Guide is my only focus at this time [17:16] sabotage: what is the status of the guide? [17:17] still 0.6, but I've incorporated the edits from Noel [17:17] and Kyle and I chatted last week and I am adding/rearranging per his input [17:18] sabotage: can you please address my point above? [17:18] One question to all, would this be better to release as a document (PDF) or as HTML? [17:18] it's some 25 pages right now [17:18] depends on the audience, both maybe? [17:18] * sabotage reads kyleN's question [17:18] sabotage, depends on if we want collaboration. If we do, a wiki is best. [17:19] but PDF or HTML is fine if it is perfect [17:19] agreed bspencer , but we don't have a wiki ;) [17:19] +1 on bspencer [17:19] ok. so we will have a guide in some format soon... 0.7 on the way [17:19] bspencer, who do you see as the collaboration parties, the entire community or ?? [17:19] kyleN: I'm not sure I understand your point? [17:20] can you rephrase [17:20] layout.tx and tempalte.png aren't up to date, right? so you can't use hildon theme tools i thought? [17:20] correct [17:20] davidm, people who care. For now we'll release a PDF and work on the wiki aspect. [17:20] and I address that in the doc as something to be solved but we need to collaborate on it [17:20] bspencer, OK the ubuntu wiki is open as the the shared wiki [17:20] so my question is what moblin's plans are for providing up to date files needed to use hildon theme tools to modify the theme [17:21] I have several proposals, varying from making moblin themes an "add-on" over hildon, with it's own tools [17:21] to modifying hildon tools to work with more than one layout and template file [17:22] to forking hildon tools to do what we want [17:22] sabotage: Who's deciding which option you'll follow? [17:22] last option is least favorabl for hopefully obvious reasons [17:22] Are you investigating on your side or waiting for moblin or UME discussion? [17:23] I'm documenting the options with pros/cons [17:23] but it really should be decided in a broader audience [17:23] I'd love to do this all on a wiki [17:23] perhaps when you've completed documenting the options we can convene folks to review/discuss/decide [17:24] sabotage: Can we ask for a preview of the current guide and your draft comparison of the options? [17:24] mawhalen: will I need to deal with legal disclaimers and such if I put this on a wiki like I do today with the document form [17:24] sabotage: no problem, we can easily do that [17:24] sabotage: Perhaps you could send us the links to your documents on the mailing-list(s) and we would schedule a meeting to discuss the options or comment on the mailing-list or simply review them during a meeting? [17:24] sure, I offered it to folks at the PDX sprint, but only bfiller and kyleN seemed interested [17:25] lool: currently it is not on the wed, so would have to be in odt or pdf form [17:25] unless I can get approval to post in html or wiki form [17:25] I guess that's fine; you can probably attach it as a file on the wiki [17:25] (If it's ok to redistribute the pdf on the wiki) [17:25] ok, so someone direct me to the right wiki to put it on [17:26] sabotage: Create a page such as https://wiki.ubuntu.com/MobileAndEmbedded/ThemeToolsGuide [17:26] mawhalen: I'll work with you to ensure that the current version is not a risk to us, and where we want to post it [17:26] Then describe with a couple of sentences the subjects of the guide and attach it [17:27] ok, I'll figure it out lool and send a message to the list [17:27] if there is a legal issue use the shared private wiki until the lawyers can sign off [17:27] sabotage: Can we give you an action to send an intermediate version of the guide and a draft of the options for implementation as links to the mailing-list for next week? [17:27] But I hope it can just be public [17:27] sabotage: Sounds good [17:27] lool yes [17:27] And next week we can discuss how we go forward with the tpoic [17:27] ok, davidm, I'll work with mawhalen to determine where we can start with it [17:28] [action] sabotage to provide drafts of themes tools guide and implementation options as links on the mailing-list [17:28] ACTION received: sabotage to provide drafts of themes tools guide and implementation options as links on the mailing-list [17:28] sabotage, good enough [17:28] sabotage: there shouldn't be any reason this can't be posted. I see nothing stopping this and will work with sabotage [17:28] Anything else on this subject? [17:28] bfiller, kyleN perhaps? [17:28] but by next week it will either be on moblin.org, wiki.ubuntu.com or the private wiki [17:28] ok? [17:28] i have one point [17:28] I'm good [17:28] kyleN: [17:28] kyleN: Go ahead [17:29] we don't use gnome-settings-deamon in mobile so monitoring changes to gconf key that sets the current gtk-theme doesn't work [17:29] I'll look more into it for later discussion [17:29] kyleN: we have moblin-settings-daemon [17:30] ToddBrandt: it doesn't work in this respect currently though [17:30] It can perform that function if we turn the functionality on [17:30] turn it on [17:30] please [17:30] ok [17:30] :) [17:30] ok, getting risque... [17:30] You want an action? [17:30] and, which of the two possible gtk_theme keys will it monitor [17:30] or [17:30] we made our own, one sec, lemme get them [17:30] at least two [17:31] [action] ToddBrandt to turn on moblin-settings-daemon's watching of the gtk theme gconf keys [17:31] ACTION received: ToddBrandt to turn on moblin-settings-daemon's watching of the gtk theme gconf keys [17:31] /desktop/moblin/interface/gtk_theme [17:31] yea that one [17:31] this is the kind of discussion btw, that needs to happen to complete the theme guide...it's the details that I am still missing [17:31] also: /desktop/moblin/interface/icon_theme [17:31] great. [17:31] so we should capture these in the log, do we log these meetings? [17:32] sabotage: we can chat about this too [17:32] I've been experimenting [17:32] sabotage, this meeting is fully logged and recorded [17:32] ok, email me with a time to chat...I;ve been busy on other work and not on chat much recently [17:33] sabotage: I just need to know what moblin-settings-daemon should do when the gtk_theme and icon_theme change [17:33] it's in the theme guide ToddBrandt ;) [17:33] ToddBrandt: regarding gtk_theme, it needs to do essentially what gnome-settings does [17:33] ahh [17:33] sabotage, Any meeting in this channel can be monitored by mootbot :-) [17:33] ToddBrandt: I suspect you need to do the same things as gnome-settings-daemon which is to set the xsettings [17:33] (I think) [17:33] ok, I'll check out sab's doc then :) [17:33] and I sent you a copy a while back...probably should get you a newer version [17:34] soudns good [17:34] Cool [17:34] unbelievable progress! [17:34] lool, a few other things are done too, but that's the gist of it [17:34] Ok, nice [17:34] Everybody fine with moving to next topic? [17:34] yes [17:34] [topic] lool to document versioning in the ppa into wiki [17:34] New Topic: lool to document versioning in the ppa into wiki [17:34] some env vars are also changed, and the X start scripts need to be updated too [17:35] [link] https://wiki.ubuntu.com/MobileAndEmbedded/PpaVersioning [17:35] LINK received: https://wiki.ubuntu.com/MobileAndEmbedded/PpaVersioning [17:35] I cooked this rapidly, and I found it hard to summarize the key points; I'm taking critics to improve the page [17:36] I tried giving some concrete examples at the bottom for day to day questions: how do I version my upload [17:36] lool, it's a nice first cut, thanks [17:36] If there is anybody who has any question about proper versioning, please talk to me and let me try to update the page to be clearer [17:37] lool, I'll be happy to critique it. I need to understand versions better anyway [17:37] Good [17:37] Oh, I need to mention dpkg --compare-versions [17:37] (no action needed ; ) [17:38] same here [17:38] In particular, it would be nice if Moblin folks uploading to the ppa could tell me if that disrupts their workflow or if they are fine with the version numbering scheme [17:38] Ok; I'm going to move to last topic [17:38] * rustyl_ reads the link [17:39] rustyl_: I suggest you consider its usefulness when faced with your next uploads to the ppa and yell at me for the cases which are not covered [17:39] (But please read it now nevertheless ;) [17:39] [topic] overwriting changes in ppa packages, revisit this topic next week with Intel developers present. [17:39] New Topic: overwriting changes in ppa packages, revisit this topic next week with Intel developers present. [17:40] Ok, last week we briefly complained on this front, but most Intel folks where away [17:40] cause we knew you'd be complaining [17:40] so we hid [17:40] Naturally [17:40] ok, i'll read through it... but right off the bat i don't see documentation about dealing with moblin packages (i.e. stuff that is not in hardy, and that we don't add ubuntu specific patches, but just keep uploading the next version right off moblin) [17:40] rustyl_: That's actually also what creates the problem we should discuss now [17:41] Basically Moblin folks have commit access to moblin git repositories and do changes their; it's their canonical source tree [17:41] Then, they decide to publish and push to the ppa [17:41] from the sprint... my understanding was that for moblin packages... if you work off the moblin repositry, and upload exactly what is in the repo, then you don't have to worry about clobbering [17:41] It happened that moblin git trees where pushed as it to the ppa [17:41] i.e. you have a change, you check it into the moblin repo and the push the package [17:42] rustyl_: Well that's not true [17:42] lool, how? [17:42] The problem is other people than moblin folks are also working with the ppa [17:42] They grab packages from the ppa, change them (add a fix for instance), try to think of sending the patch immediately to moblin [17:42] again... we can change the plan, but my understanding from the sprint was that moblin development would happen on moblin [17:43] Starting from there, anything can happen: the patch can be rejected, the patch can be forgotten for a while etc. [17:43] lool, if they send a patch to moblin they can get a quick turn-around on us uploading to moblin and pushing a new version to ppa [17:43] sometimes. [17:43] Not always. [17:43] but if the patch is not moblin-friendly or whatever, then you are right that it can stall [17:43] bspencer: part of the problem is sometimes we need a quicker turnaround [17:43] rustyl_: It's entirely possible to do it like this, but IMO that's only feasible if anybody can commit to the canonical source [17:43] bspencer: That's in the perfect world, but you can't guarantee it [17:43] so we've been pushing the fix to the ppa and sending patches to moblin [17:43] bfiller, I know where you are coming from. When we have a patch, we want it quick [17:44] bspencer: It might happen that late night hacking are pushed to the ppa first and the patch only comes the next day leaving plenty of time for another push to happen from another source [17:44] ok... so suggestions? [17:44] possible solution: can some canonical people have commit access to git like you guys have to launchpad projects? [17:44] if I update a moblin package, how will I know if I should push it to the PPA? [17:44] Either 1) give commit access to ubuntu-mobile members to all moblin git trees: allows to commit to the canonical source tree immediately all the time [17:45] OR 2) never push directly from git to ppa, always check what the ppa carries and merge with what you planned to upload [17:45] OR 3) move to bzr haha [17:45] 3) +1 ;) [17:45] 1) is chaos that doesn't work [17:45] rustyl_: How so? [17:45] lool, even internally we have been tightening #1) to only a few select maintainers [17:45] rustyl_: Everybody has commit to the ubuntu-mobile bzr branches [17:46] how can you stabilize anything when you have so many hands in the pot [17:46] rustyl_: We can yell at someone committing something wrong and revert it easily [17:46] image if linus granted unfettered write access to the kernel [17:46] rustyl_: what needs to be controls is the pushes to the PPA [17:46] rustyl_: The number of hands in the pot doesn't change with limiting commit access to the trees: everybody uploads to the PPA already [17:46] rustyl_: folks needs to make sure it is tested against Hardy and works properly [17:47] rustyl_: I don't think comparing to linux is fair here [17:47] bspencer: your question is very important: when should package be pushed to PPA [17:47] rustyl_: But then, you realize everybody has upload rights to the ppa, so effectively publishing power [17:47] ok, for a minute lets talk about the anybody uploads to the ppa so you need to make sure you are not clobbering thing [17:47] I concur with the need for testing before pushing. [17:47] bspencer: I think we need strict rules around this as PPA is supposed to be stable [17:47] I guess that either we have to open our repos to write access (not our preference) or take the hit in verifying that when we push to PPA we have merged new changes (our headache) [17:47] I think it makes sense to have the same power higher in the chain [17:48] +1 on bfiller [17:48] so the idea is that a person always pulls the source package and does a diff with the real source tree? [17:48] and then merges in the changes? [17:48] bspencer: I think it would help to follow 2) if moblin at a real release process [17:48] Not particularly aimed at bspencer BTW [17:48] bfiller, you mean you don't want a broken mobile-basic-home checked in? [17:49] If moblin would say, release tarballs of its projects, without any packaging [17:49] bspencer: you could say that :) [17:49] The act of uploading it to a packaged repo could be kept separate from the upstream source drops [17:49] if all packages only applied patches (from the debian directory) then this would be easier [17:49] We could review new upstream source code drops and decide to push them separately from doing incremental packaging fixes [17:50] rustyl_: That's the plan anyway [17:50] but when people are actually modifying random files in the source then it's more difficult [17:50] rustyl_: At least for hildon packages, we decided to follow this path [17:50] but that's now what's happening right now [17:50] for example, the changes i clobbered were not in patches [17:50] rustyl_: We can make that a part of the solution [17:50] that would make me feel better [17:51] i can see just ignoring any of the package from the moblin sources... it doesn't really matter if a tarball is uploaded or not, anybody can checkout the source on a tag and nuke the debian directory [17:51] Ok; so I understand moblin as upstream doesn't want to give us commit access, we ranked 1) out definitely? [17:51] lool, no, that's not what i am saying [17:51] I think most UME folks would be in favor of 1) naturally :) [17:52] lool, we do give commit rights to people actively working on a project [17:52] Ok [17:52] The proposal to give everybody commit is rejected though, right? [17:52] lool, I am not comfortable with write access to any arbitrary person that might be working on ubuntu mobile in some form or fashion [17:52] Let's look at how we can do 2) properly then [17:53] Are there objections to the tarball releaes concept I propose? [17:53] Something like moblin commiting $next version on one side and then other people looking at whether this version is fit for the ppa? [17:53] lool: so basically you mean do an apt-get source from the ppa, make your mods, then upload the source package to ppa? [17:54] no objections other then we shouldn't wait till moblin provides tarballs... developers can just checkout the source off a tag to get a given release [17:54] bfiller: that would be the day to day process [17:54] bfiller: And if you produce an upstream patch, send it upstream [17:54] rustyl_: then the .tar.gz won't have the same md5sum, which is slightly bad. [17:54] rustyl_: assuming git projects have tags for corresponding PPA release, then don't always [17:54] rustyl_: We need tarballs in the process because of the way source packages are built (of a .tar.gz + .diff.gz usually) [17:55] rustyl_: It's best if everybody can agree on the tarball [17:55] Mithrand1r, i agree that providing tarball releases is a good idea, and moblin will do it, but i don't want people looking at me saying "we are blocked because of moblin" [17:55] rustyl_: Also, tags are not always properly done [17:55] Five minute warning...... === Mithrand1r is now known as Mithrandir [17:55] davidm: thanks [17:55] NP [17:55] one issue... who will do the initial debianization of all the moblin stuff? [17:56] rustyl_: agreed. How about moblin always tags releases and pushes the tarball? [17:56] rustyl_: We'll just copy over the debian/ we currently use [17:56] lool, we've improved our tagging. If you find inconsistencies, please holler [17:56] lool, ok [17:56] rustyl_: To be clean, we repack some moblin tarballs to drop the upstream debian/ [17:57] It would be top notch if moblin could be outputting tarballs without any debian/ [17:57] bspencer: Ok === Jay-laptop_ is now known as Jay-laptop [17:57] A while ago, I suggested this be codified in a moblin release process [17:57] we will also start looking into fixing up moblin to provide project tarballs with md5 sums [17:57] That would be nice [17:57] Ok, how do we action that? [17:58] rustyl_: Who would be working on this on moblin? [17:58] lool, we have started tagging, but you might find a project that didn't get the memo... which would be a bug [17:58] We also need to pass the word to developers / packagers [17:58] rustyl_: Ok, will report as I see git [17:58] *fit [17:59] One minute warning [17:59] Can extend if necessary, just letting everyone know. [17:59] Everybody agrees that we want moblin to move to an unified (documented?) release process where they output tarballs without debian/ and people with upload rights to the ppa check each new upstream release before upload? with debian/patches/ in the source packages [17:59] (I propose we extend by 10 minutes max to list actions) [17:59] lool, i agree [18:00] rustyl_, we have a big mtg at 10 [18:00] I propose an action to document the release process at moblin [18:00] no? [18:00] Who would take it on moblin side? [18:00] I can help, but I can't bless it [18:00] * rustyl_ you can assign the action to me [18:00] [action] rustyl_ (+ lool if necessary) document release process for Moblin modules [18:00] ACTION received: rustyl_ (+ lool if necessary) document release process for Moblin modules [18:01] We revisit this next week and spread the word about the new processes? [18:01] sounds like a plan [18:01] Cool [18:01] Anybody got something to add on the topic? [18:02] Perfect, everybody is happy! :-P [18:02] Any other last minute topic? seems not [18:02] About to close the meeting... [18:02] Thanks to everybody for attending! [18:02] [endmeeting] [18:02] * rustyl_ runs to the next meeting [18:02] #endmeeting [18:02] Meeting finished at 18:02. [18:03] Thanks lool for running this thing [18:04] * lool leaves for dinner [18:05] * ToddBrandt gets breakfast [19:28] lool: if I'm on https://launchpad.net/~ubuntu-mobile, choose bugs, how do I see the UME tag? Maybe I'm not in the right place? thx. [19:32] lool: or maybe that is a really stupid question since when you choose bugs it says - Bugs related to Ubuntu Mobile and Embedded developers [19:32] lool: so never mind === nrp_ is now known as nrp [20:05] mawhalen: The ume tag is global to the Ubuntu packages [20:05] mawhalen: let me forward the email I sent to Don [20:06] mawhalen: There you go [20:06] mawhalen: You can see the tags on https://bugs.launchpad.net/ubuntu [20:06] (there are too many tags to show on https://bugs.launchpad.net/ [20:07] Does Mohamed Abbas IRC? === matt_c is now known as not_matt_c === not_matt_c is now known as matt_c [21:16] mawhalen, are you there [21:26] patm: just back [21:27] patm: I was just going to go ping Jay about the cb boot issue - be right back [21:27] mawhalen, thanks [21:27] I was trying on moblin channel [21:30] patm: there is a private bug but someone was going to open a ume bug, so I'm tracking it down [21:31] mawhalen: I opened that bug (in image creator), someone at Intel made the bug private without explanation [21:33] smagoun: patm I'm going into a meeting, will follow up on email [21:34] mawhalen, bug says bios v69 resolves the issue [23:34] hello [23:34] Just curious...what is the status of ubunut mobile [23:34] anybody using it and on what devices?