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#898007: RFS: edenmath.app/1.1.1a-8
Package: sponsorship-requests Severity: normal Dear mentors, I'm looking for a sponsor for my package "edenmath.app". * Package name: edenmath.app Version : 1.1.1a-8 Upstream Author : Chad Armstrong , Rob Burns * URL : http://www.eskimo.com/~pburns/EdenMath/ * License : GPL-2+ Section : math It builds this binary package: edenmath.app - Scientific calculator for GNUstep To access further information about this package, please visit the following URL: https://mentors.debian.net/package/edenmath.app Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/edenmath.app/edenmath.app_1.1.1a-8.dsc Git repository: https://salsa.debian.org/gnustep-team/edenmath.app Changes since the last upload: * debian/compat: Bump to 11. * debian/source/format: New file, set to 3.0 (quilt). * GNUmakefile: Move local modifications... * debian/patches/include-help.patch: ...here. * debian/patches/series: New file. * debian/rules: Rewrite for modern dh. Move Resources to /usr/share. Enable hardening. Do not use gs_make (Closes: #897622). (override_dh_compress): Exclude .rtf files. * debian/maintscript: New file, handle the dir to symlink switch. * debian/control: Run wrap-and-sort -ast for diff-friendliness. (Uploaders): Remove Hubert on his request; add myself. (Build-Depends): Bump debhelper to >= 11. Drop ancient libgnustep-gui-dev version constraint. Require gnustep-make >= 2.7.0-3 for the optim variable definition. (Vcs-Git, Vcs-Browser): New fields. (Standards-Version): Compliant with 4.1.4 as of this release. (Description): Mention the original app. * debian/changelog: Whitespace cleanup. * debian/lintian-override: * debian/menu: * debian/dirs: Delete; no longer necessary. * debian/install: New file; install the .desktop file. * debian/EdenMath.desktop: Remove invalid Version key, add Keywords, set Icon to the real file in /usr/share. * debian/watch: New file. * debian/copyright: Rewrite in format 1.0.
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#897969: closing 897969
close 897969 thanks Uploaded. One adjustment: Use pkgkde-symbolshelper(1) to refresh symbols here. For upcoming uploads, a joint utilization of getbuildlog(1) and pkgkde-symbolshelper(1) might be a better plan. -- Regards, Boyuan Yang
Re: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)
Mattia Rizzolo wrote: > On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote: > > Andreas Tille wrote: > > > What's the correct way to fix the symbols file to work with both > > > versions of gcc? > > > > Don't use symbols files for C++ libraries? > > Please do not advocate nor recommend such pointless stands. Symbols files are not mandatory; it's up to the maintainer whether to use them or not. If the maintainer's judgment is that the burden outweighs the benefit, then so be it -- there is nothing wrong in that. What makes me feel uneasy is that the standard way of maintaining symbols files involves abusing the Debian infrastructure. It was unthinkable 10-15 years ago to upload a package knowing in advance that it would definitely FTBFS at least on certain architectures. That's common practice nowadays and some of the slow arches are suffering from it. > Yes, many C++ libraries do a very horrible job at ABI maintenance > that for them maintaining a symbols file is impossible. They are probably hard to maintain as proper public shared libraries, with symbols files or not. > No, it's not impossible to maintain a symbols file for a C++ > library. I didn't say it is impossible. > Guess what, C++ is more complex than C. Undoubtedly.
Bug#897969: RFS: dtkcore/2.0.8-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dtkcore" * Package name: dtkcore Version : 2.0.8-1 Upstream Author : Deepin Technology Co., Ltd. * URL : https://github.com/linuxdeepin/dtkcore * License : GPL-3+ Section : libs It builds those binary packages: libdtkcore-bin - Deepin Tool Kit Core library (utilities) libdtkcore-dev - Deepin Tool Kit Core library (development files) libdtkcore2 - Deepin Tool Kit Core library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dtkcore Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dtkcore/dtkcore_2.0.8-1.dsc More information about hello can be obtained from https://salsa.debian.org/pkg-deepin-team/dtkcore Changes since the last upload: * New upstream release. * Refresh symbols. * d/libdtkcore-dev.install: Remove /usr/lib/*/libdtk/modules/* . -- Yanhao Mo signature.asc Description: PGP signature
Bug#896714: RFS: cavestory-nx/1.0.0-1 [ITP] -- NXEngine is a Cave Story game engine clone
Control: tags -1 moreinfo Hi Carlos, Some general remarks: Please do not open new RFS bugs for new versions of your package if the previous one has not been sponsored. Reopen the bug, retitle it appropiatly and send the RFS to the old bug please. (that this is something I've told you already earlier.) Now let's review cavestory-nx: Debian-Packaging: - There is a wrapper script in /usr/share/games calling /usr/share/games/cavestory-nx which is a symlink to ../../../lib/games/cavestory-nx/cavestory-nx This feels quite wrong... - Can't the executable not installed to /usr/share/games/ directly? - as you're upstream, please include the manpage also there, so that other distributions will benefit from it more easily. - you can also use the file d/clean for cleaning, sparing you of the override of dh_auto_clean. - There seems to bean embedded code copy of nlohmann-json. - That means also that your d/copyright is incomplete. Please make sure to go over _every_ file to ensure that d/copyright is accurate. There are tools like licensecheck or license-reconsile to aid you with this. Others / ITP related / Project related. - there is a Readme.txt on the game assests stating that this is free software but there is no license text attached. As "free" is ambiguous, Can you please elaborate the source where you've got the data from? I've only found some data file at the original authors website, but it is lacking this Readme.txt. (I can't find the rationale why you say it is Public Domain) - as you've seem have to forked from nxegine-evo [1], can you go a bit into the reasons of your fork. As far as I can see the changes are minor, to the level of fixing spelling errors in comments and variable names. [1] https://github.com/nxengine/nxengine-evo (I'm BCC'ing the ITP as the "Others" sections would actually belong there, but I do not want to join those threads (therefore BCC) -- tobi
Bug#897964: RFS: uriparser/0.8.5-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "uriparser" Package name: uriparser Version : 0.8.5-1 Upstream Author : Sebastian Pipping URL : https://github.com/uriparser/uriparser License : BSD-3-clause, LGPL-2.1+, GPL-3+ Section : libs It builds those binary packages: liburiparser-dev - development files for uriparser liburiparser-doc - documentation files for uriparser liburiparser1 - URI parsing library compliant with RFC 3986 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/uriparser Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/uriparser/uriparser_0.8.5-1.dsc or from git: https://anonscm.debian.org/cgit/collab-maint/uriparser.git?h=release%2Fdebian%2F0.8.5-1 Changes since the last upload: * New upstream release (Closes: #893316). - Refresh symbols file. - Refresh debian/copyright. - Rewrite debian/upstream/metadata. * Remove trailing whitespaces: - debian/changelog - debian/control - debian/rules * Migrate to debhelper 11: - Change debian/compat to 11. - Bump minimum debhelper version in debian/control to >= 11. - Remove dh-autoreconf from Build-Depends. * Declare compliance with Debian Policy 4.1.4 (No changes needed). * Change to my new email address: - debian/control - debian/copyright * New README.source to explain the branching model used. * debian/rules: - Switch to $(DEB_UPSTREAM_VERSION). Regards, Jörg Frings-Fürst - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlrtbuoACgkQCfifPIyh 0l0/cxAA1Oe6PA3W4p/YuftMYYxjuCurHWrJOU4iK/351G2L1DSY6mCOdhqdBp8a gFHX+jzIPv10SNnY+Z34/DZUCMhr+ocd4jT678h0ECuclz9OLaKu6Hk3elh+mRUH Mhnk1e94jPhFhFdZwZ1Kv2HyklhNONIqvDNu/8vgrC7ZJhXvT/x1DaPVAI1jov5B r9pWQqEjkBLLbli9Jp0btO6oW7pEOgIGGxnxo1FLqcWTNTciGrPWviPpzk95OO8y l16xfNR+Sur88tcR3PYrrF9rUzrupUCt/j4ZUG8jN+lCzsgej5NcYtb8GgttIU29 NGxZd/jVp1n2m5MRaj3WMEV1PA6FiTN+q3DQ3YT2kgmwVK6Qwq8Lqfrh3IW8gzGe z+KnkwOo9k8BqdD4w9ak/lgIUi+pKnJf6xQKH3OddpBJJRcEphf1o00/+TZEiAtY TeaAqKSh6+ix4lBb6wG+VFqq+aHvIUK9v8o64Y63q9VTo9cfR9g72IVRtH2kYUCy y+AiGA94LlI+NcyiIqBpme9bZ95HynsfkEMyFTNUVqYrkLdXRIbp+e/Qlmd7V+0E BMxS7+xF+eYyTWo37rhX6I7edZRrk1lS0yMML1w60QfP+f49rM7Zj/8KzSuCcmRm kKHNX+bHCaL3bUZX5MKLjE3SR2C3ABIjrteO3ujark4S2becDUQ= =5qDG -END PGP SIGNATURE-
Bug#897957: RFS: deepin-movie-reborn/3.2.4-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "deepin-movie-reborn" * Package name: deepin-movie-reborn Version : 3.2.4-1 Upstream Author : Deepin Technology Co., Ltd. * URL : https://github.com/linuxdeepin/deepin-movie-reborn * License : GPL-3+ Section : video It builds those binary packages: deepin-movie - Deepin movie player libdmr-dev - Deepin movie player - widget library (development files) libdmr0.1 - Deepin movie player - widget library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/deepin-movie-reborn Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/deepin-movie-reborn/deepin-movie-reborn_3.2.4-1.dsc More information about hello can be obtained from https://salsa.debian.org/pkg-deepin-team/deepin-movie-reborn Changes since the last upload: * New upstream release. * d/control: add uploader Yanhao Mo * d/control: change maintainer field back to pkg-deepin-de...@lists.alioth.debian.org -- Yanhao Mo signature.asc Description: PGP signature
