date:20230109

On Mon, Jan 09, 2023 at 11:53:17PM +0100, Kevin Kofler via devel wrote:
> Am Montag, 9. Jänner 2023 23:06:17 CET schrieb Zbigniew Jędrzejewski-Szmek:
> > On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > > Kevin Kofler via devel wrote:
> > > PS: The impression I get is that everything was deliberately rigged
> > > so that the vote would end up the way it did:
> > 
> > You're mixing up two things: a vote being "rigged" with a result you don't
> > like.
> 
> No, the result is NOT why I got the impression that the vote was rigged. The
> way that result was obtained is.

Exactly, you're just confirming what I wrote above.

A "vote being rigged" means that either the people who should be allowed to vote
couldn't, or that people who are not allowed to vote did, or that voters were
tricked or forced to vote differently, or that votes were miscounted.

None of this happened in this case. The fact that the absolute majority of FESCo
cast a vote makes the considerations simpler, because we know that the two votes
that were not cast would not have changed the result.

> In fact, I had explained exactly that in
> the remainder of the message, which you omitted from your quote and pushed
> to the bottom of the mail (and even that quotes only half of it) for some
> reason.

You message very verbosely explains why you think the result should be 
different.
That is not "rigged". That is other people deciding differently than you.

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 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote:
> Now I'm getting bit by the rpmautospec and COPR issue.

Please be more precise. How are you building the rpms?

If rpmautospec is used in COPR, and the build is started in a
compatible way, the release field should be the same as in koji.

> I'm trying to test rebuilds of all dependent packages for a new OpenColorIO
> release, but usd uses rpmautospec and in Fedora it's usd--16 but
> COPR is calculating it as usd--9 so the Fedora version has a
> higher NEVR.

First of all, if you e.g. want to test the rebuilt packages on your system,
you can always install a lower version than the one currently released.
Dnf allows both downgrades and installations of a specific package and
a specific package version.

Second, how exactly are you building the package?
Looking at [1], you used "Source Type: SRPM or .spec file upload".
How was it generated?

[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/

Both 'fedpkg srpm' and uploading that to copr, and letting copr build from
dist-git should result in the expected release. (Though without other steps
it'll still be the same as the version in Fedora release, so you'll need
to tell dnf to install that specific build.)

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 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-09 Thread Richard Shaw

Now I'm getting bit by the rpmautospec and COPR issue.

I'm trying to test rebuilds of all dependent packages for a new OpenColorIO
release, but usd uses rpmautospec and in Fedora it's usd--16 but
COPR is calculating it as usd--9 so the Fedora version has a
higher NEVR.

Now what am I supposed to do?

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

[Bug 2159571] New: perl-Email-Stuffer-0.019 is available

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

Bug ID: 2159571
   Summary: perl-Email-Stuffer-0.019 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Email-Stuffer
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.019
Upstream release that is considered latest: 0.019
Current version/release in rawhide: 0.018-8.fc37
URL: http://search.cpan.org/dist/Email-Stuffer/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/13425/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2159571
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2159570] New: perl-Email-MIME-Kit-3.000007 is available

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

Bug ID: 2159570
   Summary: perl-Email-MIME-Kit-3.07 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Email-MIME-Kit
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.07
Upstream release that is considered latest: 3.07
Current version/release in rawhide: 3.06-15.fc37
URL: http://search.cpan.org/dist/Email-MIME-Kit/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/12953/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2159570
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2159569] New: perl-Email-Address-1.913 is available

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

Bug ID: 2159569
   Summary: perl-Email-Address-1.913 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Email-Address
  Keywords: FutureFeature, Triaged
  Assignee: spo...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.913
Upstream release that is considered latest: 1.913
Current version/release in rawhide: 1.912-14.fc37
URL: http://search.cpan.org/dist/Email-Address/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2848/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2159569
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2159569] perl-Email-Address-1.913 is available

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2159569
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-01-09 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-afa80a1455   
cacti-1.2.23-1.el7 cacti-spine-1.2.23-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-96ef72f1b2   
viewvc-1.1.30-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-6569f44fa5   
moin-1.9.11-1.el7


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

awstats-7.8-3.el7
libxo-1.6.0-2.el7

Details about builds:



 awstats-7.8-3.el7 (FEDORA-EPEL-2023-f91d2e3281)
 Advanced Web Statistics

Update Information:

Security fix for CVE-2022-46391

ChangeLog:

* Mon Jan  9 2023 Tim Jackson  - 7.8-3
- Fix CVE-2022-46391 (rhbz #2150632)
- Clean up spec file, removing conditionals for now-obsolete releases

References:

  [ 1 ] Bug #2150632 - CVE-2022-46391 awstats: XSS due to improper input checks
https://bugzilla.redhat.com/show_bug.cgi?id=2150632




 libxo-1.6.0-2.el7 (FEDORA-EPEL-2023-4b2bbb0153)
 A Library for Generating Text, XML, JSON, and HTML Output

Update Information:

libxo library available now in EPEL

ChangeLog:

* Thu Jul 21 2022 Fedora Release Engineering  - 
1.6.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Aug 11 2021 Kanitha Chim  - 1.6.0-1
- Initial package


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

[Bug 2158853] perl-System-Info-0.063 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-5dcad355f2 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-5dcad355f2`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-5dcad355f2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2158853
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

2023-01-09 Thread Siddhesh Poyarekar

On Mon, Jan 9, 2023 at 5:53 PM Kevin Kofler via devel
 wrote:
> * It made wrong assumptions about the performance impact of
> _FORTIFY_SOURCE=3, which, compared to the already existing (!)
> _FORTIFY_SOURCE=2, appears to actually have NO performance impact at all
> (!), only compared to no _FORTIFY_SOURCE at all.

Your larger point is correct (and what I've been talking about too)
but for the sake of accuracy: there is no known overhead due to
_FORTIFY_SOURCE=2 either AFAIK; there's one publicly available
analysis[1] that shows a minor speedup (!) in ffmpeg due to
_FORTIFY_SOURCE=2.  The ~1.3% overhead I mentioned was for
"-fstack-protector-strong -fstack-clash-protection
-D_FORTIFY_SOURCE={2,3} -D_GLIBCBXX_ASSERTIONS" and IMO it should
mainly be attributed to -fstack-protector-strong
-fstack-clash-protection and perhaps -D_GLIBCXX_ASSERTIONS.

Thanks,
Sid

[1] https://zatoichi-engineer.github.io/2017/10/06/fortify-source.html
___
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: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Demi Marie Obenour wrote:

> On 1/6/23 20:35, Frank Ch. Eigler wrote:
>> (There are exist other profiling tools and techniques that do not
>> require frame pointer recompilation, but whatever.)
> 
> Which ones?  I would love for them to exist, and I believe there is
> work being done in that direction, but I am not aware of any yet.

For speed:
https://valgrind.org/info/tools.html#cachegrind
or
https://valgrind.org/info/tools.html#callgrind
with (in both cases)
https://apps.kde.org/kcachegrind/

For memory (RAM) usage:
https://valgrind.org/info/tools.html#massif
with
https://apps.kde.org/massif-visualizer/

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

python-cryptography license fix

2023-01-09 Thread Charalampos Stratakis

The license of python-cryptography was changed to SPDX and also fixed after
clarification from upstream from "ASL 2.0 or BSD" to "(Apache-2.0 OR
BSD-3-Clause) AND PSF-2.0"

-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, 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

Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

Miro Hrončok wrote:
> Considering the mass rebuild is happening really soon, I feel like
> repeating the vote later is not helpful, but if people want to, we can
> surely run the vote again. However, I am confident the result will be the
> same.

With all this talk about the mass rebuild being imminent, why can the change 
not be pushed back to Fedora 39, to have more time for discussion, for 
evaluating the impact in (post-branching) Rawhide (with almost 6 months time 
to try out things before the next mass rebuild), and to have a realistic 
possibility of reverting it BEFORE it reaches end users of stable releases 
(if the impact is as bad as I fear)?

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: Schedule for Tuesday's FESCo Meeting (2023-01-03)


Am Montag, 9. Jänner 2023 23:06:17 CET schrieb Zbigniew Jędrzejewski-Szmek:

On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:

Kevin Kofler via devel wrote:
PS: The impression I get is that everything was deliberately 
rigged so that 
the vote would end up the way it did:


You're mixing up two things: a vote being "rigged" with a result you don't
like.


No, the result is NOT why I got the impression that the vote was rigged. 
The way that result was obtained is. In fact, I had explained exactly that 
in the remainder of the message, which you omitted from your quote and 
pushed to the bottom of the mail (and even that quotes only half of it) for 
some reason.



Absolute majority (6 out of 9) of voting members voted in favour.


As I believe, as a consequence of the incomplete and misleading data that 
was provided to them in the one-sided discussion, in particular, the flawed 
comparison with the _FORTIFY_SOURCE=3 change. (It might not have mattered 
to you personally, but you were the only one who had been in favor of that 
change from the beginning anyway.)


The changes to this Change proposal were not considered major 
changes that would require a repeat discussion on fedora-devel,


And that was a fatal misjudgement. A crucial point that swayed the vote was 
a comparison with another change, the _FORTIFY_SOURCE=3 one, which had not 
previously come up in the discussion. Therefore, we had no chance to debunk 
the flawed comparison. And flawed it was:
* It neglected that _FORTIFY_SOURCE=3 is a security feature for end users 
whereas frame pointers are a developer-only feature.
* It made wrong assumptions about the performance impact of 
_FORTIFY_SOURCE=3, which, compared to the already existing (!) 
_FORTIFY_SOURCE=2, appears to actually have NO performance impact at all 
(!), only compared to no _FORTIFY_SOURCE at all.
* It came with an implied accusation of hypocrisy (double standards) 
against the Tools Team which makes no sense when you consider the above 
details, and the Tools Team was given no chance to defend themselves. That 
matters particularly because that false accusation was used to justify 
ignoring the Tools Team's stakeholder opinion on the frame pointer change.



If you were to look at FESCo meeting logs, this happens every once in
a while: a proposal is made, it get's a few +1 votes but not enough
and is effectively rejected, so a different-but-similar proposal is
made and the vote repeats. Sometimes we go through a few of those in
one meeting. In this case this was split over two meetings, but is not
substantially different.


This is substantially different in that it was publicly communicated that 
the change was rejected and then suddenly FESCo changed their mind out of 
the blue. That is different from voting on multiple proposal variants 
during the same meeting and then communicating the final outcome.


(And by the way, what was ultimately accepted was not really a *different* 
proposal, but effectively the same as your proposal that had been voted 
down a couple weeks earlier.)



Discussion was ongoing all that time, both publicly and privately,


This was not transparent at all. We all got the impression that the 
discussion was closed and the feature conclusively rejected, and had no 
idea that there was still a discussion ongoing to which we were not 
invited.



and there is nothing that says that FESCo members must not change their
votes based on new information.


But, as I explained above, said "new information" was misleading or 
incorrect, and the stakeholders were not given a chance to prove that.



The intent of this particular proposal is to learn and adjust based on the
feedback from the initial implementation. The specific flags on different
architectures can and should be adjusted to get the desired result.


That is effectively treating stable Fedora releases and their users as 
guinea pigs. Especially since you want to wait 2 whole release cycles 
before even considering a revert (and there is already the expectation from 
the Change owners that a revert will have the burden of proof reversed in 
its disfavor, which I consider unacceptable, but which was neither 
confirmed nor denied by FESCo – that is not what I would consider a 
provisional acceptance of the change).


I really do not see why gathering data cannot be done in a side tag and/or 
as a Fedora Remix. Experiments belongs into an experimental branch, not 
into a stable release.



An interesting phenomenon is that before the Change was approved, most
of the feedback on fedora-devel was about whether we need the change
at all, and how horrible the performance degradation will be, and what
distribution to switch to. After it was approved, the feedback
immediately became more technical, with suggestions about specific
flags and architecture differences.


That is because the people have apparently resignated to accept that Fedora 
has decided to become unusable and are

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> Kevin Kofler via devel wrote:
> > Still, it gives an extremely bad impression of rushing this through
> > without giving anybody the chance to object.
> > 
> > I also do not see why this needed to be approved for F38 on such a short
> > notice and could not wait for F39.
> 
> PS: The impression I get is that everything was deliberately rigged so that 
> the vote would end up the way it did:

You're mixing up two things: a vote being "rigged" with a result you don't
like. Absolute majority (6 out of 9) of voting members voted in favour.

The rules in Fedora are that FESCo gets to vote on certain things. There is a
time reserved for public discussion, but at some point a vote is scheduled, and
at that point we often discuss things in a meeting and vote one way or another
without futher input from outside.

It does happen occasionally that repeat votes happen, for example a resolution
is approved, but somebody immediately raises some additional concern so it is
amended. At that point we don't seek repeat opinions from all stakeholders.
Things would take forever, and most stakeholders wouldn't change their opinion
anyway for some minor detail.

The changes to this Change proposal were not considered major changes that would
require a repeat discussion on fedora-devel, but were instead a narrowing and
clarification of the proposal, so the vote was held at the earliest convenience.
It is important that *FESCo members* know about the vote, which obviously
they did in this case because absolute majority did vote.

If you were to look at FESCo meeting logs, this happens every once in a while:
a proposal is made, it get's a few +1 votes but not enough and is effectively
rejected, so a different-but-similar proposal is made and the vote repeats.
Sometimes we go through a few of those in one meeting. In this case this was
split over two meetings, but is not substantially different. Discussion was
ongoing all that time, both publicly and privately, and there is nothing that
says that FESCo members must not change their votes based on new information.

The intent of this particular proposal is to learn and adjust based on the
feedback from the initial implementation. The specific flags on different
architectures can and should be adjusted to get the desired result.

An interesting phenomenon is that before the Change was approved, most of the
feedback on fedora-devel was about whether we need the change at all, and how
horrible the performance degradation will be, and what distribution to switch
to. After it was approved, the feedback immediately became more technical, with
suggestions about specific flags and architecture differences.

If we had approved the Change 3 months ago, we would have gotten that useful
part of the feedback much earlier. For me the lesson is that we shouldn't dawdle
on high-stakes controversial votes, but instead approve ambitious proposals
early and have more time to adjust or even revert if it turns out necessary.

Zbyszek

> 1. A new ticket was filed, in order to exclude the participants of the 
> previous discussion.
> 2. The people watching the old ticket were NOT notified.
> 3. The Tools Team was NOT notified.
> 4. The proponents of the Change, on the other hand, WERE notified.
> 
> So, with all of the above, the discussion participants were preselected to 
> only include people in favor of the change.
> 
> 5. The ticket was filed in the middle of the holiday season. Many people in 
> Europe are on vacation until today.
> 6. There was NO thread about the reopening of the discussion on the mailing 
> list. The first message that mentioned the issue on the mailing list was 
> "Schedule for Tuesday's FESCo Meeting (2023-01-03)" from 2023-01-03 09:39 
> UTC, only 7 hours 21 minutes before the meeting. This is in contrast to the 
> Change policy requiring at least a week between the mailing list 
> announcement and opening the FESCo ticket.
> 7. Only 4 days had elapsed between the (unannounced) opening of the ticket 
> and the vote. This is clearly insufficient. The one week in the Change 
> policy that I cited above is designed as a minimum time for discussion.
> 8. The change was approved only 2 weeks before the mass rebuild, leaving 
> little to no time to revert it in the contigency case.
> 
> So, this ensured that whoever was deliberately NOT invited had no chance to 
> find out by themselves and intervene before it was too late.
> 
> This strikes me as extremely intransparent and undemocratic.
> 
> Therefore, I hereby request that the vote be annulled as having happened in 
> violation of the Change policy.
> 
> 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:

Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Mark Wielaard

Hi Matthew,

On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > Therefore, I hereby request that the vote be annulled as having happened
> > in violation of the Change policy.
> 
> So, from a purely "what are the rules?" view, the Change process says:
> 
>   FESCo will vote to approve or deny a change proposal in accordance with
>   the FESCo ticket policy.
> 
> ... and I won't quote all of that, but looking at
> https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy...
> I don't see any violations, either in the letter or the spirit of what is
> written.
> 
> And, from a practical point of view, since this passed with six +1 votes,
> I'm not sure what benefit canceling and re-voting would really add.

It does feel to me as being against the spirit, and only not against
the letter because it is presented as a "revote" on an existing change
proposal instead of proposing a new change proposal (which this really
is IMHO).

Practically people have started preparing for the mass rebuild at the
end of last year since that was when the change checkpoint for change
proposals requiring a mass rebuild was. And at that point the Change
Proposal was already decided to not be included. So it was never
expected that the build flags would suddenly change so drastically
(and some flags are still wrong). Cancelling and backing out these
last minute changes will cause a lot less stress.

Socially I think it will be better for all involved if the policies on
revoting and/or reintroducing a change proposal are first clarified
before allowing a revote. At the moment everybody involved seems hurt
because of the unclear policy. Not having clear rules on the needed
visibility and time needed to discuss this revote/resubmission of the
change proposal caused people to assume the worst about others. Lets
reset and take the time to heal first, so people start actually
talking about real solutions again.

Cheers,

Mark
___
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Tom Stellard


On 1/9/23 12:27, Kevin Kofler via devel wrote:

Am Montag, 9. Jänner 2023 21:02:48 CET schrieb Tom Stellard:

I think a good solution would be to move the proposal submission deadlines
a month earlier in the schedule.  There's only 3 weeks between the
"Changes Requiring Mass Rebuild" deadline and the mass rebuild.  I don't think 
3 weeks is really enough time for FESCO review/approval and
also getting the necessary patches reviewed and committed.


How would this have helped in this case? The original change proposal was 
actually submitted more than 6 months ago! It is just that it took 5 months to 
finally get to a vote (with whose outcome one FESCo member was then unhappy).



It wouldn't have helped in this case, but if we are discussing
changing the schedule to avoid holiday conflicts, then I think
moving the "Change Proposal Deadlines" earlier would
be better than shifting the whole schedule a few weeks.


The resubmission, on the other hand, happened one day AFTER the submission 
deadline for changes requiring a mass rebuild and hence was already late under 
the current process. Pushing the submission deadline earlier would not have 
changed that.

If we need a rule, then it needs to be that rejected changes cannot be 
resubmitted for reconsideration after the change submission deadline. Though 
FESCo could just vote to accept the late change anyway, so it would not really 
help if the resubmission comes from FESCo itself and if FESCo really wants it 
to happen. At most it could discourage such late reconsiderations.



Yes, I agree with this and I actually just proposed this up-thread.

-Tom


    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

___
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Tom Stellard


On 1/9/23 08:47, Matthew Miller wrote:


It might be useful to improve both the documented policies. The Changes
policy has nothing about reconsidering Changes in the current cycle that I
can see. (Or, actually, for that matter, for resubmitting in future cycles
either, unless i'm missing something.) And the FESCo ticket policy could
include a) some steps for wider communication, and b) maybe something about
holidays and other times which might need special consideration.



I would recommend that reconsidering (which I would describe as modifying and 
revoting)
Changes like this should not be allowed after the Proposal Submission Deadlines.
Making major decisions like this late in the process introduces too much risk 
(imo).

Looking at this specific change, part of the reason that it was accepted is 
because
it has a trivial opt-out mechanism, but the decision was made so late in the 
release
process that there may not be enough time for maintainers to opt-out before the
mass rebuild.

-Tom
___
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: Shorter Shutdown Timer (System-Wide Change proposal)

On Sat, Jan 07, 2023 at 12:59:26AM +0100, Peter Boy wrote:
> 
> > Am 06.01.2023 um 18:06 schrieb Michael Catanzaro :
> > 
> > ...
> > 
> > I think most of the feedback on this change can be summarized as:
> > 
> > (a) Specific services want longer timeouts.
> > 
> > This can already be configured via existing configuration mechanisms, so I 
> > think it's safe enough to ignore this problem. E.g. if a quick shutdown 
> > will brick your Pinephone modem or corrupt your database, then whatever 
> > service is involved there should request a larger timeout.
> 
> As several posts have shown, it is specifically not safe to ignore the 
> problem. It is a mystery to me how you can come to this assessment. 
> 
> We don't know if all affected services explicitly request a longer timeout. 
> We don't have a test procedure nor a QA criterion for this that is testable. 
> We don't know how many rely on the current default timeout because it has 
> worked so far. And in view of these known circumstances to introduce a "quick 
> shutdown" so nonchalantly and without exact data and tests is simply 
> irresponsible and endangers the good reputation of the distribution and 
> especially Fedora Server known to run reliably stable with (or in spite of) a 
> quick release sequence. 
> 
> And it does not take into account in any way the other fact, expressed here 
> in several posts, that it is not a problem of individual, singular processes, 
> but the interaction of several processes in the specific shutdown situation, 
> whereby individual processes can not terminate themselves as quickly as they 
> do in normal circumstances. And it's obviously a non-determinant random 
> process that turns out differently for each shutdown.
> 
> The current timeout may not be perfect, but long experience shows that in the 
> vast majority of cases the value results in a safe, uncorrupted shutdown.  We 
> do not have a wave of complaints about system corruption after shutdown.
> 
> And the current value may be the result of a wild guess. I do not know how it 
> was achieved. But replacing one wild guess with another wild guess that 
> introduces additional, unpredictable risks is not a sound and robust approach 
> (and that is true not only for server, by the way).

The current default is mostly arbitrary. It was just selected as a nice round
value, in the spirit of "let's pick something large enough to be larger than any
realistic process will ever need".

I think you're misinterpreting Michael's words that "it's safe enough to ignore 
this problem".
IIUC, the idea is to set a longer timeout in those cases at the service level.
I.e. the problem is "ignored" only in the sense of the system-wide default being
smaller, and the specific services setting a higher timeout as required.

Also, even with the current high defaults, some services still actually time 
out.
If something bad happens in that case, it is already happening. This is bad
for users in at least two ways. First, because they have to wait and wait, and
second because the timeout is actually hit so things *do* get terminated but 
when
this happens, we do nothing. The idea would be to lower the default timeouts,
but also approach any cases where we hit the timeout much more seriously.

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 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Mon, Jan 09, 2023 at 11:04:11AM +0100, Lennart Poettering wrote:
> On Fr, 06.01.23 11:06, Michael Catanzaro (mcatanz...@redhat.com) wrote:
> 
> > Maybe instead of SIGKILL, we should send SIGQUIT instead. That way abrt
> > should complain next time you boot and users will have an opportunity to
> > report bugs to the package maintainer, instead of the problem being forever
> > ignored. Killing things silently makes it real hard to report bugs. And as a
> > bonus, the core dump should actually show what the process was doing at the
> > time it got killed. The more I think about it, the better this sounds.
> > Currently this can be configured using FinalKillSignal=SIGQUIT, so we'd just
> > need to figure out the right place to put that.
>
> > systemd already has a configuration option for this so we'd just have to
> > turn it on.
> 
> Don't use FinalKillSignal=SIGQUIT.
> 
> Use TimeoutStopFailureMode=abort instead. (which covers more ground,
> and sends SIGABRT rather than SIGQUIT on failure, which has the same
> effect: coredumping).

I guess we could add DefaultTimeoutStopFailureMode= setting and a
-Ddefault-default-timeout-stop-failure-mode= compile-time default for it.

Barring that, it's possible to do a per-type drop-ins:
/usr/lib/systemd/system/{service,scope,mount}.d/10-kill-mode.conf
or so, maybe for more types. But that'd be harder to override and more
messy in general.

> That said: dumping core is potentially extremely expensive (web
> browsers have gigabytes of virtual memory that we might end up
> processing and compressing). Quite often the stuff that is slow when
> exiting is also the stuff that is expensive to dump.
> 
> Hence, I am not sure you'll gain that much via this mechanism: you cut
> a long operation short and then execute long operation as result. You
> might end delaying things more than you hope shortening them.

That is true, but I don't think that it's an actual reason to not do this. The
job for the coredump gets a separate timeout, so the coredump would generally
run successfully during shutdown.

It'll obviously delay the shutdown, making the whole thing even more painful.
I assume that we would treat any such cases as bugs. If we get the coredumps
reported though abrt, it'd indeed make it easier to diagnose those cases.

--

Digging into some details:

It seems that coredumping usually takes a few seconds at most, even with
gigabytes of RSS. I won't cite specific numbers, since that's just a very
biased sample on my laptop gathered via
  journalctl --grep 'systemd-coredump@.*: Consumed'

If the default stop timeout is set to 15s, we would probably have to raise the
timeout for the systemd-coredump@.service to something higher. This would let
the coredump process run successfully in most cases.

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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]


Am Montag, 9. Jänner 2023 21:02:48 CET schrieb Tom Stellard:

I think a good solution would be to move the proposal submission deadlines
a month earlier in the schedule.  There's only 3 weeks between the
"Changes Requiring Mass Rebuild" deadline and the mass rebuild. 
 I don't think 3 weeks is really enough time for FESCO review/approval and

also getting the necessary patches reviewed and committed.


How would this have helped in this case? The original change proposal was 
actually submitted more than 6 months ago! It is just that it took 5 months 
to finally get to a vote (with whose outcome one FESCo member was then 
unhappy).


The resubmission, on the other hand, happened one day AFTER the submission 
deadline for changes requiring a mass rebuild and hence was already late 
under the current process. Pushing the submission deadline earlier would 
not have changed that.


If we need a rule, then it needs to be that rejected changes cannot be 
resubmitted for reconsideration after the change submission deadline. 
Though FESCo could just vote to accept the late change anyway, so it would 
not really help if the resubmission comes from FESCo itself and if FESCo 
really wants it to happen. At most it could discourage such late 
reconsiderations.


   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: static USERMODEHELPER_PATH

2023-01-09 Thread Simo Sorce

On Fri, 2023-01-06 at 18:21 +0100, Lennart Poettering wrote:
> On Fr, 06.01.23 10:10, Steve Grubb (sgr...@redhat.com) wrote:
> 
> > Hello,
> > 
> > On Friday, January 6, 2023 9:33:12 AM EST Lennart Poettering wrote:
> > > On Do, 05.01.23 20:17, Steve Grubb (sgr...@redhat.com) wrote:
> > > > I work on RHEL security problems. I have been looking into a number of
> > > > exploits and I think we have a problem that has an easy fix. We are not
> > > > using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There
> > > > are a number of exploits that overwrite the path to modprobe and then
> > > > pass something weird that causes modprobe to be invoked. But instead of
> > > > modprobe, it's their reverse shell.
> > > 
> > > umh is such a problematic interface. The processes forked off that way
> > > live in a weird netherworld besides the init system, in the root
> > > cgroup (and that even though inner cgroups in cgroupsv2 are not
> > > supposed to have processes in them) without any of the resource or
> > > security restrictions we otherwise make on all of userspace.
> > 
> > One approach to solving this is to use selinux policy.
> 
> selinux cannot apply resource controls, not can it arrange processes
> properly in the cgroup tree, nor can it apply seccomp filters,
> namespacing and so on.
> 
> selinux can do some things, sure, but an init system is not a MAC, it
> does a lot more (and also a lot less).
> 
> > Yeah, that's another approach that may have merit. But with the asynchronous
> > nature of that approach, I don't know how the kernel would know it can now
> > make calls into the module it needed to have loaded.
> 
> Well, umh is async too in a way, kernel must wait for the userspace
> process to finish. There's not much of a difference to say "fork off +
> wait for process exit" and "send netlink message to userspace + wait
> for reply".

If I remember correctly the claim was that umh is robust if the user
space fails and just terminates. As then the kernel know user space is
gone, whether it got the data it needed or not and can stop waiting.

While messages may never get replied to and require handling timeouts
and then handling the case a user space process was slow and ignoring
late replies.

Not sure this is really a good point given waiting indefinitely for a
user space program that hangs for some reason seems worse to me.

When I had to code a call from knfsd to user space for GSS-Proxy I used
unix sockets. I think that is better than netlink in some cases as
sockets are simpler to handle from user space programs and are also
easily namespaced...

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Tom Stellard


On 1/9/23 11:18, Neal Gompa wrote:

On Mon, Jan 9, 2023 at 2:11 PM Daniel P. Berrangé  wrote:


On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:

On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:

PS: The impression I get is that everything was deliberately rigged so that
the vote would end up the way it did:

1. A new ticket was filed, in order to exclude the participants of the
previous discussion.
2. The people watching the old ticket were NOT notified.
3. The Tools Team was NOT notified.
4. The proponents of the Change, on the other hand, WERE notified.


I agree with your earlier post that this did not have enough visibility,
enough notice, or enough time. I was certainly taken by surprise, and I was
trying to keep an eye on this one in particular. (Having the discussion
under "Schedule for Tuesday's FESCo Meeting" didn't help it jump out at me
either.)


Holding a FESCo meeting and vote on the very first working day after
the long xmas / new year holiday is not exactly good timing if you
want contributors to be broadly aware it is happening[1]. I might
humbly suggest that next year, any important meetings that would
naturally fall in the 1st week, be postponed until the 2nd week
of Jan.



We should push out the entire schedule one to two weeks then. We keep
losing time in the schedule, and we shouldn't lose even more.



I think a good solution would be to move the proposal submission deadlines
a month earlier in the schedule.  There's only 3 weeks between the
"Changes Requiring Mass Rebuild" deadline and the mass rebuild.  I don't think
3 weeks is really enough time for FESCO review/approval and also getting the
necessary patches reviewed and committed.

- Tom





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

___
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Daan De Meyer via devel

> I think it would save everyone a bit of time if we restricted the change
> to x86-64.  We do not have much experience with the -mbackchain flag
> that was added at the last minute on s390x.  The change owners have
> stated that they aren't interested in s390x.  IBM doesn't want this.
> Platform Tools does not want it.  I doubt the desktop team does GNOME
> performance analysis on s390x on Fedora.  I'm not even sure if the tools
> support backchain-based unwinding; it's not a frame pointer after all.
> Maybe -mbackchain won't cause any issues in after all, but we just don't
> have the time to test this before the mass rebuild.

I had a look at the kernel unwinding code for s390 and it seems to use
the backchain if it's available and fall back to the frame pointer otherwise.
So from our end (change proposal authors) we're OK with dropping
mbackchain for s390 and only using fno-omit-frame-pointer for s390.
We'll open a PR to change this in the rpm macros.

> As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on
> i686 is known to break certain packages (although I worked around this
> in glibc last year), simply because the reduced number of registers
> makes it impossible for GCC to compile certain functions with inline
> assembly in them.  As with s390x, the concrete impact is not known at
> this point, and we are out of time for test builds.

Given these issues should manifest as compilation failures, we should notice
very clearly once the mass rebuild starts if there's a bigger problem. If 
there's
only a few packages that run into issues, they can opt-out. If there's larger 
problems,
we can remove frame pointers from i686.

> Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another
> last-minute addition without any clear justification.  (On AArch64, the
> link register allows one to recover the address of the immediate caller
> even if a leaf function does not have a frame pointer.  That's not
> possible on x86-64, where the caller's address must be read from the
> stack, and that has to be based on the frame pointer.)  Just because the
> compiler option is there to enable doesn't mean it does anything useful
> in this context.

As I mentioned in the fesco ticket, the kernel unwinder looks at the
frame pointer register (x29) first when starting an unwind on aarch64 before 
looking
at the link register. As such, it seems logical to require frame pointers to be 
available
in leaf functions so the frame pointer register is available to start 
unwinding. I'm happy
to be proven wrong here so we can remove mno-omit-leaf-frame-pointer for 
aarch64.

Cheers,

Daan De Meyer


From: Daan De Meyer 
Sent: 09 January 2023 19:21
To: Matthew Miller; Development discussions related to Fedora
Subject: Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was 
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

> I think it would save everyone a bit of time if we restricted the change
> to x86-64.  We do not have much experience with the -mbackchain flag
> that was added at the last minute on s390x.  The change owners have
> stated that they aren't interested in s390x.  IBM doesn't want this.
> Platform Tools does not want it.  I doubt the desktop team does GNOME
> performance analysis on s390x on Fedora.  I'm not even sure if the tools
> support backchain-based unwinding; it's not a frame pointer after all.
> Maybe -mbackchain won't cause any issues in after all, but we just don't
> have the time to test this before the mass rebuild.

I had a look at the kernel unwinding code for s390 and it seems to use
the backchain if it's available and fall back to the frame pointer otherwise.
So from our end (change proposal authors) we're OK with dropping
mbackchain for s390 and only using fno-omit-frame-pointer for s390.
We'll open a PR to change this in the rpm macros.

> As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on
> i686 is known to break certain packages (although I worked around this
> in glibc last year), simply because the reduced number of registers
> makes it impossible for GCC to compile certain functions with inline
> assembly in them.  As with s390x, the concrete impact is not known at
> this point, and we are out of time for test builds.

Given these issues should manifest as compilation failures, we should notice
very clearly once the mass rebuild starts if there's a bigger problem. If 
there's
only a few packages that run into issues, they can opt-out. If there's larger 
problems,
we can remove frame pointers from i686.

> Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another
> last-minute addition without any clear justification.  (On AArch64, the
> link register allows one to recover the address of the immediate caller
> even if a leaf function does not have a frame pointer.  That's not
> possible on x86-64, where the caller's address must be read from the
> stack, and that has to be based on

Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

On Mon, Jan 9, 2023 at 2:11 PM Daniel P. Berrangé  wrote:
>
> On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> > On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > > PS: The impression I get is that everything was deliberately rigged so 
> > > that
> > > the vote would end up the way it did:
> > >
> > > 1. A new ticket was filed, in order to exclude the participants of the
> > > previous discussion.
> > > 2. The people watching the old ticket were NOT notified.
> > > 3. The Tools Team was NOT notified.
> > > 4. The proponents of the Change, on the other hand, WERE notified.
> >
> > I agree with your earlier post that this did not have enough visibility,
> > enough notice, or enough time. I was certainly taken by surprise, and I was
> > trying to keep an eye on this one in particular. (Having the discussion
> > under "Schedule for Tuesday's FESCo Meeting" didn't help it jump out at me
> > either.)
>
> Holding a FESCo meeting and vote on the very first working day after
> the long xmas / new year holiday is not exactly good timing if you
> want contributors to be broadly aware it is happening[1]. I might
> humbly suggest that next year, any important meetings that would
> naturally fall in the 1st week, be postponed until the 2nd week
> of Jan.
>

We should push out the entire schedule one to two weeks then. We keep
losing time in the schedule, and we shouldn't lose even more.




--
真実はいつも一つ！/ 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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]


Am Montag, 9. Jänner 2023 20:10:53 CET schrieb Daniel P. Berrangé:

Holding a FESCo meeting and vote on the very first working day after
the long xmas / new year holiday is not exactly good timing if you
want contributors to be broadly aware it is happening[1]. I might
humbly suggest that next year, any important meetings that would
naturally fall in the 1st week, be postponed until the 2nd week
of Jan. 


With regards,
Daniel

[1] Yes, I'm aware that not every part of the world will shutdown
during the xmas/new year period, but a large enough part of
our contributor base does that its worth taking into account


In fact, as I already mentioned, in Austria, this meeting happened *during* 
the school holidays and many companies' companywide holidays. E.g., at my 
employer, we resumed work today. It is commonplace here to have holidays 
until Epiphany, i.e., January 6, or even until the end of the week in which 
it falls. And this year, January 6 was a Friday, so even more places were 
on vacation until the end of the week.


   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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Daniel P . Berrangé

On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > PS: The impression I get is that everything was deliberately rigged so that 
> > the vote would end up the way it did:
> > 
> > 1. A new ticket was filed, in order to exclude the participants of the 
> > previous discussion.
> > 2. The people watching the old ticket were NOT notified.
> > 3. The Tools Team was NOT notified.
> > 4. The proponents of the Change, on the other hand, WERE notified.
> 
> I agree with your earlier post that this did not have enough visibility,
> enough notice, or enough time. I was certainly taken by surprise, and I was
> trying to keep an eye on this one in particular. (Having the discussion
> under "Schedule for Tuesday's FESCo Meeting" didn't help it jump out at me
> either.)

Holding a FESCo meeting and vote on the very first working day after
the long xmas / new year holiday is not exactly good timing if you
want contributors to be broadly aware it is happening[1]. I might
humbly suggest that next year, any important meetings that would
naturally fall in the 1st week, be postponed until the 2nd week
of Jan. 

With regards,
Daniel

[1] Yes, I'm aware that not every part of the world will shutdown
during the xmas/new year period, but a large enough part of
our contributor base does that its worth taking into account
-- 
|: 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

libmpc: fedora-ci.koji-build.tier0.functional failure

2023-01-09 Thread Jerry James

Hi everyone,

I built an update for libmpc in Rawhide a few weeks ago, then didn't
have time to follow up due to holiday-related travel.  (I'm one of
those people you saw on TV sitting around in airports due to canceled
flights.)  One test failed: fedora-ci.koji-build.tier0.functional.  I
have tried rerunning the tests a couple of times in the last few days,
and that test persists in failing.  The log says:

Waiting for Testing Farm...
[Pipeline] waitForWebhook
[Pipeline] retry
[Pipeline] {
[Pipeline] httpRequest
[Pipeline] }
[Pipeline] // retry
[Pipeline] echo
The status is now "complete"
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] catchError
[Pipeline] {
[Pipeline] error
[Pipeline] }
ERROR: Infrastructure Error

I don't know what "Infrastructure Error" means.  Can someone explain
that to me?  I can waive the test results, but I want to be sure
nothing is really wrong before doing so.

This libmpc update is ABI compatible with the previous version.  It
adds some functions, but does not alter ABI of the existing functions.

This is the update:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-8a8a64ee65

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

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

2023-01-09 Thread Demi Marie Obenour

On 1/6/23 20:35, Frank Ch. Eigler wrote:
> 
> Hi -
> 
>> The thing is that perf + flamegraphs makes your whole system much more
>> visible and so it's much easier to find these kind of gains in
>> specific scenarios.
> 
> (There are exist other profiling tools and techniques that do not
> require frame pointer recompilation, but whatever.)

Which ones?  I would love for them to exist, and I believe there is
work being done in that direction, but I am not aware of any yet.
-- 
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

F38 proposal: Noto CJK Variable Fonts (Self-Contained Change proposal)

2023-01-09 Thread Ben Cotton

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

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 ==
Switch the default Noto CJK fonts for Chinese, Japanese and Korean
from static to variable fonts.

== Owner ==
* Name: [[User:pwu| Peng Wu]]
* Email: p...@redhat.com


== Detailed Description ==
In order to reduce the font size in Noto CJK fonts, we plan to switch
to use the variable fonts by default.

# Split the google-noto-cjk-fonts package into
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts, and
provide the variable fonts in google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts.
# Drop several sub packages which are not installed by default from
the google-noto-cjk-fonts package.
## Like google-noto-sans-cjk-*-fonts, google-noto-sans-*-fonts,
google-noto-sans-mono-cjk-*-fonts, google-noto-serif-cjk-*-fonts and
google-noto-serif-*-fonts
# Install the Noto CJK Variable Fonts by default.

Fedora Copr for testing: https://copr.fedorainfracloud.org/coprs/pwu/noto-cjk/

== Feedback ==


== Benefit to Fedora ==
The variable fonts will reduce the disk space usage and live image
size compared to the static fonts.

{| class="wikitable"
|+ RPM Size
|-
!  Size (bytes) !! Noto Sans CJK !! Noto Serif CJK
|-
| Static Fonts || 130674365 || 181621033
|-
| Variable Fonts || 64613100 || 56924710
|}

== Scope ==
* Proposal owners:
** Package four font packages for Noto CJK fonts
** Retire google-noto-cjk-fonts in Fedora rawhide
** Switch to install variable fonts by default in fedora-comps and langpacks
** Submit pull request to lorax templates to use
google-noto-sans-cjk-fonts in the boot.iso

* Other developers:

* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==

When upgrade, the variable fonts will be installed by default.

== How To Test ==

* Please upgrade to Fedora 38 or rawhide to get the latest fonts
* Install the variable fonts: google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts
** Check the google-noto-sans-cjk-ttc-fonts and
google-noto-serif-cjk-ttc-fonts packages are replaced
* Then use CJK locales to check if the new fonts have any problem

== User Experience ==

This new variable fonts will reduce the disk space usage and live image size.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: Use the static fonts by default -
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts
* Contingency deadline: N/A
* Blocks release? N/A


== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==

This new variable fonts will reduce the disk space usage and live image size.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: Noto CJK Variable Fonts (Self-Contained Change proposal)

2023-01-09 Thread Ben Cotton

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

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 ==
Switch the default Noto CJK fonts for Chinese, Japanese and Korean
from static to variable fonts.

== Owner ==
* Name: [[User:pwu| Peng Wu]]
* Email: p...@redhat.com


== Detailed Description ==
In order to reduce the font size in Noto CJK fonts, we plan to switch
to use the variable fonts by default.

# Split the google-noto-cjk-fonts package into
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts, and
provide the variable fonts in google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts.
# Drop several sub packages which are not installed by default from
the google-noto-cjk-fonts package.
## Like google-noto-sans-cjk-*-fonts, google-noto-sans-*-fonts,
google-noto-sans-mono-cjk-*-fonts, google-noto-serif-cjk-*-fonts and
google-noto-serif-*-fonts
# Install the Noto CJK Variable Fonts by default.

Fedora Copr for testing: https://copr.fedorainfracloud.org/coprs/pwu/noto-cjk/

== Feedback ==


== Benefit to Fedora ==
The variable fonts will reduce the disk space usage and live image
size compared to the static fonts.

{| class="wikitable"
|+ RPM Size
|-
!  Size (bytes) !! Noto Sans CJK !! Noto Serif CJK
|-
| Static Fonts || 130674365 || 181621033
|-
| Variable Fonts || 64613100 || 56924710
|}

== Scope ==
* Proposal owners:
** Package four font packages for Noto CJK fonts
** Retire google-noto-cjk-fonts in Fedora rawhide
** Switch to install variable fonts by default in fedora-comps and langpacks
** Submit pull request to lorax templates to use
google-noto-sans-cjk-fonts in the boot.iso

* Other developers:

* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==

When upgrade, the variable fonts will be installed by default.

== How To Test ==

* Please upgrade to Fedora 38 or rawhide to get the latest fonts
* Install the variable fonts: google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts
** Check the google-noto-sans-cjk-ttc-fonts and
google-noto-serif-cjk-ttc-fonts packages are replaced
* Then use CJK locales to check if the new fonts have any problem

== User Experience ==

This new variable fonts will reduce the disk space usage and live image size.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: Use the static fonts by default -
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts
* Contingency deadline: N/A
* Blocks release? N/A


== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==

This new variable fonts will reduce the disk space usage and live image size.


-- 
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Florian Weimer

* Matthew Miller:

> BUT, I do not think it was done with malice, as "deliberately rigged"
> implies. I don't see that at all -- I see excitement and interest in moving
> forward on something that already has taken a long time, and looming
> practical deadlines.

No one spoke out when the tools team was called untrustworthy on the
FESCo ticket.  We can try explain it as an accident that the toolchain
team was sidelined afterwards.  But the overall sequence of events
certainly looks rather odd.

There are infrastructure problems as well.  Notifications in the Fedora
wiki system are broken (email notifications are spotty, but not
completely defunct; that did not matter here because the new FESCo
ticket was added to the change page only after the second vote), and
missing notifications for label updates on FESCo tickets (so it's hard
to spot that an issue is scheduled for discussion).  So unless you are
in the in-group or invited, it's hard to contribute.

All these issues contribute to a work environment that I find very
problematic.  The individual aspects are probably not deliberate, but
there's still an impact.

> And, from a practical point of view, since this passed with six +1 votes,
> I'm not sure what benefit canceling and re-voting would really add.

I'm pretty sure no one considered the impact on non-x86-64
architectures, given that the change as voted and submitted as a PR
would have broken the ppc64le and s390x buildroots.

I think it would save everyone a bit of time if we restricted the change
to x86-64.  We do not have much experience with the -mbackchain flag
that was added at the last minute on s390x.  The change owners have
stated that they aren't interested in s390x.  IBM doesn't want this.
Platform Tools does not want it.  I doubt the desktop team does GNOME
performance analysis on s390x on Fedora.  I'm not even sure if the tools
support backchain-based unwinding; it's not a frame pointer after all.
Maybe -mbackchain won't cause any issues in after all, but we just don't
have the time to test this before the mass rebuild.

As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on
i686 is known to break certain packages (although I worked around this
in glibc last year), simply because the reduced number of registers
makes it impossible for GCC to compile certain functions with inline
assembly in them.  As with s390x, the concrete impact is not known at
this point, and we are out of time for test builds.

Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another
last-minute addition without any clear justification.  (On AArch64, the
link register allows one to recover the address of the immediate caller
even if a leaf function does not have a frame pointer.  That's not
possible on x86-64, where the caller's address must be read from the
stack, and that has to be based on the frame pointer.)  Just because the
compiler option is there to enable doesn't mean it does anything useful
in this context.

Thanks,
Florian
___
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Miro Hrončok


On 09. 01. 23 17:47, Matthew Miller wrote:

On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:

PS: The impression I get is that everything was deliberately rigged so that
the vote would end up the way it did:

1. A new ticket was filed, in order to exclude the participants of the
previous discussion.
2. The people watching the old ticket were NOT notified.
3. The Tools Team was NOT notified.
4. The proponents of the Change, on the other hand, WERE notified.


I agree with your earlier post that this did not have enough visibility,
enough notice, or enough time. I was certainly taken by surprise, and I was
trying to keep an eye on this one in particular. (Having the discussion
under "Schedule for Tuesday's FESCo Meeting" didn't help it jump out at me
either.)

BUT, I do not think it was done with malice, as "deliberately rigged"
implies. I don't see that at all -- I see excitement and interest in moving
forward on something that already has taken a long time, and looming
practical deadlines.



Therefore, I hereby request that the vote be annulled as having happened
in violation of the Change policy.


So, from a purely "what are the rules?" view, the Change process says:

   FESCo will vote to approve or deny a change proposal in accordance with
   the FESCo ticket policy.

... and I won't quote all of that, but looking at
https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy...
I don't see any violations, either in the letter or the spirit of what is
written.

And, from a practical point of view, since this passed with six +1 votes,
I'm not sure what benefit canceling and re-voting would really add.


It might be useful to improve both the documented policies. The Changes
policy has nothing about reconsidering Changes in the current cycle that I
can see. (Or, actually, for that matter, for resubmitting in future cycles
either, unless i'm missing something.) And the FESCo ticket policy could
include a) some steps for wider communication, and b) maybe something about
holidays and other times which might need special consideration.


Most crucially, let's please drop the idea that anyone is acting out of malice. 
I'm
quite sure that everyone arguing passionately on both sides of this issue
has the best interest of Fedora and of Fedora Linux users in mind. Let's all
keep that framing in mind in the ongoing discussion. Thank you.


I feel like I need to add some words as a chair of the meeting where this was 
approved.


First, let me apologize for not suggesting that we should invite all the 
stakeholders to the meeting before we voted. In retrospect, this was a bad call 
on my part and I sincerely regret it.


When the ticket was opened on Decmeber 28th, when many Fedora contributors were 
spending time with their families etc. instead of on Fedora, I raised my 
concerns about the date, as I was afraid it might be approved by gaining +3 
votes in a week without the remaining FESCo members even knowing about this.


Fortunately, another FESCo member voted -1, hence this option was no longer my 
concern. That immediately pushed the ticket to the agenda of the meeting on 
January 3rd.


During the meeting, I felt like the proposal is gaining a (close) majority of 
the required votes and I decided to conduct the vote because I felt like all 
the discussion topics wrt this were already exhausted. I am not sure if this 
was a good call, but I am pretty confident that postponing the vote would have 
not changed the results.


Considering the mass rebuild is happening really soon, I feel like repeating 
the vote later is not helpful, but if people want to, we can surely run the 
vote again. However, I am confident the result will be the same.


--
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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]


Am Montag, 9. Jänner 2023 17:47:54 CET schrieb Matthew Miller:

And, from a practical point of view, since this passed with six +1 votes,
I'm not sure what benefit canceling and re-voting would really add.


Canceling the vote and requiring that the Change Policy be followed would 
mean that the change needs to be announced on the mailing list now and that 
a FESCo ticket may only be filed no earlier than 7 days from now, i.e., 
2023-01-16. So, it could be voted no earlier than the 2023-01-17 FESCo 
meeting. That is right before the mass rebuild, hence this Change must be 
pushed back to Fedora 39 at the earliest. So from a practical standpoint, 
even if the outcome of the vote were not to change, it would save Fedora 38 
from being pessimized by this change.


But I would hope that the discussion could actually convince those FESCo 
members that have switched to voting +1 due to the (IMHO unfair) comparison 
with the _FORTIFY_SOURCE=3 change to switch back.


   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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Frank Ch. Eigler

Matthew Miller  writes:

> So, from a purely "what are the rules?" view, the Change process says:
>   FESCo will vote to approve or deny a change proposal in accordance with
>   the FESCo ticket policy.
>
> ... and I won't quote all of that, but looking at
> https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy...
> I don't see any violations, either in the letter or the spirit of what is
> written.

OTOH:

"The motivation for the Changes process is to raise the visibility of
planned changes and make coordination and planning effort easier. It is
nearly impossible to follow all changes happening in a big project such
as Fedora. By providing a mechanism for sharing changes, it is easier
for contributors to know what is coming and to ensure that we can
address impacts of changes well before the release date. Change
proposals should be shared as early as possible, before the change is
implemented and even in the very early state of the idea, to gather
community feedback and review."

One could argue that taking a change that was widely discussed and
clearly rejected, then initiating a sudden revote without at least as
much publicity, undercuts the "easier for contributors to know what is
coming" or "gather community feedback and review" point of the whole
thing.

- FChE
___
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: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

2023-01-09 Thread Timothée Ravier

Working on having a better Firefox shipped as a Flatpak by default will please 
a lot of people that as asking for Firefox to be removed from the base image: 
https://github.com/fedora-silverblue/issue-tracker/issues/288

If we can have Cisco host a container image with openh264 as a Flatpak 
extension then that would be great as the extension would be pulled down 
automatically during flatpak update.
___
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

FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

2023-01-09 Thread Matthew Miller

On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> PS: The impression I get is that everything was deliberately rigged so that 
> the vote would end up the way it did:
> 
> 1. A new ticket was filed, in order to exclude the participants of the 
> previous discussion.
> 2. The people watching the old ticket were NOT notified.
> 3. The Tools Team was NOT notified.
> 4. The proponents of the Change, on the other hand, WERE notified.

I agree with your earlier post that this did not have enough visibility,
enough notice, or enough time. I was certainly taken by surprise, and I was
trying to keep an eye on this one in particular. (Having the discussion
under "Schedule for Tuesday's FESCo Meeting" didn't help it jump out at me
either.)

BUT, I do not think it was done with malice, as "deliberately rigged"
implies. I don't see that at all -- I see excitement and interest in moving
forward on something that already has taken a long time, and looming
practical deadlines. 

> Therefore, I hereby request that the vote be annulled as having happened
> in violation of the Change policy.

So, from a purely "what are the rules?" view, the Change process says:

  FESCo will vote to approve or deny a change proposal in accordance with
  the FESCo ticket policy.

... and I won't quote all of that, but looking at
https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy...
I don't see any violations, either in the letter or the spirit of what is
written.

And, from a practical point of view, since this passed with six +1 votes,
I'm not sure what benefit canceling and re-voting would really add.

It might be useful to improve both the documented policies. The Changes
policy has nothing about reconsidering Changes in the current cycle that I
can see. (Or, actually, for that matter, for resubmitting in future cycles
either, unless i'm missing something.) And the FESCo ticket policy could
include a) some steps for wider communication, and b) maybe something about
holidays and other times which might need special consideration.

Most crucially, let's please drop the idea that anyone is acting out of malice. 
I'm
quite sure that everyone arguing passionately on both sides of this issue
has the best interest of Fedora and of Fedora Linux users in mind. Let's all
keep that framing in mind in the ongoing discussion. Thank you.

-- 
Matthew Miller

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

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

2023-01-09 Thread Matthias Clasen

On Sat, Jan 7, 2023 at 9:31 AM Giuseppe Scrivano 
wrote:

>
> I've just opened a PR upstream for Podman to kill -9 all the remaining
> exec sessions when the container process terminates, so both --pid=host
> and --pid=private behaves in the same way.  It would solve the issue we
> are seeing.
>
>
That is fantastic. Thanks, Giuseppe!
___
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: RISC-V -- are we ready for more, and what do we need to do it?

2023-01-09 Thread Josh Boyer

On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
>
> On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  wrote:
> >
> > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> >  wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  wrote:
> > > >
> > > >
> > > >
> > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > >
> > > > > Summary from multi-year discussions/feedback on this:
> > > > > - We don't have proper hardware to put into the data center that holds
> > > > > servers used by Fedora infrastructure.
> > > > Right.  dev boards are not the solution here.  It's got to be something
> > > > that can be racked and with enough performance to matter.
> > > >
> > > > > - Not enough single and multi thread performance to avoid large impact
> > > > > to Fedora development.
> > > > Agreed.   Returning to a situation like we had with armv7 isn't
> > > > acceptable IMHO.
> > > >
> > > > >
> > > > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > > > good day we can keep up (if the builds aren't too large, e.g. GCC). We
> > > > > don't really run Bodhi thus once package is built it's immediately
> > > > > available. We run a very minimal setup right now (ideas to expand
> > > > > that).
> > > > It's fantastic we've got that far.  But clearly it's not viable long 
> > > > term.
> > >
> > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > cannot move forward until the proper hardware (and things around it)
> > > becomes available.
> > >
> > > >
> > > >
> > > > > Another news is that Fedora/RISCV Koji server (
> > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > Excellent.  I'll have to update my chroots and containers as the F38
> > > > bits start appearing.
> > >
> > > I am still tweaking the server configuration, but I should be ready
> > > for mass building soonish.
> > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > happen soon (I think).
> > >
> > > >
> > > > >
> > > > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > > > > yet convinced about their upstream support efforts (TBD).
> > > > Yes Veyron-v1 will have a BMC and will be rackable.   I have no
> > > > significant insight into the T-HEAD efforts other than they do work a
> > > > fair amount with VRULL on compiler and related technology.
> > >
> > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > potentially kernel side for a few months now. This makes them much
> > > more optimistic about their SoC/HW support in general.
> > >
> > > >
> > > >
> > > > >
> > > > > If there is away to acquire Veyron V1 Development Platform I would be
> > > > > interested to talk, and figure out what that would take. Such hardware
> > > > > would be a game charger, and I do trust Ventana regarding upstream
> > > > > support :)
> > > > I'll be pushing to make systems available to Fedora and the GCC farm,
> > > > but in general Ventana is more aligned towards Ubuntu.  My goal is to
> > > > have Fedora and Ubuntu on equal footing as quickly as possible.
> > >
> > > We have been trying to get stuff into GCC Compiler Farm for years now.
> > > There are a couple of boards IIRC. There are additional requirements
> > > on the software side (well, distributions) that we couldn't provide
> > > for quite some time.
> > >
> > > >
> > > > I do know rackable systems will be limited -- there's one particular
> > > > component needed on the rackable systems that is in very short supply.
> > > > We've got multiple orders in, but quantities are limited and lead times
> > > > are absolutely insane.
> > >
> > > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > > servers with 80 cores, but so far only 40-50 builders are enabled (no
> > > overcommitting on CPU as that's not a great idea [based on my own
> > > experience]).
> > >
> > > I expect Veyron V1 to deliver a decent single and multi thread
> > > performance, but we will need a lot of them. Probably 20-25 systems if
> > > we assume a similar configuration as aarch64 builders (8-core, 32-64G
> > > of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> > > will continue to be a problem. If we could somehow get to this level
> > > we could stop investing into SBCs as they are stop-gap solutions for
> > > builders.
> > >
> > > Based on some guesses there isn't a lot of time either. I would love
> > > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > > riscv64 in a good shape before that happens, but probably unrealistic.
> >
> > It is very unlikely that CentOS

Re: Starting Flatpak SIG

2023-01-09 Thread Kalev Lember

On Thu, Jan 5, 2023 at 10:55 AM Kalev Lember  wrote:

> Hi all,
>
> Hopefully most people are back from vacations now so I think we can go on
> with organizing the first Flatpak SIG meeting.
>
> I have created a whenisgood poll for the next week:
> https://whenisgood.net/s3rzh5h
> Please put your name in there and what times would work for you.
>
> I am thinking that a weekly meeting would be too often, but maybe
> bi-weekly? So that we do one next week, and then again two weeks after etc.
> 10 people have already signed up on the
> https://fedoraproject.org/wiki/SIGs/Flatpak page so I suspect it's going
> to be hard to make it work for everybody, but hopefully we can find
> something that would work for most of the group.
>
> I'll collect the results later this week when it looks like most of the
> people have replied.
>
> Thanks and Happy New Year everybody!
>

OK, we now have a time for the first Flatpak SIG meeting. 10 people replied
to the poll and we managed to find a time slot that actually works for
everybody:

  15:00 GMT on Monday, starting on January 23, and recurring every two
weeks.

Looks like the #fedora-meeting IRC channel is available at that time so
I've gone ahead and made a reservation in
https://calendar.fedoraproject.org/SIGs/2023/1/23/#m10431

Some topics for the first meeting, off the top of my head: introductions,
why do we need to do Fedora Flatpaks, how to handle openh264, announcements.

See you all there!

-- 
Kalev

(I've cross-posted this to the desktop list again but let's try to keep the
discussion on the devel mailing list.)

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

libharu 2.4.3, mathgl 8.0.1, vtk 9.2.5 update coming to rawhide soon

2023-01-09 Thread Orion Poplawski

I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk 
to 9.2.5 at the end of this week.  Builds will be done in a side tag. 
Test builds are being done here:


https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Help with Rust packaging

2023-01-09 Thread Fabio Valentini

On Mon, Jan 9, 2023 at 3:25 PM Maxwell G via devel
 wrote:
>
>
> Jan 7, 2023 4:41:29 PM Lumír Balhar :
>
> > y-py upstream uses maturin as a build backend which is not available in
> > Fedora yet so I had to add some metadata manually to port it to
> > setuptools-rust
> Why not package maturin? Is there something particularly problematic
> about maturin (e.g. lots of missing dependencies) or is it just lack of
> time?

Packaging maturin is on the long-term roadmap for the Rust SIG, but
it's currently blocked for at least two reasons:

- a few dozen dependencies are not packaged for Fedora yet
- some of the dependencies which *are* packaged are too old in Fedora,
but updating to newer versions is blocked by our tool's lack of
support for newer cargo features
- some of the dependencies / features of maturin will probably not be
acceptable as Fedora packages, because they require accepting
Microsoft EULA (I hope it will be possible to patch out / disable
those features)
- some of the dependencies / features of maturin are not available on
all Fedora architectures (most notably, the zig compiler, and the
rustls TLS backend) - I hope these features are optional for what we
need to build RPM packages, but I haven't been able to confirm that
yet

Last time I looked into maturin, I tried to document the current state
of things here:
https://copr.fedorainfracloud.org/coprs/decathorpe/maturin/

I haven't had time to look into this further since. So the easiest
solution for y-py was to port it from maturin to setuptools_rust,
which is already packaged for Fedora, and has already been used
successfully for building Python packages for a while.
Most of the additional features that maturin provides compared to
setuptools_rust are only useful for upstream development, so until
maturin is available as a Fedora package, porting projects to
setuptools_rust is much easier than waiting for maturin to be
packaged.

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

Re: Help with Rust packaging

2023-01-09 Thread Maxwell G via devel



Jan 7, 2023 4:41:29 PM Lumír Balhar :

y-py upstream uses maturin as a build backend which is not available in 
Fedora yet so I had to add some metadata manually to port it to 
setuptools-rust
Why not package maturin? Is there something particularly problematic 
about maturin (e.g. lots of missing dependencies) or is it just lack of 
time?

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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: RISC-V -- are we ready for more, and what do we need to do it?

2023-01-09 Thread Jeff Law




On 1/9/23 07:14, Neal Gompa wrote:



It is very unlikely that CentOS Stream 10 will include RISC-V as a
fully included architecture.  Perhaps via a CentOS Stream SIG.



I believe that was the implication in the first place, hence
mentioning CentOS Stream rather than RHEL.

The Alternative Architectures SIG in CentOS would be where this would
happen. But the work needs to be done in Fedora first.
Hard to see a path for CentOS and certainly not RHEL until after Fedora 
is in better shape.  Even then ISTM we need pull from sites looking to 
deploy this stuff at scale.


jeff
___
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: RISC-V -- are we ready for more, and what do we need to do it?

On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  wrote:
>
> On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
>  wrote:
> >
> > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  wrote:
> > >
> > >
> > >
> > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > >
> > > > Summary from multi-year discussions/feedback on this:
> > > > - We don't have proper hardware to put into the data center that holds
> > > > servers used by Fedora infrastructure.
> > > Right.  dev boards are not the solution here.  It's got to be something
> > > that can be racked and with enough performance to matter.
> > >
> > > > - Not enough single and multi thread performance to avoid large impact
> > > > to Fedora development.
> > > Agreed.   Returning to a situation like we had with armv7 isn't
> > > acceptable IMHO.
> > >
> > > >
> > > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > > good day we can keep up (if the builds aren't too large, e.g. GCC). We
> > > > don't really run Bodhi thus once package is built it's immediately
> > > > available. We run a very minimal setup right now (ideas to expand
> > > > that).
> > > It's fantastic we've got that far.  But clearly it's not viable long term.
> >
> > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > cannot move forward until the proper hardware (and things around it)
> > becomes available.
> >
> > >
> > >
> > > > Another news is that Fedora/RISCV Koji server (
> > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > > server. We are about to start work on Fedora 38/Rawhide.
> > > Excellent.  I'll have to update my chroots and containers as the F38
> > > bits start appearing.
> >
> > I am still tweaking the server configuration, but I should be ready
> > for mass building soonish.
> > I might want to wait for GCC 13 to land in Rawhide, which should
> > happen soon (I think).
> >
> > >
> > > >
> > > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > > > yet convinced about their upstream support efforts (TBD).
> > > Yes Veyron-v1 will have a BMC and will be rackable.   I have no
> > > significant insight into the T-HEAD efforts other than they do work a
> > > fair amount with VRULL on compiler and related technology.
> >
> > I noticed that VRULL has been involved with T-HEAD on GCC and
> > potentially kernel side for a few months now. This makes them much
> > more optimistic about their SoC/HW support in general.
> >
> > >
> > >
> > > >
> > > > If there is away to acquire Veyron V1 Development Platform I would be
> > > > interested to talk, and figure out what that would take. Such hardware
> > > > would be a game charger, and I do trust Ventana regarding upstream
> > > > support :)
> > > I'll be pushing to make systems available to Fedora and the GCC farm,
> > > but in general Ventana is more aligned towards Ubuntu.  My goal is to
> > > have Fedora and Ubuntu on equal footing as quickly as possible.
> >
> > We have been trying to get stuff into GCC Compiler Farm for years now.
> > There are a couple of boards IIRC. There are additional requirements
> > on the software side (well, distributions) that we couldn't provide
> > for quite some time.
> >
> > >
> > > I do know rackable systems will be limited -- there's one particular
> > > component needed on the rackable systems that is in very short supply.
> > > We've got multiple orders in, but quantities are limited and lead times
> > > are absolutely insane.
> >
> > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > servers with 80 cores, but so far only 40-50 builders are enabled (no
> > overcommitting on CPU as that's not a great idea [based on my own
> > experience]).
> >
> > I expect Veyron V1 to deliver a decent single and multi thread
> > performance, but we will need a lot of them. Probably 20-25 systems if
> > we assume a similar configuration as aarch64 builders (8-core, 32-64G
> > of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> > will continue to be a problem. If we could somehow get to this level
> > we could stop investing into SBCs as they are stop-gap solutions for
> > builders.
> >
> > Based on some guesses there isn't a lot of time either. I would love
> > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > riscv64 in a good shape before that happens, but probably unrealistic.
>
> It is very unlikely that CentOS Stream 10 will include RISC-V as a
> fully included architecture.  Perhaps via a CentOS Stream SIG.
>

I believe that was the implication in the first place, hence
mentioning CentOS Stream rather than RHEL.

The Alternative Architectures SIG in CentOS would be where

Re: RISC-V -- are we ready for more, and what do we need to do it?

2023-01-09 Thread Josh Boyer

On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
 wrote:
>
> On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  wrote:
> >
> >
> >
> > On 1/6/23 23:41, David Abdurachmanov wrote:
> > >
> > > Summary from multi-year discussions/feedback on this:
> > > - We don't have proper hardware to put into the data center that holds
> > > servers used by Fedora infrastructure.
> > Right.  dev boards are not the solution here.  It's got to be something
> > that can be racked and with enough performance to matter.
> >
> > > - Not enough single and multi thread performance to avoid large impact
> > > to Fedora development.
> > Agreed.   Returning to a situation like we had with armv7 isn't
> > acceptable IMHO.
> >
> > >
> > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > good day we can keep up (if the builds aren't too large, e.g. GCC). We
> > > don't really run Bodhi thus once package is built it's immediately
> > > available. We run a very minimal setup right now (ideas to expand
> > > that).
> > It's fantastic we've got that far.  But clearly it's not viable long term.
>
> Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> cannot move forward until the proper hardware (and things around it)
> becomes available.
>
> >
> >
> > > Another news is that Fedora/RISCV Koji server (
> > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > server. We are about to start work on Fedora 38/Rawhide.
> > Excellent.  I'll have to update my chroots and containers as the F38
> > bits start appearing.
>
> I am still tweaking the server configuration, but I should be ready
> for mass building soonish.
> I might want to wait for GCC 13 to land in Rawhide, which should
> happen soon (I think).
>
> >
> > >
> > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > > yet convinced about their upstream support efforts (TBD).
> > Yes Veyron-v1 will have a BMC and will be rackable.   I have no
> > significant insight into the T-HEAD efforts other than they do work a
> > fair amount with VRULL on compiler and related technology.
>
> I noticed that VRULL has been involved with T-HEAD on GCC and
> potentially kernel side for a few months now. This makes them much
> more optimistic about their SoC/HW support in general.
>
> >
> >
> > >
> > > If there is away to acquire Veyron V1 Development Platform I would be
> > > interested to talk, and figure out what that would take. Such hardware
> > > would be a game charger, and I do trust Ventana regarding upstream
> > > support :)
> > I'll be pushing to make systems available to Fedora and the GCC farm,
> > but in general Ventana is more aligned towards Ubuntu.  My goal is to
> > have Fedora and Ubuntu on equal footing as quickly as possible.
>
> We have been trying to get stuff into GCC Compiler Farm for years now.
> There are a couple of boards IIRC. There are additional requirements
> on the software side (well, distributions) that we couldn't provide
> for quite some time.
>
> >
> > I do know rackable systems will be limited -- there's one particular
> > component needed on the rackable systems that is in very short supply.
> > We've got multiple orders in, but quantities are limited and lead times
> > are absolutely insane.
>
> FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> swap. The older machines had 8G/core setup. There seems to be 8 (?)
> servers with 80 cores, but so far only 40-50 builders are enabled (no
> overcommitting on CPU as that's not a great idea [based on my own
> experience]).
>
> I expect Veyron V1 to deliver a decent single and multi thread
> performance, but we will need a lot of them. Probably 20-25 systems if
> we assume a similar configuration as aarch64 builders (8-core, 32-64G
> of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> will continue to be a problem. If we could somehow get to this level
> we could stop investing into SBCs as they are stop-gap solutions for
> builders.
>
> Based on some guesses there isn't a lot of time either. I would love
> to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> riscv64 in a good shape before that happens, but probably unrealistic.

It is very unlikely that CentOS Stream 10 will include RISC-V as a
fully included architecture.  Perhaps via a CentOS Stream SIG.

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

Non-responsive maintainer check for amatyuko

2023-01-09 Thread Ali Erdinc Koroglu


Hello everyone!
Does anyone know how to contact Andrey Matyukov (amatyuko)? I have tried to 
reach out via email but have not received a response.

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

--
Ali Erdinc Koroglu
Linux OS Systems Engineering
___
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: ImageMagick 7 is landing in Rawhide

2023-01-09 Thread Dan Horák

On Mon, 9 Jan 2023 06:46:59 -0500
Neal Gompa  wrote:

> On Mon, Jan 9, 2023 at 6:42 AM Neal Gompa  wrote:
> >
> > On Mon, Jan 9, 2023 at 6:30 AM Dan Horák  wrote:
> > >
> > > On Fri, 6 Jan 2023 16:34:29 -0500
> > > Neal Gompa  wrote:
> > >
> > > > Hey all,
> > > >
> > > > The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> > > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
> > > >
> > > > Most packages in the reverse dependency chain were rebuilt, though a
> > > > few are still left to fix and will be addressed separately.
> > > >
> > > > The ones remaining are:
> > > >
> > > > * autotrace (contacting upstream planned)
> > > > * q (dead upstream, orphaned)
> > > > * vdr-scraper2vdr (maybe dead upstream?)
> > > > * vdr-skinnopacity (dead upstream)
> > > > * vdr-tvguide (dead upstream)
> > >
> > > the list is missing dmtx-utils now reported as FailsToInstall, which
> > > failed in your rebuild due
> > >
> > > No matching package to install: 'pkgconfig(Wand)'
> > >
> > > see https://koji.fedoraproject.org/koji/taskinfo?taskID=95776617
> > >
> > > Was there any change in this regard in the new ImageMagick?
> > >
> >
> > Ah, oops. I thought I had caught that and fixed it. It's
> > `pkgconfig(MagickWand)` now (which also works for IM6 too).
> >
> 
> This should be fixed now:
> https://src.fedoraproject.org/rpms/dmtx-utils/c/adc7f3d9733496edf6c9e90a1fced30e40052553
> 
> (As an aside, the sources already request via this name, so no source
> code adjustment required)

ack, thanks


Dan
___
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: ImageMagick 7 is landing in Rawhide

On Mon, Jan 9, 2023 at 6:42 AM Neal Gompa  wrote:
>
> On Mon, Jan 9, 2023 at 6:30 AM Dan Horák  wrote:
> >
> > On Fri, 6 Jan 2023 16:34:29 -0500
> > Neal Gompa  wrote:
> >
> > > Hey all,
> > >
> > > The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
> > >
> > > Most packages in the reverse dependency chain were rebuilt, though a
> > > few are still left to fix and will be addressed separately.
> > >
> > > The ones remaining are:
> > >
> > > * autotrace (contacting upstream planned)
> > > * q (dead upstream, orphaned)
> > > * vdr-scraper2vdr (maybe dead upstream?)
> > > * vdr-skinnopacity (dead upstream)
> > > * vdr-tvguide (dead upstream)
> >
> > the list is missing dmtx-utils now reported as FailsToInstall, which
> > failed in your rebuild due
> >
> > No matching package to install: 'pkgconfig(Wand)'
> >
> > see https://koji.fedoraproject.org/koji/taskinfo?taskID=95776617
> >
> > Was there any change in this regard in the new ImageMagick?
> >
>
> Ah, oops. I thought I had caught that and fixed it. It's
> `pkgconfig(MagickWand)` now (which also works for IM6 too).
>

This should be fixed now:
https://src.fedoraproject.org/rpms/dmtx-utils/c/adc7f3d9733496edf6c9e90a1fced30e40052553

(As an aside, the sources already request via this name, so no source
code adjustment required)




--
真実はいつも一つ！/ 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: ImageMagick 7 is landing in Rawhide

On Mon, Jan 9, 2023 at 6:30 AM Dan Horák  wrote:
>
> On Fri, 6 Jan 2023 16:34:29 -0500
> Neal Gompa  wrote:
>
> > Hey all,
> >
> > The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
> >
> > Most packages in the reverse dependency chain were rebuilt, though a
> > few are still left to fix and will be addressed separately.
> >
> > The ones remaining are:
> >
> > * autotrace (contacting upstream planned)
> > * q (dead upstream, orphaned)
> > * vdr-scraper2vdr (maybe dead upstream?)
> > * vdr-skinnopacity (dead upstream)
> > * vdr-tvguide (dead upstream)
>
> the list is missing dmtx-utils now reported as FailsToInstall, which
> failed in your rebuild due
>
> No matching package to install: 'pkgconfig(Wand)'
>
> see https://koji.fedoraproject.org/koji/taskinfo?taskID=95776617
>
> Was there any change in this regard in the new ImageMagick?
>

Ah, oops. I thought I had caught that and fixed it. It's
`pkgconfig(MagickWand)` now (which also works for IM6 too).




--
真実はいつも一つ！/ 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: ImageMagick 7 is landing in Rawhide

2023-01-09 Thread Dan Horák

On Fri, 6 Jan 2023 16:34:29 -0500
Neal Gompa  wrote:

> Hey all,
> 
> The initial rebase of ImageMagick to v7 is landing in Rawhide now:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd
> 
> Most packages in the reverse dependency chain were rebuilt, though a
> few are still left to fix and will be addressed separately.
> 
> The ones remaining are:
> 
> * autotrace (contacting upstream planned)
> * q (dead upstream, orphaned)
> * vdr-scraper2vdr (maybe dead upstream?)
> * vdr-skinnopacity (dead upstream)
> * vdr-tvguide (dead upstream)

the list is missing dmtx-utils now reported as FailsToInstall, which
failed in your rebuild due

No matching package to install: 'pkgconfig(Wand)'

see https://koji.fedoraproject.org/koji/taskinfo?taskID=95776617

Was there any change in this regard in the new ImageMagick?


Dan
___
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: WASM from Ruby - Lightning Chess Web App

2023-01-09 Thread Jun Aruga (he / him)

Hi Philip,
I added a Ruby SiG mailing list to TO.

Folks at Ruby SiG,
Could you take a look at the message below? Philip is trying to create
a RPM package including WASM built Ruby binaries. Your feedback is
helpful.

On Mon, Jan 9, 2023 at 11:00 AM Philip Rhoades  wrote:
>
> Jun,
>
>
> On 2023-01-09 00:36, Jun Aruga (he / him) wrote:
> > On Sun, Jan 8, 2023 at 11:51 AM Philip Rhoades via devel
> >  wrote:
> >>
> >> People,
> >>
> >> Over the holidays we had our irregular Family Lightning Chess
> >> competition (10 seconds per move) - I have not found an online web
> >> site
> >> that will work exactly with our rules and it occurs to me that this
> >> would be a nice project for me to get working via a Ruby2WASM project.
> >> If I could get that project working, it would allow the family to have
> >> at least annual electronic competitions for the times when not all the
> >> relatives can physically make it to the one place at the one time . .
> >>
> >> What do you think?
> >
> > Good idea!
>
>
> Good! - I wasn't sure if it was or note . .
>
>
> > Ruby 3.2 released a few weeks ago, started to support the WASM built
> > feature, and I guess that people want to use it easily.
>
>
> I certainly do!
>
>
> > The first choice for the packaging is to create WASM built binaries as
> > a sub package of "ruby" https://src.fedoraproject.org/rpms/ruby or to
> > create a new package with the new RPM spec file.
>
>
> I don't know about that but it would be good for me to get started with
> a "Hello World!" Ruby2WASM app and go from there . .

OK. I think trying to create a minimal RPM package such as "Hello
World" is a good idea if you have never experienced RPM packaging.
Then as your next step, you may be able to try to build by creating
your package by copying the current rpms/ruby's ruby.spec to e.g.
ruby-wasm.spec, and modifying it to build WASM binaries.

Tutorial: 
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/
Packaging Guide: https://docs.fedoraproject.org/en-US/packaging-guidelines/

> > We discussed if we shipped WASM binaries a bit in the ruby-sig@
> > mailing list. I can recommend you to join the list to discuss people
> > in the ruby related packages  if you like.
> >
> > * Ruby 3.2 - ruby-sig@
> >
> > https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/thread/FK3XRKUICBS7HFZVEENSEGJ4ZMKCVNWF/
>
>
> Yes, I read that stuff and am subscribed to that list now.

OK. Nice!

> > Fedora WASM SIP might be launched. You can check the situation.
> >
> > * Web Assembly on Fedora: interested in a Fedora SIG to work on this?
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JO2YYDQPC65EMQVO6UCHDV4SAKQNSGKV/
>
>
> Happy to join that list too but that is a much wider deal than the
> Ruby2WASM project?

Yes. right. I think it's about WASM things more than Ruby.
For example, it's about what you need to do to build WASM binaries of
Ruby, and which dependency RPM packages you need.

> Thanks!
>
> Phil.
> --
> Philip Rhoades
>
> PO Box 896
> Cowra  NSW  2794
> Australia
> E-mail:  p...@pricom.com.au

Thanks too!

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: Malicious communication (was: Re: Schedule for Tuesday's FESCo Meeting (2023-01-03))

2023-01-09 Thread Arthur Bols


On 9/01/2023 10:09, Mamoru TASAKA wrote:

Honestly saying, I cannot understand this context, why native English
speaker or not is relevant here, especially because I am also
non-native.

I don't think Fedora committers change their attitude against
between native or non-native English speakers.

Mamoru


/Disclaimer: I don't want to take part in this discussion and this is 
not me taking a "side"./


I want to clarify that it's often difficult for non-native English 
speakers to come across as friendly. It's quite easy to write/speak 
English but sounding formal or friendly is a bit more difficult. 
Therefore I understand and agree that non-native English speakers are 
given a bit of leeway.


--
Arthur Bols
fas/irc: principis
___
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: Help with Rust packaging

2023-01-09 Thread Miro Hrončok


On 07. 01. 23 23:41, Lumír Balhar wrote:

Hi.

I'm working on packaging new version of Juyter Notebook and Lab into Fedora and 
I have a problem with one Rust/Python package - y-py.


The problem is that when I'm building python-y-py in COPR 
https://copr.fedorainfracloud.org/coprs/lbalhar/notebook/builds/ I'm getting


error: no matching package named `lib0` found

It seems to be obvious but the situation is more complex. y-py upstream uses 
maturin as a build backend which is not available in Fedora yet so I had to add 
some metadata manually to port it to setuptools-rust, see the specfile: 
https://download.copr.fedorainfracloud.org/results/lbalhar/notebook/fedora-rawhide-x86_64/05201544-python-y-py/python-y-py.spec


The dependency it complains about (rust-lib0) is not yet available in Fedora 
but it is available in the COPR and as you can see in the build log, it is also 
installed: 
https://download.copr.fedorainfracloud.org/results/lbalhar/notebook/fedora-rawhide-x86_64/05201544-python-y-py/builder-live.log.gz


I've tried to play around with the Cargo.toml config and I've removed the 
versions from the requirements but I have no idea how to fix this problem. 
Might be the rust-lib0 package broken?


My best guess is that without %cargo_prep, the libraries are not searched for 
in the RPM-installed locations but rather in some project-local cargo directory.


I suggest adding %cargo_prep to %prep and use %cargo_generate_buildrequires in 
%generate_buildrequires instead of manualyl specifying the dependencies.


This should be possible:

  %generate_buildrequires
  %cargo_generate_buildrequires
  %pyproject_buildrequires


--
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: Schedule for Tuesday's FESCo Meeting (2023-01-03)

2023-01-09 Thread Mark Wielaard

Hi Neal,

On Wed, 2023-01-04 at 08:44 -0500, Neal Gompa wrote:
> On Wed, Jan 4, 2023 at 8:30 AM Vitaly Zaitsev via devel
>  wrote:
> > 
> > Already rejected proposal was submitted because big corporations
> > weren't
> > happy with the results. This is a VERY BAD precedent for Fedora.
> > 
> 
> Actually, the Change owners were prepared to give up. I was the one
> that pushed for it to be reconsidered

I must say I find this rather odd. As you say there was an agreement on
moving forward without frame pointers. And as far as I could see there
was even an healthy discussion about alternative ways to get faster and
more accurate unwinding/backtracing between the profiling and
compiler/tools hackers.

I don't mind if you would re-try to get this change in for f39 or f40
if it turns out those discussions about alternative unwinders didn't
result in faster/better profilers.

But trying to do it while multiple stackholders were away and unaware
of this because it wasn't really announced doesn't feel good.

Cheers,

Mark
___
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: Shorter Shutdown Timer (System-Wide Change proposal)

2023-01-09 Thread Lennart Poettering

On Fr, 06.01.23 11:06, Michael Catanzaro (mcatanz...@redhat.com) wrote:

> Maybe instead of SIGKILL, we should send SIGQUIT instead. That way abrt
> should complain next time you boot and users will have an opportunity to
> report bugs to the package maintainer, instead of the problem being forever
> ignored. Killing things silently makes it real hard to report bugs. And as a
> bonus, the core dump should actually show what the process was doing at the
> time it got killed. The more I think about it, the better this sounds.
> Currently this can be configured using FinalKillSignal=SIGQUIT, so we'd just
> need to figure out the right place to put that.
>
> systemd already has a configuration option for this so we'd just have to
> turn it on.

Don't use FinalKillSignal=SIGQUIT.

Use TimeoutStopFailureMode=abort instead. (which covers more ground,
and sends SIGABRT rather than SIGQUIT on failure, which has the same
effect: coredumping).

That said: dumping core is potentially extremely expensive (web
browsers have gigabytes of virtual memory that we might end up
processing and compressing). Quite often the stuff that is slow when
exiting is also the stuff that is expensive to dump.

Hence, I am not sure you'll gain that much via this mechanism: you cut
a long operation short and then execute long operation as result. You
might end delaying things more than you hope shortening them.

Lennart

--
Lennart Poettering, Berlin
___
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: WASM from Ruby - Lightning Chess Web App

2023-01-09 Thread Philip Rhoades via devel

Jun,

On 2023-01-09 00:36, Jun Aruga (he / him) wrote:

On Sun, Jan 8, 2023 at 11:51 AM Philip Rhoades via devel
wrote:

People,

Over the holidays we had our irregular Family Lightning Chess
competition (10 seconds per move) - I have not found an online web
site

that will work exactly with our rules and it occurs to me that this
would be a nice project for me to get working via a Ruby2WASM project.
If I could get that project working, it would allow the family to have
at least annual electronic competitions for the times when not all the
relatives can physically make it to the one place at the one time . .

What do you think?

Good idea!

Good! - I wasn't sure if it was or note . .

Ruby 3.2 released a few weeks ago, started to support the WASM built
feature, and I guess that people want to use it easily.

I certainly do!

The first choice for the packaging is to create WASM built binaries as
a sub package of "ruby" https://src.fedoraproject.org/rpms/ruby or to
create a new package with the new RPM spec file.

I don't know about that but it would be good for me to get started with
a "Hello World!" Ruby2WASM app and go from there . .

We discussed if we shipped WASM binaries a bit in the ruby-sig@
mailing list. I can recommend you to join the list to discuss people
in the ruby related packages if you like.

* Ruby 3.2 - ruby-sig@

https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/thread/FK3XRKUICBS7HFZVEENSEGJ4ZMKCVNWF/

Yes, I read that stuff and am subscribed to that list now.

Fedora WASM SIP might be launched. You can check the situation.

* Web Assembly on Fedora: interested in a Fedora SIG to work on this?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JO2YYDQPC65EMQVO6UCHDV4SAKQNSGKV/

Happy to join that list too but that is a much wider deal than the
Ruby2WASM project?

Thanks!

Phil.
--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: p...@pricom.com.au
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2158853] perl-System-Info-0.063 is available