| (spiv/#launchpad) SteveA, lulu: registering through the plone site with a + in the email address seems to work fine, apart from an odd error immediately after signing up (and I had to explicitly ask for a password reset after signing up, too) | 12:07 | |
| SteveA | spiv: did you see the subsequent email from lu? the people mailing in were having trouble with mako's shipit, not with the main website | 12:10 |
|---|---|---|
| SteveA | but, thanks for checking into it. we should fix the odd error you uncovered | 12:10 |
| (daf/#launchpad) spiv: lulu is not here | 12:10 | |
| (spiv/#launchpad) SteveA: Yeah, I did, but I thought it would be working checking just in case :) | 12:10 | |
| (elmo/#launchpad) steve: it's 11pm... | 12:10 | |
| (spiv/#launchpad) daf: Damn people with nicks that are too short to bother tab-completing ;) | 12:10 | |
| SteveA | elmo: it is 1am | 12:11 |
| (daf/#launchpad) spiv: damn them :) | 12:11 | |
| (spiv/#launchpad) SteveA: Also, this means the nick-generation stuff is live. | 12:11 | |
| SteveA | cool | 12:11 |
| (elmo/#launchpad) SteveA: blahblah, you know what I mean. where Lu is, it's 11pm | 12:11 | |
| SteveA | can you note the odd error in the bug report? | 12:11 |
| (spiv/#launchpad) (I also changed the authserver to accept nicks as login IDs, alongside Person.id values and emailaddresses) | 12:12 | |
| SteveA | elmo: ok, but it was spiv who addressed lulu | 12:12 |
| SteveA | great | 12:12 |
| (daf/#launchpad) aye, Lu clocks of pretty regularly between 5 and 6 | 12:12 | |
| (spiv/#launchpad) Hmm, it's midnight here, come to think of it... | 12:12 | |
| (daf/#launchpad) s/of/off/ | 12:12 | |
| SteveA | that will allow us to switch between email address for login and nick, if we want to at some point | 12:12 |
| === spiv still isn't quite used to being on roughly the same timezone as other people ;) | ||
| (daf/#launchpad) :) | 12:13 | |
| (daf/#launchpad) being over here is weird | 12:14 | |
| SteveA | you mean you're not dead yet? | 12:14 |
| (daf/#launchpad) stub tends to be saying "good morning" when I'm going to bed | 12:14 | |
| (daf/#launchpad) SteveA: not yet | 12:14 | |
| SteveA | does it feel safe at night? | 12:14 |
| (daf/#launchpad) Mark's estimation of my life expetancy notwithstanding | 12:15 | |
| (daf/#launchpad) it does, actually | 12:15 | |
| SteveA | wow | 12:15 |
| (daf/#launchpad) not that I've been out at night much | 12:15 | |
| (daf/#launchpad) safe, but cold | 12:15 | |
| SteveA | I must try to sleep | 12:15 |
| (daf/#launchpad) yes | 12:16 | |
| (daf/#launchpad) you must | 12:16 | |
| === BradB just realized daf and co. are a few hours from Montreal | ||
| BradB | NYC Mao Championship! | 12:18 |
| (daf/#launchpad) :) | 12:18 | |
| BradB | last time i was in NYC was for the '96 NY Open Chess Championship...memories... | 12:18 |
| BradB | pictures of the twin towers, etc. | 12:18 |
| (daf/#launchpad) gosh, 8 years | 12:19 | |
| BradB | yep | 12:19 |
| === carlos hates too much the functional tests... | ||
| BradB | carlos: why? | 12:21 |
| carlos | BradB: because I'm trying to fix one, that's all :-) | 12:21 |
| BradB | ah...yeah, that's the fun part | 12:21 |
| BradB | fsdo "fun" | 12:21 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: implemented bug subscription listing (patch-632) | 12:26 | |
| carlos | daf: I detected a bug in pofile_adapters that I don't think it's a direct problem of my changes, should I fix it? (the functional tests are failing because it) | 12:35 |
| carlos | I mean, should I fix it or wait after the merge? | 12:36 |
| (daf/#launchpad) if it's not related to your branch, you'll ideally fix it in the trunk and merge the fix onto your branch | 12:38 | |
| (daf/#launchpad) I don't know if that's feasible or not | 12:38 | |
| carlos | daf: it should be doable, I will take that approach tomorrow, I'm tired today and it's too late... | 12:39 |
| carlos | daf: we need to do a review of all code, I was adding XXX in many places | 12:39 |
| (daf/#launchpad) "all" code? | 12:40 | |
| carlos | well, all code related to pofile.py | 12:42 |
| carlos | perhaps it's me, but there are some places where I have some doubts if it's correct... | 12:43 |
| carlos | daf: I'm tired tonight, let me rephrase it tomorrow :-) | 12:44 |
| (daf/#launchpad) sure :) | 12:44 | |
| carlos | ok, good night!! | 12:47 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: fixed adding of bug subscriptions (patch-633) | 01:04 | |
| lifeless | spiv: around ? | 01:13 |
| ddaa | lifeless: duh... just realised that the sql recipe you gave me to enable sync was wrong... | 01:14 |
| ddaa | had to dig into sourcesource.py, a job is a sync if sourcesource.syncingapproved is non-NULL instead of just processingapproved... | 01:15 |
| lifeless | oh? | 01:15 |
| ddaa | you said: update sourcesource set processingapproved=NOW(), syncinterval='1 day' where name like 'foo%'; | 01:15 |
| lifeless | the recipe I gave you was syncingapproved=NOW() ... | 01:15 |
| lifeless | oh, oops. | 01:15 |
| ddaa | the force of copy-pasting :-P | 01:16 |
| sabdfl | limi has real issues with his tla revision library | 01:17 |
| ddaa | btw, I noticed that the taxi.py brokeness will prevent the mirror from ever being populated, since the mirroring is done there. You're sure that's not going to be a problem for testing? | 01:17 |
| sabdfl | inode signature validation problems, etc | 01:17 |
| sabdfl | can i just blow away the revision library contents? | 01:17 |
| ddaa | sabdfl: yes | 01:17 |
| sabdfl | rm -r the directory/* | 01:18 |
| sabdfl | ? | 01:18 |
| ddaa | rm -rf revlib/*@* | 01:18 |
| ddaa | so you do not blow the =* files which store the options | 01:18 |
| lifeless | ddaa: thats what I'm trying to track dow with spoiv | 01:18 |
| lifeless | ddaa: and yes, the stuff that you are testing doesn't need the mirroring. | 01:19 |
| ddaa | lifeless: ha... I thought that spiv was tasked to "make taxi.py sort of work again" | 01:19 |
| lifeless | apparently the sqlobject stuff had thread safety issues. | 01:20 |
| ddaa | ho btw, I noticed that the slave bot tend to hang with a two zombie subprocs, on sh and one cvs... i would not be very surprised that the cscvs process handling stuff is making twisted unhappy... | 01:21 |
| lifeless | ddaa: you tracked down a hang on that? | 01:22 |
| ddaa | nope | 01:22 |
| ddaa | just a guess | 01:22 |
| lifeless | I've had a suspicion about it, but haven't verified it. Can't fix a guess. | 01:22 |
| lifeless | :) | 01:23 |
| ddaa | lifeless: that's exactly what I did with pyarch/twisted... | 01:23 |
| ddaa | "I guess that using twisted own process handling will make thing run more smoothly" | 01:23 |
| ddaa | and, surprise, it worked the first time | 01:23 |
| lifeless | ddaa: with pyarch I had verified it as being a problem - I threw logging statements before and after pyarch calls. | 01:23 |
| lifeless | and it consistent broke there. | 01:24 |
| ddaa | lifeless: oh ok | 01:24 |
| === ddaa goes back at putting zenity to sync | ||
| lifeless | so far, its not been breaking *for me* around similar popen calls in cvs. | 01:24 |
| ddaa | btw, I made a hack here so buildbot binds to localhost only | 01:25 |
| lifeless | if you can track down a hang there, that would be great - I'll port over your process handling asap. | 01:25 |
| ddaa | so it does not listen to the wild internet on my non-firewalled ubuntu system. | 01:26 |
| lifeless | aw man, kdelibs has a file kdecore/libintl.cpp.orig | 01:26 |
| lifeless | anyone spot the problem there ?! | 01:26 |
| ddaa | I do | 01:26 |
| ddaa | it will be moved to +conflicting-files or something, won't it? | 01:26 |
| lifeless | yeah, but the id remains. | 01:27 |
| lifeless | so you get a tree-lint error. | 01:27 |
| ddaa | that orig/rej handling behaviour in tla is soooo stupid... | 01:27 |
| lifeless | I don't agree. | 01:28 |
| ddaa | it's moving stuff around even when the inventory tells it's source. | 01:28 |
| ddaa | "if it source it belongs there, user said" | 01:28 |
| lifeless | the problem is that foo.c is patched by 'patch'. and patch created foo.c.orig and foo.c.rej. | 01:28 |
| ddaa | lifeless: that does not happen in your case | 01:29 |
| lifeless | having those files present in a 'names' or 'tagline' with 'untagged source source' would result in them being commited. | 01:29 |
| ddaa | so it's creating a problem in your case. | 01:29 |
| lifeless | ddaa: my case is irrelevant. its like commiting a dir called CVS to CVS. | 01:29 |
| lifeless | it can't do it. | 01:29 |
| ddaa | You can't commit .orig and .rej file to arch? Weird, i already commited {arch}/=tagging-methog.orig, of course the result was a corrupt archive since the revlib would not build. | 01:30 |
| ddaa | I just cachedrev to work around it. | 01:31 |
| ddaa | And the revlib would not build because tla moved the file around. | 01:31 |
| ddaa | even though it was source | 01:31 |
| lifeless | well, more accurately, if you manage to do it, you get trouble. | 01:31 |
| lifeless | I *can* go to a cvs repository and create a dir inthe repo called CVS | 01:32 |
| === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad | ||
| lifeless | and that similarly gives the system kiniptions. | 01:32 |
| ddaa | What causes trouble is that tla move source files when their name end in .orig or .rej. If the user says it's source, trust the user. | 01:32 |
| lifeless | ddaa: heres where I disagree. | 01:32 |
| ddaa | *shrug* | 01:33 |
| lifeless | tla should lift the semantic problems first. once that is done, your suggestion is viable. until then its just a can of corner cases. | 01:33 |
| lifeless | for instance, we could reserver ,,filename.orig and ,,filename.rej for tla. | 01:33 |
| lifeless | as we already have reserved ,,* for tla. | 01:34 |
| ddaa | Yup. Would be better. | 01:34 |
| ddaa | There's probably no one around except tom perverse enough to use such names. | 01:35 |
| ddaa | Yet I reckon the moving .orig files around causing breakage was hard to forsee for the arch designer. | 01:36 |
| ddaa | that's the kind of thing you think is perfectly reasonable until | 01:37 |
| ddaa | a use case comes where it's not... | 01:37 |
| lifeless | moving around was not the original behaviour | 01:37 |
| lifeless | it was a reaction to other negative behaivour... | 01:37 |
| ddaa | I was probably not there at the time... | 01:38 |
| ddaa | what was the issue? | 01:38 |
| lifeless | IIRC the original one was them being committed to tla. | 01:39 |
| lifeless | so then they got moved out of the way. | 01:39 |
| lifeless | rather than out of the namespace at creation. :{ | 01:40 |
| ddaa | That was before the inventory classification? | 01:40 |
| ddaa | Was not, because that still need "precious" logic to work... | 01:41 |
| lifeless | inventory is way back | 01:43 |
| ddaa | so... wrong solution... the right solution was to classify as non-source. | 01:43 |
| lifeless | but the defaults were older still | 01:43 |
| lifeless | and no, classifiying as non-source doesn't fix anything. | 01:44 |
| ddaa | it prevents the file from being commited | 01:44 |
| lifeless | but not from overwriting a possible users file, and not from the user changing the naming methods, and not the naming methods for existing archives. | 01:45 |
| ddaa | overwriting a possible user file: that's were the +conflict-file should trigger, not before | 01:46 |
| ddaa | changing the naming method: that's exactly my point, if I say those are source, they should be archived and handled correctly. | 01:46 |
| lifeless | ddaa: we're back full circle. | 01:47 |
| ddaa | lifeless: yes... I was expecting it... | 01:47 |
| ddaa | so, you just need to special-case your code to say that .orig and .rej file cannot possibly be source, and if someone is perverse enough to actually use a .orig suffix for a real source file, then you're screwed. | 01:49 |
| lifeless | well, I'm checking if thats what kdelibs do. | 01:49 |
| lifeless | or if its a glitch they would rather forget. | 01:50 |
| === ddaa lights a notional candle and notionally prays | ||
| ddaa | Tools that cause screwage are bad. Pyarch is bad for having a synchronous api, twisted is bad for causing other process handling schemes to break, sqlos is bad for having difficult thread safety problems, and tla is bad for messing around with .orig and .rej files. | 01:52 |
| lifeless | congratulations, you have just channeled asuffield. | 01:53 |
| lifeless | how do you feel? | 01:53 |
| ddaa | bad | 01:53 |
| ddaa | like the world is a big pile of steaming shit | 01:53 |
| ddaa | if asuffield feels like that all the time, I understand he's generally unfriendly. | 01:53 |
| ddaa | but I find the irony of it all funny :-D | 01:54 |
| === ddaa had blushed... | ||
| lifeless | omg. | 01:55 |
| lifeless | revision 1.1 | 01:55 |
| lifeless | date: 1998-06-03 21:04:23 +0000; author: kulow; state: Exp; | 01:55 |
| lifeless | true LPGL version of libintl. I'm almost sure, that this will cause major | 01:55 |
| lifeless | problems, but has one big advantage: we have no longer mixed licenses. | 01:55 |
| lifeless | Anyway, I've added the .orig file, so in trouble, the user can copy the | 01:55 |
| lifeless | .orig file back | 01:55 |
| lifeless | ==== | 01:56 |
| lifeless | the kde folk overloaded .orig in their tree. | 01:56 |
| === ddaa cackles | ||
| lifeless | the first patch failure they get, they'd be hosed. | 01:56 |
| lifeless | then 25 days later, they nuke it. | 01:56 |
| lifeless | ---------------------------- | 01:57 |
| lifeless | revision 1.2 | 01:57 |
| lifeless | date: 1998-06-28 22:18:05 +0000; author: garbanzo; state: dead; lines: +0 -0 | 01:57 |
| lifeless | *.orig and *.new don't really belong in here, and they're not being used | 01:57 |
| lifeless | anyways, so I'd just as soon sweep em into the Attic. | 01:57 |
| lifeless | ---------------------------- | 01:57 |
| lifeless | ok, time to teach cscvs that .orig and .rej should be ignored. | 01:57 |
| === ddaa still thinks that's not the Right solution | ||
| ddaa | <insert asuffield's rant about upstream being stupid and evil> | 01:58 |
| ddaa | lifeless: Exceptions.RuntimeError, No CVS Commits have occured, cannot perform incremntal totla | 01:59 |
| lifeless | ddaa: you know the right soluiton: alter tla to use ,,filename.{orig,rej}. update the move-conflictpatch files logic, update the default naming conventions. | 01:59 |
| lifeless | do we want to do this for 1 repository ? | 01:59 |
| lifeless | which 6 years ago for one month had a brain fart ? | 02:00 |
| ddaa | lifeless: that's not the right solution, i expect that will hose emacs diff-mode which handles .rej files by (i suppose) guessing the patch target from the name of the rej. | 02:01 |
| ddaa | and any other tool which does essentially the same thing. | 02:01 |
| ddaa | Except, if the ,,filename.rej file is altered to be a proper patch. | 02:02 |
| lifeless | ddaa: its the only solution that both prevents the user hosing their working tree and simultaneously allows them to put .orig and .rej files in the archive. | 02:02 |
| lifeless | in short, this isn't a trivial problem, and asserting that tla should 'just leave the files alone' isn't sufficient to fix it. | 02:02 |
| lifeless | your exception - the lastFoo method has failed to retrieve the incremental starting point. | 02:03 |
| ddaa | I'm all in favor of letting the user hose the tree if the inventory is altered so .orig/.rej files are source. You know, the sharp knives / dangerous tools stance. | 02:03 |
| lifeless | ddaa: we currently give people a bandsaw. And you want to make it worse ? | 02:04 |
| lifeless | I'm fully in favour of powerful tools, and *should they need to be* dangerous ones. | 02:04 |
| ddaa | Same thing as I said before. There should be something that is really a toolbox, and something that is really a user tool. The same tool cannot do both properly. | 02:04 |
| lifeless | ah yes - cscvs.arch.findLastCSCVSCommit | 02:05 |
| lifeless | that returned None, not the revision that was last commited to arch. | 02:05 |
| ddaa | Yet, you are correct that this discussion is not very relevant, since existing tools and practices effectively route most people around the problematic use cases. | 02:05 |
| lifeless | you should be able to just import it and execute it to see what the results are. | 02:05 |
| === jblack_ [~jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad | ||
| ddaa | ah... my fault... last time I tried to sync I had not set the syncingapproved and it nukedtargets then crashed because of the locked sqlite db. | 02:15 |
| ddaa | (which was locked because the previous run crashed on taxi.py) | 02:15 |
| ddaa | It's tricky to get that thing to run. | 02:17 |
| BradB | sabdfl: wasn't the adding of comments to a bug already working? i thought it may have been but it isn't anymore. | 02:31 |
| sabdfl | BradB: might have been broken with the skinning | 02:32 |
| sabdfl | underlying code might still work | 02:32 |
| sabdfl | check for a BugMessage addform | 02:32 |
| sabdfl | BradB: could you focus on email for this week? | 02:32 |
| sabdfl | i'll keep cleaning up the basics | 02:32 |
| sabdfl | sorry, got a bit lost on the artwork today | 02:33 |
| sabdfl | but i spent a lot of time on it over the weekend | 02:33 |
| BradB | sabdfl: that was my intent, so the first thing that seemed needing email notification was adding of comments. | 02:33 |
| BradB | but adding of comments doesn't work. | 02:33 |
| sabdfl | ah :-) | 02:35 |
| BradB | i also fixed subscriptions earlier, because notifications are pretty useless if people aren't able to subscribe. :) | 02:35 |
| sabdfl | BradB: i think they *do* work but the form is messed up | 02:35 |
| BradB | yeah, that's why i asked here next | 02:36 |
| BradB | hm | 02:36 |
| BradB | fixed. | 02:40 |
| === daf [daf@muse.19inch.net] has joined #launchpad | ||
| === justdave [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad | ||
| ddaa | lifeless: portd/JobStrategy.py, line 180 in getCVSTempRepoDirPath | 02:53 |
| ddaa | return os.path.join(self.getWorkingDir(self.aJob,self.dir), "cvs_temp | 02:54 |
| ddaa | exceptions.AttributeError: 'CVSStrategy' object has no attribute 'dir' | 02:54 |
| ddaa | I'm going to bed now. | 02:54 |
| ddaa | Just pointing out the problem. If you do not have the time to fix it, I'll do it tomorrow. | 02:55 |
| === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] | ||
| sabdfl | cheers guys, launch day tomorrow, need some sleep | 03:12 |
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: fixed adding comments to bugs (patch-634) | 03:28 | |
| === BradB is now known as BradB|away | ||
| === jblack_ is now known as jblack | ||
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/cscvs--devel--1.0: skip over .rej and .orig files in CVS repositories (patch-33) | 04:59 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/buildbot--devel--0: api update to latest cscvs (patch-60) | 05:21 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/buildbot--devel--0: restore setting the cscvs tree's logger (patch-61) | 05:38 | |
| stub | stub@belch ~ $ tla -V | 06:47 |
| stub | tla tla-1.2-4 from regexps.com | 06:47 |
| stub | Copyright 2003 Tom Lord | 06:47 |
| stub | This is free software; see the source for copying conditions. | 06:47 |
| stub | There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A | 06:47 |
| stub | PARTICULAR PURPOSE. | 06:47 |
| stub | Report bugs to lord@emf.net. | 06:47 |
| stub | # automatically generated release id (by arch-buildpackage) | 06:47 |
| stub | tla-1.2-4 | 06:47 |
| stub | lifeless: Before I go chasing why things are screwed at my end, is that correct? | 06:48 |
| lifeless | thats the standard ubuntu or debian build | 06:48 |
| lifeless | we are generally using integration, but - whats the problem ? | 06:48 |
| lifeless | (Is it the one I mailed you back about already?) | 06:48 |
| stub | The one I mailed you about (I think you were confused by by mail client helpfully word wrapping). But I'm getting the same error in launchpad, so something has changed between the last patch I committed yesterday and this morning. I was checking if a package upgrade had bit me without me realizing. | 06:51 |
| lifeless | the (null)/ bit in your log was definately wrong | 06:52 |
| jblack | what tla are you using? | 06:52 |
| lifeless | that (null) will cause the lookup for the signing rule to fail. | 06:52 |
| lifeless | do you see the same (null)/category--branch--version--patch-level in the launchpad corrupt checksum ? | 06:52 |
| lifeless | jblack: 1.2-4 - ubunut standard | 06:52 |
| lifeless | (where that (null) is, should have been the archive name - 'stuard.bishop@canonical.com') | 06:54 |
| jblack | Yeah. | 06:54 |
| === jblack looks up bofh... | ||
| jblack | Cosmic rays, stub. | 06:55 |
| jblack | More seriously, very weird. Can I see the log? | 06:55 |
| stub | lifeless: No - there is no null in the launchpad one. | 06:55 |
| lifeless | stub: eek. | 06:56 |
| lifeless | but its also not got the gpg lines around it ? | 06:56 |
| === lifeless hands over to jblack, as he's flat out | ||
| jblack | First time I've heard of anything like this. Nothing even close. | 06:57 |
| jblack | tla bombs if it can't figure out the version involved. | 06:57 |
| lifeless | jblack: try 'tla init-tree', 'tla import -S $fqversion' | 06:58 |
| lifeless | then check checksum in the base-0 | 06:58 |
| stub | -----BEGIN PGP SIGNED MESSAGE----- | 06:58 |
| stub | Hash: SHA1 | 06:58 |
| stub | Signature-for: stuart.bishop@canonical.com/cookiecrumbler--canonical--1.2--patch-3 | 06:58 |
| stub | md5 log b42f0da30042d2c99a3492293a5a7fb7 | 06:58 |
| stub | md5 cookiecrumbler--canonical--1.2--patch-3.patches.tar.gz aedf797c0b7536fd7043076990b4acd2 | 06:58 |
| stub | -----BEGIN PGP SIGNATURE----- | 06:58 |
| stub | Version: GnuPG v1.2.4 (GNU/Linux) | 06:58 |
| stub | iD8DBQFBZqpZAfqZj7rGN0oRAtcHAJ9nvP5ql3gzm9lwsMuc9n9TQZk7fACfSBDT | 06:58 |
| stub | vfPyu0fhr2x2+FVK3IGUeDU= | 06:58 |
| stub | =Kcvn | 06:58 |
| stub | -----END PGP SIGNATURE----- | 06:58 |
| lifeless | I advised stuart to use the normal way which is 'tla init-tree $fqversion' ; 'tla import -S' | 06:58 |
| stub | That is the checksum from a project I am sure hasn't been touched since it was working. Same error, so either my tla is screwed or I've screwed my config and don't remember doing it. | 06:59 |
| lifeless | stub: that looks fine syntax wise. | 06:59 |
| lifeless | cat $thatfile | gpg --verify-files - | 06:59 |
| jblack | my patch-log looks right for init-tree $fqv ; tla import -S | 07:00 |
| lifeless | it's signature-for line does not have (null)/.. ? | 07:00 |
| jblack | Though I'm using a newer gpg of course. | 07:00 |
| jblack | pardon, newer tla. | 07:00 |
| jblack | I didn't make a signed (duh) making | 07:01 |
| lifeless | jblack: hang on. | 07:01 |
| lifeless | 'init-tree $fqv ; tla import -S ' is known good | 07:01 |
| lifeless | its 'init tree'; 'tla import -S $fqversion' that is suspect | 07:02 |
| lifeless | stub: did that cat work ? | 07:02 |
| jblack | since when does import -S take an option ? | 07:03 |
| lifeless | year 0 | 07:03 |
| jblack | Doesn't improt here. | 07:03 |
| jblack | Doesn't improt here. "tla init-tree; tla import -S this--that--0" | 07:03 |
| jblack | reports no patchlog. | 07:03 |
| lifeless | but its not the recommended way because things between init-tree and import need the patch-log dir etc | 07:04 |
| jblack | and import -S doesn't take a fqvn argument. | 07:04 |
| lifeless | heh, well stub got a bad checksum in the archive. | 07:04 |
| jblack | Just checked the code. | 07:04 |
| lifeless | tla import [options] [[archive] /version] | 07:04 |
| lifeless | is the help. | 07:04 |
| lifeless | stub: ping | 07:06 |
| stub | lifeless: The cat worked | 07:06 |
| jblack | I can't reproduce his behavior here. | 07:06 |
| lifeless | ok, stub, now cat your ~/.arch-params/stuart@canonical.com.check file | 07:06 |
| jblack | not with my tla-dev, anyways | 07:06 |
| stub | I'm doing a tla get from rocketfuel@canonical.com-SOURCE - this should confirm if I have a corrupted archive or not. | 07:07 |
| lifeless | stub: hang on | 07:07 |
| lifeless | please | 07:07 |
| lifeless | lets work through this methodically. | 07:07 |
| lifeless | doing a get from -SOURCE *will not work*. | 07:07 |
| lifeless | you are thrashing, which helps noone. | 07:07 |
| lifeless | stub: so, please cat that file. | 07:07 |
| stub | I don't have a stuart@canonicalcom.check - just an =default.check. It contails just 'gnome-gpg --clearsign' | 07:07 |
| lifeless | stub: ok, thats not what we recommend. | 07:08 |
| lifeless | but, we can test if its working | 07:08 |
| lifeless | in fact. | 07:08 |
| lifeless | thats your problem. | 07:08 |
| lifeless | your default *check file* is *signing*. | 07:09 |
| lifeless | which will never work. | 07:09 |
| lifeless | the check file should be something like | 07:09 |
| lifeless | tla-gpg-check gpg_command="gpg --verify-files -q --no-show-notation --batch --no-tty " 2>&1 | grep "^gpg: Good signature from" 1>&2 | 07:09 |
| lifeless | with extra params if you are checking a specific archive to restrict the keys that can be used. | 07:10 |
| stub | Sorry - wrong file | 07:10 |
| stub | stub@belch ~/tmp $ cat ~/.arch-params/signing/=default.check | 07:10 |
| stub | #!/bin/sh | 07:10 |
| stub | tmp=$(mktemp tla-gpgout.XXXXXX) | 07:10 |
| stub | if ! gpg --batch --verify 1>"$tmp" 2>&1; then | 07:10 |
| stub | cat "$tmp" | 07:10 |
| stub | exit 1 | 07:10 |
| stub | fi | 07:10 |
| stub | rm -f "$tmp" | 07:10 |
| lifeless | omg | 07:10 |
| lifeless | where did you get that from ? | 07:10 |
| jblack | probably me | 07:10 |
| stub | Yu | 07:10 |
| stub | p | 07:10 |
| jblack | which goes all the way back to the orignal recommendations of keychecking. | 07:11 |
| lifeless | sh ~/.arch-params/signing/\=default.check <good checksum file> | 07:11 |
| stub | Anyway - I just checked our a revision from chinstrap and things look to be working fine. I think my archive is screwed. | 07:12 |
| lifeless | bah | 07:12 |
| lifeless | thats | 07:12 |
| lifeless | sh ~/.arch-params/signing/\=default.check < 'good checksum file' | 07:12 |
| lifeless | that will succeed or fail | 07:12 |
| lifeless | (good checksum file in your archive, obviously) | 07:13 |
| stub | sh ~/.arch-params/signing/\=default.check < /home/stub/.arch-archives/stuart.bishop\@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-271/checksum | 07:14 |
| stub | Works fine | 07:14 |
| lifeless | try this | 07:15 |
| lifeless | tla cat-archive-log stuart.bishop\@canonical.com/launchpad--devel--0--patch-271 | 07:15 |
| stub | $ tla cat-archive-log stuart.bishop\@canonical.com/launchpad--devel--0--patch-271 | 07:16 |
| stub | ******************************** | 07:16 |
| stub | INVALID CHECKSUM FILE SYNTAX FOR REVISION! | 07:16 |
| stub | archive: stuart.bishop@canonical.com | 07:16 |
| stub | revision launchpad--devel--0--patch-271 | 07:16 |
| stub | checksum file: checksum | 07:16 |
| stub | ******************************** | 07:16 |
| stub | trouble reading checksum file for stuart.bishop@canonical.com/launchpad--devel--0--patch-271 | 07:16 |
| lifeless | ok, can you paste the checksum file please | 07:16 |
| stub | stub@belch ~/launchpad/launchpad $ cat /home/stub/.arch-archives/stuart.bishop\@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-271/checksum-----BEGIN PGP SIGNED MESSAGE----- | 07:17 |
| stub | Hash: SHA1 | 07:17 |
| stub | Signature-for: stuart.bishop@canonical.com/launchpad--devel--0--patch-271 | 07:17 |
| stub | md5 log bf098182919c00fb76eabd690f0ea426 | 07:17 |
| stub | md5 launchpad--devel--0--patch-271.patches.tar.gz 0550eecf8e2860babf1d61e55a80f649 | 07:17 |
| stub | -----BEGIN PGP SIGNATURE----- | 07:17 |
| stub | Version: GnuPG v1.2.4 (GNU/Linux) | 07:17 |
| stub | iD8DBQFBc4BCAfqZj7rGN0oRAk3xAKCDHHaHsMG5bl9Ke34kRO+/GBvX9wCeIXRE | 07:17 |
| stub | 0gqPzMMbxHymwpMYmu5tMKo= | 07:17 |
| stub | =yr2h | 07:17 |
| stub | -----END PGP SIGNATURE----- | 07:17 |
| stub | stub@belch ~/launchpad/launchpad $ cat /home/stub/.arch-archives/stuart.bishop\@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-271/checksum | gpg --verify-files - | 07:18 |
| stub | gpg: Signature made Mon 18 Oct 2004 18:35:14 EST using DSA key ID BAC6374A | 07:18 |
| stub | gpg: Good signature from "Stuart Bishop <stuart@stuartbishop.net>" | 07:18 |
| stub | gpg: aka "Stuart Bishop <zen@shangri-la.dropbear.id.au>" | 07:18 |
| stub | gpg: aka "Stuart Bishop (dropbear.id.au Domain Admin) <hostmaster@dropbear.id.au>" | 07:18 |
| stub | gpg: aka "Stuart Bishop (Work) <stuart.b@commonground.com.au>" | 07:18 |
| stub | gpg: aka "Stuart Bishop (Work) <stuart.bishop@canonical.com>" | 07:18 |
| lifeless | ah | 07:19 |
| lifeless | nm | 07:20 |
| lifeless | that looks fine to me | 07:20 |
| lifeless | jblack: can you see anything? | 07:20 |
| jblack | lets md5 the files, and see which one mismatches. | 07:21 |
| jblack | maybe its a doublecacherev or something. | 07:21 |
| lifeless | nah | 07:22 |
| lifeless | that would spit out a different error | 07:22 |
| lifeless | stub: can you try patch-270 | 07:22 |
| lifeless | please ? | 07:22 |
| stub | stub@belch ~/tmp $ md5sum /home/stub/.arch-archives/stuart.bishop\@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-271/checksum 3fef8a3397c50797399d9a7956df99a9 /home/stub/.arch-archives/stuart.bishop@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-271/checksum | 07:22 |
| lifeless | just cat-archive-log ... patch-270 | 07:23 |
| jblack | invalid syntax... | 07:23 |
| stub | yup | 07:23 |
| lifeless | stub: works ? | 07:24 |
| stub | No - invaid revision name error | 07:24 |
| lifeless | tla cat-archive-log stuart.bishop\@canonical.com/launchpad--devel--0--patch-270 | 07:24 |
| stub | stub@belch ~/launchpad/launchpad $ tla cat-archive-log launchpad--devel--0--patch-270 | 07:24 |
| stub | ******************************** | 07:24 |
| stub | INVALID CHECKSUM FILE SYNTAX FOR REVISION! | 07:24 |
| stub | archive: stuart.bishop@canonical.com | 07:24 |
| stub | revision launchpad--devel--0--patch-270 | 07:24 |
| stub | checksum file: checksum | 07:24 |
| stub | ******************************** | 07:24 |
| stub | trouble reading checksum file for stuart.bishop@canonical.com/launchpad--devel--0--patch-270 | 07:24 |
| lifeless | ok that works for me on chinstrap. | 07:24 |
| lifeless | so its /not/ a f*cked archive. | 07:24 |
| lifeless | its almost certainly a f*cked gpg check rule | 07:25 |
| stub | I havn't mirrored it since it was working | 07:25 |
| lifeless | patch-270 is on chinstrap. | 07:25 |
| jblack | else if (file_contents && arch_pfs_memoize_checksum_file (arch->arch.name, | 07:25 |
| jblack | arch->arch.official_name, revision, file_contents)) | 07:25 |
| jblack | else if (file_contents && arch_pfs_memoize_checksum_file (arch->arch.name, | 07:25 |
| jblack | arch->arch.official_name, revision, file_contents)) | 07:25 |
| lifeless | which is why I asked you to check it. :) | 07:25 |
| stub | And the gpg check rule works file if I checkout someone elses stuff from chinstrap | 07:25 |
| lifeless | ls ~/.arch-params/signing | 07:25 |
| jblack | so arch_pfs_memoize_checksum_file is returning 1. | 07:26 |
| stub | stub@belch ~/launchpad/launchpad $ ls -al ~/.arch-params/signing/ | 07:26 |
| stub | total 28 | 07:26 |
| stub | drwxr-xr-x 2 stub stub 4096 2004-10-19 14:54 . | 07:26 |
| stub | drwx------ 4 stub stub 4096 2004-09-23 05:02 .. | 07:26 |
| stub | -rwxr-xr-x 1 stub stub 22 2004-10-19 15:03 =default | 07:26 |
| stub | -rwxr-xr-x 1 stub stub 131 2004-10-19 15:03 =default.check | 07:26 |
| stub | -rw-r--r-- 1 stub stub 28 2004-09-23 05:04 stuart.bishop@canonical.com-MIRROR | 07:26 |
| stub | -rw------- 1 stub stub 183 2004-10-19 14:54 tla-gpgout.IYPB0S | 07:26 |
| stub | -rw------- 1 stub stub 183 2004-10-19 14:53 tla-gpgout.OxzwWn | 07:26 |
| lifeless | stub: try this. | 07:27 |
| lifeless | tla cat-archive-log stuart.bishop\@canonical.com-MIRROR/launchpad--devel--0--patch-270 | 07:27 |
| lifeless | if that works, your local disk has gone wonky in some respect. | 07:27 |
| lifeless | if that doesn't work, its almost certainly gpg related, and we can check by making your check script a no-op. | 07:28 |
| stub | stub@belch ~/tmp/foo $ tla cat-archive-log stuart.bishop\@canonical.com-MIRROR/launchpad--devel--0--patch-270 | 07:28 |
| stub | Revision: launchpad--devel--0--patch-270 | 07:28 |
| stub | Archive: stuart.bishop@canonical.com | 07:28 |
| stub | Creator: Stuart Bishop <stuart.bishop@canonical.com> | 07:28 |
| stub | Date: Mon Oct 18 16:49:54 EST 2004 | 07:28 |
| stub | Standard-date: 2004-10-18 06:49:54 GMT | 07:28 |
| stub | Modified-files: lib/canonical/launchpad/database/person.py | 07:28 |
| stub | lib/canonical/launchpad/scripts/nicole/database.py | 07:28 |
| stub | lib/canonical/librarian/storage.py | 07:28 |
| stub | lib/canonical/lucille/TagFiles.py test_on_merge.py | 07:29 |
| stub | New-patches: stuart.bishop@canonical.com/launchpad--devel--0--patch-270 | 07:29 |
| lifeless | ok, this is kinda weird. | 07:29 |
| stub | Summary: Tabnanny putting on her jackboots for the whitespace impared | 07:29 |
| stub | Keywords: | 07:29 |
| stub | I also just created a fresh archive locally and it is working fine for some simple tests. | 07:29 |
| jblack | lifeless: arch_pfs_memoize_checksum_file is failing one of two regexes. | 07:29 |
| stub | You want I tar up my archive and email it to you? | 07:29 |
| lifeless | stub: I'd like you do copy down the checksum file from patch-270 on chinstrap, and compare it locally. | 07:29 |
| lifeless | I have to leave shortly for the stug group I'm talking at tonight. | 07:30 |
| lifeless | so mailing to me won't do you much good. | 07:30 |
| lifeless | jblack: yeah | 07:30 |
| stub | stub@belch ~/tmp/foo $ scp chinstrap.warthogs.hbd.com:/home/warthogs/archives/stuart.bishop@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-270/checksum checksum270.chinstrap | 07:33 |
| stub | checksum 100% 434 0.4KB/s 00:00 | 07:33 |
| stub | stub@belch ~/tmp/foo $ diff checksum270.chinstrap /home/stub/.arch-archives/stuart.bishop\@canonical.com/launchpad/launchpad--devel/launchpad--devel--0/patch-270/checksum | 07:33 |
| stub | stub@belch ~/tmp/foo $ | 07:33 |
| stub | They are identical | 07:33 |
| lifeless | ok, now that is plain old bizarre | 07:33 |
| stub | Brought to you by the user who first broke star-merge :-) | 07:34 |
| lifeless | jblack: can you please follow this through ? | 07:34 |
| jblack | I can try, but I'm rather lost. | 07:34 |
| lifeless | ok, summary: | 07:34 |
| lifeless | he can't access the revision ...-patch-270 | 07:35 |
| lifeless | locallay | 07:35 |
| jblack | but he can remotely. | 07:35 |
| lifeless | but he can when he does it via -MIRROR | 07:35 |
| lifeless | and the checksum is identical | 07:35 |
| lifeless | we haven't had stub cross-check the md5s in the checksum against the files on disc. | 07:35 |
| lifeless | (stub can you do that now) | 07:35 |
| stub | I would qualify that to 'I can't access any of the revisions or branches I have tried in that archive' | 07:36 |
| stub | launchpad--devel--0, cookiecrumbler--canonical--, etc. | 07:36 |
| jblack | stub: can we disclude obvious stuff, like you haven't played with permissions? | 07:36 |
| stub | Permissions on the archive look fine and I havn't messed with them | 07:37 |
| lifeless | in fact there is an interesting idea, stub if you have sshd running, you could register the local archive via sftp and see if that fixes it. | 07:37 |
| stub | And I have disk space | 07:37 |
| stub | Nope - I get the same checksum error if I access it via sftp | 07:39 |
| jblack | Its failing on either the revision, or on the official_archive search. | 07:39 |
| jblack | could it be that the checksum is saying its for a different archive than the name the archive is registered as? | 07:39 |
| stub | stub@belch ~ $ tla register-archive stuart.bishop@canonical.com-SFTP sftp://localhost/home/stub/.arch-archives/stuart.bishop@canonical.com | 07:39 |
| stub | stub@belch ~ $ cd tmp | 07:39 |
| stub | stub@belch ~/tmp $ tla get stuart.bishop@canonical.com-SFTP/launchpad--devel--0 | 07:39 |
| stub | Password: | 07:39 |
| stub | * ensuring library has stuart.bishop@canonical.com-SFTP/launchpad--devel--0--patch-271 | 07:39 |
| stub | ******************************** | 07:39 |
| stub | INVALID CHECKSUM FILE SYNTAX FOR REVISION! | 07:40 |
| stub | archive: stuart.bishop@canonical.com-SFTP | 07:40 |
| stub | revision launchpad--devel--0--patch-271 | 07:40 |
| stub | checksum file: checksum | 07:40 |
| stub | ******************************** | 07:40 |
| stub | trouble reading checksum file for stuart.bishop@canonical.com-SFTP/launchpad--devel--0--patch-271 | 07:40 |
| stub | stub@belch ~/tmp $ | 07:40 |
| lifeless | stub, please stay with the cat-archive-log ....-patch-270 as the test | 07:40 |
| lifeless | as 270 is known good, 271 isn't. | 07:40 |
| lifeless | you may have several things wrong. | 07:40 |
| jblack | For your mirror, what is =meta-info/name ? | 07:40 |
| stub | stub@belch ~/tmp $ tla cat-archive-log stuart.bishop\@canonical.com-SFTP/launchpad--devel--0--patch-270 | 07:41 |
| stub | Password: | 07:41 |
| stub | ******************************** | 07:41 |
| stub | INVALID CHECKSUM FILE SYNTAX FOR REVISION! | 07:41 |
| stub | archive: stuart.bishop@canonical.com-SFTP | 07:41 |
| stub | revision launchpad--devel--0--patch-270 | 07:41 |
| stub | checksum file: checksum | 07:41 |
| stub | ******************************** | 07:41 |
| stub | trouble reading checksum file for stuart.bishop@canonical.com-SFTP/launchpad--devel--0--patch-270 | 07:41 |
| stub | jblack: My mirror on chinstrap you mean? | 07:41 |
| lifeless | jblack: very interesting that sftp access to the local one also fails. | 07:42 |
| jblack | lifeless: Yeah. | 07:42 |
| lifeless | so the same code path, with the two archives, fails. | 07:42 |
| lifeless | and the checksum files are the same. | 07:42 |
| lifeless | I'll butt out now. | 07:43 |
| jblack | To restate, he can get from his mirror, but not from his original archive. | 07:43 |
| lifeless | following the tla code is probably the right thing. :0 | 07:43 |
| jblack | stub: =meta-info/name for both, please | 07:43 |
| lifeless | jblack is there a tla command to show that? | 07:43 |
| lifeless | tla meta-info-file or something right ? | 07:44 |
| jblack | not listed in the help. | 07:44 |
| stub | Am I supposed to have ~/.arch-archives/stuart.bishop@canonical.com/=meta-info ? If so, that might be the problem. | 07:44 |
| jblack | I seem to remember that ddaa uses something with pyarch though... | 07:44 |
| jblack | there's a cmd-archive-meta-info.c | 07:45 |
| lifeless | stub: erm YES YOU ARE | 07:45 |
| stub | lifeless: Ok. Then we have found the cause. It aint there. | 07:45 |
| lifeless | stub: copy the \=meta-info dir from chinstrap to yours | 07:45 |
| jblack | lifeless: And that's why the regex fails. :) | 07:46 |
| lifeless | then remove the single file called 'master' | 07:46 |
| lifeless | sorry, 'mirror' | 07:46 |
| lifeless | jblack: yup. | 07:46 |
| lifeless | what a mindblowing bad error-report from tla. | 07:46 |
| jblack | Oh, I don't think so. | 07:46 |
| jblack | Well, yeah. | 07:46 |
| lifeless | yeah, that should be 'corrupt arhcive' right from the get go. | 07:46 |
| jblack | But a reasonable screw up. The only way for =meta-info not to be there is for someone or something to rm it. | 07:47 |
| stub | Should I nuke the mirror file in there on my local copy? | 07:47 |
| lifeless | ack on the screwup bit. | 07:47 |
| lifeless | stub: yes, only in the local copy | 07:47 |
| lifeless | don't alter anything on chinstrap | 07:47 |
| stub | stub@belch ~ $ tla cat-archive-log stuart.bishop\@canonical.com/launchpad--devel--0--patch-270 | 07:48 |
| stub | Revision: launchpad--devel--0--patch-270 | 07:48 |
| stub | Archive: stuart.bishop@canonical.com | 07:48 |
| stub | Creator: Stuart Bishop <stuart.bishop@canonical.com> | 07:48 |
| stub | Date: Mon Oct 18 16:49:54 EST 2004 | 07:48 |
| stub | Standard-date: 2004-10-18 06:49:54 GMT | 07:48 |
| stub | Modified-files: lib/canonical/launchpad/database/person.py | 07:48 |
| stub | lib/canonical/launchpad/scripts/nicole/database.py | 07:48 |
| stub | lib/canonical/librarian/storage.py | 07:48 |
| stub | lib/canonical/lucille/TagFiles.py test_on_merge.py | 07:48 |
| stub | New-patches: stuart.bishop@canonical.com/launchpad--devel--0--patch-270 | 07:48 |
| stub | Summary: Tabnanny putting on her jackboots for the whitespace impared | 07:48 |
| stub | Keywords: | 07:48 |
| lifeless | yay | 07:49 |
| stub | I suspect I should rsync from chinstrap to ensure nothing else is missing? | 07:49 |
| lifeless | stub: check the new imports and so on. | 07:49 |
| === jblack grumbles something about "Don't go into archive dirs and changing/removing files" | ||
| lifeless | no, don't | 07:49 |
| lifeless | that will bring across archive lock dirs | 07:49 |
| lifeless | any imports/commits during this period, you should check the checksums for (null) | 07:50 |
| lifeless | if they have (null) replace it with the archive name, and regenerate the gpg signature around it | 07:50 |
| jblack | just make sure you have name and signed-archive in =meta-info on both. | 07:50 |
| lifeless | jblack can help if you need ot do that | 07:50 |
| jblack | lifless: Oh, and that explains the (null) too. | 07:50 |
| lifeless | exactly | 07:50 |
| lifeless | permitting that in the first place is a major bug IMO | 07:51 |
| jblack | I've already got up a postit to do more =meta-info checks | 07:51 |
| stub | I'm not worried about recent commits or anything, since none of them worked :-) More that whatever nuked =meta-info might have nuked bits and pieces elsewhere (although I supposed the checksums should see to that now they are working) | 07:51 |
| jblack | stub: Ok. Cheat. | 07:52 |
| jblack | steal tla's archive check script. | 07:52 |
| jblack | That will sanity check the archive. | 07:52 |
| jblack | =gpgcheck.awk or somesuch. | 07:52 |
| lifeless | that doesn't check the archive tough IIRC - it only checks for gpg issues | 07:52 |
| lifeless | wouldn't have helped here. | 07:53 |
| jblack | it doesn't check md5s? | 07:53 |
| jblack | sure doesn't. | 07:53 |
| lifeless | no, its a wrapper script. | 07:53 |
| jblack | Oh. I know. :) | 07:53 |
| jblack | really lazy way. | 07:53 |
| stub | Hmm... the most reasonable explanation for it missing is my fingers slipping when I was removing branches trying to get my import working nicely (although I can't think how I managed to only remove a single file rather than the entire damn archive) | 07:53 |
| jblack | try a get on every branch in your archive. | 07:53 |
| lifeless | omg StringIO is slow | 07:55 |
| jblack | mkdir test; cd test; tla abrowse stuart.bishop@canonical.com | grep -- --.*-- | xargs -n1 tla get | 07:55 |
| stub | lifeless: You know about cStringIO ? | 07:56 |
| stub | jblack: ta. I didn't want to have to figure that out myself :-) | 07:56 |
| lifeless | stub: nope faster I presume ? | 07:56 |
| jblack | if any of the gets fail, then we'll fix it. If not, you're gtg | 07:56 |
| stub | lifeless: Yes - part of the standard library. Doesn't handle unicode strings though. | 07:56 |
| lifeless | how much faster? | 07:57 |
| jblack | While you're getting, I'm going to hit the local denny's for coffee and a burger, ok? | 07:57 |
| stub | Lots and lots faster | 07:57 |
| stub | (thats a technical term) | 07:57 |
| jblack | like x86 over os x faster ? | 07:57 |
| lifeless | lots n lots daddy | 07:57 |
| stub | Just use 'from cStringIO import StringIO' instead of 'from StringIO import StringIO' | 07:58 |
| jblack | stub: if you have a problem doing those gets, send email to jblackphone@linuxguru.net with a short ( <100 character) message ? | 08:01 |
| stub | Gets all ran fine except for one dummy branch I created to to help diagnose the problem, now nuked. | 08:05 |
| jblack | ok. then you're cleared for flight | 08:06 |
| === justdave [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad | ||
| === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| ddaa | Hello launchers. | 09:52 |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === limi [~limi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad | ||
| Kinnison | Morning | 10:40 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 10:57 |
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| Kinnison | Morning sabdfl | 10:58 |
| sabdfl | morning all | 10:58 |
| sabdfl | lifeless: around? | 10:58 |
| === ..[topic/#launchpad:sabdfl] : lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily, egged on by SteveA" | ||
| Kinnison | mmmm eggs | 11:02 |
| sabdfl | arch help, anyone? | 11:03 |
| sabdfl | ddaa? | 11:03 |
| Kinnison | is it scary stuff, or might I be able to help? | 11:04 |
| sabdfl | scary stuff | 11:04 |
| sabdfl | signature and checksum failures | 11:04 |
| Kinnison | merfle | 11:05 |
| === ..[topic/#launchpad:sabdfl] : lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily, with SteveA egging us on" | ||
| sabdfl | Kinnison: is your "drop my changes rather than everyone elses changes" star-merge script on the wiki? | 11:07 |
| sabdfl | has it been blessed by an arch god? | 11:07 |
| Kinnison | no and no | 11:07 |
| sabdfl | 'k | 11:07 |
| Kinnison | a version which doesn't automatically check for conflicts is in launchpad/utilities/arch/dsilvers | 11:07 |
| Kinnison | but it is not blessed | 11:07 |
| sabdfl | isn't the default in launhcpad now to refuse commit if you have .orig or .rej lying around? | 11:08 |
| Kinnison | one of stub or spiv was playing with that. I don't know if they committed it | 11:08 |
| Kinnison | unrecognized ^.*(\.orig|\.rej)$ | 11:09 |
| Kinnison | Looks like it is in | 11:09 |
| stub | Not me - I don't know arch that well | 11:09 |
| Kinnison | Today, I will be mostly generating override files | 11:09 |
| sabdfl | morning stub | 11:10 |
| ddaa | sabdfl: I, jblack and bob2 are just out of team meeting. | 11:10 |
| sabdfl | ok | 11:10 |
| sabdfl | we have.... limi arch problems! | 11:10 |
| limi | yay! | 11:11 |
| sabdfl | he was using tla 1.2.0 on ppc, now upgraded to 1.2.1 | 11:11 |
| jblack | limi! There you are. I have more questions for you on that subject. | 11:11 |
| sabdfl | just tagging off lp--devel--0 is failing | 11:11 |
| sabdfl | with checksum errors, inode errors, signature verification errors, it's a mess | 11:11 |
| sabdfl | have blown away the revision library | 11:11 |
| jblack | Really. | 11:11 |
| === ddaa suggests using 1.2.2rc2 that's definitely what works best | ||
| sabdfl | and tagged off launchpad--devel--0 into an entirely new branch, and even that did not work | 11:12 |
| ddaa | it's not official by any mean, but it's the best release around. | 11:12 |
| sabdfl | it's not available for ppc afaik | 11:12 |
| jblack | sabdfl: It builds on ppc. | 11:12 |
| jblack | but that probably won't fix these problems. | 11:12 |
| jblack | Lets hit it a step at a time. | 11:13 |
| jblack | limi, are you here? | 11:13 |
| limi | yup | 11:13 |
| jblack | Which archive is this you're having problems with? Yours, or rocketfuel's ? | 11:13 |
| limi | how can I find out? :) | 11:13 |
| jblack | by telling me which one you're trying to get from. | 11:14 |
| === ddaa leaves the matter in jblack's competent hands, but will be monitoring. | ||
| sabdfl | i did tla tag -S rocketfuel@canonical.com/launchpad--devel--0 a.l@canonical.com--2004/launchpad--devel2--0 | 11:14 |
| sabdfl | to get a brand new branch that limi could work on without disturbing previous branches | 11:14 |
| limi | and error msg is: | 11:15 |
| sabdfl | it failed | 11:15 |
| limi | INVALID SIGNATURE ON REVISION! | 11:15 |
| limi | archive: rocketfuel@canonical.com | 11:15 |
| limi | revision launchpad--devel--0--patch-248 | 11:15 |
| limi | checksum file: checksum | 11:15 |
| sabdfl | last night, we were getting similar messages on the old branch too, during star-merge | 11:15 |
| jblack | sabdfl: You were tagging in limi's archive? Are you guys in the same place or something, or did you mirror him and then drop the mirror file? | 11:15 |
| sabdfl | jblack: i'm sitting next to him, typing on his computer | 11:16 |
| jblack | Ok. Maybe his signature checker is wrong. | 11:16 |
| jblack | first, can he get from rocketfuel, such as "tla get rocketfuel@canonical.com/launchpad--devel--0" ? | 11:16 |
| sabdfl | works for about 280 patches, then fails? | 11:16 |
| jblack | would you remember the patchnumber? | 11:17 |
| limi | trying to do it again with 1.2.1 now, seems to get further | 11:17 |
| jblack | Ok. To what revision in 1.2.1 ? | 11:18 |
| limi | still working | 11:19 |
| sabdfl | ok, seems to have got as far as starting to do the patches this time | 11:19 |
| sabdfl | 1.2.1 seems better than 1.2.0 | 11:19 |
| === jblack smiles happily hearing that. | ||
| sabdfl | jblack: what's the latest public release of tla? | 11:22 |
| jblack | There's two, the one I did, and then the one Tom did. | 11:22 |
| jblack | The lastest one I made was 1.2.2rc2 | 11:23 |
| === lifeless_ [~robertc@dsl-69.8.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad | ||
| sabdfl | and toms? | 11:23 |
| jblack | his hosed 1.2.1 | 11:23 |
| ddaa | there are two 1.2.1, jblack's, on tom's. jblack's is the good one. | 11:24 |
| jblack | There's a big problem in his 1.2.1. He took some patches that weren't ready yet that is a bit too severe with truncated checksums. | 11:24 |
| === jblack waves to lifeless. | ||
| jblack | limi: still getting? | 11:24 |
| ddaa | so, current sane tla = 1.2.2rc2 | 11:25 |
| sabdfl | jblack: so if limi is using 1.2.1 which version of 1.2.1 is he using? | 11:25 |
| sabdfl | and why do we only have 1.2 in warty? | 11:25 |
| limi | jblack: still getting | 11:25 |
| jblack | Yeah. There's a small bug in 1.2.2rc2, but it only affects 10% of the people in 10% of the time, and in a safe way. | 11:25 |
| jblack | sabdfl: I'll defer to lifeless on that. | 11:25 |
| jblack | Actually, I won't. | 11:26 |
| ddaa | sabdfl: probably because asuffield, who is the debian maintainer, tracks tom. | 11:26 |
| jblack | Lifeless and I are avoiding a power struggle with Tom. | 11:26 |
| jblack | The arch release process is just starting to get going again. | 11:26 |
| jblack | If we start pushing a fork, we throw everything back into chaos. | 11:26 |
| sabdfl | ok, we're still going to do a public integration / community build right? | 11:26 |
| sabdfl | as discussed? | 11:27 |
| jblack | I've still got plans for that, yes. | 11:27 |
| sabdfl | spiv: around? | 11:27 |
| (spiv/#launchpad) sabdfl: Just waking up, yeah. | 11:27 | |
| jblack | And I'll act on that if you wish, but my recommendation is to wait about 3 weeks, and give the new merge process a fair shot. | 11:27 |
| sabdfl | this came in last night, was it from you? | 11:28 |
| sabdfl | @@ -132,7 +135,8 @@ | 11:28 |
| sabdfl | return { | 11:28 |
| sabdfl | 'id': personID, | 11:28 |
| sabdfl | 'displayname': displaynameOrig, | 11:28 |
| sabdfl | - 'emailaddresses': list(emailAddresses) | 11:28 |
| sabdfl | + 'emailaddresses': list(emailAddresses), | 11:28 |
| sabdfl | + 'salt': saltFromDigest(sshaDigestedPassword), | 11:28 |
| sabdfl | } | 11:28 |
| sabdfl | def changePassword(self, loginID, sshaDigestedPassword, | 11:28 |
| sabdfl | jblack: if there's a new merge process let's pursue that | 11:28 |
| (spiv/#launchpad) sabdfl: Yep. | 11:28 | |
| jblack | Yes sir. I'll make sure you're up to date as to how its working out. | 11:28 |
| sabdfl | but i'm losing patience with tom w.r.t. arch, and am starting to think it's inevitable that we put out a regular release | 11:29 |
| sabdfl | a little competition is healthy, as you've seen | 11:29 |
| ddaa | it's not making any public progress yet, but it's not right time to step out with a new integration branch. That could be perceived as sabotage. | 11:29 |
| limi | (still patching) | 11:29 |
| ddaa | sabdfl++ | 11:29 |
| stub | Is the existing arch community large enough that its perceptions actually matter? | 11:29 |
| sabdfl | ddaa: yes, and has to be handled carefully, but tla has stagnated and unless this new process gets it going i'll risk that perception in favour of actually getting the tool usable | 11:30 |
| jblack | sabdfl: I'm agree with you. But the timing isn't quite right. If we push at this exact moment, we may not carry the community with us, and then you're paying for a lot of development you could otherwise get for free. | 11:30 |
| sabdfl | spiv: where is the salt getting used? | 11:30 |
| (spiv/#launchpad) sabdfl: It's handed back to the XML-RPC caller. | 11:30 | |
| sabdfl | jblack: understood, keep me posted | 11:30 |
| sabdfl | spiv: why? | 11:30 |
| (spiv/#launchpad) I added it there to be consistent the return value from everywhere else. | 11:31 | |
| sabdfl | we should never expose salt | 11:31 |
| ddaa | stub: i'm not sure what you mean. Tla is defined by what tom puts on gnu.org. And gets some non-trivial public coverage. | 11:31 |
| (spiv/#launchpad) sabdfl: The salt is the only way the caller can generate a matching digest. | 11:31 | |
| sabdfl | SteveA and i discussed this at length and agreed to change the protocol | 11:31 |
| sabdfl | the caller should not be generating the digest | 11:31 |
| sabdfl | the caller gives credentials (username, password) and you then calculate the match yourself | 11:31 |
| (spiv/#launchpad) Then the caller needs to send the password cleartext. | 11:31 | |
| (spiv/#launchpad) I'm happy for that to change, but it's the first I've heard of it :) | 11:32 | |
| (spiv/#launchpad) It'll also need changes on Roche's end. | 11:32 | |
| sabdfl | spiv: either use tls, or public key encrypt the credentials in transit, at your option, but don't expose the salt | 11:32 |
| sabdfl | i nearly fell off my chair when i realised we were passing the salt around | 11:32 |
| (spiv/#launchpad) sabdfl: I'm not sure why exposing the salt is such a big problem? | 11:33 | |
| sabdfl | spiv: salt is there as a last-minute defense | 11:33 |
| sabdfl | no sense in giving it away | 11:33 |
| jblack | limi: still going ? | 11:33 |
| limi | just finished | 11:34 |
| jblack | so you're good? | 11:34 |
| limi | * Made cached revision of alexander.limi@canonical.com--2004/launchpad--devel2--0--base-0 | 11:34 |
| jblack | Ok. Are you using libraries? | 11:35 |
| sabdfl | spiv: your other option is to store the username and password in the clear | 11:35 |
| limi | "How can I find out?" | 11:35 |
| jblack | If not, we should set you up with sparse greedy libraries. That'll speed you up dramatically. | 11:35 |
| limi | :] | 11:35 |
| sabdfl | then to generate a random salt for every connection | 11:35 |
| sabdfl | pass that salt to them | 11:35 |
| sabdfl | have them also generate a salt | 11:35 |
| limi | I think I am running greedy sparse | 11:35 |
| stub | ddaa: Let me put it this way - if arch split into gnu-arch and sane-arch, and worst case every arch user outside of cononical stuck with gnu-arch, would sane-arch still attract more users over the long term? If sane-arch actually has a measurable uptake (unlike gnu-arch), it will smother it. I suspect a split might encourage new people to come over to arch (or refugees from arch comming back). | 11:35 |
| (dilys/#launchpad) Bug 1918 resolved: implement XML-RPC authentication server | 11:35 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1918 | 11:35 | |
| sabdfl | then they send you their salt plus the digest of credentials and both salts | 11:35 |
| jblack | type tla my-revision-library. Do you get a directory? | 11:35 |
| ddaa | jblack: sabdfl rm'ed the lib because they had a inode corruption errors. | 11:36 |
| (spiv/#launchpad) sabdfl: I'm not sure that a salt from both ends makes sense there -- surely in that case the salt is only good to protect against replay attacks? | 11:36 | |
| limi | $ tla my-revision-library | 11:36 |
| limi | $ tla my-revision-library | 11:36 |
| limi | /opt/local/bin/revision-library | 11:36 |
| limi | /Users/limi/Work/Canonical/revision-library | 11:36 |
| sabdfl | spiv: user generates own salt to reduce dictionary attacks by man in the middle | 11:36 |
| jblack | Ok. for both of those, type "tla library-config <dirname>" | 11:36 |
| jblack | And just to make sure, neither of those are on nfs, right? | 11:37 |
| ddaa | stub: you only want to make a split if the company is willing to invest a substantial amount of the arch team time into developing it. | 11:37 |
| sabdfl | say a mitm send you a carefully crafted salt, which when used as a salt will in fact expose the credentials | 11:37 |
| ddaa | st | 11:37 |
| sabdfl | you generate your own random salt | 11:37 |
| (spiv/#launchpad) sabdfl: That's sounding excessively complex for note enough gain to me... we should just go for ssl/tls in that case. | 11:37 | |
| sabdfl | that way you *know* your credentials are never exposed | 11:37 |
| ddaa | stub: besides it's probably better to avoid such a solution as long as possible. | 11:37 |
| limi | * library /Users/limi/Work/Canonical/revision-library | 11:37 |
| limi | greedy? yes | 11:37 |
| limi | sparse? yes | 11:37 |
| sabdfl | spiv: i'm not telling you what to do, just telling you what your options are | 11:37 |
| limi | $ tla library-config /opt/local/bin/revision-library | 11:38 |
| limi | tla: indicated library is not on library path | 11:38 |
| limi | dir /opt/local/bin/revision-library | 11:38 |
| (spiv/#launchpad) sabdfl: Sure. Just giving my opinion on the options :) | 11:38 | |
| sabdfl | thawte.com school of cryptography | 11:38 |
| jblack | LOL! I suppose you would an authority. :) | 11:38 |
| (spiv/#launchpad) SSL would be easy to do on the server end. I'm not sure how easy it is to do on the client end with out-of-the-box xmlrpclib, but I'm sure it can be done. | 11:39 | |
| ddaa | jblack: a signing authority in that case :-P | 11:39 |
| jblack | limi: Sorry. Missed your answer. | 11:40 |
| jblack | Ok. I suggest going to sparse greedy libraries. | 11:41 |
| jblack | and I'd remove the library that doesn't exist as well. | 11:41 |
| jblack | tla library-config --sparse /Users/limi/Work/Canonical/revision-library | 11:42 |
| jblack | tla my-revision-library -d /opt/local/bin/revision-library | 11:42 |
| ddaa | jblack: the lib was already greedy sparse :-) | 11:44 |
| jblack | and now it'll be extra sparse! | 11:44 |
| jblack | (sorry limi. Getting tired on this side) | 11:44 |
| limi | thanks, seems things are under control again | 11:45 |
| jblack | Ok. | 11:45 |
| jblack | You know how to reach me for emergencies? | 11:45 |
| === ddaa missed what was done to fix the checksum errors | ||
| jblack | he went from 1.2.0 to 1.2.1, and the problem magically disapeared. | 11:48 |
| jblack | just as a reminder, if you need to reach me during an emergency, send a short ( < 100 character) email to jblackphone@linuxguru.net | 11:50 |
| jblack | chances are good (but not 1.0) that I'll respond. | 11:51 |
| ddaa | duh! | 11:54 |
| ddaa | That code cannot possibly work for syncs!!! | 11:55 |
| ddaa | lifeless_: CSCVSStrategy.sync is emphy | 12:06 |
| ddaa | is that normal, or is that result of some error? | 12:06 |
| limi | jblack: thanks | 12:07 |
| ddaa | How can syncs possibly work if the .dir, .aJob and .logger instance variables are not set? | 12:07 |
| limi | ddaa: we also blew away my entire local setup before upgrading to 1.2.1 | 12:07 |
| ddaa | lifeless_: I'm going to examine the history, but you might save me some time. | 12:07 |
| ddaa | limi: next time you have some time, upgrade to 1.2.2rc2, it's significantly better in the error reporting dept. | 12:08 |
| limi | well, I tend to stick to what's available in my ports tree | 12:09 |
| limi | compiling arch was non-trivial the last time I tried it | 12:09 |
| ddaa | ha... OS X.. last time I looked (back in the texmacs days) compiling random unix stuff just did not work. The build system apparently required some black magic... | 12:10 |
| ddaa | Since that, I no longer buy it when someon says "osx is just a bsd variant" | 12:11 |
| ddaa | in my experience it's a horribly mutilated bsd variant if anything | 12:11 |
| ddaa | (but maybe the situation have improved) | 12:11 |
| ddaa | *has improved | 12:12 |
| sabdfl | what's the shell magic to say "if there's a .rej or .orig file"? | 12:12 |
| limi | it has | 12:12 |
| limi | only arch that doesn't build ;) | 12:12 |
| Kinnison | FOO=`find . -name "*.rej" -o -name "*.orig"` | 12:13 |
| ddaa | sabdfl: you prolly want something along "tla inventory -b | egrep -e '\.(rej|orig)$'' | 12:13 |
| Kinnison | if [ "x$FOO" = "x" ] ; then | 12:13 |
| Kinnison | # no .rej or .orig | 12:13 |
| Kinnison | else | 12:13 |
| ddaa | Kinnison: no find, tla inventory | 12:13 |
| Kinnison | # some .rej or .orig | 12:14 |
| Kinnison | fi | 12:14 |
| Kinnison | ddaa: feh; no context == generic answer :-) | 12:14 |
| ddaa | sabdfl: unless that's one of those trees where rejects are classified as unrecognized, spiv did that to launchpad at a point. | 12:15 |
| sabdfl | Kinnison: thanks | 12:15 |
| ddaa | I dunno if it was reverted. | 12:15 |
| sabdfl | so find doesn't give a useful exit code? | 12:15 |
| ddaa | In that case it would be "tla inventory -u" instead of -b | 12:15 |
| ddaa | sabdfl: egrep does, and tla inventory saves you the traversal of {arch} | 12:16 |
| ddaa | just "tla inventory" w/o option would do it as well in your case. | 12:17 |
| ddaa | if tla inventory -b | egrep -e '\.(rej|orig)$ ; then <rejects> ; else <no rejects> ; fi | 12:19 |
| ddaa | ooops | 12:19 |
| ddaa | if tla inventory | egrep -e '\.(rej|orig)$' ; then <rejects> ; else <no rejects> ; fi | 12:19 |
| === ddaa realizes he was probably inaccurate with this statement about not traversing {arch} | ||
| sabdfl | does make check give a useful result code? | 12:26 |
| ddaa | Yes, pqm relies on it. | 12:26 |
| limi | stub: how do I set up the plpython stuff? | 12:30 |
| sabdfl | stub, BradB|away: we've got limi up again but can't test anything till we get plpython running | 12:32 |
| sabdfl | on macosx | 12:32 |
| sabdfl | any tips? | 12:32 |
| limi | i guess we need to rebuild postgres | 12:39 |
| limi | with python support | 12:40 |
| Kinnison | comment it out of the makefile | 12:40 |
| Kinnison | they're not *needed* for now IIRC | 12:40 |
| sabdfl | what was the resolution for finding a python apt_pkg on macosx? | 12:46 |
| carlos | sabdfl: fink.sf.net | 12:59 |
| sabdfl | carlos: thanks | 01:03 |
| sabdfl | limi: can you look for python-apt on fink? | 01:03 |
| stub | Running the makefile with the plpython commented out should work - it just means some database constraints won't exist atm. | 01:03 |
| limi | I need to install fink then - but, sure | 01:04 |
| stub | I'd suggest seeing if DarwinPorts (which I think limi is already running) has the python stuff though - I never had much success with fink's postgresql stuff (it never got out of unstable for a start) | 01:04 |
| limi | I tried, only found the ruby bindings in DP | 01:06 |
| sabdfl | stub: we found an apt in darwin ports, not sure if that has hte python-apt module | 01:07 |
| === limi is not a big fan of fink either | ||
| stub | It would also be trivial to remove the dependancy on it at this stage - it just restricts us a bit in the future and means we will start having pl/sql code in the codebase | 01:07 |
| sabdfl | plpython wasn't too hard | 01:07 |
| limi | (if it works :) | 01:07 |
| sabdfl | but it's python-apt which the soyuz guys use which we now need to solve | 01:07 |
| stub | limi: What is the error message you get when it tries to run createlang? There is a chance it is installed and something else is going wrong | 01:08 |
| sabdfl | could be permissions again, though limi is running pg_ctl start as his local user, so he should be postgres superuser too right? | 01:08 |
| limi | createlang? haven't seen that error msg | 01:09 |
| stub | darwinports seems setup to let you do everything as the localuser. | 01:09 |
| === limi is downloading Fink to look for py-apt | ||
| ddaa | Please someone who has access to the production database tell me the output of: | 01:10 |
| stub | createlang is the command the makefile runs to make plpythonu available in the launchpad_test database. If the error message is from something else, it isn't a plpythonu problem | 01:10 |
| ddaa | select name, cvsroot from sourcesource where name like 'zenity%' ; | 01:10 |
| ddaa | and then "select * from sourcesource where name like 'zenity%'" | 01:11 |
| (spiv/#launchpad) ddaa: zenity-HEAD-import.job | http://chinstrap.warthogs.hbd.com/~jdub/cvsballs/zenity.tar.bz2 | 01:11 | |
| stub | zenity-HEAD-import.job | http://chinstrap.warthogs.hbd.com/~jdub/cvsballs/zenity.tar.bz2 | 01:12 |
| ddaa | spiv: and what are all the fields? | 01:12 |
| (spiv/#launchpad) ddaa: More than I'd like to paste on IRC ;) | 01:12 | |
| (spiv/#launchpad) privmsg? | 01:13 | |
| ddaa | spiv: then paste on jabber please | 01:13 |
| (spiv/#launchpad) Jabber, ok. | 01:13 | |
| ddaa | q | 01:13 |
| Kinnison | ddaa: any idea how the backbuilder stuff is going? | 01:18 |
| ddaa | abentley is using it for himself, but it's not being merged because it was not regression-tested. | 01:24 |
| ddaa | And if/when it breaks, it would break silently and severely (data loss) | 01:24 |
| Kinnison | merp | 01:24 |
| === ddaa is out for lunch | ||
| sabdfl | what's the backbuilder? | 01:25 |
| Kinnison | It an extension to allow tla to build patch-X from patch-(X+1) by reverse-application of patches | 01:25 |
| Kinnison | AIUI | 01:26 |
| ddaa | actually, from patch-(X+N) and even across version boundaries. | 01:26 |
| ddaa | hairy, and in a critical part, so to be handled with extreme caution. | 01:27 |
| ddaa | Kinnison: btw, what's "merp"? | 01:27 |
| Kinnison | ddaa: it's a noise word | 01:29 |
| Kinnison | ddaa: say it out loud with a high-pitched voice | 01:29 |
| Kinnison | ddaa: Like 'meep' or 'erk' only different :-) | 01:29 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| sabdfl | carlos: any idea what to look for in fink for python-apt? is it in unstable only? | 01:33 |
| carlos | sabdfl: no idea, I'm not using fink, I just know about it, sorry | 01:33 |
| === Kinnison loves approaching code the day after | ||
| === Kinnison deletes two pointless classes; alters the SQL views and merges all the publishing logic into one place | ||
| sabdfl | the joy of sleep | 01:35 |
| Kinnison | Indeed. This way there isn't pointlessly duplicated code | 01:35 |
| Kinnison | and SourcePackagePublisher/BinaryPackagePublisher get collapsed into what was originally just a base class... Publisher | 01:35 |
| Kinnison | (all in canonical.lucille of course) | 01:35 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| sabdfl | stub: do we want someone to be able to have multiple subscriptions to the same bug? | 01:41 |
| sabdfl | watch / cc / ignore? | 01:41 |
| sabdfl | i think we should make (bug, person) UNIQUE | 01:41 |
| stub | That depends on the behaviour of 'cc'. If you have 'cc' and you automatically get the same behaviour as 'watch' as well, then yes. | 01:41 |
| Kinnison | what is the difference between watch and cc? | 01:42 |
| stub | (erm... yes... make it unique) | 01:42 |
| stub | My interpretation is that watch makes the bugs appear on your reports (when they exist. The dashboard, 'my bugs' etc.). CC means you get emailed about all changes to that bug. | 01:42 |
| Kinnison | Can someone else add you to CC without necessarily knowing you're watching the bug? | 01:43 |
| sabdfl | we could define the apropraite behaviour | 01:43 |
| === Kinnison is concerned that while they have equivalent results; the two concepts are sufficiently different that you should allow both at once | ||
| Kinnison | E.g. you might be watching all bugs in a given package yes? But that means something different to explicitly being in the CC list on a bug doesn't it? | 01:44 |
| stub | CC would be Watch with extra behaviour. Watching all bugs on a given package would be stored in a seperate table if implement that behaviour. | 01:46 |
| sabdfl | what stub said | 01:46 |
| sabdfl | relationship between person and package is different to that between person and bug | 01:47 |
| stub | I'll go make it unique. We can replace it with a more lax constraint in the future if we implement more complex subscription types. | 01:48 |
| Kinnison | okay | 01:48 |
| === Kinnison just thought he should pipe up in case :-) | ||
| sabdfl | cc is watch + email, i figure | 01:49 |
| sabdfl | stub was that you that fixed the subscriptions portlet? | 01:49 |
| stub | No - that was Brad I think | 01:49 |
| Kinnison | We're using SQLObject 0.6 these days; aren't we? | 01:50 |
| stub | It was working just fine last time I played with that one ;) | 01:50 |
| sabdfl | Kinnison: yes | 01:50 |
| Kinnison | coolie | 01:50 |
| Kinnison | stub: 0.6 does non-integer IDs as follows | 01:50 |
| Kinnison | in your class, put _idType = str | 01:50 |
| Kinnison | wallow in the joy | 01:51 |
| === Kinnison now has almost certainly unique and non-specious id columns in his package publishing views | ||
| stub | Can someone run 'make test' and let me know if there are a heap of failures bitching about not being able to find the Utilities component? | 01:55 |
| === stub runs it himself from a rocketfuel checkout | ||
| stub | Hmm.. those tests already broken. Cool... I guess... ;) | 02:01 |
| ddaa | stub: what is the result of the following command on the production database? | 02:06 |
| ddaa | select count(*) from sourcesource where cvsroot like '%.tar.%' or cvsroot like '%.tgz'; | 02:06 |
| stub | ddaa: You want a snapshot of the production database btw? There are hourly backups being made and I'm happy to push them somewhere as long as Mark, Elmo & Thom have no objections to where the data is escaping too. | 02:08 |
| === stub runs the query | ||
| stub | ddaa: 332 | 02:08 |
| ddaa | Bad news. 332 rows of the sourcesource table have broken data. | 02:09 |
| ddaa | Good news. We are going to fix it. | 02:09 |
| ddaa | What is the procedure to fix production data? | 02:10 |
| ddaa | generate a sql script to be eyeballed and manually applied? | 02:10 |
| stub | Pretty much, yeah. I'm happy to do it or help out, but you probably know the data better. | 02:11 |
| === debonzi_ [~debonzi@200.158.100.251] has joined #launchpad | ||
| Kinnison | elmo: ping? | 02:13 |
| stub | ddaa: It doesn't have to be an sql script btw. A Python script would work just as well. | 02:13 |
| Kinnison | elmo: can you install man-db on zhongshan please? | 02:13 |
| === Kinnison goes shopping, bbl | ||
| (elmo/#launchpad) Kinnison: what on earth for? | 02:15 | |
| Kinnison | elmo: for reading of apt-ftparchive manpages | 02:15 |
| ddaa | stub: I would have expected more anal retention... | 02:15 |
| Kinnison | elmo: It's irritating to have to have another terminal up :-( | 02:15 |
| (elmo/#launchpad) Kinnison: sorry, but you'll need to deal with that - the DC stays minimal | 02:15 | |
| stub | ddaa: It is easier to get Python code correct that SQL code :-) | 02:15 |
| Kinnison | elmo: okay | 02:15 |
| ddaa | stub: sorta makes sense... | 02:16 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Vocabularies should be looked up by name (avoids circular import issues and they get a context too). Rationalize vocabulary/vocabularies package (patch-635) | 02:41 | |
| sabdfl | stub: i'm going to blast malone/browser.py into ordered parts this afternoon, ok? | 02:45 |
| stub | Sure. Subsumed in the launchpad area or separate? | 02:46 |
| sabdfl | stub: yes into launchpad browser/ database/ interfaces/ | 02:50 |
| sabdfl | there will still be the core MaloneAppView etc in the old location i think | 02:51 |
| stub | Hmm... I don't know if there is much point leaving it around. All the database code and the Z3 code is in the one spot, a few minor bits of bootstrap code around elsewhere seems to be a bit of a decoy. | 02:53 |
| stub | I guess see how it looks after | 02:54 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| sabdfl | i tihnk we'll end up with launchpad/browser/malone | 03:01 |
| sabdfl | which has just the bootstrap code for malone | 03:01 |
| sabdfl | and launchpad/browser/rosetta | 03:01 |
| sabdfl | etc | 03:01 |
| sabdfl | at some "long distant future" time we may also want to distribute the lp components separately, and that will require a whole new component glue | 03:02 |
| cprov | elmo: ping | 03:02 |
| stub | I wonder if launchpad/launchad/lib/launchpad needs some thought... the swedish chef school of project layout ;) | 03:02 |
| SteveA | dists/launchpad/lib/canonical/launchpad ? | 03:03 |
| sabdfl | i'll be someone has canonical/launchpad/launchpad/lib/canonical/launchpad :-) | 03:03 |
| sabdfl | bet | 03:03 |
| sabdfl | blech. circular imports | 03:05 |
| cprov | elmo: I request new password on mawson, but I still can't create a DB, either as "sudo -u launchpad .." (inserting crazy rand. gen. pass everytime is an issue, anyway) | 03:05 |
| sabdfl | what's the lazy import thing? | 03:05 |
| SteveA | cprov: change your password perhaps? | 03:05 |
| cprov | SteveA: do you mean via passwd ? (doesn't work ...) | 03:06 |
| stub | Stick the import statements in the function that needs it is the work around. | 03:07 |
| SteveA | sabdfl: the lazy import thing is a bit of non-standard magic I cooked up during the soyuz sprint. I don't think it is checked in right now, but the code is around somewhere. | 03:07 |
| sabdfl | ok | 03:07 |
| sabdfl | hm | 03:07 |
| sabdfl | bugs depend on assignments depend on bugs | 03:07 |
| SteveA | cprov: there's a "userdir-ldap" thing you can use to change your password. I don't know how to access it though. | 03:07 |
| sabdfl | stub: this BugContainerBase class, is that something you know all about? | 03:08 |
| cprov | SteveA: https://... stuff ? I saw, but like you, I don't know how to access | 03:08 |
| SteveA | the zope3 way to avoid circular imports is to use adapters and utilities to indirectly refer to objects via the interfaces you need. | 03:08 |
| SteveA | So, everything depends on interfaces, but doesn't have many interdependencies | 03:09 |
| stub | Mmm... | 03:09 |
| stub | I think I wrote BugContainerBase - yeah. | 03:09 |
| === BradB|away is now known as BradB | ||
| limi | BradB! | 03:11 |
| BradB | yo! | 03:11 |
| limi | BradJIT | 03:11 |
| limi | I need your helpful Mac assistance ;) | 03:11 |
| limi | apt_pkg and plpython | 03:12 |
| limi | how? :) | 03:12 |
| limi | aka. python-apt | 03:12 |
| BradB | limi: apt_pkg: forget it. Just create a stub for the module that has the two names that actually get imported set to None. | 03:12 |
| BradB | kiko filed a bug for what's wrong with it, but it won't get fixed anytime soon. | 03:12 |
| limi | ok | 03:12 |
| sabdfl | BradB: can't wait for the soyuz boys to check in their page tests :-) | 03:12 |
| BradB | limi: plpython: forget it too. :) I always just comment out that part of the Makefile when I work, then uncomment it before I check in again. | 03:13 |
| cprov | BradB: if you think necessary we can eliminate the apt_pkg dependency | 03:13 |
| BradB | limi: And, I'm hoping that extra complexity will be dropped, because it's overkill. | 03:13 |
| BradB | cprov: You'd have to ask sabdfl if it's worth it. | 03:13 |
| limi | I see | 03:14 |
| === limi is at one point going to forget that Makefile | ||
| BradB | sabdfl: there are some already | 03:14 |
| BradB | I know, because there's one that always fails for me because of not having apt_pkg. | 03:14 |
| limi | is there any way to tell arch to ignore any changes to that file? | 03:14 |
| sabdfl | i tihnk the package dependency links are awesome | 03:14 |
| cprov | sabdfl: what do you think, apt_pkg helps, but it is causing many problems to Mac people, | 03:14 |
| BradB | limi: You wouldn't want to, because it gets updated somewhat frequently by other people. | 03:15 |
| sabdfl | so yes, we can create smarter stubs for MacOSX that return lists etc instead of None | 03:15 |
| sabdfl | that should work | 03:15 |
| cprov | sabdfl: I suggest to write a simple DEB deps parser (that's why we need apt_pkg) and eliminate the dependency intead of write an imporved stub for Mac ..it will be easier and cleaner for everybody | 03:20 |
| cprov | s\intead\instead | 03:20 |
| stub | 'try: import apt_pkg; except ImportError: import stub as apt_pkg' would work for now (and possibly good enough permanenty?) | 03:22 |
| (spiv/#launchpad) stub: So long as we can make tests that depend on the real apt_pkg get skipped when it's not available, yeah. | 03:22 | |
| sabdfl | cprov: | 03:22 |
| sabdfl | just use: | 03:22 |
| BradB | SteveA: Any word on when the page test generator will work again? Malone is costing a fair bit of coin for me to do the same things over and over again, because people are being allowed to checkin code that breaks things that already work, because I can't do page tests for that code due to the bugs filed in Bugzilla. | 03:23 |
| BradB | So, today again, I have to go through and unbreak vocabularies that are looked up by name that can't be looked up by name, because they're vocabularies, not vocabulary factories. | 03:23 |
| sabdfl | defParseDepends(test): | 03:24 |
| sabdfl | return [[('macosx', '', '')] ] | 03:24 |
| sabdfl | bradb: ^^ | 03:24 |
| BradB | stub: Your vocab changes to Malone broke every screen that's accessed off a bug, btw. | 03:24 |
| stub | Urgh... | 03:25 |
| sabdfl | same for ParseSrcDepends | 03:25 |
| stub | I think we fix that properly this time then | 03:25 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| cprov | sabdfl: ok, but as spiv said, we'll lack on ftests, btw is there a way to don't consider an <ul> ... </ul>, or it should be done just by line ? | 03:27 |
| BradB | sabdfl: Is that basically saying that the given package has no dependencies on a package in os x? | 03:27 |
| sabdfl | BradB: it means that the pages will still run | 03:31 |
| sabdfl | and we can bypass the ftests for that in macosx | 03:31 |
| sabdfl | this is just a stub that will pretend that EVERY package depends on a package called macosx | 03:31 |
| sabdfl | for fun | 03:31 |
| sabdfl | BradB: what was the magic incantation to build postgres with plpython? | 03:32 |
| BradB | sabdfl: ./configure --help. it's either to add --with-python, or --enable-python; the former, I think. | 03:32 |
| sabdfl | there's no ./configure in the darwin ports dir that i can see? | 03:33 |
| BradB | Oh, I just d/l'd the source of 7.4.5 | 03:33 |
| Kinnison | I think you have to invoke a specific target to get the ports tree to unpack and prepare the source tree | 03:34 |
| sabdfl | Kinnison: que? | 03:34 |
| BradB | lulu: ping | 03:35 |
| lulu | BradB:pong! | 03:35 |
| lulu | BradB: How's our cookie issue? | 03:36 |
| sabdfl | Kinnison: how do i invoke a specific target? | 03:36 |
| BradB | lulu: I was just going to ask you if I can go ahead and do it again now. (I have to go grab the patch, but it should be easy this time) | 03:37 |
| Kinnison | sabdfl: Not a clue; It's been years since I've used a ports tree | 03:37 |
| lulu | BradB: Go for it. Thanks Brad. | 03:37 |
| BradB | lulu: thanks, i'll let you know in the next little bit when everything should be okay. | 03:38 |
| lulu | BradB: Great! Do we need to log out? | 03:38 |
| BradB | It'd be better if noone were logged in. It'll probably take me about 10-20 mins to get the patch and check it out before applying it to canonical.com. | 03:40 |
| lulu | BradB: Ok - I'll log off. Tx! | 03:41 |
| === lifeless_ is now known as lifeless | ||
| === jblack_ [~jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad | ||
| === Kinnison pouts at this query doing seqscans which are probably sucky | ||
| Kinnison | oh well; it only takes 600msecs for now | 03:51 |
| sabdfl | BradB: did you build with readline support? | 03:51 |
| stub | sabdfl: Should be unnecessary unless limi wants to use psql to talk to the database. Readline will be in /opt/local | 03:55 |
| sabdfl | how do i tell ,.configure where to look? | 03:56 |
| stub | So I take it that it is createlang that is failing when limi tries to build the launchpad database? | 03:56 |
| sabdfl | doens't like --with-readline=/path | 03:56 |
| sabdfl | stub: yes | 03:56 |
| stub | env LIBS=-L/opt/local/lib ./configure blah blah blah | 03:56 |
| sabdfl | 'k thanks | 03:57 |
| sabdfl | i'm installing postgres *cough* 8.0.0b3 *cough* | 03:58 |
| sabdfl | don@t tell limi :-) | 03:58 |
| stub | Troublemaker :-) | 03:58 |
| sabdfl | will give it a quick shot and see if it works | 03:58 |
| sabdfl | we may as well start to cut our teeth on personal machines | 03:59 |
| stub | Need to get martin to package it up for hoary packages so it is easy for us to test | 04:00 |
| BradB | sabdfl: Yeah, I built with readline, I think | 04:02 |
| BradB | stub: Your Plone changes were only in CMFCore/ presumably? | 04:04 |
| stub | Yup - tla changes --diffs stuart.bishop@canonical.com/plone--release--2.0.4 should tell you exactly what (about 3 lines in CookieCrumbler.py and the new cipher.py module) | 04:05 |
| === BradB finds out how long that takes to run | ||
| stub | oh... I can send you the diff | 04:07 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Make vocabulary method produce factories, and move to vocabulary module (patch-636) | 04:08 | |
| BradB | stub: I was just in the midst of undoing your vocab patch on my tree (not being entirely sure if arch will do what I think it should, but...) | 04:09 |
| stub | Yes - just CookieCrumbler.py and the cipher.py module | 04:09 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| BradB | The amount of output coming from a "tla undo foo@bar/baz--patch-123" is definitely a bug. | 04:11 |
| === stub has never tried it | ||
| === BradB looks through the diffs | ||
| ddaa | BradB: if you have a revlib/pristine for the specified revision, the output is clean. | 04:14 |
| ddaa | Maybe the revision generation should only produce summary output if that's what you mean. | 04:14 |
| ddaa | Mhh... even then... yes, the changeset should appear twice... once for generation anh once for application. | 04:15 |
| ddaa | Maybe the generation output should be cut off. | 04:16 |
| BradB | stub: So i guess this patch depends on PyCrypto? :) | 04:21 |
| stub | Yes. I thought that would be a better approach than attempting to implement AES myself ;) | 04:22 |
| === SteveA wonders what's wrong with xor and a large one-time pad | ||
| stub | It needs someone who knows this stuff better than me to vet the cipher.py module to ensure I'm not on crack, but is better than what we have atm at least ;-) | 04:23 |
| SteveA | (and a large salt) | 04:23 |
| stub | SteveA: Because you know the plaintext (the passphrase) and can reverse the secret from the cipher text. | 04:24 |
| SteveA | hmm -- right, the point is to set a cookie with information that the person knows already. | 04:24 |
| === limi [~limi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| BradB | elmo: Presumably you're the guy to ask to get a python package installed on gentoo? | 04:26 |
| BradB | SteveA: Should I just install pycrypto somewhere under ~zope, or should I wait until someone can install it system-wide? | 04:41 |
| Kinnison | ConfigurationError: ('Invalid value for', 'factory', 'Module canonical.launchpad.vocabulary has no global BugTrackerVocabulary') | 04:47 |
| Kinnison | will that go away if I star-merge? | 04:47 |
| === ddaa notes that undo does not display the changeset generation output, only application. | ||
| BradB | ddaa: I think that all the output I was seeing was due to having a greedy revlib. | 04:48 |
| ddaa | probably... then I agree this output should be sumarized (only display "* building revision xxxx") | 04:50 |
| SteveA | BradB: python-crypto is in ubuntu, so we should just get that installed on gentoo | 04:51 |
| BradB | SteveA: okay, i'll email elmo then | 04:52 |
| SteveA | ok. I just asked elmo and thom on #canonical | 04:52 |
| SteveA | but, mail to admins is the "canonical" way to do it | 04:53 |
| BradB | ok | 04:53 |
| === limi [~limi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| Kinnison | Okay, make check currently fails | 04:55 |
| === limi fills daf and mako with volcanicity | ||
| Kinnison | Mostly with: ConfigurationError: ('Invalid value for', 'factory', 'Module canonical.launchpad.vocabulary has no global BugTrackerVocabulary') | 04:55 |
| Kinnison | anyone know what I can do to fix that? | 04:56 |
| Kinnison | (parsing ftesting.zcml -> configure.zcml -> vocabulary/configure.zcml | 04:56 |
| sabdfl | macosx has a funnny | 04:59 |
| sabdfl | wc | 04:59 |
| sabdfl | wc -l | 04:59 |
| sabdfl | gives an indented result | 04:59 |
| sabdfl | which breaks some of stub's new magic | 04:59 |
| sabdfl | how do i get rid of the whitespace before the number? | 05:00 |
| BradB | sabdfl: yes! | 05:00 |
| sabdfl | BradB: any suggestions? | 05:00 |
| Kinnison | is this in shell? | 05:00 |
| sabdfl | yes | 05:00 |
| === BradB was thinking of sed or awk | ||
| Kinnison | dsilvers@petitemort:~$ echo $(( 500)) | 05:00 |
| Kinnison | 500 | 05:00 |
| Kinnison | that might help | 05:00 |
| sabdfl | i guess i need wc -l | ??? | 05:00 |
| sabdfl | to get rid of leading and trailing ws | 05:00 |
| sabdfl | what's the ??? foo? | 05:01 |
| Kinnison | instead of foo=`wc -l bar` do foo=$((`wc -l bar`)) | 05:01 |
| SteveA | BradB: thom has installed python-crypto on gentoo | 05:01 |
| sabdfl | is that /bin/sh? | 05:01 |
| BradB | SteveA: cool, thanks | 05:01 |
| stub | Hmm... is there a way of saying do a numeric comparison so whitespace doesn't matter? | 05:01 |
| BradB | ah yes, echo `wc -l ...` seems to do the right thing. | 05:01 |
| Kinnison | BradB: there's that too actually; good call | 05:01 |
| Kinnison | dsilvers@petitemort:~$ dash | 05:02 |
| Kinnison | \u@\h:\w$ echo $(( 4500)) | 05:02 |
| Kinnison | 4500 | 05:02 |
| Kinnison | I guess $(()) is posix shell | 05:02 |
| stub | Kinnison: make check is working here.... and I checked in the last changes to vocabulary as far as I know | 05:02 |
| sabdfl | BradB: we'll commit from limi's box to verify that he can actually do that | 05:03 |
| sabdfl | stub: will you see if there's a better way to check if a db exists? | 05:04 |
| sabdfl | also, pg 8.0 bitches if you try to install a language twice | 05:04 |
| sabdfl | please could you find a way first to test if the language is installed, and then only try and install if it isn't? | 05:05 |
| stub | psql -l is the most trustworthy way I think - the other way is to attempt to connect and catch the error. | 05:05 |
| stub | I didn't think the install language would run twice, since the database is being dropped and recreated by default (hmm... unless it has been added to template1...). | 05:06 |
| stub | I'll need to drop the makefile and replace with a python script I think, or at least some python helper scripts to use in the makefile. | 05:07 |
| Kinnison | stub: Okay; so it's some of my changes magically causing the issue | 05:08 |
| Kinnison | stub: Sorry for the noise on-channel | 05:08 |
| === BradB mutters something about converting to a Python-based build process | ||
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: canonical.arch.infoUpdater, fix sourcesource.cvsroot from info files (patch-637) | 05:11 | |
| SteveA | Kinnison: if launchpad out of rocketfuel doesn't start at all, that means the "make check" before merging isn't working. | 05:11 |
| sabdfl | this is weird | 05:11 |
| limi | stub: you are no longer running Mac OS X? | 05:11 |
| Kinnison | SteveA: noted | 05:11 |
| sabdfl | the $(()) trick works find at the command prompt | 05:11 |
| sabdfl | for both bash | 05:11 |
| sabdfl | and bin/sh | 05:12 |
| BradB | SteveA: unless he doesn't have something that the pqm box does. | 05:12 |
| stub | Good or bad mutters? I know they work for me but don't know what other people think. | 05:12 |
| Kinnison | It seems that the real error message was "class Interface not defined" | 05:12 |
| SteveA | unless his environent is "broken", yes | 05:12 |
| stub | limi: Nope. Had to give my mac back to old work | 05:12 |
| SteveA | Kinnison: didn't compile zope libraries | 05:12 |
| sabdfl | but it fails inside the makefile | 05:12 |
| Kinnison | sabdfl: what is $(SHELL) ? | 05:12 |
| Kinnison | SteveA: Naah; it was that I have 'Interface' somewhere where i meant 'SQLBase' | 05:12 |
| BradB | stub: Lucky you. :P | 05:12 |
| Kinnison | SteveA: 'make check' works now :-) | 05:13 |
| SteveA | cool | 05:13 |
| sabdfl | Kinnison: at the command prompt it's bash | 05:14 |
| === stub misses his 17" G4 TiBook | ||
| Kinnison | sabdfl: and in the script? | 05:14 |
| sabdfl | appropriately enough, from make it is "HELL" | 05:14 |
| Kinnison | sabdfl: $$(SHELL) | 05:14 |
| stub | I also miss iPhoto and iCal :-( | 05:14 |
| Kinnison | (from make) | 05:14 |
| BradB | stub: is there any hope for HFS+ though? sometimes i wonder... | 05:14 |
| BradB | maybe I'm meant to have Panther and UFS | 05:14 |
| Kinnison | sabdfl: don't forget to double-up all dollar signs for shell-under-make | 05:15 |
| sabdfl | hey, i know so little about make AND shell i'm not worthy of debugging stub's code | 05:15 |
| stub | BradB: ufs didn't seem nice when I tried it under 10.0, although I vaguely remember the problems from OS9 apps. I would want to see benchmarks on same hardware/different os before condemning HFS+ though. | 05:16 |
| BradB | stub: My "muttering" was my hinting that we need a Python-based build process to sanely and easily do the more complex dependency checks we're currently trying to shoehorn (in a cross-platform way) into a Makefile. | 05:16 |
| sabdfl | hmm... if i put @ echo $$(SHELL) in the makefile it says: | 05:16 |
| BradB | And with a Python-based build, we then have a Makefile 10-12 people can maintain, instead of 1-2. | 05:16 |
| stub | sabdfl: You think I know what I'm doing??? I learnt when I started sysadmining so I never would have to learn sh, awk etc. and have spend the last 10 years with tcsh as my shell :-) | 05:17 |
| sabdfl | /bin/sh: line 1: SHELL: command not found | 05:17 |
| stub | BradB: Cool. +1 then :-) | 05:17 |
| stub | (ermm... learnt Perl that should be) | 05:17 |
| BradB | Yeah, Perl precludes me from knowing all the different little shell programs that people actually still, well, use. | 05:18 |
| sabdfl | stub: ok, the magic incantation appears to be: | 05:25 |
| sabdfl | @if [ "$$((`psql.... | 05:26 |
| limi | @if [ "$$((`psql -l | grep ${TEST_DBNAME} | wc -l`))" = '1' ] ; \ | 05:26 |
| limi | then dropdb ${TEST_DBNAME} ; \ | 05:26 |
| limi | fi | 05:26 |
| BradB | heh heh | 05:26 |
| SteveA | I suggest keeping the makefile strictly to handle dependencies, and using python scripts for the rest. That is, the makefile targets are just python scripts. That's what I did for test_on_merge.py and make check. | 05:27 |
| SteveA | it may be more verbose, but it is easier to understand, and less prone to sh-jockies writing incomprehensible stuff in the makefile. | 05:27 |
| sabdfl | why would a fresh pull of rocketfuel have test errors? | 05:30 |
| SteveA | it won't | 05:30 |
| sabdfl | it does | 05:30 |
| SteveA | not page test errors, anyway | 05:30 |
| sabdfl | yes | 05:30 |
| SteveA | have you installed all the things required? | 05:30 |
| SteveA | is it on a machine that has run launchpad before? | 05:30 |
| BradB | sabdfl: What are the errors? :) | 05:32 |
| sabdfl | it's db integrity error's during the page tests | 05:32 |
| sabdfl | it seems as though it's running the page tests against a db that already has the page test data in it | 05:32 |
| sabdfl | que? | 05:32 |
| limi | IntegrityError: ERROR: duplicate key violates unique constraint "productrelease_pkey" | 05:33 |
| BradB | sabdfl: what if you manually reset the DB and run make check? | 05:39 |
| BradB | (e.g. i don't rely on the make check rule properly resetting the DB here, because it doesn't seem to reset it properly on OS X, due to the indent issues with wc and such.) | 05:40 |
| SteveA | is this the optimisation recently introduced by stub not working on OS X? | 05:41 |
| BradB | SteveA: there are rules that are broken in the top-level and schema Makefile, and dependencies that have been introduced that break things on OS X (e.g. plpython), which would indicate that they were probably made by someone who wasn't working on OS X, if that's what you're asking. :) | 05:45 |
| sabdfl | <limi> would A-A-P be an alternative to make? http://www.linuxjournal.com/article.php?sid=7215 | 05:45 |
| sabdfl | <limi> Python-based and all | 05:46 |
| SteveA | BradB: I noticed that stub had recently checked in some optimisations of the setup for functional tests and page tests | 05:46 |
| BradB | ah, that, not sure yet | 05:47 |
| stub | That won't affect this - it is creating the launchpad_unittest_template database, not the one used by the page tests | 05:48 |
| SteveA | grep provides decent exit codes, so why use wc -l ? | 05:50 |
| sabdfl | stub: problems was that ALL the places you have the new voodoo needed $$(()) love | 05:50 |
| sabdfl | we have it fixed now | 05:50 |
| sabdfl | just have to see if limi can actually commit and pqm | 05:50 |
| limi | committed | 05:53 |
| sabdfl | does make check give a useful exit code? | 05:56 |
| Kinnison | pqm relies on it | 05:57 |
| sabdfl | shell would be...? | 05:57 |
| SteveA | echo $? | 05:59 |
| sabdfl | if [ $? -GT 0 ] ; then | 06:00 |
| sabdfl | sans caps on the gt, right? | 06:00 |
| Kinnison | looks good | 06:00 |
| kiko | yes, sabdfl | 06:01 |
| sabdfl | kiki! | 06:01 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: More lucille-related db stuff and an example of how non-integer primary keys work (patch-638) | 06:15 | |
| kiko | heh | 06:19 |
| Kinnison | kiko: ? | 06:21 |
| kiko | hey Kinnison | 06:26 |
| Kinnison | I was wondering what you were laughing at | 06:27 |
| kiko | sabdfl's kiki smirk. | 06:28 |
| Kinnison | aha | 06:32 |
| === BradB is now known as BradB|lunch | ||
| kiko | they think it's funny to corrupt a person's name that way. | 06:45 |
| (elmo/#launchpad) err, pot, kettle, black, mister Trout | 06:45 | |
| Kinnison | I see | 06:46 |
| kiko | sabdfl, can I request elmo allow the creation of an account for salgado@async.com.br? | 06:46 |
| === Kinnison decides to call kiko 'koko' instead then | ||
| kiko | that wasn't english. hopefully it's half-afrikaans. | 06:46 |
| sabdfl | kiko: who's that? | 06:47 |
| kiko | sabdfl, Guilherme Salgado, who will be starting after next month as per our phone discussion | 06:48 |
| kiko | sabdfl, we'd rather he tagged off debonzi or cprov but we're not sure arch makes that safe enough. | 06:48 |
| === cprov thinks "koko" might sound funny/strange in a portuguese talk | ||
| kiko | sabdfl, if you would rather we pursued the arch route for this period, I'm okay with it. | 06:49 |
| (dilys/#launchpad) New bug 2121 for Launchpad/Launchpad: product interface verification fails | 07:13 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2121 | 07:13 | |
| sabdfl | kiko: it does | 07:14 |
| (dilys/#launchpad) New bug 2122 for Launchpad/Launchpad: branch interface verification fails | 07:15 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2122 | 07:15 | |
| kiko | sabdfl, hmmm. | 07:16 |
| kiko | sabdfl, "it does"? | 07:16 |
| sabdfl | i'm starting to like arch | 07:16 |
| sabdfl | i think he could tag off cprov, then cprov merges from him and pushes up to rocketfuel | 07:16 |
| sabdfl | at least for a week or two | 07:16 |
| kiko | so I should try and get salgado to tag off cprov. | 07:17 |
| kiko | okay -- the only issue I see is gpg-signing the merged patches, but I think jblack_ can help us there. | 07:17 |
| (dilys/#launchpad) New bug 2123 for Launchpad/Launchpad: dbschema unit tests fail | 07:17 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2123 | 07:17 | |
| kiko | jblack_, if you are around, we'd appreciate some help. | 07:17 |
| kiko | sabdfl, I know jblack_ takes patches from elsewhere and merges them into RF, so I assume it is possible, we just never have. | 07:18 |
| (dilys/#launchpad) New bug 2124 for Launchpad/Launchpad: "check" rule for top-level makefile should run unit tests | 07:21 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2124 | 07:21 | |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| sabdfl | kiko: "elsewhere" could be tricky | 07:36 |
| sabdfl | but if he tags of cprov then there is no loop | 07:36 |
| sabdfl | he can only update when cprov updates | 07:36 |
| sabdfl | essentially, cprov is his upstream, not rocketfuel | 07:36 |
| sabdfl | he doesn't mirror to chinstrap or merge to rocketfuel | 07:36 |
| kiko | yes, I understand. | 07:36 |
| sabdfl | cprov merges from him and pushes to rocketfuel | 07:36 |
| kiko | we just were thinking if the fact that chinstrap won't recognize his gpg signature be a problem for cprov's RF request. | 07:37 |
| (spiv/#launchpad) kiko: I'm not sure, but I think that may be ok, because cprov will have signed it. | 07:37 | |
| (spiv/#launchpad) kiko: But it's worth checking with our arch guys :) | 07:38 | |
| cprov | spiv: ok, I'm not sure if the patches will be resigned, but anyway salgado should have access to my archive (in my laptop), it might be complex (WEBDAV maybe) | 07:42 |
| (spiv/#launchpad) cprov: He only needs read access, so plain http would work (although you'd have to mirror it and make sure the mirror had .listing files) | 07:44 | |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| === spiv boggles as archzoom takes over a minute of cpu time to process one page request | ||
| === BradB|lunch is now known as BradB | ||
| === carlos hates current.sql, he had a hard to detect bug because the sample data :-( | ||
| daf | "corrupt library (failed inode signature validation)" | 08:12 |
| daf | is there any way for me to find out which files were corrupted? | 08:12 |
| daf | ddaa, lifeless, jblack_: ^^^ | 08:13 |
| ddaa | None that I am aware of. | 08:14 |
| ddaa | But because of hardlinking, you should probably remove at least the whole version from the revision library. | 08:14 |
| daf | I'd really like to know what got corrupted so I can work out whether it was my fault and whether it's likely to happen again | 08:14 |
| (spiv/#launchpad) ddaa: I've been in daf's position too. It'd be a really useful diagnostic. | 08:15 | |
| ddaa | If you are interesting in diagnosis, you can just move the revision out of the revlib, remove the whole version, then run "tla changes" in the tree. | 08:15 |
| daf | "remove the whole version"? | 08:15 |
| (spiv/#launchpad) (for instance, there seems to be something that reguarly corrupts my zope checkout if I hardlink it, but I've no idea what, so I just don't hardlink that anymore) | 08:16 | |
| ddaa | rm -rf path-to-revlib/arch@host/category/category--branch/category--branch--0 | 08:16 |
| (spiv/#launchpad) ddaa: It was the conflicting "move the revision out of the revlib" and "remove the whole version" that confused me :) | 08:17 | |
| daf | also, a way of automatically removing corrupt revisiosn would be nice | 08:17 |
| daf | removing each one by hand is a pain | 08:17 |
| ddaa | If you love shell one liners you could do something along "tla library-revisions $version | xargs -n 1 tla library-remove" or something like that | 08:18 |
| ddaa | daf: good point, I do not know how to do that. | 08:18 |
| daf | well, wishlist bug | 08:19 |
| daf | do we have a place in Bugzilla for bugs on Arch? | 08:19 |
| daf | we should | 08:19 |
| ddaa | There should probably be a tool which traverse the whole revlib, check the inode sigs, and remove and list corrupt revisions. | 08:20 |
| daf | agreed | 08:20 |
| ddaa | daf: you can post a message to gau with a subject starting with "[BUG] ", that will put in in tla own bts, which is being written by asuffield. | 08:21 |
| ddaa | Well, it was beinf | 08:21 |
| ddaa | being written by asuffield until not long ago. He does not seem very active on that atm. I've heard that tom pissed him off by changing his mind multiple times on some feature. | 08:22 |
| ddaa | arch is BIG on NIH | 08:22 |
| daf | the model we've been using so far is this: | 08:22 |
| daf | if we have people at Canonical who are involved in some project we use | 08:22 |
| daf | like Steve for Zope, Andrew for SQLObject, etc. | 08:23 |
| (spiv/#launchpad) (BradB for SQLObject, me for sqlos...) | 08:23 | |
| daf | then we file bugs in bugzilla and the appropriate people interface with upstream | 08:23 |
| daf | spiv: ah, ok | 08:23 |
| ddaa | daf: okay | 08:23 |
| daf | I think this could work for Arch also | 08:23 |
| (spiv/#launchpad) daf: BradB has commit privs on SQLObject :) | 08:23 | |
| daf | spiv: I bet you were happy to get rid of that one :) | 08:24 |
| ddaa | No problem with that. I guess "the appropriate person" will end up being jblack. | 08:24 |
| (spiv/#launchpad) daf: Hah. I'm still happy to look into SQLObject issues, but it's good having more help, not to mention someone that's a little more responsive than ianb... | 08:24 | |
| daf | justdave: how about a category in Bugzilla for Arch bugs? | 08:25 |
| (spiv/#launchpad) An "Arch" category in bugzilla could potentially be a good place for PQM bugs/feature requests as well. | 08:25 | |
| daf | yes | 08:26 |
| daf | they're currently filed agains "Project Admin" or somesuch | 08:26 |
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| ddaa | is that usual to use something of the form "<date> <author>" as the summary of cvs commit messages? | 08:29 |
| === daf shrugs | ||
| daf | I tend to do a one-line summary of the commit | 08:29 |
| daf | which is usually "Updated Welsh translation." :) | 08:30 |
| (spiv/#launchpad) ddaa: Not in my limited experience. | 08:30 | |
| ddaa | I see many of those in zenity and yelp, so I'm not sure that's normal. | 08:30 |
| === BradB starts the scary canonical.launchpad.event namespace | ||
| ddaa | I also see many summaries starting with a "* " which looks suspect... | 08:30 |
| ddaa | but... well, I'm not even sure that cvs has the notion of a summary line... | 08:31 |
| SteveA | BradB: events? | 08:32 |
| daf | ddaa: *-lines are probably copied out of the changelog | 08:32 |
| ddaa | yeah... I guess I should ask lifeless... | 08:32 |
| daf | ddaa: hah, true -- I've clearly been using Arch too much :) | 08:33 |
| ddaa | Coming from cvs, I do not know what is expected crack and what is unusual crack. | 08:33 |
| BradB | SteveA: for things that are added or edited related to a bug | 08:33 |
| daf | then again, that would imply that I haven't been using CVS enough, which is oxymoronic | 08:34 |
| ddaa | "my users hate arch, but they hate cvs even more" | 08:34 |
| daf | hmm: deleting the last 50 revisions fixed the corruption | 08:34 |
| SteveA | BradB: good idea. Don't bother using an interface for the events. Use classes and keep them simple (no, or next to no logic in the event itself). | 08:34 |
| SteveA | If you must use logic in the event, do it in the __init__ | 08:34 |
| daf | ddaa: precisely! | 08:35 |
| SteveA | sabdfl was unkeen on using events at this point when I brought up the idea in London. | 08:35 |
| (spiv/#launchpad) ddaa: I'm pretty sure that cvs doesn't have a summary line concept. Many projects have software that mails commit messages with the first line as the subject, so the first line tends to be a de facto summary line. | 08:35 | |
| (spiv/#launchpad) ddaa: (But I am not a CVS expert :) | 08:35 | |
| BradB | SteveA: it seems the most natural way... | 08:36 |
| BradB | there are a total of about 13-14 things that we need to monitor | 08:37 |
| BradB | about 7ish, but there's add/edit events for each (the only exception is perhaps comments, which aren't currently editable | 08:38 |
| SteveA | I agree. If you add events.py... it should be events not event, because like interfaces there are many kinds of event in the file. It isn't like we have a domain object type called an "Event". | 08:38 |
| BradB | oh, ok | 08:38 |
| SteveA | Write in the module's docstring about using just classes, not interfaces, and keeping them as free of logic as possible (as in, just carriers of information) | 08:39 |
| SteveA | and if there must be any logic in them, to do all the processing in __init__, just like with an exception. | 08:39 |
| SteveA | events are a lot like exceptions, actually | 08:39 |
| SteveA | personally, I'd put them in with interfaces | 08:39 |
| BradB | Is the only reason to avoid interface to reduce the amount of typing? | 08:39 |
| SteveA | along with exceptions. because they are a lot like exceptions, and form part of the interface to something. | 08:40 |
| SteveA | there should never be more than one implementation of a particular event. | 08:40 |
| SteveA | the event itself carries sufficient type information for routing the event to subscribers. | 08:40 |
| BradB | yeah. i'll have one handler class that delegates to the appropriate method based on what happened. | 08:41 |
| SteveA | so, I'd say, put the events in with the interfaces | 08:41 |
| SteveA | you can just have handler functions, when that makes more sense | 08:41 |
| SteveA | and, it often does | 08:41 |
| BradB | SteveA: why not keep them in canonical.launchpad.events? seems simpler than to group them in interfaces, which they aren't. | 08:42 |
| SteveA | exceptions aren't interfaces too | 08:42 |
| SteveA | s/too/either/ | 08:42 |
| BradB | i'd put exceptions in an exceptions namespace :) | 08:42 |
| SteveA | but, they are part of the public interface of a thing. | 08:42 |
| SteveA | and vocabularies in a vocabularies namespace? | 08:43 |
| BradB | yeah :) | 08:43 |
| BradB | like they are currently | 08:43 |
| SteveA | the interfaces modules define the boundaries of a subsystem. | 08:43 |
| SteveA | that boundary is not just the IWhatever interface, it is also the exceptions that can be raised when interacting with an IWhatever | 08:44 |
| SteveA | and the events that get produced when interacting with an IWhatever | 08:44 |
| SteveA | but, really, I don't mind a lot either way. | 08:44 |
| BradB | i'll leave it in events for now, and if people find it that strange, i'll let someone else tla mv it. | 08:44 |
| BradB | (or do the conceptual equivalent :) | 08:45 |
| SteveA | the point is, if you're looking for stuff to do with a Bug... | 08:45 |
| BradB | hm, true | 08:45 |
| === BradB hmms | ||
| SteveA | the other thing is one of dependency | 08:46 |
| SteveA | so, a subscriber to such an event needs to know about the event | 08:46 |
| SteveA | and about the interface of whatever the event is carrying | 08:46 |
| SteveA | a BugAddedEvent would probably carry the bug | 08:46 |
| SteveA | maybe the IPerson that added the bug... maybe not | 08:47 |
| SteveA | anyway, some things for you to think about :-) | 08:47 |
| BradB | yeah | 08:47 |
| BradB | i'll check in some kind of code that works today | 08:47 |
| SteveA | cool | 08:47 |
| SteveA | Kinnison: lib/canonical/lucille/tests is not a package | 08:51 |
| SteveA | it must be a package | 08:51 |
| SteveA | add an __init__.py to it to make it into a package | 08:52 |
| ddaa | what's the cvs magic to know whether a file has the binary bit on? | 08:52 |
| (dilys/#launchpad) Bug 2123 resolved: dbschema unit tests fail | 08:54 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2123 | 08:54 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix bug 2123, failing dbschema tests. (patch-639) | 08:58 | |
| ddaa | Okay... knew that... | 09:05 |
| ddaa | someone tell the zenity folks about -kb... | 09:05 |
| === ddaa is out | ||
| daf | SteveA: we discussed this yesterday | 09:09 |
| daf | SteveA: Lucille's tests don't pass when run outside a specific directory | 09:10 |
| daf | SteveA: so Kinnison is deliberately not making it a package until he's fixed them | 09:10 |
| SteveA | I'd be inclined to make it a package, but not call it "tests" | 09:13 |
| SteveA | so, the test runner won't complain | 09:13 |
| SteveA | and I won't be mislead into thinking that they're standard launchpad tests ;-) | 09:13 |
| daf | I don't think it's worth worrying about it if it's a short-term problem :) | 09:13 |
| (spiv/#launchpad) daf: Is it because it needs to access the tests/data directory? | 09:14 | |
| (spiv/#launchpad) Or is it more than just that? | 09:14 | |
| daf | spiv: yes | 09:14 |
| daf | (AFAIK) | 09:14 |
| (spiv/#launchpad) Ok, that's fairly easy to fix, I would think. | 09:14 | |
| daf | a volunteer! :) | 09:14 |
| (spiv/#launchpad) Heh. | 09:14 | |
| daf | are you still in Ma{j,ll,y}orca, spiv? | 09:15 |
| (spiv/#launchpad) It'd be easier to fix with Twisted's test runner ;) | 09:15 | |
| (spiv/#launchpad) Yeah, for a couple more days. | 09:15 | |
| daf | and then on to Prague? | 09:15 |
| (spiv/#launchpad) Yep. | 09:15 | |
| daf | it's cold here, how's Spain? | 09:15 |
| (spiv/#launchpad) Good :) | 09:15 | |
| (spiv/#launchpad) It's not really swimming weather anymore, but it's not far off... | 09:16 | |
| (spiv/#launchpad) There was plenty of people sun bathing on the weekend :) | 09:16 | |
| SteveA | spiv: you're in spain? | 09:17 |
| jblack_ | kiko: I'm here | 09:17 |
| (spiv/#launchpad) For a couple more days, yeah. | 09:18 | |
| SteveA | mainland or island? | 09:18 |
| (spiv/#launchpad) SteveA: See my travel itinerary on the wiki ;) | 09:18 | |
| (spiv/#launchpad) Island. | 09:18 | |
| jblack_ | \\\\\\ | 09:18 |
| jblack_ | cprov, like I told kiko, I'm here | 09:18 |
| === SteveA fixes one of the lucille tests | ||
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: imrpoved project search; various tidyings-up (patch-640) | 09:36 | |
| daf | carlos: around? | 09:42 |
| carlos | daf: yes | 09:42 |
| daf | how's your branch looking? | 09:43 |
| carlos | daf: better, but not as good as it should :-(, I had a bug on the sample data and I expend too many hours with it | 09:46 |
| daf | ok | 09:47 |
| daf | it's fixed now? | 09:47 |
| carlos | I'm with the export and import functional tests, seems like the functionality is now in place, but with some minor errors | 09:47 |
| carlos | daf: yes, the sample data bug is fixed | 09:47 |
| carlos | I also detected that the functional tests need some love | 09:48 |
| carlos | because I imported a pofile and it was empty in the database and the functional test said it was right | 09:48 |
| SteveA | carlos: you haven't merged your branch yet? | 09:48 |
| carlos | SteveA: no :-( | 09:49 |
| SteveA | any idea when it will be merged? | 09:49 |
| SteveA | Kinnison: please please no UTF8 source files! | 09:50 |
| BradB | SteveA: do events that get trigged by a foo getting added to a bug belong in lib/canonical/launchpad/zcml/foo.zcml? | 09:50 |
| BradB | Events are one of the things not mentioned in the example.zcml. | 09:50 |
| daf | canonical/launchpad/zcml/bug-events.zcml? | 09:51 |
| SteveA | that's because we don't have any events, and mark was unkeen to start using them | 09:51 |
| SteveA | I don't know what a foo is | 09:51 |
| SteveA | but, decide on the best place to put them that answers the question: | 09:51 |
| carlos | I cannot give a concrete estimation, I think I have studied all code now so it should be easy because I understand all, my plan is don't go to sleep until it's fixed, I'm starting to be bored of this patch | 09:51 |
| SteveA | "If I'm a person who has spent only 1 week on the project as a whole, where would I go looking to find it?" | 09:52 |
| SteveA | carlos: can you break the job down into smaller parts that you can merge? | 09:52 |
| === daf wonders what the aversion to find/grep is | ||
| carlos | daf: I thought that I prefer if you merge your changes to pofile.py because It will be easier If I merge it with my branch than if you should do it... | 09:53 |
| daf | carlos: is there something I could help with that you make your job easier? | 09:53 |
| === BradB goes for bugevents.zcml | ||
| daf | BradB: no '-'? | 09:53 |
| carlos | SteveA: no, the problem is the database change if we change the schema, all the changes are needed | 09:53 |
| SteveA | how can I open a .txt file encoded in UTF-8 and save it without screwing it up? | 09:53 |
| daf | SteveA: use a decent editor | 09:53 |
| BradB | hmph | 09:54 |
| daf | :se encoding=utf-8 | 09:54 |
| SteveA | I'm using gvim. I think a bit of :set encoding=utf8 will do it | 09:54 |
| carlos | daf: perhaps you could start validating my code, I'm working on it too much time and perhaps you could catch the errors I don't see... | 09:54 |
| SteveA | but, I'll repeat... All source code files should be in ascii | 09:54 |
| daf | carlos: ok | 09:54 |
| carlos | SteveA: use recode | 09:54 |
| daf | carlos: how should I go about validating it? | 09:55 |
| daf | carlos: what does recode do? | 09:55 |
| carlos | daf: I will do a star-merge now to get latest unittest fixed | 09:55 |
| carlos | daf: change the encoding of a text file | 09:55 |
| daf | carlos: that doesn't help for editing it | 09:55 |
| carlos | recode latin1..utf8 file.txt | 09:55 |
| carlos | it converts it into non utf-8 | 09:55 |
| carlos | and you can edit it later | 09:56 |
| daf | what if there are non-latin-1 glyphs in the file? | 09:56 |
| carlos | I thought that was what SteveA wants to do | 09:56 |
| daf | Steve doesn't want Latin 1 either | 09:56 |
| carlos | daf: change latin1 with the encoding :-P | 09:56 |
| daf | he wants ASCII | 09:56 |
| carlos | but that will break the file removing chars, right? | 09:57 |
| daf | if you have (say) "" in the source code, you can't convert it to Latin 1 | 09:57 |
| carlos | Instead of "Perell Marn" he will get "Perell Marn" | 09:57 |
| daf | because Latin 1 doesn't have such a character | 09:57 |
| daf | and are in Latin 1, and so they can be converted | 09:58 |
| carlos | daf: dude, the latin1 string was just an example it should be changed to the needed encoding, of course if you want to strip out the non ascii chars... I don't have any idea about how to do it :-) | 09:58 |
| daf | oh, an example :) | 09:59 |
| daf | I think Stee was saying that he wants to edit the file | 09:59 |
| daf | Steve | 09:59 |
| daf | without changing the encoding for now | 09:59 |
| carlos | In fact the command I pasted is to convert a latin1 file into utf-8 :-) | 09:59 |
| daf | carlos: heh, I thought it might be :) | 10:00 |
| daf | anyhow, this is getting off topic | 10:00 |
| daf | any suggestions for reviewing the changes you have made? | 10:00 |
| daf | also, you said I should merge my changes to pofile.py? | 10:01 |
| carlos | yes, please merge it and I will review the merge into my branch | 10:02 |
| carlos | I think it will be easier | 10:02 |
| daf | well, it's not a critical change | 10:02 |
| daf | so I can merge it after you have merged your branch | 10:02 |
| carlos | as you want | 10:02 |
| daf | I think it will let us merge your branch quicker if we delay that change | 10:02 |
| carlos | about the suggestions to review the changes... not sure, let me merge the rocketfuel changes into my branch and looking the functional tests for one more hour, perhaps It's finished already, because seems like it's beeing imported the file already | 10:03 |
| SteveA | please get merged as quickly as you can | 10:03 |
| daf | carlos: you'll report back to me in 1 hour? | 10:04 |
| carlos | daf: yes | 10:04 |
| carlos | at 21:00 UTC, is it ok? | 10:04 |
| daf | yes | 10:04 |
| daf | later, then | 10:04 |
| daf | I'll be finishing work today at 21:25 or so | 10:05 |
| carlos | ok | 10:05 |
| justdave | daf: arch product created. | 10:07 |
| carlos | I need to get some food, I'm back in 10 minutes | 10:08 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Some soyuz fix and sql.py cleanup started. (patch-641) | 10:11 | |
| daf | justdave: great, thanks! | 10:12 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Make lucille tests run as part of the main launchpad unit tests. Reformat lucille test code to pep8. Change utf8 encoded file into ascii encoding. (patch-642) | 10:15 | |
| (dilys/#launchpad) New bug 2125 for Arch/general: Arch leaves a revision lock when signature fails | 10:21 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2125 | 10:21 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: fix makefile for Mac OS X (patch-643) | 10:21 | |
| (dilys/#launchpad) New bug 2126 for Arch/general: cleaning broken revisions from one's revision library is painful | 10:27 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2126 | 10:27 | |
| carlos | spiv: someday you should explain me why we should use SQLObject.selectBy(fooID=foo.id) instead of just SQLObject.selectBy(foo=foo) or am I doing anything wrong? | 10:49 |
| daf | carlos: BradB knows SQLObject well also | 10:50 |
| carlos | BradB: someday you should explain me why we should use SQLObject.selectBy(fooID=foo.id) instead of just SQLObject.selectBy(foo=foo) or am I doing anything wrong? | 10:51 |
| carlos | :-D | 10:51 |
| (spiv/#launchpad) carlos: Because SQLObject is pants. | 10:52 | |
| BradB | carlos: Because of a bug in sqlobject. ;) | 10:52 |
| carlos | funny, SQLObject is a really good idea but it sucks... | 10:52 |
| carlos | :-) | 10:52 |
| BradB | SteveA: Looks like I'm creating a package called canonical.launchpad.events anyway, to hold the classes that implement event interfaces (since interfaces are required for events.) | 10:56 |
| daf | carlos: nice idea, shame about the implementation? | 10:58 |
| carlos | daf: well, I think it needs some bug fixing :-) but I can live with it if I know how to workarround the bugs | 10:59 |
| BradB | carlos: It's a hell of a lot better than not-sqlobject, at least. | 11:01 |
| daf | perhaps we should have a bug open in our Bugzilla about this SQLObject issue | 11:01 |
| carlos | BradB: true | 11:01 |
| daf | carlos: BONG! 21:00 :) | 11:01 |
| carlos | daf: let the test I'm running finish and I will give you an answer :-) | 11:02 |
| === carlos is not sure but thinks it's all fixed but two easy to fix bugs in the exporter | ||
| === BradB looks forward to moving LP to python 2.4 and multi-line imports | ||
| carlos | daf: the main problems I had was the fooID=foo.id thing | 11:03 |
| daf | BradB: multi-line imports? | 11:04 |
| daf | BradB: they sound good | 11:04 |
| BradB | surrounding imports with brackets Does The Right Thing | 11:05 |
| BradB | no more: | 11:05 |
| BradB | import foo, \ | 11:05 |
| BradB | bar, \ | 11:05 |
| BradB | baz, \ | 11:05 |
| BradB | etc. | 11:05 |
| BradB | (with step indentation for added effect :P) | 11:06 |
| carlos | wow!! it worked (more or less....) | 11:06 |
| carlos | daf: I have now minor bugs to fix, so what do you prefer?, check the code now or as soon as those minor bugs are fixed do the merge into rocketfuel? (tonight for sure) | 11:07 |
| ddaa | BradB: why not just one import per line??? | 11:07 |
| ddaa | and I believe that's what pep8 recommends. | 11:08 |
| BradB | er, more specifically i meant the from imports. | 11:08 |
| daf | ddaa: because this is annoying | 11:10 |
| daf | from canonical.launchpad.foo.bar.baz import corge, grault | 11:10 |
| daf | from canonical.launchpad.foo.bar.baz import flarp, bling | 11:10 |
| sabdfl | daf: should i be able to see the current code running on mawson? | 11:12 |
| daf | sabdfl: yes | 11:12 |
| daf | mawso's code is currently 27 minutes old | 11:13 |
| sabdfl | i get "forbidden" | 11:13 |
| sabdfl | on / | 11:13 |
| daf | did you install the SSL certificate? | 11:14 |
| sabdfl | i have the launchpad client cert | 11:14 |
| sabdfl | not the second one | 11:14 |
| daf | that should be enough | 11:14 |
| daf | it works for me | 11:14 |
| daf | I have no idea how to go about debugging this sort of thing | 11:15 |
| sabdfl | heisenbug, works now :-) | 11:15 |
| daf | heh :) | 11:15 |
| sabdfl | tls i can debug :-) | 11:15 |
| daf | :D | 11:16 |
| sabdfl | that code appears to be massively out of date | 11:16 |
| daf | why so? | 11:19 |
| daf | oh, hmm | 11:19 |
| sabdfl | changes i made over the weekend and though had been merged | 11:19 |
| daf | maybe the update is broken | 11:19 |
| sabdfl | :-) | 11:19 |
| daf | yeah, there was a Makefile.orig lying around | 11:20 |
| daf | bah | 11:20 |
| daf | ok, try again now | 11:22 |
| === daf goes out | ||
| SteveA | BradB: I don't think interfaces are required for events | 11:26 |
| carlos | daf: should I merge the branch when it's ready or should I wait for your review? | 11:26 |
| BradB | SteveA: They are. Jim said so. :) | 11:27 |
| BradB | SteveA: The idea is that classes should be usable, but they aren't yet. | 11:28 |
| SteveA | ah -- that's just in the directive | 11:28 |
| SteveA | not in the underlying system | 11:28 |
| BradB | right | 11:29 |
| SteveA | I'm doing something a bit different with email, Brad | 11:37 |
| SteveA | because I want to integrate testing sending email with pagetests | 11:38 |
| SteveA | so, I suggest you make a function in canonical/launchpad/mail.py for sending mail | 11:38 |
| SteveA | use the standard python libs for it | 11:38 |
| BradB | I had it in mailnotification (where all the subscriber functions are) | 11:38 |
| BradB | ok | 11:39 |
| SteveA | the stuff that subscriber functions do should be pretty minimal glue stuff, imo | 11:39 |
| BradB | yep, they're simple | 11:39 |
| SteveA | various other things will need to send email, for example, the forgotten password pages | 11:39 |
| SteveA | I'm writing more page tests for the forgotten password stuff | 11:39 |
| BradB | canonical.launchpad.sendmail, perhaps? | 11:39 |
| SteveA | but I want to get it so that I can test sending email from there too | 11:40 |
| SteveA | sure | 11:40 |
| === BradB shifts some code around | ||
| SteveA | but, I'd be inclined towards canonical.launchpad.mail.send for the function | 11:40 |
| SteveA | or canonical.launchpad.mail.sendmail for ease of importing | 11:40 |
| BradB | i'll do the latter | 11:40 |
| SteveA | k | 11:40 |
| SteveA | thanks | 11:40 |
| SteveA | I'll sort out getting the zope transactional stuff hooked up, but we can manage without that at present | 11:41 |
| BradB | ok | 11:41 |
| BradB | not sure if python's stdlib blocks or not | 11:42 |
| BradB | that was another feature of the z3 way | 11:42 |
| SteveA | it blocks | 11:42 |
| SteveA | but we want that right now | 11:43 |
| SteveA | keep it really simple right now | 11:43 |
| BradB | i see what you mean | 11:43 |
| SteveA | probably when we're developing stuff, we'll want to keep it blocking | 11:54 |
| BradB | the events work now; now i've just got to go and implement 15 different handlers :P | 11:54 |
| SteveA | cool | 11:54 |
| BradB | The handlers are admittedly really simple; making sure an event is published on, e.g., an edit, may be slightly less simple. | 11:55 |
| sabdfl | Kinnison: need to split up publishing.py, it's getting a little overloaded | 11:57 |
| Kinnison | sabdfl: which one? | 12:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!