Re: Private Debian package: Quilt | git | add files to package
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" 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//apache.conf.example >> >> Here I do not get... What Makefile? > > > Something like: > > all: > > install: > mkdir -p > [...] > cp -r webfiles/* $(DESTDIR)/usr/share/webfiles > [...] > > 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 >
Re: Private Debian package: Quilt | git | add files to package
On Tue, May 10, 2016 at 01:22:53PM +0200, Denny Fuchs wrote: > > 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. This is wrong as (for non-native packages) you always have the orig tarball which is created from the upstream branch (from the specified tag, actually) and not changed by commits in the master one. If you really want to edit upstream files you need to commit that into the upstream branch and move the tag (or make a new one). This may sound too complicated but that's because you are not packaging some software released by other people, which is the workflow Debian tools were made for. If you are releasing the software to the public your only options are to make a new release each time or to chanmge upstream files using patches. > > 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. Yes, and you need to think as both roles separately. -- WBR, wRAR
Re: Private Debian package: Quilt | git | add files to package
hi Giulio, 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. 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. 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//apache.conf.example Here I do not get... What Makefile? Something like: all: install: mkdir -p [...] cp -r webfiles/* $(DESTDIR)/usr/share/webfiles [...] 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
Re: Private Debian package: Quilt | git | add files to package
Hi Denny, (I am resending because I forgot to add mentors in the reply) Il 10/mag/2016 10:02, "Denny Fuchs" mailto:linuxm...@4lin.net>> ha scritto: > I trying to create a own private Debian package which mostly worked [...] > until I wanted to add a file (an example Apache configuration). Now it fails > ... and I don't get it in the right way. > dpkg-source: info: local changes detected, the modified files are: > sandbox_simulators/apache.conf > dpkg-source: error: aborting due to unexpected upstream changes, see > /tmp/sandbox-simulators_1.0-4.diff.NYXrUc 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. 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). > 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. > 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//apache.conf.example Here I do not get... What Makefile? Anyway I think you may have a look at dh_install and dh_installdocs. You can just add the file somewhere in the debian directory and add .install and .docs to install them in the proper location. > My last Howto: http://www.lpenz.org/articles/debgit/ > Any suggestions are welcome :-) I just had a quick look at it. The prerequisites you listed are not needed for the tutorial. And their descriptions can be improved and made more general. The tutorial is mixing at least two roles: upstream developer and debian packager. These roles have different goals and operates in different ways. So, I suggest to make it clear in the tutorial, and 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 package the tarball. When upstream will release new tarballs, you will package them. Your goal is to simplify system administration. Please add relevant documentation from Debian. At least the debian policy and, as you are targeting upstream developers: https://wiki.debian.org/UpstreamGuide Regarding this last document, please, read it and try to review your tutorial according to it. I think small practical examples are useful, as long as they do not conflict with reference guidelines. Cheers, Giulio signature.asc Description: OpenPGP digital signature
