date:20230110

All dependent packages have successfully rebuilt in COPR and will be
completed in a side tag.

The following dependencies will be rebuilt:

OpenImageIO
usd
blender
krita
luxcorerender

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] perl-Email-Stuffer-0.020 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Email-Stuffer-0.019 is |perl-Email-Stuffer-0.020 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Releases retrieved: 0.020
Upstream release that is considered latest: 0.020
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

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

2023-01-10 Thread Siddhesh Poyarekar

On Tue, Jan 10, 2023 at 7:17 PM Fabio Valentini  wrote:
> Speaking for myself, the only way in which the _FORTIFY_SOURCE change
> impacted my opinion on -fno-omit-frame-pointers is that it made me
> think about it again, and that the level of scrutiny myself - and
> other members of FESCo - had given that change, had been
> disproportionate.

The _FORTIFY_SOURCE change really shouldn't even have prompted a
discussion on the frame pointers change, let alone a reflection
because there is absolutely nothing in common there.  Especially in
the context of scrutiny level; one is a security change that has no
broad slowdown and another is a developer experience change that is
shown to have a broad slowdown (characterized by minor or major
depending on which side of the aisle you stand on).

> And you might like it or not, I had just changed my
> mind on the topic since we had the first vote.

I wish you had spoken up sooner then, using the _FORTIFY_SOURCE change
as the opportunity to speak up not only confused the whole thing, it
also makes it harder to convince that the change of mind came
independently.

Sid
___
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-10 Thread Kevin Fenzi

On Tue, Jan 10, 2023 at 09:15:41PM -0500, Siddhesh Poyarekar wrote:
...snip...
> 
> Finally, another voting member commented, this time on the re-vote
> ticket[1], again indicating that the reason for the revote is the
> misdirection in the _FORTIFY_SOURCE proposal discussion.

Just to set the record straight here: I made that comment, and I was
wondering/suggesting (or as I note in the comment "guessing") as to why
the revote was taking place. I was not involved in the revote and
indeed I was trying to say "if this is because of the _FORTIFY_SOURCE proposal,
there's a lot of difference between them and I can't see why it would change 
things."

Indeed it didn't change anything for me, as I kept my -1 vote. 

kevin

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

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

2023-01-10 Thread Siddhesh Poyarekar

On Tue, Jan 10, 2023 at 4:31 PM Zbigniew Jędrzejewski-Szmek
 wrote:
> That description assumes that FESCo members are preschoolers who are
> easy to trick and also need to be reminded who said what every day.
> That's certainly not the case. The objections against the proposal
> were made very clearly and they certainly weren't forgotten over a few
> days. Those objections also didn't *change* over those few days, so
> repeating them wouldn't actually change anything.

They don't need to be preschoolers; it's not that hard to manufacture
an opinion among well informed adults, even unintentionally by just
having a lot of conviction about it.

The seeds for the revote were placed in the _FORTIFY_SOURCE=3 change
discussion and throughout the discussion, repeated explanations of why
the proposals are not comparable were ignored, instead of which the
focus seemed to be on driving consensus towards getting a revote on
the frame pointer proposal and trying to paint the tools team's
position as being duplicitous.

In the _FORTIFY_SOURCE=3 ticket one of the FESCo voters (who also
drove the revote FWIW) took a hard negative stand only because they
perceived a double standard on performance, which had, by then,
already been debunked a couple of times in the devel thread.  While he
did change his vote to +1 later, he appeared to do so only after other
members voiced their support.  If that's not influencing narrative
then I don't know what is.

Multiple other FESCo voters, when voting for the _FORTIFY_SOURCE
proposal, talked about the frame pointer proposal, again clearly
indicating that there is a cross-influence.

Finally, another voting member commented, this time on the re-vote
ticket[1], again indicating that the reason for the revote is the
misdirection in the _FORTIFY_SOURCE proposal discussion.

Christian did make an impassioned plea on the re-vote ticket for the
case of frame pointers and it's perfectly understandable if that was a
turning point for those who changed their vote (and please say it if
that was what it was; I'd disagree but that's a different matter then)
but the thing is, that plea needs counterarguments and further
discussion and there was no opportunity for that to happen.  Even
then, the only reason why the revote happened at all was because of
the persistent misdirection in the _FORTIFY_SOURCE proposal.

> Speaking for myself, I heard the objections from various sides, and I
> think I understand them. In particular I think that the objections from
> the compiler team are based on correct evaluation of the effect of the
> change. But that evaluation is hyperfocused on benchmark performance and
> doesn't look at the needs of the whole ecosystem. I think that the
> advantages of the proposal and the gains I hope will be realized outweigh
> the drawbacks.

Ack, I respect that even if I don't agree with the conclusion.

Thanks,
Sid

[1] https://pagure.io/fesco/issue/2923#comment-833708
___
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-10 Thread Kevin Fenzi

On Tue, Jan 10, 2023 at 06:00:59PM -0600, Michael Catanzaro wrote:
> On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi 
> wrote:
> > Is there something wrong with that approach that I am not understanding?
> 
> No, I don't think you're missing anything. That should work fine for
> PackageKit. But of course it won't do a thing to help with for other
> services that are misbehaving! The goal here is to make the operating system
> generally more robust.

Ok, but it seems safer to just add timeouts to things that take too long
and can safely be killed off rather than lowering the timeout for
everything and potentially kill things that cannot safely be killed. 

I realize it's a lot more work to try and fix particular slow things.

It's hard to know what really needs more time and what just should be
killed off sooner. :(

kevin


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

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

2023-01-10 Thread updates

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


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

apptainer-1.1.5-1.el7
libopenmpt-0.6.7-1.el7
partclone-0.3.22-1.el7

Details about builds:



 apptainer-1.1.5-1.el7 (FEDORA-EPEL-2023-253bcc)
 Application and environment virtualization formerly known as Singularity

Update Information:

Update to upstream 1.1.5, and change Obsoletes on main package to Conflicts

ChangeLog:

* Tue Jan 10 2023 Dave Dykstra  - 1.1.5-1
- Update to upstream 1.1.5, including changing the obsoletes on the main
  apptainer package to conflicts.
* Wed Jan  4 2023 Dave Dykstra  - 1.1.4-3
- Restore the singularity obsoletes on the apptainer main package, so
  that now it is on both the main package and suid subpackage.

References:

  [ 1 ] Bug #2158332 - apptainer: installing apptainer while singularity is 
installed is causing transaction check conflict errors
https://bugzilla.redhat.com/show_bug.cgi?id=2158332
  [ 2 ] Bug #2159814 - apptainer-1.1.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2159814




 libopenmpt-0.6.7-1.el7 (FEDORA-EPEL-2023-4cb227ab17)
 C/C++ library to decode tracker music module (MOD) files

Update Information:

# libopenmpt 0.6.7 (2023-01-08)* [Bug] openmpt123: openmpt123 crashed on
Windows 9x when showing any console output.   * IT: In sample mode, portamento
to a different sample turns off the filter if cutoff / resonance was previously
127 / 0.   * S3M Detect files saved with Graoumf Tracker instead of claiming
they were made with OpenMPT 4.47.   * S3M: Pattern loop state was not propagated
anymore since libopenmpt 0.6.0, leading to wrong song length calculation and SB0
+ SBx being located on different channels not working properly anymore.   *
mpg123: Update to v1.31.1 (2022-11-01).   * FLAC: Update to v1.4.2 (2022-10-22).
* pugixml: Update to v1.13 (2022-11-02).

ChangeLog:

* Mon Jan  9 2023 Michael Schwendt  - 0.6.7-1
- update to 0.6.7

References:

  [ 1 ] Bug #2159131 - libopenmpt-0.6.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2159131




 partclone-0.3.22-1.el7 (FEDORA-EPEL-2023-033d0860b0)
 Utility to clone and restore a partition

Update Information:

# partclone v0.3.22   - Fix log message to add new line after "Open devicefile
successfully"  - Add missing space before opening parenthesis  - Skip FAT tests
on big-endian architectures  - Skip F2FS tests on big-endian architectures  -
Increase F2FS default test size to 100+ MB  - Increase XFS default test image
size to 300+ MB  - fail-mbr: Remove binutils section `.note.gnu.build-id` using
`objcopy`

ChangeLog:

* Wed Jan 11 2023 Robert Scheck  0.3.22-1
- Upgrade to 0.3.22 (#2159671)

References:

  [ 1 ] Bug #2159671 - partclone-0.3.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2159671


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

[Bug 2157775] Please branch and build cpanspec in epel9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2023-c7fe4b2d6b has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c7fe4b2d6b

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=2157775
___
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: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

2023-01-10 Thread Alexander Ploumistos

On Wed, Jan 11, 2023 at 1:59 AM Michael Catanzaro  wrote:
>
> On Wed, Jan 11 2023 at 01:33:18 AM +0100, Fabio Valentini
>  wrote:
> > Also, given that it is now apparently considered "allowed" to enable
> > unfiltered flathub with the "Enable third-party repositories" switch,
> > I wonder if that reasoning also applies to the  equivalent situation
> > for RPMFusion repos? The "Enable third-party repositories" switch only
> > enables "filtered" repos (containing only RPMs for proprietary NVidia
> > drivers and the Steam client), so following the same reasoning, it
> > should now be possible to enable "unfiltered" RPMFusion repos with
> > that switch instead, as well?
>
> This is only allowed for RPM Fusion's NVIDIA driver repo.

Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of
ffmpeg and so on. Why is it ok now to get these from flathub, but not
from RPM Fusion?
___
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 2156199] perl-ExtUtils-MakeMaker-7.66 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-ExtUtils-MakeMaker-7.6 |perl-ExtUtils-MakeMaker-7.6
   |6-1.fc38|6-1.fc38
   ||perl-ExtUtils-MakeMaker-7.6
   ||6-1.fc37
 Resolution|--- |ERRATA
Last Closed||2023-01-11 01:20:48



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-4fae89f4dc has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2156199
___
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: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

On Wed, Jan 11 2023 at 01:33:18 AM +0100, Fabio Valentini 
 wrote:

Also, given that it is now apparently considered "allowed" to enable
unfiltered flathub with the "Enable third-party repositories" switch,
I wonder if that reasoning also applies to the  equivalent situation
for RPMFusion repos? The "Enable third-party repositories" switch only
enables "filtered" repos (containing only RPMs for proprietary NVidia
drivers and the Steam client), so following the same reasoning, it
should now be possible to enable "unfiltered" RPMFusion repos with
that switch instead, as well?


This is only allowed for RPM Fusion's NVIDIA driver repo.

___
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: Unfiltered Flathub (System-Wide Change proposal)

2023-01-10 Thread Fabio Valentini

On Tue, Jan 10, 2023 at 7:34 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
>
> Note that I am processing this proposal past the deadline because 1. I
> think it could reasonably be considered a Self-Contained Change
> proposal and 2. the reasons outlined by Mattias in another thread:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PKUEM64L7FDGQBPRKZTHF5EF5FTLVSXG/
>
> 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 ==
> Fedora Workstation's existing
> [https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/
> third party repo feature] allows users to enable a selection of
> software repos that are hosted by external organizations. This
> selection has included a filtered version of Flathub since F35, which
> provides access to a small number of Flathub apps. This change would
> remove the filtering from our Flathub offering, so that users can
> enable a complete version of Flathub using the third party
> repositories feature. In the graphical software manager app, Flathub
> packages will only be selected by default when no Fedora package is
> available.

I appreciate the work that will go into making sure that software
provided by Fedora will always take priority over third-party
flatpaks, thank you for working on that.

Also, given that it is now apparently considered "allowed" to enable
unfiltered flathub with the "Enable third-party repositories" switch,
I wonder if that reasoning also applies to the  equivalent situation
for RPMFusion repos? The "Enable third-party repositories" switch only
enables "filtered" repos (containing only RPMs for proprietary NVidia
drivers and the Steam client), so following the same reasoning, it
should now be possible to enable "unfiltered" RPMFusion repos with
that switch instead, as well?

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

2023-01-10 Thread Fabio Valentini

On Wed, Jan 11, 2023 at 12:15 AM Kevin Kofler via devel
 wrote:
>
> Michael Catanzaro wrote:
> > (In particular, I doubt the _FORTIFY_SOURCE=3 change was really a major
> > consideration here.)
>
> What was, then? That was literally the only thing that has changed between
> the two diametrically different votes.

Speaking for myself, the only way in which the _FORTIFY_SOURCE change
impacted my opinion on -fno-omit-frame-pointers is that it made me
think about it again, and that the level of scrutiny myself - and
other members of FESCo - had given that change, had been
disproportionate. And you might like it or not, I had just changed my
mind on the topic since we had the first vote.

At that point, the only thing that could have convinced me to *not* to
vote for enabling frame pointers would have been substantial arguments
*against* the change from the toolchain team (and by substantial I
mean something more than "the team is against it", "we don't like it",
or "it's going to have a small performance impact"). Given that there
had been *months* for people to speak up, the likelihood of any such
arguments materializing at the last minute is pretty small (and even
then, the change could have been reverted between approval and mass
rebuild, if necessary).

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

On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi  
wrote:
Is there something wrong with that approach that I am not 
understanding?


No, I don't think you're missing anything. That should work fine for 
PackageKit. But of course it won't do a thing to help with for other 
services that are misbehaving! The goal here is to make the operating 
system generally more robust.


I'm going to amend this proposal to specify 
TimeoutStopFailureMode=abort as well, so we can get crash dumps and bug 
reports when programs fail to quit properly.


Michael

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

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

Zbigniew Jędrzejewski-Szmek wrote:
> That description assumes that FESCo members are preschoolers who are
> easy to trick and also need to be reminded who said what every day.
> That's certainly not the case. The objections against the proposal
> were made very clearly and they certainly weren't forgotten over a few
> days. Those objections also didn't *change* over those few days, so
> repeating them wouldn't actually change anything.

The objections did change because the arguments brought up by the other side 
did. I already pointed that out once. I do not want to sound like a broken 
record, so instead of a copy, here is the link:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CJ2P37D56LEDFKCZSBZ5LDSD53KH662B/

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

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

2023-01-10 Thread Kevin Fenzi

On Mon, Jan 09, 2023 at 08:45:43PM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> 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.

I'm a bit confused why we can't just fix the units that are taking too
long instead of changing the global value. The change page mentions that
"it's not possible to fix every misbehaving service: in some cases the
misbehaviour comes from design flaws that are difficult to resolve." but
can't we just change their timeout? ie, add to packagekitd's service
file: 
TimeoutStopSec=30s
(or 15 or whatever)?

Is there something wrong with that approach that I am not understanding?

kevin


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

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

Michael Catanzaro wrote:
> (In particular, I doubt the _FORTIFY_SOURCE=3 change was really a major
> consideration here.)

What was, then? That was literally the only thing that has changed between 
the two diametrically different votes.

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)

Michael Catanzaro wrote:
> You've previously indicated that developers should just 'dnf
> distro-sync' to an alternative Fedora that has frame pointers, as if
> building two alternate versions of Fedora, one for developers and one
> for users, is a reasonable thing to do. The cost of this is just too
> high. We'd need double build infrastructure.

+100% CPU power for the Koji build farm is still a lot less overall cost 
than +2.5% CPU power for *all* Fedora users in the entire world.

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: Change Proposal: replace dnf with dnf5

2023-01-10 Thread Richard W.M. Jones

On Tue, Jan 10, 2023 at 02:13:37PM -0500, David Cantrell wrote:
> https://pagure.io/fesco/issue/2870
> https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
> 
> This change proposal has been under discussion and revision for a while.  A
> lot of work has gone in to this plan to minimize the disruption.  Still, dnf
> is a core piece of software and we want to make sure everyone understands the
> proposal and has an opportunity to discuss it.
> 
> The final revision of the proposal is available at the URL above.  FESCo is
> waiting one more week for any remaining discussion on the change proposal.  We
> plan to bring the proposal up for vote in the next meeting.

Can you check if:

  dnf5 download --destdir= [list of pkgs] [-c configfile]

works as non-root?  eg:

  $ mkdir /var/tmp/test
  $ dnf5 download --destdir=/var/tmp/test bash glibc

Note the not needing root bit is vitally important.

I don't have a sacrificial machine to install dnf5 on right now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.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: Porting Fedora for the LoongArch architecture.

2023-01-10 Thread Richard W.M. Jones

Hi,

Porting Fedora to a new architecture is quite a challenge but a lot of
fun.  It sounds as if you've made a lot of progress already.  A few
thoughts from the Fedora/RISC-V effort ...

(1) Cross-compiling RPMs (eg. from x86-64 to LoongArch) isn't really
useful.  Almost any significantly complex RPM must be compiled on the
same architecture as it targets.  For example it may run tests or
tools that it builds as part of building the RPM.

For Fedora/RISC-V the problem was that we didn't have a viable Linux
environment to even run RPM on (in 2016), so I came up with a pretty
nasty bootstrapping hack, which cross-compiled enough of an
environment to be able to run rpmbuild.  For historical interest
that's here: https://github.com/rwmjones/fedora-riscv-bootstrap

However you won't need to use this.  There already exists a major
distro on LoongAch (ie. Debian).  You could use Debian to build a base
set of RPMs, and then once you have enough, install them into a
buildroot and continue using the Fedora you've built.

(I guess from your email that you've already done something like this.)

(2) noarch RPMs don't need to be compiled!  You can just copy them
from x86-64.  (At least for bootstrapping purposes, you'll want to be
able to compile them eventually.)  This is a nice time-saving tip to
remember.

(3) For RISC-V we didn't start with Koji (used our own hacky build
system), but did eventually set one up:
http://fedora.riscv.rocks/koji/

You'll also want to set up a Koji instance eventually.

(4) As another reply mentioned, to get LoongArch as a primary Fedora
architecture, an essential requirement is 19" rackable server-class
hardware.  It needs to be fully manageable through a BMC.  Fedora will
probably need a few such servers to be donated.

This is the main reason why RISC-V isn't a primary Fedora architecture
yet, although progress is happening.

(5) PLEASE PLEASE PLEASE get your patches upstream!  If they are
patches to the upstream software, send them to the upstream
maintainers.  If they are patches to the RPM builds, add them to
Fedora.  (People on this list can help with both these tasks.)

Getting stuff upstream benefits the whole community beyond Fedora, and
makes everyone's life easier.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.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: Change Proposal: replace dnf with dnf5

2023-01-10 Thread Arthur Bols


On 10/01/2023 20:13, David Cantrell wrote:

https://pagure.io/fesco/issue/2870
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5

This change proposal has been under discussion and revision for a while.  A
lot of work has gone in to this plan to minimize the disruption.  Still, dnf
is a core piece of software and we want to make sure everyone understands the
proposal and has an opportunity to discuss it.

The final revision of the proposal is available at the URL above.  FESCo is
waiting one more week for any remaining discussion on the change proposal.  We
plan to bring the proposal up for vote in the next meeting.

Thanks for the reminder David!

DNF5 looks very promising and the performance improvement is very welcome.

Just to be sure, are the critical features under scope in the change 
proposal considered as blockers (Search for example isn't listed under 
`Acceptance Criteria`)? It would be a very bad idea to have a package 
manager without basic features such as search, list or info...


Furthermore, DNF5 feels rough...
- "???%" progress
- negative/broken progress numbers (download/time/...)
- unclear error message when running without root permissions
- manually aborting download (^C) results in jumping to "Verifying PGP 
signatures" which of course fails

- aborting (^C) mid progress breaks cursor
- dnf5 clean packages shows "1 errors occurred" but no explanation?
- I managed to break dnf5 with a std::length_error' error? (not sure how 
I did that)
- it's less clear if a package is installed or not (there used to be a 
list of what was installed/removed)


I know that this is a bit harsh and there's still a lot of time for 
improvements and polishing, but are we sure that there is enough time 
before the Fedora 39 release? Should this be postponed to Fedora 40 to 
allow for more testing, migration of other tools and more?


 --
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: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

2023-01-10 Thread Stephen Gallagher

On Tue, Jan 10, 2023 at 4:58 PM Vitaly Zaitsev via devel
 wrote:
>
> On 10/01/2023 19:33, Ben Cotton wrote:
> > In the graphical software manager app, Flathub
> > packages will only be selected by default when no Fedora package is
> > available.
>
> Thanks for implementing that. Looks good for me now.

Indeed, this is exactly what we were looking for.
___
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 Tue, Jan 10, 2023 at 11:48 AM Miro Hrončok  wrote:

> On 10. 01. 23 13:52, Richard Shaw wrote:
> > 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/
> > <
> 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.)
> >
> >
> > Looks like the problem is using `rpkg` but that's the easiest method and
> has
> > worked great until now...
>
> For the record I've reported several issues with the rpkg method over the
> years. The distgit method was partially a response for those. tl;dr rpkg
> "works
> great" until it doesn't because it does not work like fedpkg, but instead
> it is
> a pre-processor for templated spec files that happens to work in most of
> the
> cases with bare spec files as well.
>

I didn't realize the fedpkg had grown the ability to do COPR builds. I will
use that from now on.

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 2159835] New: perl-IO-Zlib-1.14 is available

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

Bug ID: 2159835
   Summary: perl-IO-Zlib-1.14 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Zlib
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
perl-ma...@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.14
Upstream release that is considered latest: 1.14
Current version/release in rawhide: 1.13-1.fc38
URL: https://metacpan.org/release/IO-Zlib

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2159835
___
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: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

2023-01-10 Thread Vitaly Zaitsev via devel


On 10/01/2023 19:33, Ben Cotton wrote:

In the graphical software manager app, Flathub
packages will only be selected by default when no Fedora package is
available.


Thanks for implementing that. Looks good for me now.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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-10 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Jan 10, 2023 at 08:30:25AM -0500, Siddhesh Poyarekar wrote:
> On Tue, Jan 10, 2023 at 3:05 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> > 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.
> 
> What's being alleged is that many members were tricked into changing
> their vote by using the false narrative about _FORTIFY_SOURCE proposal
> getting an unfair pass despite performance concerns (which *I*
> hypothesized months ago and I later dispelled, in the end even quoting
> benchmark results for it) and creating the impression that the
> toolchain team is being duplicitous about the performance question.
> Further trickery involved rushing the vote, claiming that it had to be
> done soon to meet the mass rebuild deadline; too bad if those who had
> strong objections earlier weren't around to put their comments on
> record.

That description assumes that FESCo members are preschoolers who are
easy to trick and also need to be reminded who said what every day.
That's certainly not the case. The objections against the proposal
were made very clearly and they certainly weren't forgotten over a few
days. Those objections also didn't *change* over those few days, so
repeating them wouldn't actually change anything.

Speaking for myself, I heard the objections from various sides, and I
think I understand them. In particular I think that the objections from
the compiler team are based on correct evaluation of the effect of the
change. But that evaluation is hyperfocused on benchmark performance and
doesn't look at the needs of the whole ecosystem. I think that the
advantages of the proposal and the gains I hope will be realized outweigh
the drawbacks.

I can't speak for other people, but I assume that they made a similar
evaluation. FWIW, I voted the same both times, but I didn't make up my
mind to vote +1 until relatively late before the vote after I had time
to read up on the topic and go through various options that we have.

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: Summary/Minutes from today's FESCo Meeting (2023-01-10)


On 10. 01. 23 20:41, Kevin Kofler via devel wrote:

So FESCo is willing to prevent this from happening again in the future, but
NOT to remedy the existing wrongdoing?


Would you prefer if we ignored this altogether?

--
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: Retiring libwebcam

2023-01-10 Thread Michael Cronenworth


On 1/10/23 2:25 PM, Hans de Goede wrote:

ATM there is no replacement for uvcdynctrl which is still necessary for
some Logitech webcams. uvcdynctrl uses a userspace database to map
some Logitech custom control GUIDs to standard v4l2-controls.

This allows various extra functionality on Logitech webcams, like
adjusting the image (auto-exposure algorithm) for backlight conditions.

But also controlling the focus on some Logitech models with a manual
controlled electronic focus lens (instead of auto-focus) and I have
1 Logitech model with a motorized stand with electronic tilt / swivel
controls which needs this.


I dusted off my original Logitech webcam I used libwebcam with and plugged it in 
today and the controls all showed up in guvcview so I assumed there would not be any 
missing functionality. Have you tried the latest verison of guvcview?



I actually recently discussed what to do with this with the kernel
UVC driver maintainer. When the discussion was made many years ago
to put the mapping of vendor specific GUIDs in userspace the thought
was that there would be many many vendor specific controls and that
we did not want to have to add all those to the kernel.

But other then the Logitech custom controls set no support for
other custom controls was ever added to uvcdynctrl-data. So
the UVC driver maintainer said that he would be ok with just
adding these mappings directly to the kernel.

Once someone finds the time to actually add these mappings
to the kenrel libwebcam can be retired but until then it would
be nice if we can keep it around for uvcdynctrl.


I guess I'll keep it around a few more Fedoras. Luckily it doesn't cause any FTBFS 
bugs on mass rebuilds. Thanks for the note, Hans.

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

Re: [Fedocal] Reminder meeting : Prioritized bugs and issues

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

There are no nominated prioritized bugs, so I'm cancelling this week's
meeting. I follow up with the currently accepted bugs out of band. The
next meeting is scheduled for 25 January.


-- 
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: Retiring libwebcam

2023-01-10 Thread Hans de Goede

Hi Michael,

On 1/10/23 18:04, Michael Cronenworth wrote:
> Hi all,
> 
> Unless someone speaks up in the next week I am going to retire the 
> libwebcam[1] package.
> 
> Background: Some of the first USB web cameras using the "UVC" protocol needed 
> a user-space driver for controlling the hardware features. Logitech developed 
> the libwebcam library as an interface for users. Around 2014 Logitech stopped 
> development on it and it is now abandoned.
> 
> I have seen replacements pop up with the 'v4l-utils' package and the v4l2-ctl 
> CLI tool and guvcview graphical tool. Both receive modern care so I don't see 
> a need to continue shipping the libwebcam package. There are no known 
> (reqoquery) dependencies on libwebcam.

ATM there is no replacement for uvcdynctrl which is still necessary for
some Logitech webcams. uvcdynctrl uses a userspace database to map
some Logitech custom control GUIDs to standard v4l2-controls.

This allows various extra functionality on Logitech webcams, like
adjusting the image (auto-exposure algorithm) for backlight conditions.

But also controlling the focus on some Logitech models with a manual
controlled electronic focus lens (instead of auto-focus) and I have
1 Logitech model with a motorized stand with electronic tilt / swivel
controls which needs this.

I actually recently discussed what to do with this with the kernel
UVC driver maintainer. When the discussion was made many years ago
to put the mapping of vendor specific GUIDs in userspace the thought
was that there would be many many vendor specific controls and that
we did not want to have to add all those to the kernel.

But other then the Logitech custom controls set no support for
other custom controls was ever added to uvcdynctrl-data. So
the UVC driver maintainer said that he would be ok with just
adding these mappings directly to the kernel.

Once someone finds the time to actually add these mappings
to the kenrel libwebcam can be retired but until then it would
be nice if we can keep it around for uvcdynctrl.

Regards,

Hans

___
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: Unannounced? lua-libs soname change

2023-01-10 Thread Hans de Goede

Hi,

On 1/10/23 20:48, Kevin Kofler via devel wrote:
> Hans de Goede wrote:
>> lua-5.4.4-4.fc37 in F37 release provides both:
>>
>> liblua-5.3.so()(64bit)
>> liblua-5.4.so()(64bit)
>>
>> aka both of:
>>
>> /usr/lib64/liblua-5.3.so
>> /usr/lib64/liblua-5.4.so
> 
> This was a compatibility hack that was accidentally left enabled:
> https://src.fedoraproject.org/rpms/lua/c/519e6ee319c76a598fa09844a11461a091cb0e59?branch=rawhide
> 
>> but the recent update to lua-libs-5.4.4-7.fc37 only provides:
>>
>> liblua-5.4.so()(64bit)
>> /usr/lib64/liblua-5.4.so
> 
> which is how it should have been from the beginning.
> 
> Apparently, it was missed that some packages still depend on the old version 
> though. They need to be rebuilt.

Ok, the packages with deps on the old version appear to only be cegui
and megaglest I'll do builds + updates for the both of them.

Regards,

Hans

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

Non-responsive maintainer check for jhli

2023-01-10 Thread Ali Erdinc Koroglu


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

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

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



On Tue, Jan 10 2023 at 01:12:35 AM +0100, Kevin Kofler via devel 
 wrote:

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/


None of these are acceptable alternatives to sysprof. We need to be 
able to profile the entire desktop all at once; that point has been 
repeated many times and heavily emphasized throughout this discussion. 
So valgrind tools might be great at what they do, but they are not 
adequate replacements for sysprof. We also need to be able to profile 
applications that are already running, since sometimes we don't know 
how an application gets into a bad state that triggers a performance 
problem: if you can't initiate profiling once you've noticed the 
application running slow, then fixing the problem in impractical.


You've previously indicated that developers should just 'dnf 
distro-sync' to an alternative Fedora that has frame pointers, as if 
building two alternate versions of Fedora, one for developers and one 
for users, is a reasonable thing to do. The cost of this is just too 
high. We'd need double build infrastructure.


A 2.5% runtime slowdown won't make Fedora "unusable" like you claim. It 
will make us look mildly bad on benchmarks. The cost is clearly well 
worth the benefit in my opinion, but it's OK to disagree on this.


Michael

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

Re: Unannounced? lua-libs soname change

Simo Sorce wrote:
> Soname breakage should not happen in stable releases...

There are exceptions, including but not limited to security updates, which 
is relevant for Lua.

> liblua should be rebuilt to provide the older so name and if not
> possible with the new code, reverted back via epoch change or some
> patching

Providing the older soname is not possible with the new code. The way the 
old package worked is that it actually contained both Lua 5.3 and Lua 5.4, 
i.e., two completely different source trees, and the 5.3 sources were 
unmaintained and insecure.

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




On Mon, Jan 9 2023 at 06:54:09 PM +0100, Florian Weimer 
 wrote:

No one spoke out when the tools team was called untrustworthy on the
FESCo ticket.


That was one of my comments. [1] I should have worded that more 
carefully, but didn't because I was very frustrated. I apologize. What 
I meant here is that I strongly disagree with how the members of the 
toolchain team were evaluating the trade-offs in this issue. Of course 
I don't believe that you (or any other Fedora contributors) are 
generally untrustworthy.


[1] https://pagure.io/fesco/issue/2817#comment-830245


 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.


Sounds like everyone agrees the process here did not work very well. 
The FESCo meeting was held on January 3, which is first day back from 
holidays for most folks in the US, and probably other countries too. An 
hour or two before the revote, I was quite worried that I wouldn't be 
able to contact Christian in time to attend the meeting, since it was 9 
AM on first day back in his timezone. Contacting opponents of the 
change proposal was just not on my radar at all.


Anyway, the good news is there is still two more weeks until the mass 
rebuild begins, which is plenty of time for continued discussion and 
for FESCo to cancel the change if desired. So I don't think the outcome 
here was horribly unfair. I believe FESCo had an appropriate 
understanding of the considerations involved at the time of the vote: 
pay a performance price, gain ability to debug performance problems. 
(In particular, I doubt the _FORTIFY_SOURCE=3 change was really a major 
consideration here.)


Michael

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

Re: Unannounced? lua-libs soname change

Hans de Goede wrote:
> lua-5.4.4-4.fc37 in F37 release provides both:
> 
> liblua-5.3.so()(64bit)
> liblua-5.4.so()(64bit)
> 
> aka both of:
> 
> /usr/lib64/liblua-5.3.so
> /usr/lib64/liblua-5.4.so

This was a compatibility hack that was accidentally left enabled:
https://src.fedoraproject.org/rpms/lua/c/519e6ee319c76a598fa09844a11461a091cb0e59?branch=rawhide

> but the recent update to lua-libs-5.4.4-7.fc37 only provides:
> 
> liblua-5.4.so()(64bit)
> /usr/lib64/liblua-5.4.so

which is how it should have been from the beginning.

Apparently, it was missed that some packages still depend on the old version 
though. They need to be rebuilt.

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: Summary/Minutes from today's FESCo Meeting (2023-01-10)

Miro Hrončok wrote:
> * ACTION: bcotton to make a proposal on the mailing list to explicitly
> require full resubmission of rejected proposals (and then bring it
> to a FESCo ticket once discussion has happened)  (mhroncok,
> 18:36:36)

So FESCo is willing to prevent this from happening again in the future, but 
NOT to remedy the existing wrongdoing?

The only issue that was addressed was excluding architectures almost nobody 
uses anyway (i686, which has been multilibs-only for years, and s390x, which 
is for hardware no normal user has at home). x86_64 users will be hit by the 
performance hit of this change due to the irregularly reached decision, and 
nothing is being done to repair this before the damage is done.

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: Unannounced? lua-libs soname change

2023-01-10 Thread Simo Sorce

On Tue, 2023-01-10 at 20:29 +0100, Hans de Goede wrote:
> Hi,
> 
> lua-5.4.4-4.fc37 in F37 release provides both:
> 
> liblua-5.3.so()(64bit)
> liblua-5.4.so()(64bit)
> 
> aka both of:
> 
> /usr/lib64/liblua-5.3.so
> /usr/lib64/liblua-5.4.so
> 
> but the recent update to lua-libs-5.4.4-7.fc37 only provides:
> 
> liblua-5.4.so()(64bit)
> /usr/lib64/liblua-5.4.so
> 
> And the same appears to be happening in F36 (I did not check):
> 
> This is causing the following fails to install cegui bugs:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2156354
> https://bugzilla.redhat.com/show_bug.cgi?id=2156356
> https://bugzilla.redhat.com/show_bug.cgi?id=2156626
> 
> and the following fails to install megaglest bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2156357
> 
> I can rebuild cegui (and issue updates of it for f36 + f37),
> which I think might be easier/better then restoring the
> liblua compat build.
> 
> And I guess I can also take care of megaglest while at it,
> but first I wanted to make sure that this is the right
> way to move forward with fixing this...  ?


Soname breakage should not happen in stable releases...
liblua should be rebuilt to provide the older so name and if not
possible with the new code, reverted back via epoch change or some
patching

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

2023-01-10 Thread Eike Rathke

Hi,

On Monday, 2021-10-04 13:03:27 -0400, Matthew Miller wrote:

> But beyond that: What other things might be limits? Are there key bits of
> the distro which don't build yet?

Fwiw, I learned just yesterday that apparently to stay on the cheap side
they underspecified RISC-V FPU to omit some IEEE 754 optional behaviour
that would preserve and propagate a quiet NaN's payload in floating
point calculations. It may or may not (optionally) be supported on
a given RISC-V architecture.

That is a feature LibreOffice Calc makes heavy use of to transport error
information in doubles, where without those payload details it would
result in just a general NaN error for illegal FP operation.

Some other software may also use NaN payloads (R is mentioned in the
IEEE 754 .pdf on NaNs
https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf
("Known and possible uses of NaN payloads"), and JavaScript NaN-boxing
for type of data).

Further pointers in
https://bugs.documentfoundation.org/show_bug.cgi?id=152943

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A

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

Unannounced? lua-libs soname change

2023-01-10 Thread Hans de Goede

Hi,

lua-5.4.4-4.fc37 in F37 release provides both:

liblua-5.3.so()(64bit)
liblua-5.4.so()(64bit)

aka both of:

/usr/lib64/liblua-5.3.so
/usr/lib64/liblua-5.4.so

but the recent update to lua-libs-5.4.4-7.fc37 only provides:

liblua-5.4.so()(64bit)
/usr/lib64/liblua-5.4.so

And the same appears to be happening in F36 (I did not check):

This is causing the following fails to install cegui bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2156354
https://bugzilla.redhat.com/show_bug.cgi?id=2156356
https://bugzilla.redhat.com/show_bug.cgi?id=2156626

and the following fails to install megaglest bug:

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

I can rebuild cegui (and issue updates of it for f36 + f37),
which I think might be easier/better then restoring the
liblua compat build.

And I guess I can also take care of megaglest while at it,
but first I wanted to make sure that this is the right
way to move forward with fixing this...  ?

Regards,

Hans




___
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

Change Proposal: replace dnf with dnf5

2023-01-10 Thread David Cantrell

https://pagure.io/fesco/issue/2870
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5

This change proposal has been under discussion and revision for a while.  A
lot of work has gone in to this plan to minimize the disruption.  Still, dnf
is a core piece of software and we want to make sure everyone understands the
proposal and has an opportunity to discuss it.

The final revision of the proposal is available at the URL above.  FESCo is
waiting one more week for any remaining discussion on the change proposal.  We
plan to bring the proposal up for vote in the next meeting.

Thanks,

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

Summary/Minutes from today's FESCo Meeting (2023-01-10)


===
#fedora-meeting: FESCO (2023-01-10)
===


Meeting started by Eighth_Doctor at 17:00:24 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-10/fesco.2023-01-10-17.00.log.html
.



Meeting summary
---
* init process  (Eighth_Doctor, 17:02:53)

* #2870 Change proposal: Replace DNF with DNF5  (Eighth_Doctor,
  17:04:26)
  * LINK:
https://github.com/rpm-software-management/dnf5/discussions/210
(mhroncok, 17:07:51)
  * LINK: https://pagure.io/fesco/issue/2870#comment-832295   (mhroncok,
17:09:09)
  * ACTION: dcantrell will post to devel@ to trigger dnf/dnf5 discussion
(Eighth_Doctor, 17:25:19)

* Limiting the frame pointers thing to x86_64  (mhroncok, 17:25:47)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5EXPQL3APZZLVXE2N7BMG7EOETL5YX64/
(mhroncok, 17:28:45)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AZBSLQXEHGJLXHR65A5VVZXVF34XNJK4/
(mhroncok, 17:29:23)
  * LINK:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/231#comment-126098
is the reply from IBM s390x toolchain team  (sharkcz, 17:33:07)
  * LINK: https://gitlab.com/fedora/packager-tools/mass-prebuild should
help to identify what breaks with a flag change  (sharkcz, 17:44:24)
  * AGREED: Let's exclude i686 and s390x completely from the fomit frame
pointer thing for F38 (+7,0,-0)   (mhroncok, 17:57:16)
  * LINK:

https://www.goodreads.com/quotes/40705-but-the-plans-were-on-display-on-display-i-eventually
(sgallagh, 18:21:10)
  * ACTION: bcotton to make a proposal on the mailing list to explicitly
require full resubmission of rejected proposals (and then bring it
to a FESCo ticket once discussion has happened)  (mhroncok,
18:36:36)

* Next week's chair  (mhroncok, 18:42:23)
  * ACTION: zbyszek will chair next meeting  (mhroncok, 18:43:10)

Meeting ended at 18:43:17 UTC.




Action Items

* dcantrell will post to devel@ to trigger dnf/dnf5 discussion
* bcotton to make a proposal on the mailing list to explicitly require
  full resubmission of rejected proposals (and then bring it to a FESCo
  ticket once discussion has happened)
* zbyszek will chair next meeting




Action Items, by person
---
* bcotton
  * bcotton to make a proposal on the mailing list to explicitly require
full resubmission of rejected proposals (and then bring it to a
FESCo ticket once discussion has happened)
* dcantrell
  * dcantrell will post to devel@ to trigger dnf/dnf5 discussion
* zbyszek
  * zbyszek will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mhroncok (103)
* nirik (39)
* zbyszek (30)
* sgallagh (30)
* gotmax (30)
* Eighth_Doctor (28)
* davide (28)
* dcantrell (23)
* zodbot (16)
* bcotton (16)
* decathorpe (12)
* music[m] (9)
* jmracek (9)
* DaanDeMeyer[m] (6)
* mhayden (4)
* sharkcz (4)
* dtometzki (1)
* music (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: Unfiltered Flathub (System-Wide Change proposal)

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

Note that I am processing this proposal past the deadline because 1. I
think it could reasonably be considered a Self-Contained Change
proposal and 2. the reasons outlined by Mattias in another thread:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/PKUEM64L7FDGQBPRKZTHF5EF5FTLVSXG/

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 ==
Fedora Workstation's existing
[https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/
third party repo feature] allows users to enable a selection of
software repos that are hosted by external organizations. This
selection has included a filtered version of Flathub since F35, which
provides access to a small number of Flathub apps. This change would
remove the filtering from our Flathub offering, so that users can
enable a complete version of Flathub using the third party
repositories feature. In the graphical software manager app, Flathub
packages will only be selected by default when no Fedora package is
available.

== Owner ==

* Name: Workstation WG
* Email: mcla...@redhat.com

== Detailed Description ==
Since F35, Fedora has included a Flatpak repo definition for Flathub
in the fedora-flathub-remote package. This Flathub remote can be used
by those who enable third-party software repositories through either
GNOME Initial Setup or GNOME Software. Users who do not opt in do not
see any content from Flathub.

The current Flathub remote is filtered by an allowlist, to only make a
limited subset of software from Flathub available.

The unfiltered Flathub change has two parts:

# Remove the allowlist from the Flatpak remote, so that when a user
opts in, they gain access to all Flathub content and not just a small
selection.
# Adjust GNOME Software so that it uses the following priority order
when deciding which package to offer by default:
## Fedora Flatpaks
## RPMs
## Flathub Flatpaks

This will mean that, when using the graphical software manager,
Flathub Flatpaks will only be selected by default when there is no
Fedora Flatpak or RPM.

Other details:

* In GNOME Software, users will continue to be able to manually select
a different source for individual applications.
* The filtering mechanism will remain in place, and it will be
possible to reinstate a filter via a package update, should the need
arise in the future.
* It has been indicated that it is legally acceptable for us to remove
the filtering from the Flathub remote that we make available for users
to opt into.
* The UI for enabling the third party repositories clearly states that
they contain proprietary software.
* GNOME Software shows information about whether apps are open source
or proprietary, so that users can decide whether they want to install
them or not.

== Feedback ==
A previous version of this proposal was rejected by FESCo for Fedora
37. It has subsequently been modified to address the concerns raised:

* GNOME Software will prefer packages that have been through the
Fedora packaging process, over those that have not.
* For developer tools that do not work well in a sandbox, there will
be no Fedora Flatpak, and the RPM will be preferred over the Flathub
Flatpak.

Some other questions and concerns that were raised in the previous discussion:

=== Who owns and runs Flathub? ===

Flathub is owned and run by [https://foundation.gnome.org/ the GNOME
Foundation], which is a 501c(3) organization registered in the USA.
(The GNOME Foundation
[https://foundation.gnome.org/legal-and-trademarks/ owns the Flathub
trademark], and employs one of the sysadmins who works on Flathub.)

As a non-profit, the GNOME Foundation is required to fulfill a
charitable purpose. This is set out in its IRS registration, which
states that the organization's mission is "broadening access to
technology through the development and distribution of... usable free
computer desktop software".

The GNOME Foundation is governed by its Board of Directors, which is
elected by contributors to the GNOME project.

Plans exist to create additional governance around Flathub itself, so
that other desktops and projects have a formal role in the running of
the Flathub service.

=== Isn't Flathub full of repackaged binaries? ===

At present, around 10% of the apps on Flathub have been repackaged
from another format. These other formats include distro packages and
tarballs, as well as binaries. (The previous figure was 12% - the
analysis for this can be read
[https://blogs.gnome.org/wjjt/2022/06/14/how-many-flathub-apps-reuse-other-package-formats/
here].)

Flathub prefers that apps be built from source, and if sources are
available this is what it is expected to be used. Repackaging is only
used when sources aren't available,

Re: A late change proposal

On Tue, Jan 10, 2023 at 12:53 PM Stephen Gallagher  wrote:
>
> I agree, this should be fine to consider. We still should give it a
> week in the devel list before voting on it. I haven't seen the
> official announcement email go out yet.

It has now! 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JXUEWBN6ZDFNOY4BKUH4MS343KFHMQYT/

(For the sake of posterity, let's keep further discussion on that thread)

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

F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

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

Note that I am processing this proposal past the deadline because 1. I
think it could reasonably be considered a Self-Contained Change
proposal and 2. the reasons outlined by Mattias in another thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PKUEM64L7FDGQBPRKZTHF5EF5FTLVSXG/

== Owner ==

* Name: Workstation WG
* Email: mcla...@redhat.com

The current Flathub remote is filtered by an allowlist, to only make a
limited subset of software from Flathub available.

The unfiltered Flathub change has two parts:

This will mean that, when using the graphical software manager,
Flathub Flatpaks will only be selected by default when there is no
Fedora Flatpak or RPM.

Other details:

== Feedback ==
A previous version of this proposal was rejected by FESCo for Fedora
37. It has subsequently been modified to address the concerns raised:

Some other questions and concerns that were raised in the previous discussion:

=== Who owns and runs Flathub? ===

The GNOME Foundation is governed by its Board of Directors, which is
elected by contributors to the GNOME project.

Plans exist to create additional governance around Flathub itself, so
that other desktops and projects have a formal role in the running of
the Flathub service.

=== Isn't Flathub full of repackaged binaries? ===

Flathub prefers that apps be built from source, and if sources are
available this is what it is expected to be used. Repackaging is only
used when sources aren't available,

Re: A late change proposal

2023-01-10 Thread Stephen Gallagher

On Tue, Jan 10, 2023 at 12:00 PM Neal Gompa  wrote:
>
> On Tue, Jan 10, 2023 at 11:39 AM Matthias Clasen  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
> >
> > Before xmas, when the deadline for system-wide changes came near,
> > I flipped this change proposal to the ChangePageReadyForWrangler category,
> > and thereby send it to neverneverland, since the correct category is
> > ChangeReadyForWrangler :(
> >
> > I've corrected that today, and I would like to ask that this feature could
> > maybe still be considered, even though it is late by now.
> >
> > The reasons are:
> >
> > - While this is flagged as a system-wide change, really the only 
> > system-widge
> >aspect here is policy (there are no releng or other coordination needs)
> >
> > - This is not a new feature, it has been discussed before, so the discussion
> >   will hopefully be short and can focus on the changes we made to address
> >   the concerns from last time.
> >
> > - It was submitted in time and only missed the deadline due to process 
> > gotchas.
> >
>
> I'm fine with it, given the scope of the Change itself.

I agree, this should be fine to consider. We still should give it a
week in the devel list before voting on it. I haven't seen the
official announcement email go out yet.
___
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 10. 01. 23 13:52, Richard Shaw wrote:

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


Looks like the problem is using `rpkg` but that's the easiest method and has 
worked great until now...


For the record I've reported several issues with the rpkg method over the 
years. The distgit method was partially a response for those. tl;dr rpkg "works 
great" until it doesn't because it does not work like fedpkg, but instead it is 
a pre-processor for templated spec files that happens to work in most of the 
cases with bare spec files as well.


Examples:

https://pagure.io/copr/copr/issue/1703
https://pagure.io/copr/copr/issue/798
https://pagure.io/copr/copr/issue/1219

Umbrella issue:
https://pagure.io/copr/copr/issue/529

--
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: Automation of Fedora SCM requests

Most of the issues are resolved now. There is one remaining ticket [0] 
that is returning 500 on branch creation. I will continue investigation 
on this ticket tomorrow.


I'm sorry for the rough start.

On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests/issue/50370

On 10. 01. 23 13:52, Michal Konecny wrote:

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be 
processed automatically. If you find any issue with the automation, 
please report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working 
on automating Fedora SCM requests [0]. The automation is currently 
live on staging. You can see the output (closed tickets) in Fedora 
SCM requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more 
about it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make 
the job of Fedora Release Engineering Team easier and let them focus 
on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274




___
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

Re: Automation of Fedora SCM requests

Most of the issues are resolved now. There is one remaining ticket [0] 
that is returning 500 on branch creation. I will continue investigation 
on this ticket tomorrow.


I'm sorry for the rough start.

On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests/issue/50370

On 10. 01. 23 13:52, Michal Konecny wrote:

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be 
processed automatically. If you find any issue with the automation, 
please report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working 
on automating Fedora SCM requests [0]. The automation is currently 
live on staging. You can see the output (closed tickets) in Fedora 
SCM requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more 
about it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make 
the job of Fedora Release Engineering Team easier and let them focus 
on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274




___
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: Automation of Fedora SCM requests

The documentation would need to be updated in multiple places, but I 
didn't know about this one. Thanks for sharing.


Michal

On 10. 01. 23 14:08, Richard Shaw wrote:
On Tue, Jan 10, 2023 at 5:26 AM Michal Konecny  
wrote:


Hi everyone,

this automation is now in place and new SCM requests will be
processed automatically. If you find any issue with the
automation, please report it to toddlers issue tracker [0].

On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues


While I'm hopeful I can find this email if needed but it would be 
better if this was documented here (and wherever else appropriate):


https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner

Thanks,
Richard

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.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: Donate 1 minute of your time to test upgrades from F36 to F37

2023-01-10 Thread Stephen Smoogen

On Tue, 10 Jan 2023 at 11:55, Stuart S  wrote:

> I've just tried this for Fed 35 >> Fed 37
>
> Got the following errors
>
>  Problem: conflicting requests
>   - nothing provides module(platform:f35) needed by module
> php:remi-7.4:20230104141955:.x86_64
>

You have an outside module installed on the system. Going from the name I
would expect it is the remi PHP ones. You will need to disable that module
and/or replace it with the f37 one to get things going.



> Error:
>  Problem 1: package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64
> requires php(api) = 20190902-64, but none of the providers can be installed
>   - package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 requires
> php(zend-abi) = 20190902-64, but none of the providers can be installed
>   - php-common-7.4.33-2.fc35.remi.x86_64 does not belong to a distupgrade
> repository
>   - problem with installed package
> php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64
>  Problem 2: package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires
> libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers
> can be installed
>   - package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires
> qt5-qtbase(x86-64) = 5.15.2, but none of the providers can be installed
>   - qt5-qtbase-5.15.2-31.fc35.x86_64 does not belong to a distupgrade
> repository
>   - problem with installed package qt5-qtenginio-1:1.6.2-36.fc35.x86_64
> (try to add '--skip-broken' to skip uninstallable packages)
>
>
> I know this is not a help page but can someone point me in right direction
> as I can't find it...
>
> Cheers
> ___
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

Retiring libwebcam

2023-01-10 Thread Michael Cronenworth


Hi all,

Unless someone speaks up in the next week I am going to retire the libwebcam[1] 
package.

Background: Some of the first USB web cameras using the "UVC" protocol needed a 
user-space driver for controlling the hardware features. Logitech developed the 
libwebcam library as an interface for users. Around 2014 Logitech stopped 
development on it and it is now abandoned.


I have seen replacements pop up with the 'v4l-utils' package and the v4l2-ctl CLI 
tool and guvcview graphical tool. Both receive modern care so I don't see a need to 
continue shipping the libwebcam package. There are no known (reqoquery) dependencies 
on libwebcam.


Thanks,
Michael

[1] https://src.fedoraproject.org/rpms/libwebcam
___
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-10)

On Tue, Jan 10, 2023 at 11:48 AM Neal Gompa  wrote:
>
> Following is the list of topics that will be discussed in the
> FESCo meeting Tuesday at 18:00UTC in #fedora-meeting on
> irc.libera.chat.

This is, in fact, at 17:00 UTC. I missed updating this on my local
template. Sorry.



-- 
Neal Gompa (FAS: ngompa)
___
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: A late change proposal

On Tue, Jan 10, 2023 at 11:39 AM Matthias Clasen  wrote:
>
> https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
>
> Before xmas, when the deadline for system-wide changes came near,
> I flipped this change proposal to the ChangePageReadyForWrangler category,
> and thereby send it to neverneverland, since the correct category is
> ChangeReadyForWrangler :(
>
> I've corrected that today, and I would like to ask that this feature could
> maybe still be considered, even though it is late by now.
>
> The reasons are:
>
> - While this is flagged as a system-wide change, really the only system-widge
>aspect here is policy (there are no releng or other coordination needs)
>
> - This is not a new feature, it has been discussed before, so the discussion
>   will hopefully be short and can focus on the changes we made to address
>   the concerns from last time.
>
> - It was submitted in time and only missed the deadline due to process 
> gotchas.
>

I'm fine with it, given the scope of the Change itself.



-- 
真実はいつも一つ！/ 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: Porting Fedora for the LoongArch architecture.

2023-01-10 Thread Robin Lee

On Tue, Jan 10, 2023 at 11:13 PM 孙海勇  wrote:
>
> Hi everyone,
>
> I am Sun Haiyong, from China. I want to port Fedora for the LoongArch
> architecture.
> LoongArch is a RISC ISA released by Loongson Technology Corporation Limited,
> and has supported a series of (Binutils, GCC, Linux, Glibc, LLVM, QEMU,
> etc.)
> core open source projects.
>
> Currently, there are many linux distributions that can run on LoongArch
> machines,
> they are OpenEuler, OpenAnolis, UOS, Kylin.
>
> I am good at cross-compiling operating systems and often build Linux systems
> using something like LFS or CLFS.
>
> I have built Linux distributions using rpm package management from scratch
> several times since 2015 (some systems are not publicly available):
>
> 1 Fedora 21, 28, 32 based on MIPS64EL architecture;
> 2 CentOS 7 based on MIPS64EL architecture;
> 3 CentOS 7 based on Power8 architecture;
> 4 CentOS 8.3 based on LoongArch architecture;
> 5 OpenEuler 2109 based on LoongArch architecture.
>
> And I have published a book on porting Fedora systems to new architectures.
>
> I want to add LoongArch to the official Fedora support architecture, and
> I've
> been doing so for some time, here's some of what I've done so far：
>
> To verify the feasibility of building a LoongArch architecture branch for
> Fedora, I have used the software version from the rawhide git repository,
> and have now compiled a large number of base packages and built a temporary
> repository that can be accessed at https://mirrors.wsyu.edu.cn/fedora/
>
> I have compiled and generated more than 45,000 installable rpm files (of
> course there are a lot of perl, Python, rust and texlive files), and the
> number is still expanding, the scope of the package is enough to build a
> LiveCD system, for which I have built LXDE, MATE, WorkStation ( Gnome3) of
> the LiveCD and the installation of the ISO, you can get in the following
> address: https://github.com/fedora-remix-loongarch/releases-info
>
> Of course, there are still a lot of problems with LoongArch's Fedora system,
> for example, some software is not yet fully supported by the upstream
> community, but I believe the power of the community can gradually improve
> them, so I am sending out an email here to get more people to support this
> new LoongArch architecture.
>
> I have recruited some developers who are interested in this and they are：
>
> Wu Xiaotian
> Chen Huacai
> Shi Pujin
> Si Yanteng
> Chen Feiyang
>
> Of course, there are many other users who are interested in Fedora systems.
>
> I'm currently a newbie in the Fedora community, so I need help from
> community
> developers, and would like someone to guide me on what to do next, such as
> what would be a better time to submit necessary patches to packages in the
> Fedora repository, how to develop in a collaborative manner, what other
> systems to be used for management, etc. In short, any information would be
> useful. Could I get help here? :)
>
> Again, thanks for reading this email.

Hi, 海勇 and other LoongArch contributors!

I am a long-term Chinese Fedora packager. I also got interested in
LoongArch recently
and started to create some PRs[1][2] related to LoongArch.

Please feel free to reach out to me personally. I hope I can help you
from the Fedora side.

[1] https://src.fedoraproject.org/rpms/cross-binutils/pull-request/2
[2] https://src.fedoraproject.org/rpms/cross-gcc/pull-request/3
-robin
>
> Best Regards
> Sun Haiyong
> ___
> 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

Schedule for Tuesday's FESCo Meeting (2023-01-10)

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

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

or run:
  date -d '2023-01-10 17:00 UTC'


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

= Discussed and Voted in the Ticket =

Change: Use mdadm for BIOS RAID Support in Anaconda
https://pagure.io/fesco/issue/2922
APPROVED (+5, 0, -0)

Change: Pyramid 2.0
https://pagure.io/fesco/issue/2924
APPROVED (+6, 0, -0)

Change: Xfce 4.18
https://pagure.io/fesco/issue/2925
APPROVED (+6, 0, -0)

Change: Unified Kernel Support Phase 1
https://pagure.io/fesco/issue/2926
APPROVED (+5, 0, -0)

Change: X Server Prohibits Byte-swapped Clients
https://pagure.io/fesco/issue/2927
APPROVED (+6, 0, -0)

= Followups =

#2870 Change proposal: Replace DNF with DNF5
https://pagure.io/fesco/issue/2870

= New business =

None at this time.

= Open Floor = 

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

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

A late change proposal

2023-01-10 Thread Matthias Clasen

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

Before xmas, when the deadline for system-wide changes came near,
I flipped this change proposal to the ChangePageReadyForWrangler category,
and thereby send it to neverneverland, since the correct category is
ChangeReadyForWrangler :(

I've corrected that today, and I would like to ask that this feature could
maybe still be considered, even though it is late by now.

The reasons are:

- While this is flagged as a system-wide change, really the only
system-widge
   aspect here is policy (there are no releng or other coordination needs)

- This is not a new feature, it has been discussed before, so the discussion
  will hopefully be short and can focus on the changes we made to address
  the concerns from last time.

- It was submitted in time and only missed the deadline due to process
gotchas.

Matthias
___
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: Donate 1 minute of your time to test upgrades from F36 to F37

2023-01-10 Thread Stuart S

I've just tried this for Fed 35 >> Fed 37

Got the following errors

 Problem: conflicting requests
  - nothing provides module(platform:f35) needed by module 
php:remi-7.4:20230104141955:.x86_64
Error: 
 Problem 1: package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 requires 
php(api) = 20190902-64, but none of the providers can be installed
  - package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 requires 
php(zend-abi) = 20190902-64, but none of the providers can be installed
  - php-common-7.4.33-2.fc35.remi.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package 
php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64
 Problem 2: package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires 
libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers can be 
installed
  - package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires qt5-qtbase(x86-64) = 
5.15.2, but none of the providers can be installed
  - qt5-qtbase-5.15.2-31.fc35.x86_64 does not belong to a distupgrade repository
  - problem with installed package qt5-qtenginio-1:1.6.2-36.fc35.x86_64
(try to add '--skip-broken' to skip uninstallable packages)


I know this is not a help page but can someone point me in right direction as I 
can't find it...

Cheers
___
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: Porting Fedora for the LoongArch architecture.

2023-01-10 Thread Matthew Miller

On Tue, Jan 10, 2023 at 11:12:22PM +0800, 孙海勇 wrote:
> I want to add LoongArch to the official Fedora support architecture,

This is really cool -- welcome, and I'd love to help make sure you succeed!

> I'm currently a newbie in the Fedora community, so I need help from
> community developers, and would like someone to guide me on what to do
> next, such as what would be a better time to submit necessary patches to
> packages in the Fedora repository, how to develop in a collaborative
> manner, what other systems to be used for management, etc. In short, any
> information would be useful. Could I get help here? :)

This message is a good start! There is a little bit of information here
https://fedoraproject.org/wiki/Architectures, but it's not really complete.
I'm afraid a lot of the knowledge is really held in a few people's heads.
Hopefully we can get you connected with the right people!


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


On 10. 01. 23 0:44, Kevin Kofler via devel wrote:

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


That is certainly a possibility, but it's not helpful to tell that to me 
personally. I have not voted for this change, I have abstained, because I was 
not sure the promises made by the approved statement are likely to be held.


--
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: [Modularity] XML format for in-repository modules

2023-01-10 Thread Petr Pisar

V Wed, Dec 07, 2022 at 04:31:36PM -0500, Stephen Gallagher napsal(a):
> On Wed, Dec 7, 2022 at 8:40 AM Petr Pisar  wrote:
> ...
> > As you can see, there are no separate documents for modules and default
> > streams. Everything is kept inside one document. That enables
> > properties (e.g. obsoletes or default profiles) pertaining the same entity
> > (e.g. a stream) to be placed together. That prevents from repeating the
> > identifiers (e.g. stream names) and makes the format more succinct and 
> > easier
> > for querying.
> 
> To provide a bit of context here: the output format containing all of
> the modules, streams and defaults together makes perfect sense. Please
> make sure to keep in mind that the input format still needs to
> recognize at least some of these differences. The reason is that the
> default stream must be specified on a per-distribution/release basis.
> Its input file has to therefore be independent from the module stream
> definition. Initially, the modulemd design had both default streams
> and default profiles specified as content that was to be managed by
> the distribution, rather than the module maintainer. We later realized
> that the default profile selection should be left up to that stream's
> maintainer. Unfortunately, our output format still maintained it as
> part of the modulemd-defaults document. This is part of why we created
> the modulemd-packager format. This format enabled maintainers to
> specify their preferred stream defaults in the packager document and
> the result would be output that translated that into the
> modulemd-defaults format.
> 
> If we're going the route of entirely replacing the output format, then
> this is definitely a place we can improve upon. But please keep the
> default stream selection independent from the stream definition.
> 
Thanks for explaining the reasons behind the YAML fromat design.

Now I do not plan changing the input YAML format. The output XML is capable to
deliver definitions of default streams independently of module build
definitions:

http://fedoraproject.org/metadata/moduleindex; version="1" 
revision="0">





When DNF will see a document like that it will know that a default perl stream
is 5.34. It does not imply that there is a perl module build for installation
or even presentation in "dnf module list" command.

The default profile can be similarly encoded like that:

http://fedoraproject.org/metadata/moduleindex; version="1" 
revision="0">



default





If a module maintainer specified a default profile in modulemd-packager
document, it would be encoded in XML like this:

http://fedoraproject.org/metadata/moduleindex; version="1" 
revision="0">



...


default





This is similar how MBS is supposed to produce YAML output documents. (I write
supposed because MBS does not implement this feature yet.)

> Regarding glib: it was chosen entirely because DNF (at the time) was
> using already using it, so it would theoretically simplify the
> consumption of libmodulemd. If DNF5 has moved away from glib, I don't
> see any reason why libmodulemd couldn't do the same. However, since
> DNF isn't the only consumer of libmodulemd, I'd very much like to see
> this new parser implementation made available as an external library
> with a public API that DNF5 consumes, rather than as an internal
> detail of DNF. While I understand (and even like) that XML gives you
> syntax validation capabilities, libmodulemd was also capable of
> recognizing logical errors (such as specifying a default profile that
> doesn't exist in the stream). A library that can provide such
> hand-holding would be very valuable to anyone who intends to consume
> the new format. The API can also guide the consumer to the data they
> care about, rather than forcing them to parse the XML directly.

Yes, the XML parser will be a separate library from libmodulemd library.
Regarding validator, there probably will be a validating tool for the XML
format. I'm aware that XML Schema is unable to grasp all contrains and
recommendations and that for users it's easier to execute a dedicated tool
than invoke xmllint with a path to the schema burried somewhere deep in a file
system.

-- Petr


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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2023-01-10 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2023-01-11 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

___
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

Re: Porting Fedora for the LoongArch architecture.

On Tue, Jan 10, 2023 at 10:13 AM 孙海勇  wrote:
>
> Hi everyone,
>
> I am Sun Haiyong, from China. I want to port Fedora for the LoongArch
> architecture.
> LoongArch is a RISC ISA released by Loongson Technology Corporation Limited,
> and has supported a series of (Binutils, GCC, Linux, Glibc, LLVM, QEMU,
> etc.)
> core open source projects.
>
> Currently, there are many linux distributions that can run on LoongArch
> machines,
> they are OpenEuler, OpenAnolis, UOS, Kylin.
>
> I am good at cross-compiling operating systems and often build Linux systems
> using something like LFS or CLFS.
>
> I have built Linux distributions using rpm package management from scratch
> several times since 2015 (some systems are not publicly available):
>
> 1 Fedora 21, 28, 32 based on MIPS64EL architecture;
> 2 CentOS 7 based on MIPS64EL architecture;
> 3 CentOS 7 based on Power8 architecture;
> 4 CentOS 8.3 based on LoongArch architecture;
> 5 OpenEuler 2109 based on LoongArch architecture.
>
> And I have published a book on porting Fedora systems to new architectures.
>
> I want to add LoongArch to the official Fedora support architecture, and
> I've
> been doing so for some time, here's some of what I've done so far：
>
> To verify the feasibility of building a LoongArch architecture branch for
> Fedora, I have used the software version from the rawhide git repository,
> and have now compiled a large number of base packages and built a temporary
> repository that can be accessed at https://mirrors.wsyu.edu.cn/fedora/
>
> I have compiled and generated more than 45,000 installable rpm files (of
> course there are a lot of perl, Python, rust and texlive files), and the
> number is still expanding, the scope of the package is enough to build a
> LiveCD system, for which I have built LXDE, MATE, WorkStation ( Gnome3) of
> the LiveCD and the installation of the ISO, you can get in the following
> address: https://github.com/fedora-remix-loongarch/releases-info
>
> Of course, there are still a lot of problems with LoongArch's Fedora system,
> for example, some software is not yet fully supported by the upstream
> community, but I believe the power of the community can gradually improve
> them, so I am sending out an email here to get more people to support this
> new LoongArch architecture.
>
> I have recruited some developers who are interested in this and they are：
>
> Wu Xiaotian
> Chen Huacai
> Shi Pujin
> Si Yanteng
> Chen Feiyang
>
> Of course, there are many other users who are interested in Fedora systems.
>
> I'm currently a newbie in the Fedora community, so I need help from
> community
> developers, and would like someone to guide me on what to do next, such as
> what would be a better time to submit necessary patches to packages in the
> Fedora repository, how to develop in a collaborative manner, what other
> systems to be used for management, etc. In short, any information would be
> useful. Could I get help here? :)
>
> Again, thanks for reading this email.
>

I think a starting point is to talk to Fedora Infrastructure and
Release Engineering about this.

Also, is there any server-class hardware that can be racked for us to
power builds? We don't typically do emulated builds because they're
incredibly slow.

That said, Fedora RISC-V is probably a good blueprint for how to get
started bootstrapping LoongArch in Fedora. Those folks are here on
this list and they can reply with some details (I don't remember
exactly how they did it).




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

2023-01-10 Thread Jerry James

On Tue, Jan 10, 2023 at 8:14 AM David Howells  wrote:
> Also, the isl package was split out from gcc so that cross-gcc could use it
> also, but gcc now seems to be carrying its own isl package of a different
> version (0.12.2 rather than 0.16.1).  Do we still build with isl support or
> could this also be dropped?

The sagemath package would like to build with isl support, but needs
version 0.12.0 or later.  There is a "BuildRequires: pkgconfig(isl)"
in sagemath.spec in case the system version is ever updated, but right
now the build system rejects it as being too old.
-- 
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: [Modularity] XML format for in-repository modules

2023-01-10 Thread Petr Pisar

V Wed, Dec 07, 2022 at 02:45:28PM -, Daniel Alley napsal(a):
> 
> In practice I am not certain that Satellite (and similar tools) can prefer
> the XML metadata precisely because it is cut down, so in repos which contain
> both Yaml and XML metadata it will not be possible to recreate the original
> Yaml from the metadata in the XML without losing the "packager" specific
> bits, should they exist.  Perhaps that is actually fine, but it makes me
> uncomfortable, and we have to support the Yaml parsing anyway due to the
> distros which will only ever support Yaml, which unfortunately makes it is
> the greatest common denominator.  
> 
> I presume there are no plans to remove the Yaml metadata from repos
> entirely?

There are no plans to remove YAML from repositories. The modular metadata are
relatively small comparing to other data in the repository, so there is no
pressure on removing the YAML files.

-- Petr


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

Re: [Modularity] XML format for in-repository modules

2023-01-10 Thread Petr Pisar

V Wed, Dec 07, 2022 at 02:43:32PM +0100, Ewoud Kohl van Wijngaarden napsal(a):
> On Wed, Dec 07, 2022 at 02:23:18PM +0100, Petr Pisar wrote:
> > Those who should be concerned most are DNF5 developers and relengs producing
> > composes.
> 
> There are third party repositories which also publish modular metadata. I
> know this because in yum.theforeman.org we do this. Do we fall under relengs
> producing composes?
> 
Yes. If you produce a repository with modular metadata, then you are the
target audience.

I believe that DNF will retain support for YAML format for some (rather long) 
period.

> > If you are interested in it, I recommend starting with overview.xml file. It
> > shows a skeleton of the format. It's so small I can quote it here:
> > 
> > http://fedoraproject.org/metadata/moduleindex; version="" 
> > revision="">
> >
> > 
> > > description="">
> >
> >...
> >
> 
> Is comunity a typo for community?
> 
Yes. A typo. Thanks for the review. I fixed it now.

> > A grand plan how to implement and deploy this format is outlined in
> > top-level README.md
> > .
> > Basically it will be injected into createrepo_c tool to produce the XML data
> > in YUM repositories.
> 
> I really like integration into the existing tooling like createrepo_c. That
> was a massive gap in functionality. The plan is rather light on these
> details so I'd be interested to see how you plan to expose this
> functionality.

Yes, this has not yet been planned in details. It's indeed handy that
crearerepo_c automatically recognizes YAML files.

My plan is to enhance createrepo_c so that when it sees the YAML files, it
will put them into repodata as now and in addition convert them into XML and
put the XML files into repodata.

Naturally there will be a new option to disable this feature and to specify
a version of the XML format. That's to maintain a repository format for older
distributions. Whether producing XML will be the default mode of operation,
or it will be on demand will depend on createrepo_c maintainers. I guess they
have better insight on what the default behaviour should look like than me.

-- Petr



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

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

2023-01-10 Thread David Howells

I wonder if we should drop the cloog package from Fedora.  It was separated
from gcc so that both gcc and cross-gcc could use it.  However neither of them
now do.

Also, the isl package was split out from gcc so that cross-gcc could use it
also, but gcc now seems to be carrying its own isl package of a different
version (0.12.2 rather than 0.16.1).  Do we still build with isl support or
could this also be dropped?

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

Porting Fedora for the LoongArch architecture.

2023-01-10 Thread 孙海勇


Hi everyone,

I am Sun Haiyong, from China. I want to port Fedora for the LoongArch 
architecture.

LoongArch is a RISC ISA released by Loongson Technology Corporation Limited,
and has supported a series of (Binutils, GCC, Linux, Glibc, LLVM, QEMU, 
etc.)

core open source projects.

Currently, there are many linux distributions that can run on LoongArch 
machines,

they are OpenEuler, OpenAnolis, UOS, Kylin.

I am good at cross-compiling operating systems and often build Linux systems
using something like LFS or CLFS.

I have built Linux distributions using rpm package management from scratch
several times since 2015 (some systems are not publicly available):

1 Fedora 21, 28, 32 based on MIPS64EL architecture;
2 CentOS 7 based on MIPS64EL architecture;
3 CentOS 7 based on Power8 architecture;
4 CentOS 8.3 based on LoongArch architecture;
5 OpenEuler 2109 based on LoongArch architecture.

And I have published a book on porting Fedora systems to new architectures.

I want to add LoongArch to the official Fedora support architecture, and 
I've

been doing so for some time, here's some of what I've done so far：

To verify the feasibility of building a LoongArch architecture branch for
Fedora, I have used the software version from the rawhide git repository,
and have now compiled a large number of base packages and built a temporary
repository that can be accessed at https://mirrors.wsyu.edu.cn/fedora/

I have compiled and generated more than 45,000 installable rpm files (of
course there are a lot of perl, Python, rust and texlive files), and the
number is still expanding, the scope of the package is enough to build a
LiveCD system, for which I have built LXDE, MATE, WorkStation ( Gnome3) of
the LiveCD and the installation of the ISO, you can get in the following
address: https://github.com/fedora-remix-loongarch/releases-info

Of course, there are still a lot of problems with LoongArch's Fedora system,
for example, some software is not yet fully supported by the upstream
community, but I believe the power of the community can gradually improve
them, so I am sending out an email here to get more people to support this
new LoongArch architecture.

I have recruited some developers who are interested in this and they are：

Wu Xiaotian
Chen Huacai
Shi Pujin
Si Yanteng
Chen Feiyang

Of course, there are many other users who are interested in Fedora systems.

I'm currently a newbie in the Fedora community, so I need help from 
community

developers, and would like someone to guide me on what to do next, such as
what would be a better time to submit necessary patches to packages in the
Fedora repository, how to develop in a collaborative manner, what other
systems to be used for management, etc. In short, any information would be
useful. Could I get help here? :)

Again, thanks for reading this email.

Best Regards
Sun Haiyong
___
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-10 Thread Matthew Miller

On Mon, Jan 09, 2023 at 10:08:11PM +0100, Mark Wielaard wrote:
> > ... 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.
[...]
> 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).

To be clear -- I don't think what happened is in conflict with the _FESCo_
policy about tickets (see link above). FESCo does not, as far as I can see,
have any specific policies about how votes related to a Change should be
conducted. And I don't think there is a general "FESCo can never reconsider
decisions!" rule.

But like I said, I _don't_ think this revote was as visible or transparent
as it should have been, and I agree that that doesn't really fit with the
intention of the Changes policy.


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

Yep, I definitely agree with this.


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

2023-01-10 Thread Diego Herrera

I have a roundabout way to make COPR and rpmautospec work with any git repo :)

1. Create a new COPR project
2. Add a new COPR package with source type Custom
- Script
#! /bin/sh -x
git clone  
cd 
spectool -g 
#other stuff you need to prepare
rpmautospec process-distgit  
- Build dependencies:
git rpmdevtools rpmautospec
- Result directory:

3. Press Save and Rebuild
4. Wait for the results. Release and changelogs should work as expected
___
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 9 2023 at 11:04:11 AM +0100, Lennart Poettering 
 wrote:

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.


Web browser core dumps will fail by default due to the 2 GB limit on 
core dumps, after which systemd-coredump truncates the core dump. I 
think we should raise the default core size limit to at least 20 GB.


___
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 2157099] perl-DateTime-Format-Natural-1.14 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157099
Bug 2157099 depends on bug 2157628, which changed state.

Bug 2157628 Summary: Review Request: perl-DateTime-HiRes - Create DateTime 
objects with sub-second current time resolution
https://bugzilla.redhat.com/show_bug.cgi?id=2157628

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157099
___
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)

Am Dienstag, 10. Jänner 2023 08:25:27 CET schrieb Zbigniew 
Jędrzejewski-Szmek:

On Mon, Jan 09, 2023 at 11:53:17PM +0100, Kevin Kofler via devel wrote:
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.


Nonsense! Where am I confirming anything? (Quite the opposite, in fact!) 
Why do you keep completely missing the point of what I wrote?



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 point of the message you first replied to is that I believe that voters 
may have been tricked into voting differently, by inviting only one side of 
the discussion and by providing the voters with a misleadingly biased 
presentation of the facts (up to baseless allegations of double standards 
against the Tools Team, based only on a misunderstanding of performance 
measurements).



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.


It would if that were the issue at hand. It is not. The issue is with those 
who did vote.



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.


No. The message very verbosely explains errors in the process, not in the 
outcome. Inviting only one side of the discussion is inherently biased. Not 
allowing sufficient time for discussion is also a way to silence dissenting 
opinions. No matter whether it has been done deliberately or accidentally. 
The ultimate outcome is that the vote has happened under unfair 
circumstances.


Sure, I also happen to think that the result should be different. For 
explanations of that, see one of my mails with clear technical objections 
to this change. But that was NOT the matter of the mail to which you are 
replying here. That mail was about HOW that result was obtained, pointing 
out clear procedural bias that you refuse to acknowledge.


   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)

2023-01-10 Thread Siddhesh Poyarekar

On Tue, Jan 10, 2023 at 3:05 AM Zbigniew Jędrzejewski-Szmek
 wrote:
> 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.

What's being alleged is that many members were tricked into changing
their vote by using the false narrative about _FORTIFY_SOURCE proposal
getting an unfair pass despite performance concerns (which *I*
hypothesized months ago and I later dispelled, in the end even quoting
benchmark results for it) and creating the impression that the
toolchain team is being duplicitous about the performance question.
Further trickery involved rushing the vote, claiming that it had to be
done soon to meet the mass rebuild deadline; too bad if those who had
strong objections earlier weren't around to put their comments on
record.

In that context the vote could in fact be considered rigged.  If the
voting members could come out and clarify exactly why they changed
their vote, it would make things a lot clearer.

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

[EPEL-devel] Re: libmaxminddb removed from epel7

2023-01-10 Thread Stephen Smoogen

On Tue, 10 Jan 2023 at 04:41, Sebastian Albrecht <
sebastian.albre...@agido.com> wrote:

> Hi Dan,
> thank you for answering. Is there a known reason, why it was removed for
> the x86_64 arch but not for aarch64? Because i can still find it there.
>
>
aarch64 is a 'dead' release for EL-7 with no updates since 2019. This has a
knock-on effect that nothing gets removed either until 2024 without
removing all the packages from the mirrors.



> BR,
> Sebastian.
> ___
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

Re: Automation of Fedora SCM requests

On Tue, Jan 10, 2023 at 5:26 AM Michal Konecny  wrote:

> Hi everyone,
>
> this automation is now in place and new SCM requests will be processed
> automatically. If you find any issue with the automation, please report it
> to toddlers issue tracker [0].
>
> On behalf of CPE Team,
> Michal
>
> [0] - https://pagure.io/fedora-infra/toddlers/issues
>

While I'm hopeful I can find this email if needed but it would be better if
this was documented here (and wherever else appropriate):

https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner

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

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

2023-01-10 Thread Josh Boyer

On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
 wrote:
>
> On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
> >
> > 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

Re: Automation of Fedora SCM requests


Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please 
report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make the 
job of Fedora Release Engineering Team easier and let them focus on 
other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274


___
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

Re: Automation of Fedora SCM requests


Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please report 
it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and it 
will ping correct people if the manual intervention is needed. This 
will not change anything in user workflow, it will just make the job 
of Fedora Release Engineering Team easier and let them focus on other 
things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274
___
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

Re: Automation of Fedora SCM requests


Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please 
report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make the 
job of Fedora Release Engineering Team easier and let them focus on 
other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274


___
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 Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

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

The SRPMS? I'm using "rpkg build "



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

I don't want to test the packages per say, I just need COPR to pull in the
rebuilt package instead of the one in Fedora, otherwise I get dnf conflicts:

 Problem: package usd-libs-22.05b-16.fc38.x86_64 requires
libOpenColorIO.so.2.1()(64bit), but none of the providers can be
installed
  - cannot install both OpenColorIO-2.1.2-5.fc38.1.x86_64 and
OpenColorIO-2.2.0-1.fc38.x86_64
  - package usd-devel-22.05b-16.fc38.x86_64 requires usd-libs(x86-64)
= 22.05b-16.fc38, but none of the providers can be installed
  - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires
libOpenColorIO.so.2.2()(64bit), but none of the providers can be
installed
  - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires
OpenColorIO(x86-64) = 2.2.0-1.fc38, but none of the providers can be
installed

- cannot install the best candidate for the job



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

Looks like the problem is using `rpkg` but that's the easiest method and
has worked great until now...

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 10, 2023 at 4:39 AM Miroslav Suchý  wrote:
>
> Dne 10. 01. 23 v 9:29 Vitaly Zaitsev via devel napsal(a):
> > On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:
> >> 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.
> >
> > Steps to reproduce:
> >
> > 1. Create a new COPR project.
> > 2. Add a new COPR package with building from SCM:
> >  - Type - Git
> >  - Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you can 
> > choose any other package with rpmautospec)
> >  - Commithash: rawhide
> >  - Spec File: protobuf-c.spec
> >  - How to build SRPM - rpkg (default choice)
> > 3. Press Save and Rebuild.
> > 4. Wait for the results. Check the final RPM. It will have Release: 1 and 
> > an empty %changelog.
> >
> rpmautospec should work with plain git - I will leave the defending for 
> others.
>
> But in your case you should rather use DistGit instead of SCM method (the 
> first row of tabs):
>
> https://docs.pagure.org/copr.copr/user_documentation.html#distgit
>
> And it should start working.
>

Admittedly, I have a weird case here, but I'm forking a Fedora package
and putting it outside of DistGit. It uses RPMAutoSpec and I'm trying
to build this in COPR, but because I can't use it through the DistGit
method, the NVR is broken.

Example:
* Git: https://pagure.io/fedora-asahi/asahi-fedora-remix-release
* Package: 
https://copr.fedorainfracloud.org/coprs/g/asahi/fedora-remix-branding/build/5207916/


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

[rpms/perl-HTTP-Daemon-SSL] PR #1: Fix for IO::Socket::SSL 2.078

2023-01-10 Thread Jitka Plesnikova


jplesnik merged a pull-request against the project: `perl-HTTP-Daemon-SSL` that 
you are following.

Merged pull-request:

``
Fix for IO::Socket::SSL 2.078
``

https://src.fedoraproject.org/rpms/perl-HTTP-Daemon-SSL/pull-request/1
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-10 Thread Vitaly Zaitsev via devel


On 10/01/2023 10:38, Miroslav Suchý wrote:
But in your case you should rather use DistGit instead of SCM method 
(the first row of tabs):

https://docs.pagure.org/copr.copr/user_documentation.html#distgit


Looks interesting. Thank you very much for the info. I will use it in 
the future.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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

[Bug 2157775] Please branch and build cpanspec in epel9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2023-c7fe4b2d6b has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c7fe4b2d6b


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157775
___
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: Automation of Fedora SCM requests

2023-01-10 Thread Jonathan Wright via devel

This is incredible, thank you all so much for the work!

On Tue, Jan 10, 2023, 5:26 AM Michal Konecny  wrote:

> Hi everyone,
>
> this automation is now in place and new SCM requests will be processed
> automatically. If you find any issue with the automation, please report it
> to toddlers issue tracker [0].
>
> On behalf of CPE Team,
> Michal
>
> [0] - https://pagure.io/fedora-infra/toddlers/issues
>
> On 08. 12. 22 11:10, Michal Konecny wrote:
>
> Hello everyone,
>
> for some time CPE (Community Platform Engineering) team is working on
> automating Fedora SCM requests [0]. The automation is currently live on
> staging. You can see the output (closed tickets) in Fedora SCM requests
> staging repo [1].
> The automation is done using a plugin in toddlers [2]. We have a
> documentation [3] for the new toddler, if you want to know more about it.
> There is also a ticket [4] tracking this work.
>
> We plan to deploy this in production on *10th January 2023*, after that
> all the Fedora SCM request will be processed automatically and it will ping
> correct people if the manual intervention is needed. This will not change
> anything in user workflow, it will just make the job of Fedora Release
> Engineering Team easier and let them focus on other things.
>
> On behalf of CPE Team,
> Michal
>
> [0] - https://pagure.io/releng/fedora-scm-requests
> [1] - https://stg.pagure.io/releng/fedora-scm-requests
> [2] - https://pagure.io/fedora-infra/toddlers
> [3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
> [4] - https://pagure.io/releng/issue/9274
>
>
> ___
> 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: Automation of Fedora SCM requests


Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please report 
it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and it 
will ping correct people if the manual intervention is needed. This 
will not change anything in user workflow, it will just make the job 
of Fedora Release Engineering Team easier and let them focus on other 
things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274
___
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 Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
 wrote:
>
> On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
> >
> > 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

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

2023-01-10 Thread David Abdurachmanov

On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
>
> 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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-10 Thread Florian Weimer

* Vitaly Zaitsev via devel:

> On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:
>> 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.
>
> Steps to reproduce:
>
> 1. Create a new COPR project.
> 2. Add a new COPR package with building from SCM:
>  - Type - Git
>  - Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you
>can choose any other package with rpmautospec)
>  - Commithash: rawhide
>  - Spec File: protobuf-c.spec
>  - How to build SRPM - rpkg (default choice)
> 3. Press Save and Rebuild.
> 4. Wait for the results. Check the final RPM. It will have Release: 1
> and an empty %changelog.

rpmautospec only works for type Build from DistGit, I think.

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

[EPEL-devel] Re: libmaxminddb removed from epel7

2023-01-10 Thread Sebastian Albrecht

Hi Dan,
thank you for answering. Is there a known reason, why it was removed for the 
x86_64 arch but not for aarch64? Because i can still find it there.

BR,
Sebastian.
___
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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-10 Thread Miroslav Suchý


Dne 10. 01. 23 v 9:29 Vitaly Zaitsev via devel napsal(a):

On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:

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.


Steps to reproduce:

1. Create a new COPR project.
2. Add a new COPR package with building from SCM:
 - Type - Git
 - Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you can choose 
any other package with rpmautospec)
 - Commithash: rawhide
 - Spec File: protobuf-c.spec
 - How to build SRPM - rpkg (default choice)
3. Press Save and Rebuild.
4. Wait for the results. Check the final RPM. It will have Release: 1 and an 
empty %changelog.


rpmautospec should work with plain git - I will leave the defending for others.

But in your case you should rather use DistGit instead of SCM method (the first 
row of tabs):

https://docs.pagure.org/copr.copr/user_documentation.html#distgit

And it should start working.

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

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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Email-Address-1.913-1.
   ||fc38
 Resolution|--- |ERRATA
Last Closed||2023-01-10 09:29:04



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-f271d263dc has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
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