Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

[sorry, this got stuck in my drafts folder]

Dear Nicholas,

On Sun, Jan 15, 2017 at 10:26:44PM -0700, Nicholas D Steeves wrote:
> Thank you again for your patience and extra help!

No problem.  I hope that this was educational for you as a new DM --
that's probably more important than the updated package.

> > > Ah!  Yes, this is the spec that addresses my question to #3.  That
> > > said, in the past some of my other work on d/copyright has been said
> > > to be "worse than useless" even though it adhered to the spec, and
> > > even though it seemed to reflect what I saw reading the packages
> > > COPYING file, in addition to spending a while reading VCS commits for
> > > stuff I wasn't sure about.  This has led me to wonder about the tribal
> > > rules that are not in the spec...
> > 
> > Could you give me an example of a rule like that?
> 
> It'll take time to dig up examples from my backups, so I'll need to
> defer concrete examples until something like mid February.  It might
> be stuff like my failure to identify a package that is following DEP-5
> vs SPDX, but because of comments like "worst than useless" I figured
> there must have been some rule I didn't understand...because that's
> way too strong of a reaction for something that is a question of
> style. :-)  At this point, however, I don't think further discussion
> fits into this thread, because it is too tangential to muse-el.

Okay.  Probably best to address you question to the d-mentors list.

> By the way, is one space indentation for copyright definition blocks
> what should now be used (commit
> 5ba94789a7f35d5938d88226c6ea35fd98635a5b)?  I noticed the packaging
> guide's example uses one space, but most of the copyright-format/1.0
> packages I've looked at use four.  Just a convention?

I've only seen it done with a single space.  If it works with more than
one, fine.

> > > Would you please check to see if my latest commit to d/copyright
> > > is ok?  It's what makes the most sense to me.  As far as I can
> > > tell, it might be problematic because it infers that Eric Marsden
> > > changed cgi.el in 2003.  If it's problematic I'll revert it, then
> > > dch -r.
> > 
> > No, it doesn't actually imply that Marsden changed that file in 2004
> > (the spec does explain this!).
> 
> Ah, from packaging-manuals/copyright-format/1.0 "Not all copyright
> notices may apply to every individual file, and years of publication
> for one copyright holder may be gathered together" [1].  So short form
> rules I misunderstood are:
> 
> * Wildcards are hungry globs.
> * Lists of files are white-space, tab, or newline separated strings.
> * Years may be specified as either a comma-separated list of discrete
>   years, or a year-to-year range.
> * Refer to individual files or VCS for specific dates when multiple
>   files are grouped, because [1].

I don't know whether this list is an accurate list of what you
misunderstood, but the four bullet points are true of the format :)

> I also wonder how many contributors there must be to justify a
> "Primary copyright holder, and others" statement, and also if one
> needs to do VCS archaeology to find and list all of the potential
> one-off contributors.

That's beyond my knowledge, I'm afraid.  You might want to ask d-legal.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

Thank you again for your patience and extra help!

On Sun, Jan 15, 2017 at 05:51:09PM -0700, Sean Whitton wrote:
> > Ah!  Yes, this is the spec that addresses my question to #3.  That
> > said, in the past some of my other work on d/copyright has been said
> > to be "worse than useless" even though it adhered to the spec, and
> > even though it seemed to reflect what I saw reading the packages
> > COPYING file, in addition to spending a while reading VCS commits for
> > stuff I wasn't sure about.  This has led me to wonder about the tribal
> > rules that are not in the spec...
> 
> Could you give me an example of a rule like that?

It'll take time to dig up examples from my backups, so I'll need to
defer concrete examples until something like mid February.  It might
be stuff like my failure to identify a package that is following DEP-5
vs SPDX, but because of comments like "worst than useless" I figured
there must have been some rule I didn't understand...because that's
way too strong of a reaction for something that is a question of
style. :-)  At this point, however, I don't think further discussion
fits into this thread, because it is too tangential to muse-el.

By the way, is one space indentation for copyright definition blocks
what should now be used (commit
5ba94789a7f35d5938d88226c6ea35fd98635a5b)?  I noticed the packaging
guide's example uses one space, but most of the copyright-format/1.0
packages I've looked at use four.  Just a convention?

> > Would you please check to see if my latest commit to d/copyright is
> > ok?  It's what makes the most sense to me.  As far as I can tell, it
> > might be problematic because it infers that Eric Marsden changed
> > cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.
> 
> No, it doesn't actually imply that Marsden changed that file in 2004
> (the spec does explain this!).

Ah, from packaging-manuals/copyright-format/1.0 "Not all copyright
notices may apply to every individual file, and years of publication
for one copyright holder may be gathered together" [1].  So short form
rules I misunderstood are:

* Wildcards are hungry globs.
* Lists of files are white-space, tab, or newline separated strings.
* Years may be specified as either a comma-separated list of discrete
  years, or a year-to-year range.
* Refer to individual files or VCS for specific dates when multiple
  files are grouped, because [1].

I also wonder how many contributors there must be to justify a
"Primary copyright holder, and others" statement, and also if one
needs to do VCS archaeology to find and list all of the potential
one-off contributors.

> Go ahead and `dch -r`!

Done, finally! :-D

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sun, Jan 15, 2017 at 04:51:24PM -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> > I found some more errors in the copyright file.  Rather than go back and
> > forth once again, I fixed them in our team git repository.  I set the
> > changelog back to UNRELEASED: if you are okay with the changes, please
> > `dch -r`, commit and push, and I will upload.
> 
> Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
> the file is time stamped <2001-08-24 emarsden>?  

Ah, sorry.

> For httpd.el, I agree that "2001, 2003" is more accurate, but is it
> allowed?  In the past, when I've submitted patches to this effect the
> maintainer of the package changed the lines to something like
> "2001-2003", even though the VCS and copyright embedded in the file
> specified discreet years rather than a range...which led me to believe
> that a discreet range is unacceptable.

A discrete range is fine.

> Ah!  Yes, this is the spec that addresses my question to #3.  That
> said, in the past some of my other work on d/copyright has been said
> to be "worse than useless" even though it adhered to the spec, and
> even though it seemed to reflect what I saw reading the packages
> COPYING file, in addition to spending a while reading VCS commits for
> stuff I wasn't sure about.  This has led me to wonder about the tribal
> rules that are not in the spec...

Could you give me an example of a rule like that?

> Would you please check to see if my latest commit to d/copyright is
> ok?  It's what makes the most sense to me.  As far as I can tell, it
> might be problematic because it infers that Eric Marsden changed
> cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

No, it doesn't actually imply that Marsden changed that file in 2004
(the spec does explain this!).

Go ahead and `dch -r`!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Hi Sean,

On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> I found some more errors in the copyright file.  Rather than go back and
> forth once again, I fixed them in our team git repository.  I set the
> changelog back to UNRELEASED: if you are okay with the changes, please
> `dch -r`, commit and push, and I will upload.

Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
the file is time stamped <2001-08-24 emarsden>?  For httpd.el, I agree
that "2001, 2003" is more accurate, but is it allowed?  In the past,
when I've submitted patches to this effect the maintainer of the
package changed the lines to something like "2001-2003", even though
the VCS and copyright embedded in the file specified discreet years
rather than a range...which led me to believe that a discreet range is
unacceptable.

Thank you for the addition of FSF (c) holder, and for adding the final
newline back in.  I'm guessing it disappeared as an artefact of a git
rebase.  A manual git rm elpa-muse.maintscript was also necessary
(argh).

> > > 3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
> > > reflected in d/copyright.
> > 
> > I broke these out into individual stanzas, because I'm short on time
> > right now and wasn't able to find canonical documentation quickly
> > enough.  Comma separated or
> > Files: file1
> >file2
> > 
> > both seem like likely possibilities.  Would it be a nuisance to the
> > maint-guide maintainers if I filed a bug requesting some guidelines on
> > how to group things?  Is that the most appropriate package to file a
> > bug against for this issue?
> 
> You couldn't find the info in the spec?
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Ah!  Yes, this is the spec that addresses my question to #3.  That
said, in the past some of my other work on d/copyright has been said
to be "worse than useless" even though it adhered to the spec, and
even though it seemed to reflect what I saw reading the packages
COPYING file, in addition to spending a while reading VCS commits for
stuff I wasn't sure about.  This has led me to wonder about the tribal
rules that are not in the spec...

Would you please check to see if my latest commit to d/copyright is
ok?  It's what makes the most sense to me.  As far as I can tell, it
might be problematic because it infers that Eric Marsden changed
cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

> > For some reason my piuparts installation isn't working properly, but
> > manually I tested both clean install and upgrading in a clean sid
> > chroot. (this is how I tested #1 and #6)
> 
> piuparts is failing here too, due to issues in the ldap packages.  I
> also tested the manual upgrade and it works :)

:-)


Kind regards,
Nicholas


signature.asc
Description: Digital signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sat, Jan 14, 2017 at 09:04:28PM -0700, Nicholas D Steeves wrote:
> I think it's finally ready.

I found some more errors in the copyright file.  Rather than go back and
forth once again, I fixed them in our team git repository.  I set the
changelog back to UNRELEASED: if you are okay with the changes, please
`dch -r`, commit and push, and I will upload.

> > 3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
> > reflected in d/copyright.
> 
> I broke these out into individual stanzas, because I'm short on time
> right now and wasn't able to find canonical documentation quickly
> enough.  Comma separated or
> Files: file1
>file2
> 
> both seem like likely possibilities.  Would it be a nuisance to the
> maint-guide maintainers if I filed a bug requesting some guidelines on
> how to group things?  Is that the most appropriate package to file a
> bug against for this issue?

You couldn't find the info in the spec?

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

> > 4) contrib/pyblosxom/make-blog has a custom license.
> This one required research.  Fixed.

Great work figuring this one out!

> > Don't forget to update the changelog for the above, and `dch -r`.  I
> > would recommend testing with piuparts to confirm the (1) and (6) are
> > resolved.  I'm confident that I'll be able to upload once you've
> > resolved these six points, though I've replied to your other comments
> > below.
> 
> For some reason my piuparts installation isn't working properly, but
> manually I tested both clean install and upgrading in a clean sid
> chroot. (this is how I tested #1 and #6)

piuparts is failing here too, due to issues in the ldap packages.  I
also tested the manual upgrade and it works :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

I think it's finally ready.

On Sat, Dec 31, 2016 at 02:19:27PM +, Sean Whitton wrote:

> Thank you for your updated package.  As mentioned previously, we're
> still in time for binNEW.  I've found six remaining issues.  All are
> very easy to fix/check.  Some of these I should have found earlier, so
> my apologies for that.  Some of them are due to your most recent
> changes, though.
> 
> 1) From running adequate:
> 
> 2m48.4s ERROR: FAIL: Inadequate results from running adequate!
>   muse-el: obsolete-conffile /etc/emacs/site-start.d/50muse-el.el

Fixed by adding muse-el.maintscript.  For renamed
packages/transitions, it looks like it needs to be old-name.maintscript.

> 2) "License: MIT" should be "License: Expat".
> 
> "MIT" is ambiguous between various different licenses.

Fixed.

> 3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
> reflected in d/copyright.

I broke these out into individual stanzas, because I'm short on time
right now and wasn't able to find canonical documentation quickly
enough.  Comma separated or
Files: file1
   file2

both seem like likely possibilities.  Would it be a nuisance to the
maint-guide maintainers if I filed a bug requesting some guidelines on
how to group things?  Is that the most appropriate package to file a
bug against for this issue?

> 4) contrib/pyblosxom/make-blog has a custom license.
This one required research.  Fixed.

> 5) COPYING is not copyright the muse-el authors!  By convention, we
> ignore copies of licenses in d/copyright, so you can just remove it.
Thanks for the tip!

> 6) elpa-muse_3.20+dfsg-1_all.deb did not install cleanly.  I pushed a
> commit fixing the problem -- please check it is okay with you.

Back in August, I remember consulting you about what package to source
htmlize from, but forgot that this was the original cause, so yes, I'm
ok with it ;-)

> Don't forget to update the changelog for the above, and `dch -r`.  I
> would recommend testing with piuparts to confirm the (1) and (6) are
> resolved.  I'm confident that I'll be able to upload once you've
> resolved these six points, though I've replied to your other comments
> below.

For some reason my piuparts installation isn't working properly, but
manually I tested both clean install and upgrading in a clean sid
chroot. (this is how I tested #1 and #6)

> > On Sat, Dec 10, 2016 at 02:46:11PM -0700, Sean Whitton wrote:
> > > Dear Nicholas,
> > > 
> > > On Wed, Dec 07, 2016 at 09:16:28PM -0500, Nicholas D Steeves wrote:
[...]
> > > 4. "- Change section to editors; Change priority to optional."
> > > 
> > > This should be two separate lines.
> > 
> > Notice of this kind of convention I'd like to see in a "New Packages
> > Guide" ;-)
> 
> This should probably be in maint-guide.  You could file a bug if there
> is no mention there.  The idea is simply that each '*' is a separate
> change.

Bug filed!

Thanks again for the help!
Nicholas

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sat, Dec 31, 2016 at 02:19:27PM +, Sean Whitton wrote:
> Thank you for your updated package.  As mentioned previously, we're
> still in time for binNEW.  I've found six remaining issues.  All are
> very easy to fix/check.

Ping?

We're running out of time!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Thu, Dec 29, 2016 at 09:10:28PM -0700, Nicholas D Steeves wrote:
> I hope you're enjoying the holidays.  Mine have been busy, and I hope
> this version of src:muse-el is of sufficient quality to be uploaded to
> the archive, because the addition of the new package elpa-muse won't
> be possible after Jan 5th.

Thank you for your updated package.  As mentioned previously, we're
still in time for binNEW.  I've found six remaining issues.  All are
very easy to fix/check.  Some of these I should have found earlier, so
my apologies for that.  Some of them are due to your most recent
changes, though.

1) From running adequate:

2m48.4s ERROR: FAIL: Inadequate results from running adequate!
  muse-el: obsolete-conffile /etc/emacs/site-start.d/50muse-el.el

Please read dpkg-maintscript-helper(1) to fix this.

2) "License: MIT" should be "License: Expat".

"MIT" is ambiguous between various different licenses.

3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
reflected in d/copyright.

4) contrib/pyblosxom/make-blog has a custom license.

5) COPYING is not copyright the muse-el authors!  By convention, we
ignore copies of licenses in d/copyright, so you can just remove it.

6) elpa-muse_3.20+dfsg-1_all.deb did not install cleanly.  I pushed a
commit fixing the problem -- please check it is okay with you.

Don't forget to update the changelog for the above, and `dch -r`.  I
would recommend testing with piuparts to confirm the (1) and (6) are
resolved.  I'm confident that I'll be able to upload once you've
resolved these six points, though I've replied to your other comments
below.

> On Sat, Dec 10, 2016 at 02:46:11PM -0700, Sean Whitton wrote:
> > Dear Nicholas,
> > 
> > On Wed, Dec 07, 2016 at 09:16:28PM -0500, Nicholas D Steeves wrote:
> > > Thank you once again for holding me to high standards and for taking
> > > the time to point out what needs work!
> > 
> > And thank you for your patience with this review process.
> > 
> > I saw some more problems.  Some of these are quite elementary errors:
> > 
> > 1. You're still not closing the ITA properly.  You are missing a '#'
> > character.
> > 
> > 2. There is a spurious '+' character in your rules file that is subtly
> > breaking the build.
> > 
> > I notice that you have an application to be a DM.  These sorts of errors
> > can cause broken uploads, and confusion among collaborators.  Please try
> > to get into the habit of checking your commits very carefully,
> > especially when they are intended for upload to Debian.
> 
> I'm collecting a list of mistakes I'm likely to make when I'm not 100%
> focused on the work I'm doing; in the future, I plan to use it as a
> personal checklist.  If any of these mistakes fall into the "useful
> for other new packages" category, please let me know and I'll find a
> wiki.d.org article to contribute to.  On the other hand, maybe they're
> just dumb mistakes ;-)

I'd just recommend the technique of putting your work aside for a few
hours and coming back to it.  I.e., fix everything, walk away and do
something else, come back and look over what you did before, and then
upload.

> > 3. Point 15 from my previous e-mail not yet addressed:
> > > Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment to
> > > the control file.
> > 
> Ah, specifically with a comment in d/control vs d/changelog.  Fixed,
> plus a mistake I missed; in d/changelog I had intended to compromise
> with recommends vs requires, but failed to make the change to
> d/control).

Great.

> > 4. "- Change section to editors; Change priority to optional."
> > 
> > This should be two separate lines.
> 
> Notice of this kind of convention I'd like to see in a "New Packages
> Guide" ;-)

This should probably be in maint-guide.  You could file a bug if there
is no mention there.  The idea is simply that each '*' is a separate
change.

> > 5. Have you figured out that "binary package" stuff discussed in
> > your previous e-mail by yourself, or is that something I can help
> > you with?
> 
> Sorry, unfortunately I have not.  Yes, please help me with this and
> feel free commit directly to pkg-emacsen.

Sorry -- I couldn't figure out what your problem was, from your previous
message.  If you'd like me to try to help, please have another go at
explaining it (or we can just forget about it if you have other things
to do).

> > > I've contacted Michael Olson about the possibility of providing an
> > > examples/mwolson tarball on his website, because as I see it the
> > > external links are an integral part of the Muse-managed website
> > > example.  Specifically, I believe the intent of the example is to
> > > provide a copy of a website that is browsable online so that the
> > > user can explore both the source layout of a Muse-managed project
> > > and browse the result.  In the meantime, I've added an override;
> > > if that override is unacceptable, please let me know.  If we can
> > > keep the override, I'd be happy 

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Paul Wise]

On Fri, Dec 30, 2016 at 12:10 PM, Nicholas D Steeves wrote:

> I'm collecting a list of mistakes I'm likely to make when I'm not 100%
> focused on the work I'm doing; in the future, I plan to use it as a
> personal checklist.  If any of these mistakes fall into the "useful
> for other new packages" category, please let me know and I'll find a
> wiki.d.org article to contribute to.  On the other hand, maybe they're
> just dumb mistakes ;-)

I think it would be best to add detection of those issues to the
appropriate packages, probably lintian, check-all-the-things and or
dependencies of the two.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

On Fri, Dec 30, 2016 at 04:59:11PM +, Sean Whitton wrote:
> Just to let you know, we've already missed the deadline to add elpa-muse
> to stretch (it was Christmas day, due to 10 day migrations).

Sorry, looks like we were both wrong -- the deadline for binNEW is
February 5th.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Hello Nicholas,

Just to let you know, we've already missed the deadline to add elpa-muse
to stretch (it was Christmas day, due to 10 day migrations).

I'll respond properly later.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

I hope you're enjoying the holidays.  Mine have been busy, and I hope
this version of src:muse-el is of sufficient quality to be uploaded to
the archive, because the addition of the new package elpa-muse won't
be possible after Jan 5th.

On Sat, Dec 10, 2016 at 02:46:11PM -0700, Sean Whitton wrote:
> Dear Nicholas,
> 
> On Wed, Dec 07, 2016 at 09:16:28PM -0500, Nicholas D Steeves wrote:
> > Thank you once again for holding me to high standards and for taking
> > the time to point out what needs work!
> 
> And thank you for your patience with this review process.
> 
> I saw some more problems.  Some of these are quite elementary errors:
> 
> 1. You're still not closing the ITA properly.  You are missing a '#'
> character.
> 
> 2. There is a spurious '+' character in your rules file that is subtly
> breaking the build.
> 
> I notice that you have an application to be a DM.  These sorts of errors
> can cause broken uploads, and confusion among collaborators.  Please try
> to get into the habit of checking your commits very carefully,
> especially when they are intended for upload to Debian.

I'm collecting a list of mistakes I'm likely to make when I'm not 100%
focused on the work I'm doing; in the future, I plan to use it as a
personal checklist.  If any of these mistakes fall into the "useful
for other new packages" category, please let me know and I'll find a
wiki.d.org article to contribute to.  On the other hand, maybe they're
just dumb mistakes ;-)

> Okay, now the less elementary stuff:
> 
> 2. Upstream's README says that the license for contrib/*blosxom is
> different from the main project.  This should be reflected in
> d/copyright (though see below for other issues to resolve first).

Done/pending.

> 3. Point 15 from my previous e-mail not yet addressed:
> > Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment to
> > the control file.
> 
Ah, specifically with a comment in d/control vs d/changelog.  Fixed,
plus a mistake I missed; in d/changelog I had intended to compromise
with recommends vs requires, but failed to make the change to
d/control).

> 4. "- Change section to editors; Change priority to optional."
> 
> This should be two separate lines.

Notice of this kind of convention I'd like to see in a "New Packages
Guide" ;-)

> 5. Have you figured out that "binary package" stuff discussed in your
> previous e-mail by yourself, or is that something I can help you with?

Sorry, unfortunately I have not.  Yes, please help me with this and
feel free commit directly to pkg-emacsen.

> > I've contacted Michael Olson about the possibility of providing an
> > examples/mwolson tarball on his website, because as I see it the
> > external links are an integral part of the Muse-managed website
> > example.  Specifically, I believe the intent of the example is to
> > provide a copy of a website that is browsable online so that the user
> > can explore both the source layout of a Muse-managed project and
> > browse the result.  In the meantime, I've added an override; if that
> > override is unacceptable, please let me know.  If we can keep the
> > override, I'd be happy to notify users--with NEWS--of the potential
> > privacy breach.
> 
> Looks good to me -- thanks for figuring out the warnings.
> 
> It would be good to limit the override to that directory.  Lintian
> overrides support wildcards, so you should be able to do something like
> this (not tested):
> 
> elpa-muse binary: 
> privacy-breach-generic*/usr/share/doc/elpa-muse/examples/mwolson/*

Originally I tried (and failed) to limit the override, so fell back to
the sloppy glob approach.  For future reference to anyone reading this
thread, this is the syntax that worked for me:

elpa-muse binary: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/*

> > > 10. How are the *.py files meant to be used?  Are they supposed to
> > > be copied into a pyblosxom installation, or run directly from where
> > > they are installed?  If the latter, they should be bytecompiled and
> > > installed into /usr/share/elpa-muse/contrib.  If the former, they
> > > are fine as they are.
> > 
> > By reading the following from getstamps.py:
[...]
> > It would seem that these are intended to be used in the following
> > manner: user reads the headers of these contributed python programs,
> > then adapts them to his/her needs, then copies them to the blog
> > project dir (eg: ~/my_blog).  Previous versions of src:muse-el
> > installed these contributed programs to
> > /usr/share/doc/muse-el/contrib.
> 
> I would be inclined to put them in /usr/src/elpa-muse.  The propellor
> package puts a copy of its upstream source code in /usr/src/propellor.
> 
> The current location is fine if you prefer.  Thanks for the explanation.

You're welcome.  In this particular case, I prefer to be conservative
vs disruptive ;-)

> > > 11. I've now reviewed d/copyright.  Unfortunately, you can't claim
> > > that the debian/ directory is GPL-3+ without 

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Wed, Dec 07, 2016 at 09:16:28PM -0500, Nicholas D Steeves wrote:
> Thank you once again for holding me to high standards and for taking
> the time to point out what needs work!

And thank you for your patience with this review process.

I saw some more problems.  Some of these are quite elementary errors:

1. You're still not closing the ITA properly.  You are missing a '#'
character.

2. There is a spurious '+' character in your rules file that is subtly
breaking the build.

I notice that you have an application to be a DM.  These sorts of errors
can cause broken uploads, and confusion among collaborators.  Please try
to get into the habit of checking your commits very carefully,
especially when they are intended for upload to Debian.

Okay, now the less elementary stuff:

2. Upstream's README says that the license for contrib/*blosxom is
different from the main project.  This should be reflected in
d/copyright (though see below for other issues to resolve first).

3. Point 15 from my previous e-mail not yet addressed:

> Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment to
> the control file.

4. "- Change section to editors; Change priority to optional."

This should be two separate lines.

5. Have you figured out that "binary package" stuff discussed in your
previous e-mail by yourself, or is that something I can help you with?

> > 6. In d/NEWS,
> > 
> > > Unfortunately, it is not possible to distribute this manual with the
> > > muse-el Debian package because the Debian project has chosen to remove
> > > most GFDL'd documentation.
> > 
> > Wouldn't you say the unfortunate thing is that the manual has not been
> > relicensed under a DFSG-compatible license? ;)
> 
> Yes, I agree :-) however, I didn't write that part of d/NEWS and only
> made in-line updates to paths.  Originally I had added a message at
> the top which essentially said "in your head, do s/this/that/ -e s/and
> this/with this/ -e s/and don't forget/this either/".  It seemed
> clumsy, so I decided to merge it and put the originally author's name
> unambiguously right at the top.

Okay.

> > 7. I'm pretty sure you shouldn't compress
> > /usr/share/doc/elpa-muse/QuickStart.pdf.  It might break doc-base
> > clients, and in any case, I doubt that gzip compression is very good
> > for PDFs.
> 
> That you for reminding me to fix this; my mental TODO list dropped
> this item!  On that topic, should examples/* be ready to copy into
> place and use, or is ok to let dh_examples compress those? (related to
> the answer to 10.)

I think it's fine to let examples be compressed.

> > 9. There is still a lot of Lintian output.  Please make the package
> > Lintian clean.  Please ensure you turn on experimental and
> > informational tags:
> > 
> > I: muse-el source: binary-control-field-duplicates-source field 
> > "priority" in package muse-el
> > E: muse-el source: license-problem-gfdl-invariants README invariant 
> > part is: with no invariant sections, and with the front-cover texts and 
> > back-cover texts as specified in the manual
> > I: muse-el source: debian-watch-file-is-missing
> > I: elpa-muse: debian-news-entry-uses-asterisk
> > X: elpa-muse: privacy-breach-generic 
> > usr/share/doc/elpa-muse/examples/mwolson/templates/generic-header.html 
> > (http://www.mwolson.org/web/aboutme.html)
> > X: elpa-muse: privacy-breach-generic 
> > usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
> > (http://blog.mwolson.org/index.rss)
> > X: elpa-muse: privacy-breach-generic 
> > usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
> > (http://mwolson.org/web/aboutme.html)
> > X: elpa-muse: privacy-breach-generic ... use --no-tag-display-limit to 
> > see all (or pipe to a file/program)
> > I: muse-el: debian-news-entry-uses-asterisk
> > I: muse-el: description-synopsis-might-not-be-phrased-properly
> 
> E: muse-el source: license-problem-gfdl-invariants README is, to the
> best of my knowledge bogus, because that documentation is stripped
> from our orig.tarball.  I believe it's ok to leave the README
> unpatched, but I might be wrong about this.

Yes, it's fine to leave it unpatched.

> I've contacted Michael Olson about the possibility of providing an
> examples/mwolson tarball on his website, because as I see it the
> external links are an integral part of the Muse-managed website
> example.  Specifically, I believe the intent of the example is to
> provide a copy of a website that is browsable online so that the user
> can explore both the source layout of a Muse-managed project and
> browse the result.  In the meantime, I've added an override; if that
> override is unacceptable, please let me know.  If we can keep the
> override, I'd be happy to notify users--with NEWS--of the potential
> privacy breach.

Looks good to me -- thanks for figuring out the warnings.

It would be good to limit the override to that directory.  Lintian
overrides support 

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

Thank you once again for holding me to high standards and for taking
the time to point out what needs work!

1-to-5, and 8: done
>
> 6. In d/NEWS,
> 
> > Unfortunately, it is not possible to distribute this manual with the
> > muse-el Debian package because the Debian project has chosen to remove
> > most GFDL'd documentation.
> 
> Wouldn't you say the unfortunate thing is that the manual has not been
> relicensed under a DFSG-compatible license? ;)

Yes, I agree :-) however, I didn't write that part of d/NEWS and only
made in-line updates to paths.  Originally I had added a message at
the top which essentially said "in your head, do s/this/that/ -e s/and
this/with this/ -e s/and don't forget/this either/".  It seemed
clumsy, so I decided to merge it and put the originally author's name
unambiguously right at the top.

> 7. I'm pretty sure you shouldn't compress
> /usr/share/doc/elpa-muse/QuickStart.pdf.  It might break doc-base
> clients, and in any case, I doubt that gzip compression is very good for
> PDFs.

That you for reminding me to fix this; my mental TODO list dropped
this item!  On that topic, should examples/* be ready to copy into
place and use, or is ok to let dh_examples compress those? (related to
the answer to 10.)

> 9. There is still a lot of Lintian output.  Please make the package
> Lintian clean.  Please ensure you turn on experimental and informational
> tags:
> 
> I: muse-el source: binary-control-field-duplicates-source field 
> "priority" in package muse-el
> E: muse-el source: license-problem-gfdl-invariants README invariant part 
> is: with no invariant sections, and with the front-cover texts and back-cover 
> texts as specified in the manual
> I: muse-el source: debian-watch-file-is-missing
> I: elpa-muse: debian-news-entry-uses-asterisk
> X: elpa-muse: privacy-breach-generic 
> usr/share/doc/elpa-muse/examples/mwolson/templates/generic-header.html 
> (http://www.mwolson.org/web/aboutme.html)
> X: elpa-muse: privacy-breach-generic 
> usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
> (http://blog.mwolson.org/index.rss)
> X: elpa-muse: privacy-breach-generic 
> usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
> (http://mwolson.org/web/aboutme.html)
> X: elpa-muse: privacy-breach-generic ... use --no-tag-display-limit to 
> see all (or pipe to a file/program)
> I: muse-el: debian-news-entry-uses-asterisk
> I: muse-el: description-synopsis-might-not-be-phrased-properly

E: muse-el source: license-problem-gfdl-invariants README is, to the
best of my knowledge bogus, because that documentation is stripped
from our orig.tarball.  I believe it's ok to leave the README
unpatched, but I might be wrong about this.

I've contacted Michael Olson about the possibility of providing an
examples/mwolson tarball on his website, because as I see it the
external links are an integral part of the Muse-managed website
example.  Specifically, I believe the intent of the example is to
provide a copy of a website that is browsable online so that the user
can explore both the source layout of a Muse-managed project and
browse the result.  In the meantime, I've added an override; if that
override is unacceptable, please let me know.  If we can keep the
override, I'd be happy to notify users--with NEWS--of the potential
privacy breach.

> 10. How are the *.py files meant to be used?  Are they supposed to be
> copied into a pyblosxom installation, or run directly from where they
> are installed?  If the latter, they should be bytecompiled and installed
> into /usr/share/elpa-muse/contrib.  If the former, they are fine as they are.

By reading the following from getstamps.py:

Run 'python getstamps.py' from the directory that contains your
unpublished blog entries.

You may need to make some modification for your situation. This
assumes your blog entries use a .txt extension and that you generate
them from "source" files in a different directory (with an optional
.muse extension).

It would seem that these are intended to be used in the following
manner: user reads the headers of these contributed python programs,
then adapts them to his/her needs, then copies them to the blog
project dir (eg: ~/my_blog).  Previous versions of src:muse-el
installed these contributed programs to
/usr/share/doc/muse-el/contrib.  According to this precedent and the
intended usage described in the programs header, I believe that the
current location is correct.  Alternatively, these files might exist
primarily as examples of how to configure upstream pyblosxom for use
with Muse; if this is the case, then they belong in /usr/share/doc.

> 11. I've now reviewed d/copyright.  Unfortunately, you can't claim that
> the debian/ directory is GPL-3+ without contacting each of the authors
> you name and confirming they are happy to release their contributors
> under that license, since it was not explicitly stated.  What happens 

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

Thanks again for your work on this.  I'm looking forward to seeing the
cleaned-up package in Debian stretch.

Before I reply to your message, let me note a few more things to fix:

1. s/Muse-el/muse-el/ in the changelog

2. You need to re-run `dch -r` so the timestamp is later than your
changes.

3. "Includes changes to debian/control, debian/rules, NEWS"

This is not very informative.  I'm not saying that you have to list
every change, but see how much more informative this is:

- Update Build-Depends; Maintainer; Uploaders [or whatever fields you updated]
- Rewrite d/rules
- Update NEWS

For a sample, see the most recent changelog entry of the yasnippet
package, which I recently converted to use dh_elpa.

4. "Add patch ..."

When you say that you added a patch, it is best to explicitly state the
patch filename so that someone searching the changelog for that patch
name can find it easily.

5. "Add depends on doc-base to register Quickstart.pdf as
muse-quickstart."

Build-Depends?  Binary package dependency?

Are you sure you need this?  doc-base registration uses triggers, so you
don't generally need to depend on it.

6. In d/NEWS,

> Unfortunately, it is not possible to distribute this manual with the
> muse-el Debian package because the Debian project has chosen to remove
> most GFDL'd documentation.

Wouldn't you say the unfortunate thing is that the manual has not been
relicensed under a DFSG-compatible license? ;)

7. I'm pretty sure you shouldn't compress
/usr/share/doc/elpa-muse/QuickStart.pdf.  It might break doc-base
clients, and in any case, I doubt that gzip compression is very good for
PDFs.

8. In the patch header for use_see_not_open.diff, it would be good to
know why you're applying the patch.  What's the advantage of see(1) over
open(1)?

9. There is still a lot of Lintian output.  Please make the package
Lintian clean.  Please ensure you turn on experimental and informational
tags:

I: muse-el source: binary-control-field-duplicates-source field "priority" 
in package muse-el
E: muse-el source: license-problem-gfdl-invariants README invariant part 
is: with no invariant sections, and with the front-cover texts and back-cover 
texts as specified in the manual
I: muse-el source: debian-watch-file-is-missing
I: elpa-muse: debian-news-entry-uses-asterisk
X: elpa-muse: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/templates/generic-header.html 
(http://www.mwolson.org/web/aboutme.html)
X: elpa-muse: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
(http://blog.mwolson.org/index.rss)
X: elpa-muse: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
(http://mwolson.org/web/aboutme.html)
X: elpa-muse: privacy-breach-generic ... use --no-tag-display-limit to see 
all (or pipe to a file/program)
I: muse-el: debian-news-entry-uses-asterisk
I: muse-el: description-synopsis-might-not-be-phrased-properly

10. How are the *.py files meant to be used?  Are they supposed to be
copied into a pyblosxom installation, or run directly from where they
are installed?  If the latter, they should be bytecompiled and installed
into /usr/share/elpa-muse/contrib.  If the former, they are fine as they are.

11. I've now reviewed d/copyright.  Unfortunately, you can't claim that
the debian/ directory is GPL-3+ without contacting each of the authors
you name and confirming they are happy to release their contributors
under that license, since it was not explicitly stated.  What happens if
one of them is only happy with GPL-2, and no later versions?

I think this means that you can't switch to copyright format 1.0, and
have to keep the old copyright file.  You could add credit for revamping
the package for yourself if you like.

12. Your change in the "Priority:" field is not in the changelog.

13. You bumped the standards-version but didn't mention it in the
changelog.  Did you review the upgrading checklist?[1]

14. Consider s/emacs24/emacs25/ in build-depends-indep.

15. Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment
to the control file.

16. muse-el is not a library.  It shouldn't be in section: oldlibs.

17. The deletion of d/emacsen-* is not in the changelog.  Similarly,
d/muse-el.dirs.

18. At dh compat 10, you can drop --parallel from d/rules.

19. I think you should remove Joey Hess's copyright notice in d/rules,
since you're not using old-style debhelper at all anymore.

On Thu, Nov 24, 2016 at 07:25:29PM -0500, Nicholas D Steeves wrote:
> On Sun, Nov 13, 2016 at 03:38:01PM -0700, Sean Whitton wrote:
> > In the future, when submitting a new bug, please use X-Debbugs-CC: rather
> > than CC: so that the bug gets assigned a number before reaching my
> > inbox.
> 
> Would you please share how to get X-Debbugs-CC: to show up in mutt's
> edit_headers?  It seems to be ignored unless it is set using this:
> my_hdr X-Debbugs-CC: bogus_value

You can 

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Updated package was uploaded to mentors over the weekend.

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

On Thu, Nov 24, 2016 at 07:25:29PM -0500, Nicholas D Steeves wrote:
> > 5. There are a lot of Lintian warnings.  Please make the package
> > Lintian-clean.
> 
> I'm having trouble with "W: elpa-muse: syntax-error-in-debian-news-file
> line 68 "found eof where expected first heading", and have tried
> synchronising my date stamp with the one in changelog, removing '*'s and
> '-'s, and several white-space experiments...to no avail.

Fixed.  I did it by: 1. Discovering dch --news  2. Removing my
additions  3. Dch --news  4. Oops, it picks UNRELEASED  5. Change
changelog entry to UNRELEASED  6. Paste my additions back into NEWS
7. Dch -r --news  8. git commit  9. Build.

And then, for some reason, it worked...  I fail to understand why, and
it seems like voodoo hand waving.  The only thing I can think of is
that there is a hidden rule that the date stamps on changelog and NEWS
cannot be the same, and that NEWS must be older than changelog.
Additionally, I wonder if there is an invisible mtime to claimed
datestamp comparison.  Whatever the case, it looks like I'll be using
dch --news in the future. :-)

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Hi Sean,

Thank you very much for all your help and for this review!  Would you
please pull my working copy from here:

git+ssh://git.debian.org/git/pkg-emacsen/pkg/muse-el.git
here:
https://anonscm.debian.org/git/pkg-emacsen/pkg/muse-el.git
or consult this:
https://anonscm.debian.org/cgit/pkg-emacsen/pkg/muse-el.git/

to see how I've implemented the changes you've advised.  Further
questions follow inline.

On Sun, Nov 13, 2016 at 03:38:01PM -0700, Sean Whitton wrote:
> In the future, when submitting a new bug, please use X-Debbugs-CC: rather
> than CC: so that the bug gets assigned a number before reaching my
> inbox.

Would you please share how to get X-Debbugs-CC: to show up in mutt's
edit_headers?  It seems to be ignored unless it is set using this:
my_hdr X-Debbugs-CC: bogus_value

> I've split my review into two sections: things that I would consider
> must-fixes before an upload to Debian, and suggested improvements.  The
> latter aren't strictly necessary, but they would help demonstrate to a
> potential sponsor that you are committed to maintaining this package in
> Debian.
> 
> Must-fixes
> ==
> 
> 1. Your changelog could do with some work.
>
> - you should close the ITA bug

Close the ITA bug in the changelog?  Do I need to send a control email
to the ITA bug (something like "also affects")?  I anticipate a
"closes bugs improperly" lintian error.

> - "Update format." -- from what to what?

I'm not sure what format the old copyright was.  Where "Format:" is
usually found it said this:
This package was debianized by Trent Buck  on
Thu, 23 Jun 2005 13:12:12 +1000.

Updated to this:
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

> 3. README.Debian should have a single timestamp.  Remove the previous
> maintainer's timestamp, add subheadings for the parts added by each of
> you, and put your timestamp at the bottom.

I'm not adding any new information so much as updating the paths to
reflect the new install locations.  Please let me know if this is a
more clear to do it this way than my original "Whenever path X is
mentioned, it actually refers to path Y".  The upside is the paths can
now be copied and pasted, useful full-text search, usefully grepped
etc, but I'm not sure if I've sufficiently attributed the original
author.

> 5. There are a lot of Lintian warnings.  Please make the package
> Lintian-clean.

I'm having trouble with "W: elpa-muse: syntax-error-in-debian-news-file
line 68 "found eof where expected first heading", and have tried
synchronising my date stamp with the one in changelog, removing '*'s and
'-'s, and several white-space experiments...to no avail.

> > Do my patches look ok?
> 
> 8. They need patch headers, preferably conforming to DEP-3, explaining
> what each of them is for.  Try to include a Forwarded: header, in
> particular.

I've added headers, and I've added you to the "Reviewed-by: " one.  Why
do I need the "Forwarded: " header when my patch is already checked into
git.debian.org?

> > Should elpafied packages continue to be arch-independent?
> 
> Yup.

When debugging some of my failed experimental modifications I noticed
that this is a binary package.  Is arch-independent interpreted source
+ docs still a binary package?  As far as I can tell, the
QuickStart.pdf is the only binary.

> Suggestions
> ===
>
Complete.


Please let me know if I've correctly addressed all ellipted items.

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

Dear Nicholas,

On Sat, Nov 12, 2016 at 10:18:54PM -0500, Nicholas D Steeves wrote:
> I am looking for review and a sponsor for my package "src:muse-el".
> I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and
> any emacs-on-Debian integration issues.

In the future, when submitting a new bug, please use X-Debbugs-CC: rather
than CC: so that the bug gets assigned a number before reaching my
inbox.

I've split my review into two sections: things that I would consider
must-fixes before an upload to Debian, and suggested improvements.  The
latter aren't strictly necessary, but they would help demonstrate to a
potential sponsor that you are committed to maintaining this package in
Debian.

Must-fixes
==

1. Your changelog could do with some work.

- you should close the ITA bug

- "Elpafy!" is not informative; please rewrite

- the change to use 3.0 (quilt) and debhelper compat 9 should be
  separate entries

- "Include images used by the QuickStart.muse example" -- what does
  'include' mean?  Are you installing them?  Be specific.

- "Fix misattributed source" -- which?

- "Update format." -- from what to what?

- "add override" -- you could say specifically which overrides you added

- "Install docs and examples the new dh_way." -- it's not really new,
  so I would say "Install docs and examples with dh_install* tools."

- "Thank you Kevin Ryde ..." -- it's good to thank people, but I find it
  too informal to talk about your personal history of learning the
  command ;)  How about just "Thank you to Kevin Ryde for suggesting
  this change."  (and thanks, I didn't know about see(1) either :))

- "texi stuff" -- again, informal and not informative.  How about just
  s/stuff/documentation/?

> Is debian/changelog too verbose and could it be condensed?

I don't find it to be too verbose.

2. Use spaces, not tabs, to wrap lines in debian/NEWS.

3. README.Debian should have a single timestamp.  Remove the previous
maintainer's timestamp, add subheadings for the parts added by each of
you, and put your timestamp at the bottom.

4. The maintainer should be the pkg-emacsen team, with you as an
uploader.  See other team packages.

5. There are a lot of Lintian warnings.  Please make the package
Lintian-clean.

6. The package fails testing with adequate:

2m16.3s ERROR: FAIL: Inadequate results from running adequate!
  elpa-muse: py-file-not-bytecompiled 
/usr/share/emacs/site-lisp/elpa-src/muse-3.20/getstamps.py
  elpa-muse: py-file-not-bytecompiled 
/usr/share/emacs/site-lisp/elpa-src/muse-3.20/hardcodedates.py
  elpa-muse: py-file-not-bytecompiled 
/usr/share/emacs/site-lisp/elpa-src/muse-3.20/metadate.py

7. These .py files should probably not be installed into
/usr/share/emacs -- or is it impossible to use them outside of Muse?
Have you considered installing them according to the python packaging
policy?  Can Muse be patched to use them when installed that way?

> Are the generated packages in the correct sections for an elpafied
> package?

Yup.

> Is removing hrefs to favicon.ico (Bug: #775885) sufficient?
> Distributing a favicon.ico seems unnecessary and honestly, I'm
> against it. In Canada, because the author retains all distribution
> rights in the absence of a license or declared copyright, even
> something as trivial as a favicon.ico can be unredistributable.  I
> couldn't find the license on Michael Olson's website
> , so I decided it was best not to copy it.

Yes, I think just removing the href is fine.

> Do my patches look ok?

8. They need patch headers, preferably conforming to DEP-3, explaining
what each of them is for.  Try to include a Forwarded: header, in
particular.

> Should elpafied packages continue to be arch-independent?

Yup.

Suggestions
===

1. Consider using dh compat 10.

2. Consider adding Enhances: emacs25.

3. Consider priority: optional, not extra.

4. Please use secure URIs in Vcs-* fields.

5. Please add doc-base registration.

I haven't tried installing and running the package yet, but the above
should be enough to be going on with.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for review and a sponsor for my package "src:muse-el".
I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and
any emacs-on-Debian integration issues.
Here are a few things I'm wondering about:

Are the generated packages in the correct sections for an elpafied
package?
Is removing hrefs to favicon.ico (Bug: #775885) sufficient?
Distributing a favicon.ico seems unnecessary and honestly, I'm
against it. In Canada, because the author retains all distribution
rights in the absence of a license or declared copyright, even
something as trivial as a favicon.ico can be unredistributable.  I
couldn't find the license on Michael Olson's website
, so I decided it was best not to copy it.

Do my patches look ok?
Should elpafied packages continue to be arch-independent?
Is debian/changelog too verbose and could it be condensed?

Package name: muse-el
Version : 3.20+dfsg-1
Section : editors

It builds those binary packages:

  elpa-muse  - Author and publish projects using Wiki-like markup
  muse-el- transitional dummy package for elpa-muse.

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/muse-el

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+dfsg-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

muse-el (3.20+dfsg-1) unstable; urgency=medium

  * New Maintainer.
  * debian/control:
- Bump required debhelper to >=9.
- Update emacs dependency.
- Add emacs-goodies-el dependency, which provides htmlize.el.
  * Switch to debcompat 9; Switch to 3.0 (quilt) non-native packaging.
  * Add patch to fix privacy breaches; removes hrefs. (Closes: #775885)
  * Elpafy! (depends on dh-elpa).
  * Add patch to disable non-DFSG compliant texi stuff.
  * Install docs and examples the new dh_way.
  * debian/rules:
- add override to build examples and autoloads.
- add override to install upstream changelog series.
  * debian/copyright:
- Fix misattributed source (found by comparing timestamps in comments
  between gna.org tarballs and git sources).
- Update format.
- Add debian/* section.
  * Include images used by the QuickStart.muse example. (Closes: #720121)
  * Add patch to use Debian's "see" command instead of "open".  Thank
you Kevin Ryde, I didn't know about the existence of "see" before
reading this bug report. (Closes: #720126)
  * Patch README to explain how installed files relate to src:muse-el.

 -- Nicholas D Steeves   Tue, 18 Oct 2016 20:58:45 -0400


Regards,
Nicholas D Steeves