[12:40] <bbgoll> hey everybody
[12:40] <bbgoll> when would be next ubuntu meeting for Asia memebership?
[12:41] <bazhang> on fridge.ubuntu.com ?
[12:41] <bazhang>  /calendar
[12:42] <head_victim> Their wiki said 4th Jan so not sure how frequent they're meant to be
[12:42] <bbgoll> that is why I am asking!
[12:43] <bazhang> 2/1/2011
[12:43] <bazhang> next week from what the calendar says
[12:44] <bbgoll> what time?
[12:44] <bazhang> http://fridge.ubuntu.com/calendar  <--- bbgoll have a look
[12:44] <bbgoll> ok, lets have a look on cal
[12:45] <bbgoll> ohh
[12:45] <bbgoll> tnx
[12:45] <bazhang> welcome
[12:49] <dingDong> what meeting I should join for gaining membership?
[12:51] <head_victim> dingDong: have a read of https://wiki.ubuntu.com/Membership/
[12:51] <dingDong> yep
[12:52] <dingDong> I did, I mean, I am in Asia, which meeting in (fridge cal) should I join?
[12:53] <ogra> the EMEA meeting
[12:55] <dingDong> ok, thanks
[15:48] <bbgoll> I did read the ubuntu membership and did the procedure + editting the wiki page for being next meeting candidate!
[15:48] <bbgoll> is here anything else which I should do? except being present at the meeting?
[15:48] <highvoltage> that's pretty much the procedure, yes
[15:49] <highvoltage> it's also a good idea to prepare a short introduction to yourself that you can paste when it's your turn to present yourself
[15:49] <bbgoll> ok, then ?
[15:50] <highvoltage> then you'll get membership or not get membership, based on your current contributions and history with the project
[15:51] <bbgoll> haha, tnx anyway
[15:51] <ogra> a good quality wikipage helps ;)
[15:51] <highvoltage> it's also a good idea to have people who have worked with you and your sponsors (if applicable) present during the meeting
[15:53] <bbgoll> hmmm, good Idea, lets c
[16:03] <robbiew> o/
[16:04] <cjwatson> yo
[16:04] <barry> howdy
[16:04] <robbiew> #startmeeting
[16:04] <MootBot> Meeting started at 10:04. The chair is robbiew.
[16:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:04] <jhunt> hi
[16:05] <barry> bug 665740 (c-j sru); bug 688732 (reviewed; python-webkit); bug 685476 (mgltools); bug 706044 (daily-journal for py27); general py27 transition testing; bug 697792 (/etc/fuse.conf perms; natty, mav, lucid); bug 706051 (quickly for dh_python2); ubuntu dev guide for udd; pkgme merge proposal reviews; bug 707416 (investigated, not fixed); bug 630511 (-proposed verification)
[16:05] <robbiew> wow...it's almost like barry knew I was going to call on him
[16:05] <robbiew> [TOPIC] Lightning Round
[16:05] <MootBot> New Topic:  Lightning Round
[16:05] <barry> robbiew: repaste? :)
[16:05] <robbiew> nah
[16:05] <ev> lets play a game called get ubotu kicked for flooding
[16:05] <robbiew> ev?
[16:05] <ev> Nearly done on showing the smartest choice only in usb-creator, working on detecting hostname collisons in ubiquity, walked czajkowski through a parted bug, trying to get to the bottom of a thread issue in the pygi branch of usb-creator, fixed a race condition in the installer testing system, thought I had fixed the netbooks locking but that reappeared today so will need to pick up a usb serial cable after all, moved keyamp decision tree generation into
[16:05] <ev> (done)
[16:06] <ev> console-setup, saving some ubiquity build time, started bootcharting ubiquity and d-i component build times, looking for obvious speed ups (in support of faster unit testing).
[16:06] <robbiew> jhunt: ?
[16:06] <jhunt> Fixed lp:#706842 (we still need work done on kdm and lighdm though).
[16:06] <jhunt> Got my new USB serial console setup and then reviewed lp:#70257. Still
[16:06] <jhunt> investigating why "console=" kernel param being truncated (apw aware).
[16:06] <jhunt> Worked on lp:#672177 a bit with Clint. Spent half a day taming
[16:06] <jhunt> pbuilder: I can atlast build Upstart packages with it. Started to review
[16:06] <jhunt> Scotts Upstart branches for natty.  Basics of Upstart job visualization
[16:06] <jhunt> are in place (sent details and a few questions to Scott) - no merge
[16:06] <jhunt> request yet as I haven't written test-code, doc, etc. However, to whet
[16:07] <jhunt> your appetites, we can now auto-gen graphs like this:
[16:07] <jhunt> http://people.canonical.com/~jhunt/upstart/viz/upstart-viz-small-25jan2011.png
[16:07] <MootBot> LINK received:  http://people.canonical.com/~jhunt/upstart/viz/upstart-viz-small-25jan2011.png
[16:07] <jhunt> EOT
[16:07] <robbiew> jhunt: \o/...nice graphs
[16:07] <czajkowski> ev: \o/
[16:08] <ev> :)
[16:08] <robbiew> mvo: ?
[16:08] <mvo> did: vacation and then cross-distro meeting about application installer in Nuernberg (really good meeting); todo: land ratings&reviews in natty
[16:08] <mvo> (done)
[16:09] <mvo> (plus a bit of hacking webkit transition and software-center in between)
[16:09] <mvo> (really done)
[16:09] <robbiew> doko: ?
[16:09] <doko> natty test rebuild, prepare a gcc-4.6 test rebuild (lucas probably will do this; at this stage it doesn't make a difference if it's done on Debian or Ubuntu), prepared various security updates, LO updates (THE LAST ONE BEFORE THE NEW MAINTAINER JOINS ... HUA HUA!!)
[16:10] <robbiew> doko: whoohoo!
[16:10] <robbiew> lol
[16:10] <doko> will be away the next two weeks
[16:10] <doko> done
[16:10] <robbiew> psurbhi: ?
[16:10] <psurbhi> * worked on https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/579858
[16:10] <psurbhi> * worked on creation of btrfs subvolumes and mounting them during installation, for aiding automatic snapshots. Considered that /home is a separate partition, as this made things easy. This week, need to work on creating a subvolume for home, when home is not a separate partition. Testing this takes a little time :(
[16:10] <psurbhi> (done)
[16:12] <robbiew> cjwatson: ?
[16:12] <cjwatson> done: finished d-i rebase onto git (except for debian-installer package itself, and some pending bzr-git problems); finished sorting out live CD upgrade problems in lucid (#591207); other 10.04.2 bits and bobs; packagekit/qapt fix for mysterious dpkg errors and empty apt term.log files (#680328); GRUB multipath backport to lucid (#687501); making progress on console-setup upgrade breakage (#698263), fixed for new ...
[16:13] <cjwatson> ... upgrades now but need to clean up the wreckage too
[16:13] <cjwatson> todo: plymouth framebuffer-switch handling (carried over); whatever comes up for alpha-2
[16:13] <cjwatson> --
[16:13] <mvo> thanks cjwatson for the packagekit/qapt fixes!
[16:13] <robbiew> thnx
[16:13] <robbiew> [TOPIC] Natty
[16:13] <MootBot> New Topic:  Natty
[16:13] <robbiew> Alpha 2 next week
[16:13] <robbiew> http://people.canonical.com/~pitti/workitems/natty/canonical-foundations-natty-alpha-2.html
[16:13] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-foundations-natty-alpha-2.html
[16:14] <cjwatson> also https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-01-21#Foundations
[16:14] <cjwatson> that's not updated dynamically, some of them have been fixed
[16:14] <robbiew> mvo: you going to finish your ToDos in time?
[16:14] <mvo> oh, I need to cleanup the rnr stuff
[16:14] <robbiew> or should we look at postponing
[16:14] <robbiew> ah
[16:14] <robbiew> cool
[16:14] <mvo> quite a bit if done but not marked as such
[16:14] <mvo> sorry for that
[16:14]  * robbiew ignores mpt and isd workitems
[16:14] <cjwatson> that's good to hear :)
[16:15] <mvo> ignore++
[16:15] <mvo> ;)
[16:15] <cjwatson> I was beginning to get a bit itchy about the work item count
[16:16] <cjwatson> http://people.canonical.com/~platform/workitems/natty/canonical-foundations.html shows us below the trend line again, with pretty much a flat line for the last week :-(
[16:16] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-foundations.html shows us below the trend line again, with pretty much a flat line for the last week :-(
[16:16] <cjwatson> well, on the trend line, I can't quite see
[16:16] <robbiew> yeah...all in all, we're doing fine
[16:16] <robbiew> https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-01-21#Foundations does have a good number of bugs though :/
[16:17]  * robbiew is reminded to finish scrubbing mvo's bug assignment list :D
[16:17] <mvo> thanks for that btw robbiew, I owe you [ ] beer [ ] tea
[16:17] <cjwatson> heh, I did a bit of scrubbing on my list, though it still needs work
[16:17] <cjwatson> below ev now \o/
[16:18] <robbiew> cjwatson: whoohoo
[16:18] <robbiew> [TOPIC] AOB/GoodNews?
[16:18] <MootBot> New Topic:  AOB/GoodNews?
[16:19]  * robbiew avoided jury duty yesterday!!!!
[16:19]  * mvo got some new (and delicious) tea today
[16:19] <cjwatson> I've said I'm standing down from the DMB at the end of my term (next month); one more free hour a fortnight ...
[16:20] <robbiew> http://webapps.ubuntu.com/employment/canonical_SE%20UP%20RW%2001-01/
[16:20] <MootBot> LINK received:  http://webapps.ubuntu.com/employment/canonical_SE%20UP%20RW%2001-01/
[16:20] <robbiew> we're hiring for foundations
[16:20] <mvo> http://people.canonical.com/~mvo/tmp/sc-meets-debtags.png <- playing with tag suggestions for debtags
[16:20] <robbiew> :D
[16:20] <MootBot> LINK received:  http://people.canonical.com/~mvo/tmp/sc-meets-debtags.png <- playing with tag suggestions for debtags
[16:20] <ScottK> dh_python3 got some good new capability this last week due to working with POX on sip4 in Debian (all in Natty too).
[16:21] <robbiew> nice!
[16:21] <barry> ScottK: awesome
[16:22] <robbiew> #endmeeting
[16:22] <MootBot> Meeting finished at 10:22.
[16:22] <robbiew> thnx all!
[16:22] <cjwatson> ScottK: http://packages.qa.debian.org/p/python3-defaults/news/20110119T184733Z.html and http://packages.qa.debian.org/p/python3-defaults/news/20110120T224725Z.html I guess?
[16:23] <psurbhi> thanks robbie
[16:23] <doko> fastest meeting this year =)
[16:23] <ev> thanks
[16:23] <jhunt> thx
[16:23] <ScottK> cjwatson: Yes.
[16:23] <cjwatson> doko: you keep stats? :)
[16:23] <mvo> thanks
[16:24] <czajkowski> robbiew: should chair allmeetings
[16:24] <czajkowski> soo productive
[16:24] <robbiew> ummm...no
[16:24] <ScottK> cjwatson: http://packages.qa.debian.org/p/python3-defaults/news/20110106T210912Z.html as well (sip4 took a while).
[16:25] <czajkowski> robbiew: I only ever tune into yours, I know full well they wont run for a crazy length!
[16:25] <ScottK> robbiew: Better mess it up next time then.  Three hour meeting.  You'll never have to do it again.
[16:25] <cjwatson> /usr/lib/python3/dist-packages/> excellent
[16:25] <robbiew> ScottK: lol
[16:26] <barry> cjwatson: it's a beautiful sight
[16:26]  * cjwatson still remembers the hoary kickoff meeting ...
[16:26] <cjwatson> four hours, I think that way
[16:26] <cjwatson> *was
[16:26] <maco> doko: first meeting this year as well?
[16:26] <czajkowski> cjwatson: can't have been productive
[16:26] <cjwatson> not by the end
[16:27] <cjwatson> we've learned a bit since then ...
[16:27] <doko> maco: no, not that bad ...
[19:13]  * stgraber waves
[19:16] <highvoltage> hi
[19:16] <stgraber> hey everyone !
[19:16] <stgraber> 20:14 < highvoltage> well, we have some seed changes, kstars has been dropped (in favour of kstars) and there's a bunch of other seed changes too but I don't have them open right  now
[19:17] <stgraber> 20:15 < highvoltage> I've been talking to LibreCAD upstream a bit off-list
[19:17] <stgraber> 20:16 < highvoltage> they are eagre to have it in Edubuntu, they're just finalising logos, etc. then I'll review it for universe
[19:17] <highvoltage> yeah I started talking there because I usually get poked in -meeting for meetings :)
[19:17] <stgraber> sorry, my bad :)
[19:17] <highvoltage> we're also shipping grokking-the-gimp and tuxguitar
[19:17] <mhall119> o/
[19:17] <highvoltage> and kalgebra is dropped in favour of geogebra
[19:18] <mhall119> kstarts has been dropped in favor of kstars?
[19:18] <stgraber> I'm currently busy updating the meta packages, I started doing it this morning but my laptop crashed (apparently I've got a kvm bug that tends to make it kernel panic)
[19:18] <highvoltage> in favour of stellarium
[19:19] <mhall119> ok
[19:19] <highvoltage> I updated the Pencil package so that it says "Pencil" in the menus now instead of "pencil"
[19:20] <highvoltage> and updated the calibre package so that LRF viewer now uses the calibre icon until it has its own icon
[19:20] <highvoltage> (so the menus look a bit better now)
[19:21] <stgraber> ah right, still need to re-upload arkose, to fix the same issue
[19:21] <highvoltage> we have an "akonadi tray" entry under accessories and a kde data backup tool unders system tools that we need to disable
[19:21] <highvoltage> then our menus should be good
[19:22] <stgraber> highvoltage: what's the usual format again ? (I don't have a menu anymore ;))
[19:23] <highvoltage> stgraber: for the menu entries?
[19:23] <stgraber> yep
[19:23] <stgraber> Name field in a .desktop
[19:24] <highvoltage> in the Ubuntu menus it's just the name of the application without description
[19:24] <highvoltage> hmm, sometimes it does (like in the graphics menu): http://launchpadlibrarian.net/62372790/pencil.png
[19:25] <mhall119> .desktop has fields for both name and description
[19:25] <stgraber> ok, so if I go with "Arkose Desktop Application Sandboxing" it'd kind of respect what we have at the moment ?
[19:25] <highvoltage> yep
[19:26] <stgraber> as I don't really have an identifiable icon, just going with the name probably wouldn't be enough
[19:26] <highvoltage> it would be consistantly inconsistant with our current menus
[19:26] <mhall119> Ubuntu's naming seems to be "App name plus descriptive" if the app name isn't descriptive on it's own
[19:26] <stgraber> ok, pushing new package now
[19:26] <highvoltage> and consistant with ubuntu's usual application menus as mhall119 points out
[19:26] <mhall119> so "Simple Scan" is just that
[19:26] <mhall119> while Gimp is "Gimp Image Editor"
[19:27] <highvoltage> some applications could really do with short descriptions like that.
[19:28] <highvoltage> calibre would be much nicer as "calibre e-book reader"
[19:28] <mhall119> yeah, they're supposed to, according to something from Canonical I read a while ago and don't have a link to
[19:28] <mhall119> probably the ones in main all do
[19:28] <highvoltage> mhall119: indeed
[19:28] <mhall119> it might be good to make it an action item to make sure all the ones in ubuntu-edu-* are named accordingly too
[19:29] <mhall119> since it's such a minor change
[19:30] <highvoltage> that's pretty much all of them then
[19:30] <mhall119> though I'm not sure how you'd name gCompris
[19:30] <mhall119> maybe it doesn't work as well for games
[19:31] <highvoltage> "gCompris Kindergarden Suite"? not sure but we should be able to come up with something :)
[19:31] <mhall119> or Tux Math
[19:31] <highvoltage> I think in Fedora it used to say "GCompris - I have understood"
[19:31] <mhall119> yeah, that's the translation from French of the pronunciation
[19:31] <mhall119> but it isn't really a descriptive of the app
[19:32] <highvoltage> yep
[19:32] <highvoltage> I think tuxmath, tuxpaint is in the same category as libreoffice
[19:32] <highvoltage> the libreoffice menu items just say "LibreOffice Draw" and "LibreOffice Impress", etc
[19:32] <highvoltage> so they seem to be descriptive enough to not need more of a description
[19:33] <mhall119> hmmm,I have "Open Office Presentation" instead of "Open Office Impress"
[19:33] <highvoltage> FreeMind would be a lot better as "FreeMind Mindmap Editor" or something like that
[19:33] <mhall119> yeah
[19:34] <highvoltage> maybe the libreoffice packages still need the menu patches. it's probably still the same as in debian
[19:35] <mhall119> could be, yeah
[19:35] <stgraber> it's actually quite bad that we need to patch the .desktop files for that, it'd probably be better to just have some package shipping all the updated .desktop files
[19:35] <highvoltage> one thing that I'd like to squeeze (heh) in before the 2nd alpha is try to fix our panel icons so that they fit in better
[19:35] <stgraber> that way you have one package to centralize all the translations and do the name/description standardization
[19:36] <highvoltage> stgraber: how would you do that? with some kind of menu profile? diverts? or is there a nice way of doing it already?
[19:36] <highvoltage> stgraber: I'd also kind of dread having to update so many packages just for menu entries :)
[19:36] <stgraber> just put all of the translated/patched .desktop files in some directory /usr/share/ubuntu-applications/ for example and change the XDG order to have them match first
[19:37] <highvoltage> ok
[19:37] <stgraber> if the binary isn't there, they won't show up, if it's there and there's a custom .desktop it'll apply, otherwise the one from /usr/share/applications will be used
[19:37] <stgraber> that's what we do for ltsp-localapps and it works quite well
[19:37] <highvoltage> I'll just poke you for the translations stuff, I'm not sure how that works
[19:38] <stgraber> remember when I told you we could quite easily ship with custom menu structure and apps name, that's how I'd have done it
[19:38] <highvoltage> ok
[19:39] <highvoltage> I blogged about our YouTube channel and we got a whole bunch of new YouTube subscribers (haven't counted them yet though)
[19:40] <highvoltage> besides that I don't think I have anything else to report on, Alpha 2 is just around the corner so we'll just have to test those images so that they can be released and do the usual alpha 2 announcements, etc
[19:41] <mhall119> I've got a few Qimo updates
[19:41] <mhall119> if you're done
[19:41] <highvoltage> I am
[19:41] <mhall119> okay, first off I forked xdg-launcher to qimo-launcher
[19:42] <mhall119> qimo-launcher will remain very basic and just do what I need for Qimo
[19:42] <mhall119> but functionality wise it's done, it'll display a panel full of launchers from an XDG .menu file
[19:42] <mhall119> and now I have a custom qimo-launcher.menu file for it
[19:43] <mhall119> so, apt-get install $game will put $game in the panel automatically
[19:43] <mhall119> it currently merges anything in the Games or Education category, excluding things like card games
[19:43] <highvoltage> nice
[19:43] <mhall119> plus a couple of specific exclusions for Lernid and the cGompris admin
[19:44] <mhall119> probably the exclusions list will grow over time
[19:44] <mhall119> but for now I think it's pretty good
[19:44] <mhall119> I think all of my packages for the Xfce-based session are finished, so I should be able to start on the Gnome-session soon
[19:44] <highvoltage> nice
[19:44] <mhall119> but, debmower still isn't building a bootable ISO for me :(
[19:45] <highvoltage> I'm definitely planning to spend some time on it this Friday
[19:45] <mhall119> so for now I'm going to have to go back to unsquashing an xubuntu iso, installing my packages, and resquashing
[19:45] <mhall119> I've copied all the Xubuntu settings I rely on into /etc/xdg/xdg-qimo, so I shouldn't have any dependency on anything Xubuntu anymore
[19:46] <mhall119> and the Gnome session won't depend on anything Xfce either
[19:46] <highvoltage> I think last when I talked to you there were some files missing from the syslinux directory on the iso, I'll do it from a clean machine on Friday, I guess my laptop where I last tested it might have some packages installed that it doesn't depend on
[19:46] <mhall119> I will need a menu editor to allow people to customize the launcher panel though
[19:46] <highvoltage> ah that's mgariepy's dept :)
[19:46] <mhall119> highvoltage: yeah, pretty much everthing was missing except casper and syslinux folders
[19:47] <mhall119> I think i can slightly modify alacarte
[19:47] <mhall119> it's 99% generic XDG menu editor
[19:47] <mhall119> but for some reason they hard-coded the Applications and Settings menus into it
[19:47] <mhall119> rather than making them runtime options
[19:47] <mgariepy> mhall119, for the menu-editor, i guess edubuntu-menueditor will be ok with a few lines of changes
[19:48] <mhall119> I'll look into it
[19:48] <mhall119> thanks
[19:48] <mhall119> is it python?
[19:48] <mgariepy> mhall119, yes :)
[19:48] <mhall119> cool
[19:48] <mhall119> so, one way or another I'll have that
[19:48] <mhall119> but it'll be later in the release cycle
[19:48] <highvoltage> one important thing we should do before alpha 3 is decide whether we're going all-unity now that there'll be unity-2d for this release. and also how that's going to impact stuff like sabayon, nanny, etc. (I guess we can expect some breakage)
[19:49] <mhall119> yeah, going all Unity is going to probably abort my current plans for a gnome session
[19:49] <stgraber> I guess we should give the choice at install time as we do at the moment. What we need to choose is what we want on the live cd
[19:49] <mhall119> so, the sooner that's known, the better for me
[19:54] <highvoltage> it seems that, at least for natty, the classic gnome desktop should stay the default
[19:54] <highvoltage> and then for users who don't need all the lockdown stuff can just choose unity
[19:56] <mhall119> +1
[19:56] <mhall119> I know that, speaking to the president of System76 at UDS-N, he told me flat out that he wasn't shipping anything with Unity or Gnome Shell
[19:57] <mhall119> and that if Edubuntu didn't offer the classic Gnome, he'd have to drop it
[19:57] <mhall119> now, Unity has come a long way since then, so I don't know if he still feels that way
[19:57] <stgraber> so he won't ship 11.04 ?
[19:57] <mhall119> that was the impression I got
[19:57] <mhall119> at least not stock Ubuntu 11.04
[19:57] <maco> mhall119: i didnt realise they offered *any* options at all for distro
[19:58] <stgraber> unity in 11.04 actually works quite well, it's almost usable :) (as in, it's at least fast)
[19:58] <mhall119> maco: I think they ofer the *buntus
[19:58] <stgraber> so he'll probably reconsider
[19:58] <stgraber> I wouldn't have shipped 10.10 with unity either :)
[19:58] <maco> mhall119: well yes, but i thought it was only ubuntu, specifically.
[19:58] <highvoltage> well, it was understandable with the old unity, perhaps with all the changes and improvements he'll change his mind. they could always just make the classic desktop default if they want to
[19:58] <mhall119> no, hey's shipping 10.04 with UNR
[19:59] <mhall119> maco: yeah, it looks that way, but he did mention that he did edubuntu, I'm just not sure how you specified
[19:59] <maco> mhall119: i asked him about kubuntu before and was told no kubuntu no xubuntu, he doesnt want people to have to make that choice
[19:59] <mhall119> well we talked about Xubuntu, specifically if Unity or Shell were the only Gnome options
[20:00] <mhall119> anyway, just a thought
[20:00] <mhall119> I'm not sure how much considersation Edubuntu should give it
[20:00] <maco> well i last talked to him before the unity announcement so... obviously hes had reconsiderations to make
[20:01] <mhall119> I can't remember if we talked before or after
[20:01] <mhall119> but with 11.04, he'll have reconsiderations to make anyway
[20:01] <mhall119> I assume zareason has no problem shipping Unity
[20:02] <highvoltage> system76 does ship edubuntu, at least
[20:04] <highvoltage> ogra: unity-2d looks a lot like old unity!
[20:04] <ogra> yep
[20:05] <ogra> and runs in framebuffer with zero accelleration
[20:05] <ogra> should be good for ltsp ;)
[20:05] <stgraber> yep, though regular unity should work quite well too (haven't tested yet). Compiz worked fine before, so unity-3d should work too :)
[20:06] <ogra> if you have 3d capability
[20:06] <ogra> -2d runs on anything
[20:06] <highvoltage> I would think that unity-3d would work better on ltsp than unity-2d, but ok
[20:06] <ogra> wont be installed in natty though
[20:06] <ogra> highvoltage, how would unity 3d work on a vesa card ?
[20:07] <stgraber> ogra: I guess -2d is meant for arm boards with no available 3D drivers ? (like your laptop ? :))
[20:07] <highvoltage> it wouldn't, but I'd never suggest a thin client to anyone that can only work with vesa
[20:07] <ogra> stgraber, 2d is meant to become a fallback for 3d at some point i guess ... for natty it will be on the arm images as default
[20:07] <ogra> highvoltage, well, with 2d even the vesa client flies
[20:08] <stgraber> I guess that's mostly because of space issue on the CDs ? IIRC -2d is in QT
[20:08] <highvoltage> ogra: that's nice
[20:08] <ogra> right
[20:09] <stgraber> if it's installed, is it automatically working as a fallback ?
[20:09] <stgraber> (we can easily ship it with Edubuntu as we already have QT on the DVD anyway)
[20:10] <stgraber> so if the user chooses to use unity, he'll get it either in 2D or 3D
[20:10] <highvoltage> iirc the plan is to have Qt on Ubuntu discs as well for 11.04
[20:10] <alkisg> Hi all
[20:10] <highvoltage> alkisg: hey. an hour late again :)
[20:10] <alkisg> Hehe
[20:11] <stgraber> highvoltage: was that for 11.04 or 11.10 ? I thought it was longer term plan. QT isn't exactly light to ship and CD space is usually a big issue.
[20:11] <highvoltage> stgraber: perhaps
[20:12] <mhall119> especially with them doubling-down on Mono by making Banshee default
[20:12] <highvoltage> Edubuntu has always shipped with Qt :)
[20:12] <maco> because only one desktop has an education projection
[20:13] <highvoltage> heh, indeed
[20:13] <stgraber> yep, but it's been a long time since we really had to care about CD space :)
[20:13] <highvoltage> well there's some gnome stuff getting better now, gperiodic is quite nice
[20:14] <highvoltage> but gnome doesn't have a nice umbrella for edu stuff like kde does
[20:14] <mhall119> it doesn't for office stuff either
[20:14] <stgraber> I'd just wish for the kdeedu stuff to depend on less KDE stuff, seems to have improved lately but there's probably still room for improvement :)
[20:15] <highvoltage> yeah, I think those are more ubuntu packaging problems than kde specific problems
[20:15] <highvoltage> but luckily we have a kubuntu team member listening :p
[20:16] <highvoltage> anything else before we go back to idle in #edubuntu?
[20:16] <stgraber> nope
[20:16] <mhall119> debmower
[20:17] <mhall119> ;)
[20:17] <maco> stgraber: mostly whats going on there is that we have some giant monolithic packages for all the kde librarry stuff
[20:17] <maco> and splitting them into like 15-20 different packages would require a lot of work
[20:17] <stgraber> maco: yep, splitting stuff like kdelibs into smaller packages could make a big difference
[20:17] <mhall119> maco: IIRC, wasn't it from dependencies on a debugging library that didn't need to be depended on?
[20:17] <highvoltage> mhall119: heh, actually, I'll move that closer and look at it tonight instead of Friday then :)
[20:18] <mhall119> highvoltage: thanks, that'll make the rest of my work go much faster
[20:18] <maco> mhall119: there was one thing with the kde version of apport, but there's also the splitting out packages thing
[20:18] <stgraber> mhall119: yes, a ton of packages got pulled in at some time because of some kubuntu debug package. That's solved in natty though IIRC
[20:18] <mhall119> maco: ok, I'm not at all familiar with the goings on of KDE
[20:18] <maco> although for example i think highvoltage was saying "but it pulls in akonadi and ___ and ___" and actually it wasnt pulling in those whole things just the libraries that reference them
[20:18] <highvoltage> yeah it's more dependencies problems. like, we can't install a kde python game without getting stuff like Akonadi tray and Nepomuk backup
[20:19] <highvoltage> we get menu entries for those too, so it seems more like just libraries
[20:19] <highvoltage> then again, nothing happens when you click on them, so perhaps those menu entries are in the wrong packages
[20:20] <maco> oh thatd be intersting...
[20:20] <maco> libakonadi4 is one of the things python-kde4 pulls in for example, but thats just the lib
[20:20] <maco> python-kde4 does depend on kdebase-workspace-bin though
[20:20] <maco> er n....sorry
[20:20] <maco> kdebase-runtime
[20:21] <maco> bleh, have a play with apt-cache depends to see what i mean :P
[20:21] <maco> highvoltage: actually for that matter...could you do a "dpkg -S /path/to/desktop/entry" and see what package it is, then "aptitude why package"?
[20:21]  * mhall119 is off, gotta run
[20:21] <maco> no use for me to do it since i intentionally have kde installed
[20:22] <highvoltage> heh, aparently akonaditra.desktop comes from kdepim-runtime
[20:22] <stgraber> fun :)
[20:22] <highvoltage> also something we probably don't want (but is there)
[20:22] <maco> kdepim-runtime is a Depends of python-kde4
[20:22] <maco> so is kdebase-runtime
[20:22] <maco> because python-kde4 is one of those monolithic libraries i mentioned
[20:22] <highvoltage> personally I don't think that's very elegant
[20:23] <maco> er, monolithic packages
[20:23] <highvoltage> (sorry to drop a kde word :p)
[20:24] <highvoltage> mgariepy just asked me if this meeting is going to end any time soon
[20:24] <highvoltage> so I guess it's time to do so :)
[20:24] <stgraber> hehe
[20:24] <highvoltage> thanks everyone
[20:24] <maco> hmm i think i see why the deskto is in kdepim-runtime
[21:00] <barry> #startmeeting
[21:00] <MootBot> Meeting started at 15:00. The chair is barry.
[21:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:00] <barry> hi folks and welcome to this week's ubuntu distributed development meeting
[21:00] <barry> who's here today?
[21:01] <james_w> o/
[21:01] <barry> note that because we did the meeting last week largely in person at the natty rally, we don't yet have minutes up for the meeting on the 12th.  hopefully we won't re-cover too much ground
[21:01] <barry> [TOPIC] agenda
[21:01] <MootBot> New Topic:  agenda
[21:01] <barry> https://wiki.ubuntu.com/DistributedDevelopment/20110126
[21:01] <barry> [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110126
[21:01] <MootBot> LINK received:  https://wiki.ubuntu.com/DistributedDevelopment/20110126
[21:02] <poolie> hello
[21:02] <poolie> the raw transcript is in http://irclogs.ubuntu.com/2011/01/12/%23ubuntu-meeting.html#t21:06
[21:02] <poolie> hi james
[21:02] <jam>  /wave
[21:02] <barry> jelmer, thumper, slangasek, ajmitch, james_w ping
[21:03] <james_w> hi poolie
[21:03] <poolie> i like the hot bugs list
[21:03] <ajmitch> hi
[21:03] <poolie> i will take an action to bring that up to date for the next meeting, on the 10th feb
[21:04] <poolie> i believe a few more things have been crossed off
[21:04] <poolie> we had a two-week sprint that was very productive
[21:04] <barry> yep, thanks
[21:04] <barry> [ACTION] poolie to update hot bugs list for next meeting
[21:04] <MootBot> ACTION received:  poolie to update hot bugs list for next meeting
[21:04] <barry> i guess we'll just get started
[21:04] <slangasek> augh where did my morning go :/
[21:05] <barry> [TOPIC] action items
[21:05] <MootBot> New Topic:  action items
[21:05] <barry>   * ajmitch to come up with questions/topics for next meeting (re: REVU)
[21:05] <barry>  
[21:05] <barry> ajmitch: i forgot, did we decide to keep this on the list?
[21:05]  * ajmitch hasn't done much beyond the list that came up last time, sorry - that's probably fallen off pastebin by now
[21:06] <jam> barry: he wasn't there last time, so poolie had it stay
[21:06] <poolie> let's not just keep this thing dangling
[21:06] <ajmitch> strike it from the list or discuss?
[21:06] <poolie> ajmitch, do you have any particular things you think should be getting attention but aren't?
[21:06] <poolie> let's discuss briefly
[21:07] <poolie> if any come to mind now, let's do them in the meeting
[21:07] <poolie> otherwise if you want to nominate things, feel free to poke us any time
[21:07] <jam> ajmitch: I think the idea is that you can choose whether to bring stuff up or not, but we'd rather not have an on-going item that just never completes
[21:07] <poolie> right
[21:07] <jam> I agree that the strength of that list is that it is nice and compact and *actionable*
[21:08] <ajmitch> jam: right, I'd rather it not stay around
[21:08] <barry> agreed.  i'll strike it from the list for next week
[21:08] <ajmitch> I don't really have any actionable items to discuss about REVU at this stage
[21:08] <barry>   * poolie to send bzr rotation pitch to platform mailing list
[21:08] <barry>  
[21:08] <poolie> definitely today!
[21:08] <barry> \o/
[21:08] <poolie> ie keep it :)
[21:09] <barry> will do :)
[21:09] <jam> It seems it would be interesting to have something revu-like integrated with the Launchpad merge-proposals stuff.
[21:09] <jam> though they may not be quite similar enoguh
[21:09] <barry> [TOPIC] bugs of interest
[21:09] <MootBot> New Topic:  bugs of interest
[21:09] <barry> this list might be out of date, but let's go thru them quickly
[21:09] <barry>   * http://pad.lv/674353 - graph packages built through UDD
[21:09] <barry>  
[21:09] <poolie> a gap analysis there could be good
[21:10] <poolie> this was, specifically, that we'd insert markers to catch anything done by bzr builder or builddeb
[21:10] <poolie> we agreed to strike that particular implementation
[21:10] <poolie> it's nontrivial work and it's not actually helping
[21:10] <poolie> ubuntu developers
[21:10] <jam> poolie: so should the bug be closed as WontFix ?
[21:11] <jam> or is that bug #676766
[21:11] <poolie> instead, we'll measure things we're already doing that ought to correlate with user happiness/uptake
[21:11] <poolie> jam: with a note
[21:11] <poolie> next bug?
[21:12] <barry>   * http://pad.lv/556132 - don't drop SSH connection after sending 1GB; requested by kiko
[21:12] <barry> ]
[21:12] <jam> done, I believe
[21:12] <poolie> fixed and deployed!
[21:12] <barry> you guys rock!
[21:12] <barry>   * http://pad.lv/375013 - support committing direct to stacked branches
[21:12] <barry>  
[21:12] <jam> done
[21:12] <poolie> thanks to exarkun and mwh too
[21:12] <poolie> you rock, jam!
[21:12] <barry>   * bzr branches are too expensive to use for casual sponsoring, compared with downloading packages from my local mirror (slangasek)
[21:12] <barry>  
[21:13] <slangasek> still on my rainy day hacking list
[21:13] <jam> lots of discussion at UDS, but I don't think we had strong concrete answers
[21:13] <persia> What class of solution is considered for that problem?
[21:13] <jam> I think it got put on the poker table (create a branch from a mirror tarball)
[21:13] <slangasek> you'd think Portland would give me rainy days to go around, but no
[21:13] <jam> and also shallow checkouts
[21:14] <slangasek> persia: I'm planning to implement support for automating mirroring of branches
[21:14] <persia> Ah, OK.  Thanks for the detail.
[21:14] <barry> i think we should keep this on the list, since it's a core improvement that the team is working on
[21:14] <slangasek> this is important to me even if other solutions (e.g., shallow branches) speed up the download from LP itself
[21:14] <jam> note that spiv and I were working on getting a fast shallow checkout from LP
[21:14] <poolie> it is
[21:15] <poolie> some of the specific things we discussed are in https://wiki.canonical.com/Bazaar/Plan/2011/Tasks
[21:15] <jam> so it should be equiv to downloading a tarball from LP, which isn't as good as a local mirror
[21:15] <poolie> including that
[21:15] <poolie> (canonical-only, sorry)
[21:15] <jam> but better than full history
[21:15] <jam> I think it got slightly back-burnered vs other bzr work
[21:16] <barry>   * [[https://launchpad.net/bugs/295274|(watch file support)]] - james_w and barry to sprint on that at uds-n
[21:16] <barry>  
[21:16] <jam> I don't think they got to it
[21:16] <jam> definitely talked about it
[21:16] <barry> note that i unassigned myself from this bug, sadly
[21:16] <jam> but no code was implemented
[21:16] <james_w> jelmer has been hacking on that
[21:16] <james_w> it needs some merge proposals reviewing
[21:16] <jam> ah, it says "jelmer hacked it together and will be submitting mps"
[21:17] <persia> Note that sometimes it is desireable to create a new upstream version which isn't the latest upstream version according to the watch file, depending on release status, etc.  Please be sure to allow override, rather than relying purely on the watch file.
[21:17] <jam> I don't think he has submitted anything
[21:17] <barry> persia: definitely.  i don't think they plan to remove the explicit options, but just make the common case easy
[21:17] <james_w> persia, "shouldn't /require/ --version"
[21:17] <persia> Just checking :)
[21:17] <jam> persia: I'm pretty sure the idea is that you don't *have* to specify version, but if you do, it will be used
[21:18] <jam> barry: sounds like 'in progress' but not closed yet
[21:18] <barry> we'll keep it on the list; it's really nice to see progress on it (since i suck :)
[21:18] <barry>   * [[https://launchpad.net/bugs/653307|Import fails with missing referenced chk root keys]]
[21:18] <barry>  
[21:19] <barry> this one falls under the general class of import failures, which i know is a top priority for the team
[21:19] <poolie> it is
[21:20] <poolie> i believe we fixed 50% of the imports last week?
[21:20] <poolie> i wonder if the graph agrees?
[21:20] <jam> I'm pretty sure that specific bug is, restart them and they all work
[21:20] <poolie> ah, ok
[21:20] <barry> *nice*
[21:20] <jam> http://package-import.ubuntu.com/status/ says it is back down a lot
[21:20] <MootBot> LINK received:  http://package-import.ubuntu.com/status/ says it is back down a lot
[21:20] <poolie> so that needs someone, probably spiv, to agree with james_w that it's ok to delete and restart it?
[21:20] <poolie> nice
[21:21] <poolie> that's a log scale of course
[21:21] <jam> at the moment, it is all pretty manual
[21:21] <poolie> meaning the software will crash if it ever reaches 0 :-) (jk)
[21:21] <barry> :)
[21:21] <slangasek> yes, that was bug #653832, right?
[21:21] <jam> slangasek: nope, a different one
[21:21] <jam> bug 653307
[21:21] <barry> (that one was coming up)
[21:22] <poolie> ok it looks like bug 655307 is not blocked on james
[21:22] <slangasek> jam: I thought 32 was the one that fixed 50% of the imports :)
[21:22] <jam> ah, slangasek, yes that was the one I fixed
[21:22] <poolie> we just need to do it
[21:22] <jam> which was 700 or so failures
[21:22] <barry> i know there was a bug about (or we talked about) making sure that bzr branch of a package that had import failures at least warned the user
[21:22] <poolie> yes, we did talk about it
[21:22] <poolie> i think we should file a bug
[21:23] <barry> poolie: i'll take that action item
[21:23] <poolie> i'll do that now
[21:23] <barry> oh, okay, i'll let you do it :)
[21:23] <poolie> unless anyone knows of an existing bug
[21:23] <jam> [ACTION] poolie to file bug about MOTD information for out-of-date packages
[21:23]  * barry looks
[21:24] <jam> aparrently mootbot only likes barry
[21:24] <poolie> ah bug 609187 exists
[21:24] <barry> which is funny, 'cause i hate mootbot
[21:24] <barry> [ACTION] poolie to file bug about MOTD information for out-of-date packages
[21:24] <MootBot> ACTION received:  poolie to file bug about MOTD information for out-of-date packages
[21:25] <slangasek> whoever starts the meeting is stuck with it for the duration :)
[21:25] <barry> poolie: i'll put that one on the hot list
[21:25] <barry>   * [[https://bugs.launchpad.net/bzr/+bug/603395|bzr commit in a heavyweight checkout does not propagate new tags]]
[21:25] <barry>  
[21:25] <poolie> thanks barry
[21:25] <poolie> fixed, or almost fixed?
[21:26] <poolie> bug 603395
[21:26] <jam> I think it is fixed thanks to spiv
[21:26] <barry> the bug is still in progress but the branch was merged apparently
[21:27] <jam> ah but isn't landed yet
[21:27] <jam> right
[21:27] <jam> action item me to review it
[21:27] <barry> [ACTION] jam to review spiv's branch for bug 603395
[21:27] <MootBot> ACTION received:  jam to review spiv's branch for bug 603395
[21:27] <barry>   * [[https://launchpad.net/bugs/653832|Import fails with "trying to import version ... again"]]
[21:27] <barry>  
[21:27] <jam> fixed
[21:27] <barry> rock
[21:27] <barry>   * [[https://launchpad.net/bugs/499684|Interface to dpkg-buildpackage inconsistent and not well documented]]
[21:27] <barry>  
[21:28] <barry> a.k.a. the ScottK special
[21:28] <poolie> spiv is away this week
[21:29] <jam> poolie: well I'm PP this week anyway, so take it over, etc as necessary
[21:29] <barry> we'll just keep this one on the list and revisit next week
[21:29] <barry>   * http://pad.lv/608450 and others - ways to update debian/control and versions from a recipe
[21:29] <barry>  
[21:30] <poolie> jam, thanks
[21:30] <poolie> nothing on that one
[21:30] <barry> k
[21:31] <barry> that's it for known hot bugs.  i'd like to get the debcommit/bzr commit item on the radar.  it's not critical, but i do view it as a wart.  what do y'all think?
[21:32] <jam> poolie just marked 608450 as invalid, do we take it of the list then?
[21:32] <jam> barry: I don't fully understand what you need from it, but getting it specified and making sure we have the hooks, etc is certainly worthy
[21:32] <jam> Some other possible hot-items
[21:33] <jam> pristine-tar is the next most common import failure
[21:33] <jam> and I have rt #43560 to have the new version backported
[21:33] <jam> which is in-progress, lamont said he's got the backport but needs to test it before deploying
[21:33] <jam> I don't think there is a bug on it. but after deploy the packages will need to be requeued
[21:33] <poolie> i don't have a strong opinion on fixing it
[21:33] <barry> jam: i would like to recommend folks always use bzr commit, though debcommit does have some nice properties.  lifeless (iirc, my email is unavail atm) suggested hooks to allow bzr commit to do the things debcommit does, which would be nice
[21:33] <poolie> i just made bug 608450 wontfix because that's more accurate than invalid
[21:34] <barry> not that i don't like debcommit, but it would be better imo, to stick with bzr once you're accustomed to using it
[21:34] <poolie> barry, i think that was a good idea
[21:34] <jam> poolie: right, but invalid/wontfiix sounds like it will kick it out of the hot-bugs to work on
[21:34] <poolie> right, at the moment it won't be fixed
[21:34] <poolie> should we reopen it?
[21:34] <jam> poolie: *I* have no need to reopen it :)
[21:35] <jam> barry: right, I did follow the discussions, and I think having it integrated well would be nice
[21:35] <poolie> iow you have to persuade lp devs, not specifically me
[21:35] <jam> I don't fully know what debcommit does, though, to say what it takes
[21:35] <persia> barry, I've previously needed to modify debian/changelog in a bzr maintained package where the bzr commit message should *not* match detected new entries from debian/changelog.
[21:35] <barry> [ACTION] barry to file bug on debcommit/bzr commit
[21:35] <MootBot> ACTION received:  barry to file bug on debcommit/bzr commit
[21:35] <jam> persia: would -m be sufficient for you?
[21:35] <jam> or do you want to get a template that you can edit?
[21:36] <poolie> i mentioned a bug in that thread to add hooks to enable it
[21:36] <barry> persia: i'll subscribe you to the bug i'll file :)
[21:36] <poolie> perhaps we should have a separate bug saying "and this hook should be used to ..."
[21:36] <persia> jam, -m is probably enough, but that may end up being comfusing when compared to debcommit -m
[21:36] <jam> I think there are other rough points where when giving a template if you *don't* modify it, then we assume you don't want to commit (or at least prompt you) which people didn't like
[21:37] <barry> any other comments about hot bugs before we move on?
[21:37] <jam> barry: I don't know the specific workflow, but is a bzr commit *always* matching the changelog? Or would you do a couple intermediate cleanups before the branch is final?
[21:37] <poolie> any more nominations of things people really want fixed?
[21:37] <jam> barry: action item to follow up on pristine-tar stuff
[21:38] <barry> jam: i personally do many commits, then a dch -i as almost the last thing, then one last bzr commit.  it's that last that debcommit is currently better at because it also --fixes to link the branch to the bug as well as using d/changelog entry
[21:38] <barry> jam: but i also think that if d/changelog doesn't change, then it'll just be a 'normal' commit
[21:38] <jam> barry: right, so how does that interact with 'bzr commit' automagic? Just that it only kicks in if there is a *new* changelog entry
[21:39] <jam> ?
[21:39] <jam> right
[21:39] <barry> [ACTION] jam to follow up on pristine-tar stuff :)
[21:39] <MootBot> ACTION received:  jam to follow up on pristine-tar stuff :)
[21:39] <barry> jam: yes, i think so.  would also be nice to warn if LP: #12345 wasn't included or mis-formatted
[21:40] <barry> jam: there's a question about what to do if you change a changelog entry (i.e. don't add a new one but edit an existing one).  for now, i'd say whatever is easiest is fine (it's a bit of an uncommon - for me - occurrence)
[21:40] <persia> editing changelog is the special case I mentioned above.
[21:40] <barry> anyway, we can carry that on in the bug comments or in the ml
[21:40] <jam> barry: right
[21:41] <persia> Another common case where I use debcommit is with -R magic, which would be nice to integrate if trying to emulate the tool.
 is interesting Re: debcommit
[21:41]  * barry 's email is offline atm :(
[21:41] <barry> cool.  if there are no other hot bug nominations, let's move on to aob
[21:41] <poolie> k
[21:41] <barry> [TOPIC] aob
[21:41] <MootBot> New Topic:  aob
[21:42] <poolie> i have a couple
[21:42] <barry> the floor is poolie's
[21:42] <poolie> * bug queue management
[21:42] <poolie> we agreed to make a small process change last week,
[21:42] <james_w> as is <1236587080.23732.44.camel@flash>
[21:42] <jam>  sidebar: what is AOB?
[21:42] <poolie> which is that the shortlist of bugs for my team will now be <https://bugs.launchpad.net/~canonical-bazaar/+assignedbugs>
[21:43] <poolie> (any other business?)
[21:43] <poolie> as opposed to previously opening a task against udd
[21:43] <poolie> this is just fyi
[21:43] <poolie> if any of you feel a bug is important to udd, please make that clear in comment text or set the importance as you see fit
[21:44] <poolie> we can always change it or discuss it later
[21:44] <poolie> also, i will try to set up an instance of jkakar's kanban software to give a view of this
[21:44] <poolie> questions/comments?
[21:45] <jam> poolie: how do we handle it when someone on the team starts it
[21:45] <barry> poolie: just to clarify: we still have (i think) some uncertainty whether to file bugs against udd or bzr-builddeb.  do you have some clear guidelines for folks on that?
[21:45] <jam> do we reassign it? or just mark it in-progress?
[21:45] <poolie> reassign to that person
[21:45] <poolie> and inprogress
[21:45] <poolie> i'm hoping that lp:kanban will give us an aggregated view, or can be tweaked to do so
[21:46] <poolie> barry, i think the rule now would be, file against whatever code base needs the fix
[21:46] <poolie> if in doubt, udd
[21:46] <barry> poolie: thanks
[21:47] <jam> barry: right, and then when it is something that the canonical team is going to focus on, it gets assigned to that team
[21:47] <jam> but we monitor udd/bzr/bzr-builddeb etc
[21:47] <jam> at least, I know *I* get emails for bugs in both
[21:47] <barry> :)
[21:47] <jam> if I happen to ignore them...
[21:47] <poolie> next item?
[21:47] <poolie> * bzr team theme
[21:48] <poolie> we're going to make it possible to stop doing source package uploads by uds
[21:48] <poolie> the main things under this seem to be,
[21:48] <poolie> 1- reliable package imports, so people have a place to start from
[21:48] <poolie> 2- build from branch into the main archive
[21:49] <poolie> this doesn't mean we'll turn off dput uploads, but we want to make it possible for people to do that if they want
[21:49] <slangasek> are you targeting the current devel distro only?
[21:49] <poolie> and i hope that around that time frame, some people will be finding it worthwhile to stop doing source package uploads
[21:49] <poolie> yes
[21:49] <slangasek> ok
[21:50] <slangasek> just checking; I'm still keen to see -proposed queues turned into merge requests :-)
[21:50] <barry> very cool
[21:50] <poolie> for past releases, i think lp should always keep supporting the toolchain used when they were originally released
[21:51] <poolie> i think this is a good goal because it will help us distinguish the 'must be done' features
[21:51] <barry> poolie: do you foresee requiring udd-only for 12.04 and onward?
[21:51] <poolie> and, remove some complexity or inconsistency from supporting multiple mechanisms
[21:51] <poolie> barry, well, it's not for me to set that kind of requirement
[21:51] <jam> barry: it is under discussion
[21:51] <poolie> we'll do our best to get things to a state where the TB can decide that they will do udd-only
[21:51] <jam> but as poolie says, that is something outside the bzr group to control
[21:52]  * barry nods
[21:52] <jam> I think it also affects stuff like the linaro build process
[21:52] <poolie> there's a middle step where lp could get an acl on source packages in particular releases to say they should only come from branches
[21:52] <poolie> to let them be used as canaries for the process
[21:52] <barry> that's a good idea
[21:53] <slangasek> poolie: well, bear in mind that ~4 months after UDS we enter archive freeze, and then LP should /not/ automatically build from branch...
[21:53] <slangasek> or at least, not from any branch ubuntu-dev can commit to directly
[21:53] <poolie> slangasek, right, only, what ~archive-admins can approve things?
[21:53] <james_w> I'm not sure it will even be automatic
[21:54] <poolie> there is a question here about whether committing should automatically build
[21:54] <poolie> or whether there is a separate 'do it' step
[21:54] <slangasek> poolie: in practice archive admins push the button, though this is a (minor) LP bug
[21:54] <slangasek> it should be the release team
[21:54] <jam> slangasek: so how is the dput uploads processed. Just restricted to specific users after a given point?
[21:54] <lifeless> slangasek: so the build from branch implementation will initially be a front-end to the uploader
[21:54] <slangasek> and for previous releases, the SRU team
[21:54] <barry> it might be nice to do the build as an intermediate step, but have different criteria for upload-to-archive
[21:54] <slangasek> jam: dumped into an 'unapproved' queue within soyu^W launchpad
[21:54] <lifeless> slangasek: so all the normal policy knobs, freezing etc will operate unaltered.
[21:54] <slangasek> lifeless: fair enough
[21:55] <poolie> interesting idea
[21:55] <poolie> ah, what else
[21:55] <poolie> we will probably still publish source packages
[21:55] <lifeless> we can iterate for deeper glue etc once regular uploads *cannot happen* - e.g. in 7 years
[21:55] <lifeless> :P
[21:55] <poolie> right
[21:55] <poolie> https://dev.launchpad.net/LEP/BuildFromBranchIntoMain
[21:56] <poolie> an update of a very old spec
[21:56] <poolie> but now in reach!
[21:56] <persia> Given 7 years, it oughtn't be that hard to implement a `dput` that does the bzr stuff.
[21:57] <poolie> so, this is what we're planning to do
[21:57] <barry> point of order: we're coming up on an hour, so we should wrap up.  anything else we need to discuss here today?
[21:58] <barry> if not, then...
[21:58] <barry> #endmeeting
[21:58] <MootBot> Meeting finished at 15:58.
[21:58] <jam> end p o o ?
[21:58] <poolie> i think that's it
[21:58] <barry> jam: :)
[21:58] <poolie> i'll send mail about that plan
[21:58] <barry> thanks everybody!  i'll just note that about 4" of snow has fallen since this meeting started :)
[21:58] <jam> barry: wow
[21:58] <poolie> great
[21:58] <poolie> thankyou, all
[21:58] <maco> barry: and hail/sleet!
[21:59]  * maco just rode home in it
[21:59] <barry> maco: time to hunker down!
[21:59] <slangasek> thanks :)
[21:59] <jam> barry: so how were the wiki pages made from the IRC notes?
[22:00] <jam> were / are
[22:00] <barry> jam: very low tech: i copy them from my erc buffer, and paste them into my browser
[22:01] <jam> barry: so what *is* the point of mootbot?
[22:01] <barry> jam: exactly
[22:02] <barry> jam: i got out of the habit of using the logs back in my lp days because it almost never worked
[22:02] <barry> now i use erc and bip and have my own logs