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

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

           Summary: em_ipset: Unknown symbol ip_set_test
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: i586
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Kernel
        AssignedTo: kernel-maintainers-at-forge.provo.novell.com
        ReportedBy: rommel-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Component Test
           Blocker: ---

The kernel module em_ipset is not loadable:

boxer:~ # modprobe -v em_ipset
insmod /lib/modules/3.11.10-11-desktop/kernel/net/netfilter/nfnetlink.ko
insmod /lib/modules/3.11.10-11-desktop/extra/ipset/ip_set.ko
insmod /lib/modules/3.11.10-11-desktop/kernel/net/sched/em_ipset.ko
FATAL: Error inserting em_ipset
(/lib/modules/3.11.10-11-desktop/kernel/net/sched/em_ipset.ko): Invalid
argument
boxer:~ # dmesg | tail
[   89.925139] Bluetooth: HCI socket layer initialized
[   89.925141] Bluetooth: L2CAP socket layer initialized
[   89.925146] Bluetooth: SCO socket layer initialized
[   89.936326] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   89.936329] Bluetooth: BNEP filters: protocol multicast
[   89.936336] Bluetooth: BNEP socket layer initialized
[  399.366396] Netfilter messages via NETLINK v0.30.
[  399.366960] ip_set: protocol 6
[  399.367073] em_ipset: disagrees about version of symbol ip_set_test
[  399.367077] em_ipset: Unknown symbol ip_set_test (err -22)

Is see this both in 3.11.10-11-desktop and 3.11.10-7.1-desktop and
3.11.6-4.1-desktop.

summary: em_ipset: Unknown symbol ip_set_test


body:
Non-security maintenance release.

Note the line:
    * mod_dav_svn: blacklist building with broken versions of httpd; 2.2.25,
      2.4.5 and 2.4.6 (r1545835)

The required patches were applied to our apache2 (httpd) package in #864308,
already released.

From https://svn.apache.org/repos/asf/subversion/tags/1.8.9/CHANGES

Version 1.8.9
(07 May 2014, from /branches/1.8.x)
http://svn.apache.org/repos/asf/subversion/tags/1.8.9

 User-visible changes:
  - Client-side bugfixes:
    * log: use proper peg revision over DAV (r1568872)
    * upgrade: allow upgrading from 1.7 with exclusive locks (r1572102 et al)
    * proplist: resolve inconsitent inherited property results (r1575270 et al)
    * increase minimal timestamp sleep from 1ms to 10ms (r1581305 et al)
    * merge: automatic merge confused by subtree merge (issue #4481)
    * propget: report proper error on invalid revision for url (r1586255)
    * commit: fix an assertion when committing a deleted descendant
      (r1571747, r1571787, r1571795)
    * merge: resolve segfault when '--force' merges a directory delete
      (r1577812, r1577813, r1579429)
    * resolve: prevent interactive conflict resolution when nothing has been
      done to resolve the conflict (r1577294)
    * update: fix locks lost from wc with pre-1.6.17 servers (issue #4412)
    * merge: honor the 'preserved-conflict-file-exts' setting (r1577151)
    * list: fix '--verbose' against older servers (r1591111)
    * unlock: fix ability to remove locks with timeouts (r1579588)
    * copy: fix 'svn copy URL WC' on relocated working copies
      (r1580626, r1580650)
    * export: allow file externals to be exported (issue #4427)
    * move: fix working copy db inconsistency in cert scenarios (issue #4437)
    * commit: fix an issue where mixed revision copy with non copy descendants
      that shadow a not present node couldn't be committed (r1518942 et al)
    * delete: properly remove move_to info when the node in its original
      location is removed (r1538812 et al)
    * status; fix an issue where output would vary based on if the target
      was the node itself or its parent (r1544597 et al)

  - Server-side bugfixes:
    * ensure proper access synchronization in fsfs on Windows (r1568953 et al)
    * svnadmin dump: don't let invalid mergeinfo stop dump (r1574868 et al)
    * svnserve: resolve performance regression caused by iprops (r1578853 et
al)
    * reduce size of memory buffer when reading config files (r1581296)
    * remove dead transaction if commit was blocked by hook (r1583977)
    * svnrdump load: fix crash when svn:* normalization (issue #4490)
    * fix memcached support (issue #4470)
    * svndumpfilter: fix order of node record headers (r1578670 et al)
    * mod_dav_svn: blacklist building with broken versions of httpd; 2.2.25,
      2.4.5 and 2.4.6 (r1545835)
    * mod_dav_svn: allow generic DAV clients to refresh locks (issue #3515)
    * mod_dav_svn: detect out of dateness correctly during commit (issue #4480)

 Developer-visible changes:
  - General:
    * improve consistency checks of DAV inherited property requests (r1498000)
    * fix ocassional failure in autoprop_tests.py (r1567752)
    * avoid duplicate sqlite analyze information rows (r1571214)
    * add Mavericks to our sysinfo output (r1573088)
    * bump copyright years to 2014 (r1555403)
    * unbreak test suite when running as root (r1583580)
    * resolve buffer overflow in testcode (r1481782)
    * fix libmagic detection with custom LDFLAGS (r1577200)
    * fix an out of scope variable use in merge (r1587946)
    * javahl: fix crash from resolve callback throwing an exception (r1586439)
    * ruby: fix two memory lifetime bugs (r1586052, r1586467)
    * fix a missing null byte when handling old pre-1.4 deltas (r1587968)
    * fix building with APR 0.9.x (r1585499)
    * make svn_ra_get_locks() and svn_ra_get_lock() report not locked nodes
      with a NULL svn_lock_t *, as documented (r1578273, r1578311, r1578326)
    * fix tests for compiler flags (r1573106)

Reproducible: Didn't try

summary: Apache Subversion 1.8.9 maintenance release


body:
fdupes is used to remove/symlink duplicate files during %install in several
packages. This process has to be deterministic regarding which file is the
"original", otherwise the rpm comparision of the current build result and a
previous run will have the false result.

fdupes 1.40 had a SUSE specific patch to sort by filename. This patch was
dropped for fdupes-1.50, which sorts by mtime, which was considered good
enough.

Unfortunately mtime sorting is not stable, as files may be created in parallel
during the build.

Reproducible: Always

Steps to Reproduce:
1. build a package on obs

Actual Results:
This is as excerpt from a Mesa build log:

[ 1289s]  /usr/share/man/man3/glColorTableParameter.3gl.gz 2 (none) 100444 root
root 0 4294967295
[ 1289s] -/usr/share/man/man3/glColorTableParameterfv.3gl.gz 2 (none) 100444
root root 0 4294967295
[ 1289s] -/usr/share/man/man3/glColorTableParameteriv.3gl.gz 2 (none) 120777
root root 0 4294967295 glColorTableParameterfv.3gl.gz
[ 1289s] +/usr/share/man/man3/glColorTableParameterfv.3gl.gz 2 (none) 120777
root root 0 4294967295 glColorTableParameteriv.3gl.gz
[ 1289s] +/usr/share/man/man3/glColorTableParameteriv.3gl.gz 2 (none) 100444
root root 0 4294967295
[ 1289s]  /usr/share/man/man3/glConvolutionFilter1D.3gl.gz 2 (none) 100444 root
root 0 4294967295

glColorTableParameterfv.3gl.gz and glColorTableParameteriv.3gl.gz are
identical, but the symlink direction has changed.

Expected Results:
Symlink direction should be deterministic.

A patched fdupes (optional sorting by filename, activated in the %fdupes macro
by default) is available in the utilities:fdupes repository

Affects openSUSE 12.3 and 13.1.

fdupes should be updated in 12.3 and 13.1 as it reduces rebuilds on obs and
avoids unnecessary package updates/downloads for users having additional
repositories. (e.g. Tumbleweed, KDE:Current ...)

summary: fdupes file sorting is not deterministic between OBS build runs


body:
The default config of fail2ban /etc/fail2ban/jail.conf has loads of default
entries which point to log files that are not used per default by openSUSE.
E.g.
> [ssh-iptables]
>
> enabled  = false
> filter   = sshd
> action   = iptables[name=SSH, port=ssh, protocol=tcp]
>            sendmail-whois[name=SSH, dest=you-at-example.com, sender=fail2ban-at-example.com, sendername="Fail2Ban"]
> logpath  = /var/log/sshd.log
> maxretry = 5
>
points to /var/log/sshd.log but per default, openSUSE logs ssh entries to
/var/log/messages. Also the log-file /var/log/fail2ban remains empty. So
nothing gets ever noticed by fail2ban.

Reproducible: Always

Steps to Reproduce:
1. default installation of openSUSE 13.1
2. sudo zypper in fail2ban
3. systemctl fail2ban start

Actual Results:
Fail2ban does not block anything.

Expected Results:
Fail2ban should at least work for elementary services like ssh out-of-the-box.

summary: default config of fail2ban points to non existing log file


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

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

           Summary: Packaging bug: file conflict between time and man-pages
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
        AssignedTo: pgajdos-at-suse.com
        ReportedBy: aduffeck-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

RPM --verify suggests that there's a file conflict between the time and
man-pages packages on my 13.1 machine:

1c108:~ # rpm -qV time
.........  d /usr/share/man/man1/time.1.gz (replaced)
1c108:~ # rpm -q time
time-1.7-3.1.2.x86_64
1c108:~ # rpm -qf /usr/share/man/man1/time.1.gz
man-pages-3.53-2.1.4.noarch

Not sure if the problem is man-pages or time, so please reassign accordingly if
I got it wrong :)

pkgs: man-pages time


body:
I'm running Opensuse 13.1

    uname -a
        Linux gdesk 3.14.4-1.gbebeb6f-desktop #1 SMP PREEMPT Tue May 13
12:36:01 UTC 2014 (bebeb6f) x86_64 x86_64 x86_64 GNU/Linux

with kernel from

    Kernel:/stable/standard

I added a new USB3 card.  It's a

    Anker AI440 3-Port USB 3.0 and Gigabit Ethernet Port PCI-E Card
    http://www.ianker.com/support-c13-g359.html

which I'd originally selected because I was told in #linux that the card is
supported using the existing xhci_hcd driver.

With the card installed, I get a bunch of these when booting:

May 17 18:32:32 gdesk kernel: ------------[ cut here ]------------
May 17 18:32:32 gdesk kernel: WARNING: CPU: 3 PID: 0 at
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.14.4/linux-3.14/drivers/usb/host/xhci-ring.c:1582
handle_cmd_completion+0xe18/0xe70 [xhci_hcd]()
May 17 18:32:32 gdesk kernel: Modules linked in: ohci_pci xhci_hcd
scsi_dh_hp_sw scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh dm_mirror
dm_region_hash dm_log forcedeth edd fan ata_generic sata_nv pata_amd thermal
processor dummy sha512_generic sha256_generic glue_helper lrw gf128mul
ablk_helper cryptd aes_x86_64 vfat fat udf crc_itu_t xfs libcrc32c dm_snapshot
dm_bufio dm_crypt dm_mod raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq raid10 raid1 raid0 md_mod
May 17 18:32:32 gdesk kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted
3.14.4-1.gbebeb6f-desktop #1
May 17 18:32:32 gdesk kernel: Hardware name: System manufacturer System Product
Name/M5A78L-M, BIOS 1603 12/19/2013
May 17 18:32:32 gdesk kernel:  0000000000000009 ffffffff81602401
0000000000000000 ffffffff810582c7
May 17 18:32:32 gdesk kernel:  ffff88041a58e000 ffff880418476480
ffff880418476020 0000000418476020
May 17 18:32:32 gdesk kernel:  0000000000000000 ffffffffa02e0628
0000000000000046 0000000000000246
May 17 18:32:32 gdesk kernel: Call Trace:
May 17 18:32:32 gdesk kernel:  [<ffffffff81004c65>] dump_trace+0x85/0x2f0
May 17 18:32:32 gdesk kernel:  [<ffffffff81004f76>]
show_stack_log_lvl+0xa6/0x190
May 17 18:32:32 gdesk kernel:  [<ffffffff81006401>] show_stack+0x21/0x50
May 17 18:32:32 gdesk kernel:  [<ffffffff81602401>] dump_stack+0x49/0x6a
May 17 18:32:32 gdesk kernel:  [<ffffffff810582c7>]
warn_slowpath_common+0x77/0x90
May 17 18:32:32 gdesk kernel:  [<ffffffffa02e0628>]
handle_cmd_completion+0xe18/0xe70 [xhci_hcd]
May 17 18:32:32 gdesk kernel:  [<ffffffffa02e20e3>] xhci_irq+0x333/0xa10
[xhci_hcd]
May 17 18:32:32 gdesk kernel:  [<ffffffff810b2d15>]
handle_irq_event_percpu+0x35/0x210
May 17 18:32:32 gdesk kernel:  [<ffffffff810b2f2e>] handle_irq_event+0x3e/0x60
May 17 18:32:32 gdesk kernel:  [<ffffffff810b58e5>] handle_edge_irq+0x85/0x150
May 17 18:32:32 gdesk kernel:  [<ffffffff81004bcd>] handle_irq+0x1d/0x30
May 17 18:32:32 gdesk kernel:  [<ffffffff81612a39>] do_IRQ+0x49/0xe0
May 17 18:32:32 gdesk kernel:  [<ffffffff81608f6d>] common_interrupt+0x6d/0x6d
May 17 18:32:32 gdesk kernel:  [<ffffffff81041002>] native_safe_halt+0x2/0x10
May 17 18:32:32 gdesk kernel:  [<ffffffff8100bdf9>] default_idle+0x19/0xf0
May 17 18:32:32 gdesk kernel:  [<ffffffff810b2005>]
cpu_startup_entry+0xe5/0x2e0
May 17 18:32:32 gdesk kernel:  [<ffffffff810322fa>] start_secondary+0x21a/0x2c0
May 17 18:32:32 gdesk kernel: ---[ end trace cb90807db2e323f4 ]---

The system continues to boot, never gets all the way to loading the desktop,
then hangs indefinitely.

Just removing the card fixes it, and boot's back to normal.

Chatting in

    ##kernel

after sharing this detail, I was instructed

    [20:05] <PRIVMSG> well, kernel not tainted, so a good candidate for bug
report
    [20:06] <PRIVMSG> but with opensuse, not kernel.org

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: Opensuse 13.1 throws CALL TRACE and fails to boot when USB3 (xhci_hcd) card is added.


body:
Replacing original kmix rpm with kmix-4.11.4-2.mga4.x86_64.rpm (Mageia 4) gives
temporary solution to the problem. Event Sounds slider appears.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: KMIX doesn't contain Event Sounds slider


body:
If you try to run xmtr as a normal user from the start menu, it fails silently.
If you try it from a terminal, it fails with "mtr: unable to get raw sockets."
So it seems to have not enough rights - mtr has owner root:dialout.

The path of mtr is /usr/sbin, that of xmtr is user/bin shouldn't it be sbin,
too?

/usr/share/applications/xmtr has "Exec=xmtr". Perhaps it should be something
like "/usr/bin/xdg-su -c /[s]bin/xmtr"

I don't know, if it should be fixed by the maintainer or upstream.

Reproducible: Always

Steps to Reproduce:
If you run it as root, it works fine.
If you try to run it as normal user, it fails - see above.

summary: running xmtr as normal user fails with "mtr: unable to get raw sockets."


body:
With the package privoxy, a logrotate config /etc/logrotate.d/privoxy is
shipped. The postrotate section of /etc/logrotate.d/privoxy tries to execute
"/etc/init.d/privoxyd reload" which is deprecated and therefore not present.
Logrotate should now reload the systemd service not the init.d script.

Reproducible: Always

summary: /etc/logrotate.d/privoxy tries to execute non-existing /etc/init.d/privoxyd


body:
The SSSD service in version 1.9.5 is very slow at logging in users in a large
company LDAP setup, where thousands of users and groups exists.

The reason being that a group lookup for a single user at login enumerates all
group member of these groups, although this information is not required to
login the specific user.

In SSSD version 1.9.6 a new configuration option "ignore_group_members" has
been added to prevent group member lookups when enumerating user groups.
See https://fedorahosted.org/sssd/ticket/1376 which is included in version
1.9.6

Hence, please update openSUSE 13.1 from SSSD version 1.9.5 to 1.9.6.

The 1.9.6 version has been built on OBS here:
https://build.opensuse.org/package/show/home:endzone:branches:openSUSE:13.1:Update/sssd
Test with this version and the new option have been successful (15 seconds for
user login w/ 1.9.5 and only 1 second with 1.9.6).

Reproducible: Always

Steps to Reproduce:
1. Large number of users and groups in LDAP
2. Login with SSSD service enabled

Actual Results:
Very slow user login as all group members are looked up in LDAP, which is not
needed

Expected Results:
Login should be reasonably fast

https://fedorahosted.org/sssd/ticket/1376

summary: SSSD 1.9.5 very slow with large LDAP groups, please update to 1.9.6


body:
During the installation of the latest update kernel for openSUSE 13.1 on my
system, "mkinitrd" refused to build the "initrd" file due to bailing out with
an error in the "/lib/mkinitrd/setup/72-block.sh" script.

The problem turns out to be a bug in the "/lib/mkinitrd/setup/72-block.sh"
script, which cannot handle the fact that the root file system is placed on a
MD RAID device that consists of a physical disk and another MD RAID device!

Reproducible: Always

Steps to Reproduce:
1. On my system, I have created 2 RAID1 MD devices:
        /dev/md/data   consistent of /dev/sdb and /dev/sdc
        /dev/md/system consistent of /dev/sda and /dev/md/data1
   The /dev/md/data MD device has been configured with 2 partitions (data[12]).
   The /dev/md/system MD device has been configured with 4 partitions
(system[1234]).

   Graphically the MD RAID layout looks like this (all disk paths relative to
"/dev"):

 sda --------------------------------(c)-+-> md/system -+-> md/system1 -> EFI
 sdb -(a)-v                              !              !-> md/system2 -> /boot
 sdc -(b)-*-> md/data -+-> md/data1 -(d)-^              !-> md/system3 -> /
                       !                                *-> md/system4 -> swap
                       !
                       !-> md/data2 --> LVM volume -+-> vol/var
                                                    !-> vol/tmp
                                                    *-> vol/home

   where (a) and (b) is a RAID 1 device with 2 disks (sdb and sdc), and
   (c) and (d) is a RAID 1 device with 2 disks (sda and md/data1).

2. When using "mkinitrd" to create an "initrd" file on a system using the above
given disk layout, results in the "initrd" not being build, due to an error
bail out in script "/lib/mkinitrd/setup/72-block.sh".
Actual Results:
Using "mkinitrd" to create an "initrd" file on systems, where the root file
system is placed on an MD RAID device that itself consists of MD RAID devices,
results in an error and no "initrd" file (extract from the
"/var/log/zypp/history" log file:

# 2014-05-20 12:49:22 kernel-desktop-3.11.10-11.1.x86_64.rpm installed ok
# Additional rpm output:
#
# Kernel image:   /boot/vmlinuz-3.11.10-11-desktop
# Initrd image:   /boot/initrd-3.11.10-11-desktop
# KMS drivers:     radeon
# Root device:  /dev/md127p3 (mounted on / as ext4)
# Resume device:        /dev/disk/by-label/swap00 (/dev/md127p4)
# Device md126 not handled
# Script /lib/mkinitrd/setup/72-block.sh failed!
# There was an error generating the initrd (1)

Expected Results:
Creation of the "initrd" file in "/boot" containing the correct MD set up in
"/etc/mdadm.conf", i.e. containing all the definitions needed to be able to
have consistent MD devices of which the "root" file system depends.

Although this patch definitively is not the right one (fix at the wrong place,
as far as I can tell), it does at least work as a work-around in my case:

-

summary: mkinitrd cannot handle multiple depended MD RAID configurations


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

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

           Summary: yast can't resize windows partition
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Installation
        AssignedTo: aschnell-at-suse.de
        ReportedBy: coolo-at-suse.com
         QAContact: jsrain-at-suse.com
          Found By: ---
           Blocker: ---

https://openqa.opensuse.org/tests/5466/modules/start_install/steps/3 shows the
error popup openqa gets while installing factory next to windows8.

The yast logs are available as
https://openqa.opensuse.org/tests/5466/file/y2logs.tar.bz2

summary: yast can't resize windows partition


body:
The atq in 13.1 uses a date/time format that is unsuitable for sorting by
date/time and there is no way to set the date format used (e.g. to ISO8601).

Reproducible: Always

Steps to Reproduce:
1. Set up some jobs with at
2. Run atq

Actual Results:
> atq
1377    Thu May 29 15:04:00 2014 a ms
1387    Thu May 22 21:59:00 2014 a ms
1376    Thu May 29 18:39:00 2014 a ms
1372    Wed May 28 21:32:00 2014 a ms
1       Fri May 23 21:04:00 2014 a ms
1361    Sun May 25 08:04:00 2014 a ms
1373    Thu May 29 09:29:00 2014 a ms
1367    Tue May 27 20:02:00 2014 a ms
4       Fri May 23 22:03:00 2014 a ms
1369    Wed May 28 21:04:00 2014 a ms
7       Sat May 24 19:04:00 2014 a ms
10      Sat May 24 23:03:00 2014 a ms

Expected Results:
The date format should be ISO 8601 - or there should be a switch to set the
date format used.

The atq up to 12.3 used ISO 8601, so this is a regression.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612075

summary: date format of atq is unusable for sorting


body:
(I filed this against Factory, but the same problem exists in
KDE:Distro:Factory and KDE:Current as well of course. Also this is not yet a
problem in 13.2 Milestone0 as that still contains KDE 4.12, but I couldn't
select a different Product Version)

See the following upstream bug report:
https://bugs.kde.org/show_bug.cgi?id=334235

This is missing because kdelibs4 4.13 is built without Nepomuk. And it would
need strigi as well to show additional metadata like Width/Height for pictures.

Reproducible: Always

Steps to Reproduce:
1. copy a file to a place where it already exists (with dolphin f.e.)

Actual Results:
A dialog appears saying that the file already exists, and asks whether to
overwrite it, rename it or cancel. This dialog doesn't show anything except for
the file name.

Expected Results:
It should show file metadata, such as file size.

This works fine in Ubuntu 14.04 f.e., which also ships KDE 4.13.

summary: Regression: File details missing from rename dialogue window


body:
openSUSE 12.3 x86_64
I have installed 1-click install for openSUSE and had always gpu support for my
applications like blender.
After the latest package update to nvidiaG03 331.67-26-1x86_64 there is no gpu
support anymore ?
See my post here :
https://forums.opensuse.org/showthread.php/497966-No-gpu-support-after-update-nvidia

Reproducible: Always

Steps to Reproduce:
1.choose 1 click install geforce 8 and later
http://en.opensuse.org/SDB:NVIDIA_drivers
2.nvidia-xconfig
3. restart
Actual Results:
no gpu cuda support

Expected Results:
It should give the option GPU CUDA within blender 2.70a user preferences

Installed nvidia driver 331.67.
http://www.nvidia.com/download/drive...px/75019/en-us

All works fine.
So openSUSE package install is the problem.

summary: 1 click install nvidia driver 331.67-26-1x86_64 has no gpu support anymore


body:
Attached patch adds systemd-like socket activation support to libmilter by
allowing to specify "fd:N" socket name in smfi_setconn. Please apply it so
milters  can use the same systemd unit with socket activation.

It is applied in Debian sendmail >= 8.14.4-6.

Reproducible: Always

summary: sendmail: systemd socket activation support for libmilter


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

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

           Summary: Replace TightVNC with TigerVNC as default VNC client
    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: vpelcak-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

TightVNC is not developed for some 5 years now, while TigerVNC is still
actively developed.

Therefore it makes sense to use it as default.


body:
The pkg-config file /usr/share/pkgconfig/log4net.pc contained in
log4net-1.2.10-72.1.3-noarch (official openSuse 13.1 Repo) states the version
of the library as 1.2.9 instead of 1.2.10

Reproducible: Always

Steps to Reproduce:
1.grep Version /usr/share/pkgconfig/log4net.pc

Actual Results:
Version: 1.2.9

Expected Results:
Version: 1.2.10

summary: log4net.pc contains wrong version number


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

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

           Summary: nfsv3 + ext3 + quotas = error -5 when attempting revoke
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: x86-64
        OS/Version: openSUSE 13.1
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Network
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: jimc-at-math.ucla.edu
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Versions:
kernel-desktop-3.11.10-11.1.x86_64, also 3.11.6, also kernel-default
nfs-client-1.2.8-4.13.1.x86_64
nfs-kernel-server-1.2.8-4.13.1.x86_64
quota-4.01-2.1.2.x86_64
quota-nfs-4.01-2.1.2.x86_64

The problem occurs when all of these elements are present:
1.  NFS server exports an ext3 (not ext4) filesystem.
2.  User block quotas are turned on for this filesystem.
3.  Client mounts it with Nfsvers=3 (not 4) in /etc/nfsmount.conf
4.  The user, executing on the client, writes a lot of stuff to a file
    rapidly and runs himself over quota.  In production, some X-Windows
    app spews error messages and fills up ~/.xsession-errors.  In the
    test scenario I do dd if=/dev/zero of=oinkage.dat bs=1M .

The correct outcome is that the writer should get EDQUOT (quota exceeded)
and die.  Two actual outcomes are seen.  In the test scenario given
below, the writer gets EIO (I/O error).  In the more complex production
environment, the user may not receive any error


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

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

           Summary: glibc: localedef.1 man page is now included in man-pages
    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: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: pgajdos-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

man-pages version (2014-05-26) seems to be polished version of the glibc
version (2005-05-20).

Changes:
NAME: no changes
SYNOPSIS: no changes
DESCRIPTION: more or less no changes, maybe better structured now
OPTIONS: general getopt informations removed; some option descriptions are more
exhaustive
EXIT STATUS: added
ENVIRONMENT: slightly different wording
FILES: format fixes, different wording
EXAMPLE: almost no changes
SEE ALSO: no changes
STANDARDS: replaced by CONFIRMING TO
AUTHOR: removed
COLPHON: added

Could you please look at it at consider to remove localdef.1 from glibc?


body:
With a bcache device present, mkinitrd fails with the error "Device bcache0 not
handled". Please see following patch for a solution:

-

summary: With bcache device present, mkinitrd fails


body:
With OpenSUSE 13.1, booting from a bcache device is not possible because of
lacking initrd support. See https://github.com/g2p/bcache-tools/issues/6

With bcache-tools installed and the following patch it works:

-

summary: Make booting from bcache device possible


body:
The bundled firmware in kernel-firmware for the Intel(R) Wireless 7260 chipset
is broken. In Factory, the firmware was updated

-------------------------------------------------------------------
Wed Mar 19 09:02:11 CET 2014 - tiwai-at-suse.de
...
  * iwlwifi: update firmware for 7260 / 3160 devices

There is a fixed version available in
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/iwlwifi-7260-7.ucode?id=824994715e0276e64cdbf2badbe02921a78fb287.

With the above updated firmware, the problem no longer occurs and the 7260 is
rock solid.

Reproducible: Sometimes

Steps to Reproduce:
1.
2.
3.

Although not directly security related, with the bundled firmware in 13.1, the
7260 will crash frequently and at times will be unusable.

summary: Firmware bug Intel(R) Wireless 7260 chipset


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

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

           Summary: dracut inefficiently called multiple times per zypper [dup|up|in] command
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: PC
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: mrmazda-at-earthlink.net
         QAContact: qa-bugs-at-suse.de
                CC: hare-at-suse.com, ma-at-suse.com, tiwai-at-suse.com,
                    trenn-at-suse.com, werner-at-suse.com,
                    Ulrich.Windl-at-rz.uni-regensburg.de,
                    suse-beta-at-cboltz.de, abittner-at-abittner.de,
                    nfbrown-at-suse.com, mmarek-at-suse.com, dmzhang-at-suse.com,
                    arvidjaar-at-gmail.com, sfalken-at-opensuse.org
        Depends on: 786318
          Found By: ---
           Blocker: ---

If they ever had this problem, Fedora, Mageia & Buntu solved it many many moons
ago, by during upgrade processes *not* automatically rebuilding initrds for
previously installed kernels.

+++ This bug was initially created as a clone of Bug #786318 +++ and Bug
#858840 +++
This is filed to finish what was started there but closed after the libzypp
foundation was "fixed".

mailing list thread starter:
http://lists.opensuse.org/opensuse-kernel/2012-10/msg00048.html

see also Novell access only FATE 313506

Each of the following packages triggers dracut to build a new initrd for each
installed kernel:

  device-mapper
  dracut (sometimes? already fixed? never?)
  lvm2
  mdadm
  multipath-tools
  udev

To reproduce:
1a-zypper up or zypper dup where any of the above listed packages are upgraded,
or
1b-zypper in one or more of the above listed packages

Actual behavior:
1-dracut is called to product a new initrd for each installed kernel each time
a package is installed that ever affects what goes into an initrd
(today's session, with lock kernel* set, nearly 3 months after 786318 was
marked fixed, on a 64 bit Factory installation last upgraded 10 days ago:
-rw-----


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

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

           Summary: serf 1.3.6 fixes crashes with Apache Subversion
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: All
        OS/Version: openSUSE 13.1
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Maintenance
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: Andreas.Stieger-at-gmx.de
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

From https://groups.google.com/d/msg/serf-dev/I2sUqG4D6-4/qjeufu5vhEgJ

This release fixes an instability introduced in serf 1.3.5 by
reverting that change (r2319).

If you have upgraded your application to use 1.3.5 or packaged serf
1.3.5 then we suggest upgrading to 1.3.6 soon.

From http://serf.googlecode.com/svn/tags/1.3.6/CHANGES

Serf 1.3.6 [2014-06-09, from /tags/1.3.6, rxxxx]
  Revert r2319 from serf 1.3.5: this change was making serf call
handle_response
    multiple times in case of an error response, leading to unexpected
behavior.


body:
When trying to use image writer for img files, it will not accept them

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: disk imagewriter does not work with img


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

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

           Summary: wlan on asus x550ca needs a patch
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: x86-64
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Kernel
        AssignedTo: jslaby-at-suse.com
        ReportedBy: jslaby-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Otherwise it does not work properly and is left hard blocked.

The commit is in -next so far:
commit 6f2724dcad3ca05ce5cd145e78c898780dec941a
Author: Andreas Utterberg <andreas.utterberg-at-thundera.se>
Date:   Tue May 6 22:27:45 2014 +0200

    WAPF 4 for ASUSTeK COMPUTER INC. X550CA WLAN ON.

summary: wlan on asus x550ca needs a patch


body:
Invocations from Emacs to (t)csh for non-interactive shells (i.e. via
call-process-shell-command) produce spurious erros from tset and stty since
there is no terminal available.  Moving the block that deals with Emacs'
shell-mode until after the test for an interactive shell resolves the problem.

#
# Only for interactive shells
#
if (! ${?prompt}) goto done

#
# Avoid trouble with Emacs shell mode
#
if ($?EMACS) then
  setenv LS_OPTIONS '-N --color=none -T 0';
  path tset -I -Q
  path stty cooked pass8 dec nl -echo
# if ($?tcsh) unset edit
endif

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: csh.cshrc produces spurious errors when (t)csh is called from Emacs non-interactively


body:
Make a figure containing text with the "Special" flag set. For the bug to be
clearly visible, type some TeX formula, e.g. "$\alpha$". Export to Combined
PS/PDF/LaTeX.

Open the foo_pspdftex.pdf file generated: the raw text appears, when it should
not (compare foo_pspdftex.ps).

Consequence: Try to \input{foo_pspdftex.tex} in a LaTeX document: you'll get
two superimposed texts: an alpha and "$\alpha$".

With Google you can find this bug has already been reported in other distros a
few years ago, you can even find a patch proposal.

Reproducible: Always

summary: Xfig somehow duplicates text when exporting to combined PS/PDF/LaTeX


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

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

           Summary: With latest updates nopw xlockmore crahses
    Classification: openSUSE
           Product: openSUSE 12.3
           Version: Final
          Platform: Other
        OS/Version: openSUSE 12.3
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: X11 Applications
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: werner-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: sbrabec-at-suse.com
          Found By: Development
           Blocker: ---

After latest updates the xlock progam crashes within nose mode

/home/werner> tail .xsession-errors -n 2
Access control list restored.
xlock: caught signal 11 while running nose mode (uid 1000).
/home/werner> xlock -install -timeout 15 -mode nose
Could not create FontSet
-*-fixed-medium-r-*-*-14-*-*-*-*-*-*,-*-*-medium-r-normal--14-*
Access control list restored.
xlock: caught signal 11 while running nose mode (uid 1000).
/home/werner> xlock -timeout 15 -mode nose
Could not create FontSet
-*-fixed-medium-r-*-*-14-*-*-*-*-*-*,-*-*-medium-r-normal--14-*
Access control list restored.
xlock: caught signal 11 while running nose mode (uid 1000).
/home/werner> xlock -mode nose
Could not create FontSet
-*-fixed-medium-r-*-*-14-*-*-*-*-*-*,-*-*-medium-r-normal--14-*
Access control list restored.
xlock: caught signal 11 while running nose mode (uid 1000).

... it always happens if some text will drawn onto the screen, e.g. if  the
nose guy tries to show its message


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

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

           Summary: Frequent crashes of autofs in NIS environment
    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: lchiquitto-at-suse.com
        ReportedBy: dmueller-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Hi,

autofs likes to crash on factory, example backtrace:

Thread 1 (Thread 0x7fb5058b5800 (LWP 2718)):
#0  0x00007fb5054c21d8 in _xend () at
../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:33
#1  __lll_unlock_elision (lock=0x7fb5054afd00 <rpcsoc_lock>, private=0)
    at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
#2  0x00007fb5054bc52d in __pthread_mutex_unlock_usercnt (mutex=<optimized
out>, decr=decr@entry=1)
    at pthread_mutex_unlock.c:66
#3  0x00007fb5054bc5ba in __GI___pthread_mutex_unlock (mutex=<optimized out>)
at pthread_mutex_unlock.c:310
#4  0x00007fb50529aa6f in clnt_com_create (raddr=raddr@entry=0x7fff202a4be0,
prog=prog@entry=100007,
    vers=vers@entry=2, sockp=sockp@entry=0x7fff202a4bcc, sendsz=sendsz@entry=0,
recvsz=recvsz@entry=0,
    tp=tp@entry=0x7fb5052a7b64 "tcp", flags=flags@entry=0) at rpc_soc.c:171
#5  0x00007fb50529ae1c in clnttcp_create (raddr=raddr@entry=0x7fff202a4be0,
prog=prog@entry=100007,
    vers=vers@entry=2, sockp=sockp@entry=0x7fff202a4bcc, sendsz=sendsz@entry=0,
recvsz=recvsz@entry=0)
    at rpc_soc.c:238
#6  0x00007fb505074f47 in yp_bind_ypbindprog
(domain=domain@entry=0x7fb505285420 <ypdomainname> "suse.de",
    ysd=ysd@entry=0x7fb507673ed0) at ypclnt.c:127
#7  0x00007fb50507516a in __yp_bind (domain=domain@entry=0x7fb505285420
<ypdomainname> "suse.de",
    ypdb=ypdb@entry=0x7fff202a4ca8) at ypclnt.c:198
#8  0x00007fb505075615 in __yp_bind (ypdb=0x7fff202a4ca8, domain=0x7fb505285420
<ypdomainname> "suse.de")
    at ypclnt.c:368
#9  do_ypcall (domain=0x7fb505285420 <ypdomainname> "suse.de", prog=3,
xargs=0x7fb5050743a0 <__GI_xdr_ypreq_key>,
    req=0x7fff202a4d20 " T(\005\265\177", xres=0x7fb5050744a0
<__GI_xdr_ypresp_val>,
    resp=resp@entry=0x7fff202a4d00 "") at ypclnt.c:348
#10 0x00007fb505075729 in do_ypcall_tr (domain=<optimized out>, prog=<optimized
out>, xargs=<optimized out>,
    req=<optimized out>, xres=<optimized out>, resp=0x7fff202a4d00 "") at
ypclnt.c:382
#11 0x00007fb5050757fe in yp_match (indomain=0x7fb5054afd00 <rpcsoc_lock> "",
inmap=0x0,
    inkey=0x7fb5054afd00 <rpcsoc_lock> "", inkeylen=-1, outval=0x7fff202a4da8,
outvallen=0x7fff202a4da4)
    at ypclnt.c:464
#12 0x00007fb502a063a6 in ?? () from /usr/lib64/autofs/lookup_nis.so
#13 0x00007fb502a06ab3 in lookup_init () from /usr/lib64/autofs/lookup_nis.so
#14 0x00007fb505906156 in open_lookup ()
#15 0x00007fb505906a78 in ?? ()
#16 0x00007fb505907591 in lookup_nss_read_master ()
#17 0x00007fb505918008 in master_read_master ()
#18 0x00007fb5058fbeda in main ()
(gdb) q


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

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

           Summary: seed fails to build on POWER
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: PowerPC-64
        OS/Version: openSUSE 13.2
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: GNOME
        AssignedTo: bnc-team-gnome-at-forge.provo.novell.com
        ReportedBy: dvaleev-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: mfrueh-at-suse.com, bugproxy-at-us.ibm.com,
                    hannsj_uhl-at-de.ibm.com
          Found By: ---
           Blocker: ---

for quite long time seed and seed too are failing to build for POWER BE
32bit,64bit and now for 64bit LE as well.

@IBM could you please help to resolve this?

It seems something is wrong with webkitgtk

[   69s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/seed-3.8.1/doc/modules/readline'
[   69s] ../../../src/seed ../../../doc/modules/make-functions.js
../../../doc/modules/readline/readline.js >
../../../doc/modules/readline/readline-funcs.xml
[   69s] 1   0x3fff807029e4
/usr/lib64/libjavascriptcoregtk-3.0.so.0(WTFCrash+0x44) [0x3fff807029e4]
[   69s] 2   0x3fff80723bb0
/usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3WTF11OSAllocator6commitEPvmbb+0x60)
[0x3fff80723bb0]
[   69s] 3   0x3fff80481640
/usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC7JSStack12growSlowCaseEPNS_8RegisterE+0xc0)
[0x3fff80481640]
[   69s] 4   0x3fff8047f508
/usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC7JSStack10entryCheckEPNS_9CodeBlockEi+0xe8)
[0x3fff8047f508]
[   69s] 5   0x3fff8047e0e8
/usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC11Interpreter7executeEPNS_17ProgramExecutableEPNS_9ExecStateEPNS_8JSObjectE+0x12c8)
[0x3fff8047e0e8]
[   69s] 6   0x3fff8057a95c
/usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC8evaluateEPNS_9ExecStateERKNS_10SourceCodeENS_7JSValueEPS5_+0x2ec)
[0x3fff8057a95c]
[   69s] 7   0x3fff80378168
/usr/lib64/libjavascriptcoregtk-3.0.so.0(JSEvaluateScript+0x2c8)
[0x3fff80378168]
[   69s] 8   0x3fff80b1f144
/home/abuild/rpmbuild/BUILD/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_simple_evaluate+0x54)
[0x3fff80b1f144]
[   69s] 9   0x3fff80b2662c
/home/abuild/rpmbuild/BUILD/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init_constrained_with_context_and_group+0x288)
[0x3fff80b2662c]
[   69s] 10  0x3fff80b269bc
/home/abuild/rpmbuild/BUILD/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init_with_context_and_group+0x40)
[0x3fff80b269bc]
[   69s] 11  0x3fff80b26b40
/home/abuild/rpmbuild/BUILD/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init_with_context_group+0x50)
[0x3fff80b26b40]
[   69s] 12  0x3fff80b26bc4
/home/abuild/rpmbuild/BUILD/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init+0x58)
[0x3fff80b26bc4]
[   69s] 13  0x10001850 /home/abuild/rpmbuild/BUILD/seed-3.8.1/src/.libs/seed()
[0x10001850]
[   69s] 14  0x3fff80934700 /lib64/libc.so.6(+0x24700) [0x3fff80934700]
[   69s] 15  0x3fff809348f4 /lib64/libc.so.6(__libc_start_main+0xc4)
[0x3fff809348f4]
[   69s] /bin/sh: line 1:  6549 Segmentation fault      ../../../src/seed
../../../doc/modules/make-functions.js
../../../doc/modules/readline/readline.js >
../../../doc/modules/readline/readline-funcs.xml
[   69s] Makefile:546: recipe for target 'readline-funcs.xml' failed

Full logs are available through webui:
https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/seed

summary: seed fails to build on POWER


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

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

           Summary: valgrind unhandled instruction
    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: Development
        AssignedTo: dmueller-at-suse.com
        ReportedBy: schwab-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Using the glibc from home:Andreas_Schwab:glibc valgrind fails with an unhandled
insn error.

# valgrind --db-attach=yes cat
==10970== Memcheck, a memory error detector
==10970== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10970== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==10970== Command: cat
==10970==
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1B 0x4 0x24 0x66 0xF
0x1B
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==10970== valgrind: Unrecognised instruction at address 0x4014487.
==10970==    at 0x4014487: _dl_runtime_resolve (dl-trampoline.S:72)
==10970==    by 0x4028AC: ??? (in /usr/bin/cat)
==10970==    by 0xFFF000277: ???
==10970==    by 0x1B: ???
==10970== Your program just tried to execute an instruction that Valgrind
==10970== did not recognise.  There are two possible reasons for this.
==10970== 1. Your program has a bug and erroneously jumped to a non-code
==10970==    location.  If you are running Memcheck and you just saw a
==10970==    warning about a bad jump, it's probably your program's fault.
==10970== 2. The instruction is legitimate but Valgrind doesn't handle it,
==10970==    i.e. it's Valgrind's fault.  If you think this is the case or
==10970==    you are not sure, please let us know and we'll try to fix it.
==10970== Either way, Valgrind will now raise a SIGILL signal which will
==10970== probably kill your program.
==10970==
==10970== Process terminating with default action of signal 4 (SIGILL)
==10970==  Illegal opcode at address 0x4014487
==10970==    at 0x4014487: _dl_runtime_resolve (dl-trampoline.S:72)
==10970==    by 0x4028AC: ??? (in /usr/bin/cat)
==10970==    by 0xFFF000277: ???
==10970==    by 0x1B: ???
==10970==
==10970== --

summary: valgrind unhandled instruction


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

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

           Summary: Scilab 5.5.0 in Opensuse 13.1 cannot use eigs function
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: x86-64
        OS/Version: openSUSE 13.1
            Status: NEW
          Keywords: easy_fix
          Severity: Critical
          Priority: P5 - None
         Component: Bugzilla
        AssignedTo: badshah400-at-gmail.com
        ReportedBy: vanag-at-telecom.ntua.gr
         QAContact: novbugzilla-bugs-at-forge.provo.novell.com
          Found By: Community User
           Blocker: Yes

The arpack dependency is not listed in libsciarnoldi.so

Minimal test

=ones(3,3);

-->eigs(A)
A previous error has been detected while loading libsciarnoldi.so:
/usr/lib64/scilab/libsciarnoldi.so: undefined symbol: dseupd_
 !--error 999
Impossible to load libsciarnoldi.so library: (null)
at line     111 of function eigs called by :
eigs(A)

With ldd on downloaded scilab

ldd /home/vanag/apps/scilab-5.5.0/lib/scilab/libsciarnoldi.so
    linux-vdso.so.1 (0x00007fffa329d000)
    libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f9b0ab10000)
    libblas.so.3gf => not found
    liblapack.so.3gf => not found
    libarpack.so.2 => /usr/lib64/libarpack.so.2 (0x00007f9b0a8c0000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9b0a6a2000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f9b0a49d000)
    libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f9b0a276000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f9b0a042000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f9b09d3e000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f9b0998f000)
    libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f9b09753000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9b0953b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f9b0b06c000)
ldd /usr/lib64/scilab/libsciarnoldi.so
    linux-vdso.so.1 (0x00007fff5a9fe000)
    libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007f5ad3ef1000)
    liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00007f5ad369b000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5ad347c000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f5ad3278000)
    libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f5ad3051000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f5ad2d4d000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f5ad299e000)
    libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f5ad2684000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5ad246c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5ad438a000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f5ad2238000)
    libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f5ad1ffb000)

The difference is libarpack.

Scilab is useless. Even though the packaged is twice as fast as the downloaded.


body:
Because of security considerations, I have set umask to 022 and symlinked
/root/.bash_history to /dev/null.

With this settings, an update of aaa_base sets /dev/null to mode 0600 in its
postinstall script.

This is a long-standing issue, originally dicussed at
http://lists.opensuse.org/opensuse/2009-03/msg00515.html and
http://lists.opensuse.org/opensuse/2014-06/msg00748.html.

The offending piece of code has been identified in
http://lists.opensuse.org/opensuse/2014-06/msg00755.html and
http://lists.opensuse.org/opensuse/2014-06/msg00761.html shows that the issue
should have been fixed, but the fix addresses only the touch, not the
chmod/chown.

Reproducible: Always

Steps to Reproduce:
As root, execute:

# umask 077; ln -sf /dev/null /root/.bash_hostory; zypper install -f aaa_base

Actual Results:
/dev/null is set to mode 0600, breaking all kinds of scripts

Expected Results:
Don't mess around with /dev/null

summary: Update of aaa_base removes permissions to /dev/null


body:
KDE Project Security Advisory
=============================

Title:          KMail/KIO POP3 SSL MITM Flaw
Risk Rating:    Medium
CVE:            CVE-2014-3494
Platforms:      All
Versions:       kdelibs 4.10.95 to 4.13.2
Author:         Richard J. Moore <rich-at-kde.org>
Date:           17 June 2014

Overview
========

The POP3 kioslave used by kmail will accept invalid certificates without
presenting a dialog to the user due a bug that leads to an inability to
display the dialog combined with an error in the way the result is checked.

Impact
======

This flaw allows an active attacker to perform MITM attacks against the
ioslave which could result in the leakage of sensitive data such as the
authentication details and the contents of emails.

Workaround
==========

None

Solution
========

Upgrade to version 4.13.3 or apply the patch at
http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=bbae87dc1be3ae063796a582774bd5642cacdd5d&hp=1ccdb43ed3b32a7798eec6d39bb3c83a6e40228f

Credits
=======

Thanks to Jim Scadden for reporting this issue and writing the initial fix,
and to David Faure for reviewing and improving the fix.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: KMail/KIO POP3 SSL MITM Flaw  (CVE-2014-3494)


body:
Hi,

Could you please patch hunspell, so that it would work with emacs and utf8
characters?

Here the patch to apply: the file hunspell-1.3.2/DIFFS in archive
http://sourceforge.net/projects/ezwinports/files/hunspell-1.3.2-3-w32-src.zip/download
or just http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7781#31

Here some links for further reading:
- https://sourceforge.net/p/hunspell/bugs/185/
- https://sourceforge.net/p/hunspell/patches/57/
- http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7781#46

TIA, Peter

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: make hunspell work with emacs and utf-8


body:
With the default service/unit-file dependencies as shipped with openSuSE 13.1,
the remote-fs service is started before if-up controlled network interfaces are
available, and is shut down after the network interfaces.

This results in remote mounts that should be mounted by remote-fs.service (for
example, cifs mounts defined in /etc/samba/cifstab) failing to mount at
startup, and if mounted manually, not being unmounted cleanly at shutdown. The
shutdown process also hangs until the unmount job times out since the network
has been taken down before the remote file systems are unmounted.

To fix this locally, I had to add the line:

Requires=network@eth0.service

to /usr/lib/systemd/system/remote-fs.service.

This ensures that remote-fs.service is not started before the network interface
is up and that the network interface is not stopped until remote-fs.service has
exited during shutdown.

I tried using "Requires=network.service" and "Requires=network.target" - these
fixed mounting at start up but did not fix the delayed shutdown.

Unforunately my hack is too system specific because it requires that the
correct interface name is known when remote-fs.service is created. This will
not be the same on every system and, in the case of multiple network
interfaces, there may be multiple dependencies.

Although it works as a short-term workaround a more permanent and more generic
solution is needed.

Reproducible: Always

Steps to Reproduce:
1. Define remote smb mounts in /etc/samba/cifstab
2. Have LAN interface controlled by if-up
3. Startup the system - remote cifs mounts will not be mounted.
4. Manually mount the cifs shares (systemctl restart remote-fs will do it).
5. Shutdown the systme - the system will hang during shutdown because the
network interface is stopped before the cifs shares are unmounted.
Actual Results:
As described above.

Expected Results:
The remote-fs service should only be started after the relevant network
interface(s) are started and online.

The remote shares should be unmounted before the relevant network interface(s)
is/are shut down.

summary: Race condition in systemd startup/shutdown affecting CIFS remote mounts


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

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

           Summary: server:monitoring/zabbix: Bug
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: x86-64
        OS/Version: openSUSE 12.3
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: boris-at-steki.net
        ReportedBy: cesarmartins_2004-linux-at-yahoo.com.br
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
                CC: nix-at-opensuse.org
          Found By: Customer
           Blocker: ---

Hi,

I just update my zabbix-server from version 2.2.3-3.1 to 2.2.3-11.1 (with
zypper up) and it not started , where give error of permission:

(5/7) Installing: zabbix-server-2.2.3-11.1
............................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/zabbix/zabbix-server.conf created as
/etc/zabbix/zabbix-server.conf.rpmnew
redirecting to systemctl  try-restart zabbix-server

root@jdivm04:/etc/init.d # ./zabbix-server start
redirecting to systemctl  start
Starting zabbix server zabbix-server [26168]: cannot open
[/var/log/zabbix/zabbix-server.log]: [13] Permission denied

          failed
r

I check the /etc/init.d/zabbix-server and compare with last version and notice
they try start the zabbix server with wrong(?) new user : zabbixs which is for
Java Daemon ....
I just back the old version of script and start without problems.

root@jdivm04:/etc/init.d
# diff -u zabbix-server  ~/zabbix-server.backup.bad
-

summary: server:monitoring/zabbix: Bug


body:
Distributed Replicated Block Device
(OS level clustered storage with block level replication)

Not sure if DRBD is now an official part of the HA stack, but it is often used
as the base technology for HA without the complex configuration required of
setups like RH clustering.

Current standard kernels require DRBD 8.4 as per the following project page
http://www.drbd.org/download/mainline/

DRBD 8.4 implements significant changes from the current 8.3.x versions
available in OSS and Factory repos.

Besides DRBD itself, tools should be built. Not sure why the accompanying tools
are not visible using a normal search at
http://software.opensuse.org/search?q=drbd&baseproject=openSUSE%3A13.1&search_devel=false&search_unsupported=false

While tools are available with the following modified search
http://software.opensuse.org/search?baseproject=ALL&p=1&q=drbd

This is the information for currently available drbd which does not work
Information for package drbd:
-----------------------------
Repository: Main Repository (OSS)
Name: drbd
Version: 8.3.11-8.1.3
Arch: x86_64
Vendor: openSUSE
Installed: No
Status: not installed
Installed Size: 473.5 KiB

Bottom line is that current DRBD installs but cannot run due to lack of tools.
Until this is addressed, I will attempt to install from source instead.

Reproducible: Always

Steps to Reproduce:
1. Install drbd
2. systemctl start drbd

Actual Results:
After attempting to start, drbd fails with the following status output

systemctl status drbd
drbd.service - LSB: Control drbd resources.
   Loaded: loaded (/etc/init.d/drbd)
   Active: failed (Result: exit-code) since Fri 2014-06-20 11:59:01 PDT; 6s ago
  Process: 2119 ExecStart=/etc/init.d/drbd start (code=exited, status=20)

Jun 20 11:59:01 linux-hf5m systemd[1]: Starting LSB: Control drbd resources....
Jun 20 11:59:01 linux-hf5m drbd[2119]: Starting DRBD resources: DRBD
module....3
Jun 20 11:59:01 linux-hf5m drbd[2119]: userland version: 8.3.11
Jun 20 11:59:01 linux-hf5m drbd[2119]: you should upgrade your drbd tools!
Jun 20 11:59:01 linux-hf5m drbd[2119]: no resources defined!
Jun 20 11:59:01 linux-hf5m systemd[1]: drbd.service: control process
exited...20
Jun 20 11:59:01 linux-hf5m systemd[1]: Failed to start LSB: Control drbd
re.....
Jun 20 11:59:01 linux-hf5m systemd[1]: Unit drbd.service entered failed state.

Expected Results:
drbd should start without errors

summary: Request - Build DRBD and DRBD Tools with latest stable source


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

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

           Summary: suitesparse can't find some symbols
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: crrodriguez-at-opensuse.org
        ReportedBy: dmitry-at-roshchin.org
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
          Found By: ---
           Blocker: ---

Some libraries from suitesparce package can't find some symbols, for example:

cat > conftest.c << 'EOF'
char umfpack_zi_get_determinant ();
int main ()
{
  return umfpack_zi_get_determinant ();
}

EOF

gcc -o conftest conftest.c -lumfpack

result - many errors:

>libumfpack.so: undefined reference to ...

Workaround is specifying all libraries, like
>gcc -o conftest conftest.c -lumfpack -lcholmod -lcolamd -lsuitesparseconfig -llapack

pkgs: octave suitesparse

summary: suitesparse can't find some symbols


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

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

           Summary: hostname lost while zypper dup from 13.1 to Factory
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: x86-64
        OS/Version: openSUSE 13.2
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: pgajdos-at-suse.com
        ReportedBy: lmuelle-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Development
           Blocker: No

lmuelle@hip:~> LC_ALL=POSIX ls -l /etc/{hostname,HOSTNAME}
lrwxrwxrwx 1 root root  8 Jun 20 20:18 /etc/HOSTNAME -> hostname
-rw-r--r


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

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

           Summary: bzip2 -dcf skips the first block if fed uncompressed data
    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: jnweiger-at-gmail.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

$ echo hello world | bzip2 -dcf

returns nothing. I'd expect to see 'hello world'.

According to the manual, the effects of -f include: "bzip2 normally declines to
decompress files which don't have the correct magic header bytes.  If forced
(-f),  however,  it  will pass  such  files  through  unmodified.   This  is
how GNU gzip behaves.

strace includes:

read(0, "hello world\n", 4096)          = 12
read(0, "", 4096)                       = 0
lseek(0, 0, SEEK_SET)                   = -1 ESPIPE (Illegal seek)
read(0, "", 4096)                       = 0
close(0)                                = 0

I assume, the failing lseek() should be acted on.
Possibly already an upstream issue?


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

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

           Summary: systemd update does not handle crypted lvm
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: x86-64
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: systemd-maintainers-at-suse.de
        ReportedBy: coolo-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: trenn-at-suse.com, idonmez-at-suse.com
          Found By: ---
           Blocker: ---

It seems to be a problem between kernel,plymouth,dracut and systemd - but only
since the latest systemd changes the problem is seen in openqa.

I reproduced it locally and the booting hangs with this:
http://stephan.kulow.org/systemd-plymouth-dracut.png

There is no continuing after that - but pressing esc twice will show me the
same last ~10 lines repeatedly.

This is based on openSUSE:Factory:Staging:H which has latest factory kernel and
dracut and Base:System/systemd, but misses plymouth changes


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

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

           Summary: libvirt-created iptables rules lost on DHCP lease renewal
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Network
        AssignedTo: lnussel-at-suse.com
        ReportedBy: vuntz-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: mt-at-suse.com
          Found By: ---
           Blocker: ---

libvirt is adding some rules to the firewall for the networks configured for
the VMs (to allow some NAT).

However, when using dhcpcd (ie, default network configuration on a
workstation), every time the lease is renewed,
/etc/sysconfig/network/if-up.d/SuSEfirewall2 is run and is resetting the
firewall rules to what is configured, which doesn't include the libvirt rules.

That means that the libvirt rules are lost every now and then.

A similar issue was debugged in bug 573246 and the fix was
http://bugzillafiles.novell.org/attachment.cgi?id=378796.

Is this fix acceptable for SuSEfirewall too?


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

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

           Summary: /usr/sbin/fsck.{msdos,vfat,fat} nissing legacy links below /sbin
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: All
        OS/Version: SLES 12
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: pgajdos-at-suse.com
        ReportedBy: werner-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Development
           Blocker: ---

Please remember that systemd uses the legacy path for fsck.<file_system> which
is /sbin/fsck.<file_system>

Therefore to support msdos, vfat, and fat please add legacy links from

        /usr/sbin/fsck.{msdos,vfat,fat}

to

        /sbin/fsck.{msdos,vfat,fat}

This bug is also valid for SLES-12


body:
Final Release in 2.0 branch.

Upstream Minor Bugfix Release

Changelog:
* Change to BibleGateway URL to use legacy web interface
* Issues with Themes when comparing theme files (lp#719514)
* Improved error messages with Easy Worship Song Imports (lp#1326664)
* Allow more than 26 equal verses within a Song. (lp#1310523)
* Handle songs where two optional breaks follow each other. (lp#1296104)
* Improve Database update error handling. (lp#1136278)

Reproducible: Always

summary: Update OpenLP from 2.0.4 to 2.0.5


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

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

           Summary: python-3.4 ensurepip is broken
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
        AssignedTo: jmatejek-at-suse.com
        ReportedBy: speilicke-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

Seems like the recently added ensurepip patch is broken, pip isn't installed
into the venv anymore.

saschpe@bort:~/Projects/scrello pyvenv .venv34
> /usr/lib64/python3.4/venv/__init__.py(251)_setup_pip()
-> subprocess.check_output(cmd, stderr=3Dsubprocess.STDOUT)
(Pdb) l
246             # environment vars, the current directory and anything else
247             # intended for the global Python environment
248             cmd =3D [context.env_exe, '-Im', 'ensurepip', '--upgrade',
249                                                         '--default-pip']
250             import pdb; pdb.set_trace()
251  ->         subprocess.check_output(cmd, stderr=3Dsubprocess.STDOUT)
252=20=20
253         def setup_scripts(self, context):
254             """
255             Set up scripts into the created environment from a director=
y.
256=20=20
(Pdb) subprocess.check_output(cmd)
/home/saschpe/Projects/scrello/.venv34/bin/python3.4: Error while finding s=
pec
for 'ensurepip.__main__' (<class 'ImportError'>: Module 'pip' is missing. U=
se:

  sudo zypper install python3-pip

to install it.
See README.SUSE for more information.); 'ensurepip' is a package and cannot=
 be
directly executed
*** subprocess.CalledProcessError: Command
'['/home/saschpe/Projects/scrello/.venv34/bin/python3.4', '-Im', 'ensurepip=
',
'--upgrade', '--default-pip']' returned non-zero exit status 1
(Pdb) q
Error:=20
saschpe@bort:~/Projects/scrello zypper if python3-pip
Loading repository data...
Reading installed packages...
...
Name: python3-pip
Version: 1.5.6-0
Installed: Yes
...
saschpe@bort:~/Projects/scrello find .venv34
.venv34
.venv34/lib
.venv34/lib/python3.4
.venv34/lib/python3.4/site-packages
.venv34/include
.venv34/pyvenv.cfg
.venv34/bin
.venv34/bin/python
.venv34/bin/python3.4
.venv34/bin/python3
.venv34/lib64
saschpe@bort:~/Projects/scrello .venv34/bin/python3.4 -Im ensurepip --upgra=
de
--default-pip                               git:master=E2=9C=97
/home/saschpe/Projects/scrello/.venv34/bin/python3.4: Error while finding s=
pec
for 'ensurepip.__main__' (<class 'ImportError'>: Module 'pip' is missing. U=
se:

  sudo zypper install python3-pip

to install it.
See README.SUSE for more information.); 'ensurepip' is a package and cannot=
 be
directly executed

That's pretty obvious since the following works:

saschpe@bort:~/Projects/scrello pyvenv --without-pip v
saschpe@bort:~/Projects/scrello find v
v
v/lib
v/lib/python3.4
v/lib/python3.4/site-packages
v/include
v/pyvenv.cfg
v/bin
v/bin/activate.csh
v/bin/activate.fish
v/bin/python
v/bin/python3.4
v/bin/activate
v/bin/python3
v/lib64

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

summary: python-3.4 ensurepip is broken


body:
Adobe has released security updates for Adobe Flash Player 14.0.0.125 and
earlier versions for Windows and Macintosh and Adobe Flash Player 11.2.202.378
and earlier versions for Linux. These updates address vulnerabilities that
could potentially allow an attacker to take control of the affected system.
Adobe recommends users update their product installations to the latest
versions:

    Users of Adobe Flash Player 14.0.0.125 and earlier versions for Windows and
Macintosh should update to Adobe Flash Player 14.0.0.145.
    Users of Adobe Flash Player 11.2.202.378 and earlier versions for Linux
should update to Adobe Flash Player 11.2.202.394.
    Adobe Flash Player 14.0.0.125 installed with Google Chrome will
automatically be updated to the latest Google Chrome version, which will
include Adobe Flash Player 14.0.0.145 for Windows, Macintosh and Linux.
    Adobe Flash Player 14.0.0.125 installed with Internet Explorer 10 will
automatically be updated to the latest Internet Explorer 10 version, which will
include Adobe Flash Player 14.0.0.145 for Windows 8.0.
    Adobe Flash Player 14.0.0.125 installed with Internet Explorer 11 will
automatically be updated to the latest Internet Explorer 11 version, which will
include Adobe Flash Player 14.0.0.145 for Windows 8.1.
    Users of the Adobe AIR 14.0.0.110 SDK and earlier versions should update to
the Adobe AIR 14.0.0.137 SDK.
    Users of the Adobe AIR 14.0.0.110 SDK & Compiler and earlier versions
should update to the Adobe AIR 14.0.0.137 SDK & Compiler.
    Users of Adobe AIR 14.0.0.110 and earlier versions for Android should
update to Adobe AIR 14.0.0.137.

Affected software versions

    Adobe Flash Player 14.0.0.125 and earlier versions for Windows and
Macintosh
    Adobe Flash Player 11.2.202.378 and earlier versions for Linux
    Adobe AIR 14.0.0.110 SDK and earlier versions
    Adobe AIR 14.0.0.110 SDK & Compiler and earlier versions
    Adobe AIR 14.0.0.110 and earlier versions for Android

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: flash-player, multiple vulnerabilities: CVE-2014-0537, CVE-2014-0539, CVE-2014-4671


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

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

           Summary: unnecessary write to /etc/HOSTNAME and/or /etc/hostname unnecessarily prevents netcfg installation
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 13.2 Milestone 0
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Basesystem
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: mrmazda-at-earthlink.net
         QAContact: qa-bugs-at-suse.de
                CC: pgajdos-at-suse.com
          Found By: ---
           Blocker: ---

In order to not have a current timestamp polluting either /etc/HOSTNAME or
/etc/hostname, and preserve the timestamp of a wired single fixed IP network
access point desktop PC's original installation, before doing installation or
upgrade,  I set a hard link from /etc/HOSTNAME to /etc/hostname, then set
"HOSTNAME" immutable.

I just did a minimal X HTTP Factory (20140626) installation, which failed to
install netcfg. On later installing some package that "requires" netcfg,
installation halted waiting for user input because the netcfg package
apparently thinks it needs to disturb /etc/HOSTNAME:

Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed
on file /etc/HOSTNAME: cpio: rename failed - Operation not permitted
error: netcfg-11.5-22.1.noarch: install failed

This unnecessary write shouldn't halt the process waiting for user input. It
should be sufficient for the package to complain in an installation log if it
insists on an unnecessary write. In the case of netcfg, the package
installation fails "completely" - on querying its changelog, not installed is
reported, and yet according to zypper the package depending on it is installed.

cf. bug 883999


body:
I get errors with SuSEfirewall2 in factory:

linux:~ # SuSEfirewall2
SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
SuSEfirewall2: using default zone 'ext' for interface wlp2s0
iptables-batch v1.4.21: host/network `ACCEPT' not found
Try `iptables-batch -h' or 'iptables-batch --help' for more information.
SuSEfirewall2: Error: iptables-batch failed, re-running using iptables
iptables v1.4.21: host/network `ACCEPT' not found
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.21: host/network `ACCEPT' not found
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.21: host/network `ACCEPT' not found
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.21: host/network `ACCEPT' not found
Try `iptables -h' or 'iptables --help' for more information.
SuSEfirewall2: Firewall rules successfully set

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: susefirewall errors on factory


body:
With a 3.15 opensuse (tumbleweed) kernel 3.15.6-40.1 my Seagate external USB
driver is not mountable. The USB device is detected, but USB storage does not
load.

I found that disabling CONFIG_USB_UAS fixes it. uas is already blacklisted as a
module:

50-blacklist.conf:# uas has been confirmed to be hopelessly broken
50-blacklist.conf:blacklist uas

But that is not enough because the kernel source also changes behavior when the
module

grep -r CONFIG_USB_UAS drivers/usb/*
drivers/usb/storage/Makefile:obj-$(CONFIG_USB_UAS)              += uas.o
drivers/usb/storage/usb.c:#if IS_ENABLED(CONFIG_USB_UAS)
drivers/usb/storage/usb.c:#if IS_ENABLED(CONFIG_USB_UAS)
drivers/usb/storage/unusual_devs.h:#if IS_ENABLED(CONFIG_USB_UAS)

and that is enough to break the standard usb storage.

So until the thing is really working the only way to handle it is to disable it
completely in the kernel config.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: CONFIG_UAS needs to be disabled at in kernel config


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

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

           Summary: qemu-2.1rc2 stalls VNC updates
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 201407*
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: KVM
        AssignedTo: kvm-bugs-at-forge.provo.novell.com
        ReportedBy: coolo-at-suse.com
         QAContact: jdouglas-at-suse.com
          Found By: Development
           Blocker: ---

I updated qemu on openqa.opensuse.org to the version in factory (compiled in
devel:openQA) and we see missing redraws.

openQA uses VNC protocol to get the screen updates and in 20-25% of all cases
it fails to pass the bootloader test as its stuck in a state like this:
https://openqa.opensuse.org/tests/12844/modules/bootloader/steps/3 (it should
read console=tty but reads console=ttty)

And when I connect to qemu with a 2nd VNC client, the redraws kick in out of
the sudden.

I compiled qemu from factory sources and the VNC worker thread gets stuck in
vnc-jobs.c in this code:

224     while (QTAILQ_EMPTY(&queue->jobs) && !queue->exit) {
225         qemu_cond_wait(&queue->cond, &queue->mutex);
226     }

(the line numbers are off due to my adding debug output). Somehow there are
never jobs in the queue, so the thread is not continueing sending updates.

I'm going back to 2.0, but if you have an idea how to continue debugging this,
let me know.

summary: qemu-2.1rc2 stalls VNC updates


body:
Attached is a patch for pam-config which adds support the Google Authenticator
which provides two-step verification. This patched is based off
pam-config-0.87.

https://code.google.com/p/google-authenticator/

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: pam-config pam-google-authenticator patch


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

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

           Summary: "Preparing disk" crashes kernel
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 201407*
          Platform: i586
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: P5 - None
         Component: Kernel
        AssignedTo: kernel-maintainers-at-forge.provo.novell.com
        ReportedBy: coolo-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: aschnell-at-suse.com
          Found By: ---
           Blocker: ---

https://openqa.opensuse.org/tests/13025 shows the kernel crashing while
formatting the disks.

[  201.263361] BUG: unable to handle kernel paging request at 00d6840c
[  201.264020] IP: [<c048983a>] __blk_bios_map_sg+0x18a/0x2f0
[  201.264020] *pde = 00000000
[  201.264020] Oops: 0000 [#1] SMP
[  201.264020] Modules linked in: dm_multipath dm_mod scsi_dh multipath raid10
raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq
raid1 raid0 md_mod parport_pc parport nls_utf8 isofs usb_storage iscsi_ibft
iscsi_boot_sysfs 8021q garp stp mrp llc arc4 ecb fan thermal nfs lockd fscache
nls_iso8859_1 nls_cp437 sg st af_packet hid_generic usbhid sunrpc sr_mod cdrom
ata_generic cirrus syscopyarea sysfillrect sysimgblt virtio_net ttm virtio_blk
uhci_hcd ehci_hcd drm_kms_helper ata_piix ahci usbcore libahci drm pvpanic
processor thermal_sys libata button hwmon i2c_core floppy usb_common virtio_pci
virtio_ring virtio edd squashfs loop [last unloaded: ppa]
[  201.264020] CPU: 0 PID: 4999 Comm: mkfs.btrfs Not tainted
3.16.0-rc5-1-default #1
[  201.264020] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Bochs 01/01/2011
[  201.264020] task: ec1540d0 ti: d338c000 task.ti: d338c000
[  201.264020] EIP: 0060:[<c048983a>] EFLAGS: 00010206 CPU: 0
[  201.264020] EIP is at __blk_bios_map_sg+0x18a/0x2f0
[  201.264020] EAX: 00d6840c EBX: d338de08 ECX: eeb3d5a4 EDX: 00d6840f
[  201.264020] ESI: 00000000 EDI: 00000000 EBP: d338ddf4 ESP: d338ddac
[  201.264020]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  201.264020] CR0: 8005003b CR2: 00d6840c CR3: 16e97000 CR4: 000006d0
[  201.264020] Stack:
[  201.264020]  f2d3ae00 00000010 d338dde4 eeb3cb90 00002000 ee921248 01000004
00000081
[  201.264020]  d336b350 00000000 f3956bc0 2c1dc000 00001000 00001000 00001000
eeb3ca80
[  201.264020]  ee921248 00000000 d338de18 c04899cf d338de08 f368d0e0 00000000
00d6840c
[  201.264020] Call Trace:
[  201.264020]  [<c04899cf>] blk_rq_map_sg+0x2f/0x130
[  201.264020]  [<f84ae478>] virtio_queue_rq+0x98/0x220 [virtio_blk]
[  201.264020]  [<c048ce59>] __blk_mq_run_hw_queue+0x199/0x2c0
[  201.264020]  [<c048df0b>] blk_mq_insert_requests+0xab/0x100
[  201.264020]  [<c048e8bf>] blk_mq_flush_plug_list+0x10f/0x120
[  201.264020]  [<c0485ece>] blk_flush_plug_list+0x9e/0x1b0
[  201.264020]  [<c04862d2>] blk_finish_plug+0x12/0x40
[  201.264020]  [<c0327f8d>] generic_writepages+0x3d/0x60
[  201.264020]  [<c0328d4a>] do_writepages+0x1a/0x40
[  201.264020]  [<c0320124>] __filemap_fdatawrite_range+0x54/0x60
[  201.264020]  [<c0322b2b>] SyS_fadvise64_64+0x24b/0x250
[  201.264020]  [<c071db15>] syscall_call+0x7/0xb
[  201.264020]  [<b7645eb3>] 0xb7645eb2
[  201.264020] Code: 5d e4 c1 fa 05 c1 e2 0c 03 55 dc 01 d9 39 d1 0f 84 fc 00
00 00 8d 74 26 00 83 20 fd 8b 45 08 8b 00 e8 bb fe 02 00 8b 5d 08 89 03 <8b> 10
8b 5d e0 83 e2 03 f6 c3 03 0f 85 0c 01 00 00 8b 4d dc 09
[  201.264020] EIP: [<c048983a>] __blk_bios_map_sg+0x18a/0x2f0 SS:ESP
0068:d338ddac
[  201.264020] CR2: 0000000000d6840c
[  201.310761] ---[ end trace a22ed0866cd5a71b ]---

summary: "Preparing disk" crashes kernel


body:
Within OpenSuSE 13.1 libgdbm4 is used to create and manage database files. A
good example for an application of this is vacation. vacation -i initializes a
file .vacation.db with the help of gdbm_open(). But the database file that was
created seems to be unusable. The file format should be something like "GNU dbm
1.x or ndbm database, little endian", but the file can only be identified as
"data". I can reproduce the behaviour also with a little program in C to open a
database (see the Attachment). Its a short extract from vacation.c of the
source package of vacation-1.2.7.1.

Reproducible: Always

Steps to Reproduce:
1. call "vacation -i"
2.
3.
Actual Results:
Generated .vacation.db looks like:
-rw-r--r

summary: vacation -i initializes unusable db files with gdbm_open()


body:
vcut from vorbis-tools reproducibly crashes with a segmentation fault. I get
the following backtrace:

#0  __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:40
#1  0x00007fa0beab48cc in ogg_stream_iovecin () from /usr/lib64/libogg.so.0
#2  0x00007fa0beab4a2c in ogg_stream_packetin () from /usr/lib64/libogg.so.0
#3  0x0000000000401b90 in write_packet (s=s@entry=0x7fffe76e2210,
packet=packet@entry=0x7fffe76e2080) at vcut.c:494
#4  0x0000000000401d05 in submit_headers_to_stream (s=0x7fffe76e2210) at
vcut.c:199
#5  open_output_stream (s=0x7fffe76e2210) at vcut.c:247
#6  write_packet (s=s@entry=0x7fffe76e2210, packet=packet@entry=0x7fffe76e2150)
at vcut.c:483
#7  0x000000000040215a in process_audio_packet (s=s@entry=0x7fffe76e2210,
vs=vs@entry=0x7fffe76e2258, packet=0x7fffe76e2150) at vcut.c:464
#8  0x0000000000402503 in process_page (s=s@entry=0x7fffe76e2210,
page=page@entry=0x7fffe76e21c0) at vcut.c:586
#9  0x000000000040272b in vcut_process (s=s@entry=0x7fffe76e2210) at vcut.c:618
#10 0x0000000000401688 in main (argc=<optimized out>, argv=0x7fffe76e28c8) at
vcut.c:312

Reproducible: Always

Steps to Reproduce:
Run vcut on any Ogg Vorbis file, with any parameters.
Actual Results:
Segmentation fault

Expected Results:
Split Ogg Vorbis file

I can reproduce on a second machine so it's not a local issue.

summary: vcut crashes with segmentation fault


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

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

           Summary: virt-v2v build fails due to META.yml not being created
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 201407*
          Platform: x86-64
        OS/Version: openSUSE 13.2
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Other
        AssignedTo: mlatimer-at-suse.com
        ReportedBy: mlatimer-at-suse.com
         QAContact: qa-bugs-at-suse.de
          Found By: Development
           Blocker: ---

virt-v2v is failing to build, as shown in the following build log snippet:

[   84s] Creating p2v/image-builder/version.ks
[   84s] sh: autoreconf: command not found
[   85s] t/001-pod.t ........... ok
[   86s] t/002-pod-coverage.t .. ok
[   86s] Module::Build will be removed from the Perl core distribution in the
next major release. Please install it from CPAN. It is being used at
t/003-syntax.t, line 24.
[   87s] t/003-syntax.t ........ ok
[   87s] t/004-ExecHelper.t .... ok
[   87s] All tests successful.
[   87s] Files=4, Tests=64,  3 wallclock secs ( 0.12 usr  0.03 sys +  2.64 cusr
 0.28 csys =  3.07 CPU)
[   87s] Result: PASS
[   87s] + exit 0
[   87s] Processing files: virt-v2v-0.9.1-14.2.x86_64
[   87s] Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.ifjRFv
[   87s] + umask 022
[   87s] + cd /home/abuild/rpmbuild/BUILD
[   87s] + cd virt-v2v-0.9.1
[   87s] +
DOCDIR=/home/abuild/rpmbuild/BUILDROOT/virt-v2v-0.9.1-14.2.x86_64/usr/share/doc/packages/virt-v2v
[   87s] + export DOCDIR
[   87s] + /usr/bin/mkdir -p
/home/abuild/rpmbuild/BUILDROOT/virt-v2v-0.9.1-14.2.x86_64/usr/share/doc/packages/virt-v2v
[   87s] + cp -pr TODO.txt
/home/abuild/rpmbuild/BUILDROOT/virt-v2v-0.9.1-14.2.x86_64/usr/share/doc/packages/virt-v2v
[   87s] + cp -pr META.yml
/home/abuild/rpmbuild/BUILDROOT/virt-v2v-0.9.1-14.2.x86_64/usr/share/doc/packages/virt-v2v
[   87s] cp: cannot stat 'META.yml': No such file or directory
[   87s] error: Bad exit status from /var/tmp/rpm-tmp.ifjRFv (%doc)
[   87s]
[   87s]
[   87s] RPM build errors:
[   87s]     Bad exit status from /var/tmp/rpm-tmp.ifjRFv (%doc)

The problem is that META.yml is not being created during the build process.


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

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

           Summary: MariaDB config files not seen by Unix non-root users. Permission Problem in Package
    Classification: openSUSE
           Product: openSUSE 13.1
           Version: Final
          Platform: x86-64
        OS/Version: openSUSE 13.1
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Other
        AssignedTo: bnc-team-screening-at-forge.provo.novell.com
        ReportedBy: drankinatty-at-suddenlinkmail.com
         QAContact: qa-bugs-at-suse.de
          Found By: ---
           Blocker: ---

After trying to determine why mysql (MariaDB) /etc/my.cnf settings are only
seen in mysql is run by unix root user, I've stumbled on to a permission
problem with the mariadb package for 13.1 that makes NO sense at all. The
problem with normal unix users not getting the system-wide setting in
/etc/my.cnf is because /etc/my.cnf cannot be read by normal users. That's nuts.
In fact, the whole system-wide conf scheme for mysql can only be read by 'root'
or members of the 'mysql' group. Specifically:

 # l /etc/my.cnf
-rw-r---


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

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

           Summary: git-review -s problem on non-english locale
    Classification: openSUSE
           Product: openSUSE 12.3
           Version: Final
          Platform: All
        OS/Version: openSUSE 12.3
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Other
        AssignedTo: bwiedemann-at-suse.com
        ReportedBy: bwiedemann-at-suse.com
         QAContact: qa-bugs-at-suse.de
                CC: maintenance-at-opensuse.org
          Found By: Development
           Blocker: ---

git-review -s
is parsing git output, which fails in non-english locales such as
LANG=de_DE.utf8
in a way that is not easy to diagnose.

This is fixed in git-review-1.24
as found in the devel:languages:python repo

Because this bug can be quite frustrating
I'd like to do a maintenance-update for 12.3 and 13.1
and might need some help with the setup,
because 12.3 is still using the python-git-review package name


body:
According to the manual page the compiled in load limit for atd is 0.8. Thus,
no at-job will be started if the system load exceeds 0.8.
Unfortunately in Linux the system load is not the average, but the sum of all
processors' loads. That way for a 10-CPU-system each CPU may only be loaded
0.08 at most to keep the overall load below 0.8.
To summarize: For multi-core or multi-thread systems the default load limit in
atd and /etc/sysconfig/atd is too low. The limit should be based on the number
of CPUs (cores, threads) in the system.

Reproducible: Always

Steps to Reproduce:
1. Have a system with (let's say) 6 cores (12 threads, it's Intel)
2. (The system has a load of 2.4)
3. You start an batch-job (at-job)
Actual Results:
at -l shows the job, meaning it's not done
Looking for the job in the process list, you cannot find it

Expected Results:
The job should be started

Workaround was "atd -s -l 4" (run once with a load limit of 4)

summary: default load limit for atd is obsolete (too low)


body:
libmtdev-devel is required for multitouch support

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

missing multitouch support for touchscreens is also mentioned in bnc#859804

summary: xf86-input-evdev is compiled without multitouch support


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

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

           Summary: [PATCH] build-compare: Remove numbered anchors from all Docbook / HTML files
    Classification: openSUSE
           Product: openSUSE.org
           Version: unspecified
          Platform: Other
               URL: https://pmbs.links2linux.de/package/show/Essentials/bu
                    ild-compare
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: 3rd party software
        AssignedTo: coolo-at-suse.com
        ReportedBy: johannesobermayr-at-gmx.de
         QAContact: opensuse-communityscreening-at-forge.provo.novell.com
                CC: adrian-at-suse.com, aj-at-suse.com
          Found By: ---
           Blocker: ---

See now same result:
https://pmbs.links2linux.de/package/live_build_log/Multimedia/kid3/openSUSE=
_13.1/x86_64
-

Synchronisierter Text und
Ereignis-Zeitcodes

+

Synchronisierter Text und
Ereignis-Zeitcodes

Productive on:
https://pmbs.links2linux.de/package/show/Essentials/build-compare

Index: build-compare.changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-


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

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

           Summary: systemctl enable display-manager.service fails
    Classification: openSUSE
           Product: openSUSE Factory
           Version: 201408*
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: X.Org
        AssignedTo: bnc-team-xorg-bugs-at-forge.provo.novell.com
        ReportedBy: jeffm-at-suse.com
         QAContact: xorg-maintainer-bugs-at-forge.provo.novell.com
          Found By: Development
           Blocker: ---

While trying to use 'yast remote', I got an error saying that display-manager
couldn't be enabled.

That led me to this snippet:
[Ruby] yast2/systemd_unit.rb:125 `systemctl enable display-manager.service `
ShellCommand.cc(shellcommand):78 Failed to execute operation: No such file or
directory

Running the command manually, I see:

sled1:/home/jeffm # systemctl enable display-manager.service
Failed to execute operation: No such file or directory

Inside display-manager.service, I see:
Also: xdm.service

... but xdm.service isn't offered anywhere.

Commenting out that rule eliminates the error but I'm not sure if there are
other side effects.


body:
From https://code.google.com/p/serf/source/detail?r=2392

> Deal with NUL bytes in fields of an X.509 cert.
>
> * buckets/ssl_buckets.c:
>   (pstrdup_escape_nul_bytes, get_subject_alt_names, validate_cert_hostname):
>     New functions.
>   (validate_server_certificate): Use validate_cert_hostname() to return
>     SERF_SSL_CERT_INVALID_HOST if CommonName or SubjectAltNames include a
>     NUL byte.
>   (convert_X509_NAME_to_table): Use pstrdup_escape_nul_bytes() to escape
>     NUL bytes before adding fields to the hash table.
>   (serf_ssl_cert_certificate): Replace some code with a call to
>     get_subject_alt_names() where we factored out the code to.
>
> * serf_bucket_types.h
>   (SERF_SSL_CERT_INVALID_HOST): New error.

Reads like this may similar to CVE-2009-2408, e.g. \0 bytes in certificates
would allow MITM attacks. CWE-297?

> openssl x509 -in test/certs/servercert_cnsan_nul.pem -text -noout
> [...]
> Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=www.example.net\x00.example.com
> [...]

Change will be part of serf 1.3.7 scheduled for 2014-08-11.

openSUSE 13.1: libserf-1-1 (serf) 1.3.6
openSUSE 12.3: libserf-1-0 (serf) 1.1.1

Reproducible: Didn't try

summary: serf handling of NUL bytes in fields of an X.509 cert


body:
This is annoying.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

summary: xscreensaver (5.22) displays a nag-screen to update it


body:
Selecting the help -> symbols option in the yast2 package manager menu shows a
list of all possible package states (installed, uninstalled, auto install and
so on) next to its indicator symbol. But in openSUSE 13.1 (final, not factory!)
at least in the english and german versions (or language settings) the symbols
are all missing (it is a placeholder shown instead for each symbol)!

This is confirmed by a view other people in the opensuse forum:
https://forums.opensuse.org/showthread.php/500114-Yast2-Package-Manager-package-symbols-not-loaded-in-help

here is a screenshot of the situation (is for the german version but the
problem occurs in the english version too!):
http://postimg.org/image/z2upu1ggb/

Reproducible: Always

Steps to Reproduce:
0. boot openSUSE 13.1 (final, not factory)
1. open the package manager (add, remove software)
2. click on help
3. click on symbols
Actual Results:
You can see that the symbols are missing.

Expected Results:
Showing the package state indication symbols. The purpose of the symbols help
is to explain what the symbols stand for, but that is not achieved when the
symbols are not shown.

summary: package manager symbols missing in help window


body:
When attempting to set up DHCPD to enable dynamic DNS updates, the daemon
complains about not being able to set up a tsec structure.
The only algorithm that seems to be supported, though, is HMAC-MD5.

Adding any zones under these circumstances causes DHCPD to refuse to start up.

Reproducible: Always

Steps to Reproduce:
1. Generate a DNSSEC key with any of the HMAC-SHA algorithms
2. Configure BIND for dynamic zone updates
3. Configure DHCPD for dynamic zone updates, but without any zones so far
(should still start up to here)
4. Add zones for dynamic updates

Actual Results:
DHCPD complains when attempting to set up zones for DDNS and algorithm that
isn't HMAC-MD5 is used because of the rejected tsec structure.

Expected Results:
Set up the zones normally and do dynamic DNS updates whenever a lease is
requested

One can work around this problem by using HMAC-MD5 instead, but for obvious
reasons this should be avoided.

summary: DHCPD (dynamic DNS): HMAC-SHA{1|224|256|384|512} not supported by DHCPD


body:
Hi,

2 years ago I updated the pt_BR dictionary in myspell, and looking to see if it
need some update today I found that you rework the myspell-dictionary packages
in a better way!

In the meantime the pt_BR version gets an grammar checker using Lightproof
which is present on the pt_BR subfolder in dictionaries.tar.xz
package(L:O:Factory), but this doesn't apper on LibreOffice. If I download the
pt_BR package by hand on LO site, the gramar check is installed.

What is missing in LO package on openSUSE to get it working?

Regards

Reproducible: Always

summary: the grammar checker in myspell-pt_BR is not working