I've never been able to get the watch file to work right, and it is mis-behaving like it always has. I think I've made all the other changes requested except I'm still a total loss as to how to migrate to the short debhelper format.
On Tue, Jan 3, 2017 at 7:28 AM, Tobias Frost <t...@debian.org> wrote: > > Very much appreciate the feedback. Willing to learn, but overwhelmed by > the > > Debian machinery. > > You're welcome! > > Yes, indeed it can be overwhelming. But don't worry, we've all had to learn > this ;-) > > > Stupid question at the top: If I dput another package, does it update > this > > one or do I need to delete the currently uploaded package from mentors > > first? > > You can just dput it. It will overwrite the previous version. > > > - d/changelog. A lot has changed. Here are pointers to 'brief' change > logs > > for 2.7, 2.9, and 2.10: > > > > http://www.tinymux.org/changes27.txt > > http://www.tinymux.org/changes29.txt > > http://www.tinymux.org/changes.txt > > > > That's four years of why to retrace, and the actual check-in messages > from > > the repository would be much longer. Does Debian really want all of that? > > No, the debian changelog is only for changes done to the (Debian) > packaging, > not to the upstream source. See the Debian Policy ยง4.4 > You ship already an upstream changelog (though it seems only to be limited > to > the last version and more a NEWS file than a real changelog...) > > > - d/patches > > > > - Not sure what a dep3 header is, yet. More to learn. > > http://dep.debian.net/deps/dep3/ > Hint: $ quilt header -e --dep3 > > > - All but one of the patches is checked-in upstream already. > > Ok. (Document that with the appropiate dep3-header "Applied-Upstream") > > > - I don't know how to have config.guess be updated at build time? Did > not > > know about that one. Is this part of automake? TinyMUX is more autoconf > > than it once was, but it still doesn't use automake or libtool. > > https://wiki.debian.org/Autoreconf > > NOTE: When you change to compat level 10 and short debhelper format it is > even > more easier, as compat level 10 default to use dh_autoreconf. > > > - Dependency-created-noise.patch. The way users normally build > TinyMUX is > > untar the package, ./configure;make depend;make. The 'make depend' scans > > all the include files and builds ".depend" which is then re-consumed by > > Makefile. It must exist -- at least empty. The Debian build system would > > see either way as a source change, but it isn't a change to taken > upstream. > > It always changes in different ways in every environment. > > Another reason to get rid of it to make it really portable ;-) But as said, > patching it is wrong, especially if it can be reconstructed during the > build. > > If it just needs to exists, why not > - remove it e.g via (the file) debian/clean > - after configure, touch it to be present > - in build run make > > > - d/copyright dep5...OK, more to study. The copyright is the same as > > previous 2.6 package except for the dates. That was hammered out between > > the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and RhostMUSH). I'm > > loath to change the substance of it, but if there is some Debian-friendly > > form to call out that it is the Artistic license, that seems reasonable > > enough. > > Well that happens when a package gets some care only after several years > (btw, THANK YOU for this caring!) Policies / Procedures have been updated, > so the "Machine-readable debian/copyright file" is now standard. > > > - silent rule. TinyMUX uses the other autoconf tools, but not libool or > > automake. Silent rule seems to be a term from those things? > > When I compiled the package I saw that the gcc command line executed was > not > echoed to the console. That needs change. Several Debian tools analyzes the > build logs to find certain problems. > > > - d/rules. I'm picking this up from the previous maintainer, Noltar, and > > there should be simpler ways of doing this now. I'm just not up to speed > on > > them and haven't found examples I grok, yet. I want to use the simple > > debhelper method. dh, done. > > man dh > (you probably need to override dh_auto_configure and dh_auto_build and > specify > the source directory (the manpage above explains it); other tweaks is > probably > to fix the install file instead of listing them in the install target. > Let me know when you're stuck, I'll help with hints > (my policy is to make you learn and also to use google and e.g > codesearch.debian.net ;-)) > > Another point which I missed this morning*: You should provide a watch > file. > Hint: https://wiki.debian.org/debian/watch#GitHub > > * I was quite time constrained -- I apologize in advance if I find other > points later :). But lets first tackle the above and then look for the > missing > pieces... > > -- > tobi > > > Stephen > > > > On Mon, Jan 2, 2017 at 11:41 PM, Tobias Frost <t...@debian.org> wrote: > > > >> control: tags -1 moreinfo > >> > >> Hallo Stephen, > >> > >> (not taking ownership of the bug as I cannot guarantee to find time for > >> follow ups. Other DDs are welcome to take this bug) > >> > >> Many thanks for your intention to adopt your pacakge. > >> I see that you're also upstream of it; this means that I can also > >> request to fix some upstream parts, like the build system ;-) > >> > >> here is a review: > >> > >> - d/changelog is incomplete. You've changed quite a bit in the debian > >> packaging, more than "new upstream reelase" ;-) > >> Please make sure that you really document everything you changed, > >> (and as this is often done wrong, the changelog should ensure that > >> it explains the "why (have it been changed)" adequately. > >> > >> - d/patches > >> - they could have use of a dep3 header > >> - as you're upstream, do you plan to roll out a new release with > >> them? (question out of curiosity, not required for sponsoring) > >> > >> autoconf patch: > >> - you should not patch config.guess. They need to be updated on > >> build-time! (autotools-dev is your friend, and debhelper with > >> compat level 10 will be even better.) > >> dependency-created-noise patch: > >> - I'm not sure about this patch. What is its purpose? > >> The header reads as it is for canceling changes due to the build > >> process? Looks like it is regenerated at build time? If so, it > >> should not be patched but mereley deleted in the clean target. > >> (Otherwise the build system should be fixed that this is not > >> needed; automake is capable to create dependencie) > >> > >> - d/copyright should be transferred to dep5 format. > >> > >> - Please disable silent rules (the buildlog should emit all compiler > >> flags) > >> > >> - d/rules should be converted to short debhelper format. > >> - the buildsystem should be really fixed to properly clean up. > >> - otherwise, errors from rm should not be ignored, also not errors > >> from make realclen. Just don't execute it when there is no Makefile. > >> > >> (Stopping here for time reasons; especially I did not do a d/copyright > >> audit, not checked the upstream code) > >> > >> Please fix above, remove the moreinfo tag, and -- time permitting -- I > >> will iterate. > >> > >> -- > >> tobi > >> > >> > > > > >