Bug#912201: RFS: manticore/2.7.3 [ITP]

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Manticore Search Maintainers
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "manticore"

 * Package name    : manticore
   Version         : 2.7.3
   Upstream Author : Manticore Search
 * URL             : https://www.manticoresearch.com/
 * License         : GPL-2
   Section         : misc

  It builds those binary packages:

    manticore  - High performance full-text search engine

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

  https://mentors.debian.net/package/manticore


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

    dget -x https://mentors.debian.net/debian/pool/main/m/manticore/manticore_2.7.3.dsc

  More information about manticore can be obtained from https://github.com/manticoresoftware/manticoresearch.

 
  Regards,
   Manticore Search Maintainers 
Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

[2018-10-29 09:39] Manticore Search Maintainers <[hidden email]>
>   I am looking for a sponsor for my package "manticore"
>     dget -x https://mentors.debian.net/debian/pool/main/m/manticore/manticore_2.7.3.dsc

As time of writing (Mon Oct 29 20:44:20 UTC 2018), I see following
issues with package on mentors:

 * Since this package is not debian-specific, and have its own release
   process, package must be foreign (with -1 revision), not native.
 * I have no idea what -DDISTR_BUILD=jessie means, but it looks
   suspicious. New packages are built in sid environment, which in
   future will become stretch release.
 * compat=11 implies --parallel. No need to mention it in `debian/rules'
 * Policy version is old. Current is 4.2.1
 * You claim compat=11, but build-depends on debhelper >= 10. You'd
   better use new style: build-depends on `debhelper-compat (=11)' and
   remove `debian/compat'. See debhelper(7)
 * Maintainer could be a mailing list, but upload is always done by
   human, who is mentioned in `debian/changelog'.
 * Your build system tries to download dependencies. It is wrong. You
   have to declare dependencies in `debian/control' and make sure that
   build success without network access. `unshare -rn' could be of use,
   as more complex sbuild/pbuild solutions.

I will stop here for now.

--
Best regards, Dmitry Bogatov, a Debian Developer.

Note, that I fetch/send email at most once every 24 hours. In case of
emergency, use Signal (+7 985 316 75 70) to message/call.

Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Adrian Nuta
Hi Dmitry, 

 * Since this package is not debian-specific, and have its own release
   process, package must be foreign (with -1 revision), not native. 
changed to 1.0, not sure if this is correct 
* You claim compat=11, but build-depends on debhelper >= 10. You'd
   better use new style: build-depends on `debhelper-compat (=11)' and
   remove `debian/compat'. See debhelper(7) 
 did that, but now I see 'No compatibility level set!' in mentors lintian. 
On DDISTR_BUILD -  our cmake  build to different targets,  now in rules it will be DDISTR_BUILD=$(lsb_release -i -s ).
Fixed the dependencies, their are not downloaded anymore.
Changed uploader in changelog.

Thanks


On Tue, Oct 30, 2018 at 10:10 PM Dmitry Bogatov <[hidden email]> wrote:

[2018-10-29 09:39] Manticore Search Maintainers <[hidden email]>
>   I am looking for a sponsor for my package "manticore"
>     dget -x https://mentors.debian.net/debian/pool/main/m/manticore/manticore_2.7.3.dsc

As time of writing (Mon Oct 29 20:44:20 UTC 2018), I see following
issues with package on mentors:

 * Since this package is not debian-specific, and have its own release
   process, package must be foreign (with -1 revision), not native.
 * I have no idea what -DDISTR_BUILD=jessie means, but it looks
   suspicious. New packages are built in sid environment, which in
   future will become stretch release.
 * compat=11 implies --parallel. No need to mention it in `debian/rules'
 * Policy version is old. Current is 4.2.1
 * You claim compat=11, but build-depends on debhelper >= 10. You'd
   better use new style: build-depends on `debhelper-compat (=11)' and
   remove `debian/compat'. See debhelper(7)
 * Maintainer could be a mailing list, but upload is always done by
   human, who is mentioned in `debian/changelog'.
 * Your build system tries to download dependencies. It is wrong. You
   have to declare dependencies in `debian/control' and make sure that
   build success without network access. `unshare -rn' could be of use,
   as more complex sbuild/pbuild solutions.

I will stop here for now.

--
Best regards, Dmitry Bogatov, a Debian Developer.

Note, that I fetch/send email at most once every 24 hours. In case of
emergency, use Signal (+7 985 316 75 70) to message/call.


--
Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

[ Top posting is discouraged ]


[2018-11-27 21:11] Adrian Nuta <[hidden email]>
>  * Since this package is not debian-specific, and have its own release
>    process, package must be foreign (with -1 revision), not native.
> changed to 1.0, not sure if this is correct

No. Source format 1.0 is long deprecated. You want to use 3.0 (quilt).

And, by the way, where is the source of debianization?

While not strictly mandatory, Vcs-* fields are very useful. I suggest
git, obliviously.

Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Adrian Nuta
Hi,
Switched to quilt, but I don't understand why mentor lintian says "No compatibility level set!"
Thanks
Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

[2018-12-07 16:39] Adrian Nuta <[hidden email]>
> Switched to quilt, but I don't understand why mentor lintian says "No
> compatibility level set!"

Can you please remind, where are git sources of your package?

I could be that mentor lintian is old and does not recognize

        Build-Depends: debhelper-compat (= 11)

Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Adrian Nuta

Right now I have debhelper (>= 11), but previous used debhelper-compat (= 11), same message.
Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

[2018-12-09 23:03] Adrian Nuta <[hidden email]>
> Hi, git repo is at https://github.com/manticoresoftware/manticoresearch.
>
> Right now I have debhelper (>= 11), but previous used debhelper-compat (=
> 11), same message.

[ Comments below are about commit 0f016406 ---
  remote HEAD at time of writing ]

Can't help about debhelper, because I failed to find .orig.tar.gz.
You have neither `debian/watch' nor `upstream' branch. I suggest you

 * add `debian/watch' file (very desirable)
 * take a look at `git-buildpackage' manual. Just one of many tools,
   but very fine tool, IMHO.

In mean time,

 * debian/control indented strangely. Maybe wrap-and-sort(1) from devscripts?

 * there is no point in such overrides:

        override_dh_auto_build:
                dh_auto_build

   overrides are used when you want to perform some actions before/after
   default, provided by debhelper.

  * Using output of `lsb_release' in CPP flags could be issue for
    reproducibility. Is it strictly necessary?

Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Adrian Nuta
 * there is no point in such overrides:
        override_dh_auto_build:
                dh_auto_build
 understood

  * Using output of `lsb_release' in CPP flags could be issue for
    reproducibility. Is it strictly necessary?
 
That flag is for our cmake to know on which distro is (the output of that command involving lsb_release should be  'debian' )  -  we already have it setup to build for several distros, but need to tell him on which he is.
I saw others use lsb_release output in control for similar job. I'm open to suggestions.

Thanks


Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

[2018-12-10 22:13] Adrian Nuta <[hidden email]>
>   * Using output of `lsb_release' in CPP flags could be issue for
> >     reproducibility. Is it strictly necessary?
> >
>
> That flag is for our cmake to know on which distro is (the output of that
> command involving lsb_release should be  'debian' )  -  we already have it
> setup to build for several distros, but need to tell him on which he is.
> I saw others use lsb_release output in control for similar job. I'm open to
> suggestions.

(Debian hat) Fine.

(Programmer hat) Why build system need to know, which distro it is build
on?  I guess (did not check sources) you actually interested in
something more specific, then name of distribution (my
linux-from-scratch installation does not have name, for example).

Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Adrian Nuta

(Programmer hat) Why build system need to know, which distro it is build
on?  I guess (did not check sources) you actually interested in
something more specific, then name of distribution (my
linux-from-scratch installation does not have name, for example).

Yes, name of distribution (although now for current Debians there is one target 'debian', but e.g. for ubuntu we have special target for trusty to use upstart instead of systemd).
Added a debian/watch, not sure why mentor lintian doesn't see it, uscan doesn't report any error, it should get our official tar.gz release for github.

Fixed the overrides and indentation.



Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

> Added a debian/watch, not sure why mentor lintian doesn't see it, uscan
> doesn't report any error, it should get our official tar.gz release for
> github.

You run `lintian -EvIL +pedantic', don't you? Missing `debian/watch'
considered low-severity issue

> Fixed the overrides and indentation.

Nice. It builds. I found at least following issues.

 * no manpage for wordbreaker. You will not pass NEW without it.
 * whitespace errors in debian/rules, debian/copyright, ...
 * missing years in some entries in debian/copyright
 * your documentation should be in /usr/share/doc/manticore, not MANTICORE
 * I believe you install not all available documentation. You may want
   to create bin:manticore-doc for it.
 * I doubt usefullness for end-user of internal-coding-standard.txt
 * lists in descriptions in `debian/control' are usually indented
   by one space
 * `manticore' system user seems to not get removed on package purge
 * What is the point of 'foo || exit $?' construct with `set -e' set?
 * chown manticore:manticore /etc/sphinxsearch is strage. Files in /etc
   are not meant to be edited by someone, but root. Ideally, you should
   assume /etc is mounted read-only.
 * What are relations with bin:sphinxsearch? Are they co-installable?

I will stop here for now. I am sorry to see you use analytics. Your
right as upstream, sure, but it must not appear in html files, provided
by debian.

Also, I remind you that new packages have only one changelog entry, with
revision -1 and single line "Initial release (Closes: #ITP-number)"

Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Adrian Nuta
Uploaded a new version.
You run `lintian -EvIL +pedantic', don't you? Missing `debian/watch'
considered low-severity issue
Didn't knew about these switches, I'll use that from now on.  

 * no manpage for wordbreaker. You will not pass NEW without it.
 * whitespace errors in debian/rules, debian/copyright, ...
 * missing years in some entries in debian/copyright
done 
 * your documentation should be in /usr/share/doc/manticore, not MANTICORE
removed that folder (not sure why cmake was using uppercased name)
 * I believe you install not all available documentation. You may want
   to create bin:manticore-doc for it.
We don't have a text version of the documentation and it's pretty large. Not sure how would make sense to include it in package when it's online.
 * I doubt usefullness for end-user of internal-coding-standard.txt
Took out 
  * chown manticore:manticore /etc/sphinxsearch is strage. Files in /etc
   are not meant to be edited by someone, but root. Ideally, you should
   assume /etc is mounted read-only.
 * What are relations with bin:sphinxsearch? Are they co-installable?
About these ... there's a big omission I've made: manticore is a replacement for sphinxsearch 
(mantictore is a fork from last OSS version of sphinx, the current sphinxsearch is some kind of free binary only ).
I added Replace and  Break in control file.
The reason /etc/sphinxsearch is chowned in case user switch to manticore (we use different folders for log and data, but kept same config file path). 
 
I will stop here for now. I am sorry to see you use analytics. Your
right as upstream, sure, but it must not appear in html files, provided
by debian.
Which file(s)? none of the files in deb package should have that. Several .md files have that indeed.
If this is a problem (source files), let me know ... I'll see what I can do.

One question about debian/watch: when checking, is the orig.tar.gz uploaded on mentors used or the version from watch? 
Because right now the upstream release doesn't include many of the fixes (they will be all on next one)
Reply | Threaded
Open this post in threaded view
|

Bug#912201: RFS: manticore/2.7.3 [ITP]

Dmitry Bogatov-3

[2018-12-19 15:41] Adrian Nuta <[hidden email]>
> >  * your documentation should be in /usr/share/doc/manticore, not MANTICORE
> >
> removed that folder (not sure why cmake was using uppercased name)
>
> >  * I believe you install not all available documentation. You may want
> >    to create bin:manticore-doc for it.
> >
> We don't have a text version of the documentation and it's pretty large.
> Not sure how would make sense to include it in package when it's online.

HTML local documentation is fine too.

Including it has a lot of sense. It brings convenience -- not everybody
has fast (>= 1Mb/sec) access to Internet and privacy -- local
documentation do not have trackers and access.log.

>  * chown manticore:manticore /etc/sphinxsearch is strage. Files in /etc
>
> >    are not meant to be edited by someone, but root. Ideally, you should
> >    assume /etc is mounted read-only.
> >  * What are relations with bin:sphinxsearch? Are they co-installable?
> >
> About these ... there's a big omission I've made: manticore is a
> replacement for sphinxsearch
> (mantictore is a fork from last OSS version of sphinx, the current
> sphinxsearch is some kind of free binary only).

I believe in this case you'd better coordinate your work with maintainer
of bin:sphinxsearch, Radu Spineanu <[hidden email]>. He would be much
more compenent sponsor in your case. Added him in Cc.

> I added Replace and  Break in control file.
> The reason /etc/sphinxsearch is chowned in case user switch to manticore
> (we use different folders for log and data, but kept same config file
> path).

I foresee issues when user installs manticore, and after that try to
install sphixsearch. You definitely need to coordinate.

> One question about debian/watch: when checking, is the orig.tar.gz
> uploaded on mentors used or the version from watch?  Because right now
> the upstream release doesn't include many of the fixes (they will be
> all on next one)

uscan downloads what is written in `debian/watch'. In your case it would
be github release. If it is incomplete, they you have to make it
complete :)