Problem with modules during upgrade to 5.0.6

After my host provider upgraded to Linux 4.14 [with perl 5.26.1], 
my Bugzilla 4.4.0 release stoped working. So I decided to upgrade 
Bugzilla to the current release [5.0.6]. Reading the Bugzilla 
documentation at https://bugzilla.readthedocs.io. I found out that 
I would first have to migrate my current old release from a tarball 
to git. Things are never as easy as one might hope.

I did this migration using a new sub-directory called bugzilla-new.
I then upgraded this git release to bugzilla 5.0.6. When I ran 
../checksetup.pl on this version of bugzilla I got a message about 4 
modules being missing or out of date. One of these modules was 
DateTime.pm, so I ran ./install-module.pl DateTime and then reran 
../checksetup.pl. But the DateTime module was still not found. 

What am I doing wrong?

Below is a link to the output from "./install-module.pl DateTime"  
and the subsequent execution of "./checksetup.pl". 

https://drive.google.com/open?id=1bHfuZRsIWXmqU2zD-BEZAd_AXO0D0W1b
0
Richard
6/4/2019 2:48:59 PM
mozilla.support.bugzilla 10091 articles. 0 followers. Post Follow

16 Replies
60 Views

Similar Articles

[PageSpeed] 17

Guten Tag Richard Price,
am Dienstag, 4. Juni 2019 um 16:48 schrieben Sie:

> After my host provider upgraded to Linux 4.14 [with perl 5.26.1],=20
> my Bugzilla 4.4.0 release stoped working.

If you used install-module.pl with the old Bugzilla as well, there's a
chance that cleaning "lib" of the old Bugzilla and installing missing
packages using your package manager gets your old Bugzilla runing
again.

> [...]One of these modules was
> DateTime.pm, so I ran ./install-module.pl DateTime[...]

Don't do that, install-module.pl is the last resort only, always prefer
you package manager! install-module.pl doesn't handle dependencies
etc. as good as your package manager does. So install using your
package manager and see if things work already.

Besides that, check things like time zone and region settings. There
have been problems in the past when those were wrong or missing, as
packages depending on them didn't load propelry and stuff.

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=E4ftsf=FChrer: Andreas Muchow

0
windows
6/4/2019 5:17:27 PM
 Thorsten :

Thank you for replying to my post. The problem I have with your suggestion
is that I am using a server that is provided by a service bureau. Thus I ha=
ve
neither access to a package manager nor root access.

As far as I know the required modules are already installed somewhere on th=
is
server. But I don't know how to direct the BugZilla package in finding them=
..

What do you mean by =E2=80=98cleaning =E2=80=9Clib=E2=80=9D of the old BugZ=
illa=E2=80=99?
Could you be a bit more specific?
0
Richard
6/4/2019 6:08:12 PM
Guten Tag Richard Price,
am Dienstag, 4. Juni 2019 um 20:08 schrieben Sie:

> As far as I know the required modules are already installed somewhere on =
this
> server. But I don't know how to direct the BugZilla package in finding th=
em.

If things still fail after you installed DateTime, I suggest assuming
that either dependencies are still missing or the system is not setup
correctly for DateTime to work. Bugzilla simply follows default Perl
conventions and the Perl of your OS provides default directories to
search for system wide dependencies. That's normally nothing one need
to take care of, it should just work.

If it doesn't, either dependencies are still missing, the setup is
wrong or the dependencies are not installed following the normal Perl
conventions. In the latter case, you need to ask your service provider
where the necessary dependencies are and provide them to Bugzilla
e.g. using SetEnv PERL5LIB in your web server config or such. From my
experience, that won't be your problem most likely, but really
additionally missing dependencies.

checksetup.pl tries to load DateTime to check if it's available and
fails in your case, but simply doesn't provide the reason why loading
that module failed. So give it a try by manually loading that module
to see if Perl provides stacktraces of missing dependencies or
additional error messages. The following should be enough already:

> perl -MDateTime -e "print DateTime->VERSION"

In my case it e.g. prints "1.21". That means the package can be
successfully loaded and in the best case it fails for you telling you
why.

You might give that a try OUTSIDE the "lib"-folder of Bugzilla, INSIDE
the "lib"-folder of Bugzilla and INSIDE using the following:

> perl -I. -MDateTime -e "print DateTime->VERSION"

Newer Perls don't contain the current working directory in the paths
searching for packages, so you might need to add that manually. That
is what "-I" is for. If "." fails, you should give an absolute path a
try, I don't have access to such a new Perl to test currently.

https://linux.die.net/man/1/perl
https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Rem=
oval-of-the-current-directory-%28"."%29-from-@INC

> What do you mean by =E2=80=98cleaning =E2=80=9Clib=E2=80=9D of the old Bu=
gZilla=E2=80=99?
> Could you be a bit more specific?

Bugzilla's installation folder ocntains a directory named "lib" and
install-module.pl installs modules into that, so that those are only
visible by Bugzilla by default, you don't need root etc. The problem
with that approach is that nobody handles incompatibilities with newer
Perls which might have been installed during an OS-upgrade.

If install-module.pl installs things linking to system wide Perl-libs,
which are binary incomaptible now, Bugzilla will fail to load its own
libs now. Same with changed dependencies in pure Perl packages
referenced in whatever is installed in "lib".

That's the reason why I always suggest to not use install-module.pl
unless absolutely necessary and why emptying "lib" might solve some
problems already. If the OS-upgrade newly brought Perl packages which
had to be installed manually before, with an empty "lib" those are
used by Bugzilla instead of the private, maybe now broken ones in
"lib".

Mit freundlichen Gr=C3=BC=C3=9Fen,

Thorsten Sch=C3=B6ning

--=20
Thorsten Sch=C3=B6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=C3=A4ftsf=C3=BChrer: Andreas Muchow

0
utf
6/5/2019 7:16:35 AM
Thorsten:

Using your commands I have come to the conclusion that the problem is due=
=20
to a missing directory [lib] in the perl module search path. I would like t=
o add=20
that directory manually. Could you please instruct me as to how to add the=
=20
=E2=80=9Clib=E2=80=9D directory to the local bugzilla search path. Thanks.

On 6/5/19 2:16 AM, Thorsten Sch=C3=B6ning wrote:
> Newer Perls don't contain the current working directory in the paths
> searching for packages, so you might need to add that manually.=20

--=20
Rich Price
0
Richard
6/6/2019 4:12:31 PM
Guten Tag Richard Price,
am Donnerstag, 6. Juni 2019 um 18:12 schrieben Sie:

> Using your commands I have come to the conclusion that the problem is due
> to a missing directory [lib] in the perl module search path. I would like=
 to add
> that directory manually. Could you please instruct me as to how to add the
> =E2=80=9Clib=E2=80=9D directory to the local bugzilla search path. Thanks.

Do you really mean the "lib" folder within the Bugzilla installation
directory? That IS already added to the module search path by Bugzilla
itself with the following lines in each file necessary:

> use lib qw(. lib);

The above is copied from checksetup.pl, without that Bugzilla wouldn't
work that way for anyone. So instead of adding things you should debug
in checksetup.pl:

> use Data::Dumper;
> die(Dumper(@INC));

I guess that contains "lib" already. If that doesn't work, check that
you execute checksetup.pl in the installation dir instead of something
else, so that the current working dir is the installation dir.
Additionally, check permissions on the "lib" folder and stuff.

Might be of help as well to actually print the results of your former
tests.

Mit freundlichen Gr=C3=BC=C3=9Fen,

Thorsten Sch=C3=B6ning

--=20
Thorsten Sch=C3=B6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=C3=A4ftsf=C3=BChrer: Andreas Muchow

0
utf
6/6/2019 5:05:14 PM
On Thursday, June 6, 2019 at 12:05:26 PM UTC-5, Thorsten Sch=C3=B6ning wrot=
e:
> Guten Tag Richard Price,
> am Donnerstag, 6. Juni 2019 um 18:12 schrieben Sie:
>=20
> Might be of help as well to actually print the results of your former
> tests.

Here are the results:
  =20
---
  =20
[hanover]$ cd bugzilla-new
[hanover]$ perl -MDateTime -e "print DateTime->VERSION"
1.46[hanover]$
[hanover]$ cd lib
[hanover]$ perl -MDateTime -e "print DateTime->VERSION"
1.46[hanover]$=20
[hanover]$ perl -I. -MDateTime -e "print DateTime->VERSION"
Devel::StackTrace version 2 required--this is only version 1.30 at /usr/sha=
re/perl5/Exception/Class/Base.pm line 9.
BEGIN failed--compilation aborted at /usr/share/perl5/Exception/Class/Base.=
pm line 9.
Compilation failed in require at /usr/share/perl5/Exception/Class.pm line 1=
0.
BEGIN failed--compilation aborted at /usr/share/perl5/Exception/Class.pm li=
ne 10.
Compilation failed in require at /usr/share/perl5/Params/ValidationCompiler=
/Exceptions.pm line 26.
BEGIN failed--compilation aborted at /usr/share/perl5/Params/ValidationComp=
iler/Exceptions.pm line 26.
Compilation failed in require at /usr/share/perl5/Params/ValidationCompiler=
/Compiler.pm line 11.
BEGIN failed--compilation aborted at /usr/share/perl5/Params/ValidationComp=
iler/Compiler.pm line 11.
Compilation failed in require at /usr/share/perl5/Params/ValidationCompiler=
..pm line 8.
BEGIN failed--compilation aborted at /usr/share/perl5/Params/ValidationComp=
iler.pm line 8.
Compilation failed in require at x86_64-linux-gnu-thread-multi/DateTime/Dur=
ation.pm line 13.
BEGIN failed--compilation aborted at x86_64-linux-gnu-thread-multi/DateTime=
/Duration.pm line 13.
Compilation failed in require at x86_64-linux-gnu-thread-multi/DateTime.pm =
line 14.
BEGIN failed--compilation aborted at x86_64-linux-gnu-thread-multi/DateTime=
..pm line 14.
Compilation failed in require.
BEGIN failed--compilation aborted.
[hanover]$ perl -I~/bugzilla-new/lib -MDateTime -e "print DateTime->VERSION=
"
1.46[hanover]$=20
[hanover]$
0
Richard
6/6/2019 5:38:01 PM
Guten Tag Richard Price,
am Donnerstag, 6. Juni 2019 um 19:38 schrieben Sie:

> [hanover]$ cd bugzilla-new
> [hanover]$ perl -MDateTime -e "print DateTime->VERSION"
> 1.46[hanover]$

From=20my understanding that means that you have DateTime installed
system wide and that can be loaded successfully.

> [hanover]$ cd lib
> [hanover]$ perl -MDateTime -e "print DateTime->VERSION"
> 1.46[hanover]$

Same as above, because "lib" is ".", which is not part of @INC anymore
in your Perl 5.26.1

> [hanover]$ perl -I. -MDateTime -e "print DateTime->VERSION"
> Devel::StackTrace version 2 required--this is only version 1.30 at
> /usr/share/perl5/Exception/Class/Base.pm line 9.

Now you make "lib" part of @INC manually and things fail. That is why
checksetup.pl fails as well, it does exactly the same thing. Whatever
you have installed in "lib" using "install-module.pl" is simply
incompatible with your system wide installed Perl packages.

Search your "lib"-dir for Devel/Stacktrace.pm or something like that,
I guess you find some with version 1.30. Do the same in your system
wide Perl and I guess you find some newer one. In your test or with
Bugzilla "lib" gets precedence, so if an older Devel::Stacktrace is
found there first, that is loaded and breaks if a system wider
Class::Base needs a new version.

As I said before, clean the lib folder. From what I see in
Bugzilla::Install::Requirements, DateTime is needed in version 0.75+,
whcih your system seems to provide already. You don't need to install
it using install-module.pl and get arbitrary other dependencies
breaking your Perl. If the ssystem wide DateTime doesn't work for
checksetup.pl, there's some other problem most likely.

I suggest starting over with a clean "lib" folder, run checksetup.pl
and for each and every missing package checksetup.pl tells you about,
do the same tests you did with DateTime above. Only those packages NOT
available at all system wide try install-module.pl for that one
package only AND redow the test for that package from above. That will
revela if things break again after using install-module.pl

Might be easier of course to

> [hanover]$ perl -I~/bugzilla-new/lib -MDateTime -e "print DateTime->VERSI=
ON"
> 1.46[hanover]$=20

"~" is not resolved as you might think, so this is simply calling
through to loading the system wide package:

> tschoening@potsdam:~$ perl -I~/murks -MData::Dumper -e "print Dumper(@INC=
)"
> $VAR1 =3D '~/murks';
> $VAR2 =3D '/etc/perl';
> $VAR3 =3D '/usr/local/lib/x86_64-linux-gnu/perl/5.22.1';
[...]

"~/murks" is a relative path internally to Perl not existing and
therefore ignored during loading packages. It doesn't resolve
shell-stuff at that point anymore AFAIK.

Mit freundlichen Gr=C3=BC=C3=9Fen,

Thorsten Sch=C3=B6ning

--=20
Thorsten Sch=C3=B6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=C3=A4ftsf=C3=BChrer: Andreas Muchow

0
utf
6/7/2019 6:14:19 AM
Thanks for this information Thorsten.

I have been able to adjust "lib" so that checksetup now works to completion.

This is a link to the output from the final checksetup run.
https://drive.google.com/open?id=1W17tAUcPmumxT-fYvcbINucalFL14km6

But now when I browse the fixed bugzilla site I get the following web page:
https://drive.google.com/open?id=1lODcynvM1jr0Cc8zyui5GnoeDN123YC1

The page seems to have formatting issues. Perhaps a CSS problem.
Can you suggest a next step for me to take?
0
Richard
6/7/2019 6:12:25 PM
Guten Tag Richard Price,
am Freitag, 7. Juni 2019 um 20:12 schrieben Sie:

> I have been able to adjust "lib" so that checksetup now works to completi=
on.

Would be great if you could document what exactly you have done to
fix your setup, as problems like you had are somewhat common.

> But now when I browse the fixed bugzilla site I get the following web pag=
e:
> https://drive.google.com/open?id=3D1lODcynvM1jr0Cc8zyui5GnoeDN123YC1

Check the required settings, especially urlbase and sslbase.
Additionally have a lok at the development tools of your browser,
especially the network tab and see why requesting CSS fails. Then have
a look at the logs of your web server.

https://bugzilla.readthedocs.io/en/5.0/installing/essential-post-install-co=
nfig.html

Sometimes people configure their web server wrongly so that fetching
CSS is forbidden or that it wrongly gets executed as Perl or something=20
like that. Those things are most likely seen using HTTP status 403, 404
and 500 in the dev tools.

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=E4ftsf=FChrer: Andreas Muchow

0
windows
6/8/2019 6:53:08 AM
> > I have been able to adjust "lib" so that checksetup now works to completion.
> 
> Would be great if you could document what exactly you have done to
> fix your setup, as problems like you had are somewhat common.

Thorsten
I will soon start working on the css issue using your suggestions, thanks!

I have created some notes describing the module issue and its fix. 
The following link points to this document. If you have any 
suggestions for a venue to which it should be posted please let me know.
I would also appreciate any edits or issues you may have with it.

https://drive.google.com/open?id=1j0vbd5CEfc4uHssTBqARZPxt0QK63PU3fnDyZD7cjAY


0
Richard
6/9/2019 6:18:32 PM
Guten Tag Richard Price,
am Sonntag, 9. Juni 2019 um 20:18 schrieben Sie:

> https://drive.google.com/open?id=3D1j0vbd5CEfc4uHssTBqARZPxt0QK63PU3fnDyZ=
D7cjAY

The following is the important part I was interested:

> Using this command [and modified versions of it]
>      perl -MDateTime -e "print DateTime->VERSION"
> I was able to determine that DateTime and DateTime::TimeZone
> could be successfully loaded when the Bugzilla.lib directory
> Was omitted from the search path. but the load failed when this
> library was added to the search path. I deleted the bad DateTime
> and DateTime::TimeZone modules from Bugzilla.lib.

Cleaning "lib" should always be done first.

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=E4ftsf=FChrer: Andreas Muchow

0
windows
6/10/2019 7:02:41 AM
Using the Chrome debugger I found that my bugzilla was getting 403 (Forbidden) errors. I believe that I must regenerate .htaccess to solve this problem. 

Before I do I want to  be sure that my proposed procedure is correct.
I intend to first delete the existing .htaccess file and then to run 
checksetup.pl. Is this the correct thing to do?
0
Richard
6/10/2019 3:16:16 PM
Guten Tag Richard Price,
am Montag, 10. Juni 2019 um 17:16 schrieben Sie:

> Using the Chrome debugger I found that my bugzilla was getting 403
> (Forbidden) errors. I believe that I must regenerate .htaccess to solve t=
his problem.

> Before I do I want to  be sure that my proposed procedure is correct.
> I intend to first delete the existing .htaccess file and then to run=20
> checksetup.pl. Is this the correct thing to do?

Yes:

https://bugzilla.mozilla.org/show_bug.cgi?id=3D1270116

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=E4ftsf=FChrer: Andreas Muchow

0
windows
6/10/2019 4:12:37 PM
I deleted .htaccess and reran ./checksetup.pl but the error remains.
Checking, I found that no new ,htaccess file was created by ./checksetup.pl

This is a link to the output from my attempted fix:
https://drive.google.com/open?id=19oYrOMGWWdOxJGGSeReUSecM_Mqlk8Ub
0
Richard
6/10/2019 4:33:30 PM
Guten Tag Richard Price,
am Montag, 10. Juni 2019 um 18:33 schrieben Sie:

> I deleted .htaccess and reran ./checksetup.pl but the error remains.
> Checking, I found that no new ,htaccess file was created by ./checksetup.=
pl

You are in the wrong directory: The .htaccess in the bugzilla
installation dir comes from GIT and is therefore not recreated by
checksetup.pl, so you better restore it.

https://github.com/bugzilla/bugzilla/blob/5.0/.htaccess

Your CSS-error comes most likely from .htaccess in the "data" folder,
as that is what gets created by checksetup.pl and that's where CSS is
served from. You need to delete all of those and rerun checksetup.pl
and should see new files created.

In fact there are other .htaccess files in others dirs as well, but
those might not  be responsible for your problem.

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch=E4ftsf=FChrer: Andreas Muchow

0
windows
6/10/2019 5:37:40 PM
> Your CSS-error comes most likely from .htaccess in the "data" folder,
> as that is what gets created by checksetup.pl and that's where CSS is
> served from. You need to delete all of those and rerun checksetup.pl
> and should see new files created.
>
Yes it was the "data" folder. It seems to be working now!

Thanks for all of your help.
0
Richard
6/10/2019 6:15:25 PM
Reply: