[00:35] <cleary> hi folks
[00:36] <cleary> I'm hoping someone can help me - I'd like to change the default xsession in use on 11.04 installs to gnome-classic
[00:37] <cleary> there are a couple of complications: 1. unity needs to be left installed as an option
[00:37] <cleary> 2. since ldap will be used for authentication, ~/.dmrc is not an option
[00:41] <cleary> these are the only two options my searching has turned up - does anyone know where gdm pulls it's initial choice from?
[00:42] <cleary> a dirty way around it would be to just swap the /usr/share/xsessions/[gnome|gnome-classic].desktop entries
[00:47] <ohsix> doesn't the contents dictate the order? you could divert one of them
[00:48] <cleary> ohsix: I'm not sure what contents you're referring to?
[00:48] <ohsix> the desktop files, but i just looked and they don't
[00:49] <cleary> I can't see any debconf selection options either, gconf doesn't seem to have anything
[00:50] <ohsix> well they did it by calling unity "gnome" and classic something else, gnome is the default; hmm, i don't know what controls the order
[00:51] <Sarvatt> cleary: /etc/gdm/custom.conf?
[00:51] <cleary> Sarvatt: what would I put in it?
[00:52] <Sarvatt> [daemon]
[00:52] <Sarvatt> DefaultSession=gnome-classic maybe?
[00:52] <ohsix> bam
[00:53]  * ohsix commit to memory
[00:53] <cleary> I'll give it a shot - I didn't see that key in the gnome library
[00:53] <Sarvatt> http://library.gnome.org/admin/gdm/stable/configuration.html.en#daemonconfig
[00:55] <cleary> that's what I was reading...
[00:55] <cleary> still can't see the defaultsession key
[00:55] <Sarvatt> yeah, sorry, maybe it was removed in gnome 3?
[00:57] <ScottK> Aren't any remaining features in Gnome 3 considered bugs?

[00:57] <cleary> Sarvatt: fwiw, that seems to have worked :)
[00:58] <cleary> thanks
[00:58] <kees> hi, can an archive admin pocket-copy linux-meta-ti-omap4 from -updates to -security to match the kernel in -security?
[01:16] <slangasek> kees: that's maverick-updates?
[01:17] <slangasek> kees: done
[01:50] <highvoltage> it's a LaserJock!
[01:51] <LaserJock> hi there
[01:53] <LaserJock> highvoltage: been a while :-)
[01:54] <highvoltage> LaserJock: how are you?
[01:54] <LaserJock> oh, pretty good
[01:54] <LaserJock> thought I'd check in with my *buntu friends, spending a little time this evening doing some hacking
[01:56] <highvoltage> and that's how it starts :)
[01:57] <LaserJock> lol
[01:58] <LaserJock> kinda quiet, I guess Natty must be all wrapped up :-)
[01:59] <highvoltage> yeah that's a weird thing about this timezone :)
[02:03] <ScottK> LaserJock: Wrapped up/Broken beyond repair.  You say Tomato, I say tomatoe.
[02:05] <highvoltage> broken, maybe. beyond repair, no way!
[02:06] <LaserJock> I've been running it since Beta 1 and it's been pretty nice
[02:06] <LaserJock> I'm even having to take back some of those nasty things I said about Unity ;-)
[02:06] <ScottK> Opinions seem mixed.  As with most things.
[02:07] <LaserJock> highvoltage: I'm in Mountain time now, I'm all screwed up
[02:07] <LaserJock> ScottK: yeah, seems to be the open-source way
[02:08] <ajmitch> hi LaserJock
[02:10] <LaserJock> hi there ajmitch
[02:12] <LaserJock> I just wish things could stay around long enough to learn any of it. I was just getting used to gnome-panel and PyGTK and  now ....
[02:13] <ajmitch> there does seem to be a bit of churn over time :)
[02:15] <highvoltage> gnome-panel was the visible part of gnome that I though needed most improvements. and now that it's gone I miss it dearly.
[02:16] <LaserJock> well, I had just figured out this year how to make it work well on my netbook
[02:16] <LaserJock> oh well
[02:17] <LaserJock> this week though I was reminded how it could be a lot worse ... I tried getting a decent Ruby development platform going
[02:17] <ajmitch> so have you found some free time to return to ubuntu development?
[02:17] <LaserJock> oh, probably not much
[02:18] <LaserJock> my time away has taught me 2 things: 1) Ubuntu is just fine without me and 2) I'm so totally not a programmer
[02:18] <LaserJock> so I dunno, I love Ubuntu as always, I just don't know what I could actually contribute
[02:19] <ajmitch> I'm sure there's still plenty you (or I) could get involved in again :)
[02:22] <LaserJock> maybe
[02:25] <LaserJock> ajmitch: with all these rock starts around, I'm not sure what a couple of old buzzards like use could do ;-)
[02:26] <ajmitch> heh
[02:47]  * ScottK <--- So not a programmer either.
[02:49] <ohsix> your comments are peculiar
[02:49] <lifeless> who is, really?
[02:49] <LaserJock> lifeless: whatever, you *totally* count :-)
[02:50] <lifeless> heh :)
[02:50] <LaserJock> like, I can usually follow along the simple tutorials and can read along with several languages
[02:50] <LaserJock> but I can barely write anything useful
[02:50] <ScottK> LaserJock: You didn't get to be a core-dev because people found you unable to contribute.
[02:51] <ScottK> LaserJock: So what, most of what's needed isn't writing, but the finding and the interating.
[02:51] <ScottK> ... integrating.
[02:52] <LaserJock> I just don't know that I can keep up with packaging anymore
[02:53] <LaserJock> finding sounds ok though
[02:53] <highvoltage> LaserJock: bah, you're an old-time pro when it comes to packaging. and you literally wrote a book on it!
[02:54] <LaserJock> lol
[02:54] <LaserJock> that's because back in my day the person who got to write the book was the one asking all the dumb questions ;-)
[02:55] <ScottK> That's still the best way to do it.
[02:55] <highvoltage> I don't think I've asked all the dumb questions yet, but I'm making progress with it.
[02:57] <LaserJock> I've always loved QA, maybe I can find something to do there, who knows
[03:36] <kees> slangasek: yup, and thanks!
[04:13] <hallyn> 'apt-get source libvirt-bin' on a lucid-proposed system gives me newer result than 'bzr branch lp:ubuntu/lucid-proposed/libvirt.'  Is that something that can get kicked back into sync?
[04:59] <james_w> hallyn, not without some investigation and possibly a bug fix unfortunately
[07:17] <pitti> Good morning
[07:18] <ajmitch> morning pitti
[07:19] <pitti> hey ajmitch, how are you?
[07:24] <ajmitch> pitti: good, how are you?
[07:24] <pitti> ajmitch: quite well, thanks! preparing to move to another city soon, so my rooms look more and more like a Sokoban level
[07:25] <ajmitch> you must be busy, with it coinciding with a release :)
[07:34] <pitti> ajmitch: somewhat :)
[08:03] <didrocks> good morning
[08:52] <dholbach> good morning
[08:55] <ion> that
[09:32] <tseliot> pitti: hi, I'm going to upload nvidia-173 today as it finally works with the new xserver. I guess we'll have to re-enable it in jockey too
[09:32] <pitti> tseliot: actually no; as long as it depends on the correct X.org ABI it should be available automatically
[09:33] <pitti> that was the point of this dynamic check :)
[09:33] <tseliot> pitti: oh, right, I forgot about that. Very good :)
[09:33] <pitti> tseliot: this will also make it a lot easier to test drivers in a PPA and such
[09:33]  * tseliot nods
[10:21] <pitti> jj:q
[10:21] <pitti> sorry
[11:06] <abhinav-> Hi, can someone merge this branch ? or is it too late for natty ? https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/patch-757635/+merge/58303
[11:13] <pitti> abhinav-: seems ok, I can merge; however, the MP has a conflict in debian/changelog?
[11:14] <pitti> abhinav-: and wrong branch, we use Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/tomboy/ubuntu
[11:14] <pitti> so I'll just get the patch and apply it manually
[11:15] <abhinav-> pitti: oh , I have no clue how the conflict came in debian/changelog, although I did a few changes in the code today and pushed but didn't touch dch (perhaps edit-patch did it ?)
[11:16] <pitti> could also be some internal bzr magic
[11:16] <pitti> unfortunately bzr tries to be too clever when merging changelogs
[11:17] <abhinav-> pitti: oh , I have been struggling all the way to create this patch :-/ , thanks for taking it :)
[11:17] <pitti> kees: polkit> FYI, quilt po patch sent upstream, and changes applied to Debian git and uploaded to sid
[11:17] <pitti> abhinav-: thanks for fixing!
[11:18] <matttbe> Hello,
[11:18] <matttbe> I'm still looking for a sponsor in order to upload our cairo-dock packages on Ubuntu Natty.
[11:18] <matttbe> Is somebody can help me by uploading these packages?
[11:18] <matttbe> Bzr branches have been linked to these bugs reports and I've also joined the .debian.tar.gz generated by 'debuild' command and a link the original tarball given by the upstream.
[11:18] <matttbe>  https://bugs.launchpad.net/bugs/723994
[11:18] <matttbe>  https://bugs.launchpad.net/bugs/723995
[11:19] <matttbe> Should I have to upload something else and/or add another comment?
[11:19] <pitti> abhinav-: looks like upstream now likes it too, good work!
[11:19] <seb128> matttbe, didn't someone review that said it was not ready yesterday?
[11:19] <abhinav-> pitti: yes, they are going to merge it for next release . Thanks :)
[11:19] <matttbe> seb128: I think not
[11:20] <seb128> matttbe, jdstrand did, he mentioned it in his patch pilot summary email on the ubuntu-devel list yesterday
[11:20] <matttbe> seb128: yesterday they spoke about cairo-dock packages in Debian
[11:21] <seb128> "
[11:21] <seb128> Review/discuss at length with upstream LP: #723994 (FFe: Please update
[11:21] <seb128> Cairo-Dock to 2.3.0~0rc1 version). Not ready yet. Will provide
[11:21] <seb128> packages/packaging changes to review. Updated bug so it is more clear
[11:21] <seb128> what needs to happen to move forward."
[11:21] <seb128> he wrote
[11:21] <matttbe> yes but I've updated the bug report :)
[11:22] <seb128> oh, so your reply was confusing, seemed like you didn't know it was reviewed yesterday and now you know about it and say your updated since?
[11:23] <seb128> well anyway I will let someone who has a clue about it already did a first review sponsor ;-)
[11:23] <matttbe> yes but jdstrand said : "Matthieu, please update the other bug to more accurately reflect this (or open a new one)."
[11:23] <matttbe> I did that and nobody had reviewed it since this change
[11:24] <seb128> ok
[11:29] <matttbe> seb128: but should I have to do something else? or to contact someone in particular?
[11:29] <seb128> matttbe, no, just wait for someone to do sponsoring and pick it up
[11:30] <matttbe> seb128: ok thank you
[11:30] <seb128> your welcome, thanks for your work!
[11:42] <ogra_> pitti, ping
[11:49] <seb128> ogra_, contextless pong
[11:49] <ogra_> seb128, are you pitti ? :P
[11:49] <seb128> no
[11:49] <seb128> but contexltess pings don't have a defined receivers ;-)
[11:49] <ogra_> well, i have a udev related question
[11:50] <seb128> well just ask it? you never know maybe someone else can reply and at least pitti will have context to reply even if you are not around when he pong
[11:51] <pitti> ogra_: on phone, what's up?
[11:51] <ogra_> pitti, i need an advise for bug 746023, apparently its easily solvable by two lines to the soundcard rules in udev ... i would like to have that fixed for release but that would mean a udev upload for these two lines
[11:55] <pitti> ogra_: which rules? I don't see a patch there
[11:55] <ogra_> there is no patch yet
[11:55] <ogra_> /lib/udev/rules.d/78-sound-card.rules would need two additional lines
[11:56] <pitti> if they are generally useful and not vendor/product specific, i. e. they can go upstream, I have no objection
[11:56] <ogra_> pitti, if you say an udev upload is possible for that i'll add a debdiff (or even do the upload) i just dont want to "just upload away"
[11:56] <pitti> otherwise they can be shipped by just about any other package
[11:56] <ogra_> they are HW specific
[11:56] <pitti> ogra_: my condition for that would be that it is upstreamable
[11:56] <ogra_> and i have no arch sopecific package at all i could put them in
[11:58] <pitti> alsa-utils? well, let's see the rules first
[11:58] <ogra_> there is currently only one board that uses this sound chip, if others come the handling might have to change
[11:58] <ogra_> ATTRS{id}=="SDP4430", RUN+="alsaucm set _verb HiFi"
[11:58] <ogra_> ATTRS{id}=="SDP4430", RUN+="alsaucm set _verb Record"
[11:58] <pitti> if they are working around a kernel bug, no upstream will like them, and we can only quick fix them in natty
[11:58] <ogra_> thats the two lines needed
[11:59] <pitti> alsa-utils: /usr/bin/alsaucm
[11:59] <pitti> so they should go into alsa
[11:59] <ogra_> its not a kernel bug, arm uses alsas use case manager nowadays, you need to initialize that with the right profiles
[11:59] <pitti> udev doesn't ship alsaucm, so the rules don't make sense there
[12:00] <pitti> anyway, need to run out for a bit before the next confcall
[12:00] <ogra_> ok
[12:01] <ogra_> pitti, thanks, i'll roll an alsa patch
[12:20] <devurandom> Hi!
[12:20] <devurandom> Has anyone already noticed that there is an ugly conflict in the repositories for maverick?
[12:20] <devurandom> "linux-image-generic: Depends: linux-image-2.6.35-29-generic which is a virtual package."
[12:21] <devurandom> And also this: "libpolkit-qt-1-1: Conflicts: libpolkit-qt-1-0 (<= 0.99.0-0ubuntu1) but 0.95.1-1ubuntu1 is to be installed."
[12:27] <directhex> devurandom, which repositories do you have enabled?
[12:27] <directhex> security, backports, proposed, updates?
[12:28] <devurandom> maverick, maverick-updates, maverick-security (reading sources.list)
[12:28] <devurandom> Ah, also maverick-backports and maverick-proposed, yes.
[12:31] <devurandom> Is it possible to have a look where the offending update comes from?
[12:31] <devurandom> i.e. which repository
[12:32] <tsimpson> "apt-cache policy <package>" should tell you
[12:32] <devurandom> Ah, nice. Candidate for linux-image-generic is version 2.6.35.29.37 from -proposed
[12:33] <directhex> devurandom, proposed does this. that's why it's proposed
[12:33] <devurandom> And polkit is a kubuntu-ppa issue.
[12:33] <devurandom> directhex: Does what?
[12:33] <directhex> devurandom, blows up on missing things
[12:34] <devurandom> Well, I assume it is available to get some feedback?
[12:34] <directhex> devurandom, and not everything in proposed gets published. i'd avoid it unless testing specific stuff
[12:34] <devurandom> devurandom does this ;)
[12:34] <devurandom> Ok, so I better disable it? If I do, so, will everything be downgraded to non-proposed?
[12:35] <directhex> no, it won't
[12:35] <directhex> downgrades are never automatic
[12:35] <devurandom> Are there scripts to do it?
[12:39] <devurandom> Anyway, thanks for that suggestion, directhex!
[14:07] <stgraber> mvo: hey! Saw my update on that python-apt bug ? Apparently some templates have their type set to None ... it's now fixed
[14:11] <ogra_> stgraber, oooh, awesome !
[14:12] <stgraber> ogra_: yeah, we should hopefully have something that can be uploaded to fix your issue :)
[14:12] <tgall_foo> GrueMaster, ping
[14:12] <cjwatson> stgraber: mind if I grab bug 759545 and finish it off?
[14:12] <cjwatson> stgraber: I just committed a fix on the Debian side
[14:13] <cjwatson> stgraber: http://paste.ubuntu.com/596541/
[14:14] <dpm> mvo, are such strings supposed to go in app-install data -> https://translations.launchpad.net/ubuntu/natty/+source/app-install-data-ubuntu/+pots/app-install-data/ca/1036/+translate ? I think it sneaked in from the firefox quicklist entries
[14:17] <stgraber> cjwatson: sure, go ahead. Thanks!
[14:17] <cjwatson> stgraber: thanks for pointing out my negligence in failing to update that file :-/
[14:18] <cjwatson> stgraber: hm, though I note that the md5sum you mention isn't there; I think that this is due to the gross way we handle /etc/default/grub
[14:19] <cjwatson> I guess I'll have to do a test install to check
[14:20] <stgraber> cjwatson: yeah, the one I mentioned is what you get when installing ubuntu 10.10 server from the CD. I was trying to do a netinstall of 10.10 desktop when the language-selector issue appeared in 10.10 breaking my install :(
[14:21] <cjwatson> I would love to fix that horrible config file handling, but not for natty
[14:21] <cjwatson> the defaults aren't even constant
[14:33] <dobey> hey all
[14:34] <dobey> if i need to upload a couple patches today, what is the probability that we will actually get them on the gold CD?
[14:37] <pitti> dobey: the smaller they are, the higher the chance :)
[14:39] <dobey> of course. but you know, it's ubuntuone, and we do everything big. :)
[14:39] <pitti> dobey: in general the hurdle is pretty low today still
[14:40] <pitti> today should be the deadline for big packages such as webkit/libo, tomorrow for small packages
[14:40] <pitti> as over the Easter holidays we have little firefighting capacity
[14:42] <dobey> right. was just looking at the schedule and it says release image build is tomorrow
[14:48] <SpamapS> can somebody please take a look at the sync request bug 766879 .. it fixes the FTBFS bug 752164
[14:48] <pitti> well, tomorrow we want buildable images, right
[14:49] <pitti> fabbione_vac: happy Easter holidays :)
[14:49] <fabbione_vac> pitti: thanks dude :)
[14:50] <cjwatson> SpamapS: doing a sync run now
[14:51] <SpamapS> cjwatson: ty
[14:52] <mvo> dpm: yeah, that looks like it, I have a look
[14:53] <dpm> cool, thanks mvo :)
[15:05] <pitti> SpamapS: congrats, you now have +queue access :)
[15:05] <SpamapS> pitti: \o/
[15:05] <soren> SpamapS: Click something!
[15:05] <pitti> SpamapS: (shameless plug) want to exercise it on the postgresql update? :-)
[15:05] <james_w> click /everything/
[15:06]  * stgraber turns off unattended-upgrade for the time being :)
[15:06] <pitti> SpamapS: in fact, I'd appreciate reviewing/accepting the maverick one, that saves me from having to upload the orig.tar.gz for lucid all over again
[15:06] <SpamapS> stgraber: I <heart> u too ;-)
[15:06]  * pitti hands SpamapS a ♥
[15:07]  * SpamapS is reviewing the postgres sru now
[15:07] <stgraber> SpamapS: that was in case you follow james_w's recommendation :)
[15:08] <SpamapS> stgraber: his demos are so good, why not just blindly follow his advice?
[15:08] <SpamapS> pitti: whats the hold up on the natty fix?
[15:08] <pitti> SpamapS: doing it right now
[15:08] <pitti> SpamapS: I thought I could do a sync, but I can't
[15:09] <stgraber> SpamapS: ;)
[15:09] <SpamapS> pitti: <christopher walken voice>damn</voice>
[15:11] <stgraber> SpamapS: http://paste.ubuntu.com/596557/
[15:11] <pitti> SpamapS: likewise, once the maverick one is accepted, I don't need to reupload the orig all over again for natty as well :)
[15:12] <SpamapS> stgraber: that was for IE6
[15:13] <SpamapS> it plays fast and loose with tag names
[15:13] <SpamapS> pitti: well I trust you then that you'll get natty fixed soon. :)
[15:13] <cnd> I'm trying to dput to ubuntu, but it's saying the gpg sig is bad
[15:13] <cnd> I've never had this issue before
[15:13] <pitti> SpamapS: postgresql-8.4_8.4.8-0ubuntu0.11.04_source.changes is ready to be dput :)
[15:13] <cnd> is there something odd going on with lp right now?
[15:14] <soren> cnd: Yeah, SpamapS just got access to a bunch of things. Brace yourself.
[15:14] <soren> (jk)
[15:14] <pitti> cnd: in freeze times it always costs a beer for the release team before it accepts it
[15:14] <cnd> pitti, shouldn't I still be able to upload to the queue?
[15:15] <pitti> cnd: LP just has liked to whine a bit in the past few weeks, but don't worry, it'll work anyway
[15:15] <cnd> pitti, oh? so I can ignore the error?
[15:15] <pitti> cnd: well - I can say that _so far_ it has worked for everyone else who had the bug :)
[15:15] <cnd> pitti, ahh, just got the emails back
[15:16] <cnd> I tried three times, so I dunno if that means there's three copies in the queue...
[15:16] <pitti> cnd: yes, there will
[15:16] <cnd> pitti, sorry bout that :(
[15:16] <pitti> cnd: np; I just rejected two
[15:17] <cnd> thanks!
[15:17] <SpamapS> pitti: alright, done. :)
[15:17]  * SpamapS goes to have breakfast now
[15:18] <pitti> SpamapS: cheers; lucid/natty uploaded
[15:18] <pitti> SpamapS: ah, did you run the sru-accept command now?
[15:39] <GrueMaster> tgall_foo: pong
[15:46] <tgall_foo> GrueMaster, for testing sound (in this case on arm hardware) do you have any particular recommendations ? Generally I'm just trying out things like speaker-test, aplay, xmm2 ...   sound reasonable ?
[15:47] <dobey> SpamapS: are you the reason that dput is breaking for me now? :)
[15:47] <GrueMaster> That's where I start.  Go with the lowest variables first.  For example, on omap (beagle, beagleXM), audio is muted by default and the pulseaudio mixer doesn't fix it.  But you can enable it through alsamixer and play sound through speaker-test
[15:49] <tgall_foo> yeah we're thinking we're going to include an asound.test with the levels set correct as partof the images to avoid that problem ...   but to date adjusting the levels hasn't yielded any audio
[15:49] <dobey> SpamapS: http://pastebin.ubuntu.com/596574/
[15:52] <GrueMaster> tgall_foo: Which platform are you referencing?
[15:52] <ogra_> omap4 sound should be fixed with next alsa-utils upload
[15:53] <ogra_> omap3 likely needs the same bits in natty
[15:53] <pitti> dobey: just ignore it; it'll work anyway
[15:53] <tgall_foo> ogra_, yes I saw the bug update for that
[15:53] <tgall_foo> ogra_, great work!
[15:53] <pitti> dobey: I'll reject one of your two ubuntuone-client uploads
[15:53] <tgall_foo> GrueMaster, panda, beagle xm and beagle C are the 3 I care about most
[15:54] <GrueMaster> Well, for panda, we have some ucm fixes that make it work.
[15:54] <dobey> pitti: ah ok. guess i checked the queue too quickly
[15:54] <ogra_> kirkland, even when setting FRONTEND_BACKGROUND=legacy on the kernel cmdline i get the violet colors in screen ... should i see a difference ?
[15:55] <kirkland> ogra_: screen shot?
[15:55] <kirkland> ogra_: try FRONTEND_BACKGROUND=dark
[15:55] <kirkland> ogra_: and FRONTEND_BACKGROUND=original
[15:55] <ogra_> kirkland, trying to get you the screenshots for bug 747229 ... note that we use oem-config-debconf there, not d-i though
[15:58] <GrueMaster> tgall_foo: See bug 746023.  It has fixes for panda.  As to omap (beagle, beagleXM) I am going to see if I can write a set of UCM rules for it as well.
[16:01] <ogra_> kirkland, doesnt change a thing, i suspect oem-config doesnt respect that var on cmdline
[16:01] <chrismat> I want to create a .deb file that copies everything from a directory called texmf into /usr/local/texmf
[16:01] <chrismat> how do I do that?
[16:01] <kirkland> ogra_: hmm, i guess not
[16:01] <kirkland> ogra_: how is it different than d-i?
[16:01] <cjwatson> kirkland: oem-config uses debconf, not cdebconf
[16:01] <ogra_> kirkland, though i'm pretty sure i saw the issue before the theme was changed
[16:02] <cjwatson> I wonder if we need to call setvtrgb inside bterm
[16:11] <Sarvatt> YokoZar: do you by any chance have any plans to update ia32-libs again? https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/755720 is a pretty major problem and already fixed on the mesa side but needs to be updated in there
[16:23] <SpamapS> pitti: I did sru-accept for maverick, will do lucid shortly
[16:23] <pitti> SpamapS: splendid, thanks
[16:31] <SpamapS> pitti: accepted lucid and hardy as well now
[16:31] <yofel> pitti: can we get the fix for bug 765808 into natty?
[16:32] <pitti> SpamapS: thanks
[16:32] <pitti> yofel: yep, will look at it ASAP
[16:33] <\sh> pitti: ping pygobject Gtk.Dialog and AttributeError: type object 'DialogFlags' has no attribute 'MODAL' ... do you have any clue what this error occurs on natty...
[16:33] <\sh> s/what/why/
[16:34] <pitti> \sh: (@phone, bbl)
[16:36] <pitti> $ python -c 'from gi.repository import Gtk; print Gtk.DialogFlags.MODAL'
[16:36] <pitti> <flags GTK_DIALOG_MODAL of type GtkDialogFlags>
[16:36] <pitti> \sh: ? do you have a reproducer?
[16:37] <\sh> pitti, http://paste.ubuntu.com/596595/ <- could be that I'm the one is wrong, but I doubt so
[16:37] <\sh> it complains in  File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 358, in __init__
[16:37] <\sh>     if flags & Gtk.DialogFlags.MODAL:
[16:37] <pitti> \sh: sorry, I don't see "MODAL" there at all?
[16:37] <\sh> pitti, see ;)
[16:38] <maxb> What's a good place to ask about debian-installer preseeding ubuntu-specific issues? (I'm wondering if it's known that auto=true doesn't seem to have the desired effect in Ubuntu)
[16:38] <pitti> \sh: ah -- import appindicator
[16:38] <pitti> don't do that, it imports "gtk"
[16:39] <pitti> \sh: you need to use GI for appindicator as well
[16:39] <\sh> pitti, from gi.repository import appindicator?
[16:39] <pitti> \sh: AppIndicator
[16:41] <cjwatson> maxb: I think I vaguely know that I've never got round to enabling that
[16:41] <cjwatson> maxb: (#ubuntu-installer, in general)
[16:42] <maxb> cjwatson: Thanks. I assume it not-working is fallout from Ubuntu using console-setup, when Debian doesn't?
[16:42] <stgraber> mvo: so any chance of seeing a new python-apt uploaded today (based on discussion in -meeting) ? :)
[16:43] <mvo> stgraber: yes, I check it out after the meeting, thanks for your update on it
[16:44] <stgraber> mvo: great thanks! I'm sure ogra_ is looking forward to finally having this bug solved ;)
[16:44] <ogra_> ++
[16:44] <ogra_> \o/
[16:45] <cjwatson> maxb: no, auto-install was always a separate component
[16:45] <cjwatson> maxb: though it's possible it's never been properly hooked into console-setup, granted
[16:46] <maxb> The "Ubuntu Installation Guide" is an interesting creature. You have to read between the lines interpreting which bits are unmodified from Debian an thus may not apply :-)
[16:58] <jamespage> kirkland, elmo: the version of etherpad in ppa:etherpad/ppa is prob as good as its going to get pre-UDS
[16:59] <jamespage> Daviey and I have worked on pulling in a few key patches today but it looks OK.
[17:05] <pitti> zul: rejecting N-1 of your many nut uploads
[17:11] <SpamapS> can somebody explain why this is a "failed to build": https://launchpadlibrarian.net/70014536/buildlog_ubuntu-natty-amd64.python-drizzle_1.0-2_FAILEDTOBUILD.txt.gz
[17:11] <SpamapS> Looks almost identical to the i386 build log
[17:16] <doko> Spads: it deliberately rejected
[17:19] <Spads> ^-- SpamapS
[17:19] <doko> SpamapS: PyCObject was removed in 3.2
[17:23] <jhunt> cjwatson, SpamapS: lp:ubuntu/upstart is showing as last modified "4 weeks ago"...?
[17:26] <SpamapS> doko: right so how did it build on i386 and not amd64 ?
[17:27] <doko> SpamapS: pretty sure that it did build, but will fail to load due to undefined symbols
[17:27] <SpamapS> jhunt: http://package-import.ubuntu.com/status/upstart.html#2011-03-26 09:47:55.356196
[17:27] <SpamapS> doko: interesting
[17:27] <SpamapS> well I suppose the right thing to do is just disable the python3 bits then
[17:28] <SpamapS> I believe swig has only *just* gotten 3.2 support
[17:28] <doko> if it cannot be fixed, yes
[17:28] <SpamapS> like.. 9 days ago http://sourceforge.net/tracker/?func=detail&atid=101645&aid=3057804&group_id=1645
[17:30] <jhunt> SpamapS: hmm. that tag certainly isn't there, but I'm wondering how it worked for the 5 previous changes?
[17:30] <jhunt> SpamapS: I really need the bzr repo to be correct as we have 1 more change to make to upstart for natty.
[17:31] <SpamapS> jhunt: you can just do an apt-get source
[17:31] <SpamapS> "old school" ;)
[17:31]  * SpamapS has started noticing more and more udd failures that make it less and less useful. :-/
[17:31] <jhunt> SpamapS: I'm guessing I should have tagged the ubuntu branch and just haven't been doing so.
[17:32] <cjwatson> jhunt: if you have a branch that's closer to reality, tag it and 'bzr push --overwrite lp:ubuntu/upstart'
[17:33] <cjwatson> jhunt: or, actually, you'll need to point SpamapS or me at it and have us do that
[17:33] <jhunt> cjwatson: ok, I think all that reality is missing is the tag(s).
[17:33] <cjwatson> jhunt: I think for the ones I sponsored, I probably set the tag
[17:33] <cjwatson> maybe SpamapS didn't
[17:33] <jhunt> cjwatson: ok, sorry. didn't realise I should have been tagging.
[17:33] <SpamapS> I didn't actually merge into the branch
[17:33] <SpamapS> I thought uploading would do so
[17:34] <cjwatson> no, uploading will (at best) construct a new tree with the same contents, based on whatever was previously in lp:ubuntu/upstart
[17:34] <cjwatson> you should actually merge
[17:34] <SpamapS> cjwatson: *ahhh*
[17:34] <cjwatson> it doesn't know where to merge from ...
[17:35] <jhunt> SpamapS: can I leave you to resolve as I'm trying to get a fix for bug 767053 out kinda "now" :)
[17:35] <SpamapS> Ok so we can fix it by just importing the packages that aren't properly represented and then overwriting?
[17:35] <cjwatson> SpamapS: is there an existing branch which is correct?  point me to it and I'll fix it up
[17:36] <SpamapS> cjwatson: I don't believe there is one with the appropriate tags.
[17:36] <cjwatson> I don't care about that
[17:36] <jhunt> SpamapS, cjwatson: why is it looking for tag upstream-0.9.4
[17:36] <cjwatson> is there an existing branch with the right content history?
[17:36] <SpamapS> but the content is correct in ...
[17:36] <cjwatson> jhunt: forget about that
[17:36]  * SpamapS grabs it
[17:37] <cjwatson> jhunt: (get james_w to explain it properly at some point, but we don't need to worry about it at the moment)
[17:37] <jhunt> cjwatson: ack! :)
[17:37] <SpamapS> lp:~clint-fewbar/ubuntu/natty/upstart/fix-chroot-sessions
[17:37] <SpamapS> cjwatson: ^^ thats what was uploaded
[17:38] <cjwatson> SpamapS: so in a checkout of that: 'bzr tag; bzr push lp:ubuntu/upstart'
[17:38] <cjwatson> er, push --overwrite
[17:38] <SpamapS> I did not need overwrite for some reason
[17:39] <SpamapS> jhunt: check lp:ubuntu/upstart now
[17:39] <cjwatson> oh, yeah, you wouldn't need --overwrite if the auto-import failed
[17:40] <jhunt> SpamapS: awesome, thx!
[17:41] <SpamapS> cjwatson: debcommit --release should do the tag part for me should it not?
[17:43] <cjwatson> SpamapS: normally yes
[17:48] <matttbe> Hello everybody,
[17:48] <matttbe> I'm still looking for a sponsor in order to upload our cairo-dock packages on Ubuntu Natty.
[17:48] <matttbe> Of course bzr branches have been linked to these bugs reports and I've also joined the .debian.tar.gz generated by 'debuild' command and a link the original tarball given by the upstream.
[17:48] <Daviey> matttbe: is there a merge proposal?
[17:49] <matttbe> Daviey: yes but it seems that cairo-dock-plug-ins bzr branch is broken
[17:49] <zul> pitti: thanks i was having problems locally
[17:50] <pitti> zul: LP complaining about invalid keys? :-)
[17:50] <matttbe> Daviey: and the cairo-dock bzr branch has a lack of tags... but branches are there
[17:50] <zul> pitti: how did you guess? :)
[17:50] <matttbe> this is why I've joined other files
[17:51] <matttbe> Both packages seem ready, I've tested them a lot. This version is used on our ppa and on our repository. So... we just need somebody to upload these two packages (cairo-dock and its plug-ins)
[17:51] <matttbe> https://bugs.launchpad.net/bugs/723994
[17:51] <matttbe> And for our plug-ins:
[17:51] <matttbe> https://bugs.launchpad.net/bugs/723995
[17:51] <pitti> zul: because that seems to affect half of the developers
[17:51] <pitti> with "half" varying depending on the moon phase
[17:51] <Daviey> matttbe: so, the debdiff on comment 4 is what you want?
[17:51] <matttbe> Should I have to upload something else and/or add another comment?
[17:51] <zul> pitti: hehe
[17:51] <pitti> zul: it complains, but it works anyway
[17:51] <zul> pitti: odd isnt it
[17:52] <matttbe> Daviey: sorry, I've joined this debdiff but it was for the rc1 release
[17:52] <matttbe> but I can recreate this debdiff for the final release
[17:52] <cjwatson> pitti: unless you're using dupload, in which case it breaks
[17:52] <cjwatson> (slightly stricter error handling, presumably)
[17:53] <Daviey> matttbe: yeah, i think it's kinda confusing... there are multiple things there.. debdiff from current natty archive would help.
[17:53] <matttbe> Daviey: this is why I asked here if I had to join another file because everything is there (the original tarball, a bzr branch and the debian directory)
[17:53] <matttbe> Daviey: Ok, I'll do that asap!
[17:53] <Daviey> matttbe: yup.. seems you've been doing all the correct things!
[17:54] <cjwatson> psurbhi: oh, hm, I said in my to-do list in the meeting that I was going to look at bug 764893, but I see you just assigned it to yourself - are you already working on it?
[17:54] <cjwatson> psurbhi: happy to review etc.
[17:54] <Daviey> matttbe: if you debdiff from cairo-dock-plug-ins 2.2.0~4-0ubuntu4 -> what you want, that would help.
[17:55] <matttbe> Daviey: ok thank you :)
[17:55] <Daviey> matttbe: let me know when you have done that, and i'll have a poke.
[17:55] <matttbe> Daviey: great thank you!
[17:57] <pitti> yofel: merged, uploading now; thanks!
[18:15] <CodeGnome> Is this the right channel to talk about non-maintainer uploads?
[18:15] <cjwatson> CodeGnome: Ubuntu doesn't have that concept
[18:16] <CodeGnome> cjwatson: Well, even if it's called something else, there are certainly people who maintain packages in Ubuntu, and people without commit access to them.
[18:17] <cjwatson> CodeGnome: calling that a non-maintainer upload would be misleading even in Debian - all Debian developers have *technical* ability to upload anything, the restriction is just social
[18:17] <cjwatson> CodeGnome: perhaps you could rephrase your question to say what you actually want, anyway
[18:18] <CodeGnome> The password-gorilla packages are two years out of date. It needs to be repackaged. I'm not a committer for the package. Whatever you want to call it, what's the process?
[18:19] <cjwatson> CodeGnome: https://wiki.ubuntu.com/SponsorshipProcess
[18:19] <seb128> do you want to do the work or just to point that it needs an update
[18:19] <cjwatson> CodeGnome: also, it would be significantly better to get the package updated in Debian first, and then we can just sync it and more people benefit
[18:20] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622398 was filed last week
[18:20] <infinity> CodeGnome: What's the current upstream version?  Sid has 1.5.3.4
[18:20] <infinity> CodeGnome: If Debian is in sync with upstream, this problem will be self-correcting in Ubuntu in a week or two.
[18:20] <CodeGnome> seb128: I don't mind doing the work, but there are some real peculiarities to how this was originally packaged. There are the real sources, the ubuntu launchpad sources, and the debian packages.
[18:20] <cjwatson> heh, Patrick forgot to close the bug with that upload
[18:20] <infinity> (ie: when the next release opens and we re-sync)
[18:21] <cjwatson> yeah, that'll happen automatically
[18:21] <seb128> CodeGnome, so what cjwatson said
[18:21] <infinity> CodeGnome: There are no "launchpad sources" in the sense that we've forked it from Debian (we haven't).
[18:21] <infinity> CodeGnome: And Debian is in sync with the latest upstream.  We're just in a relese freeze right now.
[18:22] <infinity> CodeGnome: So, when our next release opens, you'll have the latest version synced from Debian, no need to do anything.
[18:22] <CodeGnome> Well, there sort of is. What's lp:ubuntu/password-gorilla if it isn't the launchpad fork?
[18:22] <cjwatson> CodeGnome: it's an exact copy of a previous Debian version.
[18:22] <cjwatson> that's not a fork by anyone's standards
[18:22] <infinity> ^
[18:23] <cjwatson> shortly after we open oneiric, we'll automatically sync in all changes from Debian to packages that didn't have Ubuntu modifications (and manually go through merging any that did have Ubuntu modifications)
[18:23] <CodeGnome> Well, fair enough. I was told that there were issues getting the latest version packaged in Debian. I'm not a Debian maintainer, so I thought I'd handle it in Ubuntu instead. Guess it's not necessary for this particular package.
[18:23] <cjwatson> CodeGnome: there may have been, but it got updated in Debian yesterday
[18:24] <cjwatson> so those issues seem to be in the past
[18:24] <CodeGnome> cjwatson: Ah. Well, fair enough. :)
[18:25] <cjwatson> the reason we try to avoid doing that kind of thing independently is that it usually ends up resulting in more manual work in the future; although the possibility's there if there's a pressing need
[18:25] <cjwatson> (i.e. Debian would likely do it at some point, and then we'd have to figure out how to merge)
[18:26] <cjwatson> for a single package this isn't too hard, but it gets pretty scary when you multiply it up by the number of packages we ship
[18:26] <CodeGnome> Debian is sometimes several years behind on certain packages, though. Doing NMUs for Debian is a bit of a hassle. :/
[18:26] <cjwatson> right, but redirecting that effort into Ubuntu is not *necessarily* a good use of time
[18:27] <CodeGnome> cjwatson: I can see your point. I'm not arguing it; I just had an itch to scratch, but it looks like someone else already scratched it. :)
[18:27] <infinity> And, to be fair, if a maintainer is literally years behind on a package and can't seem to make a coherent technical argument as to why, I'd tend to consider it abandoned and fair game for NMUs in Debian.
[18:28] <matttbe> Daviey: .debdiff are available! :)
[18:28] <CodeGnome> infinity: You still need to get sponsored to do NMUs, though, don't you? I had a very, very frustrating experience with that a few years back, and haven't bothered with Debian upstream packaging since.
[18:29] <infinity> CodeGnome: Sponsored in Debian, or sponsored in Ubuntu, causing Ubuntu to carry a painful diff (or just offloading the work on Ubuntu devs to push the change back to Debian)... The former still sounds more pleasant.
[18:29] <matttbe> Daviey: LP: #723994 and LP: #723995
[18:30] <infinity> CodeGnome: As Colin says, we do sometimes fork packaging for either technical reasons or "bleeding edge versions", but those occasions are few, far between, and fairly carefully considered.
[18:30] <Daviey> matttbe, thanks
[18:30] <CodeGnome> Alright. So, for the most part, packages need to be pushed on the Debian side. Got it.
[18:31] <infinity> CodeGnome: Ideally.  Exceptions to every rule and all that, but we prefer it that way.
[18:32] <CodeGnome> Thanks for the help, guys.
[18:37] <bdmurray> pitti: have you uploaded apport yet?  I have a change yet
[18:38] <pitti> bdmurray: uploaded yes, but not accepted yet
[18:38]  * pitti needs to run now, have a good night!
[18:45] <Daviey> matttbe, I'm kinda confused... the debdiff for cairo-dock upstream code differs from the upstream tarball.
[18:45] <Daviey> (ignoring debian/ for the moment)
[18:45] <matttbe> oh
[18:46] <matttbe> Daviey: yes but if I used "bzr merge-upstream" it deletes the debian directory
[18:46] <matttbe> Daviey: I don't know if it's linked
[18:46] <Daviey> matttbe, no.. ignore debian/ for the moment... just the upstream code
[18:48] <matttbe> Daviey: I download the old version (2.2.0) with apt-get source. And I used the .dsc generated with debuild with files from my bzr branch
[18:48] <Daviey> matttbe, let me try again... maybe i made an error.
[18:49] <matttbe> Daviey: do I have to add some parameters next to the debdiff command?
[18:49] <Daviey> no
[18:50] <matttbe> This is what I did: debdiff cairo-dock-plug-ins_2.2.0~4-0ubuntu4.dsc ../build-area/cairo-dock-plug-ins_2.3.0~1-0ubuntu1.dsc > cairo-dock-plug-ins_2.2.0~4-0ubuntu4_-_2.3.0~1-0ubuntu1.debdiff
[18:50] <Daviey> matttbe, okay, give me a few mins.
[18:50] <matttbe> Daviey: ok thank you!
[18:55] <Daviey> matttbe, http://pb.daviey.com/mQNV/raw/  the binary files are fine... but the translations and such?
[18:56] <matttbe> Daviey: this file (en.po) is now a symbolic link ;)
[18:57] <Daviey> Ahh!
[18:58] <Daviey> matttbe, suprised the debdiff didn't represent that
[18:58] <matttbe> Daviey: oh, strange
[18:59] <matttbe> Daviey: it should have a symbolic link from en_GB.po to en.po
[19:02] <matttbe> Daviey: but there is this line: [19:02] <matttbe> at the end of your file
[19:03] <Daviey> matttbe, Okay... happy with that... regarding debian/ it looks good.  A few comments... you've added quilt as a build depends and cdbs entries for quilt and patchsys... you have made the packge source format 3.0 (quilt).. you don't need that - as you get it for free
[19:04] <Daviey> matttbe, also, you have two debian/changelog entries... two of which are both UNRELEASED.... the top one is fine, as i can change that when uploading.. but the second is odd as it was never in the archive... Do you want me merge them together.. or i am happy to?
[19:05] <matttbe> Daviey: so can I remove the cdbs entries for quilt?
[19:05] <Daviey> matttbe,yeah
[19:05] <matttbe> Daviey: yes, you can do what you want :)
[19:05] <Daviey> matttbe, infact, you can drop cdbs altogther, as the only remaining one is debhelper
[19:06] <matttbe> Daviey: ok, thank you for this note :)
[19:07] <matttbe> Daviey: about the debian/changelog, I didn't know what to do
[19:21] <Daviey> matttbe, can you ack http://pb.daviey.com/OGwB/raw/ and i'll upload it?
[19:23] <matttbe> Daviey: perfect :)
[19:36] <ohsix> anyone have some pointers on how to add a media player to the indicator menu that shows controls for them? is that mpris?
[19:36] <ohsix> pithos is nice, i'd like to add what i can to get it to show upthere
[19:39] <Daviey> matttbe, Okay, regarding the plugins... http://pb.daviey.com/TXnW/raw/  - 2.2.0~4-0ubuntu4 changelog is edited aswell?   depends - python/valac/ruby/mono all new?
[19:40] <matttbe> Daviey: about the changelog, it's strange that there is a diff for this version 2.2.0~4-0ubuntu4!
[19:40] <matttbe> but I don't know why
[19:41] <matttbe> it's maybe because I used the version of the my previous bzr branch, sorry for that!
[19:42] <matttbe> about the debian/control file, yes, python/valac/ruby/mono all new => it's to create an interface for these languages
[19:42] <Daviey> matttbe, no worries... if you can give me merged updated debian/changelog for the two versions... just pastebinit... i'll put it in.
[19:42] <matttbe> Daviey: ok!
[19:43] <Daviey> matttbe, I am a little nervous about all the new depends, but i'll defer that to the release team.
[19:44] <matttbe> Daviey: no worry, it's just a few new depends for the build process, not for the user
[19:44] <Daviey> ok
[19:49] <matttbe> Daviey: this is the diff http://pastebin.com/6dScE6d9 and the file: http://pastebin.com/h7dS8GRZ
[19:57] <Daviey> matttbe, uploaded both
[19:57] <matttbe> Daviey: many thanks!!! :)
[19:58] <cjwatson> pitti: you demoted xulrunner-2.0 yesterday morning, but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is showing it as a promotion candidate due to a build-dependency from packagekit
[20:01] <chrisccoulson> cjwatson, it's an alternative build-depend
[20:01] <chrisccoulson> (ie, firefox-dev | xulrunner-dev)
[20:02] <chrisccoulson> oh, actually, it is "xulrunner-dev | firefox-dev"
[20:02] <cjwatson> chrisccoulson: hmm, germinate wouldn't normally pick it up in that case, and yet it is ...
[20:02] <cjwatson> chrisccoulson: OK.  Can we flip that?
[20:02] <cjwatson> or is that ordering appropriate?
[20:02] <chrisccoulson> cjwatson, it's like that to keep the packaging in sync with debian, i think
[20:03] <chrisccoulson> the debian build uses xulrunner-dev
[20:03] <cjwatson> it's possible that we could fix it up with an explicit seed
[20:03] <cjwatson> if you'd rather keep it that way, I can experiment ...
[20:07] <chrisccoulson> cjwatson, i don't mind really. comments 43 - 46 in bug 740815 explain the current implementation though
[20:09] <YokoZar> Sarvatt: ok, I'll start on an update tonight
[20:37] <Ampelbein> pitti: the latest apport fails to install here with http://paste.ubuntu.com/596662/ but I can't see what is wrong. any hints on debugging that?
[20:44] <smoser> what shoudl i build-depend on to use dh --with python2 ?
[20:44] <Ampelbein> smoser: I think dh_python2 is integrated in the python package
[20:46] <sladen> pitti: Seen this before?  1k/2k550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"] : Permission denied.
[20:49] <sladen> pitti: (the signature is valid)
[20:51] <smoser> Ampelbein, thanks.
[20:56] <Laney> sladen: is that at dput time? I think that's a Launchpad issue if so
[20:58] <sladen> Laney: filed as https://bugs.launchpad.net/launchpad/+bug/767595
[20:59] <cjwatson> sladen: we've been having this for some days
[20:59] <cjwatson> sladen: lifeless knows about it
[21:00] <Laney> yeah it's definitely a known issue
[21:01] <Quintasan> https://lists.ubuntu.com/archives/sounder/2004-August/000000.html
[21:01] <Quintasan> :D
[21:03] <sladen> Quintasan: a lesson in how First Post! might land you a job
[21:06] <Quintasan> sladen: ha ha, as if :D
[21:07] <cjwatson> dashua: FYI, the light-themes rejects you may get by mail were just for the duplicates in the queue (see discussion of Launchpad bug above); I'm letting somebody with more desktop experience do the actual review
[21:21] <broder> hmm...would it be difficult to pre-populate natty-{security,updates} pockets on ddebs.u.c? do-release-upgrade got unhappy at me for having maverick-* in my sources.list
[21:27] <stgraber> pitti: apparently apport doesn't like being disabled :)
[21:28] <stgraber> pitti: its init script now fails and blocks the update. Setting it back to enabled manually unblock the update process.
[21:29] <cjwatson> bug 767498
[21:29]  * highvoltage wonders if cjwatson knew that bug number without having to look it up
[21:29] <cjwatson> no
[21:29] <kees> is the change in dh_installinit expected?
[21:30] <stgraber> I'm wondering if we shouldn't just make pre-start work in all cases and just do nothing if apport is disabled ? not sure what the old behavior was though
[21:30] <kees> or should apport's pre-start be changed to exit 0 when ! $enabled ?
[21:32] <SEJeff_work> is there a ppa with gtk3 for maverick?
[21:32] <SEJeff_work> So I can build some gtk3 apps on maverick without resorting to jhbuild
[21:33] <cjwatson> stgraber,kees: or perhaps --error-handler=true ...
[21:33] <kees> cjwatson: yeah, that might be the better approach, since "start" really should fail if it's disabled, imo
[21:34] <cjwatson> kees: IIRC, it might need to be '|| { stop; exit 0; }' or some such, if we were going for exit 0
[21:34] <cjwatson> though I'd have to check - error-handler is simpler
[21:34] <stgraber> yeah, I guess it makes sense for start to fail when the service is disabled as it didn't start :)
[21:35] <cjwatson> does one of you want to take care of this, or should I?
[21:35] <cjwatson> if somebody else does, I can accept it through the queue :-)
[21:36] <stgraber> I can do it
[21:44] <ScottK> pitti: Are you aware of problems with the latest apport update:
[21:44] <ScottK> Setting up apport (1.20.1-0ubuntu3) ...
[21:44] <ScottK> start: Job failed to start
[21:44] <bdmurray> ScottK: its being fixed
[21:45] <ScottK> bdmurray: Thanks.
[21:47] <superm1> ScottK, for now if you enable apport in /etc/default/apport and then apt-get -f install it's fine
[21:56] <ScottK> superm1: Thanks.
[21:59] <barry> hi all.  is there still time, and are any sponsors available for a no-change rebuild to eliminate a mod_python error log message?
[22:16] <Sweetshark> good evening! reporting in to receive a good slapping for bug 740815.
[22:17] <Sweetshark> anyone having an idea why "xulrunner-dev | firefox-dev" in libreoffice/libreoffice-l10n does not get me on the component-mismatches page?
[22:18] <Sweetshark> cjwatson: ^^
[22:20] <cjwatson> Sweetshark: it probably depends on which seed germinate happens to encounter your package in - if it encounters it in a context where some other package has already pulled in firefox-dev, then it will use that
[22:21] <cjwatson> alternative build-dependencies are unstable if they aren't consistent
[22:21] <cjwatson> packagekit is a transitive build-dependency of some very low-level stuff - it gets pulled in while trying to expand the build-dependency tree of the kernel
[22:21] <cjwatson> I wouldn't expect that libreoffice is in that situation
[22:23]  * Sweetshark mumbles: no, its at the end of the foodchain and rather stumbles over surprise changes in packages below it ;)
[22:24] <Sweetshark> cjwatson: would you say it is critical to change the build-dep order for the release?
[22:28] <cjwatson> Sweetshark: not for LO, no
[22:29] <Sweetshark> cjwatson: I just looked in the buildlog and it is indeed using firefox-dev ....
[22:29] <Sweetshark> cjwatson: good, thanks.
[23:36] <bdmurray> stgraber: there are still some apport bugs coming in with that new package version bug 767790
[23:37] <bdmurray> kees: any ideas?
[23:38] <bdmurray> oh, that's still the old one - my bad
[23:48] <Andy80> hi all