[06:22] <Ziroday> @schedule Singapore
[06:22] <ubotu> Schedule for Asia/Singapore: 20 Sep 20:00: Desktop Team Development | 21 Sep 20:00: MOTU Team | 25 Sep 03:00: Screencast Team | 25 Sep 23:00: Server Team meeting | 26 Sep 00:00: Kernel Team | 26 Sep 03:00: Technical Board
[08:55] <kraut> moin
[01:53] <kwwii> hi Keybuk
[01:55] <Keybuk> Heya
[01:55] <Keybuk> just putting together the agenda so I can mail it out :-)
[01:59] <pitti> hi
[02:01] <Keybuk> just waiting for iwj I think
[02:02] <pitti> he just pung in #distro
[02:02] <Keybuk> ah, my canonical connection appears stoned
[02:03] <kwwii> i pung him
[02:03] <Keybuk> #startmeetingt
[02:03] <Keybuk> #startmeeting
[02:03] <MootBot> Meeting started at 11:52. The chair is Keybuk.
[02:03] <MootBot> Commands Available: [TOPIC] , [IDEA] , [ACTION] , [AGREED] , [LINK] , [VOTE] 
[02:03] <Keybuk> Ok, this should be a fairly short one since there weren't any agenda items to add
[02:04] <Keybuk> did anybody have anything they wanted to add to my mail I just sent out
[02:04] <Keybuk> currently we just have
[02:04] <Keybuk>  * Ideas for hardy
[02:04] <kwwii> I have one thing to add about some artwork packages will still need to change
[02:04] <pitti> syncing and reading mail...
[02:04] <kwwii> but nothing major...just s/feisty/gutsy
[02:05] <kwwii> it just occured to me yesterday that this was a problem
[02:05] <Keybuk> kwwii: ok, let's cover that briefly; what are the packages?
[02:05] <iwj> Err, I put some agenda items in my activity report and they don't seem to be there.  Some of them have been dealt with ...
[02:05] <Keybuk> [TOPIC]  some artwork packages still need to change feisty -> gutsy
[02:05] <MootBot> New Topic:  some artwork packages still need to change feisty -> gutsy
[02:05] <kwwii> feisty-session-splash, feisty-gdm-theme and such
[02:06] <kwwii> as I have started taking over more of the packages themselves I did not realize it until yesterday, so I have to make sure that I can still get them in
[02:06] <pitti> kwwii: that sounds fine
[02:06] <kwwii> the one package which included different artwork was changed yesterday
[02:06] <pitti> kwwii: subject to my scrutinizing, of course :)
[02:07] <kwwii> pitti: cool, when I am done with the changes I will show them to you first
[02:07] <pitti> kwwii: sounds like some NEWing is in order there, but that shouldn't be a problem either
[02:07] <kwwii> pitti: yeah, in the future (at UDS) I will discuss this and figure out how to make the package non-release dependent
[02:07] <kwwii> silly to use a release name in the package and have to make it new every time
[02:08] <kwwii> dholbach and I agreed to discuss this at UDS
[02:08] <Keybuk> I think the original intent was that we'd change the theme for each release
[02:08] <Keybuk> so people should be able to retain the old one
[02:08] <dholbach> and that people can install their 'feisty theme' if they like that better, even if they run hardy
[02:09] <kwwii> hrm, right
[02:09] <pitti> kwwii: NEWing is no problem and not much work, I just need to be told so that it happens quickly
[02:09] <pitti> s/I/any archive admin/
[02:09] <kwwii> pitti: I'll get it done right away then
[02:10] <kwwii> I also have a new package for universe but that does not seem to be such a problem
[02:10] <Keybuk> [AGREED]  Ken and Daniel to discuss theme package naming at UDS
[02:10] <MootBot> AGREED received:  Ken and Daniel to discuss theme package naming at UDS
[02:10] <Keybuk> [ACTION]  kwwii to fix package names and notify pitti beforehand to aid NEW processing
[02:10] <MootBot> ACTION received:  kwwii to fix package names and notify pitti beforehand to aid NEW processing
[02:11] <Keybuk> ok, Ian: sorry missed your sl-modem-daemon agenda item (I think the QA one is being discussed by mail adequately?)
[02:11] <iwj> QA> Yes.
[02:11] <Keybuk> [TOPIC]  sl-modem-daemon has stopped working since Tribe 5
[02:11] <MootBot> New Topic:  sl-modem-daemon has stopped working since Tribe 5
[02:11] <iwj> So I just wanted to ask kernel guys if they had any ideas ?
[02:11] <Keybuk> I'm not sure we have any kernel guys here :)
[02:11] <iwj> Or thoughts about how to go about debugging it.
[02:11] <iwj> Hmm.
[02:12] <Keybuk> probably best to follow up on #ubuntu-kernel or the mailing list, and grab a developer directly
[02:12] <iwj> OK, I'll try that.
[02:12] <Keybuk> did you try the newer version of sl-modem-daemon you talked about
[02:12] <iwj> Not yet.
[02:12] <Keybuk> ok
[02:12] <iwj> But I did retest tribe 5, and it still works.
[02:12] <Keybuk> does anyone else here have a modem that has worked with sl-modem-daemon that they could use to help Ian test?
[02:12] <Keybuk> iwj: that's something, at least :-)
[02:13] <pitti> soren has one
[02:13] <iwj> You don't need an actual phone line for this particular bug.
[02:13] <pitti> and TeTeT has two
[02:13] <soren> huh?
[02:13] <pitti> they both helped me with testing the new restricted-manager magic for it
[02:13] <iwj> soren: Let's talk about it out of the meeting.  I'd like a bit of help with sl-modem-daemon testing.
[02:14] <pitti> soren: I saw your pci modalias! (Muhhahaha)
[02:14] <soren> *g*
[02:14] <soren> iwj: Right, I think I have some logs for you that might help.
[02:14] <TeTeT> iwj: ping me any time, we have a quasi modem line in the Montreal h/w cert lab
[02:14] <Keybuk> [ACTION]  iwj to talk to kernel developers about sl-modem-daemon breakage
[02:14] <MootBot> ACTION received:  iwj to talk to kernel developers about sl-modem-daemon breakage
[02:14] <Keybuk> [ACTION]  iwj to test newer sl-modem-daemon to see whether that fixes the problem
[02:14] <iwj> TeTeT: OK, are you on #ubuntu-devel ?  We can talk there.
[02:14] <MootBot> ACTION received:  iwj to test newer sl-modem-daemon to see whether that fixes the problem
[02:14] <Keybuk> [ACTION]  iwj to rope in soren and TeTeT to help testing
[02:14] <MootBot> ACTION received:  iwj to rope in soren and TeTeT to help testing
[02:15] <Keybuk> ok
[02:15] <Keybuk> [TOPIC]  Ideas for hardy
[02:15] <MootBot> New Topic:  Ideas for hardy
[02:15] <Mithrandir> iwj wins at action items.
[02:15] <Keybuk> Thanks to everyone who included their Hardy ideas in their activity summary e-mail
[02:16] <Keybuk> I'd like to go down the list quickly to generate some discussion
[02:16] <Keybuk> prefix your idea with "[IDEA] " so mootbot can pick it up <g>
[02:16] <Keybuk> kwwii: you first
[02:17] <kwwii> [IDEA]  update the widget theme
[02:17] <MootBot> IDEA received:  update the widget theme
[02:17] <kwwii> [IDEA]  straighten out the process for artwork
[02:17] <MootBot> IDEA received:  straighten out the process for artwork
[02:17] <kwwii> [IDEA]   create a color palette and clear rules of use
[02:17] <MootBot> IDEA received:   create a color palette and clear rules of use
[02:17] <pitti> artwork process: is it so complicated ATM?
[02:18] <kwwii> pitti: well, we have no clear process and lots of different versions which all have their own rules
[02:18] <kwwii> pitti: also, it would be good to be able to get the community involved again
[02:18] <pitti> kwwii: ah, as "set of packages we need to update", and check whether we can merge some of them, etc.?
[02:19] <kwwii> pitti: right, and on top of that decide which versions have total community control, and which not
[02:19] <kwwii> pitti: and in addition set clear rules for evolving the look instead of just recreating the wheel every time
[02:19] <kwwii> ubuntu is very stagnant, no wonder that the community finds it hard to contribute
[02:20] <kwwii> that brings us to the second idea, of creating a palette and clear rules for the artwork
[02:20] <Keybuk> kwwii: one of the things I've talked about already with Mark is the idea of using the LTS as the time we bring in a bold new look, and then evolve it over the next non-LTS releases until a new look for the next LTS
[02:20] <kwwii> until now, we have light brown and dark brown
[02:20] <Keybuk> that would seem to fit in with your idea?
[02:20] <kwwii> Keybuk: yes, it does
[02:21] <kwwii> in some ways, the most important part of this is to know exactly what we can change (from mark)
[02:21] <kwwii> as for the widget theme, we would need some technical people to help out
[02:22] <Keybuk> ok, thanks
[02:22] <Keybuk> iwj: you're next :)
[02:22] <iwj> [IDEA]  Dialup support should be better
[02:22] <MootBot> IDEA received:  Dialup support should be better
[02:22] <iwj> [IDEA]  Easy reinstallation: separate /home and a bit of migration support
[02:22] <MootBot> IDEA received:  Easy reinstallation: separate /home and a bit of migration support
[02:22] <iwj> [IDEA]  Encrypted swap (already!)
[02:22] <MootBot> IDEA received:  Encrypted swap (already!)
[02:23] <iwj> [IDEA]  Disk encryption by default on laptops
[02:23] <MootBot> IDEA received:  Disk encryption by default on laptops
[02:23] <iwj> [IDEA]  Declarative diversions
[02:23] <MootBot> IDEA received:  Declarative diversions
[02:23] <iwj> [IDEA]  Better conffile messing support
[02:23] <MootBot> IDEA received:  Better conffile messing support
[02:23] <Keybuk> iwj: could you expand a little on "easy reinstallation" and "declarative diversions" ?
[02:23] <iwj> Easy reinstallation - separate /home and some migration of installed packages or other key bits of system configuration.  We cannot assume our users are competent to fix a broken system or a failed upgrade, so we need to make reinstallation without loss of data easy.
[02:24] <kwwii> iwj: excellent idea
[02:24] <iwj> Declarative diversions for dpkg.  This will get rid of a whole class of packaging bugs, and make Robert Collin's conflicts/replaces checker much more effective.  For the usual reasons this has a longish deployment schedule: if we implement it for hardy we'll be able to use it in anger in hardy+1 and of course eventually Debian will adopt it and it will become the new default.
[02:24] <cjwatson> separate /home> we need to have an argument about this ;-) it's come up many times before and there are reasons we haven't done it
[02:24] <cjwatson> (not necessarily insuperable but they can't just be brushed aside IMO)
[02:24] <Keybuk> cjwatson: if only we got everyone together in one room :p
[02:24] <iwj> cjwatson: I know, but I think the benefits outweigh the alleged disadvantages on modern systems with big disks.
[02:25] <Keybuk> . o O { lvm by default makes the issues go away }
[02:25] <iwj> I think we should talk about it at UDS.
[02:25] <cjwatson> sure
[02:25] <cjwatson> Keybuk: and brings in so many new ones ...
[02:25] <Keybuk> iwj: what does a declarative diversion mean?
[02:25] <Keybuk> or, I should say, what would one look like?
[02:26] <iwj> It means your package has a control file DEBIAN/diversions instead of your maintscripts calling dpkg-divert to edit a database in /var.
[02:26] <Mithrandir> which means people won't try to add diversions in postinsts and similar.
[02:26] <iwj> There are all sorts of braindamages which will be impossible to perpetrate :-).
[02:27] <Mithrandir> declarative diversions sounds like a great thing to have.
[02:27] <cjwatson> can you lump in declarative alternatives with that?
[02:27] <pitti> ++, as with declarative obsolete conffiles
[02:27] <iwj> cjwatson: Possibly.  Hmm.  Worth thinking about the two together, at least.
[02:27] <cjwatson> last time I checked there were eight different systems in routine use for where to call update-alternatives in your maintainer scripts
[02:28] <Mithrandir> cjwatson: "nice"
[02:28] <iwj> Let me make a separate idea for it so it doesn't get lost.
[02:28] <iwj> [IDEA]  Declarative alternatives
[02:28] <MootBot> IDEA received:  Declarative alternatives
[02:28] <cjwatson> (not helped by policy not providing any guidance at all on the topic)
[02:28] <iwj> Tempting to say [IDEA]  Alternative declaratives
[02:29] <Keybuk> iwj: excellent!
[02:29] <Keybuk> pitti: your turn
[02:29] <pitti> [IDEA]  Complete redesign of the restricted-manager code
[02:29] <MootBot> IDEA received:  Complete redesign of the restricted-manager code
[02:29] <pitti> The initial design was never meant to get all the features and extensions bolted on that we use it for nowadays: non-module related handlers, KDE frontend, notifications, cooperation with compiz settings, etc. The current code makes it a pain to add new features or fix bugs.
[02:29] <pitti> not exactly sexy, but we won't get around it, I'm afraid
[02:30] <pitti> [IDEA]  Find/tweak/create a backup solution that doesn't suck and is adequate for home users, as well as flexible enough for dudes like us.
[02:30] <MootBot> IDEA received:  Find/tweak/create a backup solution that doesn't suck and is adequate for home users, as well as flexible enough for dudes like us.
[02:30] <pitti> [IDEA]  Improve synchronization between Evolutions, cellphones, PDAs, etc.
[02:30] <pitti> (everything that speaks SyncML for now).
[02:30] <MootBot> IDEA received:  Improve synchronization between Evolutions, cellphones, PDAs, etc.
[02:30] <pitti> (stolen from the IdeaPool)
[02:30] <pitti> and finally something longer-term:
[02:31] <pitti> [IDEA]  Start a desktop application for a decision tree based guided bug filing.
[02:31] <MootBot> IDEA received:  Start a desktop application for a decision tree based guided bug filing.
[02:31] <pitti> We started discussing this on last UDS (UbuntuSpec:smart-bugreporting-tool) and I do not expect to get it done by Hardy, but we should start on it.
[02:31] <pitti> EOL
[02:31] <Mithrandir> pitti: backup> can we throw in "and you don't trust the host/medium you're backing on to" to the list of features?
[02:32] <Mithrandir> trust as in security-trust, not reliability-trust.
[02:32] <pitti> Mithrandir: nothing spec'ed yet :)
[02:32] <pitti> Mithrandir: I see what you are up to, yes (not that I would use crypto myself, I quite trust my colo server)
[02:32] <Mithrandir> so I do a buddy backup to a friend's machine, and him to mine and we wouldn't be able to read each other's backups.
[02:33] <pitti> Mithrandir: -> UDS spec, I'd say, but great idea
[02:33] <Keybuk> pitti: ok, make a note of Tollef's concerns
[02:33] <iwj> backups++
[02:33] <pitti> but in general, the lack of a good backup solution has nagged me for years
[02:33] <Mithrandir> heck, I use encrypted file systems on racked servers too, disks die and I don't trust the disk manufacturers. :-)
[02:33] <pitti> s/good/one that doesn't suck for me/
[02:34] <Mithrandir> backuppc isn't too bad, but it's pull, not push.
[02:34] <Mithrandir> but we probably don't need to look at all the options here. :-)
[02:34] <pitti> Keybuk: note> done
[02:34] <pitti> Mithrandir: right, pull sucks
[02:34] <pitti> (for my use case, anyway)
[02:35] <pitti> rsnapshot is pull for remote op, too
[02:35] <Keybuk> ok, and Mithrandir?  (though you may have already communicated your mobile ideas to mdz)
[02:35] <Mithrandir> [IDEA]  get bluetooth fixed
[02:35] <MootBot> IDEA received:  get bluetooth fixed
[02:35] <Mithrandir> [IDEA]  investigate webkit for mobile
[02:35] <Mithrandir> [IDEA]  get conduit into shape so we can use it for syncing anything to anything
[02:35] <MootBot> IDEA received:  investigate webkit for mobile
[02:35] <MootBot> IDEA received:  get conduit into shape so we can use it for syncing anything to anything
[02:36] <Mithrandir> [IDEA]  pam_keyring or similar, by default?
[02:36] <MootBot> IDEA received:  pam_keyring or similar, by default?
[02:36] <Mithrandir> [IDEA]  UME - chroots, how to manage?
[02:36] <MootBot> IDEA received:  UME - chroots, how to manage?
[02:36] <Keybuk> Mithrandir: webkit for desktop might be nice <g>
[02:36] <Keybuk> pitti: did you look at conduit for your syncing solution?
[02:36] <Mithrandir> well, yes, that too, so possibly rewrite that to "investigate webkit"
[02:37] <Mithrandir> there exists patches for epiphany to use webkit.
[02:37] <pitti> Keybuk: I haven't looked yet; last time I actually tried that stuff was over a year ago with multisync
[02:37] <Keybuk> Mithrandir: yeah, I built them here a couple of days ago
[02:38] <seb128> Mithrandir: we already have pam_keyring by default
[02:38] <Mithrandir> seb128: we do?
[02:38] <seb128> Mithrandir: it's part of gnome-keyring 2.20 and gdm uses it
[02:39] <seb128> Mithrandir: yes libpam-gnome-keyring
[02:39] <Keybuk> there's a checkbox in the gnome-keyring password dialog now isn't there?
[02:39] <Keybuk> [ ]  Unlock keyring on login
[02:39] <Keybuk> or something
[02:39] <Keybuk> (it doesn't work if you use auto-login of course ... :p)
[02:39] <seb128> right
[02:39] <Mithrandir> seb128: to my defence, I haven't been on a WPA network lately so I haven't been annoyed by the gnome keyring manager dialogue.
[02:39] <seb128> if anybody who knows pam would like to help me to get it working with autologin that would be nice
[02:40] <seb128> also integrating it with passwd should work but I didn't do the packaging changes
[02:40] <seb128> so when the password is changing the keyring one is updated
[02:40] <cjwatson> seb128: you might want to grab Steve for that
[02:40] <cjwatson> (pam/autologin)
[02:40] <seb128> cjwatson: right
[02:41] <seb128> http://live.gnome.org/GnomeKeyring/Pam has details also, I need to try with that, I've just been too busy
[02:41] <MootBot> LINK received:  http://live.gnome.org/GnomeKeyring/Pam has details also, I need to try with that, I've just been too busy
[02:41] <seb128> MootBot: that was not for you :p
[02:41] <Keybuk> ok, thanks everyone
[02:42] <Keybuk> any other business?
[02:43] <Keybuk> #endmeeting
[02:43] <MootBot> Meeting finished at 12:32.
[02:43] <pitti> 12 MB oversizedness, without a single langpack to remove *sigh*
[02:44] <iwj> Keybuk: Are we going to take these [IDEA] s and turn them into a spec each ?  Can I suggest that the thing on the UDS agenda should be or include a solution-neutral problem statement ?
[02:45] <iwj> (Less relevant for "fix this broken thing in the obvious way")
[02:45] <Hobbsee> pitti: we discussed this.  reverse langpacks are still the way to go.  *g*
[02:45] <Keybuk> iwj: Sorry, didn't make that clear :-)
[02:46] <Keybuk> The ideas will be discussed with the other team leads, and then will form the basis of the goals for UDS/Hardy - after some moderation depending on what's possible, or desirable for the LTS
[02:46] <Keybuk> they may form one or more specs each
[02:46] <iwj> Right.
[02:47] <Keybuk> I expect that will form the bulk of today's team leads call
[02:48] <iwj> Oh, I need coffee!
[03:00] <siretart> #help
[03:00] <siretart> MootBot: #help
[03:00] <siretart> hmmm
[04:50] <evand> @schedule New_York
[04:50] <ubotu> Schedule for America/New_York: 21 Sep 08:00: MOTU Team | 24 Sep 15:00: Screencast Team | 25 Sep 11:00: Server Team meeting | 25 Sep 12:00: Kernel Team | 25 Sep 15:00: Technical Board | 26 Sep 16:00: Edubuntu
[05:01] <Rinchen> anyone from the scribes team around?