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