http://www.kannel.org/news.shtml#1.5.0 kannel-sqlbox has been merged into kannel proper in the addons directory. It appears the old (0.7.2) is not longer functional with kannel 1.5.0. It may be easiest to keep them as separate packages and just change kannel-sqlbox to use the same source tarball as kannel. Thanks! Reproducible: Always
It looks like the old builds have been removed from the kannel server. I'd integrate the ebuilds into 1 unified ebuild rather than 2.
I've updated the ebuild and placed it here: https://github.com/travisghansen/chaos/tree/master/app-mobilephone/kannel-sqlbox patches no longer necessary. I probably have syntax on deps wrong but maybe not :)
[QA] The mobile-phone herd has been dissolved to maintainer-needed due to absence. This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers
I would drop app-mobilephone/kannel-sqlbox and make app-mobilephone/kannel install that addon then :/
I'll proxy maintain.
(In reply to Travis Hansen from comment #5) > I'll proxy maintain. Are you referring to app-mobilephone/kannel package or this one?
(In reply to Pacho Ramos from comment #6) > (In reply to Travis Hansen from comment #5) > > I'll proxy maintain. > > Are you referring to app-mobilephone/kannel package or this one? Oops, I missed that. Is the plan then to combine this into the kannel ebuild or just drop it altogether?
If I don't miremember, all should live in kannel package
(In reply to Pacho Ramos from comment #8) > If I don't miremember, all should live in kannel package Well it's the same src tarball but a totally different build process. You can review the src uri etc.. https://github.com/travisghansen/chaos/blob/master/app-mobilephone/kannel-sqlbox/kannel-sqlbox-1.5.0.ebuild
Umm, then maybe it will be better to keep it splitted indeed. I will CC proxy-maintainers For now (regarding the ebuild): - Please try to use eapi5 http://devmanual.gentoo.org/ebuild-writing/eapi/index.html - openssl has two slots, but likely it requires one concrete one, please specify the right one in dependencies - Why do you need "LDFLAGS="""? - As a suggestion (it's not mandatory ;)), you maybe could rely on readme.gentoo-r1.eclass for replacing that elog messages and prevent people from always getting that messages every time they rebuild the package
(In reply to Pacho Ramos from comment #10) > Umm, then maybe it will be better to keep it splitted indeed. I will CC > proxy-maintainers I'm actually fine if this goes away (I'd prefer kannel remain in-tree however). I can just keep it in my overlay. I'm also happy to put the effort in and make it proxy-worthy if that's desired. Thanks for the consideration!
(In reply to Travis Hansen from comment #11) > (In reply to Pacho Ramos from comment #10) > > Umm, then maybe it will be better to keep it splitted indeed. I will CC > > proxy-maintainers > > I'm actually fine if this goes away (I'd prefer kannel remain in-tree > however). I can just keep it in my overlay. I'm also happy to put the > effort in and make it proxy-worthy if that's desired. I don't really know ifthere's a concrete answer to that. If y're willing to proxy maintain the package we will support you in doing so.
(In reply to Ian Delaney from comment #12) > I don't really know ifthere's a concrete answer to that. If y're willing to > proxy maintain the package we will support you in doing so. I'm happy to proxy maintain. 1.5.0 came out in 2010 so I doubt it will be much maintenance ;)
(In reply to Travis Hansen from comment #13) > (In reply to Ian Delaney from comment #12) > > I don't really know ifthere's a concrete answer to that. If y're willing to > > proxy maintain the package we will support you in doing so. > > I'm happy to proxy maintain. 1.5.0 came out in 2010 so I doubt it will be > much maintenance ;) To my understanding, you need submit an ebuild to bump it to 1.5.0 and its yours.
Created attachment 424582 [details] kannel-sqlbox-1.5.0.ebuild
Missing the init, but there's my ebuild from the repo.
commit 72a3b80e11bc56c4597a810cc374a2b4ea876ad3 Author: Ian Delaney <idella4@gentoo.org> Date: Sat Feb 6 15:23:05 2016 +0800 app-mobilephone/kannel-sqlbox: bump to vn. 1.5.0 package pmasked for a while by pacho, then offer by user Travis Hansen to proxy maintian the package. Bup to vn. 1.5.0 source from ebuild by him, added to metadata.xml accordingly, closes the gentoo bug Gentoo bug: 493712
(In reply to Pacho Ramos from comment #10) > Umm, then maybe it will be better to keep it splitted indeed. I will CC > proxy-maintainers > > For now (regarding the ebuild): > - Please try to use eapi5 > http://devmanual.gentoo.org/ebuild-writing/eapi/index.html > - openssl has two slots, but likely it requires one concrete one, please > specify the right one in dependencies > - Why do you need "LDFLAGS="""? > - As a suggestion (it's not mandatory ;)), you maybe could rely on > readme.gentoo-r1.eclass for replacing that elog messages and prevent people > from always getting that messages every time they rebuild the package All this problems are still there in final ebuild :/ readme.gentoo-r1.eclass is optional, but using eapi2 for a newly added ebuild, not specifying openssl slot and that strange overwritten of LDFLAGS need to be addressed :|
(In reply to Pacho Ramos from comment #18) > readme.gentoo-r1.eclass is optional, but using eapi2 for a newly added > ebuild, not specifying openssl slot and that strange overwritten of LDFLAGS > need to be addressed :| readme.gentoo-r1: done eapi: bumped to 5 openssl: fairly certain I've used it with both but I've added :0 LDFLAGS: appears to be something related to --as-needed, filtering just that out now. NOT TOUCHING LDFLAGS: checking for Ct-Lib support... checking for FreeTDS Ct-Lib support... checking for gw-config... /usr/bin/gw-config checking Kannel version... 1.5.0 checking Kannel libs... -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -ldl -lpam -lpcreposix -lrt -lresolv -lnsl -lm -luuid -lpthread -lxml2 -lz -lm -ldl -L/usr/lib64 -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -L/usr/lib64 -lmysqlclient_r -lpthread -lz -lm -lssl -lcrypto -ldl -L/usr/local/lib -lsqlite3 checking Kannel includes... -I/usr/include/kannel -O2 -march=native -pipe -fno-strict-aliasing -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -I/usr/include/uuid -D_LARGE_FILES= -I/usr/include/libxml2 -Wall -I/usr/include/openssl -I/usr/include/mysql checking for cfg_create in -lgwlib... no configure: error: Kannel gwlib is required! AS IS: checking for Ct-Lib support... checking for FreeTDS Ct-Lib support... checking for gw-config... /usr/bin/gw-config checking Kannel version... 1.5.0 checking Kannel libs... -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -ldl -lpam -lpcreposix -lrt -lresolv -lnsl -lm -luuid -lpthread -lxml2 -lz -lm -ldl -L/usr/lib64 -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -L/usr/lib64 -lmysqlclient_r -lpthread -lz -lm -lssl -lcrypto -ldl -L/usr/local/lib -lsqlite3 checking Kannel includes... -I/usr/include/kannel -O2 -march=native -pipe -fno-strict-aliasing -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -I/usr/include/uuid -D_LARGE_FILES= -I/usr/include/libxml2 -Wall -I/usr/include/openssl -I/usr/include/mysql checking for cfg_create in -lgwlib... yes checking for Kannel's DB support... configure: creating ./config.status Also it looks like the LICENSE should be updated for both this and just kannel (appears to be the same license although the sqlbox addon has a copy of it in the source addons/sqlbox/KannelLICENSE). The Kannel Software License, Version 1.0 What's the proper way to deal with that (I've added the file to dodoc)?
Created attachment 424878 [details] kannel-sqlbox-1.5.0-r1.ebuild
(In reply to Pacho Ramos from comment #18) > > All this problems are still there in final ebuild :/ > > readme.gentoo-r1.eclass is optional, but using eapi2 for a newly added > ebuild, not specifying openssl slot and that strange overwritten of LDFLAGS > need to be addressed :| k thx for further checking pacho License team please review the observation by T. Hansen "Also it looks like the LICENSE should be updated for both this and just kannel (appears to be the same license although the sqlbox addon has a copy of it in the source addons/sqlbox/KannelLICENSE)." Storing a copy of a license does not is not helpful and I will likely revert this.
(In reply to Ian Delaney from comment #21) > Storing a copy of a license does not is not helpful and I will likely revert > this. I'll revert that in my repo then when I update the LICENSE to whatever is appropriate then. I'll hold tight until I know how to move forward on that front. Thanks!
(In reply to Ian Delaney from comment #21) > License team please review the observation by T. Hansen > > "Also it looks like the LICENSE should be updated for both this and just > kannel (appears to be the same license although the sqlbox addon has a copy > of it in the source addons/sqlbox/KannelLICENSE)." AFAICS, kannel-1.5.0.ebuild and kannel-sqlbox-1.5.0.ebuild have LICENSE="Apache-1.1" and "Apache-1.1 GPL-2", respectively (GPL-2 for the init file, I suppose). This looks good to me. Why should it be updated? > Storing a copy of a license does not is not helpful and I will likely revert > this.
(In reply to Ulrich Müller from comment #23) > This looks good to me. Why should it be updated? The title of the LICENSE file in the source is: The Kannel Software License, Version 1.0 The same file is found in addons/sqlbox/KannelLICENSE I'm not sure where GPL-2 came from or apache for that matter. Presumably they both should have the same licenses I'd guess.
(In reply to Travis Hansen from comment #24) > (In reply to Ulrich Müller from comment #23) > > This looks good to me. Why should it be updated? > > The title of the LICENSE file in the source is: > > The Kannel Software License, Version 1.0 Yes, but its terms are identical (word for word) to Apache-1.1. We avoid having copies of the same license under different names.
I just see that the license issue was handled in bug 444848 previously.
(In reply to Ulrich Müller from comment #25) > Yes, but its terms are identical (word for word) to Apache-1.1. We avoid > having copies of the same license under different names. Ah! OK, is it common to put GPL-2 for init script? Should I leave as is or remove GPL-2 then?
(In reply to Travis Hansen from comment #27) > Ah! OK, is it common to put GPL-2 for init script? Should I leave as is or > remove GPL-2 then? Seems we have bugs for everything. :) Bug 425914 should answer your question.
(In reply to Ulrich Müller from comment #28) > Seems we have bugs for everything. :) Bug 425914 should answer your question. OK, I'll simply remove the license from dodoc then. That appears to be the only required change to what I currently have. Anything else? I'll create r2 and upload.
commit b785fa83cc5f909cdb4721096bf7d5126d0b2024 Author: Ian Delaney <idella4@gentoo.org> Date: Tue Feb 9 14:40:16 2016 +0800 app-mobilephone/kannel-sqlbox: revbump to 1.5.0-r1 fixing issues from bump update EPI, drop unused autotools eclass and inherit readme.gentoo-r1, set slot operator to openssl, fixes the gentoo bug, remove defunct 1.5.0 Gentoo bug: #493712
(In reply to Ian Delaney from comment #30) > update EPI, drop unused autotools eclass and inherit readme.gentoo-r1, > set slot operator to openssl, fixes the gentoo bug, remove defunct 1.5.0 Thanks! Did you want to leave KannelLICENSE in dodoc?
(In reply to Travis Hansen from comment #31) > Did you want to leave KannelLICENSE in dodoc? Removed.