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