[12:05] <mpt> Good afternoon *now*
[12:05] <mpt> kiko, that list isn't a list of headings, or a menu
[12:05] <mpt> which is why both "distribution management" and "any other aspect of Launchpad" aren't capitalized
[12:06] <mpt> "Malone", "Rosetta", and "Calendar" are capitalized because they're proper nouns
[12:07] <cyberix> jordi: https://gnunet.org/svn/
[12:07] <cyberix> jordi: I'll go sleep now
[12:07] <cyberix> good night everyone
[12:08] <kiko> okay mpt 
[12:10] <mpt> in other news, https://staging.ubuntu.com/ isn't working for me
[12:11] <mpt> oh, now it loads
[12:16] <Burgwork> please contrast http://bugzilla.gnome.org/describeuser.cgi and https://launchpad.net/people/cburger/+assignedbugs (the default view for bugs)
[12:16] <Burgwork> the gnome bugzilla one is actually useful for a large number of uses, the malone one for only one
[12:17] <kiko> it's also a custom gnome bugzilla hack
[12:17] <kiko> cprov, e a?
[12:17] <Burgwork> that is fine
[12:17] <Burgwork> regardless  of where it comes fomr
[12:18] <kiko> I was just remarking on it -- that it's not in bugzilla upstream
[12:18] <kiko> not disagreeing
[12:18] <cprov> kiko: email
[12:19] <cprov> kiko: going down to discuss it
[12:19] <kiko> u
[12:22] <kiko> 3@#!@#@!
[12:32] <mpt> Burgwork, I'm designing that page today <https://wiki.launchpad.canonical.com/MaloneFrontPages>
[01:20] <Burgwork> mpt, you make my heart sing
[03:02] <mpt> hi stub
[03:03] <stub> mpt: Morning
[03:03] <mpt> stub, currently staging.launchpad.net redirects to staging.ubuntu.com. It would make more sense if the opposite was true. Is that something you can fix, or is it a matter for RT?
[03:03] <stub> It is a matter for rt
[03:04] <mpt> ok
[03:04] <stub> If you are sending in a request, make sure to mention librarian.staging.launchpad.net and shipit.staging.launchpad.net (I'm not sure what URLs they are on off the top of my head)
[03:05] <stub> And that I'll reconfigure the staging launchpad instance once it is done if necessary
[03:13] <mpt> stub, what should librarian.staging.launchpad.net do?
[03:13] <mpt> currently it says "these aren't the droids you're looking for" over HTTP, and (like staging.launchpad.net) gives me broken ShipIt over HTTPS
[03:14] <mpt> and librarian.launchpad.net is broken in different ways (hello, Warthogs Bugzilla!)
[03:15] <stub> mpt: librarian is only available over http, and that 404 is the correct response for the root url
[03:15] <stub> So it looks like librarian.staging.launchpad.net is working on the correct domain.
[03:20] <mpt> shipit.staging.launchpad.net and shipit.staging.ubuntu.com don't work at all
[03:20] <mpt> Is there a ShipIt staging server at all?
[03:21] <mpt> If ShipIt is part of Launchpad under the hood, I suppose that's a meaningless question, it's just that ShipIt on staging isn't accessible
[03:30] <lifeless> IIRC just use the right paths and it will work
[03:31] <mpt> ah, https://staging.ubuntu.com/shipit/
[03:33] <mpt> wow, this is a mess
[04:24] <stub> mpt: https://shipit.staging.canonical.com/ is the current shipit one
[04:24] <stub> (Just for variety)
[04:28] <stub> mpt: Can you please bounce me the rt response you got back? I need the rt number.
[04:28] <elmo> 2073
[04:30] <stub> Ta
[04:42] <mpt> stub, I corrected item #2
[04:42] <mpt> in that https://librarian... should redirect to http://librarian... because the Librarian does only HTTP
[04:50] <mpt> *sigh*
[04:51] <mpt> The two most recently registered products in Launchpad are "WordPress 2.0" (we already have WordPress) and "WordPress 2.0 Thai L10N"
[05:09] <mpt> More from the bad data dept.: https://launchpad.net/people/?name=.name&searchfor=peopleonly
[05:14] <Burgundavia> mpt, aside from teams, does LP have any plans for saying "I know this person" and for integrating web of trust infromation?
[05:15] <mpt> Burgundavia, not as far as I know
[05:15] <mpt> what would that be useful for?
[05:15] <Burgundavia> mpt, for the "everything but wipe your ass"-side of LP
[05:15] <ajmitch> iirc under the hood there's FOAF that could be used
[05:16] <mpt> Burgundavia, why does http://doc.ubuntu.com/ include Kubuntu release notes but not Ubuntu release notes?
[05:16] <Burgundavia> mpt, no idea, likely a bug in the build scripts, ping mdke_ 
[05:17] <mpt> How similar are the Ubuntu and Kubuntu release notes?
[05:18] <Burgundavia> mpt, no idea, never looked at any Kubuntu docs
[05:22] <mpt> hmm, quite similar
[05:22] <mpt> except the Ubuntu release notes are much harder to find :-)
[05:34] <mpt> Burgundavia, your appraisal of https://wiki.launchpad.canonical.com/BugzillaImportProcess/DocumentationProduct would be useful
[05:35] <mpt> I just created an ubuntu-docs Launchpad project, to group the various UDP products
[05:36] <Burgundavia> mpt, the general gist is good, but our products are likely to change each release, so we need the ability to edit them
[05:37] <mpt> As I understand it, you can do that if you're a member of the ubuntu-doc team
[05:37] <Burgundavia> can we restrict that only admins?
[05:37] <mpt> since that's now the owner of the project and all the products
[05:37] <Burgundavia> can it do the auto forwarding to our mailing list?
[05:37] <mpt> Well, you could create an ubuntu-doc-admins team, but then why do you have the ubuntu-doc team?
[05:38] <Burgundavia> ok
[05:39] <Burgundavia> mpt, allowing access level control based on rights within a group might be a nice thing for the future
[05:41] <mpt> jamesh, ping
[06:13] <mpt> Good morning carlos 
[06:20] <jamesh> mpt: pong
[06:23] <mpt> jamesh, I mailed you to say that the BugzillaImport/DocumentationProduct page was finished
[06:40] <jamesh> mpt: I'll see if I can get things setup for an import soon.  I'll do a test import locally beforehand
[07:32] <jamesh> mpt_: started running the conversion, but it seems to have hung on the 4th bug for some reason
[07:34] <jamesh> I'll try again in a sec
[07:58] <jamesh> mpt_: all bugs with product=Documentation have been migrated.  It is just doing the bug duplicate run
[07:58] <jamesh> I'll get the shipit bugs done next
[08:07] <mpt_> thanks jamesh 
[08:10] <jamesh> mpt_: the 5 shipit bugs should be in as well now.
[08:10] <jamesh> could you annonce it to the ubuntu-docs list?
[08:11] <jamesh> it should all be complete now.
[08:11] <jamesh> https://launchpad.net/people/bugzilla-importer <- 8220 karma :)
[08:43] <mdke_> hey mpt_ 
[08:44] <mdke_> there was already a product/ubuntu-doc
[08:44] <mdke_>  [04:35:22]  < mpt> I just created an ubuntu-docs Launchpad project, to group the various UDP products
[08:51] <mdke_> also there is something strange going on here: https://launchpad.net/people/ubuntu-doc-lists
[08:51] <mdke_> there is already an ubuntu-doc person, and the Ubuntu Technical Board appears to be a member of ubuntu-doc-lists (??)
[08:55] <jamesh> mdke_: project != product
[08:56] <mdke_> jamesh, where do i find the project, and what is its purpose?
[08:56] <mdke_> i see it
[08:57] <jamesh> mdke_: https://launchpad.net/projects/ubuntu-doc
[08:57] <jamesh> ubuntu-docs, even
[08:57] <jamesh> the existing ubuntu-doc product is now associated with that project
[08:58] <mdke_> so https://launchpad.net/projects/ubuntu-docs/ubuntu-doc is the same as https://launchpad.net/products/ubuntu-doc ?
[08:58] <jamesh> yeah
[08:58] <mdke_> ok
[08:58] <mdke_> any idea about the ubuntu-doc-lists thing?
[08:59] <jamesh> https://launchpad.net/people/ubuntu-doc-lists was created as an owner for bugs previously owned by ubuntu-doc@lists.ubuntu.com in bugzilla
[08:59] <mdke_> and the TB is the only member?
[08:59] <mdke_> can that be moved to people/ubuntu-doc?
[08:59] <jamesh> and as the maintainer for the packages owned by ubuntu-doc@lists.ubuntu.com
[09:00] <jamesh> we don't currently have a way to merge teams through the web
[09:00] <jamesh> but file a bug or support request if you want them merged
[09:01] <mdke_> jamesh, i'll rely on you: do you think the ubuntu-doc-lists team is useful, given the existence of the ubuntu-doc team?
[09:01] <mdke_> i still don't understand LP enough to judge
[09:01] <jamesh> mdke_: it is essentially there as a way to direct bug mail through to the list
[09:02] <mdke_> ok...
[09:02] <jamesh> mdke_: same use as the ubuntu-doc@lists.ubuntu.com user in bugzilla was
[09:02] <mdke_> can ubuntu-doc be used for that?
[09:02] <jamesh> that's for you to answer
[09:02] <mdke_> argh
[09:02] <jamesh> if they are effectively the same thing, then we should probably work out a way to merge them
[09:03] <mdke_> I don't know whether ubuntu-doc can be used to put bug mail to the mailing list
[09:04] <jamesh> mdke_: if the email address for the team was set to the list address, then it could
[09:04] <jamesh> but you can't set the list address as the team email right now, since ubuntu-doc-lists owns the address
[09:04] <mdke_> ah, well we can do that
[09:04] <mdke_> right
[09:04] <mdke_> jamesh, ok so I file a bug, then when its done, we add the address
[09:05] <jamesh> mdke_: or get whoever does the merge to migrate the email address
[09:06] <mdke_> jamesh, ok even better
[09:07] <jamesh> mpt__: https://launchpad.net/people/jamesh <- apparently I have an "OpenGPG key" :)
[09:08] <mdke_> jamesh, one more minor thing. There are 2 open bugs assigned to me in bugzilla, but none in LP, any ideas? 
[09:09] <mdke_> http://bugzilla.ubuntu.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=matthew.east&emailassigned_to2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&c
[09:09] <mdke_> holy cow
[09:09] <mdke_> sorry
[09:10] <mdke_> merge request filed at bug 29177
[09:10] <Ubugtu> Malone bug 29177: "please merge people/ubuntu-doc and people/ubuntu-doc-lists" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29177
[09:47] <jamesh> mdke_: both of those bugs are imported: https://launchpad.net/products/ubuntu-doc/+bug/29143 and https://launchpad.net/products/distro-about-page/+bug/29167
[09:47] <Ubugtu> Malone bug 29143: "broken links to screenshots in "Getting Started"" Fix req. for: ubuntu-doc (upstream), Severity: Minor, Assigned to: Matthew East, Status: Confirmed
[09:49] <jamesh> mdke_: you can use the link https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/$bugzillaid to find the LP bug(s) corresponding to a particular bugzilla.ubuntu.com bug
[09:56] <mdke_> jamesh, ok, so the assigned field wasn't maintained, i can just reassign them
[09:56] <mdke_> hmm they are assigned to me
[09:59] <mdke_> dunno why i missed them, sorry
[10:00] <jamesh> mdke_: what do you mean?  Both of those bugs are listed as being assigned to "Matthew East"
[10:01] <mdke_> jamesh, sorry for wasting your time. I saw a sidebar earlier with "Your bugs" and it didn't have them in, but now i see I must have been mistaken
[10:01] <mdke_> thanks very much for your help on this
[10:02] <jamesh> mdke_: one of those two bugs is listed here: https://launchpad.net/people/mdke/+assignedbugs
[10:02] <jamesh> the other one is in the "Fix Committed" state (equivalent of PENDINGUPLOAD), so not shown
[10:03] <mdke_> yep
[10:04] <mdke_> jamesh, i've thought of one more question. Where a bug is subscribed to by me, and by a group of which I am a member, which goes to a mailing list, is there any way (otherthan procmail on my side or something) that I can avoid getting two copies of bugmail?
[10:19] <mpt> mdke_, what you probably want to do is set the mailing list as the "Initial Bug Contact" for the ubuntu-docs project
[10:19] <mpt> That way the mailing list gets notified of new bugs, and not about everything that happens to every bug
[10:19] <mdke_> yeah absolutely
[10:20] <mdke_> mpt, will that work for bugs reported on ubuntu/distros/ubuntu-docs?
[10:21] <mdke_> or do both need to be done separately
[10:22] <mpt> ubuntu-docs is a distro??
[10:22] <mpt> wait
[10:22] <mpt> I don't understand that question
[10:22] <mpt> What's ubuntu/distros/ubuntu-docs?
[10:22] <mdke_> sorry i'll rephrase
[10:23] <mdke_> it's distros/ubuntu i meant
[10:23] <mdke_> if somebody reportes a bug in ubuntu under the ubuntu-docs package
[10:23] <mdke_> which is what will normally happen
[10:23] <mdke_> will setting the "Initial Bug Contact" for the ubuntu-docs project mean that those bugs go to ubuntu-doc for QA?
[10:27] <mpt> Sorry mdke_, I missed your question
[10:28] <mdke_> ok
[10:28] <mdke_> mpt, if somebody reportes a bug in ubuntu under the ubuntu-docs package, will setting the "Initial Bug Contact" for the ubuntu-docs project mean that those bugs go to ubuntu-doc for QA?
[10:28] <mpt> oh, suck
[10:28] <mpt> It looks like projects don't have initial bug contacts yet :-/
[10:28] <mpt> only products do
[10:28] <mpt> so, here for example <https://launchpad.net/products/ubuntu-doc/+editbugcontact>
[10:28] <mdke_> ok
[10:28] <mdke_> will that apply then to bugs reported in Ubuntu too?
[10:29] <mpt> every new bug report for that product will mail that person
[10:29] <mpt> what do you mean by "reported in Ubuntu"?
[10:29] <mpt> Bugs about anything in Ubuntu won't mail that list
[10:29] <mpt> just bugs in the ubuntu-doc product
[10:29] <mdke_> i mean a bug reported in the ubuntu source package ubuntu-docs
[10:29] <mpt> ohhh
[10:29] <mpt> no, packages are separate
[10:29] <mdke_> because that is the only place we release our product
[10:29] <mdke_> so everyone will file it in Ubuntu
[10:29] <mpt> teehee, what fun
[10:30] <mdke_> ;?
[10:30] <mdke_> I get an oops when setting the Initial Bug Contact in the ubuntu-doc product too
[10:30] <mpt> https://launchpad.net/distros/ubuntu/+source/ubuntu-docs/+bugs
[10:30] <mdke_> OOPS-20A197
[10:31] <mpt> report a bug, https://launchpad.net/products/malone/+bugs
[10:31] <mdke_> ok
[10:31] <mpt> what, there's no Initial Bug Contact link at the package page
[10:31] <mpt> this sucks
[10:31] <mdke_> could it be https://launchpad.net/distros/ubuntu/+source/ubuntu-docs/+subscribe ?
[10:32] <mpt> yyyyes
[10:32] <mpt> so why does it have different text
[10:32] <mdke_> boh
[10:32] <mpt> ok, report that as a bug too
[10:32] <mpt> it hurts my brain
[10:33] <mdke_> ok the oops is bug 29181
[10:33] <Ubugtu> Malone bug 29181: "Can't change Initial Bug Contact for product/ubuntu-doc" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29181
[10:34] <mpt> you also release docs in Kubuntu, though, right?
[10:34] <mpt> and in Edubuntu?
[10:35] <mdke_> different docs
[10:35] <mdke_> oh yeah, sometimes the same ones too
[10:36] <mdke_> mpt, lack of Initial Bug Contact is at bug 29182, you might have to clear it up for me, I'm not sure if I understand the problem correctly
[10:36] <Ubugtu> Malone bug 29182: "Can't change the Initial Bug Contact on a source package" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29182
[10:45] <jamesh> OOPS reports rock
[11:22] <jbailey> How do I tweak the list of packages for which malone sends me email?
[11:22] <jbailey> It seems to amount to about half of the packages I was interested in 6 months ago.
[11:23] <jbailey> So, I suspect that at some point a list was compiled, but I'm not sure how to find it or update it.
[11:34] <mpt> jbailey, the person to ask about bug contacts is bradb
[11:34] <mpt> I thought I knew how they worked, but discovered in the past few hours that I don't
[11:39] <jbailey> =)
[11:39] <jbailey> Cool.  I'll catch him when I'm back in his timezone.  Thanks, mpt.
[11:43] <dilys> Merge to devel/launchpad/: [r=spiv]  Fix bug 4838, make it possible to add comments while signing the email with a non-registered (in Launchpad) GPG key. Also fix bug 1014, get rid of BugTaskFactory (r3018: Bjorn Tillenius)
[12:14] <matsubara> good morning!
[12:17] <ddaa> daf: ping
[12:17] <daf> ddaa: pong
[12:18] <ddaa> my optional-branch-title branch on chinstrap is out of date with my work here
[12:18] <ddaa> which is compounded by the fact I have been hit with a nasty bug in recent bzr
[12:19] <ddaa> so, I'm going to try to publish my pending changes today, it make take a little while
[12:19] <ddaa> * it may take
[12:19] <daf> oh, right
[12:19] <daf> I just merged from it
[12:19] <daf> shall I just wait and merge it again later?
[12:20] <ddaa> I think you should wait for the latest stuff before starting to modify it.
[12:21] <ddaa> Merging multiple times should not harm.
[12:21] <daf> ok
[01:15] <daf> cprov: any idea what's going on in bug 6712?
[01:15] <Ubugtu> Malone bug 6712: "Oops when trying to access "Resulting Binaries"" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6712
[01:15] <cprov> daf: I'll look
[01:15] <daf> ta
[01:16] <daf> ddaa: any luck at unwedging bzr?
[01:16] <ddaa> not really
[01:16] <ddaa> making some progress though
[01:16] <daf> cool
[01:17] <ddaa> never had to do bzr unwedging before...
[01:17] <ddaa> it's a good thing and a bad thing
[01:17] <ddaa> it's a good thing because it does not happen often
[01:17] <ddaa> it's a bad thing because I do not know what to do...
[01:17] <daf> yeah
[01:26] <cprov> daf: uhm .. 6712 is a dup of 6635, which is fixed in my branch, will update the bug comment/status
[01:29] <daf> cprov: great, thanks
[01:30] <cprov> daf: you're welcome. I'd appeciate your further investigation on it, binarypackagerelease API is utterly broken in many senses 
[01:31] <ddaa> the latest fetcher optimisations are fantastic (well, once you have the bugfix...) that makes bzr pull i/o bound most of the time!
[01:31] <daf> cprov: heh :)
[01:32] <daf> ddaa: oooh, nice
[01:32] <ddaa> if I were you, I'd wait until 0.7... or at least until j-a-meinel bugfix gets audited and merged
[01:32] <cprov> daf: Hope "heh" means:  "Yes, I'll help you on this" ;)
[01:33] <daf> cprov: sure, as long as you don't let me forget about it
[01:33] <daf> cprov: maybe we should open a bug
[01:35] <cprov> daf: feel free to do it, but believe, we won't forget this bug, it's so annoying, it brakes soyuz magic 
[01:35] <carlos> see you later
[01:35] <daf> cprov: ok -- maybe I'll be doing some Soyuz hacking next week
[01:36] <cprov> daf:  good to know
[01:36] <kiko> hey guys
[01:36] <kiko> how's it going
[01:37] <daf> querytastic
[01:41] <daf> kiko: you should paste your query traceback hack to the list
[01:44] <kiko> daf, it is such a hack :-)
[01:44] <daf> yeah, but it's not like it's going to get merged
[01:44] <daf> and it was really useful for optimising malone
[01:45] <kiko> it could actually be added as a special flag
[01:45] <kiko> but la la la I did not say that
[01:45] <kiko> matsubara, do you have a passport in so carlos?
[01:46] <daf> file a wishlist bug on having a proper query traceback flag
[01:46] <daf> we can use the hack in the meantime
[01:46] <matsubara> kiko: yep, but it's expired
[01:47] <kiko> matsubara, that's fine. can you get me photocopies by tomorrow?
[01:48] <matsubara> kiko: yep.
[01:59] <kiko> cprov, how's it going? I have a little bit more email and then I am free, want to come down?
[01:59] <cprov> kiko: yes, I'm overriding binaries atm
[02:00] <kiko> jamesh, are you around?
[02:13] <SteveA> stub: hello
[02:14] <SteveA> stub: next week, i want to polish up kiko's launchpad celebs improvements.  what i plan to do is...
[02:15] <SteveA>  1. on first use of a celeb that is "fixed" (like the admin team) I'll remember its id.  When full crowd stuff lands, that will mean that no further queries will be needed for security/team lookups.
[02:15] <SteveA>  2. on first use in a transaction/request that needs more than the id, I'll cache the object
[02:15] <SteveA>  in a thread local launchbag like thing
[02:16] <SteveA>  3. caches are cleared at transaction/request boundaries
[02:16] <kiko> SteveA, get the fuck off IRC dude. it's VACATION.
[02:16] <kiko> jesus christ
[02:17] <SteveA> kiko: gotta do something while waiting for my hair to dry ;-)
[02:17] <ddaa> daf: haha, looks like just pulling with the fixed code does it... now running "bzr check" to be sure it's sane. It should take a few hours.
[02:17] <kiko> SteveA, fox-hunting?
[02:17] <SteveA> campden market is calling me
[02:18] <stub> SteveA: yo
[02:18] <ddaa> daf: i.e. the branch will prolly not be uploaded today... 
[02:20] <SteveA> it is surprising that sqlobject isn't cacheing the celebs, though
[02:20] <SteveA> at least, through a single transaction
[02:20] <SteveA> so i guess i'll look into that too
[02:28] <bradb> SteveA: You need poker dude.
[02:34] <SteveA> i'm outta here!
[02:38] <bradb> Damn, my newer Powerbook is making noises
[02:39] <bradb> whoa, hard drive might be dying
[02:42] <ddaa> kiko: review Kamion's patch?
[02:45] <kiko> ddaa, me?
[02:46] <ddaa> I'm not an appointed reviewer
[02:46] <kiko> ddaa, I bless you with the power of reviewing kamion's patch.
[02:47] <ddaa> rs=kiko? r=ddaa?
[02:47] <kiko> sure.
[02:47] <kiko> both
[02:47] <ddaa> ack
[03:28] <seb128> connection refused on launchpad.net ... known issue?
[03:28] <kiko> nope.
[03:28] <seb128> does it work for oyu?
[03:28] <seb128> you
[03:28] <kiko> nope.
[03:28] <seb128> k
[03:28] <seb128> thanks for looking at it :)
[03:28] <kiko> it appears to be as dead as elvis
[03:28] <mdke> here too
[03:29] <seb128> kiko: yeah, but the king was cool at least :p
[03:29] <mdke> launchpad is cool too
[03:30] <kiko> seb128, just WAIT until I see you in person
[03:30] <seb128> kiko: coming to the distro sprint? :)
[03:30] <kiko> I will be there the week before
[03:31] <seb128> ah, so with some luck we will not meet this time, good for me :)
[03:31] <kiko> if soyuz crashes and burns I may be in london forever though
[03:31] <seb128> ah ah
[03:31] <Nafallo> kiko: arrange traps and stuff... "home alone 666" or something :-)
[03:33] <kiko> launchpad is back
[03:36] <seb128> kiko: thank you for the quick fixing :)
[03:36] <kiko> Znarl is de man
[03:38] <Mez> how often does launchpad import package details?
[03:38] <ddaa> kiko: I sent a merge request to pqm yesterday, and nothing seems to have happened... so I sent it again a few hours ago, and now the second one is in the queue (suggesting that the first one was indeed received), but still nothing happens.
[03:39] <siretart> lp gone again?
[03:39] <ddaa> it's a cscvs merge request, it's not supposed to take forever to push...
[03:41] <ddaa> It's weird, I seem to be typing "-h" or "help" after every other command I type...
[03:41] <ddaa> mostly bzr ones
[03:41] <ddaa> persistent freudian slip?
[03:42] <ddaa> and weird things like "bzr log | help"
[04:17] <kiko> can anyone access shipit.ubuntu.com?
[04:19] <seb128> "Error establishing an encrypted connection to shipit.ubuntu.com. Error Code: -12195."
[04:19] <Znarl> seb128 : What browser?
[04:19] <kiko> same for me in firefox.
[04:20] <lfittl> kiko: works for me (also firefox)
[04:21] <kiko> Kinnison, was sftp://chinstrap/home/warthogs/archives/dsilvers/launchpad/buildd-fixes  landed?
[04:21] <kiko> it's unfortunate that it doesn't work consistently.
[04:22] <Znarl> kiko : Does https://lists.ubuntu.com work for you?
[04:22] <seb128> Znarl: epiphany-browser
[04:22] <seb128> lists.ubuntu.com works fine
[04:22] <poningru> sorry to disturb, anyone know when launchpad will be freed
[04:22] <kiko> Znarl, yes.
[04:23] <Znarl> kiko : Can you try again now?
[04:24] <Kinnison> kiko: Some of those patches were merged into the branch cprov took before xmas, the others I have a fresh branch I'm preparing for merging
[04:24] <Kinnison> kiko: I can probably set that branch pushing actually
[04:26] <Kinnison> Yep, I can push the updates
[04:26] <kiko> Znarl, sweet, it works.
[04:27] <kiko> what did you change? 
[04:27] <kiko> Kinnison, great.
[04:27] <kiko> Kinnison, should cprov merge it in or.. ?
[04:27] <Kinnison> kiko: Naah, I can get it to pqm
[04:27] <Kinnison> kiko: I just wanna do a test-merge against head now that pqm is updating chinstrap so I can be sure it won't testfail
[04:28] <kiko> sure.
[04:28] <Znarl> kiko : I turned off some extra openssl checks on the server.
[04:28] <kiko> Znarl, okay, cool.
[04:28] <Kinnison> kiko: everything set for your flights?
[04:28] <Znarl> I believe, once the images and css load from shipit I can turn them back on again.
[04:28] <kiko> salgado-lunch, do you have an ETA for fixing up the shipit dependencies on www.ubuntu.com?
[04:29] <kiko> Znarl, sure.
[04:29] <kiko> Kinnison, yes, we fly out sunday at 23:30
[04:30] <kiko> arrive in london at 13:00 so will be around and ready at, say 16:00
[04:30] <Kinnison> kiko: so, one last suicide bike-ride before you fly?
[04:30] <Kinnison> kiko: I'll aim to arrive around 13:00 too, then we all be ready at the same time
[04:31] <kiko> yes, one 110km ride tomorrow
[04:31] <kiko> great.
[04:33] <kiko> ddaa, great work on kamion's branch
[04:33] <kiko> ddaa, I see only one request now in pqm -- what do you think?
[04:33] <ddaa> love thy patch submitters
[04:34] <ddaa> I think yesterday request is still being processed
[04:34] <kiko> hmmm
[04:34] <kiko> no pqm mail to you yet?
[04:34] <ddaa> nope
[04:35] <ddaa> I also decided that pqm just crossed my threshold for "unbearably painful hoop to jump through"
[04:36] <kiko> you are lucky.
[04:36] <ddaa> no, I have a very high threshold
[04:37] <ddaa> I agree with all the theory about automated unit testing and such
[04:37] <ddaa> it's great
[04:37] <ddaa> and I'm willing to accept a LARGE amount of pain to put it in practice.
[04:42] <kiko> PQM causes so much pain it makes you glow in the dark
[04:43] <ddaa> to be fair, much of the pain is related to test suite breakage
[04:43] <ddaa> but it's compounded by
[04:43] <ddaa> * lack of early feedback, and nearly useless monitoring facility
[04:44] <ddaa> * no resilience to test suite breakage
[04:44] <ddaa> both items have been known forever
[04:44] <ddaa> in particular the second one has a specced fix
[04:45] <ddaa> did I miss something about why it's still up in the air?
[04:46] <kiko> bug 2732
[04:46] <Ubugtu> Malone bug 2732: "Adding a poll with a finish date before start date causes error" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Gabriel Neuman, Status: Confirmed http://launchpad.net/bugs/2732
[04:47] <ddaa> is that pqm-related???
[04:48] <kiko> it was me asking for a hint because gneuman doesn't give me enough information
[04:52] <kiko> ddaa, by the way, did you review the patch I sent you to fix add bazaar branch?
[04:52] <kiko> I think I lost the message
[04:52] <ddaa> hu... I looked at it quickly, noticed a few things to comment on, then forgot about it
[04:53] <ddaa> I flagged in the mail client too, but I did not get any round tuits to go over flagged messages...
[04:53] <kiko> dude I did that patch just to cheer you up
[04:53] <kiko> and now you tell me this
[04:53] <kiko> @#!@$!
[04:53] <ddaa> thanks to giving optional-branch-title away, I should be able to do that RSN.
[04:53] <kiko> well
[04:53] <kiko> thanks
[04:54] <ddaa> Thank you for spreading my load.
[04:55] <ddaa> sorry, I'm bad at multitasking...
[04:58] <ddaa> kiko: it's really important for me to review patches, but that thing landed on my lap while I was scrambling to do spread the baz2bzr load...
[04:58] <ddaa> that was really an "every minute counts" situation.
[05:32] <kiko> hey I'm not complaining just nagging
[05:40] <kiko> ddaa, is there any user we can use to indicate THIS PRODUCT IS ORPHANED STEAL IT FOR YOURSELF?
[05:44] <ddaa> I guess we could rename "Registry Administrators" to "Orphaned, mail me and I'll give it to you"
[05:45] <poningru> have to ask again
[05:45] <poningru> anyone know if/when launchpad et al will be freed?
[05:46] <kiko> poningru, sorry, I was out for lunch
[05:46] <kiko> there is commitment from canonical to open source launchpad
[05:46] <kiko> there is, however, no date specified yet.
[05:47] <ddaa> Or maybe we could actually make a patch that displays something like "This product was registered by the Registry Adminstrators. If you are related to this project and willing acquire this Launchpad product, and all the nice stuff we've put into it for you, please send a mail at admins@launchpad.net."
[05:47] <poningru> if you can link me to the literature?
[05:47] <ddaa> in the page body when the owner in Registry Administrators.
[05:47] <ddaa> The phrasing and positioning would have to go through mpt, though.
[05:47] <kiko> poningru, I am not sure it has ever been put in writing, but mdz might.
[05:47] <kiko> hey ddaa 
[05:47] <kiko> why are registry admins being subscribed to bugs?
[05:48] <ddaa> Hu
[05:48] <mdz> kiko: unfortunately I don't
[05:48] <ddaa> To continue the previous question, a user _cannot_ take an Registry Admins product for himself. He needs to ask an admin.
[05:49] <poningru> hmm
[05:49] <poningru> mdz: any idea at all when that might happen?
[05:49] <poningru> like post dapper?
[05:49] <mdz> ddaa: the problem, if it hasn't been articulated yet, is that members of Registry Administrators are getting spammed with bug mail
[05:50] <mdz> poningru: I don't have a written reference to give you, so I can't make any commitment
[05:50] <poningru> k
[05:50] <ddaa> mh... I guess my spam filter is being _too_ effective then...
[05:51] <ddaa> Mh... I'm not a Registry Admin?
[05:51] <mdz> ddaa: 29191, 28757, 29173 for example
[05:52] <kiko> are product owners subscribed by default to their bugs, bradb?
[05:53] <ddaa> I notice that bob2 is a registry admin...
[05:53] <bradb> kiko: Only if there's no bug contact.
[05:53] <ddaa> That looks odd to me, should he be made inactive?
[05:54] <kiko> ddaa, sure.
[05:54] <kiko> bradb, I see.
[05:55] <kiko> bradb, I wonder if that's correct for the case of the registry admins.
[05:55] <kiko> okay, ddaa, mdz: I have an idea.
[05:55] <kiko> create a hotmail account for the registry admins
[05:55] <kiko> add that as the registry admins team email
[05:55] <kiko> validate the email
[05:55] <kiko> live happily ever after
[05:55] <ddaa> hu
[05:56] <kiko> seriously, we could probably create an orphaned-products list or something
[05:56] <ddaa> sounds like a not too good idea
[05:56] <ddaa> kiko: yes, that's the list of products owned by registry :)
[05:56] <ddaa> so we have it already
[05:57] <kiko> a mailing list ddaa 
[05:58] <ddaa> what does that buy us compared to the existing situation?
[05:58] <ddaa> easier mail sorting for registry members?
[05:58] <kiko> mdz doesn't get spammed
[05:58] <kiko> he can just not be subscribed to the list
[05:59] <kiko> we should probably add a X-Launchpad-To: header perhaps
[05:59] <ddaa> out of curiosity, why does mdz need to be a registry member?
[05:59] <mdz> that would be a workaround
[05:59] <kiko> because he is the CTO
[05:59] <mdz> don't I need to be a registry admin in order to fix up product registrations?
[05:59] <kiko> yes
[06:00] <kiko> BjornT, remind me why process-mail crashed in the regexp issue, for the LP report?
[06:00] <mdz> but anyway, Mark must be getting spammed with this too
[06:00] <mdz> and jordi
[06:00] <ddaa> So, what puzzles me
[06:01] <mdz> I would say that the registry administrators should never be the point of contact for a product
[06:01] <mdz> that will always be wrong
[06:01] <ddaa> is "why is registry subscribed to bugs, and what should we do with those bugs, anyway"?
[06:02] <ddaa> mdz: exactly what I mean.
[06:02] <kiko> ddaa, the first is: because there is no bug contact.
[06:02] <kiko> the second is: probably put it in a mailing list that other people care about?
[06:02] <kiko> or just /dev/null them
[06:02] <ddaa> bzzzzzzt
[06:02] <ddaa> about dev/nulling...
[06:03] <mdz> the registrant of a product (the person who registered it in launchpad, right?) is often not a valid point of contact for the product
[06:03] <mdz> that is the general issue
[06:03] <mdz> people other than the upstream themselves register products
[06:03] <mdz> and we encourage this
[06:03] <ddaa> I think that's a bit different. When somebody registers a product, he takes reponsibility for it.
[06:04] <ddaa> OTOH 'registry' is just synonymous for Nobody as far as bug responsibility is concerned.
[06:05] <ddaa> I believe it should not be possible _at all_ to create a bugtaks for a product that's owned by registry.
[06:06] <kiko> that's interesting.
[06:06] <kiko> BjornT?
[06:06] <kiko> bradb?
[06:06] <bradb> kiko: What's your question?
[06:07] <BjornT> kiko: the mime message boundary in an email was used in a regexp, but i didn't take into account that the boundary could contain characters like + and so on, which have meaning in a regexp.
[06:07] <ddaa> If somebody is willing to be the upstream contact, he can just take ownership of the product, that's also a person that will know about things like "upstream RCS moved" or telling about bounties, or uploading translations, etc.
[06:07] <kiko> bradb, see discussion above, culminating in
 I believe it should not be possible _at all_ to create a bugtaks for a product that's owned by registry.
[06:08] <bradb> That depends.
[06:09] <bradb> If we want to link to external bugs for that product, we need to be able to create bugtasks on it.
[06:09] <mdz> ddaa: I think it should be possible to register a product without taking responsibility for it, just for the sake of organizing the data
[06:10] <mdz> there is nothing special about Registry Administrators
[06:10] <mdz> they just happen to register products
[06:10] <ddaa> mdz: yeah, I was taking the "product owner responsibility" thing to it's logical end
[06:10] <ddaa> and I see that it turns out to be a pretty big thing
[06:10] <salgado> kiko, I didn't know I had to fix that... maybe you're telling me now and asking for an ETA?
[06:11] <ddaa> But I do not have a good answer to this problem...
[06:11] <kiko> salgado, I discussed it on IRC before but you forget ;)
[06:12] <salgado> really? that's a bad sign
[06:12] <salgado> I'll fix it now, then
[06:12] <kiko> cool
[06:12] <kiko> it will be nice to have a padlock there
[06:13] <mdz> it's also a problem that I can't unsubscribe registry administrators from these bugs
[06:13] <ddaa> mdz: offhand idea... what about explicit activation of the various services for a product: bugs tracker, support, translations, rcs imports (not branch registration!), so somebody could create a product for e.g. an associated package w/o becoming the de-facto upstream contact for bugs and stuff?
[06:14] <mdz> ddaa: the thing is, we use products for representing status upstream even if upstream doesn't use launchpad
[06:14] <ddaa> hu
[06:14] <mdz> so there is no contact on the product, but e.g. we use it in malone to record that the bug is forwarded upstream and add a bug watch
[06:14] <mdz> https://launchpad.net/products/libwnck/+bug/28757
[06:14] <Ubugtu> Malone bug 28757: "taskbar blinking never stops" Fix req. for: libwnck (upstream), Severity: Normal, Assigned to: Sebastien Bacher, Status: Unconfirmed
[06:15] <ddaa> you mean existence of an upstream bugtask may mean any of "not a packaging bug", "we told upstream about it" and "somebody got confused and filed a bug there"?
[06:16] <ddaa> or, of course "upstream is actually using malone"
[06:18] <ddaa> annoying cat still has food
[06:18] <ddaa> mdz: I think I got confused about this issue... That or it's an big nasty can of worms...
[06:18] <bradb> I've been doing other things instead of following this discussion in detail, but from the Malone perspective, I think that: 1. You shouldn't be able to file new bugs on products that aren't using Malone as their official bug tracker, but 2. you should be able to open bugtasks *linked to external bug reports* for products that aren't officially using Malone.
[06:18] <kiko> any resolution in sight?
[06:18] <kiko> right
[06:19] <kiko> BjornT, can you take that into account in your bugwatch work?
[06:19] <ddaa> bradb: that sounds sane
[06:20] <bradb> And on that note, I need food.
[06:22] <BjornT> kiko: yes, that's more or less what i was thinking as well. i'll send an email about it on monday.
[06:23] <ddaa> mdz: I think the only way to represent "created a product to organize data" ATM is to get it assigned to registry...
[06:24] <kiko> BjornT, wonderful.
[06:24] <ddaa> that will speccing to actually figure out something less broken...
[06:24] <ddaa> * that will require speccing
[06:26] <salgado> kiko, ~salgado/shipit.diff
[06:27] <kiko> salgado, does it work?
[06:28] <salgado> sure it does
[06:28] <kiko> does firefox list anything suspicious in the page info dialog?
[06:28] <kiko> r=kiko
[06:28] <elmo> haha, "does it work?" "sure" "reviewed!"
[06:30] <salgado> this is called agile software development. :p
[06:31] <Kinnison> Oh for fucks sake
[06:31] <Kinnison> bzr has eaten my branch
[06:31] <kiko> I looked at the patch, fwiw
[06:31] <kiko> it's just a big fat copy and paste job
[06:31] <salgado> kiko, nothing suspicious, but you can check http://shipit.async.com.br/
[06:31] <kiko> are you using a recent version, Kinnison?
[06:32] <ddaa> Kinnison:  you are using mpool's branch, or the 0.7 prerelease right?
[06:32] <kiko> salgado, good thing I tested. you forgot the images
[06:32] <ddaa> If that's true, I've got one bad news and one good
[06:33] <ddaa> the bad news is: your branch is wedged, but I think you can repair it by pulling it into another branch using... the good news: j-a-meinel's 0.7-bugfixes has a fix.
[06:34] <kiko> salgado?
[06:35] <salgado> I'm checking what are the images that we use. seems to be only the header one
[06:37] <salgado> kiko, only header-bg4.png and header-image4.png, AFAICT
[06:37] <Kinnison> ddaa: mpool's branch
[06:37] <Kinnison> ddaa: where's jam's branch?
[06:37] <Kinnison> ddaa: the issue I'm seeing is my inventory missing a bunch of revisions apparently
[06:37] <ddaa> http://bzr.arbash-meinel.com/branches/bzr/0.7-bugfix/
[06:38] <ddaa> will conflict
[06:38] <Kinnison> how badly?
[06:38] <kiko> salgado, I think only two ones
[06:38] <ddaa> I have no investigated, too busy, I use jam's branch ATM.
[06:38] <Kinnison> Right, I'll see
[06:42] <Kinnison> otherwise 'bzr resolved' won't work
[06:43] <salgado> kiko, check shipit.async.com.br again
[06:50] <Kinnison> ciau
[06:50] <Kinnison> kiko: have a good bike ride, and I'll see you on Monday. ciau
[06:58] <kiko> salgado, r=kiko
[06:59] <ddaa> kiko: do you want me to comment on the patch, or to take it and finishit?
[07:01] <kiko> ddaa, comment is fine, it's very simple work
[07:11] <jordi> nooooooooooooooooooooooooooooooooo
[07:11] <jordi> This makes me climb up the wall
[07:11] <jordi> NO NO NO
[07:11] <jordi> I fucked up an import again
[07:11] <jordi> I hate this 
[07:12] <jordi> carlos: gah, I imported German zwiki-plone to zwiki by mistake. How do we recover from these?
[07:13] <carlos> jordi, if it's no longer on the queue, you cannot recover from that. Other than import the German zwiki file to override any change on common strings
[07:14] <carlos> seems like I will need to add a big red 'STOP import' buttons to prevent this errors to happen again...
[07:21] <jordi> carlos: as I told you last week, thre's lots of rooms for human fuckups here.
[07:21] <jordi> After you've done like 20 zwiki files, it was just too easy to mess it up
[07:21] <kiko> jordi, you are calling yourself human now. how quaint.
[07:22] <jordi> carlos: how hard would it be to implement the "for all the selected files, approve them straight away without going to edit, basing on the file name"?
[07:22] <carlos> jordi, use firefox autocompletation...
[07:22] <carlos> :-P
[07:22] <jordi> carlos: that would be very important for me
[07:22] <jordi> my productivity is like 20% now :/
[07:22] <jordi> kiko: heh
[07:23] <carlos> jordi, how often are we getting new import requests?
[07:25] <jordi> carlos: the queue is flooded and it's proving quite difficult to keep it under control. Sometimes it's very easy to have a debconf template translation disguised as a program translation. The queue info doesn't tell me any hint, unless I download the file and have ae look
[07:26] <jordi> when I do that it takes like 3 misn for every entry
[07:26] <jordi> and there's a lot
[07:26] <carlos> right
[07:26] <carlos> that's a bug
[07:26] <jordi> there are other submissions that are unknown stuff, and need to be investigated and so on
[07:26] <carlos> we should show the potemplate that people selected when did the upload
[07:26] <jordi> I ust uploaded a pkg-exim4 translation
[07:27] <jordi> I spotted it because I know you don't translate exim4, so it had to be debconf
[07:27] <carlos> jordi, I need that you file bugs for those problems to be able to priorize them and implement the most critical ones....
[07:28] <jordi> yes
[07:28] <jordi> I'm swamped
[07:28] <jordi> sometimes I don't know if mailing lists, the queue or filing bugs is more important
[07:32] <jordi> sigh, I'm going to have a stormy night with the gf as soon as she appears. I think she's upset about something, and I am too. :)
[07:32] <jordi> that can't help either
[07:34] <jordi> https://launchpad.net/products/exe1
[07:34] <jordi> I present you with the Bazaar branch "0.12, Merry Santa release" :P
[07:38] <bradb> jordi: We all know how stormy nights with gf's end...
[07:38] <bradb> Normally very well.
[07:38] <jordi> bradb: haha
[07:38] <jordi> let's cross fingers. :)
[07:38] <bradb> heh
[07:49] <jordi> carlos: Ive asked this two times already, sorry :)
[07:50] <jordi> carlos: John translates v 0.1 into Portuguese in rosetta. Version 0.2 gets imported, and it has a translation coming from the tarball, done by Tommy. Who's translation wins?
[07:51] <jordi> This is a product translation
[07:51] <jordi> not a distro
[07:52] <carlos> jordi, if you upload it as published
[07:52] <carlos> jordi, the ones from v0.1 have preference over 0.2
[07:52] <carlos> jordi, if you don't upload them as published, 0.2
[07:54] <jordi> carlos: but I guess the owner uploaded a tarball with all the files
[07:54] <jordi> that's a published upload, right?
[07:54] <jordi> it wasn't a single file upload
[07:56] <carlos> jordi, right
[07:56] <jordi> carlos: uh, wouldn't it be the other way round?
[07:57] <carlos> jordi, no
[07:57] <jordi> 19:52 < carlos> jordi, if you upload it as published the ones from v0.1 have preference over 0.2
[07:57] <carlos> jordi, the translator is the only one that should change translations
[07:57] <carlos> jordi, the maintainer should not change translations with tarball uploads
[07:57] <jordi> what if there was another translator working outside the rosetta process, and had updates in the tarball?
[07:57] <carlos> jordi, they will appear as suggestions
[07:57] <jordi> I see.
[07:57] <jordi> makes sense, somehow
[07:58] <carlos> that's the idea ;-)
[07:59] <jordi> koke: ping
[07:59] <jordi> koke: you uploaded GNOME Torrent
[07:59] <jordi> koke: do you know the upstream author?
[08:00] <koke> jordi: I didn't upload it
[08:00] <koke> but I'm the author :P
[08:00] <koke> ah, ok uploaded to launchpad
[08:00] <koke> yes, I did
[08:02] <jordi> you're the author? didn't know.
[08:02] <jordi> cool :)
[08:02] <jordi> 19:59 <sm> so if a project uses rosetta, it should only accept translations made via rosetta ?
[08:02] <jordi> carlos: ^
[08:02] <jordi> carlos: that's probably something that will annoy many people
[08:04] <jordi> ok, he got it
[08:05] <koke> jordi: anything more for me? have to go
[08:06] <jordi> koke: nope, it's in
[08:16] <jordi> carlos: can I import a po file as a pot file?
[08:16] <carlos> jordi, that's not true
[08:16] <jordi> someone imported what appears to be at emplate with a .po filename
[08:16] <carlos> jordi, just import it as not published
[08:16] <carlos> and it's like a web translation
[08:16] <jordi> how do I do that?
[08:16] <carlos> hmmm
[08:16] <jordi> https://launchpad.net/products/libswitch/+series/stable-0
[08:16] <jordi> err
[08:16] <carlos> for the .po like a .pot file...
[08:16] <jordi> sorry
[08:16] <jordi> https://launchpad.net/rosetta/imports/284
[08:17] <carlos> I think it should work, but I'm not sure now if I already implemented it....
[08:17] <carlos> jordi, try leaving the language field empty
[08:17] <jordi> lets see
[08:18] <carlos> That's 'no value'
[08:18] <carlos> jordi, and pry
[08:18] <jordi> heh
[08:18] <jordi> let's see what happened
[08:18] <carlos> s/pry/pray/
[08:19] <carlos> jordi, I need to implement tests for that but with our current system I think we get it for free...
[08:22] <jordi> carlos: it worked
[08:22] <jordi> https://launchpad.net/products/libswitch/+series/stable-0/+pots/libswitch
[08:22] <carlos> jordi, ;-)
[08:22] <carlos> jordi, now I must add a test so it always work
[08:22] <carlos> jordi, In fact, I think that if you have only a valid .po file
[08:23] <carlos> and import it without any .pot imported
[08:23] <carlos> it's imported twice
[08:23] <carlos> one as a .pot file and another one as a .po file
[08:23] <jordi> as pot and as po?
[08:23] <jordi> cool
[08:23] <carlos> but that's a hack :-P
[08:23] <carlos> and I cannot promise you that it works
[08:26] <jordi> heh
[08:29] <jordi> enough for today
[08:29] <jordi> I've imported most of the series requests
[08:29] <jordi> I'll do ubuntu stuff tomorrow
[08:29] <jordi> now bradb, wish me luck :P
[08:29] <jordi> laters
[08:32] <bradb> heh, good luck :)
[08:51] <salgado> cprov, around?
[08:51] <cprov> salgado: yup
[08:53] <salgado> cprov, I miss some docstrings for the example code in the MM spec (specially for the guessSources(), guessBinaries(),  mirror.desiredPrefferedProbes and mirror.updateContentModel() methods)
[08:53] <salgado> without them it's very hard to find out how the probing is performed
[08:54] <cprov> salgado: so do I ;) didn't have time to write them propely, was personal code originally
[08:54] <cprov> salgado: will look somepoint today, exactly now, i can't, DF is burning :(
[08:54] <salgado> that's okay, no worries. :)
[09:02] <cprov> salgado: just got it right now, do you mean the "virtual" code included in the spec, not the example code urlProber.. Sorry I missunderstood it. uhm about the code i can't do much more than it's already there, maybe we can talk personally later today about that.
[09:05] <salgado> cprov, yes, it was about that code included in the spec.
[09:07] <salgado> cprov, let's talk either tomorrow then, I need to go now
[09:09] <kiko> jordi?
[09:09] <kiko> cprov, should we try and fix the uploader issues meanwhile?
[09:10] <kiko> jordi...
[09:10] <kiko> why does he always leave
[09:10] <cprov> kiko: I don't have any idea how to fix those reamining issueswould be worth to have dsilvers beside us 
[09:11] <cprov> kiko: they are only 3, and indeed are corner cases 
[09:11] <cprov> kiko: I'm working a a FULL and EFECTIVE binary override list 
[09:12] <kiko> cprov, okay. but I think I can fix the remaining issues with you
[09:13] <cprov> kiko: there is also a more import issue to be sorted (IMO) that is to figure out why it's not publishing arch independent pkgs properly
[09:14] <kiko> well
[09:14] <kiko> why don't you come down and we fix those issues?
[09:14] <kiko> I think kiko and cprov are a good team for patching up archivepublisher/* :)
[09:15] <cprov> kiko: "patching up" doesn't cope with the current code state, you know 
[09:16] <kiko> well
[09:16] <kiko> in our case patching up means basically making the code less ugly than it is today
[09:24] <lifeless> refactor!
[09:25] <kiko> lifeless, without tests? sure.
[09:25] <lifeless> kiko: ah, not refactoring then.
[09:25] <lifeless> write tests! then refactor!
[09:25] <kiko> lifeless, and deploy said tested refactored code.. monday?
[09:26] <lifeless> kiko: depends on the size of the refactorings needed. But mainly I'm teasing cause its 0730 on sat morning
[09:26] <lifeless> and I can
[09:31] <kiko> I know it's teasing
[09:31] <kiko> but I wish I could do what you wanted
[09:31] <lifeless> If I had a few more cycles I'd ofer to help
[09:31] <lifeless> strangely I enjoy sorting out that sort of thing
[11:23] <pvdvyve> Hi
[11:27] <kiko> till tomorrow guys