devel January 2019

devel@lists.fedoraproject.org

211 participants
259 discussions

Non-responsive maintainer - Mosaab Alzoubi
by Vitaly Zaitsev 14 Feb '19

14 Feb '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! According Non-responsive Maintainer Policy I'm asking the maintainer to respond second time and resolve issues with package goldendict. RHBZ tickets: https://bugzilla.redhat.com/show_bug.cgi?id=1667084 and https://bugzilla.redhat.com/show_bug.cgi?id=1594569 Proposed PR with fix: https://src.fedoraproject.org/rpms/goldendict/pull-request/1 - -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org) -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEGFSlHDlYR1Xq8pxov5n8bdRauQoFAlxEPjsACgkQv5n8bdRa uQpOLhAAlqcuEaRpsKkdO27Qi3XIq6BH2cmUzshQKqW98uYoP3QxepI2X1jaZ5sJ IbbROzvu2ZyOQYlWAecV1LSNgO9zDuHSC2SKhOThGa5HguGZJRtrCyILLU0w3IeD cCOpRaTy1Zg1MfaqsEqb9bZe/Fz7dzOpuVTE2HQ/YDDlwe6iA1iqAIpD1CBK2yNT qcghrpQQtZweFb72fbPbSgnE8k4GBvzYaTtbxxP1ZaXoiZqKTgwUFrFVecT9+CuR /5ffcFh38o4mb1pP8c0VjJCioSv9qf7achY0IlaZhQsC7XB+VkUH11hdoKlUC1az 9Ws8g+DFHB0Z8roUBrSQWM2hX8m+jPQqTAjE5QtGgdveggdUvII7dMIIbSLjr3hw /SrfKin6ALNvanumma02eZw93tv+YXR+uvT1HzMC/iaFwoclbFMsbUYn5gbr4viR ukJLJgN/L1w/NNI63BU3JYsuH9LC9GOY/bmyeK4w1L7zkIdL3atCyUv2QrJ+JI4e IXvmO6eIwJOENLcT9D8YUA6GSftE4nUeiWU7QT02/51vm6BLJSu53KiW8BMtD0Ij W5+oltdb6X0PRm+mzDfkgweh1kn26bHCMTM/SZUVtKxPHVHW6VYKombXDtJgwbDt BLTdGcGKBhCpcdr41EWt8BzzzcnQMnJIXNQwCThccYtXyAJn9zA= =fkRA -----END PGP SIGNATURE-----

2 1

MBI (Playground 2.0)
by Igor Gnatenko 14 Feb '19

14 Feb '19

MayBe I …(can do something useful)? Hello, We've been discussing some (hopefully) nice idea with Mikolaj, Neal and Jakub how we could improve packager (and user) experience and we have some proposal which will be described below. We would like to ask you to read it, understand it and ask us any questions you have. From the Fedora Infrastructure we would like to ask for some machines to implement this idea (you can find some more information in "Implementation details" part). I would like to apologize for HTML email, but it is much easier to have it that way to have better visibility and reading easiness. Feel free to reply to this email or comment in google doc (there is a link on the bottom). Proposal Owners - Mikolaj Izdebski (mizdebsk) <mizdebsk(a)redhat.com> - Java SIG, Fedora infrastructure - Igor Gnatenko (ignatenkobrain) <ignatenkobrain(a)fedoraproject.org> - Rust SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor - Neal Gompa (ngompa) <ngompa13(a)gmail.com> - Rust SIG, Golang SIG, RPM contributor - Jakub Čajka (jcajka) <jcajka(a)fedoraproject.org> - Golang SIG, Container SIG This proposal aligns with the objective of improving the packager experience <https://fedoraproject.org/wiki/Objectives/Packager_Experience> by developing a platform whereby the proposal owners and others can experiment with improvements that can be funneled back into the official production infrastructure. ProblemsProblem №1: Build-only packages Some ecosystems have many build-only packages (packages which are used to build other packages, without having them installed on end-user systems). Those ecosystems include Java, Rust and Go. It is extremely hard to keep up maintaining them due to lack of time/people. Upstreams are usually changing quickly (sometimes when you update just one such package, you’d need to update tens of the dependencies). Few facts about such packages: - They are almost always outdated in released versions of distribution; - They are often FTBFS (e.g. because there was compiler update but not package update, broken deps, broken APIs due to deps rebases, …). In Rust ecosystem, we abuse Rawhide to build and store such packages there and then generate end-user application (e.g. ripgrep) which uses some of those packages and produces binary for all supported releases. Those applications have high quality and are supported. Rawhide gating makes this much more complicated because builds appear in buildroot slower, updating group of packages would need side tags and it’s just painful to work with. https://pagure.io/fesco/issue/2068 And, after all, those packages shouldn’t be shipped to users. Problem №2: Testing of new rpm/koji/mock features/configuration When developing new features in RPM (e.g. rich dependencies) or testing different Koji configuration (e.g. removing gcc/gcc-c++ from the buildroot), it is required to make custom configuration and try building things. Problem №3: Developing modules Modules are built in MBS as a single unit. It is hard to develop big modules by progressively improving individual packages or small package groups. Scratch builds for modules are not implemented. Local builds work differently from official module builds, they don’t scale and don’t allow groups of people to work collaboratively. All these problems can be solved by first developing a flat repository of packages in a shared environment and then generating modulemd from such package set. Problem №4: Testing things before push Primary Fedora Koji and dist-git are not suited for packaging experimentation. Packagers are expected to experiment on their own systems and push changes of successful experiments only. But this approach doesn’t scale with number of maintained packages. Often you can find commits like “d’oh, forgot to upload sources” or “let’s try with this settings”. People need to build things somewhere quickly, do development and testing. And only after that, they should push commit(s) to Fedora. Solution - Separate Koji + Koschei deployed in Fedora infrastructure cloud; - Builders are optimized for the best performance (see below <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…> ); - People can have their own targets where they can break things as they wish without affecting others; - Package changes are eventually contributed to Fedora proper by merging changes to Fedora dist-git and rebuilding packages in official Fedora Koji; - All improvements can eventually be contributed back to official Fedora infra. Ideas All ideas which you’ll find below are just an ideas and do not have to be implemented. Idea №1: Automated legal review openSUSE released their review app called Cavil <https://github.com/openSUSE/cavil> which we could try running in automated way. Idea №2: Automated package review Currently review process is burden and we could run automated legal review, create a repo, run set of checks and notify person. Somewhat similar to fresque <https://github.com/fedora-infra/fresque>. In future might be integrated with approval process and auto-imported into Fedora. Idea №3: Building packages for multiple distributions In Rust ecosystem, we managed to get have same packaging guidelines in openSUSE, Mageia and Fedora. We could automatically build some packages on multiple distributions and be kinda upstream. Idea №4: Building custom images with user content Deploy (or build) a tool(s) to enable user-built install, appliance and container images with their content (modulo restrictions similar to COPR) on top of Fedora. Implementation details - Koji and Koschei deployed in fedorainfracloud.org - A few builders constantly running, with a possibility to add more builders as needed and as available cloud resources allow - Deployed and maintained by proposal owners - not supported by Fedora infrastructure - Other contributors can have access granted by proposal owners (for the time being only users in “packagers” group will be eligible to get access) - Possibility to have some builders running outsides of Fedora infrastructure - contributed by proposal owners - Koji builds can be done from SCM (src.fp.o, pagure.io, github, …) or from SRPM upload FAQWhy not COPR? - COPR has been starved of resources for years, which has impaired its ability to provide reliable service at scale. Fedora Infrastructure refuses to consider supporting it officially and Fedora Release Engineering seems to have some undefined issues with COPR. - It is not official build system of Fedora which is not helping with Problem №2: Testing of new rpm/koji/mock features/configuration <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…> . - COPR is not extensible enough, more specifically: - No query API (e.g. it is not possible to find out from which SCM commit the package has been built) - Builds always have access to all previous builds in a repository (i.e. not possible to control when/how repo is created) - GC doesn’t exist - No scratch builds Why not staging Koji? - Staging Koji is meant for testing Koji itself and not for package development. - Staging Koji is often in broken state where it is not possible to build anything. - No one can touch staging Koji, so it’s pointless for offering a useful service. How can you make Koji builds faster? - By tuning Koji for performance, not correctness and reliability. - By building only on a single, fast architecture. - By extensive caching. Files like RPM packages, repodata and files in lookaside cache don’t change after they are initially stored, so builders can cache them aggressively. - By keeping build repositories small. Some package sets don’t need to be built against full Fedora, but can use a minimal subset of Fedora. Such repositories can be generated by Koji in seconds, not minutes. Why not the Open Build Service (OBS)? - OBS is not yet packaged for Fedora officially. The upstream code lacks adaptations necessary to deploy and run on Fedora and in Fedora Infrastructure. - OBS is not official build system of Fedora, which does not help with Problem №2: Testing of new rpm/koji/mock features/configuration <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…> . What does MBI stand for? - M for middlestream, module, mizdebsk, … - B for build, bootstrap, … - I for infrastructure, initiative, ignatenkobrain, … - MBI might be pronounced as “maybe I …(can make something cool)?” - MBI is also initials of mizdebsk (Mikolaj Bozydar Izdebski) - MBI is also IBM spelled backwards :) Is it somehow related to Fedora Playground <https://fedoraproject.org/wiki/Playground>? Yes, it is. Although it is more developer-focused. Users could enrol for some specific things like experimental Java/Rust packages. MBI (Playground 2.0) <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…>

15 50

Attempt to update ispc
by Luya Tshimbalanga 14 Feb '19

14 Feb '19

Hello team, Upstream ispc updated to 1.10.0. Unfortunately, the build failed with broken clang++ compiler according to koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=32150411) Can someone investigate the issue? This package is needed by embree, a dependency for both Blender, luxcorerender and Yafaray. Thanks Luya

7 20

F30 Self-Contained Change proposal: SWID tag enablement
by Ben Cotton 13 Feb '19

13 Feb '19

https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement == Summary == Provide tools to allow users and developers to create Software Identity (SWID) tags for Fedora installs and repositories. == Owner == * Name: [[User:adelton|Jan Pazdziora]] * Email: jpazdziora(a)redhat.com == Detailed Description == SWID (ISO/IEC 19770:2-2015) is a portable standard for identifying software installed on a system. We already have SWID tags in fedora-release to identify the overall release+edition of Fedora. We will add tools to allow users to * list installed tags * create and install individual tags identifying RPMs * add pre-built tags to repositories * automatically update local tags as packages are installed, updated and removed This will involve standalone tools to query and build SWID tags and to add prebuilt tags to dnf repositories, and plugins for dnf/libdnf to build and download tags. == Benefit to Fedora == Fedora will be usable to users and developers interested in the SWID functionality being added to relevant other tools, such as OpenSCAP-1.3. == Scope == * Proposal owners: ** Add python SWID tools (swidq, rpm2swidtag) ** add SWID metadata awareness to createrepo (but this will not be used in Fedora, only enabled for user use), agreeing metadata format with dnf team ** add dnf and libdnf plugins (no core dnf/libdnf changes expected) * Other developers: 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) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == No change unless users choose to enable SWID tags. If requested, SWID tags will be either built automatically on demand for installed RPMs, or downloaded from a repository that the user has added SWID tags to, at the user’s choice. swidq will allow the user to see all installed tags and their relationships. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No * Blocks product? No == Release Notes == Inform users of new capabilities and how they can be used with the existing tags in fedora-release-* -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

6 8

F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages
by Ben Cotton 12 Feb '19

12 Feb '19

https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_indi… == Summary == Make ibus-typing-booster the default input method for Indian languages. == Owner == * Name: [[User:Mfabian|Mike Fabian]] * Email: <mfabian(a)redhat.com> == Detailed Description == Currently, ibus-m17n is the default input method for Indian languages in Fedora. ibus-typing-booster uses the same libm17n used by ibus-m17n to support input for Indian languages and thus it can do everything ibus-m17n can do. But on top of that, ibus-typing-booster supports predictive input by remembering user input and by using words from dictionaries. Therefore, ibus-typing-booster is a more useful input method for these languages. == Benefit to Fedora == A better input experience for users of Indian languages. == Scope == * Proposal owners: The langtable package has data about default input methods. Change this data. But the data in langtable is currently apparently not used by gnome-initial setup. The list of default input methods used by gnome-initial-setup us stored in <pre> libgnome-desktop/default-input-sources.h </pre> Currently there are the following default input methods for the Indian locales: <pre> static DefaultInputSource default_input_sources[] = { ... { "as_IN", "ibus", "m17n:as:phonetic" }, ... { "bn_IN", "ibus", "m17n:bn:inscript" }, ... { "gu_IN", "ibus", "m17n:gu:inscript" }, ... { "hi_IN", "ibus", "m17n:hi:inscript" }, ... { "kn_IN", "ibus", "m17n:kn:kgp" }, ... { "mai_IN", "ibus", "m17n:mai:inscript" }, ... { "ml_IN", "ibus", "m17n:ml:inscript" }, ... { "mr_IN", "ibus", "m17n:mr:inscript" }, ... { "or_IN", "ibus", "m17n:or:inscript" }, ... { "pa_IN", "ibus", "m17n:pa:inscript" }, ... { "sd_IN", "ibus", "m17n:sd:inscript" }, ... { "ta_IN", "ibus", "m17n:ta:tamil99" }, ... { "te_IN", "ibus", "m17n:te:inscript" }, ... { "ur_IN", "ibus", "m17n:ur:phonetic" }, ... </pre> Here, "m17n:as:phonetic" would need to be replaced with "typing-booster". And similar for the other Indian languages. ibus-typing-booster selects the default input method to use from the locale when it is first started. For the above Indian locales ibus-typing-booster >= 2.4.2 has the same default m17n input methods as libgnome-desktop/default-input-sources.h, except that it always uses inscript2 instead of inscript by default. * Other developers: 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) == Upgrade/compatibility impact == Nothing should happen when upgrading from a previous version of Fedora. If a user used ibus-m17n before the upgrade, he will still use it after the upgrade. This change proposal only changes the default input method for an Indian language for new installs or new user accounts. == How To Test == Do a new installation of Fedora 30 in an Indian language. Log into Gnome. See what input method is suggested by default by gnome-initial-setup. == User Experience == Easier input of Indian language because of predictive input. == Dependencies == gnome-initial-setup == Contingency Plan == * Contingency mechanism: Leave the default input methods as they are now and move the change to Fedora 31 * Contingency deadline: Fedora 30 Beta release * Blocks release? No. * Blocks product? No. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

5 5

F30 Self-Contained Change proposal: Bash 5.0
by Ben Cotton 11 Feb '19

11 Feb '19

https://fedoraproject.org/wiki/Changes/Bash_5.0 == Summary == Upgrade bash to 5.0 release. This release fixes several outstanding bugs in bash-4.4 and introduces several new features. The most significant bug fixes are an overhaul of how nameref variables resolve and a number of potential out-of-bounds memory errors discovered via fuzzing. == Owner == * Name: [[User:svashisht| Siteshwar Vashisht]] * Email: svashisht(a)redhat.com * Release notes owner: == Detailed Description == There are a number of changes to the expansion of $@ and $* in various contexts where word splitting is not performed to conform to a Posix standard interpretation, and additional changes to resolve corner cases for Posix conformance. The most notable new features are several new shell variables: BASH_ARGV0, EPOCHSECONDS, and EPOCHREALTIME. The `history` builtin can remove ranges of history entries and understands negative arguments as offsets from the end of the history list. There is an option to allow local variables to inherit the value of a variable with the same name at a preceding scope. There is a new shell option that, when enabled, causes the shell to attempt to expand associative array subscripts only once (this is an issue when they are used in arithmetic expressions). The `globasciiranges' shell option is now enabled by default; it can be set to off by default at configuration time. There are a few incompatible changes between bash-4.4 and bash-5.0. The changes to how nameref variables are resolved means that some uses of namerefs will behave differently, though upstream has tried to minimize the compatibility issues. == Benefit to Fedora == Bash is the default shell in Fedora and it will benefit from new features and performance improvements of the latest release. == Scope == * Proposal owners: Upgrade bash to 5.0 * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) ** 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) == Upgrade/compatibility impact == Code related to resolving namerefs was changed, so some scripts may break. But impact should be minimum as this release is largely backward compatible. == Dependencies == N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

14 36

Retiring perl-perlmenu
by Emmanuel Seyman 11 Feb '19

11 Feb '19

[ perl-devel is in cc: ] Hello, all. I maintain perl-perlmenu in Fedora and I will be retiring it at the end of the week unless someone offers to maintain it instead. For the record, I would advise against this since upstream no longer exists and nothing depends on the particular package. Emmanuel

1 1

Orphaning: llvm5.0, clang5.0, llvm6.0, clang6.0
by Tom Stellard 10 Feb '19

10 Feb '19

Hi, I am orphaning the llvm and clang compatibility packages for versions 5.0 and 6.0. We are about to push LLVM 8.0 into rawhide, so I will no longer maintain these older versions. There are still a few users of these packages, so the package owners can either rebuild their packages for LLVM 7/8 or take over ownership of the compatibility package they need. -Tom

5 7

Boost 1.69 update with soname bumps in rawhide/F30
by Jonathan Wakely 09 Feb '19

09 Feb '19

With enormous thanks to Denis Arnaud for doing the actual boost.spec rebase, we're ready to update Boost in rawhide, for this change: https://fedoraproject.org/wiki/Changes/F30Boost169 As always, this changes the soname of every libboost_*.so library, so we'll be rebuilding all the packages that link to Boost libs. These rebuilds will happen on the f30-boost side tag, and once they're all done everything will move to the main f30 target all at once. IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it in the next few days, please get in touch so we can coordinate. It's better to avoid me doing a rebuild in the f30-boost side tag, then somebody else doing another rebuild in the main f30 target, and then me having to do another build in the side tag! If you'd rather I don't rebuild your package (e.g. so you can finish an update and then build it yourself) please get in touch. I've done local builds of most of them, and 130+ build OK. Any that fail I'll create bugzilla FTBFS reports for. I expect the following to fail, because they link to libboost_python.so and that has changed to libboost_python27.so, so unless they have build-system logic to already detect that change (which might exist in some build systems already, I guess), they'll need a fix: avogadro condor dmlite freecad gfal2-python ledger

7 19

Orphaning pl (SWI Prolog)
by Petr Pisar 08 Feb '19

08 Feb '19

I have no interest in maintaining pl (SWI Prolog) package and thus I'm going to orphan it. The package is a Prolog langugage interpreter with bundled various libraries and tools written in that language. E.g. an HTTP server or an interface to Java virtual machine. Upstream does a new major release roughly every year and a few bug-fix releases during the year. From packaging point of view there are few downs like: Reviewing each rebase for licenses is tiresome due the size (118 MB). Upstream does not like how it is packaged because Fedora bends it to FHS. Fedora does not like how it is packaged because it's not bended enough. There are occasional FTBFS when JVM reorganizes its files. The package should be renamed to swipl to match the upstream. The source archive is stripped down from non-free files. The pl package has two comaintainers, mef and bagnara, who did not touch the pacakge for last 10 years. The package is required when building and running these source packages: perl-Language-Prolog-Yaswi ppisar,jplesnik Can be removed. ppl bagnara,pcpa A subpackage can be disabled. python-pyswip thofmann A subpackage can be disabled. The package builds fine now and a new 8.1 release is waiting for packaging. If you want to take over a maintainership of this package, let me know and I will assign it to you. Otherwise I will orphan it next week. -- Petr

1 1

← Newer
1
2
3
4
5
6
7
8
...
26
Older →

Jump to page:

2026

2025

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 2019