[00:37] <maxb> exarkun: So, given I've already downloaded the svn repo, is there anything else I can do to help with this divmod conversion?
[00:50] <jml> oh yeah
[00:50] <jml> I should volunteer to help
[00:50] <jml> but probably won't be able to until the weekend.
[01:05] <maxb> jml: divmod? Are you a bzr-svn person?
[01:06] <jml> maxb: uhh, no, not really. I used to be a divmod person though, and I am a Launchpad person.
[01:06] <jml> maxb: I guess I could help them by poking jelmer in real life :)
[01:06] <jml> anyway, really gone
[01:06] <maxb> heh
[01:08] <maxb> Am trying to dream up a bug report for this weird crash importing Nevow
[01:26] <lifeless> maxb: words of one syllable :)
[01:28] <maxb> Argh! is one syllable :-)
[01:46] <maxb> exarkun: bug 701752, in case you want to subscribe
[01:54] <exarkun> maxb: thanks
[01:54] <exarkun> maxb: I'm not really sure what my next step would be, since I don't really understand the memory leak, or why I get different behavior for splitting Nevow out than you do
[01:56] <exarkun> one extra thing I remembered, though, is that in addition to https://code.launchpad.net/nevow there's also already https://code.launchpad.net/pyflakes
[01:57] <exarkun> (I don't _think_ any of the other code has been stuck on a launchpad project)
[02:15] <maxb> Well, at least for me, the memory leak is not an issue importing one project at a time
[02:15] <maxb> I'm running on a 4GB machine
[02:16] <maxb> It just killed me when I tried to import the entire 13 projects in one bzr svn-import execution
[02:17] <maxb> As for Nevow, I made an evil hack in the bzr-svn source code, and it proceeded to import the rest of the Nevow branch ok. But I'm a little reluctant to go with that since I'm not certain the produced history will be the same as a properly fixed bzr-svn
[02:17] <maxb> We'll have to see what Jelmer has to say concerning bug 701752, because that code is over my head
[02:18] <exarkun> Okay.  Maybe jml will manage to get his attention soon. :)
[02:19] <maxb> Of course, there's nothing stopping us doing all the other 12 projects meanwhile
[02:20] <exarkun> glyph has some objections to throwing away the information that's present in some of the existing cross-project branches
[02:21] <exarkun> hmph, I forgot about reverend and combinator.
[02:22] <exarkun> I think those, and nevow and pyflakes can obviously be split off with only benefits
[02:22] <maxb> hmm
[02:23] <exarkun> when I mentioned to glyph that you thought the projects should be split up, I didn't really have an argument to make, because when you brought it up to me it just sounded like the right thing to do, so I don't think you had to argue it any further :)
[02:23] <exarkun> the best reason I can think of is that the launchpad bug tracker doesn't have any way to mark tickets as for one project or another
[02:23] <lifeless> how do you mean?
[02:24] <exarkun> lifeless: now the word "project" is getting in the way
[02:24] <lifeless> nouns do that
[02:24] <exarkun> if two "projects" had their code in a single bzr branch attached to a single Launchpad Project
[02:24] <maxb> The situation is a legacy svn repository in which 13 projects all sat side by side within a single trunk
[02:24] <maxb> And the question is how best to get this lot into bzr
[02:25] <lifeless> exarkun: ah, yes you could not use the drop down widgets.
[02:25] <lifeless> exarkun: you could do the following:
[02:25] <lifeless>  - use two LP Projects, with only one having code branches
[02:26] <lifeless>  - use two LP Projects, with both having code branches starting with one initial branch, and then only evolving one "project" code in the code branches for one LP Project
[02:26] <lifeless>  - some variation
[02:26] <lifeless>  - use bug tags
[02:28] <exarkun> hum, that second option is interesting
[02:32] <poolie> exarkun, hi there, thanks for the conch fix
[02:32] <poolie> is it all done then?
[02:34] <exarkun> poolie: committed to twisted trunk, ticket marked as fixed :)
[03:08] <poolie> exarkun, i'll just see if it's possible to test it actually on lp
[03:08] <poolie> i think mwh only tested on his own machine
[03:09] <poolie> which is probably definitive as far as your side of the fix goes, but i'd just like to know it's deployed ok
[03:29] <poolie> exarkun, works for me on production
[03:29] <poolie> thanks!
[03:30] <thumper> poolie: hi
[03:30] <poolie> hi there
[03:30] <thumper> poolie: just wondering, which conch bug are you referring to?
[03:31] <poolie> https://bugs.launchpad.net/bzr/+bug/556132
[03:31] <thumper> poolie: mwh seems to think it is all good :)
[03:32] <poolie> good
[03:32] <poolie> me too
[03:34] <poolie> thumper, you don't mind me marking it fixreleased at this point?
[03:35] <thumper> poolie: I'm not sure if it has been rolled out
[03:35] <thumper> so unless you know it has, I'd wait until the release
[03:35] <poolie> i tested against production and it worked, and it claims to be fixed in the revision of stable that is mentioned in the lp footer
[03:35] <poolie> does that add up to it being rolled out?
[03:36] <thumper> the id in the footer is just the webapp, not the codehosting server
[03:36] <thumper> I don't think the codehosting server is part of the no downtime rolls
[03:38] <poolie> hm
[03:38] <poolie> so that's kinda interesting it doesn't fail
[03:38] <poolie> maybe my client is not requesting rekeying
[03:40] <poolie> ok, so a kind of false positive
[03:53] <wildintellect> anynone know if you can add both deb and deb-src from a ppa with apt-add? or the correct channel to ask such a question?
[03:55] <thumper> wgrant: do you know? ^^
[03:57] <wildintellect> maybe it's just a limitation of the apt-add application now that I think about it, I'll go check their tickets
[04:01] <wgrant> wildintellect: Most users don't use source packages, so it doesn't add them.
[04:01] <wgrant> wildintellect: It *could*, but it's not clear whether it's worth it.
[04:02] <wildintellect> true I guess I'll write my script to do it the old fashioned way copying to sources.list.d
[04:10] <wgrant> poolie: The next rollout is tomorrow, FWIW.
[04:12] <wildintellect> thanks
[07:37] <fta2> how difficult/realistic would it be to make the translation exports faster/more frequent?
[14:57] <jml> jelmer: https://launchpad.net/bugs/701752
[14:57] <maxb> he knows, he's already triaged it
[14:57] <maxb> :-)
[15:02] <jml> maxb: good good.
[15:02] <jml> maxb: just pasting to give an easy link as a follow up to a real life conversation.
[16:36] <Williamson69[TFD> If anyone knows a lot about Linux and could answer my questions. Please query me. I am a very new user and want to use Linux. Please help me. If you are a Guru on Linux. I would love to talk to you. Please query
[16:41] <micahg> Chiumiento: try #ubuntu if you have questions on how to use Ubuntu
[16:55] <shadeslayer> hi could someone delete this branch : https://code.launchpad.net/~neon/kdebindings/trunk/
[16:55] <shadeslayer> i get this : This branch cannot be deleted as it has 2 branches sharing revisions. : when trying to delete it
[17:01] <maxb> shadeslayer: Why does it need to be deleted?
[17:02] <shadeslayer> maxb: because the upstream branch got split .. one sec
[17:02] <shadeslayer> maxb: https://code.launchpad.net/~neon/kdebindings/
[17:02] <shadeslayer> so that branch is completely empty
[17:03] <maxb> hmm
[17:03] <maxb> Ok, so 3 things
[17:03] <maxb> 1. It's development focus for project kdebindings, a registry admin is needed to unmark it as such
[17:04] <maxb> 2. It's a stacking base for two branches of ~yofel
[17:04] <maxb> 3. Usually vcs import branches just get renamed when they are obsolete, in case someone is interested in the history
[17:04] <shadeslayer> maxb: oh the history is preserved with the new branches ...
[17:05] <shadeslayer> they used a script to convert svn history to git history ...
[17:05] <maxb> yofel: ping?
[17:06] <shadeslayer> he's away i think
[17:08] <maxb> henninge: If you are available for a brief CHR operation, please visit https://launchpad.net/kdebindings/trunk/+linkbranch and change the linked branch field to be empty
[17:09] <maxb> hah
[17:09] <maxb> :-)
[17:09] <henninge> maxb: let see what I can do but I was about to leave ... ;)
[17:09] <shadeslayer> maxb: https://code.launchpad.net/~yofel << i dont see anything related to bindings
[17:10] <maxb> shadeslayer: the branches are in the Merged status, which is not included in the default "Any active status" filter
[17:10] <shadeslayer> ohk
[17:10] <henninge> maxb: /me is reading backscroll
[17:11] <maxb> henninge: Summary: upstream project has reorganized into various distinct subprojects, so there is no single appropriate branch to be lp:kdebindings any more
[17:12] <henninge> ok, I see
[17:13] <maxb> thanks
[17:14] <henninge> maxb, shadeslayer: done. Good night ;)
[17:14] <shadeslayer> thanks :)
[17:14] <shadeslayer> good noght
[17:14] <shadeslayer> *night
[17:14] <maxb> shadeslayer: OK, so, I still think we should not delete the branch outright, but I think we should rename it from trunk to obsolete-monolithic
[17:14] <maxb> In theory we can do that now
[17:14] <shadeslayer> ok ...
[17:15] <shadeslayer> sounds good
[17:15] <maxb> It'll break ~yofel's branches until the stacked-on location is manually updated
[17:15] <maxb> But they are ancient and marked as merged, so it's probably fine
[17:15] <shadeslayer> i dont think we will be using those anyways
[18:39] <yofel> maxb: so I should delete them?
[18:39] <yofel> (I'm fine with it)
[18:39] <maxb> yofel: it is not necessary that you do
[18:39] <maxb> I was just going to ask you to run "bzr reconfigure --unstacked lp:~yofel/kdebindings/..." on each
[18:40] <yofel> can do
[18:40] <maxb> Since they do not appear to actually be sharing any revisions with the import branch anyway
[18:42] <yofel> done
[18:43] <maxb> great, now they should work, and no longer be unnecessarily tied to the other rbanch
[18:46] <davidstrauss> Hi, I need help recovering access to an account for a friend. His username on LP is "solrize." We don't remember the email address.
[18:59] <mwhudson> davidstrauss: i can tell you the email address if you like
[18:59] <mwhudson> or send email to it, but i don't know if that will help
[18:59] <davidstrauss> mwhudson, that would be great
[18:59] <davidstrauss> mwhudson, is it @archive.org?
[18:59] <mwhudson> davidstrauss: yes
[19:02] <davidstrauss> mwhudson, do you know who could help or would know the procedure?
[19:02] <mwhudson> mrevell would i expect
[19:03] <mwhudson> who would be around now... bac?
[19:08] <mwhudson> davidstrauss: this is sort of relevant: https://help.launchpad.net/YourAccount/Merging
[19:08] <mwhudson> davidstrauss: i have to go now, i hope you can get this sorted
[19:09] <davidstrauss> mwhudson, is there a delay in sending new account emails? paul is trying to set up a new account, and the confirmation email is taking a very long time
[19:09] <mwhudson> davidstrauss: no :(
[19:10] <davidstrauss> mwhudson, just a launchpad-can-be-slow delay?
[19:10] <mwhudson> davidstrauss: https://answers.launchpad.net/launchpad/+faq/969 :(
[19:10] <mwhudson> davidstrauss: it's more likely to be a "mail providers suck" delay
[19:10] <davidstrauss> lol
[19:10] <mwhudson> bye for now
[19:10] <davidstrauss> mwhudson, thanks
[22:40] <soren> I have an upload that seems to have gone missing.
[22:41] <mwhudson> luckily for you wgrant should be awake by now
[22:41] <soren> At 22:15:19 UTC (about 25 minutes ago) I uploaded a package to one of my PPA's (soren/ppa). It's nowhere to be seen.
[22:45] <wgrant> soren: The cron jobs may have already been switched off for the upgrade.
[22:45] <wgrant> That seems oddly early, though.
[22:45] <wgrant> mbarnett: ^^?
[22:45] <soren> wgrant: Oh, there's an upgrade going on right now?
[22:46] <wgrant> soren: It starts in 15 minutes, I believe.
[22:46] <mbarnett> wgrant: yeah, crons were quite recently shut off
[22:46] <mbarnett> and yes, 13 minutes from now
[22:47] <soren> How long is this expected to run for?
[22:47] <soren> Err..
[22:47] <soren> That's an odd sort of question.
[22:47] <soren> When can I expect the upload to be processed is what I really wonder.
[22:47] <soren> Hours?
[22:48] <micahg> 90 minutes was given as the outage window IIRC
[22:48] <jcsackett> soren: projected downtime for the upgrade is 90 min.
[22:48] <wgrant> soren: A few minutes after the upgrade finishes, so about 100 minutes from now.
[22:48]  * micahg notices the topic :)
[22:48]  * soren follows in micahg's foot steps
[22:49] <soren> Cool, not going to wait up, then :)
[22:49] <soren> Thanks!
[22:49] <hrw> hi
[22:49] <jml> hi
[22:50] <hrw> I dputted my package into ppa some time ago and nothing is visible in web ui. no 'rejected' email either ;(
[22:51] <wgrant> hrw: The upload processor has been disabled for the upgrade.
[22:51] <wgrant> It should be back in a couple of hours.
[22:51] <hrw> thank you
[22:51]  * hrw will go to other activities then
[22:52] <hrw> btw - will I have to reupload later or will my upload processed later?
[22:52] <wgrant> hrw: It will be processed.
[22:53] <hrw> thx
[22:53] <Nafallo> wgrant: damnit. I was about to answer "yes"
[22:54] <Nafallo> wgrant: let's talk in jabber instead :-)