< Return to Video

Preferred_Debian_Packaging.webm

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

English subtitles

Revisions Compare revisions