[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#837408: RFS: partimage/0.6.9-1 new upstream build partimage-0.6.9



Good points - I guess it is not worth making a new package to fix
these items you mention - but the next one I should consider them. See
below for more details


On 11 September 2016 at 23:18, Eriberto Mota <eriberto@debian.org> wrote:
> Contol: tag 837408 moreinfo
>
> Hi Andrew,
>
> I have some considerations:
>
> 1. d/changelog:
>
> - You are doing a QA upload. So, it must be in changelog.
>
> - You renamed the patch 03-ftbfs-zlib.patch to 01-ftbfs-zlib. Please,
> point it in changelog.
>
> 2. d/control:
>
> - Please, bump Standards-Version to 3.9.8.
>
> Thanks for your work.
>
> Regards,
>
> Eriberto
>

Thanks for your e-mail I will note the points about the changelog for
next time (as policy says best to fix changelog via an additional
entry).

I didn't check the changes to the Standards-Version field as I didn't
feel expert to look at that so I didn't attempt to update that.

So I have started to trawl through the changes via

/usr/share/doc/debian-policy/upgrading-checklist.txt.gz
 (from stretch which is upto 3.9.8.0)

since partimage-0.6.8 is currently as per Standards-Version 3.9.1.
I  found some things:

3.9.3:
     9.1.1
          `/run' is allowed as an exception to the FHS and replaces
          `/var/run'.  `/run/lock' replaces `/var/lock'.  The FHS
          requirements for the older directories apply to these directories
          as well.  Backward compatibility links will be maintained and
          packages need not switch to referencing `/run' directly yet.
          Files in `/run' should be stored in a temporary file system.
...

     9.1.4
          New section spelling out the requirements for packages that use
          files in `/run', `/var/run', or `/var/lock'.  This generalizes
          information previously only in 9.3.2.

partimage-0.6.9/debian/partimage-server.partimaged.init

has PIDFILE=/var/run/partimaged.pid

The above is ok I guess and otherwise I think the policy is good - so
next build I will bump up the Standards-version level as well.

Thanks  again

Andrew


Reply to: