January 2017 - openSUSE Factory - openSUSE Mailing Lists

Re: [opensuse-factory] Next snapshot with updated systemd and plymouth
by Robby Engelmann 02 Feb '17

02 Feb '17

Ohh, there are more than that one. I remember, that I also commented on one of these: no graphical input, instead textmode input is shown. The question is, whether these are indeed related... This time, no imput is shown at all (here in approx. 20% of the reboots). Cheers, Robby. -- On Dienstag, 31. Januar 2017 15:55:56 CET Jeroen Mathon wrote: > Hey Robby, > > It seems that Chan Ju Ping also made a bug report in 2016. > > https://bugzilla.opensuse.org/show_bug.cgi?id=997200 > > Perhaps also worth looking at or marking as duplicate to avoid people > recreating the wheel. > > On 31-01-17 15:48, Robby Engelmann wrote: > > You may want to have a look here: > > https://bugzilla.novell.com/show_bug.cgi?id=1020283

19 35

[opensuse-factory] add pam_faillock for factory, 42.2, SLES 12 SP2
by Jason Newton 02 Feb '17

02 Feb '17

I'd consider adding it as an update, too, to 42.1 and SP1, at least in aux repositories - preferably to updates :-). I've spoken with the author of pam_faillock and I believe it to be superior to pam_tally2, particularly concerning handling of screensaver handling. pam_faillock is part of the recommended RHEL configuration for secured computers and holding out for pam_tally2 also presents a nasty non-uniformity for nearly the same functionality (although, weaker). I've asked the author, Tomas Mraz, to make the patch available standalone - which he has provided here: http://people.redhat.com/tmraz/pam_faillock/ I would've have submitted my branch against factory pam incorporating the patch - but unfortunately I seem to be having some automake/libtool issues in the build that I cannot figure out - so I'm going to have to leave that effort to someone who knows those build tools better than I. I also intend to poke upstream to ask them to reconsider adding that patch into master. -Jason -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 7

[opensuse-factory] Tumbleweed on rsync.opensuse.org
by mh＠mike.franken.de 02 Feb '17

02 Feb '17

Hi *, is there any reason, why rsync.opensuse.org::opensuse-full/opensuse/tumbleweed/ does not offer the latest Tumbleweed packages, while I can find them on ftp.gwdg.de::opensuse/tumbleweed/ ?? rsync.opensuse.org latest versions are from 28.12.2016. In the meantime there were lots of new packages. Thx and bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 8

[opensuse-factory] [New Package] GitKraken
by Luke Jones 01 Feb '17

01 Feb '17

Hi all, I was about to submit GitKraken to the devel:tools project where I thought it would fit best - until I saw the mess of licenses this has. I'm unsure of how the licensing (there are a multitude of licenses used due to the number of libraries used) would affect openSUSE. GitKraken itself uses its own license https://www.gitkraken.com/eula Package link: https://build.opensuse.org/package/show/home:luke_nukem/gitkraken If someone more experienced than I, could advise on this, it would be appreciated. On that note, would "packman" be a better place for it to live? Regards, Luke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 4

[opensuse-factory] Next snapshot with updated systemd and plymouth
by Robby Engelmann 01 Feb '17

01 Feb '17

Hi all, openqa seems to be quite satisfied with the new snapshot. On a local test, however, I still get no password prompt in my setup. So will live with plymouth.enable=0 as boot parameter. Cheers, Robby. --

10 17

[opensuse-factory] ANNOUNCE: transactional updates for Tumbleweed
by Thorsten Kukuk 01 Feb '17

01 Feb '17

Hello, I would like to announce a new package in Tumbleweed: "transactional-update". What is this, and why is this from interest for you? Tumbleweed is a rolling release distribution. Which means, even intrusive changes will be applied to a running system, which is in use by the user. For a lot of updates this is no problem, but sometimes there are updates, which make trouble. Only remember the email from Martin Wilk from Jan 16th, 2017: "CAREFUL: New Tumbleweed snapshot 20170112 released!". Or think about the pam-config update last year. For another project I wrote a script updating a distribution in a transactional way. I was asked by many people if I couldn't provide that for Tumbleweed, too. So, here it is. What are transactional updates? A transactioan update: - is atomic - The update does not influence your running system. - It's either successful applied or nothing is changed. So no broken RPMs are flying around in the system. - can be rolled back - if the upgrade fails or if the update is not compatible, you can quickly restore the situation as it was before the upgrade. What do you need to be able to use it? - A recent installation of Tumbleweed (updating from older versions, especially installations made with openSUSE 13.x, will not work) with btrfs and snapshots enabled. If your installation is not recent enough, the script will tell and warn you and refuse to work. How does it work? In short, we create a snapshot of the system, update this snapshot, do a "rollback" (or better "somersault") to this new snapshot and with the next reboot, the updates are there. And if they don't work, boot the old snapshot and continue to work, until the problem is fixed with another update. So, everything is fine? No, it is not. The original project did work with a read-only root filesystem. Which means, after taking the snapshot, the original data couldn't be modified and no data could go lost. With Tumbleweed, all changes you are doing to the root filesystem subvolume after starting the script will be lost with the next reboot into the new snapshot. Which means, after running the script, you should immeaditly reboot to activate the changes and avoid data lossage. Modifications in other subvolumes are fine. Another problem is: we are using snapshots and rollback, so face the same issues as with snapshots and rollback. I have run this script now for three month on a default Tumbleweed installation by cron without any problems. But there are RPMs, which will create problems, and which needs to be adjusted. 1. strictly seperate code from user data. /srv is a real nightmare. Either user data will go lost, or the application will not be updated or rolled back. 2. Don't modify data in post install sections, but during boot or first start instead. If the data is in a subvolume, this one will not be accessible during the upgrade. Or the update wouldn't be atomic anymore. 3. Don't create something outside the snapshot subvolume, this will not survive the next reboot. 4. RPM, which installs directories or data into directories, which are subvolumes, needs to be adjusted. This will not work. Example: /var/cache is an own subvolume. Quite some RPMs create directories and data there, and some of them will stop working if you remove this directories. That's bad even without transactional updates, a system administrator should always be allowed to delete the cache. A better way is to create the directories during boot with tmpfiles.d(5). Same problem for all other subvolumes like /var/log, /var/spool, etc. So, now you can test the script and I hope it is from use for many of you. I'm pretty sure there are still situations which the script cannot handle, and a lot of you have ideas about how to improve it. I'm happy about every patch or idea. And of course adjusted RPMs, which have no problem with this update method. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

17 44

[opensuse-factory] Better joint effect in Leap maintenance
by Marguerite Su 31 Jan '17

31 Jan '17

Hi, Firstly, I know Leap is joint effect. That is, some packages are from SLE and some others are from Factory. Both sides are working great, "separately". Today I just want to talk about some leaf problems. 1. Some packages have different maintainers for the version in Factory and the version in Leap. No explanation. It is the nature of Leap. 2. The maintainers from SLE for Leap is actually unknown from build.opensuse.org eg. I am the maintainer for all the lua versions in openSUSE:Factory, and libplist/libimobiledevice stuff in hardware repository. But I don't know who is the maintainer from SLE counterpart. No one tells me. No where to find. I don't even know SLE has those packages (Because I'm not the target of SLE sales :-D) So, no communication between us, at all. But when users report bug on bugzilla, everything is assigned to me because I am the only person they know. sometimes security leaks too (our security team is brilliant, they care both openSUSE and SLE, but in different bugzilla IDs) I don't even know Leap version is none of my business, at all. (Because of #3) Even if I know, it should be my responsibility to fix it (1. I am the assignee 2. sometimes Factory fixes should go into Leap) To me, it's a brand-new and fresh bug report. It means only one bug report entry, no previous discussions, no re-assign. So I take cares of it, interact with the reporter, preparing fixes for Factory and Leap. I just following the standard procedure for bug fixes. Bang! "Sorry, XXX is from SLE, MR rejected!" This message annoys me because the fixes now look like a waste of my time. I don't know who to talk now. And the maintainer from SUSE doesn't know there's a bug here needed to be fixed by him either. It just leaves there. Let's say, even if it is from SLE, what about a bug fix backported from Factory? By nature, it should be taken care of by Factory maintainers. But you can't touch it at all. Because it will break the "sync" between SLE and Factory. There's only one-way sync: SLE to Factory. And many times, it just vanished after I reassigned it to SLE maintainer. (boo#1010089, boo#988491 and more) because Leap is not their 1st priority, leaving me the person on fire. Can you imagine that a security flaw is known by me for one month but just no way to fix it? This is just the easiest case that I think every maintainer meets. One more thing, things changed in large scale. I have 300+ packages. I have to "beg" SLE maintainers 300+ times to fix something. It will become a great burden. So, here, we eagerly need to develop a common sense/rule that let Factory/SLE maintainers continue to maintain the same package, just like the OBS development procedure that both can submit things. And it should be no email threads involved. That is, if maintenance request gets accepted, the other maintainer will automatically catch up. We don't have to know each other at all. Maintenance team have to judge, based on whether it is a valid fix, instead of whether it comes from the right origin. 3. People don't know which package is from SLE. Release team knows. We don't. Or we can't remember that much even was told. And things just get update, eg in 42.1 some packages are from Factory, in 42.2 they are from SLE because no one from the community actually care it. Or, in 42.1 some packages are from SLE but in 42.2+ they are from Factory because there's a strong reason to switch origin. Currently there's no clear indicator that tells people which package is from SLE in official Leap repositories. You have to test yourself by wasting your time preparing maintenance request to be rejected for it. 4. There is no clear rule to override packages by the one from different origin. In 42.1, I know there's an email sent here, that people who want to override SLE packages can submit directly from openSUSE:Factory to openSUSE:Leap:42.1 But today when you do so, most of the times you will be told "it is from SLE, don't do that". But sometimes things do work. We don't know why. There should be a clear rule for doing this. And both Factory and SLE maintainers should know if he's "still" responsible for that package. Or both sides will not take care of it until told to. Personally I think to expect bug fix from SLE for Leap for leaf packages is kinda like to expect you become a millionaire tomorrow. Plenty of reasons like: * Leap is 2nd class citizen for SLE maintainers. I can say more. but it is true * Bug reports go to community maiintainers who can actually do nothing * SLE maintainers can't follow upstream that tight as 7x24x365 community maintainers because they do need time off work. * One of the dependencies in Leap may be from Factory, so the same problem doesn't get reproduced in SLE * Many others like he doesn't register on bugzilla.opensuse.org, or he left his job and those packages are unmaintained now even they are from SLE Finally, I just want to say, SUSE is great. It let its maintainers do things for openSUSE Factory. So why not let community maintainers help maintaining SLE to some extent, in Leap field that can easily/flawlessly go into SLE? Greetings Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 4

[opensuse-factory] New Tumbleweed snapshot 20170129 released!
by Dominique Leuenberger 31 Jan '17

31 Jan '17

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&versio… When you reply to report some issues, make sure to change the subject. It is not helpful to keep the release announcement subject in a thread while discussing a specific problem. Packages changed: MozillaFirefox (50.1.0 -> 51.0.1) MozillaThunderbird (45.6.0 -> 45.7.0) gcal (4 -> 4.1) glyr gtk4 (3.89.1 -> 3.89.2) iodbc (3.52.10 -> 3.52.12) kernel-source (4.9.5 -> 4.9.6) lightdm (1.21.1 -> 1.21.3) mozilla-nspr (4.12 -> 4.13.1) mozilla-nss (3.26.2 -> 3.28.1) sed (4.2.2 -> 4.3) squid (3.5.22 -> 3.5.23) virt-manager === Details === ==== MozillaFirefox ==== Version update (50.1.0 -> 51.0.1) Subpackages: MozillaFirefox-translations-common - Mozilla Firefox 51.0.1: - Multiprocess incompatibility did not correctly register with some add-ons (bmo#1333423) - update to Firefox 51.0 * requires NSPR >= 4.13.1, NSS >= 3.28.1 * Added support for FLAC (Free Lossless Audio Codec) playback * Added support for WebGL 2 * Added Georgian (ka) and Kabyle (kab) locales * Support saving passwords for forms without 'submit' events * Improved video performance for users without GPU acceleration * Zoom indicator is shown in the URL bar if the zoom level is not at default level * View passwords from the prompt before saving them * Remove Belarusian (be) locale * Use Skia for content rendering (Linux) * MFSA 2017-01 CVE-2017-5375: Excessive JIT code allocation allows bypass of ASLR and DEP (bmo#1325200, boo#1021814) CVE-2017-5376: Use-after-free in XSL (bmo#1311687, boo#1021817) CVE-2017-5377: Memory corruption with transforms to create gradients in Skia (bmo#1306883, boo#1021826) CVE-2017-5378: Pointer and frame data leakage of Javascript objects (bmo#1312001, bmo#1330769, boo#1021818) CVE-2017-5379: Use-after-free in Web Animations (bmo#1309198,boo#1021827) CVE-2017-5380: Potential use-after-free during DOM manipulations (bmo#1322107, boo#1021819) CVE-2017-5390: Insecure communication methods in Developer Tools JSON viewer (bmo#1297361, boo#1021820) CVE-2017-5389: WebExtensions can install additional add-ons via modified host requests (bmo#1308688, boo#1021828) CVE-2017-5396: Use-after-free with Media Decoder (bmo#1329403, boo#1021821) CVE-2017-5381: Certificate Viewer exporting can be used to navigate and save to arbitrary filesystem locations (bmo#1017616, boo#1021830) CVE-2017-5382: Feed preview can expose privileged content errors and exceptions (bmo#1295322, boo#1021831) CVE-2017-5383: Location bar spoofing with unicode characters (bmo#1323338, bmo#1324716, boo#1021822) CVE-2017-5384: Information disclosure via Proxy Auto-Config (PAC) (bmo#1255474, boo#1021832) CVE-2017-5385: Data sent in multipart channels ignores referrer-policy response headers (bmo#1295945, boo#1021833) CVE-2017-5386: WebExtensions can use data: protocol to affect other extensions (bmo#1319070, boo#1021823) CVE-2017-5394: Android location bar spoofing using fullscreen and JavaScript events (bmo#1222798) CVE-2017-5391: Content about: pages can load privileged about: pages (bmo#1309310, boo#1021835) CVE-2017-5392: Weak references using multiple threads on weak proxy objects lead to unsafe memory usage (bmo#1293709) (Android only) CVE-2017-5393: Remove addons.mozilla.org CDN from whitelist for mozAddonManager (bmo#1309282, boo#1021837) CVE-2017-5395: Android location bar spoofing during scrolling (bmo#1293463) (Android only) CVE-2017-5387: Disclosure of local file existence through TRACK tag error messages (bmo#1295023, boo#1021839) CVE-2017-5388: WebRTC can be used to generate a large amount of UDP traffic for DDOS attacks (bmo#1281482, boo#1021840) CVE-2017-5374: Memory safety bugs fixed in Firefox 51 (boo#1021841) CVE-2017-5373: Memory safety bugs fixed in Firefox 51 and Firefox ESR 45.7 (boo#1021824) - switch Firefox to Gtk3 for Tumbleweed - removed obsolete patches * mozilla-flex_buffer_overrun.patch - updated RPM locale support tag - improve recognition of LANGUAGE env variable (boo#1017174) - add upstream patch to fix PPC64LE (bmo#1319389) (mozilla-skia-ppc-endianess.patch) - fix build without skia (big endian archs) (bmo#1319374) (mozilla-disable-skia-be.patch) ==== MozillaThunderbird ==== Version update (45.6.0 -> 45.7.0) Subpackages: MozillaThunderbird-translations-common - update to Thunderbird 45.7.0 * Message preview pane non-functional after IMAP folder was renamed or moved * "Move To" button on "Search Messages" panel not working * Message sent to "undisclosed recipients" shows no recipient (non-functional since Thunderbird version 38) * Security updates from MFSA 2017-03 (Gecko 45.7.0) boo#1021991. In general, these flaws cannot be exploited through email in Thunderbird because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts: CVE-2017-5375: Excessive JIT code allocation allows bypass of ASLR and DEP (bmo#1325200, boo#1021814) CVE-2017-5376: Use-after-free in XSL (bmo#1311687, boo#1021817) CVE-2017-5378: Pointer and frame data leakage of Javascript objects (bmo#1312001, bmo#1330769, boo#1021818) CVE-2017-5380: Potential use-after-free during DOM manipulations (bmo#1322107, boo#1021819) CVE-2017-5390: Insecure communication methods in Developer Tools JSON viewer (bmo#1297361, boo#1021820) CVE-2017-5396: Use-after-free with Media Decoder (bmo#1329403, boo#1021821) CVE-2017-5383: Location bar spoofing with unicode characters (bmo#1323338, bmo#1324716, boo#1021822) CVE-2017-5373: Memory safety bugs fixed in Thunderbird 45.7 (boo#1021824) ==== gcal ==== Version update (4 -> 4.1) - Update to version 4.1: * National holiday replaced Pentecost Monday as a Swedish holiday 2005 * Report Reformation Day as an holiday everywhere in Germany in 2017 ==== glyr ==== - Trim descriptions and fix spelling errors. ==== gtk4 ==== Version update (3.89.1 -> 3.89.2) - Update to version 3.89.2: + gtk4-icon-browser works again. + gtk-encode symbolic works for icons with names containing dots. + GtkFlowBox and GtkListBox have been changed to no longer emit the ::selected-children-changed signal during destruction. + gtk-demo has gained an example for using PangoTabArray with GtkTextView. + We now support CSS border-spacing in GtkGrid, GtkBox and in gadgets. + The rendering in GDK and GSK has been further refactored. We now only draw toplevel windows, and we always redraw the whole window. + A Vulkan implementation has been added in parallel to the GL one. + Dropped APIs: - gdk_window_process_updates. - gdk_window_process_all_updates. - gdk_window_reparent. - Support for native and foreign subwindows. - gsk_render_node_{append/prepend/insert} variations. - gsk_render_node_make_immutable. - gtk_cairo_should_draw_window. - gtk_snapshot_append. - GtkJunctionSides. + New APIs: - gdk_rgba_is_clear. - gdk_rgba_is_opaque. - GdkDrawContext: A base class for vulkan and gl contexts. - Render node subclasses. - GskRoundedRect. - gtk_container_snapshot_child. + The GSK_USE_SOFTWARE environment variable has been generalized as GSK_RENDERER. Use GSK_RENDERER=help to learn about possible values. Other environment variables that have gained new possible values in clude GSK_DEBUG=vulkan and GTK_DEBUG=snapshot. + Bugs fixed: bgo#749012, bgo#771242, bgo#772371, bgo#773299, bgo#774265, bgo#774534, bgo#774686, bgo#774695, bgo#774743, bgo#774760, bgo#774784, bgo#774790, bgo#774893, bgo#774915, bgo#774917, bgo#774939, bgo#775038, bgo#775212, bgo#775316, bgo#775319, bgo#775410, bgo#775525, bgo#775651, bgo#776132, bgo#776187, bgo#776306. + Updated translations. - Drop gtk4-find-wayland.patch: Fixed upstream. Following this, drop gnome-common BuildRequires and autoreconf call as we no longer carry any patches. - Add vulkan-devel BuildRequires and Requires, also pass - -enable-vulkan to configure to ensure we build the vulkan support. ==== iodbc ==== Version update (3.52.10 -> 3.52.12) Subpackages: libiodbc-devel libiodbc3 - Update to version 0.52.12: * Added 64bit version of the iODBC Administrator to configure and test DSNs on drivers that are only available in 64bit format * Documentation fixes - Changes in version 0.52.11: * Added support for x86_64 to iODBC Demo * Fix crash ODBCdemo - error message overwrite stack data * Fix iODBCdemo issue with UID/PWD values * Fixed crash in iODBC DM on push of "Test" button when 64bit ODBC driver is used. * Fixed crash when create_dsnsetup fails to load the window. * Fixed crash when passing an empty connect string with no window handle * Fixed crash when passing an empty connect string with no window handle. * Fixed issue in SQLGetInfo * Fixed crash when create_dsnsetup fails to load the window - fix-nonvoid-return.diff: submitted upstream ==== kernel-source ==== Version update (4.9.5 -> 4.9.6) Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms - Linux 4.9.6 (bnc#1012628). - commit d1207ac - drm/i915/execlists: Reset RING registers upon resume (bsc#1021921). - commit 7b0a59a - [media] uvcvideo: uvc_scan_fallback() for webcams with broken chain (bsc#1021474). - commit 9bb1a8a ==== lightdm ==== Version update (1.21.1 -> 1.21.3) Subpackages: liblightdm-gobject-1-0 lightdm-lang - Update to version 1.21.3 (changes since 1.21.1): * Use SA_RESTART on signals so we don't get interrupted reads. * Use logind to terminate greeter sessions if it is available. * Load greeters from XDG_DATA_DIRS instead of the compile time value. * Allow the D-Bus interface to be disabled. * Always pass through LD_PRELOAD, LD_LIBRARY_PATH and PATH to sessions/display servers. * Fix an incorrect unref in the XDMCP server code. * Fix logging warnings. - Rebase lightdm-sysconfig-support.patch. ==== mozilla-nspr ==== Version update (4.12 -> 4.13.1) - update to version 4.13.1 * The previously released version 4.13 had changed pipes to be nonblocking by default, and as a consequence, PollEvent was changed to not block on clear. The NSPR development team received reports that these changes caused regressions in some applications that use NSPR, and it has been decided to revert the changes made in NSPR 4.13. NSPR 4.13.1 restores the traditional behavior of pipes and PollEvent. - update to version 4.13 NSPR 4.13 has the following bug fixes: * PL_strcmp (and others) were fixed to return consistent results when one of the arguments is NULL. * PollEvent was fixed to not block on clear. * Pipes are always nonblocking. * PR_GetNameForIdentity: added thread safety lock and bound checks. * Removed the PLArena freelist. * Avoid some integer overflows. * fixed several comments. ==== mozilla-nss ==== Version update (3.26.2 -> 3.28.1) Subpackages: libfreebl3 libsoftokn3 mozilla-nss-certs mozilla-nss-tools - update to NSS 3.28.1 No new functionality is introduced in this release. This is a patch release to update the list of root CA certificates and address a minor TLS compatibility issue that some applications experienced with NSS 3.28. * The following CA certificates were Removed CN = Buypass Class 2 CA 1 CN = Root CA Generalitat Valenciana OU = RSA Security 2048 V3 * The following CA certificates were Added OU = AC RAIZ FNMT-RCM CN = Amazon Root CA 1 CN = Amazon Root CA 2 CN = Amazon Root CA 3 CN = Amazon Root CA 4 CN = LuxTrust Global Root 2 CN = Symantec Class 1 Public Primary Certification Authority - G4 CN = Symantec Class 1 Public Primary Certification Authority - G6 CN = Symantec Class 2 Public Primary Certification Authority - G4 CN = Symantec Class 2 Public Primary Certification Authority - G6 * The version number of the updated root CA list has been set to 2.11 * A misleading assertion/alert has been removed when NSS tries to flush data to the peer but the connection was already reset. - update to NSS 3.28 New functionality: * NSS includes support for TLS 1.3 draft -18. This includes a number of improvements to TLS 1.3: - The signed certificate timestamp, used in certificate transparency, is supported in TLS 1.3. - Key exporters for TLS 1.3 are supported. This includes the early key exporter, which can be used if 0-RTT is enabled. Note that there is a difference between TLS 1.3 and key exporters in older versions of TLS. TLS 1.3 does not distinguish between an empty context and no context. - The TLS 1.3 (draft) protocol can be enabled, by defining NSS_ENABLE_TLS_1_3=1 when building NSS. - NSS includes support for the X25519 key exchange algorithm, which is supported and enabled by default in all versions of TLS. New Functions: * SSL_ExportEarlyKeyingMaterial * SSL_SendAdditionalKeyShares * SSL_SignatureSchemePrefSet * SSL_SignatureSchemePrefGet Notable Changes: * NSS can no longer be compiled with support for additional elliptic curves. This was previously possible by replacing certain NSS source files. * NSS will now detect the presence of tokens that support additional elliptic curves and enable those curves for use in TLS. Note that this detection has a one-off performance cost, which can be avoided by using the SSL_NamedGroupConfig function to limit supported groups to those that NSS provides. * PKCS#11 bypass for TLS is no longer supported and has been removed. * Support for "export" grade SSL/TLS cipher suites has been removed. * NSS now uses the signature schemes definition in TLS 1.3. This also affects TLS 1.2. NSS will now only generate signatures with the combinations of hash and signature scheme that are defined in TLS 1.3, even when negotiating TLS 1.2. - This means that SHA-256 will only be used with P-256 ECDSA certificates, SHA-384 with P-384 certificates, and SHA-512 with P-521 certificates. SHA-1 is permitted (in TLS 1.2 only) with any certificate for backward compatibility reasons. - New functions to configure signature schemes are provided: SSL_SignatureSchemePrefSet, SSL_SignatureSchemePrefGet. The old SSL_SignaturePrefSet and SSL_SignaturePrefSet functions are now deprecated. - NSS will now no longer assume that default signature schemes are supported by a peer if there was no commonly supported signature scheme. * NSS will now check if RSA-PSS signing is supported by the token that holds the private key prior to using it for TLS. * The certificate validation code contains checks to no longer trust certificates that are issued by old WoSign and StartCom CAs after October 21, 2016. This is equivalent to the behavior that Mozilla will release with Firefox 51. - update to NSS 3.27.2 * SSL_SetTrustAnchors leaks (bmo#1318561) - removed upstreamed patch * nss-uninitialized.patch - raised the minimum softokn/freebl version to 3.28 as reported in boo#1021636 ==== sed ==== Version update (4.2.2 -> 4.3) - Update to version 4.3: * sed's regular expression matching is now typically 10x faster * sed now uses unlocked-io where available, resulting in faster I/O operations. * lots of bugfixes (for detailed list see NEWS) - Drop patches (all upstreamed): * sed-fix-overlapping-address-ranges.patch * sed-follow-symlinks-hyphen.patch * sed-follow-symlinks-stdin.patch * sed-temp-delete.patch * sed-y-NUL-RHS.patch - Spec file cleanups * run spec-cleaner * use macro for configure * execute tests with produced binary as well * use url for signature as well * use https for download links * use xs compressed tarballl * make building verbose ==== squid ==== Version update (3.5.22 -> 3.5.23) - Update Squid to 3.5.23 * Do not share private responses with collapsed client(s). (CVE-2016-10003) * Fixes incorrect processing of responses to If-None-Modified HTTP conditional requests. (CVE-2016-10002) * partially fix hostHeaderVerify failures MISS when they should be HIT * HTTP/1.1: Add registered codes entry for new 103 (Early Hints) status code * Hang on DNS query with dead-end CNAME * partial: Fix segfault via Ftp::Client::readControlReply * Fix ssl::server_name ACL - was badly broken since inception. * HTTP/1.1: make Vary:* objects cacheable * fix Strange IPv6 shown in access.log ==== virt-manager ==== Subpackages: virt-install virt-manager-common - bsc#1022173 - virt-manager: unknown input device type 'virtio1.0-input' 1d2cd306-Fix-incorrect-usage-of-virtio-input.patch - bsc#1005848 - KVM: guest can not be started on top of SLES12SP1 KVM host ppc64 5a11cf07-virt-manager-generates-invalid-guest-XML.patch - Upstream bug fixes 617b9271-dont-return-virtio1.0-net-as-valid-device-name.patch 7962672c-fix-error-checking-extra_args.patch b4858842-fix-bad-version-check-regression.patch f07a3021-fix-wait-to-behave-like-noautoconsole.patch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 11

Re: [opensuse-factory] splash not
by Andrei Borzenkov 31 Jan '17

31 Jan '17

On Tue, Jan 31, 2017 at 9:39 AM, Jeroen Mathon <jeroenmathonmac(a)gmail.com> wrote: > Hey Andrei, > > I still received a message saying that plymouth.service has failed to start. > > So I assume that it still attempts to start plymouth. > Yes. This option is interpreted by plymouth, not systemd (or in general your init system). So plymouth will be started but should not do anything. > > On Tue, 31 Jan 2017, 07:37 Andrei Borzenkov, <arvidjaar(a)gmail.com> wrote: >> >> On Tue, Jan 31, 2017 at 8:25 AM, Neil Rickert <nrickert(a)ameritech.net> >> wrote: >> > >> > Yes, "nosplash" does disable showing the plymouth splash. But perhaps >> > plymouth still runs without showing any splash. >> > >> >> Correct. To completely prevent plymouth from loading use >> plymouth.enable=0. >> -- >> To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org >> To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org >> > -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] [Tumbleweed] spyder3-3.0.0 dependencies missing
by skific 30 Jan '17

30 Jan '17

Hi all, The spyder3 now depends on rope >= 0.94, while the python3-rope in tumbleweed is on 0.93. Forthermore, almost all of the icons are missing, that is the toolbar shows rectangles instead of icons. Only the icons from Run, Debug and Consoles are shown. thanks in advance, skific -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0