--- Begin Message ---On Wed, May 11, 2005 at 09:45:20PM +0100, Roger Leigh wrote: > Floris Bruynooghe <fb102@soton.ac.uk> writes: > > > Plotutils was orphaned quite a while ago (#279827). In the packages I > > created all outstanding bugs are closed. Also the packages now use > > dpatch to keep a clean upstream tree. They are available at > > http://www.soton.ac.uk/~fb102/Debian. > > Your changelog has a spelling mistake ("postscrip"). More Thanks > importantly, it doesn't document all of your changes. We don't impose > penalties for more detailed descriptions, so feel free to be more > verbose. This is of great benefit to those who are not familiar with > the package. For example, you "use dpatch", but you could detail > exactly how you are using dpatch with a description of each patch. I have detailed all (?) my changes now (from looking at my diff), I haven't described every patch however. Is that really desirable? There is always the dpatch-list-patches command. It seems ok to write if you modify or add a patch, but seems a bit lengthy to describe the ~13 patches which where already in the old .diff.gz and are now split off. > What is debian/changelog.mine? You might want to take a more careful <snip> Thanks, this'll learn me not to prepare a package in between two lectures and decide it'll be fine. I'll take my time from now on. > - From my quick look at the diff, it looks like all of the autotools > stuff, and texinfo.tex and the info docs have been regenerated. This > was also in 4.2.1-12. If you didn't already, it might be a good idea > to regenerate them again with current tools to ensure they are > up-to-date. This also went wrong :(. I wanted to make a dpatch clean package, only files added to the debian/ tree in the diff. I'm having quite some trouble with that, my goal of a clean tree and outdated autotools (libtool) from upstream means I need to run the autotools at build time. The trouble I'm having now is that after the autotools have been run the files have changed and these changes will not be undone in the clean target. So if you build again without starting from a freshly unpacked source the diff grows (and the upstream tree is not clean anymore). I have googled on this but could not find anything. Now I have a script that moves all the auto-generated files to FILE.upstream before the autotools are run, and moves them back at clean time. It is not perfect however and sometimes the diff grows anyway. So I was wondering, there must be a "proper" way of handling this. I can't be the only one wanting to regenerate the autotools at build time and keep a clean upstream tree. Did I miss something obvious? > Have you coordinated this with the QA team? The latest upload was > just 4 days ago. It's worth asking the developer who did that upload, > if you haven't already. I noticed the QA upload a bit late so I did the duplicate work of fixing all the bugs. Guess I'd have to file the ITA bug earlier to avoid that but anyway. Why (and what) would I need to ask? The developer who did the upload did not file an ITA and is doubtlessly buzzy with other things. He only noticed, just like me, that the outstanding bugs where easy to fix and did so. Not that I want to appear rude or so, but I just don't see why that would be of needed. Regards Floris -- Debian GNU/Linux -- The power of freedom www.debian.org | www.gnu.org | www.kernel.org
--- End Message ---