devel April 2019

devel@lists.fedoraproject.org

195 participants
311 discussions

[Fedocal] Reminder meeting : Modularity Team (weekly)
by nils＠redhat.com 29 Apr '19

29 Apr '19

Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-04-30 from 15:00:00 to 16:00:00 UTC At fedora-meeting-3(a)irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/

1 0

Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
by Ben Cotton 29 Apr '19

29 Apr '19

https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot == Summary == Create <code>gdb-minimal</code> package (without XML support, Python support, Syntax Highlight and such) and switch to it in buildroot. == Owner == * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio Durigan Junior]] * Email: ignatenkobrain(a)fedoraproject.org, sergiodj(a)sergiodj.net == Detailed Description == Create subpackage in <code>gdb</code> source package called <code>gdb-minimal</code> that will contain 2 files: * <code>/usr/libexec/gdb-minimal</code> — GDB executable built without optional unneeded features * <code>/usr/bin/gdb-add-index</code> — Executable script shared with gdb-headless package (modified to fallback to gdb-minimal if exists) debuginfo code in RPM needs just gdb-add-index and that one doesn't need any syntax highlight or python plugins to work. As of Apr 26, following packages would disappear from buildroot: <pre> boost-regex-1.69.0-6.fc30.x86_64 ctags-5.8-25.fc30.x86_64 gdbm-libs-1:1.18-4.fc30.x86_64 libbabeltrace-1.5.6-2.fc30.x86_64 libicu-63.1-2.fc30.x86_64 libipt-2.0-2.fc30.x86_64 python-pip-wheel-19.0.3-1.fc31.noarch python-setuptools-wheel-40.8.0-1.fc30.noarch python3-3.7.3-2.fc31.x86_64 python3-libs-3.7.3-2.fc31.x86_64 python3-pip-19.0.3-1.fc31.noarch python3-setuptools-40.8.0-1.fc30.noarch source-highlight-3.1.8-24.fc31.x86_64 sqlite-libs-3.27.2-3.fc31.x86_64 </pre> == Benefit to Fedora == * Python 3 will disappear from buildroot (yes, it was there just because of GDB) * RPM download size for buildroot preparation will go down from 101M to 85M * installed buildroot size will go down from 439M to 350M == Scope == * Proposal owners: Create a subpackage in gdb, Add <code>Suggests: gdb-minimal</code> into rpm-build * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/8311 #8311] * 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) == User Experience == Python 3 will disappear from buildroot, but nobody should have ever relied on it since we have guidelines about that for long time: https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires == Dependencies == N/A (not a System Wide Change) == 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) -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him

6 12

Fedora Atomic Host Two Week Release Announcement: 29.20190429.0
by noreply＠fedoraproject.org 29 Apr '19

29 Apr '19

1 0

fuse/fuse3 - repos and moving forward
by Phil Wyett 29 Apr '19

29 Apr '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, We have a fuse repo on pagure at 2.99 and a PR regarding fuse3 from 'dwd'. We also have a fuse3 repo that has been created on pagure. What is the situation at present and how we will be moving forward with fuse 3? Regards Phil - -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Twitter: kathenasorg IRC: kathenas Web: https://kathenas.org Github: https://github.com/kathenas GitLab: https://gitlab.com/kathenas GPG: A0C3 4C6A AC2B B8F4 F1E5 EDF4 333F 60DC B0B9 BB77 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJcx03nAAoJEDM/YNywubt3MegQAKAzd6f/3b38acNEXYU/edZe W6BRRTPEsrv0i0i/3XOsJxuMUlSEBfIYB97WOhWvWDCEMxq3uFwrKZ4Eoqk7I89j kVLoD3SWQ/xJgKqeiOpuJr3vj9hepDJm+WtfU390eJxmHxwFoi7nDIGI/BoCI/ZG nyNnprSWuiV0PKYuX/wMMR9fIwjg7VisMrVspPR5ddKNBrO5KTmlZO0pBEVt49PU XgKGCmE/GyWzaWTkBjcJvxm5tK04Kpkk6HY1DNygvQjk6/nlOk5b00/V8UQqV7d9 7EV+brFBPGDWiEbjYtgwZS6hXj2BKA+hzy3pA/XT0z/MHkkKAt/y2gKmcSut7zbX MHm7pQ/YXTQHqDCW0NUPYcrlUpcHIeVI4OjEWeIL70MRFulf92/kltF5SGcFaIgo 5noYMnKbQT8IjAOaixlvX73jwmhYXg6EEe5vvmcYWRdpK1ALAsujUC3+zcgX3pPF UVmn99/jQagxwKU9JUeM08MdgAvG/2AVKykxftiApRVI3JKvf+NRpFKH9L9mh/LQ 99Ed+Bj3iGvsILJ3cu+RIHiFokeKyfGiaikL9t/h8p/MHZK0RYLI6liTYYdFYnAv BzeH/NrSUdMZf9fOS2BEDKq9TSBQegnzCPjqmqlFdZyXmpZrSxKUWZBgr/tGLi7J +JquPRvQLqreg3wG9fhd =btir -----END PGP SIGNATURE-----

1 1

rpmlint whitelisting broken in taskotron?
by Fabio Valentini 29 Apr '19

29 Apr '19

Hi, I've noticed that my bodhi updates started showing rpmlint errors for my packages again, where they were previously silent because I supply a $SRCNAME.rpmlintrc file in my dist-git repos. It looks like taskotron is broken and/or ignores this file again. Is this a known issue? For example, this build from today shows rpmlint issues that are explicitly whitelisted (using the file locally suppresses the warnings/errors as intended): update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecaba1eef1 in repo: https://src.fedoraproject.org/rpms/elementary-greeter/blob/f30/f/elementary… Fabio

2 3

Fedora Rawhide-20190429.n.0 compose check report
by Fedora compose checker 29 Apr '19

29 Apr '19

Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 3 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 10/137 (x86_64), 1/2 (arm), 2/24 (i386) ID: 393350 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/393350 ID: 393370 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/393370 ID: 393382 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/393382 ID: 393383 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/393383 ID: 393397 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/393397 ID: 393399 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/393399 ID: 393402 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/393402 ID: 393422 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/393422 ID: 393452 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/393452 ID: 393465 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/393465 ID: 393469 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/393469 ID: 393480 Test: i386 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/393480 ID: 393490 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/393490 Soft failed openQA tests: 3/24 (i386), 7/137 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 393362 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/393362 ID: 393363 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/393363 ID: 393372 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/393372 ID: 393381 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/393381 ID: 393386 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/393386 ID: 393413 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/393413 ID: 393415 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/393415 ID: 393416 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/393416 ID: 393417 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/393417 ID: 393473 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/393473 Passed openQA tests: 120/137 (x86_64), 19/24 (i386) Skipped non-gating openQA tests: 1 of 163 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Orphaning rubygem-jquery-ui-rails
by Pavel Valena 29 Apr '19

29 Apr '19

$SUBJ, as I have no use for it. -- Pavel Valena Software Engineer, Red Hat Brno, Czech Republic

1 0

Fedora 32 System-Wide Change proposal: Retire Python 2
by Ben Cotton 29 Apr '19

29 Apr '19

https://fedoraproject.org/wiki/Changes/RetirePython2 == Summary == The {{package|python2}} package and all its subpackages will be removed from Fedora 32. A legacy {{package|python27}} package for developers and users will be provided. All packages in Fedora that need Python 2 to run will be removed from Fedora 32 regardless of their dependencies. All packages in Fedora that need Python 2 to build will be removed from Fedora 32 regardless of their dependencies. Exceptions can be granted by FESCo. == Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Email: <mhroncok(a)redhat.com> <python-devel(a)lists.fedoraproject.org> == Detailed Description == Python 2 is unsupported upstream since 2020-01-01. Packages dependent on Python 2 are being removed from Fedora for several releases already: * [[Changes/Mass_Python_2_Package_Removal|Fedora 30 Mass Python 2 Package Removal]] * [[Changes/F31_Mass_Python_2_Package_Removal|Fedora 31 Mass Python 2 Package Removal]] Now, the Python maintainers have decided to pull the plug. The {{package|python2}} package and all its subpackages will be retired (read: removed) from Fedora 32 (Rawhide) as soon as Fedora 31 is branched. All packages depending on any python2 package will be removed. The removal starts 2 weeks before the planned Fedora 32 Mass Rebuild. Broken dependencies will not stop the removals. Packages that Fail to Build From Source and prevent to remove Python 2 subpackages may end up with broken dependencies, in cases where it is not desired, those packages will be retired instead. The rules also apply to modules built for Fedora 32+. The package removal will be executed in an automated fashion. Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}. === The python27 package === Similarly to existing {{package|python36}}, {{package|python37}} etc. packages, a {{package|python27}} package will be created. This package is indented for Python developers who still need to support the legacy version of Python. This package is indented for users, who still need to use some software depending on the legacy version of Python. This package is not intended for other Fedora packages to be depended upon. The {{package|python27}} package has several drawbacks compared to the original {{package|python2}} package: * it is "flat" - there are no subpackages, everything lives in one package * there is no debug build (previously available as {{package|python2-debug}}) * there is no <code>/usr/bin/python</code> (note: there might be already the case before this change) * any special backwards compatible Provides are removed (this package is not intended to be depended upon) === FESCo exceptions === We realize that there are some packages whose removal could seriously hurt Fedora. FESCo can grant exceptions for packages to use the {{package|python27}} as a runtime or build dependency. The package maintainer is responsible to check the entire dependency chain and they need to request exceptions for the entire list of packages. For example, when seeking exception for the {{package|chromium}} package, the request should contain {{package|python-psutil}} and other dependent packages. (Yes, this is tedious. Maintaining a Python 2 dependent package is a burden.) The exception request must include a plan for migrating to Python 3. Any non-essential dependency must be dropped. That includes optional dependencies, test dependencies, optional subpackages etc. Package that fail to get an exception when the removal starts (see above) will be removed. Their importance for Fedora Release Engineering, Fedora Infrastructure or any other body will not be automagically respected; every package that needs Python 2 needs an exception. The change owners will send regular reminders to the package owners. == Benefit to Fedora == Python 2 is past upstream End of Life since 2020-01-01. This changes is generally crafted in a way that: * it leaves Python developers an option to use it in case they still need to support it * it leaves Fedora users an option to use it in case they still need it to run their (3rd party) software * it leaves Fedora packagers an option to keep using it (complicated, but possible) While: * it removes Python 2 software from Fedora that was only preserved so far by inaction Using Python 2 is dangerous. While the Fedora Python maintainers will try to fix as many security bugs as possible, without the upstream involvement this will be hard. Python 2 is deprecated since Fedora 30. This change moves Python 2 from second class citizen to third class citizen. == Scope == * Proposal owners: ** retire {{package|python2}} ** introduce {{package|python27}} ** remove all {{package|python2}} dependent packages that do not have FESCo exceptions ** obsolete removed packages that break the upgrade path via {{package|fedora-obsolete-packages}} * Other developers: ** remove their {{package|python2}} dependent packages without exceptions ** get exceptions if needed ** fix broken dependencies * Release engineering: [https://pagure.io/releng/issue/8306 #8306] easeBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: none * Policies and guidelines: Python 2 packaging is against the guidelines since Fedora 30. Python 2 packaging guidelines will be removed from [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/ Python Appendix] (unless the FPC wants to keep them around until F31 EOL). * Trademark approval: not needed for this Change == Upgrade/compatibility impact == The majority of removed packages will be obsoleted and removed on upgrade. Users needing Python 2 libraries will not find these packaged as RPMs. They may install upstream versions using pip and virtualenv. == How To Test == Try to update Fedora 30 or 31 to 32. No python2 packages should block the upgrade. Try to run Python 2 software via the {{package|python27}} package. == User Experience == There will be close to zero Python 2 RPMs in Fedora repos. Users are encouraged to switch to Python 3 and/or use Python 2 virtual environments and pip for development. == Dependencies == Ideally, all programs that use python2 would be switched to use python3. Although we don't expect everything to be switched over, as much as possible should be, so that the ripped remaining python2 set is small as possible. == Contingency Plan == * Contingency mechanism: ** In case of serious issues, FESCo can issue a general exception for packages that would otherwise prevent Fedora 32 from being composed. ** If someone steps up to maintain Python 2 (including the full ecosystem of packages now in Fedora), they can decide to discontinue removing packages, revert this Change, or come up with another plan. (Note that in this case, current maintainers will most likely orphan many fundamental python2 packages.) * Contingency deadline: Fedora 32 Beta * Blocks release? in theory it should not, in practice, it may break the release and hence it will block it until fixed * Blocks product? all of them? == Documentation == This page should serve as the documentation. == Release Notes == TBD. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him

8 15

Modularity UX Questions
by Stephen Gallagher 29 Apr '19

29 Apr '19

Last month, we had a Modularity Hackfest in Boston. I wrote up a hackfest report at the Community Blog[1] back then, which included several open questions related to how to handle stream and profile defaults. I'm reprinting them here on Fedora Devel for public input. == Open Questions == We had some discussions throughout the course of the hackfest that didn’t reach a clear consensus. The most contentious was around what to do about empty profile data. There are several uncommon cases that need to have clear UX decisions made around them. === A module does not have one or more of its profiles specified to be the default. === The module creator has not provided a defaults object into the YAML (in Fedora, this is done by requesting it be added by release engineering or submitting a pull request to the fedora-module-defaults repository). This may be intentional or unintentional. Fedora QA has asked us if they should be treating the lack of a defaults reference for the profile as a failure, since this is something that could be detected during post-compose testing and reported. My personal opinion on this case is that for modules in Fedora itself, we should indeed treat this as a bug and require that all modules have a defaults object that properly references a set of default profiles for any stream included in that compose. The open question here is what the DNF experience should be if dnf module install modulename:modulestream is called. The current behavior is that DNF treats this as equivalent to calling dnf module enable modulename:modulestream (it makes the contents of this module explicitly available, but installs nothing at that time. Feedback from users of the RHEL 8 Beta have indicated that this is an unexpected behavior of the install verb. They’d prefer to see DNF report an error if install is called and results in no packages being installed. In part, this is because it would be silently hiding the possibility that the defaults are missing. === A module has explicitly set one or more of its streams to have no default profiles === This is a similar case to the above, except that a conscious choice was made by the module maintainer to say that this module has no reasonable default packages that could be selected. (For example, it could be a collection of popular libraries that extend a particular programming language, but there’s no obvious subset of them that makes sense to install. It may exist and have streams solely because it needs to be kept in sync with the interpreter version.) The open question is the same as the previous one: how should dnf module install handle this case? In this particular example, it might be more acceptable that it follows the enable fallback, since the maintainer selected the lack of a profile explicitly. However, having context-sensitive differences can be difficult for people to process. === A module has a profile that contains zero RPMs === In this case, a profile definition has been made in the module metadata and it explicitly contains zero RPMs within it. Such an example might be for compatibility: the module previously provided a profile with that name that contained content, but it is no longer doing so. Retaining the name may have been done to allow existing scripts to avoid breaking. If we have a profile that contains zero packages, should it be an error if we attempt to install it? If not, what should the UX look like? [1] https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/

4 7

Un-orphaned NodeJS packages upgrades in rawhide
by Jan Staněk 29 Apr '19

29 Apr '19

Hello, I have recently (last week) taken on maintenance of several to-be orphaned nodejs packages. Since the packages were not upgraded for a while, they are usually a major version behind the upstream release. I have started to remedy this, but given the relatively large jump in version numbers, there might be issues. If your node package stops building in rawhide suddenly, check the dependencies for updates; feel free to reach to me with related issues. The upgraded (or soon to be upgraded) packages in question: - nodejs-bluebird - nodejs-clean-css - nodejs-grunt-known-options - nodejs-path-exists Keep in mind that the above list might expand in the near future, given the current situation with many nodejs-* orphans. -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jstanek(a)redhat.com IM: jstanek

4 4

← Newer
1
2
3
4
5
6
7
8
9
...
32
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 April 2019