Hi Denny, I think most of the confusion comes from the two roles that you are trying to have. I think it would be easier to try to gain some experience in the Debian packager role, before trying to mix them. Well, this is how it works with me. :-)
Anyway... Il 10/mag/2016 13:23, "Denny Fuchs" <linuxm...@4lin.net> ha scritto: > Am 10.05.2016 11:15, schrieb Giulio Paci: > > [...] > >> No changes are allowed to files outside the debian/ directory. So it >> seems that you changed and commited sandbox_simulators/apache.conf, >> making it different with respect to what you have in the tarball file. > > > that is the point, where I get lost. I have no tarball, because, everything is committed via Git. > So git-buildpackage creates its own tarball, and I expected, that the newly added file is simply there (it is) and also in the new (on the fly) created tarball. But the process complains ... that there is no patch. Reading your tutorial, at some point you create a tarball (make dist) and you import it to git (gbp import-orig). From that point, you have a tarball and you should stop changing any file outside the debian directory. Unless a new tarball is available and you are going to import it using gbp import-orig. > I'm relative sure, if I drop the git repo and create a brand new one, also included with the apache.conf, it works again. > So, there is some fundamental error, I have done, or git-buildpackage. I often wear the two hats of upstream and packager. The approach that works best for me is having one separate branch (or more) for Debian packaging and one for the pristine-tar, on top of my upstream development setup. As upstream developer I continue to develop as usual. As a packager, from time to time (usually decided on development or deployment needs) I create tarballs, import them and merge in the debian branch, and start doing packaging work on that branch. I personally do not have a straregy for "continuos packaging" (i.e., a system that creates a Debian package from the development git branch), although it is possible to setup CI on both development and packaging branches. So I cannot give you hints about it. In practice your goal is to create a Debian package with every push on the development branch, right? If yes, I have no experience with that. >> In practice, before building the package, with all patches removed, >> you have to grant that all the files outside of the debian directory >> are exactly as they are in the tarball (with a few exceptions, like >> .gitignore file). > > > See above :-) > > >>> I red (somewhere), that a Git commit (the new file for example) has >> >> to be added via a (quilt) patch >> >> I never tried, but, as soon as quilt pop -a, makes the changes outside >> the debian directory go away, it should work. I suggest to avoid >> commit files outside the debian directory anyway. > > > jupp, right, but you can cleanup the whole directory or remove and do a git clone .... and try again. It breaks on the newly added file. > > > >>> In the Makefile (also a quilt patch, to copy all files to the right >> >> place ...), I tried to copy the created apache.conf file to >> /usr/share/doc/<something>/apache.conf.example >> >> Here I do not get... What Makefile? > > > Something like: > > all: > > install: > mkdir -p <create some dirs> > [...] > cp -r webfiles/* $(DESTDIR)/usr/share/webfiles > [...] > <and so on and last> > cp apache.conf $(DESTDIR)/usr/share/doc/sandbox-emulators/apache-example.conf > > > [...] > > The Makefile is created via quilt (debian/patches/01_create_makefile.diff) and is easy enough for the most jobs. > > >> start thinking that, as a Debian package,r you are not going to >> develop the software itself: you have a tarball and you have to > > > In that case, I'm own both roles (if I understand you correct). I'm the maintainer and one of the upstream developer. > > >> package the tarball. When upstream will release new tarballs, you will >> package them. Your goal is to simplify system administration. > > > ( ... and make it working with Jenkins ;-) ..) > > thanks for the suggestions ... but for the git part ... I didn't understand it :-) > > cu denny >
