[06:45] <wolter> hi, I want to link a +junk branch to a project, but when I try to link the branch to the series, i get "Invalid value"
[06:46] <wgrant> wolter: You'll need to push the branch up again, this time into the project. You can't link a +junk branch to a project.
[06:46] <wolter> oh
[06:46] <wolter> thanks wgrant :)
[07:04] <wolter> also, how can I make tarballs appear on the downloads box?
[07:04] <wgrant> wolter: Add files to a release.
[07:05] <wgrant> https://help.launchpad.net/Projects/FileDownloads
[07:06] <wolter> thanks again
[09:19] <evaluate> hello
[09:19] <evaluate> I sent an e-mail yesterday to ayatana-dev@lists.launchpad.net but I can't see the e-mail anywhere on the list.
[09:20] <lifeless> are you subscribed?
[09:20] <lifeless> if not, it will be in the moderation queue
[09:22] <evaluate> lifeless, I am subscribed, I just noticed that I didn't have the E-mail address, from which I sent the mail, in my account. Could this also be a reason?
[09:23] <lifeless> yes
[09:23] <evaluate> lifeless, ok, so it's fine and I just have to wait for it to be moderated?
[09:28] <lifeless> evaluate: AFAICT yes
[09:29] <evaluate> lifeless, ok, thank you! :-)
[13:16] <mok0_> Is there a way to change the text of a previous commit?
[13:16] <mok0_> (bzr question)
[13:17] <cdbs> mok0_: I guess the only way is to bzr uncommit, then bzr commit again, then bzr push --force
[13:17] <cdbs> bzr uncommit doesn't revert the changes, it just removes the commit
[13:17] <mok0_> cdbs: what if the commit is more than one commit old?
[13:17] <cdbs> hmm, gets confusing then
[13:17] <mok0_> cdbs: indeed
[13:18] <mok0_> cdbs: It's because of the annoying thing with bzr that you need to commit on a local branch after you pull from trunk
[13:19]  * maxb does not understand that last comment
[13:19] <mok0_> cdbs: so I have like, important changes from trunk, at a stupid little change locally, and the whole commit gets named after the stupid little change and not the important one :-(
[13:20] <cdbs> hmm mok0_  I can't help, I am not a bzr expert
[13:20] <maxb> I think you may be doing something wrong
[13:20] <mok0_> maxb: probably :-)
[13:21] <mok0_> maxb: I am working on the same project from several parallel checkouts
[13:22] <maxb> When I merge from trunk into a feature branch, I would usually just commit with the message "Merge trunk"
[13:22] <maxb> I assume you mean merge where you've said pull, since if you'd just successfully pulled, there would be nothing to commit
[13:23] <maxb> Are you perhaps referring to making the history look sensible when you merge a feature branch back into trunk?
[13:24] <mok0_> maxb, look at the log here: http://bazaar.launchpad.net/%7Emok0/gpp4/master/changes
[13:24] <mok0_> see rev 69
[13:24] <mok0_> It has the comment "get rid of..."
[13:25] <mok0_> which is like a one file change
[13:26] <maxb> hmm. I'm not sure why you'd commit a merge like that with a commit message like that
[13:26] <maxb> It doesn't make sense :-)
[13:26] <mok0_> maxb: no
[13:26] <mok0_> :-)
[13:26] <mok0_> maxb: that's why I'd like to change it
[13:26] <mok0_> maxb, guess I'll have to find another mode of working with bzr
[13:27] <mok0_> maxb: the merge 68.1.2 has the really important changes
[13:28] <maxb> I think part of the problem is that you committed both a merge and a direct change at the same time - how did you do that? I believe 'bzr merge' complains if you try to merge when you already have local changes
[13:30] <mok0_> maxb, I can't remember exactly what I did
[13:30] <mok0_> maxb, I might have forced a merge
[13:31] <maxb> ok. Well, one of the major rules of having a comprehensible history is that every commit should be either a direct change or a merge, never both together
[13:31] <mok0_> maxb: what else to do, if you've done a lot of edits, and realize you need to import fixes which is already commited?
[13:32] <maxb> Several options
[13:33] <maxb> 1) If your local changes are not yet committed, 'bzr pull' would bring in the new revisions, merge your working copy, leaving you with your uncommitted changes still uncommitted
[13:33] <maxb> 2) Or, if your local changes are not yet committed, and you want to store them out of the way whilst you pull, to be brought back later, 'bzr shelve'
[13:34] <mok0_> maxb, ah, perhaps that is the trick I need to use
[13:34] <mok0_> maxb: Sometimes I get the message that the versions have diverged
[13:34] <maxb> 3) Or, if your branch has already diverged from trunk, and you have no local changes, then you do need to do a merge
[13:35] <mok0_> maxb: I think it's in case 3 that the commit message gets buried
[13:35] <maxb> 4) Or, if your branch has already diverged from trunk AND you have additional local changes, then you need to commit or shelve the local changes before doing a merge
[13:36] <maxb> In case 3 there are no local changes, and the commit message exists solely to describe what you are merging
[13:36] <mok0_> maxb: case 4 rather
[13:36] <mok0_> maxb: if I fail to shelve, I think the commit message gets buried in a sub-revision
[13:37] <maxb> In case 4, you shelved or committed the local changes before merging, so the merge commit message *still* exists solely to describe what you are merging
[13:37] <maxb> If you fail to commit or shelve first, then merge refuses to work because your local copy is not clean. If you --force it.... on your head be it :-)
[13:38] <mok0_> maxb: I understand
[13:38] <mok0_> maxb: sometimes I don't want to make a commit, because what I'm doing is not completed
[13:38] <mok0_> maxb, I just want to pull in revisions that I know I've done
[13:39] <mok0_> maxb: so I guess "shelve" is what I should be doing
[13:40] <mok0_> maxb: but what happens if there is a conflict when you "unshelve"?
[13:41] <maxb> Same as what happens for any conflict that arises from "merge"
[13:43] <mok0_> maxb: thanks for the tips! Very useful
[14:58] <gusnan> I am upstream of a package, and also maintain it in debian - Now I see that the powerpc build fails in Ubuntu - but I get no log or anything - what is the problem? the page where I would expect a build log just says "Failed to build".
[14:59] <gusnan> the package is sciteproj, see https://launchpad.net/ubuntu/+source/sciteproj/0.3.22-1/+build/2099651
[15:28] <CarlFK> shouldn't marking a bug as close cascade to duplicate bugs?
[16:09] <maxb> gusnan_: AFAIK a failed build with no log is a result of a build being terminated abnormally by the launchpad buildd system. I would suggest asking someone to trigger a retry
[16:10] <maxb> I think any MOTU can do this for you - ask in #ubuntu-motu
[16:21] <gusnan_> maxb, Thanks!
[16:24] <maxb> CarlFK: No. If a bug is marked as a duplicate, it is considered as having no status of its own, so there's nothing to cascade to.
[16:24] <CarlFK> maxb: does the dupe need to be closed, or is the dupe status already close it?
[16:25] <maxb> The dupe does not need to be closed
[16:27] <CarlFK> k thanks
[16:32] <exarkun> Can tickets/ticket comments be migrated from trac into launchpad (not synchronize, just one off)?
[16:42] <maxb> There is a bulk import XML format which the Launchpad sysadmins can use to migrate bugs into launchpad. I'm not sure if anyone has written an exporter from trac to that format, but it seems possible
[16:44] <exarkun> maxb: Ah.  I just found https://launchpad.net/trac-launchpad-migrator and was wondering what to do with the XML afterwards.
[16:44] <maxb> As it's a weekend, your best option might be to email the launchpad-users mailing list - enough of the right people watch it that you ought to get an answer in the coming week, I think
[16:45] <maxb> ah, in that case, I suggest trying to produce the XML dump, and then registering a question (https://answers.launchpad.net/launchpad/+addquestion) to get the import process started
[16:46] <exarkun> Cool, thanks.
[17:59] <lifeless> exarkun: hi
[19:11] <exarkun> lifeless: Hi
[19:23] <lifeless> exarkun: we often test imports on staging - that needs a losa, which is going to be in fairly short supply this week - holiday season
[19:23] <lifeless> exarkun: (importing to prod also requires a losa)
[19:25] <exarkun> I don't think anyone will be surprised if it takes until early january for this process to be completed.
[19:25] <lifeless> cool
[19:25] <lifeless> something you can do to test locally, if you want, is to setup a vm with launchpad in it, and run the import script yourself. https://dev.launchpad.net/Running/VirtualMachine
[19:26] <exarkun> I have to figure out how to extract data from a corrupt database file first, anyway :/
[19:26] <lifeless> I don't know if thats worth the effort or not.
[19:26] <lifeless> ugh
[19:26] <lifeless> thats less than pleasant
[19:26] <exarkun> Yes
[19:27] <exarkun> But it's Saturday so I'll do something fun instead, like write Python bindings for this C++ library
[19:27] <lifeless> \o/