(In reply to V P from comment #0)
> You will first get an error message asking you to run "checksetup.pl".

When you install the bugzilla RPM, it asks you to run checksetup.pl before anything else. So this error is expected if you didn't do it.


> However, this also not work the first time because you have incompatible
> options in the file named "localconfig". Hopefully, the second time it works
> because the incompatible options are moved to another file. 

If you get errors about localconfig, this means that there are either new parameters which you may have to edit to match your installation, or that existing parameters are not set correctly. This step is also expected.


> However, when I try to log in, there is no skin applied : the page is plain
> black and white and looks ugly.
> 
> By looking at the firefox developer mode, I can see that it's trying to load
> js files located under /var/lib, for instance:
> http://10.166.120.152/var/lib/bugzilla/assets/
> 1b4e898422a669ab82b604a2c23edce5.js

This is the single issue. The URL is incorrectly built (packaging issue, not an upstream issue).


> The firefox developer mode also tells me there are references to "YAHOO"
> which are unknown to firefox : "ReferenceError: YAHOO is not defined"

This is still the same issue. If it cannot load the JS file, then the YAHOO variable is undefined.


> Seems to happen after an upgrade rom MGA5 to MGA6 with "bugzilla" installed.

The issue is related to the Bugzilla 5.0 RPM itself (Mageia 5 has Bugzilla 4.4).

I will give it a look.

CC: (none) => LpSolit

One easy solution is to edit /usr/share/bugzilla/lib/Bugzila/Constants.pm, line 216 and to set CONCATENATE_ASSETS to 0:

use constant CONCATENATE_ASSETS => 0;

Then run checksetup.pl again and the problem is gone.

Thanks for this precise answer I will only be able to test in 15 days but I'll give you feeback by then

Created attachment 9612 [details]
patch for Bugzilla 5.0.x

Due to the way Bugzilla is packaged by Mageia, here is a fix for its RPM:

1) Apply the attached patch to force Bugzilla to remove the undesired leading /var/lib/bugzilla/ path (Bugzilla expects $datadir to be a relative path, not an absolute path).


2) Edit /etc/httpd/conf/sites.d/bugzilla.conf:

2a) Missing:

  Alias /bugzilla/graphs /var/lib/bugzilla/graphs
  Alias /bugzilla/webdot /var/lib/bugzilla/webdot

  <Directory /var/lib/bugzilla>
      AllowOverride All
  </Directory>


2b) Remove:

  # The dot files must be accessible to the public webdot server
  # The png files locally created locally must be accessible
  <Directory /var/lib/bugzilla/webdot>
      <FilesMatch \.dot$>
          Require host research.att.com
      </FilesMatch>

      <FilesMatch \.png$>
          Require all granted
      </FilesMatch>
  </Directory>

Bugzilla already generates its own .htaccess files. Please don't mess with them.


2c) I removed the trailing / to this line (not sure it matters, but for consistency...):

  Alias /bugzilla/data /var/lib/bugzilla


3) apachectl restart (I hope the RPM can do that automatically, else changes will be ignored till next restart).

Assigning to Bugzilla's registered maintainer.

@ Frédéric

Thanks for your help :-)
Can the patch already be packaged, or do you want it to be tested first?

Assignee: bugsquad => shlomif
CC: (none) => marja11
Keywords: (none) => PATCH

(mga6 and cauldron both have bugzilla-5.0.3-1.mga6)

Whiteboard: (none) => MGA6TOO
Version: 6 => Cauldron

(In reply to Marja van Waes from comment #5)
> Can the patch already be packaged, or do you want it to be tested first?

It can be packaged.

(In reply to Frédéric Buclin from comment #7)
> (In reply to Marja van Waes from comment #5)
> > Can the patch already be packaged, or do you want it to be tested first?
> 
> It can be packaged.

Hi Frederic!

What will help me even more is a patch against the mgarepo checkout. E.g:

1. mgarepo co bugzilla
2. cd bugzilla
3. "Hack, hack, hack"
4. mgarepo sync -d
5. svn di > ~/my.patch

Can you provide it preferably with as little trailing space (see http://perl-begin.org/tutorials/bad-elements/#trailing-whitespace ) as possible?

mgarepo doesn't work for me:

$ mgarepo co bugzilla
Warning: Permanently added 'svn.mageia.org,2a02:2178:2:7::9' (RSA) to the list of known hosts.
Permission denied (publickey,keyboard-interactive).
svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.mageia.org/svn/packages/cauldron/bugzilla/current'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly

(In reply to Frédéric Buclin from comment #9)
> mgarepo doesn't work for me:
> 
> $ mgarepo co bugzilla
> Warning: Permanently added 'svn.mageia.org,2a02:2178:2:7::9' (RSA) to the
> list of known hosts.
> Permission denied (publickey,keyboard-interactive).
> svn: E170013: Unable to connect to a repository at URL
> 'svn+ssh://svn.mageia.org/svn/packages/cauldron/bugzilla/current'
> svn: E210002: To better debug SSH connection problems, remove the -q option
> from 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: E210002: Network connection closed unexpectedly

sorry for the late reply. You can still use mgarepo by editing /etc/mgarepo.conf and following the instructions there. Also see https://wiki.mageia.org/en/Mgarepo . Looking forward to your patch.

Created attachment 9613 [details]
patch for the bugzilla RPM

Here we go. It builds correctly, and installs fine. I tested it briefly, and everything works ok.

Attachment 9612 is obsolete: 0 => 1

fixed on svn ( sorry i forgotten to tell that the patch was from you so i tell here:


THANK YOU :)

CC: (none) => mageia
Status: NEW => RESOLVED
Resolution: (none) => FIXED

pushed in updates_testing
src.rpm:
        bugzilla-5.0.3-1.1.mga6

Assignee: shlomif => qa-bugs
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Testing the update with 
$ urpmi.update Core\ Updates\ Testing
$ urpmi --search-media Core\ Updates\ Testing bugzilla

... and it works fine. Thanks.

Oh no... it worked until I restarted apache.

It looks like the .htaccess under "assets" doesn't work - I get a permission denied.

Could be because of a general AllowOverride directive in httpd.conf which also got updated (and I have an .rpmnew) but I didn't merge the changes yet... I'll have a look.

Did not find the exact root cause but .htaccess under /var/lib/bugzilla/assets is using a mix of 2.2 and 2.4 syntax and I think apache doesn't like it.

By slightly modifying the .htaccess file, it works correctly, see my file below:

# Allow access to .css files
<FilesMatch \.(css|js)$>
  <IfModule mod_version.c>
    <IfVersion < 2.4>
      Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
      Require all granted
# >>>> Added the following directive <<<<<
      Allow from all
    </IfVersion>
  </IfModule>

Same problem with the .htaccess file under "webdot" directory: it's using apache 2.2 syntax but does not work well here: I have to add a "Require all granted" directive to be able to see dependency graphs...

(In reply to V P from comment #16)
> Did not find the exact root cause but .htaccess under
> /var/lib/bugzilla/assets is using a mix of 2.2 and 2.4 syntax and I think
> apache doesn't like it.

This mix is intentional as not everybody runs Apache 2.4. This mix is fine.


>     <IfVersion >= 2.4>
>       Require all granted
> # >>>> Added the following directive <<<<<
>       Allow from all
>     </IfVersion>

This change is incorrect. Apache 2.4 no longer supports the Allow from all syntax, unless being in compat mode.


(In reply to V P from comment #15)
> Could be because of a general AllowOverride directive in httpd.conf which
> also got updated (and I have an .rpmnew) but I didn't merge the changes
> yet... I'll have a look.

You have to accept the new config file in order for things to work correctly.

Ok but then see comment #17: why does bugzilla itself includes .htaccess files with "allow from all" directive. It looks like not all htaccess files have been migrated to use 2.4 syntax.

(In reply to V P from comment #19)
> Ok but then see comment #17: why does bugzilla itself includes .htaccess
> files with "allow from all" directive. It looks like not all htaccess files
> have been migrated to use 2.4 syntax.

All .htaccess files should work out of the box with Apache 2.4. Mageia 5 initially released Bugzilla 4.4.9, which was the first version to support Apache 2.4. So unless your Bugzilla installation was initially created in Mageia 4 or older, you shouldn't have any .htaccess file with "allow from all" alone.

The release notes for Bugzilla 5.0.2 ask Bugzilla administrators to manually delete old .htaccess files and to regenerate them to correctly fix a problem with mod_perl, see:

https://www.bugzilla.org/releases/5.0.2/release-notes.html#point


If you think some of your .htaccess files are incorrect, you should delete and regenerate them using a command similar to the one given in the release notes above (I say similar, because upstream assumes all Bugzilla files are under one given bugzilla directory, while Mageia packagers split them between several directories).

If you think one of the .htaccess files is still not correct after the regeneration, please paste its content in this bug.

Removing .htaccess files and regenerating them with checksetup.pl fixed the issue. Now things work properly. Some .htaccess were indeed generated under mga3.

The least we should do is mention this problem in the errata / release notes. 

Maybe more automated but less clean: have the package remove .htaccess files and automatically run checksetup.pl.

(In reply to V P from comment #21)
> Removing .htaccess files and regenerating them with checksetup.pl fixed the
> issue. Now things work properly. Some .htaccess were indeed generated under
> mga3.

OK, so this was indeed the problem. :)


> Maybe more automated but less clean: have the package remove .htaccess files
> and automatically run checksetup.pl.

I thought about that too. But this is not a good idea to run checksetup.pl automatically, because you would loose its output, and this would be problematic if installing Bugzilla for the first time (because checksetup.pl would wait for the new admin login name and password forever) or when doing a major upgrade, such as Bugzilla 4.4 -> 5.0 (due to new parameters).

I think we should update README.urpmi to mention that if Bugzilla was initially installed on Mageia 4 or older, then all .htaccess files (except the one in the bugzilla directory) should be removed and recreated by running checksetup.pl. We could even provide a small script to delete them safely. :)

Yes, README.urpmi is a good location. I must admit it wouldn't have been enough for me as I did not read this file (but I read the release notes / errata).

Talking about README.urpmi, I would scratch the last part entirely (additional packages) because checksetup.pl gives the exact same information but more accurate and up-to-date.

I would also provide more details for the step "create a database in one of: MySQL/MariaDB/PostgreSQL". Or maybe we should provide a script performing these steps interactively:
* Create the DB if not existing
* Remove old .htaccess
* Run checksetup.pl

Please clarify some thing sbout this update.

1. (In reply to Nicolas Lécureuil from comment #13)
> pushed in updates_testing
> src.rpm:
>         bugzilla-5.0.3-1.1.mga6
Is this the final update anticipated for now? There have been 10 mostly problematic comments subsequently. Is it proposed to implement any of the additional tweaks proposed - even agreed in principle? Or problems encountered by V_P?

2. Does this update apply to just M5 -> M6 upgrades? Or is it also applicable to a new Bugzilla install on M6? Can one test it like this: install Bugzilla, update it? Or would this prove nothing (beyond a clean update)?

CC: (none) => lewyssmith

(In reply to Lewis Smith from comment #24)
> Is this the final update anticipated for now? There have been 10 mostly
> problematic comments subsequently. Is it proposed to implement any of the
> additional tweaks proposed - even agreed in principle? Or problems
> encountered by V_P?

My proposal in comment 22 can come later as only installations from Mageia 4 and older are affected.


> 2. Does this update apply to just M5 -> M6 upgrades? Or is it also
> applicable to a new Bugzilla install on M6? Can one test it like this:
> install Bugzilla, update it? Or would this prove nothing (beyond a clean
> update)?

The skin problem is visible in both cases: either a new installation or an upgrade.

(In reply to Frédéric Buclin from comment #25)
> (In reply to Lewis Smith from comment #24)
> > 2. Does this update apply to just M5 -> M6 upgrades? Or is it also
> > applicable to a new Bugzilla install on M6? Can one test it like this:
> > install Bugzilla, update it? Or would this prove nothing (beyond a clean
> > update)?
> The skin problem is visible in both cases: either a new installation or an
> upgrade.
Thank you for that.

About to try this for M6/64, using PostgreSQL.
 https://bugs.mageia.org/show_bug.cgi?id=16776#c14
onwards provides useful installation & configuration info & pointers.

# urpmi bugzilla
immediately requires & proposes a Mail Transport Agent! Chose 'postfix'.
post-installation:
 - create a database in one of: MySQL/MariaDB/PostgreSQL
 - run /usr/share/bugzilla/bin/checksetup.pl

1. Use postgreSQL (already installed)
 # su - postgres

2. Create Bugzilla user 'bugs' + its password
 [postgres@localhost ~]$ createuser -U postgres -dRSP bugs
 Enter password for new role: 
 Enter it again: 
 [postgres@localhost ~]$ exit
 logout

3. Edit /var/lib/pgsql/data/pg_hba.conf as Bugzilla advise
 # vi /var/lib/pgsql/data/pg_hba.conf                     [to add the line:
host   all    bugs   127.0.0.1    255.255.255.255  md5

4. Run checksetup.pl 1st time
 # /usr/share/bugzilla/bin/checksetup.pl
* This is Bugzilla 5.0.3 on perl 5.22.3
* Running on Linux 4.9.43-tmb-desktop-1.mga6 #1 SMP PREEMPT Sun Aug 13 19:34:40 UTC 2017
Checking for...
Lots of 'found' and in red 'not found'. No matter, I think. Finishes:
"Please edit the file /etc/bugzilla/localconfig and then re-run checksetup.pl
to complete your installation."

5. Edit /etc/bugzilla/localconfig for database
($db_name = 'bugs'; & $db_user = 'bugs'; lines already correct).
 # vi /etc/bugzilla/localconfig                          [altered lines:
$db_driver = 'Pg';                                       [from Mysql]
$db_pass = '<DBpassword>';

6. Run checksetup.pl 2nd time
 # /usr/share/bugzilla/bin/checksetup.pl
Lots of output, including creating the DB. Finally questions:
...
Enter the e-mail address of the administrator: <valid e-mail address>
Enter the real name of the administrator: <apparently first & second names>
Enter a password for the administrator account:
Please retype the password to verify:
<the e-mail address> is now set up as an administrator.   [The LOGIN NAME]
...
"checksetup.pl complete."

6. Try testserver
 # /usr/share/bugzilla/bin/testserver.pl http://localhost/bugzilla/
 TEST-OK Webserver is running under group id in $webservergroup.
 TEST-FAILED Fetch of images/padlock.png failed
 Your web server could not fetch http://localhost/bugzilla/images/padlock.png.
 Check your web server configuration and try again.
Same as in the M5 installation procedure referred to; basically OK.

7. Try to connect
 http://localhost/bugzilla/               gave 404
 http://localhost/bugzilla/index.cgi      gave 404
Worse than previous M5 procedure, where I could at least login/out.
To investigate.

BEWARE
As previously, I found that my *home directory* had been hijacked:
 [root@localhost home]# ls -al lewis
 drwxr-x--- 35 root  apache  4096 Med  11 09:17 ./
Had to chown & chgroup it back to myself:
 [root@localhost home]# chown lewis:lewis lewis
 [lewis@localhost home]$ ls -l
 drwxr-x--- 35 lewis lewis 4096 Med  11 09:17 lewis/

Since this seems a long-term issue, bug it?

[Damn, just lost a pack of comments]
Continuing M6/64 installation/configuration.

Mystery: this skinless problem is a repeat of itself found in bug
 https://bugs.mageia.org/show_bug.cgi?id=16776
which proposed an update from bugzilla-4.4.9-1.mga5 (which had the problem) to bugzilla-4.4.10-1.mga5, never issued and replaced during testing by
bugzilla-4.4.11-1.mga5, which fixed the problem.

BEFORE the update: bugzilla-5.0.3-1.mga6
Re-booted, and lo! http://localhost/bugzilla/ shows the skinless Entry page, from which I could log in. First time, that goes to another page saying you should configure a few more things, with appropriate links; particularly:
- urlbase -> http://localhost/bugzilla/
- cookiepath -> /bugzilla/            [suggested]
- maintainer -> admin e-mail address as per step 6 above, pre-set thus.
(Do not forget 'save changes').

Without a skin (this bug/update), it is difficult to use. 

AFTER update to: bugzilla-5.0.3-1.1.mga6
which pulled in >20 additional pkgs.
Alas, bugzilla still had no skin.
 # systemctl restart httpd
resolved that.
 http://localhost/bugzilla/ showed the familiar "Welcome to Bugzilla" page. For administration, http://localhost/bugzilla/admin.cgi did the trick, with an admin login dialogue. All nicely displayed.
Added a dummy bug just to make sure it works... Update OK.

@ Nicolas or Frédéric
This needs an advisory. I can invent one if you wish from Comment 13; or you propose one.

Whiteboard: (none) => MGA6-64-OK

> @ Nicolas or Frédéric
> This needs an advisory. I can invent one if you wish from Comment 13;
> or you propose one.
Setting feedback for a response re an Advisory.

Keywords: (none) => feedback

Advisory (no idea if it's correctly formatted):

This update fixes several issues:
- Paths to CSS and JS files were not correctly formatted, making Bugzilla to be
  displayed without any theme.
- Several perl dependencies were missing to make Bugzilla run correctly.
- Python is no longer a dependency (it was used in some contributed scripts only,
  not used by Bugzilla itself).
- Dependency graphs and charts are working again.

Also, if your Bugzilla installation has been initially created in Mageia 4 or older,
you may have to delete .htaccess files in Bugzilla subdirectories to make your
installation work with Apache 2.4, see the upstream release notes:

  https://www.bugzilla.org/releases/5.0.2/release-notes.html#point

As for all Bugzilla updates, make sure to run checksetup.pl from a shell.

Keywords: feedback => (none)

Thank you Frédéric. Advisory from comments 29 & 13.
Validating as it has a 64-bit OK, Mageia 6 only.

Keywords: (none) => advisory, validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2017-0082.html

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED