[12:39] <mpt> thanks sladen
[04:51] <dilys> Merge to<EMAIL_ADDRESS>Cherrypick patch-2345 into rocketfuel (patch-3<EMAIL_ADDRESS><EMAIL_ADDRESS>[06:02] <peloverde> why does launchpad think that gnuradio-examples is an invalid source package name?
[06:04] <spiv> Probably because that package information hasn't been imported into launchpad yet :/
[06:06] <peloverde> It doesn't mind "gnuradio" which isn't the real name, thats what i'm going to file bugs under
[06:07] <peloverde> am i supposed to manually assign to MOTU or anything like that>
[07:09] <stub> Given the byte string 'Invalid value \xff\xfeh\x00e\x00l\x00l\x00o\x00', what would be the simplest way of converting it to 'Invalid value \\xff\\xfeh\\x00e\\x00l\\x00l\\x00o\\x00' (ie. replace unprintable and non-ascii characters with backslash notation)
[07:10] <stub> I got a string in an unknown and possibly invalid character set and I need to spit it out an ASCII stream
[07:10] <spiv> repr('Invalid value \xff\xfeh\x00e\x00l\x00l\x00o\x00') ?
[07:10] <stub> spiv: Nah - that will give be "'Invalid value... '" (ie. an extra set of quotes)
[07:10] <stub> spiv: And I want ASCII strings to pass through unmolested.
[07:11] <spiv> repr(...)[1:-1]  then ;)
[07:11] <spiv> But yeah, it will molest quotes.
[07:12] <spiv> Hmm...
[07:12] <spiv> Use codecs.register_error('backslash', xxx)?
[07:12] <stub> encode('ascii','backslashrepace') doesn't work which sucks... don't know if it supposed to
[07:13] <stub> hmm...
[07:14] <spiv> Although there is already supposed to be backslashreplace
[07:16] <stub>  m.decode('ascii', 'replace').encode('ascii', 'backslashreplace')
[07:16] <stub> That seems to do the trick
[07:16] <stub> Although I end up with Unicode references in there instead in some cases instead of \x notation, but that will be good enough
[07:51] <SteveA> morning!
[07:52] <BjornT> good morning SteveA, up early today? :)
[07:52] <SteveA> earli0ish
[07:52] <SteveA> too early to type properly
[07:53] <stub> yo
[08:00] <stub> I'll put staging back on the daily devel--0 code
[08:01] <stub> (But not the database resyncs until Carlos gives me the nod)
[08:07] <SteveA> surely that will cause a bunch of failures
[08:07] <SteveA> as the database schema will not be in sync with the code
[08:12] <stub> No - the schema will be updated, but the data will not.
[08:12] <SteveA> ok
[08:13] <stub> (procedure is normally sync the database, upgrade the schema and code, restart. Nothing new here, nothing to see, move along ;) )
[08:31] <SteveA> kaip?
[08:31] <SteveA> kaip btent?
[09:27] <sabdfl> hi guys
[09:28] <sabdfl> stub: do you think you could track down the cause of IntegrityError -> ProgrammingError on Breezy?
[09:28] <sabdfl> if you need a breezy login, I can provide one
[09:29] <sabdfl> jamesh: ping
[09:30] <stub> sabdfl: I don't have a spare box to run breezy. I expect it is simply that breezy has a newer version of psycopg.
[09:30] <stub> sabdfl: I would rewrite that test as:
[09:30] <stub> try:
[09:31] <stub>     bad_task = bugtaskset.createTask(...)
[09:31] <stub> except psycopg.DatabaseError:
[09:31] <stub>     print 'A database exeption was raised'
[09:32] <sabdfl> hmmm... we do have a different psycopg package, but it's not the latest upstream
[09:32] <sabdfl> could you investigate that please, and see if we should be syncing in a newer one from debian?
[09:32] <stub> Are you running against 8.0 or 7.4?
[09:33] <stub> (PostgreSQL)
[09:33] <SteveA> sabdfl: i spoke with doko about that
[09:33] <sabdfl> stub: 7.4
[09:33] <SteveA> and i spoke with vdg, the author
[09:33] <SteveA> or rather, doko spoke with him
[09:33] <SteveA> the current version of psycopg is bogus and buggy
[09:34] <sabdfl> ok, so we stick with the current one in breezy
[09:34] <SteveA> vdg is releasing a new version very soon that addresses the regressions / problems
[09:34] <SteveA> but it hasn't reached debian yet
[09:34] <sabdfl> too risky
[09:34] <SteveA> right
[09:34] <SteveA> so, that's the psycopg situation
[09:34] <jamesh> sabdfl: yeah?
[09:34] <SteveA> i think we already have the patches from jamesh
[09:34] <SteveA> in the ubuntu package
[09:34] <sabdfl> jamesh: have you had a chance to look at the spec bits? can we talk about a schedulo-matic?
[09:35] <SteveA> there was one other segfault issue in the changelog i think, that someone else than jamesh found
[09:35] <jamesh> SteveA: all my psycopg patches went into hoary
[09:35] <SteveA> so we might want to get that one patch applied
[09:35] <sabdfl> ok
[09:38] <jamesh> sabdfl: I've had a quick look over the basic data model.  So the idea of the schedulomatic would be to take a collection of specs + subscriptions and try and schedule things?
[09:39] <sabdfl> jamesh: basically
[09:39] <sabdfl> let's hammer over some details by privmsg
[09:39] <jamesh> (and dependencies)
[09:48] <carlos> morning
[09:49] <lifeless> sabdfl: pong
[09:52] <SteveA> lifeless: can i ask pqm to specifically take one changeset and apply that?
[09:53] <SteveA> or, would i need to make a branch that is suitable for star-merging, and reply that changeset onto my branch, and then ask pqm to starmerge that branch?
[09:54] <lifeless> SteveA: you can give it a specific patch and the replay command, but for anything going into mainline, please do not do that.
[09:54] <SteveA> ok
[09:54] <lifeless> SteveA: as it will cause failed merged later.
[09:58] <stub> SteveA: https://shipit.staging.canonical.com/ is running trunk, but isn't working. Also the links that are there point to localhost. Anything to worry about, or is there more stuff to land still?
[10:00] <sabdfl> lifeless: np, was xml question that stevea answered last night
[10:00] <SteveA> what does "isn't working" mean, specifically?
[10:01] <SteveA> hmm, not sure the virtual hosting stuff is working properly
[10:02] <SteveA> stub: we need to check with elmo about the rewrite rules that are being applied.
[10:02] <SteveA> stub: can you look in the logs on staging to see what requests are being sent?
[10:02] <stub> I can probably see the rules on asuka... hang on.
[10:04] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/fileLa64hi.html
[10:05] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/files2aYOr.html
[10:06] <SteveA> that first one looks correct to me
[10:07] <SteveA> it may be just something about the error page is wrong
[10:07] <SteveA> can you get some zope request logs from staging, and grep them for 'shipit' ?
[10:12] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/fileehnppi.html
[10:12] <stub> SteveA: ^^
[10:13] <SteveA> https://staging.canonical.com/ gets me a 502 now
[10:14] <SteveA> so, something is screwed
[10:17] <SteveA> stub: how long are you around for?
[10:17] <stub> I was going to take a break before the meeting - you need me now?
[10:17] <SteveA> well, i want you and elmo to work out why staging is not working
[10:17] <SteveA> i can phone elmo and see when he can do it
[10:18] <stub> shipit is the same as before for me - no 502 there.
[10:18] <stub> (and staging)
[10:18] <SteveA> you get a webpage from staging?
[10:18] <stub> Yes
[10:18] <SteveA> https://staging.canonical.com/
[10:18] <SteveA> from there?
[10:19] <stub> https://staging.ubuntu.com
[10:19] <stub> canonical.com is busted
[10:19] <stub> (no idea if it ever worked...)
[10:19] <SteveA> oh
[10:20] <SteveA> so, i made a mistake asking elmo to put shipit on shipit.staging.canonical.com
[10:21] <SteveA> oh i see an error
[10:21] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/fileLa64hi.html
[10:22] <SteveA> stub: see the RewriteRule -- uses http: but port 443
[10:22] <stub> Oh... yes.
[10:23] <SteveA> i guess that's an admins job?
[10:24] <SteveA> as in, i suspect you have read-only access to those configs
[10:24] <stub> Yup
[10:25] <SteveA> would you mail RT ?
[10:25] <SteveA> what do you think about changing it to shipit.staging.ubuntu.com too?
[10:25] <stub> Doing it now
[10:26] <SteveA> ta
[10:27] <stub> staging should really be staging.launchpad.net, although shipit shold be shipit.staging.ubuntu.com. Or something. Ermm... perhaps we should write all these urls down somewhere so we can make them a bit saner ;)
[11:01] <Kinnison> spiv: ping?
[11:02] <spiv> Kinnison: pong
[11:02] <Kinnison> spiv: I've just put a (very short, very easy) branch in your queue
[11:03] <Kinnison> It's a very small librarian feature which we need for dogfooding the buildd system
[11:03] <spiv> I'll take a look.
[11:03] <Kinnison> lifeless had a very very quick glance over it at breakfast for me
[11:06] <lifeless> I got through 5 lines and stopped.
[11:06] <lifeless> (for clarity)
[11:07] <Kinnison> but there were only 20 lines anyway
[11:19] <spiv> Kinnison: +>>> re.search('^http://NOT\.VALID\.COM/\d+/\d+/text.txt$', url) is not None
[11:19] <spiv> Use raw strings with regexes.
[11:20] <spiv> You're lucky that neither \. or \d has special meaning in current python, but you shouldn't rely on it.
[11:20] <Kinnison> Erm, I *copied* an earlier test
[11:20] <Kinnison> :-)
[11:20] <Kinnison> shall I fix up the earlier tests to use r'' ?
[11:20] <lifeless> spiv: you are bad, it was your test.
[11:20] <lifeless> :)
[11:21] <spiv> Kinnison: Please :)
[11:21] <spiv> lifeless: Don't blame me, blame my reviewer ;)
[11:21] <lifeless> rotfl
[11:22] <spiv> I don't understand why the buildd does simply use a different config?
[11:22] <spiv> s/does/doesn't/
[11:23] <Kinnison> because the buildd master sometimes downloads stuff from the librarian too
[11:24] <Kinnison> we simply need a different URL base when we generate a URL to pass into the restricted slave network
[11:25] <spiv> Which system is "we" here?
[11:26] <cprov> spiv: buildd-slave must access librarian through an internal vh, just it
[11:27] <spiv> cprov: I understand that part.
[11:27] <spiv> The buildd slave gets the URL from the buildd master, doesn't it?
[11:27] <cprov> spiv: so "we" is buildd-slave farm
[11:28] <cprov> spiv: yes, it does
[11:28] <spiv> (I should've been clear that I meant the "we" in "we generate", damn English :)
[11:28] <cprov> spiv: specfically from getURLForAlias()
[11:28] <spiv> So why not just run the buildd master with a different config that has download_url set appropriately?
[11:29] <cprov> spiv: it shoudl probabbly be a lot of config overhead, 50 options for only 1 change.
[11:30] <Kinnison> spiv: Mostly because the buildd master may also download files
[11:30] <Kinnison> spiv: and it needs the appserver download url, not the one presented to the restricted network
[11:30] <cprov> spiv: the only motivation i can see for use another config section is using another DB, which isn't the case.
[11:31] <spiv> Ok, that's what I was looking for -- specifically that the master also needs a download_url that works for it, and at the same time needs to be able to give the slave urls that the slaves can use.
[11:32] <spiv> It still feels a bit odd to me, but it is a small change.
[11:33] <spiv> If you can clarify in a comment/doc somewhere that there needs to be two different download_urls coexisting in the same process, then you have r=spiv.
[11:37] <Kinnison> Should I do that in the schema.xml, the doctest, or the client.py ?
[11:38] <Kinnison> Or in the configs themselves?
[11:39] <spiv> In the schema or the doctest.
[11:39] <spiv> The doctest seems to have the most comprehensive text on the subject so far.
[11:39] <spiv> Although in theory the schema is a better place for it.
[11:39] <spiv> I have a strong gut feeling we'll need to revisit this change, but it's not particularly complex, so I'll just deal :)
[11:50] <Kinnison> okay
[11:50] <Kinnison> I'll put it in both the schema and the doctest
[12:22] <carlos> I think PQM is stalled again...
[12:22] <carlos> lifeless, ?
[12:33] <lifeless> killed nc
[12:34] <Kinnison> hey elmo
[12:36] <dilys> Merge to<EMAIL_ADDRESS>add gpgme_op_trust() wrapper [r=spiv]  (patch-2<EMAIL_ADDRESS><EMAIL_ADDRESS>[12:40] <carlos> lifeless, thanks
[01:16] <SteveA> developers meeting in 25 mins
[01:16] <SteveA>  /msg me items for the agenda
[01:16] <SteveA> spec system and shipit are already on the agenda
[01:17] <Kinnison> erm, surely 40m to meeting?
[01:18] <SteveA> i slipped
[01:18] <SteveA> yeah, 42 mins
[01:18] <Kinnison> phew
[01:18] <Kinnison> stop playing with time vortices
[01:19] <SteveA> you should have told me earlier!
[01:20] <Kinnison> which was 12 minutes ago in the future
[01:21] <Kinnison> Why does launchpad forget my login?
[01:21] <Kinnison> I can appreciate it not remembering over browser restarts (secure cookie and all that)
[01:22] <Kinnison> but not remembering from one hour to the next
[01:22] <Kinnison> this is *INCREDIBLY ANNOYING*
[01:22] <Kinnison> (I'm sure this isn't the first time I've brought this up)
[01:22] <SteveA> it ought to remember.  perhaps a bug in server affinity...
[01:23] <Kinnison> are the sessions not in the shared zodb?
[01:23] <SteveA> there is no shared zodb
[01:23] <SteveA> there is one session storage per server
[01:23] <Kinnison> oh
[01:24] <Kinnison> that sucks
[01:24] <Kinnison> so if an appserver goes down, we lose all the sessions on it?
[01:24] <SteveA> yes
[01:24] <SteveA> we have plans to improve it, but there have been higher priorities
[01:25] <Kinnison> Right
[01:25] <Kinnison> that makes sense
[01:25] <Kinnison> it isn't a showstopper after all
[01:29] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Fixed corner case when fixing missing/extra leading/trailing whitespace characters + tests added for it (patch-2367<EMAIL_ADDRESS>[01:30] <Kinnison> carlos: Mark found the bug which was causing dogfood to explode
[01:31] <Kinnison> carlos: Someone added 'datecreated' to the orderBy in distribution.py
[01:31] <carlos> Kinnison, really? what was it?
[01:31] <carlos> hmmm
[01:31] <carlos> Kinnison, I didn't know about any other problem outside the missing code problem you had
[01:32] <carlos> Kinnison, anyway, is it fixed on rocketfuel?
[01:32] <Kinnison> carlos: It's very odd that it's not causing explosions elsewhere
[01:32] <carlos> ok
[01:33] <Kinnison> then I'll prepare a shortfix for that
[01:33] <segfault> morning.
[01:40] <carlos> Kinnison, ok, thanks
[01:50] <SteveA> carlos: any rosetta issues for the agenda?
[01:50] <carlos> SteveA, hmmm perhaps someone that could take care of urgent problems while I'm on holidays?
[01:50] <carlos> other than that... nothing that I can think on
[01:51] <jamesh> carlos: btw, did you pull in the extra gettext validation checks I had on my branch?
[01:52] <carlos> jamesh, hmm, sorry, I forgot that...
[01:52] <carlos> jamesh, please, remind me the branch and I will take a look now
[01:52] <jamesh> carlos: if you want I can put it up for review separately (if it doesn't fit in with what you're doing right now)
[01:52] <sivang> hey all
[01:52] <jamesh> carlos<EMAIL_ADDRESS>[01:53] <superted> carlos: do you know when rosetta (ubuntu) syncs with GTP for the last time before breezy is released?
[01:53] <carlos> jamesh, well, it fits, your checks will detect If I'm missing anything with my latest changes
[01:53] <carlos> superted, with last package uploaded into Breezy
[01:53] <carlos> sivang, hi
[01:53] <carlos> superted, usually the .1 release (2.12.1)
[01:54] <superted> carlos: ok, thanks
[01:57] <Kinnison> hey mpt
[01:57] <mpt> hi Kinnison
[01:58] <jamesh> carlos: did you see Bruno's response to the bug report about adding extra checks to libgettextpo?
[02:00] <carlos> jamesh, yeah, and that makes me feel that we should take another approach, instead of use libgettextpo use something more python friendly...
[02:00] <carlos> jamesh, anyway, we need to do our own stuff
[02:00] <jblack> meeting time, right?
[02:00] <jamesh> carlos: gettextpo still seems the best way of performing the format string checks
[02:01] <Kinnison> SteveA: meeting time
[02:01] <kiko-afk> morning
[02:01] <lifeless> YOYOYO
[02:01] <stub> Here!
[02:01] <lifeless> There!
[02:01] <SteveA> so it is
[02:01] <carlos> jamesh, yeah, but we could sync the C scode from time to time and use a better API
[02:01] <SteveA> let's start the meeting
[02:01] <SteveA> MEETING STARTED!
[02:01] <stub> And I'm up to date
[02:01] <SteveA> who's present?
[02:01] <BjornT> me
[02:01] <salgado> I'm here
[02:02] <bradb> me
[02:02] <mpool> me
[02:02] <kiko-afk> I am
[02:02] <ddaa> I'm not.
[02:02] <jamesh> carlos: there is a _lot_ of code there (more than just C format strings)
[02:02] <cprov> here
[02:02] <lifeless> ddaa: liar!
[02:02] <spiv> me
[02:02] <jamesh> me
[02:02] <SteveA> daf is still on sick leave
[02:02] <SteveA> morgs is on vacation
[02:02] <jblack> here
[02:02] <mpt> I'm here
[02:02] <SteveA> == Agenda ==
[02:02] <SteveA>  - roll call
[02:02] <SteveA>  - next meeting
[02:02] <SteveA>  - activity reports
[02:02] <SteveA>  - production / staging status
[02:02] <SteveA>  - spec tracking!
[02:02] <SteveA>  - shipit
[02:03] <SteveA>  - rosetta while carlos is on leave
[02:03] <SteveA>  - three sentences
[02:03] <SteveA>
[02:03] <SteveA> any other items, please /msg me
[02:03] <SteveA> next meeting, same time next week?
[02:03] <Kinnison> ack.
[02:03] <bradb> sure
[02:03] <kiko_> yes
[02:03] <carlos> jamesh, but are only using the format checks and we can extract them easily. Anyway, we will talk about it later :-P
[02:03] <spiv> yep.
[02:03] <SteveA> done
[02:03] <cprov> yeah
[02:03] <SteveA> activity reports: who's on top of the world, and who's kinda spelunking?
[02:03] <jblack> what's the offset from nwo?
[02:03] <lifeless> TOP
[02:04] <kiko_> I'm restarting, I'm restarting
[02:04] <bradb> i'm up to date
[02:04] <stub> i'm fine
[02:04] <cprov> top, but with bad catchup style
[02:04] <mpt> up to date
[02:04] <jamesh> I sent one in for yesterday
[02:04] <jblack> I'm 1 week out. My new roles are log resistant and I'm seeking solutions.
[02:04] <jamesh> will send in today's later
[02:05] <mpool> i'm uptodate, but i'm trying to concentrate so they're brief
[02:05] <SteveA> brief is good
[02:05] <ddaa> Not technically up-to-date, but I've just given up on making daily reports on sprints...
[02:05] <SteveA> anyone else not accounted for on activity reporting?
[02:06] <lifeless> sabdfl ?
[02:06] <lifeless> :)
[02:06] <SteveA> sabdfl is doing community stuff now
[02:06] <lifeless> *cough*
[02:06] <Kinnison> shouldn't he be here for the spec bit of the meeting?
[02:06] <ddaa> I think he's having lunch or something...
[02:06] <SteveA> carlos: please restart your activity reports by sending one today
[02:06] <mpt> community stuff like landing major new Launchpad features :-)
[02:07] <SteveA> jblack: please send a report for today.  don't worry about making it detailed.  look at how mpool's reports look.
[02:07] <SteveA> Kinnison: the specs stuff is my items.
[02:07] <carlos> SteveA, I have all inside time tracker, I just need to send them. Will be up to date before leaving tomorrow
[02:07] <SteveA> carlos: ok
[02:07] <mpt> specs stuff? no, that's so last week
[02:07] <Kinnison> SteveA: okies
[02:07] <SteveA>  - production / staging status
[02:07] <Kinnison> kiko_: We've not seen an activity report from you since July 7th
[02:07] <SteveA> stub: what's happening on staging?
[02:07] <SteveA> Kinnison: i'll kick his ass later
[02:08] <kiko_> Kinnison, :-P
[02:08] <stub> Running trunk, but db won't be refreshed from production until carlos has had a chance to confirm the results of the whitespace-migration scrpt
[02:08] <SteveA> stub: also, is production rolling out happening as normal?
[02:08] <dilys> Merge to<EMAIL_ADDRESS>Librarian buildd_download_url support. r=spiv (patch-2368<EMAIL_ADDRESS>[02:08] <stub> production rollouts as planned. Rolled out Tuesday, will roll out next tuesday unless anyone has special needs
[02:08] <kiko_> stub, ah, so running trunk and applying database patches to the existing data?
[02:09] <carlos> stub, I think that it will happen later today. I think I fixed all issues and is safe to execute the migration script on production
[02:09] <stub> yes
[02:09] <SteveA> stub: i have some significant menus stuff that is being reviewed right now. i'd like to get it onto staging soon, and maybe includeed in the next production rollout.  it fixes lots of menus bugs.
[02:09] <kiko_> stub, I have to review some of salgado's shipit stuff for today
[02:09] <stub> SteveA: Let me know the patch number when it lands
[02:09] <SteveA> stub: the RF patch number?
[02:09] <stub> Ok - sounds like I will be tagging in maybe 24 hours time
[02:09] <stub> SteveA: Yes.
[02:09] <SteveA> okay
[02:10] <kiko_> did anyone see any issues in staging that arised from kinnison's package patch?
[02:10] <SteveA> thanks
[02:10] <SteveA> did anyone CHECK?
[02:10] <Kinnison> kiko_: thanks for asking, I was just about to ask :-)
[02:10] <salgado> stub, I have some small DB schema fixes that needs to go in the next shipit cherrypick. is that a problem?
[02:10] <stub> Kinnison's changes only landed on staging today btw.
[02:10] <Kinnison> but they've been in RF for a week
[02:10] <stub> salgado: Cherry pick, as in you need it before the next production rollout?
[02:11] <salgado> stub, yes
[02:11] <stub> salgado: Generally isn't a problem. Give me the rocketfuel patch number as normal, and remind me about the db patch (which I will need to renumber)
[02:12] <salgado> stub, okay. and I'll need an updated sqloject too. I need a fix applied this week
[02:12] <stub> staging/production issues done?
[02:12] <SteveA> jamesh: i will need your help in understanding some of the calendaring code's use of menus, btw.  i may have broken it :-/
[02:13] <stub> salgado: hurry up then - not much left of this week ;)
[02:13] <jamesh> SteveA: okay
[02:13] <SteveA> stub/salgado: we need to think about getting the shipit code onto staging very soon
[02:13] <stub> It is on staging already
[02:13] <salgado> the one that is not in rf, I guess?
[02:13] <kiko_> has been for a long time
[02:14] <SteveA> with virtual hosting?
[02:14] <kiko_> no
[02:14] <kiko_> but that isn't in RF yet
[02:14] <SteveA> right, that's what i want to see
[02:14] <kiko_> I will review it today
[02:14] <kiko_> well be patient old man :)
[02:14] <SteveA> when i say "shipit", i'm talking about the application as it will be deployed
[02:14] <niemeyer> kiko_: Btw, I couldn't get to the review site you mentioned for shipit due to permissions. Do I need some specific permission to get there?
[02:14] <kiko_> that's clearer :)
[02:15] <mpt> The shippable shipit
[02:15] <kiko_> niemeyer, you need the certificate I sent you
[02:15] <kiko_> niemeyer, well, wait, what site?
[02:15] <niemeyer> kiko_: Will check it
[02:15] <SteveA> so, what's the stu / kiko / salgado plan for getting the latest shipit onto staging, and maybe out to production soon
[02:15] <Kinnison> So, has ANYONE checked their apps?
[02:15] <niemeyer> kiko_: The shipit review you mentioned on a mail the day before yesterday
[02:16] <lifeless> yep, I ran make check on mine before committing
[02:16] <SteveA> okay
[02:16] <salgado> SteveA, I'll write more tests, get kiko to review, make sure it's cherrypickable and then merge
[02:16] <SteveA> let's take this one point at a time
[02:16] <niemeyer> kiko_: To marilize..
[02:16] <SteveA> Kinnison: your checking of apps stuff
[02:16] <Kinnison> lifeless: if only the test suite was comprehensive :-)
[02:16] <kiko_> SteveA, review salgado's patch today, land it in RF, goes onto staging, merge it into production by tuesday
[02:16] <stub> Gina broke, but you know that already
[02:16] <SteveA> kiko_: thanks
[02:16] <Kinnison> stub: aye, I've got a fix for that flying through pqm now
[02:17] <SteveA> Kinnison: you have the floor.
[02:17] <SteveA> let's check out the checking
[02:17] <Kinnison> Right, I sent a mail last week when I merged PackageDBRework
[02:17] <stub> (which reminds me - I should be doing gina runs daily on staging)
[02:17] <Kinnison> asking people to check their individual apps which might interact with binary packages
[02:17] <Kinnison> The test suites passed (obviously)
[02:17] <Kinnison> But as demonstrated by stub, this doesn't catch everything
[02:18] <cprov> Kinnison: but they are so silly atm (about gina tests ..)
[02:18] <Kinnison> I'd like to see everyone whose app goes near binary packages confirming that their app is safe on the PackageDBRework wiki page
[02:18] <SteveA> so, that's buildd, soyuz ui, malone, rosetta, foaf
[02:18] <cprov> buildd patch for it is partially done, ETA today evening.
[02:19] <Kinnison> the C.A.P. is done now and merged
[02:19] <SteveA> BjornT / bradb: who will check malone?
[02:19] <SteveA> carlos / jordi: you need to organise checking rosetta
[02:19] <bradb> the tests, mainly
[02:19] <bradb> i think it's ok
[02:19] <SteveA> bradb: what do you mean?
[02:19] <cprov> SteveA: soyuz will be delayed for next week or weekend (if i'm not too tired)
[02:19] <carlos> SteveA, Kinnison we are not using binary packages on Rosetta atm
[02:19] <carlos> SteveA, Kinnison only languagepacks exports
[02:19] <Kinnison> carlos: thanks
[02:20] <SteveA> salgado: please check foaf asap
[02:20] <bradb> SteveA: our test coverage is fairly solid. any breakage that we'd be likely to find by manually checking would likely have already been spotted by the test suite.
[02:20] <carlos> SteveA, Kinnison and that's useless without gina's data...
[02:20] <SteveA> carlos: then sign it off on the PackageDBRework page
[02:20] <bradb> and we don't really use BPs in malone
[02:20] <salgado> SteveA, will do it
[02:20] <carlos> SteveA, Kinnison anyway, the language packs exports are run by hand...
[02:20] <BjornT> bradb, SteveA: i'll take a quick look anyway just to make sure
[02:20] <bradb> BjornT: sure, sounds good
[02:20] <kiko_> does foaf even touch BP?
[02:20] <Kinnison> If there's any chance you go near BPs, check
[02:20] <carlos> SteveA, ok
[02:20] <Kinnison> basically
[02:20] <SteveA> BjornT: thanks, please sign off on the wiki page when you're done
[02:20] <BjornT> will do
[02:21] <SteveA> salgado: sign off when you've looked
[02:21] <jordi> SteveA: sorry, I've been ill for the last two days and couldn't get anything useful done yesterday
[02:21] <jordi> I hope to be available all evening today, ok
[02:21] <SteveA> jordi: did you let me or carlos or kiko know you were ill?
[02:22] <SteveA> moving on to...
[02:22] <SteveA>  - spec tracking!
[02:22] <SteveA> so, mark landed a spec status tracker in launchpad
[02:22] <Kinnison> (in my personal project)
[02:22] <cprov> cprov: is using too
[02:22] <SteveA> jblack will be adding the bzr specs to it shortly
[02:23] <jordi> not by mail, I'm afraid. I dropped a note on IRC, but I thought it was ok as I can catch up any day of the week after all
[02:23] <kiko_> I am going to be adding LP specs shortly
[02:23] <SteveA> great.
[02:23] <jordi> SteveA: if mails are requiuired I'll do so next time
[02:23] <SteveA> kiko_: do launchpad specs get tagged on the wiki in any way to show where they are in the spec tracker?
[02:23] <jblack> Shortly is defined as within the next 24 hours.
[02:23] <SteveA> jordi: you just need to tell someone.  carlos or me or kiko.
[02:24] <jordi> SteveA: sure
[02:24] <SteveA> kiko_: or rather, that they are in the spec tracker?
[02:24] <jordi> SteveA: just note this doesn't affect my working hours at all, just want to make that clear
[02:24] <jblack> (I'm on the tail end of a ~ 16 hour day)
[02:24] <SteveA> Everyone, if you add a new launchpad spec, or alter the status of one for some reason, or rename one, then put that information into launchpad.
[02:24] <kiko_> SteveA, my idea was to remove the header and add a link to the spectracker homepage for the wiki
[02:24] <kiko_> that way we don't have duplicated information
[02:24] <SteveA> kiko_: sounds good
[02:24] <kiko_> and that way there's a link back to launchpad
[02:25] <jamesh> possibly inconsistent duplicated information ..
[02:25] <SteveA> so, it will be obvious from looking at the wiki page that it is in launchpad
[02:25] <SteveA> that its metadata is in launchpad, i mean
[02:25] <kiko_> I was going to consult with you about this plan, but that's what I was thinking
[02:25] <SteveA> kiko_: sounds fine
[02:25] <SteveA> any questions, observations or points about the spec tracker?
[02:26] <kiko> it has too many links in the Person's actions portlet?
[02:26] <cprov> SteveA:  how will be the policy to add the tracker-side summary, anything brief is ok ?
[02:26] <mpt> Is it going to be possible in future for the spec tracker to contain actual specs?
[02:26] <stub> There appear to be no specs linked to the launchpad product atm
[02:26] <lifeless> mpt: no
[02:26] <lifeless> mpt: they are references not the spec themselves, this is deliberate
[02:26] <kiko> mpt, in the future, yes, that's the plan.
[02:26] <lifeless> kiko: ?!
[02:26] <mpt> lifeless, meet kiko. kiko, lifeless.
[02:26] <lifeless> kiko: mark was saying it wasn't.
[02:26] <SteveA> i guess if we add wiki functions into launchpad
[02:27] <SteveA> but that's some way in the future
[02:27] <carlos> kiko, will you handle then all specs? or should we add there our own specs?
[02:27] <spiv> Sounds like we need a spec for this, to clear up the confusion ;0
[02:27] <spiv> ;)
[02:27] <mpt> I'm just concerned that having the spec on one site, and the metadata on another site, will slow things down a bit
[02:27] <kiko> not for the current iteration, lifeless, but it's obviously a lot better if specs are kept in launchpad.
[02:27] <kiko> or, in more words, what mpt said.
[02:27] <sivang> guys, are you going to disucss the support application in UBZ?
[02:27] <lifeless> kiko: I'm not sure it is, having them external is nice for nont-Canonical projects.
[02:27] <stub> And it appears specs can be linked to the product, or the productseries. So should specs go against Launchpad, Launchpad-main, Malone, Malone-main?
[02:27] <lifeless> anyway, ETOPIC for now.
[02:28] <lifeless> sivang: sure.
[02:28] <SteveA> i think all specs should go against Launchpad
[02:28] <kiko> lifeless, that can be an optional situation, but it's not the ideal in terms of convenient workflow.
[02:28] <kiko> carlos, I can start by trying to move them all and ask for help
[02:28] <sivang> lifeless: nice, cause I see it mentioned on the MaloneSupportIntegration pre-spec , I figured they should be probably discussed together or with some proximity
[02:28] <carlos> kiko, ok
[02:29] <SteveA> can i move onwards?
[02:29] <SteveA> anyting more on specs?
[02:29] <SteveA>  - shipit
[02:29] <SteveA> i think we discussed that earlier
[02:29] <SteveA> there's code review happening, it will be on staging soon
[02:30] <SteveA> the virtual host set-up for staging has been done
[02:30] <kiko> maybe talk a bit about shipit and vhosting for people who don't know about it?
[02:30] <SteveA> we'll need to sort out an equivalent for production when it is time to switch the apps
[02:30] <salgado> there's one thing I need to talk with you and kiko, but I don't think we should discuss it here
[02:30] <SteveA> kiko: i'd rather not do so right now.
[02:31] <SteveA> except to say that shipit will be running using the launchpad app server, but with special configuration so that some pages are available with a different UI main template
[02:31] <SteveA> different CSS, and at a different domain for that subtree of pages.
[02:31] <kiko> thanks
[02:32] <bob2> is that just done with a ++skin++ and mod_rewrite?
[02:32] <SteveA> bob2: no, not at all
[02:32] <SteveA> ++skin++ is evil
[02:32] <SteveA> and should be removed from zope3
[02:32] <bob2> praise the lord!
[02:32] <bob2> lifeless: you like sin and skin
[02:32] <SteveA>  - rosetta while carlos is on leave
[02:32] <jamesh> ++sin++?
[02:32] <Kinnison> a lot of times, a like of skin is a sin
[02:33] <SteveA> so, carlos is taking some leave soon
[02:33] <SteveA> when is that carlos?
[02:33] <carlos> next week
[02:33] <SteveA> for how long?
[02:34] <carlos> will be without computer or network since tomorrow night until 17th morning
[02:34] <SteveA> so, jordi will be around to be on the mailing lists
[02:35] <SteveA> if there are any urgent issues, kiko or i can take care of it
[02:35] <carlos> ok, I will have my phone with me
[02:35] <carlos> just in case something urgent happens
[02:35] <kiko> about rosetta, just ftr, I am concerned that 50% of the exports fail with a librarian problem
[02:35] <kiko> (manual downloaded exports)
[02:35] <carlos> but I will have only my mind with me, nothing to check code with :-)
[02:36] <kiko> and another 30% or so fail because of rosetta issues
[02:36] <kiko> that's pretty bad QoS
[02:36] <carlos> kiko, I have a branch with many fixes that should handle that 30%
[02:36] <SteveA> hmm
[02:36] <kiko> hopefully; put it up for review
[02:36] <carlos> that will add to the review queue today or tomorrow
[02:36] <SteveA> we need to get spiv looking at the librarian problem
[02:36] <carlos> as that was my work of last weeks
[02:36] <kiko> spiv is aware of the problem, but says he doesn't know how to debug it
[02:36] <kiko> I have suggested instrumenting the librarian/rosetta code to help debug
[02:37] <SteveA> okay, then i need to talk with spiv and maybe carlos about it
[02:37] <spiv> I'll have to expend more effort trying to ping it down.
[02:37] <spiv> s/ping/pin/
[02:37] <SteveA> let's talk about this tomorrow, okay?
[02:37] <spiv> Good idea.
[02:37] <kiko> sure
[02:37] <carlos> kiko, as a workaround we could stop using librarian as a cache....
[02:37] <SteveA> spiv: we'll talk in the morning my time
[02:37] <kiko> carlos, good point
[02:37] <carlos> ok
[02:37] <spiv> kiko: Is it really 50% due to librarian?
[02:37] <kiko> yes
[02:37] <kiko> I've sent you a few errors, but I have about 5 daily
[02:38] <spiv> kiko: I only see a trickle of the librarian ailures in the error logs.
[02:38] <kiko> there are only about 10 download requests daily
[02:38] <spiv> SteveA: Ok.
[02:38] <jordi> SteveA: I'll be leaving office soonish, should I do my magic lines?
[02:38] <SteveA> yeah, let's do the three sentences!
[02:38] <SteveA> DONE: menus refactoring, management, code review, shipit debugging
[02:38] <SteveA> TODO: menus landing, management, navigation components
[02:38] <SteveA> BLOCKED: no
[02:38] <bradb> DONE: Various things involved in URL changes (created a new distro source package object, fixed canonical URLs for IBugTask to return "most specific" URL possible.) BugInContext spec. Landed portlet mania, the finale. Landed significant /malone/assigned decrackification. Landed some warnings cleanup.
[02:38] <spiv> Ah, ok.  I thought rosetta was busier than that, because of all the other tracebacks  ;)
[02:38] <bradb> TODO: Slay the URL dragon, possibly sneaking in other UI improvements along the way.
[02:38] <bradb> BLOCKED: No.
[02:38] <mpt> DONE: AutoBuild pages, spec tracker cleanup, bug fixes, LaunchpadMenus facetization
[02:38] <mpt> TODO: more LaunchpadMenus work, support tracker cleanup, more bugfixes
[02:38] <mpt> HINDRANCES: none
[02:38] <Kinnison> DONE: sprinting (mostly publisher and buildd)
[02:38] <Kinnison> TODO: sprinting (mostly uploader and buildd)
[02:38] <Kinnison> BLOCKED: amazingly; nothing of note.
[02:38] <cprov> DONE: need fix in buildd, partially setup DF, partially integrating uploader support
[02:38] <cprov> TODO: some missed review, DF running until end of the week
[02:38] <cprov> BLOCKED: none
[02:38] <BjornT> DONE: user documentation for email ui. started with PreDefinedBugReports and MaloneSearchResult. reviews. some bugs.
[02:39] <jblack> DONE: bazaar wiki, support, lots of list traffic, blogging
[02:39] <BjornT> TODO: MaloneSearchResult and PreDefinedBugReports.
[02:39] <jblack> TODO: more of the same
[02:39] <BjornT> BLOCKED: no
[02:39] <stub> DONE: LibrarianGarbageCollection, BrowserNotificationMessages
[02:39] <salgado> DONE: ShipItNG
[02:39] <stub> TODO: LibrarianGarbageCollection, BrowserNotificationMessages
[02:39] <stub> BLOCKED: Nothing
[02:39] <jblack> BLOCKED: none new.
[02:39] <jamesh> DONE: finish off gpg keyring trust analyser, track down sqlobject cache bug, handle celso's reviews
[02:39] <carlos> DONE: lots of Languagepacks / poexport fixes, user support and minor templates fixes
[02:39] <jamesh> TODO: scheduler to work with specs code, CalendarAggregation, code review
[02:39] <jamesh> BLOCKED: no
[02:39] <lifeless> DONE: symlink support for bzr, pendingreviews is bzr enabled, pqm is bzr enabled
[02:39] <kiko> DONE: Shipit design and planning, Code reviews, Rosetta export assistance, bug triage, bugfixing of pagetitles fallout, exploring xx-notfound-traversals (thanks stub), some canonical-related issues
[02:39] <kiko> TODO: Code reviews, land bugfixes and spec work
[02:39] <kiko> BLOCKED: Not really, will need stub and salgado to get shipit where it needs to be
[02:39] <ddaa> DONE: preparing branches for leave, leave, launchpad-branch sprint
[02:39] <ddaa> TODO: finish importd-archivelocation, prepare launchpad-branch for landing, fix cscvs bugs
[02:39] <ddaa> BLOCKER: importd-archivelocation got out of hand, not enough hours in a day.
[02:39] <lifeless> TODO: baz2bzr, more symlink support, gpg support for bzr
[02:39] <lifeless> BLOCKED: nothing
[02:39] <spiv> DONE: Mainly reviews!  And some ad hoc debugging for people on irc.  But not much else :/
[02:39] <spiv> TODO: Rosetta/Librarian debugging.  Reviewing (hopefully not as much as last week).  Following up patches sent to SQLObject.  Work on supermirror SFTP changes.
[02:39] <spiv> BLOCKED: No.
[02:39] <salgado> TODO: ShipItNG, BasicVoting
[02:39] <jordi> DONE: haven't worked this week yet; been ill.
[02:39] <salgado> BLOCKED: No
[02:39] <carlos> TODO: Move my fixes branch into review queue and take a break
[02:39] <carlos> BLOCKED: No
[02:39] <jordi> TODO: cleanup backlog of mailing list/rosetta email, do pending imports
[02:40] <SteveA> anyone else?  mpool ?
[02:40] <jordi> BLOCKED: need feature to track what applications join launchpad to use it as their official translation/bug tracker (bug in malone, sabdfl should be looking at it). I need this to start my fierce "Use rosetta" campaign.
[02:40] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Missed a binarypackage->binarypackagerelease in gina, fixes #2130 (patch-2369<EMAIL_ADDRESS>[02:41] <niemeyer> DONE: Introspection on HCT, mostly
[02:41] <SteveA> mpool: three sentences.  DONE: what you did in the last week or so, as a single short sentence.  TODO: same, but for the forthcoming week.  BLOCKED: if there is anything stopping you working on things you need to.
[02:41] <niemeyer> TODO: Sprint next week on HCT
[02:41] <niemeyer> BLOCKED: Nothing
[02:41] <Kinnison> stub: if ^^ that patch doesn't fix it, let me know. It bloody well ought to :-)
[02:41] <SteveA> no one seriously blocked this week
[02:41] <SteveA> BjornT: working from pov offices, meet at 10am tomorrow as arranged, okay?
[02:42] <mpool> DONE: about 60% of integration of weave into bzr
[02:42] <BjornT> SteveA: sounds good
[02:42] <mpool> TODO: the other 60% :)
[02:42] <mpool> BLOCKED: no
[02:42] <sabdfl> jordi: it landed last night, very basic but it's there
[02:42] <jordi> sabdfl: oh, great.
[02:42] <sabdfl> just a toggle that will but a little alert in the product portlet
[02:42] <sabdfl> s/but/put/
[02:42] <jordi> sabdfl: if you want to add something to malone, that's https://launchpad.net/malone/bugs/1718
[02:42] <SteveA> we have three more meeting minutes
[02:42] <jordi> sabdfl: that's all I need.
[02:42] <SteveA> any final points or issues?
[02:42] <bradb> SteveA: two small things
[02:43] <bradb> 1. this is week 4 that i'm asking for a malone 1.0/delivery date ;)
[02:43] <jordi> sabdfl: so this will be usable on Tuesday, right?
[02:43] <sabdfl> erm, is logging in broken?
[02:43] <jordi> sabdfl: I just logged in
[02:43] <sabdfl> bradb: you set the delivery date
[02:43] <bradb> but 2. to help you along, i'd suggest we roll out right after the URL changes have landed and the same has stabilized
[02:43] <bradb> s/same/system/
[02:44] <bradb> sabdfl: the requested features were continuing to be a moving target though :)
[02:44] <bradb> what do you think of rolling out after the URL changes have landed, we've run the system for a few days to ensure it remains stable?
[02:45] <kiko> bradb, without having a stable URL structure it's hard for me to use tha app and agree it looks 1.0able
[02:45] <sabdfl> bradb: have you created a 1.0 milestone for malone? and assigned bugs and specs to it?
[02:45] <SteveA> 45s left.  brad, let's talk this through in detail later today.
[02:45] <kiko> bradb, and what do you mean "rolling out after the URL changes have landed"?
[02:45] <bradb> sabdfl: I did a huge amount of triage in the wiki and updated MaloneOneDotZero to give kiko a prelim list, as requested.
[02:45] <kiko> bradb, how does this differ from the normal rollout process?
[02:45] <SteveA> i don't want to keep everyone else here to talk about malone 1.0
[02:45] <kiko> sabdfl, yes, we're aware of the planned specs.
[02:45] <kiko> SteveA, then terminate the meeting
[02:46] <bradb> sabdfl: not using a 1.0 milestone in the BTS though, because there aren't bugs for all these
[02:46] <bradb> right, we can discuss the date outside the meeting
[02:46] <SteveA> cool
[02:46] <SteveA> MEETING OVER
[02:46] <sabdfl> thanks guys
[02:46] <SteveA> thanks people.  see you next week, except carlos.  have a good vacation, carlos.
[02:46] <bradb> cheers
[02:46] <carlos> SteveA, thank you
[02:46] <Kinnison> cool
[02:46] <bradb> kiko: i meant roll out 1.0 after the URL changes have landed
[02:46] <carlos> SteveA, spiv when will we talk about the librarian issues?
[02:47] <bradb> and, of course, that we've ensured that the system remains stable
[02:47] <SteveA> i'll talk with spiv about it tomorrow morning
[02:47] <lifeless> lunchtime
[02:47] <SteveA> late lunch launchtime
[02:47] <kiko> bradb, we'll see when we have the code landed.
[02:47] <carlos> SteveA, ok
[02:48] <jordi> so, for your information, I lost another kilogram this week, thanks to being ill
[02:49] <jordi> I didn't eat anything in over 24 hours and went back to 53 kilograms. :)
[02:49] <kiko> carlos, you need to explain the "why" of the change in the normalize_whitespaces function
[02:49] <kiko> jordi, that's hardly a healthy way to diet
[02:49] <carlos> jordi, dude!
[02:49] <mpool> sleep here too
[02:49] <jordi> kiko: dude, everything I drank or ate would leave my organism after 30 mins
[02:50] <kiko> okay let's be less graphical
[02:50] <carlos> kiko, Hmm, because it's broken? :-P
[02:50] <jordi> I don't think I could absorb any nutrient in 30 mins :)
[02:50] <jordi> kiko: you asked for it :P
[02:50] <carlos> jordi, but we didn't ;-)
[02:50] <\sh> jordi: you diagnosis sounds like mine a couple of years ago :(
[02:50] <jordi> next time details via /msg :P
[02:50] <kiko> carlos, well, you need to explain to me how a string that is originally "\n\n\n\n" can be translated to "".
[02:51] <jordi> that would error out in msgfmt even
[02:51] <carlos> kiko, it's a fix, so people cannot fill a translation with garbage
[02:52] <carlos> kiko, that's only true if the msgid has text
[02:52] <kiko> carlos, I still don't understand.
[02:52] <carlos> so if you have as a msgid 'foo' it's a bit broken that you have as a translation '\n\n\n\n'...
[02:52] <carlos> kiko, it's a side effect of the bug we had with textareas and firefox
[02:52] <kiko> oh
[02:52] <kiko> so it /will/ fail validation?
[02:52] <carlos> where we got new lines where nothing was typed
[02:52] <jordi> carlos: ah, so it doesn't affect a msgid "\n\n\n\n" that gets translated to ""?
[02:53] <carlos> kiko, right
[02:53] <kiko> I'll update your docstring to make that clearer, thanks.
[02:53] <carlos> jordi, if a msgid has only whitespaces, that code will not break the translation
[02:53] <kiko> jordi, this is designed to make it fail properly
[02:53] <jordi> nod
[02:53] <niemeyer> Is that mostly empty page expected to be the result after a login on launchpad?
[02:54] <carlos> jordi, kiko if msgid == '\n\n\n\n' and the msgstr is '', the system will set it to '\n\n\n\n' automatically
[02:54] <kiko> carlos, right, right
[02:54] <carlos> if the msgstr is already that, we will not touch it
[02:54] <carlos> if we do, it's a bug :-)
[02:56] <stub> spiv/carlos: is the librarian issue rosetta exports having likely to be a transaction problem, and will using the newly undeprecated make-the-librarian-do-the-database-inserts API likely to work around the problem?
[02:56] <stub> Erm... scrap that.... exports won't be able to use that...
[02:57] <jordi> carlos: good
[02:58] <kiko> carlos, why don't you just "fix" the output text instead of making it error out?
[02:59] <kiko> carlos, because it doesn't make sense to include a translation of something which isn't whitespace into something which is whitespace only, perhaps?
[02:59] <carlos> kiko, making it error out?
[03:00] <carlos> kiko, we fix the output....
[03:00] <kiko> by returning ""?
[03:00] <kiko> not really
[03:00] <kiko> if the original translation is "foo\n\n" and the translation is "\n\n" then...
[03:00] <kiko> you return "" which will be an error (right?)
[03:01] <kiko> s/original translation/template/
[03:01] <kiko> carlos, can you explain to poor me?
[03:02] <carlos> kiko, no, it will not be an error
[03:02] <carlos> kiko, Rosetta will take that as the real import
[03:02] <salgado> anybody willing to try the new shipit (http://shipit.async.com.br/)? use sampledata users to login
[03:02] <carlos> and will store it as if the user didn't submit any value there
[03:04] <kiko> carlos, and then?
[03:04] <carlos> kiko, normalize_whitespace is just a 'filter'
[03:04] <carlos> that improves the input we get from the user
[03:04] <carlos> kiko, it's not a validator
[03:05] <carlos> if you remove the filter, you can get garbage into the db (until jamesh's validation changes land into rocketfuel)
[03:05] <carlos> kiko, so we simulate that the user left that field untranslated, nothing more
[03:06] <kiko> carlos, okay, understood.
[03:16] <carlos> jamesh, btw, your patch looks ok
[03:17] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  config file updates (patch-2370<EMAIL_ADDRESS>[03:23] <salgado> SteveA, ping?
[03:39] <kiko> cprov, ping?
[03:39] <cprov> kiko: pong
[03:53] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  distrorelease does not have an attribute called datecreated. Thusly do not orderBy it in distribution.py (patch-2371<EMAIL_ADDRESS>[04:05] <Kinnison> brb
[04:22] <bradb> how the heck did sabdfl manage to write a support tracker and a spec tracker when we weren't looking? :)
[04:23] <kiko> he's working on community stuff, bradb
[04:23] <bradb> kiko: makes it even more impressive ;)
[04:31] <Keybuk> ok
[04:31] <Keybuk> I'm going in a loop
[04:32] <Keybuk> https://launchpad.net/ -> "Log In/Register" -> "Log In" -> You are now logged in -> Overview
[04:32] <Keybuk> and I'M NOT LOGGED IN again
[04:39] <cprov> SteveA: are you available for a quick-flash review in a urgent patch for buildd/uploader integration or do you have any suggestion ?
[04:42] <niemeyer> kiko: ping
[04:43] <niemeyer> Keybuk: ping
[04:45] <kiko> niemeyer?
[04:46] <niemeyer> kiko: How do I reach the zope admin interface on a local launchpad?
[04:47] <kiko> niemeyer, there is no such thing in zope3.
[04:47] <kiko> well, at least not in our instance
[04:47] <niemeyer> kiko: There isn't?
[04:47] <kiko> nope.
[04:47] <kiko> what do you need to do?
[04:47] <niemeyer> kiko: What about the usual /manage?
[04:48] <niemeyer> kiko: I'm trying to setup hct to talk to my own launchpad
[04:48] <niemeyer> kiko: But I don't understand how, so far.
[04:48] <kiko> there is no /manage
[04:49] <kiko> well, hct itself should have a configuration (independent of launchpad), AIUI
[04:49] <niemeyer> kiko: There's one in zope3, but ok.. you don't use it.
[04:49] <kiko> this configuration would indicate what server it contacted
[04:49] <kiko> yes, no /manage in launchpad
[04:50] <niemeyer> kiko: Yes, I understand that part
[04:50] <niemeyer> kiko: But launchpad itself is not prepared to answer those requests, if I understood the problem correctly.
[04:50] <niemeyer> kiko: I mean, my own setup of launchpad.
[04:50] <niemeyer> kiko: So I'm just trying to figure out what I'm missing.
[04:52] <niemeyer> kiko: Btw, how isn't there any kind of admin interface? Something that allows superusers to give permissions, etc?
[05:01] <niemeyer> s/how//
[05:01] <Kinnison> the database
[05:09] <lifeless> Kinnison: export LD_PRELOAD=/usr/lib/libflcow.so:$LD_PRELOAD
[05:09] <lifeless> export FLCOW_PATH=/usr/src/:/home/robertc/source/
[05:10] <Kinnison> gotcha
[05:14] <kiko> niemeyer, the database, code, etc. :)
[05:15] <niemeyer> kiko: Understood :)
[05:16] <SteveA> salgado: ping
[05:16] <SteveA> cprov: ping
[05:16] <cprov> SteveA: pong
[05:16] <salgado> SteveA, have you seen my email about launchbag.txt?
[05:16] <kiko> welcome back SteveA
[05:16] <SteveA> salgado: not yet
[05:16] <SteveA> just back from lunch
[05:16] <salgado> hmmm. I sent it last night
[05:18] <cprov> SteveA: any clue on that review or what else ?
[05:18] <SteveA> cprov: you want me to do some instant review for you?
[05:19] <cprov> SteveA: if you can, it'd be great ;)
[05:19] <SteveA> how many kloc?
[05:20] <SteveA> ;-)
[05:21] <cprov> SteveA: just switch back, but not more than 300 (including a big method removal)
[05:21] <SteveA> okay, give me the url to the diff
[05:21] <cprov> SteveA: kloc ;)
[05:23] <kiko> salgado, shipit.async.com.br is down
[05:23] <kiko> can you put it back up (or run a separate instance)
[05:24] <salgado> kiko, you need it now?
[05:24] <kiko> sabdfl wanted to look at it, salgado -- does that answer the question? :)
[05:24] <Kinnison> brb
[05:26] <salgado> great. got conflicts while doing the merge
[05:26] <salgado> undoing the merge. need 2 more seconds
[05:26] <kiko> okay
[05:27] <cprov> SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJVeLhO.html
[05:28] <salgado> kiko, it's back
[05:42] <niemeyer> kiko: Trebuchet was the name I was looking for.. it's running indeed. I'll have to study that further to understand how to glue those pieces together.
[05:42] <kiko> niemeyer, right, trebuchet is the xmlrpc server you're talking to. I told you you should come and stay with us for a bit.. :-)
[05:45] <niemeyer> kiko: I know.. that would be nice indeed. OTOH, while talking to Mark he mentioned I should first try to catch up with Scott on HCT, and then move to Launchpad.
[05:46] <kiko> HCT and Launchpad are siamese twins
[05:46] <niemeyer> kiko: It turns out that some parts of HCT are inside Launchpad :)
[05:46] <bradb> BjornT: ping
[05:46] <BjornT> bradb: pong
[05:46] <bradb> BjornT: hi, question about the NotBugInContext implementation...
[05:47] <bradb> so, I'm on, say +edit, to edit the bug desc, summary, etc.
[05:47] <bradb> the context on that page has already been magically adapted to an IBug in behind the scenes
[05:47] <bradb> therefore, the bug portlets that are registered already on IBugTask also need to be registered on IBug. that part i've done now, but...
[05:48] <bradb> in those pages, when i do "stucture context/@@+portlet-actions", how do i get at the bug task, when this is a view on an IBug? specifically, i need the URL of the bug task.
[05:48] <bradb> in a way that works whether the template is shown on the bug page, or whether the portlet is shown on a page hanging off that page (e.g. +edit, +activity, whatever.)
[05:50] <bradb> (just to be clear, i mean "how do i get at the bug task in bug-portlet-actions.pt code, whose view class is BugPortletView, and whose context is, in this case, an IBug, even before IBug(context))
[05:51] <BjornT> what you can do is, in those cases where you need to access the bugtask, put it on the view class
[05:51] <bradb> BjornT: where would i get that information from to set it as an attribute in the view class?
[05:52] <bradb> the context is an IBug, even before the adaptation IBug(context)
[05:52] <mpt> SteveA: After merging from your branch, I get "ConfigurationError: ('Invalid value for', 'class', "Couldn't import canonical.launchpad.browser, cannot import name DefaultLink")", though DefaultLink is defined in __init__.py
[05:53] <SteveA> DefaultLink is gone
[05:53] <SteveA> so it sounds like a merge that needs massaging
[05:54] <mpt> well, I did try without that line too, but got the same error
[05:54] <bradb> BjornT: I might have asked the question in a confusing way. Do you understand what I'm asking?
[05:54] <mpt> SteveA: Had you merged from rocketfuel into that branch recently?
[05:55] <SteveA> yes
[05:55] <SteveA> okay, spiv has reviewed that code
[05:56] <SteveA> so i'll be merging it into RF soon
[05:56] <SteveA> cprov: review sent
[05:57] <cprov> SteveA: I've seen, thank you
[06:00] <bradb> BjornT: ?
[06:00] <cprov> SteveA: what do you mean with:  having a hardcode filename is nasty .. ?
[06:00] <mdke> carlos, around?
[06:00] <BjornT> bradb: i think i understand the question. i'm wondering if that problem will be solved using menus, though. otherwise, if it's dependant on a bugtask, the portlet probably should be registered only on IBugTask
[06:00] <carlos> mdke, yes
[06:00] <carlos> hi
[06:00] <mdke> carlos, hiya :) It's that time of year again when I pester you about stuff
[06:01] <bradb> BjornT: it has to be shown on both pages though. the bug page, and pages that live underneath that URL (which might be one level deep, or might be deeper than that.)
[06:01] <carlos> mdke, ;-)
[06:01] <mdke> carlos, the documentation from ubuntu-doc is basically ready, we need to figure out how to get it in rosetta for translation now.
[06:01] <bradb> BjornT: "it", i.e. the portlets in question
[06:01] <mdke> carlos, my main concern is not losing translations done for the hoary release
[06:02] <carlos> mdke, well, you don't lose them, you will see them as suggestions
[06:02] <mdke> if the string is unchanged right?
[06:02] <carlos> mdke, right
[06:02] <bradb> BjornT: for example, if there were in IBugInContext, I would simply do "context/bugtask/fmt:url" and it would work everywhere.
[06:02] <carlos> if you changed the string... we still don't show that kind of suggestions
[06:02] <mdke> carlos, cool np
[06:03] <mdke> carlos, i'll try and get the pot's generated and then will email, ok?
[06:03] <bradb> (ideally, i'd like it to be just context/fmt:url, but i'm not sure that the canonical_url framework can handle it.)
[06:03] <carlos> mdke, sure
[06:03] <carlos> mdke, but it's better if you handle that with jordi now
[06:03] <carlos> mdke, he's handling that kind of requests
[06:04] <carlos> mdke, and I will be offline next week
[06:04] <mdke> carlos, ok that is fine. I'll email the list and copy to him
[06:04] <mdke> carlos, thanks very much
[06:04] <carlos> mdke, send the copy to<EMAIL_ADDRESS>so I get a copy (Jordi is also behind it)
[06:04] <jordi> I just came in
[06:04] <jordi> hello
[06:04] <mdke> hi
[06:04] <mdke> carlos, okay
[06:04] <mdke> i need to figure out how to make the pot now...
[06:05] <jordi> carlos: ok, to start with my backlog, I had something in my history about me dealing with "review-" templates.
[06:05] <bradb> BjornT: so, what do i do to be able to access the bugtask's canonical URL when these portlets have IBug as their context then? i'm hoping you have something in mind that i overlooked.
[06:05] <jordi> I guess I need info on that, if I have to do it now.
[06:05] <jordi> mdke: hi!
[06:05] <jordi> what's up?
[06:05] <mdke> hi jordi
[06:05] <sabdfl> hey jordi
[06:05] <sabdfl> did you see the flag yet?
[06:05] <jordi> hi mark, thanks for fixing
[06:05] <jordi> in staging?
[06:06] <jordi> nope, just got home from office/lunch
[06:06] <mdke> jordi, we are nearly ready to release some ubuntu documentation for Breezy, we'd like to have it translated in Rosetta, I'll explain more clearly in an email once I've figured out how to do the xml->pot
[06:06] <jordi> mdke: is it in standard sgml like GNOME docs?
[06:06] <Nafallo> jordi: was that review- gajim?
[06:06] <Keybuk> nie_lunch: pong
[06:06] <mdke> jordi, it's written in docbook xml
[06:06] <sabdfl> https://staging.ubuntu.com/products/gnomebaker
[06:06] <jordi> if so, setting it up for gnome-doc-utils should be quite simple
[06:06] <sabdfl> of course, that's wrong for gnomebaker :-)
[06:07] <sabdfl> need a better text than "Rosetta Not Official"
[06:07] <mdke> jordi, i think we used some different utilities for last release, I'll check
[06:07] <carlos> jordi, the review-* templates are a bit hard but I could drive you into that interesting subject as soon as you are ready
[06:07] <BjornT> bradb: well, what exactly do you need the bugtask for?
[06:07] <bradb> BjornT: its canonical url, as mentioned
[06:07] <jordi> mdke: g-d-u is what GNOME used for the release notes for 2.10 and specially for 2.12
[06:07] <jordi> mdke: it's pretty well tested by now
[06:07] <bradb> BjornT: i have to generate various links in these portlets
[06:08] <SteveA> salgado: can you paste up the actual error you get from launchbag.txt ?
[06:08] <jordi> sabdfl: and maybe a better icon too
[06:08] <BjornT> bradb: what kind of links?
[06:08] <bradb> e.g. to the bug page, and to things hanging off the bug page
[06:08] <jordi> it sounds like not being rosetta official is like a Nuclear threat :)
[06:08] <bradb> e.g. in the bug details portlet _Bug #1_
[06:08] <mdke> jordi, ok we can give that a go, do you know where I can start looking?
[06:08] <bradb> links to the bug page
[06:09] <bradb> same with cve refs, watches, web links, subscribers, and all the other objects that these portlets present information about
[06:09] <jordi> mdke: on IRC, #i18n and #docs might be very helpful, on GIMPnet
[06:09] <mdke> ok
[06:09] <jordi> my first tries to google haven't been too successful, but I keep trying
[06:09] <mdke> jordi, i think we used the po-xml tool last time
[06:09] <salgado> SteveA, sure.
[06:10] <carlos> mdke, yeah, the one from KDE
[06:10] <mdke> yes
[06:10] <jordi> sabdfl: so when we get people to use rosetta officially, I ask lp-admins to activate that checkbox?
[06:11] <bradb> BjornT: and these pages might be rendered at URLs that hang directly off the bug page (add attachment, for example), or might be at an arbitrarily deeper level (e.g. edit a CVE ref)
[06:11] <\sh> jordi: people want to use rosetta officially...we have now a small distress with an upstream developer ,-) because their finished .po's are not imported ,-)
[06:11] <bradb> (or edit a subscription, whatever)
[06:11] <bradb> s/these pages/these portlets/
[06:12] <salgado> SteveA, https://chinstrap.ubuntu.com/~dsilvers/paste/filemOc0Kg.html
[06:12] <jordi> mdke: http://asixinformatica.com/blog/?p=4
[06:12] <jordi> mdke: spanish, but should be self explanatory
[06:12] <BjornT> SteveA: you said that you easily could provide a way of getting the nearest IBugTask, right?
[06:12] <mdke> jordi, ok the xml2po thing looks pretty simple, I can generate some pots and have a quick test
[06:12] <SteveA> BjornT: yes
[06:12] <jordi> mdke: yup
[06:12] <SteveA> BjornT: i'll land that as part of my menus work today if you like...
[06:12] <bradb> that'd be great if that can land today
[06:13] <SteveA> salgado: this is an easy test to fix.
[06:13] <BjornT> SteveA: yes, thanks
[06:13] <jordi> mdke: I have this personal goal at work to move our user manual (a huge book in sgml) to use this
[06:13] <BjornT> bradb: ok, so use that when SteveA lands it :)
[06:13] <bradb> that would probably fix this problem, but i didn't know it was ready to land already
[06:13] <bradb> BjornT: right, cool, thanks
[06:13] <mdke> jordi, ok I did this: xml2po -o about-ubuntu.pot about-ubuntu.xml
[06:13] <mdke> looks ok?
[06:13] <jordi> mdke: perfect
[06:14] <jordi> mdke: ok, this is the doc we're looking for
[06:14] <jordi> http://kvota.net/hacks/shaunize/guide.html
[06:14] <mdke> lemme open the new file in an editor
[06:14] <bradb> SteveA: just a note that landing that "nearest" stuff will unblock the URL work
[06:14] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Single line change to allow builddmaster to use its new specific librarian URL. (patch-2372<EMAIL_ADDRESS>[06:14] <SteveA> salgado: in the launchbag.txt test, you need to make the request have a 'response' attribute.  this 'response' attribute needs to have a getCookie(name) method that always returns None.
[06:14] <mdke> jordi, pot file looks ok
[06:14] <jordi> \sh: what's your problem again?
[06:14] <jordi> mdke: GO TRANSLATE! :)
[06:15] <\sh> jordi: we need to import some finished .po files
[06:15] <mdke> jordi, heh
[06:15] <mdke> some more work to do before that
[06:15] <\sh> jordi: before the people from outside starting again to translated already translated stuff
[06:15] <jordi> \sh: nod. what project?
[06:15] <\sh> jordi: gajim
[06:15] <jordi> \sh: oh, I see. It was imported without the translations?
[06:15] <\sh> yes
[06:15] <jordi> bad bad bad. When did this happen?
[06:15] <\sh> jordi: and upstream is not happy about this fact ;)
[06:16] <jordi> we'll fix it in am in
[06:16] <Nafallo> jordi: yesterday
[06:16] <\sh> don't ask me...I just got the bang from upstream ;)
[06:16] <mdke> jordi, do you know if the xml2po thing handles xincludes?
[06:16] <jordi> Nafallo: how did it get imported like that (ie, without all the files)?
[06:16] <jordi> mdke: that's a question for shaunm in #docs I'm afraid
[06:17] <jordi> \sh: k, what branch, 0.8 or head? or both?
[06:17] <Nafallo> jordi: I don't know how all this works, but we had a version in the archives without the mo's installed cause upstream forgot to tell the changelog they installed those in another path.
[06:18] <mdke> jordi, seems to work! :)
[06:18] <\sh> Nafallo: 0.8?
[06:18] <Nafallo> jordi: 0.8
[06:18] <Nafallo> 0.8.2 even
[06:18] <Nafallo> but that's in 0.8 ;-)
[06:18] <jordi> mdke: cool!
[06:18] <jordi> Nafallo: rosetta understands branches, not releases.
[06:19] <jordi> it doesn't make sense to translate releases.
[06:19] <jordi> after they' been relaesed anyway.
[06:19] <\sh> jordi: then put the pos in HEAD
[06:19] <Nafallo> indeed
[06:19] <\sh> jordi: I hope it's only a matter of time, when importing po-files is working oob
[06:19] <Nafallo> that way we are up-to-date for 0.9 :-)
[06:20] <jordi> \sh, Nafallo: we should put the files on the branch that is recommended for translating
[06:20] <jordi> ie, if the new versions will come out from head, we should only import that
[06:21] <mdke> jordi, ok I've made pot files for the about-ubuntu document and our main guide (faq guide), i'd like to test em before putting them into rosetta, have you got any ideas as to how we can do that?
[06:21] <Nafallo> jordi: will we have diffrent "translationbranches" for upstream and packages in breezy?
[06:21] <Nafallo> cause right now those seem to be the same :-/
[06:21] <jordi> mdke: I guess you need to translate it, or at least a portion, try the xml2po conversion back to xml and see if the xml makes any sense.
[06:22] <jordi> if it looks good, import
[06:22] <mdke> k
[06:22] <jordi> Nafallo: you don't want them to be the same?
[06:22] <jordi> carlos: here?
[06:22] <\sh> jordi: hmm...can't we import the stuff from HEAD from their svn?
[06:22] <jordi> \sh: we can
[06:23] <jordi> that's what I suggest actually
[06:23] <Nafallo> jordi: nope, use runs stable, upstream svn head
[06:23] <Nafallo> s/use/breezy/
[06:23] <jordi> Nafallo: I see.
[06:23] <salgado> SteveA, that fixed the problem. thank you. :)
[06:24] <carlos> jordi, yes
[06:24] <SteveA> okay, good
[06:24] <jordi> carlos: https://launchpad.net/distros/ubuntu/breezy/+sources/gajim/+pots/gajim I see this template, which is apparently not attached to any branch. Do we want to keep it?
[06:24] <\sh> Nafallo: I think it doesn't matter to import HEAD .po's. strings which are not used are only taking space but are not a problem at all.../me is not a gettext freak ;)
[06:24] <Nafallo> \sh: we won't have head (0.9) in breezy, right? and if we do we probably could merge from that "open permissions" rosetta branch.
[06:25] <\sh> Nafallo: lets say: we won't update anything anymore for gajim in breezy
[06:25] <Nafallo> jordi: also, right now it's only ubuntu translators that can translate it seems. two branches would solve that, no?
[06:25] <\sh> Nafallo: so we're going for HEAD (aka 0.9 milestone) in anyway...we can branch it here
[06:25] <carlos> jordi, not attached to any branch?
[06:25] <carlos> jordi, what?
[06:26] <\sh> ay...I wanted to talk to jblack anyways
[06:26] <\sh> jblack: ping
[06:27] <Nafallo> jordi: so this will be upstream (head, open permissions) and breezy (0.8/stable, ubuntu translators)? :-)
[06:28] <jordi> (sorry, on the phone)
[06:28] <Nafallo> oki :-)
[06:29] <\sh> Nafallo: sorry dude .. i have to rush into office to do my tax stuff now...will be back in a couple of hours 2 or 3 I think...
[06:30] <Nafallo> \sh: oki, I'll keep translating :-)
[06:30] <\sh> cu later gentlemen
[06:30] <\sh> Nafallo: u rock :=
[06:32] <jordi> back
[06:33] <jordi> carlos: there's no template for 0.8 or head
[06:33] <jordi> but ther'es one for the breezy distro
[06:33] <jordi> carlos: so I don't know if we need to keep all: people are going to randomly translate on breezy or the series if I add pots to the series
[06:34] <jordi> carlos: this is the first time I see this, so I need help to sort it out :)
[06:34] <Nafallo> :-)
[06:35] <Nafallo> jordi: this would be solved ;-)
[06:35] <Nafallo> https://launchpad.net/products/gajim/+translations
[06:35] <Nafallo> on that page it's open permissions to translate
[06:35] <Nafallo> but they get closed when you press a language ;-)
[06:36] <jordi> Nafallo: that's probably because the template belongs to Ubuntu
[06:36] <jordi> let's see what carlos says
[06:36] <carlos> Nafallo, because you are redirected to Ubuntu translations
[06:36] <carlos> Nafallo, look at the URL
[06:37] <Nafallo> carlos: yepp, but upstream would have gajim head with open permissions and breezy stable with closed permissions.
[06:37] <Nafallo> that's how it is supposed to work in my mind anyway ;-)
[06:37] <carlos> Nafallo, and is that a problem?
[06:37] <Nafallo> carlos: whoever can't translate gajim for upstream, so yes.
[06:38] <jordi> Nafallo: for my experience, it's pretty sane to assign projects to Ubuntu translators, though.
[06:39] <Nafallo> jordi: but than my grandmother can't translate it ;-).
[06:39] <jordi> Nafallo: the Catalan translations of the open projects I've seen here or there have random contributions which in many cases make the translation worse. But maybe this is a Catalan-specific issue, because we have a tight set of rules.
[06:39] <jordi> she can join the ubuntu translators :)
[06:39] <salgado> bradb, ping?
[06:39] <bradb> salgado: hi
[06:40] <salgado> yo bradb. have you seen my email re: xx-person-assignedbugs.txt?
[06:40] <Nafallo> jordi: we also have a rules (100 karma and qualitycontrol) so no, she can't :-)
[06:40] <Nafallo> s/a\ /(
[06:40] <Nafallo> baah, just remove the "a " in your mind ;-)
[06:41] <jordi> Nafallo: aha
[06:41] <bradb> salgado: I haven't verified whether or not the warnings are still there, but I removed that method entirely (for a completely unrelated task), so if the thing causing the warnings was restricted to code in that method, then the warning should no longer be happening. You might want to double-check though.
[06:41] <carlos> Nafallo, 100 karma?
[06:42] <Nafallo> carlos: yes.
[06:42] <carlos> Nafallo, then people will stop joining you for a while.... :-P
[06:42] <Nafallo> carlos: ?
[06:42] <carlos> Nafallo, we need to reset all karma to fix a bug I introduced with karma implementation....
[06:42] <Nafallo> gaah!
[06:43] <jordi> Nafallo: dude
[06:43] <jordi> my ZILLIONS of points are going away too
[06:43] <salgado> bradb, okay, I'll check that. ta
[06:43] <carlos> Nafallo, only if they are related to translations
[06:43] <bradb> salgado: no prob, thanks
[06:43] <carlos> Nafallo, the ones from malone will be there
[06:43] <Nafallo> carlos: those 400 are for translating breezy gajim :-P
[06:44] <Nafallo> hmm, so what is the verdict on gajim? open head and closed stable?
[06:45] <carlos> Nafallo, all ubuntu packages will be always closed
[06:45] <carlos> Nafallo, head will be open/closed depending on upstream, it's their project so it's their choose
[06:45] <Nafallo> carlos: yes, and I translated for example bazaar before I was in ubuntu-l10n-se
[06:46] <Nafallo> carlos: not if upstream leads to the breezy one, like it do now
[06:46] <carlos> Nafallo, we started with Rosetta karma only a month ago or so
[06:46] <jordi> Nafallo: ok, all clear. We have to import the stuff, which branch do you want to get translation focus on?
[06:47] <Nafallo> jordi: upstream
[06:47] <jordi> Nafallo: or s/you/upstream/g
[06:47] <Nafallo> jordi: upstream :-)
[06:47] <jordi> Nafallo: there's two upstream: 0.8 branch, or head in svn?
[06:47] <Nafallo> ehm. we should remove that 0.8 branch
[06:47] <jordi> why?
[06:48] <Nafallo> that was me trying to link it to end up in breezy :-P
[06:48] <Nafallo> not the best thing I've done indeed
[06:48] <jordi> Nafallo: oh, heh.
[06:48] <jordi> carlos: can we hide branches?
[06:49] <carlos> jordi, don't think so
[06:49] <carlos> jordi, a branch is not specific to Rosetta
[06:49] <carlos> do please, don't do that
[06:49] <carlos> s/do/so/
[06:49] <jordi> carlos: I can't do anything. What if someone fucks up when adding one?
[06:49] <Nafallo> "0.8 Stable" shouldn't be anywhere ;-)
[06:50] <jordi> there should be a way to cleanup., right?
[06:50] <Nafallo> the 0.8 series are the upstream releases with fixes from head.
[06:51] <Nafallo> like in most projects ;-)
[06:52] <jordi> Nafallo: so it is an existing branch, why delete it?
[06:52] <jordi> Nafallo: should translators translate 0.8.x or HEAD?
[06:53] <jordi> that's all we nee to know right now.
[06:53] <Nafallo> jordi: head
[06:53] <Nafallo> cause 0.8 is unexisting upstream, we could say ;-)
[06:54] <jordi> ok, I guess that's carlos' to decide. I can't get rid of it anyway.
[06:54] <carlos> jordi, ask morgs (when he's back from his holidays)
[06:54] <jordi> carlos: I'll file a bug.
[06:54] <carlos> Nafallo, then we should rename it to any branch that exists
[06:55] <jordi> carlos: what if there isn't any other than head? :)
[06:55] <Nafallo> carlos: there is _one_ branch upstream, head :-)
[06:55] <carlos> jordi, then we should shoot the user that added it....
[06:55] <carlos> :-)
[06:55] <jordi> Nafallo: sorry man
[06:55] <jordi> close your eyes
[06:55] <Nafallo> ouch ;-)
[06:55] <jordi> carlos: now on to a different kind of problem. Do you know if the are problems with tar.bz2 uploads?
[06:56] <carlos> Nafallo, ok, let's just say kick :-)
[06:56] <carlos> jordi, no idea I need to check it
[06:56] <carlos> jordi, is it urgent?
[06:56] <carlos> I have many things to do before leaving tomorrow...
[06:56] <jordi> there's a request on rosetta-users<EMAIL_ADDRESS>[06:57] <jordi> carlos: I think I had problems with tar.bz2 too when importing plone
[06:57] <niemeyer> Keybuk: Was just wondering if there are any docs explaining how to get a package imported into launchpad for a "hct source" command.
[06:57] <carlos> jordi, then try .tar.gz and if there is no bug report, file it, please
[06:57] <jordi> yes
[06:58] <Keybuk> niemeyer: hmm, interesting question
[06:58] <carlos> Keybuk, are those Ubuntu packages?
[06:58] <Keybuk> carlos: are what?
[06:58] <Keybuk> niemeyer: did you manage to get your hct talking to your local trebuchet yet?
[06:58] <niemeyer> Keybuk: Yes
[06:59] <carlos> Keybuk, forget that, I thought Nafallo was asking about translations for the packages handled by hct....
[06:59] <niemeyer> Keybuk: They're not quite "understanding" each other, but certainly talking. :)
[06:59] <Keybuk> niemeyer: not quite understanding, how?
[06:59] <Keybuk> let's debug that first <g>
[06:59] <niemeyer> Keybuk: I think it's working fine.. I just to have any data in launchpad to ask for.
[06:59] <niemeyer> s/to/don't/
[07:00] <Keybuk> right
[07:00] <Keybuk> are you running trebuchet from rocketfuel launchpad, or my sourcerer-production launchpad branch?
[07:00] <niemeyer> rocketfuel
[07:01] <Keybuk> run it from the other one ;)
[07:01] <niemeyer> Keybuk: Couldn't get your branch to work.. got a missing banzai module error. But then, I didn't really get into the problem. Just kept using the rocketfuel launchpad which was already working.
[07:01] <Keybuk> right
[07:02] <Keybuk> hmm
[07:03] <jordi> Nafallo: ok, where do we get the files from?
[07:03] <niemeyer> I'm trying to run bubblewrap.run() by hand to get something imported. Am I way off? :)
[07:03] <jordi> for headf
[07:04] <Keybuk> I'm not even sure whether the rocketfuel code _can_ import something <g>
[07:04] <Nafallo> jordi: http://trac.gajim.org/file/trunk/po/
[07:04] <Nafallo> jordi: and then you could mark RosettaPendingImports after that ;-)
[07:04] <Keybuk> nope, that's pretty much what you do
[07:05] <jordi> Nafallo: I get an error on that url
[07:06] <Nafallo> jordi: http://trac.gajim.org/browser/trunk/po/
[07:06] <jordi> it's cool that you guys use trac
[07:06] <jordi> we use it at lliurex too :)
[07:06] <Nafallo> :-)
[07:07] <jordi> Nafallo: hmm. it's a lot more convenient when you guys provide a tar.gz
[07:07] <jordi> or a svn path to do a checkout
[07:07] <jordi> but downloading the files from trac can take 20 mins
[07:08] <Nafallo> jordi: svn://svn.gajim.org/gajim/trunk gajim
[07:08] <niemeyer> Keybuk: Right.. so rocketfuel code is the wrong way to go. Is this banzai.py missing in the repo, perhaps?
[07:09] <Keybuk> banzai hasn't existed for ages
[07:09] <niemeyer> % baz tree-id
[07:09] <niemeyer><EMAIL_ADDRESS>[07:09] <jordi> Nafallo: actually adding a /po is better for me :)
[07:09] <niemeyer> Keybuk: I'm using that one?
[07:09] <Keybuk> ouch, that's old :p
[07:09] <niemeyer> s/?/.
[07:09] <Nafallo> jordi: I'm not good at svn, sorry ;-)
[07:09] <niemeyer> Keybuk: Oh.. that's actually good. :)
[07:10] <niemeyer> Keybuk: Which one are you working on?
[07:10] <Nafallo> jordi: I'm trying out bzr instead ;-)
[07:10] <Keybuk> you want hct--devel--0.5  (in lib/hct) and sourcerer--devel--0.3 (in lib/sourcerer)
[07:11] <jordi> Nafallo: good :)
[07:12] <Nafallo> jordi: and hmm, I'm not upstream ;-). I just package the thing with \sh :-)
[07:12] <jordi> Nafallo: ok :)
[07:15] <Keybuk> niemeyer: (I'm just getting a launchpad tree myself, I wiped my laptop last week so haven't yet put lp on it again and my desktop is currently doing breezy preview tests <g>)
[07:16] <Nafallo> Keybuk: I should do something like that :-)
[07:16] <niemeyer> Keybuk: :)
[07:17] <niemeyer> Keybuk: Do I need any special database setup or the rocketfuel one is ok?
[07:17] <Keybuk> there are db changes
[07:17] <jordi> Nafallo: ok, should be done now.
[07:19] <niemeyer> Keybuk: That explains the error I just got :))
[07:19] <Keybuk> probably something about ManifestAncestry being missing, or missing hint on ManifestEntry
[07:19] <niemeyer> Keybuk: Do you have a schema patch or should I just wipe it out and recreate?
[07:20] <Nafallo> jordi: after a cron or something?
[07:20] <Keybuk> it's patch*mumble*26*mumble* I think
[07:20] <Keybuk> you should be able to just python database/schema/upgrade.py
[07:20] <Keybuk> and have it dtrt
[07:20] <Keybuk> it's stub-approved, but the code depends on hct functionality that's not in the rf branch
[07:20] <Keybuk> so I haven't submitted the merge yet
[07:21] <jordi> Nafallo: a few mins I guess
[07:21] <jordi> Nafallo: or should
[07:22] <Nafallo> jordi: I'll just keep refreshing then ;-)
[07:23] <niemeyer> Keybuk: Cool! Seems to be working fine
[07:25] <Keybuk> so, Importing A Package 101
[07:25] <Keybuk> first you need stuff in the database to import
[07:25] <lifeless> how does one unsubscribe from a bug in HEAD
[07:25] <Keybuk> you need a SourcePackageRelease record which is ready
[07:25] <Keybuk> or, to put it simply, the database already needs to know about "simple 1.0 published in ubuntu/breezy"
[07:26] <niemeyer> Right
[07:26] <niemeyer> I have some entries in that table indeed.
[07:26] <Keybuk> now, this will have an equivalent URL
[07:26] <Keybuk> if you know the record id, you can cheat and do something like:
[07:27] <Keybuk> >>> from canonical.launchpad.hctapi import where_am
[07:28] <niemeyer> _i
[07:28] <niemeyer> :)
[07:28] <Keybuk> >>> where_am_i(SourcePackageRelease.get(1))
[07:28] <Keybuk> u'lp:///distros/ubuntu/mozilla-firefox/0.9'
[07:29] <niemeyer> >>> from canonical.launchpad.database import *
[07:29] <niemeyer> >>> where_am_i(SourcePackageRelease.get(1))
[07:29] <niemeyer> Traceback (most recent call last):
[07:29] <niemeyer> AttributeError: 'NullCache' object has no attribute 'get'
[07:29] <niemeyer> >>>
[07:29] <niemeyer> I'm missing the db initialization
[07:30] <Keybuk> PYTHONPATH=lib python -i lib/canonical/database/harness.py
[07:30] <Keybuk> is what I tend to do
[07:30] <Keybuk> (in launchpad)
[07:31] <niemeyer> Got it working with
[07:31] <niemeyer> >>> from canonical import lp
[07:31] <niemeyer> >>> lp.initZopeless()
[07:31] <niemeyer> Next time will follow your suggestion
[07:31] <Keybuk> try .get(14) too, don't think there is an id=1
[07:31] <niemeyer> >>> where_am_i(SourcePackageRelease.get(14))
[07:31] <niemeyer> u'lp:///distros/ubuntu/mozilla-firefox/0.9'
[07:31] <Kinnison> Keybuk: cd lib/canonical/database ; python -i harness.py
[07:31] <niemeyer> Works
[07:31] <Kinnison> Keybuk: then there's no need for PYTHONPATH=
[07:31] <niemeyer> Keybuk: Nice!
[07:34] <Keybuk> ok, so that gives the url bubblewrap needs to import this
[07:35] <Keybuk> you'll also need a destination baz archive
[07:35] <Keybuk> and a directory with some source files in it
[07:36] <niemeyer> Keybuk: Ok, got both of them
[07:36] <niemeyer> Keybuk: I suppose they don't have to be the dsc of mozilla-firefox, for testing purposes.
[07:36] <Keybuk> >>> sourcerer.bubblewrap.run( [ "simple_1.0-1.dsc", "simple_1.0-1.diff.gz", "simple_1.0.orig.tar.gz" ]<EMAIL_ADDRESS>"lp:///distros/ubuntu/simple/1.0-1", logging.getLogger(), "path/to/sources")
[07:36] <Keybuk> right
[07:36] <jordi> carlos: is there a backlog of imports?
[07:37] <carlos> jordi, yes
[07:37] <jordi> carlos: oh, ok. Any estimation on when that should be cleared?
[07:37] <carlos> jordi, btw, subscribe to<EMAIL_ADDRESS>if you want to see the logs of the imports/attachments
[07:38] <jordi> carlos: high traffic I assu,e
[07:38] <carlos> jordi, I have 100 .po files pending to be imported, but I think it's related to bugs on our code related to broken files, I need to review them. Anyway, it should not block any other imports... just delay them a bit
[07:38] <carlos> jordi, yeah
[07:38] <jordi> delay them how much?
[07:39] <jordi> I want to give an estimation to people
[07:39] <carlos> jordi, don't know, an hour or so
[07:39] <jordi> oh, just that
[07:39] <carlos> jordi, my next task will be to reduce the big log output fixing bugs
[07:39] <jordi> nod
[07:43] <Nafallo> will we ever be able to translate launchpad through rosetta? :-)
[07:43] <niemeyer> Keybuk: Almost worked: hct.backends.xmlfiles.XmlFilesError: This backend does not allow manifest creation.
[07:43] <niemeyer> Keybuk: I should have registered the lp backend, I suppose
[07:45] <Keybuk> odd
[07:45] <Keybuk> oh, wait; I thought sourcerer.bubblewrap did that -- but it's the sourcerer-import script that does not
[07:45] <Keybuk> yeah
[07:45] <Keybuk> before that command ... from canonical.launchpad import hctapi
[07:45] <Keybuk> (that'll automatically register it)
[07:46] <Keybuk> s/not$/now/
[07:48] <jordi> Nafallo_: yes, sooner or later launchpad will be i18n'ed
[07:48] <Nafallo> jordi: yay :-)
[07:48] <carlos> jordi, there is a spec about that already
[07:49] <carlos> https://wiki.launchpad.canonical.com/LaunchpadI18n
[07:49] <jordi> carlos: I remember it :)
[07:50] <jordi> carlos: to fix this: https://launchpad.net/malone/bugs/2042 what is the best approach?
[07:51] <carlos> jordi, some Dutch translator should do the merge by hand (exporting the .po files and doing it outside Rosetta)
[07:51] <carlos> jordi, after that import the new .po file
[07:52] <carlos> and ask stuart to remove it, but I will do that part, request me the removal and I will give stuart the exact sql query to get those POFiles
[07:52] <jordi> ok
[07:53] <jordi> abiword has a hell lot of silly translations goin on
[07:53] <jordi> :(
[07:53] <carlos> jordi, abiword is a bit broken, yes. It's old so it has all problems we had when we started...
[07:53] <jordi> feh :(
[07:56] <jordi> ok, replied on malone
[07:56] <jordi> carlos: should I subscribe you to that bug too?
[07:57] <jordi> damn lp is slow today
[07:57] <carlos> jordi,  by default, subscribe me and daf to any Rosetta bug you touch, please
[07:57] <jordi> ok.
[07:57] <carlos> hmmm
[07:58] <carlos> or at least me until daf is back
[07:58] <jordi> k
[07:58] <carlos> not sure if he will be able to handle the amount of pending email he has...
[07:58] <niemeyer> Keybuk: I'm trying to figure out that one: LaunchpadError: Source package release '0.9' not found in URL: 'lp:///distros/ubuntu/mozilla-firefox/0.9'
[07:58] <niemeyer> It really looks to be in the database
[07:59] <Keybuk> oh, yeah, there's a general problem with that url lookup code :(
[07:59] <Keybuk> you'll probably find that it's not _published_ or something
[07:59] <Keybuk> bad sampledata
[08:08] <jbailey> What's the best way to customise what malone sends me by email?
[08:09] <Nafallo> jbailey: procmail? ;-)
[08:10] <jbailey> Ah, it's not that far yet? =)
[08:11] <Keybuk> niemeyer: pick an SPR other than 14 and keep trying until it works <g>
[08:11] <Nafallo> I dunno. I just tried to be fun ;-)
[08:11] <jbailey> Nafallo: Ah. =)
[08:11] <jbailey> That *might* still be the answer. =)
[08:11] <Nafallo> hehe
[08:14] <bradb> jbailey: No way to customize, atm. But just so we some ideas, what kinds of things do you want to customize?
[08:15] <jbailey> bradb: The first is that now that I've merged my accounts, it's sending to the wrong email address. =)
[08:16] <jbailey> bradb: But in generally, I usually have bugzilla setup to not email on things that are assigned to me.  When I have time, I go and I look at the list based on modification date and use the ones that are newer than that.
[08:16] <jbailey> bradb: So I ask it to email me when I've been cc:'d and such, or if it's a bug I filed.
[08:16] <bradb> jbailey: The emails are sent to your "preferred" email address. Do you want to be able to have a "preferred" email address but send bugmail somewhere else?
[08:16] <jbailey> Hmm.
[08:16] <jbailey> I thought I had set that to the @ubuntu.com, but maybe that was before I merged them.
[08:18] <niemeyer> Keybuk: Weird.. it looks like it *is* published..
[08:18] <jbailey> Hmm, must've been before, sorry about the noise.
[08:18] <niemeyer> # select status from securesourcepackagepublishinghistory where sourcepackagerelease=14;
[08:18] <bradb> Right, I'll file a bug on the points you've mentioned so far about email customization. It may be a little while off, to be honest, but at least it won't be forgotten if a bug is filed.
[08:18] <niemeyer>  status
[08:18] <niemeyer> --------
[08:18] <niemeyer>       2
[08:18] <lifeless> niemeyer: do you have space for ddaa to visit for a week just before UBZ ?
[08:19] <Keybuk> niemeyer: odd; the source/version stuff is broken though
[08:19] <niemeyer> lifeless: Visit me? Certainly
[08:20] <lifeless> niemeyer: cool.
[08:20] <jbailey> bradb: Thatnks, I appreciate it.  I just get a point where I get too many bugmails so I stop reading them, so my biggest concern is how to keep them relevant.  Either by priority, or working through lists or something like that.
[08:20] <ddaa> Apparently I'm supposed to make you drink decoctions of my spinal fluid or something to get you up to speed with launchpaddy things I'm figuring out right now.
[08:21] <niemeyer> ddaa: :))
[08:21] <niemeyer> Keybuk: Nice table name, btw :))
[08:21] <lifeless> niemeyer: we're thinking that you'll move onto bzr for a few weeks after the sprint.
[08:21] <Keybuk> niemeyer: which one?
[08:22] <niemeyer> Keybuk: securesourcepackagepublishinghistory
[08:22] <Keybuk> "secure" ?!
[08:22] <Keybuk> that isn't my stuff, that's all Kinnison's faulty
[08:23] <lifeless> niemeyer: and then just before ubz spend time with ddaa in brazil...
[08:23] <niemeyer> lifeless: Excellent! I enjoy SCM related code.
[08:23] <bradb> jbailey: Cc'd you on #2145 ;)
[08:23] <Kinnison> niemeyer: SecureSourcePackagePublishingHistory thankyouverymuch
[08:23] <lifeless> niemeyer: good :)
[08:23] <Kinnison> Keybuk: and s'not faulty (much)
[08:23] <ddaa> niemeyer: what about code that deals with 3 (three!!) scm at the same time?
[08:23] <lifeless> night all
[08:23] <Keybuk> Kinnison: all of that stuff, you get the blame and credit for
[08:23] <niemeyer> lifeless: Sounds great. We don't have a lot of space here, but the office is in much better shape now, and ddaa will certainly survive. :)
[08:24] <lifeless> :)
[08:24] <ddaa> niemeyer: I'm looking for someone foolish enough to accept taking it over :)
[08:24] <Kinnison> ciao all
[08:24] <lifeless> tchau
[08:24] <niemeyer> Kinnison: ;)
[08:25] <jbailey> bradb: Lol.  Is there a way to see the list of things I'm interested in?
[08:25] <jbailey> The "assigned to me" doesn't have ones that I'm cc:'d on
[08:25] <bradb> jbailey: right, not yet
[08:25] <bradb> but somebody else mentioned that the other day too
[08:25] <bradb> maybe I can wip up a report right now, while blocked on SteveA for something
[08:25] <niemeyer> ddaa: Humm... perhaps three at the same time would exceed my expectations. :)
[08:25] <bradb> whip, even
[08:26] <bradb> jbailey: What if you had a "Bugs I'm Interested In" link from your people page?
[08:26] <jbailey> bradb: Lovely.    I don't know that my usages are normal, though. =)
[08:26] <jbailey> bradb: That would be lovely, except that with Bugzilla's version of that "My Bugs" it also includes bugs that I filed, which is a totally different frame of mind for me than ones I'm solving.
[08:28] <bradb> jbailey: we already have a link for bugs you reported anyway
[08:32] <bradb> jbailey: BTW, what bugs are you "interested in", exactly?
[08:35] <jbailey> bradb: Is it useful to talk in terms of how I work with bugzilla?
[08:36] <bradb> Sure. I remember when you showed me that canned query of "most recently changed bugs", etc. but I'm curious to learn more about exactly what bugs "interest" you, to make this report as useful as possible
[08:39] <carlos> mpt, hi, around?
[08:39] <jbailey> bradb: I guess my "interested" bugs varies by the moment on what I want to work on.  The queries that I do now are "My Bugs for Ubuntu 5.04", "My Bugs for Ubuntu 5.10". That's the list that's assigned to me or that I'm in the Cc: list for.
[08:39] <bradb> jbailey: right, that's what i would have guessed
[08:39] <jbailey> The 5.04 one only shows bugs that are targetted at 5.04, the 5.10 shows 5.10 targetted and unassigned.
[08:40] <jbailey> I also have a 'My RC Bugs', which is any bug of seerity Maj or above with me in the assigned or cc list.
[08:43] <bradb> jbailey: ok, i think i have some ideas for how we can improve this for you, but i won't promise that i'll be able to finish it today (working on some high-priority URL demolition atm), but i'll see what i can do
[08:44] <Keybuk> niemeyer: having any further luck?
[08:44] <niemeyer> Keybuk: Yes, imported the package fine
[08:44] <jbailey> bradb: I'm just happy knowing it's in the queue.  I'll be more anxious once all of our bugs are in there.
[08:44] <Keybuk> niemeyer: did it save it into the database ok?
[08:44] <niemeyer> Keybuk: But 'hct source' still doesn't work
[08:44] <SteveA> re
[08:44] <niemeyer> Keybuk: Yes, the manifest is there
[08:44] <Keybuk> check the SourcePackageRelease record you saved it to
[08:45] <Keybuk> is the manifest attribute set to the id of the manifst record?
[08:45] <bradb> SteveA: hi. do you have a "nearest" ETA?
[08:45] <niemeyer> Keybuk: hctapi.get_manifest("/distros/ubuntu/pmount/0.1-2") works correctly
[08:45] <Keybuk> right
[08:45] <Keybuk> so try this
[08:45] <Keybuk> hct source hct://localhost/distros/ubuntu/pmount/0.1-2
[08:45] <jbailey> bradb: Do you know when the great bugzilla off'ing is targetted for?
[08:45] <niemeyer> Doesn't work, for another reason
[08:45] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Finished and registered architecture icon (bug 1840); vanquished use of plone.org resources (bug 275); nuked ul-main-template.pt (patch-2373<EMAIL_ADDRESS>[08:46] <Keybuk> what's the other reason? :-/
[08:46] <niemeyer> Keybuk: ERROR:  permission denied for relation vsourcepackageindistro
[08:46] <Keybuk> ah
[08:46] <niemeyer> Trying to figure that out now
[08:46] <Keybuk> python database/schema/security.py
[08:46] <Keybuk> (that doesn't get run by upgrade.py *sigh*)
[08:46] <niemeyer> Oh! :)
[08:47] <bradb> jbailey: Not yet, because I can't make that call. If I could, it would happen right after my URL changes land. It'll be a pain rolling out a brand new BTS for power-user debbugs/Bugzilla guys no matter what, so the sooner we can get feedback from you guys the sooner we can get you feeling fuzzy, IMHO.
[08:50] <jbailey> Keybuk: I'm thinking of filing a wishlist against get-source such that when using apt, it makes the directory as package/package so that it's consistant with hct source.  Any objections?
[08:50] <Keybuk> jbailey: none at all
[08:50] <Keybuk> you could file the bug the other way too <g>
[08:51] <Keybuk> (hct source gives you source-ver [assembled tree] )
[08:51] <jbailey> Keybuk: No, I acutally like it that way.
[08:51] <jbailey> I usually put everything in a subdirectory named the package anyway so that I can rm -rf the parent and get allof the build cruft gone, too.
[08:51] <Keybuk> oh, ok
[08:51] <Keybuk> yeah, I do that too
[08:52] <Keybuk> I don't like the "+assembled" bit though :-/
[08:52] <jbailey> I haven't figured out what that's for yet. =)
[08:52] <Keybuk> that's the source package itself
[08:52] <Keybuk> if you look in there, you'll see the assembled source with the patches and stuff
[08:53] <SteveA> bradb: it already exists
[08:53] <SteveA> bradb: from canonical.launchpad.webapp import nearest
[08:53] <SteveA> bradb: nearest(obj, IFoo, IBar, IBaz)
[08:53] <SteveA> bradb: returns None if there is no object on the url chain that provides one of the interfaces.  Otherwise, returns the object.
[08:54] <bradb> ok, I guess I can hack it into a view method for now, but I thought that the patch you were referring to earlier (to BjornT) would make it work cleanly in ZPT
[08:55] <niemeyer> Keybuk: Still no luck.. would you have a different security.cfg?
[08:55] <Keybuk> ( example/example-1.0 is actually not the source package, it's the contents of the diff.gz with the debian directory taken out )
[08:55] <SteveA> i can do such a thing, but i'd like to see it in use from a view class first.
[08:56] <bradb> SteveA: ok
[08:56] <jbailey> Keybuk: I'm using initramfs-tools as an example, I don't see a -version directory in there.
[08:56] <Keybuk> niemeyer: make sure you're in my lp branch and try python database/schema/security.py -d launchpad_dev
[08:56] <Keybuk> (it might need that extra args)
[08:56] <Keybuk> jbailey: ah, no, that's a native so you woudln't
[08:58] <jbailey> =)
[08:58] <niemeyer> Keybuk: "make sure you're in my lp branch".. my fault.
[08:59] <Keybuk> I'm very sure this will be a HOT TOPIC next week
[08:59] <Keybuk> "why do you have unmerged changes AGAIN!?$(*(&"
[08:59] <Keybuk> :p
[09:00] <niemeyer> :)
[09:00] <niemeyer> Keybuk: It works! It works!
[09:00] <niemeyer> :)
[09:01] <Keybuk> the reason is that hctapi needs the hct code that supports ManifestAncestry; but that code drags in lots of other code which has bugs that cause lp test cases to fail
[09:01] <Keybuk> and my first priority is "get the distro team using it" at the moment
[09:02] <niemeyer> Keybuk: I confess I'm a bit terrified about how the manifest spreads all around the database, but I'll certainly get over it. :)
[09:03] <Keybuk> there are a few places that link to them
[09:03] <Keybuk> never the same record though
[09:04] <jbailey> Keybuk: Phear.  Does hct know about glibc's dpatches?
[09:04] <jbailey> Or is it just pulling debian/ one at a time?
[09:05] <niemeyer> Keybuk: I think there's a minor here: % hct source hct://localhost/distros/ubuntu/pmount/0.1-2
[09:05] <niemeyer> Source directory: /tmp/0
[09:05] <Keybuk> glibc isn't in the list
[09:05] <Keybuk> (I don't think)
[09:05] <niemeyer> Look at the source directory name
[09:05] <Keybuk> niemeyer: yeah *chuckle* that's quite a way down the priority list, but it is a bug
[09:05] <Keybuk> I haven't taught the distro people that they can do more than just "hct source PACKAGENAME" yet, so I'm ignoring it <g>
[09:05] <niemeyer> ;)
[09:06] <Keybuk> fix is to return more than just the manifest from the database, and include information about _WHAT_ you just grabbed
[09:06] <jbailey> Keybuk: I thought it was.  It's certainly not using apt.
[09:06] <Keybuk> like the source package name, version, description, etc.
[09:07] <mdke> jordi, in here
[09:07] <jbailey> apt would've been done a long time ago, this is quite slow.
[09:07] <Keybuk> jbailey: oh, might be then.  are they separated out?
[09:07] <carlos> salgado, is kiko near you?
[09:07] <jbailey> Keybuk: I think it's jsut listing each file that it's fetching.
[09:07] <niemeyer> Keybuk: Got it
[09:08] <Keybuk> jbailey: it is
[09:08] <jordi> mdke?
[09:08] <Keybuk> niemeyer: you can also do hct soucre hct://.../pmount/0.1-2 pmount
[09:08] <Keybuk> (ie. give the directory name)
[09:09] <jbailey> Keybuk: Mmm at this rate, I'm not sure it will finish today.  Is this expected?
[09:10] <mdke> jordi, i wanted to ask, where abouts in rosetta will the pots be uploaded?
[09:11] <niemeyer> Keybuk: Just discovered the new --packaging-- concept. Nice idea as well
[09:11] <Keybuk> jbailey: baz is slow, news at 10
[09:11] <niemeyer> Keybuk: (new to me, at least :)
[09:11] <Keybuk> niemeyer: debian directories are separated out ... in theory this makes them swappable quite easily
[09:12] <carlos> mdke, jordi at /distros/ubuntu/breezy/+sources/ubuntu-docs/
[09:12] <Keybuk> it also means we can move "debian" one directory up so all the dpkg-dev tools still work <g>
[09:12] <niemeyer> Keybuk: Yeah.. makes a lot of sense
[09:12] <Keybuk> (ie anyone can do "dch -i" anywhere in a HCT source tree, and have it do the right thing)
[09:12] <carlos> jordi, for those .pot files we will do an exception and will do manual uploads
[09:12] <jordi> carlos: ie, I need to do it?
[09:12] <Keybuk> jbailey: right now, glibc is "too big"
[09:12] <mdke> carlos, thanks for that
[09:12] <niemeyer> Keybuk: And may also version-manage control information without fiddling with the package itself.
[09:13] <Keybuk> the funny thing is that baz is spending all of its time moving things out of the revision library there
[09:13] <carlos> jordi, if there is not such potemplate, yes
[09:13] <jbailey> Keybuk: Are is there a certain size threshold at which point it starts to suck hard?
[09:13] <Keybuk> niemeyer: yup
[09:13] <carlos> hmmm
[09:13] <Keybuk> jbailey: dunno, only just got a good set of imports to start measuring things <g>
[09:14] <carlos> jordi, mdke why is there an upstream product called ubuntu-docs?
[09:14] <jordi> carlos: is ubuntu-docs the gettext domain?
[09:14] <mdke> carlos, i don't know
[09:14] <carlos> jordi, no, they have three templates
[09:14] <carlos> jordi, it's the source package where the documentation is stored
[09:14] <jordi> ok
[09:15] <mdke> --> food, brb
[09:15] <jordi> mdke: ok, ping me later to get that done
[09:15] <carlos> jordi, just look at hoary's package
[09:16] <jbailey> Keybuk: Assuming this actually gets around to finishing, will it be faster for working with after each update?
[09:16] <Keybuk> jbailey: not really, the speed problem seems to be revlib related
[09:16] <Keybuk> I haven't debugged it yet
[09:16] <Keybuk> 1) get it working, 2) get it working FAST

[09:17] <jbailey> Keybuk: That's fair.  Just if it's not likely to be faster after iterations, then I can cheerfully not use this with glibc for now. =)
[09:17] <Keybuk> yup
[09:17] <jbailey> If it were just one time pain, I'd suffer for you. =)
[09:18] <Keybuk> theoretically every patch is just one changeset away from what you have in the revlib
[09:18] <Keybuk> so I don't understand why baz takes a metric week to do it
[09:18] <Keybuk> it even makes sure you have a properly configured revlib <g>
[09:19] <jbailey> Hmm.  Does it try to do something special with the files in debian/patches/*dpatch?
[09:19] <jbailey> or for now does it just load them in?
[09:19] <jbailey> You showed me cleverness at UDU, but I'm not sure how much of it was fuzzy demo. =)
[09:19] <Keybuk> define "special" ?
[09:20] <Keybuk> how much chest-thumping are we talking about?
[09:20] <jbailey> Like, just it autoamtically know them as patches and create different things that I can assemble based on them?
[09:20] <Keybuk> it knows they're patches
[09:20] <Keybuk> so you should get a branch for them
[09:20] <Keybuk> however it doesn't know they're not _JUST_ patches
[09:20] <Keybuk> so assemble makes patches, rather than dpatches
[09:21] <Keybuk> (ie. the bit at the top is missing)
[09:21] <jbailey> Okay, so the metadata at the top is.. yeah. =)
[09:21] <jbailey> How does it guess the -p level, --dry-run and iteratae?
[09:21] <Keybuk> iterate
[09:21] <Keybuk> without --dry-run, because otherwise you can't get stacked patches
[09:21] <Keybuk> sourcerer does that
[09:21] <Keybuk> and it's stored in the manifest
[09:21] <Keybuk> (the dirname bit)
[09:21] <jbailey> Hmm.
[09:22] <jbailey> How does this handle arch-specific patches?  (like 00list.hurd-i386, etc)
[09:22] <Keybuk> it doesn't need to handle them, does it?
[09:22] <Keybuk> it makes a branch available for every patch
[09:22] <Keybuk> it's up to your debian/rules file to pick which ones get applied
[09:22] <Keybuk> assemble puts them back in debian/patches, it doesn't apply them
[09:22] <jbailey> Mmm.  But some patches will rely on previous ones to be applied.
[09:23] <Keybuk> yes
[09:23] <jbailey> So it would have to know what order to apply them in to get a tree at a given point.
[09:23] <Keybuk> it detects that
[09:23] <Keybuk> it's quite clever
[09:23] <jbailey> It must be.
[09:23] <Keybuk> if the patch doesn't apply to the diff, it tries to apply it to other patches
[09:24] <jbailey> Ahahah,  So you have this massive explosion of it trying to figure what to apply where?
[09:24] <Keybuk> yup
[09:24] <Keybuk> it's the bulk of the import time, in fact
[09:24] <jbailey> No wonder you thought that glibc was probably 'too big'
[09:24] <jbailey> I think we carry 100 patches in that directory.
[09:24] <Keybuk> shadow is funnier
[09:24] <Keybuk> they have a patch for every translation update
[09:24] <jbailey> Ahaha
[09:24] <jbailey> Phear
[09:25] <Keybuk> the theory is that we'll have BIG HARDWARE doing all this
[09:25] <jbailey> So, erm, once you have hct commit, what's the best thing to do then?
[09:25] <Keybuk> so the end result is peachy and just right
[09:25] <Keybuk> "best thing to do" ? for ?
[09:25] <jbailey> Is there a preferred patch format and some metadata to help with this?
[09:25] <Keybuk> help with what?
[09:26] <Keybuk> oh, reducing the time to import?
[09:26] <Keybuk> once it's done one import, it already generally knows the answer
[09:27] <Keybuk> but as that's an import-time cost, it's not hugely worrysome
[09:27] <jbailey> Right, and I guess the idea is that an import should happen once and then all further updates are through hct?
[09:27] <Keybuk> yu
[09:27] <Keybuk> you got it
[09:27] <jbailey> Hmm.
[09:27] <Keybuk> we'll keep on importing for Debian and RedHat
[09:28] <Keybuk> but the dream is that we won't need to import for Ubuntu, because all uploads will be done from hct and not dupload/dput
[09:28] <jbailey> rpm imports, phear.
[09:28] <Keybuk> no, don't fear the rpm imports
[09:28] <Keybuk> fear the gentoo/portage ones
[09:28] <jbailey> I don't know the portage source format at all.
[09:28] <jordi> carlos: do you hae time to look at why zwiki isn't getting imported?
[09:28] <Keybuk> me neither
[09:28] <jbailey> *g*
[09:28] <Keybuk> that's what we hired nathaniel to do
[09:28] <Keybuk> (originally)
[09:29] <carlos> jordi, let me check...
[09:29] <jbailey> Keybuk: Will there eventually be a preferred way to associate metadata with each patch?
[09:29] <jordi> carlos: also, have a look at the "Po download broken" email in the mailing list
[09:29] <jordi> seems serious
[09:30] <Keybuk> jbailey: well, you already do <g>
[09:30] <Keybuk> when you do "hct patch new-patch-filename", if you want to associate a parent with it, you do "hct patch parent-filename new-patch-filename"
[09:30] <Keybuk> so it's all there in the way you build your branches
[09:30] <niemeyer> Keybuk: I belive it shouldn't be hard to parse the rules file and try to guess a certain order, falling back to the current behavior if all else fails.
[09:31] <Keybuk> niemeyer: it's harder than just trying it
[09:31] <niemeyer> Keybuk: Sure, but speed-wise..
[09:32] <niemeyer> Keybuk: Using it just as a hint, I mean.. not really replacing the current behavior.
[09:34] <carlos> jordi, did you upload all .po files?
[09:35] <jbailey> Keybuk: Ah, cool.  What format will that generate the patch in?
[09:36] <Keybuk> niemeyer: 95% of packages apply the patches in asciibetical order to the diff (possibly depending on a previously applied patch)
[09:36] <niemeyer> jbailey: I think the same format.. the difference is the patch ancestry.
[09:36] <Keybuk> so we try them like that by default
[09:37] <niemeyer> Keybuk: So the feature is already there. Understood.
[09:37] <jbailey> niemeyer: Ah cool, so we won't get a third in dpatch, a third in quilt and a third in simple-patchsys. =)
[09:37] <Keybuk> jbailey: patch at the moment, I was hoping someone who understands dpatch (WELL VOLUNTEERED) would teach me about it <g>
[09:37] <jbailey> in glibc we don't use the standard shell bits at the top of dpatch.
[09:37] <jbailey> So that's part of why I'm wondering. =)
[09:38] <Keybuk> the "format" of the output and stuff is stored in the manifest
[09:38] <jordi> carlos: I think I did, yes.
[09:38] <carlos> jordi, I don't see anything in the logs...
[09:39] <jbailey> Keybuk: What we really need is W&P.
[09:39] <jbailey> Hmm.
[09:39] <Keybuk> yes
[09:39] <carlos> will try to take a look tomorrow... but I'm not sure I will be able to fix it before I leave...
[09:39] <jbailey> I wonder how W&P copes with per-arch patches. =)
[09:39] <Keybuk> at some point, in my copious free time, I'll get around to finishing W&P
[09:39] <carlos> jordi, could you send me the .pot and the .po files to me?
[09:39] <jbailey> I thougt you said it already was in?
[09:39] <Keybuk> jbailey: it tells you to stop being annoying and use #ifdef like normal people <g>
[09:39] <carlos> something is wrong there...
[09:39] <Keybuk> unpack, yes; pack/build, no
[09:39] <carlos> jordi, did you checked that the .pot file is not broken?
[09:40] <jbailey> Doesn't much matter until the rest of the archive can cope with it anyway.
[09:40] <jbailey> Or does lp have those bits in it already?
[09:40] <Keybuk> nope
[09:40] <Keybuk> even sourcerer can't import W&P packages yet <g>
[09:40] <jordi> carlos: I didn't do the wxwidgets import, this is prior to my arrival I think
[09:40] <niemeyer> Keybuk: What is W&P?
[09:40] <jbailey> So it's a strong case of "not soon" then.
[09:41] <Keybuk> niemeyer: Wig And Pen ... a new dpkg source format
[09:41] <carlos> jordi, zwiki dude....
[09:41] <niemeyer> Ahh, right
[09:42] <niemeyer> Keybuk: Anything available about it?
[09:42] <carlos> jordi, btw, the export problem is because he copied & paste the point we use as space char....
[09:42] <Keybuk> http://www.dpkg.org/NewSourceFormat
[09:42] <niemeyer> Thanks
[09:42] <carlos> jordi, I did a fix for that, it should be fixed soon. I will try to answer tomorrow after reviewing all the errors he gets
[09:42] <jordi> carlos: eek
[09:43] <carlos> jordi, we are going to change it automatically so we don't store it ever
[09:43] <jordi> carlos: ah, I was preparing another upload of that tarball
[09:43] <jordi> should I not do it?
[09:43] <carlos> even when the user pastes it
[09:43] <carlos> jordi, do it
[09:43] <jordi> carlos: what po file had that error?
[09:43] <jordi> I had to fix fi, es and ja, they had errors
[09:44] <carlos> jordi, hmmm, it's another character....
[09:44] <jordi> these errors were uninitialised po headers
[09:44] <carlos> jordi, the fi.po file has a character that it's not a valid latin1 character but the .po header has that encoding so the export fails
[09:45] <carlos> jordi, are they from upstream?
[09:45] <jordi> carlos: yes
[09:45] <jordi> fi.po:    ASCII PO (gettext message catalogue) text
[09:45] <carlos> jordi, the ones that requested you the upload
[09:45] <jordi> I get this. Are you sure?
[09:45] <carlos> jordi, dude, you are mixing issues
[09:45] <jordi> I think he is, yes.
[09:45] <carlos> jordi, 1.- Zwiki is not being imported
[09:45] <carlos> 2.- Someone complains because is not able to download files
[09:46] <carlos> 2.- Is due problems with the encoding and broken files, does not seems to be a general problem
[09:46] <jordi> carlos: yeah. So 1) is zwiki. 2) is on the mailing list, about wxwidgets
[09:46] <carlos> 1.- I don't have a clue about that
[09:47] <niemeyer> Keybuk: I've got the general idea of hct and sourcerer. We don't have much time left before the sprint, but even then, do you have any issue you'd like to delegate to me so that I may look more carefully into a certain direction?
[09:47] <jordi> carlos: how do we fix 2?
[09:47] <carlos> jordi, I don't see any reference to wxwidgets...
[09:47] <Keybuk> niemeyer: I think it might be cute to get you to get the RPM importer working
[09:47] <carlos> jordi, he just complains that he's not able to download anything...
[09:47] <carlos> what am I missing?
[09:47] <Keybuk> it should teach you lots about how things work too
[09:48] <jordi> oh, sorry.
[09:48] <jordi> So he is replying to a thrad about wxwidgets
[09:48] <jordi> but has nothing to do with this
[09:48] <jordi> sorry, my bad (and he is silly too)
[09:48] <niemeyer> Keybuk: Right.. I've already looked quickly into that already. Will work on it
[09:48] <niemeyer> s/already././ :)
[09:48] <jordi> carlos: ok, should I mail him back to ask for details?
[09:48] <Keybuk> niemeyer: basically sourcerer/debian.py is the Debian importer, and sourcerer/upstream.py is the plain-old-Upstream importer
[09:48] <jordi> ie, what file exactly he can't download
[09:48] <carlos> jordi, anyway, we get the error emails
[09:49] <carlos> jordi, so it's easy to check the problems
[09:49] <Keybuk> the RPM code looks nothing like them because it predates this version of sourcerer by a long way
[09:49] <carlos> jordi, you should be subscribed to the error mailing list....
[09:49] <niemeyer> Keybuk: I noticed that _specparser.c expects a new version of rpm
[09:49] <Keybuk> so you'd probably have to write an all new sourcerer/rpm.py based on the existing one, but taking interesting code from the rpm one
[09:49] <carlos> jordi, he tried some of them
[09:49] <niemeyer> Keybuk: (including rpmts.h)
[09:49] <carlos> jordi, and the errors he has are related to the errors I'm fixing this week
[09:49] <carlos> so...
[09:49] <niemeyer> Keybuk: Ahh, ok
[09:49] <niemeyer> Keybuk: So the idea is starting all over again
[09:50] <niemeyer> Keybuk: Reusing bits when possible
[09:50] <jordi> carlos: I'll subscribe.
[09:50] <jordi> sigh
[09:50] <jordi> buried under email :(
[09:50] <jordi> carlos: I'll tell him that
[09:50] <Keybuk> niemeyer: I think so, the old code is just waayyyy too old I expect
[09:50] <jordi> carlos: will the fix be on Tuesday's update?
[09:50] <Keybuk> you pick
[09:51] <carlos> jordi, no, wait don't tell him anything yet
[09:51] <carlos> jordi, I will do it tomorrow
[09:51] <carlos> as I will know if all is fixed
[09:51] <niemeyer> Keybuk: Right. Thanks for all the information you provided today.
[09:51] <jordi> carlos: good.
[09:52] <carlos> and I will have time to see all emails
[09:52] <carlos> just in case he has any other error
[09:52] <carlos> see you later
[09:53] <jordi> carlos: later
[09:53] <jordi> and thanks
[09:53] <carlos> you are welcome
[09:54] <hannosch> jordi: hi. do you have some time to discuss my mail for the Plone project?
[09:54] <jordi> hannosch: yeah, I'm going through pending emails!
[09:54] <jordi> let me get back to it
[09:55] <hannosch> someone told me you were even visiting #plone. Thx for all your help and time so far ;)
[09:55] <jordi> yeah
[09:55] <jordi> np!
[09:55] <jordi> have people started to use rosetta to translate plone?
[09:56] <jordi> ok
[09:56] <jordi> I have some difficulty to understand how your miriad of packages work together.
[09:57] <jordi> Did you get the suggestion to setup a plone project and all your products under it?
[09:58] <hannosch> yes. but there is the official Plone project (consisiting of some products) and some third party add-on products. as there is a difference in licensing and ownership I would like to keep these seperated
[10:01] <carlos> hannosch, that's the point behind projects and products
[10:01] <carlos> you create a project that will aggregate all products belonging to plone
[10:01] <carlos> and the addons will be products outside the plone project...
[10:03] <dilys> Merge to<EMAIL_ADDRESS>r=spiv major menus refactoring. (patch-2374<EMAIL_ADDRESS>[10:04] <jordi> hannosch: makes sense?
[10:04] <hannosch> ok, that's my idea also. But to ease management for some of these addons I would like to get a second project for these called plone-collective as they are also in the same svn repo with everybody having write access on every product
[10:05] <bradb> kiko:
[10:05] <bradb> bradb@oxygen:~/launchpad $ make lint
[10:05] <bradb> sh ./utilities/lint.sh
[10:05] <bradb> Tree is not lint clean. Unable to continue past this point
[10:05] <bradb> No changed files detected
[10:05] <bradb> bradb@oxygen:~/launchpad $
[10:05] <bradb> I believe I know why that happens, but still... :)
[10:09] <kiko> blame baz status!
[10:11] <bradb> kiko: it would be slightly more useful, IMHO, if it showed baz's output in that case, so that i don't have to rerun baz status again myself
[10:12] <bradb> (i.e. all the status output, not just the first line.)
[10:15] <jordi> hannosch: sounds doable
[10:16] <hannosch> jordi: that would be really great! One minor bug: I'm currently not allowed to appoint translators to the plone group, thereby noone is being able to start translating...
[10:17] <jordi> kiko: hey
[10:18] <jordi> kiko: are only lp admins able to add people to translation groups?
[10:18] <jordi> kiko: would it be possible in the future to grant perms to some people so they can manage that themselves?
[10:18] <jordi> hannosch is the owner of plone, but can't add plone translators.
[10:19] <jordi> hannosch: for now, I guess you'll have to give us a list of launchpad usernames
[10:19] <jordi> and kiko will do it
[10:20] <kiko> jordi, yes, for the 10th time, we need to change the perms system there :-)
[10:20] <jordi> kiko: aha. :)
[10:21] <hannosch> I'm in no hurry, as I'm currently quite busy myself just having released Plone 2.1 and Plone Conference happening in two weeks ;)
[10:21] <jordi> hannosch: either file a bug against launchpad with the list of your translators, or email<EMAIL_ADDRESS>[10:23] <mdke> jordi, what are you hours here? I will ping you tomorrow for the ubuntu-docs stuff if that is ok
[10:23] <mdke> you/your
[10:24] <jordi> mdke: try to find me at 18:00 CEST or so
[10:25] <mdke> what is that compared to UTC?
[10:25] <hannosch> jordi: will do that if I can't add them myself in three or four weeks ;)
[10:26] <jordi> mdke: +2
[10:26] <jordi> hannosch: great
[10:26] <mdke> jordi, i'll be out at that time but I will see what I can do. At the most, email will work
[10:31] <jordi> mdke: yeah
[10:31] <mdke> thanks for your patience!
[10:31] <mdke> night
[10:32] <jordi> hannosch: was t here anything else?
[10:33] <hannosch> jordi: oh. in my mail I told you about some problems regarding name changes as we aren't using the ll_CC naming
[10:34] <jordi> ok
[10:34] <jordi> let me refresh memory
[10:34] <jordi> hannosch: ok
[10:34] <hannosch> If Rosetta depends on this, I'll have to adjust the names manually...
[10:35] <jordi> the name changes for sr@Latn and so are a problem when importing
[10:35] <jordi> ie, you can keep them as they are in svn
[10:35] <jordi> but rosetta needs to get them uploaded with @ and _LL I think
[10:35] <jordi> we could make it grok that convention too
[10:36] <jordi> you can do a rosetta-sanitize script that does it.
[10:37] <hannosch> ok. just wanted to know that. I'll rename them half-automatic before import then. We will use the ll_CC naming in the future as part of moving to Zope3
[10:37] <jordi> aha
[10:37] <jordi> don't force that because of rosetta though
[10:37] <jordi> it shouldn't be a big problem for rosetta to grok pt-BR or pt-br
[10:39] <hannosch> Zope3 forces us to do that anyway and also using the locales/LC_MESSAGES/ folder structure. But we will stay with the current approach for at least one year
[10:41] <hannosch> One last question: Will I be able to register/add new products to the two projects all by myself or do I always have to ask for some initial import?
[10:57] <jordi> locales/LC_MESSAGES/ is insane.
[10:57] <jordi> My opinion though :)
[10:58] <jordi> hannosch: the initial import needs admin help, yeah.
[10:58] <jordi> It's fuckup prone
[10:58] <mpt> carlos: I'm around now
[10:59] <hannosch> ok. just wanted to warn you, that I'll have some twenty products. So it might be more time effecient to lower that border ;)
[10:59] <sabdfl> hannosch: the main reason to require admin support is to ensure we get all the languags
[10:59] <sabdfl> we used to let guys to the import themselves
[10:59] <sabdfl> but they would just do one or two languages
[11:00] <jordi> hannosch: don't worry about the 20 products. Unfortunately that'll be my prob :)
[11:00] <sabdfl> so then the problem was people would start translating the other languages, and perhaps those were already translated upstream, just not imported
[11:00] <jordi> yeah, that was a nightmare.
[11:00] <carlos> mpt, sabdfl any idea about what happens with the missing action links in Rosetta?
[11:00] <sabdfl> carlos: no idea
[11:00] <carlos> mpt, I just saw that we are missing too the Translate link from hte pofile's index page
[11:01] <carlos> sabdfl, it's related to the menu tabs change from last week...
[11:01] <Nafallo> jordi: the translations _still_ doesn't show up! :-(
[11:01] <jordi> Nafallo: what product was this?
[11:02] <jordi> Nafallo: no way, I checked it myself
[11:02] <jordi> gajim?
[11:02] <Nafallo> jordi: gajim
[11:02] <jordi> They are there.
[11:02] <hannosch> hhm. that sounds like you need a more fine-grained permissions set. As I would assume that there are some people capable of it and poor jordi has enough to do *g*
[11:02] <Nafallo> jordi: https://launchpad.net/products/gajim/+translations?
[11:02] <jordi> hannosch: I guess t hat'll happen with time
[11:02] <bradb> mpt: I've got a little no-bug-in-this-context treat to show you in a bit
[11:02] <jordi> Nafallo: hmm, that url is a bit missleading
[11:03] <bradb> mpt: Whatever you're thinking, it's way cooler than that.
[11:03] <jordi> Nafallo: have a look at the last of the boxes at the right
[11:03] <jordi> sabdfl: have a look at https://launchpad.net/products/gajim/+translations
[11:03] <Nafallo> jordi: ahh, fix that! :-D
[11:03] <jordi> while we should be promoting translations in HEAD, we show the Breezy stuff, which is not so complete.
[11:04] <jordi> actually, https://launchpad.net/products/gajim/ also promotes the breezy template, those coming from the branch are hidden in "More translations".
[11:05] <Nafallo> hmm, that kind of sucks indeed :-P
[11:05] <jordi> carlos: any opinion on that?
[11:07] <carlos> jordi, sabdfl wanted it that way
[11:07] <jordi> carlos: ok, then I have to fight the sabdfl :)
[11:07] <sabdfl> jordi: yes, you do ;-)
[11:08] <sabdfl> with the breezy translations, we *know* they will show up, quickly, in language packs
[11:08] <jordi> sabdfl: I really want to discuss this, because it's difficult to find the translation upstream wants to get done.
[11:08] <sabdfl> at least, when carlos ships language packs
[11:08] <jordi> sabdfl: right
[11:08] <jordi> sabdfl: I guess this would be a non-issue with TranslationPushThrough.
[11:08] <sabdfl> jordi: yes
[11:08] <sabdfl> even then, we want to sort the strings so that people translate strings that are common with ubuntu first
[11:08] <jordi> any ideas of how much will it take to get that in?
[11:08] <sabdfl> so we get the max benefit, soonest
[11:09] <sabdfl> the major issue, of course, is permissions
[11:09] <jordi> sabdfl: but of course the problem would be a lot smaller then.
[11:09] <jordi> because on most cases, the tarsnaltions would differ very little.
[11:09] <sabdfl> i'll rearrange the portlets, so the upstream ones are more visible
[11:09] <sabdfl> i'll put them right below the actions portlet
[11:10] <jordi> sabdfl: how can we make it a bit more obvious that there are more templates available? Maybe s/More translations.../See the other %d templates/g in the product summary?
[11:10] <jordi> sabdfl: great
[11:10] <jordi> do you want a bug for this?
[11:10] <Nafallo> jordi: those po's will get updated from upstream svn at regular interval now?
[11:11] <jordi>  Nafallo the breezy thing?
[11:11] <jordi> or the head branch?
[11:11] <Nafallo> jordi: the upstream translations
[11:11] <jordi> no, you should refresh them whenever it suits you.
[11:11] <Nafallo> jordi: we have that permission now?
[11:11] <jordi> ie, not at the moment. In the future it'll be possible
[11:11] <jordi> Nafallo: yes, once the template is setup.
[11:12] <jordi> sabdfl: want me to file a bug about it so you can track it?
[11:13] <sabdfl> jordi: i'm editing that page as we speak, see if you like it after my next landing (cve rework)
[11:14] <jordi> sabdfl: good, I can have a look tomorrow in staging.
[11:14] <Nafallo> sabdfl: YOU ROCK! :-D
[11:15] <sabdfl>       <p>
[11:15] <sabdfl>         The recommended target for current translation activity is
[11:15] <sabdfl>         <strong><span tal:replace="target/displayname" />.</strong>
[11:15] <sabdfl>         Rosetta includes translations for upstream and Ubuntu, see
[11:15] <sabdfl>         the "translatable branches" (on the right of this page)         for any upstream translation templates.
[11:15] <sabdfl>       </p>
[11:15] <sabdfl> jordi: this won't land tonight, i'm afraid. some heavy lifting to do
[11:15] <jordi> sabdfl: no worries. I'm happy it's being dealt with already, that suffices :)
[11:15] <jordi> hmm.
[11:16] <sabdfl> basically, it stays the same, but with stronger hints.
[11:16] <jordi> yeah, as I see your reasoning for promoting ubuntu translations above the others, my concern was the total lack of visibility for the others. I guess that's enough for a fix.
[11:17] <sabdfl> in future it would be nice for the product to designate a branch for current work. then we can include that specifically in the body of the page, rather than just in a portlet
[11:19] <jordi> nod
[11:19] <kiko> sabdfl, ping?
[11:19] <jordi> I think we'll requests for that as people join rosetta
[11:31] <sabdfl> jordi: thanks for coming to UBZ, will be great to have you there
[11:32] <jordi> sabdfl: you can't imagine how exciting it is
[11:32] <jordi> sabdfl: first time over the atlantic :)
[11:32] <Nafallo> sabdfl: I'll seek sponsorship for UBZ+1 instead ;-)
[11:33] <Nafallo> so somewhere near Sweden would be great ;-)
[11:33] <bradb> kiko, mpt: Check it out: http://<IP_ADDRESS>:8086/products/evolution/+bug/5
[11:34] <bradb> There's no doubt a bit of tuning required to get the UI spot on, but the functionality's all there, in any casea
[11:34] <sabdfl> Nafallo: by then, we should have LaunchpadKarma for more independent ticket allocation ;-)
[11:34] <bradb> s/casea/case/
[11:34] <jordi> fuck, I just got a bounce from Edward Parsons
[11:35] <sabdfl> bradb: looks good
[11:35] <bradb> sabdfl: cool :)
[11:35] <Nafallo> sabdfl: hehe, that sounds good, I think :-)
[11:35] <sabdfl> jordi: ah well. there's always May 06... ;-)
[11:35] <jordi> lol
[11:35] <sabdfl> bradb: could you put the message in a portalMessage?
[11:35] <jordi> sabdfl: I'm resending from another box :)
[11:35] <jordi> that isn't blacklisted or anything
[11:35] <kiko> bradb, wow!
[11:35] <bradb> sabdfl: I tried that, but then the button appears outside of the portalMessage
[11:36] <sabdfl> button?
[11:36] <kiko> bradb, "log in", not "login"
[11:36] <bradb> sabdfl: for when you're already logged in, in any case
[11:36] <bradb> sabdfl: the "Yes, ..." button is outside the portalMessage box, for some odd reason
[11:36] <sabdfl> ok, i see. Hmm. we can make that look a bit better
[11:36] <bradb> indeed, indeed
[11:37] <bradb> kiko: right, fixed
[11:37] <sabdfl> you need to provide a "cancel", which takes the user to canonical_url(bug)
[11:38] <kiko> bradb, visit http://<IP_ADDRESS>:8086/products/firefox/+bug/5/+viewstatus
[11:38] <kiko> without being logged in
[11:38] <kiko>  To change this status page, you
[11:38] <jordi> sabdfl: don't worry, resent now :)
[11:38] <kiko> bradb, check where that is linking -- it's the wrong place.
[11:38] <kiko> bradb, you need to do some grepping for +edit
[11:39] <bradb> kiko: right, there's still tons of damage to clean up. the patch ain't ready yet. just wanted to give a taste of the null bugtask love. :)
[11:39] <bradb> i haven't even touched the test suite yet.
[11:39] <kiko> nice!
[11:39] <bradb> kiko: oh, another treat...
[11:39] <bradb> kiko: /malone/bugs/1
[11:40] <bradb> or, heck, /bugs/1, if you feel like it
[11:40] <kiko> neat
[11:40] <kiko> bradb, on the first context it finds?
[11:40] <bradb> kiko: yep, where first == smallest id
[11:40] <kiko> sounds reasonable.
[11:42] <bradb> kiko: note that /distros/debian/+sources/mozilla-firefox/+bug/3 also works now
[11:42] <jordi> kiko: dude I went on the scale today after my little health problem and I am proudly back to 53kgs
[11:42] <kiko> bradb, very cute
[11:42] <sabdfl> bradb: the current email change notification doesn't seem to have a good way to handle removals
[11:43] <bradb> sabdfl: what did you remove?
[11:43] <sabdfl> bradb: cve
[11:43] <Nafallo> carlos: when will you nuke translating-karma? ;-)
[11:43] <sabdfl> i'm restructuring our cve system
[11:43] <sabdfl> we will fetch the full cve database and have the cve's in the system up front
[11:44] <bradb> sabdfl: the email doesn't show:
[11:44] <bradb> CVE references changed:
[11:44] <carlos> Nafallo, I will try to prepare it tomorrow and I suppose it will be done on Tuesday
[11:44] <bradb>     - CAN-XXXX-XXXX [some title]
[11:44] <bradb> ?
[11:44] <sabdfl> bradb: not currently, no
[11:45] <Nafallo> camilotelles: hehe, thanx for the heads up ;-)
[11:45] <Nafallo> carlos: ^ (dooh)
[11:45] <sabdfl> bradb: here's the tricky bit
[11:46] <bradb> sabdfl: ok, that's a bug then, because it's spec'd to do that
[11:46] <sabdfl> we now have table Cve, and a table BugCve
[11:46] <sabdfl> i guess i need an SQLObjectDeletionEvent
[11:46] <sabdfl> is there such a thing?
[11:46] <bradb> no, not that I created
[11:46] <mpt> bradb: Nifty.
[11:46] <sabdfl> i'll do that then
[11:47] <bradb> mpt: glad you like it :)
[11:48] <bradb> sabdfl: ok...what about calling it SQLObjectDeletedEvent? to be consistent with SQLObjectCreatedEvent.
[11:48] <sabdfl> done
[11:48] <bradb> awesome
[11:48] <sabdfl> bradb: where are those defined?
[11:49] <bradb> canonical.launchpad.event.sqlobjectevent