[12:03] so tomorrow morning [12:03] I will wake up early tomorrow [12:03] so that should work too [12:04] kiko, thank you very much! [12:04] good night! === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad [12:21] does malone offer other output formats beside html? [12:21] or is such a feature planned? [12:22] Seveas, mail? [12:23] Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix up duration of build job in progress, correct trivial bug in builder-index page template. r=salgado (patch-2499: daniel.silverstone@canonical.com) [12:23] no, xml :) [12:23] something like bugzillas xml would help [12:23] I'm porting the supybot bug reporting plugin to malone, but currently the plan is to have a massive regex to filter out the info [12:24] is such a thing available/planned/not considered yet/may be considered? [12:25] somewhere between planned and not considered, i think :) [12:25] ok :) [12:26] we'll do XML and RSS feeds like everybody else, i'm sure. not a priority atm though. [12:26] then i'll hope the output format of malone does not change too heavily too often [12:26] thanks for the info bradb [12:26] bradb: xml-rpc interface will be for all functionality of malone, correct? [12:26] Seveas: the emails might still change pretty significantly. well, so might the web UI. [12:27] k, then I/#ubuntu-desktop will have to live with the fact that the plugin will break once in a while :) [12:27] ajmitch: too early to say, but my guess would be probably, more or less [12:29] Seveas: yeah, sorry, it's possible that it could hurt. after ubuntu main has been on it for 6 months or a year, things will become more predictable. right now, there's just a whole lot of guessing about how people might use the UI, so it's hard to say what will be adjusted still. [12:32] bradb, that's ok, it was no complaint. It's great to see launchpad getting shape, now if only the hackergotchis would work :) [12:32] Seveas: perms problem, you mean? [12:33] yeah [12:33] I can edit it for a team I created, but not my own [12:35] There are some other issues I collected, I'll file them in malone (if not there yet) tomoorow-ish [12:37] Seveas: if you're interested in the hackergotchi problem, you might want to subscribe to bug #2501 [12:56] bradb, what are null bugtasks, again? [12:57] bradb, matsubara has a fix, the test has just been a bit involved to run [12:57] kiko: a bugtask for which no actual bugtask exists (so that you can, e.g., view a bug in a context in which it's not yet been reported.) [12:58] bradb, a bug without a bugtask in the context being currently viewed. ah, ok. [12:58] i.e. it's a null object implementation of IBugTask [12:58] right [01:10] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=salgado] make upstream tasks be wiki-mode (patch-2500: brad.bollenbach@canonical.com) [01:11] salgado, https://launchpad.net/errors/showEntry.html?id=1127776181.690.431611962761 === salgado quickly clicks on the link [01:12] this was a person who followed a link from email [01:12] this was a person who found the +login page on shipit [01:13] no [01:13] look at the referrer [01:13] kiko, he found the +login page and then tried to register on there [01:15] how did he get there from the referer? [01:15] later dudes === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] [01:17] kiko, if you reach the +login page and try to register there, the email sent to you will have a link to https://shipit.ubuntu.com/token/, because the application_url on that page is https://shipit.ubuntu.com [01:17] (I mean, if you reach the +login page on https://shipit.ubuntu.com/) [01:18] if you follow the link to launchpad.net/+login and register there, everything will be fine [01:19] salgado, how did the guy find the +login link? it should be pretty easy, we're getting dozens of these in production. [01:20] I have no idea, but this is why we overwrote all that error pages for shipit [01:20] to make sure people won't get a link to the +login page if something goes wrong or they don't have permission [01:21] there must be a straightforward way.. [01:22] salgado, just fyi -- even googlebot is finding it. [01:22] dammit [01:22] actually, false. [01:22] we need to talk to SteveA and find a way to disable it in shipit [01:22] , name: u',' [01:22] NotFound: Object: , name: u'robots.txt' [01:22] interesting, eh? a single comma. [01:24] heh [01:25] salgado, here's an interesting one. [01:25] salgado, if you are logged in but don't log out, logging in again doesn't fail. [01:25] (even if you enter an invalid name and pass) [01:27] kiko, how do I get the login page if I'm already logged in? [01:28] salgado, use the back button? [01:32] kiko, well, I guess that's because the form-processing code identifies you're already logged in and do not process the form [01:32] ah, right, perhaps. [01:33] does anyone know when staging last refreshed? [01:34] no idea [01:35] a staging that is a week old is pretty useless [01:35] dammit [01:37] jamesh, ping? [01:41] jbailey: ping [01:43] lifeless: pong [01:44] BAH [01:44] jamesh: ping [01:44] jbailey: unping [01:44] :/ [01:44] lifeless: unpong [01:44] lol [01:44] jbailey: you need to change your name, I think [01:45] ajmitch: True. I hear "Andrew" is a good one. [01:45] Wouldn't that just make #chug confusing? [01:45] not at all [01:46] Oh good. [01:46] I'm glad you've settled that. =) [02:22] kiko/lifeless: yeah? === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad === niemeyer [n=niemeyer@200.181.170.230] has joined #launchpad === Kinnison updates dogfood [03:08] jamesh, could you commit my patch attached to bug https://launchpad.net/malone/bugs/2540 -- ? [03:19] kiko: sure. [03:19] thanks! [03:19] kiko: once we can dump hoary, we can use the system gettext [03:20] which should make these sort of problems a non-issue [03:26] hmmm [03:26] night all === Kinnison beds [03:33] Merge to rocketfuel@canonical.com/launchpad--devel--0: Make sure slave passes /dev/null as stdin to the subprocess. Rev launchpad-buildd to v7. r=spiv (patch-2501: daniel.silverstone@canonical.com) [04:06] Merge to rocketfuel@canonical.com/launchpad--production--1.34: Cherry pick patch-2493 into production 1.34 (patch-7: rocketfuel@canonical.com, christian.reis@canonical.com) [04:54] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Improve script exception output and fix noisy log test (patch-2502: stuart.bishop@canonical.com) === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [05:35] Merge to rocketfuel@canonical.com/launchpad--production--1.34: Cherry pick patch-2502 into production 1.34 (patch-8: stuart.bishop@canonical.com, rocketfuel@canonical.com) [05:36] jamesh: ping [06:26] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Add indexes to the ShipIt tables (patch-2503: stuart.bishop@canonical.com) [06:56] Merge to rocketfuel@canonical.com/pygettextpo--devel--0: [trivial] disable csharp bindings in included gettext-tools package. Fixes bug 2540 (patch-7: james.henstridge@canonical.com) === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad === sabdfl [n=mark@pdpc/supporter/silver/sabdfl] has joined #launchpad [07:26] Merge to rocketfuel@canonical.com/launchpad--production--1.34: Cherry pick patch-2503 into production 1.34 (patch-9: stuart.bishop@canonical.com, rocketfuel@canonical.com) === stub starts the weekly upgrade [07:45] drumroll... [08:03] spiv: Can you poke the librarian to see if it survived the database outage? === BjornT [n=bjorn@82-135-221-189.ip.takas.lt] has joined #launchpad === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [08:05] stub: Ok. [08:07] stub: Seems ok. [08:07] Cool ;) [08:08] sabdfl: Have you seen the new bounty? https://launchpad.net/bounties/chquite [08:12] getting a system error now trying to view assigned bugs [08:12] url is https://launchpad.net/people/motu/+assignedbugs [08:14] ajmitch: ta. I can fix that [08:15] thanks [08:17] ajmitch: fixed [08:18] quick work :) === lifeless_ [n=robertc@dsl-93.19.240.220.rns02-kent-syd.dsl.comindico.com.au] has joined #launchpad [08:25] Hey, the 'tabs are a few pixels off' bug got fixed last night :) [08:25] nice [08:28] other ui oddities seem to have been introduced :) [08:37] malone uses a different from address for bug emails now? (submitters address) [08:38] hey where do i go to translate launchpad itself? [08:39] moyogo: I think this is not yet available, but discussions are going to take place on that - stay tuned, this should come up sometime close. (anybody correct me if I'm wrong) [08:53] sivang: there's version 7 in multiverse but it's broken [08:53] sivang: i guess i'll have to use evince... [08:53] moyogo: huh? version of launchpad ? [08:59] I don't think we've looked at setting up the i18n for Launchpad yet [08:59] some parts of the code have strings marked, and other parts don't [09:04] jamesh: ah, so there's i18n data in multiverse for launchapd ? === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [09:07] sivang: not to my knowledge. [09:09] jamesh: k, that's what I thought === Treenaks [n=martijn@messy.foodfight.org] has joined #launchpad [09:16] I'm getting mail ("Your mail to Launchpad-bugs awaits moderation") when filing bugs in malone [09:18] Treenaks: yes, seems the from address for malone bugs has changed :) [09:19] hah [09:19] ajmitch: it also breaks people with SPF on their From: domains [09:19] +for [09:19] Treenaks: SPF doesn't have anything to do with From: [09:19] bob2: MAIL FROM: then [09:19] presumably LP uses it's own envelop-sender [09:20] bob2: it changed, yes [09:20] bob2: new behaviour breaks RFC 2821 section 3.10 [09:22] that is messed up [09:22] bob2: already filed a bug === jbailey_ [n=jbailey@testhaus.cns.utoronto.ca] has joined #launchpad === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad === jbailey [n=jbailey@testhaus.cns.utoronto.ca] has joined #launchpad [09:49] BjornT: ping [09:56] hi stub [09:56] You broke the bugs mailing list ;) [09:57] nope, bradb did :) [09:57] Or should I say, the changes to bugmail (set reply-to: rather than munging from:) breaks mailman - I've had to open the list. [09:58] But I think this is mailman's problem rather than Malones [09:58] (because I now have no way of saying 'let through emails from malone but hold everything else) [09:59] I might send a use case to Barry === carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net] has joined #launchpad [09:59] morning [09:59] stub: can't mailman look at reply-to instead? or some other header? [10:00] BjornT: Nope ;) It would be a simple change through. But currently, it can't. [10:00] Or at least I can't find it === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [10:02] SteveA, I need a fast review to cherrypick into production before Stub leaves today. It's related to language packs [10:02] morning [10:02] hello carlos :) [10:02] zyga, morning [10:03] stub: in the mailman admin interface, go to "privacy options -> spam filters" [10:04] jamesh: I can't see how to use that though [10:04] stub: you should be able to configure mailman to accept messages that match an arbitrary header using header_filter_rules [10:04] jamesh: I need to say 'let through anything with this', but the spam filters say 'block anything with this' [10:04] morning [10:04] carlos: go for it [10:04] jamesh: oh! I see [10:05] stub: really? on the gnome installation, it has a box where you can enter a regexp, and a set of radio buttons (defer, hold, reject, discard, accept) [10:05] SteveA, carlos.perello@canonical.com--2004/launchpad--devel--0 [10:05] Yes - I didn't notice the radio buttons [10:06] jamesh: They are regexps? [10:06] stub: the text beside the textarea says "Spam Filter Regexp:" [10:08] carlos: was that the bug about missing translations? that sometimes the date isn't updated? [10:09] SteveA, right, translators update pofile outside Rosetta [10:09] stub: how do i create a new dbuser for process-mail.py to use? [10:09] and the revision date is not updated [10:09] so Rosetta ignores that [10:09] BjornT: Add the relevant section to security.cfg, then somewhere in schema.xml to make it configurable [10:09] so rosetta ignores the new translations because rosetta depends (currently) on the revision date in the po file [10:10] SteveA, right [10:10] SteveA, I just relaxed it a bit and if the revision date is the same we have in our database we accept it [10:11] i see [10:11] what happens if the revision date is a lot in the future? [10:11] does that stop new translations from occuring? [10:11] we changed our db schema a couple of months ago so reimporting a pofile with the same data will not produce that we lose data [10:11] SteveA, yes [10:12] stub: ok, thanks === sabdfl [n=mark@wbs-146-138-47.telkomadsl.co.za] has joined #launchpad [10:13] carlos: is that fixed in this patch i'm reviewing? [10:14] SteveA, yeah, that's the point behind that patch [10:14] ok [10:15] baz is still working on it [10:15] SteveA, it has also the karma change you cherrypicked last week [10:16] ok, great [10:16] but it's missing the update you did [10:16] I'm getting the production branch to apply that change too [10:16] i sure hope bzr comes along soon... baz is getting unbearably slow [10:19] BjornT: I'll turn off that deprecation warning on production [10:20] stub: cool. i'll fix it anyway since i already started === dand [n=dand@gw.datagroup.ro] has joined #launchpad === carlos -> breakfast [10:31] SteveA: I think I've got the test suite warning issues sorted -- they weren't due to out-of-process tests === jbailey [n=jbailey@testhaus.cns.utoronto.ca] has joined #launchpad [10:34] jamesh: really? what was it? [10:34] is there a tree i can look at? [10:37] SteveA: haven't mirrored the changes yet [10:37] ok [10:37] SteveA: the logging module contains internal state (the configuration of the loggers), and some of the tests were reconfiguring the logger [10:38] ah [10:38] so running individual tests wouldn't cause the bug, but running them in sequence would [10:38] s/bug/output/ [10:39] we could do with a way of registering subsystems to have their state checked and/or cleared between tests. [10:39] there is something like this for zope3 tests, but i think it is rather messy [10:39] Grrrr! [10:39] this could be done with a root-level event subscriber, very simply [10:39] lifeless: svn import is crap [10:40] samba (on hoover) and videolan-vlc (on roomba) repeatedly fail with out of memory :( [10:41] lifeless: need your help about how to diagnose fix the leak [10:42] Short of a better idea, I'll try implementing some form of batched fetching (based on svn co) in the hope that it would reduce the problem, but without any proof beforehand that it would. [10:43] SteveA: for doctests, I wonder if it would be better to configure the logging subsystem to send messages to stdout [10:43] so that people would need to account for the messages in their tests [10:43] jamesh: yes, i think that would be good. === Seveas [n=seveas@dyn127.roaming.few.vu.nl] has joined #launchpad [10:47] jamesh: I fixed some test noise from the librarianformatter tests - log messages were bubbling up to the root logger. === Treenaks [n=martijn@messy.foodfight.org] has left #launchpad [] [10:49] stub: I found the doctests in scripts/logger.py were one of the culprits -- they left the root logger configured with the LibrarianFormatter handler attached [10:50] jamesh: yes. I've landed a fix that just set 'propagate=False' on the custom logger [10:50] so that might conflict with your work [10:51] stub: nope. I didn't find any problems with those tests (I did check if they were one of the culprits [10:56] jamesh: erm... yer. the doctests in scripts/logger.py are the ones I mean. The propagate=False fix means you don't have to mess with the root logger. [10:57] (at least the noise I fixed didn't) [10:58] stub: the tests in the docstrings for logger_options() and logger() were the ones that were messing with the root logger. [10:59] stub: my other fix was to configure the root logger again in FunctionalTestSetup.setUp() [10:59] ok [10:59] You configure it to raise an exception if used ;) ? [11:00] Probably too much code to fix if you did that... [11:00] no [11:00] it was already being configured to put all the log messages in a StringIO instance [11:00] oh... never knew that ;) [11:04] hmm [11:06] if you don't call close() on a logging handler, it never gets freed until you call logging.shutdown() [11:08] carlos: you have new mail (in fact, two new mails, seeing as i forgot to attach the review the first time) === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad === jbailey_ [n=jbailey@testhaus.cns.utoronto.ca] has joined #launchpad === sivang wonders if there is already or is planned a todo list tracker for lanchapd. if not would be keen on suggesting that as a BOF [11:27] *launchpad [11:27] carlos: so, do we not bring Universe packages into Rosetta? [11:28] sivang: the spec tracker is a bit like that. === sivang looks === sabdfl [n=mark@pdpc/supporter/silver/sabdfl] has left #launchpad [] === jinty [n=jinty@205.134.224.215] has joined #launchpad [11:35] SteveA, ok, thanks [11:35] carlos: what's the answer to what mark asked above? [11:36] SteveA: maybe you can help, do you have any general strategy to help tracking memory leaks in python, that are likely to originate from an extension module? [11:36] ddaa: like, C code? [11:36] C++ actually, but yeah [11:36] here's what i do [11:37] 1. get a debug build of python [11:37] that's more than just symbols, it has extra code in to track memory usage / garbage / etc. [11:37] 2. build your extension against that python === eruin [n=eruin@unaffiliated/eruin] has joined #launchpad [11:38] 3. run the test suite using the options to run it in a loop, and output object counts after each cycle [11:38] 4. narrow down the set of tests you need to run in a cycle while still seeing certain objects increase in number [11:38] 5. write your own test to make it even more minimal [11:39] 6. scrutinize this minimal code path to check for problems in the extension code along that path === ddaa points out that the extension code is essentially libsvn... [11:39] that sounds very cumbersome [11:39] 7. give up and ask jamesh to look at, because he's proved himself very good and finding such problems ;-) [11:40] ddaa: it's fiddly, but it uses divide-and-conquor to get the job done [11:40] hihi [11:40] is there a way to connect with a specific dbuser in a doctest? [11:40] so, I guess the first step is running the test suite in a loop and checking that memory usage grows, right? [11:42] ddaa: yes, or a subset of the test suite [11:43] yeah, of course [11:43] spiv: Twisted does longest-prefix-first matching when resolving a request for a server which has an object attached to /foo/ and one attached to /, yes? [11:43] there are specific options to help with this in the zope test runner [11:43] look at launchpad's test.py perhaps [11:43] SteveA: well, cscvs is not zope stuff :) [11:43] but I think I get the idea [11:45] Kinnison: you mean twisted.web? No. [11:45] It does it pretty much the same way as Zope: path segment by path segment. [11:45] SteveA: is there a python functionality to monitor memory usage process-wise (i.e. the leak might be in C++ structures that the gc is not aware of)? [11:45] At least, with the default Resources it does. You could implement all sorts of crazy stuff if you really wanted ;) [11:45] spiv: so it does shortest-first? [11:46] ddaa: i don't know. ask jamesh. [11:46] Kinnison: The question doesn't really make sense. [11:46] okay, allow me to give you context [11:46] BjornT: setup = LaunchpadTestSetup(); setup.dbuser = 'foo'; setup.setUp(); .......; setup.tearDown() [11:46] jamesh: is there a python functionality to monitor memory usage process-wise? [11:46] the buildd slave has an XMLRPC interface on / [11:46] Kinnison: it treats it as a hierarchy, not as an opaque string [11:46] I want to add a simple HTTP interface to the filecache on /filecache/ [11:46] Kinnison: For a path /a/b/c, it'll do root.getChild('a'), then do .getChild('b') on the result of that, and so on. [11:47] BjornT: That should also work with other subclasses, like LaunchpadZopelessTestSetup. LaunchpadFunctionalTestSetup will be problematic though. [11:47] And whereever that stops, it calls render. [11:48] BjornT: Although if this is for process-email.py, you might want to use the subprocess module to invoke the actual script so that is tested too (see the test_update_stats.py for example) [11:48] Kinnison: The short answer is: root.putChild('filecache', static.File('blah/blah/filecache')) [11:48] root? === Kinnison is not a very twisted person [11:49] Kinnison: Whatever resource you're passing to server.Site === Kinnison looks at buildd-slave.tac [11:50] stub: setup = LaunchpadTestSetup(); setup.dbuser = 'foo'; still makes the test pass [11:51] Kinnison: Hmm, XML-RPC is a bit funny, because some clients will hit "http://foo/RPC2" when you tell them the server is at "http://foo/RPC2". [11:51] Kinnison: Let me do a quick patch for you. [11:51] BjornT: Does your test do initZopeless itself? If so, you need to change that to initZopeless(dbuser=foo) [11:52] stub: using subprocess isn't an option here, since I need to look at the email notifications (i guess i could use subprocess for some tests, and call the function directly for some) [11:52] stub: it did use the normal setup. i change it to do what you suggested, but it seems like the dbuser is ignored [11:57] BjornT: How does your test get a connection? Or is it using LaunchpadZopelessTestSetup? [11:57] spiv: what will your patch do? [11:58] Kinnison: https://chinstrap.ubuntu.com/~dsilvers/paste/fileLVyrWj.html [11:59] Er, I should have said, 'hit "http://foo/RPC2" when you tell them the server is at "http://foo/"' [11:59] right [11:59] static.File() [11:59] that's a static file *root* yes? [11:59] Kinnison: Right. [11:59] coolio [11:59] thanks dude [12:00] (Or a single file. It's happy either way) [12:01] stub: it's currently using LaunchpadTestSetup, since it needs to look at the email notifications. is there any way of using LaunchpadZopelessTestSetup and have the sent email end up in test_emails? [12:02] spiv: was it you who told me to use SafeConfigParser instead of ConfigParser? [12:02] stub: (the test also needs to use the same security policy as the web app) [12:02] Kinnison: Possibly. I told someone to use it :) [12:02] probably me :-) === Kinnison will change buildd-slave.tac to use SafeConfigParser while he's in there [12:03] BjornT: Hmm... that is working by accident I think. If you need to use the Z3 email stuff, that would require using LaunchpadFunctionalTestSetup to load the component architecture. And there is no way to change the user connected as in that case. [12:04] ddaa: nothing really accurate (there was a google summer of code project to product a memory profiler, but I don't know the status) [12:04] (working by accident because the CA is never actually torn down, which causes problems :-( ) [12:05] jamesh, ddaa: You can apparently make valgrind work with Python. [12:05] jamesh: I just mean something to answer simple question like "How much VM does this python eat?" [12:05] ddaa: one trick you can use is the fact that instances of heap allocated classes (i.e. ones not defined in C extension modules) hold a reference to their class [12:05] ddaa: poke around in /proc/$pid/status? [12:06] stub: don't all system documentation tests use LaunchpadTestSetup by default? [12:06] BjornT: I don't think we have any suitable fixtures for what you need at the moment. [12:06] ddaa: In theory the resource module can do stuff like htat. [12:06] jamesh: I think that would do the trick. I'm interesting in monitoring all process memory usage including what the GC does not know about [12:06] ddaa: I haven't usedit, though. [12:06] BjornT: They use LaunchpadTestSetup and FunctionalDocFileSuite combined, which pretty much duplicates LaunchpadFunctionalTestSetup. [12:07] ddaa: it'll be quite inaccurate though -- address space isn't returned to the system except for large allocations, so you'll be looking at the high water mark [12:08] jamesh: I just want to confirm that "running that code causes a memory leak, somehow, somewhere" [12:08] ddaa: okay. it might be enough for that kind of thing. [12:08] THEN I can start talking gc and figure out what kind of leak that is [12:09] ddaa: If you do want to interrogate the gc, http://twistedmatrix.com/users/spiv/countrefs.py may help. [12:09] spiv: thanks [12:09] spiv: does static.File() provide content-length headers properly? [12:09] Kinnison: Yes. [12:09] mh, no twisted crack in that, good [12:10] spiv: cool, ta [12:10] ddaa: Hah :) [12:10] stub: hmm, i'll look into if i change change my test, otherwise i'll wait with changing the dbuser of process-mail until you implement such a text fixture ;) === stub reads scrollback to work out when he volunteered [12:16] SteveA, the answer to mark's question is: Rosetta is importing universe translations but we don't have language packs for universe so the translations will not reach the archive unless the developer in charge of that package adds it by hand [12:16] are the MOTU aware of this? [12:18] not that I'm aware of [12:18] at least we didn't expect to have langpacks for universe [12:20] what module has the routine for joining bits of urls together? [12:22] i mean, are the MOTU aware of how they can get translations out of rosetta for use in the packages? [12:22] SteveA: unless it's written up somewhere, I doubt that we are [12:23] SteveA, I think so, but not 100% sure [12:23] we had some mails changed with pitti and sabdfl some weeks ago about this [12:23] but nothing more [12:24] aha, urlparse.urljoin, nm [12:25] spiv: Given I have two file handles (well, one file, one urllib) what is the accepted way of pumping the contents of slave_file into out_file ? [12:26] ajmitch, carlos, jordi: i think you guys need to talk about using rosetta for Universe sometime [12:27] ajmitch, We cannot use current language packs or they will grow a lot [12:27] something to talk about at UBZ [12:27] ajmitch, jordi I'm a bit busy atm.... [12:27] stevea: Given I have two file handles (well, one file, one urllib) what is the accepted way of pumping the contents of slave_file into out_file ? === Kinnison asks steve too :-) [12:27] ajmitch, if it can wait, then yes, better at UBZ [12:27] carlos: of course, the universe translations need to be separate [12:27] depends if we want to try & get them into breezy [12:28] ajmitch, in the mean time, the only solution I see is to get all translations from Rosetta and add them as a patch to the package [12:28] which will be a lot of work if there's many translations, I think [12:29] we can try for some key universe apps [12:29] is there a quick guide for getting the translations out for a package? [12:30] s/out/out of rosetta/ [12:30] ajmitch, every sourcepackage has an export/download link that let's you get a tarball with all translations [12:31] sounds easy enough for us then [12:31] if the source packages are imported for universe & translated [12:32] right [12:32] spiv, SteveA: never mind, I've stolen the loop from the librarian uploader [12:34] ddaa: how often are source imports processed for a product? [12:35] ajmitch: syncs are done every day, initial imports are done whenever I come around to it. [12:35] if a syncing branch appears out of date, I'm the right person to complain to. There are many failed syncs but I just do not have the resources to fix them. [12:36] If you want an import done in reliable way, ask me. I'll tell you if I hit a roadblock. [12:36] (or when it's done) [12:36] ddaa: right, gnuenterprise is sitting on testing - initial import failed a couple of weeks ago & svn url has changed since then [12:36] I'll have a look right now. [12:37] hm, svn might still be a little broken upstream [12:37] pleonasm [12:37] what do you mean, actually? [12:38] gnu enterprise server shifted recently, I can't recall if anon svn is working correctly yet [12:38] I'll ask you about it when I know it is :) [12:38] ajmitch: product description: I'm a bit puzzled [12:38] you say that it's a meta-project, but you say there is a RCS to import [12:38] that's contradictory [12:39] GNOME, Mozilla are meta-projects, they do not have a single RCS to import, they have several products instead [12:39] ok, the project has tools & a number of subprojects in the same svn [12:39] such meta-projects are "projects" in launchpad parlance, specific projects that actually release something are products [12:40] elmo, lifeless: Any chance one of you can tickle pqm ? [12:40] gnue/trunk ? === ddaa is confused [12:41] ajmitch: you mean that for release management, security fixes etc, gnue is a single product? [12:41] there are a number of packages that get released with different versions [12:41] so I'd say not then [12:41] so, how does the gnue/trunk relate to those packages? [12:42] each of them are in a directory under there [12:42] ajmitch: are you a bit familiar with arch/bazaar? [12:42] a bit [12:42] I've mainly been using bzr [12:43] same difference === ddaa rolls a cig [12:43] ajmitch: I hope I'm not annoying you by appearing nitpicky [12:44] not at all === ajmitch is picky enough with others :) [12:44] bah, their SVN instruction page is broken... [12:44] everything was recently shifted in the last week [12:45] You can browse the subversion tree online. -> 404 with a python traceback [12:45] ajmitch: I have the impression that either: [12:46] this was the first new product I did, to learn how it goes [12:46] 1. the actually trees to import are gnue/trunk/ [12:46] or 2. the gnue release process is a bit broken [12:46] importing separate trees & having separate products for each tool is better [12:47]