Proposed F19 Feature: Enlightenment - Integrate Enlightenment in Fedora
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/Enlightenment = https://fedoraproject.org/wiki/Features/Enlightenment * Detailed description: Enlightenment 0.17 a new stable release has been released after 12 years or so of development. The goal is to include all of the Enlightenment Foundation Libraries, the Enlightenment window manager and the integrated apps like Terminology as part of Fedora. All the essential packages are already filed for review. For the set of packages under review, see Feature page. Please, see also the Talk page https://fedoraproject.org/wiki/Talk:Features/Enlightenment Jaroslav ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
As the Feature was renamed and the content of Feature has been extended as requested by FESCo, re-announcing it to the community for re-review. See https://fedorahosted.org/fesco/ticket/986 = Features/Fix Network Name Resolution = https://fedoraproject.org/wiki/Features/FixNetworkNameResolution * Detailed description Currently the getaddrinfo() function doesn't work as it was desinged. Many of its features are buggy and cannot be used without extensive workarounds. Many software packages are using getaddrinfo() with such workarounds. Many can trigger its failures. And many packages that don't use getaddrinfo() will be ported in the near future. - Rationale We are submitting this bug fixing effort as a Feature because: It is a high-impact change that will (positively) affect allmost all networking software Developers will be able to use getaddrinfo() without ugly workarounds for new code We are going to publish guidelines for proper getaddrinfo() usage Documentation for getaddrinfo() bugs will be availabe Possible workarounds will be offered for backward compatibility Comments and errata will be sent to standards organizations We want to recieve critical response during the whole process It will be part of the next networking testweek - Problem statement The behavior of getaddrinfo() is often nonstandard, undocumented, surprising, or just plain wrong. We already indentified a number of problems. The most prominent examples are here. getaddrinfo() may return duplicate or even wrong addresses from /etc/hosts getaddrinfo() with NULL servname may return duplicate addresses getaddrinfo() with AI_PASSIVE may still return address list not suitable for bind() getaddrinfo() with AI_ADDRCONFIG may fail to translate literal addresses getaddrinfo() with AI_ADDRCONFIG may fail to resolve /etc/hosts addresses getaddrinfo() with AI_ADDRCONFIG may send unwanted queries getaddrinfo() has a bad choice of default flags/code Whether or not the problematic actually occurs depends on /etc/hosts configuration, /etc/resolv.conf configuration, getaddrinfo() input parameters, runtime kernel network interface configuration, and more. While testing the known bugs or reading the source code, more and more bugs are discovered. Bug reports related to getaddrinfo() can be found upstream: http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo -Affected software The above problems affect software that wants to use getaddrinfo() to: Get parameters for connect() or sendto() to start communicating Get parameters for bind() to listen on specific addresses Build IP address based accesslists Perform name resolution for other purposes Although it would be nice to also test and fix all software in Fedora using getaddrinfo(), that is not feasible. Therefore we are going to concentrate on checking and fixing the GNU C library, checking and fixing the most important toolkits dealing with networking, and documenting a set of guidelines for daemons and application software. Fedora bugs related to dualstack networking including name resolution problems should be added to the following tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=883152 - Original Message - As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/DualstackNetworking = https://fedoraproject.org/wiki/Features/DualstackNetworking * Detailed description Fedora supports dualstack global networking. That means the computer with Fedora is connected to internet using both IPv4 and IPv6 protocols. But many important system services and applications either don't do IPv6, do it incorrectly, or don't cope with various network conditions. Unfortunately, while trying to improve IPv6 support, some IPv4 use cases became broken as well. That's why the goal of this feature is not only to support IPv4, but to support all possible real-world cases. Dualstack-ready software must cope with all possible scenarios including IPv4-only connectivity, IPv6-only connectivity and dual connectivity. The software must also cope with node-local (aka localhost) networking, which as been used by software for decades. Though it would be nice to have all applications in Fedora fixed to work in any of the scenarios, it is not feasible to test that. Therefore this feature is about major software used in servers, desktops and laptops. The list of such applications will be completed over the time. Bugs related to dualstack networking should be added to the following tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=883152 Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker ___ devel-announce mailing list
Proposed F19 Feature: RemovePyXML - the goal of this Feature is to remove the PyXML package from Fedora
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/RemovePyXML = https://fedoraproject.org/wiki/Features/RemovePyXML * Detailed description: PyXML has been dead upstream for many years. The main authors of it have stated this explicitly on the python-dev mailing list. It's successor, the python stdlib's xml module, has been getting bugfixes that PyXML has not. The current Fedora package maintainer (rrakus) asked about removing it in February, 2012. The Python stdlib in python2.x also has the dubious behaviour of importing PyXML if it is installed and replacing its own code with PyXML's. In some cases, this leads to bugs (For instance: Eric bug, Docutils bug) as the old PyXML code does not cope with some usages that the version in the stdlib does. We want to remove this package from Fedora. To do that we need to decide what happens to the packages that depend on it. After analyzing the packages that use it, most of them will be ported to another xml library as part of this Feature. However, a few packages will be dropped from Fedora instead. -- PS: CC'ing the maintainer of PyXML, he's aware of this Feature and he is ok with the proposal ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Proposed F19 Feature: Boost 1.53 Uplift - brings Boost 1.53.0 to Fedora 19
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/F19Boost153 = https://fedoraproject.org/wiki/Features/F19Boost153 * Detailed description: That feature aims at synchronising the top of the Fedora tree with the current Boost upstream release. The current Fedora release is boost-1.50.0. As of Fedora 13, the canonical sources used for the package switched from the official Boost release (with BJam build) to an alternate repository (with CMake build, for boost-1.41.0). That alternate repository has been deprecated and may be deleted any time soon (as of January 2013). boost-1.41.0 has been delivered from that (now deprecated) Boost-CMake repository (hosted on Gitorious), where the code base had slightly diverged from upstream. From Fedora 14, boost-1.44.0 has been rebased on upstream, with a mere patch implementing CMake support. Moreover, there is a new Git repository reflecting those changes, hosted on GitHub (and cloned on Gitorious). That repository relies on the Ryppl project (in particular, on the Boost Subversion replicated repository), created and maintained by two Boost developers, namely Eric Niebler and Dave Abrahams. From Fedora 18, boost-1.50.0 was rebased back to Boost.Build v2, as keeping two distinct build systems sometimes conducted to two distinct binary distributions, for instance, when compared to Debian/Ubuntu deliveries. Note that upstream Boost has decided, at the end of 2012, to switch to: Git repository, with GitHub as one of the main hosting services and project management facilities (later on, when the switch to Git will be stable enough) a modularized organisation, and CMake as the primary build system, replacing BJam/BBuild The objective is now to keep delivering the latest stable Boost release for each new Fedora release. ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
