2010-04-15
Next Session: TBD |
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)