On 02/06/14 12:25, Fredrik Roubert wrote: > On 27/05/14 15:59, tony mancill wrote: > >> * it has a build-dep on libre2-dev, which is currently only in >> experimental > > That's explained here: > > http://alioth.debian.org/scm/loggerhead/collab-maint/re2/trunk/view/head:/debian/README.Debian
Stefano, we are now at the point where another package needs to link against re2 - could you please make an upload to unstable or add any other comments about the situation? I tried building libre2 manually on wheezy, one of the test cases failed: obj/test/parse_test FAIL; Output: ................................re2/testing/parse_test.cc:214: Check failed: (string(tests[i].parse)) == (s)Regexp: \s parse: cc{0x9-0xd 0x20} s: cc{0x9-0xa 0xc-0xd 0x20} flag=1676 > > On Thu, May 29, 2014 at 8:43 PM, Daniel Pocock <dan...@pocock.com.au> wrote: > >> Fredrik indicated upstream would welcome improvement to the packaging >> files. > > Yes, just send code reviews to me. Or, if they're about the > CMakeLists.txt file, better to Philippe Liard > <philip.li...@gmail.com>, who actually knows CMake ... I've spent some time going over this. Here is my diff - you could just take my whole debian/* and dump it on top of yours (notice some files renamed/moved): https://github.com/dpocock/libphonenumber/tree/debian Rather than keeping this in debian/patches, you probably want to apply this directly in SVN, I think this is the fix for the issue Tony noticed with boost system: https://github.com/dpocock/libphonenumber/blob/debian/debian/patches/0001-add-boost-system.patch I also made an upload to mentors so it is easy for people to review visually: https://mentors.debian.net/package/libphonenumber Here are some things that need fixing in SVN: - the content that was in debian/changelog should be in a top-level ChangeLog file called changelog.txt - the debian/changelog file should only be changed when somebody does an upload to Debian, it only needs to mention things that change in the package (e.g. "New upstream version", or "initial release of JavaScript sub-package") - distribution of a source tarball - we can autogenerate source tarballs from the tags in the github mirror: https://github.com/libphonenumber/libphonenumber/releases or could somebody put source tarballs (without any binary JARs inside) in the Google Code download page? http://code.google.com/p/libphonenumber/downloads/list - remove binary JARs from SVN so they don't end up in the autogenerated source tree (see the lintian alerts on the mentors link to see the filenames) - the typos One thing stands out for me - the package numbering, e.g. libphonenumber5, libphonenumber6, ... The SONAME in the file appears correct: $ objdump -p ./cpp/build/libphonenumber.so | grep SONAME SONAME libphonenumber.so.6 If you change the ABI number regularly, then it will be hard to push updates to stable distributions (e.g. Debian stable, Ubuntu LTS, EPEL). Ideally, if updates are just data changes (to recognize new area codes and numbering plan changes) then they would be in some separate package that can be distributed through $(stable)-updates - just like anti-virus patterns, timezones, etc: https://lists.debian.org/debian-volatile-announce/2012/msg00000.html The binary ABI and the developer API would stay the same for a given Linux version. I don't want to deter you from adding new features or make it more tedious to support, but would it be possible to distribute the pattern data separately in such a manner? The other problem with the package name is that each time there is a new package name anywhere in the control file (e.g. a libphonenumber7 package) then the next upload to Debian will need to go in the FTP NEW queue for manual approval, that adds a delay of 1-4 weeks. If the package names haven't changed, then uploads to Debian (and propagation to Ubuntu) happen automatically within a few hours. Usually if this happens no more than once per year it is OK. If the version number is really significant, maybe the Java packages should also be named libphonenumber${VERSION}-java? Does anybody care either way? This source file: cpp/src/phonenumbers/test_metadata.cc changes during the build. If it is an auto-generated file, maybe it should not be in SVN at all as it will always be recreated when needed? There are various other files like this (*.cc) that are not in SVN. One thing I haven't look at yet is the JavaScript code - we should make a libjs-phonenumber.deb package containing that code too. I've done a first upload to the NEW queue today, there seems to be quite a backlog there so I thought it would be good to get it in the queue while we continue refining this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org