[08:03] <pitti> Good morning
[08:08]  * bryce waves to pitti
[08:08] <pitti> hey bryce
[08:09] <pitti> bryce: so you think hal-less X.org would actually be feasible for lucid? from the ML and mjg59's comments it seemed that it would be too hard
[08:09] <bryce> pitti, I don't really think it is feasible without incurring a considerable number of regressions
[08:10] <bryce> pitti, however keybuk felt it had to be done regardless
[08:11] <bryce> pitti, so I'm unclear as to what to do and could use your direction on this one
[08:12] <pitti> bryce: for normal mice/keyboards it shouldn't actually be hard; I'm mostly concerned about those wacom things
[08:12] <pitti> TBH I have no idea how those work
[08:12] <pitti> for normal mice/keyboards, I'm happy to build a test X.org server in a PPA with the patch, and with the Ubuntu specific bits to set the keyboard layout
[08:14] <bryce> mostly I'm concerned with the manpower that'll be required to chase down and fix regressions this change may cause
[08:15] <pitti> bryce: do you know of other "weird" input devices that we need to be concerned about?
[08:15] <pitti> touch screens seem to be represented as normal mice
[08:16] <pitti> I have a Joystick, we can test those as well
[08:16] <bryce> yeah
[08:16] <bryce> anything where we have some fdi files, I guess those will need changed into udev rules
[08:16] <pitti> but the basic task is actually quite simple: get the input device list from the kernel (lsinput-like), augment it with some properties like keyboard layout, and poke it into X
[08:17] <pitti> right now, it's udev -> hal -> X.org, and we'd just skip the middle man
[08:17] <bryce> for wacom, I've contacted the wacom driver developer about it
[08:17] <pitti> keyboard layouts are well understood, they just need to be grabbed from /etc/default/console-setup for us
[08:18] <pitti> one problem I know of are options for the synaptics driver
[08:18] <bryce> we'll need xserver 1.7 but once we're on that, there is a fixed -wacom available we can use
[08:18] <pitti> oooh
[08:18] <pitti> well, 1.7 is the plan anyway, right?
[08:18] <pitti> bryce: so, I don't see a principal reason why the synaptics options couldn't become udev properties instead of hal properties
[08:18] <bryce> right (and not coincidentally)
[08:18] <pitti> it might not be the cleanest solution, but it will work
[08:19] <pitti> in the long run, those options should maybe get back into xorg.conf
[08:19] <bryce> noooo
[08:19] <pitti> or an xorg.conf.d/50-synaptics or so
[08:20] <pitti> but anyway, converting that synaptics fdi file into an udev rules file to slam the parameters to the touchpad input device seems entirely feasible
[08:20] <didrocks> hey bryce and pitti
[08:20] <pitti> bonjour didrocks! comment vas-tu?
[08:20] <bryce> heya didrocks
[08:21] <pitti> bryce: I reopened the BP for now
[08:21] <didrocks> pitti: sehr gut, und du? :)
[08:21] <didrocks> (not sure of my german though)
[08:22] <pitti> didrocks: tres bien, merci!
[08:22] <didrocks> :)
[08:22] <pitti> didrocks: your German is perfect :)
[08:23] <didrocks> pitti: ahah, if I only use few words... ;)
[08:26] <pitti> bryce: want me to write some udev rules to produce sth. like on http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/2108 ?
[08:26] <bryce> pitti, sounds good
[08:27] <pitti> bryce: so, I think if we are going to do this, we should do it soon, to see where the regressions are
[08:27] <pitti> so how about:
[08:27] <pitti> 1. apply the patch soon (by alpha-1), pitti to create udev rules for keyboard layout, etc.
[08:28] <huats> morning everyone
[08:28] <pitti> 2. update to new wacom driver and test it (who could do this?)
[08:28] <bryce> when's alpha-1?
[08:28] <pitti> 3. at alpha-3, make the call to revert (because of regressions), or keep
[08:28] <pitti> ?
[08:28] <pitti> bryce: hm, december 10th
[08:28] <pitti> perhaps alpha-2 then
[08:29] <bryce> ok that sounds more doable
[08:29] <pitti> bryce: I don't think that the original patch requires 1.7 (just the new wacom does)
[08:29] <pitti> but ICBW, I didn't try to apply it yet
[08:29] <bryce> #2 has as pre-requisite merging in xserver 1.7 (and all of its protos and libs that it depends on)
[08:30] <bryce> true the udev patch may work against what we have now for xserver
[08:30] <bryce> in which case I can probably slap it in tomorrow
[08:33] <pitti> bryce: does Alberto or you have a wacom device for testing?
[08:33] <pitti> or Timo?
[08:34] <bryce> I sent Alberto a tablet, and I've got one myself
[08:34] <bryce> I think Timo has one but am not certain
[08:35] <tjaalton> I have a waltop, not proper wacom
[08:35] <tjaalton> and it doesn't work with the driver in karmic
[08:35] <tjaalton> don't know if it ever will
[08:36] <pitti> bryce: options in xorg.conf> http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/2108
[08:36] <bryce> pitti, oh -evtouch supported devices probably will also break when we move away from hal
[08:36] <tjaalton> the brand name is aiptek media tablet 10000U
[08:39] <pitti> bryce: oh, do we use that? at least the "fake" touchscreen in kvm is just a normal evdev mouse; we could ask ogra to check on his real touchscreen
[08:39] <pitti> it's in universe, hmm
[08:41] <bryce> pitti, yeah all the touchscreen stuff is in a really sorry state
[08:41] <tjaalton> jcristau (the author of the udev patch) said that the only missing bit is recognizing a synaptics device
[08:41] <bryce> the hal changes will just make it sorrier
[08:42] <tjaalton> because now it's done by matching input.touchpad, but udev doesn't have that AIUI
[08:42] <bryce> tjaalton, ogra told us in the touchscreen session that he'd fixed up -evtouch to work with hal, and added some fdi's for it
[08:42] <tjaalton> bryce: I meant synaptics
[08:42] <bryce> oh gotcha
[08:42] <pitti> tjaalton: well, hal has to figure it out somehow, too (IIRC it looks at the types of events  it can produce and sets this capability)
[08:43] <pitti> tjaalton: no reason that this bit cannot become an udev callout to set the property, if we need it
[08:43] <tjaalton> pitti: right
[08:43] <tjaalton> but not there yet ;)
[08:43] <pitti> I can write that bit
[08:44] <tjaalton> I guess that's why it's not merged upstream yet
[08:44] <pitti> I'd probably just stick it into udev proper, into some extras/
[08:44] <pitti> once it works
[08:47] <tjaalton> what ML did you refer to where it was said to be hard to drop hal?
[08:48]  * pitti tries to remember
[08:48] <pitti> tjaalton: I think it was from mjg59, probably somewhere on devkit-devel@
[08:48] <tjaalton> pitti: thanks, I'll check that out
[08:48] <pitti> at that time I thought we didn't want to backport that stuff, and that wacom would be too big of a problem for lucid
[08:49] <pitti> tjaalton: he basically said that "xorg is not ready for this yet, so we'll have to keep hal for the next cycle"
[08:49] <tjaalton> wacom does it's own hotplugging now, and set's up the device according to what the kernel says it has
[08:50] <pitti> yay
[08:51] <bryce> tjaalton, had a chance to look at what we need to do for getting xserver 1.7 in lucid?
[08:51] <tjaalton> bryce: only ~6 libs to go, then updating xorg & xorg-server
[08:52] <bryce> sweet
[08:52] <tjaalton> there are more libs to upload to unstable when jcristau has time (maybe tomorrow), then the rest of the proto's can go too
[08:52] <tjaalton> uploading them now would make the xserver unbuildable
[08:52] <tjaalton> so they need to go in at the same time
[08:53]  * bryce nods
[08:54] <pitti> bryce: do you know if there's a newer patch than the original one proposed by Julien in http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/2108 ?
[08:55] <bryce> hmm, not spotting it
[08:55] <pitti> bryce: it's not in that thread, but there were some discussions how to improve it
[08:56] <bryce> yeah
[08:56] <bryce> seems not to be in git yet
[08:56] <bryce> at least, not in master
[08:57] <bryce> bingo http://cgit.freedesktop.org/~jcristau/xserver/
[08:57] <pitti> rocking
[08:57] <bryce> pitti, ^ newer stuff there
[08:59] <pitti> bryce: I'm working on creating udev rules now (a default "evdev for everything" corresponding to 10-x11-input.fdi, and one for "synaptics" corresponding to 11-x11-synaptics.fdi)
[08:59] <bryce> ok
[08:59] <AnAnt> Hello, when I attempt to install gnome-shell (in karmic), I found that it wants to pull several -dev packages, is that a bug ?
[09:03] <mac_v> AnAnt: the Ubuntu version is old , its better you use the upstream version
[09:04] <AnAnt> mac_v: is there a PPA ?
[09:06] <mac_v> AnAnt: hmm , there is a ppa mentioned in this thread > http://ubuntuforums.org/showthread.php?t=1305154 , but its pretty easy to build from upstream version itsefl
[09:06] <mac_v> itself*
[09:07] <mac_v> AnAnt: its just like 4 commands to install from upstream and you get the shell ;)
[09:07] <AnAnt> mac_v: ok, but why does the deb package depend on -dev packages ?
[09:07] <AnAnt> depend or recommend
[09:08] <mac_v> AnAnt: hmm odd, it doesnt show the -dev packages as depends for me
[09:09] <AnAnt> attempting to install gnome-shell says that it will install a number of -dev packages
[09:19] <tseliot> pitti: please keep me informed about your progress with the udev rules for synaptics as a patch of mine in synaptics makes use of 11-x11-synaptics.fdi for setting quirks
[09:19] <pitti> tseliot: I was going to transform the existing quirks to udev rules, too
[09:21] <tseliot> pitti: great, I would like to see the that file when it's ready
[09:22]  * tseliot is glad that we won't have to deal with corrupted fdi cache any more :-)
[09:34] <mac_v> mpt: hi.. is there a blueprint for the -symbolic icons?
[09:36] <mpt> mac_v, not as far as I know. If you like, you could register one with me as drafter, kwwii as assignee, and ivanka as approver
[09:37]  * mac_v scratches head... needs to figure out how to draft a blueprint ;p
[09:41] <mac_v> mpt: its a blueprint in xdg naming specs or...?
[09:42] <seb128> good morning there
[09:42] <pitti> hey seb128
[09:42] <didrocks> pitti: my girlfriend has a wacom tablet, so she can test it too if you ping me.
[09:42] <didrocks> hey seb128
[09:42] <seb128> hey pitti didrocks
[09:42] <mac_v> mpt: yay... no work for me ... there is already one , >https://blueprints.launchpad.net/icon-naming-spec/+spec/extra-icon-namespace
[09:42]  * seb128 overslept
[09:43] <pitti> seb128: jet lag FTW?
[09:43] <seb128> sort of, I had no issue going to sleep
[09:43] <seb128> but I wanted to finish syncs and it took me ages
[09:44] <seb128> so I went to bed quite late and sleep through ;-)
[09:44] <mpt> mac_v, cool, thanks
[09:45] <didrocks> seb128: take care of having some good rest before the week-end this week :)
[09:45] <seb128> lol
[09:47] <mpt> good morning glatzor
[09:49] <glatzor> morning mpt!
[09:49] <cviorel> hi everybody!
[09:49] <glatzor> sorry for saying good bye to you personally, but I haven't seen you on friday
[09:49] <cviorel> I keep receiving this message during boot up: One or more of the mounts listed in /etc/fstab cannot yet be mounted:
[09:50] <cviorel> on did not find a good solution on ubuntu forums
[09:53] <mvo> hey glatzor
[09:55] <glatzor> morning mvo
[09:56] <glatzor> mvo, the sessioninstaller is nearly complete. I am currently adding the ability to install PackageKit catalogs
[09:56] <mvo> glatzor: woah, sweet
[09:56]  * mvo hugs glatzor
[09:57] <mvo> glatzor: just give me a shout when its ready and I will package/upload
[09:57] <glatzor> mvo, it isn't any rocket science. just providing simple dialogs and some basic python-apt stuff :)
[09:57] <mvo> glatzor: its still sweet :)
[09:58] <mvo> and useful, great to have
[09:59]  * glatzor is away peeling potatoes
[10:21] <pitti> bryce, tseliot: I think I figured it out; I'll mail you (and julien)
[10:21] <tseliot> pitti: great, thanks
[10:21] <bryce> nice
[10:21] <bryce> I've got the touchscreen spec mostly drafted -- https://wiki.ubuntu.com/X/Blueprints/Touchscreen
[10:22] <bryce> tseliot, btw, I also drafted up the proprietary driver spec, but you may want to review that
[10:22] <tseliot> bryce: sure, I was about to ask you about that one
[10:24] <bryce> tseliot, sure shoot
[10:25] <tseliot> bryce: I wanted to know who would deal with that wiki page as per pitti's email. You've already given me an answer ;)
[10:26] <tseliot> bryce: also, we're not going to use alternatives, are we?
[10:27] <bryce> tseliot, isn't that what was decided at UDS?  Was there subsequent discussion to the contrary?
[10:27]  * tseliot would be happy with a clean up and with better documentation of the packages
[10:28] <tseliot> bryce: from what I remember pitti said that weird things can happen with alternatives (not that diversions are any better)
[10:28] <tseliot> so I took that as a no
[10:28] <tseliot> maybe I misunderstood
[10:29] <bryce> tseliot, ahh, I think we addressed that concern - some of your comments resolved his worries
[10:29] <bryce> guess happy pitti smiles didn't transfer through the mike
[10:30] <tseliot> bryce: ah, ok so my promise about the hooks for the nvidia-installer was convincing then :-)
[10:30] <bryce> yep
[10:30] <pitti> hehe
[10:30] <tseliot> very well
[10:30] <pitti> we just make sure that the maintscripts apply enough force to not leave dangling alternatives behind
[10:30] <pitti> usually the user can override the system default
[10:31] <tseliot> pitti: do you mean "override" with update-alternatives?
[10:31] <pitti> tseliot: I don't know alternatives handling very well; I try to stay away from it like the plague :)
[10:31] <tseliot> as the nvidia-installer won't be capable of doing such things
[10:32] <tseliot> pitti: diversions are not fun either, I assure you ;)
[10:32] <tseliot> I'll do my best to come up with something sane this time
[10:33] <tseliot> well, sane is a big word when dealing with this kind of packages...
[10:33] <pitti> tseliot: good luck!
[10:34] <tseliot> thanks, I'll need it ;)
[10:34] <pitti> bryce: so if we really attack xorg halsectomy, I guess I should work on suspend quirks halsectomy, and dropping hal from the few remaining gnome bits :)
[10:35] <bryce> *nod*
[10:35] <tseliot> bryce: the wiki pages look good to me
[10:35] <pitti> bryce: I mailed the udev rules and updated the whiteboard; do you see anything else which needs to be converted for a first test?
[10:35] <bryce> I will try to take a look at getting jcristau's xserver patches packaged tomorrow maybe
[10:35] <tseliot> pitti: would suspend quirks work with udev? This is something I will need for OEM stuff too
[10:36] <pitti> tseliot: they wouldn't go into udev; Victor and I plan to put them into a text file straight into pm-utils
[10:36] <pitti> nothing else uses them
[10:36] <pitti> and udev is not appropriate for this kind of information
[10:36] <pitti> tseliot: Victor wrote a script to convert the fdi into a simple text format
[10:37] <tseliot> pitti: and what is that loads the text file so that the system knows how to suspend?
[10:37] <pitti> tseliot: pm-suspend/pm-hibernate
[10:37] <tseliot> yes, of course
[10:37]  * bryce rotfl's at GOTO's
[10:37] <pitti> so you don't need to worry about them at all any more
[10:37] <pitti> it will "just happen"
[10:38] <tseliot> that's good
[10:38] <pitti> bryce: my initial rule was one big one, but I found that this doesn't work for some reason:
[10:38] <pitti> IMPORT{parent}="ABS", ENV{ABS}=="?*"
[10:38] <pitti> with two separate rules it works
[10:38] <pitti> iz udev bug
[10:38] <bryce> ok
[11:09] <pitti> hey asac
[11:09] <pitti> asac: do you still remember your pm-utils patch "90-nm-proper-wakeup.patch" which adds a --print-reply?
[11:09] <asac> pitti: yes
[11:09] <asac> whats up?
[11:10] <pitti> asac: that's not in upstream yet; did that get forwarded upstream? or was it only a hack?
[11:10] <asac> its definitly a workaround
[11:10] <asac> not sure if it should go upstream
[11:10] <asac> basically without --print-reply the process might exit too early and no message gets send out
[11:11] <asac> afaik the --print-reply workaround was posted to the dbus mailing list
[11:12] <pitti> asac: would you mind posting it to https://bugs.freedesktop.org/enter_bug.cgi?product=pm-utils ? I'd like to commit it to Debian as well, etc.
[11:13] <pitti> but we shouldn't keep such hacks forever without at least having it forwarded
[11:14] <asac> maybe its fixed by now
[11:25] <pitti> asac: oh, it's already in Debian, too, so I'll keep it for now; but the final fate of it would still be interesting
[11:25] <asac> yes
[11:25] <asac> as i said. it was a bug in dbus ... which is known upstream ;)
[11:26] <asac> (to dbus upstream at least)
[12:05] <seb128> hey slomo
[12:05] <slomo> hi seb128 :)
[12:05] <seb128> slomo, do you think you could make the vala build run the testsuite and break on error?
[12:06] <seb128> that's the only diff we have in ubuntu
[12:06] <seb128> we could sync if debian was doing that too ;-)
[12:06] <slomo> seb128: no, the testsuite fails if dbus can't be started... which is the case in some debian buildds :(
[12:06] <seb128> are you sure?
[12:07] <seb128> we didn't get any build issue during the karmic cycle
[12:07] <seb128> though soyuz != debian buildds
[12:07] <slomo> the ubuntu buildds are much more easy to handle than debian's :)
[12:07] <slomo> you even have writable home directories ;)
[12:07] <seb128> ok
[12:07] <seb128> shame
[12:07] <seb128> pitti, ^ any opinion?
[12:08] <seb128> having to merge this one every time is annoying
[12:08] <seb128> but making the build fail on testsuite errors was a mir requirement by security team
[12:08] <seb128> I guess I should talk to kees again about this one...
[12:08] <slomo> seb128: i could add something to debian/rules to only make the testsuite fatal on ubuntu
[12:08] <seb128> slomo, that would be nice of you ;-)
[12:09] <pitti> seb128: right, would be nice to have the test suite working
[12:10] <pitti> ubuntu buildds have problems with d-bus too, though
[12:10] <slomo> now i only need to wait until git.debian.org works again ;)
[12:10] <pitti> slomo: hm, I have pushed several bits in the last hour
[12:10] <seb128> pitti, do you know if we have a meeting today btw?
[12:11] <pitti> seb128: I guess we do
[12:11] <seb128> ok, thanks
[12:11] <seb128> 17:30 local right?
[12:11] <pitti> rightg
[12:11] <seb128> cool
[12:13] <slomo> pitti: works now :)
[12:13] <slomo> seb128: you can sync 0.7.8-2 from debian/unstable later
[12:14] <seb128> slomo, thanks!
[12:14] <slomo> btw, who's responsible for pulseaudio in ubuntu? :)
[12:17] <baptistemm> hello
[12:18] <seb128> slomo, TheMuso and dtchen
[12:21] <slomo> dtchen: are you going to enable flat volumes again for next release?
[12:22] <slomo> seb128: uploaded :)
[12:23] <slomo> seb128: btw, the dbus tests didn't work in my pbuilder chroot ;)
[12:23] <seb128> slomo, rock on, thanks again!
[12:24] <seb128> slomo, do you think flat volumes are a good idea?
[12:24] <seb128> we got many bugs from confused users while it was on
[12:25] <slomo> seb128: definitely a good idea, yes. and those bugs should all be fixed now, at least in every gnome/gstreamer application (it's a bit sad that nobody forwarded the gstreamer related bugs upstream though)
[12:26] <pitti> what does flat-volumes do?
[12:26] <seb128> pitti, I think it makes channels volume move in a sync way
[12:26] <seb128> ie when you change volume you change master and pcm together
[12:27] <slomo> pitti: http://0pointer.de/blog/projects/oh-nine-fifteen.html  first part
[12:32] <seb128> slomo, well there is still some users or card having saturation issues
[12:32] <seb128> which is probably driver or hardware issue but when you force all channels to act in a sync way you remove the ability to workaround those easily
[12:58] <seb128> ok, I'm away for debugging my uncle computer
[12:58] <seb128> I'm not far so feel free to call if something is needed, otherwise I should be back in 1 or 2 hours...
[13:27] <pitti> did anyone actually see "[pitti away: lunch]" and "[pitti back: gone 00:39:00]"? I hope these are just local messages from my IRC client (got a major update yesterday) and they don't get echoed to the channel
[13:27] <chrisccoulson> good afternoon everyone
[13:29] <pitti> hey chrisccoulson
[13:29] <chrisccoulson> hey pitti, how are you today?
[13:29] <pitti> I'm great, how about you?
[13:30] <chrisccoulson> yeah, i got quite a good night sleep last night, and enjoying my 2 weeks off work too :)
[14:08] <Laney> pitti: no, no sign
[14:09] <pitti> Laney: thanks
[15:08] <rickspencer3> jcastro good morning
[15:18] <pitti> dtchen: can you hop into #ubuntu-meeting?
[15:51] <tgpraveen221> can anyone tell me in how many hours the desktop team meeting starts
[16:02] <kenvandine> tgpraveen221, it was canceled for today
[16:04] <seb128> re!
[16:04] <seb128> so karmic 0 - win xp 2, grrrrr
[16:07] <seb128> trying to install karmic on my uncle box is a fail
[16:07] <ccheney`> seb128: what kind of problem?
[16:09] <seb128> the first install ubiquity crashed
[16:10] <seb128> there was a ntfs partition change dunno if that was due to it
[16:10] <seb128> after running it again it was saying that no OS was installed
[16:10] <seb128> it scared me for a moment I though it destroyed the win install
[16:10] <ccheney`> oh :-(
[16:10] <seb128> after reboot install worked correctly
[16:10] <seb128> the first did the disk changes after all and working...
[16:11] <seb128> but after reboot no grub
[16:11] <ccheney`> oh, weird
[16:11] <seb128> so there is a karmic installed and no way to boot it now
[16:11] <seb128> I decided I spent enough time on that today
[16:11] <seb128> will go back an another day
[16:11] <ccheney`> ok
[16:11] <ccheney`> did it have no grub but booted properly back into xp immediately?
[16:11] <seb128> yes
[16:12] <ccheney`> ok
[16:12] <seb128> known issue?
[16:12] <ccheney`> i don't know, sounds like it either didn't install or somehow installed to the linux partition instead of the mbr (if that is possible)
[16:12] <seb128> there is 2 disks in the box
[16:13] <seb128> karmic was installed on the second one
[16:13] <ccheney`> oh ok, or a 3rd option it installed to the mbr of the second disk
[16:14] <ccheney`> i haven't ever tried installing to a second hard drive before, so not sure what it tries to do in that case
[16:16] <pitti> I think I did once
[16:17] <pitti> and back then there was some confusion about which MBR it installs to
[16:19] <pitti> seb128: next time you are at your uncle, have a look into the bios; all halfway recent BIOSes should allow you to select the hard disk order on boot
[16:19] <seb128> pitti, ok thanks
[16:20] <pitti> in the best case, the installer picked up the win partition and added it to grub
[16:20] <seb128> otherwise is there a way to just re-do grub install?
[16:20] <pitti> and all you have to do is to try booting from the second hda first
[16:20] <pitti> with grub 1 there was "grub-install /dev/sda"
[16:21] <pitti> and according to --help it should still work for grub 2
[16:21] <pitti> but I never used it with grub 2 manually
[16:21] <seb128> other story is that new ipod + ubuntu = fail ...
[16:21] <seb128> not ubuntu specific
[16:22] <seb128> but neither the ipod nano 5g nor the itouch works
[16:22] <seb128> db changes and libgpod need changes, upstream is on it though
[16:22] <seb128> and I can't get the touch to connect to wifi
[16:23] <seb128> apple = fail
[16:23] <pitti> rickspencer3: did you send the "team meeting cancelled" to everyone or just me?
[16:23] <seb128> pitti, ok, thanks
[16:23] <seb128> oh
[16:23] <rickspencer3> pitti, I sent it to the list
[16:23] <seb128> no team meeting?
[16:23] <rickspencer3> canonical-desktop-team
[16:23] <seb128> hum
[16:23] <pitti> rickspencer3: I only see me in To:
[16:23] <seb128> I need to filter those out somewhere
[16:24] <seb128> there land in middle of thousand of launchpad bug emails
[16:24] <pitti> rickspencer3: ah, through LP magic?
[16:24] <rickspencer3> yes
[16:24] <seb128> launchpad = noise so far for me
[16:24] <pitti> weird
[16:24] <rickspencer3> and then seb128 filters it out
[16:24] <rickspencer3> :)
[16:24] <pitti> seb128: for me it's "To: Martin Pitt <martin.pitt@ubuntu.com>", and no X-LP-Bugs: stuff
[16:24] <seb128> I'm wondering if I should have 2 lp account
[16:24] <seb128> one for "work" and one for bug spam
[16:25] <rickspencer3> I could just recreate the list locally, but I forgot to back up my lists on evo last time I reinstalled, and the lp page is right there and so easy
[16:25]  * pitti gently points seb128 to https://wiki.ubuntu.com/Bugs/HowToFilter
[16:26] <seb128> pitti, I've filters thanks, I just need a new one for this case
[16:26] <pitti> rickspencer3: I added tseliot to that team
[16:26] <seb128> I'm already putting assigned bugs, etc on the side
[16:27] <rickspencer3> pitti, ok
[16:27] <rickspencer3> looks like the rotations starts officially Nov 30th
[16:27]  * rickspencer3 just got mail
[16:27] <tseliot> right
[16:27] <tseliot> I got that email too
[16:27] <bryce> morning
[16:28] <pitti> hey bryce
[16:31] <seb128> urg, "finish merges"
[16:32] <seb128> is that a "continue merges" or are those supposed to be done now?
[16:32]  * seb128 still has tons of those to do
[16:32]  * rickspencer3 whip cracking noises
[16:32] <pitti> seb128: there's no immediate deadline for it
[16:33] <pitti> seb128: it was just a gentle reminder "those still exist, too" :)
[16:33] <pitti> but this week, drafting blueprints has higher urgency
[16:35] <seb128> the after sprint+uds stack of tasks is exiting and depressing... ;-)
[16:36] <pitti> I hope that was meant to mean "exciting" :)
[16:36]  * pitti hugs seb128
[16:36]  * seb128 hugs pitti
[16:37] <seb128> not sure, add this to the burn-out chart ;-)
[16:37] <pitti> lol
[16:37] <bryce> seb128, agreed
[16:39]  * seb128 kicks launchpad
[16:39] <seb128> stop sending me a zillion email each time somebody runs apport-collect
[16:39] <seb128> 21 emails by run
[16:40] <seb128> it's ridiculous...
[16:40] <pitti> rickspencer3: ^ how many "whip crack noises" should we account for every assignee on the burn-out chart?
[16:40] <seb128> pitti, could be tar.gz those on client side...?
[16:40] <rickspencer3> hehe
[16:40] <pitti> seb128: in theory yes, but that woudl make them even less convenient to look at?
[16:40] <seb128> I guess it will make people complain about that making thoses harder to review though
[16:41]  * pitti wants those condensed in one mail
[16:41] <pitti> but fortunately there is a "delete thread" key in mutt
[16:41]  * seb128 too
[16:42] <seb128> well, I don't want to delete the thread
[16:42] <seb128> I use my bugboxes archive to find bugs
[16:42] <seb128> quicker than using web search
[16:44] <bryce> pitti, it would be lovely if the apport-collect emails had some text or tag we could make procmail rules for to exclude them...
[16:44] <bryce> although I admit I've pretty much given up on my bug inbox
[16:45] <bryce> hmm, no meeting today? or did daylight savings get me again?
[16:45] <pitti> -        bug.addAttachment(comment='',
[16:45] <pitti> +        bug.addAttachment(comment='apport-collect data',
[16:45] <pitti> bryce: ^ like so?
[16:46] <pitti> bryce: meeting was cancelled, see Rick's recent mail
[16:46] <bryce> pitti, yeah
[16:47] <pitti> bryce: it's not a mail subject, though
[16:47] <pitti> so you have to filter on the body
[16:47] <pitti> addAttachment() doesn't have a subject field
[16:47] <bryce> pitti, yeah that would be better but body filtering is doable
[16:48] <bryce> erf, wish I'd known the meeting was canceled, I'd have not gotten up early ;-)
[16:48] <pitti> bryce: committed
[16:48] <bryce> sweet
[16:49] <bryce> seb128, ^^ there you go
[16:50] <bryce> # Notifications of apport data collection
[16:50] <bryce> :0 B:
[16:50] <bryce> * ^apport-collect data$
[16:50] <bryce> launchpad.apport
[16:50] <bryce> haven't tested it, but think that's the right procmail rule for this
[16:51] <pitti> hm, I guess what you really want is to get the first one in your regular bug mailbox
[16:51] <pitti> and all others to /dev/null
[16:51] <pitti> so perhaps the first one should have a different comment?
[16:51] <bryce> yeah
[16:52] <pitti> at least I want to know that people added new info
[16:52] <pitti> oh, hang on
[16:52] <pitti>     print'   short text data...'
[16:52] <pitti>     bug.newMessage(content=part.get_payload(decode=True),
[16:52] <pitti>         subject='apport-collect data')
[16:53] <pitti> that would be it
[16:53] <pitti> you can just look for "Subject: apport-collect data" and route that to your regular bug mailbox
[16:53] <pitti> (already there, in karmic)
[16:53] <pitti> and change above rule to /dev/null
[16:54] <pitti> just don't overdo it, otherwise you'll get "/dev/null: No space left on device" :)
[16:56] <bryce> pitti, I got one of those usb dongles that expands your /dev/null space
[16:57] <pitti> I saw those next to the subspace radio transmitters at Fry's, but they were sold out
[16:57] <bryce> they're quite handy - when it fills I just throw it in the trash and buy a new one
[16:58] <kenvandine> pitti, does your workitems script scrape all blueprints for lucid or specific ones related to desktop?
[16:58] <pitti> kenvandine: lucid-targetted ones which match the pattern desktop-lucid-*
[16:59] <pitti> (the pattern is configurable, of course)
[16:59] <kenvandine> ok, should we add dx and ubuntuone?
[16:59] <kenvandine> the plan is to have workitems in those blueprints for tasks that affect the desktop team
[16:59] <pitti> should they appear on the desktop team's chart, or get their own reports/
[16:59] <pitti> ?
[16:59] <kenvandine> i think our chart
[17:00] <kenvandine> but might be cool to have separate reports
[17:00] <kenvandine> so we can track each team seperately
[17:00] <kenvandine> and aggregate that into a toplevel burndown
[17:00] <pitti> I think so, too
[17:00] <seb128> kenvandine, I did a list of dxteam tasks already
[17:01] <kenvandine> as work items?
[17:01] <seb128> kenvandine, based on the sprint week, I emailed it to pitti and rickspencer3
[17:01] <seb128> yes
[17:01] <kenvandine> dbarth said he would have all their work items in by end of next week
[17:01] <rickspencer3> kenvandine, yes, but we have some work items as well
[17:01] <seb128> well, that was sort of why I intended the sprint
[17:01] <seb128> oh
[17:02] <seb128> my list is desktop team side
[17:02] <seb128> no dxteam side
[17:02] <kenvandine> right
[17:02] <kenvandine> we want to track dxteam and u1 for tasks that will affect the desktop
[17:02] <seb128> ie "get new packages in lucid, patches nn softwares for indicators changes, etc"
[17:02] <kenvandine> even if they are doing the work
[17:02] <seb128> ok
[17:02] <seb128> I didn't do that
[17:05] <jtholmes> anyone know of a double layer or blue ray dvd that will work well with 9.10
[17:19] <seb128> pitti, good to see new uploader approvals but when will those be effective?
[17:19] <pitti> seb128: for these three they are already
[17:20] <seb128> and ubuntu-desktop?
[17:20] <pitti> I still don't know how to set those
[17:20] <seb128> not that having Amaranth uploading compiz is not great
[17:21] <seb128> but I want chrisccoulson and didrocks uploads
[17:21] <seb128> that would reduce our sponsoring load a lot
[17:21] <seb128> ok
[17:21] <seb128> is somebody else going to look at those?
[17:21] <pitti> $ ./edit_acl.py -p ubuntu-desktop query
[17:21] <pitti> == All rights for ubuntu-desktop ==
[17:21] <pitti> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in karmic
[17:21] <pitti> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in lucid
[17:21] <pitti> seb128: cjwatson is
[17:22] <pitti> but I wonder if above output doesn't mean that it already works
[17:22] <pitti> someone could try?
[17:22] <seb128> oh, maybe it works
[17:22] <seb128> same
[17:22] <seb128> chrisccoulson, didrocks: ^
[17:22] <seb128> pitti, thanks
[17:23] <pitti> mythbuntu-dev and kubuntu-dev are displayed to work, too
[17:23] <pitti> kenvandine: so if you have something to upload, please try
[17:24] <kenvandine> i don't at the moment
[17:24] <pitti> same result for "./edit_acl.py -p ken-vandine query"
[17:24] <pitti> so, upload away :)
[17:24] <kenvandine> :)
[17:24] <kenvandine> upload with dput? or is there some magic tool?
[17:25] <pitti> kenvandine: just like into ppas, just not with "dput ppa" :)
[17:25] <kenvandine> ok
[17:25] <kenvandine> cool
[17:25]  * pitti pulls desktop bzr trees to see whether there's something UNRELEASED
[17:25] <seb128> there is ton of updates and merges to do
[17:25] <pitti> rickspencer3: you know that this means that you now have unrestricted GNOME upload rights :)
[17:25] <seb128> easy to pick one ;-)
[17:26] <pitti> rock'n'roll
[17:26] <rickspencer3> chouette
[17:26]  * rickspencer3 uploads lolz
[17:27] <chrisccoulson> seb128 / pitti - thanks
[17:27] <seb128> pitti, we need to be careful, GNOME might be switched to quickly over night
[17:27] <chrisccoulson> i need to start doing 2.29 merges soon :)
[17:27] <seb128> chrisccoulson, ;-)
[17:27] <seb128> chrisccoulson, how are you and your family doing?
[17:27] <seb128> the mother and baby are back already?
[17:28] <chrisccoulson> seb128 - good thanks. we had our first trip together to the supermarket today
[17:28] <chrisccoulson> which was quite a lot of hassle!
[17:28] <seb128> nice ;-)
[17:28] <kenvandine> hehe
[17:28] <kenvandine> chrisccoulson, i remember that
[17:28] <seb128> so now you can say goodbye to sleep
[17:29] <chrisccoulson> seb128 - yeah, i think i said goodbye to that quite a while ago ;)
[17:29] <seb128> hehehe
[17:29] <chrisccoulson> i'm sleeping occasionally in the daytime at the moment, when the baby sleeps
[17:29] <chrisccoulson> but i can't really get used to that!
[17:31] <bryce> chrisccoulson, congrats!
[17:32] <chrisccoulson> bryce - thanks:)
[17:32] <pitti> wow, asac is fast -- http://piware.de/workitems/mobile/lucid/report.html
[17:32] <bryce> chrisccoulson, boy or girl?
[17:32] <chrisccoulson> bryce - girl, 8lb 1oz
[17:33] <seb128> you guys should really use metric systems ;-)
[17:33] <bryce> chrisccoulson, nice :-)
[17:33] <chrisccoulson> heh, i'm too used to imperial ;)
[17:34] <bryce> seb128, 0.123 m^3
[17:34]  * seb128 sights
[17:34] <chrisccoulson> seb128 - she weighs 3.656 kg ;)
[17:35] <seb128> I was just looking for an online converter
[17:35] <seb128> that speaks to me now, thanks ;-)
[17:35] <pitti> http://www.google.com/search?q=8lb+1oz+in+kg
[17:35] <chrisccoulson> i didn't know how much she was in kg until i just worked it out there
[17:35] <chrisccoulson> that means she is lighter than our cat!
[17:35] <bryce> chrisccoulson, last night our 3 mo old boy slept from 10pm to 7am, after eating 6oz (~180ml).  A record!
[17:36] <chrisccoulson> bryce - i bet you're quite pleased about that!
[17:36] <bryce> my son was 6lb 8oz at birth, a little guy.  But he picked up weight and is almost 11lb now
[17:36] <bryce> chrisccoulson, well I wear ear plugs, so...  ;-)
[17:36] <bryce> mama was happy tho!
[17:37] <chrisccoulson> our girl feeds for about an hour, then we change her nappy and try and put her to bed, but she screams the house down and the whole cycle starts again ;)
[17:37] <chrisccoulson> then she sleeps from about 7am
[17:37] <chrisccoulson> although, she slept for 2 hours last night
[17:37] <bryce> chrisccoulson, yeah good burping is the key
[17:38] <bryce> chrisccoulson, for us, wrapping him up tightly in a blanket helped a lot to get him to rest
[17:38] <bryce> hmm, probably we need #ubuntu-babies ;-)
[17:39] <chrisccoulson> heh, we might try that, but she was already quite hot last night
[17:39] <bryce> ok back to bug mail
[17:39] <chrisccoulson> i should probably turn our heating system down a little
[17:39] <bryce> chrisccoulson, http://www.thehappiestbaby.com/
[17:40] <chrisccoulson> thanks, i'll have a look at that later ;)
[18:24]  * dobey needs a superior python hacker's brain to pick
[18:26] <and471> mvo : hello
[18:27] <and471> mac_v :hi there
[18:37] <dobey> kenvandine: ping
[18:37] <seb128> hum
[18:37] <dobey> hi seb128
[18:37] <seb128> seahorse agent seems to not be used in lucid
[18:37] <seb128> hey dobey, had a good trip back?
[18:37] <dobey> yeah. no delays or anything :)
[18:38] <kenvandine> dobey, hey
[18:38] <dobey> and i upgraded the second leg of my flight to first class :)
[18:38] <kenvandine> nice
[18:38] <dobey> and gave the guy next to me a karmic cd
[18:39] <dobey> kenvandine: hey, since i know you're in my timezone... can you teach me how to get a debdiff between two revisions of a package?
[18:39] <seb128> debdiff old.dsc new.dsc
[18:40] <dobey> ah
[18:40] <dobey> cool beans
[18:40] <kenvandine> what seb128 said :)
[18:40] <dobey> also
[18:40] <dobey> does my last comment in bug 487710 make sense to you guys?
[18:42] <kenvandine> dobey, if it depends on it to run
[18:42] <kenvandine> it should be a depends imho
[18:42] <kenvandine> which might not be great for other desktop environments
[18:42] <kenvandine> i would rather have u1-client drag in a bunch of deps and function than blow up
[18:43] <dobey> kenvandine: well i'd raher fix the dependencies properly. we depend on the library, which depends on the daemon, so the library dependency seems wrong to me
[18:43] <kenvandine> maybe
[18:44] <kenvandine> is there ever a case where the library is used without a daemon?
[18:44] <dobey> i don't think so
[18:44] <dobey> the library is basically just wrapping the protocol
[18:45] <kenvandine> i would think so
[18:46] <seb128> dobey, could the code just say "no gnome-keyring fallback to other method"?
[18:46] <pitti> rickspencer3: work item stuff set up, wikified, and announced; please let me know if something still doesn't work for you
[18:47] <dobey> seb128: for lucid we're going to move to python-keyring which abstracts the keyring stuff out, and works with gnome-keyring, kwallet, osx, and win, and a couple other storage formats
[18:47] <rickspencer3> pitti, ok .. but I can't promise I'll get to it today... might have to wait until Monday
[18:47] <pitti> rickspencer3: sure, no hurry
[18:47] <rickspencer3> pitti, is there something specific that it would help if I looked at it today?
[18:47] <pitti> rickspencer3: no, just making sure that I covered everything you need
[18:47] <seb128> dobey, what I'm saying is that you might have case for libgnome-keyring being used and no gnome-keyring running
[18:47] <dobey> seb128: so i'm not sure how we'll express that exactly in the packaging, but looking at the deps in karmic, they seem wrong anyway
[18:47] <rickspencer3> thanks pitti
[18:48] <seb128> if you can check for that a runtime
[18:48]  * rickspencer3 is typing as fast as possible
[18:48] <pitti> rickspencer3: we have by-milestone tracking, assignees, and documentation how to move WIs into different phases on the whiteboard
[18:48] <rickspencer3> schweet
[18:48] <dobey> seb128: yes, but that gives a different error, and really, it should be getting activated by dbus
[18:48] <rickspencer3> pitti, as usual, you did an awesome job ... thanks
[18:48] <rickspencer3> (I can confidently say without even looking ;) )
[18:49] <kenvandine> dobey, but you  can see that it fails to fire with dbus and handle that exception
[18:49] <kenvandine> not sure what the fallback should be
[18:50] <dobey> the fallback would be "fail"
[18:50] <dobey> and that is much less of a concern to me right now :)
[19:02] <pitti> rickspencer3: eww, pitivi needs hal, too? *sigh*
[19:02] <rickspencer3> oh?
[19:03] <rickspencer3> to detect video cameras?
[19:03] <pitti> presumably
[19:03]  * rickspencer3 notes that pitti has it out for pitivi
[19:03] <pitti> just responded to the bug :)
[19:03] <rickspencer3> I think we should *not* deliver anything new that relies on hal
[19:04] <rickspencer3> like, isn't that exactly the opposite direction we are trying to go?
[19:05]  * pitti -> dinner
[19:05] <pitti> rickspencer3: right
[19:06] <pitti> rickspencer3: well, we can change hal to start on demand instead of on boot
[19:06] <kenvandine> i bet we can get that fixed
[19:06] <pitti> that will take out most concerns
[19:06] <rickspencer3> hmm
[19:06] <pitti> but I suppose it should be easy to port it
[19:06] <rickspencer3> right, but I think if distros are moving away from HAL, now is probably a good time to get pitivi fixed anyway
[19:07] <rickspencer3> pitti, can you please just rewrite the code real quick before you go for dinner?
[19:07] <rickspencer3> j/k
[19:07] <rickspencer3> I need a break, that wasn;t even funny
[19:07]  * rickspencer3 goes to get some lunch
[19:12] <seb128> re
[19:12] <seb128> dobey, did you get my comment before?
[19:13] <seb128> dobey, in any case python-gnomekeyring should at least use a Recommends
[19:15] <dobey> i guess i didn't get your comment, no
[19:16] <dobey> but i don't think it's at all useful without gnome-keyring installed
[19:16] <dobey> as i understand it, uninstalling something from a Suggests/Recommends should in no way break the thing that lists that dependency
[19:25] <seb128> " which would make gnome-keyring installed by default
[19:25] <seb128>  not sure between Depends or Recommends
[19:25] <seb128>  ie I'm not sure if some software might use gnome-keyring but fallback if it's not running in which case the user might be able to stop the daemon..."
[19:25] <seb128> " which would make gnome-keyring installed by default
[19:25] <seb128>  not sure between Depends or Recommends
[19:25] <seb128>  ie I'm not sure if some software might use gnome-keyring but fallback if it's not running in which case the user might be able to stop the daemon..."
[19:25] <seb128> dobey, ^
[19:27] <dobey> seb128: well, i'm not sure what cases do a fallback AND require that libgnome-keyring0 be installed and used, though
[19:27] <seb128> well has libgnome-keyring an api to know if gnome-keyring is running?
[19:27] <seb128> libtracker for example doesn't require tracker to run
[19:28] <seb128> it's up to application to be smart about the service running or not
[19:28] <seb128> in which case a Recommends = install by default but let user able to opt out is correct
[19:29] <dobey> if the application itself has to do extra things to handle that, the API is wrong, or the developer doesn't want to depend on the keyring, and is doing something else anyway if the library isn't there
[19:30] <dobey> tracker isn't a vital system service (yet)
[19:30] <dobey> gnome-keyring is
[19:30] <seb128> you can't uninstall a library you built again
[19:30] <seb128> ld will be really unhappy and you software will not run...
[19:30] <seb128> I agree that in 99% of cases you want gnome-keyring running
[19:31] <seb128> I've seen subversion has a counter example today though
[19:31] <seb128> they have code using gnome-keyring or fallbacking to text storage otherwise
[19:31] <seb128> Recommends should be enough it will install it by default
[19:31] <dobey> hrmm?
[19:31] <seb128> which mean only user who decide to remove gnome-keyring can complain
[19:32] <seb128> and that would be their fault
[19:32] <dobey> if you want to depend on the keyring NOT being available, then you need to dlopen() the library, and fall back gracefully
[19:32] <dobey> which is what python does
[19:32] <dobey> well it's already installed by default
[19:32] <seb128> no
[19:32] <seb128> it's installed by default on ubuntu
[19:33] <dobey> it's installed by default if you install python-ubuntuone-client
[19:33] <seb128> but having a recommends would mean that anybody installing python-gnomekeyring would get gnome-keyring
[19:33] <dobey> because it depends on python-gnomekeyring, which depends on libgnome-keyring0, which recommends gnome-keyring
[19:33] <seb128> ok
[19:33] <seb128> so your bug is notabug
[19:33] <dobey> or do recommends only get handled for the requested package?
[19:33] <seb128> if somebody decide to remove recommends it's their fault
[19:34] <seb128> to be honest I've no strong opinion
[19:34] <seb128> we can add a strong depends in lucid
[19:34] <seb128> and wait to see who complains
[19:34] <bryce> pitti, btw desktop-lucid-xorg-driver-selection-for-nvidia-hardware needs added to our list of stuff to do for lucid
[19:35] <bryce> pitti, it's a deferred blueprint from karmic, but came out as a requirement from the KMS session
[19:44] <dobey> seb128: ok. i'll look into it
[19:53] <kenvandine> seb128, the gnome-keyring issue with python-ubuntuone-client isn't really a problem for ubuntu-desktop, but kubuntu and others that don't include gnome-keyring by default
[19:53] <kenvandine> so having the depends would ensure it works
[19:58] <seb128> kenvandine, right, still trying to figure if the lib should depends or recommends the server though
[19:58] <kenvandine> ok
[19:58] <seb128> ie there is a case for libgnome-keyring being used but optional
[19:59] <seb128> like if (keyring_running) use it; or use other method to store...
[19:59] <pitti> rickspencer3: heh; well, I suppose it's some two hours of work to port it
[19:59] <pitti> bryce: did you really mean to assign that one to me?
[19:59] <seb128> oh, we can assign specs to pitti? ;-)
[20:00] <pitti> seb128: technically yes, I just don't think it will help much, given my existing workload :)
[20:00] <bryce> pitti, oops
[20:00] <seb128> pitti, no fun if that doesn't me you are going to fix those
[20:00] <bryce> pitti, I only read the first letter of words apparently
[20:01] <seb128> pitti, I was going to assign you the "make gnome boot in 0.3 seconds" spec now ;-)
[20:01]  * seb128 hugs pitti
[20:01] <pitti> seb128: sure, I'll make it 0.1 seconds, and add a sleep 0.2
[20:01] <seb128> anyway enough trolling, time for dinner
[20:01] <pitti> seb128: enjoy!
[20:01] <seb128> thanks
[20:01] <pitti> bryce: ah, approver?
[20:01] <seb128> bbl
[20:01] <bryce> pitti, ahh I see the problem - on the blueprint view page it lists Approver / Drafter / Assignee.  When you click edit, the edit page lists them in the reverse order Assignee / Drafter / Approver
[20:01] <pitti> usability bug! papercut!
[20:02] <bryce> those insidious launchpad guys strike again
[20:03] <bryce> heh, if only anyone would look at blueprint bug reports
[20:03] <bryce> pitti, anyway fixed
[20:04] <bryce> pitti, I don't know if we have a blueprint for tracking the boot performance stuff but I updated the status for work items at https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/Lucid/X
[20:05] <pitti> bryce: we'll use the wiki page from foundations, yes
[20:05] <pitti> it already has desktop bits
[20:16] <didrocks> seb128: I've uploaded the vino merge. Let's see if I will be striken by thunder... hum no... denied permission :)
[20:22]  * pitti crosses fingers
[20:22] <didrocks> kicked off :(
[20:22] <pitti> rejected?
[20:22] <didrocks> yeah
[20:23] <pitti> "kick off" == "start", doesn't it?
[20:23] <didrocks> hum, I used this word the wrong way so
[20:23] <didrocks> "Signer is not permitted to upload to the component 'main'."
[20:23] <pitti> meh
[20:24] <didrocks> I should run for core dev someday. It will be easier…
[20:24] <pitti> but this is supposed to work
[20:25] <didrocks> is vino seeded in the desktop track?
[20:25] <pitti> $ ./edit_acl.py -p didrocks query
[20:25] <pitti> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in karmic
[20:25] <pitti> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in lucid
[20:26] <pitti> didrocks: it certainly should, but I don't know how to check
[20:27] <bryce> haha we can replace gimp with `firefox http://pixlr.com/editor/` ;-) ;-)
[20:27] <pitti> == All uploaders for package 'vino' ==
[20:27] <pitti> Archive Upload Rights for ubuntu-core-dev: package set 'ubuntu-desktop' in karmic
[20:27] <pitti> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in karmic
[20:27] <pitti> didrocks: in theeeeeeory it should work
[20:28] <pitti> didrocks: mind forwarding the reject to cjwatson and ask about it?
[20:29] <didrocks> pitti: no pb, doing it now
[20:30] <bryce> hmm actually that works pretty good for redeye removal
[20:32] <didrocks> pitti: sent, let's wait :)
[20:33] <didrocks> I've pushed the bzr branch during this time
[20:44] <pitti> didrocks: colin is on holiday this week
[20:44] <seb128> bryce, f-spot does that too now
[20:45] <seb128> pitti, he was around today so he might reply when passing by
[20:45] <seb128> pitti, no hurry anyway
[20:46] <didrocks> we'll see…
[20:47] <seb128> didrocks, you bother doing ... in utf now? ;-)
[20:48] <didrocks> seb128: always when I'm on my GNU/Linux computers (ie not at work ;))
[20:48] <didrocks> seb128: only huats is always using « ... » :)
[20:48] <seb128> how do you do it?
[20:49] <didrocks> seb128: with the default French keyboard: Shift + Altgr + ,
[20:50] <seb128> doesn't work there...
[20:51] <didrocks> seb128: which keyboard setup do you have?
[20:51] <didrocks> « France Autre » ?
[20:53] <seb128> didrocks, ok works now
[20:54] <seb128> I had France without autre
[20:54] <didrocks> oh, ok :)
[20:54] <bryce> seb128, does f-spot have the 'pinch' functionality?
[20:54] <didrocks> you can also use AltGr + W and AltGr + X to get true « » :)
[20:56] <seb128> bryce, what pinch does?
[20:59] <bryce> seb128, hard to explain... "double-chin remover" is maybe a better description ;-)
[20:59] <seb128> ok, I guess f-spot doesn't have that
[21:01] <seb128> it has those: crop; red-eyes reduction; desaturation; sepia tone; straighten; soft focus; auto color; adjust colors
[21:03] <mannyv> seb128, the tomboy merge FTBFS
[21:03] <seb128> I've noticed
[21:03] <seb128> I'm doing the 1.1.0 update now
[21:03] <seb128> I will have a look to that too
[21:04] <mannyv> i ran interdif on the patch i submitted and the one on launchpad
[21:04] <mannyv> i think part of the patch was missing
[21:04] <mannyv> http://pastebin.com/f1a2d451d
[21:04] <mannyv> there is the interdiff
[21:04] <mannyv> the dirs file got deleted from the patch
[21:05] <mannyv> its all the way at the bottom
[21:05] <seb128> ok
[21:05] <seb128> it's all fixed in bzr already
[21:06] <seb128> I forgot to bzr add the new ones...
[21:06] <seb128> the changelog change is normal
[21:06] <seb128> there is no point to keep tons of old changelog
[21:06] <seb128> doing the summary in the new version is enough
[21:06] <mannyv> ok that is good to know
[21:07] <seb128> mannyv, sorry about that
[21:07] <seb128> mannyv, http://wiki.ubuntu.com/DesktopTeam/Bzr is worth reading too...
[21:07] <seb128> mannyv, http://wiki.ubuntu.com/DesktopTeam/Bzr is worth reading too...
[21:07] <seb128> it has details on how to use bzr for packaging
[21:08] <seb128> it makes easier to merge your changes
[21:09] <mannyv> so on merges  if it is in bzr you want me to merge it that way?
[21:09] <seb128> as you want
[21:10] <seb128> it makes work easier but debdiff works too
[21:10] <mannyv> i had one question about that, it says to commit every change. Does that mean if in the merge i change debian/rules and debian/changelog, and add delete a patch those will be 3 different commits?
[21:10] <seb128> I've no strong opinion on that
[21:10] <seb128> I would tend to say that upgrades or merges are easy enough to be one commit
[21:10] <seb128> then if sponsor has comments you do an another update
[21:11] <seb128> and reviewing the change is just reading that new commit
[21:11] <seb128> which is easier than dealing with debdiffs stacked
[21:11] <mannyv> ok
[21:13] <pitti> good night everyone
[21:14] <seb128> 'night pitti
[21:50] <Amaranth> hmm, compiz upload rights
[21:50]  * Amaranth prepares an 0.9 git snapshot
[21:51]  * Amaranth runs
[22:02]  * TheMuso looks at Amaranth. You have upload privileges, not upload rights. We all earn the privilege to upload to Ubuntu without someone looking over our shoulder. :p
[22:06] <rickspencer3>  robert_ancell TheMuso good morning
[22:07] <rickspencer3> did you get the email to the effect that there's no Eastern Edition today?
[22:07] <robert_ancell> rickspencer3, hey, sure did
[22:25] <seb128> hey robert_ancell
[22:25] <robert_ancell> seb128, hey
[22:26] <seb128> robert_ancell, how are you doing? managed to get over jetlag?
[22:26] <robert_ancell> seb128, hasn't been bad this time :)
[22:26] <seb128> good ;-)
[22:26] <seb128> still no news from eom guys?
[22:27] <robert_ancell> HR says change over on the 30th
[22:27] <seb128> ok, good
[22:27] <seb128> still one week to get desktop work done ;-)
[22:27]  * seb128 points robert_ancell to the topic for updates, etc
[22:28] <robert_ancell> yeah, that's the plan :)
[22:30] <TheMuso> rickspencer3: Yes, thanks.