devel July 2019

devel@lists.fedoraproject.org

227 participants
279 discussions

Fedora 31 System-Wide Change proposal (late): No i686 Repositories
by Miro Hrončok 21 Sep '19

21 Sep '19

https://fedoraproject.org/wiki/Changes/Noi686Repositories (Ben is on vacation, so I announcing this on his behalf.) == Summary == Stop producing and distributing the Modular and Everything i686 repositories. == Owner == * Name: Kevin Fenzi * Email: kevin(a)scrye.com == Current status == * Targeted release: [[Releases/31| Fedora 31 ]] * Last updated:  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} * Tracker bug: <will be assigned by the Wrangler> * Release notes tracker: <will be assigned by the Wrangler> == Detailed Description == With the dropping of the i686 kernel package it's no longer possible to directly install Fedora 31 or later on i686 hardware, however, it is still possibly to upgrade older releases as long as we continue to provide a repository. This will leave those users with an old possibly vulnerable kernel installed. The only other use/need for the repostories is to allow maintainers to debug and test fixes for multilib shipped packages, but the koji buildroot repo can be used for this use case. == Benefit to Fedora == * users won't try and upgrade old i686 installs with insecure kernels. * compose times will be decreased (no more gathering i686 packages up and running createrepo on them). * Updates push times will be reduced. * disk size on mirrors will be reduced. == Scope == * Proposal owners: ** modify pungi-fedora to no longer produce i386 repo for Everything and Modular, modify bodhi config for f31+ to not make i386 repos for updates/updates-testing. ** modify mock to use the koji buildroot for i686 for f31+ for those few users that need to build i686 packages locally. * Other developers: n/a * Release engineering: [https://pagure.io/releng/issues 8529] == Upgrade/compatibility impact == i686 users will not be able to upgrade, and will have to move to another supported arch. == How To Test == * Confirm that there are no trees under https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Every… or https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Modul… * Confirm that there are no trees under https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|Mo… or https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Every… * Confirm that mock can init a chroot for fedora-i386-31 using the koji buildroot repository. == User Experience == * Users will get updates and rawhide and rc composes faster. * Users will not be able to upgrade to a insecure Fedora configuration. == Contingency Plan == i686 trees will just continue to be composed and published. Users can upgrade to them (with an old kernel from f30). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

48 165

Donate 1 minute of your time to test upgrades from F29 to F30
by Miroslav Suchý 13 Sep '19

13 Sep '19

Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run: sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the real upgrade. Upgrades will be fine for you. But very likely you get some dependency problem now. In that case please report it against appropriate package. Thank you Miroslav

37 71

Re: Possibly unresponsive maintainer: vakwetu
by Fabio Valentini 13 Sep '19

13 Sep '19

On Tue, Jul 9, 2019 at 3:26 PM Rob Crittenden <rcritten(a)redhat.com> wrote: > > Fabio Valentini wrote: > > Hi everybody, > > > > While working on packages of the Stewardship SIG, I again came across > > another package that is in dire need of attention, while its main > > admin seems to be AWOL (even though the email address associated with > > his FAS account is a Red Hat one): > > > > - no bodhi updates in 4 years [0] > > - no bodhi comments in 2 years [0] > > - no koji builds in 4 years [1] > > > > There's also been no response to security issues on bugzilla, > > including CVE-2016-6346, CVE-2016-6347, CVE-2018-1051, CVE-2016-9606, > > CVE-2016-6345, CVE-2016-6348 - all of which are filed against the > > resteasy package, which is, entirely by coincidence (*sigh*), exactly > > the package that we need fixed for some Stewardship SIG packages. > > > > Since it looks like he's not been contributing to fedora in about 2-4 > > years, I will initiate the non-responsive maintainer process with > > FESCo if I don't get any negative feedback within a week. > > > > Fabio (decathorpe) > > > > [0]: https://bodhi.fedoraproject.org/users/vakwetu > > [1]: https://koji.fedoraproject.org/koji/userinfo?userID=2030 > > He's on PTO for a few weeks. > > rob Good to know, thanks! If it's necessary to fix the broken package (resteasy) before he's back, I'll use my provenpackager powers. Fabio

4 7

Packit-as-a-Service is now live!
by Tomas Tomecek 12 Sep '19

12 Sep '19

We are happy to announce the availability of Packit-as-a-Service [1], a GitHub App, which utilizes the Packit project [2]. Using the Packit service in your upstream projects helps you continuously ensure that your projects work in Fedora OS. Just add one config file [3] to your repository, along with the RPM spec file and you're almost there. We have started publishing docs for the service over here [4]. In the next couple of months, Packit Service will run in an invite-only mode, where we need to manually approve every user of the app. Our initial target is Fedora contributors. Packit service validates your pull requests by building your software in Fedora OS. Once the builds are done, Packit lets you know how to install the RPM with the change inside your environment. Packit service helps you test the changes before merging them to the main developer branch and shipping them to your users. Happy hacking! The packit team [1] https://github.com/apps/packit-as-a-service/ [2] https://packit.dev/ [3] https://github.com/packit-service/packit/blob/master/docs/configuration.md [4] https://packit.dev/packit-as-a-service/

2 1

Interest in doing Fedora CI with test subpackages
by Neil Horman 11 Sep '19

11 Sep '19

Hey all- I was starting to setup CI for one of my packages in Fedora (cscope), which requires that I have access to the sources to run my test (cscope uses its own source tree to search for various symbols to confirm that its working properly). Getting the sources in the CI environment is a bit of a pain, so I started working on trying to do this by creating a test subpackage (specifically named -citest) to package up the sources solely for the purpose of getting them installed and available during CI runs. It occured to me that this offers several advantages, among them: 1) the ability to codify dependencies within the ame spec file, rather than having to copy them to the test.yml file, and keep them in sync 2) The ability to use a file format (rpm spec files) that I'm more familiar with 3) Easy access to tests that are embedded in the source tree 4) minimizing the test harness setup in test.yml For anyone interested, I've got a pull request started here: https://src.fedoraproject.org/rpms/cscope/pull-request/2 If anyone wants to take a look at the changes I had to make to do this (fair warning, its still very rough). That all said, I was wondering if perhaps there was general interest in making this kind of test model somewhat more formal (i.e. creating an rpm macro library to make test package generation a bit easier, creating a standard entry point to run tests, etc). Thoughts welcome

3 3

Please help with youtube-dl and possibly other packages of mine.
by Till Maas 11 Sep '19

11 Sep '19

Hi, Please help with updating youtube-dl and possibly other packages of mine because I cannot do it and my comaintainers do not seem to be able to do it as well. Thank you and kind regards Till

4 4

Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
by Ben Cotton 09 Sep '19

09 Sep '19

https://fedoraproject.org/wiki/Changes/fedora-change-wrangler = Track Changes in Taiga = The Motivation for this proposal is to propose using the Taiga instance at teams.fedoraproject.org for Change processing. [[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously proposed for this. The new Change Processing workflow aims to simplify the process to improve visibility and ease of management. == Summary == The current process allows contributors to propose changes in upcoming Fedora releases. However, the management of those feature proposals is cumbersome and requires several manual steps. This introduces more opportunity for error and reduces the time available to the Change Wrangler for more valuable contributions to Fedora. In particular, the current process includes artifacts and discussion in the Fedora Wiki, on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets. The current process is cumbersome with several manual steps,this introduces more opportunity for error and reduces the time available for the Change Wrangler. A Cli Tool Written in Python that interacts with Taiga,Pagure and Bugzilla.Functionality includes Promoting,announcing,submitting,accepting and updating the changes across the three platforms and over mailing list. The new process will consolidate much of the information in Taiga.Proposed Changes will be submitted as an issue in Taiga. The description of the Issue will include the content with few exceptions: * System-Wide or Self-Contained change will be indicated by a binary in the issue metadata * Fedora release will be indicated by a milestone in the issue metadata * Change status will be indicated by a list selection in the issue metadata == Owner == * Name: [[User:Pac23| Manas Mangaonkar]] * Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org * Name: [[User:Bcotton | Ben Cotton]] * Email: bcotton(a)redhat.com == Detailed Description == As Part of GSoC 2019 the fedora-change-wrangler tool will be developed to smooth out the workflow,reduce Manual Work involved for both the Contributors and the Change-Wrangler(FPgm). The tool makes it easy by covering all the functionality required for the process of moving forward proposals. The tool will be developed using Python 3.6+ and will interact with Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP. The General Workflow would be : 1. Change Owner opens an issue and fills in the fields. When they are ready to submit the Change proposal, they set the status to "Ready for Wrangler". 2. The Change Wrangler (FPgM) reviews the proposal. If it is incomplete, they set the status back to "New" and inform the Change Owner of what's needed. If it is ready to process, then... Functionality covered 1. Promote * The issue will be promoted to a user story in taiga,copies the contents of the custom fields from the issue to the user story. Closes the issue. 2. Announce * The tool would have the functionality to enable announcing the change proposal to devel and devel-announce lists using smtp. It will also automatically change the story status to announced. 3. fesco-submit * Allowing creation of a new issue in the FESco Pagure repo directly from the command line. 4. Accept * Once the changes are accepted the change-wrangler can create a tracking bug in Bugzilla along with release notes on Pagure.THe status of the user story is updated to accepted aswell. 5. Update * Status can be changed to testable if BZ is "Modified" and to Complete is BZ is "ON_QA" 6. Creation of Report * The user can create a report to provide quick view of changes and their status. It can be in wiki or Html form. Techstack: * Python3.6+ * SMTP * Taiga/Pagure/Bugzilla API's * Nano/Gedit/Vi ( Inbuilt support to edit text) * Kerberos(For authentication) The current sample arg created looks like this [ change-tool convert --taiga <issue no> <issue no> ] . The advantage of this the Manager would be able to specify unlimited no of issues to change at once in a single command using the issue no in taiga to convert to user story. == Benefit to Fedora == The proposed change will make the change-process easier for everyone.Everyone would be able to see them in one place with status,id filters. The current wiki process can be bit difficult for formatting,having defined fields would mean easy access without the cumbersome wiki edits. Since changes would be submitted in Issue format on Taiga,pre-submission discussions would be available thus getting suggestions/feedback at the first stage itself would be easy for everyone involved. == Scope == * Proposal owners: I will be working with the Change-Wrangler(Ben Cotton) throughout the summer to create this tool from scratch. * Other developers: N/A (not a System Wide Change) * Release engineering:(no release engineering impact is expected) * 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 visible Impact is expected. == Dependencies == No other packages depend on this. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) Enough buffer time has been allocated to complete this during the GSoC period. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

5 7

RH Account of package maintainer disabled
by Till Hofmann 09 Sep '19

09 Sep '19

Hi all, I'm trying to contact the maintainer (Marek Skalický) of mongo-cxx-driver, which has a pending update: https://bugzilla.redhat.com/show_bug.cgi?id=1723810 However, if I try to select "Need additional information", I get an error: You can't ask Marek Skalický <mskalick(a)redhat.com> because that account is disabled. Should the package have been orphaned? Kind regards, Till

3 3

Duplicate speedtest-cli packages in the repo.
by Leigh Scott 08 Sep '19

08 Sep '19

speedtest-cli and python3-speedtest-cli appear to be the same package. Downloading Packages: python3-speedtest-cli-1.0.2-7.fc30.noarch.rpm 364 kB/s | 44 kB 00:00 -------------------------------------------------------------------------------- Total 64 kB/s | 44 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction check error: file /usr/lib/python3.7/site-packages/speedtest.py from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch file /usr/lib/python3.7/site-packages/speedtest_cli.py from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch file /usr/share/man/man1/speedtest-cli.1.gz from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch Error Summary

2 1

Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
by Ben Cotton 01 Sep '19

01 Sep '19

https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression = Switch RPMs to zstd compression = == Summary == Binary RPMs are currently compressed with xz level 2. Switching to zstd would increase decompression speed significantly. == Owner == * Name: [[User:dmach| Daniel Mach]] * Email: dmach(a)redhat.com == Detailed Description == * The change requires setting a new compression algorithm in rpm macros. Then a mass rebuild of all packages is required. * The macro for setting the compression is: %define _binary_payload w19.zstdio * The recommended compression level is 19. The builds will take longer, but the additional compression time is negligible in the total build time and it pays off in better compression ratio than xz lvl2 has. * SRPM payload compression should stay at gzip (there's almost no benefit in changing the compression, because SRPM's contents is compressed already) === Use case: Firefox installation === I rebuilt firefox-66.0.5-1.fc30 with zstd level19. Then I compared installation times with the original (xz compressed) package: {| class="wikitable" |- ! Compression !! Target File System !! Time |- | xz level 2 || tmpfs || 8s |- | xz level 2 || ext4 on nvme || 11s |- | zstd level 19 || tmpfs || 2s |- | zstd level 19 || ext4 on nvme || 4s |- |} === Comparison of compression algorithms and levels === Following table shows '''cpio''' and '''compressed cpio''' extraction times into a tmpfs. Actual times in decompressing RPMs will differ due to extracting on an actual disk and also some overhead in the RPM tool (checks, scriptlets). {| class="wikitable" |- ! Compression !! Level !! Size B !! Size GiB !! Compression time !! Compression time, 4 threads !! Decompression time !! Comment |- | CPIO || - || 5016785692 || 4,7 || - || - || - || |- | xz || 2 || 1615017616 || 1,6 || 9m55s || - || 1m36s || slow decompression |- | pxz || 2 || 1631869880 || 1,6 || - || 6m11s || 1m38s || slow decompression |- | gzip || 9 || 2086354992 || 2,0 || 10m23s || - || 31s || insufficient compression ratio |- | bzip2 || 9 || 1889161565 || 1,8 || 8m || - || 2m50s || very slow decompression; compression ratio could be better |- | zstd || 3 || 1913536587 || 1,8 || 31s || 29s || 6,5s || |- | zstd || 10 || 1737928978 || 1,7 || 3m27s || 2m34s || 6,3s || |- | zstd || 15 || 1717303256 || 1,7 || 9m37s || 6m34s || 6,3s || identical compression speed to xz; fast decompression; slightly worse compression ratio than xz |- | zstd || 17 || 1635525492 || 1,6 || 16m16s || 11m20s || 6,7s || |- | zstd || 19 || 1575843696 || 1,5 || 24m2s || 18m55s || 7,7s || |- |} == Benefit to Fedora == * Faster installations/upgrades of user systems * Faster koji builds (installations in build roots) * Faster container builds * Lower bandwidth on mirrors if we choose the highest compression level == Scope == * Proposal owners: submit a patch to redhat-rpm-config * Other developers: redhat-rpm-config maintainer: include the patch and make a new build * Release engineering: [https://pagure.io/releng/issue/8345 #8345] mass rebuild is needed == Upgrade/compatibility impact == * RPM in Fedora supports zstd compression already (from Fedora 28, rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected. * Fedora <= 27 and some other distros will not be able to decompress zstd-compressed RPMs. == How To Test == * dnf install <package> * rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" <package> * expected output: zstd 19 Also the overall system installation time should decrease significantly. == User Experience == See '''Benefit to Fedora''' == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Not needed, Fedora will stay at current compression. * Contingency deadline: N/A * Blocks release? No * Blocks product? N/A == Documentation == N/A == Release Notes == RPMs have switched to zstd compression level 19. Users will benefit from faster package decompression. Users that build their packages will experience slightly longer build times. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

31 83

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