devel November 2018

devel@lists.fedoraproject.org

227 participants
247 discussions

Proposal: Abandon v8 package
by Tom Callaway 07 Mar '19

07 Mar '19

Background: I made the original v8 Fedora package many moons ago, when I was more optimistic about the possibility of separating the useful components inside of chromium. Since that point, it has become clear that while v8 is useful software, the following facts are also true: 1. The v8 upstream is entirely disinterested in the concept of maintaining any sort of ABI/API consistency between releases. 2. The v8 that is used in chromium is not necessarily compatible with the upstream v8, as they have a history of picking and choosing code changes (and even applying chromium specific changes locally). 3. Virtually all consumers of v8 (including chromium) take a git checkout (not a specific one, just whatever they decided to code to) and use that revision, often creating a local fork of v8 from that revision, as they are either unwilling or unable to track v8 upstream. 4. Since v8 has no concept of a "stable" release that I can see, they simply do security fixes to the master branch, which, combined with the code changing violently, makes it very difficult to backport security fixes. This means that other than plv8 (which is currently unable to build against the current v8 package in Fedora), I do not see any consumers of the Fedora v8 package (chromium has long since abandoned any possibility of using it). It does contain a "d8" binary, which is a javascript CLI debugger, but it is not clear to me that this is widely used, or that the benefit of its inclusion in Fedora outweighs the pain of maintaining this package. Thus, I propose that the v8 package be abandoned/orphaned/taken to the farm upstate to run and play with the other dogs. If you disagree, or are crazy enough to want to take it over, speak now. ~tom P.S. I'll still maintain v8-314 as best I can, since there are actually users of that. The irony of that really ancient version being considered stable (and thus, used by other software) as a result of Fedora sticking on that version of v8 for so many releases is not lost on me.

4 7

F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik 04 Mar '19

04 Mar '19

= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries Owner(s): * Matus Honek <mhonek at redhat dot com> OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r. == Detailed description == After this change the non-threaded version of libldap will not be shipped any more. Instead, this library will rather be built the same way as the threaded libldap_r. This has been previously discussed in Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and other distributions where this change already happened. Upstream still supports non-threaded version of their library as it might be used on processors where threads are not supported. However, when these two versions happen to be loaded at the same time (as discussed about Curl in the Bugzilla) symbol names overlap which may result in unpredictable behaviour. Immediate solution would be to symlink libldap to libldap_r, however SONAME of the library would be the same, hence breaking dependencies of other packages. For that reason the solution hereby proposed should be the most convenient one. == Scope == * Proposal owners: update SPEC file so that non-threaded libldap is replaced with threaded one. * Other developers: None. Issues should not occur. * Release engineering: [https://pagure.io/releng/issue/7253] ** List of deliverables: N/A * Policies and guidelines: None. * Trademark approval: (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

5 9

F29 System Wide Change: Remove Excessive Linking
by Jan Kurik 18 Feb '19

18 Feb '19

Note from Change Wrangler: This Change Proposal requires mass rebuild. However, two weeks ago (June 19th), we have already passed the deadline for Change proposals requiring mass rebuild. I will leave the decision whether this Change proposal is accepted or not to RelEng and FESCo teams. = Proposed System Wide Change: Remove Excessive Linking = https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking Owner(s): * Igor Gnatenko <ignatenkobrain at fedoraproject dot org> * Neal Gompa <ngompa13 at gmail dot com> Pass "--as-needed" flag the linker through default system-wide LDFLAGS. == Detailed description == The flag ("--as-needed") tells the linker to link in the produced binary only the libraries containing symbols actually used by the binary itself. This binary can be either a final executale or another library. The use of the "--as-needed" flag allows the linker to avoid linking extra libraries in a binary. This not only improves startup times (as the loader does not have to load all the libraries for every step) but might avoid the full initialization of big frameworks. == Scope == * Proposal owners: Add "-Wl,--as-needed" into RPM_LD_FLAGS (in redhat-rpm-config). * Other developers: Nothing should break, but immediate work-around would be to disable this flag (will be provided in redhat-rpm-config) and fix real issue later. * Release engineering: #7604 [https://pagure.io/releng/issue/7604] (mass rebuild is desired after this change). ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: Add information how to turn it off (TODO link to FPC ticket). * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

11 17

Orphan/retire gogoc
by J. Randall Owens 17 Feb '19

17 Feb '19

Hello, gogoc is dead to the world upstream (the gogo6.com site is now a nutritional supplement pusher!), and without gogo6's servers, gogoc is fairly useless. It's still possible it could be used to TSP tunnel through one's own servers to get IPv6, but as far as I know, there aren't any more tunnel services out there that use it. So, if someone would find it worthwhile to keep it around for their own tunnelling needs, feel free to pick it up. Otherwise, I'll retire it in two weeks. -- J. Randall Owens | http://www.GhiaPet.net/

3 2

Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal
by Ben Cotton 17 Feb '19

17 Feb '19

https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal == Summary == (Sub-)packages only providing python2 importable modules without additional functionality will be removed from Fedora unless some other package(s) depends on them. Python 2 will be deprecated in Fedora. Packagers can mark any other Python 2 packages as deprecated as well. == Owner == * Miro Hrončok (Churchyard) * Petr Viktorin (Pviktori) * Charalampos Stratakis (Cstratak) * Zbigniew Jędrzejewski-Szmek (Zbyszek) * Igor Gantenko (Ignatenkobrain) * Neal Gompa (Ngompa) == Detailed Description == Python 2 reaches End of Life on 2020-01-01. Its current maintainers would like to orphan it before that date, and so far no one else has stepped up to maintain Python 2 (with the full ecosystem) past 2020. Since thousands of packages still depend on python2, we need a more careful approach than normal orphaning. Some of those packages are abandoned and/or the Python 2 version is unnecessary. Others are useful and just need more time to port to Python 3. Hence we set up criteria for python2 packages that can remain in the distribution and we remove everything else. This should allow us to keep python2 for limited use, not break everything, but should also send a strong message that it is no longer a first class citizen, and filter packages we need to focus Python 3 porting efforts on. (Sub-)packages that only provide a python2 importable module, and are not required for other packages, will be removed. Examples of situations where a (sub-)package does not provide only the importable module: * A package also provides an application, mostly likely in /usr/bin, /usr/libexec... ** (Note that according to current guidelines, if the Python 3 version of a package provides the same functionality, the Python 3 package should provide the application.) ** (In certain situations the provided application is only useful to boostrap or manage projects using the module. Such applications don't count.) * A package provides a plugin for another application, most likely trough a setuptools entrypoint interface or some custom location on disk. Our process will be: * File bugs for all packages that look like they only provide a Python 2 importable module. (This includes those needed by other packages we plan to remove.) * Leave at least a week for packagers to respond to the bugs. * If the packager approves or there is no response for a week, we will remove the package. There are currently ~3000 source packages that generate python2 dependent RPMs. Automation is being created to be able to provide us a rough list of packages to remove. === Packages to remove === The list is at https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List not to disturb the reading experience of this page. Packagers can block some packages from removal by responding on Bugzilla and providing reasons. If no general consensus is reached, FESCo will decide (as Python SIG does not have a formal process for such decisions). We'll also actively try to remove unused or optional dependencies to reduce the number of packages that need to be kept because other packages depend on them. As dependencies evolve over time, we will regularly repeat this proces on rawhide from now on even on future releases. Packagers are strongly encouraged to help port their applications to Python 3. Removing old Python 2 only applications from Fedora is also encouraged, especially if the upstream is dead. Python SIG is available to help with porting. Packaging guidelines will be updated to reflect that packaging for Python 3 only is the default. Instructions for Python 2 and dual-support will be moved to the Appendix. Python 2 will be marked deprecated (see https://fedoraproject.org/wiki/Packaging:Deprecating_Packages) Any package that only provides a Python 2 importable module may be marked as deprecated as well if the maintainer(s) want to. == Benefit to Fedora == A giant pile of unneeded software running on a legacy interperter will be removed from Fedora before the interpreter stops being supported upstream. While we would very much like to remove Python 2 entirely, this way we are not breaking Fedora, and we can accomodate some exceptions. == Scope == * Proposal owners: ** Provide a list of packages to remove ** Collect feedback from affected packagers ** Retire the python2 only packages ** Remove python2 subpackages from dual-python packages * Other developers: ** Ask for packages to be removed from the list if needed (with reasons). ** Remove python2 subpackages from dual-python packages (not needed, but helpful) ** Optionaly mark remainign python2 packages deprecated * Policies and guidelines: ** Python packaging guidelines will be changed to only describe Python 3 ** Python 2 and dual-support packaging will be moved to the appendix ** Only packages providing additional features different than importable modules will be allowed to be added in Fedora (with exception for dependenecies of other packages) ** Python 2 will be marked deprecated https://fedoraproject.org/wiki/Packaging:Deprecating_Packages * Trademark approval: not needed for this Change == Upgrade/compatibility impact == Packages removed form Fedora repos will remain on the installed OS until explicitly removed by the user or obsoleted by the packagers. We'll only obsolete packages that would break upgrade (from fedora-obsolete-packages). == How To Test == Any program written in Python and any program that has Python plugins could potentially be influenced by this change. Testing is different for software that is still using Python 2 and for software that has been switched to Python 3. For any ''python2'' programs, make sure those programs are still functional after the package removal. Since various packages that are no longer built will not be removed from an existing system, just upgrading and checking packages is not enough. Either a new installation should be used, or after a branching point, any packages which haven't been rebuilt for F30, so any packages with .fc29 or lower release suffix should be removed from the system before testing. For the ''python3'' programs, install all upgrades and check if the software works. Upgrade failures because of missing dependencies should be treated as bugs. Any removed python2 subpackages which break upgrades need to be added to Obsoletes in fedora-obsolete-packages. == User Experience == There will be less Python 2 RPMs in Fedora repos. Users are encouraged to switch to Python 3 and/or use Python 2 virtual environments and pip for development. == Dependencies == Ideally, all programs that use python2 would be switched to use python3. Although we don't expect everything to be switched over, as much as possible should be, so that the set of remaining python2 subpackages is as small as possible. == Contingency Plan == * Contingency mechanism: ** If for some reason not everything is removed, nothing happens, it can be removed later. If for some reason something breaks, some packages can be unretired or restored. ** If someone steps up to maintain Python 2 (including the full ecosystem of packages now in Fedora), they can decide to discontinue removing packages, revert the Change, or come up with another plan. (Note that in this case, current maintainers will most likely orphan many fundamental python2 packages.) == Documentation == This page is the main documentation. Also see: https://pythonclock.org/ -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

4 4

Intel's Clear Linux optimizations
by František Zatloukal 08 Feb '19

08 Feb '19

Hi, Phoronix recently release article[1] about Intel's Clear Linux with some cool graphs showing nice performance gain compared to Xubuntu. I didn't have time to dig in and look how it's performing against Fedora, but I'd assume Fedora can be compared to Xubuntu in terms of compiler settings. I think i'll be interesting to look into it and find out if Fedora can't tweak compiler settings (eg use LTO for critical things like Mesa, Kernel, ...). I think it could be interesting fo Fedora users to have this enabled if there are not any disadvantages other than compile time, compile memory usage and so on. What do you think? [1] http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1 -- Best regards / S pozdravem, František Zatloukal Project Coordinator Red Hat

15 50

Fedora 30 System-Wide Change proposal: Ruby 2.6
by Ben Cotton 28 Jan '19

28 Jan '19

https://fedoraproject.org/wiki/Changes/Ruby_2.6 == Summary == Ruby 2.6 is the latest stable version of Ruby. Many new features and improvements are included for the increasingly diverse and expanding demands for Ruby. With this major update from Ruby 2.5 in Fedora 29 to Ruby 2.6 in Fedora 30, Fedora becomes the superior Ruby development platform. == Owner == * Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]] * Email: vondruch(a)redhat.com, pvalena(a)redhat.com == Detailed Description == Ruby 2.6 is upstream's new major release of Ruby. Many new features and improvements are included. === JIT === Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler. JIT compiler aims to improve performance of any Ruby program execution. Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native code. The main purpose of this JIT release is to provide a chance to check if it works for your platform and to find out security risks before the 2.6 release. JIT compiler is supported when Ruby is built by GCC, Clang, or Microsoft VC++, which needs to be available on runtime. Otherwise you can’t use it for now. As of Ruby 2.6.0 preview3, we achieved 1.7x faster performance than Ruby 2.5 on CPU-intensive non-trivial benchmark workload called Optcarrot. The performance on memory-intensive workload like Rails application are going to be improved as well. === RubyVM::AST [Experimental] === Ruby 2.6 introduces `RubyVM::AST` module. This module has `parse` method which parses a given ruby code of string and returns AST (Abstract Syntax Tree) nodes, and `parse_file` method which parses a given ruby code file and returns AST nodes. `RubyVM::AST::Node` class is also introduced. You can get location information and children nodes from `Node` objects. This feature is experimental. Compatibility of the structure of AST nodes are not guaranteed. === New Features === * Add a new alias `then` to `Kernel#yield_self`. * Add `Random.bytes`. * Add `Binding#source_location`. This method returns the source location of binding, a 2-element array of __FILE__ and __LINE__. * Add `:exception` option to let `Kernel.#system` raise error instead of returning `false`. * Add a new alias then to `Kernel#yield_self`. * `else` without `rescue` now causes a syntax error. [EXPERIMENTAL] * Constant names may start with a non-ASCII capital letter. * An endless range, (1..), is introduced. It works as it has no end. === Performance improvements === * Speedup `Proc#call` because we don’t need to care about $SAFE any more. With `lc_fizzbuzz` benchmark it makes x1.4 speed improvement. * Speedup `block.call` where block is passed block parameter. Ruby 2.6 improves the performance of passed block calling. There can observed 2.6x improvement with micro-benchmarks. * Transient Heap (theap) is introduced. theap is managed heap for short-living memory objects which are pointed by specific classes. For example, making small and short-living Hash object is x2 faster. With rdoc benchmark, 6-7% performance improvement is observed. === Other notable changes since 2.5 === * `$SAFE` is a process global state and we can set `0` again. * Passing `safe_level` to `ERB.new` is deprecated. `trim_mode` and `eoutvar` arguments are changed to keyword arguments. * Merged RubyGems 3.0.0.beta2. * Merge Bundler as default gem. == Benefit to Fedora == With a latest release, Ruby language is supporting the newest language features, which enables even faster and easier development of Ruby applications. == Scope == * Proposal owners: ** Finish packaging of Ruby 2.6. Current changes available in PR https://src.fedoraproject.org/rpms/ruby/pull-request/32 ** Rebuilding of Ruby packages providing native extensions (i.e. packages which depends on libruby). . * Other developers: ** Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 2.6 properly. * Release engineering: [https://pagure.io/releng/issue/7936 #7936] ** Separate Koji tag for package rebuild will be needed. * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * User specific Ruby binary extensions need to be rebuild. == How To Test == * No special hardware is needed. * To test, install Ruby 2.6. The test builds are pusblished in PR or on Ruby-SIG ML * Try to locally rebuild your packages using Ruby 2.6. * Use the packages with your applications previously written in Ruby. * If something doesn't work as it should, let us know. == User Experience == The Ruby programs/scripts should behave as they were used to. == Dependencies == <pre> $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq | wc -l 156 </pre> == Contingency Plan == * Contingency deadline: Mass Rebuild * Blocks release? No * Blocks product? No == Documentation == * [http://www.ruby-doc.org/ Help and documentation for the Ruby programming language] * [https://github.com/ruby/ruby/blob/v2_6_0_preview3/NEWS Ruby 2.6.0.preview3 NEWS] == Release Notes == * The Ruby 2.6 bumps soname, therefore Ruby packages, which use binary extensions, should be rebuilt. Nevertheless, since upstream paid great attention to source compatibility, no changes to your code are needed. https://github.com/ruby/ruby/blob/trunk/NEWS -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

2 2

Installation image layout
by Marek Marczykowski-Górecki 16 Jan '19

16 Jan '19

Hi all! I'm new on this list. I work on Qubes OS, where Fedora is used as a base distribution. While trying to build the installation image in reproducible manner[1], I found the current installation image have unusual layout. Quoting dracut.cmdline manual page: squashfs.img | Squashfs from LiveCD .iso downloaded via network !(mount) /LiveOS |- rootfs.img | Filesystem image to mount read-only !(mount) /bin | Live filesystem /boot | /dev | ... | This rootfs.img layer makes the image build very much unreproducible. Why is it even there? Bare squashfs.img layer should be enough. Then, mount overlayfs over it (I see there is even some partial support for it in dmsquash-live). Most other Live systems I've seen use just squashfs + overlayfs (or aufs if kernel is older), so it's commonly tested configuration. I *guess* it's there for historical reason, from before aufs/overlayfs being available. Is there any other reason for that? If there is no other reason, I propose to drop this and have installer/live filesystem directly in squashfs.img. This have multiple benefits: - it's much easier to make the image build process reproducible (see below) - less complexity, both in the build and in the boot (the whole dmsquash-live dracut module can be replaced with <20 line function[2] - smaller initramfs (which is extremely important if needed to be included in efiboot.img, which can't be larger than 32MB) - slightly faster boot time (device-mapper is slow) What do you think? As for the reproducibility, I've made changes to lorax (including dropping rootfs.img layer), anaconda, pungi and createrepo and this all allows to build bit-by-bit identical image, given the same input (rpm packages, pungi configuration, $SOURCE_DATE_EPOCH variable[3]). Well, almost - there is an issue with efiboot.img, but I already have a solution, just not pushed it yet. You can find all the pull requests collected here: https://github.com/QubesOS/qubes-installer-qubes-os/pull/26 I'll work further to make the changes merged upstream. [1] https://reproducible-builds.org/ [2] https://github.com/QubesOS/qubes-installer-qubes-os/pull/26/commits/332be8e… [3] https://reproducible-builds.org/specs/source-date-epoch/ -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

9 19

Bodhi update pushes are now automated
by Mohan Boddu 08 Jan '19

08 Jan '19

Hello all, For a long time now updates are pushed manually everyday. It was troublesome and someone has to own it for a week and look after it. Now, the pushes are automated and are pushed everyday at 00:00 UTC. If anything fails there will be an oncall person (same person who used to do the pushes) who will take care of the failure. During release freezes these automated pushes are disabled and are manually pushed by RelEng/Infra. Since freezes should be handled differently this will give RelEng more control over the pushes. Please let us know if you have any questions or contact us on #fedora-releng on Freenode. Thanks, Mohan Boddu. _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

15 18

Lifecycle objective - problems, solutions, and proposal
by Paul Frields 06 Jan '19

06 Jan '19

I worked with FPL Matthew Miller and our engineering manager Jim Perrin, among others, to define the various problems we want to solve in diversifying the Fedora lifecycle. We're seeking review and feedback from community members. The most salient feedback will be from those involved in the efforts we describe, but we welcome all constructive feedback. Here's the summary from the page, which proposes we pause the release after F30 for these efforts: * * * Fedora’s singular lifecycle has been in place for almost a decade and a half. During that time, technology users have changed how they consume platform and applications. Fedora needs to be more toward the forefront of these changes. But more importantly, Fedora needs to be more hospitable to community management of lifecycle. Currently Fedora can’t scale for more community ownership of the things we release: (1) Only a few people can build and push out releases; and (2) we manage releases largely based on that staffing. The Fedora community should be able to run releases of content themselves, using tools that work well, with only minimal oversight, and determine their own schedule for doing so. This implies a great deal of both redesign and reworking of tools and processes. To unblock the community, several things need to happen. We need a faster, more scalable compose to enable CI/CD operations; we need to automate more testing and quality measures; and we need to update our delivery tools and processes. We also need to track and coordinate this work across teams, since it involves collaboration among Fedora infrastructure, QA, applications, release engineering, CentOS CI, maintainers, and more. We should skip the F31 release cycle and leave F30 in place longer in order to focus on improving the tooling and testing changes. These tooling changes will improve the overall reliability of Fedora, and will decrease the manual effort and complexities involved in producing the distribution artifacts. Although we’ve done this before to make “editions” happen, the intent is to track this multi-team effort more actively so we can (1) use the time as well as possible, and (2) give the work maximum transparency. * * * The full page is here, with a set of problems, solutions, and actions proposed. I invite you to take time to read it in detail: https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements I also attached that page to the main Lifecycle objective page here, which was previously approved by the Council: https://fedoraproject.org/wiki/Objectives/Lifecycle Rather than try to spin this one email into a thread of doom that people will give up on reading, I encourage those with feedback to open a thread for any particular topic. That way the community discussion should be more useful for all. I'll collect input and use it both for responses and to help tweak plans for (hopefully) optimal results. I'm on vacation next week, for which timing I apologize. But I'll try to look at mail here from time to time and when I return. -- Paul

30 92

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2018