Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hi Dmitry, Thanks for the update! On Fri, Aug 31, 2018 at 03:41:01PM +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > I've uploaded new 1.19.0.2-1 version to mentors.d.o. > I've added manpages, fixed copyright info, fixed alternatives > and enabled auto-tests. Could you please review it? Build-dependency libibverbs-dev is missing. It failed to build from source because the linker cannot find -libverbs After adding that dependency I tried to build again however it ended up with a test failure. (also see the appendix part of this mail) http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.2-1/buildlog > сб, 2 июн. 2018 г. в 7:08, Lumin : > > > > On Sat, Jun 02, 2018 at 03:24:07AM +, Lumin wrote: > > > Please fix the aforementioned problems. Hopefully we'll have the last > > > round of check next time. Thank you for working on this. > > > > > > [1] > > > http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog > > > > Forgot to check the copyright ... The copyright looks incomplete. A > > simple search on the source tree would reveal many non-Linaro copyright > > holders: > > > > grep -ri copyright | grep -vi linaro | grep -i copyright > > > > The package will be rejected by ftp-master if we don't fix the > > copyright. > > Should be fixed now. Oops, you may have missed my second mail. The copyright file could be simpler by merging similar paragraphs into one instead one paragraph per file. A template can be generated with the following command: licensecheck -r --deb-machine . Which will automatically merge paragraphs. > > grep -ri copyright | grep -vi linaro | grep -i copyright ^ And I use this command for double-checking the copyright. Apart from that, these lintian complains should be fixed: I: odp source: wildcard-matches-nothing-in-dep5-copyright platform/linux-generic/odp_hash.c (paragraph at line 101) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_check_compile_flag.m4 (paragraph at line 219) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_compiler_vendor.m4 (paragraph at line 224) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_compiler_version.m4 (paragraph at line 229) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_pthread.m4 (paragraph at line 237) I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 101 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 109 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 219 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 224 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 229 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 237 > > When checking odp-dpdk, one more problem was found: > > > > root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config > > libodp-linux.so-x86_64-linux-gnu > > There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu > > (providing /usr/lib/x86_64-linux-gnu/libodp-linux.so). > > > > SelectionPath > > Priority Status > > > > * 0/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 > >auto mode > > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so 40 > >manual mode > > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 > >manual mode > > > > > > * 0/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 > > 60auto mode > > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 > > 60manual mode > > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119 > > 40manual mode > > > > Taking BLAS as an example, the generic and slow libblas3 provides > > libblas.so.3 symlink with a priority of 10. Faster implementations > > provides the same symlink with higher priorities, e.g. 40 for openblas. > > > > Maybe you want to adjust the priority values in those postinst scripts? > > The exact value is up to you, as long as it helps to tell the difference > > among different implementations. > > I'll fix odp-dpdk later. It's good as long as all odp-generic packages are assigned with the same priority, and odp-dpdk with a higher one. > -- > With best wishes > Dmitry > Appendix FAIL: scheduler/scheduler_main == odp_ishm.c:936:_odp_ishm_reserve():No huge pages, fall back to normal pages. check: /proc/sys/vm/nr_hugepages. Queue config: queue_basic.max_queue_size: 8192 queue_basic.default_queue_size: 4096 Using scheduler 'basic' Scheduler config: sched_basic.prio_spread: 4 PKTIO: initialized loop interface. PKTIO: initialized dpdk pktio, use export ODP_PKTIO_DISABLE_DPDK=1 to disable. PKTIO: initialized pcap i
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hello, I've uploaded new 1.19.0.2-1 version to mentors.d.o. I've added manpages, fixed copyright info, fixed alternatives and enabled auto-tests. Could you please review it? сб, 2 июн. 2018 г. в 7:08, Lumin : > > On Sat, Jun 02, 2018 at 03:24:07AM +, Lumin wrote: > > Please fix the aforementioned problems. Hopefully we'll have the last > > round of check next time. Thank you for working on this. > > > > [1] > > http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog > > Forgot to check the copyright ... The copyright looks incomplete. A > simple search on the source tree would reveal many non-Linaro copyright > holders: > > grep -ri copyright | grep -vi linaro | grep -i copyright > > The package will be rejected by ftp-master if we don't fix the > copyright. Should be fixed now. > > When checking odp-dpdk, one more problem was found: > > root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config > libodp-linux.so-x86_64-linux-gnu > There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu > (providing /usr/lib/x86_64-linux-gnu/libodp-linux.so). > > SelectionPath > Priority Status > > * 0/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 > auto mode > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so 40 > manual mode > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 > manual mode > > > * 0/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 > 60auto mode > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 > 60manual mode > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119 > 40manual mode > > Taking BLAS as an example, the generic and slow libblas3 provides > libblas.so.3 symlink with a priority of 10. Faster implementations > provides the same symlink with higher priorities, e.g. 40 for openblas. > > Maybe you want to adjust the priority values in those postinst scripts? > The exact value is up to you, as long as it helps to tell the difference > among different implementations. I'll fix odp-dpdk later. -- With best wishes Dmitry
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
On Sat, Jun 02, 2018 at 03:24:07AM +, Lumin wrote: > Please fix the aforementioned problems. Hopefully we'll have the last > round of check next time. Thank you for working on this. > > [1] > http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog Forgot to check the copyright ... The copyright looks incomplete. A simple search on the source tree would reveal many non-Linaro copyright holders: grep -ri copyright | grep -vi linaro | grep -i copyright The package will be rejected by ftp-master if we don't fix the copyright. When checking odp-dpdk, one more problem was found: root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config libodp-linux.so-x86_64-linux-gnu There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libodp-linux.so). SelectionPath Priority Status * 0/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 auto mode 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so 40 manual mode 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 manual mode * 0/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 60 auto mode 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 60 manual mode 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119 40 manual mode Taking BLAS as an example, the generic and slow libblas3 provides libblas.so.3 symlink with a priority of 10. Faster implementations provides the same symlink with higher priorities, e.g. 40 for openblas. Maybe you want to adjust the priority values in those postinst scripts? The exact value is up to you, as long as it helps to tell the difference among different implementations.
Bug#896970: Info received (Bug#896970: RFS: odp/1.19.0.0-1 [ITP])
Forgot to check the copyright ... The copyright looks incomplete. A simple search on the source tree would reveal many non-Linaro copyright holders: grep -ri copyright | grep -vi linaro | grep -i copyright The package will be rejected by ftp-master if we don't fix the copyright.
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
On Wed, May 30, 2018 at 01:40:48PM +0300, Dmitry Eremin-Solenikov wrote: > > 1. README.Debian > >"Library packages should contain libodp-linux.so.FOO" > >It should be "libodp-linux.so.SOVER", which is more precise. > > Hmm. I have checked buster package lists. Only blas/lapack packages > use soname as virtual package name in provides. The rest of packages > use libsomethingSOVER. Wouldn't it be logical to stick to convention > used by the rest of packages? I checked the Packages.gz file under the dist directory of the archive. It seems that the reason why BLAS/LAPACK has taken the virtual package name "libblas.so.3" is due to ambiguity of libblas3, which could be a real package and a virtual package following that convention at the same time. Providing libodp-linux119 and libodp-linux-dev looks good to me. > New packages are uploaded to mentors.d.n. Hopefully with this upload > I will have just two remaining issues: > - manpages > - dh_auto_test override. If they are to be fixed in the future uploads, please at least override the missing-manpage lintian warning, prepending a comment to it. The empty override_dh_auto_test should have a proper comment too. > I plan to look onto adding package autotests afterwards. With those tests the package would be better. The present package looks good to me[1], except for: 1. [optional] debian/rules: please wrap long lines to 80 characters. 2. [error] libodp-generic119.prerm.in: update-alternatives --remove \ /usr/lib/@DEB_HOST_MULTIARCH@/libodp-linux.so.@ODP_SOVERSION@ \ libodp-linux.so.@ODP_SOVERSION@-@DEB_HOST_MULTIARCH@ \ /usr/lib/@DEB_HOST_MULTIARCH@/odp-generic/libodp-linux.so.@ODP_SOVERSION@ This is causing a removal failure: http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/piuparts Please fix the aforementioned problems. Hopefully we'll have the last round of check next time. Thank you for working on this. [1] http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog signature.asc Description: PGP signature
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hello, Thank for your review. 2018-05-25 9:31 GMT+03:00 Lumin : > On Wed, May 23, 2018 at 07:50:57PM +0300, Dmitry Eremin-Solenikov wrote: >> Hello, >> >> I have updated odp & odp-dpdk packages on mentors.d.n. > > Please file another RFS bug for the odp-dpdk package since it is a > different source. Sure, filled #900407. >> 2018-05-06 3:56 GMT+03:00 Dmitry Eremin-Solenikov : >> > I will make my next upload use alternatives, thank you. >> >> This upload uses alternatives to select ODP library to be used. > > The package is going in the right way, but the alternatives still needs > to be improved. Thanks. I've updated -dev packages to also use alternatives. > Nitpickings about the updated package: > > 1. README.Debian >"Library packages should contain libodp-linux.so.FOO" >It should be "libodp-linux.so.SOVER", which is more precise. Hmm. I have checked buster package lists. Only blas/lapack packages use soname as virtual package name in provides. The rest of packages use libsomethingSOVER. Wouldn't it be logical to stick to convention used by the rest of packages? > 2. command `dot` comes from graphviz, but it is missing from B-D. Ack, fixed. > > 3. libodp-generic119 should provide libodp-linux.so.119 instead of >libodp-linux119. And applications that need libodp-linux.so.119 >could declare Depends: libodp-linux.so.119 | libodp-generic119 . > >This is similar to libblas.so.3 | libblas3 setting of the BLAS >implementations. See above. > 4. libodp-generic-dev should Privides: libodp-linux.so . >odp-generic/libodp-linux.so should be registered in the alternatives >system to provide a /usr/lib/DEB_HOST_MULTIARCH/libodp-linux.so . > >The static library /usr/lib/x86_64-linux-gnu/libodp-linux.a should >be put to the /.../odp-generic directory, and be registered as a slave >of the libodp-linux.so alternative. > >I also noticed that the symlink points to an invalid path. >Please solve this issue by the alternatives system as said above. > >root@bfb95763d3d6 ~/odp-1.19.0.1# ll > /usr/lib/x86_64-linux-gnu/libodp-linux.so >lrwxrwxrwx 1 root root 23 May 23 16:01 > /usr/lib/x86_64-linux-gnu/libodp-linux.so -> libodp-linux.so.119.0.1 > > libblas3 and libopenblas-base and their corresponding -dev packages are > good examples at this point. If you have doubts, you can carefully > examine these packages which may possibly provide help. I have fixed alternatives usage for -dev packages (and removed Conflicts entry in d/contron and README.Debian files). > Please ping me if you have question, or ready for the next round of > review :-) New packages are uploaded to mentors.d.n. Hopefully with this upload I will have just two remaining issues: - manpages - dh_auto_test override. I plan to look onto adding package autotests afterwards. -- With best wishes Dmitry
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
On Wed, May 23, 2018 at 07:50:57PM +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > I have updated odp & odp-dpdk packages on mentors.d.n. Please file another RFS bug for the odp-dpdk package since it is a different source. > 2018-05-06 3:56 GMT+03:00 Dmitry Eremin-Solenikov : > > I will make my next upload use alternatives, thank you. > > This upload uses alternatives to select ODP library to be used. The package is going in the right way, but the alternatives still needs to be improved. > >> * move all the executables to /usr/bin. Their name starts with odp_, so > >> I don't expect them to pollute the public name space. Putting these > >> test programs in a private directory just makes it hard to find and > >> use them. > > > > This looks logical to me. I will move some (usefull) programs to /usr/bin > > and will drop the rest of them. > > I have moved several executables to /usr/bin and removed the rest of them. > > This upload does not have manpages for those binaries, I will fix that in > the next upload. Reasonable. > >>> > 11. Why is dh_auto_test overrode to empty? > >>> > >>> We had issues with make check before, they interacted strangely with > >>> build environment, that is why it is disabled for now. I plan to > >>> reenable it later. > >> > >> How strange is it? And what happend during the test? > >> > >> As per policy, network access during the build is not availble. If this > >> is the cause of test problem, we can omit the test part. However, we > >> should still write the tests in the override_dh_auto_test target, if our > >> user want to test it somehow. > > > > Some of the validation scripts are trying to create/remove network > > interfaces. > > > >> override_dh_auto_test: > >> -test_binary > >> > >> This should be ok. > > > > Ack > > This is not fixed yet. Also will be fixed in the next upload. OK. Once you have managed to add working tests, adding autopkgtest test cases is recommended. Debian's infrastructure will run these tests regularly to make sure there is no problem that are easy to detect. > Could you please review alternatives system, so that I can be sure that > I've used them correctly? > > -- > With best wishes > Dmitry Nitpickings about the updated package: 1. README.Debian "Library packages should contain libodp-linux.so.FOO" It should be "libodp-linux.so.SOVER", which is more precise. 2. command `dot` comes from graphviz, but it is missing from B-D. 3. libodp-generic119 should provide libodp-linux.so.119 instead of libodp-linux119. And applications that need libodp-linux.so.119 could declare Depends: libodp-linux.so.119 | libodp-generic119 . This is similar to libblas.so.3 | libblas3 setting of the BLAS implementations. 4. libodp-generic-dev should Privides: libodp-linux.so . odp-generic/libodp-linux.so should be registered in the alternatives system to provide a /usr/lib/DEB_HOST_MULTIARCH/libodp-linux.so . The static library /usr/lib/x86_64-linux-gnu/libodp-linux.a should be put to the /.../odp-generic directory, and be registered as a slave of the libodp-linux.so alternative. I also noticed that the symlink points to an invalid path. Please solve this issue by the alternatives system as said above. root@bfb95763d3d6 ~/odp-1.19.0.1# ll /usr/lib/x86_64-linux-gnu/libodp-linux.so lrwxrwxrwx 1 root root 23 May 23 16:01 /usr/lib/x86_64-linux-gnu/libodp-linux.so -> libodp-linux.so.119.0.1 libblas3 and libopenblas-base and their corresponding -dev packages are good examples at this point. If you have doubts, you can carefully examine these packages which may possibly provide help. Please ping me if you have question, or ready for the next round of review :-) signature.asc Description: PGP signature
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hello, I have updated odp & odp-dpdk packages on mentors.d.n. 2018-05-06 3:56 GMT+03:00 Dmitry Eremin-Solenikov : > I will make my next upload use alternatives, thank you. This upload uses alternatives to select ODP library to be used. >> * move all the executables to /usr/bin. Their name starts with odp_, so >> I don't expect them to pollute the public name space. Putting these >> test programs in a private directory just makes it hard to find and >> use them. > > This looks logical to me. I will move some (usefull) programs to /usr/bin > and will drop the rest of them. I have moved several executables to /usr/bin and removed the rest of them. This upload does not have manpages for those binaries, I will fix that in the next upload. >>> > 11. Why is dh_auto_test overrode to empty? >>> >>> We had issues with make check before, they interacted strangely with >>> build environment, that is why it is disabled for now. I plan to >>> reenable it later. >> >> How strange is it? And what happend during the test? >> >> As per policy, network access during the build is not availble. If this >> is the cause of test problem, we can omit the test part. However, we >> should still write the tests in the override_dh_auto_test target, if our >> user want to test it somehow. > > Some of the validation scripts are trying to create/remove network > interfaces. > >> override_dh_auto_test: >> -test_binary >> >> This should be ok. > > Ack This is not fixed yet. Also will be fixed in the next upload. Could you please review alternatives system, so that I can be sure that I've used them correctly? -- With best wishes Dmitry
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hello, 2018-05-05 16:47 GMT+03:00 Lumin : > On Sat, Apr 28, 2018 at 01:58:26PM +0300, Dmitry Eremin-Solenikov wrote: >> > 5. Could you explain why these lines exist? Package libodp-linux-dev >> > seems not exist. >> >> Packages libodp-linux-dev and libodp-linux119 are virtual package, >> provided by different implementations of ODP API. We are providing >> another ODP implementation, implemented specifically on top of DPDK >> (https://github.com/Linaro/odp-dpdk). It is not packaged (yet). These >> two implementations are binary compatible. It is planned that odp-dpdk >> will have libodp-dpdk119 (Provides: libodp-linux119) and libodp-dpdk-dev >> (Provides: libodp-linux-dev) packages. >> >> Would you recommend how should I better document and/or implement these >> packages. > > How many libodp-linux.so.119 providers are there? It is not known yet. For previous long term support release we had more than 6 providers. Not all of them are going to be packaged/provided through Debian, as they were provided by hardware vendors. > If there are only a few alternatives, why should we make a virtual > package, whose SOVERSION might bump regularly? From the policy we can > find a list of authoritative virtual packages: > > https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > > All of these packages are widely used and be depended by a lot of > packages. If the list of libodp-linux.so.* providers is short, we can > write the Depends field of an application package like this: > > Depends: libodp-implement1 | libodp-impl2 | ..., > > where there is no virtual package. Unfortunately it is not easy to predict in advance, which libraries/implementations will be provided (and when). I will make my next upload use alternatives, thank you. > By doing so you will get rid of the 'package-name-doesnt-match-sonames' > warning, and be able to keep several implementations at the same time. > This situation must be better for your next package. > > To implement this, you first need to rename libodp-linux.so.* to match > your package name. Then write some postinst and prerm scripts. Here is a > good example: > > > https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.postinst.in > > https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.prerm.in > > By looking around in the openblas packaging you'll also find the example > for -dev package. Quite interesting, thank for the pointer. The idea of generating these scripts during build time didn't occur to me before. >> libodp-test-utils? These tools are mostly testing programs, that can be >> used either by autotests (in future) or users (to check that their ODP >> installation works). > > odp-linux-tools: > > -rwxr-xr-x root/root 31016 2018-04-28 14:48 > ./usr/lib/odp/linux/examples/odp_l3fwd > -rwxr-xr-x root/root 18504 2018-04-28 14:48 > ./usr/lib/odp/linux/examples/odp_pktio > > This still look weird. The convention is that -utils/-tools packages > would install executable binaries under /usr/bin (or /usr/sbin in some > cases). I think either of the two solutions will do > > * move all the executables to /usr/bin. Their name starts with odp_, so > I don't expect them to pollute the public name space. Putting these > test programs in a private directory just makes it hard to find and > use them. This looks logical to me. I will move some (usefull) programs to /usr/bin and will drop the rest of them. >> > 11. Why is dh_auto_test overrode to empty? >> >> We had issues with make check before, they interacted strangely with >> build environment, that is why it is disabled for now. I plan to >> reenable it later. > > How strange is it? And what happend during the test? > > As per policy, network access during the build is not availble. If this > is the cause of test problem, we can omit the test part. However, we > should still write the tests in the override_dh_auto_test target, if our > user want to test it somehow. Some of the validation scripts are trying to create/remove network interfaces. > override_dh_auto_test: > -test_binary > > This should be ok. Ack -- With best wishes Dmitry
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
On Sat, Apr 28, 2018 at 01:58:26PM +0300, Dmitry Eremin-Solenikov wrote: > > 5. Could you explain why these lines exist? Package libodp-linux-dev > > seems not exist. > > Packages libodp-linux-dev and libodp-linux119 are virtual package, > provided by different implementations of ODP API. We are providing > another ODP implementation, implemented specifically on top of DPDK > (https://github.com/Linaro/odp-dpdk). It is not packaged (yet). These > two implementations are binary compatible. It is planned that odp-dpdk > will have libodp-dpdk119 (Provides: libodp-linux119) and libodp-dpdk-dev > (Provides: libodp-linux-dev) packages. > > Would you recommend how should I better document and/or implement these > packages. How many libodp-linux.so.119 providers are there? If there are only a few alternatives, why should we make a virtual package, whose SOVERSION might bump regularly? From the policy we can find a list of authoritative virtual packages: https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt All of these packages are widely used and be depended by a lot of packages. If the list of libodp-linux.so.* providers is short, we can write the Depends field of an application package like this: Depends: libodp-implement1 | libodp-impl2 | ..., where there is no virtual package. According to your current debian/control, it seems that there can be only one libodp-linux119 provider existing on system at the same time. I'd really suggest to fix it before uploading, because you planed to upload another implementation. I think you have just written a better solution in the TODO file, i.e. to use the alternative mechanism. Note that, a package contains libodp-linux implementation can leave the Provides: fields blank, and actually providing symlinks via the alternative system. For example: libodp-generic119: contains libodp-generic.so.119, which is symlinked to libodp-linux.so.119 via alternatives system. libodp-dpdk119: contains libodp-dpdk.so.119, which is symlinked to libodp-linux.so.119 via alternatives system. No package provides a real libodp-linux.so.119 library. By doing so you will get rid of the 'package-name-doesnt-match-sonames' warning, and be able to keep several implementations at the same time. This situation must be better for your next package. To implement this, you first need to rename libodp-linux.so.* to match your package name. Then write some postinst and prerm scripts. Here is a good example: https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.postinst.in https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.prerm.in By looking around in the openblas packaging you'll also find the example for -dev package. > libodp-test-utils? These tools are mostly testing programs, that can be > used either by autotests (in future) or users (to check that their ODP > installation works). odp-linux-tools: -rwxr-xr-x root/root 31016 2018-04-28 14:48 ./usr/lib/odp/linux/examples/odp_l3fwd -rwxr-xr-x root/root 18504 2018-04-28 14:48 ./usr/lib/odp/linux/examples/odp_pktio This still look weird. The convention is that -utils/-tools packages would install executable binaries under /usr/bin (or /usr/sbin in some cases). I think either of the two solutions will do * move all the executables to /usr/bin. Their name starts with odp_, so I don't expect them to pollute the public name space. Putting these test programs in a private directory just makes it hard to find and use them. * provide a script to call all or some of these programs. But you still need to strip the "examples" substring from the path. User might want to find human-readable examples in the "examples" directory, but actually they will end up with a pile of binaries. > > 10. Why is the package containing > > ./usr/lib/x86_64-linux-gnu/libodp-linux.so.119.0.0 > > named libodp-generic119? If libodp-generic.so.119 provides alternative, the shared object can simply be renamed to libodp-generic.so.SOVERSION. > > 11. Why is dh_auto_test overrode to empty? > > We had issues with make check before, they interacted strangely with > build environment, that is why it is disabled for now. I plan to > reenable it later. How strange is it? And what happend during the test? As per policy, network access during the build is not availble. If this is the cause of test problem, we can omit the test part. However, we should still write the tests in the override_dh_auto_test target, if our user want to test it somehow. override_dh_auto_test: -test_binary This should be ok.
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hi Dimitry, I'm keeping an eye on the list and these bugs. I know that your package needs to be checked, but these days I'm a little busy dealing with real life work so that I postponed reviewing packages. I'll review and give you feedbacks in this weekend. On Thu, May 3, 2018 at 22:21 Dmitry Eremin-Solenikov wrote: > Package: sponsorship-requests > Followup-For: Bug #896970 > > Hi Lumin, > > I've updated ODP package on mentors.d.n, according to most of your > comments. Could you please review it? > > -- > With best wishes > Dmitry > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Best,
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Package: sponsorship-requests Followup-For: Bug #896970 Hi Lumin, I've updated ODP package on mentors.d.n, according to most of your comments. Could you please review it? -- With best wishes Dmitry -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Package: sponsorship-requests Followup-For: Bug #896970 For the reference I've uploaded a preview of ODP-DPDK 1.19.0.0 package to mentors.d.n. It features library and -dev packages, which provide libodp-linux119 and libodp-linux-dev packages. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Package: sponsorship-requests Followup-For: Bug #896970 Hi Lumin, I have uploaded next iteration of ODP package to mentors.d.n. It fixes all issues you have pointed out, except issues 5, 6, 10, 11. I'd like your advice wrt points 5 and 10 (we would like to keep virtual packages in place). For point 6 I'll consider installing less tools (and renaming a package). Where should I install them? Is /usr/bin fine from your point of view? I'm considering reenabling make check (point 11), however I haven't decided at this point. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Package: sponsorship-requests Followup-For: Bug #896970 > 1. This package misses dependency libconfig-dev Added. > 2. Please fix the lintian warnings. e.g. > > W: odp-doc: privacy-breach-generic I will try to. Privacy breaches come from generated documentation. > 3. debhelper compat level and the standards-version is a bit old. > The latest compat is 11, and standards-version is 4.1.4. > See debhelper(7) section COMPATIBILITY LEVELS for compat checklist. > See https://www.debian.org/doc/debian-policy/ for the standards upgrading > checklist. Ack > 4. Please break the lines whose length exceeds 80 characters in > debian/control and rules. Ack > 5. Could you explain why these lines exist? Package libodp-linux-dev > seems not exist. Packages libodp-linux-dev and libodp-linux119 are virtual package, provided by different implementations of ODP API. We are providing another ODP implementation, implemented specifically on top of DPDK (https://github.com/Linaro/odp-dpdk). It is not packaged (yet). These two implementations are binary compatible. It is planned that odp-dpdk will have libodp-dpdk119 (Provides: libodp-linux119) and libodp-dpdk-dev (Provides: libodp-linux-dev) packages. Would you recommend how should I better document and/or implement these packages. > 6. Must we provide a example package with pre-built binaries shipped? > > 77 Package: odp-linux-examples > >Why can't we put the source of these examples into the doc package? >Or why don't we choose a name such as libodp-tools / libodp-utils >to avoid ambiguity? libodp-test-utils? These tools are mostly testing programs, that can be used either by autotests (in future) or users (to check that their ODP installation works). > 7. your patch directory is empty, could you please remove it? Sure, removing > 8. Changelog: This is the first-time upload. Could you change the file > so that it looks like this: OK. I will upload updated package with shortened changelog. > 9. debian/docs This file looks useless ? Dropping now. > 10. Why is the package containing > ./usr/lib/x86_64-linux-gnu/libodp-linux.so.119.0.0 > named libodp-generic119? See point 5. > 11. Why is dh_auto_test overrode to empty? We had issues with make check before, they interacted strangely with build environment, that is why it is disabled for now. I plan to reenable it later. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
control: tag -1 +moreinfo
control: owner -1 !
Hi Dmitry,
Thank you for this package. Here are some problems found in your package:
1. This package misses dependency libconfig-dev
2. Please fix the lintian warnings. e.g.
W: odp-doc: privacy-breach-generic
3. debhelper compat level and the standards-version is a bit old.
The latest compat is 11, and standards-version is 4.1.4.
See debhelper(7) section COMPATIBILITY LEVELS for compat checklist.
See https://www.debian.org/doc/debian-policy/ for the standards upgrading
checklist.
4. Please break the lines whose length exceeds 80 characters in
debian/control and rules.
5. Could you explain why these lines exist? Package libodp-linux-dev
seems not exist.
43 Conflicts: libodp-linux-dev
44 Provides: libodp-linux-dev
also, package libodphelper-dev depends on the non-existing package.
53 Package: libodphelper-dev
54 Architecture: any
55 Section: libdevel
56 Depends: libodphelper119 (= ${binary:Version}),
57 libodp-linux-dev,
6. Must we provide a example package with pre-built binaries shipped?
77 Package: odp-linux-examples
Why can't we put the source of these examples into the doc package?
Or why don't we choose a name such as libodp-tools / libodp-utils
to avoid ambiguity?
7. your patch directory is empty, could you please remove it?
8. Changelog: This is the first-time upload. Could you change the file
so that it looks like this:
PACKAGE (VERSION) UNRELEASED; urgency=low
* Initial release. (Closes: #XX)
-- maintainer Thu, 26 Apr 2018 13:06:09 +
9. debian/docs This file looks useless ?
10. Why is the package containing
./usr/lib/x86_64-linux-gnu/libodp-linux.so.119.0.0
named libodp-generic119?
11. Why is dh_auto_test overrode to empty?
Please feel free to ask if you have any question about
the above points. And have a good day :-)
--
Best,
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist I am looking for a sponsor for my package "odp" * Package name: odp Version : 1.19.0.0-1 Upstream Author : Linaro / ODP community * URL : https://www.opendataplane.org/ * License : [fill in] Section : libs It builds those binary packages: libodp-common-dev - OpenDataPlane library (common development files) libodp-generic-dev - OpenDataPlane reference implementation library (development) libodp-generic119 - OpenDataPlane reference implementation library (runtime) libodphelper-dev - OpenDataPlane helper library (development) libodphelper119 - OpenDataPlane helper library (runtime) odp-doc- OpenDataPlane library (documentation) odp-linux-examples - OpenDataPlane examples To access further information about this package, please visit the following URL: https://mentors.debian.net/package/odp Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/odp/odp_1.19.0.0-1.dsc More information about odp can be obtained from https://www.opendataplane.org. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
