 So Welcome everyone So this is the get build package skill share and I'm hoping to take some notes here I'm here basically as a facilitator. I don't actually plan So So Maybe just to get a sense of the room initially so we all know who we're talking to so who here is currently maintaining a devian package Okay, and who here is thinking that they might want to maintain a devian package in the future, but it's not currently maintaining one now All right, cool, awesome I'm really glad to have folks who are Starting packaging wanting to think about these kind of workflows not just people who are already And so of the people who are here packaging how many people here currently use get build package But that's not everyone who currently packages so So it's great that people are thinking about this. So if people have other Packaging schemes that use revision control That they're currently using and you're thinking about switching to get build package or you're just here to troll us Because your system is better. That's great And I want to hear what works for you and other systems and if there are workflows that you know Don't point out Analogies of things that work maybe without get build package or with other tools That we can that we can share and maybe try to build a bit in a sense of what goes on. So Can you remind me how many minutes this session is sorry Oh It's a 45 minute session. Hi, okay. Do I hear 30? So So I wonder if somebody wants to take a crack at explaining To people in the room who maybe don't yet use get build package Just briefly if you could try to do it in two sentences What guilt what get build package means to you as a packager like what is it? What does it do for you as a maintainer like what's the thing that? Pick a highlight a short highlight. Anybody want to volunteer to do that? I'm gonna use currently using get build package What do they do for you? It ties tags together with either S build or Okay, so you've got an S build cow builder integration By the way, this is a this is a pad. I don't know if you can see this URL up here I don't know how to in big in this part of my screen But it's DC 15 pad dot rise up net slash p slash d Yeah I Anyway, so hopefully folks have seen that So sorry you said I welcome other people to Co-note take because I'm gonna miss them. You said cow builder and S builder integration with get tags, right? Yes, the main value for me is that it allows me to not have to keep track of Files on my own that way I can point tags or point of tags for upstream Okay, so you okay So somebody else it takes care that I don't build packages with uncommitted changes So take the one thing For example, but can't happen unless I want to text specifically Okay, great It also Can generate your original turbos if you're generating for a snapshot of repository includes the understandable Trees within your version and just generate for you It cares about the pristine tar handling for me. It cares about wanting you spin for me It does so does somebody want to explain pristine tar for people who don't know what Well Pristina saves a minimal Set of data so that with the content of the git repository plus the delta you can beat wise we would use Tarball Okay, so Debbie it right and the reason that we care about that is because Debian our whole infrastructure is sort of framed around Tarball upstream tar balls whether that's actually how upstream distribute source code or not That's the way we think of upstream source code is terrible. And so pristine tar says we got this tarball from somewhere And here's how to get exactly back to it and it's all started So somebody says you scan integration just you want to explain how do you do user scan integration? import oik the sub command as a Option dash dash you scan Great so you scan looks at the Debian watch file and looks for new versions of the upstream source code via HTTPS or FTP or whatever And so GBP so so so just some basics for folks who haven't maybe looked at get bill package before right the way you invoke it These days is you say instead of using Do you use GBP for that's get bill package and then you have a sub command this is very similar to get right where you have a Command and you have a sub command and so there's GBP import a ridge that says get an upstream tarball and bring it into the repository and put it in the repository in like to get build package way and then this is saying oh Well, we've got this other option that does it automatically it goes out and fetches it from the network and then also does the thing for the ridge So some other things that GBP can do besides import a ridge art is build package is the other big one So you'd say GBP build package and it does some of the checks The people were talking about to make sure that no additional files got mixed in No additional changes that you weren't expecting to get mixed in got mixed in that requires of course that you when you're using get to do Your packaging you're paying attention to what you're committed But if you just blindly go ahead and commit everything I think to mention the third important alright, this is the longest one sentence I've ever heard Well, there is also import a DSC Which imports complete? Damian source package. So for example if you Take over a package from someone else who hasn't used get before for packaging you can import his source package and start for example Your packaging with it can also import multiple with import DSC and That one has a nice option to use snapshot to be an org Dash-dash depth snap I think and you get push at the package name And it pulls the whole history available for that package into your freshly to be created Get repository for packaging. I like that a lot if I have to take over some legacy package Okay, this is exactly why I wanted to have this picture. I had no idea Oh Very cool, they call it RTFM So So maybe that was only news to me and everybody else already This whole session is a teach DKG You want to sum up what you know how get build package works for them what what things it does We do want to step into some some workflows, or maybe look at a get build package repository Before what clothes maybe some problems we counter during your day-to-day work place for the peach picking we Every now and then I have a problem with the import of the upstream Because it goes crazy So what what is the problem specifically you import an upstream to our ball Fitness program for me It just gives you a problem and version conflict and he doesn't want to apply all the changes Maybe it's something we do wrong I'm embarrassed to say this. I don't know who's on the team. It's maintaining get build package. Are they here? Thank you very much No, no, I don't but so if you have kind of weird history That's a new thing like on which is merge mode replace Which basically doesn't care about history and just dumps the whole Upstream tree on the ESVM branch by will be keeping the devian here, so you can't have any Finally solved by the option export Because wc because if you don't have this option in your Config file, then it's always built from the last commit if you say minus minus ignore you I said I wanted to test what I changed before I commit And but this ignore you means it took the last commit and ignored what I did And if you don't have this option then So a long time to learn this so this only happens if you export into a separate directory before this Yeah, don't you know what it just takes what is the directory in the export you have to tell it It behaves totally wrong to me and now this is option it is right so but can you does not marriage why don't you commit? This is like a this is a workflow question So and it actually I think I've heard an equal number of voices shouting just commit or I'm like, no For a shoot they ask Someone want to politely say why they feel One side makes more sense to me. I would have a question before that So why would you export your source tree before building if you use people there or something like that? Oh, I mean I'm sure this clean Some some little change and sense the control file and I'll say ignore you Nothing else Yeah, I know if you export everything before that but people will export it again Yeah, okay, so I'm not saying that there's no valid reason to export it before the final build for example But when I just want to test something I don't want to take the time to export the source Tree to that pbuilder built a table from it to unpack it in a change boot again and have all the bills So I just don't export before you find those So so what I'm what I'm realizing now that I wish I had prepared to do this would be To to try to package canoe hello on the screen with everybody telling me what I should be doing I mean maybe we can take it Maybe we can take another time to do that But I do want to get to the question of workflow because there are people here who have probably never used it They'll package and I'd like to explain to those people like what it normally looks like and that I'm sorry But I'd like maybe could somebody actually describe Roughly briefly the steps you would take for the process of taking a new upstream package It's not ever been in Debbie and before and bringing it into a get bill package Workflow someone want to try to take a crack at that To explain to people who have never who have maybe never used to get bill packet before I think we can take as a baseline the idea that people are comfortable with the idea of get And I apologize if there are people in the room for who are who are not comfortable with the idea of get But I think that might need to be a baseline for us to have a productive discussion Is that Okay. Yeah, so what I usually do is I create a new I think I create a new git repository and then I just give gbp in Pochery Pull the table Then if you think you will do two things you create an upstream range for me Which the contents of the table it will detect The version number from the file name assuming the file names It's reasonably named and then it will create a tag of stream slash number points into that point And then you use whatever you want to create a devian directory So when I'm doing a Ruby package, it just called DH make Ruby dot that creates devian for me and then I commit that and then Assuming the packaging never did it seem right I can give right from there And then I from there I start Sorry, so the you end up the master branch So usually you want the upstream source in the upstream range We should know that indirectly and then you merge that into the master branch with the And then we have a new upstream version you call gbp in Pochery again update the upstream range With that new version and then you measure that back into the devian directory Then you bump your change log So the result is a sort of ladder of you have an upstream you have a set of you have an upstream branch That includes all of the upstream tar balls eventually once you have new versions and then you have another branch That's the devian brand the master branch that merges in from upstream that tracks all of your devian work All right, so it's this sort of ladder Get history when I say a ladder. I'm thinking about it in this Sorry, I feel like I'm going to expose something horrible here So there's a there's a little bit of a ladder. It's kind of it's a little messier, maybe But so here's here's this upstream Sorry, these aren't totally sink. This is that this is get K if you're using get and you don't have a Graphical some sort of viewer visualizer of the repository. I think you're missing out So I want to encourage you to do that. I use get K for mine But other you want other ones that are also nice and good You can also have some text for the ones So the idea is that you've got this upstream Development that's going on and then you have a dead you have devian development I'm sorry the ladder is not very nicely visible here because it goes it scrolls down It weighs But so so up the new upstream versions are being pulled in and These things are being developed in parallel One of the things that I've also done that I've taken into habit of doing is using the dash dash upstream dash VCS dash Tag option to import a ridge So So that would be here right GBP import a ridge you'd say dash dash upstream dash VCS dash tag And now it has the an option you can put that into your your Configuration as well and what that does is it links the upstream import to the upstream revision control history as well so So if we look over here This is the import of the upstream version, and it actually has two children Sorry, it's that it has two parents think about the children with the parents the other direction right one of the parents is the previous upstream and then the other parent is the actual upstream revision control system so you can actually get one revision control system that has both upstream commits upstream tar balls Devian packaging and you can have the devian packaging on multiple branches clarification Example talking about importing a simple table, and you're talking about starting from an existing Version control repository those are two slightly different things. They are slightly different things So I was saying this is an additional thing that you can do is you can have the upstream tar ball and the upstream repository revision control system as well The ladder diagram that I was describing also implies an additional complication Which is you have a new version right so you're pulling in a new package a new version of the old package And it's it's growing one side of that ladder the upstream side of the So right so so yeah, there's a bunch of different pieces that can be pulled in together So I mentioned the config file there's this devian slash GBP calm This is a place if there are regular Flags and options that you use for get build package you can drop this file in your devian directory And every time you use GBP within that within that project. It'll use those parameters So you can look you can find the example an example file for this in Etsy Get-build package slash GBP calm You can just copy it in and strip it down and minimize it to be what you want to be for regular flags So I recommend the use of that. I find this Yes Just copying it over from existing repositories You actually can store a GBP.com in your dot-kit Directory and then you have configurations just for your local repository Okay, so what are the trade-offs between story in your got that get directory and storing it here? What when should you do one or the other? Well, I think everything related to one branch should be stored in the pit history on that branch so that's this and Some other stuff Signed with your peak which is basically Specific for your machine should we go into the top case Well, or let's say you are in protein repository from SVM you are working in a team right there using SVM You use modern things right so you just give you get build package That's why you want to say it's to use overlay for these one Put into dot-kit gbp.com that it's overlaid with and then it doesn't go to SVM and you still use get build package to build it That's not a use case Other nuances people want to add we've covered a bunch of things much more complicated than my initial question Sorry for that kind of I could get back to this no commit the issue Which I've tried to correct on the phone, but it didn't collaborate Sorry, they know commit like you I recommended to commit always before you build the package, right? and Why don't you want to commit because you might want to change it, but there is give commit a man Right, so you could always later on a man or reset card even to before so you always have opportunities to go back That's how it's different from those with the rings, right? That's more complicated just for one so it's one change you want to kind of polish out Right you start with the change commit right then you build immediately and it's all in your batch history So you just build it. Oh, it didn't work out. So you Change you get commit a man and you also keep them in your batch history So control R a man. It's all there You could kind of interactively go through this single commit over and over and over again until you're done If you want to reconstruct that history of your changes, you could even do that That's why it is cool because it keeps it in your ref log You could run a deep ref log and then you have like bunch of commits which have all the same commit message But they are all your interactive kind of you know trying to get there over and over and over again You could look at those changes No ignore new Just if you don't want actually to use those changes, right? They ignore them still want to build from what is committed. Maybe I'm working on just one file, and they have 10 of them change Well the issue that people have Not on there I guess if I have been there is that When you commit it sort of finished and you have quite a nice commit message and if you are Interrupted because somewhere else when you come back, you think it's done You did not remember it's it was not tested yet. So that's why people are reluctant to commit it so an intermediate resolution is to use a sort of fake commit message starting with WIP walking progress so that you don't forget that this commit is not really finished But you have to commit dash dash and then at least to drop the WIP I could flip the coin when I come to the repository to see some uncommitted changes. I forgot what the college was for With the commute message, I know that I think normally you put the commit message and the WIP and then just remove WIP when you're finished Here we go But this is this is the model where I called git as cognitive prosthesis This is that you're offloading the stuff because you can't remember it So if you can get it in the in the history Start the packaging you might need to do more than one change to get it building and in the process I Changes here and there Without committing them and once it is built I am cherry picking the changes and doing separate commits for the separate Changes get a final Bunch of commits that are actually building. So and I don't see a good way to use a good commit So as anybody been reading Joey has his blog he had a great blog post I think about a month ago talking about the difference between the git commit histories that we publish and our actual Our actual histories of what we do and he calls it what like the real histories are the messy histories The other ones are this like nice workflow And I don't know what the right answer is there, but I think it's worth Considering that maybe the right answer is just to go ahead and commit the messy history Right, it actually reflects the thought process that you went through even though it's not as clean The difference is that when someone comes back and looks at their positive They're going to see that you made some mistakes along the way So there's something to be said with the intellectual honesty of owning up to making mistakes along the way And at least you can track what you've done on the flip side if I come to a new repository And it's full of commits that are just egregious mistakes with no You know after the fact let me go ahead and describe what I was trying to do in a nice clean way It's harder for me to understand the history So I think there's a trade-off and a balance there But I don't think we should be afraid to publish a git commit that has an error in it But I don't know how I don't know how far you go It makes the exacting impossible Actually, so you don't kind of have tested for myths or something like that. You can't use it for anything same Unless the legacy commits or you know off on a separate pager branch and then you're by taking on the main branch But yeah, of course The other thing is I treat this I'm often trying to think about at least for my projects the most time I'm trying to think about Trying to make the person who comes along later hate me less when they're looking at the history because especially for some of the Stuff when I'm implementing or working on something that took me a lot of figure out like in a project where there's complicated algorithms or whatever I'll want to leave a lot of information there and try to make it really coherent what I did so that There's less work on their part when they come along later I'm not saying I would succeed If you allow me I would come back to the two problems with the git build package. I have two small problems I have a git archive where I have a master branch and a legacy branch and I work on the master branch and do my commits and convert them into quilt packages and patches and then I Generate my change lock with the with git build package and at some point I merge to the Legacy branch and then I always get a merge conflict on the change lock. That's one problem The legacy branch in an older option version as well. So it or is it it's the same version. It's a it's a back for it Can you write it down The second dash First change once yes That man page with Explanation how to configure it basically you have to It's not perfect, but it did with This case with the comment the comment Like when you met French words when you do cherry peaks Okay, and another problem which I encountered I think half a year ago, maybe it's already fixed upstream in the I made some changes in the back part branch and then I Wanted to generate the change lock and it didn't combine the feature branch and the legacy branch The met the commit messages in the log, but took only the messages from the master branch Okay Are you okay in general with people just opening bugs to say I did this workflow Repulatory to reproduce it's fine. Otherwise You showed the GPG history. So there's so many different kid histories that um, they are I'm sure lots of bugs in all these tools. Um, so um, you always need some good history to verify and to check against so does anybody else have a Particular workflow that they find get build package helps them do what they want to talk about Does anybody want to talk about a particular sub-option in my patch queue? I have a question about how many people are keeping their Debian repository in the same repo as upstreams and If you are how are you dealing with how are you using GBP to help you with the FSG problems? So I think there's there's there's three there's three kinds of ways One of them is that you just keep your Debian directory in git. I don't even keep any upstream data in git One of them is that you keep the upstream tar balls with your Debian directory in git And the third is that you're actually combining your revision histories with upstreams get I think you're asking about the third one. Yes, so it's not just about upstream tar balls It's about the third Yeah, because obviously repacking a tar ball fine, but it's everything is together Okay, so I assume that you need to put upstream into your own Debian Your own Debian Git repository to have to use Git build package. And it seems like it's not necessary Basically my question is do you need to have both upstream and your Debian directory in one repository to use git build package or you can just have Debian directory And you can use git build package I've never tried to do just the Debian directory Is that a sort of workflow you expect to work? So I'm not using it myself, but I People using it and I just use it today Okay, so it can work I mean, I imagine we can have a big fight here about whether No, it's answering this question Yeah, I can answer one of these three questions I have several Upstreams where the Debian packaging is part of the upstream repo Because I'm also part of the upstream team in some way and I must admit I don't use git build package there at all because Well, it's it's too entangled and there's not much Gain in using git build package there Well, yeah, so so I actually do In situations where I'm working with closely with upstream where I am upstream I do use git build package and in there There's one thing that I find a little bit awkward which is that in those situations my Debian packaging is on the Debian branch and my master branch is the actual development branch And so I have to sort of context switch depending on which project Whether the master branch means upstream or whether the master branch means Debian unstable And that's a little bit awkward for me I haven't just figured out how to do that But I actually do find it useful when I'm part of upstream to just continue to use the same repository I just have a separate branch that contains the Debian packaging Just a short question about what you said about how do you then build Packages from git snapshots from upstream You don't I think I don't, sorry The issue, I don't currently use git I use bazaar for historical reasons, but I'm not I'm not having a serious opinion about these things So I can switch to git But I also use bazaar build package That hasn't a feature called split equals true And it takes a normal repository with both upstream and the Debian directory in it And creates, you know, a dot or a dot tz file and splits it Split equals true? Yeah, those are build packages Want to have that feature in git build package or something like it before I can switch to git But I haven't found it and it's really hard to search When I have a build package, we learn git yet I don't think I understand what the feature does It says here To remove the non-screen bits No, no, no, no, no, no It says here this takes a package from barn That includes both the upstream source and the Debian there And creates a non-native package from it By creating that oric dot star dot tz From the code outside of the Debian directory This is probably most useful If you are both upstream and Debian maintainer of a non-native package Thanks There's one tool called git pkd Which does exactly that You can create a 3.0 code package by splitting the upstream part from the Debian directory Git pkd Is that ready? Pkd Ah, g Got it Without dashes Without space So no one has actually answered Harlan's question yet Thank you for providing that But no one's answered Harlan's question I need that glance What I did is that I keep three branches One for upstream One for an upstream that's good enough for Debian And then another one that's the Debian package So in that case not just one pre-compiled binary in the repository So the good enough for Debian, a three branch just has a commit that deletes the file And then I just keep merging the new upstreams And then it's mostly all right But you can't host that on Alia Because it's because the repository itself is on So no Is this a case? No, it's a binary You can All right, I can do it Binary in the source Well, so git is free Definition of the 2.0 package on the inside Is what we can go through to view out here What you can tell us does not really come And that's also part of the reason why 3.0 git packages were never allowed Because they have the history In the FTP master side, they really make the difference between this git Which is the way that we used to build and the source package that we used for So what I do usually is that Either I use useCAN with the 5.2.0 option So when it's downloaded the child git and it already has this 5.0 treat So my upstream branch is clean already So you can not even have a problem You only have it if you use the upstream VCS tag Because in that case you merge the upstream history with probably the 5.2.0 So that's the ice when you're going to be able to complete it When you do have the upstream history in your default story Yeah, I mean I've been doing that myself right now with files excluded But that trying to integrate the upstream's history into it I don't know how to like then I run into the problem So my repository even if my directory is not unique What I have with the Debian is not My repository is now tainted with non-free stuff But I have to be careful to make sure that that never ends up somewhere That doesn't allow non-free content at all I'm not sure that Aliov has that constraint Yeah, I'd like to know the answer to that question Because I might need to go make some arrangements I mean I have the emacs that he called And I don't actually use the build package Which is actually a question I'm not going to ask a bit of time But yeah, all the documentation is not Yeah, I probably have things uploaded that have RFCs in them That are on Aliov Yeah It's possible it's my misconception about Aliov It's a good question It's a valid question I used to be an Aliov salient I mean as there's no, I don't know any subtracted picture I mean you're free to maintain a non-free package on Aliov We do our work there And we do a block package that are non-free too I think the main point that there is If we can really subude that code Right if it's really not for sure Like what? Yeah The only problem I think is Because we said that when the distribution is not allowed When it's only does not meet the DEFG Then it's not allowed I had this problem My absolute was My absolute was This is a non-free example Someone pointed to this error And then actually deleted it from this Because the remote is still in history Non-free example is not a problem The problem is when you have a file that is not supposed to be distributed I don't know a sample that is copyrighted To claim or something like that For more or something Oh yeah That kind of stuff You're talking about master articles Something that is already preserved Unless we have no right to distribute it Exactly Yeah but in that case you can't talk about it anywhere Yeah so So actually we really should rewrite this story With deep pictograms So let's bring it back to get ill packaged As fast as we can as the people of Nice and yousauce There's no need for that So do folks have a I wanted to mention the GDP patch queue Because nobody else seems to have brought it up yet I know something that I've been using And I admit I still struggle with it a little bit But I found it really useful as a way of representing The Debian patches directory So the Debian patches directory in a 3.0 quilt package Is just a collection of diffs And then a file that says what were to apply them in And git gbpq says take the Debian You can take the Debian patch queue And treat it as a git branch Sorry So the git branch So then you can work within the git branch As though you're working directly on the modified package And then you can re-export that branch Back into the Debian patches directory And build the software from there And so the nice thing about that is that There's several nice things One is that the patches can then If you've got your upstream repository as well Your patches are easy to sort of cherry pick stuff From one to the other It also means that you can When a new upstream version comes in You can say rebase the patch queue And that updates all of your patches Using git smarts about how to update the patches And it just does that for you And it also means that when I'm working In modifying the package to try to make it Fix a particular Debian bug I'm working in my normal git workflow On that patch queue On the patch queue branch The point is that the patch queue branch lives You probably don't publish the patch queue branch But anybody who If you're working like this Anybody who checks out your git repository Can build a patch queue branch easily And work on it from there And then they can export it back So gbpq And it itself has subcommands Which are import, export, and rebase Are the three names that I use But if you haven't played with it You should try playing with it I think it's useful How is your branch layout? Is your patch queue branch Based on the upstream branch Or the Debian branch? The patch queue branch Sorry, we've got one minute left The patch queue branch is based on the Debian branch So when you're pulling stuff back and forth It's often a sort of cherry-ticking situation Not an urge We have one minute left There's obviously more that we can talk about And more ways that we can sort of share Workload in the future I don't know Do you have a preferred place to talk about GVP process or? You mean on the internet or here? Both Because we have one minute left here But we have a long time left on the internet No, that's amazing this actually So that's actually fine to use And that's the backtracking system Yeah, that's basically it Okay, there's the walk in the next hour Yeah, so and there's the walk in the next hour Which kind of the idea is like This one is about the workflows The other one would be like enhancement So if you have like other parts And get build package that Are not doing what you want Or you're using features Or kind of like limitations in your workflow If you want to resolve then just come there And maybe we can move some of the workflow parts there as well Because I think that will be part of it anyway So I think we're probably out of time So thanks everyone for coming And let's keep the conversation going And improving the package So we've got these tools to help us work together Easier I mean that's the big outcome of get build package for me Is that I find it makes it easier To work with other people And easier to keep track of what I've done And see what I've been doing So thank you for providing us with this