[02:59] <larka06> Hello everyone
[03:03] <larka06> I do not think anyone is home today. I see the schedule is tomorrow. bye
[16:01] <james_w> hi
[16:02] <james_w> Who is here for the packaging training session?
[16:06] <james_w> I'll wait a couple more minutes for people to join
[16:07] <james_w> right, hello everyone
[16:07] <james_w> most of the names that just joined I recognise, so I won't take it too slowly today
[16:08] <james_w> this is all a bit last-minute though, so I don't have anything prepared
[16:08] <james_w> so I'm happy to answer any questions you have
[16:08] <james_w> right, so a quick introduction
[16:09] <james_w> you can now use bzr for doing a lot of packaging work, instead of having to learn how to generate debdiffs and the like
[16:09] <james_w> debdiffs are ok, they have some disadvantages, but the main thing is that they aren't something used in other projects
[16:10] <james_w> bzr is a version control system, and so is probably more familiar to newcomers
[16:10] <james_w> so, if you want to make use of it, please install bzr and bzr-builddeb if you don't already have them installed
[16:10] <james_w> bzr-builddeb is a plugin for bzr that knows about packaging stuff
[16:11] <james_w> once you have those, then you can run
[16:11] <james_w> bzr branch lp:ubuntu/<source package name>
[16:11] <james_w> to get the current source of any package in ubuntu as a bzr branch
[16:11] <james_w> there is also lp:ubuntu/karmic/source etc. as well
[16:12] <james_w> you can run bzr log and bzr annotate and the like to see how the package evolved over time
[16:13] <james_w> that gets useful when debugging etc.
[16:13] <james_w> now, you can build a package by using "bzr builddeb" from one of these branches
[16:13] <james_w> "bzr bd" for short
[16:13] <james_w> to build a source package use "bzr bd -S"
 QUESTION: is there a specific bzr revision for each different version commited to the archives ?
[16:13] <james_w> yes
[16:14] <james_w> grab a branch of a package you know and have a look
[16:14] <james_w> or click around on launchpad
[16:14] <james_w> https://launchpad.net/ubuntu/+source/package
[16:14] <james_w> and then click on "Branches" and you can browse them online
 Question: Would it make sense to automatically handle "-v" when doing "bzr builddeb -S" (so that it auto-adds the last uploaded version with it)?
[16:14] <james_w> that would be cool
[16:14] <james_w> however, you can't do it automatically
[16:15] <james_w> without querying something remote to find out what the current version is, and I don't want building a package to require that
[16:16] <james_w> so, we currently require a human to tell us what value to use
[16:16] <james_w> what I would like to do is have a flag to say "this is a merge from Debian", so use -vlast-ubuntu-version and -sa if needed
[16:17] <james_w> the main thing stopping me is that I can't come up with a good name for that flag ;-)
[16:18] <james_w> so, once you have built the package with your changes and tested it, you can commit
[16:18] <james_w> how do you get someone to upload that for you?
[16:19] <james_w> to do that you should propose the branch for merging on launchpad
[16:19] <james_w> first, push it to your namespace on launchpad
[16:19] <james_w> bzr push lp:~LP-ID/ubuntu/lucid/package/some-descriptive-name
[16:19] <james_w> then open up the branch page on launchpad and click "Propose for merging"
[16:20] <james_w> explain what you have done and click "Propose"
[16:20] <james_w> a couple of timesavers here:
[16:20] <james_w> bzr lp-open
[16:20] <james_w> running that after you pushed will open your browser at the right page
[16:20] <james_w> bzr lp-propose
[16:21] <james_w> instead of clicking around on the webapp this will let you type your description in to your editor, like when you commit, and then make the merge proposal for you
[16:21] <james_w> someone will review your changes and vote on them
[16:22] <james_w> if they would like you to fix something then you can just make the changes locally, "bzr commit", "bzr push" and then comment on the merge proposal to say you have done it
[16:22] <james_w> once they are happy they will upload it for you
 QUESTION:  Are there branches for Debian packages (lp:debian/package) ?
[16:22] <james_w> indeed
[16:22] <james_w> you can find any debian package that way as well
[16:23] <james_w> the history isn't nearly as complete for Debian packages, but it will improve from here on out
[16:23] <james_w> so, what can you do with the Debian branches?
[16:23] <james_w> diff between Ubuntu and Debian when investigating something
[16:23] <james_w> merge from Debian to pull in their changes
[16:23] <james_w> cherry-pick from them when near release time and you just want part of their changes
[16:24] <james_w> use the branches to generate a diff to send back to them
[16:24] <james_w> let's look at merging
[16:24] <james_w> from a copy of an ubuntu branch you can run
[16:24] <james_w> bzr merge-package lp:debian/sid/package
[16:24] <james_w> to merge from the sid version of the package
[16:26] <james_w> this may give you conflicts, which you can resolve
[16:26] <james_w> run "bzr diff" if you want to check the changes that are being pulled in
[16:26] <james_w> then commit when you are happy
[16:26] <james_w> running
[16:26] <james_w> bzr diff --old lp:debian/sid/package
[16:26] <james_w> will tell you the current diff from Debian, so you can see if there is anything that should be submitted back
[16:26] <james_w> again you can push this up and request the merge
 QUESTION: re auto-using "-v" with "bzr bd", couldn't you use the last tag from mark-uploaded? Does mark-uploaded do anything besides creating a tag only?
[16:27] <james_w> first, no, mark-uploaded is just creating a tag
[16:27] <james_w> in maverick you will just be able to run "bzr tag" thanks to jelmer
[16:28] <james_w> as for using the last tag from mark-uploaded that's an interesting idea, but I'm not sure if it would be reliable enough
[16:28] <james_w> might be worth a go
[16:28] <james_w> I'd be happy to help you implement it if you like
 QUESTION: so no more debdiffs ?
[16:28] <james_w> you don't have to use debdiffs to get sponsored any more
[16:28] <james_w> they may have their use from time to time
[16:29] <james_w> any more questions before I move on?
 QUESTION: are there branchs for PPAs  ?
[16:31] <james_w> only if you make them
[16:31] <james_w> you can branch from Ubuntu, make your changes, and then push it
[16:31] <james_w> uploading the source package to your PPA
[16:31] <james_w> they aren't created automatically or anything though
 QUESTION: more bzr related. Is it possible to get the "diff" after a merge annotated? When diffing, you see what's added, but not from what particular merged revision.
[16:36] <james_w> I don't think that's possible
[16:36] <james_w> ask in #bzr
 QUESTION: branches for PPA: is there planned anything to get them created automatically?
[16:36] <james_w> no
[16:37] <james_w> there's not a lot of payoff there
[16:37] <james_w> and you can just use bzr to manage the PPAs
[16:38] <james_w> right, we've looked at merging from Debian
[16:38] <james_w> let's look briefly at merging from upstream
[16:38] <james_w> this is based around the inventively named "bzr merge-upstream" command
[16:39] <james_w> from one of the branches we got earlier we can merge a new upstream release by passing it the URL of the tarball of the new upstream release (or a local path if you have already downloaded it)
[16:39] <james_w> and the version number that is assigned to this release
[16:39] <james_w> bzr merge-upstream --version 1.2 http://example.org/foo-1.2.tar.gz
[16:40] <james_w> works with tar.gz tar.bz2 .zip and a couple more
[16:40] <james_w> again it will leave you with a diff to review and any conflicts to fix up
[16:40] <james_w> I plan to make it use uscan, so that you don't even have to tell it that stuff if you have a watch file
[16:41] <james_w> "bzr merge-upstream" would just find everything out and do the obvious thing for you
[16:41] <james_w> I think this is one of the coolest things
[16:42] <james_w> and I plan to add more things as cool as that and build on top of it
[16:42] <james_w> so, what else do we have planned?
[16:42] <james_w> work is currently underway to add support in Launchpad for building from branches
[16:43] <james_w> that means you will be able to go from the branch you just pushed up to a package in your PPA without building and uploading it
[16:43] <james_w> we will probably extend that to Ubuntu itself once we are happy with it
[16:44] <james_w> this will allow us to do lots of great things
[16:44] <james_w> daily builds will be just a few clicks
[16:44] <james_w> it will be easy for people to find a patch upsteam, stick it in to bzr, and put it in their PPA for people on the bug to test
[16:44] <james_w> like, one command easy if someone wants to automate that
[16:45] <james_w> and building on top of bzr makes it easier for an Ubuntu developer to hoover up such patches after testing and merge them all together
 QUESTION: are you doing anything with ground control to get these features in that?
[16:46] <james_w> not yet
[16:46] <james_w> but I want to have some of that stuff
[16:46] <james_w> there's a possible SoC project to lay the groundwork for that
[16:46] <james_w> we're not /quite/ at the point where we can have something as slick as groundcontrol, but very close
[16:47] <james_w> and because we are just using bzr, launchpad etc. it should be easy to modify groundcontrol to do packages as well as projects
[16:47] <james_w> right, any more questions for the last 10 minutes
[16:48] <james_w> right, some cool stuff
[16:49] <james_w> bzr gannotate or the qt equivalent when you find a bad line of code can tell you when it was changed, regardless of whether upstream debian or ubuntu changed it
[16:49] <james_w> assuming that it's v3 quilt right now
[16:50] <james_w> and you can then go from that to the diff of the revision that uploaded it, so see the rationale in the changelog
[16:50] <ClassBot> There are are 10 minutes remaining in the current session.
[16:50] <james_w> and if you want to revert it, it's one bzr command, rather than doing it by hand, or trying to generate a patch to reverse-apply
[16:51] <james_w> similar with cherry picking
[16:51] <james_w> you can grab the changes in the last debian upload and pull them in to your tree
[16:51] <james_w> bzr merge -c 1 lp:debian/sid/package
[16:52] <james_w> then use "bzr revert" and "bzr shelve --destroy" to remove the parts you don't want
[16:52] <james_w> and keep only the parts you do
[16:52] <james_w> you don't need to rely on Merge-o-Matic to have the merge ready for you to apply
[16:52] <james_w> you can merge from testing, unstable, experimental as you like
[16:52] <james_w> or the branch of anyone else in the same way
[16:53] <james_w> you have a version control system so you can just "bzr revert" if you get in to a strange situation, rather than having to blow away your workspace and unpack the source package again like you had to sometimes before
[16:53] <james_w> and plenty more as well
[16:54] <james_w> there's loads of opportunity for automating tasks and the like now, so if you have an idea for something like that I would be happy to help you implement it
[16:54] <james_w> and I'm keen that the tools are usable, so if you find something that is too hard or doesn't make sense, please file a bug
[16:55] <james_w> any last questions?
[16:55] <ClassBot> There are are 5 minutes remaining in the current session.
[16:58] <james_w> ok, let's call it a day and go make lucid even better :-)
[16:58] <james_w> thanks all
[21:02] <mhall119> james_w: are you still around?
[21:02] <james_w> yeah