devel February 2019

devel@lists.fedoraproject.org

209 participants
273 discussions

Blocking criteria proposal for F30+: Printing
by Stephen Gallagher 01 Apr '19

01 Apr '19

There was a bug[1] filed recently that indicated that printing was broken on certain printers. As a result of that discussion, it became apparent that there was no criteria for printing to work at all, which seems like an oversight. I discussed this briefly with Matthias Clasen this morning and he agreed that this should be treated as blocking for Workstation. I'd like to propose that we add the following criteria to Beta for Fedora 30+: * Printing must work on at least one printer available to Fedora QA. "Work" is defined as the output from the device matching a preview shown on the GNOME print preview display. (Note that differences in color reproduction are not considered "non-working".) and this to Final for Fedora 30+: * Printing must work on at least one printer using each of the following drivers: (I don't know which ones to specify here, but we ought to try to figure out a cross-section that covers a large swath of our expected user base). [1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255

9 22

Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages
by Fabio Valentini 28 Mar '19

28 Mar '19

Hi everybody, In the past few weeks, it has come up regularly that future "module-only" packages are orphaned (and hence will soon be retired), and nobody stepped up to fix this issue - especially for non-leaf packages. I don't think fedora as a project has a solution for this yet. I propose to create a "Stewardship" Group / SIG that will take care of such packages - either until a new main maintainer steps up, or until modularity matures enough so it won't be necessary anymore. (Or, until it dies a quiet death, which is always a possibility.) However, I think this is necessary until the situation stabilizes. Comments and future contributors are very welcome. Fabio

14 35

Can we please stop enforcing Signed-off-by commits?
by Miro Hrončok 20 Mar '19

20 Mar '19

It happened to me almost dozen times now, so here's my rage :D I want to send a pull request to a Fedora project*, I clone it, fork it, push to the fork, open a PR and there it goes: ! This repo requires all commits to have the Signed-off-by whatnot in them ! So I have to go again, amend with -s, push force. That is tedious and at least I know how to do that. I assume there are people who don't. Can we stop this nonsense? I usually smuggle something like: Signed-off-by: Stop This <pretty(a)plea.se> And nobody ever cares! The thing is enforced only because it can be enforced. The line in that commit message is totally useless and doesn't provide any benefit, just pain. I've signed the Fedora Project Contributor Agreement. That should be enough. Now a bit more serious: What information am I missing? Why do Fedora upstreams enforce this? Thanks (* last time it was simple-koji-ci, but it's also fedpkg and other projects on pagure.io) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

16 23

Tracking translation status of a package built in koji
by Sundeep Anand 14 Mar '19

14 Mar '19

Hi Everyone, At times this could be a requirement to track or know translation status of a package which has (just) built in koji. Transtats could be used for this purpose. We just need to run a job. Steps: 1. Navigate to https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based 2. Select 'Sync Package Build System' job template and proceed. 3. You may read and continue with the tasks defined in YML. 4. Select or enter package name. For example: anaconda. Select Build System and Tag. For example: koji and rawhide Click 'Next' 5. And run the job. Upon successful completion an unique URL will be created. This could really be helpful. We are working on creating alerts or warnings. Feel free to share comments on this here: http://feedback.transtats.xyz thanks, sundeep

3 8

HEADS UP: dhcp will ship bunded bind libraries
by Pavel Zhukov 12 Mar '19

12 Mar '19

All, tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring dhcp-libs-static with bundled version of libisc/libdns/etc As ISC dropped support of single thread build of BIND libraries [1] and dhcp requires one we decided to not patch dhcp/bind build scripts anymore and ship bundled bind libraries just like upstream (ISC) does it. It will allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be expected in rawhide/F31 soon! I'm aware of FPG recommendation to avoid shipping of bundled libraries due to its maintenance cost but maintaining of heavy patched build sctipts and inability to ship newer versions are even worse. I have not find any application in Fedora repository which link with libdhcp/libomapi. Please let me know if you aware of any. [1] https://ftp.isc.org/isc/bind9/9.13.3/RELEASE-NOTES-bind-9.13.3.html -- Pavel

4 3

F31 System-Wide Change proposal: BuildRequires Generators
by Ben Cotton 11 Mar '19

11 Mar '19

https://fedoraproject.org/wiki/Changes/BuildRequires_Generators = BuildRequires Generators = == Summary == Add possibility to generate build-time dependencies within RPM spec file and teach RPM and mock how to handle this. == Owner == * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian Festi]], [[User:msuchy|Miroslav Suchý]] * Email: ignatenkobrain(a)fedoraproject.org, ffesti(a)redhat.com, miroslav(a)suchy.cz == Detailed Description == For many languages (Rust, Golang, Node.Js, Ruby, Python), BuildRequires can be automatically generated. All it takes, run some special tool which will output dependencies in RPM format. Q: How will it work under the hood? A: When you build RPM, something like this will happen under the hood… # rpm would perform %prep (which is supposed to abort if some dependencies missing and print them) # mock would install those dependencies and resume build Q: Will src.rpm contain all generated dependencies? A: This is not known yet, we'll update page once it is known. Q: Does this mean that package builds won't be reproducible anymore? A: No, as long as you have same buildroot and tool which is generating BuildRequires is doing so in reproducible manner, it should not affect reproducibility. == Benefit to Fedora == Packagers won't have to pre-generate BuildRequires in the spec file which means it will be always updated (and correct) : * Packagers can focus of making their packages better instead of spending all their packaging time copying BuildRequires from documentation and third party tools. * BuildRequires are dropped as soon as they're no longer necessary * Packages can be easily bumped without requiring a manual BuildRequires refresh * BuildRequires and Requires generation can use similar utilities, making sure that the deps packages declare can also be used for second-level building. Packages no longer need to declare the deps of their second and n-th dependencies because someone forgot to declare them in the correct package. == Scope == * Proposal owners: Implement support for a feature in RPM and mock (if implemented properly, Koji should just work). Make use of it in Rust ecosystem. * Other developers: Maintainers of language stacks are advised to use this feature. * Release engineering: [https://pagure.io/releng/issue/8129 #8129] * Policies and guidelines: Packaging Guidelines need to be updated with instructions how to use this feature. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Packagers and users who use repoquery might be affected (src.rpm might not contain generated dependencies). == How To Test == TBD. == User Experience == Users won't notice differences. == Dependencies == Required feature needs to be implemented in RPM and mock. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Proposal Owners might still ship feature disabled for Fedora buildsystem but have it available for end-users, and move full completion to the next release. * Contingency deadline: Beta Freeze * Blocks release? No. * Blocks product? No. == Documentation == TBD. == Release Notes == TBD. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

10 15

Introducing packit
by Tomas Tomecek 08 Mar '19

08 Mar '19

Hello, at DevConf.cz, we have introduced a new project: packit [1] [2]. I started a Fesco ticket [3] recently to get it approved but the consensus was to start a devel@ thread instead and discuss it here. So... Here we go! TL;DR What's packit? * Packaging automation: get latest bits into Fedora rawhide with the minimum amount of manual steps. * Upstream integration: let upstream know how their project stands in Fedora. * Source-git [4] That's a very brief intro. I spent some time on updating our readme [2] and creating this fedora wiki page about packit [5]. Please read those documents and give us feedback: either in this thread or feel free to create new github issues. [1] https://www.youtube.com/watch?v=KpF27v6K4Oc [2] https://github.com/packit-service/packit [3] https://pagure.io/fesco/issue/2084 [4] https://github.com/packit-service/packit#ehm-whats-source-git [5] https://fedoraproject.org/wiki/Packit Thank you, Tomas & the packit team

3 3

modular repositories in mock configs: please don't
by Fabio Valentini 07 Mar '19

07 Mar '19

Hi everybody, Recently, modular repositories were enabled in the mock configs for fedora 29+. Now, I can't build at least one of my packages (elementary-music) in fedora 29 chroots, due to dependency issues within modules. dnf just gives up with this rather unhelpful message: Problem: cannot install the best candidate for the job - package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded I don't want or need modules installed for this package to build. See: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-9015… IMO it was a mistake to enable modular repositories in mock configs by default. Now dnf only downloads even more metadata for no benefit (or, it even breaks dependency resolution, as in this case). Do I really have to manually edit mock's config files to disable modular repos, to get builds equivalent to koji (where modules aren't available / usable either)? I want to test builds locally, before I push them to koji builders ... Any insights why this was done? Can it be fixed please? Or am I the only one having problems? Fabio

18 34

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

F30 Self-Contained Change proposal: Retire YUM 3
by Ben Cotton 06 Mar '19

06 Mar '19

(Note this change was previously submitted for Fedora 29: https://pagure.io/fesco/issue/2064) https://fedoraproject.org/wiki/Changes/Retire_YUM_3 == Summary == Remove yum (v3) and all related packages from Fedora. == Owner == * Name: [[User:mdomonko|Michal Domonkos]] * Email: mdomonko(a)redhat.com == Detailed Description == Remove packages from the distribution: * createrepo * yum * yum-langpacks * yum-utils * yum-metadata-parser * yum-updatesd * python-urlgrabber All these packages should no longer be used and all software using them should be migrated to DNF. Compatibility: * Important packages such as yum, createrepo or yum-utils will be provided/obsoleted by relevant packages from the dnf stack * Important executables such yum, repoquery, createrepo, etc. will be provided either as new executables or via symlinks == Benefit to Fedora == Drop an old package manager that has no active upstream development. Move existing users to DNF which that has active development. Secondary benefit is reducing number of packages in Fedora that still depend on Python 2. == Scope == * Proposal owners: Remove packages from the distribution: createrepo, yum, yum-langpacks, yum-utils, yum-metadata-parser, yum-updatesd, python-urlgrabber * Other developers: Either remove packages from the distribution or switch them to DNF * Release engineering: [https://pagure.io/releng/issue/7588 #7588] * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Any tool based on YUM 3 Python API will stop working. This applies on any 3rd party software which won't be changed in Fedora as part of this change. CLI compatibility will be provided by DNF. == How To Test == Repoclosure passes after dropping the packages. == User Experience == There shouldn't be any impact on YUM users because the functionality is provided by DNF already. Users of tools listed in the Dependencies section shouldn't see any difference if the migration to DNF is done properly. == Dependencies == The list of source packages (SRPMs) that still depend on some of the yum-related packages to be removed: (see wiki page) == Contingency Plan == * Contingency mechanism: Do not remove the packages in the current release. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? No == Documentation == N/A == Release Notes == Inform end-users about removing the YUM 3 stack and definitive migration to DNF. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

23 51

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

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 February 2019