Re: End of CentOS Linux: What about Fedora?
On Thu, 2020-12-10 at 03:59 +0100, Kevin Kofler via devel wrote: > Jaroslav Prokop wrote: > > But apparently some already took on this task [0]. > > [0] https://github.com/hpcng/rocky > > The official website is: > https://rockylinux.org/ > (Still somewhat under construction, of course.) > > It was started by the original founder of CentOS with the aim of going back > to the roots of CentOS, the way it worked before Red Hat started their > Embrace, Extend, Extinguish scheme. Off the record...there really wasn't one. It was an Embrace, Equivocate, Evacuate policy... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1906282] New: perl-Text-Fuzzy-0.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1906282 Bug ID: 1906282 Summary: perl-Text-Fuzzy-0.29 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Text-Fuzzy Keywords: FutureFeature, Triaged Assignee: de...@fateyev.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.29 Current version/release in rawhide: 0.28-8.fc33 URL: http://search.cpan.org/dist/Text-Fuzzy/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/9583/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1906282] perl-Text-Fuzzy-0.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1906282 --- Comment #1 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Good morning, 20/12/9 23:24(e)an, Kevin Fenzi igorleak idatzi zuen: On Wed, Dec 09, 2020 at 08:02:45AM +0100, Julen Landa Alustiza wrote: 20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen: On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote: On 12/3/20 4:39 PM, Petr Šabata wrote: On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote: On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote: Since I don't see those on the list, does this impact * rpkg (fedpkg)? Wrapper to git, should not be impacted. The only thing I could think of was: when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M main" directly. That being said, I'm not 100% sure when we creating a project on dist-git today we create them empty. Optionally, they can be empty. $ fedpkg request-repo ... --no-initial-commit This could be anoying if someone then pushes as master branch back up, but I guess we can take those on a case by case basis. This change proposal should cover changing pagure-dist-git's rules so that should be impossible. Indeed, we can add that. Indeed we'll need to be able to opt-in to the new naming on some repos while the rest keeps the old one, so we could temporary need to disable the hardcoded rules and rely on upstream protected branches feature or something similar at least during the transition. I'm not sure what you mean here. Someone pushing while we are changing the repos? I thought there were some rpms namespace repos on phase 0, but that's not true, so nevermind. We can just modify dist-git for full rpms namespace :) src.fp.o has strict rules to avoid to push some tags, this transition must keep those stricts rules in place while transitioning imo Yep. And add master. Will update the change. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] Heads-up: Discussing proposed changes to the EPEL Packagers SIG documentation
Background: we're resurrecting the dormant epel-wranglers SIG as epel- packagers-sig. Members will co-maintain packages for EPEL that the SIG is interested in, if the primary maintainers are not interested in supporting EPEL. Per the discussion in the EPEL SIG meeting last Friday, the following changes to the documentation will be discussed in the next meeting (Friday, December 11, 14:00 EST in #fedora-meeting) https://fedoraproject.org/w/index.php?title=EPEL%2FPackagers=revision=596506=592132 - the SIG should review the list of open requests and track the ones it is interested in. Query added to the wiki - the mechanism for joining the SIG (currently borrowed from the provenpackagers instructions but lowered the acceptance threshold given there's not that many SIG members yet) Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
Jaroslav Prokop wrote: > But apparently some already took on this task [0]. > [0] https://github.com/hpcng/rocky The official website is: https://rockylinux.org/ (Still somewhat under construction, of course.) It was started by the original founder of CentOS with the aim of going back to the roots of CentOS, the way it worked before Red Hat started their Embrace, Extend, Extinguish scheme. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1906256] New: perl-Cache-FastMmap-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1906256 Bug ID: 1906256 Summary: perl-Cache-FastMmap-1.53 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Cache-FastMmap Keywords: FutureFeature, Triaged Assignee: jpazdzi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jpazdzi...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.53 Current version/release in rawhide: 1.51-1.fc34 URL: http://search.cpan.org/dist/Cache-FastMmap/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6745/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[EPEL-devel] Re: plasma desktop not starting on CentOS 8.3
On 12/9/20 9:27 AM, Orion Poplawski wrote: After updating to CentOS 8.3, my plasma (KDE) desktop is not starting. It seems like X is not starting. Is anyone else seeing this and knows what's happening? I haven't had a chance to dig much deeper myself yet... Orion This was likely triggered by our anti-virus software (don't ask), so unlikely to affect others. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
[Bug 1902861] perl-Locale-Codes-3.66 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1902861 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Locale-Codes-3.66-1.fc |perl-Locale-Codes-3.66-1.fc |34 |34 |perl-Locale-Codes-3.66-1.fc |perl-Locale-Codes-3.66-1.fc |33 |33 ||perl-Locale-Codes-3.66-1.fc ||32 --- Comment #6 from Fedora Update System --- FEDORA-2020-a027dc1c6a has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1902728] perl-PAR-Dist-0.51 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1902728 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-PAR-Dist-0.51-1.fc34 |perl-PAR-Dist-0.51-1.fc34 |perl-PAR-Dist-0.51-1.fc33 |perl-PAR-Dist-0.51-1.fc33 ||perl-PAR-Dist-0.51-1.fc32 --- Comment #6 from Fedora Update System --- FEDORA-2020-ba9ea7701d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1902861] perl-Locale-Codes-3.66 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1902861 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Locale-Codes-3.66-1.fc |perl-Locale-Codes-3.66-1.fc |34 |34 ||perl-Locale-Codes-3.66-1.fc ||33 Resolution|--- |ERRATA Last Closed||2020-12-10 01:13:54 --- Comment #5 from Fedora Update System --- FEDORA-2020-6c3985436d has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1902728] perl-PAR-Dist-0.51 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1902728 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-PAR-Dist-0.51-1.fc34 |perl-PAR-Dist-0.51-1.fc34 ||perl-PAR-Dist-0.51-1.fc33 Resolution|--- |ERRATA Last Closed||2020-12-10 01:13:43 --- Comment #5 from Fedora Update System --- FEDORA-2020-4a49e3b0ab has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On 2020-12-09 16:46, Damian Ivanov wrote: All this sounds cool, rolling release FTW! On that topic (rolling release) I have another suggestion - please fork the thread if that's too OT. Rawhide is good so far but is not suitable as a productive rolling release because some packages have debug flags that slow the system down (I have measured it and rawhide is always significantly slower on my devices). Maybe provide a rolling release fedora as well (which is suitable for non-debug systems). Regards, Damian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org What packages have debug flags? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Rawhide users: don't update to 20201208.n.0 packages (fprintd 1.90.6), console login and su are broken
On Wed, Dec 09, 2020 at 12:53:05PM -0800, Adam Williamson wrote: ...snip... > > There were bug reports already that I hadn't found as I was looking for > glibc bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=1905667 > https://bugzilla.redhat.com/show_bug.cgi?id=1905964 > > so, skip fprintd 1.90.6! There's a fixed fprintd now, however glibc still does have a bug where it doesn't give you your secondary groups on login. This makes it hard to use 'sudo' if you depend on being in the 'wheel' group. A fix is being worked on, but in the mean time as a workaround you can use 'newgrp wheel' and then sudo. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: %pytest and pytest-django
On 12/10/20 12:47 AM, Miro Hrončok wrote:
On 12/9/20 10:43 PM, Kai A. Hiller wrote:
Hi,
I'm the maintainer of a python package that uses pytest and the pytest plugin
pytest-django (python-authlib). Under %check I currently run `%{python3} -m
pytest tests/core` to execute the tests. Now I wanted to do the right thing
and change that line to the %pytest macro (`%pytest tests/core`) and that failed:
ModuleNotFoundError: No module named 'tests'
ImportError: No module named 'tests'
pytest-django could not find a Django project (no manage.py file could be
found). You must explicitly add your Django project to the Python
path to have it picked up.
I think the macro and the plugin are interfering here. Is there something that
has to be changed in my spec file, the plugin or the
macro itself to make it work? Should I just keep it the way it is?
It seem that the tests require current working directory to be on the Python
path. `%{python3} -m pytest` does that, `%pytest` doesn't -- because usually you
want to avoid that (to actually import the code from %{python3_site(lib|arch)}
instead of $PWD). In this case, where it cannot be avoided, you can try either:
PYTHONPATH=$PWD %pytest
Or possibly (if it works):
PYTHONPATH=%{buidlroot}%{python3_sitelib}:$PWD %pytest
Or keep using `%{python3} -m pytest`. But note that `%pytest` also sets other
useful environment variables.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On 12/9/20 7:44 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault ... * Policies and guidelines: N/A (not a System Wide Change) Should there be an update of: https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ ? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: %pytest and pytest-django
On 12/9/20 10:43 PM, Kai A. Hiller wrote:
Hi,
I'm the maintainer of a python package that uses pytest and the pytest plugin
pytest-django (python-authlib). Under %check I currently run `%{python3} -m
pytest tests/core` to execute the tests. Now I wanted to do the right thing and
change that line to the %pytest macro (`%pytest tests/core`) and that failed:
ModuleNotFoundError: No module named 'tests'
ImportError: No module named 'tests'
pytest-django could not find a Django project (no manage.py file could be
found). You must explicitly add your Django project to the Python
path to have it picked up.
I think the macro and the plugin are interfering here. Is there something that
has to be changed in my spec file, the plugin or the
macro itself to make it work? Should I just keep it the way it is?
It seem that the tests require current working directory to be on the Python
path. `%{python3} -m pytest` does that, `%pytest` doesn't -- because usually you
want to avoid that (to actually import the code from %{python3_site(lib|arch)}
instead of $PWD). In this case, where it cannot be avoided, you can try either:
PYTHONPATH=$PWD %pytest
Or keep using `%{python3} -m pytest`. But note that `%pytest` also sets other
useful environment variables.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On 12/9/20 9:56 PM, Troy Dawson wrote: On Wed, Dec 9, 2020 at 11:21 AM Miro Hrončok wrote: On 12/9/20 7:44 PM, Ben Cotton wrote: == How To Test == * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. What is the plan wrt Obsoletes of the removed packages? -- Miro Hrončok -- We do not plan on obsoleting them. Obsoleting them has the potential to break third party software. dnf should also clean things up by seeing that the dependencies of an upgraded package have gone away. If dnf misses it, these are libraries, not binaries. If nothing is using them, they just take up some disk space. If a user really wants to clean them up, those types of users usually have their favorite ways of doing so. I worry about this specific case: There are several JS libraries unbundled in python-notebook. Due to RPM/DNF limitations, they can onyl be unbondled if the JS packages are obsoleted: https://bugzilla.redhat.com/show_bug.cgi?id=1787079#c8 I can definitively make sure the relevant packages are obsoleted by fedora-obsolete-packages but that opens a can of worm, because if only some removed packages are obsoleted, other removed packages will block the upgrade path to Fedora 34/35. And they will need to be obsoleted as well. I rutinelly spend several hours each release to figure out and fix upgrade path issues by obsoleting packages via fedora-obsolete-packages. I'd like some help with this by the change owners / NodeJS SIG. Can I count on that? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 09, 2020 at 12:27:10AM +0100, Miro Hrončok wrote: > On 12/8/20 11:54 PM, Kevin Fenzi wrote: > > Well, I don't want to keep master around in any form... and yeah, I > > realize there's going to be fallout. ;( > > Maybe we can phase it? First, provide the backwards compatible ref, see what > breaks anyway. And only after some time, remove it? We could, but I think thats just kicking the can down the road and it's better to just do it and fix things now when we have time, rather than later when we might have less. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 09, 2020 at 08:09:44AM +0100, Julen Landa Alustiza wrote: > Would be great if we add a deprecation notice (wich could include an EOL for > the symbolic-ref) to git's output while operating on master branch :D I think that would require changes on the git client end? kevin -- > > > > 20/12/3 16:53(e)an, Daniel P. Berrangé igorleak idatzi zuen: > > On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main > > > > > > == Summary == > > > > > > This Change will move Fedora git repositories to use "main" as the > > > default git branch instead of "master". Specific repositories will be > > > manually moved and default git branch for new projects will be set to > > > use "main". > > > > > > The Fedora Community strives to be open and welcoming. Some language > > > around our git repositories is dated and could be more inclusive. Many > > > git repositories currently use "master" as the default branch. This > > > Change will move many repositories (see below) to use a "main" branch > > > as default. This small bit of naming adjustment is in-line with > > > Fedora's vision for free and open source software built by inclusive, > > > welcoming, and open-minded communities. > > > > snip > > > > > == Upgrade/compatibility impact == > > > > > > Users with old checkouts will need to update their git configuration > > > or re-clone repositories that have changed before they can see any new > > > changes. > > > > Is it possible to enhance pagure to support configuring branch > > symbolic refs when branches are renamed, so clients don't need > > to update their checkout ? IIUC, it involves running something > > approximately like this on the server git repo: > > > > git symbolic-ref refs/heads/master refs/heads/main > > > > > > > > Regards, > > Daniel > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 09, 2020 at 08:02:45AM +0100, Julen Landa Alustiza wrote: > > > 20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen: > > On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote: > > > On 12/3/20 4:39 PM, Petr Šabata wrote: > > > > On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon > > > > wrote: > > > > > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote: > > > > > > Since I don't see those on the list, does this impact > > > > > > > > > > > > * rpkg (fedpkg)? > > > > > Wrapper to git, should not be impacted. The only thing I could think > > > > > of was: > > > > > when we fedpkg clone an empty git repo, have fedpkg do the "git > > > > > branch -M main" > > > > > directly. That being said, I'm not 100% sure when we creating a > > > > > project on > > > > > dist-git today we create them empty. > > > > > > Optionally, they can be empty. > > > > > >$ fedpkg request-repo ... --no-initial-commit > > > > This could be anoying if someone then pushes as master branch back up, > > but I guess we can take those on a case by case basis. > This change proposal should cover changing pagure-dist-git's rules so that > should be impossible. Indeed, we can add that. > Indeed we'll need to be able to opt-in to the new naming on some repos while > the rest keeps the old one, so we could temporary need to disable the > hardcoded rules and rely on upstream protected branches feature or something > similar at least during the transition. I'm not sure what you mean here. Someone pushing while we are changing the repos? > > src.fp.o has strict rules to avoid to push some tags, this transition must > keep those stricts rules in place while transitioning imo Yep. And add master. Will update the change. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 09, 2020 at 04:25:53PM -0500, Stuart D Gathman wrote: > Wouldn't "rawhide" be more consistent with the other branch names? This has been discussed elsewhere in the thread. I think we agreed to add a sym-ref between rawhide and main (ie, either would work). I can get the change updated. kevin -- > > On Thu, 3 Dec 2020, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main > > > > == Summary == > > > > This Change will move Fedora git repositories to use "main" as the > > default git branch instead of "master". Specific repositories will be > > manually moved and default git branch for new projects will be set to > > use "main". > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 09, 2020 at 09:21:34PM -, Jean-Baptiste Holcroft wrote: > hi, > > I see some pagure.io project are automatically handled by this change > > could teams register their repositories to be migrated automatically? > if so, what's the deadline to ask for our repositories to be included in this > change? Yes, I think we could look at doing more on an opt-in basis if that was something folks wanted. I'd say get the list into us the week before? Or if after just file a infrastructure ticket with list and we can do it then (although it might be nice to do as the same time as others I agree). kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Fedora 34 Change proposal: Boost 1.75 upgrade (System-Wide Change)
https://fedoraproject.org/wiki/Changes/F34Boost175 == Summary == This change brings Boost 1.75 to Fedora. This will mean Fedora ships with a recent upstream Boost release. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodg...@redhat.com == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is absent from Boost, this entails rebuilding of all dependent packages. This also entails the change owner assisting maintainers of client packages in decoding cryptic boost-ese seen in output from g++. The equivalent changes for previous releases were [[Changes/F33Boost173]], [[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora 28 Change]], [[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora 25 Change]], [[Changes/F24Boost160|Fedora 24 Change]], [[Changes/F23Boost159|Fedora 23 Change]] and [[Changes/F22Boost158|Fedora 22 Change]]. == Benefit to Fedora == Fedora 33 includes Boost 1.73 (released April 28th 2020). Fedora will stay relevant, as far as Boost clients are concerned. In addition to serveral bug fixes and enhancements to existing components (including many as part of Boost 1.74's release) Boost 1.75 brings three new components: * [https://www.boost.org/doc/libs/1_74_0/libs/stl_interfaces Boost.STL_Interfaces], A library to assist in writing STL conforming iterators, views, and containers, from T. Zachary Laine (introduced in Boost 1.74). * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/json/ Boost.JSON], A portable C++ library which provides containers and algorithms that implement JavaScript Object Notation, from Vinnie Falco, Krystian Stasiowski. * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/leaf Boost.LEAF], A lightweight error handling library for C++11, from Krystian Stasiowski. * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/pfr Boost.PFR], A C++14 library for very basic reflection, from Antony Polukhin. == Scope == * Proposal owners: ** Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) ** Request a "f34-boost" [https://docs.pagure.org/releng/sop_adding_side_build_targets.html build system tag] ([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html discussion]): ** Build boost into that tag (take a look at the [http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493] for inspiration) ** Post a request for rebuilds to fedora-devel ** Work on rebuilding dependent packages in the tag. ** When most is done, re-tag all the packages to rawhide ** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: ** Those who depend on Boost DSOs will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Policies and guidelines: ** Apart from scope, this is business as usual, so no new policies, no new guidelines. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. Historically this hasn't been too much of a problem and could always be resolved before deadline. == How To Test == * No special hardware is needed. * Integration testing simply consists of installing Boost packages (`dnf install boost`) on Fedora and checking that it does not break other packages (see below for a way to obtain a list of boost clients). == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new Boost packages, and may need to adjust their code if the new Boost release is not source-compatible. * Developers using `bjam` to build their own software will need to switch to using the new name for the tool, `b2` == Dependencies == Packages that must be rebuilt: $ dnf repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u All clients: $ dnf repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F34 with Boost 1.73, which is already in rawhide. It would also be possible to ship the 1.74.0 which would still be newer than in current Fedora releases and contains numerous fixes and improvements to existing Boost components. * Contingency deadline: We will know whether the change can be made once the rebuilds in the side tag are done * Blocks release? No * Blocks product? None == Documentation == * https://www.boost.org/users/history/version_1_75_0.html (expected release mid December 2020) *
Fedora 34 Change proposal: Boost 1.75 upgrade (System-Wide Change)
https://fedoraproject.org/wiki/Changes/F34Boost175 == Summary == This change brings Boost 1.75 to Fedora. This will mean Fedora ships with a recent upstream Boost release. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodg...@redhat.com == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is absent from Boost, this entails rebuilding of all dependent packages. This also entails the change owner assisting maintainers of client packages in decoding cryptic boost-ese seen in output from g++. The equivalent changes for previous releases were [[Changes/F33Boost173]], [[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora 28 Change]], [[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora 25 Change]], [[Changes/F24Boost160|Fedora 24 Change]], [[Changes/F23Boost159|Fedora 23 Change]] and [[Changes/F22Boost158|Fedora 22 Change]]. == Benefit to Fedora == Fedora 33 includes Boost 1.73 (released April 28th 2020). Fedora will stay relevant, as far as Boost clients are concerned. In addition to serveral bug fixes and enhancements to existing components (including many as part of Boost 1.74's release) Boost 1.75 brings three new components: * [https://www.boost.org/doc/libs/1_74_0/libs/stl_interfaces Boost.STL_Interfaces], A library to assist in writing STL conforming iterators, views, and containers, from T. Zachary Laine (introduced in Boost 1.74). * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/json/ Boost.JSON], A portable C++ library which provides containers and algorithms that implement JavaScript Object Notation, from Vinnie Falco, Krystian Stasiowski. * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/leaf Boost.LEAF], A lightweight error handling library for C++11, from Krystian Stasiowski. * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/pfr Boost.PFR], A C++14 library for very basic reflection, from Antony Polukhin. == Scope == * Proposal owners: ** Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) ** Request a "f34-boost" [https://docs.pagure.org/releng/sop_adding_side_build_targets.html build system tag] ([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html discussion]): ** Build boost into that tag (take a look at the [http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493] for inspiration) ** Post a request for rebuilds to fedora-devel ** Work on rebuilding dependent packages in the tag. ** When most is done, re-tag all the packages to rawhide ** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: ** Those who depend on Boost DSOs will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Policies and guidelines: ** Apart from scope, this is business as usual, so no new policies, no new guidelines. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. Historically this hasn't been too much of a problem and could always be resolved before deadline. == How To Test == * No special hardware is needed. * Integration testing simply consists of installing Boost packages (`dnf install boost`) on Fedora and checking that it does not break other packages (see below for a way to obtain a list of boost clients). == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new Boost packages, and may need to adjust their code if the new Boost release is not source-compatible. * Developers using `bjam` to build their own software will need to switch to using the new name for the tool, `b2` == Dependencies == Packages that must be rebuilt: $ dnf repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u All clients: $ dnf repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F34 with Boost 1.73, which is already in rawhide. It would also be possible to ship the 1.74.0 which would still be newer than in current Fedora releases and contains numerous fixes and improvements to existing Boost components. * Contingency deadline: We will know whether the change can be made once the rebuilds in the side tag are done * Blocks release? No * Blocks product? None == Documentation == * https://www.boost.org/users/history/version_1_75_0.html (expected release mid December 2020) *
%pytest and pytest-django
Hi,
I'm the maintainer of a python package that uses pytest and the pytest
plugin pytest-django (python-authlib). Under %check I currently run
`%{python3} -m pytest tests/core` to execute the tests. Now I wanted to
do the right thing and change that line to the %pytest macro (`%pytest
tests/core`) and that failed:
ModuleNotFoundError: No module named 'tests'
ImportError: No module named 'tests'
pytest-django could not find a Django project (no manage.py file could
be found). You must explicitly add your Django project to the Python
path to have it picked up.
I think the macro and the plugin are interfering here. Is there
something that has to be changed in my spec file, the plugin or the
macro itself to make it work? Should I just keep it the way it is?
Cheers
Kai
Full output:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/pytest_django/plugin.py", line
170, in _handle_import_error
yield
File "/usr/lib/python3.9/site-packages/pytest_django/plugin.py", line
323, in pytest_load_initial_conftests
dj_settings.DATABASES
File "/usr/lib/python3.9/site-packages/django/conf/__init__.py", line
76, in __getattr__
self._setup(name)
File "/usr/lib/python3.9/site-packages/django/conf/__init__.py", line
63, in _setup
self._wrapped = Settings(settings_module)
File "/usr/lib/python3.9/site-packages/django/conf/__init__.py", line
142, in __init__
mod = importlib.import_module(self.SETTINGS_MODULE)
File "/usr/lib64/python3.9/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 972, in
_find_and_load_unlocked
File "", line 228, in
_call_with_frames_removed
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 972, in
_find_and_load_unlocked
File "", line 228, in
_call_with_frames_removed
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 984, in
_find_and_load_unlocked
ModuleNotFoundError: No module named 'tests'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/pytest", line 33, in
sys.exit(load_entry_point('pytest==6.0.2', 'console_scripts',
'pytest')())
File "/usr/lib/python3.9/site-packages/_pytest/config/__init__.py",
line 180, in console_main
code = main()
File "/usr/lib/python3.9/site-packages/_pytest/config/__init__.py",
line 136, in main
config = _prepareconfig(args, plugins)
File "/usr/lib/python3.9/site-packages/_pytest/config/__init__.py",
line 313, in _prepareconfig
config = pluginmanager.hook.pytest_cmdline_parse(
File "/usr/lib/python3.9/site-packages/pluggy/hooks.py", line 286, in
__call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
File "/usr/lib/python3.9/site-packages/pluggy/manager.py", line 93,
in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
File "/usr/lib/python3.9/site-packages/pluggy/manager.py", line 84,
in
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
File "/usr/lib/python3.9/site-packages/pluggy/callers.py", line 203,
in _multicall
gen.send(outcome)
File "/usr/lib/python3.9/site-packages/_pytest/helpconfig.py", line
99, in pytest_cmdline_parse
config = outcome.get_result() # type: Config
File "/usr/lib/python3.9/site-packages/pluggy/callers.py", line 80,
in get_result
raise ex[1].with_traceback(ex[2])
File "/usr/lib/python3.9/site-packages/pluggy/callers.py", line 187,
in _multicall
res = hook_impl.function(*args)
File "/usr/lib/python3.9/site-packages/_pytest/config/__init__.py",
line 932, in pytest_cmdline_parse
self.parse(args)
File "/usr/lib/python3.9/site-packages/_pytest/config/__init__.py",
line 1204, in parse
self._preparse(args, addopts=addopts)
File "/usr/lib/python3.9/site-packages/_pytest/config/__init__.py",
line 1107, in _preparse
self.hook.pytest_load_initial_conftests(
File "/usr/lib/python3.9/site-packages/pluggy/hooks.py", line 286, in
__call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
File "/usr/lib/python3.9/site-packages/pluggy/manager.py", line 93,
in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
File "/usr/lib/python3.9/site-packages/pluggy/manager.py", line 84,
in
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
File "/usr/lib/python3.9/site-packages/pluggy/callers.py", line 208,
in _multicall
return outcome.get_result()
File "/usr/lib/python3.9/site-packages/pluggy/callers.py", line 80,
in get_result
raise ex[1].with_traceback(ex[2])
File "/usr/lib/python3.9/site-packages/pluggy/callers.py", line 187,
in _multicall
res = hook_impl.function(*args)
File "/usr/lib/python3.9/site-packages/pytest_django/plugin.py",
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Wouldn't "rawhide" be more consistent with the other branch names? On Thu, 3 Dec 2020, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main == Summary == This Change will move Fedora git repositories to use "main" as the default git branch instead of "master". Specific repositories will be manually moved and default git branch for new projects will be set to use "main". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
hi, I see some pagure.io project are automatically handled by this change could teams register their repositories to be migrated automatically? if so, what's the deadline to ask for our repositories to be included in this change? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
At the moment this is their landing page: https://github.com/rocky-linux/organization/wiki/Contributing and they're working on a home page today for rockylinux.org. Dave On Wed, Dec 09, 2020 at 03:53:12PM +0100, Christopher Engelhard wrote: > On 09.12.20 15:20, Troy Dawson wrote: > > Does anyone know of a group that is going to start their own RHEL Clone? > > I'm sure the Scientific Linux people will do something, given that they > just recently decided to not release SL8 but rather use CentOS 8. I feel > quite bad for them, actually ... > > Some tentative work seem to be happening here: > https://github.com/hpcng/rocky > but it's early days obviously. They seem to be interested in > coordination with other attempts > (https://github.com/hpcng/rocky/issues/2 ), which is good. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020 at 11:21 AM Miro Hrončok wrote: > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > == How To Test == > > > > * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. > > What is the plan wrt Obsoletes of the removed packages? > > -- > Miro Hrončok > -- We do not plan on obsoleting them. Obsoleting them has the potential to break third party software. dnf should also clean things up by seeing that the dependencies of an upgraded package have gone away. If dnf misses it, these are libraries, not binaries. If nothing is using them, they just take up some disk space. If a user really wants to clean them up, those types of users usually have their favorite ways of doing so. Troy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Rawhide users: don't update to 20201208.n.0 packages (fprintd 1.90.6), console login and su are broken
On Wed, 2020-12-09 at 12:02 -0800, Adam Williamson wrote: > On Wed, 2020-12-09 at 10:34 -0800, Adam Williamson wrote: > > Hey folks! > > > > Just a heads up that the most recent Rawhide compose (20201208.n.0) > > seems badly broken; console login doesn't work and 'su' segfaults. I > > think the most likely cause of these issues is the new glibc 2.32.9000- > > 19.fc34 build. > > > > So if you're running Rawhide I'd recommend holding off on updating, and > > especially on updating glibc, if you didn't do it already. If you've > > updated glibc you may want to downgrade it (if you still have a root > > shell somewhere :>) > > Still looking into this, but it seems kinda complex. Downgrading glibc > on my test VM didn't fix the issues. I thought sssd might be the > culprit, but downgrading that didn't help either. > > It seems like the console login bug at least doesn't happen with a > minimal package install: > https://openqa.fedoraproject.org/tests/737305 > passed, including console login as user and root, and I verified that > it used the packages from the 1208.n.0 compose. But it seems to > reliably happen on Server, Workstation and KDE installs. So it's > apparently caused by something present in those installs but not in > minimal... > > Still looking into this, my advice for now is still not to upgrade past > the 1207.n.0 package state until it's figured out :) OK, further update: culprit seems to be fprintd. fprintd 1.90.6 is the bad version. A 1.90.7 build is done which should fix it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1656747 A libfprint 1.90.6 is also done, not sure if that's also needed: https://koji.fedoraproject.org/koji/buildinfo?buildID=1656771 There were bug reports already that I hadn't found as I was looking for glibc bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1905667 https://bugzilla.redhat.com/show_bug.cgi?id=1905964 so, skip fprintd 1.90.6! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: TBB soname bump
* Jerry James: > Greetings all, > > TBB 2021.1.1 is out, and comes with many improvements. It also comes > with an soname bump, so we will have to rebuild all consumers. I > believe the following is the list of packages to be rebuilt. > Hopefully my repoquery skills have been up to the task. Which parts changed soname? Only libtbb.so.12 (from libtbb.so.2)? Do you know why? Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020 at 11:52 AM James Cassell wrote: > > > > On Wed, Dec 9, 2020, at 1:44 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > == Summary == > > > > For Nodejs, Fedora should only package: > > * The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > * Packages that provide binaries that users would want to use in their > > shell. > > * compiled/binary nodejs modules (for now) > > > > Better title would have been, "bundle all nodejs dependencies into binary > packages requiring them". > Yes ... that does sound better. Naming is hard. > It feels contrary to the Minimization Objective. Is there really no better > solution? Can modularity help here? Better packaging macros? > To me this sounds exactly in line with the Minimization Objective. It can get rid of potentially 700 Fedora packages. Minimizing the number of packages needed to be installed as well as being built with. > Is there really no better solution? Not that we've found. This isn't an off the cuff proposal, it was months of discussion on mailling lists and off. To be honest, this is really years in the making. macros and scripts were tried for years, making them better and better in hopes that it would ease the problem. When things finally started falling apart, we really could say we'd tried all we could, but nothing was sustainable. > Can modularity help here? Better packaging macros? No, and No > How will licensing of dependencies be verified? Unlike most other languages, nodejs libraries contain a License field in their package.json. A simple 'find' script can get the licenses of your bundled packages. Run that each time you update your package, putting the output in your License: line of your spec. > What happens when a project adds new dependencies? Re-run your bundling script. You should re-run it every time you do any update, pulling in the correct and often updated nodejs libraries for your package. Troy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Failed to pair: org.bluez.Error.AuthenticationFailed
On Wednesday, December 9, 2020 3:40:47 AM WET Steve Dickson wrote: > Its a kernel problem... On the 5-9 kernel I tried > bluez-5.53, bluez-5.54, bluez-5.5 all failed > with Connection refused (111) > > Then I tried bluez-5.5 on the last 5.8 kernel > (5.8.18-300.fc33)... everything worked again > > steved. I will probably add this information to the bug report that you opened. I tried the last kernel from rawhide: 5.10.0-0.rc6.20201204git34816d20f173.92.fc34 And the problem still persists there. :-( -- José Abílio___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On 09/12/2020 20:55, Matthew Miller wrote: On Wed, Dec 09, 2020 at 08:46:39PM +0100, Jaroslav Prokop wrote: Looks like my use case should be included and hopefully with good options :). Although the way of communicating it feels a bit unfortunate. I would at least like to see what kind of initiatives are we talking about, what is in consideration. I know that centos-questi...@redhat.com is being answered by real people who are working on planning these programs, so sharing your needs with them can't hurt. Thanks! I'll do that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
EPEL 6 re-enabled, but... Re: Fedora 31 and EPEL 6 is EOL in Fedora Copr
After feedback from several users still doing _development_ against EL6, we decided to re-enable epel-6 build chroots temporarily (probably till the end of ELS of RHEL 6, but without promises). CentOS 6 repos are not mirrored anymore, so the builds are now done against the repos on https://vault.centos.org/ server (this is first time experience, so we don't know the stability or throughput). WARNING: It is very unlikely you want to waste your time and Copr resources (computational power but especially storage) with epel-6, so we'd still like to appeal to you to _disable_ epel-6 chroots in your projects. Pavel On Thursday, December 3, 2020 11:56:32 AM CET Pavel Raiskup wrote: > The Fedora 31 and EPEL 6 chroots are marked as EOL in Copr now (for the epel > case, it's not even easily possible to build there nowadays because CentOS > already stopped mirroring of the repos). > > There's additional 180 days period when we keep the build results. If you > want > to keep the results longer than that, don't forget to periodically check your > EOLed chroots: https://copr.fedorainfracloud.org/user/repositories/ > > Copr Team > > > ___ > copr-devel mailing list -- copr-de...@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Rawhide users: don't update to 20201208.n.0 packages (likely glibc), console login and su are broken
On Wed, 2020-12-09 at 10:34 -0800, Adam Williamson wrote: > Hey folks! > > Just a heads up that the most recent Rawhide compose (20201208.n.0) > seems badly broken; console login doesn't work and 'su' segfaults. I > think the most likely cause of these issues is the new glibc 2.32.9000- > 19.fc34 build. > > So if you're running Rawhide I'd recommend holding off on updating, and > especially on updating glibc, if you didn't do it already. If you've > updated glibc you may want to downgrade it (if you still have a root > shell somewhere :>) Still looking into this, but it seems kinda complex. Downgrading glibc on my test VM didn't fix the issues. I thought sssd might be the culprit, but downgrading that didn't help either. It seems like the console login bug at least doesn't happen with a minimal package install: https://openqa.fedoraproject.org/tests/737305 passed, including console login as user and root, and I verified that it used the packages from the 1208.n.0 compose. But it seems to reliably happen on Server, Workstation and KDE installs. So it's apparently caused by something present in those installs but not in minimal... Still looking into this, my advice for now is still not to upgrade past the 1207.n.0 package state until it's figured out :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 09, 2020 at 08:46:39PM +0100, Jaroslav Prokop wrote: > Looks like my use case should be included and hopefully with good > options :). > > Although the way of communicating it feels a bit unfortunate. > I would at least like to see what kind of initiatives are we talking > about, what is in consideration. I know that centos-questi...@redhat.com is being answered by real people who are working on planning these programs, so sharing your needs with them can't hurt. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1906052] Please build perl-Eval-WithLexicals for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1906052 Jitka Plesnikova changed: What|Removed |Added Doc Type|--- |If docs needed, set a value --- Comment #1 from Jitka Plesnikova --- https://pagure.io/releng/fedora-scm-requests/issue/31283 https://pagure.io/releng/fedora-scm-requests/issue/31284 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020, at 1:44 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > == Summary == > > For Nodejs, Fedora should only package: > * The interpreter, development headers/libraries, and the assorted > tools to manage project-level installations (NPM, yarn, etc.). > * Packages that provide binaries that users would want to use in their shell. > * compiled/binary nodejs modules (for now) > Better title would have been, "bundle all nodejs dependencies into binary packages requiring them". It feels contrary to the Minimization Objective. Is there really no better solution? Can modularity help here? Better packaging macros? How will licensing of dependencies be verified? What happens when a project adds new dependencies? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On 09/12/2020 20:24, Matthew Miller wrote: On Wed, Dec 09, 2020 at 02:07:01PM +0100, Jaroslav Prokop wrote: It would provide with what is lost with CentOS Linux. Let's entertain an example: I would like to setup a home server with some locally hosted services, but I wouldn't like to update it to new system with new software every year just to get security updates. [...] "pioneer" of new releases, I feel that then I would miss a production ready, free and long term supported system from the ecosystem of RHEL/Fedora. But apparently some already took Take a look at this part of the CentOS FAQ: "In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available." https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 Those details really have not been worked out, but I expect your use to be one that's definitely thought of. Thank you for responding! Looks like my use case should be included and hopefully with good options :). Although the way of communicating it feels a bit unfortunate. I would at least like to see what kind of initiatives are we talking about, what is in consideration. Jarek. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 09, 2020 at 02:07:01PM +0100, Jaroslav Prokop wrote: > It would provide with what is lost with CentOS Linux. > Let's entertain an example: > I would like to setup a home server with some locally hosted > services, but I wouldn't like to update it to new system with new > software every year just to get security updates. [...] > "pioneer" of new releases, I feel that then I would miss a > production ready, free and long term supported system > from the ecosystem of RHEL/Fedora. But apparently some already took Take a look at this part of the CentOS FAQ: "In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available." https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 Those details really have not been worked out, but I expect your use to be one that's definitely thought of. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 09, 2020 at 12:26:18AM -0300, Sergio Belkin wrote: > How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) > affect Fedora? I wrote a blog post about this last September and I think it's all still very true: https://fedoramagazine.org/fedora-and-centos-stream/ -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Packaging a go application
On 12/8/20 8:20 AM, Robin Opletal wrote:
Hi,
As I have said earlier, I am trying to package aerc, the mail client,
for Fedora. What didn't cross my mind is that internet access will be
limited during the build, thus the automatic dependency resolution
from the Makefile during the build stage of aerc doesn't work.
I was wondering what the best way would be to get this into
BuildRequires.
My current .spec - https://pastebin.com/HZsuPXds
The project uses go.mod
(https://git.sr.ht/~sircmpwn/aerc/tree/master/go.mod) with quite a few
dependencies, most of them not available in the official repositories as
packages.
As far as I understand, that gives me two options:
1) Bundle the dependencies as a package for each release of aerc based
on aerc's go.mod
2) Package a go application according to the official Go packaging
guidelines (from here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_dependencies)
I have attempted this, generating the deps with golist as described and
adding those as BuildRequires, but the builds then failed with
error: Failed build dependencies:
golang(github.com/creack/pty) is needed by
aerc-0.5.2-4.fc33.x86_64
I have tried looking at the spec file of kubectl for reference, but I
am not sure which all macros are required to make BuildRequires:
golang() work.
Thanks for any pointers!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
This gonna be tricky because of the Makefile we can't use because we do
not support Go modules yet. And git.sr.ht is not a supported repo home.
First you should use go2rpm to get the basic structure of your SPEC:
go2rpm --stdout git.sr.ht/~sircmpwn/aerc -f https://git.sr.ht/~sircmpwn/aerc
Here's one modified to work with Drew's Makefile while keeping Fedora's
flags for the binary compilation, and the handling git.sr.ht:
# Generated by go2rpm 1.3
%bcond_without check
# https://git.sr.ht/~sircmpwn/aerc
%global goipath git.sr.ht/~sircmpwn/aerc
%global forgeurlhttps://git.sr.ht/~sircmpwn/aerc
Version:0.5.2
%global tag 0.5.2
# /!\ Prerelease to fix compilation with go-pgpmail
%global commit b56a688589c946ff8224f3d9e2e73de2edbc39b4
%global repoaerc
%global archivename %{repo}-%{commit}
%global archiveext tar.gz
%global archiveurl %{forgeurl}/archive/%{commit}.%{archiveext}
%global topdir %{repo}-%{commit}
%global extractdir %{repo}-%{commit}
%global scm git
%gometa
%global common_description %{expand:
Aerc is an email client that runs in your terminal. It's highly
efficient and extensible, perfect for the discerning hacker.}
%global golicenses LICENSE
%global godocs doc README.md
Name: aerc
Release:1%{?dist}
Summary:Email client for your terminal
License:MIT
URL:%{gourl}
Source0:%{gosource}
# Disable building of aerc that we handle manually in the SPEC
Patch0: aerc-fix-makefile.patch
BuildRequires: scdoc
BuildRequires: golang(git.sr.ht/~sircmpwn/getopt)
BuildRequires: golang(git.sr.ht/~sircmpwn/tcell)
BuildRequires: golang(git.sr.ht/~sircmpwn/tcell/views)
BuildRequires: golang(github.com/brunnre8/go.notmuch)
BuildRequires: golang(github.com/creack/pty)
BuildRequires: golang(github.com/danwakefield/fnmatch)
BuildRequires: golang(github.com/ddevault/go-libvterm)
BuildRequires: golang(github.com/emersion/go-imap)
BuildRequires: golang(github.com/emersion/go-imap-idle)
BuildRequires: golang(github.com/emersion/go-imap-sortthread)
BuildRequires: golang(github.com/emersion/go-imap/client)
BuildRequires: golang(github.com/emersion/go-maildir)
BuildRequires: golang(github.com/emersion/go-message)
BuildRequires: golang(github.com/emersion/go-message/charset)
BuildRequires: golang(github.com/emersion/go-message/mail)
BuildRequires: golang(github.com/emersion/go-message/textproto)
BuildRequires: golang(github.com/emersion/go-pgpmail)
BuildRequires: golang(github.com/emersion/go-sasl)
BuildRequires: golang(github.com/emersion/go-smtp)
BuildRequires: golang(github.com/fsnotify/fsnotify)
BuildRequires: golang(github.com/go-ini/ini)
BuildRequires: golang(github.com/google/shlex)
BuildRequires: golang(github.com/imdario/mergo)
BuildRequires: golang(github.com/kyoh86/xdg)
BuildRequires: golang(github.com/mattn/go-isatty)
BuildRequires: golang(github.com/mattn/go-runewidth)
BuildRequires: golang(github.com/miolini/datacounter)
BuildRequires: golang(github.com/mitchellh/go-homedir)
BuildRequires: golang(github.com/pkg/errors)
BuildRequires:
TBB soname bump
Greetings all, TBB 2021.1.1 is out, and comes with many improvements. It also comes with an soname bump, so we will have to rebuild all consumers. I believe the following is the list of packages to be rebuilt. Hopefully my repoquery skills have been up to the task. By package, with maintainers: - blender: luya, design-sw, hobbes1069, ignatenkobrain, kwizart, roma, s4504kr, slaanesh - bowtie2: jaruga - cryptominisat: jjames - dyninst: scox, fche, jistone, lberk, orion, wcohen - embree: luya, slaanesh - fawkes: thofmann, rmattes, timn - gazebo: rmattes, @robotics-sig - luxcorerender: luya, kwizart, besser82, slaanesh - mathicgb: jjames - oidn: luya, slaanesh, design-sw - opencascade: hobbes1069 - opencv: kwizart, jridky, sergiomb, jkucera, vjancik, hhorak, jmlich, hguemar - OpenImageIO: hobbes1069 - opensubdiv: luya - openvdb: slaanesh, luya - pmemkv: kilobyte - prusa-slicer: tibbs, churchyard - root: ellert - suitesparse: jkastner, deji, mjakubicek, nphilipp, orion, dkaspar I will do test mock builds prior to building in Rawhide to hopefully catch any breakage. Sadly, I can't seem to do that today. See Adam's email about segfaults in Rawhide. As soon as that is cleared up, I will start doing test builds. I hope that sometime next week we can do these builds for real. Please let me know if you prefer to build your own package, otherwise I can do it for you. Also let me know of any scheduling constraints so I can stay out of your way if you've got a complicated update coming up. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On 12/9/20 7:44 PM, Ben Cotton wrote: == How To Test == * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. What is the plan wrt Obsoletes of the removed packages? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault == Summary == For Nodejs, Fedora should only package: * The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.). * Packages that provide binaries that users would want to use in their shell. * compiled/binary nodejs modules (for now) == Owner == * Name: [[User:tdawson| Troy Dawson]] * Email: tdaw...@redhat.com * Name: [[User:sgallagh| Stephen Gallagher]] * Email: sgall...@redhat.com * Name: [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] * Email: nod...@lists.fedoraproject.org == Detailed Description == The nodejs libraries have been approved to be bundled, and there is infrastructure in place for the bundling to work properly. Currently, it is recommended that packagers should create individual nodejs library packages instead of bundling all of the libraries into the package requiring them. This change is to make it default to bundle the nodejs libraries with the package that needs them, and retire the vast majority of nodejs library packages. In summary, for Nodejs Fedora should only package: * The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.). * Packages that provide binaries that users would want to use in their shell. * compiled/binary nodejs modules (for now) == Feedback == There has been a discussion on the fedora nodejs mailing list about what to do with the extreme dependency problem of the nodejs library packages. Because of the extreme inter-dependency, upgrading almost any package causes others to break. It has caused most packages to rot, remaining on unsupported versions for years. Many of the nodejs packagers are giving up and orphaning their packages, which has caused even more problems. An initial proposal was to find all of the important nodejs library packages and bundle those, making them easier to upgrade and maintain. But there was problems with figuring out what was important, and what versions should those have. During that discussion, this rather extreme solution of getting rid of all nodejs libraries was proposed. To our surprise, it has been the best received suggestion and fixes the most problems. == Benefit to Fedora == * In Fedora 33, there are many nodejs libraries that are uninstallable, thus causing other programs based off them to also be uninstallable. This gets rid of that problem. * Packages in Fedora that use nodejs libraries will be able to use the library versions that upstream has tested and approved. * If a package in Fedora uses a nodejs library, the packager will not have to also package extra individual nodejs library packages. There have been times this has led to over 100 extra packages, each with their own package reviews and maintenance problems. This change will lower the workload on that packager, and possibly get more packages into Fedora. * The nodejs maintainers can concentrate on nodejs itself, instead of the whole nodejs library infrastructure. * Nodejs developers using Fedora will no longer have to worry about Fedora's global nodejs libraries causing conflicts or inconsistencies. == Scope == * Proposal owners: We will go through the Fedora release and determine what nodejs packages Fedora should package. We will implement nodejs library bundling on those we already own. For those that we do not own, we will work with their owners to implement nodejs library bundling. As packages implement nodejs library bundling, we will monitor the nodejs libraries and note which ones are no longer required. When they are no longer required, we will retire them, if we own them. If we do not own them, we will work with the owners to retire them, if they wish. * Other developers: For Fedora packagers whose package rely on nodejs libraries, please contact the [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] and we will help you find the easiest way to bundle your nodejs libraries. For Fedora nodejs library packages, look to see what depends on your library. If it looks like you can do so, retire your nodejs library. If you would like, give the [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] admin to your nodejs libraries, and they will work through the process for you. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == N/A == How To Test == * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. * Try to install all packages that require nodejs in Fedora 34. * Install all packages that require nodejs in Fedora 33. Try to update to Fedora
Fedora 34 Change: Binutils 2.36 (System-Wide Change)
https://fedoraproject.org/wiki/Changes/BINUTILS236
== Summary ==
Rebase the binutils package from version 2.35.1 to version 2.36.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com
== Detailed Description ==
Switch the binutils package from being based on the 2.35.1 release of
the GNU binutils to
being based on the 2.36 release. This release will bring in numerous
bug fixes, as well
as support for new x86 and ARM architecture extensions.
== Benefit to Fedora ==
The main benefit will be the bug fixes and the improvements to the
linker and assembler. Whilst invisible to ordinary users these
changes will benefit package maintainers and application developers.
== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
This is a significant change to the underlying tools used to build
Fedora and so there should be a mass rebuild in order for the changes
to be noticed across the system.
* Other developers: None
* Release engineering: https://pagure.io/releng/issue/9898
A mass rebuilt will be required.
* Policies and guidelines: No documents need to be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
The rebase of the binutils will bring with it improved support for
smaller architectures (eg ARM, RISC-V, MIPS) which in turn will align
with the Fedora Internet of Things objective.
== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no
changes should be necessary.
== How To Test ==
The binutils package does include its own set of testsuites which
check basic functionality.
The real test however is by rebuilding other packages which depend
upon the binutils, or
more likely, upon gcc. If these packages continue to work then the
binutils update has not
broken anything.
== User Experience ==
The change should not be noticeable to the user.
== Dependencies ==
This update has no hard dependencies on any other package.
There are other packages that do depend upon the binutils however.
Most notably gcc and redhat-rpm-config.
== Contingency Plan ==
* Contingency mechanism:
Revert to the 2.35.1 binutils as currently used in rawhide. This work
can be done by me, should it prove necessary.
* Contingency deadline: Beta freeze.
* Blocks release? No
* Blocks product? None
== Documentation ==
This rebase brings with it many bug fixes, plus the following notable
new features:
New features in the Assembler:
General:
* When setting the link order attribute of ELF sections, it is now
possible to use a numeric section index instead of symbol name.
* Added a .nop directive to generate a single no-op instruction in
a target neutral manner. This instruction does have an effect on
DWARF line number generation, if that is active.
* Removed --reduce-memory-overheads and --hash-size as gas now
uses hash tables that can be expand and shrink automatically.
X86/x86_64:
* Add support for AVX VNNI, HRESET, UINTR, TDX, AMX and Key
Locker instructions.
* Support non-absolute segment values for lcall and ljmp.
* Add {disp16} pseudo prefix to x86 assembler.
* Configure with --enable-x86-used-note by default for Linux/x86.
ARM/AArch64:
* Add support for Cortex-A78, Cortex-A78AE and Cortex-X1,
Cortex-R82, Neoverse V1, and Neoverse N2 cores.
* Add support for ETMv4 (Embedded Trace Macrocell), ETE (Embedded
Trace Extension), TRBE (Trace Buffer Extension), CSRE (Call
Stack Recorder Extension) and BRBE (Branch Record Buffer
Extension) system registers.
* Add support for Armv8-R and Armv8.7-A ISA extensions.
* Add support for DSB memory nXS barrier, WFET and WFIT
instruction for Armv8.7.
* Add support for +csre feature for -march. Add CSR PDEC
instruction for CSRE feature in AArch64.
* Add support for +flagm feature for -march in Armv8.4 AArch64.
* Add support for +ls64 feature for -march in Armv8.7
AArch64. Add atomic 64-byte load/store instructions for this
feature.
* Add support for +pauth (Pointer Authentication) feature for
-march in AArch64.
New features in the Linker:
* Add --error-handling-script= command line option to allow
a helper script to be invoked when an undefined symbol or a
missing library is encountered. This option can be suppressed
via the configure time switch: --enable-error-handling-script=no.
* Add -z x86-64-{baseline|v[234]} to the x86 ELF linker to mark
x86-64-{baseline|v[234]} ISA level as needed.
* Add -z unique-symbol to avoid duplicated local symbol names.
* The creation of PE format DLLs now defaults to using a more
secure set of DLL
Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault == Summary == For Nodejs, Fedora should only package: * The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.). * Packages that provide binaries that users would want to use in their shell. * compiled/binary nodejs modules (for now) == Owner == * Name: [[User:tdawson| Troy Dawson]] * Email: tdaw...@redhat.com * Name: [[User:sgallagh| Stephen Gallagher]] * Email: sgall...@redhat.com * Name: [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] * Email: nod...@lists.fedoraproject.org == Detailed Description == The nodejs libraries have been approved to be bundled, and there is infrastructure in place for the bundling to work properly. Currently, it is recommended that packagers should create individual nodejs library packages instead of bundling all of the libraries into the package requiring them. This change is to make it default to bundle the nodejs libraries with the package that needs them, and retire the vast majority of nodejs library packages. In summary, for Nodejs Fedora should only package: * The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.). * Packages that provide binaries that users would want to use in their shell. * compiled/binary nodejs modules (for now) == Feedback == There has been a discussion on the fedora nodejs mailing list about what to do with the extreme dependency problem of the nodejs library packages. Because of the extreme inter-dependency, upgrading almost any package causes others to break. It has caused most packages to rot, remaining on unsupported versions for years. Many of the nodejs packagers are giving up and orphaning their packages, which has caused even more problems. An initial proposal was to find all of the important nodejs library packages and bundle those, making them easier to upgrade and maintain. But there was problems with figuring out what was important, and what versions should those have. During that discussion, this rather extreme solution of getting rid of all nodejs libraries was proposed. To our surprise, it has been the best received suggestion and fixes the most problems. == Benefit to Fedora == * In Fedora 33, there are many nodejs libraries that are uninstallable, thus causing other programs based off them to also be uninstallable. This gets rid of that problem. * Packages in Fedora that use nodejs libraries will be able to use the library versions that upstream has tested and approved. * If a package in Fedora uses a nodejs library, the packager will not have to also package extra individual nodejs library packages. There have been times this has led to over 100 extra packages, each with their own package reviews and maintenance problems. This change will lower the workload on that packager, and possibly get more packages into Fedora. * The nodejs maintainers can concentrate on nodejs itself, instead of the whole nodejs library infrastructure. * Nodejs developers using Fedora will no longer have to worry about Fedora's global nodejs libraries causing conflicts or inconsistencies. == Scope == * Proposal owners: We will go through the Fedora release and determine what nodejs packages Fedora should package. We will implement nodejs library bundling on those we already own. For those that we do not own, we will work with their owners to implement nodejs library bundling. As packages implement nodejs library bundling, we will monitor the nodejs libraries and note which ones are no longer required. When they are no longer required, we will retire them, if we own them. If we do not own them, we will work with the owners to retire them, if they wish. * Other developers: For Fedora packagers whose package rely on nodejs libraries, please contact the [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] and we will help you find the easiest way to bundle your nodejs libraries. For Fedora nodejs library packages, look to see what depends on your library. If it looks like you can do so, retire your nodejs library. If you would like, give the [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] admin to your nodejs libraries, and they will work through the process for you. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == N/A == How To Test == * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. * Try to install all packages that require nodejs in Fedora 34. * Install all packages that require nodejs in Fedora 33. Try to update to Fedora
Fedora 34 Change: Binutils 2.36 (System-Wide Change)
https://fedoraproject.org/wiki/Changes/BINUTILS236
== Summary ==
Rebase the binutils package from version 2.35.1 to version 2.36.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com
== Detailed Description ==
Switch the binutils package from being based on the 2.35.1 release of
the GNU binutils to
being based on the 2.36 release. This release will bring in numerous
bug fixes, as well
as support for new x86 and ARM architecture extensions.
== Benefit to Fedora ==
The main benefit will be the bug fixes and the improvements to the
linker and assembler. Whilst invisible to ordinary users these
changes will benefit package maintainers and application developers.
== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
This is a significant change to the underlying tools used to build
Fedora and so there should be a mass rebuild in order for the changes
to be noticed across the system.
* Other developers: None
* Release engineering: https://pagure.io/releng/issue/9898
A mass rebuilt will be required.
* Policies and guidelines: No documents need to be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
The rebase of the binutils will bring with it improved support for
smaller architectures (eg ARM, RISC-V, MIPS) which in turn will align
with the Fedora Internet of Things objective.
== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no
changes should be necessary.
== How To Test ==
The binutils package does include its own set of testsuites which
check basic functionality.
The real test however is by rebuilding other packages which depend
upon the binutils, or
more likely, upon gcc. If these packages continue to work then the
binutils update has not
broken anything.
== User Experience ==
The change should not be noticeable to the user.
== Dependencies ==
This update has no hard dependencies on any other package.
There are other packages that do depend upon the binutils however.
Most notably gcc and redhat-rpm-config.
== Contingency Plan ==
* Contingency mechanism:
Revert to the 2.35.1 binutils as currently used in rawhide. This work
can be done by me, should it prove necessary.
* Contingency deadline: Beta freeze.
* Blocks release? No
* Blocks product? None
== Documentation ==
This rebase brings with it many bug fixes, plus the following notable
new features:
New features in the Assembler:
General:
* When setting the link order attribute of ELF sections, it is now
possible to use a numeric section index instead of symbol name.
* Added a .nop directive to generate a single no-op instruction in
a target neutral manner. This instruction does have an effect on
DWARF line number generation, if that is active.
* Removed --reduce-memory-overheads and --hash-size as gas now
uses hash tables that can be expand and shrink automatically.
X86/x86_64:
* Add support for AVX VNNI, HRESET, UINTR, TDX, AMX and Key
Locker instructions.
* Support non-absolute segment values for lcall and ljmp.
* Add {disp16} pseudo prefix to x86 assembler.
* Configure with --enable-x86-used-note by default for Linux/x86.
ARM/AArch64:
* Add support for Cortex-A78, Cortex-A78AE and Cortex-X1,
Cortex-R82, Neoverse V1, and Neoverse N2 cores.
* Add support for ETMv4 (Embedded Trace Macrocell), ETE (Embedded
Trace Extension), TRBE (Trace Buffer Extension), CSRE (Call
Stack Recorder Extension) and BRBE (Branch Record Buffer
Extension) system registers.
* Add support for Armv8-R and Armv8.7-A ISA extensions.
* Add support for DSB memory nXS barrier, WFET and WFIT
instruction for Armv8.7.
* Add support for +csre feature for -march. Add CSR PDEC
instruction for CSRE feature in AArch64.
* Add support for +flagm feature for -march in Armv8.4 AArch64.
* Add support for +ls64 feature for -march in Armv8.7
AArch64. Add atomic 64-byte load/store instructions for this
feature.
* Add support for +pauth (Pointer Authentication) feature for
-march in AArch64.
New features in the Linker:
* Add --error-handling-script= command line option to allow
a helper script to be invoked when an undefined symbol or a
missing library is encountered. This option can be suppressed
via the configure time switch: --enable-error-handling-script=no.
* Add -z x86-64-{baseline|v[234]} to the x86 ELF linker to mark
x86-64-{baseline|v[234]} ISA level as needed.
* Add -z unique-symbol to avoid duplicated local symbol names.
* The creation of PE format DLLs now defaults to using a more
secure set of DLL
Re: End of CentOS Linux: What about Fedora?
Hello! On 09.12.20 18:08, Gary Buhrmaster wrote: For those that want the equivalent of a point release, I would think they should be able to write an ansible script to upgrade to the point release of packages that EL 8.x ship with. Just had the same idea. ;-) So if I only upgrade to the point releases, I have more or less a EL system. For me this is a sufficient replacement for CentOS. Best Regards Christoph ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Rawhide users: don't update to 20201208.n.0 packages (likely glibc), console login and su are broken
Hey folks! Just a heads up that the most recent Rawhide compose (20201208.n.0) seems badly broken; console login doesn't work and 'su' segfaults. I think the most likely cause of these issues is the new glibc 2.32.9000- 19.fc34 build. So if you're running Rawhide I'd recommend holding off on updating, and especially on updating glibc, if you didn't do it already. If you've updated glibc you may want to downgrade it (if you still have a root shell somewhere :>) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On 12/9/20 12:33 PM, Jaroslav Prokop wrote: Hello, On 09/12/2020 12:12, Christoph Karl wrote: Hello! On 09.12.20 04:26, Sergio Belkin wrote: How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) affect Fedora? I think Fedora now needs some kind of LTS. At least I was planning to support CentOS via EPEL as a kind of "Fedora LTS". If I remember correctly and not making it up there was a discussion some years back about Fedora LTS. Where does the fairy tale of CentOS being a "Fedora LTS" come from? Fedora and CentOS address completely different audiences and provide completely different packages and "features". I am starting to get really confused on Fedora's position here. So am I. Actually I do not see any common ground for Fedora and CentOS. Are we anywhere in the pipeline? Actually, I do not care. I support Fedora, RHEL is RHAT's business and so is its puppet/clone CentOS. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: main vs master: no more localization :(
Hi Jean-Baptiste, On 12/8/20 6:06 PM, Jean-Baptiste wrote: > > Hello, > > our localization system, for every single doc component is broken. > > The reason is the change of branch from "master" to "main". > I do not understand how this happened. Only a handful of Fedora Docs repos have switched from `master` to `main`. Did the changing of a few repos have an impact on the translations build script? If so, which repos specifically caused localization to break? > the question I have: how could we have better testing of changes? > > > Thanks for your understanding, > I am still confused how it happened. If any docs repo can break the localization tooling by changing the default branch, this seems like a bug with the tooling. Right now, no mass branch renames have happened yet, although this is planned in the near future: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main -- Cheers, Justin W. Flory (he/him) https://jwf.io TZ=America/New_York publickey - foss@jwf.io - 570e854f.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] Re: plasma desktop not starting on CentOS 8.3
I just tested on my laptop running CentOS 8. Updated to 8.3 and both X and KDE started up with no problems. Do you have something special like an nvidia card with drivers? On Wed, Dec 9, 2020 at 8:29 AM Orion Poplawski wrote: > > After updating to CentOS 8.3, my plasma (KDE) desktop is not starting. It > seems like X is not starting. Is anyone else seeing this and knows what's > happening? I haven't had a chance to dig much deeper myself yet... > > Orion > > -- > Orion Poplawski > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 9, 2020 at 4:52 PM Adam Williamson wrote: > For some folks / maintenance styles this might still be an issue, but > it should work OK in quite a lot of cases. It's not like you're running > Rawhide. For those that want the equivalent of a point release, I would think they should be able to write an ansible script to upgrade to the point release of packages that EL 8.x ship with. A little more work (for someone) to maintain, but I would not be surprised if someone (or a community) decided to take it one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On Wed, Dec 09, 2020 at 11:17:46AM +0100, Miro Hrončok wrote: > Hello, > > wrt https://blog.centos.org/2020/12/future-is-centos-stream/ > > Since EPEL 8 is for RHEL 8 and EPEL Next 8 is for CentOS Stream 8, I assumed > we will continue to use CentOS Linux 8 for local mock (and Copr) builds of > EPEL 8 packages. The same for EPEL 9. > > However, since CentOS Linux 8 (and 9!) will be no more, do we have some > ideas how to handle this? Do we require all EPEL contributors to obtain the > developer RHEL subscription (seems like a huge pain)? Do we switch to Oracle > Linux (only half joking)? Do we try to fight this decision (however I am > afraid I've exhausted my fight capacity on different decisions)? > > Not looking for specific answers yet, this is more a discussion kick off. I guess this is a decision for the mock/copr maintainers in the end? but yeah, not sure what the best way is. We do have some time... kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, 2020-12-09 at 14:07 +0100, Jaroslav Prokop wrote: > > If I understood the announcement, it would be a kind of CentOS streams > is rolling release or a release with short > release interval. That does not make my job much easier as someone who > just sets up services and leaves it running. It's a rolling release *of a stable RHEL branch*. You're not getting radical new changes if you run CentOS Stream; you're just getting the changes you'd usually get in RHEL stable point releases (e.g. 8.1, 8.2 etc) but getting them early and as they are produced, rather than in periodic lumps). For some folks / maintenance styles this might still be an issue, but it should work OK in quite a lot of cases. It's not like you're running Rawhide. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] plasma desktop not starting on CentOS 8.3
After updating to CentOS 8.3, my plasma (KDE) desktop is not starting. It seems like X is not starting. Is anyone else seeing this and knows what's happening? I haven't had a chance to dig much deeper myself yet... Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
[389-devel] please review: PR 4485 - heap-use-after-free in disk monitoring
https://github.com/389ds/389-ds-base/pull/4485 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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/389-devel@lists.fedoraproject.org
Re: f33: systemd-resolved hang on ip query
On Tue, Dec 8, 2020 at 8:34 PM Marius Schwarz wrote: > > Am 08.12.20 um 19:32 schrieb Dridi Boukelmoune: > > > >> Petr was so nice to supply a test procedure, i suggest that you use it > >> also. > > I'll try to strace stuff to to see what's going on, but I can only > > assume that this BZ is not trying to resolve ip addresses through > > systemd-resolved. > > > > > > No, they didn't . An pretimed bind-libs update, caused apps not to be > able to resolve hostnames . they crashed. > All tools which did it themself, worked "in a way". they first tried > local resolving with /etc/hosts, thats where libc crashed, which took time, > and then used root dns to do theire jobs. > > It could have the same underlying issue: not matching sys libs. I > suggest to update them. Actually, it looks like this is happening for all NXDOMAIN replies. $ dig @1.1.1.1 com.example | grep -e SERVER -e HEADER ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29880 ;; SERVER: 1.1.1.1#53(1.1.1.1) $ dig +timeout=1 com.example ; <<>> DiG 9.11.25-RedHat-9.11.25-2.fc33 <<>> +timeout=1 com.example ;; global options: +cmd ;; connection timed out; no servers could be reached A quick search for systemd-resolved nxdomain yields many results with a syslog I do not see on my system: > Server returned error NXDOMAIN, mitigating potential DNS violation > DVE-2018-0001 So it looks like my initial intuition that there could be a mitigation of sorts is starting to hold water. The problem now is that clients on my system using getaddrinfo in a way that was legit until now are now being DoS'd by systemd-resolved, waiting forever for a reply that is not coming. I wouldn't mind the mitigation, if only I could disable it. Does anyone know any better? I'm still suspecting I configured something wrong but at the same time systemd seems to have a history with NXDOMAIN handling. Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1906052] Please build perl-Eval-WithLexicals for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1906052 Steve Traylen changed: What|Removed |Added Blocks||1900710 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1900710 [Bug 1900710] RFE - build perl-Object-Remote for epel 8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1900710] RFE - build perl-Object-Remote for epel 8
https://bugzilla.redhat.com/show_bug.cgi?id=1900710 Steve Traylen changed: What|Removed |Added Depends On||1906052 --- Comment #4 from Steve Traylen --- Blocked on 1906052 now which reading above must be a new dependency as was apparenty not present last time I looked at this. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1906052 [Bug 1906052] Please build perl-Eval-WithLexicals for EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1906052] New: Please build perl-Eval-WithLexicals for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1906052 Bug ID: 1906052 Summary: Please build perl-Eval-WithLexicals for EPEL8 Product: Fedora Version: rawhide Status: NEW Component: perl-Eval-WithLexicals Assignee: jples...@redhat.com Reporter: steve.tray...@cern.ch QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Please could a build of perl-Eval-WithLexicals be built for EPEL8. I verified the current HEAD package is both buildable and installable for EPEL8. This would unstick. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3be8d97b7b many thanks. Steve. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
>> Maybe provide a rolling release fedora as well (which is >> suitable for non-debug systems). > > > https://fedoraproject.org/wiki/RawhideKernelNodebug > > -Jared Thanks, I thought to recall that it's not just the kernel. Also mentioned in the wiki link is that it doesn't work with secureboot. I was hoping for something can take it up with opensuse tumbleweed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[389-devel] please review: PR 4484 - Remove DES to AES conversion code
https://github.com/389ds/389-ds-base/pull/4484 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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/389-devel@lists.fedoraproject.org
[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On 09.12.20 15:20, Troy Dawson wrote: > Does anyone know of a group that is going to start their own RHEL Clone? I'm sure the Scientific Linux people will do something, given that they just recently decided to not release SL8 but rather use CentOS 8. I feel quite bad for them, actually ... Some tentative work seem to be happening here: https://github.com/hpcng/rocky but it's early days obviously. They seem to be interested in coordination with other attempts (https://github.com/hpcng/rocky/issues/2), which is good. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: python-testresources version weirdness...
On Wed, 9 Dec 2020, Scott Talbert wrote: I'm working on test builds of OpenColorIO 2.0 in a COPR[1] and one of the requirements to build the documentation is python-testresources. The problem is it's looking for version 2.0+ but only 1.0 is in Fedora[2]. But I can't even find where that exists as a release! More strangely, when you go to the PyPi page[3] it does show the current version is 2.0.1, but when you go to the testresources homepage on launchpad[4], the latest is 0.2.4 released in 2010. Is PyPi correct that 2.0.x exists? Who's lying? PyPi is probably correct. Looks like they just stopped putting release tarballs on Launchpad. You can see (somewhat recent) development in their VCS on Launchpad. See also: https://src.fedoraproject.org/rpms/python-testresources/pull-request/2 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@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/python-devel@lists.fedoraproject.org
Re: python-testresources version weirdness...
On Wed, 9 Dec 2020, Richard Shaw wrote: I'm working on test builds of OpenColorIO 2.0 in a COPR[1] and one of the requirements to build the documentation is python-testresources. The problem is it's looking for version 2.0+ but only 1.0 is in Fedora[2]. But I can't even find where that exists as a release! More strangely, when you go to the PyPi page[3] it does show the current version is 2.0.1, but when you go to the testresources homepage on launchpad[4], the latest is 0.2.4 released in 2010. Is PyPi correct that 2.0.x exists? Who's lying? PyPi is probably correct. Looks like they just stopped putting release tarballs on Launchpad. You can see (somewhat recent) development in their VCS on Launchpad. Scott ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@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/python-devel@lists.fedoraproject.org
[389-devel] please review: PR 4482 - Unable to build with Rust-enabled in a closed environment
https://github.com/389ds/389-ds-base/pull/4482 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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/389-devel@lists.fedoraproject.org
[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On Wed, Dec 9, 2020 at 2:19 AM Miro Hrončok wrote: > > Hello, > > wrt https://blog.centos.org/2020/12/future-is-centos-stream/ > > Since EPEL 8 is for RHEL 8 and EPEL Next 8 is for CentOS Stream 8, I assumed > we > will continue to use CentOS Linux 8 for local mock (and Copr) builds of EPEL 8 > packages. The same for EPEL 9. > > However, since CentOS Linux 8 (and 9!) will be no more, do we have some ideas > how to handle this? Do we require all EPEL contributors to obtain the > developer > RHEL subscription (seems like a huge pain)? Do we switch to Oracle Linux (only > half joking)? Do we try to fight this decision (however I am afraid I've > exhausted my fight capacity on different decisions)? > > Not looking for specific answers yet, this is more a discussion kick off. What are the current clones of RHEL that people know about? I know of Springdale Linux and Oracle Linux. I've seen a couple others but I didn't keep track. Does anyone know of a group that is going to start their own RHEL Clone? Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Schedule for Wednesday's FESCo Meeting (2020-12-09)
Sorry for sending this late :) Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 onirc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-12-09 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = None = Followups = #topic #2508 F34 Change: Route all Audio to PipeWire https://pagure.io/fesco/issue/2508 = New business = None = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found athttps://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue athttps://pagure.io/fesco, e-mail me directly, or 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
(Just to be clear before I start, I was not involved in the decision process for yesterday's announcement.) On Tue, Dec 8, 2020 at 10:29 PM Sergio Belkin wrote: > > Hi, > How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) > affect Fedora? The short version: it doesn't. The long version: CentOS Stream is downstream of Fedora. Where there used to be a big leap between Fedora and RHEL, CentOS Stream provides a bridge. A bridge that allows community contribution to RHEL. Think of it this way: Current Fedora -> RHEL 9 Current CentOS Stream -> RHEL 8.4 On Wed, Dec 9, 2020 at 6:16 AM Christoph Karl wrote: > > I think Fedora now needs some kind of LTS. > At least I was planning to support CentOS via EPEL as > a kind of "Fedora LTS". > This comes up every so often, but I don't see it happening. If nothing else, you're putting a maintenance burden on every package maintainer to continue providing updates for whatever definition of "long-term" we come up with. As many maintainers contribute on a volunteer basis (even many of us who are Red Hat employees don't maintain Fedora packages as part of our day job), this is a big burden to ask. We already see signs of the package maintenance burden becoming too high, this would only make it worse. There's also the question of fit. While it's not impossible to be leading edge and provide long-term support at the same time, it's certainly not easy. Beyond package maintenance, there would be additional demands on QA, websites, release engineering, etc to provide a consistent experience over a long-term support lifecycle. On Wed, Dec 9, 2020 at 8:10 AM Jaroslav Prokop wrote: > > While I personally think that Fedora should uphold mainly its philosophy > of being the > "pioneer" of new releases, I feel that then I would miss a production > ready, free and long term supported system > from the ecosystem of RHEL/Fedora. I agree wholeheartedly. CentOS Linux filled a valuable niche in the ecosystem. But Fedora is not the place to replace it. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 9, 2020 at 8:57 AM Damian Ivanov wrote: > Maybe provide a rolling release fedora as well (which is > suitable for non-debug systems). > https://fedoraproject.org/wiki/RawhideKernelNodebug -Jared ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 9, 2020 at 1:54 AM Petr Šabata wrote: > On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi wrote: > > > > On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote: > > > On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi wrote: > > > > > > > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote: > > > > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi > wrote: > > > > > > > > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > > > > > > Also a couple of notes on modularity here: > > > > > > > > > > > > > > # By default, module stream name is derived from the branch > name > > > > > > > If we have any "master" modules, those will get unexpectedly > renamed > > > > > > > as soon as they get rebuilt. This might impact tagging or > updates and > > > > > > > cause confusion in general. We should check if there are any > like that > > > > > > > and decide on further steps. > > > > > > > > > > > > Good thing to check yes. I can try and do so. > > > > > > > > > > Thanks. > > > > > > > > hum, but I am not 100% sure what I am looking for. > > > > modules with a master branch and no name defined? > > > > What does the name being defined look like in the yaml file? > > > > > > Yes. You could also query MBS for stream=master and see if there's > > > anything reasonably recent to narrow your search. But branches would > > > be enough. > > > > > > In modulemd, stream name is defined as "stream: ". > > > > So, I looked back the last 3 months and I am pretty sure the only ones > > are all flatpaks. (firefix, thunderbird, etc) > > > https://mbs.fedoraproject.org/module-build-service/1/module-builds/?stream=master > > I can also see avocado:master built for f33 there on the first page. > But it could also matter for flatpaks if the name is referenced in the > build process. > > CC'ing Owen. > > > > > > > > # Modules might be pulling components from their master > branches to > > > > > > > build Rawhide artifacts > > > > > > > There are various use cases for this, too long to list. If the > master > > > > > > > ref is no longer available, these will not build. Modulemd > files that > > > > > > > pull components from master need to be updated after Phase 2. > > > > > > > > > > > > Yep. +1 > > > > > > > > > > Great, will you do that, too? > > > > > > > > There seems to be a bunch of them. ;( > > > > > > Many of those are definitely obsolete, though! > > > > Well, I checked out all the modules from rawhide. How can I tell they > > are obsolete? > > Uh; I was fairly certain some of those were my dev modules from the > Boltron era. > If I recall correctly, Merlin was working on marking modules as > obsolete at some point. Maybe we didn't actually run it all of them > and they're being built automatically. We should review everything > that's in Rawhide and obviously isn't supposed to be. > > CC'ing Merlin. > I created https://pagure.io/releng/issue/8887 last year to clean up a bunch of obsolete module stream branches, but it's still on the back burner. Merlin P > > > > > > > > # The modulemd component ref is optional and defaults to master > > > > > > > Unless this got changed later, if the ref field is omitted, > the value > > > > > > > defaults to "master". This is part of the specification and is > handled > > > > > > > by libmodulemd. Not sure how to proceed here. > > > > > > > > > > > > Can we change the default? > > > > > > > > > > According to Vít that's already happened (for completely unrelated > > > > > reasons), so we're good here. > > > > > > > > ok. > > > > > > > > > > > And besides modularity: > > > > > > > > > > > > > > There are people and teams who use bots to autobuild their > upstream > > > > > > > projects in Rawhide. If they have a bot account (and I hope > they do), > > > > > > > they should be notified to update their tooling. > > > > > > > > > > > > We don't have much tracking on bot accounts. People make them > and sign > > > > > > up for fas for them, etc. > > > > > > > > > > > > We can try and find things that are obvious, but we are likely > to miss > > > > > > some. We can definitely help people who notice breakage tho. > > > > > > > > > > Ah, I kinda expected these accounts to be clearly marked as being > > > > > non-human. Oh well. > > > > > > > > > > Anyway, besides the magical module stream renames, all of this > should > > > > > continue to work fine if we get the symbolic refs, I think? > > > > > > > > Well, I am ok with a symbolic ref from main to/from rawhide, but I > don't > > > > like the idea of a master symbolic ref. It kind of defeats the > purpose > > > > of the entire thing. ;( > > > > > > Well, okay. If we get the master ref, I'm happy as that's mostly a > no-op for me. > > > If not, it implies a lot of downstream RHEL work we'll have to handle. > > > Just let us all know in due time. > > > > Well, I don't want to keep master around in any form... and yeah, I > > realize there's going to be fallout. ;( > > > > kevin > >
Re: End of CentOS Linux: What about Fedora?
All this sounds cool, rolling release FTW! On that topic (rolling release) I have another suggestion - please fork the thread if that's too OT. Rawhide is good so far but is not suitable as a productive rolling release because some packages have debug flags that slow the system down (I have measured it and rawhide is always significantly slower on my devices). Maybe provide a rolling release fedora as well (which is suitable for non-debug systems). Regards, Damian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: How do really work RAID1 on btrfs?
On 12/9/20 1:31 AM, Kevin Kofler via devel wrote: It follows that the solutions are nonnegative under the following conditions: * a+b≥c * a+c≥b * b+c≥a which are quite logical. Consider a=4, b=1, and c=1, i.e., disks of 4 GB, 1 GB, and 1 GB. Each of the 1 GB disks can only mirror (at most) 1 of the 4 GB, so where would you want to mirror the remaining 2 GB to? And without attempting a formal proof, I would suspect that there is not a unique solution for more than 3 disks, since you get a lot more freedom, but in any case the bigger disk can't be bigger than the sum of all the others, because then of course losing that would be impossible to recover. That condition will be necessary, and I think sufficient too. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
Hello, On 09/12/2020 13:28, Peter Robinson wrote: On Wed, Dec 9, 2020 at 11:12 AM Christoph Karl wrote: Hello! On 09.12.20 04:26, Sergio Belkin wrote: How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) affect Fedora? I think Fedora now needs some kind of LTS. Why? What would it provide that CentOS Stream doesn't? It would provide with what is lost with CentOS Linux. Let's entertain an example: I would like to setup a home server with some locally hosted services, but I wouldn't like to update it to new system with new software every year just to get security updates. That is for me use case that would benefit from LTS. I would've used CentOS Linux but that won't be enough because CentOS 8 is EOL roughly next year. I could use Fedora server but that has too quick a release cycle and I don't have the time to check that everything is running right so often. Instead I would like LTS system that I comfortable with, which is from the RHEL ecosystem. But I don't see sense in running paid RHEL instance that would be only serve as my hobby project server. So with those out of the picture I would probably have to settle for something like Ubuntu LTS. However that is not the solution I'd like to see. If I understood the announcement, it would be a kind of CentOS streams is rolling release or a release with short release interval. That does not make my job much easier as someone who just sets up services and leaves it running. While I personally think that Fedora should uphold mainly its philosophy of being the "pioneer" of new releases, I feel that then I would miss a production ready, free and long term supported system from the ecosystem of RHEL/Fedora. But apparently some already took on this task [0]. Regards, Jarek [0] https://github.com/hpcng/rocky At least I was planning to support CentOS via EPEL as a kind of "Fedora LTS". Best Regards Christoph ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)
Hi, On Wed, Dec 2, 2020 at 5:33 PM Vít Ondruch wrote: > Dne 02. 12. 20 v 14:18 Neal Gompa napsal(a): > > I think that unless it's actually being split out from upstream > > sources from the xorg-server repo, it would just be easier to call it > > xorg-x11-server-Xwayland. > > That was also my thought. I was just curious if this was considered, > because both approaches have some pros/cons. But I don't think I have > preference. > Yep, I reckon calling the standalone package "xorg-x11-server-Xwayland" would be actually easier (for users as well), so I would be fine with such a decision. Cheers Olivier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
El mié, 9 dic 2020 a las 9:28, Peter Robinson () escribió: > On Wed, Dec 9, 2020 at 11:12 AM Christoph Karl wrote: > > > > Hello! > > > > On 09.12.20 04:26, Sergio Belkin wrote: > > > How does this ( > https://blog.centos.org/2020/12/future-is-centos-stream/) > > > affect Fedora? > > > > I think Fedora now needs some kind of LTS. > > Why? What would it provide that CentOS Stream doesn't? > > > At least I was planning to support CentOS via EPEL as > > a kind of "Fedora LTS". > > > > Best Regards > > Christoph > Cutting-edge features? -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1905896] perl-libnet-3.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905896 --- Comment #2 from Fedora Update System --- FEDORA-2020-557bf13b96 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-557bf13b96 --- Comment #2 from Fedora Update System --- FEDORA-2020-e307fe0d5e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e307fe0d5e -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1905896] perl-libnet-3.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905896 --- Comment #2 from Fedora Update System --- FEDORA-2020-557bf13b96 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-557bf13b96 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Packaging a go application
Hi Robin, "Robin Opletal" writes: > On Tue Dec 8, 2020 at 8:17 PM CET, Dan Čermák wrote: >> Hi Robin, > > Hi Dan, > >> BuildRequires: golang($url/$owner/$pkg) >> indicates a dependent package that must be available in Fedora. It is >> actually not a macro, it's just a naming convention for golang packages >> (more specifically, this is a capability that golang packages provide). >> Thus we would be free to change the naming of github.com/creack/pty >> to fancy-golang-github-creack-pty (just a ridiculous example) while not >> having to touch our packages at all, as long as it would still provide >> golang(github.com/creack/pty). > > That makes sense perfect sense to me now - thanks for the explanation. I > will look into how this could then be done > > May I ask if bundling the dependencies in this case would be a good > idea, as even the used libraries are often tagged on a commit for each > aerc release? Bundling is generally discouraged in Fedora, so unless there are really compelling reasons (e.g. there's hundreds of dependencies or aerc does not work with the unbundled go package), you should try to unbundle everything as much as possible. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 9, 2020 at 11:12 AM Christoph Karl wrote: > > Hello! > > On 09.12.20 04:26, Sergio Belkin wrote: > > How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) > > affect Fedora? > > I think Fedora now needs some kind of LTS. Why? What would it provide that CentOS Stream doesn't? > At least I was planning to support CentOS via EPEL as > a kind of "Fedora LTS". > > Best Regards > Christoph > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1905896] perl-libnet-3.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905896 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-libnet-3.12-1.fc34 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Wed, Dec 9, 2020 at 1:15 PM Ondrej Budai wrote: > > Hello! > > st 9. 12. 2020 v 12:35 odesílatel Jaroslav Prokop > napsal: >> >> Hello, >> >> On 09/12/2020 12:12, Christoph Karl wrote: >> > Hello! >> > >> > On 09.12.20 04:26, Sergio Belkin wrote: >> >> How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) >> >> affect Fedora? >> > >> > I think Fedora now needs some kind of LTS. >> > At least I was planning to support CentOS via EPEL as >> > a kind of "Fedora LTS". >> >> If I remember correctly and not making it up there was a discussion some >> years back about Fedora LTS. >> I think it was dismissed because we had CentOS providing LTS stability. >> But now it does not seem like >> we can rely on long term stability. Maybe it's time to revive that >> discussion? > > > Maybe the community can use CentOS Stream as a base for some kind of LTS > distro. > >> >> >> I am starting to get really confused on Fedora's position here. Are we >> anywhere in the pipeline? > > > RHEL/CentOS Stream is branched out of Fedora. > > RHEL and CentOS Stream have a much closer relationship. Someone put it very > nicely: RHEL minor versions are branched off CentOS Stream every 6 months. > It's a bit of oversimplification but it very nicely describes how tight their > relationship is. On the other hand, RHEL/CentOS Stream is branched off Fedora > every 3 years. There's much bigger space for a deviation between them. Red Hat also specifically mentions Fedora ELN in their FAQ: https://www.redhat.com/en/blog/faq-centos-stream-updates#Q8 regards, bex > >> Are we prelude for software before it gets on CentOS streams or maybe >> testing grounds for >> RHEL if something got proved on the ground of CentsOS streams? >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > > > Cheers, > > Ondřej > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
Hello! st 9. 12. 2020 v 12:35 odesílatel Jaroslav Prokop napsal: > Hello, > > On 09/12/2020 12:12, Christoph Karl wrote: > > Hello! > > > > On 09.12.20 04:26, Sergio Belkin wrote: > >> How does this (https://blog.centos.org/2020/12/future-is-centos-stream/ > ) > >> affect Fedora? > > > > I think Fedora now needs some kind of LTS. > > At least I was planning to support CentOS via EPEL as > > a kind of "Fedora LTS". > > If I remember correctly and not making it up there was a discussion some > years back about Fedora LTS. > I think it was dismissed because we had CentOS providing LTS stability. > But now it does not seem like > we can rely on long term stability. Maybe it's time to revive that > discussion? > Maybe the community can use CentOS Stream as a base for some kind of LTS distro. > > I am starting to get really confused on Fedora's position here. Are we > anywhere in the pipeline? > RHEL/CentOS Stream is branched out of Fedora. RHEL and CentOS Stream have a much closer relationship. Someone put it very nicely: RHEL minor versions are branched off CentOS Stream every 6 months. It's a bit of oversimplification but it very nicely describes how tight their relationship is. On the other hand, RHEL/CentOS Stream is branched off Fedora every 3 years. There's much bigger space for a deviation between them. Are we prelude for software before it gets on CentOS streams or maybe > testing grounds for > RHEL if something got proved on the ground of CentsOS streams? > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Cheers, Ondřej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
Hello, On 09/12/2020 12:12, Christoph Karl wrote: Hello! On 09.12.20 04:26, Sergio Belkin wrote: How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) affect Fedora? I think Fedora now needs some kind of LTS. At least I was planning to support CentOS via EPEL as a kind of "Fedora LTS". If I remember correctly and not making it up there was a discussion some years back about Fedora LTS. I think it was dismissed because we had CentOS providing LTS stability. But now it does not seem like we can rely on long term stability. Maybe it's time to revive that discussion? I am starting to get really confused on Fedora's position here. Are we anywhere in the pipeline? Are we prelude for software before it gets on CentOS streams or maybe testing grounds for RHEL if something got proved on the ground of CentsOS streams? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On 09.12.20 11:17, Miro Hrončok wrote: > However, since CentOS Linux 8 (and 9!) will be no more, do we have some > ideas how to handle this? Do we require all EPEL contributors to obtain > the developer RHEL subscription (seems like a huge pain)? Do we switch > to Oracle Linux (only half joking)? Do we try to fight this decision > (however I am afraid I've exhausted my fight capacity on different > decisions)? Intuitively, I think that requiring RHEL dev subscriptions would pretty much kill EPEL packaging on Copr. Unless you specifically want to create EPEL packages, why would you get and keep a RHEL dev subscription when you could just not check the EPEL-boxes? From a purely technical perspective, i.e. pretending it were CentFork Community Linux, are there reasons not to use Oracle Linux? Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
Hello! On 09.12.20 04:26, Sergio Belkin wrote: How does this (https://blog.centos.org/2020/12/future-is-centos-stream/) affect Fedora? I think Fedora now needs some kind of LTS. At least I was planning to support CentOS via EPEL as a kind of "Fedora LTS". Best Regards Christoph ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1905896] perl-libnet-3.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905896 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1905544] perl-PerlIO-via-QuotedPrint-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905544 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PerlIO-via-QuotedPrint ||-0.09-1.fc34 Resolution|--- |RAWHIDE Last Closed||2020-12-09 10:41:57 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Rawhide Repo needs downgradeable packages
Marius Schwarz wrote: > it will eat disk space. If you have 0ad laying around in 3 different > version, that's 1 GB each. Sure, but that is usually not the scarce resource. And if you need the disk space, you can always clear the cache manually. Deleting data should not be the default action. > Ohh.. you meant: default for rawhide.. No, I did not. I explicitly wrote: "Even for stable releases". Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[EPEL-devel] Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
Hello, wrt https://blog.centos.org/2020/12/future-is-centos-stream/ Since EPEL 8 is for RHEL 8 and EPEL Next 8 is for CentOS Stream 8, I assumed we will continue to use CentOS Linux 8 for local mock (and Copr) builds of EPEL 8 packages. The same for EPEL 9. However, since CentOS Linux 8 (and 9!) will be no more, do we have some ideas how to handle this? Do we require all EPEL contributors to obtain the developer RHEL subscription (seems like a huge pain)? Do we switch to Oracle Linux (only half joking)? Do we try to fight this decision (however I am afraid I've exhausted my fight capacity on different decisions)? Not looking for specific answers yet, this is more a discussion kick off. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: Rawhide Repo needs downgradeable packages
Am 09.12.20 um 00:34 schrieb Kevin Kofler via devel: Vít Ondruch wrote: As a workaround, if you use `keepcache=True` in dnf.conf, you'd have copies of everything you previously installed on your system. I still don't understand why this is not the default. Even for stable releases, because without it, you can easily obtain only the ancient GA version of the package, which is usually not what you want to downgrade to. it will eat disk space. If you have 0ad laying around in 3 different version, that's 1 GB each. Ohh.. you meant: default for rawhide.. True. reasonably it should be the default. best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1905896] New: perl-libnet-3.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905896 Bug ID: 1905896 Summary: perl-libnet-3.12 is available Product: Fedora Version: rawhide Status: NEW Component: perl-libnet Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.12 Current version/release in rawhide: 3.11-458.fc33 URL: http://search.cpan.org/dist/libnet/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6982/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
I think the official answer to your question is "nothing: Fedora will continue to provide the development distro upon Centos Stream and then RHEL are built". My opinion instead is that we have many valuable contributors that are in the Fedora community because they have CentOS/RHEL servers in some prod environments. If they're willing to move the prod servers to other distros I don't think they're going to continue their help in the Fedora community. Or to be more sarcastic: - step 1: enter a community to offer help - step 2: hire the most active users of the community and slowly move them to something else - step 3: drop support to the community -- kill the community Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Open Power Hub contact (Re: Sponsorship for non-maintainers)
Hello, Michal. Sorry for replying publicly, but I haven't gotten a reply from you to my direct e-mails since February. I sent a follow-up in August, but you haven't replied to that one, either. If you're no longer the contact person for the Open Power Hub, then do you know who it is now? Or is the project closed? I haven't been able to access my VMs there since February. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
[Bug 1905544] perl-PerlIO-via-QuotedPrint-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1905544 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Packaging a go application
On Tue Dec 8, 2020 at 8:17 PM CET, Dan Čermák wrote: > Hi Robin, Hi Dan, > BuildRequires: golang($url/$owner/$pkg) > indicates a dependent package that must be available in Fedora. It is > actually not a macro, it's just a naming convention for golang packages > (more specifically, this is a capability that golang packages provide). > Thus we would be free to change the naming of github.com/creack/pty > to fancy-golang-github-creack-pty (just a ridiculous example) while not > having to touch our packages at all, as long as it would still provide > golang(github.com/creack/pty). That makes sense perfect sense to me now - thanks for the explanation. I will look into how this could then be done May I ask if bundling the dependencies in this case would be a good idea, as even the used libraries are often tagged on a commit for each aerc release? Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
