otrs helpdesk 5.0.1 has been released today: https://www.otrs.com/release-notes-otrs-5/ they talk of version 5, but the tarball is numbered 5.0.1 In the next posting I attach a patch against otrs-4.0.13.ebuild which is in portage. otrs-5.0.1 might become unstable version in portage at first. Reproducible: Always
Created attachment 415020 [details, diff] patch against www-apps/otrs-4.0.13.ebuild
Created attachment 415022 [details, diff] patch against www-apps/otrs-4.0.13.ebuild sorry, MY_P and MY_PV aren't used at all. removed that now.
We need to work out another solution. Calling sudo in an ebuild is forbidden.
I don't exactly get why you used sudo and what is it good for but it is really forbidden in ebuilds. So if you don't mind and try to figure out new solution for it, please? If you have any questions you can ask on #gentoo-proxy-maint channel on freenode or just write me email. Thanks. Amynka
Also, for thoroughness, I tried runtesting the ebuild. Firstly, the systemd service file 'otrs-daemon.service' is not present. It seems it was added with this ebuild, so will need to be attached to this bug in order to be included. If it is included in the upstream source, then it can be installed from there rather than from ${FILESDIR}. Also, as a test I also tried removing the calls to `sudo` during the pkg_postinst() when calling the perl scripts, however that did indeed fail, noting that they shouldn't be run as the root user.
thanks for all your comments, I am currently on a vacation and will try to improve the ebuild next week.
Created attachment 415574 [details] otrs-daemon.service files/otrs-daemon.service it is not in the upstream tarball, wrote it myself and it works for me so far
The systemd service files appears to install fine. OTRS_HOME="/var/lib/otrs" on install into image; $ find /mnt/gen2/TmpDir/portage/www-apps/otrs-5.0.1/image/ -name RELEASE /mnt/gen2/TmpDir/portage/www-apps/otrs-5.0.1/image/var/lib/otrs/RELEASE So RELEASE is installed to /var/lib/otrs/ On attampt to merge; * Setting correct permissions ... Setting permissions on /var/lib/otrs * Rebuilding config ... ERROR: Can't read /opt/otrs/RELEASE: No such file or directory This file is needed by central system parts of OTRS, the system will not work without this file. Died at /var/lib/otrs/Kernel/Config/Defaults.pm line 2028. * ERROR: www-apps/otrs-5.0.1::gentoo failed (postinst phase): * Could not rebuild config So it is attempting to find in in the path /opt/otrs/. Something has not been reset to find OTRS_HOME="/var/lib/otrs". It is sought in /opt/otrs/. sudo -u otrs /usr/bin/env perl "${OTRS_HOME}"/bin/otrs.Console.pl Maint::Config::Rebuild The use of sudo is still in place. sudo run from a script is not the intemded style for sudo/ If this configuration script cannot be run form an ebuild, it need be left to be run manually post emerge.
(In reply to Ian Delaney from comment #8) > ERROR: Can't read /opt/otrs/RELEASE: No such file or directory This file is > needed by central system parts of OTRS, the system will not work without > this file. > Died at /var/lib/otrs/Kernel/Config/Defaults.pm line 2028. > * ERROR: www-apps/otrs-5.0.1::gentoo failed (postinst phase): > * Could not rebuild config > > So it is attempting to find in in the path /opt/otrs/. > Something has not been reset to find OTRS_HOME="/var/lib/otrs". > It is sought in /opt/otrs/. Interesting. My installation does not have the dir /var/lib/otrs at all AND does not fail to install this ebuild. I will retry that in a fresh vagrant VM to check. sudo-topic: understood
upstream uses /opt/otrs as default for the installation. It is set in $OTRS_HOME/Kernel/Config/Defaults.pm, line 885. Older ebuilds used /var/lib/otrs. So we have to handle fresh installations different from updates.
(In reply to Stefan G. Weichinger from comment #9) > Interesting. My installation does not have the dir /var/lib/otrs at all correction: I meant /opt/otrs in this statement
sudo-topic: is this allowed and OK ? -> einfo "Rebuilding config ..." su -c "${OTRS_HOME}/bin/otrs.Console.pl Maint::Config::Rebuild" \ -s /bin/bash otrs \ || die "Could not rebuild config" it works at least ... I took this from the output of: # /var/lib/otrs/bin/otrs.Console.pl Error: You cannot run otrs.Console.pl as root. Please run it as the 'otrs' user or with the help of su: su -c "bin/otrs.Console.pl MyCommand" -s /bin/bash otrs
As a generic answer, no. The authors of this have made an unwinnable battle front with this. Use of su or sudo ought not be utilised within an ebuild. Al alternative is to write the whole install phase manually from scratch which means skirting use of the script in per. This is feasible but for a user such as yourself, quite beyond reasonable expectations. I still think this is best left to running this script manually post emerge.
Created attachment 415736 [details] patch against www-apps/otrs-4.0.13.ebuild I understand. See my next suggested patch.
I have to hold back on this due to a tip from another dev re the use of /opt/otrs. Everything in this bug suggests that the perl script has hard coded the path to /opt/otrs in opposition to the test of the ebuild pointing it to /var/lib/orts. It seems to me the perl script will need patching to adjust the install location to the OTRS_HOME. You will need to do a full run test of a full emerge followed by running the perl script manually and ensure it 'works'.
What is the preferred installation DIR for gentoo? /var/lib or /opt ? I will then install/patch everything there.
(In reply to Stefan G. Weichinger from comment #16) > What is the preferred installation DIR for gentoo? /var/lib or /opt ? > I will then install/patch everything there. Stefan, our rules are clear that only binary packages should be installed into /opt. If this package is a source package or built during installation, it shouldn't use /opt.
https://devmanual.gentoo.org/general-concepts/filesystem/ It took me a while to find the reference I was looking for.
Stefan, It appears this can likely be resolved by the perl-module eclass. Here's a start PERL_EXPORT_PHASE_FUNCTIONS=no inherit perl-module I suggest you join in the #Gentoo-proxy-maint for further support.
Created attachment 415936 [details] patch against www-apps/otrs-4.0.13.ebuild fix for the issue with $OTRS_HOME. -> run sed over "${S}"/Kernel/Config.pm after cp-ing the template.
(In reply to Ian Delaney from comment #19) > Stefan, > It appears this can likely be resolved by the perl-module eclass. > Here's a start > > PERL_EXPORT_PHASE_FUNCTIONS=no > inherit perl-module > > I suggest you join in the #Gentoo-proxy-maint for further support. Isn't that for installing perl-modules? I don't see anything related to *executing* a perl script in the docs for that eclass.
This is why I suggest you join in the #Gentoo-proxy-maint for further support. In short, a senior dev from the perl team suggested all the above as a means to install it in the correct directory. You interpretation appears far too literal. If the eclass only acted on perl modules he'd not have suggested it. The flow would be that a function in the eclass stipulates an install location which could override that set in the perl script itself. Either way, you have taken on a very challenging package to ebuild.
OK, I understand the direction ... Today I copied the ebuild to otrs-5.0.2.ebuild as upstream released a new version. Running the 2 commands manually works for me so far. - otrs-5.0.x.ebuild : I won't find much time in the next weeks as I move house here in the next week etc. / but it is ~ anyway in portage, right? not exactly belonging to this bug: there should be a otrs-4.0.14.ebuild done for stable version as there is also an upstream release for 4.x. Should I file this as a new bug? thanks, regards, Stefan
ping? any progress here?
(In reply to Marc Schiffbauer from comment #24) > ping? any progress here? I use my own ebuild for 5.0.10. Not yet ready for portage, though.
(In reply to Marc Schiffbauer from comment #24) > ping? any progress here? If you want to test it while it still installs into /opt I can share my current ebuild (here or via github or pm). I'd be happy to have someone else helping with fixing the installation path (as I am still quite busy with other issues here). Aside from the path my otrs-installation runs fine (used daily).
Would be nice if you'd append it to this bug. FOr me personally installing to /opt would be ok. Thanks!
(In reply to Marc Schiffbauer from comment #27) > Would be nice if you'd append it to this bug. FOr me personally installing > to /opt would be ok. > > Thanks! pls clone from here: https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs and don't forget to provide any feedback ;-)
OTRS help desk 5.0.11 is out: https://www.otrs.com/release-notes-otrs-5-patch-level-11/ As I installed my new otrs-5.0.11.ebuild (check git-repo as mentioned above) I noticed that I already fixed the installation directory issue. My installation is in /var/lib/otrs which seems correct to me? I also cp-ied over metadata.xml to clear some repoman warnings, now "repoman full" seems quite happy: # repoman full RepoMan scours the neighborhood... Note: use --include-dev (-d) to check dependencies for 'dev' profiles RepoMan sez: "If everyone were like you, I'd be out of business!" pls review and test, maybe we can get an updated ebuild into portage soon. thanks, Stefan
Hi Stefan, thanks very much for your feedback and ebuild. I will have a look at it ASAP.
# cp otrs-5.0.11.ebuild otrs-5.0.12.ebuild ... works for me to install latest upstream release 5.0.12
We should get 5.0.14 out, at least as unstable. check https://bugs.gentoo.org/show_bug.cgi?id=598768 for security issues. My local ebuild installs and works fine for me. btw: this bug is over a year old now (remember "gentoo = bleeding edge" , someone? ;-) )
OTRS Help Desk 5.0.15 :: https://www.otrs.com/release-notes-otrs-5s-patch-level-15
Now in repository, https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f478142f7e09113eda2a1618aab90c2b563f34d6
