[00:07] <thumper> I wish I knew how big lp:mysql-server was
[00:07] <thumper> I'm streaming it down now with no indication of % complete
[00:09] <mwhudson> it's probably about 700 megs
[00:10] <lifeless> its big
[00:11] <thumper> lifeless: streaming from LP though gets upto 200kb/s
[00:12] <thumper> lifeless: which I think is close to saturating my down pipe
[00:12] <thumper> ah
[00:12] <thumper> no it isn't
[00:12] <thumper> but it is better than it used to be :)
[00:13] <lifeless> I'm encouraging the sun folk to move to 2a
[00:14] <lifeless> once drizzle do I think jay will get the message soon enough :)
[00:19] <wgrant> Should LP's mirrored copies of branches be repacked now that LP has bzr 2.0.0?
[00:19] <wgrant> (db-)devel aren't too badly packed, but they're worse than they could be.
[00:20] <thumper> wgrant: probably
[00:21]  * thumper wants to talk to a foundations person
[00:21] <thumper> badly
[00:21] <thumper> rockstar: I just used JS to update some bug statuses, went to the listing and it showed me the old ones
[00:21] <wgrant> That's right.
[00:21] <thumper> rockstar: this is the same behaviour you are seeing on the page where it doesn't come back correctly
[00:21] <wgrant> Webservice POSTs aren't enough to blacklist your session from the slave.
[00:22] <thumper> WTF not?
[00:22] <wgrant> Is bug.
[00:22] <thumper> wgrant: do you know the bug number?
[00:22] <wgrant> Hunting.
[00:22] <rockstar> wgrant, bug plz
[00:22] <rockstar> :)
[00:22] <rockstar> thumper, this is a good fing.  It means that my javascript doesn't suck so bad.
[00:23] <rockstar> (It still sucks though)
[00:24] <thumper> rockstar: yes
[00:27] <wgrant> Hmmm. Can't find it.
[00:29] <mwhudson> haha
[00:29] <mwhudson> # Launchpad virtual domains. This should be on one line.
[00:29] <mwhudson> 127.0.0.88      launchpad.dev ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname}
[00:29] <mwhudson> # Launchpad virtual domains. This should be on one line.
[00:29] <mwhudson> 127.0.0.88      launchpad.dev ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname}
[00:29] <mwhudson> in /etc/hosts
[00:29] <mwhudson> i think my script isn't quite right...
[00:34] <wgrant> bug #351724 is all I can find.
[00:34] <mup> Bug #351724: Inline editing of bug summary is overwritten by edit of description <Launchpad Foundations:Confirmed> <https://launchpad.net/bugs/351724>
[00:39] <wgrant> How do I object to a merge proposal?
[00:40] <wgrant> The approved fix for bug #435628 is bad.
[00:40] <mup> Bug #435628: Attempting to file a bug on an Ubuntu source packages OOPSes when bug filing is disabled <oops> <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/435628>
[00:41] <mwhudson> wgrant: you can "add a review" i think?
[00:42] <wgrant> mwhudson: Ah, so I can. I was looking for the ghost reviewer that used to be there. But anyway, not much point doing that now it's approved.
[00:42] <mwhudson> wgrant: well, telling people somehow would be good
[00:47] <wgrant> There aren't going to be bugs people around in time for the re-roll, are there?
[00:49] <wgrant> deryck: Unlikely ping about the above.
[00:50] <deryck> hey
[00:51] <deryck> wgrant, I've got a fix for that already.  it got rc approval today.
[00:51] <wgrant> deryck: Ah, great. Can you check my comment on https://code.edge.launchpad.net/~deryck/launchpad/filebug-redirect-package-oops-435628/+merge/12366?
[00:51] <deryck> so it will make the reroll
[00:51] <wgrant> Yes, but the fix is bad.
[00:51]  * deryck looks
[00:53] <deryck> wgrant, ah, ok.  I can work up a better fix tonight then.
[00:53] <wgrant> deryck: Great, thanks.
[00:54] <wgrant> (permissions-wise, the bug supervisor of a source package is already the bug supervisor of the distribution)
[00:55] <deryck> I thought the bug was caused because source packages didn't have bug supervisor.
[00:55] <wgrant> It is.
[00:56] <wgrant> The bug supervisor is inherited from the distribution.
[00:56] <wgrant> So it's not a separate attribute.
[00:56] <deryck> right
[00:57] <deryck> I was confused by what you meant with "is already the bug supervisor."
[00:58] <wgrant> Sorry, I was rather unclear.
[00:58] <deryck> wgrant, I'll be afk for a bit longer but then will work up a better fix.  hopefully bac will be around to confirm for rc again.
[00:58] <wgrant> deryck: Thanks.
[01:00] <deryck> np
[01:17] <mwhudson> thumper: wanna review https://code.edge.launchpad.net/~mwhudson/launchpad/public-only-update-sourcecode/+merge/12394 ?
[01:17] <mwhudson> or anyone else, of course
[02:04] <gary_poster> sidnei: pong, but have to go away soon
[02:24] <thumper> stub: morning
[02:24] <thumper> stub: https://code.edge.launchpad.net/~thumper/launchpad/permission-fail/+merge/12329
[02:25] <thumper> stub: not landing as an RC, but has a db permission that needs to be set
[02:28] <stub> np
[02:30] <stub> thumper: Permissions all granted on production
[02:31] <thumper> stub: ta
[02:37]  * mwhudson (a) back from lunch (b) happy to have figured out https://bugs.edge.launchpad.net/launchpad-code/+bug/435783
[02:37] <mup> Bug #435783: branch appears in loggerhead but can't be read over http <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/435783>
[02:42] <thumper> mwhudson: bug 385032 is done right?
[02:42] <mup> Bug #385032: branchupgradejob should not upgrade in place <Launchpad Bazaar Integration:Triaged by mwhudson> <https://launchpad.net/bugs/385032>
[02:42] <thumper> damn
[02:42] <thumper> wrong one
[02:42] <thumper> bug 371484
[02:42] <mup> Bug #371484: branch puller should be a branch job <branch-puller> <Launchpad Bazaar Integration:Triaged by mwhudson> <https://launchpad.net/bugs/371484>
[02:42] <mwhudson> thumper: no
[02:42] <thumper> poo
[02:43] <thumper> push it off or unschedule?
[02:43] <thumper> tech-debt?
[02:43] <mwhudson> thumper: it uses job-type scheduling, but it's not a row in the BranchJob table yet
[02:43] <mwhudson> thumper: let's do it, it shouldn't be very hard
[02:44] <mwhudson> (famous last words, ofc)
[02:44] <thumper> ok, I'll add to 3.1.10
[02:54] <thumper> mwhudson: look at the job oops report
[02:54] <thumper> mwhudson: three different issues to do with diffstat generation
[02:55] <thumper> mwhudson: I'm going to create a branch to catch and log, but continue
[02:55] <thumper> mwhudson: since we don't do anything with the diffstat just yet
[02:59] <mwhudson> thumper: hm, i don't have the oops report
[03:00]  * mwhudson stabs thunderbird in the head
[03:00] <thumper> https://devpad.canonical.com/~lpqateam/oops-summaries/jobs-2009-09-24.html
[04:53] <jtv> mwhudson: indeed, working with staging-local branches worked near-perfectly for me yesterday.  Thanks.
[04:54] <mwhudson> jtv: glad to hear it
[04:54] <jtv> Revision pages kicked me back to the front page, but I imagine that's because revisions don't normally live on staging and there'd be trouble.
[04:55] <jtv> mwhudson: the other thing we've been looking at that you may know more about is the Job/BranchJob system.  It seems to have been designed with all sorts of heartbeat monitoring and watchdogging in mind, but none of it is implemented.
[04:55] <mwhudson> jtv: yes, i think that's a fair description
[04:55] <mwhudson> jtv: abentley knows most about this code fwiw
[04:56] <mwhudson> jtv: did you see that thumper found the bug that was probably causing the seemingly forever running Jobs?
[04:57] <jtv> No!?
[04:57] <jtv> what was the bug that was probably causing the seemingly forever running jobs?
[04:57] <mwhudson> jtv: this bug https://bugs.edge.launchpad.net/rosetta/+bug/434192
[04:57] <mup> Bug #434192: bzr imports are sometimes stuck in 'running' state <Launchpad Translations:Triaged by jtv> <https://launchpad.net/bugs/434192>
[04:58] <jtv> That's the problem description... finding that isn't very impressive.  Hasn't he found the cause?
[04:59] <mwhudson> yes, that's what i was trying to say
[04:59] <mwhudson> jtv: r8523 of db-devel should fix it
[04:59] <jtv> !
[04:59] <mwhudson> jtv: basically, when a job failed, it wasn't properly marked as failed in the database
[05:00] <mwhudson> because we went "transaction.abort(); mark job failed; raise"
[05:00] <mwhudson> not "transaction.abort(); mark job failed; transaction.commit(); raise"
[05:00] <jtv> Damn, I checked for that and found nothing wrong.
[05:01] <jtv> Because the exception was caught one level higher, I thought,
[05:01] <jtv> and then the transaction would be committed either at the beginning of the next iteration or when the script completed.
[05:01] <mwhudson> well, maybe we misdiagnosed
[05:01] <mwhudson> maybe it only happens when two jobs in a row fail or something?
[05:02] <jtv> No, because the next commit happens before the next job starts running.
[05:02] <jtv> Maybe if somehow the end-of-script commit doesn't happen
[05:02] <jtv> Or the exception is not one that's caught, though IIRC the catching clause cast a pretty wide net.
[05:03] <jtv> (Even SystemError and break)
[05:03] <mwhudson> huh yeah
[05:03] <thumper> jtv: the transaction isn't committed when the script ends
[05:04] <thumper> jtv: it is aborted
[05:04] <thumper> jtv: hence the failure to record the last one
[05:04] <jtv> ahhhh
[05:04] <mwhudson> jtv: what was happening in our case was that the oops reporting itself was blowing up, because of a lack of config values
[05:04] <mwhudson> ... ending the script, then what thumper said took over
[05:04] <jtv> ...and no place for that error to go.  Neat.
[05:05] <jtv> I considered that, but thought people would have noticed.  -1 for second-guessing.
[05:06] <mwhudson> the job stuff isn't completely battle hardened yet
[05:06] <mwhudson> i guess we really should use it for the puller, that seems to be particularly good at shaking out race conditions
[05:07] <jtv> I noticed that CodeImportJob did implement all of the watchdog stuff, completely separate from Job.
[05:07] <jtv> Another thing about Job is it could still die from a kill, and there'd be nothing to GC the dead "running" job.
[05:07] <mwhudson> the code import stuff precedes and somewhat inspired the job stuff
[05:07] <mwhudson> and is rather more battle hardened
[05:10] <jtv> Very important not to count on the original process getting things into their final state.  I expected to find some kind of GC job for Jobs/BranchJobs.
[05:17]  * stub wonders if it is possible to install an atexit handler that bitches if the script terminates without an explicit transaction.commit() or transaction.abort()
[05:19] <stub> Or just hack it into LaunchpadScript.... I don't think you can tell though...
[05:31] <jtv> stub: wouldn't it lead to people slapping unnecessary or half-baked commits and aborts onto difficult code paths?
[05:32]  * jtv is a big fan of explicit-commit, implicit-abort
[05:34] <jtv> mwhudson: frustrating...  I'm trying to read Tim's db-devel fix, but the interesting part won't show up in the page.  Folding out that section just waits forever.
[05:34] <jtv> Did he add a commit as well as dealing with the cause of the oops-reporting failures?
[05:34] <mwhudson> jtv: he added a commit
[05:35] <jtv> ah good, I expected it but better safe than sorry
[05:37] <jtv> Where did the oops-reports URL go again?  https://devpad.canonical.com/~matsubara/oops.cgi is no longer accessible.
[05:41] <mwhudson> _thumper_: 33 megs of diff eh?
[06:21] <thumper> mwhudson: heh, yeah
[06:21]  * thumper is EDOing
[06:21] <thumper> I'll check later on some test runs
[06:21]  * mwhudson too
[06:25] <stub> jtv: It would lead to people slapping an explicit abort at the end of their script, which at least makes people think about it.
[06:25] <stub> jtv: I think implicit abort is good, but explicit abort is better.
[06:25] <jtv> stub: but at the end of your script is no good; you'd be getting this warning on top of regular errors, so people would either ignore it or silence it without giving it much thought.
[06:26] <stub> jtv: I don't follow why that would happen
[06:27] <stub> If you get multiple errors, you always just pay attention to the first.
[06:27] <jtv> Unless it seems to be just fluff.
[06:27] <jtv> You want an explicit commit at the end of your script; that's easy.  But when things go wrong, you break out of your normal path and don't get there.
[06:27] <stub> If you have fluff errors, you have bigger problems.
[06:28] <jtv> So you have an exception, and besides the regular error, you'd get a warning "by the way, you didn't abort explicitly."
[06:28] <stub> Indeed. Or you don't warn at all when the script is terminating because of an exception.
[06:28] <stub> Or non-zero return code or whatever.
[06:31] <jtv> But then what's left?  "You need an explicit commit at the end of the script."  For simple scripts it's actually quite nice that you can make them transaction-unaware: they're basically the transaction body.  To me it's more a hack that sometimes we have to do explicit commits.
[06:31] <jtv> Right now it's LaunchpadScript's responsibility to bracket, and your derived script provides the body.
[06:38] <jtv> So in fact I'd be more interested in the opposite: a warning against explicit commits/aborts during appserver requests.
[06:38] <jtv> stub: feel like a lumberjack?
[06:39] <stub> not today - up early and already partaken. This 8am thing is scary.
[06:45] <jtv> I've heard of it
[06:46] <jtv> I usually get these phases after travel—such as that last trip
[09:10] <mrevell> Morning
[09:10] <jml> good morning
[09:10] <wgrant> Morning mrevell/jml.
[09:11] <henninge_> jml: Hi!
[09:12] <henninge> thumper: gone for the weekend?
[09:27] <henninge> jml: as a former code guy, are you able to tell me which the cronjobs are that are running the branch jobs?
[09:28] <jml> henninge, I don't quite follow, what are you trying to find out?
[09:29] <jml> henninge, or rather, there's more than one cronscript running branch jobs-
[09:29] <jml> so it depends on which job you mean.
[09:29] <henninge> jml: all jobs access the branch table to change job status.
[09:30] <henninge> all jobs *that* access
[09:30] <henninge> jml: background:
[09:31] <henninge> today's roll-out will include a fix by Tim that will prevent from jobs remaining in the "running" state for ever and that will also let us see the oopses of our jobs.
[09:32] <henninge> to start on a clean slate, I wan't to set all jobs marked as "running" to "failed"
[09:32] <henninge> but I can only do that if those "running" jobs are not really running. For that I need to stop all jobs that run jobs.
[09:33] <jml> I see.
[09:33] <henninge> jml: those are the one I try to round up.
[09:33] <henninge> ones
[09:33] <jml> henninge, here's what I'd do if I were you
[09:34] <jml> bzr ls -VR --kind=file --null | xargs -0 grep -In JobRunner.fromReady
[09:34] <henninge> jml: good idea.
[09:34] <jml> henninge, and then look for the ones that are branch jobs, based on context
[09:34] <jml> henninge, (most of them will be)
[09:35] <jml> henninge, because there's no one cronscript and there's no canonical list.
[09:35] <henninge> jml: yes, I am aware of that.
[09:36] <henninge> jml: actually, I'll go for all jobs, not only branch jobs, since the bug was in the job system itself.
[09:37] <henninge> jml: thank you
[09:37] <jml> henninge, np. you might also want to grep for JobCronScript
[09:38] <henninge> ok
[09:38] <henninge> jml: yup, just saw that that calls fromReady, too.
[09:38] <jml> cool.
[11:00] <deryck> Good morning, all.
[11:01] <mrevell> morning deryck
[11:02]  * deryck hides his still-hasn't-blogged head in shame
[11:03] <mrevell> haha
[11:03] <mrevell> :)
[11:32] <wgrant> How acceptable is it to produce a branch which is a collection of largely unrelated trivial UI fixes?
[11:33] <bigjools> if they're genuinely trivial it sounds fine
[11:36] <asabil> hi all
[11:36] <asabil> is there any documentation about how to deploy lp for production ?
[11:51] <Fly-Man-> Is there a Wiki page on how the cron is defined ?
[12:00] <henninge> Hi, I just tried to push a branch locally to dev. Traditionally this would only work when pushing to ~sabdfl branches but that name has been changed to ~mark now. It seem, though, that sabdfl is still found somewhere. What needs to be updated here? http://paste.ubuntu.com/277814/
[12:01] <henninge> jml: (ex code guy ;) Any idea? ^
[12:02] <wgrant> henninge: ~/.ssh/config
[12:04] <henninge> wgrant: oh, that's where! Thanks!
[12:07] <henninge> wgrant: and now I know what to do when I want to push to a different branch. Thanks again!
[12:07] <henninge> s/branch/user/
[12:08] <wgrant> henninge: You can always use bzr+ssh://user@bazaar.launchpad.dev/~user/project/branch, of course.
[12:08] <henninge> too much noise .. ;-)
[12:08] <henninge> yeah, you're right
[12:08] <henninge> too many things to remember and to connect to each other ...
[12:19] <Fly-Man-> wgrant: Who's the server guru again ?
[12:19] <wgrant> Fly-Man-: 'server guru'?
[12:19] <Fly-Man-> Yeah, 1 or more ppl that manage the server
[12:20] <Fly-Man-> I'm trying to setup the cron jobs for the cronjobs that I found in the folder
[12:20] <wgrant> Note to self: remember to reset /etc/hosts after running ec2demo, or be prepared to get very strange pages at launchpad.dev next time...
[12:20] <Fly-Man-> but it seems that there's 1 or more cronjobs that can't run simularly
[12:20] <wgrant> Fly-Man-: What are you trying to do?
[12:21] <Fly-Man-> wgrant: I'm trying to setup the lp-branches/devel
[12:21] <Fly-Man-> and trying to setup cron jobs instead of me constantly clicking them
[12:21] <wgrant> Fly-Man-: To do what?
[12:21] <Fly-Man-> to run my internal system
[12:21] <Fly-Man-> building also fails for some strange reason
[12:25] <Fly-Man-> because before all I had to do is make a directory in the /var/tmp folder
[12:25] <Fly-Man-> but now it doesn't even do checkouts from local svn/git based trunks
[12:35] <jml> henninge, use ./utilities/make-lp-user
[12:35] <jml> henninge, and remove any mention of sabdfl from your .ssh/config
[12:41] <Fly-Man-> Finally
[12:41] <Fly-Man-> Now the code importer does his magic again ...
[12:54] <henninge> jtv1: This looks like a cocnfiguration error for errordir to me, doesn't it? http://paste.ubuntu.com/277857/
[12:54] <jtv1> henninge: is that what the job runner's attempts at oops logging were breaking on?
[12:55] <jtv1> they said it was because of missing config entries.
[12:55] <henninge> jtv1: probably
[13:04] <henninge> jtv: The missing config may just be an issue on dev, though. I have added that now and will retry.
[13:04] <jtv> henninge: most of that stuff is in the shared part of the config though
[13:05] <henninge> jtv: no, in the shared part error_dir is None, not only for rosettabranches but for most others, too.
[13:06] <jtv> ah ok
[13:06] <henninge> jtv: all others set it in development/launchpad-lazr.conf
[13:06] <henninge> we didn't
[13:06] <henninge> but I don't know about production config.
[13:07] <henninge> jtv: and oops_id ...
[13:07] <henninge> oops_prefix, that is
[13:09] <henninge> jtv: now I got an oops! 2009-09-25 12:08:38 INFO    Job resulted in OOPS: OOPS-1364RSBR1
[13:09] <jtv> henninge: good!
[13:10] <jml> kiko, good morning!
[13:11] <kiko> morning jml
[13:11] <kiko> how are you doing?
[13:11] <jml> kiko, well! just typing out the draft programme for next week
[13:11] <kiko> good job
[13:12] <jml> kiko, and then I have a million hours of meetings
[13:32] <asabil> I am trying to run launchpad from an installed egg
[13:32] <asabil> but when I run the bin/run script I get a: ImportError: cannot import name IAuthenticationUtility
[13:41] <henninge> jtv: here is the oops: Oops-Id: OOPS-1364RSBR1
[13:41] <henninge> Exception-Type: NoSuchFile
[13:41] <henninge> Exception-Value: No such file: ('tree_root-20070725222321-bwkrhbkxcrm83ygz-1', 'rcryderman@gmail.com-20090925041620-7chqzwqcbehtmzz0')
[13:41] <henninge> Date: 2009-09-25T12:08:38.944943+00:00
[13:41] <henninge> Page-Id:
[13:41] <henninge> Branch: jobrunner_fix
[13:41] <henninge> Revision: 8526
[13:42] <henninge> User: None
[13:42] <henninge> URL: None
[13:42] <henninge> Duration: -1
[13:42] <henninge> branch_job_id=3
[13:42] <henninge> branch_job_type=Rosetta Upload
[13:42] <henninge> branch_name=%7Emark/awn/0.4
[13:42] <henninge> job_id=3
[13:42] <henninge> Traceback (most recent call last):
[13:42] <henninge>   Module lp.services.job.runner, line 142, in runAll
[13:42] <henninge>     self.runJob(job)
[13:42] <henninge>   Module lp.services.job.runner, line 121, in runJob
[13:42] <henninge>     job.run()
[13:42] <henninge>   Module lp.code.model.branchjob, line 791, in run
[13:42] <henninge>     self._init_translation_file_lists()
[13:42] <henninge>   Module lp.code.model.branchjob, line 761, in _init_translation_file_lists
[13:42] <henninge>     changed_files.append((
[13:42] <henninge>   Module bzrlib.revisiontree, line 68, in get_file_text
[13:42] <henninge>     _, content = list(self.iter_files_bytes([(file_id, None)]))[0]
[13:42] <henninge>   Module bzrlib.revisiontree, line 84, in iter_files_bytes
[13:42] <henninge>     raise errors.NoSuchFile(e.revision_id)
[13:42] <henninge> NoSuchFile: No such file: ('tree_root-20070725222321-bwkrhbkxcrm83ygz-1', 'rcryderman@gmail.com-20090925041620-7chqzwqcbehtmzz0')
[13:42] <henninge> oops, sorry
[13:42] <jtv> henninge: paste would have worked!
[13:42] <henninge> I *have* pasted it: http://paste.ubuntu.com/277895/
[13:43] <henninge> that was my intention ... ;)
[13:43] <jtv> henninge: I think there are more oopses of this ilk in the codehosting oops reports from time to time.
[13:44] <henninge> jtv: but I con confirm that thumpers fix is working, all jobs are in "failed" state.
[13:48] <jtv> henninge: that's good.  There will be more "hanging" jobs in the future as scripts are killed for whatever reason, but nowhere near as many.
[13:48] <henninge> jtv: so we still need a garbage collection, I guess.
[13:49] <jtv> yes, eventually
[14:00]  * henninge relocates
[14:25] <allenap> gary_poster: Is it okay for me to push new revisions to trunk for lazr.restful?
[14:25] <gary_poster> allenap: sort of :-)  to explain...
[14:27] <gary_poster> allenap: if it is reviewed, then the process that has been recommended to me is to ``bzr co lp:lazr.restful`` , merge the desired branch , and ``bzr commit -m '[r=whoever] message'``.  I vaguely recall scenarios in which the same effect can be accomplished other ways, but the important idea is that all commit messages to the trunk should be of the pattern [r=*] * .
[14:27] <kiko> james_w, hey, how's it going?
[14:28] <gary_poster> That may have been truncated; let me know if it appears to not be complete
[14:28] <allenap> gary_poster: Ended with "pattern [r=*] * .".
[14:28] <gary_poster> allenap: then message received :-)
[14:29] <allenap> gary_poster: I'll follow that. I assume the same goes for wadllib? Also, currently there is a single failing test in trunk for lazr.restful. Should I do something about that?
[14:29] <gary_poster> allenap: wadllib: yes
[14:31] <gary_poster> allenap: failure: yes.  a bug minimally (point it out to me and I'll mark it critical, or you can).  fixing it would be lovely, and possibly necessary if you need a release today, unless you want to lean on me to try and figure it out.  (leonardr would almost certainly have an easier time addressing it.)
[14:31] <gary_poster> (leonardr is out today)
[14:32] <allenap> gary_poster: It seems like a simple fix; I'll get an mp together.
[14:32] <gary_poster> allenap: awesome thank you
[14:54] <Fly-Man-> wgrant: *ping*
[14:54] <Fly-Man-> What is devpad ?
[15:00] <james_w> hey hey kiko
[15:01] <kiko> james_w, how's it going?
[15:01] <james_w> kiko: I'm good thanks. How are you?
[15:02] <kiko> james_w, pretty busy, but good
[15:13] <beuno> flacoste, hi
[15:13] <beuno> flacoste, do you have 15-20 minutes to talk to me now-ish-y?
[15:18] <flacoste> beuno: in 2-5 minutes?
[15:19] <beuno> flacoste, perfect
[15:25] <flacoste> beuno: skype me
[15:25] <flacoste> beuno: or do you need me to call a number?
[15:25] <beuno> flacoste, skyping
[15:26] <beuno> flacoste, I have no sound
[15:26] <beuno> one sec
[15:26] <flacoste> beuno: that's bad!
[15:44]  * Fly-Man- shall rephrase his Q
[15:45] <Fly-Man-> How do I get an example from the crontab that a development server can run
[15:45] <Fly-Man-> and also can be placed on the Wiki as an example
[16:24] <bac> hi jml
[16:24] <rockstar> maxb, you around?
[16:24] <maxb> hiya
[16:25] <rockstar> maxb, have you gotten Windmill running on hardy.
[16:25] <rockstar> Er, on Karmic...
[16:25] <maxb> I've never tried Windmill at all
[16:25] <maxb> This is "make jscheck" ?
[16:26] <maxb> My policy on javascript is to leave it to other people :-)
[16:26] <jml> bac: hi, I'm on a call atcm.
[16:26] <maxb> At least until we're happy on python 2.6
[16:26] <rockstar> maxb, try this: ./bin/lp-windmill -e test=lib/code/windmill firefox http://launchpad.dev:8085
[16:26] <bac> jml: np. ping me when you have a free moment.
[16:26] <jml> bac, will do
[16:27] <maxb> rockstar: I am about to disappear for ~20 mins, will try when I can
[16:27] <rockstar> maxb, great, thanks.
[16:27] <maxb> I assume from the URL I'm supposed to make run first?
[17:42] <Fly-Man-> kfogel: Maybe you have a answer to this wise question ?
[17:44] <Fly-Man-> Where on the dev.launchpad.net is a simple example of the cron that staging or edge runs ?
[17:44] <jml> Fly-Man-, "the cron"
[17:44] <jml> ?
[17:44] <Fly-Man-> jml: yes, I figure there's not more then 1
[17:44] <jml> heh heh
[17:45] <Fly-Man-> and I am sure there's someone that can look on devpad
[17:45] <Fly-Man-> where kfogel posted an example for that
[17:45] <Fly-Man-> according to the search on the dev.launchpad
[17:45] <jml> maybe I'm missing some context
[17:45]  * Fly-Man- is getting tired of manually running the cron scripts
[17:45] <jml> which ones?
[17:46] <Fly-Man-> rosetta-imports
[17:46] <Fly-Man-> the standard karma updates
[17:46] <Fly-Man-> etc
[17:46] <Fly-Man-> etc
[17:46] <jml> Fly-Man-, Launchpad.net is run on a number of different machines and the cronjobs are spread across those
[17:47] <Fly-Man-> jml: but still there must be 1 total list of the jobs that run ?
[17:47] <jml> Fly-Man-, a while ago, faced with a problem similar to yours, I wrote the make target 'sync_branches'
[17:47] <jml> Fly-Man-, I don't think there is.
[17:47] <Fly-Man-> jml: I know that there's sync_branches
[17:47] <Fly-Man-> but that doesn't solve the issue
[17:48] <Fly-Man-> sync_branches works for bzr imports
[17:48] <jml> Fly-Man-, it solves the issue for the codehosting cronscripts.
[17:48] <Fly-Man-> and I have more then just the bzr imports
[17:48] <Fly-Man-> jml: I run the latest build locally
[17:48] <Fly-Man-> Having issues to even get a branch to import normally
[17:49] <Fly-Man-> and translations aren't picked up if I'm not running the rosetta cron scripts
[17:49] <jml> Fly-Man-, I was suggesting that you do something similar to what I did, and add other helpers for running the cron scripts.
[17:49] <jml> brb.
[17:49] <Fly-Man-> jml: I think the suggestion is great :)
[17:49] <Fly-Man-> But that doesn't solve the main issue
[17:50] <Fly-Man-> The main issue is that I want to run Launchpad like a normal intranet version app
[17:50] <Fly-Man-> and that means that I am not able to click every 10 mins on every cron script in that folder, just to make the user happy
[17:51] <Fly-Man-> and since I know that there's someone here that can either make a compilation of what the cron jobs are
[17:51] <Fly-Man-> and when they should be run
[17:51] <Fly-Man-> I'm hoping that someone might help
[17:51] <Fly-Man-> thus making it possible to run it as a intranet application for my developers
[17:51] <Fly-Man-> and not like the idea was, locally on 1 pc
[17:52] <bigjools> why are you just not using Launchpad itself?
[17:52] <Fly-Man-> bigjools: Good Q, bad answer
[17:52] <Fly-Man-> These are school kids that program things
[17:52] <Fly-Man-> and no internet connection available all the time
[17:52] <Fly-Man-> so their internet timer is limited
[17:53] <bigjools> what do they need to do, exactly?
[17:53] <Fly-Man-> bigjools: They need to be able to create a project
[17:53] <Fly-Man-> upload their translation files
[17:53] <Fly-Man-> be able to import their own git repro's
[17:53] <Fly-Man-> and be able to help each other with their projects
[17:54] <Fly-Man-> In other words:
[17:54] <Fly-Man-> The trunk version of Launchpad will be enough for them
[17:54] <Fly-Man-> as I donated a server to their school
[17:54] <Fly-Man-> so they could have a local system that works
[17:54] <bigjools> I honestly don't see how an intermittent internet connection prevents that, especially if you're using Bazaar
[17:54] <Fly-Man-> but so far, I'm forced to login with ssh every hour to run the cron scripts
[17:55] <Fly-Man-> bigjools: Bazaar is nice
[17:55] <Fly-Man-> especially when it works
[17:55] <Fly-Man-> because they have TurtoiseBzr now
[17:55] <bigjools> interesting comment
[17:55] <Fly-Man-> and so far, lpt://dev/project doesn't like to be uploaded to the server
[17:58] <Fly-Man-> So I think it might be time to just use Launchpad for all the things but the bzr
[17:58] <Fly-Man-> and install fusionforge next to it
[17:58] <Fly-Man-> so they can use that to make branches
[17:58] <Fly-Man-> and update that inside launchpad
[17:59] <bigjools> well I think you need to ask someone why you can't push branches
[17:59] <bigjools> because a lot of people are doing it quite successfully ;)
[17:59] <Fly-Man-> bigjools: I started using the trunk
[18:00] <Fly-Man-> because launchpad.net doesn't even import the most simple svn and git tree that I have
[18:00] <Fly-Man-> either it fails on import
[18:00] <Fly-Man-> or the svn/git parser dies
[18:00] <bigjools> have you asked a Codehosting expert to take a look?
[18:01] <Fly-Man-> bigjools: Yes :)
[18:01] <Fly-Man-> and let's see:
[18:01] <Fly-Man-> "This is a problem with the svn trunk"
[18:01] <Fly-Man-> "This is a problem with the svn parser we use"
[18:01] <Fly-Man-> "This is a Git issue, we'll fix it somewhere in fall 2009"
[18:01] <Fly-Man-> That's the answers so far
[18:01] <bigjools> ok
[18:02] <Fly-Man-> the strange thing is
[18:02] <bigjools> well if you're dead set on running your own instance of Launchpad, you did replace all the trademarked images I hope?
[18:02] <Fly-Man-> when I run it locally, it imports the whole svn or git without problems
[18:02] <Fly-Man-> bigjools: of course :)
[18:02] <Fly-Man-> that's what the readme on the website said
[18:02] <Fly-Man-> and it's a intranet version
[18:02] <Fly-Man-> so there's no outside connection
[18:03] <bigjools> I don't think that makes any difference ;)
[18:03] <Fly-Man-> bigjools: According to the file it does
[18:03] <bigjools> well, I'm sorry someone couldn't help you with the importing.  If it works for you locally then perhaps it works in our new release.
[18:04] <Fly-Man-> bigjools: what release would that be ?
[18:04] <bigjools> you can use the Launchpad images only for development and testing purposes
[18:04] <Fly-Man-> 3.0 ?
[18:04] <bigjools> yes 3.0
[18:04] <kfogel> Fly-Man-: the only example I posted is on dev.launchpad.net/Contributions, but that cron job has nothing to do with running Launchpad.
[18:04] <Fly-Man-> kfogel: I know, i found a message on dev.launchpad about you explain that there's a cron example of devpad
[18:05] <Fly-Man-> https://dev.launchpad.net/Translations/LanguagePackSchedule?highlight=%28cron%29
[18:05] <kfogel> Fly-Man-: since I know very little about Launchpad production practices, if I said I knew an example of a cron job I was probably lying.
[18:06]  * bigjools goes to eat
[18:07] <Fly-Man-> kfogel: I included your runninglocally page in the How to btw
[18:08] <kfogel> Fly-Man-: heh, I wouldn't call it  my page only because I mostly took instructions from other people (though I guess I did test them).  Anyway, glad it's been useful!
[18:08] <Fly-Man-> kfogel: It's been usefull
[18:08] <Fly-Man-> but the problem that occurs is in the part that you explain how to push a bzr
[18:09] <Fly-Man-> bzr push -d <some branch> lp://dev/~<you>/+junk/branchname
[18:09] <Fly-Man-> this doesn't work
[18:09] <Fly-Man-> when on a remote machine
[18:10] <beuno> Fly-Man-, I suspect because they can't resolve lp:// remotely...?
[18:10] <Fly-Man-> Correct
[18:11] <beuno> right, so there you get into more complex issues, like the launchpad plugin in bzr
[18:11] <kfogel> Fly-Man-: have yuo fixed up the wiki page to explain this issue?  (I thought you had, right?)
[18:11] <Fly-Man-> kfogel: barry fixed up that page of yours
[18:11] <Fly-Man-> because you wrote killall mailmanctl
[18:11] <kfogel> Fly-Man-: oops
[18:11] <Fly-Man-> and barry thought that was a bit harsh
[18:12] <kfogel> Fly-Man-: actually, I didn't write that (at laest, not that I remember)
[18:12] <Fly-Man-> but the method he described is even worse ;)
[18:12] <Fly-Man-> as that doesn't kill anything
[18:12] <kfogel> Fly-Man-: I hardly ever use the killall command, as it postdates when I learned Unix and I've got a fossilized brain :-).
[18:12] <Fly-Man-> But the point to this all is
[18:13] <Fly-Man-> The source is open
[18:13]  * rockstar lunches
[18:13] <Fly-Man-> but when someone wants to get it to work remotly
[18:13] <Fly-Man-> they'd need patience of a elephant to get something working together
[18:14] <rockstar> Fly-Man-, you've discovered the REAL secret to Launchpad.  We have AMAZING LOSAs.
[18:14] <Fly-Man-> LOSA ?
[18:15] <beuno> sysadmins
[18:15] <beuno> Fly-Man-, Launchpad is not built as a software that can be moved around
[18:15] <beuno> it's a service
[18:15] <beuno> that has been open sourced
[18:15] <Fly-Man-> beuno: I know
[18:15] <Fly-Man-> and that's the point exactly
[18:15] <beuno> if it's not easy to install, it's because it isn't
[18:15] <Fly-Man-> It's made easy to get the source
[18:15] <beuno> nad our resources are targeted at making the service better
[18:16] <beuno> it's easy because *we* need it to be easy to develop
[18:16] <Fly-Man-> but after that, the problems to make it a working something
[18:16] <beuno> it's not intentional, it's just where our focus is
[18:16] <Fly-Man-> is like asking Santa Clause for a new bicycle
[18:16] <Fly-Man-> You think you will get it
[18:16] <Fly-Man-> but you will never get it
[18:16] <beuno> no, that is the way *you* picture it
[18:16] <beuno> because you're linking open source to your view of it
[18:16] <Fly-Man-> beuno: Correct :)
[18:17] <beuno> it's open source so our users can help us improve
[18:17]  * Fly-Man- is in more then 20 open source projects
[18:17] <Fly-Man-> and we all have the need to ask questions and hope to get back info
[18:17] <beuno> this is not an open source application
[18:17] <beuno> this is an open source service
[18:17] <Fly-Man-> but in the 30 projects I take part in
[18:17] <Fly-Man-> we always tend to make documentation so ppl understand
[18:18] <Fly-Man-> and the dev wiki is definitly a good start
[18:18] <Fly-Man-> and I am happy that I can run it remotly now
[18:18] <Fly-Man-> but some pieces of the big puzzle are just missing
[18:18] <beuno> Fly-Man-, because those projects only succeed with more users and developers
[18:18] <beuno> Launchpad is funded as a service
[18:18] <beuno> our goal is to make it better
[18:18] <beuno> that's what we get paid for
[18:18]  * rockstar gives beuno an "AMEN!"
[18:18] <Fly-Man-> and I'm hoping that by asking some one might feel the need to express how it works
[18:19] <Fly-Man-> so that can be documented
[18:19] <beuno> we provide a service, and do what no one else does:  give you the code
[18:19] <rockstar> ...and with that, I go locate viddles
[18:19] <Fly-Man-> so that other ppl don't have the issue I'm facing
[18:19] <Fly-Man-> beuno: Ever heard from SourceForge ?
[18:19] <Fly-Man-> They made something called Gforge
[18:19] <Fly-Man-> and thought that ppl wanted it
[18:20] <Fly-Man-> that project is now taken over by ppl that want to make it better
[18:20] <Fly-Man-> and is called FusionForge now
[18:20] <Fly-Man-> and every step on that path is trail and error
[18:20] <Fly-Man-> but we tend to make it better
[18:20] <Fly-Man-> and the feeling that I have from Launchpad is that it's nice to test things on
[18:20] <Fly-Man-> but it's never a complete package
[18:21] <beuno> sourceforge stopped releasing their code
[18:21] <Fly-Man-> because you'd need to fiddle and use things that's never written down
[18:21] <beuno> they dropped a tarball
[18:21] <Fly-Man-> Yupz, Gforge Express and Gforge Community
[18:21] <beuno> we are an open source service, and we have decided to making it an amazing service, *not* a product
[18:21] <Fly-Man-> and the only one they develop on themselves is expensive
[18:22] <beuno> so if there's no documentation, it's because we don't have any
[18:22] <beuno> and will not invest time in it, since it won't make it a better service
[18:22] <Fly-Man-> In other words, here's the code
[18:22] <Fly-Man-> fiddle with it
[18:22] <Fly-Man-> but don't ask us how to make it work for you
[18:22] <Fly-Man-> that's the feeling I have with it
[18:23] <beuno> "help us improve"
[18:23] <beuno> "send us patches"
[18:23] <beuno> "participate in discussions"
[18:23] <Fly-Man-> beuno: Improvement can only be made when you can test everything there is
[18:23] <Fly-Man-> on a remote machine
[18:23] <Fly-Man-> not on a local machine
[18:23] <beuno> Fly-Man-, you can:  use the service
[18:23] <Fly-Man-> beuno: the service doesn't function on some parts
[18:23] <Fly-Man-> which I find strange
[18:24] <beuno> it does
[18:24] <Fly-Man-> why does a svn/git import on the local version work
[18:24] <beuno> launchpad.net works very well
[18:24] <Fly-Man-> and why does it fail on launchpad.net ?
[18:24] <Fly-Man-> it's the same server it's talking to
[18:24] <Fly-Man-> the same svn trunk it's pulling
[18:24] <beuno> I don't know, there's probably a bug there, or a connection issue, or whatever?
[18:24] <beuno> there's thousands of working imports
[18:24] <Fly-Man-> beuno: I know
[18:24] <Fly-Man-> and that's very good :)
[18:24] <beuno> good
[18:24] <beuno> so, it's open source
[18:24] <Fly-Man-> but when I can't import a simple svn trunk
[18:24] <beuno> if you have a problem
[18:25] <beuno> find the bug, fix it, send us a patch
[18:25] <Fly-Man-> so I can use the translations files that are in my trunk
[18:25] <beuno> we'll help you test it and submit it
[18:25] <beuno> so, either file a bug and help chase it, or look at the code and try to find the problem, send a patch
[18:25] <beuno> everyone wins
[18:25] <Fly-Man-> beuno: Okay, then let's send a bug report
[18:26] <Fly-Man-> why are you using a compiled version of svn that uses python
[18:26] <Fly-Man-> or git compiled that uses python /
[18:26] <Fly-Man-> why not just a clean svn checkout <url>
[18:26] <beuno> I guess because we use bzr-git to import branches?
[18:26] <beuno> I don't know the code imports in detail
[18:27] <Fly-Man-> because that's 1 of the main issues that I'd like to see fixed
[18:27] <Fly-Man-> use the tools that are there
[18:27] <Fly-Man-> grab a svn trunk
[18:27] <Fly-Man-> then compile it into a bzr
[18:27] <beuno> I suspect we don't want to double the amount of space per imported branch
[18:28] <beuno> or maintain svn/git/cvs/hg branches
[18:28] <Fly-Man-> and the best part is this
[18:28] <beuno> or deal with their problems
[18:28] <Fly-Man-> Bazaar is hosted by ....
[18:28] <Fly-Man-> Launchpad
[18:28] <Fly-Man-> and what does Bazaar have
[18:28] <Fly-Man-> svn2bzr is a tool to convert Subversion repositories into Bazaar repositories.
[18:29] <Fly-Man-> But enough on the trunk problems
[18:30] <Fly-Man-> because the main issue why I am not using Launchpad for my projects is mainly
[18:30] <Fly-Man-> my users like svn and git
[18:30] <Fly-Man-> and I don't want them to learn yet another code handling tool
[18:30] <beuno> so maybe Launchpad is not the right tool...?
[18:31] <Fly-Man-> beuno: Well, so far Launchpad is handy for the translations part
[18:31] <Fly-Man-> that's about the only thing that works like a charm
[18:31] <beuno> so use it for that
[18:31] <Fly-Man-> I am
[18:31] <beuno> good
[18:31] <beuno> then you're happy
[18:31] <beuno> I'm glad to see that
[18:31]  * Fly-Man- shakes hand of beuno
[18:32] <Fly-Man-> If you're happy with that, then I am happy too
[18:32]  * Fly-Man- smiles
[18:32] <beuno> I'm always happy
[18:33] <Fly-Man-> beuno: Can you do me a favor then
[18:33] <Fly-Man-> and delete the code part on 1 project
[18:33] <Fly-Man-> as it won't import anyway
[18:33] <Fly-Man-> https://code.edge.launchpad.net/fusionforge
[18:33] <Fly-Man-> Leave the flyman trunk there
[18:33] <Fly-Man-> I will use it to push the translations in
[18:34] <beuno> you want me to delete this?  https://code.edge.launchpad.net/~vcs-imports/fusionforge/trunk
[18:35] <Fly-Man-> Yes, as it won't import
[18:36] <beuno> Fly-Man-, I need you to delete the series it's linked to: https://code.edge.launchpad.net/fusionforge/trunk
[18:37] <Fly-Man-> You cannot delete a series that is the focus of development. Make another series the focus of development before deleting this one.
[18:37] <beuno> that is annoying
[18:37] <Fly-Man-> Yes
[18:38] <beuno> I will need you to do that, unfortunetly
[18:39] <Fly-Man-> Can you disable the import
[18:39] <Fly-Man-> then I will redirect the translations to that one that's still there
[18:39] <beuno> we can try and ammend the URL?
[18:40] <beuno> see if that's what's making it fail?
[18:40] <Fly-Man-> Hmm, I have a better idea
[18:40] <Fly-Man-> let's just delete the project
[18:40] <beuno> does "svn checkout svn://scm.fusionforge.org/svnroot/fusionforge/trunk: work?
[18:40] <Fly-Man-> yup
[18:40] <Fly-Man-> within 20 secs
[18:40] <Fly-Man-> then I have the complete trunk
[18:41] <Fly-Man-> I'm running Hudson to test the trunk
[18:41] <Fly-Man-> so I know that it fetches within 20 secs
[18:41] <beuno> pysvn._pysvn_2_4.ClientError: Connection closed unexpectedly
[18:41] <beuno> so it's a connection error that's preventing it from importing
[18:42] <beuno> it drops suddenly at some point
[18:42] <Fly-Man-> yupz, I checked with the admin of that server
[18:42] <Fly-Man-> he sees that Launchpad connects
[18:42] <Fly-Man-> then after 1,5 or 2 mins Launchpad drops the connection
[18:42] <beuno> well, I kicked off the import again while adding a trailing slash
[18:42] <beuno> and it's working
[18:43] <beuno> 2 minutes in
[18:43] <Fly-Man-> poof
[18:43] <beuno> and failed again...
[18:43] <Fly-Man-> there is goes
[18:44] <beuno> ok, so, if you're interested in pursuing this, file a bug
[18:44] <Fly-Man-> beuno: it's almost like it doesn't like svn
[18:45] <Fly-Man-> https://code.edge.launchpad.net/~vcs-imports/opensim/svn-trunk
[18:45] <Fly-Man-> this is another project
[18:45] <Fly-Man-> this tries to grab an svn from another server
[18:45] <Fly-Man-> and after 1 hour, Launchpad just gices up
[18:45] <Fly-Man-> but when you look on the buildserver
[18:45] <Fly-Man-> the whole svn trunk is already there
[18:47] <Fly-Man-> Same goes for the Git trunk
[18:47] <Fly-Man-> as I wasn't sure if it was svn that had issues
[18:47] <Fly-Man-> I tried to import the git trunk
[18:48] <beuno> it's not good that there are so many failing imports, this is something that needs to be looked in to
[18:48] <Fly-Man-> https://code.edge.launchpad.net/~vcs-imports/opensim/new-trunk
[18:48] <Fly-Man-> So this is the Git trunk
[18:48] <Fly-Man-> and it failed just as miserable as the svn
[18:48] <Fly-Man-> but the git at least says something wise
[18:48] <Fly-Man-> it can't decompile something
[18:49] <beuno> yeah, this needs to be raised
[18:50] <beuno> I've pinged the bzr-git developer about it
[18:55] <Fly-Man-> but beuno, do you understand now why I don't have trust in the code importer /
[18:55] <beuno> yeap
[18:56] <Fly-Man-> :)
[18:56] <beuno> it's not working reliably for you
[18:56] <beuno> we need to fix it
[18:56] <Fly-Man-> Okay, and that's why I saw the announcement for the launchpad going opensource
[18:56] <Fly-Man-> and decided to give that a spin
[18:57] <Fly-Man-> because 1 thing I miss is an option to import an already bazaar repro into Launchpad
[18:57] <Fly-Man-> to have Launchpad as a backup
[18:59] <beuno> there are imports for bazaar branches
[18:59] <beuno> they are called mirrored branches
[19:01] <Fly-Man-> how do I add one ?
[19:01] <Fly-Man-> Ahh, register new branch
[19:01] <Fly-Man-> then just setup mirrored ?
[19:01] <beuno> yeap
[19:03] <Fly-Man-> (KnitPackRepository('http://scm.fusionforge.org/bzr/fusionforge/.bzr/repository/') has no revision ...)
[19:03] <beuno> right, sso you need to specify a branch
[19:04] <beuno> not a repository
[19:04] <Fly-Man-> beuno: All I entered is
[19:04] <Fly-Man-> (KnitPackRepository('http://scm.fusionforge.org/bzr/fusionforge/
[19:04] <Fly-Man-> http://scm.fusionforge.org/bzr/fusionforge/
[19:04] <beuno> that is a repository
[19:04] <Fly-Man-> Anonymous read-only Bazaar gateway (updated hourly)
[19:04] <beuno> you need to point it to a branch
[19:05] <Fly-Man-> bzr checkout http://scm.fusionforge.org/bzr/fusionforge/svn-trunk-ro fusionforge-trunk
[19:06] <beuno> right, point it at: http://scm.fusionforge.org/bzr/fusionforge/svn-trunk-ro
[19:07] <Fly-Man-> Hmm, I might know the answer to that one
[19:07] <Fly-Man-> bzr 1.0
[19:10] <Fly-Man-> K, I give up on this
[19:10] <Fly-Man-> even with another url it fails
[19:27] <maxb> Fly-Man-: If you look to the Launchpad licence, it's fairly clear that Canonical doesn't really want people to run their own Launchpads.
[19:27] <Fly-Man-> maxb: I have seen it
[19:27] <maxb> Which is sad, because that would be neat.
[19:28] <Fly-Man-> maxb: Well, you can run your local version
[19:28] <Fly-Man-> but you'd need to fiddle around to make it a working version
[19:28] <maxb> But I can understand why given that running your own Launchpad either dilutes the value of launchpad.net, or takes away money that you might otherwise be paying to Canonical
[19:29] <Fly-Man-> maxb: In what way would I be paying Canonical when I only want hosting of my open source projects ?
[19:30] <maxb> If it's open source projects, that falls under the heading of "dilutes the value of launchpad.net"
[19:30] <maxb> Part of what makes Launchpad great is that it's a one-stop-shop for OSS
[19:31] <maxb> The money aspect is applicable if the motivation for running a Launchpad instance is private/proprietary projects
[19:31] <Fly-Man-> yup
[19:31] <maxb> Which I'd love to do at my office, if I could do it legally
[19:31] <maxb> :-)
[19:31] <Fly-Man-> and when FusionForge does the same with translations as Launchpad
[19:31] <Fly-Man-> then I think my choice will be a lot easier ;)
[19:33] <maxb> As far as LP documentation is concerned, I've seen Canonical folks make reference to the LOSAs private collection of howto wiki pages. If they were prepared to open those onto the dev wiki, I reckon there'd be a fair amount of interesting info there
[19:33] <maxb> I should post to the mailing list
[19:34] <Fly-Man-> maxb: I think I know the answer to that request
[19:34] <abentley> rockstar: Around?
[19:34] <maxb> It never hurts to ask
[19:35] <Fly-Man-> maxb: True
[19:36] <abentley> maxb: The LOSA documentation is, or should be, purely about operational issues.  I agree that anything which isn't should be opened.
[19:36] <Fly-Man-> abentley: Does running cron jobs fall under that operational part ?
[19:37] <abentley> Fly-Man-: Yes, I would think so.
[19:38] <Fly-Man-> abentley: Then the docs are of no use ;)
[19:38] <Fly-Man-> the operational part
[19:38] <Fly-Man-> because as I heard earlier, the parts that someone would need most
[19:38] <Fly-Man-> is the part that doesn't open up to the outside
[19:39] <maxb> Well, it's nice that Canonical open-sourced it at all
[19:39] <maxb> And Soyuz and Codehosting were going to be withheld at one point
[19:40] <Fly-Man-> maxb: Yes, don't get me wrong
[19:40] <Fly-Man-> I am very happy that it got opensourced
[19:41] <Fly-Man-> but with opening up the source and then saying "Well, there's more but we won't tell you"
[19:41] <Fly-Man-> but you can help us with improving
[19:41] <maxb> Yeah, I agree that's an irritation
[19:41] <Fly-Man-> then my feeling is that they did this just because large companies asked about it
[19:42] <maxb> Well, helping improve LP helps me in that launchpad.net, which I use, gets better
[19:42] <maxb> But there's an irritation in the "so close but so far" position
[19:42] <abentley> Fly-Man-: We did it because open-source lovers wanted it open-sourced, and so that others could contribute.
[19:42] <maxb> Also LP is teaching me a lot about large systems in Python
[19:43] <Fly-Man-> abentley: Yes, but i've held that speech before this hour
[19:43] <Fly-Man-> and someone pointed out that it's opensourced to make it better
[19:43] <Fly-Man-> well, in order to make it better I would need to be able to have it running just like a development machine
[19:43] <abentley> Fly-Man-: AIUI, large companies were no part of the motivation.
[19:44] <Fly-Man-> so be able to test all the features that Launchpad.net has
[19:44] <abentley> Fly-Man-: "make run_all" is what we developers use for that.
[19:44] <Fly-Man-> abentley: but don't tell me that you don't have a cron job schedule with it
[19:44] <Fly-Man-> or did you want to say that you don't use translations, code importer, etc ?
[19:44] <abentley> Fly-Man-: Why not?
[19:45] <maxb> There is documentation on the dev wiki that tells you what cronscripts to poke when to make codehosting work
[19:45] <Fly-Man-> maxb: I know which scripts there are
[19:45] <Fly-Man-> and also that they're run
[19:45] <abentley> Fly-Man-: Us developers do not have any cron scripts scheduled.
[19:45] <Fly-Man-> but what I lack to find is how many times a day 1 script is run
[19:46] <Fly-Man-> or which scripts I need to run at what times
[19:46] <Fly-Man-> because simply 3 scripts have names that tell me when to run then
[19:46] <maxb> Well, you don't really need to know that unless you want the instance to work for something other than single-user development
[19:46] <Fly-Man-> maxb: Exactly
[19:46] <Fly-Man-> Why did you think I wrote the piece about the remote access ?
[19:47] <Fly-Man-> not that I have 1 machine
[19:47] <Fly-Man-> but that I can login with more then 1 machine to do testing
[19:47] <maxb> And Canonical quite clearly doesn't want to facilitate you doing anything other than single-user development
[19:47] <Fly-Man-> upload things
[19:48] <Fly-Man-> maxb: Yes, that's the policy I feel
[19:48] <Fly-Man-> but whenever a sys admin that's on this channel says
[19:48] <Fly-Man-> "Hey, run rosetta-po-importer.py every 15 mins from the hour"
[19:48] <Fly-Man-> then I would know how many times I would have to have it run
[19:48] <Fly-Man-> or differently
[19:49] <Fly-Man-> "I think you could run the code-importer.py every 5 mins"
[19:49] <Fly-Man-> that would make more sense then
[19:49] <Fly-Man-> "Uhm, we have no clue"
[19:49] <beuno> that depends on your systems, traffic, etc
[19:49] <abentley> Fly-Man-, maxb: We don't want a million different Launchpads popping up, because that dilutes the value of Launchpad as a system that connects multiple projects together.
[19:49] <beuno> so, it's an operational issue
[19:49] <beuno> so, it's not part of Launchpad
[19:49] <beuno> dude, listen to what we're telling you
[19:49] <beuno> we're not evil, we just don't work for you
[19:50] <Fly-Man-> beuno: So in order to get the information that I would need for my version of testing
[19:50] <Fly-Man-> I would need to write a nice email to the launchpad mailinglist
[19:50] <Fly-Man-> or maybe the head of the development on Canonical
[19:51] <beuno> you would need to do operational work
[19:52] <Fly-Man-> and that's 1 thing that they'd prohibit by making this a single user development system
[19:52] <Fly-Man-> no outgoing email
[19:52] <abentley> Fly-Man-: The number of times you run code-importer per day is purely arbitrary.  Our particular crontabs are not something you would need to set up a competing service, much less do remote testing.
[19:52] <Fly-Man-> etc
[19:52] <Fly-Man-> abentley: But it would clarify some more about what the scripts do
[19:53] <maxb> abentley and beuno are right: What we have here is a situation where people have been freely given access to a huge amount of code, but haven't been given all the pieces to use it in the way they want, and are focussing on the negative, despite the fact that we have any of it is a gift
[19:53] <Fly-Man-> maxb: I agree on that
[19:53] <Fly-Man-> It's a gift
[19:53] <abentley> Fly-Man-: What would it clarify?
[19:53]  * beuno high-fives maxb 
[19:54] <Fly-Man-> abentley: It would clarify how many times I would run which script
[19:54] <Fly-Man-> in order to have it perform like a development machine that could do production
[19:54] <maxb> It would clarify what you would need to do to establish a working model of production.
[19:55] <Fly-Man-> maxb: Correct
[19:55] <maxb> You don't necessarily need a working model of production to be an effective developer
[19:55] <beuno> yes, that would require work from our part on documenting it, probably changing the way some things work, etc
[19:55] <Fly-Man-> as I am a developer that always tests things as if they're a production machine
[19:55] <abentley> Fly-Man-: If the scripts aren't clear enough about their function for you to decide how often to run them, that's a bug we will happily fix.
[19:55] <beuno> this is not what we want to spend time on, as a project
[19:55] <maxb> In fact I doubt you could reasonably run a working model of the entirety of production on a single system and develop on it, unless it was uber-powerful
[19:56] <Fly-Man-> abentley: So where do I place that bug then ?
[19:56] <Fly-Man-> because I think that's a reasonable solution to this
[19:56] <maxb> Fly-Man-: Well you'd start by examining every file in cronscripts/* and making a list of which ones you couldn't figure out
[19:56] <abentley> Fly-Man-: When in doubt, file on the main launchpad project.  If it's misfiled, someone will fix it.
[19:57] <maxb> an index to scripts/* and cronscripts/* broken down by launchpad application would actually be rather neat
[19:57] <maxb> maybe we should start one on dev.lp.net
[19:58] <Fly-Man-> maxb: And I would be happy to write those pages
[19:58] <maxb> start one up and I'll happily help
[19:58] <Fly-Man-> but in order to write things, I would need to know what the scripts would do, how many times they're run in a production environment
[19:58] <maxb> No you wouldn't
[19:58] <Fly-Man-> so I'll file a bug/blueprint to ask
[19:59] <maxb> That would be silly
[20:02] <Fly-Man-> maxb: Why would it ?
[20:02] <Fly-Man-> abentley asked me to file one
[20:03] <Fly-Man-> so I nicely written one
[20:03] <Fly-Man-> And we'll see what the outcome of it will be
[20:04] <maxb> He asked you to file a bug on scripts that were unclear as to their purpose. That is quite thoroughly independent from disclosure of production crontabs
[20:05] <Fly-Man-> maxb: I filed a blueprint asking to be explained either in the scripts themselves or with a response on the purpose of the scripts in the cronscripts and scripts folder
[20:24] <Fly-Man-> k, time for a restfull weekend
[20:24] <Fly-Man-> Thank you all for listening and for all your advice :)
[21:12] <mrevell-dinner> Night all
[23:20] <barry> kfogel: nice
[23:21] <kfogel> barry: now we have to actually remember to use it.
[23:21] <kfogel> we'll see
[23:22] <kfogel> barry: oh, hey, can you review a launchpadlib branch?  https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs/+merge/12442
[23:22] <kfogel> barry: easy one, just adds title attributes to the api ref HTML.
[23:22]  * barry looks
[23:25] <barry> kfogel: this looks fine.  are there any wadl related tests in the launchpadlib tree that you could piggyback on?  i don't know if launchpadlib currently tests its wadl or not
[23:25] <kfogel> barry: I don't know either.
[23:27] <barry> and unfortunately leonardr isn't around.  maybe flacoste knows?
[23:33] <barry> kfogel: i'm going to mark this needs fixing for now, but if we find the answer it'll be an easy switch
[23:35] <kfogel> barry: sounds good