https://bugzilla.novell.com/show_bug.cgi?id=389386
User mmrazik(a)novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389386#c358865
Summary: vnc installation crashes
Product: openSUSE 11.0
Version: Beta 2
Platform: Other
OS/Version: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: YaST2
AssignedTo: sndirsch(a)novell.com
ReportedBy: mmrazik(a)novell.com
QAContact: jsrain(a)novell.com
Found By: ---
Created an attachment (id=214455)
--> (https://bugzilla.novell.com/attachment.cgi?id=214455)
y2logs
This might be a duplicate of bug #358865 but I'm observing this on a i386
machine (it is a x86_64 host with i386 installation).
VNC installation crashes right after connection of the VNC client. The VNC
client is asked for a password and right after the password is entered the
installation crashes with "An error occurred during the installation" message.
y2logs attached. Unfortunately I don't know how to debug this better so if you
need more logs please let me know. I think this one may be easy to reproduce.
Attached are 2 screenshots from the text console (from KVM). This host doesn't
have serial port thus I'm unable to attach the whole output.
--
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=370872
Summary: "pccardctl eject" hangs in state D
Product: openSUSE 11.0
Version: Alpha 2plus
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
AssignedTo: kernel-maintainers(a)forge.provo.novell.com
ReportedBy: seife(a)novell.com
QAContact: qa(a)suse.de
CC: fseidel(a)novell.com
Found By: Development
During suspend, one thing we do is eject PCMCIA card with "pccardctl eject".
I quite frequently see that command hanging in state D, which makes suspend
fail. Attempting to shut down the machine cleanly lead to a hang when the sound
modules are unloaded, a clean shutdown does only happen if i do a sysrq-e to
kill the hanging processes and make init proceed.
I have seen this with various 3G/UMTS CardBus cards, both USB-serial based and
nozomi based, so i believe this to be a generic PCMCIA issue.
Will attach sysrq-T
--
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=362947
Summary: evaluate debian/ubuntu libtool patch
Product: openSUSE 11.0
Version: Alpha 2
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: Development
AssignedTo: schwab(a)novell.com
ReportedBy: crrodriguez(a)novell.com
QAContact: qa(a)suse.de
Found By: Development
Both debian and Ubuntu are using a libtool patch{1} that sets
link_all_deplibs=no on ELF systems, this will help a lot reducing unedded
library dependencies in packages.
{1}
http://patches.ubuntu.com/by-release/extracted/debian/libt/libtool/1.5.26-1…
This is just a suggestion, I think this may work for us as well ( ubuntu and
debian archives are a biiiigg test ;) )
--
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=341350
Summary: severe limitations in xen-tools python scripts
Product: openSUSE 10.3
Version: Final
Platform: x86-64
OS/Version: openSUSE 10.3
Status: NEW
Severity: Major
Priority: P5 - None
Component: Xen
AssignedTo: cgriffin(a)novell.com
ReportedBy: duwe(a)novell.com
QAContact: qa(a)suse.de
Found By: Development
qemu-dm appears to be accepting the same type of arguments as qemu does;
however the automatically generated command line is impossible to contain
1st) multiple "-usbdevice" switches --
one is already used up by the "tablet" option.
2nd) a "-parallel" switch
This may not be serious for a server virtualisation, but it surely hurts on the
desktop.
--
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=343180
Summary: XEN keymap problem.
Product: openSUSE 10.3
Version: Final
Platform: i586
OS/Version: openSUSE 10.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Xen
AssignedTo: cgriffin(a)novell.com
ReportedBy: nice(a)titanic.nyme.hu
QAContact: qa(a)suse.de
Found By: Other
I installed Vindows Vista on Xen by vm-install ran from YaST with the following
settings (/etc/xen/vm/windowsvista):
###############################################
name="windowsvista"
ostype="windowsvista"
uuid="cf93a3e0-c33f-50c4-dd3f-b68691418a40"
memory=1024
vcpus=1
on_crash="destroy"
on_poweroff="destroy"
on_reboot="restart"
localtime=1
builder="hvm"
extid=0
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="c"
disk=[ 'file:/mnt/xen/vista.bin,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r', ]
vif=[ 'mac=00:16:3e:1a:4d:7d,model=rtl8139,type=ioemu', ]
stdvga=0
vnc=1
vncunused=1
apic=0
acpi=1
pae=1
usb=1
usbdevice='tablet'
serial="pty"
###############################################
I tried to manage this qemu-dm assisted fully virtualized host either via VNC
or SDL (changing the config file above), but I realized that the host's
keyboard map was incomplete and incorrect. Let's see a sort example from the
file /var/log/xen qemu-dm.29632.log:
###############################################
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 501
Warning: no scancode found for keysym 501
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
###############################################
I figured out that the problem could by corrected by make qemu-dm use some of
the keymaps under /usr/share/xen/qemu/keymaps by passing a -key CODE parameter
to it. Or am I wrong? I also figured out that I can make xend to pass this
parameter to qemu-dm by adding a keymap='CODE' line to the /etc/xen/vm/VM file.
So I added the line keymap='hu' to the vm config file, and qemu-vm's command
line really changed:
milleniumfalcon:/var/log/xen # cat /proc/8046/cmdline | sed y/'\x0'/' '/
/usr/lib/xen/bin/qemu-dm -d 2 -vcpus 1 -boot c -localtime -serial pty -acpi
-usb -usbdevice tablet -k hu -domain-name windowsvista -net
nic,vlan=1,macaddr=00:16:3e:1a:4d:7d,model=rtl8139 -net tap,vlan=1 -vncunused
-vnclisten 127.0.0.1 milleniumfalcon:/var/log/xen # cat /proc/8046/cmdline |
sed y/'\x0'/' '/
The keyboard got a bit better but there are still missing keys, "ű" for
example. I tried other keymaps with similar results. What may be wrong with
these keymaps? Are they defectivein a way? I have no idea.
Thist bug report is primarily about the possible errors int these keymap files,
but I have other related quetions too:
It wold be good to make it possible to change the keymap setting in vm-install
if it is necessary at all.
Furthermore I do not know where virt-manager gets the information about VMs
from. Once I moved every file from /etc/xen/vm to the root directory, restarted
virt-manager and in spite of the lack of VM description files it still
remebered my guest VM.
I also do not know, what keeps the files /etc/xen/vm/VM and /etc/xen/vm/VM.xml
in synchron.
So, if i add a keymap to the file /etc/xen/vm/VM then that VM will use that
keymap if I start if by the xm command. But what happens if i start that VM
from virt-manager? Do I also need to add the keymap to the file
/etc/xen/vm/VM.xml? Or to a third file?
--
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=285914
Summary: Sound hangs on CPU frequency change
Product: openSUSE 10.3
Version: Alpha 5
Platform: x86-64
OS/Version: openSUSE 10.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Sound
AssignedTo: tiwai(a)novell.com
ReportedBy: ray(a)openland.cz
QAContact: qa(a)suse.de
Found By: ---
First of all I must say, that I am using openSUSE 10.2, but I have selected
openSUSE 10.3 product, because I am using latest kernel from HEAD repository.
Hardware Environment: Asus A6Km
Software Environment: e.g. Amarok audio player
Problem Description:
I have Asus A6Km with AMD Turion 3200+. It has Realtek ALC650 integrated sound
card and is working fine.
Recently, I bought Creative Sound Blaster Live! 5.1 24-bit External for this
laptop, because I have already one connected to my desktop computer (openSUSE
10.2 x86) and works fine too.
However, when I connect Sound Blaster to my laptop, sound hangs randomly. I
spent lot of time finding the reason, because there was nothing in logs, dmesg
etc. Finally I found, that it is caused by CPU frequency scaling. When CPU
speed is changed, than sound hangs - to reboot help only disconnection of Sound
Blaster. When I fix CPU frequency, than Sound Blaster works like the other one
in my desktop computer - fine.
I found only two refs describing similar/same problem:
http://www.linuxforums.org/forum/linux-laptops/63126-sound-problems-cpu-ste…http://alsa.opensrc.org/Tascam_US-224
Steps to reproduce:
1) Connect Sound Blaster Live! 5.1 24-bit External
2) start some audio output with your favorite player
3) wait on frequency change
4) Sound hangs
5) For successful reboot, it is necessary to disconnect Sound Blaster
Hope, you can help me.
If you will need any other info, just ask me.
I also submit bug to Alsa bugzilla (ID: 0003097) month ago and kernel bugzilla
(ID: 8648), but there were no response. I am not sure whether this is sound
subsystem related issue or USB subsystem issue (my laptop has SIS chipset,
which is not so often used like others).
May be I am absolutely wrong putting this bug report to this bugzilla, so if
anyone from Novell staff decide, that this report is not related to this
bugzilla, but only to kernel/alsa bugzilla, feel free to close it.
--
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=385376
Summary: Package 'python' does not build correctly on PPC64
Product: openSUSE 10.2
Version: Final
Platform: PowerPC-64
OS/Version: Linux
Status: NEW
Severity: Major
Priority: P5 - None
Component: Development
AssignedTo: pth(a)novell.com
ReportedBy: sergiodj(a)linux.vnet.ibm.com
QAContact: qa(a)suse.de
Found By: ---
Hi,
I'm currently trying to build the last version of Python's src.rpm (namely
python-2.5-19.6.src.rpm) on a biarch machine (i.e., 64-bit kernel and mostly
32-bit userspace apps). The 32-bit build works properly:
#> rpmbuild --target ppc -bb SPECS/python.spec
<< OK >>
What happens is that, when I try to build it for PPC64, some errors occurs:
#> rpmbuild --target ppc64 -bb SPECS/python.spec
..
Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
Requires: python = 2.5 libc.so.6()(64bit) libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit) libpthread.so.0()(64bit)
libpython2.5.so.1.0()(64bit)
RPM build errors:
File not found:
/var/tmp/python-2.5-build/usr/lib64/python2.5/lib-dynload/_sqlite3.so
Note that Python got compiled successfuly, and all the tests were done without
errors. Only after that this error came up.
I'd like to know what can be done to fix this. Actually, what's happening is
that I don't have (and haven't found) the package sqlite3 for PPC64. I've also
tried to build it from its src.rpm, but fell in another dependency case and
gave up.
Obs.: I've made a tiny modification on Python's spec file in order to be able
to compile it for PPC64:
--- SPECS/python.spec 2008-01-10 09:59:23.000000000 -0800
+++ SPECS/python.spec.new 2008-04-30 11:11:49.000000000 -0700
@@ -217,6 +217,9 @@
# use rpm_opt_flags
########################################
export OPT="$RPM_OPT_FLAGS"
+%ifarch ppc64 ia64
+export CC="gcc -m64"
+%endif
########################################
# regenerate
########################################
--
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=381135
Summary: [multiscreen]: Print screen messed up
Product: openSUSE 11.0
Version: Factory
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: GNOME
AssignedTo: bnc-team-gnome(a)forge.provo.novell.com
ReportedBy: captain.magnus(a)opensuse.org
QAContact: qa(a)suse.de
Blocks: 374148
Found By: ---
Created an attachment (id=208796)
--> (https://bugzilla.novell.com/attachment.cgi?id=208796)
Screenshot
I have my internal LCD (1450x1050) on the right and an external CRT (1024x768)
on the left. I've added a panel to the left.
See attached screenshot for some cool wierdness.
Note; On the left, the panel IS on the bottom right. I can not see the icons on
the left that's revealed in the screenshot (they would show up if I go 'arrange
icons')
--
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=381030
Summary: [multiscreen] A few UI suggestions for gnome-display-
properties
Product: openSUSE 11.0
Version: Factory
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: GNOME
AssignedTo: bnc-team-gnome(a)forge.provo.novell.com
ReportedBy: vuntz(a)novell.com
QAContact: qa(a)suse.de
Blocks: 374148
Found By: ---
We have "Resolution", "Refresh Rate:" and "Rotation". They should all have
semi-colons.
"Detect Displays" is really too wide. It shouldn't be as wide as the window.
Title of the window contains "monitor". First option contains "screen". Last
button contains "displays". See where I'm heading? :-) Monitor is probably the
best term to use.
Not quite sure why "Mirror Screens" is at the top. Looks weird to me. I'd try
putting it just before the "Detect Displays" button.
--
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=368800
Summary: build status wrongly inaccuracy
Product: openSUSE.org
Version: unspecified
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: BuildService
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: poeml(a)novell.com
QAContact: adrian(a)novell.com
Found By: ---
The build status "succeeded" often doesn't reflect reality. A packager
frequently sees the following.
First, after a commit:
poeml@batavia510 ~/bs/openSUSE:Tools/osc
% osc results
CentOS_5 i586 scheduled
CentOS_5 x86_64 building
Debian_Etch i586 scheduled
Debian_Etch x86_64 scheduled
Fedora_7 i586 succeeded
Fedora_7 x86_64 scheduled
Fedora_8 i586 succeeded
Fedora_8 x86_64 succeeded
Fedora_Core_6 i586 succeeded
Fedora_Core_6 x86_64 succeeded
Mandriva_2006 i586 succeeded
Mandriva_2007 i586 succeeded
Mandriva_2007 x86_64 succeeded
Mandriva_2008 i586 succeeded
Mandriva_2008 x86_64 succeeded
openSUSE_10.2 i586 succeeded
openSUSE_10.2 x86_64 succeeded
openSUSE_10.3 i586 succeeded
openSUSE_10.3 x86_64 succeeded
openSUSE_Factory i586 succeeded
openSUSE_Factory x86_64 succeeded
RHEL_5 i586 succeeded
RHEL_5 x86_64 succeeded
SLES_9 i586 disabled
SLES_9 x86_64 disabled
SLE_10 i586 succeeded
SLE_10 x86_64 succeeded
SUSE_Linux_10.1 i586 succeeded
SUSE_Linux_10.1 x86_64 succeeded
xUbuntu_6.06 i586 succeeded
xUbuntu_7.04 i586 succeeded
xUbuntu_7.10 i586 succeeded
xUbuntu_7.10 x86_64 succeeded
Fine -- I just don't believe it's succeeded already, because I committed
only a minute ago. But I know what to think.
Later, things get confusing:
poeml@batavia510 ~/bs/openSUSE:Tools/osc
% osc results
CentOS_5 i586 finished
CentOS_5 x86_64 building
Debian_Etch i586 succeeded
Debian_Etch x86_64 succeeded
Fedora_7 i586 succeeded
Fedora_7 x86_64 succeeded
Fedora_8 i586 succeeded
Fedora_8 x86_64 succeeded
Fedora_Core_6 i586 finished
Fedora_Core_6 x86_64 succeeded
Mandriva_2006 i586 succeeded
Mandriva_2007 i586 finished
Mandriva_2007 x86_64 succeeded
Mandriva_2008 i586 succeeded
Mandriva_2008 x86_64 building
openSUSE_10.2 i586 building
openSUSE_10.2 x86_64 succeeded
openSUSE_10.3 i586 finished
openSUSE_10.3 x86_64 succeeded
openSUSE_Factory i586 finished
openSUSE_Factory x86_64 succeeded
RHEL_5 i586 building
RHEL_5 x86_64 succeeded
SLES_9 i586 disabled
SLES_9 x86_64 disabled
SLE_10 i586 succeeded
SLE_10 x86_64 succeeded
SUSE_Linux_10.1 i586 succeeded
SUSE_Linux_10.1 x86_64 succeeded
xUbuntu_6.06 i586 succeeded
xUbuntu_7.04 i586 succeeded
xUbuntu_7.10 i586 finished
xUbuntu_7.10 x86_64 succeeded
Can you tell which of them are already succeeded, and which ones are
still "succeeded"?
It would be better if the commit would invalidate the "succeeded" state.
The "succeeded should only be reached again once the package has
actually been built (successfully of course).
--
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.