April 2020 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Leap 15.2 update to Build 626.2 causes serious issue
by Frank Krüger 16 Apr '20

16 Apr '20

FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=1169588 Regards, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 6

[opensuse-factory] Announcing schedule slip of openSUSE Leap 15.2
by Lubos Kocman 16 Apr '20

16 Apr '20

Hello openSUSE! I have not seen any objections on opensuse-project@ nor opensuse- factory@ regarding the timing part of the recent Jump proposal. With this in mind, I'd like to announce a schedule slip of openSUSE Leap 15.2. openSUSE Leap was originally supposed to enter the RC phase this Thursday. However, this step will be moved to May 28th. This date was chosen on purpose. It's Thursday after the SLE Public RC. SLE Public RC is also supposed to be the deadline for incorporating changes related to Closing the Leap Gap (CtLG) in the current release of SLE. I'd like to use this extended period to finish any pending Factory refreshes and accept any changes to unify SLE and openSUSE Leap code- streams. The new FCS date is scheduled for 2nd July and was chosen to fit the rule of releasing openSUSE Leap in between SLE Gold Master and release dates. So the versions of base-system packages released on GA are in sync. More information about the schedule can be found in https://en.opensuse.org/openSUSE:Roadmap Thank you

4 5

[opensuse-factory] openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 16 Apr '20

16 Apr '20

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - bstone Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org> N��r��y隊Z)z{.��r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��r�+��0��Ǩ�

2 1

[opensuse-factory] openSUSE:Leap:15.2 - Build fail notification
by openSUSE release team 15 Apr '20

15 Apr '20

Dear Package maintainers and hackers. Below package(s) in openSUSE:Leap:15.2 have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - python-psycopg2 Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Leap:15.2. Kind regards, openSUSE release team <opensuse-releaseteam(a)opensuse.org>

2 1

[opensuse-factory] How to get stuff to the new Leap prototype?
by Lubos Kocman 15 Apr '20

15 Apr '20

Hello openSUSE! let me share a proposal on how could the new submission workflow for the "Jump" could look like. Just to make sure, Jump is the openSUSE Leap prototype build on top of SLE Binaries and Backports. FYI: Tasks for current Jump effort are tracked here: https://progress.opensuse.org/projects/jump_152/ **Let's define 4 separate package origins:** (1) **SUSE:SLE-15* Code stream in OBS** * Synced 1:1 from IBS with few packages skipped, 00products, 000release-packages, packages related to infrastructure, live patching, ... less than 50) *Roughly 4000 packages (2) **Backports** * Additional packages for Leap and SLE via https://packagehub.suse.com/ . Available by default to Leap user, SLE user has to enable Package Hub. * Roughly 8000 packages (3) **openSUSE Leap forks of SLE packages** * Packages with additional functionality that didn't make it to SLES. This should be a very small group of packages (<130). * Less than 130 packages (4) **openSUSE Leap distribution and branding** * Packages defining content of openSUSE Leap artifacts (000products, release packages, kiwi descriptions) and *-branding packages * Less than 50 packages So here are my thoughts ... Updating the base system There is currently no well-defined process for updating (1) aside from the Factory First rule. Not many SLE packages are in sync with the version from Factory, so that rule just by itself is not sufficient. This is 1/3 of the openSUSE Leap distribution. Changes are usually handled via bugs in openSUSE product. Release Manager transforms Submit Requests or Bugs during review into SUSE Linux Enterprise feature requests. I usually try to handle this while Bugzilla triage, which is setting priority to bugs with priority set to P5 (None). A feature gets approved, or bug gets resolved. Change is implemented in IBS, synced to OBS, Jump gets the new build. This takes quite some time. And lowers the turnover rate of Rel-eng. I did a small research and contacted all Bugzilla component owners in openSUSE Distribution. Most of the feedback was that it is the team's best effort to triage bugs. Bugzilla should be used only for bugs, not a feature request, which is currently the case. This is a candidate for a brand new process that should be available to all active openSUSE Leap contributors. I can imagine a similar process to an existing SUSE partner feature request process in jira.suse.com. I did already create a request for our Jira team. At this point, it's still unclear where and how will be the request tracked. We'd like to have this implemented by Q3/2020. Updating openSUSE Leap package which is not in SLE Changes to (2) would be the same as today, in case that "Jump" is just a parallel build. This means submission to openSUSE Leap 15.2. From a Jump "as the only Leap" perspective. Submit Request is newly created against the openSUSE Backports project in OBS. openSUSE Backports don't have a Staging process to my knowledge, this needs improvement. Integration testing is necessary. Otherwise, I like this, since here it reduces work. One less SR and one less build mean less waiting to get the change in. The workaround to resolve blocking issues similar to SLE Workarounds would be still available if we need it. Submit to openSUSE Backports was happening anyway, to provide software to SLED/SLES. We can now even distribute the very same binary for SLE and Leap. Changing the distribution This would be the case for any package in (4). A direct Submit Request against the existing package in "Jump". Usually done by a member from the openSUSE Rel-eng team. Moving apart SLE and openSUSE Leap Commits to (3) should be subject to extensive review. We should always try to approach it in the same way as a Feature request in (1). Try to get SLE buy-in and extend fork only if necessary. Generally, the attempt here is to reduce this group and therefore have equal functionality in SLE and Leap if possible. What do you think? -- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

3 2

[opensuse-factory] Bringing Leap and SUSE Linux Enterprise closer together - a proposal
by Gerald Pfeifer 15 Apr '20

15 Apr '20

Hi everyone, today I have some exciting news and a proposal to relay: SUSE wants to go another step in openness towards the openSUSE community and suggests to bring the relationship of openSUSE Leap and SUSE Linux Enterprise to a new level. Internally this idea is called "Closing the Leap Gap" and proposes to strengthen and bring more closely together: * developer communities, by focusing on openSUSE Leap as a development platform for communities and industry partners; * user communities, by leveraging the benefits of both a stable Enterprise code base and the speed of community contributions; * the code bases of openSUSE Leap and SUSE Linux Enterprise (SLE), by not only sharing sources, but also offering the SUSE Linux Enterprise binaries for inclusion in openSUSE Leap. The proposal includes a three step approach: 1. Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of functionality or stability. (SUSE has started a cleanup process on the SUSE Linux Enterprise side already.) 2. In parallel to classic openSUSE Leap 15.2 create a flavor leveraging SLE binaries, leading to an intermediate release in the October 2020 time frame. 3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement). As you can imagine, a number of people have been involved with this so far, and I'd like to pull some of them in front of the curtain in a little interview. Q: Thomas, all of engineering at SUSE reports to you, and I know openSUSE is something you care about quite a bit. What is SUSE putting on the table here? Thomas Di Giacomo: Let me step back, and give you a perspective as I see it. SUSE for 27+ years has been a part of global open source ecosystem that includes a vast number of developers, end users, communities, and organizations of all sizes working together and benefiting from the collective work. Most of our engineers are involved as well with some open source communities that they feel passionate about. Open source communities are an integral part of who we are and the ecosystem we serve. Naturally, we feel responsible to support the communities and the work done by them. openSUSE is no different and is actually even more special and very dear to SUSE. So, it should come as no surprise that we are fully committed towards the openSUSE project(s) and its community. It makes us all feel proud to see Leap and Tumbleweed grow and evolve, together with SUSE Linux Enterprise. This effort of our engineers working together with others in the openSUSE community will benefit everyone involved for many years to come. Q: And why are you doing this? Thomas: We want open source to succeed for everyone – developers, contributors to end users and everyone in between. The benefits of open source are tremendous when the ecosystem grows as a result of the positive virtuous cycle of – contributing more, supporting the contributions, benefiting from contributions, which inspires more people contributing, and it goes on to grow as an upward virtuous spiral. We feel fortunate to be in the position of seeing the openSUSE community grow in tandem with the success of SUSE Linux Enterprise, and both feeding off each other to grow even more. This idea definitely goes in that direction. Now, let me defer to Matthias who came up with this idea. Q: Okay, so, Matthias, first of all: what is your role at SUSE? Matthias Eckermann: I am leading the Product Management team for Linux platforms, covering SUSE Linux Enterprise, Edge, and Security. Q: And what made you propose this? Matthias: My team and I realized that the engagement of our SLE business with the openSUSE community does not fully fit our view on openness, and that mutual benefits are not leveraged sufficiently. We discussed what it would take to bridge the gap and bring the relationship to the next level. Beyond a common ground on the technical side, the code streams, this requires learning from each other; for example, we need to re-establish an open feature process between community, SUSE, and our industry partners. Thus we developed "Closing the Leap Gap", and - to test whether it might have a chance to fly - we outlined the initial idea with the openSUSE Board before going for approvals by SUSE management. Q: You mention the board, so let me ask. What is your take? What opportunities, benefits do you see? What risks? Dr. Axel Braun: With this change, we can make better use of our resources, as two code bases converge - so one build target less to consider. Everyone who packages for Leap and for Package Hub will immediately benefit from this. Marina Latini: It's really exciting to see how SUSE is trying to increase its support for Leap, reducing the existing differences between our openSUSE Leap and SLE. I can see this proposal as a way to be more inclusive, giving to the community the opportunity to contribute in an easier way to Leap and giving the chance to bring the openSUSE spirit also in an Enterprise product like SLE. On the other hand, every new move is a change and we need to be sure that the changes won't limit our community freedom to submit packages to Leap or won't slow down Leap for following the internal SUSE development model. Q: Matthias, that sounds like some extra effort required. How is SUSE contributing, what is SUSE committing to? Matthias: Indeed, there is quite some one-time effort needed to get (back) to the common ground; this is covered by SUSE engineering teams; two groups are heavily involved: The Open Build Service experts are designing a workflow for a smooth integration of the binaries, and for reducing the long term maintenance efforts for our community contributors. SUSE release managers and packagers are working hard to synchronize the code bases without losing functionality or quality. Hundreds of change requests have been filed already, and to get this done properly, we are delaying the release of SUSE Linux Enterprise 15 SP2 to July. And we are willing to invest more, to drive the idea to success quickly: we would take the burden, to create an intermediate openSUSE Leap release in October 2020 which then would incorporate SUSE Linux Enterprise binaries into Leap the first time. Probably, Adrian can comment on the Build Service aspects, and Lubos what it means to developers within SUSE and to the community release process? Q: So, Lubos, as release manager for Leap, what have you been doing so far, and what is the impact you see? Lubos Kocman: I spent most of the time on collecting data regarding SLE and Leap differences and having follow-up discussions and transforming feedback into action items. Max and the rest of the openSUSE release engineering team meanwhile did an excellent job of keeping Leap release activities going forward. The idea of re-using should generally lower the effort on the Leap side. However, it comes with the price of increased complexity to bring all pieces together. A new process will allow external contributors to file feature or update requests directly to SLE. This will already help a lot. Q: Is this an outcome bound effort, or time bound? I know the SLE release schedule is a bit like a 300m tanker. Lubos: It's both. I see this as a balance between what can we deliver, how, and to what date. It took quite some effort to create a plan acceptable by all involved teams. Splitting the work across the upcoming two releases seemed to be accepted well at least by involved parties so far. Q: So, that is SLE 15 SP2. How about Leap 15.2? Lubos: openSUSE Leap 15.2 will have to slip by about 8 weeks to incorporate all changes from the SLE and align with its new schedule. I believe that the release will find a great use for extra time since we're still finishing the refresh of packages from Factory. The prototype will be meanwhile available in parallel to the openSUSE Leap 15.2. Q: How is that research proceeding, Adrian? Adrian Schröter: We have an idea about the setup in build.opensuse.org. I anticipate to have a first prototype of the build setup in next three weeks. And more important is how to develop the workflows to allow a more collaborative joint effort between SLE and openSUSE development. However, we must keep in mind that this is really an entire new way to develop a distribution. On one hand it makes a lot of sense to integrate for example the SUSE Backports (aka Package Hub) people directly in our development process. This will make our distribution development stronger. On the other hand, we also must find ways how to solve new problems. For example how to keep our builds for architectures not covered by SLES like Arm 32bit and RISC-V. Also the turn around times of submissions and build results will be a challenge in the initial setup. And last but not least, the installed systems and users may need to deal with more repositories. But we have one year to work on these problems in parallel to our stable distribution. And we are indeed looking forward to make openSUSE and SLE development more beneficial than ever. Gerald: Thanks everyone for your input. I'll be sharing all this with openSUSE mailing lists, and am sure there will be further questions, offers to help, and other input, so please chime in there. https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap has an FAQ with more details. Lubos is going to send a proposal with more details on the implementation side to opensuse-factory@. I suggest we focus technical discussions of this offer and proposals there (opensuse-factory@) and general discussions on opensuse-project@. So, what do you think? Gerald -- Dr. Gerald Pfeifer <gp(a)suse.com>, CTO @SUSE + chair @openSUSE

19 31

[opensuse-factory] New Tumbleweed snapshot 20200413 released!
by Dominique Leuenberger 15 Apr '20

15 Apr '20

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… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: MozillaFirefox (74.0.1 -> 75.0) btrfsprogs (5.4.1 -> 5.6) cdrdao (1.2.3 -> 1.2.4) discover grub2 libappindicator3 libnotify (0.7.8 -> 0.7.9) libostree (2019.6 -> 2020.3) libreoffice (6.4.2.2 -> 6.4.3.2) nano (4.9.1 -> 4.9.2) qpdf (10.0.0 -> 10.0.1) vulkan-loader (1.2.133 -> 1.2.135) xdg-desktop-portal xf86-input-mouse zsh === Details === ==== MozillaFirefox ==== Version update (74.0.1 -> 75.0) Subpackages: MozillaFirefox-translations-common - Mozilla Firefox 75.0 * https://www.mozilla.org/en-US/firefox/75.0/releasenotes MFSA 2020-12 (bsc#1168874) * CVE-2020-6821 (bmo#1625404) Uninitialized memory could be read when using the WebGL copyTexSubImage method * CVE-2020-6822 (bmo#1544181) Out of bounds write in GMPDecodeData when processing large images * CVE-2020-6823 (bmo#1614919) Malicious Extension could obtain auth codes from OAuth login flows * CVE-2020-6824 (bmo#1621853) Generated passwords may be identical on the same site between separate private browsing sessions * CVE-2020-6825 (bmo#1572541,bmo#1620193,bmo#1620203) Memory safety bugs fixed in Firefox 75 and Firefox ESR 68.7 * CVE-2020-6826 (bmo#1613009,bmo#1613195,bmo#1616734,bmo#1617488, bmo#1619229,bmo#1620719,bmo#1624897) Memory safety bugs fixed in Firefox 75 - removed obsolete patch mozilla-bmo1609538.patch - requires * rust >= 1.41 * rust-cbindgen >= 0.13.1 * mozilla-nss >= 3.51 * nodejs10 >= 10.19 - fix build issue in libvpx for i586 via mozilla-bmo1622013.patch - increase _constraints memory for ppc64le ==== btrfsprogs ==== Version update (5.4.1 -> 5.6) Subpackages: btrfsprogs-udev-rules libbtrfs0 - Update to 5.6: * inspect logical-resolve: support LOGICAL_INO_V2 as new option '-o', helps advanced dedupe tools * inspect: user larger buffer (64K) for results * subvol delete: support deletion by id (requires kernel 5.7+) * dump-tree: new option --hide-names, replace any names (file, directory, subvolume, xattr) in the output with stubs * various fixes - Update to 5.4.1 * build: fix docbook5 build * check: do extra verification of extent items, inode items and chunks * qgroup: return ENOTCONN if quotas not running (needs updated kernel) * other: various test fixups - BuildRequire pkgconfig(udev) instead of udev: Allow OBS to shortcut through the -mini flavor. - Use pkg-config --modversion udev to identify the current udev version. This is more portable and supports the -mini flavors. - Update to 5.4 * support new hash algorithms (kernel 5.5): * mkfs.btrfs and btrfs-convert with --csum, crc32c, xxhash, sha256, blake2 * mkfs: support new raid1c3 and raid1c4 block group profiles (kernel 5.5) * check: * --repair delays start with a warning, can be skipped using --force * enhanced detetion of inode types from partial data, more options for repair * receive: fix quiet option * image: speed up chunk loading * fi usage: * sort devices by id * print ratio of used/total per block group type * rescue zero-log: reset the log pointers directly, avoid reading some other potentially damaged structures * new make target install-static to install only static binaries/libraries * other * docs updates * new tests * cleanups and refactoring - Update to 5.3.1: * libbtrfs: fix link breakage due to missing symbols - Updaet to 5.3: * mkfs: * new option to specify checksum algorithm (only crc32c) * fix xattr enumeration * dump-tree: BFS (breadth-first) traversal now default * libbtrfsutil: remove stale BTRFS_DEV_REPLACE_ITEM_STATE_x defines * ci: add support for gitlab * other: * preparatory work for more checksum algorithms * docs update * switch to docbook5 backend for asciidoc * fix build on uClibc due to missing backtrace() * lots of printf format fixups - Enable build of python-bindings for libbtrfsutil - Update to 5.2.2: * check: * fix false report of wrong byte count for orphan inodes * option -E was not handled correctly * new check and repair for root item generation * balance: check for full-balance before background fork * mkfs: check that total device size does not overflow 16EiB * dump-tree: print DEV_STATS key type * other: * new and updated tests * doc fixups and updates - update to 5.2.1 * scrub status: fix ETA calculation after resume * check: fix crash when using -Q * restore: fix symlink owner restoration * mkfs: fix regression with mixed block groups * core: fix commit to process all delayed refs * other: * minor cleanups * test updates - update to 5.2 * subvol show: print qgroup information when available * scrub: * status: show ETA, revamp the whole output * fix reading/writing of last position on resume/cancel, potentially skipping part of the filesystem on next resume * dump-tree: add new option --noscan to use only devices given on the commandline * all-in-one binary (busybox style) with mkfs.btrfs, btrfs-image, btrfs-convert, btrfstune * image: fix hang when there are more than 32 cpus online and compression is requested * convert: fix some false ENOSPC errors when --rootdir is used * build: fix gcc9 warnings * core changes * command handling cleanups * dead code removal * cmds-* files moved to cmds/ * other shared userspace files moved to common/ * utils.c split into more files * preparatory work for more output formats * libbtrfsutil: fix unaligned access * other * new and updated tests * fix tests so CI passes again * sb-mod can modify more superblock items - update to version 5.1 * repair: flush/FUA support to avoid breaking metadata COW * file extents repair no longer relies on data in extent tree * lowmem: fix false error reports about gaps between extents * add inode mode check and repair for various objects * add check for invalid combination of nocow/compressed extents * device scan option to forget scanned devices [new] * mkfs: use same chunk size as kernel for initial creation * dev-repace: better report when other exclusive operation runs * help for sntax errors on command lines, print relevant msgs * defrag: able to open files in RO mode * dump-tree: --block can be specified multiple times - update to version 4.20.2 * dump-super: minor output fixup * revert fix for prefix detection of receive path, this is temporary and unbreaks existing user setups - Use correct path for dracut-fsck-help.txt in module-setup.sh (bsc#1122539) * Remove module-setup.sh * Add module-setup.sh.in - Advise user of fs recovery options when we fail to mount (fate#320443, bsc#1122539) * Add dracut-fsck-help.txt * Add module-setup.sh - update to version 4.20.1 * libbtrfs: fix build of external tools due to missing symbols * ci: enable library test - update to version 4.20 * new feature: metadata uuid * lightweight change of UUID without rewriting all metadata (incompatible change) * done by btrfstune -m/-M, needs kernel support, 5.0+ * image: * fix block groups when restoring from multi-device image * only enlarge result image if it's a regular file * check * more device extent checks and fixes * can repair dir item with mismatched hash * mkfs: uuid tree created with proper contents * fix mount point detection due to partial prefix match * other: * new tests, build fixes, doc updates * libbtrfsutil: fix tests if kernel lacks support for new subvolume ioctls - partial cleanup with spec-cleaner - drop 0001-btrfs-progs-Add-support-for-metadata_uuid-field.patch - drop 0002-btrfs-progs-btrfstune-Add-support-for-changing-the-u.patch - drop 0003-btrfs-progs-Remove-fsid-metdata_uuid-fields-from-fs_.patch - drop 0004-btrfs-progs-Remove-btrfs_fs_info-new_fsid.patch - drop 0005-btrfs-progs-Directly-pass-root-to-change_devices_uui.patch - Use %license instead of %doc [bsc#1082318] - Implement fate#325871 * Added 0001-btrfs-progs-Add-support-for-metadata_uuid-field.patch * Added 0002-btrfs-progs-btrfstune-Add-support-for-changing-the-u.patch * Added 0003-btrfs-progs-Remove-fsid-metdata_uuid-fields-from-fs_.patch * Added 0004-btrfs-progs-Remove-btrfs_fs_info-new_fsid.patch * Added 0005-btrfs-progs-Directly-pass-root-to-change_devices_uui.patch - update to version 4.19.1 * check * many lowmem mode improvements * properly report qgroup mismatch errors * check symlinks with append/immutable flags * fi usage * correctly calculate allocated/unallocated for raid10 * minor output updates * mkfs * detect ENOSPC on thinly provisioned devices * fix spurious EEXIST during directory traversal * restore: fix relative path for restore target * dump-tree: print symbolic tree names for backrefs * send: fix regression preventing send -p with subvolumes mounted on "/" * corrupt-tree: refactoring and command line updates * build * make it work with e2fsprogs < 1.42 again * restore support for autoconf 2.63 * detect if -std=gnu90 is supported * other * new tests * cleanups - update to version 4.19 * check: support repair of fs with free-space-tree feature * core: * port delayed ref infrastructure from kernel * support write to free space tree * dump-tree: new options for BFS and DFS enumeration of b-trees * quota: rescan is now done automatically after 'assign' * btrfstune: incomplete fix to uuid change * subvol: fix 255 char limit checks * completion: complete block devices and now regular files too * docs: * ship uncompressed manual pages * btrfsck uses a manual page link instead of symlink * other * improved error handling * docs * new tests - update to version 4.17.1 * check: * add ability to fix wrong ram_bytes for compressed inline files * beautify progress output * btrfstune: allow to continue uuid change after unclean interruption * several fuzz fixes: * detect overalpping chunks * chunk loading error handling * don't crash with unexpected root refs to extents * relax option parsing again to allow mixing options and non-options arguments * fix qgroup rescan status reporting * build: * drop obsolete dir-test * new configure option to disable building of tools * add compatibility options --disable-static and --disable-shared * other: * cleanups and preparatory work * new test images - spec cleanup - update to version 4.17 * check * many lowmem mode improvements * properly report qgroup mismatch errors * check symlinks with append/immutable flags * fi usage * correctly calculate allocated/unallocated for raid10 * minor output updates * mkfs * detect ENOSPC on thinly provisioned devices * fix spurious EEXIST during directory traversal * restore: fix relative path for restore target * dump-tree: print symbolic tree names for backrefs * send: fix regression preventing send -p with subvolumes mounted on "/" * corrupt-tree: refactoring and command line updates * build * make it work with e2fsprogs < 1.42 again * restore support for autoconf 2.63 * detect if -std=gnu90 is supported - Removed patches (upstreamed): * 0001-btrfs-progs-convert-fix-support-for-e2fsprogs-1.42.patch * 0002-btrfs-progs-build-autoconf-2.63-compatibility.patch * 0003-btrfs-progs-build-detect-whether-std-gnu90-is-suppor.patch - Don't require libzstd-devel-static on builds that don't use it. - fix installation of btrfs.5.gz - Fix building on SLE11: * btrfs-progs: convert: fix support for e2fsprogs < 1.42 * btrfs-progs: build: detect whether -std=gnu90 is supported * btrfs-progs: build: autoconf 2.63 compatibility * Fixed mismerged addition of libbtrfsutil1 package description - Added patches: * 0001-btrfs-progs-convert-fix-support-for-e2fsprogs-1.42.patch * 0002-btrfs-progs-build-autoconf-2.63-compatibility.patch * 0003-btrfs-progs-build-detect-whether-std-gnu90-is-suppor.patch - update to version 4.16.1 * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, btrfs-show-super, btrfs-calc-size * sb-mod: new debugging tool to edit superblock items * mkfs: detect if thin-provisioned device does not have enough space * check: don't try to verify checksums on metadata dump images * build: fail documentation build if xmlto is not found * build: fix build of btrfs.static - Remove patch: 0001-btrfs-progs-build-fix-static-build.patch (upstream) - Update initrd script - update to version 4.16 * libbtrfsutil - new LGPL library to wrap userspace functionality * several 'btrfs' commands converted to use it: * properties * filesystem sync * subvolume set-default/get-default/delete/show/sync * python bindings, tests * build * use configured pkg-config path * CI: add python, musl/clang, built dependencies caching * convert: build fix for e2fsprogs 1.44+ * don't install library links with wrong permissions * fixes * prevent incorrect use of subvol_strip_mountpoint * dump-super: don't verify csum for unknown type * convert: fix inline extent creation condition * check: * lowmem: fix false alert for 'data extent backref lost for snapshot' * lowmem: fix false alert for orphan inode * lowmem: fix false alert for shared prealloc extents * mkfs: * add UUID and otime to root of FS_TREE - with the uuid, snapshots will be now linked to the toplevel subvol by the parent UUID * don't follow symlinks when calculating size * pre-create the UUID tree * fix --rootdir with selinux enabled * dump-tree: add option to print only children nodes of a given block * image: handle missing device for RAID1 * other * new tests * test script cleanups (quoting, helpers) * tool to edit superblocks * updated docs - Add patch: 0001-btrfs-progs-build-fix-static-build.patch - Add new library packages: libbtrfsutil - use documentation shipped by upstream tar, reduce dependencies - enable static build again, zstd now has static version - update to version 4.15 * mkfs --rootdir reworked, does not minimize the final image but can be still done using a new option --shrink * fix allocation of system chunk, don't allocate from the reserved area * other * new and updated tests * cleanups, refactoring * doc updates - spec: fix distro version condition - update to version 4.14.1 * dump-tree: print times of root items * check: fix several lowmem mode bugs * convert: fix rollback after balance * other * new and updated tests, enabled lowmem mode in CI * docs updates * fix travis CI build * build fixes * cleanups - update to version 4.14 * build: libzstd now required by default * check: more lowmem mode repair enhancements * subvol set-default: also accept path * prop set: compression accepts no/none, same as "" * filesystem usage: enable for filesystem on top of a seed device * rescue: new command fix-device-size * other * new tests * cleanups and refactoring * doc updates - Removed patches: - rollback-regression-fix.patch - upstreamed - spec: disable static build, missing libzstd-devel-static - spec: disable zstd support for non-Tumbleweed distros ==== cdrdao ==== Version update (1.2.3 -> 1.2.4) - Update to version 1.2.4: * Fixed autocon warnings (Denis Leroy) * Ported to lame 3.100 (from Fedora) * G++ compile fixes (Nick Bailey) * Renamed xdao folder to gcdmaster (Denis Leroy) * pccts format security patch (from Fedora) * Fixed compile issues with glibc >= 2.12 * Gcdmaster segfault fix (Adrian Knoth) * Prevent a FTBFS on kfreebsd (Christoph Egger) * Also look in /etc/default/cdrdao config (Andrew Suffield) * Fix printf format security issues (Frantisek Kluknavsky Fedora) * Add missing options to man page (Honza Horák) * CD_TEXT fix for HL-DT-ST (Kees Cook) * Man page hyphen fixes (Markus Koschany) * Some updates to the old scsilib smake files (Ubuntu patches) - Drop no longer needed patches: * cdrdao-1.2.2-scan.patch * cdrdao-gcc6-fixes.patch ==== discover ==== Subpackages: discover-backend-flatpak discover-backend-fwupd discover-backend-packagekit discover-lang - Add missing kdeclarative-components runtime dependency (boo#1169153) ==== grub2 ==== Subpackages: grub2-i386-pc grub2-snapper-plugin grub2-systemd-sleep-plugin grub2-x86_64-efi grub2-x86_64-xen - Fix GCC 10 build fail (bsc#1158189) * 0001-mdraid1x_linux-Fix-gcc10-error-Werror-array-bounds.patch * 0002-zfs-Fix-gcc10-error-Werror-zero-length-bounds.patch ==== libappindicator3 ==== - Do not apply xappstatusicon.patch: pulls half of Mate into Ring1. - Fix build on py2 less system - Added xappstatusicon.patch. It adds support for XAppStatus Icon by Linux Mint. ==== libnotify ==== Version update (0.7.8 -> 0.7.9) Subpackages: libnotify-tools libnotify4 typelib-1_0-Notify-0_7 - Remove service files. - Update to version 0.7.9: + Added man page for notify-send. + Dropped autotools. - Require docbook5-xsl-stylesheets. Needed for manpage generation. ==== libostree ==== Version update (2019.6 -> 2020.3) Subpackages: libostree-1-1 - Update to version 2020.3: * A quick followup to 2020.2, which introduced support for read-only sysroot ended up breaking some of the Fedora CoreOS tests in coreos-assembler which in turn holds back ostree going into FCOS * Now that gap has been closed and more of those tests are being run on the new CI. - Update to version 2020.2: * lib: Fix Since versions for 2020.1 * Post-release version bump * "Brown paper bag" release that actually sets the is_release_build=yes flag and also fixes the Since: on a few new functions. - Update to version 2020.1: * There is now support for making the /sysroot mount point read-only to start. This protects against a lot of accidental damage, and also generalizes and improves the previous special case handling of having /boot read-only. One known issue is that ostree pull is broken with this enabled, and this will be fixed. * Error-handling around GPG verification has had an overhaul. Specifically, libostree now has more specific error codes to distinguish between different verification failures. This should allow apps to have more fine-grained control over how to respond to errors. Do note that the error messages themselves have changed, and we strongly suggest that anyone relying on a specific error message string to migrate to using the API directly. * The original "archive" (split up objects) format didn't make it easy for a client system to know how much data it would be downloading. Later, static deltas were added which addressed this problem, but there are situations in which object fetches still occur. Later then support for optional sizes metadata in commit objects was added but was never really stabilized/publicized. There were also some bugs in it. That is now completed - the sizes data is now stable. and new API was added to read it. * This release adds initial fs-verity support; it doesn't do too much today. Bigger picture it's important to understand that the vision of OSTree is to enable Linux systems that feel like they're "image based" (transactional, versioned updates, no dependency resolution client side), but also to enable things like doing commits on the client side. Today rpm-ostree supports replacing the kernel client side as a first class operation. This is crucially important to make it feel truly like a Linux system that you own. * A small tweak was made to have OSTree create repo structure directories and files (such as objects/ or .lock) with group write permissions. This is useful for managing OSTree remote servers from multiple UIDs. For systems with the default umask of 0022, this should have no effect. * We've extensively reworked CI for the upstream repo. In addition to Travis, testing is now done on top of Fedora CoreOS. Not all tests have been carried over, but expect to see more coming. This rework will also allow us to have more comprehensive tests previously not possible. * Several fixes were made to the test suite to handle the cases of systemd vs no-systemd, and systemd is now advertised in the list of features in ostree --version if present. ==== libreoffice ==== Version update (6.4.2.2 -> 6.4.3.2) Subpackages: libreoffice-base libreoffice-base-drivers-firebird libreoffice-calc libreoffice-draw libreoffice-filters-optional libreoffice-gnome libreoffice-gtk3 libreoffice-icon-themes libreoffice-impress libreoffice-l10n-cs libreoffice-l10n-da libreoffice-l10n-de libreoffice-l10n-el libreoffice-l10n-en libreoffice-l10n-en_GB libreoffice-l10n-es libreoffice-l10n-fr libreoffice-l10n-hu libreoffice-l10n-it libreoffice-l10n-ja libreoffice-l10n-pl libreoffice-l10n-pt_BR libreoffice-l10n-ru libreoffice-l10n-zh_CN libreoffice-l10n-zh_TW libreoffice-mailmerge libreoffice-math libreoffice-pyuno libreoffice-qt5 libreoffice-writer libreofficekit - Update to 6.4.3.2: * 6.4.2 RC2 release - Drop merged patch adapt-o3tl-span-to-removal-of-std-span-cbegin-et-al.patch ==== nano ==== Version update (4.9.1 -> 4.9.2) Subpackages: nano-lang - GNU nano 4.9.2: * fix crash after undoing an <Enter> at the end of leading whitespace ==== qpdf ==== Version update (10.0.0 -> 10.0.1) - Update to version 10.0.1 * Fixes a regression in QPDFObjectHandle::getStreamData ==== vulkan-loader ==== Version update (1.2.133 -> 1.2.135) - Update to release 1.2.135 * Updated `CMakeLists.txt` and `common_codegen.py` to allow access to beta types and commands when including `vulkan.h`. Generated new loader header files. ==== xdg-desktop-portal ==== Subpackages: xdg-desktop-portal-lang - Add patch from upstream to fix a use-after-free case: * 0001-Fix-use-after-free-in-xdg_get_app_info_from_pid.patch - Add patch from upstream to add AssumedAppArmorLabel key to D-Bus service files to allow sandboxed processes to activate the portal services if the sandbox makes use of AppArmor D-Bus mediation rules that depend on the service's security label: * 0002-add-AssumedAppArmorLabel-key-to-D-Bus-service-files.patch - Add patch from upstream to fix a null pointer usage when no default handler is set for desired type: * 0003-Fix-criticals-if-no-default-handler-for-desired-type.patch ==== xf86-input-mouse ==== - Downgrade Supplements: xorg-x11-server to Enhances, to avoid the package being pulled in by default. Contemporary mice are handled by xf86-input-evdev or xf86-input-libinput. ==== zsh ==== - Stop sourcing /etc/bash.bashrc which causes problems with ls, add a call to manually source /etc/zsh.zshrc.local if available.

1 0

[opensuse-factory] New Bluez is breaking Bluetooth for receiving files!!!
by Marco Calistri 14 Apr '20

14 Apr '20

Hello, After almost 2 hours of testings, I finally discovered that new *bluez* is breaking Tumbleweed Bluetooth which normally can just send files outside and it is not allowing receiving files from external devices. The solution for me has been to install *bluez-deprecated* which in turn provide *hcitool* required for this kind of file transfers. Wonder if this fact is know by others around there and if a different way, I mean by not using blez-deprecated package is available to configure in/out file transfers over Bluetooth in Tumbleweed. Thanks! -- Marco Calistri Build: openSUSE Tumbleweed 20200411 Kernel: 5.6.2-1-default - Cinnamon 4.2.2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 2

[opensuse-factory] openSUSE:Leap:15.2 - Build fail notification
by openSUSE release team 14 Apr '20

14 Apr '20

Dear Package maintainers and hackers. Below package(s) in openSUSE:Leap:15.2 have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - PyGreSQL - courier-authlib - ghc-store - gnokii - psqlODBC - python-matrix-synapse-ldap3 Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Leap:15.2. Kind regards, openSUSE release team <opensuse-releaseteam(a)opensuse.org>

4 5

[opensuse-factory] openSUSE:Leap:15.2 - Build fail notification
by openSUSE release team 14 Apr '20

14 Apr '20

Dear Package maintainers and hackers. Below package(s) in openSUSE:Leap:15.2 have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - orion Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Leap:15.2. Kind regards, openSUSE release team <opensuse-releaseteam(a)opensuse.org> N��r��y隊Z)z{.��r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��r�+��0��Ǩ�

2 1