gitbuildpackage_skillshare.webm

welcome everyone
so this is the git-buildpackage skillshare BOF
and im hoping to take some notes here
im here basically as a facilitator
i dont plan to tell you exactly what you should do
what im hoping to do is to learn from everyone here
and we can all mutually get some practices ??
maybe to get a sense of the room initally
so we all know who we are talking to
who here is currently maintaining a debian package
ok, and who here is thinking he might want to maintain
a debian package in the future but is not currently
maintaining one now
alright, cool, awesome
i really glad to have folks who are starting packaging
one now and are starting thinking how this workflow goes
?? this people were just only packaging
so, of the peopl who are here packaging
how many people currently use git-buildpackage
but thats not everyone that currently packages
so its great that people are thinking about this
so if people have other packaging schemas that use version control
that they are currently using and that they are thinking of
??
or that are here just to troll us because your system is better
that is great and i want to hear what works for you and
other systems and workflows that
?? point out analogies of things that work without git-buildpackages
or other tools that we can share and ??
so ?? remain me... how many minutes this session is?
is it a 45 minutes session? do i hear 30?
I wonder if somebody want to take a crack at explaining
to people in the room who maybe dont yet use git-buildpackage
just briefly, if you could just try to do it in 2 sentences
what git-buildpackage means to you as a packager
what does it do for you as a maintainer
what is the thing that... pick a highlight, a short highlight
anyone want to volunteer to do that? someone that is currently using git-buildpackage
what does it do for you
- it ties tags together where either sbuilder or cowbuilder in a logical sense
- ok, so you have either sbuilder or cowbuilder integration with git-buildpackage
by the way, this is a path, i dont know if you can see this URL up here
i dont know how to embigger this part of my screen
but it is pad.riseup.net/p/ oh... there you go
anyway, hopefully folks have seen that and you can get it from ??
I welcome other people to take notes because im going to miss
so you use sbuilder or cowbuilder with git-tags integration, right?
yeah, the main value for me is that it utilize??
not to keep track of files on my own, right?
I can point tags for upstream for the package i want to build
ok, so somebody else?
- it takes care that i dont build packages with uncommited changes
so take the wrong thing, for example, that can happen
and that i wanted explicetly
- ok, great
- it builds ?? of your original tarballs if you are generating for snapshots
a repository includes the git understandable trees within your version
and it just generates ?? for you
- it cares about the pristine tar handeling for me, it cares about running uscan for me
- can you explain what pristine tar is people who dont know what it is?
- well, pristine tar saves a minimal set of data that
with the content of the git repository plus the delta, you can
reproduce bitwise orig tarball
- ok, and the reason we care about that is becauase
debian, their whole infrastructure is framed around upstream tarballs
whether thats how upstream distributes their code or not,
thats the way we think about upstream source code
so pristine tar says, we get this tarball from somewhere
and thats exactly how to get that ??
so how many use uscan integration?
do you want to expalin how you do uscan integration
- import-orig, the sub command, has this option --uscan
- yeah, its already there
so uscan looks at the debian's watch file and looks for new versions of the
upstream source code via https or http or whatever
??
so just for people that havent maybe look at gbp before
the way you invoke it these days, you use gbp, thats git build package
and then you have sub command, this is very similar to git
where you have a command and then a subcommand
so there is gbp import-orig that says get upstream tarball and bring it into the repository
and put it in the repository in the gbp way
and then we have this other option that says
it goes automatically and fetches from the network
and also does the import-orig
theres some other things that gbp can do besides import-orig
build packages is another big one, so you say gbp buildpackage
and it does some of the checks that people where talking about to make sure
no additional files get mixed in ?? or changes that you werent expecting and got mixed in
it requires of course than when you are using git for packaging, you are paying attention to
what you are commited, if you go ahead and blindnly commited everything ??
- I like to mention the third important
- alright, this is the longes phrase i have ever heard
- where you can also import-dsc which import a complete debian source package
for example, if you take a package from someone else who hasnt use git before for packaging
you can import his source package and ?? your packaging with it
you can also import multiple with dscs and that one has a nice option to your snapsshot.d.o
--debsnap and you get push the package name and it pushes the whole history of that package
in your fresh to be created repository for packigng
if i have to take over some legacy package
- ok, this is exactly why i wanted to take this discussion
I had no idea ?? which is great
- they call it RTFM, right?
- so maybe that was only new to me and everybody already knew it
this whole sessions is teach dkg sesion. Anything else you want to teach me?
Anybody want to sum up how gbp works for them, what things does
Do you want to step in some workflows that maybe look at gbp