=== bradb adds a distro sp bug listing and filebug page, gets ready to review the URL changes (and a million other fixes) diff [12:07] good work bradb [12:07] sabdfl: revisions 2121/2373 1:09:24 [12:08] hiatus while I went to the xtc meeting [12:08] will let it run overnight, but I have high hopes [12:08] lifeless: no ways, still 1:09? [12:08] there's some improvements i'd like to jump in on right after this branch lands, like adding a sane distro sp details portlet (the DR SP doesn't feel right for a DSP, to me) [12:08] sabdfl: yeah, it was suspended :) [12:08] bradb: i will do fresh content objects for D+SPN, DR+SPN, etc soon [12:09] noted [12:09] lifeless: if it crashes, can you resume it gracefully? [12:09] sabdfl: no, though you can run it in segments and resume frm those [12:23] kiko: wasn't I supposed to get a langpack export a few "tomorrows" ago? === mpool [n=mbp@cor5-ppp1627.for.dsl.connect.net.au] has joined #launchpad [12:29] #malone [12:30] hi, BjornT or bradb? [12:30] mpool: hi [12:32] hi bradb [12:32] so we'd like to start tracking bzr bugs on malone [12:33] as you (probably) know, we have two codebases in one product, with one of them probably fading away [12:33] how should we set this up in malone [12:33] the main requirement is that users or developers interested in the bzr python codebase should never see baz bugs [12:33] and vice versa [12:33] it would be confusing and annoying if they get mixed in together [12:33] should we just create two products, or is there some way to keep them separate within one product? [12:34] oh, maybe we should have two products inside one project? [12:34] There's already a bazaar product in Malone [12:34] yes i know [12:34] but there doesn't seem to be any way to segregate bugs within it? [12:34] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA] clean up spec tracker pages (patch-2403: mpt@canonical.com) [12:35] mpool: Nope. Can you just create another product specific to bzr? [12:35] sure [12:35] just wanted to check if i was missing something [12:35] thanks! [12:35] no prob [12:35] btw, what do you expect the weather will be like at UBZ? [12:35] mpool: slightly BZ probably :) [12:36] but not -10 yet? [12:36] possibly, but i wouldn't expect that to be the average at that time of year [12:37] thanks [12:56] "124 files changed, 2033 insertions(+), 1107 deletions(-)" -- in BjornT's queue now === Alinux [n=Ubuntu@p54A382F4.dip0.t-ipconnect.de] has joined #launchpad [12:59] night all [12:59] sabdfl: looking good : revisions 2307/2373 0:18:08 [01:07] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA] clean up spec tracker pages (patch-2404) === bradb & # out === robitaille [n=robitail@p235-083.public.uvic.ca] has joined #launchpad [01:38] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA] clean up spec tracker pages (patch-2405) === Lovechild [n=dnielsen@love-sources/Lovechild] has joined #launchpad === stub [n=stub@203.214.4.72] has joined #launchpad === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad === depoll is now known as dePOLL [03:47] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] Next production config (patch-112: stuart.bishop@canonical.com) === mpool [n=mbp@cor5-ppp1627.for.dsl.connect.net.au] has left #launchpad [] === dePOLL is now known as depoll [04:52] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] Fix production version number in config (patch-113: stuart.bishop@canonical.com) === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] === BjornT_ [i=10183@82-135-221-189.ip.takas.lt] has joined #launchpad === Virtuall is now known as Virtuall[BZA] [05:45] Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2399 into production (patch-1: guilherme.salgado@canonical.com, rocketfuel@canonical.com) === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [06:13] Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2400 into production (patch-2: mpt@canonical.com, rocketfuel@canonical.com) [06:49] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Switch on db_statement_timeout in production Launchpad instances (patch-2406: stuart.bishop@canonical.com) === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad [08:28] Anyone going to bitch loudly if I take Launchpad down now for upgrades? Might be two hours or so this time. [08:29] stub: Database too? [08:29] Yup [08:29] Hmm, the authserver might be an issue for some people :/ [08:29] Need to do a full dump/restore I've been putting off for a while [08:29] think of the children [08:30] I should implement AuthServerCaching, I guess ; [08:30] ;) [08:30] spiv: I think that is pretty much in my court for 'setup a read only replica' === spiv quickly re-reads the spec === spiv smiles at Moin: "/!\The authentication database is temporarily unavailable. Anonymous access only." [08:32] stub: Hmm, there's a small amount of authserver code required too :) [08:32] But I think I've worked out how to do that with a minimum of hassle, but need to clear out a few other tasks first. Will give steve his readonly db too. [08:33] spiv: Yer, but that will only take you a few minutes ;) [08:33] Heh. [08:33] morning people [08:36] hail [08:38] And SteveA can see the launchpad down for maintenance page right now if he likes [08:39] Pitty Pound roots it by sticking its own headers at the top [08:41] ewww [08:41] does it *have* to? [08:42] it is probably a simple matter of code to fix it [08:42] Looks like it. We could hack Pound (and then we would need to repackage it for installation), or just do it in Apache. === dand [n=dand@gw.datagroup.ro] has joined #launchpad [09:36] Eek, gotta go... === spiv -> yoga === Keybuk [n=scott@217.205.109.249] has joined #launchpad [09:58] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Tweak Gina warning levels (patch-2407: stuart.bishop@canonical.com) === sabdf1 [n=mark@217.205.109.249] has joined #launchpad === sabdf1 [n=mark@217.205.109.249] has left #launchpad [] === mdke [n=matt@unaffiliated/mdke] has joined #launchpad [10:27] hi all [10:27] what is the ETA for lp being back? [10:27] 20 mins [10:27] thanks === niemeyer [n=niemeyer@217.205.109.249] has joined #launchpad === jinty [n=jinty@205.134.224.215] has joined #launchpad [10:49] Morning all! [11:04] stub: did you mean to merge the fix-whitespace stuff in -2407? [11:05] That's fine. PQM just ate my previous [trivial] on that branch. [11:07] righ [11:07] +t [11:07] just thought I'd point it out in case it wasn't meant to have happened [11:07] Kinnison: are you coming up tonight ? [11:08] lifeless: No, tomorrow morning === Kinnison is literally just doing the day [11:08] Kinnison: K === Kinnison expects to hit the office ca. 9.30 to 9.45 [11:08] any earlier and I'd have to leave tonight practically [11:09] and I have a date with a steel rule and a circular saw tonight [11:09] gotta prepare the kitchen for having the floor put in [11:15] Kinnison: into home improvements eh? :) === BjornT_ [i=10183@82-135-221-189.ip.takas.lt] has joined #launchpad [11:15] Kinnison: howdy [11:15] jordi, around? [11:15] sivang: aye === sabdfl [n=mark@217.205.109.249] has joined #launchpad [11:21] SteveA, how about now? [11:21] stub: ping [11:21] sabdfl: Pong [11:21] stub: can i privmsg you a db patch? [11:22] mdke: for a few mins [11:22] jordi, we have a huge problem with the faqguide.pot :/ [11:22] paste is better -- https://chinstrap.ubuntu.com/~dsilvers/paste/ [11:22] mdke: really? what is it? [11:23] jordi, launchpad is down so I can't show you it in rosetta, but if you go to sg you a db patch? [11:23] argh [11:23] start again [11:23] yeah, I can't parse that at all :D [11:23] if you go to https://docteam.ubuntu.com/repos/branches/breezy/generic/faqguide/C/faqguide.pot [11:24] ok [11:24] jordi, then search for installing-applications.xml:10(para) [11:24] done [11:24] that line is totally ridiculously long and includes a number of paragraphs in the actual text [11:25] wow [11:25] there's "See . " stuff in there. === jinty [n=jinty@205.134.224.215] has joined #launchpad [11:25] Have you contacted shaunm about it? [11:25] I suspect somethign in your xml is not so good. [11:25] wher'es the xml? [11:25] jordi, i pinged him now [11:26] I see it [11:26] https://docteam.ubuntu.com/repos/branches/breezy/generic/faqguide/C/installing-applications.xml [11:27] jordi, moving channel [11:28] #docs? === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad [11:33] jordi, what really worries me is that if we use a different utility to create a better pot file, then upload it, a lot of translation will be lost :/ === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [11:43] SteveA: ping === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:46] stub: mailed [11:46] mdke, jordi: PO is really not ideal for documents [11:46] but i can't think of a better plan right no9w [11:47] :( === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad [11:55] stub: s/person/owner/g [11:56] lifeless: If there are no dependancies of cscsv on launchpad, why do we need to run cscvs tests when we commit launchpad changes? It would be impossible for a launchpad commit to stop cscsv tests passing. [11:57] sabdfl, jordi, i don't know whether I should send an email to warn translators to stop translating the guide until the issue with the pot is resolved, what do you think? [11:57] stub: eh? cscvs uses lp interfaces [11:57] It does? Ahh bugger [11:58] are you referring to the race condition with nc ? [11:58] sabdfl: Argh.... a diff. Now I need to strip all the '+' signs :-( [12:01] stub: if you are happy with the comments i can send you the patch directly [12:01] sorry, the .sql file [12:01] sabdfl: Nah - got it. === stub is a master of vim [12:02] sabdfl: Looks fine. patch-25-26-0.sql. [12:03] stub: super, thanks [12:03] sabdfl: (pending the person->owner change of course) [12:04] stub: done [12:05] mdke: maybe it's wise. Let's see if you get something from the mailing list. [12:05] Hopefully you will === Kinnison workraves :-( [12:15] anyone want to review a quick publisher change? [12:15] It's a touch large to [trivial] but it needs to get in fairly soon [12:16] https://chinstrap.ubuntu.com/~dsilvers/paste/fileiJyx2B.html [12:16] It's d-i support for the C.A.P. [12:17] pep8ness [12:17] self._has_di, not _hasdi [12:17] dituples->di_tuples [12:18] also tup and tuples are really hirrble variable names [12:18] what is a didr ? [12:19] whats a comp ? [12:19] a didr is a debian_installer_distrorelease [12:19] if you have to explain it, the variable name is probably wrong [12:19] the variable's existence is there purely because otherwise the line is too long [12:20] I wanted to do self._has_di.setdefault(dr, Set()).add(comp) [12:20] but that wraps [12:20] and I think it's less ugly to use a temp var than to split it on the comma [12:20] its also pretty darn opaque [12:20] I'd docstring self._has_di if you could do that sort of thing [12:20] I didn't critque the temp vars existnece, I critiqued its name [12:21] you'll have less problems with line wrapping if you write smaller functions too [12:22] Hmm [12:22] Okay, I'll tidy up the pep8ness and try and make the stuff more understandable [12:22] so rather than a detailed review, I suggest you read it out loud to a teddy bear. [12:23] and anytime its face gets blank, make the code more clear === Kinnison points out that he pair-programmed this with freddybear anyway === Kinnison waves freddy at lifeless [12:24] freddybear obviously knows too much about buildds [12:24] He helped me write the publisher :-) [12:25] jordi, mailed [12:25] mdke: the list? [12:25] oh, the translators. [12:25] let's hope we can resolve this ASAP [12:25] everything :D [12:26] jordi, i'm going to try the kde util and see if the pot file is any better [12:26] mdke: xml2po was missing info, or was it just doing huge para's? [12:26] mdke: nod [12:26] jordi, both I think [12:26] let's see what you find out [12:26] maybe confuses it. [12:26] What's the dict iterator which gives you key,value tuples? [12:26] is it .items() [12:26] ? [12:27] ddping [12:27] jordi, yes, it may not support qanda set [12:29] jordi, can you push my mail through to rosetta-users, it needs to be moderated [12:29] in a min [12:30] thanks [12:30] it hasn't got through to any list :/ [12:31] i'll cancel and try again [12:32] yours is accepted [12:32] thanks [12:35] mdke, thx [12:56] stub: pong [12:56] SteveA: We are still getting lockups. Looks like long running or blocked queries. [12:57] SteveA: Possibly update-stats.py is the culprit [12:57] interesting. why would that lock up the webapp? because the postgres backend is so busy? [12:57] or are some tables locked? [12:58] SteveA: If a process has updated rows, but not committed, anything selecting on that table will block [12:59] does update-stats.py do that? as in, not commit for a while after updating stuff? [01:00] if you selectively kill off cron jobs, does the webapp return? [01:00] SteveA: Yes. But I'm not 100% sure yet. [01:01] SteveA: It might also be these rosetta queries too just taking too long [01:10] well, i can't access launchpad.net now [01:10] can you kill all cron scripts ? [01:11] would the DB need bouncing too? [01:12] lifeless: is https://chinstrap.ubuntu.com/~dsilvers/paste/file9TWzrW.html better? [01:12] has_di ? [01:12] what's a "di" >? [01:13] comment or better variable name please [01:13] ahahaha [01:14] Kinnison: see! === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [01:15] Kinnison: still very opaque. steve's commend is right on [01:15] s/mend/ment === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [01:15] Kinnison: i.e. whats a di_tuple ? really, what does it _mean_ not what typ eit is. [01:17] okies === Kinnison tries not to assume that anyone playing in the publisher will understand what di is === Kinnison goes through to add comments [01:18] better names >> comments [01:18] so _has_debian_installer_inside_components_for_distrorelease ? [01:18] I'm all for good variable names for simple things :-) [01:19] I don't get whaat has debian installer inside components for distrorelease means [01:19] tell me about this, here, in englihsh [01:19] I'll try and translate to english. [01:19] Okay [01:19] so each distrorelease has a bunch of components in it [01:20] some of those components will contain binaries which are for debian-installer rather than the distrorelease itself [01:20] we have to note down which components of which distroreleases have debian-installer bits in them so that we can construct the correct configuration for apt-ftparchive later [01:20] in _has_di I store (keyed by distrorelease name) a Set of the component names which contain debian-installer binaries [01:21] so that is the 'debian installer components for distrorelease' ? [01:21] More 'components for debian-installer by distrorelease' [01:22] ok. [01:22] thats understandable. [01:22] But that's 'what' rather than 'why' [01:22] now, you have a dictionary of distroreleases with the components for d-i in that release [01:23] what about _di_release_components ? with a comment that this is the components for d-i in each distro release [01:23] or release_di_components [01:24] may well still need a comment, but at least is a vaguely informative variable name [01:24] is PQM jammed? [01:24] I've put a comment in anyway, detailing what it stores, where it is generated and where it is consumed [01:24] because I think that'll be useful [01:25] so it's just chosing a name [01:25] sabdfl: was === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [01:26] pqm didn't allow my merge, with ERROR: testAnwersOnce (CVS.tests.test_CVS.PServerHelperTest) [01:26] SteveA: thats the CVS race condition [01:26] lifeless: can we disable these CVS tests for a while, until they are reliable again? [01:28] SteveA: up to you, do you trust us not to break launchpad via cscvs, or vice verca [01:28] s/launchpad/importd [01:28] Kinnison: moving right aling [01:28] i don't care about breaking the specific code that the tests that have a race condition test [01:28] because the tests are faulty [01:29] uhm, they aren't testing a race condition, there is a race condition in th etests that is causing the problem [01:29] that's what i meant. my english was ambiguous. [01:30] jamesh: ping [01:31] SteveA: pong [01:32] hi. stub says that the code that is supposed to make long-running queries time-out doesn't seem to be working. [01:32] lifeless: okay, added explanatory comment in __init__ and renamed _has_di to _di_release_components [01:32] i'm looking at canonical/database/adapter.py now [01:33] Kinnison: rediff, lets have a look [01:33] running now === Kinnison hasn't had a chance to flcow his desktop yet [01:33] jamesh: can you take a fresh look at it, just to see if anything obvious looks wrong [01:34] SteveA: what value do you have db_statement_timeout set to in the launchpad.conf? [01:36] 60 [01:36] we should have at least a manually runnable functional test for that [01:36] (Originally 4000, but I knocked it down a bit in case it was seconds instead of ms) [01:36] like, a deliberately slow query on a page on the debug skin [01:37] Doesn't need to be a page test. Can fake a slow query easily enough using a Python server side procedure. [01:37] it seems to work here === stub continues to wait until his branches commit so he can test [01:38] jamesh: how did you test it? [01:38] SteveA: set it to a low value, and then ran some other job to burn CPU time [01:38] ddaa: ping [01:38] also, the "print" should be a log surely [01:38] lifeless: pong [01:39] ddaa: how did pythons cvs import go ? [01:39] ddaa: and how is the svn fi for samba looking ? [01:39] I got a "ProgrammingError: ERROR: canceling query due to user request" exception [01:40] python has failed twice since the sprint for various connection problems, right now it's at changeset 10043 [01:40] SteveA: unfortunately, it is a statement timeout rather than a transaction timeout [01:40] ddaa: out of ? [01:40] so it is possible for a query to do a lot of work and still not hit the timeout [01:40] out of 32425 [01:41] ddaa: thanks. [01:41] jamesh: okay. so, we should also have an overall request processing timeout. [01:41] stub and i discussed this before. [01:41] one way to do it is to have the database adapter check some value before each query [01:42] yesterday, had a short day to sort some appartment related issues, and spent it all on replying spiv's review for the nested log parsing (python fix) patch for cscvs [01:42] and have that value change when the request has gone on too long [01:42] jamesh: Can you issue a few more requests and see if it still happens (ie. that the setting isn't reset next time that handler thread handles a query) [01:42] so, nothing new for samba, but it's the next thing to do === stub is still waiting for his commit to commit [01:42] lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileXl82lz.html [01:42] either the value can be the latest time some query can start to be executed [01:42] or the value can be a boolean that is set by an event [01:42] ddaa: ok. please keep me posted, Its very urgent [01:43] I suppose we could do that by recording when the transaction started, and rollback/fail any future statements past the timeout [01:43] setting to a max value is probably the simplest, although it does mean regular calls to time.time() i guess [01:43] i don't know how expensive time.time() is [01:43] not for a transaction -- for the whole web request. [01:43] so, the web publisher would set the value upon receiving the request for processing [01:44] and unset the value at the end of that request's processing [01:44] the value would be thread.local [01:44] or, set on the connection used for that thread, if there is definiely one connection per request. [01:45] a thread.local seems less tightly coupled to connection policies though [01:45] and, i want to decouple these things for supporting read-only connections for GETs [01:45] so at what points do we check the timeout? [01:45] You could perform the check in the database adapter - that seems a common point to do the check and raise an exception if the request has taken too long [01:45] okay [01:45] stub: yes, i think that's what i meant to say above [01:47] both these things together, that is, max request time and max single query time, should make the webapp more available in general. [01:47] Read only connections are just a case issuing 'set transaction read only' it turns out btw. [01:47] oh [01:47] so, no need for an extra user [01:47] that's cool [01:47] i can do that today ;-) [01:47] so, that can be added to the launchpad database adapter too [01:47] i mean, a method to say "set transaction read only" [01:48] Just make sure it gets set back again too ;) [01:48] hmm... [01:48] but there can be many transactions in a single request [01:48] i want all transactions for that request to be read only [01:49] eh? There is only one transaction per request. You are thinking connections. [01:50] there can be more than one transaction per request [01:50] for example, when someone commits [01:50] Nobody should be committing in the webapp [01:51] And Zopeless doesn't use the DA anyway [01:51] according to my grep, only script code is committing [01:51] so, that's good [01:52] i'd still rather do it right, if it isn't so hard to do [01:53] mdke: oh dear. [01:53] I suspected xml2po didn't like something in the doc. === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [01:54] We should make the publisher raise a 503 or something if there are more than X requests in the queue waiting to be handled [01:54] erm... the http service I mean, not the publisher [01:55] Kinnison: your comment talks about _has_di! [01:55] lifeless: arse, well spotted [01:56] still go tthis 'di_tuples' thing [01:56] tell me about di_tuples [01:56] it is a list of the tuples we save to output to the di overrides instead of the normal overrides [01:56] thats in these tuples ? [01:57] s/that/what/ [01:57] assuming you mean "what's in these tuples?" the answer is "a set of columns to be output tab-separated to the override files" [01:57] specifically package name, priority and section [01:57] so it would be reasonable to call them 'di_overrides' ? [01:57] aye, I guess that'd be sane === Kinnison makes that change [01:58] would it be clearer :) === Kinnison gets workraved, keep on complaining here :-) [01:59] calling something that is a list of type-X's thing-'Xs' or 'X'-things is usually very unclear === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:59] its like [01:59] ints = [1,2,3,5,7,11,13 ..] [02:00] when what you use it for is 'for prime in ..' [02:00] so, rule of thumb I'd like you to imprint on your brain: when you see a type name in a variable name, THINK HARD. [02:01] for name in names -> what are they names of? package_names ? file_names ? === Kinnison nods. I'll do my best to remember that [02:02] file_names [02:02] drfullname <- pep8ify please [02:02] stub: surely apache / pound can do the "too many requests" error, and not even pass it on to zope === Kinnison yeuchs [02:03] I do so hate under_scored_variable_names [02:03] they're uggerlee :-) [02:03] https://launchpad.net/ gave me a 502 proxy error, with a nasty error page. [02:03] SteveA: Pound can't. No idea about Apache. === Kinnison must print out the parts of PEP8 which he keeps forgetting and stick them to his wall [02:04] i'm getting launchpad pages again. hurrah [02:04] Yay specs page not found [02:04] Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2406 into production (patch-3: stuart.bishop@canonical.com, rocketfuel@canonical.com) [02:04] stub: one line fix [02:05] stub: the link in the menu is to /+specs, but the page is (and should be) just /specs [02:05] it is correct in staging [02:05] want me to find you the line that needs to change? [02:06] Kinnison: + cnf.write(s % { [02:06] + "LISTPATH": self._config.overrideroot, [02:06] I'm working on lockups atm ;) [02:06] that stuff, could benefit by being put in a smaller more readable funtion === SteveA finds the line for stub [02:06] Kinnison: i.e. 'self.write_component' === Kinnison fails to see how that'll actually improve matters [02:07] given that it's a long argument list, so it'd be best served with named arguments [02:07] the calling code will be a shorter semantic statement [02:07] and thus won't be any timpler [02:07] the dirty stuff will be out of the way [02:08] you mean hide the d-i changes behind some "isDebianInstaller=True" argument or something? [02:08] def write_di_component (self, dr, pocketsuffix[pocket] , component, arches) [02:08] dor instance. [02:08] bah, for. [02:08] it'd have to cope with the non-di situation too [02:09] def write_component(...) [02:09] let me put it another way. you ahve a _long_ function that you are making longer. === Kinnison shrugs [02:10] it doesn't feel right/useful to me to split it out, but I'll do so if you think it's important [02:11] can you paste the entire file up? I'd like to see it in context [02:11] jordi, yeah. well at least hopefully we can figure out how to fix it [02:11] jordi, this danilo guy sounds helpful :D [02:11] https://chinstrap.ubuntu.com/~dsilvers/publishing.py [02:12] mdke: danilo is the man [02:12] Internal Server Error [02:12] jordi, cool [02:12] lifeless: wowyay [02:12] https://chinstrap.ubuntu.com/~dsilvers/publishing.py.txt ? [02:12] mdke: plus, lives in a decent timezone :) [02:12] Internal Server Error [02:12] try publishing.txt [02:13] pub.txt [02:14] ok. [02:14] this makes some stuff clearer [02:14] 's' is a template for the apt output yes ? [02:14] yeah [02:14] It's a poor name [02:14] I've already changed it to "stanza" [02:14] why is it in the for pocked in loop ? [02:14] but I didn't upload that [02:14] thats ok, I'm not blaming you :) [02:15] because it's dumb === Kinnison moves it out [02:15] updated pub.txt [02:16]