devel May 2020

devel@lists.fedoraproject.org

246 participants
393 discussions

Schedule for Thursday's FPC Meeting (2020-05-21 16:00 UTC)
by James Antill 21 May '20

21 May '20

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-05-21 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2020-05-21 09:00 PDT US/Pacific 2020-05-21 12:00 EDT --> US/Eastern <-- 2020-05-21 16:00 UTC UTC 2020-05-21 17:00 BST Europe/London 2020-05-21 18:00 CEST Europe/Berlin 2020-05-21 18:00 CEST Europe/Paris 2020-05-21 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2020-05-22 00:00 HKT Asia/Hong_Kong 2020-05-22 00:00 +08 Asia/Singapore 2020-05-22 01:00 JST Asia/Tokyo 2020-05-22 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #963 Blanket Bootstrap Exception for building Mono .fpc 963 https://pagure.io/packaging-committee/issue/963 = New Issues = #topic #982 Font packaging stopped working in rawhide/F33 .fpc 963 https://pagure.io/packaging-committee/issue/963 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines https://pagure.io/packaging-committee/pull-request/814 #topic #pr-938 Add Package Review Process page https://pagure.io/packaging-committee/pull-request/938 = New Pull Requests = #topic #pr-#942 Recommend storing changelog entries in separate file. https://pagure.io/packaging-committee/pull-request/942 #topic #pr-#947 Deprecate Old Style Dependency Generators https://pagure.io/packaging-committee/pull-request/947 #topic #pr-#954 Prohibit use of `rpm` command from specfile. https://pagure.io/packaging-committee/pull-request/954 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 1

Orphaning kchildlock
by Vascom 21 May '20

21 May '20

kchildlock orphaned. It is for KDE4 and has dead upstream. -- Best regards, Vasiliy Glazov

1 0

Fedora-IoT-33-20200521.0 compose check report
by Fedora compose checker 21 May '20

21 May '20

No missing expected images. Passed openQA tests: 8/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 147 MiB to 171 MiB System load changed from 0.08 to 0.31 Peak task count changed from 103 to 114 Previous test data: https://openqa.fedoraproject.org/tests/597767#downloads Current test data: https://openqa.fedoraproject.org/tests/602209#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 148 MiB to 170 MiB Peak task count changed from 104 to 124 Previous test data: https://openqa.fedoraproject.org/tests/597768#downloads Current test data: https://openqa.fedoraproject.org/tests/602210#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

[Test-Announce] Fedora-IoT 33 RC 20200521.0 nightly compose nominated for testing
by rawhide＠fedoraproject.org 21 May '20

21 May '20

Announcing the creation of a new nightly release validation test event for Fedora-IoT 33 RC 20200521.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200521.0_Sum… The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200521.0_Gen… Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer _______________________________________________ test-announce mailing list -- test-announce(a)lists.fedoraproject.org To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro…

1 0

Fedora-Cloud-31-20200521.0 compose check report
by Fedora compose checker 21 May '20

21 May '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-32-20200521.0 compose check report
by Fedora compose checker 21 May '20

21 May '20

No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 602207 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/602207 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-30-20200521.0 compose check report
by Fedora compose checker 21 May '20

21 May '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

An Apology
by Ty Young 21 May '20

21 May '20

Hi, I think I owe some in the Fedora project an apology. I feel like some good people where caught in the crossfire who were never intended to be with my words. I do not believe it to be true nor was it intended to be taken as "all Linux distros and their software maintainers are evil". I understand that, if nothing else, Fedora and others takes the route it does in order to be safe rather than sorry. That doesn't mean I agree with it, but it should never be confused with malicious intentions either, which I may very well have given off I was accusing innocent people of. There are no doubt many in the Fedora project that try to make right for everyone whenever and however possible, sometimes going above and beyond to do so. Those people deserve praise and compliments, not criticism or negativity thrown in their direction. I'm very sorry to all those people. I should take the time to say that, despite what some may think, I don't hate Fedora. I guess for those that don't know how nerdy I am for Fedora Silverblue, it would be easy to get the idea that I somehow hate everything Fedora does. This isn't remotely the case. I've been poking Fedora Silverblue every beta release trying to see if it's ready to take Arch Linux's spot when it goes south, and while it and the number of Flatpaks have improved and are still improving, they and Fedora aren't ready for me personally. If I was to recommend someone else who had less strict requirements(nvidia/rolling/software availability) a Linux distro though, Fedora Silverblue would probably be it. I should also be clear here that I'm not, in shape or form anyway, apologizing to anyone who actually believes that which amounts to "Open Source projects are nothing without Linux distros and their packagers". I do not feel like I owe anyone who thinks or claims such anything. Again, very sorry.

2 2

Fedora 33 System-Wide Change proposal: Sqlite RpmDB
by Ben Cotton 21 May '20

21 May '20

https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb == Summary == Change format of the RPM database from Berkeley DB to a new Sqlite format. == Owner == * Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]] * Email: pmatilai(a)redhat.com ffesti(a)redhat.com == Detailed Description == The current rpm database implementation is based on Berkeley DB 5.x, a version which is unmaintained upstream for several years now. Berkeley DB 6.x is license incompatible so moving to that is not an option. In addition, the existing rpmdb implementation is notoriously unreliable as it's not transactional and has no other means to detect inconsistencies either. Changing to a more sustainable database implementation is long overdue. We propose to change the default rpmdb format to the new sqlite based implementation. Support for current BDB format will be retained in Fedora 33, and phased out to read-only support in Fedora 34. == Benefit to Fedora == * A far more robust rpm database implementation * Getting rid of Berkeley DB dependency in one of the core components == Scope == * Proposal owners: ** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial shakedown, change the default rpmdb configuration to sqlite ** Address any bugs and issues in the database backend found by wider testing base ** Help other developers to address Berkeley DB dependencies * Other developers: ** Test for hidden Berkeley DB dependencies in other software, address them as found and needed * Release engineering: [https://pagure.io/releng/issue/9308 #9308] * Policies and guidelines: Policies and guidelines are not affected * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == === Upgrading === * Ability to upgrade is not affected * After upgrade completes, manual action (rpmdb --rebuilddb) will probably be needed to convert to sqlite. Alternatively user can change configuration to stay on BDB. === Compatibility === * Container/chroot use-cases will be affected: older rpm versions will be unable to query/manipulate the rpmdb from outside the chroot * Koji/COPR may need to override the database format (back to) BDB for the time being == How To Test == * Rpmdb gets thoroughly exercised as a matter of normal system operation, performing installs, updates, package builds etc * Of specific interest here is torture testing: forcibly killing rpm in various stages of execution - database should stay consistent and operational (other system state is out of scope) * Test database conversions from one backend to another (rpmdb --rebuilddb --define "_db_backend <backend>") == User Experience == * In normal operation, users should see little or no change * Behavior in error situations is much more robust: forcibly killed transaction no longer causes database inconsistency or corruption == Dependencies == * This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for sqlite rpmdb is not present in older versions * RPM will grow a new dependency on sqlite-libs * Technically the rpmdb format is an internal implementation detail of RPM and the data is only accessible through the librpm API, but some software is making assumptions both about the format and/or in particular, file naming. These are being tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1766120 * Upgrade tooling could/should perform rpmdb rebuild at end, this would be a good thing to do regardless of this change == Contingency Plan == * Contingency mechanism: ** Revert the default database back to Berkeley DB backend in the package. Running 'rpmdb --rebuilddb' on hosts is currently required to actually convert the database, but means to automate conversion in specific conditions is being discussed upstream. ** The rpm-team does not expect problems with the database backend itself, but we are aware that postponing may be needed due to infrastructure or other tooling not being ready, primarily due to inability to access the database from older releases. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == * [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes] == Release Notes == * After upgrading from an older release, rpm operations will issue warnings about database backend configuration not matching what's on disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or change configuration to stay on Berkeley DB backend (eg 'echo %_db_backend bdb > /etc/rpm/macros.db') * The details are subject to change, the database rebuild may be done by upgrade tooling -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

16 55

[CI][gating.yaml] Test names starting with org.centos.prod.ci.pipeline.. are deprecated
by Aleksandra Fedorova 21 May '20

21 May '20

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
40
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 May 2020