[12:39] thanks sladen === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad === Lovechild [n=dnielsen@0x50c71cc7.adsl-fixed.tele.dk] has joined #launchpad === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad === aatim [n=aatim@202.138.138.20] has joined #launchpad === niran_ [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad [04:51] Merge to rocketfuel@canonical.com/launchpad--production--1.31: Cherrypick patch-2345 into rocketfuel (patch-3: carlos.perello@canonical.com, rocketfuel@canonical.com) === superted [n=superted@213.167.101.222] has joined #launchpad === peloverde [n=alex@129.22.169.230] has joined #launchpad [06:02] why does launchpad think that gnuradio-examples is an invalid source package name? [06:04] Probably because that package information hasn't been imported into launchpad yet :/ [06:06] It doesn't mind "gnuradio" which isn't the real name, thats what i'm going to file bugs under [06:07] am i supposed to manually assign to MOTU or anything like that> === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [07:09] Given the byte string 'Invalid value \xff\xfeh\x00e\x00l\x00l\x00o\x00', what would be the simplest way of converting it to 'Invalid value \\xff\\xfeh\\x00e\\x00l\\x00l\\x00o\\x00' (ie. replace unprintable and non-ascii characters with backslash notation) [07:10] I got a string in an unknown and possibly invalid character set and I need to spit it out an ASCII stream [07:10] repr('Invalid value \xff\xfeh\x00e\x00l\x00l\x00o\x00') ? [07:10] spiv: Nah - that will give be "'Invalid value... '" (ie. an extra set of quotes) [07:10] spiv: And I want ASCII strings to pass through unmolested. [07:11] repr(...)[1:-1] then ;) [07:11] But yeah, it will molest quotes. [07:12] Hmm... [07:12] Use codecs.register_error('backslash', xxx)? [07:12] encode('ascii','backslashrepace') doesn't work which sucks... don't know if it supposed to [07:13] hmm... [07:14] Although there is already supposed to be backslashreplace [07:16] m.decode('ascii', 'replace').encode('ascii', 'backslashreplace') [07:16] That seems to do the trick [07:16] Although I end up with Unicode references in there instead in some cases instead of \x notation, but that will be good enough === niran [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad [07:51] morning! [07:52] good morning SteveA, up early today? :) [07:52] earli0ish [07:52] too early to type properly [07:53] yo [08:00] I'll put staging back on the daily devel--0 code [08:01] (But not the database resyncs until Carlos gives me the nod) [08:07] surely that will cause a bunch of failures [08:07] as the database schema will not be in sync with the code [08:12] No - the schema will be updated, but the data will not. [08:12] ok [08:13] (procedure is normally sync the database, upgrade the schema and code, restart. Nothing new here, nothing to see, move along ;) ) === BjornT goes away to learn some lithuanian [08:31] kaip? [08:31] kaip btent? === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [09:27] hi guys [09:28] stub: do you think you could track down the cause of IntegrityError -> ProgrammingError on Breezy? [09:28] if you need a breezy login, I can provide one [09:29] jamesh: ping [09:30] sabdfl: I don't have a spare box to run breezy. I expect it is simply that breezy has a newer version of psycopg. [09:30] sabdfl: I would rewrite that test as: [09:30] try: [09:31] bad_task = bugtaskset.createTask(...) [09:31] except psycopg.DatabaseError: [09:31] print 'A database exeption was raised' [09:32] hmmm... we do have a different psycopg package, but it's not the latest upstream [09:32] could you investigate that please, and see if we should be syncing in a newer one from debian? [09:32] Are you running against 8.0 or 7.4? [09:33] (PostgreSQL) [09:33] sabdfl: i spoke with doko about that [09:33] stub: 7.4 [09:33] and i spoke with vdg, the author [09:33] or rather, doko spoke with him [09:33] the current version of psycopg is bogus and buggy [09:34] ok, so we stick with the current one in breezy [09:34] vdg is releasing a new version very soon that addresses the regressions / problems [09:34] but it hasn't reached debian yet [09:34] too risky [09:34] right [09:34] so, that's the psycopg situation [09:34] sabdfl: yeah? [09:34] i think we already have the patches from jamesh [09:34] in the ubuntu package [09:34] jamesh: have you had a chance to look at the spec bits? can we talk about a schedulo-matic? [09:35] there was one other segfault issue in the changelog i think, that someone else than jamesh found [09:35] SteveA: all my psycopg patches went into hoary [09:35] so we might want to get that one patch applied [09:35] ok [09:38] sabdfl: I've had a quick look over the basic data model. So the idea of the schedulomatic would be to take a collection of specs + subscriptions and try and schedule things? [09:39] jamesh: basically [09:39] let's hammer over some details by privmsg [09:39] (and dependencies) === carlos [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad [09:48] morning [09:49] sabdfl: pong [09:52] lifeless: can i ask pqm to specifically take one changeset and apply that? [09:53] or, would i need to make a branch that is suitable for star-merging, and reply that changeset onto my branch, and then ask pqm to starmerge that branch? === cprov [n=cprov@217.205.109.249] has joined #launchpad [09:54] SteveA: you can give it a specific patch and the replay command, but for anything going into mainline, please do not do that. [09:54] ok [09:54] SteveA: as it will cause failed merged later. [09:58] SteveA: https://shipit.staging.canonical.com/ is running trunk, but isn't working. Also the links that are there point to localhost. Anything to worry about, or is there more stuff to land still? [10:00] lifeless: np, was xml question that stevea answered last night [10:00] what does "isn't working" mean, specifically? === SteveA looks at https://shipit.staging.canonical.com/ [10:01] hmm, not sure the virtual hosting stuff is working properly [10:02] stub: we need to check with elmo about the rewrite rules that are being applied. [10:02] stub: can you look in the logs on staging to see what requests are being sent? [10:02] I can probably see the rules on asuka... hang on. [10:04] https://chinstrap.ubuntu.com/~dsilvers/paste/fileLa64hi.html [10:05] https://chinstrap.ubuntu.com/~dsilvers/paste/files2aYOr.html [10:06] that first one looks correct to me [10:07] it may be just something about the error page is wrong [10:07] can you get some zope request logs from staging, and grep them for 'shipit' ? [10:12] https://chinstrap.ubuntu.com/~dsilvers/paste/fileehnppi.html [10:12] SteveA: ^^ [10:13] https://staging.canonical.com/ gets me a 502 now [10:14] so, something is screwed [10:17] stub: how long are you around for? [10:17] I was going to take a break before the meeting - you need me now? [10:17] well, i want you and elmo to work out why staging is not working [10:17] i can phone elmo and see when he can do it [10:18] shipit is the same as before for me - no 502 there. [10:18] (and staging) [10:18] you get a webpage from staging? [10:18] Yes [10:18] https://staging.canonical.com/ [10:18] from there? [10:19] https://staging.ubuntu.com [10:19] canonical.com is busted === ddaa [n=ddaa@217.205.109.249] has joined #launchpad [10:19] (no idea if it ever worked...) [10:19] oh [10:20] so, i made a mistake asking elmo to put shipit on shipit.staging.canonical.com [10:21] oh i see an error [10:21] https://chinstrap.ubuntu.com/~dsilvers/paste/fileLa64hi.html [10:22] stub: see the RewriteRule -- uses http: but port 443 [10:22] Oh... yes. [10:23] i guess that's an admins job? [10:24] as in, i suspect you have read-only access to those configs [10:24] Yup [10:25] would you mail RT ? [10:25] what do you think about changing it to shipit.staging.ubuntu.com too? [10:25] Doing it now [10:26] ta [10:27] staging should really be staging.launchpad.net, although shipit shold be shipit.staging.ubuntu.com. Or something. Ermm... perhaps we should write all these urls down somewhere so we can make them a bit saner ;) === sabdfl [n=mark@217.205.109.249] has joined #launchpad === carlos -> breakfast [11:01] spiv: ping? [11:02] Kinnison: pong [11:02] spiv: I've just put a (very short, very easy) branch in your queue [11:03] It's a very small librarian feature which we need for dogfooding the buildd system === Kinnison would appreciate it if you would look it over [11:03] I'll take a look. [11:03] lifeless had a very very quick glance over it at breakfast for me === dand [n=dand@gw.datagroup.ro] has joined #launchpad [11:06] I got through 5 lines and stopped. [11:06] (for clarity) [11:07] but there were only 20 lines anyway === Kinnison laughs === ddaa [n=ddaa@217.205.109.249] has joined #launchpad [11:19] Kinnison: +>>> re.search('^http://NOT\.VALID\.COM/\d+/\d+/text.txt$', url) is not None [11:19] Use raw strings with regexes. [11:20] You're lucky that neither \. or \d has special meaning in current python, but you shouldn't rely on it. [11:20] Erm, I *copied* an earlier test [11:20] :-) [11:20] shall I fix up the earlier tests to use r'' ? [11:20] spiv: you are bad, it was your test. [11:20] :) === lifeless whips spiv [11:21] Kinnison: Please :) [11:21] lifeless: Don't blame me, blame my reviewer ;) [11:21] rotfl [11:22] I don't understand why the buildd does simply use a different config? [11:22] s/does/doesn't/ [11:23] because the buildd master sometimes downloads stuff from the librarian too [11:24] we simply need a different URL base when we generate a URL to pass into the restricted slave network [11:25] Which system is "we" here? [11:26] spiv: buildd-slave must access librarian through an internal vh, just it [11:27] cprov: I understand that part. [11:27] The buildd slave gets the URL from the buildd master, doesn't it? [11:27] spiv: so "we" is buildd-slave farm [11:28] spiv: yes, it does [11:28] (I should've been clear that I meant the "we" in "we generate", damn English :) [11:28] spiv: specfically from getURLForAlias() [11:28] So why not just run the buildd master with a different config that has download_url set appropriately? [11:29] spiv: it shoudl probabbly be a lot of config overhead, 50 options for only 1 change. [11:30] spiv: Mostly because the buildd master may also download files [11:30] spiv: and it needs the appserver download url, not the one presented to the restricted network [11:30] spiv: the only motivation i can see for use another config section is using another DB, which isn't the case. [11:31] Ok, that's what I was looking for -- specifically that the master also needs a download_url that works for it, and at the same time needs to be able to give the slave urls that the slaves can use. === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad [11:32] It still feels a bit odd to me, but it is a small change. [11:33] If you can clarify in a comment/doc somewhere that there needs to be two different download_urls coexisting in the same process, then you have r=spiv. [11:37] Should I do that in the schema.xml, the doctest, or the client.py ? === niran [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad [11:38] Or in the configs themselves? [11:39] In the schema or the doctest. [11:39] The doctest seems to have the most comprehensive text on the subject so far. [11:39] Although in theory the schema is a better place for it. [11:39] I have a strong gut feeling we'll need to revisit this change, but it's not particularly complex, so I'll just deal :) [11:50] okay [11:50] I'll put it in both the schema and the doctest === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === BjornT [i=10183@82-135-221-189.ip.takas.lt] has joined #launchpad [12:22] I think PQM is stalled again... [12:22] lifeless, ? [12:33] killed nc === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad [12:34] hey elmo [12:36] Merge to rocketfuel@canonical.com/pyme--devel--0.6.1: add gpgme_op_trust() wrapper [r=spiv] (patch-2: james.henstridge@canonical.com, robert.collins@canonical.com) [12:40] lifeless, thanks === mdke [n=matt@unaffiliated/mdke] has joined #launchpad === BjornT [n=bjorn@82-135-221-189.ip.takas.lt] has joined #launchpad === Alinux [n=Ubuntu@p54A3A033.dip0.t-ipconnect.de] has joined #launchpad === Alinux is now known as AlinuxOS === mdke [n=matt@unaffiliated/mdke] has left #launchpad [] [01:16] developers meeting in 25 mins [01:16] /msg me items for the agenda [01:16] spec system and shipit are already on the agenda [01:17] erm, surely 40m to meeting? [01:18] i slipped [01:18] yeah, 42 mins [01:18] phew [01:18] stop playing with time vortices [01:19] you should have told me earlier! === Kinnison will have told you in 20 minutes from the other time. [01:20] which was 12 minutes ago in the future [01:21] Why does launchpad forget my login? [01:21] I can appreciate it not remembering over browser restarts (secure cookie and all that) [01:22] but not remembering from one hour to the next [01:22] this is *INCREDIBLY ANNOYING* [01:22] (I'm sure this isn't the first time I've brought this up) [01:22] it ought to remember. perhaps a bug in server affinity... [01:23] are the sessions not in the shared zodb? [01:23] there is no shared zodb [01:23] there is one session storage per server [01:23] oh [01:24] that sucks [01:24] so if an appserver goes down, we lose all the sessions on it? [01:24] yes [01:24] we have plans to improve it, but there have been higher priorities [01:25] Right [01:25] that makes sense [01:25] it isn't a showstopper after all === Kinnison takes his 'user' hat off :-) [01:29] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fixed corner case when fixing missing/extra leading/trailing whitespace characters + tests added for it (patch-2367: carlos.perello@canonical.com) [01:30] carlos: Mark found the bug which was causing dogfood to explode [01:31] carlos: Someone added 'datecreated' to the orderBy in distribution.py === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad [01:31] Kinnison, really? what was it? [01:31] hmmm [01:31] Kinnison, I didn't know about any other problem outside the missing code problem you had [01:32] Kinnison, anyway, is it fixed on rocketfuel? [01:32] carlos: It's very odd that it's not causing explosions elsewhere === Kinnison will send a [trivial] fix later today [01:32] ok === Kinnison is waiting on an archive-mirror to complete so he can submit two merges [01:33] then I'll prepare a shortfix for that === segfault [i=carlos@prognus.com.br] has joined #launchpad [01:33] morning. [01:40] Kinnison, ok, thanks === Kinnison workraves === niran [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad [01:50] carlos: any rosetta issues for the agenda? [01:50] SteveA, hmmm perhaps someone that could take care of urgent problems while I'm on holidays? [01:50] other than that... nothing that I can think on === mpool [n=mbp@cor6-ppp610.for.dsl.connect.net.au] has joined #launchpad [01:51] carlos: btw, did you pull in the extra gettext validation checks I had on my branch? [01:52] jamesh, hmm, sorry, I forgot that... [01:52] jamesh, please, remind me the branch and I will take a look now [01:52] carlos: if you want I can put it up for review separately (if it doesn't fit in with what you're doing right now) [01:52] hey all [01:52] carlos: james.henstridge@canonical.com--2004/launchpad--smallfixes--0 [01:53] carlos: do you know when rosetta (ubuntu) syncs with GTP for the last time before breezy is released? [01:53] jamesh, well, it fits, your checks will detect If I'm missing anything with my latest changes [01:53] superted, with last package uploaded into Breezy [01:53] sivang, hi [01:53] superted, usually the .1 release (2.12.1) [01:54] carlos: ok, thanks === mpt [n=mpt@201-1-132-73.dsl.telesp.net.br] has joined #launchpad [01:57] hey mpt [01:57] hi Kinnison [01:58] carlos: did you see Bruno's response to the bug report about adding extra checks to libgettextpo? === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:00] jamesh, yeah, and that makes me feel that we should take another approach, instead of use libgettextpo use something more python friendly... [02:00] jamesh, anyway, we need to do our own stuff [02:00] meeting time, right? [02:00] carlos: gettextpo still seems the best way of performing the format string checks [02:01] SteveA: meeting time [02:01] morning [02:01] YOYOYO [02:01] Here! [02:01] There! [02:01] so it is [02:01] jamesh, yeah, but we could sync the C scode from time to time and use a better API [02:01] let's start the meeting [02:01] MEETING STARTED! [02:01] And I'm up to date [02:01] who's present? [02:01] me [02:01] I'm here [02:02] me [02:02] me === Kinnison . [02:02] I am === carlos is here [02:02] I'm not. [02:02] carlos: there is a _lot_ of code there (more than just C format strings) [02:02] here [02:02] ddaa: liar! [02:02] me [02:02] me [02:02] daf is still on sick leave [02:02] morgs is on vacation [02:02] here [02:02] I'm here [02:02] == Agenda == [02:02] - roll call [02:02] - next meeting [02:02] - activity reports [02:02] - production / staging status [02:02] - spec tracking! [02:02] - shipit [02:03] - rosetta while carlos is on leave [02:03] - three sentences [02:03] [02:03] any other items, please /msg me [02:03] next meeting, same time next week? [02:03] ack. [02:03] sure [02:03] yes [02:03] jamesh, but are only using the format checks and we can extract them easily. Anyway, we will talk about it later :-P [02:03] yep. === ..[topic/#launchpad:SteveA] : Discussion with Launchpad users and developers. || https://launchpad.net/ || Includes Rosetta and Malone. || Developers' meeting, Thursday 15 Sep, 12:00 UTC [02:03] done [02:03] yeah [02:03] activity reports: who's on top of the world, and who's kinda spelunking? [02:03] what's the offset from nwo? [02:03] TOP === Kinnison is flying high [02:04] I'm restarting, I'm restarting [02:04] i'm up to date [02:04] i'm fine [02:04] top, but with bad catchup style [02:04] up to date === BjornT is up to date [02:04] I sent one in for yesterday === SteveA has kept records but not sent them :-/ time to restart [02:04] I'm 1 week out. My new roles are log resistant and I'm seeking solutions. === spiv is behind, but has some records. === salgado is up to date [02:04] will send in today's later === carlos is a week behind :-( [02:05] i'm uptodate, but i'm trying to concentrate so they're brief [02:05] brief is good [02:05] Not technically up-to-date, but I've just given up on making daily reports on sprints... [02:05] anyone else not accounted for on activity reporting? [02:06] sabdfl ? [02:06] :) [02:06] sabdfl is doing community stuff now [02:06] *cough* === niemeyer [n=niemeyer@200.163.195.103] has joined #launchpad [02:06] shouldn't he be here for the spec bit of the meeting? [02:06] I think he's having lunch or something... [02:06] carlos: please restart your activity reports by sending one today [02:06] community stuff like landing major new Launchpad features :-) [02:07] jblack: please send a report for today. don't worry about making it detailed. look at how mpool's reports look. [02:07] Kinnison: the specs stuff is my items. [02:07] SteveA, I have all inside time tracker, I just need to send them. Will be up to date before leaving tomorrow [02:07] carlos: ok [02:07] specs stuff? no, that's so last week [02:07] SteveA: okies [02:07] - production / staging status [02:07] kiko_: We've not seen an activity report from you since July 7th [02:07] stub: what's happening on staging? [02:07] Kinnison: i'll kick his ass later [02:08] Kinnison, :-P [02:08] Running trunk, but db won't be refreshed from production until carlos has had a chance to confirm the results of the whitespace-migration scrpt [02:08] stub: also, is production rolling out happening as normal? [02:08] Merge to rocketfuel@canonical.com/launchpad--devel--0: Librarian buildd_download_url support. r=spiv (patch-2368: daniel.silverstone@canonical.com) [02:08] production rollouts as planned. Rolled out Tuesday, will roll out next tuesday unless anyone has special needs [02:08] stub, ah, so running trunk and applying database patches to the existing data? [02:09] stub, I think that it will happen later today. I think I fixed all issues and is safe to execute the migration script on production [02:09] yes [02:09] stub: i have some significant menus stuff that is being reviewed right now. i'd like to get it onto staging soon, and maybe includeed in the next production rollout. it fixes lots of menus bugs. [02:09] stub, I have to review some of salgado's shipit stuff for today [02:09] SteveA: Let me know the patch number when it lands [02:09] stub: the RF patch number? [02:09] Ok - sounds like I will be tagging in maybe 24 hours time [02:09] SteveA: Yes. [02:09] okay [02:10] did anyone see any issues in staging that arised from kinnison's package patch? [02:10] thanks [02:10] did anyone CHECK? [02:10] kiko_: thanks for asking, I was just about to ask :-) [02:10] stub, I have some small DB schema fixes that needs to go in the next shipit cherrypick. is that a problem? [02:10] Kinnison's changes only landed on staging today btw. [02:10] but they've been in RF for a week [02:10] salgado: Cherry pick, as in you need it before the next production rollout? [02:11] stub, yes [02:11] salgado: Generally isn't a problem. Give me the rocketfuel patch number as normal, and remind me about the db patch (which I will need to renumber) [02:12] stub, okay. and I'll need an updated sqloject too. I need a fix applied this week [02:12] staging/production issues done? [02:12] jamesh: i will need your help in understanding some of the calendaring code's use of menus, btw. i may have broken it :-/ [02:13] salgado: hurry up then - not much left of this week ;) [02:13] SteveA: okay [02:13] stub/salgado: we need to think about getting the shipit code onto staging very soon [02:13] It is on staging already [02:13] the one that is not in rf, I guess? [02:13] has been for a long time [02:14] with virtual hosting? [02:14] no [02:14] but that isn't in RF yet [02:14] right, that's what i want to see [02:14] I will review it today [02:14] well be patient old man :) [02:14] when i say "shipit", i'm talking about the application as it will be deployed [02:14] kiko_: Btw, I couldn't get to the review site you mentioned for shipit due to permissions. Do I need some specific permission to get there? [02:14] that's clearer :) [02:15] The shippable shipit [02:15] niemeyer, you need the certificate I sent you [02:15] niemeyer, well, wait, what site? [02:15] kiko_: Will check it [02:15] so, what's the stu / kiko / salgado plan for getting the latest shipit onto staging, and maybe out to production soon [02:15] So, has ANYONE checked their apps? [02:15] kiko_: The shipit review you mentioned on a mail the day before yesterday [02:16] yep, I ran make check on mine before committing [02:16] okay === SteveA calls the meeting to order [02:16] SteveA, I'll write more tests, get kiko to review, make sure it's cherrypickable and then merge [02:16] let's take this one point at a time [02:16] kiko_: To marilize.. [02:16] Kinnison: your checking of apps stuff [02:16] lifeless: if only the test suite was comprehensive :-) [02:16] SteveA, review salgado's patch today, land it in RF, goes onto staging, merge it into production by tuesday [02:16] Gina broke, but you know that already [02:16] kiko_: thanks [02:16] stub: aye, I've got a fix for that flying through pqm now [02:17] Kinnison: you have the floor. [02:17] let's check out the checking [02:17] Right, I sent a mail last week when I merged PackageDBRework [02:17] (which reminds me - I should be doing gina runs daily on staging) [02:17] asking people to check their individual apps which might interact with binary packages [02:17] The test suites passed (obviously) [02:17] But as demonstrated by stub, this doesn't catch everything [02:18] Kinnison: but they are so silly atm (about gina tests ..) [02:18] I'd like to see everyone whose app goes near binary packages confirming that their app is safe on the PackageDBRework wiki page [02:18] so, that's buildd, soyuz ui, malone, rosetta, foaf [02:18] buildd patch for it is partially done, ETA today evening. [02:19] the C.A.P. is done now and merged [02:19] BjornT / bradb: who will check malone? === BjornT can check it today [02:19] carlos / jordi: you need to organise checking rosetta [02:19] the tests, mainly [02:19] i think it's ok [02:19] bradb: what do you mean? [02:19] SteveA: soyuz will be delayed for next week or weekend (if i'm not too tired) [02:19] SteveA, Kinnison we are not using binary packages on Rosetta atm [02:19] SteveA, Kinnison only languagepacks exports [02:19] carlos: thanks [02:20] salgado: please check foaf asap [02:20] SteveA: our test coverage is fairly solid. any breakage that we'd be likely to find by manually checking would likely have already been spotted by the test suite. [02:20] SteveA, Kinnison and that's useless without gina's data... [02:20]