313739 - "graphs" directory location is presumed to be in its standard location

Status: RESOLVED FIXED

(Bugzilla :: Reporting/Charting, enhancement)

Description

[Joel Peshkin]

The "graphs" directory is presumed to be in its standard location.  This causes th debian packagers to miss it.  It should be specified in Bugzilla/Config.pm much as $datadir and $webdotdir are.

Comment 1

[Frédéric Buclin]

a dupe of bug 280180?

Comment 2

[Gervase Markham [:gerv]]

No; this is a different issue.

Gerv

Comment 3

[Frédéric Buclin]

joel, I don't see how this could be a blocker for 2.20. It's not a bug, but an enhancement, in the same way as bug 280180 is.

Comment 4

[Dave Miller [:justdave]]

agreed.  This has been an ongoing target and something we're striving to make easier for the packagers, but it's not something that's critical to Bugzilla functioning (it just means the packagers have bigger patches to write until we fix it).

Comment 5

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 6

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

Comment 7

[GavinS]

Also, the graph dir is not PROJECT aware, from bug#419014

Comment 8

[Emmanuel Seyman]

It appears this is also needed by the Fedora package. Taking.

Comment 9

[Emmanuel Seyman]

Attachment: make all references to the graph directory use $graphdir

Fairly straightforward.

Comment 10

[Frédéric Buclin]

Comment on attachment 436438 [details] [diff] [review]
make all references to the graph directory use $graphdir

>Index: reports.cgi

>-my $graph_url = 'graphs';
>-my $graph_dir = bz_locations()->{'libpath'} . '/' .$graph_url;
>+my $graph_dir = bz_locations()->{'graphdir'};
>+my ($graph_url) = ($graph_dir  =~ s/.*\///);

Not sure what you are trying to do here. .*\/ seems dangerous to me.
Do you mean [^\/]*\/ ? If 'graphs' is not in the same directory as CGI scripts, this path won't work, right? Same if libpath contains an absolute path.



>Index: Bugzilla/Constants.pm

>+        'graphdir' => "$libpath/graphs2",

Why 'graphs2'?


Otherwise looks good.

Comment 11

[Emmanuel Seyman]

(In reply to comment #10)
>
> Not sure what you are trying to do here. .*\/ seems dangerous to me.
> Do you mean [^\/]*\/ ?

I'm actually looking for the last directory (the basename function without having to drag in File::Basename as a requirement).

Then again, I suspect that "$datadir/graphs" would be a better choice for this since it would make reports.cgi $PROJECTS-compliant.

> >+        'graphdir' => "$libpath/graphs2",
> 
> Why 'graphs2'?

So that I can tell if my changes work. :-|

Comment 12

[Emmanuel Seyman]

Attachment: same thing with basename()

Looking back on this, it turns out that .*\/ is actually what I wanted. I also realized that Bugzilla::Constants loads File::Basename so there's no problem with adding it as a requirement to reports.cgi.

Comment 13

[Frédéric Buclin]

The patch will be bitrotten by bug 561797 (which should land first as it's a security patch, and it's always a pain to backport/maintain them).

Comment 14

[Emmanuel Seyman]

Comment on attachment 437969 [details] [diff] [review]
same thing with basename()

Withdrawing my review request. I'll resubmit a patch later.