[12:21] <bradb> SteveA: yeah, it's not really important enough to bug stub, IMHO
[03:13] <elmo> bradb: how do you delete attachments in malone?
[04:05] <jamesh> spiv: ping?
[04:05] <spiv> jamesh: pong
[04:05] <spiv> I'm just starting skype :)
[04:17] <bradb> elmo: attachments can't be deleted, unfortunately. bug 48771.
[04:17] <Ubugtu> Malone bug 48771 in malone "It should be possible to delete attachments" [Normal,Unconfirmed]  http://launchpad.net/bugs/48771
[05:27] <BenC> what might be the problem with an attachment in malone that isn't hyperlinked (meaning it shows it, but there's no way to get it)
[05:28] <BenC> I can privmsg the bug url to a dev, but not in channel (private bug)
[05:44] <bradb> BenC: are you saying that attachment title isn't hyperlinked in the bug attachments portlet on the RHS?
[05:44] <bradb> s/that/the/
[05:45] <bradb> BenC: you can privmsg me the url if you don't mind first sub'ing me to the bug report so i can view it
[06:23] <BenC> sorry, I had to leave
[06:30] <stub> bradb: The attachment isn't hyperlinked because elmo requested I remove the file.
[06:31] <stub> (If there is a bug here, it is that we need a (deleted) flag or something when rendering expired or deleted librarian files)
[07:13] <stub> Launchpad will be going down in 20 minutes for its regular code update. Estimated down time is 10 minutes.
[09:09] <SteveA> morning
[09:18] <SteveA> stub: hello
[09:55] <sivang> morning all
[10:03] <SteveA> hi sivan
[10:06] <stub> SteveA: Hi
[10:08] <carlos> stub: where you able to do the production update?
[10:08] <stub> carlos: Yes, as per the mailing list email and wiki page updates.
[10:09] <carlos> hmm, I didn't see the mail in the mailing list
[10:09] <carlos> stub: ok, thanks!
[10:09] <SteveA> carlos: subscribe to the production status wiki page
[10:09] <carlos> yeah, good idea...
[10:10] <carlos> BjornT: hi, around?
[10:11] <BjornT> hi carlos 
[10:12] <carlos> BjornT: would you have time today to have a skype call about the desing of https://launchpad.net/products/rosetta/+bug/44214 ?
[10:13] <carlos> salgado told me that he's a bit busy but that would try to do it if you are not available
[10:14] <stub> BjornT: Did you send me a reminder email telling me about something important to do after rollout? If so, I've lost it ;)
[10:14] <stub> Ahh... found it.
[10:14] <SteveA> carlos: i updated the description of bug 44214 to say "bug 41653" rather than "#41653"
[10:14] <SteveA> the latter isn't auto-linked
[10:14] <SteveA> i wonder if it should be
[10:15] <carlos> SteveA: ok, thanks
[10:15] <stub> Should be - I tend to use that form ;)
[10:15] <sivang> hey stub , SteveA , carlos 
[10:15] <SteveA> someone who cares should file a bug then :-)
[10:15] <carlos> sivang: hi!
[10:16] <SteveA> i think it is a bit permissive to autolink on #1234
[10:16] <SteveA> because that means  "number 1234"
[10:16] <stub> Oh... not just that. That would suck.
[10:16] <SteveA> do we number anything else?
[10:16] <BjornT> carlos: sure. maybe in an hour?
[10:16] <stub> Bug #1234
[10:16] <SteveA> that will work
[10:16] <carlos> BjornT: ok
[10:16] <carlos> 09:15 UTC ?
[10:16] <BjornT> yeah, that'll be fine
[10:17] <carlos> BjornT: ok, thanks
[10:31] <mdke> my mail software doesn't allow filtering on reply-to, only sender/subject/recipient. Is there another easy way I can filter bugmail?
[10:34] <SteveA> not really.  what is your mail software?
[10:42] <mdke> SteveA: I dunno, it is what is provided by the control panel on the hosting I have. I will learn procmail and see if I can use that
[11:03] <lifeless> spiv: does os.listdir use readdir ?
[11:10] <Kinnison> BjornT: Do products not have the same subscribe/unsubscribe as packages for bugs?
[11:12] <BjornT> Kinnison: not quite. a package can have any number of bug contacts, while a product can have only one.
[11:13] <Kinnison> Mmm, this kinda sucks
[11:13] <Kinnison> Was there a reason for not adding it to products too, or was it just never asked for?
[11:14] <BjornT> i'm not sure why it was done this way, you have to ask bradb about it.
[11:15] <Kinnison> Okay, thanks
[11:19] <siretart> is launchpad able to mirror 'knit' branches?
[11:20] <Kinnison> spiv: ^^^
[11:21] <carlos> BjornT: meeting time?
[11:21] <carlos> BjornT: if you need more time, feel free to delay it
[11:21] <Kinnison> carlos: So are we ready to open edgy as far as rosetta is concerned?
[11:22] <carlos> Kinnison: yeah, from the UI part, we are ready. The translations imports can be handled later
[11:22] <BjornT> carlos: i'm ready. what's your skype handle?
[11:22] <carlos> carlospm_1
[11:22] <Kinnison> carlos: right
[11:46] <Keybuk> how often are archives mirrored from sftp to http (bazaar.lp.net)
[11:56] <glatzor> Keybuk: once a day - I think
[12:07] <mdz> kiko: awake?
[12:13] <Kinnison> mdz: Judging by previous days I'd say we're not due kiko for between 1h and 2h
[12:14] <mdz> I wouldn't be surprised if he showed up early to prepare for opening edgy
[12:14] <Kinnison> That's a good point
[12:17] <SteveA> kiko mentioned 1200 UTC to me last night
[12:17] <Kinnison> So in 1h45m ?
[12:17] <SteveA> yes
[12:27] <tortho> FYI: Since we didn't find any good answers to it, and it has been discussed here before, From the norwegian translators: Bug #48799:
[02:00] <spiv> lifeless: yes, os.listdir on posix uses readdir
[02:00] <spiv> siretart, Kinnison: launchpad should be able to mirror knit branches as of the rollout earlier today.
[02:02] <Kinnison> Cool
[02:04] <Keybuk> Is ddaa at the London sprint?
[02:08] <lifeless> yes
[02:09] <Keybuk> can be be summoned briefly
[02:12] <spiv> Keybuk, ddaa: https://launchpad.net/products/launchpad-bazaar/+bug/48813
[02:18] <lifeless> Keybuk: summoned
[02:18] <cprov> stub: ping
[02:18] <stub> cprov: pong
[02:18] <lifeless> Keybuk: actually, hes rather focusde. can I realy ?
[02:18] <lifeless> s/realy/relay
[02:19] <cprov> stub: do we have a production DB backup for today (open edgy task) ?
[02:20] <stub> There is one running right now... and the last one was...
[02:20] <stub> Around 01:00 UTC
[02:20] <Keybuk> lifeless: would like a vague answer as to whether that bug is possible to fix quickly or not
[02:21] <lifeless> yes, I thought there was one already open. If spiv has time to do the relevant hack - we've discussed it already - then it should be fine. Spiv can you chat with SteveA about timing for this ?
[02:21] <cprov> stub: uhm the 01AM would be enough
[02:21] <lifeless> we should not poll all hosted branches everytime.
[02:21] <kiko> morning!
[02:22] <lifeless> we have machinery to set an arbitrary interval already.
[02:22] <kiko> hello cprov 
[02:22] <kiko> hello stub 
[02:22] <kiko> hello mdz
[02:22] <stub> kiko: 'ello
[02:22] <stub> Whee... more lightening
[02:23] <stub> If I disappear, the power has gone out ;)
[02:23] <kiko> how's it going out east?
[02:23] <cprov> kiko: hello
[02:23] <stub> Getting into the cool thunderstorm season. Great view from up here ;)
[02:24] <lifeless> ack after lunch
[02:29] <kiko> cprov, so are we waiting for a backup to push the button?
[02:32] <cprov> kiko: kind of, we have the 1AM one, but since stub has started another one, let's wait it to finish
[02:33] <cprov> kiko: I'm sorting archive backup with Kinnison
[02:33] <kiko> all right. coolio
[02:33] <stub> Its done
[02:36] <kiko> rockon
[02:36] <kiko> spiv, ping?
[02:36] <spiv> kiko: pong
[02:37] <spiv> lifeless: sure, I'll do that.
[02:38] <kiko> spiv!
[02:38] <spiv> kiko!
[02:38] <spiv> What's up? :)
[02:38] <kiko> spiv, on a scale from 1-10, how likely am I to get an email about this dotted prejoin business? :)
[02:39] <spiv> How long are you prepared to wait? ;)
[02:39] <spiv> I'll take a look now.
[02:42] <kiko> thanks!
[02:48] <kiko> spiv, I have improved the tests and they guarantee sanity! yay!
[03:27] <bradb> Kinnison: In retrospect, it may have been a mistake to allow only one bug contact for product/distro, because it would seem to make it very hard for non-core-team users to follow bug activity, in many cases.
[03:28] <bradb> Kinnison: what product do you want to be a bug contact for? i'm curious to see its configuration.
[03:30] <spiv> kiko: sent
[03:33] <kiko> spiv, is it good news or bad news?
[03:34] <spiv> kiko: good, I hope.  I have a suggestion about _prejoinOne that I hope you like.
[03:37] <kiko> spiv, I have factored cache.clear() and the assert == 0s into a function, which avoids some of the repetition and makes clear that yes the repetition was accidental :-/
[03:38] <kiko> spiv, your suggestion is excellent but I will need to butcher the entire method to do it, and you want me to stop straying from upstream. should I do it anyway, or should I limit its impact?
[03:39] <spiv> You could limit it to just dealing with the prejoin bits.
[03:39] <spiv> I think I'd lean towards limiting it, but I'm not sure.
[03:40] <spiv> I guess it depends on how much cleaner it would be if you butchered the entire method.
[03:40] <spiv> If it was sufficiently beautiful, perhaps rewriting changes made in upstream to use our newer code wouldn't be so painful.
[03:41] <kiko> spiv, I'll consider that carefully then
[03:41] <spiv> Or perhaps it would be horribly difficult... but wasn't his function originally fairly simple before we added this prejoin business?
[03:41] <spiv> s/his/this/
[03:41] <kiko> I can't remember
[03:41] <kiko> spiv, however, your suggestion is somewhat limited by the fact that it doesn't take into account the fact that current_class and current_table need to mutate
[03:41] <spiv> Like 15 lines or something that suddenly turned into 100.
[03:42] <kiko> but perhaps I can supply them to addPrejoin()
[03:42] <spiv> kiko: They'd be state on the queryBuilder object.
[03:42] <kiko> hmmm
[03:42] <kiko> I think that'd be bad
[03:42] <kiko> well, unless we /did/ limit its use
[03:42] <spiv> Hmm, perhaps.
[03:42] <kiko> because you always want to reset back to the original class
[03:42] <spiv> Ah, right.
[03:42] <kiko> but I think we can manage well enough in the loop
[03:42] <spiv> Yeah, when I wrote that sketch I was just thinking of the limited problem.
[03:43] <kiko> so I'll take that into consideration. when working on SO I always find it hard to balance between rewriting the goddamned thing and doing what I need to do
[03:43] <spiv> It was a bit of a "this proof is left as an exercise for the reader" kind of review ;)
[03:43] <spiv> Yeah.
[03:44] <kiko> heh
[03:44] <kiko> okay I'll improve it
[03:44] <spiv> I'd lean towards the path of spending less effort.
[03:44] <kiko> but apparently testing it on LP has shown a bug in it! I am fascinated
[03:45] <spiv> I'm really happy to see that prejoin code somewhat factored out of that function, btw.  It was getting crazy...
[03:46] <kiko> I just discovered I need to normalize the prejoins
[03:46] <kiko> because if you do
[03:46] <kiko>             prejoins=["potemplate", "language", "latestsubmission",
[03:46] <kiko>                       "potemplate.sourcepackagename",
[03:46] <kiko>                       "latestsubmission.person"] ,
[03:47] <kiko> then it fucks up by joining twice on latestsubmission and potemplate
[03:47] <spiv> Whee!
[03:47] <kiko> hmmm
[03:47] <kiko> that idea about the QueryBuilder
[03:48] <kiko> it is pure genius :)
[03:48] <kiko> hmmmm
[03:48] <spiv> What about ["foo.owner", "bar.owner"] , i.e. two different dotted prejoins onto Person, did you have a test for that already?
[03:49] <kiko> no, haven't tested that either
[03:49] <kiko> should work as long as the renaming works though
[03:49] <spiv> Oh, crazy idea: use sqlobject's sqlbuilder ;)
[03:49] <spiv> Yeah, I agree it *should*... can't hurt to be sure we didn't miss something :)
[03:49] <Kinnison> bradb: launchpad-publisher
[03:53] <kiko> oh-oh
[03:53] <kiko> spiv, https://chinstrap.ubuntu.com/~dsilvers/paste/fileTekw4O.html
[03:55] <spiv> I think my eyes are bleeding.
[03:56] <kiko> stub, do you know how we should reformat https://chinstrap.ubuntu.com/~dsilvers/paste/fileTekw4O.html to actually work?
[03:56] <kiko> spiv, I think I hit a speedbump
[03:57] <kiko> it appears that we can't mix inner and outer joins?
[04:02] <spiv> kiko: maybe we need to use parens?
[04:02] <kiko> spiv, can you explain further? you mean subqueries?
[04:03] <cprov> salgado: ping
[04:03] <spiv> "A JOIN clause combines two FROM items. Use parentheses if necessary to determine the order of nesting. In the absence of parentheses, JOINs nest left-to-right."
[04:04] <salgado> cprov, pong
[04:04] <cprov> salgado: do you have any idea about how mirror stuff will get affected by open edgy ?
[04:04] <lifeless> Keybuk: I am here now
[04:05] <salgado> cprov, it's designed to Just Work
[04:05] <salgado> cprov, but we'll see if that happens in practice after edgy opens
[04:07] <cprov> salgado: perfect, dude, thank you. keep your eyes on it and let me know if the procedure to open edgy can do something to help you in this land
[04:08] <stub> salgado: How often should it be running? I think it is currently scheduled to run daily.
[04:08] <salgado> cprov, thanks for asking, but I think all we can do is wait until the mirrors start mirroring edgy
[04:09] <cprov> salgado: right, let's watch it 
[04:10] <salgado> stub, I think daily should be okay for now. maybe later we can make it run more often
[04:13] <mdz> morning
[04:14] <cprov> mdz: morning, publishing edgy
[04:16] <cprov> mdz: when can you come around to __sign___ the archive results ?
[04:17] <mdz> cprov: sign?
[04:17] <cprov> mdz: check 
[04:18] <mdz> cprov: I'm here now
[04:19] <Kinnison> Publisher is almost finished
[04:19] <cprov> mdz: then check archive in drecher, if you can  
[04:20] <mdz> cprov: did you make a hardlink backup I can compare against?
[04:20] <Kinnison> Yes I did
[04:21] <Kinnison> in .../ubuntu-archive-backup
[04:22] <bradb> Kinnison: Interesting (re: launchpad-publisher) team. Is it an option for you to set up a team for this product? Then add mdz, you, etc.? Then you could all get email about it (no need for a mailing list.)
[04:22] <Kinnison> A team would do, but then individuals couldn't unsub from bugs
[04:23] <bradb> Kinnison: Indeed, though that bug remains even if more than one person can be a product bug contact.
[04:23] <Kinnison> bradb: I thought the bug contact could unsubscribe if they wanted
[04:23] <Kinnison> bradb: I want the same sort of behaviour as package subscriptions
[04:24] <Kinnison> mdz: It's ready for checking
[04:24] <Kinnison> s'just removing dists.old
[04:24] <mdz> cprov: edgy is missing the Task extraoverrides
[04:24] <bradb> Kinnison: You can't unsubscribe from package bugs anymore either. Package contact subscriptions are now looked up at bugmail delivery time, not "explicitly" created at filebug time.
[04:24] <Kinnison> mdz: Right, cron.germinate probably hasn't built them yet
[04:24] <mdz> cprov: and main/*installer*
[04:25] <Kinnison> mdz: yep, those need copying in, I knew that and I'm not sure how we should automate it in the future
[04:25] <cprov> mdz: uhm ..
[04:25] <bradb> Kinnison: maybe ping me later to discuss this further when you're less busy?
[04:25] <Kinnison> bradb: sure, that'd be cool
[04:26] <bradb> thanks
[04:26] <Kinnison> mdz: Germinate running
[04:27] <Kamion> Kinnison: you need to change cron.germinate to say suite=edgy
[04:27] <Kamion> at the moment it's working on dapper
[04:27] <Kinnison> Kamion: poo
[04:27] <Kinnison> Kamion: thanks
[04:29] <Kamion> Contents needs to be copied in too
[04:29] <mdz> the dist-upgrader stuff is missing too, though perhaps that's not a bug
[04:29] <Kamion> unless that'll get rebuilt automaticaly
[04:29] <Kamion> +k
[04:29] <Kamion> damn, +l. I'll stop now.
[04:31] <mdz> Kamion: I think it's uploaded pre-built
[04:32] <Kamion> I meant Contents
[04:32] <Kinnison> Contents will be copied and/or generated soon
[04:41] <Kinnison> mdz: Right, I'm ready to re-run the publisher to see if the germinate did the right thing
[04:41] <Kinnison> running
[04:42] <Kamion> oh, er, wonder what it'll have done with xubuntu seeds
[04:42] <kiko> please mind the gap
[04:43] <Kamion> xubuntu seeds will be b0rken
[04:43] <Kamion> sorry about that, I can fix it, give me a minute
[04:44] <Kinnison> Kamion: it's already running, but it won't reach the override generation phase for a few minutes
[04:44] <Kinnison> Kamion: not that cron.germinate would run in time
[04:45] <Kamion> I can't pull from jani until the SM gets round to pulling the seeds, but that's ok, I just branched xubuntu-dapper to xubuntu-edgy
[04:46] <Kamion> ... however, it seems to have worked anyway, I guess it reused the old dapper files when germinate failed
[04:46] <Kamion> so we're actually ok
[04:47] <cprov> salgado: don't we use a field validator for email addresses yet ? 
[04:47] <cprov> salgado: instead of simple TextLine. Do you think it's worth to have ?
[04:48] <cprov> salgado: i know that we have high-level validation for that, but right no I need to map an address that isn't stored in EmailAddress table
[04:50] <salgado> cprov, the interface for IEmailAddress.email is bogus. IIRC, all forms that expect an email address do the validation manually
[04:51] <salgado> so, yes, a custom field for email addresses would probably be a good idea, but we'd also need to switch some pages to use GeneralFormView
[04:51] <cprov> salgado: uhm, what do you think about writing a EmailAddress field validator ? would you also use it in FOAF ?
[04:53] <salgado> yes, it'd be useful, definitely
[04:53] <kiko> spiv, I am completely and absolutely fucked.
[04:53] <kiko> I will need to produce a query ordering thingifier
[04:53] <salgado> cprov, but I don't see why do you want it
[04:53] <cprov> salgado: yes, maybe fixing the callsites will be overkill, but at least we can reuse it for new forms, which would use GFV anyway, thanks for the oppinion, I will write it 
[04:54] <cprov> salgado: DistroRelease.changeslist tweak via distrorelease/+admin
[04:55] <salgado> cprov, but aren't you going to need to create a special schema in order to have an emailaddress field on that page?
[04:55] <cprov> salgado: don't know if we can model it using EmailAddress, it doesn't need hig level validation 
[04:55] <stub> kiko: Sounds like you have been belting at SQLObject with a hammer to keep the rusty old thing running and it finally exploded.
[04:55] <salgado> cprov, I don't see what you mean
[04:56] <BjornT> anyone up for a trivial review?
[04:56] <cprov> salgado: I mean validation cycle compared with what we have for personal email addresses
[04:57] <kiko> stub, I appreciate your support
[04:57] <kiko> a query ordering thingamajingifier
[04:58] <stub> heh... I just noticed on that my web host provider has switched to Ubuntu ;)
[04:58] <cprov> salgado: don't know if we have plans to model maillistings in LP and how we would do it. the point is we can't simply check "user@url"
[04:59] <stub> cprov, salgado: http://www.stuartbishop.net/Software/EmailAddress/index.html will do the validation heavy lifting
[04:59] <stub> (I think(
[04:59] <stub> )
[05:00] <salgado> cprov, what other checks do we need to do?
[05:00] <cprov> stub: you rock ! do you think we can create a field validator based on it ?
[05:01] <cprov> salgado: that's the point, right now, we can't do anything to certify it's a real maillisting and people are listening it
[05:02] <stub> cprov: It might be strict enough. If not, it would be a start.
[05:02] <cprov> salgado: even checking user@host we mail be sending email to an non-existent maillisting
[05:03] <salgado> cprov, but checking that a given email is for an existing mailing list involves at least sending one email and receiving a response, doesn't it?
[05:03] <stub> We can't confirm that the address is deliverable though without sending an email and catching bounces, and we can't confirm that anyone actually monitors that mailbox and it is not a spam honeypot or anything
[05:03] <salgado> this sounds like you need a LoginToken-style workflow
[05:04] <salgado> like the one we do to add new email addresses for people/teams
[05:04] <cprov> however, I'll continue with the field validator, it's an admin page, people will take care, later we can thing in a login-token extension
[05:04] <salgado> what is your field validator going to do, exactly?
[05:04] <cprov> salgado: yes, we may think about this at somepoint 
[05:05] <cprov> salgado: just check if the email address sintaxe is correct
[05:06] <salgado> well, AFAIK, the rules for inserting an email address in the database are pretty strict. I'm not sure if the fact that it's inserted using an admin interface is enough for us to alleviate these rules
[05:06] <cprov> salgado: stub's code looks sane for doing this
[05:06] <cprov> salgado: you're right, it's not, but anyway it's not in EA table yet ;)
[05:07] <salgado> eh? that email address will go in a separate table?
[05:07] <cprov> salgado: and current EA is only refered by Person table
[05:08] <matsubara> cprov: fwiw, we've been using validators/email.py for simple syntax checking
[05:08] <cprov> salgado: yes, I told you the text field, IDistroRelease.changeslist
[05:09] <hub> how do I unsubscribe from a bug I am notified because of dupliactes...
[05:09] <salgado> cprov, that doesn't mean much. I thought it'd be a reference to the EmailAddress table
[05:09] <hub> I get spammed several times a day and this is driving me nuts
[05:09] <salgado> but it looks like it's a text column?
[05:10] <cprov> salgado: yes, it still being a text field, which I pointed as an unreliable wy to solve the problem ;)
[05:11] <bradb> hub: You can't, atm, unfortunately. Just curious, why are you interested in being subscribed to the duplicate, but not to the dupe target?
[05:11] <salgado> cprov, well, if that's the case then all you need to do is to specify a constraint on IDistroRelease.changeslist's definition
[05:11] <cprov> salgado: uhm .. we already have that validator, I forgot about it, it's used in logintoken
[05:12] <hub> bradb: I don't even know what the duplicate is, and I think I got subscribed to the duplicate because I'm upstream on the package where the bug orignally is reported in
[05:12] <carlos> hub: hmm, you would need to wait for bradb to answer you, but I just tried unsubscribing me from the duplicate bug and seems like I'm still subscribed, so seems like the fact that you cannot subscribe it's a bug
[05:12] <ajmitch> bradb: a bug may be marked duplicate later on
[05:12] <cprov> salgado: Text(..,constraint=valid_email,...) should work
[05:12] <carlos> oh, bradb already answered ;-)
[05:12] <hub> bradb:  that bug https://launchpad.net/distros/ubuntu/+source/libgnomeprint/+bug/34112
[05:12] <Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  
[05:12] <hub> bradb: I'm in "also notified"
[05:12] <Kinnison> mdz: Cleaning up the old dists, Do you want to take a quick look?
[05:12] <hub> and can't remove myself
[05:13] <carlos> bradb: I guess we should be removed from it when we remove our subscription to the duplicated bug
[05:13] <hub> no
[05:13] <hub> we should be able to get unotified on that bug too
[05:13] <hub> this bug as something like 20 dupes
[05:14] <hub> and I don't know which one is mine
[05:14] <bradb> indeed, there are too many to look through
[05:14] <carlos> hub: it makes no sense to be unsubscribed from the main bug and stay subscribed to the duplicate one. The duplicate one should not get any activity
[05:14] <Kinnison> mdz: Once you're happy we can turn things on again :-)
[05:14] <carlos> hub: oh, I see your point
[05:14] <hub> carlos: it makes no sense to not not be able to unsubscribe from anyuthing
[05:15] <carlos> hub: sorry, I misunderstood you
[05:15] <hub> carlos: I call that SPAM
[05:15] <hub> carlos: in fact it is easier for me to hunt down a LP developer than to hunt down the duplicate on that one
[05:15] <hub> bradb: fear, I'm only 2 hours away 
[05:15] <hub> :-)
[05:15] <hub> bradb: I know where you live :-)
[05:16] <bradb> heh
[05:16] <bradb> hub: I can see why this is causing you, and others, grief. I'll need some time to think about how to address it.
[05:16] <carlos> hub: yeah, I didn't get your point, I thought you wanted to stay subscribed to the duplicated one
[05:16] <hub> ok
[05:16] <hub> bradb: bonus point: provide a direct link in the message "unsubscribe from this"
[05:17] <hub> bradb: with a way that it does not get caught by spamassassin
[05:17] <hub> bradb: just for the hacking value :-)
[05:17] <hub> then I'll owe you beer
[05:17] <bradb> yeah, that's a nice idea
[05:17] <Kamion> Kinnison: xubuntu-desktop tasks did end up wrong in the end
[05:17] <bradb> can you file a bug about being able to unsub from the "also notified" list?
[05:18] <bradb> hub ^^
[05:18] <hub> okay then
[05:18] <bradb> thanks
[05:18] <hub> and then I'll get spammed again ;-)
[05:18] <Kamion> Kinnison: I have a feeling they've ended up as copies of corresponding edubuntu-* tasks
[05:18] <Kamion> I'm pretty sure that'll get cleaned up automatically next cron.germinate/cron.daily runs though
[05:18] <Kinnison> cool
[05:18] <Kamion> I'd understand if mdz wanted to make sure though
[05:19] <Kamion> the rest of diff -ru dists/{dapper,edgy} looks ok to me
[05:20] <hub> what distribution or whatever shoudl I use?
[05:20] <bradb> hub: https://launchpad.net/products/malone/+filebug
[05:20] <Kamion> hub: /products/malone
[05:20] <hub> there is no launchpad / malone
[05:20] <hub> great
[05:20] <mdz> Kinnison: looking
[05:21] <Kinnison> mdz: thanks
[05:21] <mdz> Kamion: btw, ~kiko/bin/compare-archives is the latest version of the somewhat smarter comparison tool
[05:22] <hub> https://launchpad.net/products/malone/+bug/48862
[05:22] <Ubugtu> Malone bug 48862 in malone "Can not unsubscribe from a bug when "Also Notified"" [Untriaged,Unconfirmed]  
[05:22] <mdz> Kinnison: all of the old Release.gpg have been re-signed (hoary, etc.)
[05:22] <hub> no offense guys, but UI-wise, I give a good D
[05:22] <hub> to not give a F
[05:23] <bradb> hub: No offense taken, and bug reports welcome.
[05:23] <kiko> spiv, stub: SUCCESS!
[05:23] <kiko> YES!
[05:23] <hub> bradb: well, I have a few weeks of filing
[05:24] <hub> then
[05:24] <Kinnison> mdz: very odd
[05:25] <hub> bradb: and I'm currenly busy with *paid* work
[05:25] <bradb> hub: I understand fully. Just noting that it's much more likely that the specific issues you encounter will be fixed if you or somebody else reports them.
[05:26] <hub> I know that
[05:26] <hub> that's why I filed to bugs, but at the same time I found 4 more to file
[05:26] <Kamion> mdz: kewl
[05:26] <hub> so I don't really want an exponential progression of bugs to file
[05:27] <bradb> Maybe one day soon Launchpad can have an Edgy style development process. :)
[05:27] <Kinnison> mdz: Is it causing an issue?
[05:28] <mdz> Kinnison: I haven't checked the signatures, but have no reason to believe so
[05:28] <Kamion> somewhat smarter but a hell of a lot slower. urk.
[05:30] <mdz> Kamion: longer runtime, less time reviewing the output :-)
[05:31] <kiko> hah
[05:31] <kiko> HAH!
[05:32] <hub> bradb: maybe
[05:32] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/fileuUCO5b.html
[05:32] <kiko> I KILL YOU
[05:32] <hub> bradb: since I don't know python, I'll be useless
[05:32] <kiko> stub, how horrible is that query going to be?
[05:32] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/fileuUCO5b.html
[05:33] <Kinnison> mdz: D'you want us to turn on the pipeline then?
[05:33] <mdz> Kinnison: is there anything in the queue?
[05:33] <mdz> would be nice to run a test upload through it
[05:33] <Kamion> the queue is staying disabled until glibc/gcc land anyway, I'm tol
[05:33] <Kamion> told
[05:33] <Kamion> we could run something non-C through
[05:34] <Kinnison> We can run a source through
[05:34] <Kinnison> there're no chroots
[05:34] <Kinnison> Until infinity supplies us with chroots we're not turning binaries on
[05:34] <Kinnison> (his request)
[05:35] <mdz> Kinnison: how about a trivial upload of a package which is modified in ubuntu anyway?
[05:35] <mdz> er, hmm
[05:36] <mdz> if there are no chroots, we can neither test nor do useful work
[05:36] <mdz> why delay that?
[05:36] <Kamion> Keybuk/jbailey want to start building the world with the new toolchain
[05:37] <Kinnison> The delay is, afaict, jbailey owes infinity a new glibc
[05:37] <mdz> Kinnison: but we'll need to build that
[05:37] <Keybuk> Kamion: waiting on a new libc from jbailey to test on my i386
[05:37] <Keybuk> and then we need new gcc and gcj from doko
[05:38] <Keybuk> and then we need infinity to be awake to make chroots and feed the buildds some hamsters
[05:38] <mdz> Kinnison: I don't see the point in rolling this out without creating chroots...what will happen with uploads? source will be published and just never built?
[05:38] <Kinnison> indeed
[05:38] <Kinnison> once the chroots turn up the builds will happen
[05:38] <Keybuk> mdz: we've turned off the upload processor
[05:39] <mdz> Keybuk: but we want to turn that back on
[05:39] <Keybuk> no, we don't
[05:39] <Keybuk> otherwise somebody will start uploading crap to edgy
[05:39] <Keybuk> and then we'll have to have all of it rebuilt again once the new toolchain is in
[05:39] <mdz> Keybuk: no builds will happen
[05:40] <mdz> Kinnison: so all you're asking is whether to re-enable pushing to the mirrors?
[05:40] <Keybuk> true, but this way the buildds don't need to be on manual or anything
[05:40] <mdz> Kinnison: if so, sure
[05:40] <Kamion> infinity will have to be very careful about sucking from the firehose if the whole queue comes back on
[05:40] <stub> kiko: You appear to be joining POTemplate about three times with exactly the same criteria.
[05:41] <stub> kiko: If we are going to start to join more than 6 tables I'm going to need to tweak some PostgreSQL config to keep the query optimizer working well.
[05:41] <Keybuk> scary gnome people were talking about starting the war-uploader
[05:41] <Kinnison> Right, so I'll turn cron.daily back on, but not the buildd sequencer or the upload processor
[05:42] <Kinnison> Okay cron.daily and cron.germinate are reenabled
[05:42] <Keybuk> we can re-enable the security upload processor, right?
[05:43] <Kinnison> Umm, *ponder*
[05:43] <Kinnison> Should be able to, yes
[05:43] <kiko> stub, well, the POTemplate duplication is a bug
[05:44] <Keybuk> ok
[05:47] <Kinnison> Keybuk: security queue is alive
[06:03] <Kinnison> stub: any chance that the statistician will run soon?
[06:04] <kiko> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/file62ZUoL.html
[06:04] <kiko> stub, look better now?
[06:05] <Kinnison> stub: otherwise LP claims edgy is empty
[06:08] <salgado> stub, I just commented on https://launchpad.net/products/shipit/+bug/5812/ explaining what I discussed with SteveA yesterday. can you check if that's okay?
[06:13] <kiko> stub's in high demand
[06:14] <Keybuk> stub: does my bum look big in this?
[06:15] <stub> Kinnison: It will kick in tomorrow I think. You need it run earlier?
[06:16] <Kinnison> stub: ideally, currently LP thinks edgy is empty
[06:16] <Kinnison> stub: which makes for bad looking /distros/ubuntu/edgy
[06:16] <stub> kiko: There is still a spurious POTemplate join in there.
[06:18] <stub> FROM POTemplate, POFile JOIN POTemplate AS _prejoin0 ON _prejoin0.id = POFile.potemplate ... WHERE ... AND POfile.potemplate = POTemplate.id
[06:19] <carlos> stub: do you think this restriction makes sense?: 'posubmission_can_be_selected' UNIQUE, btree (pomsgset, pluralform, id)
[06:19] <carlos> I think it makes no sense at all, the id is going to be unique anyway...
[06:20] <carlos> sorry, forget what I said
[06:20] <stub> Kinnison: Running now
[06:20] <Kinnison> stub: thanks
[06:24] <Keybuk> I'd guess it means taht the PO submission can be selected
[06:48] <stub> carlos: it is required so another table can refer to those columns using a foreign key
[06:49] <carlos> stub: Oh, I see
[07:12] <Keybuk> where did the stuff in dapper-updates go?
[07:12] <Keybuk> is that copied into edgy?
[07:12] <Keybuk> or is edgy == dapper ?
[07:13] <Kinnison> The decision made in conjunction with some distro team members was that when initialising a new release, you only copy the release pocket, not -updates or -security
[07:13] <Keybuk> right
[07:14] <Keybuk> what's proposed, btw?
[07:14] <Keybuk> that's a new pocket to me
[07:14] <Kinnison> proposed-updates
[07:14] <Kinnison> the idea being you could put stuff in there, and then if they are okay they could migrate to -updates
[07:18] <fabbione> Kinnison: 
[07:18] <Keybuk> so it's not related to UNAPPROVED ?
[07:18] <fabbione> dists/edgy/main/daily-installer-amd64/20051026ubuntu13.0.20060124/
[07:18] <fabbione> is it expected?
[07:18] <Kinnison> yes, we copied daily-installer and installer in from dapper
[07:19] <Kinnison> Keybuk: no, UNAPPROVED is a queue state, not a pocket
[07:19] <Keybuk> right
[07:19] <Keybuk> I'm curious as to the process
[07:19] <Keybuk> it is intended to be like backports, and a free-for-all update zone?
[07:20] <Kinnison> It's a sabdfl idea
[07:20] <Kinnison> ask him
[07:20] <kiko> well, there must be some rationale behind it you understand Kinnison?
[07:22] <Kinnison> The sab explained it to me a while ago and I must confess I don't remember the rationale other than as a staging area because -updates was in the apt config and -proposed-updates wouldn't be
[07:22] <kiko> I guess that's reasonable enough
[07:22] <Kinnison> He'll be able to better explain it
[07:26] <fabbione> Kinnison: out of curiosity, why?
[07:26] <fabbione> (the copy of the installer)
[07:27] <fabbione> (that also triggered a pulse in the dapper/ dirs)
[07:29] <sabdfl> staging area is a good description
[07:30] <sabdfl> so, a sysadmin has three sane options
[07:30] <sabdfl>  - enable -security only (very stable, only security updates)
[07:30] <sabdfl>  - leave it as -security and -updates (should be stable, some new bits, and security)
[07:30] <sabdfl>  - enable all of -security, -updates,  -proposed-updates (get new up and coming fixes, perhaps for internal testing)
[07:31] <salgado> BjornT, around?
[07:35] <BjornT> hi salgado 
[07:36] <salgado> BjornT, have you seen https://chinstrap.ubuntu.com/~dsilvers/paste/fileSELAtI.html before?
[07:36] <salgado> I'm getting that when running a new-style pagetest, and I think it's because the page I'm trying to print the contents of contains non-ascii characters
[07:39] <BjornT> salgado: yeah, i think so to. i guess you should either not print the contents, or convert the contents to ascii, replacing non-ascii characters with something.
[07:41] <salgado> well, in this specific case the problem is that the content is not what the test expects, and then zope is printing it for me
[07:41] <salgado> so, I don't see how I could do what you suggest
[07:42] <BjornT> ah, right
[07:42] <Kinnison> fabbione: we copied the dirs to edgy because it seemed like the right thing to do
[07:44] <BjornT> salgado: well, you could use '"foo" in browser.contents', or you could use something like BeautifulSoup to extract the parts your interested in.
[07:45] <SteveA> doing a match like:  "<h1> whatever </h1>" in fuzzy_htmlmatch(browser.contents)   would be cool
[07:45] <salgado> hmmm. is it impossible to fix this in zope?
[07:45] <SteveA> and having this as a standard thing in pagetests
[07:46] <BjornT> salgado: it's in python, not in zope
[07:46] <salgado> BjornT, because when it fails, I'd like to have browser.contents printed so that I can see what went wrong
[07:47] <salgado> well, I was thinking of catching that exception and then smashing the non-ascii characters or something like that
[07:48] <salgado> (doing that in zope/testing/doctest.py, I mean)
[07:51] <SteveA> salgado: encode using the error handling strategy that replace unencodable chars as ? 
[07:54] <BjornT> salgado: changing zope/testing/doctest.py should probably be avoided, since that's basically a copy the doctest module in python. i think encoding the content yourself is the best option for now
[08:04] <salgado> so, that would be "browser.contents.encode('ascii', 'replace')"?
[08:06] <BjornT> yeah
[08:06] <salgado> shouldn't browser.contents be a unicode object?
[08:06] <salgado> (Pdb) type(browser.contents)
[08:06] <salgado> <type 'str'>
[08:07] <SteveA> i guess not.  a bytestream is what gets served up
[08:07] <BjornT> ah, then that won't work. not sure what it's meant to be.
[08:07] <SteveA> there shoud/could be a method getUnicodeContents()
[08:08] <SteveA> that would use the encoding header of the page
[08:08] <salgado> exactly. that's why the contents.encode('ascii') won't work
[08:08] <SteveA> if there is one
[08:08] <SteveA> but meanwhile, you can write a function to do that
[08:08] <SteveA> and re-encode it as ascii
[08:09] <BjornT> according to the interface (IBrowser) it should be a unicode string, though.
[08:09] <salgado> aha!
[08:21] <salgado> so, we'll have to do this for every page that (with our sampledata) can contain non-ascii characters?
[08:40] <carlos> hmm
[08:40] <carlos> SteveA, kiko: Would be possible to get bzr updated in asuka? (I still don't know if we should ask those things directly to admins or ask you first)
[08:41] <fabbione> Kinnison: imho it's kind of pointless :) dapper installer can't install edgy :) you might as well wait for the first edgy installer upload ;)
[08:41] <carlos> we have there 0.7pre
[08:41] <carlos> so it's useless with the knits branches
[08:42] <kiko> carlos, I think so, yes -- I'd write to stub,lifeless CC: launchpad and if so I'd request rt@admins
[08:43] <carlos> kiko: ok, thanks
[09:03] <SteveA> just go to RT
[09:03] <SteveA> stub has asked about this before
[09:03] <SteveA> there may even be an RT issue on it
[09:05] <SteveA> nope, not in rt
[09:05] <SteveA> carlos: please send in an RT request, r=me
[09:06] <carlos> SteveA: ok
[09:19] <Keybuk> can somebody confirm that the sftp->http bazaar.lp.net mirror happened today?
[09:24] <sivang> hmm, any reason why I wouldn't have .bzr dir after installing bzr from dapper?
[09:25] <Keybuk> why would you expect a .bzr dir?
[09:26] <sivang> Well, it alaways had been before I reinstalled dapper and reinstalled bzr ;-)
[09:26] <sivang> and I would create .bazaar manually, as per the RocketFuelSetup document
[09:27] <sivang> (before, that is)
[09:39] <Keybuk> .bzr is created by "bzr init"
[09:39] <Keybuk> ie. it marks a repository
[09:41] <sivang> ah , right damn my memory. it's created per branch.
[09:41] <sivang> Keybuk: sorry 
[09:47] <Kamion> can somebody just kill off daily-installer-* from edgy please?
[09:48] <Kamion> we have no mechanism to update it since the switch to soyuz, and it's better missing than outdated
[09:48] <Kamion> in fact, I really wouldn't object if it got purged from dapper too
[09:48] <Kamion> I know it's released, but I can guarantee that nobody can actually be using it successfully
[09:49] <Kamion> (it has an incompatible kernel; if you try to boot it it will get to the point where it tries to suck more of itself from the archive and then fall over in a heap)
[09:49] <Kamion> fabbione: no, having the dapper installer there is good, daily-installer is pointless though
[09:49] <Kamion> the dapper installer certainly can install edgy; you might have to preseed stuff but that's about it
[10:01] <sivang> do we have packages for rocketfuel-get and -refesh scripts?
[10:03] <sivang> I have a very small fix to the rocketfuel-refresh script, but I see the RFS wiki page he become immutable (good thinkg to protect the PQM key fingerprint for verification) but if we have packages for that, I could introduct the fix there.
[10:04] <sivang> basically, the change is from 'XPULL=".bzr/parent"' to 'XPULL=".bzr/branch/parent"'
[10:04] <sivang> if someone could change that on the wiki page, that would be great.
[10:54] <cprov> kiko: do you have time for a quick review/talk on fixes for edgy release ? https://chinstrap.ubuntu.com/~dsilvers/paste/fileTK38zd.html
[10:55] <kiko> cprov, for you? always