June 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 865018] New: The manual page if current insserv is to short
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=865018 https://bugzilla.novell.com/show_bug.cgi?id=865018#c0 Summary: The manual page if current insserv is to short Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: All OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: lnussel(a)suse.com ReportedBy: werner(a)suse.com QAContact: qa-bugs(a)suse.de CC: lnussel(a)suse.com, mt(a)suse.com, nfbrown(a)suse.com, krienke(a)uni-koblenz.de, arvidjaar(a)gmail.com, jzhang(a)suse.com Depends on: 861489 Found By: Development Blocker: --- In fact the lines SYNOPSIS insserv [[-r] <script>] OPTIONS --remove, -r Remove the listed scripts from all runlevels DESCRIPTION This version of insserv is just a stub for compatibility. does not explain anything about ### BEGIN INIT INFO # Provides: boot_facility_1 [ boot_facility_2 ...] # Required-Start: boot_facility_1 [ boot_facility_2 ...] # Required-Stop: boot_facility_1 [ boot_facility_2 ...] # Should-Start: boot_facility_1 [ boot_facility_2 ...] # Should-Stop: boot_facility_1 [ boot_facility_2 ...] # X-Start-Before: boot_facility_1 [ boot_facility_2 ...] # X-Stop-After: boot_facility_1 [ boot_facility_2 ...] # Default-Start: run_level_1 [ run_level_2 ...] # Default-Stop: run_level_1 [ run_level_2 ...] # X-Interactive: true # Short-Description: single_line_description # Description: multiline_description ### END INIT INFO Tbhis bug is also relevant for SLES12 -- 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.

1 4

[Bug 880595] New: gcc segfaults at SLES12 beta4 P8
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=880595 https://bugzilla.novell.com/show_bug.cgi?id=880595#c0 Summary: gcc segfaults at SLES12 beta4 P8 Classification: openSUSE Product: openSUSE 13.1 Version: RC 1 Platform: LittleEndian OS/Version: SLES 12 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: wangn(a)ca.ibm.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 we are testing sles12 beta4, g++ ICE(segfaults) on sles12 P8 but pass on non-sles12 P8 machine. Reproducible: Always Steps to Reproduce: 1. machine: Linux cit323 3.12.15-3-default #1 SMP Wed Apr 2 17:08:55 UTC 2014 (69c2ea8) ppc64le ppc64le ppc64le GNU/Linux 2. source code: t.cpp: class A { static int aval; public: int get_val(); }; class B : public A { static int bval; public: int get_val(); int bf(); }; int B::bval=5; int B::get_val() {return bval;}; int B::bf() {return 3;}; int funcB() { B b; return b.get_val(); } 3. command: gcc -m64 -c t.cpp Actual Results: gcc: internal compiler error: Segmentation fault (program cc1plus) Segmentation fault Expected Results: compile pass no problem on the following machine: Linux cit318 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:09:21 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux -- 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.

1 2

[Bug 707967] New: [Update WindowMaker] Wrong placement of menus on Xinerama displays...
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=707967 https://bugzilla.novell.com/show_bug.cgi?id=707967#c0 Summary: [Update WindowMaker] Wrong placement of menus on Xinerama displays... Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: X11 Applications AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: ma(a)novell.com QAContact: qa(a)suse.de Found By: Development Blocker: --- Using the WindowMaker-0.92.0 package shipped with 11.4, several applications show weird behavior e.g. when displaying menus (context as well as pull down). Menus either do not show up art all, or they are placed at the top of the screen instead of inside the applications window. Most of them also using the wrong orientation and are just partially visible. The behavior sometimes even differs depending on which screen of the Xinerama display the window is shown. Looking for a fix I found: http://repo.or.cz/w/wmaker-crm.git A fork based on the last known CVS version of Window Maker. The repo contains a version WindowMaker-0.94.0.crm, which fixes the above problems. At https://gitorious.org/mlandres/wmaker-crm-obs/commits/obs I took a snapshot of the above repo (v. 0.94.0.crm) and applied all the patches from obs://X11:windowmanagers/WindowMaker(0.92.0). Most of them are meanwhile superfluous as they are already present. You'll find just 3 commits for the WindowMaker-de_translation.patch, WindowMaker-config.dif and WindowMaker-menu.patch left. The resulting package is built at obs:/home:mlandres:Wmaker-crm and by mow running flawlessly on my workstation. Please consider updating to WindowMaker-crm -- 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.

1 2

[Bug 743697] New: if updating OBS from 2.1 (11.3 based) to 2.2.116 (12.1 based) mysql update fails
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=743697 https://bugzilla.novell.com/show_bug.cgi?id=743697#c0 Summary: if updating OBS from 2.1 (11.3 based) to 2.2.116 (12.1 based) mysql update fails Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: SuSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: kkeil(a)linux-pingi.de QAContact: qa(a)suse.de Found By: --- Blocker: --- Created an attachment (id=472946) --> (http://bugzilla.novell.com/attachment.cgi?id=472946) log files User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20100101 Firefox/9.0 I tried a update ofthe openbuildserver from a 2.1 version to a 2.2.116 version. The 2.1 appliance was running on 11.3, 2.2.116 is a appliance based on 12.1. When starting the mysql database the first time, it try to upgrade the database and fails, the data base is corrupted after this. Reproducible: Always Steps to Reproduce: 1. Run a OBS appliance from opensuse:Tools:2.1., with a extra LVM volume for OBS/server (so database is not in the root filesystem). 2.Try the latest applicance image from opensuse:Tools:unstable (obs-server.x86_64-2.2.116-Build1.2.raw.bz2). 3.The upgrade of the database will fail. Actual Results: see attached log files Expected Results: update of the database is successful. -- 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.

1 6

[Bug 881022] New: Net install over wlan difficult with non-english keyboard, keyboard should be selectable
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=881022 https://bugzilla.novell.com/show_bug.cgi?id=881022#c0 Summary: Net install over wlan difficult with non-english keyboard, keyboard should be selectable Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: yast2-maintainers(a)suse.de ReportedBy: u.michel(a)t-online.de QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 After starting installation from network with openSUSE-Factory-NET-Build0117-x86_64.iso network name and password have to be entered over the keyboard. If the keyboard is a non-english one, it is difficult to enter a password, if it contains special characters. A keyboard selection should be offered before this step. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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.

1 1

[Bug 879726] New: Seeking bug in smplayer from KDE:Extra
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=879726 https://bugzilla.novell.com/show_bug.cgi?id=879726#c0 Summary: Seeking bug in smplayer from KDE:Extra Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Applications AssignedTo: kde-maintainers(a)suse.de ReportedBy: aloisio(a)gmx.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 When using the mousewheel to seek through the file, the stepping is always 1 second, regardless of what it has been set. The problem appears to be upstream, since it occurs even in a build of vanilla 14.3.0. It disappeared in trunk, not sure at what commit. Reproducible: Always Steps to Reproduce: 1. Install smplayer 2. Set the mousewheel function for media seeking 3. Wheel back and forth during play Actual Results: Position is changed only by 1 second at each step. Expected Results: It should have moved by the time set in Preferences/Interface/Seeking/Mousewheel jump. -- 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.

1 6

[Bug 880757] New: After flipping over from a static IP to DHCP in NetworkManager, a "phantom" network appears in the routing table
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=880757 https://bugzilla.novell.com/show_bug.cgi?id=880757#c0 Summary: After flipping over from a static IP to DHCP in NetworkManager, a "phantom" network appears in the routing table Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: novell(a)nixwizard.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 I noticed that when I switch NetworkManager from a static IP I configred over to DHCP, the original route for the static IP configured gets added to the routing table along with the DHCP leased route. This occasionally breaks thing in mysterious ways, especially if the static route that NetworkManager installs happens to correspond to a static route previously entered that no longer is configured in NetworkManager. Reproducible: Always Steps to Reproduce: 1. Set a static IP. In my case I set a static IP of 1.1.1.1/32 just to reproduce the bug 2. Set NetworkManager back to DHCP 3. Let NetworkManager successfully get an IP address 4. Run 'route -n' and observe the old network from a previous static IP config, along with the successful DHCP IP Actual Results: A DHCP IP address is successfully leased, but mysteriously a network that corresponds to the previous static IP that was set is also added to the routing table. Expected Results: NetworkManager should have received a DHCP IP address and not added the "extraneous" route from the old static network I had configured previously Here's my 'route -n' every step of the way: ---- Static IP 1.1.1.2/32, default GW of 1.1.1.1 configured ---- laptop:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 1.1.1.1 0.0.0.0 UG 0 0 0 eth0 1.1.1.0 0.0.0.0 255.255.255.252 U 1 0 0 eth0 ---- DHCP configured, waiting for an IP address offer from DHCP server ---- laptop:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ---- DHCP IP address lease received from DHCP server, "phantom" 1.1.1.0/32 added too mysteriously ---- laptop:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.7.98.1 0.0.0.0 UG 0 0 0 eth0 1.1.1.0 0.0.0.0 255.255.255.252 U 1 0 0 eth0 10.7.98.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0 -- 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.

1 1

[Bug 880858] New: bcache symbolic links in /dev/bcache/by-uuid are unstable
by bugzilla_noreply＠novell.com 03 Jun '14

03 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=880858 https://bugzilla.novell.com/show_bug.cgi?id=880858#c0 Summary: bcache symbolic links in /dev/bcache/by-uuid are unstable Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: seroton10(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 Using a standard and fully updated openSUSE 13.1 running in a KVM, I demonstrate that the symbolic links to bcache devices under in /dev/bcache/by-uuid are unstable. Exactly the same bug when running outside of a VM. Reproducible: Always Steps to Reproduce: 1. A zeroed-out block device /dev/vdb is added to the KVM, and some partitions are created for testing: Disk /dev/vdb: 1073 MB, 1073741824 bytes, 2097152 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x4df97356 Device Boot Start End Blocks Id System /dev/vdb1 2048 1026047 512000 83 Linux /dev/vdb2 1026048 1230847 102400 83 Linux 2. bcache backing and cache devices are set up: vbase:~ # make-bcache -B /dev/vdb1 -C /dev/vdb2 UUID: db49ed8a-522a-4823-9ac6-24964450e556 Set UUID: 40c17628-f9d9-4ebf-9eea-b1196e5f206c version: 0 nbuckets: 500 block_size: 1 bucket_size: 1024 nr_in_set: 1 nr_this_dev: 0 first_bucket: 1 UUID: 9c38f1ae-d2d4-47e3-8764-304624aae65f Set UUID: 40c17628-f9d9-4ebf-9eea-b1196e5f206c version: 1 block_size: 1 data_offset: 16 vbase:~ # ls -l /dev/bcache/by-uuid/ total 0 lrwxrwxrwx 1 root root 13 May 31 23:12 9c38f1ae-d2d4-47e3-8764-304624aae65f -> ../../bcache0 vbase:~ # lsblk /dev/vdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vdb 253:16 0 1G 0 disk ├─vdb1 253:17 0 500M 0 part │ └─bcache0 251:0 0 500M 0 disk └─vdb2 253:18 0 250M 0 part └─bcache0 251:0 0 500M 0 disk 3. A file system is initialized on the cached device: vbase:~ # mkfs.ext4 /dev/bcache0 mke2fs 1.42.8 (20-Jun-2013) Discarding device blocks: done Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 128016 inodes, 511992 blocks 25599 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 63 block groups 8192 blocks per group, 8192 fragments per group 2032 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done vbase:~ # ls -l /dev/bcache/by-uuid/ ls: cannot access /dev/bcache/by-uuid/: No such file or directory 4. After a reboot we have: vbase:~ # lsblk /dev/vdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vdb 253:16 0 1G 0 disk ├─vdb1 253:17 0 500M 0 part │ └─bcache0 251:0 0 500M 0 disk └─vdb2 253:18 0 250M 0 part └─bcache0 251:0 0 500M 0 disk vbase:~ # ls -l /dev/bcache/by-uuid/ total 0 lrwxrwxrwx 1 root root 13 May 31 23:18 9c38f1ae-d2d4-47e3-8764-304624aae65f -> ../../bcache0 5. Define a mount point for the cached device based on the symlink: vbase:~ # echo "/dev/bcache/by-uuid/9c38f1ae-d2d4-47e3-8764-304624aae65f /mnt ext4 defaults 1 2" >>/etc/fstab vbase:~ # mount /mnt vbase:~ # lsblk /dev/vdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vdb 253:16 0 1G 0 disk ├─vdb1 253:17 0 500M 0 part │ └─bcache0 251:0 0 500M 0 disk /mnt └─vdb2 253:18 0 250M 0 part └─bcache0 251:0 0 500M 0 disk /mnt vbase:~ # ls -l /dev/bcache/by-uuid/ total 0 lrwxrwxrwx 1 root root 13 May 31 23:18 9c38f1ae-d2d4-47e3-8764-304624aae65f -> ../../bcache0 6. After a reboot we find the cached device mounted, but no symlink: vbase:~ # lsblk /dev/vdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vdb 253:16 0 1G 0 disk ├─vdb1 253:17 0 500M 0 part │ └─bcache0 251:0 0 500M 0 disk /mnt └─vdb2 253:18 0 250M 0 part └─bcache0 251:0 0 500M 0 disk /mnt vbase:~ # ls -l /dev/bcache/by-uuid/ ls: cannot access /dev/bcache/by-uuid/: No such file or directory Actual Results: In step 3, the directory with the symbolic links to the cache device disappears after initializing a file system on it. After a reboot in step 4 it comes back. In step 5, mounting the cached device via an fstab entry based on the symbolic link works, and the symbolic link remains, as expected. However, after a reboot in step 6, even though the mount point works, the symbolic link is no longer present. Expected Results: Once /dev/bcache0 has been created (in step 2), the /dev/bcache/by-uuid/ directory should always provide a symbolic link to it in all use cases above. This bug becomes a real problem if more than one bcache device is in use, because the symlinks in /dev/bcache/by-uuid/ can't be relied upon. -- 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.

1 1

[Bug 881018] New: One an NFS Client Relationship has been Created at Boot If its NFS Server is Shut-Down ALL Network Traffic Will Cease on NFS Client PC
by bugzilla_noreply＠novell.com 02 Jun '14

02 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=881018 https://bugzilla.novell.com/show_bug.cgi?id=881018#c0 Summary: One an NFS Client Relationship has been Created at Boot If its NFS Server is Shut-Down ALL Network Traffic Will Cease on NFS Client PC Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: secure(a)aphofis.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 I have been reluctant to report this bug as being 100% reproducible as I have tried to dismiss this bug but I can reproduce it time after time after time! When Mounting of an NFS Client to its NFS Server at time of boot, if its Server is shut-down ALL Network Traffic on the NFS Client will cease up until its NFS Server comes back online. I feel this is due to the weird association of susefirewall 2, stage 2 in part. See open Bug #856916 about to be tested with latest version of Kernel based NFS Client and Server! Please more accurately Assign correct clasification I so want to be wrong about this situation but its 100% reproducible each and every time even if I test the same on different PC's Please advise what log information or files you need for this by reply NEEDINFO Reproducible: Always Steps to Reproduce: 1.Create NFS Client and Server Relationship 2.Boot both PC's - test for Internet traffic 3.Shut down NFS Server PC 4.Now the NFS client PC will have No internet access what so ever until its relational server is restored Actual Results: The NFS Client in the above relationship halts all Network Traffic when its NFS Server PC is shut-down. Please see open BUG #856916 which cast's its own issues with both kernel Based NFS and unreasonable delay in loading susefirewall 2 stage 2...About to test with susefirewall 2 not running however, I want to preserve status for log info I can get for you before I disengage susefirewall on each and then both PC's. I can reproduce this on other PC's on my network and the same result! -- 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.

1 1

[Bug 860633] New: Strange PolicyKit1-Kde dialog asks for root password to change the "Folder Watch Limit"(?)
by bugzilla_noreply＠novell.com 02 Jun '14

02 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=860633 https://bugzilla.novell.com/show_bug.cgi?id=860633#c0 Summary: Strange PolicyKit1-Kde dialog asks for root password to change the "Folder Watch Limit"(?) Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: carthexis(a)yahoo.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=576002) --> (http://bugzilla.novell.com/attachment.cgi?id=576002) Screenshot of the insane dialog User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Some time after KDE startup I get the following annoying dialog: PolicyKit1-KDE An application is attempting to perform an action that requires root privilges. Authentication is required to perform this action Password for root: [ ] [X] Remember authorization [ ] For this session only Application: Action: Folder Watch Limit polkit.subject_pid: 2545 polkit.caller-pid: 3137 The programs in question seem to be: $> ps ax | grep '2545\|3137' 2545 ? SNl 0:12 /usr/bin/nepomukfilewatch 3137 ? Sl 0:00 /usr/lib64/kde4/libexec/kde_nepomuk_filewatch_raiselimit Why is something KDE/desktop related asking for my root password? What could _possibly_ justify such an insanity? Regards, Lorenz PS: I have openSUSE 13.1 with Tumbleweed, which is apparently not something one can directly specify in this bugtracker(?) Reproducible: Always -- 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.

1 2