[00:07] <allquixotic> Hi, I am trying to add a patch to the quilt stack in lp:~ubuntu-desktop/rhythmbox/ubuntu. I used `quilt import' to pull the patch in. but lintian gives me this error: "E: rhythmbox source: quilt-series-references-non-existent-patch 01_vala_vapigen.patch" The problem is that exact file *does* exist in the patches dir, and it's in the right place in the series file. What gives?
[00:07] <slangasek> allquixotic: did you 'bzr add' the patch file?
[00:08] <allquixotic> slangasek: No :) That's all I had to do?! OK. Let me try that.
[00:09] <slangasek> allquixotic: without 'bzr add', the new patch file isn't part of the bzr branch and won't be picked up by bzr bd
[00:09] <allquixotic> slangasek: Ah, right. And I was running bzr-buildpackage which == bzr bd. Many thanks!
[00:09] <slangasek> sure :)
[00:10] <RAOF> What sort of useless filesystem debugging tool segfaults when fed a broken filesystem?  GAH!
[00:12] <corecode> is there a special tool to write to debian/changelog and commit a bzr revision at the same time?
[00:14] <TheMuso> corecode: debcommit
[00:14] <TheMuso> corecode: sorry, you have to write to debian/changelog first with debcommit
[00:15] <TheMuso> slightly misread your question.
[00:20] <corecode> ok
[00:20] <corecode> thanks
[00:32] <slangasek> so, 'dch && debcommit' :)
[00:35] <slangasek> ttx: commented the bug
[01:00] <smoser> anyone able to tell me why there would be no maverick build of libjibx-java ?
[01:00] <smoser> https://launchpad.net/ubuntu/+source/libjibx-java
[01:01] <smoser> i'm guessing ftbfs ?
[01:01] <ajmitch> smoser: it was removed, see https://edge.launchpad.net/ubuntu/+source/libjibx-java/+publishinghistory
[01:05] <smoser> hm...
[01:05] <smoser> so it *does* have reverse depends in ubuntu
[01:08] <slangasek> smoser: check with Riddell, I guess?  Generally we shouldn't auto-process removals from Debian for packages that have reverse dependencies in the archive still
[01:09] <slangasek> smoser: would bringing the new libjibx1.{1,2}-java packages into maverick address the issue?
[01:09] <smoser> i dont know the answer to that.
[01:47] <mathiaz> kees: hi!
[01:48] <mathiaz> kees: could you do a search on the archive to see if there are any package using dbi_conn_error_flag?
[01:48] <mathiaz> kees: this function has been changed in the new upstream version of libdbi
[02:08] <mathiaz> kees: nevermind - I've been able to get what I was looking for
[03:28] <allquixotic> When I grab a source package via `apt-get source' and the sources dir contains debian/patches/nn_*.patch and debian/patches/series, how do I apply those patches? quilt?
[03:52] <smoser> kees, around ?
[03:53] <smoser> euca_rootwrap question.
[04:31] <kees> smoser: email me; i'mhigh latency this week (at blackhat and defcon conferences)
[04:32] <smoser> i found the answer.
[04:32] <smoser> whether ror not you'd like it to be true, a program invoked via euca_rootwrap can fork/exec anything it wants.
[04:32] <smoser> i had thought that your security measures might have stopped that.
[04:55] <kees> smoser: ew, it's not supposed to be able to do that
[04:55] <smoser> hm..
[04:55] <smoser> maybe i did something wrong
[04:56] <kees> maybe you're using the upstream version instead of the replacement i wrote?
[04:58] <smoser> i dont think so
[04:59] <smoser> from our packages:
[05:00] <smoser> kees, http://paste.ubuntu.com/470524/
[05:00] <smoser> maybe i wasn't explaining myself well.
[06:44] <pitti> Good morning
[06:44] <ion> ing
[06:46] <andreserl> Hi all. Have a quick question. Should we Build-Depend in a virtual package, or in a real package?
[06:55] <pitti> zul: can you please aply v7x' debdiffs in bug 611101  and bug 611102 and then actually test the package?
[07:04] <kees> smoser: uhm... you added /bin/sh to the conf...
[07:04] <smoser> yes.
[07:04] <smoser> and then invoked /bin/sh (a command in the conf)
[07:04] <kees> so, of course it can run anything.
[07:04] <smoser> and it forked something else
[07:04] <smoser> thats what i was asking.
[07:04] <smoser> if you were intending to stop forks of other programs.
[07:05] <kees> no, and that would probably break other stuff.
[07:05] <smoser> right
[07:05] <smoser> ok.
[07:05] <kees> the euca white list was built to just try to not make it blindingly simple to gain root privs from the euca user
[07:06] <kees> it's almost certainly possible, but it was REALLY possible with the old one, which just did exec(argv[1]) etc...
[07:06] <kees> the idea was to try to help euca start to build up a whitelist and helpers to validate arguments, etc.
[07:07] <kees> but since it's still not upstream, I don't think there are any plans to improve it.
[08:08] <dholbach> good morning
[08:17] <diwic> dholbach, good morning
[08:17] <dholbach> hey diwic
[08:37] <mdz> mvo, unfortunately I can no longer test that nvidia progress bar issue. the nvidia card in question is dead (its fan stopped)
[08:38] <mvo> mdz: thanks, I can reliable reproduce it now on both a ati and a nvidia card, looks like a issue with cairo 1.9.x hitting slow rending path(es) on these cards
[08:38] <mvo> mdz: its now in bug #595845 (including small demp and timing info)
[08:56] <RAOF> I'm not entirely sure where that slowness is coming from - I was going to look at oprofile output, but on my nouveau system the slowness *isn't* accompanied by CPU usage, so oprofile wasn't catching any hot paths.
[09:02] <mvo> RAOF: today my nouveau system does not start (complains that drm can not set DRM device bus id, otherwise I would be able to help
[09:03] <RAOF> Gargh.
[09:03] <RAOF> Yeah, that's a race condition.
[09:03] <RAOF> Delete the ureadahead pack file and your boot should slow down enough for X to start
[09:04] <RAOF> Alternatively, add drm to your initramfs by setting FRAMEBUFFER=y in one of the conf files.
[09:06] <RAOF> mvo: bug #606244 is what you want to follow for that.
[09:08] <mvo> RAOF: thanks!
[09:46] <pitti> 2010-07-29 08:46:34 INFO    Comment: NBS
[09:46] <pitti> 2010-07-29 08:46:34 INFO    1196 packages successfully removed.
[09:46] <pitti> wow
[09:46] <pitti> seems nobody did that for a while
[09:48]  * pitti removes 543 more old kernel packages
[12:21] <apw> pitti, ! 543 ! ... that really hasn't been done for a while
[12:23] <chrisccoulson> pitti - how frozen is lucid for SRU's?
[12:23] <chrisccoulson> i have an ubufox SRU with a couple of fixes in (one of them disables the "Report a problem" menu item in firefox)
[13:01] <pitti> chrisccoulson: once mysql lands (hopefully today, will coordinate with zul), then that's "it"
[13:22] <Riddell> TheMuso: ping?
[13:55] <TheMuso> Riddell: pong
[13:57] <Riddell> TheMuso: I e-mailed, you should be asleep :)
[13:57] <TheMuso> Riddell: heh, its about 11:0PM in the evening, will take a quick peak before heading to bed. :)
[13:59] <TheMuso> Riddell: speech-dispatcher. I have resigned from the fork, and don't intend to package opentts for maverick.
[14:01] <TheMuso> Now I am off to bed.
[14:49] <ikonia> dholbach: are you there ?
[14:51] <dholbach> ikonia: yes
[14:51] <ikonia> dholbach: can I nudge you a pm please ?
[14:51] <dholbach> you can try :)
[15:32] <mathiaz> superm1: hi - I'm currently investigating bug 598030
[15:32] <mathiaz> superm1: is there anything in the code that would make things harder?
[15:33] <mathiaz> superm1: is inventory_firmware_gui the only bit that call anything gui related?
[15:42] <quadrispro> ehy mvo, nice to see you aroun! I've mail'd you but now I have to leave, see you later
[15:54] <superm1> mathiaz, you are best speaking with michael brown about that stuff, but i dont see him on right now
[15:54] <superm1> mebrown is his handle
[15:58] <mathiaz> superm1: great - thanks
[16:01] <superm1> mathiaz, here's mebrown
[16:01] <superm1> you can restate your question to him
[16:01] <mathiaz> mebrown: hi - I'm currently investigating bug 598030
[16:02] <mathiaz> mebrown: is there anything in the code that would make things harder?
[16:02] <mebrown> not really.
[16:02] <mathiaz> mebrown: is inventory_firmware_gui the only bit that call anything gui related?
[16:02] <mebrown> they are separate bins
[16:02] <mebrown> I think so.
[16:02] <mathiaz> mebrown: IIUC inventory_firmware_gui is just a GUI frontend that call the cli scripts?
[16:03] <mebrown> no
[16:03] <mebrown> separate implementation that uses the backend python libs
[16:03] <mebrown> shares same libs as the cli, but does not use
[16:03] <mathiaz> mebrown: gotcha
[16:03]  * mathiaz nods
[16:03] <mathiaz> mebrown: do you have an opinion on the package names?
[16:04] <mathiaz> mebrown: ie should the gui be split to firmware-tools-gui?
[16:04] <mathiaz> mebrown: that would require desktop users to install firmware-tools-gui instead of firware-tools
[16:04] <mathiaz> mebrown: I wonder what's the impact on existing documentation
[16:04] <mebrown> mathiaz, no real strong opinions.
[16:05] <mathiaz> mebrown: or users expects to have a gui when installing firmware-tools?
[16:05] <mebrown> mathiaz, would like it if all the pkgs could use the same convention, though. (rpm/deb/etc)
[16:05] <mathiaz> mebrown: is there already a split for rpm packages?
[16:05] <mebrown> no.
[16:06] <mebrown> would probably need to split into something like: firmware-tools-libs, firmware-tools-cli, firmware-tools-gui
[16:06] <mebrown> and have firmware-tools be a meta-pkg for backwards compat
[16:06] <mathiaz> mebrown: ok - s/-libs/-common/
[16:07] <mebrown> I dont really have a clear idea if most people use the cli or gui. I suspect that most people use cli, but no hard data
[16:07] <mebrown> -common works for me
[16:07] <mathiaz> mebrown: so firmware-tools-common, firmware-tools-cli, firmware-tools-gui and firware-tools depending on firware-tools-gui
[16:07] <mathiaz> mebrown: as a transitional package
[16:07] <mebrown> sounds fine to me. probably want f-t to depend on both f-t-g and f-t-c
[16:08] <mathiaz> mebrown: great - thanks for your input
[16:08] <tumbleweed> if anyone is doing anything about firmware-tools, dell probably needs a prod. It looks like their firmware repository is in poor shape
[16:09] <mebrown> tumbleweed, yes, I know.
[16:09] <mebrown> its mine and I'm catching up on all my projects now
[16:09] <mebrown> spent a year in limbo working on... just a sec, let me get the link.
[16:10] <tumbleweed> a cool. I was the last person to touch firmware-tools here, and found it to be rather unhappy
[16:10] <mebrown> http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2010/07/27/dell-openmanage-6-3-for-ubuntu.aspx
[16:11] <mebrown> got a funny message from the blog team this morning: Why does your blog post have two orders of magnitude more views than any of the other stories?
[16:13] <ScottK> pitti: Would you please rescore xine-lib.  It just affects powerpc and ia64 and should save us some retries on those archs to get it built now.
[16:21] <pitti> ScottK: sure, doing
[16:21] <ScottK> pitti: Thanks.
[16:25] <zul> ptti: acked
[16:53] <zul> pitti: done
[17:33] <LucidFox> seb128, I have talked to ritz about releasing xchat-gnome 0.26.2 - he says he plans to finalize and commit by Wednesday.
[17:33] <LucidFox> So hopefully we'll be able to get it in before FF
[17:33] <seb128> hey LucidFox
[17:33] <seb128> ok
[17:43] <LucidFox> Is f-spot going to be demoted to universe now that shotwell is in main
[17:43] <LucidFox> ?
[17:44] <chrisccoulson> LucidFox, no
[17:56] <jono> are others finding that evolution is crashing a lot?
[18:02] <ebroder> I haven't been using it too extensively, but not really
[18:03] <jono> it is crashing every few messages for me
[18:03] <ebroder> Yeah, definitely not that bad
[18:32] <pitti> zul: can you please reupload with referring the two regression bugs in the changelog, and include all three -proposed uploads in -v?
[18:32] <pitti> zul: please check the _source.changes, it should have three records
[18:32] <zul> pitti: k
[18:33] <ScottK> pitti: Would you please rescore libmpc - need that one apparently before I need xine-lib.
[18:33] <pitti> ScottK: done
[18:34] <ScottK> pitti: Thanks.
[18:54] <zul> pitti: done
[19:00] <pitti> zul: still don't see it -- was the upload successful? (old ".upload already exists" trap?)
[19:00] <zul> gah....shakes fist
[19:31] <bdrung> how can i determine, who of the archive-admin team rejected an upload?
[19:33] <pitti> bdrung: nobody can
[19:34] <pitti> bdrung: the convention is that the archive admin sends the reason to the uploader and CC:s ubunt-archive@
[19:34] <pitti> or does a bug followup in the case of a rejected SRU
[19:34] <Laney> bdrung: are you talking about projectm?
[19:34] <bdrung> Laney: yes
[19:35] <Laney> That was ScottK: the maintainer spoke up in #-motu about this version being unsuitable
[19:35] <Laney> see scrollback there for the discussion
[19:36] <ScottK> bdrung: You were highlighted at the end of the discussion.
[19:36] <pitti> zul: was an identical double-upload, so I reject one; don't get scared
[19:36] <zul> pitti: hehe thanks
[19:36] <pitti> zul: oh, but can you please reupload with the to new bug refs in the latest changelog?
[19:37] <zul> pitti: sure
[19:37] <pitti> zul: 611101  and 611102
[19:37] <bdrung> ok, thanks
[19:41] <zul> pitti: uploaded
[19:53] <pitti> zul: thanks, looks good; can you upload to maverick, too?
[19:53] <zul> yeps as soon as im done with what im working on
[19:53] <pitti> thank you
[19:56] <pitti> so, that (hopefully) closes the 10.04.1 SRUs
[20:42] <jono> folks, evolution keeps crashing for me when I want to reply to an email, it seems to do it every few messages - I run it in a terminal but it just says it is a segfault - how can I get better debug info?
[20:42] <jono> (in Maverick)
[20:44] <BlackZ> jono: I think you could try to install evolution-dbg
[20:48] <jono> thanks BlackZ - what is that?
[20:50] <BlackZ> jono: that package contains debugging symbols for evolution, http://live.gnome.org/GettingTraces/Details
[20:54] <jono> thanks BlackZ
[21:04] <Chipzz> BlackZ: eh? why are you redirecting him to a gnome.org page when ubuntu has apport??
[21:05] <BlackZ> Chipzz: if he wants to do a bug report against the ubuntu package then he can use apport, but it's better to report it to gnome too
[21:05] <Chipzz> BlackZ: yes, but the ubuntu bug will get forwarded to gnome bugzilla anyway
[21:06] <BlackZ> Chipzz: FYI someone will have to
[21:06] <Chipzz> and someone will
[21:06] <Chipzz> but
[21:07] <Chipzz> evolution-dbg only contains debugging symbols for evolution
[21:07] <Chipzz> what if the problem is in an underlying library?
[21:08] <Chipzz> I don't know the official pov from ubuntu, but my gut feeling tells me it's better to use apport/ddebs
[21:08] <pitti> the retracers install ddebs for every depending lib
[21:08] <pitti> once the retracer kicked in and produced a good stack trace, it's ready for upstream forwarding, yes
[21:08] <pitti> before that it's just a nuisance for upstream
[21:12] <BlackZ> Chipzz: evolution-dbg will collect the useful debug *for* evolution and you have to see if with that the stack trace provides enough informations. However yes, he can use apport
[21:14] <micahg> BlackZ: not necessarily, depends on what other components are involved in the error
[21:15] <BlackZ> jono: could you please check in malone/gnome if there's a bug against that?
[21:16] <Chipzz> pitti: what's the recommended approach for filing bug reports? apport or the approach BlackZ suggested?
[21:17] <Chipzz> (as an aside, I am more than a little surprised jono of all ppl did not know about apport.. :P)
[21:17] <Chipzz> pitti: also, since jono is running maverick (a development release), shouldn't apport have been enabled by default?
[21:18] <BlackZ> micahg: exactly
[21:21] <pitti> Chipzz: the easiest is to report the crash through apport, wait until the retracer got to it, and then poke people to forward it upstream and/or fix it
[21:21] <pitti> might be something simple
[21:21] <pitti> Chipzz: yes, maverick has apport enabled
[21:23] <jono> Chipzz, I know about apport, but it is not triggering when it crashes
[21:24] <pitti> jono: do you get apport on: sh -c 'kill -SEGV $$'
[21:24] <pitti> ?
[21:24] <SpamapS> mathiaz: agreed better here...
[21:24] <SpamapS> mathiaz: so .. collectd plugins.. what would you say to splitting it into its own source package, much like php-imap does?
[21:24] <SpamapS> mathiaz: at issue is the list of MIR-needing libs .. if we can just leave the plugins that need those libs out of main .. *win*
[21:25] <mathiaz> SpamapS: both packages would have the same .orig.tar.gz though?
[21:25] <SpamapS> mathiaz: otherwise we need to pile even more stuff onto the already massive main seed.. libesmtp, libconfuse, libganglia ...
[21:25] <SpamapS> mathiaz: right
[21:25] <mathiaz> SpamapS: the other solution is to disable the unwanted plugins during build time
[21:26] <SpamapS> mathiaz: that would be a disaster
[21:26] <SpamapS> mathiaz: "We support collectd now, but we had to turn off half of the cool features."
[21:26] <SpamapS> The reason we want it in main is for uec...
[21:26] <SpamapS> so we should be able to just bring what we want for uec, into main, and leave the rest in universe.
[21:27] <mathiaz> SpamapS: right - as a monitoring agent for UEC components
[21:27] <SpamapS> one issue with that is that the plugins can only be in "suggests" ..
[21:27] <mathiaz> SpamapS: rather than a monitoring agent for instances running into the cloud
[21:27] <SpamapS> so users will install the collectd package, and then wonder why it doesn't have all the plugins they want.
[21:27] <SpamapS> But one way to get around that..
[21:28] <SpamapS> is to have collectd-basic in main .. used by uec and whatever else needs it, but then the actual 'collectd' package is in universe.
[21:28] <mathiaz> SpamapS: right - having a collectd-core in main
[21:28] <Chipzz> jono: shouldn't it? maybe you have it disabled?
[21:28] <SpamapS> core, that sounds much better. :)
[21:28] <mathiaz> SpamapS: (rather than -basic)
[21:28] <mathiaz> SpamapS: so IIRC there was a similar issue with xen
[21:29] <mathiaz> SpamapS: where xen was in main but only to have the -dev package
[21:29] <mathiaz> SpamapS: in main
[21:31] <mathiaz> SpamapS: yes - xen-3.3 is in main
[21:32] <mathiaz> SpamapS: http://packages.ubuntu.com/source/lucid/xen-3.3
[21:32] <mathiaz> SpamapS: however the hypervisor and the tools are in universe
[21:32] <jono> Chipzz, it should, I am not sure why it isn't - how do I check
[21:32] <mathiaz> SpamapS: and only libxen3-dev is in main
[21:32] <mathiaz> SpamapS: because of libvirt
[21:33] <BlackZ> agreed with pitti: you could report it with apport against the ubuntu package and then report it to upstream (gnome, in this case). But if you just want to get the debug symbols, you can use the debug symbols for the respective packages (e.g. evolution-dbg for evolution)
[21:34] <mathiaz> SpamapS: so that's another option - it may make the MIR processing easier
[21:34] <SpamapS> mathiaz: my main concern is actually just the explosion of responsibility we're accepting in main
[21:34] <micahg> BlackZ: the problem is that since we use system libs for most packages, you'll get a partial trace using the package-dbg packages
[21:36] <Chipzz> jono: if you have it disabled? I think some file in /etc/default (if I'm not mistaken)
[21:37] <jono> Chipzz, I have it now, it was removed from my panel
[21:37] <jono> thanks
[21:38] <mathiaz> SpamapS: so the collectd dependencies that would need to be promoted to main are: 'collectd', 'libdbi', 'libesmtp', 'liboping', 'memcached', 'libmemcached', 'yajl'
[21:38] <mathiaz> SpamapS: memcache is already done
[21:38] <SpamapS> mathiaz: memcached+libmemcached are already approved to main
[21:39] <mathiaz> SpamapS: libdbi on its way because of rrdtool?
[21:39] <SpamapS> mathiaz: and libdbi should make it due to rrdtool's dependence (and its relative stability)
[21:39] <SpamapS> mathiaz: libganglia1 is also needed
[21:39] <pitti> good night everyone
[21:40] <mathiaz> SpamapS: hm - right - it seems that my script fails
[21:40] <BlackZ> micahg: that's true too but not always, first we should try to collect the debug information and see if they're partial, agreed?
[21:40] <mathiaz> SpamapS: because rrd-dev is currently unstalable in maverick
[21:40]  * mathiaz tries on lucid
[21:41] <SpamapS> mathiaz: librrd-dev > 1.4 is , I think, the build-dep for the latest collectd
[21:42] <SpamapS>  librrd-dev (>= 1.4~),
[21:42] <mathiaz> SpamapS: so on lucid the list is: 'collectd', 'confuse', 'libdbi', 'libesmtp', 'ganglia', 'liboping', 'memcached', 'libmemcached', 'yajl'
[21:42] <SpamapS> mathiaz: 1.4 isn't uploaded, though I did do the merge. I think its awaiting merge-proposal-review by ubuntu-server. ;)
[21:43] <SpamapS> https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/rrdtool/merge-1.4.3-1/+merge/30675
[21:43] <mathiaz> SpamapS: it seems that libesmtp liboping could be disabled
[21:44] <SpamapS> mathiaz: liboping I believe is the baseline ping monitor. Not needed for uec, but a huge need by your average collectd user
[21:45] <mathiaz> SpamapS: the library seems quite simple - so could be easy to MIR
[21:45] <mathiaz> SpamapS: I think the main one would be ganglia
[21:45] <micahg> BlackZ: requires debugging twice, vs 1 apport crash
[21:47] <BlackZ> micahg: yeah, so as pitti said using apport is the easiest way
[21:47] <micahg> BlackZ: even if people want privacy and won't upload a coredump, they can retrace the apport crash (which can also install all the appropriate -dbgsym packages) locally, it's really an awesome tool
[21:47] <SpamapS> mathiaz: agreed, ganglia's only non main dependency is libconfuse
[21:48] <mathiaz> SpamapS: ok - and ganglia itself would be a huge effort to MIR
[21:48] <mathiaz> SpamapS: I'm not sure we want that in main
[21:49] <BlackZ> micahg: yes
[21:49] <SpamapS> mathiaz: ganglia could just have libganglia1 in main
[21:50] <mathiaz> SpamapS: yeah - that would be an option - similarly to what we do for xen
[21:50] <SpamapS> mathiaz: but I'd rather do even more to reduce the burden on main by moving the bulk of the optional plugins to a non-main package
[21:51] <mathiaz> SpamapS: well - we'd increase our burden by splitting source packages
[21:51] <mathiaz> SpamapS: as we'd have to update collectd-plugin whenever collectd is updated
[21:52] <SpamapS> mathiaz: right, I think we have more merge-bandwidth than we do security-bandwidth. ;)
[21:53] <mathiaz> SpamapS: hm - well - the split proposal is much more unusual
[21:53] <mathiaz> SpamapS: I don't know of any package where we do that
[21:54] <mathiaz> SpamapS: I'd send an email to ubuntu-devel to ask for feedback on the two options
[21:54] <mathiaz> SpamapS: I'd lean towards including ganglia into main personally
[21:56] <SpamapS> mathiaz: meh.. munin, collectd, and ganglia, all in main.. ;)
[21:58] <mathiaz> SpamapS: right
[21:58] <mathiaz> SpamapS: we'll sort things out during the next UDS
[21:58] <mathiaz> SpamapS: to get everything in order for the next LTS
[22:02] <SpamapS> mathiaz: I think we should have a *very* clear picture of what the next LTS looks like, server wise, by the end of UDS-O
[22:03] <SpamapS> mathiaz: we can't wait for P. :)
[22:06] <mathiaz> SpamapS: we should discuss that at UDS-N then
[22:07] <SpamapS> Yeah I have my UDS-N ideas brewing now. :)
[22:08] <mathiaz> SpamapS: awesome - don't forget to *capture* them
[22:09] <SpamapS> mathiaz: rememberthemilk.com is turning out to be perfect for that
[22:10] <mathiaz> SpamapS: http://brainstorm.ubuntu.com/ as well :)
[22:11] <SpamapS> mathiaz: a difficult step for me is clarify.. I'm such a pack-rat.. I never want to delete anything. ;)
[22:19] <SpamapS> can somebody who moderates ubuntu-devel please take a look at the posting I just did (clint@ubuntu.com "MIR for collectd requires some guidance") and accept/reject it. The last message I sent to ubuntu-devel sat unmoderated for 3 weeks. ;)
[22:31] <rsavoye> is there a bzr branch on launchpad for OpenJDK ?
[22:32] <rsavoye> that is the source, not just packaging files
[22:34] <SpamapS> rsavoye: I don't know where the official upstream for openjdk is, but lp:ubuntu/openjdk should be the current development package w/ the source.
[22:35] <rsavoye> there is nothing at that url, I tried
[22:35] <rsavoye> java.net has a mercurial repository, but you have to be registered to access it
[22:37] <micahg> rsavoye: apparently a default branch isn't registered for that source, can you file a bug on bugs.launchpad.net/udd ?
[22:37] <rsavoye> sure, but I need it now! :-)
[22:37] <micahg> it should be lp:ubuntu/openjdk-6
[22:38] <rsavoye> should be... openjdk6 has the packaging files, nothing else that I can find
[22:44] <micahg> seems to be stopped on bug 513215
[22:51] <rsavoye> ah, I see, it mentions openjdk-6 as an affected package. Oh well...
[22:52] <rsavoye> well, now there are two of us the bug effects :-)
[23:41] <wgrant> barry: Hi.
[23:43] <wgrant> barry: AFAICS, both system-config-printer builds have a non-None current_source_publication. That's how you're meant to get the source details.