http://bugzilla.novell.com/show_bug.cgi?id=601779http://bugzilla.novell.com/show_bug.cgi?id=601779#c0
Summary: 32bit 'tree' doesn't show files 2GB and larger
Classification: openSUSE
Product: openSUSE 11.2
Version: Final
Platform: x86
OS/Version: openSUSE 11.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: jc(a)ymmv.dk
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9)
Gecko/20100317 SUSE/3.5.9-0.1.1 Firefox/3.5.9
Hi
On 32bit systems the 'tree' command dosn't show 'large' files.
I have tested on a 64bit system as well, and the problem is only present on
32bit systems.
I have done a fair amount of research, comparing compile-time arguments with
those of 32bit Debian packages. In the end I think it comes down to the 'spec'
file:
In tree.spec the 'make' command is:
%build
make CFLAGS="$RPM_OPT_FLAGS"
-which overrides the CFLAGS set in the Makefile:
CFLAGS=-O2 -Wall -fomit-frame-pointer -DLINUX -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64
-which results in the binary being built with these flags instead:
RPM_OPT_FLAGS="-O2 -g -m32 -march=i586 -mtune=i686 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables"
Now;
If I change the spec file so that;
%build
make
-then the compiler gets the flags as set in the Makefile, and the resulting
binary works with files larger than 2G.
I'm guessing that it's desirable to get $RPM_OPT_FLAGS passed to the compiler,
but I'm unsure as to how one would 'merge' this variable with $CFLAGS from the
Makefile?
As for the severity of the bug:
It doesn't break the system, but the functionality of the command is seriously
hampered by this. It seems reasonable (to me) that it's a packaging bug, and
therefore it should be easily fixed.
I have confirmation from the opensuse(a)opensuse.org list that the bug is present
on 11.0, so it seems to be an 'old' problem...
Kind Regards,
Jon Clausen
Reproducible: Always
Steps to Reproduce:
1. get or create a file larger than 2GB
I used 'dd' to create two files - one 2GB, one 1KB smaller:
dd if=/dev/zero of=2G bs=1k count=2097152
dd if=/dev/zero of=2G-1k bs=1k count=2097151
2. use 'tree /path/to/large/file'
3. observe output
Actual Results:
output from 32bit system:
jon@nx8220:~> ll tmp/largefiles/
total 4194304
-rw-r--r-- 1 jon users 2147483648 2010-04-30 12:50 2G
-rw-r--r-- 1 jon users 2147482624 2010-04-30 12:52 2G-1k
jon@nx8220:~> tree tmp/largefiles/
tmp/largefiles/
`-- 2G-1k
0 directories, 1 file
Expected Results:
output from 64bit system:
jon@cnu8092slm:~> ll tmp/largefiles/
total 4194304
-rw-r--r-- 1 jon users 2147483648 2010-04-30 12:58 2G
-rw-r--r-- 1 jon users 2147482624 2010-04-30 12:58 2G-1k
jon@cnu8092slm:~> tree tmp/largefiles/
tmp/largefiles/
|-- 2G
`-- 2G-1k
0 directories, 2 files
AFAICT the flag that makes the difference is -D_FILE_OFFSET_BITS=64 - which
makes the binary use *stat64() rather than *stat() when files are 'large'.
On 64bit systems I suppose everything uses *stat64() anyways, which is why the
problem only surfaces on 32bit systems... ?
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=578994http://bugzilla.novell.com/show_bug.cgi?id=578994#c0
Summary: hwinfo cuts off list of cpu features
Classification: openSUSE
Product: openSUSE 11.3
Version: Factory
Platform: x86-64
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: HMWiesinger(a)gmx.at
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (compatible; Konqueror/4.3; Linux) KHTML/4.3.1
(like Gecko)
The list of supported features is cut off at some point. hwinfo (16.10) shows
the following list:
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,
clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,
arch_perfmon,pebs,bts,rep_good,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,
smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse
whereas "cat /proc/cpuinfo" shows:
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon
pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority
Reproducible: Always
Steps to Reproduce:
1. hwinfo --cpu
2. cat /proc/cpuinfo
3. compare output
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=559704http://bugzilla.novell.com/show_bug.cgi?id=559704#c0
Summary: gnome-web-photo doesn't work because it can't find
libxul.so
Classification: openSUSE
Product: openSUSE 11.2
Version: Final
Platform: x86
OS/Version: openSUSE 11.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: arizonagroovejet(a)gmail.com
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5)
Gecko/20091103 SUSE/3.5.5-1.1.2 Firefox/3.5.5
mike@continuity:/tmp$ gnome-web-photo http://news.bbc.co.uk foo.png
gnome-web-photo: error while loading shared libraries: libxul.so: cannot open
shared object file: No such file or directory
Reproducible: Always
Steps to Reproduce:
1. Try and use gnome-web-photo
Actual Results:
Error message as shown above.
Expected Results:
That it works.
It can be made to work like this:
mike@continuity:/tmp$ LD_LIBRARY_PATH="/usr/lib/xulrunner-1.9.1.5/"
gnome-web-photo http://news.bbc.co.uk foo.png
*** nss-shared-helper: Shared database disabled (set NSS_USE_SHARED_DB to
enable).
mike@continuity:/tmp$ identify foo.png
foo.png PNG 1024x1710 1024x1710+0+0 8-bit DirectClass 530kb
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=578053http://bugzilla.novell.com/show_bug.cgi?id=578053#c0
Summary: postgresql-plperl looks for libperl.so in the wrong
place
Classification: openSUSE
Product: openSUSE 11.3
Version: Factory
Platform: All
OS/Version: openSUSE 11.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: eggyknap(a)gmail.com
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.8
(KHTML, like Gecko) Chrome/4.0.299.0 Safari/532.8
On a completely new openSUSE 11.3 machine, I installed the postgresql-server,
postgresql, and postgresql-plperl packages. After starting PostgreSQL and
letting it initialize a new database, I sudo-d to the postgres user, and tried
to add the PL/Perl language, as follows, with the error below:
postgres@linux-e16r:~> createlang plperl
createlang: language installation failed: ERROR: could not load library
"/usr/lib/postgresql/plperl.so": libperl.so: cannot open shared object file: No
such file or directory
libperl.so lives in
/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE/libperl.so. Creating a
symlink at /usr/lib/libperl.so to the installed libperl.so binary works around
the problem. This also exists in at least one of the 10.x versions, though I
don't have access to the servers to know the precise version(s)
As a secondary note, the description of the postgresql-plperl package, at least
as it appears in YaST2, says the package also includes PL/Tcl and PL/Python.
This is incorrect.
Thirdly, the documentation also claims "PostgreSQL also offers the builtin
procedural language PL/SQL". This is also incorrect -- PL/SQL is an
Oracle-specific language. PostgreSQL offers PL/pgSQL, which fact might be worth
noting in the PL/Perl documentation, or it might not.
Reproducible: Always
Steps to Reproduce:
1.install postgresql, postgresql-server, and postgresql-plperl
2.start postgresql (/etc/init.d/postgresql start)
3.become the postgres user (sudo su - postgres)
4.create the plperl language in the default database: createlang plperl
Actual Results:
# createlang plperl
createlang: language installation failed: ERROR: could not load library
"/usr/lib/postgresql/plperl.so": libperl.so: cannot open shared object file: No
such file or directory
Expected Results:
createlang should have no output, and a 0 exit status
I realize this is a packaging bug, and likely not something distributed by
Novell directly. I saw nowhere else to file the bug.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551014
Summary: one click install: error ccoured while initializing
the software repository
Classification: openSUSE
Product: openSUSE 11.2
Version: RC 1
Platform: Other
OS/Version: openSUSE 11.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: suse-beta(a)cboltz.de
QAContact: jsrain(a)novell.com
Found By: Beta-Customer
Created an attachment (id=324701)
--> (http://bugzilla.novell.com/attachment.cgi?id=324701)
y2logs
(11.2 repo from today, probably near RC2)
I tried to install YaBSC from the openSUSE:Tools repo using one click install.
After entering the root password, YaST showed an error dialog:
An error ccoured while initializing the software repository.
Details:
Try again?
[Ja] [Nein] (= Yes / No)
Yes, the line after "Details:" was really empty. Therefore this bug has two
parts:
- the missing information about details in the error dialog
- maybe the failure itsself is also a bug
The last lines from y2log when the error dialog was open:
2009-10-29 15:48:16 <1> geeko(26435) [zypp]
RepoManager.cc(init_knownRepositories):557 end construct known repos
2009-10-29 15:48:16 <3> geeko(26435) [Pkg] Source_Create.cc(RepositoryAdd):449
alias openSUSE:Tools already exists
[That's probably the disabled 11.1 version of the openSUSE:tools repo]
2009-10-29 15:48:16 <1> geeko(26435) [Pkg]
OneClickInstallWorkerFunctions.ycp:113 Pkg Builtin called: SourceRefreshNow
2009-10-29 15:48:16 <3> geeko(26435) [Interpreter]
OneClickInstallWorkerFunctions.ycp:113 Parameter 1 is nil, Integer is required
2009-10-29 15:48:16 <1> geeko(26435) [Pkg]
OneClickInstallWorkerFunctions.ycp:116 Pkg Builtin called: LastError
2009-10-29 15:48:16 <1> geeko(26435) [ui] YPushButton.cc(setFunctionKey):183
Guessing button role YOKButton for YPushButton "Ja" at 0x18fb1b8 from
function key F10
2009-10-29 15:48:16 <1> geeko(26435) [ui] YPushButton.cc(setFunctionKey):183
Guessing button role YCancelButton for YPushButton "Nein" at 0x198aac
8 from function key F9
The full y2logs are attached. Search for [cb] in y2log - I have marked when
the error dialog popped up.
BTW: After answering the dialog with yes (= try again) and confirming the repo
details, the installation worked.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=630434http://bugzilla.novell.com/show_bug.cgi?id=630434#c0
Summary: Server refuses to boot, while used iSCSI based non "/"
file system is not available.
Classification: openSUSE
Product: openSUSE 11.3
Version: Final
Platform: x86-64
OS/Version: SLES 11
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Basesystem
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: DOlsson(a)WEB.de
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.6)
Gecko/20100626 SUSE/3.6.6-1.1 Firefox/3.6.6
On our SLES 11 GM based "mirror" server (running as a virtual XEN guest), we
are using iSCSI to attach to our NAS holding the "/data" file system, whereas
all other file systems (/, /boot, /var, /home) are placed on local disk.
When rebooting the server, it refuses to boot correctly, while it is not able
to "fsck" the "/data" file system -- The system stops in "(repair filesystem)
#" mode (after having entered the "root" password).
Using the "nofail" option for the "/data" file system helps to get the system
to reboot correctly, but in this case the "/data" file system is neither being
checked nor mounted during the system startup, which therefore -- once again --
makes the system unusable!
Using the "nofail" option is part of the "solution" listed in the SLES 11 SP1
documentation, but since the system is unusable, this is *not* the solution to
the problem.
The problem is that the "mkinitrd" is and the boot scripts are not capable of
handling iSCSI attached file systems correctly.
The correct way of handling iSCSI attached devices are:
- All iSCSI devices having the "onboot" set as node startup setting must be
attached during the "initrd" boot sequence (i.e. by "boot.open-iscsi") -- and
this *independent* of whether the "/" (root) file system is attached via iSCSI
or not,
- All iSCSI devices having the "automatic" set as node startup setting need to
be attached during the normal booting sequence (i.e. by "open-iscsi"),
- All iSCSI devices having the "manual" set as node startup setting should be
left alone.
Using such a attaching schema will ensure that a server is capable of being
booted with all its iSCSI file systems being attached, checked and mounted.
Reproducible: Always
Steps to Reproduce:
1a. Setup an iSCSI device and mount it e.g. as "/home" (no changes to
"/etc/fstab").
2a. Reboot the system
3a. System fails to boot, while "/home" is not available.
1b. Setup an iSCSI device and mount it e.g. as "/home", and add the "nofail"
option in "/etc/fstab" to the "/home" mount point.
2b. Reboot system.
3b. System boots, but "/home" is neither checked nor mounted!
Actual Results:
When using iSCSI devices for non root file systems
- the system is not able to boot, when the file system on the iSCSI device is
listed in "/etc/fstab" as a file system that should be mounted
or
- the system boots boots, when the file system on the iSCSI device has been
marked with "nofail" in "/etc/fstab", but the file is neither being checked nor
it is being mounted.
Expected Results:
System boots with all file systems listed in "/etc/fstab" being checked and
mounted independently of whether they are on local or iSCSI attached disks.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=549849
Summary: Eclipse doesn't accept mouse clicks on buttons
Classification: openSUSE
Product: openSUSE 11.2
Version: RC 1
Platform: x86
OS/Version: openSUSE 11.2
Status: NEW
Severity: Major
Priority: P5 - None
Component: Development
AssignedTo: pth(a)novell.com
ReportedBy: davor.cengija(a)gmail.com
QAContact: qa(a)suse.de
Found By: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3)
Gecko/20090909 SUSE/3.5.3-3.2 Firefox/3.5.3
As described on Beta and Pre-release forum,
http://forums.opensuse.org/pre-release-beta/424021-eclipse-doesnt-accept-mo…
I just downloaded the newest Eclipse, just to be sure, but I had the same
problem with some older version.
Start Eclipse, and for example try to create a new project. Enter the project's
name and click Next. The button recognizes that it's being clicked (e.g. gets
focus, changes color etc) but nothing happens. Pressing enter works (as the
button has focus now). The same thing happens on the next screen with the
Finish button.
Reproducible: Always
Steps to Reproduce:
1. Start Eclipse
2. Click File>New>Java Project
3. Enter project's name, click Next - nothing happens
4. Press Enter button - wizard advances to next step, as expected
It seems that this problems is easiliy reproducible, and is related to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=288909
However, it is quite serios, almost a showstopper for a number of users.
If you need additional details, don't hesitate to ask, I'm more than willing to
assist here.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=635920https://bugzilla.novell.com/show_bug.cgi?id=635920#c0
Summary: hdparm v9.28 does not work with OCZ Vertex 2E SSD
Classification: openSUSE
Product: openSUSE 11.3
Version: Final
Platform: All
OS/Version: openSUSE 11.3
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Basesystem
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: Greg.Freemyer(a)gmail.com
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8)
Gecko/20100723 SUSE/3.6.8-0.1.1 Firefox/3.6.8
Please upgrade oS 11.2 and 11.3 to hdparm v9.30 available on sourceforge.
== background for request
This bug relates to the hdparm --trim-sector-ranges-stdin capability which is
invoked by the wiper.sh script which is also part of the hdparm package.
Support for wiper.sh and hdparm --trim-sector-ranges-stdin is included in both
openSUSE 11.2 and 11.3.
Thomas Hertweck <Thomas.Hertweck at web.de> reported:
> I have now installed openSUSE 11.3 on a OCZ Vertex 2E SSD. I used a
> standard ext4 filesystem, the mount options at the moment are
> "rw,noatime,acl,user_xattr". Unfortunately, wiper.sh doesn't work at all.
>
> No joy, obviously.
I have asked Mark Lord (the hdparm maintainer) for feedback.
He said the default max TRIM payload sent via hdparm has been lowered in the
latest release of hdparm v2.30 and recommended we upgrade and see if it fixes
the problem
Reproducible: Always
Steps to Reproduce:
1. Run wiper.sh against a Ext4 FS on a OCZ Vertex 2E SSD
2.
3.
Actual Results:
> $> wiper.sh --verbose --commit /dev/sdb1
> wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord.
> wiper.sh: This tool is DANGEROUS! Please read and understand
> wiper.sh: /usr/share/doc/packages/hdparm/README.wiper
> wiper.sh: before going any further.
> rootdev=/dev/sdb1
> fsmode2: fsmode=read-write
> /: fstype=ext4
> freesize = 45338732 KB, reserved = 453387 KB
> Preparing for online TRIM of free space on /dev/sdb1 (ext4 mounted
> read-write at /).
> This operation could silently destroy your data. Are you sure (y/N)? y
> Creating temporary file (44885345 KB)..
> Syncing disks..
> Beginning TRIM operations..
> get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.13467
> /dev/sdb:
> trimming 89770696 sectors from 1493 ranges
> FAILED: Input/output error
> Removing temporary file..
> Syncing disks..
> Aborted.
Expected Results:
All EXT4 unallocated space on the SSD should be "trimmed" such that the SSD can
erase the unallocated sectors in advance of their being used, thus improving
performance of the SSD.
Note: There is a wiki entry that covers discard (trim) in openSUSE:
http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support
Thread that originated the bug is available at:
http://lists.opensuse.org/opensuse-kernel/2010-08/msg00068.html
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=635830https://bugzilla.novell.com/show_bug.cgi?id=635830#c0
Summary: AppArmor: ag_subdomain broken: Can't locate
Immunix/Notify.pm
Classification: openSUSE
Product: openSUSE 11.3
Version: Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: YaST2
AssignedTo: juhliarik(a)novell.com
ReportedBy: mvidner(a)novell.com
QAContact: jsrain(a)novell.com
CC: kmachalkova(a)novell.com
Found By: ---
Blocker: ---
$ /usr/lib/YaST2/servers_non_y2/ag_subdomain
Can't locate Immunix/Notify.pm in @INC (@INC contains: [...]) at
/usr/lib/YaST2/servers_non_y2/ag_subdomain line 23
yast2-apparmor contains the file as
/usr/lib/perl5/vendor_perl/Immunix/Notify.pm but that path is not searched by
Perl. It needs to be in vendor_perl/$VERSION/Immunix instead.
I am not sure where exactly this hits the user, but surely at some point
y2-apparmor calls the agent.
Originally reported by ezekiellg at
http://forums.opensuse.org/english/get-help-here/applications/445307-yast-p…
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=635762https://bugzilla.novell.com/show_bug.cgi?id=635762#c0
Summary: webalizer didn't support "GeoIP"
Classification: openSUSE
Product: openSUSE 11.3
Version: Final
Platform: All
OS/Version: openSUSE 11.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: st-schaefer(a)fsproductions.de
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.8)
Gecko/20100723 SUSE/3.6.8-1.3 Firefox/3.6.8
If we use webalizer with configuration Options:
GeoIP yes
GeoIPDatabase /var/lib/GeoIP/GeoIP.dat
we get this error output:
Warning: Invalid keyword 'GeoIP' (webalizer.conf)
Warning: Invalid keyword 'GeoIPDatabase' (webalizer.conf)
We found the following solution for this behavior:
"In earlier versions of this patch, there was a configure-parameter
"--enable-geoip" to explicitly enable the geoip-extension. If you use this
parameter with patch-20070115, it acts like "--disable-geoip"! Beware of using
the --enablie-geoip option if you want to enable GeoIP. This took me some time
to locate this error..."
This happens with webalizer Versions newer 2.0.
Stefan
Reproducible: Always
Steps to Reproduce:
1.see details
2.
3.
Actual Results:
see Details
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.