devel-announce March 2014

devel-announce@lists.fedoraproject.org

7 participants
34 discussions

F21 Self Contained Change: Add amd map parser to autofs
by Jaroslav Reznik 06 Mar '14

06 Mar '14

= Proposed Self Contained Change: Add amd map parser to autofs = https://fedoraproject.org/wiki/Changes/Add_amd_map_parser_to_autofs Change owner(s): Ian Kent <raven(a)themaw.net> The am-utils package provides automount services for automount maps that use an amd format. However, the am-utils project has not been actively maintained for quite a while now. The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package. == Detailed Description == The am-utils package provides automount services for automount maps that use an amd format. Unfortunately the am-utils project has not been actively maintained for quite a while now. The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package. The goal is to implement enough of the am-utils amd map parsing functionality to cover a large portion of the use cases provided by the am-utils package. Once this is done it will be up to users to describe the missing am-utils feature they need which will then be considered for addition in the upstream implementation. == Scope == The implementation of this functionality is restricted to the autofs package. Some areas of this change will require changes to code common to the autofs parser and the amd parser and the amd parser will leverage existing autofs functionality but there is a high level of code separation because of the way parse modules are added to autofs. Initially the change will be added as a path series to the autofs package, later when an upstream beta is released the source will be updated, finally when autofs-5.1.0 is released the source will updated again. The release schedule has not been decided yet but the plan is to release a beta soon followed by 5.1.0 with the timing dependant on community feedback. Not all the changes (planned for 5.1.0 but not the amd parser itself) will be included in 5.1.0, they will be added as time permits via minor version updates. This is because the amd parser is considered an important feature and needs to be made available sooner rather than later. * Proposal owners: upstream the change is nearly ready to be committed to the master branch and a beta released. If the beta is released soon enough updating the Fedora autofs package source is all that will be needed. If not then the existing patch series can be added to the autofs package in the mean time. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change)

1 0

F21 System Wide Change: cron to systemd time units
by Jaroslav Reznik 04 Mar '14

04 Mar '14

= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units Change owner(s): Jóhann B. Guðmundsson <johannbg AT gmail DOT com> Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units. == Detailed description == Add dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units in packages that already depend on systemd. == Scope == * Policies and guidelines: ** Adjust packaging guidelines to fix dependency in cron packages [Package Cron Files 1] DONE ** Adjust packaging guidelines to mention migration of cron jobs to timer units for packages that already depend on systemd * Fix spec files in packages that are not applicable for migration [Fix Cron Dependency Tracking Bug 2] * Review and migrate if applicable cron jobs shipped in packages that already depend on systemd [Timer Migration Tracking Bug 3] * Update systemd wikipage to contain timer units example [1] https://fedoraproject.org/wiki/Packaging/CronFiles [2] https://bugzilla.redhat.com/show_bug.cgi?id=947037 [3] https://bugzilla.redhat.com/show_bug.cgi?id=991679

1 0

F21 Self Contained Change: Lohit Odia Gurumukhi font naming
by Jaroslav Reznik 03 Mar '14

03 Mar '14

= Proposed Self Contained Change: Lohit Odia Gurumukhi font naming = https://fedoraproject.org/wiki/Changes/Lohit_Odia_Gurumukhi Change owner(s): Pravin Satpute <psatpute(a)redhat.com> This is a change to make Lohit Oriya fonts name as per the guidelines by Odisha governement and improve Lohit Punjabi font name to avoid confusion between Arabic and Gurumukhi script fonts. It will change Lohit Oriya fonts to Lohit Odia and Lohit Punjabi to Lohit Gurumukhi. == Detailed description == Lohit fonts upstream is going to change two fonts name. Font name changes and detailed information is as follows Lohit Oriya to Lohit Odia: Odia language name was improperly translated and written as a Oriya. This has been corrected by Government of India in 2011 and it is called as a Odia now. Reference for same [1]. Discussion regarding same happened in Lohit fonts upstream [2] and it has been decided to change Lohit Oriya fonts name to Lohit Odia. Lohit Punjabi to Lohit Gurumukhi: Punjabi is a language and written by two script Arabic and Gurumukhi. Generic font name like Punjabi often create confusion whether this font is belonged to writing Punjabi in Arabic script or Gurumukhi script. It has become important to change font name from Lohit Punjabi to Lohit Gurumukhi. Lohit upstream has already accepted this change [3] and looks will release fonts with this name. == Scope == Developers need to accomplish following things. * Upstream release with proposed font name changes. * New package request with corrected font names in upstream in Fedora by obsoleting existing packages. * Notifying Anaconda and Libreoffice langpacks to install renamed packages. Proposal owners: * Working in upstream for release with names * new package request. * notifying package using Lohit fonts for updating it. Other developers: N/A (not a System Wide Change) * Anaconda need to update default fonts installation list. * Libreoffice lang pack requires need to change. Release engineering: No, mass rebuild required. Policies and guidelines: No change in policies and guideline. Change Wrangler note: a wider coordination is required for this Change but the scope is limited and will be covered by Change Owner. [1] http://www.ndtv.com/article/india/parliament-passes-bill-to-change-orissa-s… [2] http://www.redhat.com/archives/lohit-devel-list/2013-December/msg00001.html [3] http://www.redhat.com/archives/lohit-devel-list/2013-December/msg00009.html

1 0

F21 Self Contained Change: Allwinner sunxi (A10 / A13 / A20) ARM SoC support
by Jaroslav Reznik 03 Mar '14

03 Mar '14

= Proposed Self Contained Change: Allwinner sunxi (A10 / A13 / A20) ARM SoC support = https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport Change owner(s): Hans de Goede <hdegoede(a)redhat.com>, Peter Robinson <pbrobinson(a)fedoraproject.org > Allwinner A10 / A13 / A20 SoCs are used in a number of popular low cost arm development boards and arm mini computers. Currently Fedora ARM is supported on these devices through a Remix [1]. Allwinner kernel support is progressing rapidly upstream, and with this upstream kernel support it should be possible to support Allwinner SoCs in the official Fedora ARM images, without the need for a remix. == Detailed description == The linux-sunxi community is currently working hard to get Allwinner SoCs supported in the upstream kernel. A big part of this should land in the 3.14 kernel. The plan is to support Allwinner SoCs in headless mode for now, and carry patches for mmc, ahci and usb support for 1-2 kernel releases (until they land upstream). == Scope == Supporting Allwinnner SoCs ootb will require kernel and u-boot support. Kernel support is landing upstream and we will add patches to the Fedora kernel for 1-2 kernel releases to supplement this. u-boot support currently lives in a u- boot fork upstream, this fork is tracking / merging u-boot upstream and does intent to get sunxi support merged into the official u-boot packages, but there is no timeline for this atm. For u-boot we will create a separate u-boot-sunxi package, which can be dropped once u-boot support has been merged into u-boot upstream. Proposal owners: Will try to get as much kernel support upstream as possible, supplement with patches in the Fedora kernel package. Will create a u-boot- sunxi package with sunxi specific u-boot. Will look into adding a config tool to the sdcard images to easily select and install the correct u-boot and dtb, like the Allwinner Remix images have. Other developers: N/A Release engineering: N/A Policies and guidelines: N/A [1] https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2014