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

[Mattia Verga via devel]

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

___
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: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)

[Jitka Plesnikova]

On 11/11/22 14:10, Jitka Plesnikova wrote:



Something like this should work:

File: /usr/lib/rpm/fileattrs/perllib.attr


%__perllib_requires() %{lua:
    if macros['1']:match('.+%.so$') and macros.perl_version then
   print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
    else
   print('perl-libs')
    end
}
%__perllib_path ^(%{perl_vendorarch}|%{perl_vendorlib})/.+


(Untested.)



Thanks for hint. I'll check if it works for my change.
Jitka

MODULE_COMPAT is used for 1) Perl Modules and also 2) for packages which 
use perl interpreter or libperl.so.
For the second case, the RPM dependency generator above does not work. 
These packages may not contain

the Perl directories.

For now, I prefer to use the change describe in the proposal. It works 
for all these cases.


Jitka

--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
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

Non-responsive maintainer check for strobert

[Robert Scheck]

Hello,

does somebody know how to contact Steven Roberts? Yes, two requests are for
EPEL 9, but I would be even happy to maintain the EPEL branch(es) myself in
case of a negative response.

 - https://bugzilla.redhat.com/show_bug.cgi?id=1974006
 - https://bugzilla.redhat.com/show_bug.cgi?id=2072993
 - https://bugzilla.redhat.com/show_bug.cgi?id=2104397

I also filed https://bugzilla.redhat.com/show_bug.cgi?id=2142700 to follow
the non-responsive maintainer policy.


Regards,
  Robert


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

[Neal Gompa]

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.



-- 
真実はいつも一つ！/ 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: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)

[Kevin Kofler via devel]

> 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.

How about Calamares in a dont-chroot: true configuration?

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

[Demi Marie Obenour]

On 11/14/22 13:32, Robbie Harwood wrote:
> Timothée Ravier  writes:
> 
>>> 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.
>>
>> I should probably have used only 'safe' here. My understanding of the 
>> "fallback work" was that with it, we could do updates automatically and 
>> retry them after failures without risking ending up in a state where we have 
>> no working bootloader. The update process would look like this:
>> 1. Verify current bootloader hash
>> 2. Fix it if not good
>> 3. Copy current version to fallback
>> 4. Update bootloader to new version
>>
>> What I've indeed forgotten to specify is that this only applies to EFI (so 
>> probably only x86 & aarch64) for now as that's what's implemented in bootupd.
>>
>> Am I missing something?
> 
> 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.)
> 
> While I think it will surprise no one that I don't agree with doing so,
> bootupd claims the additional goal of supporting Legacy BIOS.  For that,
> you also need to consider updates to the MBR, which isn't a file at all.

For at least UEFI, this can be solved by using *two* boot entries.  Once
everything is working in the new location, switch to it.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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)

[Kevin Kofler via devel]

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?

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: Direct to stable updates

[Kevin Kofler via devel]

Kevin Fenzi wrote:
> For a few years I was keeping track of updates that caused big problems:
> 
> https://fedoraproject.org/wiki/Updates_Lessons

That is also very anecdotal evidence though. And with only one exception 
(the broken dependency in celt), the updates in the above list above are 
all:
* either updates that have made it through to stable despite being broken, 
in all cases since March 2010 (i.e., after the dnssec-conf one that was the 
trigger for the main Bodhi crackdown) despite (or even because of) the new 
update policies, (In other words, the strict rules have NOT prevented the 
breakage in stable. At least in one case (the 2014-03 one), you have 
explicitly documented autokarma as the cause for the breakage: 
"User:Adamwill noticed several cases where updates had been submitted to 
stable despite a valid AutoQA test failure, usually not via a manual push 
but via karma automatism.")
* or critical updates that have not made it through to stable in a timely 
manner, usually because of the karma requirements. (In other words, those 
issues were directly CAUSED by the strict policies!)

And this list is by no means complete. I remember way more bad updates and 
delayed updates (sometimes even together: bad update gets through instantly 
through autokarma, the regression fix is stuck in testing for days, because 
the testers just did not care about and/or were unable to test the regressed 
use case), too many to write down a list like this (and indeed, I have no 
such list). Your list has only the worst failures of the bureaucratic update 
policy.

> The orig "very bad" update was a dbus update that broke everything.

That was one of the issues that had triggered a perceived demand for 
stricter rules, but the Bodhi crackdown was actually implemented only 
starting from March 2010, after the dnssec-conf update (which was pushed 
directly to stable, as was still allowed in February 2010).

The D-Bus one actually affected a large range of users, but it had a trivial 
workaround (update from the CLI, i.e.: su -c "yum update" – yum because DNF 
was not a thing at the time). The dnssec-conf one affected only a very small 
percentage of Fedora users, because most users do not run their own DNS 
server software. (Not even most domain owners, because name servers are 
typically provided by the registrar.) None was as catastrophic a failure as 
the mob for stricter rules had painted them.

> In any case I have seen our current updates system working and blocking
> tons of harmfull updates over the years.

But you do not have a list proving that. (The list you linked to is not it, 
because I see only exactly one entry in it where a bad update did not make 
it beyond testing, the 2010-07-02 celt one.) And even if you had one, it 
would not prove that the maintainers would not have used updates-testing the 
intended way without being forced to by software.

What I have seen (and no, I do not have a list either) is updates making it 
through (due to karma or because the 7 or 14 days just ran out without 
anybody bothering to test them) to stable causing a bad regression, and then 
the regression fix needlessly sitting in testing for up to two weeks, 
instead of being pushed directly to stable to undo the breakage. Not only 
does that delay the fix for those users unlucky enough to get the bad 
update, but it also largely increases the number of affected users, because 
many users do not update daily and might not have noticed the regression if 
the fix had been pushed the next day rather than 1-2 weeks later (window of 
exposure). In some cases, I was the maintainer that was unable to push the 
regression fix out any sooner due to the rules, so I definitely know that 
the rules are to blame. (And before the rules were enforced, I had always 
used direct stable pushes to fix regressions, leading to happy users.)

Due to the window of exposure effect, 7 regressions slipping through, each 
fixed the next day with a direct stable push, are not necessarily worse than 
1 regression slipping through (the other 6 having been prevented by the 
rules), fixed only 7 days later due to the update rules. And in practice, 
the testing is far from catching 6 bad updates out of 7. A lot slips 
through, because testers are unable to test, e.g., library packages 
exhaustively.

> I think direct to stable is a bad idea.

I think it is a good idea, under some conditions (critical regression or 
security fix, entirely new package, or package that was previously 
uninstallable or unusable). When stable is actually open for pushes.

Of course it does not work during a freeze, which (together with the fact 
that karma thresholds can be reached even before the updates reach testing, 
leading to a special case in which direct stable pushes are actually still 
possible after all) is the issue that started this thread. But that should 
be solved the way I already mentioned (automatically divert the push to 
testing instead, but keep 

Re: SPDX - How to handle MIT and BSD

[Richard Fontana]

On Mon, Nov 14, 2022 at 3:29 PM Miroslav Suchý  wrote:

> Until now, what Fedora described as an "MIT" license was, in fact, a whole 
> family of licenses. SPDX identify them differently. And the differences can 
> be subtle. E.g., compare
>
> https://spdx.org/licenses/MIT.html
> https://spdx.org/licenses/MIT-feh.html
> https://spdx.org/licenses/MIT-open-group.html
>
> If your old Fedora license was MIT, there is a very high chance that the new 
> one will be MIT too. But it is far from being 100 % sure.

BTW this can vary based on the age and language community/ecosystem of
the upstream project. Relatively old projects written in C are more
likely to have "MIT"-like licenses that are not MIT in the OSI/SPDX
sense, while, say, less old PyPI-packaged Python projects are more
likely to just have that de-facto-standard MIT license. I'm pretty
sympathetic to maintainers of some of the older and more
(license-wise) complex packages where this process of license
representation migration can be more complicated.

> There are 14 other options. These that `license-fedora2spdx` listed in the 
> warning above.
>
> Similarly, for BSD. BSD also identified the whole family. You likely end up 
> with "BSD-2-Clause" or "BSD-3-Clause", but there are two different options as 
> well.
>
>
> 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.

While that is worth checking, it assumes that you can identify a
license based on its name (or what you think it might be) which will
not work in all cases. I'm hoping that eventually we can develop tools
that could do license text matching against the corpus of allowed and
not-allowed Fedora licenses (maybe something like an adaptation of
spdx-license-diff, maybe something simpler).

Also, feel free to submit an issue at
https://gitlab.com/fedora/legal/fedora-license-data or (less
preferable) posting a question to le...@lists.fedoraproject.org.

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

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

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/KDERemoveInitialSetup

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 ==

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.

== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Ngompa| Neal Gompa]]
* Email: si...@fedoraproject.org, ngo...@fedoraproject.org

== Detailed Description ==

We'll remove the initial-setup package from the KDE Spin & Fedora
Kinoite. This will fix a bug that is only visible on Kinoite (where
the user gets a warning on first boot because / is read only) and will
let us work on replacing it by another more KDE native application
instead.

OEM installations are installations where only the minimum is
configured by the vendor (hardware provider) and everything else is
done by the user on first boot. This is the default experience on
Fedora Workstation and other major operating systems. See also:
https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-linux-distributions.

Note that this is not about removing Anaconda as an installer or from
the Live ISO, but removing initial-setup. For Fedora Kinoite where we
don't have a Live ISO but a separate installer ISO that includes
Anaconda, this will effectively also remove Anaconda from the final
system.

See also the discussion in https://pagure.io/fedora-kde/SIG/issue/243
for potential alternatives.

== Feedback ==

None so far.

== Benefit to Fedora ==

* Smaller image
* One less UX bug on Kinoite
* Work in the direction of OEM installations for the KDE based variants

== Scope ==
* Proposal owners:
** Remove the packages and test the change. Work on packaging
alternatives and potential integration.
** OpenQA tests to update if we successfully enable the OEM installation mode.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

Only impacts the first boot after installation. Should not impact updates.

== How To Test ==

Once the change has landed in Rawhide, downloading the ISO and
performing an installation should behave the same as currently. If we
successfully have a replacement then folks will be able to test OEM
installations.

== User Experience ==

No change initially. If we successfully have a replacement then we can
enable OEM installations.

== Dependencies ==

N/A

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?) Revert the change.
* Contingency deadline: Anytime, probably before Beta
* Blocks release? No

== Documentation ==
N/A

== Release Notes ==
N/A. If we add OEM installation support then we can mention that.


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

Re: SPDX - How to handle MIT and BSD

[Kevin Kofler via devel]

Miroslav Suchý wrote:
> 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.

That is a lot of pointless work for details that almost certainly is going 
to care about, or even notice to begin with.

I would suggest just picking the most common option (MIT→MIT and BSD→BSD-3-
Clause) and letting people file a bug if it turns out to be wrong. We have 
had packages with more inaccurate License tags than that (wrong GPL version, 
GPL instead of LGPL or vice-versa, etc., sometimes even entirely wrong 
licenses).

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

SPDX - How to handle MIT and BSD

[Miroslav Suchý]

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

```


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


You can take the result of this tool only when there is no warning. E.g.:


```

$ license-fedora2spdx 'GPLv2'
GPL-2.0-only

```


Until now, what Fedora described as an "MIT" license was, in fact, a whole family of licenses. SPDX identify them 
differently. And the differences can be subtle. E.g., compare


 * https://spdx.org/licenses/MIT.html
 * https://spdx.org/licenses/MIT-feh.html
 * https://spdx.org/licenses/MIT-open-group.html

If your old Fedora license was MIT, there is a very high chance that the new one will be MIT too. But it is far from 
being 100 % sure. There are 14 other options. These that `license-fedora2spdx` listed in the warning above.


Similarly, for BSD. BSD also identified the whole family. You likely end up with "BSD-2-Clause" or "BSD-3-Clause", but 
there are two different options as well.



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.



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

[Timothée Ravier]

> 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?

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

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.

> While I think it will surprise no one that I don't agree with doing so,
> bootupd claims the additional goal of supporting Legacy BIOS.  For that,
> you also need to consider updates to the MBR, which isn't a file at all.

While we do have that as a goal, we don't support legacy BIOS right now thus 
the reason why this proposal is focusing on EFI systems: 
https://github.com/coreos/bootupd/issues/53
___
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

moby-engine (also known as Docker) maintenance in Fedora

[Timothée Ravier]

Hi everyone,

The moby-engine package [1] (also known as Docker) has been orphaned in Fedora 
and is looking for a new maintainer. The waiting period will soon be over and 
the package will be retired if nobody steps in.

This means that the package will be unavailable starting with the next release 
of Fedora (Fedora 38) that should happen in approximately 5 to 6 months.

If you are using this package and are interested in helping maintaining it, now 
is the time to come forward!

This notably impacts Fedora CoreOS as we are including the moby-engine package 
by default to let users pick their container engine of choice whithout deciding 
for them in advance. We offer both major container engines by default in the 
image (podman and moby-engine).

If the moby-engine package ends up being retired for Fedora 38, then we will 
have to recommend to its users on Fedora CoreOS that they either switch to the 
official Docker packages [2] or move to containerd or podman when the rebase to 
Fedora 38 happens alongside the Fedora 38 release [3].

Note that we will likely not remove the containerd package from Fedora CoreOS 
as it is still maintained in Fedora and is currently used by Kubernetes 
distributions based on Fedora CoreOS (such as Typhoon for example).

See also the Fedora CoreOS tracker issue [4] for more details.

[1] https://src.fedoraproject.org/rpms/moby-engine
[2] https://docs.docker.com/engine/install/fedora/
[3] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
[4] https://github.com/coreos/fedora-coreos-tracker/issues/1291

Thanks,

Timothée Ravier for the Fedora CoreOS team
___
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:

>> 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.
>
> I should probably have used only 'safe' here. My understanding of the 
> "fallback work" was that with it, we could do updates automatically and retry 
> them after failures without risking ending up in a state where we have no 
> working bootloader. The update process would look like this:
> 1. Verify current bootloader hash
> 2. Fix it if not good
> 3. Copy current version to fallback
> 4. Update bootloader to new version
>
> What I've indeed forgotten to specify is that this only applies to EFI (so 
> probably only x86 & aarch64) for now as that's what's implemented in bootupd.
>
> Am I missing something?

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.)

While I think it will surprise no one that I don't agree with doing so,
bootupd claims the additional goal of supporting Legacy BIOS.  For that,
you also need to consider updates to the MBR, which isn't a file at all.

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

SCIP MI(L)P and MINLP solver (and SoPlex LP solver) now Free Software

[Kevin Kofler via devel]

Hi,

I have good news for everyone interested in optimization software: SCIP 
(https://www.scipopt.org/) has changed its license from the previously used 
semi-free academic non-commercial license to the Apache 2.0 License, i.e., a 
Free Software license and an OSI Approved Open Source license.

The license change also applies not only to SCIP itself, a solver for mixed-
integer linear (MIP/MILP) and non-linear (MINLP) problems, but also to the 
underlying default continuous LP solver SoPlex.

The change has already been made in git. New tarballs will be released with 
the next bugfix release (8.0.3), though I do not know when exactly that will 
be.

So it should now be possible to package this in Fedora. In my experience, 
SCIP performs much better than COIN-OR Cbc on MIPs (MILPs).

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: HEADS UP: gdal-3.6.0 landing in rawhide

[Sandro Mani]

On 14.11.22 17:22, Sandro Mani wrote:



On 14.11.22 00:13, Sandro Mani wrote:


This is done now and the side tag merged. Two packages failed to build:

>  python-rasterio

which fails to build due to test failures, I'll investigate whether 
they are gdal related



Reported at https://github.com/rasterio/rasterio/issues/2653


Fixed in python-rasterio-1.3.3-3.fc38___
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)

[Timothée Ravier]

If I understood things correctly, that's not how this would work. We would not 
touch the boot order at all.
See https://github.com/rhboot/shim/pull/502 & 
https://mivehind.net/2022/08/17/shim-ab-booting-poc/.
___
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: Pull-request related question.

[Kevin Fenzi]

On Sat, Nov 12, 2022 at 08:29:17PM -, Sergey Mende wrote:
> Hi,
> during development of my own project I hit the bug in `gdb` that is already 
> fixed upstream but not backported to rawhide yet.
> I did a backport and ready to submit a PR. What is the right way to proceed: 
> 
> a) just file a PR;
> b) open a bug in bugzilla, submit a PR;
> c) submit a PR, open a bug in bugzilla noting that PR is in a way?

There's no hard rule or even good convention here, but I would
personally say just a PR and waiting a bit would be best. If there's no
answer after a while, a bug could be filed to attract the maintainers(s)
attention. 

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: Direct to stable updates

[Kevin Fenzi]

For a few years I was keeping track of updates that caused big problems:

https://fedoraproject.org/wiki/Updates_Lessons

The orig "very bad" update was a dbus update that broke everything. 

In any case I have seen our current updates system working and blocking
tons of harmfull updates over the years. I think direct to stable is a
bad idea. 

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: HEADS UP: gdal-3.6.0 landing in rawhide

[Sandro Mani]

On 14.11.22 00:13, Sandro Mani wrote:


This is done now and the side tag merged. Two packages failed to build:

>  python-rasterio

which fails to build due to test failures, I'll investigate whether 
they are gdal related



Reported at https://github.com/rasterio/rasterio/issues/2653

___
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: webkit2gtk5.0 -> webkitgtk6.0

[Michael Catanzaro]

On Sat, Nov 12 2022 at 01:50:28 PM +0100, Vitaly Zaitsev via devel 
 wrote:

Thanks for the information. Switched to webkit2gtk4.1:
https://github.com/rpmfusion/telegram-desktop/commit/f7faaf463172ee60e04598bd681957ae98be082f


OK, thanks, that should be good.

For now, this API change will only land in rawhide. It will arrive in 
F37 in March when I update it from WebKitGTK 2.38 -> 2.40. I *usually* 
would update F36 as well at the same time, but maybe it will be more 
convenient to just leave F36 on WebKitGTK 2.38 forever due to the GTK 4 
API change.


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: SPDX Change update

[Michel Alexandre Salim]

On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote:
> On 11. 11. 22 17:24, Sandro wrote:
> > I'm not quite sure why pulling in an additional supplemental dependency
> > would be considered a breaking change. Is it because rpmlint behaves
> > differently with the new license definitions?
> 
> Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I
> use it to validate spec files for RHEL 9. When I install
> rpmlint-fedora-license-data, a huge bulk of licenses that were not valid
> when I started to use Fedora 36 and that are not valid for RHEL 9 are
> suddenly valid.
> 
To clarify -- while SPDX license strings are not valid for RHEL 9, are
they valid for EPEL 9?

Thanks,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

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

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Prevent-Providing-python3dist(pkg)%3D0

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 ==
It sometimes happens that Python packages succeed to build as RPM with
incorrect version metadata.
They generate a wrong provide in format `python3dist(...) = 0` and
`python3.Xdist(...) = 0`.
While version `0` (or equal versions like `0.0` or `0.0.0`) is
probably technically valid, in most cases this indicates a packaging
error.
We propose to prevent this error from happening by explicitly failing
the RPM build instead of generating such provides.

== Owner ==
* Name: [[User:Ksurma|Karolina Surma]]
* Email: ksu...@redhat.com


== Detailed Description ==
This change is about automatic RPM provides in the following form:

* `python3dist(distname) = 0`
* `python3.Xdist(distname) = 0`

Where X is the Python minor version (eg. 10, 11...).
It does not affect any other provides.
More about these provides:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides

The provides generated during the RPM build come from the upstream
Python package metadata.
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.

In other cases, for example when building package from a particular
git commit, the incorrect provide can be generated due to a packaging
error.
We've never encountered a situation when packaging the version `0` was
the package maintainers intention.
After a discussion on python-devel mailing list we agreed we'd like to
prevent such situations from happening in Fedora.

An example of the incorrect provides:

 $ rpm -qpP python3-ssh-python-0.10.0-5.fc38.x86_64.rpm
 python-ssh-python = 0.10.0-5.fc38
 python3-ssh-python = 0.10.0-5.fc38
 python3-ssh-python(x86-64) = 0.10.0-5.fc38
 python3.11-ssh-python = 0.10.0-5.fc38
 '''python3.11dist(ssh-python) = 0'''
 '''python3dist(ssh-python) = 0'''

Why is it bad?

If any package requires `python3-ssh-python > 0.9` (correctly assuming
there's `0.10.0` in Fedora's repositories), the automatic dependency
generators will not discover the example package, making the other
package non-installable.

In January 2022 the
[https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0
umbrella Bugzilla ticket] was created for Python packages providing
version `0`. In all cases the automatic provide wasn't intended.

Affected packages (as of Nov 11 2022):

 b43-tools
 dionaea
 marisa
 python-podman-api
 rpkg
 spectrographic
 python-ssh-python
 python-streamlink

The change doesn't affect a big part of the Python ecosystem.

We aim to prevent such situation from happening by increasing the
robustness of the python-rpm-generators (namely
[https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py
pythondistdeps.py]).
The generator will error and fail the build if `python3dist(...) = 0`
was to be generated.

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`.
Packagers who encounter such need are encouraged to work with upstream
to set the version to at least `0.0.1`.

== Feedback ==
The idea was posted on
[https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/K35JCFVJLETVUOICQM634OSYBYQ3Q2WQ/
python-devel mailing list] and received a positive feedback. No
alternatives to this approach were proposed.

== Benefit to Fedora ==
The correct metadata is essential for the whole package ecosystem.
More deterministic behavior of the generators will bring those
benefits:
* The packages will stop lying about the version they provide.
* The requirements generators (eg. `%pyproject_buildrequires`) will
correctly evaluate the Build- and Runtime Requirements based on the
correct Provides.
* The package maintainers who BuildRequire `%{py3dist pkgname} >= 0.2`
in their specfiles will always require the correctly evaluated
version.

== Scope ==
* Proposal owners:
# implement & test the change in python-rpm-generators
([https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py
pythondistdeps.py])

* Other developers:
** Fix the packaging error to generate correct metadata and successful
build. There's no common way to deal with such packages. In most of
the cases the issue originates from packaging errors that need to be
fixed. Contact the change owners if you need help with the necessary
changes to your package.

* Release engineering: not needed for this Change
* Policies and guidelines:
[https:

Review swap

[Iñaki Ucar]

Hi everyone,

Here's an easy one: https://bugzilla.redhat.com/show_bug.cgi?id=2140316
Happy to review something in exchange.

Best,
-- 
Iñaki Úcar
___
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 Change update

[Miro Hrončok]

On 14. 11. 22 14:58, Richard W.M. Jones wrote:

On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote:

On 11. 11. 22 17:24, Sandro wrote:

I'm not quite sure why pulling in an additional supplemental
dependency would be considered a breaking change. Is it because
rpmlint behaves differently with the new license definitions?


Yes. Suppose I am running a Fedora 36 system with rpmlint installed
and I use it to validate spec files for RHEL 9. When I install
rpmlint-fedora-license-data, a huge bulk of licenses that were not
valid when I started to use Fedora 36 and that are not valid for
RHEL 9 are suddenly valid.


This issue sounds like it'd be better solved by using RHEL 9 for the
checks.  Or the rather more complicated solution of creating a new
‘rpmlint --release=rhel-9’ flag.


I don't disagree. I've just said that for the current users of Fedora 35/36 who 
decided to use Fedora this way, adding a strict dependency on 
rpmlint-fedora-license-data might be disturbing, which is I've only made it a 
weak one.


--
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 Change update

[Richard W.M. Jones]

On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote:
> On 11. 11. 22 17:24, Sandro wrote:
> >I'm not quite sure why pulling in an additional supplemental
> >dependency would be considered a breaking change. Is it because
> >rpmlint behaves differently with the new license definitions?
> 
> Yes. Suppose I am running a Fedora 36 system with rpmlint installed
> and I use it to validate spec files for RHEL 9. When I install
> rpmlint-fedora-license-data, a huge bulk of licenses that were not
> valid when I started to use Fedora 36 and that are not valid for
> RHEL 9 are suddenly valid.

This issue sounds like it'd be better solved by using RHEL 9 for the
checks.  Or the rather more complicated solution of creating a new
‘rpmlint --release=rhel-9’ flag.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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 rawhide compose report: 20221114.n.0 changes

[Fedora Rawhide Report]

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

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   70
Downgraded packages: 0

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

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

= ADDED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20221114.n.0.ppc64le.tar.xz
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20221114.n.0.ppc64le.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20221114.n.0.ppc64le.qcow2

= DROPPED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20221113.n.0.s390x.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  GMT-6.4.0-4.fc38
Old package:  GMT-6.4.0-3.fc38
Summary:  Generic Mapping Tools
RPMs: GMT GMT-common GMT-devel GMT-doc
Size: 66.30 MiB
Size change:  3.24 KiB
Changelog:
  * Sat Nov 12 2022 Sandro Mani  - 6.4.0-4
  - Rebuild (gdal)


Package:  OpenSceneGraph-3.6.5-11.fc38
Old package:  OpenSceneGraph-3.6.5-10.fc37
Summary:  High performance real-time graphics toolkit
RPMs: OpenSceneGraph OpenSceneGraph-Collada OpenSceneGraph-OpenEXR 
OpenSceneGraph-devel OpenSceneGraph-examples OpenSceneGraph-examples-SDL 
OpenSceneGraph-examples-fltk OpenSceneGraph-examples-gtk OpenSceneGraph-gdal 
OpenSceneGraph-gstreamer OpenSceneGraph-libs OpenThreads OpenThreads-devel 
mingw32-OpenSceneGraph mingw32-OpenSceneGraph-tools mingw64-OpenSceneGraph 
mingw64-OpenSceneGraph-tools
Size: 205.56 MiB
Size change:  10.20 MiB
Changelog:
  * Sat Nov 12 2022 Sandro Mani  - 3.6.5-11
  - Rebuild (gdal)


Package:  PDAL-2.4.3-3.fc38
Old package:  PDAL-2.4.3-1.fc37
Summary:  Point Data Abstraction Library
RPMs: PDAL PDAL-devel PDAL-doc PDAL-libs
Size: 45.25 MiB
Size change:  8.80 KiB
Changelog:
  * Wed Nov 09 2022 Markus Neteler  2.4.3-2
  - SPDX license tag update

  * Sat Nov 12 2022 Sandro Mani  - 2.4.3-3
  - Rebuild (gdal)


Package:  ProDy-2.3.0-1.fc38
Old package:  ProDy-2.2.0-5.fc37
Summary:  Application for protein structure, dynamics and sequence analysis
RPMs: python3-ProDy
Size: 21.99 MiB
Size change:  1.97 MiB
Changelog:
  * Sun Nov 13 2022 Antonio Trande  - 2.3.0-1
  - Release 2.3.0


Package:  R-rgdal-1.5.32-11.fc38
Old package:  R-rgdal-1.5.32-10.fc38
Summary:  Bindings for the 'Geospatial' Data Abstraction Library
RPMs: R-rgdal
Size: 17.28 MiB
Size change:  -3.84 KiB
Changelog:
  * Sat Nov 12 2022 Sandro Mani  - 1.5.32-11
  - Rebuild (gdal)


Package:  alembic-1.8.4-1.fc38
Old package:  alembic-1.8.3-4.fc37
Summary:  Open framework for storing and sharing scene data
RPMs: alembic alembic-devel alembic-libs
Size: 4.73 MiB
Size change:  -15.02 KiB

Package:  asahi-scripts-20221027-7.fc38
Old package:  asahi-scripts-20221027-6.fc38
Summary:  Miscellaneous admin scripts for Asahi Linux
RPMs: asahi-fwextract asahi-scripts dracut-asahi linux-firmware-vendor 
update-m1n1
Size: 53.62 KiB
Size change:  394 B
Changelog:
  * Mon Nov 14 2022 Davide Cavalca  20221027-7
  - Relax uboot-images-armv8 versioned dependency; Fixes: RHBZ#2140827


Package:  bes-3.20.13-2.fc38
Old package:  bes-3.20.13-1.fc38
Summary:  Back-end server software framework for OPeNDAP
RPMs: bes bes-devel bes-doc
Size: 329.88 MiB
Size change:  -1.28 MiB
Changelog:
  * Sat Nov 12 2022 Sandro Mani  - 3.20.13-2
  - Rebuild (gdal)


Package:  brewtarget-3.0.3-1.20221112gitv3.0.3.fc38
Old package:  brewtarget-3.0.2-1.20221027gitv3.0.2.fc38
Summary:  An open source beer recipe creation tool 
RPMs: brewtarget
Size: 23.18 MiB
Size change:  -2.68 KiB
Changelog:
  * Sat Nov 12 2022 Sandro  3.0.3-1
  - Update to 3.0.2 (RHBZ#2140886)
  - SPDX migration


Package:  celluloid-0.24-4.fc38
Old package:  celluloid-0.24-3.fc38
Summary:  A simple GTK+ frontend for mpv
RPMs: celluloid
Size: 1.31 MiB
Size change:  -339 B
Changelog:
  * Sun Nov 13 2022 Vitaly Zaitsev  - 0.24-4
  - Rebuilt due to mpv update.


Package:  cloudcompare-2.11.3-5.fc38
Old package:  cloudcompare-2.11.3-4.fc38
Summary:  3D point cloud and mesh processing software
RPMs: cloudcompare cloudcompare-doc
Size: 34.23 MiB
Size change:  7.73 KiB
Changelog:
  * Sat Nov 12 2022 Sandro Mani  - 2.11.3-5
  - Rebuild (gdal)


Package:  drupal7-backup_migrate-3.10-1.fc38
Old package:  drupal7-backup_migrate-3.7-7.fc37
Summary:  Backup the Drupal database and files or mi

Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 11, 2022 at 12:05:03PM +0100, Alexander Sosedkin wrote:
> On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar  wrote:
> > > As a result, more RPM packages will be reproducible:
> >
> > Where will this reproducibility stop?
> 
> Ideally, when it's achieved,
> and 100% of Fedora will be reproducible under reprotest =P

Exactly ;) My personal goal is to achieve 100% build reproducibility
for packages and other build artifacts. This Change is just one of the
first steps. Sources of non-reproducibility will be tackled one-by-one
as we find them.

> > An RPM package itself carry a build time in its RPM header.
> > Are we also going to fake this time in the name of
> > reproducibility?
> 
> My opinion: yes, please do (%use_source_date_epoch_as_buildtime).

Oh, I'm surprised we don't do this yet. I think we should.

> And fake the builder hostname (%_buildhost).

Yes. Maybe the best option is to set it when rebuilding an rpm to the
original value.

> And enable back --enable-deterministic-archives in binutils:
> (https://bugzilla.redhat.com/show_bug.cgi?id=1195883).
> And do whatever else is necessary to stop shipping binary packages
> that users can't reproduce bit-to-bit.

The compile-time setting is a brute hammer that affects too many things.
Instead we should clamp the times inteligently where this makes sense.
https://reproducible-builds.org/docs/archives/ describes the approaches
that Debian took. E.g. for tar they add a --clamp-mtime flag, which
seems a nicer approach. I think we'll want something similar for 'ar'.

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: [Test-Announce] 2022-11-14 @ 16:00 UTC - Fedora QA Meeting

[Luna Jernberg]

Will attend today :)

On Mon, Nov 14, 2022 at 10:09 AM Tim Flink  wrote:
>
> # Fedora Quality Assurance Meeting
> # Date: 2022-10-24
> # Time: 16:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location: #fedora-meeting on irc.libera.chat
>
> Greetings testers!
>
> F37 went GO last week and is due to be released immanently. Let's review any 
> remaining last-minute items for F37 and start looking at F38.
>
> If you have any items for the agenda, please reply to this email to suggest 
> them.
>
> == Proposed Agenda Topics ==
>
> 1. Previous meeting follow-up
> 2. Fedora 37 status
> 3. Fedora 38 changes
> 4. Test Day / community event status
> 4. Open floor
> ___
> 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
___
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: Heads-up: Side-tag rebuild due to minizip-ng soname bump

[Lukas Javorsky]

Hi,

please may you include my PRs before you start the rebuild?
>

I'll take a look at them. Thanks

 Are you also updating to 3.0.6? The latest version of OpenColorIO requires
> that version at a minimum.


I'm updating to the latest version of minizip-ng which is 3.0.7

On Thu, Nov 10, 2022 at 2:16 PM Richard Shaw  wrote:

> On Mon, Nov 7, 2022 at 6:41 AM Lukas Javorsky  wrote:
>
>> Hi,
>>
>> Minizip-ng has changed its soname name from "libminizip.so.3.0" to
>> "libminizip.so.3" thus we need to rebuild all the packages that are
>> requiring this soname.
>>
>
> Are you also updating to 3.0.6? The latest version of OpenColorIO requires
> that version at a minimum.
>
> 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
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 11, 2022 at 02:05:11PM +0100, Miro Hrončok wrote:
> On 11. 11. 22 11:53, Petr Pisar wrote:
> > V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a):
> > > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
> > > 
> > > == Summary ==
> > > 
> > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`.
> > > When an RPM package is built, mtimes of packaged files will be clamped
> > > to `$SOURCE_DATE_EPOCH`
> > 
> > Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If
> > I had a source file dated 1970-01-01 and installed it with "install -p", 
> > will
> > the packaged file retain that 1970-01-01 date, or will it be set to the date
> > of the latest changlog, e.g. 2022-11-11? In other words, will all files in
> > a package have the same mtime, or there won't be an mtime newer than the
> > changelog entry?
> 
> Capping maximal mtime. It's actually described in the detailed description:
> 
> """Clamping means that all files which would otherwise have a modification
> datetime higher than $SOURCE_DATE_EPOCH will have the modification datetime
> changed to $SOURCE_DATE_EPOCH; files with mtime lower (or equal) to
> $SOURCE_DATE_EPOCH will retain the original mtimes."""
> 
> Possibly "higher" should say "greater" instead, not sure.
> 
> > > which is already set to the date of the latest `%changelog` entry.
> > 
> > What's a changelog entry date in case of rpmautospec changelog? Is it
> > a git AuthorDate or CommitDate?
> 
> I don't know from top of my head. There's also
> https://pagure.io/fedora-infra/rpmautospec/issue/209 which touches this
> topic a bit.

This is obviously an interesting question, but it's orthogonal to this
proposal. Here we'll take whatever rpmautospec generates as the last
timestamp. The details of that generation may even change over time,
as discussed in the issue.

> > > As a result, more RPM packages will be reproducible:
> > 
> > Where will this reproducibility stop? An RPM package itself carry a build
> > time in its RPM header. Are we also going to fake this time in the name of
> > reproducibility?
> 
> Not as part of this change proposal and I have no intention to propose such
> a thing.
> 
> > What value these faked timestamps have? E.g. a compiled file is a function 
> > not
> > only of its source, but also of the compiler. This proposed change removes
> > the compiler part from the timestamp. Will timestamps like this be helpful?
> 
> Are the current timestamps helpful?
> 
> > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate
> > all of them stamps from various data formats rather than trying to fake 
> > them?
> 
> I don't think it would be easier, but I have not tried that.
> 
> > Simply changing rpmbuild to set timestamp to 0 for all contained files, or
> > removing the time attribute from the RPM format completely?
> 
> RPM does not currently support this. RPM currently supports mtime clamping
> which is what we have proposed. You seem to not like the idea but you don't
> say so explicitly. If you prefer status quo over this change and would
> rather see the proposal rejected, please say so, so FESCo can evaluate your
> feedback when voting about the proposal.

I think we should not get rid of timestamps altogether. They are useful metadata
and even end users look at them occasionally. Our packaging guidelines say that
an effort must be made to preserve _upstream_ timestamps. We also know from
the experince with ostree systems that setting timestamps to 0 confuses some
software. Thus, I think we should clamp the timestamps as required to achieve
reproducible builds, but not more.

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

[Test-Announce] 2022-11-14 @ 16:00 UTC - Fedora QA Meeting

[Tim Flink]

# Fedora Quality Assurance Meeting
# Date: 2022-10-24
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat

Greetings testers!

F37 went GO last week and is due to be released immanently. Let's review any 
remaining last-minute items for F37 and start looking at F38.

If you have any items for the agenda, please reply to this email to suggest 
them.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 37 status
3. Fedora 38 changes
4. Test Day / community event status
4. Open floor
___
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