20080312

Log

TZ UTC-4

(02:59:29 AM) cjwatson: doko: ping
(03:00:03 AM) ogra: TheMuso, sounds like some kind of southamerican pimp :)
(03:00:08 AM) doko: good morning
(03:00:10 AM) TheMuso: ogra: I know.
(03:00:14 AM) TheMuso: :)
(03:00:22 AM) evand: calc: pff, a cakewalk
(03:00:26 AM) cjwatson: aha, welcome
(03:00:56 AM) cjwatson: right, I only have two activity reports this week; I hope that the rest are stuck in a mail queue (I think my mail reception doesn't work so well overnight for some reason)
(03:01:11 AM) ***cjwatson blinks and realises he clearly can't count
(03:01:11 AM) ***TheMuso saw a lot on the ml./
(03:01:28 AM) ArneGoetje: I just submitted mine a few minutes ago... sorry for that
(03:01:31 AM) ***ogra just sent his ... with wrong date first place ...
(03:01:32 AM) calc: cjwatson: more coffee?
(03:01:50 AM) cjwatson: ah, I counted ogra twice and made it nine without bothering to check all the names :) sorry Steve
(03:01:54 AM) slangasek: :-)
(03:02:25 AM) cjwatson: ok, somebody else will have to say if there are agenda items in activity reports
(03:02:25 AM) ogra: yeah, we're easy to mix up :P
(03:02:41 AM) ArneGoetje: 2 in my one
(03:03:09 AM) cjwatson: so I wanted to talk first about scim, since there has been a lot of user confusion about scim accidentally being enabled for them, and I want to make sure we have a clear plan to ensure this is fixed for beta
(03:03:30 AM) ArneGoetje: cjwatson: it is fixed already
(03:03:33 AM) cjwatson: at the moment it looks like live CDs and fresh installs don't have it switched on, but that users sometimes get it enabled on upgrade
(03:03:50 AM) cjwatson: ArneGoetje: somebody reported breakage on upgrade just yesterday
(03:03:51 AM) asac: i don't know if i forcefully uninstalled it, but its not enabled for me anymore. it was rather annoying a week ago.
(03:04:07 AM) ArneGoetje:  * scim enabled by default for non-CJK locales: This has been resolved
(03:04:07 AM) ArneGoetje: with the latest scim and scim-bridge updates. On a current Live CD the
(03:04:07 AM) ArneGoetje: old behaviour, where scim is by default disabled for non-CJK locales can
(03:04:08 AM) ArneGoetje: be observed. Upgrading from Gutsy to Hardy should work fine also,
(03:04:08 AM) ArneGoetje: however I haven't tested it yet. For users who followed the Hardy
(03:04:10 AM) ArneGoetje: development manual interaction is required though. Calling
(03:04:13 AM) ArneGoetje: Language-selector, unchecking the checkbox and doing a re-login should
(03:04:15 AM) ArneGoetje: be sufficient.
(03:04:16 AM) calc: i had to go back to gutsy for my vmware session for other reason so i didn't see if it got fixed for my issue
(03:04:27 AM) cjwatson: ArneGoetje: ah, is that a change since yesterday?
(03:04:47 AM) calc: but it hasn't seemed to have affect my two hardy systems
(03:04:52 AM) ArneGoetje: cjwatson: no, I updated the packages a few days ago.
(03:05:08 AM) cjwatson: ArneGoetje: there have been reports since then; the evidence suggests that upgrades are still broken
(03:05:35 AM) cjwatson: somebody just yesterday reported upgrading from alpha-6 to current and having scim enabled
(03:05:54 AM) ogra: i didnt have any trace of scim on yesterdays classmate image
(03:05:58 AM) _czessi is now known as Czessi
(03:06:03 AM) ArneGoetje: cjwatson: for users who follow Hardy for a longer period, manual interaction is required to fix this. Language-selector -> uncek the checkbox -> re-login should fix it.
(03:06:08 AM) slangasek: well, presumably neither I nor the other bug reporter followed the "calling language-selector" step?
(03:06:13 AM) ogra: i mean of it getting in my way ... its installed indeed
(03:06:32 AM) slangasek: OTOH, where *is* language-selector? I don't seem to have it on my system
(03:06:43 AM) ArneGoetje: cjwatson: Live CD from Mar 9 had it fixed already
(03:06:48 AM) cjwatson: ArneGoetje: OK, I'll be happy if gutsy->hardy (and ideally also dapper->hardy) are tested for this before beta
(03:06:55 AM) cjwatson: ArneGoetje: could you organise that?
(03:07:06 AM) ArneGoetje: slangasek: System -> Administration -> Language Support
(03:07:07 AM) cjwatson: slangasek: we should add Arne's comment above to the release notes
(03:07:26 AM) slangasek: cjwatson: ack
(03:07:43 AM) ArneGoetje: cjwatson: will do.
(03:07:54 AM) cjwatson: ArneGoetje: is there any way to sanely spot the breakage and revert it without also overwriting user customisations?
(03:08:07 AM) cjwatson: three's been a lot of noise on #ubuntu-devel, #distro, #canonical, well just about everywhere about it
(03:08:15 AM) cjwatson: Scott has been taking a lot of heat for it too
(03:08:30 AM) cjwatson: (since everyone assumes it's a desktop thing)
(03:08:44 AM) ArneGoetje: cjwatson: not really... see my comments in bug #199030
(03:08:50 AM) slangasek: override the alternative on upgrade only if it's set to the expected value and we're upgrading from the problematic version?
(03:09:49 AM) ArneGoetje: cjwatson: short explanation:
(03:10:53 AM) ArneGoetje: cjwatson: some time in the past the function to enable/disable scim in language-selector broke and the link in /etc/X11/xinit/xinout.d/ for all_ALL was set by default.
(03:11:32 AM) ArneGoetje: cjwatson: as we cannot detect which user enabled it on purpose and who didn't, we cannot fix it by script, can we?
(03:11:59 AM) ogra: you could ask
(03:13:15 AM) slangasek: by "set by default", you mean "update-alternatives was misused from a maintainer script"?
(03:13:15 AM) slangasek: or something else?
(03:13:15 AM) ogra: like the directory conversion tool does
(03:13:15 AM) ogra: its ugly but helps
(03:13:15 AM) ArneGoetje: slangasek: I'm not sure what caused it actually.. I just remember that I couldn't uncheck the checkbox anymore...
(03:13:15 AM) cjwatson: I'm not convinced that all these users had ever seen the language-selector UI
(03:13:15 AM) slangasek: I hadn't :)
(03:13:15 AM) cjwatson: it feels much more like an update-alternatives accident to me
(03:13:23 AM) ArneGoetje: cjwatson: as I said, I'm not sure what caused the breakage...
(03:13:34 AM) calc: it affected my vmware image when i hadn't done anything with it, of course it wasn't a local fresh install (got it off the site)
(03:13:38 AM) cjwatson: that means we need to be extra-careful about testing it
(03:13:50 AM) calc: it was a image that was upgraded from gutsy
(03:13:53 AM) cjwatson: if you aren't sure what caused it, it doesn't seem that you can say that it happened during hardy development
(03:14:20 AM) cjwatson: and we should probably put some effort into tracking down what *did* cause it
(03:14:34 AM) cjwatson: report is that alpha-6 -> current reproduces it, so perhaps we should start there
(03:14:35 AM) ArneGoetje: the bug was triggered recently with the seeding of im-switch. when im-switch is not installed on the system, scim can't be started at all. that's why it hadn't surfaced earlier.
(03:14:48 AM) cjwatson: indeed
(03:15:11 AM) cjwatson: but it's a very serious problem when it does show up, so it is our responsibility to understand it as much as we can
(03:15:42 AM) slangasek:   * debian/scim.postinst: disable u-a calls for all_ALL; remove the
(03:15:42 AM) slangasek:     scim-bridge entries again... they should go into the scim-bridge package.
(03:15:44 AM) cjwatson: while I'm happy with "hardy users have to do some magic to recover" if that's necessary, it would be better for that not to be required
(03:16:01 AM) slangasek: ArneGoetje: that's from the most recent changelog on scim; what was the u-a call being disabled?
(03:16:28 AM) ArneGoetje: slangasek: that was the fix, yes
(03:16:33 AM) cjwatson: also, was the removal of those alternatives from postinst accompanied by a prerm change to remove existing alternatives on upgrade?
(03:16:43 AM) slangasek: ArneGoetje: "what" was the u-a call being disabled? :)
(03:17:16 AM) cjwatson: hmm, apparently those alternatives are unconditionally removed on upgrade
(03:18:09 AM) cjwatson: slangasek: it's the one that's commented out in scim.postinst at the moment
(03:18:12 AM) cjwatson:         #ua_inst all_ALL scim  0
(03:18:13 AM) cjwatson:         #ua_inst all_ALL scim-immodule 0
(03:18:13 AM) ArneGoetje: slangasek: before it was set to scim-bridge, as well as additiinal entries to scim and scim-immodule, but with lower priority. that was amistake
(03:18:15 AM) slangasek: ok, those are just removals of calls to ua_inst(), which currently DTRT
(03:18:20 AM) cjwatson: oh, no, I'm wrong
(03:18:22 AM) slangasek: so it's not the culprit for the manual u-a
(03:18:46 AM) cjwatson: ArneGoetje: we have some empirical evidence that update-alternatives has ended up in manual mode for the xinput-all_ALL alternative
(03:18:50 AM) cjwatson: in the buggy cases
(03:19:05 AM) cjwatson: this class of problem is traditionally an absolute bastard to track down, but usually worth it
(03:19:26 AM) cjwatson: (and sometimes is a bug in update-alternatives, which is one of the least reliable programs in the dpkg toolchain)
(03:19:28 AM) ArneGoetje: cjwatson: they will also be removed in prerm
(03:20:15 AM) cjwatson: worst case, as ogra suggests, a debconf question on upgrade might be the least ugly solution
(03:20:47 AM) slangasek: hrm, I don't remember if u-a --remove DT"R"T if called for an alternative in manual mode that's pointed at the entry you're removing
(03:21:12 AM) slangasek: so the alternative was reported to be wrong in the alpha-6 liveCD?
(03:21:33 AM) cjwatson:     if ($mode eq "manual" and $state ne "expected" and (map { $hits += $apath eq $_ } @versions) and $hits and $linkname eq $apath) {
(03:21:37 AM) cjwatson:         &pr(_g("Removing manually selected alternative - switching to auto mode"));
(03:21:39 AM) slangasek: should be traceable in that case
(03:21:40 AM) cjwatson:         $mode = "auto";
(03:21:43 AM) cjwatson:     }
(03:21:46 AM) cjwatson: it's supposed to, at least
(03:22:00 AM) cjwatson: I'm not sure if it was desktop or alternate, the report wasn't detailed enough
(03:22:06 AM) slangasek: cjwatson: well, that means that every package upgrade resets the value...
(03:22:20 AM) slangasek: since they're all being unregistered in prerm and reregistered in postinst
(03:22:24 AM) cjwatson: hah, yes, apparently
(03:22:35 AM) cjwatson: this is one of the broken modes of update-alternatives use
(03:22:42 AM) slangasek: yep
(03:22:47 AM) cjwatson: (which is UNDOCUMENTED, gah policy rant)
(03:23:05 AM) slangasek: so I'll dig into the livefs and see if I can confirm the broken alternative there
(03:24:01 AM) ubotu: Launchpad bug 199030 in scim "Can't close SCIM" [High,Fix released] https://launchpad.net/bugs/199030
(03:24:19 AM) doko_: fixing bugs in update-alternatives for hardy+1 would be nice ...
(03:24:32 AM) ***cjwatson would just like to say http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71621
(03:24:44 AM) ubotu: Debian bug 71621 in debian-policy "No policy on calling update-alternatives (was Re: update-alternatives)" [Wishlist,Fixed]
(03:24:55 AM) cjwatson: (which Manoj closed out of hand)
(03:25:02 AM) slangasek: heh
(03:25:14 AM) slangasek: you could reopen it now that Russ is a policy maintainer :-)
(03:25:20 AM) cjwatson: I think I might
(03:26:10 AM) cjwatson: slangasek: could you continue to work with Arne to try to nail this down?
(03:26:53 AM) slangasek: yes
(03:27:00 AM) cjwatson: great, thanks
(03:27:16 AM) cjwatson:  * Beta status
(03:27:27 AM) cjwatson: I know we aren't quite frozen yet - anything interesting to report?
(03:27:43 AM) TheMuso: Wubi installs onto FAT32 partitions are currently a non-event.
(03:27:58 AM) cjwatson: I wonder if those should just plain be blacklisted
(03:28:06 AM) cjwatson: "doctor, it hurts when I do this"
(03:28:32 AM) slangasek: beta is the milestone where aaaaaall the bugs have landed that weren't critical for the alphas
(03:28:46 AM) TheMuso: Spent time with Agostino today debugging a few things, but still an issue somewhere, where abouts I'm not sure yet.
(03:28:47 AM) ***ogra is heavily disappointed by ram usage of the i810 driver on the classmate ... 
(03:28:59 AM) slangasek: so there's some triaging to be done, but more importantly there's plenty of bugfixing we should be doing too :)
(03:28:59 AM) TheMuso: cjwatson: Sounds sane to me, since NTFs allows for much larger files, and we can now write to it anyways.
(03:29:15 AM) ogra: i tried the intel driver by accident, it takes over 30M less reserved ram :(
(03:29:22 AM) slangasek: (.oO wubi to umsdos...)
(03:29:52 AM) TheMuso: slangasek: Yes, installing onto FAT32 bails out on first attempted boot from the loop mounted FS.
(03:30:15 AM) slangasek: TheMuso: oh, sorry, I thought I was making a umsdos joke
(03:30:24 AM) cjwatson: that is rather a lot of bugs
(03:30:56 AM) calc: ugh no umsdos die die die
(03:30:57 AM) evand: ZipSlack will make a comeback someday ;)
(03:31:11 AM) ogra: yay
(03:31:17 AM) calc: umsdos on fat16... really good way to eat up all clusters
(03:31:32 AM) cjwatson: bug 193842 looks complex, and better sooner than later if it's going to land
(03:31:35 AM) ubotu: Launchpad bug 193842 in acpi-support "Please sponsor cherrypicked fixes for acpi-support into Hardy" [Medium,Triaged] https://launchpad.net/bugs/193842
(03:33:01 AM) ogra: are we sure these scripts are executed at all with the new power management structure ?
(03:33:26 AM) ***ogra knows modules he lists in /etc/default/acpi-support are definately not unloaded anymore
(03:33:29 AM) slangasek: well, I know things aren't firing that I'm expecting to on my Thinkpad
(03:34:15 AM) slangasek: but I'm not sure whether that's a kernel issue
(03:34:22 AM) ogra: all i know is that with hardy the PM structure changed a lot leaving everything to hal, having mjg59 taking a look at that bug would be a good thing imho
(03:34:35 AM) calc: btw are systems supposed to make noise now on sleep/wake?
(03:34:43 AM) cjwatson: it wouldn't hurt, but since he's formally left the project we cannot rely on him to do it
(03:34:43 AM) calc: i noticed my laptop started doing that a while back
(03:35:00 AM) doko_: had a lot of problems with the lcd brightness not coming up again after sleeping
(03:35:09 AM) doko_: but current kernel works
(03:35:19 AM) ogra: calc, it does that on lid open/close as well ... gpm doesnt have a fine grained scheme for it and just makes noise for everything or nothing
(03:35:39 AM) calc: ogra: ah
(03:35:40 AM) slangasek: calc: there's a g-p-m change, if you look under preferences there's "Use sound to notify in event of an error"... it seems to believe that everything is an error
(03:35:52 AM) dholbach: acpi-support has ~18 bugs with patches attached: http://daniel.holba.ch/really-fix-it
(03:36:00 AM) ogra: i had disabled it in the past because i didnf fid it suitable without being able to tag events for noise specifically
(03:36:00 AM) cjwatson: ok, we could probably keep on looking at ACPI bugs all day, but I gathered there were a few other agenda items
(03:36:28 AM) calc: slangasek: yea it always claims my system doesn't suspend properly but it seems to afaict
(03:36:30 AM) slangasek: who else do we have that's versed in the current power management structure then?
(03:36:35 AM) slangasek: pitti?
(03:36:59 AM) ogra: slangasek, ted does the frontend and matthew the acpi and parts of the kernel stuff
(03:36:59 AM) cjwatson: pitti is usually a good start for matters of hardware-from-userspace
(03:37:11 AM) bryce: it suddenly got awfully quiet - is this thing still on?  *pff pff*
(03:37:12 AM) ogra: for hardcore kernel things amit is also a good resource
(03:37:21 AM) cjwatson: and as ogra says Ted has been taking on gnome-power-manager maintenance
(03:37:46 AM) cjwatson: bryce: there's been pretty steady conversation for the last 30+ minutes
(03:38:41 AM) bryce: weird, irc was being hangy.  seems better now
(03:38:44 AM) dholbach: g-p-m has 14 bugs open on http:/daniel.holba.ch/really-fix-it - if we can't review them, maybe we should forward them upstream and see what hughsie says
(03:39:02 AM) cjwatson: could somebody volunteer to review and sponsor that acpi-support change, please?
(03:39:24 AM) cjwatson: I suspect that, if it's any good, Daniel Hahler may end up as the de facto acpi-support maintainer ;-)
(03:39:26 AM) slangasek: I've already followed up to an acpi-support sponsor request, because some of the proposed changes affect my hardware
(03:39:54 AM) slangasek: I can follow through
(03:40:25 AM) cjwatson: much appreciated
(03:41:09 AM) cjwatson: ArneGoetje: you said you had some other agenda items?
(03:41:31 AM) ArneGoetje:  * There is a crash report for scim-bridge which has lots of duplicates
(03:41:31 AM) ArneGoetje: by now. However, I cannot reliably reproduce it. People claim
(03:41:31 AM) ArneGoetje: scim-bridge crashes on startup. However, on a recent Live CD and also on
(03:41:31 AM) ArneGoetje: my local system, there is no crash.
(03:41:31 AM) ArneGoetje: When installing the Live CD from 3 days ago, after reboot, I activated
(03:41:33 AM) ArneGoetje: scim support in Language-Selector and did a reboot. After then I opened
(03:41:35 AM) ArneGoetje: a terminal and toggeled scim repeatedly by pressing crtl+space multiple
(03:41:38 AM) ArneGoetje: times. The crash happened once and never again. Also inputting complex
(03:41:41 AM) ArneGoetje: scripts with scim worked. So, as I cannot reliably reproduce this crash,
(03:41:43 AM) ArneGoetje: I'm asking for help.
(03:42:13 AM) slangasek: no apport retracer data on it
(03:42:14 AM) slangasek: ?
(03:42:43 AM) ArneGoetje: slangasek: the bug has apport data attached.
(03:42:52 AM) slangasek: bug #?
(03:43:44 AM) ArneGoetje: bug #199592
(03:44:29 AM) ***slangasek whimpers
(03:44:46 AM) slangasek: that looks like conflicting libstdc++ versions to me
(03:45:06 AM) ArneGoetje: So, basically my question is, why it happens only in some situations, and whether it really is a scim-bridge bug or libscim, which is in the scim package, or somewhere else...
(03:45:42 AM) ArneGoetje: I noticed there were some linstdc++ updates in the past days...
(03:46:12 AM) slangasek: I'm thinking of the class of crash that's caused by having two different libstdc++ sonames loaded in memory at the same time
(03:46:29 AM) ***ArneGoetje has no idea about that
(03:46:32 AM) slangasek: it classically affects XIM because XIM is one of the few things that's dynamically loaded by a large range of apps, *and* is written in C++
(03:46:59 AM) cjwatson: this is the actual scim-bridge process though, not a random client
(03:47:05 AM) doko_: but even the fglrx driver now uses libstdc++.so.6
(03:47:32 AM) slangasek: right; I don't know for sure that's the same problem here, but it's the first thing I think of when I see unreproducible crashes in a C++ deconstructor
(03:47:54 AM) cjwatson: could of course be a poorly-written destructor
(03:48:00 AM) slangasek: true
(03:48:11 AM) doko_: hmm, when was scim-bridge built the last time?
(03:48:29 AM) slangasek: 6 days ago
(03:48:46 AM) doko_: ok
(03:49:29 AM) cjwatson: scim::Module::unload is not exactly trivial ...
(03:49:52 AM) cjwatson: calls a bunch of other stuff, does dlclose, etc.
(03:50:13 AM) cjwatson: but the crash doesn't always seem to be there, either
(03:50:29 AM) cjwatson: it might be worth running scim-bridge under valgrind
(03:51:06 AM) cjwatson: doko_: could you help Arne out with this?
(03:51:34 AM) doko_: cjwatson: trying, but probably not before Tuesday
(03:52:22 AM) cjwatson: ok, if the other problems with scim being started by default get fixed, then it will only affect CJK users (for whom presumably it isn't a regression)
(03:52:50 AM) ArneGoetje: for CJK users it's expected behaviour
(03:53:00 AM) cjwatson: a crash is not expected behaviour
(03:53:04 AM) cjwatson: without loss of generality
(03:53:31 AM) ArneGoetje: I mean scim being started by default :P
(03:53:38 AM) cjwatson: right, but I didn't :-)
(03:53:42 AM) ArneGoetje: got it
(03:53:45 AM) cjwatson: I meant that the crash has presumably been around for a while
(03:54:00 AM) cjwatson: I'll un-private that bug and stick it on the hardy list
(03:54:13 AM) ArneGoetje: thanks
(03:54:31 AM) cjwatson: any other business?
(03:54:35 AM) asac: two quick questions:
(03:54:36 AM) TheMuso: Yes, a quick one re minutes.
(03:54:43 AM) TheMuso: asac: go
(03:54:45 AM) asac: NetworkManager: does anyone experience issues since 0.6.6? i am especially interested in ipw2X00, madwifi and broadcom things.
(03:55:03 AM) cjwatson: broadcom seems OK for me so far
(03:55:06 AM) doko_: cjwatson: some things ...
(03:55:12 AM) ***ogra is very happy with it on his laptop and on the classmate
(03:55:17 AM) ***TheMuso hasn't used his ipw2100 for a fair while, but will try with the latest daily.
(03:55:23 AM) ogra: (laptop == broadcom as well)
(03:55:24 AM) asac: TheMuso: please do
(03:55:31 AM) asac: i dropped a bunch of driver tweaks
(03:55:36 AM) doko_: do we want to have bash-completion installed on the desktop?
(03:55:45 AM) asac: and its hard to judge from bugs if that is just after-upgrade-"noise"
(03:55:56 AM) asac: 2nd. did anyone retrieve my activity report last week?
(03:55:57 AM) ***ArneGoetje has ipw2200... will try tonight... (no wireless here right now)
(03:56:01 AM) doko_: some users think so, but others disagree. if it's installed, it is enabled by default
(03:56:05 AM) ogra: doko_, is it big ? does it do any harm sitting on the disk ?
(03:56:21 AM) cjwatson: 3010     Mar 05 Alexander Sack  (  74) [ACTIVITY] Feb 27 - Mar 04 (asac)
(03:56:24 AM) doko_: no harm on the list
(03:56:24 AM) cjwatson: 3069   L Mar 12 Alexander Sack  (  59) [ACTIVITY] Mar 05 - Mar 11
(03:56:24 AM) asac: ArneGoetje: highly appreciated. i have reports about it being broken
(03:56:27 AM) Hobbsee: asac: wfm, ipw3945 (know it's not exactly your target group)
(03:56:28 AM) slangasek: wasn't it installed by default before (as part of bash)?
(03:56:41 AM) ArneGoetje: asac: orz
(03:56:46 AM) doko_: 120k
(03:56:47 AM) cjwatson: doko_: I never wanted it enabled by default in the first place, but considered that I'd lost that battle
(03:56:47 AM) ***TheMuso wondered where his useful completion went.
(03:56:53 AM) TheMuso: s/his/the/
(03:56:53 AM) asac: cjwatson: ok thanks. i still didn't get that. just want to be sure because it contained some valuable content about mozilla translations imo
(03:57:09 AM) TheMuso: I can live with not having it by default.
(03:57:12 AM) ogra: doko_, pfft
(03:57:14 AM) doko_: slangasek: yes, but I got tired, never getting any replies from upstream
(03:57:16 AM) ogra: thats nothing
(03:57:32 AM) asac: ok if you could try all the chipsets you have around i would be happy to receive feedback
(03:57:39 AM) ogra: imho we should have it ... its comfortable
(03:57:42 AM) TheMuso: asac: Will keep you posted.
(03:57:43 AM) asac: TheMuso: go
(03:57:53 AM) cjwatson: the only thing that ever concerned me about bash-completion was shell startup time
(03:57:55 AM) doko_: in the case we still want it, I'd like to seed it for desktop, so that people can uninstall it on the server
(03:58:05 AM) calc: asac: not sure if this is expected but it seems nm still drops connection on upgrades
(03:58:13 AM) cjwatson: mainly affecting people like us who start lots of shells
(03:58:18 AM) TheMuso: Ok. re minutes, this is the 4th week I've done it. While I don't mind doing them, I wonder if people would be up for doing 4 weekly stints of minutes, and then moving onto someone else?
(03:58:32 AM) asac: calc: thats expected. i will fix that for final (e.g. don't restart at all)
(03:58:38 AM) calc: asac: ok
(03:58:42 AM) doko_: ok, but the lots of you can then remove or disable it
(03:58:42 AM) ogra: cjwatson, well, give that the terminal we use already grabs 20-25M and is slow anyway, who cares ...
(03:58:47 AM) ogra: *given
(03:58:54 AM) asac: not restarting is the official advice from upstream :(
(03:58:59 AM) cjwatson: ogra: might be the terminal *you* use :-P
(03:59:12 AM) ogra: cjwatson, i use the one *we* install by default :)
(03:59:15 AM) doko_: any disagreement to seed bash-completion again?
(03:59:22 AM) ogra: the one our users use :)
(03:59:25 AM) cjwatson: doko_: remove/disable> indeed, I do, but still
(03:59:39 AM) cjwatson: doko_: bash-completion is a Recommends at present, so it looks like it can be removed already
(03:59:40 AM) doko_: we can keep it in universe as well
(04:00:01 AM) cjwatson: in fact, I appear not to have it installed, presumably by accident
(04:00:15 AM) cjwatson: ogra: (yeah, this is my one deviation from that rule which I normally do apply to myself)
(04:00:59 AM) doko_: next thing: shorewall - do we want to have this in main?
(04:01:10 AM) cjwatson: I have no objection to bash-completion either being seeded or unseeded; if it is seeded, it should be as a recommends (" * (bash-completion)")
(04:01:14 AM) ogra: i use xterm on the classmate i must admit :)
(04:01:27 AM) cjwatson: hang on, let's serialise these agenda items
(04:01:33 AM) ogra: doko_, i thought that was gone after th discussion a month ago
(04:01:43 AM) cjwatson: 07:58 <TheMuso> Ok. re minutes, this is the 4th week I've done it. While I don't mind doing them, I wonder if people would be up for doing 4 weekly stints of minutes, and then moving onto someone else?
(04:02:42 AM) cjwatson: I have no objection to rotating the secretary job if there are other volunteers
(04:03:15 AM) cjwatson: TheMuso: BTW, as a small tweak, it would be good to have an explicit Actions section at the end with any specific follow-on tasks that have been agreed; I find that useful when it comes to the next meeting
(04:03:31 AM) TheMuso: cjwatson: Ok thanks for feedback.
(04:03:48 AM) cjwatson: would anyone else like to do this after Luke, with the knowledge that it's for a bounded time?
(04:04:25 AM) TheMuso: Ok, I'm quite happy to keep doing them for the time being.
(04:04:26 AM) doko_: I volunteer, but not for the next two weeks
(04:05:07 AM) bryce: I can take May
(04:05:32 AM) cjwatson: thanks, I'm sure even a rotation of three will help; sort it out among yourselves :-)
(04:05:36 AM) cjwatson: doko_: so, shorewall
(04:05:44 AM) cjwatson: as contrasted with ufw, presumably
(04:06:12 AM) doko_: ok, I'll re-add it to the seeds, with a comment
(04:06:25 AM) cjwatson: ... (I didn't think that was a decision)
(04:06:33 AM) doko_: oops
(04:06:45 AM) cjwatson: shorewall was in main up to gutsy, so I certainly have no objection to it being added back
(04:07:05 AM) doko_: once the bashims were fixed it looks rather stable
(04:07:07 AM) cjwatson: you removed it, I see
(04:07:09 AM) cjwatson:   - remove shorewall from server-ship (ufw is in main)
(04:07:39 AM) slangasek: it's not the killer firewall, but ufw isn't today either; and shorewall gives users functionality that ufw doesn't
(04:07:50 AM) doko_: yes, but it's still referenced in Kubuntu hardy
(04:07:53 AM) cjwatson: my gut feeling is that ufw is rather new and relatively untried compared to shorewall, and, while ufw may well turn out to be the future once it's well-integrated, a lot of people will still want to use shorewall for good reasons
(04:08:09 AM) cjwatson: so I think we should ship it
(04:08:27 AM) ***ArneGoetje is happily using shorewall on all my machines, including laptop :)
(04:08:50 AM) cjwatson: technically it should be a server team decision, mind you
(04:09:53 AM) doko_: I'll bring it to their attention
(04:10:07 AM) doko_: next: any actions about duplicates/unnecessary files on the CDs?
(04:10:12 AM) cjwatson: but I think it's fine to go for status quo (i.e. ship shorewall, as in gutsy) until they explicitly say otherwise
(04:10:35 AM) cjwatson: which would correspond to "use ufw in all cases, damn your eyes"
(04:11:00 AM) cjwatson: can we carry on discussing duplicates/unnecessary files on the list?
(04:11:13 AM) cjwatson: or perhaps on ubuntu-devel@, since it's currently distro-team@
(04:11:21 AM) cjwatson: just conscious that we're over time
(04:11:25 AM) doko_: fine with me, sending then to u-d
(04:11:29 AM) asac: i have another quick one about seeds: the crash reporter of mozilla upstream builds doesn't work in default installs, because we don't ship ca-certificates. any arguments against shipping them?
(04:11:45 AM) asac: (or make curl depend on ca-certificates)
(04:12:05 AM) cjwatson: I'm sure we used to ship ca-certificates?
(04:12:08 AM) ogra: didnt we ship the before ?
(04:12:17 AM) asac: i think so ... i guess one rdepends got removed from cd
(04:12:36 AM) cjwatson: no objection to shipping them provided that its (crazy) debconf question doesn't get asked by default
(04:12:51 AM) cjwatson: unfortunately I suspect it does get asked by default on upgrades, worth checking its priority
(04:12:51 AM) asac: yes. afaik you don't get asked about that
(04:13:23 AM) asac: hmm ... really? i never saw any question. but maybe thats because the packages wasn't updated for a while
(04:13:31 AM) asac: i can check that
(04:13:33 AM) asac: thanks
(04:13:42 AM) cjwatson: I'm just going on vague memory, I'm afraid
(04:13:55 AM) cjwatson: ca-certificates was in dapper/desktop
(04:14:08 AM) cjwatson: dependency of libcurl3
(04:14:42 AM) cjwatson: apparently it fell out in gutsy
(04:14:54 AM) asac: hmmm ... libcurl3-gnutls has a recommends on it now
(04:15:18 AM) cjwatson: might have to duplicate that recommendation in the seeds, then, until such time as we do recommends-by-default
(04:15:26 AM) asac: yep
(04:15:27 AM) asac: thanks
(04:15:31 AM) cjwatson: which I think fell out of hardy because the ball was in too many people's courts
(04:15:43 AM) cjwatson: ok, 15 minutes over time, so let's adjourn
(04:15:45 AM) cjwatson: thanks all

MeetingLogs/UbuntuDev/20080312 (last edited 2008-08-06 16:31:55 by localhost)