=== BenC [n=bcollins@debian/developer/bcollins] has joined #launchpad [12:27] Hey lp'ers [12:28] I notice that on https://launchpad.net/distros/ubuntu/+milestone/ubuntu-6.10-beta if you hit Status, it doesn't exactly sort like you would expect [12:28] hmm, I think theres a bug already [12:28] but perhaps not [12:28] I'm guessing that it's sorting on some other target for the bug besides the one aimed at the milestone [12:29] actually, no, it isn't [12:29] just isn't right :) [12:29] can you file a bug please [12:30] be sure to copy the sorted output from bug 54690 through 59883 in [12:30] Malone bug 54690 in foo2zjs "[Edgy] Please sync new upstream version" [Medium,Fix released] http://launchpad.net/bugs/54690 [12:30] sure thing [12:30] as that shows the problem really vividly [12:30] (fix released, confirmed, fix released) [12:33] bug 62526 filed [12:33] Malone bug 62526 in launchpad "Status sorting on milestone listing is wrong" [Undecided,Unconfirmed] http://launchpad.net/bugs/62526 [12:34] thanks guys === BenC [n=bcollins@debian/developer/bcollins] has left #launchpad ["Ex-Chat"] === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] [12:40] New bug: #62526 in launchpad "Status sorting on milestone listing is wrong" [Undecided,Unconfirmed] http://launchpad.net/bugs/62526 === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has left #launchpad [] === dsas [n=dean@host-84-9-171-130.bulldogdsl.com] has joined #launchpad [12:53] SteveA: ping === marcus_notebook [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === jinty [n=jinty@195.Red-83-58-178.dynamicIP.rima-tde.net] has joined #launchpad === doko_ [n=doko@dslb-088-073-065-104.pools.arcor-ip.net] has joined #launchpad [01:50] New bug: #62532 in launchpad "release pages does not show changelog" [Undecided,Unconfirmed] http://launchpad.net/bugs/62532 [02:11] SteveA: ping [04:10] any launchpad developers awake? [04:11] yes [04:11] jamesh: do you know if anything big is going on with Rosetta right now? [04:11] I'm having trouble with bug 46559 [04:13] mdz: I don't think anything special has changed [04:13] jamesh: do you have access to look at any of that sort of thing? [04:14] if they are doing a big import, I don't even know where that would run [04:14] this is a huge blocker for ubuntu [04:14] I think you'll have to wait for stub (who should be up soon) [04:15] jamesh: I'll be in and out; would you pounce on him for me? [04:15] okay [04:15] have him call or SMS me and I'll explain [04:16] by the look of that bug, the affected soyuz code would need to be changed to be able to retry the failing transaction [04:16] (which a lot of the scripts aren't set up to do) [04:17] I've tried it 4 times in a row and it has failed consistently [04:17] a couple of hours ago, it ran successfully [04:21] jamesh: do you know if there has been a production update recently? [04:21] there was one yesterday [04:22] about what time? === jamesh checks logs [04:25] mdz: looks like it would have finished around 9:00 UTC [04:25] New bug: #62545 in soyuz "View all builds for a just published SourcePackage crashes" [Medium,In progress] http://launchpad.net/bugs/62545 [04:25] so ~17 hours ago [04:26] that doesn't seem consistent [04:26] ah: soyuz is still down - I'll wait a tick until malcc shows up and he can confirm it should still be running with the old code. [04:27] there may be another update time for the soyuz code [04:27] the first failure was around 0038 UTC [04:27] we dont update soyuz as part of the regular update [04:27] because its fragile [04:27] malcc won't be up for several hours [04:28] The soyuz code was updated. [04:28] hmm, I'm going low-blood-sugar, let me grab some food, back in 10 (sorry, I realise this is urgent, but mistakes here would be bad) [04:28] looks like that question was resolved several hours later [04:29] with soyuz being updated as spiv said [04:29] this problem is only a couple of hours old [04:29] Right. stub talked to malcc ~15 hours ago, and updated soyuz, and Kamion reported that the problem he observed was now fixed. [04:29] I think I just got lucky, the most recent publisher run seems to be succeeding after 7 failures in a row [04:30] that isn't too surprising given the type of error [04:40] back [04:43] looking [04:43] mdz: poimport is running [04:44] mdz: please try now === Burgundavia_ [n=corey@ubuntu/member/burgundavia] has joined #launchpad [04:47] lifeless: I got lucky and one succeeded; we don't have any more uploads in the queue [04:48] mdz: what time did it succeed ? [04:49] lifeless: shortly before I said it for the first time in this channel [04:49] which was 1929 local, 0229 UTC [04:49] thanks [04:49] while you were away [04:50] well, I have killed poimport anyhow, you should have no further trouble [04:53] lifeless: thank you [04:53] lifeless: is that something which runs automatically? any idea why things are going badly today in particular? [04:54] lifeless: I sent a message to launchpad@ about the situation; if you could follow up with your findings and actions I'd appreciate it [04:54] meanwhile I'm going to drive the cd image builds [04:55] I've re-enabled the hourly run of the publisher and will let it fall where it may [04:57] mdz: yes, it runs from cron [04:57] no idea about what made it unhappy today, the rosetta devs may have more insight. [04:57] I've already replied to your launchpad@ email, if anything new crops up I shall follow up [05:19] thanks [05:27] we should really look at how we want scripts to handle retries on aborted transactions [05:27] so that problems like this could be avoided === stub [n=stub@ppp-58.8.4.98.revip2.asianet.co.th] has joined #launchpad === mpt_ [n=mpt@203-167-187-9.dsl.clear.net.nz] has joined #launchpad [06:00] Goooooooooooooooood afternoon Launchpadders! [06:36] lifeless: Did you get any more feedback from the distro team? I'm wondering if the poimport cron job needs to be disabled or run less often, or if it is only the occasional run that causes blockage. === jelmer [n=jelmer@dyn-160-39-59-216.dyn.columbia.edu] has joined #launchpad [06:37] 12:53 < mdz> lifeless: thank you [06:37] 12:53 < mdz> lifeless: is that something which runs automatically? any idea why things are going badly today in particular? [06:37] 12:54 < mdz> lifeless: I sent a message to launchpad@ about the situation; if you could follow up with your findings and actions I'd appreciate it [06:37] 12:54 < mdz> meanwhile I'm going to drive the cd image builds [06:37] 12:55 < mdz> I've re-enabled the hourly run of the publisher and will let it fall where it may [06:37] stub: no more feedback no. [06:38] stub: I don't think I can provide any feedback which would help with that decision [06:38] stub: someone needs to find out why that job was causing a problem, when it apparently doesn't usually [06:38] perhaps it was running for an extended period of time [06:39] whatever it was doing differently, it needs to not do that [06:39] serialization exceptions are expected when running in serializable transaction isolation level. We either need to handle them, or lower the transaction isolation. [06:40] Some runs will be more likely to trigger them (probably big rosetta imports), but they can still happen any time until we fix the problem. [06:41] The fix is trivial (and documented in that bug report), but will need to be tested before landing on production. [06:44] stub: that bug report was marked wishlist until a couple of hours ago :-/ [06:44] I'll leave the cronjob enabled if things are happy now - there is already a new poimport process running - but we can disable it if necessary to keep the release moving (maybe run it once or twice a day manually) [06:44] stub: who do I call to get it stopped and disabled if needed? [06:45] mdz: Yeah - I hadn't heard of it causing much besides minor annoyance before and soyuz didn't have a particularly robust test process setup [06:45] mdz: Me, lifeless, admins, stevea (I think) [06:45] thanks [06:45] poimport process running as launchpad on gangotri, and spawned from launchpad's crontab [06:46] Process can be killed without harm - it will recover === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === jml [n=jml@ppp200-172.lns1.hba1.internode.on.net] has joined #launchpad === stu1 [n=stub@ppp-58.8.10.236.revip2.asianet.co.th] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [07:50] stu1, ping [07:51] mpt: pong [07:51] the enumvalue:foo TALES expression would be useful if it worked with security wrapped values ... [07:53] stub, do you know why the web stats claim that there has been zero traffic on blueprint.launchpad.net? [07:54] Because we moved to features.launchpad.net? [07:54] oh. [07:54] rotfl [07:55] That's not a blueprint, that's a feature! [07:55] thanks stub [07:55] You want to rt a request to get the stats for features.launchpad.net put up and blueprint.launchpad.net removed? [08:00] yeah === lfittl [n=lfittl@193.170.41.114] has joined #launchpad === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [08:47] morning === lfittl [n=lfittl@193.170.41.114] has joined #launchpad [09:03] good morning === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos [n=carlos@12.Red-83-39-60.dynamicIP.rima-tde.net] has joined #launchpad [09:04] morning === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === marcus_notebook [n=mholthau@175.32.3.213.cust.bluewin.ch] has joined #launchpad [09:34] stub: hi === mholthaus_ [n=mholthau@175.32.3.213.cust.bluewin.ch] has joined #launchpad === slytherin [n=onkarshi@203.199.147.101] has joined #launchpad [09:48] Can anyone tell me how can I apply for a mailing list for a l10n team. === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === Spads [n=spacehob@217.205.109.249] has joined #launchpad === lfittl [n=lfittl@194.50.115.210] has joined #launchpad === _thumper_ [n=tim@host86-141-71-114.range86-141.btcentralplus.com] has joined #launchpad [10:17] BjornT, ping [10:17] mpt: pong [10:18] BjornT, I saw you said "I'm working on this" in the enter-URLs-as-bug-watches bug [10:18] Is there an existing spec for that? [10:18] or is it too small to need a spec? === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad [10:23] mpt: well, i'm planning to do it steps. the first one will be to simply allow an url in the remote bug field, but still keeping the ability to choose a bug tracker manually. [10:23] mpt: there is a spec at https://wiki.ubuntu.com/BugForwardingWorkflow, though, with some mock-ups at http://www.async.com.br/~kiko/mockups/bug-forwarding-workflow.html [10:26] mpt: hello. I will try calling usman now. [10:27] mpt: there has also been some discussion about this on the mailing list. [10:27] BjornT: those mockups look really busy to me [10:28] BjornT: I also dislike the term "indicate" [10:29] BjornT, could those mockups be put on the wiki? Last week I went through a bunch of specs that linked to mockups on cprov.gwyddion.com, a host that no longer exists. I'm not saying that async.com.br is going to stop existing, but it would be nice to keep all parts of the spec in one place === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [10:31] Burgundavia: yeah, they are quite busy. it could be worth redesigning them, to make the field where you enter the bug url more prominent. [10:31] mpt: he's in a meeting, but I left a message and he'll call me back when he's available. [10:32] ok [10:33] Burgundavia: i also don't like the them "indicate", but it's so hard to come up with a good term. this has been discussed before, but no suitable term was found. === danilos [n=danilo@147.91.15.35] has joined #launchpad [10:35] Burgundavia: it is better than the "request fix in" language [10:35] but isn't perfect [10:39] mpt: iirc, we tried to put the mockups on the wiki at first, but there were some problems with linking to images or something, so we did it like this instead. [10:40] wellllll, those ones don't really need images :-) === slytherin [n=onkarshi@203.199.147.101] has left #launchpad [] [10:42] mpt: do you have sometime to talk about the structural object presentation code? [10:42] SteveA, sure === danilo_ [n=danilo@62.193.129.233] has joined #launchpad === mpt [n=mpt@203-167-187-9.dsl.clear.net.nz] has left #launchpad ["http://mpt.net.nz/"] [11:05] danilo_: hey dude [11:05] carlos: hi [11:05] danilo_: is your network link working well today? [11:06] carlos: not really, and I racoon (VPN) packages are broken for my "backup" provider, so I am back at my parents house :( [11:06] s/I racoon/ipsec and racoon/ [11:06] i.e. bug 44246 [11:06] Malone bug 44246 in ipsec-tools "racoon-0.6.5-4ubuntu1 fails to configure" [Medium,Confirmed] http://launchpad.net/bugs/44246 [11:07] :-( [11:07] well, at least you can work [11:07] yeah [11:07] did you see my request for help? [11:07] not yet, where? email? [11:07] danilos: yeah, email [11:07] I'm stalled with some tests [11:07] it fail and I don't find why [11:08] I've been setting up ADSL on my new computer, so I still started a bit late [11:08] don't worry [11:10] so, what do you need help with? [11:10] (until all of my email gets downloaded, which goes a bit slower at 256kbps) [11:12] danilos: sftp://devpad.canonical.com/home/warthogs/archives/carlos/launchpad/bug-44214/ [11:12] that branch [11:12] and test translationimportqueue.txt [11:14] sure, I'm checking it out right now [11:15] I got so used to 1-2mbps connection, that all this is now terribly slow ;) [11:15] :-P === mpt [n=mpt@203-167-187-9.dsl.clear.net.nz] has joined #launchpad [11:31] New bug: #62584 in soyuz "Deathrow executioner doesn't guarantee stay of execution time" [Medium,Confirmed] http://launchpad.net/bugs/62584 === _thumper_ [n=tim@host86-141-71-114.range86-141.btcentralplus.com] has joined #launchpad [11:40] 123 [11:40] jordi: 456 [11:40] :-) [11:47] btw, I should probably filter translation imports into another account on the server directly, since I am only at 1200/1600 messages now === poolie [n=mbp@ozlabs.org] has left #launchpad [] [11:50] danilos: well, I think we should disable those emails if there are no errors with the imports [11:50] carlos: yeah, most likely, is there a bug about it, or should I report it? [11:51] report it, please === Kylekf [n=Kyle@61.6.65.122] has joined #launchpad [12:10] New bug: #62595 in launchpad "Timeout to low for ISO images?" [Undecided,Unconfirmed] http://launchpad.net/bugs/62595 [12:20] New bug: #62598 in rosetta "Successful imports should not send email to rosetta@launchpad.net" [Wishlist,Confirmed] http://launchpad.net/bugs/62598 [12:26] bug #62598 a.k.a. stop spamming admins!! [12:26] Malone bug 62598 in rosetta "Successful imports should not send email to rosetta@launchpad.net" [Wishlist,Confirmed] http://launchpad.net/bugs/62598 [12:26] :-P [12:27] ;) === danilo_ [n=danilo@62.193.129.209] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === jml [n=jml@ppp200-172.lns1.hba1.internode.on.net] has joined #launchpad [01:16] ddaa: I've done a bit more work untangling the $series/+source form. I'd appreciate if you could take a quick look over the action button implementations for the sourceadmin functionality. [01:17] URL? [01:17] https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/bug-50569/full-diff [01:18] bah, okay, I'll figure out the branch from that [01:18] the changes in lib/canonical/launchpad/browser/productseries.py are the interesting ones as far as this goes [01:19] I got rid of IProductSeriesSourceSet and IProductSeriesSource while doing this too ... [01:19] I was hardly making sense at all of that code before, so I am mostly interested in the UI result [01:19] jamesh: there's a bug open on merging those classes, you can take it [01:19] yep [01:20] the ProductSeriesView class is down to 170 lines after pulling the +source/+sourceadmin stuff out [01:21] ddaa: the "FTP details" bit will be moved from the +source form soon, so pretend it isn't there when looking at the changes. [01:28] jamesh: maybe remove the "# DEPRECATED" in browser.bazaar, it's just confusing and has not enough information to be useful. === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad [01:29] both, or just for /bazaar/series ? [01:30] I was thinking of /bazaar/series [01:30] I dunno which other one you're thinking of [01:30] done. [01:30] ddaa: in that class, there are two occurences of "# DEPRECATED" [01:31] hu? [01:31] products? [01:31] WTF is that for [01:31] ddaa: I can traverse like this: https://launchpad.net/bazaar/products/launchpad [01:31] ??? [01:32] there's a problem with cruft in launchpad [01:32] it changes the layer, so I suppose it might have been intended that "/bazaar/products/foo would display the same as "/products/foo/+branches" does [01:32] but it can probably go completely === jamesh kills [01:33] of course, 'series' could probably just be a view on /bazaaar [01:34] rather than using IProductSeriesSet as a context [01:34] that page is also quite crufty [01:34] for example the "Ready" checkbox is no longer useful [01:34] it appears to ignore disabled products [01:34] I mean, not ignore [01:35] it has the old crazy js hack from plone that prevent keyboard navigation of the table [01:36] I updated/simplified that template a little, btw [01:36] but since it's only for admin use, it's not a biggie [01:36] so you can navigate with the keyboard [01:39] jamesh: FYI, I think the ProductSeries.syncCertified is buggy: it checks for a non-null timestamp instead of looking for the value of the importstatus [01:39] well... which makes senses in the context it is used in allowCertify... [01:40] I also sometimes need to put an import into production without going through autotest first, like the python import [01:40] to short out the double import === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has left #launchpad [] [01:42] In the current design, an import should allowCertify if it's DONTSYNC, TESTING, TESTFAILED or AUTOTESTED [01:43] eventually, I want to redesign importstatus, but it's not yet clear how. [01:43] that would probably take the value of import_branch into account [01:43] carlos: ping [01:44] cprov: pong [01:44] did you see the bug report and the mail thread about buildd vs Rosetta? [01:45] carlos: hi dude, yep, process-accepted isn't using READ_COMMITED yet [01:45] carlos: I'll request stub quick review and get it done [01:46] cprov: Oh, I thought you tried it and failed... [01:47] cprov: ok, thanks [01:47] There was a bug where the setting was not taking effect which might have blocked the fix - I don't remember. [01:48] ddaa: thanks. We probably want to disallow these options if the rcstype isn't one of CVS or SVN too, right? [01:49] Well... [01:50] Actually, there should be a constraint, (rcstype = 0) = (importstatus is NULL) [01:50] if the rcstype is any of the deprecated type, the behaviour is undefined :) [01:51] in the state my branch is in, it'll set rcstype = BAZAAR if that checkbox gets checked [01:51] s/checkbox/radio button/ [01:51] hu? [01:51] which checkbox? [01:51] the "Bazaar" radio button [01:52] please do not use that [01:52] it would get in the way of separating ExternalBranch from ProductSeries [01:53] okay. I'll look at refactoring how I do that part of the code. === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has joined #launchpad [01:55] cprov/malcc: drescher: === ddaa got Ewa to turn off eMule, and got his BW back [01:56] /dev/cciss/c0d0p1 533G 481G 26G 95% / [01:56] elmo: Argh [01:57] elmo: Did we ever resolve for you whether or not that bunch of stuff could be deleted? === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:57] malcc: we did it and it was [02:01] cprov: r=stub on the transaction isolation fix [02:02] stub: thank you ! [02:02] Done a test run anywhere, or is the test suite enough now? === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === carlos -> lunch [02:07] jamesh: in your branch, http://launchpad.dev/products/firefox/1.0 is broken [02:07] as in oops [02:07] gar. I was probably a bit over-eager in cleaning things up === niemeyer [n=niemeyer@200.103.133.243] has joined #launchpad [02:08] the hct-status stuff is used in a lot of places [02:09] jamesh: I think the Bazaar branch thing should be independent from the CVS/SVN stuff [02:09] as it is actually in the underlying database === seb128 [n=seb128@ANancy-151-1-54-182.w83-194.abo.wanadoo.fr] has joined #launchpad [02:10] It's initial value should be something like: [02:10] empty if user_branch and import_branch are both null [02:10] user_branch if user_branch is set [02:10] import_branch if user_branch is null and import_branch is set [02:11] setting it to a value != from import_branch sets user_branch [02:11] setting it to a value == import_branch clears user_branch [02:12] The alternative would be to just point people at +edit [02:12] might be easier than the alternatives [02:13] I cannot speak about implementation, but I think what I described would be quite intuitive to use [02:13] but I'm very strongly biased... [02:13] ddaa: ignoring the "bazaar branch" option on the form for now, it is possible to submit the form with no details entered. The action buttons will need to handle that situation [02:14] mh... I am not sure, are you asking a question? [02:16] yeah: how should the buttons act if rcstype == NONE? [02:17] it should be allowed in some circumstances [02:18] allowed to Edit (owner) if importstatus < PROCESSING (not in production) [02:18] allowed to Admin (vcs-import and admin) in all cases [02:21] Then, it should clear import_branch, import_status, datelastsynced, syncinterval, rcstype, cvsroot, cvsmodule, cvsbranch, cvstarfileurl, svnrepository, dateautotested, dateprocessapproved, datesyncapproved, datestarted, datefinished [02:21] what I mean is that if the form has "No RCS details" selected, we don't want you to be able to put the import into production [02:21] the bkrepository and targetarch* fields will be deleted when the current remove-gnuarch lands [02:22] jamesh: successfully posting that form should remove all the vcs-import information [02:22] so, yes, you do not want to put that into production [02:23] actually, you should not even be allowed because of db constraints [02:24] in ForeignBranch terms, that would be the action equivalent to deleting a ForeignBranch [02:24] jamesh: I am not sure I am answering your question === lfittl [n=lfittl@194.50.115.210] has joined #launchpad [02:25] ddaa: I think you have explained it okay. [02:30] note that the importstatus-based access restriction can lead to some interesting race conditions [02:30] for example, an Edit loads the form and clears the details, an Admin posts the form to approve the import for production, and the Edit posts the form. [02:31] The second post should fail. It's probably a unlikely enough race that it's okay to oops. [02:33] ddaa: they should get an unauthorised exception, right? [02:33] since they no longer have launchpad.EditSource permission when they post [02:34] jamesh: right === ddaa -> break [02:43] stub, BjornT, around? [02:43] salgado: yes [02:44] salgado: i'm around, but i'm about to leave for a while [02:45] BjornT, stub, I'd like to discuss quickly if we should or not make Person.creation_rationale a NOT NULL and set a rationale for accounts created through the web UI [02:45] this is what I had in mind initially, and I actually implemented it [02:45] What prompted the change? [02:45] but then at some point I thought that the rationale would only make sense for automatically created accounts [02:46] that is, we don't actually need a rationale for accounts created by their owners [02:46] NULL generally means 'this hasn't been set', so it is a bit ambiguous given that the field can be NULL or rationale.UNKNOWN [02:47] salgado: i think that it should be NOT NULL. that makes you think about what the rationale should be when creating new persons automatically. it's much easier to pass None, than to pass an incorrect rationale to createPerson() [02:47] If we have a status for accounts created by their owners, then we actually know that this account was created by their owner. [02:47] on the other hand, having the rationale NOT NULL would make things simpler, and we could have a special rationale (something like rationale.OWNER_CREATED) for accounts created through the web [02:47] Rather than some screwup [02:48] yeah, this is what I had initially [02:48] we should try to ensure that new people all have a rationale, even if that's "registered when ordering shipit CD's". [02:48] we often have people say "launchpad has an account for me and i don't know why" [02:48] when often they created those themselves! [02:48] We can even use it to store more information. For example, OWNER_CREATED_LAUNCHPAD and OWNER_CREATED_SHIPIT etc. But that might be overkill. [02:49] this is especially true if we create the account when parsing the real world (mailing lists, po files, bug reports etc) [02:49] sabdfl, that, specifically, we can't tell. because from shipit we simply direct people to launchpad and ask them to create an account [02:49] salgado: trivial to fix and necessary to do so [02:49] salgado: we know a URL to send people back to after they register their account though, right? [02:49] salgado: There is a URL referencing shipit that is used to send the user back after sighup. [02:50] yeah, we could use the redirection url [02:50] salgado: in the case of direct person creation we absolutely must ask the person doing the creation to leave some comment on why they created the record. ideally we also get permission to email the newly-registered person, quoting that reason AND the registrant's name [02:51] elmo: The space all goes into our endless archive of everything ever uploaded, which grew around 40GB in August. We need an infinite disk, or a plan for when to archive/delete these. I've raised https://launchpad.net/products/soyuz/+bug/62612 as a home for discussion on what to do. [02:51] Malone bug 62612 in soyuz "Need a drescher disk space strategy" [Undecided,Unconfirmed] [02:52] sabdfl, that is what I had in mind [02:54] salgado: Based on this discussion, I think the column should become NOT NULL and a value stored for all users. === ddaa is back [02:55] stub, agreed. I'm already changing it. :) [02:55] stub, btw, should the UPDATE statements be moved to a separate sql script and moved to the pending/ directory? [02:56] jamesh: clearing vcs import details appeared to work with your branch, but then setting them back again causes an oops [02:56] UPDATES are fine in the database patches provided they don't modify the sample data, and are required if you are setting the column to NOT NULL. [02:57] I see [02:57] jamesh: actually, just posting the form w/o change causes an oops: http://launchpad.dev/products/a52dec/failedbranch/+source [02:57] as Foo Bar [02:58] jamesh: test coverage for +source/+sourceadmin is seriously lacking, so do not assume that not breaking tests means it's good. [02:58] stub, how about teams; what rationale do you think we should use for them? [02:59] Hmm... I guess the field makes no sense for teams, so the column should be NULLable but with a check constraint CHECK (creation_reason IS NULL = teamowner IS NULL). Sound reasonable? [03:00] yeah, I think so [03:00] stub: hey, can you give some love to the db patch in sftp://devpad.canonical.com/home/warthogs/archives/david/launchpad/remove-gnuarch? It's in the DBA review queue and has r=SteveA already [03:00] New bug: #62612 in soyuz "Need a drescher disk space strategy" [Undecided,Unconfirmed] http://launchpad.net/bugs/62612 [03:01] stub: is it a text field, or a combination reason int not null, comment text nullable? [03:02] sabdfl: combination int and comment text [03:02] cool [03:02] stub, shouldn't it be CHECK (creation_rationale IS NULL = teamowner IS NOT NULL)? [03:03] salgado: yes [03:04] stub, https://devpad.canonical.com/~andrew/paste/file0TTwYT.html ; I'm adding the comments now, btw === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:10] salgado: Will those updates mess with your sample data, or will it just reset the values? [03:12] stub, no, the branch includes a patch to the sampledata too [03:13] salgado: See if make sampledata still works after building a fresh database with your patch and the updated sample data. [03:14] stub, the current sampledata doesn't have the rationale for validated accounts, but I'll add them and it should pass, I think [03:16] ddaa: ping [03:16] If the patch screws the sampledata rebuilding, then we need to move the UPDATES to a post rollout data migration script and delay adding the CHECK constraint until a future rollout. [03:17] SteveA: I'm about to go out to the photographer [03:17] back in < 1h [03:17] stub, hmmm. I don't see what you mean. isn't it enough to just update the sampledata to not break the new constraint? [03:18] salgado: There is a catch-22 situation in how the sample data is rebuilt. I can't quite recall the details unfortunately :-( [03:20] stub: If I \e'd a query, then quit postgres, how can I get the whole query back? \e'ing again brings up an empty editor, and line-by-line copy-and-pasting the readline history is against my religion. [03:20] bradb: Dunno if you can. [03:21] hrm. blasphemy it is. [03:23] ddaa: Huh. I missed that earlier because it is flagged merge-approved === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [03:26] stub, updated sampledata works fine with this patch: https://devpad.canonical.com/~andrew/paste/file6i8b5C.html [03:26] (same as the previous one, but added a name to the constraint) [03:27] salgado: So rebuilding the sample data again works, and the diff between current.sql and newsampledata.sql does not show anything alarming? If so, r=stub === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === mholthaus_ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad [03:28] salgado: patch-67-21-0.sql [03:28] stub, actually, I didn't try rebuilding the sampledata... I changed it manually. I'll see if I can rebuild it [03:29] yeah, it rebuilt just fine [03:29] thanks stub === mholthaus__ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === mholthaus___ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === lfittl [n=lfittl@85-125-229-117.dynamic.xdsl-line.inode.at] has joined #launchpad === danilos [n=danilo@62.193.129.71] has joined #launchpad [04:22] hello hello === jgi [n=jgilli@251.9.39-62.rev.gaoland.net] has joined #launchpad [04:30] Morning kiko. Any thoughts on https://launchpad.net/products/soyuz/+bug/62612 ? [04:30] Malone bug 62612 in soyuz "Need a drescher disk space strategy" [Critical,Confirmed] [04:30] let's see. === mholthaus_ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad [04:33] malcc, I think that's something the distro team is best equipped to give consel on, but why don't we just throw away anything that's more than a month old? [04:34] kiko: Doesn't sound unreasonable [04:35] malcc, historically, have uploads from before that period been useful? [04:36] kiko: Sometimes useful, but not usually vital. A couple of times when builds have gone missing or other odd data artifacts have turned up, it's been useful to check what was originally uploaded [04:36] malcc, even for builds that are more than a month old? [04:36] kiko: I can think of one time I looked at something at least that old, but it wasn't vital that it was still there. [04:36] kiko: We could go for three months, we've got space for that and at least it's finite [04:37] malcc, fine by me as well. how much would that save today? [04:37] kiko: Probably around 100 gigs, don't know exactly [04:37] wow [04:38] malcc, should we chat a bit now about effects of the rollout? [04:38] kiko: Sure [04:39] malcc, privmsg or ##soyuz1.0? [04:39] kiko: How about ##soyuz1.0? [04:39] hi everyone [04:39] y not [04:39] yo jgi [04:39] I'm trying to upload a new template for the WengoPhone project, but I don't see anything in the import queue [04:40] Could you please tell me where I should check if I've done something wrong? === xenru [n=Miranda@85.192.13.237] has joined #launchpad [04:40] jgi, sounds odd. matsubara can you give him a hand? [04:41] kiko: I can take care of that, don't worry [04:41] jgi: hi [04:41] cool [04:41] carlos, hi [04:41] jgi: where did you upload it? [04:41] kiko, thanks! [04:41] carlos, here: https://launchpad.net/products/wengophone/trunk/+pots/qtwengophone/+upload [04:42] jgi: that's the right place [04:42] let me check... === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === mholthaus__ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad [04:46] jgi: hmmm, I guess it's not this file: http://librarian.launchpad.net/4519061/qtwengophone_en.po (I think our system changed the filename, so don't pay attention to it) [04:48] jgi: I don't see any other entry that failed or was imported recently for wengophone [04:49] jgi: if that's the file you uploaded.... it looks broken [04:49] it contains translations and the file format seems like is not completely correct... === mholthaus___ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad [04:52] carlos, hmmm... [04:53] carlos, the file I uploaded does not contain any translation [04:54] jgi: this one contains just one string as translation and a lot of " " for the other strings: [04:54] #: [04:54] AIMSettings [04:54] #2 [04:54] msgid "" [04:54]