[01:58] Pretto: :P [01:59] :> === ubott2 is now known as ubottu === davidm_ is now known as davidm === greeneggsnospam is now known as jsgotangco === YDdraigGoch is now known as Richie === robbiew is now known as robbiew_ === swoody_ is now known as Guest43907 === porthose_ is now known as porthose === dholbach_ is now known as dholbach [10:00] * persia peers about [10:01] pleia2: very quiet... [10:04] czajkowski: I'm expecting https://wiki.ubuntu.com/Membership/RegionalBoards/AsiaOceania to start soonish [10:05] persia: I gathered that [10:05] usually they're here before ye guys asking when does it start. [10:06] Indeed :) [10:10] Well, I don't think we'll have the meeting. 10 minutes in and the candidate isn't present (and hasn't been), and no quorum. [10:11] (or maybe we'd have quorum if people were poked, but no point without a candidate) [10:13] heh [11:05] persia: hi, was sprinting, so tz fail. [11:05] but it looks like it didnt matter anyhoo [11:21] lifeless: Didn't matter at all, as it turns out. [11:36] :) === JamieBennett1 is now known as JamieBennett [12:59] * GrueMaster adjusts toothpicks in eyelids for better reading. [13:00] *yawn* [13:00] #startmeeting [13:00] Meeting started at 07:00. The chair is NCommander. [13:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:00] morning all [13:00] morning :) [13:01] * NCommander pokes dyfet davidm persia ogra GrueMaster [13:01] I'm already here. [13:01] pokes back [13:01] * NCommander also pokes StevenK [13:01] * ogra falls over [13:02] Hello NCommander [13:02] morning davidm [13:02] * asac waves [13:02] hey asac [13:02] hey asX [13:02] lol [13:02] damn keyboard [13:03] hey asac [13:03] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091110 [13:03] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091110 [13:03] hope you don't mind if i lurk to touch base this meeting ;) [13:03] [link] https://wiki.ubuntu.com/MobileTeam/LucidSpecifications [13:03] LINK received: https://wiki.ubuntu.com/MobileTeam/LucidSpecifications [13:03] * NCommander waits another minute for everyone to appear before starting [13:04] NCommander: The first spec (yours) has a dead link [13:04] fail [13:05] * NCommander forgot to fix its URL when I renamed the specs ... [13:05] mobile-lucid-arm-alternate-images [13:05] Fixed [13:06] * NCommander notes for the firs ttime since I attended this meeting, there are NO action items [13:06] [topic] Specification Review [13:06] New Topic: Specification Review [13:07] [topic] ARM: properly support alternate images in addition to live (NCommander) [13:07] New Topic: ARM: properly support alternate images in addition to live (NCommander) [13:07] Registered in Launchpad, and I wrote out a basic spec for it outlying the basic jest of it for quick completion during UDS [13:08] [topic] ARM: 2D launcher for UNR (JamieBennett) [13:08] New Topic: ARM: 2D launcher for UNR (JamieBennett) [13:08] grr [13:08] * ogra_ wonders how his reconnct moved to that inconvenient time :/ [13:08] Mostly done apart from action items === fader|away is now known as fader_ [13:08] [topic] ARM: Device Tree support (JamieBennett) [13:09] New Topic: ARM: Device Tree support (JamieBennett) === ogra_ is now known as ogra [13:09] This is half done, finishing it today. [13:09] [topic] ARM: lightweight webkit based browser (dyfet) [13:09] New Topic: ARM: lightweight webkit based browser (dyfet) [13:09] This might be a firefight at UDS :) [13:09] dyfet, I'll bring my bunker gear [13:09] * ogra is testing midori since a week ... [13:09] what alternatives are currently tested for browser? [13:10] * NCommander has been using Chrome [13:10] could someone pick up epiphany [13:10] anyone tried to build the latest chromium dailies? [13:10] ogra, epiphany-webkit, or epiphany-gecko [13:10] I have looked at chrome. I added to the spec what I think are the requirements for something to be selected [13:10] epiphany-webkit is the only thing that exist in karmic [13:10] True [13:10] I can look at epiphany [13:10] asac, chromimium for ARM might be a good idea, if someone is willing to sacrifice a goat to compile it. [13:10] its a bit immature with rough edges, but i think that would be sorted in lucid timeframe [13:11] I agree it is a possibility [13:11] NCommander: you have a native ppa, right? can you try to just copy the latest dailies there? [13:11] NCommander, doesnt matter ... for now we should simply get an impression on the usability issues of $browser vs firefox [13:11] asac, won't work, the build system I believe requires cross-compilation due to a dependency on ia32-libs [13:11] NCommander: afaik we fixed that [13:12] i remember that we had that spinning in some ppa [13:12] asac, someone should update the wiki ;-). Poke me after the meeting, and I'll be glad to kick it into my PPA [13:12] right ... will do [13:12] [action] ogra to report back on midori usability [13:12] ACTION received: ogra to report back on midori usability [13:12] in any case each of us should test one of the available briowsers for a few days [13:12] [action] NCommander to report back on Chromium Browser's usability [13:12] ACTION received: NCommander to report back on Chromium Browser's usability [13:13] to see the difference in handling etc [13:13] [action] dyfet to report back on epiphany-webkit's usability [13:13] ACTION received: dyfet to report back on epiphany-webkit's usability [13:13] Anyone else want anything? [13:13] do we have others? [13:13] (not on arm yet, just to see how they work differently, so we can bring impressions to the discussion) [13:13] plars, Internet Explorer in WINE [13:13] * NCommander runs [13:14] NCommander, that will only work if we have wubi for ARM :P [13:14] ok, serious options? [13:14] dunno, dont we have a virtual package you can search for ? [13:14] plars, Konquerer is KHTML based [13:14] * ogra tries x-www-browser [13:14] probably worth looking at [13:15] not really as an alternative across all images though [13:15] I can look at it, but probably overkill if we are not using the kde libs for anything else [13:15] Or Fennec, which is what Maemo 5 uses [13:15] nope [13:15] ogra, I just bring it up as a possibility due to the fact its a different rendering engine [13:15] they use firefox with nokia hacks in maemo5 [13:15] no fennec [13:15] and fennect is unusably slow on my n900 [13:15] Oh, then I'm out of date [13:16] the maemo browser is cool though [13:16] i really like it [13:17] for fennec: i think we would need to do an up-to-date fennec to tell whats right or wrong ... the archive version is outdated, because everything newer needs not released xulrunner [13:17] would be worth getting it into the archive imho ... but i'm nopt sure all nokia patches are public [13:17] asac, I think for this, we could accept hand-compiled packages [13:17] asac, for purposes of evaluation [13:17] yeah. should be possible to get fennec up somewhere [13:17] well, i tested the very latest fennec on the n900 when i got it ... which is about 4 weeks ago [13:18] and it was compiled optimized for the platform already ... still to slow though [13:18] hmm... ok [13:18] The problem is gecko is a bit of a memory hog [13:18] but we should indeed test it on *our* arches [13:18] n900 is nothing we actually care for officially ... [13:19] so is someone eager to try fennec for a few days ? [13:19] asac, would you like the action item to test fennec? [13:19] right. i think we should at least check it .... also i can ask someone who i think still works for nokia on heir browser [13:19] NCommander: i have no hardware ;) ... i can take action to check how to build the latest and make a package if thats feasible [13:19] getting their maemo browser in would rock for handheld devices ... [13:20] i'm not sure it provides anything we could benefit from on the desktop though [13:20] ogra, I'd like to know how they got Gecko to run so smoothly [13:20] asac, usability testing to give a rundown during the BoF is the most intresting part atm [13:20] i dont think you need to test on armel right now [13:21] (and indeed we should get you HW ASAP) [13:21] davidm, ^^^ [13:21] ok. i can do that [13:21] NCommander, they separated rendering from display [13:21] right [13:21] i can also take action to talk to the nokia guy i think would know what they did to gecko ... but unlikely to test the maemo browser myself before UDS [13:21] Interesting [13:21] [action] asac to test fennec and report back [13:21] they render the whole site in advance in ram and then have a panning window for the offscreen site [13:21] ACTION received: asac to test fennec and report back [13:22] [action] asac to talk to Nokia on their optimizations to gecko [13:22] ACTION received: asac to talk to Nokia on their optimizations to gecko [13:22] move on ? [13:22] anything else on this spec? [13:22] [topic] ARM: Per SoC Power management improvements (ogra) [13:22] New Topic: ARM: Per SoC Power management improvements (ogra) [13:23] meh [13:23] ugly one ... [13:23] i'll felsh it out more but there isnt much i can add yet before i get something from the vendors [13:23] *flesh [13:23] [topic] ARM: Sleep/hibernation support and testing (ogra/GrueMaster) [13:23] New Topic: ARM: Sleep/hibernation support and testing (ogra/GrueMaster) [13:23] i hope we have enough of them in place at UDS for input [13:24] * GrueMaster follows ogra's lead. [13:24] same thing ... we dont have armel HW with batteries at all yet [13:24] [topic] ARM: Make gcc default to ARMv7 and Thumb2 (ogra) [13:24] New Topic: ARM: Make gcc default to ARMv7 and Thumb2 (ogra) [13:24] so resume from suspend might be tricky to test at all [13:24] hibernate will definately work [13:24] NCommander, that one should be removed [13:24] ogra: we don't need batteries for sleep/hibernation testing. [13:24] its was moved to doko_ already and i think its already implemented [13:25] ogra, wooo, first spec implemented! [13:25] GrueMaster, we need support for the power button to wake up the thing [13:25] yes, but that shouldn't have any thing to do with battery or not. [13:25] [topic] ARM Softbootloader (NCommander) [13:25] New Topic: ARM Softbootloader (NCommander) [13:25] * NCommander coughs [13:25] As long as it shows up as an acpi event. [13:26] GrueMaster, hibernate should theoretically work though (since that resumes from a normal bootprocess) suspend needs additional kernel side support [13:26] GrueMaster, this is ARM, no ACPI [13:26] yeah [13:26] What little power management we have is APM based I believe [13:26] There's APM, which tends to work [13:26] call it "PM" event :) [13:26] persia, good to see you back btw :) [13:26] ok, still learning the arm stuff. [13:27] ACPI is BIOS based ... no BIOS on arm [13:27] GrueMaster, ACPI braindamage was fortunately x86/amd64 specific [13:28] NCommander, so what about softbootloader ? [13:28] The spec and blueprint have been recycled [13:28] any solution in sight ? [13:28] But we still don't have kexec() on ARMv7 so ... [13:28] This spec probably will end up deferred again until theres some change on that end [13:28] i thought it only breaks on imx51 [13:29] but works on dove [13:29] ogra, if it works on Dove, thats news to me. [13:29] i thought you said that during karmic [13:29] [action] NCommander to investigate kexec() on ARM [13:29] ACTION received: NCommander to investigate kexec() on ARM [13:29] ogra, based on the mailing list traffic, kexec is completely broken on armv7 SoCs. [13:30] well, we should test it in lucid at least [13:30] [topic] UMR: Moblin Remix Reloaded (persia) [13:30] New Topic: UMR: Moblin Remix Reloaded (persia) [13:30] can you prepare some testing mechanism we could use to check if its working or not ? [13:30] that could be part of the spec for lucid [13:31] ogra, I'm not even sure if the spec is actually needed if UEFI on ARM pops into being. [13:31] i doubt many people on the ML have the HW we look at [13:31] UEFIU on ARM needs vendor support [13:31] *UEFI [13:31] UEFI is not expected in this cycle [13:31] That's mostly a discussion item: there's a lot of stuff that still doesn't fit in the archive, and needs to have a sufficiency of interested parties. [13:32] thats as utopic as hoping for a standardized uboot across all vendors :) [13:32] UEFI might make it in the next cycle or the one after that, but not expected now. [13:32] ok, so the UEFI spec can be defferred and removed from the list? or do we still want to investigate proactively this cycle? [13:33] well, would be good to have a small overview of what it is and how we can benefit from it [13:33] I personally think we can remove it for this cycle and just talk to ARM about it since they are trying to drive it. [13:33] but beyond that i dont expect that we implement anything [13:33] * ogra wouldnt mind an informational spec [13:33] ok. so make a low prio informational spec out of it ... or defer? [13:33] asac, the later I think [13:34] asac, up to you :) make a decision ;) [13:34] We should maybe also have a spec on implementing a generic second stage bootloader (ala elilo), if UEFI isn't going to pop into existance for six months to a year ... [13:34] ok. lets defer that spec then [13:34] Works, we can talk to Dave from ARM over beers :-) [13:34] NCommander, i doubt that helps us much more than softbootloader [13:34] good idea ;) [13:35] ++ [13:35] beer++ [13:35] [topic] Establish test procedures and documentation for new hardware (plars) [13:35] New Topic: Establish test procedures and documentation for new hardware (plars) [13:35] This is basically initial testing of what works/doesn't for new boards, and documentation of whether each things works, any workarounds required, etc. [13:35] Mostly this would be targetted at new ARM devices where hardware is often in limited supply at first, but no reason why it couldn't be applied to other devices such as netbooks. [13:35] plars, we might want ot extend it to include having new SoCs in the Ubuntu installation manual ... [13:36] NCommander, any reason you skipped persia and StevenK ? [13:36] ogra, I skipped over StevenK cause he's not here. I didn't skip over persia [13:36] UMR: Moblin Remix Reloaded (persia)-space" [13:37] right [13:37] (apart from the junk on the end of the line) [13:37] :) [13:37] plars, so anything else on this one? [13:38] not unless somone has questions, feedback, etc [13:38] [topic] move debian-cd for imx51 completely to redboot-tools (ogra) [13:38] New Topic: move debian-cd for imx51 completely to redboot-tools (ogra) [13:38] needs felshing out ... but i have a detailed plan [13:38] *fleshing [13:39] A plan is good [13:39] :) [13:39] [topic] clean up d-cd armel backends to remove a ton of code duplication between imx51 and dove (NCommander) [13:39] New Topic: clean up d-cd armel backends to remove a ton of code duplication between imx51 and dove (NCommander) [13:39] This is depwait partially on ogra's spec, but I want to rip out the partitioning code from the backends and create a generic create-partition-map script [13:39] Or at least, have some sorta partitioning library [13:40] its also related to the ext2/3 spec [13:40] yeah [13:40] and in addition, if we add anymore arm+uboot SoCs, the backend's code duplication problem going to simply grow [13:41] same for other bootloaders [13:41] i dont think thats a uboot specific issue [13:41] I'll probably do some work on straighting this code out before UDS, get the low hanging fruit so the speak. [13:41] [topic] stacked squashfs builds for live images (separate rootfs and kernel/modules completely) (ogra) [13:41] New Topic: stacked squashfs builds for live images (separate rootfs and kernel/modules completely) (ogra) [13:41] yeah ! [13:42] my favorite one :) [13:42] * NCommander notes that if this spec gets implemented, I will love ogra long time [13:42] needs fleshing out (as all my specs) [13:42] and is not easy to explain in words ... [13:42] and as well is somewhat half in the foundations team realm [13:42] ogra, I'm vaguely reminded of the bundles discussion at UDS jaunty [13:43] [topic] HDD based Recovery Images (NCommander) [13:43] New Topic: HDD based Recovery Images (NCommander) [13:43] I spoke to davidm on this one. I'm going to kick it into foundations team realm, as its really theres, and not ours [13:44] right ... just wanted to ask. sounds like something the whole platform would benefit from [13:44] yeah [13:44] indeed [13:44] [topic] extX images versus vfat (NCommander) [13:44] New Topic: extX images versus vfat (NCommander) [13:44] you truncated the title on the wikipage [13:44] ogra: refresh [13:44] ogra, I fixed it [13:45] heh [13:45] This spec is multi-aspected, and part of it overlaps into the foundation team (specifically usb-creator, do we want to have that also move to extX images) [13:45] not really [13:45] I had a thought we could do what we do for UNR, and make ARM ISO images for SoCs with sane partitioning layouts [13:45] eeek ! [13:45] ;-) [13:45] please no isos on armel [13:46] its hard enough to install them [13:46] The big issue with implementation is that we need a non-root replacement for mtools [13:46] so lets not add another complex hurdle [13:46] right [13:46] And I'm not even sure what options we have [13:46] nbd can mount images in userspace [13:46] ogra, nbd? [13:46] and there are surely also fuse based solutions [13:46] yep [13:47] you can loop mount images as nbd images [13:47] ogra, right, but whatever we need has to be in hardy (or backported), and then blessed by Canonical IS [13:47] well nbd surely works for that ... for fuse we probably need something backported [13:48] ogra, the other headache is that we need ext2 images for Dove, but probably imx51 would want ext3/4, so we need to handle multi-filesystem support [13:48] (woo, fun!) [13:48] (note that nbd is not sexy but can provide a solution here) [13:48] we surely dont want ext2 at all [13:48] ogra, I plan to poke Marvell on seeing if we can figure out why u-boot won't read form an ext3 partition at all [13:48] else you end with corrupted filesystems if you just kill your live session [13:48] *from [13:49] you only need ext2 for /boot, dont you ? [13:49] the spec is for the live image partition [13:49] ogra, *shiver*, I was trying to avoid multi-partitoin images for Dove [13:49] But obviously that pipe dream just died. [13:49] its about that darn ppp package issue actually [13:49] ah [13:49] we wont need to switch to ext* if we can fix that one on vfat :) [13:50] if its just the long version string of ppp i could see if i can upload that with a more compressed version ;) [13:50] ogra, there are other reasons we may want ext* [13:50] NCommander, sure, but thats the main one [13:50] whats the problem in particular with ppp? [13:50] ogra, specifically, hardlinks being one cited both myself for lool [13:50] along with the ability for symlinks [13:50] asac, filename gets truncated by mtools [13:50] well, it's not clear to me its mtools [13:50] The hardlink/symlink thing is usually worked around by using a union filesystem from some image-within-the-image [13:51] might be parted and the fs we actually create with it [13:51] persia, ew [13:51] Alternate images also loose any symlinks that they might had [13:51] it definately needs a lot of research [13:51] I thought alternate images were designed to not need symlinks or hardlinks. [13:51] I think we need an action item, although I'm not sure what it was [13:51] it might even be that its an issue that only shows with the hardy tools [13:52] NCommander, [action] find the cause for ppp packagename truncation [13:52] [action] ogra to find cause for ppp packagename truncation [13:52] ACTION received: ogra to find cause for ppp packagename truncation [13:52] :-) [13:52] should be the first forcus for that spec [13:52] huh ? [13:52] your spec, not mine :P [13:52] [action] NCommander to find cause for ppp packagename truncation [13:52] ACTION received: NCommander to find cause for ppp packagename truncation [13:52] just giving you a hand :) [13:52] Anyway [13:52] [topic] rootstock gui (ogra) [13:53] New Topic: rootstock gui (ogra) [13:53] integrate rootstock with either ubiquity or oem-config [13:53] needs fleshing out [13:53] [topic] LSB Compliance testing (gruemaster) [13:53] New Topic: LSB Compliance testing (gruemaster) [13:54] (part of it is also covered in the "multiarch execution environment with qemu static' spec) [13:54] I think we can kill this one [13:54] It's up there. [13:54] yeah, not much point for it without moblin [13:54] Not necessarily. [13:54] I'll knock it down to wishlist [13:54] LSB != moblin. [13:54] GrueMaster, do we care without moblin? [13:54] moblin = customer for LSB testing though [13:55] We don't care much I think [13:55] This is for LSB Compliance, not Moblin compliance. This is tested on desktop. [13:55] is that LSB compliance really a mobile spec? [13:55] asac, it was for the karmic cycle [13:55] We should ask rickspenser or robbie if they care [13:55] Should we check with foundations first to see if it's something they need? [13:55] Rather than argue about whether anyone cares, let it be "low priority", which means that if anyone cares, they can do it. [13:56] * NCommander already kicked it down to wishlist [13:56] [topic] UNE(UNR) Social Networking Applets (gruemaster) [13:56] New Topic: UNE(UNR) Social Networking Applets (gruemaster) [13:57] I wanted to bring this up at UDS. Currently, UNR is the only netbook image w/o social networking software (twitter, facebook, etc). [13:57] Are you thinking something like libbickley integration, or just clients? [13:57] what do other netbook images ship for that? [13:57] Kubuntu netbook. And other distros have similar things. [13:58] some I see do so by redefining the desktop environment [13:58] asac, whatever Kubuntu netbook ships, we probably odn't want it for UNR [13:58] we have https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-default-apps and https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-social-from-the-start [13:59] The n900 uses the new Microfeed framework, maybe something to look at? [13:59] JamieBennett, on maemo5 or 6 ? [14:00] maemo5 (http://bergie.iki.fi/blog/microfeed_could_be_to_status_updates_what_telepathy_is_to_instant_messaging/) [14:00] Biggest issue I see is that UNR/UNE doesn't have the framework in place for this. [14:01] we have notify-osd though [14:01] probably you can merge parts of both [14:01] i think desktop will built on top of gwibber [14:01] which has a dbus daemon ... and a UI ... [14:01] notify-osd is a popup message displayer. [14:02] right, add a microfeed backend [14:02] ogra: thats gwibber-daemon most likely ... we could just reuse what desktop does there and see if we need more special UIs [14:02] yeah [14:02] ogra: I was thinking of something more integrated into the UI. Like Moblin and Kubuntu netbook have. [14:03] Well, unr is much more application-centric [14:03] you think notify-osd isnt integrated enough in the UI ? [14:03] ogra: notify-osd just displays the notifications ;) [14:03] :) [14:03] but the social from start spec from desktop team has the following points: [14:03] yeah, but thats the UI side [14:03] 1. Microblogging from Session menu [14:03] 2. Converge social networking accounts into "About Me", make accessible from places like Session Menu [14:03] No, it isn't. Not or some of the other widgits I see on other systems. [14:03] or am i missing any other UI elements but messages [14:03] ah [14:04] We need someway of getting the messages in too - http://microfeed.org/ has a pretty diagram. [14:04] Not to cut you off, but these are implementation detials for UDS, and we're over time. [14:04] sounds a bit like overlap between mobile and DX imho [14:04] Anything quick before I go onto the next spec? [14:05] [topic] lpia versus i386 (NCommander) [14:05] we are over time, are we overlapping with another meeting right now? [14:05] New Topic: lpia versus i386 (NCommander) [14:05] plars, not according to the calendar [14:06] This is pretty much our plan for the lpia port. Do we finally ax it or what not [14:06] [topic] Efficient testing of install images (plars) [14:06] Is there any benefit to the lpia compiler differences? [14:06] New Topic: Efficient testing of install images (plars) [14:06] This is to have a good set of tests to get good coverage of install-time options, with out having an explosion in the number of test cases [14:06] GrueMaster, what compiler differences? (we compile for i686 versus i586) [14:06] Has anything changed since last time for lpia? Is there new information that it certainly will or won't be different at an instruction set level? [14:07] [topic] UNE: replace the maximus blacklist(s) with proper info on the affected windows (persia) [14:07] New Topic: UNE: replace the maximus blacklist(s) with proper info on the affected windows (persia) [14:08] We kept the lpia alive due to potential Intel chips that might benefit from it. None have come out so I'm thinking we drop lpia, but I'll double check that [14:08] MIssed that one. I'll get something together for next week :) [14:08] how much resources does the lpia port consume? [14:08] Is this a UDS topic or just better having a conversation with Neil? [14:09] asac, if we actively maintain it its a lot [14:09] asac, its in maintenance mode right now, and fairly broken [14:09] asac, if its just idling around without anyone looking (like in karmic) not much [14:09] It would be a ton of effort to even bring it back up to installable [14:09] ok. but with dropping we mean: make it an unsupported arch (e.g. keep the whole infrastructure in place in case we need it still)= [14:09] Although it's probably worth asking the launchpad crew to turn it off for PPAs. [14:09] asac, we don't actively maintain lpia at all [14:10] asac, i think we mean wipe it completely from everywhere ... including our minds and bad dreams [14:10] * NCommander would approve of that action [14:10] * ogra would be specifically intrested in the latter :) [14:10] hmm ... for me it feels like we shouldnt completely wipe it unless we are really sure we won't need it anymore [14:11] I think that's pretty much where we were at last cycle [14:11] asac, my opinion hasn't changed since last time, but if we do need lpia due to an incompatibility of i386, then we still have to rebootstrap it and everything [14:11] which is wat davidm said he'd check on. [14:11] right [14:12] [topic] UNE: replace the maximus blacklist(s) with proper info on the affected windows (persia) [14:12] New Topic: UNE: replace the maximus blacklist(s) with proper info on the affected windows (persia) [14:13] MIssed that one. I'll get something together for next week :) [14:13] * ogra guesses thats mainly discussing with upstream [14:13] [topic] casper cleanup/speedup (JamieBennett) [14:13] New Topic: casper cleanup/speedup (JamieBennett) [14:13] yay [14:13] needs flashing out, anyone have experience with this? [14:13] I think we need to bump this to Medium, as live CD boot speed can be painful [14:13] NCommander: agreed [14:14] JamieBennett, i know casper a bit [14:14] JamieBennett: I'd be happy to help review it with you. [14:14] * NCommander knows it well enough to hit it with a sledgehammer [14:14] great [14:14] guys I have to drop off now [14:14] casper is one of the few things that really needs minimal tweaks to work for new SoCs [14:15] davidm, cya [14:15] [topic] multiarch execution environment with qemu static (ogra) [14:15] New Topic: multiarch execution environment with qemu static (ogra) [14:15] and we should come to an end [14:15] fleshing out ... [14:15] ogra, I rather finish the specs out if no one has any objections. [14:15] sure [14:15] [topic] Optimizations for SSD netbooks (dyfet) [14:15] New Topic: Optimizations for SSD netbooks (dyfet) [14:16] This spec was a result of getting a netbook with ssd. [14:16] I self documented which things I did and why to optimize it for unr. [14:16] The spec is intended to propogate this for general case users. [14:16] but sounds like very close to foundations space [14:17] It may be... [14:17] dyfet, might want to talk to mdz, he's done a lot with SSDs and boot speed I think. [14:17] and i think Keybuk too [14:17] * NCommander can't think who else has done work on this [14:17] Okay [14:17] Well, I can start by subscribing them to the spec [14:17] [topic] ARM: kernel version (NCommander) [14:17] New Topic: ARM: kernel version (NCommander) [14:17] please don't just do that [14:17] please actually come talk to me [14:18] okay :) [14:18] make sure to tie him up to a chair and bring him to the BoF :) [14:18] This is an informational spec just to make sure we have a proper roadmap for handling ARM kernels for the lucid cycle, and what versions we're going to peg various SoCs for the each stage of development [14:18] i thought that was clear already [14:18] we stick with what we have [14:19] ogra, this is more for any new SoCs we get, and what plans we have for new versoins from FSL and Marvell [14:19] 2.6.31 [14:19] no further plans to my knowledge [14:19] ogra, so ax this spec? [14:19] afaik we plan to stick with .31 for all armel [14:20] no, keep it and fill it with the actual info [14:20] ogra, ah [14:20] [topic] LXDE Community Development for Lucid (dyfet) [14:20] New Topic: LXDE Community Development for Lucid (dyfet) [14:20] so we can point users/vendors to the info [14:20] This was to track lxde efforts [14:20] since originally we did the specs for lxde for karmic [14:20] but it is now community driven [14:21] right [14:21] well, it was supposed to from the beginning [14:21] Ok, w.r.t. to items on the agenda, I have UNR status, and the status of Desktop Switcher [14:21] this also was to have a single slot for discussion in uds for lxde [14:21] we should just give it a kickoff setup [14:21] but no StevenK and no davidm, so I think these have to be a carry over [14:21] so [14:21] yeah indeed [14:21] [topic] Any Other Business [14:21] New Topic: Any Other Business [14:21] We skipped, UMR: Moblin Remix Reloaded, was that intentional? [14:22] JamieBennett, I brought it up, persia said it needed discussion with vendors [14:22] JamieBennett, well, NCommander said he didnt miss persia when i asked :P [14:22] and other people. [14:22] * JamieBennett needs more sleep [14:22] well, i have one AOB item ... [14:22] * NCommander needs some toast to put his marmite on [14:22] * JamieBennett hasn't forgot [14:22] david asks us to look over the sponsoring queue and indeed to do our merges asap [14:23] JamieBennett, i managed to buy five jars when I was in NYC 125g each :-) [14:23] I didn't say anything about vendors. I said something about interested parties. [14:23] so please everyone do some merges [14:23] persia, sorry, misspoke [14:23] NCommander: ah, cool [14:23] * NCommander has only two merges, both of which require fakesyncing [14:23] the people who are not MOTU yet, please coordinate with someone with upload privs to get sponsored uploads [14:23] NCommander, you are free to take more :) [14:24] BTW, if anyone is maintaining any package in Debian which is NOT migrating to testing, please poke me or a DD so we can fix that. Being able to autosync from testing is a good thing. [14:24] https://merges.ubuntu.com/main.html has the list in case you dont know [14:24] ogra, I'm spending some time fixing packages in Debian so they will autosync without me having to be constantly on it [14:24] https://wiki.ubuntu.com/DistributedDevelopment/Documentation [14:24] has infos on how to do it right [14:24] (KDE is for instance stuck in Debian sid) [14:25] given that we are supposed to do everything in bzr if possible [14:25] so please take a look at that wikipage and pick some merges :) [14:25] Anything else before I close the meeting down [14:26] going once [14:26] twice [14:26] Goodbye! [14:26] (sorry for the long meeting) [14:26] #endmeeting [14:26] Meeting finished at 08:26. [14:26] wow, that was 30 min over time [14:26] thanks [14:26] we need to improve here :) [14:26] ogra, our record is one hour 20 minutes over. [14:26] thanks [14:26] We still missed UNR status and Desktop Switcher. [14:27] ah yes [14:27] if someone needs help/sponsorship on getting started on merges, feel free to ping me ;) [14:27] GrueMaster, we skipped it due to ENOSTEVENK ENODAVIDM [14:27] quick question: stevenk usually does not attend this meeting, right? [14:27] i assume its the middle of the night for him [14:27] he usually does [14:27] oh [14:27] so he works like me ;) [14:28] it's what, 1:30 AM there right now? [14:28] Actually, he does. He just has a flight to leave for soon. [14:28] 1:28 in sydney atm [14:28] He has a 7am flight. [14:28] And he needs all the beauty sleep he can get. :P [14:29] we are trying to teach him to be nocturnal === robbiew_ is now known as robbiew [15:07] ogra: We do NOT create the FS with parted... [15:07] ogra: parted might create a fs, but the real FS with actual contents is dd-ed on top of it [15:09] asac: Problem with ppp is actually a problem with images containing .debs with "~" in their version number on a vfat image [15:10] hmm ok [15:10] thanks [15:10] asac: We used to release VFAT images for UNR (.img) and we are still using VFAT for arm images; ppp used to have a ~ in its version number which meant a ~ in the .deb filename; ppp was included in the pool/ in the images; however when debian-cd created the md5 list which is put on the CD, it would output a truncated filename === marjomercado is now known as marjo [15:12] asac: 360925 [15:12] asac: If you download the jaunty UNR ISO, you should see that find pool -iname ppp\* lists: [15:12] pool/main/p/ppp/ppp_245~.d [15:27] ok will check that [15:52] asac, lool, we have a good bunch of packages with ~ in their name that dont cause probs ... its the lenght of the filename in combination with ~ here [15:57] ogra, asac: Note that it's only for packages in the pool/ [15:57] Not all packages in the squash [15:57] yeah [15:57] which is why we dont hit it on desktop images [15:58] ppp is installed in the squashfs with karmic [15:58] Indeed, there are other packages with ~ in the pool on this image; it's likely not just the presence of ~ but that's certainly a trigger [15:58] yeah [15:58] http://paste.ubuntu.com/315174/ [15:58] its more than one trigger ~ is one [15:58] find pool|grep \~ [15:58] yup, i did that before :) [15:59] but i'll leave the spec to NCommander :) [16:01] ogra, lool w.r.t. to extX images, I thought part of the reason for doing that was also that having more robust filesystem would be a good thing, and we wanted to be able to take advantage of hardlinks and such. I'm looking into what causes the ppp bug, so hopefully can fix that even if we don't go with vfat images [16:02] yes, that should be one of the focus points of the spec [16:02] NCommander: Hmm yes, I think it's orthogonal [16:03] I dont think the ppp bug should be part of a spec, it's just a bug [16:03] Except it's not trivial to reproduce :-/ [16:03] lool, I'll revise the spec. As it stands now, I'm pulling down everything to create alternates locally for i386 and armel so i should be able to start locally reproducing in a few hours [16:04] Ok; admitedly I wasn't reproducing in ideal conditions (using symlinks to the ftp mirror) [16:05] lool, ogra, lets move this to a more appropriate channel :-) [16:05] -arm === fader_ is now known as fader|lunch === robbiew is now known as robbiew_ === fader|lunch is now known as fader_ === JayFo is now known as JFo === asac__ is now known as asac === robbiew_ is now known as robbiew === robbiew is now known as robbiew_ === YDdraigGoch is now known as Richie === JamieBennett2 is now known as JamieBennett === fader_ is now known as fader|away