Hi, On Thu, Aug 21, 2014 at 5:51 AM, Thorsten Stettin <thorsten.stettin@xxxxxxxxx> wrote: > Do that and all things will done. > > EXTRA_DIST = \ > AUTHORS \ > COPYING \ > ChangeLog \ > ChangeLog.pre-1-0 \ > ChangeLog.pre-1-2 \ > ChangeLog.pre-2-0 \ > ChangeLog.pre-2-2 \ > ChangeLog.pre-2-4 \ > ChangeLog.pre-2-6 \ > ChangeLog.pre-git \ > HACKING \ > INSTALL \ > LICENSE \ > NEWS \ > NEWS.pre-2-0 \ > NEWS.pre-2-2 \ > NEWS.pre-2-4 \ > NEWS.pre-2-6 \ > README \ > README.i18n \ > authors.dtd \ > authors.xml \ > authors.xsl \ > config.h.win32 \ > gimp-zip.in \ > /usr/share/gtk-doc/data/gtk-doc.make > Wait what? You *never* write down an absolute path for a file of a third party package in a Makefile.am. This is like never, never. What if this file is somewhere else on another machine? In any case, I just tested again a `make dist`, and it works fine already. I'm even sure it did work fine before Mitch's recent commit too, because that's what a distcheck tests for (it will compile again from the uncompressed dist tarball, then make a new tarball from it, ensuring the dist is self-contained. Cf. automake doc. So if it weren't fine, `make distcheck`, which is run all the time on our continuous integration machine, would have failed a long time ago). gtk-doc make is automatically created by the command `gtkdocize`, which is run by ./autogen.sh. If you created your ./configure script with ./autogen.sh — which we should assume you did — then you will see gtk-doc.make in your root directory. At this time, this will be a symbolic link to the system gtk-doc-make, which happens to be /usr/share/gtk-doc/data/gtk-doc.make in many default installations, but which could be anything else, for instance if the user installed gtk-doc-tools oneself, or with a specific distribution tree (and that would still be a completely valid gtk-doc.make, thus you must *never* write down abolute path yourself!), and which will become a normal file when copied into the tarball. > This is the Makefile.am in the root of GIMP's - yes, it comes from Git - > source tree. > I changed my Ubuntu/Debian rules file, so I don't need no patch anymore > regarding this issue, I hope. But please ensure > /usr/share/gtk-doc/data/gtk-doc. must exist at build time, if you, e.g. > change the Holy Grail, aka Makefile.am, pay attention, :-D > > Regards > > Thorsten > > PS: Please, don't get me wrong: > https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge/+packages. > Reading educates. O:-) I don't understand why you keep linking your launchpad page. There is nothing there, except for binaries (.deb, tarballs, etc.), and some diff or build logs here and there. We want your *procedure*, the exact commands you run to make your package. Something readable. If there is something like this in this page, please could you give us the direct link, so that we get directly to it? Because I could not find it. In any case, I checked the bug report from the Debian project you linked earlier: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686941 Well it turns out this is a bug in Debian packaging, which happens with any projects using gtk-doc. You should copy the whole relevant part when you make quotes: « With the source tree, the problem is that `gtk-doc.make` gets deleted during `debian/rules clean`. This concerns all gtk-doc using packages using (dh-)autoreconf. As a work around manually copying `/usr/share/gtk-doc/data/gtk-doc.make` should do the trick. » So basically there is a Debian rules which cleans out some files (why?! Whatever is in a dist tarball is deemed to be needed. Proof is with this gtk-doc.make issue). And there is *absolutely nothing* we can do about it (and no, using an absolute path is completely broken, wrong and would bite us back anyway!): the file was there, the Debian rule simply sweep in in-between and removes it. And then you have to add it back manually. So you should continue to patch your package, or better patch upstream the Debian tools (the ones which make .deb packages and such clean rule), because that's what is bugged. GIMP has a lot of bug, but on this particular matter, it is fine. Have fun, Jehan > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
