-
Thank you very much.
-
Thanks everybody for coming,…
-
If you are packaging software and you want
me to work on with you,
-
this is how you can do that.
-
It is a very self-??? talk:
-
I just want to explain some of the things
that I like,
-
some practice that I prefer about Debian
packaging,
-
and I don't pretend this is any sort of…
-
official, permanent or final thing.
-
I just wanted to share some ideas that I
have about the way that I work with
-
packages, in the hope that maybe, hmm,
for two hopes:
-
One is that I hope that I can show you
something that you have not heard of,
-
or maybe you were doing differently,
-
or maybe you think it is
the right think to do
-
and it is just nice to see
somebody else doing it.
-
My second hope is that you can tell me
what I am doing wrong,
-
and you can help me learn and improve
on my own packaging techniques.
-
If you see something that
I am proposing up here,
-
and you think there is a problem with it,
I would like to hear about it too.
-
I just want to see more of the culture
within Debian,
-
of people who are doing packaging,
explaining what they are doing,
-
and so I thought I would
just step up and explain:
-
"Here is some of the practice that I do",
-
In the hope that other people will do the
same and explain what they are doing,
-
and maybe they can learn from
me and I can learn from them.
-
Without much further ????, I am
just going to dive into it.
-
If you have questions, I am perfectly
happy to be interrupted,
-
we have some folks with walking mics
in the crowd:
-
you can just raise your hand.
-
If you have got a question or an
interruption or whatever,
-
that is fine.
-
I doubt I will go the whole 15 minutes,
I think there are 20 minutes,
-
I doubt I will go the whole time,
so there will be also
-
time for questions at
the end if you prefer.
-
But I do not mind being interrupted.
-
So, this is all on this web page here,
-
you could probably skip this talk and go
read the web page,
-
but then you would not have the nice
??? actions,
-
and it is easier to tell me that I am
wrong in person,
-
so I would like to have that happen.
-
I put this up on the Debian wiki,
-
because I want anyone
to be able to find it.
-
If you think you have got some good ideas,
you should put it on the Debian Wiki too:
-
other people can take advantage of the
ideas that you have got.
-
First baseline is:
I really like revision control.
-
And I know that it makes me
a certain flavor on nerd,
-
but when we are working with things that
are as complicated as software packages,
-
hmmm…
-
I think a lot of people don't get
that in Debian you are not
-
just working on one
software package:
-
you are actually probably, if you
are doing a responsibly work,
-
on at least two software packages,
and maybe 5.
-
So you have got the version that is
unstable,
-
and you have got the version that you
try to maintain for stable as well.
-
And we are committing to
doing maintenance work.
-
A lot of our work in the project is ???
in nature:
-
we want to clean up the mess and
we want us to stay out of the way
-
and make sure things work,
functionally,
-
for people who are relying on the
operating system to not get in their way.
-
So revision control I think is really
helpful because it means you can
-
keep track of what changes you have done
on different branches of the project
-
while you are maintaining both of them.
-
Basically, ??? require working with
the revision system I am comfortable with,
-
I prefer Git, I am not going to have a
religious word about it.
-
If upstream uses Git, I am
even happier, and I try to make
-
my packaging depend on
upstream's revision control.
-
I like to use 'git-buildpackage', and I
like to use it with debhelper.
-
If you have not tried out
'git-buildpackage',
-
we are going to have a
'git-buildpackage' skill share session
-
later on today actually, and I welcome
you to come and share your tricks with it,
-
or learn some tricks from other people.
-
It is a particular way that you can keep
your Debian packaging in a Git repository,
-
and it helps you to keep track of all of
the changes that have happened within
-
your packaging and within upstream to
make sure you are not accidentally
-
making other changes.
-
So it is very easy to go back and
review what you have done.
-
I find that really useful.
-
I definitely also like to keep
upstream's source code
-
in the same revision control system.
-
I like to keep the tarballs in the
revision control system
-
because it means that
if someone is interested,
-
they can uses a tool called
'debcheckout'.
-
You can use 'debcheckout' with
a name of a package:
-
you just say "I am really
interested in package 'foo',
-
let me see the source code for that":
'debcheckout foo'
-
You get the source code, and
you get the source code…
-
from a revision control system
that you can now track
-
and you can just propose changes on.
-
You can also extract the tarball from that
revision control system.
-
'debcheckout' actually works even if you
do not have upstream stuff in there,
-
but I like to keep it all in one
revision control system,
-
it is just easier to find everything
when you want.
-
Some of these things that
I prefer have to do with
-
what the upstream software
developer has done,
-
so I am less inclined to try the package,
an upstream software project,
-
if they just throw tarballs
here over the wall
-
to an FTP side every now and then.
-
It makes it more difficult for me to
know what they are doing,
-
and why they are doing it.
-
So i like it, I have already said,
when upstream uses Git,
-
I also like it when upstream
signs their releases,
-
and says "hey, this is specific release",
-
because that is a signal
that I can use,
-
or somebody else that
understands the project.
-
As said, "we think that this is
something that other people can use",
-
or "this is a particular version that
we would like other people to test".
-
There are a lot of other situations where
maybe it is not so important.
-
And having that be cryptographically
signed is really useful.
-
I care about cryptographic signature on
software because I want to know that
-
what I am running is related to the code
that somebody else out should be run.
-
And if you don't verify your
software cryptographically,
-
anyone who can intercept
the network connection
-
between you and that software, can
modify the software before it gets to you.
-
And the cryptographic signature just says:
-
"look, this is a version
that I am OK with.
-
I am putting it out there
and it comes from me".
-
So I can have a trace back
to that point.
-
??? just talk about briefly about how you
do cryptographic verification of upstream.
-
One is you might know upstream:
-
you might know them personally, you
know their key already, that is fine.
-
That is not the usual case:
we work on the Internet.
-
In the situation where your upstream
is signing their tarballs
-
and you have not met them,
you do not have to sign their key,
-
you do not have to say
"I announce this is their key".
-
But it is probably the same one
that is signing every release,
-
so you should keep track of that.
-
Debian has a nice way to
keep track of that:
-
you can tell Debian how to find the new
version of the upstream tarball.
-
This is in the Debian 'watch' file.
-
If you type 'man uscan', you can learn
more about Debian 'watch',
-
and Debian 'watch' now has
a feature that lets you say
-
"that is not only this way
you find the tarball,
-
but upstream publishes signatures
and the signatures look like this".
-
You know, they got a '.sig' at the end.
-
So there is a particular arcane way to
specify that, but if you specify that,
-
then 'uscan' can find
not only the upstream tarball,
-
it can find the upstream signature.
-
And, if you drop
upstream's signing key
-
- which of course I did not
put on the wiki page,
-
someone should
edit that and fix it -
-
you can put the upstream signing
key in 'debian/upstream/signing-key.asc'.
-
And then if you do that, when you say
'uscan', you can tell…
-
Maybe some people here do not
know how to use 'uscan':
-
'uscan' is a very simple tool,
-
you run it from a software package
that has a 'debian' directory,
-
or even one level up if you keep all of
your software packages in one folder.
-
You can go one level up
and say 'uscan',
-
and it will look in all of the folder
that are children of it,
-
and look for new versions
-
by trying to find a new upstream
version in 'debian/watch'.
-
And if you have configured
'debian/watch' properly,
-
it can find the new upstream signatures,
-
and if you have got the
'upstream/signing-key.asc',
-
then it will actually verify
the signatures for you
-
as part of fetching the
new upstream tarball.
-
So you can get all of those things just
by setting ???? that way.
-
There is a hand up down there, could we
get the mic down to the hand ?
-
Thanks.
-
Or to the person who has that hand,
it is not just a hand. [public laugh]
-
[attendee] Publish a tarball,
and a hash, '.sha1',
-
and sign that hash,
'.sha1.asc'.
-
Can 'uscan' cope with this and
check the signature on the hash
-
and that the hash belongs
to that tarball ?
-
[Daniel] I do not believe that 'uscan'
can do that currently.
-
So anybody out there who wants to make
things better for the world
-
should go hack on 'uscan': that is a
pretty straightforward thing
-
that we should fix because
I agree that is common pattern.
-
[attendee] I have no answer to this
question by I have another question:
-
how do you convince upstreams
who do not release tarballs
-
or who do not set tags in Git ?
-
[Daniel] Who do not make tags in Git ?
-
[someone] Yes, if there is no tags
you can not check out a tarball.
-
Is there any good way to
convince upstream to do this ?
-
[Daniel] Git has this nice feature, which
is that you can create a tag,
-
which is associated with
a particular revision,
-
and you would like to have a tag
-
everywhere that a tarball
has been released from.
-
I am tempted to pull up a Git
view and show people some tags.
-
The question that you ask is a
social one, not just a technical one,
-
and I actually find that my upstreams
are pretty responsive.
-
Usually I frame my request as
-
"hey, it like you made this tarball
from this particular commit 'id'.
-
If you could tag you releases,
it would be really helpful to me,
-
and here is the command
that I would use to tag the release".
-
And I say "git tag…"
-
and of course I can never
remember so first I look it up,
-
but it is either 'tag name' 'commit id'
or 'commit id' 'tag name'.
-
But I would look it up and
I would write the e-mail so that
-
all they have to do is they read it,
-
understand my argument,
-
and execute one command.
-
And then it starts them ??????
-
And if you say 'tag -s',
-
Not Synced
then your tag will be
cryptographically signed,
-
Not Synced
which I think is a really
good thing to do too.
-
Not Synced
So, cryptographic verification of
upstream.
-
Not Synced
As I said, I want to keep upstream's code
in the revision control system.
-
Not Synced
I also like to keep…
-
Not Synced
In my ideal case upstream is using Git:
I am using Git for packaging.
-
Not Synced
I actually like to keep upsteam's Git
history fully in my repository,
-
Not Synced
so that I do not just have the tarballs,
but I actually have all of their commits.
-
Not Synced
And that turns out to be really useful
for two specific cases:
-
Not Synced
In one case, there is a common scenario
where upstream will fix a bug,
-
Not Synced
but they have not made a release yet.
-
Not Synced
And that bug is really, really obviously
problematic for the folks who are
-
Not Synced
using Debian, so want to fix it.
-
Not Synced
All I can do, because I have their full
revision history, I can use Git to "cherry
-
Not Synced
pick" the upstream commit.
-
Not Synced
And then I "cherry pick" that upstream
commit and I can have it applied
-
Not Synced
separately and release an Debian version
that has the fix, even before upstream
-
Not Synced
has made a release with the fix.
-
Not Synced
So one nice thing about having upstream
revision is that I can pull fixes from
-
Not Synced
upstream before they decided
to release it.
-
Not Synced
The other advantage is the other
way around.
-
Not Synced
Often when I am doing packaging,
I discover a problem,
-
Not Synced
and maybe I can fix the problem.
-
Not Synced
And if that maybe I am already shipping
a Debian package that fixes the problem.
-
Not Synced
If my Debian fixes can be directly applied
to upstream, then I can use whatever
-
Not Synced
their preferred upstream patch
submission guidelines are,
-
Not Synced
whether it is a Github pull request, or
a patch to a mailing list,
-
Not Synced
or a "hey can you pull this from my Git
repository over here", e-mail…
-
Not Synced
The fact that I am using the same Git
history that they are using makes it
-
Not Synced
much easier for me to push my changes
back to them.
-
Not Synced
So, it sort of smooth the interaction if
you can consolidate and use the same
-
Not Synced
revision control system as their.
-
Not Synced
Towards that aim, I use a system now
called 'patch q',
-
Not Synced
which is part of 'git buildpackage'.
-
Not Synced
So 'git buildpackage' is 'gbp', 'patch q'
is 'pq',
-
Not Synced
so to deal with 'patch q' you say
'gbp pq'
-
Not Synced
and then you have some commands.
-
Not Synced
And what that does, is it takes…
-
Not Synced
How many of you are Debian packagers ?
-
Not Synced
How many of you package
software for Debian ?
-
Not Synced
A very large percentage, but not everyone.
-
Not Synced
I hope some folks are considering starting
packaging if you have not done it yet.
-
Not Synced
Of those of you who package software,
how many of you package software
-
Not Synced
with modifications, how many of you ship
a modified version of upstream sources ?
-
Not Synced
Beyond the 'debian' directory, just Debian
patches ?
-
Not Synced
So the common way to do that, for the
Debian 3.0 ??? packaging skill, is that in
-
Not Synced
your 'debian' directory you have a
'patches' sub-directory that has a set of
-
Not Synced
individual patches that apply certain
changes, and they are applied in order
-
Not Synced
based on the file called
'debian/patches/series'.
-
Not Synced
So maintaining that is kind of a drag
when upstream makes big changes:
-
Not Synced
then all of sudden you have got this set
of patches and they do not quite apply…
-
Not Synced
I is a drag even you do not have it in
the 'debian/patches/' directory.
-
Not Synced
But what Debian 'patch q' does is it maps
that directory of patches into a little
-
Not Synced
branch on your Git revision history.
-
Not Synced
So when you get a new upstream version,
you can say 'patch q rebase',
-
Not Synced
and it treats it just as Git: it takes the
'patch q'…
-
Not Synced
You have already imported the new version,
and it re-applies your patches,
-
Not Synced
and sometimes that means some minor
adjustments.
-
Not Synced
Git is really good at figuring out what
the right minor adjustments are to make,
-
Not Synced
and so all of the sudden the 'patch q' is
re-based, you refresh it in your revision
-
Not Synced
control system, and there you go.
-
Not Synced
So I like to use 'git-buildpackage' 'patch q',
tagging, as already brought up,
-
Not Synced
thank you for that, I like to to tag
everything that I release,
-
Not Synced
I like to push that as soon as I can,
so that other people who are following
-
Not Synced
my work can now where my releases
come from.
-
Not Synced
The reason that I like other people
following my work is
-
Not Synced
they can fix my bugs easier.
-
Not Synced
I make mistakes, everybody makes mistakes,
and it is really important to me that
-
Not Synced
if someone catches one of my mistakes,
I can accept their feedback,
-
Not Synced
their criticism, their improvements,
as easily as possible.
-
Not Synced
I want a low barrier to entry for people
to help me fix my problems,
-
Not Synced
it is selfishness. So I try to patch it
and publish this things for people
-
Not Synced
can find it.
-
Not Synced
I am ??? on these pretty fast because
were are almost at the time.
-
Not Synced
I like to put in some place where other
people get to the them,
-
Not Synced
at the moment I like to put them in
'collab-maint',
-
Not Synced
it has some problems but it is better
than not publishing your stuff,
-
Not Synced
and it is nice because it is sort of
a public use.
-
Not Synced
I like to standardize how of my branches
are named, so if I am working on
-
Not Synced
something that has got a stable version,
that is for Jessie, I will name the branch
-
Not Synced
'jessie', because I ???
-
Not Synced
???? multiple branches ???
-
Not Synced
I try to push as frequently as I have made
something that looks sensible.
-
Not Synced
I do not feel obliged to push my commits
to a public repository when I am still
-
Not Synced
experimenting, I actually really like to
experiment, and I also like to keep track
-
Not Synced
of my experiments while I am doing them.
-
Not Synced
So I try to push when there is a sensible
set of changes, and I am trying to get
-
Not Synced
myself to a point where I can understand
what I have done, even if it wrong.
-
Not Synced
If I can get myself to a conceptual point
where it is done, I will push my changes
-
Not Synced
so other people can see what I am
working on, and then work from there.
-
Not Synced
That is OK to push something that is
wrong,
-
Not Synced
as long as you push something that
people can understand.
-
Not Synced
When you make a 'git commit' (if you are
working with Git),
-
Not Synced
One of the things that helps me to think
about commit messages…
-
Not Synced
People often think that commit messages
should say "what change you made".
-
Not Synced
I think that the 'git patch' shows what
change what change you have made,
-
Not Synced
and I thin your commit messages should
say "why you made the change".
-
Not Synced
That is what people really want to read.
-
Not Synced
If you need to explain technically why
the thing that you did
-
Not Synced
maps to the conceptual thing that you
wanted to do, that is fine:
-
Not Synced
do that in your commit message too.
But it is really important to say why
-
Not Synced
you made the change. It is not just like
"initialize variable to 'no'":
-
Not Synced
OK, we can see that from the patch,
but you what you are really saying
-
Not Synced
is "there was a crash if someone did 'x',
-
Not Synced
and we are avoiding that crash by
setting this to 'no'.
-
Not Synced
So I like to send patches via email,
-
Not Synced
so I try to configure Git email, which
make it really easy to just
-
Not Synced
push patches back upstream.
-
Not Synced
If I am starting taking over a project
that somebody else has past on,
-
Not Synced
and they did not use Git, I will try to
restore all of the imports.
-
Not Synced
I would be happy to talk with people
about how to do that,
-
Not Synced
if you have questions come find me.
-
Not Synced
I like to keep my files ???? simple:
there is a tool 'wrap-and-sort',
-
Not Synced
that just canonicalizes your files to
make them look in a simple and
-
Not Synced
sensible way. And it is nice because it
means that everything is…
-
Not Synced
It does things like alphabetize your
list of build depends,
-
Not Synced
and brake them out one per line.
The nice thing about that,
-
Not Synced
since you are using revision control,
when you make a change
-
Not Synced
to your build depends, the changes
become very easy to see:
-
Not Synced
"oh, they added one new package here,
there is a single '+'".
-
Not Synced
When ???? so you can see that kind of
thing.
-
Not Synced
I like to use ? deb five ? to format
Debian copyright to be machine readable,
-
Not Synced
it is nice for people who are doing scans
of the archive and try reason about
-
Not Synced
what the patterns are, and licensing of
free software.
-
Not Synced
And if I am doing something really crazy,
that is going to make a big change,
-
Not Synced
I like to use a feature branch in
revision control.
-
Not Synced
So we have got one minute left,
I want to open it up for other questions.
-
Not Synced
????
-
Not Synced
[attendee] You said you are using
'wrap-and-sort' which is nice,
-
Not Synced
I had learned that ???? editors
- 'cme' - do the same job,
-
Not Synced
and somehow does a better job:
it also ??? standard version
-
Not Synced
if it does not fit, or it makes VCS
fields properly has it should be.
-
Not Synced
'cme fix dpkg-control' fixes your
control file.
-
Not Synced
[Daniel] 'cme' ? And it is in
what package ?
-
Not Synced
[attendee] The package 'cme', in
unstable ????. In Jessie it is ????
-
Not Synced
[Daniel] You are developing in unstable,
that is OK.
-
Not Synced
'cme'
OK, thank you.
-
Not Synced
Other questions or suggestions,
or complains ?
-
Not Synced
[attendee] If you change the original
source code, and do some commits,
-
Not Synced
how do you convert that into a series
of ??? patches ?
-
Not Synced
[Daniel] I use 'patch q' for that as well,
so what I do is I say
-
Not Synced
"I want to move over to my 'patch q'
view of the tree",
-
Not Synced
and then I make may changes, I make
my commits,
-
Not Synced
and then I say
'gbp pq export',
-
Not Synced
and it takes the 'patch q' that I am on
and dumps it back
-
Not Synced
into the Debian patches directory.
-
Not Synced
If you have not use 'gbp pq', I
recommend looking into it.
-
Not Synced
It takes a little while to get used to,
and I still screwed it up sometimes,
-
Not Synced
but it makes easy to fix your
mistakes too.
-
Not Synced
[organizer] Last question ?
-
Not Synced
[attendee] Do you think it is possible to
make this 'patch q' branch
-
Not Synced
"pullable" by upstream ?
-
Not Synced
[Daniel] I do not actually think it is
possible to make it directly
-
Not Synced
"pullable" by upstream: I think upstream
can cherry pick patches from it,
-
Not Synced
but I do not see how to
make it "pullable".
-
Not Synced
If someone else does, I would be
happy to learn.
-
Not Synced
[organizer] This was "before last",
so last.
-
Not Synced
[attendee] Do you have a recording of
you using the tools that you mentioned,
-
Not Synced
a video recording would be great,
just to show your workflow ?
-
Not Synced
[Daniel] I do not really know how
to do that: if somebody wants to
-
Not Synced
help me do that I would be
happy to do it.
-
Not Synced
I am going to give one last plug,
-
Not Synced
I know we are out of time here,
sorry.
-
Not Synced
This tool is called 'gitk'.
-
Not Synced
This is an example - sorry we
should leave - but this the way
-
Not Synced
that I visualize my revision
control system.
-
Not Synced
We could do a whole other session
about 'gitk'.
-
Not Synced
If you do not try to visualize your
revision control system,
-
Not Synced
you are missing out: try to find a way
to visualize stuff,
-
Not Synced
find one that works for you.
-
Not Synced
Thanks for coming.
-
Not Synced
[organizer] Thank you.