[00:15] <LPCIBot> Project devel build #983: STILL FAILING in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/983/
[00:17] <StevenK> !!!
[00:17] <StevenK> Jenkins is back!
[00:37] <LPCIBot> Project db-devel build #816: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/db-devel/816/
[00:53] <gary_poster> Hello everybody.  I believe trunk is still broken.  This fixes the last test (monkey-see monkey-do from what wgrant submitted for fixing the other tests) but I don't know if it is correct.  http://pastebin.ubuntu.com/672811/ Can anyone verify?  If so, I'll do another testfix.
[00:54] <gary_poster> lifeless, wallyworld, are either of you around and able to verify correctness?
[00:54] <gary_poster> FWIW, this runs the failing test:
[00:54] <gary_poster> ./bin/test -cvvt lp.bugs.model.tests.test_bugtask.TestValidateTransitionToTarget.test_sourcepackage_to_sourcepackage_in_same_series_works
[00:55] <wallyworld> gary_poster: i'll have a look
[00:55] <gary_poster> thank you wallyworld
[00:55] <wallyworld> np
[00:55] <wallyworld> gary_poster:  i think wgrant submitted a test fix - are you saying it's still broken?
[00:55] <wallyworld> or is this a different issue?
[00:56] <gary_poster> yes wallyworld.  He missed one test.  I copied his fix pattern to the remaining one.
[00:56] <wallyworld> ah, right
[00:56] <wallyworld> perhaps we should nuke bb
[00:56] <StevenK> No LOSAs
[00:56] <wallyworld> still?
[00:56] <StevenK> Not in this timezone
[00:57] <gary_poster> s'alright.  If I land a testfix it will immediately run the next test, with only an email compaint.
[00:57] <gary_poster> I mean, immediately after the current one fails
[00:57] <gary_poster> so there shouldn't actually be any outage for you guys
[00:57] <wallyworld> ok, thanks!
[00:58] <wallyworld> the pastebin looks ok to my untrained eye. running the test to verify
[00:59] <gary_poster> wallyworld, I'll treat this effectively as an r= and then self-approve :-)
[00:59] <gary_poster> (once you run the test
[00:59] <gary_poster> )
[00:59] <wallyworld> ok, doing it now
[01:00] <gary_poster> wallyworld, I still intend to take you up on more of the PyCharm hints (like the bzr plugin).  Things have felt a bit up-in-the-air lately so I haven't attempted the full PyCharm switch yet
[01:01] <gary_poster> StevenK, btw, know that I would have begged for your assistance by name too had I remembered that you were around. ;-)
[01:01] <wallyworld> gary_poster: whenever on pycharm. bigjools likes it :-)
[01:01] <wallyworld> gary_poster: the test passes :-)
[01:01] <gary_poster> cool wallyworld :-)
[01:02] <wallyworld> thanks for fixing
[01:03] <gary_poster> test passing: great thanks wallyworld, and I'm taking that also as affirmation that, to your best guess, you think it is not making the test pass...by asserting broken functionality or something.  :-) OK, off to submit...
[01:03] <StevenK> gary_poster: Haha
[01:03] <gary_poster> :-)
[01:04] <StevenK> And here I was thinking that I was loud and annoying enough to not be forgotten.
[01:04] <wallyworld> gary_poster: well, don't take me as someone who knows about this bit of the product :-) so my best guess is not necessarily all that good
[01:04] <wallyworld> but the fix seems like it's in line with the observed failure
[01:05] <nigelb> FUUUUUUUUUU More test failures.
[01:05] <gary_poster> wallyworld, yeah.  Fair enough.  Here's hoping, then.  Right, and it looks like what wgrant did.
[01:05] <nigelb> I can't figure out what I broke
[01:05] <wallyworld> nigelb: what's up?
[01:05] <nigelb> wallyworld: two attempts at landing that branch and I have test failures
[01:06] <gary_poster> nigelb, trunk is broken fwiw, and was broken worse before.  If the errors look like "IllegalTarget: Package unique-from-factory-py-line3362-24070 not published in Distribution-24050" then wait a sec and then pull from trunk once I have the last fix in.
[01:06] <wallyworld> nigelb: some test failures occurred due recently due to some broken code elsewhere. perhpas you are seeing that issue
[01:06] <wallyworld> do you want to pastebin the failures?
[01:06] <nigelb> gary_poster: Indeeed it does!
[01:07] <StevenK> nigelb: It happens like that sometimes, sadly.
[01:07] <gary_poster> nigelb, well, good news, for some definition of good news. ;-)  I'll ping you when it's in.  Should be <5 min.
[01:07] <nigelb> \o/
[01:07] <nigelb> gary_poster: Thanks :)
[01:07] <StevenK> nigelb: Did you want your branch tossed at ec2 for the 3rd time?
[01:08] <nigelb> StevenK: sec, there's one failure that's fallout from me.
[01:08] <nigelb> let me fix that
[01:08] <nigelb> doctests *stab* *stab* *stab*
[01:08] <wallyworld> StevenK: if it's just the distro packaging failures we could lp-land it?
[01:10] <gary_poster> wgrant, any objections to http://pastebin.ubuntu.com/672811/ ?  About to land it?
[01:10] <StevenK> gary_poster: Only if you format sp2 correctly
[01:11] <StevenK> sp2 = self.factory.makeSourcePackage(
[01:11] <gary_poster> StevenK, bah, that's PEP8 compliant last time I checked :-P
[01:11] <StevenK>     distroseries=sp1.distroseries, publish=True)
[01:11] <gary_poster> If lint complains I'll do it...waiting...
[01:11] <wgrant> gary_poster: Huh, that mustn't have come up in the summary...
[01:11] <wgrant> Let me check.
[01:12] <gary_poster> StevenK, linter likes my code more than you do ;-)
[01:12] <gary_poster> Thanks wgrant
[01:12] <StevenK> gary_poster: Bah! :-)
[01:12] <wgrant> gary_poster: Argh, no, I just misread. thought it was part of TestValidateTarget.
[01:13] <gary_poster> wgrant, ok cool, so I'm assuming you approve of what I did.  I'm about to lp-land
[01:13] <wgrant> gary_poster: That diff looks fine.
[01:13] <wgrant> Thanks.
[01:13] <gary_poster> thank you
[01:21] <gary_poster> nigelp, merge trunk and all those other ones should go away.  good luck.
[01:21] <gary_poster> nigelb, even :-P
[01:23] <nigelb> hehe, okay
[01:35] <wgrant> wallyworld: 274	+        var filter_msg = Y.substitute(
[01:35] <wgrant> 275	+            'Showing <strong>{filter}</strong> matches for "{search_terms}".',
[01:35] <wgrant> 276	+            {filter: current_filter_value,
[01:35] <wgrant> 277	+            search_terms: this._search_input.get('value')});
[01:35] <wallyworld> yeees?
[01:36] <wgrant> wallyworld: It's not exploitable, as it's only displaying immediate user input, but it is wrong.
[01:36] <wallyworld> security issue?
[01:37] <wgrant> It would be, if search_terms didn't happen to come from a textbox.
[01:37] <wallyworld> so the problem is?
[01:37] <wgrant> Search terms involving HTML will break the world.
[01:38] <wgrant> And it's using a forbidden pattern which people will follow.
[01:38] <wallyworld> well if anyone types in html they deserve it to break
[01:38] <wallyworld> i just cargo culted the pattern myself
[01:38] <wgrant> Right.
[01:38] <wgrant> Let's not perpetuate this.
[01:38] <wallyworld> i dont' see this instance as a huge issue in this case
[01:39] <wallyworld> but yes, as a drive-by....
[01:40] <wgrant> In the current form it is barely exploitable, true.
[01:40] <wgrant> But it is a terrible pattern, and could very easily accidentally become exploitable.
[01:40] <wallyworld> sure, so next time someone is in the neighbourhood.....
[01:41] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/fix-codebrowse-oopses/+merge/72515
[01:42] <StevenK> wgrant: r=me
[01:43] <nigelb> StevenK: could you land https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575 again? :)
[01:43] <wgrant> StevenK: I want to wait for lifeless, as this was obvious enough from the logs that I think I might be missing some other issue.
[01:43] <nigelb> Third time's the charm I hope.
[01:55] <cjwatson> if anyone types in html> such as web browser developers looking for bugs involving certain kinds of HTML, for example ...
[01:55] <wgrant> cjwatson: Surely not!
[01:55] <wgrant> Nobody would ever do that.
[01:56] <wgrant> Web applications can break in bad ways in some cases.
[01:56] <wgrant> All good.
[02:16] <lifeless> wgrant: hi
[02:17] <wgrant> lifeless: I tried loggerhead locally and got a pretty obvious traceback. Did that not appear on prod?
[02:17] <wgrant> s/prod/qas/
[02:17] <lifeless> qas just ISE'd on us
[02:18] <lifeless> I prepped a monkey to get into pdb and see what is causing it -
[02:18] <lifeless> ok pages are ok
[02:18] <lifeless> but failing pages didn't seem to oops
[02:18] <lifeless> its in the -ops history
[02:18] <wgrant> http://paste.ubuntu.com/672845/
[02:19] <lifeless> hahhhhhhahhahahaha bloody ha ha
[02:19] <wgrant> Yes.
[02:19] <wgrant> That stuff didn't make it into qastaging's debug.log?
[02:19] <lifeless> no
[02:19] <wgrant> Yay
[02:19] <wgrant> Shall I land the fix, then?
[02:20] <lifeless> hell yes
[02:20] <lifeless> if thats s/oopsid/id/
[02:20] <wgrant> It is.
[02:20] <wgrant> It even works.
[02:20] <wgrant> Sad that this isn't tested.
[02:20] <lifeless> thank you & sinzui very much
[02:20] <wgrant> But let's unbreak it first.
[02:21] <wgrant> lifeless: Do I want a --rollback?
[02:21] <wgrant> Since it's already been fixed once, right?
[02:21] <wgrant> Let's see the report...
[02:23] <wgrant> Ah, there was no --rollback last time.
[02:23] <wgrant> I shall put it on this one.
[02:33] <StevenK> lifeless: O hai
[02:33] <StevenK> lifeless: Can you peer at http://pastebin.ubuntu.com/672806/ when you have a tick?
[02:34] <lifeless> wgrant: the cascade thing had me suspicious
[02:34] <lifeless> wgrant: I figured I could lp-land a no-op --rollback easier than unlanding one that didn't fix it
[02:34] <StevenK> lifeless: I'd like the query to return every BPR that has unexpired BPFs and doesn't already exist in BPRC.
[02:36] <lifeless> StevenK: what context is it running in?
[02:36] <StevenK> lifeless: Garbo job
[02:36] <lifeless> 18 seconds is tolerable to seed the job
[02:37] <StevenK> lifeless: wgrant's concern was that the performance is like that and BPRC only has 1 million rows on DF -- it's only going to get worse
[02:37] <lifeless> well
[02:38] <lifeless> the binarypackagereleasecontents_pkey index will allow fairly efficient determination of bpr's
[02:40] <lifeless> the merge join took most of the time
[02:40] <lifeless> whats thesecond query ?
[02:41] <lifeless> this is inefficient:  AND NOT EXISTS
[02:41] <StevenK> It's the same query, cold and hot
[02:41] <lifeless>     (SELECT BinaryPackageReleaseContents.binarypackagepath
[02:41] <lifeless>      FROM BinaryPackageReleaseContents
[02:41] <lifeless>      WHERE BinaryPackageReleaseContents.binarypackagerelease = BinaryPackageRelease.id)
[02:46] <StevenK> lifeless: Are you fiddling for something more efficient?
[02:46] <lifeless> yes
[02:52] <nigelb> ah, its wgrant's review day.
[02:52] <wgrant> So it is.
[02:52] <nigelb> StevenK: did you get a chance to land that? Should I poke wgrant into landing?
[02:53] <StevenK> 4595-upgrade-bug-linking => devel  [OK]     (up for 1:09:13.836563)
[02:54] <lifeless> StevenK: Time: 5.961 ms
[02:55] <lifeless> http://paste.ubuntu.com/672861/
[02:55] <lifeless> StevenK: this takes advantage of the fact that we expect:
[02:55] <lifeless>  - most rows to need analysis
[02:55] <lifeless>  - and we're walking a batch upward
[02:56] <lifeless> with analyze http://paste.ubuntu.com/672862/
[02:56] <nigelb> StevenK: aha, thanks :)
[02:56] <StevenK> lifeless: Why the first limit 1000?
[02:56]  * nigelb heads for caffeine and breakfast
[02:56] <lifeless> StevenK: thats large enough that we won't get lots of empty batches
[02:57] <lifeless> StevenK: its a guess. It just needs to be large enough that we'll get 1 (one is enough) rows most of the time
[02:57] <wgrant> lifeless: Won't an empty batch cause it to think it's done?
[02:57] <lifeless> yes, the driver logic needs tweaking
[02:57] <lifeless> it should say something like 'max id - last seen id < 1000'
[02:59] <lifeless> and/or
[03:00] <lifeless> always increments the last seen id by 20 if no results were found
[03:00] <lifeless> when it exceeds the max id, we're done-done.
[03:00] <lifeless> and can switch to a simpler plan using the highest ids and working back or whatever
[03:15] <jamesh> lifeless: in case you're interested, I added a first-go patch to https://code.djangoproject.com/ticket/16674 that makes django work with python-oops-wsgi
[03:22] <jtv> wgrant: have you had a chance to look at that buildbot failure?  With you, me, and the big J on the blamelist I guess it's not as easy as "oh it's packaging-related, I know who it is."  :)
[03:22] <wgrant> jtv: It was my fault. It is fixed.
[03:22] <jtv> Oh good, thanks.
[04:06] <lifeless> jamesh: I am
[04:07] <lifeless> jamesh: do we want a python-oops-django containing the django glue ?
[04:07] <jamesh> lifeless: ideally I'd like it if no glue was necessary
[04:07] <jamesh> hence the django bug report
[04:07] <lifeless> yeah
[04:07] <lifeless> me too
[04:08] <lifeless> jamesh: thanks for digging into this!
[04:08] <lifeless> I'm going to be hacking on more gpg extraction / gpgverifyd today
[04:08] <lifeless> but should be back on oopses tomorrow
[04:08] <lifeless> and probably on leave monday
[04:12] <wgrant> lifeless: On Monday, or from Monday?
[04:14] <jamesh> lifeless: you said that some other web frameworks had the same problem of hiding the exception context when producing an error page.  Perhaps the best solution would be to patch a few other popular ones and hope that python-oops-wsgi is compelling enough to convince others to patch the remaining ones
[04:14] <nigelb> jamesh: that's interesting.
[04:14] <nigelb> jamesh: I was just thinking the other day what it would take to use python-oops with django
[04:15] <nigelb> (after all the excitement lifeless was making with python-oops :P)
[04:18] <jamesh> nigelb: well, hopefully the patch in that bug (or a better version of the same) will make it into a future version of Django
[04:19] <jamesh> then the answer is just "wrap Django's WSGIHandler() with python-oops-wsgi and embed in your favourite WSGI container"
[04:19] <nigelb> :)
[04:20] <StevenK> nigelb: In reference to your G+ post: <ESC>:shell
[04:21] <nigelb> StevenK: I used byobu instead
[04:21] <nigelb> with a vertical split
[04:21] <StevenK> Cheater
[04:21] <nigelb> heh
[04:22] <nigelb> Its pretty nifty actually.
[04:22] <nigelb> I like commiting often and a terminal right below the editor helps
[04:23] <wgrant> Hmm.
[04:23] <wgrant> https://bugs.launchpad.net/launchpad/+bug/411409
[04:23] <_mup_> Bug #411409: AJAX "Link to a bug report" could be improved <confusing-ui> <disclosure> <javascript> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/411409 >
[04:23] <wgrant> The attachment link there no longer works.
[04:24] <wgrant> (I always used to insert odd characters into attachment names to break things... but I think this one used to work)
[04:27] <wgrant> Interestingly it works locally.
[04:27] <StevenK> The number is the LFA?
[04:27] <StevenK> (In the URL, I mean)
[04:27] <wgrant> BugAttachment.id
[04:28] <nigelb> How much work is that bug?
[04:28] <nigelb> Its tempting to pick up
[04:28] <wgrant> http://launchpadlibrarian.net/30110664/what%3F.png works
[04:29] <wgrant> nigelb: Pickers are not something you want to get into.
[04:29] <wgrant> At least not yet.
[04:29] <nigelb> Hmm, ok.
[04:30] <StevenK> Yes, that picker sucks
[04:30] <wgrant> That's not even a picker.
[04:30] <wgrant> it should be.
[04:30] <StevenK> Do we even have a picker that can search by bug number?
[04:30] <wgrant> No.
[04:30] <wgrant> We want one that can search by ID/summary/description.
[04:31] <StevenK> True
[04:31] <StevenK> Can haz FDT now
[04:33] <StevenK> lifeless: So I need another number for {B,S}PPH indices -- is it another -1 and goes to db-devel?
[04:34] <wgrant> StevenK: That can be done live.
[04:34] <wgrant> Once the column is there.
[04:34] <wgrant> Wait until then, I suspect.
[04:34] <StevenK> Bleh
[04:35] <StevenK> We probably need more than just CREATE INDEX binarypackagepublishinghistory__binarypackagename__idx ON BinaryPackagePublishingHistory(binarypackagename) anyway
[04:35] <wgrant> Hah, yes.
[04:35] <StevenK> (And the correspending SPPH, of course)
[04:35] <StevenK> wgrant: Suggestions for what we want to index?
[04:35] <wgrant> Depends what you want to make fast.
[04:36] <StevenK> The DSP vocab
[04:36] <wgrant> The current indexes are pretty arbitrary and useless.
[04:36] <wgrant> StevenK: Do you have an example query?
[04:37] <wgrant> Given the
[04:37] <StevenK> Not handy
[04:37] <wgrant> possible new DSP cache table approach, this may all be irrelevant.
[04:37] <StevenK> wgrant: Yes, I wanted to talk about that too
[04:37] <wgrant> Since we'll have a cache table which has (archive, sourcepackagename, [binaries]) or so.
[04:37] <StevenK> We will?
[04:37] <wgrant> I hope so.
[04:38] <wgrant> Something like DistributionSourcePackageCache, except not stupid and less useless.
[04:38] <wgrant>  binpkgnames        | text         |
[04:38] <wgrant> Also without that.
[04:38] <wgrant> plural -> text
[04:38] <StevenK> And not like DistributionSourcePackageInDatabase? :-)
[04:38] <wgrant> Uh, yeah.
[04:39] <wgrant> StevenK: Have you, sinzui and bigjools discussed this at all?
[04:39] <wgrant> I saw bigjools decrying the idea that something could be in a distribution without a publication, but that's about it.
[04:39] <StevenK> The thing that sinzui and I have discussed is populating the DSP table for series older than maverick
[04:40] <wgrant> And for other series.
[04:40] <wgrant> It doesn't need populating for old series.
[04:40] <wgrant> It needs reconceiving, reworking, and reimplementing.
[04:40] <wgrant> Then you can think about populating it.
[04:45] <jtv> wgrant, are you reviewing today?  You might enjoy this one. https://code.launchpad.net/~jtv/launchpad/fix-some-utilities/+merge/72523
[04:46] <StevenK> wgrant: So we have DSP, DSPC, and DSPID. /wrists
[04:46] <wgrant> StevenK: Right. We need to talk about how this should work.
[04:46] <wgrant> jtv: Sure.
[04:46] <wgrant> jtv: The number of selfs in interfaces is disturbing.
[04:47] <jtv> Yes, maybe we should just add a grep to "make lint."  :-)
[04:47] <wgrant> StevenK: (DSPC is presently updated by a script that takes like 20 hours)
[04:48] <StevenK> And DSPID is perpuated by IPublishingSet.newSourcePublication()
[04:48] <wgrant> It's not quite clear what should happen to DSPID.
[04:48] <wgrant> It possibly still has a place in the world.
[04:49] <wgrant> jtv: Approved.
[04:49] <jtv> Thanks.
[04:50] <wgrant> StevenK: I think we need to take DSP, DSPC, DSPC and DSPID, all their users, and some other stuff and work out WTF we have and what we want.
[04:51] <wgrant> (no the two DSPCs are not a mistake: DistributionSourcePackageCache and DistroSeriesPackageCache)
[04:51] <wgrant> I can hear your wrists from here.
[04:52] <StevenK> That's funny, I didn't think blood pooling on the carpet was that noisy.
[04:54] <nigelb> Is StevenK slashing his wrists again? :P
[04:55]  * StevenK logs into the ec2 instance that is testing nigelb's branch and injects a few failures.
[04:56] <nigelb> gah!
[04:56] <wgrant> lifeless: https://bugs.launchpad.net/python-oops-wsgi/+subscriptions <- please unsubscribe launchpad-security
[04:56] <wgrant> Anyone can add the subscription, but only a team admin can remove it :)
[04:57] <nigelb> hm, isn't there something wrong with that?
[04:57] <StevenK> wgrant: So I think DSP is used by a *lot* of stuff -- and DSPID is tied directly into most of it. The two DSPCs, I don't really know
[04:59] <wgrant> Merging DSP and DSPID is going to be really fiddly and time-consuming, if it ever happens.
[05:00] <wgrant> It may be best to add a flag on DSPID indicating officialness.
[05:00] <wgrant> Or just assume that is presence is official.
[05:00] <wgrant> But then you'd also need to join against DSPC to do the binary lookup.
[05:00] <wgrant> DSPC has the complication that it has an archive.
[05:01] <StevenK> So I think you're right. It's a horrid horrid mess, and it needs to die.
[05:01] <wgrant> You know what would be cool?
[05:01] <wgrant> If Launchpad wasn't a monolithic monster with no separation or interfaces.
[05:02] <StevenK> Hah
[05:03] <StevenK> Right, DSP fills me with despair
[05:03] <wgrant> But if we can work this out, then Soyuz will be much closer to its own little world.
[05:03] <wgrant> s/world/insane asylum/
[05:03] <wgrant> Since Bugs will have no fingers left in the Soyuz pie.
[05:04] <wgrant> Oh, curses.
[05:04] <wgrant> Components.
[05:04] <wgrant> And bug nomination permissions.
[05:05]  * wgrant dies.
[05:05] <StevenK> Yes
[05:05] <StevenK> I'm making a list, and getting more depressed by the microsecond
[05:05] <wgrant> Anyway, let's see what still uses DSPC²
[05:05] <wgrant> I think most of its users are long-dead.
[05:06] <StevenK> Which DSPC?
[05:06] <wgrant> ²
[05:06] <wgrant> ie. both.
[05:06] <wgrant> They are similar.
[05:06] <wgrant> And have the same name.
[05:07] <StevenK> OH, WHAT THE
[05:07] <wgrant> ?
[05:07] <wgrant> The name is slightly different
[05:07] <wgrant> DistroSeries vs DistributionSource
[05:07] <StevenK> DistributionSourcePackage.getPersonsByEmail(email_addresses)
[05:07] <StevenK> SERIOUSLY?
[05:07] <wgrant> Pardon?
[05:07] <wgrant> lib/lp/registry/model/distributionsourcepackage.py:    def getPersonsByEmail(email_addresses):
[05:07] <StevenK> It's in there, and the DSP view calls it
[05:07] <wgrant> O_O
[05:07] <wgrant> You are correct.
[05:08] <wgrant> It will die before EOD.
[05:08] <StevenK> Can I kill it?
[05:08] <wgrant> brb, qannotate
[05:08] <StevenK>         the_changelog = '\n'.join(
[05:08] <StevenK>             [spr.changelog_entry for spr in sprs
[05:08] <StevenK>              if not_empty(spr.changelog_entry)])
[05:09]  * StevenK now feels depressed and ill
[05:09] <wgrant> That evil is somewhat necessary, unfortunately.
[05:12] <StevenK> Icky
[05:13] <wgrant> Debian changelogs are, yes.
[05:13] <StevenK> If we're logged in, pull every single e-mail address out of a constructed changelog, call that abomdination of a method, and then drop persons that have hidden mail addresses
[05:13] <StevenK> *Disgusting*
[05:16] <wgrant> It does seem to be the sort of thing that built up slowly over 5 years into an unfathomable monster, which could have been avoided if it had been redesigned half way through.
[05:16] <wgrant> Hmm, like something else...
[05:16] <wgrant> Launchpad!
[05:17] <lifeless> hang on
[05:17] <lifeless> why do we drop those people?
[05:17] <wgrant> Probably so we can show the email addresses, just unlinked because why.
[05:18] <lifeless> well
[05:18] <lifeless> couldn't we show the person and not show the email addresses ?
[05:18] <wgrant> The changelog is indexed by numerous other places.
[05:19] <wgrant> Anybody putting their email address in a changelog but wanting it to remain private is even more misguided than someone who wants their email address to remain private.
[05:19] <wgrant> And that is saying something.
[05:19] <lifeless> sure
[05:20] <lifeless> but thats a separate argument, AIUI we're currently not linking to the persons
[05:20] <lifeless> which seems bizarro
[05:20] <wgrant> Not necessarily.
[05:20] <wgrant> To link them would allow you to determine the owner of an address.
[05:20] <lifeless> you can probe for (many) by sending a comment to a bug with a custom from
[05:20] <wgrant> s/an address/a private address/
[05:20] <wgrant> Ja.
[05:20] <lifeless> over half our users in fact
[05:21] <wgrant> Hm?
[05:21] <lifeless> does 'private address' mean 'do not show', or 'do not link against from other data sources'
[05:21] <lifeless> I think its intended to be the former
[05:21] <wgrant> lalalala
[05:22] <lifeless> IIRC the UI says 'hide address' not 'pretend it does not exist'
[05:22] <wgrant>  Hide my email addresses from other Launchpad users
[05:22] <lifeless> right
[05:25] <StevenK> wgrant: And if we're going to attack DSP/DSPID, what about its bastard half-sibling, DSPR?
[05:25] <wgrant> StevenK: It's unrelated.
[05:25] <wgrant> It exists solely for the URL space.
[05:26] <StevenK> wgrant: Have you finished looking for DSPC usage?
[05:26] <wgrant> You distracted me.
[05:26] <StevenK> Heh
[05:27] <StevenK> I suppose screaming blue murder is a bit distracting.
[05:28] <lifeless> wgrant: how did l-s get subscribed ?
[05:28] <wgrant> lifeless: It's the bug supervisor.
[05:28] <wgrant> lifeless: Bug supervisors get a subscription by default, because someone likes to confuse people.
[05:29] <lifeless> aieee
[05:29] <lifeless> so there will be a few more to clean up
[05:29] <lifeless> is there a page showing all l-s's subscriptions
[05:29] <wgrant> Yes.
[05:29] <lifeless> and the docs need tweaking
[05:29] <wgrant> Possibly... I think it might ahave been cut.
[05:29] <wgrant> Let me try to find it.
[05:30] <lifeless> https://launchpad.net/~launchpad-security/+subscriptions
[05:30] <wgrant> Yeah./
[05:30] <lifeless> which mingles structural and explicit.
[05:30] <lifeless> or perhaps only shows concrete objects
[05:31] <lifeless> StevenK: indices on non-empty-or-close-enough tables are separate patches, yes.
[05:34] <lifeless> wgrant: cleaned up the ones i can remember making
[05:34] <wgrant> lifeless: Thanks.
[05:35] <wgrant> https://launchpad.net/~launchpad-security/+structural-subscriptions
[05:35] <lifeless> and the docs are updated
[05:35] <wgrant> Three left.
[05:35] <lifeless> I wonder
[05:35] <wgrant> Bug mail for Launchpad Security about Timeline is filtered; it will be sent only if it matches the following filter:
[05:35] <wgrant> This filter allows all mail through.
[05:35] <wgrant> Yay.
[05:35] <lifeless> can you subscribe an arbitrary team by setting bug-supervisor
[05:36] <lifeless> apparently I am in a team cxalled 'morfose'
[05:36] <wgrant> You used to be able to.
[05:36] <wgrant> I think only team members can now, though.
[05:36] <lifeless> fixed those as well
[05:36] <wgrant> Thankyou sir.
[05:37] <StevenK> wgrant: DSPC, or did lifeless distract you? :-)
[05:37] <wgrant> blargh dying
[05:37] <lifeless> wgrant: on and from
[05:38] <wgrant> lifeless: Monday?
[05:38] <lifeless> yes
[05:38] <wgrant> :(
[05:39] <lifeless> jamesh: re patching other frameworks. Perhaps ;) certainly though they must have some way of glueing in already and making users upgrade their platform isn't really a goal of python-oops-wsgi : so both hacking around, and doing the Right THing, is probably needed
[05:49] <StevenK> Surely we already have a method to return Persons given an iterable of e-mail addresses
[05:50] <wgrant> StevenK: I doubt it.
[05:50] <StevenK> wgrant: So, I hack the view to call IPersonSet.getByEmail(), but that strikes me as slow
[05:51] <wgrant> Impractically slow, yes.
[05:51] <wgrant> You need to introduce a sensible method to do it in one query.
[05:52] <StevenK> On IPersonSet, do you think?
[05:52] <wgrant> Next to getByEmail, yes.
[05:52]  * StevenK attempts to not swear in a branch name
[05:52] <wgrant> getByEmail becomes a convenience wrapper.
[05:53] <StevenK> Sounds like a plan
[05:53] <jamesh> lifeless: I wouldn't be surprised if other frameworks are as easy to fix as Django.
[05:54] <jamesh> lifeless: and for some there might be an option to disable error recovery, letting everything fall through to the wsgi container
[05:56] <lifeless> jamesh: sure
[05:57] <jamesh> lifeless: having some way to report the exception from deep in the stack might be enough to hack around frameworks that don't do the right thing: that is essentially how we're currently using wsgi-oops's logging support.
[05:58] <lifeless> wheee
[06:00] <lifeless> 831035 is a dupe isn't it ?
[06:09] <LPCIBot> Project devel build #984: STILL FAILING in 5 hr 54 min: https://lpci.wedontsleep.org/job/devel/984/
[06:10] <wgrant> lifeless: Fixed.
[06:13] <lifeless> pop quiz
[06:14] <lifeless> rewrite zeca as simple server, as a paste app, web.py, or keep it as twisted ?
[06:14] <wgrant> Should be pretty trivial to make it Paste/webpy, right?
[06:14] <lifeless> yes
[06:14] <wgrant> It's like 300 lines.
[06:14] <StevenK> Given a result set which returns two columns, can I call something on it to just return the first column and first row?
[06:15] <wgrant> StevenK: Do you have a more specific example?
[06:15] <lifeless> StevenK: slice it to get the first row; then call .values()
[06:15] <lifeless> StevenK: but better to decide what you want to query in the first place
[06:15] <StevenK> I have a query which returns (Person, EmailAddress), I want the first Person only
[06:16] <lifeless> for clarity, I like twisted, but its seems a heavy dep for this
[06:16] <lifeless> and I *hate hate hate* .tac files
[06:17] <wgrant> It is only a test dep, though, right?
[06:17] <nigelb>  \o/ TEST SUCCESS
[06:18] <lifeless> wgrant: yes
[06:18] <nigelb> StevenK: Thanks! :)
[06:18] <lifeless> but I need to extract ready service and a tonne of stuff
[06:19] <wgrant> True.
[06:19] <lifeless> ahh, wsgiref
[06:19] <wgrant> lifeless: It seems like porting it would be pretty easy.
[06:19] <lifeless> wgrant: onh for sure
[06:20] <lifeless> it raises the question that perhaps readyservice is needed for other tests
[06:20] <wgrant> And just about anything but Zope is lighter than Twisted.
[06:20] <wgrant> True.
[06:20] <lifeless> OTOH I think importing zcml is the problem.
[06:20] <lifeless> 'microservice' + 'zcml' are incompatible
[06:20] <wgrant> Heh.
[06:20] <wgrant> Not necesarily :)
[06:23] <StevenK> ProgrammingError: operator does not exist: text = bytea
[06:23] <StevenK> Sadface
[06:24] <wgrant> You fail at Unicode.
[06:24] <wgrant> And Python 2 doesn't help.
[06:24] <StevenK> Yes
[06:25] <StevenK> I think I have purged the evil
[06:26] <wgrant> Excellent.
[06:26] <StevenK> % bzr di | diffstat | tail -n 1
[06:26] <StevenK>  5 files changed, 23 insertions(+), 28 deletions(-)
[06:26] <wgrant> I'm still working out how best to fix DSP(C²|ID)?
[06:27] <wgrant> StevenK: diffstat -s
[06:28] <StevenK> I shall have to try and remember that.
[06:31] <StevenK> OPENID! STAB!
[06:36] <jtv> wgrant: what say you we make make lint grep for "self" in interface methods?
[06:38] <lifeless> some actually classes are in interface modules
[06:38] <lifeless> (and need to be)
[06:39] <lifeless> As long as they are catered for, it makes sense to me.
[06:39] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/dsp-getpersonsbyemail-stab-stab-stab/+merge/72528
[06:40] <jtv> lifeless: that's a nuisance.  Got any examples for me?
[06:40] <lifeless> not offhand
[06:40] <jtv> I can think of enums, but they don't have methods.
[06:41] <lifeless> jtv: stuff in bugs probably, and things raised in notify() are commonly in the interface (and thats a zope inherited idiom)
[06:41] <jtv> Thanks, that gives me something to look for.
[07:20] <jtv> StevenK, wgrant: do I remember correctly that you were scheming to add source package names to SPPH?
[07:27] <wgrant> jtv: The patch has landed.
[07:28] <jtv> wgrant: so… in db-devel now, to be rolled out RSN?  It may well be useful to what I'm doing right now.
[07:28] <wgrant> jtv: Yeah. Then we need to populate it and add indices and stuff.
[07:29] <wgrant> jtv: What are you up to? gina deletions?
[07:29] <jtv> Yup.
[07:29] <wgrant> Indeed, it would make that rather quick.
[07:29] <wgrant> However, after the first run it should only have like 20000 publications to consider.
[07:29] <wgrant> So it won't be that slow even without it.
[07:30] <jtv> I'm not too worried about the number of publications to consider—AIUI I only need to worry about ones where superseded is null, and that helps massively.
[07:30] <jtv> I'm worried about client-side memory.
[07:31] <wgrant> supersededby is not relevant here.
[07:34] <jtv> Why not?  I only need to delete SPPHs in "published" or "pending" statuses, right?  Can an SPPH be superseded yet be in one of those states?
[07:35] <wgrant> No.
[07:36] <wgrant> But supersededby does not determine supersededness.
[07:36] <wgrant> yes, anything with supersededby set is not Published or Pending, but it's not the correct discriminator.
[07:36] <lifeless> jamesh: around ?
[07:37] <jtv> wgrant: it doesn't have to be the correct discriminator and it doesn't need to determine supersededness.  It only needs to eliminate lots of SPPHs that I'm not interested in very effectively.
[07:37] <wgrant> jtv: Filter on status.
[07:38] <wgrant> status IN (1, 2)
[07:38] <wgrant> Done.
[07:38] <wgrant> That eliminates all the SPPHs you're not interested in, and is probably the most indexed column on the table.
[07:38] <jtv> Well of course I'm filtering by status.
[07:38] <jamesh> lifeless: yeah
[07:38] <wgrant> Then why are you interested in supersededby?
[07:39] <lifeless> jamesh: some of lp's gpghandler looks like things gpgme could sensibly have
[07:39] <lifeless> jamesh: what do you think ?
[07:39] <jtv> wgrant: like I said, I'm looking for ways to eliminate uninteresting SPPHs.  But if status does that well enough, then fine.
[07:39] <jtv> As I said, it's not important.
[07:40] <wgrant> jtv: You need to consider everything that is still active.
[07:40] <jamesh> lifeless: is this significantly different to the gpg utility thingee I'd remember from 2008, or something different?
[07:40] <lifeless> jamesh: doubt it
[07:41] <lifeless> jamesh: things like 'santizei a fingerprint'
[07:41] <jtv> wgrant: And you just said that this wouldn't affect that.  As I'm said, it's not that important.
[07:41] <lifeless> 'import a secret key' -> checks the key was imported, and only the one key
[07:41] <wgrant> jtv: Right, but your initial comment about "superseded is null" had me somewhat concerned.
[07:41] <lifeless> (and can disable the agent temporarily for tests)
[07:42] <jamesh> lifeless: okay.  Where abouts is this code?  If you're talking about some code I haven't seen then I can't sensibly answer the question.
[07:43] <lifeless> jamesh: I doubt it is different to what you've seen
[07:43] <lifeless> jamesh: I'll get you a url though, one sec
[07:43] <lifeless> jamesh: (I think the sense of my reply got inverted somehow)
[07:44] <jamesh> oh.  you meant you doubt it is different rather than doubt it is the same.
[07:44] <lifeless> yes :)
[07:44] <lifeless> 'is it different?' 'doubt it' :P
[07:44] <lifeless> jamesh: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/canonical/launchpad/utilities/gpghandler.py
[07:44] <lifeless> jamesh: I'm pulling out the for-test-only stuff into lp:gpgfixtures
[07:44] <lifeless> jamesh: e.g. making a GNUPGHOME dir
[07:44] <lifeless> jamesh: stashing test keys
[07:44] <lifeless> jamesh: running a test keyserver.
[07:45] <lifeless> jamesh: most of the rest looke like gpgme code to me. In the spirit of better-than-what-it-wraps.
[07:50] <lifeless> PymeUserId can just get deleted though
[07:50] <lifeless> and be replaced with a zope decl.
[07:50] <lifeless> or at least, its not a candidate for moving into pygpgme
[07:57] <adeuring> good morning
[07:58] <jtv> hi adeuring
[07:58] <adeuring> hi jtv!
[07:58] <jtv> All well?
[08:01] <lifeless> jamesh: so, your thoughts ?
[08:02] <jamesh> lifeless: I guess some of them might make sense.  The sanitisefingerprint one looks a bit mysql-ish the way it truncates long input
[08:03] <lifeless> jamesh: so, it clearly doesn't belong in LP :)
[08:03] <lifeless> jamesh: I could make a third library to wrap gpgme, but that seems an arbitrary split
[08:04] <jamesh> I'd be happy to include some helper utilities along side the extension module.
[08:04] <lifeless> whats your preference? Like I say, I want to gut (most of) this stuff from LP, and AFAICT its in three camps: test code, input handling, sane-default-wrappers-of-gpgme-things
[08:05] <jamesh> it'd be worth checking on a case by case basis whether the helpers make sense though.
[08:05] <lifeless> the test code -> gpgfixtures, because I think its inappropriate to impose that on every user of gpgme
[08:05] <lifeless> [though gpgme's test suite could well use gpgfixtures if you don't mind a test-only dependency]
[08:06] <jamesh> some of the checks it is doing are no longer necessary (e.g. explicitly checking for multiple signatures as a possible concatenated clear signed message attack, which gpg has errored out on for a while now)
[08:06] <adeuring> lifeless: could you also review my MP you already commented on?
[08:06] <lifeless> adeuring: sorry, no
[08:07] <wgrant> jamesh: Hm, does it really?
[08:07] <lifeless> adeuring: if you can't find another reviewer I will, but I have approx 24 hours work time to get microservices live, before I'm away for a while
[08:07] <wgrant> jamesh: Given a few recent vulnerabilities I've found, I'm not so sure about that.
[08:07] <adeuring> lifeless: ok, no problem
[08:07] <lifeless> jamesh: that wouldn't be harmful to handle though, would it? (In case of folk running old gpg)
[08:08] <jamesh> wgrant: I used to have tests for concatenated clearsigned blocks in the pygpgme test suite, and they stopped passing
[08:08] <wgrant> Hmm.
[08:08] <wgrant> Must be slightly different.
[08:08] <jamesh> lifeless: it'd be really old gpg though.
[08:09] <mrevell> Hey good morning#
[08:10] <lifeless> jamesh: so, its your call. I am going to extract what I need to test gpgverifyd from LP; thats definite. If you'd like it in gpgme as a place for others to reuse and iterate, I'd be delighted to add it there (with tests etc)
[08:10] <lifeless> jamesh: if you don't want it, no skin off my nose ;)
[08:10] <lifeless> jamesh: And if you do want it, I'll happily to modest tweaks to meet whatever style or other criteria you have.
[08:10] <jamesh> lifeless: the best option is probably to file bugs against pygpgme, and we can work from there.
[08:11] <lifeless> jamesh: that really doesn't work for me; I have a very short time to do a lot of stuff, so the round trips involved there would destroy any hope of getting what I need to get done done.
[08:11] <lifeless> jamesh: sorry
[08:16] <lifeless> jamesh: in case that came across as a bit dicky, I guess I mean I need to action it now, and can round trip in review etc, but doing a pre-flight-check on it all just seems to front load round trip discusssions that review will need anyhow.
[08:17] <jamesh> lifeless: I don't necessarily mean do it all individually.  If you've got an idea of what you would like to see moved, I'd be happy to review that all in one go.
[08:17] <jamesh> lifeless: that said, if all the helpers do is wrap StringIO()'s around the arguments, I'm not sure if that adds a lot of value
[08:18] <lifeless> well, they check for bytestrings, check how many signatures are found, sanitise input
[08:18] <jamesh> the gpghandler interface was originally wrapped around a different gpg interface, so there is a fair bit that would be different if pygpgme was the starting point
[08:19] <lifeless> pygpgme still exposes what gpgme does though right? its very up-to-the-user-to-interpret? [which most of this lp non-test-code is - interpretation]
[08:19] <jamesh> and I don't remember why the code configures "keyserver-options auto-key-retrieve" and also has code to directly download keys from the keyserver's http interface
[08:19] <lifeless> thats test code
[08:20] <lifeless> as I said, its not what I'm talking about
[08:20] <lifeless> that will be in gpgfixtures.GPGHomeFixture
[08:22] <lifeless> for pygpgme I am talking about: sanitizeFingerprint, getVerifiedSignature importPublicKey importSecretKey encryptContent(possibly) signContent(possibly)
[08:22] <lifeless> _submitKey might be intereseting
[08:23] <jamesh> okay.  It is just that most of the helpers include the http key download, which I would have thought was handled if your gpg config is for auto-key-retrieve
[08:23] <lifeless> the encrypt and sign stuff aren't really interesting to me at this point, and they probably need a lot more consideration
[08:24] <lifeless> jamesh: I can test that
[08:24] <lifeless> you're talking about the comment for handling of subkeys, yes ?
[08:25] <lifeless> which is in getVerifiedSignature
[08:25] <jamesh> everything that calls retrieveKey() is potentially doing an HTTP request
[08:26] <StevenK> Oh, bah.
[08:26] <lifeless> yes, which is only getV..S.. of the ones I listed
[08:26] <StevenK> Now it's +31/-28
[08:26] <StevenK> I am disappoint.
[08:26] <lifeless> StevenK: delete 3 random lines.
[08:28] <lifeless> jamesh: for the win : we don't test that subkey code path anyhow
[08:29] <lifeless> aieee http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/lib/canonical/launchpad/utilities/gpghandler.py
[08:30] <lifeless> well, perhaps in gpg-signatures.txt. If that still exists
[08:32] <jamesh> I'd be hesitant to accept things like getVerifiedSignatureResilient(), fwiw :)
[08:32] <lifeless> jamesh: not on my list
[08:32] <lifeless> jamesh: noddy things are noddy
[08:33] <jamesh> right.  it is just things like that that make me nervous about you initially talking about merging gpghandler into pygpgme.  The smaller set of methods seems a lot more sane.
[08:36] <jamesh> wgrant: fyi, here's the CVE about the message concatenation issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1263
[08:37] <jamesh> you'd have to be using particularly old code to be vulnerable
[08:39] <wgrant> jamesh: Ah. Not the same thing, right. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1829 and a few related things are what I discovered. Only one signature, but some unsigned bits.
[08:41] <jamesh> ah.  I guess that is what happens when you roll your own gpg interface ...
[08:41] <wgrant> Inline signatures must die.
[08:41] <wgrant> Yes!
[08:42] <wgrant> LP/dak were similarly vulnerable.
[08:42] <wgrant> (mostly because the LP code was copied straight from dak)
[08:42] <wgrant> We need good libraries.
[08:43] <jamesh> prior to the CVE I linked, you couldn't distinguish between a single clearsigned document signed by two keys and two concatenated clearsigned documents signed with one key each using gpgme
[08:43] <jamesh> now you can because the second form errors out
[08:46] <lifeless> heh, so a quick test suggests that retrieveKey going to the keyserver is indeed needed
[08:46] <lifeless> digging further
[08:47] <lifeless> (I replaced the http lookup with a key search, but that doesn't find the key)
[08:47] <lifeless> so - verifying the signature just-in-time obtains the signing subkey, not the master key.
[08:49] <lifeless> ah, wants GPGME_KEYLIST_MODE_EXTERN
[08:51] <jtv> gmb: morning!  Can I trouble you for a review?  https://code.launchpad.net/~jtv/launchpad/pre-830890/+merge/72535
[08:58] <stub> Anyone fixing the merge conflict?
[09:05] <lifeless> jamesh: ok, so heres what a quick poke got me
[09:05] <lifeless> jamesh: the auto key retrieval only gets the specified key
[09:06] <lifeless> jamesh: some keyservers return the master, some don't (this I remember from way back :P)
[09:06] <lifeless> jamesh: setting context.keylist_mode = context.keylist_mode | gpgme.KEYLIST_MODE_LOCAL | gpgme.KEYLIST_MODE_EXTERN
[09:07] <lifeless> jamesh: does do an hkp lookup, but seems to not work - and there are mailing list messages asking about this same behaviour upsream
[09:07] <lifeless> jamesh: so it looks like some nontrivial debugging is needed to identify whats going on (possibly not very hard, but very much a yak I didn't plan on shaving)
[09:08] <jamesh> hmm.  The gpg man page also mentions an "include-subkeys" keyserver option, but it says "Note  that  this  option is not used with HKP key servers, as they do not support retrieving keys by subkey id"
[09:08] <lifeless> yes
[09:08] <stub> I've got the merge conflict - just looks like imports
[09:09] <jamesh> ah.  it is saying that hkp supports retrieving subkeys by subkey id, but not the whole keys by the subkey id
[09:09] <lifeless> anyhow, I think I need to keep the http lookup because the test case (which does still exist) does fail.
[09:09] <lifeless> jamesh: exactly, and we're running with hkp.
[09:09] <jamesh> fair enough.
[09:09] <lifeless> you have to do two requests, one for the subkey, and one for the master, and the 'obvious' way to make get_key do the retrival for us doesn't work.
[09:10] <jamesh> so the utilities would need to know about an http keyserver?
[09:10] <lifeless> e.g. just doing get_key(sig.fpr) barfs, with or without keylist_mode set
[09:11] <lifeless> jamesh: I think its fugly to have the python code doing the lookups
[09:11] <lifeless> jamesh: I don't know how deep the rabbit hole to avoid that is ;)
[09:12] <lifeless> its pretty clear that the Right Thing depends on whether the gpg.conf has a keyserver setup and whether it has auto-key-retrieval setup
[09:13] <lifeless> so certainly *some* degree of configuration is needed
[09:13] <lifeless> whether that should be supplied (Wrapper(keyserver=xxx)) or inferred by grepping gpg.conf, etc I dunno
[09:14] <lifeless> I think at this point I'm inclined to rename gpgfixtues to gpgsupport or gpgwrappers or something, bundle the http code and all into it
[09:14] <lifeless> and file a bug saying that this aspect is fugly and point in the right long term direction
[09:17] <gmb> jtv: Sure, I'll take a looks shortly
[09:18] <jtv> thx
[09:18] <lifeless> jamesh: what do you think?
[09:19] <jamesh> lifeless: that might be a good short term option.  I'm still open to moving parts that make sense to gpgme.
[09:19] <jamesh> pygpgme, even
[09:35] <gmb> jtv: Approved. Good stuff; I likes me a cleanup.
[09:35] <jtv> yay
[09:35] <jtv> thanks again
[09:35] <gmb> np
[09:48] <lifeless> jamesh: thanks
[09:56] <adeuring> gmb: could you review this MP: https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-fix-issues-for-unprecise-result-length/+merge/72473/+index ?
[09:58] <gmb> adeuring: Certainly
[09:59] <adeuring> thanks!
[10:02] <lifeless> night y'all
[10:04] <bigjools> nn
[10:05] <wgrant> Yay, loggerhead OOPSes work again.
[10:06] <wgrant> jelmer: I guess you were trying to QA stuff?
[10:06] <jelmer> wgrant, yep
[10:06] <wgrant> jelmer: Although the bzr-svn rev is much less interesting right now that the SafeBranchOpener one.
[10:07] <jelmer> wgrant, I'm looking at both - the SafeBranchOpener one was why I was asking about loggerhead
[10:07] <wgrant> Ah, of course.
[10:07] <wgrant> Thanks.
[10:32] <StevenK> wgrant: DistributionSourcePackage.createBug() makes me sad.
[10:32] <wgrant> StevenK: ... does anything use it?
[10:32] <StevenK> Yes, sadly.
[10:32] <wgrant> Ew what/
[10:33] <wgrant> Surely not +filebug.
[10:33] <wgrant> But it looks like it may.
[10:34] <StevenK> wgrant: Two soyuz tests, at least.
[10:34] <StevenK> wgrant: But there are a large amount of methods called createBug()
[10:34] <StevenK> Distribution and Distroseries have one, as does Product ...
[10:34] <wgrant> Looks like it's a standard IBugTarget method.
[10:38] <gmb> adeuring: Approved.
[10:38] <adeuring> gmb: thanks!
[10:38] <gmb> np
[10:50]  * gmb lunches
[10:59] <henninge> gmb: when you are back from lunch: I have a branch here that I hope you'll have as much reviewing, if you can, as I had writing the code. ;-) Seriously.
[10:59] <henninge> https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-2/+merge/72546
[10:59] <henninge> it's slightly oversized, though.
[10:59] <henninge> s/slightly//
[11:57] <benji> nigelb: there were some test failures for https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
[11:57] <benji> I pasted them as a comment.
[12:02] <LPCIBot> Project devel build #985: STILL FAILING in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/985/
[12:10] <gmb> henninge: Sure, I'll take a look shortly
[12:11] <henninge> gmb: great, thank! ;-)
[12:11] <henninge> s
[12:26] <nigelb> benji: I fixed them and got it rebuild and merged.
[12:27] <nigelb> (retested)
[12:27] <benji> cool
[12:28] <nigelb> You would have caught it, except I gave you a useless diff yesterday :)
[13:05] <deryck> Morning, everyone.
[13:07] <gmb> henninge: Nice work! Approved.
[13:07] <henninge> gmb: Thank you! ;)
[13:10] <gmb> danilos, henninge, jtv: Can one of you help radifar over in #launchpad? He seems to be getting a weird error when trying to review a translation.
[13:10] <jtv> gmb: sorry, too far past EOD here.
[13:10] <gmb> jtv: No worries
[13:10] <jtv> Ta
[13:19] <bigjools> stub: still there?
[13:19] <stub> yo
[13:20] <bigjools> stub: patch-2208-78-1.sql won't apply on DF because there's loads of null owner columns - do you know if the production data was massaged outside of a patch?
[13:20] <stub> bigjools: There was a garbo job that cleaned the data
[13:21] <bigjools> crap
[13:21] <stub> bigjools: Which will be the standard way of doing data migration now, so need to get that running regularly on DF.
[13:21] <bigjools> *cry*
[13:21] <bigjools> ok
[13:22] <bigjools> thanks
[13:22] <stub> Should be able to fix the data with a single update if you don't want to chase the old garbo... hangon.
[13:22] <bigjools> yeah DF is not there to test bugs stuff so I don't care if I poke it with Joe Blogs
[13:23] <stub> update bugmessage
[13:23] <stub> set owner=message.owner
[13:23] <stub> from message
[13:23] <stub> where message.id = bugmessage.message;
[13:23] <bigjools> ta
[13:26] <bigjools> stub: should I run -daily or -hourly?
[13:28] <stub> bigjools: I don't think we have standardized which is needed for data migration - might need both (and soon -frequently too once the db-devel merge is unblocked), but you don't need to run them all that often.
[13:29] <bigjools> stub: well I was going to cron one in on DF to run late at night when nobody is using it so that I don't have to sit and wait again like I am now :)
[13:32] <deryck> henninge, ping for standup.
[13:33] <henninge> deryck, abentley: sorr y guys, my phone is acting up ...
[13:33] <henninge> need to reboot
[13:33] <deryck> henninge, np.  we'll start and join when you can.
[14:03] <bac> gmb when you have time could you look at https://code.launchpad.net/~bac/launchpad/bug-823490/+merge/72577
[14:03] <gmb> bac: sure
[14:19] <gmb> bac: Approved.
[14:19] <bac> thanks gmb
[14:46] <nigelb> qastaging is continously timing out.
[15:27] <gmb> nigelb: WFM. Can you give a specific URL?
[15:28] <nigelb> gmb: worked after continously abusing F5 ;)
[15:28] <gmb> Heh.
[15:28] <nigelb> bugs.qastaging.launchpad.net/bugs was what timed out for me :)
[15:39] <abentley> gmb: could you please review https://code.launchpad.net/~abentley/launchpad/bad-state-transition-2/+merge/72592 ?
[15:39] <gmb> abentley: Sure.
[15:39] <abentley> gmb: thanks.
[15:55] <gmb> abentley: approved
[15:55] <abentley> gmb: Thanks!
[15:55] <gmb> np
[16:04] <LPCIBot> Project db-devel build #817: STILL FAILING in 6 hr 22 min: https://lpci.wedontsleep.org/job/db-devel/817/
[16:56] <LPCIBot> Project devel build #986: STILL FAILING in 4 hr 54 min: https://lpci.wedontsleep.org/job/devel/986/
[17:04] <mrevell> G'night all!
[18:12] <jml> Are all the Virginians alright?
[18:12] <jml> And NCers too
[18:13] <benji> jml: yep, but we've used up this month's supply of adrenaline
[18:15] <nigelb> heh
[18:16] <jml> benji: heh. glad to hear all is well :)
[18:20] <bac> jml: people 7 miles north and 25 miles east of here felt it ... but there was nothing where i am.
[18:21] <bac> but that's ok, as we have a hurricane four days out
[18:24] <nigelb> heh
[18:24] <nigelb> we're happend to lend you adrenaline :P
[18:24] <nigelb> *happy
[18:26] <deryck> cr3, ping
[18:31] <cr3> deryck: pong, what's up?
[18:52] <bac> matsubara: what's the procedure for clearing out the staging/qastaging imap mbox?  it's pretty big and i'd be happy to zap it.
[18:53] <matsubara> bac, I thought there was a script running deleting those messages. Ursinha used to run it
[18:54] <matsubara> bac, I think old emails can be safely deleted from the mbox
[18:54] <bac> matsubara: ok
[18:54] <matsubara> or any bug email
[18:54] <matsubara> since those are the ones that takes the most space
[19:41] <lifeless> gary_poster: ping
[19:42] <gary_poster> lifeless, hi
[19:42] <lifeless> gary_poster: with buildout develop = ...
[19:42] <lifeless> gary_poster: is there a way to set that without editing a version controlled file in the LP tree ?
[19:44] <bac> abentley: an ec2 job just failed due to the new test_memory_hog_job.  have you seen any spurious failures with it before?  i can't reproduce locally
[19:44] <gary_poster> lifeless, should be, if I understand you.  ./bin/buildout section:key=value works IIRC, so ./bin/buildout buildout:develop=foo ought to work.  I'll go confirm with docs...
[19:45] <lifeless> gary_poster: that sounds great.
[19:45] <lifeless> I will edit our docs :)
[19:45] <abentley> bac: No, I haven't seen spurious failures before.
[19:46] <lifeless> gary_poster: this is the bit I was referring to - https://dev.launchpad.net/HackingLazrLibraries 'In this software's buildout.cfg, in the [buildout] section, look for a
[19:46] <lifeless> develop key. I'....
[19:47] <gary_poster> ah gotcha lifeless.  Yes, I remembered correctly, at least generally, and that ought to work for this specific case. (http://pypi.python.org/pypi/zc.buildout/1.5.2#command-line-usage fwiw)
[19:54] <lifeless> gary_poster: care to check my recording of it ? https://dev.launchpad.net/HackingLazrLibraries
[19:54]  * gary_poster looks
[19:58] <gary_poster> lifeless, do these contradict? "A reasonable option is to add it in the top-level directory of this software." vs "The best thing to do is to locate it in a sibling tree so that its separation is clear."  If so, let's settle on one; if not, it needs some clarity.
[19:58] <gary_poster> "but that will get committed and as such is rarely what you want": *really* rarely as long as bzr doesn't support externals ;-) Once we have externals, it can be nice in some cases.
[19:59] <gary_poster> "When you want to switch back to using an egg for that other component run bin/buildout build:develop=.": Actually, you should just need to run "bin/buildout".  You won't be overriding the set value anymore on the commandline, so...it should just work.
[20:05] <lifeless> gary_poster: ok, so one needs to keep supplying the key until done ?
[20:05] <gary_poster> yes lifeless
[20:06] <lifeless> gary_poster: I would like to delete the nesting options
[20:06]  * gary_poster on call
[20:07] <lifeless> gary_poster: given that we're using buildout for getting at stuff, one system is preferrable to three, all other things being equal
[20:10] <gary_poster> ack
[20:10] <lifeless> gary_poster: tweaked further, if you can let me know after your call that would be great
[20:10] <gary_poster> cool
[20:32] <sinzui> jcsackett, do you have time to mumble?
[20:32] <jcsackett> sinzui: sure.
[20:33] <jcsackett> sinzui: i hear you. i presume you cannot hear me.
[20:34]  * sinzui looks at sound preferences
[21:12] <gary_poster> lifeless, I just read the lazr page: looks good, thank you
[21:16] <lifeless> gary_poster: thanks
[21:24] <lifeless> jelmer: had you heard of 'python-gitdb' before its ITP ?
[21:24] <jelmer> lifeless: yeah, it's from the author of python-git
[21:24] <lifeless> jelmer: he didn't like your stuff ?
[21:24] <jelmer> lifeless: although I was a bit surprised to see the ITP - python-gitdb is EOL, and merged into python-git
[21:25] <jelmer> lifeless: python-git existed before dulwich, but was always more of a wrapper around git itself
[21:25] <jelmer> lifeless, he's only recently started looking at a pure-python implementation
[21:25] <lifeless> its a bit sad he's not using dulwich
[21:25] <jelmer> yeah
[21:27] <jelmer> lifeless: apparently python-git has support for multiple backends - gitdb being one of them, and dulwich and pygit2 (Python wrapper around libgit2) being other backends
[21:29] <lifeless> jelmer: interesting, though you have to wonder why gitdb is needed then ;)
[22:00] <LPCIBot> Project db-devel build #818: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/818/
[22:48] <LPCIBot> Project devel build #987: STILL FAILING in 5 hr 51 min: https://lpci.wedontsleep.org/job/devel/987/


[03:02] <Drakeson> I want to create a bootable {cd,dvd,usb stick,etc.}.  I can create a chroot by debootstrap.  I can also install grub2 on that partition.  Is there any *major* step that I might be missing?
[03:03] <ebroder> Drakeson: Checkout the livecd-rootfs package to see how the live CD's...rootfs's get built.  Like, say, install a kernel for starters
[03:12] <Drakeson> ebroder: thanks. livecd-rootfs looks very useful.
[05:57] <pitti> Good morning
[05:58] <pitti> ScottK: no, it's not a problem to have installed; in lucid I changed it from starting at boot to dbus activation, so as long as nothing tries to talk to it, it remains inert
[05:59] <pitti> ScottK: XFCE upstream also made the switch, and the packages are currently flowing into natty, so at some point hal shold just drop to universe; then the upgrade should take care of auto-cleanup
[07:33] <didrocks> good morning
[08:18] <dholbach> good morning!
[08:19] <didrocks> hey dholbach
[08:20] <dholbach> hey didrocks
[08:21] <bilalakhtar> Good morning dholbach !
[08:21] <bilalakhtar> dholbach: What is the procedure of adding datasources to hall-of-fame.u.c?
[08:21] <dholbach> bilalakhtar, it's currently unmaintained and being rewritten
[08:22] <dholbach> bilalakhtar, but if you set up some kind of script that sets up a .csv file somewhere that is easy to parse I can add it
[08:22] <dholbach> just send me an email
[08:22] <bilalakhtar> I have a script that writes it to an HTML
[08:22] <dholbach> hum
[08:22] <dholbach> I think it'd be better to just have the values
[08:22] <bilalakhtar> dholbach: http://people.ubuntu.com/~bilalakhtar/papercutters-hall-of-fame.html
[08:22] <bilalakhtar> dholbach: CSV would be easier
[08:23] <bilalakhtar> I would do the thing and mail you
[08:23] <dholbach> excellent
[08:24] <dholbach> bilalakhtar, just "launchpad-id, number" is enough
[08:25] <bilalakhtar> good, will do surely
[08:25] <bilalakhtar> dholbach: BTW, is it proprietary?
[08:27] <dholbach> bilalakhtar, yes, and the code sucks - it's really really bad stuff that contains passwords and all the rest of it
[08:27] <dholbach> that's why it's being rewritten in django
[08:27] <bilalakhtar> oh
[08:27] <dholbach> https://wiki.ubuntu.com/Spec/HallOfFameRewrite
[08:27] <dholbach> I had to finish it quickly back then and it's really horrible
[08:28] <dholbach> so I hope we can do it properly soon
[08:31] <bilalakhtar> will do soon
[09:00] <bilalakhtar> dholbach: Should the list limit the people to 10 or something? or will the hall of fame do that?
[09:00] <dholbach> bilalakhtar, I can limit it easily, no problem
[09:20] <quadrispro> hi all
[09:20] <quadrispro> is there any release manager around?
[09:20] <micahg> quadrispro: try #ubuntu-release :)
[09:20] <quadrispro> s/release manager/sru member/
[09:20] <quadrispro> micahg, trying, thanks
[09:21] <micahg> quadrispro: oh, pitti's around somewhere for SRUs  :)
[09:21]  * pitti hides :)
[09:21] <quadrispro> pitti, bug #665243, would you take a look?
[09:21] <quadrispro> pitti, the patch seems to work fine
[09:37] <pitti> quadrispro: (in a bit, having another discussion right now)
[09:39] <quadrispro> ok
[10:20] <jibel> pitti, Is the removal of wubi.exe from the ISO part of the 'reducing cd footprint' policy ?
[10:20] <pitti> jibel: I'm not aware of this; sounds like a bug rather?
[10:20] <jibel> pitti, sounds like a bug to me too, bug filed. Thanks.
[10:25] <pitti> quadrispro: seems fine to me
[10:28] <quadrispro> good!
[10:32] <quadrispro> pitti, please leave a msg on the report, I'll upload it right now
[10:32] <pitti> quadrispro: you don't need a prior ack, just upload :)
[10:32] <quadrispro> \o/
[10:32] <quadrispro> I didn't know
[10:33] <quadrispro> thanks!
[10:33] <micahg> quadrispro: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure <-- see step #4 at the end :)
[10:34] <quadrispro> ahhh yes, I see
[10:34] <quadrispro> I forgot it
[11:08] <chrisccoulson> @pilot in
[11:08] <chrisccoulson> yay \o/
[11:09] <dholbach> yeeeeehaw :)
[11:09]  * dholbach hugs chrisccoulson
[11:09]  * chrisccoulson hugs dholbach
[11:09] <dholbach> :)
[11:13] <cjwatson> ev: could you make http://people.canonical.com/~evand/wubi/natty/stable exist, please?
[11:13] <cjwatson> jibel,pitti: ^- that's the cause of wubi.exe going missing
[11:13] <ev> bah, I should've done that when I sorted usb-creator
[11:14] <pitti> cjwatson: ah, thanks for the heads-up
[11:15] <ev> cjwatson: done, I've put the signed version from maverick up for now.  Should I build a copy against the latest grub, or have there not been many changes there yet?
[11:16] <cjwatson> ev: would probably be a good idea after alpha-1.  let's leave it with what we have for now?
[11:16] <ev> sure
[11:29] <jhunt_> tseliot: hi - talking to apw about nvidia drivers: he mentioned that X may soon allow a graceful fallback from nvidia to nouveau. Meantime, could we consider maybe having a facility that only boots kernels compatible with the nvidia drivers?
[11:30] <tseliot> jhunt_: err.. what do you mean by "only boot kernels compatible with the nvidia drivers"?
[11:33] <jibel> cjwatson, thank you for the info.
[11:35]  * cjwatson fixes MoM, I think
[11:35] <cjwatson> and wags a finger at quadrispro for breaking it. :)
[11:37] <quadrispro> cjwatson, huh? did i break something? :/
[11:37] <cjwatson> quadrispro: your mixxx upload that didn't unpack properly
[11:37] <cjwatson> (to Debian)
[11:38] <cjwatson> MoM gets really upset by that kind of thing :)
[11:39] <quadrispro> cjwatson, maybe is it due to the fact that I use different quilt series?
[11:39] <cjwatson> you fixed it in -4
[11:40] <cjwatson> but it was stuck trying to unpack -3
[11:40] <quadrispro> ahhh! yes
[11:40] <cjwatson> wonder why that didn't get rejected on upload to Debian, though
[11:40] <quadrispro> yep, and this was actually 'cause of that I said above
[11:41] <quadrispro> I wrongly appended the patch to the quilt's ubuntu.series, so it got a little mess
[11:42] <cjwatson> you mean it failed to unpack in Ubuntu but not in Debian?
[11:42] <quadrispro> no, only in Debian, I didn't upload it to Ubuntu
[11:42] <cjwatson> ok
[11:43] <cjwatson> still; I think maybe MoM needs to be careful to ensure that the proper series file is used when unpacking
[11:43] <quadrispro> ACK
[11:44] <quadrispro> cjwatson, and I'd like to take a closer look at MoM, hope to do it soon
[11:45] <quadrispro> cjwatson, PS: I tried to catch you during the natty's release party in London, but I failed to find you guys :(
[11:47] <cjwatson> the maverick party?  it was buried deep in the weird uncharted depths of London
[11:47] <cjwatson> or you mean you found the party but not me?
[11:48] <quadrispro> no, I get to the "shooting star" but seemed there was no party at all
[11:57] <quadrispro> leaving, bye!
[12:11] <chrisccoulson> cjwatson - for bug 616682 - do you still just want the patches backported from maverick, or am i ok to upload 2.10.0 to lucid-proposed? i just attached a minimal diff, showing what the upstream changes look like without all of the autotools bits in it
[12:19] <cjwatson> chrisccoulson: the whitespace changes and the like are tedious, but I suppose that isn't too bad
[12:21] <chrisccoulson> cjwatson, yeah, it looks like quite a small diff, but i can take whichever approach you prefer for it anyway
[12:40] <jhunt_> tseliot: kernel linux-image-2.6.35-23-generic-pae breaks my nvidia (NVS 3100M). If I switch to linux-image-2.6.35-22-generic-pae I'm good.
[13:48] <jdstrand> didrocks: hi! do you have a moment to talk about unity vs the old gnome desktop? today's update really broke me
[13:49] <seb128> jdstrand, just ask your question
[13:49] <jdstrand> heh
[13:49] <seb128> jdstrand, if your machine is not capable of 3d a fix has been uploaded
[13:49] <jdstrand> yes, I guess that is irc 101 isn't it
[13:49] <seb128> it will start gnome-panel for you
[13:49] <didrocks> jdstrand: sure, that's a tricky issue, I'll let you read that first: https://lists.ubuntu.com/archives/ubuntu-desktop/2010-November/002689.html
[13:50] <jdstrand> well, my machine is capable of running unity, but let me read that first
[13:50] <didrocks> then, gnome-session has landed the change we needed last Monday and we will build a fallback solution for alpha2
[13:50] <seb128> jdstrand, I guess that post will not reply to your question then
[13:50] <seb128> that's about fallbacks
[13:51] <jdstrand> ok, so let me just say what happened
[13:51] <jdstrand> I'm running natty
[13:51] <jdstrand> every once in a while, I try unity be enabling the plugin
[13:52] <jdstrand> in the past there were bugs that affected my productivity, so I disabled the unity compiz plugin and used the classic plugin
[13:52] <jdstrand> so today, I did a natty upgrade from within the classic session and rebooted
[13:52] <jdstrand> I login, expecting a classic session, and no gnome-panel is launched
[13:52] <didrocks> jdstrand: what do you call "classic session", the "Ubuntu classic desktop" or "Ubuntu Desktop session"
[13:53] <seb128> I guess the second one
[13:53] <didrocks> you have two sessions in gdm
[13:53] <jdstrand> my background is drawn, with icons, so it is partially started
[13:53] <jdstrand> didrocks: I was going by the language in that email thread you mentioned
[13:53] <jdstrand> the traditional gnome desktop
[13:53] <seb128> jdstrand, so what you did is that your turned unity off from the unity session
[13:53] <didrocks> jdstrand: env | grep GDMSESSION
[13:53] <didrocks> you are in the unity session, not the classic one
[13:53] <seb128> didrocks,  you should probably not let users do that :p
[13:54] <didrocks> seb128: already planned for alpha2, need to add "mandatory plugins" in compiz
[13:54]  * jdstrand is confused
[13:54] <didrocks> just I can't do everything in a round :)
[13:54] <seb128> jdstrand, you basically shoted yourself on this one
[13:54] <jdstrand> when I disabled the plugin, I would logout and back in and have the traditional gnome desktop
[13:54] <seb128> jdstrand, the "default" session is unity now
[13:54] <jdstrand> yes
[13:54] <didrocks> jdstrand: you shouldn't do that, unity plugin will be mandatory
[13:54] <seb128> jdstrand, well it used to do that because were still running gnome-panel
[13:54] <seb128> jdstrand, which we stopped now since we don't need it
[13:55] <didrocks> jdstrand: then, in gdm, you have a "Ubuntu Classic Session" which runs compiz + gnome-panel
[13:55] <jdstrand> maybe that changed in today's update, but prior to today, I only saw one choice in gdm
[13:55] <didrocks> jdstrand: did you update to latest gnome-session?
[13:55] <jdstrand> and so I didn't know how to change to the traditional desktop
[13:56] <didrocks> 2.32.1-0ubuntu2 should get it
[13:56] <jdstrand> 2.32.1-0ubuntu3
[13:56] <didrocks> so, you should get it in gdm
[13:56] <jdstrand> btw, right this second I have:
[13:56] <jdstrand> $ env | grep GDMSESSION
[13:56] <jdstrand> GDMSESSION=gnome
[13:56] <jdstrand> but with unity
[13:56] <didrocks> yeah, this is the default session
[13:57] <didrocks> you have a gnome-classic one
[13:57] <didrocks> named Name=Ubuntu Classic Desktop
[13:57] <jdstrand> the only way I could get antyhing to work was to right click on the desktop, create a launcher to ccsm and then check the unity plugin
[13:57] <didrocks> jdstrand: yeah, in the future, yo uwon't be able to remove the unity plugin in the default session
[13:57] <didrocks> just not implemented yet
[13:57] <jdstrand> didrocks: so what I am hearing is that I should have a choice in gdm as to traditional vs unity. correct?
[13:58] <didrocks> jdstrand: right
[13:58] <jdstrand> ok, let me try that
[13:58] <didrocks> sure, keep me posted :)
[13:58]  * jdstrand -> logs out
[14:04] <jdstrand> didrocks: ok, I have the choice and gdm is picking one or the other, and unity launches ok, but logging into the classic desktop results in no window manager and my bottom panel not launching
[14:04] <didrocks> jdstrand: of course, if you don't enable the unity plugin
[14:04] <didrocks> jdstrand: and the dynamic detection is something not easy, as pointed in my post
[14:05] <jdstrand> didrocks: I need to have the unity plugin enabled in the classic desktop??
[14:05] <didrocks> it would answer the question why we don't launch gnome-panel dynamically
[14:05] <didrocks> jdstrand: well, let's use the name of the session
[14:05] <didrocks> jdstrand: are you telling about gnome-classic.desktop or gnome.desktop?
[14:05]  * jdstrand is just trying to use the terminology given in gdm now
[14:05] <didrocks> ok
[14:05] <didrocks> so gnome-classic.desktop?
[14:05] <jdstrand> gdm said Ubuntu Desktop or Ubuntu Desktop Classic or something
[14:05] <seb128> didrocks, gdm doesn't display the .desktop name
[14:06] <jdstrand> I chose Classic
[14:06] <jdstrand> my top panel started
[14:06] <didrocks> jdstrand: ok, and no panel, nor window mananger?
[14:06] <jdstrand> I have no window manager
[14:06] <jdstrand> I don't have a bottom panel
[14:06] <didrocks> hum, weird
[14:06] <didrocks> jdstrand: there is a drawing bug with the bottom panel, if you click on it, it doesn't appear?
[14:07] <jdstrand> since I had a top panel, I tried to go to Appearance and verified my desktop effects
[14:07] <didrocks> (I'm more surprized by the now window manager)
[14:07] <didrocks> jdstrand: well, it doesn't work yet with the new compiz
[14:07] <jdstrand> they were set to 'None' (odd, since I had them enabled prior to today)
[14:07] <didrocks> so, don't trust that
[14:08] <didrocks> ok, so, let's see what can happens
[14:08] <didrocks> happen*
[14:08] <didrocks> if you don't have a windowmananger, that means that ctrl + alt + t isn't working, right,
[14:08] <jdstrand> I also tried launcing ccsm to verify that the unity plugin wasn't started-- it was not checked, but I didn't change anything
[14:09] <jdstrand> well, hold on
[14:09] <didrocks> no, it's another compiz profile, so it should work without unity
[14:09] <jdstrand> let me start irssi on my console and then I can go back and forth
[14:09] <didrocks> ok :)
[14:09]  * jdstrand logs out again
[14:11] <jdstrand> ok, I am back
[14:12] <didrocks> ok, so, you have no window manager at all? ctrl + alt + t doesn't bring you a terminal, for instance?
[14:13] <jdstrand> didrocks: no window manager. ctrl+alt+t does not bring up a terminal. if I launch it from Applications, it starts but has no borders, etc
[14:13] <jdstrand> didrocks: interestingly, this time both the top and the bottom panel started
[14:14] <didrocks> jdstrand: the bottom panel always started, it's just not drawn sometimes and you have to click on it to get the X window to be redrawn
[14:14] <jdstrand> didrocks: I can also say that the cursor is 'spinning' so it is working on starting something (this is on login, not ctrl+alt+t)
[14:14] <didrocks> I'm more concerned about the "no window manager part"
[14:14] <jdstrand> ok
[14:14] <didrocks> one sec
[14:15] <jdstrand> ps auxww| grep compiz gives nothing
[14:15] <jdstrand> same with metacity
[14:15] <jdstrand> let me try with a new user
[14:15] <didrocks> jdstrand: gconftool-2 -g /desktop/gnome/session/required_components/windowmanager
[14:15] <jdstrand> ok, let me try that
[14:16] <jdstrand> didrocks: compiz
[14:16] <didrocks> jdstrand: can you try launching compiz in a terminal and pastebin the output?
[14:16] <jdstrand> k
[14:20] <jdstrand> didrocks: http://paste.ubuntu.com/538661/
[14:20] <jdstrand> didrocks: the segfault happened after two flashes
[14:21] <jdstrand> at least I think it was two...
[14:21] <didrocks> and you get unity on the ubuntu desktop session? (no compiz segfault)?
[14:21] <jdstrand> didrocks: yes
[14:21] <didrocks> oh, you have the ini backend
[14:21] <seb128> seems you standard profile is broken
[14:22]  * jdstrand doesn't know what you are talking about
[14:22] <didrocks> seems that your profile is broken, right
[14:22] <seb128> jdstrand, the compiz config on your GNOME session
[14:22] <didrocks> well, you can easily reset it
[14:22] <didrocks> but having it can be interesting
[14:22] <jdstrand> I try to not enable anything special in compiz
[14:22] <didrocks> jdstrand: so, can you please pack somewhere ~/.config/compiz-1 and then rename that?
[14:23] <jdstrand> I always just use 'Normal desktop effects'
[14:23] <didrocks> (also, do you have a ~/.config/compiz)
[14:23] <dholbach> james_w, Daviey: if you have a tiny little bit of time could you review my harvest merge proposal?
[14:23] <james_w> dholbach, sure, link?
[14:23] <jdstrand> earlier this week I saw something with 'Extra effects for increased bling' or some such
[14:23] <jdstrand> so I did enable that
[14:23] <jdstrand> but not the 'everything plus the kitchen sink' option
[14:23] <dholbach> james_w, https://code.launchpad.net/~dholbach/harvest/581732/+merge/40950
[14:23] <didrocks> jdstrand: well, forget about the capplet for now, it's broken
[14:24]  * Daviey dodged that bullet! :)
[14:24] <didrocks> jdstrand: so, can you please pack what I requested? :)
[14:24] <jdstrand> ie, there were 4 options in Appearances/Desktop Effects, whereas in the past there were 2
[14:24] <seb128> jdstrand, the desktop effects tab has not been updated for the new compiz
[14:24] <jdstrand> didrocks: I understand, I am just trying to give you history as to how I got here
[14:24] <seb128> jdstrand, so it might create issues
[14:25] <seb128> it might well screwed compiz 0.9 compiz
[14:25] <jdstrand> I do not have ~/.config/compiz
[14:25] <didrocks> jdstrand: ok, then just tar ~/.config/compiz-1 and remove it then
[14:25] <didrocks> jdstrand: you should remove it once under another windowmanager, like metacity --replace
[14:25] <didrocks> to avoid it dumping the config again
[14:26] <mdz> pitti, thanks for merging the apport python traceback stuff. if you get bug reports about cases I might have missed, let me know and I will try to fix them.
[14:26] <pitti> mdz: thanks for improving that
[14:26] <jdstrand> didrocks: so I am in unity (so I could start firefox for the paste)
[14:27] <jdstrand> didrocks: I will logout of unity, then into classic, then try to start compiz manually, then tar up compiz-1
[14:27] <jdstrand> didrocks: does that sound reasonable?
[14:28] <jdstrand> didrocks: ie, does that repeat my steps sufficiently?
[14:28] <didrocks> jdstrand: just add an additional step
[14:28] <didrocks> jdstrand: oh no sorry, that should work
[14:28] <jdstrand> ok
[14:28] <didrocks> (if you confirm compiz is crashing :))
[14:29] <jdstrand> yes
[14:29] <didrocks> just tar and rename compiz-1 without compiz running
[14:29] <hallyn_> oh, compiz was segfaulting?  i did not some weird behavior on my natty laptop, but wasn't at tis console enough to be able to play with it
[14:34] <jdstrand> didrocks: http://people.canonical.com/~jamie/compiz-1.tar.gz
[14:34] <smoser> mvo, ping
[14:34] <didrocks> jdstrand: ok nice, now tell me with removing that + restarting compiz :)
[14:35] <jdstrand> didrocks: ok, I might also point you to http://paste.ubuntu.com/538670/
[14:35] <jdstrand> didrocks: those are the segfaults from this morning as seen in kern.log
[14:35] <mvo> hey smoser
[14:36] <didrocks> jdstrand: ok, you frigthened me :)
[14:36] <jdstrand> didrocks: the 08:29:39 was for my last login from a second ago
[14:36] <jdstrand> didrocks: oh sorry, I apparently had some from yesterday too that I hadn't noticed
[14:36] <didrocks> ok
[14:37] <didrocks> so, compiz still segfaults for you?
[14:37] <jdstrand> didrocks: starting at 07:37:05 is after I upgraded this morning
[14:37] <smoser> mvo, soren suggested i ping you about some bzr /launchpad branch stacking issues.
[14:37] <didrocks> jdstrand: well, with broken config and without a stacktrace doesn't really help :)
[14:37] <smoser> i think i'm getting the correct help in #launchpad though. (bzr-set-stacked-url)
[14:38] <jdstrand> didrocks: sure, but it is interesting that it is all happening in libstaticswitcher.so (for the most part)
[14:38] <jdstrand> anyway, let me move compiz-1 aside and see what happens
[14:38] <didrocks> jdstrand: right, but there are pending issue with the new mainloop
[14:38] <didrocks> jdstrand: so, it can be related
[14:41] <jdstrand> didrocks: ok, moving compiz-1 aside, I now have a window manager, but all kinds of applets have 'quit unexpectedly'. Trash, Show Desktop, System Monitor, Notification Area, Clock, Window List, and Workspace Switcher
[14:42] <mvo> smoser: if you could repush your old branches that would help, here is the background
[14:42] <mvo> smoser:  https://bugs.launchpad.net/bzr/+bug/681431
[14:42] <mvo> smoser: but btw, I think this should be fixed in LP for all branches
[14:42] <didrocks> jdstrand: yeah, this is a know bug related to compiz vs gnome-panel race
[14:42] <jdstrand> didrocks: so I tried clicking 'Reload' on them, and it was working until I reloaded the system monitor, and compiz crashed and my panel went away
[14:42] <mvo> smoser: its not really going to scale if I/soren ping each and every branch owner
[14:42] <mvo> smoser: let me file a RT ticket
[14:42] <smoser> mvo, yes, i would say it should be fixed on launchpad side, quite possibly results in loss of data.
[14:42] <jdstrand> maybe my panel was there and I had to click on it, I don't know
[14:43] <smoser> well, if user starts trying to "fix" things.
[14:43] <didrocks> jdstrand: this is due to compiz 0.9 and reparenting, sam is working on this but there can be a lot of side effects
[14:43] <smoser> mvo, where would you want me to push them ?
[14:43] <didrocks> jdstrand: I have a workaround to minimize that, just try to delay gnome-panel load
[14:43] <didrocks> jdstrand: and remove the startup animation
[14:43] <jdstrand> didrocks: ok. I have noticed this in the past few weeks, so that seems no worse
[14:43] <didrocks> jdstrand: you will still get some, but less
[14:43] <mvo> smoser: its dosn't really matter, it seems like a push under a new name is enough to work around the problem
[14:43] <seb128> didrocks, I don't think delay works
[14:44] <seb128> didrocks, I've tried to wait 15 seconds, compiz crashes after clicking on a few "reload" buttons
[14:44] <seb128> and gnome-panel is still in a weird state
[14:44] <seb128> like applets not drawed
[14:44] <didrocks> seb128: I tried a sleep 5 && and didn't get any crash, but as it's a timing issue, I was just maybe lucky
[14:44] <smoser> mvo, yeah. i got it fixed. maxb in #launchpad suggested http://j.maxb.eu/~maxb/bzr-set-stacked-url , then bzr reconfigure --unstacked (which is appropriate in this case)
[14:44] <mvo> smoser: aha, cool!  thanks
[14:44] <jdstrand> I have found that stopping gdm and logging in again usually works
[14:44] <didrocks> like the animation disabled, you got the issue less present
[14:44] <maxb> I really ought to get that thing built into bzr core
[14:45] <mvo> smoser: I want to keep vmbuilder in a vaguely working state would be nice to unitfy 0.11 and 0.12 again
[14:45] <didrocks> jdstrand: yeah, because it's loading faster as it's in the cache (that's my guess) and so compiz doesn't have to cope with it…
[14:45] <smoser> mvo, yeah... i have gone rogue on 0.11, i agree.
[14:45] <smoser> :)
[14:45] <jdstrand> didrocks: right, that was my guess too
[14:45] <mvo> smoser: ;)
[14:46] <didrocks> jdstrand: hopefully, we'll have a fix end of week/next week but they can have drawbacks (right now, with the new reparenting event, all menus are disabled :))
[14:46] <jdstrand> didrocks: anyway, it seems I am back to the state I was in yesterday-- a racy classic desktop, but at least I can work
[14:46] <smoser> and, i agree, it would be good to have vmbuilder in a working state, but for me, i have a functional uec image build process, and getting that onto 0.12 doesn't benefit me at all, just costs me.
[14:46] <didrocks> jdstrand: yeah, sorry for that, and thanks for the configuration, I sent it to upstream
[14:46] <smoser> also, before moving to 0.12, i'd consider live-helper
[14:47] <jdstrand> didrocks: thanks for your time. you might want to get the word out on not disabling the unity plugin in ccsm, cause people are blogging about how that is the right way to disable unity
[14:47] <didrocks> jdstrand: yeah, but my server is in a box as I'm moving so my blog is down, I'll try to get that soon :)
[14:48] <jdstrand> heh
[14:48] <jdstrand> didrocks: thanks again
[14:48] <didrocks> jdstrand: you're welcome :)
[14:49] <mvo> smoser: ok, good to know.
[14:49] <mvo> smoser: what is the advantage of live-build?
[14:49] <jdstrand> didrocks: I'll toss something out on my blog in the mean time
[14:49] <seb128> didrocks, get jcastro to blog
[14:49] <didrocks> jdstrand: thanks :)
[14:49] <didrocks> seb128: yeah, can do that
[14:50] <jdstrand> didrocks: do you need a bug filed for the compiz-1 business are are we good?
[14:50] <smoser> mvo, well, while i'm extremely *not* interested in starting a flame war, the interest in live-build would be centered around perceived livelyhood/maintainance of vmbuilder.
[14:50] <jdstrand> s/are are/or are/
[14:50] <didrocks> jdstrand: please, file one and attach the tarball
[14:51] <didrocks> jdstrand: with the debug output in the description
[14:51] <mvo> smoser: fair enough, I don't have strong feelings either way, I just need something to build image for my upgrade tester :)
[14:51] <smoser> exactly.  no politics involved, i want something that works, and is likely to be maintained in the future.
[14:53] <smoser> mvo, fwiw, my opinion, is of course, that you should use our images on ec2 for your upgrade tester :)
[14:53] <mvo> smoser: will they work with kvm?
[14:53] <smoser> the uec images "sort of" work with kvm.
[14:53] <smoser> https://help.ubuntu.com/community/UEC/Images
[14:54] <mvo> interessting, I have a look
[14:54] <mvo> I need them as kvm as often its useful/iimportant to run it on the local machine for better control etc
[14:54] <smoser> yeah, i understand that they might not fit the bill.
[14:55] <smoser> but on ec2, you can fairly easily start an instance of a fully updated M and 'do-release-upgrade -d'
[14:55] <smoser> with local mirrors, and instance start up is < 2 minutes ,and all automatiable.
[14:55] <mvo> yeah, the release upgrader tester has a ec2 backend (that is not used much though)
[14:56] <mvo> one of the disadvantages of the ec2 test is that it does not test the kernel upgrade and the xserver (both will be done with kvm). however that is only a tiny disadvantage as most problems are from the packages (maintainer script issues etc)
[14:57] <smoser> kernel upgrade works in maverick and going forward
[14:58] <smoser> and i'm working on getting that into 10.04
[14:58] <mvo> oh? sweet, good to know
[14:58] <smoser> https://launchpad.net/~smoser/+archive/lucid-kernel-upgrades has more info
[15:01] <ogra> doko, bug 683683 ... given that klibc didnt change between maverick and natty would you agree that this is likely toolchain related ?
[15:02] <ScottK> pitti: Thanks for the feedback (re hal and stuff)
[15:02] <pitti> ScottK: nice to see it going!
[15:03] <ScottK> I've got what I believe are the needed changes for Kubuntu to drop in right after Alpha 1.
[15:04] <dholbach> thanks a lot james_w
[15:04] <doko> ogra: ENOCLUE. but I don't follow your logic from "klibc unchanged" -> "toolchain issue"
[15:05] <james_w> dholbach, pas de problem
[15:05] <ogra> doko, hmm, seems linaro sees it too
[15:06] <ogra> doko, bug 683582
[15:06] <ogra> doko, well, what else could it be? klibc doesnt have much build deps so it must be something in the toolchain
[15:07] <dholbach> james_w, tu as appris à parler Français? :)
[15:07] <doko> ogra: but klibs isn't rebuilt
[15:07] <ogra> hmm
[15:08] <ogra> so we probably *should* rebuild it :)
[15:08] <jdstrand> didrocks: fyi bug #683686
[15:08]  * ogra is clueless as you can see
[15:09] <didrocks> jdstrand: thanks :)
[15:14] <mdz> pitti, I noticed the "update TeamReports" item on TechnicalBoardAgenda got removed---are we not doing that anymore?
[15:15] <pitti> mdz: I didn't remove that; I thought we should bump that to "[next due: May 2011]" or so
[15:16] <mdz> pitti, wasn't it done every month?
[15:16] <pitti> mdz: I thought we'd do it once per cycle?
[15:16] <pitti> it was on the agenda as a reminder when we should handle it
[15:16] <mdz> pitti, hmm, ok. I must be confused
[15:17] <pitti> mdz: argh, sorry
[15:17] <pitti> mdz: I am confused
[15:17] <pitti> mdz: somehow I thought you were speaking about the brainstorm review
[15:17]  * pitti engages brain this time
[15:18] <pitti> mdz: updating the teamreports page is of course something that we should do after each meeting
[15:18] <highvoltage> hmmm brains
[15:18] <pitti> mdz: it's not a topic in the meeting per se, but an action that the chair has to do as part of the post-processing
[15:20] <cjwatson> should be done every meeting, yes
[15:23] <smoser> cjwatson, do you have a minute ? (you're back from holiday?)
[15:25] <cjwatson> yeah
[15:25] <ogra> doko, hmm, looking at runinitlib.c is see the following at the top, http://paste.ubuntu.com/538687/ could it be that eglibc defines these constants differently on arm now ?
[15:25] <smoser> I'd like your insight on bug 683379.
[15:26] <smoser> the two prompts are not avoidable by DEBIAN_FRONTEND=noninteractive
[15:26] <doko> ogra: we still have the same eglibc in natty as in maverick-updates/-proposed
[15:26] <ogra> damned
[15:27] <cjwatson> smoser: the best way to get such bugs handled quickly is to provide DEBCONF_DEBUG=developer output
[15:27] <smoser> ah.
[15:27] <smoser> this is new to me. i can do that.
[15:27] <cjwatson> smoser: and, if possible, to attach /var/cache/debconf/config.dat from before the upgrade
[15:28] <smoser> coming your way
[15:28] <cjwatson> any installation logs you have would be good too
[15:28] <smoser> i can attach install logs also
[15:32] <dholbach> Daviey, I fixed the merge proposal with regard to james_w's comments - maybe you can review now? :-P
[15:35] <james_w> dholbach, I don't think it needs another review
[15:35] <dholbach> alrightie
[15:35] <dholbach> I'll go and merge it then
[15:35] <smoser> cjwatson, i'm guessing DEBCONF_DEBUG=developer sends info to stderr ?
[15:35] <cjwatson> yeah
[15:42] <smoser> cjwatson, hm... DEBCONF_DEBUG=developer sudo apt-get install grub-pc 2>debconf-developer.out
[15:42] <smoser> gave me empty debconf-developer.out
[15:42] <hggdh> can someone please give me Status edit rights to coreutils bugs?
[15:43] <dholbach> james_w, Daviey: I'll release a new Harvest soon, so people can take advantage of giving us .json feeds as opposed to .csv
[15:43] <james_w> \o/
[15:44] <cjwatson> smoser: sudo DEBCONF_DEBUG=developer ...
[15:46] <smoser> oh yeah.
[15:46] <smoser> shoot
[15:46] <smoser> i didn't realize that sudo took 'env' type arguments.
[15:47] <smoser> i had actually done sudo env KEY=VALUE before to get around sudo's cleaning of environment
[15:52] <ogra> Keybuk, if i break=bottom, "exec run-init /root /sbin/init" should theoretically work, right ?
[15:54] <Keybuk> not sure
[15:54] <Keybuk> can't remember whether panic() turns the initramfs into a shell
[15:54] <ogra> hmm, k
[15:54] <Keybuk> or spawns a sub-shell
[15:54] <Keybuk> check your PID
[15:54]  * ogra is seeing weird run-init errors on armel recently
[15:55] <ogra> and given that nothing changed the only thing i can imagine is that the args are not handed over right
[15:55] <Keybuk> if panic() turns initramfs into a shell
[15:55] <Keybuk> (exec bash)
[15:55] <ogra> (i.e. i would expect run-init to work fine instead of spilling an "Unknown error")
[15:55] <Keybuk> then yes, that will work
[15:56]  * ogra talks about bug 683683 and is a bit clueless
[15:57] <ogra> Keybuk, so you mean the kernel panicing there would be normal ? (and shoudl drop me into bash)
[15:57] <ogra> if thats supposed to happen, it never worked on armel :)
[15:58] <cjwatson> panic starts a subprocess
[15:58] <cjwatson> right now
[15:58] <ogra> hmm, it doesnt on armel
[15:58] <smoser> cjwatson, ok. i've attached everything you asked for to bug 683379. if you want access to a pristine instance, let me know.
[15:59] <Keybuk> ogra: initramfs panic() not kernel PANIC
[15:59] <ogra> oh !
[15:59] <ogra> k, thanks
[15:59] <Keybuk> cjwatson says it spawns a sub-shell
[15:59] <Keybuk> so you cannot run-init from that
[16:03] <ogra> hmm, k i see it now in initramfs-tools/scripts/functions
[16:04] <ogra> intresting though that i get the same error when trying
[16:08]  * ogra tries init=/bin/bash
[16:09] <ogra> hrm. same error
[16:28] <mrenouf|work> sorry guys
[16:28] <mrenouf|work> all fixed
[17:25] <cjwatson> mvo: RT#42717: if it were me, I'd file a question on https://answers.launchpad.net/launchpad-code
[17:25] <cjwatson> IME that gets good response on tickets requiring LOSAs
[17:26] <cjwatson> (that said I see Andrew has already added a losa tag to that RT ticket so maybe just leave it there for now ...
[17:26] <cjwatson> )
[17:31] <dobey> anyone know why adding -Vfoo:Bar=1.9.0 to DEB_DH_GENCONTROL_ARGS_ALL in rules wouldn't work as expected? it's getting passed to dh_gencontrol it looks like, but dpkg-deb is failing with a parse error as the value isn't actually getting substituted it seems
[17:33] <cjwatson> did you put it after --?
[17:33] <cjwatson> (what exactly does the DEB_DH_GENCONTROL_ARGS_ALL line say?)
[17:37] <cjwatson> Riddell: should bug 683400 be reassigned to kdebindings?
[17:38] <Riddell> cjwatson: yes, I can do that
[17:40] <ScottK> pitti: I approved the pg 9.0 backport request today.  In the future if those lag for approval, please feel free to ping me to have a look.
[17:45] <dobey> cjwatson: DEB_DH_GENCONTROL_ARGS_ALL = -Vbanshee:Version=$(BANSHEE_VERSION)
[17:45] <dobey> cjwatson: do i have to put a -- at the beginning of that?
[17:45] <cjwatson> -- -Vbanshee:Version=...
[17:45] <cjwatson> the dh_gencontrol(1) manual page should explain
[17:52] <linuxfreaker> After how many hours Alpha 1 is releasing?
[17:53] <dobey> thanks cjwatson
[17:54] <statik> hi ScottK! low priority ping about this backport, anything else I should do before it's ready to be approved? https://bugs.launchpad.net/lucid-backports/+bug/683193
[17:55] <cjwatson> linuxfreaker: some
[17:55] <cjwatson> linuxfreaker: we don't give exact times
[17:57] <ScottK> statik: Commented.
[17:57] <statik> ta
[17:59] <linuxfreaker> Does Ubuntu 11.04 Alpha 1 has kernel 2.6.37-rc4
[17:59] <linuxfreaker> I just saw it under http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=shortlog;h=refs/heads/master-next
[17:59] <cjwatson> no, it'll be -rc3
[18:00] <cjwatson> if we pulled in -rc4 at this point we'd have to move back the alpha release
[18:00] <linuxfreaker> ahh
[18:00] <linuxfreaker> So -rc3 will be final kernel being put
[18:00] <linuxfreaker> Why it says rebase to v2.6.37-r c4
[18:03] <cjwatson> linuxfreaker: because the kernel team is preparing that for their next set of packages, *after* alpha 1
[18:03] <cjwatson> alpha 1 is just a snapshot of development
[18:38] <mvo> thanks cjwatson, answers is a good idea, I will do that next time
[18:44] <pitti> ScottK: ah, thanks; TBH I forgot about it myself
[18:56] <pitti> c/quit
[18:56] <ogra_ac> pitti, nearly :)
[19:09] <bryceh> chrisccoulson, mind if I take over?
[19:11] <chrisccoulson> bryceh - yeah, sure
[19:12] <chrisccoulson> @pilot out
[19:12] <bryceh> @pilot in
[19:12] <ebroder> The bot handles multiple pilots, btw
[19:22] <cody-somerville> mvo, Is python-apt uploaded to pypi?
[19:23] <SpamapS> bryceh: ping? can you get this one into lucid-proposed by any chance? https://code.launchpad.net/~clint-fewbar/ubuntu/lucid/mysql-dfsg-5.1/increase-killtimeout/+merge/41403
[19:26] <bryceh> SpamapS, sure thing
[19:26] <bryceh> SpamapS, is there a .dsc generated for it I can grab?
[19:29] <SpamapS> bryceh: err.. no but I could generate one I 'spose. :-P
[19:36] <SpamapS> bryceh: though you can very easily just apt-get source mysql-dfsg-5.1 and then apply the patch linked to..
[19:36] <SpamapS> bryceh: probably easier than I can serve the dsc+orig+diff to you..
[19:39] <SpamapS> bryceh: but.. for your viewing pleasure .. http://spamaps.org/files/mysql-dfsg-5.1_5.1.41-3ubuntu12.8.dsc
[19:39] <SpamapS> err.. 403.. doh
[19:41] <SpamapS> bryceh: ok, you should be able to dget that .dsc now
[19:44] <bryceh> SpamapS, thanks
[19:46] <bryceh> SpamapS, upload sponsored
[19:49] <mvo> cody-somerville: I don't think its at pypi, I never uploaded it
[19:49] <mvo> cody-somerville: but maybe someone else did
[19:49] <PROGRAM_IX> 'evening all.
[19:52] <SpamapS> bryceh: sweet thanks! :)
[19:54] <highvoltage> Is there any reason why ubuntu-desktop depends on unity (as apposed to recommending it)?
[19:55] <highvoltage> we need to have unity available as an option in Edubuntu, and it's kind of hard to make it just optional when edubuntu-desktop depends on ubuntu-desktop
[19:57] <cjwatson> Recommends would seem more in keeping with standard seed practices, certainly
[20:00] <highvoltage> cjwatson: what would you recommend? Should I open a bug or poke someone in the desktop team?
[20:03] <highvoltage> (filing bug anyway)
[20:15] <achiang> hm, booting the Lucid alternate ISO, what do I do to make it only install a console-based system? a command line option? something during d-i?
[20:17] <achiang> i don't get any menus, since i booted a USB key
[20:18] <achiang> ah, 'cli' on the boot command line will do it
[20:19] <achiang> maybe it's "install cli"
[20:33] <achiang> hm, i don't think that was it. i still see d-i installing xservers. :-/
[20:49] <ebroder> pitti: ping, do you know off the top of your head if there's an easy fix I could apply locally for bug #592239?
[20:50] <ebroder> Oh, it's marked as a dup. Missed that
[20:55] <achiang> the help text on the installer says that 'cli' is available, but trying that, there's an error saying 'cli kernel not found'. pressing <tab> to see what grub knows about, i don't see cli in there either...
[21:59] <smoser> pitti, are you around ?
[22:00] <smoser> I was doing some verification of bug 671103 and found that it did not fix one issue that I had expected it to fix (bug 671103)
[22:01] <smoser> whoops. second bug was bug 683890
[22:01] <smoser> i am not clear on the process here, but I have a fix for the second and would would like to get it in as soon as possible.
[22:45] <Patrickdk> how do I go about publishing a package to a ppa for both lucid and hardy?
[22:45] <Patrickdk> I can get it to work for one or the other, but not both
[22:46] <ScottK> Patrickdk: PPA support is in #launchpad
[22:47] <Patrickdk> ah heh, been attempting to find the right place :)