[opensuse-factory] New Tumbleweed snapshot 20160714 released!
Please note that this mail was generated by a script.
The described changes are computed based on the x86_64 DVD.
The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading:
https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&version=Tumbleweed&build=20160714
Packages changed:
Mesa (12.0.0 -> 12.0.1)
crash
google-croscore-fonts
java-1_8_0-openjdk
kiwi (7.03.72 -> 7.03.77)
libappindicator
libsmbios (2.2.28 -> 2.3.0)
libspectre (0.2.7 -> 0.2.8)
libthai (0.1.24 -> 0.1.25)
libvirt (1.3.5 -> 2.0.0)
libvirt-python (1.3.5 -> 2.0.0)
poppler (0.44.0 -> 0.45.0)
poppler-qt (0.44.0 -> 0.45.0)
poppler-qt5 (0.44.0 -> 0.45.0)
python-setuptools (20.2.2 -> 23.1.0)
qemu
squid (3.5.19 -> 3.5.20)
tomcat (8.0.33 -> 8.0.36)
xf86-video-mga
xf86-video-vesa
yast2-auth-client (3.3.7 -> 3.3.8)
=== Details ===
==== Mesa ====
Version update (12.0.0 -> 12.0.1)
Subpackages: Mesa-devel Mesa-dri-devel Mesa-libEGL-devel Mesa-libEGL1 Mesa-libEGL1-32bit Mesa-libGL-devel Mesa-libGL1 Mesa-libGLESv1_CM-devel Mesa-libGLESv1_CM1 Mesa-libGLESv2-2 Mesa-libGLESv2-devel Mesa-libglapi-devel Mesa-libglapi0 Mesa-libglapi0-32bit Mesa-libva libOSMesa-devel libOSMesa9 libOSMesa9-32bit libgbm-devel libgbm1 libgbm1-32bit libvdpau_nouveau libvdpau_r300 libvdpau_r600 libvdpau_radeonsi libvulkan_intel libwayland-egl-devel libwayland-egl1 libxatracker2
- update to 12.0.1
* Vulkan driver for Intel hardware from Ivy Bridge onward.
* OpenGL 4.3 for nvc0, radeonsi and i965 (Gen8+)
* OpenGL ES 3.1 on nvc0 and radeonsi
* DRI3 enablement for VDPAU, OMX and VAAPI
- Fix Group tag.
==== crash ====
- crash-kernel-4.7.patch:
support 4.7 kernel (page._count renamed to page._refcount)
==== google-croscore-fonts ====
Subpackages: google-arimo-fonts google-cousine-fonts google-symbolneu-fonts google-tinos-fonts
- Ensure prereq fonts macros are called in subpackages and not in
main package.
==== java-1_8_0-openjdk ====
Subpackages: java-1_8_0-openjdk-devel java-1_8_0-openjdk-headless
- Fix script linking /usr/share/javazi/tzdb.dat for platform where
it applies (bsc#987895)
- Enable SunEC for SLE12 and Leap
==== kiwi ====
Version update (7.03.72 -> 7.03.77)
Subpackages: kiwi-desc-isoboot kiwi-desc-netboot kiwi-desc-oemboot kiwi-desc-vmxboot kiwi-doc kiwi-media-requires kiwi-pxeboot kiwi-templates kiwi-tools
- v7.03.77 released
- Fix potential timing issue after vgchange
After activation of the volume group with vgchange an
udev wait until the volume device nodes exists should
be performed
- v7.03.76 released
- Fixed zipl installation
prior to the zipl installation some parameters are read from the
disk file. kiwi ran another loopsetup call on the raw disk file
to get those values. However while the raw disk is already loop
setup by another loop device this causes problems when calling
fdasd on the new loop. This patch prevents another loopsetup call
and operates on the given block device
- v7.03.75 released
- Don't run updateMTAB on RHEL6 systems
RHEL6 doesn't have /etc/mtab as a link. Let's keep original behaviour
Signed-off-by: Dinar Valeev
* Dominique Leuenberger
Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&version=Tumbleweed&build=20160714
Packages changed: Mesa (12.0.0 -> 12.0.1) crash google-croscore-fonts java-1_8_0-openjdk kiwi (7.03.72 -> 7.03.77) libappindicator libsmbios (2.2.28 -> 2.3.0) libspectre (0.2.7 -> 0.2.8) libthai (0.1.24 -> 0.1.25) libvirt (1.3.5 -> 2.0.0) libvirt-python (1.3.5 -> 2.0.0) poppler (0.44.0 -> 0.45.0) poppler-qt (0.44.0 -> 0.45.0) poppler-qt5 (0.44.0 -> 0.45.0) python-setuptools (20.2.2 -> 23.1.0) qemu squid (3.5.19 -> 3.5.20) tomcat (8.0.33 -> 8.0.36) xf86-video-mga xf86-video-vesa yast2-auth-client (3.3.7 -> 3.3.8)
Computing upgrade... The following 6 NEW packages are going to be installed: firebird 3.0.0.32483-1.1 kernel-default 4.6.3-1.3 libfbclient2 3.0.0.32483-1.1 libib_util 3.0.0.32483-1.1 libpoppler62 0.45.0-1.1 libtommath1 1.0-2.1 This "announcement" is incorrect, firebird is not installed presently and "zypper dup" is not installing it in spite of the declaration. ??? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, 15 July 2016 14:24:52 BST Patrick Shanahan wrote:
* Dominique Leuenberger
[07-15-16 12:54]: Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versi on=Tumbleweed&build=20160714> Packages changed: Mesa (12.0.0 -> 12.0.1) crash google-croscore-fonts java-1_8_0-openjdk kiwi (7.03.72 -> 7.03.77) libappindicator libsmbios (2.2.28 -> 2.3.0) libspectre (0.2.7 -> 0.2.8) libthai (0.1.24 -> 0.1.25) libvirt (1.3.5 -> 2.0.0) libvirt-python (1.3.5 -> 2.0.0) poppler (0.44.0 -> 0.45.0) poppler-qt (0.44.0 -> 0.45.0) poppler-qt5 (0.44.0 -> 0.45.0) python-setuptools (20.2.2 -> 23.1.0) qemu squid (3.5.19 -> 3.5.20) tomcat (8.0.33 -> 8.0.36) xf86-video-mga xf86-video-vesa yast2-auth-client (3.3.7 -> 3.3.8)
Computing upgrade...
The following 6 NEW packages are going to be installed: firebird 3.0.0.32483-1.1 kernel-default 4.6.3-1.3 libfbclient2 3.0.0.32483-1.1 libib_util 3.0.0.32483-1.1 libpoppler62 0.45.0-1.1 libtommath1 1.0-2.1
This "announcement" is incorrect, firebird is not installed presently and "zypper dup" is not installing it in spite of the declaration.
???
tks, I just noticed that firebird and kernel-default install on my system, not sure about the others via zypper dup
-- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160712) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, 15 July 2016 18:53:00 BST Dominique Leuenberger wrote:
Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&version =Tumbleweed&build=20160714
Packages changed: Mesa (12.0.0 -> 12.0.1) crash google-croscore-fonts java-1_8_0-openjdk kiwi (7.03.72 -> 7.03.77) libappindicator libsmbios (2.2.28 -> 2.3.0) libspectre (0.2.7 -> 0.2.8) libthai (0.1.24 -> 0.1.25) libvirt (1.3.5 -> 2.0.0) libvirt-python (1.3.5 -> 2.0.0) poppler (0.44.0 -> 0.45.0) poppler-qt (0.44.0 -> 0.45.0) poppler-qt5 (0.44.0 -> 0.45.0) python-setuptools (20.2.2 -> 23.1.0) qemu squid (3.5.19 -> 3.5.20) tomcat (8.0.33 -> 8.0.36) xf86-video-mga xf86-video-vesa yast2-auth-client (3.3.7 -> 3.3.8)
=== Details ===
==== Mesa ==== Version update (12.0.0 -> 12.0.1) Subpackages: Mesa-devel Mesa-dri-devel Mesa-libEGL-devel Mesa-libEGL1 Mesa-libEGL1-32bit Mesa-libGL-devel Mesa-libGL1 Mesa-libGLESv1_CM-devel Mesa-libGLESv1_CM1 Mesa-libGLESv2-2 Mesa-libGLESv2-devel Mesa-libglapi-devel Mesa-libglapi0 Mesa-libglapi0-32bit Mesa-libva libOSMesa-devel libOSMesa9 libOSMesa9-32bit libgbm-devel libgbm1 libgbm1-32bit libvdpau_nouveau libvdpau_r300 libvdpau_r600 libvdpau_radeonsi libvulkan_intel libwayland-egl-devel libwayland-egl1 libxatracker2
- update to 12.0.1 * Vulkan driver for Intel hardware from Ivy Bridge onward. * OpenGL 4.3 for nvc0, radeonsi and i965 (Gen8+) * OpenGL ES 3.1 on nvc0 and radeonsi * DRI3 enablement for VDPAU, OMX and VAAPI - Fix Group tag.
==== crash ====
- crash-kernel-4.7.patch: support 4.7 kernel (page._count renamed to page._refcount)
==== google-croscore-fonts ==== Subpackages: google-arimo-fonts google-cousine-fonts google-symbolneu-fonts google-tinos-fonts
- Ensure prereq fonts macros are called in subpackages and not in main package.
==== java-1_8_0-openjdk ==== Subpackages: java-1_8_0-openjdk-devel java-1_8_0-openjdk-headless
- Fix script linking /usr/share/javazi/tzdb.dat for platform where it applies (bsc#987895) - Enable SunEC for SLE12 and Leap
==== kiwi ==== Version update (7.03.72 -> 7.03.77) Subpackages: kiwi-desc-isoboot kiwi-desc-netboot kiwi-desc-oemboot kiwi-desc-vmxboot kiwi-doc kiwi-media-requires kiwi-pxeboot kiwi-templates kiwi-tools
- v7.03.77 released - Fix potential timing issue after vgchange After activation of the volume group with vgchange an udev wait until the volume device nodes exists should be performed - v7.03.76 released - Fixed zipl installation prior to the zipl installation some parameters are read from the disk file. kiwi ran another loopsetup call on the raw disk file to get those values. However while the raw disk is already loop setup by another loop device this causes problems when calling fdasd on the new loop. This patch prevents another loopsetup call and operates on the given block device - v7.03.75 released - Don't run updateMTAB on RHEL6 systems RHEL6 doesn't have /etc/mtab as a link. Let's keep original behaviour Signed-off-by: Dinar Valeev
- Fix RHEL6 bootloader install RHEL expects /etc/grub.conf to be a symlink to /boot/grub/grub.conf, lets fix a condition where we enter that specific path. Signed-off-by: Dinar Valeev - v7.03.74 released - Fixed creation of install stick The bind mountpoint boot directory needs to be created It's not enough to assume the boot mount point exists in any case. - Fixed setup of container configuration An empty fstab file is created, the former deletion of a potentially existing fstab failed if no such file existed - v7.03.73 released - Make sure package cache dir is managed Fix spec file to create and manage /var/cache/kiwi/packages - Translated using Weblate (Chinese (China)) Currently translated at 100.0% (28 of 28 strings) - Translated using Weblate (Chinese (China)) Currently translated at 100.0% (28 of 28 strings) ==== libappindicator ==== Subpackages: libappindicator3-1 typelib-1_0-AppIndicator3-0_1
- Allow building with mono support in case without mono is set
==== libsmbios ==== Version update (2.2.28 -> 2.3.0) Subpackages: libsmbios2 python-smbios smbios-utils-python
- Update to latest version 2.3.0 supporting smbios 3.0 - Remove old compatibility binaries
==== libspectre ==== Version update (0.2.7 -> 0.2.8) Subpackages: libspectre-devel libspectre1
- Update to version to version 0.2.8: + Fixed the document rotation with newer versions of Ghostscript (fdo#76450). + Build was also broken with Ghostscript >= 9.18 and has been fixed. + Fixed a compile warning due to a comparison of integers of different signs when building on OS X (fdo#56476). + Makefiles were updated to properly use CPPFLAGS instead of CFLAGS (fdo#56481). - Drop libspectre-gs-9.18.patch and libspectre-rotate-documents-correctly.patch: Fixed upstream. - Drop zypper BuildRequires: It was only needed for above patches.
==== libthai ==== Version update (0.1.24 -> 0.1.25) Subpackages: libthai-data libthai0 libthai0-32bit
- Update to version 0.1.25: + New word break APIs for more thread-safety. + Fix compilation error and warning with GCC 6. + Do not test word breaking if dictionary is disabled. + Updated word break dictionary.
==== libvirt ==== Version update (1.3.5 -> 2.0.0) Subpackages: libvirt-client libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-interface libvirt-daemon-driver-libxl libvirt-daemon-driver-lxc libvirt-daemon-driver-network libvirt-daemon-driver-nodedev libvirt-daemon-driver-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-driver-secret libvirt-daemon-driver-storage libvirt-daemon-driver-uml libvirt-daemon-driver-vbox libvirt-daemon-lxc libvirt-daemon-qemu libvirt-daemon-xen
- systemd: fix ready notification on abstract socket c8f08e48-systemd-notify-fix.patch boo#987668 - Update to libvirt 2.0.0 - Change version scheme to match libvirt's time-driven release schedule. <major> will be incremented on first release of new calendar year, <minor> on each monthly release, and <micro> on stable branch maintenance release - Include libvirt-admin utility and API - Many incremental improvements and bug fixes, see http://libvirt.org/news.html - Dropped patches: apparmor-dont-scrub-environment-of-virtlogd-process.patch, e33cd67a-xenconfig-backendtype-fix.patch
==== libvirt-python ==== Version update (1.3.5 -> 2.0.0)
- Update to 2.0.0 - Add all new APIs and constants in libvirt 2.0.0
==== poppler ==== Version update (0.44.0 -> 0.45.0) Subpackages: libpoppler-cpp0 libpoppler-devel libpoppler-glib8 poppler-tools
- Qt 5.7 needs gnu++11 standard, export the appropriate flag in spec when compiler doesn't enforce it by default. - Update to version 0.45.0: + core: - SplashOutputDev: Fix iccTransform + splashModeXBGR8. - Fix memory leaks. - Fix crash in broken files (fdo#95567, fdo#96027). - Emulate some non portable glibc functions when not available. + utils: - pdftohtml: Fix crash in broken files (fdo#95563). - pdfinfo: . Convert dates to local time zone. . Add -isodates for printing dates in ISO-8601 format. . Fix memory leaks. + glib: Return date in UTC instead of local time (fdo#94173). + cpp: Switched from detail::convert_date() to core's dateStringToTime(). - Bump soname following upstream changes. - Drop poppler-Fix-mem-leak-SplashgouraudTriangleShadedFill.patch: Fix upstream.
==== poppler-qt ==== Version update (0.44.0 -> 0.45.0)
- Qt 5.7 needs gnu++11 standard, export the appropriate flag in spec when compiler doesn't enforce it by default. - Update to version 0.45.0: + core: - SplashOutputDev: Fix iccTransform + splashModeXBGR8. - Fix memory leaks. - Fix crash in broken files (fdo#95567, fdo#96027). - Emulate some non portable glibc functions when not available. + utils: - pdftohtml: Fix crash in broken files (fdo#95563). - pdfinfo: . Convert dates to local time zone. . Add -isodates for printing dates in ISO-8601 format. . Fix memory leaks. + glib: Return date in UTC instead of local time (fdo#94173). + cpp: Switched from detail::convert_date() to core's dateStringToTime(). - Bump soname following upstream changes. - Drop poppler-Fix-mem-leak-SplashgouraudTriangleShadedFill.patch: Fix upstream.
==== poppler-qt5 ==== Version update (0.44.0 -> 0.45.0) Subpackages: libpoppler-qt5-1 libpoppler-qt5-devel
- Qt 5.7 needs gnu++11 standard, export the appropriate flag in spec when compiler doesn't enforce it by default. - Update to version 0.45.0: + core: - SplashOutputDev: Fix iccTransform + splashModeXBGR8. - Fix memory leaks. - Fix crash in broken files (fdo#95567, fdo#96027). - Emulate some non portable glibc functions when not available. + utils: - pdftohtml: Fix crash in broken files (fdo#95563). - pdfinfo: . Convert dates to local time zone. . Add -isodates for printing dates in ISO-8601 format. . Fix memory leaks. + glib: Return date in UTC instead of local time (fdo#94173). + cpp: Switched from detail::convert_date() to core's dateStringToTime(). - Bump soname following upstream changes. - Drop poppler-Fix-mem-leak-SplashgouraudTriangleShadedFill.patch: Fix upstream.
==== python-setuptools ==== Version update (20.2.2 -> 23.1.0)
- Update fix-sle11-test-failure.patch to new line numbers and indentation - Use pypi.io for Source url - update to 23.1.0: * #619: Deprecated ``tag_svn_revision`` distribution option. * #611: Removed ARM executables for CLI and GUI script launchers on Windows. If this was a feature you cared about, please comment in the ticket. * #604: Removed docs building support. The project now relies on documentation hosted at https://setuptools.readthedocs.io/. * #604: Restore repository for upload_docs command to restore publishing of docs during release. * #589: Upload releases to pypi.io using the upload hostname and legacy path. * #589: Releases are now uploaded to pypi.io (Warehouse) even when releases are made on Twine via Travis. * #589: Releases are now uploaded to pypi.io (Warehouse). * #190: On Python 2, if unicode is passed for packages to ``build_py`` command, it will be handled just as with text on Python 3. * #598: Setuptools now lists itself first in the User-Agent for web requests, better following the guidelines in `RFC 7231 https://tools.ietf.org/html/rfc7231#section-5.5.3`_. * Minor fixes to changelog and docs. * #261: Exclude directories when resolving globs in package_data. * #539: In the easy_install get_site_dirs, honor all paths found in ``site.getsitepackages``. * #572: In build_ext, now always import ``_CONFIG_VARS`` from ``distutils`` rather than from ``sysconfig`` to allow ``distutils.sysconfig.customize_compiler`` configure the OS X compiler for ``-dynamiclib``. * Removed ez_setup.py from Setuptools sdist. The bootstrap script will be maintained in its own branch and should be generally be retrieved from its canonical location at https://bootstrap.pypa.io/ez_setup.py. * #553: egg_info section is now generated in a deterministic order, matching the order generated by earlier versions of Python. Except on Python 2.6, order is preserved when existing settings are present. * #556: Update to Packaging 16.7, restoring support for deprecated ``python_implmentation`` marker. * #555: Upload command now prompts for a password when uploading to PyPI (or other repository) if no password is present in .pypirc or in the keyring. * #548: Update certify version to 2016.2.28 * #545: Safely handle deletion of non-zip eggs in rotate command. * Issue #544: Fix issue with extra environment marker processing in WorkingSet due to refactor in v20.7.0. * Issue #543: Re-release so that latest release doesn't cause d�j� vu with distribute and setuptools 0.7 in older environments. * Refactored extra enviroment marker processing in WorkingSet. * Issue #533: Fixed intermittent test failures. * Issue #536: In msvc9_support, trap additional exceptions that might occur when importing ``distutils.msvc9compiler`` in mingw environments. * Issue #537: Provide better context when package metadata fails to decode in UTF-8. * Issue #523: Restored support for environment markers, now honoring 'extra' environment markers. * Issue #523: Disabled support for environment markers introduced in v20.5. * Issue #503: Restore support for PEP 345 environment markers by updating to Packaging 16.6. * New release process that relies on `bumpversion https://github.com/peritus/bumpversion`_ and Travis CI for continuous deployment. * Project versioning semantics now follow `semver https://semver.org`_ precisely. The 'v' prefix on version numbers now also allows version numbers to be referenced in the changelog, e.g. https://pythonhosted.org/setuptools/history.html#v20-6-0. * BB Pull Request #185, #470: Add support for environment markers in requirements in install_requires, setup_requires, tests_require as well as adding a test for the existing extra_requires machinery. * Issue #422: Moved hosting to `Github https://github.com/pypa/setuptools`_ from `Bitbucket https://bitbucket.org/pypa/setuptools`_. Issues have been migrated, though all issues and comments are attributed to bb-migration. So if you have a particular issue or issues to which you've been subscribed, you will want to "watch" the equivalent issue in Github. The Bitbucket project will be retained for the indefinite future, but Github now hosts the canonical project repository. * Issue #519: Remove import hook when reloading the ``pkg_resources`` module. * BB Pull Request #184: Update documentation in ``pkg_resources`` around new ``Requirement`` implementation. * BB Pull Request #179: ``pkg_resources.Requirement`` objects are now a subclass of ``packaging.requirements.Requirement``, allowing any environment markers and url (if any) to be affiliated with the requirement * BB Pull Request #179: Restore use of RequirementParseError exception unintentionally dropped in 20.2.
==== qemu ==== Subpackages: qemu-arm qemu-block-curl qemu-block-dmg qemu-block-gluster qemu-block-iscsi qemu-block-ssh qemu-extra qemu-ipxe qemu-ksm qemu-kvm qemu-lang qemu-ppc qemu-s390 qemu-seabios qemu-sgabios qemu-tools qemu-vgabios qemu-x86
- Fix OVMF iPXE network menu (bsc#986033, boo#987488) ipxe-efi-fix-garbage-bytes-in-device-path.patch ipxe-efi-fix-uninitialised-data-in-HII.patch
==== squid ==== Version update (3.5.19 -> 3.5.20)
- Update to version 3.5.20: * Assertion failed: Write.cc:38: "fd_table[conn->fd].flags.open" * Bug #4523: smblib compile fails on NetBSD * Do not make bogus recvmsg(2) calls when closing UDS sockets. * Fix SEGFAULT parsing malformed adaptation service configuration * Fixed ConnStateData::In::maybeMakeSpaceAvailable() logic. * Bug #3579: assertion failed 'MemPools[type]' from dst_as ACL * SourceFormat Enforcement * Do not allow low-level debugging to hide important/critical messages. * Bug #4485: off-by-one out-of-bounds Parser::Tokenizer::int64() read errors * Increase debug level in a peek-and-splice related debug message * Fix icons loading speed. * Fix OpenSSL detection on FreeBSD * Do not override user defined -std option * SourceFormat Enforcement * Support unified EUI format code in external_acl_type
==== tomcat ==== Version update (8.0.33 -> 8.0.36) Subpackages: tomcat-admin-webapps tomcat-el-3_0-api tomcat-jsp-2_3-api tomcat-lib tomcat-servlet-3_1-api tomcat-webapps
- Version update to 8.0.36: * Another bugfix release for the 8.0 series. Full details:
http://tomcat.apache.org/tomcat-8.0-doc/changelog.html#Tomcat_8.0.36_(markt ) - CVE fixed by the version update: - CVE-2016-3092 (bnc#986359) - Fixed a deployment error in the examples webapp by changing the context.xml format to the new one introduced by Tomcat 8. See http://tomcat.apache.org/migration-8.html#Web_application_resources
==== xf86-video-mga ====
- u_shadow-Calulate-the-shadow-buffer-size-correctly.patch * Calculate the shadow buffer size correctly to avoid the screen being cut off (boo#987670).
==== xf86-video-vesa ====
- u_DPMS-Check-for-broken-DPMSGet.patch Check for broken DPMSGet (bsc#986974).
==== yast2-auth-client ==== Version update (3.3.7 -> 3.3.8)
- Fix bsc#986281: * Support importing configuration from legacy XML. * Always install sssd-tools. * Allow customising homedir override in domains. * Fix exceptions caused by missing dependencies at runtime. Bump version to 3.3.8.
Just noticed that the "zypper dup" process removes the old kernel before its successfully installed the new one - is this a good idea or am i misinterpreting it? -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160712) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/15/2016 03:29 PM, ianseeks wrote:
Just noticed that the "zypper dup" process removes the old kernel before its successfully installed the new one - is this a good idea or am i misinterpreting it?
I noticed the same thing even though I have multiversion enabled. -- Ken linux since 1994 S.u.S.E./openSUSE since 1996 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 16 Jul 2016 19:12, Ken Schneider wrote:
On 07/15/2016 03:29 PM, ianseeks wrote:
Just noticed that the "zypper dup" process removes the old kernel before its successfully installed the new one - is this a good idea or am i misinterpreting it?
I noticed the same thing even though I have multiversion enabled.
Well, there are different view points. One of the cases to be handled is "/boot" on its own partition. If this partition is small, an additional kernel coud overfill it, thus the removal of the old kernel befor installing the new kernel makes sense, as long as the kernel to be removed is not the running kernel.
From the "Safety First" viewpoint this (remove old first) is not ideal.
Choose your poision, YMMV. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-07-16 19:31, Yamaban wrote:
On Sat, 16 Jul 2016 19:12, Ken Schneider wrote:
On 07/15/2016 03:29 PM, ianseeks wrote:
Just noticed that the "zypper dup" process removes the old kernel before its successfully installed the new one - is this a good idea or am i misinterpreting it?
I noticed the same thing even though I have multiversion enabled.
Well, there are different view points.
One of the cases to be handled is "/boot" on its own partition. If this partition is small, an additional kernel coud overfill it, thus the removal of the old kernel befor installing the new kernel makes sense, as long as the kernel to be removed is not the running kernel.
If multiversion is enabled, the old one can never be removed. It is a service that runs after boot which clears the kernel before the previous one. This clearing could be modified to run prior to installing the new kernel, but still, the old (running) kernel has to remain. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2016-07-16 20:22 (UTC+0200):
Yamaban wrote:
One of the cases to be handled is "/boot" on its own partition. If this partition is small, an additional kernel coud overfill it, thus the removal of the old kernel befor installing the new kernel makes sense, as long as the kernel to be removed is not the running kernel.
If multiversion is enabled, the old one can never be removed. It is a
Never say never or always. I just did what I interpret your statement to mean six hours ago, and not having anything to do with this thread. WRT https://lists.opensuse.org/opensuse/2016-07/msg00283.html I installed TW's kernel in 42.1 as a troubleshooting step, booted it, then removed it, while running it, without encountering any evidence one way or another WRT your assertion "can never be removed". I suspect package management in TW has not changed materially in this regard since 42.1 release.
service that runs after boot which clears the kernel before the previous one. This clearing could be modified to run prior to installing the new kernel, but still, the old (running) kernel has to remain. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-07-16 20:44, Felix Miata wrote:
Carlos E. R. composed on 2016-07-16 20:22 (UTC+0200):
Yamaban wrote:
One of the cases to be handled is "/boot" on its own partition. If this partition is small, an additional kernel coud overfill it, thus the removal of the old kernel befor installing the new kernel makes sense, as long as the kernel to be removed is not the running kernel.
If multiversion is enabled, the old one can never be removed. It is a
Never say never or always. I just did what I interpret your statement to mean six hours ago, and not having anything to do with this thread. WRT https://lists.opensuse.org/opensuse/2016-07/msg00283.html I installed TW's kernel in 42.1 as a troubleshooting step, booted it, then removed it, while running it, without encountering any evidence one way or another WRT your assertion "can never be removed". I suspect package management in TW has not changed materially in this regard since 42.1 release.
Of course that you can shoot your own foot if you wish. Nothing impedes it. Maybe I should have used a different verb than "can". Andrei has explained why it happens: different build of the same version. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
16.07.2016 20:12, Ken Schneider пишет:
On 07/15/2016 03:29 PM, ianseeks wrote:
Just noticed that the "zypper dup" process removes the old kernel before its successfully installed the new one - is this a good idea or am i misinterpreting it?
I noticed the same thing even though I have multiversion enabled.
It removes different build of the same version. In the past attempt to install such update caused file conflicts. Two kernel RPMs that differ inlyoin build number are identical and cannot be installed side by side. So it can be considered bug fix. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2016-07-16 at 21:38 +0300, Andrei Borzenkov wrote:
It removes different build of the same version. In the past attempt to install such update caused file conflicts. Two kernel RPMs that differ inlyoin build number are identical and cannot be installed side by side. So it can be considered bug fix.
Is it really certain that regressions can't happen if only the build number increases? Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jul 18, 2016 at 10:22 AM, Martin Wilck
On Sat, 2016-07-16 at 21:38 +0300, Andrei Borzenkov wrote:
It removes different build of the same version. In the past attempt to install such update caused file conflicts. Two kernel RPMs that differ inlyoin build number are identical and cannot be installed side by side. So it can be considered bug fix.
Is it really certain that regressions can't happen if only the build number increases?
Well, we had regressions caused by updated compiler. But then you will need to change kernel version scheme to include build number. Until this is done you cannot install two builds in parallel anyway. There was discussion about it but I am not sure whether any definitive conclusion was reached - probably, yes, as we see :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2016-07-18 at 10:37 +0300, Andrei Borzenkov wrote:
Well, we had regressions caused by updated compiler. But then you will need to change kernel version scheme to include build number. Until this is done you cannot install two builds in parallel anyway.
The question that comes to my mind - if it can cause no harm, what possible good it can do? In other words, why is this "build-number- only" update pushed to repos at all? Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On pondělí 18. července 2016 9:42 Martin Wilck wrote:
On Mon, 2016-07-18 at 10:37 +0300, Andrei Borzenkov wrote:
Well, we had regressions caused by updated compiler. But then you will need to change kernel version scheme to include build number. Until this is done you cannot install two builds in parallel anyway.
The question that comes to my mind - if it can cause no harm, what possible good it can do? In other words, why is this "build-number- only" update pushed to repos at all?
These spontaneous rebuilds usually happen when some of the build dependencies changes. For userspace applications, change in a library it's built against can mean significant changes in the resulting binary and its behaviour. For kernel, it's much less likely to happen. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jul 18, Martin Wilck wrote:
Well, we had regressions caused by updated compiler. But then you will need to change kernel version scheme to include build number. Until this is done you cannot install two builds in parallel anyway. The question that comes to my mind - if it can cause no harm, what
On Mon, 2016-07-18 at 10:37 +0300, Andrei Borzenkov wrote: possible good it can do? In other words, why is this "build-number- only" update pushed to repos at all?
Because pkgs which make use of binary signing are not handled by build-compare. As a result pkgs like kernel, xen and kmps get rebuilt and republished all the time. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2016-07-18 at 10:18 +0200, Olaf Hering wrote:
On Mon, Jul 18, Martin Wilck wrote:
Well, we had regressions caused by updated compiler. But then you will need to change kernel version scheme to include build number. Until this is done you cannot install two builds in parallel anyway. The question that comes to my mind - if it can cause no harm, what
On Mon, 2016-07-18 at 10:37 +0300, Andrei Borzenkov wrote: possible good it can do? In other words, why is this "build-number- only" update pushed to repos at all?
Because pkgs which make use of binary signing are not handled by build-compare. As a result pkgs like kernel, xen and kmps get rebuilt and republished all the time.
Well then, summarizing: - build number changes can't be avoided, - regressions caused by build number increases are very unlikely but can't be excluded, - kernels that differ only by build number can't be installed in parallel / multiversion(kernel) isn't functional => regression might result in unbootable system, - the end-user benefit of updating to a kernel with just increased build number is unclear to me. My conclusion would be that users would be well-advised to skip these updates. Martin
Olaf
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
My conclusion would be that users would be well-advised to skip these updates.
your conclusion is wrong
On 18 July 2016 at 12:16, Martin Wilck
On Mon, 2016-07-18 at 10:18 +0200, Olaf Hering wrote:
On Mon, Jul 18, Martin Wilck wrote:
Well, we had regressions caused by updated compiler. But then you will need to change kernel version scheme to include build number. Until this is done you cannot install two builds in parallel anyway. The question that comes to my mind - if it can cause no harm, what
On Mon, 2016-07-18 at 10:37 +0300, Andrei Borzenkov wrote: possible good it can do? In other words, why is this "build-number- only" update pushed to repos at all?
Because pkgs which make use of binary signing are not handled by build-compare. As a result pkgs like kernel, xen and kmps get rebuilt and republished all the time.
Well then, summarizing: - build number changes can't be avoided, - regressions caused by build number increases are very unlikely but can't be excluded, - kernels that differ only by build number can't be installed in parallel / multiversion(kernel) isn't functional => regression might result in unbootable system, - the end-user benefit of updating to a kernel with just increased build number is unclear to me.
My conclusion would be that users would be well-advised to skip these updates.
Martin
Olaf
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2016-07-18 at 13:47 +0200, Ondřej Súkup wrote:
My conclusion would be that users would be well-advised to skip these
updates.
your conclusion is wrong
would you mind to give a reason? Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18.07.2016 16:33, Martin Wilck wrote:
On Mon, 2016-07-18 at 13:47 +0200, Ondřej Súkup wrote:
My conclusion would be that users would be well-advised to skip these
updates.
your conclusion is wrong
would you mind to give a reason?
Martin
Well I can't speak for Ondrej, but your conclusion is based on avoiding hypothetical regressions, which do not seem to be bound to kernel rebuilds, most of your arguments against installation of such kernel updates could be said for any package that is important for booting, yet they are rebuilt and published. Perhaps you might focus more on arguments supporting you advice or refrain from giving such advices in case of lack of said arguments. Cheers Martin
On Mon, 2016-07-18 at 20:23 +0200, Martin Pluskal wrote:
On 18.07.2016 16:33, Martin Wilck wrote:
On Mon, 2016-07-18 at 13:47 +0200, Ondřej Súkup wrote:
My conclusion would be that users would be well-advised to skip these
updates.
your conclusion is wrong
would you mind to give a reason?
Martin
Well I can't speak for Ondrej, but your conclusion is based on avoiding hypothetical regressions, which do not seem to be bound to kernel rebuilds, most of your arguments against installation of such kernel updates could be said for any package that is important for booting, yet they are rebuilt and published.
The kernel is special: multiversion(kernel) exists for a reason, and multiversion(kernel) appears to be non-functional in this specific case. That was my point. Maybe I missed something.
Perhaps you might focus more on arguments supporting you advice or refrain from giving such advices in case of lack of said arguments.
I thought I had presented arguments. You don't have to be convinced. It's true that the risk of a regression is so low that TW users (who live on the edge anyway) don't need to worry. Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The kernel is special: multiversion(kernel) exists for a reason, and multiversion(kernel) appears to be non-functional in this specific case. That was my point. Maybe I missed something.
yes , you missed multiversin IS between version number not release, so on correctly set system are always installed two kernels .. for Tumbleweed now: i | kernel-default | balíček | 4.6.2-1.6 | x86_64 | (system packages) i | kernel-default | balíček | 4.6.3-1.3 | x86_64 | openSUSE-Tumbleweed-Oss
I thought I had presented arguments. You don't have to be convinced. It's true that the risk of a regression is so low that TW users (who live on the edge anyway) don't need to worry.
risk of regression is order lower than problems between keyboard and chair
On 18 July 2016 at 20:37, Martin Wilck
On Mon, 2016-07-18 at 20:23 +0200, Martin Pluskal wrote:
On 18.07.2016 16:33, Martin Wilck wrote:
On Mon, 2016-07-18 at 13:47 +0200, Ondřej Súkup wrote:
My conclusion would be that users would be well-advised to skip these
updates.
your conclusion is wrong
would you mind to give a reason?
Martin
Well I can't speak for Ondrej, but your conclusion is based on avoiding hypothetical regressions, which do not seem to be bound to kernel rebuilds, most of your arguments against installation of such kernel updates could be said for any package that is important for booting, yet they are rebuilt and published.
The kernel is special: multiversion(kernel) exists for a reason, and multiversion(kernel) appears to be non-functional in this specific case. That was my point. Maybe I missed something.
Perhaps you might focus more on arguments supporting you advice or refrain from giving such advices in case of lack of said arguments.
I thought I had presented arguments. You don't have to be convinced. It's true that the risk of a regression is so low that TW users (who live on the edge anyway) don't need to worry.
Martin
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2016-07-18 at 20:57 +0200, Ondřej Súkup wrote:
The kernel is special: multiversion(kernel) exists for a reason, and multiversion(kernel) appears to be non-functional in this specific case. That was my point. Maybe I missed something.
yes , you missed multiversin IS between version number not release, so on correctly set system are always installed two kernels .. for Tumbleweed now: i | kernel-default | balíček | 4.6.2-1.6 | x86_64 | (system packages) i | kernel-default | balíček | 4.6.3-1.3 | x86_64 | openSUSE- Tumbleweed-Oss
You're right, I assumed that the "build number only" update scenario could cause the user to end up with only one (in the worst case, broken) kernel installed. Looking at the docs, I don't know if that would be possible. On my system, as you already said, when installing 4.6.3-1.3, "zypper dup" would remove 4.6.3-1.1 but keep 4.6.2-1.6, so I'd be fine anyway. IOW, my conclusions were premature. Thanks for the explanation. Martin
risk of regression is order lower than problems between keyboard and chair
On 18 July 2016 at 20:37, Martin Wilck
wrote: On Mon, 2016-07-18 at 20:23 +0200, Martin Pluskal wrote:
On 18.07.2016 16:33, Martin Wilck wrote:
On Mon, 2016-07-18 at 13:47 +0200, Ondřej Súkup wrote:
My conclusion would be that users would be well-advised to skip these
updates.
your conclusion is wrong
would you mind to give a reason?
Martin
Well I can't speak for Ondrej, but your conclusion is based on avoiding hypothetical regressions, which do not seem to be bound to kernel rebuilds, most of your arguments against installation of such kernel updates could be said for any package that is important for booting, yet they are rebuilt and published.
The kernel is special: multiversion(kernel) exists for a reason, and multiversion(kernel) appears to be non-functional in this specific case. That was my point. Maybe I missed something.
Perhaps you might focus more on arguments supporting you advice or refrain from giving such advices in case of lack of said arguments.
I thought I had presented arguments. You don't have to be convinced. It's true that the risk of a regression is so low that TW users (who live on the edge anyway) don't need to worry.
Martin
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (13)
-
Andrei Borzenkov
-
Carlos E. R.
-
Dominique Leuenberger
-
Felix Miata
-
ianseeks
-
Ken Schneider
-
Martin Pluskal
-
Martin Wilck
-
Michal Kubecek
-
Olaf Hering
-
Ondřej Súkup
-
Patrick Shanahan
-
Yamaban