| sabdfl | i'm assuming they are working and i'm not, in fact, breaking pages :-) | 12:00 |
|---|---|---|
| kiko | that's the problem with tests -- you can only rely on them to the extent that they themselves have enough coverage :) | 12:03 |
| === limi loves tests too | ||
| limi | we always write our tests before our code in our company now (really) | 12:06 |
| limi | it rocks | 12:06 |
| BradB | I do too; can't do that with functional doctests though. :) | 12:06 |
| limi | no, of course not :) | 12:06 |
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === BradB is now known as BradB|away | ||
| sabdfl | night guys | 12:53 |
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| cprov | Kinnison: ping | 01:00 |
| Kinnison | yes? | 01:10 |
| Kinnison | cprov: pong | 01:12 |
| lifeless | so how do I find a project by its name ? | 01:17 |
| carlos | when I try to execute the launchpad's tests I get this error: | 01:17 |
| carlos | Traceback (most recent call last): | 01:17 |
| carlos | File "test.py", line 27, in ? | 01:17 |
| carlos | from zope.app.tests.functional import FunctionalTestSetup | 01:17 |
| carlos | File "/home/carlos/Work/dists/launchpad2/lib/zope/app/tests/functional.py", line 32, in ? | 01:17 |
| carlos | from ZODB.DB import DB | 01:17 |
| carlos | File "/home/carlos/Work/dists/launchpad2/lib/ZODB/__init__.py", line 21, in ? | 01:17 |
| carlos | from persistent import TimeStamp | 01:17 |
| carlos | File "/home/carlos/Work/dists/launchpad2/lib/persistent/__init__.py", line 19, in ? | 01:17 |
| carlos | from cPersistence import Persistent, GHOST, UPTODATE, CHANGED, STICKY | 01:17 |
| carlos | ImportError: No module named cPersistence | 01:17 |
| carlos | which python module should I install? (It was working before merging with rocketfuel) | 01:18 |
| spiv | carlos: Have you built Zope's C modules? | 01:21 |
| spiv | lifeless: With the SQLObject? | 01:22 |
| lifeless | well I had a convenience mapper, where I could just go 'mapper.findByName('foo')' | 01:22 |
| lifeless | but thats gone away... and I just found that not all the code using it was converted. | 01:22 |
| Kinnison | Well; on the assumption that cprov isn't gonna wake up | 01:22 |
| spiv | lifeless: That's still there, hiding in soyuz/importd.py, according to ctags... :) | 01:23 |
| spiv | You should be able to say "from canonical.database import Project; foo = Project.byName('foo')", but someone needs to set alternateID=True in the declaration of the name column. | 01:24 |
| carlos | spiv: seems like that was the problem, thank you. I did not saw that zope was updated since my last rebuild... | 01:24 |
| lifeless | Project.byName('foo') would be good. | 01:24 |
| lifeless | Product.byNameAndProject('bar', foo) | 01:25 |
| lifeless | would be the next request. | 01:25 |
| spiv | lifeless: I think I'm going to have to run importd on my laptop to track down this taxi bug... my guesses at causes haven't found any problem.s | 01:25 |
| lifeless | spiv: ok. | 01:25 |
| lifeless | its easy to setup, or at least, I've always found it easy. | 01:25 |
| lifeless | step 1 - check out a buildbot config. | 01:26 |
| spiv | lifeless: There's a wiki page of something describing how? | 01:26 |
| spiv | 1. got that already :) | 01:26 |
| lifeless | spiv: yes | 01:26 |
| lifeless | ImportProcess | 01:26 |
| spiv | Ok, I'll try that. I recall getting those instructions to work on my desktop a few months ago... | 01:27 |
| lifeless | now, there are a couple of minor nits with that page. | 01:27 |
| lifeless | we've changed to reading from the database - but you can ignore that | 01:27 |
| lifeless | taxi in the slave is not affected by that change. | 01:28 |
| === spiv nods | ||
| lifeless | basically, let me know of any irregularities, and I'll fix them with you right now and update the wiki page | 01:31 |
| lifeless | Exception exceptions.TypeError: <exceptions.TypeError instance at 0x40d02acc> in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0x40fcdf4c>> ignored | 01:32 |
| lifeless | has started happening for me.. just a heads up | 01:32 |
| spiv | Yeah, I've seen that too. | 01:32 |
| spiv | It's a real pita to track down. | 01:32 |
| spiv | Because it happens during Python's shutdown, so things liek teh sys module aren't available any more... | 01:33 |
| spiv | Makes debugging tricky :) | 01:33 |
| lifeless | ewww | 01:33 |
| lifeless | import pdb; import sys; :) | 01:33 |
| spiv | lifeless: You'd think so, wouldn't you? ;) | 01:33 |
| === debonzi [~debonzi@200.158.100.251] has left #launchpad ["Leaving"] | ||
| cprov | lifeless: pqm is not sending success/failure email to me anylonger . can you verify why ? the last time on Soyuz sprint I sent hin an unsigned message, after that no messages are comming from my PQM request, but they still working fine | 01:46 |
| cprov | lifeless: email me if you have news about it, tks | 01:49 |
| lifeless | spiv: well, there goes the mapper. | 01:57 |
| lifeless | :[ | 01:57 |
| lifeless | spiv: got it going ? | 02:01 |
| spiv | lifeless: Just getting to that now... | 02:02 |
| lifeless | ok. | 02:03 |
| lifeless | I think my lappy is gonna meltdown | 02:03 |
| spiv | Not enough fans? ;) | 02:04 |
| lifeless | 15 minutes on 100% cpu, and its boiling hot here right now | 02:04 |
| lifeless | was 41' in north ryde two days back | 02:04 |
| spiv | Ouch. | 02:04 |
| lifeless | just about burn my hand in the airstream from the fans | 02:07 |
| spiv | Hmm. The slave won't start for me. | 02:12 |
| spiv | Fails in arch._twisted in _spawn on assert not threadable.isInIOThread() | 02:12 |
| lifeless | ewww. | 02:13 |
| lifeless | that sounds like either a) twisted has changed breaking davids test suite (try make check in pyarch), or b) its not making the thread in buildbot_slavecommand.py in importd/ | 02:14 |
| spiv | make check in pyarch has one failure for me: ERROR: Changeset.get_index supports escaped file names. | 02:16 |
| spiv | Otherwise, it passes. | 02:16 |
| lifeless | ok, that sounds like you have an old tla. | 02:17 |
| lifeless | shouldn't matter for this. | 02:17 |
| lifeless | 'shouldn't. | 02:17 |
| lifeless | so, when does it fail - twistd -f buildbot.tap, or when you 'force job' ? | 02:17 |
| spiv | The former. | 02:17 |
| lifeless | the slave doesn't do any arch stuff on startup. | 02:18 |
| spiv | (I have an integration tla from a few days ago, I think...) | 02:18 |
| lifeless | unless you'd already done a force job, which is queued. | 02:18 |
| lifeless | got a backtrace on the failure? | 02:18 |
| spiv | Oh, my bad, I think this is in botmaster. | 02:18 |
| lifeless | oh ok. | 02:18 |
| lifeless | I know what that will be. the master *is* running the io thread. | 02:19 |
| lifeless | do this. | 02:19 |
| carlos | lifeless: do we have any schedule for arch.gnome.org? | 02:19 |
| lifeless | in master.cfg, before the 'scan arch directories' code, | 02:19 |
| lifeless | import arch._tla | 02:19 |
| lifeless | arch._tla.spawn=arch._tla.PyArchSpawningStrategy('tla') | 02:20 |
| lifeless | that should fix it. | 02:20 |
| lifeless | carlos: no. | 02:20 |
| carlos | ok | 02:25 |
| spiv | Oops, need a cvsmail dir... | 02:26 |
| spiv | Ok, it's running... | 02:28 |
| spiv | Hmm, the slaves aren't connecting... | 02:29 |
| spiv | Ok, the port number on the wiki instructions is wrong... | 02:30 |
| lifeless | check master.cfg | 02:31 |
| lifeless | I'm noting all these down to document later. | 02:32 |
| spiv | What should I be looking for? builders is being passed to processDB... | 02:33 |
| spiv | Oh, hmm. | 02:34 |
| spiv | It has paths like '/home/robertc/source/canonical/buildbot/launchpad/botslave/' :) | 02:34 |
| lifeless | oh right. | 02:34 |
| === spiv tries the obvious thing... | ||
| lifeless | that is new | 02:34 |
| lifeless | in your botslave dir | 02:35 |
| lifeless | mkdir gpg | 02:35 |
| lifeless | mkdir mirrorarchives | 02:35 |
| lifeless | set the other path to point at mirrorarchives | 02:35 |
| lifeless | and in the gpg dir create a keypair | 02:36 |
| lifeless | ddaa: btw, .netrc isn't needed, curl already does the auth with the current config. | 02:37 |
| lifeless | you have to put it in the url - https://foo@bar:host/ | 02:37 |
| lifeless | and it will just work. | 02:37 |
| spiv | Do you know the gpg command off-hand? | 02:37 |
| lifeless | gpg --no-default-keyring --keyring ./arch@canonical.com.pub --secret-keyring ./arch@canonical.com.secret --gen-key | 02:38 |
| lifeless | it must have arch@canonical.com as the uid | 02:38 |
| spiv | [Broker,client] setBuilderList [] | 02:41 |
| lifeless | ddaa: and no, I wrote the buildbot conversion logic. bob2 did taxi. | 02:41 |
| lifeless | spiv: hmm. no builders found. | 02:41 |
| spiv | Oh, and the master says: [Broker,0,127.0.0.1] slave trogslave has leftover directories (gpg,mirrorarchives): you can delete them now | 02:41 |
| lifeless | try visiting /reload on buildbot | 02:41 |
| spiv | Ooh. | 02:42 |
| spiv | I got an error in my new stuff. | 02:42 |
| lifeless | hmm ? | 02:42 |
| lifeless | you know I need more detail to help :) | 02:43 |
| spiv | I'm checking it's not my fault ;) | 02:43 |
| spiv | I'm saving you for the important questions ;) | 02:44 |
| spiv | It's from the initZopeless call in jobstuff... | 02:44 |
| spiv | Hmm, now an SQLObject error. | 02:45 |
| spiv | Oh, no, my bad :) | 02:45 |
| lifeless | whats the big O for list.append ? | 02:46 |
| spiv | O(1) | 02:48 |
| spiv | Python lists are basically like a vector<PyObject*> ;) | 02:49 |
| lifeless | constant time ? | 02:51 |
| lifeless | serious ? | 02:51 |
| spiv | Amortized, of course. | 02:51 |
| lifeless | cause buildbot slows /waaaaay/ down when the log gets long | 02:52 |
| lifeless | and I mean /way/ | 02:52 |
| spiv | Intriguing. | 02:52 |
| spiv | From listobject.c in Python: | 02:53 |
| spiv | /* This over-allocates proportional to the list size, making room | 02:53 |
| spiv | * for additional growth. The over-allocation is mild, but is | 02:53 |
| spiv | * enough to give linear-time amortized behavior over a long | 02:53 |
| spiv | * sequence of appends() in the presence of a poorly-performing | 02:53 |
| spiv | * system realloc(). | 02:53 |
| spiv | * The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ... | 02:53 |
| spiv | */ | 02:53 |
| spiv | (in list_resize) | 02:53 |
| lifeless | ah, linear != O(1) | 02:54 |
| lifeless | that O(n) | 02:54 |
| lifeless | O(1) is constant time | 02:55 |
| lifeless | i.e. searches in a trie are constant time if the maximum length allowed in the trie is set. | 02:55 |
| lifeless | STL vectors do amortised constant time insertion at the end, linear time insertion at beginning or middle | 02:57 |
| stub | lifeless: If you are trying optimizations, it might work if you initialized the list to some big chunk using range(0,100000) and keep track or the next insert index | 02:58 |
| spiv | That comment is actually a bit ambiguous. | 02:58 |
| lifeless | stub: I'll profile first. | 02:58 |
| lifeless | if its the list, I'll probably just throw a splay container in instead of a list. | 02:59 |
| spiv | I'm not sure if it's referreing to the sequence of appends being linear time, or the individual appends... | 02:59 |
| stub | dictionaries or sets might be useful aternatives too | 03:00 |
| lifeless | stub: it needs to be ordered, so a dictionary with the index as the first key is a solid option. | 03:00 |
| stub | spiv: I'm could have sword it was O(1) with some additional overhead when it needed to realloc | 03:01 |
| lifeless | we are talking about /big/ lists here | 03:01 |
| lifeless | its highly likely that the < double copy behaviour starts to dominate. | 03:02 |
| spiv | stub: Ditto. | 03:02 |
| lifeless | spiv: whats the current error ? | 03:03 |
| spiv | stub: I just found a post by Tim Peters asserting that it's amortised O(1), so that's good enough for me ;) | 03:04 |
| spiv | lifeless: Still no builders. | 03:04 |
| lifeless | spiv: what was that error you encountered ? (does /reload work) | 03:04 |
| spiv | Even after making reload work by fiddling with the initZopeless stuff. | 03:05 |
| lifeless | ok. what in your master.cfg - processDir or processDB ? | 03:05 |
| spiv | processDB. | 03:06 |
| lifeless | ok, run your luanchpad, goto the do not use prject, unassigned jobs. | 03:06 |
| lifeless | pick a52dec from the +sources lust | 03:07 |
| lifeless | clik on 'enable' up the top, then down the bottom choose a project - say 'ubuntu'. | 03:07 |
| lifeless | this will fail, but its what you need to do :) | 03:07 |
| lifeless | I have a patch in draft here. | 03:07 |
| lifeless | or... | 03:07 |
| lifeless | comment out the processDB and infoIMporter calls in master.cfg | 03:07 |
| lifeless | uncommment the processDir call. | 03:08 |
| === spiv does that | ||
| spiv | Ok, lots of jobs on the web page now... | 03:10 |
| spiv | Although the slave still says [Broker,client] setBuilderList [] | 03:10 |
| lifeless | now thats bizarre | 03:10 |
| lifeless | bounce the slave. | 03:10 |
| spiv | No change. | 03:13 |
| lifeless | no way. | 03:13 |
| lifeless | refresh /importd/status | 03:13 |
| spiv | It still reports them all as "offline" inthe web page.. | 03:13 |
| lifeless | offline means the slave hasn't attached. | 03:14 |
| spiv | I already have :) | 03:14 |
| lifeless | oh. | 03:14 |
| lifeless | I know. | 03:14 |
| lifeless | in jobstuff.py, there is a slave name in the builder | 03:14 |
| lifeless | change that (lifelesswks) to (spivsslavename) | 03:14 |
| spiv | Ah. | 03:14 |
| spiv | That looks likely :) | 03:15 |
| lifeless | a52decv is a nice small one | 03:15 |
| === limi [~limi@212.80-202-72.nextgentel.com] has left #launchpad [] | ||
| spiv | Oops, updated the wrong part of jobstuff.py... | 03:16 |
| spiv | Ah, "idle" :) | 03:17 |
| lifeless | great | 03:17 |
| spiv | Hmm, and error... | 03:17 |
| spiv | Error during call to `vu_chdir' for /srv/importdtest/archives/ (No such file or directory) | 03:17 |
| spiv | (from the slave...( | 03:18 |
| spiv | Ah, that's easy.. | 03:18 |
| spiv | master.cfg again. | 03:18 |
| lifeless | unchanged path in master.cfg | 03:18 |
| === spiv nods | ||
| === spiv hmms | ||
| spiv | Hmm, it expects "archives" in my slavedir, not "mirrorarhives" | 03:21 |
| lifeless | oh, there are two paths, it depends on how you set them | 03:22 |
| spiv | exceptions.AttributeError, 'WorkingTree' object has no attribute 'logger' | 03:22 |
| lifeless | ??? | 03:22 |
| lifeless | have you got the latest cscvs and buildbot patches from rocketfuel ? | 03:22 |
| spiv | Hmm, maybe not cscvs... | 03:23 |
| lifeless | heh. | 03:23 |
| lifeless | that will be it | 03:23 |
| spiv | Ok, I was missing a couple from cscvs :) | 03:23 |
| lifeless | ok, the two paths for me are: | 03:23 |
| lifeless | '/home/robertc/source/canonical/buildbot/launchpad/botslave/', '/home/robertc/source/canonical/buildbot/launchpad/botslave/mirrorarchives/', | 03:24 |
| lifeless | the first path is where it makes the archives, and gets the gpg key | 03:24 |
| lifeless | the second path is where it makes the public mirrors of the archives. | 03:24 |
| spiv | I left the paths as is, but had to mkdir "archives" in the first to make the error go away. | 03:24 |
| lifeless | the second cannot be the first + 'archives' | 03:24 |
| lifeless | yes, thats fine | 03:24 |
| spiv | Ok, it's actually doing stuff. | 03:25 |
| spiv | "creating changesets", etc :) | 03:25 |
| lifeless | great. | 03:26 |
| spiv | I presume I just need to wait, now? | 03:26 |
| lifeless | to see the slowdown I mention, in buildbot/importd/buildbot_slavecommand.py, change the debug level - its at WARNING now I think | 03:26 |
| lifeless | if you make it INFO, then run a big job... weeooo. | 03:26 |
| lifeless | in the buildbot console | 03:27 |
| lifeless | web page | 03:27 |
| lifeless | thing | 03:27 |
| lifeless | do a refresh | 03:27 |
| lifeless | on the waterfall display of that job | 03:27 |
| spiv | I'm at http://localhost:8000/importd/status/a52dec-HEAD-import.job/events/5/log | 03:27 |
| spiv | And it's still streaming... | 03:27 |
| lifeless | hit back | 03:27 |
| lifeless | then refresh | 03:27 |
| lifeless | when you get an exception there, you are ready for the next step my chjild. | 03:28 |
| spiv | Yeah, but I shouldn't get an exception until the log finishes streaming... :) | 03:28 |
| lifeless | right. | 03:28 |
| lifeless | if you want to watch the stream, go right ahead :) | 03:28 |
| spiv | Well, I'm watching the throbber ;) | 03:32 |
| lifeless | mmmm, throbber | 03:32 |
| lifeless | ok, I'm going for a shower. | 03:39 |
| lifeless | then lunch, then RMS. | 03:39 |
| lifeless | that a52dec should have finished by now tho. | 03:39 |
| spiv | Nope. | 03:42 |
| spiv | No action for quite a while... | 03:42 |
| spiv | Last output was: A libao/audio_out_null.c [1.1] | 03:42 |
| lifeless | check the slaves log | 03:43 |
| spiv | Nothing. | 03:43 |
| lifeless | if the last thing is roughly 'problem encountered', you've hit a bug | 03:43 |
| lifeless | serious? nothing in the botslave/twistd.log ? | 03:43 |
| spiv | No new lines in that log for almost 20 minutes. | 03:43 |
| spiv | 2004/10/15 03:24 CEST [Broker,client] startCommand:job [id 1 760629] | 03:43 |
| spiv | 2004/10/15 03:24 CEST [Broker,client] method 'runJob' with args [] , kwargs {'dir': '/home/andrew/warthogs/code/dists-buildbot/launchpad/trogslave/buildbot-jobs/a52dec-HEAD-import.job'} [1 760629] | 03:43 |
| lifeless | what is the last entry in there then ? | 03:44 |
| lifeless | now, you aren't using tail -f are you ? | 03:44 |
| spiv | I'm mainly using less, with the magical G key... | 03:44 |
| lifeless | try a 'tail' on its own | 03:45 |
| spiv | But that's definitely the lsat thing in that file :) | 03:45 |
| lifeless | twistd often breaks log observers I've foudn :() | 03:45 |
| lifeless | ok, well thats plain weird and sucky. | 03:45 |
| spiv | Confirmed... | 03:45 |
| lifeless | kill the slave | 03:45 |
| carlos | spiv: how could I execute a SELECT DISTINCT with a object.select(...) ? | 03:45 |
| lifeless | in cscvs/modules/CVS/__init__.py, line 372 | 03:46 |
| lifeless | change "-d%s" to "-d%s<" | 03:46 |
| spiv | carlos: you currently can't... | 03:46 |
| lifeless | then start the slave and try again. | 03:47 |
| spiv | carlos: The current workaround is to wrap a Set around it. See SQLObjectGuide's notes on DISTINCT. | 03:47 |
| carlos | ok | 03:47 |
| carlos | spiv: thanks | 03:47 |
| lifeless | also change the log level in buildbot/importd/buildbot_slavecommand.py from INFO to WARNING | 03:47 |
| lifeless | spiv: hows that looking ? | 03:52 |
| spiv | lifeless: It's doing stuff :) | 03:53 |
| spiv | N changeset MAIN.58, etc | 03:53 |
| lifeless | ok | 03:55 |
| spiv | Ooh, an exception... | 03:57 |
| spiv | File "/home/andrew/warthogs/code/dists-buildbot/launchpad/lib/cscvs/cmds/totla.py", line 508, in totla | 03:57 |
| spiv | raise ValidationFailed("cannot cross_check yet") | 03:57 |
| spiv | cscvs.cmds.totla.ValidationFailed: cannot cross_check yet | 03:57 |
| spiv | Interesting, but not mine as far as I can tell :) | 03:58 |
| lifeless | oh right | 04:01 |
| lifeless | add this: | 04:01 |
| lifeless | launchpad/lib/canonical/sourcerer/util to the pythonpath for the slave | 04:02 |
| spiv | Ok. | 04:03 |
| spiv | _sqlite.OperationalError: database is locked | 04:04 |
| lifeless | the change won't take effect until you kill off all the slave threads | 04:05 |
| lifeless | ... | 04:05 |
| spiv | I killed and restarted the slave... I have to stop and restart the botmaster too? | 04:05 |
| lifeless | no | 04:05 |
| lifeless | ps x | grep twistd | 04:06 |
| lifeless | there are old slave threads still running | 04:06 |
| lifeless | I'm shutting down now, ring me if there is other issues. | 04:06 |
| spiv | Ok. | 04:07 |
| spiv | I'll have to sleep soon anyway. | 04:07 |
| spiv | Ok, back to creating changesets... | 04:08 |
| spiv | Hmm.. | 04:08 |
| spiv | File "/home/andrew/warthogs/code/dists-buildbot/launchpad/lib/cscvs/cmds/totla.py", line 396, in enforceTargetNewOrCleanAndUpdated | 04:09 |
| spiv | assert (not target_tree.has_changes()) | 04:09 |
| spiv | exceptions.AssertionError: | 04:09 |
| spiv | lifeless: I guess you've alrady really gone? :) | 04:09 |
| carlos | stub: ping | 04:24 |
| === Signon time : Wed Oct 13 08:43:40 2004 | ||
| === Signoff time : Fri Oct 15 04:33:35 2004 | ||
| === Total uptime : 1d 19h 49m 55s | ||
| === warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad | ||
| === Topic for #launchpad: lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily" | ||
| === Topic (#launchpad): set by daf at Tue Oct 12 23:03:04 2004 | ||
| ddaa | lifeless: it's a pita to see you and spiv struggling with buildbot, while it would have been a simple matter of running make with my botmaster tree. | 10:14 |
| ddaa | lifeless: I still do not understand why you object to having an official testing botmaster tree, that would save everyone time and frustration. | 10:15 |
| ddaa | lifeless: also, please do not say "no" in the middle of some unrelated discussion to answer something I said 12 hours ago. I know that bob2 wrote taxi.py, I have no idea what you were answering to. | 10:16 |
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad | ||
| Kinnison | sabdfl: Classes for database tables should be CamelCase or just Initialcapital ? | 11:13 |
| sabdfl | CamelCase | 11:14 |
| === Kinnison nods and corrects daniel's overzealous decamelling :-) | ||
| Kinnison | I guess he got the wrong end of the stick wrt Sourcepackage | 11:16 |
| Kinnison | and didn't notice us agree to SourcePackage | 11:16 |
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| Kinnison | >>> PackagePublishing.get(9).distroarchrelease.distrorelease.name | 12:11 |
| Kinnison | u'warty' | 12:11 |
| Kinnison | I'm finally getting the hang of this SQLObject stuff | 12:11 |
| Kinnison | Anyone here an sqlobject guru who can tell me why: PackagePublishing.selectBy(distroarchrelease=1) gives me: KeyError: 'distroarchrelease' given that I have: ForeignKey(name='distroarchrelease', foreignKey='DistroArchRelease', dbName='distroarchrelease'), | 12:15 |
| Kinnison | ? | 12:15 |
| stub | Because in that syntax, distroarchrelease should be a DistroArchRelease object, not an int. You want selectBy(distroarchreleaseID=1) I think | 12:23 |
| Kinnison | PackagePublishing.selectBy(distroarchrelease=DistroArchRelease.get(1)) | 12:23 |
| Kinnison | gives me the same error | 12:23 |
| stub | and you might want to do selectBy(PackagePublishing.q.distroarchrelease == 1) | 12:24 |
| Kinnison | >>> PackagePublishing.selectBy(PackagePublishing.q.distroarchrelease=1) | 12:26 |
| Kinnison | SyntaxError: keyword can't be an expression | 12:26 |
| stub | ==, not = | 12:26 |
| Kinnison | that gives a different traceback but still a KeyError | 12:26 |
| stub | Check the definition of PackagePublishing - make sure it has that column defined and the case is correct | 12:29 |
| stub | I don't know the technical difference between select and selectBy - I've only used the former | 12:30 |
| Kinnison | ForeignKey(name='distroarchrelease', foreignKey='DistroArchRelease', dbName='distroarchrelease'), | 12:31 |
| Kinnison | that's what's in PackagePublishing._columns | 12:31 |
| Kinnison | aha | 12:33 |
| Kinnison | I am supposed to selectBy(distroarchreleaseID=DistroArchReleaseInstance) | 12:33 |
| stub | eh? hmm | 12:33 |
| Kinnison | oh, maybe not | 12:34 |
| === Kinnison gets different errors for that | ||
| stub | That might work because DistroArchReleaseInstance is castable to an int | 12:34 |
| Kinnison | oh no; that gives me: | 12:35 |
| Kinnison | ValueError: Unknown SQL builtin type: <class 'canonical.launchpad.database.distro.DistroArchRelease'> for <DistroArchRelease at 0x40e189cc> | 12:35 |
| Kinnison | right; so PackagePublishing.selectBy(distroarchreleaseID=1) | 12:36 |
| Kinnison | works | 12:36 |
| Kinnison | >>> PackagePublishing.selectBy(distroarchreleaseID=1)[0] .section.name | 12:37 |
| Kinnison | u'universe/games' | 12:37 |
| Kinnison | so we're getting somewhere | 12:38 |
| sabdfl | Kinnison: isn't universe the component? | 12:38 |
| Kinnison | >>> PackagePublishing.selectBy(distroarchreleaseID=1)[0] .component.name | 12:39 |
| Kinnison | u'universe' | 12:39 |
| Kinnison | I imagine that's a gina-needs-teaching issue | 12:39 |
| Kinnison | although it's probably come straight out of katie; so I guess it should stay | 12:39 |
| === Kinnison hugs sabdfl for harness.py | ||
| Kinnison | it's *so* useful | 12:40 |
| === SteveA|way is now known as SteveA | ||
| Kinnison | Hey SteveA, aren't we meant to have had a meeting by now? | 12:45 |
| Kinnison | Oh no, my ability to count is broken | 12:45 |
| === Kinnison blames late nights and python | ||
| lifeless | spiv: back | 12:50 |
| === BradB|away is now known as BradB | ||
| Kinnison | Hey brad | 12:55 |
| BradB | hi | 12:56 |
| SteveA | Launchpad meeting in 30 seconds! | 12:59 |
| Kinnison | SteveA: you said 12:00 UTC | 01:00 |
| SteveA | oh, right.. | 01:00 |
| SteveA | darn timezones | 01:00 |
| Kinnison | dsilvers@petitemort:~$ TZ=:UTC date | 01:00 |
| Kinnison | Fri Oct 15 11:00:21 UTC 2004 | 01:00 |
| SteveA | it's 11:00 UTC isn't it? | 01:00 |
| BradB | hien!? | 01:00 |
| BradB | i thought 12 UTC was now | 01:00 |
| SteveA | nah | 01:00 |
| SteveA | `date -u` | 01:01 |
| BradB | wow, i guess the time just changed | 01:01 |
| Kinnison | SteveA: where do we have meetings? | 01:01 |
| SteveA | here | 01:01 |
| Kinnison | right | 01:01 |
| SteveA | right here | 01:01 |
| === BradB goes back to sleep for an hour | ||
| === BradB is now known as BradB|away | ||
| Kinnison | sabdfl: I'm going to put SourcePackageReleaseFile and BinaryPackageFile into publishing.py unless you'd rather they went into library.py or somewhere else entirely | 01:02 |
| sabdfl | Kinnison: no, please either packages.py or library.py | 01:06 |
| === Kinnison thinks packages.py then | ||
| sabdfl | what about files.py? | 01:06 |
| === limi [~limi@212.80-202-72.nextgentel.com] has joined #launchpad | ||
| Kinnison | I suppose I could do a files.py with them | 01:07 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| Kinnison | hey cprov | 01:13 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 01:15 |
| === warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad | ||
| === Topic for #launchpad: lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily" | ||
| === Topic (#launchpad): set by daf at Tue Oct 12 23:03:04 2004 | ||
| (stub/#launchpad) Yup | 01:42 | |
| (stub/#launchpad) Trivial rename since nobody is importing it anymore | 01:42 | |
| SteveA | it is all using names? | 01:42 |
| stub | Yup. Might as well actually use some of the infrastructure Z3 gives us ;) | 01:43 |
| SteveA | ok. so, my next question is, are vocabularies sufficiently different from database/domain objects to be put in one place on their own? | 01:43 |
| stub | Nope, although a number of them inherit common behaviour from a base class | 01:45 |
| SteveA | we have some different kinds of thing that we're considering as sufficiently different to be in their own distinct places in the source tree: interfaces of database objects, database object implementations, page templates, zcml glue | 01:45 |
| SteveA | what we don't yet have a good place for is the adapters and other code that does not fall into those categories | 01:46 |
| SteveA | this code is currently in canonical/rosetta, canonical/malone etc. | 01:47 |
| sabdfl | SteveA: i originally tried a vocabulary package with an __init__.py that imports the separate files | 01:48 |
| sabdfl | but importing one of the subsidiary files was always resulting in an execution of __ini__.py | 01:48 |
| sabdfl | which gave me big circular import headaches | 01:48 |
| SteveA | yes, it will do. | 01:48 |
| sabdfl | that's why I structured it this way | 01:49 |
| === thom [~thom@amnesiac.heapspace.net] has joined #launchpad | ||
| sabdfl | happy for you to do it differently | 01:49 |
| SteveA | I'll look into it. | 01:49 |
| thom | hi | 01:49 |
| sabdfl | SteveA: adapters that MAY have functional use outside of a single app should be with their classes or in a dedicated place | 01:49 |
| sabdfl | stuff like RosettaApplication belongs in rosetta | 01:50 |
| SteveA | what do you mean by "with their classes" ? | 01:50 |
| thom | SteveA: basic problem with the site is that it uses absolute urls everywhere, so having multiple vhosts pointing at the same plone "site" doesn't work right. | 01:51 |
| thom | is that fixable with a virtualhostmonster? | 01:51 |
| SteveA | thom: can you give me some context please? | 01:51 |
| SteveA | ubuntulinux.org ? | 01:51 |
| thom | yes | 01:51 |
| sabdfl | SteveA: some context | 01:52 |
| thom | sabdfl wishes to use an uncached version of the site for editing | 01:52 |
| SteveA | what does the rewrite rule look like? | 01:52 |
| sabdfl | we are having problems with the cacheing of pages by the procy server | 01:52 |
| thom | (sorry, i assumed you knew context) | 01:52 |
| sabdfl | for people who log in | 01:52 |
| SteveA | thom: I was just discussing code layout in launchpad | 01:52 |
| sabdfl | when i log into the web site, it often just starts sending me cached "not logged in pages" | 01:52 |
| stub | SteveA: I suspect adapters can live along side the class they are instantiating (as they only need the interface of the source class, but need to know about the implementation of the destination class) | 01:52 |
| sabdfl | or worse, i'll be editing a page, several times, and it sends me edit pages of previous revisions | 01:53 |
| thom | SteveA: ProxyPass / http://gentoo.warthogs.hbd.com:8002/VirtualHostBase/https/www.ubuntulinux.org:443/ubuntu/VirtualHostRoot/ | 01:53 |
| sabdfl | stub: that, or in a dedicated "adapters" section, in files named by interface or class | 01:53 |
| thom | SteveA: should that just change to be site-edit.ubuntu... ? | 01:53 |
| === BradB|away is now known as BradB | ||
| thom | SteveA: (does that even work like that?) | 01:53 |
| sabdfl | SteveA: so we created https://site-edit. which is supposed to be https-only, uncached | 01:54 |
| sabdfl | it lets me see the site that way | 01:54 |
| sabdfl | but when i go to log in i'm switched to https://www. | 01:54 |
| Kinnison | stub: I've just committed a merge to add another sql patch | 01:54 |
| sabdfl | and the login may or may not succeed (!) | 01:54 |
| Kinnison | stub: can you look at it once pqm has weaved its magic? | 01:54 |
| stub | Sure. | 01:54 |
| sabdfl | and either way i'm logged in to www not site-edit | 01:54 |
| sabdfl | so we basically cannot edit the site | 01:55 |
| sabdfl | and finally, when we do manage to edit a page, by luck | 01:55 |
| sabdfl | it doesn't send any updated header so apache doesn't know about it for an hour or two | 01:55 |
| sabdfl | and one last thing | 01:55 |
| sabdfl | sometimes it caches the page of a logged in user, so someone random sees a page showing them as "logged in as jane silber" | 01:56 |
| sabdfl | or me | 01:56 |
| Kinnison | When logged in for editing; I guess the app should send no-cache headers or something? | 01:56 |
| SteveA | apache needs to be configured not to cache pages that were authenticated. So, plone should be configured to send "don't cache" headers when someone is logged in. | 01:57 |
| SteveA | I don't know how to make plone do that, as I really don't know very much about plone. | 01:57 |
| SteveA | BradB knows a lot about plone. | 01:57 |
| thom | plone sends no-cache *ALL THE TIME* | 01:57 |
| thom | so apache has to be told to ignore them | 01:57 |
| SteveA | ok. then the issue is the plone should send proper "cache" headers | 01:58 |
| thom | SteveA: agreed | 01:58 |
| SteveA | and apache shoud not ignore no-cache | 01:58 |
| stub | Or we just use wget to mirror the plone site and use that as the public face... | 01:58 |
| thom | but in the near term, can i just change the proxy, and will zope's virtual hosting cope with that | 01:58 |
| SteveA | the point of the VirtualHostBase stuff in the URL is to tell Zope what protocol/host/port it should pretend to be for this request | 02:00 |
| SteveA | that's why you don't need ProxyPassReverse with Zope when you're using this | 02:00 |
| thom | SteveA: ok, so if i tell it to be site-edit.ubuntulinux.org it should DTRT? | 02:00 |
| SteveA | as Zope knows how to produce the appropriate Location: headers when necessary | 02:00 |
| === Kinnison runs to the loo before the meeting starts | ||
| SteveA | DTRT? | 02:01 |
| thom | do the right thing | 02:01 |
| SteveA | Do theright thing | 02:01 |
| SteveA | yes, that should work fine | 02:01 |
| thom | right, will try | 02:01 |
| SteveA | you can have one zope site serving to multiple domains | 02:01 |
| debonzi | hi Kinnison, yesterday night I've changed some SQLObject name from CamelCase to no-CamelCase (liki ProcessorFamily to Processorfamily) because I remember we had agreed with it but I saw now you have reverted this changes? why? Im wrong? | 02:01 |
| SteveA | the domain it pretends to be is set per-request | 02:01 |
| SteveA | workrave is screaming at me. back for the meeting in 3-4 mins. | 02:02 |
| Kinnison | debonzi: I guess we'll cover that in this meeting. It's all a bit up-in-the-air currently | 02:02 |
| sabdfl | debonzi: it was CamelconceptCamelconcept | 02:02 |
| sabdfl | we wil switch to WordWord | 02:03 |
| debonzi | sabdfl, so it is gonna be ProcessorFamily as it was right? | 02:04 |
| sabdfl | debonzi: yes | 02:04 |
| debonzi | sabdfl, ok .. thanks | 02:04 |
| Kinnison | stub: that db patch has come through pqm now btw. | 02:05 |
| SteveA | ok, let's meet! | 02:08 |
| SteveA | all who are present, please say "aye!" (or something equivalent that you find pleasing) | 02:09 |
| Kinnison | nay! | 02:09 |
| stub | meat! | 02:09 |
| === SteveA says "aye!" | ||
| === thom [~thom@amnesiac.heapspace.net] has left #launchpad [] | ||
| BradB | mau! | 02:09 |
| BradB | (mao?) | 02:09 |
| Kinnison | BradB: latter | 02:09 |
| === SteveA hands brad a large number of cards | ||
| === Kinnison laughs | ||
| BradB | encore une fois | 02:09 |
| SteveA | daf: ??? | 02:10 |
| SteveA | debonzi, cprov? | 02:10 |
| SteveA | carlos: ? | 02:11 |
| carlos | yes | 02:11 |
| SteveA | hi carlos | 02:11 |
| carlos | hi | 02:11 |
| sabdfl | aye | 02:11 |
| SteveA | ok, malone team is all here | 02:11 |
| SteveA | so, let's start with malone, then soyuz and rosetta, and then launchpad in general | 02:11 |
| Kinnison | lucille team here too :-) | 02:12 |
| SteveA | you can be "soyuz" just for today ;-) | 02:12 |
| === Kinnison feels all special | ||
| debonzi | SteveA, | 02:12 |
| SteveA | what's new in malone? | 02:12 |
| BradB | SteveA: source package release infestations | 02:13 |
| SteveA | or, specifically, what's been achieved since the end of the sprint in london? | 02:13 |
| BradB | page tests | 02:13 |
| BradB | there's some other new things i've seen in the UI since London, but i didn't add them | 02:13 |
| BradB | (maybe they were added over the weekend | 02:13 |
| BradB | ) | 02:13 |
| SteveA | is malone doing email things yet? | 02:13 |
| sabdfl | i have some new portlets from limi to integrate | 02:13 |
| sabdfl | SteveA: no | 02:14 |
| sabdfl | do we have a simple way to send mail from launchpad? | 02:14 |
| SteveA | there's a simple way to send email from python | 02:14 |
| stub | The Z3 mail stuff is turned on - just needs to be used | 02:14 |
| SteveA | I would like launchpad to use the zope3 transactional mail stuff, because it means that mail will not be sent if a transaction is aborted | 02:15 |
| SteveA | which is nice, as it means the email will more likely represent reality | 02:15 |
| SteveA | how about we (me, someone) write a simple "mail template" system, | 02:15 |
| SteveA | that allows for text files in the source code, with standard python %(personname)s replacements | 02:16 |
| SteveA | and gets replaced, and wrapped to 78 chars (as per standard textwrap library in python) | 02:16 |
| SteveA | and mailed | 02:16 |
| SteveA | that would make sending email from the code straightforward, and we can plug in the transactional mail, or not, easily | 02:17 |
| === SteveA waits for a response | ||
| stub | Sure. I think it should assemble an email.Message since that is standard. | 02:17 |
| SteveA | yeah. allows us to plug in attachments / mime later too | 02:18 |
| Kinnison | aye | 02:18 |
| Kinnison | sounds good | 02:18 |
| SteveA | do you need attachments for malone now? | 02:18 |
| sabdfl | no | 02:18 |
| stub | The tricky bit will be something that says 'what has changed in this bug this transaction', logs the changes in the audittrail table and assembles a meaningful email to send. | 02:19 |
| sabdfl | just need to be able to send a "something changed" message | 02:19 |
| sabdfl | BradB: can we make bidirectional email integration the goal for next week? | 02:19 |
| SteveA | I was about to ask about incoming email | 02:19 |
| sabdfl | stub: your goal would be the buzilla integration | 02:19 |
| BradB | sabdfl: sure | 02:19 |
| sabdfl | great | 02:20 |
| sabdfl | i'll worry about presentation and reports | 02:20 |
| SteveA | stub: does sqlobject offer any help as to "what has changed this transaction" ? | 02:20 |
| sabdfl | i think malone should be dogfoodable shortly by the launchpad team | 02:20 |
| sabdfl | we have product and person assignment | 02:21 |
| stub | SteveA: I don't think it is part of the interface, although the necessary information is buried in there somewhere. | 02:21 |
| SteveA | stub: this could be hidden by means of an IWhatChanged adapter | 02:21 |
| BradB | there's a bit of a showstopping bug in the page test generator though, which has caused problems for moving forward with Malone | 02:21 |
| sabdfl | blech workrave | 02:21 |
| SteveA | what's that Brad? | 02:21 |
| SteveA | And, is it filed in bugzilla? | 02:22 |
| BradB | yes, it's in your inbox | 02:22 |
| sabdfl | SteveA: can we make the website authentication page available under bot www. and site-edit.? | 02:22 |
| BradB | the generated tests have a "Connection: closed" header being added, for some reason | 02:22 |
| sabdfl | and have it send appropriate cookies? | 02:22 |
| BradB | so the tests fail | 02:22 |
| === BradB digs up the Bugzilla bug | ||
| SteveA | BradB: just on macosX, or in general? | 02:23 |
| BradB | i dunno | 02:23 |
| BradB | i can only speak for os x | 02:23 |
| SteveA | sabdfl: what is the "website authentication page" ? | 02:23 |
| SteveA | BradB: mail me a reminder and I'll try to reproduce that problem here. | 02:24 |
| sabdfl | https://www.ubuntulinux.org/login_form | 02:24 |
| SteveA | sounds more like a minor inconvenience than a show-stopper though | 02:24 |
| SteveA | sabdfl: all the pages should be available on each virtual host. That page is inside plone. | 02:25 |
| BradB | SteveA: sent | 02:25 |
| sabdfl | ok | 02:25 |
| SteveA | thanks, brad | 02:25 |
| SteveA | the only functionality on ul.org that is part of launchpad is the "I forgot my password, let me get a new one" pages | 02:25 |
| SteveA | justdave isn't here. | 02:26 |
| stub | sabdfl: By 'bugzilla integration' you mean ensuring the bug watches work to bugzilla or something else? | 02:26 |
| SteveA | do we have a means to export bugs from bugzilla and into the launchpad db? | 02:26 |
| BradB | SteveA: the problems may be deeper (there seemed to be somewhat significant diffs when i ran a more complex test that visited about 4-5 different pages to demonstrate the functionality of product assignment). I'll have to look more into it today. | 02:26 |
| sabdfl | stub: the following should work: | 02:26 |
| sabdfl | create a watch | 02:26 |
| sabdfl | list watches on bug status page | 02:26 |
| SteveA | BradB: okay, keep the reports coming in. If I can reproduce it I can fix it. | 02:26 |
| sabdfl | regularly update watch status | 02:27 |
| BradB | SteveA: ok :) | 02:27 |
| sabdfl | send an email if watch status has changed in an interesting way | 02:27 |
| sabdfl | remove a watch | 02:27 |
| sabdfl | i thnk that's enough to get going with | 02:27 |
| sabdfl | most of the plumbing's there | 02:27 |
| stub | sabdfl: Ok. As far as I'm aware all that should be working except the email, so just plumbing like you said. | 02:27 |
| sabdfl | we can now create bug trackers, and associate them with projects | 02:28 |
| sabdfl | so in theory, justdave can now get going | 02:28 |
| sabdfl | we need to start populating the production database | 02:28 |
| sabdfl | with projects and products and packages | 02:28 |
| sabdfl | nicole is coming along nicely | 02:28 |
| BradB | if my day goes well today, among the things i hope to accomplish are that everything that is currently supposed to be working in malone (i.e. there's already implementation there) will be a. working and b. tested -- one won't be able to commit code that breaks any part of malone that we know to be working already. | 02:29 |
| SteveA | who is nicole, and why is she not in the https://wiki.canonical.com/ProjectGlossary ? | 02:29 |
| stub | For those of us not at the Soyuz sprint, can someone explain he scope of Nicole? | 02:29 |
| BradB | are we done with malone then? | 02:29 |
| stub | (And Lucille is pretty sketchy too on the Wiki) | 02:30 |
| SteveA | Almost -- I want to take some notes on what is happening during next week with malone | 02:30 |
| cprov | sabdfl: have you seen the comments on #2088 for "new strategy and Merge Products" | 02:30 |
| Kinnison | stub: that's partly my fault (Lucille being sketchy) | 02:30 |
| SteveA | And what the target dates for deploying malone are | 02:30 |
| BradB | SteveA: first, we should have a refactoring freeze on malone | 02:30 |
| cprov | SteveA: my fault, I will add description to Gina and Nicole on Wiki | 02:30 |
| SteveA | I'll note that refactoring is different than simply moving code around in the source tree | 02:31 |
| SteveA | BradB: what in particular do you want to be frozen? | 02:32 |
| BradB | SteveA: they're often the same thing though; they have been lately | 02:32 |
| BradB | SteveA: moving things around :) | 02:32 |
| SteveA | I don't see how moving a thing should cause a problem provided we have tests that continue to pass. | 02:32 |
| BradB | if my page tests already worked, i wouldn't worry really. until they do though, it's costing too much time. | 02:33 |
| sabdfl | stub: nicole is a screenscraper for freshmeat and sourceforge | 02:33 |
| SteveA | I'm concerned that if we can't move things into the right place, they'll remain in the wrong place, for a long time. | 02:33 |
| sabdfl | and possibly savannah | 02:33 |
| sabdfl | it runs through the list of packages and tries to find matching projects and products | 02:33 |
| BradB | SteveA: the "right place" usually means the "right place at the moment". i think it's a bad idea to do anymore of that until malone has users. | 02:33 |
| SteveA | BradB: what do you mean by "if my page tests already worked" ? Do you mean that existing page tests do not work, or do you mean that you have insufficient tests? | 02:33 |
| sabdfl | cprov: rather than creating empty projects and products I'd rather have a report of "doap-less" source packages | 02:34 |
| sabdfl | that way we know which ones need projects and products still | 02:34 |
| BradB | SteveA: the tests don't cover nearly enough of the functionality, due to the bug i hit with "Connection: closed", etc. | 02:34 |
| SteveA | BradB: can you work around that bug by just editing the .txt file of the page test? | 02:35 |
| SteveA | perhaps with a global search and replace? | 02:35 |
| BradB | SteveA: that bug, yes, it's easy enough. there might be other problems though (as i hinted at above.) | 02:35 |
| BradB | i'll find out more on that when i continue working on it. | 02:35 |
| SteveA | ok | 02:35 |
| dilys | New bug 2107 for Launchpad/Soyuz: Add Gina and Nicole Descriptions on Wiki | 02:35 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2107 | 02:35 |
| SteveA | So, I suggest that the malone team co-ordinate with each other before doing refactoring, but not totally freeze it | 02:36 |
| sabdfl | stub: also need a page to link an existing bugtracker and project together | 02:36 |
| cprov | sabdfl: don't you find more usefull a way to Merge Ophan products inside existent projects | 02:36 |
| SteveA | Malone targets: when do you want to dogfood with launchpad, when start using with live data on ubuntu? | 02:36 |
| sabdfl | i don't want orphansed products that were only created because we have a sourcepackage | 02:36 |
| sabdfl | SteveA: let's set wednesday as the day to bring up malone code on the production server and begin dogfooding | 02:37 |
| sabdfl | for our team | 02:37 |
| sabdfl | for the warty team, we can set a date once we have our own experience with it | 02:37 |
| BradB | sabdfl: perhaps you could clarify what you believe to be done, out of the following (which were remaining on the todo list we made in london): | 02:37 |
| SteveA | on the production server meaning, on the server being used for the rosetta alpha? | 02:37 |
| BradB | sabdfl: * source package assignments | 02:38 |
| BradB | - allow reassignment to different sourcepackage | 02:38 |
| sabdfl | BradB: that's done, i believe | 02:38 |
| cprov | sabdfl: ok, in this case we can continue to use the nicole_notfound report, that contains all DOAP-less sourcepackage | 02:38 |
| BradB | * subscriptions: | 02:38 |
| BradB | - watch | 02:38 |
| BradB | - ignore (for when maintainer changes) | 02:38 |
| BradB | that looks like it should be working | 02:38 |
| BradB | haven't tried it yet | 02:39 |
| BradB | er, it's not quite working | 02:39 |
| sabdfl | BradB: we have a very rough thing up, but we don't have the portlet to match, nor do we of course have any email flying around as a result | 02:39 |
| BradB | yeah | 02:39 |
| sabdfl | the older portlet worked but we need a different laout | 02:39 |
| BradB | bugzillas seem to work, more or less | 02:39 |
| BradB | (not that i've really tested it, but it looks like it's done, and i seem to remember you saying you'd done some work on it) | 02:40 |
| SteveA | This may sound ironic, but how about we add a "launchpad dogfood for malone" bug in bugzilla, and make things that need to be done depend on that? | 02:40 |
| sabdfl | stub needs to go through the full loop, i think it's still very basic | 02:40 |
| SteveA | Then I can look at a nice graph of outstanding issues and tasks and bugs. | 02:40 |
| sabdfl | SteveA: good idea | 02:40 |
| BradB | sabdfl: finally, what's the status of the assigned bugs report? | 02:40 |
| sabdfl | BradB: done, i believe | 02:40 |
| Kinnison | SteveA: surely make it depend on things which need to be done? | 02:40 |
| SteveA | Kinnison: yes. | 02:40 |
| SteveA | strike that, reverse it | 02:40 |
| BradB | sabdfl, SteveA: okay, so dogfooding by wednesday seems reasonable | 02:41 |
| BradB | a production release probably a week later | 02:41 |
| sabdfl | sounds good | 02:41 |
| sabdfl | now, which server for wednesday | 02:41 |
| SteveA | is someone adding the "launchpad dogfood" bug, or shall I do it now? | 02:41 |
| sabdfl | if we use the rosetta alpha we are going to have to find a way to migrate all the bug stuff | 02:42 |
| sabdfl | from our dogfooding | 02:42 |
| sabdfl | using the emperor/macquarie has the advantage that we don't need to migrate data afterwards | 02:42 |
| sabdfl | but the disadvantage that any db changes need greater review and planning | 02:43 |
| SteveA | how hard is it to migrate the data? | 02:43 |
| SteveA | the bug tables will be empty in emperor | 02:43 |
| SteveA | the product/project info for launchpad will not be there | 02:44 |
| SteveA | the people may have different ids | 02:44 |
| stub | SteveA: There is already a 'get malone ready for dogfood' bug in bugzilla | 02:44 |
| SteveA | stub: ok, can you comment on it "target is wednesday 20 Oct 2004" ? | 02:44 |
| sabdfl | i suppose we could always leave the dogfood server up as our test server, and preserve that database of launchpad bugs | 02:45 |
| sabdfl | that solves the problem of not having private projects / products in DOAP | 02:45 |
| BradB | Malone will be giving out candy for halloween | 02:45 |
| SteveA | (oh, great, evolution's alarms are one hour late for me...) | 02:45 |
| sabdfl | so we could say that the launchpad team just continues to use this server for its dogfooding | 02:45 |
| stub | Migrating the data will be a pita unless we can guarentee product ids etc. will be identical on production, which may be problematic. | 02:45 |
| SteveA | the production server can "watch" the dogfood server | 02:45 |
| BradB | ! | 02:46 |
| sabdfl | hell no | 02:46 |
| sabdfl | the dogfood server can, however, watch our existing bugzilla :-) | 02:46 |
| === warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad | ||
| === Topic for #launchpad: lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily" | ||
| === Topic (#launchpad): set by daf at Tue Oct 12 23:03:04 2004 | ||
| === Your nick [wartylog] is owned by ~warthylog@port49.ds1-van.adsl.cybercity.dk | ||
| (Kinnison/#launchpad) I've been building the sqlobject classes for the tables which lucille needs for doing the publishing too (where they weren't already present) | 02:55 | |
| (SteveA/#launchpad) "publishing" is also a term meaning "to present an object in a web page in response to a web request" | 02:55 | |
| (Kinnison/#launchpad) SteveA: I'll be sure to note that in my glossary entry | 02:55 | |
| (SteveA/#launchpad) so I was confused initially when I saw "publisher.py" | 02:55 | |
| (SteveA/#launchpad) there's a similarly named file in lib/canonical which deals with web-publishing | 02:56 | |
| (Kinnison/#launchpad) SteveA: aah, shall I rename those to packagepublishing or something? | 02:56 | |
| (SteveA/#launchpad) nope -- it is clear I think | 02:56 | |
| (Kinnison/#launchpad) okay | 02:56 | |
| (SteveA/#launchpad) as they are in the "domain objects" kind of area | 02:56 | |
| (Kinnison/#launchpad) Cool. | 02:56 | |
| (SteveA/#launchpad) and most launchpad developers don't need to know the details of web publishing | 02:56 | |
| === Kinnison tries to recall anything else to report | ||
| (SteveA/#launchpad) cprov, debonzi: what have you been up to since the sprint? | 02:57 | |
| (Kinnison/#launchpad) I think that's it. My goal of generating a pool from the database by the end of the week may yet be met. Being ill yesterday kinda slowed me down | 02:57 | |
| (SteveA/#launchpad) what's a "pool" ? | 02:57 | |
| (debonzi/#launchpad) SteveA, Some more infrastructure work and other bugzilla bug fixes. | 02:57 | |
| (Kinnison/#launchpad) SteveA: again; I'll add it to the glossary. A 'Pool' is the directory in which the package files sit in a published archive | 02:58 | |
| (Kinnison/#launchpad) SteveA: E.g. pool/main/a/apache/apache_2_i386.deb | 02:58 | |
| (SteveA/#launchpad) ok | 02:58 | |
| (stub/#launchpad) Kinnison: There are a few feature requests regarding the librarian in Bugzilla - do you know if you have accidently addressed any of them? (Higher level API, getURL() are two) | 02:58 | |
| (Kinnison/#launchpad) SteveA: should I put these in the general glossary page; or do a Lucille/glossary ? | 02:58 | |
| (Kinnison/#launchpad) stub: I don't think I have; but I will look | 02:59 | |
| (debonzi/#launchpad) SteveA, All the stuff we had in dkiko and ikiko is placed in launchpad/database and launchpad/interfaces | 02:59 | |
| (cprov/#launchpad) SteveA: I've integrated more features on Nicole looking for add more sane project/products on doap and integrating it with sourcepackages | 02:59 | |
| (SteveA/#launchpad) Kinnison: this is a seriously important part of what we do. Perhaps put them all together on the main glossary page. | 02:59 | |
| (SteveA/#launchpad) Kinnison: whatever you think is best | 02:59 | |
| (Kinnison/#launchpad) SteveA: Okay; I shall do that | 02:59 | |
| (debonzi/#launchpad) SteveA, some duplicated SQLObjects and Interfaces was removed too | 02:59 | |
| (SteveA/#launchpad) ok, great | 03:00 | |
| (SteveA/#launchpad) can you start writing pagetests for soyuz? | 03:00 | |
| (cprov/#launchpad) who ? | 03:00 | |
| (SteveA/#launchpad) the soyuz team | 03:00 | |
| (cprov/#launchpad) SteveA: of course, do you have some advice for the begin ? | 03:01 | |
| (SteveA/#launchpad) We need to aim to get souyz used in production soon -- for the warty team to use. | 03:01 | |
| (SteveA/#launchpad) cprov: https://wiki.canonical.com/LaunchpadPageTests | 03:01 | |
| (Kinnison/#launchpad) SteveA: In summary; I think the goals for Lucille are '1. Get pool being regenerated from database; 2. Get dists tree being regenerated from database" (and yes; I'll add dists-tree to the glossary :-) | 03:02 | |
| (debonzi/#launchpad) SteveA, I would like to finish the infrastructure work moving all sql queries that we have inside the soyuz app components to it SQLObject or "Sets" ... But it is more important to write firt the pages tests, Im ok with it | 03:02 | |
| (cprov/#launchpad) SteveA: I mean beyond this <wink> | 03:02 | |
| (SteveA/#launchpad) Can we get a soyuz running on an app server, talking to the main database on emperor, protected by certificate auth in apache, by next wednesday? | 03:02 | |
| (debonzi/#launchpad) s/But it/But if it | 03:02 | |
| (sabdfl/#launchpad) (stub: we use it to help creating watches: the ddlistbox of bugtrackers has the ones for the relevant project at the top) | 03:03 | |
| (SteveA/#launchpad) debonzi: if you have some page tests, it will be more apparent if something breaks. You can write 10 pagetests in 15 minutes. | 03:03 | |
| (debonzi/#launchpad) SteveA, ok np | 03:04 | |
| (Kinnison/#launchpad) SteveA: I have some unittests for lucille. Should I be working them into the general 'make check' stuff at the top level of launchpad? | 03:04 | |
| (SteveA/#launchpad) cprov: it is more important to get page tests into the system now. We can re-do them later, with comments. Right now, we should go for coverage so we know when something has broken. | 03:04 | |
| (sabdfl/#launchpad) SteveA: agreed on page tests first | 03:05 | |
| (sabdfl/#launchpad) do we have a way to do authenticated page tests? | 03:05 | |
| (SteveA/#launchpad) Kinnison: if they are unit-tests, then no. Add them to a "tests" package in a module with the name "test_nameofmodulebeingtested.py" | 03:05 | |
| (SteveA/#launchpad) Kinnison: run them from dists/launchpad with python test.py canonical.launchpad | 03:05 | |
| (cprov/#launchpad) SteveA: ok, we will coordinate ourself to do and integrate it til monday ... is it ok for you ? | 03:05 | |
| (SteveA/#launchpad) or python test.py canonical.launchpad.lucille.tests (for example) | 03:06 | |
| (Kinnison/#launchpad) SteveA: gotcha; I'll have a play with that later | 03:06 | |
| (SteveA/#launchpad) use python test.py -u for just unit tests | 03:06 | |
| (SteveA/#launchpad) cprov: let's talk on Monday about getting things ready for the warty team to use | 03:06 | |
| (SteveA/#launchpad) does 12:00 UTC work for you? | 03:06 | |
| (cprov/#launchpad) SteveA: fine | 03:07 | |
| (debonzi/#launchpad) SteveA, yep | 03:07 | |
| (SteveA/#launchpad) great | 03:07 | |
| (SteveA/#launchpad) elmo: can you make that? | 03:07 | |
| (cprov/#launchpad) SteveA: " things ready for the warty team to use" means soyuz running on app server? | 03:07 | |
| (SteveA/#launchpad) I'll mail out an announcement of that meeting. | 03:07 | |
| (SteveA/#launchpad) yes, it does | 03:07 | |
| (SteveA/#launchpad) but, only for the warty team | 03:07 | |
| (SteveA/#launchpad) we'll use certificates to limit its use | 03:08 | |
| (cprov/#launchpad) SteveA: perfect | 03:08 | |
| (sabdfl/#launchpad) cprov: does nicole put data in the sourceforgeproject and freshmeatproject fields when she creates a product or project? | 03:08 | |
| (sabdfl/#launchpad) SteveA: we need to get more experience working with gina running to populate the soyuz tables before we start putting it into production on emperor | 03:08 | |
| (cprov/#launchpad) sabdfl: no, but it's quite simple to do | 03:08 | |
| (sabdfl/#launchpad) cprov: please do that | 03:08 | |
| (sabdfl/#launchpad) spiv: around? | 03:08 | |
| (cprov/#launchpad) sabdfl: sure | 03:08 | |
| (Kinnison/#launchpad) Indeed; I have a couple of TODOs against gina which I need to get done (E.g. getting the build table populated properly) | 03:09 | |
| (SteveA/#launchpad) sabdfl: how much more experience? when can we start supporting the warty team with soyuz? | 03:09 | |
| === Kinnison makes a note to file bugs | ||
| (SteveA/#launchpad) spiv: pingping? | 03:09 | |
| (Kinnison/#launchpad) SteveA: define "supporting the warty team with soyuz" ? | 03:10 | |
| (sabdfl/#launchpad) SteveA: depends on how complete cprov thinks gina is, and how many more changes Kinnison thinks will be needed for the db structure | 03:10 | |
| (cprov/#launchpad) sabdfl: btw, we need to arrange a way to have gina running again ( librarian integration requires some work) | 03:10 | |
| (SteveA/#launchpad) ok, let's talk about that in detail on monday | 03:10 | |
| (sabdfl/#launchpad) i'd rather we ran soyuz on the same development machine we will e using for malone, so we can demo to the other guys | 03:10 | |
| (Kinnison/#launchpad) cprov: I have a todo to make the librarian integration optional | 03:10 | |
| (sabdfl/#launchpad) ok, so let's aim to get soyuz and malone both running on the same db where gina is running | 03:11 | |
| (cprov/#launchpad) sabdfl: I lost Gina, Kinnison owns it now | 03:11 | |
| (Kinnison/#launchpad) cprov: *pout* I'm just patching her | 03:11 | |
| (sabdfl/#launchpad) ok | 03:11 | |
| (SteveA/#launchpad) so... there's no data export issue for soyuz, I guess. | 03:11 | |
| (elmo/#launchpad) SteveA: y es | 03:11 | |
| (sabdfl/#launchpad) SteveA: no | 03:11 | |
| (sabdfl/#launchpad) :-) | 03:11 | |
| (SteveA/#launchpad) because we can use the same tools to re-populate the db on emperor | 03:11 | |
| (sabdfl/#launchpad) yes | 03:11 | |
| === SteveA thinks "maybe..." | ||
| (spiv/#launchpad) sabdfl, SteveA: pong | 03:11 | |
| (sabdfl/#launchpad) but we'll lose the links between bugs and source packages | 03:12 | |
| (sabdfl/#launchpad) so as soon as we think the db is stable, we should move over to the production db | 03:12 | |
| (SteveA/#launchpad) ok | 03:12 | |
| (sabdfl/#launchpad) and that's where we'll have to do the sourcepackage / bug work for the warty team | 03:12 | |
| (sabdfl/#launchpad) spiv: please could you add the freshmeatproject and sourceforgeproject to the product/project add/edit forms? | 03:13 | |
| (sabdfl/#launchpad) should be trivial, fields are already there, format is text | 03:13 | |
| (spiv/#launchpad) sabdfl: Ok. | 03:13 | |
| (SteveA/#launchpad) ok. soyuz going somewhat live meeting on monday. we'll work out all the details of deploying on the "rosetta alpha" machine, and later onto an app server. | 03:13 | |
| (spiv/#launchpad) I'll get that done today. | 03:13 | |
| (sabdfl/#launchpad) great spiv, thanks | 03:13 | |
| (Kinnison/#launchpad) SteveA: you'll send an email about that meeting; yes? | 03:13 | |
| (SteveA/#launchpad) sabdfl: are you ready to hand over DOAP and FOAF to spiv? | 03:13 | |
| (SteveA/#launchpad) Kinnison: yes | 03:14 | |
| (sabdfl/#launchpad) i'm checking in the final piece of doap phase 1 today too | 03:14 | |
| (sabdfl/#launchpad) we now have the ability to add and edit all of the doap objects: project, product, series and release. | 03:14 | |
| (sabdfl/#launchpad) last piece is productrelease editing, its about another 20 lines of code, then testing, and page tests | 03:14 | |
| (sabdfl/#launchpad) will be done today | 03:15 | |
| (sabdfl/#launchpad) is there a doc on the wiki that describes how to do page tests? | 03:15 | |
| (Kinnison/#launchpad) https://wiki.canonical.com/LaunchpadPageTests | 03:15 | |
| (sabdfl/#launchpad) gracias | 03:15 | |
| (sabdfl/#launchpad) ok, will check it in with full tests | 03:16 | |
| (Kinnison/#launchpad) danada | 03:16 | |
| (SteveA/#launchpad) spiv, sabdfl: please announce on the launchpad list when doap and foaf have been handed over, so everyone knows who to file new bugs on, and ask stuff to | 03:17 | |
| (sabdfl/#launchpad) will do | 03:17 | |
| (SteveA/#launchpad) elmo: do we have certificate stuff sorted out? | 03:17 | |
| === cprov wonders if Kinnison has any idea about which word he's just typed ... | ||
| (Kinnison/#launchpad) cprov: not a clue :-) | 03:17 | |
| (SteveA/#launchpad) russian | 03:17 | |
| (cprov/#launchpad) Jesus ... | 03:18 | |
| (sabdfl/#launchpad) as long as it doesn;t involve nudity, i've had about as much about that as i can stomache | 03:18 | |
| (Kinnison/#launchpad) cprov: I like using foreign languages without the faintest idea what I'm saying | 03:18 | |
| (ddaa/#launchpad) cprov: that's latin! | 03:18 | |
| (sabdfl/#launchpad) thank you | 03:18 | |
| === Kinnison attempts to eat his lunch without spilling rigatoni on the keyboard | ||
| (elmo/#launchpad) SteveA: no I was waiting on an okay from you to switch over | 03:19 | |
| (elmo/#launchpad) for mawson anyway - lifeless had me push through macquarie | 03:19 | |
| (sabdfl/#launchpad) SteveA: do we have page tests for authenticated pages yes, I understood those were not working | 03:19 | |
| (SteveA/#launchpad) sabdfl: I'll look into that. | 03:19 | |
| (sabdfl/#launchpad) and many of the critical ones are authenticated | 03:20 | |
| (dilys/#launchpad) New bug 2108 for Launchpad/Malone: Need screen to add/edit ProjectBugTracker | 03:20 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2108 | 03:20 | |
| (sabdfl/#launchpad) stub: we have a screen to add one | 03:20 | |
| (SteveA/#launchpad) elmo: daf and carlos will need to make the "testers" certificate available to rosetta testers | 03:20 | |
| (sabdfl/#launchpad) we also have a screen to add one to a project, which both adds one AND adds the projectbugtracker entry | 03:21 | |
| (sabdfl/#launchpad) what we don't have is a way to associate or deassociate an existing project and bugtracker | 03:21 | |
| (stub/#launchpad) ProjectBugTracker is what does that association, isn't it? | 03:21 | |
| (SteveA/#launchpad) Have we talked enough about soyuz now? | 03:21 | |
| (sabdfl/#launchpad) yes | 03:21 | |
| (carlos/#launchpad) SteveA: talking about a SSL certificate or what? | 03:21 | |
| (SteveA/#launchpad) Let's move on to rosetta... | 03:21 | |
| (SteveA/#launchpad) carlos: yep. | 03:21 | |
| (sabdfl/#launchpad) hold on | 03:21 | |
| (carlos/#launchpad) ok | 03:21 | |
| (sabdfl/#launchpad) elmo: i think you'll need a different cert for the rosetta testers | 03:22 | |
| (sabdfl/#launchpad) then use SSLRequire accordingly | 03:22 | |
| (elmo/#launchpad) yeah | 03:22 | |
| (sabdfl/#launchpad) ok | 03:22 | |
| (SteveA/#launchpad) we have two certificates don't we? one for testers, and one for canonical ? | 03:22 | |
| (cprov/#launchpad) SteveA: yes, send the emails and revise the bugs from soyuz, please | 03:22 | |
| (SteveA/#launchpad) revise the bugs | 03:23 | |
| (SteveA/#launchpad) ? | 03:23 | |
| (elmo/#launchpad) rosetta alpha specifically, or just a "testers" cert ? | 03:23 | |
| (SteveA/#launchpad) I'd say just a testers would do | 03:23 | |
| (SteveA/#launchpad) cprov: what do you mean by "revise the bugs from soyuz" ? | 03:25 | |
| (sabdfl/#launchpad) testers would be fine | 03:25 | |
| (SteveA/#launchpad) no sniggering, elmo | 03:25 | |
| (SteveA/#launchpad) let's move on to rosetta | 03:26 | |
| (SteveA/#launchpad) daf | 03:26 | |
| (SteveA/#launchpad) daf daf daf daf daf, calling daf | 03:26 | |
| (carlos/#launchpad) SteveA: he's away in jabber... | 03:26 | |
| (SteveA/#launchpad) ok, carlos, what's been happening with rosetta over the last week? | 03:26 | |
| (cprov/#launchpad) SteveA: I need you help on some bugs ... if you have time | 03:26 | |
| (SteveA/#launchpad) cprov: sure. I need to go and meet people for lunch straight after this meeting. | 03:27 | |
| (cprov/#launchpad) s\you\your | 03:27 | |
| (carlos/#launchpad) SteveA: lots of fixes about the object merge | 03:27 | |
| (SteveA/#launchpad) but, mail me bug numbers, and I'll look through them, and we can talk here. | 03:27 | |
| (carlos/#launchpad) planned the remaining database changes | 03:27 | |
| (cprov/#launchpad) SteveA: ok, I'll do so | 03:27 | |
| (SteveA/#launchpad) have you merged the branch you were working on yet, carlos? | 03:28 | |
| (carlos/#launchpad) not yet, I need some stub review for the .sql patch | 03:28 | |
| === Kinnison gets workraved; brb | ||
| (carlos/#launchpad) and I still have some bugs | 03:28 | |
| (carlos/#launchpad) but it will be done today (if stub has time) | 03:29 | |
| (SteveA/#launchpad) there's a bunch of stuff I want to talk about with the rosetta team. let's have the rosetta portion of this meeting later, when daf is around. | 03:29 | |
| (carlos/#launchpad) ok | 03:29 | |
| (SteveA/#launchpad) carlos: is there anything about rosetta in relation to the rest of launchpad you want to bring up? | 03:29 | |
| (SteveA/#launchpad) (while the rest of launchpad is here) | 03:30 | |
| (carlos/#launchpad) well, It could be really good to know when will be imported real projects into launchpad | 03:30 | |
| (carlos/#launchpad) from arch | 03:30 | |
| (carlos/#launchpad) or if it's working now, how should it be done | 03:30 | |
| (lifeless/#launchpad) they are being imported now. | 03:30 | |
| (lifeless/#launchpad) by the arch team. | 03:30 | |
| (carlos/#launchpad) to add the .po/.pot import bits | 03:31 | |
| (carlos/#launchpad) lifeless: any place where we could read about how to setup it in our local machine? | 03:31 | |
| (lifeless/#launchpad) carlos: the ImportProcess page. but why ? | 03:32 | |
| (lifeless/#launchpad) I need to update that page, and ddaa reckons hes got a streamlined setup process - which I need to review. | 03:32 | |
| (carlos/#launchpad) because we need to add some code to fill the POFile and POTemplate tables with every import | 03:32 | |
| (lifeless/#launchpad) erm. Thats decoupled surely. | 03:33 | |
| (carlos/#launchpad) not sure if at the same time or as an external process | 03:33 | |
| (lifeless/#launchpad) the imports are in an inaccessible area., | 03:33 | |
| (SteveA/#launchpad) while carlos and lifeless chat about this, I'll declare the meeting over for the rest of us. | 03:33 | |
| (lifeless/#launchpad) and only when finished are they loaded into launchpad. | 03:33 | |
| (SteveA/#launchpad) Thanks, everyone. | 03:33 | |
| (lifeless/#launchpad) its 23:33 - I'm not really here. | 03:33 | |
| (carlos/#launchpad) lifeless: well, we could talk about it on Monday if you prefer, I could work on other tasks today | 03:34 | |
| (lifeless/#launchpad) monday for sure. | 03:34 | |
| (carlos/#launchpad) ok | 03:34 | |
| (lifeless/#launchpad) AFAIK there is no reason for anyone not testing the actual cscvs conversions to have the import environment installed. | 03:34 | |
| (lifeless/#launchpad) it was never mentioned to me as a requirement in the design or implementation. | 03:34 | |
| (lifeless/#launchpad) and I think that you would be best to do it as a separate task for several reasons. | 03:35 | |
| (carlos/#launchpad) Well, I was thinking on use arch directly not cvs | 03:35 | |
| (lifeless/#launchpad) (I'm just brain dumping now, we can talk properly monday). | 03:35 | |
| (lifeless/#launchpad) those reasons are: | 03:35 | |
| (lifeless/#launchpad) 1) you want the arch archives, not the cvs, so the cvs->arch conversion isn't directly interesting | 03:36 | |
| (lifeless/#launchpad) 2) its easier to debug single-task processes - cvs->arch->pofile as one thing would IMO get messy | 03:37 | |
| (carlos/#launchpad) lifeless: I agree | 03:37 | |
| (lifeless/#launchpad) 3) the buildbot infrastructure is written in twisted - nonblocking, event based - because it has to deal with long running (days long in some cases) conversions in parallel.. plus there was an existing framework we've reused. | 03:37 | |
| (lifeless/#launchpad) for tasks that don't need the advanced queueing and dispatching (and the potfile thing shouldn't from what I've seen of it) buildbot is not the most efficient programming environment | 03:38 | |
| (lifeless/#launchpad) 4) the buildbot jobs run against *different archives* than those that launchpad has. | 03:38 | |
| (Kinnison/#launchpad) Is there an antonym for 'to publish' ? | 03:38 | |
| (spiv/#launchpad) Kinnison: "censor" ;) | 03:39 | |
| (SteveA/#launchpad) to retract? | 03:39 | |
| (SteveA/#launchpad) redact? | 03:39 | |
| (carlos/#launchpad) lifeless: I suppose that all arch archives that you are importing are the ones at arch.ubuntu.com, right? | 03:39 | |
| (lifeless/#launchpad) those archives are a 'scratch area', which we rollback on errors and so forth. Your potfile importer needs to run against the *official* archives, which the buildbot jobs create. | 03:39 | |
| (SteveA/#launchpad) to subscribe? (not really antonym) | 03:39 | |
| (carlos/#launchpad) lifeless: where are they located? | 03:39 | |
| (lifeless/#launchpad) the official archives are a) in launchpad (use canonical.arch to get their details) and b) accessible to tla via arch.ubunto.com | 03:39 | |
| (lifeless/#launchpad) *ubuntu* | 03:40 | |
| === SteveA -> lunch | ||
| === Kinnison decides to use 'unpublish' :-) | ||
| (carlos/#launchpad) ok | 03:40 | |
| (lifeless/#launchpad) thats my brain dump. | 03:40 | |
| (carlos/#launchpad) lifeless: thanks | 03:40 | |
| (lifeless/#launchpad) On monday, if we can talk about your requirements - frequency, required data etc - we can talk about how best to do it. | 03:41 | |
| (lifeless/#launchpad) SteveA will probably need to be there to advise what zope machinery can help, so I don't get out the twisted hammer if its not needed | 03:41 | |
| (carlos/#launchpad) lifeless: I will talk about it with daf so we have the requirements clear | 03:42 | |
| (lifeless/#launchpad) great | 03:42 | |
| === Kinnison goes off to do some chores etc. If you need me; ring | ||
| (lifeless/#launchpad) Kinnison: we need you! | 03:42 | |
| (lifeless/#launchpad) just teasing. | 03:42 | |
| (lifeless/#launchpad) night all. | 03:42 | |
| (carlos/#launchpad) I think I will leave also to have lunch | 03:42 | |
| (carlos/#launchpad) lifeless: night | 03:42 | |
| (spiv/#launchpad) lifeless: G'night. | 03:42 | |
| (lifeless/#launchpad) spiv: oh you are here | 03:43 | |
| (lifeless/#launchpad) did you get success ? | 03:43 | |
| (spiv/#launchpad) lifeless: Not yet. | 03:43 | |
| === lifeless defers sleep | ||
| (lifeless/#launchpad) do you need input from me ? | 03:43 | |
| (spiv/#launchpad) It'd speed things up. | 03:43 | |
| (ddaa/#launchpad) lifeless, while you are around... | 03:43 | |
| (spiv/#launchpad) But I don't mind if you'd ratehr sleep :) | 03:43 | |
| (lifeless/#launchpad) spiv: I mind. | 03:44 | |
| (lifeless/#launchpad) :) | 03:44 | |
| (lifeless/#launchpad) ddaa: shoot | 03:44 | |
| (ddaa/#launchpad) I put my buildbot in some broken state yesterday, which is described in my last activity report. | 03:44 | |
| (spiv/#launchpad) lifeless: so, current traceback from slave: | 03:44 | |
| (spiv/#launchpad) File "/home/andrew/warthogs/code/dists-buildbot/launchpad/lib/cscvs/cmds/totla.py", line 396, in enforceTargetNewOrCleanAndUpdated | 03:44 | |
| (spiv/#launchpad) assert (not target_tree.has_changes()) | 03:44 | |
| (spiv/#launchpad) exceptions.AssertionError: | 03:44 | |
| (spiv/#launchpad) [from calling self.runtotla(self.sourceDir(), "-SCc", "%s.1::" % aJob.sourceBranch(), tlapath, logger)] | 03:45 | |
| (ddaa/#launchpad) Basically, after starting the bots, clean without tap and jobs in the slave dir, it still show the job as running,,, | 03:45 | |
| (ddaa/#launchpad) spiv: you need to disable the revlib. | 03:45 | |
| (lifeless/#launchpad) spiv: nuke the subtree a52dev@arch.ubuntu.com from your revlibrary. | 03:45 | |
| (lifeless/#launchpad) its a todo on my sticky notes for the nuke logic to detect that. | 03:45 | |
| (spiv/#launchpad) lifeless: Ah :) | 03:46 | |
| (lifeless/#launchpad) ddaa: mail me such things directly. | 03:46 | |
| (ddaa/#launchpad) spiv: you might want to look at the sandboxing magic in david.allouche@canonical.com--2004/configs--buildbot-macquarie--0 | 03:46 | |
| (lifeless/#launchpad) activity reports are not a good way to get me to be alerted/address things. | 03:46 | |
| (ddaa/#launchpad) lifeless: okay will do in the future. Just did not have the time for that yesterday. | 03:47 | |
| (lifeless/#launchpad) so what is the wedged state ? | 03:47 | |
| (ddaa/#launchpad) I spent waaaay too much time making redundant fixes on buildbot and cscvs :-( | 03:47 | |
| (lifeless/#launchpad) lol. | 03:47 | |
| === ddaa does the test again | ||
| (lifeless/#launchpad) shoulda looked in rocketfuel first :) | 03:47 | |
| (ddaa/#launchpad) First time I have such a race... | 03:48 | |
| (lifeless/#launchpad) I haven't pulled any of your code in yet. | 03:48 | |
| (sabdfl/#launchpad) ddaa: we've really improved the code layout, you should be able to figure out what code exists much more easily now | 03:48 | |
| (lifeless/#launchpad) there is a cscvs bugfix though, let me push it | 03:48 | |
| (sabdfl/#launchpad) those were in place when you started work | 03:48 | |
| (sabdfl/#launchpad) lifeless: please can you take a look at the layout of lib/canonical/launchpad | 03:49 | |
| (sabdfl/#launchpad) and organise your team to bring it's code into line | 03:49 | |
| (ddaa/#launchpad) sabdfl: thanks but that was a time-race... a good half of my work conflict with changes lifeless made on the exact same lines to fix the exact same thing. | 03:49 | |
| (sabdfl/#launchpad) check out ZCMLStyleGuide on the wiki and other relevant pages | 03:49 | |
| (sabdfl/#launchpad) ok | 03:49 | |
| (sabdfl/#launchpad) yeah, it happens when everyone sees the same bugs :-) | 03:49 | |
| (sabdfl/#launchpad) in the same order :-) | 03:50 | |
| (lifeless/#launchpad) sabdfl: we're not writing any launchpad code at the moment, but certainly, we'll follow suite. | 03:50 | |
| (sabdfl/#launchpad) lifeless: you have a ton of classes that still need to be organised | 03:50 | |
| (lifeless/#launchpad) sabdfl: agreed. | 03:50 | |
| (sabdfl/#launchpad) they are currently in lib/canonical/launchpad/i*.py and d*.py | 03:50 | |
| (lifeless/#launchpad) what does the i and d stand for ? | 03:50 | |
| (sabdfl/#launchpad) please put them into database/tablename.py and interfaces/tablename.py | 03:50 | |
| (sabdfl/#launchpad) interfaces and database | 03:51 | |
| (lifeless/#launchpad) ok | 03:51 | |
| (lifeless/#launchpad) is this on the wiki somewhere? the actual conventions ? | 03:51 | |
| (sabdfl/#launchpad) please don't just create a monolithic "arch.py" but get some sane granularity | 03:51 | |
| (sabdfl/#launchpad) default to tablename.py unless there's a good reason to bring classes into the same file | 03:51 | |
| (sabdfl/#launchpad) then the rest of us will know where to look for your tables and where to extend them | 03:51 | |
| (ddaa/#launchpad) lifeless: make stop; rm -rf buildbot.tap slave/* ; make start | 03:51 | |
| (lifeless/#launchpad) sabdfl: sure. We were following the older style guide at the time. | 03:51 | |
| (lifeless/#launchpad) (thats an excuse, yes it is) :) | 03:52 | |
| (sabdfl/#launchpad) if you have any relevant zcml, and view classes, they go in zcml/ and browser/ respectively | 03:52 | |
| (ddaa/#launchpad) lifeless: then zenity still appears building in the summary page... | 03:52 | |
| (sabdfl/#launchpad) lifeless: a fair one, but now the policy is in place, and working, we need to get everything into line | 03:52 | |
| (lifeless/#launchpad) sabdfl: can we do this as we change things? or do we need to divert time just to that ? | 03:53 | |
| (lifeless/#launchpad) ddaa: could be a dropped stop message. | 03:54 | |
| (lifeless/#launchpad) I've seen a couple of those recently, haven't tracked down the cause yet. | 03:54 | |
| (ddaa/#launchpad) prolly, I had to kill -9 the slave more than once... | 03:54 | |
| (lifeless/#launchpad) bounce the master | 03:54 | |
| (sabdfl/#launchpad) lifeless: it's pretty quick | 03:54 | |
| (sabdfl/#launchpad) debonzi just whack the soyuz classes in a day | 03:54 | |
| (ddaa/#launchpad) lifeless: "bounce the master"? | 03:55 | |
| (lifeless/#launchpad) sabdfl: it still means switching from the production code base to devel, doing it, testing, then going back to the production to do imports | 03:55 | |
| === ddaa also tried purging the slave_home to no effect | ||
| (sabdfl/#launchpad) are you doing a lot of coding on the production branch? | 03:55 | |
| === ddaa just remembered he should not have done that... | ||
| (lifeless/#launchpad) all the bugfixes I do are done against production on my disk, then integrated to devel, commited there and merged to production so that I can then run said import. | 03:56 | |
| (ddaa/#launchpad) lifeless: I'm using production | 03:56 | |
| (ddaa/#launchpad) ooops | 03:56 | |
| (ddaa/#launchpad) I'm using devel | 03:56 | |
| (lifeless/#launchpad) ddaa: 'bounce the master' - stop the botmaster, then start it again. | 03:56 | |
| (lifeless/#launchpad) ddaa: you aren't testinging the launchpad side of it, so that shouldn't be a worry. | 03:57 | |
| (ddaa/#launchpad) lifeless: that's done by "make stop" (terminate master and slave) and make start (start both) | 03:57 | |
| (lifeless/#launchpad) ddaa: then your make stop isn't stopping it | 03:57 | |
| (ddaa/#launchpad) Yes it is... | 03:57 | |
| (lifeless/#launchpad) stop them, check that twistd is not in your ps list, then start them. | 03:57 | |
| (lifeless/#launchpad) RMS's talk was very interesting | 03:58 | |
| (lifeless/#launchpad) sabdfl: have you heard of ututo | 03:58 | |
| (lifeless/#launchpad) argentinian linux distribution, free software only, nothing proprietry at all - RMS is recommending them (where he says he cannot recomment debian) | 03:58 | |
| === kiko [~kiko@200-181-087-079.bsace705.dsl.brasiltelecom.net.br] has joined #launchpad | ||
| (ddaa/#launchpad) grmbl... | 03:59 | |
| (ddaa/#launchpad) apparently that was a rogue twistd... | 03:59 | |
| kiko | morning | 04:00 |
| (ddaa/#launchpad) okay... now I have that stupid failure when the slave tries to create a mirror that already exists because I had purged its .arch-params... | 04:01 | |
| (lifeless/#launchpad) 'dont do that' | 04:01 | |
| (ddaa/#launchpad) lifeless: too late | 04:01 | |
| (lifeless/#launchpad) the jobs clean out what needs to be cleaned out. | 04:01 | |
| (lifeless/#launchpad) if you have to manually do something - its a bug. | 04:02 | |
| (ddaa/#launchpad) would it make sense to check for existence of the mirror in the mirror_dir before trying to create it? | 04:02 | |
| (spiv/#launchpad) lifeless: hmm, this slave job isn't showing much signs ofvisible progres... | 04:02 | |
| (ddaa/#launchpad) also, I'd love to fix the summary listing problem, but "it's not on the critical path". | 04:02 | |
| (lifeless/#launchpad) ddaa: not really, we couldn't trust it. | 04:03 | |
| (spiv/#launchpad) lifeless: last log message is still Repository base not available -- catalog created with an older cscvs? Rebuilding | 04:03 | |
| (lifeless/#launchpad) ddaa: this runs in a very controlled environment. | 04:03 | |
| (lifeless/#launchpad) spiv: - top ? | 04:03 | |
| === ddaa thrashes everything, database, mirrors etc and starts zenity again from scratch. | ||
| (spiv/#launchpad) lifeless: No cpu load to speak of. | 04:04 | |
| (lifeless/#launchpad) slave twistd.log ? | 04:04 | |
| (spiv/#launchpad) Also quiet. | 04:04 | |
| (ddaa/#launchpad) spiv check the running log from the waterfall page | 04:04 | |
| (lifeless/#launchpad) thats mucho bizarro | 04:04 | |
| (ddaa/#launchpad) it's generally more verbose | 04:05 | |
| (spiv/#launchpad) ddaa: That's the log I was quoting. | 04:05 | |
| (jblack/#launchpad) Good morning. | 04:05 | |
| === ddaa raises eyebrow and then shoulders... | ||
| (lifeless/#launchpad) spiv, kill the slave's thread | 04:05 | |
| (lifeless/#launchpad) not the slave itself. | 04:06 | |
| (spiv/#launchpad) lifeless: Hmm.. | 04:06 | |
| kiko | muy bizarro | 04:06 |
| kiko | mucho is for countables | 04:06 |
| (ddaa/#launchpad) hey jblack | 04:06 | |
| (lifeless/#launchpad) kiko: thanks! | 04:06 | |
| (spiv/#launchpad) lifeless: How do I determine which thread that is? | 04:06 | |
| kiko | heh | 04:06 |
| (lifeless/#launchpad) twistd.pid is the slave and the master | 04:07 | |
| (spiv/#launchpad) ps afxw only lists one process for that... | 04:07 | |
| kiko | actually, not for countables, but it's muy bizarro anyway. | 04:07 |
| (lifeless/#launchpad) != twistd.pid is the child. | 04:07 | |
| (lifeless/#launchpad) unless you have NPTL instlaled, | 04:07 | |
| (lifeless/#launchpad) in which case. hahahhaa. | 04:07 | |
| (spiv/#launchpad) Ah. | 04:07 | |
| (spiv/#launchpad) Well, SIGTERM didn't make any difference... SIGKILL, I guess? | 04:08 | |
| (lifeless/#launchpad) yeah | 04:08 | |
| (spiv/#launchpad) Blam! :) | 04:08 | |
| (lifeless/#launchpad) there is an occasional 'death' that occurs, that I have to track down. | 04:08 | |
| (spiv/#launchpad) And away we go... | 04:08 | |
| (lifeless/#launchpad) ddaa: I'd like to get some of your sandboxing stuff more generally available. | 04:10 | |
| (spiv/#launchpad) _sqlite.DatabaseError, database disk image is malformed | 04:10 | |
| (spiv/#launchpad) Hmm. | 04:10 | |
| (spiv/#launchpad) What do I need to clean to fix that? :) | 04:10 | |
| (ddaa/#launchpad) lifeless: it's on my canonical archive | 04:10 | |
| (lifeless/#launchpad) I should clarify - I'm not 'against an easy setup environment' - I'm 'pro you focusing on the tasks at hand' | 04:10 | |
| (ddaa/#launchpad) lifeless: I'm all in favor of that. | 04:11 | |
| (ddaa/#launchpad) Having an easy test environment is part of it. | 04:11 | |
| (ddaa/#launchpad) spiv: remove the *-job directories in botslave directory | 04:15 | |
| (lifeless/#launchpad) spiv: thats good, it tells me where the problem might be | 04:15 | |
| (lifeless/#launchpad) just remove the cvsworking directory in that buildbot-jobs/jobname... tree | 04:15 | |
| (lifeless/#launchpad) (find -name 'cvsworking' | xargs rm -rf ) | 04:15 | |
| (ddaa/#launchpad) the sqlite db gets corrupt very easily, but it seems that fixing that is not really part of the task at hand. | 04:15 | |
| (spiv/#launchpad) Ok. | 04:15 | |
| (lifeless/#launchpad) ddaa: I've only seen 2 corruptions ever for me, 1 on chinstrap, one on my disk. | 04:16 | |
| (jblack/#launchpad) ddaa: sqlite bad? | 04:16 | |
| (spiv/#launchpad) Well, when I'm SIGKILLing things... :) | 04:16 | |
| (lifeless/#launchpad) ddaa: but if you are kill -9'ing stuff, you can (of course) cause problems. | 04:16 | |
| (ddaa/#launchpad) lifeless: I have already seen two corruptions in the last couple of days | 04:16 | |
| (lifeless/#launchpad) are you kill -9ing ? | 04:16 | |
| (ddaa/#launchpad) lifeless: I did it yesterday, because I did not manage to kill the non-daemon slave in any other way. | 04:17 | |
| (ddaa/#launchpad) It's reacts well to sigterm in daemon mode though. | 04:17 | |
| (lifeless/#launchpad) ddaa: you'll want the cscvs rlog bugfix I've just merged | 04:18 | |
| (ddaa/#launchpad) lifeless: okay. Will merge once the zenity import run is complete | 04:19 | |
| (ddaa/#launchpad) (well once it blows on taxi.py...) | 04:19 | |
| (lifeless/#launchpad) if it fails with a 'missing branch not caught by branches: statement', then its the bug I've fixed. | 04:19 | |
| (ddaa/#launchpad) never seen that one | 04:20 | |
| (ddaa/#launchpad) Not directly related to the task at hand... | 04:21 | |
| (ddaa/#launchpad) what does the arch team think of recommanding "tag from rocketfuel" as a way to restore sanity after a cross-merge? | 04:21 | |
| (jblack/#launchpad) wont that throw away their old changes? | 04:22 | |
| (ddaa/#launchpad) Then local changes can be replayed with "replay --skip-present". Since that happens only on the local branch, that does not have the unpleasant side effects of --skip-present on rocketfuel. | 04:23 | |
| (ddaa/#launchpad) --skip present will effectively skip the merges | 04:23 | |
| (lifeless/#launchpad) ddaa: Offhand, could be useful. would like some test data. | 04:24 | |
| (lifeless/#launchpad) are we still seeing cross-merges ? | 04:24 | |
| (spiv/#launchpad) I did that recently. | 04:24 | |
| (spiv/#launchpad) lifeless: I somehow managed to cross-merge a few days ago :( | 04:24 | |
| (jblack/#launchpad) lifless yeah | 04:24 | |
| (daf/#launchpad) SteveA: my apologies, I forgot to set my alarm | 04:24 | |
| (spiv/#launchpad) But seeing as I'd just merged, I had no outstanding changes. | 04:24 | |
| (jblack/#launchpad) ddaa: Pre-coffee, that sounds like a good idea. | 04:24 | |
| (ddaa/#launchpad) spiv is the one who suggested to tag from rocketfuel, and that struck me as a good and simple solution. | 04:24 | |
| (spiv/#launchpad) Hence, tagging worked well for me. | 04:24 | |
| (spiv/#launchpad) (after checking with ddaa that it was a sane idea :) | 04:24 | |
| (ddaa/#launchpad) For some reason we did not thought about it before... | 04:25 | |
| (ddaa/#launchpad) *did not think | 04:25 | |
| (jblack/#launchpad) ddaa: The only remaining question I'd have is what that does to history. | 04:25 | |
| (sabdfl/#launchpad) SteveA: is there an rule about the use of set_schema vs set_attributes? | 04:25 | |
| (jblack/#launchpad) for example, can they still do a changes across a tag, delta, etc. | 04:25 | |
| (spiv/#launchpad) (it also effectively put a cacherev in my mirror for free ;) | 04:25 | |
| (ddaa/#launchpad) jblack: you'd have to be more specific | 04:25 | |
| (jblack/#launchpad) than my example? | 04:26 | |
| (ddaa/#launchpad) race.., | 04:26 | |
| (lifeless/#launchpad) spiv: that should have worked or failed by now | 04:27 | |
| (spiv/#launchpad) lifeless: Yeah, bombed out on ArchiveMapper -- I was just about to find your fix for that. | 04:27 | |
| (ddaa/#launchpad) yes, changes, delta etc are okay. Then only thing that's broken by tag-in-version is "replay the whole version". | 04:27 | |
| (spiv/#launchpad) (ISTR you already fixed that) | 04:27 | |
| (spiv/#launchpad) ("exceptions.NameError, global name 'ArchiveMapper' is not defined") | 04:27 | |
| (jblack/#launchpad) ddaa: What happens when replay gets to the tag? | 04:27 | |
| (lifeless/#launchpad) spiv: I don't recally fixing that | 04:27 | |
| (lifeless/#launchpad) RevisionMapper was what I fixed | 04:28 | |
| (spiv/#launchpad) Oh, ok. | 04:28 | |
| (ddaa/#launchpad) jblack: it will replay the tag changeset, which only adds a revlog. | 04:28 | |
| (spiv/#launchpad) I'll fix it myself, then :) | 04:28 | |
| (lifeless/#launchpad) is likely that ArchiveMapper is available as database.ArchiveMaper | 04:28 | |
| (lifeless/#launchpad) as thats where they all seemed to have moved. | 04:28 | |
| (jblack/#launchpad) ddaa: Ouch. So anybody that did a get on him will have to reget. | 04:28 | |
| (ddaa/#launchpad) ? | 04:28 | |
| (ddaa/#launchpad) Update or star-merge. | 04:29 | |
| (ddaa/#launchpad) It's just replay-as-update that's broken. | 04:29 | |
| (jblack/#launchpad) Lets say he he has base-0 - patch-12, but patch-10 is a retag of rf. | 04:29 | |
| (lifeless/#launchpad) are the new standards - using sqlobject directly etc etc all on the wiki somewhere ? | 04:29 | |
| (jblack/#launchpad) Somebody back at patch-8 did a tla get on him, and then replays. | 04:29 | |
| (jblack/#launchpad) From what you say, replay will break at the retag. | 04:29 | |
| (ddaa/#launchpad) Then it breaks yes. | 04:29 | |
| (lifeless/#launchpad) The arch mappers have a very important purpose - they make changes explicit actions, because arch data is read only. | 04:29 | |
| (ddaa/#launchpad) jblack: that's why people should not use replay when they mean update. | 04:30 | |
| (ddaa/#launchpad) unless they know what they are doing. | 04:30 | |
| (ddaa/#launchpad) Old news. | 04:30 | |
| (jblack/#launchpad) Is get smart enough to go back to the last tag, like it is cacherevs | 04:30 | |
| (jblack/#launchpad) replay is supposed to be a safe command afaik. I've alweays used replay. | 04:30 | |
| (spiv/#launchpad) lifeless: AFAIK there's no policy that addresses the mappers that buttress uses, because no other part of launchpad has that abstraction. | 04:30 | |
| (ddaa/#launchpad) get does the right thing even if there is no cachedren | 04:30 | |
| (ddaa/#launchpad) jblack: replay is low-level. Yes the policy has changed since the "arch meets hello world" crap was written. | 04:31 | |
| === jblack wonders idly what arch does if you tag a revision to the previous revision. | ||
| (ddaa/#launchpad) jblack: that's functionally equivalent to commiting w/o change. | 04:32 | |
| (jblack/#launchpad) ddaa: Gah. Then I'll have to rewrite my minihowtos. | 04:32 | |
| (lifeless/#launchpad) spiv: let me rephrase: I got the strong impression from mark that mappers shouldn't be used. But these serv a purpose that AFAICT isn't available as easily/at all in sqlobject classes (ignore the abstraction of search logic etc). How do I meet these two requirements | 04:32 | |
| (lifeless/#launchpad) ? | 04:32 | |
| (jblack/#launchpad) spiv: How often do you hyit the crossed merges? | 04:32 | |
| (ddaa/#launchpad) jblack: tom pretty explicitely said that replay was not meant to handle the tag-in-version back when we discussed it on the mailing list. | 04:33 | |
| (spiv/#launchpad) lifeless: To be honest, I'm not 100% sure what the purpose of the mappers are, so I can't really answer that without more details. | 04:33 | |
| (jblack/#launchpad) ddaa: Ahhhhhhh. | 04:33 | |
| (jblack/#launchpad) ddaa: So now we sell update, because it can. :) | 04:33 | |
| (spiv/#launchpad) jblack: That's the only time it's hit me. | 04:33 | |
| (ddaa/#launchpad) jblack: Yup. Or star-merge. | 04:33 | |
| (ddaa/#launchpad) Which might be faster in this case since it does not have to do the undo/redo stuff. | 04:33 | |
| (jblack/#launchpad) ddaa: Remember? This is a case in which star-merge can't be used, because of the cross. | 04:34 | |
| (lifeless/#launchpad) spiv: they let us inherit behaviours without inheriting representation, for starters. | 04:34 | |
| (ddaa/#launchpad) jblack: I'm talking of star-merge with own version. | 04:34 | |
| (BradB/#launchpad) Did we agree that the dependency on plpython is going to be dropped? I see nothing filed in bugzilla for this, so if it's agreed that it's not worth it, I'll add a bug now. | 04:34 | |
| (jblack/#launchpad) Oh. Yeah. | 04:34 | |
| (ddaa/#launchpad) or without argument, I think it works. | 04:34 | |
| (lifeless/#launchpad) the pyarch object model is only vaguely related to the tables - because they are aimed at different things. | 04:34 | |
| (jblack/#launchpad) Bradb: we still on for 10? | 04:34 | |
| (lifeless/#launchpad) for example, the tables have a concept of an arch namespace, + a branch | 04:34 | |
| (BradB/#launchpad) tomorrow, yeah :) | 04:34 | |
| (jblack/#launchpad) tomorrow? Heh. good you told me. I've got it as today. =). Tomorrow it is | 04:35 | |
| (lifeless/#launchpad) in pyarch - which is the interface that canonical.arch implements, you have Category and Branch and Version. | 04:35 | |
| (jblack/#launchpad) (I remember that now, "this weekend") | 04:35 | |
| (ddaa/#launchpad) rah... slave is doing the hanging thing to me too... | 04:35 | |
| (BradB/#launchpad) :) | 04:35 | |
| (BradB/#launchpad) saturday, yep | 04:35 | |
| (BradB/#launchpad) jblack: BTW, it appears that I'm GMT - 4 atm | 04:36 | |
| (lifeless/#launchpad) I'm frankly at a complete loss to try to do that anywhere near accurately without something bridge the impedence mismatch. | 04:36 | |
| === ddaa terms the bots and update the launchpile | ||
| === BradB isn't sure when to spring forward and fall back (i.e. with clocks) | ||
| (lifeless/#launchpad) did zenity fail? | 04:36 | |
| (jblack/#launchpad) badb: You're on east coast time? | 04:36 | |
| (jblack/#launchpad) bradb: Oh. I'll timechange too. | 04:36 | |
| (BradB/#launchpad) yeah, in Montreal | 04:36 | |
| (ddaa/#launchpad) lifeless: no, just idle hang... | 04:37 | |
| (jblack/#launchpad) Lets oversimplify this. To me, it is 10:37. To you, it is... ? | 04:37 | |
| (ddaa/#launchpad) I previously did a sucessful import run for zenity. | 04:37 | |
| (BradB/#launchpad) 10:37 | 04:37 | |
| (BradB/#launchpad) ntp baby! | 04:37 | |
| (ddaa/#launchpad) I still have to make it work again and test the sync. | 04:37 | |
| (jblack/#launchpad) Ok. So we meet in 23 hours and 23 minutes. | 04:37 | |
| (BradB/#launchpad) yep | 04:37 | |
| (lifeless/#launchpad) ddaa: ok. | 04:38 | |
| (jblack/#launchpad) rephrase: "same time tomorror, but 38 minutes earlier" | 04:38 | |
| (BradB/#launchpad) same difference, yeah :) | 04:38 | |
| (spiv/#launchpad) lifeless: I think buttress needs to be a bit different here, because as you point out, the DB and pyarch have different concepts that need to be bridged. | 04:38 | |
| (spiv/#launchpad) lifeless: So off the top of my head, I suspect the mappers should stay. They could do with clearer commenting about their purpose, though. | 04:39 | |
| === BradB files the plpython bug, in any case | ||
| (lifeless/#launchpad) spiv: ok. | 04:39 | |
| (spiv/#launchpad) lifeless: It's not very obvious to the casual reader why they're needed. | 04:39 | |
| (lifeless/#launchpad) I've just added a todo to document them | 04:40 | |
| (lifeless/#launchpad) feel free to tweak their docstrings though :) | 04:40 | |
| (lifeless/#launchpad) ok, 1am is creeping up here. | 04:42 | |
| (Kinnison/#launchpad) lifeless: can anyone cacherev launchpad? | 04:44 | |
| (lifeless/#launchpad) Kinnison: no. | 04:44 | |
| (lifeless/#launchpad) not unless you have the launchpad gpg key. | 04:44 | |
| (Kinnison/#launchpad) lifeless: It's kinda due a cacherev unless someone added once since yesterday | 04:44 | |
| (lifeless/#launchpad) what needs cachereving ? | 04:44 | |
| (lifeless/#launchpad) I added one this morning | 04:45 | |
| (Kinnison/#launchpad) to launchpad--devel--0 ? | 04:45 | |
| (lifeless/#launchpad) uhuh | 04:45 | |
| (Kinnison/#launchpad) excellent, ta | 04:45 | |
| (Kinnison/#launchpad) How's CVS feeling? | 04:45 | |
| === kiko misses cvs | ||
| (Kinnison/#launchpad) kiko: You do? Gosh | 04:46 | |
| (dilys/#launchpad) New bug 2109 for Launchpad/Launchpad: Drop plpython dependency in LP database | 04:46 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2109 | 04:46 | |
| === Kinnison never thought he'd see the day; but.. I have finally reached the point where tla is actually nicer for me than perforce ever was | ||
| kiko | heh | 04:47 |
| (BradB/#launchpad) Perforce? What're you a core Perl hacker? | 04:47 | |
| kiko | dilys, dilys. | 04:47 |
| === Kinnison enjoys writing little wrappy things like 'hive' | ||
| (lifeless/#launchpad) Kinnison: cscvs good now that I've fixed rlog in the native protocol | 04:47 | |
| (Kinnison/#launchpad) BradB: I run one of the UK's open-source licenced perforce depots | 04:47 | |
| (BradB/#launchpad) ah | 04:47 | |
| (Kinnison/#launchpad) lifeless: excellent. | 04:48 | |
| (debonzi/#launchpad) Ops.. something is going wrong here.. everytime I run make check my db (launchpad_test) is erased | 04:48 | |
| (debonzi/#launchpad) does anybody know about it? | 04:48 | |
| (Kinnison/#launchpad) debonzi: nup, the ftests currently use it | 04:48 | |
| (Kinnison/#launchpad) there is a bug I think about changing that | 04:49 | |
| === BradB star-merges, recreates DB, gets: ConfigurationError: ('Invalid value for', 'class', "Couldn't import canonical.soyuz.sql, No module named apt_pkg") | ||
| (BradB/#launchpad) s/DB, gets/DB, make runs, gets/ | 04:51 | |
| (debonzi/#launchpad) BradB, you need python-apt | 04:51 | |
| (BradB/#launchpad) debonzi: How long has this been a dep? This is the first time I've seen this kind of failure, and I didn't see anything on lp@ mentioning that I should install this. | 04:52 | |
| (dilys/#launchpad) kiko, kiko! | 04:52 | |
| (debonzi/#launchpad) BradB, it is there since yesterday | 04:54 | |
| kiko | debonzi, BradB: is there something where we can enforce this sort of change? | 04:54 |
| kiko | i.e. a global makefile? | 04:55 |
| (BradB/#launchpad) kiko: How would you want it "enforced"? Like spit out a friendly error message if a dep is missing? | 04:55 | |
| (BradB/#launchpad) this doesn't build on OS X, it appears | 04:56 | |
| kiko | hmmm | 04:56 |
| (BradB/#launchpad) which isn't worth spending much time thinking about. | 04:57 | |
| kiko | something that make run would do -- a few attempted import | 04:57 |
| (BradB/#launchpad) is this pkg required, or something soyuz can function without? | 04:57 | |
| kiko | a list of required modules | 04:57 |
| kiko | BradB, required. | 04:57 |
| (BradB/#launchpad) urgh | 04:57 | |
| kiko | it's for parsing dpkg-related content | 04:57 |
| (daf/#launchpad) BradB: it's a choice of use python-apt or rewrite the wheel | 04:58 | |
| (lifeless/#launchpad) daf: I think the question was more 'does every install need it' or 'only those using those functions' | 04:58 | |
| (daf/#launchpad) lifeless: true | 04:59 | |
| (sabdfl/#launchpad) debonzi: thanks for the camelcase patches, it's starting to look nice and neat | 04:59 | |
| (BradB/#launchpad) going to try to just comment out relevant configs for now...not yet sure that'll be adequate, but i'll find out | 04:59 | |
| (spiv/#launchpad) lifeless: Hmm, slave paused at N changeset MAIN.84... is it hung, or should I be patient? | 04:59 | |
| (sabdfl/#launchpad) debonzi: if you want to fix SourcepackageRelease as well then please go ahead | 04:59 | |
| (lifeless/#launchpad) spiv: scroll up | 04:59 | |
| (debonzi/#launchpad) sabdfl, no problem :) | 04:59 | |
| (lifeless/#launchpad) look for 'revs on MAIN' | 05:00 | |
| (Kinnison/#launchpad) spiv: ping | 05:00 | |
| (lifeless/#launchpad) if its 84, then it should just be cross checking | 05:00 | |
| (spiv/#launchpad) lif210 | 05:00 | |
| (spiv/#launchpad) lifeless: 210 | 05:00 | |
| (lifeless/#launchpad) spiv: bah. | 05:00 | |
| (sabdfl/#launchpad) Kinnison: bradb prefers not using the _columns approach to SQLobjects | 05:00 | |
| (lifeless/#launchpad) tell you what, use python-apt as the test | 05:00 | |
| (Kinnison/#launchpad) sabdfl: Oh? | 05:00 | |
| (lifeless/#launchpad) its way small | 05:00 | |
| (sabdfl/#launchpad) 0.6 lets us do it more neatly | 05:00 | |
| (spiv/#launchpad) Kinnison: pong. | 05:00 | |
| (Kinnison/#launchpad) sabdfl: I admit I was just copying from other instances :-) | 05:00 | |
| (sabdfl/#launchpad) check out um... | 05:00 | |
| (Kinnison/#launchpad) spiv: I think I can address one of the bugs (the alias -> URL one) with a little work | 05:01 | |
| (spiv/#launchpad) Kinnison: See thSQLObjectGuide | 05:01 | |
| (spiv/#launchpad) Kinnison: BradB updated it to not use _columns :) | 05:01 | |
| (sabdfl/#launchpad) try database/product.py | 05:01 | |
| (spiv/#launchpad) Kinnison: Great :) | 05:01 | |
| (Kinnison/#launchpad) sabdfl: gotcha, that style is way nicer | 05:01 | |
| (sabdfl/#launchpad) otherwise all your changes look great Kinnison | 05:02 | |
| (sabdfl/#launchpad) agreed | 05:02 | |
| (Kinnison/#launchpad) sabdfl: I'll reflow my code once I've covered the librarian thing I've spotted | 05:02 | |
| (sabdfl/#launchpad) ok | 05:02 | |
| kiko | BradB, you h-e-r-e-t-i-c :) | 05:02 |
| (BradB/#launchpad) heh | 05:02 | |
| kiko | BradB, dude, we were just recalling the elevator spewage yesterday. | 05:03 |
| kiko | wasn't that an experience! | 05:03 |
| (BradB/#launchpad) ewph, yeah | 05:03 | |
| (Kinnison/#launchpad) spiv: 1921 is the one I'm addressing | 05:04 | |
| (sabdfl/#launchpad) lifeless: can we get pqm to send a message to irc when it begins, ends merging? | 05:04 | |
| (sabdfl/#launchpad) or jabber, if that's more secure? | 05:05 | |
| (Kinnison/#launchpad) spiv: is it reasonable for getURIForAlias to return a uri rather than a url? (I.E. /4/8/barfoo.txt rather than http://internalbox:randomport/4/8/barfoo.txt ? | 05:05 | |
| kiko | lifeless, you could get daf to hook that into dilys | 05:05 |
| (sabdfl/#launchpad) spiv: incoming pqm merge gets doap core-complete | 05:05 | |
| (sabdfl/#launchpad) can add, edit, view all the doap table | 05:05 | |
| (sabdfl/#launchpad) will put some time into layout later today | 05:06 | |
| (sabdfl/#launchpad) next week, for doap, i'd like to add portlets for all the linking tables | 05:06 | |
| (sabdfl/#launchpad) so... bugtrackers, bugs, packages, people, translations.... | 05:06 | |
| (sabdfl/#launchpad) sound good spiv? | 05:06 | |
| (lifeless/#launchpad) sabdfl: can easily do that. daf has a bug open where we are discussing this | 05:07 | |
| (lifeless/#launchpad) dilys ? | 05:07 | |
| (debonzi/#launchpad) sabdfl, I got a bit confused now.. in my package.py I have SourcePackageRelease and Sourcepackage. wich one should change? SourcePackageRelease to SourcepackageRelease or Sourcepackage to SourcePackage? | 05:07 | |
| (BradB/#launchpad) Where's the one stanza I can comment out to say "don't load Soyuz"? | 05:07 | |
| kiko | lifeless, it's dilys's dog. | 05:08 |
| kiko | errr | 05:08 |
| (sabdfl/#launchpad) BradB: futurist | 05:08 | |
| kiko | that's wrong. | 05:08 |
| (sabdfl/#launchpad) ;-) | 05:08 | |
| kiko | lifeless, it's daf's dog :) | 05:08 |
| (Kinnison/#launchpad) lifeless: dilys is daf's bot | 05:08 | |
| (spiv/#launchpad) sabdfl: Yep, sounds good. | 05:08 | |
| (BradB/#launchpad) Science fiction, oh, ok. :) | 05:08 | |
| (sabdfl/#launchpad) debonzi: when you're ready, do them all to SourcePackage* | 05:09 | |
| (sabdfl/#launchpad) BradB: i'm keen to get to that point | 05:09 | |
| (sabdfl/#launchpad) but it'll take major work | 05:09 | |
| (sabdfl/#launchpad) for example, we'll need hooks so that soyuz can go and tell doap that it's there | 05:09 | |
| (lifeless/#launchpad) ok, I've fully collapsed now, its one a, | 05:10 | |
| (sabdfl/#launchpad) which then means doap will include soyuz portlets on doap pages | 05:10 | |
| (lifeless/#launchpad) spiv - enjoy | 05:10 | |
| (debonzi/#launchpad) sabdfl, right .. thanks :) | 05:10 | |
| (sabdfl/#launchpad) lifeless: before you crash... | 05:10 | |
| (lifeless/#launchpad) ddaa: catch up with ya monday. | 05:10 | |
| (spiv/#launchpad) lifeless: Thanks. | 05:10 | |
| (lifeless/#launchpad) sabdfl: hmm ? | 05:10 | |
| (ddaa/#launchpad) lifeless: have a nice weekend | 05:10 | |
| (BradB/#launchpad) Actually, I have the required libs, I think...I just need to get the build process to see them. | 05:10 | |
| === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] | ||
| (spiv/#launchpad) Kinnison: Where would this method be? | 05:13 | |
| (Kinnison/#launchpad) FileDownloadClient | 05:14 | |
| (spiv/#launchpad) Hmm. | 05:15 | |
| (Kinnison/#launchpad) It's there anyway for the getFileByAlias() routine (I just split it out) | 05:15 | |
| === Kinnison is about to sit and do the unicode stuff | ||
| (spiv/#launchpad) stub's use-case in 1921 really wants a full URL, with scheme included. | 05:16 | |
| (Kinnison/#launchpad) yeah; which I think is bogus | 05:16 | |
| (Kinnison/#launchpad) because the librarian will be on the appservers somewhere and not on the front-end webservers | 05:16 | |
| (spiv/#launchpad) Hmm. | 05:17 | |
| (spiv/#launchpad) So, for stub's use-case, there's an attachment on a bug stored in the librarian. | 05:18 | |
| (SteveA/#launchpad) sabdfl: set_schema looks at the fields in a schema that are not read-only, and uses the names of those fields | 05:18 | |
| (spiv/#launchpad) It looks like he was envisaging just giving a URL directly to a librarian server. | 05:18 | |
| (SteveA/#launchpad) sabdfl: set_attributes allows the setting of particular attributes by name | 05:19 | |
| (Kinnison/#launchpad) spiv: which seems a touch silly | 05:19 | |
| (spiv/#launchpad) Otherwise, the webserver (i.e. launchpad/zope) needs to download from the librarian, and then pass that to the client. | 05:19 | |
| (sabdfl/#launchpad) SteveA: yeah, it was a readonly that i'd inherited unknowingly, on "title". was interesting to debug. | 05:19 | |
| (Kinnison/#launchpad) spiv: we should give a url which goes through the caches etc | 05:19 | |
| (Kinnison/#launchpad) spiv: Just like we Proxypass for the apps anyway | 05:19 | |
| (spiv/#launchpad) Well, there's no reason why that wouldn't go through caches. | 05:19 | |
| (Kinnison/#launchpad) there's no reason for the apps to speak via the caches to the librarian though really | 05:20 | |
| (Kinnison/#launchpad) unless you want to go through and add all the no-cache headers in the right places | 05:20 | |
| (SteveA/#launchpad) the librarian was conceived as being able to be used directly from people's browsers | 05:20 | |
| (SteveA/#launchpad) that's why the filenames are appropriate for being downloaded | 05:20 | |
| (Kinnison/#launchpad) SteveA: completely *direct* or via a proxypass? | 05:20 | |
| (spiv/#launchpad) Why would the librarian need no-cache headers? | 05:20 | |
| (Kinnison/#launchpad) spiv: digest lookups etc | 05:21 | |
| (spiv/#launchpad) Hmm. | 05:21 | |
| (spiv/#launchpad) Really, that's not hard to add. | 05:21 | |
| (spiv/#launchpad) The files themselves would never change, it's the search resources that would need to do that. | 05:21 | |
| (SteveA/#launchpad) Kinnison: it shouldn't matter all that much -- the librarian ought to be pretty fast. I suppose apache would be faster. | 05:22 | |
| (Kinnison/#launchpad) spiv: okay; I'll alter that call to return a full URL instead | 05:22 | |
| (spiv/#launchpad) The librarian ought to be fast enough. | 05:22 | |
| (Kinnison/#launchpad) SteveA: aye; I was just concerned; but then I remembered we use a different port for uploads | 05:22 | |
| (spiv/#launchpad) If not, it's possible to use sendfile from Twisted, iirc... | 05:22 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: add getURIForAlias to librarian client (patch-613) | 05:30 | |
| (dilys/#launchpad) Bug 2107 resolved: Add Gina and Nicole Descriptions on Wiki | 05:30 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2107 | 05:30 | |
| kiko | Kinnison, ping | 05:35 |
| kiko | Kinnison, do you owe me favors? | 05:36 |
| kiko | wow | 05:36 |
| kiko | there goes jblack-a-deb-buildin' | 05:36 |
| (BradB/#launchpad) Here's the error I'm getting trying to compile python-apt on Jaguar: http://paste.husk.org/1794 | 05:39 | |
| (Kinnison/#launchpad) kiko: probably | 05:39 | |
| (SteveA/#launchpad) daf, carlos: can we meet to talk about rosetta in a bit? | 05:39 | |
| (carlos/#launchpad) SteveA: it's fine for me | 05:40 | |
| kiko | Kinnison, it may be that I can save that credit, jblack seems to be coping. he may have a gift for us soon. | 05:40 |
| (daf/#launchpad) SteveA: yes | 05:42 | |
| (SteveA/#launchpad) 30 mins? | 05:43 | |
| (carlos/#launchpad) here or at #canonical-meeting? | 05:43 | |
| (SteveA/#launchpad) let's see how noisy it is here | 05:44 | |
| (carlos/#launchpad) ok | 05:44 | |
| (Kinnison/#launchpad) kiko: How do you mean? | 05:50 | |
| kiko | let's see | 05:50 |
| (BradB/#launchpad) kiko, debonzi: I think I'll go Thinkpad shopping this weekend, but in the meantime, do you guys have a quick workaround for avoiding the python-apt dependency? | 05:50 | |
| kiko | BradB, commenting out the import, and, well, not looking at package pages? | 05:51 |
| (BradB/#launchpad) kiko: That's the painful workaround, yes. :) | 05:51 | |
| (BradB/#launchpad) I can avoid using the app easily enough, of course, but there are several imports to comment out, which is a pain to deal with with tla. | 05:52 | |
| kiko | Kinnison, I am looking into jblack's version of arch, as part of a sabdfl-endorsed project to improve #launchpad's life | 05:52 |
| (Kinnison/#launchpad) kiko: Hehe | 05:52 | |
| (Kinnison/#launchpad) kiko: Personally I find arch rarely if ever gets in my way :-) | 05:53 | |
| kiko | obviously you don't play gold | 05:53 |
| kiko | err | 05:53 |
| kiko | golf | 05:53 |
| kiko | :) | 05:53 |
| (Kinnison/#launchpad) golf? | 05:53 | |
| kiko | insider joke, nevermind. | 05:53 |
| (BradB/#launchpad) ah, not so bad, turns out i only need to actually uncomment one of the apt_pkg imports | 05:58 | |
| kiko | BradB, why not install apt-pkg? | 05:58 |
| (BradB/#launchpad) kiko: See my comment above about the compiler errors. | 05:59 | |
| (cprov/#launchpad) kiko: wake up ! http://paste.husk.org/1794 | 05:59 | |
| kiko | dude, my scrollback only goes so far | 05:59 |
| kiko | uhm | 06:00 |
| kiko | why not use the .deb? | 06:00 |
| kiko | ah, osX, argh. | 06:00 |
| (cprov/#launchpad) kiko: aha | 06:00 | |
| (cprov/#launchpad) kiko: C++ crap ... | 06:01 | |
| kiko | interesting. appears that there's something fooked in the devel packages for dpkg. | 06:01 |
| kiko | pkgCache::PkgIterator::TargetDist is not found. | 06:02 |
| kiko | hmmm. | 06:02 |
| (BradB/#launchpad) probably not worth spending time thinking about, i'm moving along with malone's page test suite | 06:05 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Library URLs are more use than URIs (patch-614) | 06:09 | |
| (dilys/#launchpad) New bug 2110 for Launchpad/Soyuz: Gina needs to aggregate binary packages into single builds | 06:10 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2110 | 06:10 | |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: More CamelCase changes (patch-615) | 06:16 | |
| (SteveA/#launchpad) daf, carlos | 06:23 | |
| (carlos/#launchpad) SteveA: yep | 06:23 | |
| (daf/#launchpad) hi | 06:26 | |
| (daf/#launchpad) can we postpone by about 10 minutes? | 06:26 | |
| (daf/#launchpad) I need to have some food | 06:26 | |
| kiko | Kinnison, wrt UTF-8, I did some minor experimenting with gina and found a solution that worked for our case. Have you seen it? | 06:27 |
| (SteveA/#launchpad) sure | 06:27 | |
| (carlos/#launchpad) ok | 06:27 | |
| kiko | Kinnison, basically, it's an encode/decode hack that works for the cases relevant for gina, though they aren't magic. | 06:28 |
| === daf returns | ||
| (SteveA/#launchpad) hi | 06:46 | |
| (carlos/#launchpad) let's go | 06:46 | |
| (SteveA/#launchpad) what's been done on rosetta this week? | 06:47 | |
| (daf/#launchpad) we finished the database code reorganization | 06:47 | |
| (daf/#launchpad) a few broken pages were fixed | 06:47 | |
| (carlos/#launchpad) some tests were fixed also | 06:47 | |
| (SteveA/#launchpad) can you add pagetests for the broken pages that were fixed? | 06:48 | |
| (daf/#launchpad) yes | 06:48 | |
| (daf/#launchpad) we'll add tests for all the pages, but we'll do those ones first | 06:48 | |
| (SteveA/#launchpad) in general, if you fix a bug that has stopped a page from working, add a test for it, to stop it happening again | 06:49 | |
| (daf/#launchpad) I did add a unit test for one page when I fixed it | 06:49 | |
| (SteveA/#launchpad) god | 06:49 | |
| (SteveA/#launchpad) good | 06:49 | |
| (SteveA/#launchpad) goood | 06:50 | |
| (carlos/#launchpad) :-P | 06:50 | |
| === carlos should learn page test writting, seems easy after your mails | ||
| (daf/#launchpad) it should be easy | 06:51 | |
| (daf/#launchpad) let us know if it isn't | 06:51 | |
| (carlos/#launchpad) sure | 06:52 | |
| === justdave [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad | ||
| (SteveA/#launchpad) how does the "I want to add an open source app Foo to rosetta" system work at the moment? | 06:52 | |
| (carlos/#launchpad) about my current work, I'm having some problems with the pomsgset split, the pofile_adapters.py need a big change and I did not noticied it until I started with it :-( | 06:52 | |
| (carlos/#launchpad) SteveA: it's a form that sends an email to daf | 06:53 | |
| (daf/#launchpad) carlos: so it's going to take longer than you estimated? | 06:53 | |
| (carlos/#launchpad) SteveA: and he imports the .pot/.po files | 06:53 | |
| (carlos/#launchpad) daf: yes, we are back to the initial estimation (for today) | 06:54 | |
| (daf/#launchpad) oh, you think it can be finished by the end of today? | 06:54 | |
| (daf/#launchpad) that's good | 06:54 | |
| (carlos/#launchpad) yes, I think so | 06:54 | |
| (SteveA/#launchpad) ok, so there's an email sent to daf, and then he does stuff. What does daf need to do? | 06:55 | |
| (daf/#launchpad) have you had any problems with conflicts with Rocketfuel | 06:55 | |
| (daf/#launchpad) SteveA: I need to create the Project, any Products, and run a script on the .pot and .po files | 06:55 | |
| (carlos/#launchpad) daf: but will not be merged into rocketfuel until monday (is too late to get a db change from Stub) | 06:55 | |
| (daf/#launchpad) ok, I'm concerned that merging will be non-trivial | 06:56 | |
| === kiko is now known as kiko-fud | ||
| (daf/#launchpad) well, I'm certain it will be non-trivial | 06:56 | |
| (daf/#launchpad) I suspect it will be a significant amount of work | 06:56 | |
| (SteveA/#launchpad) daf: can you use data from the soyuz guys to stick products and projects in there? | 06:56 | |
| (carlos/#launchpad) daf: yes, but I fixed my tree in a way to prevent them, I removed your pofile.py and commited mine (after checking for any additional change from you, I did not saw any change but code movements) | 06:57 | |
| (daf/#launchpad) SteveA: I don't know | 06:57 | |
| (daf/#launchpad) SteveA: which data are we talking about? | 06:57 | |
| (daf/#launchpad) carlos: I see | 06:57 | |
| (SteveA/#launchpad) product and project data -- there's a screen-scraper for freshmeat etc. Do you think it is possible to automate a lot of the "add a new app to rosetta" stuff? | 06:58 | |
| (daf/#launchpad) carlos: in that case, I'll hold off on any changes to that file | 06:58 | |
| (daf/#launchpad) carlos: the code movement was non-trivial | 06:58 | |
| (SteveA/#launchpad) ideally, someone would request it, it gets added to a queue, and you can choose to authorize it or not, perhaps altering the details. | 06:58 | |
| (daf/#launchpad) carlos: it involved changing imports and things like "implements()" calls | 06:58 | |
| (carlos/#launchpad) daf: I fixed already the imports and those things (as I told you) | 06:58 | |
| (carlos/#launchpad) SteveA: for that, I suppose we should start looking at lifeless imports, right? | 06:59 | |
| (daf/#launchpad) ok, mea culpa, I was confused | 06:59 | |
| (carlos/#launchpad) daf: not, you were right, the movement should be done in different commits, I need to get more used to split better the changes | 07:00 | |
| (SteveA/#launchpad) daf, carlos: I'd like you to think about how to make the "here's new app to translate" process streamlined and simple. | 07:00 | |
| (SteveA/#launchpad) talk to lifeless about imports etc., and come up with a plan on how you can do this. | 07:01 | |
| (daf/#launchpad) SteveA: I think you're right that the creation of Projects and Products could be improved | 07:01 | |
| (SteveA/#launchpad) write the plan to the launchpad list for discussion/information | 07:01 | |
| (carlos/#launchpad) SteveA: does it includes projects that are not imported into arch.ubuntu.com ? | 07:02 | |
| (SteveA/#launchpad) yes, we'll need to have a way of doing this. It might involve actually importing them into arch first, though. | 07:02 | |
| (SteveA/#launchpad) Or it might involve just uploading their pot files | 07:02 | |
| (SteveA/#launchpad) think it through | 07:02 | |
| (carlos/#launchpad) ok | 07:03 | |
| (SteveA/#launchpad) next topic: certificates | 07:03 | |
| (SteveA/#launchpad) please talk to elmo about using the "testers" certificate for rosetta testers, and the "canonical" certificate for the devel server. | 07:04 | |
| (SteveA/#launchpad) the work is done, elmo is just waiting for you to ensure you know what to tell the rosetta testers and launchpad teams, and tell him to turn it on. | 07:04 | |
| (carlos/#launchpad) I don't understand it fully, does it means we will need a SSL certificate to connect with the server instead of a user + password? | 07:05 | |
| (SteveA/#launchpad) yes | 07:05 | |
| (carlos/#launchpad) so we need a certificate per user? | 07:05 | |
| (SteveA/#launchpad) you'll still need a user+password if you want to log in as a particular user | 07:05 | |
| (SteveA/#launchpad) the certificate restricts access to the servers to people we want to access it | 07:05 | |
| (SteveA/#launchpad) the certificate allows us to keep nosy strangers (like readers of slashdot) out | 07:06 | |
| (daf/#launchpad) carlos: no | 07:06 | |
| (carlos/#launchpad) ok | 07:06 | |
| (SteveA/#launchpad) the "canonical" certificate will remain reasonably secure | 07:06 | |
| (daf/#launchpad) carlos: we have two certificates | 07:06 | |
| (SteveA/#launchpad) the "testers" one will probably become somewhat publicly known over time | 07:06 | |
| (SteveA/#launchpad) but that's okay | 07:06 | |
| (carlos/#launchpad) I see | 07:07 | |
| (SteveA/#launchpad) the "canonical" certificate will be at least as secure as the standard username and password we use now | 07:07 | |
| (SteveA/#launchpad) please arrange this very soon | 07:07 | |
| (daf/#launchpad) where can we get these certificates? | 07:07 | |
| (SteveA/#launchpad) ask elmo | 07:07 | |
| (daf/#launchpad) elmo: can you let me know when you're around? | 07:08 | |
| (SteveA/#launchpad) he's not on jabber just now | 07:08 | |
| (daf/#launchpad) elmo seems to be away | 07:08 | |
| (SteveA/#launchpad) maybe use email? | 07:08 | |
| (SteveA/#launchpad) the mention of slashdot leads us on to the next topic... | 07:09 | |
| (SteveA/#launchpad) slashdot. | 07:09 | |
| (SteveA/#launchpad) we should plan to announce a public beta (with the golden database) shortly before the next warty conference | 07:09 | |
| (SteveA/#launchpad) this announcement will almost certainly get us attention from slashdot and other places | 07:10 | |
| (SteveA/#launchpad) so, we need to think about how to design the application to cope with that. | 07:10 | |
| (carlos/#launchpad) the slashdot effect... | 07:10 | |
| (daf/#launchpad) in terms of load? | 07:10 | |
| (SteveA/#launchpad) most readers would click through to the front page of rosetta.ubuntu.com (or whatever) | 07:10 | |
| (SteveA/#launchpad) and, provided that answers their questions, go no further | 07:10 | |
| (SteveA/#launchpad) a proportion will be interested to see if their favourite application is in there | 07:11 | |
| (SteveA/#launchpad) so, that should be fast and obvious | 07:11 | |
| (daf/#launchpad) perhaps we could cache the front page | 07:11 | |
| (SteveA/#launchpad) a proportion will be interested to see what is available in their language | 07:11 | |
| (SteveA/#launchpad) so, that should be fast and obvious | 07:11 | |
| (daf/#launchpad) we don't support that use case | 07:11 | |
| (SteveA/#launchpad) yes, the front page should be cached (for those not logged in) | 07:11 | |
| (daf/#launchpad) and I'm not entirely convinced of its usefulness | 07:11 | |
| (SteveA/#launchpad) but, we should come up with a set of typical use-cases that people coming off the street will casually try | 07:12 | |
| (SteveA/#launchpad) and make sure each use-case is either: | 07:12 | |
| (SteveA/#launchpad) * simply satisfied with minimal load | 07:12 | |
| (SteveA/#launchpad) * clearly indicated as not available | 07:12 | |
| (carlos/#launchpad) daf: "competition" between teams that's the most useful part for it (of course, sane competition) | 07:12 | |
| (SteveA/#launchpad) you can ask the rosetta testers for suggestions of what these use-cases will be | 07:12 | |
| (SteveA/#launchpad) after the certificates are in place | 07:13 | |
| (SteveA/#launchpad) to stop a slashdotting too early | 07:13 | |
| (SteveA/#launchpad) I don't know whether the use-cases I suggested are representative. I mention them to get you thinking about this. | 07:14 | |
| (carlos/#launchpad) ok | 07:14 | |
| (SteveA/#launchpad) also, anti/. isn't urgent, but it is something we need to do over the next 4-5 weeks. | 07:15 | |
| (carlos/#launchpad) I'm waiting for some feedback from Jordi Mallach about Rosetta, where he works have a needs where Rosetta could be used to save their time | 07:16 | |
| (carlos/#launchpad) that will help us also with this | 07:16 | |
| (carlos/#launchpad) he needs to write down a document about their needs and what they miss from the current Rosetta | 07:17 | |
| (daf/#launchpad) https://wiki.canonical.com/RosettaBeta | 07:17 | |
| (SteveA/#launchpad) * streamlined adding of applications | 07:19 | |
| (SteveA/#launchpad) * slashdot-proofing | 07:19 | |
| (daf/#launchpad) the second point is there | 07:20 | |
| (daf/#launchpad) but please add the first | 07:20 | |
| (SteveA/#launchpad) * different "looks" for TSF, ubuntu, the league of catalan floss users... | 07:20 | |
| (daf/#launchpad) multiflavouring Launchpad | 07:21 | |
| (daf/#launchpad) this has been started with the layer work | 07:21 | |
| (SteveA/#launchpad) yes | 07:21 | |
| (daf/#launchpad) do we need to think about changes that will make it more scalable? | 07:21 | |
| (SteveA/#launchpad) we can have many layers at the same time | 07:21 | |
| (daf/#launchpad) i.e. easier to add different flavours? | 07:21 | |
| (SteveA/#launchpad) so, we could have RosettaLayer and TSFLayer simultaneously | 07:22 | |
| (SteveA/#launchpad) TSFLayer would override some colour and logo features, perhaps, | 07:22 | |
| (SteveA/#launchpad) and have a new index page | 07:22 | |
| (SteveA/#launchpad) we need to think about how to do this in an automated way rather than in code, but that's not a priority | 07:22 | |
| (daf/#launchpad) in the future, though, we're going to want to override more than that | 07:22 | |
| (carlos/#launchpad) Should I know what are you talking about?, because I'm lost... | 07:23 | |
| (daf/#launchpad) e.g. to make Rosetta appear to be an application that is for translating one project only | 07:23 | |
| (daf/#launchpad) SteveA: perhaps we should make a note about Launchpad customisation in Bugzilla or on the wiki for later? | 07:24 | |
| (carlos/#launchpad) I mean, I know the concept, but I don't have an idead about how that could be done | 07:24 | |
| (daf/#launchpad) carlos: it will be done using a mechanism called layers | 07:24 | |
| (daf/#launchpad) if you like, I could try and explain them to you later | 07:25 | |
| (daf/#launchpad) right now, let's finish this meeting | 07:25 | |
| (carlos/#launchpad) ok | 07:25 | |
| (SteveA/#launchpad) daf: I've added a section to RosettaBeta for you to add in the requirements for rosetta's handling of different instances. | 07:26 | |
| (SteveA/#launchpad) I don't know that we want to make rosetta an app for translating one project only | 07:27 | |
| (daf/#launchpad) it's something that Mark has mentioned in the past | 07:27 | |
| (SteveA/#launchpad) we can make it have a single project as prominent, | 07:27 | |
| (SteveA/#launchpad) but others will of course be available | 07:27 | |
| (SteveA/#launchpad) because that's the point, isn't it? | 07:27 | |
| (carlos/#launchpad) SteveA: rosetta.gnome.org | 07:27 | |
| (daf/#launchpad) the hypothetical "rosetta.mozilla.org" situation | 07:27 | |
| (carlos/#launchpad) and things like that | 07:27 | |
| (carlos/#launchpad) don't think rosetta.gnome.org should have the kde modules or vice versa | 07:28 | |
| (SteveA/#launchpad) so, I guess the front page of rosetta.mozilla.org would look like mozilla.org, and link directly to mozilla translations... | 07:28 | |
| (carlos/#launchpad) that's the idea | 07:28 | |
| (SteveA/#launchpad) gnome should be able to use the same translations as kde, where they fit | 07:28 | |
| (daf/#launchpad) yes | 07:28 | |
| (carlos/#launchpad) sure, the common modules should be shared, but kdegames does not need to be available as a module at gnome.org | 07:29 | |
| (SteveA/#launchpad) I think you need to take an example (such as gnome or mozilla) and clearly explain what that example should look like and do | 07:29 | |
| (daf/#launchpad) this is a longer-term goal than the shallow customisation we were talking about just now | 07:30 | |
| (SteveA/#launchpad) the final thing I have for this meeting... | 07:30 | |
| (SteveA/#launchpad) daf: ok, so do a phase1, phase N thing here | 07:30 | |
| (SteveA/#launchpad) the main point of rosetta is to allow translating of applications' pot files | 07:31 | |
| (SteveA/#launchpad) we need to make this really really slick before the public beta | 07:31 | |
| (daf/#launchpad) agreed | 07:32 | |
| (SteveA/#launchpad) how about filing a bug called "really slick translation workflow" or similar? | 07:32 | |
| (SteveA/#launchpad) we need to start to pay attention to the finer details now | 07:32 | |
| (SteveA/#launchpad) or at least, over the next few weeks | 07:32 | |
| (SteveA/#launchpad) make specific issues / features bugs linked to that bug | 07:33 | |
| (dilys/#launchpad) New bug 2112 for Launchpad/Rosetta: make the translation process really smooth | 07:36 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2112 | 07:36 | |
| (carlos/#launchpad) SteveA: How does limi's leave affect us?, because the UI needs some help to be able to represent fuzzy strings and suggestions from the translation interface. I'm not too good with UI don't know about daf and that bug depends also on those UI "features" | 07:36 | |
| (SteveA/#launchpad) also, how about a weekly "how slick?" meeting, where we can get someone to go through doing a translation, and give comments, much like the warty team were getting for improving the installer? | 07:36 | |
| (daf/#launchpad) SteveA: good idea | 07:37 | |
| (SteveA/#launchpad) carlos: keep a list of issues that need specific UI work. We can see about contracting limi for specific UI tasks. | 07:37 | |
| (daf/#launchpad) carlos: I think we'll just have to muddle through as best we can, and make the best use of limi's time while we still have him | 07:37 | |
| (carlos/#launchpad) ok | 07:37 | |
| (carlos/#launchpad) another thing interesting to know is if lalo left completely already (to reasign his bugs and see if there is any pending commit from his archive to merge into rocketfuel) | 07:39 | |
| (SteveA/#launchpad) lalo has left completely. | 07:40 | |
| (SteveA/#launchpad) it is a good idea to reassign his bugs. | 07:40 | |
| (SteveA/#launchpad) I suggest to not worry about his code, as it will be tough to merge now, after all the refactoring. | 07:40 | |
| (spiv/#launchpad) I'm working with his code, actually. | 07:40 | |
| (carlos/#launchpad) ok | 07:41 | |
| (spiv/#launchpad) It's needed for stuff I'm doing for lifeless. | 07:41 | |
| (SteveA/#launchpad) the databae stuff? | 07:41 | |
| (spiv/#launchpad) Yeah. We didn't touch sqlbase, so merging wasn't an issue. | 07:41 | |
| (SteveA/#launchpad) but, nothing for the rosetta team to particularly worry about | 07:41 | |
| (spiv/#launchpad) Right. | 07:41 | |
| (SteveA/#launchpad) ok | 07:42 | |
| (SteveA/#launchpad) that's all from me. Thanks daf and carlos! | 07:43 | |
| (carlos/#launchpad) ok | 07:43 | |
| (daf/#launchpad) SteveA: thank you | 07:43 | |
| (daf/#launchpad) spiv: is this the transactional zopeless stuff? | 07:44 | |
| (spiv/#launchpad) daf: Yep. | 07:44 | |
| (daf/#launchpad) what state is that in? | 07:44 | |
| (daf/#launchpad) any idea when we can use it? | 07:45 | |
| (spiv/#launchpad) I've extended it to cope with multiple threads, and it seems to work for me, but it's having problems with importd. | 07:45 | |
| (spiv/#launchpad) daf: You're welcome to play with my zopeless-transactions branch if you want ;) | 07:45 | |
| (spiv/#launchpad) I expect to have it merged very soon, as soon as I've tracked down the importd bug. | 07:46 | |
| === kiko-fud is now known as kiko | ||
| (carlos/#launchpad) spiv: should I reassign to you https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1986 ? | 07:46 | |
| (spiv/#launchpad) carlos: Yes, thanks. | 07:46 | |
| (spiv/#launchpad) carlos: Or I can reassign it myself :) | 07:47 | |
| (carlos/#launchpad) spiv: I did it already :-P | 07:47 | |
| (spiv/#launchpad) :) | 07:48 | |
| === carlos goes to get some food | ||
| (daf/#launchpad) spiv: I suspect it will be good enough for at least some of what I'd like to do with it | 07:56 | |
| (daf/#launchpad) spiv: is there documentation? | 07:56 | |
| (spiv/#launchpad) daf: Not yet. Assign a bug to me about it :) | 08:01 | |
| (dilys/#launchpad) New bug 2113 for Launchpad/Launchpad: documentation for transactional Zopeless database access | 08:06 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2113 | 08:06 | |
| (spiv/#launchpad) daf: Ta. | 08:06 | |
| (daf/#launchpad) welcome :) | 08:06 | |
| kiko | I suppose we could move gina to zopeless. | 08:09 |
| (BradB/#launchpad) SteveA: By the way, it appears that the PT generator isn't usable for stuff that requires auth. I'll be filing a couple of (more) bugs saying why right now. | 08:11 | |
| (SteveA/#launchpad) cool. I'll be working on this tomorrow. | 08:11 | |
| (SteveA/#launchpad) as, we have lots of pages requireing auth | 08:11 | |
| (BradB/#launchpad) yes, definitely | 08:13 | |
| (sabdfl/#launchpad) daf: sorry, wrong window on the mawson stuff in #canonical | 08:15 | |
| (sabdfl/#launchpad) nonetheless, think we can open 8086 for bug tracebacks on that box too? | 08:15 | |
| (SteveA/#launchpad) daf is talking to elmo about getting client certs going for the servers on mawson | 08:16 | |
| (SteveA/#launchpad) you can go to /errors to see tracebacks | 08:17 | |
| (SteveA/#launchpad) https://rosetta.warthogs.hbd.com/errors | 08:17 | |
| (sabdfl/#launchpad) SteveA: thanks for the errors tip | 08:19 | |
| (sabdfl/#launchpad) does that work for any launchpad instance? | 08:20 | |
| (SteveA/#launchpad) yes | 08:20 | |
| (sabdfl/#launchpad) cool | 08:21 | |
| (SteveA/#launchpad) of course, it is inaccessible from the rosetta alpha, because '/' to the outside world is '/rosetta/' on the launchpad server | 08:21 | |
| (SteveA/#launchpad) the tracebacks at /errors are held in memory. they are cleared whenever the server is restarted. | 08:21 | |
| (daf/#launchpad) sabdfl: I'll make an announcement when Mawson is using client certs | 08:25 | |
| (sabdfl/#launchpad) thanks daf | 08:27 | |
| (sabdfl/#launchpad) SteveA: if that's a problem i'm sure we could rewrite the proxy to pass /errors/ through appropriately too | 08:28 | |
| (SteveA/#launchpad) sure, or expose /errors in each application | 08:30 | |
| (SteveA/#launchpad) it's just a suburls directive | 08:30 | |
| (dilys/#launchpad) New bug 2114 for Launchpad/Launchpad: Page test generator generates failing tests for protected pages | 08:30 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2114 | 08:30 | |
| (SteveA/#launchpad) but actually, having /errors available, and protected by certificate auth, might be a good idea anyway for rosetta alpha | 08:30 | |
| (BradB/#launchpad) SteveA: With these PT's, are we supposed to record doing the actual authentication, or is it also okay to already have auth'd (on port 9000), before you start recording? | 08:48 | |
| (BradB/#launchpad) IIRC, it doesn't affect the outcome re: the bugs I'm reporting. | 08:48 | |
| (BradB/#launchpad) (Of course you'd have to have recorded while auth'ing on 9000, but I mean if you record, auth, stop recording, erase the file, then start recording again once already auth'd) | 08:49 | |
| (daf/#launchpad) "while auth'ing"? | 08:50 | |
| (daf/#launchpad) doesn't HTTP send credentials with each request? | 08:51 | |
| (BradB/#launchpad) yes | 08:55 | |
| (BradB/#launchpad) if you're auth'd | 08:55 | |
| (BradB/#launchpad) :) | 08:55 | |
| (daf/#launchpad) right | 08:55 | |
| (daf/#launchpad) so it doesn't matter if you do the typing in of the password | 08:56 | |
| (daf/#launchpad) they key thing is that the auth headers are captured for the pages you want to record | 08:56 | |
| (dilys/#launchpad) New bug 2115 for Launchpad/Launchpad: Firefox's fetching of favicon causes AssertionError in page test generator | 08:57 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2115 | 08:57 | |
| (sabdfl/#launchpad) where do I store page tests, or does the script that creates them know where to put them? | 09:03 | |
| (debonzi/#launchpad) sabdfl, I belive they will be altomatic placed in lib/canonical/launchpad/pagetests | 09:05 | |
| (daf/#launchpad) sabdfl: the script knows | 09:07 | |
| (daf/#launchpad) sabdfl: did you see the document on the wiki? | 09:07 | |
| kiko | BradB, wanna try and sort out your apt-pkg bustage? | 09:08 |
| (BradB/#launchpad) kiko: If you have an idea that can solve it quickly, sure. :) | 09:09 | |
| (sabdfl/#launchpad) debonzi: thanks | 09:10 | |
| (sabdfl/#launchpad) does teh page test use the existing sample data or does it use a separate data source? | 09:10 | |
| kiko | BradB: do you have the apt-pkg headers installed? | 09:10 |
| (BradB/#launchpad) yep | 09:11 | |
| (daf/#launchpad) sabdfl: existing sample data | 09:11 | |
| (daf/#launchpad) sabdfl: Read The Fine Wiki :) | 09:11 | |
| (BradB/#launchpad) kiko: i'm fairly sure they're not a suitable version though | 09:11 | |
| kiko | BradB, can you grep through them for the required method? | 09:11 |
| (BradB/#launchpad) kiko: Yep, did that already. Doesn't find anything. | 09:11 | |
| kiko | BradB, can you check the version? | 09:12 |
| (BradB/#launchpad) i apt-dev 0.5.4-15 Advanced front-end for dpkg | 09:12 | |
| kiko | BradB, this is from fink, right? | 09:12 |
| (sabdfl/#launchpad) daf: hmm.... this means that there might be bad interactions between the data and the tests | 09:12 | |
| (BradB/#launchpad) kiko: In Jaguar, yes. | 09:12 | |
| (daf/#launchpad) sabdfl: why? | 09:12 | |
| kiko | Package: libapt-pkg-dev | 09:13 |
| (sabdfl/#launchpad) because id's might vary | 09:13 | |
| kiko | Version: 0.5.26 | 09:13 |
| kiko | Depends: apt-utils, libapt-pkg-libc6.3-5-3.3 | 09:13 |
| kiko | Filename: pool/main/a/apt/libapt-pkg-dev_0.5.26_i386.deb | 09:13 |
| (sabdfl/#launchpad) if we expose id in the ui, which we prefer not to do but which we might anyhow | 09:13 | |
| (BradB/#launchpad) kiko: yep, that's what i'm thinking it is. | 09:13 | |
| (sabdfl/#launchpad) say you create a test now | 09:13 | |
| (daf/#launchpad) that's what "..." is for | 09:13 | |
| (sabdfl/#launchpad) for adding a project | 09:13 | |
| (BradB/#launchpad) kiko: I'm not confident on install a version that isn't used by fink though. | 09:13 | |
| (sabdfl/#launchpad) it will get added with a specific id | 09:13 | |
| (BradB/#launchpad) s,on install,on installing, | 09:13 | |
| kiko | BradB, http://apt.darwinports.com/ | 09:13 |
| (sabdfl/#launchpad) then you have tests for things related to that | 09:13 | |
| (sabdfl/#launchpad) they all expect specific id's | 09:14 | |
| kiko | http://apt.darwinports.com/dports/sysutils/apt/Portfile | 09:14 |
| (sabdfl/#launchpad) now we update the sampledata | 09:14 | |
| (sabdfl/#launchpad) suddenly, all the tests fail | 09:14 | |
| (sabdfl/#launchpad) seems to me that running the page test creation script should: | 09:14 | |
| (sabdfl/#launchpad) - reset the launchpad_test db to a known starting state | 09:14 | |
| (sabdfl/#launchpad) - fire up launchpad using the launchpad_test db | 09:15 | |
| (sabdfl/#launchpad) oh, actually, that's the one we're already using, innit | 09:15 | |
| kiko | BradB, hum hum. | 09:15 |
| (sabdfl/#launchpad) so, some other db | 09:15 | |
| (sabdfl/#launchpad) then create the tests using that data | 09:15 | |
| (BradB/#launchpad) kiko: i'm giving it a try right now; installing apt-get via port, instead of what i already had, which is via fink | 09:15 | |
| (daf/#launchpad) we've discussed this to some extent on the mailing list | 09:15 | |
| (sabdfl/#launchpad) i guess we can solve this when the problem occurs, but i bet it is going to occur | 09:16 | |
| (daf/#launchpad) I think you're right that it could cause problems | 09:16 | |
| (daf/#launchpad) we reset the database for running the tests, but not for creating them | 09:16 | |
| (sabdfl/#launchpad) resetting the db for creating them would be worse | 09:17 | |
| (sabdfl/#launchpad) because then each test would expect to be run with a clean db | 09:17 | |
| (daf/#launchpad) no, that's not the plan | 09:17 | |
| (sabdfl/#launchpad) and clearly, if it is run after another test, it won't have one | 09:18 | |
| (daf/#launchpad) it's fine for tests to depend on each other | 09:18 | |
| kiko | BradB, you da man | 09:18 |
| (daf/#launchpad) they are run in a specific order | 09:18 | |
| (sabdfl/#launchpad) well then we would have to reset the db, run the tests, THEN create the new one | 09:18 | |
| (sabdfl/#launchpad) maybe that's exactly what the makepagetest script should do | 09:18 | |
| (sabdfl/#launchpad) start with an absolutely minimal db | 09:19 | |
| (daf/#launchpad) that's what Steve intnds to do, I think | 09:19 | |
| (daf/#launchpad) so, if you're creating a test with priority 40 | 09:19 | |
| (BradB/#launchpad) sabdfl: you could always use "..." to say "i don't care what this part of the page looks like", to avoid those problems with changing test data. | 09:19 | |
| (sabdfl/#launchpad) then each time you want to create a test it first runs the previous tests, thereby creating a new test environment for the new test | 09:19 | |
| (daf/#launchpad) it would reset the DB, run tests 00..39, and create the new one | 09:19 | |
| (sabdfl/#launchpad) right | 09:19 | |
| (daf/#launchpad) BradB: but you can't do that in the request part of the test | 09:20 | |
| (daf/#launchpad) BradB: such as if you have an id in a URL | 09:20 | |
| (sabdfl/#launchpad) anyhow i'm happily creating tests now and glad for it, its a very good start | 09:20 | |
| (BradB/#launchpad) daf: if someone's going to change an id, they better have a good reason for doing so. :) | 09:21 | |
| (daf/#launchpad) right | 09:21 | |
| (daf/#launchpad) but the tests might create new IDs | 09:21 | |
| (daf/#launchpad) which might be different ones depending on those already in the DB | 09:22 | |
| (BradB/#launchpad) yeah...could get pretty painful for someone trying to check in changes to sampledata | 09:23 | |
| (BradB/#launchpad) kiko: gah, port install apt fails | 09:23 | |
| (BradB/#launchpad) ... | 09:23 | |
| (BradB/#launchpad) init.cc: In function `bool pkgInitConfig(Configuration&)': | 09:23 | |
| (BradB/#launchpad) init.cc:100: `bindtextdomain' undeclared (first use this function) | 09:23 | |
| (BradB/#launchpad) init.cc:100: (Each undeclared identifier is reported only once for each | 09:23 | |
| (BradB/#launchpad) function it appears in.) | 09:23 | |
| (BradB/#launchpad) init.cc:101: `textdomain' undeclared (first use this function) | 09:23 | |
| (BradB/#launchpad) ... | 09:23 | |
| kiko | BradB, you need gettext | 09:23 |
| kiko | libintl | 09:23 |
| (BradB/#launchpad) eek, is port really that bad at dependency handling... | 09:24 | |
| === BradB finds out | ||
| (sabdfl/#launchpad) ah, just ran into the problem :-) | 09:25 | |
| (sabdfl/#launchpad) but this time it's easily solvable. | 09:25 | |
| (sabdfl/#launchpad) my new test modifies the title / description etc of a product, so that was causing other tests to barf | 09:25 | |
| (BradB/#launchpad) kiko: same error after installing gettext with port. | 09:27 | |
| kiko | could to be an extern C { } issue -- those are defined in libintl.h -- is that being imported? it is present? | 09:29 |
| (BradB/#launchpad) kiko: It's in /opt/local/include. | 09:30 | |
| (BradB/#launchpad) kiko: port installs everything under /opt, so I'd expect it should know where it is...in some magical way. | 09:30 | |
| kiko | I'm more concerned about a missing include in init.cc, perhaps turned off because of a configuration option. | 09:32 |
| (BradB/#launchpad) ah | 09:32 | |
| (BradB/#launchpad) trying to build it by hand now | 09:32 | |
| kiko | that's what it's indicating -- missing libintl.h. | 09:33 |
| kiko | you may get link-time errors but a -lintl should fix that. | 09:33 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: initial doap tests (patch-616) | 09:47 | |
| kiko | BradB, no luck? | 09:48 |
| (BradB/#launchpad) kiko: Nope, i gave up. I thought "port fetch apt" would give me a tarball or a directory in the current dir, but I have no idea where it's putting the source, or if that even d/l's it. | 09:49 | |
| kiko | I can get you an apt-pkg tarball, but this situation just sucks. | 09:51 |
| (BradB/#launchpad) The manpage doesn't tell me how to use "port fetch" to grab the tarball, nor does Google. | 09:51 | |
| (BradB/#launchpad) ooo...i think i accidentally found that dir | 09:55 | |
| === kiko chuckles | ||
| kiko | I can get you a tarball if that helps | 10:00 |
| kiko | and btw | 10:00 |
| kiko | you probably don't need to actually install this renegate apt version | 10:00 |
| kiko | just compile against it | 10:00 |
| kiko | *maybe* place the library somewhere | 10:00 |
| (BradB/#launchpad) I just tried that | 10:00 | |
| kiko | here comes bad news? | 10:01 |
| (BradB/#launchpad) bradb@ozone:~/darwinports/dports/sysutils/apt/work/apt-0.5.24/apt-pkg$ grep -rn TargetDist * | 10:01 | |
| (BradB/#launchpad) bradb@ozone:~/darwinports/dports/sysutils/apt/work/apt-0.5.24/apt-pkg$ | 10:01 | |
| kiko | wtf. | 10:01 |
| kiko | one sec. | 10:01 |
| kiko | wait, what you want is libapt-pkg-dev | 10:02 |
| kiko | not apt-pkg | 10:02 |
| kiko | I don't actually have an apt-pkg thing here. | 10:02 |
| (BradB/#launchpad) dude, that is libapt-pkg-dev | 10:02 | |
| (BradB/#launchpad) well, in effect it is, anyway | 10:02 | |
| (BradB/#launchpad) that dir has all the .c's in it | 10:02 | |
| (BradB/#launchpad) er, .cc's actually, hm | 10:02 | |
| (BradB/#launchpad) and headers | 10:03 | |
| kiko | let me look this up, give me 2 | 10:03 |
| (BradB/#launchpad) ok | 10:03 | |
| === kiko curses apt-pkg | ||
| (BradB/#launchpad) sabdfl: were you able to get a page test passing that needs auth? | 10:04 | |
| === jblack [~jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad | ||
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: more doap tests (patch-617) | 10:09 | |
| (BradB/#launchpad) sabdfl: second, presumably each time one of the following things happens to a bug, a notification email should be sent to each person subscribed: a followup comment, adding/editing of a {product,packge} assignment, adding/editing of a {product release,package release} infestation, adding/editing of an external ref, adding/editing of a bug watch. | 10:13 | |
| (sabdfl/#launchpad) BradB: yes, seemingly without problem | 10:14 | |
| (sabdfl/#launchpad) just needed a bit of ... action | 10:14 | |
| kiko | BradB, apt-pkg is now up to 0.5.27 :) | 10:14 |
| (sabdfl/#launchpad) BradB: sounds good | 10:15 | |
| (sabdfl/#launchpad) also editing of the bug details itself | 10:15 | |
| (sabdfl/#launchpad) each of these things should also presumably generate an entry in bugentry too | 10:15 | |
| (sabdfl/#launchpad) erm... bugactivity | 10:15 | |
| (BradB/#launchpad) ah | 10:16 | |
| (BradB/#launchpad) sabdfl: How simple is your auth PT? | 10:16 | |
| (sabdfl/#launchpad) very | 10:16 | |
| (BradB/#launchpad) e.g. I can get one working if I just click one link, and remove the "Connection: closed" garbage. | 10:16 | |
| (sabdfl/#launchpad) for most of them i'm basically only testing "is the page there"? | 10:16 | |
| (BradB/#launchpad) But a more complex one (as detailed in Bugzilla) fails in a big way. | 10:17 | |
| (sabdfl/#launchpad) Connection: closed? | 10:17 | |
| (sabdfl/#launchpad) here's an example that's working for me: | 10:17 | |
| (BradB/#launchpad) kiko: Yeah, well, it's hopeless on Jaguar...that's why I say, no point worry about it probably. | 10:17 | |
| kiko | BradB, uhm, what version of python-apt are you installing? | 10:17 |
| kiko | BradB, I don't have that symbol in any header either. | 10:17 |
| (sabdfl/#launchpad) >>> print http(r""" | 10:17 | |
| (sabdfl/#launchpad) ... POST /doap/projects/mozilla/firefox/+edit HTTP/1.1 | 10:17 | |
| (sabdfl/#launchpad) ... Authorization: Basic Zm9vLmJhckBjYW5vbmljYWwuY29tOnRlc3Q= | 10:17 | |
| (sabdfl/#launchpad) ... Content-Length: 595 | 10:17 | |
| (sabdfl/#launchpad) ... Content-Type: application/x-www-form-urlencoded | 10:17 | |
| (sabdfl/#launchpad) ... Referer: http://localhost:9000/doap/projects/mozilla/firefox/+edit | 10:18 | |
| (sabdfl/#launchpad) ... | 10:18 | |
| (sabdfl/#launchpad) ... displayname=Firefox&title=Firefox&shortdesc=The+Mozilla+Firefox+web+browser+is+a+fast%2C+efficient+web+browser+that+has+superb+support+for+Internet+standards%2C+is+considered+more+secure+than+the+more+common+browsers+and+has+many+features+that+enhance+your+web+browsing+experience.&description=The+Mozilla+Firefox+web+browser+is+a+direct+descendant+of+the+Netscape+browser+which+brought+the+Internet+phenomenon+to+the+attention+ | 10:18 | |
| (BradB/#launchpad) kiko: 0.0.2 | 10:18 | |
| (sabdfl/#launchpad) HTTP/1.1 303 See Other | 10:18 | |
| (sabdfl/#launchpad) ... | 10:18 | |
| kiko | BradB, it could just be you've got an old python-apt version. | 10:18 |
| kiko | ah! | 10:18 |
| (sabdfl/#launchpad) Content-Type: text/html;charset=utf-8 | 10:18 | |
| (sabdfl/#launchpad) Location: http://localhost:9000/doap/projects/mozilla/firefox | 10:18 | |
| (sabdfl/#launchpad) ... | 10:18 | |
| (sabdfl/#launchpad) <h1>Edit "..." Product | 10:18 | |
| (sabdfl/#launchpad) Details</h1> | 10:18 | |
| (sabdfl/#launchpad) ... | 10:18 | |
| (sabdfl/#launchpad) you get all of that? | 10:18 | |
| kiko | BradB, 0.5.10 :-P | 10:18 |
| (BradB/#launchpad) oh, i just went to sf | 10:19 | |
| (sabdfl/#launchpad) i basically retain all of the POST header and content | 10:19 | |
| (sabdfl/#launchpad) and then just enough of the response header and content to know that there was a response, and it had a h1 section that looked sort of correct | 10:19 | |
| === kiko chuckles | ||
| kiko | BradB, let me get you a tarball. | 10:19 |
| (BradB/#launchpad) of python-apt? | 10:19 | |
| (sabdfl/#launchpad) how does python-apt come into it? | 10:20 | |
| (BradB/#launchpad) sabdfl: that was to kiko :) | 10:20 | |
| (sabdfl/#launchpad) ah :-) | 10:20 | |
| (sabdfl/#launchpad) sorry | 10:20 | |
| (BradB/#launchpad) kiko: I'd imagine this info would be best sent to the lp@ | 10:20 | |
| (BradB/#launchpad) As with any new dep that gets added. | 10:20 | |
| kiko | that's the package that contains apt-pkg | 10:21 |
| (sabdfl/#launchpad) bradb i've committed some authenticated tests, would be interested to know if they all run ok for you | 10:21 | |
| (BradB/#launchpad) sabdfl: yeah, i'll check now (well...after a star-merge) | 10:21 | |
| (sabdfl/#launchpad) see you in an hour or two then | 10:21 | |
| (sabdfl/#launchpad) :-) | 10:21 | |
| (BradB/#launchpad) heh | 10:21 | |
| === BradB wonders if OS X is just arse, or of it just needs more lovin from Open Source developers | ||
| (sabdfl/#launchpad) BradB: i suspect they needed to mung FreeBSD pretty badly to make it fit the old apple way | 10:28 | |
| (sabdfl/#launchpad) and it will likely get better with time | 10:28 | |
| kiko | BradB, is DCC good for you? | 10:31 |
| (BradB/#launchpad) kiko: mm, can you put it at a URL? | 10:31 | |
| kiko | email? | 10:32 |
| kiko | it's teensy. | 10:32 |
| (BradB/#launchpad) oh, sure. i guess it's small. | 10:32 | |
| (BradB/#launchpad) bradb@bbnet.ca | 10:32 | |
| kiko | or, hmmm. | 10:32 |
| kiko | www.async.com.br/~kiko/python-apt_0.5.10.tar.gz | 10:33 |
| kiko | BradB, does that hurt less? | 10:37 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Source and Binary package sample data for page tests (patch-618) | 10:38 | |
| (BradB/#launchpad) kiko: what's the simplest way i can specifically tell it to use a certain include dir? | 10:40 | |
| kiko | kiko@scurvy:~/python-apt-0.5.10$ CFLAGS=-I/usr/foo python setup.py build | 10:41 |
| (BradB/#launchpad) ouch | 10:45 | |
| kiko | what now? | 10:45 |
| (BradB/#launchpad) My C is pretty rusty, but now I see about 100+ lines of crap from the build that fails | 10:46 | |
| kiko | can I get a shell account on that box? | 10:46 |
| (BradB/#launchpad) is it worth it though dude? | 10:48 | |
| (BradB/#launchpad) I don't think OS X is a platform that's worth supporting. | 10:48 | |
| (BradB/#launchpad) Unless sabdfl sees a need for it. | 10:48 | |
| jblack | except for arch? :) | 10:49 |
| (BradB/#launchpad) yeah, for arch for sure | 10:49 | |
| (sabdfl/#launchpad) what's python-apt for? | 10:50 | |
| jblack | according to dpkg, a python interface to libapt-pkg | 10:50 |
| (daf/#launchpad) sabdfl: it's used for parsing data suck as package lists | 10:50 | |
| (daf/#launchpad) ahem, such | 10:51 | |
| (sabdfl/#launchpad) ah, ok, gina et al | 10:51 | |
| (daf/#launchpad) yes | 10:51 | |
| (sabdfl/#launchpad) thanks daf | 10:51 | |
| (BradB/#launchpad) daf: Why must LP depend on it though? | 10:51 | |
| (BradB/#launchpad) daf: It doesn't seem like something I should need to have installed for LP to start up. | 10:51 | |
| (daf/#launchpad) BradB: does LP fail to start up without it? | 10:52 | |
| kiko | BradB, sabdfl: we use it to parse the dependency lists stored in *Package. | 10:52 |
| (BradB/#launchpad) daf: yes, that's why this matters to me at all right now :) | 10:52 | |
| kiko | BradB, sabdfl: that in turn is what produces the nice linked list that we display on the package browsing view. | 10:52 |
| (daf/#launchpad) BradB: can you give me a backtrace? | 10:52 | |
| kiko | sorry if that wasn't clear up to now. | 10:52 |
| (daf/#launchpad) BradB: on Jabber or in a query would do | 10:53 | |
| kiko | BradB, I do think it's worth it, by jove, your chosen platform! | 10:53 |
| (BradB/#launchpad) daf: It's pretty simple, the error comes from the fact that lib/canonical/soyuz/sql.py does a: from apt_pkg import ParseDepends, ParseSrcDepends. (the TB is simply a non-descriptive error message that would ultimately lead you to finding that import) | 10:53 | |
| (daf/#launchpad) ok :) | 10:54 | |
| (BradB/#launchpad) so, of course, any ZCML file that configures something in that namespace will raise that error, which is tons of places. | 10:55 | |
| (daf/#launchpad) kiko: does this import need to be in sql.py? | 10:55 | |
| (daf/#launchpad) kiko: seems to me that it's not that closely related to the database stuff | 10:55 | |
| (daf/#launchpad) kiko: and why does Soyuz still have an sql.py anyhow? | 10:55 | |
| kiko | daf, not necessarily, but seems to me that that's besides the point. | 10:55 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: First page tests for soyuz (patch-619) | 10:55 | |
| kiko | daf, historical reasons, we're getting rid of it. | 10:55 |
| (BradB/#launchpad) kiko: You *can't* tell me that LP failing to startup on machines that don't have apt_pkg is The Right Thing to do though. :) | 10:55 | |
| (BradB/#launchpad) I mean, you could tell me that, but I'd have a hard time believing you. :P | 10:56 | |
| (daf/#launchpad) kiko: I can see BradB's point of view | 10:56 | |
| (daf/#launchpad) kiko: he doesn't want to get gina working or anything like that, he just wants Launchpad to run | 10:56 | |
| kiko | BradB, I'm not sure -- it *is* a part of the required packages to run Soyuz. I don't know what the policy is for dependencies -- we're just the first ones to actually entail that. | 10:56 |
| kiko | daf, it's not just Gina, it's Soyuz pages. | 10:56 |
| (daf/#launchpad) kiko: *really*? | 10:56 | |
| kiko | daf, the package browser, as I wrote a few lines above. | 10:57 |
| (daf/#launchpad) kiko: isn't it just for import stuff? | 10:57 | |
| (daf/#launchpad) I thought all the web stuff just used the database | 10:57 | |
| kiko | no, the package browser lists dependencies. dependencies are parsed using python-apt. | 10:57 |
| (daf/#launchpad) I see | 10:57 | |
| (daf/#launchpad) that makes more sense to me now | 10:57 | |
| (BradB/#launchpad) hm | 10:58 | |
| kiko | there are other things that could also be handled by python-apt, I just decided to unify this, unfortunately creating a dependency that is a problem on problematic OSs. | 10:58 |
| (daf/#launchpad) I wonder how difficult it would be for BradB to "turn off" Soyuz temporarily | 10:58 | |
| kiko | there are a couple of solutions to this, but BradB needs to let me try and fix python-apt to compile on his box or else I can't evaluate that option :) | 10:58 |
| (BradB/#launchpad) I commented out the import. If it were moved into the methods where the apt_pkg classes are actually being used, that would fix it too. | 10:58 | |
| kiko | "fix". | 10:58 |
| kiko | you'd still have broken pages, remember. | 10:58 |
| (BradB/#launchpad) yeah, well.. | 10:59 | |
| (daf/#launchpad) moving imports into methods is ugly | 10:59 | |
| (BradB/#launchpad) indeed | 10:59 | |
| (daf/#launchpad) ok, perhaps fixing python-apt is the best course of action after all | 10:59 | |
| (BradB/#launchpad) kiko: my point about the ssh thing though is that if i'm the only person this is affecting, it's probably not worth the time (unless you think it is.) | 11:00 | |
| kiko | it's more of a platform thing: is python-apt not worth trusting because it's going to be a cross-platform nuisance? | 11:01 |
| kiko | should I kill a tuesday and rewrite it in Python? | 11:01 |
| kiko | etc. | 11:01 |
| (BradB/#launchpad) I would have thought the answer to that question is obvious though, python-apt isn't cross platform. | 11:02 | |
| kiko | hey, some C++ is cross-platform. :) | 11:02 |
| (BradB/#launchpad) python-apt on windows? hmm. | 11:02 | |
| === kiko shrugs | ||
| kiko | I am willing to invest an ssh hour to evaluate the option on OS X, but you have to let me. :) | 11:03 |
| (BradB/#launchpad) ok, i'll give you an acct then. :) | 11:03 | |
| === kiko cheers for lost fridays | ||
| (daf/#launchpad) you're more likely to get something that works on Debian working on Mac OS X than vice versa | 11:04 | |
| kiko | fink, even. | 11:05 |
| (carlos/#launchpad) anyone is filling the current.sql file with ^M new line characters... | 11:07 | |
| (carlos/#launchpad) do we have any "Windows" developer?? | 11:07 | |
| kiko | not me. | 11:08 |
| kiko | cvs blame? :) | 11:08 |
| (sabdfl/#launchpad) (21:53:06) kiko: BradB, I do think it's worth it, by jove, your chosen platform! | 11:08 | |
| (sabdfl/#launchpad) kiko you are priceless :-) | 11:08 | |
| kiko | I do honestly feel that way, though. :) | 11:10 |
| (sabdfl/#launchpad) BradB: what about a stub implementation that just has those names in its namespace? | 11:10 | |
| (sabdfl/#launchpad) you're not actually going to run that code ar you? | 11:10 | |
| (dilys/#launchpad) New bug 2116 for Launchpad/Launchpad: page test helper generates a failing test for Rosetta project view | 11:11 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2116 | 11:11 | |
| (BradB/#launchpad) sabdfl: nope...i thought about that...it was just that commenting one line of python was quicker | 11:13 | |
| === debonzi goes to sync his laptop for the weekend | ||
| (sabdfl/#launchpad) BradB: hmmm... thinking about it | 11:16 | |
| (sabdfl/#launchpad) you might not run that code but the page tests will | 11:16 | |
| (BradB/#launchpad) ah, that too | 11:18 | |
| (cprov/#launchpad) sabdfl: can you look in gwyddion.gwyddion.com:8085/soyuz/distros/ubuntu/src/warty/ubuntu-artwork and give me your opinions about the suggested features ? | 11:24 | |
| kiko | sabdfl, while BradB tries to coax OS X to run an advanced secure remote login daemon (openssh), let me ask you | 11:25 |
| kiko | what's going on with Proposed? it's removed from the current schema. | 11:25 |
| kiko | I suspect good Kinnison is involved in this abduction. | 11:27 |
| === sabdfl groans at the mention of artwork | ||
| (sabdfl/#launchpad) Kinnison is indeed | 11:28 | |
| (sabdfl/#launchpad) sorry, should have kept celso in the loop on this | 11:28 | |
| (sabdfl/#launchpad) cprov: you might want to hear this | 11:28 | |
| kiko | sabdfl, sore spots, we all get them. | 11:28 |
| (sabdfl/#launchpad) there were two concepts embodied in the status of the publishing fields | 11:29 | |
| === cprov is hearing | ||
| (sabdfl/#launchpad) one was the workflow of package queueing and acceptance | 11:29 | |
| (sabdfl/#launchpad) the other was publishing | 11:29 | |
| (sabdfl/#launchpad) those are now separated | 11:29 | |
| (sabdfl/#launchpad) the publishing tables basically JUST talk about whether or not a package is published (in other words if it is currently in the distribution) | 11:29 | |
| (sabdfl/#launchpad) new packages and those related decisions are handled through the distroreleasequeue (uqueuueeueueeeueeququqq) tables | 11:30 | |
| (sabdfl/#launchpad) don't worry about representing those visually just yet | 11:30 | |
| (sabdfl/#launchpad) just stick to the published packages | 11:30 | |
| (sabdfl/#launchpad) the queues are going to be where things get interesting for soyuz | 11:31 | |
| (sabdfl/#launchpad) because that's where people will be taking decisions like "do i want this package in my derivative"? | 11:32 | |
| kiko | I see | 11:32 |
| (sabdfl/#launchpad) but it will be a month or two before we start trying to solve those problems | 11:32 | |
| kiko | cprov, for now, we should probably omit Proposed until we start tracking the releasequeue. | 11:32 |
| (sabdfl/#launchpad) our goal with soyuz is to try to get it running semi-live next week, and really-live the week after | 11:33 | |
| (cprov/#launchpad) sabdfl: it's what I'm doing now ...and I suppose the proposed property of sourcepackages comming in a near future from distroreleasequeue | 11:33 | |
| (sabdfl/#launchpad) Kinnison may use different terminology than "proposed" but yes, in principle, that's where the information will showup | 11:33 | |
| (sabdfl/#launchpad) there have been a few commits from him already so i guess you could find something in dbschema.py already | 11:34 | |
| (cprov/#launchpad) kiko: ommit it == class="dummy", I don't want to lost my direction :) | 11:34 | |
| (Kinnison/#launchpad) The dbschema changes are floating in a tla undo on my laptop | 11:34 | |
| === Kinnison will fish them out and clean them up over the w/e | ||
| (Kinnison/#launchpad) I would have had them done yesterday but for feeling like I had been run over :-) | 11:35 | |
| (Kinnison/#launchpad) but now; I've had a week of late nights and to be honest; they've all caught up with me | 11:35 | |
| === Kinnison waves and heads to bed | ||
| (Kinnison/#launchpad) g'night | 11:35 | |
| === sabdfl thinks Kinnison should listen to the beeping the big trucks make when they reverse next time | ||
| (sabdfl/#launchpad) night :-) | 11:35 | |
| (Kinnison/#launchpad) sabdfl: *grin* | 11:35 | |
| kiko | cprov, okay, but if people start using words like "polish" and "clean-up" I'm not here. :) | 11:36 |
| (cprov/#launchpad) sabdfl: what about the new feature in sourcepackage page ? | 11:36 | |
| (sabdfl/#launchpad) cprov: sorry, got distracted | 11:37 | |
| (cprov/#launchpad) kiko: aha, I'll do the same ... | 11:37 | |
| === cprov is counting XXX over than 50 !! | ||
| === sabdfl thinks cprov is man enough for it :-) | ||
| (sabdfl/#launchpad) cprov: so you are looking for new ideas or features to implement for that page? | 11:38 | |
| (cprov/#launchpad) sabdfl: those features covers some requests from Debian QA ... i think they would be integrated | 11:39 | |
| (cprov/#launchpad) sabdfl: what do you think ? the interface with Lucille/Librarian is needed anyway, the Package Tracking System is a nice feature to consider and mybe implement using ZODB | 11:41 | |
| (sabdfl/#launchpad) cprov: when you say "those features" you mean the ones in grey? | 11:41 | |
| (cprov/#launchpad) sabdfl: yes | 11:41 | |
| (sabdfl/#launchpad) they look excellent | 11:41 | |
| (sabdfl/#launchpad) we already have sourcepackagebugassignment roughly working (thanks bradb and stub) | 11:42 | |
| (sabdfl/#launchpad) so you should be able to do a bug portlet | 11:42 | |
| (cprov/#launchpad) sabdfl: great ! then we can implement at least this portlet | 11:43 | |
| (sabdfl/#launchpad) kinnison should have the librarian stuff working next week, so that takes care of another portlet | 11:43 | |
| (sabdfl/#launchpad) the package subscribers i would like in the rdbms not in zodb | 11:44 | |
| (cprov/#launchpad) ok | 11:44 | |
| (sabdfl/#launchpad) just requires a person-package-role type table | 11:44 | |
| (sabdfl/#launchpad) the email would come from the EmailAddress table via person | 11:45 | |
| (cprov/#launchpad) interesting | 11:45 | |
| (sabdfl/#launchpad) build log should come along before december too | 11:46 | |
| (cprov/#launchpad) just Staff people will be able to subscribe ? | 11:46 | |
| (sabdfl/#launchpad) cprov: no, any launchpad user | 11:46 | |
| (cprov/#launchpad) sabdfl: ok | 11:46 | |
| (sabdfl/#launchpad) in fact, if you are not logged in, we should put that email address thing there | 11:46 | |
| (sabdfl/#launchpad) and if people subscribe and we don't have them we just create a new person, with the email address, and setup the subscription | 11:47 | |
| (sabdfl/#launchpad) so they don't even have to create a proper launchpad user account with password etc | 11:47 | |
| (sabdfl/#launchpad) "lightweight subscriptions" | 11:47 | |
| (cprov/#launchpad) personally, in that case I'd preffer to restrict it to looged users then | 11:47 | |
| (sabdfl/#launchpad) the risk is just that someone will subscribe other people to things they don't want | 11:48 | |
| (sabdfl/#launchpad) we find him and break his kneecaps, end of problem :-) | 11:48 | |
| (cprov/#launchpad) aha | 11:48 | |
| (cprov/#launchpad) aren't we use confirm policy ? | 11:49 | |
| kiko | yeah.. | 11:49 |
| kiko | we should confirm the email | 11:49 |
| kiko | but we can do that automatically then | 11:49 |
| kiko | sabdfl, one hour, fifteen minutes, BradB 0 x 1 OpenSSH | 11:49 |
| === kiko chuckles | ||
| (sabdfl/#launchpad) yes, confirm the email, but still not create username / passwd for the person | 11:50 | |
| (sabdfl/#launchpad) what's the deal with openssh? | 11:51 | |
| (sabdfl/#launchpad) doesn't macosx include it? | 11:51 | |
| kiko | apparently it doesn't bind to both interfaces. | 11:51 |
| kiko | we need to set it up because jblack and arch hacking co. would like to see the effects of tla on HFS+, additionally. | 11:52 |
| kiko | he's trying to set up a router to get it to port forward. imagine that. | 11:52 |
| (cprov/#launchpad) sabdfl: so, do you mean we'll have persons in FOAF environment (just person id and EmailAddress) not able to login on LP? | 11:53 | |
| (sabdfl/#launchpad) cprov: yes, LOTS of them | 11:53 | |
| (sabdfl/#launchpad) every time we see an arch id we'll create one | 11:53 | |
| (sabdfl/#launchpad) every time we see an email address | 11:53 | |
| (cprov/#launchpad) sabdfl: in this case the People Search should be aware of it ... | 11:54 | |
| kiko | cprov, that's already true. Gina creates people left and right. | 11:54 |
| kiko | I don't even email verify because I assume the emails there are valid. | 11:54 |
| === BradB [~bradb@modemcable165.196-131-66.mc.videotron.ca] has joined #launchpad | ||
| BradB | kiko: should work now dude | 11:55 |
| (cprov/#launchpad) kiko: it's still being a problem in Gina ... Person Handling | 11:55 | |
| kiko | aha | 11:55 |
| kiko | cprov, really? | 11:56 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| kiko | cprov, what's the issue? | 11:56 |
| kiko | debonzi_ara? | 11:56 |
| debonzi | kiko, nop debonzi_still_sc :) | 11:56 |
| (sabdfl/#launchpad) cprov: yes | 11:56 | |
| (sabdfl/#launchpad) we need a "Real People" search (tm) :-) | 11:57 | |
| (cprov/#launchpad) sabdfl: one of the many improves that Soyuz need | 11:58 | |
| (sabdfl/#launchpad) we'll get there | 11:58 | |
| (sabdfl/#launchpad) once we have the piees all in production we will move a lot faster because it will be easier to see where we need to work next | 11:58 | |
| (sabdfl/#launchpad) i'm excited to get soyuz up in front of the hoary team | 11:59 | |
| (cprov/#launchpad) sabdfl: btw, we have fresh nicole DB dump on zhongshan with sfproject/fmproject | 11:59 | |
| (sabdfl/#launchpad) cprov: ok, so if you do create a project / product, you put the relevant details in those fields? cool | 11:59 | |
| (sabdfl/#launchpad) what's the filename? | 12:00 | |
| (cprov/#launchpad) sabdfl: I see same, now I have just few user requests | 12:00 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!