Re: SPDX Change update

[Petr Pisar]

V Mon, Nov 14, 2022 at 11:01:54AM -0500, Michel Alexandre Salim napsal(a):
> To clarify -- while SPDX license strings are not valid for RHEL 9, are
> they valid for EPEL 9?
> 
Yes. Fedora packaging guidelines also apply to EPEL.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX - How to handle MIT and BSD

[Petr Pisar]

V Mon, Nov 14, 2022 at 08:53:09PM +0100, Miroslav Suchý napsal(a):
> There are two common ways to find out what SPDX identifier you should use in 
> such cases.
> 
> 
> 1) You can use https://github.com/spdx/spdx-license-diff and use it to
> identify your license. This is a Chrome and Firefox plugin and allows you to
> select the text; and in the context menu, you can choose to identify the
> license. It will print, e.g., that it matches 60% of the MIT-feh license and
> highlight the difference. Or...
> 
> 
> 2) you can navigate to
> 
> https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
> 
> in the search box above the first table, you enter your license and filter
> the content. If you enter "MIT", it will find you 26 licenses. Out of them,
> 15 have "MIT" in the "Fedora abbreviation" column (Hmm, this should be
> changed to "legacy name"). Now you have to open the link in the "URL" column
> and find your package's license. This may look painful, but you usually find
> the correct license within a few clicks.
> 
>
SPDX has a web page  which can help
identify a license. It works to some degree. E.g. it operates on license
texts. Not on license declarations. It also requires the license without
a context. E.g. without warranty disclaimers. Without programming laguage
comment markers.

Though I usually resort to opening all MIT-like licenses, "X11" is one of
them, from an SPDX license list  and comparing
them against my license.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)

[Kamil Paral]

On Mon, Nov 14, 2022 at 10:34 PM Ben Cotton  wrote:

> We currently don't use the initial-setup application in the main KDE
> Spin and Kinoite installation ISOs as everything gets configured at
> installation time via Anaconda.


While that's true, wouldn't it make sense to adjust Anaconda to require a
regular admin user created during installation? Because currently you
either need to set root password or create a regular admin user in
Anaconda, and if you only set up root, you're offered to create the regular
user in the initial-setup. If you drop initial-setup, that workflow is not
possible anymore. According to our recent conversation in the kde list, it
seems you'd like to make sure a regular admin user gets created every time.
I think it would make sense to configure Anaconda this way at the same time
as initial-setup is dropped.
___
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: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Miro Hrončok]

On 15. 11. 22 0:03, Kevin Kofler via devel wrote:

(Though actually, would %global __provides_exclude_from … together with a
manual Provides: python3dist(…) = 0 not work?)


I believe that %__provides_exclude_from would actually work.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX - How to handle MIT and BSD

[Daniel P . Berrangé]

On Mon, Nov 14, 2022 at 08:53:09PM +0100, Miroslav Suchý wrote:
> MIT and BSD are very common licenses and can be tricky to convert to SPDX
> license identifiers. Just today, I got two questions about it. We have this
> covered in FAQ
> 
> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#I_have_a_package_with_BSD_or_MIT_in_the_License_field,_how_do_I_convert_that?
> 
> But still, it can be confusing. So let me explain more verbosely than we have 
> in the FAQ.
> 
> 
> You have a package that is licensed under the "MIT" license. So you run
> 
> 
> ```
> 
> $ license-fedora2spdx *'*MIT*'*
> Warning: more options how to interpret MIT. Possible options: ['mpich2',
> 'libtiff', 'SMLNJ', 'SGI-B-2.0', 'NTP', 'MIT', 'MIT-open-group', 'MIT-feh',
> 'MIT-enna', 'MIT-Modern-Variant', 'MIT-CMU', 'ICU', 'HPND', 'BSL-1.0',
> 'Adobe-Glyph']
> 
> Adobe-Glyph

Interestingly when I run  'license-fedora2spdx MIT' is just
always prints 'mpich2', and the list of suggestions is entirely
reversed from what you show here. Why 'mpich2' - it is simply
because it is last in the list to be loaded. This is rather
misleading and unhelpful IMHO.

> ```
> 
> 
> Can you choose any license from the output? No. Definitely no.

In that case, IMHO, the tool should NOT suggest a license from the
list at all, and definitely not arbitrarily suggest the last one it
loaded, which is highly likely to be wrong. If it wants to suggest,
then suggest the most likely option out of the variants.  Or can it
suggest an intentionally invalid placeholder eg "{MIT choice}" to
make it explicit that the maintainer has to actively make a choice.

$ license-fedora2spdx  "(GPLv2 or MIT or BSD)"
Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 
'BSL-1.0', 'BSL-1.0', 'HPND', 'HPND', 'ICU', 'MIT-CMU', 'MIT-Modern-Variant', 
'MIT-enna', 'MIT-feh', 'MIT-open-group', 'MIT', 'NTP', 'SGI-B-2.0', 'SMLNJ', 
'SMLNJ', 'libtiff', 'libtiff', 'mpich2']
Warning: more options how to interpret BSD. Possible options: 
['BSD-2-Clause-FreeBSD', 'BSD-2-Clause-Views', 'BSD-2-Clause', 'BSD-3-Clause', 
'BSD-3-Clause', 'BSD-3-Clause', 'BSD-3-Clause']
( GPL-2.0-only OR {{pick MIT choice}} OR {{pick BSD choice}} )


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)

[Timothée Ravier]

We'll need to investigate this option. I've added it in 
https://pagure.io/fedora-kde/SIG/issue/243
___
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: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)

[Timothée Ravier]

Good point. We'll have to do that indeed.
___
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 rawhide compose report: 20221115.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221114.n.0
NEW: Fedora-Rawhide-20221115.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  10
Dropped packages:39
Upgraded packages:   99
Downgraded packages: 0

Size of added packages:  7.40 MiB
Size of dropped packages:2.39 MiB
Size of upgraded packages:   3.35 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: chibi-scheme-0.10.0-1.fc38
Summary: Minimal Scheme implementation for use as an extension language
RPMs:chibi-scheme chibi-scheme-devel
Size:4.62 MiB

Package: cmrc-2.0.1-1.fc38
Summary: Standalone CMake-Based C++ Resource Compiler
RPMs:cmrc-devel
Size:17.44 KiB

Package: crosswords-puzzle-sets-pzzl-3.1-1.fc38
Summary: Dutch puzzle sets from pzzl.net for GNOME Crosswords
RPMs:crosswords-puzzle-sets-pzzl
Size:11.56 KiB

Package: obs-service-cargo_vendor-0.4.3-1.fc38
Summary: An OBS source service: Download, verify and vendor Rust crates 
(libraries)
RPMs:obs-service-cargo_vendor
Size:17.90 KiB

Package: perl-Type-Tiny-XS-0.025-2.fc38
Summary: Provides an XS boost for some of Type::Tiny's built-in type constraints
RPMs:perl-Type-Tiny-XS
Size:173.65 KiB

Package: pico-wizard-0.1.0^git20220929.934dbcf-1.fc38
Summary: Post-installation configuration wizard
RPMs:pico-wizard
Size:156.56 KiB

Package: rust-libadwaita-sys-0.1.0-2.fc38
Summary: FFI bindings for libadwaita
RPMs:rust-libadwaita-sys+default-devel rust-libadwaita-sys+dox-devel 
rust-libadwaita-sys-devel
Size:38.55 KiB

Package: rust-rustdct-0.7.1-1.fc38
Summary: Compute Discrete Cosine Transforms (DCT) in O(nlogn) time
RPMs:rust-rustdct+default-devel rust-rustdct-devel
Size:60.37 KiB

Package: rust-sequoia-policy-config-0.4.0-1.fc38
Summary: Configure Sequoia using a configuration file
RPMs:rust-sequoia-policy-config+default-devel 
rust-sequoia-policy-config-devel sequoia-policy-config
Size:2.25 MiB

Package: rust-uriparse-0.6.4-1.fc38
Summary: URI parser including relative references
RPMs:rust-uriparse+default-devel rust-uriparse+serde-devel 
rust-uriparse-devel
Size:62.56 KiB


= DROPPED PACKAGES =
Package: drupal7-active_tags-2.0-0.23.alpha1.fc37
Summary: Enhanced tag widget for free tagging vocabularies
RPMs:drupal7-active_tags
Size:18.92 KiB

Package: drupal7-admin_language-1.0-9.fc37
Summary: Displays administration pages in preferred language
RPMs:drupal7-admin_language
Size:24.78 KiB

Package: drupal7-backup_migrate-3.10-1.fc38
Summary: Backup the Drupal database and files or migrate them to another 
environment
RPMs:drupal7-backup_migrate
Size:115.64 KiB

Package: drupal7-boxes-1.2-16.fc37
Summary: Provides exports for custom blocks and spaces integration
RPMs:drupal7-boxes
Size:34.31 KiB

Package: drupal7-cck-3.0-0.17.alpha3.fc37
Summary: Miscellaneous field functions not handled by core
RPMs:drupal7-cck
Size:38.24 KiB

Package: drupal7-chosen-2.1-13.fc37
Summary: Makes select elements more user-friendly using Chosen
RPMs:drupal7-chosen
Size:23.98 KiB

Package: drupal7-crumbs-2.7-9.fc37
Summary: The ultimate breadcrumbs module
RPMs:drupal7-crumbs
Size:130.28 KiB

Package: drupal7-domain-3.17-7.fc37
Summary: A domain-based access control system
RPMs:drupal7-domain
Size:155.53 KiB

Package: drupal7-domain_locale-1.0-0.22.beta6.fc37
Summary: Adds language handling functionality per domain basis
RPMs:drupal7-domain_locale
Size:25.91 KiB

Package: drupal7-domain_views-1.5-19.fc37
Summary: Provides Views integration for Domain Access
RPMs:drupal7-domain_views
Size:31.47 KiB

Package: drupal7-drafty-1.0-0.16.rc1.fc37
Summary: Facilitates handling of draft revisions
RPMs:drupal7-drafty
Size:33.81 KiB

Package: drupal7-drush_language-1.6-0.8.rc3.fc37
Summary: Drush language commands
RPMs:drupal7-drush_language
Size:21.61 KiB

Package: drupal7-ds-2.16-9.fc37
Summary: Extend the display options for every entity type
RPMs:drupal7-ds
Size:152.68 KiB

Package: drupal7-eva-1.4-11.fc37
Summary: Provides a Views display type that can be attached to entities
RPMs:drupal7-eva
Size:23.10 KiB

Package: drupal7-features_extra-1.0-15.fc37
Summary: Provides faux exportables of several site-building components
RPMs:drupal7-features_extra
Size:35.42 KiB

Package: drupal7-fences-1.2-15.fc37
Summary: Configurable field wrappers
RPMs:drupal7-fences
Size:46.74 KiB

Package: drupal7-field_permissions-1.1-8.fc37
Summary: Set field-level permissions to create, update or view fields
RPMs:drupal7-field_permissions
Size:32.91 KiB

Package: drupal7-i18n_boxes-1.0-19.fc37
Summary: Provides the ability to localize Boxes blocks
RPMs:drupal7-i18n_boxes
Size:17.39 KiB

Package: drupal7-l10n_client-1.3-17

Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

> == Summary ==
> 
> We currently don't use the initial-setup application in the main KDE
> Spin and Kinoite installation ISOs as everything gets configured at
> installation time via Anaconda. We thus want to remove this package
> from the installation ISOs while keeping it where we currently need it
> (pre-installed disk images, etc.). Note that an "initial setup" app is
> still needed to enable OEM-style installations
> (https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-linux-distributions)
> of the KDE Spin/Kinoite (like Fedora Workstation/Silverblue) so we're
> planning on introducing a more KDE native application as a replacement
> once it is ready, but that may not not happen as part of this change.

For clarity, please add a sentence at the beginning of this text that
explains what initial-setup is and what it does.

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

Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 10, 2022 at 03:24:07PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
> 
> 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 ==
> 
> By design, ostree does not manage bootloader updates as they can not
> (yet) happen in a transactional, atomic and safe fashion. Thus bootupd
> (https://github.com/coreos/bootupd) was created to solve this issue
> and enable admin-lead bootloader updates. This change is about
> enabling bootupd integration in Fedora Silverblue and Fedora Kinoite
> to make bootloader updates easier.

This is missing a sentence that actually says what "bootupd" is and does.

Also "admin-lead" → "admin-led". (Though "admin-controlled" would be
probably better.)

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

Re: SPDX - How to handle MIT and BSD

[Miro Hrončok]

On 14. 11. 22 20:53, Miroslav Suchý wrote:
1) You can use https://github.com/spdx/spdx-license-diff and use it to identify 
your license. This is a Chrome and Firefox plugin and allows you to select the 
text; and in the context menu, you can choose to identify the license. It will 
print, e.g., that it matches 60% of the MIT-feh license and highlight the 
difference. Or...


Do we have a command line tool for this? Does licensecheck support SPDX 
identifiers?


(I find the use of browser extension for this very weird. I have the LICENSE 
file unpackaged with the sources on my machine, I am not browsing it on the web.)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Karolina Surma]

On 11/15/22 08:37, Mattia Verga via devel wrote:
> Il 15/11/22 00:23, Neal Gompa ha scritto:
>> On Mon, Nov 14, 2022 at 6:03 PM Kevin Kofler via devel
>>  wrote:
>>> So let me sum up:
>>>
 Some Python building backends, eg. setuptools, explicitly allow
 creating package with version `0.0.0` when the version used by a
 project is not known. This was
 [https://github.com/pypa/setuptools/issues/2329 discussed upstream]
 with conclusion that it's an intended behavior.
>>> Upstream says that it is intended that packages are able to set their
>>> version to 0 or 0.0.0, but…
>>>
 Based on discussion on python-devel mailing list there will be no way
 to opt out from this change. There will be no possibility to package a
 Python package with version `0`.
>>> … your proposed Change will fail those packages' build with no opt-out!? You
>>> cannot be serious!
>>>
>>> (Though actually, would %global __provides_exclude_from … together with a
>>> manual Provides: python3dist(…) = 0 not work?)
>>>
>>> A clear -1 to this Change as proposed.
>>>
 We've never encountered a situation when packaging the version `0` was
 the package maintainers intention.
>>> What if it is the *upstream* maintainer's intention? Are we now dictating
>>> versioning schemes on upstream projects, disallowing version numbers that
>>> upstream setuptools explicitly considers valid?
>>>
>> Unfortunately, I have to agree here. Nobody said we should be
>> dictating the versions for people. PEP-440 does not even make 0
>> version illegal, so this is unnecessarily punishing.
>>
> IMO, the policy is right, it just have to allow to opt out, so that the
> maintainer is informed that **there could be** something wrong with the
> package metadata / build process. Maybe an opt-out + file a ticket in BZ
> to have track of the opt out, just like the ExcludeArch is the right
> approach.
> 
> Mattia
> 

Hello,

The standard invocation of the Python dependency generator will be
changed to always run with option like `--fail-if-version-zero`. (This
is the subject of the current proposal.)

Based on your concerns, an opt out mechanism would be added:
If you wanted to bypass the option, you could define a macro in the
specfile, eg.
`%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`

This would allow to build RPMs without bothering with versions. Also, if
it's upstream's decision to use version 0, that would be the way to go.
In Fedora this would give us an insight into how often this is needed.

What do you think of enhancing the proposal this way?

Karolina Surma
___
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: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 15, 2022 at 12:35:32PM +0100, Karolina Surma wrote:

On 11/15/22 08:37, Mattia Verga via devel wrote:

Il 15/11/22 00:23, Neal Gompa ha scritto:

On Mon, Nov 14, 2022 at 6:03 PM Kevin Kofler via devel
 wrote:

So let me sum up:


Some Python building backends, eg. setuptools, explicitly allow
creating package with version `0.0.0` when the version used by a
project is not known. This was
[https://github.com/pypa/setuptools/issues/2329 discussed upstream]
with conclusion that it's an intended behavior.

Upstream says that it is intended that packages are able to set their
version to 0 or 0.0.0, but…


Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility to package a
Python package with version `0`.

… your proposed Change will fail those packages' build with no opt-out!? You
cannot be serious!

(Though actually, would %global __provides_exclude_from … together with a
manual Provides: python3dist(…) = 0 not work?)

A clear -1 to this Change as proposed.


We've never encountered a situation when packaging the version `0` was
the package maintainers intention.

What if it is the *upstream* maintainer's intention? Are we now dictating
versioning schemes on upstream projects, disallowing version numbers that
upstream setuptools explicitly considers valid?


Unfortunately, I have to agree here. Nobody said we should be
dictating the versions for people. PEP-440 does not even make 0
version illegal, so this is unnecessarily punishing.


IMO, the policy is right, it just have to allow to opt out, so that the
maintainer is informed that **there could be** something wrong with the
package metadata / build process. Maybe an opt-out + file a ticket in BZ
to have track of the opt out, just like the ExcludeArch is the right
approach.

Mattia



Hello,

The standard invocation of the Python dependency generator will be
changed to always run with option like `--fail-if-version-zero`. (This
is the subject of the current proposal.)

Based on your concerns, an opt out mechanism would be added:
If you wanted to bypass the option, you could define a macro in the
specfile, eg.
`%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`

This would allow to build RPMs without bothering with versions. Also, if
it's upstream's decision to use version 0, that would be the way to go.
In Fedora this would give us an insight into how often this is needed.

What do you think of enhancing the proposal this way?


I wonder how many Python packages have ever been packaged with version 
0. Are we trying to solve a problem that doesn't exist?


Semver recommends[1] starting at 0.1.0 and without proof I think today 
most packages start by following semver. Any old packages that predate 
semver have a version > 0 by now.


[1]: 
https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase
___
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 - How to handle MIT and BSD

[Neal Gompa]

On Tue, Nov 15, 2022 at 6:24 AM Miro Hrončok  wrote:
>
> On 14. 11. 22 20:53, Miroslav Suchý wrote:
> > 1) You can use https://github.com/spdx/spdx-license-diff and use it to 
> > identify
> > your license. This is a Chrome and Firefox plugin and allows you to select 
> > the
> > text; and in the context menu, you can choose to identify the license. It 
> > will
> > print, e.g., that it matches 60% of the MIT-feh license and highlight the
> > difference. Or...
>
> Do we have a command line tool for this? Does licensecheck support SPDX
> identifiers?
>
> (I find the use of browser extension for this very weird. I have the LICENSE
> file unpackaged with the sources on my machine, I am not browsing it on the 
> web.)
>

licensecheck supports SPDX, you just have to run it with
"--shortname-scheme spdx".



-- 
真実はいつも一つ！/ 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: SPDX - How to handle MIT and BSD

[Miroslav Suchý]

Dne 15. 11. 22 v 10:44 Daniel P. Berrangé napsal(a):

Interestingly when I run  'license-fedora2spdx MIT' is just
always prints 'mpich2', and the list of suggestions is entirely
reversed from what you show here. Why 'mpich2' - it is simply
because it is last in the list to be loaded. This is rather
misleading and unhelpful IMHO.

Yes. Just first one in the list.


In that case, IMHO, the tool should NOT suggest a license from the
list at all, and definitely not arbitrarily suggest the last one it
loaded, which is highly likely to be wrong. If it wants to suggest,
then suggest the most likely option out of the variants.  Or can it
suggest an intentionally invalid placeholder eg "{MIT choice}" to
make it explicit that the maintainer has to actively make a choice.

$ license-fedora2spdx  "(GPLv2 or MIT or BSD)"
Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 
'BSL-1.0', 'BSL-1.0', 'HPND', 'HPND', 'ICU', 'MIT-CMU', 'MIT-Modern-Variant', 
'MIT-enna', 'MIT-feh', 'MIT-open-group', 'MIT', 'NTP', 'SGI-B-2.0', 'SMLNJ', 
'SMLNJ', 'libtiff', 'libtiff', 'mpich2']
Warning: more options how to interpret BSD. Possible options: 
['BSD-2-Clause-FreeBSD', 'BSD-2-Clause-Views', 'BSD-2-Clause', 'BSD-3-Clause', 
'BSD-3-Clause', 'BSD-3-Clause', 'BSD-3-Clause']
( GPL-2.0-only OR {{pick MIT choice}} OR {{pick BSD choice}} )


Good idea. I will try to implement it. Thank you.

Miroslav
___
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

Schedule for Tuesday's FESCo Meeting (2022-11-15)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2022-11-15 17:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2889 Change: Porting Fedora to Modern C
https://pagure.io/fesco/issue/2889
APPROVED (+5,0,-0)

#2890 Change: Python 3.12
https://pagure.io/fesco/issue/2890
APPROVED (+6,0,-0)

= Followups =

#topic #2883 Change: Ostree Native Container (Phase 2, stable)
https://pagure.io/fesco/issue/2883

#topic #2887 move IMA RPM file-signature change to F38?
https://pagure.io/fesco/issue/2887

#topic #2817 Change proposal: Add -fno-omit-frame-pointer to default 
compilation flags
https://pagure.io/fesco/issue/2817


= New business =


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX - How to handle MIT and BSD

[Richard Fontana]

On Tue, Nov 15, 2022 at 6:29 AM Miro Hrončok  wrote:
>
> On 14. 11. 22 20:53, Miroslav Suchý wrote:
> > 1) You can use https://github.com/spdx/spdx-license-diff and use it to 
> > identify
> > your license. This is a Chrome and Firefox plugin and allows you to select 
> > the
> > text; and in the context menu, you can choose to identify the license. It 
> > will
> > print, e.g., that it matches 60% of the MIT-feh license and highlight the
> > difference. Or...
>
> Do we have a command line tool for this? Does licensecheck support SPDX
> identifiers?
>
> (I find the use of browser extension for this very weird. I have the LICENSE
> file unpackaged with the sources on my machine, I am not browsing it on the 
> web.)

Yeah, this tool was developed by a lawyer and I think is mainly aimed
at lawyers. Since it does seem to be somewhat useful a good deal of
the time I've wondered whether it would be straightforward to create a
command line tool based on it (in addition to creating a similar tool
that would target the Fedora license list data rather than SPDX
license identifiers as such).

Richard
___
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 - How to handle MIT and BSD

[Todd Zullinger]

Neal Gompa wrote:
> On Tue, Nov 15, 2022 at 6:24 AM Miro Hrončok  wrote:
>> Do we have a command line tool for this? Does licensecheck support SPDX
>> identifiers?
>>
>> (I find the use of browser extension for this very weird. I have the LICENSE
>> file unpackaged with the sources on my machine, I am not browsing it on the 
>> web.)
> 
> licensecheck supports SPDX, you just have to run it with
> "--shortname-scheme spdx".

In my recent & limited experience, licensecheck did not
produce valid SPDX output in many cases.  As an example,
take a file with the following license header:

/*
 * test-run-command.c: test run command API.
 *
 * (C) 2009 Ilari Liusvaara 
 *
 * This code is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */

I expect it to return GPL-2.0-only, but it returns GPL-2:

$ licensecheck --shortname-scheme spdx t/helper/test-run-command.c
t/helper/test-run-command.c: GPL-2

I did not see any files in the git source labeled with the
appropriate SPDX identifier for GPL-2.0*.  Similar for LGPL.
For BSD-3-Clause, licensecheck used a lower-case C, which
then fails to match a valid license in rpmlint.

Am I missing something obvious or does licensecheck not work
as expected?  This is with licensecheck-3.3.0-2.fc36.noarch.

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

yaml-cpp 0.7.0 soname bump for Rawhide is complete

[Richard Shaw]

I had to back off updating OpenColorIO as it needed a newer version of
minizip-ng than what's available.

https://bodhi.fedoraproject.org/updates/FEDORA-2022-518f2de934

The only fallout is supercollider which failed to build for other reasons:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2085987

Thanks,
Richard
___
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

Intent to retire: opencolorio1

[Richard Shaw]

This compat package was created when OpenColorIO 2 was "new" and a few
projects failed to build with it.

Currently USD is the only consumer and I was able to get it to build with
OCIO 2 just now. I'll wait a bit to see if there's any fallout and if not,
retire it within a week.

Thanks,
Richard
___
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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Robbie Harwood]

Timothée Ravier  writes:

>> Bootloaders are not single files.  Consider UEFI:
>> 
>> For grub2, there's both a .efi and some configuration that I'll handwave
>> for purposes of this conversation.  For shim, it's more like 4 things -
>> the main shim*64.efi, fallback.efi, boot.efi, and boot.csv.  These all
>> serve different purposes, and need to get loaded from specific parts of
>> the ESP.  (Recall here that fat32 doesn't have symlinks, either.)
>
> I don't think I understand the problem here. Do shim updates usually
> change all of those files at once? What's blocking us from updating
> them one by one?

Conceptually, we need to be able to update most of them in the event of
a security issue.  Shim releases are infrequent due to needing signing,
which means that as a signed unit they update more at once.  In the
issue you linked, I described what would be a safe order to apply
updates to them in, but that's not *transactional* (a system that takes
a reboot during the small window of moving files around could see some
from old and some from new).

> Note that bootupd is not trying to solve the "safe" part of bootloader
> updates: we're aware that the system should not crash while the
> bootloader is being updated. See
> https://github.com/coreos/bootupd#questions-and-answers

If your model doesn't permit the system to cease execution during
bootloader updates, then I'm not sure why you need bootupd at all -
traditional RPM updating will work just fine (assuming the A/B change
we've been talking about).  But the "Questions and answers" section
doesn't read that way to me: it mentions that "forcibly pulling the
power during OS updates" is a case ostree wants to support and doesn't
explicitly negate that for the bootloader.

I'm happy to send a PR to update that text if that's not what's meant.

> Thus that's why we're requiring interactions from an admin to apply
> the update as only they can now when the system is the less likely to
> crash.

Are you referring to
https://github.com/fedora-silverblue/issue-tracker/issues/120#issuecomment-1177515110
?  I didn't think that was generally something admins expected to be
doing, but would be happy to be wrong about that.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX - How to handle MIT and BSD

[Neal Gompa]

On Tue, Nov 15, 2022 at 11:05 AM Todd Zullinger  wrote:
>
> Neal Gompa wrote:
> > On Tue, Nov 15, 2022 at 6:24 AM Miro Hrončok  wrote:
> >> Do we have a command line tool for this? Does licensecheck support SPDX
> >> identifiers?
> >>
> >> (I find the use of browser extension for this very weird. I have the 
> >> LICENSE
> >> file unpackaged with the sources on my machine, I am not browsing it on 
> >> the web.)
> >
> > licensecheck supports SPDX, you just have to run it with
> > "--shortname-scheme spdx".
>
> In my recent & limited experience, licensecheck did not
> produce valid SPDX output in many cases.  As an example,
> take a file with the following license header:
>
> /*
>  * test-run-command.c: test run command API.
>  *
>  * (C) 2009 Ilari Liusvaara 
>  *
>  * This code is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
>
> I expect it to return GPL-2.0-only, but it returns GPL-2:
>
> $ licensecheck --shortname-scheme spdx t/helper/test-run-command.c
> t/helper/test-run-command.c: GPL-2
>

That is DEP-5 SPDX(ish) identifiers, which is what Debian uses for
debian/copyright files. I am a bit surprised it gives DEP-5 for
"spdx", but since the tool is from Debian, I guess it makes some
sense...

The identifier is considered valid, as SPDX GPL-2.0 is considered
equivalent to DEP-5 GPL-2, and SPDX-3.0 GPL-2.0-only is equivalent to
SPDX-2.0 GPL-2.0.

Cf. https://wiki.debian.org/Proposals/CopyrightFormat

> I did not see any files in the git source labeled with the
> appropriate SPDX identifier for GPL-2.0*.  Similar for LGPL.
> For BSD-3-Clause, licensecheck used a lower-case C, which
> then fails to match a valid license in rpmlint.
>
> Am I missing something obvious or does licensecheck not work
> as expected?  This is with licensecheck-3.3.0-2.fc36.noarch.
>

licensecheck does not follow/use SPDX-License-Identifier at all. It
predates that scheme.



--
真実はいつも一つ！/ 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: SPDX - How to handle MIT and BSD

[Todd Zullinger]

Neal Gompa wrote:
> On Tue, Nov 15, 2022 at 11:05 AM Todd Zullinger  wrote:
>> Am I missing something obvious or does licensecheck not work
>> as expected?  This is with licensecheck-3.3.0-2.fc36.noarch.
> 
> licensecheck does not follow/use SPDX-License-Identifier at all. It
> predates that scheme.

Then it seems odd to recommend it when someone asks "Does
licensecheck support SPDX identifiers?" I think.  :)

The answer is closer to: "sort of, but not really in a way
that helps Fedora maintainers do the SPDX license
conversion."

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX - How to handle MIT and BSD

[Neal Gompa]

On Tue, Nov 15, 2022 at 12:17 PM Todd Zullinger  wrote:
>
> Neal Gompa wrote:
> > On Tue, Nov 15, 2022 at 11:05 AM Todd Zullinger  wrote:
> >> Am I missing something obvious or does licensecheck not work
> >> as expected?  This is with licensecheck-3.3.0-2.fc36.noarch.
> >
> > licensecheck does not follow/use SPDX-License-Identifier at all. It
> > predates that scheme.
>
> Then it seems odd to recommend it when someone asks "Does
> licensecheck support SPDX identifiers?" I think.  :)
>
> The answer is closer to: "sort of, but not really in a way
> that helps Fedora maintainers do the SPDX license
> conversion."
>

It's very rare to see SPDX-License-Identifier in source code.
Licensecheck will attempt to evaluate source files to determine a
license for each file. This is because in Debian, the DEP-5
debian/copyright file needs per-file license declarations. The ability
to return SPDX short names instead of full names is a courtesy.




--
真実はいつも一つ！/ 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

Mock v3.4 released

[Pavel Raiskup]

Hello maintainers!

I'm glad I can announce that we have a new release of Mock v3.4.  There
are just two small new things, a better --forcearch check and
the device-mapper control file is exposed in chroot.  Full release notes:

https://rpm-software-management.github.io/mock/Release-Notes-3.4

The updated packages are in Bodhi:

[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c3b827df24
[Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-389622bd06
[Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-993c7450c6
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-440fa7af21
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a07aa4589e

Happy building!
Pavel


___
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

Summary/Minutes from today's FESCo Meeting (2022-11-15)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting/2022-11-15/fesco.2022-11-15-17.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting/2022-11-15/fesco.2022-11-15-17.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting/2022-11-15/fesco.2022-11-15-17.00.log.html

Meeting summary
---
* init process  (zbyszek, 17:00:09)

* #2883 Change: Ostree Native Container (Phase 2, stable)  (zbyszek,
  17:01:18)
  * AGREED: Everybody is to re-read the prosal and vote in the ticket.
(zbyszek, 17:12:59)
  * If that fails, we'll vote next week in the meeting.  (zbyszek,
17:13:20)

(We later cancelled the next week's meeting because of holidays in US.
Please read that as "next meeting in two weeks".)

* #2887 move IMA RPM file-signature change to F38?  (zbyszek, 17:13:32)
  * AGREED: Change doesn't seem to have been implemented. It can be
resubmitted for F38 with more details (+6, 0, 0)  (zbyszek,
17:22:34)

* #2817 Change proposal: Add -fno-omit-frame-pointer to default
  compilation flags  (zbyszek, 17:22:43)
  * LINK: https://pagure.io/fesco/issue/2817   (zbyszek, 17:22:46)
  * 
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/6TQYCHMX4FZLF27U5BCEC7IFV6XNBKJP/
(zbyszek, 17:26:24)

* Next week's chair  (zbyszek, 17:30:10)
  * Next week is Thanksgiving in US. Next meeting will be in two weeks.
(zbyszek, 17:32:29)
  * We will keep the meeting time at 17:00 UTC for now, which means
18:00 in EU.  (zbyszek, 17:35:55)
  * ACTION: sgallagh will chair the next meeting (Nov 29th, 17:00 UTC)
(zbyszek, 17:36:32)

(As later discussed, "EU" is wrong. Apologies to anyone in the
neighbouring timezones.)

* Open Floor  (zbyszek, 17:36:38)


Action Items

* sgallagh will chair the next meeting (Nov 29th, 17:00 UTC)




Meeting ended at 17:39:15 UTC.
___
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: Direct to stable updates

[Kevin Fenzi]

On Mon, Nov 14, 2022 at 11:54:32PM +0100, Kevin Kofler via devel wrote:
...snip...

I think we are going to just have to agree to disagree here. 

I think we have had this discussion a number of times now and aren't
going to convince the other. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Colin Walters]

On Fri, Nov 11, 2022, at 11:41 PM, Chris Murphy wrote:
> On Thu, Nov 10, 2022, at 6:08 PM, Robbie Harwood wrote:
>> Ben Cotton  writes:
>>
>>> By design, ostree does not manage bootloader updates as they can not
>>> (yet) happen in a transactional, atomic and safe fashion.
>>
>> As we've talked about before, it's not possible to make updates
>> transactional.  It involves, per spec and depending on processor
>> architecture, updating multiple files in different directories,
>> potentially on different filesystems entirely, one of which is fat32.
>
> EFI/FedoraA
> EFI/FedoraB
>
> NVRAM bootorder uses A then B
>
> Update the bootloader in EFI/FedoraB
>
> At any point of failure, only the EFI/FedoraA bootloader path is used. 
> Once everything in EFI/FedoraB is committed to stable media, set 
> bootnext FedoraB. If the boot fails, automatic failback to FedoraA. If 
> the boot succeeds, bootupd can change bootorder. B then A.

I think it makes sense for us to make some use of BootNext indeed.  However, 
this heavily overlaps with a potential move to UKIs, which effectively obviate 
this whole thread by dropping shim and grub out of the equation.  It also 
overlaps with https://github.com/ostreedev/ostree/issues/2725 where ostree 
could potentially start using BootNext itself - and this is I guess strongly 
pushing things to be more integrated.  (I'd tried to keep the two independent, 
but...)

(There's also an overlap in your proposal with fully redundant EFI partitions 
across multiple disks and how that would need to be handled, also something I'd 
hoped to support in bootupd explicitly)

___
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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Colin Walters]

On Tue, Nov 15, 2022, at 12:00 PM, Robbie Harwood wrote:

> If your model doesn't permit the system to cease execution during
> bootloader updates, then I'm not sure why you need bootupd at all -
> traditional RPM updating will work just fine (assuming the A/B change
> we've been talking about).  But the "Questions and answers" section
> doesn't read that way to me: it mentions that "forcibly pulling the
> power during OS updates" is a case ostree wants to support and doesn't
> explicitly negate that for the bootloader.

There's lots of nuance going on here.  What both bootupd and your shim 
prototype are doing is effectively moving the "payload" into /usr and not have 
RPM directly writing to /efi (or /boot/efi, wherever it's mounted).

This also then directly leads into a next issue: 
https://github.com/coreos/bootupd/issues/50
Basically, `rpm -q shim` becomes a lie - or at least, starts to mean something 
else[1].
So part of the role of bootupd here is just to become the API to query and 
manage state.  It is also kind of aiming to abstract out the differences across 
platforms, i.e. we were discussing bringing BIOS and PReP under management too 
in https://github.com/coreos/bootupd/issues/398

So basically the rationale for bootupd is to become a (relatively thin) layer 
for managing this stuff since it is decoupled from the kernel+rootfs lifecycle 
(but, delivered inside that).

[1]  In a similar vein of course, `rpm -q kernel` can often be a lie after live 
updates but before rebooting, and similar for userspace services that aren't 
restarted or old libraries loaded.  But, admins have known about those for a 
long time, or if they don't they learn the hard way.
___
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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Robbie Harwood]

"Colin Walters"  writes:

> On Tue, Nov 15, 2022, at 12:00 PM, Robbie Harwood wrote:
>
>> If your model doesn't permit the system to cease execution during
>> bootloader updates, then I'm not sure why you need bootupd at all -
>> traditional RPM updating will work just fine (assuming the A/B change
>> we've been talking about).  But the "Questions and answers" section
>> doesn't read that way to me: it mentions that "forcibly pulling the
>> power during OS updates" is a case ostree wants to support and doesn't
>> explicitly negate that for the bootloader.
>
> There's lots of nuance going on here.  What both bootupd and your shim
> prototype are doing is effectively moving the "payload" into /usr and
> not have RPM directly writing to /efi (or /boot/efi, wherever it's
> mounted).

No, the install script install script in an RPM trigger, so the write is
still carried out by RPM.

> This also then directly leads into a next issue:
> https://github.com/coreos/bootupd/issues/50 Basically, `rpm -q shim`
> becomes a lie - or at least, starts to mean something else[1].

I don't agree.  Just because a user can mess with files on the system
doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all
paths on the filesystem just in case they've done so, or create a daemon
to provide an interface for doing that.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Direct to stable updates

[Kevin Kofler via devel]

Kevin Fenzi wrote:
> I think we are going to just have to agree to disagree here.
> 
> I think we have had this discussion a number of times now and aren't
> going to convince the other.

So Bodhi will continue to become more and more unmaintainable due to piling 
up more and more complicated rules that it needs to enforce, and obvious 
defects such as the one that started this thread will never get addressed.

It is really sad that you are not willing to open your eyes and see the 
amount of damage that this dead-end policy has caused and is still causing.

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

Fedora CoreOS streams rebasing to Fedora Linux 37

[Dusty Mabe]

Following our scheduling policy around Fedora major version releases [1]
we will be rolling out the Fedora Linux 37 rebase over the next few weeks.
This rollout started earlier today with the `testing` stream.

Of note is that during this development cycle we were promoted to an official
edition [2].

Current known issues:

- kernel 6.x update breaks proxy NDP [3]

Thanks to everyone who participated in the test day [4] and to everyone that
follows the `testing` and `next` streams to help us identify and fix issues
before they get to `stable`.

Dusty Mabe, for the Fedora CoreOS team

[1] 
https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md#major-fedora-version-rebases
[2] https://github.com/coreos/fedora-coreos-tracker/issues/915
[3] https://github.com/coreos/fedora-coreos-tracker/issues/1337
[4] https://github.com/coreos/fedora-coreos-tracker/issues/1225
___
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: [Fedocal] Reminder meeting : Prioritized bugs and issues

[Ben Cotton]

On Tue, Nov 15, 2022 at 11:29 AM  wrote:
>
> You are kindly invited to the meeting:
>Prioritized bugs and issues on 2022-11-16 from 10:00:00 to 11:00:00 
> America/Indiana/Indianapolis
>At fedora-meetin...@irc.libera.chat
>
> More information available at: 
> https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/

We will discuss the following nominated bug:

* ABRT on KDE can't store any passwords: Secret Service is not available
- https://bugzilla.redhat.com/show_bug.cgi?id=2141237

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gordon Messmer]

After reading this thread and bz 2123998, I had thought that the Fedora 
37 mesa packages retained accelerated video for open codecs (for AMD 
hardware).  However, the Fedora wiki[1] indicates that even open codecs 
are no longer accelerated without third party packages.  Is that true?  
(I don't think that I can test this, since I don't have any AMD GPUs, 
only Intel.)



1: 
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-API_Video_decoding_on_AMD

___
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: yaml-cpp 0.7.0 soname bump for Rawhide is complete

[Mamoru TASAKA]

Richard Shaw wrote on 2022/11/16 1:10:

I had to back off updating OpenColorIO as it needed a newer version of
minizip-ng than what's available.

https://bodhi.fedoraproject.org/updates/FEDORA-2022-518f2de934

The only fallout is supercollider which failed to build for other reasons:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2085987


supercollider is fixed in -7, backporting upstream fix for libsndfile 1.1.x .
https://koji.fedoraproject.org/koji/buildinfo?buildID=2089036

repoquery says cantera also needs rebuilding for new yaml-cpp, so it's done.


Thanks,
Richard



Regards,
Mamoru
___
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 - How to handle MIT and BSD

[Kan-Ru Chen]

On Tue, Nov 15, 2022, at 8:23 PM, Miro Hrončok wrote:
> On 14. 11. 22 20:53, Miroslav Suchý wrote:
>> 1) You can use https://github.com/spdx/spdx-license-diff and use it
>>to identify your license. This is a Chrome and Firefox plugin and
>>allows you to select the text; and in the context menu, you can
>>choose to identify the license. It will print, e.g., that it
>>matches 60% of the MIT-feh license and highlight the difference.
>>Or...
>
> Do we have a command line tool for this? Does licensecheck support
> SPDX identifiers?
>
> (I find the use of browser extension for this very weird. I have the
> LICENSE file unpackaged with the sources on my machine, I am not
> browsing it on the web.)

There's also a cli tool and library called "askalono"
https://github.com/jpeddicord/askalono that can detect license and
output SPDX identifiers (the data set is sourced from SPDX). It also
outputs a score for similarity. There are also other tools mentioned
in the README, licensee (ruby), ScanCode (python).



  Kan-Ru
___
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: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Tue, Nov 15, 2022 at 5:27 PM Gordon Messmer  wrote:
>
> After reading this thread and bz 2123998, I had thought that the Fedora
> 37 mesa packages retained accelerated video for open codecs (for AMD
> hardware).  However, the Fedora wiki[1] indicates that even open codecs
> are no longer accelerated without third party packages.  Is that true?
> (I don't think that I can test this, since I don't have any AMD GPUs,
> only Intel.)
>

This is not true. However, until recently, support for hardware
accelerated open codecs was limited to Intel QuickSync Video, which is
blocked on the VA-API driver landing in Fedora[1].

AMD VP9 decoding was added in VCN 1.0:
https://en.wikipedia.org/wiki/Video_Core_Next

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1942132



-- 
真実はいつも一つ！/ 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: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gordon Messmer]

On 2022-11-15 15:32, Neal Gompa wrote:

This is not true. However, until recently, support for hardware
accelerated open codecs was limited to Intel QuickSync Video, which is
blocked on the VA-API driver landing in Fedora[1].

AMD VP9 decoding was added in VCN 1.0:



Sorry, I'm still not clear on what I should take away from that, and 
that's probably my fault for summarizing what I'd read.  BZ 2123998 
suggested that mesa-22.2.0~rc3-1.fc37 had support for 
VAProfileVP9Profile0 and VAProfileVP9Profile2 in radeonsi_drv_video.so 
(after the patent-encumbered formats were disabled), but the wiki page 
says that VP8, VP9, and AV1 are no longer accelerated out of the box on 
AMD GPUs.


Is VP9 currently accelerated for AMD GPUs without third-party packages, 
or not?


Again, sorry if I'm being dense.
___
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: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Tue, Nov 15, 2022 at 7:52 PM Gordon Messmer  wrote:
>
> On 2022-11-15 15:32, Neal Gompa wrote:
> > This is not true. However, until recently, support for hardware
> > accelerated open codecs was limited to Intel QuickSync Video, which is
> > blocked on the VA-API driver landing in Fedora[1].
> >
> > AMD VP9 decoding was added in VCN 1.0:
>
>
> Sorry, I'm still not clear on what I should take away from that, and
> that's probably my fault for summarizing what I'd read.  BZ 2123998
> suggested that mesa-22.2.0~rc3-1.fc37 had support for
> VAProfileVP9Profile0 and VAProfileVP9Profile2 in radeonsi_drv_video.so
> (after the patent-encumbered formats were disabled), but the wiki page
> says that VP8, VP9, and AV1 are no longer accelerated out of the box on
> AMD GPUs.
>
> Is VP9 currently accelerated for AMD GPUs without third-party packages,
> or not?
>
> Again, sorry if I'm being dense.

It is, provided the GPU supports it.


-- 
真実はいつも一つ！/ 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: SPDX - How to handle MIT and BSD

[Miroslav Suchý]

Dne 15. 11. 22 v 10:44 Daniel P. Berrangé napsal(a):

In that case, IMHO, the tool should NOT suggest a license from the
list at all, and definitely not arbitrarily suggest the last one it
loaded, which is highly likely to be wrong. If it wants to suggest,
then suggest the most likely option out of the variants.  Or can it
suggest an intentionally invalid placeholder eg "{MIT choice}" to
make it explicit that the maintainer has to actively make a choice.

$ license-fedora2spdx  "(GPLv2 or MIT or BSD)"
Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 
'BSL-1.0', 'BSL-1.0', 'HPND', 'HPND', 'ICU', 'MIT-CMU', 'MIT-Modern-Variant', 
'MIT-enna', 'MIT-feh', 'MIT-open-group', 'MIT', 'NTP', 'SGI-B-2.0', 'SMLNJ', 
'SMLNJ', 'libtiff', 'libtiff', 'mpich2']
Warning: more options how to interpret BSD. Possible options: 
['BSD-2-Clause-FreeBSD', 'BSD-2-Clause-Views', 'BSD-2-Clause', 'BSD-3-Clause', 
'BSD-3-Clause', 'BSD-3-Clause', 'BSD-3-Clause']
( GPL-2.0-only OR {{pick MIT choice}} OR {{pick BSD choice}} )


Your wish has been granted. Implemented, built and I just submitted it to bodhi 
as license-validate-14-1

Miroslav
___
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 - How to handle MIT and BSD

[Bob Mauchin]

On Tue, Nov 15, 2022, 12:24 Miro Hrončok  wrote:

> On 14. 11. 22 20:53, Miroslav Suchý wrote:
> > 1) You can use https://github.com/spdx/spdx-license-diff and use it to
> identify
> > your license. This is a Chrome and Firefox plugin and allows you to
> select the
> > text; and in the context menu, you can choose to identify the license.
> It will
> > print, e.g., that it matches 60% of the MIT-feh license and highlight
> the
> > difference. Or...
>
> Do we have a command line tool for this? Does licensecheck support SPDX
> identifiers?
>
> (I find the use of browser extension for this very weird. I have the
> LICENSE
> file unpackaged with the sources on my machine, I am not browsing it on
> the web.)
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue



I package askalono-cli which can detect license texts and outputs an SPDX
identifier:  https://github.com/jpeddicord/askalono

We use it in go2rpm.

Best regards,

Robert-André

>
>
___
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: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 15, 2022 at 12:35:32PM +0100, Karolina Surma wrote:
> On 11/15/22 08:37, Mattia Verga via devel wrote:
> > Il 15/11/22 00:23, Neal Gompa ha scritto:
> >> On Mon, Nov 14, 2022 at 6:03 PM Kevin Kofler via devel
> >>  wrote:
> >>> So let me sum up:
> >>>
>  Some Python building backends, eg. setuptools, explicitly allow
>  creating package with version `0.0.0` when the version used by a
>  project is not known. This was
>  [https://github.com/pypa/setuptools/issues/2329 discussed upstream]
>  with conclusion that it's an intended behavior.
> >>> Upstream says that it is intended that packages are able to set their
> >>> version to 0 or 0.0.0, but…
> >>>
>  Based on discussion on python-devel mailing list there will be no way
>  to opt out from this change. There will be no possibility to package a
>  Python package with version `0`.
> >>> … your proposed Change will fail those packages' build with no opt-out!? 
> >>> You
> >>> cannot be serious!
> >>>
> >>> (Though actually, would %global __provides_exclude_from … together with a
> >>> manual Provides: python3dist(…) = 0 not work?)
> >>>
> >>> A clear -1 to this Change as proposed.
> >>>
>  We've never encountered a situation when packaging the version `0` was
>  the package maintainers intention.
> >>> What if it is the *upstream* maintainer's intention? Are we now dictating
> >>> versioning schemes on upstream projects, disallowing version numbers that
> >>> upstream setuptools explicitly considers valid?
> >>>
> >> Unfortunately, I have to agree here. Nobody said we should be
> >> dictating the versions for people. PEP-440 does not even make 0
> >> version illegal, so this is unnecessarily punishing.
> >>
> > IMO, the policy is right, it just have to allow to opt out, so that the
> > maintainer is informed that **there could be** something wrong with the
> > package metadata / build process. Maybe an opt-out + file a ticket in BZ
> > to have track of the opt out, just like the ExcludeArch is the right
> > approach.
> > 
> > Mattia
> > 
> 
> Hello,
> 
> The standard invocation of the Python dependency generator will be
> changed to always run with option like `--fail-if-version-zero`. (This
> is the subject of the current proposal.)
> 
> Based on your concerns, an opt out mechanism would be added:
> If you wanted to bypass the option, you could define a macro in the
> specfile, eg.
> `%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`
> 
> This would allow to build RPMs without bothering with versions. Also, if
> it's upstream's decision to use version 0, that would be the way to go.
> In Fedora this would give us an insight into how often this is needed.
> 
> What do you think of enhancing the proposal this way?

This would provide the opt-out that was requested.

But it's also very specific to a problem that is mostly theoretical.
Maybe instead add %__python_dist_extra_flags that would contain 
'--fail-if-version-zero'
by default. That would also provide an opt-out, but allow other
currently unforeseen uses.

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