I'd add that the recommended thing to do if you're trying to create a package for software you own is to blatantly wear two hats: with one hat you're the upstream author, and with the other hat you're the packager. Have two different repositories, don't add the debian/ directory to the upstream distribution, when you find an upstream bug fix it there and make a release and *then* import the new release into the Debian repository and make a new package, etc. The workflow works much better like that.
In your specific case, this will avoid the git weirdness because you'd be only using the public dist files on import. On Sat, 11 Jan 2020 at 13:17, David Griffith <d...@661.org> wrote: > > My reply is at the bottom. Please put your reply there too. > On Sat, 11 Jan 2020, Thomas Dettbarn wrote: > >> David Griffith <d...@661.org> hat am 11. Januar 2020 um 05:57 > geschrieben: > >> > >> I'm trying to debianize Frotz 2.50 and put the debian/ directory into > the > >> git repository. A complication is that the contents of a dist file > >> differs from what you get from a git clone. This is what I get from > >> dpkg-source -b ./ > >> > >> dpkg-source: info: using options from frotz-git/debian/source/options: > --tar-ignore=public > >> dpkg-source: info: using source format '3.0 (quilt)' > >> dpkg-source: info: building frotz using existing > ./frotz_2.50.orig.tar.gz > >> dpkg-source: info: using patch list from debian/patches/series > >> dpkg-source: info: local changes detected, the modified files are: > >> frotz-git/.gitlab-ci.yml > >> frotz-git/Makefile > >> frotz-git/public/index.html > >> frotz-git/src/dos/bchash.h > >> dpkg-source: info: you can integrate the local changes with dpkg-source > --commit > >> dpkg-source: error: aborting due to unexpected upstream changes, see > >> /tmp/frotz_2.50-1.1.diff.B02OBO > >> > >> My problems: > >> 1) .gitlab-ci.yml handles the Frotz webpage > >> https://davidgriffith.gitlab.io/frotz/, which lives in public/. By > way of > >> .gitattributes, that's automatically stripped out of the tarball when > >> making a distribution source tarball. It should be ignored by > >> dpkg-source too. > >> > >> 2) I can't seem to make dpkg-source ignore public/. I put 'tar-ignore > = > >> "public"' into debian/source/options and it doesn't seem to work because > >> dpkg-source is still complaining about public/index.html. > >> > >> 3) When a dist tarball is made, hash and date information is put into > >> Makefile and dos/bchash.h by way of export substitutions in > >> .gitattributes. The object of this is to embed commit hashes and build > >> times into the executable. How do I tell the debianization process that > >> these changes are okay? I'd rather not have to do "made dist", open up > >> the resulting tarball, and debianize there. > >> > >> 4) I would also like the debianization process to ignore src/dos/ as > well > >> because that contains MS-DOS specific code. > >> > >> My working code for this is in the debian branch at > >> https://gitlab.com/DavidGriffith/frotz > > > The way into debian is a complicated one. There are a LOT of > > helper scripts out there, which have grown. Some of them are > > still useful, some are not. > > On top of that, the contents of the debian/ directory are > > plentiful, and not very well documented, if I may say so. > > > > My solution was to create a new repository (ports and packages) > > outside of my project, and put the debian/ directory in > > it. And edited the contents by hand. > > > > I also added a shell script mkpackage.sh, and only used three > > tools: debuild, debsign and dput. Within this script, I am > > also creating the orig.tar.gz, to make sure that it only > > contains files that I want it to contain. > > > > If you would like to have a look, you can clone it from here: > > github.com/dettus/ports_and_packages > > maybe it helps. > > I think I understand most of the debianization process as far as it > applies to packing up Frotz. My main concerns are why I continue to have > trouble with the public/ directory, how I'm supposed to make it ignore > src/dos, and what I'm supposed to do to make it not complain about > .gitlab-ci.ylm and Makefile. > > > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > -- ┌─── http://www.cowlark.com ─── │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup
