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

[David Suarez]

Re-Ping ?

El jue., 6 ago. 2020 a las 18:36, David Suarez
(<david.sephirot at gmail.com>) escribió:
>
> 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 !