Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Dan Čermák]

Hi,

just a minor suggestion:

On November 15, 2021 7:15:49 PM UTC, Ben Cotton  wrote:
>
>Overall arm32 is generally waning with generally few new ARMv7 devices
>added to Fedora in recent releases. 

Remove one of the two generally/general.

>== Contingency Plan ==
>
>Continue on as before with the added advantage of the people that
>protested the removal of the architecture will be actively
>contributing to the maintenance of the architecture
>
>* Contingency mechanism: Leave enabled. We basically won't get to this
>if FESCo doesn't approve the change.
>* Contingency deadline: Mass rebuild.
>* Blocks release? Yes
>* Blocks product? Yes

I am a bit confused, assuming this gets approved and implemented: is there a 
way back?


Cheers,

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

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Gary Buhrmaster]

On Mon, Nov 15, 2021 at 7:16 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/RetireARMv7
>

I cannot recall the last time I tried to run a full armv7 desktop
(which, I would guess, generate a significant percentage of
the large app build failures since the "desktop" apps are,
well, large), but I still have a number of small server
appliances and/or IoT environments where armv7 SoCs
(and Fedora) have been a good fit, and match the rest
of my development environment (which is Fedora).

I guess I will need to decide if building my own Fedora
(minimal) server/IoT environment will be better than
moving to (possibly) openSuse (the SoC's are fixed,
and cannot be easily replaced).

All good things must come to an end.  Thanks for
supporting fedora on armv7 for as long as you did.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2023554] New: perl-Test2-Suite-0.000142 is available

[bugzilla]

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

Bug ID: 2023554
   Summary: perl-Test2-Suite-0.000142 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test2-Suite
  Keywords: FutureFeature, Triaged
  Assignee: mspa...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.000142
Current version/release in rawhide: 0.000141-1.fc35
URL: http://search.cpan.org/dist/Test2-Suite/

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://fedoraproject.org/wiki/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/9536/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2023554
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2023516] New: perl-Date-Manip-6.86 is available

[bugzilla]

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

Bug ID: 2023516
   Summary: perl-Date-Manip-6.86 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Date-Manip
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: huzai...@redhat.com, jpazdzi...@redhat.com,
ka...@ucw.cz, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.86
Current version/release in rawhide: 6.85-3.fc35
URL: http://search.cpan.org/dist/Date-Manip/

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://fedoraproject.org/wiki/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/2785/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2023516
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2022400] Please branch and build an epel8 for perl-Config-Grammar

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2021-e94ada710f has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e94ada710f


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2022400
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 18:28, Aleksei Bavshin wrote:

On 11/15/21 08:45, Martin Stransky wrote:

On 11/15/21 17:38, Aleksei Bavshin wrote:

On 11/12/21 00:37, Martin Stransky wrote:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


Intel section fails to mention that accelerated video decoding on the 
Iris XE (Gen12) GPUs requires intel-media-driver and won't work with 
older libva-intel-driver. So we're out of luck until the sandboxing 
issue is resolved and the fix is backported to Fedora Firefox builds.


As usually, please update the page.
Thanks.


Hm. I just reread the whole section again.
Martin, did you mean to use intel-media-driver (iHD_drv_video.so) 
instead of the libva-intel-hybrid-driver (hybrid_drv_video.so)? Because 
everything makes sense with that substitution and the sandbox bug only 
mentions iHD_drv_video.so.


Frankly I use only libva-intel-driver (i965_drv_video.so) for Intel UHD 
620/630 which I have available and other info I have from upstream 
bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1619585).


Martin

--
Martin Stransky
Software Engineer / 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Reon Beon via devel]

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1291136-fedora-drafts-plans-for-retiring-armv7-support
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 release retrospective

[Ben Cotton]

Hi everyone,

Now that we've released F35, I'd like to share the first semi-annual
release retrospective survey:
https://fedoraproject.limequery.com/231354

I kept it intentionally short and open-ended. It should only take a
few moments of your time. If you have any questions, please let me
know. If you have suggestions for the next time around, there's a
field for that in the survey!

The survey is open through 4 December. I'll share results on the
Community Blog in late December or early January.

If you haven't seen, Adam is running a QA-specific retrospective as
well. If you only have QA feedback, you can record it on the wiki page
and I'll incorporate the responses into my final analysis.
 https://fedoraproject.org/wiki/Fedora_35_QA_Retrospective

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Keeping track of inconsistent backports

[Fabio Valentini]

On Mon, Nov 15, 2021 at 8:42 PM Major Hayden  wrote:
>
> Hey there,
>
> As much as I try not to, I sometimes forget to backport a package that I
> manage.
>
> For example, Google's Python SDK updates rather frequently and I usually
> bring those changes into rawhide fairly quickly. The SDK is made up of
> plenty of different packages that release at different times. Mondays
> are usually the day when I take all of the most recent updates, test
> them out together, and backport the updates to the most recent stable
> version.
>
> However, I sometimes miss one or two of these packages. It's usually not
> a big deal since I might process another update for that package within
> a week or two. I'd like to get better with this and somehow identify
> which package updates made it into rawhide without getting backported.
>
> Do we have any tools to help with this now? I was looking at potentially
> writing my own scripts to do this but it would involve a *lot* of calls
> to mdapi and that's probably not the most infrastructure-friendly
> option. My goal is to look across my packages and find the ones with a
> version mismatch from rawhide to stable.
>
> Thanks for reading this far and for any ideas you might have. 珞

I don't really have a solution here, but I'd be interested in looking
at this problem.

For example, most* [1] packages in the Rust stack will have (and
should! have) the same versions across all supported Fedora branches.
For any Rust packages that I push updates for, I update them right
away across all branches, and that works very well to prevent me from
forgetting things.
However, any "newcomers" (or contributors who are more easily
distracted than me) will often mess that up, making it hard for me
(main Rust stack maintainer right now) to keep things aligned when I
update other packages.

[1]: some package sets contain non-self-contained breaking changes,
for example the latest gtk-rs bindings are only available on Fedora
35+

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Schedule for Monday's FESCo Meeting (2021-11-15)

[Stephen Gallagher]

===
#fedora-meeting: FESCO (2021-11-15)
===


Meeting started by StephenGallagher at 19:00:10 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2021-11-15/fesco.2021-11-15-19.00.log.html
.



Meeting summary
---
* init process  (StephenGallagher, 19:00:10)
  * LINK: https://pagure.io/fesco/issue/2687   (StephenGallagher,
19:05:28)

* #2687 F36 Change: Package information on ELF objects
  (StephenGallagher, 19:06:32)
  * AGREED: APPROVED (+5, 1, -2) Permit the addition of package metadata
to the ELF objects in Fedora  (StephenGallagher, 19:12:09)

* #2688 Election Interview Questions — FESCo (F35)  (StephenGallagher,
  19:17:41)
  * AGREED: We replace the existing question about RHEL and Fedora
conflicts with "Fedora ELN brings RHEL engineering more closely into
Fedora. How do you feel we should balance RHEL engineering with the
community with ELN building from Fedora?" (+6, 0, 0)
(StephenGallagher, 19:33:59)
  * AGREED: Add "What are your thoughts on Fedora ELN and what are your
suggestions in improving it?" to the list of questions (+5, 1, -0)
(StephenGallagher, 19:48:58)

* #2695 Suggested new intro paragraph for Updates policy
  (StephenGallagher, 19:50:57)
  * LINK: https://sembr.org/   (zbyszek, 19:57:38)

* Open Floor  (StephenGallagher, 19:58:21)

* Next week's chair  (StephenGallagher, 19:58:40)
  * ACTION: zbyszek to chair the 2021-11-22 meeting  (StephenGallagher,
20:03:50)

* Open Floor (vol. 2)  (StephenGallagher, 20:04:03)

Meeting ended at 20:09:03 UTC.




Action Items

* zbyszek to chair the 2021-11-22 meeting




Action Items, by person
---
* zbyszek
  * zbyszek to chair the 2021-11-22 meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* StephenGallagher (104)
* zbyszek (34)
* Eighth_Doctor (31)
* zodbot (20)
* defolos (18)
* dcantrell (16)
* decathorpe (14)
* bcotton (13)
* nirik (12)
* dustymabe (11)
* mboddu (8)
* ZbigniewJdrzejew (2)
* sgallagh (0)
* mhroncok (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)




Generated by `MeetBot`_ 0.3

.. _`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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Julian Sikorski]

Am 12.11.21 um 09:37 schrieb Martin Stransky:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


For VP9 on AMD the following set-up seems to work:

media.ffmpeg.vaapi.enabled to true
media.ffvpx.enabled to false
media.rdd-ffvpx.enabled to false
media.rdd-vpx.enabled to false

H264 also seems to work. mp4/h265 from 
https://test-videos.co.uk/bigbuckbunny/mp4-h265 do not play at all.


Best regards,
Julian
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Keeping track of inconsistent backports

[Major Hayden]

Hey there,

As much as I try not to, I sometimes forget to backport a package that I 
manage.


For example, Google's Python SDK updates rather frequently and I usually 
bring those changes into rawhide fairly quickly. The SDK is made up of 
plenty of different packages that release at different times. Mondays 
are usually the day when I take all of the most recent updates, test 
them out together, and backport the updates to the most recent stable 
version.


However, I sometimes miss one or two of these packages. It's usually not 
a big deal since I might process another update for that package within 
a week or two. I'd like to get better with this and somehow identify 
which package updates made it into rawhide without getting backported.


Do we have any tools to help with this now? I was looking at potentially 
writing my own scripts to do this but it would involve a *lot* of calls 
to mdapi and that's probably not the most infrastructure-friendly 
option. My goal is to look across my packages and find the ones with a 
version mismatch from rawhide to stable.


Thanks for reading this far and for any ideas you might have. 珞

--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


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

Re: Update of rust-cfg-expr

[Rémi Lauzier via devel]

Thanks. Will push when i be on my computer.


Envoyé depuis ProtonMail mobile



\ Message d'origine 
Le 15 nov. 2021, 13 h 43, Fabio Valentini < decatho...@gmail.com > a écrit :

>
>
>
> On Mon, Nov 15, 2021 at 5:47 PM Rémi Lauzier via devel
>  wrote:
> >
> > Sorry for that. I don't have access to rust-system-deps so somebody else 
> > will have to do it.
>
> Builds of rust-system-deps with cfg-expr bumped from 0.8 to 0.9 have
> finished for all three side tags, so you can create the bodhi updates
> now.
>
> 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][https_fedoraproject.org_wiki_Mailing_list_guidelines]
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
>


[https_fedoraproject.org_wiki_Mailing_list_guidelines]: 
https://fedoraproject.org/wiki/Mailing_list_guidelines

publickey - EmailAddress(s=remilauzier@protonmail.com) - 0x0C8AA258.asc
Description: application/pgp-keys


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

Re: LTO objects after build: Rebuilding vs erroring out

[Jakub Jelinek]

On Mon, Nov 15, 2021 at 12:13:19PM -0700, Jeff Law wrote:
> > with somehting that errors out (fails the build) if any relocatable
> > object files (.o) or static archives (.a) by default, and stop producing
> > object code by default, only LTO representation.  If a special
> > redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is
> > configured to produce both object code and LTO representation (basically
> > what we have today).
> Right.  In fact, I had a brp-strip-lto which did precisely this and I did a
> Fedora build with that brp-strip-lto to get a set of packages that wanted to
> install a .o or .a composed from .o files. I did a build with that, but I
> don't have the results anymore.

What we perhaps could try (but not sure how far we could get) if we detect
in an installed *.a or *.o GCC LTO bytecode, instead of erroring out and
failing the build try to convert it to normal *.o file (for *.a recursively
for each *.o file in there with LTO bytecode) - at least if debug info
is emitted and there is DW_AT_producer, try to reconstruct gcc command line
and gcc -r that_perhaps_slightly_massaged_command_line -o new.o old.o

Or if we recorded all command line options we care about into LTO bytecode
(Optimization/Target options are recorded already on a per-function basis
but I'm worried about others), just have a gcc driver mode that turns
a non-fat LTO object into normal non-LTO object.

Jakub
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: RetireARMv7 (System-Wide Change proposal)

[Ben Cotton]

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

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: 

== Detailed Description ==

The ARMv7 arm architecture was the second variant of the arm
architecture that Fedora has supported, the first was ARMv5, the third
is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
release. This will allow ARMv7/armhfp to be supported until the Fedora
36 end of life in around June 2023.

Overall arm32 is generally waning with generally few new ARMv7 devices
added to Fedora in recent releases. To add to that a number of newer
Fedora features designed to improve speed and security of the Fedora
release are causing 32 bit architectures in general primarily due to
the process memory limit when linking large applications. The
ARMv7/armhfp is the last fully supported 32 bit architecture, we still
currently build i686 packages, but it's not shipped as artefacts.

== Benefit to Fedora ==

The primary benefit is to maintainers of the ARM architecture, the
various toolchain teams and package maintainers in general.

== Scope ==

* Proposal owners: Work with rel-eng to disable the architecture in
koji, remove all the various pungi pieces and clean up any other
release detritus.

* Other developers: No action required.

* Release engineering: [https://pagure.io/releng/issue/10387 Releng
issue #10387] Disable a bunch of stuff, it's really just one koji
admin command and a PR for pungi config changes

* Policies and guidelines: No initial updates to policies and
guidelines as ARMv7 won't completely disappear until F-36 EOL.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.

== How To Test ==
There's not really anything to test as it's removing the support for
an architecture.

== User Experience ==
Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.

== Dependencies ==
N/A.

== Contingency Plan ==

Continue on as before with the added advantage of the people that
protested the removal of the architecture will be actively
contributing to the maintenance of the architecture

* Contingency mechanism: Leave enabled. We basically won't get to this
if FESCo doesn't approve the change.
* Contingency deadline: Mass rebuild.
* Blocks release? Yes
* Blocks product? Yes

== Documentation ==

N/A

== Release Notes ==

Fedora Linux 37 with the ARMv7 architecture is retired into the
sunset. There will definitely be celebrations, there will likely be
some that shed some tears! Overall for the maintainers it will likely
be seen as a net win, for the few, generally shrinking, users it's
probably a net loss but they can probably just go and buy a Raspberry
Pi Zero 2W for US$15. ¯\_(ツ)_/¯


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

F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
The legacy wireless extensions interface was replaced by the new
mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions
support has been long deprecated and only supports long EOL WiFi
encryption like WEP so it's time to disable it and remove it.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]

== Detailed Description ==

The Wireless Extensions support in the kernel has been long replaced
by the mac80211/cfg80211 support. Disable the kernel options and
retire the wireless-tools userspace utilities. Wireless Extensions
only supports a minor subset of the wireless interfaces, predominently
the WEP interface and userspace has been replaced by iw/libnl/ip
interfaces which offer a lot more advanced features as well as modern
802.11 functionality like WPA.

== Benefit to Fedora ==

More secure and advanced features in wireless. In most cases most
users won't notice a difference. The vast majority of users use
NetworkManager to use 802.11 based wireless interfaces which has long
ceased to support wireless extensions/wireless-tools, if it evere did.

== Scope ==
* Proposal owners:
** Disable the wireless extensions interface in the kernel and any
drivers that depend on it. The only driver that is currently enabled
that requires wireless extension support is the Intel Pro Wireless
2100/2200 drivers, this hardware was released in 2003-2005 as part of
the original Centrino laptop platforms and all officially supported
devices were 32 bit so it's unlikely there's any current users but as
they were mPCI cards it's possible there's a few users that put them
into 64 bit machines.
** Retire the wireless-tools package, retirn any packages that depend
on it, or migrate them to use libnl3.

* Other developers:
** No impact

* Release engineering: [https://pagure.io/releng/issue/10386 #10386]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
A handful of packages still use the libiw interface and hence depend
on the wireless-tools package. Some projects look dead upstream, a
number have already been migrated in the last year or so. Where the
project is alive upstream tickets have been filed requesting
migration. The current remaining package list is:

* conky
* lxpanel
* reaver

== How To Test ==

* Check that the wireless extensions kernel options are disabled:
(CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WEXT_SPY CONFIG_WEXT_PRIV
CONFIG_CFG80211_WEXT CONFIG_CFG80211_WEXT_EXPORT)
* Check the wireless-tools package is no longer available

== User Experience ==

Generally users should notice little to no difference.

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

== Contingency Plan ==

* Contingency mechanism: Leave WEXT enabled in the kernel, leave
wireless-tools package in Fedora package repository.
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.

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

== Release Notes ==
N/A


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

F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
The legacy wireless extensions interface was replaced by the new
mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions
support has been long deprecated and only supports long EOL WiFi
encryption like WEP so it's time to disable it and remove it.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]

== Detailed Description ==

The Wireless Extensions support in the kernel has been long replaced
by the mac80211/cfg80211 support. Disable the kernel options and
retire the wireless-tools userspace utilities. Wireless Extensions
only supports a minor subset of the wireless interfaces, predominently
the WEP interface and userspace has been replaced by iw/libnl/ip
interfaces which offer a lot more advanced features as well as modern
802.11 functionality like WPA.

== Benefit to Fedora ==

More secure and advanced features in wireless. In most cases most
users won't notice a difference. The vast majority of users use
NetworkManager to use 802.11 based wireless interfaces which has long
ceased to support wireless extensions/wireless-tools, if it evere did.

== Scope ==
* Proposal owners:
** Disable the wireless extensions interface in the kernel and any
drivers that depend on it. The only driver that is currently enabled
that requires wireless extension support is the Intel Pro Wireless
2100/2200 drivers, this hardware was released in 2003-2005 as part of
the original Centrino laptop platforms and all officially supported
devices were 32 bit so it's unlikely there's any current users but as
they were mPCI cards it's possible there's a few users that put them
into 64 bit machines.
** Retire the wireless-tools package, retirn any packages that depend
on it, or migrate them to use libnl3.

* Other developers:
** No impact

* Release engineering: [https://pagure.io/releng/issue/10386 #10386]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
A handful of packages still use the libiw interface and hence depend
on the wireless-tools package. Some projects look dead upstream, a
number have already been migrated in the last year or so. Where the
project is alive upstream tickets have been filed requesting
migration. The current remaining package list is:

* conky
* lxpanel
* reaver

== How To Test ==

* Check that the wireless extensions kernel options are disabled:
(CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WEXT_SPY CONFIG_WEXT_PRIV
CONFIG_CFG80211_WEXT CONFIG_CFG80211_WEXT_EXPORT)
* Check the wireless-tools package is no longer available

== User Experience ==

Generally users should notice little to no difference.

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

== Contingency Plan ==

* Contingency mechanism: Leave WEXT enabled in the kernel, leave
wireless-tools package in Fedora package repository.
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.

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

== Release Notes ==
N/A


-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: RetireARMv7 (System-Wide Change proposal)

[Ben Cotton]

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

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: 

== Detailed Description ==

The ARMv7 arm architecture was the second variant of the arm
architecture that Fedora has supported, the first was ARMv5, the third
is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
release. This will allow ARMv7/armhfp to be supported until the Fedora
36 end of life in around June 2023.

Overall arm32 is generally waning with generally few new ARMv7 devices
added to Fedora in recent releases. To add to that a number of newer
Fedora features designed to improve speed and security of the Fedora
release are causing 32 bit architectures in general primarily due to
the process memory limit when linking large applications. The
ARMv7/armhfp is the last fully supported 32 bit architecture, we still
currently build i686 packages, but it's not shipped as artefacts.

== Benefit to Fedora ==

The primary benefit is to maintainers of the ARM architecture, the
various toolchain teams and package maintainers in general.

== Scope ==

* Proposal owners: Work with rel-eng to disable the architecture in
koji, remove all the various pungi pieces and clean up any other
release detritus.

* Other developers: No action required.

* Release engineering: [https://pagure.io/releng/issue/10387 Releng
issue #10387] Disable a bunch of stuff, it's really just one koji
admin command and a PR for pungi config changes

* Policies and guidelines: No initial updates to policies and
guidelines as ARMv7 won't completely disappear until F-36 EOL.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.

== How To Test ==
There's not really anything to test as it's removing the support for
an architecture.

== User Experience ==
Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.

== Dependencies ==
N/A.

== Contingency Plan ==

Continue on as before with the added advantage of the people that
protested the removal of the architecture will be actively
contributing to the maintenance of the architecture

* Contingency mechanism: Leave enabled. We basically won't get to this
if FESCo doesn't approve the change.
* Contingency deadline: Mass rebuild.
* Blocks release? Yes
* Blocks product? Yes

== Documentation ==

N/A

== Release Notes ==

Fedora Linux 37 with the ARMv7 architecture is retired into the
sunset. There will definitely be celebrations, there will likely be
some that shed some tears! Overall for the maintainers it will likely
be seen as a net win, for the few, generally shrinking, users it's
probably a net loss but they can probably just go and buy a Raspberry
Pi Zero 2W for US$15. ¯\_(ツ)_/¯


-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: LTO objects after build: Rebuilding vs erroring out

[Jeff Law]

On 11/15/2021 6:06 AM, Florian Weimer wrote:

In the future, we might want to switch GCC not to generate both object
code and LTO representation during the build process.  For most
packages, dual generation is not necessary because no relocatable object
files for static linking are included in the RPM (neither as separate
ET_REL .o files, nor in static .a archives).  Final (non-relocatable)
links of any kind will generate object code, so only LTO representation
needs to be written by GCC.

Yup.  It's something I wanted to do, but never had the time to complete.



But in case relocatable object files are produced by the package (e.g.,
for a -static subpackage for static linking), it is necessary to
generate object code for relocatable files as well.  The reason is that
only object code (not LTO representation) is a stable format, and it's
the only way to achieve cross-toolchain linking.

The way I envisioned LTO-only building for GCC was to replace
the brp-strip-lto script



with somehting that errors out (fails the build) if any relocatable
object files (.o) or static archives (.a) by default, and stop producing
object code by default, only LTO representation.  If a special
redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is
configured to produce both object code and LTO representation (basically
what we have today).
Right.  In fact, I had a brp-strip-lto which did precisely this and I 
did a Fedora build with that brp-strip-lto to get a set of packages that 
wanted to install a .o or .a composed from .o files. I did a build with 
that, but I don't have the results anymore.




However, Clang has chosen a different approach: Build object code in the
final stages, via the brp-llvm-compile-lto-elf script:



This does not really work for GCC in downstream because we have multiple
GCCs there, with incompatible LTO representation.  We also cannot
replicate the exact command line options that have been used during the
package-internal build process; we only have the default
redhat-rpm-config flags at this point, and whatever has been serialized
into the LTO representation.

Fedora has multiple LLVMs (e.g., rust in Fedora 35 is at LLVM 12, but
/usr/bin/clang is LLVM 13).  LLVM bitcode is supposed to be more
compatible:

   

But don't know to what extent we test that.

I'd prefer to use a single mechanism for both toolchains.  But it seems
that Clang does not support creating ELF object files that contain LLVM
IR (GCC's default mode we use today).  Given the problems with
post-building object code for GCC, I'm not sure if this is feasible.

Thoughts?
It'd be nice to have the same approach, but it may not be ultimately 
feasible.


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

Re: Update of rust-cfg-expr

[Fabio Valentini]

On Mon, Nov 15, 2021 at 5:47 PM Rémi Lauzier via devel
 wrote:
>
> Sorry for that. I don't have access to rust-system-deps so somebody else will 
> have to do it.

Builds of rust-system-deps with cfg-expr bumped from 0.8 to 0.9 have
finished for all three side tags, so you can create the bodhi updates
now.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[PGNet Dev]

Video decoding on NVIDIA
Please buy some real Linux hardware.


This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?


After trying to configure HW acceleration on 9xx series GPU, I'll just take 
that as a serious response.
Consider following points:
  * VDPAU is not compatible with Wayland, our main desktop scenario.
  * Video decoding in Firefox on X11 is limited to X11/EGL, which does not work 
with the Nvidia proprietary driver (but at least there's a hope for that 
scenario).
  * There's no NVDEC vaapi backend, and I see opinions that it would be hard to 
fit NVDEC into vaapi model.
  * Nouveau support ends at VP5 (7xx series).

The wording might be different, but _at the moment_ any recent Nvidia hardware 
cannot be used for HW video acceleration in Firefox.



currently,for proprietary nvidia hw accel

useful docs

https://wiki.archlinux.org/title/Hardware_video_acceleration

e.g.

on

lsb_release -rd
Description:Fedora release 35 (Thirty Five)
Release:35

with nvidia hw,

hwinfo --gfxcard | egrep " Model| Device| Driver:"
Model: "nVidia GP108 [GeForce GT 1030]"
Device: pci 0x1d01 "GP108 [GeForce GT 1030]"
Driver: "nvidia"

latest upstream driver,

nvidia-settings -q NvidiaDriverVersion

Attribute 'NvidiaDriverVersion' (test.loc:0.0): 495.44
Attribute 'NvidiaDriverVersion' (test.loc:0[gpu:0]): 495.44

lsmod | grep nv
nvidia_uvm   1167360  0
nvidia_drm 73728  8
nvidia_modeset   1150976  20 nvidia_drm
nvidia  36950016  1354 nvidia_uvm,nvidia_modeset
drm_kms_helper303104  1 nvidia_drm
drm   630784  14 
drm_kms_helper,nvidia,drm_ttm_helper,nvidia_drm,ttm


currently, this set of relevant pkgs

rpm -qa | egrep 
"libva|nvidia|vdpau|dkms|kernel-devel|glx|^egl|glvnd|libvpx|vulkan"
dkms-2.8.6-1.fc35.noarch
egl-utils-8.4.0-12.20210504git0f9e7d9.fc35.x86_64
glx-utils-8.4.0-12.20210504git0f9e7d9.fc35.x86_64
kernel-devel-5.14.17-301.fc35.x86_64
libglvnd-1.3.4-2.fc35.x86_64
libglvnd-core-devel-1.3.4-2.fc35.x86_64
libglvnd-devel-1.3.4-2.fc35.x86_64
libglvnd-egl-1.3.4-2.fc35.x86_64
libglvnd-gles-1.3.4-2.fc35.x86_64
libglvnd-glx-1.3.4-2.fc35.x86_64
libglvnd-opengl-1.3.4-2.fc35.x86_64
libva-2.13.0-2.fc35.x86_64
libva-utils-2.13.0-1.fc35.x86_64
libva-vdpau-driver-0.7.4-110.fc35.x86_64
libvdpau-1.4-6.fc35.x86_64
libvdpau-devel-1.4-6.fc35.x86_64
libvdpau-trace-1.4-6.fc35.x86_64
libvdpau-va-gl-0.4.2-20.fc35.x86_64
libvpx-1.10.0-2.fc35.x86_64
mesa-vdpau-drivers-21.2.5-1.fc35.x86_64
mesa-vulkan-drivers-21.2.5-1.fc35.x86_64
vdpauinfo-1.4-1.fc35.x86_64
vulkan-headers-1.2.189.0-1.fc35.noarch
vulkan-loader-1.2.189.0-1.fc35.x86_64
vulkan-loader-devel-1.2.189.0-1.fc35.x86_64
vulkan-tools-1.2.189.0-1.fc35.x86_64

checking for X11

grep -iE 'vdpau | dri driver' /var/log/Xorg.0.log
[37.637] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia

verifying

ldd `which mpv` | egrep -i "egl|nvidia|vdpau"
libEGL.so.1 => /lib64/libEGL.so.1 (0x7fadfdbb4000)
libwayland-egl.so.1 => /lib64/libwayland-egl.so.1 
(0x7fadfbdbe000)
libvdpau.so.1 => /lib64/libvdpau.so.1 (0x7fadfacea000)

VDPAU_DRIVER=nvidia mpv --hwdec=auto TEST.mp4
 (+) Video --vid=1 (*) (h264 1920x1080 30.015fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)

Using hardware decoding (nvdec).

AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 cuda[nv12]
AV: 00:00:02 / 00:00:39 (7%) A-V:  0.026 ct:  0.256

for FF

rpm -qa firefox
firefox-94.0-1.fc35.x86_64

read


https://www.phoronix.com/scan.php?page=news_item=Firefox-94-EGL-Linux-Usage

https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/

note

"In X.org, since 94, Firefox will run in EGL mode by default which is 
sufficient [19]."

user.js settings currently include,

user_pref("media.ffmpeg.enabled", true);
user_pref("media.ffmpeg.vaapi.enabled", true);
user_pref("media.ffmpeg.vaapi-drm-display.enabled", true);
user_pref("media.ffvpx.enabled", false);
user_pref("media.navigator.mediadatadecoder_vpx_enabled", true);
  

Re: Firefox Hardware acceleration & VA-API how-to

[Aleksei Bavshin]

On 11/15/21 08:45, Martin Stransky wrote:

On 11/15/21 17:38, Aleksei Bavshin wrote:

On 11/12/21 00:37, Martin Stransky wrote:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


Intel section fails to mention that accelerated video decoding on the 
Iris XE (Gen12) GPUs requires intel-media-driver and won't work with 
older libva-intel-driver. So we're out of luck until the sandboxing 
issue is resolved and the fix is backported to Fedora Firefox builds.


As usually, please update the page.
Thanks.


Hm. I just reread the whole section again.
Martin, did you mean to use intel-media-driver (iHD_drv_video.so) 
instead of the libva-intel-hybrid-driver (hybrid_drv_video.so)? Because 
everything makes sense with that substitution and the sandbox bug only 
mentions iHD_drv_video.so.


To be honest, I have no idea what GPUs even use 
libva-intel-hybrid-driver alone. libva-intel-driver claims to support 
everything up to Gen 10 GPUs and Gen11+ (Ice Lake, Tiger Lake, etc..) is 
handled by the intel-media-driver. And hybrid-driver's only purpose 
seems to be a VP9 decoding backend for the libva-intel-driver 
(--enable-hybrid-codec).

Can someone confirm that?

--
Best regards,
Aleksei Bavshin
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Nicolas Chauvet]

Le lun. 15 nov. 2021 à 17:25, Aleksei Bavshin
 a écrit :
>
...
> After trying to configure HW acceleration on 9xx series GPU, I'll just
> take that as a serious response.
> Consider following points:
>   * VDPAU is not compatible with Wayland, our main desktop scenario.
True.
Still I have raised the concern at
https://gitlab.freedesktop.org/vdpau/libvdpau/-/issues/2

>   * Video decoding in Firefox on X11 is limited to X11/EGL, which does
> not work with the Nvidia proprietary driver (but at least there's a hope
> for that scenario).
>   * There's no NVDEC vaapi backend, and I see opinions that it would be
> hard to fit NVDEC into vaapi model.
Well, technically it's NVDEC support for aarch64 tegra SOC, but it's
different than desktop NVDEC (using nouveau)
https://github.com/cyndis/vaapi-tegra-driver
See also https://bugzilla.redhat.com/show_bug.cgi?id=2023429

Anyway, a more relevant goal is Vulkan Video API.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: LTO objects after build: Rebuilding vs erroring out

[Florian Weimer]

* Tom Stellard:

> On 11/15/21 05:06, Florian Weimer wrote:
>> In the future, we might want to switch GCC not to generate both object
>> code and LTO representation during the build process.  For most
>> packages, dual generation is not necessary because no relocatable object
>> files for static linking are included in the RPM (neither as separate
>> ET_REL .o files, nor in static .a archives).  Final (non-relocatable)
>> links of any kind will generate object code, so only LTO representation
>> needs to be written by GCC.
>> But in case relocatable object files are produced by the package
>> (e.g.,
>> for a -static subpackage for static linking), it is necessary to
>> generate object code for relocatable files as well.  The reason is that
>> only object code (not LTO representation) is a stable format, and it's
>> the only way to achieve cross-toolchain linking.
>> The way I envisioned LTO-only building for GCC was to replace
>> the brp-strip-lto script
>> 
>> with somehting that errors out (fails the build) if any relocatable
>> object files (.o) or static archives (.a) by default, and stop producing
>> object code by default, only LTO representation.  If a special
>> redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is
>> configured to produce both object code and LTO representation (basically
>> what we have today).
>> 
>
> If we produced LTO only static archives, does this mean end-users who
> want to use them would need to build their applications with LTO enabled?

No, when building for LTO-only mode, it would be a hard error (build
failure) if an RPM is built that contains .o or .a files.  So the
situation that an end users sees LTO only static archives after
installing a -devel RPM package cannot actually happen.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Update of rust-cfg-expr

[Rémi Lauzier via devel]

Sorry for that. I don't have access to rust-system-deps so somebody else will 
have to do it.

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

Le lundi 15 novembre 2021 à 06:42, Fabio Valentini  a 
écrit:

> On Mon, Nov 15, 2021 at 7:09 AM Rémi Lauzier via devel
> 

> devel@lists.fedoraproject.org wrote:
> 

> > I everyone! I am updating rust-cfg-expr to version 0.9.0. I will push the 
> > side-tag in two weeks unless there is an objection. The only dependant 
> > package is rust-system-deps.
> > 

> > f36-build-side-47814
> > 

> > f35-build-side-47816
> > 

> > f34-build-side-47818
> 

> Thanks for the heads-up!
> 

> However, it would be good to know if you'll be patching and building
> 

> system-deps for those side tags yourself or if somebody else needs to
> 

> do that.
> 

> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure

publickey - remilauzier@protonmail.com - 0x0C8AA258.asc
Description: application/pgp-keys


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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 17:38, Aleksei Bavshin wrote:

On 11/12/21 00:37, Martin Stransky wrote:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


Intel section fails to mention that accelerated video decoding on the 
Iris XE (Gen12) GPUs requires intel-media-driver and won't work with 
older libva-intel-driver. So we're out of luck until the sandboxing 
issue is resolved and the fix is backported to Fedora Firefox builds.


As usually, please update the page.
Thanks.

--
Martin Stransky
Software Engineer / 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Aleksei Bavshin]

On 11/12/21 00:37, Martin Stransky wrote:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


Intel section fails to mention that accelerated video decoding on the 
Iris XE (Gen12) GPUs requires intel-media-driver and won't work with 
older libva-intel-driver. So we're out of luck until the sandboxing 
issue is resolved and the fix is backported to Fedora Firefox builds.


--
Best regards,
Aleksei Bavshin
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: LTO objects after build: Rebuilding vs erroring out

[Tom Stellard]

On 11/15/21 05:06, Florian Weimer wrote:

In the future, we might want to switch GCC not to generate both object
code and LTO representation during the build process.  For most
packages, dual generation is not necessary because no relocatable object
files for static linking are included in the RPM (neither as separate
ET_REL .o files, nor in static .a archives).  Final (non-relocatable)
links of any kind will generate object code, so only LTO representation
needs to be written by GCC.

But in case relocatable object files are produced by the package (e.g.,
for a -static subpackage for static linking), it is necessary to
generate object code for relocatable files as well.  The reason is that
only object code (not LTO representation) is a stable format, and it's
the only way to achieve cross-toolchain linking.

The way I envisioned LTO-only building for GCC was to replace
the brp-strip-lto script



with somehting that errors out (fails the build) if any relocatable
object files (.o) or static archives (.a) by default, and stop producing
object code by default, only LTO representation.  If a special
redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is
configured to produce both object code and LTO representation (basically
what we have today).



If we produced LTO only static archives, does this mean end-users who
want to use them would need to build their applications with LTO enabled?

-Tom


However, Clang has chosen a different approach: Build object code in the
final stages, via the brp-llvm-compile-lto-elf script:



This does not really work for GCC in downstream because we have multiple
GCCs there, with incompatible LTO representation.  We also cannot
replicate the exact command line options that have been used during the
package-internal build process; we only have the default
redhat-rpm-config flags at this point, and whatever has been serialized
into the LTO representation.

Fedora has multiple LLVMs (e.g., rust in Fedora 35 is at LLVM 12, but
/usr/bin/clang is LLVM 13).  LLVM bitcode is supposed to be more
compatible:

   

But don't know to what extent we test that.

I'd prefer to use a single mechanism for both toolchains.  But it seems
that Clang does not support creating ELF object files that contain LLVM
IR (GCC's default mode we use today).  Given the problems with
post-building object code for GCC, I'm not sure if this is feasible.

Thoughts?

Thanks,
Florian

PS: I tried to avoid fat/thin references because the terms are
inconsistent across the toolchains.


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Aleksei Bavshin]

On 11/15/21 04:34, Fabio Valentini wrote:

On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky  wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


I appreciate the effort to document ways to improve things. However:


Video decoding on NVIDIA
Please buy some real Linux hardware.


This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?


After trying to configure HW acceleration on 9xx series GPU, I'll just 
take that as a serious response.

Consider following points:
 * VDPAU is not compatible with Wayland, our main desktop scenario.
 * Video decoding in Firefox on X11 is limited to X11/EGL, which does 
not work with the Nvidia proprietary driver (but at least there's a hope 
for that scenario).
 * There's no NVDEC vaapi backend, and I see opinions that it would be 
hard to fit NVDEC into vaapi model.

 * Nouveau support ends at VP5 (7xx series).

The wording might be different, but _at the moment_ any recent Nvidia 
hardware cannot be used for HW video acceleration in Firefox.


--
Best regards,
Aleksei Bavshin
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Steve Grubb]

Hello,

On Monday, November 15, 2021 11:02:08 AM EST Nicolas Chauvet wrote:
> Le lun. 15 nov. 2021 à 16:06, Steve Grubb  a écrit :
> ...
> 
> > I use the negativio repository only because I need the whole cuda stack
> > including cudnn.
> 
> Totally undeeded, you can get rpmfusion+nvidia-cuda repository
> directly and avoid incompatible repository.
> https://rpmfusion.org/Howto/CUDA

I used to do that. But the problem is that one day out of the blue, you do a 
system update, get new video drivers, and now it's incompatible with the cuda 
layer. Then you find out that nvidia doesn't package things right. They 
include the version number in the name. This means you have to remove 
everything, download new packages, and reinstall. 

It's much simpler to use a repository that keeps everything in sync so that 
your projects don't unexpectedly refuse to run.

-Steve

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Nicolas Chauvet]

Le lun. 15 nov. 2021 à 16:06, Steve Grubb  a écrit :
...
> I use the negativio repository only because I need the whole cuda stack
> including cudnn.
Totally undeeded, you can get rpmfusion+nvidia-cuda repository
directly and avoid incompatible repository.
https://rpmfusion.org/Howto/CUDA
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Luca Boccassi]

> On Mon, Nov 15, 2021 at 10:33 AM Luca Boccassi  
> Please mention RPMCoW directly.

Mentioned and also linked the mailing list post you linked above as a 
reference, let me know if there's other changes I can do.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Neal Gompa]

On Mon, Nov 15, 2021 at 10:33 AM Luca Boccassi  wrote:
>
> > On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi  > wrote:
> >
> > Huh, I guess it was. :/
>
> Does that paragraph address your concerns? If so, I can update it to mention 
> RPMCoW directly, for future reference.

Please mention RPMCoW directly.



-- 
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Luca Boccassi]

> On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi  
> Huh, I guess it was. :/

Does that paragraph address your concerns? If so, I can update it to mention 
RPMCoW directly, for future reference.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 16:06, Steve Grubb wrote:

On Monday, November 15, 2021 8:23:59 AM EST Dominik 'Rathann' Mierzejewski
wrote:

Well, nVidia refuses to support VA-API like Intel and AMD do and the
VA-API-to-VDPAU won't help because dmabuf support is still required.
So... tough luck:


I can confirm that nvidia acceleration works fine on Fedora:

# vainfo
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.13 (libva 2.13.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API -
0.7.4



# vdpauinfo
display: :1   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  495.44  Fri Oct 22
06:03:50 UTC 2021



I use the negativio repository only because I need the whole cuda stack
including cudnn.


Please update the 
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Video_decoding_on_NVIDIA 
page. I don't have supported NVIDIA hardware so I can't test that.


Thanks.

--
Martin Stransky
Software Engineer / 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unexpected /patches VERIFY result from rpminspect

[David Cantrell]

On Thu, Nov 04, 2021 at 06:51:23PM +0100, Florian Weimer wrote:

* Aleksei Bavshin:


On 11/4/21 09:17, Florian Weimer wrote:

Why is this VERIFY?  The patch was generated as if by “git show”, and I
do not see anything wrong with it.


rpminspect thinks that the patch is suspiciously large and asks you to
confirm that it is intentional.

There's a test description in the beginning of the log:

Inspects all patches defined in the spec file and reports changes
between builds.  At the INFO level, rpminspect reports diffstat(1) and
patch size changes.  If thresholds are reached regarding a change in
the patch size or the number of files the patch touches, rpminspect
reports the change at the VERIFY level unless the comparison is for a
rebase. The configuration file can also list patch names that
rpminspect should ignore during the inspection.


Is this a new check?  It was flagged as a regression in Jenkins.


I should also point out that rpminspect is configurable with regard to
what it considers a "large" patch.  The intent of the inspection is to
provide a guard for packages in maintenance mode.  For example, if a
maintainer wants to stay on a particular version even though a newer
release is available and then someone submits a PR that patches the
source and the patch is effectively the new version, something like
this patches inspection could provide the maintainer with a warning
that this is a large patch and that _may_ be something that needs
closer inspection.

It is entirely subjective and some maintainers don't really care for
it.  I think in the case of maintenance builds, it can be helpful to
catch large patches that may introduce an unwanted change and provide
another guard for the maintainer to doublecheck the work.

If rpminspect is comparing builds and determines the comparison to be
a rebase (that is, the version numbers are different), it will report
all findings in the patches inspection at the INFO level.  But if it
determines the builds compared are the same version but the release
numbers differ (that is, a maintenance update), it will report
findings in the patches inspection at the VERIFY level.

You can control the patches inspection with an rpminspect.yaml file in
your dist-git directory.  First, you can exclude specific patches from
the inspection.  You can also set the file_count_threshold (default is
20) which is the number of files a single patch modifies and you can
also set the line_count_threshold (default 5000) which is the number
of lines a single patch modifies.

Not all packages are the same, so these settings are configurable on a
per-package basis so the rpminspect results are more useful to package
maintainers.  See this section in the upstream project for
documentation on what the patches section in rpminspect.yaml can look
like:

https://github.com/rpminspect/rpminspect/blob/master/data/generic.yaml#L646

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Neal Gompa]

On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi  wrote:
>
> > On Mon, Nov 8, 2021 at 2:06 PM David Cantrell  > wrote:
> >
> > Last cycle, I brought up the problem that it being part of the ELF
> > data destroys a lot of the value of the RPMCoW change[1] that is also
> > in development for this release. I'm disappointed that the Change
> > authors didn't care to resolve that issue for this iteration.
> >
> > [1]:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> Unless I'm mistaken, this is addressed indirectly by this paragraph, no?
>
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Concerns_about_additional_changes_to_files
>
> > ELF files in Fedora already vary between different package versions. The 
> > official version of the package is embedded in the .gnu_debuglink section. 
> > And since that varies between rebuilds, .note.gnu.build-id link which is 
> > calculated over all sections also varies. Thus every file has two sections 
> > that vary, and we're adding a third.
>
> So package content is already changing if any part of the source package 
> changes, if I understand correctly.

Huh, I guess it was. :/



-- 
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Luca Boccassi]

> On Mon, Nov 8, 2021 at 2:06 PM David Cantrell  wrote:
> 
> Last cycle, I brought up the problem that it being part of the ELF
> data destroys a lot of the value of the RPMCoW change[1] that is also
> in development for this release. I'm disappointed that the Change
> authors didn't care to resolve that issue for this iteration.
> 
> [1]:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...

Unless I'm mistaken, this is addressed indirectly by this paragraph, no?

https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Concerns_about_additional_changes_to_files

> ELF files in Fedora already vary between different package versions. The 
> official version of the package is embedded in the .gnu_debuglink section. 
> And since that varies between rebuilds, .note.gnu.build-id link which is 
> calculated over all sections also varies. Thus every file has two sections 
> that vary, and we're adding a third.

So package content is already changing if any part of the source package 
changes, if I understand correctly.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Steve Grubb]

On Monday, November 15, 2021 8:23:59 AM EST Dominik 'Rathann' Mierzejewski 
wrote:
> Well, nVidia refuses to support VA-API like Intel and AMD do and the
> VA-API-to-VDPAU won't help because dmabuf support is still required.
> So... tough luck:

I can confirm that nvidia acceleration works fine on Fedora:

# vainfo 
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.13 (libva 2.13.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 
0.7.4



# vdpauinfo
display: :1   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  495.44  Fri Oct 22 
06:03:50 UTC 2021



I use the negativio repository only because I need the whole cuda stack 
including cudnn.

Cheers,
-Steve

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Neal Gompa]

On Mon, Nov 8, 2021 at 2:06 PM David Cantrell  wrote:
>
> On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
> >On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote:
> >
> >> Thanks for revising the change proposal and filling in more details.
> >> After reading through it, I have some questions:
> >>
> >> 1) The proposal notes that users tend to combine built packages from
> >> different distributions.  Even in the current environment, do we care
> >> about those use cases without also getting a reproducer for Fedora?
> >
> >I'd see it this way: ultimately, if this gets adopted by multiple
> >distros this annotation will helps us separating out the reports by
> >distro, and then ignore everything but fedora. i.e. if someone deploys
> >a debian or ubuntu container on a fedora host this should be something
> >we shouldn't be bothered with supporting. But right now a coredump
> >generated that way won't tell us much about the situation. But once
> >this spec is adopted this becomes easy: if we get a report we'll
> >immediately see that the code that aborted was actually from a
> >different distro, and we can point the reporter to that and tell them
> >politely to ask the other distro for help, or alternatively invest the
> >time and reproduce the issue with the binary provided by fedora
> >instead.
> >
> >So, having this info around us allows us to be more efficient with
> >"not caring" for non-fedora issues.
> >
> >> For me, I feel that in a situation like that where a user has
> >> submitted a bug report that implies using a binary from some other
> >> distribution will lead me to ask "ok, but does this happen with the
> >> packages provided in Fedora?  If so, how can I reproduce the problem
> >> locally?"  So while these scenarios are described in the proposal, are
> >> they something that Fedora is trying to support?
> >
> >Well, I don't think Fedora has to care about crashes in other distro's
> >binaries. we have more than enough to look after anyway. But I do think
> >we should make it easier to detect this situation and more easily
> >provide helpful pointers how to find someone else who might be
> >interested or what to do to make fedora interested.
> >
> >> 3) The proposal notes making crash reporting more user-readable.  NVRs
> >> instead of Build-IDs, for instance.  Why can't systemd ask debuginfod
> >> for that information for reporting?  Why does this need to be embedded
> >> in the ELF objects?  If it's a value-add, then it could happen if
> >> debuginfod is set up and just have it fall back on the current
> >> reporting mechanism.
> >
> >We want to be able to do things generically in an offline fashion in
> >systemd-coredump. I.e. we run the coredump analyzer in a tight
> >sandbox, and we want quick answers without relying on the network.
> >
> >The goal of systemd-coredump is to make a coredump something that is
> >primarily a relatively cheapish log event, and were we do analysis as
> >much as possible locally, automatically, securely, in privacy and
> >quickly. If we'd always talk to the network we'd have to open our
> >sandbox quite a bit, we'd be dependent on external services, we'd leak
> >some data to the outside, we'd be unreliable and slower — and all that
> >even though we are interested in only a single string of data
> >ultimately.
> >
> >(I think debuginfod is excellent, but I think it would probably be a
> >consumer of this spec, not a replacement. for example, consider that
> >the spec has a suggested field 'debugInfoUrl' already, which would
> >inform debugging tools about the debuginfod servers to talk to to
> >acquire extended debug info data)
>
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system.  And that
> strikes me as pretty invasive, so is it worth the tradeoffs and risks
> and such?
>
> Debugging is a pain, and anything to make that easier is better.  It
> has been stated multiple times that the information needs to be in the
> ELF header because containers and images may lack an RPM database.
> Fair, but what about the users that both want a container and image
> without the RPM database and systemd-coredump?  They still have all of
> their ELF files with this information that they removed in other ways.
> Do we provide those users with a script to strip .gnu.notes from
> everything or is that even a use case of concern?
>
> Efforts to get the system very small for container and image use has
> been a goal for a while.  And sure we're not talking about a lot of
> data, but that's now.  The size of everything only grows, so is that
> something to consider with the implementation of this feature?
>
> Another thing I thought about were reproducible builds.  Does this
> impact reproducible builds and if so, how do we handle that?
>
> I would feel more comfortable with this proposal if the data for
> 

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 13:34, Fabio Valentini wrote:

On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky  wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


I appreciate the effort to document ways to improve things. However:


Video decoding on NVIDIA
Please buy some real Linux hardware.


This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?

I mean, even if I *could* throw a couple hundred bucks out the window
to replace a perfectly working NVidia hardware, most places don't even
seem to have AMD graphics cards in stock right now. Does that just
mean "tough luck" for users like me?


Please read it as "I'm too stupid for such task". I don't know how to 
setup/run VA-API on NVIDIA.


--
Martin Stransky
Software Engineer / 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Monday's FESCo Meeting (2021-11-15)

[Stephen Gallagher]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19: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 '2021-11-15 19: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 =

F36 Change: Retire the NIS(+) user-space utility programs
https://pagure.io/fesco/issue/2685
APPROVED (+5,0,-0)

F36 Change: Replace the fbdev drivers with simpledrm and the DRM fbdev
emulation layer
https://pagure.io/fesco/issue/2689
APPROVED (+6,0,-0)

F36 Change: Rubygem Cucumber 7.1.0
https://pagure.io/fesco/issue/2690
APPROVED (+7,0,-0)

F36 Change: Stratis 3.0.0
https://pagure.io/fesco/issue/2691
APPROVED (+5,0,-0)


= Followups =

#2687 F36 Change: Package information on ELF objects
https://pagure.io/fesco/issue/2687

= New business =

Nothing this week

= 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20211115.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 5/206 (x86_64), 7/141 (aarch64)

New failures (same test not failed in Fedora-Rawhide-2024.n.0):

ID: 1064902 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1064902
ID: 1064951 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1064951
ID: 1065012 Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1065012
ID: 1065021 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1065021
ID: 1065037 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1065037
ID: 1065187 Test: aarch64 universal install_blivet_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/1065187

Old failures (same test failed in Fedora-Rawhide-2024.n.0):

ID: 1064921 Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1064921
ID: 1064932 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1064932
ID: 1064940 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1064940
ID: 1065007 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1065007
ID: 1065015 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1065015
ID: 1065047 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1065047

Soft failed openQA tests: 4/206 (x86_64), 3/141 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Rawhide-2024.n.0):

ID: 1064920 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1064920
ID: 1064950 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1064950
ID: 1064958 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1064958
ID: 1065033 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1065033
ID: 1065053 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1065053
ID: 1065097 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1065097
ID: 1065165 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1065165

Passed openQA tests: 131/141 (aarch64), 197/206 (x86_64)

New passes (same test not passed in Fedora-Rawhide-2024.n.0):

ID: 1064978 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1064978
ID: 1064998 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/1064998
ID: 1065004 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1065004
ID: 1065020 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/1065020
ID: 1065041 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1065041
ID: 1065145 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1065145

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 0.16 to 0.30
Previous test data: https://openqa.fedoraproject.org/tests/1064411#downloads
Current test data: https://openqa.fedoraproject.org/tests/1064839#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
System load changed from 0.23 to 0.08
Previous test data: https://openqa.fedoraproject.org/tests/1064466#downloads
Current test data: https://openqa.fedoraproject.org/tests/1064894#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 9 MiB to 13 MiB
System load changed from 0.75 to 1.06
Previous test data: https://openqa.fedoraproject.org/tests/1064472#downloads
Current test data: https://openqa.fedoraproject.org/tests/1064900#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 9 MiB to 11 MiB
System load changed from 1.29 to 1.08
Previous test data: https://openqa.fedoraproject.org/tests/1064473#downloads
Current test data: https://openqa.fedoraproject.org/tests/1064901#downloads

Installed system changes in test x86_64 KDE-live-iso 

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 15:25, Peter Robinson wrote:

On Mon, Nov 15, 2021 at 2:20 PM Martin Stransky  wrote:


On 11/12/21 17:07, Scott Talbert wrote:

On Fri, 12 Nov 2021, Martin Stransky wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration


Along these lines, I am experiencing a pretty big regression in video
performance with recent Firefox versions on Fedora.  It probably started
with FF 93, but got a little better with FF 94.  It is really noticeable
when using Google Meet.  I'm using Wayland on AMD GPU hardware.  Is this
at all related to this HW acceleration stuff?


Please file a bug at https://bugzilla.redhat.com/ for further
investigation and cc me there. I can name ten reasons why you see it.


It sounds quite a lot like this bug filed by mattdm:
https://bugzilla.redhat.com/show_bug.cgi?id=2016162


Please file your own, I can dupe that later.
Thanks.

--
Martin Stransky
Software Engineer / 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Peter Robinson]

On Mon, Nov 15, 2021 at 2:20 PM Martin Stransky  wrote:
>
> On 11/12/21 17:07, Scott Talbert wrote:
> > On Fri, 12 Nov 2021, Martin Stransky wrote:
> >
> >> Hi folks,
> >>
> >> I was told that people were having trouble with Firefox/HW
> >> acceleration/VA-API setup on Fedora so I put some info at wiki at:
> >>
> >> https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
> >
> > Along these lines, I am experiencing a pretty big regression in video
> > performance with recent Firefox versions on Fedora.  It probably started
> > with FF 93, but got a little better with FF 94.  It is really noticeable
> > when using Google Meet.  I'm using Wayland on AMD GPU hardware.  Is this
> > at all related to this HW acceleration stuff?
>
> Please file a bug at https://bugzilla.redhat.com/ for further
> investigation and cc me there. I can name ten reasons why you see it.

It sounds quite a lot like this bug filed by mattdm:
https://bugzilla.redhat.com/show_bug.cgi?id=2016162
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

HEADS UP: OpenSceneGraph 3.6.5 and osgearth 3.2 landing in rawhide + review request python-sphinx-markdown-tables

[Sandro Mani]

Hi

I'll be updating to OpenSceneGraph 3.6.5 and osgearth 3.2 in rawhide in 
the f36-build-side-47862 side tag, and I'll also rebuild the following 
packages:


fgrun-2016.3.1-45.fc36.src.rpm
FlightGear-2020.3.11-1.fc36.src.rpm
scribus-1.5.7-6.fc36.src.rpm
SimGear-2020.3.11-1.fc36.src.rpm
speed-dreams-2.2.3-1.fc36.src.rpm

I've already performed all the builds in this [1] copr repo.

To update osgearth, I'd appreciate a review of 
python-sphinx-markdown-tables, required for building the osgearth 
documentation. The review is here


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

Happy to review in exchange.

Thanks
Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/osg-3.6.5/builds/
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/12/21 17:07, Scott Talbert wrote:

On Fri, 12 Nov 2021, Martin Stransky wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration


Along these lines, I am experiencing a pretty big regression in video 
performance with recent Firefox versions on Fedora.  It probably started 
with FF 93, but got a little better with FF 94.  It is really noticeable 
when using Google Meet.  I'm using Wayland on AMD GPU hardware.  Is this 
at all related to this HW acceleration stuff?


Please file a bug at https://bugzilla.redhat.com/ for further 
investigation and cc me there. I can name ten reasons why you see it.



--
Martin Stransky
Software Engineer / 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F36 Change: Unit Names in Systemd Messages (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
The default format of messages printed by systemd to the console and
the journal is changed from "Starting Frobnicating Daemon..." /
"Started Frobnicating Daemon" to "Starting frobnicator.service —
Frobnicating Daemon..." / "Started frobnicator.service — Frobnicating
Daemon".

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl


== Detailed Description ==
Systemd has three message formatting modes: `description`, `name`, and
`combined`. The first uses the Description, the second uses the unit
name, and the third uses " — ". We currently
default to `description`, and the proposal is to change the
compile-time default to `combined`. Users can override the default by
creating a configuration file and/or specifying an override on the
kernel command line.

systemd historically used the unit Description in console and journal
status messages, just like SysV init scripts. The Description is
intended to be easy to understand, but has the downside that to
interact with the service in any way, one has to figure out what the
unit name is. Thus, for an unfamiliar service, the user would have to
grep the unit list for the description first. And for more experienced
users, the unit name is more informative than the description. People
interact with unit names when operating on units, and don't look at
the descriptions during normal system administration. Thus, for both
new and experienced users, seeing the unit name is useful. To make the
change easier to accept, we added the `combined` mode, that also
prints the description on the right.

`journalctl -o cat` (old and new):

Started Journal Service.
Finished Load Kernel Modules.
Starting Apply Kernel Variables...
Starting Create Volatile Files and Directories...
Finished Apply Kernel Variables.
Finished Create Volatile Files and Directories.
Finished Setup Virtual Console.
Starting dracut ask for additional cmdline parameters...
Finished dracut ask for additional cmdline parameters.
Starting dracut cmdline hook...



Started systemd-journald.service - Journal Service.
Finished systemd-modules-load.service - Load Kernel Modules.
Finished systemd-tmpfiles-setup-dev.service - Create Static Device
Nodes in /dev.
Starting systemd-sysctl.service - Apply Kernel Variables...
Starting systemd-tmpfiles-setup.service - Create Volatile Files and
Directories...
Finished systemd-sysctl.service - Apply Kernel Variables.
Finished systemd-tmpfiles-setup.service - Create Volatile Files and Directories.
Finished systemd-vconsole-setup.service - Setup Virtual Console.
Starting dracut-cmdline-ask.service - dracut ask for additional
cmdline parameters...
Finished dracut-cmdline-ask.service - dracut ask for additional
cmdline parameters.
Starting dracut-cmdline.service - dracut cmdline hook...


If users don't like the new default, they can use
`systemd.status-unit-format=name|description` to override the default.
It is also possible to use `bootctl systemd-efi-options
systemd.status-unit-format=name|description` on EFI systems, and
create a config file with `[Manager]
StatusUnitFormat=name|description` to pick a different setting.


== Benefit to Fedora ==
The default format of messages is more directly useful. A user can
selectpaste the unit name directly from a message into a command
like `systemctl status` or `journalctl -u`.

== Scope ==
* Proposal owners:
** Implement the new mode (already done, available in systemd-249).
** Flip the compile-time default in systemd.

* Other developers:
** Adjust Descriptions of their units if appropriate. For example,
firewalld.service repeats the unit name in the Description. This was
already discouraged in the systemd.unit(5) man page, but now becomes
even more visible: `rawhide systemd[1]: Starting firewalld.service -
firewalld - dynamic firewall daemon...`. The Description should be
changed to "Description=Dynamic Firewall Daemon".

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


== Upgrade/compatibility impact ==
There shouldn't be any. I'm making this a Change because people don't
like surprises in the default look of things. There might be some
poorly written scripts which grep for unit Descriptions.


== How To Test ==
Boot, look at `journalctl -b _PID=1`.

Optionally, disable the plymouth screen (with Esc or by removing `rhgb
quiet` on the kernel command line), and look at console messages.
Output should contain unit names and be generally readable.
Unfortunately, the console output is ellipsized to fit in 80 columns,
so the full text is not always visible.

== User Experience ==
See example output above.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Revert the change.
* Contingency deadline: Final release, or maybe even later.
* Blocks release? No.

== Documentation ==
* 

F36 Change: Unit Names in Systemd Messages (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
The default format of messages printed by systemd to the console and
the journal is changed from "Starting Frobnicating Daemon..." /
"Started Frobnicating Daemon" to "Starting frobnicator.service —
Frobnicating Daemon..." / "Started frobnicator.service — Frobnicating
Daemon".

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl


== Detailed Description ==
Systemd has three message formatting modes: `description`, `name`, and
`combined`. The first uses the Description, the second uses the unit
name, and the third uses " — ". We currently
default to `description`, and the proposal is to change the
compile-time default to `combined`. Users can override the default by
creating a configuration file and/or specifying an override on the
kernel command line.

systemd historically used the unit Description in console and journal
status messages, just like SysV init scripts. The Description is
intended to be easy to understand, but has the downside that to
interact with the service in any way, one has to figure out what the
unit name is. Thus, for an unfamiliar service, the user would have to
grep the unit list for the description first. And for more experienced
users, the unit name is more informative than the description. People
interact with unit names when operating on units, and don't look at
the descriptions during normal system administration. Thus, for both
new and experienced users, seeing the unit name is useful. To make the
change easier to accept, we added the `combined` mode, that also
prints the description on the right.

`journalctl -o cat` (old and new):

Started Journal Service.
Finished Load Kernel Modules.
Starting Apply Kernel Variables...
Starting Create Volatile Files and Directories...
Finished Apply Kernel Variables.
Finished Create Volatile Files and Directories.
Finished Setup Virtual Console.
Starting dracut ask for additional cmdline parameters...
Finished dracut ask for additional cmdline parameters.
Starting dracut cmdline hook...



Started systemd-journald.service - Journal Service.
Finished systemd-modules-load.service - Load Kernel Modules.
Finished systemd-tmpfiles-setup-dev.service - Create Static Device
Nodes in /dev.
Starting systemd-sysctl.service - Apply Kernel Variables...
Starting systemd-tmpfiles-setup.service - Create Volatile Files and
Directories...
Finished systemd-sysctl.service - Apply Kernel Variables.
Finished systemd-tmpfiles-setup.service - Create Volatile Files and Directories.
Finished systemd-vconsole-setup.service - Setup Virtual Console.
Starting dracut-cmdline-ask.service - dracut ask for additional
cmdline parameters...
Finished dracut-cmdline-ask.service - dracut ask for additional
cmdline parameters.
Starting dracut-cmdline.service - dracut cmdline hook...


If users don't like the new default, they can use
`systemd.status-unit-format=name|description` to override the default.
It is also possible to use `bootctl systemd-efi-options
systemd.status-unit-format=name|description` on EFI systems, and
create a config file with `[Manager]
StatusUnitFormat=name|description` to pick a different setting.


== Benefit to Fedora ==
The default format of messages is more directly useful. A user can
selectpaste the unit name directly from a message into a command
like `systemctl status` or `journalctl -u`.

== Scope ==
* Proposal owners:
** Implement the new mode (already done, available in systemd-249).
** Flip the compile-time default in systemd.

* Other developers:
** Adjust Descriptions of their units if appropriate. For example,
firewalld.service repeats the unit name in the Description. This was
already discouraged in the systemd.unit(5) man page, but now becomes
even more visible: `rawhide systemd[1]: Starting firewalld.service -
firewalld - dynamic firewall daemon...`. The Description should be
changed to "Description=Dynamic Firewall Daemon".

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


== Upgrade/compatibility impact ==
There shouldn't be any. I'm making this a Change because people don't
like surprises in the default look of things. There might be some
poorly written scripts which grep for unit Descriptions.


== How To Test ==
Boot, look at `journalctl -b _PID=1`.

Optionally, disable the plymouth screen (with Esc or by removing `rhgb
quiet` on the kernel command line), and look at console messages.
Output should contain unit names and be generally readable.
Unfortunately, the console output is ellipsized to fit in 80 columns,
so the full text is not always visible.

== User Experience ==
See example output above.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Revert the change.
* Contingency deadline: Final release, or maybe even later.
* Blocks release? No.

== Documentation ==
* 

Planned Outage - server update/reboots - 2021-11-17 21:00 UTC

[Mark O'Brien]

All,

There will be a planned outage this week as outlined below:

Planned Outage - server update/reboots - 2021-11-17 21:00 UTC

There will be an outage starting at 2021-11-17 21:00UTC,
which will last approximately 4 hours.

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

date -d '2021-11-17 21:00UTC'

Reason for outage:

We will be updating and rebooting various servers to bring them up to date.
During the outage window any services may be up and down as proxies and
gateways are rebooted.

Affected Services:

Any fedoraproject services may be affected with the exception of
mirrorlists and static web content.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10336

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


Regards,
Fedora Infrastructure Team
___
devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Planned Outage - server update/reboots - 2021-11-17 21:00 UTC

[Mark O'Brien]

All,

There will be a planned outage this week as outlined below:

Planned Outage - server update/reboots - 2021-11-17 21:00 UTC

There will be an outage starting at 2021-11-17 21:00UTC,
which will last approximately 4 hours.

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

date -d '2021-11-17 21:00UTC'

Reason for outage:

We will be updating and rebooting various servers to bring them up to date.
During the outage window any services may be up and down as proxies and
gateways are rebooted.

Affected Services:

Any fedoraproject services may be affected with the exception of
mirrorlists and static web content.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10336

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


Regards,
Fedora Infrastructure Team
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Dominik 'Rathann' Mierzejewski]

On Monday, 15 November 2021 at 13:34, Fabio Valentini wrote:
> On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky  wrote:
> >
> > Hi folks,
> >
> > I was told that people were having trouble with Firefox/HW
> > acceleration/VA-API setup on Fedora so I put some info at wiki at:
> >
> > https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
> >
> > Hope it helps.
> > Martin
> 
> I appreciate the effort to document ways to improve things. However:
> 
> > Video decoding on NVIDIA
> > Please buy some real Linux hardware.
> 
> This doesn't really help at all. Is it supposed to be funny, or is it
> just cynical resignation?
> 
> I mean, even if I *could* throw a couple hundred bucks out the window
> to replace a perfectly working NVidia hardware, most places don't even
> seem to have AMD graphics cards in stock right now. Does that just
> mean "tough luck" for users like me?

Well, nVidia refuses to support VA-API like Intel and AMD do and the
VA-API-to-VDPAU won't help because dmabuf support is still required.
So... tough luck:

https://bugzilla.mozilla.org/show_bug.cgi?id=1669189
https://bugzilla.mozilla.org/show_bug.cgi?id=1210729

... and probably others.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

LTO objects after build: Rebuilding vs erroring out

[Florian Weimer]

In the future, we might want to switch GCC not to generate both object
code and LTO representation during the build process.  For most
packages, dual generation is not necessary because no relocatable object
files for static linking are included in the RPM (neither as separate
ET_REL .o files, nor in static .a archives).  Final (non-relocatable)
links of any kind will generate object code, so only LTO representation
needs to be written by GCC.

But in case relocatable object files are produced by the package (e.g.,
for a -static subpackage for static linking), it is necessary to
generate object code for relocatable files as well.  The reason is that
only object code (not LTO representation) is a stable format, and it's
the only way to achieve cross-toolchain linking.

The way I envisioned LTO-only building for GCC was to replace
the brp-strip-lto script



with somehting that errors out (fails the build) if any relocatable
object files (.o) or static archives (.a) by default, and stop producing
object code by default, only LTO representation.  If a special
redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is
configured to produce both object code and LTO representation (basically
what we have today).

However, Clang has chosen a different approach: Build object code in the
final stages, via the brp-llvm-compile-lto-elf script:


  

This does not really work for GCC in downstream because we have multiple
GCCs there, with incompatible LTO representation.  We also cannot
replicate the exact command line options that have been used during the
package-internal build process; we only have the default
redhat-rpm-config flags at this point, and whatever has been serialized
into the LTO representation.

Fedora has multiple LLVMs (e.g., rust in Fedora 35 is at LLVM 12, but
/usr/bin/clang is LLVM 13).  LLVM bitcode is supposed to be more
compatible:

  

But don't know to what extent we test that.

I'd prefer to use a single mechanism for both toolchains.  But it seems
that Clang does not support creating ELF object files that contain LLVM
IR (GCC's default mode we use today).  Given the problems with
post-building object code for GCC, I'm not sure if this is feasible.

Thoughts?

Thanks,
Florian

PS: I tried to avoid fat/thin references because the terms are
inconsistent across the toolchains.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Fabio Valentini]

On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky  wrote:
>
> Hi folks,
>
> I was told that people were having trouble with Firefox/HW
> acceleration/VA-API setup on Fedora so I put some info at wiki at:
>
> https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
>
> Hope it helps.
> Martin

I appreciate the effort to document ways to improve things. However:

> Video decoding on NVIDIA
> Please buy some real Linux hardware.

This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?

I mean, even if I *could* throw a couple hundred bucks out the window
to replace a perfectly working NVidia hardware, most places don't even
seem to have AMD graphics cards in stock right now. Does that just
mean "tough luck" for users like me?

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20211115.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-2024.n.0
NEW: Fedora-Rawhide-2025.n.0

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

Size of added packages:  7.42 MiB
Size of dropped packages:0 B
Size of upgraded packages:   410.72 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-2025.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-2025.n.0.s390x.raw.xz

= DROPPED IMAGES =
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-Rawhide-2024.n.0.armhfp.raw.xz

= ADDED PACKAGES =
Package: golang-github-schollz-cli-2-2.2.1-1.fc36
Summary: A simple, fast, and fun package for building command line apps in Go
RPMs:golang-github-schollz-cli-2-devel golang-github-schollz-cli-2-doc
Size:2.64 MiB

Package: golang-github-schollz-mnemonicode-1.0.1-1.fc36
Summary: Method for encoding binary data into a sequence of words
RPMs:golang-github-schollz-mnemonicode-devel mnemonicode
Size:3.64 MiB

Package: libpal-0.9.8-3.fc36
Summary: Positional Astronomy Library
RPMs:libpal libpal-devel libpal-doc
Size:896.52 KiB

Package: python-gelidum-0.5.7-1.fc36
Summary: Freeze your objects in python
RPMs:python3-gelidum
Size:35.99 KiB

Package: python-noiseprotocol-0.3.1-1.fc36
Summary: Python 3 implementation of Noise Protocol Framework
RPMs:python-noiseprotocol-doc python3-noiseprotocol
Size:230.15 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Mayavi-4.7.4-1.fc36
Old package:  Mayavi-4.7.3-3.fc35
Summary:  Scientific data 3-dimensional visualizer
RPMs: Mayavi Mayavi-doc python3-mayavi
Size: 92.45 MiB
Size change:  -170.39 KiB
Changelog:
  * Mon Nov 15 2021 Orion Poplawski  - 4.7.4-1
  - Update to 4.7.4


Package:  anjuta-1:3.34.0-10.fc36
Old package:  anjuta-1:3.34.0-9.fc35
Summary:  GNOME IDE for various programming languages (including C/C++, 
Python, Vala and JavaScript)
RPMs: anjuta anjuta-devel anjuta-libs
Added RPMs:   anjuta-libs
Size: 29.87 MiB
Size change:  -3.56 MiB
Changelog:
  * Sun Nov 14 2021 Gwyn Ciesla  - 1:3.34.0-10
  - Split out libs package to reduce gtkpod footprint.


Package:  corectrl-1.2.2-1.fc36
Old package:  corectrl-1.2.1-1.fc36
Summary:  Friendly hardware control
RPMs: corectrl
Size: 5.94 MiB
Size change:  4.47 KiB
Changelog:
  * Sun Nov 14 2021 Artem Polishchuk  - 1.2.2-1
  - chore(update): 1.2.2


Package:  cri-o-1.22.1-1.module_f36+13372+a10f91a1
Old package:  cri-o-1.22.0-3.module_f36+12977+19790ad0
Summary:  Open Container Initiative-based implementation of Kubernetes 
Container Runtime Interface
RPMs: cri-o
Size: 112.11 MiB
Size change:  -106.10 KiB
Changelog:
  * Mon Nov 08 2021 Peter Hunt  - 0:1.22.0-4
  - update golang version

  * Thu Nov 11 2021 Peter Hunt  - 0:1.22.1-1
  - bump to v1.22.1


Package:  cri-tools-1.22.0-3.module_f36+13372+a10f91a1
Old package:  cri-tools-1.19.0-1.module_f36+12977+19790ad0
Summary:  CLI and validation tools for Container Runtime Interface
RPMs: cri-tools
Size: 36.85 MiB
Size change:  9.24 MiB
Changelog:
  * Wed Aug 18 2021 Peter Hunt  - 1.20.0-2
  - bump to v1.20.0

  * Thu Nov 11 2021 Peter Hunt  - 1.21.0-3
  - bump to v1.21.0


Package:  curl-7.80.0-2.fc36
Old package:  curl-7.80.0-1.fc36
Summary:  A utility for getting files from remote servers (FTP, HTTP, and 
others)
RPMs: curl curl-minimal libcurl libcurl-devel libcurl-minimal
Size: 10.35 MiB
Size change:  662 B
Changelog:
  * Sun Nov 14 2021 Paul Howarth  - 7.80.0-2
  - sshserver.pl (used in test suite) now requires the Digest::SHA perl module


Package:  dummy-test-package-gloster-0-5821.fc36
Old package:  dummy-test-package-gloster-0-5805.fc36
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 355.67 KiB
Size change:  975 B
Changelog:
  * Sun Nov 14 2021 packagerbot  - 0-5806
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5807
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5808
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5809
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5810
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5811
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5812
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5813
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5814
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5815
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5816
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5817
  - rebuilt

  * Sun Nov 14 2021 packagerbot  - 0-5818
  - rebuilt

  * Mon Nov 15 2021 packagerbot  - 0

Re: Update of rust-cfg-expr

[Fabio Valentini]

On Mon, Nov 15, 2021 at 7:09 AM Rémi Lauzier via devel
 wrote:
>
> I everyone! I am updating rust-cfg-expr to version 0.9.0. I will push the 
> side-tag in two weeks unless there is an objection. The only dependant 
> package is rust-system-deps.
>
> f36-build-side-47814
> f35-build-side-47816
> f34-build-side-47818

Thanks for the heads-up!
However, it would be good to know if you'll be patching and building
system-deps for those side tags yourself or if somebody else needs to
do that.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox Hardware acceleration & VA-API how-to

[Dan Horák]

On Fri, 12 Nov 2021 09:37:26 +0100
Martin Stransky  wrote:

> Hi folks,
> 
> I was told that people were having trouble with Firefox/HW 
> acceleration/VA-API setup on Fedora so I put some info at wiki at:
> 
> https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
> 
> Hope it helps.

it does help :-) Briefly tested on my F-34/ppc64le with AMD GPU and it
seems to make a difference.


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

Fedora-Cloud-34-20211115.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-2021.0):

ID: 1064824 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1064824
ID: 1064833 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1064833

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] [Test Week] Fedora Linux Kernel 5.15 2021-11-14 through 2021-11-21

[Sumantro Mukherjee]

Hey All,

I would like to invite all of you to participate in the Kernel 5.15
Test week is happening from 2021-11-14 to 2021-11-21. It's
fairly simple, head over to the wiki [0] and read in detail about the
test week and simply run the test case mentioned in[1] and enter your
results.

As usual, the Fedora QA team will hangout at #fedora-test-...@libera.chat
for question and
discussion.

If you are someone who is just starting out, remember that we give out
badges[2] for
testing new Kernel Builds!
Collect 'em now :)

[0] http://fedoraproject.org/wiki/Test_Day:2021-11-14_Kernel_5.15_Test_Week
[1] https://testdays.fedoraproject.org/events/125
[2] https://badges.fedoraproject.org/badge/science-kernel-tester-i



-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure