From bugdude1 at syndicomm.com  Fri Jan  3 13:47:11 2003
From: bugdude1 at syndicomm.com (Dave Miller)
Date: Fri, 3 Jan 2003 08:47:11 -0500
Subject: [ANN] Bugzilla 2.14.5 Released
In-Reply-To: <73230.1041593859@thrush.ravenbrook.com>
References: <73230.1041593859@thrush.ravenbrook.com>
Message-ID: <a05200f00ba3b38b1b0af@[192.168.1.203]>

On 1/3/03 11:37 AM +0000, Nick Barnes wrote:

> At 2003-01-02 21:17:32+0000, David Miller writes:
>> The Bugzilla Team is pleased to announce the release of Bugzilla 2.14.5.
>>
>> 2.14.5 is the latest release on the 2.14 branch and fixes two security bugs
>> in Bugzilla 2.14.4. For more detailed information, review the latest
>> Bugzilla status report available at
>> http://www.bugzilla.org/status_reports/2002-09-22.html .
>>
>> The Bugzilla team strongly recommends all 2.14.x users upgrade at least to
>> 2.14.5, if not 2.16.2, due to the security bugs fixed in this release.
>
> What's the current advice for Windows users?

Go ahead and get 2.14.5 for now, if you're still running 2.14.x on Windows.

Bugzilla was never intended to run on Windows, and although we do intend to
make it able to run on Windows in the near future, it has always in the
past required lots of hacking to run on Windows, so the work required to
install 2.16.2 won't be much worse than it was to install 2.12 or 2.14 when
they first put it in.  That's one of the dangers of installing software on
a platform it's not supported on.

Hopefully it'll be much less work for them to install 2.18 (or one of the
2.17's in the near future).  It would make me very happy if we could have a
2.17.4 that ran out of the box on Windows.  The one bug that makes 2.16
worse than 2.14 for the amount of hacking required is the mail processing
(http://bugzilla.mozilla.org/show_bug.cgi?id=84876).  Hopefully there won't
be any more security bugs, but just to be safe, we need to make that bug a
priority in the short term so Windows users have somewhere to go.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From justdave at syndicomm.com  Mon Jan  6 22:38:07 2003
From: justdave at syndicomm.com (David Miller)
Date: Mon, 6 Jan 2003 17:38:07 -0500
Subject: Internationalization Support
Message-ID: <a05200f0cba3fb511a4b8@[192.168.1.203]>

There's some folks at Netscape who have a strong interest in making
Bugzilla be completely i18n in the near future.

Seems like the most obvious thing to do would be to force everything to be
UTF-8, everywhere.

However, digging around and doing a little research, it looks like we'd
need to use perl 5.8.0 and MySQL 4.1 in order to pull that off...

Anyone have some ideas for sure what we'd need to do for this?  I'd like to
kind of figure out what I'm getting myself into. :-)
-- 
Dave Miller          Project Leader, Bugzilla Bug Tracking System
Webtools Developer, Netscape Client QA   http://www.bugzilla.org/


From dkl at redhat.com  Mon Jan  6 22:53:21 2003
From: dkl at redhat.com (Dave Lawrence)
Date: 06 Jan 2003 17:53:21 -0500
Subject: Internationalization Support
In-Reply-To: <a05200f0cba3fb511a4b8@[192.168.1.203]>
References: <a05200f0cba3fb511a4b8@[192.168.1.203]>
Message-ID: <1041893600.1519.12.camel@mrhanky.devel.redhat.com>

Seems to be working for us here using 2.17.1. I created the database and
told it to use UTF-8 for the database encoding. Then added the following
META tag to the header template

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

People have since been able to view and input international characters
if the browser supports it.

On Mon, 2003-01-06 at 17:38, David Miller wrote:
> There's some folks at Netscape who have a strong interest in making
> Bugzilla be completely i18n in the near future.
> 
> Seems like the most obvious thing to do would be to force everything to be
> UTF-8, everywhere.
> 
> However, digging around and doing a little research, it looks like we'd
> need to use perl 5.8.0 and MySQL 4.1 in order to pull that off...
> 
> Anyone have some ideas for sure what we'd need to do for this?  I'd like to
> kind of figure out what I'm getting myself into. :-)


From justdave at syndicomm.com  Mon Jan  6 22:51:21 2003
From: justdave at syndicomm.com (David Miller)
Date: Mon, 6 Jan 2003 17:51:21 -0500
Subject: Internationalization Support
In-Reply-To: <1041893600.1519.12.camel@mrhanky.devel.redhat.com>
References: <a05200f0cba3fb511a4b8@[192.168.1.203]>
 <1041893600.1519.12.camel@mrhanky.devel.redhat.com>
Message-ID: <a05200f0dba3fb8bd80e1@[192.168.1.203]>

On 1/6/03 5:53 PM -0500, Dave Lawrence wrote:

> Seems to be working for us here using 2.17.1. I created the database and
> told it to use UTF-8 for the database encoding. Then added the following
> META tag to the header template
>
> <meta http-equiv="content-type" content="text/html; charset=UTF-8">
>
> People have since been able to view and input international characters
> if the browser supports it.

OK, and you're using PostgreSQL obviously (which already support UTF8 -
MySQL doesn't yet).  What version of Perl are you using?
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From dkl at redhat.com  Mon Jan  6 23:08:59 2003
From: dkl at redhat.com (Dave Lawrence)
Date: 06 Jan 2003 18:08:59 -0500
Subject: Internationalization Support
In-Reply-To: <a05200f0dba3fb8bd80e1@[192.168.1.203]>
References: <a05200f0cba3fb511a4b8@[192.168.1.203]>
	 <1041893600.1519.12.camel@mrhanky.devel.redhat.com>
	 <a05200f0dba3fb8bd80e1@[192.168.1.203]>
Message-ID: <1041894539.1519.15.camel@mrhanky.devel.redhat.com>

Ah sorry, forgot to mention that we are using PostgreSQL. Did not
realize that MySQL did not yet support UTF-8. Is that a 4.x thing? I
have perl-5.6.0-12 installed on the web server itself. 

You can reference one of the internationalization bugs entered into our
instance at

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80349

On Mon, 2003-01-06 at 17:51, David Miller wrote:
> On 1/6/03 5:53 PM -0500, Dave Lawrence wrote:
> 
> > Seems to be working for us here using 2.17.1. I created the database and
> > told it to use UTF-8 for the database encoding. Then added the following
> > META tag to the header template
> >
> > <meta http-equiv="content-type" content="text/html; charset=UTF-8">
> >
> > People have since been able to view and input international characters
> > if the browser supports it.
> 
> OK, and you're using PostgreSQL obviously (which already support UTF8 -
> MySQL doesn't yet).  What version of Perl are you using?


From bbaetz at student.usyd.edu.au  Tue Jan  7 08:02:06 2003
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Tue, 7 Jan 2003 19:02:06 +1100
Subject: Internationalization Support
In-Reply-To: <a05200f0cba3fb511a4b8@[192.168.1.203]>
References: <a05200f0cba3fb511a4b8@[192.168.1.203]>
Message-ID: <20030107080206.GA1174@mango.home>

On Mon, Jan 06, 2003 at 05:38:07PM -0500, David Miller wrote:
> There's some folks at Netscape who have a strong interest in making
> Bugzilla be completely i18n in the near future.
> 
> Seems like the most obvious thing to do would be to force everything to be
> UTF-8, everywhere.
> 
> However, digging around and doing a little research, it looks like we'd
> need to use perl 5.8.0 and MySQL 4.1 in order to pull that off...
> 

Well, that depends on how you define 'support' :)

AIUI, given a valid utf8 string, we don't have to worry about it
matching only part of another utf8 byte in another string. This is due
to the prefix bytes, and so on.

Since we don't use database stuff like length and so on, we should be
able to get away with what we have. The only thing we would need is
input validation, and then the perl code cna treat everything as bytes
(with |use bytes|)

I think a first step would be to do that, possibly only supporting
comments/summary/status whiteboard if its easier to do that way. (I
don't think it is, though. UTf8 platform/OS will be more difficult,
because it in localconfig. We can live without that, I think)

'Validation' may be better off being done by modifying CGI.pm, because
its simpler that way. We may need to require 5.6.1 though, or at least
strongly recommend it.

Bradley


From gerv at mozilla.org  Thu Jan  9 09:30:38 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 09 Jan 2003 09:30:38 +0000
Subject: Why did we use this phrase?
Message-ID: <3E1D413E.40408@mozilla.org>

 From LWN's "security updates" list:

"A cross site scripting vulnerability has been reported for Bugzilla, a 
web-based bug tracking system. Bugzilla does not properly sanitize any 
input submitted by users. As a result, it is possible for a remote 
attacker to create a malicious link containing script code which will be 
executed in the browser of a legitimate user, in the context of the 
website running Bugzilla. This issue may be exploited to steal 
cookie-based authentication credentials from legitimate users of the 
website running the vulnerable software."

Or, for the people who only read the first two sentences:

"A cross site scripting vulnerability has been reported for Bugzilla, a 
web-based bug tracking system. Bugzilla does not properly sanitize any 
input submitted by users. ..."

Why did we use that second sentence in our advisory? Taken at its 
obvious meaning, it's totally untrue, and it makes us look like clueless 
idiots who don't know the first thing about web app security.

A better sentence might have been "Up until two years ago, Bugzilla did 
not properly sanitize quips submitted by users."

Gerv



From justdave at syndicomm.com  Thu Jan  9 09:33:17 2003
From: justdave at syndicomm.com (David Miller)
Date: Thu, 9 Jan 2003 04:33:17 -0500
Subject: Why did we use this phrase?
In-Reply-To: <3E1D413E.40408@mozilla.org>
References: <3E1D413E.40408@mozilla.org>
Message-ID: <a05200f16ba42f200eb88@[192.168.1.203]>

On 1/9/03 9:30 AM +0000, Gervase Markham wrote:

> Why did we use that second sentence in our advisory? Taken at its
> obvious meaning, it's totally untrue, and it makes us look like clueless
> idiots who don't know the first thing about web app security.

We didn't.

Debian took it upon themselves to rewrite our advisory and everyone else
has been copying theirs.

Both Debian and SecurityFocus have already issued corrections at my
request.  But it's too late for everyone who already copied it.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Thu Jan  9 09:44:22 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 09 Jan 2003 09:44:22 +0000
Subject: Why did we use this phrase?
In-Reply-To: <a05200f16ba42f200eb88@[192.168.1.203]>
References: <3E1D413E.40408@mozilla.org> <a05200f16ba42f200eb88@[192.168.1.203]>
Message-ID: <3E1D4476.70509@mozilla.org>

>>Why did we use that second sentence in our advisory? Taken at its
>>obvious meaning, it's totally untrue, and it makes us look like clueless
>>idiots who don't know the first thing about web app security.
> 
> We didn't.

Oh. :-) I'm sure I noticed that phrase in one of our drafts. But maybe I 
was hallucinating.

Gerv



From justdave at syndicomm.com  Thu Jan  9 09:44:00 2003
From: justdave at syndicomm.com (David Miller)
Date: Thu, 9 Jan 2003 04:44:00 -0500
Subject: Why did we use this phrase?
In-Reply-To: <3E1D4476.70509@mozilla.org>
References: <3E1D413E.40408@mozilla.org>
 <a05200f16ba42f200eb88@[192.168.1.203]> <3E1D4476.70509@mozilla.org>
Message-ID: <a05200f18ba42f4a08922@[192.168.1.203]>

On 1/9/03 9:44 AM +0000, Gervase Markham wrote:

>>>Why did we use that second sentence in our advisory? Taken at its
>>>obvious meaning, it's totally untrue, and it makes us look like clueless
>>>idiots who don't know the first thing about web app security.
>>
>> We didn't.
>
> Oh. :-) I'm sure I noticed that phrase in one of our drafts. But maybe I
> was hallucinating.

We didn't.  Trust me.  I went ballistic when I saw Debian's advisory and
went back to check to make sure. :)  I raised hell with both them and
SecurityFocus over it (SecurityFocus had that wording on their website as
well).
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From Timo.Huebel at ClassiX.de  Thu Jan  9 10:02:34 2003
From: Timo.Huebel at ClassiX.de (Timo.Huebel at ClassiX.de)
Date: Thu, 9 Jan 2003 11:02:34 +0100 
Subject: P4DTI: Leading zeros in jobnames
Message-ID: <B10181E022CCD411B19200037489093209F9B9@DFU>

Hi,

i am using Bugzill with the P4DTI and want to know, if it is possible, to
get some leading zeros in the jobnames when using the option
use_perforce_jobname=0.

Thanks in advance,
Timo

-- 
Timo H?bel
ClassiX Software GmbH
Alter Teichweg 25a
22081 Hamburg
E-Mail: timo.huebel at classix.de
URL: http://www.classix.de

Sitz der Gesellschaft: Hamburg
AG Hamburg, HRB 36750
Gesch?ftsf?hrer: Stefan G. Brenner, Peter Matthes



From justdave at syndicomm.com  Thu Jan  9 10:29:39 2003
From: justdave at syndicomm.com (David Miller)
Date: Thu, 9 Jan 2003 05:29:39 -0500
Subject: Fwd: [SECURITY] [DSA 218-1] New bugzilla packages fix cross site
 scripting problem
Message-ID: <a05200f1eba42fe14c060@[192.168.1.203]>


----- Begin Forwarded Text -----

Date: Mon, 30 Dec 2002 13:43:09 -0500
To: security at debian.org, joey at infodrom.org
From: David Miller <justdave at syndicomm.com>
Subject: Fwd: [SECURITY] [DSA 218-1] New bugzilla packages fix cross site
scripting problem
Cc:
Bcc:
X-Attachments:

Is there a reason this was worded the way it was?  "Bugzilla does not
properly sanitize any input submitted by users" without any additional
clarification in the same sentence (or even in the same paragraph) is an
outright lie, because input is validated hopefully everywhere.  The input
validation bug specifically-referenced in this advisory was fixed in
version 2.12 of Bugzilla (current stable version is 2.16.1), and the vast
majority of the input validation bugs were resolved prior to the previous
Debian package that you released.  Although you do clarify it in the
following paragraph, people who aren't using Bugzilla and just reading it
as an FYI would likely read the first paragraph and go on to the next
email, and this paints a falsely negative image of Bugzilla as a whole by
claiming we're not doing any input validation when we are.

Don't get me wrong, even one little HTML encoding issue like this is a
serious issue (which is why we sent out a security advisory of our own
about it when it was discovered), so I'm not trying to make light of the
issue.  I'm only concerned with your wording in the Debian advisory.

----- Begin Forwarded Text -----

Date: Mon, 30 Dec 2002 15:11:17 +0100 (CET)
From: joey at infodrom.org (Martin Schulze)
Subject: [SECURITY] [DSA 218-1] New bugzilla packages fix cross site
scripting problem
Mail-Followup-To: bugtraq at securityfocus.com
To: bugtraq at securityfocus.com
Resent-Date: Mon, 30 Dec 2002 08:17:26 -0600 (CST)
Resent-From: list at murphy.debian.org (SmartList)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --------------------------------------------------------------------------
Debian Security Advisory DSA 218-1                     security at debian.org
http://www.debian.org/security/                             Martin Schulze
December 30th, 2002                     http://www.debian.org/security/faq
- --------------------------------------------------------------------------

Package        : bugzilla
Vulnerability  : cross site scripting
Problem-Type   : remote
Debian-specific: no
BugTraq Id     : 6257

A cross site scripting vulnerability has been reported for Bugzilla, a
web-based bug tracking system.  Bugzilla does not properly sanitize
any input submitted by users.  As a result, it is possible for a
remote attacker to create a malicious link containing script code
which will be executed in the browser of a legitimate user, in the
context of the website running Bugzilla.  This issue may be exploited
to steal cookie-based authentication credentials from legitimate users
of the website running the vulnerable software.

This vulnerability only affects users who have the 'quips' feature
enabled and who upgraded from version 2.10 which did not exist inside
of Debian.  The Debian package history of Bugzilla starts with 1.13
and jumped to 2.13.  However, users could have installed version 2.10
prior to the Debian package.

For the current stable distribution (woody) this problem has been
fixed in version 2.14.2-0woody3.

The old stable distribution (potato) does not contain a Bugzilla
package.

For the unstable distribution (sid) this problem will be fixed soon.

We recommend that you upgrade your bugzilla packages.

wget url
        will fetch the file for you
dpkg -i file.deb
        will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
        will update the internal database
apt-get upgrade
        will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 3.0 alias woody
- --------------------------------

  Source archives:


http://security.debian.org/pool/updates/main/b/bugzilla/bugzilla_2.14.2-0woody3.dsc
      Size/MD5 checksum:      621 5cffc6c1cb27caabaeab50f09d1eaba4

http://security.debian.org/pool/updates/main/b/bugzilla/bugzilla_2.14.2-0woody3.diff.gz
      Size/MD5 checksum:    37296 cdb8158a7d72a439c8dd04e207721a10

http://security.debian.org/pool/updates/main/b/bugzilla/bugzilla_2.14.2.orig.tar.gz
      Size/MD5 checksum:   933766 0c60df541e63e33d92ac9ba0fbb05be3

  Architecture independent components:


http://security.debian.org/pool/updates/main/b/bugzilla/bugzilla-doc_2.14.2-0woody3_all.deb
      Size/MD5 checksum:   489566 6575c255a98a0bcea4b55b24c064215e

http://security.debian.org/pool/updates/main/b/bugzilla/bugzilla_2.14.2-0woody3_all.deb
      Size/MD5 checksum:   274178 79345c65df4c9ede183089f0d5601fd7


  These files will probably be moved into the stable distribution on
  its next revision.

-
---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security
dists/stable/updates/main
Mailing list: debian-security-announce at lists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+EFQEW5ql+IAeqTIRAqyqAKCr6J0B7jWLVY3/H8kJ61eL7ntgcgCfTcV3
pl4aGLA23/PJZbH5Ie/H/ZY=
=SVah
-----END PGP SIGNATURE-----
----- End Forwarded Text -----

-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/
----- End Forwarded Text -----

###############################################################
###############################################################

----- Begin Forwarded Text -----

Date: Mon, 30 Dec 2002 20:43:26 +0100
From: Martin Schulze <joey at infodrom.org>
To: David Miller <justdave at syndicomm.com>
Cc: security at debian.org
Subject: Re: Fwd: [SECURITY] [DSA 218-1] New bugzilla packages fix cross
site scripting problem
Mime-Version: 1.0
User-Agent: Mutt/1.4i

David Miller wrote:
> Is there a reason this was worded the way it was?  "Bugzilla does not
> properly sanitize any input submitted by users" without any additional
> clarification in the same sentence (or even in the same paragraph) is an
> outright lie, because input is validated hopefully everywhere.  The input
> validation bug specifically-referenced in this advisory was fixed in

The Debian advisory reports about the problem and explains it.  In the
next paragraph it is written that this only affects users with quips
turned on and upgraded from one particular old version.  I don't see
that this is wrong, but if it is, please tell me where exactly it is
wrong.

You've quoted "Bugzilla does not properly sanitize any input submitted
by users" without the explanation that followed.  Well, if you cut off
one sentence, it may be used for anything and you can't blame us for
that.

Fortunately (or not, as you may claim), this paragraph is copied from
BugTraq:

   Reportedly, Bugzilla does not properly sanitize any input submitted
   by users. As a result, it is possible for a remote attacker to
   create a malicious link containing script code which will be
   executed in the browser of a legitimate user, in the context of the
   website running Bugzilla.

> version 2.12 of Bugzilla (current stable version is 2.16.1), and the vast
> majority of the input validation bugs were resolved prior to the previous

According to BugTraq, this problem was fixed in 2.14.4 and 2.16.1 and
not in 2.12, but BugTraq may be wrong, of course.  However, this was
my source of information.

> Debian package that you released.  Although you do clarify it in the
> following paragraph, people who aren't using Bugzilla and just reading it
> as an FYI would likely read the first paragraph and go on to the next
> email, and this paints a falsely negative image of Bugzilla as a whole by
> claiming we're not doing any input validation when we are.

I'm sorry, but I can't save ourselves from people who can't read or
don't want to read.

> Don't get me wrong, even one little HTML encoding issue like this is a
> serious issue (which is why we sent out a security advisory of our own
> about it when it was discovered), so I'm not trying to make light of the

Unfortunately I can't disagree.

> issue.  I'm only concerned with your wording in the Debian advisory.

I'd be happy to receive an improvement and update the text on the web.

Regards,

	Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry
----- End Forwarded Text -----

###############################################################
###############################################################

----- Begin Forwarded Text -----

Date: Mon, 30 Dec 2002 15:23:55 -0500
To: Martin Schulze <joey at infodrom.org>
From: David Miller <justdave at syndicomm.com>
Subject: Re: Fwd: [SECURITY] [DSA 218-1] New bugzilla packages fix cross
site scripting problem
Cc: security at debian.org
Bcc:
X-Attachments:

On 12/30/02 8:43 PM +0100, Martin Schulze wrote:

> You've quoted "Bugzilla does not properly sanitize any input submitted
> by users" without the explanation that followed.  Well, if you cut off
> one sentence, it may be used for anything and you can't blame us for
> that.

It doesn't refute that claim anywhere in that paragraph, either.

> Fortunately (or not, as you may claim), this paragraph is copied from
> BugTraq:
>
>    Reportedly, Bugzilla does not properly sanitize any input submitted
>    by users. As a result, it is possible for a remote attacker to
>    create a malicious link containing script code which will be
>    executed in the browser of a legitimate user, in the context of the
>    website running Bugzilla.

The above paragraph does not appear anywhere in my local archives of
Bugtraq, so I must have missed that one.  We certainly never said anything
like that in our security advisory
(http://online.securityfocus.com/archive/1/301316).  I did locate the page
in question on the SecurityFocus website, and will mail a correction to
them as well.  That page did, however, have the two paragraphs in the
opposite order, which as silly as it sounds, changes the context a bit. :)

>> version 2.12 of Bugzilla (current stable version is 2.16.1), and the vast
>> majority of the input validation bugs were resolved prior to the previous
>
> According to BugTraq, this problem was fixed in 2.14.4 and 2.16.1 and
> not in 2.12, but BugTraq may be wrong, of course.  However, this was
> my source of information.

The input validation error was fixed in version 2.12.  The already existing
data in the database placed there before the input validation was put in
place was not corrected at that time, nor was the output when presenting
that data back to the user escaped properly.  The escaping of the data
output is what was corrected in 2.17.1 (2.14.4 and 2.16.1 are both still
vulnerable if not patched).  Bugtraq has this correct on their site.

> I'm sorry, but I can't save ourselves from people who can't read or
> don't want to read.

Yeah, don't I know it :(

>> issue.  I'm only concerned with your wording in the Debian advisory.
>
> I'd be happy to receive an improvement and update the text on the web.

Let's see, removing the word "any" from that sentence would probably be
plenty. :)  That or add "for quips" on the end of the sentence.  The latter
would probably be more accurate in this case.  And since the input
sanitizing was fixed in an older version, and not in this most recent one,
changing the "does" to "did" would probably help, too.

"Bugzilla did not properly sanitize any input submitted by users for use in
quips."
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/
----- End Forwarded Text -----

###############################################################
###############################################################

----- Begin Forwarded Text -----

Date: Mon, 30 Dec 2002 21:51:27 +0100
From: Martin Schulze <joey at infodrom.org>
To: David Miller <justdave at syndicomm.com>
Subject: Re: Fwd: [SECURITY] [DSA 218-1] New bugzilla packages fix cross
site scripting problem
Mime-Version: 1.0
User-Agent: Mutt/1.4i

David Miller wrote:
> "Bugzilla did not properly sanitize any input submitted by users for use in
> quips."

Ok, except for the tense.

Regards,

	Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry
----- End Forwarded Text -----

###############################################################
###############################################################

I took this last one to mean he was doing it.  I didn't look.
SecurityFocus fixed theirs within an hour when I pointed it out to them.

Debian's still has the original (incorrect) wording.
http://www.debian.org/security/2002/dsa-218
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Thu Jan  9 13:02:50 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 09 Jan 2003 13:02:50 +0000
Subject: P4DTI: Leading zeros in jobnames
In-Reply-To: <B10181E022CCD411B19200037489093209F9B9@DFU>
References: <B10181E022CCD411B19200037489093209F9B9@DFU>
Message-ID: <3E1D72FA.2000202@mozilla.org>

> i am using Bugzill with the P4DTI and want to know, if it is possible, to
> get some leading zeros in the jobnames when using the option
> use_perforce_jobname=0.

Ask the P4DTI developers :-)

Gerv



From usmlekaplan at yahoo.com  Thu Jan  9 15:58:33 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Thu, 9 Jan 2003 07:58:33 -0800 (PST)
Subject: bugzilla e-mail interface problem-Please help
Message-ID: <20030109155833.89012.qmail@web20201.mail.yahoo.com>

Hi ,

We have bugzilla 2.16.1 installed and enabled the
e-mail interface. When I send an e-mail to bugzilla
server(bugzilla at ausdhcp92-128.crystal.cirrus.com) and
cc and bcc to a list of people, only the first person
in the cc list and first person in bcc list is
receiving the e-mail and all the others on the list
don't get any e-mail notification. Is there a place
where I need to make modifications so that everyone on
the cc as well as bcc list receive e-mail
notification.Your help is highly appreciated.

Thanks a lot,

Srikant Nandamuri


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


From luismi at b2bi.es  Fri Jan 10 10:42:52 2003
From: luismi at b2bi.es (Luis Miguel Cruz Miranda)
Date: Fri, 10 Jan 2003 11:42:52 +0100
Subject: spanish template for 2.16.2
Message-ID: <5.1.1.6.2.20030110113952.00b49fa8@172.26.0.8>

Hi all,

I don't know if it is the best mailing list to ask my dude but I will do it 
anyway.
I would like to know where I can download templates for bugzilla, exactly, 
I am looking for the spanish template, I would like to use bugzilla in spanish.


Luis Miguel Cruz Miranda.
CCNA - Systems Administrator

---------------------------------------------------------------
B2B INTEGRAL, S.A.
Pol. Ind. de Asipo
C/A - Parcela 86-C
33.428 - CAYES - LLANERA
ASTURIAS (ESPA?A/SPAIN)
---------------------------------------------------------------
Tel: +34 985 980 804 ---- Fax: +34 985 980 794
---------------------------------------------------------------
WEB: http://www.b2bi.es/




From justdave at syndicomm.com  Fri Jan 10 17:30:01 2003
From: justdave at syndicomm.com (David Miller)
Date: Fri, 10 Jan 2003 12:30:01 -0500
Subject: spanish template for 2.16.2
In-Reply-To: <5.1.1.6.2.20030110113952.00b49fa8@172.26.0.8>
References: <5.1.1.6.2.20030110113952.00b49fa8@172.26.0.8>
Message-ID: <a05200f01ba44aed6b0b3@[192.168.1.203]>

On 1/10/03 11:42 AM +0100, Luis Miguel Cruz Miranda wrote:

> I don't know if it is the best mailing list to ask my dude but I will do it
> anyway.
> I would like to know where I can download templates for bugzilla, exactly,
> I am looking for the spanish template, I would like to use bugzilla in
>spanish.

In general you can look on http://www.bugzilla.org/download.html for
templates, they're listed about halfway down the page.  However, the
Spanish ones aren't listed there yet because I haven't gotten any
confirmation that they're complete or that anyone's actually been
maintaining them beyond the initial posting.

See http://bugzilla.mozilla.org/show_bug.cgi?id=125584

-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From burnus at gmx.de  Fri Jan 10 17:29:28 2003
From: burnus at gmx.de (Tobias Burnus)
Date: Fri, 10 Jan 2003 18:29:28 +0100
Subject: spanish template for 2.16.2
References: <5.1.1.6.2.20030110113952.00b49fa8@172.26.0.8>
Message-ID: <3E1F02F8.8EFF1274@gmx.de>

Hi,

Luis Miguel Cruz Miranda wrote:
> I don't know if it is the best mailing list to ask my dude but I will do it
> anyway.
> I would like to know where I can download templates for bugzilla, exactly,
> I am looking for the spanish template, I would like to use bugzilla in spanish.

See:
  http://bugzilla.mozilla.org/show_bug.cgi?id=125584
which points to:
  http://www.hispalinux.es/~data/bugzilla/
but I think this is against 2.16 not 2.16.2, but there are probably only
little changes.

Tobias
-- 
This above all: To thine own self be true / And it must follow as
the night the day / Thou canst not then be false to any man.


From bugreport at peshkin.net  Fri Jan 10 18:30:32 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 10 Jan 2003 10:30:32 -0800
Subject: mysql version dependencies?
Message-ID: <3E1F1148.3040905@peshkin.net>


Developers:

   We have a report that implies that there is a bug in mysql that 
manifests itself with 2.17, but it is not yet confirmed.  The symptom 
would be that users who are neither the reporter, assignee, or CC'd 
cannot see bugs that are not restricted to any groups at all.  

    I had no problem with mysqld (the server) 3.23.41.   Richard had 
problems with 3.23.39-nt that went away when he updated to 3.23.54-nt.

    Does anyone out there run 3.23.39?   Also, please respond to this by 
identifying the mysqld versions you are using with 2.17 and if 
everything is working.  Thanks.

-Joel

excerpt from Richard's posting.....

    Many thanks for your help with this. I was running mysql 3.23.39-nt.
    I have
    now upgraded to 3.23.54-nt and the original query works. So I think
    it was
    an obscure mysql error as you suggest.








From gerv at mozilla.org  Fri Jan 10 19:01:12 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 10 Jan 2003 19:01:12 +0000
Subject: mysql version dependencies?
In-Reply-To: <3E1F1148.3040905@peshkin.net>
References: <3E1F1148.3040905@peshkin.net>
Message-ID: <3E1F1878.9050703@mozilla.org>

>    Does anyone out there run 3.23.39?   Also, please respond to this by 
> identifying the mysqld versions you are using with 2.17 and if 
> everything is working.  Thanks.


3.23.52; but I've done very little testing recently.

Gerv



From justdave at syndicomm.com  Fri Jan 10 19:32:02 2003
From: justdave at syndicomm.com (David Miller)
Date: Fri, 10 Jan 2003 14:32:02 -0500
Subject: mysql version dependencies?
In-Reply-To: <3E1F1878.9050703@mozilla.org>
References: <3E1F1148.3040905@peshkin.net> <3E1F1878.9050703@mozilla.org>
Message-ID: <a05200f09ba44d0247f02@[192.168.1.203]>

On 1/10/03 7:01 PM +0000, Gervase Markham wrote:

>>    Does anyone out there run 3.23.39?   Also, please respond to this by
>> identifying the mysqld versions you are using with 2.17 and if
>> everything is working.  Thanks.
>
>
> 3.23.52; but I've done very little testing recently.

I have 3.23.49 with no problems.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From justdave at syndicomm.com  Fri Jan 10 22:20:53 2003
From: justdave at syndicomm.com (David Miller)
Date: Fri, 10 Jan 2003 17:20:53 -0500
Subject: Bugzilla in Java?
Message-ID: <a05200f0fba44f7abc282@[192.168.1.203]>

Here we go again....   maybe?

I encourage everyone to take a look at bug 188570
http://bugzilla.mozilla.org/show_bug.cgi?id=188570

and offer opinions :)

We have an offer to port Bugzilla to Java again.  My immediate reaction was
WONTFIX and pointed him at Scarab as work already done, but he points out
that Scarab turned out to be a replacement and not a compatible port, and
he wants a compatible port.

He's offering to do the work of course, but what kind of support should he
get?  I'm a bit iffy on it personally.  But if someone keeps it up to date
I don't see a problem with giving an admin a choice of interfaces.  The
problem comes with that keeping it up-to-date part.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From bbaetz at student.usyd.edu.au  Fri Jan 10 23:14:50 2003
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Sat, 11 Jan 2003 10:14:50 +1100
Subject: Bugzilla in Java?
In-Reply-To: <a05200f0fba44f7abc282@[192.168.1.203]>
References: <a05200f0fba44f7abc282@[192.168.1.203]>
Message-ID: <20030110231450.GA1185@mango.home>

Why? What benefits does this bring? I find it hard to believe that there
exists a platform where java works but perl doesn't, so it cna't be for
portability.

We also use perl tricks which aren't available in java, not to mention
all teh supporting modules like TT.

If we're only talking about the front end (which is what the bug seems
to be hinting at) then making bugzilla support xmlrpc would probably be
the way to go.

Bradley


From sergeyli at pisem.net  Fri Jan 10 23:30:24 2003
From: sergeyli at pisem.net (Sergey)
Date: Fri, 10 Jan 2003 18:30:24 -0500
Subject: Bugzilla in Java?
In-Reply-To: <20030110231450.GA1185@mango.home>
References: <a05200f0fba44f7abc282@[192.168.1.203]> <20030110231450.GA1185@mango.home>
Message-ID: <3E1F5790.4010703@pisem.net>



Bradley Baetz wrote:
  to be hinting at) then making bugzilla support xmlrpc would probably be

We pray every day for this to happen, but doing Bugzilla-workalike in Java may force development to take a more structured 
approach than the way Bugzilla handles things now. However, my two cents' worth opinion (I did write some code to interconnect 
our tools with Bugzilla through its database) is that of course supporting XMLRPC is a better application of effort than simply 
remaking the whole thing in Java hoping to get rid of some deficiencies in the process (which may never come true). And mod_perl 
support. And... OK, enough :-).

Sergey.




From justdave at syndicomm.com  Fri Jan 10 23:43:14 2003
From: justdave at syndicomm.com (David Miller)
Date: Fri, 10 Jan 2003 18:43:14 -0500
Subject: Bugzilla in Java?
In-Reply-To: <3E1F5790.4010703@pisem.net>
References: <a05200f0fba44f7abc282@[192.168.1.203]>
 <20030110231450.GA1185@mango.home> <3E1F5790.4010703@pisem.net>
Message-ID: <a05200f13ba450a7b2b57@[192.168.1.203]>

On 1/10/03 6:30 PM -0500, Sergey wrote:

> doing Bugzilla-workalike in Java may force development to take a more
>structured approach than the way Bugzilla handles things now.

If anyone's taken a peek at Bugzilla in CVS recently (even in the 2.17.3
tarball) you'll notice a Bugzilla directory that contains a whole mess of
*.pm files (perl modules).  Bugzilla is, piece by piece, getting the entire
back end moved into OOP modules.  The *.cgi scripts are little by little
becoming nothing but a front-end UI to the perl modules.  It won't be too
much longer and we'll have enough of the back end put into those perl
modules that you'll be able to write standalone perl scripts on the command
line that can use Bugzilla without having to know what the database looks
like or even what database it's using.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From preed at sigkill.com  Sat Jan 11 00:00:55 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Fri, 10 Jan 2003 16:00:55 -0800 (PST)
Subject: Bugzilla in Java?
In-Reply-To: <a05200f0fba44f7abc282@[192.168.1.203]>
Message-ID: <Pine.LNX.4.43.0301101600090.21275-100000@underworld.sigkill.com>

On Fri, 10 Jan 2003, David Miller wrote:

> Here we go again....   maybe?
>
> I encourage everyone to take a look at bug 188570
> http://bugzilla.mozilla.org/show_bug.cgi?id=188570

My $0.02:

http://bugzilla.mozilla.org/show_bug.cgi?id=188570#c6

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  To hold on to sanity too tight is insane.  -- Nick Falzone, Pushing Tin



From jimw at bugopolis.com  Sat Jan 11 00:21:18 2003
From: jimw at bugopolis.com (Jim Walters)
Date: Fri, 10 Jan 2003 16:21:18 -0800
Subject: Bugzilla in Java?
In-Reply-To: <a05200f0fba44f7abc282@[192.168.1.203]>
References: <a05200f0fba44f7abc282@[192.168.1.203]>
Message-ID: <3E1F637E.9010205@bugopolis.com>

So the objective has to be to have the Perl/CGI code concurrently operating
on the same live database as the Java code. A Java work-a-like without this
capability just becomes another defect tracking database

It seems there are at least two types of support you can give this project.
One would be technical assistance in terms of the internals of the Bugzilla
code base and the other would be actual design changes to facilitate the Java
engine. On the second point the question is: How far would you go? The first
type of support seems to happen regardless of what people use the information
for.

The question of alternate front ends (for richer UIs) has been brought up
before in the webtools group. XMLRPC has been brought up a couple of times.
It seems like a reasonable approach. But I'm really curious about Jason sees
the advantage of using Bugzilla is for their project given they are going to
have to do all the app logic and UI in Java.

My $.01.

Jim

David Miller wrote:

>Here we go again....   maybe?
>
>I encourage everyone to take a look at bug 188570
>http://bugzilla.mozilla.org/show_bug.cgi?id=188570
>
>and offer opinions :)
>
>We have an offer to port Bugzilla to Java again.  My immediate reaction was
>WONTFIX and pointed him at Scarab as work already done, but he points out
>that Scarab turned out to be a replacement and not a compatible port, and
>he wants a compatible port.
>
>He's offering to do the work of course, but what kind of support should he
>get?  I'm a bit iffy on it personally.  But if someone keeps it up to date
>I don't see a problem with giving an admin a choice of interfaces.  The
>problem comes with that keeping it up-to-date part.
>  
>



From bbaetz at student.usyd.edu.au  Sat Jan 11 04:33:25 2003
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Sat, 11 Jan 2003 15:33:25 +1100
Subject: mysql version dependencies?
In-Reply-To: <3E1F1148.3040905@peshkin.net>
References: <3E1F1148.3040905@peshkin.net>
Message-ID: <20030111043324.GA3021@mango.home>

On Fri, Jan 10, 2003 at 10:30:32AM -0800, Joel Peshkin wrote:
> 
> Developers:
> 
>    I had no problem with mysqld (the server) 3.23.41.   Richard had 
> problems with 3.23.39-nt that went away when he updated to 3.23.54-nt.

There was a mysql bug with joins which affected mysql from at least
3.22, which was fixed in 3.23.44. I did look for this in the new
permission code when that was rewritten, and I didn't think we triggered
it anymore. That doesn't explain why it works in .41, though.

If you could track this down, that would be helpful. Try running the
query in CanSeeBug (in globals.pl) with the two different db versions,
and compare teh results. Then start removing bits.

The 3.23.40 changelogs for mysql do say: "Fixed a bug when using
COUNT(DISTINCT) with LEFT JOIN and there weren't any matching rows."

We do use that, but on the LHS of the join. Does 3.23.40 work? IF so, we
should update the required mysql version.

Bradley


From bbaetz at student.usyd.edu.au  Sat Jan 11 05:04:40 2003
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Sat, 11 Jan 2003 16:04:40 +1100
Subject: mysql version dependencies?
In-Reply-To: <20030111043324.GA3021@mango.home>
References: <3E1F1148.3040905@peshkin.net> <20030111043324.GA3021@mango.home>
Message-ID: <20030111050440.GA3225@mango.home>

On Sat, Jan 11, 2003 at 03:33:25PM +1100, Bradley Baetz wrote:
> 
> The 3.23.40 changelogs for mysql do say: "Fixed a bug when using
> COUNT(DISTINCT) with LEFT JOIN and there weren't any matching rows."
> 
> We do use that, but on the LHS of the join. Does 3.23.40 work? IF so, we
> should update the required mysql version.

... and now having actually read the post on npm.webtools, I think thats
what its likely to be.

The bug report/fix (http://lists.mysql.com/cgi-ez/ezmlm-cgi?1:msn:76814)
looks very similar to this, but it doesn't have a workarround.

So we should probably update the mysql requirements then. Debian stable
has 3.23.49, whilst RH7.1 has .36, 7.2 has .41, and 7.3 has .49.

IOW, keeping .41 as the minimum will let us keep RH7.2 out-of-the-box
requirements. Since we no longer trigger the bug in .44, we should
probably have 3.23.41 as the minimum supported version.

Thoughts?

Bradley


From caseyg at chsamerica.com  Tue Jan 14 21:10:29 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Tue, 14 Jan 2003 16:10:29 -0500
Subject: Login
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF5569E9D@BUCKWHEAT>

I have this problem. I just got bugzilla working on my linux 7.1 box. but
when you go to login if you enter a valid username, and leave the password
field empty it will log you in as that user. but if you type any text, it
will not work unless that test is the password that IS assigned to the user.

Any ideas? I could not find anything on this.

Thank you,
  Casey Gregoire


From gerv at mozilla.org  Tue Jan 14 21:55:33 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 14 Jan 2003 21:55:33 +0000
Subject: Login
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF5569E9D@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF5569E9D@BUCKWHEAT>
Message-ID: <3E248755.8090506@mozilla.org>

Casey Gregoire wrote:
> I have this problem. I just got bugzilla working on my linux 7.1 box. but
> when you go to login if you enter a valid username, and leave the password
> field empty it will log you in as that user. but if you type any text, it
> will not work unless that test is the password that IS assigned to the user.

(Fortunately) this doesn't happen for me - because if it did, we'd have 
a bit of a crisis. I have no idea why it's happening for you, but would 
be eager to find out.

Exactly which version of Bugzilla are you using?
Does it happen for every account on the system?
Are you using the emailsuffix param?

This conversation should really take place in a bug. Please file one and 
CC me, and I will make it confidential just in case this is a security 
problem.

Gerv



From bbaetz at acm.org  Fri Jan 17 14:12:41 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Sat, 18 Jan 2003 01:12:41 +1100
Subject: Using DBI
Message-ID: <20030117141241.GA1803@mango.home>

A few days ago, I checked in a reorg for the database code (bug 163290).
Combined with various other patches which went in over the past few
motnhs, this means that we can now use the DBI. All new code should use
the DBI methods; SendSQL and friends are now deprecated. (You need to
update DBI/DBD::mysql for this to work. checksetup should pick that up,
though)

|perldoc DBI| has more information than you ever want to know about the
DBI. There are also numerous docs on the web.

A quick summary:

- Don't use SendSQL (or {Push,Pop}GlobalSQLState/MoreSQLData/etc. They
won't work w/o SendSQL anyway)

- Use the DBI helper functions. They're easier to write, clearer to
understand, and some of them are written in XS (ie C) which makes them
faster. (Postgres doesn't use the C version, and you must have compiled
your DBD:: driver _after_ installing the updated DBI for the C version
to be used)

For example, consider get_product_id:

  sub get_product_id {
    my ($prod) = @_;
    PushGlobalSQLState();
    SendSQL("SELECT id FROM products WHERE name = " . SqlQuote($prod));
    my ($prod_id) = FetchSQLData();
    PopGlobalSQLState();
    return $prod_id;
  }

That routine can now become:

  sub get_product_id {
    my $prod = shift;
    my $dbh = $Bugzilla->instance->dbh; # Explained below
    return $dbh->selectrow_array("SELECT id FROM products WHERE name = "
                                 . SqlQuote($prod));
  }

(Note that this is not optimal; see below)

selectrow_array (and fetchrow_array) return a scalar if called in scalar
context. If there is more than one value in the SELECT, then its
undefined which is returned; so don't do that.

When selecting more than one row of data, there are also selectall_
variants which can put all the data into an arrayref/hashref for you. Be
careful about storing the arrayref somewhere. For really tight loops
where SQL is the main overhead, look into ->bind_columns. That stuff is
a readability vs speed tradoff, and is unlikly to be useful in teh
general case since we don't really hammer the DB in that way. (It should
be sufficient to use the ref stuff)

See DBI docs for details.

The $Bugzilla->instance->dbh stuff is needed in order to actually get
the database handle to use. See Bugzilla.pm for docs.

- Use placeholders

 sub get_product_id {
    my $prod = shift;
    my $dbh = $Bugzilla->instance->dbh;
    return $dbh->selectrow_array("SELECT id FROM products WHERE name=?",
                                 undef,
                                 $prod);
  }

This is not only useful for prepared statements (see below), but also
for quoting. Notice how there is no SQLQuote - DBI 'knows' that since
$prod is a string, it needs to be escaped. This also helps sybase, I
believe, since if we get a number DBI knows not to quote it.

There is one important difference, however. The DBI checks all incoming
values for tainted-ness. Before, we were mainly worried about tainted
data from an sql POV - 'can I put this string here?'. Now we have to
think about it from a logical point of view - 'is this query still OK no
matter what the user has given me?'. The _caller_ should trick_taint,
since it is in the best position to know what it wants. (I'm open for
discuission on that one though. It may end up being handled on a case by
case basis)

(Note that this does not apply to attachment uploads, mainly for
cross-db reasons. Gory details on the DBI list, in the DBD::Pg
discussions)

- Use prepared statements.

Creating a statement handle is relativly expensive. If we're going to
run an sql command lots of times, it makes sense to produce it once and
then just reuse the statement handle. If you have a nested loop, you can
use ->prepare. From within a sub, use prepare_cached:

  sub get_product_id {
    my $prod = shift;
    my $dbh = $Bugzilla->instance->dbh; # Explained below
    my $sth = $dbh->prepare_cached("SELECT id FROM products WHERE name=?");
    return $dbh->selectrow_array($sth, undef, $prod);
  }

Don't use prepare_cached unless the statement is going to be reused
multiple times from somewhere where you can't use prepare - there is DBI
overhead to match the SQL to the prepared handle. However, DBI handles
the 'firsttime' creation of the sth, including recreation/revalidation
if the database has disconnected in the meantime (eg via a subsequent
mod_perl connection)

Notice how we need placeholders for this to work. If we used
concatenation, then we'd have one statement handle for every value
passed in. It would still work, but would be ess efficient, due to the
_cached overhead, and the lack of any benefit.

However, when deciding whether to use _cached or not, remember that even
if most scripts only call get_product_id once, bugzilla will be running
multiple pages at some point, via mod_perl, so it will be a benefit.

As an example, I've attached a benchmark script. The results (+/- 5%)
are:

                  Rate SendSQL concat prepare_cached prepare_nobind prepare
SendSQL         5305/s      --    -4%           -45%           -46% -63%
concat          5540/s      4%     --           -43%           -43% -61%
prepare_cached  9709/s     83%    75%             --            -0% -32%
prepare_nobind  9756/s     84%    76%             0%             -- -31%
prepare        14184/s    167%   156%            46%            45% --

In other words, using prepare makes the SQL 2.67 times as fast as
SendSQL.

Some notes:

a) This obviously doesn't mean that bugzilla will be 2.67 times as fast.
Module load time is the vast majority of stuff.
b) prepare_nobind is faster than prepare_bind, but as mentioned above
its no help unelss the value is constand, in which case you shouldn't be
using a bind val anyway.
c) Where the SQL is complicated, the differences will obviously get
less.
d) The SendSQL sub has the ->finish because selectall_* does. IOW it was
used to make a fair comparison. Without it, SendSQL is marginally faster
than concat.

Comments? I'm sure I've forgotton stuff....

Bradley
-------------- next part --------------
#!/usr/bin/perl -w

use strict;

use Benchmark qw(cmpthese);
use DBI;

my $dbh = DBI->connect("DBI:mysql:host=localhost;database=bugs", "bugs", 
"bugged");

my $id = 1;
use constant QUERY => "SELECT bug_id FROM bugs WHERE bug_id = ";
my $sth = $dbh->prepare(QUERY . "?");
$dbh->prepare_cached(QUERY . "?");

cmpthese (20000, {
  'concat' => sub { my $res = $dbh->selectrow_array(QUERY . $id); },
  'prepare' => sub { my $res = $dbh->selectrow_array($sth, undef, $id);},
  'prepare_cached' => sub { my $sth = $dbh->prepare_cached(QUERY . "?");
                            my $res = $dbh->selectrow_array($sth, undef, $id);
                          },
  'prepare_nobind' => sub { my $sth = $dbh->prepare_cached(QUERY . "1");
                            my $res = $dbh->selectrow_array($sth);
                          },
  'SendSQL' => sub { my $sth = $dbh->prepare(QUERY . $id);
                     $sth->execute || die $dbh->errstr;
                     my @arr = $sth->fetchrow_array;
                     my $res = $arr[0];
                     $sth->finish;
                   },
});

From jon at vmware.com  Fri Jan 17 19:01:19 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 17 Jan 2003 11:01:19 -0800
Subject: Using DBI
In-Reply-To: <20030117141241.GA1803@mango.home>
References: <20030117141241.GA1803@mango.home>
Message-ID: <1042830078.2398.4.camel@jonschatz-lx.vmware.com>

On Fri, 2003-01-17 at 06:12, Bradley Baetz wrote:
> A quick summary:
> 
> - Don't use SendSQL (or {Push,Pop}GlobalSQLState/MoreSQLData/etc. They
> won't work w/o SendSQL anyway)
> 
> - Use the DBI helper functions. They're easier to write, clearer to
> understand, and some of them are written in XS (ie C) which makes them
> faster. (Postgres doesn't use the C version, and you must have compiled
> your DBD:: driver _after_ installing the updated DBI for the C version
> to be used)

does there exist the possibility of keeping the old *SQL functions
working by changing them to use DBI? i didn't know this was coming, and
you've magically added an extra week's worth of work to my current
project. 

i'd write this if there is any interest. i personally find DBI to be
extremely ugly and generally write wrapper classes around it. in fact, i
don't think i've ever (professionally) used DBI without some kind of
abstraction level.

while i agree that the bugzilla sql subs were ugly, i'm seriously
dreading a rewrite of the code i've got. is anyone else in this same
situation?

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From justdave at syndicomm.com  Fri Jan 17 19:19:40 2003
From: justdave at syndicomm.com (David Miller)
Date: Fri, 17 Jan 2003 14:19:40 -0500
Subject: Using DBI
In-Reply-To: <1042830078.2398.4.camel@jonschatz-lx.vmware.com>
References: <20030117141241.GA1803@mango.home>
 <1042830078.2398.4.camel@jonschatz-lx.vmware.com>
Message-ID: <a05200f11ba4e074c3f87@[192.168.1.203]>

On 1/17/03 11:01 AM -0800, Jonathan Schatz wrote:

> On Fri, 2003-01-17 at 06:12, Bradley Baetz wrote:
>> A quick summary:
>>
>> - Don't use SendSQL (or {Push,Pop}GlobalSQLState/MoreSQLData/etc. They
>> won't work w/o SendSQL anyway)
>>
>> - Use the DBI helper functions. They're easier to write, clearer to
>> understand, and some of them are written in XS (ie C) which makes them
>> faster. (Postgres doesn't use the C version, and you must have compiled
>> your DBD:: driver _after_ installing the updated DBI for the C version
>> to be used)
>
> does there exist the possibility of keeping the old *SQL functions
> working by changing them to use DBI? i didn't know this was coming, and
> you've magically added an extra week's worth of work to my current
> project.

The old *SQL functions are still there.  You have to "use Bugzilla::DB qw(
:deprecated )" to get them, but they're there.  If you already have
something written using them, by all means don't feel like you have to
change it now.  The conversion is an ongoing thing, and someone else will
probably convert it down the road if it's something you're contributing.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Fri Jan 17 20:11:42 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 17 Jan 2003 20:11:42 +0000
Subject: Using DBI
In-Reply-To: <a05200f11ba4e074c3f87@[192.168.1.203]>
References: <20030117141241.GA1803@mango.home> <1042830078.2398.4.camel@jonschatz-lx.vmware.com> <a05200f11ba4e074c3f87@[192.168.1.203]>
Message-ID: <3E28637E.80701@mozilla.org>

> The old *SQL functions are still there.  You have to "use Bugzilla::DB qw(
> :deprecated )" to get them, but they're there.  

This is kind of depressing - mostly because, as Jonathan says, the new 
functions are really ugly. Not necessarily to use, but certainly to look 
at. Currently, at lot of our code is really nice, because it doesn't 
have constructs like
     my $dbh = $Bugzilla->instance->dbh;
     return $dbh->selectrow_array("SELECT id FROM products WHERE name=?",
                                  undef,
                                  $prod);
all over it.

Is there no way we can keep the old interface, or something resembling 
it? For example:

use Bugzilla::DBI; # (or some other package)
...
my @products = SelectRow("SELECT id FROM products WHERE name=?", $prod);

[As a sidenote, I note from today's Slashdot interview that AMI (the 
BIOS people) use Bugzilla internally.]

Gerv



From bbaetz at acm.org  Fri Jan 17 22:04:11 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Sat, 18 Jan 2003 09:04:11 +1100
Subject: Using DBI
In-Reply-To: <1042830078.2398.4.camel@jonschatz-lx.vmware.com>
References: <20030117141241.GA1803@mango.home> <1042830078.2398.4.camel@jonschatz-lx.vmware.com>
Message-ID: <20030117220411.GA1096@mango.home>

On Fri, Jan 17, 2003 at 11:01:19AM -0800, Jonathan Schatz wrote:

> does there exist the possibility of keeping the old *SQL functions
> working by changing them to use DBI? i didn't know this was coming, and
> you've magically added an extra week's worth of work to my current
> project. 

Yes; thats why Bugzilla still works :) The compat code is basically
identical to teh old code (Except I changed the fetchahead buffer to use
arrafrefs instead of arrays)

> i'd write this if there is any interest. i personally find DBI to be
> extremely ugly and generally write wrapper classes around it. in fact, i
> don't think i've ever (professionally) used DBI without some kind of
> abstraction level.

Well, we do have an abstraction layer of sorts - stuff like Bug.pm, for
example.

> 
> while i agree that the bugzilla sql subs were ugly, i'm seriously
> dreading a rewrite of the code i've got. is anyone else in this same
> situation?

I'm not suggesting rewriting existing code, although if someone wants to
do that that would be good. Over time, however, stuff will change.

[I do want to get rid of Push/PopGlobalSQLState though, but that only
affects a small handfull of functions]

Bradley


From bbaetz at acm.org  Fri Jan 17 22:13:23 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Sat, 18 Jan 2003 09:13:23 +1100
Subject: Using DBI
In-Reply-To: <3E28637E.80701@mozilla.org>
References: <20030117141241.GA1803@mango.home> <1042830078.2398.4.camel@jonschatz-lx.vmware.com> <a05200f11ba4e074c3f87@[192.168.1.203]> <3E28637E.80701@mozilla.org>
Message-ID: <20030117221323.GB1096@mango.home>

On Fri, Jan 17, 2003 at 08:11:42PM +0000, Gervase Markham wrote:
> >The old *SQL functions are still there.  You have to "use Bugzilla::DB qw(
> >:deprecated )" to get them, but they're there.  
> 
> This is kind of depressing - mostly because, as Jonathan says, the new 
> functions are really ugly. Not necessarily to use, but certainly to look 
> at. Currently, at lot of our code is really nice, because it doesn't 
> have constructs like
>     my $dbh = $Bugzilla->instance->dbh;
>     return $dbh->selectrow_array("SELECT id FROM products WHERE name=?",
>                                  undef,
>                                  $prod);
> all over it.

No, it has

  PushGlobalSQLState();
  ' Remember the quote!
  SendSQL("SELECT id FROM products WHERE name=" . SqlQuote($prod));
  my $foo = FetchOneColumn();
  PopGlobalSQLState();

and we get stuff like bug 189446 because noone has ever been checking
for errors.

> 
> Is there no way we can keep the old interface, or something resembling 
> it? For example:
> 
> use Bugzilla::DBI; # (or some other package)
> ...
> my @products = SelectRow("SELECT id FROM products WHERE name=?", $prod);
> 

Why? The 2nd argument can have stuff in it; it just didn't in this
particular example.

We could have wrappers, I guess, but there are so many DBI functions
that its not really appropriate.

One example I hinted at, but didn't mention, was that to select all
bug_ids matching a certain criteria, we can do:

my $ref = $dbh->selectcol_arrayref("SELECT bug_id FROM bugs WHERE ...");

To produce an id=> name hash, we can do (from DBI docs):

  my $ary_ref = $dbh?>selectcol_arrayref("select idname from table",
                                         { Columns=>[1,2] });
  my %hash = @$ary_ref; # build hash from key?valupairs so $hash{$id} => name

and so on. You only have to get the dbh once per sub. I will think about
removing the ->instance stuff, and probably do that since its not really
needed for our case.

> [As a sidenote, I note from today's Slashdot interview that AMI (the 
> BIOS people) use Bugzilla internally.]
> 

Cool.

> Gerv
> 

Bradley


From justdave at syndicomm.com  Fri Jan 17 22:18:59 2003
From: justdave at syndicomm.com (David Miller)
Date: Fri, 17 Jan 2003 17:18:59 -0500
Subject: Login
In-Reply-To: <3E248755.8090506@mozilla.org>
References: <C3EB95A31BDAD511827C00B0D0F95AF5569E9D@BUCKWHEAT>
 <3E248755.8090506@mozilla.org>
Message-ID: <a05200f16ba4e300ebf21@[192.168.1.203]>

On 1/14/03 9:55 PM +0000, Gervase Markham wrote:

> Casey Gregoire wrote:
>> I have this problem. I just got bugzilla working on my linux 7.1 box. but
>> when you go to login if you enter a valid username, and leave the password
>> field empty it will log you in as that user. but if you type any text, it
>> will not work unless that test is the password that IS assigned to the user.
>
> (Fortunately) this doesn't happen for me - because if it did, we'd have
> a bit of a crisis. I have no idea why it's happening for you, but would
> be eager to find out.
>
> Exactly which version of Bugzilla are you using?
> Does it happen for every account on the system?
> Are you using the emailsuffix param?
>
> This conversation should really take place in a bug. Please file one and
> CC me, and I will make it confidential just in case this is a security
> problem.

There's already a bug for this, filed by Casey on the 15th. :)
http://bugzilla.mozilla.org/show_bug.cgi?id=189189

Last I heard he was on RedHat 7.1 running ActiveState Perl...  which threw
most of us because we'd never seen ActiveState on Linux :)  Last action on
the bug I believe was he was trying to install an official RedHat
distribution of Perl to see if that fixed it.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Sat Jan 18 13:50:36 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 18 Jan 2003 13:50:36 +0000
Subject: Using DBI
In-Reply-To: <20030117141241.GA1803@mango.home>
References: <20030117141241.GA1803@mango.home>
Message-ID: <3E295BAC.9060907@mozilla.org>

Bradley Baetz wrote:
> (You need to
> update DBI/DBD::mysql for this to work. checksetup should pick that up,
> though)

DBI would not install in Perl 5.6.1 without Time::HiRes. Is that an 
additional dependency?

> - Use the DBI helper functions. They're easier to write, clearer to
> understand, and some of them are written in XS (ie C) which makes them
> faster. (Postgres doesn't use the C version, and you must have compiled
> your DBD:: driver _after_ installing the updated DBI for the C version
> to be used)

Currently, if you don't have the right versions of both these, you get:
Bugzilla requires some Perl modules which are either missing from your
system, or the version on your system is too old.
They can be installed by running (as root) the following:
    perl -MCPAN -e 'install "DBD::mysql"'
    Minimum version required: 2.1010
    perl -MCPAN -e 'install "DBI"'
    Minimum version required: 1.32

If DBI should be installed before DBD, should we reverse the order of 
these messages?

Gerv



From justdave at syndicomm.com  Sat Jan 18 17:27:37 2003
From: justdave at syndicomm.com (David Miller)
Date: Sat, 18 Jan 2003 12:27:37 -0500
Subject: Using DBI
In-Reply-To: <3E295BAC.9060907@mozilla.org>
References: <20030117141241.GA1803@mango.home>
 <3E295BAC.9060907@mozilla.org>
Message-ID: <a05200f1aba4f3ecd347e@[192.168.1.203]>

On 1/18/03 1:50 PM +0000, Gervase Markham wrote:

> Currently, if you don't have the right versions of both these, you get:
> Bugzilla requires some Perl modules which are either missing from your
> system, or the version on your system is too old.
> They can be installed by running (as root) the following:
>     perl -MCPAN -e 'install "DBD::mysql"'
>     Minimum version required: 2.1010
>     perl -MCPAN -e 'install "DBI"'
>     Minimum version required: 1.32
>
> If DBI should be installed before DBD, should we reverse the order of
> these messages?

Did someone change the order of the array?  I remember hassling dkl about
that when we changed to using a hash for the dependency list because it
listed the dependencies out of order.  If it's doing that now, someone's
broken it again since then, and it should by all means be fixed.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From bbaetz at acm.org  Sat Jan 18 22:52:33 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Sun, 19 Jan 2003 09:52:33 +1100
Subject: Using DBI
In-Reply-To: <3E295BAC.9060907@mozilla.org>
References: <20030117141241.GA1803@mango.home> <3E295BAC.9060907@mozilla.org>
Message-ID: <20030118225233.GB1097@mango.home>

On Sat, Jan 18, 2003 at 01:50:36PM +0000, Gervase Markham wrote:
> Bradley Baetz wrote:
> >(You need to
> >update DBI/DBD::mysql for this to work. checksetup should pick that up,
> >though)
> 
> DBI would not install in Perl 5.6.1 without Time::HiRes. Is that an 
> additional dependency?

No, its a testing bug which has been fixed in the devel version, IIRC.
you only need it to run the tests.

> 
> >- Use the DBI helper functions. They're easier to write, clearer to
> >understand, and some of them are written in XS (ie C) which makes them
> >faster. (Postgres doesn't use the C version, and you must have compiled
> >your DBD:: driver _after_ installing the updated DBI for the C version
> >to be used)
> 
> Currently, if you don't have the right versions of both these, you get:
> Bugzilla requires some Perl modules which are either missing from your
> system, or the version on your system is too old.
> They can be installed by running (as root) the following:
>    perl -MCPAN -e 'install "DBD::mysql"'
>    Minimum version required: 2.1010
>    perl -MCPAN -e 'install "DBI"'
>    Minimum version required: 1.32
> 
> If DBI should be installed before DBD, should we reverse the order of 
> these messages?

Hmm. Yeah, %missing could probably be made into an array to preserve
order.

Note that it will all still work; it just won't use the XS version for
new functions which were added to the stub code.

Bradley


From caseyg at chsamerica.com  Mon Jan 20 12:40:36 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 20 Jan 2003 07:40:36 -0500
Subject: Login
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF557E91A@BUCKWHEAT>

That is what i ended up doing. Using the Perl 5.6.1 from CPAN worked fine.
It messed up my installation of Apache to upgrade perl for some reason. I am
not sure if that was my fault or not. But it is working fine now. I am
wondering what function in ActiveState Perl would allow the everything to
work EXCEPT the password checking in Bugzilla. Any how, thanks for the
reply, its all working fine now.

Thank you,
   Casey Gregoire.

-----Original Message-----
From: David Miller [mailto:justdave at syndicomm.com]
Sent: Friday, January 17, 2003 5:19 PM
To: developers at bugzilla.org
Subject: Re: Login


On 1/14/03 9:55 PM +0000, Gervase Markham wrote:

> Casey Gregoire wrote:
>> I have this problem. I just got bugzilla working on my linux 7.1 box. but
>> when you go to login if you enter a valid username, and leave the
password
>> field empty it will log you in as that user. but if you type any text, it
>> will not work unless that test is the password that IS assigned to the
user.
>
> (Fortunately) this doesn't happen for me - because if it did, we'd have
> a bit of a crisis. I have no idea why it's happening for you, but would
> be eager to find out.
>
> Exactly which version of Bugzilla are you using?
> Does it happen for every account on the system?
> Are you using the emailsuffix param?
>
> This conversation should really take place in a bug. Please file one and
> CC me, and I will make it confidential just in case this is a security
> problem.

There's already a bug for this, filed by Casey on the 15th. :)
http://bugzilla.mozilla.org/show_bug.cgi?id=189189

Last I heard he was on RedHat 7.1 running ActiveState Perl...  which threw
most of us because we'd never seen ActiveState on Linux :)  Last action on
the bug I believe was he was trying to install an official RedHat
distribution of Perl to see if that fixed it.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>


From usmlekaplan at yahoo.com  Mon Jan 20 15:12:54 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Mon, 20 Jan 2003 07:12:54 -0800 (PST)
Subject: How to Log into CVS without entering the password
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF557E91A@BUCKWHEAT>
Message-ID: <20030120151254.47582.qmail@web20203.mail.yahoo.com>



Hi,
I am planning to automate the build process which
involves checking out the source code from CVS and
this step prompts for the password which I want to
avoid.Can you please let me know if there is any flag
in CVS that let's me include the password when setting
the CVSROOT variable.I do not want to use ssh as our
build is done on  winxp machine.
Thanks for your help,
Srikant

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


From jason at pyeron.com  Mon Jan 20 15:37:09 2003
From: jason at pyeron.com (Jason Pyeron)
Date: Mon, 20 Jan 2003 10:37:09 -0500 (EST)
Subject: How to Log into CVS without entering the password
In-Reply-To: <Pine.LNX.4.44.0301201024070.21723-100000@ns.pyerotechnics.com>
Message-ID: <Pine.LNX.4.44.0301201036390.21723-100000@ns.pyerotechnics.com>

sorry if this is a dup, there was some list issues on my behalf.

On Mon, 20 Jan 2003, Jason Pyeron wrote:


read http://www.bugzilla.org/download.html
from the download page (very bottom): 

win: > SET CVSROOT=:pserver:anonymous at cvs-mirror.mozilla.org:/cvsroot

-jason pyeron



-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Owner & Lead                  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)           500 West University Parkway #1S -
- +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.





From usmlekaplan at yahoo.com  Tue Jan 21 21:00:28 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Tue, 21 Jan 2003 13:00:28 -0800 (PST)
Subject: Implementation of Custom Fields in Bugzilla Error- editing Custom Field
Message-ID: <20030121210028.39102.qmail@web20207.mail.yahoo.com>

I installed 2.16.2 on Red Hat Linux 8 but couldn't
find any scripts related to Custom Field
implementation like editcustomfileds.cgi and so on.Is
there a document on how to implement this?
On our production environment it was already
implemented I don't know how and on the production
server  when editing a custom field I am getting this
error  

Attempted to send tainted string 'Update
customerfileds SET type='multi',
valid_exp='Test|Dev|QA|Field',
mandatory=0,default_value='test1' where id ='45'' to
the database at globals.pl line 251.


Is there a way to change the name of the custom field
itself while editing the custom field.
Thanks,
Srikant

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


From gerv at mozilla.org  Thu Jan 23 15:31:18 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 23 Jan 2003 15:31:18 +0000
Subject: MySQL 4.1
Message-ID: <3E300AC6.6010409@mozilla.org>

http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.012103/230210030

This supports subselects and Unicode.

Is there an argument for moving to it before we start converting lots of 
database stuff? It would prevent us having to write subselect emulation 
cruft.

Is there an argument for moving to it before we get start using Unicode 
throughout? Presumably Unicode support means you can store it as text 
rather than binary.

I love this quote:

Noted Michael "Monty" Widenius, MySQL CTO and co-founder, "Any software 
we release, regardless of version or stage, is free of all known bugs."

Gerv



From jason at pyeron.com  Thu Jan 23 19:29:01 2003
From: jason at pyeron.com (Jason Pyeron)
Date: Thu, 23 Jan 2003 14:29:01 -0500 (EST)
Subject: MySQL 4.1
In-Reply-To: <3E300AC6.6010409@mozilla.org>
Message-ID: <Pine.LNX.4.44.0301231423310.20692-100000@ns.pyerotechnics.com>


Does anyone believe they will be releasing v4.1 as stable/production by the 
time the changes mentioned are incorporated into the stable branch?

If you can answer yes, then go for it.

Asking a sysadmin to install beta (no less alpha) quality database, which
may interfere with there production quality install when installing a
stable release of bugzilla is inappropriate. IMHO

-Jason Pyeron

On Thu, 23 Jan 2003, Gervase Markham wrote:

http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.012103/230210030

This supports subselects and Unicode.

Is there an argument for moving to it before we start converting lots of 
database stuff? It would prevent us having to write subselect emulation 
cruft.

Is there an argument for moving to it before we get start using Unicode 
throughout? Presumably Unicode support means you can store it as text 
rather than binary.

I love this quote:

Noted Michael "Monty" Widenius, MySQL CTO and co-founder, "Any software 
we release, regardless of version or stage, is free of all known bugs."

Gerv

----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jpyeron at pyerotechnics.com>


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Owner & Lead                  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)           500 West University Parkway #1S -
- +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.






From bbaetz at acm.org  Thu Jan 23 20:06:08 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Fri, 24 Jan 2003 07:06:08 +1100
Subject: MySQL 4.1
In-Reply-To: <3E300AC6.6010409@mozilla.org>
References: <3E300AC6.6010409@mozilla.org>
Message-ID: <20030123200608.GA1139@mango.home>

On Thu, Jan 23, 2003 at 03:31:18PM +0000, Gervase Markham wrote:
> http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.012103/230210030
> 
> This supports subselects and Unicode.
> 

Yeah, well, its Alpha, so we can't rely on it for quite a while yet. I
don't even think 4.0 is released yet. Its not vapourware, since you can
download it, but its not something I'd trust a database too.

For those who are interested, I was playing with postgres last night,
and it can optimise OR queries (as long as there is an index on all the
bits we need to look at). Using subselects instead of LEFT JOINS also
speeds things up a ton. We should get dkl's pachs in, and then move bmo
over at some point in the short term.

Bradley


From preed at sigkill.com  Thu Jan 23 20:26:28 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Thu, 23 Jan 2003 12:26:28 -0800 (PST)
Subject: MySQL 4.1
In-Reply-To: <20030123200608.GA1139@mango.home>
Message-ID: <Pine.LNX.4.44.0301231221030.21911-100000@orbital.sigkill.com>

On Fri, 24 Jan 2003, Bradley Baetz wrote:

> We should get dkl's pachs in, and then move bmo over at some point in
> the short term.

I agree, but I will give MySQL one thing: changing the database while it's
"in play" (adding/deleting columns, etc.) is *really* easy in MySQL,
compared to PgSQL.

In fact, it's a downright pain in the ass with PgSQL; minor version number
upgrades (7.1 -> 7.2) require full dumps/restores of the database, and any
complex table changes require... badness. This is probably because either
a) the Postgres documentation is so bad, I'm doing something wrong, or b)
they use triggers and other "real DB fu", so it's more difficult than in
MySQL.

On Thu, 23 Jan 2003, Gervase Markham wrote:

> I love this quote:
>
> Noted Michael "Monty" Widenius, MySQL CTO and co-founder, "Any software
> we release, regardless of version or stage, is free of all known bugs."

Ahh... this is why I love the MySQL people... they fundamentally don't
"get it." Releasing a DB with sketchy, tacked on support for
commit/rollback does not make it ACID. And quotations like this do not
provide any sense of security that they know what they're doing.

Microsoft marketing says the same sorts of things... (note it's not really
false, just... meaningless).

Later,
Paul
  ----------------------------------------------------------------------
  J. Paul Reed                preed at sigkill.com || web.sigkill.com/preed
  To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin



From gerv at mozilla.org  Thu Jan 23 22:51:23 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 23 Jan 2003 22:51:23 +0000
Subject: MySQL 4.1
In-Reply-To: <Pine.LNX.4.44.0301231221030.21911-100000@orbital.sigkill.com>
References: <Pine.LNX.4.44.0301231221030.21911-100000@orbital.sigkill.com>
Message-ID: <3E3071EB.4090007@mozilla.org>

> In fact, it's a downright pain in the ass with PgSQL; minor version number
> upgrades (7.1 -> 7.2) require full dumps/restores of the database, and any
> complex table changes require... badness. This is probably because either
> a) the Postgres documentation is so bad, I'm doing something wrong, or b)
> they use triggers and other "real DB fu", so it's more difficult than in
> MySQL.

If this were true, this would suck mightily - Bugzilla's entire upgrade 
strategy (checksetup.pl) relies on being able to tweak the schema.

Gerv



From gerv at mozilla.org  Thu Jan 23 23:05:15 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 23 Jan 2003 23:05:15 +0000
Subject: Implementation of Custom Fields in Bugzilla Error- editing Custom
In-Reply-To: <20030121210028.39102.qmail@web20207.mail.yahoo.com>
References: <20030121210028.39102.qmail@web20207.mail.yahoo.com>
Message-ID: <3E30752B.4090507@mozilla.org>

usmle Prep wrote:
> I installed 2.16.2 on Red Hat Linux 8 but couldn't
> find any scripts related to Custom Field
> implementation like editcustomfileds.cgi and so on.Is
> there a document on how to implement this?

No. Custom fields are not supported by Bugzilla.

> On our production environment it was already
> implemented I don't know how 

Presumably the admin applied the patch for custom fields - it's in one 
of the Bugzilla bugs.

I'm afraid that it's unlikely that anyone will be able to help you. Not 
many people are familiar with this patch. If you look in the Bugzilla 
bug, you might find someone to email.

Gerv



From jon at vmware.com  Fri Jan 24 03:31:04 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 23 Jan 2003 19:31:04 -0800
Subject: os groups patch (feedback request)
Message-ID: <1043379064.14249.15.camel@jonschatz-lx.vmware.com>

i've completed my first working version of this code.the patch (against
HEAD)is here:

http://www.divisionbyzero.com/os_group.tgz

the archive contains two files:

os_group.patch
editopsys.cgi

patch your cvs tree with the patch file, and copy editopsys.cgi into
your bugzilla root directory.

this code provides an interface to edit os's like keywords or
milestones. this code also allows you to logically group os's together
for easy querying. a sample group is created ("All Windows") when
checksetup.pl is run. 

warning: this code will alter the structure of your db. make a backup
first. it works fine on my machine, but i can't make any guarantees for
you.

i'd love to get some feedback here. i'm going to attach this to a bug or
two eventually, but i have to figure out which ones first :-)

-jon

-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From bbaetz at acm.org  Fri Jan 24 07:09:19 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Fri, 24 Jan 2003 18:09:19 +1100
Subject: MySQL 4.1
In-Reply-To: <3E3071EB.4090007@mozilla.org>
References: <Pine.LNX.4.44.0301231221030.21911-100000@orbital.sigkill.com> <3E3071EB.4090007@mozilla.org>
Message-ID: <20030124070919.GB1124@mango.home>

On Thu, Jan 23, 2003 at 10:51:23PM +0000, Gervase Markham wrote:
> >In fact, it's a downright pain in the ass with PgSQL; minor version number
> >upgrades (7.1 -> 7.2) require full dumps/restores of the database, and any
> >complex table changes require... badness. This is probably because either
> >a) the Postgres documentation is so bad, I'm doing something wrong, or b)
> >they use triggers and other "real DB fu", so it's more difficult than in
> >MySQL.
> 
> If this were true, this would suck mightily - Bugzilla's entire upgrade 
> strategy (checksetup.pl) relies on being able to tweak the schema.

This has been fixed in version 7.3. You can even 'drop' columns without
needing a full copy of the db, and clean up later at your conviencence.
(DROP COLUMN is basically like oracle's ALTER TABLE ... SET UNUSED)

The only extra thing we need is that to delete an index you need to know
its name. Our current CREATE INDEX clauses don't name it, so we get a
system generated one. It is possible to find out the index name from teh
columns, but that involves poking at system tables in 7.3 whch changes
from release to release, so we probably want to avoid that...

Bradley


From gerv at mozilla.org  Fri Jan 24 09:36:33 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 24 Jan 2003 09:36:33 +0000
Subject: Using DBI
In-Reply-To: <a05200f1aba4f3ecd347e@[192.168.1.203]>
References: <20030117141241.GA1803@mango.home> <3E295BAC.9060907@mozilla.org> <a05200f1aba4f3ecd347e@[192.168.1.203]>
Message-ID: <3E310921.5060108@mozilla.org>

> Did someone change the order of the array?  I remember hassling dkl about
> that when we changed to using a hash for the dependency list because it
> listed the dependencies out of order.  If it's doing that now, someone's
> broken it again since then, and it should by all means be fixed.

As far as I can see, we use an array to store the dependency list, but a 
hash to collect the names of the ones we are missing. So, the missing 
modules still come out in hash order (i.e. any order you like.) This 
also needs to be a list, to preserve the ordering.

Do you want to hassle dkl again, or file a bug? :-)

Gerv



From Jeffrey.Morgan at BristolWest.com  Fri Jan 24 15:55:53 2003
From: Jeffrey.Morgan at BristolWest.com (Jeffrey Morgan)
Date: Fri, 24 Jan 2003 10:55:53 -0500
Subject: API to access data
Message-ID: <5D753A0448365C448CE3D9097D767E8C03DFA602@ohindex01.bristolwest.com>

Is that a document that describes how an external system can
interact with the bugzilla data?

Thanks
-Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030124/7fc9c40a/attachment.html>

From preed at sigkill.com  Fri Jan 24 23:49:48 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Fri, 24 Jan 2003 15:49:48 -0800 (PST)
Subject: API to access data
In-Reply-To: <5D753A0448365C448CE3D9097D767E8C03DFA602@ohindex01.bristolwest.com>
References: <5D753A0448365C448CE3D9097D767E8C03DFA602@ohindex01.bristolwest.com>
Message-ID: <Pine.LNX.4.53.0301241547570.3126@underworld.sigkill.com>

On Fri, 24 Jan 2003, Jeffrey Morgan wrote:

> Is that a document that describes how an external system can interact
> with the bugzilla data?

I don't know of such a document (other than the schema diagrams, the
administrator's manual, and, of course, the source code itself).

But take a look at bug 188570; if they're gonna do a Java port, one of the
first things they'd have to do, I'd think, is create such a document.

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  To hold on to sanity too tight is insane.  -- Nick Falzone, Pushing Tin


From gerv at mozilla.org  Sun Jan 26 13:45:03 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 26 Jan 2003 13:45:03 +0000
Subject: Bugzilla in the running for Product Excellence Award
Message-ID: <3E33E65F.8060106@mozilla.org>

LINUXWORLD NAMES FINALISTS FOR OPEN SOURCE PRODUCT EXCELLENCE AWARDS

http://www.linuxworldexpo.com/linuxworldny03/V33/press.cvn?id=11&p_id=10	

Best Developer Tools:
   ActiveState - Komodo
   APPX - 4.1.2
   Bugopolis - Bug Station
   IBM - Websphere Studio Appl. Developer V.5
   LTrix - lice

The Bug Station, of course, contains Bugzilla.

Has anyone heard from any of its developers? Are they even on this list?

Gerv



From justdave at syndicomm.com  Sun Jan 26 14:43:14 2003
From: justdave at syndicomm.com (David Miller)
Date: Sun, 26 Jan 2003 09:43:14 -0500
Subject: Bugzilla in the running for Product Excellence Award
In-Reply-To: <3E33E65F.8060106@mozilla.org>
References: <3E33E65F.8060106@mozilla.org>
Message-ID: <a05200f01ba59a3959fd2@[192.168.1.203]>

On 1/26/03 1:45 PM +0000, Gervase Markham wrote:

> LINUXWORLD NAMES FINALISTS FOR OPEN SOURCE PRODUCT EXCELLENCE AWARDS
>
> http://www.linuxworldexpo.com/linuxworldny03/V33/press.cvn?id=11&p_id=10
>
> Best Developer Tools:
>    ActiveState - Komodo
>    APPX - 4.1.2
>    Bugopolis - Bug Station
>    IBM - Websphere Studio Appl. Developer V.5
>    LTrix - lice
>
> The Bug Station, of course, contains Bugzilla.
>
> Has anyone heard from any of its developers? Are they even on this list?

I'm pretty sure they are.

FYI, that's been the headline article on the Bugzilla home page for a week
or so...  :-)

BTW, the winner was supposed to be announced on Thursday this last week at
4:30pm...  But as of Saturday morning I'll be darned if I can find word of
who won.  I haven't looked yet today, but half the net seems to be down
thanks to this MSSQL worm that's going around so I haven't had much luck
surfing this morning.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From preed at sigkill.com  Sun Jan 26 14:48:50 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 26 Jan 2003 06:48:50 -0800 (PST)
Subject: Bugzilla in the running for Product Excellence Award
In-Reply-To: <a05200f01ba59a3959fd2@[192.168.1.203]>
References: <3E33E65F.8060106@mozilla.org> <a05200f01ba59a3959fd2@[192.168.1.203]>
Message-ID: <Pine.LNX.4.53.0301260647580.11160@underworld.sigkill.com>

On Sun, 26 Jan 2003, David Miller wrote:

> But as of Saturday morning I'll be darned if I can find word of who won.
> I haven't looked yet today, but half the net seems to be down thanks to
> this MSSQL worm that's going around so I haven't had much luck surfing
> this morning.

It warn't us.

Websphere Studio Appl. Developer V.5 won.

http://www.linuxworldexpo.com/linuxworldny03/V33/press.cvn?id=11&p_id=12

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  To hold on to sanity too tight is insane.  -- Nick Falzone, Pushing Tin


From jimw at bugopolis.com  Sun Jan 26 22:47:24 2003
From: jimw at bugopolis.com (Jim Walters)
Date: Sun, 26 Jan 2003 14:47:24 -0800
Subject: Bugzilla in the running for Product Excellence Award
In-Reply-To: <Pine.LNX.4.53.0301260647580.11160@underworld.sigkill.com>
References: <3E33E65F.8060106@mozilla.org> <a05200f01ba59a3959fd2@[192.168.1.203]> <Pine.LNX.4.53.0301260647580.11160@underworld.sigkill.com>
Message-ID: <3E34657C.5020705@bugopolis.com>

:-(
After the ceremony I couldn't help but say, "IBM - You're goin' down!" :-)

Just got back to Seattle this morning. I'll write up something on the 
feedback we got and share it later this afternoon. But Bugzilla is 
defnately is the right app for the business model we are using. /*Lots*/ 
of people want to use it because it has a great reputation.

Jim

J. Paul Reed wrote:

>On Sun, 26 Jan 2003, David Miller wrote:
>
>  
>
>>But as of Saturday morning I'll be darned if I can find word of who won.
>>I haven't looked yet today, but half the net seems to be down thanks to
>>this MSSQL worm that's going around so I haven't had much luck surfing
>>this morning.
>>    
>>
>
>It warn't us.
>
>Websphere Studio Appl. Developer V.5 won.
>
>http://www.linuxworldexpo.com/linuxworldny03/V33/press.cvn?id=11&p_id=12
>
>Later,
>Paul
>  -----------------------------------------------------------------------
>  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
>  To hold on to sanity too tight is insane.  -- Nick Falzone, Pushing Tin
>----
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=jimw at bugopolis.com>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030126/dcfb6bdd/attachment.html>

From preed at sigkill.com  Mon Jan 27 13:00:04 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Mon, 27 Jan 2003 05:00:04 -0800 (PST)
Subject: Adopt me!
Message-ID: <Pine.LNX.4.53.0301270459330.23866@underworld.sigkill.com>


http://slashdot.org/article.pl?sid=03/01/27/0042256

Maybe we should do this... ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  To hold on to sanity too tight is insane.  -- Nick Falzone, Pushing Tin


From gerv at mozilla.org  Mon Jan 27 18:07:21 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 27 Jan 2003 18:07:21 +0000
Subject: [Fwd: Re: Issue Nomenclature]
Message-ID: <3E357559.8060205@mozilla.org>

See the below newsgroup message. What do people think of the idea of a 
patch (or incremental change) to convert all instances of "bug" etc. to 
[% _bug %], [% _Bug %], [% _bugs %] etc.?

Would this just be a maintainability headache for the templates, or 
would it allow people to make a much-requested customisation without the 
need for custom templates and hassle?

Gerv

-------- Original Message --------
Subject: Re: Issue Nomenclature
Date: Mon, 27 Jan 2003 08:19:38 -0500
From: Mike <NoSpam at NoSpam.net>
Newsgroups: netscape.public.mozilla.webtools
References: <b0saba$5qc3 at ripley.netscape.com> 
<b10o00$na32 at ripley.netscape.com> 
<MPG.189dfc96f2ce483298968c at news.verizon.net> 
<b12c7r$ah1 at ripley.netscape.com> <b132eu$af3 at ripley.netscape.com>

On Mon, 27 Jan 2003 10:50:30 +0000, Gervase Markham <gerv at mozilla.org>
wrote:

 >> Are you accounting for the fact that Bugzilla auto-linkifies "bug
 >> xxx"... I don't know of any way to deal with that without changing
 >> source code.
 >
 >That's right, there is no way to fix this without changing source code.
 >
 >/me considers whether we might accept a patch making all references to
 >"bug" configurable, e.g. by using in templates:

I would very much like to see all references to "bug" configurable.
The main reason being an enhancement request is not a bug, and to
refer to an ehancement as a bug merely confuses the [non-techinical]
end-users I am working with.



From jake at bugzilla.org  Mon Jan 27 20:30:30 2003
From: jake at bugzilla.org (Jake)
Date: Mon, 27 Jan 2003 15:30:30 -0500 (EST)
Subject: Adopt me!
In-Reply-To: <Pine.LNX.4.53.0301270459330.23866@underworld.sigkill.com>
References: <Pine.LNX.4.53.0301270459330.23866@underworld.sigkill.com>
Message-ID: <37361.208.20.196.122.1043699430.squirrel@waldo.homelinux.org>

Paul wrote:
>
> http://slashdot.org/article.pl?sid=03/01/27/0042256
>
> Maybe we should do this... ;-)

Anybody who wants to help w/my tution (more than they already are ;) is
more than welcome... and I wouldn't turn down a new computer or two. In
fact, if you're gonna buy me one, I'd like to see how well those new
Powerbooks from Mac work. I've never used OS X, but doing so on somebody
else's dime WFM :)






From jimw at bugopolis.com  Mon Jan 27 21:15:29 2003
From: jimw at bugopolis.com (Jim Walters)
Date: Mon, 27 Jan 2003 13:15:29 -0800
Subject: Impressions from LinuxWorld
Message-ID: <3E35A171.3040704@bugopolis.com>

The nice part about having Bugzilla as part of the product is that its 
pretty well known. Of the people stopping by the booth maybe only 25% 
didn't know it by name. So we didn't have to demo the product too 
heavily. But for those who wanted to see a demo they seemed pretty happy.

Besides the usual suspects ("What's up with the query page?" "Can it be 
integrated with XYZ source control system?") there was a lot of interest 
in the following aspects:

- report generation capability
- language support
- integration with GForge/SourceForge
- number of projects it can support

I described the reports and query result formats for 2.16.x and 
mentioned there are more wonderful things to come in 2.18 (right Gerv? 
:-)). I really had to punt on listing all available languages since I've 
seen German, rumors of Russian and some really old Japanese support. But 
I know I need to add language support to our web page (not to mention 
add foreign language translation of our web pages themselves), but I'm 
sort of a loss as to how to start collecting together a list of the 
Bugzilla supported languages and putting them on the box. Also, I'm I 
correct (I didn't promised this to anyone) in saying that the TT library 
will switch templates based on the language of the client browser?

With regard to integration with GForge/SourceForge I said that I was 
looking into it. I did find a reference to someone who apparently has 
done this once. But I think I will wait until I have a chance to play 
with PostgreSQL and 2.17 or until the GForge group decides whether they 
are going to use XML-RPC or SOAP.

Everyone seemed happy with what is going on with group limits in 2.18.

Got a chance to meet Dave Lawrence and foisted a schema poster on him. 
:-) Luis Villa over at Ximian took two posters. Anyway, had a great time 
and it was a positive thing for Bugopolis.

One quick question... is anything being changed with the query page? 
Would tabs like in the user prefs help? Same question for the admin options.

Thanks again for the great software. As soon as things settle (maybe in 
a week) I hope to get some time to contribute back some stuff to the 
project. If you have any particular questions e-mail me.

Jim




From gerv at mozilla.org  Mon Jan 27 22:30:14 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 27 Jan 2003 22:30:14 +0000
Subject: Impressions from LinuxWorld
In-Reply-To: <3E35A171.3040704@bugopolis.com>
References: <3E35A171.3040704@bugopolis.com>
Message-ID: <3E35B2F6.4070902@mozilla.org>

> Besides the usual suspects ("What's up with the query page?"

As in "how come it's changed so much from the default in Bugopolis?" or 
"How come it's so complicated/powerful?"

> - report generation capability
> - language support
> - integration with GForge/SourceForg
> - number of projects it can support

Now, basically unlimited, within the Product/Component 2-level limitation.

> I described the reports and query result formats for 2.16.x and 
> mentioned there are more wonderful things to come in 2.18 (right Gerv? 
> :-)).

Have you tried the patch on bug 16009? ;-) It's still quite rough around 
the edges, but I'm looking to polish it up RSN.

> I really had to punt on listing all available languages since I've 
> seen German, rumors of Russian and some really old Japanese support. But 

Yes. The problem is that it's still not possible, quite, to do a full 
localisation without changing code - we still haven't sorted out all the 
edge cases, and things like mail. There's a 12xxxx bug I have to review 
to that end.

> Bugzilla supported languages and putting them on the box. Also, I'm I 
> correct (I didn't promised this to anyone) in saying that the TT library 
> will switch templates based on the language of the client browser?

As of last week, yes :-)

> One quick question... is anything being changed with the query page? 
> Would tabs like in the user prefs help? Same question for the admin 
> options.

The admin options are going to get tabbified if I have anything to say 
about it. But, as for the query page, if you want something simpler, use 
a custom template, removing the options your users don't use.

Gerv



From jimw at bugopolis.com  Mon Jan 27 23:31:48 2003
From: jimw at bugopolis.com (Jim Walters)
Date: Mon, 27 Jan 2003 15:31:48 -0800
Subject: Impressions from LinuxWorld
In-Reply-To: <3E35B2F6.4070902@mozilla.org>
References: <3E35A171.3040704@bugopolis.com> <3E35B2F6.4070902@mozilla.org>
Message-ID: <3E35C164.4010500@bugopolis.com>

Well, I guess 'powerful' like gdb. ;-)

I think the main point of confusion for someone looking at it the first 
time is that that the horizontal bars seem to indicate three sorts of 
definable datasets but only the first two have associated search 
buttons. But that isn't really the way it works. So the question is why 
are there two Search buttons. (I imagine for convenience if scrolled 
down the page.) Since the advanced query appears to be a superset of the 
possibilities in the above two section someone using it doesn't need the 
other fields and maybe it could be tabbed into an advanced query form 
similar to the top level organization of some search engines.

But really, I need to fiddle with it more and see what it "feels" like 
with the modification I described.

Jim

Gervase Markham wrote:

>> Besides the usual suspects ("What's up with the query page?"
>
>
> As in "how come it's changed so much from the default in Bugopolis?" 
> or "How come it's so complicated/powerful?"
>



From gerv at mozilla.org  Tue Jan 28 00:14:10 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 28 Jan 2003 00:14:10 +0000
Subject: Impressions from LinuxWorld
In-Reply-To: <3E35C164.4010500@bugopolis.com>
References: <3E35A171.3040704@bugopolis.com> <3E35B2F6.4070902@mozilla.org> <3E35C164.4010500@bugopolis.com>
Message-ID: <3E35CB52.8080909@mozilla.org>

> I think the main point of confusion for someone looking at it the first 
> time is that that the horizontal bars seem to indicate three sorts of 
> definable datasets but only the first two have associated search 
> buttons. But that isn't really the way it works. So the question is why 
> are there two Search buttons. (I imagine for convenience if scrolled 
> down the page.) 

That's exactly the reason. The idea is that someone scared by complexity 
can just type in the top box and hit "Search". And that most of the 
commonly-used controls are on the "first page", so you don't have to 
scroll all that often.

> Since the advanced query appears to be a superset of the 
> possibilities in the above two section someone using it doesn't need the 
> other fields 

That's not really true. Because the other fields are so much easier to 
use, people tend to get as close as possible using them, and then add 
only the complicated clauses using the Boolean Charts.

> and maybe it could be tabbed into an advanced query form 
> similar to the top level organization of some search engines.

Thing is, I'm not sure that removing this section really reduces the 
visual complexity all that much.

Gerv



From jon at vmware.com  Tue Jan 28 21:04:03 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 28 Jan 2003 13:04:03 -0800
Subject: 2 template questions
Message-ID: <1043787843.28726.3.camel@jonschatz-lx.vmware.com>

1) Does anyone have an xemacs html-mode that knows how to properly
indent template files? when i hit tab, mine chokes with the message
"parsing prolog". I also get random segfaults with certain templates.

2) Where do I get the user hash to pass to global/footer.html.tmpl? I
can't seem to make it show anything other than the default non-logged-in
footer.

-jon

-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From jon at vmware.com  Tue Jan 28 21:07:52 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 28 Jan 2003 13:07:52 -0800
Subject: 2 template questions
In-Reply-To: <1043787843.28726.3.camel@jonschatz-lx.vmware.com>
References: <1043787843.28726.3.camel@jonschatz-lx.vmware.com>
Message-ID: <1043788072.27397.5.camel@jonschatz-lx.vmware.com>

On Tue, 2003-01-28 at 13:04, Jonathan Schatz wrote:
> 2) Where do I get the user hash to pass to global/footer.html.tmpl? I
> can't seem to make it show anything other than the default non-logged-in
> footer.

nevermind. i just realized that if i import the global $vars (rather
than my own locally scoped version) it Just Works(tm).

-jon

-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From jon at vmware.com  Tue Jan 28 21:51:26 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 28 Jan 2003 13:51:26 -0800
Subject: yet another template question
Message-ID: <1043790685.27397.10.camel@jonschatz-lx.vmware.com>

how do i get useful error messages out of Template? i've got a template
file that dies with this message:

Template::Exception at /usr/lib/perl5/5.8.0/CGI/Carp.pm line 301.

which tells me nothing. line 301 of Carp.pm is:

sub realdie { CORE::die(@_); }

which is also kind of useless. is there a way to to get more worthwhile
info (or a better way to debug template files)?

-jon

-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From justdave at syndicomm.com  Tue Jan 28 22:00:32 2003
From: justdave at syndicomm.com (David Miller)
Date: Tue, 28 Jan 2003 17:00:32 -0500
Subject: yet another template question
In-Reply-To: <1043790685.27397.10.camel@jonschatz-lx.vmware.com>
References: <1043790685.27397.10.camel@jonschatz-lx.vmware.com>
Message-ID: <a05200f28ba5cad9bfa36@[192.168.1.203]>

On 1/28/03 1:51 PM -0800, Jonathan Schatz wrote:

> how do i get useful error messages out of Template? i've got a template
> file that dies with this message:
>
> Template::Exception at /usr/lib/perl5/5.8.0/CGI/Carp.pm line 301.
>
> which tells me nothing. line 301 of Carp.pm is:
>
> sub realdie { CORE::die(@_); }
>
> which is also kind of useless. is there a way to to get more worthwhile
> info (or a better way to debug template files)?

Look in globals.pl for a routine called "die_with_dignity" which is
commented out.  In theory you can uncomment that and it'll give you a
traceback when a die is encountered.  Unfortunately the one that's there
got broken by some recent Bugzilla changes.  Replace it with this:

sub die_with_dignity {
    require Carp;  # for confess
    my ($err_msg) = @_;
    print $err_msg;
    confess($err_msg);
}
$::SIG{__DIE__} = \&die_with_dignity;

Be warned, it makes the error messages REALLY ugly to end users (it's
basically only useful to programmers) so you probably want to comment it
out again after you find the error.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From bbaetz at acm.org  Wed Jan 29 07:20:10 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 29 Jan 2003 18:20:10 +1100
Subject: yet another template question
In-Reply-To: <1043790685.27397.10.camel@jonschatz-lx.vmware.com>
References: <1043790685.27397.10.camel@jonschatz-lx.vmware.com>
Message-ID: <20030129072010.GB1290@mango.home>

On Tue, Jan 28, 2003 at 01:51:26PM -0800, Jonathan Schatz wrote:
> how do i get useful error messages out of Template? i've got a template
> file that dies with this message:
> 
> Template::Exception at /usr/lib/perl5/5.8.0/CGI/Carp.pm line 301.
> 
> which tells me nothing. line 301 of Carp.pm is:

This is a perl bug which TT triggers. See
http://mailhub.ourshack.com/pipermail/templates/2002-October/003779.html
and
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-09/msg01204.html

and update TT to 2.08c or later.

Bradley




From bbaetz at acm.org  Wed Jan 29 07:27:44 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 29 Jan 2003 18:27:44 +1100
Subject: 2 template questions
In-Reply-To: <1043787843.28726.3.camel@jonschatz-lx.vmware.com>
References: <1043787843.28726.3.camel@jonschatz-lx.vmware.com>
Message-ID: <20030129072744.GA1471@mango.home>

On Tue, Jan 28, 2003 at 01:04:03PM -0800, Jonathan Schatz wrote:
> 1) Does anyone have an xemacs html-mode that knows how to properly
> indent template files? when i hit tab, mine chokes with the message
> "parsing prolog". I also get random segfaults with certain templates.

emacs segfaults? Fun...

You can't use sgml-mode for validation/indenting, because TT files
aren't sgml. Theres an html-helper-mode I use to do .ASP stuff, and ISTR
that the tag format is configurable. You may want ot look into thtat.

> 
> 2) Where do I get the user hash to pass to global/footer.html.tmpl? I
> can't seem to make it show anything other than the default non-logged-in
> footer.
> 

As you notd, you need to keep the lboal vars hash arround for the
moment. Thats (slowly) going away, and it will be Bugzilla.user instead,
at some point in the future.

> -jon

Bradley


From bbaetz at acm.org  Wed Jan 29 10:31:41 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 29 Jan 2003 21:31:41 +1100
Subject: Bugzilla->instance and friends
Message-ID: <20030129103141.GA2390@mango.home>

Currently, to get a template object, you do:

my $template = Bugzilla->instance->template

to get a dbh:

my $dbh = Bugzilla->instance->dbh

And so on. IOW, Bugzilla is a singleton class which has references to
various objects we want to keep arround for some span of time.

There were several anticipated advantage behind all this. One was that
all the global 'stuff' would be in one place, which would make it easier
to handle, both for normal use and mod_perl. There was also this vague
hope that we could do user logins in one step, by passing a separate arg
(or rather, hashkey, in the spirit of other perl-based stuff) to
represent quietly_check vs require vs that-param-joel-added. This would
allow one command to do everything.

I've been playing with this when trying to fix bug 187861, and I'm not
sure that this is the way to go anymore.

My original idea for the fix was to do what I'd been planning for a
while - make the Bugzilla object creation routine take an argument
indicating what type of program it was, and then only initalise whats
required. (With defaults so that the majority of cgi files wouldn't
have to specify anything, and would get Bugzilla::TYPE_CGI
automaticaly)

Then it was mentioned that the ->instance was a bit ugly. Removing that
points to the fact that we don't really need an object, whch leaves us
with a whle set of unrelated subroutines.

So, the alternative is to use Class::Singleton either directly (or just
use the standard ||= construct), possibly with Apache::Singleton too
(despite the name, this sort of works without mod_perl, although the
install tests fail). To get a template, you then:

Bugzilla::Template->instance

and to get a cgi object:

Bugzilla::CGI->instance

DBH's will be Bugzilla::DB->dbh() (rather than instance) because of the
shadowdb stuff and the fact that we don't subclass DBI, nor do we want
to. The shadowdb switch routines can move to Bugzilla::DB, and the
Bugzilla.pm file then becomes the location of generic functions like
get_product_id and friends, as well as $VERSION. Stuff like the
versioncache may go there too.

Code which wants a cgi object then explictly asks for it, and its
created as needed. Code which doesn't never asks, and so never inits
stuff it doesn't want. (This doesn't actually solve the current problem
with processmail, because globals.pl gets the cgi object, so we probably
have to $^0 test that instead. Just forget about that for now, and
imagine a world where globals.pl is gone. :)

mod_perl can explictly call
Bugzilla->load_everything_persistent_right_now_please, or something. (TT
devel versions have a Template->preload to do much the same thing)

Pros of the new way:
- Stuff isn't mangled together
  - No circular links like we will have with Bugzilla->user =>
    Bugzilla::User -> Bugzilla->dbh
- More explicit
- Stuff can be lazily instantiated
  - Not much benefits from this - initing the Template for an
    attachment.cgi?action=view is the only case I can think of where we
    won't ever use a template.
- Simpler/cleaner/etc

Cons vs the current way:
- May require an extra module (Class::Singleton)
  - I don't object, but I know others may
- We can never have two Template/CGI objects
  - Well, we can, but it would be a bit of hackery
  - Do we care?
- Errors may be delayed. For example, if theres an error creating the
  Template object, we won't know until we're about to use the result
  - Again, do we care? I don't think so.
- Things are separated, and so persistency isn't as obvious.
  - We may need separate cleanup routines, although doing something like
    what Apache::Singleton does will make this simple.
- More code in .cgis
  - although not more than the current code.
- More characters to type
  - We get a template/CGI once per script. DBH is the only one we do
    more of
- Need to find somewhere to stick the currently logged in user where it
  is globally accessible
  - This is the main one, but not having modularised the login code yet,
    I don't have details. Bugzilla::Login->current_user perhaps. In any
    event, explicit initliasation will be needed for this one so that
    we can differentiate between the types of logins.

Thoughts? I'm gong to start hacking on this tonight, and will see if its
workable. Yes, the cons list takes up more lines, but thats not the
point :)

Bradley


From bbaetz at acm.org  Wed Jan 29 10:59:23 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 29 Jan 2003 21:59:23 +1100
Subject: Bugzilla->instance and friends
In-Reply-To: <20030129103141.GA2390@mango.home>
References: <20030129103141.GA2390@mango.home>
Message-ID: <20030129105923.GA3176@mango.home>

On Wed, Jan 29, 2003 at 09:31:41PM +1100, Bradley Baetz wrote:
> 
> Cons vs the current way:
  - The test for 'is bugzilla down' doesn't have an obvious place to go.
    - I'm guessing the cgi object constructor would work for that, 
      although I guess there are times where we want to stop batch
      cmdline jobs

Bradley


From jth at mikrobitti.fi  Wed Jan 29 11:08:17 2003
From: jth at mikrobitti.fi (Jouni Heikniemi)
Date: Wed, 29 Jan 2003 13:08:17 +0200
Subject: Bugzilla->instance and friends
In-Reply-To: <20030129103141.GA2390@mango.home>
Message-ID: <5.1.0.14.2.20030129130330.01d12808@mikrobitti.fi>

At 21:31 29.1.2003 +1100, you wrote:
>So, the alternative is to use Class::Singleton either directly (or just
>use the standard ||= construct), possibly with Apache::Singleton too
>(despite the name, this sort of works without mod_perl, although the
>install tests fail). To get a template, you then:

Why is that class called Apache::Singleton? Is there something that should 
be abstracted out using something less Apache-specific? I don't know if 
Apache::Singleton is anything bad (I really know nothing about it), but 
having something like that in the code sounds like a potential disaster for 
people using other web server software. While it may be harmless now, it 
might not be that in every possible environment or in the future.


Jouni




From bbaetz at acm.org  Wed Jan 29 11:26:23 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 29 Jan 2003 22:26:23 +1100
Subject: Bugzilla->instance and friends
In-Reply-To: <5.1.0.14.2.20030129130330.01d12808@mikrobitti.fi>
References: <20030129103141.GA2390@mango.home> <5.1.0.14.2.20030129130330.01d12808@mikrobitti.fi>
Message-ID: <20030129112623.GB3176@mango.home>

On Wed, Jan 29, 2003 at 01:08:17PM +0200, Jouni Heikniemi wrote:
> At 21:31 29.1.2003 +1100, you wrote:
> >So, the alternative is to use Class::Singleton either directly (or just
> >use the standard ||= construct), possibly with Apache::Singleton too
> >(despite the name, this sort of works without mod_perl, although the
> >install tests fail). To get a template, you then:
> 
> Why is that class called Apache::Singleton? Is there something that should 
> be abstracted out using something less Apache-specific? I don't know if 
> Apache::Singleton is anything bad (I really know nothing about it), but 
> having something like that in the code sounds like a potential disaster for 
> people using other web server software. While it may be harmless now, it 
> might not be that in every possible environment or in the future.

Yeah, the name is sucky. Basically, you can inherit from
Apache::Singleton::Per{Request,Process}. Whether we use hat or roll our
own isn't realy important at this stage.

Theres no effect when not running under mod_perl, but we wuld need some
changes to run under the win32 perlex stuff.

Bradley


From zach at zachlipton.com  Fri Jan 31 15:04:37 2003
From: zach at zachlipton.com (Zach Lipton)
Date: Fri, 31 Jan 2003 07:04:37 -0800
Subject: [mailinglists] Fw: Bugzilla Guide
In-Reply-To: <OE717qDEoHin7kQOgZS00001ce6@hotmail.com>
Message-ID: <BA5FD085.95EC%zach@zachlipton.com>

Hi Ashutosh,

Thanks for the praise!

Actually, Bugzilla is Open Source free-software under the Mozilla Public
License (mozilla.org/MPL). As a result, you are free to do a wide variety of
things including post it on the web at no charge. You are free to make any
modifications to the software as well. Of course, if you think your changes
would be helpful to the Bugzilla community at large, we would appreciate a
patch, but it is by no means required.

Of more information on Free Software, you may want to look at gnu.org and
opensource.org.

Zach

On 1/31/03 3:07 AM, "Ashutosh Tyagi" <ashutosh_jack at hotmail.com> wrote:

> Hi Zach,
> 
> I found your Manual The Bugzilla Guide very useful is setting up Bugzilla the
> bug tracking software in our systems, by which only specifying the IP address
> of the machine on which Bugzilla is installed we can see the home page and can
> use the Bug Tracking Software. The integration of My Sql and Apache web server
> is very good.
> 
> I want to know that is there any possibility by which we can upload this Bug
> tracking software to our respective Website by which our customers can report
> the bugs in our products directly through our Website because we have .cgi
> files in this software, I know that some license will be required for this.
> But is it possible.
> 
> Thanx in advance.
> 
> With warm regards
> Ashutosh Tyagi
>