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
> >>
> >>
> >
>
>
>

Reply via email to