> 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 Another reason to get rid of it to make it really portable ;-) But as said,
> 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.
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 <tobi@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
>>
>>
>