Ubuntu Wiki

Log

Started logging meeting in #ubuntu-meeting
[11:53:19] <Keybuk> Ok, this should be a fairly short one since there weren't any agenda items to add
[11:53:27] <Keybuk> did anybody have anything they wanted to add to my mail I just sent out
[11:53:29] <Keybuk> currently we just have
[11:53:31] <Keybuk> * Ideas for hardy
[11:53:50] <kwwii> I have one thing to add about some artwork packages will still need to change
[11:53:53] <pitti> syncing and reading mail...
[11:54:09] <kwwii> but nothing major...just s/feisty/gutsy
[11:54:21] <kwwii> it just occured to me yesterday that this was a problem
[11:54:40] <Keybuk> kwwii: ok, let's cover that briefly; what are the packages?
[11:54:47] <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 ...
[11:54:52] <Keybuk> [TOPIC] some artwork packages still need to change feisty -> gutsy
[11:55:17] <kwwii> feisty-session-splash, feisty-gdm-theme and such
[11:55:50] <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
[11:56:01] <pitti> kwwii: that sounds fine
[11:56:07] <kwwii> the one package which included different artwork was changed yesterday
[11:56:12] <pitti> kwwii: subject to my scrutinizing, of course :)
[11:56:25] <kwwii> pitti: cool, when I am done with the changes I will show them to you first
[11:56:32] <pitti> kwwii: sounds like some NEWing is in order there, but that shouldn't be a problem either
[11:56:58] <kwwii> pitti: yeah, in the future (at UDS) I will discuss this and figure out how to make the package non-release dependent
[11:57:14] <kwwii> silly to use a release name in the package and have to make it new every time
[11:57:45] <kwwii> dholbach and I agreed to discuss this at UDS
[11:57:47] <Keybuk> I think the original intent was that we'd change the theme for each release
[11:57:52] <Keybuk> so people should be able to retain the old one
[11:58:06] <dholbach> and that people can install their 'feisty theme' if they like that better, even if they run hardy
[11:58:24] <kwwii> hrm, right
[11:58:45] <pitti> kwwii: NEWing is no problem and not much work, I just need to be told so that it happens quickly
[11:58:50] <pitti> s/I/any archive admin/
[11:59:10] <kwwii> pitti: I'll get it done right away then
[11:59:26] <kwwii> I also have a new package for universe but that does not seem to be such a problem
[11:59:49] <Keybuk> [AGREED] Ken and Daniel to discuss theme package naming at UDS
[12:00:07] <Keybuk> [ACTION] kwwii to fix package names and notify pitti beforehand to aid NEW processing
[12:00:36] <Keybuk> ok, Ian: sorry missed your sl-modem-daemon agenda item (I think the QA one is being discussed by mail adequately?)
[12:00:42] <iwj> QA> Yes.
[12:00:43] <Keybuk> [TOPIC] sl-modem-daemon has stopped working since Tribe 5
[12:00:55] <iwj> So I just wanted to ask kernel guys if they had any ideas ?
[12:01:06] <Keybuk> I'm not sure we have any kernel guys here :)
[12:01:10] <iwj> Or thoughts about how to go about debugging it.
[12:01:11] <iwj> Hmm.
[12:01:24] <Keybuk> probably best to follow up on #ubuntu-kernel or the mailing list, and grab a developer directly
[12:01:30] <iwj> OK, I'll try that.
[12:01:35] <Keybuk> did you try the newer version of sl-modem-daemon you talked about
[12:01:39] <iwj> Not yet.
[12:01:40] <Keybuk> ok
[12:01:51] <iwj> But I did retest tribe 5, and it still works.
[12:01:55] <Keybuk> does anyone else here have a modem that has worked with sl-modem-daemon that they could use to help Ian test?
[12:02:02] <Keybuk> iwj: that's something, at least :-)
[12:02:25] <pitti> soren has one
[12:02:27] <iwj> You don't need an actual phone line for this particular bug.
[12:02:29] <pitti> and TeTeT has two
[12:02:42] <soren> huh?
[12:02:46] <pitti> they both helped me with testing the new restricted-manager magic for it
[12:03:16] <iwj> soren: Let's talk about it out of the meeting. I'd like a bit of help with sl-modem-daemon testing.
[12:03:21] <pitti> soren: I saw your pci modalias! (Muhhahaha)
[12:03:30] <soren> *g*
[12:03:43] <soren> iwj: Right, I think I have some logs for you that might help.
[12:03:43] <TeTeT> iwj: ping me any time, we have a quasi modem line in the Montreal h/w cert lab
[12:03:43] <Keybuk> [ACTION] iwj to talk to kernel developers about sl-modem-daemon breakage
[12:03:56] <Keybuk> [ACTION] iwj to test newer sl-modem-daemon to see whether that fixes the problem
[12:03:57] <iwj> TeTeT: OK, are you on #ubuntu-devel ? We can talk there.
[12:04:08] <Keybuk> [ACTION] iwj to rope in soren and TeTeT to help testing
[12:04:30] <Keybuk> ok
[12:04:47] <Keybuk> [TOPIC] Ideas for hardy
[12:04:48] <Mithrandir> iwj wins at action items.
[12:05:15] <Keybuk> Thanks to everyone who included their Hardy ideas in their activity summary e-mail
[12:05:25] <Keybuk> I'd like to go down the list quickly to generate some discussion
[12:05:56] <Keybuk> prefix your idea with "[IDEA]" so mootbot can pick it up
[12:05:59] <Keybuk> kwwii: you first
[12:06:22] <kwwii> [IDEA] update the widget theme
[12:06:40] <kwwii> [IDEA] straighten out the process for artwork
[12:07:06] <kwwii> [IDEA] create a color palette and clear rules of use
[12:07:15] <pitti> artwork process: is it so complicated ATM?
[12:07:47] <kwwii> pitti: well, we have no clear process and lots of different versions which all have their own rules
[12:08:05] <kwwii> pitti: also, it would be good to be able to get the community involved again
[12:08:06] <pitti> kwwii: ah, as "set of packages we need to update", and check whether we can merge some of them, etc.?
[12:08:31] <kwwii> pitti: right, and on top of that decide which versions have total community control, and which not
[12:08:53] <kwwii> pitti: and in addition set clear rules for evolving the look instead of just recreating the wheel every time
[12:09:14] <kwwii> ubuntu is very stagnant, no wonder that the community finds it hard to contribute
[12:09:35] <kwwii> that brings us to the second idea, of creating a palette and clear rules for the artwork
[12:09:40] <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
[12:09:45] <kwwii> until now, we have light brown and dark brown
[12:09:47] <Keybuk> that would seem to fit in with your idea?
[12:09:56] <kwwii> Keybuk: yes, it does
[12:10:27] <kwwii> in some ways, the most important part of this is to know exactly what we can change (from mark)
[12:10:46] <kwwii> as for the widget theme, we would need some technical people to help out
[12:11:45] <Keybuk> ok, thanks
[12:11:49] <Keybuk> iwj: you're next :)
[12:12:01] <iwj> [IDEA] Dialup support should be better
[12:12:12] <iwj> [IDEA] Easy reinstallation: separate /home and a bit of migration support
[12:12:17] <iwj> [IDEA] Encrypted swap (already!)
[12:12:24] <iwj> [IDEA] Disk encryption by default on laptops
[12:12:29] <iwj> [IDEA] Declarative diversions
[12:12:44] <iwj> [IDEA] Better conffile messing support
[12:12:48] <Keybuk> iwj: could you expand a little on "easy reinstallation" and "declarative diversions" ?
[12:13:16] <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.
[12:13:26] <kwwii> iwj: excellent idea
[12:13:39] <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.
[12:13:55] <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
[12:14:07] <cjwatson> (not necessarily insuperable but they can't just be brushed aside IMO)
[12:14:10] <Keybuk> cjwatson: if only we got everyone together in one room :p
[12:14:15] <iwj> cjwatson: I know, but I think the benefits outweigh the alleged disadvantages on modern systems with big disks.
[12:14:32] <Keybuk> . o O { lvm by default makes the issues go away }
[12:14:32] <iwj> I think we should talk about it at UDS.
[12:14:37] <cjwatson> sure
[12:14:45] <cjwatson> Keybuk: and brings in so many new ones ...
[12:14:50] <Keybuk> iwj: what does a declarative diversion mean?
[12:15:02] <Keybuk> or, I should say, what would one look like?
[12:15:21] <iwj> It means your package has a control file DEBIAN/diversions instead of your maintscripts calling dpkg-divert to edit a database in /var.
[12:15:39] <Mithrandir> which means people won't try to add diversions in postinsts and similar.
[12:15:56] <iwj> There are all sorts of braindamages which will be impossible to perpetrate :-).
[12:16:32] <Mithrandir> declarative diversions sounds like a great thing to have.
[12:16:48] <cjwatson> can you lump in declarative alternatives with that?
[12:17:02] <pitti> ++, as with declarative obsolete conffiles
[12:17:07] <iwj> cjwatson: Possibly. Hmm. Worth thinking about the two together, at least.
[12:17:12] <cjwatson> last time I checked there were eight different systems in routine use for where to call update-alternatives in your maintainer scripts
[12:17:27] <Mithrandir> cjwatson: "nice"
[12:17:35] <iwj> Let me make a separate idea for it so it doesn't get lost.
[12:17:39] <iwj> [IDEA] Declarative alternatives
[12:17:45] <cjwatson> (not helped by policy not providing any guidance at all on the topic)
[12:17:54] <iwj> Tempting to say [IDEA] Alternative declaratives
[12:18:27] <Keybuk> iwj: excellent!
[12:18:44] <Keybuk> pitti: your turn
[12:18:53] <pitti> [IDEA] Complete redesign of the restricted-manager code
[12:18:58] <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.
[12:19:14] <pitti> not exactly sexy, but we won't get around it, I'm afraid
[12:19:23] <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.
[12:19:44] <pitti> [IDEA] Improve synchronization between Evolutions, cellphones, PDAs, etc.
[12:19:44] <pitti> (everything that speaks SyncML for now).
[12:19:55] <pitti> (stolen from the IdeaPool)
[12:20:17] <pitti> and finally something longer-term:
[12:20:23] <pitti> [IDEA] Start a desktop application for a decision tree based guided bug filing.
[12:20:29] <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.
[12:20:42] <pitti> EOL
[12:21:16] <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?
[12:21:28] <Mithrandir> trust as in security-trust, not reliability-trust.
[12:21:31] <pitti> Mithrandir: nothing spec'ed yet :)
[12:21:59] <pitti> Mithrandir: I see what you are up to, yes (not that I would use crypto myself, I quite trust my colo server)
[12:22:08] <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.
[12:22:26] <pitti> Mithrandir: -> UDS spec, I'd say, but great idea
[12:22:36] <Keybuk> pitti: ok, make a note of Tollef's concerns
[12:22:37] <iwj> backups++
[12:22:45] <pitti> but in general, the lack of a good backup solution has nagged me for years
[12:22:47] <Mithrandir> heck, I use encrypted file systems on racked servers too, disks die and I don't trust the disk manufacturers. :-)
[12:22:54] <pitti> s/good/one that doesn't suck for me/
[12:23:32] * pitti currently uses rsnapshot plus rsync to get them to the server
[12:23:49] <Mithrandir> backuppc isn't too bad, but it's pull, not push.
[12:24:02] <Mithrandir> but we probably don't need to look at all the options here. :-)
[12:24:06] <pitti> Keybuk: note> done
[12:24:12] <pitti> Mithrandir: right, pull sucks
[12:24:16] <pitti> (for my use case, anyway)
[12:24:24] <pitti> rsnapshot is pull for remote op, too
[12:24:57] <Keybuk> ok, and Mithrandir? (though you may have already communicated your mobile ideas to mdz)
[12:25:09] <Mithrandir> [IDEA] get bluetooth fixed
[12:25:18] <Mithrandir> [IDEA] investigate webkit for mobile
[12:25:18] <Mithrandir> [IDEA] get conduit into shape so we can use it for syncing anything to anything
[12:25:21] <Mithrandir> [IDEA] pam_keyring or similar, by default?
[12:25:23] <Mithrandir> [IDEA] UME - chroots, how to manage?
[12:25:51] <Keybuk> Mithrandir: webkit for desktop might be nice
[12:26:04] <Keybuk> pitti: did you look at conduit for your syncing solution?
[12:26:13] <Mithrandir> well, yes, that too, so possibly rewrite that to "investigate webkit"
[12:26:25] <Mithrandir> there exists patches for epiphany to use webkit.
[12:26:29] <pitti> Keybuk: I haven't looked yet; last time I actually tried that stuff was over a year ago with multisync
[12:26:44] <Keybuk> Mithrandir: yeah, I built them here a couple of days ago
[12:27:41] <seb128> Mithrandir: we already have pam_keyring by default
[12:27:55] <Mithrandir> seb128: we do?
[12:28:00] <seb128> Mithrandir: it's part of gnome-keyring 2.20 and gdm uses it
[12:28:26] <seb128> Mithrandir: yes libpam-gnome-keyring
[12:28:40] <Keybuk> there's a checkbox in the gnome-keyring password dialog now isn't there?
[12:28:47] <Keybuk> [ ] Unlock keyring on login
[12:28:48] <Keybuk> or something
[12:28:55] <Keybuk> (it doesn't work if you use auto-login of course ... :p)
[12:29:01] <seb128> right
[12:29:06] <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.
[12:29:19] <seb128> if anybody who knows pam would like to help me to get it working with autologin that would be nice
[12:29:45] <seb128> also integrating it with passwd should work but I didn't do the packaging changes
[12:29:52] <seb128> so when the password is changing the keyring one is updated
[12:30:05] <cjwatson> seb128: you might want to grab Steve for that
[12:30:08] <cjwatson> (pam/autologin)
[12:30:12] <seb128> cjwatson: right
[12:30:33] <seb128> http://live.gnome.org/GnomeKeyring/Pam has details also, I need to try with that, I've just been too busy
[12:30:55] <seb128> MootBot: that was not for you :p
[12:31:11] <Keybuk> ok, thanks everyone
[12:31:45] <Keybuk> any other business?
[12:32:43] <Keybuk> #endmeeting
Meeting ended.