http://bugzilla.opensuse.org/show_bug.cgi?id=907495
Bug ID: 907495
Summary: adding a manual route to a dhcp configured interface
results in failed dhcp setup (wicked managed)
Classification: openSUSE
Product: openSUSE 12.3
Version: Final
Hardware: Other
OS: openSUSE 13.2
Status: NEW
Severity: Major
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: hpj(a)urpla.net
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When adding a manual route to a dhcp configured eth interface managed by
wicked, the dhcp setup fails with a silly message:
device enp7s0 failed: "call to
org.opensuse.Network.Addrconf.ipv4.static.requestLease failed: General failure"
Add a manual route to a dhcp configured interface and restart your system.
Be prepared, that this interface will not come up correctly.
BTW: the routing editor allows selecting configured interfaces only. The usual
order is: setup interface, add route, but you have to confirm the interface
setup first, reenter yast network and add the interface based route there
after.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=899330
Bug ID: 899330
Summary: Interfaces does not automatically show up in firewall
with NetworkManager
Classification: openSUSE
Product: openSUSE Factory
Version: 201408*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: razirazo_90(a)live.com.my
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When using NetworkManager, network interfaces does not listed in firewall.
I have to manually configure it using Wicked Service first, to make it
registered in firewall. And then use networkManager back.
This is troublesome, for example when setting up internet sharing you can't
proceed to zone assign and Network masquerade until you do the step above.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=918705
Bug ID: 918705
Summary: alpine locking failure (against procmail) leads to
mail corruption
Classification: openSUSE
Product: openSUSE Factory
Version: 201502*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: gp(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
This is something I started to see a bit ago, and since it now happened
twice today I figured I'd report it.
When I obtain mail via fetchmail, using procmail as the delivery agent,
occasionally I get corrupted mails like the following (in mbox format):
==== snip ====
>From gp Thu Feb 19 18:56:54 2015
Mime-Version: 1.0
Date: Thu, 19 Feb 2015 18:56:00 +0100
Subject: AW: Re: Your help needed: Fwd: Comment opportunity: Software
Status: RO
X-Status:
X-Keywords:
X-UID: 9310
definedstorage
Subject: AW: Re: Your help needed: Fwd: Comment opportunity: Software
definedstorage
References: <54E302D90200006F00158C8B(a)suse.com>
<54E2D72A0200002B000A1B55(a)suse.com>
<54E339FA0200006F00158DBD(a)suse.com>
<54E2D7DE0200002B000A1B68(a)suse.com>
<alpine.LSU.2.11.1502191739290.2252(a)ghan.fvgr>
In-Reply-To: <alpine.LSU.2.11.1502191739290.2252(a)ghan.fvgr>
Message-ID: <54E623B70200006F001594A6(a)suse.com>
From: ...
To: "Gerald Pfeifer" <gp(a)suse.com>
==== snap ====
This does not happen daily, and I believe it happens especially when
I have been offline for several hours and a few dozen e-mails are
delivered at once (though this specific case was not that).
The same configuration had been working for years without ever showing
this problem, and it looks like looking on the Alpine side (or procmail,
though less likely I guess, since it essentially only reads
:0
INBOX
)
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906594
Bug ID: 906594
Summary: Apper showing wrong package description
Classification: openSUSE
Product: openSUSE Factory
Version: NO 13.2 BUGS!!
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: KDE4 Applications
Assignee: kde-maintainers(a)suse.de
Reporter: erwin.vandevelde(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Apper shows the package's description when clicking on it, but only for the
first package you click on this is done correctly.
Apper shows the same description again and again for each other package you
click on.
Versions:
apper 0.9.1-2.1
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=917759
Bug ID: 917759
Summary: osc fails with a python exception
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Hardware: Other
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: BuildService
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: lmb(a)suse.com
QA Contact: adrian(a)suse.com
Found By: ---
Blocker: ---
This is about the latest osc client on Factory (osc-0.150.1-158.1.noarch) used
on the internal build service instance:
# iosc rdiff Devel:Storage:1.0 _product SUSE:SLE-12:Update:Products:Cloud5
Traceback (most recent call last):
File "/usr/bin/osc", line 26, in <module>
r = babysitter.run(osccli)
File "/usr/lib/python2.7/site-packages/osc/babysitter.py", line 61, in run
return prg.main(argv)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 343, in main
return self.cmd(args)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 366, in cmd
retval = self.onecmd(argv)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 500, in onecmd
return self._dispatch_cmd(handler, argv)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 1230, in
_dispatch_cmd
return handler(argv[0], opts, *args)
File "/usr/lib/python2.7/site-packages/osc/commandline.py", line 3593, in
do_rdiff
expand=not opts.unexpand)
File "/usr/lib/python2.7/site-packages/osc/core.py", line 4488, in
server_diff_noex
unified, missingok, meta, expand)
File "/usr/lib/python2.7/site-packages/osc/core.py", line 4477, in
server_diff
f = http_POST(u)
File "/usr/lib/python2.7/site-packages/osc/core.py", line 3201, in http_POST
def http_POST(*args, **kwargs): return http_request('POST', *args,
**kwargs)
File "/usr/lib/python2.7/site-packages/osc/core.py", line 3144, in
http_request
install_opener(conf._build_opener(url))
File "/usr/lib/python2.7/site-packages/osc/conf.py", line 507, in
_build_opener
from . import oscssl
File "/usr/lib/python2.7/site-packages/osc/oscssl.py", line 8, in <module>
import M2Crypto.httpslib
File "/usr/lib64/python2.7/site-packages/M2Crypto/__init__.py", line 24, in
<module>
import ASN1
File "/usr/lib64/python2.7/site-packages/M2Crypto/ASN1.py", line 12, in
<module>
import BIO
File "/usr/lib64/python2.7/site-packages/M2Crypto/BIO.py", line 221, in
<module>
class CipherStream(BIO):
File "/usr/lib64/python2.7/site-packages/M2Crypto/BIO.py", line 227, in
CipherStream
SALT_LEN = m2.PKCS5_SALT_LEN
AttributeError: 'module' object has no attribute 'PKCS5_SALT_LEN'
Most invocations fail like that for me, including "osc up", submitreq, etc,
making it completely unusable for me.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902583
Bug ID: 902583
Summary: Thunderbird fails to connect when launched before
Internet connection is up
Classification: openSUSE
Product: openSUSE Distribution
Version: 13.2 RC 1
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Firefox
Assignee: bnc-team-mozilla(a)forge.provo.novell.com
Reporter: sb56637(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Hi,
I have noticed that if I launch Thunderbird before my network connection is up
(NetworkManager WiFI connection), it will fail to connect even after the
network comes up. The only way to make it connect is by closing all instances
and restarting Thunderbird.
This appears to be related to Bug 90258.
Thanks for looking into this!
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=909111
Bug ID: 909111
Summary: The rescan-scsi-bus.sh from the sgutils package is
broken since SuSE-13.1
Classification: openSUSE
Product: openSUSE Distribution
Version: 13.2
Hardware: x86-64
OS: openSUSE 13.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: dmarkh(a)cfl.rr.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101
Firefox/33.0
Build Identifier:
This script no longer "finds new" or "removes no longer attached" scsi devices.
As shown below, I have a scsi disk at scsi ID-0 at /dev/sg5.
# lsscsi -g
[0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0
[13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1
[16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5
[17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2
[18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3
[18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4
I remove the drive at scsi ID-0 drive and install an additional drive at scsi
ID-1 then run the script.
# rescan-scsi-bus.sh
Scanning SCSI subsystem for new devices
Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 0 0 0 0 ...
OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3320620AS Rev: K
Type: Direct-Access ANSI SCSI revision: 05
Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 5 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 7 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 8 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 9 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 10 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 11 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 12 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 13 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 13 0 0 0 ...
OLD: Host: scsi13 Channel: 00 Id: 00 Lun: 00
Vendor: Marvell Model: 91xx Config Rev: 1.01
Type: Processor ANSI SCSI revision: 05
Scanning host 14 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 15 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning host 16 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 16 0 0 0 ...
OLD: Host: scsi16 Channel: 00 Id: 00 Lun: 00
Vendor: IMPRIMIS Model: 94601-15 Rev: 4614
Type: Direct-Access ANSI SCSI revision: 01
Scanning host 17 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 17 0 0 0 ...
OLD: Host: scsi17 Channel: 00 Id: 00 Lun: 00
Vendor: LITE-ON Model: DVDRW LH-20A1P Rev: KL0G
Type: CD-ROM ANSI SCSI revision: 05
Scanning host 18 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
Scanning for device 18 0 0 0 ...
OLD: Host: scsi18 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3160811AS Rev: E
Type: Direct-Access ANSI SCSI revision: 05
Scanning for device 18 0 1 0 ...
OLD: Host: scsi18 Channel: 00 Id: 01 Lun: 00
Vendor: ATA Model: ST3160815AS Rev: B
Type: Direct-Access ANSI SCSI revision: 05
0 new or changed device(s) found.
0 remapped or resized device(s) found.
0 device(s) removed.
# lsscsi -g
[0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0
[13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1
[16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5
[17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2
[18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3
[18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4
It not only did not remove the one at ID-0 that was removed, but did not find
the new one attached. Below is an "lsscsi -g" after a reboot with BOTH drives
attached.
#lsscsi -g
[0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0
[13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1
[16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5
[16:0:1:0] disk IMPRIMIS 94601-15 4614 /dev/sde /dev/sg6
[17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2
[18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3
[18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4
Reproducible: Always
Steps to Reproduce:
1. See details
2.
3.
Actual Results:
This script, before SuSE-13.1 would remove any disks physically removed and add
any physically added since boot. It is broken
This is NOT kernel related as the same thing happens with a vanilla 3.16.7
kernel. I'm fairly certain this is a systemd issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=899501
Bug ID: 899501
Summary: Only one display wakes up after powersave
Classification: openSUSE
Product: openSUSE Factory
Version: 201409*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: X.Org
Assignee: bnc-team-xorg-bugs(a)forge.provo.novell.com
Reporter: lmb(a)suse.com
QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com
Found By: ---
Blocker: ---
Created attachment 608781
--> http://bugzilla.suse.com/attachment.cgi?id=608781&action=edit
Xorg.0.log
I have a Lenovo Thinkpad T440s with Intel graphics. I'm using a dual monitor
setup - the internal 1920x1080 display on eDP1 and a 1920x1200 screen (HP ZR24w
on DP4 via the docking station).
(Running Factory as of now, but tried 13.2b1 yesterday and had the same
effect.)
Leaving the system alone for a bit leads to the screens being turned off
(powersave). However, only the internal display wakes up again; the external
output remains in power-save mode.
(e.g., the monitor doesn't find any signal on any port.)
I tried using xrandr --output --off and turning it on with --auto again,
turning off the monitor itself, etc. No change; the only apparent way to
resolve this and get my external monitor back is to reboot, which seems a bit
harsh.
Any suggestions?
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated
Graphics Controller (rev 0b)
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x
175mm
1920x1080 60.01*+
1400x1050 59.98
1280x1024 60.02
1280x960 60.00
1024x768 60.00
800x600 60.32 56.25
640x480 59.94
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
DP4 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x
352mm
1920x1200 59.95*+
1920x1080 59.99
1600x1200 60.00
1680x1050 59.95
1280x1024 60.02
1440x900 59.89
1280x960 60.00
1024x768 60.00
800x600 60.32
640x480 60.00
DP5 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Pl
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=901887
Bug ID: 901887
Summary: Lenovo t440s / Intel 4400: External display
non-functional
Classification: openSUSE
Product: openSUSE Factory
Version: 201410*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: X.Org
Assignee: bnc-team-xorg-bugs(a)forge.provo.novell.com
Reporter: lmb(a)suse.com
QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com
Found By: ---
Blocker: ---
Created attachment 610633
--> http://bugzilla.suse.com/attachment.cgi?id=610633&action=edit
Xorg.0.log
On the same system where I experienced bug 899501, I've updated the system to a
later Factory build and can now no longer activate my external display at all.
Though xrandr reports:
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x
175mm
1920x1080 60.01*+
1400x1050 59.98
1280x1024 60.02
1280x960 60.00
1024x768 60.00
800x600 60.32 56.25
640x480 59.94
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
DP4 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x
352mm
1920x1200 59.95*+
1920x1080 59.99
1600x1200 60.00
1680x1050 59.95
1280x1024 60.02
1440x900 59.89
1280x960 60.00
1024x768 60.00
800x600 60.32
640x480 60.00
DP5 disconnected (normal left inverted right x axis y axis)
The output on DP4 is black, and the monitor does not detect a signal.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=903189
Bug ID: 903189
Summary: USB trackball not detected on reboot
Classification: openSUSE
Product: openSUSE Factory
Version: 201410*
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-maintainers(a)forge.provo.novell.com
Reporter: lmb(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 611775
--> http://bugzilla.suse.com/attachment.cgi?id=611775&action=edit
lsusb -v directly after reboot
After a reboot, the kernel doesn't detect the USB attached trackball
automatically. I have to unplug and plug it in again.
I'm attaching lsusb output directly after a reboot and after the unplug/plug
step (to the same USB port). Note that it is attached to a port on the docking
station.
--
You are receiving this mail because:
You are on the CC list for the bug.