[01:48] <pitti> hello
[01:54] <Hobbsee> hi pitti
[01:54] <Keybuk> mvo, MacSlow, Mithrandir: ping ?
[01:55] <Keybuk> (I suddenly realise that an interestingly large portion of my team begins their nickname with "M")
[01:55] <kwwii> I picked kwwii just so I would have a K, like you :p
[01:55] <Mithrandir> good morning
[01:56] <Keybuk> Mirco just lost power
[01:56] <Mithrandir> we should just name the team reporting-to-Scott-team to avoid any confusion
[01:57] <Hobbsee> heh
[01:57] <mvo> hey Keybuk
[01:57] <DrPepperKid> test 1..2..3..
[01:57] <Keybuk> Hobbsee: it's the meeting of the team that's a subset of both :p
[01:58] <Keybuk> DrPepperKid: that was quick!
[01:58] <Hobbsee> Keybuk: right then :P
[01:58] <Mithrandir> Keybuk: and some others. :-P
[01:58] <DrPepperKid> Keybuk, I'll see how long it lasts
[01:58] <DrPepperKid> *sigh*
[01:58] <pitti> DrPepperKid: pedal faster!
[01:58] <Keybuk> I did send out a quick mail about an hour ago for agenda items
[01:58] <Keybuk>  * Update on compiz decision from TB
[01:58] <Keybuk>  * Compiz bug update from mvo and Mirco
[01:58] <Keybuk>  * Herdy planning
[01:59] <Keybuk> did anyone have anything to add to that?
[01:59] <pitti> does 'herdy planning' involve some sponsoree issues?
[02:00] <pitti> (invited people for UDS)
[02:00] <Keybuk> pitti: it can do, depending on what you want to discuss?
[02:00] <Keybuk> if particular people are involved, it may be better to raise that privately since this is a public meeting
[02:00] <pitti> just an update how we should proceed
[02:00] <DrPepperKid> I just got the "short term" announce... power will be off for an hour or so... *sigh*
[02:01] <Keybuk> pitti: let's discuss that afterwards
[02:01] <pitti> 'k
[02:02] <mvo> is MacSlow here yet
[02:02] <mvo> ?
[02:02] <Keybuk> mvo: he came and went
[02:02] <Keybuk> mvo: but please do give us a quick update on how compiz is going
[02:03] <ogra> mvo, he was hiding behind DrPepperKid :)
[02:03] <Keybuk> now that the Technical Board have agreed to ship with compiz
[02:03] <mvo> ok
[02:03] <mvo> the bug situation is not too bad currently. upstream is very active and helpful
[02:03] <mvo> especially danny baumann and amaranth (thanks!)
[02:04] <mvo> we may have to blacklist nvidia if the xserver problem does not get sorted (patch 132 breaks the 1.3 abi)
[02:04] <mvo> we may have to blacklist mga (or g450) because its too slow
[02:05] <Keybuk> how is video playback going?
[02:06] <Keybuk> I saw that Mez blogged about it not working, was that related or unrelated?
[02:06] <pitti> yesterday, ati was blacklisted; is there any video driver besides intel which is still enabled, btw?
[02:06] <Keybuk> (with xine, at least)
[02:06] <mvo> pitti: there will be another upload today that just blacklists rs480
[02:06] <pitti> mvo: ah, cool
[02:06] <mvo> I have not seen mez blog post yet
[02:07] <pitti> mvo: and the ABI change cannot be accounted for in the sourceful part of nvidia?
[02:07] <mvo> but video works for most people, but *not* for intel on i965
[02:07] <mvo> #111257
[02:07] <mvo> bug #111257
[02:07] <ubotu> Launchpad bug 111257 in xserver-xorg-video-intel "totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver" [High,Confirmed]  https://launchpad.net/bugs/111257
[02:07] <Keybuk> mvo: do we know what causes that?
[02:08] <Keybuk> is there a fix likely?
[02:08] <mvo> now I though I had fixed that with the xf86VFillKeyHelperDrawable patch, but that seems to be not the case
[02:08] <mvo> but I do not have hardware myself to test so its a bit difficult for me currently
[02:08] <mvo> pitti: apparently not, patch 132 is important for ubuntu-mobile but breaks nvidia
[02:09] <mvo> Keybuk: I honestly don't know yet
[02:09] <pitti> mvo: right, I meant changing the nvidia driver itself to adapt to the new API
[02:09] <Keybuk> mvo: do we know anyone with that hardware?
[02:09] <mvo> I will try to find someone
[02:09] <mjg59> Xv will not work for 965 under compiz if XAA is used. We discussed that at TB.
[02:10] <mvo> worst case is blacklisting this pciid
[02:10] <Mithrandir> mvo: 132 is important for upstream gtk too, since what it does is enabling inter-widget compositing.  At least, AIUI, from talking with seb.
[02:10] <mjg59> Choices are either (a) don't use compiz on 965, or (b) use EXA
[02:10] <Keybuk> mjg59: what's the downside to using EXA?
[02:11] <pitti> hi Amaranth, good to have you here!
[02:11] <Amaranth> i really need to start using some calendar software
[02:11] <Keybuk> (tangent: I really need that SoC guy to finish the evolution google calendar backend :p)
[02:11] <mjg59> Keybuk: Significantly less well tested, very different codepaths
[02:12] <mvo> mjg59: you went to XDS, right? what were the opionions about compiz-by-default there?
[02:12] <pitti> Amaranth: import the fridge calendar into evo
[02:13] <mvo> Amaranth: anything you want to add about the bug situation in compiz?
[02:13] <mjg59> mvo: On aiglx? That it wasn't sensible yet
[02:13] <Amaranth> i don't think so
[02:13] <Amaranth> same as the TB meeting
[02:13] <Amaranth> other than driver issues (which we can work around or blacklist) it's mostly little things
[02:14] <mvo> macslow is working on the workspaces layout bug currently
[02:14] <mvo> that is hopefully fixed soon too
[02:15] <Keybuk> ok, thanks
[02:15] <Amaranth> Keybuk: that's your pet bug, no?
[02:15] <Keybuk> Amaranth: I have lots of pet bugs
[02:15] <Amaranth> hehe
[02:15] <Keybuk> sometimes I forget to feed them
[02:16] <pitti> that one is one of my favourite's, too :)
[02:16] <mvo> use a flat layout!
[02:18] <mvo> Keybuk: we hope to attack more bugs on the compiz sprint next week
[02:18] <mvo> and we also hope for more user feedback/bugreports
[02:18] <Keybuk> indeed
[02:18] <mvo> now that its "offical"
[02:18] <Amaranth> man i got a lot of comments on my blog for that
[02:18] <Amaranth> so there is obviously interest :)
[02:18] <Keybuk> Amaranth: what kind of balance?
[02:19] <Amaranth> all negative :P
[02:20] <Amaranth> mostly asking if this means their pet driver bug will be fixed
[02:20] <Amaranth> or what happens for people with unsupported hardware
[02:20] <Amaranth> http://www.realistanew.com/2007/09/12/compiz-by-default-in-ubuntu-710/#comments
[02:21] <Keybuk> cool
[02:21] <mjg59> It wouldn't surprise me if r300 isn't especially stable
[02:21] <Keybuk> mvo: before the sprint, if you could check over the bug list and find those that are most user-affecting, etc.  that would be great
[02:22] <Keybuk> anyway, Herdy
[02:22] <Amaranth> Keybuk: i already did that
[02:22] <mvo> Keybuk: I plan to do that, yes
[02:23] <mvo> but Amaranth did great work already
[02:23] <Keybuk> 8.04 will be an LTS, in some form or other
[02:23] <mvo> is there more than one form ;) ?
[02:24] <pitti> so, no crazy new stuff? :)
[02:24] <Keybuk> the general thought is that new development is fine if it fixes problems
[02:24] <Keybuk> or improves usability, etc.
[02:25] <Keybuk> we want to tackle problems that matter most to our users as well, mdz is looking at some digg-like way of collecting the top problems
[02:25] <pitti> one thing I had in mind for hardy was an application for guided bug filing (decision-tree based); I guess stuff like this is appropriate?
[02:26] <pitti> (we already had that spec for gutsy, but it didn't get very far)
[02:26] <Keybuk> potentially; Henrik's new Desktop QA Developer will certainly help with that kind of thing :)
[02:27] <Keybuk> since we're especially looking at what users want, it's worth everyone going through things like:
[02:27] <Keybuk>  * https://wiki.ubuntu.com/IdeaPool
[02:27] <Keybuk>  * https://wiki.ubuntu.com/UsabilityWishlist
[02:27] <Keybuk>  * https://blueprints.launchpad.net/ubuntu
[02:27] <Keybuk> and seeing if there's any items in there that interest you
[02:27] <pitti> and maybe the long list of specs that users created
[02:28] <pitti> . o O { a sensible backup solution! }
[02:28] <Mithrandir> I need to come up with a list of development issues for UME, which is kinda on the side of what Ubuntu Desktop does.
[02:28] <mvo> backup++
[02:29] <pitti> mvo++; more time for bug fixing
[02:30] <Keybuk> so please, over the next week put together a list of problems to tackle
[02:30] <Keybuk> and then we'll discuss everyone's lists at the team meeting
[02:30] <Mithrandir> Keybuk: to what extent do you expect me to have complete lists for UME?
[02:30] <Keybuk> Mithrandir: I'm not sure, check with mdz :)  at least a partial list will be good though
[02:30] <Keybuk> he expressed some urgency to the planning
[02:31] <Keybuk> UME is more interesting simply because it's still in development
[02:31] <Keybuk> I'm not sure whether it's being considered for LTS or not
[02:32] <Mithrandir> I think we want to LTS it, simply because we'll have devices with it on in the field for quite a while.
[02:32] <Amaranth> stupid router
[02:32] <Mithrandir> and I don't think we'll have people doing dist-upgrades of their MIDs
[02:32] <Mithrandir> urgency> yes, everything about UME is urgent.  :-)
[02:33] <Keybuk> urgency to general planning, in fact
[02:34] <Keybuk> is there any other business?
[02:34] <Mithrandir> I don't have anything
[02:35] <pitti> let's go squash bugs
[02:35] <Amaranth> \o/
[02:35] <Keybuk> ok thanks all
[02:35] <pitti> 11 down, 3 to go \o/, so I might be able to help with the unassigned beta bugs soon, too
[02:36] <Keybuk> pitti: I expect you're glad we have a full time release manager starting on Monday :p
[02:36] <Amaranth> pitti: feel free to fix all the compiz bugs :)
[02:36] <pitti> indeed I am \o/
[02:36] <pitti> Amaranth: *cough*
[02:36] <pitti> Amaranth: in fact I am about to go to a shop and take a look at some shiny new laptops now :)
[02:36] <pitti> so that I can actually test it
[02:37] <pitti> Keybuk: although I guess that we'll do the beta release together, for mentoring?
[02:37] <Keybuk> I imagine so
[04:34] <ArneGoetje> @now
[04:34] <ubotu> Current time in Etc/UTC: September 13 2007, 14:34:08 - Next meeting: IRC Council in 3 days
[05:03] <dholbach> hey mvo :)
[05:03] <heno> Suggested agenda item: Tribe 6 and Beta bug status
[05:03] <ogra> @now
[05:03] <ubotu> Current time in Etc/UTC: September 13 2007, 15:03:26 - Next meeting: IRC Council in 3 days
[05:03] <asac> hi
[05:03] <pitti> hi
[05:04] <calc> hi
[05:04] <dholbach> It's not really an agenda item, but please all have a look at http://daniel.holba.ch/sponsoring - there are bugs which I might have assigned to you - please try to get back to patch authors
[05:04] <calc> pitti: btw i will look into fixing the office bean issue with the next upload of OOo
[05:04] <pitti> calc: thank you! appreciated
[05:04] <pitti> calc: when is that scheduled? IOW, when can we expect to have testable CDs again?
[05:05] <calc> pitti: oh it completely breaks the CD *wince* :\
[05:05] <evand> hi
[05:05] <pitti> calc: well, not completely break (VMWare testing is fine), but you cannot burn them
[05:05] <calc> pitti: i had hoped to do it after 2.3.0 is released on Monday but I can try to push that to sooner
[05:06] <pitti> calc: and TBH I have no idea how to free 12 MB on them
[05:06] <Mithrandir> just remove OOo? :-P
[05:06] <pitti> there are almost no langpacks left to remove (which is a pity on itself)
[05:06] <calc> pitti: will dropping office bean by itself be enough to fix the problem or should i look to some other things?
[05:06] <pitti> Mithrandir: ! why didn't I think about *that*?
[05:07] <heno> Could everyone please look at bugs on https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=473 assigned to them and try to give an updated ETA? (then we can move on to beta)
[05:07] <pitti> calc: should be fine, it pulls in java-gcj-compat and that big libgcj8-jar
[05:07] <Amaranth> do we use -Os when building?:)
[05:07] <Keybuk> heno: if only that view showed who they were assigned to <g>
[05:07] <calc> pitti: ok
[05:07] <pitti> heno: shouldn't we move all of those to beta straight away?
[05:08] <heno> pitti: we should I just though we could do a Tribe 6 wrap-up first
[05:08] <evand> CDs> As of yesterday they still have serious unionfs issues anyway
[05:08] <heno> our non-release milestone :)
[05:08] <mathiaz> for bug 120085, isn't it too late in the release cycle to introduce such a change ?
[05:08] <ubotu> Launchpad bug 120085 in sysklogd "Various problems running syslogd with "-u syslog" option" [Medium,Triaged]  https://launchpad.net/bugs/120085
[05:09] <pitti> heno: hm, I don't think that all tribe6 bugs are really more important than the beta ones
[05:09] <pitti> heno: that hasn't been very consistent in the past, bugs were just dragged from tribe to tribe and eventually to beta
[05:09] <pitti> heno: unless you have different experiences?
[05:09] <heno> pitti: no, it's just a subset. should we instead to High priority bugs from both lists?
[05:10] <pitti> (is a verb missing here?)
[05:10] <calc> my two bugs are done :)
[05:10] <heno> ... instead look at ....
[05:10] <ogra> mathiaz, its a regression fix, no ?
[05:10] <mathiaz> ogra: yes. A regression that was introduce in edgy
[05:11] <ogra> sounds to me like it should go in
[05:11] <mathiaz> then if a core-dev could have a look at the debdiff I've attached and comment, it would be great
[05:12] <evand> my bugs are done with workarounds, prettier fixes are still being investigated
[05:12] <pitti> heno: that's why I think we should just merge them into one list and adjust priorities
[05:12] <pitti> I'm down to three restricted-manager bugs for beta, rest is done
[05:13] <mvo> the compiz/g-screensaver issue is still under investiagation
[05:15] <heno> after moving the last tribe bugs we'll have ~200 open bugs milestoned for beta. how does that compare with previous releases at this stage?
[05:15] <heno> Mithrandir: ^
[05:15] <Mithrandir> that's quite a bit more, I believe
[05:16] <Mithrandir> but then, we have a much more active server team, for instance.
[05:16] <heno> making more bugs :)
[05:16] <heno> we still need to do a critical review of that list though
[05:17] <heno> pitti: shall we do that some time next week?
[05:18] <pitti> heno: agreed; or tomorrow, fine for me
[05:18] <heno> for bug 132320 I was wondering whether we should just leave tracker indexing off by default anyway
[05:18] <ubotu> Launchpad bug 132320 in tracker "Tracker consumes more then 90% of CPU even when indexing is disabled" [Critical,Confirmed]  https://launchpad.net/bugs/132320
[05:18] <heno> pitti: ok, tomorrow is good
[05:19] <heno> and activate it the first time someone goes to search
[05:19] <asac> heno: the bug claims that it consumes cycles even if indexing is disabled? how would disabling it help?
[05:20] <heno> asac: I mean, not run the deamon at all
[05:21] <Amaranth> compiz/g-screensaver is annoying hard to figure out
[05:22] <Amaranth> heno: tracker uses that much CPU by design
[05:22] <Amaranth> heno: it uses 100% cpu but nice level 19 so as soon as something wants CPU time tracker gets pushed out
[05:23] <heno> Amaranth: which is a good argument for turning it off. I would guess only a fraction of users actually use desktop search
[05:23] <Amaranth> heno: but it's not a bug
[05:23] <Amaranth> and it's not a problem
[05:23] <calc> Amaranth: using 100% cpu for prolonged time period on laptops is an issue... right?
[05:23] <Amaranth> calc: it's going to not do anything when running on battery
[05:23] <calc> Amaranth: ah ok
[05:24] <Amaranth> well, jamie said we could expect that soon
[05:24] <heno> it's bad for the environment even on desktops :)
[05:24] <asac> Amaranth: soon enough for gutsy?
[05:24] <Amaranth> asac: yes
[05:24] <Amaranth> before beta even, i guess
[05:24] <asac> Amaranth: you know jamie?
[05:24] <heno> seriously, using that much CPU is bad form
[05:24] <calc> so why does it use 90%+ cpu when apparently not doing anything?
[05:24] <Amaranth> asac: sort of
[05:24] <asac> Amaranth: ok fine then.
[05:25] <heno> and most users don't want it (is my humble guess)
[05:25] <asac> i must admit that i was a bit annoyed by it
[05:25] <pochu> calc: When it's 90+ it's indexing
[05:25] <calc> when it is actually doing indexing it causes the system to basically grind to a halt until it is done due to disk iowait
[05:25] <asac> it indexed for two days or so when i upgraded to gutsy
[05:25] <Amaranth> well you could throttle it
[05:25] <Amaranth> then it uses less % but runs longer
[05:25] <Amaranth> so same cpu time in the end
[05:26] <heno> asac: and how often have you used desktop search since then?
[05:26] <calc> pochu: the bug report mentioned above said it was at 90%+ even with indexing disabled, whether that is actually the case I don't know
[05:26] <dholbach> also having ~1G of indexing data in .cache/tracker annoyed me a bit
[05:26] <asac> heno: actually i tried it ... e.g. to find things in mozilla source
[05:26] <Amaranth> we are not the target audience
[05:26] <asac> heno: i think i would use it if I could dump updatedb completely in turn
[05:26] <pedro_> dholbach: i seconded that.
[05:26] <pochu> calc: I think there's another bug saying it didn't stop to index when it was told to, so probably it was indexing :)
[05:26] <Amaranth> we keep track of things on our filesystem
[05:26] <asac> but afaik i cannot search for filenames
[05:26] <calc> pochu: oh ok
[05:27] <heno> the target audience use firefox, an mp3 player and skype. that's it :)
[05:27] <Amaranth> my grandfather can't remember where he puts anything
[05:27] <asac> heno: yeah ... but the target audience doesn't have a home with zillions of fileitems either ;)
[05:27] <dholbach> asac: you don't know my sister :)
[05:28] <calc> i haven't looked into this but how do you disable tracker normally?
[05:28] <asac> heno: so indexing shouldn't take so long ;)
[05:28] <heno> right they keep their pictures in their gmail acct and search that
[05:28] <calc> its depended on by ubuntu-desktop so shouldn't actually be completely removed
[05:28] <mvo> its a recommends, no?
[05:28] <calc> oh yea just recommends, recommends gets autoinstalled I forgot about that
[05:28] <asac> well i think its rare that there are picture folders with as many files as a mozilla source copy ;)
[05:28] <heno> no, it's just that the deamon should be set to not run until the user tries their first search
[05:29] <jdstrand> calc: I used Sessions
[05:29] <asac> heno: the backdraft would be that the first search wouldn't yield any results right? so people will never try again :)
[05:29] <Amaranth> heno: then their first search is worthless and they stop using it
[05:29] <asac> ack
[05:30] <bdmurray> Maybe we should ask people instead of speculating?
[05:30] <asac> bdmurray: yeah ... forum vote ;)
[05:30] <heno> or their first experience into Ubuntu is slooooow and they stop using _that_
[05:30] <pedro_> asac: it could show a message "your files are not indexed with tracker do you want to start blabla bla?" ok/cancel
[05:30] <heno> we should take it to the list
[05:30] <heno> pedro_: +1
[05:30] <jdstrand> heno: perhaps a notice telling the user that the first index isn't complete would work
[05:30] <pedro_> agreed.
[05:30] <asac> pedro_: right ... i agree that things can be improved ... but we have to chew on it i guess
[05:31] <heno> Windows help used to do this, so people are used to that
[05:32] <heno> it would make the two top tracker bugs no longer Critical
[05:32] <Amaranth> in OS X they just made it the default. new installs are no problem because there are no files to index and upgrades have maybe one day of pain then they're fine
[05:32] <heno> (though they should still be fixed)
[05:32] <Amaranth> so maybe on by default for new installs only?
[05:33] <asac> Amaranth: +1 (when combined with heno/pedro_ suggestion for existing installs)
[05:33] <heno> it still takes CPU cycles, RAM and disk space for the 90% who will never use it
[05:33] <heno> (my random guess)
[05:34] <Amaranth> it uses almost no RAM so...
[05:34] <heno> Amaranth: do you have numbers?
[05:34] <Amaranth> and people have 400GB hard drives so that's not a big deal
[05:34] <pitti> erm, laptops don't
[05:34] <pedro_> well not all the people
[05:35] <heno> some people have 30GB drives and 256MB RAM
[05:35] <dholbach> I have 40G in my laptop
[05:35] <mvo> I would not mind if it would stop indexing if the space gets tight
[05:35] <pedro_> same here
[05:35] <heno> and we want to support them as well
[05:35] <Amaranth> heno: it uses no (noticeable) CPU
[05:35] <Amaranth> heno: because it only uses idle cycles
[05:35] <jdstrand> what about default off, with a note on first login about how to enable it?
[05:36] <heno> but that still makes the machine noisy, both on laptops and desktops
[05:36] <heno> and will be seen as a regression
[05:36] <asac> jdstrand: i think these kind of popups are usually just ignored by users
[05:36] <jdstrand> asac: I ignore tracker anyway :)
[05:36] <illovae> hello o/
[05:36] <mvo> asac++
[05:36] <heno> jdstrand: if we start down that path we'll soon have 10 pop-ups at boot :)
[05:37] <sourcercito> Amaranth, sure you don't live in south america or africa
[05:37] <Amaranth> heno: so throttle it
[05:37] <Amaranth> sourcercito: you can't even _install_ with 256MB
[05:37] <sourcercito> most people here don't have hard drives that big
[05:37] <sourcercito> yes, i've a 5gb partition to ubuntu, but still
[05:37] <Amaranth> sourcercito: and the size of the index is relative to the size of the stuff on your computer
[05:37] <jdstrand> asac, heno: I see your point, but question that there is a sane default.  It is indeed useful for some of our users, but not others.
[05:38] <Amaranth> so if you have a small HD you have a small index
[05:38] <kwwii> Amaranth: not if I had lots of small files, or?
[05:38] <pitti> mvo's proposal of stopping indexing when space gets tight is good IMHO
[05:38] <jdstrand> asac, heno: could default off with an entry in Ubuntu Help Center
[05:38] <heno> jdstrand: riht, but I think the notice on first search makes more sense
[05:38] <Amaranth> kwwii: well it's not a linear thing
[05:38] <asac> don't we have other features already that are enabled/disabled based on hardware profiles?
[05:38] <pitti> asac: yes, compiz
[05:38] <BenC> laptop mode comes to mind
[05:38] <pitti> asac: and gnome-power-manager
[05:39] <jdstrand> heno: ah-- so it is default off, then when they try to use it the first time, turn it on?
[05:39] <asac> so in case lots of people complain in beta we might wanna think about extending this for tracker?
[05:39] <heno> what about making the checkbox to turn off indexing actually stop the deamon from running?
[05:39] <heno> jdstrand: right
[05:39] <Amaranth> asac: compiz is easier
[05:39] <pedro_> heno: yes please.
[05:39] <Amaranth> asac: it's just a matter of checking features, not performance
[05:39] <asac> another idea would be to show up a tray icon that shows "now indexing" .. which you could right click and say "stop this" ?
[05:40] <mvo> also checking performance before starting compiz would be useful too
[05:40] <jdstrand> heno: I think an 'are you sure' type of thing with a warning about CPU and disk space might be a good idea to think about
[05:40] <jdstrand> heno: on that first try
[05:40] <Amaranth> mvo: afaik all the hardware it actually is capable of running on is fast enough to run it somewhat decently
[05:40] <Amaranth> mvo: i used it on a Radeon 7500
[05:40] <popey> asac: +1, I'd love to be able to stop/pause trackerd when I am playing a game for example
[05:40] <mvo> Amaranth: true, I the slowest I have is a i830 and even that is okish
[05:41] <Amaranth> popey: other than the kernel bug with io scheduling you should not need to
[05:41] <heno> I don't want it to run somewhat decently, I want my desktop to *always* be super-responsive :)
[05:41] <popey> "hah"
[05:41] <Amaranth> popey: it is explicitly designed to use only what is idle
[05:41] <heno> Linux should be able to deliver that
[05:41] <popey> my core2duo 2.6GHz gets murdered by trackerd
[05:41] <Amaranth> popey: in feisty it worked fine :)
[05:41] <heno> unless we shoot ourselves in the foot
[05:41] <Amaranth> popey: like i said, it uses all available _idle_ cpu
[05:41] <Amaranth> popey: so if you play a game it scales down
[05:42] <popey> Amaranth: I understand the theory, but practically it doesn't work like that, it slows down every machine I own, all over 2GHz, most multicore
[05:42] <Amaranth> only the IO is a problem here
[05:42] <heno> a problem is a problem, no matter what the technical reason
[05:42] <Amaranth> this is apparently only a problem with upgrades
[05:42] <popey> indeed, and I'd still like to be able to pause it :)
[05:42] <mvo> and it seems to be something new that was introduced by 2.6.22
[05:43] <Amaranth> so hopefully we'll figure out why
[05:43] <heno> ok, cool. on that note, let's take it to the mailing list
[05:43] <asac> cool
[05:43] <heno> shall swe look at the other Critical beta bugs?
[05:43] <asac> can we take a look at bug 139403
[05:44] <ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/139403
[05:44] <asac> i would like to know if anyone has any hard reasons not to do that?
[05:44] <asac> pleaes read summary
[05:45] <pitti> provided that u-m removes auto/dhcp interfaces from /e/n/i on upgrades, and the installer does not write the stanzas for desktop isntallations
[05:45] <heno> that does seem to be causing a lot of bug reports
[05:45] <asac> pitti: look at bug
[05:45] <asac> pitti: the new suggestion is to make postinst do that
[05:46] <asac> (not u-m)
[05:46] <pitti> asac: urgh
[05:46] <asac> so people that now use network manager for auto dhcp will still use it
[05:46] <calc> another suggestion, have network manager not kill connections on upgrade... (not sure if that is known and/or fixed yet)
[05:46] <asac> while those that have n-m uniinstalled won't see a regression
[05:46] <pitti> asac: 3. needs to be extended to '... for desktop installations'
[05:47] <pitti> asac: since we do want it on servers, CLI, or expert installations
[05:47] <asac> pitti: 3. desktop installer should not add auto dhcp interfaces.
[05:47] <asac>       ^^^
[05:47] <asac> its already in there ... isnt it?
[05:47] <pitti> asac: right, but it should do that for above cases
[05:47] <pitti> oh, *only* ubiquity?
[05:47] <asac> pitti: ok but it shouldn't install nm for those as well
[05:47] <pitti> fine then
[05:47] <asac> pitti: no idea ... i think it should depend on whether nm is installed or not
[05:48] <pitti> right
[05:48] <pitti> then we just need to make damn sure that n-m actually works and always brings up eth0 on boot
[05:49] <asac> i have not many bugs about wired
[05:49] <pitti> asac: what's your experience with that so far?
[05:49] <asac> usually wired works ... if wired doesn't work ifupdown mostly fails as well
[05:49] <mvo> what people with two interfaces? that is not supported by n-m, right? so this needs to be carfully checked
[05:49] <pitti> asac: when I trawled over the n-m bugs the last time, there were a lot of that kind, but I guess this was often due to the 'tears down ifaces on startup' but
[05:49] <pitti> s/t$/g/
[05:49] <asac> pitti: right
[05:50] <pitti> mvo: those need an e/n/i entry mostly AFAICS
[05:50] <asac> what we see now is either "tears down" ... or now ingutsy "nm shows some random interface because we have to active, managed connections"
[05:50] <pitti> mvo: e. g. my secondary interface has static configuration
[05:50] <mvo> right, so the thing that removes stuff needs to check for this, right?
[05:50] <calc> a lot of nvidia based desktop motherboards have two nics on them, btw
[05:50] <Zic> @schedule Paris
[05:50] <ubotu> Schedule for Europe/Paris: 17 Sep 14:00: IRC Council | 18 Sep 18:00: Kernel Team | 19 Sep 14:00: Edubuntu | 19 Sep 22:00: Xubuntu Developers | 20 Sep 14:00: Desktop Team Development | 21 Sep 14:00: MOTU Team
[05:50] <asac> pitti: and if people don't have a network they most likely go to network-admin ... and once they configured the interface there it will be just ifupdown
[05:51] <asac> which doesn't work atm because if you configure just dhcp there, network manager will still manage it
[05:51] <pitti> good point
[05:51] <pitti> asac: but with that, you'll lose the possibility to switch to a wifi, don't you?
[05:51] <asac> no
[05:51] <asac> thats the good thing
[05:52] <asac> you go to network-admin .. configure eth as dhcp ... then you still can use nm for wireless
[05:52] <pitti> asac: but I don't see how "don't touch ifupdown connections" and "use wifi although there is an eth configured" mix?
[05:52] <asac> unless you configure wirelss as "not-roaming" there as well
[05:52] <asac> pitti: please rephrase :) ?
[05:52] <pitti> ok, I plug my laptop into my ethernet and have auto eth0/dhcp
[05:53] <pitti> (in /e/n/i)
[05:53] <asac> yeah
[05:53] <pitti> then I unplug it, and want to use my wifi
[05:53] <pitti> but since n-m doesn't manage eth0 any more, the default route won't be torn down for eth
[05:53] <pitti> (and neither the dhclient)
[05:53] <pitti> i. e. everyone who every uses network-admin will be stuck there
[05:54] <pitti> oh, you can switch it back to 'roaming'
[05:54] <asac> what happens if you have two default routes?
[05:54] <asac> for me it worked
[05:54] <pitti> asac: you lose
[05:54] <pitti> asac: it's a race condition, from my experience
[05:54] <pitti> sometimes it works, sometimes you lose all packets
[05:55] <pitti> it's bit of a corner case, yes, but so far these cases were handled pretty well because n-m actually understood /e/n/i
[05:55] <pitti> I know, choosing between two evils :/
[05:55] <asac> pitti: understood is a bit exaggerated
[05:55] <asac> it broke ifupdown :)
[05:56] <pitti> IOW, once someone configures "dhcp" in network-admin for eth0, n-m will just go to 'static configuration' and not do anything any more
[05:56] <pitti> might be a bit confusing
[05:56] <asac> he?
[05:56] <ogra> who?
[05:56] <asac> it will not go to static ... it will just stop to manage it
[05:57] <pitti> asac: right, but it won't switch interfaces either because you have a manual configuration
[05:57] <asac> can't dhclient listen to hal events?
[05:57] <pitti> unless, of course, n-m continues to actually parse and interpret /e/n/i, but I thought you wanted to get rid of that
[05:57] <pitti> asac: in what way?
[05:58] <asac> remove/add route?
[05:58] <pitti> after all, dhclient *is* the bit that actually configures routes...
[05:58] <asac> i don't mean dhclient .. i mean ifupdown mechanism
[05:58] <ogra> asac, you could use route directly :)
[05:59] <pitti> asac: there's no ifupdownd or something that could do that; what should it do?
[05:59] <ogra> pitti, he wants to remove the defaultroute for that interface if i understood right
[05:59] <ogra> but keep the interface as is
[05:59] <pitti> asac: if we want n-m to override ifupdown routes, then we could make ifupdown use defualtroutes with metric 1
[06:00] <asac> pitti: how would that look like?
[06:00] <pitti> and keep n-m use metric 0 routes
[06:00] <pitti> so that n-m's routes win
[06:00] <asac> yes that sounds reasonable then
[06:00] <pitti> asac: just "metric 1" option
[06:01] <pitti> asac: just think about it as 'priority'
[06:01] <asac> yeah ... were would such a feature be added?
[06:01] <pitti> the lower one wins
[06:01] <heno> We've been going for an hour; let's declare the meeting done and continue this wherever
[06:01] <heno> Thanks everyone
[06:01] <asac> pitti: ok i will add that to the bug and subscribe you
[06:02] <mvo> thanks
[06:02] <pitti> thanks everyone
[06:02] <mathiaz> thanks
[06:02] <dholbach> thanks - see you tomorrow
[06:03] <kwwii> bye