[01:47] <mwhudson> is this a good place to ask upstart questions?
[01:47] <slangasek> yes, though not the ideal time :)
[01:48] <mwhudson> i guess that
[01:49] <mwhudson> slangasek: do you know things about job instances?
[01:49] <slangasek> yes
[01:49] <mwhudson> so we have a lava-instance job that has
[01:49] <mwhudson> instance $LAVA_INSTANCE
[01:49] <mwhudson> and lava-instance-uwsgi that has
[01:50] <mwhudson> instance $LAVA_INSTANCE
[01:50] <mwhudson> start on starting lava-instance
[01:50] <mwhudson> stop on stopping lava-instance
[01:50] <mwhudson> when we do start lava-instance LAVA_INSTANCE=foo a lava-instance-uwsgi instance with LAVA_INSTANCE=foo is started
[01:51] <mwhudson> when we do stop lava-instance LAVA_INSTANCE=anything, all lava-instance-uwsgi jobs stop
[01:51] <slangasek> hmm, really?
[01:51] <mwhudson> i guess this isn't so surprising, and we should say stop on stopping lava-instance LAVA_INSTANCE=$LAVA_INSTANCE ?
[01:51] <slangasek> oh
[01:51] <mwhudson> slangasek: well, that's what seems to happen
[01:51] <slangasek> try 'stop lava-instance anything' instead
[01:52] <mwhudson> uh really?
[01:52] <slangasek> IIRC yes
[01:52] <mwhudson> stop: Env must be KEY=VALUE pairs
[01:52] <slangasek> oh, n/m, I think I see the issue
[01:52] <slangasek> lava-instance-uwsgi should be
[01:53] <slangasek> stop on stopping lava-instance LAVA_INSTANCE=$LAVA_INSTANCE
[01:53] <mwhudson> ok
[01:53] <mwhudson> thats what i was leaning towards suspecting
[01:53] <mwhudson> or something like that
[01:54] <mwhudson> slangasek: it's slightly funny that the instance-ness propagates 'down'
[01:54] <mwhudson> but i guess that's because there are really environment variables involved here?
[01:54] <slangasek> yes, there are
[01:54] <slangasek> well, at some stages ;)
[01:54] <slangasek> at other stages it's just key,value pairs being passed in a dbus call
[01:54] <mwhudson> and when you do start on starting <mumble>, you inherit the env mumble starts in?
[01:55] <slangasek> hmm, not entirely... I think init(5) explains the various idiosyncracies
[01:55] <slangasek> sorry, afk now :)
[01:55] <mwhudson> ok
[01:59] <mwhudson> ahah
[01:59] <mwhudson> we also have
[01:59] <mwhudson> export LAVA_INSTANCE
[01:59] <mwhudson> in lava-instance
[01:59] <mwhudson> the murk parts, slightly
[02:25] <RAOF> @pilot out
[02:37] <mwhudson> argl bargl
[05:12] <slangasek> broder: http://paste.ubuntu.com/844050/ looks good to me for sysvinit, yes
[05:12] <broder> slangasek: ok, cool. i'll go ahead and upload it
[05:12] <broder> and i'll start working on the srus for that as well
[05:19] <slangasek> broder: thanks :)
[05:19] <broder> thanks for the review
[05:33] <broder> slangasek: oh, hmm. is there any way for me to ensure that the sysvinit update gets taken after the insserv update? i could do a breaks, but that wouldn't technically prohibit, e.g., not-fixed-oneiric insserv + fixed-natty sysvinit
[05:35] <micahg> why wouldn't sysvinit breaks << fixed precise insserv prevent oneiric insserv + precise sysvinit/
[05:36] <broder> it would, but i also need to sru this fix to lucid through precise, inclusive
[05:36] <slangasek> broder: you could breaks: insserv (<< 1.14.0-2ubuntu1), insserv (= 1.14.0-2.1)
[05:36] <broder> ooh, breaks with an =. never thought of that
[05:37] <slangasek> although breaks doesn't actually require the broken insserv to be /removed/, just /deconfigured/, so it is technically possible to still get breakage after initscripts has been upgraded
[05:38] <micahg> well, seemingly, each release gets its proper breaks (is there any problem with insserv getting upgraded before sysvinit on dist-upgrade?
[05:39] <slangasek> if necessary, we could have initscripts use a versioned depends on insserv; initscripts already depends on sysv-rc | file-rc and sysv-rc depends on insserv and file-rc isn't actually installable in Ubuntu because upstart depends on sysv-rc
[05:39] <slangasek> so it wouldn't break the world to have initscripts depend on insserv directly
[05:40] <slangasek> micahg: the problem is that the old insserv breaks things and the new initscripts tries to clean it up... we don't want to leave insserv in a position to break things again and force us to do /another/ round of srus to clean up
[05:41] <broder> so what would i do in that case? oneiric's initscripts would depend: insserv (>= 1.14.0-2.1ubuntu1) | insserv (= 1.14.0-2.1ubuntu0.1) ?
[05:41] <broder> and then i keep adding disjunctions as i go further back?
[05:41] <slangasek> yeah
[05:41] <slangasek> fugly, innit :)
[05:41] <broder> yeah...
[05:42] <rectec> Is there any way I can check the HUD's development? Like its stages? (Alpha, beta, etc.)
[05:42] <broder> slangasek: we could survive without that dependency in precise, right? which at least means that the fugliness is temporary?
[05:43] <micahg> that would also couple any other insserv SRU with an initscripts upload
[05:43] <slangasek> broder: yes, for precise I think it's fine to drop the disjunctions
[05:43] <pitti> Good morning
[05:43] <slangasek> micahg: this is the only time we've done an insserv SRU to date
[05:43]  * slangasek waves to pitti
[05:43] <pitti> yay empty precise_probs \o/
[05:44] <pitti> and that at FF time
[05:44] <micahg> pitti: new glib-networking broke ia32-libs, I subscribed you to the bug, needs multiarching
[05:44] <micahg> err..deps need multiarching
[05:44] <pitti> micahg: for libproxy? I thought that already was
[05:44] <pitti> micahg: thanks, will have a look
[05:44] <micahg> yeah
[05:45] <micahg> libproxy's deps I think
[05:45] <broder> slangasek: ok. well, for starters, would you mind rejecting the oneiric initscripts i just uploaded?
[05:45] <broder> err, sysvinit that is, of course
[05:45] <pitti> micahg: ah, libjavascriptcoregtk-1.0-0
[05:45] <slangasek> broder: done
[05:45] <pitti> i. e. webkit
[05:46] <pitti> micahg: acually, I'd rather not have it depend on that in the first place, it's rather big
[05:46] <pitti> will ask Laney about it when he comes online
[05:47] <micahg> sounds good
[05:47] <broder> slangasek: and you think the depends is the best option here?
[05:48] <slangasek> broder: I think it's the safest option that's most certain to kill this bug dead
[05:54] <broder> slangasek: do you think it's an acceptable risk that this would break users who have their own insserv (e.g. from a ppa) installed?
[05:55] <slangasek> heh
[05:55] <slangasek> yes
[05:55] <slangasek> worst case, they need to either rev their ppa build of insserv, or do a ppa build of sysvinit with it
[05:59] <broder> slangasek: ok, really bad idea: have initscripts trigger on /usr/lib/insserv?
[05:59] <slangasek> yuck :)
[05:59] <broder> but...i think it would work, no?
[06:00] <slangasek> I can see a couple ways that could be made to work; none of them appeal to me
[06:00] <slangasek> why do anything with a trigger that could be expressed as a declarative package relationship
[06:01] <broder> because the declarative syntax only lets me express an approximation of what i'm really trying to say?
[06:02] <slangasek> ok, but suppose the user upgrades insserv to a version (local or otherwise) that doesn't include /usr/lib/insserv
[06:02] <slangasek> this may or may not trigger
[06:02] <slangasek> and it may or may not result in insserv being run and breaking things again afterwards
[06:04] <broder> we could clean up the rc*.d links in the initscripts upgrade case and the trigger case
[06:04] <slangasek> yes
[06:04] <slangasek> but the point at which things get *broken* again is when $random_other_thing calls insserv
[06:04] <slangasek> and there's no way to ensure the postinst is called at that point to fix it up
[06:05] <broder> but that's still a problem with the dependency plan
[06:05] <slangasek> how?
[06:06] <slangasek> the only versions satisfying the dependency are ones that have moved insserv off the path
[06:06] <broder> unless it moves back into the path in the future, which i thought was what you were worried about
[06:07] <slangasek> broder: I'm not worried about it moving back into the path in an *archive* version
[06:07] <slangasek> but a *ppa* version could be doing the wrong thing
[06:07] <slangasek> hmm, let me check if that makes sense
[06:08] <slangasek> nah, I officially don't care about any broken versions of insserv packages in anyone's ppa
[06:09] <slangasek> what if the user installs the initscripts SRU but not the insserv one though?
[06:09] <broder> with the dependency approach, they can't
[06:09] <slangasek> are you doing the dependencies?
[06:09] <broder> with the triggers approach, they're still screwed until they get the insserv update, but when they do, it'll be cleaned up
[06:09] <slangasek> I thought that's what you were trying to talk me out of
[06:09] <slangasek> right
[06:10] <broder> i'm currently banging my head against a table trying to keep all of this straight :)
[06:10] <broder> but not yet writing any code
[06:10] <slangasek> I would prefer to deliver an SRU that forces the upgrade to a good version of insserv immediately, so that their shutdown is un-screwed and stays that way
[06:11] <broder> ok. i think that seems right
[06:13] <slangasek> ok
[06:13] <slangasek> fwiw I wouldn't reject either approach if uploaded
[06:13] <slangasek> I also wouldn't accept them at the moment, because I'm headed for bed ;)
[07:00] <pitti> micahg: uploaded a fixed libproxy which drops the webkit dependency FYI, I updated bug 933913
[07:01] <micahg> pitti: great, thanks
[07:25] <rickspencer3> pitti, nice to wake up to a beer this morning! http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[07:25] <pitti> rickspencer3: indeed!
[07:25] <pitti> rickspencer3: we got new armel panda buildds yesterday, they nicely managed to catch up with the backlog
[07:25] <pitti> and compiz fixed
[07:26] <rickspencer3> yeah!
[07:29] <rickspencer3> pitti, looks like the server smoke tests are in less good shape
[07:29]  * rickspencer3 braces for the desktop tests to run
[07:30] <pitti> rickspencer3: these look odd; maybe the same QA lab problem that didrocks was experiencing with his unity mergers?
[07:30] <pitti> error: internal error process exited while connecting to monitor: libvir: error : cannot execute binary /usr/local/bin/kvm: Permission denied
[07:30] <pitti> err
[07:30] <didrocks> no, doesn't seem the same issue
[07:30] <pitti> rickspencer3: so, once the alternates and desktops build, that'll hit them as well
[07:30] <rickspencer3> oops, looks like a lab issue, indeed
[07:30] <didrocks> (it was a network one)
[07:30] <pitti> didrocks: right, sorry; should have checked logs before
[07:30] <pitti> jibel: ^ halp
[07:31] <didrocks> no worry :)
[07:31] <rickspencer3> day after FF, bad luck!
[07:32] <rickspencer3> pitti, did 10.04.4 go out as expected?
[07:32] <pitti> rickspencer3: yes, it's out and announced
[07:32] <rickspencer3> sweet!
[07:32] <rickspencer3> big day yesterday
[07:32] <pitti> http://releases.ubuntu.com/10.04.4/
[07:33] <pitti> http://releases.ubuntu.com/kubuntu/10.04.4/, too
[07:34] <dholbach> good morning
[07:34]  * pitti hugs dholbach
[07:35]  * dholbach hugs pitti back
[07:36] <rickspencer3> morning dholbach
[07:36] <dholbach> hey rickspencer3
[07:39] <pitti> Riddell, debfx_: hmm, kubuntu-docs wants to go to universe; is that intended?
[08:11] <jibel> pitti, good morning
[08:11] <pitti> bonjour jibel
[08:14] <jibel> pitti, permission denied on kvm in the lab. that's weird.
[08:53] <pitti> YokoZar: indeed, http://people.canonical.com/~ubuntu-archive/nbs.html now has dssi-vst which needs to change its b-dep to wine1.4
[08:53] <YokoZar> pitti: Aye, I'll get it right after I get this wine1.4 upload going.
[08:55] <dholbach> does anybody else have issues with thunderbird too?
[08:56] <dholbach> as in widgets being completely empty?
[08:56] <micahg> dholbach: bug 933951
[08:56] <dholbach> ah, thanks micahg
[08:58] <sabdfl> it's a real friday when you don't have to cram as much email as possible in between conversations
[08:58] <sabdfl> thanks, somebody :)
[08:58] <dholbach> haha, thanks sabdfl :)
[08:59] <dholbach> luckily it's easy to workaround it
[09:17] <Riddell> pitti: kubuntu-docs rescued
[09:19] <pitti> cheers
[09:45] <pitti> cjwatson: any opinion on https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/810068/comments/13 ? I'm inclined to just reject the maverick-proposed uploads; we had enough trouble verifying this for lucid already
[09:45] <Laney> pitti: it would have been OK were that still a module
[09:46] <Laney> but I think disabling mozjs stops that being so
[09:46] <pitti> Laney: this probably needs to be split into several source packages at some point?
[09:46] <Laney> why source packages?
[09:47] <Laney> having them in separate binaries was alright wasn't it?
[09:47] <pitti> Laney: you can't build-dep on universe packages, though
[09:47] <Laney> it would be good to disable mozjs and have webkit still be a plugin
[09:47] <pitti> i. e. if we want the mozjs plugin in universe, it needs to be in an universe source package
[09:47] <pitti> Laney: yes, but webkit doesn't build without mozjs apparently
[09:47] <pitti> when I disabled mozjs, webkit wasn't built
[09:47] <Laney> it was
[09:47] <Laney> it's just a part of the main package now
[09:48] <pitti> ah; could this be split out again somehow?
[09:48] <Laney> I think — let me check
[09:48] <pitti> pulling in an extra > 1 MB package just for this seems a little exaggerated
[09:48] <pitti> having it in the plugin would be fine
[09:49] <pitti> also, we shoudl check whether it builds against libwebkitgtk-3.0-dev
[09:49] <Laney> for ubunt2 we had " * pacrunner_webkit"
[09:49] <Laney> i.e. webkit is builtin
[09:51] <Laney> I'm pretty sure it has webkit3 support
[09:51] <pitti> ok, SRU queues processed as much as possible
[09:51] <Laney> next week I'll speak to upstream about the module thing
[09:52] <pitti> thanks
[09:52] <Laney> or … actually, see libproxy/cmake/modules.cmk:21
[10:07] <jamespage> any archive admins around?  I'm reviewing a proposed new package (see bug 930422) and wanted a second opinion on what they are doing with qtrpc2
[10:27] <Laney> pitti: bug #934088
[10:28] <micahg> pitti: did you see my ping before?
[10:28] <pitti> micahg: only the one about libproxy
[10:28] <micahg> pitti: can you please copy firefox/lucid-oneiric from ubuntu-mozilla-security to $RELEASE-security?
[10:28] <pitti> Laney: sweet, thanks! sponsoring
[10:28] <pitti> micahg: uh, not in backscroll; weird
[10:28] <Laney> cheers!
[10:28] <pitti> micahg: sure, doing
[10:29] <micahg> pitti: I've been having IRC issues, I'm hoping after I dist-upgrade they'll go away :)
[10:33] <smb> optimism seems to die last... :-P
[10:40] <pitti> micahg: done
[10:40] <micahg> pitti: thanks
[10:41] <hrw> ~curse thunderbird
[10:42] <micahg> hrw: fix already uploaded and buidling
[10:43] <hrw> micahg: cool
[10:43] <hrw> time to run dget - will be faster then waiting for archive
[10:44] <hrw> micahg: can TB be built in 7GB of disk space?
[10:44]  * micahg checks
[10:46] <micahg> hrw: umm, cutting it very clsoe
[10:46] <hrw> hope it will fit - 7GB is my pbuilder tmpfs
[10:47] <micahg> oh, on armhf it's less
[10:48] <RAOF> hrw: Someone has too much ram!
[10:48] <hrw> RAOF: 16GB was <100€ so why bother with 8GB :D
[10:49] <RAOF> Fair call!
[10:49] <hrw> RAOF: when 8GB DDR3 sticks will be around price of 2x4GB DDR3 I will consider 16->24/32GB
[10:49] <RAOF> Yeah, I guess I could build a desktop... :)
[10:51] <pitti> hrw: "swap? what is that?"
[10:52] <hrw> pitti: can you speak english? :)
[10:53] <hrw> pitti: with low price of ram I do not see sense in having swap
[11:00] <pitti> err -- WTH
[11:00] <pitti> all my copying of kernels to -proposed were just silently forgotten by LP
[11:01] <pitti> ah, no, seems just the publisher is veeery behind
[11:11] <cjwatson> bdrung: http://paste.ubuntu.com/845621/
[11:11] <cjwatson> pitti: maverick> I guess; I was just uploading it for everything without especially thinking about it, really
[11:16] <karel_ff> According to omgubuntu (http://goo.gl/vXnPf) the sun java packages were going to be pulled from the partner repos yesterday.
[11:17] <karel_ff> It appears they're still there for natty. Can anyone enlighten me if they are going to be removed there as well?
[11:33] <pitti> go, ev, go!
[11:34] <ev> haha
[11:42] <hrw> micahg: thx - ubuntu3 tb package works
[11:47] <micahg> hrw: chrisccoulson fixed it
[11:53] <debfx> could someone please close https://code.launchpad.net/~marcelstimberg/ubuntu/precise/scribus/merge-1.4-from-debian/+merge/92623
[11:53] <hrw> chrisccoulson: thx for fix
[11:53] <debfx> a newer version has already been merged, see bug #930639
[11:53] <hrw> micahg: and you confirmed that this version will work
[12:33] <chrisccoulson> doko_, you around?
[12:38]  * TorpedoSkyline thinks doko_ disappeared.
[13:12] <mdeslaur> bdmurray: sorry, the oneiric update-manager security update superseded your package in -proposed...
[13:15] <doko> chrisccoulson, yes, what's the issue?
[13:29] <chrisccoulson> doko - i could use some help on https://bugzilla.mozilla.org/show_bug.cgi?id=694594 :)
[13:30] <doko> chrisccoulson, that's what you get when backporting new upstream versions :-/
[13:30] <chrisccoulson> heh
[13:33] <doko> chrisccoulson, did you test vanilla 4.4.6, or the Ubuntu packages? does 4.5.x work?
[13:33] <chrisccoulson> doko, i tested the ubuntu 4.4.6 package. i've not tested a vanilla gcc yet
[13:33] <chrisccoulson> 4.5.x seems to work though
[13:33] <doko> note that there are backports for lucid in the ubuntu-toolchain-r/test repository, and in ubuntu-toolchain-r/ppa for gcc-4.4
[13:34] <chrisccoulson> at least, we don't get any crashes from builds that are built with 4.5 :)
[13:34] <doko> ok, but maybe not an option or the upload
[13:34] <chrisccoulson> thanks, i'll try a vanilla build too
[13:35] <doko> chrisccoulson, from the bug report I understand that you can work-around the issue?
[13:36] <chrisccoulson> doko, sort of. it's not a good long term solution, as this code is pretty performance optimized. and there's no guarantee that we don't see the same problem in other places too
[13:36] <doko> understood
[14:05] <doko> bdmurray, 933946 was closed with the wrong text (talking about apport, while it's a corrupt archive)
[14:39] <zumbi> hello, base-files fails to install on precise, when /var/run is not empty dir, there is a patch attached to a BR, is there something special that needs doing to get this applied? (BR: https://bugs.launchpad.net/ubuntu/+source/multistrap/+bug/874505)
[14:43] <roadmr> zumbi: looks like  it needs to be reviewed, I see the review team is already subscribed so it should get some attention soon
[14:44] <zumbi> roadmr: ah! thanks
[14:50] <pitti> Riddell: ah, has there been a decision for telepathy-KDE now?
[14:50] <pitti> Riddell: (I'm just curious)
[14:50] <pitti> I read your blog a few days ago, and it didn't seem obvious which one was better
[14:51] <Riddell> pitti: not yet, I'm still a fan of telepathy-KDE because it's maintained but others are more cautious for the LTS.  It might come down to whether we can convince upstream to add message indicator integration :)
[14:52] <Riddell> we'll make a decision in plenty time either way
[14:52] <pitti> Riddell: ah, I was just reading your -release@ mail
[14:53] <Riddell> pitti: I still hope to have it in but happy to accept if it can't be done
[14:53] <pitti> Riddell: tricky situation indeed; we had pretty much the same a few cycles ago
[14:54] <pitti> at least the telepathy stack settled down since then, it's actually surprisingly stable these days
[14:54] <pitti> video connections used to be a bit unstable (sometimes you needed to try connecting twice), but that was some time ago; I don't use them often
[14:54] <pitti> the tubes for sharing your desktop etc. are really cool, though
[14:55]  * pitti goes back offline until release meeting, bbl
[15:01] <barry> Riddell: good to see you got a version of telepathy uploaded that fixes the failure.  i got as far as disabling the fix_test_linkage.patch and getting that built in my ppa.  if you're happy with your fix, i'll move on to other things
[15:03] <Riddell> barry: oh do I?  clever me!
[15:03] <Riddell> barry: where is this?
[15:12] <barry> Riddell: https://launchpad.net/ubuntu/precise/+source/telepathy-qt4/0.9.0+repack-0ubuntu2
[15:13] <pitti> cking: I have a first version of a power-usage-report script (WI in that spec) in https://code.launchpad.net/~pitti/+junk/power-usage-report/
[15:14] <pitti> cking: it can be run without arguments, does its thing (fatrace, powertop, and post-processing), and gives a reasonably meaningful output
[15:14] <pitti> cking: I'd appreciate comments and suggestions that you might have
[15:15] <pitti> cking: today I overheard in a bug report that you have an events-something script yourself, perhaps we can combine this somehow?
[15:15] <cking> pitti, yes, that's doable - my code is free to be used + reworked
[15:16] <cking> pitti, I will look at this in ~40 mins - I'm halfway through making a load of edits to a document that needs to be completed today
[15:16] <pitti> cking: oh, not urgent at all
[15:16] <pitti> I'll go offline again until release meeting, and won't re-look at this until Tuesday anyway
[15:16] <pitti> cking: thanks in advance!
[15:17] <ion> Heh. By chance the nicks of everyone who has been discussing here for the last 25 minutes end up having the same appearance in WeeChat. (It uses nick hashes to select attributes such as color for nicks.)
[15:17] <pitti> cking: there's another WI to add stracing for the worst offenders, but that'll introduce some interesting problems (reporting passwords and what not), so that'll need some thought
[15:17] <cking> ok - well, I'm off on monday, so I will either get back to you end of day or on tuesday
[15:17] <pitti> cking: I'm off on Monday as well
[15:17] <pitti> cking: but I think in the end the automatic stracing might be overkill -- at that point it's better to analyze the offending processes individually anyway in bug reports, I think
[15:18] <pitti> this script should give a good overview where the problems are on a particular system
[15:18] <pitti> anyway, /me waves, bbl
[15:18] <cking> pitti, yep, I think one can has tools to identify rogue processes, debugging it is a strace + gdb effort
[15:19] <cking> pitti, thanks for letting me know - I shall look at the tool with great interest! \o/
[15:22] <rbasak> Does "pull-lp-source" fail for anyone else? Eg: "pull-lp-source hello".
[15:24] <Riddell> barry: yeah but that has led to a new problem, needing LD_LIBRARY_PATH or something
[15:25] <rbasak> It seems to work from my machine (authenticated) but not from an anonymous machine
[15:27] <barry> Riddell: yep.  but hey, a built package is a built package, right? :)
[15:30] <rbasak> Hmm...rm -Rf ~/.launchpadlib fixed it.
[15:37] <Riddell> barry: it's not built
[15:37] <bdmurray> mdeslaur: in oneiric or lucid?
[15:38] <cjwatson> ivoks: I've merged your livecd-rootfs change, but two things
[15:38] <ivoks> cjwatson: sure?
[15:38] <cjwatson> ivoks: firstly, in order to get a BuildLiveCD change deployed, you'll need to raise an RT
[15:38] <mdeslaur> bdmurray: oneiric...oh, looks like your lucid -proposed package dropped the new security update too
[15:39] <mdeslaur> bdmurray: d'oh...sorry about that
[15:39] <barry> Riddell: okay.  let me look in more detail
[15:39] <cjwatson> ivoks: secondly, the rest of Ubuntu nowadays only uses livecd-rootfs as a wrapper for live-build - the code for that is in the live-build/ subdirectory
[15:39] <cjwatson> ivoks: so in some ways you seem to be going in the wrong direction
[15:39] <mdeslaur> bdmurray: publishing security updates when there are packages in -proposed is painful :(
[15:39] <Riddell> barry: it's cdbs so actually mine and debfx's preference is just to turn it into dh9 and hope that helps
[15:39] <bdmurray> mdeslaur: the lucid was just approved and had been pending queue
[15:39] <ivoks> cjwatson: mrmh... ok :)
[15:39] <cjwatson> ivoks: live-build/auto/config is probably the main one to edit
[15:40] <ivoks> cjwatson: ok, thanks i'll do that
[15:40] <barry> Riddell: i definitely support that choice :).  shall i just leave this one to you guys then?
[15:40] <mdeslaur> bdmurray: yeah, but while it was in the queue, a security update got published, and since you bumped the major version instead of the minor version, it superseded the security update
[15:41] <ivoks> cjwatson: atm cloud-live is build with live-build; does that make any difference? should i still change livecd-rootfs?
[15:41] <bdmurray> mdeslaur: Is there anything for me to do besides upload new versions to -proposed?
[15:41] <bdmurray> I mean in addition to
[15:42] <mdeslaur> bdmurray: no, you just need to remerge the security update and re-upload it
[15:43] <cjwatson> ivoks: how are you configuring live-build right now?
[15:45] <ivoks> cjwatson: (sorry, i'm otp) i have whole live-build tree (lp:cloud-live)
[15:46] <cjwatson> ivoks: you mean you branched the whole thing?
[15:50] <cjwatson> ivoks: wow, that's ... interesting
[15:50] <cjwatson> ivoks: what I'd suggest is that you figure out how to do this with the stock live-build package in precise, using suitable 'lb config' parameters and possibly the odd hook
[15:50] <cjwatson> ivoks: then it should be a short step from there to expressing that in livecd-rootfs/live-build/auto/config
[15:50] <ivoks> cjwatson: let me get back to you in few minutes (on the phone)
[15:50] <cjwatson> ivoks: sure, no rush
[15:51] <cjwatson> ivoks: ah, looks like you checked in the result of running lb config and creating hooks
[15:51] <cjwatson> ivoks: so that could be done on the fly in auto/config instead
[15:51] <kelemengabor> dobey: ping. do you have time to review the proposed merge for bug #856728?
[15:52] <dobey> kelemengabor: yep, i will poke at it shortly. i am working on installer right now :)
[15:53] <dobey> kelemengabor: thanks for the reminder
[15:53] <kelemengabor> yw :)
[15:53] <dobey> bdmurray: i'll try to poke at your lptools branch today too
[15:55] <bdmurray> dobey: thanks
[16:01] <ivoks> cjwatson: sorry, i had a meeeting
[16:01] <ivoks> cjwatson: all those changes are now in the package, so that build mechanism is kind of obsolete
[16:01] <ivoks> cjwatson: s/changes/hooks
[16:12] <dylan-m> Little question before I file a bug report: why are the category icons for gnome-control-center named like preferences-desktop-personal-directory instead of preferences-desktop-personal ?
[16:13] <pitti> ev: test_run_crash_known() test case in ui.py works for you? I still get a KeyError (just re-merged your branch 5 mins ago)
[16:15] <ev> pitti: ah, I wasn't sure if that one was related to the gdb weirdness I was seeing.  When I poked at it last night, it was raising an IOError inside collect()
[16:15] <ev> I'll have another look
[16:15] <ev> apols for that
[16:15] <pitti> ev: no, I get KeyError: 'KnownReport'
[16:15] <pitti> PYTHONPATH=. python apport/ui.py -v _T.test_run_crash_known
[16:16] <pitti> ev: that looks like a regression in the dupe detection
[16:16] <ev> yes, but if memory serves, it's because the IOError is raised, setting self.report to None
[16:16] <ev> (and thus the KeyError)
[16:24] <pitti> ev: bug report window looking nicely now, thanks for fixing that up!
[16:25] <pitti> ev: btw, I'm not getting the gdb failures; I suspect it's a race condition, but I don't think that's related to your work at all
[16:30] <ev> pitti: cheers!
[16:31] <pitti> ev: I'm currently walking through all {bug, crash, symptoms} x {gtk, cli, qt} cases
[16:32] <ev> thanks for that - I tried to understand them as best I could, to ensure I wasn't just making the test pass, but it was getting on in the evening and I could've made a mistake somewhere.
[16:34] <SpamapS> Ugh
[16:34] <SpamapS> why does apt want to remove unity-2d?!
[16:34] <SpamapS>   gnome-session: Breaks: unity-2d (< 5.4~) but 5.2.1-0ubuntu2 is installed.
[16:34] <SpamapS> ahh, that
[16:36] <pitti> buildd lag
[16:41] <apw> cjwatson, is it possible to increase 'something' on key packages like ubuntu-desktop to encourage apt's conflict resolution to prefer not to remove it
[16:43] <smoser> SpamapS, around ?
[16:43] <SpamapS> smoser: I am
[16:43] <smoser>  /etc/network/if-up.d/upstart
[16:43] <smoser> i'm looking tat that and wondering
[16:43] <SpamapS> yes
[16:44] <kelemengabor> is there any unity dev around, who could take a look at the merge proposal in bug #923762 ?
[16:44] <smoser> if no interfaces are auto, will all interfaces ever be noticed as up?
[16:44] <SpamapS> kelemengabor: try #ubuntu-desktop
[16:44] <SpamapS> smoser: lo is always going to be auto
[16:45] <smoser> well.. yeah.
[16:45] <SpamapS> smoser: and actually no, if there are no auto interfaces, all_interfaces_up will return 0
[16:45] <smoser> so here s what i'm looking at right now.
[16:45] <SpamapS> because the for loop will be skipped
[16:45] <smoser> its mostly an edge case
[16:45] <SpamapS> err
[16:45] <SpamapS> actually this script will never be called in that case
[16:46] <SpamapS> and you'll failsafe boot
[16:46] <smoser> but in cloud-init, i can now take an /etc/network/interfaces file from "config drive" or from DataSourceNoCloud
[16:46] <Daviey> jdstrand / mdeslaur (barry for info): bug 934295, not proud that i got it to build by giving back.. but you might want to be aware if it's not fixed before release.
[16:46] <smoser> the order would then be boot... likely lo up, mount / , cloud-init, cloud-init writes /etc/network/interfaces and runs 'ifup --all'
[16:47] <smoser> but if the new /etc/network/interfaces does not have any auto (other than lo) then nothing would emit that.
[16:47] <jdstrand> Daviey: gotta love it! thanks :)
[16:47] <smoser> hm..
[16:47] <pitti> ev: for a crash report I still get the second window with the info colelction progress bar
[16:48] <pitti> ev: you don't?
[16:48] <smoser> but i guess that snot really all that bad, because anything waiting on that is probably actually expecting network.
[16:49] <ev> pitti: Do you not get that error in test_run_crash_known with trunk? the error it's attempting to raise (but which gets swallowed by the except clause around collect_info) in both trunk and my branch is 'CRC check failed 0x6d754465 != 0x0L'
[16:49] <ev> pitti: I do not. What's the command you're running where you're seeing that?
[16:49] <pitti> ev: gedit &; killall -SEGV gedit
[16:49] <pitti> PYTHONPATH=. gtk/apport-gtk
[16:49] <pitti> ev: that's with killall update-notifier, so that it doesn't get in the way
[16:50] <pitti> ev: trying with trunk again
[16:50] <ev> I'll give it a bash after this interview call
[16:50] <pitti> ev: (I'm in release meeting, sorry for lagging)
[16:50] <ev> no worries at all!
[16:50] <ev> I appreciate your careful and thorough review of this
[16:54] <SpamapS> So, dpkg experts.. if I have a conffile, say, /etc/apparmor/profiles.d/usr.sbin.mysqld .. and it is owned by mysql-server-5.1 ...
[16:54] <SpamapS> and then mysql-server-5.5 Breaks/Replaces mysql-server-5.1 ..
[16:55] <SpamapS> and it also owns said file..
[16:55] <SpamapS> wouldn't one expect that the file would *only* be owned by mysql-server-5.1 ?
[16:59] <SpamapS> err
[16:59] <SpamapS> 5.5
[17:00] <SpamapS> I would expect that the conffile would be owned by 5.5, and that it would be updated to the 5.5 version
[17:03] <pitti> ev: I'm done with testing, I followed up to the MP
[17:03] <pitti> ev: I don't get that _T.test_run_crash_known failure in trunk
[17:04] <pitti> ev: then the second progress dialog, and finally the apport-kde crash (which might or might not be your fault)
[17:07] <pitti> ev: oh, and the "dash" vs. "Ubuntu 12.04 internal", but I agree that we can sort this out later and it's not a blocker
[17:07] <SpamapS> slangasek: ^^ any ideas on the conffiles? Its showcased in bug 934013
[17:09] <slangasek> SpamapS: yes, Replaces should be sufficient to cause the mysql-5.5 version to take over
[17:12] <jtaylor> barry: can you do a no change rebuild of libvigraimpex please
[17:12] <SpamapS> slangasek: its showing rc for mysql-server-5.1 .. and the content is still the 5.1 version
[17:12] <slangasek> SpamapS: the new version of the package doesn't ship that conffile at all?
[17:12] <slangasek> so since the old package is removed but not purged...
[17:12] <slangasek> the old conffiles remain
[17:13] <SpamapS> slangasek: it does ship that conffile
[17:13] <slangasek> SpamapS: not according to dpkg -c / Contents.gz
[17:13] <SpamapS> ruh roh
[17:13] <SpamapS>     if [ "$(DISTRIBUTION)" = "Ubuntu" ]; then \
[17:13] <SpamapS>       dh_apparmor -pmysql-server-5.5 --profile-name=usr.sbin.mysqld; \
[17:13] <SpamapS>     fi
[17:14] <SpamapS> hmmmmm
[17:15] <SpamapS> oh
[17:15] <SpamapS> no.. hmm.. debian/apparmor-profile is there...
[17:16] <SpamapS> oh wait.. does dh_apparmor not actually pull that file in?
[17:17] <pitti> SpamapS: FWIW, if mysql is anything like postgresql, then uploading whole microreleases to -updates/-security is probably better than trying to cobble together large patches ourselves
[17:17] <pitti> SpamapS: a microrelease exception would be in order then, and likely granted provided that upstream has strict policy for microreleases and good QA
[17:17] <SpamapS> pitti: I was under the impression that postgres was far more careful abotu not introducing incompatible changes in patch releases though.
[17:18] <pitti> SpamapS: yes, that's the "if"; I am not familiar at all about the nature of changes that happen in mysql microreleases
[17:18] <jdstrand> SpamapS: iirc, when using dh_apparmor you need to rename apparmor-profile to what you are passing as the --profile-name
[17:18] <SpamapS> pitti: about every 2-3 releases they break something. To be fair, they usually identify it in their changelog.
[17:18] <jdstrand> SpamapS: ie, mv apparmor-profile usr.sbin.mysqld
[17:19] <SpamapS> jdstrand: indeed, looks like the file got missed
[17:19] <jdstrand> SpamapS: (in the debian/ directory of course)
[17:19] <pitti> SpamapS: not that helpful for production servers, though
[17:19] <pitti> SpamapS: if that is so, then backporting security fixes indeed sounds better then?
[17:19] <SpamapS>     install -D -m 644 debian/apparmor-profile $(TMP)/etc/apparmor.d/usr.sbin.mysqld
[17:19] <SpamapS> In 5.1 packaging, not in 5.5
[17:19] <SpamapS> ok it all makes sense now. :)
[17:19] <jdstrand> SpamapS: yes, 5.1 did not use dh_apparmor iirc
[17:20] <SpamapS> pitti: we can't do that
[17:20] <SpamapS> pitti: Oracle *obfuscates* their security fixes
[17:20] <jdstrand>  /o\
[17:20] <SpamapS> jdstrand: it did
[17:20] <pitti> SpamapS: hm, you think mariadb will have compatibility problems, too?
[17:20] <SpamapS> pitti: yes
[17:21] <pitti> rock <-> SpamapS <-> hard place
[17:21] <jdstrand> can we migrate mysql users to postgresql?
[17:21] <SpamapS> s/SpamapS/Ubuntu & Debian MySQL users/
[17:21]  * jdstrand is obviously kidding
[17:21] <SpamapS> jdstrand: lol
[17:21] <pitti> SpamapS: for psql I found that users didn't appreciate the backporting fixes that I used to do
[17:21] <SpamapS> pitti: to be fairl, neither do a lot of MySQL users.
[17:21] <pitti> SpamapS: they wanted the full microreleases, even though they had larger changes (but usually no incompatibilities, except to fix security holes)
[17:22] <pitti> SpamapS: just giving that as a data point
[17:22] <pitti> SpamapS: so maybe the odd incompatiblity is ok, as users can then go directly upstream to discuss/log bugs/etc.
[17:22] <SpamapS> Its really not about the users perception.. they'll take 5.1.61 and use it. Its just that we are going to be the first point of contact for when it breaks their app.
[17:22] <pitti> just giving that as a data point; I can't make a solid recommendation what to do for mysql
[17:23] <SpamapS> pitti: heh.. except that bugs.mysql.com is now a 2nd class citizen at Oracle.
[17:23] <SpamapS> pitti: you have to pay to get access to the private bug tracker.
[17:23] <SpamapS> to be fair, they have been responding a bit more to community bugs
[17:24] <pitti> good night everyone!
[17:24] <SpamapS> but.. yeah.. its just the suck.. what made MySQL great... nimble openness .. is gone. Its now just "Mini-Oracle"
[17:24] <jdstrand> SpamapS: ignore me on the apparmor-profile/dh_apparmor bit. I was confused. dh_apparmor just needs the profile to where it expects it to be based on --profile-name. whether one uses 'install -D -m 644...' or a debian/*.install file doesn't matter. sorry for the noise
[17:24] <SpamapS> jdstrand: indeed, I'm fixing the files sections now
[17:25] <SpamapS> somehow missed the apport hook too
[17:26] <SpamapS> Ugh.. I really want to rewrite this packaging from scratch
[17:27] <ion> “what made MySQL great” /me snorts
[17:28] <SpamapS> right, its not great.. it just accidentally dominated the database market for the last 10 years. ;)
[17:28] <ajmitch> ion: not a fan? :)
[17:29] <ion> ajmitch: For a toy database, SQLite is easier to deploy and maintain. For a real database, one might want to use a real database. :-P
[17:29] <SpamapS> mysql is to databases as sitcoms are to television.
[17:29] <SpamapS> yes.. a toy that runs facebook and google... just a toy. :)
[17:30] <ion> An awesome piece of history: http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Broken_Foreign_KEY
[17:30] <SpamapS> seriously
[17:30] <SpamapS> did you just quote the 3.23 manual?!
[17:31] <jdstrand> hehe
[17:31] <ajmitch> it may be old, but it's an amusing read :)
[17:31] <ajmitch> SpamapS: I don't envy you or other maintainers trying to keep up with security fixes from oracle though
[17:31] <SpamapS> ajmitch: we're not going to. We're going to ship the micro releases.. period. :-/
[17:32]  * ajmitch relies on mysql at work, so it's sort of important to have it still function 
[17:32] <jdstrand> SpamapS: yeah, I just don't see any other way atm :(
[17:32] <ajmitch> just have to hope that the tests catch any regressions
[17:32] <SpamapS> jdstrand: neither do any of the experts .. people who have been developing mysql for years cannot find the way to get the security patches out
[17:32] <jdstrand> SpamapS: to add insult to injury, its my understanding that there most recent 5.0 release was their last
[17:33] <jdstrand> s/there/their/
[17:33] <SpamapS> jdstrand: yeah.. we're on thin ice for the next 14 months w/ hardy
[17:33] <jdstrand> SpamapS: well, maybe they'll wait 14 months to group security vulnerabilities together like they did last time :P
[17:33] <ajmitch> isn't that a problem with any upstream that doesn't provide fixes over a long period?
[17:34] <jdstrand> ajmitch: the problem is there isn't any path to backport from 5.1. the fixes are all obfuscated with no access to the bugs
[17:34] <SpamapS> jdstrand: the reality is that many of the CVE's they reported as being fixed in 5.1.61 were fixed in earlier releases
[17:35]  * ajmitch could write some things about that situation, but has to adhere to the CoC
[17:35] <jdstrand> ajmitch: you and me both
[17:35] <SpamapS> jdstrand: but 5.1.61 is just the first release where they're 100% using oracle's machinery
[17:35] <jdstrand> I see
[17:36] <SpamapS> jdstrand: in fact the mariadb guys were pretty convinced that some of them were duplicate CVE's of publicly disclosed bugs.
[17:36] <SpamapS> I say bring on Drizzle
[17:36] <jdstrand> heh
[17:36] <jdstrand> 'pretty convinced'
[17:37] <jdstrand> that is from the experts. man, what a mess
[17:37] <SpamapS> http://bit.ly/x40TS8
[17:37]  * ajmitch wonders if he can move to postgresql
[17:37] <SpamapS> ajmitch: You're going to have a lot less friction moving to Drizzle.
[17:38] <SpamapS> 99.9% compatibility.. just all the stupid stuff removed.
[17:38] <jdstrand> SpamapS: seriously :)
[17:38] <ajmitch> SpamapS: you're probably right, the drizzle packages in precise look to be a few months old though
[17:38] <SpamapS> like   update table set timestamp column = NULL; ... in mysql a select from that column will give '0000-00-00 00:00:00'
[17:38] <SpamapS> in drizzle it gives.. SURPRISE.. null
[17:39] <SpamapS> ajmitch: I'll be uploading the GA release of drizzle to precise next week
[17:39] <ajmitch> SpamapS: great
[17:39] <SpamapS> ajmitch: its beta right now
[17:39] <ajmitch> SpamapS: are you currently the only person touching php & mysql in ubuntu?
[17:43] <SpamapS> ajmitch: mostly yeah
[17:43] <SpamapS> ajmitch: zul helps some too
[17:44] <ajmitch> that figures
[17:44] <zul> secrets and lies!
[17:44] <SpamapS> hmm
[17:44] <ajmitch> zul: oh hello there
[17:44] <SpamapS> so.. I wish dh_apparmor actually installed the file into the intended package..
[17:45] <SpamapS> because it makes it really hard to sync packages between debian/ubuntu if you have to change the .install or .files ..
[17:56] <ajmitch> SpamapS: where is the best place to help out with php-related stuff these days?
[18:01] <lamont> lamont    3722  0.3 60.0 6779384 2310004 ?     SLl  Feb14  15:24      \_ nm-applet
[18:01] <SpamapS> ajmitch: testing testing testing testing. :)
[18:01] <lamont> what has my machine done to itself that nm-applet has chosen a 6GB footprint in memory?
[18:01] <SpamapS> ajmitch: We've diverged from debian recently, as they've removed suhosin, and we're keeping it
[18:02] <ajmitch> yeah I saw that in your latest upload
[18:03] <slangasek> lamont: hahaha
[18:04] <lamont> slangasek: yeah, something like that
[18:04] <lamont> network mangler has expanded its scope to include swap manglement
[18:05]  * lamont dist-upgrades again before rebooting
[18:12] <dylan-m> Hey, I noticed the Wacom settings panel has a Map Buttons button, which is disabled. Anyone know what's going on with that? (WIP upstream, or is it a missing dependency?)
[18:17] <slangasek> lamont: hmm, so, the postfix resolvconf hook still fails miserably in early boot
[18:17] <lamont> slangasek: somehow, this does not surprise me
[18:18] <slangasek> it's weird though
[18:19] <slangasek> things fail, then /etc/init.d/postfix status exits zero :P
[18:19] <slangasek> oh, ah yes
[18:20] <slangasek> because postmulti fails, enabled_instances() returns an empty list
[18:20] <lamont> haha
[18:20] <lamont> nice
[18:20] <slangasek> so "all" 0 instances are running
[18:20] <lamont> yeah
[18:35] <Sarvatt> dylan-m: it looks like its just a stub and hasn't been implemented yet
[18:37] <dpm> hi pitti, the latest precise langpacks are dated from 0209 and were disabled for the beta freeze. I haven't seen any other langpacks, but the cron job is enabled. Did you just enabled it recently, or is something happening with the builds?
[18:38] <SpamapS> jdstrand: hey, is there any reason that an apparmor profile containing package should include the dir etc/apparmor.d/force-complain
[18:38] <SpamapS> ?
[18:39] <jdstrand> SpamapS: the force-complain directory is used for upgrades from a release of Ubuntu that shipped the package without a profile (or non-enforcing) to a release that ships an enforcing profile
[18:40] <SpamapS> jdstrand: ok, so 5.1 has always shipped enforcing profiles
[18:40] <jdstrand> SpamapS: idea being, that if you upgrade from a release that didn't have the profile present, we don't have enough information to be sure we won't break your system, so we force it into complain mode
[18:40] <SpamapS> I think, let me check lucid..
[18:41] <jdstrand> I think mysql has since hardy tbh
[18:41] <SpamapS> jdstrand: ok, so we don't need that dir anymore seems
[18:41] <jdstrand> yes, it was in hardy
[18:42] <jdstrand> shouldn't, no
[18:42] <SpamapS> jdstrand: should I leave the bit in postrm to remove the symlink?
[18:42] <SpamapS> seems like yes
[18:42] <SpamapS> or is that dh_apparmor's job now?
[18:42] <jdstrand> SpamapS: yes-- the user could have done it
[18:43] <jdstrand> oh, good point
[18:43]  * jdstrand looks
[18:43] <SpamapS> yep
[18:43] <SpamapS> cool
[18:43] <jdstrand> cat /usr/share/debhelper/autoscripts/postrm-apparmor
[18:44] <jdstrand> dh_apparmor does it
[18:44]  * SpamapS <heart> dh
[18:44] <jdstrand> hehe
[18:45] <jdstrand> SpamapS: fyi, it got easier in Debian. apparmor in Debian ships dh-apparmor now so everyone can start using it
[18:45] <jdstrand> SpamapS: we need the apparmor merge to happen though in Ubuntu first before we can then pull those Debian packages into Ubuntu (should happen next week)
[18:46]  * jdstrand thanks kees for his tireless work with debhelper upstream and finding a solution for us
[18:47] <SpamapS> # no DEBHELPER here, "update-rc.d remove" fails if mysql-server-5.5 is installed
[18:47] <SpamapS> DOH
[18:48] <SpamapS> I bet thats not the case anymore.
[18:48] <SpamapS> jdstrand: thats awesome!
[18:51] <jdstrand> yeah-- next cycle we can start removing that delta and push all this up to Debian, now that they have an apparmor
[19:06] <slangasek> jdstrand: hmm, I don't see a dh_apparmor in the current debhelper package in unstable?
[19:06] <kees> slangasek: it's in the dh-apparmor binary package in unstable
[19:07] <slangasek> ah
[19:07] <slangasek> oh, he kinda said that already
[19:16] <dylan-m> Okay, thanks, Sarvatt
[19:41] <m4n1sh> ev: ping
[20:38] <bdmurray> doko: thanks - I've pushed a fix for that
[21:35] <barry> Riddell: well, at least i can reproduce the failure in my sbuild now, not that i have a fix yet
[22:26] <Riddell> barry: debfx says he has a patch http://people.ubuntu.com/~debfx/telepathy-qt4_0.9.0+repack-0ubuntu3.debdiff
[22:26] <Riddell> ah well a port to dh
[22:26] <Riddell> debfx: have you tried it in a PPA?
[22:28] <barry> Riddell, debfx that's probably the best longer term fix.  i'll give that a try in preference to the fix/hack i've been developing
[22:52] <barry> Riddell, debfx your debdiff works for me locally.  tests pass, package gets built.  i'll try it in a ppa to double check.  don't know if you're still online, but if there are no objections, i'll go ahead and sponsor this upload.  will be nice to get this one fixed
[22:52] <Riddell> barry: yes please
[22:52] <barry> +1
[23:38] <broder> slangasek: spent some more time thinking about initscripts/insserv
[23:38] <broder> does it make any sense to put the postinst code in insserv just for the srus, and not sru initscripts at all?
[23:39] <broder> we've have the better fix for the long-term, and the "short term" of the srus would have a fix that was guaranteed ordered correctly
[23:39] <slangasek> it makes a certain amount of sense, yes
[23:39] <slangasek> notwithstanding my dislike for insserv messing with links belonging to initscripts
[23:39] <broder> sure, that's not ideal, but at the same time, it is insserv cleaning up its own mess, which seems appropriate at some level
[23:40] <broder> and my head doesn't explode trying to think about the edge cases in possible upgrade paths
[23:40] <slangasek> yeah; I wouldn't reject this solution either
[23:41] <broder> ok. i think i prefer doing it this way. would you mind rejecting the insserv srus i've already uploaded, and then i can roll this in and reupload?
[23:43] <broder> thanks
[23:43] <slangasek> broder: rejected
[23:46] <ScottK> dobey: Where's your split python-qt4 package?
[23:54] <lamont> slangasek: bind9 9.8.1.dfsg.P1-3 uploaded to debian, I figure we can sync it monday
[23:54] <slangasek> lamont: sounds good to me
[23:54] <lamont> I'll work on postfix next,sometime this weekend
[23:54]  * slangasek nods
[23:54] <bdrung> cjwatson: around?
[23:54]  * lamont wanders
[23:55] <slangasek> bdrung: he isn't
[23:55] <bdrung> k