[12:02] Sounds like the rosetta instance that's currently being used fits into "test", so that leaves us needing to get the dev LP up and running, and then on the next test deployment, include soyuz and malone along with the next ver of rosetta === kiko-fud is now known as kiko [12:05] BradB: the Rosetta alpha server is not suitable for testing other things [12:06] BradB: it is on its own code branch, is not regularly updated, and has modifications in place so that Rosetta is the only application available [12:07] the test apps shouldn't get regularly updated [12:07] what;s the diff between the dev and the test lp? [12:08] dev is the one that gets updated every day with the latest and greatest changes (or breakages) [12:08] bradb: i don't think people work well in too many branches [12:08] right [12:08] test is the one that users test, and should actually expect to work relatively well, and change relatively infrequently. [12:08] i'd like to be moving to production as frequently as is sane [12:08] weekly, or fortnightly [12:09] so there's not really much difference between dev and test [12:09] and i don't think it's worth having it [12:09] not at this stage [12:09] when lp is huge with tens of thousands of users, yes [12:09] but right now we want it to evolve FAST [12:09] so prefer to keep it lighter weight [12:10] ok, so first step, we want testing LP that is running all three apps, right? what happens to the rosetta alpha? [12:10] dev is the one that gets updated every N minutes, not every day [12:11] I think we should update soon the rosetta alpha version with some bug fixes [12:11] the main point of the dev one is so that lu and others can see changes that developers make hour-by-hour [12:12] daf: did you merged the patchsets to fix the language_country language selection? [12:12] rather than waiting a day to see some contentious change take effect [12:13] SteveA: you can see the hour-by-hour status on your own dev box [12:13] yes [12:13] rosetta.wh.h.c [12:13] but can lu? [12:13] but we should hjust blow that db away every half hour too [12:13] oh, you mean the dev server on mawson [12:13] I thought you were proposing to do away with that [12:13] the dev box is a daily build, with data we care about enough to backup regularly [12:14] no [12:14] i'm tired, so i may not be explaining this clearly [12:14] heres what i would suggest we have: [12:15] (a) crack of the hour (rosetta.wh.h.c equivalent) that nobody uses except to poke people at a brand new feature, blows away its own code abd db every half hour [12:15] (b) dev / dogfood box, updated daily to latest db and code schema, with specific merges by the team leads to fix critical issues that come up [12:15] (c) staging server ONLY FOR THE HOUR OR TWO BEFORE A PRODUCTION UPLOAD [12:15] (d) production server [12:16] stub will focus mostly on (b) [12:16] then (c) and (d) during a push to production [12:16] we should push to production weekly or fortnightly [12:16] time based releases [12:16] use tests to ensure the whole system is always deployable [12:16] phew [12:17] how's that sound [12:17] sabdfl: I suggest you write up your proposal to the mailing list [12:17] for the benefit of those not present [12:17] sounds good to me. I imagine staging will be hit by automated tests, not people so much. [12:18] timeforbed [12:18] SteveA agreed [12:18] staging is a place to bring in a dump of the production db, run the db update scripts, run the tests, and see if it all looked to work. then repeat on production server [12:19] it's a defined process, not a place for arbitrary work [12:19] BradB: any success on mawson? [12:20] sabdfl: i stopped deploying, based on the current discussion (which started somewhat earlier) [12:20] does this proposal sound sane to you? [12:21] it makes sense [12:21] we bring up malone. we get kinnison ad cprov to bring up soyuz. [12:21] three seems like enough, but if you really want to maintain a forth, i won't object. [12:21] and when daf is ready they migrate the rosetta alpha to the dogfood platform [12:21] fourth even [12:22] r.w.h.c is on autopilot [12:22] all our work is focused on the dev [12:22] staging is a pritine environment for stub to blow away, test, blow away again [12:22] production is production [12:22] this is less fragmented than having a rosetta "test" and a malone "test" and a soyus "test" [12:23] isn't this more complicated than what i suggested of just dev, test, and live? [12:24] (one dev LP where anything goes, one test LP that should be fairly sane, and one live LP where lives hang in the balance.) [12:24] it's the same, just addin the pristine staging server we always planned on [12:24] so dogfood = dev [12:24] same proposal [12:25] keep going :-) === carlos is tired [12:26] daf: please, send me an email with a "go" to the merge if you are able to test it today so I can do the merge tomorrow morning. [12:26] good night === BradB starts build-config again, on patch-659. [12:27] I can have that up and running in however much CPU time it takes, less the appropriate Apache configuration. [12:27] cool [12:27] elmo will sort out apache config in a tick [12:28] basically, no reason not for it to be identical to the current rosetta.wh.h.c [12:28] client cert for vpn effect [12:28] we should probably get rid of the rosetta.w.h.c domain [12:28] as an alias for mawson [12:28] daf: right, just run it on mawson, on a different port? [12:29] it's purely to show off brand spanking new features [12:29] rosetta.w.h.c is the same machine as mawson.ul.o [12:29] diff port [12:29] diff db [12:29] you're thinking of rosetta.sf.o [12:29] (I suspect) [12:30] no... [12:30] that's the "alpha" [12:30] ok [12:30] https://mawson.ubuntulinux.org is exactly the same as https://rosetta.warthogs.hbd.com [12:30] rosetta.wh.h.c is the "update every half hour to crack of the minute db and code" [12:30] NOW it is [12:30] right [12:30] but? [12:30] but bradb is bringing up the dev / dogfood server on mawson too [12:31] or not? [12:31] i am [12:31] right [12:31] waiting on the build-config [12:31] sabdfl: are we going to use rosetta.w.h.c for something difference? [12:31] so... r.w.h.c is just for kicks, its just a "public" snapshot of your and my dev box [12:32] daf: please read what i wrote [12:32] the dev server will only be updated once a day [12:32] I'm saying I think we should stop using that domain [12:32] to avoid confusion [12:32] *relatively* stable [12:32] daf: agreed [12:32] ok, then we were agreed all along :) [12:32] let's call them the bleeder, the feeder, the staging and the breeder :-) === sabdfl ducks and weaves [12:33] the bleeder should take none of our time [12:34] it just happens in the background [12:34] the feeder is where we really test [12:34] it's running a relatively full db [12:37] and it's hosting guests working on rosetta beta code [12:37] and it's hosting our own launchpad bug tracking instance of malone [12:37] staging is just for stub and lifeless [12:37] production is production [12:37] ok, bleeder, feeder and breeder are terrible names :-) [12:37] but bleeder, dailydev and production might be better === debonzi_ [~debonzi@200-206-134-238.async.com.br] has joined #launchpad === debonzi_ is now known as debonzi === BradB goes to get food while build-config continues chugging === BradB is now known as BradB|food === BradB|food is now known as BradB === debonzi [~debonzi@200-206-134-238.async.com.br] has joined #launchpad === debonzi [~debonzi@200-206-134-238.async.com.br] has joined #launchpad [03:15] daf: How bad will it be if I blow away rosetta's DB on mawson? [03:27] daf or elmo_: ping [03:28] I need someone to stop rosetta so that I can create malone_alpha [03:30] BradB: Ignore what I said in email about the header rewriting - just changing the destination address in the envelope (what is happening now) is fine. That said, I'd already implemented the (optional) full header rewriting before I realised it so I'll check it in anyway. [03:33] Should I document this sort of thing on the Wiki or in a README.email ? [03:35] Mmm.... Malone is starting to look like a real system :-) [03:35] wiki or README, heads or tails, hm [03:35] I'd say a README [03:37] Mmm... I prefer that too... keep it in the same RCS. [03:37] yep [03:37] as for malone: once edit notification works (which i almost was able to wrap my brain around earlier), the 80%'ll be done. [03:39] I guess that email thing is pretty cool. Where do bounces go though? [03:40] e.g. if the envelop says From: test@bbnet.ca, and the From: header says steve@canonical.com, I hope it bounces to bbnet.ca :) [04:05] At the moment there is an Errors-To: header being set to 'nobody@example.com' along with a TODO. [04:06] BradB: I opened a bugzilla bug about configuration information via ZCML, as it should be configurable rather than hard coded. [04:11] Feel free to change the default if your mail server doesn't mind everyone spamming it :-) [04:21] We will need to do bounce processing in the future to detect expired email addresses, but I think it is ok to just check them in /dev/null for now (?) [04:23] Merge to rocketfuel@canonical.com/launchpad--devel--0: Header rewriting and email documentation (patch-670) [04:42] BradB: "rosetta's DB"? [04:54] on mawson [04:55] stub: Probably, only reason I was asking about bouncing was perhaps slight over paranoia of real emails getting spammed when tests with expired recipient addresses get run. [04:57] Yup. I think it is very valid paranoia - the email system needs to get this stuff right. [04:58] Errors-To: should cope, or the header rewriting if we want to be doubly sure. [05:43] BradB: you mean the "launchpad_test" DB on mawson? [05:44] BradB: trash that as you like [05:45] is that what you're running on? oh. [05:45] presumably i can't trash it as i like though [05:46] nope, that definitely wouldn't be a good idea ;) [05:46] but i need rosetta stopped momentarily, so that i can create malone_alpha [05:46] daf: can you stop rosetta on mawson momentarily while i do that? [05:47] oh, ok [05:47] when I say you can trash the launchpad_test DB, I mean it [05:47] it doesn't contain any critical information [05:47] other than the schema :) [05:47] the schema cna be recreated also [05:47] there's no guarantee that it'll be the same as what i'm using [05:48] there's a separate DB for the alpha, which actually should not be changed [05:48] oh, ok, well anyway, i'm creating a separate db anyway [05:48] it sucks how Postgres won't let you create new databases while other databases are being used [05:49] yeah, i don't understand why [05:49] ok, stopped [05:49] do I need to stop the Alpha also? [05:50] nope, db recreated, you should be able to restart the thing you just stopped [05:51] huh? [05:51] weird [05:51] the Rosetta alpha was using the DB [05:51] the test LP was using the DB [05:51] but I only needed to stop one of them? [05:53] *shrug* [05:54] eh, how do i start an LP app on this machine? [05:54] if I run it as the launchpad user, i get a perms error on a log file [05:55] if i run it as bradb, i can't access the db [05:56] which log file? [05:57] /home/bradb/launchpad-malone-dogfood/launchpad.log [05:57] if you want to run it as launchpad, you'll probably need to make a copy of the checkout as launchpad [05:58] how are you doing it with rosetta? [05:58] e.g. sudo -u launchpad "cp -a ~bradb/launchpad-malone-dogfood /home/launchpad; cd /home/launchpad/launchpad-malone-dogfood; make run" [05:58] actually, the existing instances are still running as me [05:58] the launchpad user doesn't have a home dir :) [05:59] I should change it, but I always have more urgent stuff to do [05:59] oh, I think the launchpad user has permissions in /srv or someplace like that [05:59] how did you auth to pgsql then? [05:59] um [05:59] if you're running rosetta as daf [05:59] I think the DB has permissions for either me or LP to access it [05:59] both databases [06:00] because you created the new DB as bradb, the launchpad user can't access it [06:00] i created it as launchpad [06:00] oh, hmm === daf shrugs [06:18] daf: can you access https://mawson.ubuntu.com:9020/malone? [06:21] no [06:21] it won't work [06:21] because it is firewalled [06:22] ah, so it was more than just apache config :) [06:22] well [06:22] Apache acts as a proxy [06:23] Apache listens to ports which are allowed through the firewall, and proxies ports which aren't [06:24] proxy on block ports? i don't follow... [06:24] s/block/blocked/ [06:26] Apache listens on port 443 [06:26] and forwards requests it recieves based on the virtual host [06:26] sure [06:27] i'll get james or thom to set me one up tomorrow then [06:29] best to send the email now === BradB sends, sleeps === BradB is now known as BradB|zzz === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [11:45] SteveA: around? === Kinnison [~dsilvers@81-178-238-108.dsl.pipex.com] has joined #launchpad [11:55] I guess I should be here too [11:57] Merge to rocketfuel@canonical.com/launchpad--devel--0: Tidying lucille ready for renaming views etc (patch-671) [11:57] thanks babe. [11:58] sabdfl: Right; I'm doing the view rename/column rename we discussed on wednesday [11:58] Kinnison: cool, thank you [11:59] sabdfl: The views I have to rename are... BinaryPackageFilesToPublish SourcePackageFilesToPublish PublishedBinaryPackageOverrides and PublishedSourcePackageOverrides [11:59] sabdfl: any suggestions on better names? [11:59] Overrides needs rethinking, and better to do it with grep and %s/x/y/ sooner rather than later [12:00] It was the field names that I thought needed to be the same as the field names they map to [12:00] binarypackagename instead of bpname [12:00] yeah; the column names I'm clear on [12:00] let's use a given name as consistently as possible [12:00] "ToPublish"? [12:02] Those views list packages pending publishing [12:02] I.E. sourcepackagepublishing and packagepublishing records which have status == PendingPublishing [12:04] sabdfl: yep [12:05] hi SteveA [12:06] SteveA: blush, forgotten what i was going to ask [12:10] Anyone mind if I rename the databases, so launchpad_dev will be what is used when you do 'make run' and all the tests use launchpad_ftest? I'm fixing tests atm, and some of them are broken because they talk to the launchpad_test database. [12:10] sabdfl: How about PendingBinaryPackagePublishings and PendingSourcePackagePublishings ? [12:10] I know Daf is for it (from email about a week ago...) [12:10] Kinnison: sounds perfect [12:11] stub: yes please! [12:11] sabdfl: and for the other two... PublishedSourcePackageLocations and PublishedBinaryPackageLocations ? [12:12] the old overrides... is it really just locations? [12:12] isn't it also quite a bit of "we want this, we don't want that"? [12:12] It's not really locations at all [12:12] it's component/section/priority [12:12] ArchiveLocations [12:12] ? [12:12] The 'want this, don't want that' choice is the filelist which is the next bit on my list of things to do [12:13] ok [12:13] So PublishedBinaryPackageArchiveLocations ? [12:13] loooong but true [12:13] Then there'll be Published{Source,Binary}PackageFileList [12:13] hold on [12:13] is there any other view of "published packages"? [12:14] if not, then the rest is spurious [12:14] if this is our primary view of the packages that are published, then just call it "PublishedSourcePackage" === Kinnison ponders [12:14] and the fact that it includes the archive lcoations is nice [12:14] the primary way to see what's published is to look at the sourcepackagepublishing and packagepublishing tables [12:15] we do need to rename the Overrides table [12:15] right [12:15] these views are collating information for lucille to generate her output [12:15] hmm.... so what tables do they pull data from? [12:15] loads [12:16] E.g. 'SourcePackageFilesToPublish' draws from... sourcepackagepublishing sourcepackagerelease sourcepackagereleasefile libraryfilealias distrorelease sourcepackage sourcepackagename and component [12:17] PublishedSourcePackage then [12:17] and PublishedBinaryPackage [12:17] cool! [12:17] simpler better faster gotta love it [12:17] These views are listing *files* not packages [12:18] (assuming the ...ToPublish views are what you're on about now) [12:18] ... i can live with it === elmo_ [~james@82.211.81.249] has joined #launchpad === Kinnison thinks we're talking at cross-purposes [12:18] give me a sec to regroup === Kinnison -> thinking room [12:18] Kinnison: you're right, sorry [12:19] PublishedSourcePackage would be for the alread-published files [12:19] which tables does that draw from? [12:19] same list? === Kinnison returns [12:23] PublishedSourcePackage draws from: SourcePackagePublishing, DistroRelease, SourcePackageRelease, SourcePackage, SourcePackageName, Component and Section [12:25] Columns it provides are: [12:26] id, distroreleasename, sourcepackagename, componentname, sectionname and distribution [12:26] well; theoretically it provides sourcepackagename.name [12:26] What should I call that column? [12:32] sourcepackagenamename ? === Kinnison pokes sabdfl [12:51] Kinnison: pong [12:51] sabdfl: ^^^^^^^^^^ [12:51] just sourcepackagename [12:51] even though that has connotations of being a foreign key onto the sourcepackagename table? [12:52] a bit of a fiddle, that one [12:52] sourcepackagenamereally ;-) [12:52] so PublishedSourcePackage i'm happy with [12:52] I don't mind any of: sourcepackagename sourcepackagenamename or "sourcepackagename.name" [12:53] sourcepackagename [12:53] although sqlobject might barf at the latter [12:53] okay [12:53] what about the name of the other views? [12:53] Pending.? [12:53] PendingSourcePackageFile [12:53] PendingBinaryPackageFile [12:53] ? [12:54] Kinnison: works for me [12:54] Cool [12:54] I'll do that; and then I'll do PublishedSourcePackageFile and PublishedBinaryPackageFile for the new views I need to do too [12:55] and rename Override? [12:55] Override? [12:55] launchpad_dsilvers=> \d override [12:55] Did not find any relation named "override". [12:55] We're renaming PublishedBinaryPackageOverrides to just PublishedBinaryPackage I thought we agreed that up there somewhere? [12:58] Kinnison: yes, that's the view, right? [12:58] yep [12:58] there are no 'override' tables [12:58] but there is an underlying Override table somewhere [12:58] oh [12:58] NupNup :-) [12:58] The overrides *are* the publishing records :-) [12:58] where do you store the info about how the distro wants to publish a given package? [12:58] "when the NEXT package foo comes in, publish it in component/section/priority" [12:59] that's what I understood an override to be [12:59] when foo 1.0-2 comes in, you copy the publishing records from 1.0-1 pointing them at the new package [12:59] Or at least; that's how I was going to do it [01:00] Since that's the obvious way; then if you don't have enough context to do that; the package is clearly NEW and should be queued in the NEW queue instead === Kinnison -> lunch [02:11] Kinnison: i think we need an explicit policy table. when a new package comes in you look at the policy table to decide what to do with it [02:11] we can start with a straight line-per-package approach like the debian overrides system [02:11] but later it needs to be "accept packages that are in this bundle" (gnome / kde / etc) [02:11] and "reject packages that are in that bundle (perl / dev / etc) [02:12] so that derivatives get to shape their distro at a higher level than package-by-package. [02:23] SteveA: kamion just reminded me what i wanted to ask [02:23] wiki / zwiki decision is now urgent [02:23] what's your view on the best course of action? [02:26] What decision exactly do we need to make? Whether to use ZWiki, integrated with the UL plone site, or to use moinmoin not so integrated? [02:36] It seems that there are no tables used on wiki.ubuntu.com === BradB|zzz is now known as BradB [02:38] I did wget -m http://wiki.ubuntu.com/ and grepped the results case-insensitively for " So, we can use ZWiki, and move content across from wiki.ubuntu.com [02:42] elmo_: ping [02:44] BradB: [02:44] SteveA: ?? [02:44] stevea: check out hardware support .. [02:45] elmo_: Two things: [02:46] 1: Will you have a chance to do the Apache config for Malone soonish? [02:46] 2. Do you care if I create another postgres superuser on mawson? (bradb) [02:47] 2: yes, run stuff as launchpad please [02:47] There's a problem with that. [02:47] services should not be tied to one user's account [02:47] why? [02:47] elmo_: ah -- wget didn't get second level pages... [02:48] The problem is that the zope instance needs to write logfiles. the launchpad user can't write logfiles in ~bradb. [02:48] Unless I'm meant to have another dir under /srv [02:51] yeah, create something under /srv [02:52] hmm, there's meant to be a /srv/launchpad or something - if there isn't just let me know [02:52] have you guys agreed on the url stuff then? [02:52] yep, i put it in an email to you guys (i.e. the admins) last night [02:53] SteveA: How recent is lib/canonical/functional.py ? I think it has superceeded lib/canonical/tests/functional.py but I'm not sure. [02:53] yeah, I know, just wanted to make sure it's final [02:53] elmo_: afaic, yes :) [02:54] oh, sorry I should have read that mail [02:54] malone.w.h.c doesn't work - there's like 24 hour+ turn around time on that DNS [02:54] if you pick *.ul.o or *.u.c or *.c.c etc., I can do it.. otherwise.. === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [02:55] yeah, like i say, i'm not picky. m.u.c would be fine. [02:55] SteveA: ok, and the moin support is working, and installed in our copy of zwiki on www.ul.o? [02:56] elmo_, SteveA: the zwiki supports native html for tables [02:56] elmo_: can you create a dir /srv/malone? /srv/rosetta.* doesn't seem like an appropriate place for it. [02:56] if necessary we can munge them over as html tables directly [02:56] BradB: morning! [02:56] hi :) [02:56] sabdfl: that's super user unfriendly for editing [02:57] sabdfl: okay for malone.u.c [02:57] +? [02:57] bradb: re /malone is this for the dev server? it will host ALL the lp componets though [02:57] stub: lib/canonical/functional.py is the newest and best [02:57] elmo_: it's much better for searhcing [02:58] i think we are going to put together a dedicated Plone class for the hardware db [02:58] sabdfl: so launchpad.ubuntu.com? [02:58] BradB: perfect! [02:59] elmo_: Can you make that dir /srv/launchpad instead please? :) [03:00] tramps. this is why I asked if you guys were done "discussing" :P [03:01] i had got the impression that i was just putting up a malone df, but i guess not :) [03:01] sabdfl: the latest released ZWiki is 0.35.0. This is not installed in our plone sites. It has support for moinmoin pages without tables. The preview mode was added one week later, and has been improved since. [03:01] There will be a new wiki release on 1 November containing the preview mode, and any further work done on moinmoin markup. [03:01] If we want to get the preview mode before then, we'll need to check zwiki out of its DARCS repository. [03:02] SteveA: how extensive are the tables in hte hardware section [03:02] what client cert do we want protecting this? the testers one? [03:02] or a 'warthogs' one? [03:02] elmo_ accept either, allow testers into /rosetta but for everything else require warthogs [03:02] sabdfl: there are 11 hardware pages. most have a table on them. [03:03] good thing I checked if there was already a database called "launchpad_alpha" :) === BradB uses one called launchpad_dogfood instead [03:03] I could convert the tables to restructured text format in under 30 minutes in vim [03:04] SteveA: is the ReST table format efficient? moin is terrible [03:04] it is an improvement over moin, but still a bit awkward. Here's an example: [03:04] http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables [03:05] I'm looking at the "simple table" format [03:05] elmo_: Can you stop rosetta too please so that it doesn't hang when I try to create the DB? [03:06] "stop rosetta" ? [03:06] you mean UP it? [03:07] kill it [03:07] daf's running it on mawson [03:07] why would rosetta hang? [03:07] it uses a different db, doesn't it? [03:07] rosetta doesn't hang [03:07] postgres' fucked - I'm going to try UP-ing rosetta to see if it helps [03:07] why would your stuff hang on account of rosetta running? [03:07] me trying to create launchpad_dogfood hangs, because "another process is accessing the database" [03:07] err, UP-ing mawson [03:08] this is why we changed the machine name isn't it :) [03:08] so postgres doesn't like you doing stuff to the databases when a process is using a different database? [03:08] that sucks [03:08] indeed [03:08] makes me want to run several different postgreses [03:09] it seems to me that there must just be a problem with the pgsql config on mawson [03:09] no, you tramps, it's a bug [03:09] maybe it's fixed in 8.0b3? [03:10] sabdfl: I think HTML tables are the way to go, unless people generally use a decent editor to edit them. [03:10] we're not using beta's in production [03:10] and changing major versions between production and devel is a reciepe for madness [03:10] yeah, wasn't suggesting that, but optimistically looking towards the 8.x series :) [03:10] elmo_ are we runing 7.4.5? [03:11] yeah, 7.4.5-3 [03:11] let me UP the box first [03:11] mawson going down.. === BradB logged out [03:16] stevea: [03:16] (13:18:07) Kamion: kind of impressed that the wiki handles Korean totally seamlessly [03:16] (13:21:17) lamont: thom: you're welcome [03:16] (13:22:09) sabdfl: Kamion: i'm keen to move to the Zwiki which is a little more restrictive but *should* do the same [03:16] will zwiki handle i18n? [03:17] SteveA: the ReST table format seems very sane [03:17] if we can get kupu working nicely for the wiki then html might be fine [03:17] but let's not rush into that [03:17] SteveA: think we can big-bang the content across in a morning? === debonzi [~debonzi@200.158.100.251] has joined #launchpad [03:18] i was thinking to move it over a page at a time, and lock the moin-wiki page once it had moved [03:18] There's a discussion on #zwiki about hebrew. I just asked about the details. [03:19] the problem with the ReST table format is that if you add a row with a column that is longer than all those that currently exist, [03:19] in the simple format, you need to go through and make every row have a longer column [03:20] In the full table format, you can use wrapped text [03:20] so, although it is trickier to set up, it is easier to maintain [03:21] right, mawson's back up [03:21] please try again, and if it still hangs, yell [03:21] limi is very negative about kupu -- he says it works only in a very few browsers. [03:21] its ancestor, epoz, works in most browsers. [03:22] but, I think epoz is not integrated into zwiki, whereas kupu is [03:23] sabdfl: Do we want to restart whatever Rosetta daf had running on mawson, or is this new LP dogfood thing enough? [03:24] the rosetta alpha testers will be a bit upset, I guess [03:24] daf should be around any minute [03:24] I have a meeting with him and carlos in 30 minutes [03:28] marius says: [03:28] wiki question mgedmin: how easy is it to put non-ascii characters into a ReST zwiki page? [03:28] easy [03:28] well, depends [03:28] if it is Zope 2.7, you have to edit zope.conf [03:28] and specify rest-input-encoding utf-8 [03:28] and also rest-output-encoding utf-8 [03:29] elmo_: Bad Gateway when trying to access launchpad.ubuntu.com; is it being forwarded correctly to 9020? [03:30] here is a ReST page on zwiki.org: http://zwiki.org/SandBox There are some odd characters in it. Someone who uses non-ascii characters can try adding a comment. [03:30] no, I hadn't finished [03:30] try again now [03:30] SteveA: agree on kupu. let's use ReST, Moin, HTML for now [03:30] elmo_: looks good, thanks, just doing some quick sanity checks now. [03:31] I gave up on kupu - epoz got overengineered and became urgh... [03:31] erm.... kupu got overengineered. epoz is cool. [03:32] bradb: the old server should still continue... it's the half-hourly snapshot on a db that gets blown away thing [03:32] it should totally run on autopilot [03:32] on separate ports [03:32] with client cert restricted to warthogs only [03:33] SteveA: korean appears to be working fine there [03:33] SteveA: ok, when can we big-bang the wiki across? [03:34] and could you keep an eye on zwiki, and make sure we run the latest release? [03:34] Brad needs to tweak zope.conf, and install the latest ZWiki (perhaps latest from DARCS, so we get the improvements to preview mode) [03:35] yes we definitely need preview mode [03:36] Then we should check that we can enter all manner of characters into a test page on ul.org [03:37] We probably want to set up zwiki so that people cannot use DTML pages or other pages with server-side scripting in them. [03:38] I'm not sure how to do that when zwiki is mixed in with plone [03:38] it would be nice if we can convert all the moin wiki markup to ReST. [03:39] SteveA: i'd rather leave moin available as an option [03:39] that way, there will be just one wiki markup in use. [03:39] the guys are screaming along making lots of changes to the wiki [03:39] and i don't want to impose a change unless we have to [03:39] happy to say "sorry, tables aren't supported yet in the new wiki" [03:39] but keep the disruption to a minimum [03:39] so, pages with tables will use ReST? [03:40] or html [03:40] k [03:40] whatever the authoer prefers [03:40] the rest remain in moin [03:40] can we lock a page in moin? [03:41] I don't know [03:42] there's always "soft locking": "THIS PAGE HAS BEEN MOVED TO http://ubuntulinux.org/wiki/whatever" === SteveA uses darcs to get the latest zwiki [03:46] it doesn't look as scary as tla [03:47] it doesn't say very much. just "copying patches..." then lots of ........ [03:55] any objections to me blowing away launchpad_test on mawson? [03:55] (well, wreaking havoc on it, anyway) [03:56] it's trashable [03:57] BradB: https://chinstrap.warthogs.hbd.com/~stevea/zwiki-2004-10-22.tar.gz [03:57] that's ZWiki from today [03:57] I haven't run it. I just thought I'd save you the trouble of installing darcs on a mac :-) [04:00] deploying lp is as painful as a very painful thing [04:00] BradB: can we redecorate pages in our plone site that are below /wiki/ ? [04:00] get rid of the right-hand bars? [04:01] BradB: what's painful? Is it retrieving it from arch? [04:01] i keep getting: [04:01] __ [04:01] for row in self.table.select(): [04:01] File "/srv/launchpad.ubuntu.com/launchpad-dogfood/lib/sqlobject/main.py", line 1198, in __iter__ [04:01] return conn.iterSelect(self) [04:01] File "/srv/launchpad.ubuntu.com/launchpad-dogfood/lib/sqlobject/dbconnection.py", line 507, in iterSelect [04:01] select, keepConnection=True)) [04:01] TypeError: iteration over non-sequence [04:01] when trying to access basically any screen that hits the db [04:02] (i've even tried running directly from launchpad_test, just in case trying to run off launchpad_dogfood was config'd incorrectly) [04:03] BradB: i've been seeing that on rosetta.wh.hbd.com for a while [04:03] I wonder if postgres on that box isn't *&^*&^'d [04:03] http://paste.husk.org/1840 is the config I built from [04:04] maybe i'm not using the right version of something [04:04] it seems to me that the problem is that the app is failing to connect to the db, but that's a bit of a guess, because the error message is computer science [04:05] BradB: can you do a psql launchpad_test and see that it looks ok? [04:05] it does [04:09] BradB: wrong sqlobject version [04:09] i thought that might be the case [04:09] you want: ./launchpad-malone-dogfood/sourcecode/sqlobject rocketfuel@canonical.com/sqlobject--test--0.6 [04:09] i thought rocketfuel@canonical.com/sqlobject--test--0.5.1 was the misnamed 0.6 we had though [04:10] also, i don't think we should call it launchpad-malone-dogfood [04:10] it isn't [04:10] just call it launchpad-dev [04:10] that was just on a local build-config [04:10] or launchpad-dogfood [04:10] BradB: my config has 0.6 [04:10] it is launchpad-dogfood already :) [04:10] ok [04:11] try the updated sqlobject [04:11] that would also explain why rosetta.w.h.c was being b0rked [04:11] daf used the same version? [04:13] no, I think the development server I was running has 0.6 [04:13] daf: t was getting exactly the same error for me [04:13] iterating over a non-sequence crap [04:14] the upgrade fixed it [04:14] great [04:15] thanks for pointing out the prob [04:15] daf, please fix the other one [04:15] fyi, rosetta progress meeting starting on #canonical-meeting [04:15] ~/launchpad-devel/launchpad/sourcecode/sqlobject$ tla tree-version [04:15] rocketfuel@canonical.com/sqlobject--test--0.6 [04:15] email notification works too, but it's still always coming to me, which may be a good thing until the next version is deployed with stub's email changes [04:19] hm, i guess a clean way of starting this as a daemon would be nice :) [04:20] zdeamon? [04:20] bin/launchpadctl start [04:23] We'll also need to be able to change the DB name in exactly one place, if we're to have any hope of running this thing on four different databases (which I'm assuming will all be named differently.) [04:23] should be a config option in launchpad.conf [04:23] we'll need to do a similar thing for the zodb to use [04:24] Merge to rocketfuel@canonical.com/launchpad--devel--0: Rename databases. Implement new test harnesses. Port tests to new harnesses where appropriate. Fix all unit and functional tests. 'make test' runs without errors. (patch-672) [04:31] BradB: At the moment it should be possible to stick .zcml files in the override-includes directory that, well, overrides the default settings. This might be a way to keep the dogfood config in an easy-to-upgrade fashion [04:33] SteveA: You want we should have test_on_merge.py do a full test run now? [04:33] I think we should use a launchpad.conf.in file, with the default settings, and put all settings that could be changed on a deployment into launchpad.conf. [04:34] there's a bit of work required to put settings we need into launchpad.conf, though [04:34] stub: do all tests pass right now? If so, great, let's do it. === stub gestures up the screen to patc-672 [04:36] cool. let's go for it [04:36] BradB: how does plone handle internationalizing content? [04:36] sabdfl: have any plans been discussed about internationalizing the ul.org website? [04:38] SteveA: yeah, but i don't have an experience i18n'ing content [04:38] s/an/any/ [04:40] SteveA, sabdfl: Should I read my scrollback right now about zwiki et al. or focus on getting edit notification working in malone (and deploying stub's new email machinery?) [04:40] SteveA: LinguaPlone is the standard product there, last I checked. [04:41] limi develop{ed,s} it [04:41] BradB: I'll send a mail about zwiki [04:41] ok [04:42] I'd like you to upgrade zwiki and zope.conf on ubuntulinux.org before monday UK time [04:42] so we can get to work moving pages across on monday [04:42] ok [04:42] thanks [04:43] brb [04:43] BradB & # brekkie run === Kinnison -> tea and cakes [04:58] malone question: how are the scripts to pull open bugs out of bugzilla and into malone looking? [04:58] we'll need to use those to do dogfooding of malone [05:02] hmm.. where did all those tests with hardcoded launchpad_test come from? They wern't there a minute ago, I swear! [05:10] SteveA: i'd love to i18n the web site but will only go with what plone standard provides [05:10] SteveA, stub: i don't know about auto-pulling open bugs from bugzilla [05:10] let's ask limi's advice on what approach to look at next week [05:11] we currently have code that will update the status of a remote bugzilla bug when it changes [05:11] but not to automatically find new bugs over there and create them in maone [05:11] i suggest we just transition to malone by turning off new bug creation in bugzilla [05:12] I'm thinking more of pulling open launchpad bugs out of the launchpad bugzilla [05:12] people can wrap up old bugs in bugzilla and create new ones in maone [05:12] and putting them into malone [05:12] for critical bugs we can create them in malone and put remove watches on them in the bugzilla [05:13] (14:22:02) limi: * patching for this revision (alexander.limi@canonical.com--2004/launchpad--devel2--0--patch-20) [05:13] (14:22:05) limi: unable to open file "./.arch-inventory" (Permission denied) [05:13] (14:22:07) limi: PANIC: I/O error [05:13] (14:22:18) limi: :] [05:13] anybody seen this before? [05:14] I've seen panics from tla, but not one about .arch-inventory === debonzi is now known as debonzi|lunch [05:24] ls -l ./.arch-inventory [05:39] (16:33:03) limi: $ ls -al ./.arch-inventory [05:39] (16:33:04) limi: -rw-r--r-- 1 limi limi 98 19 Oct 11:44 ./.arch-inventory [05:42] New bug 2131 for Launchpad/Launchpad: Launchpad should have a graceful way to startup in daemon mode [05:42] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2131 [05:46] New bug 2132 for Launchpad/Rosetta: internationalize Rosetta [05:46] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2132 [05:48] New bug 2133 for Launchpad/Launchpad: Launchpad database must be configurable in exactly one place [05:48] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2133 [05:48] Merge to rocketfuel@canonical.com/launchpad--devel--0: View renaming for lucille's publishing stuff (patch-673) [05:48] sabdfl: hmph, I wonder what ./.arch-invetory it's referring to then. [05:49] s/invetory/inventory/ [05:50] dilys: you rock === debonzi|lunch is now known as debonzi [05:53] Merge to rocketfuel@canonical.com/launchpad--devel--0: Merged my BIG change to split pomsgsets and potmsgsets into their own tables (Closese: #2083) (patch-674) [06:00] New bug 2134 for Launchpad/Rosetta: Create and migrate the user languages preferences to a table PersonLanguage [06:00] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2134 [06:05] BradB, ping [06:06] Bug 2037 resolved: main search form should search products as well as projects [06:06] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2037 [06:08] debonzi: pong [06:10] hi BradB I saw there is a bug in SourcePackage that is MultipleJoin... Is there a easy way to get from the attribute bugs only the ones with BugSeverity.CRITICAL for example? [06:10] s/bug/bugs [06:11] nope, not that i'm aware of [06:12] uhmmm... so I think I need a new query and a SourcePackageBugAssignment.select [06:13] that or a list comp [06:13] BradB, what you mean with list comp? some python code to get them? [06:14] [c for c in sp.bugs if c.severity == CRITICAL] [06:14] s/c/b/, but yeah [06:15] right.. it is nice because whould avoid and circular import since SourcePackageBugAssignment already imports SourcePackage, but don't you think it is too expensive? [06:15] s/and/an [06:16] depends on what you're using it for [06:17] are you just doing a search page for all critical bugs for one SP? if so, then the solution is almost written in the question. :) [06:17] right but I don't know precise how big can be a SourcePackageBugAssignment for a given SourcePackage of course.. do you have and ideia [06:17] yes.. thats what I whould like to do [06:18] Then just do a simple select on SourcePackageBugAssignment. :) [06:19] that way you needn't add any special methods to anything [06:23] Bug 2083 resolved: Do the split of .pot and .po records from POMsgSet to two different tables [06:23] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2083 [06:23] uhm? why do you say I don't need? let me explain I little better what I want: I whould like to show some bug informations in the sourcepackage page. so, on the template I have context/sourcepackage/bugs and I can use it to should for example the total number of bugs for that sourcepackage. But I also want to show the number of critical bugs [06:24] so, I beliave I need something like context/sourcepackage/bugscritical [06:24] for that I think I do need to write a new method inside SourcePackge SQLObject. [06:24] I am wrong somewhere? [06:25] debonzi: there's a good idea in there somewhere [06:25] i would rather do it like this [06:26] we can write a function SourcePackage.bugs(severity_min=None, status=dbschema.BugStatus.OPEN) [06:26] and expose that partly through SourcePackageView [06:27] the important thing to me is that it be a general, well written function [06:27] that will report on bugs associated with the source package [06:28] and cann be constrained in interesting ways, like by status and severity and priority level [06:30] debonzi: I had the impression (as per above) that you were just doing a search page and trying to show critical bugs for an SP, in which case self.critical_bugs = SourcePackageBugAssignment.select(SourcePackageBugAssignment.q.sourcepackageID == 1, ...) would have been the simplest way to do it. Sounds like you're doing something slightly more complex though. === debonzi thinks about === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [06:35] BradB, sabdfl Im thinking about it. If I have more questions Ill ask again.. thanks :) === cprov [~cprov@200.158.100.251] has joined #launchpad [06:50] bradb: is it possible to turn off the right hand portlets for pages under /wiki/ on our plone site? [06:52] I'll take a quick look now to see if what I think might work actually does. [06:54] sabdfl: yep, it worked [06:55] i'm betting the old one's still cached at the real URL though [06:55] oh no, seems to work properly event at the real URL for me [06:55] sabdfl: does that look ok then? [06:58] SteveA: (#zope3-dev) is ignoring the class directive for an editform a bug then? [07:02] BradB: shiny! [07:02] excellent thanks [07:02] i'm going to get some of our wiki extraordinaires to play with the zwiki there [07:03] Merge to rocketfuel@canonical.com/launchpad--devel--0: Make merge check use full test suite (patch-675) [07:04] sure [07:11] yowser. chug chug. test suite just grew [07:11] ah, dilys [07:11] thanks === BradB is now known as BradB|lunch === kiko is now known as kiko-fud [08:24] !lilo:*! Of possible interest, a recently created channel: #accounting, a support channel for small not-for-profit entities.... stop by if you have skills and want to answer questions, or if you have questions and need answers :) [08:59] sabdfl, I was thinking in the way you sugested for the implementation I need and looking at the already exists but I still can't see a good way to solve my "problem". When you say SourcePackage.bugs(...) what do you mean with it? A classmethod inside SourcePackage? [09:03] SourcePackage already have and attribute called bugs that since I have a SourcePackage.SelectResult all the rows in it have a list (bug attribute) with all its bugs. [09:03] s/(bug attribute)/(bugs attribute) [09:04] given an instance of SourcePackage you want to get a list of relevant bugs assigned to that source pacakge. [09:04] you could have different functions SourcePackage.criticalBugs and Sourcepackage.closedBugs and Sourcepackage.openBugs etc [09:04] or just have a single function to which you can pass some good methods [09:05] like SourcePackage.getBugs(minSeverity=HIGH, status=OPEN) [09:05] Right... that is ok.. [09:06] but I whould like to use the bugs attribute that I already have to get this things.. but seems that there is no way [09:07] try to write a new method. [09:07] ultimately it will use Bug.select(querystring) [09:07] use the arguments to the method to build a useful querystring === sabdfl hs to leave shortly [09:07] I whould like to avoid one sql query for each "kind" of bug since I already have a list with all of them [09:08] well, you could also have one function which gets all the bugs once [09:08] then other functions which run over that and get subsets [09:08] based on your criteria [09:08] anyhow, got to go, have a good weekend! [09:08] sabdfl, ok thanks :) === BradB|lunch is now known as BradB === sabdfl is now known as sabdfl|out [09:40] stub: have you thought about pushing your CC change upstream? [10:16] i've got a foo. foo is an sqlobject, which has one attrib, x. foo.x == 1. how do i capture foo's state into an object such that when i go foo.x = 2, i can look at old_foo.x and see that it was 1? [10:16] oh, i thought of something === BradB tries [10:24] woo!