Re: leechcraft (closes ITP bug, 33 days have passed)
While I think this package is interesting, I do not intend to sponsor it. That said, here is a review of the source package: I'm not sure it is appropriate to change the ABI names used by upstream to a Debian-specific one. If you want to change the library names that should be done upstream. Please talk to upstream about how to make your patches unnecessary. Please add DEP-3 headers to your patches: http://dep.debian.net/deps/dep3/ qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. Some of the icons were created in Inkscape but the source code (SVG files) is missing. There are some pre-compressed audio files, I guess the preferred form for modification for those is missing and therefore we cannot distribute them since they are probably GPL licensed. In addition there is DFSG item 2. Your version number and your debian/rules get-orig-source do not indicate the reason for the tarball repacking. You can use wildcards in .install files like these: usr/share/leechcraft/translations/*/LC_MESSAGES/libeiskaltdcpp.mo usr/share/leechcraft/translations/leechcraft_poshuku_*.qm Some of the files have the incorrect FSF address in them, you might want to report that upstream. P: leechcraft source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5/ There are some .DS_Store files in the tarball, these are a waste of space, you might want to ask upstream to remove them. cppcheck finds some issues: qxmpp/src/QXmppTransferManager.cpp:423]: (error) Memory leak: buffer [src/plugins/azoth/plugins/metacontacts/managecontactsdialog.cpp:50]: (error) Possible null pointer dereference: entry - otherwise it is redundant to check if entry is null at line 53 [src/plugins/bittorrent/tabwidget.cpp:705]: (error) instance of Applier object destroyed immediately [src/plugins/bittorrent/tabwidget.cpp:715]: (error) instance of Applier object destroyed immediately [src/plugins/eiskaltdcpp/dcpp/PerFolderLimit.cpp:92]: (error) Possible null pointer dereference: message - otherwise it is redundant to check if message is null at line 84 ... I stopped it that this point but there might be more issues. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gp72t93qe8cdc0a2lagvkldjwdo2imv9zrkavcozp...@mail.gmail.com
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, Boris Pek tehnic...@yandex.ru writes: I am looking for a sponsor for my package leechcraft. I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2sty6evjcj@bistromathics.mathi.uni-heidelberg.de
Re: leechcraft (closes ITP bug, 33 days have passed)
While I think this package is interesting, I do not intend to sponsor it. Thanks a lot for such detailed review! And for possibility to practice in English. =) That said, here is a review of the source package: I'm not sure it is appropriate to change the ABI names used by upstream to a Debian-specific one. If you want to change the library names that should be done upstream. Please talk to upstream about how to make your patches unnecessary. I have talked a lot with main upstream developer. It was our common conclusion that I will maintain such patches special for Debian and Ubuntu. Please add DEP-3 headers to your patches: http://dep.debian.net/deps/dep3/ Is it really necessary? I can make it if yes. But these patches are trivial... And they are under the same copyright as debian/ directory. qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. You are really mistaken at this point. Maybe you have read my description inattentive or I have write it not enough clean. So I should explain here... * qxmpp package already exist in Debian. But it is absolutely not suitable for leechcraft. Leechcraft authors have made a lot of patches which are not included in upstream of qxmpp project. Some patches they (upstream) applied but not all. More over qxmpp is the static library. And nobody uses patched version of qxmpp except leechcraft project. So it should not be moved into separate package. * eiskaltdcpp package already exist in Debian. But it is another project with own binaries. Its authors have made special modification for leechcraft project (it also includes a lot of patches). And this modification is now just usual leechcraft plugin. It can't be used separately. So them should not be splitted. * etc... All these files were carefully described in suitable sections of debian/copyright file. And I don't see any reason to break current structure of the package. Some of the icons were created in Inkscape but the source code (SVG files) is missing. I haven't sighted it. What files are you talking about? I'll ask in upstream. There are some pre-compressed audio files, I guess the preferred form for modification for those is missing and therefore we cannot distribute them since they are probably GPL licensed. In addition there is DFSG item 2. What files are you talking about? And what's the problem with pre-compressed audio files? I am not sure that understood you correctly. Your version number and your debian/rules get-orig-source do not indicate the reason for the tarball repacking. But it is described in debian/copyright: https://github.com/tehnick/leechcraft-debian/blob/master/debian/copyright#L6 Non-free content and unnecessary files were removed from tarball. And yes, I have read Best Packaging Practices section in the Debian Developer's Reference. But these unnecessary files are not using anywhere and staying in repository due to historical or other reasons. I can described reasons for each deleted file or directory if you want. So it was our common decision with upstream developers to remove them from tarball in Debian. You can use wildcards in .install files like these: usr/share/leechcraft/translations/*/LC_MESSAGES/libeiskaltdcpp.mo usr/share/leechcraft/translations/leechcraft_poshuku_*.qm Hmm, I use wildcards. Maybe I have missed it somewhere. Some of the files have the incorrect FSF address in them, you might want to report that upstream. I had already sent suitable patches to upstream and they were applied in upstream git repository. So next stable release will be clean from this point. But this can't cause to not upload the package in Debian. So we don't need to wait next release. P: leechcraft source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5/ I use last actual version of this document. There are some .DS_Store files in the tarball, these are a waste of space, you might want to ask upstream to remove them. Already done some time ago. And files already removed from the git repository. So next stable release will be clean from this point. But this also can't cause to not upload the package in Debian. So we don't need to wait next release... cppcheck finds some issues: qxmpp/src/QXmppTransferManager.cpp:423]: (error) Memory leak: buffer [src/plugins/azoth/plugins/metacontacts/managecontactsdialog.cpp:50]: (error) Possible null pointer dereference: entry - otherwise it is redundant to check if entry is null at line 53 [src/plugins/bittorrent/tabwidget.cpp:705]: (error) instance of Applier object destroyed immediately [src/plugins/bittorrent/tabwidget.cpp:715]: (error) instance of Applier object destroyed immediately [src/plugins/eiskaltdcpp/dcpp/PerFolderLimit.cpp:92]: (error) Possible null pointer dereference:
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? The short answer: yes, it is. Here I can cite the description from my first message: LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. I made separate packages for each plugin. So user will be able to install only those packages which he really need. This is the main idea of the project... LeechCraft is very flexible. Also not of all plugins are enabled now. So it will be more packages... You can compare it with KDE infrastructure: kdelibs + lot of programs. Best regards, Boris. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/421711320765...@web144.yandex.ru
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, Boris Pek tehnic...@yandex.ru writes: I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? The short answer: yes, it is. Here I can cite the description from my first message: LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. I made separate packages for each plugin. So user will be able to install only those packages which he really need. This is the main idea of the project... LeechCraft is very flexible. This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Regards, Ansgar [1] https://launchpadlibrarian.net/84683703/buildlog_ubuntu-precise-i386.leechcraft-unstable_0.4.90-670-g4cccdc3-0ppa1~precise1_BUILDING.txt.gz -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lirqldfd@deep-thought.43-1.org
Re: leechcraft (closes ITP bug, 33 days have passed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Boris, On 08.11.2011 15:58, Boris Pek wrote: qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. You are really mistaken at this point. Maybe you have read my description inattentive or I have write it not enough clean. So I should explain here... ... All these files were carefully described in suitable sections of debian/copyright file. And I don't see any reason to break current structure of the package. I'm sorry, but our policy is very clear on this point. Please refer to §4.13 [1] for some more background. While it is not a strict must requirement for every case, there are very good reasons to avoid embedded code copies whenever possible. I'd consider your case as when possible which makes it somewhat unlikely to find a sponsor for it as is, which would upload your package. Note, some popular packages aren't part of Debian for this very same reason. Think of xbmc for example [2]. We, as a distribution have to be very careful when embedding libraries and third party applications into a package. You can happily do that upstream if the respective licenses allow that, but such a package is not maintainable in a distribution for the general public. Think of security updates, transitions and other updates and we didn't even talk about the waste of space yet. That's especially true for you, who are embedding regular packages into your binary package which works fine for ... well a lot of reverse dependencies. If it does not work for you as is with your upstream source, well, I'd expect the problem to be with it rather on your side. [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469397 - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOuXxEAAoJEMcrUe6dgPNtQX4QAIWAtali7SBRti9j/8r/g8eA kygbHuYMNBCpkfq6VtJJUNITygWgCn/Fj0+bKM7phOWkcoK6xTkbGJB9k2OZYTkz wnkTci7EehJj+DTOgS3oyNDtzGI/9wV5gSuV7SoeXk5UK6wkk+Wu1U4YwYDbfdvJ kkcdKDhAZOxihjqii82Lq4HsosLyUytvosJV8khtvzttZ6YC3skju2QjRZzVLvuE 0BakI+CuG3NZivRRKdeeQ1cRxCTYWoVWS0fo47i1X1sRscHslhxfr8kwICJB03Yk 3ZtKtYetlGFoZydK8NOuZcW+PXs3MrEaRiX2P4Z9OVzS0BOmA2m0MMJa4s8a4cD+ W/bTFyGFwQDjLs/wDSmUnSizC+Q+6uQ4YzQR7FxfAc3CCnQ1RFlvoGJH5krAMdi7 v8x85YavjqeE013XB/RpE1KXcMfDrI0YAqiaf2vp2uXoweDKv09hDFbWcnfwQTS4 eOfW1xONuQpy32o+KeB47JF/sXhEbST+gL1iYxIVJ86UKjILT3gQIjocRCMmKRLY 9gXsI+6AOgWG9FiFBHI57XQ6SUO/DXi6Je9UhyP/M09QcckZdfXmsVXjjZP9sdWd TGkhD7n5C60Hl3iJBLx8xFBHdcmr9nGw2FOZygMtJqpb3wV3xlTwD/XEE/KvS+Qp m+bLeXfKDPvd3b4+kSKI =2WZU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb97c44.8060...@toell.net
Re: leechcraft (closes ITP bug, 33 days have passed)
[...] You can use wildcards in .install files like these: [...] usr/share/leechcraft/translations/leechcraft_poshuku_*.qm [...] I have just found again the reason to not use it. Available wildcards are very primitive. And they will affect to sub-plugins. For example: usr/share/leechcraft/translations/leechcraft_poshuku_*.qm will also affect to sub-plugins: usr/share/leechcraft/translations/leechcraft_poshuku_ru.qm and usr/share/leechcraft/translations/leechcraft_poshuku_cleanweb_ru.qm which should be in different packages... Regards, Boris. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/366251320785...@web126.yandex.ru
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? The short answer: yes, it is. Here I can cite the description from my first message: LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. I made separate packages for each plugin. So user will be able to install only those packages which he really need. This is the main idea of the project... LeechCraft is very flexible. This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). Hmm, I have not thought about such an effect. It's bad news. I will think that can I do to decrease number of packages. This will damage general idea unfortunately but it is really more important. For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Yes, this is true. But its sub-plugins realise different communicating protocols. Of cause they can be disabled in settings dialog, users will not be able to remove unnecessary plugins completely. Also I will look to other similar software. Like kopete, pidgin, etc... [1] https://launchpadlibrarian.net/84683703/buildlog_ubuntu-precise-i386.leechcraft-unstable_0.4.90-670-g4cccdc3-0ppa1~precise1_BUILDING.txt.gz My PPA is really useful. It is nice. Regards, Boris. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/46651320787...@web113.yandex.ru
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. You are really mistaken at this point. Maybe you have read my description inattentive or I have write it not enough clean. So I should explain here... * qxmpp package already exist in Debian. But it is absolutely not suitable for leechcraft. Leechcraft authors have made a lot of patches which are not included in upstream of qxmpp project. Some patches they (upstream) applied but not all. More over qxmpp is the static library. And nobody uses patched version of qxmpp except leechcraft project. So it should not be moved into separate package. * eiskaltdcpp package already exist in Debian. But it is another project with own binaries. Its authors have made special modification for leechcraft project (it also includes a lot of patches). And this modification is now just usual leechcraft plugin. It can't be used separately. So them should not be splitted. * etc... All these files were carefully described in suitable sections of debian/copyright file. And I don't see any reason to break current structure of the package. I'm sorry, but our policy is very clear on this point. Please refer to §4.13 [1] for some more background. While it is not a strict must requirement for every case, there are very good reasons to avoid embedded code copies whenever possible. I'd consider your case as when possible which makes it somewhat unlikely to find a sponsor for it as is, which would upload your package. Please read my answers carefully before replying. I have a strong feeling that you just ignore my arguments. And that you want to throw my work into trash. Maybe you don't understand that these files are part of the project. They can't be cut from the project without destruction. Like a brick can't be moved from a wall without detrimental consequences. I can repeat my arguments in other words to make sure in common understanding between us. * qxmpp is a fork as you wish. It is the internal part of the project. Even if it is not included in original upstream tarball. * eiskaltdcpp is internal part of the project. It was produced specially for leechcraft by original authors. * miniupnpc is not used. It just present in tarball. Its license can't be cause of any problems. Plugin will use debian package miniupnpc from the main repo. Note, some popular packages aren't part of Debian for this very same reason. Think of xbmc for example [2]. Yes I know other examples. It doesn't matter. We, as a distribution have to be very careful when embedding libraries and third party applications into a package. You can happily do that upstream if the respective licenses allow that, but such a package is not maintainable in a distribution for the general public. Think of security updates, transitions and other updates and we didn't even talk about the waste of space yet. Please don't think that I am stupid or that I don't know basic principles of distribution of *nix systems. 1) You must agree that we are not talking about any system library. 2) We are talking about _internal_ library in the project. It is used only in this program and nowhere else. So where is no necessary to maintain it separately. 3) This library is not simple duplication of original sources from another library. This is completely another library now. 4) This is completely static library. It can't be updated in programs without their re-building. 5) Also we are talking about _internal_ plugin in the project. It can't be used in other way. Only in this program. And the last argument is that [1] is not strict rules but just recommendations which allow exceptions. That's especially true for you, who are embedding regular packages into your binary package which works fine for ... well a lot of reverse dependencies. If it does not work for you as is with your upstream source, well, I'd expect the problem to be with it rather on your side. Eh... You have absolutely ignored my description. This is not project fault that qxmpp upstream don't want integrate all their patches. They had to made a fork. In conclusion I want note that you shouldn't destroy anything without proposing possible solutions. Because this is way to nowhere. So have you any constructive recommendations which can be discussed?.. Finally please answer to my previous questions (from previous messages). It is important. In any case thanks for spending your time. Regards, Boris [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469397 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: leechcraft (closes ITP bug, 33 days have passed)
On Tue, 08 Nov 2011 23:23:06 +0200 Boris Pek tehnic...@yandex.ru wrote: This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). Hmm, I have not thought about such an effect. It's bad news. I will think that can I do to decrease number of packages. This will damage general idea unfortunately but it is really more important. For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Yes, this is true. But its sub-plugins realise different communicating protocols. Of cause they can be disabled in settings dialog, users will not be able to remove unnecessary plugins completely. Also I will look to other similar software. Like kopete, pidgin, etc... gstreamer is also distributed with many plugins per package. I think that approach has more advantages than disadvantages compared to one package per plugin. For users that want to use most of the plugins, having them in individual packages will waste more disc space in package overheads than they'll save by only having the plugins they need. And installing/upgrading many small packages takes longer than one large one. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2009010101.38ab6cfa@tiber
