devel December 2021

devel@lists.stg.fedoraproject.org

191 participants
293 discussions

Sundials 6.0.0
by Antonio T. sagitter 08 Jan '22

08 Jan '22

Hi all. Sundials-6.0.0 is available, it's a major release that includes many changes (https://github.com/LLNL/sundials/blob/master/CHANGELOG.md) I compiled the new packages in Copr, rebuilt bout++ and octave which need attention before we can push them in Rawhide: https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/ -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/

2 2

How do we announce new packages?
by Eduard Lucena 07 Jan '22

07 Jan '22

Hello people. First of all, I'm not a developer or a packager, I just try to help with the little things I know to do. One thing I try to do is to check news, forums, ML and places where people talk about Fedora. A thing I noted is that a lot of people in magazines and news sites like phoronix, hacker news and other sites follow this list to get news about the project and it started to worry me that a big part of the traffic follow orphaned and retired packages, but nothing is never revealed/published when a new package enter the repositories or nothing similar, maybe a review swap but it's not enough. Trying to market the number of packages, the amount of free and open source software that we offer, how this could be measured and published? Is that something that require to much work? Br, -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative

12 22

F36 Change: PostgreSQL 14 (Self-Contained Change proposal)
by Ben Cotton 07 Jan '22

07 Jan '22

https://fedoraproject.org/wiki/Changes/PostgreSQL_14 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 13 to version 14 in the non-modular (main) builds. == Owner == * Name: [[User:fjanus| Filip Januš]] * Email: fjanus(a)redhat.com == Detailed Description == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 13 to version 14 in the non-modular (main) builds. This also involves updating and rebuilding the PostgreSQL plugins that depend on postgresql server. === Plan === * Prepare PostgreSQL 14 in Copr (By 2022-01-15) * Rebuild important dependencies in Copr (By 2022-01-15) * Debug and fix compatibility issues found in dependencies (a reasonable amount of non-critical in FTBFS state might be tolerable) * Prepare Pull requests in Rawhide * Merge and build PR into Rawhide == Feedback ==  == Benefit to Fedora == The latest stable software is used by Fedora users. == Scope == * Proposal owners:  **Prepare PostgreSQL 14 **Prepare PostgreSQL 13 as a module for Rawhide **Check software that requires or depends on `postgresql-server` or `libpq` packages for incompatibilities **Build PostgreSQL 14 (postgresql and libpq) to Rawhide **Rebuild depended on packages against PostgreSQL 14 **Gather user input on the changes between PostgreSQL 13 and PostgreSQL 14 * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The PostgreSQL client library (libpq component) is compatible. So, there shouldn't be any issues with compatibility, but rebuild of the depended components is recommanded. Server plugins might require a newer version update, because they sometimes have explicit server requirements. PostgreSQL maintainer will help fixing/rebuilding any issues in the plugins. == How To Test == Usual testing as when upgrading between major PostgreSQL versions, running `postgresql-setup --upgrade` is necessary between major versions. Test that all other software runs well with PostgreSQL 14. == User Experience == The users will have to upgrade their databases the same way as between major PostgreSQL versions, aka `postgresql-setup --upgrade` after installing PostgreSQL 14 server packages. If users want to stick with PostgreSQL 13 for a little longer, there will be PostgreSQL 13 module == Dependencies == There are some packages (mostly server plugins), that build on top of PostgreSQL. Since the separation of PostgreSQL client library (libpq component), only packages that build server plugins should use postgresql package in BuildRequires, others should use libpq. In case of Postgresql-server, rebuild should be done to make sure all potential binary incompatibilities are handled. * PostgreSQL server dependecies ** perl-DBD-Pg ** pgaudit ** qt ** qt3 ** qt5-qtbase ** postgres-decoderbufs ** gambas3 ** kdb ** kea ** libpqxx ** openvas-manager ** orafce ** pg-semver ** pgRouting ** pgadmin3 ** pgsphere ** postgis ** postgresql-ip4r ** postgresql-pgpool-II ** qt3 ** rdkit ** rhdb-utils ** timescaledb ** pg_repack == Contingency Plan == Revert changes in the non-modular packages and provide PostgreSQL 14 as a module stream only. == Documentation == Upgrade strategy: https://www.postgresql.org/docs/14/upgrading.html == Release Notes == Release notes for PostgreSQL 14 release: https://www.postgresql.org/docs/14/index.html Overall overview of the changes and improvements: https://www.postgresql.org/docs/14/release-14.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

2 2

Orphaning luit
by Peter Hutterer 07 Jan '22

07 Jan '22

I've orphaned luit. The only user of it was xterm and it recently dropped support for luit so there are no users left. Whether there are *any* users left is unclear too :) The luit package we shipped is still the freedesktop.org one which has been unmaintained for about a decade now. Upstream now points to Thomas Dickey's fork at http://invisible-island.net/luit/ so if anyone wants to take this, I advise switching to that version as part of the first steps. Cheers, Peter

2 1

python-lxml license change
by Mikolaj Izdebski 07 Jan '22

07 Jan '22

License of python-lxml package was changed from "BSD" to "BSD and MIT and zlib"

1 1

Switch kwrite to kate (kde)?
by Reon Beon 06 Jan '22

06 Jan '22

Thoughts?

3 2

About how Go is updated in Fedora
by Alejandro Saez Morollon 06 Jan '22

06 Jan '22

I've been thinking a little about how Go is updated in Fedora. I would like to hear other opinions about the current state of the releases and improve it. This is not related to the Fedora proposal that I'm planning to submit today regarding the update of Go. I do not pretend to change anything for the next Fedora release, but at least have an idea of if what we are doing right now can be improved. The current state: Each Fedora release has a major release of Go available. For example, Fedora 33 had 1.15, and Fedora 34 had 1.16. The problem: I see two main issues with this approach. 1. Both Go and Fedora have release cycles of 6 months, so the schedule is a little tight. Go releases can be delayed and have issues in the mass rebuild phase. 2. A user needs to wait for the next Fedora release to get a new major version of Go. So consequentially, they will tend to download from upstream, making the Go package just necessary for dependencies but with little use on its own. Also, backport bugs to Fedora releases might be a problem. Releasing packages that depend on new features are an issue too [0]. What I think is an improvement: Suppose a new Go major version is released in the middle of a Fedora life cycle. In that case, I think it is an improvement for the user to be able to update to the following Go release. A hypothetical new release cycle would look like this: - Fedora N release follows Go upstream as close as we can. - Fedora N-1 sticks with the latest major version of Go that was available on it until the release of Fedora N. Another hypothetical approach could be using modules with each upstream supported release in a stream. To help in the decision, I made a report tool/web page [1] that shows the current state of the packages that depend on Go (Thanks to the COPR API). It compares the builds of every single Go dependent package in Fedora 35 using the current available Go package with the same list of Go packages but using the Go package is available on Fedora Rawhide. To rephrase it, it compares Fedora 35 packages built with Go 1.16 with Fedora 35 packages built with Go 1.17. As you can see, right now, from the 1901 packages that depend on Go, 196 have some sort of change and 1705 built exactly the same. You can search for "Same results" or "Something has changed" to see this. Or by the name of the package. The report is not smart enough to say what happened right now so some "issues" are in fact improvements like golang-github-cactus-statsd-client, others like golang-github-briandowns-spinner are real issues. My idea is to improve this report with your suggestions. Hence, if a new Go major release is available, we can confidently say that the package can be updated in the middle of a Fedora release. [0] https://github.com/containers/podman/pull/12544 [1] https://alexsaezm.fedorapeople.org/report.html -> let it load, it has a JS that allows you to search

8 14

F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
by Ben Cotton 05 Jan '22

05 Jan '22

https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change == Summary == Update Hunspell Dictionary system directory from /usr/share/myspell/ to /usr/share/hunspell/ == Owner == * Name: [[User:vishalvvr| Vishal Vijayraghavan]] * Email: <vishalvvr(a)fedoraproject.org> == Detailed Description == In most of Linux distributions the standard Hunspell dictionary path is `/usr/share/hunspell/` but in Fedora still has `/usr/share/myspell/`. This effort is to follow default standard to install all Hunspell dictionary into `/usr/share/hunspell/` instead of `/usr/share/myspell/`. == Benefit to Fedora == This will future proof Fedora to use the correct current location for hunspell spelling dictionaries. == Scope == * Proposal owners: In total there are `135` packages which is to be updated. libreoffice & Firefox are the two main applications and rest are mostly language dictionary packages. * Other developers: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == 1. Check if default installed dictionary path is `/usr/share/hunspell/` instead of `/usr/share/myspell/` `$ hunspell -D` or `$ ls /usr/share/hunspell/` 2. Install any language dictionary and check if it getting installed into '/usr/share/hunspell/' `$ dnf install hunspell-hi` `$ hunspell -D` == User Experience == User should not notice any difference: their applications should continue to work as expected after this directory migration. == Dependencies == == Contingency Plan == * Contingency mechanism: revert release back to /usr/share/myspell * Contingency deadline: Beta * Blocks release? No -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

9 8

F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)
by Ben Cotton 04 Jan '22

04 Jan '22

https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck == Summary == Call %set_build_flags macro automatically at the beginning of the %build and %check phases of RPM builds in Fedora Linux. This will ensure that the compiler flag environment variables are set for every RPM build. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == The %set_build_flags macro exports common environment variables used for building packages: * CFLAGS * CXXFLAGS * FFLAGS * FCFLAGS * LDFLAGS * LT_SYS_LIBRARY_PATH * CC * CXX These environment variables are set to the compiler flags defined in the system RPM configuration. This macro is currently implicitly called when packages use some of the build system helper macros, like %configure, %cmake, and %meson. However, not all packages use these macros and so some packages do not use the correct compiler flags as required by the Fedora packaging guidelines[1]. This change will be implemented by updating the %__spec_build_pre and %__speck_check_pre macros in redhat-rpm-config to include %set_build_flags. This will set these environment variables automatically before the %build and %check sections. See the proposed [https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a39741… implementation] for more details. The purpose for making this change in both the %build and %check sections is because sometimes test code gets built in the %check sections for unit tests and this will ensure that the application code and its tests are built with the same set of flags. This change should have no impact on packages that already use %set_build_flags either directly or indirectly through another macro. It also won't impact any package that currently sets these environment variables or modifies any of the %{build*_flags} macros in their %build or %check sections. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags == Benefit to Fedora == This change will ensure that more packages are built using the correct compiler flags, and bring them in compliance with the Fedora packaging guidelines. It will also help improve the security of the distribution as many of the compiler flags help defend against common security attacks. == Scope == * Proposal owners: ** Make the necessary changes to redhat-rpm-config. ** Help debug any issues uncovered by this change during the mass rebuild. * Other developers: ** Report bugs to the proposal owner. * Release engineering: [https://pagure.io/releng/issue/10482 #10482] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == How To Test == This change will be tested by rebuilding packages as part of the mass rebuild. == User Experience == This change will make some packages less susceptible to security exploits. == Contingency Plan == * Contingency mechanism: The proposal owner will revert the change in redhat-rpm-config * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == None needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

7 20

Heads-up: lxqt libraries soname bump
by Zamir SUN 03 Jan '22

03 Jan '22

Hi, I'm updating the whole LXQt desktop to 1.0.0 in rawhide, and I've built the packages in the side tag f36-build-side-49104. The following package contains library with a soname bump liblxqt (liblxqt.so.1) liblxqt-globalkeys (liblxqt-globalkeys.so.1,liblxqt-globalkeys-ui.so.1) I hope I did not miss anything. IIRC there are no packages outside of the LXQt SIG depends on those, but I'd like to still make people aware of the change and possible other packages I missed. I'll merge the side tag by the last day of the year. HTH. -- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/

4 5

← Newer
1
2
3
4
5
6
7
...
30
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 December 2021