devel January 2018

devel@lists.fedoraproject.org

239 participants
308 discussions

Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache
by Samuel Rakitničan 04 Jan '18

04 Jan '18

If I am not mistaken, EPEL still needs quite large chunk of such scriptlets[1]. What would be the best way to maintain a SPEC file for both. https://fedoraproject.org/wiki/EPEL:Packaging#Scriptlets

3 2

F28 System Wide Change: GHC 8.2
by Jan Kurik 04 Jan '18

04 Jan '18

= System Wide Change: GHC 8.2 = https://fedoraproject.org/wiki/Changes/GHC_8.2 Change owner(s): * Jens Petersen <petersen AT redhat DOT com> * Haskell_SIG <haskell AT lists DOT fedoraproject DOT org> Update the Haskell GHC compiler from major version 8.0.2 to 8.2.2. == Detailed Description == This change involves updating the GHC Haskell compiler in Fedora to the latest major version and rebuilding all the Haskell packages in Fedora with it. GHC 8.2 bring a number of important performance improvements and new features, including improved DWARF support and support for the Backpack modular packaging system. There are more details the upstream release notes linked below. == Scope == * Proposal owners: rebuild updated Haskell packages in f28-ghc - we will base package versions off [LTS 10] - installation of shared libraries in common directory to speed up startup of executables * Other developers: None really, Haskell SIG can rebuild all packages as far as possible * Release engineering: https://pagure.io/releng/issue/7216 * List of deliverables: Updated Fedora packages * Policies and guidelines: None planned, but will review * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F28 Self Contained Change: Korean Default Fonts to Google Noto
by Jan Kurik 04 Jan '18

04 Jan '18

= Proposed Self Contained Change: Korean Default Fonts to Google Noto = https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto Change owner(s): * Akira TAGOH <tagoh AT redhat DOT com> Changes the default fonts for Korean to Google Noto. == Detailed Description == Changes the default fonts for Korean to Google Noto. each typefaces will be changed as the following: * sans-serif * * VL Gothic -> Noto Sans KR * serif * * (No default serif) -> Noto Serif KR * monospace * * VL Gothic -> Noto Sans Mono CJK KR == Scope == * Proposal owners: - Update packages with proper priority of fontconfig config file (naver-nanum-gothic*fonts and google-cjk-noto-*-kr-fonts) - Update comps * Other developers: N/A (not a System Wide Change) * Release engineering: #7225: https://pagure.io/releng/issue/7225 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F28 Self Contained Change: Japanese Default Fonts to Google Noto
by Jan Kurik 04 Jan '18

04 Jan '18

= Proposed Self Contained Change: Japanese Default Fonts to Google Noto = https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto Change owner(s): * Akira TAGOH <tagoh AT redhat DOT com> Changes the default fonts for Japanese to Google Noto. == Detailed Description == Changes the default fonts for Japanese to Google Noto. each typefaces will be changed as the following: * sans-serif * * VL Gothic -> Noto Sans JP * serif * * (No default serif) -> Noto Serif JP * monospace * * VL Gothic -> Noto Sans Mono CJK JP == Scope == * Proposal owners: - Update packages with the proper priority of fontconfig config file (vlgothic*fonts and google-cjk-noto-*-jp-fonts) - Update comps * Other developers: N/A (not a System Wide Change) * Release engineering: #7224: https://pagure.io/releng/issue/7224 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

GSoC Organization Applications Open Today
by Brian Exelbierd 04 Jan '18

04 Jan '18

Hi All, I am going to start working on the Fedora GSoC Organizational application. I will also work on the structure for suggesting projects. # If you want to mentor Please use this time to start thinking about potential projects for GSoC Students. There are no wiki pages to update yet - you'll hear about those soon. (I think we might try something new this year to try and get more feedback on ideas). # If you want to help in a general or administrative way Contact me directly off list and we can figure out what works for you regards, bex

1 0

F28 Self Contained Change: Fontconfig 2.13
by Jan Kurik 04 Jan '18

04 Jan '18

= Proposed Self Contained Change: Fontconfig 2.13 = https://fedoraproject.org/wiki/Changes/Fontconfig_2.13 Change owner(s): * Akira TAGOH <tagoh AT redhat DOT com> Update fontconfig package to the latest version. == Detailed Description == Update fontconfig package to the latest version which contains the following features and bug fixes: * config file description support * allow sharing caches under the bind-mounted dirs * improve footprint on creating caches * variable fonts suppport == Scope == * Proposal owners: Package new version of fontconfig bug fixes (if any) Other developers: N/A (not a System Wide Change) Release engineering: #7223: https://pagure.io/releng/issue/7223 List of deliverables: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fwd: Retiring OmegaT and considerations about its dependencies
by Ismael Olea 04 Jan '18

04 Jan '18

Just reporting these actions: Retired package: - https://src.fedoraproject.org/rpms/OmegaT/ Orphaned packages: - https://src.fedoraproject.org/rpms/vldocking - https://src.fedoraproject.org/rpms/svnkit/ - https://src.fedoraproject.org/rpms/sqljet/ - https://src.fedoraproject.org/rpms/gnudiff/ - https://src.fedoraproject.org/rpms/sequence-library/ - https://src.fedoraproject.org/rpms/htmlparser/ Transfered main admin packages: - https://src.fedoraproject.org/rpms/snip/ - https://src.fedoraproject.org/rpms/jsap/ - https://src.fedoraproject.org/rpms/rundoc FYI ---------- Forwarded message ---------- From: Ismael Olea <ismael(a)olea.org> Date: Wed, Jan 3, 2018 at 2:41 PM Subject: Retiring OmegaT and considerations about its dependencies To: Discussion list for java related Fedora development < java-devel(a)lists.fedoraproject.org> Hi all: I delayed this for time enough. It's impossible to me to keep updated OmegaT in Fedora. Their development rhythm is pretty nice but they are adding frequent new dependencies and I can't make the effort to add them to Fedora. The good part is I'm working in the Flatpak approach which is less strict with dependencies and is multidistro too so Fedora users will get an alternative in the coming weeks.. Retiring OmegaT bring to discuss what to do with the dependencies which I honestly prefer to abandon. This is the situation: Packages to retire: - OmegaT, for the explained reasons (last version in Fedora: 2.6.3, last version upstream: 3.6.0/4.1.3) - svnkit, only used by OmegaT and broken in the current Fedora version - sqljet, only required by OmegaT and svnkit, broken in Fedora too - sequence-library, only required by svnkit and broken too OmegaT exclusive dependencies to be orphaned/retired: - gnudfif - htmlparser - vldocking OmegaT dependencies I want to delegate bc used by other package: - jsap, used by java-wakeonlan Actions: - Since I supposed there would be no interest on them I'll retire OmegaT, svnkit, sqljet and sequence-library - I'm gladly transfer maintenance of gnudiff, htmlparser and vldocking to anyone interest, so I'm going to orphan them - This message is cc:'d to Leamas, the maintainer of java-wakeonlan to offer him the ownership, if he declines I'll orphan it too. I'm open to your feedback, if any. Thanks! -- Ismael Olea http://olea.org/diario/ -- Ismael Olea http://olea.org/diario/

1 0

src.fedoraproject.org pull request merging
by Florian Weimer 04 Jan '18

04 Jan '18

How is this supposed to work? I clicked on Merge in: https://src.fedoraproject.org/rpms/glibc/pull-request/3 But the task remains in the PENDING state, apparently indefinitely: “ Waiting We are waiting for your task to finish. This page should be refreshed automatically, but if not click Here Your task is currently PENDING ” Thanks, Florian

2 1

Specs coding standard (Was: Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache)
by Tomasz Kłoczko 04 Jan '18

04 Jan '18

On 3 January 2018 at 22:51, Adam Williamson <adamwill(a)fedoraproject.org> wrote: [..] > If you still want to do it, I mean, you do you, but it would be a > *terrible* idea to bundle clear and obvious technical improvements in > with the idea of some kind of spec style guide (and enforcement). > Please treat it as an entirely separate proposal. Thanks. I'm not proposing such spec style guide in native language. This could be done by simple indentation script over which must be filtered every spec file. I've already posted example of such script. This script needs to be updated (because in this form it was used more than decade ago) then used. On first time all spec files should be used and each new enhancements. Indentation is it is not a mater personal preferences. It is the same IMPORTANT as using exact indentation in C or other languages source code. it makes spec files code easier to read and understand by other people. It makes easier to find bugs by simple relaying on some coding patterns. I remember that on start use such indentation tool was possible not only bring the same style but find as well some number spec of CODING BUGS. Generally what I'm proposing is not kind of revolution but more evolution by use initially only few coding patterns which I've already listed like: - put in exact order spec fields in spec preamble - format all %description to 80 cols - put in spec exact order of %packages, %files and other sections - substitute exact strings to use macros After this such list can be extended and each time after passing agreement/voting to use exact new patterns all specs should be changed in one go. At some point on git server side this script could be hooked into commit filters to refuse commits of the specs if this script will be able to add some changes. In other words apply exact coding standard should be kind of continuous process. kloczek PS. I was wrong that it will be possible to modify 90% of the specs automatically. In reality proportions are completely opposite and only less than 10% is possible to change using some text substitution. This is clear indicator how really bad is with all Fedora spec common coding standards. -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

1 0

RPM for libblocksruntime?
by Ron Olson 04 Jan '18

04 Jan '18

Hi all- I know this has come up before, though I apologize that I couldn't find the info, but what is preventing Fedora from including "libblocksruntime" as an available RPM? Debian provides it: https://packages.debian.org/source/jessie/libblocksruntime and it's a requirement for compiling Apple's Swift programming language on Fedora. If it's just a question of somebody doing it, I'm happy to volunteer assuming there isn't some hard-block that would prevent it from being accepted. Ron

2 1

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 January 2018