This is a request to add jinzora, a media streamer, to portage. Reproducible: Always Steps to Reproduce:
http://www.jinzora.org
http://gentoo.mirror.at.stealer.net/portage_overlay/media-sound/jinzora/ I suggest that a web-apps herder takes a look over this too, adding web-apps@g.o to CC
Created attachment 42661 [details] /jinzora-1.1.ebuild used sven's ebuild to make a new one for version 1.1 I've tested it, and everything appears to work except it can't find the gd library. It's a minor bug though, as it just disables some image functions
Created attachment 42662 [details] postinstall-en.txt
The gd bug is no more, apparently I forgot to enable the gd use flag on mod_php. Everything works now perfectly.
Created attachment 57619 [details] jinzora-2.0.1_rc2.ebuild new ebuild for jinzora 2.0
Created attachment 57620 [details] postinstall-en.txt updated postinstall-en for jinzora 2.0
The above ebuild ('jinzora-2.0.1_rc2.ebuild') works flawlessly for jinzora-2.0.1. Can we get this into portage?
Created attachment 58308 [details] jinzora-2.0.1_rc2.ebuild * added use flag for encode (to use lame for resampling) * fixed binary location of lame to /usr/bin/lame * added jinzora's php.in recommendations
Created attachment 58309 [details] jinzora-2.0.1_rc2.ebuild * forgot to add encode to IUSE last time
Isn't jinzora 2.0.1 marked stable and not a release candidate anymore?
your right, just rename the file to jinzora-2.0.1.ebuild
Roger that...what is the status on this? Its working great for me.
works great for me as well.
Can we get a few more USE flags added, like postgres (support added in 2.1)? Is there any USE flag for mpd? I am one of the main developers of Jinzora and a Gentoo user to boot, so I would love to see this move into Portage and can probably maintain it although I haven't done much with ebuilds..
Created attachment 67127 [details] jinzora-2.2.1.ebuild I've updated the ebuild to 2.2 with the postgres useflag. I don't see anything in the docs about postgres, so I'm assuming it works with any version? What is mpd?
Created attachment 67128 [details] postinstall-en.txt
Request lighttpd and sqlite support be added to ebuild. User should choose either apache or lighttpd for install requirement.
I ran into this bug: http://www.jinzora.com/forums/viewtopic.php?t=2021&highlight=gentoo It seems to be Gentoo-specific as those are all the users that seem to run into this. It showed up on the forums several times. The fix in this post works. Everything else, worksforme. Maybe the ebuild should also run a sed for each of the supported executables and not just lame?
Also, the ebuild needs to make the apache user owner of the jinzora/frontend/frontends/*/settings.php files otherwise you can't change the front end settings from the web.
Created attachment 70519 [details] jinzora-2.2.1.ebuild I've added use flag for lighttpd and sqlite. I hope I'm doing the choice between apache and lighttpd correctly. Changing frontends seems to work for me without having to set the owner/group of frontends. Are you sure it's not working for you? I'm still looking into the bug about lame.
Actually, after playing around a little more with the frontends, it doesn't appear to be working for me. The thing though, setting the owner/group to apache for all frontends does hell.
oops. not "hell". i meant "doesn't help"
Looking through the code, it appears something is causing the escape of the first quote in " -S --silent --quiet -m j -b ". I'm wondering if it maybe a specific php version problem?
The problem isn't changing front ends, it's changing the settings in the front ends. For example: System Tools | Settings Manager | Front End Settings | Pick your front end Those settings are stored in: jinzora/frontend/frontends/*/settings.php If the httpd user doesn't own the settings.php files, it won't be able to write the settings. In fact, the code won't even display an Update button. The httpd user doesn't need to own the whole directory, just that settings.php like the settings.php that is in the jinzora root. (Unless we're looking at two different problems.)
Created attachment 70560 [details] postinstall-en.txt You're right. I've updated the postinstall to instruct the user update the owner/group of those frontend settings.php This issue should probably be made aware of upstream since the installation doesn't ask the frontend settings.php to be writable
Tom, thanks for adding lighttpd to the ebuild. Should it have "virtual/httpd- php" as part of the ebuild? http://article.gmane.org/gmane.linux.gentoo.devel/30050
Add ~ppc to ebuild
Created attachment 71224 [details] jinzora-2.2.1-r1.ebuild
I had problems setting up the sqlite db when trying to install this package. It looks like sqlite is broken with this release but has been fixed(almost) in later nightly releases. http://www.jinzora.org/forums/viewtopic.php? t=2479&highlight=sqlite for anybody having troubles
Created attachment 72683 [details] Jinzora 2.3 ebuild Update for 2.3. I commented out a part of src_install that I don't think is necessary. Are there any USE keywords for things like: MPD (for the jukebox) FLAC/Musepack/etc. (for resampling from those formats)?
Comment on attachment 72683 [details] Jinzora 2.3 ebuild ># Copy:right 1999-2004 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 ># $Header: $ > >inherit versionator webapp > >DESCRIPTION="Web-based media streamer, desgined to stream mp3s (or any streaming capbable media/video)" >HOMEPAGE="http://www.jinzora.org/" >MY_PV="$(get_version_component_range 1-3)" >SRC_URI="mirror://sourceforge/${PN}/j${MY_PV}.tar.gz" > >LICENSE="GPL-2" >KEYWORDS="~x86 ~ppc" >IUSE="encode gd lighttpd mysql postgres sqlite" > >DEPEND="|| ( > lighttpd? ( www-servers/lighttpd ) > >=net-www/apache-1.3 > ) > virtual/httpd-php > encode? ( media-sound/lame ) > gd? ( media-libs/gd ) > mysql? ( dev-db/mysql ) > postgres? ( dev-db/postgresql ) > sqlite? ( dev-db/sqlite )" > >MY_PV="$(get_major_version)" >S=${WORKDIR}/${PN}${MY_PV} > >src_unpack() { > unpack ${A} > cd ${S} > > # fix location of lame > for file in docs/english/lofi.html install/defaults.php; do > sed -i -e "s:/usr/local/bin/lame:/usr/bin/lame:g" ${file} > done >} > >src_install() { > webapp_src_preinst > > # install htdocs > touch ${S}/users.php ${S}/settings.php > cp -a . ${D}/${MY_HTDOCSDIR} > > webapp_postinst_txt en ${FILESDIR}/postinstall-en.txt > webapp_src_install >} > >pkg_postinst() { > einfo "Jinzora recommends the following settings for php (php.ini):" > einfo " max_execution_time = 1200" > einfo " memory_limit = 32M (or higher)" > einfo " post_max_size = 32M (or higher)" > einfo " file_uploads = 1 (on)" > einfo " upload_max_filesize = 32M (or higher)" > > webapp_pkg_postinst >}
Comment on attachment 72683 [details] Jinzora 2.3 ebuild ># Copy:right 1999-2004 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 ># $Header: $ > >inherit versionator webapp > >DESCRIPTION="Web-based media streamer, desgined to stream mp3s (or any streaming capbable media/video)" >HOMEPAGE="http://www.jinzora.org/" >MY_PV="$(get_version_component_range 1-3)" >SRC_URI="mirror://sourceforge/${PN}/j${MY_PV}.tar.gz" > >LICENSE="GPL-2" >KEYWORDS="~x86 ~ppc" >IUSE="encode gd lighttpd mysql postgres sqlite" > >DEPEND="|| ( > lighttpd? ( www-servers/lighttpd ) > >=net-www/apache-1.3 > ) > virtual/httpd-php > encode? ( media-sound/lame ) > gd? ( media-libs/gd ) > mysql? ( dev-db/mysql ) > postgres? ( dev-db/postgresql ) > sqlite? ( dev-db/sqlite )" > >MY_PV="$(get_major_version)" >S=${WORKDIR}/${PN}${MY_PV} > >src_unpack() { > unpack ${A} > cd ${S} > > # fix location of lame > for file in docs/english/lofi.html install/defaults.php; do > sed -i -e "s:/usr/local/bin/lame:/usr/bin/lame:g" ${file} > done >} > >src_install() { > webapp_src_preinst > > # install htdocs > touch ${S}/settings.php > cp -a . ${D}/${MY_HTDOCSDIR} > > webapp_postinst_txt en ${FILESDIR}/postinstall-en.txt > webapp_src_install >} > >pkg_postinst() { > einfo "Jinzora recommends the following settings for php (php.ini):" > einfo " max_execution_time = 1200" > einfo " memory_limit = 32M (or higher)" > einfo " post_max_size = 32M (or higher)" > einfo " file_uploads = 1 (on)" > einfo " upload_max_filesize = 32M (or higher)" > > webapp_pkg_postinst >}
What does jinzora 2.3.1 need to recognize sqlite during the web install requirement check? I have sqlite installed and set up in my PHP use flags. I thought enabling the php "dbx" flag would help but it then complains: * USE flag 'dbx' needs one of these additional flag(s) set: * frontbase mssql odbc postgres sybase-ct oci8 oci8-instant-client So what should I do? I'd rather not add another database engine to my box unless I absolutely have to. Here's my current php setup: [ebuild R ] dev-lang/php-4.4.0-r4 (-adabas) -apache +apache2 -bcmath +berkdb (-birdstep) +bzip2 -calendar -cdb +cgi +cjk -cli +crypt -ctype -curl - curlwrappers -db2 +dba -dbase -dbmaker -dbx -debug -discard-path -doc - empress -empress-bcs -esoob -exif -fastbuild (-fdftk) -filepro (-firebird) - flatfile -force-cgi-redirect -frontbase -ftp +gd -gd-external +gdbm -gmp - hardenedphp -hyperwave-api +iconv -imap -informix -inifile (-interbase) -iodbc (-ipv6) -java-external -java-internal -kerberos -ldap -libedit -mcal -mcve - memlimit -mhash -ming -mnogosearch -msql -mssql +mysql +ncurses +nls -oci8 (- oci8-instant-client) -odbc -oracle7 -overload -ovrimos -pcntl +pcre -pear - pfpro -pic -posix -postgres +readline -recode -sapdb -sasl +session - sharedext -sharedmem -snmp -sockets -solid +spell +sqlite +ssl -sybase -sybase- ct -sysvipc -threads +tiff +tokenizer +truetype -wddx +xml -xml2 -xmlrpc -xpm +xsl -yaz -zip +zlib 0 kB I looked through the forum thread linked in this bug report but it seemed to deal with a known issue that was corrected before 2.3.0 was released. If that's not the case, what is needed to get this ebuild to work?
Jinzora can use SQLite in two ways: The first and best is natively. Here you need sqlite-php (I'm pretty sure) to get the native SQLite calls. But it should also be able to use DBX as a fallback via the sqlite dbx extension. The installer will report that SQLite is not found, but that DBX was, and you should be able to proceed. If not, please post to the Jinzora forums so we can work it out.
If sqlite-php is required to use the sqlite functionality, then the jinzora ebuild needs to be updated to reflect that as a dependency. But the sqlite-php ebuild looks to be in bad shape as it hasn't been seriously updated since Oct 2004. It depennds on dev-php/php-4.2. So unless the ebuild for sqlite-php is updated, it would seem that Gentoo can't really support sqlite for Jinzora at this time. As far as I can tell, the DBX method can't be used without at least pulling in another database engine.
Of course if dev-lang/php +sqlite is the equivilent to dev-php/sqlite-php, then Jinzora isn't recognizing sqlite on my machine. I posted this information to the Jinzora forums as well.
(In reply to comment #37) > Of course if dev-lang/php +sqlite is the equivilent to dev-php/sqlite-php, > then Jinzora isn't recognizing sqlite on my machine. I posted this information > to the Jinzora forums as well. Here's how I understand it: *dev-lang/php +sqlite is not the same as dev-php/sqlite-php, but IMO it should be. *DBX is an abstraction layer; there is an sqlite extension for it, but maybe dbx doesn't recognize sqlite currently in its ebuild. *PHP5 includes sqlite (the native calls) by default. *Somehow, pear fits into the mix via: pear install sqlite Check out your phpinfo() file to see what it says (<?php phpinfo(); ?>)
(In reply to comment #38) > *DBX is an abstraction layer; there is an sqlite extension for it, but maybe dbx > doesn't recognize sqlite currently in its ebuild. That sounds reasonable but I don't know how to proceed. As I wrote, I can't enable DBX and only sqlite. It requires something else and I don't know how to fix it. > *PHP5 includes sqlite (the native calls) by default. Hmm, interesting. Maybe the sqlite flag should depend on PHP5 then? I'm a bit leary on installing PHP5 on my PPC box. But if I installed PHP5 then that would be the only dependency required for sqlite? > *Somehow, pear fits into the mix via: pear install sqlite > Check out your phpinfo() file to see what it says (<?php phpinfo(); ?>) What should I be looking for in that info? I don't have pear installed on my machine. If it's required for sqlite, can we get it added to the ebuild? I really have no idea what needs to be done here so I'll have to wait for the ebuild to be updated before progressing further.
Unfortunately I think I did "pear install sqlite" and "emerge sqlite-php" at the same time. Can you try emerging sqlite-php and restarting your webserver and see if it works? In the phpinfo() page, there should be an sqlite section. There may also be a dbx section, listing which modules are installed (hopefully sqlite is one)
Ben, the sqlite-php ebuild is too old for me to consider installing. My box just got through with the dev-php/php -> dev-lang/php plus the new apache ebuilds. I'd be much more willing to jump to PHP5 than downgrade back to the old PHP. Perhaps a bug should be opened to get an updated sqlite-php ebuild. I'd submit it except that I really have no idea if what I'm asking is correct. Perhaps they intended for it to be replaced by dev-lang/php +sqlite. I've tried searching the Gentoo forums about this but haven't found any info. On that page, there is no sqlite section nor a DBX section. In fact, "sqlite" is not found anywhere on that web page.
Use "USE=sqlite emerge dev-lang/php" instead of the dev-php/sqlite package. This will work for both PHP 4 (using dev-php4/pecl-sqlite) and PHP 5 (using the bundled SQLite extension).
That's what I did so there must be another issue with Jinzora recognizing sqlite on my box. As you can see in post #34, +sqlite is used for my dev- lang/php-4.4.0-r4 compile.
(In reply to comment #43) > That's what I did so there must be another issue with Jinzora recognizing > sqlite on my box. As you can see in post #34, +sqlite is used for my dev- > lang/php-4.4.0-r4 compile. Jinzora just checks the following to see if sqlite is available natively: if (function_exists("sqlite_query"))... Did you check your phpinfo()?
Ah, you say there's no mention of sqlite in your phpinfo() so I'm guessing there is something wrong with the php ebuild..
Well, the good news is that after many tries (takes two hours to recompile PHP on 266 mhz PPC), I have successfully upgraded to PHP5 and gotten lighttpd+Jinzora 2.3.1 to recognize sqlite. I'm going to upgrade to Jinzora 2.3.2 before I actually attempt to progress beyond step 2 of the Jinzora web installer.
(In reply to comment #45) > Ah, you say there's no mention of sqlite in your phpinfo() so > I'm guessing there is something wrong with the php ebuild.. All I can offer is that I never had dev-lang/php with +pear nor any pear ebuilds installed. I did have dev-php4/pecl-sqlite 1.0.3 installed since the beginning.
jinzora is now in our unofficial overlay: http://svn.gnqs.org/projects/gentoo-webapps-overlay/browser Please note that the overlay is unofficial, not a Gentoo project, and not supported. It is intended to provide easier access to new web applications. Please file version bump requests and any other issues in the overlay trac.
Is there a reason this bug was closed? What connection does this unofficial overlay have to Gentoo. How is this ebuild going to be added to portage if there's no open bugs against it?
(In reply to comment #49) > What connection does this unofficial overlay have to Gentoo. How is this ebuild > going to be added to portage if there's no open bugs against it? It will be added if/when ready.
Just to clarify: all new web-app ebuilds should go through the overlay first. The biggest bottleneck in getting ebuilds into the official tree is finding a developer who is willing to maintain it. As you will notice, this bug has been open for ~1.5 years, and noone has volunteered so far. Our hope is that the overlay will make it easier for existing and new devs to see if there is a package they are interested in. The overlay is maintained by the web-apps herd. It's called "unofficial" only because we don't want users to file bugs about it here.
Thanks Renat, that's what I was wondering about. I didn't see anything documented before about the wep-app herd using a seperate testing repository
Is working fine for me on amd64 (had to manually add ~amd64 to keywords). Cheers.
*** Bug 121127 has been marked as a duplicate of this bug. ***
*** Bug 201236 has been marked as a duplicate of this bug. ***
