[00:46] <StevenK> RAOF: O hai! Do you tim to throw some debugging options at me for a DPMS issue I'm having?
[00:46] <StevenK> s/\(tim\)/\1e/
[00:47] <RAOF> I have any number of Tims to throw.  And maybe even a little time :)
[00:47] <RAOF> What's the problem?
[00:48] <StevenK> RAOF: I have "Put display to sleep when inactive for: 0:10" in Power Management, it just ... doesn't
[00:48] <RAOF> Heh.
[00:48] <RAOF> Is something inhibiting the display sleep?
[00:48] <StevenK> I'll come back to the machine after a few hours, and the monitor is still helpfully showing the screensaver
[00:49] <RAOF> Does “xset dpms force off ; sleep 5; xset dpms force on” turn off the monitor for 5 seconds?
[00:50] <StevenK> Nope, it blanks, and then comes right back
[00:50] <StevenK> Although, it seemed to work the second time ...
[00:51] <RAOF> Heh.
[00:52] <RAOF> I'd suspect something higher in the stack than X, generally.
[00:52] <RAOF> Particularly if xset works :)
[07:04] <dholbach> good morning!
[07:53] <didrocks> good morning
[08:02] <pitti> Good morning
[08:03] <pitti> buxy: as ebroder says, we primarily need to install less; compressing .debs more won't help much
[08:53] <pitti> jibel: do you think you can play with the test case in bug 672964, so that someone else than just me tests this? I know that it doesn't help to fix an already broken system, but I'm fairly sure the patch will prevent breaking it in the first place
[09:00] <jibel> pitti, I'm looking at it.
[09:01] <pitti> jibel: merci; not that urgent, though
[09:58] <mvo> jussi: could you please add to the channel topic that I'm "patch-pilot" of the day ? (ref is https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch%20Pilots)
[09:59] <jussi> mvo: this channel is not +t - you are able to do so yourself :=)
[09:59] <jussi> mvo: though I think we will have the bot to help out soon
[10:00] <pitti> mvo: happy piloting!
[10:00] <pitti> "launch clearance granted"
[10:01] <seb128> mvo, oh nice, that's starting today ;-)
[10:01]  * mvo puts his pilot hat on and starts the engine
[10:01] <mvo> jussi: aha, thanks
[10:01] <dholbach> can somebody approve my mail to u-d-a - it's also about the patch pilot programme
[10:01] <dholbach> please :)
[10:01] <pitti> dholbach: will do
[10:02]  * dholbach hugs pitti
[10:02] <pitti> flushed
[10:02]  * pitti hugs dholback
[10:02]  * dholbach will blog it too
[10:02] <dholbach> haha
[10:02]  * dholbach hugs mvo
[10:03] <cjwatson> (I think we can drop the maverick-proposed unfrozen item now)
[10:04]  * mvo nods
[10:06] <bryceh> dholbach, is patch pilot only looking at debdiffs?
[10:07] <dholbach> bryceh, see the mail I just sent to u-d-a
[10:07] <dholbach> I'll give you the link to my blog post in a sec :)
[10:07] <dholbach> hang on
[10:07] <bryceh> dholbach,  I just did
[10:07] <bryceh> dholbach, but I'm unclear
[10:07] <dholbach> http://daniel.holba.ch/blog/?p=820
[10:08] <dholbach> bryceh, http://reports.qa.ubuntu.com/reports/sponsoring/ is a good start
[10:09] <om26er> mvo,  can you sponser this fix https://code.launchpad.net/~om26er/ubuntu/maverick/gwibber/gwibber-fix-674894/+merge/40899
[10:09] <dholbach> bryceh, is your question about "what you're supposed to do" or "which queue to look at"?
[10:10] <bryceh> dholbach, no, my question is, if a bug report has a patch that is not in debdiff form, is it acceptable or unacceptable to subscribe ubuntu-sponsors?
[10:10] <om26er> the fix is taken from gwibber trunk
[10:10] <ogra_ac> didrocks, hrm, you messed up ubuntu-netbook-default-settings
[10:11] <dholbach> bryceh, if you reviewed the patch and it's sound and you want to upload it and it's only a matter of adding a changelog entry, it's great if you just go ahead and do it
[10:11] <didrocks> ogra_ac: well, on armel… that's why I asked you to test it before on an armel build :)
[10:11] <dholbach> what I usually do is say "this is what I did to get it in an uploadable state"
[10:11] <ogra_ac> didrocks, you should also never use DEB_HOST_ARCH, that breaks cross building and makes lool unhappy ;)
[10:11] <jibel> pitti, re 672964, I cant reproduce the original issue with udev 151-12.2 in lucid-updates and the steps described in the test cases , is there any other prerequisite ?
[10:11] <didrocks> ogra_ac: oh really? what should be used?
[10:12] <didrocks> (saw that in other packages too)
[10:12] <ogra_ac> didrocks, not armel related, seems that dh7 cant handle the code in rules the way you used it
[10:12] <pitti> jibel: hm, I only tried on maverick, and there it reproduced well
[10:12] <didrocks> ogra_ac: but you know I like make lool unhappy :)
[10:12] <ogra_ac> didrocks, ifeq ($(DEB_BUILD_ARCH),armel) would be better for cross builds
[10:12] <ogra_ac> that takes the target arch instead of the build machine arch
[10:12] <pitti> jibel: there shouldn't; if the initramfs gets built correctly while udev is unpacked, but not configured yet (i. e. /sbin/udevadm is diverted), the bug wouldn't happen
[10:13] <pitti> jibel: but I don't see what would stop that from happening in lucid
[10:13] <jibel> pitti, I'm trying in maverick.
[10:13] <didrocks> ogra_ac: ok, updating to that then (same for ubuntu-netbook)
[10:13] <ogra_ac> k
[10:13] <didrocks> ogra_ac: then, those two packages are yours :)
[10:14] <mvo> om26er: sure, I have a look now
[10:14] <ogra_ac> i_m still trying to figure out what makes it fail with "missing separator"
[10:14] <didrocks> ogra_ac: maybe you want to do the change and test with your hw rather?
[10:14] <ogra_ac> its not HW related
[10:15] <ogra_ac> but i cant see a typo either
[10:15] <didrocks> ogra_ac: it's building locally…
[10:15] <didrocks> and it built everywhere !armel
[10:16] <geser> ogra_ac: whitespace issue: space vs tab before the dh_install
[10:16] <ogra_ac> well, it doesnt go the script path you created if DEB_HOST_ARCH isnt set to armel
[10:16] <jussi> ts2: you going t explain for all the lovely folks here how this works?
[10:17] <lool> didrocks, ogra_ac: It's hte other way around; you want to use DEB_HOST_ARCH, not _BUILD_ARCH
[10:18] <lool> the arch on which you build it on shouldn't affect the results; only the target arch on which you expect to run it (host)
[10:18] <ts2> jussi: one sec, yeah :)
[10:19] <lool> geser found the real problem it seems
[10:19] <ogra_ac> didrocks, http://paste.ubuntu.com/535147/ that way it shoudl work
[10:20] <didrocks> yeah, I should sometimes have an automatic rules to not strip tabs when opening debian/rules in vim
[10:20] <ogra_ac> geser, oh
[10:20] <didrocks> replacing by a tab and uploading then
[10:20] <didrocks> thanks geser, lool, ogra_ac
[10:20] <didrocks> and so nothing to change for the ubuntu-netbook metapackage
[10:20] <mvo> om26er: thanks a lot for this branch. it looks fine, the only missing bit is a "TEST CASE" in the bug #674894 so that the SRU verification can be done, it should be pretty trivial in this case :) one more question - did you talk to kenvandine about the upload? I just want to ensure that he does not plan to upload this as part of some bigger patchset to maverick-proposed
[10:20] <lool> ogra_ac: No it wont; this will not define override_dh_install on != armel, so it will run dh_install by default
[10:21] <ogra_ac> lool, yeah, right
[10:21] <ogra_ac> lool, thanks for both
[10:21] <lool> didrocks: It would be nicer to ifneq ($(DEB_HOST_ARCH),armel) override_dh_install: endif and not have any dh_install
[10:21] <didrocks> lool: oh, directly wrapping the target? ok, can do that :)
[10:22] <om26er> mvo, there is nothing coming in maverick-proposed from ken since the last -proposed (big bug fix release) was just gone into -updates
[10:22] <seb128> mvo, om26er: you should let kenvandine's do the gwibber sponsoring
[10:22] <lool> Alternatively, you could use -X or -N; e.g. override_dh_install: dh_install $(if ...), but I find that harder to read
[10:23] <seb128> mvo, om26er: he's active on it and might have a reason for not having uploaded yet, at least check with him before upload
[10:23] <didrocks> lool: yeah, that was my first idea but I didn't like it when reading
[10:23] <didrocks> # Skipping dh_install - empty override <- nice dh7 warned about it :)
[10:24] <om26er> seb128, ok sure will do that today
[10:24] <mvo> seb128, om26er: ok, thanks. I will comment in the branch but wait for kenvandine for his final word then
[10:24] <mvo> if he is busy I'm still happy to sponsor it
[10:26] <om26er> mvo, ok this https://code.launchpad.net/~om26er/ubuntu/maverick/gexiv2/gexiv2-fix-636161/+merge/41398 ;)
[10:27] <om26er> its recommended from shotwell developer
[10:28]  * mvo looks
[10:31] <jussi> mvo: others, herses how the bot works
[10:32] <jussi> @pilot in
[10:32] <jussi> @pilot out
[10:32] <mvo> nice jussi!
[10:32] <mvo> @pilot in
[10:32] <nigelb> neat :)
[10:32] <jussi> mvo: thank ts2
[10:32]  * mvo hugs ts2
[10:32] <ts2> :)
[10:33]  * didrocks is kind of disappointed that the Patch Pilot isn't "Friendly" anymore ;)
[10:34] <jussi> ts2: can we have friendly patch pilots?
[10:34] <didrocks> :)
[10:35] <ts2> any other requests while I'm at it? ;)
[10:35] <jibel> pitti, I can't reproduce in maverick either. I only get a broken initramfs if I stop at step 2.
[10:35] <nigelb> didrocks: you want to bot you hug you at the end of your rotation? ;)
[10:35] <nigelb> *want the
[10:35] <jibel> pitti, if I run the postinst step, the diversion is removed before running update-initramfs and the correct udevadm is copied to initramfs.
[10:36] <didrocks> nigelb: oh neat idea! :)
[10:36] <jibel> pitti, or ma I missing something ?
[10:36] <jibel> s/ma/am/
[10:36] <pitti> jibel: oh, you mean udev.postinst configure rebuilds the initramfs?
[10:36] <jibel> pitti, right.
[10:37] <pitti> jibel: then it indeed seems that this test case isn't reproducing the problem, sorry
[10:40] <ts2> @pilot in
[10:40] <udevbot> An error has occurred and has been logged. Please contact this bot's administrator for more information.
[10:40] <ts2> yippy...
[10:41] <dholbach> thanks ts2
[10:41] <geser> it would be nice if the bot would tell who the bot admin is
[10:43] <ts2> @pilot in
[10:43] <jibel> pitti, np. I think that we can only reproduce the issue if the postinst script is not run at all or if it stops before calling enable_udevadm
[10:43] <ts2> @pilot out
[10:43] <jibel> pitti, let me know if you want to test something else.
[10:50] <pitti> jibel: will think about it; thanks so far!
[10:51] <mvo> om26er: you have just written history, the first upload from the new patch-pilot program
[10:52] <om26er> mvo, thanks alot :)
[10:52] <om26er> i am legend :p
[10:52] <didrocks> ts2: nice :)
[10:52] <bryceh> mvo, om26er, congrats :-)
[10:53] <didrocks> heh, congrats mvo, om26er :)
[10:53] <mvo> \o/
[10:54]  * pitti ^5s om26er and mvo
[10:54] <om26er> bryceh, didrocks thanks ;)
[10:57] <om26er> bug 655241
[10:57] <om26er> https://code.launchpad.net/~om26er/ubuntu/maverick/appmenu-gtk/appmenu-gtk-fix-655241/+merge/41397
[10:59] <om26er> the fix is merged upstream mvo
[10:59] <om26er> there are quite a few duplicates too.
[11:01] <om26er> thats the last one
[11:02] <mvo> om26er: thanks! I look in detail after my lunch break, from fist sigh it looks fine, it would be nice to have a TEST CASE in the bugreport to the SRU process
[11:02] <mvo> from the first look
[11:02]  * mvo can't type today
[11:02]  * om26er writes a TEST CASE
[11:06] <pitti> ev: FYI, I'll port usb-creator from pygtk2 to gtk3.0 and gi, if that's alright with you?
[11:07] <ev> that's fantastic, thanks pitti!
[11:12] <cjwatson> pitti: my understanding had been that gtk3/pygi only worked properly with python3; is that true in your expereience?
[11:12] <cjwatson> *experience
[11:13] <pitti> cjwatson: I have run into one bug where python3 works better
[11:13] <pitti> cjwatson: but by and large it's fine
[11:13] <cjwatson> ok, that's a relief
[11:13] <pitti> cjwatson: https://bugzilla.gnome.org/show_bug.cgi?id=620579 is the one FYI
[11:13] <pitti> it's being fixed
[11:13] <pitti> but it's easy enough to avoid/work around for now
[11:14] <seb128> pitti, no, it works fine with python2, though they recommends going for python3 while you are at porting if you can
[11:14] <seb128> ups
[11:14] <seb128> cjwatson, ^
[11:14] <pitti> that's right
[11:14] <pitti> but we don't currently ship py3 on the CDs
[11:14] <pitti> and I don't want to be the one who introduces it :)
[11:14] <mvo> didrocks: are you ok with me uploading #655241 ? it looks like you did most of the recent uploads?
[11:14] <seb128> right, I don't think we should go for python3 yet
[11:14] <cjwatson> seb128: I just don't want to have to do both ports simultaneously
[11:14] <mvo> didrocks: diff looks fine and is taken from the upstream branch
[11:14] <cjwatson> in general
[11:15] <seb128> right, my idea was to do python2 gi ports this cycle
[11:15] <didrocks> mvo: sure, cherry-pick it :)
[11:15] <didrocks> thanks :)
[11:16] <mvo> thanks didrocks, uploaded
[11:16] <seb128> mvo, yeah, feel free to do appmenu-gtk uploads
[11:16] <mvo> thanks om26er!
[11:16] <seb128> mvo, oh, you are the new maintainer then
[11:16] <seb128> ;-)
[11:16] <didrocks> you gave me compiz, you have appmenu :p
[11:16] <seb128> joke aside appmenu-gtk has a collection of issues if anybody feels like working on it...
[11:17] <mvo> seb128: geh, I'm pilot, not superman
[11:18]  * seb128 hugs mvo
[11:18] <dholbach> seb128, I just noticed in Harvest that there's a number of patches and branches for it :)
[11:18] <seb128> dholbach, I will kick dx-ers to get reviews
[11:18] <dholbach> sweet
[11:19] <geser> anyone available to review and sponsor a gparted SRU? the debdiff is in comment #53 of bug #617885
[11:19] <seb128> or nicely nudge rather
[11:19] <seb128> geser, I though cjwatson said he had it on his list
[11:19] <mvo> geser: I guess that is me
[11:20] <mvo> seb128, geser, cjwatson: I'm the pilot today, I can do the sponsoring (after lunch)
[11:20] <geser> seb128: wasn't that the vim merge? I asked cjwatson about gparted too but as he's busy I try to find someone else (the vim merge is still waiting on review)
[11:20] <mvo> but I'm equally happy to let someone else do it
[11:20] <seb128> geser, yeah, searching in my log I think I confused it with another patch
[11:20] <seb128> let mvo rock it ;-)
[11:22] <cjwatson> sorry, I really haven't had time to deal with gparted - if the patch pilot could deal with it I'd be enormously grateful
[11:23] <cjwatson> (otherwise my patch pilot morning is coming up next week, but you might not want to wait for that ...)
[11:24]  * mvo will take it
[11:25] <cjwatson> thanks!
[11:29] <mvo> ev: if you could have a look at some point at #545445, that would be nice. its  support for lxde in ubiquity, afaics its fine, I commented in the bug
[11:29] <mvo> (I had two question for the diff, but maybe they are non-issues)
[11:32] <seb128> bug #546445
[11:32] <seb128> mvo, rather?
[11:33] <mvo> seb128: rather?
[11:35] <seb128> mvo, the number, see line before
[11:35] <seb128> mvo, #545445 has nothing to do with ubiquity?
[11:35] <mvo> seb128: oh, sorry
[11:36] <mvo> seb128: indeed, typo
[11:36]  * mvo is away for lunch now
[11:36] <seb128> hum, lunch!
[11:36] <smoser> anyone else seeing bug 676790 ? I'm almost certain that its not just me (I've seen it happen every time during debootstrap on host system of maverick or lucid).
[11:36] <seb128> mvo, great idea ;-) I will do that as well
[11:36] <smoser> it seems fairly important to me, that it would affect cd install, and turn that into a multi hour affair
[11:43] <ev> mvo: when you get back, any idea what the details of "[ev] support "keep package selection" on install that preserves /home: TODO" in packageselection-foundations-n-update-manager-improvements are?  I thought OneConf was the approach for maintaining packages between installs.
[11:55] <smoser> has anyone attempted a natty ISO install ?
[11:56] <ogra_ac> there were plenty probs reported in the release meeting
[11:56] <ogra_ac> iirc X restarts continiously
[11:56] <dholbach> ogra_ac, I think that was a kernel bug and is fixed
[11:57] <ogra_ac> already uploaded and on the isos ?
[11:57] <dholbach> uploaded yes, isos I don't know
[11:57] <ogra_ac> k
[11:57] <ogra_ac> i just remember it was reported on friday
[11:58]  * ogra_ac doesnt touch x86 much anymore ;)
[12:06] <mvo> ev: well, oneconf requires a ubuntu one account. it seems like its pretty straightforward to preserve the selection via a chroot dpkg --get-selection like mechanism from the to-be-overwriten system. I don't have strong opinions here, but it sounds like the amount of work for this is about the same, the chroot dpkg --get-selections would just be one of two possilbe backend methods to retrieve the data needed
[12:07] <mvo> (as straightforrward as dealing with potentially multiple /usr, /var, /boot mount points can be I suppose ;)
[12:08] <ev> unless of course they have third party repositories
[12:08] <ev> in which case, as mpt pointed out, we risk removing all of their paid applications
[12:11] <sladen> where are the IRC logs from UDS?
[12:15] <mvo> ev: well, oneconf only partly helps here
[12:16] <mvo> ev: for payed apps we need to do "update repo to nre-release, check if software-is-still-there, if-not, fail or warn"
[12:16] <mvo> ev: we could extend the "preserve-packages" to preserves sources.list
[12:17] <mvo> not sure if that still fits in the spec, it gets complicated quickly
[12:25] <cjwatson> geser: DMB meeting?  we have some timezone confusion apparently
[12:32] <ev> mvo: speaking of the specification, are you working on that or are you keen to keep it as just a list of work items?
[12:33] <mvo> ev: the oneconf one?
[12:33] <ev> foundations-n-update-manager-improvements
[12:35] <mvo> ev: so far I was happy with the workitems as more a loose selection of todos, but I'm happy to write a proper spec if you prefer that
[12:37] <ev> I'm just concerned about handling the reinstallation of third-party applications.  dpkg --get-selections is easy enough if we assume a vanilla maverick to natty, but if we also copy over sources.list and try to reinstall packages, we may have broken dependencies.
[12:39] <mvo> geser: I'm happy to upload your gparted patch, could you please add a TEST CASE to the bugreport for the SRU verification - if that is not straightforward, just add something like "no known test method, regression test plus getting feedback fro mthe original reports required"
[12:40] <mvo> ev: yeah, I think it will need a python-apt app, I can work on something like that if it helps
[12:43] <mvo> ev: a more intelligent version of dpkg --get-selection that looks for stuff that is not downloadable, stuff that comes from third party repos and then checks if the third party stuff has upgrades etc
[12:43] <mvo> ev: similar to what u-m is doing when it performs its checks. we need to figure out a UI for this
[12:44] <mvo> I think that is the hardest part :)
[12:45] <ev> exactly
[12:45] <ev> answering the question of what we do when it cannot resolve something
[12:46] <ev> because we've told the user we were going to preserve applications or whatever
[12:46] <ev> but yes, a python-apt application would be most helpful
[12:51] <mvo> ev: thanks, I add a workitem for myself. I guess the exact message/Ui is on mpt, but I imagine something like a warning that the exact package selection can not be restored and a (optional) list of detailed packagename/descriptoins
[12:51] <mvo> ev: I add a workitem for myself
[12:54] <Chipzz> ev: wouldn't patching dpkg so the --get-selections option is aware of manually and automagically installed packages be more usefull?
[12:54] <Chipzz> (but the manually vs automatically installed information is sth on the apt and not dpkg level I suppose)
[13:09] <mvo> seb128: bug #486154 looks like something that really should be done upstream, no?
[13:09] <mvo> seb128: or do you think its appropriate as a distro patch?
[13:10] <seb128> no strong opinion about it, we use compiz by default
[13:10] <seb128> would be nicer done upstream though
[13:10] <seb128> but if you want to upload go for it
[13:13] <mvo> I don't feel confident in the diff enough for that, I would prefer upstreams comment
[13:13] <seb128> right
[14:11] <geser> mvo: I'll update the bug and add the TEST CASE when I'm back home
[14:12] <geser> cjwatson: the DMB meetings at 12 UTC don't suit me at all as I'm in the middle of a lecture at that time
[14:13] <soren> geser: It's still going on, if you're interested.
[14:14] <mvo> thanks geser
[14:55] <persia> bdrung, So, yeah, I tend to agree with you about core-dev being about work primarily in "core", but I'm uncertain to some degree, in part because of the issues one has in bringing new stuff in, and in part because all the packagesets depend on core, which often means one has to work in core in order not to just upload workarounds for various issues.
[14:55] <cjwatson> bdrung: if you disagree with the design of the package set split, that's one thing, but kenvandine has been working on things that *are* core packages and that are core because they're used by products other than desktop
[14:56] <cjwatson> bdrung: in some cases we've made specific exceptions, but the volume is high
[14:56] <cjwatson> and it's not always obvious that it *is* correct for these packages to be in desktop
[14:56] <cjwatson> although netbook being merged back into desktop reduces the question marks a bit
[14:58] <pavolzetor> hi, please look at this fix https://code.launchpad.net/~pavolzetor/ubuntu/natty/liferea/liferea-test
[14:59] <kenvandine> a big chunk of what lands on the ubuntu-desktop CD isn't in the desktop package set
[14:59] <cjwatson> bdrung: for example libindicator is in both Ubuntu and Kubuntu desktops, and therefore is in core
[14:59] <seb128> cjwatson, bdrung, persia: we also could use extra people being able to do sponsoring
[14:59] <cjwatson> (actually desktop-core I think)
[14:59] <seb128> out of set specific discussions
[14:59] <seb128> even if 99% of kenvandine's work is in desktop
[15:00] <cjwatson> bdrung: I made an exception because it seemed most sensible at the time, but this means that people entirely focused on ubuntu-desktop can make changes to kubuntu, which is really the sort of thing core-dev is meant for
[15:00] <persia> seb128, I'm not confortable with that rationale: I'm not convinced the sponsoring issue is a lack of people, so much as a lack of people willing to touch a small subset of critical packages.
[15:00] <seb128> if we have people who know enough about what they are doing to help on sponsoring that would be nice to have them set with upload rights
[15:00] <cjwatson> bdrung: so simply saying "oh that should be in desktop" simplifies the situation IMO too much
[15:00] <persia> seb128, And I'd rather grant access to folk because of my confidence in them uploading stuff, than because of my confidence in their ability to sponsor stuff.
[15:01] <pavolzetor> coukd someone help me
[15:01] <seb128> persia, sponsoring is uploading, I fail to see the difference
[15:01] <pavolzetor> I would like help make ubuntu better
[15:01] <seb128> pavolzetor, try #ubuntu
[15:01] <pavolzetor> so :-D
[15:01] <pavolzetor> ubuntu-mote => ubuntu-devel => ubuntu
[15:01] <pavolzetor> trhanks
[15:01] <persia> seb128, Yes, I agree.  There is no difference.  Hence I don't care about a willingness to sponsor (other than that everyone should have one)
[15:01] <seb128> pavolzetor, well maybe if you state your question in a better way
[15:02] <cjwatson> 14:58 <pavolzetor> hi, please look at this fix https://code.launchpad.net/~pavolzetor/ubuntu/natty/liferea/liferea-test
[15:02] <seb128> pavolzetor, but "can somebody help" usually go to #ubuntu
[15:02] <kenvandine> pavolzetor, oh... hang on
[15:02] <cjwatson> seb128: ^- did you see that?
[15:02] <kenvandine> pavolzetor, that isn't #ubuntu :)
[15:02] <seb128> cjwatson, no, just "<pavolzetor> coukd someone help me"
[15:02] <seb128> cjwatson, thanks
[15:02] <seb128> pavolzetor, sorry, I didn't read the first line you wrote
[15:02] <pavolzetor> I have done patch
[15:02] <BlackZ> pavolzetor: I will test your patch
[15:02] <kenvandine> pavolzetor, are you looking for sponsoring?
[15:02] <pavolzetor> and branch
[15:03] <pavolzetor> I am bit new in ubuntu dev
[15:03] <seb128> pavolzetor, you can try to ask mvo, he's patch pilot today
[15:03] <seb128> see the topic
[15:03] <seb128> pavolzetor, you might want to subscribe ubuntu-sponsors as well
[15:03] <pavolzetor> okey, I just must go out
[15:04] <persia> pavolzetor, Don't run away, just because we're confused :)
[15:04] <kenvandine> pavolzetor, sorry we were in the middle of a debate :)
[15:04] <pavolzetor> I am student and I fixed liferea indicator in free time
[15:04] <pavolzetor> I am sorry
[15:04] <kenvandine> pavolzetor, awesome... no worries
[15:04] <seb128> persia, well, I don't say we should care about willingness to sponsor, I'm just saying that kenvandine understand enough of what he's doing to do uploads out of the desktop set if he needs to
[15:04] <kenvandine> i should look at that then
[15:04] <persia> pavolzetor, Don't be sorry.  That's wonderful.  Thank you.
[15:05] <pavolzetor> I don't wanna make big changes in source, because of diffs between ubuntu and others
[15:05] <ivoks> guys, how does one make upstart not to kill child processes?
[15:05] <seb128> pavolzetor, we will get your patch reviewed and comment, you can maybe do a merge request from it?
[15:05] <pavolzetor> I have done it
[15:06] <seb128> pavolzetor, ok, so wait a bit and somebody is going to review the work you did and comment on it
[15:06] <pavolzetor> and I fixed gpm twcie steps, a "big bug"
[15:06] <pavolzetor> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257827
[15:06]  * persia finishes playing with "comm"
[15:07] <pavolzetor> I am trying get it to gnome also
[15:07] <pavolzetor> I have tested it at two comps and it works properly
[15:07] <pavolzetor> brb
[15:09] <seb128> persia, is your issue with kenvandine's application that you think that he doesn't have the skills to work out of the desktop set?
[15:09] <seb128> persia, I'm not sure to understand the issue
[15:09] <persia> seb128, No, my issue is that from what I have seen, he's never had anything in "core" even as a sponsored upload.
[15:10] <persia> I'm more than confident in his skills, but like to see some examples of work in the target packagesets before granting upload access.
[15:10] <seb128> why?
[15:10] <persia> That said, I might be using edit_acl or comm incorrectly.
[15:10] <seb128> it's a chicken egg issue
[15:10] <persia> Why?  Most folk find sponsors for stuff before applying.
[15:10] <seb128> he could be sponsoring things he doesn't work on if he had upload rights
[15:10] <seb128> he doesn't work out of desktop
[15:10] <bdrung> seb128: yes, we need more people doing sponsoring. there are 12 sponsor request open for ubuntu-desktop that kenvandine can work on.
[15:10] <seb128> it doesn't mean he couldn't make use of upload rights for sponsoring
[15:10] <kenvandine> persia, seb128 has sponsored lots of stuff for me
[15:11] <pitti> mvo: when you moved to apt-get changelog, did you keep the configuration support? (i. e. setting the mirror)
[15:11] <seb128> kenvandine, in the desktop set though
[15:11] <persia> kenvandine, I believe you.  I'm just not sure why I don't see it.
[15:11] <seb128> kenvandine, or things that ought to be in there
[15:11] <kenvandine> seb128, sort of... the fact that you needed to sponsor them though
[15:11] <persia> Might just be race conditions then: stuff being sponsored just before it hits.
[15:12] <seb128> bdrung, we know that we need more people doing sponsoring
[15:12] <pitti> mvo: ah, it's in apt-get(8) now, nevermind
[15:12] <seb128> persia, it's not even a race, if kenvandine has upload rights he could take on reviewing and sponsoring things out of the set he works usually on
[15:14] <persia> seb128, There's a sufficiency of patches not currently embedded in sponsor requests that would benefit from wrapping that I don't find that convincing.  There's plenty of stuff that can be uploaded that isn't sponsor requests.
[15:14] <seb128> persia, I don't see the point of stopping people to get upload rights if they have the skills for
[15:14] <seb128> they might not use them now
[15:15] <persia> What I'm less convinced about is whether the potential race condition between the state of the packageset at the time an upload was made and the state when I am reviewing the upload gives me an accurate picture of the historical work done.
[15:15] <seb128> but they would be set if there is any need showing up
[15:15] <superm1> ev, mvo: in terms of UI, it is sounding to me like once the person selects the option to reuse a partition you'll need to present them with another ubiquity page that gives them some details on what is about to happen with some checkboxes. Eg 1) Any  files in /home will be saved 2) The following applications that come from Ubuntu will be re-installed 3) The following applications that you paid for will be re-installed 4) The following third-
[15:15] <superm1> party sources will be re-activated.  You will need to manually reinstall applications from them; etc
[15:15] <bdrung> seb128: you should show that you can work in that area you want upload rights to.
[15:15] <seb128> persia, how can it hurt to have people skilled to be able to upload? even if they don't use that right often
[15:15] <superm1> and using the python-apt black box to build the lists for those checkboxes
[15:16] <seb128> bdrung, right, but persia said the issue was not on showing that you can
[15:16] <seb128> that's why I was asking if the issue is that he didn't show enough packaging skills
[15:18] <bdrung> seb128: i didn't saw enough outside the ubuntu-desktop set. there is no link to a launchpad bug or upload.
[15:18] <seb128> is outside of desktop harder?
[15:18] <persia> seb128, No, I said that I'm comfortable with kenvandine's skills.  That said, I'm not core-dev, so I wonder if I'm best qualified to review his work on packages in "core".  A lack of apparent uploads (either from an LP bug or coincidence) dissuades me from approving it.  On the other hand, there are a number of other things that kenvandine does need to do which would be facilitated by being core-dev, hence my indecision.  If it was just a matte
[15:18] <persia> r of access to the "core" packageset, I'd vote to defer until I could see some work history.
[15:18] <persia> (actually, might not be an LP bug, so much as some limits in data collection)
[15:18] <seb128> let's be honest, his focus is desktop
[15:19] <seb128> that will not be different because he got upload rights out of the set
[15:19] <seb128> but that doesn't mean he couldn't make use of uploads right of the set
[15:19] <mvo> pitti: yeah, I took your documentation and adapted it, the option is almost named the same (apt::changelog*s* iirc)
[15:19] <seb128> to do sponsoring
[15:19] <seb128> to be able to workaround set definition bugs
[15:19] <mvo> pitti: thanks for writing the docs btw \o/
[15:19] <cjwatson> my focus is installer/bootloader, that doesn't mean I do nothing else
[15:19] <seb128> to be able to help on something when we need people
[15:20] <mvo> @pilot out
[15:20] <kenvandine> and not to end up blocked by or distracting others when needing sponsoring myself
[15:20] <seb128> I fail to see why you have an issue with him having upload rights
[15:21] <seb128> if you trust him to upload to main out of desktop you should let him have those right, even if he doesn't use them every day
[15:21] <cjwatson> NCommander: are you being a patch pilot today (per the schedule)?
[15:21] <ogra_ac> cjwatson, he should be, but doesnt seem to be up yet
[15:21] <seb128> that show we have qualified people in the team and people able to take on tasks that require those rights
[15:21] <persia> cjwatson, It's 7:21am there :)
[15:21] <ogra_ac> (we discussed it last week)
[15:22] <SpamapS> anybody have ideas what might cause the error about tar here:  http://launchpadlibrarian.net/58855548/buildlog_ubuntu-lucid-i386.mongodb_1:1.2.2-1ubuntu1.1~ppa1_FAILEDTOBUILD.txt.gz ?
[15:22] <SpamapS> dpkg-deb: building package `mongodb' in `../mongodb_1.2.2-1ubuntu1.1~ppa1_i386.deb'.
[15:22] <SpamapS> tar: ./usr/bin/mongo: file changed as we read it
[15:22] <cjwatson> persia: hm, I forgot he'd moved
[15:22] <SpamapS> it works in sbuild and pbuilder .. but the PPA build fails
[15:22] <bdrung> seb128: i like to see a list of sponsored uploads to the core package set
[15:23] <cjwatson> he's still London-0500 in my head
[15:23] <persia> Thought that might be it :)
[15:24] <persia> SpamapS, Ask in #launchpad: my random guess would be overeager cleanup of some sort.
[15:24] <seb128> bdrung, he doesn't work out of desktop
[15:24] <seb128> bdrung, but he could be helping sponsoring out of desktop or be assigned task that require upload out of desktop he had right to work there
[15:24] <seb128> bdrung, which is not the case
[15:24] <seb128> there is no point for him to pick a sponsoring bug if he can't upload
[15:26] <bdrung> seb128: there are 12 sponsor request he can work on
[15:26] <seb128> I'm not saying he lack sponsoring tasks to work on
[15:26] <seb128> I'm saying he could do things
[15:26] <seb128> like if libindicate soname change tomorrow
[15:26] <seb128> he could upload all the no change rebuilds himself
[15:27] <seb128> those being in the desktop set or not
[15:27] <seb128> rather than having to deal with pinging people or opening sponsoring requests
[15:27] <seb128> you are arguing that he might not use his upload right
[15:27] <seb128> so what if he doesn't
[15:27] <seb128> it still doesn't cost anything
[15:27] <SpamapS> persia: ack
[15:28] <seb128> it can only be useful
[15:28] <seb128> if it doesn't it still doesn't hurt
[15:28] <seb128> it would be a no change compared to now
[15:28] <seb128> you block a potential win situation just because it might not win a lot?
[15:29] <seb128> I fail to see the point... let people be able to help, what they do then is their issue
[15:30] <bdrung> seb128: it's not about what he will do, but about what he has done.
[15:30] <seb128> why does it matter?
[15:30] <pavolzetor> I am back
[15:30] <pavolzetor> please reply if there are some issues with my patches
[15:31] <pavolzetor> I think, gpm patch would have higher priority
[15:31] <persia> seb128, It's how it's always been done: we expect work to be done through sponsors before we grant direct upload permissions.
[15:31] <seb128> bdrung, it's about having confidence people are ready for uploading or not
[15:31] <bdrung> seb128: is it enough to show that you have packaging skills or should you show that you can work in specific area?
[15:31] <seb128> well nobody has worked on everything
[15:31] <persia> pavolzetor, Be aware that it sometimes takes a while for folk to give feedback.  If you've subscribed the sponsors and/or made a merge proposal, someone should review it before too long.
[15:31] <seb128> even debian doesn't ask you to work on everybody before being a DD
[15:32] <persia> Debian and Ubuntu have very different models.
[15:32] <seb128> they just ask you to show you have the technical skills and social understanding to do what you want to do
[15:32] <seb128> persia, did you read what I wrote a few minutes back?
[15:32] <seb128> like being able to handle a soname change transition
[15:32] <pavolzetor> I think moths are too long
[15:33] <kenvandine> i think what seb128 is saying, it isn't likely that anyone will assign a bug with a patch on it to review if i can't upload it
[15:33] <pavolzetor> I am mainly interested in android, but this is my part-hobby
[15:33]  * ogra_ac doesnt get this discussion, 128 sponsored uploads on maverick-changes dont qualify for upload rights ?
[15:34] <persia> ogra, Where are the 128 sponsored uploads?  remember that kenvandine has upload access to a number of packages.
[15:34] <bdrung> i want to see the list where kenvandine gets an upload to the core-set sponsored
[15:35] <ogra_ac> persia, on maverick-changes in my evolution if i search for his name
[15:35] <seb128> bdrung, he doesn't, he's working on desktop
[15:35] <ogra_ac> why does he need to ?
[15:35] <seb128> bdrung, sure we don't ask to help with transitions out of the desktop set because he can't upload
[15:35] <persia> ogra, I'm having trouble finding anything sponsored.  128 seems about right based on what I see.
[15:35] <seb128> persia, I've sponsored at least 25 uploads for him last cycle
[15:36] <seb128> random number but he pings me at least once or twice a week every week
[15:36] <ogra_ac> so he is obviously able to do proper packaging
[15:36] <seb128> it does cost me non null time
[15:36] <persia> seb128, Do you happen to remember what one of them was?
[15:36] <bdrung> seb128: can you give us the list of these uploads?
[15:37] <seb128> persia, bdrung: gtk3 today
[15:37] <seb128> nov. 02 22:19:09 <kenvandine>	seb128, can you sponsor lp:~ken-vandine/ubuntu/maverick/x264/maverick-proposed
[15:37] <seb128> nov. 09 20:41:23 <kenvandine>	seb128, btw i am just running ubuntu-geoip through pbuilder for natty, then it will be ready to sponsor :)
[15:37] <seb128> nov. 09 21:37:51 <kenvandine>	seb128, lp:~ubuntu-desktop/ubuntu-geoip/ubuntu is ready to sponsor
[15:38] <seb128> I might have forgotten about x264 in fact
[15:38] <seb128> nice example of thing that would have been uploaded if it was not blocked on me
[15:38] <kenvandine> seb128, i think you did, and pitti saved the day :)
[15:38] <seb128> ok, great, I though I might just have zapped it ;-)
[15:39] <bdrung> seb128: gimme the list (pointing to the uploads like https://launchpad.net/ubuntu/+source/gtk+3.0/2.91.4-0ubuntu1 ) would convince me
[15:40] <bdrung> seb128: this list is missing on his application
[15:40] <seb128> bdrung, I changed laptop recently and don't have IRC logs over this month now
[15:40] <seb128> bdrung, I don't even see why you need it
[15:40] <seb128> ken clearly has showed he can be trusted with uploads
[15:41] <seb128> which does it matter if he use that right often or not?
[15:41] <seb128> it's wasting us hours every cycle to not have him having upload rights, that's not like we could use with extra hands
[15:41] <geser> for me having a list of sponsored uploads (direct or indirect (e.g. requested rebuilds)) would be a proof that someone has a "need" for core-dev uploads right and not just the skill but no current use for them
[15:41] <persia> seb128, It's not just about kenvandine: it's about every applicant.
[15:42]  * ogra_ac really doesnt get that discussion, we have someone who *obviously* is good at packageing, he offers to help in other areas and we refuse ?!?
[15:42] <bdrung> seb128: that's the Chicken or the egg dilemma
[15:42] <seb128> persia, well same applies to everybody
[15:42] <ogra_ac> we havent been that picky in the past
[15:42] <seb128> why should somebody with technical and social skills to be part of the team not be in?
[15:42] <geser> ogra_ac: we haven't had packagesets in the past
[15:42] <seb128> just because it doesn't help every day?
[15:42] <persia> seb128, Sure.  Historically, we've expected people to demonstrate their work by getting sponsored.  I'm not sure that's broken.  I'm having difficulty finding recent examples of that happening for kenvandine.
[15:43] <ogra_ac> geser, no, but do we need to add extra bureaucracy ?
[15:43] <kklimonda> for some reason the discussion reminds of the medieval age and apprenticeship from back then...
[15:43] <seb128> persia, it doesn't work lot out of desktop, does it mean it shouldn't be welcome?
[15:43] <persia> There are *other* reasons kenvandine would benefit from being core-dev, but I'm not yet convinced they are sufficient (uploading new packages, working on stuff in universe).
[15:43] <seb128> persia, I would be assigning him desktop tasks I can't assign him now if he could upload
[15:43] <Riddell> mvo: I don't suppose you know what's wrong with this upgrade bug 680088 ?
[15:43] <ogra_ac> if someone has obviously the tech skills it should really be a non-issue
[15:43] <seb128> persia, he would spare me sponsoring work as well
[15:44] <geser> seb128: so everyone with the needed skills should become core-dev because he *might* need them in future?
[15:44] <ogra_ac> if he/she asks for them, why not
[15:44] <seb128> everybody who has contributed to ubuntu in a significant way yes
[15:44] <ogra_ac> he/she can be a patch pilot
[15:44] <seb128> that's what debian does and what we used to do
[15:44] <ogra_ac> etc
[15:44] <seb128> uploads right doesn't hurt
[15:44] <seb128> they can only be useful
[15:44] <ogra_ac> ++
[15:44] <seb128> he might sponsor once a month
[15:45] <bdrung> i think geser and i share the same concern. i have to leave now.
[15:45] <seb128> it's still a win
[15:45] <bdrung> ogra_ac: you don't be a core-dev to be patch pilot
[15:45] <seb128> kenvandine, has uploaded hundred of packages to main
[15:45] <persia> You don't even have to be a developer
[15:45] <seb128> it's not like he was not contributing
[15:45] <persia> It's not about "main".  It's about "core"
[15:45] <seb128> same differenc
[15:46] <persia> Except it's not: it's also about new packages and universe, which complicates the picture.
[15:46] <seb128> being able to help where help is needed
[15:46] <ogra_ac> bdrung, you need to be core-dev for being a patch pilot for all core-dev packages
[15:46] <persia> No, not at all.  There's *lots* of stuff in main that isn't in core.
[15:46] <ogra_ac> its only a win
[15:46] <seb128> we need people who have skills to help out of their usual set
[15:46] <persia> ogra, No you don't: a huge number of patches are better addressed upstream.
[15:46] <ogra_ac> the criteria should really be tech based
[15:47] <ogra_ac> rarther than artificial political issues imho
[15:47] <ogra_ac> if he is technically capable and wants to help, let him do
[15:47] <persia> ogra, Which artificial political issue?
[15:47] <cjwatson> for the record, the patch pilot programme is intended to include things like poking people to follow up on patches, making sure people get a good first response and are directed to the right place to discuss their work, etc.  there's no need to drag that programme into this.
[15:47] <ogra_ac> persia, dunno, obviously there is no tech issue blocking here
[15:47] <geser> it's not political for me; I just prefer to give a person the rights that he really needs (just like access in security)
[15:48] <seb128> geser, well it means you are blocking all people working on specific sets to help
[15:48] <seb128> you should remove my rights to upload out of desktop going this way
[15:48] <mvo> Riddell: I commented in the bugreport, it complains about libkephal4/plasma-netbook
[15:48] <seb128> I'm doing 95% of my work in desktop as well
[15:49] <seb128> I'm just not sure what you would win by doing that
[15:49]  * ogra_ac doesnt want to have such a discussion for every member of the arm team in the future 
[15:49] <ogra_ac> and we dont have a single package set
[15:49] <seb128> I think I will just recommend desktop people to not try to work out of desktop
[15:49] <seb128> seems that's not welcome
[15:49] <ogra_ac> i.e. every team member would have to be core dev
[15:49] <ogra_ac> yeah
[15:49] <seb128> way to drive contributors away
[15:49] <ogra_ac> its a weird setup imho
[15:50] <persia> seb128, Rather, if there is history of work outside desktop, upload rights outside desktop are easily granted.  Without any prior history, it's uncertain.
[15:50] <seb128> "sorry but they don't like people who focus on a set"
[15:50] <persia> That's not at all the case.
[15:50] <seb128> it is
[15:50] <geser> seb128: I'm not strict on how many uploads one does outside his package set, but at least show that ones does them
[15:50]  * persia is having trouble finding *one* for maverick or natty
[15:50] <ogra_ac> persia, but why has there to be any history ? tech skills should be enough
[15:50] <seb128> persia, I just gave you 3
[15:50] <seb128> persia, for kenvandine
[15:50] <kenvandine> gtk3 today
[15:51] <seb128> gtk3 today got rejected
[15:51] <seb128> x264 in maverick-proposed
[15:51] <ogra_ac> and the expressed will to help out with more
[15:51] <persia> Ah, rejected.  Excellent.
[15:51] <persia> Why was it rejected?
[15:51] <kenvandine> perms
[15:51] <kenvandine> gtk3 isn't in the desktop set yet... so now i need seb128 to sponsor it for me
[15:52] <kenvandine> even though i applied almost the same patch to gtk2 and uploaded that
[15:52] <chrisccoulson> gtk2 isn't either is it? seb128 had to do a gtk2 upload for me last week
[15:52] <kenvandine> so until gtk3 gets added to the package set, i need to interupt someone with changes
[15:52] <kenvandine> chrisccoulson, i uploaded that fine on friday
[15:52] <chrisccoulson> oh
[15:52] <geser> that would be proof enough for me (as I expect that this won't be the only upload to the core set)
[15:52] <seb128> Signed-By: Didier Roche <didrocks@ubuntu.com>
[15:52] <seb128> https://launchpad.net/ubuntu/maverick/+source/compiz/1:0.8.6-0ubuntu8
[15:53] <seb128> ^ another one
[15:53] <chrisccoulson> i've got no idea what i can upload really, it seems a bit hit-and-miss
[15:53] <kenvandine> edit_acl.py is your friend
[15:53] <kenvandine> :)
[15:53] <geser> desktop might be a little bit special in this regard thanks to the intermix with core
[15:53] <chrisccoulson> kenvandine, oh, you're right
[15:53] <kenvandine> geser, right... ultimately the stuff i work on could be anything that ends up on the desktop CD
[15:54] <chrisccoulson> so, i could have uploaded it myself then
[15:54] <persia> chrisccoulson, `./edit_acl.py -P ubuntu-desktop -S natty query` would show you the list of desktop packages.  Dunno if you have other packagesets offhand.
[15:54] <cjwatson> this bites desktop a lot because there's a lot of overlap between Ubuntu and Kubuntu desktop that one or the other side maintains
[15:54] <seb128> Signed-By: Martin Pitt <martin.pitt@ubuntu.com>
[15:54] <seb128> https://launchpad.net/ubuntu/maverick/+source/x264/2:0.98.1653+git88b90d9-3ubuntu1
[15:54] <persia> geser, What intermix?  The exceptions lists?
[15:55] <geser> yes, that several packages that "belong" to the gnome desktop are in core
[15:55] <geser> I guess this is less a problem for e.g. mythbuntu
[15:55] <seb128> well still, we could assign him sponsoring bugs to review for example if he was able to upload
[15:55] <seb128> or helping on transitions for soname changes
[15:56] <geser> I'm happy with any proof that one will use that uploads right and just doesn't apply because it's "nice to have"
[15:56] <ogra_ac> or any other transitions
[15:56] <seb128> those cases don't show upload in uploads before because they are tasks that don't make sense when you need a sponsor
[15:56] <geser> that's part of how I understand the whole ArchiveReorg
[15:57] <seb128> you create a chicken egg issue there
[15:57] <seb128> we can't get people to help on those because to be able to help they need upload rights
[15:57] <ev> superm1: I'd like to keep things consistent with the existing interface, if possible and avoid superfluous checkboxes.  We should pick a singular outcome and structure the documentation around that.  This is automatic partitioning, after all.
[15:57] <ev> oh, when you said checkboxes did you mean bullet points?
[15:58] <superm1> well i was thinking checkboxes, but bullet points might make more sense if it is automatic
[15:58] <geser> seb128: that mustn't be necessarily sponsored uploads, I would trust a word from you that you sponsored uploads for him (without any visible LP record9
[15:58] <seb128> I sponsor at least an upload for him a week
[15:58] <superm1> but the important bit was relaying what the outcome would be before doing it since it could have different results depending on web access and for different people
[15:58] <seb128> that every week in the cycle
[15:58] <geser> for me that would be sufficient
[15:58] <geser> (the word from you)
[15:59] <seb128> we add comments from pitti and me at least on kenvandine's wiki
[15:59] <seb128> add -> had
[15:59] <kenvandine> and didrocks
[15:59] <kenvandine> all wrote endorsements :)
[15:59] <seb128> not sure what else is needed there
[15:59] <kenvandine> thx guys
[15:59] <seb128> kenvandine, np ;-)
[15:59] <persia> Examples of work would have been nice, and saved the confusion.  Turns out my issue was not querying on the "desktop-core" set.
[16:00] <ogra_ac> to me this process looks really scary and broken to be honest
[16:00] <geser> I didn't read the application page yet and didn't attend the DMB meeting, will follow-up with my vote to the DMB later
[16:00] <seb128> geser, thanks
[16:00] <seb128> still seems artificially hard
[16:00] <ogra_ac> ++
[16:00] <seb128> kenvandine does over an hundred upload a cycle and had endorsement from 3 active ubuntu members
[16:01] <persia> ogra, The process is basically: do something, get sponsored, ask for upload rights, get upload rights to the stuff you had sponsored work on (typically by packageset)
[16:01] <ogra_ac> persia, yeah, thats broken
[16:01] <seb128> well it doesn't solve the need to have people being able to work on things out of specific sets
[16:01] <seb128> or to help there
[16:01] <persia> This oughtn't be overly hard or complicated.  Sometimes the tools are confusing, or we make mistakes.
[16:01] <ogra_ac> if i have the skills and am willing to help out, even if i didnt yet, i should be granted access
[16:01] <persia> ogra, Which part is broken?
[16:01] <seb128> especially that set are buggy
[16:01] <ogra_ac> the tech skills should be all that rules here
[16:02] <seb128> we have chrisccoulson and kenvandine hitting set issues every week
[16:02] <seb128> it's costing us a lot of energy
[16:02] <cjwatson> I'm not being asked about this every week
[16:02] <cjwatson> and I wonder why not
[16:02] <seb128> those might not been "issues" than "technlogogies used in kubuntu, xubuntu, etc as well"
[16:02] <persia> seb128, If the set is buggy, we should fix that.  If we're having consistent set issues, we should describe the class, and fix that.  Fixing on a per-person basis doesn't scale.
[16:02] <kenvandine> cjwatson, just us needing sponsoring
[16:02] <seb128> cjwatson, because often those are cross desktop techs
[16:02] <seb128> dbus, libnotify, etc
[16:02] <cjwatson> seb128: ok ... but you're saying the set is buggy.  which is it?
[16:02] <cjwatson> either it is buggy, in which case the bugs should be reported, or it is not
[16:02] <seb128> "buggy" might be wrong
[16:03] <kenvandine> buggy might not be the word
[16:03] <seb128> it's just that we touch techs which impact on other sets
[16:03] <ogra_ac> the policy is buggy imho
[16:03] <cjwatson> ogra_ac: conflicting requirements
[16:03] <cjwatson> makes it hard to keep everyone happy
[16:03] <seb128> cjwatson, ideally chrisccoulson and kenvandine would have access to cross desktop techs
[16:03] <persia> ogra, How do you recommend we judge other than on prior work?
[16:03] <pitti> seb128: (which would make them eligible for core-dev IMHO)
[16:03] <cjwatson> one suggestion would be to have both Ubuntu and Kubuntu desktop folks have upload access to the desktop-core set
[16:03] <ogra_ac> persia, do a techincal only judgement of the skills
[16:04] <cjwatson> that might ease the pressures without being one-sided
[16:04] <kenvandine> the set probably is good for most people, but some of us touch a wide array of pieces
[16:04] <persia> seb128, That's being core-dev, which is fine.
[16:04] <persia> ogra, Based on what?
[16:04] <seb128> pitti, well, the issue there is that persia, geser and bdrung think kenvandine doesn't work enough out of desktop to warrant that
[16:04] <ogra_ac> persia, exposing the proper skills of former work and expressing the will to help should be enough
[16:04] <cjwatson> wait, geser doesn't seem to have expressed a definitive opinion yet
[16:04] <persia> seb128, I said I couldn't *find* the work.  I've found it now (I was looking in "core", and it's in "desktop-core")
[16:04] <seb128> persia, not it's not, we are arguing over an hour now because you said kenvandine's doesn't need it
[16:04] <cjwatson> and persia explicitly abstained
[16:04] <chrisccoulson> having access to desktop-core would help me quite a bit. most of the stuff i find i can't upload is in desktop-core
[16:05] <cjwatson> (actually, bdrung also abstained)
[16:05] <seb128> ok, so maybe what we need is desktop members to have access to desktop-core
[16:05] <seb128> would that be doable?
[16:05] <geser> seb128: that's not what I been trying so say, all I want is some proof that someone is working outside a package set
[16:05] <persia> seb128, I never said that.  I said that from what I could find, he hadn't done *any* work in the area to which he wished to be granted upload access.  This turns out to have been a problem with my tools.
[16:05] <cjwatson> I think the DMB would have to agree on it, but it's certainly technically possible.  As I say I think that it should be both Ubuntu and Kubuntu though (the desktops in main)
[16:06] <seb128> persia, ok
[16:06] <cjwatson> (meeting)
[16:06] <kenvandine> doesn't solve new packages and such
[16:06] <kenvandine> but would cover more for sure
[16:06] <persia> I'd rather keep that to core-dev, personally (and I don't mind granting core dev to people working on that set, with some demonstrated work)
[16:06] <seb128> right, it's still annoying in quite some case
[16:06] <seb128> like the GNOME3 new sources landing regularly in natty
[16:07]  * ogra_ac totally agrees
[16:07] <Laney> they can easily be added to the sets
[16:07] <kenvandine> not before they are uploaded
[16:07] <chrisccoulson> kenvandine, yeah, that probably helps me more than you, because i can already upload to universe :(
[16:07] <persia> kenvandine, Indeed: it's the new packages problem and the not-yet-in-the-packageset problem that made me almost vote for you to be core-dev *even though* I couldn't find the examples.  I'm glad I found them.
[16:07] <seb128> speaking of which what is the official way to have things added to a set?
[16:07] <seb128> out of pinging cjwatson on IRC ;-)
[16:07] <persia> seb128, It's supposed to be ask an archive-admin, but in practice it's ask cjwatson.
[16:08] <Laney> not archive-admin, member of owning team
[16:08] <chrisccoulson> and it doesn't help the fact that i still can't target bugs in packages that i can upload (or maintain) to a particular release
[16:08] <seb128> I was asking to try to avoid pinging cjwatson directly
[16:08] <persia> And ideally, the archive-admin request is in a bug.
[16:08] <seb128> chrisccoulson, you should apply for core rights
[16:08] <persia> chrisccoulson, That7s a different issue.  Isn't it targeted to get sorted soon?  I thought I heard things at UDS about it being on the short-term list.
[16:08] <geser> any TB member can add packages to TB owned packagesets (the are only DMB owned packagesets)
[16:08] <Laney> You can email the owner of the set (I think they are all TB or DMB owned)
[16:09] <seb128> Laney, where do I find the owner of a set?
[16:09] <chrisccoulson> seb128 - i was thinking about it until i saw this discussion today ;)
[16:09] <persia> Did the bug in LP that limits changing stuff to the TB get fixed?
[16:09] <seb128> persia, see what you did :p
[16:09] <chrisccoulson> i think that the DMB members will have all the same objections with my application (i do 95% of my work in desktop or mozilla)
[16:09] <seb128> you made chrisccoulson not to apply! ;-)
[16:09] <geser> seb128: through the LP API (owner attribute of the package set)
[16:09] <Laney> seb128: set.owner attribute
[16:09] <Laney> actually I patched edit_acl to display that locally
[16:09] <Laney> can push a branch if you want to merge it
[16:09] <seb128> hum
[16:10] <seb128> I will let other people deal with that
[16:10] <seb128> but seems the reply is "there is no easy way out of writting code to query launchpad"
[16:10] <persia> chrisccoulson, We don't care about the 95%: we care about the 5%: if you have work that you did in core or desktop-core, and you list it on your application page, there will be little confusion, and you'll just get approved or rejected for something other than the areas of your work.
[16:10] <Laney> the LP web UI is lacking when it comes to package sets, indeed
[16:10] <seb128> chrisccoulson, joke aside you should apply
[16:10] <Laney> I would love the +source page to display them for example
[16:10] <seb128> I think the confusion was mostly that they didn't consider desktop-core
[16:11] <seb128> chrisccoulson, should be easier for you now that this one is sorted
[16:11] <persia> Laney, That7s been requested, for the Soyuz ArchiveReorg spec from this last UDS.
[16:11] <Laney> persia: yeah, I know (or I'd be filing a bug)
[16:11] <geser> some web-UI for package sets would be nice (a little overview and the like)
[16:12] <persia> seb128, My confusion was that I didn't consider desktop-core.  I can't speak for anyone else (and some DMB members voted in favour, just not enough to confirm during the meeting)
[16:12]  * ogra_ac still would like to rather see the policy fixed
[16:12] <persia> ogra, Would you prefer to grant upload access to people with no demonstrated experience?
[16:12] <ogra_ac> persia, no
[16:13] <persia> Then why do you suggest that we shouldn't use demonstrated experience as a criterion?
[16:13] <seb128> "not uploading out of a set" != "not showing experience"
[16:13] <ogra_ac> persia, but if i have rights for packageset A and have proven that i'm technically capable, requesting sponsoder proof for packageset B if i express interest in that packagset is nonsense
[16:13] <seb128> you can do all your work in a set and demonstrate enough experience to be trusted with uploads
[16:13] <geser> ogra_ac: I don't believe that the policy has changed much, only that the packagesets made it more hard to show the expierence in the area where one wanted to have upload rights
[16:14] <ogra_ac> the *technical* skills should be all that matters here
[16:14] <persia> I don't think it's more hard.  It's the same.
[16:14] <persia> ogra, So everyone should be core-dev, with no distinctions?
[16:14] <seb128> geser, well we should be able to say that someone showed enough skills to be able to work out of one specific set
[16:14] <ogra_ac> its not, since you refused to grant rights without sponsored proof right above
[16:14] <seb128> persia, those who showed enough experience yes
[16:14] <seb128> if they ask for it
[16:14] <persia> seb128, How do we judge that except by them showing they did work outside the set?
[16:14] <seb128> if people are happy in their set no
[16:15] <ogra_ac> persia, everyone who has the skills sould be *easily able to* become core-dev, yes
[16:15] <seb128> persia, how is the work out of the set different from the work in the set?
[16:15] <ogra_ac> you are making the process overly complex
[16:15] <ogra_ac> while only the tech knowledge should matter
[16:15] <seb128> persia, the packaging doesn't change because you are out of a set
[16:15] <persia> seb128, Shows integration with wider communities of developers.  Shows consideration for other packages that depend on the packages being worked upon.
[16:15] <ogra_ac> and the tech knowledge was judgeable by existing work
[16:15] <ogra_ac> sponsored or not
[16:15] <seb128> you still use the same infrastructure, debian packaging, launchpad, etc
[16:16] <persia> No?  Compare Java packaging to GNOME packaging some day :)
[16:16] <seb128> persia, java-gnome bindings?
[16:16] <seb128> you have java in desktop as well
[16:16] <persia> That's packaged GNOMEy, but sure.
[16:16] <ogra_ac> persia, know what ? i'm core-dev and wouldnt touch java packaging with a ten foot pole
[16:16] <ogra_ac> do you want me to withdraw from core-dev now ?
[16:17] <ogra_ac> into some package set ...
[16:17] <seb128> I was asking the same before
[16:17] <geser> no
[16:17] <cjwatson> this is getting a bit emotive
[16:17] <persia> ogra, No.  You've demonstrated that you won't touch Java with a 10 foot pole, so I feel safe about you and java
[16:17] <ogra_ac> cjwatson, i'm cool sorry if i dont sond like
[16:17] <ogra_ac> persia, right, so why should that matter for someone becoming core-dev then
[16:18] <ogra_ac> ask him/her in the DMB meeting if he/she would touch java
[16:18] <seb128> persia, well you can show that you are reasonable and would not touch things you don't understand while working in a set
[16:18] <ogra_ac> but judge his/her tech skills based on existing work
[16:18] <ogra_ac> without the requirement to having sponsored packages to the future set he/she is intrested in
[16:18] <ogra_ac> the existing work should be enough for that
[16:19] <dholbach> I think trust is important - if I trust somebody to know where to stop and where to ask that's one of the most important things (plus statements from others who worked with them, etc.)
[16:19] <ogra_ac> right
[16:19] <ogra_ac> more important than sponsored uploads
[16:19] <ogra_ac> and trus is something you have to build up *without* the tech skills
[16:19] <persia> Trust is indeed important, but I have to wonder how much trust someone has if they can't find any work to do or anyone to sponsor their work in their target area.
[16:19] <ogra_ac> and whichch should be based on testimonials
[16:20] <persia> And while I try to know everyone, I know that I fail, and I am certain I'm not alone in that failure.
[16:20] <ogra_ac> sure, and you dont have to
[16:20] <ogra_ac> thats why we got wiki pages
[16:20] <geser> should everyone from the the "kernel" set get upload rights for "core" because we trust them with kernels?
[16:20] <seb128> persia, taking kenvandine's case you got pitti didrocks and me saying he does nice work
[16:21] <ogra_ac> geser, if he knows packaging good enough, yes
[16:21] <seb128> geser, no, but when you get 3 people from the set giving you recommendation you would consider that enough
[16:21] <pitti> geser: do you trust me with kernels? (you certainly shouldn't)
[16:21] <persia> I'd much rather focus on making it easy for folks to demonstrate their work in other areas than make granting of upload rights a popularity contest.
[16:21] <ogra_ac> indeed for the kernel thats hard to judge, there wont be many different packages to review
[16:21] <pitti> geser: just as a point that there can't ever be the perfect core-dev
[16:21] <apw> heh, you want to make sure this conversation is stricken from the logs, else noone will ever bother applying for core-dev again
[16:21] <pitti> in practice, everyone knows just a subset of everything
[16:21] <ogra_ac> pitti, nontheless you can upload one if you want ;)
[16:21] <geser> ogra_ac: then why do we the whole package set business at all? just having motu and core-dev like in the old days would be much easier
[16:21] <pitti> well, unless you are cjwatson, of course
[16:22] <persia> ogra, So what kernel folk do is peer-review for the first few uploads, and then bring the demonstration to the DMB, and get a new kernel uploader.  It's just collaboration.
[16:22] <seb128> geser, because some people are desktop contributors only
[16:22] <seb128> they don't want or need anything else
[16:22] <seb128> we have people who want to be able to do GNOME updates
[16:22] <seb128> it's an easier way to start
[16:22] <ogra_ac> geser, i dont say package sets are wrong
[16:23] <seb128> desktop being once example
[16:23] <ogra_ac> but the artificial threshold you put in place is
[16:23] <seb128> some people might be just interested in xubuntu
[16:23] <persia> seb128, So, if you have folk in the desktop team who need wider access, just make sure they get some stuff sponsored (you say you do this already), make sure that the examples show on their applications, and they are likely to easily be approved as core-dev.
[16:23] <seb128> then you get people over time that might feel like doing work out of the set
[16:23] <persia> With no examples, and difficulty finding any work, it's a more complicated discussion.
[16:24] <seb128> persia, well I still fail to say why we need those if you have several trusted people who worked with them and said they would be useful contributors out of the set
[16:24] <ogra_ac> geser, if there is enough work to judge on, why do i need sponsored uploads to the target set i want to enter ? i have already proven my skills enough before
[16:24] <seb128> persia, gotcha on how to get people approved easily
[16:24] <persia> And the example that raised this is not a good one, as it came from a misunderstanding on one person's part as part of an *incomplete* DMB vote.  No application was deferred.
[16:24] <seb128> I still think you are putting some requirements which are not needed
[16:25] <ogra_ac> persia, no, its a good one
[16:25] <kenvandine> the tough thing for me is there are lots of examples of my work that didn't need sponsoring, because of the the package set
[16:25] <seb128> persia, you might have people who could help with transitions or sponsoring
[16:25] <ogra_ac> since you guys asked for sponsored uploads to the future target set
[16:25] <ogra_ac> which is a big flaw imho
[16:25] <seb128> they will just not do as long as they can't upload
[16:25] <seb128> because they then need to find themself a sponsor
[16:25] <persia> ogra, Why?  it7s an *incomplete* vote.  Even without this discussion, kenvandne may have become core-dev.
[16:25] <seb128> which is costing as much work they spared
[16:25] <geser> ogra_ac: so everyone who can package gnome ("desktop") should get access to "kubuntu" just by asking? because he knows how to package?
[16:26] <ogra_ac> geser, if he can prove he knows how to package, why shouldnt he ?
[16:26] <seb128> geser, if we trust him to not upload without asking there, etc why not?
[16:26] <persia> seb128, I actively don't want folk working on sponsoring if they have no experience in the target area.  I7d rather they chase the random patches not ready for sponsoring and get them tested and in shape.  There's *lots* of non-sponsoring work to be done, and I don't think the primary activity of developers ought be sponsoring (although sponsoring is a welcome part of it).
[16:26] <ogra_ac> if i'm able to fix a bug in gtkmm, why shouldnt i be able to fix a bug in QT ?
[16:27] <cjwatson> pitti: (I steer *well* clear of desktop, FWIW ...)
[16:27] <seb128> persia, well then ignore sponsoring and take transitions as an example
[16:27] <ogra_ac> cjwatson, it was about abilities ;)
[16:27] <pitti> cjwatson: nevermind, it was just a compliment :)
[16:27] <persia> transitions and packagesets interact very badly, unfortunately.
[16:27] <\sh> persia: +1
[16:28] <geser> ogra_ac: I believe that only knowing how to package is not enough; I'd expect that he also knows how "kubuntu" works (how the packages interact each other)
[16:28] <seb128> persia, see you hit limitation which block people in doing work and helping
[16:28] <ogra_ac> geser, how does that matter to fix an ftbfs in a single package ?
[16:28] <seb128> would it be launchpad issues, new sources, set definitions bugs, transitons
[16:28] <ogra_ac> geser, i touched enough kubuntu packages in my ubuntu life and have no clue at all how kubuntu works
[16:29] <mvo> smoser: re #676790 - this is the natty apt?
[16:29] <ogra_ac> nontheless i bet people in kubuntu were happy when their packages built
[16:29] <smoser> mvo, yes.
[16:30] <\sh> ogra_ac: we all touched a lot of packages where we didn't know how that all works...but that's long time ago...
[16:30] <cjwatson> Keybuk: (from #ubuntu-meeting) I don't pretend that this would be anything other than a nasty hack, but given how the kernel presently behaves it seems to me that the only thing init can do is try a few times in the hope of winning the race eventually.  Obviously you don't want to block starting other events on that
[16:30] <geser> ogra_ac: it's also about trust; I don't know how to properly explain it and I'm myself not fully sure where I draw the borders
[16:30] <cjwatson> s/other events/other jobs/
[16:30] <ogra_ac> geser, so make it a requirement that someone from the desired package set expresses trust in the wikipage
[16:30] <mvo> smoser, pitti: it sounds like bug #676790 is releated to the compressed indexes
[16:30] <smoser> based on nothing but changelogs, i suspect it has to do with the compression
[16:31] <pitti> right
[16:31] <smoser> yeah, that was my suspicion too
[16:31] <Keybuk> cjwatson: yeah, but in theory init is going to proxy everything anyway
[16:31] <pitti> I just don't know yet what these image builds do with apt indexes
[16:31] <ogra_ac> but dont make sponsored uploads a requirement to people who can prove their knowledge already
[16:31] <cjwatson> Keybuk: remind me: would anything go wrong if pid 1 kept its own master fd on /dev/console (with O_NOCTTY of course) and duped it, rather than reopening for each job?
[16:31] <\sh> mvo: good that I see you...I don't know if you are responsible, but /etc/cron.daily/apt does some strange apt-key net-update thingy...and it starts wget to get a keyring..without a sane timeout...can we change something there?
[16:31] <Keybuk> so the fd won't be console anyway
[16:31] <Keybuk> it'll be a pty
[16:31] <cjwatson> Keybuk: this is lucid
[16:31] <Keybuk> and then it'll output that to console later
[16:31] <smoser> pitti, its nothing strange, i would suspect that a CD install would hit this
[16:31] <Keybuk> lucid we fixed already
[16:31] <cjwatson> no we didn't, per bugs
[16:31] <Keybuk> at least fixed well enough
[16:31] <smoser> its basically an 'apt-get install some package list'
[16:31] <Keybuk> what are the bugs now?
[16:32] <cjwatson> this is why I brought up bug 642555
[16:32] <Keybuk> cjwatson: yes, if you SysRq-K you get a kernel panic
[16:32] <cjwatson> in the meeting where you responded
[16:32] <Keybuk> if Upstart keeps its own console fd
[16:32] <cjwatson> I assumed you'd seen it
[16:32] <cjwatson> ok
[16:32] <Keybuk> no, I'm not reading bugs anymore
[16:32] <mvo> \sh: sure, is there a bugreport?
[16:32] <geser> ogra_ac: for me sponsored uploads are only one way to proof that, a comment from the set "leader(s)" is for me also sufficient
[16:32] <cjwatson> I assumed you'd seen it *in the meeting log* since you responded there
[16:32] <cjwatson> I know you aren't reading bug mail
[16:33] <\sh> mvo: not right now, I wanted to talk to you before :) because some of my servers do have no direct internet connection....and I always see this process hanging and timeouting after several hours whysoever
[16:33] <ogra_ac> geser, why leaders ?
[16:33] <mvo> \sh: heh :)
[16:33] <Keybuk> oh, no, I just have certain highlights ;)
[16:33] <Keybuk> I was coding
[16:33] <mvo> \sh: sure, let me quickly check the code
[16:33] <ogra_ac> and why cant you judge by existing work ?
[16:33] <\sh> mvo: especially when the firewall drops those packages
[16:34] <\sh> mvo: I think there needs to be just a --timeout option to wget (60 secs should be enough imho)
[16:34] <seb128> is grep-dctrl working for other people in natty
[16:34] <seb128> ?
[16:35] <cjwatson> there is a lot of plymouth-hatery in that bug, which makes it difficult to pick out the real issue
[16:35] <Keybuk> well, yeah
[16:35] <Keybuk> or if there is actually an issue
[16:35] <geser> ogra_ac: perhaps leaders is the wrong word, more "key persons"; persons who I'd trust from that team and not somebody who just entered into the team in the last meeting or so
[16:35] <cjwatson> but making sure that there's a console fd would dismiss that part of the question for good
[16:36] <ogra_ac> geser, agreed, still though, technical knowledge should be judgeable by former work already, i agree on the trust thing
[16:37] <chrisccoulson> seb128 - it doesn't work here, but i guess that's because the package lists in /var/lib/apt/lists are stored compressed now
[16:37] <seb128> chrisccoulson, I was wondering about that yes
[16:37] <seb128> iz pitti bog? ;-)
[16:38] <chrisccoulson> heh:)
[16:38] <pitti> chrisccoulson: "it" ==?
[16:38] <pitti> oh, grep-dctrl
[16:38] <chrisccoulson> pitti - did you break grep-dctrl? l;)
[16:38] <geser> ogra_ac: for extending permissions, the technical knowledge often isn't the hard part, for those applications I watch more on comments from "key persons" from the team where one applies
[16:38] <chrisccoulson> :)
[16:38] <pitti> chrisccoulson: presumably; can you please file a bug about it and assign to me?
[16:38] <pitti> (sorry, I'm in meeting, and then off)
[16:38] <chrisccoulson> pitti - yeah, sure
[16:39] <ogra_ac> geser, right, what seemed wrong to me above was just the requirement that ken had sponsored uploads to the core-dev set
[16:39] <seb128> chrisccoulson, I can do it if you want
[16:39] <seb128> chrisccoulson, I was the one who asked about it ;-)
[16:39] <chrisccoulson> seb128 - yeah, feel free to do that :)
[16:39] <seb128> chrisccoulson, ok
[16:53] <cjwatson> Keybuk: I posted to that bug to try to narrow things down a bit
[16:57] <pitti> ev: FTR, the UI works, but I have spent an hour trying to track down why the communication with the backend locks up; presumably a threading deadlock, so I pushed the stuff to a branch for now; will get back to that tomorrow
[16:58] <ev> thanks
[16:58] <ev> indeed, I should've never gone down the path of threads with that application.
[16:58] <pitti> it's a pain to debug indeed, but let's see
[16:59] <pitti> could be that gi/pygobject just isn't thread safe yet, I'll investigate
[17:00] <pitti> good night everyone
[17:00] <ev> g'night pitti
[17:04] <cjwatson> pitti: OK if I just accept this d-i upload?
[17:06] <bdrung> geser: you said that you found sponsored work from kenvandine - how?
[17:14] <ari-tczew> bdrung: tumbleweed has a script to looking sponsored bugs
[17:15] <mvo> \sh: commited the timeout fix to bzr now, thanks for the report!
[17:16] <\sh> mvo: thx to you...(and I didn't file any report ;))
[17:17] <mvo> \sh: no worries
[17:18] <geser> bdrung: did I? persia found it in "desktop-core"
[17:21] <Sarvatt> is there a way to mark a bug fix in a sync request without doing it in debian's changelog?
[17:23] <Laney> you can make that bug into the sync request bug
[17:24] <persia> bdrung, I screen-scraped LP to get kenvandine's uploads, and then compared with the output of edit_acl querying the desktop-core set, and found matches.
[17:26] <seb128> zul, hi
[17:26] <zul> seb128: hey
[17:26] <seb128> zul, do you think you could sru the fix from https://bugzilla.samba.org/show_bug.cgi?id=7791?
[17:26] <seb128> it's bug #393012
[17:26] <persia> RAOF, pitti Welcome to the sponsors team :)
[17:27] <seb128> zul, https://bugzilla.samba.org/attachment.cgi?id=6062&action=view
[17:27] <zul> seb128: sure
[17:27] <seb128> zul, thanks
[17:27] <\sh> oh wow...attachmate wants to take over Novell, and Microsoft wants to get hold on some IPs of Novell...oh wow...this will be fun and I can already read all the FUD news
[17:27] <seb128> zul, we got quite some users unhappy because smb copies from nautilus are broken in maverick, that should fix it ;-)
[17:28] <cjwatson> pitti: ... accepting, figuring it's OK
[17:28]  * smb does not like his copies to be broken
[17:28] <zul> seb128: gotcha...but they shouldnt be running windows in the first place ;)
[17:28] <seb128> ;-)
[17:28] <seb128> zul, thanks!
[17:30] <ogra_ac> gah, damned, no way back, i'm in the ubuntu-sponsors team
[17:31] <\sh> ogra_ac: lol...you were in the past, too..well not sponsors, but MOTU
[17:31] <ogra_ac> (thats like the patch pilot flight license, right ?)
[17:32] <ogra_ac> \sh, indeed
[17:33] <persia> ogra, The main power of the sponsors team is the ability to unsubscribe the sponsors team from things no longer of interest.
[17:34] <ogra_ac> persia, patch pilot license, as i said ;)
[17:40] <\sh> ogra_ac: I hope the patch pilots don't have problems like the A380 pilots ;)
[17:41] <ogra_ac> we dont use rolls royce ;)
[17:42] <ogra_ac> we are launchpad powered instead ;)
[17:47] <slangasek> SpamapS: bug #582963> so what does the apache2 ask-for-passphrase do if plymouth shuts down in the middle of prompting?
[17:51] <geser> ogra_ac: and no eject button :)
[17:51] <ogra_ac> heh
[17:54] <Kmos> date
[18:01] <geser> mvo: added TEST CASE to bug 617885
[18:04] <geser> mterry: can you please do a vala-dep-scanner upload soon? so we are one rdepends nearer to kill libvala-0.10{,-dev}
[18:16] <mterry> geser, ah ok!  a new version is coming out shortly, so yeah
[18:16] <geser> thanks
[18:29] <ogra_ac> stgraber, so i managed to get lightspark to build up to the point where it starts linking against the intel SSE assembler code (where it indeed fails). from a packaging POV its easy to add armel support, but the assembler is a huge lot
[18:30] <stgraber> ogra_ac: ok, cool. And I guess there's no C equivalent for that assembler code (that'd likely make it "unoptimized" but at least work) ?
[18:30] <ogra_ac> i dont think so
[18:32] <ogra_ac> the assembler really hooks deeply into SSE, rewriting that is beyond me
[18:33] <stgraber> is that something anyone at Linaro might be interested to work on ?
[18:34] <stgraber> I guess it depends on how much you really want a flash implementation and of ongoing discussions with Adobe by the manufacturers (I'm guess there's some as unfortunately flash is usually kind-of a must have :()
[18:37] <ogra_ac> well, i guess the manufacturers get access to flash internally
[18:43] <ScottK> cjwatson: re  bug 635273, I don't have a strong opinion.  Depending on what the fix it, it might be ~OK.  I'd make barry figure it out.
[18:50] <SpamapS> slangasek: you mean the race condition between ping and ask? yeah.. I thought about that when I copied it from some other package. :-/
[18:51] <ScottK> skaet: Sorry I missed the meeting, an appointment ran over.  One item of note for 10.04.2 is that the Tech Board approved putting KDE point releases in -updates so you can expect Kubuntu to update to KDE 4.4.5 (and 4.4.7 for kdepim) for 10.04.2.
[18:52] <SpamapS> slangasek: I believe apache2 will fail to start at that point.
[18:54] <SpamapS> slangasek: its kind of an interesting problem..  we kind of have to have this happen before getty's/X ..
[18:59] <bdrung> geser: sorry. i meant persia.
[19:00] <bdrung> persia: can you give me your findings?
[19:25] <bdrung> Sarvatt: i think the no-source change syncs are useless
[19:26] <Sarvatt> bdrung: ack, wasn't sure on those because pitti is doing no change reuploads of X packages in main to shrink the livecd size
[19:27] <bdrung> Sarvatt: when will be the next cd spin?
[19:27] <Sarvatt> I just requested the ones in xserver-xorg-video-all
[19:28] <Sarvatt> dunno, I agree they are kind of useless but was trying to help out since I saw him doing that
[19:28] <jmelis> Hello, is this channel the right place to ask about packaging?
[19:29] <bdrung> Sarvatt: if pitti wants the rebuilds, then give him the rebuilds. ;)
[19:29] <bdrung> jmelis: yes
[19:29] <bdrung> jmelis: maybe #ubuntu-motu is appropriate too
[19:31] <jmelis> my question is: I have a package, and I have created a system-V init script in the debian folder named <package>.init. I'm working with 10.04. The problem is that after installing the package the init script is not installed in /etc/init.d... How can I debug this? System-V init scripts are still working, or do I have to switch to upstart?
[19:31] <persia> jmelis, Are you calling dh_installinit?
[19:31] <skaet> ScottK,  Riddell,   will add that Kubuntu will update to KDE 4.4.5 (and 4.4.7 for kdepim) into the minutes.   Thanks for letting me know.
[19:31] <jmelis> persia: no. where should I do that?
[19:32] <jmelis> persia: in the rules file, correct?
[19:32] <Sarvatt> ok I'll invalidate all the sync requests that aren't new upstream versions then. sorry for all of the sync requests but its a heck of a lot easier to do everything in debian and request a sync since I'm not a core-dev :)
[19:33] <persia> jmelis, Yes, in the rules file.  If you're using dh(1), it's probably automated.  If not, it's usually done in the install: rule, somewhree around dh_installmenu
[19:33] <bdrung> Sarvatt: no, you misunderstood me
[19:33] <jmelis> persia: can you point me to a guide that explains this? I haven't had much luck finding one...
[19:34] <Sarvatt> how so? from what I understood you think it'd be better to do a no change rebuild instead of syncing something like this? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-tdfx/+bug/680110
[19:34] <persia> jmelis, Erm, I don't tend to do it manually, but ask in #ubuntu-packaging, and I'm sure someone can take you through it step-by-step
[19:35] <jmelis> persia: thanks a lot!
[19:35] <persia> Sarvatt, If that upload was needed in Debian, doesn't make any difference which way you do it.  Note that things in sync will autosync, so sometimes no request is required.
[19:35] <jmelis> i'll give it a shot myself, if it doesn't work I'll go to #ubuntu-packaging
[19:35] <persia> Heh, OK :)
[19:36] <SpamapS> slangasek: In looking at this, I don't know if we'll have other services like this, but in this case we have to make sure that apache starts before plymouth is stopped. Can we somehow wait in plymouth-stop for apache?
[19:36]  * persia isn't as sure of being active in #ubuntu-packaging later
[19:36] <SpamapS> it would appear to me that plymouth quit could be called from several locations.. :-P
[19:37]  * highvoltage somehow didn't know about #ubuntu-packaging before now
[19:37] <SpamapS> highvoltage: me too :p
[19:38] <bdrung> Sarvatt: i thought that syncing a no-change version from debian has no benefit, but if a rebuild is really desired, it's ok
[19:40] <bdrung> Sarvatt: if pitti wants the rebuilds, then give him the rebuilds by syncing from debian.
[19:41] <Sarvatt> bdrung: either way works, it's just easier for me to request syncs than find sponsors for all of the no change rebuilds so I did it that way for packages in xserver-xorg-video-all and I completely understand if a no change rebuild would be preferred, no problems doing it that way instead here outside of it being a lot harder to find sponsors :)
[19:42] <bdrung> Sarvatt: but i prefer a sync over a no change rebuild :)
[19:45] <bdrung> Sarvatt: we have ack-sync for sync requests and sponsor-patch for everything else. so there is no big difference from the sponsoring side of view
[19:51] <bdrung> Sarvatt: processed all sync requests - all were fine
[19:52] <Sarvatt> bdrung: thanks a ton for that!
[19:52] <bdrung> Sarvatt: np
[19:54] <Sarvatt> sorry to dump so many sync requests in there, unstable is being reserved for squeeze on the driver side and everything's being done in experimental
[19:55] <bdrung> Sarvatt: no problem. we can live with that. in the lucid cycle, we had to requests syncs from unstable. ;)
[19:58] <bdrung> all sync requests processed
[20:01] <SpamapS> hmm... is there a way to lock plymouth so it won't exit after 'plymouth quit' until you've unlocked it?
[20:02] <SpamapS> that would work to make sure plymouth is around to enter the SSL pass phrase...
[20:03] <SpamapS> hmm.. I actually need it to also not deactivate
[20:10] <SpamapS> I wonder if pause-pogress would work
[20:53] <slangasek> SpamapS: I don't see any sane way to wait in plymouth-stop for apache to start.  For now, perhaps open a new bug report against the package to document this know issue?
[20:53] <slangasek> +n
[21:11] <bdrung> BlackZ: libgphoto2-2.4.10.1 fails to build: Unmet build dependencies: libgpmg1-dev - but libgpmg1-dev is there
[21:12] <BlackZ> bdrung: it's related to build-dependencies with [linux-any], if you want, patch your pbuilder ( see http://bugs.debian.org/363193 )
[21:12] <BlackZ> bdrung: it's fixed in the launchpad buildd AFAIK
[21:16] <bdrung> BlackZ: the merge will took more time (this bug and big diff). ask the patch pilot instead or ask me tomorrow again.
[21:17] <bdrung> BlackZ: i sponsored enough today.
[21:17] <BlackZ> bdrung: heh, will do :)
[21:17] <bdrung> BlackZ: look at that spice in the first graph: http://reports.qa.ubuntu.com/reports/sponsoring-stats/
[21:19] <BlackZ> bdrung: uh, cool!
[21:19] <micahg> very cool :)
[21:28] <bdrung> crimsun: can you reassign bug #678183 to the correct package?
[21:33] <Awsoonn> hi all, what package is the network proxy config tool in?
[21:37] <hallyn> upstart question.  Is it actually the case that if package X installs an /etc/init/X, that its removal should not remove /etc/init/X?  (I wouldn't have thought so)
[21:38] <cjwatson> not particularly upstart-specific
[21:38] <soren> hallyn: It's got nothing to do with upstart. It's all dpkg.
[21:38] <cjwatson> in general, files in /etc are conffiles and are only removed on purge
[21:38] <hallyn> oh, ok.  so --purge should remove the conffile at least?
[21:38] <cjwatson> yes
[21:39] <soren> hallyn: this is also why most init scripts (sysv style ones, that is) almost always have a check for the presence of the daemon they're supposed to start.
[21:39] <hallyn> ok, thanks guys.
[21:39] <soren> hallyn: Sure.
[21:40] <hallyn> oh, so does dpkg do it automatically for debian/*.upstart files?
[21:41] <soren> hallyn: Not that I know of.
[21:42] <ebroder> hallyn: debhelper does it automatically for files installed into /etc
[21:42] <soren> ?
[21:42] <soren> Sorry, then I don't understand the questoin.
[21:42] <cjwatson> indeed, at debian/compat level 3 and above
[21:42] <soren> hallyn: What is "it" in your question?
[21:43] <ebroder> soren: dpkg determines what should be removed at purge vs. uninstall based on a "conffiles" file in the control information (i.e. DEBIAN/conffiles or /var/lib/dpkg/info/foo.conffiles)
[21:43] <soren> ebroder: I know.
[21:43] <hallyn> soren: sorry, i meant removing the init scripts
[21:43] <hallyn> but dh_installinit manpage i *think* answers that
[21:43] <soren> hallyn: That's what I thought. Then no. It doesn't.
[21:44] <hallyn> hm, dh_installinit says it sets up postrm commands...
[21:44] <ebroder> hallyn, soren: Err, sorry - I think I inverted the question when I answered it
[21:44] <soren> hallyn: It removes the rc?.d/ links.
[21:44] <hallyn> soren: yeah that was my first interpretation, but that doesn't help :)
[21:45] <hallyn> ebroder: meaning it does not?
[21:45] <hallyn> all right - thanks guys, at any rate it's not quite what i expected, sadly, and i know what i need to do :)  thanks
[21:45] <ebroder> hallyn: debhelper will mark /etc/init/* as a conffile. dpkg will only remove conffiles when the package is purged
[21:45] <soren> hallyn: debian/*.upstart are installed as upstart jobs. They land in /etc and are handled like any other conffile.
[21:45] <hallyn> ok, so still --purge removes them
[21:45] <soren> hallyn: "conffile" is a very specific term here.
[21:45] <soren> hallyn: Different from "config file".
[21:46] <soren> hallyn: That may not be completely obvious.
[21:46] <hallyn> it's not
[21:46] <soren> hallyn: Right. So when people talk about this stuff, "conffiles" is a term used to describe a set of files that dpkg handles in a very specific way.
[21:48] <soren> hallyn: For almost all packages that use debhelper (which is almost all of them), this set includes all files shipped in /etc.
[21:48] <soren> hallyn: Others can be added to the set. It's reasonably rare, though.
[21:49] <soren> hallyn: "shipped in /etc" is also a pretty specific phrasing. Some packages end up having files in /etc that aren't conffiles.
[21:49] <soren> hallyn: They do this by shipping the file in /usr/share somehwere and then copying it into /etc at postinst (or preinst, I suppose) time.
[21:52] <hallyn> soren: ok, thanks.  and i presume the idea is that those should be preserved as much as possible?
[21:56] <cody-somerville> ugh
[21:56] <cody-somerville> why am I getting ubuntu-desktop team bugs now? :(
[21:56] <cody-somerville> oh wait, thats the mailing list
[21:59] <soren> hallyn: Sorry, i don't understand the question.
[22:00] <hallyn> soren: well, between package upgrades, and temporary removals, etc, the conffiles are treated specially so that local customizations are preserved
[22:04] <hallyn> (i was just blabbing, ignore me)
[22:14] <ScottK> hallyn: It's described in debian-policy.
[22:16] <Gulfstream> What language is Ubuntu written in? I am thinking about simply changing the name... WHat language skills are needed?
[22:17] <cjwatson> Ubuntu is made up of lots of different pieces of software written in quite a few different languages
[22:17] <cjwatson> the primary ones, depending on how you count it, are probably C, Python, POSIX shell, C++, Perl, a few others
[22:18]  * ogra_ac thinks shell comes before python :)
[22:18] <hallyn> ScottK: thanks, bookmarked.  will be reading that
[22:18] <ogra_ac> if the order is based on most freqently used langs
[22:22] <Gulfstream> which language is best for fixing Ubuntu?
[22:22] <ogra_ac> you need to really look at the piece of ubuntu you want to fix
[22:22] <ogra_ac> (i.e. the package that has the issue)
[22:22] <ogra_ac> and find out which language this uses
[22:23] <Gulfstream> okay
[22:25] <Gulfstream> Which language would you recommend someone learn?
[22:27] <ogra_ac> shell and C would likely be a good start ....
[22:27] <ogra_ac> but thats personal preference
[22:27] <sladen> Gulfstream: pick a goal, and then work backwards to see how to achieve it
[22:28] <ogra_ac> some pepole would probably recomment to start with python
[22:28] <ogra_ac> yeah, what sladen says makes sense
[22:31] <sladen> Gulfstream: perhaps investigate some of the "papercuts" bugs.. some of those are as simple as changing a string (eg. menu item) to be more accurate
[22:32] <Gulfstream> Okay
[22:33] <Gulfstream> is C# used much?
[22:33] <cjwatson> there's some, not lots in the core
[22:33] <cjwatson> we ship a couple of applications by default that are written in C#
[22:35] <Gulfstream> Thanks for the info... I will see what I can learn
[22:36] <hunger> Gulfstream: "Our" C# is using different libs than would normally be used on windows... so do not spend too much time on the ui stuff when wieding a windows book:-)
[23:05] <SpamapS> slangasek: The bigger issue is that when we write an apache upstart job, we are going to have to revisit the non-plymouth passphrase dialog... :-P
[23:06] <slangasek> oh, this isn't even an upstart job yet?
[23:06] <ebroder> SpamapS, slangasek: Isn't the bug that plymouth will willingly exit when a client is in the middle of an ask-{for-password,question} command?
[23:07] <SpamapS> actually I don't think it will
[23:07] <SpamapS> its that gdm may start before apache has asked for a password
[23:08] <SpamapS> ebroder: I'm trying to grok plymouth's code/docs to verify that.. or to figure out how to play with it without having to constantly restart a vm
[23:08] <ebroder> SpamapS: At least with plymouth-x11, "plymouth quit" will cause plymouthd to exit, and the plymouth clients get an error
[23:08] <ebroder> SpamapS: Install plymouth-x11, then do sudo plymouthd and sudo plymouth show-plash
[23:09] <ebroder> *show-splash
[23:09] <NCommander> @pilot in
[23:09] <geser> cjwatson: (/me reading the meeting logs) I've no problems to access packagesets information over LP API with anon login. Or is a specific method failing?
[23:09] <jono> NCommander, did you just sign in for your patch pilot work?
[23:09] <SpamapS> ebroder: ahh, you're my hero. ;)
[23:09] <NCommander> jono: yeah.
[23:09] <jono> NCommander, cool, thanks!
[23:09] <NCommander> jono: I can't upload though
[23:10] <NCommander> jono: at least not today
[23:10] <jono> NCommander, no worries, if you can review patches that is fine
[23:10]  * NCommander does not have a working card reader so no GPG keys, I can put stuff in my queue however to upload when I can
[23:10] <jono> and help people get in touch with the right folks
[23:10] <jono> cool
[23:10] <jono> thanks NCommander :-)
[23:10] <ajmitch> NCommander: you're the lucky person first up for it? :)
[23:10] <ebroder> ajmitch: mvo went earlier
[23:10] <jono> ajmitch, mvo was
[23:10] <jono> :-)
[23:10] <ajmitch> aha
[23:13]  * NCommander generates a temporary GPG key for thsi laptop so I can upload
[23:13] <NCommander> BAH :-P
[23:21] <cjwatson> geser: I tried making edit_acl.py use anonymous login for query and it fell over in some way I forget
[23:21] <cjwatson> geser: if you can make it work, send me a patch :)
[23:22] <cjwatson> --- ChangeLog   2010-08-04 03:43:05 +0000
[23:22] <cjwatson> +++ ChangeLog   2010-11-22 13:33:13 +0000
[23:22] <cjwatson> @@ -1,3 +1,4041 @@
[23:22] <udevbot> Error: "@" is not a valid command.
[23:23] <cjwatson> yow, grub is not a particularly quiet project
[23:23] <geser> cjwatson: will give it a try, the FTBFS page is also using anon LP API login and can access packagesets data. I'll look what breaks.
[23:23] <cjwatson> I may just have been being stupid
[23:24] <SpamapS> ebroder: does plymouth-x11 allow typing in answers to ask-question btw?
[23:24] <SpamapS> ebroder: mine seems not to
[23:44] <ebroder> SpamapS: I can get ask-for-password to work, but not ask-question
[23:56] <SpamapS> ebroder: hmm.. so.. plymouth quit doesn't seem to kill it ... just blocks actually