[00:00] <wgrant> yofel: svn: No such revision 16208
[00:00] <wgrant> yofel: Their SVN repo says it was last changed in 2006.
[00:01] <wgrant> That sounds potentially wrong.
[00:03] <yofel> hm, indeed, I'll check the repos
[00:28] <yofel> right, the svn repository got corrupted, can someone approve the new import? https://code.launchpad.net/~scribus/scribus/trunk
[00:29] <mwhudson> yofel: done
[00:29] <yofel> thanks!
[00:44] <tgall_foo> wgrant, ok thanks ...  let me know if i need to take action to reupload that build again or what have you ...
[00:45] <wgrant> tgall_foo: I've tracked down and fixed the bug. We'll be able to reprocess the upload once it's deployed.
[00:45] <wgrant> tgall_foo: You'll get one last email about it.
[00:46] <tgall_foo> wgrant, great, thanks!   amazingly fast work!
[00:46] <wgrant> tgall_foo: Sorry about all the email.
[01:10] <cody-somerville> http://launchpadlibrarian.net/61829075/vcs-imports-django-trunk.log <-- hmmm... whats the "Getting exising bzr branch from central store." mean?
[01:13] <mwhudson> cody-somerville: launchpad doesn't import the branch from scratch each time
[01:13] <cody-somerville> mwhudson, the branch has never been successfully imported in the first place :(
[01:13] <cody-somerville> mwhudson, https://code.launchpad.net/~vcs-imports/django/trunk
[01:13] <mwhudson> the log message is printed before it knows that
[01:14] <cody-somerville> ok, so next question: why is the import failing?
[01:14] <mwhudson> cody-somerville: a strange error, on the face of it
[01:14] <mwhudson> cody-somerville: ask jelmer, i guess
[10:25] <geser> when I branch from lp:ido where should I push my branch for later merging? (bzr: ERROR: Permission denied: "~geser/ido/fix-linking-no-add-needed/": : You cannot create branches in "~geser/ido")
[10:26] <janimo> in which cases can failed builds not be retried on LP? If a package failed on 10.10 but was not updated since seems to be an example
[10:27] <wgrant> janimo: You'll need to do a fresh upload.
[10:27] <wgrant> You can't retry the maverick build, since that would attempt to upload to maverick, which would be... bad.
[10:27] <janimo> wgrant, ok, so this is the case for build1 version uploads?
[10:27] <wgrant> janimo: One case for them, yes.
[10:27] <janimo> I understand 10.,10 is closed
[10:28] <janimo> wgrant, I wonder if it made sense to try rebuilding FTBFS archs when moving binaries to a new release
[10:28] <janimo> auotmatically in soyuz I mean
[10:28] <wgrant> janimo: We used to do that.
[10:28] <wgrant> But the script to do so has bitrotten.
[10:29] <geser> janimo: I asked the same once in the past and got asked back "what makes me believe that it will build now?"
[10:29] <janimo> geser, well, different toolchain woudl be the most obiosu answer
[10:30] <wgrant> The utility of automatically trying the rebuild is limited. Allowing a rebuild would be nice.
[10:30] <janimo> but ithe chances of building may imporve in time (deps being ready). So at beginning of the cycle it would still fail, but in a month not
[10:30] <janimo> but it is probably a not too frequent case to worry about
[10:30] <janimo> just annoying a bit, to upload no changes, when LP could be a bit smarter about it
[10:30] <janimo> like offer rebuild on current cycle if the package was broken all the time
[10:31] <StevenK> Why should LP track the time since a new series was started? It doesn't sound like it offers much value
[10:31] <wgrant> geser: The project still has a private branch policy, restricting non-DX people from pushing branches.
[10:31] <janimo> wgrant I agree automatic, while useful would mean too much resources used with probably little gain
[10:32] <wgrant> geser: You should probably ask DX to convince an LP admin to relax that policy.
[10:32] <janimo> StevenK, not the time. The retry should be allowed manually just in case someone retries after a while
[10:32] <geser> wgrant: thanks
[10:32] <wgrant> geser: https://code.launchpad.net/ido should say this.
[10:32] <wgrant> But instead it just says they're public... not sure what's going on there.
[10:33] <StevenK> janimo: Can you restate, that doesn't make sense?
[10:34] <janimo> StevenK, no time tracking was implied by me. I said after 3 months into the cycle, chances of a package building (same version) are higher than at the beginning, if it ended the rpevious cucle in FTBFS
[10:34] <janimo> so a 'Retry build' button would be nice
[10:34] <fta2> wgrant, hi, read your comment about the arch-ppa bug. how can i workaround this?
[10:34] <janimo> filing a bug anyway
[10:35] <wgrant> fta2: What problems is it causing you?
[10:36] <fta2> wgrant, bugs stats for one, and too many iterations
[10:37] <fta2> wgrant, like, say a py deb, arch all, with 10 dls, is exposed with 10 for i386 + 10 for amd64 + 10 * (sparc + powerpc + armel + ia...)
[10:37] <janimo> StevenK, filed bug #699744 which I hope describes  clearly the issue as I see it
[10:37] <fta2> wgrant, so once aggregated by arch, it's 80 instead of 10
[10:38] <wgrant> fta2: Right. I'm not sure how best to fix it on our end, since this part of the data model is based on decisions from more than six years ago, and it's pretty ingrained :/ Perhaps if you can tell me what sort of data you actually need, I can expose it in a less raw form, without duplicates.
[10:38] <fta2> wgrant, and of course, each requires an interation, making the thing incredibly long to run
[10:39] <wgrant> fta2: Hence my inclination to expose it in a form that is more directly usable.
[10:41] <fta2> wgrant, i poll the stats and store raw tuples { pkgname, pkgversion, dist, arch, date, count } in a cache, so that i can later aggregate by any of those keys without re-polling
[10:41] <fta2> the reason for the cache is that it's way too slow to poll several times to have different views
[10:42] <wgrant> Right.
[10:42] <fta2> it will probably take more than a day to just poll the stats for the chromium/daily ppa
[10:42] <fta2> and probably timeout somewhere
[10:43] <fta2> it's probably 10 times worse for the mozilla/day ppa, it has zillions of packages
[10:44] <fta2> bin-pkgs
[15:24] <madcSPYnXfff> hii
[15:24] <madcSPYnXfff> hi
[15:25] <madcSPYnXfff> is there any person alive
[15:25] <madcSPYnXfff> hello
[15:25] <madcSPYnXfff> helo
[15:26]  * benji checks his pulse... yep alive.
[15:26] <madcSPYnXfff> hey
[15:27] <madcSPYnXfff> hey benji
[15:38] <madcSPYnXfff> what is launchpad.net?
[17:38] <ScottK> wgrant: Related to the retry discussion from ~7 hours ago, I was thinking that if someone mashes the retry button, they should get the email when it fails again, not the original uploader.
[18:44] <exarkun> I wonder if anyone could suggest how I should move some code onto launchpad.  I have a bzr mirror of the svn repository which used to hold the code for half a dozen related projects, and on launchpad a while ago someone created <https://launchpad.net/divmod> and imported some of the code.
[18:44] <exarkun> Can I get rid of <https://launchpad.net/divmod>?  Change it into a regular project?
[18:49] <benji> exarkun: there is a process (not sure what it is at the moment) to claim improperly registered projects, or you could ask the person that registered the project to hand ownership over to you
[18:50] <exarkun> I think he already made me an admin on the project or something like that
[18:50] <exarkun> But I still can't push to it
[18:51] <exarkun> bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: TypeError: (\'Could not adapt\', <ProjectGroup at 0x1875a550>, <InterfaceClass lp.code.interfaces.branchtarget.IBranchTarget>)">'
[18:52] <benji> unfortunately I don't have much time to help at the moment; it does look like you're pushing to something other than a branch, perhaps you need something more on the target URL
[18:53] <exarkun> That's from pushing to "lp:divmod"
[18:54] <benji> it should be something like lp:divmod/name-of-branch; where "name-of-branch" migth be "trunk" or "2.2.1", etc.
[18:55] <exarkun> It fails the same way for "lp:divmod/trunk"
[18:55] <tsimpson> there seems to only be lp:nevow in that project
[18:56] <benji> if you go to https://code.launchpad.net/divmod you can see the current branches
[18:56] <exarkun> Does this have something to do with "ProjectGroup"?  I don't really know what's going on, but it seems like launchpad has different kinds of projects, and this isn't the usual one.
[18:58] <benji> we've now exhausted my knowlege about this area of LP :)
[18:58] <exarkun> okay, thanks!
[19:01] <benji> exarkun: this might help you on your journey: https://help.launchpad.net/Code/QuickStart
[19:09] <tumbleweed> exarkun: yes, project groups are collections of projects, and don't hold bugs / code themselves. But I'm not a lp admin, so I can't tell you anything about changing it into a project or renaming it out the way
[19:10]  * benji learns something now.
[19:15] <maxb> exarkun: 'divmod' is a project group, and from what you said, it sounds like you have multiple projects to import too. So, why not register additional projects and mark them as part of the divmod group?
[19:15] <exarkun> The projects are all in the same bzr branch
[19:16] <maxb> oh. and eww
[19:16] <maxb> I would suggest fixing that before pushing
[19:16] <exarkun> That sounds hard.
[19:16] <maxb> The project as a whole is migrating from svn 2 bzr?
[19:16] <exarkun> yes
[19:16] <maxb> If so, now is the opportunity to do it right
[19:17] <maxb> How interrelated are the projects?
[19:17] <exarkun> somewhat
[19:17] <exarkun> (I don't know how to be more precise than that)
[19:18] <maxb> Well, what are the projects?
[19:18] <exarkun> Nevow, Epsilon, Axiom, Mantissa, Quotient, Hyperbola, Imaginary
[19:19] <exarkun> templating library/web server, random utility library, object database, application server, email server, blog server, text adventure library
[19:19] <maxb> uh, wow
[19:19] <maxb> right
[19:19] <maxb> you definitely don't want that lot all in one bzr branch
[19:20] <exarkun> Can I convince anyone at Canonical to split it up for me? :)
[19:20] <exarkun> Also, here's a complication
[19:21] <ScottK> exarkun: One major thing you lose going from svn to bzr is the ability to do partial checkouts.  Meaning anyone who wants one of those would need to branch/checkout all of them unless they are split up.
[19:21] <exarkun> It's a mirror of the whole svn repository, so there are 178 branches (probably some are obsolete and perhaps shouldn't be pushed, but I'm sure at least a few dozen are relevant)
[19:21] <maxb> Perhaps you could push the existing branch(es) to lp:~exarkun/+junk/various, then people can see what the current form of the branch(es) is
[19:21] <maxb> I don't suppose the original svn repository still exists?
[19:22] <exarkun> I have a copy of that too, yea
[19:23] <maxb> How large is that?
[19:23] <maxb> If not too big, simply letting me download it might be the easiest way to explain what the situation is
[19:24] <exarkun> 374MB
[19:25] <maxb> my connection will be happy with that if yours is :-)
[19:25] <exarkun> we can give it a try.  my upstream is somewhat limited, so it might take a while.
[19:27] <exarkun> just waiting for bzip2
[19:27] <maxb> The output of 'svn log -v file:///path/to/repo' would be smaller and somewhat informative, if a little more cumbersome to read than exploring an actual repository.
[19:31] <exarkun> both of those things available at http://home.intarweb.us:8080/
[19:31] <exarkun> (hopefully, let me know if I didn't hit my firewall right)
[19:33] <maxb> Hmm. gosh. very weird branching system
[19:35] <exarkun> oh, I forgot about the username thing.  that goes away after a while.
[19:35] <exarkun> anything else weird about it?
[19:35] <exarkun> I think it's normal enough that bzr-svn largely figured it out automatically
[19:35] <maxb> Hmm. So there are single commits that cross multiple projects
[19:36] <maxb> What did bzr-svn do by default? Did you get 1 trunk, or 1 trunk per project?
[19:37] <exarkun> someone else actually ran it, so I'm not sure.  But what he gave me was 1 trunk.
[19:37] <exarkun> http://codepad.org/MYbxKKt9
[19:38] <maxb> hmm
[19:38] <maxb> OK, so the fundamental problem with this conversion is what ScottK was saying. If you go with this style of conversion, everyone will always have to branch, tag, checkout, work on a tree containing all the projects, always, all the time
[19:39]  * exarkun nods
[19:39] <maxb> Whilst there seems to be some relationship (e.g. Axiom and Mantissa often getting commits together), it seems unlikely that you really want your object database's development fundamentally linked to that of a text adventure library :-)
[19:40] <exarkun> But if I want to split it up by project, then the branches that touch more than one project are going to be a problem?
[19:42] <maxb> Depends.... bzr-svn should be happy to import them as one-branch-per-branchname-per-project
[19:42] <maxb> But whether you consider that to be a useful conversion, I don't know
[19:43] <exarkun> is that done by specifying a different layout for the import?
[19:44] <exarkun> `--layout=ARGRepository layout (none, trunk, etc). Default: auto.` - is etc expanded anywhere?
[19:44] <maxb> I've never actually had cause to use bzr-svn against this sort of layout, I need to peer at the code a bit
[19:45] <maxb> Oh, no. It looks like it would be necessary to code a custom layout class to make sense of this repository
[19:47] <maxb> Hrm
[19:47] <maxb> that's probably not what you wanted to hear, but I think it's likely still worth pursuing, for the good of the future development of the project
[19:49] <exarkun> is there any documentation about writing custom layouts?
[19:50] <maxb> Not really, no
[19:52] <exarkun> okay
[19:52] <maxb> I need to go seek food before shops close around here. I'll have a closer look at the situation in ~4 hours or so, and let you know my thoughts
[19:52] <exarkun> thanks for all the help so far