[02:44] <rickspencer3> why does two weeks of writers block melt away right when I have to take care of my kids
[02:44] <rickspencer3> curse you muse!
[04:36] <Mayuresh> Good day fellas....
[04:36] <Mayuresh> I need help with connecting my 1 TB hdd with my laptop using ubuntu.
[04:37] <Mayuresh> Its failing after sometime, after writing around 58 M
[04:37] <Mayuresh> I have the dmesg output with me and have already searched the net for any useful information, but didn't get any.
[04:37] <Mayuresh> any help is much appreciated.
[04:41] <mpontillo> Mayuresh: you might have better luck in #ubuntu; this channel is a much more limited audience. I would suggest that you pastebin any relevant dmesg output first. see http://paste.ubuntu.com
[04:44] <Seven-7> Arrrrgh. Does anyone know how to get help support for Evolution?
[04:44] <Seven-7> It's freezing on opening.
[04:48] <Mayuresh> mpontillo: Thanks. I'll also place this question at #ubuntu. In the mean time, I have pasted the output: http://paste.ubuntu.com/164643/
[07:33] <pitti> Good morning
[07:34] <pitti> calc: pong
[07:34] <pitti> bryce: thanks, I processed it last night
[07:38] <robert_ancell> pitti: hello
[07:48] <pitti> robert_ancell: good morning, how are you?
[07:49] <robert_ancell> pitti: good, trying to get the hang of karmic packaging.  Is there anything different to do than a normal package update?
[07:54] <pitti> robert_ancell: not really, in what way?
[07:54] <pitti> karmic right now is in the "anything goes, break it" stage
[07:55] <robert_ancell> pitti: In that I open a bug with the debdiff and subscribe the main sponsors?
[07:58] <pitti> robert_ancell: for a new upstream version it's better to attach the source package's diff.gz
[07:58] <pitti> robert_ancell: so that we don't have to wade through the upstream diff
[07:58] <robert_ancell> pitti: do you need the orig.gz then?
[07:59] <pitti> robert_ancell: if a package is in bzr, just commit to the branch and ask us to upload it
[07:59] <pitti> robert_ancell: for GNOME packages we know where to get them from; for other packages, an URL to the orig.tar.gz is fine
[07:59] <robert_ancell> pitti: and if it needed modification due to directory naming?
[08:00] <pitti> robert_ancell: a repacked orig? then please put it on your people.u.c. page or attach it
[08:06] <robert_ancell> pitti: when you merge a debian changelog with an ubuntu one do you keep all the entries?
[08:06] <pitti> robert_ancell: we usually do, although admittedly I "flush" them from time to time
[08:06] <pitti> since a merge requirement is to give a detailled list of remaining ubuntu changes
[08:07] <pitti> robert_ancell: oh, you are merging from Debian?
[08:07] <pitti> robert_ancell: wrt. orig.tar.gz, when Debian has it, we can get it from there
[08:07] <robert_ancell> yes, ok
[08:07] <robert_ancell> I'm working on avahi - I noticed you'd done that one previously
[08:08] <pitti> right
[08:08] <pitti> in my times I didn't need to repack the orig, though
[08:08] <robert_ancell> When you say remaining ubuntu changes do you mean "any change from upstream" - as you listed the patches as provided by debian
[08:08] <robert_ancell> and the patches that are obsolete - should I list them in the changelog?
[08:09] <pitti> robert_ancell: no, "ubuntu changes" are relative only to Debian for merging
[08:09] <robert_ancell> ok, easy (in this case we have none)
[08:09] <pitti> robert_ancell: the patches shoudl usually document themselves, with https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
[08:09] <pitti> robert_ancell: if we have zero changes, we can sync
[08:10] <robert_ancell> pitti: most aren't. I have been tagging mine
[08:10] <pitti> robert_ancell: if our only remaining delta is the changelog, or some obsolete cruft, we sync
[08:10] <pitti> that's in fact the ideal case
[08:10] <robert_ancell> ok, how do we trigger that then? avahi failed the automerge
[08:10] <pitti> once we have done our homework and pushed patches to upstream and packaging fixes to Debian, we are in sync and can stop maintaining a delta
[08:11] <pitti> robert_ancell: if you are sure that the remaining delta is zero, request a sync with https://wiki.ubuntu.com/SyncRequestProcess
[08:12] <pitti> in short, "requestsync avahi karmic" should do
[08:12] <robert_ancell> pitti: ok, once the sync is complete and there are other changes should I push those to Debian so we keep the sync?
[08:13] <pitti> robert_ancell: "other changes" -> "future changes"?
[08:13] <robert_ancell> yes (I don't want to sync then immediately fix a bug)
[08:13] <pitti> robert_ancell: yes, we should, if it's packaging related
[08:13] <pitti> code changes should better go into the upstream bug tracker
[08:13] <pitti> robert_ancell: well, syncing in between has the advantage to have a really clean slate again
[08:13] <robert_ancell> sure
[08:30] <robert_ancell> pitti: again, when I look at glade it appears that should by synced too - is there anything special I should be looking out for in the debian/ directory?
[08:30] <seb128> hey robert_ancell
[08:30] <seb128> robert_ancell: did you get my email?
[08:30] <robert_ancell> seb128: hey seb - you're giving me easy packages to merge again
[08:31] <seb128> is that ironic? ;-)
[08:31] <robert_ancell> yes, as far as I can see both avahi and glade can be synced with debian
[08:32] <seb128> I didn't look at the diff but basically at the list of things not merged yet and picked some of your packages there
[08:32] <seb128> oh, that would be good ;-)
[08:32] <seb128>     - debian/rules: Create an up to date PO template during build.
[08:33] <seb128>   * Python 2.6 transition (fixes FTBFS)
[08:33] <seb128> those are in debian now?
[08:33] <robert_ancell> the PO template thing is.
[08:33] <seb128> I'm a bit surprised since the po thing is specific to ubuntu for language packs and python2.6 is not used in debian yet that I know about
[08:33] <robert_ancell> ok, no then I'm confused
[08:33] <seb128> ah good, somebody must have sent the change to lower the delta and they took it
[08:35] <seb128> robert_ancell: ok, you are right, pitti sent them the change and they applied it
[08:35] <seb128> robert_ancell: tomorrow you can do gdm which is a non trivial one ;-)
[08:37] <robert_ancell> seb128: so what was the python 2.6 fix, I'm looking at the bug and the source but I can't see what it is.  And if we merge do we use the builds from Debian or build them locally?
[08:38] <seb128> we grab the source from debian and upload that
[08:38] <seb128> it's built on ubuntu
[08:38] <seb128> robert_ancell: https://launchpad.net/ubuntu/+source/avahi
[08:38] <seb128> robert_ancell: you have the diff for each upload there
[08:39] <seb128> the change is basically site-packages -> *-packages
[08:39] <seb128> the python directory used in 2.6 changed
[08:39] <robert_ancell> ok, I see now.  So we can't sync because we need that change
[08:40] <seb128> right
[08:40] <seb128> but you can send the patch to debian
[08:40] <seb128> there is no reason they couldn't do that, that still work for site-package and they will get 2.6 too
[08:40] <seb128> so we can sync with there next upload
[08:40] <seb128> if you didn't oversight other changes too ;-)
[08:42] <seb128> robert_ancell: they don't have Keybuk's change either
[08:43] <seb128> 0.6.23-4ubuntu3
[08:45] <seb128> robert_ancell: and they still enable ipv6 apparently that we don't
[08:46] <pitti> seb128: no, I've been sending POT creation patches to Debian for years
[08:46] <robert_ancell> POT?
[08:46] <seb128> pitti: right, but they didn't take it until recently
[08:46] <seb128> robert_ancell: intltool-update call
[08:47] <seb128> pitti: it was still listed in the summary of changes when we rebased previous on debian
[08:47] <pitti> right
[08:47] <seb128> anyway there are the 3 others changes
[08:47] <seb128> python2.6 site-packages -> *-packages
[08:47] <seb128> runlevel
[08:47] <seb128> ipv6
[08:47] <seb128> which still need to be applied
[08:48] <pitti> robert_ancell: you are looking at the current ubuntu patch that MoM creates?
[08:48] <seb128> I found those patches not practical when you have different versions
[08:48] <pitti> I love them
[08:48] <seb128> I usually diff the debian directories between current debian and ubuntu
[08:49] <pitti> I usually grab the Debian version and the current ubuntu patch, and then walk through teh Ubuntu patch and throw out the obsolete stuff
[08:49] <pitti> and then apply the rest
[08:49] <robert_ancell> I'm not sure how to use MoM
[08:49] <seb128> I will let pitti explain since I don't use it
[08:50] <pitti> robert_ancell: I almost never take the automatic merge, since it's often unclean, and it can't check which changes aren't really required any more
[08:50] <robert_ancell> pitti: where are the files that MoM generates?
[08:50] <pitti> robert_ancell: the only things I use from MoM are the current Ubuntu diff and the fact that a package needs merging (and by whom)
[08:50] <pitti> robert_ancell: https://merges.ubuntu.com/main.html -> click on package -> remove '/REPORT' from URL
[08:51] <robert_ancell> oh
[08:51] <pitti> i. e. https://merges.ubuntu.com/a/avahi/avahi_0.6.23-4ubuntu4.patch is the current Ubuntu patch
[08:52] <seb128> the package names should rather point to the directory than to REPORT
[08:52] <seb128> I find myself removing the REPORT every time and wondering why it's the default
[08:52]  * pitti too
[08:52] <seb128> you can easily click on it and back to go back to the directory
[08:53] <robert_ancell> another question: debian bumped the soname from 5 to 6 when they went from 0.6.23 to 0.6.24, any idea why?
[08:53] <pitti> ugh
[08:53] <seb128> because the library soname changed?
[08:54] <seb128> that's an upstream thing usually
[08:54] <seb128> libraries are name libname.no.SONAME
[08:54] <seb128> where SONAME is a number
[08:54] <pitti> only two packages depend on libavahi-core5, so that transition is easy
[08:54] <seb128> when they break the compatibility in the abi they bump this number
[08:54] <seb128> so that doesn't break applications using the old abi
[08:55] <seb128> and you install the new abi next to it and start rebuilding things using this one
[08:55] <seb128> the package renaming is to allow installing both versions
[08:55] <seb128> and have a smooth transition
[08:56] <mvo> I personally use grab-merge and work based on this because it often has quite good results for me (checking the debdiff afterwards carefully of course)
[08:57] <seb128> I fail to see how that's better than a diff -Nru of the debian directories usually
[08:57] <seb128> you just lot of extra noises when the versions are not the same
[08:57] <pitti> mvo: it discourages you from actually checking which of our delta can be dropped, though
[08:57] <pitti> seb128: you don't get a three-way diff that way, though
[08:58] <robert_ancell> i see.  The avahi guys aren't keen on keeping ABI within minor releases.
[08:58] <mvo> pitti: not really, the debdiff of the merge (against the debian version) needs to be checked afterwards for this as well. but I guess the workflow is pretty equivalent in the end, just approaching it from different directions
[08:58]  * robert_ancell thinks the avahi package will take some more time
[08:58] <seb128> pitti: I find that not required in most cases, especially if your changelog has an accurate summary of changes from the previous merge already
[08:59] <seb128> anyway everybody has his own workflow ;-)
[08:59] <pitti> I'm just eager to drop delta
[08:59] <pitti> sure
[08:59] <seb128> one other thing I don't bother doing that quite some people do is to copy over old ubuntu changelog entries
[09:00] <pitti> same for me
[09:00] <pitti> if we have a good merge summary, it's just redundant
[09:00] <seb128> robert_ancell: see that was good that you had an easy one to start ;-)
[09:00] <mvo> I think old changelogs are often useful (and one of the things that you get with the merge from mom)
[09:00] <seb128> mvo: I summarize all those in the current entry
[09:00] <seb128> quicker to read than trying to go over all the old uploads
[09:01] <seb128> and that wins some CD space ;-)
[09:01] <seb128> especially for GNOME where we copy the NEWS each time
[09:01] <mvo> seb128: fair enough in case of NEWS I guess
[09:01] <pitti> seb128: you should *really* use Seb Bacher to save 6 bytes for each changelog record :-P
[09:01] <mvo> haha
[09:01]  * seb128 hugs pitti
[09:02] <Nafallo> lol
[09:29] <robert_ancell> good day all!
[09:29] <robert_ancell> (that was an inverted good night)
[09:29] <pitti> robert_ancell: enjoy the evening!
[09:29] <seb128> robert_ancell: good evening!
[09:29]  * crevette shouldn't do uplaod with its long name
[09:29] <robert_ancell> :)
[09:29] <pitti> robert_ancell: or, rather: ʇɥƃıu pooƃ
[09:50] <huats> morning everyone !
[09:51] <seb128> lut huats
[09:51] <huats> hello seb128
[09:52] <seb128> huats: how are you? how is your business going?
[09:52] <huats> seb128: I am fine
[09:52] <huats> and I try to start the business
[09:52] <huats> it is not that easy but I have some possibilities :)
[09:53] <huats> I think I'll know more by the end of the month :)
[09:53] <huats> well for the moment I am mainly focussing on putting together all the pieces
[09:53] <huats> :)
[09:55] <seb128> ok, good luck
[09:55] <seb128> still as busy?
[09:55] <seb128> but still going to uds?
[09:56] <huats> still going to th uds :of course seb128
[09:56] <huats> I am still busy
[09:56] <seb128> I'm wondering since you seem to not be around a lot recently
[09:56] <seb128> so I was wondering if you would still manage to get time for uds
[09:56] <huats> In fact I am around but not chatting
[09:56] <huats> :)
[09:57] <huats> it is weird for someone as talkative than I am :)
[09:57] <seb128> lol
[09:59] <huats> Need to logout
[09:59] <pitti> seb128: your X-GIO-NoFuse=true patch in f-spot, do you know whether that's reported upstream?
[09:59]  * pitti is tagging our patches
[10:00] <pitti> bug 338466
[10:00] <seb128> pitti: I don't think I sent that upstream no because I was not sure that was the right way
[10:01] <seb128> ideally it could be using the fuse mount but for some reason that sloooow
[10:01] <pitti> probably because it generates thumbnails from the real pictures isntead of using the camera's thumbnails?
[10:01] <pitti> (that's what we had in gthumb)
[10:02] <seb128> could be
[10:03] <pitti> all our other patches are reported upstream now
[10:03] <pitti> (if only they'd apply them)
[10:11] <seb128> I hate the bugzilla.gnome.org slowness
[10:13] <pochu> the good thing is that it makes launchpad feel fast ;)
[10:14] <seb128> yeah
[10:32] <seb128> mvo: you are a vm user right? what do you recommend on jaunty to have something usable? ;-)
[10:32] <seb128> I use kvm -cdrom iso to boot live cds
[10:32] <seb128> and virt-manager for installs but virt-manager is the suck, mouse location keeps being wrong, it it doesn't go in some screen corners
[10:34] <huats> seb128: if you move the mouse quite fast you can reach that corners
[10:34] <huats> seb128: i am doing that all the time :)
[10:34] <seb128> huats: it's not fast, you need to go against the opposite border rather
[10:34] <seb128> yeah, me too, but that's annoying so I'm looking for better suggestions
[10:35] <huats> yeah opposite AND going fast to the corner you want to reach :)
[10:35] <seb128> and something I could switch full screen too would be nice
[10:35]  * pitti just uses kvm in CLI mode
[10:35] <huats> ok
[10:35] <pitti> kvm -m 512 -cdrom ubuntu.iso -hda testubuntu.img -boot d
[10:35] <seb128> pitti: is there some magic command to get an hdd in kvm so you can install something? ;-)
[10:35] <seb128> oh
[10:35] <seb128> easy enough
[10:36] <seb128> and testubuntu.img need to be created using some other tool?
[10:36] <pitti> seb128: -hda, -hdb, etc. -boot c -> boot from hd; -boot d -> boot from cdrom
[10:36] <pitti> seb128: you can use existing ones, or just dd if=/dev/zero one yourself
[10:36] <seb128> ok thanks
[10:36] <seb128> I'm pondering upgrading my laptop to karmic yet
[10:36] <pitti> I have a dd'ed 6 GB testubuntu.img which works just fine
[10:36] <seb128> or using a kvm install for now
[10:37] <seb128> I would like to get working beamer, suspend, etc for uds
[10:37] <pitti> seb128: with some tool you can even mount these images in your host system, for nice and easy file exchange
[10:39] <mvo> seb128: I just use plain kvm
[10:39] <seb128> pitti, mvo: ok thanks
[10:39] <seb128> I will use the office bandwith tomorrow to do karmic and debian unstable kvm images
[10:40] <pitti> seb128: hah, yay phat pipes
[10:40] <mvo> seb128: there is also ctrl-alt-f2 with kvm that gives you a useful console to do stuff
[10:40] <mvo> seb128: like sendkey ctrl-alt-f1
[10:40] <seb128> ok thanks
[10:40] <pitti> seb128: if all else fails, I still have a jaunty install on my USB stick which I can boot, so I'm just using karmic
[10:40] <seb128> is there a way to put kvm in full screen? ;-)
[10:40] <mvo> seb128: or inject NMI (not that fullful ;)
[10:41] <seb128> pitti: I've upgraded my desktop but I tend to be a bit conservative with my laptop until uds
[10:41] <pitti> sounds fine
[10:41] <pitti> especially if you are still working on some SRUs
[10:41] <mvo> seb128: -full-screen
[10:41] <seb128> and usually it's useful for srus too
[10:41] <seb128> right
[10:41] <seb128> though I'm mostly done with srus for jaunty I think
[10:41] <pitti> seb128: I just have one computer, so I need to get along with chroots
[10:41] <seb128> mvo: kvm for the win apparently ;-)
[10:41] <pitti> well, I have the G1 for ssh etc., but that doesn't run ubuntu yet
[10:42] <seb128> "yet" ;-)
[10:42] <pitti> there was a post on planet recently about wiping android and installing ubuntu :)
[10:42] <pitti> but how would I do phone calls then?
[10:43] <seb128> who need to do phone calls on a phone anyway
[10:43] <seb128> install ekiga and use that? ;-)
[10:43] <pitti> I'd love to, if only T-Online wouldn't block voip
[10:44] <mvo> seb128: I like it a lot
[11:13] <Ampelbein> seb128: hi. i'm currently working on the gnome-media merge/update. scrollkeeper has been deactivated to fix FTBFS, see bug 243573. I tried a build with scrollkeeper enabled and it worked. So do we again use scrollkeeper?
[11:18] <seb128> Ampelbein: no
[11:18] <seb128> Ampelbein: scrollkeeper should be run on the client side not on the buildd
[11:19] <Ampelbein> seb128: ok, so i drop the build-dep, too?
[11:20] <seb128> if it's not required
[11:20] <seb128> I'm not sure how smart the configure is, ie try to pbuilder it without the build-depends
[11:47] <asac> pitti: so the sudo su -> root @console caused kind of colleteral damage to network manager ...
[11:47] <asac> pitti: walters said its unfortunate, but he thinks that root shouldnt be @console unless you login at gdm or a real console
[11:49] <asac> bug 360818 bug 371291
[11:50] <asac> pitti: in particular this means that using "deny" in @console rules is not practical as it will remove permissions from root
[11:51] <asac> no action needed for jaunty ... we will change the network manager rules to not use any deny in @console ... but i guess we should consider to not make root @console for simple sudo su's
[11:57] <Ampelbein> seb128: bug 371952 ready for review, see the linked branch.
[12:03] <seb128> Ampelbein: ok thanks
[12:04] <seb128> Ampelbein: you can do the same for gnome-utils next if you want ;-)
[12:05] <pitti> asac: oh, do you really rely on d-bus ACLs in network-manager?
[12:05] <Ampelbein> seb128: will have a look after lunch
[12:05] <seb128> Ampelbein: no hurry, enjoy your lunch
[12:05] <pitti> asac: I had hoped that at_console will go away at some time, and we can remove that hack from d-bus (with the /var/run/console/ stamps)
[12:05] <pitti> Polkit already knows that stuff, after all
[12:06] <asac> pitti: we rely on dbus acls for some parts ...  look at /etc/dbus-1/system.d/NetworkManager.conf for instance
[12:07] <asac> pitti: @console going away is probably the right long term thing
[12:07] <asac> i agree
[12:07] <asac> i will check with dan how much work is to use polkit everywhere
[12:07] <pitti> ah, I see
[12:08] <pitti> asac: so the problem is that if you do sudo -i, that terminal gets a CK session for root, and thus is able to access NM, although it shouldn't be?
[12:08] <asac> pitti: no. the problem is more devastating :)
[12:09] <asac> pitti: nm consists of multiple parts that communicate through dbus
[12:09] <asac> ... all running as root
[12:09] <asac> now you do sudo su
[12:09] <asac> and booooom. those parts cannot communicate anymore because the @console "deny" prevents it
[12:09] <asac> ;)
[12:10] <asac> so the problem is that @console leads to less permissions for root
[12:10] <asac> than without @console
[12:13] <asac> pitti: shouldnt the at_console check actually check whether the process is a child of the console?
[12:13] <asac> i think i can answer that by myself
[12:13] <asac> problem is obviously the /var/run/console/ thing ;)
[12:14] <pitti> asac: I wonder why you need that deny rule in the first place
[12:14] <asac> is there a different approach for that?
[12:14] <asac> pitti: without that deny all @console can access that interface
[12:14] <asac> pitti: we will now use explicit interface allows
[12:15] <asac> e.g. listing all interfaces that are allowed explicitly rather than adding a generic destination allow with a interface deny
[12:15] <pitti> asac: that's strange; d-bus should deny access to methods by default
[12:15] <pitti> it didn't in the past, but that was fixed in jaunty
[12:15] <asac> pitti: well. there is is a generic allow destination
[12:15] <pitti> oh, I see
[12:15] <pitti> asac: right, ignore me
[12:15] <asac> allow send_destination="org.freedesktop.NetworkManager"/>
[12:15] <asac> yeah
[12:16] <asac> so that will be replaced by all interfaces named explicitly ... which is a bit hard to maintain but also makes some sense
[12:16] <asac> hopefully that works ;)
[12:16] <asac> seems more users than expected have root shells open while doing networking
[12:18] <pitti> interesting bug, though
[12:18] <asac> yeah
[12:18] <asac> arguably dbus shouldnt deny anything for root user imo ;)
[12:19] <asac> that would at least reflect the unix best practices
[12:19] <asac> well old-best-practices. i think with selinux and stuff thats not always true anymore
[12:34]  * pitti -> lunch and some errands
[12:52] <Ampelbein> seb128: doing gnome-utils now
[12:52] <seb128> good
[13:29] <seb128> pedro_: holla!
[13:29] <seb128> or "olla"?
[13:29] <pedro_> seb128: salut my friend!
[13:29] <seb128> pedro_: how are you?
[13:29] <pedro_> seb128: hola with just one l ;-)
[13:29] <seb128> hola then ;-)
[13:29] <pedro_> seb128: good good looking at some evo bugs, how about you?
[13:29] <seb128> good
[13:30] <seb128> pedro_: do you still run jaunty?
[13:30] <seb128> pedro_: could you help to confirm some of my desktop srus so they can be moved to updates
[13:30] <seb128> pedro_: some are trivial to test on any config
[13:30] <pedro_> seb128: yeap, at least for a couple of more weeks for doing SRU verifications
[13:30] <seb128> pedro_: ok, so could you do some of those on desktop components? ;-)
[13:31] <pedro_> seb128: sure ;-)
[13:31] <pedro_> count with that
[13:31] <seb128> the gnome-settings-daemon ones should be easy (out of the lid close crasher)
[13:31]  * pedro_ looking at the pending list
[13:32] <seb128> same about gnome-applets, at least confirming that the update works correctly
[13:32] <seb128> nautilus too
[13:33]  * seb128 kicks launchpad
[13:33] <seb128> now it's playing bugzilla and timeout!
[13:33] <pedro_> seb128: ok will do those today
[13:33] <seb128> thanks
[13:33] <pedro_> yeah it's working freaking slow for me too :-/
[15:11] <pedro_> seb128: bug 360084 ; it's still an issue with the proposed version of g-s-d and seems to depend on a change to gnome-control-center as stated on the upstream report
[15:11] <pedro_> commit is at http://git.gnome.org/cgit/gnome-control-center/commit/?id=6ea3c02290362ae3e9b4e9259bc72fc0b4ac45d2
[15:12] <seb128> pedro_: ok, fine, write that on the bug saying that it's still working the same way but not broken in new ways
[15:12] <pedro_> seb128: ok will do it
[15:12] <seb128> ie we can move that to updates it doesn't fix everybody but doesn't break either
[15:12] <seb128> thanks
[15:13] <pedro_> you're welcome
[15:13] <seb128> the sru was not especially for this bug but I listed everything fixed in the new version ;-)
[15:20] <seb128> ok, time to go to catch my plane for the dxteam sprint
[15:20] <seb128> see you later
[17:22] <rickspencer3> awe: fyi, our team meeting is in 8 mins
[17:26] <pitti> uh, https://blueprints.edge.launchpad.net/sprints/uds-karmic?searchtext=desktop-karmic- is quite well filled
[17:27] <awe> rickspencer3: thanks!   you might want to update the wiki page, it says 14:00 UTC
[17:27] <awe> oops, i meant 16:00 UTC
[17:27] <rickspencer3> pitti: with two rooms, I think we have room for like 36 total or something
[17:27] <rickspencer3> awe: thanks
[17:27] <rickspencer3> could you please adjust it (being a wiki and all ;) )
[17:28] <rickspencer3> I think the fridge is correct
[17:29] <rickspencer3> 5 days x 5 Sessions per day X 1.5 rooms = 37
[17:29] <rickspencer3> pitti: sound about right ^^^ ?
[17:29] <pitti> why 1.5 rooms?
[17:29] <pitti> that's for desktop + DX + OLS, right?
[17:29] <asac> meeting?
[17:29] <rickspencer3> we have two rooms, but should save some space for impromptu meetings
[17:29] <pitti> or does OLS have their own?
[17:30] <pitti> rickspencer3: right
[17:30] <rickspencer3> design and dx
[17:30] <rickspencer3> I kept OLS in desktop track for now
[17:30] <rickspencer3> so there are some design-karmic-*
[17:30] <rickspencer3> and dx-karmic-* sessions as well
[17:30] <calc> what is OLS?
[17:30] <rickspencer3> calc: Online Services
[17:30] <calc> ah ok
[17:31] <rickspencer3> we should be saying Ubuntu1 now
[17:31] <rickspencer3> sorry
[17:31] <kenvandine_wk> yo
[17:31] <asac> so is this meeting ;)?
[17:31] <calc> no going to start any second now though
[17:31] <bryce> heya asac
[17:31] <rickspencer3> hehe
[17:31] <asac> hi bryce
[17:31] <calc> hi
[17:31] <rickspencer3> meeting time
[17:31] <rickspencer3> tkamppeter: welcome, are you there?
[17:31] <kenvandine_wk> i am laggy from the u1 upload that is happening here :)
[17:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-05-05
[17:32] <rickspencer3> I believe seb128 is traveling to the Dx sprint in London
[17:32] <rickspencer3> everyone ready to go?
[17:32] <kenvandine_wk> yup
[17:32] <rickspencer3> Riddell: ready?
[17:32]  * rickspencer3 poke poke
[17:33] <Riddell> hi
[17:33] <rickspencer3> Let's go a little out of order, start with introducing awe
[17:33] <rickspencer3> awe = Tony Espy, and he'll be an honorary desktopper for Karmic!
[17:34] <asac>  \o/
[17:34] <pitti> hey awe, welcome to the team!
[17:34] <kenvandine_wk> welcome awe!
[17:34]  * awe hey guys, nice to be part of a the new gang!
[17:34]  * asac waves @ awe 
[17:34] <rickspencer3> welcome awe!
[17:34] <bryce> heya awe
[17:34] <pitti> finally we have our own guitar rock star
[17:34] <awe> ;/
[17:34] <rickspencer3> awe: do you want to introduce yourself briefly?
[17:34] <awe> sure
[17:35] <awe> i've spent the last 9 months or so as tech lead on the hp mini
[17:35] <awe> for oem services
[17:35] <awe> my background is networking plus desktop audio playback
[17:35] <tkamppeter> hi, I am
[17:35] <awe> i've also spent a lot of time working with the kernel team and defining how oem plays with the kernel
[17:36] <awe> look forward to working with you all on karmic
[17:36]  * awe done w/intro
[17:36] <rickspencer3> sweet
[17:36] <rickspencer3> awe: you were a pepper, right?
[17:37] <rickspencer3> (pepper = worked on Pepper Pad)
[17:37] <awe> yes.  i build an equiv of network-mgr in java for pepper, plus the audio playback subsys based on helix
[17:37] <awe> s/build/built/
[17:37]  * rickspencer3 <3 pepper pad
[17:37] <asac> awe-some ;)
[17:37] <kenvandine_wk> haha
[17:38] <awe> plus i play back up guitar for pitti on "wish you were here"  ;)
[17:38] <rickspencer3> I know that I speak for everyone when I say that we are really glad to have you on the team, and we're looking forward to seeing what you do in Karmic
[17:39] <awe> thanks
[17:39] <rickspencer3> moving on
[17:39] <rickspencer3> actions from last meeting:
[17:39] <rickspencer3> ACTION: rickspencer3 to get definitive list of who has talks at all hands to double check that everyone who has one is prepared
[17:39] <rickspencer3> I totally FAILed at this, but I'm still trying
[17:39] <rickspencer3> there must be a list somewhere :)
[17:39] <pitti> the track leads certainly have themm
[17:39] <rickspencer3> pitti: good idea
[17:40] <rickspencer3> I was looking for the one list to rule them all, but just pinging track leads should work
[17:40] <asac> so can we assume that we dont have a talk if we didnt hear anything yet?
[17:40] <pitti> rickspencer3: or ask cvd, when I talked to her on the phone last week she had the schedule
[17:40] <rickspencer3> asac: I think that we *shouldn't* assume that yet, as I am concerned that perhaps some emails were filtered out in spam filters
[17:41] <asac> rickspencer3: who would have sent such a mail?
[17:41] <rickspencer3> some people got emails saying their talks *weren't* accepted, but it's not clear if this was consistent across tracks
[17:41] <asac> cvd?
[17:41] <asac> hmm.
[17:41] <asac> ok i will check with brian who submitted the talk
[17:41] <rickspencer3> asac: I'll take care of finding out asap and let you know
[17:41] <asac> thanks a lot
[17:42] <rickspencer3> next topic: UDS
[17:42] <rickspencer3> did everyone get their blueprints in?
[17:42] <kenvandine_wk> yup
[17:42] <bryce> asac, the email started with, "ENLARGE your member ship for your talk like you were on v1agr4!!!1!" you didn't get that one?
[17:42] <asac> bryce: oh ... i have more than 100 matches;)
[17:43] <bryce> asac: bingo
[17:43] <rickspencer3> hehe
[17:43] <pitti> I just have two, but they are both quite big, so I don't think I'd like to pile up more for karmic
[17:43] <pitti> since I also want to work on the devkit migration
[17:43] <bryce> rickspencer3: I've gone mine in, but there's too many; probably should trim them down a bit
[17:43] <rickspencer3> Riddell: I didn't see Kubuntu blueprints in pitti's link
[17:43] <asac> rickspencer3: blueprints without sessions dont need to be in yet?
[17:43] <rickspencer3> asac: I suppose so
[17:43] <miha> hello guys, 1. ubuntu with desktop effects likes to hang when you press notebook keys such as volume up when playing movies/down, 2. network manager fails to reconnect (you must enter password again and press connect)
[17:44] <pitti> https://blueprints.edge.launchpad.net/sprints/uds-karmic?searchtext=kubuntu
[17:44] <asac> rickspencer3: ok. thanks.
[17:44] <pitti> rickspencer3: they are prefixed kubuntu-
[17:44] <rickspencer3> miha: hi, we're in a meeting right now
[17:44] <miha> ok
[17:44] <miha> sorry
[17:44] <rickspencer3> you might want to ask in #ubuntu
[17:44] <rickspencer3> no problems, you're welcome to hang out
[17:44] <pitti> https://blueprints.edge.launchpad.net/sprints/uds-karmic?searchtext=kubuntu-karmic- is better
[17:44] <rickspencer3> pitti: thanks!
[17:44] <rickspencer3> Riddell rocks, as usual
[17:45] <rickspencer3> so essentially, pitti and rickspencer3 will sort, prioritize and such by eod Thursday
[17:45] <asac> rickspencer3: i will setup a blueprint about NM UI topics (first start, wizard, etc.) in karmic ... thats the only one left i want broader discussion on.
[17:45] <asac> doing that right after meeting
[17:45] <rickspencer3> asac: thanks
[17:45] <rickspencer3> anyone else have blueprints that need to be submitted?
[17:46] <rickspencer3> note that we have two rooms, but are covering Dx, Design, and Ubuntu1 in our track
[17:46] <asac> the prefix is ubuntu-desktop-... ?
[17:46] <asac> ah ubuntu-karmic
[17:46] <rickspencer3> none the less, I'd like to keep a lot of time unscheduled for impromptu sessions
[17:46] <rickspencer3> asac: right, the naming convention is ubuntu-karmic-*
[17:46] <pitti> asac: desktop-karmic-*
[17:46] <rickspencer3> heh
[17:46]  * asac confused ;)
[17:46] <rickspencer3> right desktop-karmic-*
[17:47] <rickspencer3> (my bad)
[17:47] <rickspencer3> Riddell confused me :)
[17:47] <rickspencer3> so is everyone good to go with blueprints?
[17:48] <rickspencer3> moving on: Desktop Summit
[17:49] <rickspencer3> if you are going, please add yourself to the meeting page
[17:49] <rickspencer3> I created a little table there
[17:49] <Riddell> which meeting page?
[17:49] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-05-05
[17:49] <rickspencer3> Riddell: ^^^
[17:50] <rickspencer3> next topic: Triaging versus Bug Fixing/Closing in Karmic
[17:50] <rickspencer3> I just wanted to briefly bring this up as pitti and I have both been talking to desktop engineers, and it seems pretty universal that the current mix is not right
[17:50] <rickspencer3> I don't want to brainstorm about it here, but ...
[17:51] <pitti> it's not so much of a mix, as of a "when to stop?" and "what to look at" questions
[17:51] <rickspencer3> I think we should have a UDS talk about how to handle bug inflow
[17:51] <rickspencer3> pitti: sure
[17:51] <rickspencer3> that's a good way to put it
[17:52] <rickspencer3> I wanted to make two points now:
[17:52] <pedro_> count me in for that session, I'd love to help with that
[17:52] <rickspencer3> 1. We should tackle this problem as a team, but the implementation of any solutions may look different for each product area, as the problems manifest differently
[17:53] <rickspencer3> 2. We should consider *bold* action in Karmic
[17:53] <rickspencer3> pedro_: absolutely!
[17:53] <bryce> bold action?
[17:54] <rickspencer3> bryce: yes
[17:54] <miha> Comrades, we stand at edge of cliff. We must make a bold step forwards. (old Yugoslavian joke) :)
[17:54] <rickspencer3> like don't think in terms of a 10% increase in throughput
[17:55] <rickspencer3> think about a 10 fold increase
[17:55] <rickspencer3> stretch your comfort zone
[17:55] <pitti> before we can determine/measure this, we first need to define "throughput"
[17:55] <pitti> in terms of "what do we want to achieve"
[17:55] <rickspencer3> pitti: hehe
[17:56] <asac> i think the ideal goal would be that developers can filter everything not triaged or so to /dev/null and spend all their time on real bug-fix work
[17:56] <asac> isntead of bugmail work
[17:56] <rickspencer3> asac: that's a great example
[17:56] <pitti> I liked the bug gravity idea
[17:56] <asac> bug-fix work == fix on own AND work with upstream
[17:57] <asac> pitti: what definition of gravity do you like?
[17:57] <pitti> to make us focus on what's most important, to maximize the usefulness
[17:57] <rickspencer3> bryce: make sense? It would be ideal if you felt that you could suggest radical approaches
[17:57] <calc> disable all desktop bug reporting without using apport would help get to the 10x throughput
[17:57] <rickspencer3> calc: yes!
[17:57] <asac> pitti: for the triaging or the bug-fixing?
[17:57] <pitti> asac: number of affected people, type of attached debugging information, number of dups, reported by core-dev member, etc.
[17:58] <asac> yeah
[17:58] <pitti> asac: triaging
[17:58] <pitti> I think once we got a bug to triaged/assigned, we are doing pretty good
[17:58] <rickspencer3> I think asac is suggesting "no triaging" for engineers!
[17:58] <pitti> the challenge is to pick the "right" ones
[17:58] <asac> pitti: i agree, but still developers would get rid of the triaging stage at all if possible
[17:58] <bryce> rickspencer3: it's still seeming rather ambiguous how to apply to X, but I'm listening
[17:58] <pitti> asac: unfortuantely their special knowledge is required very often
[17:59] <asac> pitti: thats true, but also depends on the area you look at
[17:59] <pitti> bryce: I think the point is that everyone shouldl think about the problem from his perspective
[17:59] <rickspencer3> bryce: here's a thought exercise, if you only had 1 hour a week to triage bugs, what would yo do with that time?
[17:59] <asac> pitti: for mozilla its 99.0% of bugmail that i doesnt require special skills
[17:59] <calc> for eg OOo there is very little if any triaging being done besides me currently, so i think getting the community to do more towards triaging would be needed before having engineers no longer do it
[17:59] <asac> just a guidance and man power
[17:59] <pitti> and thus at UDS we can share our thoughts
[17:59] <rickspencer3> anywho ... let's bring these ideas to UDS
[17:59] <calc> ok
[18:00] <asac> pitti: well it definitly requires special skills, but not at the early stages
[18:00] <pitti> asac: for triaging as in the medical sense ("set priority and look how many are affected"), that's probably very true
[18:00] <rickspencer3> I just wanted to plant the seed of thinking bold and trying something new and perhaps even agressive
[18:00] <rickspencer3> as pitti put it early "turn the problem upside down"
[18:00] <asac> pitti: yeah. for me it would be a huge improvement if my incoming queue would be just bugs that are properly prepared (thats what i refer to for triaging)
[18:01] <pitti> "Enter an 11-digit prime number to file this bug"
[18:01] <pitti> *cough*
[18:01] <rickspencer3> !
[18:01] <asac> the evaluation part of triaging needs to be done by developer. if we are also overloaded on that side we need gravity
[18:01] <asac> for that or more engineers ;)
[18:01] <pitti> so, some questions to think about:
[18:02] <pitti>  - Which kind of your typical bugs would you classify as "something I want to work on", and "something I want to look at", and "something I shouldn't look at"
[18:02] <bryce> rickspencer3: I guess if I had only an hour to triage, I'd use 45 min to write a launchpadlib script to automate the triaging, and then run that for the last 15 min ;-)
[18:02] <pitti>  - "how can I organize my bug queues in a way that I can process something to zero without getting overloaded"
[18:02] <kenvandine_wk> bryce: good answer :)
[18:03] <pitti> bryce++
[18:03] <rickspencer3> kewl
[18:03] <pitti>  - "which of my current work can be documented and automated"
[18:03] <rickspencer3> any other business?
[18:04] <pitti> o/
[18:04] <pitti> I had a topic for -intel
[18:04] <pitti> so, we have our first alpha-1 next Thursday
[18:04] <pitti> I think it would be nice if we could upload -intel 2.7.0 and turn on UXA by default
[18:04] <pitti> so that we can run our karmic "target" architecture for as long as possible, and collect feedback early
[18:05] <pitti> given how long it takes to fix some of those bugs, we can't start early enough I think
[18:06] <pitti> bryce: do you think that's reasonable?
[18:06] <pitti> or is there something blocking that?
[18:06] <bryce> well
[18:07] <bryce> right now we have a lot of UXA bugs, and in talking with Intel I see we have some leverage to get attention on these
[18:07] <bryce> if we move ahead and enable UXA I sort of worry Intel may conclude that we no longer consider them blocking issues, and give them less priority
[18:07] <pitti> bryce: so you want them to fix the first wave of then first?
[18:07] <pitti> s/then/them/
[18:08] <bryce> ideally, yes, if it doesn't impact our schedule for KMS enablement
[18:08] <pitti> (btw, I enabled that here, but no noticeable difference, even with usplash disabled)
[18:08] <bryce> what I am doing these days is basically 75% triaging/upstreaming UXA bugs and 25% KMS preparations
[18:09] <bryce> I've written a script to generate reports on current state of UXA bugs, that I send to Intel
[18:09] <pitti> okay, I see
[18:09] <bryce> I'll send a copy of the next one to ubuntu-devel@ for transparency
[18:09] <pitti> bryce: so perhaps 2.7.0 with exa, as in the xorg-edgers PPA?
[18:09] <bryce> for KMS, I'm working on putting together a wiki page to howto and capture testing results... link in a sec
[18:10] <bryce> https://wiki.ubuntu.com/X/KernelModeSetting <-- still a WIP
[18:10] <bryce> pitti: yes 2.7.0/exa is available now from https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/
[18:11] <bryce> I can also upload that for karmic... I started doing that but got distracted for some reason.  Should be up this week at the latest.
[18:11] <pitti> I just wondered whether there are specific reasons to hold it back
[18:11] <bryce> oh yeah I remember - the package in x-updates doesn't have the patches included in our 2.6.3 version, so I need to take time to do the merging
[18:11] <pitti> bryce: if you say that not enabling it by default yet will increase pressure to fix uxa bugs, so much the better :)
[18:12] <bryce> that's the plan :-)
[18:12] <pitti> ok, thanks for the heads-up
[18:12] <bryce> so far there are >20 bugs which will be regressions once we enable UXA
[18:13] <bryce> those are freshly tested; and that seems like a lot to me given that people are having to manually enable it at this point, I'd like to cut that down a lot before switching over
[18:13] <rickspencer3> bryce: Yingying_Zhao will be hosting weekly calls starting next week, so I'll be able to cover your bug list for you there
[18:13] <bryce> great
[18:14] <rickspencer3> any other business?
[18:14] <kenvandine_wk> one thing
[18:14] <bryce> calc, how's your son doing?
[18:14] <kenvandine_wk> i will be emailing everyone soon to test an update to u1 :)
[18:15] <rickspencer3> meeting adjourned?
[18:15] <bryce> thanks!
[18:15] <pitti> thanks everyone
[18:15] <rickspencer3> kenvandine_wk: right. What was the uptake on U1?
[18:15] <rickspencer3> did everyone on the desktop team install it?
[18:15] <rickspencer3> (hint hint)
[18:15] <awe> +1
[18:15] <kenvandine_wk> rickspencer3: i don't have reports from everyone
[18:16] <kenvandine_wk> you, pitti and Riddell for sure
[18:16] <rickspencer3> okay, we'll look for your email, and set something up so we can get everyone on it
[18:16] <awe> kenvandine_wk: what kind of report do you need?
[18:16] <kenvandine_wk> well, bug reports
[18:16] <calc> bryce: doing ok now
[18:16] <kenvandine_wk> does it work for you
[18:16] <kenvandine_wk> etc
[18:16] <calc> bryce: he was sick about a week
[18:16] <kenvandine_wk> awe:  basically we want as many people to really use it as possible
[18:17] <kenvandine_wk> there are lots of bugs fixed since last week, so there should be a new package soon
[18:17] <awe> kenvandine_wk: cool.  i had problems with it a few weeks back, but it's been solid ever since.  nice work
[18:17] <kenvandine_wk> i will mail the group when it is ready
[18:17] <bryce> calc: good to hear
[18:18] <kenvandine_wk> it won't sync my data yet :/
[18:18] <rickspencer3> thanks kenvandine_wk
[18:18] <rickspencer3> calc: glad your son is on the mend!
[18:18]  * rickspencer3 wishes he had a gavel
[18:18] <rickspencer3> thanks all!
[18:18] <asac> thanks
[18:18] <rickspencer3> mdz: hi!
[18:19] <mdz> howdy, desktop folk
[18:19] <kenvandine_wk> hey mdz
[18:19] <asac> welcome ;)
[18:19] <bryce> hi mdz
[18:21] <pitti> hey mdz
[18:22] <calc> hi
[18:40] <miha> i disabled all gnome effects..this ubuntu cute volume thing doesnt work with dekstop things
[18:40] <miha> and especially not with any movie player
[18:40] <miha> can i complain about that? :)
[18:41] <hyperair> what if i said no?
[18:41] <miha> i already said it :)
[18:41] <hyperair> oh whoops
[18:41] <miha> hehe
[18:42] <miha> is it known bug? does it matter i use ATI and the just support this effects? :)
[18:42] <hyperair> ?
[18:42] <hyperair> i don't understand you
[18:42] <chrisccoulson> hey pitti - i'm looking at getting tracker 0.7.0 ready for karmic. it has a new build-dependency on a package currently in universe though
[18:42] <chrisccoulson> not sure what to do :/
[18:43] <pitti> chrisccoulson: disable it, or file a MIR if it isn't crackful
[18:43] <miha> hyperair if i have gnome effects enabled,play divx in full screen.. and i either swith program or press volume up, Xorg crashes and then everything hangs
[18:43] <miha> switch
[18:43] <chrisccoulson> i had a look at disabling it, and it doesn't look possible. the dependency is valac, which i think is only needed at build-time
[18:44] <chrisccoulson> i can file a MIR for that
[18:44]  * hyperair washes his hands off this issue and goes to sleep
[18:44] <miha> hyperair sweet tight!:)
[18:44] <miha> sleep
[18:44] <hyperair> can't help you there. i'm using intel and got my own share of rubbish
[18:44] <miha> hehe
[18:44]  * hyperair glares in the general direction of the intel gpu driver devels
[18:44] <miha> hyperair well i disabled effects, again those nvidia kids will brag :(
[18:45] <miha> hyperair take care
[18:46] <hyperair> thanks
[18:46] <hyperair> you too
[18:46] <pochu> miha: you could try nouveau, not sure it will help though :-)
[18:47] <pochu> miha: #ubuntu-x sounds more appropriate though
[18:49] <miha> pochu i think problem is that these effects dont work with xv on ati drivers
[18:49] <miha> i might be wrong
[18:49] <miha> i had problems only with moview
[18:49] <miha> movies
[18:50] <pochu> oh, you have ati not nvidia
[18:50] <pochu> I misread then, sorry
[18:50] <miha> yeah, only in newest drivers they even support composite + direct rendering :)
[18:50] <miha> i guess it will get better?! :)
[18:50] <pochu> anyway it sounds offtopic here, this is not a support channel :-)
[18:51] <miha> okey sorry
[18:51] <miha> just i think such questions are ignored on the help channel :)
[18:51] <miha> take care
[18:51] <rickspencer3> bryce: any chance you could weed your blueprints today?
[18:52] <bryce> um, yeah...
[18:56] <bryce> rickspencer3: can we merge desktop-karmic-intel-video-retrospective into one of the others?
[18:56] <rickspencer3> bryce: sure, whatever you want
[18:57] <rickspencer3> I have to take a call now, can you send mail or ping me this afternoon?
[18:57] <rickspencer3> oh wait
[18:57] <rickspencer3> actually, we should probably keep that one on it's own
[18:57] <rickspencer3> (or cut it)
[19:02] <james_w> bryce: there's a jaunty retrospective on the foundations track that it could perhaps be merged in to?
[19:04] <bryce> james_w: mm possibly, esp. since we found that the core issues for the -intel driver issues was actually kernel changes needed, not localized to X/userspace
[19:05] <james_w> you could chat to robbie, as it sounds like you would like a couple of kernel people there as well
[19:10] <bryce> james_w: you mean pete?
[19:10] <james_w> yeah, I guess him too
[19:10] <james_w> I meant ask Robbie what he was planning to use the session for, and whether he could pull in a couple of people from each team for it
[19:10] <bryce> oh gotcha
[19:11] <bryce> well, rick had asked for this session specifically, so I'll leave it to his judgment
[19:12] <bryce> I suppose people will appreciate having a dedicated session to complain about all the problems that resulted from updating -intel past 2.4
[19:12] <james_w> heh :-)
[19:27]  * awe goes offline for awhile...  back online @ 4 EDT
[19:28] <artir> the meeting is over?
[20:03] <crevette> hello
[20:28] <calc> wow that was nice of xorg... it crashed in the middle of me using it
[20:29] <calc> not even on a sleep/resume change or something more obvious like that
[20:30] <chrisccoulson> You need to add `Option "NoCrashyForCalc" 1` or something to your xorg.conf ;)
[20:32] <calc> hehe
[20:32] <calc> it went to a bright green screen with bits of it blinking then back to gdm login
[20:32] <calc> its the first time i've seen it crash in probably a month
[20:33] <chrisccoulson> yeah, i haven't actually seen it crash for many months. although i have had a garbled screen occasionally
[20:40] <chrisccoulson> does any compiler like gcc display visible strings with proper internationalization?
[21:18] <pitti> good night everyone