[12:18] <mhz> hi all
[12:18] <mhz> I have seen some pages and still can't find the place to file a bug
[12:18] <mhz> https://launchpad.net/malone
[12:19] <mhz> I want to file a bug related to LaunchPad
[12:19] <mhz> not to other aps.
[12:19] <mhz> any hint?
[12:22] <sivang> mhz: you mean, you want to find a "prodct" per rosetta/malone/etc ?
[12:24] <sivang> mhz: currently I think, you have to file it just against "launchpad" and assign it to the person who's responsible to the piece of module you are opening the bug against
[12:26] <mhz> ooooh, ok
[12:27] <mhz> sivang: when choosong package name, i ge to 'select SourcePackageName'
[12:27] <mhz> and I get launchpad-integration
[12:27] <mhz> not just launchpad
[12:27] <mhz> is it the same?
[12:32] <sivang> mhz: can you send me a link?
[12:32] <mhz> sure
[12:33] <mhz> w8
[12:34] <mhz> sivang: 1st) https://launchpad.net/malone/bugs/+package
[12:35] <mhz> there, I press choose at Source Package Name
[12:36] <mhz> and if i understand correctly, I type launchpad
[12:36] <mhz> then, I only get launchpad-integration
[12:37] <lifeless> right
[12:37] <lifeless> launchpad is not packaged.
[12:37] <mhz> I imagined
[12:38] <lifeless> so you can't file bugs against it from there.
[12:38] <mhz> then how do I file a bug related to it?
[12:38] <lifeless> https://launchpad.net/products/launchpad/+bugs
[12:38] <mhz> lifeless: yhx
[12:38] <mhz> thx
[12:38] <ddaa> lifeless: I sent merge request for sftp://chinstrap.warthogs.hbd.com
[12:38] <mhz> i was getting dizzy 
[12:39] <mhz> :)
[12:39] <ddaa> That has apparently worked for launchpad.
[12:39] <ddaa> (though there were conflicts)
[12:39] <lifeless> ddaa: that wont work. it has to be chinstrap.ubuntu.com
[12:39] <ddaa> Why should it fail for pybaz?
[12:39] <ddaa> Mh
[12:39] <ddaa> right, the address for launchpad was on ubunt.com
[12:40] <sivang> mdz: " Report a bug about A set of Bugs" ?
[12:40] <sivang> oops
[12:40] <sivang> that was for mhz 
[12:42] <sivang> mhz: what's that gotta do with launchpad-integration?
[12:43] <mhz> sivang: 
[12:43] <mhz> nothing to do with it
[12:44] <mhz> sivang:  launchpad-integration
[12:44] <mhz> sorry
[12:44] <mhz> sivang:  Bug #4586
[12:44] <Ubugtu> Malone bug #4586: Many ubuntu related actions/work are not being tracked Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4586
[12:44] <mhz> LOL!!! Ubugtu
[12:45] <mhz> good work
[12:47] <ddaa> bug #1000
[12:47] <Ubugtu> Malone bug #1000: There are too many bug reports in Malone Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Rejected http://launchpad.net/malone/bugs/1000
[12:55] <niemeyer> ddaa: Hey
[12:56] <niemeyer> ddaa: The branch is merged
[12:56] <niemeyer> ddaa: Just have to send to pqm now
[12:56] <ddaa> niemeyer: cool what was it?
[12:57] <ddaa> I'm waiting for the merge here as well, as I just came back (and about to go to deb)
[12:57] <niemeyer> ddaa: Just simple stuff.. .bzrignore, and harness.py was changed in both places.
[12:57] <niemeyer> But not in an incompatible way..
[12:57] <Nafallo> hehe, deb ;-)
[12:58] <niemeyer> ddaa: How to submit that for pqm?
[12:58] <ddaa> https://wiki.launchpad.canonical.com/PQMSetup
[12:59] <ddaa> the .bzr/parent must be sftp://chinstrap.ubuntu.com/path/to/landing/target and the .bzr/x-pull-data must be set properly to the rsync target (what to merge from).
[12:59] <ddaa> niemeyer: I must go to bed now.
[01:00] <ddaa> Thanks. In case you do not manage to do the pqm thing, I'll do it tomorrow first thing.
[01:00] <ddaa> the postfix configuration is very important
[01:01] <ddaa> because pqm is so stupid
[01:01] <ddaa> I set the mail host name here to "allouche.net", and since my login on my workstation is "david", and the authorized user to pqm is david@allouche.net, it works.
[01:06] <lifeless> heh
[01:06] <lifeless> I so love ignorance-is-bliss
[01:06] <bob2> beats a pie in the face
[01:06] <lifeless> the authorised user comes out of the gpg signature, has nothing to do with the mail config
[01:07] <lifeless> the mail config is solely for sending the feedback emails.
[01:07] <lifeless> bob2: :)
[01:07] <lifeless> yup
[01:07] <lifeless> the spec does say that.
[01:11] <niemeyer> lifeless: Is there any other document explaining the PQM interface?
[01:11] <niemeyer> lifeless: Also, am I allowed to request merges?
[01:13] <lifeless> have you completed the PQMSetup instructions ?
[01:13] <niemeyer> :-)
[01:13] <lifeless> if not, then no.
[01:13] <niemeyer> lifeless: Yes, I did.. but long ago
[01:14] <lifeless> there is the pqm manual, and source at http://people.ubuntu.com/~robertc/pqm/trunk
[01:14] <niemeyer> lifeless: And never received an answer from you about my gpg key
[01:14] <niemeyer> lifeless: So I guess not.
[01:15] <niemeyer> Heh.. I just removed an old PQM arch tree I had around, thinking "Humm.. at that point Robert must have it under bzr"
[01:15] <niemeyer> I'm glad to have guessed right :)
[01:21] <niemeyer> lifeless: So, have you register my gpg key as allowed for submissions?
[01:21] <niemeyer> registered
[01:21] <niemeyer> lifeless: Should I resend it?
[01:21] <lifeless> una momento
[01:24] <lifeless> whats your key id ?
[01:25] <lifeless> niemeyer: you did not include that in your email
[01:25] <lifeless> nor your fingerprint. tsk.
[01:25] <niemeyer> lifeless: Well, I included the key itself..
[01:25] <lifeless> niemeyer: so, what is the key id ?
[01:26] <niemeyer> 66643A0C
[01:26] <lifeless> thanks
[01:27] <lifeless> ok
[01:27] <lifeless> you are now in the canonical group
[01:29] <niemeyer> Thanks!
[01:30] <niemeyer> So, what the merge request URL looks like? sftp://...?
[01:31] <niemeyer> lifeless: ^
[01:31] <lifeless> the script should generate it correctly, if your parent is set (to sftp://chinstrap.ubuntu.com/home/w...), and your public copy is set correctly (via x-push-)
[01:32] <niemeyer> lifeless: I'll create the email by hand..
[01:32] <lifeless> why ?
[01:32] <niemeyer> lifeless: I'm not using push (rsync).. my postfix has its own custom configuration..
[01:33] <lifeless> uhm,. So the push we use is rsync ;). 
[01:33] <niemeyer> lifeless: And it's more interesting to see how things work by starting that way.
[01:33] <lifeless> any good postfix config will work correctly, its only broken ones where sender: cannot recieve replies that are problematic.
[01:33] <lifeless> but up to you.
[01:34] <lifeless> if you want to fiddle, just use the script 'submit-bzr-merge 'test' gustavo@niemeyer.net'
[01:36] <niemeyer> lifeless: Will bzr push rsync://... work correctly if there are nested trees?
[01:36] <lifeless> it onyl pushes the current tree
[01:36] <lifeless> i.e. it ignores the nested trees.
[01:36] <niemeyer> Nice
[05:31] <Burgundavia> how can I delete items on the calendar?
[05:32] <Burgundavia> and more importantly, should the admin of a group not have complete access over the calendar? (I am getting an permissions error on the doc team calendar)
[08:28] <lifeless> SteveA: ping
[09:21] <SteveA> lifeless: hi
[09:38] <SteveA> lifeless: around?
[09:42] <carlos> morning
[10:12] <carlos> SteveA, hi, morning
[10:13] <carlos> SteveA, I need that someone reviews TranslationUploads implementation
[10:13] <carlos> SteveA, we need it for dapper import into launchpad
[10:31] <SteveA> carlos: mail me, and i will do it later today
[10:31] <carlos> SteveA, ok, thanks
[10:59] <SteveA> ddaa: hello
[10:59] <ddaa> Hey SteveA
[11:01] <SteveA> ddaa: i want to arrange a meeting to talk about bzr launchpad branch stuff, with you and lifeless.  can we do monday morning?
[11:02] <ddaa> For a relatively late value of morning.
[11:02] <SteveA> the times available are monday morning or wednesday morning
[11:03] <ddaa> I'd prefer early afternoon, say 2pm.
[11:03] <ddaa> That... 1300 UTC
[11:03] <SteveA> that won't work for lifeless
[11:03] <ddaa> Then, I can arrange to be there.
[11:04] <ddaa> monday morning, say, 0900 UTC?
[11:04] <SteveA> i think 1000 UTC would be okay
[11:04] <SteveA> shall we say monday, 1000 UTC?
[11:04] <ddaa> Deal.
[11:04] <SteveA> okay. i'll mail.
[11:05] <ddaa> BTW, any news on the asterix-at-DC front?
[11:06] <ddaa> I'm still for comfortable with chat, but voice as an addition could be nice for this sort of meeting.
[11:06] <ddaa> * still more comfortable
[11:06] <SteveA> no news
[11:08] <ddaa> SteveA: do you have an agenda for the meeting?
[11:09] <ddaa> I'd like to be able to think a bit about it in advance.
[11:13] <SteveA> talk about the launchpad / supermirror / bzr end of things
[11:13] <SteveA> and establish how all the moving parts fit together, and who is responsible for what
[11:15] <ddaa> Mh... I guess I will figure out what this kind of meeting is about :)
[11:58] <ddaa> lifeless, SteveA: PQM appears frozen again
[11:59] <ddaa> Please kick it up or something, that's blocking BranchDataStorage :(
[12:11] <matsubara> good morning!
[12:15] <ddaa> Hey matsubara
[12:16] <ddaa> I saw that you have a merge request in PQM
[12:16] <ddaa> unfortunately, it has gone catatonic again.
[12:20] <Wellark> Hi
[12:21] <matsubara> ddaa: salgado will take care of it, I hope. :)
[12:22] <ddaa> Apparently Znarl will do. At least he acked my request on #canonical
[12:22] <Wellark> translation tool for breezy is missing some projects
[12:22] <Wellark> libgksu and libgksuui
[12:23] <Wellark> they are included for hoary but not for breezy
[12:23] <carlos> Wellark, hi
[12:23] <Wellark> who has the power to add projects to distributions in launchpad?
[12:24] <carlos> Wellark, I'm a Rosetta developer
[12:24] <carlos> let me check
[12:24] <Wellark> thanks!
[12:25] <carlos> Wellark, is https://launchpad.net/distros/ubuntu/breezy/+sources/gksu/+translations what you are looking for?
[12:26] <Wellark> no, it is not
[12:27] <Wellark> to fully translate the dialog that is shown for example when you launc synaptic you also need libgksuui package to be translated
[12:27] <carlos> Wellark, sorry, https://launchpad.net/distros/ubuntu/breezy/+source/libgksu1.2/+translations
[12:27] <Wellark> yeah, and that too :)
[12:28] <Wellark> so breezy is missing 'libgksuui' and 'libgksu'
[12:28] <carlos> Wellark, ?
[12:28] <carlos> Wellark, I gave you already libgksu, right?
[12:28] <Wellark> oh yeah
[12:29] <Wellark> that's right
[12:29] <carlos> Wellark, and the other: https://launchpad.net/distros/ubuntu/breezy/+sources/libgksuui1.0/+translations
[12:29] <carlos> I will fix the 'review' templates now.
[12:30] <Wellark> carlos: thank you very much :)
[12:30] <Wellark> if notice that something else is missing should I just come bugging you here or what?
[12:32] <carlos> Wellark, file a bug or ping me here
[12:32] <carlos> anyway, those were not missing, it's just that the navigation is not as good as it should...
[12:32] <\sh> hmmm...
[12:32] <Wellark> ok. thanks.
[12:33] <\sh> did canonical trandmarked launchpad? (the Name?)
[12:34] <\sh> i'm asking because of launchpad.com ;)
[12:39] <carlos> \sh, I think they were there before us
[12:41] <\sh> carlos: I just stumbled across while I was using the wrong tld for launchpad ... but ok
[01:31] <BjornT> is there any bzr equivalent to 'baz diff $rocketfuel'? i.e only comparing up to the rf revision that is merged into my branch?
[01:47] <ddaa> BjornT: I do not think so
[01:48] <ddaa> I can imagine what would be the syntax though
[01:50] <ddaa> something like "bzr diff --merged $upstream"
[01:50] <BjornT> ddaa: ok. do you know if i can specify a specific revno when using -r branch:... ? i seem to recall some syntax to specify a revno, but the bzr documentation is somewhat lacking....
[01:51] <ddaa> Right now, you can examine the log, get the revid of the first nested revision in the latest merge, and do "bzr diff -r revid:$REVID"
[01:51] <ddaa> oh yes
[01:51] <ddaa> for a revno, it's just "bzr diff -r $REVNO"
[01:52] <ddaa> hu... shit it appears that the current packaged bzr cannot specify a branch in diff...
[01:52] <BjornT> but will that work if i: branch -> hack some -> merge -> hack some more? i.e, i want to see both the 'hack some' and 'hack some more' changes
[01:53] <ddaa> I think the "bzr diff -r revid:$REVID" thing would work right. The annoyance is that you have to find the revid by hand.
[01:54] <ddaa> That could be automated, with a "--merged $BRANCH" option that find the latest entry of $BRANCH's revision-history which is an ancestor of the current revision.
[01:54] <ddaa> Feel free to bounce that idea to the bzr folks.
[01:55] <ddaa> That should not be a very difficult feature to implement. Probably an afternoon's hack for somebody not familiar with the code.
[01:57] <BjornT> yeah, i'll do that later, i used it quite often with baz. thanks
[02:00] <BjornT> yeah, if i'm bored this weekend i might try to implement it myself. it'd be a good way of learning more how bzr works
[02:30] <gino> hello good morning 
[02:41] <stub> That pqm kill doesn't seem to have taken... I'll have a look
[02:42] <ddaa> stub: thanks
[02:52] <stub> ddaa: I've run out of things to try. arch-pqm --run appears to be silently doing nothing. Perhaps a lock file somewhere, so it thinks things are still running. But I don't know where it would be.
[03:25] <stub> ddaa: I think that has clear it (found the log file and a lock file)
[03:25] <stub> c/clear/cleared
[03:27] <stub> Or maybe not :-(
[03:49] <salgado> I can't merge from rocketfuel. always get an "bzr: ERROR: exceptions.IndexError: string index out of range". can this be related to the bzr version?
[03:52] <ddaa> stub: at least niemeyer's merge request is now off the queue
[03:53] <ddaa> so, if you hear a huge grinding noise, don't worry, it's just bzr merging the branches patch :)
[04:31] <bradb> wow
[04:31] <bradb> it's amazing how re-installing gnome-panel can fix really arcane gnome problems
[04:31] <bradb> my power cord wasn't properly plugged in last night, so my computer ran out of juice during the night
[04:32] <bradb> tried logging into gdm, and all i saw was brown
[04:32] <bradb> lynx'ing to google.ca would give a 400, bad request
[04:32] <bradb> couldn't even connect to IRC (i.e. trying this through a failsafe gnome term)
[04:32] <bradb> reinstall gnome-panel, and i am reborn
[04:38] <zyga_> since launchpad is written in python I'll ask this here
[04:38] <zyga_> I've installed libapache-mod-python2.4 and I cannot really get past the hello-world test, is this a bug or should I keep googling
[04:40] <carlos> zyga_, launchpad is not using libapache-mod-python2.4
[04:40] <carlos> zyga_, we use zope
[04:40] <carlos> zyga_, anyway, I have a friend that is using Ubuntu's mod-python2.4 without problems
[04:40] <zyga_> on apache 1.3 or 2 ?
[04:40] <carlos> so it's not a bug (at least I don't think so)
[04:40] <carlos> 2
[04:40] <zyga_> hmm I'm trying this on 1
[04:41] <zyga_> I keep getting  python_handler: make_obcallback returned no obCallBack!
[04:41] <bradb> stub: TestRequest doesn't appear to work with browser notifications (e.g. self.request.response.addNotification == AttributeError...this happens in bugattachments.txt, for example, because it tests views). any quick suggestions on a simple way to fix this?
[04:44] <stub> bradb: We will need to extend it in the same way we needed to extend HTTPRequest to implement the notifications
[04:44] <bradb> ok
[04:44] <zyga_> carlos: I also noticed this in my logs
[04:45] <zyga_> make_obcallback(): could not import mod_python.apache.
[04:45] <zyga_> make_obcallback(): could not call init.
[04:46] <stub> bradb: webapp/tests/test_notification might be a help (or not...)
[04:47] <stub> bradb: In fact, we just might need to make TestRequest adaptable to INotificationRequest
[04:48] <stub> The MockSession and adapters in test_notification.py can be reused
[05:02] <salgado> hey SteveA. I replied to your code review, have you seen it?
[05:03] <salgado-lunch> brb
[05:04] <SteveA> salgado-lunch: ok.  there's a shipit issue i want to talk about
[05:05] <salgado> SteveA, wanna talk now?
[05:06] <bradb> stub: thanks for the pointers, I'm looking around the code a bit. elsewhere, will X-Malone-Bug get rolled out on tuesday? it's revno 2835.
[05:07] <SteveA> bradb: i think it should be X-Launchpad-Bug
[05:07] <stub> bradb: Yes
[05:07] <SteveA> when we have the issue tracker with email support, will we have X-IssueTracker-Issue ?
[05:08] <SteveA> it is silly.  so, we should have X-Launchpad-KindOfThing as the header names to use
[05:08] <SteveA> i don't disagree
[05:09] <SteveA> but this way, when the app names change on various whims, we have less software to update
[05:10] <bradb> i'd hesitate slight to make a change to X-Malone-Bug. it's in an approved spec already, and we don't have any other X- headers for other apps yet, AFAIK.
[05:10] <bradb> s/slight/slightly/
[05:10] <SteveA> salgado: do we still have this issue that when people come to shipit they get directed to get a launchpad account, and then don't get guided back to shipit?
[05:10] <SteveA> bradb: sorry i didn't read the spec sooner
[05:11] <SteveA> i don't want to have to change this later, when people already have mail filters set
[05:11] <bradb> SteveA: it's in https://wiki.launchpad.canonical.com/InitialBugContacts
[05:11] <salgado> SteveA, yes, we still have this issue
[05:12] <SteveA> bradb: the header will often contain distro and people and product details.  it should be called X-Launchpad-Bug
[05:12] <salgado> SteveA, I tried to get you to review https://wiki.launchpad.canonical.com/ProperSignUpWorkflow at UBZ, but I couldn't as I wrote it in the last days. IIRC, kiko reviewed it
[05:13] <SteveA> salgado: there's a spec!  that's great.  let me read it...
[05:13] <SteveA> although, i'll do that code review for carlos first
[05:14] <bradb> SteveA: ok, i'll change it
[05:14] <carlos> SteveA, thanks!
[05:15] <SteveA> salgado: i'd say don't use the referer header.  make it an explicit query string parameter.  i need to think about this a little more though.
[05:15] <SteveA> can we talk about this a bit later?
[05:15] <SteveA> bradb: thank you.
[05:16] <salgado> SteveA, sure
[05:19] <SteveA> jamesh: what happened to the diffs on https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ ?
[05:20] <salgado> SteveA, I can't merge from rocketfuel since this morning. maybe this is not a problem only with me..
[05:21] <SteveA> carlos: can you get me a diff to review?
[05:21] <carlos> SteveA, yes
[05:21] <carlos> just a second...
[05:22] <bradb> salgado: i have no problem merging from rocketfuel
[05:22] <bradb> i rsync down the pre-built tree and do a local merge
[05:24] <salgado> bradb, would you try a merge from sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel?
[05:25] <salgado> chinstrap, I mean
[05:25] <bradb> salgado: I'd strongly recommend the pre-built tree option, tbh.
[05:25] <bradb> i've just sync'd up my two current working trees to my local copy of rf
[05:26] <carlos> SteveA, sent to your mailbox
[05:28] <SteveA> thanks carlos
[05:29] <bradb> salgado: 
[05:29] <bradb> bradb@oxygen:~/canonical/malone-feedback-messages $ bzr merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[05:29] <bradb> SSH id_dsa password:
[05:29] <bradb> bzr: ERROR: Channel request for unknown channel 1
[05:29] <bradb> Nothing to do.
[05:29] <BjornT> bradb: do you know how often the pre-built tree get rebuilt? it doesn't seem to contain the latest patch, which was commited more than 10 hours ago
[05:29] <bradb> every half hour
[05:30] <bradb> by the way, by "pre-built" i meant that it has all the dep trees inside it, not that it's "pre-built" with make
[05:30] <salgado> bradb, are you using bzr from jbailey's repo?
[05:31] <bradb> yeah
[05:31] <bradb> just updated
[05:31] <bradb> about an hour ago
[05:31] <SteveA> the launchpad team should generally be using the "integration" packages from jbailey
[05:32] <BjornT> so, who can check what's wrong with the launchpad tree?
[05:32] <salgado> BjornT, I guess the same person that can check what's wrong with pqm. lifeless 
[05:37] <salgado> aha. it failed in rocketfuel too
[05:38] <salgado> BjornT, https://chinstrap.ubuntu.com/~dsilvers/paste/file53b1Kj.html
[05:38] <salgado> BjornT, would you add that to your email too? :)
[05:38] <BjornT> salgado: yeah, branch fails as well
[05:39] <BjornT> and pull
[05:39] <salgado> really? I branched (on chinstrap) this morning and it worked fine. this is weird...
[05:42] <BjornT> yeah. it could be ddaa's branch that caused this (ddaa: wasn't it something strange with your branch?). branch fails with HistoryMissing
[05:42] <jbailey> SteveA: The -integration branch isn't tested with abently's bzrtools.  Dunno if that's a concern for you or not.
[05:42] <SteveA> lifeless has asked that the launchpad team use the integration branch
[05:42] <SteveA> so we test the latest fixes
[05:42] <ddaa> BjornT: what with my branch?
[05:43] <ddaa> It's not landed yet in rocketfuel
[05:43] <SteveA> can you set it up to run the tests before making the packages, and not make them if tests fail?
[05:43] <ddaa> AFAIK it's currently the chunk clogging PQM
[05:44] <ddaa> oh, right everybody is complaining about that ATM
[05:44] <ddaa> was working for me yesterday... not tried since then.
[05:44] <BjornT> ddaa: will "Rev 2836: [r=SteveA]  Merging bzr branch support in.." did land, which seems to include your branch
[05:44] <BjornT> s/will/well/
[05:45] <ddaa> BjornT: really?
[05:45] <BjornT> ddaa: yeah
[05:46] <jbailey> SteveA: That already happens.
[05:47] <jbailey> SteveA: The only cases where the selftests don't really catch things are when things are compiled on install.
[05:47] <jbailey> SteveA: A bit of code in something that's not used as part of the build/selftest can kill it at install time.
[05:48] <SteveA> that's fine then.  thank you
[05:48] <SteveA> lifeless has a "very conservative" bzr branch that can be used for recovering things if the integration branch screws up
[05:49] <jbailey> Is it called "releases"? =)
[05:50] <SteveA> it is releases + special launchpadding love
[05:50] <jbailey> The dapper archive now has 0.6.2 in it, and I plan to keep it quite up to date.  We could probably ask the backports folks to make sure that it's available for breezy if y'all aren't crazy enough to run dapper. =)
[05:51] <SteveA> the launchpad folks have a special line in sources.list.  i think that's fine for now.
[05:51] <SteveA> but, having a recent bzr in backports would be good for getting other folks to try out the recent improvements
[05:52] <ddaa> BjornT: apparently it has not made it into the rocketfuel-built tree...
[05:53] <BjornT> ddaa: yeah, which might be because merging/pulling/branching from the rocketfuel tree doesn't work...
[05:55] <ddaa> Well, bzr log on archives/rocketfuel/launchpad/devel gives that funny IndexError after the log for 2835, and bzr revno there says 2835
[05:55] <ddaa> I have no idea where your 2836 comes from.
[05:55] <BjornT> hmm
[05:55] <BjornT> although, arch-commits says it was merged
[05:55] <stub> The launchpad tree issue would explain PQM being blocked.
[05:56] <ddaa> arch-commits?
[05:56] <ddaa> what's that?
[05:57] <salgado> ddaa, http://rince.africaninspace.com/mailman/private/arch-commits/
[05:57] <BjornT> ddaa: the arch-commits mailing list
[05:58] <ddaa> Thanks, I see... I do not think I heard of it before...
[06:03] <elmo> Kinnison: around?
[06:03] <Kinnison> elmo: Yes, barely
[06:03] <Kinnison> but lying in bed is boring
[06:03] <elmo> Kinnison: ok, it's not urgent, but fyi mawson is down to 5G
[06:03] <Kinnison> elmo: thanks
[06:04] <elmo> it's got 272G in it's librarian dir
[06:06] <stub> I can clean that out if nobody needs to access the files in the Librarian
[06:06] <Kinnison> on mawson? leave the librarian please
[06:06] <Kinnison> I'll look into it
[06:06] <Kinnison> stub: I'd rather you used mawson as a test-bed for the librarian GC
[06:07] <stub> Oh - assumed asuka. Sorry.
[06:08] <SteveA> Kinnison: and you say "has signed coc" doesn't sound rude!
[06:12] <bradb> looks like a typo
[06:12] <bradb> DO YOU ACCEPT THE COC
[06:14] <Kinnison> SteveA: Not when it's CoC
[06:15] <SteveA> you threatening to vandalize my existing coc tattoo ?
[06:15] <Kinnison> naah, just sign it :-)
[06:15] <bradb> hm, it looks like pqm isn't even accepting new merge requests (i.e. i submitted one a while ago and it's not showing up in the queue)
[06:15] <bradb> heh
[06:16] <bradb> only partly successfully
[06:27] <elmo> argh
[06:27] <elmo> bradb: pretty please with a cherry on top could malone explain WHY it's mailing me?
[06:27] <elmo> or bjornt or whoever
[06:28] <bradb> elmo: because you confirmed your email address and are in some way involved in one or more bugs somewhere.
[06:28] <bradb> elmo: if you want to delete them, you can filter on the Reply-To
[06:28] <elmo> bradb: no, dude, I want malone to be useful
[06:28] <elmo> even bugzilla manages this, AFAICR
[06:29] <bradb> elmo: the mail you received, what's it about?
[06:29] <bradb> and to whom is it addressed?
[06:29] <elmo> http://people.ubuntu.com/~james/tmp/mail.txt
[06:29] <elmo> (reload, updated)
[06:30] <elmo> even a simple "You received this email because you're the assignee" or "the maintainer" or "in the CC list" or whatever, would help
[06:30] <elmo> these mails as they are just make me go "huh? wtf?" every time
[06:31] <bradb> elmo: right, so what appears to be happening is this:
[06:31] <bradb> Launchpad Admins are subscribed to #1458
[06:31] <bradb> you are a launchpad admin
[06:31] <bradb> the lp admin team doesn't have an email address
[06:31] <bradb> so each member of that team receives a mail individually
[06:31] <bradb> that's why you get the mail
[06:32] <bradb> there are various ways we can make this suck less, of course.
[06:32] <bradb> like, tell you why you're getting the email.
[06:33] <bradb> elmo: given the context above, how would you prefer launchpad to behave when a change is made on that bug?
[06:34] <bradb> i'll add the explanation of why you're getting the mail right now
[06:35] <elmo> b
[06:35] <elmo> Changed in: Launchpad (upstream) Status: New => Accepted
[06:35] <elmo> (err, with a newline before Status)
[06:36] <elmo> I don't know how, but I feel that could be improved.  It's not obvious what "Changed in" refers to, for a start
[06:36] <elmo> but my main gripe is the "WTH am I getting this", if you're fix that, I'd be happy :)
[06:38] <elmo> would it be sane to maybe add the short description (or summary or whatever it's called) to the mail?  it'd mean I wouldn't have to fire up a web browser to work out what it's talking about
[06:38] <elmo> OTOH, maybe some people would find that redundant/annoying
[06:39] <bradb> the bug "summary" is usually empty for bugs, but i'd agree that the bugmails generally don't contain enough context to figure out how what's going on
[06:40] <bradb> so, when a comment is made (particularly on an older bug, where one has already removed that thread from their Inbox), one often has to click on the URL in the mail to get enough context to make sense of things
[06:48] <SteveA> carlos: i send you the first part of the code review.
[06:49] <carlos> SteveA, ok, thanks
[07:07] <bradb> BjornT: can you think of any reason to not add a signature to every bugmail? (i.e. "-- \nYou are receiving this email because...")
[07:10] <jblack> Gabriel Neuman: ping
[07:14] <bradb> aka, gneuman 
[07:15] <ddaa> SteveA: it looks very much like my branches borked rocketfuel and pqm somehow
[07:16] <niemeyer> ddaa: Weren't they borked before?
[07:16] <niemeyer> ddaa: I mean, wasn't it borked before?
[07:16] <ddaa> before, pqm was borked like a cow with a leg missing
[07:17] <ddaa> now it's borked like a cow whose brains were shot out using an elephant gun
[07:17] <niemeyer> Oh, that's quite borked indeed..
[07:17] <niemeyer> :-)
[07:18] <ddaa> it's also very untidy
[07:18] <bradb> at least you have some control over a cow with a leg missing
[07:56] <gneuman> bradb
[07:56] <gneuman> sorry
[07:56] <gneuman> was out
[07:56] <gneuman> j black
[07:56] <gneuman> pong
[07:56] <gneuman> jblack, 
[07:57] <gneuman> time out..
[07:57] <jblack> gneuman: I'm here. You're here. Life is good. :)
[07:57] <gneuman> =] 
[07:57] <jblack> gneuman: We need to figure out which bzr you're using
[07:57] <jblack> can you run bzr --version for me?
[07:57] <gneuman> yes
[07:58] <gneuman> bzr (bazaar-ng) 0.7pre
[07:59] <carlos> see you
[07:59] <jblack> Mind if I attach that to your bug, or you attach it?
[08:00] <gneuman> wahtever
[08:02] <BjornT> bradb: i think it's a good idea to add signatures to bugmail, i've already started adding signatures to the error messages that the incoming email interface produces
[08:03] <bradb> ok, i'll do that then on my malone-bugmail-why-the-heck-am-i-getting-this branch
[08:06] <bradb> BjornT: Is there some doctestumentation I can read that demos what those sigs look like?
[08:10] <BjornT> bradb: you can look at emailtemplates/no-affects-target-on-submit.txt. but i'm not sure it will be useful, since that is an email you get when actively sending one yourself. general bugmail is different, since you can get it without doing anything.
[08:11] <bradb> I just wanted to make sure that our footers are consistent
[08:13] <BjornT> bradb: yeah. feel free to change that footer if you need to.
[08:23] <niemeyer> Hey, anyone knows who has write access to the shipit FAQ?
[08:24] <matsubara> niemeyer: maybe salgado
[08:24] <niemeyer> (ubuntulinux.org/support/...)
[08:24] <gneuman> niemeyer, perhaps salgado, but he is out
[08:25] <niemeyer> Ok.. thanks
[08:37] <salgado> niemeyer, I guess silbs has, and maybe hno73 too
[08:37] <salgado> (but I'm just guessing)
[08:41] <niemeyer> salgado: I've mailed Jane.. thanks!
[09:18] <niemeyer> See ya
[09:26] <thierry> is it normal that I can't request fix upstream for some packages?
[09:27] <thierry> and I'd like to find every bug filed for lbreakout2 package... where do i go?
[09:30] <salgado> thierry, why you can't request a fix upstream?
[09:30] <thierry> salgado : because the package is not in the search list
[09:31] <thierry> salgado : example here https://launchpad.net/distros/ubuntu/+source/ghextris/+bug/4618
[09:31] <Ubugtu> Malone bug #4618: [PATCH]  ghextris absolute icon path problem Fix req. for: ghextris (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4618
[09:31] <thierry> I'd like to get a upstream fix for that but when I want to choose ghextris as upstream package, it's not in the search list
[09:31] <bradb> thierry: https://launchpad.net/distros/ubuntu/+source/lbreakout2/+bugs to answer your second question
[09:32] <thierry> bradb : thanks
[09:32] <bradb> thierry: what's "upstream" to you?
[09:33] <thierry> bradb : well the next release like dapper but if it doesn't make dapper, it will make the next one... you know, the most recent changed package
[09:34] <bradb> thierry: that's how bugs work by default. i.e. they "slip" between releases if they don't get fixed.
[09:35] <bradb> when a bug is opened, it can optionally be targeted to be fixed in specific releases of a distribution
[09:35] <bradb> mainly for things like backporting
[09:36] <bradb> there's also a forward-looking targeting mechanism: milestones. but before i get ahead of myself, IIUC, the default bug report behaviour does what you're asking.
[09:37] <thierry> bradb : k but seb128 told me that I should ask for a upstream fix in about all of the bugs I send about absolute icon path
[09:38] <bradb> thierry: what page are you using to try and request the upstream fix?
[09:38] <bradb> i.e. what URL
[09:39] <thierry> the choose menu of this one https://launchpad.net/distros/ubuntu/+source/ghextris/+bug/4618/+upstreamtask
[09:39] <Ubugtu> Malone bug #4618: [PATCH]  ghextris absolute icon path problem Fix req. for: ghextris (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/4618
[09:39] <bradb> thierry: right, so not every project uses Malone.
[09:40] <bradb> thierry: if the upstream you're interested in isn't using Malone, you won't be able to request the fix upstream inside Malone.
[09:41] <bradb> if you don't find the upstream you're interested in on that page, that project is probably not using Launchpad
[09:42] <thierry> bradb : but it's only about a file in the package... what do I do then? ask a fix in dapper?
[09:43] <bradb> thierry: you don't have to do anything extra. by default bugs are reported in "the current release". if the developers don't get around to fixing them in the current release, the bugs will "slip" to the next release automatically.
[09:43] <thierry> cool
[09:43] <thierry> thanks
[09:43] <bradb> no prob
[09:49] <ddaa> Apparently, the problem with rocketfuel ATM is not caused by my data.
[09:49] <ddaa> I merged my patch into rocketfuel, then pulled on top of the previous revision, and it works.
[09:49] <ddaa> Or maybe the bug only appears in more convoluted cases.
[09:50] <ddaa> at least, it's clear that the archives/rocketfuel/launchpad/devel is corrupt.
[10:18] <bradb> elmo: I have a fix that adds a useful (I hope) footer to the bugmail so I'll merge it the next time a window of time opens up where pqm is accepting patches. The fix will probably not make the cut for this Tuesday's rollout, but next Tuesday's it'll be in prod.
[10:43] <lifeless> somehow we've got a historymissing exception in lp
[10:43] <lifeless> fixing
[10:53] <mpt> lifeless, got a minute?
[11:17] <lifeless> mpt: sure
[11:21] <mpt> lifeless, I was trying to work out the bzr equivalent of baz diff rocketfuel@canonical.com/launchpad--devel--0
[11:22] <mpt> bradb said it was bzr diff -r branch:/path/to/branch
[11:22] <lifeless> thats right
[11:23] <lifeless> except its not
[11:23] <mpt> but bzr diff -r branch:../archives/rocketfuel/launchpad produces a "no namespace registered" error
[11:23] <lifeless> :)
[11:23] <lifeless> branch: gets the tip of the branch
[11:23] <lifeless> ancestry: is more like what 'baz diff' does, it takes the current merge point instead.
[11:23] <lifeless> try
[11:23] <lifeless> bzr diff -r ancestry:/home/mpt/archives/rocketfuel/launchpad
[11:25] <mpt> lifeless: same again: "bzr: ERROR: No namespace registered for string: u'ancestry:/home/mpt/hacking/archives/rocketfuel/launchpad'"
[11:26] <lifeless> ancestor sorry
[11:26] <lifeless> not ancestry
[11:27] <mpt> ah, that looks like it's doing something
[11:27] <mpt> perhaps a couple more examples in the diff section of http://bazaar.canonical.com/IntroductionToBzr ?
[11:28] <mpt> thanks lifeless 
[11:28] <mpt> Now I just need to work out why psycopg is crashing on startup
[11:52] <CosmoDad> I've just created a launchpad account to contribute to Ubuntu's wiki. My username/password are not accepted, however, although I've finished the account creation process and both inputs are correct
[11:53] <CosmoDad> the wiki login says "incorrect password", but I'm 100% sure it's correct
[11:57] <mpt> CosmoDad, so you can log in to Launchpad itself using the same password?
[11:59] <CosmoDad> mpt: yes I can. launchpad expects email address instead of user name, however.
[12:00] <mpt> hmmm
[12:00] <CosmoDad> mpt: I just realized ubuntu wiki wants email as well but labels it "name"
[12:00] <mpt> yyyyyeah
[12:00] <mpt> that could be better labelled
[12:01] <mpt> does it work with your e-mail address? :-)
[12:01] <CosmoDad> mpt: it does
[12:01] <mpt> so that's a bug in the design of our wiki installation, then
[12:02] <mpt> unfortunately I don't know where such a bug should be reported
[12:03] <CosmoDad> mpt: Me neither. I'll check on that..
[12:03] <sivang> funny, I got used to calling "name" for the email address :)
[12:03] <CosmoDad> mpt: thanks for asking me for working launchpad logon. That made me try the email address at the Ubuntu wiki
[12:04] <CosmoDad> sivang: what do you say for name then? :)