date:20240405

[Bug 2273751] New: perl-Imager-1.024 is available

2024-04-05 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2273751

Bug ID: 2273751
   Summary: perl-Imager-1.024 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Imager
  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, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.024
Upstream release that is considered latest: 1.024
Current version/release in rawhide: 1.023-1.fc40
URL: https://metacpan.org/dist/Imager/

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://docs.fedoraproject.org/en-US/package-maintainers/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/6659/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Imager


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273751

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273751%23c0
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

2024-04-05 Thread Scott Schmit

On Thu, Apr 04, 2024 at 10:41:19PM +0200, Fabio Valentini wrote:
> If you really don't mind jumping through multiple hoops just because
> you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
> guess I can't stop you.
> 
> All I *can* do is tell you that you're not going to like the experience:
> 
> - Using "fedpkg local" is not supported for Rust packages, and I won't
> be adding workarounds to the Rust macros for it.
> - Installing rust-*-devel packages on your local system (i.e. outside
> of ephemeral build environments) is not supported.
> - The "rust-*-devel" packages are build system implementation details,
> if you want to say it like that.
> - They are not shipped to users and are not useful for Rust developers.
> - They are *only* intended to be installed in temporary chroots (like
> those set up by mock).
> - They don't get "Obsoletes" or "Provides" in case there are dropped
> subpackages and / or incompatible updates. This is not an issue
> because they are only ever *installed*, but never supposed to be
> *upgraded* in-place. Any issues you get by installing them on your
> host system are your own.

(putting this back in for larger context)

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber wrote:
> > `This package contains library source intended for building other
> > packages which use the "xyz" crate.`
> 
> So the description matches what I said?

No, it does not.  You've thrown out a whole bunch of restrictive terms
of service that are not explicitly stated in the description.

You've said it only works from mock.  "from mock" is not in that
description.

I've used Fedora (and Red Hat Linux before that) for a combined total of
25 years.  Never have I heard of a package that's only for internal
distribution use and I think it's a complete violation of Fedora's
mission statement.

Distribution packages are packaged for *users* to allow *users* to use
them for things *besides* building the distribution.  (Whether that's
software development or otherwise.)

Maybe I should quote Fedora's mission statement:
> Fedora creates an innovative platform for hardware, clouds, and
> containers that enables software developers and community members to
> build tailored solutions for their users.
>
> At the operating system level, we don’t just integrate. We do new
> things — we build a platform, not just a distribution. The *Features*

> and *First* foundations drive us to innovate. We do all of this as a
> transparent, collaborative community of *Friends*, and entirely as
> open source and free software — *Freedom.*

This perhaps explains why my efforts to use these packages did nothing
but waste my time for days. 

It sounds like you've wasted others' time as well.  That's not very
Friendly, and playing nitpicky language lawyer games doesn't change
that, and is also unFriendly.  This is about more than just you.  Other
people are trying to do things, and you're sitting here saying "too bad,
I don't care, it doesn't work and that's not my problem."  If that's not
your intent, that's how it's coming across.

That's an unacceptable attitude, and I think you need to rethink how
you're approaching this conversation and re-read
https://docs.fedoraproject.org/en-US/project/ from top to bottom.

> > If that is how you do things for the rust eco-system, those "devel"
> > packages should be clearly distinguished from real development packages,
> > come with a huge boiler plate "do not install" - or, really, be in a
> > separate repo if installing them is both worthless and misleading for
> > any "real" user. CRB for Fedora material.
> 
> You just pasted the package description above. What more do you want?
> It clearly states that the purpose of the packages is to build other packages.

It does not clearly state *anything* you've just now dropped on us.
Also, all RPMs are packages, not all packages are RPMs.  For all I know,
"package" could be another way of saying "crate."  And just because it's
"intended" to do something doesn't mean "it won't work for anything
else" or "it's not supported if you try to use it for anything else."

And I question whether making packages like that is acceptable for
Fedora.

The naming convention for packages for the last 25 years as far as I've
ever known has established that "foo-devel" packages provide programming
support files that will allow *me* to build *my own* software using
conventional build tools.

The way you've described it, they shouldn't be "foo-devel" packages at
all, because they're useless for routine development.  Admittedly, the
packaging guidelines don't address this, but I assume this is because
this principle is so obvious that nobody thought it needed to be said.
I mean, it's in the mission statement!

It seems to me that these not-"devel" packages should be named

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Kevin Kofler via devel

Peter Boy wrote:
> Well, a switch from Gnome to KDE would require a lot of changes in
> everyday applications, e.g. Mail. That is not required when you update
> from Gnome 2 to Gnome 3.

Well, in principle, GNOME applications will usually work under Plasma and 
the other way round. But in practice of course most default applications on 
the Edition would change along with the desktop environment. So if you are 
one of those users who never upgrades, but always reinstalls from scratch, 
or at least installs everything in the Edition's group on upgrades, you will 
be in for a few surprises indeed.

> Provide a reliable solution which includes a non breaking evolvement of
> the Edition.

I would argue that people upgrading to a newer Fedora should just upgrade in 
place with the packages they have installed, ignoring the new defaults of 
the Edition, so they would remain on GNOME and GNOME applications if that is 
what the release they had initially installed was shipping.

Though of course then there will be some people complaining that an upgraded 
Workstation is completely different from a freshly installed Workstation. 
But IMHO, that would be a feature, not a bug.

> Too bad, an explicit scientific desktop edition might have helped me
> propagate a Linux desktop in our University research cluster of excellence
> a good decade ago.  Scientific Linux for Servers was a great success.

We tried, but it was deemed not distinctive enough to warrant an Edition, 
our application was rejected on those grounds. After all, it was still a 
desktop spin, just with some scientific applications preinstalled on top of 
it. So it was accepted just as yet another Spin (next to the regular KDE 
Spin), and eventually the Labs category was created for this and other use-
case-specific (former) Spins.

So a Scientific Spin (now Scientific Lab) did in fact exist around a decade 
ago, but maybe "a good decade ago" was slightly too early, just before it 
was created.

In addition, there was also pushback against this suggested compromise 
(having the Plasma Edition be a Scientific Edition) from non-scientific KDE 
users who understandably did not want to have to install a Scientific 
Edition and then uninstall lots of niche apps they will never use from it. 
But that discussion became moot because the Edition application was rejected 
anyway.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Kevin Kofler via devel

Leslie Satenstein via devel wrote:
> The Cellphone user is very comfortable with Gnome. So much so, that I
> believe that if he was given KDE as the interface, two things would
> happen. a) The user will switch to Gnome, or b) The user will find a way
> to add his favourite applications to the desktop.

b) is actually very easy on modern Plasma (I tried it on Plasma 5), just 
right-click on the application in the menu and click "Add to desktop" in the 
context menu. KDE upstream has long given up trying to deprecate desktop 
icons (as they tried to do in early Plasma 4 releases, though even those 
allowed you to put a folder view widget displaying the Desktop folder (and 
hence, icons) on the desktop). In Plasma 6, the desktop is always a folder 
view.

Or the user can just switch the menu type to something icon-based and very 
similar to the menu in GNOME Shell with right-click on the menu button, 
"Show Alternatives…" and "Application Dashboard".

And if the user really wants a smartphone UI with a smartphone-style menu, 
always-maximized windows, etc., they should use Plasma Mobile, not Plasma 
Desktop. But a customized Plasma Desktop as described above is probably a 
better fit for traditional desktop/notebook computers.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Kevin Kofler via devel

Tomasz Torcz wrote:
>   GNOME (Mutter) maximizes windows if they initially take 80% of more
> screen space.

And I believe that that, too, was a refinement added in later releases. 
IIRC, GNOME 3.0 just maximized everything.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

2024-04-05 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-07e8f5f1f0   
libopenmpt-0.7.6-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-d9102d9191   
clojure-1.8.0-3.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-1f6e851537   
trafficserver-9.2.4-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-866ac60917   
nghttp2-1.33.0-1.3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

chromium-123.0.6312.105-1.el7
teem-1.11.0-59.el7
wcd-6.0.5-3.el7

Details about builds:



 chromium-123.0.6312.105-1.el7 (FEDORA-EPEL-2024-3cb841c5f0)
 A WebKit (Blink) powered web browser that Google doesn't want you to use

Update Information:

update to 123.0.6312.105
High CVE-2024-3156: Inappropriate implementation in V8
High CVE-2024-3158: Use after free in Bookmarks
High CVE-2024-3159: Out of bounds memory access in V8

ChangeLog:

* Wed Apr  3 2024 Than Ngo  - 123.0.6312.105-1
- update to 123.0.6312.105
  * High CVE-2024-3156: Inappropriate implementation in V8
  * High CVE-2024-3158: Use after free in Bookmarks
  * High CVE-2024-3159: Out of bounds memory access in V8
* Wed Mar 27 2024 Than Ngo  - 123.0.6312.86-2
- update to 123.0.6312.86
  * Critical CVE-2024-2883: Use after free in ANGLE
  * High CVE-2024-2885: Use after free in Daw
  * High CVE-2024-2886: Use after free in WebCodecs
  * High CVE-2024-2887: Type Confusion in WebAssembly
* Sat Mar 23 2024 Than Ngo  - 123.0.6312.58-2
- fixed bz#2269768 - enable build ppc64le package for F40
- fixed bz#2270321 - VAAPI flags in chromium.conf are out of date
- fixed bz#2271183 - disable screen ai service

References:

  [ 1 ] Bug #2271849 - CVE-2024-2883 chromium: Use after free in ANGLE 
[epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2271849
  [ 2 ] Bug #2271855 - CVE-2024-2885 chromium: Use after free in Dawn [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2271855
  [ 3 ] Bug #2271861 - CVE-2024-2886 chromium: Use after free in WebCodecs 
[epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2271861
  [ 4 ] Bug #2271867 - CVE-2024-2887 chromium: Type Confusion in WebAssembly 
[epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2271867
  [ 5 ] Bug #2272870 - CVE-2024-3156 CVE-2024-3158 chromium: various flaws 
[epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2272870
  [ 6 ] Bug #2272877 - CVE-2024-3159 chromium: chromium-browser: Out of bounds 
memory access in V8 [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2272877




 teem-1.11.0-59.el7 (FEDORA-EPEL-2024-f7af304d4c)
 Libraries for processing and visualizing scientific raster data

Update Information:

Actually install the man pages; update License to SPDX

ChangeLog:

* Fri Apr  5 2024 Benjamin A. Beasley  - 1.11.0-59
- Actually install the man pages
* Fri Apr  5 2024 Benjamin A. Beasley  - 1.11.0-57
- Run tests serially *without* overriding spec-file macros
* Fri Apr  5 2024 Benjamin A. Beasley  - 1.11.0-56
- Update License to SPDX
* Fri Apr  5 2024 Benjamin A. Beasley  - 1.11.0-55
- Improve summary for -libs subpackage




 wcd-6.0.5-3.el7 (FEDORA-EPEL-2024-7d01d6199f)
 Wherever Change Directory: chdir for DOS and Unix

Update Information:

Fix a typo in the Summary of the -doc subpackage

ChangeLog:

* Fri Apr  5 2024 Benjamin A. Beasley  - 6.0.5-3
- Fix a typo in the Summary of the -doc subpackage


--
___
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
Do not reply

[Bug 2272408] perl-PDL-2.087 is available

2024-04-05 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2272408

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-PDL-2.086 is available |perl-PDL-2.087 is available



--- Comment #2 from Upstream Release Monitoring 
 ---
Releases retrieved: 2.087
Upstream release that is considered latest: 2.087
Current version/release in rawhide: 2.85.0-2.fc40
URL: https://metacpan.org/dist/PDL/

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://docs.fedoraproject.org/en-US/package-maintainers/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/3205/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-PDL


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272408

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272408%23c2
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F41 Change Proposal: Pytest 8 (self-contained)

2024-04-05 Thread Aoife Moloney

Wiki - https://fedoraproject.org/wiki/Changes/Pytest_8

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

Update to a new upstream release of pytest that is not completely
compatible with previous releases. Pytest 8 is a major upstream
release removing a lot of deprecated functions and introducing
breaking changes.

== Owner ==
* Name: [[User:thrnciar| Tomáš Hrnčiar]]
* Name: [[User:churchyard| Miro Hrončok]]
* Email: python-ma...@redhat.com


== Detailed Description ==
Pytest is a popular Python framework for writing tests. The 8th major
release brings various improvements. The most notable enhancements
are:
* The diffs that pytest prints when an assertion fails were improved.
* Added the new verbosity_assertions configuration option for
fine-grained control of failed assertions verbosity.
* Additional support for exception groups and __notes__
* custom directory collectors
* “new-style” hook wrappers are now used internally

[https://docs.pytest.org/en/stable/changelog.html#breaking-changes
Breaking changes:]
* PytestRemovedIn8Warning deprecation warnings are now errors by default
* Several breaking changes to pytest’s collection phase, particularly
around how filesystem directories and Python packages are collected,
fixing deficiencies and allowing for cleanups and improvements to
pytest’s internals.
* Sanitized the handling of the default parameter when defining
configuration options
* pytest’s setup.py file is removed
* warns() now re-emits unmatched warnings when the context closes –
previously it would consume all warnings, hiding those that were not
matched by the function
* The internal FixtureManager.getfixtureclosure method has changed.
Plugins which use this method or which subclass FixtureManager and
overwrite that method will need to adapt to the change.

List of packages that will likely fail to build.

Maintainers by package:
* cffconvert   iztokf
* cloud-init   dustymabe gholms larsks mhayden otubo
* copr-backend frostyx msuchy praiskup
* copr-frontendfrostyx msuchy praiskup
* copr-rpmbuildfrostyx praiskup
* fedmsg   kevin
* git-up   ekohl
* h5py orion stevetraylen terjeros
* httpie   churchyard codeblock mikelo2
* ipython  churchyard cstratak ignatenkobrain lbalhar
mrunge salimma tomspur
* jrnl music
* mu   churchyard kushal
* pg_activity  mikelo2
* python-APScheduler   mmassari zuul
* python-aiohttp-cors  kwizart
* python-alembic   frantisekz
* python-ase   besser82 marcindulak
* python-astropy   orion sergiopr
* python-atpublic  abompard jonathanspw
* python-attrs churchyard lbalhar
* python-aws-sam-translator music
* python-bluepyopt ankursinha
* python-boto3 cstratak fale limb
* python-chalice   dcavalca
* python-contextilyqulogic
* python-cssutils  kevin
* python-dbus-next alebastr
* python-dirhash   cottsay
* python-django-extensions aekoroglu ngompa salimma
* python-earthpy   iztokf
* python-ecdsa brouhaha jonathanspw orion
* python-efel  ankursinha
* python-fastjsonschema thrnciar
* python-fiona qulogic
* python-fslpy ankursinha
* python-geopandas qulogic
* python-geoplot   qulogic
* python-glob2 jujens
* python-graphviz  eclipseo mairacanal
* python-hid-parserrathann
* python-ipykernel churchyard pcpa
* python-ipywidgetslbalhar
* python-josepynb
* python-kombu fab frantisekz mrunge ngompa pingou pjp
* python-lexicon   mhayden pghmcfc
* python-libpysal  qulogic
* python-mapclassify   qulogic
* python-marshmallow-enum fab
* python-mathics-pygments dcavalca
* python-mirrors-countme asaleh nphilipp
* python-mne   ankursinha ignatenkobrain
* python-mplcursorsqulogic
* python-networkx  jjames plautrba
* python-nibabel   ankursinha ignatenkobrain
* python-nikolajamatos maxamillion
* python-notebook  churchyard ksurma lbalhar
* python-oci   mhayden
* python-openapi-core  mattia music
* python-opentelemetry mhayden music pwouters rominf
* python-papermill ankursinha
* python-paramiko  ignatenkobrain limb orion pghmcfc sgallagh
* python-parseljonathanspw
* python-pem   mhayden
* python-pint  jcapitao lzachar mrunge
* python-prettytable   apevec clalance
* python-pydantic  gotmax23 music nikromen
* python-pymeeus   fab
* python-pynwb lbazan
* python-pysaml2   apevec
* python-pytest-cases  zbyszek
* python-pytest-forked swt2c
* python-pytest-lazy-fixture ankursinha mikelo2
* python-pytest-mpiorion
* python-pytest-postgresql mikelo2
* python-pytest-relaxed

F41 Change Proposal: Pytest 8 (self-contained)

2024-04-05 Thread Aoife Moloney

Wiki - https://fedoraproject.org/wiki/Changes/Pytest_8

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

Update to a new upstream release of pytest that is not completely
compatible with previous releases. Pytest 8 is a major upstream
release removing a lot of deprecated functions and introducing
breaking changes.

== Owner ==
* Name: [[User:thrnciar| Tomáš Hrnčiar]]
* Name: [[User:churchyard| Miro Hrončok]]
* Email: python-ma...@redhat.com


== Detailed Description ==
Pytest is a popular Python framework for writing tests. The 8th major
release brings various improvements. The most notable enhancements
are:
* The diffs that pytest prints when an assertion fails were improved.
* Added the new verbosity_assertions configuration option for
fine-grained control of failed assertions verbosity.
* Additional support for exception groups and __notes__
* custom directory collectors
* “new-style” hook wrappers are now used internally

[https://docs.pytest.org/en/stable/changelog.html#breaking-changes
Breaking changes:]
* PytestRemovedIn8Warning deprecation warnings are now errors by default
* Several breaking changes to pytest’s collection phase, particularly
around how filesystem directories and Python packages are collected,
fixing deficiencies and allowing for cleanups and improvements to
pytest’s internals.
* Sanitized the handling of the default parameter when defining
configuration options
* pytest’s setup.py file is removed
* warns() now re-emits unmatched warnings when the context closes –
previously it would consume all warnings, hiding those that were not
matched by the function
* The internal FixtureManager.getfixtureclosure method has changed.
Plugins which use this method or which subclass FixtureManager and
overwrite that method will need to adapt to the change.

List of packages that will likely fail to build.

Maintainers by package:
* cffconvert   iztokf
* cloud-init   dustymabe gholms larsks mhayden otubo
* copr-backend frostyx msuchy praiskup
* copr-frontendfrostyx msuchy praiskup
* copr-rpmbuildfrostyx praiskup
* fedmsg   kevin
* git-up   ekohl
* h5py orion stevetraylen terjeros
* httpie   churchyard codeblock mikelo2
* ipython  churchyard cstratak ignatenkobrain lbalhar
mrunge salimma tomspur
* jrnl music
* mu   churchyard kushal
* pg_activity  mikelo2
* python-APScheduler   mmassari zuul
* python-aiohttp-cors  kwizart
* python-alembic   frantisekz
* python-ase   besser82 marcindulak
* python-astropy   orion sergiopr
* python-atpublic  abompard jonathanspw
* python-attrs churchyard lbalhar
* python-aws-sam-translator music
* python-bluepyopt ankursinha
* python-boto3 cstratak fale limb
* python-chalice   dcavalca
* python-contextilyqulogic
* python-cssutils  kevin
* python-dbus-next alebastr
* python-dirhash   cottsay
* python-django-extensions aekoroglu ngompa salimma
* python-earthpy   iztokf
* python-ecdsa brouhaha jonathanspw orion
* python-efel  ankursinha
* python-fastjsonschema thrnciar
* python-fiona qulogic
* python-fslpy ankursinha
* python-geopandas qulogic
* python-geoplot   qulogic
* python-glob2 jujens
* python-graphviz  eclipseo mairacanal
* python-hid-parserrathann
* python-ipykernel churchyard pcpa
* python-ipywidgetslbalhar
* python-josepynb
* python-kombu fab frantisekz mrunge ngompa pingou pjp
* python-lexicon   mhayden pghmcfc
* python-libpysal  qulogic
* python-mapclassify   qulogic
* python-marshmallow-enum fab
* python-mathics-pygments dcavalca
* python-mirrors-countme asaleh nphilipp
* python-mne   ankursinha ignatenkobrain
* python-mplcursorsqulogic
* python-networkx  jjames plautrba
* python-nibabel   ankursinha ignatenkobrain
* python-nikolajamatos maxamillion
* python-notebook  churchyard ksurma lbalhar
* python-oci   mhayden
* python-openapi-core  mattia music
* python-opentelemetry mhayden music pwouters rominf
* python-papermill ankursinha
* python-paramiko  ignatenkobrain limb orion pghmcfc sgallagh
* python-parseljonathanspw
* python-pem   mhayden
* python-pint  jcapitao lzachar mrunge
* python-prettytable   apevec clalance
* python-pydantic  gotmax23 music nikromen
* python-pymeeus   fab
* python-pynwb lbazan
* python-pysaml2   apevec
* python-pytest-cases  zbyszek
* python-pytest-forked swt2c
* python-pytest-lazy-fixture ankursinha mikelo2
* python-pytest-mpiorion
* python-pytest-postgresql mikelo2
* python-pytest-relaxed

Fedora Linux 40 Blocker Bug Summary Report: 2024-04-05

2024-04-05 Thread Aoife Moloney

Hi folks,

We are fast approaching the end of the F40 Final Freeze and the F40
Go/No-Go meetings will start real soon. There are a number of bugs,
both accepted and proposed, filed against F40 Final, so your help in
troubleshooting and potentially finding a fix for those would be
greatly appreciated. In particular, there is a blocker bug outstanding
from the F39 release, and some additional feedback on the ideas to
resolve the issue is needed.

Please visit the blocker bugs app for more details
https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist

Summary 2024-04-05

== Proposed Blocker ==
1. khelpcenter - bluetooth.service becomes unresponsive when
disabling the interface while a device is still connected since bluez
5.73 - ON_QA
ACTION: QA to verify fix
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d9c6f3fae

3. plasma-drkonqi - Logoout after less than 60 seconds is broken on
Plasma 6.0.3 - POST
ACTION: QA to verify
https://bodhi.fedoraproject.org/updates/FEDORA-2024-668daf04ea

5. uboot-tools - U-Boot doesn't find and load the fedoa provided DTBS
from /boot/dtb - MODIFIED
ACTION: QA to verify
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1d0b793bc1

== Accepted Blockers ==
1. khelpcenter - The KDE help center does not show the documentation
for KDE applications - NEW
ACTION: Upstream to diagnose issue

2. loupe - Loupe cannot open JPEG images - VERIFIED
ACTION: None

3. snapshot - Snapshot displays only on solid pink - VERIFIED
ACTION: None

Accepted Previous Release Blocker
1. distribution - dnf system-upgrade fails on some RPi4 due to system
boot date that pre-dates gpg key - NEW
ACTION: HELP WANTED to figure out a fix please

= Bug by Bug Detail =

== Proposed Blockers ==
1. khelpcenter - bluetooth.service becomes unresponsive when disabling
the interface while a device is still connected since bluez 5.73 -
https://bugzilla.redhat.com/show_bug.cgi?id=2269516 - ON_QA

There were issues enabling and disabling the bluetooth interface after
an update to bluez in F39. It also affected connecting and
disconnecting bluetooth devices. An upstream patch was filed with
bluez that reverts a commit which appears to resolve the issue
https://lore.kernel.org/linux-bluetooth/20240403205252.71978-1-dimitris.on.li...@gmail.com/T/#t
and a build with this patch, bluez 5.73-3 has been pushed to the
Fedora 40 testing repo for verification
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d9c6f3fae

2. gtk4 - snapshot crashes on launch or after taking a picture,
console error "thread 'main' has overflowed its stack", backtrace is
4000+ frames and inc "Cannot access memory at address
0x" -
https://bugzilla.redhat.com/show_bug.cgi?id=2273497 - NEW
Snapshot is crashing in launch or after taking the first picture when
using the Logitech C920 camera. It also shows a 'no camera found'
message when launching from the gnome-shell launcher. This issue does
not seem to affect an integrated HD Webcam on an acer notebook, so
more testing on other types of hardware would be of great benefit to
identify if this bug is only related to the C920 camera, or if there
are other affected machines.

3. plasma-drkonqi - Logout after less than 60 seconds is broken in
Plasma 6.0.3 - https://bugzilla.redhat.com/show_bug.cgi?id=2272712 -
POST
When wanting to log out of KDE through the graphical interface, the
system does not log the user out at all, however the issue is only
active within the first 60 seconds of logging in. An update that
backports and upstream fix which caused the issue has been submitted
to the testing repository for F40
https://bodhi.fedoraproject.org/updates/FEDORA-2024-668daf04ea

4. python-blivet - Firmware RAID set not usable in anaconda when
booting native UEFI: "ERROR:blivet:failed to determine name for the md
array a7ff7f19-f142-4329-6b52-1dbafa835906" -
https://bugzilla.redhat.com/show_bug.cgi?id=2270209 -ASSIGNED
Anaconda (via blivet) does not detect the firmware RAID to set as a
viable target for install when booting from BIOS. This issue is found
in F39 as well as F40 beta. More testing of the F40 beta on other
hardware with firmware RAID on UEFI would be most appreciated as it is
not clear whether this is hardware specific or not as the behaviour is
seen on an Asus H97M-E motherboard, but not on a Gigabyte
GA-Z170M-D3H.

5. uboot-tools - U-Boot doesn't find and load the Fedora provided DTBs
from /boot/dtb -

[Bug 2273691] perl-Test-mysqld-1.0020 is available

2024-04-05 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2273691



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Test-mysqld-1.0020-1.fc38.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=115938838


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273691

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273691%23c2
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2273691] New: perl-Test-mysqld-1.0020 is available

2024-04-05 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2273691

Bug ID: 2273691
   Summary: perl-Test-mysqld-1.0020 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-mysqld
  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



Releases retrieved: 1.0020
Upstream release that is considered latest: 1.0020
Current version/release in rawhide: 1.0013-13.fc40
URL: http://search.cpan.org/dist/Test-mysqld/

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://docs.fedoraproject.org/en-US/package-maintainers/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/8094/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Test-mysqld


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273691

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273691%23c0
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2273691] perl-Test-mysqld-1.0020 is available

2024-04-05 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2273691



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 2025459
  --> https://bugzilla.redhat.com/attachment.cgi?id=2025459=edit
Update to 1.0020 (#2273691)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273691

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273691%23c1
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedocal] Reminder meeting : ELN SIG

2024-04-05 Thread Stephen Gallagher

On Thu, Apr 4, 2024 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2024-04-05 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:


=
# #meeting:fedoraproject.org: eln
=

Meeting started by @sgallagh:fedora.im at 2024-04-05 16:01:47



Meeting summary
---
* TOPIC: Init Process (@sgallagh:fedora.im, 16:01:57)
* TOPIC: Agenda (@sgallagh:fedora.im, 16:05:39)
* INFO: Agenda Item: Issues with guest image building
(@sgallagh:fedora.im, 16:07:26)
* INFO: Agenda Item: How to include ELN-only packages
(@sgallagh:fedora.im, 16:09:34)
* INFO: Agenda Item: ELN buildroot retention (@sgallagh:fedora.im, 16:12:40)
* TOPIC: ELN buildroot retention (@sgallagh:fedora.im, 16:15:07)
* LINK: https://pagure.io/releng/issue/12053
(@yselkowitz:fedora.im, 16:15:36)
* INFO: No specific actions to take here at the moment, other than
to schedule and work on migration of composes off of ODCS.
(@sgallagh:fedora.im, 16:28:44)
* TOPIC: How to include ELN-only packages (@sgallagh:fedora.im, 16:28:08)
* INFO: ELN-only packages should be built into eln-extras from a
separate SRPM name than the Rawhide package. (@sgallagh:fedora.im,
16:57:09)
* INFO: That separate SRPM name will be added to the exclusion
list in ELNBuildSync to avoid accidental rebuilds
(@sgallagh:fedora.im, 16:57:48)
* INFO: The needed subpackage(s) will be added to Content Resolver
for ELN Extras. (@sgallagh:fedora.im, 16:58:05)
* ACTION: Davide Cavalca to update the docs (@sgallagh:fedora.im, 17:00:41)

Meeting ended at 2024-04-05 17:02:12

Action items

* Davide Cavalca to update the docs

People Present (lines said)
---
* @sgallagh:fedora.im (59)
* @davide:cavalca.name (17)
* @yselkowitz:fedora.im (15)
* @nirik:matrix.scrye.com (6)
* @tdawson:fedora.im (4)
* @zodbot:fedora.im (4)
* @meetbot:fedora.im (2)
* @nhanlon:beeper.com (1)
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Introduction and Application for Sponsorship

2024-04-05 Thread seanmottles


Hi devel!

I'm Sean (FAS: seaninspace). I've been working professionally in Linux 
Sysadmin/Engineering positions for over a decade now, and would like to 
help out more :)


I've spent most of my Fedora time in QA with the installer, specifically 
the XFCE Live ISO. Additionally, I have maintained small/personal 
packages outside of the official repositories in the past, and have 
previously maintained an RPM mirror with a decent amount of traffic. I'm 
hoping to learn more and give back by adopting this package.


I've submitted a sponsorship ticket here: 
https://pagure.io/packager-sponsors/issue/643


Thanks for your time and work!

Sean
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

2024-04-05 Thread Jerry James

On Fri, Apr 5, 2024 at 7:35 AM Fabio Valentini  wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> wrote:
> > Is there any other set of packages which we package like that?
>
> Probably golang ... maybe Haskell, OCaml?

Not OCaml, no.  The OCaml packages can be installed and used for
software development.
-- 
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 40 compose report: 20240405.n.0 changes

2024-04-05 Thread Fedora Branched Report

OLD: Fedora-40-20240404.n.0
NEW: Fedora-40-20240405.n.0

= SUMMARY =
Added images:1
Dropped images:  2
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240405.n.0.iso

= DROPPED IMAGES =
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240404.n.0.ociarchive
Image: Silverblue ociarchive ppc64le
Path: Silverblue/ppc64le/images/Fedora-Silverblue-40.20240404.n.0.ociarchive

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Leon Fauster via devel


Am 05.04.24 um 12:20 schrieb Vít Ondruch:


Dne 04. 04. 24 v 17:32 Kevin Kofler via devel napsal(a):

Neal Gompa wrote:

By default, GNOME only presents the close window button. The other
buttons are missing, and there isn't really an intuitive way to
discover the other window management actions.



I agree that there are no other buttons. But still, Gnome opens the 
windows in normalized state, not maximized what was the original claim.



It feels strange when a discussion is done about such things, to argue
against or for a component/DE/software etc.

As I said intuition is not something that is inherently in the 
technology. For instance, the "scale a photo"-gesture on a common

mobile device OS, is not "natural". Its something that was communicated
by advertisements.

Such communication could look like (with alternatives):
In Gnome, with the focus on a window, use the leftAlt+Space shortcut
to get your needed function. All that from the keyboard (intentional 
efficient short cut). And for the mouse pushers, open the tweak app to 
configure the top bar of the windows to get your button. For the distro, 
just configure for example the minimize button to be present as default.


All that said, does not solve the dialectic discussion. I would suggest
the equal authorization to be present for both desktop environments. And
such principle should lead the further activities. Remember diversity 
wins, ideology not.


--
Leon


--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

2024-04-05 Thread Fabio Valentini

On Fri, Apr 5, 2024 at 3:16 PM Emanuel Lima  wrote:
>
> I'm not sure this helps, but I maintain a Rust and Go package that builds 
> fine with fedpkg local. If you want to take a look at the spec:
>
> https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec

This is a particularly bad example for a Rust package for two reasons:

"fedpkg local" only works because you build with vendored sources
(without following the bundling guidelines, i.e. declaring bundled
dependencies).
The package also builds in a way that does not respect default Fedora
compiler flags (see
https://bugzilla.redhat.com/show_bug.cgi?id=2167235).

Fabio
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

2024-04-05 Thread Fabio Valentini

On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  wrote:
>
> So you're saying that those packages are in the repos for everyone but
> not meant to be installed by anyone (besides mock chroots), and that is
> how and why they are packaged.

Yes. That is the best we can do given how cargo + Rust work.

> `This package contains library source intended for building other packages 
> which
> use the "xyz" crate.`

So the description matches what I said?

> Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
>
> Wow!

Sorry to burst your bubble, but "fedpkg local" is an ugly hack
(independent of Rust peculiarities).
And I am not interested in adding workarounds to the Rust packaging
toolchain to support it.

"fedpkg mockbuild" and "fedpkg srpm" all work as expected ...

> Is there any other set of packages which we package like that?

Probably golang ... maybe Haskell, OCaml?

> If that is how you do things for the rust eco-system, those "devel"
> packages should be clearly distinguished from real development packages,
> come with a huge boiler plate "do not install" - or, really, be in a
> separate repo if installing them is both worthless and misleading for
> any "real" user. CRB for Fedora material.

You just pasted the package description above. What more do you want?
It clearly states that the purpose of the packages is to build other packages.

Also, Fedora won't do split repos (been there, done that), and stuff
like it doesn't even work that well in RHEL (and causes all sorts of
issues).

While I agree that the situation is not ideal, I still think this is
the best that we can do:

1. We don't want Rust applications to vendor their dependencies
2. Rust can only do static linking (for now)
-> Dependencies can only be shipped as source code, not as compiled artifacts.

And while you *can* use packaged Rust crates for local development if
you really want, it's not really a supported use case.

Fabio
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Peter Boy

> Am 05.04.2024 um 14:16 schrieb Kevin Kofler via devel 
> :
> 
> Peter Boy wrote:
>>> 
>>> . . .
>> 
>> This is an absolute no-go! It would break everyone’s usage of Fedora
>> Workstation
> 
> It would be a major change, yes. Though not really different from the 
> aforementioned upgrade to GNOME 3 with its completely redesigned user 
> experience, which was also done.
> 
> If Workstation were never allowed to change its user experience, it would be 
> shipping MATE nowadays, not GNOME.

Well, a switch from Gnome to KDE would require a lot of changes in everyday 
applications, e.g. Mail. That is not required when you update from Gnome 2 to 
Gnome 3.

>> and is in irreconcilable contradiction to the characteristics of an
>> „Edition" as defined with Fedora.next.
> 
> How so?

Provide a reliable solution which includes a non breaking evolvement of the 
Edition.

But not to give the wrong impression: I think it would be beneficial for Fedora 
to develop an alternative to the current Gnome Workstation, which has evolved 
over the years into a rather fat, bloated and opaque entity. But I think this 
change proposal is the wrong way to go.

>> For the desktop area I don’t see a non-overlapping use case between Gnome
>> and KDE. It’s just a different tool for the same use case.
> 
> This exact argument was already used 10 years ago to reject our (that was 
> before I left the KDE SIG, though this issue was one of the triggers for me 
> leaving the SIG) request for a Plasma Edition. 10 years later, we still have 
> no way out of this dilemma. The definition of an Edition needs to be refined 
> or completely replaced to get out of this catch-22.
> 
> As part of the process to look for a non-overlapping use case, there was an 
> attempt to focus specifically on scientific applications, which eventually 
> lead to the Scientific Lab, but that did not make it to an Edition either, 
> just to a Lab.
> 
> The overlap issue is also going to hinder other deliverables' efforts to 
> become Editions. E.g., Silverblue mostly overlaps with Workstation and 
> CoreOS: Workstation for the general use cases (workstation/desktop usage), 
> CoreOS for the atomic and container-oriented use cases.

Too bad, an explicit scientific desktop edition might have helped me propagate 
a Linux desktop in our University research cluster of excellence a good decade 
ago.  Scientific Linux for Servers was a great success. 

But it could still be a non-overlapping use case in its own right (even if I am 
contradicting myself): 

Integration / integrability in professional work environments thanks to the 
similarity of the KDE interface to Windows / MacOS and thanks to the 
cross-operating system capabilities of KDE (many KDE apps are already available 
for Windows, at least I’m happily using Kate on MacOS). And additionally, a way 
aiming to specifically attract new users who are currently on Windows/MacOS.

Scientific Desktop would be a special sub-case of this.

(Hm, would be really attractive to develop something like that)

>> That may change and can change, of course. But that’s nothing for F42,
>> rather for F52.
> 
> It just requires creating a new working group. That can be done instantly.

I'm afraid it's not that simple. It requires not only a new foundation or 
restructuring of a SIG, but also a mindset change among participants.  And the 
latter takes much longer. 

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

2024-04-05 Thread Emanuel Lima

I'm not sure this helps, but I maintain a Rust and Go package that builds fine 
with fedpkg local. If you want to take a look at the spec:

https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Leslie Satenstein via devel

I am an old geezer with about 60 years of IT experience, from mainframe to 
cellphone.I am self-convinced that dropping gnome for KDE as a default would be 
BAD.Why?Today, everyone who ones a cellphone, has on his phone a set of icons. 
Some are there by default, some are there as extra applications that the user 
added.

The Cellphone user is very comfortable with Gnome. So much so, that I believe 
that if he was given KDE as the interface, two things would happen. a) The user 
will switch to Gnome, or b) The user will find a way to add his favourite 
applications to the desktop.
What then is a compromise that will satisfy the Gnome and KDE "bigots"?   
Consider:
The Fedora 41/42 installation program can ask the user if he prefers  "Menu" or 
"icon" interface.  
The above approach satisfied both camps.

Leslie Satenstein

On Friday, April 5, 2024 at 08:16:54 a.m. EDT, Kevin Kofler via devel 
 wrote:  

 Peter Boy wrote:
> I'm probably not the right person to comment on this, because I completely
> abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That
> destroyed my daily workflow and work routines and made it unusable (for
> me), or at least barely usable for serious professional work not related
> to software development (and I ended up using MacOS to this day).

Which is exactly why I proposed back then to make Plasma (which actually 
operates more similarly to GNOME 2 than GNOME 3 does) the default. :-)

>> == Summary ==
>> Switch the default desktop experience for Workstation to KDE Plasma.
>> The GNOME desktop is moved to a separate spin / edition, retaining
>> release-blocking status.
> 
> This is an absolute no-go! It would break everyone’s usage of Fedora
> Workstation

It would be a major change, yes. Though not really different from the 
aforementioned upgrade to GNOME 3 with its completely redesigned user 
experience, which was also done.

If Workstation were never allowed to change its user experience, it would be 
shipping MATE nowadays, not GNOME.

> and is in irreconcilable contradiction to the characteristics of an
> „Edition" as defined with Fedora.next.

How so?

> And that is not „just“ a technical issue (the FESCo domain), but a basic
> Fedora principle.

If you believe a basic Fedora principle is being violated, please bring that 
up with the Council.

> Another proposal is to make it an „Edition“. But basically, a merely KDE
> Desktop is not „edition-able“. Among others, an edition is meant to cover
> a specific use case and a long-term and (more or less) perfectly designed
> and engineered solution for this. So we have desktop (Workstation) and
> server. Among server we have several Editions, the universal Fedora
> Server, container centric CoreOS, edge centric IoT and Cloud. Each of the
> server-like Editions covers a destined, specific use case without
> overlapping.
> 
> For the desktop area I don’t see a non-overlapping use case between Gnome
> and KDE. It’s just a different tool for the same use case.

This exact argument was already used 10 years ago to reject our (that was 
before I left the KDE SIG, though this issue was one of the triggers for me 
leaving the SIG) request for a Plasma Edition. 10 years later, we still have 
no way out of this dilemma. The definition of an Edition needs to be refined 
or completely replaced to get out of this catch-22.

As part of the process to look for a non-overlapping use case, there was an 
attempt to focus specifically on scientific applications, which eventually 
lead to the Scientific Lab, but that did not make it to an Edition either, 
just to a Lab.

The overlap issue is also going to hinder other deliverables' efforts to 
become Editions. E.g., Silverblue mostly overlaps with Workstation and 
CoreOS: Workstation for the general use cases (workstation/desktop usage), 
CoreOS for the atomic and container-oriented use cases.

> And if we are willing to accept an exception and accept KDE desktop as an
> Edition, I don’t see that the current SIG qualifies as an edition-capable
> working group. Given the recent discussion about Wayland / X11, I don’t
> see any obligation/commitment to ensure long-term reliability and
> trouble-free usability. Instead, I see in the discussion an unbridled
> desire to introduce something new (that's good) without regard for
> backwards compatibility and uninterrupted usability (that's bad, we need
> both). And obviously the resources to manage both (Wayland and X11) in one
> working group are also lacking (and given the schism, possibly also the
> willingness to do so).

That particular concern, however, is one that I also share. The working 
group should be required to accept at least one of us plasma-workspace-x11 
maintainers (it can be Sérgio M. Basto or Steven A. Falco if they do not 
accept me) into the working group.

> That may change and can change, of course. But that’s nothing for F42,
> rather for F52.

It just requires creating a new working group. That can be done

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Tomasz Torcz

On Fri, Apr 05, 2024 at 12:20:51PM +0200, Vít Ondruch wrote:
> 
> Dne 04. 04. 24 v 17:32 Kevin Kofler via devel napsal(a):
> > Neal Gompa wrote:
> > > By default, GNOME only presents the close window button. The other
> > > buttons are missing, and there isn't really an intuitive way to
> > > discover the other window management actions.
> 
> 
> I agree that there are no other buttons. But still, Gnome opens the windows
> in normalized state, not maximized what was the original claim.

  GNOME (Mutter) maximizes windows if they initially take 80% of more
screen space.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Steve Cossette

We didnt withdraw it because, well to be completely honest, we are afraid
that, if we do that, in the eyes of the community at least, we will abandon
the idea completely and any subsequent effort would be undermined as a
result.

It’s kindof a case of « damned if you do and damned if you don’t »…

On Fri, Apr 5, 2024 at 03:03 Zbigniew Jędrzejewski-Szmek 
wrote:

> On Thu, Apr 04, 2024 at 04:26:52PM -0700, Adam Williamson wrote:
> > On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote:
> > > On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote:
> > > > > So here are three brainstorming proposals:
> > > > >
> > > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need
> to be
> > > > > careful about how we do it. I would still promote Fedora
> Workstation as the
> > > > > main/recommended "leading" desktop, would call Plasma an
> "alternative
> > > > > desktop option," and would strongly caution against use of the word
> > > > > "Workstation" anywhere in the branding for the Plasma version.
> That is,
> > > > > let's continue to steer undecided users towards Fedora
> Workstation, while
> > > > > making Plasma easier to find and presenting it more prominently
> than it is
> > > > > today.
> > > >
> > > > I like this proposal. It would give the KDE spin more prominence and
> > > > would be a good reply to the huge work that has been put into the
> spin
> > > > in recent times. It also wouldn't disrupt our story about Fedora
> Workstation.
> > > >
> > > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be
> > > > confused with Fedora Workstation.
> > > >
> > >
> > > So, effectively no change other than it moves from the Spins section
> > > to the Editions section? That would also mean it should be on the
> > > front page too, like the other Editions.
> >
> > Being an Edition is a very significant thing, though, as we conceive of
> > Fedora more widely than just the download page. We put a bunch of hoops
> > in the way of IoT and CoreOS becoming editions, and there are hoops in
> > the way of Silverblue becoming one (or, you know, wherever we go with
> > that path in the end).
>
> My silent assumption was that the current change proposal would be
> withdrawn and replaced by a new proposal. We have a formal procedure in
> [1].
> Looking at that list, it seems all fine. The only sticky point is whether
> KDE desktop serves a different purpose than Workstation with GNOME.
> I'd say it does: desktop preferences are like religion, and people don't
> just switch (except when they do).
>
> [1]
> https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/
>
> Zbyszek
> --
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Kevin Kofler via devel

Peter Boy wrote:
> I'm probably not the right person to comment on this, because I completely
> abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That
> destroyed my daily workflow and work routines and made it unusable (for
> me), or at least barely usable for serious professional work not related
> to software development (and I ended up using MacOS to this day).

Which is exactly why I proposed back then to make Plasma (which actually 
operates more similarly to GNOME 2 than GNOME 3 does) the default. :-)

>> == Summary ==
>> Switch the default desktop experience for Workstation to KDE Plasma.
>> The GNOME desktop is moved to a separate spin / edition, retaining
>> release-blocking status.
> 
> This is an absolute no-go! It would break everyone’s usage of Fedora
> Workstation

It would be a major change, yes. Though not really different from the 
aforementioned upgrade to GNOME 3 with its completely redesigned user 
experience, which was also done.

If Workstation were never allowed to change its user experience, it would be 
shipping MATE nowadays, not GNOME.

> and is in irreconcilable contradiction to the characteristics of an
> „Edition" as defined with Fedora.next.

How so?

> And that is not „just“ a technical issue (the FESCo domain), but a basic
> Fedora principle.

If you believe a basic Fedora principle is being violated, please bring that 
up with the Council.

> Another proposal is to make it an „Edition“. But basically, a merely KDE
> Desktop is not „edition-able“. Among others, an edition is meant to cover
> a specific use case and a long-term and (more or less) perfectly designed
> and engineered solution for this. So we have desktop (Workstation) and
> server. Among server we have several Editions, the universal Fedora
> Server, container centric CoreOS, edge centric IoT and Cloud. Each of the
> server-like Editions covers a destined, specific use case without
> overlapping.
> 
> For the desktop area I don’t see a non-overlapping use case between Gnome
> and KDE. It’s just a different tool for the same use case.

This exact argument was already used 10 years ago to reject our (that was 
before I left the KDE SIG, though this issue was one of the triggers for me 
leaving the SIG) request for a Plasma Edition. 10 years later, we still have 
no way out of this dilemma. The definition of an Edition needs to be refined 
or completely replaced to get out of this catch-22.

As part of the process to look for a non-overlapping use case, there was an 
attempt to focus specifically on scientific applications, which eventually 
lead to the Scientific Lab, but that did not make it to an Edition either, 
just to a Lab.

The overlap issue is also going to hinder other deliverables' efforts to 
become Editions. E.g., Silverblue mostly overlaps with Workstation and 
CoreOS: Workstation for the general use cases (workstation/desktop usage), 
CoreOS for the atomic and container-oriented use cases.

> And if we are willing to accept an exception and accept KDE desktop as an
> Edition, I don’t see that the current SIG qualifies as an edition-capable
> working group. Given the recent discussion about Wayland / X11, I don’t
> see any obligation/commitment to ensure long-term reliability and
> trouble-free usability. Instead, I see in the discussion an unbridled
> desire to introduce something new (that's good) without regard for
> backwards compatibility and uninterrupted usability (that's bad, we need
> both). And obviously the resources to manage both (Wayland and X11) in one
> working group are also lacking (and given the schism, possibly also the
> willingness to do so).

That particular concern, however, is one that I also share. The working 
group should be required to accept at least one of us plasma-workspace-x11 
maintainers (it can be Sérgio M. Basto or Steven A. Falco if they do not 
accept me) into the working group.

> That may change and can change, of course. But that’s nothing for F42,
> rather for F52.

It just requires creating a new working group. That can be done instantly.

> This is a failure to understand (or to commit to) what we have decided to
> do with Fedora.next. We don't want to DIY piece together a solution.

But one of the big strengths of Fedora is that you can do exactly that.

> And it is a plain false promise. You can't install CoreOS, IoT, silverblue
> with it, not even Server, which is offered in the menu (because a lot of
> presets are missing).

The presets thing is something that should be fixed. Maybe an entry "server 
presets" in the list of checkboxes that will install a metapackage that then 
uses boolean Requires to drag in the individual preset packages for whatever 
the user actually installs during or after the installation.

The inability to install an atomic system using Everything is inherent to 
what atomic systems are and what the Everything ISO is, and should be 
obvious to anyone who actually understands what they want to install.

>

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-05 Thread Kevin Kofler via devel

I wrote:
> That is exactly the problem with autotools code, almost nobody understands
> what the heck it does, almost everybody just copies and pastes somebody
> else's snippet hoping it does not do bad things. And gnulib is a
> particularly ugly piece of the puzzle.

PS: Here is a pretty good post summarizing the issues with autotools, both 
generally and in the context of the xz vulnerability:
https://felipec.wordpress.com/2024/04/04/xz-backdoor-and-autotools-insanity/

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Peter Boy

I'm probably not the right person to comment on this, because I completely 
abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That destroyed my 
daily workflow and work routines and made it unusable (for me), or at least 
barely usable for serious professional work not related to software development 
(and I ended up using MacOS to this day). 

But I have continued to use Fedora Server on all of our servers, have committed 
to the working group, and still consider Fedora a great distribution, 
regardless. 


So, nevertheless: 

> == Summary ==
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.


This is an absolute no-go! It would break everyone’s usage of Fedora 
Workstation and is in irreconcilable contradiction to the characteristics of an 
„Edition" as defined with Fedora.next. 

And that is not „just“ a technical issue (the FESCo domain), but a basic Fedora 
principle. 


Another proposal is to make it an „Edition“. But basically, a merely KDE 
Desktop is not „edition-able“. Among others, an edition is meant to cover a 
specific use case and a long-term and (more or less) perfectly designed and 
engineered solution for this. So we have desktop (Workstation) and server. 
Among server we have several Editions, the universal Fedora Server, container 
centric CoreOS, edge centric IoT and Cloud. Each of the server-like Editions 
covers a destined, specific use case without overlapping. 

For the desktop area I don’t see a non-overlapping use case between Gnome and 
KDE. It’s just a different tool for the same use case. 

And if we are willing to accept an exception and accept KDE desktop as an 
Edition, I don’t see that the current SIG qualifies as an edition-capable 
working group. Given the recent discussion about Wayland / X11, I don’t see any 
obligation/commitment to ensure long-term reliability and trouble-free 
usability. Instead, I see in the discussion an unbridled desire to introduce 
something new (that's good) without regard for backwards compatibility and 
uninterrupted usability (that's bad, we need both). And obviously the resources 
to manage both (Wayland and X11) in one working group are also lacking (and 
given the schism, possibly also the willingness to do so).  

That may change and can change, of course. But that’s nothing for F42, rather 
for F52.


> There are only two artifacts left on alt.fedoraproject.org that really
> need to be moved to the main site:
> 
> - the Everything netinstall ISO

This is a failure to understand (or to commit to) what we have decided to do 
with Fedora.next. We don't want to DIY piece together a solution.  

And it is a plain false promise. You can't install CoreOS, IoT, silverblue with 
it, not even Server, which is offered in the menu (because a lot of presets are 
missing). 

We should discard it from the website at all, or at least rename it to „All 
desktop offerings for DIY on your own risk“. And it really belongs to 
alt.fedoraproject.org  and under no 
circumstances on the main page, and certainly not on the editions. 



> Am 05.04.2024 um 00:17 schrieb Zbigniew Jędrzejewski-Szmek 
> :
> 
> ... 
> I’m not sure. I think the getfedora.o page could use some work, but
> just moving one or two things might not be enough. For me, when using
> the website is the huge list semi-orthogonal categories:
> the top-level split is:
>  - editions, as individual items
>  - atomic desktops
>  - spins
>  - labs
>  - alt downloads
> Alt downloads is split into:
>  - Fedora 40 beta
>  - network installer
>  - torrent downloads
>  - alternate architectures (even though download pages also have 
> architectures?)
>  - cloud base images
>  - testing images
>  - rawhide

This is really intentional. It is what we decided with Fedora.next and that 
resulted in a great success for Fedora. So we should really leave the structure 
as it is. 

> ...  
> And there are at least three domains:
> getfedora.org, fedoraproject.org, alt.fedoraproject.org.
> ... 
> This is hard to navigate. It seems that each subpage uses a different
> categorization and way to split things. And the different subpages
> use different visual styles.
> 
> I think we should have:
>  a) one domain

Basically, we have one domain *now*: fedoraproject.org 

getfedora.org is a backwards compatible forwarding of the old way of presenting 
fedora.

alt.fedoraproject.org is a subdomain, which is a widespread way to structure a 
huge and complex offering as Fedora. Similarly, we have e.g. 
calendar.fedoraproject.org or lists.fedoraproject.org  


>  b) a flat categorization where you first select the type
>  (one of the editions or the desktops or spins or labs or network
>  installer or cloud image).
> 
>  The editions should be listed prominently, and the other things can
>  lower in the page or require a click to show.

From a UX perspective, this is

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Neal Gompa

On Fri, Apr 5, 2024 at 3:03 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Apr 04, 2024 at 04:26:52PM -0700, Adam Williamson wrote:
> > On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote:
> > > On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote:
> > > > > So here are three brainstorming proposals:
> > > > >
> > > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to 
> > > > > be
> > > > > careful about how we do it. I would still promote Fedora Workstation 
> > > > > as the
> > > > > main/recommended "leading" desktop, would call Plasma an "alternative
> > > > > desktop option," and would strongly caution against use of the word
> > > > > "Workstation" anywhere in the branding for the Plasma version. That 
> > > > > is,
> > > > > let's continue to steer undecided users towards Fedora Workstation, 
> > > > > while
> > > > > making Plasma easier to find and presenting it more prominently than 
> > > > > it is
> > > > > today.
> > > >
> > > > I like this proposal. It would give the KDE spin more prominence and
> > > > would be a good reply to the huge work that has been put into the spin
> > > > in recent times. It also wouldn't disrupt our story about Fedora 
> > > > Workstation.
> > > >
> > > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be
> > > > confused with Fedora Workstation.
> > > >
> > >
> > > So, effectively no change other than it moves from the Spins section
> > > to the Editions section? That would also mean it should be on the
> > > front page too, like the other Editions.
> >
> > Being an Edition is a very significant thing, though, as we conceive of
> > Fedora more widely than just the download page. We put a bunch of hoops
> > in the way of IoT and CoreOS becoming editions, and there are hoops in
> > the way of Silverblue becoming one (or, you know, wherever we go with
> > that path in the end).
>
> My silent assumption was that the current change proposal would be
> withdrawn and replaced by a new proposal. We have a formal procedure in [1].
> Looking at that list, it seems all fine. The only sticky point is whether
> KDE desktop serves a different purpose than Workstation with GNOME.
> I'd say it does: desktop preferences are like religion, and people don't
> just switch (except when they do).
>
> [1] 
> https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/
>

I have asked that the proposal only be withdrawn once an alternative
arrangement has been successfully made[1]. I don't expect it to be
withdrawn until that is figured out, since Matthew Miller didn't
promise anything to resolve the underlying request to make Fedora KDE
Plasma Desktop as visible as Fedora GNOME Workstation[2].

[1]: https://discussion.fedoraproject.org/t/111343/44
[2]: https://discussion.fedoraproject.org/t/111343/41



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Vít Ondruch



Dne 04. 04. 24 v 17:32 Kevin Kofler via devel napsal(a):

Neal Gompa wrote:

By default, GNOME only presents the close window button. The other
buttons are missing, and there isn't really an intuitive way to
discover the other window management actions.



I agree that there are no other buttons. But still, Gnome opens the 
windows in normalized state, not maximized what was the original claim.




In the version I tried, and judging from end user reports, for several
years, it did not even present that, leading to fun issues such as some KDE
dialogs that could not be closed at all (because they were missing a "Close"
button and relying on the window decoration exclusively).



I have never seen Gnome / Gtk app without "Close" button. I can imagine 
that there likely can be issue for some non-Gtk app. I don't know.


In any case, I prefer to use Gtk apps for Gnome and I assume this is the 
case for Gnome users. Similarly I won't be surprised if KDE users prefer 
QT apps. Mixing the DE and frameworks might not always work without 
issues. And this is not just about Gtk / Qt and Gnome / KDE. E.g. Java 
apps might look out of place on both DEs.



Vít




OpenPGP_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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Issues with pytest and python-pytest-postgresql

2024-04-05 Thread Mikel Olasagasti

Hi Lumir,

Hau idatzi du Lumír Balhar (lbal...@redhat.com) erabiltzaileak (2024
api. 4(a), og. (09:57)):
>
> It might look like simple bump but you are upgrading from 4.1.1 to 6.0.0
> and there are some breaking changes between those releases.

By "simple bump" I meant no other changes in the spec. I agree with
you the update  is not that "simple".


> The error message looks like the plugin is loaded twice for some reason
> and the second try to register the same CLI option fails. %pytest macro
> sets PYTHONPATH so it's possible that the plugin is first loaded from
> buildroot and then from the current working directory or vice-versa. I
> also see some settings for pytest in pyproject.toml you might want to
> take a look.

I found how to fix and it's a mix of what you suggest and pytest params.

I had to add "-p no:postgresql" to %pytest to avoid loading the
installed module, but also had to do changes in the pyproject.toml
file.

I documented in the commit I pushed:

https://src.fedoraproject.org/rpms/python-pytest-postgresql/c/4756bd60d23908b86f81ca25d551fa22835c83ac?branch=rawhide

Best regards,
Mikel
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SPDX] Mass license change EUPL 1.2 to EUPL-1.2

2024-04-05 Thread Miroslav Suchý


Hi.

I am going to do the mass change of the license from EUPL 1.2 to EUPL-1.2.

The proposed diff is in attachment.

Affected packages:

AusweisApp2
rust-tpm2-policy
dbus-parsec

Unless somebody stop me, I will do this change directly in dist-git after a 
week.

I have the tooling in place. Very likely, I will announce more licenses for 
migration next time.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
diff -Naur rpm-specs.orig/AusweisApp2.spec rpm-specs/AusweisApp2.spec
--- rpm-specs.orig/AusweisApp2.spec	2024-04-04 04:01:05.0 +0200
+++ rpm-specs/AusweisApp2.spec	2024-04-05 10:37:43.494615583 +0200
@@ -45,7 +45,7 @@
 Release:  %autorelease
 Summary:  %{pkg_sum}
 
-License:  EUPL 1.2
+License:  EUPL-1.2
 URL:  https://www.ausweisapp.bund.de/en
 
 # Url to releases on github.
diff -Naur rpm-specs.orig/dbus-parsec.spec rpm-specs/dbus-parsec.spec
--- rpm-specs.orig/dbus-parsec.spec	2024-01-25 03:04:22.0 +0100
+++ rpm-specs/dbus-parsec.spec	2024-04-05 10:37:45.781631426 +0200
@@ -5,10 +5,10 @@
 
 Name:  dbus-parsec
 Version:   0.4.0
-Release:   7%{?dist}
+Release:   8%{?dist}
 Summary:   DBus PARSEC interface
 
-License:   EUPL 1.2
+License:   EUPL-1.2
 URL:   https://github.com/fedora-iot/dbus-parsec
 Source:%{url}/archive/v%{version}/%{name}-%{version}.tar.gz
 
@@ -59,6 +59,9 @@
 %{_unitdir}/dbus-parsec.service
 
 %changelog
+* Fri Apr 05 2024 Miroslav Suchý  - 0.4.0-8
+- convert license to SPDX
+
 * Wed Jan 24 2024 Fedora Release Engineering  - 0.4.0-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
 
diff -Naur rpm-specs.orig/rust-tpm2-policy.spec rpm-specs/rust-tpm2-policy.spec
--- rpm-specs.orig/rust-tpm2-policy.spec	2024-01-31 03:47:10.0 +0100
+++ rpm-specs/rust-tpm2-policy.spec	2024-04-05 10:37:44.749624277 +0200
@@ -5,11 +5,11 @@
 
 Name:   rust-%{crate}
 Version:0.6.0
-Release:7%{?dist}
+Release:8%{?dist}
 Summary:Specify and send TPM2 policies to satisfy object authorization
 
 # Upstream license specification: EUPL-1.2
-License:EUPL 1.2
+License:EUPL-1.2
 URL:https://crates.io/crates/tpm2-policy
 Source: %{crates_source}
 Patch0: tpm2-policy-fix-metadata.diff
@@ -67,6 +67,9 @@
 %endif
 
 %changelog
+* Fri Apr 05 2024 Miroslav Suchý  - 0.6.0-8
+- convert license to SPDX
+
 * Tue Jan 30 2024 Peter Robinson  - 0.6.0-7
 - Fix build
 
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora-IoT 40 RC 20240405.0 nightly compose nominated for testing

2024-04-05 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 40 RC 20240405.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/40iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_40_RC_20240405.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_40_RC_20240405.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

2024-04-05 Thread Miroslav Suchý


Dne 28. 03. 24 v 12:40 odp. Miroslav Suchý napsal(a):


I will do the change only for:

./bitstream-vera-fonts.spec:License: Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./bpg-fonts.spec:License:   Bitstream Vera
./R-fontBitstreamVera.spec:License:  Bitstream Vera


This has been done. Full diff of the change is in the attachment.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
diff -Naur rpm-specs.orig/bitstream-vera-fonts.spec rpm-specs/bitstream-vera-fonts.spec
--- rpm-specs.orig/bitstream-vera-fonts.spec	2024-04-04 04:01:29.0 +0200
+++ rpm-specs/bitstream-vera-fonts.spec	2024-04-05 09:09:25.602039908 +0200
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: MIT
 Version: 1.10
-Release: 50%{?dist}
-License: Bitstream Vera
+Release: 51%{?dist}
+License: Bitstream-Vera
 URL: http://www.gnome.org/fonts/
 
 BuildArch: noarch
@@ -88,6 +88,9 @@
 %fontfiles -a
 
 %changelog
+* Fri Apr 05 2024 Miroslav Suchý  - 1.10-51
+- convert license to SPDX
+
 * Tue Jan 23 2024 Fedora Release Engineering  - 1.10-50
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
 
diff -Naur rpm-specs.orig/bpg-fonts.spec rpm-specs/bpg-fonts.spec
--- rpm-specs.orig/bpg-fonts.spec	2024-02-21 03:02:00.0 +0100
+++ rpm-specs/bpg-fonts.spec	2024-04-05 09:09:27.174053011 +0200
@@ -7,7 +7,7 @@
 Name:		%{fontname}-fonts
 Summary: 	Georgian Unicode fonts
 Version:	%{common_ver}
-Release:	25%{?dist}
+Release:	26%{?dist}
 # Font exception
 # See: http://groups.google.com/group/bpg-fonts/web/gpl-gnu-license
 # No version of the GPL is specified.
@@ -196,7 +196,7 @@
 %package -n %{fontname}-dejavu-sans-fonts
 Summary:	DejaVu Sans with BPG Georgian changes
 Version:	2017.2.005
-License:	Bitstream Vera
+License:	Bitstream-Vera
 Requires:	%{name}-common = %{common_ver}-%{release}
 
 %description -n %{fontname}-dejavu-sans-fonts
@@ -211,7 +211,7 @@
 %package -n %{fontname}-dejavu-sans-mono-fonts
 Summary:	DejaVu Sans Mono with BPG Georgian changes
 Version:	2017.3.003
-License:	Bitstream Vera
+License:	Bitstream-Vera
 Requires:	%{name}-common = %{common_ver}-%{release}
 
 %description -n %{fontname}-dejavu-sans-mono-fonts
@@ -226,7 +226,7 @@
 %package -n %{fontname}-dejavu-serif-fonts
 Summary:	DejaVu Serif with BPG Georgian changes
 Version:	2017.2.37
-License:	Bitstream Vera
+License:	Bitstream-Vera
 Requires:	%{name}-common = %{common_ver}-%{release}
 
 %description -n %{fontname}-dejavu-serif-fonts
@@ -256,7 +256,7 @@
 Summary:	Excelsior family of BPG Georgian fonts
 Version:	2.03
 Requires:	%{name}-common = %{common_ver}-%{release}
-License:	Bitstream Vera
+License:	Bitstream-Vera
 
 %description -n %{fontname}-excelsior-fonts
 %common_desc
@@ -270,7 +270,7 @@
 Summary:	Excelsior Caps family of BPG Georgian fonts
 Version:	2.003
 Requires:	%{name}-common = %{common_ver}-%{release}
-License:	Bitstream Vera
+License:	Bitstream-Vera
 
 %description -n %{fontname}-excelsior-caps-fonts
 %common_desc
@@ -284,7 +284,7 @@
 Summary:	Excelsior Condenced family of BPG Georgian fonts
 Version:	2.003
 Requires:	%{name}-common = %{common_ver}-%{release}
-License:	Bitstream Vera
+License:	Bitstream-Vera
 
 %description -n %{fontname}-excelsior-condenced-fonts
 %common_desc
@@ -489,7 +489,7 @@
 %package -n %{fontname}-sans-modern-fonts
 Summary:	Sans Modern family of BPG Georgian fonts
 Version:	2.025
-License:	Bitstream Vera
+License:	Bitstream-Vera
 Requires:	%{name}-common = %{common_ver}-%{release}
 
 %description -n	%{fontname}-sans-modern-fonts
@@ -529,7 +529,7 @@
 %package -n %{fontname}-serif-modern-fonts
 Summary:	Serif Modern family of BPG Georgian fonts
 Version:	2.028
-License:	Bitstream Vera
+License:	Bitstream-Vera
 Requires:	%{name}-common = %{common_ver}-%{release}
 
 %description -n %{fontname}-serif-modern-fonts
@@ -708,6 +708,9 @@
 %doc Docs/*
 
 %changelog
+* Fri Apr  5 2024 Miroslav Suchý  - 3.300-26
+- convert license to SPDX
+
 * Tue Jan 23 2024 Fedora Release Engineering  - 20120413-25
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
 
diff -Naur rpm-specs.orig/R-fontBitstreamVera.spec rpm-specs/R-fontBitstreamVera.spec
--- rpm-specs.orig/R-fontBitstreamVera.spec	2024-01-23 03:39:54.0 +0100
+++ rpm-specs/R-fontBitstreamVera.spec	2024-04-05 09:09:28.162061246 +0200
@@ -4,10 +4,10 @@
 
 Name: R-%{packname}
 Version:  0.1.1
-Release:  20%{?dist}
+Release:  21%{?dist}
 Summary:  Fonts with 'Bitstream Vera Fonts' License
 
-License:  Bitstream Vera
+License:  Bitstream-Vera
 URL:  https://CRAN.R-project.org/package=%{packname}
 Source0:

Re: "fedpkg local" builds fail for rust packages

2024-04-05 Thread Michael J Gruber

Fabio Valentini venit, vidit, dixit 2024-04-04 22:41:19:
> On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel
>  wrote:
> >
> > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > > > The short answer is: No, "fedpkg local" is not expected to work for
> > > > > Rust packages, and probably won't ever work as expected for Rust
> > > > > packages.
> > > > >
> > > > > I am not really interested in adding the "--allow-dirty" flag (not
> > > > > sure if it would even work in this case), since building Rust packages
> > > > > with "fedpkg local" is not working for other reasons. Primarily,
> > > > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > > > this is only supported when building in mock.
> > >
> > > > I don't know what you mean? For me after patching the macro locally
> > > > local builds work as expected. Maybe I'm overlooking something?
> > >
> > > You might be lucky and just tried to package a Rust crate with no
> > > dependencies?
> > > Dependencies on other Rust crates are only resolved dynamically at build
> > > time, which "fedpkg local" does not support. So it works "by accident" for
> > > Rust crates with no crate dependencies, but in general, it can't work.
> >
> > That would have been extremely lucky, but no, I'm building crates with
> > dependencies. And the build generates the requires list just fine.
> >
> > What is not possible is installing build dependencies directly from a
> > spec file from a fresh clone, if that is what you mean? But in this case
> > running a local build generates a `.buildreqs.nosrc.rpm` file with the
> > correct dependencies, which can be passed to `dnf builddep`.
> >
> > And since a local build does not manage build dependencies themselves,
> > rather relies on them just being there, I don't really see an issue in
> > that?
> 
> If you really don't mind jumping through multiple hoops just because
> you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
> guess I can't stop you.
> 
> All I *can* do is tell you that you're not going to like the experience:
> 
> - Using "fedpkg local" is not supported for Rust packages, and I won't
> be adding workarounds to the Rust macros for it.
> - Installing rust-*-devel packages on your local system (i.e. outside
> of ephemeral build environments) is not supported.
> - The "rust-*-devel" packages are build system implementation details,
> if you want to say it like that.
> - They are not shipped to users and are not useful for Rust developers.
> - They are *only* intended to be installed in temporary chroots (like
> those set up by mock).
> - They don't get "Obsoletes" or "Provides" in case there are dropped
> subpackages and / or incompatible updates. This is not an issue
> because they are only ever *installed*, but never supposed to be
> *upgraded* in-place. Any issues you get by installing them on your
> host system are your own.

So you're saying that those packages are in the repos for everyone but
not meant to be installed by anyone (besides mock chroots), and that is
how and why they are packaged.

`This package contains library source intended for building other packages which
use the "xyz" crate.`

Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
mockbuild` it. Does a rebuild from `fedpkg srpm` even work?

Wow!

Is there any other set of packages which we package like that?

If that is how you do things for the rust eco-system, those "devel"
packages should be clearly distinguished from real development packages,
come with a huge boiler plate "do not install" - or, really, be in a
separate repo if installing them is both worthless and misleading for
any "real" user. CRB for Fedora material.

Michael
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-05 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Apr 04, 2024 at 04:26:52PM -0700, Adam Williamson wrote:
> On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote:
> > On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > 
> > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote:
> > > > So here are three brainstorming proposals:
> > > > 
> > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be
> > > > careful about how we do it. I would still promote Fedora Workstation as 
> > > > the
> > > > main/recommended "leading" desktop, would call Plasma an "alternative
> > > > desktop option," and would strongly caution against use of the word
> > > > "Workstation" anywhere in the branding for the Plasma version. That is,
> > > > let's continue to steer undecided users towards Fedora Workstation, 
> > > > while
> > > > making Plasma easier to find and presenting it more prominently than it 
> > > > is
> > > > today.
> > > 
> > > I like this proposal. It would give the KDE spin more prominence and
> > > would be a good reply to the huge work that has been put into the spin
> > > in recent times. It also wouldn't disrupt our story about Fedora 
> > > Workstation.
> > > 
> > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be
> > > confused with Fedora Workstation.
> > > 
> > 
> > So, effectively no change other than it moves from the Spins section
> > to the Editions section? That would also mean it should be on the
> > front page too, like the other Editions.
> 
> Being an Edition is a very significant thing, though, as we conceive of
> Fedora more widely than just the download page. We put a bunch of hoops
> in the way of IoT and CoreOS becoming editions, and there are hoops in
> the way of Silverblue becoming one (or, you know, wherever we go with
> that path in the end).

My silent assumption was that the current change proposal would be
withdrawn and replaced by a new proposal. We have a formal procedure in [1].
Looking at that list, it seems all fine. The only sticky point is whether
KDE desktop serves a different purpose than Workstation with GNOME.
I'd say it does: desktop preferences are like religion, and people don't
just switch (except when they do).

[1] 
https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/

Zbyszek
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2273751] New: perl-Imager-1.024 is available

Re: "fedpkg local" builds fail for rust packages

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[EPEL-devel] Fedora EPEL 7 updates-testing report

[Bug 2272408] perl-PDL-2.087 is available

F41 Change Proposal: Pytest 8 (self-contained)

F41 Change Proposal: Pytest 8 (self-contained)

Fedora Linux 40 Blocker Bug Summary Report: 2024-04-05

[Bug 2273691] perl-Test-mysqld-1.0020 is available

[Bug 2273691] New: perl-Test-mysqld-1.0020 is available

[Bug 2273691] perl-Test-mysqld-1.0020 is available

Re: [Fedocal] Reminder meeting : ELN SIG

Introduction and Application for Sponsorship

Re: "fedpkg local" builds fail for rust packages

Fedora 40 compose report: 20240405.n.0 changes

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: "fedpkg local" builds fail for rust packages

Re: "fedpkg local" builds fail for rust packages

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: "fedpkg local" builds fail for rust packages

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: Three steps we could take to make supply chain attacks a bit harder

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Re: Issues with pytest and python-pytest-postgresql

[SPDX] Mass license change EUPL 1.2 to EUPL-1.2

[Test-Announce] Fedora-IoT 40 RC 20240405.0 nightly compose nominated for testing

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

Re: "fedpkg local" builds fail for rust packages

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

36 matches

Site Navigation

Mail list logo

Footer information