[00:04] <eightyeight> is the kernel frozen for 12.04?
[00:08] <broder> eightyeight: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule lists kernel freeze as april 5th
[00:36] <smoser> slangasek, :-( no.
[00:36] <smoser> i'm sorry.
[00:37] <slangasek> smoser: hmm.  are there any tests in particular you'd like us to do before landing it in the archive?
[00:37] <slangasek> (ones that we can get done before FF, I hope)
[00:47] <smoser> i dont have a lot of expectancy of failure.
[00:47] <smoser> for it.
[00:47] <smoser> cloud-init is generally fairly light on it.  uses mounted event nof '/'.
[00:48] <AaronMT> Has there been a security bug filed for seclists.org/fulldisclosure/2012/Feb/254
[00:50] <slangasek> smoser: sure; we're being very cautious this time around, owing to the two previous false starts
[00:51] <slangasek> so if you don't think there's anything special we need to test, I can just go ahead with the upload
[00:52] <broder> slangasek: thoughts on https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/858122/+attachment/2683183/+files/insserv_1.14.0-2.1ubuntu1.unstable.debdiff ? it seems reasonable (modulo needing quilt and changelog adjustments)
[00:53] <broder> if it's ok with you i can upload it and prep/upload an oneiric sru
[00:54] <smoser> slangasek, i'll start an instance and install right now.
[00:54] <smoser> ppa link ?
[00:55] <slangasek> smoser: ppa:jamesodhunt/upstart-job-logging
[00:55] <slangasek> broder: YES PLEASE

[00:56] <broder> slangasek: haha, ok. any thoughts about attempting to unwind the damage?
[00:56] <slangasek> broder: I think I sketched something out on the bug about manually putting the key bits of /etc/rc{0,6}.d back where they belong if we detect this kind of massive breakage on upgrade
[00:57] <slangasek> broder: we might not get all of it right, but we can at least get the core initscripts stuff
[00:57] <broder> ok. i'll sketch something up. it'd be nice to have you review it, since complex maintainer scripts are easy to screw up
[00:58] <slangasek> :)
[01:00] <mwhudson> what could go wrong
[01:00] <slangasek> mwhudson: little more than already has done P
[01:00] <slangasek> :P
[01:00] <broder> look, i'm absolutely terrified of uploading insserv. that's why i'm forcing slangasek to sign off on anything i do - so i can at least spread the blame :)
[01:04] <smoser> slangasek, ok. initial snif done.
[01:04] <slangasek> smoser: thanks :)
[01:04] <smoser> no kittens sacrificed. 2 instances booted twice each.
[01:13] <broder> slangasek: ok, that actually seemed a little more straightforward than expected. how does http://paste.ubuntu.com/843826/ look to you?
[01:15] <slangasek> broder: I had been thinking in terms of the fix-up being done in initscripts, as the owner of both the scripts in question and the /run transition that's gotten clobbered; are you sure that doing the fixup from insserv will dtrt everywhere?
[01:16] <broder> hmm, not really. i hadn't thought about it all that hard
[01:16] <broder> i guess i figured that correcting the shutdown sequence from anybody's postinst -> initscripts shutdown script will do the right thing next time you reboot
[01:17] <cjwatson> ScottK: bug 634215 - why are all-numeric host names prohibited?  I mean, I get that they might be considered unwise in some contexts, but my reading of RFCs 952 and 1123 in conjunction is that all-numeric host names are permitted, and indeed I think 1123 indicates that host software MUST support them
[01:17] <slangasek> broder: two other things: 1) if the runlevel's been broken, you'll see S0{1,2,3}reboot; maybe it's better to check for one of these values instead of just !90, in case the admin had some other reason for renumbering (e.g., having fixed up all their init scripts so insserv actually works for them)?  2) the fix-up needs to handle rc0 in addition to rc6
[01:18] <slangasek> cjwatson: hmmm, stgraber brought that one up the other day and I asserted that all-numeric is illegal; perhaps I should dig up a real reference :)
[01:18] <slangasek> cjwatson: in *practice*, an all-numeric hostname gets butchered by various unix tools, which will helpfully interpret it as a decimal encoding of an IP
[01:19] <broder> slangasek: ok. i guess i need to s/reboot/halt/ for rc0, but other than that fix up the same scripts in the same way?
[01:19] <broder> slangasek: but if you'd rather have this in initscripts, i'll drop the postinst from insserv and upload it, then we can work on getting initscripts fixed
[01:19] <cjwatson> slangasek: I'm not necessarily opposed to making the installer forbid them, but I feel I'd like to have chapter and verse here :)
[01:20] <cjwatson> especially since netcfg has the same algorithm
[01:20] <slangasek> broder: yes, s/reboot/halt/ should be the only change... and yeah, I have a slight preference for putting this in initscripts, rather than embedding knowledge of another package's init scripts in the insserv postinst
[01:20] <broder> slangasek: i'm fine with that
[01:21] <stgraber> cjwatson: from my last RFC reading (last week), there's nothing explicitly prohibiting the use of all-numeric host names, as long as they aren't also used as part of a DNS record (where a DNS label can't be made of all-numeric)
[01:21] <cjwatson> stgraber: where does that restriction come from?
[01:22] <stgraber> cjwatson: 1912 IIRC
[01:24] <slangasek> cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65041#34 ?
[01:24] <infinity> rfc2181 pretty much throws it all out the window, and only keeps the 63-byte restriction.
[01:25] <infinity> But there's no reason systems can be more restrictive than the RFC (and, in our case, reasons why we need to be).
[01:26] <slangasek> well, gethostbyname() is a deprecated interface, but we either have to modify its behavior or accept that anything using it will be broken with numeric hostnames
[01:26] <cjwatson> ah, gotcha
[01:26] <cjwatson> that's probably enough for me to change netcfg too then
[01:27] <slangasek> (also, not sure if the glibc implementations of the ipv6-friendly interfaces actually do a better job with them?)
[01:30]  * infinity figures the summary at the top of http://www.zytrax.com/books/dns/apa/names.html is a fair representation of the pre-2181 rules, and probably not an awful constraint for installers to impose.
[01:30] <infinity> cjwatson: ^
[01:33] <ScottK> cjwatson: The hostname itself can be all numeric (the machine name), but the top level domain (at least historically can't).  Says so in RFC 1123 paragraph 2.1.
[01:34] <cjwatson> That point's clear (although the RFC is mainly making an observation about the existing set of TLDs, I think ...), but you aren't entering an FQDN in ubiquity.
[01:35] <broder> slangasek: do you have an opinion on whether or not i should also move /usr/sbin/{update-rc.d-insserv,update-bootsystem-insserv}?
[01:35] <ScottK> infinity: I don't see anything in 2181 that changes that.
[01:35]  * slangasek looks at broder blankly
[01:35] <slangasek> broder: not knowing what these are or why they exist, I don't have an opinion :)
[01:35] <ScottK> cjwatson: It used to be that all numeric wasn't allowed for the machine name, but that changed, so maybe I was confused.
[01:36] <slangasek> "update-rc.d-insserv is an obsolete implementation [...]"
[01:36] <slangasek> seems like upstream should move that one to /dev/null
[01:36] <slangasek> and the other one is a trivial script we don't need to care about
[01:36] <slangasek> broder: ^^ so I think it's not worth moving them
[01:36] <cjwatson> The gethostbyname problem is somewhat persuasive.
[01:36] <infinity> ScottK: We weren't talking about FQDNs until just now...
[01:36] <broder> slangasek: ok. sounds good
[01:36] <ScottK> OK.
[01:36] <ScottK> never mind me then.
[01:45] <cjwatson> I've mailed debian-boot to ask if anyone cares if I make such a restriction
[01:53]  * infinity remembers the bad old days when various operating systems used to tell him that his domain name was invalid.
[01:54] <cjwatson> You were just testing them, right?
[01:56] <infinity> cjwatson: NT4 had hissy fits about 0c3.net until SP3, I believe.
[01:56] <infinity> cjwatson: Which caused me some grief.
[02:00] <broder> oh what the heck. why does insserv ftbfs, but only in sbuild
[02:00] <broder> ...with fopen(file_the_test_suite_just_wrote_out): Operation not permitted
[02:00] <infinity> broder: In your local sbuild, you mean?
[02:00] <broder> infinity: yeah
[02:00] <infinity> broder: Is that running on top of an overlayfs-using schroot?
[02:00] <infinity> broder: If so, that's your answer.
[02:00] <broder> ...seriously?
[02:01] <broder> ugh
[02:01] <infinity> broder: The good news is that the buildds won't fail that way. :P
[02:01] <infinity> broder: The bad news is you need to test without overlayfs locally.
[02:01] <broder> wait, but why does it not happen if i build it with schroot dpkg-buildpackage, but not using sbuild?
[02:02] <broder> oh, i guess that would be hitting one of the bind mounts
[02:02] <broder> what is overlayfs doing wrong?
[02:02] <infinity> broder: overlayfs plays fast and loose with inodes in ways that can confuse tools that assume that inodes don't (or do) change based on certain actions.
[02:03] <broder> oww
[02:03] <infinity> broder: The tools (or, in this case, test suite) are usually wrong, not overlayfs, but...
[02:04] <broder> ok. since i *can* build it without copying the source into the overlayfs, i'll go ahead and move forward
[02:04] <geofft> infinity: out of curiosity, is there documentation of usual overlayfs issues?
[02:04] <geofft> I have a local buildd that I was just about to switch from LVM chroots to overlayfs one of these weekends...
[02:04] <infinity> geofft: Mostly in apw's head, and scattered around to others who've had to deal with it. :P
[02:05] <infinity> geofft: If you have a working LVM setup, I see no compelling reason to switch.
[02:05] <geofft> infinity: "working" is a bit much, it randomly panics during rebuilds every so often
[02:05] <infinity> Special.
[02:06] <broder> also LVM snapshot-based chroots are borderline unusably slow, especially when there are a lot of them in action
[02:08] <infinity> Anyhow, other than "some software makes stupid assumptions about filesystems that it shouldn't" and "overlayfs doesn't support inotify", I can't think of any other known gotchas.
[02:08] <geofft> (hm, I'm misremembering, we switched it to aufs IIRC because of the slowness, and aufs brings the panics)
[02:35] <andy753421> is it possible to request a sync from a PPA instead of from debian (or maybe not a sync, but something along those lines?)
[02:35] <Daviey> andy753421: raise a sponsorship bug and link to the PPA.
[02:40] <nigelb> man, Daviey is still awake?
[02:40]  * nigelb looks at the clock and gets confused
[02:41] <Daviey> nigelb: yes
[02:41] <nigelb> Daviey: Go to bed you crzy person.. err, I mean.. Hi!
[02:41] <Daviey> nigelb: heh
[02:41] <nigelb> :)
[02:55]  * dobey wonders if he could possibly get someone to review https://code.launchpad.net/~dobey/ubuntu/precise/twisted/backport-gireactor/+merge/93329 tonight
[03:32] <broder> slangasek: that insserv fix technically needs to be sru'd to lucid through oneiric, right?
[03:54] <broder> err, that's a dumb question that i know the answer to, since i hit the bug after installing vmplayer 4 on natty
[04:40] <pitti> Good morning
[05:07] <slangasek> broder: it's beneficial to SRU it to lucid through oneiric, but the most important is oneiric because that's where things go wrong with initscripts... for the other releases, nobody's reported any bugs yet
[05:29] <soren> soren`: ?!?!?
[05:29] <soren> soren`: You're officially freaking me out.
[05:30] <soren> Oh! That thing!
[06:35] <broder> slangasek: i installed vmplayer 4 on natty before upgrading to oneiric, triggering the bug
[06:38] <slangasek> broder: and the fixed initscripts cleaned it up suitably?
[06:39] <broder> slangasek: err, haven't made it that far in testing yet
[06:39] <slangasek> ok :)
[06:39] <broder> at the time, i think i went for the "nuke it from orbit" approach of rm /etc/rc*.d/[SK]* && dpkg --reconfigure --something-clever
[06:45] <pitti> broder: --force-confmiss probably?
[06:45] <broder> i thikn i just had a complicated one-liner to figure out all the packages that had scripts in /etc/rc*.d and then reconfigure them to run update-rc.d
[07:04] <broder> slangasek: whoa!! vmware fixed their installer in 4.0.2!
[07:04] <broder> it checks for update-rc.d before insserv now
[07:08] <broder> slangasek: anyway, if i run insserv in my precise vm by hand and then install http://paste.ubuntu.com/844050/, it does seem to fixup the symlinks as expected
[07:09] <broder> it didn't seem like there was a particular spot in the postinst the code needed to live, so i picked a point a bit above the /run transition code, since it seemed like this should probably be fixed up before then
[07:26] <rickspencer3> pitti, am I reading this right? Feature Freeze is today, but only a few problems (all armel) in the archives, and all of the ISO smoke tests but one are passing?
[07:26] <rickspencer3> that's pretty cool
[07:26] <pitti> rickspencer3: yes, the recent compiz upload broke armel unfortunately :(
[07:27] <pitti> rickspencer3: otherwise it's holding up pretty well indeed
[07:28] <rickspencer3> well, I think it's a great result, especially for the week of feature freeze
[07:29] <pitti> not sure whether didrocks has a trick up his sleeve to fix compiz on armel, though
[07:29] <didrocks> pitti: the issue is in kelibs
[07:29] <didrocks> kdelibs*
[07:29] <didrocks> I ask Riddell to look at it
[07:30] <didrocks> rickspencer3: just to be clear, compiz FTBFS on armel is due to kdelibs which ship a broken header, Riddel is already aware about it
[07:30] <rickspencer3> thanks for the update didrocks
[07:31] <rickspencer3> just to be clear, I wasn't actually complaining, as I don't recall being close to this tight on previous FF days ;)
[07:31] <didrocks> yeah, it's just on this one "not compiz fault" :) (most of the time, it is, not one that though ;))
[07:32] <pitti> bdrung: do you care about the vlc FTBFS on powerpc? if not, we could just remove the powerpc binaries
[08:15] <micahg> mvo: sorry, was in the wrong channel, can I drop the intltools patch from aptitude?  it's commented out, but it's a 50k line diff
[08:19] <mvo> micahg: yeah, if po and source are in sync again that is really not needed anymore
[08:19] <micahg> mvo: is there an easy way for me to check that?
[08:21] <mvo> micahg: well, I guess what it comes down to is if there are no po file diffs in the other patches it is fine
[08:21] <micahg> mvo: ah, ok, I'll check, thanks
[08:23] <micahg> nope, no po diffs, so I can drop it from the source then (I assume it's easy to recreate again)?
[08:23] <Riddell> didrocks: as I said on the bug report nobody knows how to solve that compiler error, either get someone to port the code or drop the compiler -Werror or drop the kde compiz bits, alas I don't have time for much non-Kubuntu while I'm still allowed to work on it
[08:25] <didrocks> Riddell: ok, I'll drop the kde build from compiz then
[08:25] <didrocks> not sure anyone is using it anyway
[08:25] <didrocks> if*
[08:26] <mvo> micahg: yeah, thats fine
[08:26] <mvo> micahg: its auto generated
[08:26] <mvo> anyway
[08:26] <micahg> ok, thanks
[08:26] <mvo> ta!
[08:27] <micahg> I still need to finish it, the patches need refreshing, but I'm hopeful :)
[08:29] <Riddell> didrocks: just be gentle so we don't get "you don't care about kde" comments!
[08:30] <didrocks> Riddell: hum? I just meant that people using kde are on kwin I guess, not compiz
[08:30] <didrocks> Riddell: I'll make it clear in the changelog, no worry :)
[08:30] <Riddell> didrocks: yes you're right.  but if one troll sees it differently it could go down badly
[08:31] <didrocks> Riddell: right, will take great care on the changelog ;)
[08:31] <Riddell> (and I've had to do more than enough media and community management recently as it is!)
[08:56] <pitti> RAOF, Laney: do you have an idea about https://launchpadlibrarian.net/93054472/buildlog_ubuntu-precise-i386.tomboy_1.9.5-1ubuntu2_FAILEDTOBUILD.txt.gz ? it built fine locally
[08:56] <pitti> I guess there's a missing build dep which I have installed locally; cli-common-dev ?
[08:56]  * apw wonders how long before the archive might not remove every :i386 package he has installed
[08:57] <pitti> did that change recently? the previous tomboy built fine without it
[08:57] <pitti> apw: gcc-4.6/i386 still building :/
[08:58] <apw> the compiler causes this mess, we really should build that in a PPA and copy it in if its going to cause utter uninstall every time
[08:58] <pitti> apw: we had a lot of similar cases recently (webkit, compiz, glibc, etc.)
[08:58] <apw> pitti, i take it that means the compiler triggers a multi-arch missmatch if amd64 and i386 don't hit together
[08:59] <pitti> apw: we discussed using precise-proposed for this, so that we have ONE staging area instead of dozens of PPAs, and we can  copy binaries (which is really a main point)
[08:59] <pitti> apw: correct
[08:59] <apw> pitti, hehe thats funny, thats was my solution too :)
[08:59] <pitti> we just need a LP tweak to allow this
[08:59] <seb128> using ppa doesn't work, or we need non virtual ones
[08:59] <seb128> but yeah, -proposed would be better
[09:01] <pitti> great, and now the buildds are all firefoxed
[09:01] <apw> pitti, i guess one needs to be able to copy your own packages from devel -proposed
[09:01] <apw> for that work work any
[09:02] <pitti> apw: yes, but I don't consider that a blocker
[09:02] <pitti> initially we'd only use it for a few packages which are huge and known to cause major damage if they FTBFS or go out of sync
[09:02] <pitti> such as yesterday's mysql, or glibc, or webkit
[09:03] <apw> pitti, yeah that is a reasonable plan indeed if its optional like that
[09:03] <bdrung> pitti: vlc will build on powerpc once the final 2.0.0 is released.
[09:03] <pitti> apw: and for the time being it's a simple script invocation by any archive admin
[09:03] <pitti> sru-release precise glibc
[09:04] <pitti> (we might rename it for this)
[09:04] <pitti> bdrung: ah, thanks; I have a local build prepared that disables altivec for now, want me to try that?
[09:05] <bdrung> pitti: no. can you grab 2.0.0+git20120215+r81-0~r28~oneiric1  from https://launchpad.net/~videolan/+archive/stable-daily and try to build that on powerpc?
[09:06] <pitti> bdrung: that's more effort/responsibility than I'm willing to take
[09:06] <pitti> I don't care AT ALL about powerpc, just about getting rid of the NBS dependencies :)
[09:06] <pitti> (in fact, I think we should have killed it long ago, but *shrug*)
[09:08] <bdrung> pitti: you could either wait a few days or remove the powerpc binaries in the meantime. do what you prefer
[09:08] <pitti> bdrung: ok, thanks
[09:16] <SpamapS> oh how I love php's crappy multiarch
[09:17] <pitti> RAOF, Laney: ah, tomboy does b-dep on cli-common-dev, so it's not that
[09:18] <pitti> so, I'm lsot :/
[09:18] <Laney> pitti: It's the DLLMap in debian/
[09:18] <Laney> WebSyncServiceAddin.dll.config probably
[09:18] <Laney> the soname needs fixing there
[09:18] <Laney> did you build on a system with libproxy0 installed?
[09:19] <pitti> Laney: yes, it's still installed here
[09:19] <pitti> Laney: but the source diff was a no-change upload (http://launchpadlibrarian.net/93053939/tomboy_1.9.5-1ubuntu1_1.9.5-1ubuntu2.diff.gz)
[09:19] <Laney> the DLLMap references the soname, it needs to be updated
[09:20] <pitti> Laney: ah, so that's why it worked locally
[09:20] <Laney> yeah, it probably would have failed in a chroot
[09:20] <pitti> Laney: thanks, doing this
[09:20] <Laney> np
[09:40] <gotwig> hey
[09:41] <gotwig> where is app development channel?
[09:43] <bdrung> gotwig: look at the topic: #ubuntu-app-devel for app development on Ubuntu
[09:45] <gotwig> bdrung: it will be an app for ubuntu
[09:45] <gotwig> I know, what ever
[09:59] <vila> hi guys, I'm running precise on my laptop and did a partial upgrade this morning,
[10:00] <vila> I encountered  http://pad.lv/933343 and after reboot I can only login with the recovery console (Unity and Unity 2D are not presented anymore in the lightdm menu)
[10:01] <vila> I also encounter transient connection issues during 'apt-get update' for extras.ubuntu.com and archive.canonical.com
[10:02] <vila> apt-get -f install  failed with... ha, it was failing on the flash stuff but has just started downloading... hold on ;)
[10:29] <vila> ok, with archive.c.c letting download the flash upgrade, everything is back to normal, more fear than harm ;)
[10:49] <frafu> Hi, We released Onboard 0.97.0 yesterday and it has been accepted as onboard 0.97.0-0ubuntu1 into Ubuntu main. Shortly afterwards, a bug with translations appeared, we already fixed it in trunk and are going to release 0.97.1 today. My question: Are micro releases (i.e.:  0.97.1-0ubuntu1) accepted in feature freeze or should I rather submit it as patch creating onboard 0.97.0-0ubuntu2?
[10:50] <micahg> frafu: bug fix only releases aren't a problem generally
[10:50] <micahg> well, at least at this point
[10:56] <SpamapS> They're really not a problem up until beta
[10:56] <SpamapS> really, beta2
[11:01] <frafu> micahg, SpamapS : So bugfix micro release updates are accepted until beta2. These were the pieces of information I was looking for. Thanks to both of you.
[11:04] <SpamapS> frafu: its not a hard and fast rule.. but generally yes, fixing bugs up until the betas are out is a good idea
[11:04] <SpamapS> frafu: after beta2 .. its up to the release team
[11:10] <frafu> SpamapS: Maybe a few more words to the procedure to get it accepted until beta2: I should file a bug containing a debian source package based on the new micro release and add the Ubuntu Sponsor Team to the bug; correct?
[11:11] <SpamapS> frafu: correct. Make sure you reference upstream bug comments/commits/etc.
[11:12] <geser> the procedure should be the same as before FF (perhaps just mention in the bug that it's a bugfix release and adds no new features)
[11:12]  * SpamapS wills the PHP test suite to pass, so he can sleep
[11:13] <frafu> SpamapS, geser: Thanks
[11:22] <SpamapS> alright.. latest (sane) version of PHP uploaded..
[11:22] <ion> Isn’t that an oxymoron? :-P
[11:23] <SpamapS> PHP is perfectly sane. Its the users who keep using it expecting a different result (non-suckage)
[11:24] <micahg> SpamapS: did the new sbuild help for dependency resolution?
[11:24] <SpamapS> micahg: nope, still have to use aptitude resolver
[11:25] <SpamapS> micahg: I haven't dist-upgraded since Friday.. was a new one uploaded this week?
[11:25] <micahg> SpamapS: I uploaded it tonight, commented on your bug :)
[11:25] <SpamapS> micahg: I'm sure I'll have to build php5 again this cycle. :)
[11:26] <micahg> especially if we go to 5.4 :)
[11:27] <SpamapS> micahg: high degree of liklihood there will be *another* RC
[11:27] <ajmitch> SpamapS: did php manage to get 5.4.0 out yet? :)
[11:27] <SpamapS> micahg: they broke signal handling, badly
[11:27] <ajmitch> aha
[11:27] <SpamapS> ajmitch: they promised "late December", or "at the latest January" when I proposed 5.4.0 at UDS
[11:27] <ajmitch> the neverending story of php releases, and even then x.y.0 isn't really LTS materiel :)
[11:27] <SpamapS> well
[11:27] <SpamapS> promise is a strong word
[11:28] <SpamapS> they thought they could hit that
[11:28] <SpamapS> ajmitch: agreed
[11:28] <SpamapS> It would take a lot to convince me that 5.4.0 will have less regressions than 5.3.10
[11:28]  * ajmitch should keep 5.4 merged in his PPA
[11:29] <SpamapS> I fully expect we will ship 5.4 in 12.10
[11:29] <ajmitch> even if 5.4.0 has no regressions, there are plenty of other packages that it can break
[11:30] <ajmitch> so mariadb vs mysql might get sorted at UDS?
[11:30]  * micahg hopes it gets sorted before release
[11:31] <SpamapS> Heh, its a hot button item. definitely needs wide discussion.
[11:31] <ajmitch> that'd be preferable, with the 5 year support thing :)
[11:32] <SpamapS> I had hoped to sort it by today, but I'd rather go the FFE route than jump blindly into something we don't fully understand.
[11:39] <tmus> What do I need to do, to try to make sure, a specific package is pulled from upstream (debian) into precise? This particular package is not a base/core package, but something that really should be in repo in a modern version... (pmacct - version 0.12.5 - http://packages.debian.org/sid/pmacct)
[11:41] <SpamapS> tmus: it needs to be merged
[11:42] <SpamapS> tmus: actually.. it looks like it can be synced
[11:44] <micahg> tmus: requestsync unless SpamapS is already processing it
[11:44] <tmus> SpamapS, can I somehow "suggest" such a sync somewhere?
[11:44] <tmus> micahg, aah, googl'ing requestsync
[11:44] <SpamapS> tmus: yes there is a program, 'requestsync', that will file a bug
[11:44] <micahg> tmus: install ubuntu-dev-tools (available in debian as well)
[11:44] <SpamapS> syncpackage: Request succeeded; you should get an e-mail once it is processed.
[11:45] <SpamapS> yes, sorry.. next time.. use requestsync. :)
[11:46] <tmus> SpamapS, Does that mean you requested a sync of it right now? :-)
[11:46] <SpamapS> alright and with that, I will retire to my tempurpedic
[11:46]  * micahg wonders if SpamapS can build something that fast
[11:46] <SpamapS> micahg: pmacct is tiny
[11:46] <SpamapS> micahg: and the Ubuntu delta was my own, which was applied in Debian. :)
[11:47] <micahg> heh, previous experience ftw :)
[11:47] <SpamapS> I should go back through all the libmysqlclient bugs I filed and sync back up
[11:47] <tmus> awesome! :-)
[11:47] <SpamapS> anyway, right now, I will retire to the tempurpedic
[11:47] <tmus> thanks
[11:49] <SpamapS> tmus: should be available within 60 minutes in precise
[11:49] <SpamapS> tmus: I stand corrected.. should be available on i386 within 60 minutes in precise ;)
[11:49] <SpamapS> more like 3 - 4 hours on amd64
[11:50] <SpamapS> FF always backs up the buildds :-P
[11:50] <micahg> yeah, someone's hogging a lot of the buildds :)
[11:50] <infinity> micahg: *stare*
[11:50] <tmus> SpamapS, perfect... I know of a few minor issues with it - already resolved locally - and communicated upstream. Will it simply be re-sync'ed later on or do I need to file bugs and patches for the ubuntu version as well?
[11:50] <micahg> :D
[11:51]  * micahg is actually surprised at the lack of feature freeze uploads
[11:51]  * micahg will upload aptitude when he wakes up
[11:51] <ogra_> must be the LTS-nature of this release
[11:52] <SpamapS> Yeah we're actually trying not to break this one  ;)
[11:52] <SpamapS> tmus: You will need to use requestsync if things are fixed in Debian
[11:53] <SpamapS> tmus: auto-syncing will resume after precise is released
[11:53] <tmus> SpamapS, okay, cool - I'll make sure things are fixed in debian
[11:53] <tmus> Thanks a lot
[11:53] <SpamapS> tmus: if Debian can't get them fixed.. then feel free to file a bug w/ a patch in Ubuntu as well, and subscribe ubuntu-sponsors ..
[11:53] <SpamapS> ok
[11:53] <SpamapS> sleep
[11:53] <SpamapS> now
[12:38] <hrw> yes! finally gcc-4.6 landed in archive
[12:39] <hrw> time to rebuild cross toolchain
[13:25] <cjwatson> bdrung: FYI your vlc package (that you were talking about with pitti this morning) fails to build on powerpc; are you already aware of that or do you want the log?
[13:25] <pitti> cjwatson: I talked to bdrung about it this morning
[13:26] <pitti> he says the final release will fix it
[13:27] <cjwatson> I read that discussion, and he said to try a PPA package which should fix it.  I tried it and it didn't.  That's why I'm mentioning it to him
[13:27] <cjwatson> Looks like missing -maltivec when building the altivec module, possibly.
[13:32] <valavanisalex> Hi All, I'm planing an update of the Inkscape package to the latest upstream version (the Debian maintainer is inactive).  My issue is that the Debian package uses the now-obsolete dpatch system, and this is giving me a lintian error (not warning).  Do I just ignore the error, or should I convert the package to using quilt?
[13:33] <cjwatson> It's best not to do major packaging rearrangements as Ubuntu deltas, on the whole
[13:33] <cjwatson> The purpose of the Lintian error is to encourage Debian maintainers to stop using dpatch
[13:34] <cjwatson> At this point it's not a big deal for Ubuntu, except in that we'd generally like to reduce the breadth of alternatives in our packaging tools; but not urgent, anyway
[13:35] <valavanisalex> Great, thanks for the explanation.  I'll just update the upstream component of the package then, and leave the patch system alone.
[14:48] <mdeslaur> slangasek: dpkg-reconfigure doesn't know about $DPKG_MAINTSCRIPT_ARCH?
[14:53] <barry> mvo: hi.  have some time today to talk about bug 876298 ?
[14:58] <mvo> barry: I have a meeting now, maybe later?
[14:59] <barry> mvo: devx?  me too (if i can get it to work this time ;).  after would work
[15:03] <mvo> barry: yeah, devx - its in g+
[15:04] <barry> mvo: i think i need to be invited.  i don't see it
[15:07] <mvo> barry: oh, sorry
[15:10] <Daviey> cjwatson / doko: Please don't scream.. but the experimental python udeb.. still an option?
[15:10] <Daviey> (^ roaksoax: fyi)
[15:11] <doko> Daviey, it's in the archive
[15:14] <Daviey> it is?!  I thought it was still a 'maybe'
[15:14] <cjwatson> it's only there for python3.2
[15:14] <cjwatson> rmadison -s precise -S python3.2
[15:16] <Daviey> ahh
[15:17] <cjwatson> shouldn't be that hard to use python3 for a new project
[15:22] <Daviey> cjwatson: right
[15:28] <doko> bah, the new Xorg with nividia drivers is so unstable ... getting logged out every 2h
[15:30] <ogra_> doko, use a tegra ;) thats stable nvidia ;)
[15:36] <apw> cjwatson, i have an initramfs-tools update to include hyper-v modules to allow root to be on paravirualised disks, i am wondering if you might be able to look it over: lp:~apw/ubuntu/precise/initramfs-tools/add-hyper-v-drivers
[15:40] <cjwatson> apw: looks good to me
[15:44] <Riddell> TheMuso: I am getting lots of reports of "Failure: Module initalisation failed" on start-pulseaudio-kde, can you check?
[15:46] <slangasek> mdeslaur: dpkg-reconfigure> correct
[15:48] <meerkats> what does linux-source synaptic's package do?
[15:48] <mdeslaur> slangasek: ok, so I have to get rid of $DPKG_MAINTSCRIPT_ARCH in the flash packages then. So...would having the rules file sed a "postinst.in" file with $DEB_BUILD_ARCH be the right way?
[15:49] <slangasek> mdeslaur: oh bah.  well, it should be DEB_HOST_ARCH
[15:51] <apw> cjwatson, would you be able to upload that puppy
[15:51] <mdeslaur> slangasek: why DEB_HOST_ARCH vs DEB_BUILD_ARCH?
[15:51] <apw> (and thanks for reviewing)
[15:51] <slangasek> mdeslaur: because of the definitions of host and build in the C standards :)
[15:51] <cjwatson> mdeslaur: DEB_BUILD_ARCH is the architecture you're building the source package on; DEB_HOST_ARCH is the architecture you're building for.  They differ in the case of cross-compiling
[15:51] <slangasek> mdeslaur: host is always the arch that the code is hosted on; while it's unlikely anyone will ever need to cross-build a flash package, we should still use the right variable
[15:52] <m4n1sh> ev: hey
[15:52] <ev> m4n1sh: hi
[15:52] <mdeslaur> cjwatson, slangasek: ah! thanks for the explanation, that makes sense
[15:52] <m4n1sh> ev: you got any update about contributor agreement?
[15:55] <cjwatson> apw: done
[15:55] <apw> cjwatson, thanks a lot
[15:55] <ev> m4n1sh: nothing yet. I'll keep you posted
[15:55] <m4n1sh> ev: so if I integrate it in alm, then what about the code in whoopsie?
[15:55] <m4n1sh> duplicated?
[15:56] <ev> m4n1sh: can you elaborate? I don't follow.
[15:56] <m4n1sh> means
[15:56] <m4n1sh> I take those two files
[15:56] <m4n1sh> and integrate it
[15:56] <m4n1sh> then this functionality is in two pakages
[15:56] <m4n1sh> *packages
[15:56] <m4n1sh> are you going to disable that in whoopsie?
[15:57] <m4n1sh> ev: is whoopsie going to be enabled by default? right?
[15:59] <ev> m4n1sh: the idea is that we'll take the preferences page code from whoopsie, put it in a GtkNotebook page in activity-log-manager, and then remove the code from whoopsie.
[15:59] <m4n1sh> hmmm
[15:59] <m4n1sh> yeah, I am working on it
[15:59] <m4n1sh> looks fine
[15:59] <m4n1sh> it uses gtkbuilder
[16:00] <ev> m4n1sh: I'm not sure if it falls under the contributor agreement or not yet, and given that today is feature freeze, I'll be doing an upload of whoopsie where the page it creates in GNOME Control Center is called "Diagnostics" rather than its current "Privacy"
[16:00] <m4n1sh> okay
[16:00] <m4n1sh> as per Colin this falls outside FF
[16:00] <ev> indeed
[16:00] <m4n1sh> so should be fine to move it from one to other
[16:00] <m4n1sh> so it is in main?
[16:01] <ev> it will be by the end of the day
[16:02] <m4n1sh> okay
[16:24] <pitti> ev: hm, does 'test/run local' work for you in your whoopsie apport branch?
[16:25] <pitti> ev: I get a ton of errors in apport/ui
[16:25] <pitti> ev: 'NoneType' object has no attribute '__getitem__'
[16:25] <ev> eep
[16:25] <ev> I had been running test/{gtk,kde} manually
[16:25] <apw> yay ... unity now rendering the archive uninstallable
[16:25] <davidcalle> Hi everyone, I'm looking for an archive admin to look at two new packages in the universe queue.
[16:25] <ev> will fix now
[16:26] <pitti> ev: thanks; reviewing in the meantime
[16:26] <ev> cheers
[16:26] <pitti> ev: I need to run out in about 10 mins, I'd rather finish this tomorrow morning than crowbaring it in today
[16:26] <pitti> skaet: ^ if that's alright with you
[16:26] <pitti> skaet: (these are the apport GUI and logic changes for whoopsie)
[16:26] <ev> pitti: sure thing
[16:26] <pitti> ev: I'll test this locally in the meantime
[16:27] <ev> cheers
[16:27] <skaet> pitti, ev =1
[16:31] <rbasak> I have a line that creates a .so with: 'gcc -shared -Wl,-soname=lib$$i-openmpi.so.1 -o lib$$i-openmpi.so.1.1 -L/usr/lib/openmpi/lib/ -lmpi -lmpi_f77 $$(find tmp -name "*.o")'. The generated .so does not declare dependencies on libmpi and libmpi_f77. I know order matters, so I tried moving the -l's to the front, and also tried -Wl,-E. What am I doing wrong?
[16:32] <ev> pitti: weird. I only get two failures in ./test/run local. Both relate to add_gdb_info: readelf: Error: /tmp/core: Failed to read file's magic number.
[16:32] <pitti> ev: hmm, weird; I'll have a look at this tomorrow morning then
[16:33] <ev> pitti: cheers
[16:36] <ev> FWIW, I just did a bzr export /tmp/apport-whoopsie; ./setup.py build; ./tests/run local and it worked just fine (well, with the same two errors)
[16:40] <pitti> ev: I followed up to the MP with various bugs
[16:40] <ev> pitti: okay, reviewing now
[16:41] <pitti> I'll look at the ui.py test crash tomorrow then
[16:41] <pitti> need to run now, sorry (theater tonight)
[16:43] <doko> Calculating upgrade... Done
[16:43] <doko> The following packages will be REMOVED:
[16:43] <doko>   unity
[16:43] <doko> \o/
[16:45] <didrocks> doko: this is what happen with ABI breakage and correctly handled packaging to prevent you partial upgrade
[16:46] <didrocks> doko: rmadison tells that 5.2.0-0ubuntu5 is published now
[16:47] <doko> didrocks, no, this is when you assume features are implemented in Debian, but not in Launchpad, and not working around these
[16:47] <didrocks> doko: do you prefer I don't break on older version and let people upgrade at a bad time?
[16:47] <didrocks> so that they start with the new compiz and unity fail to load?
[16:51] <seb128> doko, when the compiz abi change unity needs a rebuild, without rebuild it will not start ... what is your issue with the way it's handled?
[16:51] <doko> well, removing unity will make the system unusable as well?
[16:51] <seb128> well, it's an apt bug
[16:51] <seb128> it should put compiz on hold
[16:51] <seb128> not remove unity
[16:51] <cjwatson> IWBNI somebody could encapsulate this situation in an apt integration test case
[16:52] <cjwatson> they're not that hard to write if you can work out what exact dependency relationships trigger it
[16:52] <seb128> cjwatson, do you have any documentation on how to do that? or an example?
[16:52] <didrocks> cjwatson: maybe I can give it a try (will probably need guidance from where to look at), but will be after UIF
[16:52] <seb128> I can have a look (not this week though)
[16:52] <didrocks> or seb128 can :)
[16:53] <seb128> cjwatson,it's not really a "bug", I guess compiz scores high since it got rdepends and unity lower since it doesn't
[16:54] <seb128> the way to fix that would be to upload to proposed and pocket copy as it was discussed at UDS I guess
[16:54] <didrocks> yeah, we definitively should do that, will be way easier
[16:54] <didrocks> seems for nux -> unity -> unity-2d
[17:00] <cjwatson> seb128: I found it fairly self-explanatory when I looked in apt/test/integration/
[17:00] <cjwatson> e.g. test-bug-657695-resolver-breaks-on-virtuals
[17:01] <seb128> cjwatson, thanks for the pointer
[17:01] <seb128> in apt's source then ;-)
[17:01] <cjwatson> yeah
[17:01] <cjwatson> that test was for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657695
[17:01] <cjwatson> (I didn't write the test, though I should have done :-) )
[17:24] <m4n1sh> ev: do I need to copy those .policy, .conf and .service file too?
[17:24] <m4n1sh> is it for server or preferences client?
[17:26] <ev> m4n1sh: everything in the preferences directory is required for the whoopsie gnome control center page to function properly
[17:26] <m4n1sh> ev: I dont think .desktop file is needed
[17:26] <ev> m4n1sh: everything except that :)
[17:27] <m4n1sh> ev: I can integrate it easily
[17:27] <m4n1sh> can you make some minor changes in the codebase?
[17:27] <ev> m4n1sh: the privileged dbus backend is definitely required though.
[17:27] <ev> m4n1sh: what's that?
[17:27] <m4n1sh> whoopsie_daisy_preferences_panel_init contains all the glue code
[17:27] <m4n1sh> it should be outside
[17:27] <m4n1sh> and should be invoked from the method
[17:28] <m4n1sh> otherwise I am not able to understand which is a part of it and which is not
[17:28] <m4n1sh> part of cc integration and which for whoopsie
[17:28] <m4n1sh> so that I just have a g_box
[17:29] <m4n1sh> a method call which will give me GtkBox
[17:29] <m4n1sh> ev: so that i can put it in the Notebook
[17:30] <ev> m4n1sh: I'll endeavor to fit that in tomorrow, or at worst, early next week
[17:30] <ev> quite busy with changes to apport at the moment
[17:30] <m4n1sh> apport for for bug reporting?
[17:31] <ev> m4n1sh: yes
[17:31] <m4n1sh> okay
[17:31] <m4n1sh> I will try myself
[17:31] <m4n1sh> I am pretty bad at C
[18:01] <ev> pitti: found the reason why I wasn't seeing this test failure. ./tests/run exits on the first test failure, which I was getting for those gdb ones. I've fixed this in my branch (but not your other concerns yet).
[18:04] <lifeless> barry: #launchpad-dev please ;)
[18:22] <broder> does debian currently support using sysvinit without using insserv?
[18:22] <broder> (i'm trying to figure out if i can kick bug #884402 back to rra, since our update-rc.d is, in fact, identical to debian's)
[18:34] <slangasek> broder: only in the sense that sysv-rc is not mandatory
[18:35] <slangasek> if you have sysv-rc installed, you have insserv installed; but there are still alternatives to it in the Debian archive, such as file-rc
[18:35] <broder> slangasek: there's a comment in update-rc.d: "[...] upgraded systems might keep the legacy ordering until the sysadm choose to migrate to the new ordering method"
[18:35] <broder> which makes me think that debian intends to support running without switching to insserv for an arbitrary period of time
[18:36] <slangasek> oh, yes, you can have insserv installed but not active
[18:37] <broder> i'm assuming that the shibboleth-sp2 bug would be reproducible on debian if you deactivated insserv, because update-rc.d looks completely self-contained and is identical between debian and ubuntu
[18:39] <broder> i guess i can test that easily enough
[18:45] <kelemengabor> hi dobey, do you have a little time to review the merge proposal for bug #856728 ?
[18:45] <kelemengabor> kenvandine: same question to you with bug #926665 :)
[18:46] <kelemengabor> just some trivial i18n fixes
[18:47] <dobey> kelemengabor: not before 2100Z, so probably not today; but ping me tomorrow
[18:47] <kelemengabor> will do, thanks!
[19:00] <stgraber> kirkland: pastebinit 1.3 will ship without your scripts as they're still in bkieshed, let me know when it's no longer the case and I'll update pastebinit
[19:01] <kirkland> stgraber: k -- i can do that asap today
[19:01] <kirkland> stgraber: would you be willing to update subsequently?
[19:01] <stgraber> kirkland: sure, I'm planning the pastebinit 1.3 upload within the next hour or so
[19:02] <kirkland> stgraber: okay, give me a moment ...
[19:02] <kirkland> stgraber: where can I find your code to make sure the current functionality is identical?
[19:02] <stgraber> kirkland: lp:pastebinit
[19:02] <kirkland> stgraber: 18579bab7d17780bcceae23b8b7dd01d  pbput
[19:03] <stgraber> kirkland: doesn't match :(
[19:03] <kirkland> stgraber: let me diff
[19:04] <kirkland> stgraber: okay, looks good;  changes are http://paste.ubuntu.com/844801/
[19:04] <kirkland> stgraber: ie, license only changes
[19:05] <stgraber> kirkland: ok, good
[19:06] <kirkland> stgraber: changes committed;  i'm releasing and pushing right now
[19:06] <kirkland> stgraber: bikeshed 1.21 no longer contains pbput/pbget
[19:07] <stgraber> kirkland: perfect
[19:07] <kirkland> stgraber: uploaded
[19:07] <kirkland> stgraber: thanks!!!
[19:08] <stgraber> np, sorry it took so long ;)
[19:09] <slangasek> broder: followed up on the update-rc.d bug; shibboleth is plainly invoking it wrong
[19:15] <Laibsch> ping stgraber
[19:15] <stgraber> Laibsch: hey!
[19:15] <Laibsch> I'm almost dying, but I'm preparing another upload
[19:15] <stgraber> Laibsch: awesome, thanks!
[19:15] <Laibsch> what version is the last bikeshed package?
[19:15] <stgraber> Laibsch: kirkland just uploaded bikeshed 1.21
[19:15] <Laibsch> OK
[19:16] <Laibsch> I'll conflict with anything before that
[19:16] <stgraber> sounds good
[19:16] <Laibsch> I'll pastebin a diff, I'm too tired to deliver quality
[19:22] <Laibsch> stgraber: http://paste.debian.net/156526/ is what I'm thinking about (with proper changelog, of course)
[19:22] <Laibsch> will compile now and see if the result is as expected
[19:30] <stgraber> Laibsch: diff looks good (haven't tried it though)
[19:31] <Laibsch> alright
[19:31] <Laibsch> the scripts currently end up in /usr/bin/utils
[19:32] <Laibsch> which is not the intention
[19:32] <stgraber> utils/* usr/bin then
[19:34] <Laibsch> yeah, I guess
[19:34] <Laibsch> but not sure
[19:35] <Laibsch> 25 or 85 minutes left?
[19:36] <stgraber> Laibsch: 85
[19:50] <stgraber> Laibsch: let me know when it's in incoming as it'll need manual syncing from there
[19:50] <Laibsch> sure
[19:50] <Laibsch> I'm still fixing some minor issues
[19:50] <slangasek> SpamapS: does bug #933566 ring any bells with you (upstart job with no main process, fails to run pre-stop script)?
[19:51] <Laibsch> stgraber: can you grab from incoming or is there a chance you might not get the upload in time?
[19:51] <SpamapS> slangasek: restart and pre-stop do not play nicely.. hmm.. reading
[19:51] <Laibsch> maybe I should provide you with a debdiff to current testing just in case
[19:51] <slangasek> SpamapS: yeah, this isn't restart, just stopping
[19:52] <stgraber> Laibsch: I'll grab from incoming and push manually. Debdiff works too.
[19:53] <Laibsch> unstable package is building now
[19:59] <SpamapS> slangasek: very strange. I'd love to see the full syslog from an affected box at shutdown.
[19:59] <om26er> Is there a way to know how many packages I got sponsored to Ubuntu archives?
[19:59] <slangasek> SpamapS: well, this is the only job on my system that uses pre-stop+pre-start w/o a main process, so I'm not sure there's anything to compare it with
[20:00] <broder> om26er: you can look at https://launchpad.net/~broder/+uploaded-packages and https://launchpad.net/~broder/+synchronised-packages (substitute your lp id as necessary)
[20:00] <slangasek> or just use /~/
[20:00] <broder> oh right, i always forget about that
[20:01] <om26er_> broder, ah, great thanks :)
[20:02] <broder> om26er_: that list may not be complete - it will only list uploads where your name was at the end of the changelog entry. sometimes sponsors will re-sign the changelog if they make extensive changes before uploading
[20:02] <broder> so if you know there are cases where that happened, you'll need to keep track of them yourself
[20:04] <om26er_> that have happened on rare occasions but I'll keep track. thx
[20:04] <micahg> om26er_: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
[20:05] <broder> slangasek: Bear in mind that dbus is not running on servers by default> uh, i don't think that's been true for a very long time
[20:05] <slangasek> broder: really?
[20:06] <broder> i thought the default install had included dbus since the lucid era or so
[20:06] <slangasek> hmmm
[20:06] <slangasek> it's in task: standard, which I suppose might do it
[20:09] <Laibsch> stgraber: got disconnected, but upload is finished now.  good night.
[20:12] <stgraber> Laibsch: thanks!
[20:13] <stgraber> Laibsch: will wait for it to show up on incoming and will grab it from there.
[20:14] <micahg> stgraber: it's there
[20:14] <stgraber> micahg: I'm waiting for -2
[20:14] <micahg> ah :)
[20:22] <slangasek> SpamapS: interesting report of nfs mounts not working reliably, fwiw: bug #933575
[20:24]  * TorpedoSkyline weeps at the departure of jono
[20:26] <highvoltage> TorpedoSkyline: hmm?
[20:28] <TorpedoSkyline> highvoltage: jono left the chatroom.
[20:28] <TorpedoSkyline> I always liked jono. I'd like to talk to him next time he comes on.
[20:31] <TorpedoSkyline> that was weird.
[20:33] <EtienneG> quick question about isc-dhcp (slangasek, perhaps?): I see we are on 4.1.1 in precise, while Debian unstable is on 4.2.2.  Are we staying on 4.1.x in the LTS to benefit from 4.1 being an "ESV"?  (http://www.isc.org/software/dhcp/versions)
[20:33] <EtienneG> ESV == Extended Supported Version, in ISC parlance
[20:34] <slangasek> EtienneG: I don't believe it was an explicit decision; we're on 4.1.1 because that's the latest version in Debian testing
[20:34] <slangasek> and for the LTS we sync from testing, not unstable
[20:35] <EtienneG> slangasek, fair enough.  Someone pointed out to me that we where "behind" in term of isc-dhcp, but I guess it make most sense to stick to the ISV "ESV" release
[20:35] <stgraber> Daviey: speaking of isc-dhcp-server, what's the status of the work item to get it upstartified with a job for dhcp4 and one for dhcp6?
[20:35] <slangasek> stgraber: ^^ have you put any thought into isc-dhcp 4.2 for precise?  I think you may have mentioned it before but I don't remember the context
[20:35] <slangasek> right, dhcp6 server, that would've been it ;)
[20:37] <stgraber> slangasek: I only had a quick look at the isc-dhcp version, but 4.1 looked good because of ESV and it wasn't clear what would be the benefit of 4.2 (except for the nightmare of getting it to build + apparmor + ...)
[20:37] <Daviey> stgraber: untouched.
[20:37] <slangasek> stgraber: ok
[20:38] <stgraber> Daviey: will you have it done for 12.04?
[20:38] <Daviey> stgraber: i hope so, but the whole team are currently cooking way over capacity
[20:38] <Daviey> which means the best i can say is 'maybe', not a commitment at this stage
[20:39] <slangasek> bladernr_: hi, can we talk about bug #933723?
[20:39] <stgraber> Daviey: ok, should I still the work item then?
[20:39] <stgraber> Daviey: *steal
[20:39] <bladernr_> slangasek:  sure
[20:39] <slangasek> bladernr_: do you see this 127.0.0.1/example.org somewhere under /run/resolvconf?
[20:40] <slangasek> if so, what file / can you pastebin it for me
[20:43] <Daviey> stgraber: If you did, you'd earn beer tokens
[20:45] <bladernr_> slangasek:  http://pastebin.ubuntu.com/844946/
[20:45] <bladernr_> looks like it's actually pulled in interface/lo.named
[20:45] <bladernr_> :/
[20:45] <bladernr_> hrmmm
[20:45] <slangasek> bladernr_: right, so you've got bind9 installed and running and hooking itself into resolvconf
[20:45] <slangasek> not a resolvconf bug ;)
[20:46] <bladernr_> apparently so...
[20:46] <slangasek> but I think by default, bind9 is supposed to *not* do resolvconf
[20:46] <bladernr_> and about as soon as I started catting files in run I realized that
[20:46] <bladernr_> hehe
[20:46] <bladernr_> that's good then... that means perhaps this is easily solvable on our end... just gotta figure out why bind is being installed
[20:47] <bladernr_> slangasek:  sorry to alarm you :)
[20:47] <slangasek> bladernr_: n/p - is it actually breaking name resolution, btw?
[20:47] <slangasek> I think the bug should probably be reassigned to bind9
[20:48] <bladernr_> well, we don't actually USE bind
[20:48] <bladernr_> I'm not sure why it's being installed
[20:48] <slangasek> because if bind9's not working as a local resolver out of the box, the default value for the bind9/run-resolvconf template should be fixed
[20:48] <bladernr_> ugh... thi smeans there like 50+ machines in the lab all running their own nameservers
[20:48] <bladernr_> oh, well yes
[20:48] <bladernr_> to answer THAT question...
[20:49] <slangasek> nothing so wrong with running a caching-only nameserver as long as it works ;)
[20:49] <bladernr_> BUT, we're not configuring bind, so that may not really be a problem with bind iether
[20:50] <slangasek> bladernr_: so hostname resolution *is* broken?
[20:51] <bladernr_> well... define broken... as I said, bind is being installed but we're not actually configuring or doing anythihng with it.
[20:51] <slangasek> I'm asking you if host lookups work
[20:51] <bladernr_> that being said, we get NO resolution with the resolvconf including 127.0.0.1
[20:51] <bladernr_> no
[20:51] <slangasek> ok
[20:52] <slangasek> then bind9 is broken out of the box and mustn't hook into resolvconf by default
[20:52] <bladernr_> so as soon as I purged bind9, resolv.conf was re-written and now includes the working nameserver line from eth0
[20:52] <bladernr_> also...
[20:52] <broder> bladernr_, slangasek: err, i've used bind9 as a local resolver out of box
[20:52] <broder> is this a policy-rc.d-at-install-time interaction?
[20:53] <slangasek> bladernr_: are there firewalls blocking bind from forwarding DNS requests to arbitrary DNS servers on the internets?
[20:53] <slangasek> broder: no, because bind9 *only* hooks into resolvconf *from* its init script :)
[20:53] <broder> slangasek: ok, good. that's what i suspected, but didn't have the code in front of me yet
[20:53] <bladernr_> slangasek:  you have now exhausted my DNS vocabulary and ability :(
[20:54] <slangasek> bladernr_: is there a firewall ;)
[20:54] <bladernr_> we have no firewalls on the machines...
[20:54] <bladernr_> :)
[20:54] <bladernr_> heh
[20:54] <slangasek> bladernr_: bind9 *should* work without further configuration; however, it will fail to do so if it can't actually reach port 53 on the public internet
[20:54] <slangasek> bladernr_: yes, but is there a fw for the lab as a whole
[20:55] <bladernr_> yeah, just thought about that...
[20:55] <bladernr_> because we're pointing servers to the satellite as the nameserver, that could well be the case then.
[20:55] <bladernr_> sorry for being dense
[21:19] <barry> Riddell, ScottK: any thoughts on these build failures?  they don't fail for me locally.  build skew perhaps?  https://launchpad.net/ubuntu/+source/telepathy-qt4/0.9.0+repack-0ubuntu2
[21:23] <jtaylor> barry: in -packaging a django dev wants to talk about django 1.4 in precise, you had some uploads of it maybe you want to speak to him
[21:23] <Riddell> barry: I added test coverage cos mterry demanded it to feel warm and fuzzy, it works for me locally too but it seems to need an LD_LIBRARY_PATH set to keep it happy in soyuz
[21:24] <Riddell> I can look at it tomorrow or feel free to fix it
[21:24] <barry> virtualenv 1.7.1 was just released.  i'm thinking about upgrading our 1.7-1 to it.  any objections
[21:24] <Riddell> it's cdbs which I seem to have lost the nack of a bit
[21:24] <mterry> Riddell, it's cold in Massachusetts!  Tests keep me warm
[21:25] <Riddell> yeah you need something to keep your CPUs busy to keep the room temperature up I get you
[21:25] <barry> Riddell: i can take a look.  if you don't see an upload fixing it today, you'll know i failed miserably :)
[21:25] <Riddell> thanks barry
[21:29] <chrisccoulson> mterry, it seems like you should try building webkit. that would definitely keep you nice and warm
[21:29] <chrisccoulson> ask seb128 about that, he's our webkit expert now ;)
[21:29] <mterry> chrisccoulson, no way.  I'm worried if I bring it up, he'll be like "you like webkit?  it's yours"
[21:29] <seb128> chrisccoulson, did mterry just volunteered to maintain webkit?
[21:29] <seb128> \o/
[21:29] <mterry> fuck
[21:30] <chrisccoulson> heh
[21:30] <seb128> lol
[21:41] <stgraber> kirkland: new pastebinit for you ;) enjoy!
[21:45] <kirkland> stgraber: cheers mate
[21:45] <kirkland> stgraber: one question for you...
[21:46] <stgraber> kirkland: sure
[21:46] <kirkland> stgraber: do you publish ppa builds of pastebinit for older ubuntu releases?
[21:46] <kirkland> stgraber: ie, i always simultaneously push my projects (bikeshed included) to a ppa for all supported ubuntu releases
[21:46] <kirkland> stgraber: and some of my users track those
[21:46] <kirkland> stgraber: so someone who's running, 10.04, say, that's tracking my bikeshed ppa
[21:47] <kirkland> stgraber: will update tomorrow, and actually lose pbput/pbget
[21:47] <stgraber> kirkland: nope, I usually release once a year or every two years, never bothered setting up a PPA for it ;) (I do for most of my other projects though)
[21:47] <stgraber> kirkland: I guess pastebinit would be interesting to backport though if there's interest
[21:47] <kirkland> stgraber: okay, i'll push a copy of pastebinit sources to the ppa:bikeshed/ppa
[21:47] <kirkland> stgraber: yeah, if you had one already in a ppa, I'd just pocket copy it
[21:47] <stgraber> kirkland: ok, sounds good, make sure you remove the dh_python2 stuff though as it won't work on lucid
[21:47] <micahg> kirkland: stgraber: pastebinit seems like a good candidate for backports
[21:47] <kirkland> stgraber: if not, I'll just upload
[21:48] <kirkland> stgraber: nah, i'll just set my ppa's builds to backports ;-)
[21:48] <stgraber> kirkland: won't work, dh_python2 isn't even in lucid backports ;)
[21:48] <kirkland> stgraber: oh
[21:48] <kirkland> stgraber: shucks
[21:49] <stgraber> micahg: yep, I'm really surprised nobody did it already, I guess people are happy with the default pastebin and don't need the new stuff :)
[21:49] <TorpedoSkyline> when does hardy die?
[21:50] <tumbleweed> TorpedoSkyline: http://wiki.ubuntu.com/Releases
[21:50] <TorpedoSkyline> thx tumbleweed
[22:10] <dobey> barry: ping; why does python-dbus depend on python-dbus-dev?
[22:12] <barry> dobey: from the control file:
[22:12] <barry> # Depends on python-dbus-dev for backwards compatibility, until packages
[22:12] <barry> # are fixed to depend on that directly
[22:12] <barry>  
[22:13] <dobey> boo.
[22:14] <barry> dobey: could you file a bug here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=dbus-python
[22:15] <dobey> i guess i should just run reportbug or something. that web page is confusing
[22:16] <barry> reportbug -B debian i think does it (but i have to look at the manpage every time)
[22:20] <dobey> i guess i have to tell it that it doesn't have direct internet access or something. eh, i don't really feel like dealing with configuring a bug reporting tool to be able to report a bug, right now :-/
[22:21] <cjwatson> or just use the mail interface, takes a few minutes to learn :)
[22:22] <cjwatson> submit@bugs.debian.org with body "Package: dbus-python" / "Version: ITS-VERSION-NUMBER" / blank line / your report
[22:22]  * dobey prefers apport
[22:23] <cjwatson> which is fine but I just told you how to work this one in one line of IRC
[22:23] <cjwatson> so, not *that* hard
[22:23] <dobey> i'm not saying it's hard
[22:24] <dobey> i'm saying it's work :)
[23:01] <ScottK> dobey and barry: There's no need to file a bug with dbus-python.  The maintainer's well aware.
[23:26] <sabdfl> congrats on FF folks
[23:29] <RAOF> @pilot in
[23:39] <bdrung> cjwatson: can you provide a build log for the stable-daily vlc package?
[23:45] <barry> ScottK: cool
[23:53] <andy753421> Is there a naming convention that I should follow for having the a package for different ubuntu versions in a ppa?
[23:53] <andy753421> I'm thinking something like mypackage_0.7-1ppa1.11.10.dsc and mypackage_0.7-1ppa1.12.04.dsc or something?
[23:55] <infinity> andy753421: If you want 0.7-1 to be higher, then you want 0.7-1~ppa...
[23:55] <infinity> andy753421: But tacking the release version on the end is a reasonable way to keep them in a sane order, sure.