[12:01] <kiko> it means "fire in the hole" more or less and it's an inside joke with the sandwich sprinters
[12:01] <kiko> though you were absent from that dinner, when we went to the indian place IIRC and had red-hot curry.
[12:02] <kiko> SteveA actually knows how to pronounce it.
[12:36] <lifeless> sabdfl: yes I branched for the production update last night.
[12:36] <sabdfl> lifeless: ok, pity, quite a lot of useful stuff went in this morning.
[12:36] <sabdfl> i'm going to have to check the production server to make sure justdave can get going as intended
[12:37] <lifeless> any database changes?
[12:37] <sabdfl> hmm... no i don't think so
[12:37] <lifeless> if there are no database changes, I can just merge the lot across.
[12:37] <lifeless> (after breakfast :))
[12:37] <sabdfl> lifeless: ok, but we'll need to run some tests again
[12:38] <sabdfl> btw, we have a shithot script we're working on which will autopopulate project / product with freshmeat / sourceforge data
[12:38] <lifeless> I thought you didn't want to do that ?
[12:39] <lifeless> sabdfl: there are database changes. I'm going to need to cherry pick the updates.
[12:40] <lifeless> or do another full update with stub.
[12:40] <sabdfl> lifeless: it works quite well, and we can clean it up over time
[12:40] <lifeless> good. I don't know if you recall, but I was pro this in Oxford.
[12:41] <sabdfl> ok, i've come around
[12:41] <lifeless> yay
[12:42] <sabdfl> i'd still like a human review of it, so i think we should add a state field to the db, and at least know which ones we've looked at and which not
[12:44] <kiko> thanks ddaa
[12:47] <justdave> does the production server have a url yet?
[12:48] <ddaa> kiko: you're welcome pal
[01:06] <sabdfl> tal experts?
[01:06] <sabdfl> is there any way to set multiple attributes in a single element using tal:attributes?
[01:08] <daf> sure
[01:09] <daf> tal:attributes="href http://foo.com; title Foo Project"
[01:09] <sabdfl> thanks
[02:18] <kiko> ddaa, don't you think annotation is a valid part of an rcs frontend?
[02:18] <lifeless> kiko: thats a loaded question
[02:19] <kiko> thankfully my wrists hurt
[02:19] <ddaa> It would certainly by useful, and not complex in the multiple-commiter archive case.
[02:19] <lifeless> sabdfl: there were only 4 unmerged patches, I've cherry picked two. (yours and mine) into production
[02:19] <lifeless> I can code update whenever you like
[02:19] <ddaa> it's significantly more tricky to get right in a distributed development environment.
[02:20] <lifeless> kiko: whats the use case that you want to solve - 'being able to run annotate' is not a use case.
[02:20] <lifeless> ddaa: thanks for merge that in
[02:21] <lifeless> testing it on importd-test now.
[02:21] <ddaa> lifeless: I'm not kiko, but it seems that a common use case is "figuring out what the hell this stuff does here".
[02:21] <lifeless> ddaa: for annotate ?
[02:21] <ddaa> lifeless: great, I was expecting I'd have to do it myself tomorrow.
[02:22] <ddaa> lifeless: yes, that's what I think is a common use case for annotate.
[02:22] <lifeless> ddaa: your next task should you choose to accept it, is to start working through the info files and testing them, in parallel with proposing more ProjectProduct mappings from the same files.
[02:22] <lifeless> only worry about ones with CVS or SVN repositories at this point.
[02:22] <kiko> lifeless, yes.
[02:23] <ddaa> lifeless: hu... so I'll need to get the test buildbot up and running anyway.
[02:23] <lifeless> ddaa: yes indeedy.
[02:23] <lifeless> the latest launchpad & the latest database work fine for me.
[02:23] <lifeless> but keep your local hacks handy :(
[02:23] <lifeless> :)
[02:23] <kiko> lifeless, ddaa has a very reasonable point. and to be honest, browsing an annotated version of the file is, in itself, a valid use case. just want to see how much of a file has been changed by others, for instance.
[02:23] <ddaa> So, my task is to pick e.g. zlib and try to import it, and check the changelog to see whether they look half sane?
[02:24] <lifeless> ddaa: https://wiki.canonical.com/CscvsChecking
[02:24] <ddaa> lifeless: define latest? what local hacks are you talking of?
[02:25] <lifeless> didn't you tweak your install slightly for buildbot ?
[02:25] <lifeless> latest - in rocketfuel now.
[02:25] <ddaa> I mean, latest devel or latest production?
[02:25] <lifeless> latest devel
[02:25] <lifeless> latest production is (of course) good too.
[02:25] <lifeless> see the production-2 config in rocketfuel dists.
[02:27] <lifeless> ddaa: yes, the order is : put zlib mapping on the wiki page for sabdfl/I to ok. test zlib in buildbot import + sync in your local repo. then we put it into production.
[02:29] <ddaa> Mh... I'll look at it tomorrow.
[02:29] <lifeless> we're aiming for 5 into production each day.
[02:29] <ddaa> Expect me to come and harass you quite a bit until I get started.
[02:30] <lifeless> do so - this is our top priority
[02:30] <ddaa> ETA?
[02:30] <lifeless> for what 
[02:30] <ddaa> for bulk imports
[02:30] <lifeless> thats what we are doing
[02:30] <lifeless> started 3 weeks back
[02:31] <ddaa> what is the expected date of completion?
[02:31] <lifeless> target is 120 by the release of ubuntu.
[02:31] <lifeless> I think we are going to miss that by a mile, but the closer we come the better.
[02:36] <lifeless> so far so good
[02:36] <lifeless> much better than the crack you had before.
[02:36] <lifeless> thank you
[02:37] <lifeless> sabdfl: https://www.warthogs.hbd.com/ProjectProductSetup
[02:37] <lifeless> sabdfl: still has a huge number not seconded
[02:37] <lifeless> And I've much much more to come that I'm waiting for the non-seconded bit to shrink first.
[02:45] <lifeless> wtf
[02:45] <lifeless> cvs [checkout aborted] : Could not map memory to RCS archive /srv/importdtest/botslave/buildbot-jobs/coreutils-HEAD-import.job/coreutils@arch.ubuntu.com/coreutils--MAIN--0/cvs_temp_repo/coreutils/lib/offtostr.c,v: No such file or directory
[02:46] <lifeless> ls /srv/importdtest/botslave/buildbot-jobs/coreutils-HEAD-import.job/coreutils\@arch.ubuntu.com/coreutils--MAIN--0/cvs_temp_repo/coreutils/lib/offtostr.c\,v 
[02:46] <lifeless> /srv/importdtest/botslave/buildbot-jobs/coreutils-HEAD-import.job/coreutils@arch.ubuntu.com/coreutils--MAIN--0/cvs_temp_repo/coreutils/lib/offtostr.c,v
[02:46] <lifeless> chinstrap does weird-ass shit sometimes.
[02:51] <kiko> ack
[02:51] <kiko> mmap()ing rcs archives is failing?
[02:53] <lifeless> not in general.
[02:53] <lifeless> that a cvs error fwiw
[08:08] <stub> lifeless: I don't think the database schema patches made last night are required for anything that needs rolling out now
[10:00] <sabdfl> lunchpad!
[10:20] <cprov> Kinnison: sabdfl : elmo_ : Can we make the Soyuz Pages Walk-through today, asap ?
[10:24] <sabdfl> Kinnison: i'm ready when you guys are, the production update went ahead yesterday
[10:24] <Kinnison> okay; cool
[10:24] <sabdfl> stub, lifeless: production update all squared away? things I need:
[10:25] <sabdfl>  - ability to create projects and products through the doap interface (works on my system)
[10:26] <sabdfl>  - ability to regiser sources through the doap interface (works on my system)
[10:26] <cprov> Kinnison: fine, so in 10 minutes ?
[10:26] <sabdfl>  - ability to register bug trackers through doap AND malone system (both work here)
[10:26] <sabdfl> plus whatever you need, of course
[10:26] <Kinnison> cprov: fine by me. Elmo? sabdfl?
[10:26] <sabdfl> wfm
[10:27] <elmo_> yeah, 'tever
[10:36] <Kinnison> cprov: Should we head over to you; or will you come to the table?
[11:06] <SteveA> stub: ping
[11:09] <BradB> Can we not use _columns to define properties of SQLObject classes? Pretty please? :)
[11:15] <spiv> BradB: I don't care much either way. :)
[11:16] <spiv> (I somewhat like the segregation of SQLObject magic and normal attributes/methods, but then our use of e.g. MultipleJoin breaks that anyway...)
[11:17] <spiv> Is there any reason why we don't have the =tagging-method mark .rej files as unrecognised, so that it's harder to accidentallly commit unresolved conflicts?
[11:20] <stub> SteveA: pong
[11:20] <stub> BradB: I'd already started migrating ;)
[11:21] <stub> There is a Style in SQLBase to make it easier
[11:21] <spiv> The SQLObjectGuide on the wiki should probably be updated to reflect that..
[11:21] <stub> My Kernel is spinning ;-/
[11:52] <BradB> spiv: I'll do that.
[12:06] <carlos> lifeless: ping?
[12:15] <stub> BradB: Do you think we want to capture when the bugassignment changed, too?
[12:20] <SteveA> stub: underscore in "name" columns?
[12:20] <SteveA> no dash?
[12:20] <stub> Dash and undescore too (I thought I said that?)
[12:20] <SteveA> [a-z0-9._] ,
[12:21] <SteveA> that's what your email says
[12:21] <SteveA> and, why at least one non a-z digit?
[12:21] <BradB> stub: Maybe, but maybe not yet.
[12:21] <SteveA> oh, one non-digit
[12:22] <SteveA> okay
[12:22] <SteveA> also, they need + don't they?
[12:22] <SteveA> gtk+ ?
[12:22] <SteveA> but no "+" at the start
[12:22] <stub> SteveA: Yer - avoid namespace conflicts
[12:22] <SteveA> there is a package name that has all digits
[12:22] <stub> SteveA: At the moment, '+' isn't allowed. I think I need to add that
[12:23] <stub> SteveA: No numbers-only to avoid namespace conflicts between the numeric id and the name.
[12:23] <SteveA> so, realistically, we need [a-z0-9] [a-z0-9.-+] *
[12:23] <SteveA> there is a package name that has all digits
[12:23] <stub> SteveA: So do we change the package name or risk problems down the track?
[12:24] <SteveA> I don't see a need for _.  Do you?
[12:24] <SteveA> We can't change the package name
[12:24] <SteveA> that would mean we can't do soyuz / malone / doap for debian
[12:24] <SteveA> we can't go around telling debian to change on account of us
[12:25] <stub> We can ask - it sounded like the debian folk didn't like the idea of an all-numeric package name either
[12:25] <SteveA> for numeric ids, we can say something like "+id1234" in urls if necessary
[12:25] <SteveA> I'll ask james...
[12:26] <elmo_> I don't, but it's allowed by policy and there are existent examples
[12:26] <elmo_> so as Steve said, we can't try to enforce a policy on Debian
[12:26] <SteveA> we really should comply with the written debian policies
[12:27] <SteveA> it is, after all, our Rock
[12:27] <stub> Ok - but if some nutcase wants non-ASCII in their package name they can get stuffed.
[12:27] <SteveA> yes
[12:27] <SteveA> we wave the debian package policy at them
[12:28] <SteveA> and then politely give them the finger
[12:28] <stub> Malone requires names don't conflict with id's because you can traverse on either, so the Bug.name will need a special rule.
[12:28] <daf> I can't call my package "ff"?
[12:29] <SteveA> who sets a Bug.name ?
[12:29] <stub> There is actually a Debian written policy on package name to wave? That allowed all numeric
[12:29] <SteveA> where does it come from?
[12:29] <stub> ?
[12:29] <SteveA> yes, there is
[12:29] <SteveA> it is linked to the wiki page on tis
[12:29] <stub> SteveA: Anybody who wants to give a bug a nickname
[12:29] <SteveA> ok, that's fine then
[12:29] <SteveA> so, a bug's nickname can't start with a number
[12:29] <daf> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package
[12:30] <daf> that's binary packages
[12:30] <stub> Oh - it can start with a number. Just can't be all numbers ;)
[12:30] <Kinnison> daf: For the same reason I'm not allowed to call mine 
[12:31] <SteveA> stub: see https://wiki.canonical.com/WebAppProcess
[12:31] <daf> Kinnison: bah! ASCII fascists!
[12:31] <elmo_> daf: tree hugging hippy
[12:31] <daf> censorship!
[12:31] <SteveA> stub: search for "debian" in that page
[12:31] <SteveA> stub: that lists the rules for url segments / names
[12:31] <stub> daf: Blame the twonks who forgot to specify encoding in HTTP ;)
[12:32] <daf> stub: and URLs
[12:32] <SteveA> stub: please either stick to the rules on that page, or change the rules on that page
[12:33] <SteveA> 
[12:33] <SteveA> It will follow these conventions:
[12:33] <SteveA>    1.
[12:33] <SteveA>       It will consist of only lowercase letters [a-z] , digits [0-9] , the period[.] , the minus sign [-]  and the plus sign [+] .
[12:33] <stub> Yer - I can read ;)
[12:33] <SteveA>    2.
[12:33] <SteveA>       It will be at least two characters in length.
[12:33] <SteveA>    3.
[12:33] <SteveA>       It will start with either a lowercase letter [a-z]  or a digit [0-9] .
[12:33] <SteveA>    4.
[12:33] <SteveA>       It will be unique within some defined space, see the table definitions for details. For example, look for UNIQUE ( project, name ) which would tell you that the name of that item is unique for all projects.
[12:34] <SteveA> 
[12:34] <SteveA> (that was for the benefit of the channel logs)
[12:35] <SteveA> stub: on the cookies problem... any idea how much time it would take to implement decently encrypted cookies, without the need for sessions, in exUF ?
[12:35] <stub> You can't
[12:35] <daf> stub: http://www.w3.org/International/O-URL-and-ident -- woo!
[12:36] <stub> Oh... hangong
[12:38] <stub> Assuming a descent encryption library is available, an hour or two.
[12:39] <stub> You just have to find the bit where it sets the cookie and make it set it to crypt(pw) instead, and the bit where it retrieves the cookie and make it do decrypt(pw).
[12:39] <carlos> daf: do you know if lalo left already? should we reassign his bugs?
[12:39] <daf> carlos: I don't know
[12:39] <daf> carlos: I was expecting to see him around more this week
[12:39] <SteveA> stub: hmm... know of any readily available libraries where we can use a big salt?
[12:40] <stub> SteveA: Not a one way crypt - needs to be two way like rotor. There are python crypto libraries around but I haven't looked into them,
[12:41] <stub> I think they have AES implementations which would be fine.
[12:41] <stub> Heck - XOR with the secret would probably be fine.
[12:50] <daf> stub: depends how secure you want it to be
[12:51] <BradB> stub: We don't need that BugInfestationType table.
[12:52] <stub> Ta. Almost got that one done before I got distracted by name constraints ;)
[12:54] <SteveA> daf: no it doesn't
[12:54] <SteveA> daf: this is a one time pad
[12:54] <SteveA> with a salt
[12:55] <daf> oh, I see
[01:02] <stub> BradB: Do we drop the infestation column too on ProductBugInfestation?
[01:04] <stub> BradB: oic. Just leave it as an int for dbschema.py to validate
[01:11] <SteveA> stub: jabber?
[01:11] <SteveA> sometime or other
[01:20] <stub> Brad - can you live without an official patch to create your requested tables? I've got something urgent to do for Steve.
[01:22] <BradB> I'm working with the mods made locally already. I won't commit anything, of course, until there's an official patch, but I won't be ready to commit anything for a couple of hours I think anyway.
[01:23] <BradB> So yes, I can live without an official patch. ;)
[01:23] <BradB> (for now :)
[01:33] <jdub> DEBIAN IS OUR ROCK!
[02:02] <dilys> Bug 2073 resolved: James Troup(elmo) as Soyuz Tester/Guide
[02:02] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2073
[02:10] <kiko> morning pret people
[02:18] <elmo_> pizza people today
[02:20] <kiko> wow!
[02:21] <SteveA> brad says: "What has 'bilabong' to do with australia?"
[02:22] <spiv> "billabong"
[02:22] <SteveA> I mistranscribed
[02:30] <dilys> New bug 2090 for Launchpad/Soyuz: Add Brad's nickname.py lib and CreatePerson() method to FOAF 
[02:30] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2090
[02:31] <kiko> cprov, kicking bz's ass :)
[02:37] <stub> How to I import a tarball into arch?
[02:47] <Kinnison> you init a tree; unpack the tarball; add the files and dirs; check tla tree-lint is happy; and then to tla import
[02:48] <Kinnison> (approx)
[02:51] <dilys> New bug 2091 for Launchpad/Soyuz: Create a Soyuz QA branch
[02:51] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2091
[02:54] <cprov> kiko: yep, last day = good results :)
[02:55] <kiko> heh
[02:55] <kiko> wow
[02:56] <cprov> dilys: don't you like it ? btw, I'll try to create not so ugly pages :)
[02:57] <kiko> dilys is one phat chick
[03:30] <Kinnison> stub: around?
[03:31] <stub> yo
[03:31] <Kinnison> Do you want comments when I give schema changes?
[03:31] <Kinnison> I.E. SQL comments
[03:32] <Kinnison> gah; I.E. SQL 'COMMENT' commands
[03:35] <stub> Yes please. Sometime after rollout I'm going to want the entire thing commented (for my benefit if not others - I still don't know what half the tables are supposed to represent :-/ )
[03:39] <Kinnison> Okay.
[03:54] <dilys> New bug 2094 for Launchpad/Soyuz: Change to queries inside Soyuz App Components to the properly SQLObject
[03:54] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2094
[04:02] <dilys> New bug 2095 for Launchpad/Soyuz: Use Sourcepackage() instead of SoyuzSourcepage()
[04:02] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2095
[04:04] <cprov> dilys: you "bug broadcast" :)
[04:10] <cprov> dilys: what is tcpwatch (on lp/utilities) for ?
[04:10] <Kinnison> erm, a bot
[04:11] <cprov> cprov: oopps 
[04:12] <cprov> daf: what is tcpwatch (on lp/utilities) for ?
[04:12] <Kinnison> stub: any chance we can have those lucille DBA requests done soon?
[04:15] <stub> They are in aren't they?
[04:15] <Kinnison> maybe I'm missing a star-merge or two
[04:15] <Kinnison> stub: and I've just posted another one anyway :-)
[04:15] <stub> database/schema/patch-3-01-0.sql
[04:17] <kiko> cprov, LOL
[04:21] <Kinnison> stub: aah yes; although that's missing an index on the id column for sourcepackagepublishing :-(
[04:21] <Kinnison> stub: did I forget to ask for that?
[04:22] <kiko> BradB, that assumes users inhabit Jim's mind
[04:22] <BradB> Perhaps "users" was defined as "rocket scientists on their coffee break."
[04:23] <kiko> rocket scientists don't drink coffee. they drink rocketfuel.
[04:24] <BradB> heh
[04:24] <daf> cprov: it's part of a fish^Wfunctional doctesting framework we're introducing
[04:25] <cprov> daf: tks
[04:25] <daf> I'll write some documentation for it soon
[04:25] <cprov> daf: great
[04:26] <dilys> New bug 2096 for Launchpad/Launchpad: Schema class needed by Person class but it's not in place
[04:26] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2096
[04:32] <limi> seems I have a PQM merge failure for my last commit - is there a quick way to compare what I have in my repository with what is at rocketfuel?
[04:33] <cprov> limi: tla star-merge will bring the conflicts to your local  tree 
[04:33] <limi> ok
[04:34] <daf> and they you have lovely .orig and .rej files to play with :)
[04:34] <limi> and is there then a command to see them, or do I have to hunt for .orig and .rej files?
[04:34] <daf> tla tree-lint -b will list orig/rej files
[04:34] <daf> but orig/rej still sucks
[04:34] <limi> aha, thanks
[04:34] <cprov> limi: pay attention to 'C' infront of files :)
[04:34] <limi> heh, yes
[04:34] <daf> limi: do you have a merge tool?
[04:35] <limi> FileMerge from Apple should work
[04:35] <daf> limi: if you do, you can "tla get" rocketfuel, and then use a standard merge tool to fix the files that conflict
[04:35] <daf> I think the PQM error message should say which files conflict
[04:35] <limi> hm, ok
[04:35] <daf> I find it easier to use vimdiff than stare at orig/rej files
[04:35] <limi> anyway, will have to fix it later - on my way home
[04:36] <limi> see you later
[04:36] <cprov> daf: it does actually says , doesn't it ?
[04:36] <daf> cprov: the PQM error message?
[04:36] <cprov> daf: yep
[04:36] <daf> cprov: I can't remember :)
[04:37] <cprov> daf: since last week I'm not receiving success/failure from my PQM requests, I'm doing it in a BLIND way :)
[04:37] <daf> !
[04:37] <daf> mysterious email lossage?
[04:37] <spiv> 
[04:38] <daf> spiv: quite
[04:38] <spiv> Guh..
[04:38] <cprov> daf: but as far as I can remember, yes , that messages comes with the files state if failure
[04:38] <cprov> spiv: heya !
[04:38] <spiv> cprov: Hello.
 Is there any reason why we don't have the =tagging-method mark .rej files as unrecognised, so that it's harder to accidentallly commit unresolved conflicts?
[04:40] <cprov> spiv: when will you be able to move the people branch of Soyuz to FOAF ?
[04:41] <cprov> spiv: unrecognized .rej on arch ? nice !!! how ?
[04:42] <spiv> cprov: change {arch}/=tagging-method, but before I blindly do so, I'd like one of our arch gurus to tell me it's a sane thing to do :)
[04:43] <spiv> jblack/ddaa/lifeless: ^
[04:44] <cprov> spiv: ddaa : so ?!
[04:44] <ddaa> Sounds useful, but you might have surprises.
[04:45] <ddaa> tla treats .orig and .rej files a bit specially.
[04:45] <carlos> ddaa: do you know why could be that I cannot use gnome-gpg when creating a new branch with tla?
[04:45] <ddaa> Like moving them to "++ignored-conflicts" or something when they get in the way.
[04:45] <spiv> I figure there's probably a good reason why it's not like this by default :)
[04:45] <carlos> ddaa: gnome-gpg is a gnome front end to gpg
[04:46] <carlos> and it fails to connect with X
[04:46] <spiv> ddaa: get in the way of what?  another conflict?
[04:46] <ddaa> carlos: I am using gnome-gpg right now in my signing rules...
[04:46] <carlos> ddaa: it also works here, except with tla tag
[04:46] <ddaa> spiv: I think that's all, yes. But I cannot be positive.
[04:47] <ddaa> carlos: just to be sure, you did tell --no-tty?
[04:47] <carlos> nope
[04:47] <carlos> should I?
[04:48] <ddaa> I do, it avoids weird things that might happen when spawning gpg from tla.
[04:48] <spiv> ddaa: Ok, sounds like its less surprising than finding you accidentally committed without resolving a conflict.
[04:49] <ddaa> spiv: the point is that if you do multiple merges, (e.g. with replay) you might still miss conflicts.
[04:49] <carlos> ddaa: gnome-gpg --default-key 60F957D7 --clearsign --no-tty?
[04:49] <ddaa> and the additional confidence might me dangerous.
[04:49] <kiko> ddaa!
[04:49] <spiv> ddaa: But that could happen right now anyway.
[04:49] <spiv> ddaa: And our typical use-cases by far are single merges.
[04:50] <ddaa> carlos: yup, that's what I do (except I do not specify the key).
[04:50] <spiv> I appreciate that might not be true for all projects held in arch, but it is true of launchpad.
[04:50] <carlos> ddaa: ok
[04:50] <ddaa> So, moving the .rej pattern from backup to unrecognized sounds something reasonable to do.
[04:50] <spiv> Hmm, would marking ++ignored-conflicts as unrecognised work?
[04:50] <carlos> next branch will tell me if that helps :-)
[04:50] <ddaa> Nope.
[04:50] <carlos> ddaa: thanks
[04:50] <spiv> Or is that too evil? :)
[04:51] <ddaa> spiv: ++* is hardwired precious, and ,,* is hardwired junk.
[04:51] <daf> ddaa: is there a way to have conflicting files left intact?
[04:51] <spiv> Drat.
[04:51] <ddaa> daf: none that I am aware of.
[04:51] <spiv> Ok, well I'll mark .rej/.orig as unrecognised, anyway.
[04:51] <spiv> ddaa: Thanks
[04:51] <daf> ddaa: e.g. rather than foo{,.rej,.orig}, foo{.mine,.other}
[04:52] <daf> ddaa: I tink that would make resolving conflicts much easier for me
[04:53] <ddaa> daf: I understand, that was thoroughly discussed on gau. A patch in that direction would very probably be accepted easily.
[04:54] <ddaa> That's a hook for custom merge tools.
[04:54] <ddaa> daf: in the meantime --three-way is your friend.
[04:54] <daf> ah, good
[04:54] <daf> --three-way?
[04:54] <ddaa> star-merge -H
[04:54] <Kinnison> sounds like good fun
[04:54] <ddaa> use diff3 for merging
[04:55] <daf> interesting
[04:55] <ddaa> a la CVS conflict markers
[04:55] <ddaa> It is reputed to be broken though.
[04:55] <daf> oh
[04:55] <daf> are you sure it's my friend?
[04:55] <ddaa> daf: the reason why it is broken are quite subtle.
[04:56] <ddaa> I have found a test case where it seems to do the wrong thing, but I'm not too sure.
[04:56] <daf> ok, so should I trust it or not? :)
[04:56] <ddaa> There is also the fact that it will cause star-merge to ignore changes which seem have been already applied.
[04:57] <ddaa> daf: If you cannot use emacs diff mode, or something vim equivalent, and what something nice to fix conflicts, it's your friend.
[04:57] <daf> I can use vimdiff
[04:57] <daf> which I like
[04:57] <daf> but
[04:58] <Kinnison> I want to be able to use meld to solve tla conflicts
[04:58] <ddaa> But you have to be aware it's no magic and needs to me eyeballed.
[04:58] <Kinnison> meld is cool
[04:58] <daf> I have to explicitly get the tree I want to merge with in order to get pristine versions of the files I want to merge with
[04:58] <ddaa> Kinnison: ++
[04:58] <Kinnison> ddaa: ??
[04:58] <ddaa> Kinnison: meld is cool
[04:58] <ddaa> yet I'm addicted to emacs diff and ediff modes.
[04:59] <Kinnison> ediff confuses me
[04:59] <ddaa> Emacs sucks, but everything else sucks more :-)
[05:01] <ddaa> daf: I understand your problem, and it is valid. There's no easy way to solve it. Look for "custom merge" "diff3" "xml diff" threads in the archive, you should be able to find the relevant data somewhere in the noise.
[05:02] <ddaa> But if somebody implements an option, like "star-merge --external-merge" or something, it will probably be easily accepted.
[05:02] <ddaa> Mhh... I guess that's also something that might be done in FAI.
[05:02] <ddaa> ooops
[05:02] <ddaa> RAW
[05:02] <spiv> Heh.
[05:03] <SteveA> what does FAI expand to? "forget about it" ?
[05:03] <ddaa> fai has already reimplemented it's merge operator. Once you have implemented the star-merge algorithm (finding the common parent) it's trivial to do what you want. Sounds like something we could put in RAW.
[05:03] <Kinnison> stevea: fully automated installation
[05:03] <Kinnison> erm; or not
[05:03] <ddaa> Friendly Arch Interface.
[05:04] <Kinnison> s/contact/context/
[05:04] <ddaa> It's looking for a non-conflicting name, though...
[05:04] <Kinnison> ddaa: FAI is a massively overloaded acronym
[05:05] <ddaa> daf: probably you should bring your request to lifeless/scott/bob2.
[05:06] <BradB> FAI is an MOA
[05:07] <spiv> "Ouch!  You hit me right in the acronym!"
[05:07] <BradB> ARP is a real PITA FYI
[05:08] <ddaa> Kinnison: Association des Amateur d'Andouillette Auvergnate Authentique?
[05:08] <Kinnison> non
[05:08] <BradB> ben oui
[05:08] <Kinnison> BradB: j'ai dis non
[05:09] <SteveA> is Andouillette a kind of sausage?
[05:09] <ddaa> Kinnison: that's a real non-profit in France. They deliver a label of quality for a specific kind of sausage.
[05:09] <Kinnison> ddaa: American Association Against Acronym Abusers
[05:09] <SteveA> a kind of sausage that has an anus?
[05:09] <Kinnison> Trust SteveA to come up with that
[05:10] <ddaa> SteveA: ??? well, "andouille" is soft slang for idiot, I guess that explain your dictionnary information :-)
[05:19] <kiko> who said anus?!
[05:43] <dilys> New bug 2097 for Launchpad/Rosetta: make a dbschema for message ID plural forms
[05:43] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2097
[06:13] <dilys> New bug 2098 for Launchpad/Launchpad: improve Launchpad debugging modes
[06:13] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2098
[06:13] <dilys> Bug 1907 resolved: check the implementation of request/lp:person to make sure it works right
[06:13] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1907
[06:16] <dilys> Bug 1908 resolved: check that the IPerson adapter code is as it should be
[06:16] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1908
[06:34] <cprov> Kinnison: how do I configure Emacs to open ZCML files in sgml-mode ?
[06:35] <daf> cprov: alias emacs="vim +ft=xml"
[06:36] <carlos> X-)
[06:37] <cprov> daf: vim users are loosers :)
[06:37] <carlos> daf: that's why I'm using gvim :-)
[06:37] <carlos> uupps
[06:37] <carlos> cprov: that's why I'm using gvim :-)
[06:37] <carlos> :-D
[06:37] <Kinnison> cprov: (setq auto-mode-alist (cons '("\\.zcml$" . sgml-mode) auto-mode-alist))
[06:38] <Kinnison> cprov: in your .emacs
[06:39] <Kinnison> cprov: *or* <!-- -*- sgml -*- --> at the top
[06:39] <Kinnison> cprov: of the zcml file
[06:39] <cprov> Kinnison: thank you :)
[06:40] <Kinnison> cprov: I've got some cute functions for arch tags too if you want them
[06:41] <cprov> Kinnison: please !!
[06:42] <Kinnison> ;; Useful little archy bits
[06:42] <Kinnison> (defun dsilvers-insert-uuid () "" (interactive)
[06:42] <Kinnison> (insert (shell-command-to-string "uuidgen"))
[06:42] <Kinnison> )
[06:42] <Kinnison> (defun dsilvers-insert-arch-tag () "" (interactive)
[06:42] <Kinnison> (insert "arch-tag: ") (dsilvers-insert-uuid)
[06:42] <Kinnison> )
[06:42] <Kinnison> (global-set-key [(control c) (control a) t]  'dsilvers-insert-arch-tag)
[06:42] <Kinnison> that makes "C-c C-a t" insert arch-tag: <UUID>
[06:43] <cprov> Kinnison: arch tags sucks a bit when copying files ... I preffer 'tla add'
[06:44] <Kinnison> cprov: arch-tags *rock* when moving files though
[06:45] <cprov> Kinnison: but as I said you get in troubles when you copy them ...
[06:46] <Kinnison> cprov: tree-lint helps
[06:47] <daf> Kinnison: ewww, no -*- emacs warts -*- please
[06:47] <Kinnison> cprov: plus I go C-s arch-tag RET C-k C-c C-a t C-d if I copy a file anyway
[06:50] <cprov> Kinnison: aha, "Simple Life"  ?
[06:53] <Kinnison> daf: better than 'vim: ft=foo' warts
[06:54] <daf> Kinnison: they're just as bad
[06:54] <Kinnison> At least emacs warts can be almost read in-line
[06:55] <Kinnison> E.g. /* This file is written in -*- C++ -*- */
[06:58] <spiv> Kinnison: That's what the .cpp file extension is for :P
[06:59] <Kinnison> spiv: .h
[06:59] <spiv> .hpp ;)
[06:59] <Kinnison> spiv: and suggesting .hpp will result in pain
[06:59] <spiv> Hehe.
[06:59] <Kinnison> I've already told SteveA to stop fluttering his eyelashes at me
[06:59] <Kinnison> I don't need you winking at me too
[06:59] <spiv> Hah
[07:04] <daf> Kinnison: they train their employees how to do sexual harrassment?
[07:06] <BradB> anyone read the activity mailing list?
[07:06] <BradB> They're pretty, em, explicit aren't they. ;)
[07:08] <Kinnison> daf: Dunno; I never got the training
[07:25] <kiko-afk> BradB, I would rather not know about intestinal problems, yes.
[07:27] <BradB> kiko: You do not want to know about the mental movie I watched while reading that email.
[07:28] <BradB> In fact, I just watched it again.
[07:28] <spiv> BradB: Mention that in your activity report ;)
[07:29] <kiko> "Puked after reading lifeless' activity report. Went back to bed"? 
[07:29] <BradB> heheh
[07:43] <Kinnison> Why is patch 422 missing from launchpad?
[07:47] <spiv> Kinnison: it was a bad commit (from lalo iirc) that was backed out by lifeless.
[07:48] <Kinnison> aah
[07:48] <Kinnison> cool
[08:04] <BradB> spiv: ping
[08:05] <spiv> BradB: pong
[08:06] <BradB> spiv: We wanna know why pqm keeps build-config'ing and star-merging from Mark. It's on its third iteration of doing that, since I've been paying attention. Mark did his last pqm request over an hour ago and hasn't received any email.
[08:06] <BradB> now it's just finished another one of those
[08:06] <spiv> Hmm!
[08:06] <BradB> it's started another build-config now
[08:07] <spiv> I need to reboot (kacipd is eating my cpu again).
[08:07] <spiv> But I'l ltake a look after that.
[08:07] <BradB> ok
[08:20] <BradB> spiv: How's it going? :)
[08:28] <spiv> BradB: Not good -- gnome-terminal crashed :(
[08:28] <spiv> So I spent a few moments with bug buddy.
[08:28] <spiv> I also don't have enough permissions to really see what's going on.
[08:29] <spiv> The pqm queue is in /home/pqm/arch/queue on chinstrap, I believe.
[08:29] <spiv> But I can't read all the files in there.
[08:30] <elmo_> eh, what do you need to read?
[08:34] <spiv> the patch.* files in the queue.  Well, I doubt that would help me do anything other than confirm that "yep, mark's is still there, and still being processed over and over..."
[08:35] <spiv> I don't directly need to read anything, I just want to know why pqm is looping (processing the same queue item again and again, apparently), and what needs to be done to fix it :)
[08:36] <BradB> spiv: Hang on, we're doing some killing here.
[08:37] <spiv> Rockin'
[08:37] <spiv> It's great having a killer sysadmin ;)
[08:38] <daf> spiv: "killer" as in "homicidal"?
[08:40] <spiv> "no comment"