Inplace development environment setup issue

Hi All,

I’m trying to get an RT development and testing environment set up, but
there doesn’t seem to be much documentation. The “Setting up a
development environment” section of the “Hacking” doc is empty:

https://docs.bestpractical.com/rt/4.4.1/hacking.html#Setting-up-a-development-environment

I checked out the master branch from git and used the configure command
from the “Test suite” section of the “Hacking” doc:
./configure.ac --with-my-user-group --enable-layout=inplace
–enable-developer

make testdeps is passing. I’ve set up RT_DBA_USER to give the tests
access to my local MariaDB 10.0.25 server and I’m running the tests with
make test.

Unfortunately I’m seeing some failures. I’ve attached a log of the test
output. Am I missing some needed configure arguments? Is the full test
suite currently expected to pass clean on master?

Is there documentation on developer setup that I’ve missed?

Thanks,
Sam Hanes

testlog.txt (50.5 KB)

Based on the logs, RT can’t find lib/RT/Generated.pm. That file is
created when you run configure. You should see this line in the
configure output when you run it:

 config.status: creating lib/RT/Generated.pm

Although I also notice that the path looks like it’s adding an extra slash:

 Can't locate lib//RT/Generated.pm

Can you start RT using the standalone server?

 sbin/rt-server --port 8080On 8/2/16 3:26 AM, Sam Hanes wrote:

Hi All,

I’m trying to get an RT development and testing environment set up, but
there doesn’t seem to be much documentation. The “Setting up a
development environment” section of the “Hacking” doc is empty:

https://docs.bestpractical.com/rt/4.4.1/hacking.html#Setting-up-a-development-environment

I checked out the master branch from git and used the configure command
from the “Test suite” section of the “Hacking” doc:
./configure.ac --with-my-user-group --enable-layout=inplace
–enable-developer

make testdeps is passing. I’ve set up RT_DBA_USER to give the tests
access to my local MariaDB 10.0.25 server and I’m running the tests with
make test.

Unfortunately I’m seeing some failures. I’ve attached a log of the test
output. Am I missing some needed configure arguments? Is the full test
suite currently expected to pass clean on master?

Is there documentation on developer setup that I’ve missed?

Thanks,
Sam Hanes


RT 4.4 and RTIR Training Sessions https://bestpractical.com/training

  • Los Angeles - September, 2016

Based on the logs, RT can’t find lib/RT/Generated.pm. That file is
created when you run configure. You should see this line in the
configure output when you run it:

config.status: creating lib/RT/Generated.pm

Configure does emit that line, and the file does exist.

Also note that the vast majority of the tests pass (only 42 of 29311 are
failing), which I don’t think would be happening if Generated.pm were
actually missing. The problem with Generated.pm only seems to be
present in the upgrade script syntax checks in 99-policy.t.

Most of the remaining failed tests seem to have something to do with
text encoding and plaintext conversion.

Although I also notice that the path looks like it’s adding an extra slash:

Can't locate lib//RT/Generated.pm

I thought that was the issue at first too, but my production instance of
RT is generating the same path and it seems to work fine.

Can you start RT using the standalone server?

sbin/rt-server --port 8080

Yes, the server starts correctly and I can access RT just fine.

I also tried starting over from a clean checkout:

 git remote update central
 git reset --hard central/master
 git clean -fdx

 for db in $(mysql <<<"show databases;" | grep rt4); do
     mysql <<<"drop database \`$db\`;"
 done

 autoreconf
 ./configure --with-my-user-group \
     --enable-layout=inplace --enable-developer
 make testdeps
 make initdb

 make test 2>&1 | tee testlog.txt

But that produced identical test results.> On 8/2/16 3:26 AM, Sam Hanes wrote:

Hi All,

I’m trying to get an RT development and testing environment set up, but
there doesn’t seem to be much documentation. The “Setting up a
development environment” section of the “Hacking” doc is empty:

https://docs.bestpractical.com/rt/4.4.1/hacking.html#Setting-up-a-development-environment

I checked out the master branch from git and used the configure command
from the “Test suite” section of the “Hacking” doc:
./configure.ac --with-my-user-group --enable-layout=inplace
–enable-developer

make testdeps is passing. I’ve set up RT_DBA_USER to give the tests
access to my local MariaDB 10.0.25 server and I’m running the tests with
make test.

Unfortunately I’m seeing some failures. I’ve attached a log of the test
output. Am I missing some needed configure arguments? Is the full test
suite currently expected to pass clean on master?

Is there documentation on developer setup that I’ve missed?

Thanks,
Sam Hanes


RT 4.4 and RTIR Training Sessions https://bestpractical.com/training

  • Los Angeles - September, 2016

RT 4.4 and RTIR Training Sessions https://bestpractical.com/training

  • Los Angeles - September, 2016

Hi All,

I’m trying to get an RT development and testing environment set up, but
there doesn’t seem to be much documentation. The “Setting up a
development environment” section of the “Hacking” doc is empty:

https://docs.bestpractical.com/rt/4.4.1/hacking.html#Setting-up-a-development-environment

I checked out the master branch from git and used the configure command
from the “Test suite” section of the “Hacking” doc:
./configure.ac --with-my-user-group --enable-layout=inplace
–enable-developer

make testdeps is passing. I’ve set up RT_DBA_USER to give the tests
access to my local MariaDB 10.0.25 server and I’m running the tests with
make test.

Unfortunately I’m seeing some failures. I’ve attached a log of the test
output. Am I missing some needed configure arguments? Is the full test
suite currently expected to pass clean on master?

Is there documentation on developer setup that I’ve missed?

I note that your @INC does not include “.” and its “lib” is not an
absolute one:

---------------------------------8<--------------------------------------

Failed test ‘etc/upgrade/4.0.19/content syntax is OK’

at t/99-policy.t line 105.

got: 'Can’t locate lib//RT/Generated.pm in @INC (you may

need to install the lib::::RT::Generated module) (@INC contains:
lib /home/sam/code/rt/lib /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.2 /usr/local/share/perl/5.22.2 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base)
at lib/RT.pm line 786.
---------------------------------8<--------------------------------------

I believe this to be because you’re running a recently-updated perl,
which is patched for CVE-2016-1238 [1] by enforcing the removal of "."
from @INC. But you’d also have to be running an ExtUtils::Command::MM
which doesn’t make its arguments absolute, which means one from before
2002[2]?

I can replicate this if I run the test with "perl -Ilib t/99-policy.t"
and explicitly strip “.” from @INC.

I’ve pushed 4.0/dotless-inc-path [3], which addresses the issue. I
believe this only affects installs with --layout=inplace (which are used
almost exclusively for tests), as all other installs already provide a
fully qualified path to include.

You can work around this by cherry-picking that patch onto master.

  • Alex

[1] http://perl5.git.perl.org/perl.git/commitdiff/cee96d5
[2] https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/blame/master/lib/ExtUtils/Command/MM.pm#L71
[3] https://github.com/bestpractical/rt/commit/0c628220bf


I note that your @INC does not include “.” and its “lib” is not an
absolute one:

---------------------------------8<--------------------------------------

Failed test ‘etc/upgrade/4.0.19/content syntax is OK’

at t/99-policy.t line 105.

got: 'Can’t locate lib//RT/Generated.pm in @INC (you may

need to install the lib::::RT::Generated module) (@INC contains:
lib /home/sam/code/rt/lib /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.2 /usr/local/share/perl/5.22.2 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base)
at lib/RT.pm line 786.
---------------------------------8<--------------------------------------

I believe this to be because you’re running a recently-updated perl,
which is patched for CVE-2016-1238 [1] by enforcing the removal of "."
from @INC. But you’d also have to be running an ExtUtils::Command::MM
which doesn’t make its arguments absolute, which means one from before
2002[2]?

I’m on Debian Unstable with Perl 5.22.2-3, into which Debian has indeed
backported the patches for CVE-2016-1238.

However, I have ExtUtils::Command::MM 7.04_01, which should include the
commit you referenced.

I can replicate this if I run the test with "perl -Ilib t/99-policy.t"
and explicitly strip “.” from @INC.

I’ve pushed 4.0/dotless-inc-path [3], which addresses the issue. I
believe this only affects installs with --layout=inplace (which are used
almost exclusively for tests), as all other installs already provide a
fully qualified path to include.

You can work around this by cherry-picking that patch onto master.

Cherry-picking 4.0/dotless-inc-path (0c628220bf8d) onto master
(9c9cedebbb63) did indeed fix the issues in 99-policy.t as well as all
of the ‘plaintext’-related tests. Thanks!

Is 4.0/dotless-inc-path expected to land on master any time soon?

Now only web/cf_groupings.t and web/install.t remain failing; the
failures are identical to the original report.

I’m on Debian Unstable with Perl 5.22.2-3, into which Debian has indeed
backported the patches for CVE-2016-1238.

However, I have ExtUtils::Command::MM 7.04_01, which should include the
commit you referenced.

Interesting – I’m not sure how you’re getting a relative path in @INC,
then. Regardless, though, the commit is probably the right fix.

I can replicate this if I run the test with "perl -Ilib t/99-policy.t"
and explicitly strip “.” from @INC.

I’ve pushed 4.0/dotless-inc-path [3], which addresses the issue. I
believe this only affects installs with --layout=inplace (which are used
almost exclusively for tests), as all other installs already provide a
fully qualified path to include.

You can work around this by cherry-picking that patch onto master.

Cherry-picking 4.0/dotless-inc-path (0c628220bf8d) onto master
(9c9cedebbb63) did indeed fix the issues in 99-policy.t as well as all
of the ‘plaintext’-related tests. Thanks!

Is 4.0/dotless-inc-path expected to land on master any time soon?

Commits get reviewed and merged into their respective trunk
(4.0/dotless-inc-path into 4.0-trunk), than the trunks are occasionally
merged up (4.0-trunk -> 4.2-trunk -> 4.4-trunk -> master) to pick up
fixes that were also relevant to earlier releases.

Now only web/cf_groupings.t and web/install.t remain failing; the
failures are identical to the original report.

t/web/cf_groupings.t failures are fixed by 4.2/mojo-text (a recent
module that broke back-compat).

The installer error looks like it’s 500’ing when attempting to connect
to the database; my suspicion is an incompatibility with MariaDB, since
historically RT is tested on MySQL. I’d try running ./sbin/rt-server --port 8888, stepping through the installer steps via your browser at
localhost:8888, and seeing what errors pop up on the console after
the database connectivity step.

  • Alex