[00:01] <alex-weej> wow, the new update-manager behaviour is fucking annoying
[00:01] <alex-weej> i close it every 20 minutes it seems
[00:01] <alex-weej> i can't update because the mirrors are hosed
[00:01] <alex-weej> and they're not even critical updates
[00:07] <Ampelbein> alex-weej: update-manager just closes here for no reason after i click start upgrade, but only after downloading the required packages, as a quick test with aptitude shows...
[00:09] <Ampelbein> and i ddos'd my server by not specifying an uploade-rate limit in rtorrent. ;-)
[01:00] <alex-weej> oops
[02:54] <tofu_logic> congratulations ubuntu desktop team
[02:54] <tofu_logic> jaunty jackelope is pretty dope
[02:54] <tofu_logic> (lol)
[03:46] <costamatrix> hi everyone
[03:46] <costamatrix> anyone here can help me with a problem on ubuntu 9.04?
[03:47] <costamatrix> my control key does not work...to use with control+c control+v...etc.... but it works on compiz cube to swich workspace....
[07:06] <pitti> Good morning
[08:47] <huats> morning everyone
[08:48] <mvo> good morning huats
[08:49] <seb128> hey huats mvo
[08:49] <huats> morning seb128 and mvo
[08:51] <mvo> hey seb128
[08:52] <seb128> mvo: how are things looking on the upgrade bug reports front today?
[08:53] <mvo> seb128: medium, ~10 new or so
[08:54] <mvo> need to check how bad they are though
[09:51] <seb128> lool: where should unr bugs be assigned?
[09:59] <lool> seb128: Depends; we have various packages: netbook-launcher, maximus...
[09:59] <lool> seb128: bug #?
[10:00] <seb128> lool: bug #365795 for example
[10:00] <lool> seb128: (BTW StevenK wants to handle UNR these days)
[10:00] <lool> seb128: That's probably an ubuntu-cdimage bug, looking
[10:00] <seb128> lool: I'm just looking to the recent bugs list and reassigning things where I can
[10:00] <lool> seb128: Yup, thanks for that; I'm trying to give you the best contact for the future
[10:01] <seb128> thanks
[10:01] <seb128> bug #365846 too
[10:01] <seb128> that one is not really useful, would require debugging from somebody working on UNR
[10:01] <seb128> what is the best way to bring attention of the UNR team on a bug?
[10:02] <seb128> or let the team know "that's on UNR you should have a look"
[10:02] <lool> seb128: That's a good question
[10:02] <seb128> you don't have a component which can be used as triaging point for those?
[10:02] <lool> seb128: In theory, we set the ubuntu-unr tag on these bugs
[10:02] <lool> when reported with apport
[10:02] <seb128> or a team to subscribe
[10:03] <seb128> and you go through tagged bugs?
[10:03] <lool> Many people will also report bug against the upstream project, netbook-remix, but that's incorrect most of the time
[10:03] <lool> seb128: no we don't :-(
[10:03] <lool> seb128: I think we lack a good workflow for bugs, it has been the subject of discussions between UNR upstream and mobile team people
[10:03] <seb128> is there an ubuntu-unr team we can subscribe?
[10:04] <seb128> that would email notify the team members ;-)
[10:04] <lool> There's an upstream netbook-remix team
[10:04] <seb128> ok, seems there is no easy way to notify concerned people there
[10:05] <lool> seb128: I'm trying to think of a comparable project; in practice we differ only by a small number of packages
[10:05] <seb128> I will let the bug where they are for now and assume that people interested in UNR will go through recent bugs having UNR in the title at some point then
[10:05] <lool> seb128: I think the team idea is the best one so far
[10:06] <lool> StevenK: http://irclogs.ubuntu.com/2009/04/24/%23ubuntu-desktop.txt
[10:06] <seb128> hey StevenK
[10:06] <lool> StevenK: Some minutes are still missing there; basically seb128 has a pile of UNR bugs and he's looking for a consistent way to bring our attention to them
[10:06] <seb128> lool: using the netbook-remix upstream one?
[10:06] <lool> StevenK: One suggestion seb128 made was to use an ubuntu-unr team which he would subscribe
[10:07] <lool> seb128: I think a new one makes more sense
[10:07] <seb128> you could have a launchpad mailinglist for the team which would receive the bug emails
[10:07] <seb128> should be easy enough to subscribe or look to the list for people triaging then
[10:07] <StevenK> Mmmm
[10:07] <lool> StevenK: What do you think?  I think a new Ubuntu team makes sense; some bugs are related to cdimage stuff, others to the launcher, others to usability issues...
[10:08] <lool> We could also have an Ubuntu Netbook Remix *in Ubuntu* project
[10:08] <StevenK> Sounds great to me
[10:08] <lool> I personally think a team is a good first step; but I don't mind a project
[10:08] <lool> We also have the ubuntu-unr tag
[10:09] <seb128> ubuntu-unr doesn't email notify you though
[10:09] <lool> The problem I have with a project is that it's not clear when you close the bug, or it's going to be manual
[10:09] <seb128> you have to go pool on the list
[10:09] <lool> seb128: Ack
[10:09] <lool> I think team + tag are good
[10:09] <seb128> the project issue is that the ubuntu task still stay unassigned
[10:09] <lool> new project > sounds like bad workflow, and extra work
[10:09] <seb128> me too
[10:09] <lool> StevenK: Could you set that up?
[10:10] <seb128> yeah, just create an ubuntu-unr launchpad team with a list to get bug emails
[10:13] <StevenK> lool, seb128: Done, and requested mailing list
[10:13] <StevenK> seb128: Do you want to be a member too, or do you get enough bug mail? :-)
[10:14] <seb128> StevenK: I've enough emails thanks ;-)
[10:14] <seb128> StevenK: if you set a mailinglist for the team members will not get emails though
[10:14] <seb128> StevenK: but I don't work on UNR, I just triage recent ubuntu bugs right now so I've no reason to join the team there
[10:14] <StevenK> seb128: Indeed
[10:15] <lool> StevenK: Do we want a ML or just use membership as a mean to get emails?
[10:15] <StevenK> lool: I've requested a mailing list
[10:16] <lool> StevenK: is there a benefit to a ML?
[10:16] <lool> (just curious)
[10:16] <StevenK> lool: Then we can have people in the team who don't get bugmail
[10:16] <lool> StevenK: Just sub-ed the team to its first bug  ;)
[10:17]  * StevenK has cancelled the mailing list request
[10:17] <lool> I was fine either way really
[10:18] <StevenK> Well, the description says the team should get bug mail, so ...
[10:54] <lool> asac: 190227
[10:54] <lool> Weird, I thought ia32-libs had been updated
[11:15] <andreasn> mpt, just discovered a nice thing with the clickthrough on osd, I was in the middle of closing a dialog when thomas wood came online
[11:17] <andreasn> but in contrast to the previous popups, this didn't get in the way of my flow
[11:25] <asac> lool: its fixed. what is left never worked
[11:25] <asac> Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: verkeerde ELF-klasse: ELFCLASS64
[11:25] <asac> lool: needs a gtk fix. they dont look in the abi dir for "normal" directories
[11:26] <asac> so those never worked ... afaik
[11:26] <asac> s/"normal" directories/"normal" modules/
[11:27] <lool> Ok
[11:27] <asac> lool: problem is:
[11:27] <asac> ls /usr/lib/gtk-2.0/2.10.0/
[11:27] <asac> engines  immodule-files.d  immodules  loader-files.d  loaders  printbackends
[11:28] <asac> BUT
[11:28] <asac> ls /usr/lib/gtk-2.0/modules/
[11:28] <asac> libcanberra-gtk-module.so  libdwellmouselistener.so  libferret.so  libgail-gnome.so  libgail.so  libgnomebreakpad.so  libkeymouselistener.so
[11:29] <asac> and only the ones in 2.10.0/ dir is properly done on amd64
[11:29] <lool> Ok; I remember reading these bits in gtk a while ago, and they were completely inconsistent, depending even on the module type
[11:30] <asac> yep
[11:30] <mpt> andreasn, glad you like it
[11:30] <asac> actually i promissed fta to fix that for his chromium ia32 builds
[12:04] <lool> asac: In the mean time you can strip GTK_MODULES from the env if you have a place to do that
[12:11] <asac> lool: hmm. good idea. i will check that
[13:04] <Ampelbein> asac: hi. is there any regression known about network-manager not being able to detect usb-mobile-modems? bug 346835 should be fixed but i get those symptoms here with huawei modem, 0x12d1:0x1003
[13:24] <mnemo> mvo: update-manager is crashing on me with this error --> http://pastebin.com/m2309ad3b   and this is happening on a machine which was re-installed cleanly using the RC and now I'm trying to upgrade to the final...
[13:25] <james_w> mnemo: the "S"s are part of the error message?
[13:25] <mnemo> yes
[13:26] <mnemo> update-manager starts up fine and I get to press the "start upgrade" button
[13:28] <mnemo> strange, now I get another error from update-manager by just re-running it with exact same params
[13:28] <mnemo> http://pastebin.com/m517a3a35
[13:30]  * mvo looks
[13:31] <mvo> mnemo: could you please check "via dpkg -l or synpatic" what version of u-m you have installed ? and what version of update-manager-core ?
[13:31] <mnemo> sure
[13:32] <mnemo> 1:0.111.7
[13:32] <mnemo> i created an LP bug with this info as well --> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/366048
[13:33] <mnemo> (same for u-m-c)
[13:34] <james_w> /usr/share/pyshared/DistUpgrade/DistUpgradeApport.py:        from apport.python_hook import apport_excepthook
[13:34] <james_w> is it not apport_python_hook ?
[13:35] <mvo> mnemo: thanks, I confirmed
[13:35] <mvo> james_w: checking
[13:36] <james_w> the other appears to be
[13:36] <james_w> /usr/share/pyshared/DistUpgrade/DistUpgradeQuirks.py:        self.plugin_manager = PluginManager(self.controller, ["./plugins"])
[13:38] <asac> Ampelbein: sorry. so what do you get when running /lib/udev/nm-modem-probe --export --verbose /dev/ttyUSBX
[13:38] <asac> (X == 0,1, ...)
[13:39] <mvo> james_w: thanks
[13:39] <james_w> yay for dpkg -L | xargs grep :-)
[13:40] <mnemo> :)
[13:41] <Ampelbein> asac: http://paste.ubuntu.com/157185 -> ttyUSB0 http://paste.ubuntu.com/157186 -> ttyUSB1, ttyUSB2+3 time out.
[13:42] <Ampelbein> asac: see also bug 366051, I just opened it a minute prior to your question ;-)
[13:42] <asac> Ampelbein: can you replug your device in between please?
[13:43] <asac> Ampelbein: did it work in intrepid?
[13:43] <mnemo> mvo: let me know if you want me to make some modification and re-run to test something
[13:43] <mvo> mnemo: it should be fixed now in bzr, I prepare a update, thanks again
[13:44] <mnemo> np
[13:44] <Ampelbein> asac: don't know, just got the stick yesterday. what do you mean by replug in between? between what?
[13:44] <asac> nevermind ... let me check something
[13:45] <Ampelbein> asac: network-manager is the current jaunty version, 0.7.1~rc4.1.cf199a964-0ubuntu2
[13:46] <mnemo> james_w, mvo: its probably pretty easy to write a static analysis tool that finds all bugs in all packages of this type?
[13:46] <james_w> mnemo: there are several python static analysers
[13:46] <asac> Ampelbein: please tail syslog and replug your device and post what you get there in a few seconds
[13:46] <james_w> They should be able to catch the first, not really the second
[13:47] <mnemo> right
[13:47] <mvo> the second is more tricky indeed, I will refactor the code there to make it more robust
[13:49] <Ampelbein> asac: http://paste.ubuntu.com/157192/
[14:11] <asac> Ampelbein: udevadm info --query=all --path=/sys/class/tty/ttyUSB1 --attribute-walk
[14:13] <Ampelbein> asac: http://paste.ubuntu.com/157211/
[14:16] <seb128> pitti: should intrepid be changed to jaunty in https://wiki.ubuntu.com/Testing/EnableProposed?
[14:17] <pitti> should be more general, I'll edit it; thanks
[14:19] <seb128> pitti: thank you, can you also specify that uploads might take some hours to be available?
[14:19] <seb128> I've noticed it's a frequent user comment
[14:19] <seb128> there or in your stock reply
[14:20] <pitti> better in the stock reply, I think
[14:24] <seb128> pitti: right
[14:24] <seb128> pitti: btw did you code review the libgweather change?
[14:25] <seb128> pitti: the change is not an upstream backport but a local one so a second look is always welcome ;-)
[14:25] <pitti> I had a quick look only (too many SRUs)
[14:25] <pitti> seb128: I'll remember to give/require more intense testing
[14:26] <seb128> well, it's not especially complicated so it should be fine, let's wait for user testing
[14:26] <seb128> it works here at least
[14:26] <pitti> seb128: sru-accept.py changed accordingly
[14:26] <seb128> danke
[14:26]  * seb128 hugs pitti
[14:27]  * pitti hugs back seb128, thanks for the suggestions
[14:44] <asac> Amaranth: can you unplug; then set udev to debug and past what you get in syslog when pluggin it in?
[14:44] <asac> oops
[14:44] <asac> Ampelbein: ^^
[14:45] <asac> udevadm control --log-priority=debug
[14:52] <Ampelbein> asac: http://paste.ubuntu.com/157233/
[14:54] <asac> Ampelbein: something makes the 77-nm-modem*rules in /lib/udev/rules.d not match your device
[14:54] <asac> i have to compare to what i see i guess
[14:56] <Ampelbein> asac: how can i help you with that?
[14:57] <asac> Ampelbein: http://pastebin.com/f6631b5e6
[14:57] <asac> Ampelbein: replace /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules with that
[14:58] <asac> Ampelbein: and replug
[14:58] <mvo> seb128: does it make sense to get rid of scrollkeeper? it seems we still get segfaults from it (#365606)
[14:59] <mvo> seb128: or at least I suspect it :)
[15:00] <Ampelbein> asac: awesome. that works!
[15:01] <Ampelbein> asac: at least nm now identifies it as a modem, will connect now.
[15:01] <Ampelbein> asac: success! connection works, too.
[15:02] <asac> Ampelbein: great. so you see just one entry in applet and that works?
[15:02] <asac> can you try to replug multiple times and see if that causees issues?
[15:02] <Ampelbein> asac: yeah, only one entry in the applet.
[15:02] <asac> neat
[15:03] <asac> so we just found a previously unknown driver ;) ... that just works with a huawei modem ;)
[15:04] <Ampelbein> asac: tried replugging 3 times now, works like a charm. will reboot to see if it continues to work.
[15:04] <Ampelbein> asac: many many thanks!
[15:05] <asac> Ampelbein: can you file a bug please so i can target that for inclusion in the first SRU?
[15:06] <Ampelbein> asac: bug 366051
[15:06] <Ampelbein> asac: what information should i add to the report? the updated 77-nm-...?
[15:06] <Ampelbein> asac: or do you take care of that?
[15:07] <asac> Ampelbein: just attach the --attribute-walk for ttyUSB0 and state that modem XYZ isnt detected  in bug title
[15:07] <asac> Ampelbein: dont need to attach the 77-
[15:07] <Ampelbein> asac: ok, will do. rebooted and it still works. thanks again.
[15:07] <asac> i will push the change upstream today i guess
[15:12] <mvo> seb128: could you please reject my update-manager upload? I want to include another change as well
[15:27] <pitti> mvo: rejected
[15:27] <pitti> mvo: I won't accept it anyway, since the previous one needs to get verified and to -updates first
[15:28] <pitti> mvo: I'm fine with not waiting for 7 days, as long as the current SRU gets a good testing beating
[15:28] <mvo> pitti: ok
[15:33] <pitti> ArneGoetje: is it still planned to have a GUI to select LC_MESSAGES vs. LC_TIME, etc?
[15:34] <mvo> pitti: I asked on ubuntu-testing if they can do the verification for it, would be nice to get it in early
[15:39] <ArneGoetje> pitti: I think it would make sense, how about you?
[15:40] <pitti> ArneGoetje: I agree; I got reminded by bug 208548
[15:41] <ArneGoetje> pitti: so, I make a GUI for language-selector?
[15:41] <pitti> it's more like a "locale-selector", but it makes sense there, yes
[15:42] <ArneGoetje> pitti: should we discuss the details at UDS?
[15:43] <pitti> ArneGoetje: I thought it was already spec'ed out
[15:43] <ArneGoetje> pitti: not really
[15:44] <ArneGoetje> pitti: the details how it should work with the current locale setting mechanism needs to be fleshed out
[15:44] <pitti> ah, I see
[15:45] <pitti> ArneGoetje: if that's a project that interests you, would you please create a blueprint stub for it (or propose the existing one for karmic uds)?
[15:45] <ArneGoetje> pitti: ok
[16:27] <seb128> re
[16:27] <seb128> mvo: scrollkeeper? are we sure that's the scrollkeeper-update there crashing?
[16:27] <seb128> mvo: rarian-compat also has a scrollkeeper-update command
[16:29] <seb128> mvo: otherwise dropping scrollkeeper in karmic seems ok
[16:29] <mvo> seb128: not sure, unfortuantely it does not show what segfaulted
[16:29] <seb128> that's something we need to fix next cycle
[16:30] <seb128> quite some of those upgrade bugs are random crash without details
[17:05] <josephpiche> hi. i was wondering if someone could point me in the right direction for getting the source for the "Services" control panel--I'm looking to develop a simple UFW control panel
[17:18] <cj> in case you read the backlog, apt-get source gnome-system-tools
[17:23] <pitti> ^ which is unmaintained and pretty out of date, and thus not a good example...
[18:13] <seb128> mpt: I don't understand bug #366194
[18:13] <mpt> seb128, where do you get stuck in the steps?
[18:13] <seb128> you seem to mix gtk fileselector and nautilus
[18:13] <seb128> ie describe 2 bugs
[18:14] <seb128> is your bug "files added to the places list display errors when selected"?
[18:14] <mpt> yes
[18:14] <seb128> that being the case in gtk and nautilus?
[18:14] <mpt> No, only Nautilus
[18:14] <mpt> The filepicker is in the steps to reproduce for two reasons
[18:15] <mpt> 1. because Nautilus doesn't let you add a file to the Places pane, only the filepicker does
[18:15] <seb128> mpt: ok, please try to have clear steps and 1 bug by ticket please
[18:15] <seb128> ie we are not interested by a complex way to get the issue but the easier way you can get
[18:15] <mpt> 2. to show that it's possible for Nautilus to handle the file being there, because the filepicker handles it.
[18:16] <mpt> seb128, it is only one bug.
[18:16] <seb128> hum, no?
[18:16] <seb128> you have 5. and 6. listing issues
[18:16] <seb128> which seem different ones
[18:16] <seb128> oh
[18:16] <seb128> I understand the bug now
[18:17] <seb128> it's "nautlus should act as the fileselector does"
[18:17]  * seb128 tries
[18:17] <seb128> ok
[18:17] <seb128> so steps are
[18:17] <seb128> - add a bookmark to a file
[18:17] <mpt> seb128, I try to avoid making bug summaries assume the solution, I leave the suggested solution to the end of the report
[18:17] <seb128> - try to open this bookmark in nautilus
[18:18] <seb128> well those don't assume the solution
[18:18] <mpt> seb128, I don't see how you can add a bookmark to a file from within Nautilus
[18:18] <mpt> selecting a file and choosing "Add Bookmark" adds the enclosing folder instead!
[18:19] <seb128> right
[18:19] <seb128> so the steps are
[18:19] <seb128> - use a gtkfileselect to add a bookmark to a file
[18:19] <seb128> - try opening it in nautilus place pane
[18:19] <mpt> yep
[18:20] <seb128> gnome bug #561221
[18:20] <seb128> mpt: ^ dup from that
[18:20] <seb128> bug #298425 in launcupad
[18:20] <seb128> launchpad
[18:21] <mpt> Ah, I searched Bugzilla but didn't think to look in something called "Bookmarks"
[18:21] <mpt> Since it's called "Places" in both the filepicker and in Nautilus
[18:22] <mpt> thanks seb128
[18:22] <seb128> you're welcome
[18:22] <seb128> mpt: thanks for the user testing, some suggestion though
[18:22] <seb128> - the shorter the bug description is the better
[18:22] <seb128> we read log of bugs and we want to know what is the issue
[18:23] <seb128> the user story leading to it is not really interesting
[18:23] <seb128> - you can open upstream bugs only upstream ;-) but I guess you want to track those in launchpad too for those user testing?
[18:24] <mvo> pitti: is there a way to make the kernel output the name of the segfaulted app when it prints the "Segmentation fault" message? I want to include that in the apt terminal.log if possible
[18:24] <mpt> seb128, bah, that's like 4 lines out of 20
[18:24] <mpt> :-P
[18:24] <mvo> pitti: alternatively I'm thinking about just adding the dmesg output to a apt failure log if a exit status is 139
[18:25] <pitti> mvo: doesn't it already?
[18:25] <pitti> pr 22 10:52:23 tick kernel: [13255.188232] ekiga[16208]: segfault at 10 ip 00007f95142c79dc sp 00007f9506d4bd00 error 6 in libc-2.9.so[7f951424d000+168000]
[18:25] <mvo> pitti: right, in dmesg
[18:25] <mpt> seb128, yes, I plan to tag them all the same way :-)
[18:25] <mvo> pitti: I would like to have it in the terminal window too :)
[18:25] <seb128> mpt: it took me 2 goods minutes to understand your bug, I first trying to figure why it was about places and started by background and pattern dialog use
[18:26] <seb128> trying -> tried
[18:26] <pitti> mvo: oh, *that* message
[18:26] <mpt> ok
[18:26] <mvo> pitti: including the dmesg output is my fallback plan
[18:26] <pitti> mvo: hm, any chance you could get it from /var/log/apport.log?
[18:26] <mvo> pitti: that would mean to start apport, right?
[18:26] <pitti> (I thought you did that anyway)
[18:26] <mvo> pitti: currently for stable->stable upgrades its not running
[18:26] <pitti> mvo: however, that's only reliable if you parse every line, I gues
[18:26] <seb128> mpt: bug #298425 has a description which seems clearer to me for example
[18:26] <pitti> s
[18:26] <pitti> mvo: OIC
[18:27] <seb128> mpt: but maybe that's only me, or an user view against a bug triager one
[18:27] <pitti> mvo: I don't currently know a way to do that, I'm afraid
[18:27] <mpt> That one doesn't even use complete sentences
[18:27] <pitti> mvo: well, we could always change glibc to do that, of course :)
[18:27] <pitti> but not without such a change
[18:27]  * mpt is just whining now, ignore me
[18:27] <mvo> pitti: no problem, then I just use the dmesg idea then
[18:29] <seb128> mpt: right, I might be complaining a bit, just try to not be too specific if you can, ie if any fileselector do write that rather than describing a specific way to open one in nautilus ;-)
[18:29] <mpt> ok
[18:29] <seb128> thanks
[18:29] <seb128> otherwise thanks for the user testing and the detailed descriptions you do in bugs
[18:29] <seb128> and thanks for opening those upstream too ;-)
[18:51] <alex-weej> can we go back to the normal way of resizing windows in compiz now that it's not as slow as it used to be?
[18:51] <alex-weej> that blue outline isn't even in any theme
[18:52] <mvo> seb128: I added dmesg output to apport package logs now, that should make it possible to see what segfaulted in maintainer scripts
[18:54] <seb128> mvo: excellent
[18:54] <alex-weej> i've changed the patch in the bzr package for compiz
[18:55] <alex-weej> how do i properly get this change sponsored etc.?
[18:55] <alex-weej> do i push the branch to lp myself?
[18:56] <seb128> alex-weej: if there is a bug subscribe ubuntu-main-sponsors
[18:56] <seb128> alex-weej: having either a debdiff on the bug or your bzr with the change
[18:56] <seb128> there is a lp feature to match a bug and a bzr
[18:57] <seb128> alex-weej: are you sure that the changes are faster now? or do you just assume that because it's fast on your box?
[18:58] <alex-weej> i've not seen a recent machine where it's been slow enough to warrant going back to Windows 95 resizing
[18:58] <alex-weej> but i've not conducted a thorough test
[18:59] <alex-weej> i'll put the patch on and it can be closed "when it's ready" if people think not now
[19:01] <seb128> we tried before hardy ie one year ago
[19:02] <seb128> and on some box you could see it jumping when moving the cursor
[19:02] <seb128> I doubt that has changed, the issue is just slow video cards
[19:02] <alex-weej> seb128: jumping?
[19:03] <pitti> good night everyone
[19:03] <seb128> not being smooth
[19:03] <seb128> pitti: 'night
[19:03] <seb128> alex-weej: ie the graphic changes don't follow the mouse and catch up by jumping when they can
[19:03] <alex-weej> it's certainly not "smooth" now
[19:03] <alex-weej> but... a giant blue rectangle?
[19:03] <seb128> the blue rectangle is not smooth for you?!
[19:04] <seb128> well, it gives an indicate of the change
[19:04] <alex-weej> no it is, i just don't see the point of it. if i'm resizing a window to make e.g. a web page FIT, i have no idea when i can stop making it wider if i see a blue rectangle
[19:04] <seb128> nobody complained about that until now
[19:04] <alex-weej> if it's actually resizing live, i can see when to stop
[19:04] <seb128> "live" is the issue
[19:04] <alex-weej> it's not an issue. it's slow, but it's a hell of a lot more usable and less ugly than a blue rectangle
[19:04] <seb128> if you get the view refreshing every second it's highly annoying
[19:05] <alex-weej> it's not that slow
[19:05] <seb128> depends of the video card as said
[19:05] <seb128> on my 5 years old laptop it is
[19:05] <alex-weej> if your graphics hardware is that slow at 2D yet still good enough to run compiz
[19:05] <alex-weej> you got problems
[19:05] <seb128> it runs compiz just fine
[19:05] <alex-weej> every /second/?
[19:05] <alex-weej> are you exaggerating?
[19:06] <seb128> enough to give a jumping effect
[19:06] <seb128> I don't think the eyes are good at make the difference between 600ms and 800ms
[19:06] <seb128> it's just slow enough to not be usable
[19:06] <alex-weej> seb128: 5 years old is out of the scope of ubuntu right?
[19:06] <seb128> no
[19:07] <seb128> ubuntu is working just fine on this box
[19:07] <seb128> it's a 1.5GHz box
[19:07] <alex-weej> why must you penalise people with newer machines with worse usability?
[19:07] <seb128> ubuntu runs on a 500mhz with 512 meg of rams
[19:07] <seb128> because we have no good way to make speed estimation?
[19:07] <seb128> it's not only old machine
[19:08] <seb128> lot of people are describing intel 2.6 drivers being too slow to be used with compiz in jaunty
[19:08] <seb128> on recent hardware
[19:08] <seb128> ie alt-tab and desktop switching are fine
[19:08] <seb128> but extra effects are slooooow
[19:09] <alex-weej> the resizing issue is solely to do with 2D performance
[19:09] <seb128> we can try changing the setting value in karmic and see who complains
[19:09] <alex-weej> and CPU i guess (layout etc.)
[19:09] <seb128> expose too
[19:09] <seb128> and things people describe as slow in jaunty on intel
[19:10] <seb128> ideally we would have a video speed estimation by some way
[19:10] <seb128> and use that to know what to enable
[19:10] <alex-weej> i noticed expose was quite sluggish like 10fps on a fairly recent (~2 years) intel gma
[19:10] <seb128> as said we can try enabling the dynamic content refresh again in karmic
[19:11] <seb128> and see how it goes
[19:11] <seb128> anyway I've to run for now, diner time, bbl
[19:11] <alex-weej> cya
[19:11] <pedro_> is anybody aware of bug 361560 ? seems it's affecting a good quantity of users
[19:12] <james_w> pedro_: chriscoulson was looking at it the other day
[19:13] <pedro_> james_w: ah good to know i was about to ask him or to didrocks since they're touching the package now
[19:14] <james_w> pedro_: yeah, not sure where he got to, but he had a theory of the cause, and is in communication with upstream
[19:15] <pedro_> james_w: awesome, looks worth it for an SRU, let's approve the nomination on the meantime, that's james_w
[19:19] <pedro_> s/that's/thanks ;-)
[19:19] <pedro_> dammit keyboard
[19:37] <pmatulis> how does one report a boot degradation after upgrading to jaunty?  apply toward what package in Launchpad?
[19:59] <james_w> pmatulis: you mean a boot speed degradation?
[20:00] <pmatulis> james_w: yeah, btw, i believe i just apply it towards 'ubuntu' and add a tag somewhere called 'boot-performance'
[20:00] <james_w> that could work
[20:00] <james_w> have you generated a bootchart?
[20:01] <pmatulis> no, but the delay is right after grub: "boot from hd(0,0) .. UUID"
[20:01] <pmatulis> it sits there for about 12 seconds
[20:03] <james_w> ah
[20:03] <james_w> that's more specific
[20:04] <james_w> I'm not sure what component it would be there, but it's probably while searching for the root filesystem
[20:05] <james_w> pmatulis: you don't happen to have a Intel D945 motherboard do you?
[20:06] <james_w> also, a dmesg from the booted system would be good to attach
[20:11] <pmatulis> james_w: it has the intel GM965 chipset, yes, of course dmesg
[20:11] <james_w> I ask because of bug 290153 from the release notes
[21:38] <vix> is it true that every /boot partition must reside on a primary partition?
[21:41] <vix> ?
[23:17] <chrisccoulson> hey didrocks
[23:19] <chrisccoulson> i notice you worked on the gnome-session update (2.26.1). that version actually closes a few bugs on LP
[23:19] <chrisccoulson> gnome-session -> gnome-terminal