[needs packaging] Please upload seeks to Ubuntu Precise

[Nicolas DERIVE]

Please upload seeks to Ubuntu Precise (not already in Debian). It's an opensource websearch engine and it would be great to have it in our upcoming LTS.

Please look at the following:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589037

and the DSC file:

https://launchpad.net/~kalon33/+archive/ppa/+files/seeks_0.4.0-8%2Bgit201201042102-0ubuntu1.dsc

[Nicolas DERIVE (kalon33)]

Subscribe ubuntu-sponsors as advised by dholbach.

[Nicolas DERIVE (kalon33)]

versioning scheme of the package in my PPA is done in order to superseede current PPA versioning.

[Stefano Rivera (stefanor)]

Looks like that Debian ITP is pretty dead. Would you consider taking it over and maintaing seeks in Debian?

[Brian Murray (brian-murray)]

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

[Nicolas DERIVE (kalon33)]

Hi, If useful, sure I can maintain seeks in Debian too :)

[Nicolas DERIVE (kalon33)]

@stefanor: what protocol should I follow to do this? Does that mean that I have to submit it to Debian before it gets into Ubuntu? Or could we process it independently in parallel in order to get this in Precise?

[Stefano Rivera (stefanor)]

In general, we prefer new packages to go through Debian. But as there's a Feature Freeze looming, that probably couldn't be done in time for precise. So, while I'd still like to see it in Debian, I'm happy to look at uploading it straight to Ubuntu, with the promise that it'll eventually end up in Debian :)

Some review (ok, mostly questions):
* Why are we picking some random snapshot, rather than the 0.4.0 stable release?
* bzr-builder.manifest? Was this a daily build?
* That's a very odd version number for an initial release. Why the epoch? Is that because of upsteram's debs? What verisons are they using?
* What is seeks-experimental?
* A wrap-and-sort wouldmake the Build-Depends a lot prettier and more manageable
* The description ends with a blank line
* The description's bullited list only needs to be indented two spaces.
* The description has lots of trailing whitespace
* It's generally not necessary to talk about being open source in the description. The ubuntu archive is almost entirely open source :)
* wishlist: have a look at DEP5, it's a nice machine-readable format for copyright files.
* NEWS is empty. Do we really want to include it in the binary packages?
* COPYING is redundant, that's what debian/copyright is for. No need to include it in the binary packages.
* Deleting users in maintainer scripts is frowned upon, see http://bugs.debian.org/621833
* Why are we skipping dh_auto_test?
* Urgh, the init and maintainer scripts mix tabs and spaces.
* Note: I also haven't given them (the scripts) a thorough review...
* And I haven't reviewed the binaries.

For Debian, take ownership of the RFP bug and retitle it to an ITP. Then follow the Mentors process for sponsorship. I'd offer sponsorship, but it's a non-trivial package, so I can't make any guarantees.
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage
http://wiki.debian.org/Mentors/BTS

[Nicolas DERIVE (kalon33)]

Hi stefanor,

* Why are we picking some random snapshot, rather than the 0.4.0 stable release?
-> It's the last snapshot from the stable branch, it contains fixes for bugs, like google results retrieving, p2p fixes..

* bzr-builder.manifest? Was this a daily build?
-> Yes, I took the package from my daily build recipe, and edit packaging from it. Should I change some things relating to this?

* That's a very odd version number for an initial release. Why the epoch? Is that because of upsteram's debs? What verisons are they using?
->The versioning scheme is done in order to superseede other PPA builds (mine and from others). It's OK if you want to suggest something prettier and better.

* What is seeks-experimental?
->It's the experimental branch of seeks, which is packaged in another PPA.

* A wrap-and-sort wouldmake the Build-Depends a lot prettier and more manageable
-> No problem for changing it.

* The description ends with a blank line
-> Same as previous point.

* The description's bullited list only needs to be indented two spaces.
-> Same as previous point.
* The description has lots of trailing whitespace
-> Same as previous point.

* It's generally not necessary to talk about being open source in the description. The ubuntu archive is almost entirely open source :)
-> Same as previous point.
* wishlist: have a look at DEP5, it's a nice machine-readable format for copyright files.
-> Will try to look at it.

* NEWS is empty. Do we really want to include it in the binary packages?
-> Sure, let's delete it

* COPYING is redundant, that's what debian/copyright is for. No need to include it in the binary packages.
-> Same as previous point.

* Deleting users in maintainer scripts is frowned upon, see http://bugs.debian.org/621833
-> Do you have a tip for me to deal with this better?

* Why are we skipping dh_auto_test?
-> I don't remember the real reason. Let's do them again.

* Urgh, the init and maintainer scripts mix tabs and spaces.
-> I will fix this too.

Should I change some other things? How do you want me to post the relevant changes and attach them here?

Thanks for your review. Have a nice day.

[Stefano Rivera (stefanor)]

Hi Nicolas (2012.02.14_14:54:52_+0200)
> * Why are we picking some random snapshot, rather than the 0.4.0 stable release?
> -> It's the last snapshot from the stable branch, it contains fixes for bugs, like google results retrieving, p2p fixes..

Does that mean that they don't do point releases? Or that the last
stable release has significant issues?

Would we end up going with the latest stable branch commit on every
upload?

> * bzr-builder.manifest? Was this a daily build?
> -> Yes, I took the package from my daily build recipe, and edit packaging from it. Should I change some things relating to this?

Dump it, it's not useful.

> * That's a very odd version number for an initial release. Why the epoch? Is that because of upsteram's debs? What verisons are they using?
> ->The versioning scheme is done in order to superseede other PPA builds (mine and from others). It's OK if you want to suggest something prettier and better.

I suggest not bumping the epoch. There are many PPAs out there,
containing lots of things we have in the archive. We can't have epoch
fights with all of them :)

> * What is seeks-experimental?
> ->It's the experimental branch of seeks, which is packaged in another PPA.

Ok, sensible enough to conflict against that, I guess.

> * Deleting users in maintainer scripts is frowned upon, see http://bugs.debian.org/621833
> -> Do you have a tip for me to deal with this better?

Yeah, just leave the user behind.

> Should I change some other things? How do you want me to post the
> relevant changes and attach them here?

A bzr packaging branch, or an upload to debian mentors / REVU would make it
easy to review changes.

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  H: [phone] C: [phone] UCT: x3127

[Nicolas DERIVE (kalon33)]

> Does that mean that they don't do point releases? Or that the last
> stable release has significant issues?

They do point releases (0.4.0 is the last one) but they commit bug fixes regularly to stable branch, without adding new features, until a new release is out. Here are the changes sinces the release to give you an idea:

689. By Emmanuel Benazera <email address hidden> on 2012-02-13

    fixed google parser to cope with changes in google output
688. By Emmanuel Benazera <email address hidden> on 2012-01-11

    fixed the rendering of recent and suggested queries (refs #649)
687. By Pablo Joubert <email address hidden> on 2012-01-11

    changed link to opensearch file, du to a bug caused by the new api
686. By Emmanuel Benazera <email address hidden> on 2011-12-11

    fixed bug in radius computed for fetched P2P recommended records, introduced along with optional stop words in cf
685. By Emmanuel Benazera <email address hidden> on 2011-12-01

    fixed missing exception thrown after missing ref snippet is detected (+ turned sort into stable_sort) (refs #643)
684. By Emmanuel Benazera <email address hidden> on 2011-12-01

    added missing cgi-error-plugin template to makefile for installation

So what do you think about the snapshot?

Thanks.

[Stefano Rivera (stefanor)]

Hi Nicolas (2012.02.14_15:55:22_+0200)
> So what do you think about the snapshot?

Depends on how important you think the bug fixes are, and how much
instability they introduce.

The important ones could be cherry-picked as quilt patches, or even
all applied via a quilt patch (the pythonX.Y packages do this).

But if the orig tarball is small enough, and the stable branch is
reliable enough, a snopshot at every upload, isn't a bad way to go.

I'll stop nitpicking that now :)

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  H: [phone] C: [phone] UCT: x3127

[Nicolas DERIVE (kalon33)]

Hi stefanor,

I linked the branch with updated packaging to the branch. Is this good for you?

But with latest Precise, we got a new opencv version and I ran into troubles. I had to add some build-deps which were previously indirect build deps of seeks (the easy part), but I now have problems with gtest in the package. Whereas they are explicitly disabled in configure, I had to add libgtest-dev to b-d to fix build but now they seem to run though, and make the build failing. I don't know how to solve this, it didn't happen before... and it had to happen on the last time before the freeze, preventing the package to enter Ubuntu archive :(

Do you have an idea on how to fix this?

Thanks a lot for your help.

[Nicolas DERIVE (kalon33)]

https://launchpadlibrarian.net/93024612/buildlog_ubuntu-precise-i386.seeks_0.4.0%2Bgit201201042104-0ubuntu1%2Bppa12.04%2B3_FAILEDTOBUILD.txt.gz is the buildlog of the building of the last revision (4) of the bzr branch attached to the bug (only the package version number is different, due to multiple builds in PPA)

[Stefano Rivera (stefanor)]

Sorry, I didn't have time to look at this today, and I'd want another Ubuntu developer to look over it too (we require two Ubuntu dev ACKs for new packages). It's a leaf package so a feature freeze exception should be easy to organise. In fact, if we're doing that, let's get it into Debian first.

--no-as-needed isn't ideal. Can we not fix the route cause?

It'd be nice to have a get-packaged-orig-source rule to generate the git snapshot tarball

Lintian raises a few issues.

[Daniel Holbach (dholbach)]

These two lintian warnings are not so important:

W: seeks: extra-license-file usr/share/doc/seeks/COPYING.gz
E: seeks: helper-templates-in-copyright

This one here looks a bit more important:
E: seeks: init.d-script-missing-dependency-on-remote_fs etc/init.d/seeks: required-start
N:
N: The given init script seems to refer to /usr, possibly using a file or
N: binary from there. Without a dependency on $remote_fs in Required-Start
N: or Required-Stop, as appropriate, the init script might be run before
N: /usr is mounted or after it's unmounted.
N:
N: Using Should-Start or Should-Stop to declare the dependency is
N: conceptually incorrect since the $remote_fs facility is always
N: available. Required-Start or Required-Stop should be used instead. Also,
N: please note that $all should not be used in Required-Stop, only
N: Required-Start.
N:
N: Refer to http://wiki.debian.org/LSBInitScripts for details.

[Daniel Holbach (dholbach)]

I'll unsubscribe the sponsors team for now, please resubscribe when ready.