| === lifeless_ is now known as lifeless | ||
| === elmo_ [~james@george.kkhotels.co.uk] has joined #launchpad | ||
| === stu1 [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| === kiko is now known as kiko-afk | ||
| === justdave_ [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad | ||
| === justdave_ is now known as justdave | ||
| === kiko-afk is now known as kiko | ||
| !alindeman:*! Hi all .. It appears that one of our main rotation servers has dropped off the Internet ... We've pulled it from rotation and are working to mitigate further problems ... Sorry for any inconvenience and thanks for using Freenode! | 04:13 | |
| === BradB|away [~bradb@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad | ||
| justdave | ok, anyone know what this error means? | 06:08 |
|---|---|---|
| justdave | /home/dave/Source/Warthogs/launchpad/launchpad/lib/sqlobject/main.py:231: UserWarning: I tried to set the property "labels", but it was already set, as a method. Methods have significantly different semantics than properties, and this may be a sign of a bug in your code. | 06:08 |
| kiko | it seems that one class defined in :231 already has a method defined called labels() | 06:14 |
| kiko | it may be that this is only described in the interface.. | 06:14 |
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| justdave | yeah, but sqlobject isn't mine, so Apparently I"m talking to it wrong somewhere. | 06:24 |
| justdave | except I'm not calling it directly, just trying to load a couple objects from canonical.launchpad.database | 06:24 |
| justdave | and malone/browser.py is still importing them from there | 06:25 |
| justdave | although I get the same error loading browser, too | 06:26 |
| justdave | maybe it's a red herring and I should just ignore it. :) | 06:26 |
| kiko | it's triggering when importing? | 06:28 |
| stub | justdave: I think it was Carlos, Daf or Spiv who had that error last night. | 06:38 |
| justdave | yeah, triggers when importing | 06:39 |
| justdave | seems to be only a warning though, it keeps going | 06:39 |
| stub | The sqlobject subclass needs fixing (sqlobject is setting magic variables, I think because of some join attributes. It needs to be told to use names that don't conflict). | 06:40 |
| stub | Yer.. it was spiv. I'd stick it in Bugzilla or check the IRC logs from about 12 hours ago. | 06:40 |
| justdave | ok, looks like it mostly still works... | 06:46 |
| justdave | it wasn't passing tests, but that appears to be because urllib doesn't follow redirects | 06:46 |
| justdave | and it was pulling bugs from bugzilla.mozilla.org as part of the test suite | 06:46 |
| justdave | which recently started enforcing https :) | 06:47 |
| justdave | I suppose I should teach it to test for redirects, cuz that might bite us again in the future, too. | 06:47 |
| justdave | one last error from the test suite that I'm not sure on... | 06:48 |
| justdave | File "/usr/lib/python2.3/doctest.py", line 790, in rundoc | 06:48 |
| justdave | for tag, kind, homecls, value in _classify_class_attrs(object): | 06:48 |
| justdave | File "/usr/lib/python2.3/inspect.py", line 211, in classify_class_attrs | 06:48 |
| justdave | obj = getattr(cls, name) | 06:48 |
| justdave | AttributeError: __provides__ | 06:48 |
| justdave | is that the test suite complaining about that labels warning? | 06:49 |
| justdave | that's the only error it's giving now. | 06:49 |
| === daf [daf@muse.19inch.net] has joined #launchpad | ||
| justdave | if I want to set a datestamp field to CURRENT_TIME how do I do that in sqlobject to get it to actually run the "CURRENT_TIME" as SQL instead of using it as a string value? | 07:12 |
| justdave | or does it know that automatically for a timedate field? | 07:13 |
| lifeless | justdave: look at SourceSource.certify* | 07:16 |
| lifeless | it does that | 07:16 |
| justdave | where do I find that? (found SourceSource, but don't see certify in there) | 07:18 |
| justdave | grep -rin certify * comes up empty on lib/canonical | 07:19 |
| lifeless | not sure.. | 07:20 |
| lifeless | its moved a lot :0 | 07:20 |
| lifeless | you could try enable as a search instead | 07:20 |
| lifeless | if mark hasn't merged his update | 07:20 |
| justdave | ok, think I found it | 07:21 |
| stub | justdave: canonical/database/contstants.py | 07:22 |
| justdave | yep, just assigns 'NOW' to it | 07:22 |
| justdave | easy enough :) | 07:22 |
| stub | justdave: Its important to make sure you store the UTC timestamp | 07:22 |
| stub | justdave: 'NOW' stores local time. | 07:23 |
| justdave | 'NOW AT TIMEZONE UTC' ? | 07:24 |
| justdave | there's bunches of places in SourceSource that just do 'NOW' | 07:27 |
| justdave | watches = BugWatch.select( | 07:27 |
| justdave | "(lastchecked < (current_time - interval 23 hours))") | 07:27 |
| justdave | current_time in there is going to pull local time, too, isn't it? | 07:28 |
| stub | yup. and every one is a bug :-) | 07:30 |
| stub | (although I just set the production database to UTC time so it isn't a major one any more) | 07:30 |
| justdave | For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC | 07:31 |
| justdave | using the offset for the timezone zone. | 07:31 |
| stub | Our columns are timestamp-without-timezone | 07:31 |
| justdave | ok | 07:32 |
| justdave | was going to say, if they were with timezone, then it probably wouldn't matter | 07:32 |
| justdave | launchpad_test=> select timestamp 'now'; | 07:55 |
| justdave | timestamp | 07:55 |
| justdave | --------------------------- | 07:55 |
| justdave | 2004-10-07 01:53:58.90839 | 07:55 |
| justdave | launchpad_test=> select timestamp 'now' at time zone 'UTC'; | 07:55 |
| justdave | timezone | 07:55 |
| justdave | ------------------------------- | 07:55 |
| justdave | 2004-10-06 21:54:21.685953-04 | 07:55 |
| justdave | that's taking 'now' at my local time, pretending it's UTC, and converting it back to my local time. | 07:56 |
| justdave | something doesn't look right. | 07:56 |
| stub | Mmm... more reason not to futz with timezones ;-) | 07:57 |
| justdave | watches = BugWatch.select( | 08:00 |
| justdave | "(lastchecked < (now() - interval '23 hours'))") | 08:00 |
| justdave | that doesn't return a list I can iterate through? | 08:00 |
| justdave | File "./check-watches.py", line 36, in main | 08:00 |
| justdave | for watch in watches: | 08:00 |
| justdave | File "/home/dave/Source/Warthogs/launchpad/launchpad/lib/sqlobject/main.py", line 1242, in __iter__ | 08:00 |
| justdave | return conn.iterSelect(self) | 08:00 |
| justdave | AttributeError: 'ConnectionDescriptor' object has no attribute 'iterSelect' | 08:00 |
| stub | Looks like the SQLObject 0.6 upgrade has bitten you | 08:01 |
| justdave | nice. :) How do I fix it? | 08:02 |
| stub | Are you using initZopeless? | 08:03 |
| justdave | doh. that would probably help. Not even initializing the database connection. | 08:04 |
| justdave | I'm surprised it didn't crash more spectacularly than that | 08:04 |
| stub | Thats lucky - apart from that I don't know about using SQLObject outside of Zope ;) | 08:05 |
| justdave | ok, added the initZopeless and now it works :) | 08:07 |
| stub | justdave: From a command prompt can you please run 'createland -d launchpad_test plpgsql' and tell me if you get an error? | 08:13 |
| === stub is sampling how other developers have their postgresql setup | ||
| stub | Erm .... 'createlang, not createland | 08:13 |
| justdave | dave@ibook [2:14 ~ 2] tcsh> createlang -d launchpad_test plpgsql | 08:14 |
| justdave | createlang: language installation failed: ERROR: permission denied for language c | 08:14 |
| stub | Thats two out of two :-( | 08:15 |
| === stub goes back to the drawing board | ||
| justdave | gah. bugzilla.gnome.org is running too old a version of bugzilla to have the rdf buglists :( | 08:49 |
| justdave | that throws a kink in things | 08:49 |
| stub | justdave: Would it be simpler to upgrade them than work around it? | 09:26 |
| justdave | no | 09:35 |
| justdave | I already worked around it :) | 09:35 |
| justdave | turns out they actually do have rdf buglists in the version they're running, it's just using a different url syntax to get to it. | 09:37 |
| justdave | so it's making two lookups now, first one to check the version number, second using the appropriate syntax for that version to grab the bug data | 09:38 |
| justdave | we might want to store that in the BugTracker table... | 09:39 |
| justdave | I can still poll for it, but it would be pointless to poll for the version number every time I look up a bug... it won't change that often, so polling that only the first time and remembering from then on (for that day anyway) when looking up other bugs might be nice | 09:40 |
| justdave | ok, caching it in the script now. class constructor lets me pass in a version, if you pass one it uses it, if you don't, it probes. If I don't have it cached, I don't pass one, then I cache the one it finds for next time. | 09:56 |
| === SteveEgg is now known as SteveA | ||
| justdave | hmm, urllib sucks. | 10:04 |
| === justdave starts using urllib2 | ||
| justdave | urllib won't tell me if I got a 404 | 10:05 |
| === debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === Kinnison [~dsilvers@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| Kinnison | Morning | 10:09 |
| === BradB|away is now known as BradB | ||
| Kinnison | stub: So is it easy to rename a table? | 10:10 |
| === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| sabdfl | justdave: once we're up and running, i'm happy for you to spend part of your time getting the big bugzilla instances into good shape for interoperability with malone | 10:31 |
| sabdfl | stub: can we go ahead with that production system update shortly? | 10:31 |
| lifeless | sabdfl: so, how did it all go after I crashed? Is it ready for stub and I to test & move into production ? | 10:32 |
| sabdfl | lifeless: yes, i believe so, i need to make sure that i have a version that does eveything i need, then hand it over to you for your own testing | 10:32 |
| sabdfl | i still don't know how to test your stuff | 10:32 |
| stub | sabdfl: sure | 10:33 |
| lifeless | buildbot testing for the sql interface is largely done by make check | 10:33 |
| lifeless | there are a couple of bits that I still check by hand - by running up the staging instance. | 10:33 |
| lifeless | sabdfl: ok. updating my copy now | 10:34 |
| cprov | sabdfl: nicole had success yesterday, the results you can see in http://192.168.1.26:8085/++skin++Debug/doap/projects/ | 10:35 |
| lifeless | sabdfl: do you ahve a version that does what you need at the moment ? | 10:35 |
| sabdfl | cprov: that's really awesome! | 10:37 |
| cprov | sabdfl: yep | 10:38 |
| sabdfl | stub, spiv, did we get sourceforgeproject and freshmeatproject added to project and product? | 10:38 |
| daf | cprov: nice! | 10:38 |
| stub | no | 10:38 |
| sabdfl | ok, that obviously won't make today's cut then :-) | 10:38 |
| Kinnison | cprov: any way to make the table in the middle use more space? | 10:39 |
| Kinnison | cprov: horizontal space that is | 10:39 |
| stub | I don't have the email around either - was it just those two columns? what datatype? what constraints? | 10:40 |
| cprov | Kinnison: yes, I'll take note . | 10:41 |
| === stub can put it in now - provided the columns allow nulls it shouldn't affect anything | ||
| cprov | Kinnison: you also can navigate from project/product til sourcepackage and see the very low performance in sourcepackage data "fetch information" | 10:42 |
| === Kinnison grins | ||
| cprov | Kinnison: btw, you can have the DB dump in http://192.168.2.26/ to compare the performance, what do you think ? | 10:47 |
| Kinnison | cprov: performance for what? | 10:48 |
| justdave | sabdfl: ximian will be the big one (if we have anything from them that we need to track?). they're still running 2.10 | 10:52 |
| justdave | apache is on 2.14.2, and they have hardware problems preventing them from upgrading, supposedly | 10:52 |
| sabdfl | justdave: they've also done a ton of customization i think | 10:52 |
| justdave | yes, they have | 10:53 |
| justdave | I just submitted the working check-watches.py script to pqm | 10:55 |
| justdave | cron it at will :) | 10:55 |
| justdave | it has output currently though | 10:55 |
| justdave | (lists off the bugs as it checks them) | 10:56 |
| sabdfl | ok, will be useful for debugging | 10:56 |
| === justdave is strongly considering going to sleep soon | ||
| justdave | ok, just got the success message back from pqm | 11:03 |
| sabdfl | stub, lifeless: pqm message on the wire with version that works for me | 11:09 |
| sabdfl | lifeless: this version is a lot smarter about having different people logging in than what was running previously | 11:10 |
| sabdfl | please can we make sure this code is available only over https, and only with a username and password | 11:10 |
| sabdfl | even though not all pages require a login for zope, elmo, can we enforce this at the front end? | 11:11 |
| sabdfl | or do we listen to a unique port without ssl? | 11:11 |
| elmo_ | [for the benefit of those not at mark's:] they're proxypassed through https, with basic auth | 11:13 |
| sabdfl | justdave: are you running launchpad on your dev box? | 11:13 |
| sabdfl | elmo_: thanks, that's good enough for me | 11:13 |
| justdave | sabdfl: yep | 11:15 |
| sabdfl | justdave: if you update to the latest version once my patch is in, you should be able to: | 11:16 |
| sabdfl | (a) create project, and product | 11:16 |
| sabdfl | (b) register a bug tracker for that project | 11:16 |
| sabdfl | that way the bug tracker is associated with the project | 11:16 |
| justdave | can we associate a bugtracker with products optionally? | 11:17 |
| justdave | Apache Foundation has two bugtrackers, and some of the products are on each | 11:17 |
| sabdfl | we can associate both trackers with the apache project | 11:18 |
| justdave | that would work | 11:18 |
| sabdfl | and in the shortdesc makeit clear which one works | 11:18 |
| sabdfl | if the distinction is straightforward, put it in the tracker title, like "Apache Web Projects Bug Tracker" vs "Apache Java Bug Tracker" | 11:19 |
| sabdfl | that's what whill show up in the dropdown listboxen | 11:19 |
| === BradB ponders infestation while mering | ||
| BradB | merging, even | 11:21 |
| justdave | They have both Bugzilla and JIRA, and it's basically the product-manager's preference which to use, so there's no clear line between what type of projects use which tracker. | 11:22 |
| justdave | although in general the java-based projects tend to use JIRA (because it's written in Java, and the java zealots all hate perl ;) | 11:23 |
| Kinnison | stub: renaming tables... | 11:26 |
| Kinnison | stub: What's the SQL to do it? | 11:26 |
| stub | alter table foo rename to bar; | 11:26 |
| Kinnison | Does that rejiggle foreign keys etc? | 11:26 |
| stub | '\h alter table' if you want | 11:27 |
| stub | Yes - foreign keys are jigged | 11:27 |
| Kinnison | coolie | 11:27 |
| === Kinnison writes a big fookoff chunk of SQL to rename sourcepackageupload to sourcepackagepublishing; add buildpublishing and point packagepublishing at the new buildpublishing table | ||
| stub | primary key sequence will need some lovin, but I can do that. | 11:28 |
| Kinnison | Do you want new stuff to be 'create table' and then a pile of alter table commands | 11:28 |
| Kinnison | or do you want a create table with all the contraints etc built in? | 11:28 |
| stub | one create table is fine | 11:28 |
| Kinnison | cool | 11:28 |
| stub | (and preferred) | 11:28 |
| === BradB notes buginfestation has a concatenated PK, shudders | ||
| sabdfl | stub - i'd like the scriptlet that does the table rename also to rename primary_id_seq as well | 11:32 |
| sabdfl | BradB: that's a bug, please fix | 11:32 |
| sabdfl | BradB: also, i think we may want to get rid of "CodeRelease" | 11:32 |
| sabdfl | and have two infestations - one of a sourcepackagerelease and one of a productrelease | 11:33 |
| BradB | I'll have to email the list to be clear here, because Kinnison mentioned having designed tables in the same way. So here goes. | 11:33 |
| sabdfl | this is fairly deep surgery on the glue that binds doap and soyuz, can we discuss? | 11:33 |
| sabdfl | Kinnison: policy is to give every table an int primary key | 11:34 |
| sabdfl | named id | 11:34 |
| sabdfl | CREATE TABLE Foo ( | 11:34 |
| sabdfl | id serial PRIMARY KEY, | 11:34 |
| sabdfl | ... | 11:34 |
| sabdfl | ); | 11:34 |
| Kinnison | sabdfl: then sourcepackageupload fails this policy | 11:34 |
| sabdfl | Kinnison: quite possibly | 11:34 |
| sabdfl | i though't i'd caught all of them before handing over to stub | 11:34 |
| Kinnison | doesn't seem to be | 11:35 |
| === Kinnison ponders the SQL to correct this and will incorporate it into this change I'm writing | ||
| sabdfl | Kinnison: let's keep those changes separate | 11:35 |
| Kinnison | okay | 11:35 |
| sabdfl | Kinnison: a primary key fix like that requires no approval from me and can go straight in via stub | 11:36 |
| stub | Kinnison: There have already been patches to fix those issues. It involves creating a sequence, creating a new 'id' column, setting the default of the new column to be retrieved from the sequence, dropping the existing primary key and recreating the constraint as a unique, creating a unique index for the new primary key | 11:37 |
| Kinnison | stub: yeah; I've got most of the way now | 11:37 |
| stub | So just email me the screwed tables so I don't forget and I'll get on it this evening or tomorrow :) | 11:37 |
| === Kinnison nods | ||
| === justdave is now known as justdave_zzz | ||
| stub | (and the update command to populate the new id column...) | 11:39 |
| sabdfl | stub, Kinnison, for this one, because its a standard problem with a standard fix, just let stub know which table needs fixing | 11:40 |
| sabdfl | rather than let each dev figure out how to fix it | 11:40 |
| Kinnison | sabdfl: Okay; but it needs to go hand-in-hand with renaming the table | 11:40 |
| sabdfl | Kinnison: ok, fair nuff | 11:41 |
| Kinnison | sabdfl: If that's okay; then I'll punt it to stub now | 11:41 |
| sabdfl | ok | 11:41 |
| Kinnison | stub: personal mail or launchpad@ | 11:41 |
| sabdfl | lifeless: test looking ok? | 11:42 |
| stub | np. When do you need it by? | 11:42 |
| Kinnison | stub: ideally I could do with it quite soon because I have a bunch of other related changes which we'll need for lucille | 11:42 |
| stub | ok - I'll do it after rollout tonight along with your other outstanding (lucilleconfig) | 11:43 |
| Kinnison | thanks | 11:44 |
| BradB | sabdfl: Okay, so source packages can be infested and products can be infested. Let's 1. drop coderelease (unless something else uses it), 2. add an infestation_type column to buginfestation, and 3. make infestation inflate to either a sourcepackage or a product, depending on infestation_type. | 11:46 |
| stub | Is infestationtype necessary? It would be implicit depending on which of the product or the sourcepackage columns is not NULL | 11:55 |
| BradB | There wouldn't be a column for each of those. | 11:56 |
| lifeless | sabdfl: been waiting for you to say you were finished. | 11:58 |
| lifeless | are you finished ? | 11:58 |
| sabdfl | lifeless said so a while back | 12:01 |
| sabdfl | BradB: i'd rather have separate infestations | 12:03 |
| sabdfl | polymorphic tables have bitten us in the past | 12:03 |
| sabdfl | we usually end up undoing them | 12:03 |
| sabdfl | so productinfestation | 12:04 |
| sabdfl | packageinfestation | 12:04 |
| sabdfl | hmm... | 12:04 |
| sabdfl | bugproductinfestation | 12:04 |
| sabdfl | bugpackageinfestation | 12:04 |
| sabdfl | lifeless: how does it look? | 12:04 |
| sabdfl | for you? | 12:04 |
| sabdfl | stub: what do you think of separating the infestations? | 12:05 |
| stub | I'd prefer seperate ones | 12:05 |
| sabdfl | ok, let me talk through it with bradb here and we'll send a proposal | 12:06 |
| Kinnison | sabdfl: I have the SQL for the new buildpublishing table and the alters for sourcepackagepublishing and packagepublishing now. Do you want to check them; or should I send them to launchpad@ for you to see there? | 12:19 |
| sabdfl | agreed on separate tables, bradb will send stub the sql | 12:19 |
| stub | ta. | 12:19 |
| stub | Can someone send me the product-scraping columns too if they have that email lying around? I think I've nuked it. | 12:20 |
| lifeless | sabdfl: what caused this: | 12:20 |
| lifeless | * | 12:20 |
| lifeless | * Module zope.tales.tales, line 109, in __init__ | 12:20 |
| lifeless | self._next = i.next() | 12:20 |
| lifeless | * Module canonical.launchpad.database.project, line 53, in bugtrackers | 12:20 |
| lifeless | for bugtracker in self._bugtrackers: | 12:20 |
| lifeless | AttributeError: 'Project' object has no attribute '_bugtrackers' | 12:20 |
| lifeless | oh bah, new fun | 12:21 |
| lifeless | File "/home/robertc/source/canonical/buildbot/launchpad/lib/zope/configuration/fields.py", line 197, in fromUnicode | 12:21 |
| lifeless | raise InvalidToken("%s in %s" % (v, u)) | 12:21 |
| lifeless | zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/robertc/source/canonical/buildbot/launchpad/site.zcml", line 5.2-5.33 | 12:21 |
| lifeless | ZopeXMLConfigurationError: File "/home/robertc/source/canonical/buildbot/launchpad/lib/canonical/configure.zcml", line 17.2-17.36 | 12:21 |
| lifeless | ZopeXMLConfigurationError: File "/home/robertc/source/canonical/buildbot/launchpad/lib/canonical/lp/configure.zcml", line 32.2-37.8 | 12:21 |
| lifeless | ConfigurationError: ('Invalid value for', 'factory', "Couldn't import canonical.lp.tales, No module named icelso in canonical.lp.tales.RequestAPI") | 12:21 |
| lifeless | make: *** [run] Error 1 | 12:22 |
| stub | Test upgrade of a production mirror worked with no surprises | 12:22 |
| lifeless | the database ? | 12:22 |
| stub | yer | 12:23 |
| lifeless | but not a launchpad instance :[ | 12:23 |
| lifeless | can you copy an upgraded production dump into the 'buttress' postgresql database on chinstrap ? | 12:24 |
| stub | Can I nuke the existing contents? | 12:24 |
| lifeless | yes | 12:25 |
| sabdfl | lifeless: 'sec | 12:27 |
| sabdfl | lifeless: my code has: | 12:27 |
| sabdfl | _bugtrackers = RelatedJoin('BugTracker', joinColumn='project', | 12:27 |
| sabdfl | otherColumn='bugtracker', | 12:27 |
| sabdfl | intermediateTable='ProjectBugTracker') | 12:27 |
| sabdfl | just above that. do you? | 12:28 |
| lifeless | which file ? | 12:28 |
| spiv | There's a bug in SQLObject 0.6 here, I think :( | 12:28 |
| sabdfl | in lib/canonical/launchpad/database/project.py | 12:28 |
| spiv | If you add joinMethodName='_bugtrackers' to that RelatedJoin, it should fix it (but doing so shouldn't be necessary) | 12:28 |
| lifeless | sabdfl: yes. | 12:28 |
| spiv | I'm trying to find a fix for that atm. | 12:29 |
| sabdfl | spiv: it's working fine in my copy | 12:29 |
| lifeless | spiv: on the money honey | 12:29 |
| spiv | sabdfl: Have you upgraded your SQLObject since lifeless imported 0.6? :) | 12:29 |
| lifeless | spiv: that'll be the _poTemplatesJoin thing too | 12:29 |
| sabdfl | spiv: i believe so | 12:30 |
| sabdfl | how do i check? | 12:30 |
| spiv | lifeless: Yeah, I expect so. And also the two UserWarnings when it starts. | 12:30 |
| lifeless | tla tree-version sourcecode/sqlobject | 12:30 |
| spiv | sabdfl: cd sourcecode/sqlobject; tla tree-version | 12:30 |
| spiv | Or lifeless's way :) | 12:30 |
| sabdfl | rocketfuel@canonical.com/sqlobject--test--0.5.1 | 12:30 |
| sabdfl | bollocks | 12:31 |
| sabdfl | i have the following script which runs regularly | 12:31 |
| lifeless | sabdfl: this was an exception, it was an upstream release change. | 12:31 |
| sabdfl | cd ~/projects/ubuntu | 12:31 |
| sabdfl | tla cat-config configs/canonical.com/launchpad/development | xargs -n 2 tla update -d | 12:31 |
| sabdfl | why doesn't that pick it up? | 12:31 |
| lifeless | sabdfl: did you update your config as per my email ? | 12:32 |
| stub | lifeless: run ~stub/buttress-dump.sql - I don't have postgresql access on chinstrap atm. | 12:32 |
| sabdfl | lifeless: i should not have to | 12:32 |
| sabdfl | seriously, if a change like that to a piece of code which i *only use* cannot be done by admins and automatically routed, then it is a bug | 12:33 |
| lifeless | sabdfl: I'll accept that. | 12:33 |
| lifeless | ok, traversal problem: | 12:34 |
| lifeless | * Module zope.app.traversing.adapters, line 52, in traverse | 12:34 |
| lifeless | raise NotFoundError(subject, name) | 12:34 |
| lifeless | __traceback_info__: (<Product at 0x4428072c>, 'sourcesources', [] ) | 12:34 |
| lifeless | NotFoundError: (<Product at 0x4428072c>, 'sourcesources') | 12:34 |
| lifeless | http://localhost:8085/++skin++Debug/doap/projects/do-not-use-info-imports/unassigned | 12:34 |
| lifeless | is where I went to get that | 12:34 |
| sabdfl | lifeless: how do i fix it? can i simply put 0.6 in place of 0.5.1? | 12:35 |
| sabdfl | lifeless: does the same thing happen when we update to a more recent vesion of zope? | 12:35 |
| lifeless | for your dists tree, you just star merge. | 12:35 |
| lifeless | that will propogate the code to your sqlobject, although it won't change the tree-version, *it will give you 0.6* | 12:36 |
| lifeless | for zope, we're still in the same branch, because we've been tracking the same line of development. | 12:36 |
| sabdfl | i think it's the same bug | 12:36 |
| sabdfl | because sourcesources is constructed the same way _bugtrackers is | 12:36 |
| sabdfl | star merge from? | 12:37 |
| lifeless | sabdfl: I sent out an email with all this in it. Is it ok if I point you at that ? | 12:37 |
| sabdfl | ok | 12:37 |
| sabdfl | please fix it so this stuff happens silently from now on. | 12:37 |
| sabdfl | when we switch to sqlobject 0.7, it should just happen, for everybody | 12:38 |
| sabdfl | same for zope updates | 12:38 |
| lifeless | if we get everyone one raw, I'll guarantee that happily. | 12:38 |
| lifeless | s/one/on/ | 12:38 |
| lifeless | what was that demo user again ? | 12:39 |
| spiv | foo.bar@canonical.com | 12:39 |
| lifeless | got it | 12:40 |
| lifeless | sabdfl: looks good so far, testing buildbot now. | 12:41 |
| lifeless | (this is with those sqlobject bug fixes.) | 12:42 |
| spiv | I think I've got a possible fix for the SQLObject bug... just testing. | 12:45 |
| lifeless | spiv: any thoughts on this: | 12:49 |
| lifeless | psycopg.ProgrammingError: ERROR: relation "importersourcesource" does not exist | 12:49 |
| lifeless | oh. | 12:50 |
| lifeless | sabdfl: around ? | 12:50 |
| lifeless | ImporterSourceSource deriving from SourceSource breaks the queries. | 12:52 |
| sabdfl | lifeless: sec, i'm updateing to sqlobject 0.6 | 12:54 |
| sabdfl | holy crap there are a lot of patches to dists that i never had | 12:55 |
| sabdfl | lifeless: go ahead | 12:59 |
| lifeless | is there any reason you didn't move the methods on SourceSource into the database module? | 01:00 |
| lifeless | because thats broken buildbot. | 01:00 |
| lifeless | SQLObject uses the class name in the queries it makes. | 01:00 |
| sabdfl | lifeless: there were several different SourceSource classes | 01:00 |
| lifeless | ok, there was only one derived from SQLObject though. | 01:01 |
| spiv | lifeless: You can set the table name for SQLObject explicitly. | 01:01 |
| spiv | _table = 'SourceSource' | 01:01 |
| lifeless | happier thanks | 01:02 |
| lifeless | sabdfl: forget it | 01:02 |
| sabdfl | in my copy of class SourceSource: | 01:02 |
| sabdfl | class SourceSource(SQLBase): | 01:02 |
| sabdfl | """SourceSource table""" | 01:02 |
| sabdfl | implements (ISourceSource) | 01:02 |
| sabdfl | _table = 'SourceSource' | 01:02 |
| sabdfl | _columns = [ | 01:02 |
| sabdfl | StringCol('name', dbName='name', notNull=True), | 01:02 |
| lifeless | sabdfl: its all good now, no problem. | 01:02 |
| sabdfl | StringCol('title', dbName='title', notNull=True), | 01:02 |
| sabdfl | ... | 01:02 |
| sabdfl | what was the problem? | 01:03 |
| lifeless | the derived class needed _table='SourceSource' added | 01:03 |
| sabdfl | lifeless: why do you need a derived class? we are getting rid of those | 01:03 |
| lifeless | sabdfl: eventually, I don't, but there was one left half-reorganised. | 01:03 |
| lifeless | I just need it to keep working :) | 01:04 |
| sabdfl | where, i would rather fix it properly | 01:04 |
| sabdfl | lifeless: no, that's what got us into this state | 01:04 |
| lifeless | infoImporter.py in lib/canonical/arch | 01:04 |
| sabdfl | nobody know what depends on what, or where it might be hidden | 01:04 |
| sabdfl | lifeless: please move those methods to SourceSource | 01:05 |
| sabdfl | btw - for your "research" list, it might be interesting to look at advanced ways of dealing with code that moves between files | 01:05 |
| sabdfl | jesus | 01:06 |
| lifeless | ? | 01:06 |
| sabdfl | infoImporter subclasses SourceSource | 01:06 |
| sabdfl | then reassigns "SourceSource" to be the subclass | 01:06 |
| sabdfl | nice | 01:06 |
| lifeless | don't blame me - did not do that crack. | 01:06 |
| lifeless | moving them to SourceSource now. | 01:07 |
| sabdfl | so somene reading code in there might have NO idea that they were not dealing with a SourceSource | 01:07 |
| lifeless | ok I'm good. | 01:12 |
| lifeless | I've sent a merge up with what I needed. | 01:12 |
| sabdfl | lifeless: ping when you get the success message | 01:12 |
| lifeless | and I'll tag off a new production config after dinner (which is now 2 hours later due to various*, so am starving) | 01:12 |
| sabdfl | stub: do you have a fix for the RelatedJoin ? | 01:13 |
| lifeless | oh right, I haven't included the RelatedJoin fixes, I didn't want to conflict with you. | 01:13 |
| lifeless | They only affect the front end though. | 01:13 |
| stub | I no nuh-thing! | 01:14 |
| spiv | I'm slowly homing in on the Join bug. | 01:15 |
| spiv | (it also affects MultipleJoin) | 01:15 |
| sabdfl | sorry, meant spiv :-) | 01:15 |
| sabdfl | spiv, is there a workaround i can commit? | 01:15 |
| spiv | sabdfl: Set joinMethodName everywhere. | 01:16 |
| spiv | i.e. foo = RelatedJoin(...) -> foo = RelatedJoin(..., joinMethodName='foo') | 01:16 |
| sabdfl | so MultipleJoin(... joinMethodName=.. ah ok | 01:16 |
| sabdfl | that will only take a few minutes for me to do, but it then makes the code brittle to attribute renaming | 01:17 |
| sabdfl | think you'll have a proper fix shortly? | 01:17 |
| spiv | Another 30min, I think, yeah, there's a surpirsing number of layers of indirection to follow. | 01:17 |
| sabdfl | hmm... there are a lot of MultipleJoin's | 01:18 |
| sabdfl | of curse | 01:18 |
| sabdfl | RelatedJoin is not very common at this point | 01:18 |
| sabdfl | but fixing all of both would take too long | 01:18 |
| spiv | Ah-hah! | 01:21 |
| spiv | I've foundd *something*,, it might not be this bug, but it's certainly a bug ;) | 01:21 |
| spiv | Ok, I want to hurt somebody now, but at least I have a fix... | 01:22 |
| BradB | And the test to show that it works, presumably. ;) | 01:23 |
| spiv | Hah. | 01:23 |
| spiv | BradB: It's called "launchpad" ;) | 01:23 |
| spiv | BradB: It should be pretty easy to write a test for. | 01:24 |
| spiv | BradB: So easy, in fact, that there's no excuse for it to have not been done yet, so no excuse for it being broken by a stupid mistake. | 01:24 |
| spiv | </bitching> | 01:25 |
| spiv | BradB: Yes, I will write a test for it. | 01:25 |
| BradB | spiv: Not everyone using SQLObject uses Launchpad. :) | 01:25 |
| BradB | cool | 01:25 |
| spiv | (Ian actually committed a patch on the off-chance it might fix it, according to the mailing list, without any testing manual or automated!) | 01:25 |
| spiv | (it didn't fix it) | 01:26 |
| spiv | Ok, andrew.bennetts@canonical.com/sqlobject--joinMethodName-fix--0.6 | 01:28 |
| spiv | Currently it only has the fix, unit test is in the works. | 01:29 |
| spiv | The fix itself is a one-liner, btw: | 01:29 |
| spiv | + joinMethodName = property(_get_joinMethodName, _set_joinMethodName) | 01:29 |
| spiv | Gah! | 01:36 |
| spiv | It has failing tests even before I touched it. | 01:36 |
| lifeless | sabdfl: its merged. | 01:39 |
| lifeless | spiv: is that a merge request ? | 01:39 |
| lifeless | (my food is nearly ready... back in ~ 30) | 01:40 |
| spiv | lifeless: Yeah, once I've poked at it a little more and am sure it's good . | 01:41 |
| lifeless | just say wehen | 01:41 |
| spiv | I've just committed a test case that passes with the fix, but not without, though. | 01:41 |
| spiv | Stuff it, I can't see how it can be any worse,, pleas merge :) | 01:41 |
| spiv | BradB: want me to generate a patch for you to commit upstream (if you think it's ok)? | 01:42 |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| BradB | sure, that'd be good | 01:44 |
| BradB | stub: Can you email launchpad@ declaring the standard way to name unique constraints, and the standard way to name foreign key constraints? I thought I'd borrowed from the way it's currently done in much of the SQL, but I think sabdfl wants something more precise and descriptive. | 01:46 |
| stub | I'm using table_column_key to match the postgres default | 01:46 |
| stub | I usually fix peoples naming when the patches come through ;) | 01:47 |
| BradB | stub: Be lazy and write an email so that you can save yourself work. ;) | 01:53 |
| === stub is almost done | ||
| stub | Naming conventions of course really depend on what mood I'm in (or what mood Mark is in if he decides to overrule me ;) ) | 01:54 |
| BradB | we need a BDBAFL! | 01:55 |
| stub | The title I tend to use is Database Nazi, so that 'B' might have to go. Me and my 3 month contract is all for the 'FL' though ;) | 02:00 |
| BradB | spiv: The test still fails with your patch (few lines of pasting coming up): | 02:04 |
| BradB | Traceback (most recent call last): | 02:04 |
| BradB | File "test.py", line 771, in testJoinAttributeWithUnderscores | 02:04 |
| BradB | self.failUnless(hasattr(ImplicitJoiningSO, 'foo')) | 02:04 |
| BradB | File "/opt/local/lib/python2.3/unittest.py", line 278, in failUnless | 02:04 |
| BradB | if not expr: raise self.failureException, msg | 02:04 |
| BradB | AssertionError | 02:04 |
| stub | are we there yet? | 02:04 |
| spiv | BradB: Guh? | 02:05 |
| === spiv double-checks | ||
| BradB | I ran them like this: cd SQLObject/tests; python test.py -dpostgres | 02:05 |
| dilys | New bug 2086 for Launchpad/Launchpad: Melding dbschema and sqlobject would be cool | 02:06 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2086 | 02:06 |
| spiv | BradB: PYTHONPATH! | 02:06 |
| BradB | garghalj | 02:06 |
| spiv | BradB: I ran it as: | 02:06 |
| spiv | PYTHONPATH=. python tests/test.py --database=postgres | 02:06 |
| spiv | (in the root of the sqlobject checkout) | 02:07 |
| BradB | yeah yeah :) | 02:07 |
| BradB | i hate myself for that | 02:07 |
| spiv | BradB: Thanks for double-checking that the test sfail before my patch, though ;) | 02:07 |
| === spiv workraes | ||
| spiv | workraves, rather. | 02:08 |
| BradB | Committed. | 02:10 |
| === BradB picks up where he left off on submitting the schema changes for infestation | ||
| BradB | spiv: Wouldn't you think a sane test suite tests the things in its parent directory explicitly? | 02:13 |
| BradB | Maybe I'll patch test.py too, if it seems reasonably to do so. | 02:14 |
| Kinnison | ARGH, bloody mailman | 02:14 |
| BradB | s/reasonably/reasonable/ | 02:14 |
| Kinnison | Can someone with privs on the launchpad list accept the mail I sent to it? | 02:14 |
| Kinnison | At this rate I'm going to have to add a second subscription | 02:14 |
| BradB | sabdfl: We want to rename these again then, don't we? BugProductInfestation -> BugProductReleaseInfestation, BugPackageInfestation -> BugPackageReleaseInfestation. | 02:20 |
| sabdfl | BradB: no, i don't think that's necessary | 02:22 |
| BradB | ok | 02:22 |
| sabdfl | since a bug can only infect code, and the code must be in a release | 02:22 |
| sabdfl | cprov: could you check gina into the launchpad archive please, at a place stevea decides? | 02:38 |
| cprov | sabdfl: yes. of course, I'll ask him | 02:40 |
| sabdfl | great. it's super work, thank you | 02:40 |
| cprov | SteveA: ping | 02:40 |
| SteveA | cprov: lib/canonical/launchpad/gina perhaps | 02:47 |
| cprov | SteveA: maybe, lib/canonical/launchpad/scripts/ then gina & nicole ? | 02:48 |
| SteveA | these are scripts? | 02:48 |
| SteveA | not libraries | 02:48 |
| SteveA | ? | 02:48 |
| cprov | SteveA: python standalone scripts | 02:48 |
| SteveA | oh, okay | 02:49 |
| SteveA | ok, let's put it where you suggested | 02:49 |
| cprov | SteveA: tks | 02:49 |
| SteveA | we might move them to ./scripts later | 02:49 |
| SteveA | but I want to think about that a bit | 02:49 |
| cprov | SteveA: ok now it goes in /lib/canonical/launchpad/scripts :) | 02:50 |
| BradB | stub: Hang on with that SQL for a bit, there might be one column we overlooked. | 02:51 |
| lifeless | stub: ready ? | 02:59 |
| stub | yup | 02:59 |
| lifeless | all shut down | 03:00 |
| lifeless | beginning code update | 03:00 |
| stub | Database all done | 03:05 |
| sabdfl | lifeless: does your version ave a fix for the sqlobject issue? | 03:09 |
| sabdfl | SteveA: we need a "scripts" place | 03:09 |
| lifeless | sabdfl: I didn't commit that fix, thought you were going to. | 03:09 |
| sabdfl | and the libs should have names approriate to their purpose, even if the script has a fun name | 03:10 |
| daf | sabdfl: we have lib/canonical/rosetta/scripts | 03:10 |
| SteveA | sabdfl: yep, agreed | 03:10 |
| sabdfl | lifeless: spiv, i was waiting for the proper fix | 03:10 |
| daf | sabdfl: possibly we should have a lib/canonical/launchpad/scripts | 03:10 |
| daf | sabdfl: (as cprov suggested) | 03:10 |
| sabdfl | maybe "tools" is better than scripts | 03:10 |
| sabdfl | where would a library go? | 03:10 |
| daf | a library for what? | 03:11 |
| lifeless | spiv: is there a fix ? | 03:11 |
| sabdfl | spiv: whats the status on that fix, it breaks a lot of the things i need from this code update | 03:11 |
| spiv | For joinMethodName? | 03:11 |
| spiv | lifeless: It's in my branch, and ready to be merged. | 03:11 |
| lifeless | spiv: you were testing it further ... | 03:11 |
| spiv | lifeless: BradB has committed it upstream already, I believe. | 03:11 |
| spiv | lifeless: Oh, sorry, yes, I'm happy with it now :) | 03:12 |
| SteveA | daf: we'll put all the scripts in a unified place | 03:12 |
| spiv | lifeless: My bad for not notifying you :/ | 03:12 |
| lifeless | mergted | 03:12 |
| lifeless | sabdfl: update your code and that should | 03:12 |
| lifeless | work | 03:12 |
| sabdfl | lifeless: ok, i'll need to test everything | 03:13 |
| BradB | spiv: Yep, it's committed upstream. | 03:14 |
| lifeless | stub: do I still need this patch? : | 03:14 |
| lifeless | --- orig/lib/canonical/lp/sql.py | 03:14 |
| lifeless | +++ mod/lib/canonical/lp/sql.py | 03:14 |
| lifeless | @@ -3,6 +3,7 @@ | 03:14 |
| lifeless | from zope.app.rdb.interfaces import IZopeConnection, IZopeCursor | 03:14 |
| lifeless | 03:14 | |
| lifeless | def confirmEncoding(*args,**kw): | 03:14 |
| lifeless | + return None | 03:14 |
| lifeless | rdb = zapi.getUtility(IZopeDatabaseAdapter, 'launchpad') | 03:14 |
| lifeless | dsn = rdb.getDSN() | 03:15 |
| lifeless | dbname = str(dsn.split('//')[1] ) | 03:15 |
| stub | Try it without it - if it works, great. One less bug to sort out :-) | 03:15 |
| lifeless | har | 03:15 |
| stub | keep it in if it makes things simpler though - we can safely assume that production is running with the correct database encoding ;) | 03:15 |
| stub | (That is the code that makes launchpad refuse to start if the database encoding is incorrect if you remember) | 03:16 |
| daf | stub: what was the problem with it? | 03:17 |
| stub | daf: For some stupid reason, despite working perfectly on everyones dev environment it didn't on the production launchpad server :-/ | 03:17 |
| daf | oh, lovely | 03:17 |
| BradB | stub: I've changed the infestation script: added a few more columns, another table, a couple more constraints and corrected some casing to be more consistent with the SQL that's already being used to build the DB. Should I send a diff of it to the list, or the whole thing? | 03:19 |
| stub | What do you mean whole thing? | 03:20 |
| BradB | all the SQL again, or just a diff of the stuff I've just changed. | 03:20 |
| BradB | "all" needed to create the stuff related to infestation. | 03:20 |
| stub | Oh... all of your changes in one place if possible. | 03:20 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| BradB | I'll just send a second copy of it to the list then, probably easier. | 03:21 |
| stub | Ta. | 03:22 |
| kiko | morning lunchpadders | 03:22 |
| stub | yo | 03:23 |
| kiko | how's the sandwich sprint going? | 03:23 |
| kiko | debonzi, cprov: buenas | 03:23 |
| BradB | kiko: We "wrap" up tomorrow, eh. | 03:23 |
| sabdfl | erk. lifeless, found a bug editing sourcesource if you change archarchive, will fix and commit | 03:25 |
| sabdfl | i'll be toast when we're done | 03:26 |
| lifeless | heh :) | 03:26 |
| sabdfl | stub: maybe we should have a "proposed changes" dir in db/schema/ | 03:26 |
| sabdfl | with scriptlets that are under construction | 03:27 |
| lifeless | we're good | 03:27 |
| lifeless | https://macquarie.warthogs.hbd.com/launchpad/doap/projects/do-not-use-info-imports/unassigned | 03:27 |
| stub | Sure. I'm not particularly fussed how they come through. | 03:27 |
| stub | I tend to leave them lying around in database/schema with the extension '.pending' but that might get messy if everyone did it ;) | 03:27 |
| lifeless | heres the first challenge though. | 03:28 |
| lifeless | we need the apache username @ passwords synced with those inside launchpad | 03:28 |
| lifeless | or I can't edit anything :| | 03:28 |
| === lifeless goes to bring importd back to life | ||
| stub | ssh tunnel could get things running, but would suck :-( | 03:29 |
| lifeless | stub: heh, YES. | 03:29 |
| kiko | lifeless, have you considered using mod_auth_* to avoid the sync naturally? | 03:29 |
| lifeless | kiko: I didn't setup apache. so haven't considered anything :) | 03:30 |
| lifeless | I simply got to throw peanuts @ elmo @ 5am. | 03:30 |
| kiko | we could just write a mod_auth_perl module or something that connected to the DB and did what we wanted. it's not complicated. | 03:30 |
| lifeless | kiko: well, for /right now/ I'll accept stub adding a person for me, and the same password being given to apache :) | 03:31 |
| kiko | you hackers | 03:31 |
| lifeless | thank you | 03:31 |
| === limi [~limi@212.80-202-72.nextgentel.com] has joined #launchpad | ||
| limi | yay | 03:32 |
| limi | network is back at least | 03:32 |
| === limi is now one tooth less dangerous | ||
| limi | ...only 3 left to go :P | 03:33 |
| sabdfl | limi: welcome back | 03:34 |
| sabdfl | less wise? | 03:34 |
| limi | yes, 1/4th | 03:34 |
| sabdfl | lifeless: stub: code works for my purposes, pqm message is on the wire with merge for fix to sourcesource editing | 03:34 |
| limi | the scary surgery-requiring stuff comes later | 03:34 |
| === limi goes back to Shipit | ||
| cprov | spiv: ping | 03:35 |
| lifeless | sabdfl: cool. | 03:37 |
| spiv | cprov: pong. | 03:37 |
| lifeless | I'll backport it tomorrow morning. | 03:37 |
| sabdfl | lifeless: backport? can we not upload this current code? | 03:37 |
| lifeless | sabfl the username thing is somewhat more important. | 03:38 |
| sabdfl | it has a few other fixes, like passwords | 03:38 |
| lifeless | sabdfl: we're on a branch., I generally cherry pick specific fixes, so that we don't introduce regressions. | 03:38 |
| cprov | spiv: can you suggest some place to add the NickName.py lib from Brab in LP ? | 03:39 |
| lifeless | for example there has been at least one other commit in the interim (by celso I think), and I haven't tested that. | 03:39 |
| spiv | cprov: Hmm. | 03:39 |
| sabdfl | lifeless: ok, then you'll need to ask stevea where to find the password fixes he needs | 03:39 |
| lifeless | sabdfl: I'll bring your entire commit across. | 03:40 |
| lifeless | elmo_ stub so, what do I need to do to get this usercode ? | 03:41 |
| spiv | cprov: I think it'd be best to ask Steve; I'm not sure what the best place is. | 03:41 |
| cprov | spiv: aha, He told me the same thing about you one minute ago :) | 03:42 |
| spiv | cprov: Drat ;) | 03:42 |
| cprov | spiv: the question is: You'll use it in FOAF too ? where do you preffer ? | 03:42 |
| cprov | spiv: btw, we need methods inside Person(SQLBase) to createPeople() and createTeam() | 03:43 |
| cprov | spiv: they might be useful for us | 03:43 |
| spiv | cprov: I'd be tempted to put them in canonical.launchpad.nickname, I'm not sure if that's consistent with other stuff in canonical.launchpad. | 03:44 |
| spiv | cprov: FOAF is another candidate for the nickname stuff. | 03:44 |
| cprov | spiv: this place (canonical.launchpad) is a very confused today ... | 03:45 |
| spiv | cprov: How would Person.createPeople(...) differ from Person(...)? | 03:45 |
| spiv | Yes, but it's being cleaned up progressively. | 03:45 |
| spiv | Avoiding it just because it's messy will lead us back to where we started ;) | 03:45 |
| kiko | the land of rape and honey? | 03:46 |
| === spiv -> workrave for 10min | ||
| lifeless | there was a importd problem, fieldnames had been changed, fixed now. | 03:46 |
| cprov | spiv: you're right ! in nothing ... so let's use it in FOAF :) | 03:47 |
| lifeless | sabdfl: need me for anything else? | 03:51 |
| cprov | spiv: now I'm creating new Person/Team by Person() ...but I need to fill the notNull name field, so let's say some place to add the Nickname lib so I can continue to create in the same way til we decide the methods, ok? | 03:51 |
| lifeless | stub: we're done other than that person thing. | 03:52 |
| === lifeless crashes and burns. night all. | ||
| stub | eh? | 03:53 |
| lifeless | stub: apache and launchpad have conflicting http credentials. | 03:53 |
| stub | that one. | 03:53 |
| lifeless | that one. | 03:53 |
| sabdfl | night lifeless | 03:53 |
| === lifeless waves | ||
| SteveA | spiv: ping | 03:54 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | hi | 03:56 |
| kiko | carlotz! | 03:56 |
| === BradB ate too much chocolate | ||
| BradB | my brain is as fuzzy as a very fuzzy thing right now | 03:58 |
| sabdfl | lifeless: did you branch this morning for that production update? | 03:59 |
| sabdfl | stevea wants to know how to point you at the password code that needs to be on the production box? | 03:59 |
| cprov | BradB_Crashed by Launchpad DB :) | 04:00 |
| kiko | BradB, you're *SUCH* a slacker, you'll even try lunchpadding to get off the hook | 04:00 |
| carlos | daf: did you saw the db changes?, any change? | 04:00 |
| BradB | heh | 04:01 |
| cprov | carlos: don't be that dificult, we had thousands of them ...lol | 04:01 |
| spiv | SteveA: pong. | 04:02 |
| carlos | cprov: :-P | 04:03 |
| daf | carlos: do you mean "have you looked at my patch?" | 04:04 |
| carlos | daf: yes | 04:04 |
| carlos | O:-) | 04:04 |
| carlos | did you saw *my* db changes :-P | 04:04 |
| cprov | carlos: hehe | 04:05 |
| daf | sorry, no | 04:05 |
| daf | carlos: https://rosetta.warthogs.hbd.com/rosetta/prefs -- this looks broken | 04:05 |
| carlos | daf: I fixed it yesterday | 04:07 |
| carlos | daf: ok, the selector bug? | 04:07 |
| === BradB is now known as BradB|Expo | ||
| carlos | daf: it's the bug that we have after the Warnings we get from sqlobject | 04:08 |
| carlos | because the Joins | 04:08 |
| carlos | daf: spiv knows about it already | 04:08 |
| spiv | carlos, daf: that's now fixed. | 04:08 |
| spiv | Update your SQLObject :) | 04:08 |
| carlos | spiv: ok | 04:08 |
| carlos | :-) | 04:08 |
| SteveA | spiv: got jabber? | 04:09 |
| spiv | SteveA: do now. | 04:09 |
| daf | carlos: ok, going out -- back later | 04:09 |
| carlos | daf: later | 04:10 |
| SteveA | spiv: can you ping me on jabber? | 04:10 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| stub | sabdfl, BradB|Expo: BugInfestationType.type -- shouldn't this be BugInfestationType.name ? | 04:47 |
| stub | And I assume that column (type or name) is UNIQUE? | 04:48 |
| SteveA | brad is away | 04:53 |
| SteveA | as with almost everyong | 04:53 |
| SteveA | at the linux expo | 04:53 |
| === stub sulks | ||
| carlos | spiv: could you commit the patch you sent me for sqlos? | 05:08 |
| spiv | carlos: Ok. | 05:16 |
| carlos | spiv: thanks | 05:16 |
| spiv | (I already committed it upstream after all...) | 05:16 |
| carlos | spiv: btw, I have latest sqlobject code and I still have the Join bug | 05:16 |
| carlos | The warning is not there anymore, but rosetta does not work | 05:17 |
| spiv | carlos: Oh! | 05:17 |
| === carlos reactivates postgres log to see the sql sentences | ||
| spiv | carlos: I wonder if it's still the same bug, or a new one... | 05:17 |
| carlos | no idea | 05:17 |
| spiv | I'm guessing it's a different issue, but that's just a gues :) | 05:18 |
| spiv | guess, rather. | 05:18 |
| spiv | If you can narrow down where the problem is in rosetta, I'll help figure out what's going wrong. | 05:18 |
| carlos | ok, thanks | 05:19 |
| carlos | the join does not queries for the table rows | 05:20 |
| carlos | When you visit rosetta/prefs I get: | 05:20 |
| carlos | 2004-10-07 17:19:16 [4916] LOG: statement: select p.id, displayname, givenname, familyname, | 05:20 |
| carlos | password from person as p, emailaddress as e where p.id | 05:20 |
| carlos | = e.person and e.email='carlos@canonical.com' | 05:20 |
| carlos | 2004-10-07 17:19:16 [4916] LOG: statement: SELECT name, displayname, givenname, familyname, password, teamowner, teamdescription, karma, karmatimestamp FROM Person WHERE id = 13 | 05:20 |
| carlos | 2004-10-07 17:19:16 [4916] LOG: statement: SELECT Language.id, Language.code, Language.nativename, Language.englishname, Language.pluralforms, Language.pluralexpression FROM Language WHERE 1 = 1 ORDER BY englishname | 05:20 |
| carlos | we have code that ask for PersonLabel table | 05:21 |
| carlos | using the Joins | 05:21 |
| carlos | spiv: how could I debug it so it could help you? | 05:21 |
| spiv | Where is the code with that join? | 05:22 |
| carlos | inside the Person object | 05:22 |
| carlos | _labelsJoin = RelatedJoin('Label', joinColumn='person', | 05:23 |
| carlos | otherColumn='label', intermediateTable='PersonLabel') | 05:23 |
| carlos | line #71 | 05:23 |
| carlos | launchpad/lib/canonical/launchpad/database/person.py | 05:23 |
| carlos | shit | 05:25 |
| carlos | spiv: wait | 05:25 |
| carlos | I think it's not a problem with sqlobject | 05:25 |
| carlos | the template is completely broken | 05:25 |
| carlos | limi: ? | 05:26 |
| limi | carlos? | 05:26 |
| spiv | carlos: Phew ;) | 05:26 |
| carlos | limi: did you changed rosetta-preferences.pt? | 05:27 |
| carlos | it's broken, all the code I had there is gone | 05:27 |
| carlos | so the language selector is not working anymore | 05:27 |
| stub | Has anyone gone over Lalo's patch yet btw? | 05:27 |
| stub | The initZopeless modifications? | 05:27 |
| carlos | stub: don't know | 05:30 |
| carlos | stub: did he leave already? | 05:30 |
| SteveA | stub: know much about cookie auth in zope2 ? | 05:31 |
| stub | carlos: He was hanging around for a bit longer and was going to check it in - don't know | 05:32 |
| stub | SteveA: Way too much | 05:32 |
| === stub shudders | ||
| === SteveA jabbers at stub | ||
| === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| spiv | stub: Aside from the docstring of dubious copyright, it looked good to me. | 05:35 |
| stub | Cool - I guess it should be committed then and people sort out the fallout of the API change | 05:39 |
| dilys | New bug 2087 for Launchpad/Database: initZopeless patch | 05:41 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2087 | 05:41 |
| carlos | well, at this moment, launchpad is broken so I don't think it will be a problem :-P | 05:42 |
| carlos | lots of imports are missing from the new object layout | 05:42 |
| carlos | SteveA: are we free to fix the missing imports we detect? | 05:43 |
| limi | carlos: no, haven't touched Rosetta in ages, unfortunately | 05:46 |
| carlos | archzoom says that you changed it :-? | 05:46 |
| limi | when? | 05:46 |
| carlos | 2004-10-05 GMT Canonical.com Patch Queue Manager <pqm@canonical.com> patch-501 | 05:47 |
| carlos | modified files: | 05:47 |
| carlos | lib/canonical/launchpad/templates/bug-index.pt | 05:47 |
| carlos | lib/canonical/launchpad/templates/launchpad.css | 05:47 |
| carlos | lib/canonical/launchpad/templates/main-template.pt | 05:47 |
| carlos | lib/canonical/launchpad/templates/plone.css | 05:47 |
| carlos | lib/canonical/launchpad/templates/portlet-bug-reference.pt | 05:47 |
| limi | two days ago? | 05:47 |
| carlos | lib/canonical/launchpad/templates/rosetta-preferences.pt | 05:47 |
| carlos | lib/canonical/lp/resources.zcml | 05:47 |
| carlos | lib/canonical/malone/browser.py | 05:47 |
| carlos | yes | 05:47 |
| carlos | seems like you put there a "development" template | 05:47 |
| limi | that's probably an errouneous checkin from a Malone checkin | 05:48 |
| limi | feel free t back it out | 05:48 |
| === limi sighs at arch | ||
| carlos | limi: so the removal of the name and password form was accidental? | 05:48 |
| limi | I'm *this* close to setting up my own local SVN repository for doing work | 05:48 |
| limi | yes, probably | 05:48 |
| carlos | ok | 05:48 |
| carlos | I will restore it now, then | 05:49 |
| limi | I can't remember to have done any of that, but there you go | 05:49 |
| limi | arch moves in mysterious ways | 05:49 |
| === limi is in pain, and goes to bed | ||
| carlos | anyone could help me about the new object layout? | 06:04 |
| SteveA | what do you want to know? | 06:12 |
| SteveA | you are using ctags aren't you? | 06:12 |
| carlos | ctags? | 06:13 |
| carlos | SteveA: I need to know the policy about the new layout, I think it's a file per object for the interface and for the implementation (inside interfaces and database) | 06:14 |
| carlos | but I'm not sure | 06:14 |
| carlos | I'm getting errors like: | 06:15 |
| carlos | * Module canonical.rosetta.browser, line 403, in selectedLanguages | 06:15 |
| carlos | return list(self.person.languages()) | 06:15 |
| carlos | * Module canonical.launchpad.database.person, line 77, in languages | 06:15 |
| carlos | schema = Schema.byName('translation-languages') | 06:15 |
| carlos | NameError: global name 'Schema' is not defined | 06:15 |
| carlos | so I suppose I need to move the "Schema" object from dlalo.py to database/schema.py (and perhaps the same with the interface, not sure if it's already in place) | 06:16 |
| carlos | also, I don't know where should I put other objects like Languages or Schemas that are not database objects but helper ones | 06:17 |
| SteveA | not a file per class | 06:25 |
| SteveA | one file per large area of functionality | 06:25 |
| carlos | SteveA: but we have a file for potemplates and another one for pomsgsets | 06:27 |
| SteveA | I don't think we should have that | 06:27 |
| SteveA | we should probably have one file for po-related stuff | 06:28 |
| carlos | could we get a README file talking about it? | 06:28 |
| SteveA | yes | 06:28 |
| SteveA | we're still working it out | 06:28 |
| carlos | launchpad is not working at this moment and I need it understand it to help fixing it | 06:29 |
| SteveA | oh, it was working a short time ago | 06:29 |
| carlos | sorry "I need it to understand" | 06:29 |
| carlos | SteveA: I think it stop working with latest mark commit | 06:29 |
| carlos | he moved his .py file content into database/ | 06:29 |
| SteveA | circular import? | 06:30 |
| carlos | no | 06:30 |
| carlos | missing imports | 06:30 |
| SteveA | oh, ok | 06:30 |
| SteveA | interfaces should be all imported from canonical.launchpad.interfaces | 06:30 |
| SteveA | database stuff needs to be imported into other database modules from those particular database modules | 06:31 |
| SteveA | but can be imported into the rest of the application from canonical.launchpad.database | 06:31 |
| carlos | and what happens with objects that are still outside database/ ? | 06:32 |
| carlos | like Schema and Language (they are still inside dlalo.py | 06:32 |
| carlos | ) | 06:32 |
| SteveA | where is dlalo.py? | 06:37 |
| carlos | launchpad/lib/canonical/launchpad | 06:37 |
| carlos | with the other files | 06:38 |
| SteveA | and, dlalo.py is imported into database | 06:38 |
| carlos | it was | 06:39 |
| carlos | I mean, before Mark changes (not sure if the break was before them), it was working | 06:40 |
| SteveA | you could try the tree before mark's changes, and see if that works | 06:42 |
| carlos | hmm, it's not working that version either but because other problem: | 06:55 |
| carlos | ConfigurationError: ('Invalid value for', 'factory', "Couldn't import canonical.lp.tales, No module named icelso in canonical.lp.tales.RequestAPI") | 06:55 |
| carlos | SteveA: btw, I suppose that the future is to move all d*.py and i*.py files into database and interfaces so I will try to fix it as it's now | 06:56 |
| SteveA | ok, yes | 06:56 |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| === justdave_zzz is now known as justdave | ||
| === elmo_ [~james@george.kkhotels.co.uk] has joined #launchpad | ||
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| elmo_ | spiv: ! | 09:38 |
| spiv | elmo_: Hmm? | 09:46 |
| spiv | elmo_: If you're shocked at the cleartext emailing of passwords, don't be :P | 09:48 |
| kiko | I am | 09:50 |
| elmo_ | spiv: I'm not shocked, I'm bitter. very bitter | 09:52 |
| spiv | elmo_: Oh, right. | 09:52 |
| kiko | cheeky cheeky jtroup | 09:59 |
| === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| === ..[topic/#launchpad:kiko] : lunchpad: home of the sandwich sprinters | fogo na bomba | ||
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === BradB|Expo [~bradb@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === SteveA [~steve@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| sabdfl | kiko: fogo na bomba? | 12:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!