otrs version 3.3.5 is available. Maybe this will fix the bug there -> https://bugs.gentoo.org/show_bug.cgi?id=494628 So I think it's worth a try. Reproducible: Always
running otrs 3.3.5 for weeks here already .. using my own ebuild. So, yes, pls go for it.
otrs 3.3.8 is out works fine here from local ebuild pls add it to portage
*bump*
Stefan can you uttach here your ebuild for otrs-3.3.* ? Thank you very much! Best regards,
(In reply to Riccardo from comment #4) > Stefan can you uttach here your ebuild for otrs-3.3.* ? > > Thank you very much! > > Best regards, I just diffed it with the ebuild for 3.2.10 ... no mentionable difference, just my ugly workarounds from back then, around setting the permissions bin/otrs.SetPermissions.pl fails for 3.3.8 ... I will see what I can do to fix this and return here. My ebuild is a bit ugly and I ran the permission-stuff manually when upgrading.
--- /usr/portage/www-apps/otrs/otrs-3.2.12.ebuild 2013-12-02 06:47:35.000000000 +0100 Diff between 3.2.12 (latest in portage right now) and my 3.3.8-ebuild. Moved the permission-stuff (which failed before). Works here. Maybe we should add these two commands for upgrades: ./otrs.RebuildConfig.pl ./otrs.DeleteCache.pl ? -> diff: +++ otrs-3.3.8.ebuild 2014-08-30 15:03:26.000000000 +0200 @@ -112,21 +112,13 @@ cp ${i} $(basename ${i} .dist) || die done - perl "${S}"/bin/otrs.SetPermissions.pl \ - --otrs-user=otrs \ - --web-user=apache \ - --otrs-group=apache \ - --web-group=apache "${S}" \ - || die "Could not set permissions" - echo "CONFIG_PROTECT=\"${OTRS_HOME}/Kernel/Config.pm \ ${OTRS_HOME}/Kernel/Config/GenericAgent.pm\"" > "${T}/50${PN}" } src_install() { - dodoc CHANGES.md README* \ - doc/X-OTRS-Headers.txt || die + dodoc CHANGES.md README* || die dodoc doc/manual/en/otrs_admin_book.pdf @@ -142,6 +134,8 @@ keepdir "${OTRS_HOME}/var/${a}" done doenvd "${T}/50${PN}" || die + + } # This is too automagic, either einfo telling user or installing to /etc/cron.d/ should be preferred @@ -151,6 +145,14 @@ } pkg_postinst() { + + /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.SetPermissions.pl "${OTRS_HOME}" \ + --otrs-user=otrs \ + --web-user=apache \ + --otrs-group=apache \ + --web-group=apache \ + || die "Could not set permissions" + elog "Enable cronjobs with the following command:" elog "crontab -u otrs crontab" }
Added the two mentioned commands ... unsure if that should be only run conditionally at updates-only (and not on first installation). Although I think it doesn't hurt. diff --git a/www-apps/otrs/otrs-3.3.8.ebuild b/www-apps/otrs/otrs-3.3.8.ebuild index b45f981..ad3d043 100644 --- a/www-apps/otrs/otrs-3.3.8.ebuild +++ b/www-apps/otrs/otrs-3.3.8.ebuild @@ -145,7 +145,8 @@ pkg_config() { } pkg_postinst() { - + + einfo "Setting correct permissions ..." /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.SetPermissions.pl "${OTRS_HOME}" \ --otrs-user=otrs \ --web-user=apache \ @@ -153,6 +154,17 @@ pkg_postinst() { --web-group=apache \ || die "Could not set permissions" + + einfo "Rebuilding config ..." + /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.RebuildConfig.pl \ + || die "Could not rebuild config" + + einfo "Deleting cache ..." + /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.DeleteCache.pl \ + || die "Could not delete cache" + + einfo "Installation done!" + elog "Enable cronjobs with the following command:" elog "crontab -u otrs crontab" }
update: OTRS Help Desk 3.3.9 is out now -> https://www.otrs.com/release-notes-otrs-help-desk-3-3-9/ copied ebuild to otrs-3.3.9.ebuild ... works for me. Please get some newer ebuild into portage soon.
and there is a beta out as well: https://www.otrs.com/release-notes-otrs-help-desk-4-beta1/ I will test my ebuild for that, but not upgrade my local installation for now ...
(In reply to Stefan G. Weichinger from comment #9) > and there is a beta out as well: > > https://www.otrs.com/release-notes-otrs-help-desk-4-beta1/ > > I will test my ebuild for that, but not upgrade my local installation for > now ... for the beta I suggest another ticket/bug: managed to do the upgrade but with some issues ... maybe related to the beta-status, maybe to other issues.
(In reply to Stefan G. Weichinger from comment #8) > update: > > OTRS Help Desk 3.3.9 is out now -> > > https://www.otrs.com/release-notes-otrs-help-desk-3-3-9/ > > copied ebuild to otrs-3.3.9.ebuild ... works for me. > > Please get some newer ebuild into portage soon. *bump* What keeps you from adding a newer ebuild?
OTRS 3.3.10 is stable at upstream for quite a while now. And 4.x is announced for next week or so. I have 4.0.0_rc1 installed here already and a rough ebuild for it. It is far from perfect for upgrading but gets most things right. So far 4.x is working OK for me.
Today support for 3.2 branch has ended. Latest 3.3 ist 3.3.10 and Version 4 is out. Please bump...
# diff -u /usr/portage/www-apps/otrs/otrs-3.2.12.ebuild otrs-4.0.1.ebuild --- /usr/portage/www-apps/otrs/otrs-3.2.12.ebuild 2013-12-02 06:47:35.000000000 +0100 +++ otrs-4.0.1.ebuild 2014-11-25 14:47:29.000000000 +0100 @@ -21,6 +21,7 @@ DEPEND="" RDEPEND="${DEPEND} + dev-perl/Archive-Zip dev-perl/Authen-SASL dev-perl/Crypt-PasswdMD5 dev-perl/CSS-Minifier @@ -52,6 +53,7 @@ dev-perl/SOAP-Lite !=dev-perl/SOAP-Lite-0.711 !=dev-perl/SOAP-Lite-0.712 ) + dev-perl/Template-Toolkit dev-perl/Text-CSV dev-perl/Text-CSV_XS dev-perl/TimeDate @@ -89,7 +91,9 @@ confutils_require_any mysql postgres } + src_prepare() { + cd "${S}" rm -fr "${S}/scripts"/{auto_*,redhat*,suse*,*.spec} || die cp Kernel/Config.pm{.dist,} || die # procmail/fetchmail/mailfilter @@ -112,23 +116,13 @@ cp ${i} $(basename ${i} .dist) || die done - perl "${S}"/bin/otrs.SetPermissions.pl \ - --otrs-user=otrs \ - --web-user=apache \ - --otrs-group=apache \ - --web-group=apache "${S}" \ - || die "Could not set permissions" - echo "CONFIG_PROTECT=\"${OTRS_HOME}/Kernel/Config.pm \ ${OTRS_HOME}/Kernel/Config/GenericAgent.pm\"" > "${T}/50${PN}" } src_install() { - dodoc CHANGES.md README* \ - doc/X-OTRS-Headers.txt || die - - dodoc doc/manual/en/otrs_admin_book.pdf + dodoc CHANGES.md README* || die insinto "${OTRS_HOME}" doins -r .fetchmailrc.dist .mailfilter.dist .procmailrc.dist RELEASE \ @@ -142,6 +136,8 @@ keepdir "${OTRS_HOME}/var/${a}" done doenvd "${T}/50${PN}" || die + + } # This is too automagic, either einfo telling user or installing to /etc/cron.d/ should be preferred @@ -151,6 +147,24 @@ } pkg_postinst() { + + einfo "Setting correct permissions ..." + /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.SetPermissions.pl "${OTRS_HOME}" \ + --otrs-user=otrs \ + --web-group=apache \ + || die "Could not set permissions" + + + einfo "Rebuilding config ..." + /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.RebuildConfig.pl \ + || die "Could not rebuild config" + + einfo "Deleting cache ..." + /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.DeleteCache.pl \ + || die "Could not delete cache" + + einfo "Installation done!" + elog "Enable cronjobs with the following command:" elog "crontab -u otrs crontab" }
And there is otrs help desk 4.0.3 ... See my ebuild at: https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs
(In reply to Stefan G. Weichinger from comment #15) > And there is otrs help desk 4.0.3 ... > > See my ebuild at: > > https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs 4.0.5 ...
(In reply to Stefan G. Weichinger from comment #16) > (In reply to Stefan G. Weichinger from comment #15) > > And there is otrs help desk 4.0.3 ... > > > > See my ebuild at: > > > > https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs > > 4.0.5 ... ... and in portage it's still ~3.2.12 and unconfirmed here. Looks like they the gentoo team needs some help. Stefan, as I see your efforts maybe you would be the perfect maintainer for otrs in portage? Have you ever asked if you can help?
(In reply to tazinblack from comment #17) > (In reply to Stefan G. Weichinger from comment #16) > > 4.0.5 ... > > ... and in portage it's still ~3.2.12 and unconfirmed here. > > Looks like they the gentoo team needs some help. > > Stefan, as I see your efforts maybe you would be the perfect maintainer for > otrs in portage? Have you ever asked if you can help? Well, I provide my ebuilds ... which work for me. But it's not that easy ... updating OTRS still need some manual fixing sometimes. But the ebuilds would be a starting point for others to be able to install/upgrade and test, yes.
Does someone run otrs-4.0.x on gentoo? I have an issue with splitting the replies ... and upstream noone reacts (forum). Would be nice to localize that ...
4.0.6: https://www.otrs.com/release-notes-otrs-help-desk-4-patch-level-6/ my ebuild installs fine (see github as mentioned)
Hi, I wanted to add that your ebuild for 4.0.8(I didn't test older ones) fails to install with on a mostly stable gentoo system with: emerge: there are no ebuilds to satisfy ">=virtual/perl-CGI-3.33". (dependency required by "www-apps/otrs-4.0.8::x-portage" [ebuild]) Installing with emerge --nodeps succeeds nevertheless. Thanks for the work you put into providing those ebuilds!
(In reply to Captain Sifff from comment #21) > Hi, > I wanted to add that your ebuild for 4.0.8(I didn't test older ones) > fails to install with on a mostly stable gentoo system with: > > emerge: there are no ebuilds to satisfy ">=virtual/perl-CGI-3.33". > (dependency required by "www-apps/otrs-4.0.8::x-portage" [ebuild]) > > Installing with emerge --nodeps succeeds nevertheless. > Thanks for the work you put into providing those ebuilds! As was announced in the mls[1], virtual/perl-CGI has been dropped from the tree. That dep needs to be updated to perl-core/CGI. [1] - https://archives.gentoo.org/gentoo-dev-announce/message/82ea4b86b4799216425f540ab2637e80
I think it has to depend on >=dev/perl-CGI-3.33 at least it's what I have in my otrs-4.0.10.ebuild which builds and works fine so far.
helpdesk 4.0.11 working fine here.
just noticed in the Changelog: 01 Aug 2015; Patrick Lauer <patrick@gentoo.org> metadata.xml: Remove myself as maintainer What is the "standard procedure"? OTRS 5.0 beta 2 is out, I am planning to do some test upgrade soon.
otrs-5.0.0_beta2.ebuild in progress here. got the beta2 installed here successfully, but "semi-automated" -> unsure how to script the DB-schema-updates and the start of the new OTRS daemon.
I don't file a new bug for this as long it is unclear who maintains www-apps/otrs anyway. The topic here is related to upgrading version 3.3.5 while 4.0.11 is stable upstream and 5.0.0_beta3 is available. -- For your review and maybe tests: I wrote a systemd unit to start/stop the new otrs.Daemon.pl (comes with 5.x). Runs OK here, pls review and comment if necessary. I will add it to my otrs-5.0.0_beta3.ebuild soon.
see latest ebuild on https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs Pls remember that upgrading to 5.0.x needs the database schema update which is not done by the current ebuild. Pls test in a testing environment and read: http://otrs.github.io/doc/manual/admin/5.0/en/html/upgrading.html regards, Stefan
added 4.0.12 to my overlay. Is there anybody still reading this who would like to test the ebuilds? I am in contact with gentoo-devs to get this package supported better within portage, some users testing would help as well.
(In reply to Stefan G. Weichinger from comment #29) > added 4.0.12 to my overlay. > Is there anybody still reading this who would like to test the ebuilds? > > I am in contact with gentoo-devs to get this package supported better within > portage, some users testing would help as well. ok A few initial comments on the -4.0.12.ebuild 1. line 3 carries the defunct form of cvs. 2. line 5 sets EAPI=2 which is long deprecated. Needs a modern EAPI. 3. There are several lines commented out. It they no longer apply they need be deleted. 4. DEPEND="" is redundant in EAPI 5 can be deleted 5. ditto RDEPEND="${DEPEND} 6. Within RDEPEND there are several blank lines which make for unwanted white space. 7. entries like || die "Could not rebuild config" are made redundant in EAPI for helper functions. There may be more. It would be a good start to update the ebuild to one that fits the git style repos as an attachment to this bug.
Created attachment 413274 [details] suggested new ebuild Ian, see my suggestion attached. pls for more details on your comment 7 ... I merged this ebuild in a VM and ran otrs.CheckModules.pl to check for its needed (perl-)modules, OK so far.
(In reply to Stefan G. Weichinger from comment #31) > Created attachment 413274 [details] > suggested new ebuild > > Ian, see my suggestion attached. > pls for more details on your comment 7 ... > > I merged this ebuild in a VM and ran otrs.CheckModules.pl to check for its > needed (perl-)modules, OK so far. edit: and repoman was happy now as well ...
Stefan, progress made here. 1. Format issues; Line 63 has 5 tab spaces, needs 3 Line 65 has 4 tab spaces, needs 3 I would put ')' on line 68 back from 3 to 2 tab spaces I would also simplify !fastcgi? ( !mod_perl? ( www-servers/apache:2[suexec] ) ) to !fastcgi? ( !mod_perl? ( www-servers/apache:2[suexec] ) ) reducing by 1 line, which changes line 68 to 67. Similarly !fastcgi? ( !apache2? ( virtual/httpd-cgi ) )" to !fastcgi? ( !apache2? ( virtual/httpd-cgi ) )" Use of <flag> ( (blank) uses up a line and makes readability sl. confusing. Those are optionals. Line 102 is a blank, white space. 2. Lines 122 - 126 deal with pkg_config() { I would shift these to location before src_install, not after. Makes for the phases to be ordered as they are run. 3. src_install() || die is NOT required in lines 106, 110, 119. Each of these are helper funcs in which the die is made internally. In contrast, they are correctly left out in lines 113, 114, 117. Running www-apps/otrs $ sudo ebuild otrs-4.0.12.ebuild install yields >>> Install otrs-4.0.12 into /mnt/gen2/TmpDir/portage/www-apps/otrs-4.0.12/image/ category www-apps >>> Completed installing otrs-4.0.12 into /mnt/gen2/TmpDir/portage/www-apps/otrs-4.0.12/image/ * QA Notice: broken .png files found: * /mnt/gen2/TmpDir/portage/www-apps/otrs-4.0.12/image/var/lib/otrs/var/httpd/htdocs/skins/Agent/default/img/otrs-verify.png: broken IDAT window length ecompressdir: bzip2 -9 /usr/share/doc so I have not yet done a full merge invoking pkg_postinst() however your run tests declare that effective. This is only one of dozens of .png files so I cannot assess its final impact. Assigning the bug to lists@xunil.at
Created attachment 413332 [details, diff] patch with changes regarding Comment 33 Ian, see my next steps in the attached patch (diff against previous ebuild). You are right, "ebuild install" fails, I only did an "ebuild merge", my fault. pls advise how to deal with that png-issue (will try to find out myself in the meantime).
I've tested this and it fails on qmerge in pkg_postinst() while running the perl scripts. Specifically, otrs.SetPermissions.pl fails as it needs --otrs-group and --web-user specified. I corrected this locally which succeeded with that script but then failed on otrs.RebuildConfig.pl with unable to connect to MySQL server (I've only just installed, haven't set up yet). Note that this does not address the QA issue.
(In reply to wraeth from comment #35) > I've tested this and it fails on qmerge in pkg_postinst() while running the > perl scripts. Specifically, otrs.SetPermissions.pl fails as it needs > --otrs-group and --web-user specified. > > I corrected this locally which succeeded with that script but then failed on > otrs.RebuildConfig.pl with unable to connect to MySQL server (I've only just > installed, haven't set up yet). > > Note that this does not address the QA issue. interesting. In earlier releases otrs.SetPermissions.pl required more options, in the current release I get this help-text (only one mandatory option): Usage: otrs.SetPermissions.pl --web-group=<WEB_GROUP> # web server group ('www', 'www-data' or similar) [--otrs-user=<OTRS_USER>] # OTRS user, defaults to 'otrs' I remember editing this call in a previous ebuild (might have been with 3.x -> 4.x). Thanks for testing, pls let me know if things work with the mysql-server later on.
(In reply to Stefan G. Weichinger from comment #36) > (In reply to wraeth from comment #35) > > I've tested this and it fails on qmerge in pkg_postinst() while running the > > perl scripts. Specifically, otrs.SetPermissions.pl fails as it needs > > --otrs-group and --web-user specified. > > > > I corrected this locally which succeeded with that script but then failed on > > otrs.RebuildConfig.pl with unable to connect to MySQL server (I've only just > > installed, haven't set up yet). > > > > Note that this does not address the QA issue. > > interesting. In earlier releases otrs.SetPermissions.pl required more > options, in the current release I get this help-text (only one mandatory > option): > > Usage: otrs.SetPermissions.pl > --web-group=<WEB_GROUP> # web server group ('www', 'www-data' or > similar) > [--otrs-user=<OTRS_USER>] # OTRS user, defaults to 'otrs' > > I remember editing this call in a previous ebuild (might have been with 3.x > -> 4.x). > > Thanks for testing, pls let me know if things work with the mysql-server > later on. I don't think the ebuild should call any actions that expect a running MySQL (or similar) daemon on the system. Any configuration updates should remain in the domain of the application, not the systems package manager - in my case, I didn't have a DB installed until testing this, meaning from a "clean" system everyone else would get a merge failure because of the expectation of a running DB instance. I will do some more testing around otrs.SetPermissions.pl a little later and confirm for you, too.
(In reply to wraeth from comment #37) > I don't think the ebuild should call any actions that expect a running MySQL > (or similar) daemon on the system. Any configuration updates should remain > in the domain of the application, not the systems package manager - in my > case, I didn't have a DB installed until testing this, meaning from a > "clean" system everyone else would get a merge failure because of the > expectation of a running DB instance. I agree somehow, this would also help to deal with the update-scripts when it comes to database-schema-updates at major-release-upgrades (v3.x-> 4.x-> 5.x). > I will do some more testing around otrs.SetPermissions.pl a little later and > confirm for you, too. thanks!
I couldn't get the patch (attachment 413332 [details, diff]) to apply to the attached ebuild (attachment 413274 [details]) however the changes I tested with are consistent with that patch. patch -p1 < otrs-formatting.patch ... File to patch: otrs-4.0.12.ebuild patching file otrs-4.0.12.ebuild Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 14. Hunk #2 FAILED at 64. Hunk #3 FAILED at 88. Hunk #4 FAILED at 113. Hunk #5 FAILED at 127. The version that I tested before was wrong - the bug title says otrs-3.3.5, however it was later noted that this is being bumped to 4.0.12. Therefore I've retested using attachment 413274 [details] for otrs-4.0.12-r1 (with formatting corrections only) and everything worked. otrs-4* doesn't attempt/require a running mysql daemon during installation, which is good. There were some errors output by the perl scripts (not posting for brevity but can attach if required) but they completed successfully. Otherwise the ebuild installs successfully.
I should have posted the full new ebuild for 4.0.12-r1, that would have made it easier. Sorry. I will put it up my github account soon. Good to hear it installs. As now this bug is assigned to me, I can edit the subject, btw. ;-) Additional info: upstream released 4.0.13 yesterday. I suggest we work and test on this 4.0.12-r1 until Ian is happy with QA issues and then make a 4.0.13.ebuild out of it.
Created attachment 413346 [details] otrs-4.0.12-r1.ebuild improved ebuild, obsoletes previous attachments
tried to put it all together (and removed older versions) from my github-repo: https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs
With some assist from devs in gentoo-dev, it appears the broken .png file can be fixed in source. Either way the break ought by filed to upstream for their attention. The bug that carries a fix is bug #466190. Tips; the repair is done by pngfix, pngcrush just makes sure its packed efficiently but pngcrush can not just be assumed to be installed. pngfix is part of libpng, which likely is installed if you install something that ships pngs. This ought provide all material to make a repair. Let's focus on making a 4.0.12-r1 which can simply be 4.0.12 since the bump is not yet in portage. Then look at bumping to the 4.0.13. I shall re-check tomorrow and plan to bump it then, all going well.
(In reply to Ian Delaney from comment #43) > With some assist from devs in gentoo-dev, it appears the broken .png file > can be fixed in source. Either way the break ought by filed to upstream for > their attention. The bug that carries a fix is bug #466190. I am in contact with upstream already. > Let's focus on making a 4.0.12-r1 which can simply be 4.0.12 since the bump > is not yet in portage. Then look at bumping to the 4.0.13. > > I shall re-check tomorrow and plan to bump it then, all going well. Sounds good, thanks!
Just an FYI: your github copy of the ebuild looks mostly good (pending idella4's note about the PNG issue), however a couple of formatting issues seem to have crept back in: Unnecessary blank lines on lines 98 and 125, and the indentation of pkg_postinst() seems off - line 127 should be unindented by one, and lines 133, 134, 137 and 138 should be further indented by one. Otherwise, looks good to me. Let me know if you want me to test the build again.
temporary fix for png issue (tested install here): diff --git a/www-apps/otrs/otrs-4.0.12.ebuild b/www-apps/otrs/otrs-4.0.12.ebuild index 1eff9fc..7201e1d 100644 --- a/www-apps/otrs/otrs-4.0.12.ebuild +++ b/www-apps/otrs/otrs-4.0.12.ebuild @@ -81,6 +81,10 @@ src_prepare() { rm -fr "${S}/scripts"/{auto_*,redhat*,suse*,*.spec} || die cp Kernel/Config.pm{.dist,} || die + # Fix broken png files + pngfix -q --out=out.png "${S}/var/httpd/htdocs/skins/Agent/default/img/otrs-verify.png" + mv -f out.png "${S}/var/httpd/htdocs/skins/Agent/default/img/otrs-verify.png" || die + sed -i -e "s:/opt/otrs:${OTRS_HOME}:g" "${S}"/Kernel/Config.pm \ || die "sed failed"
(In reply to wraeth from comment #45) > Just an FYI: your github copy of the ebuild looks mostly good (pending > idella4's note about the PNG issue), however a couple of formatting issues > seem to have crept back in: > > Unnecessary blank lines on lines 98 and 125, and the indentation of > pkg_postinst() seems off - line 127 should be unindented by one, and lines > 133, 134, 137 and 138 should be further indented by one. > > Otherwise, looks good to me. Let me know if you want me to test the build > again. Applied your suggested formatting fixes, repoman is happy, ebuild install works for me. Yes, pls test. - sidenote: maybe I should review the RDEPEND some day ... /var/lib/otrs/bin/otrs.CheckModules.pl is happy (for USE=mysql) but seems to check for less libraries than RDEPEND lists. Maybe we could slim down here as well. I have a closer look now.
with the change for pngfix, you will also need to add media-libs/libpng to DEPEND as a build-time dependency. I'll do a test when you add a revised ebuild to the bug with both the png fix and any RDEPEND changes you make, though note I won't be able to vouch for the RDEPEND changes. If you get an ebuild attached soon I'll test tonight, otherwise will test in the morning.
Created attachment 413368 [details] otrs-4.0.12.ebuild added necessary DEPEND. This is commit dda2710f... in my github-repo (for reference). RDEPEND-changes: I still have to test them here, too soon to share.
on github you find commit cc17f5ab I created a fresh gentoo VM (vagrant, ansible), and edited RDEPEND to reflect the output of /var/lib/otrs/bin/otrs.CheckModules.pl I then emerged the new ebuild and tested again. Still everything "OK" for USE=mysql. Maybe I was too ambitious ... and that still doesn't mean that the installation would work. For today I leave it at that. Maybe someone is interested in testing it and playing with the fully installed application. thanks, Stefan
Stefan, after some brief discussion, your ebuild in https://raw.githubusercontent.com/stefangweichinger/gentoo-overlay/cc17f5ab362bdc55bead5ced52db8cfb76611f7d/www-apps/otrs/otrs-4.0.12.ebuild appears functional but format / syntax requires tidying. 1. The whole list of RDEPEND needs re-doing to be more readable and to conform to usual convention. Don't worry about this, I am sure you have inherited this state from previous ebuilds. I will re-order it if you don't. It does work. 2. l1 apache2? ( mod_perl? ( www-servers/apache:2 l2 =www-apache/libapreq2-2* www-apache/mod_perl ) l3 !fastcgi? ( !mod_perl? ( www-servers/apache:2[suexec] ) ) l4 !fastcgi? ( !mod_perl? ( www-servers/apache:2[suexec] ) ) ) l3 needs indenting 1 more tab space. l4 looks to us in the channel to be repetitious and redundant. Can you double check that? I have to leave shortly but looks like I can get this into portage later today. Great effort
I performed a merge test of the ebuild in your overlay at commit cc17f5ab and it ran fine. Again, I can't speak to the functionality of the application itself. Also, the indentation in pkg_postinst() looks to be off as well. This was probably because the line numbers I gave became invalid once earlier changes were made. Specifically, the invocation of the perl scripts should be unindented one tab space, and the "|| die ..." should be indented by one, changing: einfo "Rebuilding config ..." /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.RebuildConfig.pl \ || die "Could not rebuild config" into einfo "Rebuilding config ..." /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.RebuildConfig.pl \ || die "Could not rebuild config" (and repeating for the rest of pkg_postinst()). Can you attach to bugzilla when ready?
commit 9c434c48e1aa309c6dcfa504592bff7f6a706a2a Author: Ian Delaney <idella4@gentoo.org> Date: Thu Oct 1 12:55:13 2015 +0800 www-apps/otrs: Designate new maintainer in metadata, bump to -4.0.12 New maintainer added & supported under the proxy-maintainers herd, testing and revision carried out thanks also to wraeth, fix to broken .png file applied according to past bug #466190 supplied by Blackb|rd, all patches and revisons of ebuilds supplied via bug cited below, releases after -3.2.12 skipped, holding off from beta versions of version 5.x for now, removed old versions prior to -3.2.12. Finally closes the gentoo bug. Gentoo-Bug: 506052
(In reply to wraeth from comment #52) I looked at the ebuild in portage now and it seems your suggestions are in there already. thanks
(In reply to Ian Delaney from comment #51) > Stefan, > > after some brief discussion, your ebuild in > https://raw.githubusercontent.com/stefangweichinger/gentoo-overlay/ > cc17f5ab362bdc55bead5ced52db8cfb76611f7d/www-apps/otrs/otrs-4.0.12.ebuild > appears functional but format / syntax requires tidying. > > 1. The whole list of RDEPEND needs re-doing to be more readable and to > conform to usual convention. Don't worry about this, I am sure you have > inherited this state from previous ebuilds. I will re-order it if you don't. > It does work. > 2. > l1 apache2? ( mod_perl? ( www-servers/apache:2 > l2 =www-apache/libapreq2-2* www-apache/mod_perl ) > l3 !fastcgi? ( !mod_perl? ( www-servers/apache:2[suexec] ) ) > l4 !fastcgi? ( !mod_perl? ( www-servers/apache:2[suexec] ) ) ) > > l3 needs indenting 1 more tab space. > l4 looks to us in the channel to be repetitious and redundant. Can you > double check that? to me it looks you did all that already, thanks > I have to leave shortly but looks like I can get this into portage later > today. > > Great effort thanks a lot, I had great guides in here.
