1 [16:01] <james_w> hi
   2 [16:02] <james_w> Who is here for the packaging training session?
   3 [16:06] <james_w> I'll wait a couple more minutes for people to join
   4 [16:07] <james_w> right, hello everyone
   5 [16:07] <james_w> most of the names that just joined I recognise, so I won't take it too slowly today
   6 [16:08] <james_w> this is all a bit last-minute though, so I don't have anything prepared
   7 [16:08] <james_w> so I'm happy to answer any questions you have
   8 [16:08] <james_w> right, so a quick introduction
   9 [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
  10 [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
  11 [16:10] <james_w> bzr is a version control system, and so is probably more familiar to newcomers
  12 [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
  13 [16:10] <james_w> bzr-builddeb is a plugin for bzr that knows about packaging stuff
  14 [16:11] <james_w> once you have those, then you can run
  15 [16:11] <james_w> bzr branch lp:ubuntu/<source package name>
  16 [16:11] <james_w> to get the current source of any package in ubuntu as a bzr branch
  17 [16:11] <james_w> there is also lp:ubuntu/karmic/source etc. as well
  18 [16:12] <james_w> you can run bzr log and bzr annotate and the like to see how the package evolved over time
  19 [16:13] <james_w> that gets useful when debugging etc.
  20 [16:13] <james_w> now, you can build a package by using "bzr builddeb" from one of these branches
  21 [16:13] <james_w> "bzr bd" for short
  22 [16:13] <james_w> to build a source package use "bzr bd -S"
  23 [16:13] <james_w> <joaopinto> QUESTION: is there a specific bzr revision for each different version commited to the archives ?
  24 [16:13] <james_w> yes
  25 [16:14] <james_w> grab a branch of a package you know and have a look
  26 [16:14] <james_w> or click around on launchpad
  27 [16:14] <james_w> https://launchpad.net/ubuntu/+source/package
  28 [16:14] <james_w> and then click on "Branches" and you can browse them online
  29 [16:14] <james_w> <blueyed> 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)?
  30 [16:14] <james_w> that would be cool
  31 [16:14] <james_w> however, you can't do it automatically
  32 [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
  33 [16:16] <james_w> so, we currently require a human to tell us what value to use
  34 [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
  35 [16:17] <james_w> the main thing stopping me is that I can't come up with a good name for that flag ;-)
  36 [16:18] <james_w> so, once you have built the package with your changes and tested it, you can commit
  37 [16:18] <james_w> how do you get someone to upload that for you?
  38 [16:19] <james_w> to do that you should propose the branch for merging on launchpad
  39 [16:19] <james_w> first, push it to your namespace on launchpad
  40 [16:19] <james_w> bzr push lp:~LP-ID/ubuntu/lucid/package/some-descriptive-name
  41 [16:19] <james_w> then open up the branch page on launchpad and click "Propose for merging"
  42 [16:20] <james_w> explain what you have done and click "Propose"
  43 [16:20] <james_w> a couple of timesavers here:
  44 [16:20] <james_w> bzr lp-open
  45 [16:20] <james_w> running that after you pushed will open your browser at the right page
  46 [16:20] <james_w> bzr lp-propose
  47 [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
  48 [16:21] <james_w> someone will review your changes and vote on them
  49 [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
  50 [16:22] <james_w> once they are happy they will upload it for you
  51 [16:22] <james_w> <joaopinto> QUESTION:  Are there branches for Debian packages (lp:debian/package) ?
  52 [16:22] <james_w> indeed
  53 [16:22] <james_w> you can find any debian package that way as well
  54 [16:23] <james_w> the history isn't nearly as complete for Debian packages, but it will improve from here on out
  55 [16:23] <james_w> so, what can you do with the Debian branches?
  56 [16:23] <james_w> diff between Ubuntu and Debian when investigating something
  57 [16:23] <james_w> merge from Debian to pull in their changes
  58 [16:23] <james_w> cherry-pick from them when near release time and you just want part of their changes
  59 [16:24] <james_w> use the branches to generate a diff to send back to them
  60 [16:24] <james_w> let's look at merging
  61 [16:24] <james_w> from a copy of an ubuntu branch you can run
  62 [16:24] <james_w> bzr merge-package lp:debian/sid/package
  63 [16:24] <james_w> to merge from the sid version of the package
  64 [16:26] <james_w> this may give you conflicts, which you can resolve
  65 [16:26] <james_w> run "bzr diff" if you want to check the changes that are being pulled in
  66 [16:26] <james_w> then commit when you are happy
  67 [16:26] <james_w> running
  68 [16:26] <james_w> bzr diff --old lp:debian/sid/package
  69 [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
  70 [16:26] <james_w> again you can push this up and request the merge
  71 [16:27] <james_w> <blueyed> 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?
  72 [16:27] <james_w> first, no, mark-uploaded is just creating a tag
  73 [16:27] <james_w> in maverick you will just be able to run "bzr tag" thanks to jelmer
  74 [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
  75 [16:28] <james_w> might be worth a go
  76 [16:28] <james_w> I'd be happy to help you implement it if you like
  77 [16:28] <james_w> <ckorn42> QUESTION: so no more debdiffs ?
  78 [16:28] <james_w> you don't have to use debdiffs to get sponsored any more
  79 [16:28] <james_w> they may have their use from time to time
  80 [16:29] <james_w> any more questions before I move on?
  81 [16:31] <james_w> <joaopinto> QUESTION: are there branchs for PPAs  ?
  82 [16:31] <james_w> only if you make them
  83 [16:31] <james_w> you can branch from Ubuntu, make your changes, and then push it
  84 [16:31] <james_w> uploading the source package to your PPA
  85 [16:31] <james_w> they aren't created automatically or anything though
  86 [16:36] <james_w> <blueyed> 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.
  87 [16:36] <james_w> I don't think that's possible
  88 [16:36] <james_w> ask in #bzr
  89 [16:36] <james_w> <blueyed> QUESTION: branches for PPA: is there planned anything to get them created automatically?
  90 [16:36] <james_w> no
  91 [16:37] <james_w> there's not a lot of payoff there
  92 [16:37] <james_w> and you can just use bzr to manage the PPAs
  93 [16:38] <james_w> right, we've looked at merging from Debian
  94 [16:38] <james_w> let's look briefly at merging from upstream
  95 [16:38] <james_w> this is based around the inventively named "bzr merge-upstream" command
  96 [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)
  97 [16:39] <james_w> and the version number that is assigned to this release
  98 [16:39] <james_w> bzr merge-upstream --version 1.2 http://example.org/foo-1.2.tar.gz
  99 [16:40] <james_w> works with tar.gz tar.bz2 .zip and a couple more
 100 [16:40] <james_w> again it will leave you with a diff to review and any conflicts to fix up
 101 [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
 102 [16:41] <james_w> "bzr merge-upstream" would just find everything out and do the obvious thing for you
 103 [16:41] <james_w> I think this is one of the coolest things
 104 [16:42] <james_w> and I plan to add more things as cool as that and build on top of it
 105 [16:42] <james_w> so, what else do we have planned?
 106 [16:42] <james_w> work is currently underway to add support in Launchpad for building from branches
 107 [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
 108 [16:43] <james_w> we will probably extend that to Ubuntu itself once we are happy with it
 109 [16:44] <james_w> this will allow us to do lots of great things
 110 [16:44] <james_w> daily builds will be just a few clicks
 111 [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
 112 [16:44] <james_w> like, one command easy if someone wants to automate that
 113 [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
 114 [16:46] <james_w> <mhall119> QUESTION: are you doing anything with ground control to get these features in that?
 115 [16:46] <james_w> not yet
 116 [16:46] <james_w> but I want to have some of that stuff
 117 [16:46] <james_w> there's a possible SoC project to lay the groundwork for that
 118 [16:46] <james_w> we're not /quite/ at the point where we can have something as slick as groundcontrol, but very close
 119 [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
 120 [16:47] <james_w> right, any more questions for the last 10 minutes
 121 [16:48] <james_w> right, some cool stuff
 122 === apachelogger is now known as starshiptrooper
 123 [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
 124 [16:49] <james_w> assuming that it's v3 quilt right now
 125 [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
 126 [16:50] <ClassBot> There are are 10 minutes remaining in the current session.
 127 [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
 128 [16:51] <james_w> similar with cherry picking
 129 [16:51] <james_w> you can grab the changes in the last debian upload and pull them in to your tree
 130 [16:51] <james_w> bzr merge -c 1 lp:debian/sid/package
 131 [16:52] <james_w> then use "bzr revert" and "bzr shelve --destroy" to remove the parts you don't want
 132 [16:52] <james_w> and keep only the parts you do
 133 [16:52] <james_w> you don't need to rely on Merge-o-Matic to have the merge ready for you to apply
 134 [16:52] <james_w> you can merge from testing, unstable, experimental as you like
 135 [16:52] <james_w> or the branch of anyone else in the same way
 136 [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
 137 [16:53] <james_w> and plenty more as well
 138 [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
 139 [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
 140 [16:55] <james_w> any last questions?
 141 [16:55] <ClassBot> There are are 5 minutes remaining in the current session.
 142 [16:58] <james_w> ok, let's call it a day and go make lucid even better :-)
 143 [16:58] <james_w> thanks all


Packaging/Training/Logs/2010-04-15 (last edited 2010-04-15 22:29:55 by 99-21-107-94)