Mailing List Archive

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 8080


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

On 08/04/2016 08:13 AM, Jim Brandt wrote:
> 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

---------
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016

On Tue, 2 Aug 2016 00:26:51 -0700
Sam Hanes <sam@maltera.com> 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?


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
---------
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016

On 08/04/2016 11:48 PM, Alex Vandiver wrote:
> ...
> 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.


> [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

---------
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016

On Fri, 5 Aug 2016 00:57:09 -0700
Sam Hanes <sam@maltera.com> wrote:
> 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
---------
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016