body:
According to the changelog /etc/init.d/atd was removed while fixing bnc#849720.
This breaks /usr/sbin/rcatd however as it seems to rely on the presence of
the above file.

Reproducible: Always

Steps to Reproduce:
1. rcatd status
2.
3.
Actual Results:
rcatd: no such service atd

Expected Results:
atd.service - Execution Queue Daemon
   Loaded: loaded (/usr/lib/systemd/system/atd.service; disabled)
   Active: inactive (dead)
..

Restoring /etc/init.d/atd from at-3.1.13-5.1.2.i586.rpm makes rcatd work again.

summary: rcatd no longer works with update at-3.1.13-5.4.1.i586.rpm


body:
python 2.7.5 should be updated, and i dont think it will break the system, the
update contains lot of bug fixes.
http://hg.python.org/cpython/raw-file/99d03261c1ba/Misc/NEWS

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: Updating from 2.7.5 to 2.7.6


body:
myspell-polish is over 5 years outdated.

Reproducible: Always

Steps to Reproduce:
  1. Tell Mozilla Firefox to visit <URL: http://sjp.pl/geszefciara >.
  2. Enter "geszefciara" in LibreOffice Writer as Polish text.
3.
Actual Results:=20=20
  1. geszefciara=20
  2. geszefciarza? geszefciarz? =E2=80=A6

Expected Results:=20=20
  2. geszefciara

Upstream publishes a new version everyday so the publication date published
does not tell much whether it has changed or not.  However, 5 years=E2=80=
=99 lag is
excessive.

--=20
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=3Demail
-----

summary: please update myspell-polish


body:
With ifup each interface is started as separate service. These services do not
have any ordering dependencies which means that on shutdown they are stopped as
soon as possible. If NFS mounts are present, system will hang on shutdown for
prolonged time (it will eventually reboot, not sure whether this is done by
kernel or systemd).

The following is suggested fix. All network mounts automatically get dependency
on network-online.target. So let's order network-at-if.service before
network-online.target on startup, which ensures remote filesystems are
unmounted before interfaces are stopped:

[Unit]
..
Before=network-online.target
Wants=network-online.target

Wants here is required for manual NFS mounts, otherwise network-online.target
is not started at all.

I have tested it successfully, including busy mount points. If we are OK with
this approach, SR will follow.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: systemd: if NFS mounts are present, system hangs on shutdown when using ifup due to interfaces stopped too early


body:
Installing the latest release of octave from the science - repository, the
access to the info - files does not work any more (bug is known upstream)
Attached please find a fixing patch and a patch against my local spec-file.
The problem is caused by the fact that openSUSE distributes gzipped info -
files, see https://savannah.gnu.org/bugs/index.php?41054

Thank you for looking into this,
take care

Dieter Jurzitza

Reproducible: Always

Steps to Reproduce:
1. see above
2.
3.
Actual Results:
see above

Expected Results:
see above

This patch fixes the problems with the access to the info files on openSUSE
(whatever distribution in use)

summary: octave 3.8.0 : info files cannot be found


body:
13.1 fails to provide a 32bit compatibility package for libclang which is used
by Google's android development tool. I manually unpacked:

libclang-3.3-6.4.1.i586.rpm

and stuck the contents in /usr/lib, but that is a bit of a kludge which messes
up my use of my 13.1 rpm database a bit, and requires me to do the same thing
to every computer I install Google's adt-bundle-linux-x86_64-20131030 on.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: The is no 32bit compatibility package for libclang


body:
Hi,

I have updated my System to the new OpenSuse 13.1 - but now the=C2=A0
"autocomplete" mode on a tramp-ssh connection failed - which worked=C2=A0
before.

I could open a file if I know the hole path:
C-x C-f /[ssh/server]path/to/file.name

But if I use the <TAB>-key to list the directory content for example
C-x C-f /[ssh/server]path/to/<TAB>

I get the following error:
---------------

summary: xemacs tramp ssh completion returns "Wrong type argument: symbolp, ..."


body:
When installing office 2010 with wine without the samba-winbind package, the
following error occurs:

>....
>err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is
>outdated. Make sure that ntlm_auth >= 3.0.25 is in your
>path. Usually, you can find it in the winbind package of your
>distribution
>....
>....
>fixme:rpc:handle_bind_error unexpected status value 1765
>err:rpc:RpcAssoc_BindConnection rejected bind for reason 0

The samba-winbind package provides the ntlm_auth file needed.

For me, this solved the error and Office 2010 installed without any .dll
overrides.

Therefore i would find it usefull if the samba-winbind package is includes in
the dependencies of wine.

Reproducible: Always

Steps to Reproduce:
1.(see details)
2.
3.

summary: Dependency in Wine should include samba-winbind


body:
openSUSE installation updated from 12.3 to 13.1
all patches applied (as of 03. Jan 2013)

lightdm/X crashes on simply hitting ENTER (without supplying a username)

Reproducible: Always

Actual Results:
system displays text console

Expected Results:
system redisplays lightdm login screen

System in runlevel 3:
###
$ ps aux | grep light
root     24898  0.0  0.0   9264   928 tty2     S+   09:36   0:00 grep
--color=auto light
###

System in runlevel 5:
###
$ ps aux | grep light
root     24931  0.0  0.1 267444  5216 ?        Sl   09:36   0:00
/usr/sbin/lightdm
root     24937  0.0  0.6 289392 27344 tty7     Ssl+ 09:36   0:00 /usr/bin/X :0
-auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
root     24947  0.0  0.0 158020  3480 ?        Sl   09:36   0:00 lightdm
--session-child 16 19
lightdm  24969  0.0  0.0  37964  2248 ?        Ss   09:36   0:00
/usr/lib/systemd/systemd --user
lightdm  24970  0.0  0.0 150460  1884 ?        S    09:36   0:00 (sd-pam)
lightdm  24971  0.0  0.7 392780 28020 ?        Ssl  09:36   0:00
/usr/sbin/lightdm-gtk-greeter
lightdm  24975  0.0  0.0  14076   528 ?        S    09:36   0:00 dbus-launch
--autolaunch a044c0e72171dc2e2a90bcbe000004e8 --binary-syntax --close-stderr
lightdm  24976  0.0  0.0  24564   880 ?        Ss   09:36   0:00
/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root     24987  0.0  0.0  83740  2292 ?        S    09:36   0:00 lightdm
--session-child 12 19
root     24991  0.0  0.0   9264   928 tty2     S+   09:36   0:00 grep
--color=auto light
###

System with lightdm crashed:
###
$ ps aux | grep light
lightdm  24969  0.0  0.0  37964  2248 ?        Ss   09:36   0:00
/usr/lib/systemd/systemd --user
lightdm  24970  0.0  0.0 150460  1884 ?        S    09:36   0:00 (sd-pam)
root     25015  0.0  0.0   9264   928 tty2     S+   09:37   0:00 grep
--color=auto light
###

summary: lightdm/X crashes on empty username


body:
hello suse ppl,

first off: i'm reporting bug after several years, i promise, i'll go better :)
. now to bugreport:

default suse cups setup was always set that cupsd was listening on
localhost:631 .. in suse 13.1 systemd creates for cups sockets (and whatver
else) and cupsd is started just when something accesses these sockets or
listening "init" service as it is recognized by netstat .. now systemd listens
on both tcp/udp 0.0.0.0/:::1 which seems wrong to me ..

i've always fixed systemd cups.socket service that it look like this:

# netstat -tulnp | grep 631
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN
1/init
tcp        0      0 ::1:631                 :::*                    LISTEN
1/init
udp        0      0 127.0.0.1:631           0.0.0.0:*
1/init
udp        0      0 ::1:631                 :::*
1/init

# lsof -i | egrep ipp
systemd     1   root   15u  IPv4   8692      0t0  TCP localhost:ipp (LISTEN)
systemd     1   root   16u  IPv6   8693      0t0  TCP localhost:ipp (LISTEN)
systemd     1   root   21u  IPv4   8694      0t0  UDP localhost:ipp
systemd     1   root   22u  IPv6   8695      0t0  UDP localhost:ipp
cupsd    1650   root    4u  IPv4   8692      0t0  TCP localhost:ipp (LISTEN)
cupsd    1650   root    5u  IPv6   8693      0t0  TCP localhost:ipp (LISTEN)
cupsd    1650   root    6u  IPv4   8694      0t0  UDP localhost:ipp
cupsd    1650   root    7u  IPv6   8695      0t0  UDP localhost:ipp

adjustements need to be done in /usr/lib/systemd/system/cups.socket

# cat /usr/lib/systemd/system/cups.socket
[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=127.0.0.1:631
ListenStream=[::1]:631
ListenDatagram=127.0.0.1:631
ListenDatagram=[::1]:631
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target

Please consider changing default (less secure) cups.socket systemd service ..

regards, daniel

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: systemd makes cups.socket listening on 0.0.0.0


https://bugzilla.novell.com/show_bug.cgi?id=857377

https://bugzilla.novell.com/show_bug.cgi?id=857377#c0

           Summary: /etc/machine-id and /var/lib/dbus/machine-id differ
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: sreeves-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: systemd-maintainers-at-suse.de
          Found By: ---
           Blocker: ---

I'm not sure but from what I understand this is a bug. Should the contents of
these files match?

This report stems from a problem reported on the pulseaudio mailing list
regarding no sound in steam games. symlinking one to the other restores the
sound.


body:
In openSUSE 13.1 /etc/sysconfig/samba is missing. However,
/usr/lib/systemd/system/nmb.service as well as
/usr/lib/systemd/system/nmb.service try to get startup parameter for smbd and
nmbd from this missing file. As result, no startup parameter is used for smbd
and nmbd. This leads to the following errors in /var/log/samba/log.smb and
/var/log/samba/log.nmb :
"standard input is not a socket, assuming -D option"

Nevertheless smbd and nmbd are started, so everything works at the firste
glance. However, I don't know what else (besides the missing -D parameter) was
stored in the missing /etc/sysconfig/samba

Reproducible: Always

summary: missing /etc/sysconfig/samba


body:
bdist_rpm (as a setuptools command) is broken in the shipping Python for 13.1.

The result:

Traceback (most recent call last):
  File "setup.py", line 149, in <module>
    run_setup(True)
  File "setup.py", line 137, in run_setup
    **kwargs
  File "/usr/lib64/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/site-packages/setuptools/command/bdist_rpm.py", line
28, in run
    _bdist_rpm.run(self)
  File "/usr/lib64/python2.7/distutils/command/bdist_rpm.py", line 383, in run
    pyversion = get_python_version()
NameError: global name 'get_python_version' is not defined

a quick inspection clearly shows a missing import:

from sysconfig import get_python_version

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: python: bdist_rpm broken


body:
When I try to install the google music manager through zypper from the google
repository I get a missing dependency to qtwebkit (on OSS12.2 this just
worked).

If I "break" the google-musicmanager-beta package by installing it anyways it
works fine as long as I have libQtWebKit4 installed.

Looks to me as if in 12.2 libQtWebKit4 still provided qtwebkit, but in 12.3 it
doesn't anymore.

This can easily be fixed by either creating a metapackage "qtwebkit" that
contains no files and requires libQtWebKit4, or by putting the right
"Obsoletes:" and "Provides:" in libQtWebKit4.

Reproducible: Always

Steps to Reproduce:
1. add the google music manager repository
2. force-install google musicmanager
3. make sure you have libQtWebKit4 installed
4. test google musicmanager and observe it working just fine

sai:~ # zypper lr -u -r 12
Alias          : google-musicmanager
Name           : google-musicmanager
URI            : http://dl.google.com/linux/musicmanager/rpm/stable/x86_64
Enabled        : Yes
Priority       : 99
Auto-refresh   : On
Keep Packages  : Off
Type           : rpm-md
GPG Check      : On
GPG Key URI    :
Path Prefix    :
Parent Service :
MD Cache Path  : /var/cache/zypp/raw/google-musicmanager
sai:~ # zypper se -s musicmana
Loading repository data...
Reading installed packages...

S | Name                     | Type    | Version       | Arch   | Repository
--+--------------------------+---------+---------------+--------+--------------------
  | google-musicmanager-beta | package | 1.0.91.1050-0 | x86_64 |
google-musicmanager
sai:~ # zypper in google-musicmanager-beta
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides qtwebkit needed by
google-musicmanager-beta-1.0.91.1050-0.x86_64
 Solution 1: do not install google-musicmanager-beta-1.0.91.1050-0.x86_64
 Solution 2: break google-musicmanager-beta-1.0.91.1050-0.x86_64 by ignoring
some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): 2
Resolving dependencies...
Resolving package dependencies...

The following NEW package is going to be installed:
  google-musicmanager-beta

1 new package to install.
Overall download size: 4.6 MiB. After the operation, additional 13.3 MiB will
be used.
Continue? [y/n/? shows all options] (y): y
Retrieving package google-musicmanager-beta-1.0.91.1050-0.x86_64

                (1/1),   4.6 MiB ( 13.3 MiB unpacked)
Retrieving: google-musicmanager-beta-1.0.91.1050-0.x86_64.rpm
..................................................................................................................................[done
(807.6 KiB/s)]
(1/1) Installing: google-musicmanager-beta-1.0.91.1050-0
.....................................................................................................................................................[done]
Additional rpm output:
warning: commands will be executed using /bin/sh
job 2 at 2014-01-06 10:19

summary: libQtWebKit4 obsoletes qtwebkit but does not provide it


body:
This bug can be found in KDE's bugtracker
https://bugs.kde.org/show_bug.cgi?id=328999 my backtrace of the crash can be
found there but more importantly one contributor suggests that the packaged
libotr is outdated. The comment and the fixing patch can be found here
https://bugs.kde.org/show_bug.cgi?id=328999#c26

(btw I'm using opensuse 13.1 with the kde412 repository. The kde411 kopete was
not crashing.)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: kopete crashes on sending messages with OTR plugin enabled


body:
By default, sound does not work in wine on 13.1. Only by installing the
following plugins was I able to get sound in wine:

alsa-plugins-32bit, alsa-plugins-pulse-32bit

these should be installed by default or wine otherwise reconfigured so that it
works properly pulseaudio.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: sound is broken for wine in 13.1


https://bugzilla.novell.com/show_bug.cgi?id=857671

https://bugzilla.novell.com/show_bug.cgi?id=857671#c0

           Summary: [zypper] no way to process a patterns sugested packages
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: libzypp
        AssignedTo: zypp-maintainers-at-forge.provo.novell.com
        ReportedBy: ma-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Community User
           Blocker: ---

[from IRC]
i've found probable bug .. i installed already devel_perl pattern but finally
zypper infor shows this:

Information for pattern devel_perl:
-----------------------------------
Repository: openSUSE-13.1-1.10
Name: devel_perl
Version: 13.1-13.6.1
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Visible to User: Yes
Summary: Perl Development
Description:
Tools and libraries for software development using the Perl programming
language.
Contents:

S | Name                         | Type    | Dependency
--+------------------------------+---------+-----------
  | perl-File-Tail               | package |
  | perl-File-Type               | package |
  | perl-Font-AFM                | package |
  | perl-Gtk2                    | package |
..

and any attempt to install (it again) ends up in that those packages are just
marked as suggested with no smart (automated) way to install them.

-----
@ma: There's no automated way to process them but they are included in the
patterns content list. That's not consistent/intuitive. Add option or fix list.


body:
When using a Kobo that has been updated to the latest firmware version, Calibre
complains with:

Your Kobo is running an updated firmware/database version.
As calibre does not know about this updated firmware,
database editing is disabled, to prevent corruption.
You can still send books to your Kobo with calibre,
but deleting books and managing collections is disabled.
If you are willing to experiment and know how to reset
your Kobo to Factory defaults, you can override this
check by right clicking the device icon in calibre and
selecting "Configure this device" and then the
"Attempt to support newer firmware" option.
Doing so may require you to perform a factory reset of'
your Kobo.

Upstream commits show that no code changes are needed to support the newer
versions besides version bumps:

https://github.com/kovidgoyal/calibre/commit/a4c35af27d7d6a8b7d11c59613380917cfeafed7
https://github.com/kovidgoyal/calibre/commit/c6fda62cc774e2148d1669a69af93104b1238c63
https://github.com/kovidgoyal/calibre/commit/7f4cce12f4f5547765ae12ecbf4cc4c8021abefa
https://github.com/kovidgoyal/calibre/commit/eabb3078e83957c845f07c35611cfcffe90c5c92

Factory isn't affected since it has the upstream commits to bump the version.

Reproducible: Always

summary: Calibre in openSUSE 13.1 refuses to use Kobo with latest fimware version


body:
The package libspectre1 is licensed under the terms of GNU Public
License.  The license requires that the text of the license should be bundled
with binary packages.  Currently the package violates this requirement, thereby
invalidating the license, and therefore exposes the customers to legal risk.

Reproducible: Always

Steps to Reproduce:
  1. { rpm -qi libspectre1; }
  2. { rpm -qd libspectre1 | grep -F COPYING; }

Actual Results:
  1. License     : GPL-2.0+
  2.

Expected Results:
  2. /usr/share/doc/packages/libspectre1/COPYING

summary: package libspectre1 does not provide COPYING


body:
https://bugzilla.novell.com/show_bug.cgi?id=857850

https://bugzilla.novell.com/show_bug.cgi?id=857850#c0

           Summary: openssl doesn't load engine
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: shchang-at-suse.com
        ReportedBy: lazy.kent-at-opensuse.org
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

% openssl engine gost
140624330909328:error:25066067:DSO support routines:DLFCN_LOAD:could not load
the shared library:dso_dlfcn.c:187:filename(/lib64/engines/libgost.so):
/lib64/engines/libgost.so: cannot open shared object file: No such file or
directory
140624330909328:error:25070067:DSO support routines:DSO_load:could not load the
shared library:dso_lib.c:244:
140624330909328:error:260B6084:engine routines:DYNAMIC_LOAD:dso not
found:eng_dyn.c:450:
140624330909328:error:2606A074:engine routines:ENGINE_by_id:no such
engine:eng_list.c:417:id=gost

Engines are installed in /usr/lib64/engines/, not in /lib64/engines/.

summary: openssl doesn't load engine


body:
when attempting to play a webm file using kaffeine, a message comes up saying
that "Kaffeine currently cannot play some file formats. Do you want to install
additional support?" If install is selected, it will say "The software to
install could not be found in the currently enabled software repositories"

The video that plays will output audio, but the video output is black. This
happens even though the libvpx1 package is installed, so kaffeine should be
able to play webm videos. Gwenviews plugin is able to play the video correctly.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: kaffeine does not recognize that webm codec is installed


body:
https://bugzilla.novell.com/show_bug.cgi?id=858193

https://bugzilla.novell.com/show_bug.cgi?id=858193#c0

           Summary: gcin froze gnome-shell
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
        AssignedTo: glin-at-suse.com
        ReportedBy: glin-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

With gnome-shell, clicking the pop-up empathy notification brings on the
empathy chat window. However, a deadlock could happen when using gcin as my
input method:

- gnome-shell(gcin-immodule, actually) waited the reply from gcin on
gcin-im-client.cpp:703 handle_read()
- gcin waited on eve.cpp: 1619 is_tip_window() for the WindowAttribute.

Removing is_tip_window() fixes the deadlock. I reported the issue to upstream
and confirmed is_tip_window(), which is a workaround for old chrome, is not
necessary anymore, so it's safe to remove the function.

summary: gcin froze gnome-shell


body:
There are some GTK application which are not able to startup if qtcurve is in
use. The problem is a problem with libglib.

One example is easytag.

See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707946

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: GTK2+ application don't startup if qtcurve is used as a theme


body:
dvipdfm / dvipdfmx fail to find their configuration file, as they search for
dvipdfmx.cfg using a progname of dvipdfm-x, not dvipdfm or dvipdfmx.

Reproducible: Always

Steps to Reproduce:
1. cat test.tex
\documentclass{article}
\usepackage{times}

\begin{document}

Hello

\end{document}

2. latex test.tex

3. dvipdfm test.dvi

Actual Results:
** WARNING ** Could not open config file "dvipdfmx.cfg".
$
test.dvi -> test.pdf
$
[1
$
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 ptmr8r
mktexpk: Running gsftopk ptmr8r 600

[and for some reason gs then dies on signal 11, and no output is produced, but
that isn't the issue here]

Expected Results:
No warning about missing config files, and the use of the installed Type1
fonts.

This can be fixed as follows:

/etc/texmf # ln -s dvipdfmx dvipdfm-x
/etc/texmf # mktexlsr .

Then dvipdfmx runs fine, showing that the problem is the change in the progname
it uses for searching for its configuration file. This is probably related to
the line 2013-06-15 in texlive-20130620-source/texk/dvipdfm-x/ChangeLog "Merge
dvipdfmx and xdvipdfmx into dvipdfm-x."

It is not yet clear to me if/how upstream has fixed this (put configuration
under dvipdfm-x, or change name used when searching for configuration).

summary: dvipdfm / dvipdfmx fail to find dvipdfmx.cfg


https://bugzilla.novell.com/show_bug.cgi?id=858429

https://bugzilla.novell.com/show_bug.cgi?id=858429#c0

           Summary: do not restart libvirt-guests during libvirt updates!
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: KVM
        AssignedTo: jfehlig-at-suse.com
        ReportedBy: mrueckert-at-suse.com
         QAContact: jdouglas-at-suse.com
          Found By: ---
           Blocker: ---

Why are we restarting the libvirt guests during a libvirt update? the kvm/xen
are in a different package so no files from libvirt should be affected by
leaving those running. this broke me one of my virtualization hosts twice now.

I kind of have the feeling this behavior is new in 13.1 and wasnt there on sles
11 sp3

could we please disable this behavior or is there a good reason to keep it?


body:
When working with cua-mode one always could mark areas downwards by pressing
the shift key and Down in parallel. The same was true if one was pressing both
the shift key and Up.
Starting with openSUSE 13.1, the new emacs does not allow to do this any more.
The culprit can be found in two lines in the file .gnu-emacs (which in fact
were there since a long time but did not cause any issues, probably because
cua-mode has been modified to not reassign the corresponding keys any more):

 (global-set-key [S-up]    'previous-line)
 (global-set-key [S-down]  'next-line)

commenting them out fixes the problem - and honestly, I do not see any sense
for a declaration like the above, because the down - key provides the
functionality, so why assign shift-down the same as down ...

Reproducible: Always

Steps to Reproduce:
1. load cua - mode in emacs
2. try to mark an area by pressing up/down and shift in parallel
3.
Actual Results:
Area is not marked

Expected Results:
Area should be marked

summary: Error in .gnu-emacs prevents cua - mode from apropriate function


https://bugzilla.novell.com/show_bug.cgi?id=858448

https://bugzilla.novell.com/show_bug.cgi?id=858448#c0

           Summary: bogus content in dracut man page (/boot/grub/grub.conf)
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: PC
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Documentation
        AssignedTo: ke-at-suse.com
        ReportedBy: mrmazda-at-earthlink.net
         QAContact: ke-at-suse.com
          Found By: ---
           Blocker: ---

Second paragraph under "Boot parameters" in current 13.2 dracut man page
contains the following:

"The kernel command line usually can be configured in /boot/grub/grub/conf,
.."

That language applies only to Fedora and its derivatives that use Grub Legacy
(and lately they haven't even had a Grub Legacy option). /boot/grub/grub.conf
does not exist in openSUSE. The corresponding file for Grub Legacy in openSUSE
is /boot/grub/menu.lst. For Grub2 (which I don't use, and taboo at installation
time) it would probably be /boot/grub/grub.cfg or /boot/grub2/grub.cfg.


body:
https://bugzilla.novell.com/show_bug.cgi?id=858502

https://bugzilla.novell.com/show_bug.cgi?id=858502#c0

           Summary: GNOME:Apps/gnucash: Bug
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
        OS/Version: openSUSE 13.1
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: OBS Request
        AssignedTo: os.gnome.maintainers-at-gmail.com
        ReportedBy: dennisgrunert-at-hotmail.de
         QAContact: adrian-at-suse.com
          Found By: ---
           Blocker: ---

On 30th Dec 2013 GnuCash 2.6 released. Please update this version in the build
service, since on the 2.6 is ready for the SEPA system introduced in 2 weeks.

summary: GNOME:Apps/gnucash: Bug


body:
liferea version 1.10.4 has been released, which fixes several bugs:

http://lzone.de/Liferea-1.10.4-Released

* Fixes SF #1123: Mistakenly claims "TinyTinyRSS source is not self-updating"
  (reported by Dominik Grafenhoher)
* Fixes SF #1119: Crash on font resize at startup.
  (reported by David Smith)
* Fixes #1117: Selecting last unread item in reduced feed list jumps to next
feed
  (reported by Bruce Guenter)

I personally am affected by the last item:
http://sourceforge.net/p/liferea/bugs/1117/

Reproducible: Always

Steps to Reproduce:
1. Select menu View -> Reduced Feed List
2. Select a feed with a single item
3. Click on last unread item
Actual Results:
liferea immediately jumps to next feed, hiding the feed last selected

Expected Results:
Stay on the selected feed item

summary: liferea 1.10.4 bugfix release


body:
X crashes with a segfault when starting.

Reproducible: Always

Steps to Reproduce:
1. install latest X.Org X Server 1.15.0 from the Xorg repo for openSUSE 13.1
2. install latest nvidia proprietary driver 331.38 from
http://www.nvidia.com/Download/driverResults.aspx/72250/en-us
3. start x after installing the driver
Actual Results:
Xorg crashes with a Segmentation fault

Expected Results:
X should start, as it did with last X.Org X Server 1.14

although on page
https://devtalk.nvidia.com/default/topic/672875/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-331-38-long-lived-branch-release-/
is stated at the last in the feature list "Added support for X.org xserver ABI
15 (xorg-server 1.15)" IT IS NOT WORKING!

at least not under openSUSE 13.1 x86_64 with latest Xorg server 1.15.0.

although the new driver compiles without any problems, it crashes when starting
X with a Segmentation fault.

as you can see in the devtalk-forum-thread, in the meantime other users with
other linux distros report, that it is working on their machines.
therefor i think, it has to do something with the xorg 1.15 packages from
opensuse, because xorg 1.14 does work.

summary: X.Org X Server 1.15.0 does not work with latest nvidia proprietary driver 331.38


https://bugzilla.novell.com/show_bug.cgi?id=858908

https://bugzilla.novell.com/show_bug.cgi?id=858908#c0

           Summary: /etc/hostname vs. /etc/HOSTNAME confusion
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: openSUSE 13.1
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: fcrozat-at-suse.com
        ReportedBy: suse-beta-at-cboltz.de
         QAContact: qa-bugs-at-suse.de
          Found By: Beta-Customer
           Blocker: ---

Bug 803653 was about /etc/hostname vs. /etc/HOSTNAME on 12.3, and especially
about hostnamectl's behaviour. This bugreport is a follow-up.

The behaviour on 13.1 is interesting[tm]: After a fresh install, there's only
/etc/HOSTNAME (owned by netcfg package), but no /etc/hostname:

-rw-r--r


https://bugzilla.novell.com/show_bug.cgi?id=859041

https://bugzilla.novell.com/show_bug.cgi?id=859041#c0

           Summary: libvirt-daemon has a postinstall check for a file in libvirt-daemon-driver-network
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Other
        AssignedTo: jfehlig-at-suse.com
        ReportedBy: thardeck-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: cschum-at-suse.com, chuller-at-suse.com
          Found By: Development
           Blocker: ---

libvirt-daemon has a postinstall check for a file in the package
libvirt-daemon-driver-network which isn't a dependency.

So the file /etc/libvirt/qemu/networks/default.xml will only be created if
libvirt-daemon is reinstalled after installing libvirt-daemon-driver-network.

This is the libvirt-daemon post install snippet:
# Install the default network if one doesn't exist
if test ! -f /etc/libvirt/qemu/networks/default.xml
then
    UUID=`/usr/bin/uuidgen`
    sed -e "s,</name>,</name>\n  <uuid>$UUID</uuid>," \
         < /usr/share/libvirt/networks/default.xml \
         > /etc/libvirt/qemu/networks/default.xml
fi

$ rpm -qf /usr/share/libvirt/networks/default.xml
libvirt-daemon-driver-network-1.1.2-2.14.2.x86_64


https://bugzilla.novell.com/show_bug.cgi?id=859057

https://bugzilla.novell.com/show_bug.cgi?id=859057#c0

           Summary: git send-email fails with "Can't call method "message" on an undefined value"
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Development
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: ddiss-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

This is a duplicate of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718976
and appears to be fixed upstream with 1:1.8.4.4-1.


body:
$ systemd-analyze <TAB> bash: _init_completion: command not found

If you have command-not-found installed then it will look even more silly ...
There are even more completions broken that way.

openSUSE default bash config gets more and more broken.
How can we get rid of all those completion scripts? Please don't install them
per default or is there an easy way to disable them?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: systemd-analyze, broken TAB completion


https://bugzilla.novell.com/show_bug.cgi?id=859105

https://bugzilla.novell.com/show_bug.cgi?id=859105#c0

           Summary: server:monitoring/nagios-plugins: Bug: Update Upstream URL to https://www.monitoring-plugins.org
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: schneemann@b1-systems.de
        ReportedBy: michael.friedrich-at-gmail.com
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
                CC: nix-at-opensuse.org
          Found By: ---
           Blocker: ---

The nagios-plugins.org website has been compromised and the Nagios Plugins
Development Team was required to move to a new host at
https://www.monitoring-plugins.org whilst renaming their project to Monitoring
Plugins.

Full the story here:
https://www.monitoring-plugins.org/archive/help/2014-January/006503.html

I do not suggest to rename the package unless there's the requirement to do so,
but update the project url and any (internal) references to source urls in
order to stay safe.

Kind regards,
Michael


body:
> bang-tan:~ # systemctl status dnsmasq
> dnsmasq.service - DNS caching server.
>    Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled)
>   Drop-In: /run/systemd/generator/dnsmasq.service.d
>            \u2514\u250050-insserv.conf-$named.conf
>    Active: failed (Result: exit-code) since Fri 2014-01-17 18:21:55 EST; 7min ago
>   Process: 2776 ExecStart=/usr/sbin/dnsmasq --log-async --enable-dbus --keep-in-foreground (code=exited, status=3)
>   Process: 2754 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
>  Main PID: 2776 (code=exited, status=3)
>    CGroup: /system.slice/dnsmasq.service
>
> Jan 17 18:21:55 bang-tan systemd[1]: Starting DNS caching server....
> Jan 17 18:21:55 bang-tan dnsmasq[2754]: dnsmasq: syntax check OK.
> Jan 17 18:21:55 bang-tan dnsmasq[2776]: TFTP directory /srv/tftpboot inaccessible: Permission denied
> Jan 17 18:21:55 bang-tan systemd[1]: dnsmasq.service: main process exited, code=exited, status=3/NOTIMPLEMENTED
> Jan 17 18:21:55 bang-tan systemd[1]: Failed to start DNS caching server..
> Jan 17 18:21:55 bang-tan systemd[1]: Unit dnsmasq.service entered failed state.

or on the command line try it - fails the same way

> bang-tan:~ # /usr/sbin/dnsmasq --log-async --enable-dbus --keep-in-foreground
> bang-tan:~ # echo $?
> 3

but it works fine as long as it is not launched as a daemon

> bang-tan:~ # /usr/sbin/dnsmasq --log-async --enable-dbus --keep-in-foreground -d &
> [1] 4193
> bang-tan:~ # dnsmasq: started, version 2.65 cachesize 2000
> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack
> dnsmasq: DBus support enabled: connected to system bus
> dnsmasq: asynchronous logging enabled, queue limit is 5 messages
> dnsmasq-tftp: TFTP root is /srv/tftpboot
> dnsmasq: using local addresses only for domain sea.lab.emc.com
> dnsmasq: reading /etc/resolv.conf
> dnsmasq: using nameserver 128.221.12.10#53
> dnsmasq: using nameserver 10.254.66.24#53
> dnsmasq: ignoring nameserver 10.6.154.11 - local interface
> dnsmasq: using local addresses only for domain sea.lab.emc.com
> dnsmasq: read /etc/hosts - 9 addresses
> dnsmasq: read /etc/dnsmasq.hosts/wadet2_hosts - 21 addresses
> dnsmasq: read /etc/dnsmasq.hosts/hosts_from_ldap - 417 addresses
> ...

Reproducible: Always

Steps to Reproduce:
1. zypper dup from 12.2 to 12.3 (it fails in 12.3 the same way)
2. then zypper dup from 12.3 to 13.1 (so we're current and all)
3. then notice dnsmasq still fails to launch as a daemon - scratch head -
google - write bug
Actual Results:
tail of strace output of failure

> ...
> capset({_LINUX_CAPABILITY_VERSION_3, 0}, {CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW}) = 0
> prctl(PR_SET_KEEPCAPS, 1)               = 0
> setuid(105)                             = 0
> capset({_LINUX_CAPABILITY_VERSION_3, 0}, {CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0
> openat(AT_FDCWD, "/srv/tftpboot", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
> open("/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-bundle/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-bundle/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-bundle/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-bundle/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-bundle/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-bundle/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> write(2, "\n", 1)                       = 1
> write(2, "dnsmasq: ", 9)                = 9
> write(2, "TFTP directory /srv/tftpboot ina"..., 60) = 60
> write(2, "\n", 1)                       = 1
> open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 14
> fstat(14, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> fstat(14, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc343f10000
> read(14, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 3519
> lseek(14, -2252, SEEK_CUR)              = 1267
> read(14, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 2252
> close(14)                               = 0
> munmap(0x7fc343f10000, 4096)            = 0
> write(13, "<26>Jan 17 18:32:11 dnsmasq[4278"..., 95) = -1 ENOTCONN (Transport endpoint is not connected)
> connect(13, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
> write(13, "<26>Jan 17 18:32:11 dnsmasq[4278"..., 95) = 95
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> write(13, "<26>Jan 17 18:32:11 dnsmasq[4278"..., 53) = 53
> close(13)                               = 0
> exit_group(3)                           = ?
> +++ exited with 3 +++
>

Expected Results:
seems when daemonized it may be using another uid that doesn't have permission
to read /srv/tftpboot (tftp service is handled by dnsmasq in our config)

perms on /srv/tftpboot default to 0750  i think - at least that's what we
have...

thanks for looking into this.

summary: dnsmasq launch as daemon fails (in or out of systemctl) status=3/NOTIMPLEMENTED


body:
rc.status hands off to systemctl, which in turn can expend significantly more
work than before.  Specifically, systemctl status will search the log for the
last ten lines by default and that takes more than two minutes on an old system
with cold caches.

Reproducible: Always

Steps to Reproduce:
1. rcntp status
2. rcntp status
3. rcntp status
Actual Results:
The first invocation above takes more than two minutes on my system after the
system has booted into KDE.  The subsequent invocations are fast, but after
some time of other disk activity repeating the exercise will lead to a slow
first response again.  The slowdown is caused by the log searching performed by
systemctl (which rc.status hands the work off to).

Expected Results:
There is no reason to incur such large delays since the log output isn't used
at all in scripts (it is only for human consumtion).

Adding the option "-n0" to the hand-off in /etc/rc.status:

        exec /bin/systemctl -n0 $1 "${_rc_base}"

resolves the problem and gets boot time back to normal.  If the output is
deemed important for interactive uses of the rc scripts, then the number of
lines should be configurable with a variable (standard is ten lines) that is
set to zero during the boot process.

summary: rc.status performance regression due to systemd integration


https://bugzilla.novell.com/show_bug.cgi?id=859361

https://bugzilla.novell.com/show_bug.cgi?id=859361#c0

           Summary: incorrect kernel-xen entries in grub.cfg
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Bootloader
        AssignedTo: jsrain-at-suse.com
        ReportedBy: ohering-at-suse.com
         QAContact: jsrain-at-suse.com
          Found By: Outsourced Testing
           Blocker: ---

Created an attachment (id=574881)
 --> (http://bugzilla.novell.com/attachment.cgi?id=574881)
factory-bootloader-bug.tar.xz

With current Factory grub.cfg gets bogus kernel-xen entries. kernel-xen is
somehow the default, but can not be booted as such because the xen.xz entry is
missing in cfg.cfg. There are additional correct entries for xen which can be
booted.


https://bugzilla.novell.com/show_bug.cgi?id=859365

https://bugzilla.novell.com/show_bug.cgi?id=859365#c0

           Summary: systemd-analyze set-log-level: free(): invalid pointer
    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: Basesystem
        AssignedTo: fcrozat-at-suse.com
        ReportedBy: suse-beta-at-cboltz.de
         QAContact: qa-bugs-at-suse.de
          Found By: Beta-Customer
           Blocker: ---

# systemd-analyze set-log-level
This command expects one argument only.
*** Error in `systemd-analyze': free(): invalid pointer: 0x00007f195454b6e0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7410f)[0x7f1953da810f]
/lib64/libc.so.6(+0x7996e)[0x7f1953dad96e]
/lib64/libc.so.6(+0x7a647)[0x7f1953dae647]
/lib64/libdbus-1.so.3(dbus_error_free+0x31)[0x7f19540f55d1]
systemd-analyze[0x402b72]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f1953d55be5]
systemd-analyze[0x40313d]
======= Memory map: ========
[...]

Needless to say that the expected result is just the message "This command
expects one argument only." without the "free(): invalid pointer" part ;-)

My system is Factory, last updated 2013-11-29 and systemd-208-6.1.x86_64. I can
also reproduce this bug on 13.1.


body:
Hello

/etc/init.d/apache2 reload or systemctl reload apache2.service not reading the
new config file or graceful restart the web server.
Also the logrotate uses /etc/init.d/apache2 reload but after running logrotate
apache2 didn't write any more to the logfiles.

BR/Torsten

Reproducible: Always

Steps to Reproduce:
1.change a apache config file
2./etc/init.d/apache2 reload
3.
Actual Results:
nothing happen, apache didn't reload also if logrotate runs
and have to reload apache ther where no log entrys after restarting apache.

Expected Results:
apache should renew the readed in config file.

summary: apache2 reload fails


body:
After today's update of qtcurve-gtk2 from 1.8.16-2.1.2 to 1.8.16-2.4.1
claws-mail no longer starts.
After a fallback to qtcurve-gtk2-1.8.16-2.1.2.x86_64 it can be started again.
The system is a plain openSUSE 13.1 with all available updates.

The update was performed with "you". Other packets were updated, too (openssl
and libpng16), but only qtcurve-gtk2 has an impact.

Reproducible: Always

Steps to Reproduce:
1.have a working claws-mail with qtcurve-gtk2-1.8.16-2.1.2
2.exit claws-mail
3.upgrade to qtcurve-gtk2-1.8.16-2.4.1.x86_64
4.try to start claw-mail, it crashes during the startup

summary: update openSUSE-2014-56 (qtcurve-gtk2-1.8.16-2.4.1.x86_64.rpm)  breaks claws-mail


body:
I use the function zip_open() of libzip to open an invalid zip file. Instead of
returning an null pointer the function causes a segmentation fault.

The installed libzip is part of the package libzip2, version 0.11.1-3.1.2. The
invalid zip file which demonstrates the bug is a simple text file containing
the word 'nonsense'.

According to the unit tests I run on the openSUSE Build Service the problem
does not occur on older versions (before 13.1) of openSUSE.

Reproducible: Always

Steps to Reproduce:
1.Create a file containing the word 'nonsense'.
2.Build a program which calls zip_open() on the this file.
Actual Results:
The program crashes

Expected Results:
Return a null pointer

summary: crash when libzip opens a invalid zip file


body:
During zypper dup when wicked was upgrading network configuration disappeared.

Reproducible: Always

Steps to Reproduce:
1.zypper dup
2.
3.
Actual Results:
When installing wicked packages network drops.

Expected Results:
Network should have kept going so all the other packages would download and
install.

After on zypper dup and during another networking was lost.
From dmesg:-
[83889.988963] br1: port 1(eth1) entered disabled state
[83889.992691] br0: port 1(eth0) entered disabled state
[83889.992730] br0: topology change detected, propagating
[83890.022425] device eth1 left promiscuous mode
[83890.022507] br1: port 1(eth1) entered disabled state
[83890.025398] device eth0 left promiscuous mode
[83890.025455] br0: port 1(eth0) entered disabled state
[83890.069753] wickedd (750) used greatest stack depth: 3304 bytes left
[83890.131542] device eth1 entered promiscuous mode
[83890.137569] device eth0 entered promiscuous mode
[83890.297438] IPv6: ADDRCONF(NETDEV_UP): enp0s19f2u4u4u4: link is not ready
[83890.304990] br1: port 1(eth1) entered listening state
[83890.305020] br1: port 1(eth1) entered listening state
[83890.305114] IPv6: ADDRCONF(NETDEV_UP): br1: link is not ready
[83890.308101] br0: port 1(eth0) entered listening state
[83890.308129] br0: port 1(eth0) entered listening state
[83890.308228] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
[83900.954449] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s19f2u4u4u4: link becomes
ready

So far I have set them up manually with e.g
"ifconfig br0 192.168.10.2"
"route add default gw 192.168.10.103"

The devices all still showed with ifconfig but weren't configured as per
/etc/sysconfig/network/ifcfg-br0.

summary: During zypper dup when wicked was upgrading network dropped.


body:
After installation of opensuse 13.1 the touch screen is inoperative.
I Followed these instructions:
http://activedoc.opensuse.org/book/opensuse-reference/chapter-26-using-tablet-pcs
The tabletpc pattern was installed.
These packages are not installed and are not found using a search in yast
software manager:
x11-input-fujitsu
x11-input-evtouch

Reproducible: Always

Steps to Reproduce:
1.boot computer to desktop
2.touch screen
3.no effect to applications or mouse pointer
Actual Results:
touch screen is inoperative

Expected Results:
mouse pointer and applications will respond to touch

summary: dell xps 18 touch screen inoperative


body:
https://bugzilla.novell.com/show_bug.cgi?id=859878

https://bugzilla.novell.com/show_bug.cgi?id=859878#c0

           Summary: server:monitoring/zabbix: Bug
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: boris-at-steki.net
        ReportedBy: mika.hahtokari-at-fi.fujitsu.com
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
                CC: nix-at-opensuse.org
          Found By: ---
           Blocker: ---

SLES 11 SP3 repositories contain PHP53* packages.
Zabbix requires PHP5* packages.
-> Nothing provides php5-gd error

Resolution, SLES 11 requirement for php53 in spec file.

summary: server:monitoring/zabbix: Bug


body:
See KDE bug
https://bugs.kde.org/show_bug.cgi?id=328311#c5

There's a patch (I wrote) which works for KDE 4.11.x and 4.12.1. I'm actually
working with a patched 4.11.5 on openSUSE 13.1.

https://projects.kde.org/projects/kde/kdepim/repository/revisions/5cc79e9246caee7875bd640bd6264476bb7330ce/diff

https://projects.kde.org/projects/kde/kdepim/repository/revisions/5cc79e9246caee7875bd640bd6264476bb7330ce/diff.diff

The patch will be included in 4.12.2 but because 4.11.5 was the last 4.11.x
release it won't come to openSUSE 13.1 via normal update.

Please "manually" include that patch for the "kdepim" package in openSUSE 13.1.
It should apply without any changes to "kdepim4-4.11.4-444.11.src.rpm" and
probably also if you're planning an update to 4.11.5 (which hasn't the patch as
I said).

Reproducible: Always

summary: error on manually selecting PGP key in KMail (please apply patch from upstream)


https://bugzilla.novell.com/show_bug.cgi?id=860083

https://bugzilla.novell.com/show_bug.cgi?id=860083#c0

           Summary: /sbin/service does not consider service alias links
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: lnussel-at-suse.com
        ReportedBy: mt-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

According to opensuse packaging guidelines "If you only support a service
file, link rcXXX to /sbin/service so that rcXXX continues to work",
I've created a link to /sbin/service in sysconfig:

/sbin/rcnetwork -> /sbin/service

but it does not work properly, as network.service and syslog.service, ...
is a link to the effective service and not listed in the query:

# bash -x /sbin/rcnetwork status
+ sd_booted
[...]
+ systemctl --full --no-legend --no-pager --type=service --all list-units
+ grep -q '^network.service'
+ return 1
+ echo 'rcnetwork: no such service network'
rcnetwork: no such service network
+ exit 1


body:
https://bugzilla.novell.com/show_bug.cgi?id=860097

https://bugzilla.novell.com/show_bug.cgi?id=860097#c0

           Summary: fonts-config script is outdated
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: ASSIGNED
          Severity: Normal
          Priority: P5 - None
         Component: Other
        AssignedTo: pgajdos-at-suse.com
        ReportedBy: pgajdos-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: jsmeix-at-suse.com, aj-at-suse.com, coolo-at-suse.com,
                    pmladek-at-suse.com, sndirsch-at-suse.com, tiwai-at-suse.com,
                    mvyskocil-at-suse.com
          Found By: ---
           Blocker: ---

CC all persons I think they should be there. Of course feel free to remove
yourself if you don't think so (sorry for noise then) or add whomever could
have interest.

The Story (can be skipped)
---------
For example, in xorg_config_font_dirs(), present fonts-config is searching
/etc/X11/xorg.conf not only for FontPath, but also for Load directions and sets
xtt_module_used or freetype_module_used accordingly. Apart from that only
freetype module seems to be used nowdays: since this file do not exist for some
time yet, content of these variables remains intact (zero) and thus

  elsif ( !$freetype_module_used && !$xtt_module_used) {
    # neither the xtt module nor the freetype module is used, generating TTCap
    # options makes no sense.
    next;
  }

become a tautology.

Solution
--------
I would like to
1) cleanup present code little bit and
2) add some setting possibilities related to hinting like LCD_SUBPIXEL or
HINTING_STYLE sysconfig variables.

Second point should remain out of scope of this bug. For the first point,
please find rpm or sources here: home:pgajdos/fonts-config
I will highly appreciate any comments or suggestions, especially related to
following section.

Changes
-------
fonts-config nowadays:
1.  gets options from sysconfig
2.  make fonts.scale and fonts.dir files in font directories
3.  adjusts hinting setup
4.  adjusts embedded bitmap setup
5.  run fc-cache
6.  makes gs fontmap
7.  makes OpenOffice font setup
8.  generates java font setup
9.  xset fp rehash
10. reloads X font server

In home:pgajdos/fonts-config is abandoned for now:
(a) From point 2. do not call fix_font_scale(), which almost means, that custom
fonts.scale.* will not be merged and that TTCap entries will not be created in
scale files. Even if I do not know if TTCap entries are used somewhere (pointer
appreciated), no one is missing them from /etc/X11/xorg.conf removal.
(b) Whole point 6. Not sure if make sense to keep this code alive. This is by
default sysconfig value turned off. Introduces dependency to f2tdemos.
(c) Whole point 7. It seems to be outdated: you get 'Nothing to do for this
version of OpenOffice.' anyway as the xcu file it is searching doesn't exist
anymore

If you think there is a single user using that, please speak up.

home:pgajdos/fonts-config now honors --quiet and as we call it with this option
in fontpackages rpm macros, there will not be any "progress bar" or any '*java
might not work*' warning message during package installation anymore.

summary: fonts-config script is outdated


https://bugzilla.novell.com/show_bug.cgi?id=860275

https://bugzilla.novell.com/show_bug.cgi?id=860275#c0

           Summary: kvm postinstall should reload udev rules
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: RC 1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: brogers-at-suse.com
        ReportedBy: dmueller-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: chuller-at-suse.com, achernikov-at-suse.com
          Found By: Development
           Blocker: ---

On a minimal 13.1 install, kvm_* is autoloaded, and permissions of /dev/kvm
are:

0600 root:root /dev/kvm

when installing "kvm" package, a 80-kvm.rules is installed that fixes
permissions to root:kvm, however that only has an effect after reboot.

It would be nice if the %post script would try to reload and reapply the rules,
something like :

%post
if [ "$(readlink -f /proc/1/root)" = "/" ]; then
  /sbin/udevadm control --reload-rules  || :
  /sbin/udevadm trigger || :
fi


body:
If a line style is set to dash-dotted in xfig, xfig seg faults.

Reproducible: Always

Steps to Reproduce:
1. Open xfig
2. Draw a line
3. Set line style to dash-dotted
Actual Results:
seg fault

If I compile the sources myself, same crash. valgrind reports uninitilized
values. If optimizations are turned off (-O0), xfig runs fine and valgrind
reports no problems. I tracked the problem down to a static int variable in
w_drawprim.c, specifying the size of the dash-dot description array. I made it
volatile (patch attached) and everything is fine now, even with optimizations
turned on again. Therefore it may be a problem of gcc, or gcc is confused by
the xfig code - no clue.

summary: Xfig crashes on dash-dotted lines (gcc bug?)


body:
https://bugzilla.novell.com/show_bug.cgi?id=860340

https://bugzilla.novell.com/show_bug.cgi?id=860340#c0

           Summary: Reconsider Backward compatibility in openSUSE:Systemd packaging guidelines
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
               URL: http://en.opensuse.org/openSUSE:Systemd_packaging_guid
                    elines#Backward_compatibility
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Documentation
        AssignedTo: fs-at-suse.com
        ReportedBy: mt-at-suse.com
         QAContact: adrian-at-suse.com
                CC: lnussel-at-suse.com, stefan.fent-at-suse.com,
                    werner-at-suse.com, systemd-maintainers-at-suse.de
          Found By: ---
           Blocker: ---

I've no idea if this bug is assigned correctly... PM?

The systemd packaging guidelines enforce ("you have to") a
    rc<servicename> ->  $sbin/service
compatibility link causing bug reports which force packagres to
create such links or implement a very specific wrapper to provide
the possibility to handle a service via (IMO) the SUSE specific
"rc<servicename>",

On the one side there are feature requests enforcing that service
have to provide native systemd support or features requiring it,
on the other side "it has to work as before".

Please rethink this requirement. There are many different services.
Some service have switched to per instance start of services using
native systemd mechanisms instead of handling all instances in one
service and a target which handles all instances (e.g. bug#848070),
.. or have been reworked otherwise.

Please review all the /etc/rc.status, /sbin/service (can't handle
targets grouping multiple instance services) and all other hooks
redirecting to systemctl, decide which mechanisms are required,
define and document applicable rules and cleanup all the rest.

pkgs: rpmlint rpmlint-tests


https://bugzilla.novell.com/show_bug.cgi?id=860477

https://bugzilla.novell.com/show_bug.cgi?id=860477#c0

           Summary: get_kernel_version must not print anything but the kernel version to stdout
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: ohering-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Outsourced Testing
           Blocker: ---

depending on the kernel .config and the target arch, get_kernel_version will
print additional output to stdout, breaking mkinitrd:

invalid=1 for -
<uname -r>

Print either nothing at all or just the kernel version. But no extra garbage.


https://bugzilla.novell.com/show_bug.cgi?id=860479

https://bugzilla.novell.com/show_bug.cgi?id=860479#c0

           Summary: xfce4-settings-manager Preferred Applications doesn't work with custom applications
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: Xfce
        AssignedTo: bnc-team-xfce-at-forge.provo.novell.com
        ReportedBy: aspiers-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Development
           Blocker: ---

For example if I go to the Utilities tab, select Other under File Manager, and
type dolphin, the selected application doesn't change.  This worked fine on
12.3.


body:
stable bugfix release for 2.1 series
http://www.mysqlperformanceblog.com/2014/01/24/percona-xtrabackup-2-1-7-now=
-available/

New Features

    rebased on MySQL versions 5.1.73, 5.5.35, 5.6.15 and Percona Server
versions 5.1.73-rel14.11 and 5.5.35-rel33.0.

Bugs Fixed

    After being rebased on MySQL 5.6.11 Percona XtraBackup has been affecte=
d by
the upstream bug #69780. Fixed by rebasing Percona XtraBackup on MySQL 5.6.=
15
which contains a fix for the upstream bug. Bug fixed #1203669.
    Backup directory would need to be specified even for running the
innobackupex with --help and --version options. Bug fixed #1223716.
    When creating an incremental backup with the changed page tracking feat=
ure
available in Percona Server, innobackupex would fail if the server had the
ANSI_QUOTES SQL mode enabled. Bug fixed #1248331.
    When innobackupex --galera-info is specified and Percona XtraDB Cluster=
 is
using GTID replication (version 5.6 only), innobackupex will execute FLUSH
BINARY LOGS and then carry the current binary log as indicated in SHOW MAST=
ER
STATUS into the backup set. Bug fixed #1250375.
    Percona XtraBackup did not roll back prepared XA transactions when appl=
ying
the log. Which was a regression introduced with the original port of Percona
XtraBackup patches to 5.6. Fixed by restoring code that has been lost in the
port. Bug fixed #1254227.
    Percona XtraBackup now uses libgcrypt built in randomization functions =
for
setting the Initialization Vector. Bug fixed #1255300.
    xtrabackup_56 didn=E2=80=99t support ALL_O_DIRECT option for innodb_flu=
sh_method in
Percona Server 5.6. Bug fixed #1261877.

Reproducible: Always

--=20
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=3Demail
-----

summary: Percona xtrabackup 2.1.7 maintenance release


body:
same as:

"Robert Marcano 2013-12-29 17:01:38 EST

"loginctl kill-session" and "loginctl kill-user" commands always returns with
an error message:
Failed to issue method call: Input/output error"

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

Reproducible: Always

Steps to Reproduce:
loginctl kill-user UserName

Actual Results:
Failed to issue method call: Input/output error

Expected Results:
systemd kills all UserName processes

summary: Some loginctl actions don't work


body:
A few days ago my systems (both openSUSE 12.3, one i586 and one x86_64)
received an update for the "iputils" package from the network:utilities repo.

After that upgrade, using ping with target addresses other than 127.0.0.1 or
127.0.0.2 (which are both present in /etc/hosts by default) crashes with a
segmentation fault.

The last few lines from "strace ping -c1 <TARGET>" look like this:

munmap(0xb75d1000, 86079)               = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=851, ...}) = 0
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=851, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77a5000
read(5, "### /etc/resolv.conf file autoge"..., 4096) = 851
read(5, "", 4096)                       = 0
close(5)                                = 0
munmap(0xb77a5000, 4096)                = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
gettimeofday({1390838375, 162837}, NULL) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
send(5, "\251\23\1\0\0\1\0\0\0\0\0\0\0011\00223\00242\00210\7in-addr\4"..., 41,
MSG_NOSIGNAL) = 41
poll([{fd=5, events=POLLIN}], 1, 5000)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [90])                = 0
recvfrom(5,
"\251\23\201\203\0\1\0\0\0\1\0\0\0011\00223\00242\00210\7in-addr\4"..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")},
[16]) = 90
close(5)                                = 0
-

summary: ipustils-s20121221(network:utilities) - ping segfaults on addresses outside /etc/hosts


body:
When I boot my machine and connect my LAN cable to my router, NetworkManager
wakes up and starts some helper programs (dhcpd, dns-resolver,...) to make my
internet connection work.
From time to time, however, dns-resolver refuses to write to a file
/etc/resolv.conf.  Instead it logs /var/log/messages:
> ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched...
> You can find my version in /etc/resolv.conf.netconfig
When this happens, dns resolution isn't working, so I can't use the internet at
all.
Unplugging and replugging the LAN cable, or restarting NetworkManager.service
doesn't help.  My current workaround is to overwrite resolv.conf with
resolv.conf.netconfig manually.

Reproducible: Sometimes

Steps to Reproduce:
NetworkManager running with default settings (dhcp).  Connect LAN cable.
Actual Results:
dns-resolve reports to /var/log/messages that it can't update resolv.conf.  DNS
resolution is broken.

The attached tar file contains the files resolv.conf and resolv.conf.netconfig.
 When the bug happened, I also found a file resolv.conf.p0aeWl in /etc, which
is identical to resolv.conf.  I also includ the file
/var/adm/netconfig/md5/etc/resolv.conf in the tar file, as well as the relevant
lines of /var/log/messages.

My machine is booted/connected to the internet approx. twice a day.  The bug
occurs approx every 10th day.

I have disabled nscd.service on my machine (reason: I'm using tor with some
smart filewall rules and am afraid nscd would leak dns requests.  These rules
only affect packets of specific users, so I'm sure they don't contribute to the
problem.).

The problem appeared with me updating my machine from oS 12.3 to 13.1.

summary: dns-resolver refuses to updates resolv.conf, dns resolution broken


body:
gnome-vfs2 as shipped with openSUSE 13.1 does not include SMB support, i.e.
/usr/lib(64)/gnome-vfs-2.0/modules/libsmb.so is missing.

The reason for this is that libsmbclient-devel-4.1.x installs its include file
(libsmbclient.h) to /usr/include/samba-4.0/ instead of /usr/include.
So the configure script doesn't find it and disables Samba support.

Adding the option "--with-samba-includes=/usr/include/samba-4.0" to %configure
enables it again (and it does even work! ;) ).

Reproducible: Always

summary: gnome-vfs2 is missing SMB support


https://bugzilla.novell.com/show_bug.cgi?id=860655

https://bugzilla.novell.com/show_bug.cgi?id=860655#c0

           Summary: network:utilities/iputils: Bug ping/ping6 segfaults @ FQDNs, both OS 12.3 & 13.1
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
        OS/Version: openSUSE 13.1
            Status: NEW
          Severity: Critical
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: ms-at-suse.com
        ReportedBy: ar-at-sent.com
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
          Found By: Community User
           Blocker: ---

for both OS 12.3

    lsb_release -r
        Release:        12.3
    uname -r
        3.7.10-1.24-desktop
    rpm -qa iputils
        iputils-s20121221-59.1.x86_64

and, OS 13.1

    lsb_release -r
        Release:        13.1
    uname -r
        3.13.0-1.g4b6e17a-desktop
    rpm -qa iputils
        iputils-s20121221-59.1.x86_64

with iputils from network:utilities repo,

ping/ping6 to FQDNs are segfaulting.

verified here on multiple machines, by multiple persons
100% reproducible

given,

    host google-public-dns-a.google.com
        google-public-dns-a.google.com has address 8.8.8.8
        google-public-dns-a.google.com has IPv6 address 2001:4860:4860::8888

test @ 12.3

    ping 8.8.8.8
        PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
        64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=28.7 ms
        64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=28.1 ms
        64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=28.9 ms
        ^C
        -


body:
On two machines with "openSUSE 13.1 "Bottle" and older 32-bit CPUs,
dd_rescue (dd_rescue-1.40-2.1.2.i586) is hanging, even when called without any
parameters (can be killed by CTRL+C).

strace shows that this is caused by SIGILL:

execve("/usr/bin/dd_rescue", ["dd_rescue"], [/* 60 vars */]) = 0
brk(0)                                  = 0x94f0000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7704000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=106332, ...}) = 0
mmap2(NULL, 106332, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76ea000
close(3)                                = 0
open("/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\n\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=17288, ...}) = 0
mmap2(NULL, 16512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb76e5000
mmap2(0xb76e8000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0xb76e8000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\233\1\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1978006, ...}) = 0
mmap2(NULL, 1772252, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7534000
mmap2(0xb76df000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ab000) = 0xb76df000
mmap2(0xb76e2000, 10972, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76e2000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7533000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7533700, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb76df000, 8192, PROT_READ)   = 0
mprotect(0xb76e8000, 4096, PROT_READ)   = 0
mprotect(0x8055000, 4096, PROT_READ)    = 0
mprotect(0xb7727000, 4096, PROT_READ)   = 0
munmap(0xb76ea000, 106332)              = 0
rt_sigaction(SIGILL, {0x804b000, [ILL], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGSEGV, {0x804b000, [SEGV], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
-

summary: dd_rescue causes illegal instruction on older 32-bit CPUs


body:
https://bugzilla.novell.com/show_bug.cgi?id=860832

https://bugzilla.novell.com/show_bug.cgi?id=860832#c0

           Summary: vfs_btrfs fails to build
    Classification: openSUSE
           Product: openSUSE 12.2
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: ASSIGNED
          Severity: Minor
          Priority: P5 - None
         Component: Samba
        AssignedTo: ddiss-at-suse.com
        ReportedBy: ddiss-at-suse.com
         QAContact: samba-maintainers@SuSE.de
                CC: samba-maintainers@SuSE.de
          Found By: ---
           Blocker: ---

Samba's new vfs_btrfs module fails to build on older platforms such as openSUSE
12.2. This is due to a conflicting WRITE_FLUSH definition, shared between
source3/include/smb.h and /usr/include/linux/fs.h.

The following upstream fix is required:
commit 4e6934ec6c163ad6fd9c317b5a7dd7775b0dc83f
Author: Jeremy Allison <jra-at-samba.org>
Date:   Thu Nov 21 21:33:33 2013 -0800

    Rename the profile enums with a SAMBA_ prefix to avoid conflict with system
files.

summary: vfs_btrfs fails to build


body:
Cause: Probably gvfs-backends-1.14.2-2.1.2.x86_64, the gvfs(d)-smb part

Problem: Thunar/Nautilus hangs/freezes when copying from a samba share.
Can't stop it from gui, have to kill the process. -Ftp transfer is not
affected.
Has been going on since -if I remember right- the first SuSE 12.-version.
Today, in 12.3, since release.
Seems to be solved in SuSE13.1. gvfs-1.18

My own system:
SuSE12.3 kernel 3.7.10-1.24-desktop-X86_64 Gnome and XFCE DE
gvfs-1.14.2-2.1.2.x86_64 and the same versions for gvfs-backends,
gvfs-backend-afc, gvfs-fuse and
libgvfscommon0-1.14.2-2.1.2.x86_64

My reason for not having reported this until now is that I thought about it=
 as
a "children desease" in Thunar,
switched over to XFCE-Thunar when Gnome started to look like iPhone.
The other week I tried Nautilus for the first time in years and found it
behaved in exactly the same way.
Nautilus-samba I've used without any problem since SuSE8.2.
Did a deeper search and found these interrelated bug reports:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923
And the related gnome bug:
https://bugzilla.gnome.org/show_bug.cgi?id=3D697782
that describe exactly the same phenomenon (my only difference: I don't read=
 or
play over samba).

Posted a thread in forums.opensuse after having searched it:=20
https://forums.opensuse.org/showthread.php/494777-Problem-copying-from-samb=
a-share-in-SuSE-12-3
Signed to opensuse-gnome-mailing list and wrote about it and got a suggesti=
on
about a patch from Michael Catanzaro:
https://build.opensuse.org/package/binaries/home:Golbats_Everywhere:branche=
s:openSUSE:12.3:Update/gvfs?repository=3Dstandard
Installed the patch (the whole gvfs-pack), and voil=C3=A1: The samba-proble=
m was
gone!
Ftp works as well as before, the other backend features I haven't explored.

Reproducible: Always

Steps to Reproduce:
1. Preconditions: gvfs-1.14.2-2.1.2.x86_64 and the same versions for
gvfs-backends, gvfs-backend-afc, gvfs-fuse and
libgvfscommon0-1.14.2-2.1.2.x86_64.
2. Open a samba share in Thunar/Nautilus from the graphical tree (left) om =
in
address bar smb://[server]/[share]
3. Copy a directory containing more than a few files.

Actual Results:=20=20
4. After the first few % copied, copying will finally hang and remain so
infinitely.

Expected Results:=20=20
The copying should have continued till it had succeeded

As I mention, Michael Catanzaro's patch solves the issue without any noticed
disadvantages. (Link above)
This problem has been going on for some years now, at least since 12.2. v.1=
2.3
isn't obsolete yet, in my opinion I think it should be soved before you aba=
ndon
the openSUSE12.3.
That it is solved in 13.1 is no excuse ;-).

--=20
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=3Demail
-----

summary: gvfs-backends; Thunar/Nautilus hangs/freezes when copying from a samba share


body:
with kde settings/network
i create an ap with my wifi adapter
then
in plasmoid-management i click on the ap to activate it
then
i fill the root password
then
ok
then nothing happens
"wifi network interface stays in state "non connected"

i check all with lamarque V souza dev of networkmanager
settings are good , my wifi adapter is compliant with ap mode

in networkmanager log i have this :

<info> Connection 'Radio Wifi AP' auto-activation failed: (5) Access Point (AP)
mode is not supported by the supplicant.

lamarque says : you need wpa_supplicant 2.0

2.0 is installed

lamarque says : Well, ap-mode is a compilation option for wpa_supplicant. Maybe
whoever compiled wpa_supplicant for OpenSuse forgot to enable it.

then
please suplly a wpa_supplicant compiled with the option ap-mode

thanks

see our conversation here : https://bugs.kde.org/show_bug.cgi?id=330473

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: wpa_supplicant, ap mode is not supported


https://bugzilla.novell.com/show_bug.cgi?id=3D860916

https://bugzilla.novell.com/show_bug.cgi?id=3D860916#c0

           Summary: Prepare and release update for clutter 1.16.4
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: GNOME
        AssignedTo: dimstar-at-opensuse.org
        ReportedBy: zaitor-at-opensuse.org
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

openSUSE 13.1 has clutter 1.16.2

Upstream pushed out a new release 1.16.4
This release have a few performance fixes that would be nice to have.

  =E2=80=A2 List of changes since Clutter 1.16.2

    - Performance improvements
    Avoid using hardware picking as much as possible; do not queue redraws
    when not needed, and rely on clipped redraws more.

    - Accessibility fixes

  =E2=80=A2 List of bugs fixed since Clutter 1.16.2

    #710227 - ClutterGestureAction memory corruption
    #719747 - ClutterStage: Don't add empty actors to the stage clip
    #712563 - Fixes for cogl journal usage when picking
    #722220 - Incorrect string reported in accessible text-changed events
              when text is removed
    #722188 - atk_text_get_n_selections() should return 0 when no text is
              selected
    #719901 - ClutterStageCogl: Ignore a clip the size of the stage
    #719563 - input-device: Guard against double free
    #719367 - Bind constraints: Don't force redraws on source relayout
    #719368 - Don't queue redraws when reallocating actor that haven't moved

The updated package is in the review que for GNOME:Factory

--=20
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=3Demail
-----


body:
When blas-devel is installed or upgraded, it creates a symlink
libblas.so -> libblas.so.3.4.2 (or similar).
This does not play nice with update-alternatives, which expects
libblas.so -> libblas.so.3
so that update-alternatives can change what libblas.so.3 points to.

Please fix blas-devel to play nicely with other blas versions (e.g. openblas
from the Science repo).

The same is valid for lapack-devel. Please also fix lapack-devel.

Reproducible: Always

Steps to Reproduce:
1. Install blas-devel
2. Install openblas-devel from the Science repo
3. Use update-alternatives --config libblas.so.3 to change which BLAS is used

Actual Results:
libblas.so still links to the version from blas-devel, no matter what I specify
using update-alternatives.

Expected Results:
libblas.so should link to the version I specified with update-alternatives

summary: blas-devel symlinks libblas.so -> libblas.so.3.4.2 , rendering update-alternatives useless. Also for lapack-devel.


https://bugzilla.novell.com/show_bug.cgi?id=861124

https://bugzilla.novell.com/show_bug.cgi?id=861124#c0

           Summary: add support for Fedora like additional actions to /sbin/service
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: lnussel-at-suse.com
        ReportedBy: fcrozat-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: mt-at-suse.com
          Found By: ---
           Blocker: ---

To deal with systemctl (and therefore /sbin/service) not allowing non-standard
actions anymore, Fedora has implemented a scheme allowing additional scripts
which can be run by /sbin/service:

https://git.fedorahosted.org/cgit/initscripts.git/commit/service?id=5d91d38c8c9b81db56dcd94cf5c470b0dce68da0

This adds support for legacy initscript actions such as service iptables save
Packages wishing to provide legacy actions should install programs (probably
scripts, but could be binaries) named
/usr/libexec/initscripts/legacy-actions/<service>/<action>

This would allow to drop sysvinit initscripts but keep legacy actions, if
needed.


https://bugzilla.novell.com/show_bug.cgi?id=861153

https://bugzilla.novell.com/show_bug.cgi?id=861153#c0

           Summary: sudo constantly using 100% of one CPU core
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: x86-64
        OS/Version: openSUSE 13.2
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: vcizek-at-suse.com
        ReportedBy: lchiquitto-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

I've noticed a few days ago that sudo (sudo-1.8.9p3-1.1.x86_64) is hogging 100%
of one CPU constantly. It's quite easy to reproduce and happens all the time:
"sudo sleep 10".


https://bugzilla.novell.com/show_bug.cgi?id=861365

https://bugzilla.novell.com/show_bug.cgi?id=861365#c0

           Summary: Gnome3: Immediate system hibernation/poweroff due to crash in libpower.so
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: GNOME
        AssignedTo: mgorse-at-suse.com
        ReportedBy: lpechacek-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

After update the system started to hibernate right after start up, rendering
the laptop unusable.  The symptoms were - no battery indicator in the top right
corner, message "Battery is critically low, hibernating".  There was the
following message in kernel log:
2014-01-29T20:12:58.469488+01:00 fmn kernel: [11487.642458]
gnome-settings-[1172]: segfault at 8 ip 00007f2382be3921 sp 00007fff43014a40
error 4 in libpower.so[7f2382bd9000+18000]

libpower.so is part of gnome-settings-daemon.  Renaming the library so that
gnome-settings-daemon cannot load the shared object makes the hibernation
problem go away.  'upower --dump' shows correct battery information as well as
the Gnome power settings dialog in the control center.

The malfunction seems related to the following changelog entry:
* Wed Dec 11 2013 mgorse-at-suse.com
- Add gnome-power-manager-new-upower-api.patch: port to UPower
  0.99.

Please investigate.

gnome-settings-daemon update history on my system:
2013-12-26
20:37:40|install|gnome-settings-daemon|3.10.2-2.1|x86_64||repo-oss|b84365138c440195045fe80de6e4df54291b89003c74f4ff250f3f5701c7c672|
2014-01-29
11:35:38|install|gnome-settings-daemon|3.10.2-3.1|x86_64||repo-oss|f1130ad1dd0fced2f476395f57dfc34ece01185417b2fe9cadf828c8fbae1ffc|


body:
After openssl update to 1.0.1e-11.14.1, FreeSWITCH segfaults when using webrtc
connection.
Probably, other products can be vulnerable too.

See
http://jira.freeswitch.org/browse/FS-6078
and
http://rt.openssl.org/Ticket/Display.html?id=3214

reverting to openssl-1.0.1e-11.10.1 solves the problem

Reproducible: Always

Steps to Reproduce:
1. use freeswitch + webrtc with updated openssl

Actual Results:
freeswitch segfaults before any sound can be heared

Expected Results:
webrtc session should complete successfully

summary: update to openssl-1.0.1e-11.14.1 broke WebRTC functionality in FreeSWITCH


body:
Freshclam can't verify downloaded signature updates.
Fails to verify MD5 sig

Reproducible: Always

Steps to Reproduce:
freshclam
Actual Results:
freshclam --debug output:
Downloading main.cvd [100%]
LibClamAV debug: Initialized 0.97.8 engine
LibClamAV debug: in cli_cvdload()
LibClamAV debug: MD5(.tar.gz) = 020a61eea72868db83e891f27b116c26
LibClamAV debug: cli_cvdverify: MD5 verification error
LibClamAV debug: Cleaning up phishcheck
LibClamAV debug: Phishcheck cleaned up
ERROR: Verification: Can't verify database integrity

According to mailing list user, problem does not happen with 13.1.
13.1 contains clamav 0.98 while 12.3 update repo still contains 0.97

Expected Results:
Correct update

summary: ClamAV needs fails to verify signature packages - needs update


body:
I run several 13.1 installations. All systems that use automount in order to
mount the users home directory as well as other NFS directories from a NFS
server work fine but the system  always hangs upon shutdown. Actually it takes
a very long time to complete the shutdown (> 10min).

The very same setup (also using systemd) with 12.3 works just fine. It also
worked fine for all older suse version using sysv init without any problem.

I created a systemd debug file but actuially I seem to be unable to see
something useful inside to find out what process actually does take a long time
to shut down and why.

But since this problem only occurs on systemd using NFS and automount its
probably related to these services.

Thanks
Rainer

Reproducible: Always

Steps to Reproduce:
1. Shut down or reboot the system (does not matter if you type reboot or click
on the corresponding menu in KDE
2.
3.
Actual Results:
System shutdown starts, KDE desktop is terminated then after some seconds
nothing seems to happen any more.

Expected Results:
A system shutdown in <10min :-)

This problem is very annoying, since we use a multiboot (windows/linux)
installtion on our desktops at the university. Since a linux shutdown does not
work any longer people tend to turn the system power off wich sometimes leas to
broken systems.

summary: system shutdown hangs when using NFS filesystemd via automount


body:
When running sa-update from the suse.cron-sa-update, SpamAssassin rules will be
updated as root with permissions set to the default set in /etc/login.defs.
Usually, this will be 022, so Amavis (which runs as user 'vscan') will be able
to read them.

However, if for privacy reasons the UMASK in /etc/login.defs is set to
something more strict (like 027 or 077), the rules will no longer be readable
by Amavis.

The obvious fix for this is to set

    umask 022

in the script before running sa-update.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: suse.cron-sa-update should set umask before running sa-update


body:
https://bugzilla.novell.com/show_bug.cgi?id=861923

https://bugzilla.novell.com/show_bug.cgi?id=861923#c0

           Summary: c99: command not found
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: Development
        AssignedTo: matz-at-suse.com
        ReportedBy: jengelh-at-inai.de
         QAContact: qa-bugs-at-suse.de
                CC: coolo-at-suse.com, rguenther-at-suse.com
          Found By: Beta-Customer
           Blocker: ---

In openSUSE 13.1, make-3.82 did the following:

$ echo .POSIX: >Makefile
$ make -p 2>&1 | grep ^CC
CC := cc

With make-4.0 that now ships in openSUSE Factory, this has changed to
CC := c99

However, our gcc package does not provide a c99 symlink yet, breaking
compilation that use implicit variables/rules.

summary: c99: command not found


body:
The locate replacement - mlocate - nightly updatedb cron job (mlocate.cron)
does not respect the prunepaths (UPDATEDB_PRUNEPATHS) set by sysconfig/locate.

Reproducible: Always

Steps to Reproduce:
1.install mlocate
2.wait for daily cron jobs to run
3.use the locate command and find the files that should have been excluded have
not been.

summary: mlocate does not respect prunepaths


https://bugzilla.novell.com/show_bug.cgi?id=862058

https://bugzilla.novell.com/show_bug.cgi?id=862058#c0

           Summary: Apache/apache2: version number in description and package name of spec-file
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: draht-at-suse.com
        ReportedBy: asvetter-at-cip.physik.uni-wuerzburg.de
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
          Found By: ---
           Blocker: ---

In package summary and description is quite some version numbers wrong: 2.2
instead of 2.4.

Is it really necessary to include the version number in description?


https://bugzilla.novell.com/show_bug.cgi?id=862075

https://bugzilla.novell.com/show_bug.cgi?id=862075#c0

           Summary: CTDB should include tmpfiles.d entry for /var/run/ctdb
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Samba
        AssignedTo: samba-maintainers@SuSE.de
        ReportedBy: tserong-at-suse.com
         QAContact: samba-maintainers@SuSE.de
          Found By: ---
           Blocker: ---

/usr/sbin/ctdbd_wrapper (invoked by the ctdb systemd service file) creates
/run/ctdb at runtime, but really this directory should be created via a
tmpfiles.d entry as described at:

http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Creating_files_.2F_subdirectories_in_.2Fvar.2Frun_and_.2Frun

See /usr/lib/tmpfiles.d/samba.conf and the Samba spec file for how this was
done for Samba.

Please note that this may also arguably want fixing on pre-13.2 releases,
although users are only likely to actually hit the problem when using CTDB in a
Pacemaker cluster (where ctdbd_wrapper is not used), as opposed to using CTDB
by itself.


https://bugzilla.novell.com/show_bug.cgi?id=862076

https://bugzilla.novell.com/show_bug.cgi?id=862076#c0

           Summary: use_lvmetad = 1 in lvm.conf triggers systemd to get into emergency target on boot
    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: thomas.blume-at-suse.com
        ReportedBy: thomas.blume-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: systemd-maintainers-at-suse.de
          Found By: Development
 Services Priority: 1000
           Blocker: ---

lvm2-2.02.98-0.28.5.1.x86_64 introduced the following change in lvm.conf:

- set use_lvmetad = 1 as default of lvm.conf(bnc#854413)

This creates a failure on activating non-root lvm mounts.
In my test system I'm using lvm devices for /home and /var:

[   ***] (1 of 2) A start job is running for dev-nonroot-var.device
[**    ] (2 of 2) A start job is running for dev-mapper-nonroot\x2dhome.device

systemd tries for a while to mount them, then times out and starts the
emergency target:

Job dev-nonroot-var.device/start finished, result=timeout
[ TIME ] Timed out waiting for device dev-nonroot-var.device.
Job var.mount/start finished, result=dependency
[DEPEND] Dependency failed for /var.
Job local-fs.target/start finished, result=dependency
[DEPEND] Dependency failed for Local File Systems.
Triggering OnFailure= dependencies of local-fs.target.
Trying to enqueue job emergency.target/start/replace
Installed new job emergency.target/start as 125
Installed new job emergency.service/start as 126

But the emergency target doesn't provide a shell either, it seems to loop
somewhere.

The reason why the start jobs fail, is apparently that lvmetad is not runnig.
I've tried to enable it (it was disabled) via:

 systemctl enable lvm2-lvmetad.service

but it didn't have any effect on the behaviour.

As a workaround, one can mount system root via, e.g. the rescue system and set:

use_lvmetad = 0

in lvm.conf.


body:
first, icecast-2.3.2-CVE-2011-4612.diff is no longer required as it's fixed by
upstream.
second, this patch introduce access to free'd memory because path is changed to
filtered_path and is free'd later but path is still being accessed.

Thus, this patch should be removed.

Reproducible: Always

summary: icecast-2.3.2-CVE-2011-4612.diff causes access to free'd memory


body:
This is because the version of brise is old, and ibus-rime have changed api. We
must update brise to 0.30 to fix this bug.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: ibus-rime can not launch


body:
gnote has an add-in that can migrate notes from tomboy, but it is disabled by
default.

Reproducible: Always

Steps to Reproduce:
1. Create a note in Tomboy.
2. Run gnote. Note that, even with the add-in enabled, it will only migrate
tomboy notes the first time it is run, so it is a good idea to ensure that
gnote's directories are not present before testing (ie, rm ~/.local/share/gnote
and ~/.config/gnote).
3. Look at the list of notes displayed by gnote.
Actual Results:
The Tomboy note is not listed (and is not present in ~/.local/share/tomboy).

Expected Results:
The note created in Tomboy should have been migrated and should be listed by
gnote.

summary: gnote does not automatically migrate tomboy notes


body:
each time i connect or disconnect an ethernet or wifi network i have these
messages in t networkmanager log

*******************************************************************************
2014-01-31T14:51:40.720257+01:00 linux-b4lz NetworkManager[1697]: <info>
(wlp1s9): supplicant interface state: disconnected -> inactive
2014-01-31T14:51:41.230767+01:00 linux-b4lz nm-dispatcher.action[1805]:
/etc/NetworkManager/dispatcher.d/privoxyd: line 12: /etc/init.d/privoxyd: No
such file or directory
2014-01-31T14:51:41.233410+01:00 linux-b4lz nm-dispatcher.action: Script
'/etc/NetworkManager/dispatcher.d/privoxyd' exited with error status 127.
2014-01-31T14:51:41.233958+01:00 linux-b4lz NetworkManager[1697]: <warn>
Dispatcher script failed: Script '/etc/NetworkManager/dispatcher.d/privoxyd'
exited with error status 127.
*******************************************************************************

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: privoxy, no privoxyd


body:
Patch for bnc#854413 switched LVM2 to use lvmetad by default. It appears
lvmetad scans all available devices on startup, including CD-ROMs and floppy.
It has cosmetic issues (errors are logged) but also attempt to access
non-existent floppy is known to hang for very long time.

Currently patch is pulled back due to bnc#862076. If switch to lvmetad is
considered again, it should restrict range of devices to scan, at least skip
floppies.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: lvmetad should not scan floppy


body:
from https://svn.apache.org/repos/asf/subversion/branches/1.7.x/CHANGES

Version 1.7.15
(12 Feb 2014, from /branches/1.7.x)
http://svn.apache.org/repos/asf/subversion/tags/1.7.15

 User-visible changes:
  - Client-side bugfixes:
    * copy: fix some scenarios that broke the working copy (r1560690)
    * diff: fix regressions due to fixes in 1.7.14 (issue #4460)

  - Server-side bugfixes:
    * mod_dav_svn: prevent crashes with SVNListParentPath on (CVE-2014-0032)
    * reduce memory usage during checkout and export (r1564215)

 Developer-visible changes:
  - General:
    * fix failure in checkout_tests.py
    * support compiling against Cyrus sasl 2.1.25 (r1404912, r1413402)

Reproducible: Didn't try

summary: Apache Subversion 1.7.15 fixes remotely triggerable segmentation fault in mod_dav_svn


body:
Tweets marked favorite on Choqok-1.4 are not listed on the Choqok's Favorite
Folder. It shows Favorite Mark highlighted for the Tweet. On the other hand,
Tweets marked favorite from other twitter clients (e.g. smartphone, tablet) are
listed on Choqok's Favorite Folder. It shows Favorite Mark highlighted too.

Reproducible: Always

Steps to Reproduce:
1.Open Choqok app.Select a tweet from the timeline and mark it Favorite
2.Browse into Choqok's Favorite Folder
3.Tweet marked Favorite is not showed on the Choqok's Favorite Folder
Actual Results:
twitter.com doesn't show favorite marker from tweets marked on Chokoq. Choqok
just shows favorite marker from tweets marked in Twitter (Web) or Twitter
Oficial App.

Expected Results:
Time ago,Choqok used to show favorite marker and favorite tweets on Favorite
Folder.

Recently, I posted a bug report https://bugs.kde.org/show_bug.cgi?id=330037 It
has been fixed "Bugfix has been committed to the master branch --> closed" by
Daniel Kreuter (2014-01-17 17:03:14 UTC).

summary: Tweets marked favorite on Choqok are not showed on Favorite Folder


body:
postgrey wont start after installation because the directory /var/lib/postgrey
does not exist:

# postgrey --inet=127.0.0.1:10031 --auto-whitelist-clients
can't open /etc/postgrey/postgrey_whitelist_recipients: No such file or
directory
2014/02/06-11:53:07 postgrey (type Net::Server::Multiplex) starting! pid(3691)
Binding to TCP port 10031 on host 127.0.0.1 with IPv4
Setting gid to "51 51"
Setting uid to "493"
ERROR: can't open lock file: /var/lib/postgrey/postgrey.lock

Reproducible: Always

Steps to Reproduce:
1. install postgrey  1.34-4.1.2
2. execute the command "postgrey --inet=127.0.0.1:10031
--auto-whitelist-clients"
3. watch the ouput
Actual Results:
no running postgrey process

Expected Results:
a running postgrey service

When i created the missing directory and changed the owner to postgrey
everything worked fine.

summary: postgrey fails to start because of missing /var/lib/postgrey directory