[Bug 1984246] perl-App-cpm-0.997006 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-App-cpm-0.997005 is|perl-App-cpm-0.997006 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.997006
Current version/release in rawhide: 0.997.004-1.fc35
URL: https://metacpan.org/release/App-cpm

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/8399/


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

Re: guile22 -> gnutls -> lots of virt packages

[Dan Čermák]

On July 7, 2021 9:14:34 PM UTC, "Zbigniew Jędrzejewski-Szmek" 
 wrote:
>On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote:
>> What would be considered sufficient research about usage of guile? If
>> package provides it as optional feature among many other features,
>how
>> should package owner test one feature is still demanded? Do we have
>any
>> best practice? Is asking on users@ and devel@ list enough?
>
>I strongly suspect that those users would have made themselves known
>by now. Neal mentioned that he uses guile in some projects, and that's
>pretty much it so far.

I wouldn't be so sure about that. I don't expect most Fedora users to read 
devel, especially these rather long "orphaned packages threads". So my guess is 
that most devs, who are not Fedora contributors, but use make in their personal 
projects are not even aware of this discussion taking place.


Cheers,

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

Re: Java packaging issue on EPEL7

[Mikolaj Izdebski]

On Mon, Jul 19, 2021 at 7:31 PM Vitaly Zaitsev via devel
 wrote:
>
> Hello.
>
> Found a strange RPM autodeps issue, related to Java packaging, only on
> EPEL7.
>
> EPEL7 package contains additional auto-detected strict dependencies:
> osgi(com.github.jnr.jffi) and osgi(com.sun.jna). That's why the package
> cannot be installed due to lack of dependencies on RHEL/CentOS 7:
>
> Error: Package: pycharm-community-2021.1.3-1.el7.x86_64 (phracek-PyCharm)
> Requires: osgi(com.github.jnr.jffi)
>   You could try using --skip-broken to work around the problem
>   You could try running: rpm -Va --nofiles --nodigest

[...]

> How I can fix this?

You can disable osgi requires generator or filter osgi requires (with
eg. __requires_exclude or __requires_exclude_from macros).

--
Mikolaj Izdebski

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

Schedule for Thursday's FPC Meeting (2021-07-22 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-07-22 16:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

= Day: Thursday ==
2021-07-22 09:00 PDT  US/Pacific
2021-07-22 12:00 EDT  --> US/Eastern <--
2021-07-22 16:00 UTC  UTC   
2021-07-22 17:00 BST  Europe/London 
2021-07-22 18:00 CEST Europe/Berlin 
2021-07-22 18:00 CEST Europe/Paris  
2021-07-22 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-07-23 00:00 HKT  Asia/Hong_Kong
2021-07-23 00:00 +08  Asia/Singapore
2021-07-23 01:00 JST  Asia/Tokyo
2021-07-23 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.






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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef   
openjpeg2-2.3.1-11.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ddb4fcb22a   
opendmarc-1.4.1.1-3.el7


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

R-rlecuyer-0.3.5-7.el7
centpkg-0.6.6-3.el7
remmina-1.4.20-1.el7

Details about builds:



 R-rlecuyer-0.3.5-7.el7 (FEDORA-EPEL-2021-f90c75e82f)
 R interface to RNG with multiple streams

Update Information:

Update to 0.3-5 to functions called by .Call.

ChangeLog:

* Mon Jun 14 2021 Tom Callaway  - 0.3.5-7
- Rebuilt for R 4.1.0
* Mon Jan 25 2021 Fedora Release Engineering  - 
0.3.5-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Sat Aug  1 2020 Fedora Release Engineering  - 
0.3.5-5
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Mon Jul 27 2020 Fedora Release Engineering  - 
0.3.5-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Fri Jun  5 2020 Tom Callaway  - 0.3.5-3
- rebuild for R 4
* Tue Jan 28 2020 Fedora Release Engineering  - 
0.3.5-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Mon Nov 25 2019 Dave love  - 0.3.5-9.el7
- New version
* Mon Aug 12 2019 Elliott Sales de Andrade  - 0.3.4-9
- Remove explicit dependencies provided by automatic dependency generator
* Wed Jul 24 2019 Fedora Release Engineering  - 
0.3.4-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Thu Jan 31 2019 Fedora Release Engineering  - 
0.3.4-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild




 centpkg-0.6.6-3.el7 (FEDORA-EPEL-2021-bc0bf2fc74)
 CentOS utility for working with dist-git

Update Information:

Resolves https://git.centos.org/centos/centpkg/issue/49.

ChangeLog:

* Wed Jul 21 2021 Carl George  - 0.6.6-3
- Backport upstream patch for "name 'header' is not defined" error
* Wed Jul 21 2021 Fedora Release Engineering  - 
0.6.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild




 remmina-1.4.20-1.el7 (FEDORA-EPEL-2021-07bf174fd3)
 Remote Desktop Client

Update Information:

Update to 1.4.20, drop nx, st and xdmcp plugins.

ChangeLog:

* Wed Jul 21 2021 Simone Caronni  - 1.4.20-1
- Update to 1.4.20.
- Remove unmaintained nx, st, xdmcp plugins.
* Wed Jun 30 2021 Simone Caronni  - 1.4.19-1
- Update to 1.4.19.

References:

  [ 1 ] Bug #1959672 - Remmina crashes when trying to rdp to a remote system.
https://bugzilla.redhat.com/show_bug.cgi?id=1959672
  [ 2 ] Bug #1976479 - [abrt] remmina: gtk_box_pack(): remmina killed by SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1976479
  [ 3 ] Bug #1977368 - remmina-1.4.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1977368
  [ 4 ] Bug #1981815 - Remmina 1.4.19 is unusable , problem fixed upstream, 
please update to 1.4.20
https://bugzilla.redhat.com/show_bug.cgi?id=1981815
  [ 5 ] Bug #1983157 - [abrt] remmina: remmina_rdp_open_connection(): remmina 
killed by SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1983157


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

[Bug 1981476] perl-ExtUtils-CChecker-0.11 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-ExtUtils-CChecker-0.11 |perl-ExtUtils-CChecker-0.11
   |-1.fc34 |-1.fc34
   ||perl-ExtUtils-CChecker-0.11
   ||-1.fc33



--- Comment #11 from Fedora Update System  ---
FEDORA-2021-f9126345dc has been pushed to the Fedora 33 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1971305] perl-Dist-Zilla-6.023 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Dist-Zilla-6.023-1.fc3 |perl-Dist-Zilla-6.023-1.fc3
   |5   |5
   ||perl-Dist-Zilla-6.023-1.fc3
   ||4
 Resolution|RAWHIDE |ERRATA



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-7ca1547aa0 has been pushed to the Fedora 34 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1981476] perl-ExtUtils-CChecker-0.11 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-ExtUtils-CChecker-0.11
   ||-1.fc34
 Resolution|--- |ERRATA
Last Closed||2021-07-22 01:13:41



--- Comment #10 from Fedora Update System  ---
FEDORA-2021-30554e7461 has been pushed to the Fedora 34 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild

[Dennis Gilmore]

On Wed, Jul 21, 2021 at 3:53 PM Richard W.M. Jones  wrote:
>
> On Wed, Jul 21, 2021 at 01:52:26PM +0200, Tomas Hrcka wrote:
> >
> >
> > Can the packagers fix the failures in the f35-rebuild side tag by
> > themselves
> > while the rebuild is in progress, or do they have to wait on merging the
> > tag?
> >
> >
> >
> > So I am unable to find any policy on this. But assuming that the
> > mass rebuilds bump spec, the packager should be fine with creating a
> > new release.
>
> I'm confused -  if we fix something should we do a build
> in regular rawhide, or in f35-rebuild (or both?)
>

It should be the same as all other mass rebuilds and be done in
rawhide only. the only exception being if you resubmit something that
failed due a fixed build, the buildroot for mass rebuilds is the
rawhide rebuild and until the side tagged is tagged over things are
not built against the new builds in the side tag.

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

Re: Fedora Zuul had been integrated with Testing Farm and TMT

[Miroslav Vadkerti]

FTR verified, when TMT is not around, it is now skipped:

https://fedora.softwarefactory-project.io/zuul/status/change/189,a906cee4eafd4a13c699b8964a1a69f6acdd03c9

On Thu, Jul 22, 2021 at 1:04 AM Miro Hrončok  wrote:

> On 22. 07. 21 1:02, Miroslav Vadkerti wrote:
> > Hi Miro,
> >
> > yeah, this slipped through with the initial review. Was a Zuul
> misconfiguration:
> >
> > https://pagure.io/fedora-zuul-jobs-config/pull-request/129#
> > 
> >
> > Fabien fixed this 3 hours ago.
> >
> > It should be better on `recheck`.
> >
> > Trying now ...
>
> Awesome, thanks for a fast reply!
>

glad to help :)

Best regards,
/M


>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>

-- 
Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / BaseOS QE / OSCI
IRC mvadkert #tft #baseosci #osci :: GPG 0x7B5B2E95
TPB-C 2C215 :: Mobile +420 773 944 252
Red Hat Czech s.r.o, Purkyňova 115, 612 00, Brno, CR
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Zuul had been integrated with Testing Farm and TMT

[Miro Hrončok]

On 22. 07. 21 1:02, Miroslav Vadkerti wrote:

Hi Miro,

yeah, this slipped through with the initial review. Was a Zuul misconfiguration:

https://pagure.io/fedora-zuul-jobs-config/pull-request/129# 



Fabien fixed this 3 hours ago.

It should be better on `recheck`.

Trying now ...


Awesome, thanks for a fast reply!

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

Re: Fedora Zuul had been integrated with Testing Farm and TMT

[Miroslav Vadkerti]

Hi Miro,

yeah, this slipped through with the initial review. Was a Zuul
misconfiguration:

https://pagure.io/fedora-zuul-jobs-config/pull-request/129#

Fabien fixed this 3 hours ago.

It should be better on `recheck`.

Trying now ...

Best regards,
/M

On Thu, Jul 22, 2021 at 12:49 AM Miro Hrončok  wrote:

> On 21. 07. 21 15:04, Miroslav Vadkerti wrote:
> > Dear all,
> >
> > Today we are gladly announcing that the Zuul CI system for Fedora, which
> is
> > running checks for pull requests against src.fedoraproject.org
> > , will also run Test Management Tool
> (tmt) based
> > tests via the new `rpm-tmt-test` check, if they are available. The test
> > environment is the same as with Fedora CI, as both CI systems use our
> Testing
> > Farm service as the backend.
>
> Hello Miro,
> I see rpm-tmt-test FAILUREs for packages without TMT tests.
>
> E.g.:
>
> https://src.fedoraproject.org/rpms/pypy/pull-request/19
> https://src.fedoraproject.org/rpms/pypy3/pull-request/24
> https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/189
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>

-- 
Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / BaseOS QE / OSCI
IRC mvadkert #tft #baseosci #osci :: GPG 0x7B5B2E95
TPB-C 2C215 :: Mobile +420 773 944 252
Red Hat Czech s.r.o, Purkyňova 115, 612 00, Brno, CR
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: An unsuccessful case study: Using pyproject-rpm-macros with PyQt-builder and sip 5

[Miro Hrončok]

On 21. 07. 21 20:25, Scott Talbert wrote:
Miro, do you know any examples of Fedora packages that are using PEP-517 build 
systems that build extension modules (successfully)?


This following CI spec files:

printrun.spec
python-ldap.spec
python-markupsafe.spec
python-mistune.spec

All in 
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/tests

At least the following actual packages in Fedora:

python-indexed_gzip
python-pendulum
python-xmlsec

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Zuul had been integrated with Testing Farm and TMT

[Miro Hrončok]

On 21. 07. 21 15:04, Miroslav Vadkerti wrote:

Dear all,

Today we are gladly announcing that the Zuul CI system for Fedora, which is 
running checks for pull requests against src.fedoraproject.org 
, will also run Test Management Tool (tmt) based 
tests via the new `rpm-tmt-test` check, if they are available. The test 
environment is the same as with Fedora CI, as both CI systems use our Testing 
Farm service as the backend.


Hello Miro,
I see rpm-tmt-test FAILUREs for packages without TMT tests.

E.g.:

https://src.fedoraproject.org/rpms/pypy/pull-request/19
https://src.fedoraproject.org/rpms/pypy3/pull-request/24
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/189

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

Re: Java packaging issue on EPEL7

[Nico Kadel-Garcia]

On Tue, Jul 20, 2021 at 7:24 AM Stephen John Smoogen  wrote:
>
> On Tue, Jul 20, 2021 at 06:29 Vitaly Zaitsev via devel 
>  wrote:
>>
>> On 20/07/2021 11:18, Nico Kadel-Garcia wrote:
>> > You're violating the bundling and naming practices that EPEL and
>> > Fedora have used for years, especially their insistence that they
>> > build from source, not repackaging bundled binaries from someone else
>> > into an RPM.
>>
>> This is not a Fedora package. This is a COPR package.
>
> Your wording in your initial emails made it sound like this was a package 
> either in EPEL or going to be in EPEL. In a very rare case, I was in 
> agreement with Nico and going to say the same things they did. Thank you for 
> clarifying this but it was confusing.

I didn't see COPR mentioned either. The title referred to EPEL 7.

>> COPR guidelines allows usage of pre-built binaries if they don't violate
>> the Fedora Legal guidelines[1]: "You do not need to comply with
>> Packaging Guidelines".

Even if COPR guidelines allow it, Vitaly, it's a bad idea. I'm
startled that the jar files can compile in COPR if they don't compile
in the normal Fedora environment. I suspect they can't, the .spec file
in the git repo you mentioned doesn't pull source. It pulls a
pre-compiled tarball from

In theory, Java provides "write once, run everywhere". In practice,
especially cross-linked with other libraries such as the libffi
packages for C data structures not so much, as you've just
encountered.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild

[Richard W.M. Jones]

On Wed, Jul 21, 2021 at 01:52:26PM +0200, Tomas Hrcka wrote:
> 
> 
> Can the packagers fix the failures in the f35-rebuild side tag by
> themselves
> while the rebuild is in progress, or do they have to wait on merging the
> tag?
> 
> 
>
> So I am unable to find any policy on this. But assuming that the
> mass rebuilds bump spec, the packager should be fine with creating a
> new release.

I'm confused -  if we fix something should we do a build
in regular rawhide, or in f35-rebuild (or both?)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: glibc 2.34 vs firefox in rawhide vs mass build rebuild

[Florian Weimer]

* Florian Weimer:

> Firefox in rawhide hasn't been built successfully since
> firefox-89.0-1.fc35 (built 2021-06-02).  Unfortunately that version does
> not treat the clone3 system call correctly in its sandbox, so it won't
> work with future glibc 2.34 snapshots.
>
> I fixed the issues to get firefox building again and attached a patch to
> this bug:
>
>   firefox: FTBFS with Python 3.10 in rawhide due to collections.abc change
>   
>
> (The patch also includes a glibc 2.34 compatibility change, separately
> tracked as #1983696 for downstream convenience.)
>
> The sandbox works again because the rawhide sources already had the
> required changes, they simply had not been built yet.
>
> What's the Fedora etiquette for fixing such long-standing FTBFS bugs?
>
> I seem to recall that firefox used to be a special package, not to be
> touched even by provenpackagers.
>
> On the other hand, I would like to upload another glibc 2.34 snapshot
> whose ABI is closer to what upstream is going to release on August 2nd.
> With that snapshot, glibc will start using clone3 internally, and that's
> incompatible with older firefox builds.
>
> It's not critical to do this glibc import before the mass rebuild
> because we definitely expect that the glibc 2.34 release will be
> backwards-compatible with what we have in Fedora today.  But we will
> miss some non-critical changes related to libresolv integration, so I'd
> like to proceed with the import.

Due to this issue, I disabled glibc for the mass rebuild.  The current
version in dist-git already uses clone3, and the mass rebuild would have
eventually tagged into the buildroot/compose, which we don't want until
firefox is fixed.

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

rpm-ostree and ostree-ext: supporting booting containers directly

[Colin Walters]

Hi, this is to raise awareness of an effort we're driving from the Fedora 
CoreOS side here:
"ship quay.io/coreos/fedora-coreos" at 
https://github.com/coreos/fedora-coreos-tracker/issues/812 

Which builds on a bidirectional bridge between ostree and container images that 
lives here:
https://github.com/ostreedev/ostree-rs-ext/#module-container-encapsulate-ostree-commits-in-ocidocker-images

The technology applies to any editions using (rpm-)ostree.  As of:
https://github.com/coreos/rpm-ostree/releases/tag/v2021.7
rpm-ostree now natively supports both:
`rpm-ostree ex-container export` to convert an ostree commit into a container 
image (which is just a proxy for the ostree-rs-ext code), as well as e.g.
`rpm-ostree rebase --experimental docker://quay.io/cgwalters/fcos:latest` which 
converts the system to track an "ostree-container" image as a base.  In other 
words, this uses containers as a native transport "on the wire" instead of 
ostree.

One way I like to talk about this effort in *combination* with the cliwrap 
effort (also just posted) is that one can describe us as supporting "image 
based dnf for host updates", in other words you type `yum update` and it pulls 
and updates from a container image for the host.

If you're interested, please check out the thread above linked which contains a 
fair amount of discussion on this, as well as the issues list here: 
https://github.com/ostreedev/ostree-rs-ext/issues which touches on things like 
"can/how can we support derivation" etc.



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

rpm-ostree cliwrap effort

[Colin Walters]

I was originally thinking of this as a Change, but since it won't be enabled by 
default, and I think it's most useful to gather feedback from this group first:

See https://coreos.github.io/rpm-ostree/cliwrap/
This is available since 
https://github.com/coreos/rpm-ostree/releases/tag/v2021.6

But just for convenience of not following the link, run:

$ rpm-ostree deploy --ex-cliwrap=true
(And `rpm-ostree ex apply-live` if you want)

I'd like for some people interested in this (particularly ones doing 
interactive CLI use, e.g. more "pet" systems like desktops) to try this out.  
Is it useful for your muscle memory to have typing `yum|dnf update` just work 
for example?  If you forget you're in a host shell and not a container, is the 
new error message from `dnf install` useful?

Obviously the big change would be flipping this on by default - that'd be the 
Fedora Change.  

Longer term though, part of the idea here is that I hope by thinking about 
rpm-ostree as "image based dnf" this way, it also helps drive increase 
alignment between the two.  For example, around things like:
https://github.com/rpm-software-management/libdnf/pull/1204#issuecomment-884225903

If you have feedback, here is fine, or in 
https://github.com/coreos/rpm-ostree/issues/2883

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

Re: An unsuccessful case study: Using pyproject-rpm-macros with PyQt-builder and sip 5

[Scott Talbert]

On Wed, 23 Jun 2021, Miro Hrončok wrote:

%pyproject_buildrequires works and generates requirements on python3dist(sip) 
and python3dist(pyqt-builder) \o/


%pyproject_buildrequires -r doesn't work. It says:

 ValueError: build backend cannot provide build metadata
 (incl. runtime requirements) before buld

Except for the typo [3], this is the expected behavior for a build backend 
that does not support the prepare_metadata_for_build_wheel hook. Bummer, but 
fair.


We can RFE PyQt-builder to add that hook.


As a start to tackling these problems, I sent this RFE upstream.  It looks 
like it should be relatively easy to implement, as far as I can see.


Miro, do you know any examples of Fedora packages that are using PEP-517 
build systems that build extension modules (successfully)?


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

Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

[Josh Berkus]

Matt,

You're correct, I was being very dramatic.  I've since talked to Otaylor, and 
the only real problem is that the announcement of this change is misleading.  
Fedora isn't "filtering" anything, you're adding Flathub packages in a place 
they weren't available before.  The announcement reads like you're modifying 
the Flatpak binary to allow only filtered content, and I think you can see why 
that would create substantial alarm among SB users.

Since I was the one to raise a stink about it, I'm going to work with otaylor 
to revise the text of the change announcement so that it'll read as a positive 
feature change (which it is) instead of as taking something away.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: /usr/share/appdata vs /usr/share/metainfo

[Vitaly Zaitsev via devel]

On 21/07/2021 19:49, Lyes Saadi wrote:
Ironically, I found some `.metainfo.xml` in `/usr/share/appdata` and 
some `.appdata.xml` in `/usr/share/metainfo`.


/usr/share/metainfo - modern directory for the metainfo files.
/usr/share/appdata - legacy, for compatibility purposes.

New/updated packages should always use /usr/share/metainfo aka 
%{_metainfodir}. If not, you should fix and send a pull request to upstream.


> AppStream tools scan the /usr/share/appdata/ path for legacy 
compatibility as well. It should not be used anymore by new software 
though, even on older Linux distributions (like RHEL 7 and Ubuntu 16.04 
LTS) the metainfo path is well supported. Support for the legacy path 
will likely be dropped completely with a future AppStream 1.0 release.


https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location

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

/usr/share/appdata vs /usr/share/metainfo

[Lyes Saadi]

Hello,

I was packaging a new application when I noticed that it installed its 
AppData file in `/usr/share/appdata`, instead of `%{metainfodir}`: 
`/usr/share/metainfo`. Never noticing the distinction before, I use dnf 
and find several other packages installing files there. Interestingly, 
the `%{__metainfo_path}` macro do also refer to `/usr/share/appdata`. I 
even find out that an app I'm developing in GTK is installing its 
AppData file there :P!


The Guidelines itself is ambiguous, it is not a MUST that AppData files 
should be installed in `%{metainfodir}`, but it is clearly intended to 
be required (the SHOULD referring to the existence of the AppData file, 
and not its location):


> If a package contains a GUI application, then it SHOULD install a 
|.metainfo.xml| file into |%{_metainfodir}|. Installed |.metainfo.xml| 
files MUST follow the AppStream specification page 
.


And I found an old discussion on the mailing list about it [1]. Neal 
Gompa is recommending there that the AppData should be installed in 
`%{_metainfodir}`. So, shouldn't we clarify the Guidelines to precise 
that the AppData file MUST be installed in `%{_metainfodir}` as well as 
fixing the packages using the wrong path or should we allow both paths 
to coexist?


I don't think that this is an important issue though, since 
`appstream-glib` take both paths in account [2].


Ironically, I found some `.metainfo.xml` in `/usr/share/appdata` and 
some `.appdata.xml` in `/usr/share/metainfo`.



[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DTWEF524FXOR5MY7VQUDY3K6JLIKNUQM/
[2]: 
https://github.com/hughsie/appstream-glib/blob/master/libappstream-builder/plugins/asb-plugin-appdata.c#L31-L35

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

Re: Fedora 35 Mass Rebuild update

[Tomas Hrcka]

Hi all,

sorry for the empty commit messages, we have migrated the script from
fedpkg to plain git command to allows empty commits for rmpautospec enabled
packages.
The bug is now fixed and the script re-run, some packages will have one
empty commit followed by the actual mass rebuild commit.

Sorry for the inconvenience and confusion.

On Wed, Jul 21, 2021 at 6:04 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Jul 21, 2021 at 09:35:37AM -0600, Jerry James wrote:
> > On Wed, Jul 21, 2021 at 9:30 AM Vitaly Zaitsev via devel
> >  wrote:
> > > On 21/07/2021 17:15, Jerry James wrote:
> > > > In fact, the ones I've looked at are empty commits.  There is a
> commit
> > > > message, but no changes of any kind to the spec file: no release
> bump,
> > > > no changelog entry.
> > >
> > > Yes, I can confirm[1]:
> > >
> > > Authored and Committed by releng 3 hours ago
> > > 0 file changed. 0 lines added. 0 lines removed.
> > >
> > > [1]:
> > >
> https://src.fedoraproject.org/rpms/aircrack-ng/c/b9c84c950c4a300709ac6dfee5d0a3b83c42447e?branch=rawhide
> >
> > That would be the right thing to do for packages using rpmautospec.
> > My suspicion is that rpmautospec support was added to the rebuild
> > script, but it is somehow detecting packages that do not actually use
> > rpmautospec.
>
> I guess normally such builds would immediately fail because koji does
> not allow non-scratch builds with the same nevra. But in case of the
> mass rebuild, it works for packages which haven't been build for F35
> yet [1]: aircrack-ng-1.6-8.fc34 != aircrack-ng-1.6-8.fc35.
> But it'll break for packages which have been already built for F35.
> It's also very confusing even if it works.
>
> [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1782783
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild update

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 21, 2021 at 09:35:37AM -0600, Jerry James wrote:
> On Wed, Jul 21, 2021 at 9:30 AM Vitaly Zaitsev via devel
>  wrote:
> > On 21/07/2021 17:15, Jerry James wrote:
> > > In fact, the ones I've looked at are empty commits.  There is a commit
> > > message, but no changes of any kind to the spec file: no release bump,
> > > no changelog entry.
> >
> > Yes, I can confirm[1]:
> >
> > Authored and Committed by releng 3 hours ago
> > 0 file changed. 0 lines added. 0 lines removed.
> >
> > [1]:
> > https://src.fedoraproject.org/rpms/aircrack-ng/c/b9c84c950c4a300709ac6dfee5d0a3b83c42447e?branch=rawhide
> 
> That would be the right thing to do for packages using rpmautospec.
> My suspicion is that rpmautospec support was added to the rebuild
> script, but it is somehow detecting packages that do not actually use
> rpmautospec.

I guess normally such builds would immediately fail because koji does
not allow non-scratch builds with the same nevra. But in case of the
mass rebuild, it works for packages which haven't been build for F35
yet [1]: aircrack-ng-1.6-8.fc34 != aircrack-ng-1.6-8.fc35.
But it'll break for packages which have been already built for F35.
It's also very confusing even if it works.

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1782783

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

Re: Fedora 35 Mass Rebuild update

[Jerry James]

On Wed, Jul 21, 2021 at 9:30 AM Vitaly Zaitsev via devel
 wrote:
> On 21/07/2021 17:15, Jerry James wrote:
> > In fact, the ones I've looked at are empty commits.  There is a commit
> > message, but no changes of any kind to the spec file: no release bump,
> > no changelog entry.
>
> Yes, I can confirm[1]:
>
> Authored and Committed by releng 3 hours ago
> 0 file changed. 0 lines added. 0 lines removed.
>
> [1]:
> https://src.fedoraproject.org/rpms/aircrack-ng/c/b9c84c950c4a300709ac6dfee5d0a3b83c42447e?branch=rawhide

That would be the right thing to do for packages using rpmautospec.
My suspicion is that rpmautospec support was added to the rebuild
script, but it is somehow detecting packages that do not actually use
rpmautospec.
--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild update

[Vitaly Zaitsev via devel]

On 21/07/2021 17:15, Jerry James wrote:

In fact, the ones I've looked at are empty commits.  There is a commit
message, but no changes of any kind to the spec file: no release bump,
no changelog entry.


Yes, I can confirm[1]:

Authored and Committed by releng 3 hours ago
0 file changed. 0 lines added. 0 lines removed.

[1]: 
https://src.fedoraproject.org/rpms/aircrack-ng/c/b9c84c950c4a300709ac6dfee5d0a3b83c42447e?branch=rawhide


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

[Bug 1984174] perl-HTTP-BrowserDetect-3.33 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-HTTP-BrowserDetect-3.3 |perl-HTTP-BrowserDetect-3.3
   |2 is available  |3 is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.33
Current version/release in rawhide: 3.31-3.fc35
URL: http://search.cpan.org/dist/HTTP-BrowserDetect/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/5936/


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

Re: Fedora 35 Mass Rebuild update

[Jerry James]

On Wed, Jul 21, 2021 at 9:01 AM Scott Talbert  wrote:
> It doesn't look like the mass rebuild is committing any changelog changes
> to the specfiles it's rebuilding.  Is that expected?

In fact, the ones I've looked at are empty commits.  There is a commit
message, but no changes of any kind to the spec file: no release bump,
no changelog entry.

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

Re: Fedora 35 Mass Rebuild update

[Scott Talbert]

On Wed, 21 Jul 2021, Tomas Hrcka wrote:


Hi all,

Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild will be done in a side tag (f35-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]


It doesn't look like the mass rebuild is committing any changelog changes 
to the specfiles it's rebuilding.  Is that expected?


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

Fedora Zuul had been integrated with Testing Farm and TMT

[Miroslav Vadkerti]

Dear all,

Today we are gladly announcing that the Zuul CI system for Fedora, which is
running checks for pull requests against src.fedoraproject.org, will also
run Test Management Tool (tmt) based tests via the new `rpm-tmt-test`
check, if they are available. The test environment is the same as with
Fedora CI, as both CI systems use our Testing Farm service as the backend.

For more information about:

* Fedora Zuul: https://fedoraproject.org/w/index.php?title=Zuul-based-ci
* Test Management Tool (tmt): https://docs.fedoraproject.org/en-US/ci/tmt/

This change is opening up doors for the same functionality for the
up-coming CentOS Stream CI, once there are available images for CI, we will
enable the same check also there.

We would like to especially thank Guy Inger (Testing Farm), Fabien Boucher
(Zuul) and Tristan De Cacqueray (Zuul) for contributing to this change.

Best regards,
/M

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

Fedora 35 Mass Rebuild update

[Tomas Hrcka]

Hi all,

Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild will be done in a side tag (f35-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,
Tomas Hrcka
fas: humaton
LiberaChat: jednorozec

[1] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
[2]
https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/




-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 35 Mass Rebuild update

[Tomas Hrcka]

Hi all,

Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild will be done in a side tag (f35-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,
Tomas Hrcka
fas: humaton
LiberaChat: jednorozec

[1] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
[2]
https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/




-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 3/199 (x86_64), 10/138 (aarch64)

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

ID: 932541  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/932541
ID: 932550  Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/932550
ID: 932551  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/932551
ID: 932591  Test: aarch64 Minimal-raw_xz-raw.xz base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/932591
ID: 932761  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/932761
ID: 932769  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/932769
ID: 932778  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/932778
ID: 932786  Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/932786

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

ID: 932603  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/932603
ID: 932644  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/932644
ID: 932765  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/932765
ID: 932773  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/932773
ID: 932802  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/932802

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

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

ID: 932654  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/932654

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

ID: 932582  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/932582
ID: 932588  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/932588
ID: 932645  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/932645
ID: 932673  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/932673
ID: 932704  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/932704
ID: 932753  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/932753

Passed openQA tests: 124/138 (aarch64), 177/199 (x86_64)

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

ID: 932596  Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/932596
ID: 932598  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/932598
ID: 932618  Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/932618
ID: 932661  Test: aarch64 Workstation-raw_xz-raw.xz unwanted_packages@uefi
URL: https://openqa.fedoraproject.org/tests/932661
ID: 932664  Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/932664
ID: 932666  Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/932666
ID: 932668  Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/932668
ID: 932695  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/932695
ID: 932741  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/932741
ID: 932797  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/932797

Skipped gating openQA tests: 4/199 (x86_64)

New skipped gating tests (same test not skipped in Fedora-Rawhide-20210719.n.0):

ID: 932552  Test: x86_64 KDE-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/932552
ID: 932553  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/932553
ID: 932560  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: 

Fedora-IoT-35-20210721.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64)

New failures (same test not failed in Fedora-IoT-35-20210719.0):

ID: 932838  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/932838
ID: 932840  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/932840

Old failures (same test failed in Fedora-IoT-35-20210719.0):

ID: 932841  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/932841
ID: 932849  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/932849
ID: 932850  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/932850

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

Old soft failures (same test soft failed in Fedora-IoT-35-20210719.0):

ID: 932825  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/932825
ID: 932826  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/932826
ID: 932827  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/932827
ID: 932842  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/932842

Passed openQA tests: 11/15 (aarch64), 11/16 (x86_64)

New passes (same test not passed in Fedora-IoT-35-20210719.0):

ID: 932843  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/932843
ID: 932851  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/932851
ID: 932852  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/932852
ID: 932853  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/932853

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 217 MiB to 188 MiB
Previous test data: https://openqa.fedoraproject.org/tests/931382#downloads
Current test data: https://openqa.fedoraproject.org/tests/932826#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 218 MiB to 195 MiB
Previous test data: https://openqa.fedoraproject.org/tests/931389#downloads
Current test data: https://openqa.fedoraproject.org/tests/932827#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild

[Tomas Hrcka]

Can the packagers fix the failures in the f35-rebuild side tag by themselves
> while the rebuild is in progress, or do they have to wait on merging the
> tag?
>
>
So I am unable to find any policy on this. But assuming that the mass
rebuilds bump spec, the packager should be fine with creating a new release.

-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild

[Tomas Hrcka]

Send updated notification with fixed links. BTW the links became active
once the mass rebuild was started. 21.7 10:00 UTC

On Tue, Jul 20, 2021 at 6:24 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jul 20, 2021 at 06:02:38PM +0200, Tomas Hrcka wrote:
> > Hi all,
> >
> > Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
> > on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
> > changes listed in:
> >
> > https://pagure.io/releng/issues?status=Open=mass+rebuild
> >
> > The mass rebuild will be done in a side tag (f35-rebuild) and moved over
> > when completed.
> >
> > Failures can be seen
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html
>
> 404
>
> > 
>
> -ESTALE ;(
>
>
> > Things still needing rebuilding
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html
>
> 404
>
> > 
>
> -ESTALE too.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20210721.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210719.n.0
NEW: Fedora-Rawhide-20210721.n.0

= SUMMARY =
Added images:3
Dropped images:  3
Added packages:  11
Dropped packages:1
Upgraded packages:   216
Downgraded packages: 3

Size of added packages:  6.02 MiB
Size of dropped packages:539.89 KiB
Size of upgraded packages:   3.93 GiB
Size of downgraded packages: 964.01 KiB

Size change of upgraded packages:   142.18 MiB
Size change of downgraded packages: 32.36 KiB

= ADDED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210721.n.0.iso
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20210721.n.0.aarch64.tar.xz
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20210721.n.0.iso

= DROPPED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20210719.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210719.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20210719.n.0.iso

= ADDED PACKAGES =
Package: bletchmame-2.6-1.20210720git46115fd.fc35
Summary: MAME emulator frontend
RPMs:bletchmame
Size:1.86 MiB

Package: mt32emu-2.5.2-1.fc35
Summary: C/C++ library for emulating Roland MT-32, CM-32L and LAPC-I 
synthesizer modules
RPMs:mt32emu mt32emu-devel
Size:807.23 KiB

Package: observable-0-1.20210719gitae3a59c.fc35
Summary: Generic observable objects and reactive expressions for C++
RPMs:observable-devel observable-doc
Size:1.24 MiB

Package: rust-ab_glyph-0.2.11-1.fc35
Summary: API for loading, scaling, positioning and rasterizing OpenType font 
glyphs
RPMs:rust-ab_glyph+default-devel rust-ab_glyph+libm-devel 
rust-ab_glyph+libm2-devel rust-ab_glyph+std-devel rust-ab_glyph-devel
Size:53.29 KiB

Package: rust-andrew-0.3.1-2.fc34
Summary: Convenient drawing of shapes, lines and text to buffers
RPMs:rust-andrew+default-devel rust-andrew-devel
Size:27.18 KiB

Package: rust-calloop0.6-0.6.5-1.fc35
Summary: Callback-based event loop
RPMs:rust-calloop0.6+default-devel rust-calloop0.6-devel
Size:39.30 KiB

Package: rust-opml-1.1.1-1.fc35
Summary: OPML parser for Rust
RPMs:rust-opml+default-devel rust-opml-devel
Size:25.40 KiB

Package: rust-proc-macro-crate0.1-0.1.5-1.fc35
Summary: Replacement for crate (macro_rules keyword) in proc-macros
RPMs:rust-proc-macro-crate0.1+default-devel rust-proc-macro-crate0.1-devel
Size:23.52 KiB

Package: rust-rusttype-0.9.2-3.fc35
Summary: Pure Rust alternative to libraries like FreeType
RPMs:rust-rusttype+crossbeam-deque-devel 
rust-rusttype+crossbeam-utils-devel rust-rusttype+default-devel 
rust-rusttype+gpu_cache-devel rust-rusttype+has-atomics-devel 
rust-rusttype+libm-devel rust-rusttype+libm-math-devel 
rust-rusttype+linked-hash-map-devel rust-rusttype+num_cpus-devel 
rust-rusttype+rustc-hash-devel rust-rusttype+std-devel rust-rusttype-devel
Size:120.58 KiB

Package: rust-smithay-client-toolkit0.12-0.12.2-1.fc35
Summary: Toolkit for making client wayland applications
RPMs:rust-smithay-client-toolkit0.12+andrew-devel 
rust-smithay-client-toolkit0.12+calloop-devel 
rust-smithay-client-toolkit0.12+default-devel 
rust-smithay-client-toolkit0.12+frames-devel 
rust-smithay-client-toolkit0.12-devel
Size:140.40 KiB

Package: sip6-6.1.1-1.fc35
Summary: SIP - Python/C++ Bindings Generator
RPMs:sip6
Size:1.71 MiB


= DROPPED PACKAGES =
Package: rubygem-sdoc-2.2.0-1.fc35
Summary: RDoc generator to build searchable HTML documentation for Ruby code
RPMs:rubygem-sdoc rubygem-sdoc-doc
Size:539.89 KiB


= UPGRADED PACKAGES =
Package:  CImg-1:2.9.8-1.fc35
Old package:  CImg-1:2.9.7-1.fc35
Summary:  C++ Template Image Processing Toolkit
RPMs: CImg-devel
Size: 11.17 MiB
Size change:  34.86 KiB
Changelog:
  * Tue Jul 20 2021 josef radinger  - 1:2.9.8-1
  - bump version


Package:  NetworkManager-1:1.32.4-1.fc35
Old package:  NetworkManager-1:1.32.0-1.fc35
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 28.95 MiB
Size change:  111.78 KiB
Changelog:
  * Tue Jul 20 2021 Thomas Haller  - 1:1.32.4-1
  - update to 1.32.4 release
  - default to "nftables" firewall-backend for shared mode.


Package:  WALinuxAgent-2.3.1.1-1.fc35
Old package:  WALinuxAgent-2.3.0.2-1.fc35
Summary:  The Microsoft Azure Linux Agent
RPMs: WA

[Test-Announce] Fedora 35 Rawhide 20210721.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 35 Rawhide 20210721.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20210717.n.0: anaconda-35.19-1.fc35.src, 20210721.n.0: 
anaconda-35.20-1.fc35.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/35

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210721.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20210721.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210721.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20210720.0):

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

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild

[Petr Pisar]

V Tue, Jul 20, 2021 at 06:02:38PM +0200, Tomas Hrcka napsal(a):
> Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
> on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
> changes listed in:
> 
> https://pagure.io/releng/issues?status=Open=mass+rebuild
> 
> The mass rebuild will be done in a side tag (f35-rebuild) and moved over
> when completed.
> 
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html
> 
> 
Can the packagers fix the failures in the f35-rebuild side tag by themselves
while the rebuild is in progress, or do they have to wait on merging the tag?

-- Petr


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

Re: glibc 2.34 vs firefox in rawhide vs mass build rebuild

[Martin Stransky]

Hi Florian,

I tried to install rawhide in VM to fix FF build but rawhide failed to 
boot (live iso and update by dnf from 34).


I'll look at it again.

Martin

On 7/20/21 12:17 PM, Florian Weimer wrote:

Firefox in rawhide hasn't been built successfully since
firefox-89.0-1.fc35 (built 2021-06-02).  Unfortunately that version does
not treat the clone3 system call correctly in its sandbox, so it won't
work with future glibc 2.34 snapshots.

I fixed the issues to get firefox building again and attached a patch to
this bug:

   firefox: FTBFS with Python 3.10 in rawhide due to collections.abc change
   

(The patch also includes a glibc 2.34 compatibility change, separately
tracked as #1983696 for downstream convenience.)

The sandbox works again because the rawhide sources already had the
required changes, they simply had not been built yet.

What's the Fedora etiquette for fixing such long-standing FTBFS bugs?

I seem to recall that firefox used to be a special package, not to be
touched even by provenpackagers.

On the other hand, I would like to upload another glibc 2.34 snapshot
whose ABI is closer to what upstream is going to release on August 2nd.
With that snapshot, glibc will start using clone3 internally, and that's
incompatible with older firefox builds.

It's not critical to do this glibc import before the mass rebuild
because we definitely expect that the glibc 2.34 release will be
backwards-compatible with what we have in Fedora today.  But we will
miss some non-critical changes related to libresolv integration, so I'd
like to proceed with the import.

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




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