[Debian-iot-maintainers] ocf-spec-core_2.1.0-1_amd64.changes REJECTED

[David Suarez]

Hi !

El mar., 4 ago. 2020 a las 19:57, Carsten Schoenert
(<c.schoenert at t-online.de>) escribió:
>
> Hello David,
>
> Am 01.08.20 um 20:43 schrieb David Suarez:
> >> I just uploaded the ocf-spec-core core package to salsa.d.o., fixing
> >> the copyright mistake and importing a new upstream version.
> >>
> >> Could any DD review and upload it ? It builds fine in sbuild and
> >> passes ok the salsa pipeline [0].
> >>
> >> Thanks !
> >>
> >> [0] <https://salsa.debian.org/debian-iot-team/ofc/ocf-spec-core/-/pipelines/157165>
> >
> > Ping ?
>
> I tried to have a look at this.
> But I'm a bit confused by the current data an the master branch and
> missing tags, at least one.
>
> This repo is holding a gbp.conf in the debian folder so I assume this
> repo is managed by git-buildpackage, but there isn't a file
> d/README.source that explains the packaging workflow.
>
> Next I don't see an updated branch 'upstream' nor the tagged new
> version. Also there is no pristine-tar commit with some delta data so
> I'm unable to rebuild the source bit identical and by this I even can't
> build the package.
>

Just uploaded the upstream and pristine-tar branches (tags too). I
simply forget about them.

> The changelog entry uses UNRELEASED for the distribution. This would
> result in a autoreject.
>
> Lintian must have mention this.

Uhm, that point... I ask some time ago If the team has any politics
about directly pointing to
unstable, or UNRELEASED, like I just done.

For UNRELEASED, the uploader has to change the line himself and add
laters add the 'debian/foo-version' tag.

I prefer to let it UNRELEASED, to mark it as pending to upload to
archive. Once it enters the archive, tag it. This way
if the package. between the upload to the archive and after it enters
the archive, we can see correctly the life span (is
possible that the upload doesn't enter the archive for many reasons,
for example the current case).

> The chmod thingy I'd place into a more appropriate target
> override_dh_fixperms (as written already earlier).

We talk about it, but as I note already, for this package I prefer to
go this way because it doesn't have any build system.

At some point in the future I want to ask upstream the reason for the
lack of it and propose a patch, so the lines in
override_dh_auto_install could go into a single INSTALL command.

> Seems you have some misunderstandings how git-buildpackage is intended
> to help the packaging.
>
> Right now there is not much I can do.
>
> Given this package isn't in the archive yet I suggest to drop the last
> two commits, doing a force push to salsa and then do a restart with a
> proper and correct import of the new upstream version 2.2.0 with
> git-buildpackage.
>
> Next add the updates to the copyright file.
>
> Finally use gbp again to create a changelog entry for the new imported
> version.
> If you have further questions please ask.

As I explained before, it is because I forgot to upload some branches.

> --
> Regards
> Carsten

Thanks for the review !