Re: python-pandas has been orphaned - needs a new primary maintainer.

[Jonathan Wright via devel]

I threw my name on it.  Will go through its current state in the next few
days.

On Wed, Sep 28, 2022 at 8:45 PM Orion Poplawski  wrote:

> Looks like python-pandas has been orphaned.  Is anyone interested in
> taking it on?  I've done some drive by work (and have maintained it in
> EPEL), but I already have too many packages.
>
> Thanks,
>Orion
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


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

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

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0eb78611cf   
knot-resolver-5.5.3-1.el9
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1de0ed44a1   
kitty-0.26.3-2.el9
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4c5aee9b50   
chromium-105.0.5195.125-2.el9


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

advancecomp-2.3-2.el9
clibs-list-0.4.0-1.el9
jc-1.22.0-1.el9
ldc-1.30.0-1.el9
python-httpcore-0.15.0-1.el9
python-requests-pkcs12-1.7-9.el9
python-sphinx-copybutton-0.5.0-3.el9
rednotebook-2.26-1.el9
rlwrap-0.45.2-3.el9
voms-api-java-3.3.2-8.el9
zabbix-6.0.8-1.el9

Details about builds:



 advancecomp-2.3-2.el9 (FEDORA-EPEL-2022-af97c657dc)
 Recompression utilities for .png, .mng, .zip and .gz files

Update Information:

- Update to 2.3 - Update License to SPDX - Document bundled 7z code - Unbundle
libdeflate and zopfli - General packaging improvements

ChangeLog:

* Wed Sep 28 2022 Benjamin A. Beasley  2.3-2
- Drop conditionals for Fedora and other EPELs
* Wed Sep 28 2022 Benjamin A. Beasley  2.3-1
- Update to 2.3 (close RHBZ#2075857)
* Wed Sep 28 2022 Benjamin A. Beasley  2.1-30
- Update License to SPDX
* Wed Sep 28 2022 Benjamin A. Beasley  2.1-29
- Drop {authors,history,readme}.txt
* Sat Sep 24 2022 Benjamin A. Beasley  - 2.1-21
- Spec file formatting tweaks
- Convert URLs from HTTP to HTTPS
- Use modern spec file macros (make_build/make_install/etc.)
- Unbundle libdeflate
- Unbundle zopfli where it is available as a system library (i.e., Fedora)
- Remove unnecessary BR on tofrodos
- Properly document bundled 7z code
* Wed Jul 20 2022 Fedora Release Engineering  - 2.1-20
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jan 19 2022 Fedora Release Engineering  - 2.1-19
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #1557679 - advzip should be linked to system compression libraries
https://bugzilla.redhat.com/show_bug.cgi?id=1557679
  [ 2 ] Bug #2075857 - advancecomp-2.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2075857




 clibs-list-0.4.0-1.el9 (FEDORA-EPEL-2022-7155b91ceb)
 C doubly linked list implementation

Update Information:

Initial package

ChangeLog:

* Sat Sep 24 2022 Benjamin A. Beasley  0.4.0-1
- Update to 0.4.0
* Sat Sep 24 2022 Benjamin A. Beasley  0.2.0-1
- Initial package (close RHBZ#2123950)

References:

  [ 1 ] Bug #2123950 - Review Request: clibs-list - C doubly linked list 
implementation
https://bugzilla.redhat.com/show_bug.cgi?id=2123950




 jc-1.22.0-1.el9 (FEDORA-EPEL-2022-d4c56a317c)
 Serialize the output of CLI tools and file-types to structured JSON

Update Information:

Update to v1.22.0

ChangeLog:

* Tue Sep 27 2022 Artur Frenszek-Iwicki  - 1.22.0-1
- Update to v1.22.0

References:

  [ 1 ] Bug #2130341 - jc-1.22.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2130341




 ldc-1.30.0-1.el9 (FEDORA-EPEL-2022-09ed2e550c)
 LLVM D Compiler

Update Information:

Initial LDC build for EPEL 9.

ChangeLog:

* Tue Jul 26 2022 Kalev Lember  - 1:1.30.0-1
- Update to 1.30.0
- Build with llvm 14
* Thu Jul 21 2022 Fedora Release Engineering  - 
1:1.27.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Thu Jan 20 2022 Fedora Release Engineering  - 
1:1.27.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Wed Aug 18 

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1b4c7ee66c   
knot-resolver-5.5.3-1.el7


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

dropbear-2017.75-2.el7
fts-3.12.0-1.el7
rlwrap-0.45.2-2.el7

Details about builds:



 dropbear-2017.75-2.el7 (FEDORA-EPEL-2022-f0317a13d8)
 Lightweight SSH server and client

Update Information:

- Backport fix for CVE-2018-15599, resolves rhbz#1623177 - Backport fix for
CVE-2020-36254, resolves rhbz#1933067

ChangeLog:

* Wed Sep 28 2022 Carl George  - 2017.75-2
- Backport fix for CVE-2018-15599, resolves rhbz#1623177
- Backport fix for CVE-2020-36254, resolves rhbz#1933067

References:

  [ 1 ] Bug #1623177 - CVE-2018-15599 dropbear: User enumeration via malformed 
packets in authentication requests [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1623177
  [ 2 ] Bug #1933067 - CVE-2020-36254 dropbear: mishandles the filename of . or 
an empty filename [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1933067




 fts-3.12.0-1.el7 (FEDORA-EPEL-2022-41b0d14048)
 File Transfer Service V3

Update Information:

The FTS v3.12.0 release

ChangeLog:

* Tue Sep 27 2022 Mihai Patrascoiu  - 3.12.0-1
- Upstream release v3.12.0




 rlwrap-0.45.2-2.el7 (FEDORA-EPEL-2022-04cccae3c4)
 Wrapper for GNU readline

Update Information:

Fixes the version handling in rlwrapfilter to work with x.y.z version numbers

ChangeLog:

* Wed Sep 28 2022 Michel Alexandre Salim  0.45.2-2
- Fix version parsing in rlwrapfilter.py (rhbz#2091749)

References:

  [ 1 ] Bug #2091749 - rlwrap built for F36 sets a version number with a minor 
version to the env RLWRAP_VERSION
https://bugzilla.redhat.com/show_bug.cgi?id=2091749


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

[Bug 2123418] perl-Date-Manip-6.89 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Date-Manip-6.89-1.fc37 |perl-Date-Manip-6.89-1.fc37
   ||perl-Date-Manip-6.89-1.fc36



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-51f66cd332 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 2128593] perl-Module-CoreList-5.20220920 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022
   |0920-1.fc38 |0920-1.fc38
   |perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022
   |0920-1.fc37 |0920-1.fc37
   ||perl-Module-CoreList-5.2022
   ||0920-1.fc36



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-c032a0b0c4 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gary Buhrmaster]

On Tue, Sep 27, 2022 at 8:06 PM David Airlie  wrote:

> Think of it like a jigsaw puzzle, where the person who places the last
> piece in the puzzle pays the license. But then stop thinking of it
> like that and just assume it's a lot vaguer and way more legally
> involved than that.

So, for CPU's with iGPUs sold retail to people
like me, does Intel (and now including AMD)
include the IP license?  If not, how can I get one
from Intel (who sold me a CPU/iGPU that states
it can decode the codecs in question)?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Cronenworth]

On 9/28/22 6:45 PM, David Airlie wrote:

Please take a look at the rawhide changes I just pushed. This should
split things out sufficiently.


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

[Bug 2130729] New: perl-PAR-1.018 is available

[bugzilla]

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

Bug ID: 2130729
   Summary: perl-PAR-1.018 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PAR
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.018
Upstream release that is considered latest: 1.018
Current version/release in rawhide: 1.017-7.fc37
URL: http://search.cpan.org/dist/PAR/

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


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


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


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


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


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

python-pandas has been orphaned - needs a new primary maintainer.

[Orion Poplawski]

Looks like python-pandas has been orphaned.  Is anyone interested in 
taking it on?  I've done some drive by work (and have maintained it in 
EPEL), but I already have too many packages.


Thanks,
  Orion

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


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

python-pandas has been orphaned - needs a new primary maintainer.

[Orion Poplawski]

Looks like python-pandas has been orphaned.  Is anyone interested in 
taking it on?  I've done some drive by work (and have maintained it in 
EPEL), but I already have too many packages.


Thanks,
  Orion

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


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

Nope the _video.so files are the vaapi ones.

Replacing that package with rpmfusion built should work fine.

On Thu, Sep 29, 2022 at 10:26 AM Neal Gompa  wrote:
>
> On Thu, Sep 29, 2022 at 1:46 AM David Airlie  wrote:
> >
> > On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
> > >
> > > Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> > > >
> > > > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal 
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > since this mesa change ( 
> > > > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> > > > >  ) in F37 and rawhide, the mesa package lost support for vaapi 
> > > > > accelerated encoding and decoding of h264, h265 and decoding of vc1 ( 
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > > > >
> > > > > It seems like a big regression from F36 for users with GPUs with open 
> > > > > source drivers (mainly AMD, maybe nVidia/other non x86...), that 
> > > > > affects common use-cases of Fedora Workstation, like watching videos, 
> > > > > in-house game streaming, attending online meetings and many more.
> > > >
> > > > This was an oversight being enabled prior to this, and I think we have
> > > > to remove it from older Fedora as well. Fedora cannot ship anything
> > > > that causes the OS to provide an API which exposes patent algorithms.
> > > >
> > > > The patent licensing around H264/H265 is such that providing this
> > > > could leave Red Hat and other Fedora distributors exposed to legal
> > > > problems.
> > > > Dave.
> > > >
> > > > > I'd like to ask:
> > > > > - Can somebody elaborate on reasons to change something that was 
> > > > > working in Fedora for some time already?
> > > > > - Is there any short/mid/long term plan to improve the situation?
> > > > > - Would it be possible to provide vaapi support at least as an 
> > > > > rpmfusion addon to alleviate the fallout in the short term?
> > > >
> > > > The last might be possible, but I'm not sure how to go about it.
> > > At least I've asked in 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
> > >
> > > That the fedora mesa package completely drops the vaapi backend, so a
> > > complementary package can just drop the missing files instead of
> > > rebuilding a whole mesa package.
> > > It would assume the fedora mesa package to have everything needed in
> > > order to cope with vaapi backend enabled in the core libraries and
> > > that the vaapi backend only provide the implementation.
> >
> > Please take a look at the rawhide changes I just pushed. This should
> > split things out sufficiently.
> >
>
> But wait, aren't these the DRI drivers[1]?
>
> [1]: 
> https://src.fedoraproject.org/rpms/mesa/c/07e1e0b1628d9c55d3858c4655409768c5c0b5de?branch=rawhide
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Thu, Sep 29, 2022 at 1:46 AM David Airlie  wrote:
>
> On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
> >
> > Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> > >
> > > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > since this mesa change ( 
> > > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> > > >  ) in F37 and rawhide, the mesa package lost support for vaapi 
> > > > accelerated encoding and decoding of h264, h265 and decoding of vc1 ( 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > > >
> > > > It seems like a big regression from F36 for users with GPUs with open 
> > > > source drivers (mainly AMD, maybe nVidia/other non x86...), that 
> > > > affects common use-cases of Fedora Workstation, like watching videos, 
> > > > in-house game streaming, attending online meetings and many more.
> > >
> > > This was an oversight being enabled prior to this, and I think we have
> > > to remove it from older Fedora as well. Fedora cannot ship anything
> > > that causes the OS to provide an API which exposes patent algorithms.
> > >
> > > The patent licensing around H264/H265 is such that providing this
> > > could leave Red Hat and other Fedora distributors exposed to legal
> > > problems.
> > > Dave.
> > >
> > > > I'd like to ask:
> > > > - Can somebody elaborate on reasons to change something that was 
> > > > working in Fedora for some time already?
> > > > - Is there any short/mid/long term plan to improve the situation?
> > > > - Would it be possible to provide vaapi support at least as an 
> > > > rpmfusion addon to alleviate the fallout in the short term?
> > >
> > > The last might be possible, but I'm not sure how to go about it.
> > At least I've asked in 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
> >
> > That the fedora mesa package completely drops the vaapi backend, so a
> > complementary package can just drop the missing files instead of
> > rebuilding a whole mesa package.
> > It would assume the fedora mesa package to have everything needed in
> > order to cope with vaapi backend enabled in the core libraries and
> > that the vaapi backend only provide the implementation.
>
> Please take a look at the rawhide changes I just pushed. This should
> split things out sufficiently.
>

But wait, aren't these the DRI drivers[1]?

[1]: 
https://src.fedoraproject.org/rpms/mesa/c/07e1e0b1628d9c55d3858c4655409768c5c0b5de?branch=rawhide



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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
>
> Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> >
> > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > wrote:
> > >
> > > Hi,
> > >
> > > since this mesa change ( 
> > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> > >  ) in F37 and rawhide, the mesa package lost support for vaapi 
> > > accelerated encoding and decoding of h264, h265 and decoding of vc1 ( 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > >
> > > It seems like a big regression from F36 for users with GPUs with open 
> > > source drivers (mainly AMD, maybe nVidia/other non x86...), that affects 
> > > common use-cases of Fedora Workstation, like watching videos, in-house 
> > > game streaming, attending online meetings and many more.
> >
> > This was an oversight being enabled prior to this, and I think we have
> > to remove it from older Fedora as well. Fedora cannot ship anything
> > that causes the OS to provide an API which exposes patent algorithms.
> >
> > The patent licensing around H264/H265 is such that providing this
> > could leave Red Hat and other Fedora distributors exposed to legal
> > problems.
> > Dave.
> >
> > > I'd like to ask:
> > > - Can somebody elaborate on reasons to change something that was working 
> > > in Fedora for some time already?
> > > - Is there any short/mid/long term plan to improve the situation?
> > > - Would it be possible to provide vaapi support at least as an rpmfusion 
> > > addon to alleviate the fallout in the short term?
> >
> > The last might be possible, but I'm not sure how to go about it.
> At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
>
> That the fedora mesa package completely drops the vaapi backend, so a
> complementary package can just drop the missing files instead of
> rebuilding a whole mesa package.
> It would assume the fedora mesa package to have everything needed in
> order to cope with vaapi backend enabled in the core libraries and
> that the vaapi backend only provide the implementation.

Please take a look at the rawhide changes I just pushed. This should
split things out sufficiently.

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

Re: Explicit dependency on systemd-rpm-macros now required?

[Sérgio Basto]

On Fri, 2022-09-23 at 22:49 +0100, Sérgio Basto wrote:
> On Fri, 2022-09-23 at 22:39 +0100, Sérgio Basto wrote:
> > On Mon, 2022-09-19 at 09:08 +0200, Dan Horák wrote:
> > > On Fri, 16 Sep 2022 13:42:42 +
> > > Zbigniew Jędrzejewski-Szmek  wrote:
> > > 
> > > > On Fri, Sep 16, 2022 at 03:35:29PM +0200, Florian Weimer wrote:
> > > > > * Zbigniew Jędrzejewski-Szmek:
> > > > > 
> > > > > > So… we certainly don't want people having to declare the
> > > > > > dependency
> > > > > > manually everywhere.
> > > > > 
> > > > > The packaging guidelines seem to say that the manual
> > > > > dependency
> > > > > is
> > > > > required, though.
> > > > 
> > > > Yeah, you need *some* dependency. But opencryptoki has
> > > > BR:systemd-devel, and systemd-devel has R:systemd, which has
> > > > the
> > > > Requires(meta) under discussion. So an explicit BR:systemd-rpm-
> > > > macros
> > > > should be redundant.
> > > 
> > > the BR: systemd-devel in opencryptoki might be just a historical
> > > relict, because it used to be required to define the various
> > > macros
> > > (IIRC)
> > > 
> > > 
> > > Dan
> > 
> > 
> > Today clamav fails to build on rawhide again, this time because
> > make
> > install on mock doesn't install systemd files  ! 
> 
> 
> scratch build
> https://koji.fedoraproject.org/koji/taskinfo?taskID=92286295


systemd-devel no longer has systemd dependency on F37+, now we also
need BuildRequires: systemd

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

[EPEL-devel] EPEL 8 Modules get the axe on Halloween 2022

[Troy Dawson]

When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install or
even run on an EL-8 system. Attempts to fix this and work within how EPEL
is normally built have been tried for several years by different people but
have not worked.

At this point we are saying that this experiment with modules in EPEL has
not worked and we will focus our resources on what does work.

Schedule of EPEL 8 Module Retirement:
Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0
-- epel-modular full name will have "Deprecated" in it

October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.

After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.

Questions and Answers:

Question: Will I still be able to access the modules after October 31st?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes.  They will be in the Fedora archives,
and the mirror managers will point at them.

Question: What will you be dressed as on Halloween?
Answer (Troy): A Penguin

EPEL Steering Committee

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

Fedora 37 compose report: 20220928.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20220927.n.0
NEW: Fedora-37-20220928.n.1

= SUMMARY =
Added images:1
Dropped images:  7
Added packages:  0
Dropped packages:14
Upgraded packages:   5
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:425.35 MiB
Size of upgraded packages:   586.42 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-37-20220928.n.1.aarch64.raw.xz

= DROPPED IMAGES =
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-37-20220927.n.0.s390x.qcow2
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-37-20220927.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-37-20220927.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-37-20220927.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20220927.n.0.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20220927.n.0.s390x.qcow2
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-37-20220927.n.0.s390x.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: commissaire-client-0.0.6-19.fc37
Summary: CLI for Commissaire
RPMs:commissaire-client
Size:61.21 KiB

Package: elementary-planner-1:3.0.7-1.fc37
Summary: Task manager with Todoist support designed for GNU/Linux
RPMs:elementary-planner
Size:2.95 MiB

Package: erlang-esip-1.0.37-4.fc36
Summary: ProcessOne SIP server component in Erlang
RPMs:erlang-esip
Size:745.02 KiB

Package: erlang-jiffy-1.0.5-4.fc36
Summary: Erlang JSON parser
RPMs:erlang-jiffy
Size:185.10 KiB

Package: erlang-riak_ensemble-3.0.10-1.fc37
Summary: Multi-Paxos framework in Erlang
RPMs:erlang-riak_ensemble
Size:2.02 MiB

Package: erlang-xmpp-1.4.9-4.fc36
Summary: Erlang/Elixir XMPP parsing and serialization library
RPMs:erlang-xmpp
Size:7.51 MiB

Package: golang-x-build-0-0.19.20201229git0a4bf69.fc35
Summary: Packages and tools that support Go's build system
RPMs:golang-x-build golang-x-build-devel
Size:407.92 MiB

Package: python-august-0.25.2-7.fc37
Summary: Python API for August Smart Lock and Doorbell
RPMs:python3-august
Size:65.02 KiB

Package: python-calligrabot-1.0.0-2.fc36
Summary: A robosignatory driver for the CentOS Stream signing service
RPMs:python3-calligrabot
Size:21.04 KiB

Package: python-cu2qu-1.6.7-6.fc36
Summary: Cubic-to-quadratic bezier curve conversion
RPMs:python3-cu2qu
Size:458.82 KiB

Package: python-evic-0.1-0.27.git20161101.176cf0b.fc36
Summary: USB programmer for devices based on the Joyetech Evic VTC Mini
RPMs:python3-evic
Size:45.37 KiB

Package: python-jaydebeapi-1.2.3-8.fc37
Summary: Bridge from JDBC database drivers to Python DB-API
RPMs:python3-jaydebeapi
Size:44.90 KiB

Package: python-sendgrid-3.6.5-17.fc35
Summary: SendGrid library for Python
RPMs:python-sendgrid-examples python3-sendgrid
Size:57.22 KiB

Package: rust-just-0.9.8-4.fc37
Summary: A command runner
RPMs:just rust-just+default-devel rust-just-devel
Size:3.31 MiB


= UPGRADED PACKAGES =
Package:  firefox-105.0.1-1.fc37
Old package:  firefox-104.0.2-1.fc37
Summary:  Mozilla Firefox Web browser
RPMs: firefox firefox-langpacks firefox-wayland firefox-x11
Size: 416.08 MiB
Size change:  3.79 MiB
Changelog:
  * Tue Sep 20 2022 Martin Stransky - 105.0-1
  - Updated to 105.0

  * Thu Sep 22 2022 Martin Stransky - 105.0.1-1
  - Updated to 105.0.1
  - Excluded i686 due to https://bugzilla.mozilla.org/show_bug.cgi?id=1792159


Package:  gnome-shell-extension-appindicator-43-1.fc37
Old package:  gnome-shell-extension-appindicator-42-3.fc37
Summary:  AppIndicator/KStatusNotifierItem support for GNOME Shell
RPMs: gnome-shell-extension-appindicator
Size: 65.44 KiB
Size change:  4.19 KiB
Changelog:
  * Tue Sep 27 2022 Artem Polishchuk  43-1
  - chore(update): 43


Package:  greenboot-0.15.2-2.fc37
Old package:  greenboot-0.15.2-1.fc37
Summary:  Generic Health Check Framework for systemd
RPMs: greenboot greenboot-default-health-checks
Size: 147.79 KiB
Size change:  630 B
Changelog:
  * Fri Sep 23 2022 Adam Williamson  - 0.15.2-2
  - Backport PR #84 to fix RHBZ #2121944


Package:  mesa-22.2.0-3.fc37
Old package:  mesa-22.2.0-1.fc37
Summary:  Mesa graphics libraries
RPMs: mesa-dri-drivers mesa-filesystem mesa-libEGL mesa-libEGL-devel 
mesa-libGL mesa-libGL-devel mesa-libOSMesa mesa-libOSMesa-devel mesa-libOpenCL 
mesa-libOpenCL-devel mesa-libd3d mesa-libd3d-devel mesa-libgbm 
mesa-libgbm-devel mesa-libglapi mesa-libxatracker mesa-libxatracker-devel 
mesa-omx-drivers mesa-vdpau

Re: Self Introduction: Sébastien Le Roux

[Renich Bon Ćirić]

On Wed, 2022-09-28 at 20:01 +0200, Sébastien Le Roux wrote:
> Hello,
> and thank you all for the welcome ;-)
> 
> Not sure what you did to build it, did you download the sources from the 
> website ?

From github; as you menton next. 

> If you download the sources here: https://github.com/Slookeur/Atomes
> then the Makefile is a home cooked file,  and make can take two targets:
> 
> 'make atomes' -> normal version
> 'make debug' -> all kind of debug flags
> 
> And I will provide build instructions on the Github repo.
> 
> With the sources used to build the RPMs:
> SRPMS/atomes-1.1.5-1.src.rpm
> https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes-1.1.5.tar.gz
> 
> then './configure' followed by 'make' works just fine.

Just noticed you posted an SRPM and a SPEC file in bugzilla. 

One thing, though, the SRPM doesn't build because the SPEC file is different. I
had to:

spectool -Rag SPEC/atomes-fedora.spec
rpmbuild -bs SPEC/atomes-fedora.spec
mock --rebuild SRPMS/atomes-1.1.5-1.src.rpm

... in order for it to successfully build. 

You should update the SRPM in github. ;D


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 28 Sep 2022, at 19:40, Neal Gompa  wrote:
> 
> On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel
> mailto:devel@lists.fedoraproject.org>> wrote:
>> 
>>> On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
>>> 
>>> On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:
 
 On 9/28/22 03:50, Tommy Nguyen wrote:
> This change will only affect AMD, as the intel non-free drivers do not
> depend on the changes. It is also unclear how this would affect nvidia.
> There is barely any hardware video acceleration support for nouveau
> anyway, for which you would install the proprietary driver. Further, as
> NVIDIA does not expose a vaapi interface, you need to install third
> party packages to get it to work with Firefox. So AFAICT this will
> primarily (if not only) affect AMD users.
 
 So only everybody who specifically purchased a discrete GPU that works
 "out of the box" with Fedora?
>>> 
>>> Well, we don't ship any userspace software that provides the necessary
>>> support code to use those codecs anyway.
>>> 
>> Firefox was able to use VA-API on Intel (at least - I don’t have Radeon 
>> hardware to hand) to accelerate H.264 decode.
>> 
> 
> Intel doesn't use Gallium (Mesa) for VA-API. You need a separate
> driver package for it, which we currently don't ship and the version
> being reviewed will not have these codecs enabled.
> 
To be clear - I wasn’t saying that Intel used Mesa for VA-API; I was saying 
that with Mesa drivers and Radeon hardware, I would expect Firefox’s VA-API 
support to work as well as it does for Intel, but I have not been able to test 
this.

>> And we ship gstreamer1-vaapi which lets any GStreamer using application 
>> (Totem, for example) use hardware acceleration.
> 
> Hmm, I forgot about that. FFmpeg doesn't have it because ffmpeg does
> stupid things when the codec is available but doesn't work. GStreamer
> is probably more intelligent about failing over.
> 
GStreamer elements run code to determine what codecs are supported - the VA-API 
elements use this to avoid claiming to support a codec unless it will work.

I’m not familiar with the current state of FFmpeg - in the dim and distant 
past, it relied on data tables to determine what codecs a given plugin 
supported, rather than running code (hence the VA-API plugins can’t claim no 
codec support when VA-API is unavailable).

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

Re: Self Introduction: Sébastien Le Roux

[Alexander Ploumistos]

On Wed, Sep 28, 2022 at 8:35 PM Sébastien Le Roux
 wrote:
>
> Le 28/09/2022 à 20:13, Alexander Ploumistos a écrit :
> >
> Yes I did look into this documents today, followed the procedure, and
> submitted the bugzilla:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2130607

I'm preparing for an interview with the CNRS these days, but if nobody
else turns up, I will do the review.


> About what I understand the first thing is to find a sponsor, and I hope
> what I provided is enough,
> please let me know if you think that I missed something, I would correct
> it ASAP.

I've set the FE-NEEDSPONSOR flag to your review request, it should
help with that.

In the meantime, you could add this to your reading list:
https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/
It could give you some pointers as to what you could do to get
sponsored, e.g. unofficial reviews.


> However I wasn't able to understand how to provide a 'koji' build,
> I can build the package using 'fedpkg' (local) but not sure how both
> relate ...

It's in the "Scratch Builds" section of this document (they're quickly
piling up, I know…):
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/
Essentially, you do a scratch build of your package in Rawhide and if
it is successful, you post the link to your review request.


> > Eventually, you might be interested in joining the Sci-Tech SIG, it's
> > more than likely that we maintain some package you might be using and
> > more hands are always welcome:
> > https://fedoraproject.org/wiki/Category:SciTech_SIG
>
> Sure, but I would need a proper training before that ;-)

There are quite a few chemistry-related packages that could use more
love. I think you are more than qualified to lend a hand in many of
them, should the need occur.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How do I "unstick" koji?

[Kevin Fenzi]

On Wed, Sep 28, 2022 at 10:10:34AM -0400, Steven A. Falco wrote:
> On 9/28/22 09:59 AM, Stephen Smoogen wrote:
> > 
> > 
> > On Wed, 28 Sept 2022 at 09:53, Steven A. Falco  > > wrote:
> > 
> > Yesterday, I had a build that failed.  The task ID is 92381483.
> > 
> > I tried rebuilding it today in task 92397327 but I get the error 
> > message:
> > 
> > "GenericError: Build already in progress (task 92381483)"
> > 
> > I tried doing "koji cancel 92381483" but that doesn't help.  Another 
> > attempt (task 92398262) failed the same way.
> > 
> > Is it possible to clear this state or do I just have to bump the 
> > release number and try again?
> > 
> > 
> > There was an outage and some other issues with koji in the last 24 hours. 
> > It may take a releng person to clear this. Could you open a ticket at 
> > https://pagure.io/releng/  for that to happen?
> 
> I opened #11055 https://pagure.io/releng/issue/11055

Yeah, these builds were in a weird state because they just finished
right when the unexpected kojipkgs01 outage happened this morning. ;( 

I managed to cancel them via the api and rebuilds should finish. 

If there's any other builds in this state please let me know. 

kevin



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

[Bug 2130626] Please branch and build perl-Pegex in epel9

[bugzilla]

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

Michel Alexandre Salim  changed:

   What|Removed |Added

 Depends On||2130631
 Depends On||2130632





Referenced Bugs:

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

[Bug 2130625] Please branch and build perl-Inline in epel9

[bugzilla]

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

Michel Alexandre Salim  changed:

   What|Removed |Added

 Depends On||2130628
 Depends On||2130630





Referenced Bugs:

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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel
 wrote:
>
> > On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
> >
> > On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:
> >>
> >> On 9/28/22 03:50, Tommy Nguyen wrote:
> >>> This change will only affect AMD, as the intel non-free drivers do not
> >>> depend on the changes. It is also unclear how this would affect nvidia.
> >>> There is barely any hardware video acceleration support for nouveau
> >>> anyway, for which you would install the proprietary driver. Further, as
> >>> NVIDIA does not expose a vaapi interface, you need to install third
> >>> party packages to get it to work with Firefox. So AFAICT this will
> >>> primarily (if not only) affect AMD users.
> >>
> >> So only everybody who specifically purchased a discrete GPU that works
> >> "out of the box" with Fedora?
> >
> > Well, we don't ship any userspace software that provides the necessary
> > support code to use those codecs anyway.
> >
> Firefox was able to use VA-API on Intel (at least - I don’t have Radeon 
> hardware to hand) to accelerate H.264 decode.
>

Intel doesn't use Gallium (Mesa) for VA-API. You need a separate
driver package for it, which we currently don't ship and the version
being reviewed will not have these codecs enabled.

> And we ship gstreamer1-vaapi which lets any GStreamer using application 
> (Totem, for example) use hardware acceleration.

Hmm, I forgot about that. FFmpeg doesn't have it because ffmpeg does
stupid things when the codec is available but doesn't work. GStreamer
is probably more intelligent about failing over.




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

Re: Self Introduction: Sébastien Le Roux

[Sébastien Le Roux]

Le 28/09/2022 à 20:13, Alexander Ploumistos a écrit :

Hello Sébastien,

Bienvenue !
Have you taken a look at these documents? They should help you get started.
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/

Merci !
Yes I did look into this documents today, followed the procedure, and 
submitted the bugzilla:


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

Hopefully this is not too bad for a start ;-)
About what I understand the first thing is to find a sponsor, and I hope 
what I provided is enough,
please let me know if you think that I missed something, I would correct 
it ASAP.

However I wasn't able to understand how to provide a 'koji' build,
I can build the package using 'fedpkg' (local) but not sure how both 
relate ...
I even watch a youtube video about 'koji' but it gives an overall idea 
of what it is
and no concrete example ... try to read the doc ... really confusing for 
a beginner.
But it pointed me towards 'copr' that I somehow completely missed before 
today,

so I could at least prepare a repo for atomes:

https://copr.fedorainfracloud.org/coprs/slook/Atomes/



Eventually, you might be interested in joining the Sci-Tech SIG, it's
more than likely that we maintain some package you might be using and
more hands are always welcome:
https://fedoraproject.org/wiki/Category:SciTech_SIG


Sure, but I would need a proper training before that ;-)


Feel free to ask for help with anything.
I'm looking forward to a 'dnf install atomes'!

So nice to read, and you have no idea how forward I look to it my-self !

All the best.

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail: sebastien.ler...@ipcms.unistra.fr
Webpage: https://www.ipcms.fr/sebastien-le-roux/
ATOMES project: https://atomes.ipcms.fr/
RINGS project: http://rings-code.sourceforge.net/
ISAACS project: http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: status update on "ostree native containers"

[Colin Walters]

On Tue, Sep 27, 2022, at 6:08 PM, Colin Walters wrote:
> We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer 
> in Fedora 36 and a lot has happened since then.

Also, I should mention that we're planning to use this in OpenShift, see
https://github.com/openshift/enhancements/blob/master/enhancements/ocp-coreos-layering/ocp-coreos-layering.md
and since
https://github.com/openshift/machine-config-operator/pull/3317
literally just merged we're on track to use this to update the operating system 
by default, and further exposing the full power of any container build system 
you choose (Dockerfile or whatever) to customize the OS in a very 
Kubernetes/container native way.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2130650] New: Please branch and build perl-boolean in epel9

[bugzilla]

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

Bug ID: 2130650
   Summary: Please branch and build perl-boolean in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-boolean
  Assignee: jples...@redhat.com
  Reporter: mic...@michel-slm.name
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org
Blocks: 2130632
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-boolean in epel9.

If you do not wish to maintain perl-boolean in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-boolean/addgroup
and grant it commit access, or collaborator access on epel* branches.

I would also be happy to be a co-maintainer (FAS: salimma);
please add me through https://src.fedoraproject.org/rpms/perl-boolean/adduser



Referenced Bugs:

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

Re: Self Introduction: Sébastien Le Roux

[Alexander Ploumistos]

Hello Sébastien,

Bienvenue !
Have you taken a look at these documents? They should help you get started.
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/

Eventually, you might be interested in joining the Sci-Tech SIG, it's
more than likely that we maintain some package you might be using and
more hands are always welcome:
https://fedoraproject.org/wiki/Category:SciTech_SIG

Feel free to ask for help with anything.
I'm looking forward to a 'dnf install atomes'!


Best regards


On Wed, Sep 28, 2022 at 5:30 PM Sébastien Le Roux
 wrote:
>
> Dear all,
> my name is Sébastien Le Roux, I just join the mailing list today.
> I am a computational material scientist,
> my work can be separated in two parts: studying the physico-chemical 
> properties
> of materials using computational/theoretical methods, and developing tools to 
> help
> scientists in this field of expertise.
> I am the author of several open source programs, so far none being packaged
> by Fedora, but I recently released a new software named 'Atomes' and I would
> like to propose Atomes for packaging, and then providing that it can be 
> packaged
> maintain it.
>
> Atomes is a Free (Open Source) cross-platform toolbox developed to analyze,
> to visualize and to create/edit three-dimensional atomistic models.
> Among the possibilities offered by Atomes:
>
> Analysis of 3D atomistic model: neutron and x-rays diffraction, rings 
> statistics, chain statistics, bond order, MSD ...
> Visualization: measures, coordination polyhedras, advanced coloring, advanced 
> design
> Edition: molecular library, crystal builder, cell edition, surface creation 
> and passivation ...
> Molecular Dynamics input preparation systems:
>
> Classical MD: DLPOLY and LAMMPS
> ab-initio MD: CPMD and CP2K
> QM-MM MD: CPMD and CP2K
>
>
> More info about me here: https://www.ipcms.fr/sebastien-le-roux/
> More information about Atomes here: https://atomes.ipcms.fr/
>
> So hello world ;-)
>
> Best regards.
>
> Sébastien Le Roux
>
> PS: using Fedora since FC2
>
> --
> ===
> Dr. Sébastien Le Roux
> Ingénieur de Recherche CNRS
> Institut de Physique et Chimie des Matériaux de Strasbourg
> Département des Matériaux Organiques
> 23, rue du Loess
> BP 43
> F-67034 Strasbourg Cedex 2, France
> E-mail: sebastien.ler...@ipcms.unistra.fr
> Webpage: https://www.ipcms.fr/sebastien-le-roux/
> ATOMES project: https://atomes.ipcms.fr/
> RINGS project: http://rings-code.sourceforge.net/
> ISAACS project: http://isaacs.sourceforge.net/
> Fax:   +33 3 88 10 72 46
> Phone: +33 3 88 10 71 58
> ===
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2130616] Please branch and build perl-Inline-C in epel9

[bugzilla]

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

Michel Alexandre Salim  changed:

   What|Removed |Added

 Depends On||2130625
 Depends On||2130626

Pasi Karkkainen  changed:

   What|Removed |Added

 CC||pa...@iki.fi





Referenced Bugs:

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

[Bug 2130631] Please branch and build perl-XXX in epel9

[bugzilla]

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

Michel Alexandre Salim  changed:

   What|Removed |Added

 Depends On||2130633
   Doc Type|--- |If docs needed, set a value
 Depends On||2130632





Referenced Bugs:

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

[Bug 2130631] New: Please branch and build perl-XXX in epel9

[bugzilla]

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

Bug ID: 2130631
   Summary: Please branch and build perl-XXX in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-XXX
  Assignee: jples...@redhat.com
  Reporter: mic...@michel-slm.name
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2130626
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-XXX in epel9.

If you do not wish to maintain perl-XXX in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-XXX/addgroup
and grant it commit access, or collaborator access on epel* branches.

I would also be happy to be a co-maintainer (FAS: salimma);
please add me through https://src.fedoraproject.org/rpms/perl-XXX/adduser



Referenced Bugs:

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

[Bug 2130630] New: Please branch and build perl-TestML in epel9

[bugzilla]

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

Bug ID: 2130630
   Summary: Please branch and build perl-TestML in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-TestML
  Assignee: ppi...@redhat.com
  Reporter: mic...@michel-slm.name
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2130625
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-TestML in epel9.

If you do not wish to maintain perl-TestML in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-TestML/addgroup
and grant it commit access, or collaborator access on epel* branches.

I would also be happy to be a co-maintainer (FAS: salimma);
please add me through https://src.fedoraproject.org/rpms/perl-TestML/adduser



Referenced Bugs:

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

[Bug 2130628] New: Please branch and build perl-Inline-Files in epel9

[bugzilla]

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

Bug ID: 2130628
   Summary: Please branch and build perl-Inline-Files in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Inline-Files
  Assignee: jples...@redhat.com
  Reporter: mic...@michel-slm.name
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2130625
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Inline-Files in epel9.

If you do not wish to maintain perl-Inline-Files in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-Inline-Files/addgroup
and grant it commit access, or collaborator access on epel* branches.

I would also be happy to be a co-maintainer (FAS: salimma);
please add me through
https://src.fedoraproject.org/rpms/perl-Inline-Files/adduser



Referenced Bugs:

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

Re: Self Introduction: Sébastien Le Roux

[Sébastien Le Roux]

Le 28/09/2022 à 19:32, Renich Bon Ćirić a écrit :

On Wed, 2022-09-28 at 17:29 +0200, Sébastien Le Roux wrote:

Dear all,
my name is Sébastien Le Roux, I just join the mailing list today.
I am a computational material scientist,

Hello! 0/

Welcome to Fedora's Devel ;D


I am the author of several open source programs, so far none being packaged
by Fedora, but I recently released a new software named 'Atomes' and I
would like to propose Atomes for packaging, and then providing that it can be
packaged maintain it.

Seems pretty cool. The video rocks. Couldn't find build instructions though...


Hello,
and thank you all for the welcome ;-)

Not sure what you did to build it, did you download the sources from the 
website ?

If you download the sources here: https://github.com/Slookeur/Atomes
then the Makefile is a home cooked file,  and make can take two targets:

'make atomes' -> normal version
'make debug' -> all kind of debug flags

And I will provide build instructions on the Github repo.

With the sources used to build the RPMs:

https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes-1.1.5.tar.gz

then './configure' followed by 'make' works just fine.

I will be happy to help if you provide a little bit more info ;-)

Sébastien

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail: sebastien.ler...@ipcms.unistra.fr
Webpage: https://www.ipcms.fr/sebastien-le-roux/
ATOMES project: https://atomes.ipcms.fr/
RINGS project: http://rings-code.sourceforge.net/
ISAACS project: http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2130626] New: Please branch and build perl-Pegex in epel9

[bugzilla]

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

Bug ID: 2130626
   Summary: Please branch and build perl-Pegex in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Pegex
  Assignee: g...@zimt.uni-siegen.de
  Reporter: mic...@michel-slm.name
QA Contact: extras...@fedoraproject.org
CC: g...@zimt.uni-siegen.de,
perl-devel@lists.fedoraproject.org
Blocks: 2130616
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Pegex in epel9.

If you do not wish to maintain perl-Pegex in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-Pegex/addgroup
and grant it commit access, or collaborator access on epel* branches.

I would also be happy to be a co-maintainer (FAS: salimma);
please add me through https://src.fedoraproject.org/rpms/perl-Pegex/adduser



Referenced Bugs:

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

[Bug 2130625] New: Please branch and build perl-Inline in epel9

[bugzilla]

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

Bug ID: 2130625
   Summary: Please branch and build perl-Inline in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Inline
  Assignee: jples...@redhat.com
  Reporter: mic...@michel-slm.name
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
Blocks: 2130616
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Inline in epel9.

If you do not wish to maintain perl-Inline in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-Inline/addgroup
and grant it commit access, or collaborator access on epel* branches.

I would also be happy to be a co-maintainer (FAS: salimma);
please add me through https://src.fedoraproject.org/rpms/perl-Inline/adduser



Referenced Bugs:

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

[Bug 2130616] Please branch and build perl-Inline-C in epel9

[bugzilla]

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

Michel Alexandre Salim  changed:

   What|Removed |Added

 CC||mic...@michel-slm.name



--- Comment #1 from Michel Alexandre Salim  ---
Created attachment 1914888
  --> https://bugzilla.redhat.com/attachment.cgi?id=1914888=edit
list of missing dependencies


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
> 
> On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:
>> 
>> On 9/28/22 03:50, Tommy Nguyen wrote:
>>> This change will only affect AMD, as the intel non-free drivers do not
>>> depend on the changes. It is also unclear how this would affect nvidia.
>>> There is barely any hardware video acceleration support for nouveau
>>> anyway, for which you would install the proprietary driver. Further, as
>>> NVIDIA does not expose a vaapi interface, you need to install third
>>> party packages to get it to work with Firefox. So AFAICT this will
>>> primarily (if not only) affect AMD users.
>> 
>> So only everybody who specifically purchased a discrete GPU that works
>> "out of the box" with Fedora?
> 
> Well, we don't ship any userspace software that provides the necessary
> support code to use those codecs anyway.
> 
Firefox was able to use VA-API on Intel (at least - I don’t have Radeon 
hardware to hand) to accelerate H.264 decode.

And we ship gstreamer1-vaapi which lets any GStreamer using application (Totem, 
for example) use hardware acceleration.

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

Fedora CoreOS Meeting Minutes 2022-09-28

[Dusty Mabe]

#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:30:46 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-28/fedora_coreos_meeting.2022-09-28-16.30.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:30:51)

* Action items from last meeting  (dustymabe, 16:35:40)
  * Looks like there were no action items from last meeting!
(dustymabe, 16:35:48)

* alias quay.io/fedora/fedora-coreos:stable to :latest in quay
  (dustymabe, 16:36:01)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1309
(dustymabe, 16:36:06)
  * AGREED: While this would provide benefit to new users who just want
to pull FCOS and see what's inside we could see some potential
problems with it and would like to defer implementing something like
this until our update story for CoreOS Layering
(https://github.com/coreos/fedora-coreos-tracker/issues/1263) is
figured out.  (dustymabe, 17:12:32)

* Document /boot requirements and constrains when installing/upgrading
  kernels  (dustymabe, 17:13:20)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1247
(dustymabe, 17:13:24)

* tracker: Fedora 37 changes considerations  (dustymabe, 17:30:45)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1222
(dustymabe, 17:30:50)
  * we don't ship minizip in FCOS, so this should be a noop for us
(dustymabe, 17:32:45)

* open floor  (dustymabe, 17:33:44)
  * there is a FCOS 37 test day happening tomorrow!  (dustymabe,
17:34:34)
  * LINK:

https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/message/4J5XDZN6L2UL5U4W5SN7RM5J7U65YAQK/
(dustymabe, 17:34:40)

Meeting ended at 17:40:39 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (112)
* jlebon (39)
* zodbot (19)
* travier (12)
* walters (12)
* jmarrero (4)
* jbrooks (2)
* ravanelli (2)
* aaradhak (2)
* Nemric (2)
* mnguyen_ (1)




Generated by `MeetBot`_ 0.4

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

Re: Self Introduction: Sébastien Le Roux

[Renich Bon Ćirić]

On Wed, 2022-09-28 at 17:29 +0200, Sébastien Le Roux wrote:
> Dear all,
> my name is Sébastien Le Roux, I just join the mailing list today.
> I am a computational material scientist,

Hello! 0/

Welcome to Fedora's Devel ;D

> I am the author of several open source programs, so far none being packaged
> by Fedora, but I recently released a new software named 'Atomes' and I 
> would like to propose Atomes for packaging, and then providing that it can be 
> packaged maintain it.

Seems pretty cool. The video rocks. Couldn't find build instructions though... 

I noticed the makefile and ran make. Here's what I got (after installing OpenMP)

...
gfortran  -DOPENMP -fopenmp  -Isrc/ -Isrc/lic/ -Isrc/gui/ -Isrc/workspace/ -
Isrc/project/ -Isrc/project/readers/ -Isrc/calc/ -Isrc/calc/dl_poly/ -
Isrc/calc/lammps/ -Isrc/calc/force_fields/ -Isrc/calc/cpmd/ -Isrc/calc/cp2k/ -
Isrc/curve/ -Isrc/opengl/win/ -Isrc/opengl/edit/ -Isrc/opengl/draw/ -
Isrc/opengl/ -I. -c src/fortran/pdb.F90 -o obj/pdb.o
gfortran  -DOPENMP -fopenmp  -Isrc/ -Isrc/lic/ -Isrc/gui/ -Isrc/workspace/ -
Isrc/project/ -Isrc/project/readers/ -Isrc/calc/ -Isrc/calc/dl_poly/ -
Isrc/calc/lammps/ -Isrc/calc/force_fields/ -Isrc/calc/cpmd/ -Isrc/calc/cp2k/ -
Isrc/curve/ -Isrc/opengl/win/ -Isrc/opengl/edit/ -Isrc/opengl/draw/ -
Isrc/opengl/ -I. -c src/fortran/prepdata.F90 -o obj/prepdata.o
src/fortran/prepdata.F90:322:91:

  322 |  "If this is a bug please report it
to"//CHAR(0), PACKAGE_BUGREPORT//CHAR(0))
  |
1
Error: Symbol ‘package_bugreport’ at (1) has no IMPLICIT type
make: *** [Makefile:591: obj/prepdata.o] Error 1

Any ideas?

Thanks. 

-- 
Renich Bon Ćirić 


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Julian Sikorski]

Am 28.09.22 um 15:27 schrieb Neal Gompa:

On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:


On 9/28/22 03:50, Tommy Nguyen wrote:

This change will only affect AMD, as the intel non-free drivers do not
depend on the changes. It is also unclear how this would affect nvidia.
There is barely any hardware video acceleration support for nouveau
anyway, for which you would install the proprietary driver. Further, as
NVIDIA does not expose a vaapi interface, you need to install third
party packages to get it to work with Firefox. So AFAICT this will
primarily (if not only) affect AMD users.


So only everybody who specifically purchased a discrete GPU that works
"out of the box" with Fedora?


Well, we don't ship any userspace software that provides the necessary
support code to use those codecs anyway.



Wasn't this being used by firefox?
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

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

[Bug 2130616] Please branch and build perl-Inline-C in epel9

[bugzilla]

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

Davide Cavalca  changed:

   What|Removed |Added

 Blocks||1914423 (EPELPackagersSIG),
   ||2121592
   Doc Type|--- |If docs needed, set a value





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1914423
[Bug 1914423] Tracker for epel-packagers-sig
https://bugzilla.redhat.com/show_bug.cgi?id=2121592
[Bug 2121592] Please branch and build public-inbox in epel9
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2130616
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2130616] New: Please branch and build perl-Inline-C in epel9

[bugzilla]

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

Bug ID: 2130616
   Summary: Please branch and build perl-Inline-C in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Inline-C
  Assignee: ppi...@redhat.com
  Reporter: dcava...@fb.com
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Inline-C in epel9.

If you do not wish to maintain perl-Inline-C in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/perl-Inline-C/addgroup
and grant it commit access, or collaborator access on epel* branches.


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

Re: Self Introduction: Sébastien Le Roux

[Erol Keskin]

Welcome Sébastien :)

On Wed, 28 Sept 2022 at 18:30, Sébastien Le Roux <
sebastien.ler...@ipcms.unistra.fr> wrote:

> Dear all,
> my name is Sébastien Le Roux, I just join the mailing list today.
> I am a computational material scientist,
> my work can be separated in two parts: studying the physico-chemical
> properties
> of materials using computational/theoretical methods, and developing tools
> to help
> scientists in this field of expertise.
> I am the author of several open source programs, so far none being
> packaged
> by Fedora, but I recently released a new software named 'Atomes' and I
> would
> like to propose Atomes for packaging, and then providing that it can be
> packaged
> maintain it.
>
> Atomes is a Free (Open Source) cross-platform toolbox developed to
> analyze,
> to visualize and to create/edit three-dimensional atomistic models.
> Among the possibilities offered by Atomes:
>
>- Analysis of 3D atomistic model: neutron and x-rays diffraction,
>rings statistics, chain statistics, bond order, MSD ...
>- Visualization: measures, coordination polyhedras, advanced coloring,
>advanced design
>- Edition: molecular library, crystal builder, cell edition, surface
>creation and passivation ...
>- Molecular Dynamics input preparation systems:
>   - Classical MD: DLPOLY
>    and LAMMPS
>   
>   - ab-initio MD: CPMD  and CP2K
>   
>   - QM-MM MD: CPMD  and CP2K
>   
>
>
> More info about me here: https://www.ipcms.fr/sebastien-le-roux/
> More information about Atomes here: https://atomes.ipcms.fr/
>
> So hello world ;-)
>
> Best regards.
>
> Sébastien Le Roux
>
> PS: using Fedora since FC2
>
> --
> ===
> Dr. Sébastien Le Roux
> Ingénieur de Recherche CNRS   
> Institut de Physique et Chimie des Matériaux de Strasbourg
> Département des Matériaux Organiques
> 23, rue du Loess
> BP 43
> F-67034 Strasbourg Cedex 2, France
> E-mail: sebastien.ler...@ipcms.unistra.fr
> Webpage: https://www.ipcms.fr/sebastien-le-roux/
> ATOMES project: https://atomes.ipcms.fr/
> RINGS project: http://rings-code.sourceforge.net/
> ISAACS project: http://isaacs.sourceforge.net/
> Fax:   +33 3 88 10 72 46
> Phone: +33 3 88 10 71 58
> ===
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Self Introduction: Sébastien Le Roux

[Sébastien Le Roux]

Dear all,
my name is Sébastien Le Roux, I just join the mailing list today.
I am a computational material scientist,
my work can be separated in two parts: studying the physico-chemical 
properties
of materials using computational/theoretical methods, and developing 
tools to help

scientists in this field of expertise.
I am the author of several open source programs, so far none being packaged
by Fedora, but I recently released a new software named 'Atomes' and I 
would
like to propose Atomes for packaging, and then providing that it can be 
packaged

maintain it.

Atomes is a Free (Open Source) cross-platform toolbox developed to analyze,
to visualize and to create/edit three-dimensional atomistic models.
Among the possibilities offered by Atomes:

 * Analysis of 3D atomistic model: neutron and x-rays diffraction,
   rings statistics, chain statistics, bond order, MSD ...
 * Visualization: measures, coordination polyhedras, advanced coloring,
   advanced design
 * Edition: molecular library, crystal builder, cell edition, surface
   creation and passivation ...
 * Molecular Dynamics input preparation systems:
 o Classical MD: DLPOLY
    and LAMMPS
   
 o ab-initio MD: CPMD  and CP2K
   
 o QM-MM MD: CPMD  and CP2K
   


More info about me here: https://www.ipcms.fr/sebastien-le-roux/
More information about Atomes here: https://atomes.ipcms.fr/

So hello world ;-)

Best regards.

Sébastien Le Roux

PS: using Fedora since FC2

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS 
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail:sebastien.ler...@ipcms.unistra.fr
Webpage:https://www.ipcms.fr/sebastien-le-roux/
ATOMES project:https://atomes.ipcms.fr/
RINGS project:http://rings-code.sourceforge.net/
ISAACS project:http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Demi Marie Obenour]

On 9/28/22 08:21, Neal Gompa wrote:
> On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  
> wrote:
>>
>> As Fedora users and contributors, we profit a lot from everything that 
>> RedHat provides to the Fedora project, be it infra, people-power or 
>> "leverage" (talking to vendors etc.). In turn, RedHat can expect a certain 
>> amount of understanding from "us" for their business interests, which 
>> include legal liabilities, of course.
>>
>> Understanding is helped greatly by communication, though. Legal answers such 
>> as "We can not" do not further this understanding, and "We can not and we 
>> can not tell you why" is not much better, but these are the typical answer 
>> we get, not even with a "sorry, but we can't". Obviously, these legal 
>> questions are difficult to explain, but it can't be true that each such case 
>> is under a "gag order". This non-transparency is orthogonal to our first F 
>> and hurts all efforts to increase the number of contributors.
>>
>> Now, I don't expect the communication issue to be resolved any time soon. 
>> Therefore it's important to work on the other major friction point: How 
>> difficult do we make it for users/contributors to get the missing bits that 
>> they need or can (because they are no distributors, in a different 
>> jurisdiction etc.)?
>>
>> rpmfusion/gstreamer is a prime example of how things can work flawlessly, 
>> and takes into account all interests.
>>
>> ffmpeg is a prime example of "in your face", of course, and I'm happy to 
>> read that it may get resolved.
>>
> 
> Let's talk for a moment here about this. I'm going to give you some
> "inside baseball" (or at least as much as I can). I can tell you up
> front that ffmpeg in Fedora is *entirely* my fault.
> 
> I spent many years tirelessly trying to come up with a solution to
> bring FFmpeg into Fedora. It started from the moment we got approval
> to introduce MPEG1 and MPEG2 codecs into Fedora. I cannot overstate
> how much back-and-forth with Red Hat Legal it took to figure it out.
> Over the last few years, more and more codecs got gradually approved,
> until we got to a point that enough codecs were approved that it made
> sense to finally produce a package to introduce. I had been trying to
> come up with a stripped FFmpeg source tree to deliver and was not
> succeeding until Andreas Scheider came up with the scripts to do it
> properly. That breakthrough allowed us to bring FFmpeg into Fedora as
> ffmpeg-free.
> 
> It was my choice to be quiet about its introduction, because I was
> being verbally and emotionally abused by other community members over
> it and I didn't want to invite more by making a big announcement like
> we did for mp3. At one point, I got so stressed over it that I became
> physically ill for weeks.
> 
> Do I regret this work? No. I still firmly believe this is going to
> improve the usefulness of baseline Fedora and expand the pressure to
> improve and prioritize Free Software in the Linux space. Do I want to
> do something like this again? I don't know. It really sucked and in
> the end all I got was hate for it. I want to make Fedora the best
> Linux distribution out there, but I also don't want to create a
> situation where all Fedora users and contributors are in legal
> jeopardy.
> 
>> The other big issue are our hobbled sources: We cannot store some original 
>> sources in the look-aside cache, obviously. But packages such as openssl do 
>> not even specify a hash nor an url for the un-hobbled sources. This makes it 
>> unncessarily difficult to verify that our openssl package has indeed been 
>> built against against the hobbled version of the original sources - for a 
>> package like openssl this really is a trust issue (and might even violate 
>> our packaging guidelines, but I'm not a lawyer...).
>>
> 
> I'm (personally, though IANAL) of the opinion that the hobbling of
> crypto libraries is probably no longer necessary and can be retired
> entirely. The method of producing the stripped sources is
> reproducible, so from our guidelines perspective, it's fine. But I do
> think it's probably obsolete, and I hope Red Hat Legal concurs.
> 
>> As a side effect, it makes it unnecesarily difficult to rebuild the package 
>> locally (though it does not effectively inhibit it either, of course; it is 
>> not an "effective measure" for that cause). I do understand that providing a 
>> functional link can be construed to be "redistribution", but in the context 
>> of a spec file, a comment really is a reference to the "source of the 
>> source", without which we cannot even claim to distribute the hobbled 
>> version legally (and without which we have no trust chain).
>>
>> Note that depending on the legal outcome mesa might have to go the hobbled 
>> route, too: simply disabling the codecs in %build does not change anything 
>> about redistributing the source.
> 
> That will depend on how much codec detail exists in the Mesa codebase.
> I would guess not enough to 

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Brian C. Lane]

On Sat, Sep 24, 2022 at 08:01:45PM -0500, Maxwell G via devel wrote:
> On Tue Sep 6, 2022, Ben Cotton wrote:
> > == Upgrade/compatibility impact ==
> > The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`,
> > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`,
> > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`.
> 
> I am worried about removing python3-dnf this early. As far as I can
> tell, the new Python libdnf bindings are very much not a drop in
> replacement. There are a fair amount of tools and scripts that depend on
> python3-dnf. The change proposal listed some of them, but Ansible's dnf

I'm worried about replacing it at all. I'd like to see them coexist
until we can get things rewritten, but it also says their databases are
separate which will possibly cause other issues so that's also likely to
lead to different problems.

I took a stab at converting my test-dnf-transaction script yesterday,
and the changes so far are not anywhere near compatible with dnf v4, and
I didn't manage to get it working yet.

https://github.com/bcl/test-dnf-transaction/pull/1

https://github.com/rpm-software-management/dnf5/issues/66

Brian

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

Re: Cython build failing on longintrepr.h not found

[Sandro]

On 27-09-2022 19:41, Miro Hrončok wrote:

On 27. 09. 22 17:55, Sandro wrote:

On 27-09-2022 08:17, Lumír Balhar wrote:

Make sure that the build does not use the pyx file from upstream. It
seems to me that the file generated by Cython is in the source tarball
(skmisc/loess/src/_loess.pyx) and I did not find any mention of use of
Cython in the build log. The file is probably generated by an older
version of Cython and that is causing you the problem.


Thank you, Lumír, for pointing me in the right direction.

The offending pregenerated C file was indeed in the source tarball along with a
precompiled library for good measure.

I was looking at the source on GitHub, which does not have
skmisc/loess/src/_loess.c. I'm sure that's what you meant. It's generated from
skmisc/loess/src/_loess.pyx

I have switched to the GitHub source tarball, which seems to be aimed at
developers, who like to build everything from scratch, and comes without
pregenerated files nor binaries.

However, I haven't been able to build the package, yet. It looks like the
tools/cythonize.py script, which is called from setup.py, generates output,
that throws off %pyproject_buildrequires:

No matching package to install: 'Processing'
No matching package to install: 'changed'

Is there a standard way of handling noisy scripts? Or am I just out of luck
using pyproject macros? Or, my bet, am I missing something?

https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/4875750/


Looking at the code, this happens because:

1) their setup.py uses subprocess





We might need a more robust way of redirecting all of stdout:

https://eli.thegreenplace.net/2015/redirecting-all-kinds-of-stdout-in-python/

As a temporary workaround, you might need to sed/patch the prints away or
convince upstream to print status information to stderr.


Thanks, Miro, I managed to get past the build stage and opened a PR 
upstream.


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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Blaise Pabon]

Hey, on a related note... I'm applying for a position as a
Open source license compliance analyst
(amazing!)
and I would be eager to learn more about how we do things in Fedora.
If I get the gig, I will even be able to contribute some time to the effort.

-Blaise

On Wed, Sep 28, 2022 at 8:49 AM Neal Gompa  wrote:

> On Wed, Sep 28, 2022 at 2:41 PM Michael J Gruber 
> wrote:
> >
> > > On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  fedoraproject.org wrote:
> > >
> > > Let's talk for a moment here about this. I'm going to give you some
> > > "inside baseball" (or at least as much as I can). I can tell you up
> > > front that ffmpeg in Fedora is *entirely* my fault.
> >
> > Thanks for the inside view. Please note that my post was not about
> "fault/blame" but rather about furthering understanding by communication.
> While I may have failed doing so, you succeeded, thanks ;)
>
> The nature of these issues means we cannot publicly discuss most of
> the details. On some level, you're just going to have to trust Matthew
> Miller on what he says on behalf of Red Hat. Red Hat lawyers aren't
> going to step into this thread or any other thread about this stuff
> and say anything meaningful. While we would like the information, it's
> legal suicide to give up that information, so they won't.
>
> It sucks, but it is what it is.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
LinkedIn   |  Quora
  |  Github

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

Re: FYI: livesys and livesys-late init.d files left over after Fedora installation

[Neal Gompa]

On Mon, Sep 19, 2022 at 7:34 PM Adam Williamson
 wrote:
>
> On Mon, 2022-09-19 at 12:53 -0400, Neal Gompa wrote:
> > On Mon, Sep 19, 2022 at 12:50 PM Brian C. Lane  wrote:
> > >
> > > On Mon, Sep 19, 2022 at 11:08:35AM +0200, Kamil Paral wrote:
> > > > On Mon, Sep 19, 2022 at 10:46 AM Marius Schwarz 
> > > > wrote:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > if Fedora 35 Liveimage is used to install Fedora, livesys and
> > > > > livesys-late initscripts are incorrectly copied onto the system
> > > > > or not deleted after they lost their functionality.
> > > > >
> > > >
> > > > That's not a bug, that's expected. They should be no-op on the installed
> > > > system. Nobody cared enough to come up with a better system yet. But now
> > > > that fedora-autofirstboot exists, I filed a ticket about it here:
> > > > https://pagure.io/fedora-autofirstboot/issue/3
> > >
> > > A while back there was an initial attempt at replacing the scripts with
> > > a proper package and systemd units:
> > >
> > > https://pagure.io/livesys-scripts
> > >
> >
> > I'd like to switch to this for F38 if we can. :)
>
> Then it'd probably be a good idea to file a Change...

Now that automatic persistent overlay support for dmsquash-live has
been submitted upstream[1], I probably can start working on a Change
proposal for this.

This was the missing feature for livesys-scripts to make the
transition possible. It will let us remove the need for
livecd-iso-to-disk entirely.

[1]: https://github.com/dracutdevs/dracut/pull/1991






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

Re: Carla-2.5.0 compilation fails with: error: static assertion failed: 64-bit large file support is not enabled

[Jerry James]

On Wed, Sep 28, 2022 at 8:09 AM Martin Gansser  wrote:
> I've just read that there have been problems with Koji for the last 24 hours, 
> so I'll wait until tomorrow and maybe the problems will be solved again.

Those problems appear to have been resolved.  I'm getting good builds now.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Carla-2.5.0 compilation fails with: error: static assertion failed: 64-bit large file support is not enabled

[Jerry James]

On Wed, Sep 28, 2022 at 7:57 AM Martin Gansser  wrote:
> when i compiling Carla-2.5.0 [1] the compilation fails on i686, ppc64le and 
> s390x platform, it fails with the follwoing error message [2].
>
> g++ CarlaEngineDummy.cpp -Wall -Wextra -pipe -DBUILDING_CARLA -DREAL_BUILD 
> -MD -MP -fno-common -fPIC -DPIC -DNDEBUG -O2 -ffast-math -fdata-sections 
> -ffunction-sections -DBUILDING_CARLA_NOOPT -fvisibility=hidden 
> -fno-gnu-unique -DHAVE_DGL -DHAVE_OPENGL -DDGL_OPENGL 
> -DDONT_SET_USING_DGL_NAMESPACE -DDGL_NAMESPACE=CarlaDGL 
> -DDGL_FILE_BROWSER_DISABLED -DDGL_NO_SHARED_RESOURCES -DHAVE_FLUIDSYNTH 
> -DHAVE_HYLIA -DHAVE_JACK -DHAVE_LIBLO -DHAVE_PYQT -DHAVE_SNDFILE -DHAVE_X11 
> -DUSING_JUCE -DJUCE_APP_CONFIG_HEADER='"AppConfig.h"' -DUSING_RTAUDIO 
> -DCARLA_LIB_EXT=\".so\" -std=gnu++11 -O2 -flto=auto -ffat-lto-objects 
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m32 -march=i686 
> -mtune=generic -msse2 -mfpmath=sse -mstackrealign 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -fvisibil
>  ity-inlines-hidden -fvisibility-inlines-hidden -I. -I.. -I../.. 
> -I../../includes -I../../modules -I../../utils-pthread -c -o 
> ../../../build/backend/Release/CarlaEngineDummy.cpp.o
> make[1]: Leaving directory 
> '/builddir/build/BUILD/Carla-2.5.0/source/backend/engine'
> make[1]: Entering directory 
> '/builddir/build/BUILD/Carla-2.5.0/source/modules/ysfx'
> Compiling sources/ysfx_utils.cpp
> make[1]: Leaving directory 
> '/builddir/build/BUILD/Carla-2.5.0/source/modules/ysfx'
> sources/ysfx_utils.cpp:40:29: error: static assertion failed: 64-bit large 
> file support is not enabled
>40 | static_assert(sizeof(off_t) == 8, "64-bit large file support is not 
> enabled");
>   |   ~~^~~~
> sources/ysfx_utils.cpp:40:29: note: the comparison reduces to '(4 == 8)'
> make[1]: *** [Makefile:175: 
> ../../../build/ysfx/Release/sources/ysfx_utils.cpp.o] Error 1
> make[1]: *** Waiting for unfinished jobs
>
> [1] https://src.fedoraproject.org/rpms/Carla/tree/master
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=92393472
>
> How can i solve this ?

For the i686 build, you may need to add -D_FILE_OFFSET_BITS=64 to the
build flags.  Or consider dropping support for i686 entirely:
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval.

Are you sure you're getting the same error on ppc64le and s390x?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How do I "unstick" koji?

[Steven A. Falco]

On 9/28/22 09:59 AM, Stephen Smoogen wrote:



On Wed, 28 Sept 2022 at 09:53, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

Yesterday, I had a build that failed.  The task ID is 92381483.

I tried rebuilding it today in task 92397327 but I get the error message:

"GenericError: Build already in progress (task 92381483)"

I tried doing "koji cancel 92381483" but that doesn't help.  Another 
attempt (task 92398262) failed the same way.

Is it possible to clear this state or do I just have to bump the release 
number and try again?


There was an outage and some other issues with koji in the last 24 hours. It may take 
a releng person to clear this. Could you open a ticket at https://pagure.io/releng/ 
 for that to happen?


I opened #11055 https://pagure.io/releng/issue/11055

Thanks for the suggestion.

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

Re: Carla-2.5.0 compilation fails with: error: static assertion failed: 64-bit large file support is not enabled

[Martin Gansser]

I've just read that there have been problems with Koji for the last 24 hours, 
so I'll wait until tomorrow and maybe the problems will be solved again.

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

Re: How do I "unstick" koji?

[Stephen Smoogen]

On Wed, 28 Sept 2022 at 09:53, Steven A. Falco 
wrote:

> Yesterday, I had a build that failed.  The task ID is 92381483.
>
> I tried rebuilding it today in task 92397327 but I get the error message:
>
> "GenericError: Build already in progress (task 92381483)"
>
> I tried doing "koji cancel 92381483" but that doesn't help.  Another
> attempt (task 92398262) failed the same way.
>
> Is it possible to clear this state or do I just have to bump the release
> number and try again?
>
>
There was an outage and some other issues with koji in the last 24 hours.
It may take a releng person to clear this. Could you open a ticket at
https://pagure.io/releng/ for that to happen?



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


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Carla-2.5.0 compilation fails with: error: static assertion failed: 64-bit large file support is not enabled

[Martin Gansser]

Hi,

when i compiling Carla-2.5.0 [1] the compilation fails on i686, ppc64le and 
s390x platform, it fails with the follwoing error message [2].

g++ CarlaEngineDummy.cpp -Wall -Wextra -pipe -DBUILDING_CARLA -DREAL_BUILD -MD 
-MP -fno-common -fPIC -DPIC -DNDEBUG -O2 -ffast-math -fdata-sections 
-ffunction-sections -DBUILDING_CARLA_NOOPT -fvisibility=hidden -fno-gnu-unique 
-DHAVE_DGL -DHAVE_OPENGL -DDGL_OPENGL -DDONT_SET_USING_DGL_NAMESPACE 
-DDGL_NAMESPACE=CarlaDGL -DDGL_FILE_BROWSER_DISABLED -DDGL_NO_SHARED_RESOURCES 
-DHAVE_FLUIDSYNTH -DHAVE_HYLIA -DHAVE_JACK -DHAVE_LIBLO -DHAVE_PYQT 
-DHAVE_SNDFILE -DHAVE_X11 -DUSING_JUCE -DJUCE_APP_CONFIG_HEADER='"AppConfig.h"' 
-DUSING_RTAUDIO -DCARLA_LIB_EXT=\".so\" -std=gnu++11 -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m32 -march=i686 -mtune=generic 
-msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection -fvisibil
 ity-inlines-hidden -fvisibility-inlines-hidden -I. -I.. -I../.. 
-I../../includes -I../../modules -I../../utils-pthread -c -o 
../../../build/backend/Release/CarlaEngineDummy.cpp.o
make[1]: Leaving directory 
'/builddir/build/BUILD/Carla-2.5.0/source/backend/engine'
make[1]: Entering directory 
'/builddir/build/BUILD/Carla-2.5.0/source/modules/ysfx'
Compiling sources/ysfx_utils.cpp
make[1]: Leaving directory 
'/builddir/build/BUILD/Carla-2.5.0/source/modules/ysfx'
sources/ysfx_utils.cpp:40:29: error: static assertion failed: 64-bit large file 
support is not enabled
   40 | static_assert(sizeof(off_t) == 8, "64-bit large file support is not 
enabled");
  |   ~~^~~~
sources/ysfx_utils.cpp:40:29: note: the comparison reduces to '(4 == 8)'
make[1]: *** [Makefile:175: 
../../../build/ysfx/Release/sources/ysfx_utils.cpp.o] Error 1
make[1]: *** Waiting for unfinished jobs

[1] https://src.fedoraproject.org/rpms/Carla/tree/master
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=92393472

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

Re: status update on "ostree native containers"

[Colin Walters]

On Wed, Sep 28, 2022, at 9:47 AM, Rahul Sundaram wrote:

> FYI, the command in that page doesn't appear to be working because 
> "latest" is the default tag if you don't specify one for docker and it 
> doesn't exist, so you have to append ":stable" or something like that.

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

How do I "unstick" koji?

[Steven A. Falco]

Yesterday, I had a build that failed.  The task ID is 92381483.

I tried rebuilding it today in task 92397327 but I get the error message:

"GenericError: Build already in progress (task 92381483)"

I tried doing "koji cancel 92381483" but that doesn't help.  Another attempt 
(task 92398262) failed the same way.

Is it possible to clear this state or do I just have to bump the release number 
and try again?

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

Re: status update on "ostree native containers"

[Rahul Sundaram]

Hi

On Tue, Sep 27, 2022 at 6:09 PM Colin Walters wrote:

> We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
> in Fedora 36 and a lot has happened since then.
>
> One of the biggest things is that rpm-ostree now knows how to
> intelligently generate reproducible "chunked" container images.
>
> I'll describe this by also highlighting another big change; Fedora CoreOS
> is now shipped as a properly manifest listed container image alongside the
> other Fedora images on quay.io:
> https://quay.io/repository/fedora/fedora-coreos


FYI, the command in that page doesn't appear to be working because "latest"
is the default tag if you don't specify one for docker and it doesn't
exist, so you have to append ":stable" or something like that.

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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Catanzaro]

On Wed, Sep 28 2022 at 06:49:42 AM +, Tommy Nguyen 
 wrote:

   With a single maintainer introducing a ffmpeg-free binary packages
   into Fedora, competing with our fully featured ffmpeg build, this
   leads to various conflicts and interactions issues. While one could
   admittedly rejoice from the ffmpeg introduction intro Fedora
   (enabling ffmpeg support for some fedora package lacking it), the
   method used to forcibly introduced an un-backed (by most RPM Fusion
   packager involved) package with uncertain features enabled, was
   perceived as unfriendly for the least. A determining argument for
   any "new eyes" is the very short time the Fedora review took
   compared with a fully backed 6 months Fedora feature review 
process.


Just for avoidance of doubt, getting ffmpeg into Fedora was a priority 
for the Workstation Working Group, and Neal was working in coordination 
with us on that. We want to provide as much multimedia in Fedora as we 
legally can without requiring that users resort to third-party 
repositories.


Michael

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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:
>
> On 9/28/22 03:50, Tommy Nguyen wrote:
> > This change will only affect AMD, as the intel non-free drivers do not
> > depend on the changes. It is also unclear how this would affect nvidia.
> > There is barely any hardware video acceleration support for nouveau
> > anyway, for which you would install the proprietary driver. Further, as
> > NVIDIA does not expose a vaapi interface, you need to install third
> > party packages to get it to work with Firefox. So AFAICT this will
> > primarily (if not only) affect AMD users.
>
> So only everybody who specifically purchased a discrete GPU that works
> "out of the box" with Fedora?

Well, we don't ship any userspace software that provides the necessary
support code to use those codecs anyway.


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Ian Pilcher]

On 9/28/22 03:50, Tommy Nguyen wrote:

This change will only affect AMD, as the intel non-free drivers do not
depend on the changes. It is also unclear how this would affect nvidia.
There is barely any hardware video acceleration support for nouveau
anyway, for which you would install the proprietary driver. Further, as
NVIDIA does not expose a vaapi interface, you need to install third
party packages to get it to work with Firefox. So AFAICT this will
primarily (if not only) affect AMD users.


So only everybody who specifically purchased a discrete GPU that works
"out of the box" with Fedora?

--

Google  Where SkyNet meets Idiocracy


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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Neal Gompa]

On Wed, Sep 28, 2022 at 2:41 PM Michael J Gruber  wrote:
>
> > On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber 
> >  >
> > Let's talk for a moment here about this. I'm going to give you some
> > "inside baseball" (or at least as much as I can). I can tell you up
> > front that ffmpeg in Fedora is *entirely* my fault.
>
> Thanks for the inside view. Please note that my post was not about 
> "fault/blame" but rather about furthering understanding by communication. 
> While I may have failed doing so, you succeeded, thanks ;)

The nature of these issues means we cannot publicly discuss most of
the details. On some level, you're just going to have to trust Matthew
Miller on what he says on behalf of Red Hat. Red Hat lawyers aren't
going to step into this thread or any other thread about this stuff
and say anything meaningful. While we would like the information, it's
legal suicide to give up that information, so they won't.

It sucks, but it is what it is.


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1b4c7ee66c   
knot-resolver-5.5.3-1.el7


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

apptainer-1.1.0-1.el7
dkms-3.0.7-1.el7
haproxy18-1.8.27-3.el7
mock-core-configs-36.13-1.el7

Details about builds:



 apptainer-1.1.0-1.el7 (FEDORA-EPEL-2022-f501a536dd)
 Application and environment virtualization

Update Information:

Update to 1.1.0    Update to upstream 1.1.0-rc.3    update to upstream
1.1.0-rc.2    Update to 1.1.0~rc.1

ChangeLog:

* Tue Sep 27 2022 Dave Dykstra  - 1.1.0
- Update to upstream 1.1.0.  Uncomment the requiring of fuse2fs on el7.
* Tue Sep  6 2022 Dave Dykstra  - 1.1.0-rc.3
- Update to upstream 1.1.0~rc.3.  Uncomment setting squashfuse_version and
  the requiring of fuse2fs on el7.
* Wed Aug 17 2022 Dave Dykstra  - 1.1.0~rc.2
- Update to upstream 1.1.0~rc.2.  Remove customizations put into
  1.1.0-rc.1 packaging except for f35 inclusion of golang source.
* Tue Aug  2 2022 Dave Dykstra  - 1.1.0~rc.1
- Update to upstream 1.1.0~rc.1
- Require fuse2fs package on el7
- Require fuse-overlayfs everywhere for cases that kernel overlayfs
  does not support 
- Add patch for 32-bit compilation
* Wed Jul  6 2022 Dave Dykstra  - 1.0.3
- Update to upstream 1.0.3
* Tue May 10 2022 Dave Dykstra  - 1.0.2
- Update to upstream 1.0.2
* Wed Mar 16 2022 Dave Dykstra  - 1.0.1
- Update to upstream 1.0.1
- Remove patch from pr 299, not needed anymore
* Thu Mar  3 2022 Dave Dykstra  - 1.0.0
- Initial release from upstream 1.0.0

References:

  [ 1 ] Bug #2130297 - apptainer-1.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2130297




 dkms-3.0.7-1.el7 (FEDORA-EPEL-2022-871a539ebd)
 Dynamic Kernel Module Support Framework

Update Information:

Update to bugfix release 3.0.7.

ChangeLog:

* Tue Sep 27 2022 Simone Caronni  - 3.0.7-1
- Update to 3.0.7.




 haproxy18-1.8.27-3.el7 (FEDORA-EPEL-2022-c55b6f81ff)
 HAProxy reverse proxy for high availability environments

Update Information:

  * Backport from 1.8.27-5: Add configuration directory and update systemd unit
file (#1943869)

ChangeLog:

* Wed Sep 28 2022 Robert Scheck  1.8.27-3
- Backport from 1.8.27-5: Add configuration directory and update
  systemd unit file (#1943869)

References:

  [ 1 ] Bug #1943869 - Provide e.g. /etc/haproxy/conf.d directory and use it in 
haproxy.service
https://bugzilla.redhat.com/show_bug.cgi?id=1943869




 mock-core-configs-36.13-1.el7 (FEDORA-EPEL-2022-aa41598a0e)
 Mock core config files basic chroots

Update Information:

- add openEuler 20.03 (yikunk...@gmail.com) - Adding support Oracle Linux 9 in
mock (a.sam...@gmail.com) - change license to spdx (msu...@redhat.com) - Update
to AlmaLinux Quay.io repo (srb...@gmail.com) - Add openEuler 22.03 support
(yikunk...@gmail.com) - Do not expose the EPEL Koji repo when we are on EPEL
Next (m...@hroncok.cz) - EL7 yum can't even install the EL9 chroot
(prais...@redhat.com)

ChangeLog:

* Tue Sep 27 2022 Pavel Raiskup  36.13-1
- add openEuler 20.03 (yikunk...@gmail.com)
- Adding support Oracle Linux 9 in mock (a.sam...@gmail.com)
- change license to spdx (msu...@redhat.com)
- Update to AlmaLinux Quay.io repo (srb...@gmail.com)
- Add openEuler 22.03 support (yikunk...@gmail.com)
- Do not expose the EPEL Koji repo when we are on EPEL Next (m...@hroncok.cz)
- EL7 yum can't even install the EL9 chroot (prais...@redhat.com)

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

> On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  wrote:
> 
> Let's talk for a moment here about this. I'm going to give you some
> "inside baseball" (or at least as much as I can). I can tell you up
> front that ffmpeg in Fedora is *entirely* my fault.

Thanks for the inside view. Please note that my post was not about 
"fault/blame" but rather about furthering understanding by communication. While 
I may have failed doing so, you succeeded, thanks ;)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

> As one of the people that has previously generated one of the hobbled
> tarballs you consider a potential trust issue: The hobbled tarball is the
> upstream tarball for the particular release we ship after we extract it, run
> ./hobble-openssl (which you’ll find in the package) and repack it.
> 
> Feel free to replicate this process and compare the output to check that we
> haven’t smuggled anything else into it.

This is not about personal trust - personally, I don't have any problems 
trusting our packagers.

It is about the reproducible chain that we usually have: you can `spectool -gf` 
the original sources and compare checksums etc.


> Note that we’re discussing moving openssl to a src-git approach, so it
> should eventually become much easier to see the relation between upstream
> code and our downstream copy.

I'm curious t see what happens when we have src-git on Fedora infrastructure, 
which we should have. Will our src-git carry ("distribute") unhobbled sources?

> Are you suggesting we add a comment that contains the URL to the upstream
> tarball? I don’t think we’d have a problem with that. However, we probably

Yes, for example.

> wouldn’t want to update it for every rebase, and a comment with a %{version}
> macro might not be very helpful either.

"%%" so that rpmlint does not complain. Yes, why not? I'm not suggesting 
something that could be construed as "distributing via link"; otherwise 
defining an %origsource and bconding build switches/hobble-related patches 
would be perfect, but maybe too close to "encouraging".

> I also don’t agree that not including the URL to the upstream tarball makes
> a local rebuild unnecessarily difficult. If you replace the Source in the
> specfile with the upstream tarball URL and remove ec_curve.c and octets.c,
> the package should build just fine. How would you prefer we simplified this?

I know how to find the URL etc. (and so far don't know, but may have to in the 
future). I just think we can make it easier and more transparent (see above), 
and besides the technical aspect this also communicates "we hear you and do 
what we can" much better.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20220928.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220927.n.0
NEW: Fedora-Rawhide-20220928.n.0

= SUMMARY =
Added images:0
Dropped images:  11
Added packages:  4
Dropped packages:14
Upgraded packages:   74
Downgraded packages: 0

Size of added packages:  23.03 MiB
Size of dropped packages:18.25 MiB
Size of upgraded packages:   4.69 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20220927.n.0.ppc64le.tar.xz
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20220927.n.0.s390x.qcow2
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20220927.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20220927.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220927.n.0.s390x.qcow2
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20220927.n.0.s390x.tar.xz
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20220927.n.0.aarch64.raw.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20220927.n.0.iso
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20220927.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20220927.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220927.n.0.s390x.raw.xz

= ADDED PACKAGES =
Package: golang-sr-emersion-gqlclient-0-0.1.20220927gite4b2ae1.fc38
Summary: A GraphQL client and code generator for Go
RPMs:golang-sr-emersion-gqlclient golang-sr-emersion-gqlclient-devel
Size:12.76 MiB

Package: hut-0.2.0-2.fc38
Summary: A CLI tool for Sourcehut
RPMs:golang-sr-emersion-hut-devel hut
Size:10.06 MiB

Package: perl-Alien-CFITSIO-4.1.0.5-1.fc38
Summary: Build and Install the CFITSIO library
RPMs:perl-Alien-CFITSIO
Size:126.46 KiB

Package: python-azure-mgmt-dashboard-1.0.0-1.fc38
Summary: Microsoft Azure Dashboard Management Client Library for Python
RPMs:python3-azure-mgmt-dashboard
Size:85.30 KiB


= DROPPED PACKAGES =
Package: commissaire-client-0.0.6-19.fc37
Summary: CLI for Commissaire
RPMs:commissaire-client
Size:61.21 KiB

Package: erlang-esip-1.0.37-4.fc36
Summary: ProcessOne SIP server component in Erlang
RPMs:erlang-esip
Size:762.31 KiB

Package: erlang-jiffy-1.0.5-4.fc36
Summary: Erlang JSON parser
RPMs:erlang-jiffy
Size:185.10 KiB

Package: erlang-riak_ensemble-3.0.10-1.fc37
Summary: Multi-Paxos framework in Erlang
RPMs:erlang-riak_ensemble
Size:2.05 MiB

Package: erlang-xmpp-1.4.9-4.fc36
Summary: Erlang/Elixir XMPP parsing and serialization library
RPMs:erlang-xmpp
Size:7.59 MiB

Package: python-august-0.25.2-7.fc37
Summary: Python API for August Smart Lock and Doorbell
RPMs:python3-august
Size:65.02 KiB

Package: python-calligrabot-1.0.0-2.fc36
Summary: A robosignatory driver for the CentOS Stream signing service
RPMs:python3-calligrabot
Size:25.51 KiB

Package: python-cu2qu-1.6.7-6.fc36
Summary: Cubic-to-quadratic bezier curve conversion
RPMs:python3-cu2qu
Size:487.49 KiB

Package: python-evic-0.1-0.27.git20161101.176cf0b.fc36
Summary: USB programmer for devices based on the Joyetech Evic VTC Mini
RPMs:python3-evic
Size:51.90 KiB

Package: python-jaydebeapi-1.2.3-8.fc37
Summary: Bridge from JDBC database drivers to Python DB-API
RPMs:python3-jaydebeapi
Size:44.90 KiB

Package: python-sendgrid-3.6.5-17.fc35
Summary: SendGrid library for Python
RPMs:python-sendgrid-examples python3-sendgrid
Size:69.97 KiB

Package: rubygem-font-awesome-rails-4.7.0.8-2.fc37
Summary: An asset gemification of the font-awesome icon font library
RPMs:rubygem-font-awesome-rails rubygem-font-awesome-rails-doc
Size:675.53 KiB

Package: rubygem-prawn-manual_builder-0.3.1-6.fc37
Summary: A tool for writing manuals for Prawn and Prawn accessories
RPMs:rubygem-prawn-manual_builder rubygem-prawn-manual_builder-doc
Size:2.89 MiB

Package: rust-just-0.9.8-4.fc37
Summary: A command runner
RPMs:just rust-just+default-devel rust-just-devel
Size:3.34 MiB


= UPGRADED PACKAGES =
Package:  Falcon-0.9.6.8-25.fc38
Old package:  Falcon-0.9.6.8-24.fc36
Summary:  The Falcon Programming Language
RPMs: Falcon Falcon-devel Falcon-doc
Size: 10.80 MiB
Size change:  26.74 KiB
Changelog:
  * Wed Jul 20 2022 Fedora Release Engineering  - 
0.9.6.8-25
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild


Package:  ImageMagick-1:6.9.12.64-1.fc38
Old package:  ImageMagick-1:6.9.12.63-1.fc38

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Simo Sorce]

On Wed, 2022-09-28 at 14:21 +0200, Neal Gompa wrote:
> I'm (personally, though IANAL) of the opinion that the hobbling of
> crypto libraries is probably no longer necessary and can be retired
> entirely. The method of producing the stripped sources is
> reproducible, so from our guidelines perspective, it's fine. But I do
> think it's probably obsolete, and I hope Red Hat Legal concurs.

Just FYI,
we are working towards removing hobbling and replacing with compilation
switches that clearly and permanently disable questionable material in
the binaries.

It is just not a very high priority item because the hobbling works
fine but we will get there, and hopefully we'll get to a point where we
do not need to disable as much stuff either.

But no promises right now, resources are what they are and we are not
aware of actual issues caused by hobbling.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Neal Gompa]

On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  wrote:
>
> As Fedora users and contributors, we profit a lot from everything that RedHat 
> provides to the Fedora project, be it infra, people-power or "leverage" 
> (talking to vendors etc.). In turn, RedHat can expect a certain amount of 
> understanding from "us" for their business interests, which include legal 
> liabilities, of course.
>
> Understanding is helped greatly by communication, though. Legal answers such 
> as "We can not" do not further this understanding, and "We can not and we can 
> not tell you why" is not much better, but these are the typical answer we 
> get, not even with a "sorry, but we can't". Obviously, these legal questions 
> are difficult to explain, but it can't be true that each such case is under a 
> "gag order". This non-transparency is orthogonal to our first F and hurts all 
> efforts to increase the number of contributors.
>
> Now, I don't expect the communication issue to be resolved any time soon. 
> Therefore it's important to work on the other major friction point: How 
> difficult do we make it for users/contributors to get the missing bits that 
> they need or can (because they are no distributors, in a different 
> jurisdiction etc.)?
>
> rpmfusion/gstreamer is a prime example of how things can work flawlessly, and 
> takes into account all interests.
>
> ffmpeg is a prime example of "in your face", of course, and I'm happy to read 
> that it may get resolved.
>

Let's talk for a moment here about this. I'm going to give you some
"inside baseball" (or at least as much as I can). I can tell you up
front that ffmpeg in Fedora is *entirely* my fault.

I spent many years tirelessly trying to come up with a solution to
bring FFmpeg into Fedora. It started from the moment we got approval
to introduce MPEG1 and MPEG2 codecs into Fedora. I cannot overstate
how much back-and-forth with Red Hat Legal it took to figure it out.
Over the last few years, more and more codecs got gradually approved,
until we got to a point that enough codecs were approved that it made
sense to finally produce a package to introduce. I had been trying to
come up with a stripped FFmpeg source tree to deliver and was not
succeeding until Andreas Scheider came up with the scripts to do it
properly. That breakthrough allowed us to bring FFmpeg into Fedora as
ffmpeg-free.

It was my choice to be quiet about its introduction, because I was
being verbally and emotionally abused by other community members over
it and I didn't want to invite more by making a big announcement like
we did for mp3. At one point, I got so stressed over it that I became
physically ill for weeks.

Do I regret this work? No. I still firmly believe this is going to
improve the usefulness of baseline Fedora and expand the pressure to
improve and prioritize Free Software in the Linux space. Do I want to
do something like this again? I don't know. It really sucked and in
the end all I got was hate for it. I want to make Fedora the best
Linux distribution out there, but I also don't want to create a
situation where all Fedora users and contributors are in legal
jeopardy.

> The other big issue are our hobbled sources: We cannot store some original 
> sources in the look-aside cache, obviously. But packages such as openssl do 
> not even specify a hash nor an url for the un-hobbled sources. This makes it 
> unncessarily difficult to verify that our openssl package has indeed been 
> built against against the hobbled version of the original sources - for a 
> package like openssl this really is a trust issue (and might even violate our 
> packaging guidelines, but I'm not a lawyer...).
>

I'm (personally, though IANAL) of the opinion that the hobbling of
crypto libraries is probably no longer necessary and can be retired
entirely. The method of producing the stripped sources is
reproducible, so from our guidelines perspective, it's fine. But I do
think it's probably obsolete, and I hope Red Hat Legal concurs.

> As a side effect, it makes it unnecesarily difficult to rebuild the package 
> locally (though it does not effectively inhibit it either, of course; it is 
> not an "effective measure" for that cause). I do understand that providing a 
> functional link can be construed to be "redistribution", but in the context 
> of a spec file, a comment really is a reference to the "source of the 
> source", without which we cannot even claim to distribute the hobbled version 
> legally (and without which we have no trust chain).
>
> Note that depending on the legal outcome mesa might have to go the hobbled 
> route, too: simply disabling the codecs in %build does not change anything 
> about redistributing the source.

That will depend on how much codec detail exists in the Mesa codebase.
I would guess not enough to matter, but IANAL.

Here's something of a drop-kick for you though: those
hardware-accelerated codecs that Dave Airlie disabled from Mesa
weren't being used by *anything* 

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Clemens Lang]

Hi,

Michael J Gruber  wrote:


Understanding is helped greatly by communication, though. Legal answers
such as "We can not" do not further this understanding, and "We can not
and we can not tell you why" is not much better, but these are the typical
answer we get, not even with a "sorry, but we can't". Obviously, these
legal questions are difficult to explain, but it can't be true that each
such case is under a "gag order”.


A lawyer at a previous employer told me that explanations of such decisions
can be used against you in court. Presumably, this also applies here.



The other big issue are our hobbled sources: We cannot store some original
sources in the look-aside cache, obviously. But packages such as openssl
do not even specify a hash nor an url for the un-hobbled sources. This
makes it unncessarily difficult to verify that our openssl package has
indeed been built against against the hobbled version of the original
sources - for a package like openssl this really is a trust issue (and
might even violate our packaging guidelines, but I'm not a lawyer…).


As one of the people that has previously generated one of the hobbled
tarballs you consider a potential trust issue: The hobbled tarball is the
upstream tarball for the particular release we ship after we extract it, run
./hobble-openssl (which you’ll find in the package) and repack it.

Feel free to replicate this process and compare the output to check that we
haven’t smuggled anything else into it.

Note that we’re discussing moving openssl to a src-git approach, so it
should eventually become much easier to see the relation between upstream
code and our downstream copy.



As a side effect, it makes it unnecesarily difficult to rebuild the
package locally (though it does not effectively inhibit it either, of
course; it is not an "effective measure" for that cause). I do understand
that providing a functional link can be construed to be “redistribution”,
but in the context of a spec file, a comment really is a reference to the
"source of the source", without which we cannot even claim to distribute
the hobbled version legally (and without which we have no trust chain).


Are you suggesting we add a comment that contains the URL to the upstream
tarball? I don’t think we’d have a problem with that. However, we probably
wouldn’t want to update it for every rebase, and a comment with a %{version}
macro might not be very helpful either.

I also don’t agree that not including the URL to the upstream tarball makes
a local rebuild unnecessarily difficult. If you replace the Source in the
specfile with the upstream tarball URL and remove ec_curve.c and octets.c,
the package should build just fine. How would you prefer we simplified this?

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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

> Note that depending on the legal outcome mesa might have to go the hobbled 
> route, too:
> simply disabling the codecs in %build does not change anything about 
> redistributing the
> source.

... or may not, if it's only about the hardware implementation, in which case I 
would suggest merely commenting out the switches in spec (or bcond'ing) them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

As Fedora users and contributors, we profit a lot from everything that RedHat 
provides to the Fedora project, be it infra, people-power or "leverage" 
(talking to vendors etc.). In turn, RedHat can expect a certain amount of 
understanding from "us" for their business interests, which include legal 
liabilities, of course.

Understanding is helped greatly by communication, though. Legal answers such as 
"We can not" do not further this understanding, and "We can not and we can not 
tell you why" is not much better, but these are the typical answer we get, not 
even with a "sorry, but we can't". Obviously, these legal questions are 
difficult to explain, but it can't be true that each such case is under a "gag 
order". This non-transparency is orthogonal to our first F and hurts all 
efforts to increase the number of contributors.

Now, I don't expect the communication issue to be resolved any time soon. 
Therefore it's important to work on the other major friction point: How 
difficult do we make it for users/contributors to get the missing bits that 
they need or can (because they are no distributors, in a different jurisdiction 
etc.)?

rpmfusion/gstreamer is a prime example of how things can work flawlessly, and 
takes into account all interests.

ffmpeg is a prime example of "in your face", of course, and I'm happy to read 
that it may get resolved.

The other big issue are our hobbled sources: We cannot store some original 
sources in the look-aside cache, obviously. But packages such as openssl do not 
even specify a hash nor an url for the un-hobbled sources. This makes it 
unncessarily difficult to verify that our openssl package has indeed been built 
against against the hobbled version of the original sources - for a package 
like openssl this really is a trust issue (and might even violate our packaging 
guidelines, but I'm not a lawyer...).

As a side effect, it makes it unnecesarily difficult to rebuild the package 
locally (though it does not effectively inhibit it either, of course; it is not 
an "effective measure" for that cause). I do understand that providing a 
functional link can be construed to be "redistribution", but in the context of 
a spec file, a comment really is a reference to the "source of the source", 
without which we cannot even claim to distribute the hobbled version legally 
(and without which we have no trust chain).

Note that depending on the legal outcome mesa might have to go the hobbled 
route, too: simply disabling the codecs in %build does not change anything 
about redistributing the source.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Wed, 2022-09-28 at 15:11 +0800, yanqiy...@gmail.com wrote:
> I would be very SAD if this change lands on my computer. While
> instead
> of arguing with some legal puzzles, I think those parts can be
> provided
> by seperate package (and maybe packaged in rpmfusion?) like intel-
> media-driver. 
> 
> Is there any build-to-build ABI match requirement between the VAAPI
> implementation and mesa itself?
> 
> 
> 在 2022-09-27星期二的 20:01 +0200，Frantisek Zatloukal写道：
> > Hi,
> > 
> > since this mesa change
> > ( 
> > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6
> > ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa
> > package
> > lost support for vaapi accelerated encoding and decoding of h264,
> > h265 and decoding of vc1
> > ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > 
> > It seems like a big regression from F36 for users with GPUs with
> > open
> > source drivers (mainly AMD, maybe nVidia/other non x86...), that
> > affects common use-cases of Fedora Workstation, like watching
> > videos,
> > in-house game streaming, attending online meetings and many more.
> > 
> > I'd like to ask:
> > - Can somebody elaborate on reasons to change something that was
> > working in Fedora for some time already?
> > - Is there any short/mid/long term plan to improve the situation?
> > - Would it be possible to provide vaapi support at least as an
> > rpmfusion addon to alleviate the fallout in the short term?
> > 
> > Thanks!
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

This change will only affect AMD, as the intel non-free drivers do not
depend on the changes. It is also unclear how this would affect nvidia.
There is barely any hardware video acceleration support for nouveau
anyway, for which you would install the proprietary driver. Further, as
NVIDIA does not expose a vaapi interface, you need to install third
party packages to get it to work with Firefox. So AFAICT this will
primarily (if not only) affect AMD users.



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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:50 AM Tommy Nguyen  wrote:
>
>
>
> On Wed, 2022-09-28 at 08:40 +0200, Neal Gompa wrote:
> > On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen 
> > wrote:
> > >
> > > On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
> > > > As one of the ffmpeg maintainers, I'm actively working on
> > > > workarounds
> > > > for the problem. And I've talked to my counterparts in RPM Fusion
> > > > about the issue as well. We're all trying to figure this out.
> > >
> > > That seems to contradict this quote from
> > > https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191
> > > :
> > >
> > > > There is little to no interest at rpmfusion to package and
> > > > maintain
> > > it, also keeping the repo in sync with fedora isn't a priority for
> > > me.
> >
> > I am not talking about Mesa, but ffmpeg instead.
> >
> > Insofar as the Mesa situation, the comment *right below* that one
> > explains the situation quite well:
> > https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322383#post1322383
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> Does this imply that this section[1] is no longer accurate?
>
>With a single maintainer introducing a ffmpeg-free binary packages
>into Fedora, competing with our fully featured ffmpeg build, this
>leads to various conflicts and interactions issues. While one could
>admittedly rejoice from the ffmpeg introduction intro Fedora
>(enabling ffmpeg support for some fedora package lacking it), the
>method used to forcibly introduced an un-backed (by most RPM Fusion
>packager involved) package with uncertain features enabled, was
>perceived as unfriendly for the least. A determining argument for
>any "new eyes" is the very short time the Fedora review took
>compared with a fully backed 6 months Fedora feature review process.
>
>Having non-competing packages in fedora+rpmfusion repositories is
>not a side thing, this is the reason why the RPM Fusion projects was
>created in the first place. Because of that we cannot afford support
>for ffmpeg-free at all and will recommend to migrate to our fully
>featured version.
>
>Fedora Workaround:
>
>sudo dnf swap ffmpeg-free ffmpeg --allowerasing
>

It's being worked on, but hopefully in F38+ (and maybe in F37), it
will no longer be true.



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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[yanqiyu01]

I would be very SAD if this change lands on my computer. While instead
of arguing with some legal puzzles, I think those parts can be provided
by seperate package (and maybe packaged in rpmfusion?) like intel-
media-driver. 

Is there any build-to-build ABI match requirement between the VAAPI
implementation and mesa itself?


在 2022-09-27星期二的 20:01 +0200，Frantisek Zatloukal写道：
> Hi,
> 
> since this mesa change
> ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6
> ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa package
> lost support for vaapi accelerated encoding and decoding of h264,
> h265 and decoding of vc1
> ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> 
> It seems like a big regression from F36 for users with GPUs with open
> source drivers (mainly AMD, maybe nVidia/other non x86...), that
> affects common use-cases of Fedora Workstation, like watching videos,
> in-house game streaming, attending online meetings and many more.
> 
> I'd like to ask:
> - Can somebody elaborate on reasons to change something that was
> working in Fedora for some time already?
> - Is there any short/mid/long term plan to improve the situation?
> - Would it be possible to provide vaapi support at least as an
> rpmfusion addon to alleviate the fallout in the short term?
> 
> Thanks!
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Wed, 2022-09-28 at 08:40 +0200, Neal Gompa wrote:
> On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen 
> wrote:
> > 
> > On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
> > > As one of the ffmpeg maintainers, I'm actively working on
> > > workarounds
> > > for the problem. And I've talked to my counterparts in RPM Fusion
> > > about the issue as well. We're all trying to figure this out.
> > 
> > That seems to contradict this quote from
> > https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191
> > :
> > 
> > > There is little to no interest at rpmfusion to package and
> > > maintain
> > it, also keeping the repo in sync with fedora isn't a priority for
> > me.
> 
> I am not talking about Mesa, but ffmpeg instead.
> 
> Insofar as the Mesa situation, the comment *right below* that one
> explains the situation quite well:
> https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322383#post1322383
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

Does this imply that this section[1] is no longer accurate? 

   With a single maintainer introducing a ffmpeg-free binary packages
   into Fedora, competing with our fully featured ffmpeg build, this
   leads to various conflicts and interactions issues. While one could
   admittedly rejoice from the ffmpeg introduction intro Fedora
   (enabling ffmpeg support for some fedora package lacking it), the
   method used to forcibly introduced an un-backed (by most RPM Fusion
   packager involved) package with uncertain features enabled, was
   perceived as unfriendly for the least. A determining argument for
   any "new eyes" is the very short time the Fedora review took
   compared with a fully backed 6 months Fedora feature review process.
   
   Having non-competing packages in fedora+rpmfusion repositories is
   not a side thing, this is the reason why the RPM Fusion projects was
   created in the first place. Because of that we cannot afford support
   for ffmpeg-free at all and will recommend to migrate to our fully
   featured version.
   
   Fedora Workaround: 
   
   sudo dnf swap ffmpeg-free ffmpeg --allowerasing 


[1] https://rpmfusion.org/CommonBugs


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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Adam Williamson]

On Tue, 2022-09-27 at 23:39 -0700, Adam Williamson wrote:
> On Wed, 2022-09-28 at 08:11 +0200, Julian Sikorski wrote:
> > Recently, I experienced that the German AusweisApp, which already 
> > required entering the ID card PIN on the phone [1], has stopped working 
> > altogether [2]. This is due to hobbled openssl Fedora ships. There is no 
> > openssl-freeworld in RPM Fusion, probably because it would need to be 
> > rebuilt entirely.
> 
> On this topic, have our legal advisors re-evaluated the ECC patent
> situation lately? The last patent listed in
> https://src.fedoraproject.org/rpms/openssl//blob/rawhide/f/hobble-openssl
> supposedly expired in 2020, yet we're still doing a lot of patching of
> ECC stuff in the spec. Are there other patents not listed there which
> we're still worried about?

Looks like there's a related, very slow-moving discussion on legal@:

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/WUQNAB4EPWSJMMVECL2TZGKB5KIDESII/#WUQNAB4EPWSJMMVECL2TZGKB5KIDESII
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen  wrote:
>
> On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
> > As one of the ffmpeg maintainers, I'm actively working on workarounds
> > for the problem. And I've talked to my counterparts in RPM Fusion
> > about the issue as well. We're all trying to figure this out.
>
> That seems to contradict this quote from
> https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191:
>
> > There is little to no interest at rpmfusion to package and maintain
> it, also keeping the repo in sync with fedora isn't a priority for me.

I am not talking about Mesa, but ffmpeg instead.

Insofar as the Mesa situation, the comment *right below* that one
explains the situation quite well:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322383#post1322383


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

OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Adam Williamson]

On Wed, 2022-09-28 at 08:11 +0200, Julian Sikorski wrote:
> Recently, I experienced that the German AusweisApp, which already 
> required entering the ID card PIN on the phone [1], has stopped working 
> altogether [2]. This is due to hobbled openssl Fedora ships. There is no 
> openssl-freeworld in RPM Fusion, probably because it would need to be 
> rebuilt entirely.

On this topic, have our legal advisors re-evaluated the ECC patent
situation lately? The last patent listed in
https://src.fedoraproject.org/rpms/openssl//blob/rawhide/f/hobble-openssl
supposedly expired in 2020, yet we're still doing a lot of patching of
ECC stuff in the spec. Are there other patents not listed there which
we're still worried about?
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
> As one of the ffmpeg maintainers, I'm actively working on workarounds
> for the problem. And I've talked to my counterparts in RPM Fusion
> about the issue as well. We're all trying to figure this out.

That seems to contradict this quote from
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191:

> There is little to no interest at rpmfusion to package and maintain
it, also keeping the repo in sync with fedora isn't a priority for me.


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Nicolas Chauvet]

Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
>
> On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> wrote:
> >
> > Hi,
> >
> > since this mesa change ( 
> > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> >  ) in F37 and rawhide, the mesa package lost support for vaapi accelerated 
> > encoding and decoding of h264, h265 and decoding of vc1 ( 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> >
> > It seems like a big regression from F36 for users with GPUs with open 
> > source drivers (mainly AMD, maybe nVidia/other non x86...), that affects 
> > common use-cases of Fedora Workstation, like watching videos, in-house game 
> > streaming, attending online meetings and many more.
>
> This was an oversight being enabled prior to this, and I think we have
> to remove it from older Fedora as well. Fedora cannot ship anything
> that causes the OS to provide an API which exposes patent algorithms.
>
> The patent licensing around H264/H265 is such that providing this
> could leave Red Hat and other Fedora distributors exposed to legal
> problems.
> Dave.
>
> > I'd like to ask:
> > - Can somebody elaborate on reasons to change something that was working in 
> > Fedora for some time already?
> > - Is there any short/mid/long term plan to improve the situation?
> > - Would it be possible to provide vaapi support at least as an rpmfusion 
> > addon to alleviate the fallout in the short term?
>
> The last might be possible, but I'm not sure how to go about it.
At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8

That the fedora mesa package completely drops the vaapi backend, so a
complementary package can just drop the missing files instead of
rebuilding a whole mesa package.
It would assume the fedora mesa package to have everything needed in
order to cope with vaapi backend enabled in the core libraries and
that the vaapi backend only provide the implementation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:12 AM Julian Sikorski  wrote:
>
> Am 27.09.22 um 20:01 schrieb Frantisek Zatloukal:
> > Hi,
> >
> > since this mesa change (
> > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> >  
> > 
> >  ) in F37 and rawhide, the mesa package lost support for vaapi accelerated 
> > encoding and decoding of h264, h265 and decoding of vc1 ( 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 
> >  ).
> >
> > It seems like a big regression from F36 for users with GPUs with open
> > source drivers (mainly AMD, maybe nVidia/other non x86...), that affects
> > common use-cases of Fedora Workstation, like watching videos, in-house
> > game streaming, attending online meetings and many more.
> >
> > I'd like to ask:
> > - Can somebody elaborate on reasons to change something that was working
> > in Fedora for some time already?
> > - Is there any short/mid/long term plan to improve the situation?
> > - Would it be possible to provide vaapi support at least as an rpmfusion
> > addon to alleviate the fallout in the short term?
> >
> > Thanks!
> >
>
> While I can relate to the rationale to some extent, the amount of
> breakage caused by patents is slowly pushing me towards considering
> moving to a new distro. I am probably not the only one. This could be
> the proverbial straw breaking the camel's back.
> Recently, I experienced that the German AusweisApp, which already
> required entering the ID card PIN on the phone [1], has stopped working
> altogether [2]. This is due to hobbled openssl Fedora ships. There is no
> openssl-freeworld in RPM Fusion, probably because it would need to be
> rebuilt entirely.

I think we need to have the crypto function hobbling stuff
re-evaluated entirely, it *might* no longer be needed (IANAL). Please
raise it on the legal@ list.

> For mesa, there is apparently also little interest in maintaining a
> mesa-freeworld package [3]. The discontent with ffmpeg moving to fedora
> a while ago also seems to have been primarily caused by the monolithic
> nature of ffmpeg. On the other hand, gstreamer plugins seem not to be a
> major problem.

As one of the ffmpeg maintainers, I'm actively working on workarounds
for the problem. And I've talked to my counterparts in RPM Fusion
about the issue as well. We're all trying to figure this out.


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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Julian Sikorski]

Am 27.09.22 um 20:01 schrieb Frantisek Zatloukal:

Hi,

since this mesa change ( 
https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide  ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998  ).


It seems like a big regression from F36 for users with GPUs with open 
source drivers (mainly AMD, maybe nVidia/other non x86...), that affects 
common use-cases of Fedora Workstation, like watching videos, in-house 
game streaming, attending online meetings and many more.


I'd like to ask:
- Can somebody elaborate on reasons to change something that was working 
in Fedora for some time already?

- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion 
addon to alleviate the fallout in the short term?


Thanks!



While I can relate to the rationale to some extent, the amount of 
breakage caused by patents is slowly pushing me towards considering 
moving to a new distro. I am probably not the only one. This could be 
the proverbial straw breaking the camel's back.
Recently, I experienced that the German AusweisApp, which already 
required entering the ID card PIN on the phone [1], has stopped working 
altogether [2]. This is due to hobbled openssl Fedora ships. There is no 
openssl-freeworld in RPM Fusion, probably because it would need to be 
rebuilt entirely.
For mesa, there is apparently also little interest in maintaining a 
mesa-freeworld package [3]. The discontent with ffmpeg moving to fedora 
a while ago also seems to have been primarily caused by the monolithic 
nature of ffmpeg. On the other hand, gstreamer plugins seem not to be a 
major problem.
It thus appears that, in order to keep Fedora appealing for users in 
jurisdictions not affected by patents, effort should be made to 
modularize the affected bits so that these can be shipped by RPM Fusion 
(or equivalent) without too much hassle.


Best regards,
Julian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2000306
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2105754
[3] 
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191

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