[Bug 1976330] ctstream-30 is available

[bugzilla]

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: F34 regression: nouveau crashes on kernel 5.12

[Sam Varshavchik]

Tim Jackson writes:

I'm unfortunately no expert in this area, but as far as I can tell,  
certain(?) chipsets using the nouveau driver fail to resume from suspend on  
all 5.12 kernels, which leaves the system in an apparently unrecoverable  
state requiring a hard reboot. The same hardware configuration has worked  
perfectly for me for several years through a number of Fedora releases.


Suspend on my laptop with nouveau hasn't worked in at least ten years (ever  
since I had it), much longer before kernel 5.12.


Interestingly enough, on this laptop and laptop alone I'm offered a "Hybrid  
Sleep" alternative which works fairly reliably. It does, occasionally, fail  
to wake up, getting stuck in a weird "try to wake up, go back to sleep"  
infinite loop that only a hard power reset can cure. But it hasn't done that  
in a long while, maybe someone found this bug and fixed it. Keeping my  
fingers crossed.




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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-698907eb45   
quassel-0.13.1-8.el8


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

ctstream-30-1.el8
duplicity-0.8.20-1.el8
odfpy-1.4.0-7.el8
python-openpyxl-3.0.3-4.el8

Details about builds:



 ctstream-30-1.el8 (FEDORA-EPEL-2021-87b303b50e)
 Get URLs of Czech Television video streams

Update Information:

This new package enables users to list and retrieve a video stream from the web
pages of Czech Television.

ChangeLog:





 duplicity-0.8.20-1.el8 (FEDORA-EPEL-2021-fdb6cf1e3a)
 Encrypted bandwidth-efficient backup using rsync algorithm

Update Information:

0.8.20

ChangeLog:

* Mon Jun 28 2021 Gwyn Ciesla  - 0.8.20-1
- 0.8.20
* Fri Jun  4 2021 Python Maint  - 0.8.19-2
- Rebuilt for Python 3.10

References:

  [ 1 ] Bug #1976477 - duplicity-0.8.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976477




 odfpy-1.4.0-7.el8 (FEDORA-EPEL-2021-333cf44938)
 Python library for manipulating OpenDocument files

Update Information:

New package

ChangeLog:





 python-openpyxl-3.0.3-4.el8 (FEDORA-EPEL-2021-7dc78a18ca)
 Python library to read/write Excel 2010 xlsx/xlsm files

Update Information:

New package

ChangeLog:


References:

  [ 1 ] Bug #1950660 - EPEL8 Branch Request: python-openpyxl
https://bugzilla.redhat.com/show_bug.cgi?id=1950660


___
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 1976330] ctstream-30 is available

[bugzilla]

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1136745] perl-Convert-PEM-0.08-13.fc22 FTBFS randomly: 'errstr matches decrypt failed' t/02-encode.t test fails

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2021-976a98491a has been pushed to the Fedora EPEL 7 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-976a98491a

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1976330] ctstream-30 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2021-88812aa095 has been pushed to the Fedora EPEL 7 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-88812aa095

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


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

package review request

[Mukundan Ragavan]

Hi,

Can someone please review this relatively straightforward package? This 
is new dependency for spyder.


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

Thank you.

Mukundan.
--
GPG Key: E5C8BC67



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

Re: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[Paul Wouters]

On Mon, 28 Jun 2021, Ben Cotton wrote:


https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec



== Detailed Description ==

OpenDNSSec changed the default behavior to not include SHA1 DS by
default, and added the -sha1 knob as an immediately-deprecated
compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
default ‘ods-enforcer key export –ds’ included the SHA1 version of the
DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
use the –sha1 flag. This flag is immediately deprecated and will be
removed from future versions of OpenDNSSEC." (see ChangeLog:
https://www.opendnssec.org/archive/releases/ ).

The proposal is to disable the -sha1 knob in Fedora. I will also open
an issue upstream to remove all the sha1-related code.


This change makes me a bit nervous, and I'm the author of RFC 8624 that
recommennds not using SHA-1 for DS/CDS records anymore.

https://datatracker.ietf.org/doc/html/rfc8624#section-3.3


Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
[from ICANN] (2020-1-24): "Now is the time for administrators of zones
at all levels of the DNS to stop using SHA-1 and change to algorithms
using stronger hashes."


While this is true, the order of where things need to change are:

1 Discourage, but not block, the use of SHA-1. Eg remove it from the default 
set.
2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
3 remove support for SHA-1

This plan assumes we are in phase3. I would say we are in phase2.

Remember, any domain that depends on SHA-1 is going to be more secure
than being marked as insecure because SHA-1 is rejected. This is somewhat
different from like SHA-1 support for authentication where the rejection
of a weaker algorithm forces the use of a stronger algorithm.

The DNSSEC fallback when an algorithm is not supported is to go insecure,
not insist on a more secure SHA-2 that is not there. With DNSSEC,
there is not client-server exchange like with TLS or IPsec. There is
a producer on one end, and a consumer on the other end. The two do not
negotiate crypto parameters.


== Benefit to Fedora ==
* This change makes sure OpenDNSSec in Fedora follows ICANN's
guidelines and does not propose SHA1 DS. This is is needed given the
[https://sha-mbles.github.io/ latest attacks against SHA-1]. More
in-depth articles are available
[https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
[https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/


I know that a few people believe that shambles can in theory be abused
with DNSSEC, but a lot of people also believe the constrains of DNS
RRsets make this impossible. But even _if_ it is possible, it would
only affect multiple domains that share the same private key that made
the SHA-1 signature. And then we are talking about RRSIG records and
not, as in this proposal, the DS/CDS RDATA content.


Patch the enforcer so that bsha1 is not honored anymore:


I don't think fedora should move faster than upstream opendnssec. I
believe the people at the IETF and the software developers of the DNS
software are more aware of where we are in the migration path than
individual Fedora developers.


== Upgrade/compatibility impact ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.


The RRSIG signature is not related to the DS signature. Zone resigning
is something completely different from the DS/CDS records. Those records
are signed by the parent zone, and use whatever algorithm the parent
zone uses, which the child zone cannot dictate.


This change might break (very old) clients that only recognize SHA-1
but these should already be broken (on the Internet at least) because
the root zone is signed with SHA-256 only.


The root zone has no DS record, so this statement does not make sense.
The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
that contains a hash of the child's public key, where the hash is created
with SHA-1 or SHA-2.


== User Experience ==

OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
With this change, this will no longer be possible. The migration from
SHA1 is underway anyway.


So there are two things that really need to be clarified for this
proposal. Is it talking about DS/CDS signature algorithm as per IANA
registry http://www.iana.org/assignments/ds-rr-types, or are we talking
about DNSKEY signature algorithm, that is responsble for signing all
the zone data, that uses a hash algorithm or SHA-1 or better. Based on
the description, I am a bit worried that it is not entirely clear what
the proposed change actually is.

Please feel free to reach out to me directly to talk about this feature
request.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: Fedora Source-git SIG report #1 (June 2021)

[Neal Gompa]

On Mon, Jun 28, 2021 at 6:48 PM Colin Walters  wrote:
>
>
>
> On Thu, Jun 24, 2021, at 5:16 AM, Tomas Tomecek wrote:
> > Greetings from the Fedora source-git SIG! We are planning to start
> > publishing reports of what we are working on so everyone can easily
> > pay attention and get involved if interested. If you have any ideas,
> > comments or requests, don’t be shy and let us know :)
>
> I really appreciate your efforts here.  I think most of us know
> that the current RPM workflow is very antiquated.
>
> However, two things:
>
> - The representation for how we maintain source code is a
>   very long-term commitment.  It's hard to maintain multiple
>   of them.  Related to that, the details of how this works
>   will quickly become "frozen" and hard to change, so
>   it's important to get it right from the start.  Related
>   to that:
> - I think this proposal only benefits very few packages,
>   mainly kernel/grub where the upstream is large
>   and we carry nontrivial deltas.  For most others,
>   it will either be neutral or worse.  So...my counter
>   proposal is to iterate closer to a NixOS/OpenEmbedded style "uni-repo"
>   model, leaving these special cases to basically become
>   forked upstream repositories.  Instead of carrying 208+
>   patches to grub, we'd have a separate git repo that gets rebased.
>   Which...is how it already works at 
> https://github.com/rhboot/grub2/tree/fedora-35
>   it looks like.
>
> On the "uni-repo" counter proposal: there's a bunch of real-world examples 
> here of distributions using this successfully:
> https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow

The monorepo model scales very badly once you have a huge number of
contributors. And having per-package ACLs is basically toast in a
monorepo.

Note that AUR doesn't use a monorepo, they map each SVN folder to a
Git branch instead. It's effectively thousands of Git repos smushed
into one super-repo with thousands of branches.

Having experienced monorepo models for packaging before, it's rife
with issues and makes tracking history super-hard. In general, I think
a monorepo model is a horrible idea and should never be considered for
Fedora.


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

Re: Fedora Source-git SIG report #1 (June 2021)

[Colin Walters]

On Thu, Jun 24, 2021, at 5:16 AM, Tomas Tomecek wrote:
> Greetings from the Fedora source-git SIG! We are planning to start
> publishing reports of what we are working on so everyone can easily
> pay attention and get involved if interested. If you have any ideas,
> comments or requests, don’t be shy and let us know :)

I really appreciate your efforts here.  I think most of us know
that the current RPM workflow is very antiquated.

However, two things:

- The representation for how we maintain source code is a
  very long-term commitment.  It's hard to maintain multiple
  of them.  Related to that, the details of how this works
  will quickly become "frozen" and hard to change, so
  it's important to get it right from the start.  Related
  to that:
- I think this proposal only benefits very few packages,
  mainly kernel/grub where the upstream is large
  and we carry nontrivial deltas.  For most others,
  it will either be neutral or worse.  So...my counter
  proposal is to iterate closer to a NixOS/OpenEmbedded style "uni-repo"
  model, leaving these special cases to basically become
  forked upstream repositories.  Instead of carrying 208+
  patches to grub, we'd have a separate git repo that gets rebased.
  Which...is how it already works at 
https://github.com/rhboot/grub2/tree/fedora-35
  it looks like.

On the "uni-repo" counter proposal: there's a bunch of real-world examples here 
of distributions using this successfully:
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 1977103] New: perl-Pod-Simple-3.43 is available

[bugzilla]

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

Bug ID: 1977103
   Summary: perl-Pod-Simple-3.43 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Pod-Simple
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
spo...@gmail.com, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.43
Current version/release in rawhide: 3.42-478.fc35
URL: http://search.cpan.org/dist/Pod-Simple/

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


-- 
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: F35 Change: LLVM 13 (Self-Contained Change proposal)

[Tom Stellard]

On 6/28/21 9:57 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/LLVM-13



This is supposed to be a system-wide change not a self-contained changed.
I've fixed this now on the wiki.

-Tom


== Summary ==
Update all llvm sub-projects in Fedora to version 13.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 13, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang12 and llvm12 will be added to ensure that
packages that currently depend on clang and llvm version 12 libraries
will continue to work.


== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request a side-tag.
** Build llvm12 and clang12 into the side-tag.
** When the upstream LLVM project releases version 12.0.0-rc1 (Late
July 2021), package this and build it into the side tag.
** Merge side-tag into rawhide prior to the f35 branch date.
** Continue packaging newer release candidates into rawhide and f35
until the final release is complete (Late September 2021)

* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang12 and llvm12
compatibility packages if they want to rebuild their package and it
does not work with LLVM 13 yet.  The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
13 is added to Fedora.  The compatibility packages will ensure that
already built packages continue to work.

* Release engineering: [https://pagure.io/releng/issues/10179]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
This change should not impact upgradeability.

== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
13.

== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.

== Dependencies ==
This change can be made without updating any other packages.  However,
as mention before, packages that need to use LLVM 12 will need to
update their spec file on their first rebuild after this change.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?):  If there are
major problems with LLVM 13, the compatibility package provide a way
for other packages to continue using LLVM 12.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 13:

* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
* flang
* mlir
* polly
* libclc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

F34 regression: nouveau crashes on kernel 5.12

[Tim Jackson]

Is anyone working on, or able to assist with the fact that nouveau suffers 
crashes potentially causing data loss on all versions of kernel 5.12 with 
Fedora 34? It's a pretty serious regression especially as the update from 5.11 
to 5.12 happened in the middle of the F34 cycle.


I'm unfortunately no expert in this area, but as far as I can tell, certain(?) 
chipsets using the nouveau driver fail to resume from suspend on all 5.12 
kernels, which leaves the system in an apparently unrecoverable state 
requiring a hard reboot. The same hardware configuration has worked perfectly 
for me for several years through a number of Fedora releases.


I've commented [1] with full details on what I *believe* (although am not 100% 
certain) to be the correct upstream bug, although it seems like if anyone is 
able to assist upstream it would most likely be appreciated. Does anyone else 
see the same issue?



Tim

[1] https://gitlab.freedesktop.org/drm/nouveau/-/issues/99#note_944738
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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-packaging] Macro to smoke-test-import a Python module in %check

[Dan Čermák]

Miro Hrončok  writes:

> On 28. 06. 21 22:25, Dan Čermák wrote:
>> Hi Miro,
>> 
>> Miro Hrončok  writes:
>> 
>>> Hello Python RPM packagers,
>>>
>>> based on some discussion in the "F35 Change: Python Packaging Guidelines
>>> overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro 
>>> that
>>> can help to test-import a Python module in %check when no other tests exist 
>>> or
>>> are when they cannot be executed during build [1].
>>>
>>> The semantics is quite simple:
>>>
>>>
>>>   %check
>>>   %py3_check_import mymodule mymodule.submodule
>>>
>>> ...
>> 
>> This looks pretty good imho. Would it somehow be possible for the macro
>> to automatically try to import the module name from the generated
>> python3.Ydist() provides? That would make the macro even more convenient
>> to use and reduce any potential user error further.
>
> Honestly, I'd rather not do that. People already confuse "module names" 
> (that's 
> what you import) with "Python package names" (that's what you install from 
> PyPI 
> or what's provided as python3.Ydist()). And while this would make the macro 
> slightly easier to use for the optimal case when those names are identical, 
> it 
> would only create more confusion when they are not.
>
> In the future, we could extend it to automatically import modules found in 
> the 
> %buidlroot, but now I'd rather provide a simple tool where the packager needs 
> to be explicit, than a very complex tool that does heuristics.

That makes sense & is probably the better approach initially. I have
honestly no idea what could be improved here, so this looks more than
fine by me :)


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: GNOME on Wayland does not work on latest Rawhide

[Adam Williamson]

On Mon, 2021-06-28 at 21:37 +0200, Florian Weimer wrote:
> * Mohan Boddu:
> 
> > On Mon, Jun 28, 2021 at 3:20 PM Florian Weimer  wrote:
> > > 
> > > * Mohan Boddu:
> > > 
> > > > Not sure if its related, but bolt is also having an issue:
> > > 
> > > What's your glibc version?  glibc-2.33.9000-25.fc35 is the first build
> > > with the (then downstream-only) fix.
> > 
> > I should have mentioned this earlier, but I updated to
> > glibc-2.33.9000-25.fc35
> 
> Then this must be a different bug.  glibc or not glibc, I don't know.  A
> backtrace with debuginfo might help.  Maybe the received udev message
> has an unexpected format.

I was the one who mentioned bolt crashing in the initial bug. Since I
updated to glibc-2.33.9000-25.fc35.x86_64 it has not been crashing for
me.
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Fedora-packaging] Macro to smoke-test-import a Python module in %check

[Miro Hrončok]

On 28. 06. 21 22:25, Dan Čermák wrote:

Hi Miro,

Miro Hrončok  writes:


Hello Python RPM packagers,

based on some discussion in the "F35 Change: Python Packaging Guidelines
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that
can help to test-import a Python module in %check when no other tests exist or
are when they cannot be executed during build [1].

The semantics is quite simple:


  %check
  %py3_check_import mymodule mymodule.submodule

...


This looks pretty good imho. Would it somehow be possible for the macro
to automatically try to import the module name from the generated
python3.Ydist() provides? That would make the macro even more convenient
to use and reduce any potential user error further.


Honestly, I'd rather not do that. People already confuse "module names" (that's 
what you import) with "Python package names" (that's what you install from PyPI 
or what's provided as python3.Ydist()). And while this would make the macro 
slightly easier to use for the optimal case when those names are identical, it 
would only create more confusion when they are not.


In the future, we could extend it to automatically import modules found in the 
%buidlroot, but now I'd rather provide a simple tool where the packager needs 
to be explicit, than a very complex tool that does heuristics.


--
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-packaging] Macro to smoke-test-import a Python module in %check

[Miro Hrončok]

On 28. 06. 21 22:25, Dan Čermák wrote:

Hi Miro,

Miro Hrončok  writes:


Hello Python RPM packagers,

based on some discussion in the "F35 Change: Python Packaging Guidelines
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that
can help to test-import a Python module in %check when no other tests exist or
are when they cannot be executed during build [1].

The semantics is quite simple:


  %check
  %py3_check_import mymodule mymodule.submodule

...


This looks pretty good imho. Would it somehow be possible for the macro
to automatically try to import the module name from the generated
python3.Ydist() provides? That would make the macro even more convenient
to use and reduce any potential user error further.


Honestly, I'd rather not do that. People already confuse "module names" (that's 
what you import) with "Python package names" (that's what you install from PyPI 
or what's provided as python3.Ydist()). And while this would make the macro 
slightly easier to use for the optimal case when those names are identical, it 
would only create more confusion when they are not.


In the future, we could extend it to automatically import modules found in the 
%buidlroot, but now I'd rather provide a simple tool where the packager needs 
to be explicit, than a very complex tool that does heuristics.


--
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-packaging] Macro to smoke-test-import a Python module in %check

[Dan Čermák]

Hi Miro,

Miro Hrončok  writes:

> Hello Python RPM packagers,
>
> based on some discussion in the "F35 Change: Python Packaging Guidelines 
> overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that 
> can help to test-import a Python module in %check when no other tests exist 
> or 
> are when they cannot be executed during build [1].
>
> The semantics is quite simple:
>
>
>  %check
>  %py3_check_import mymodule mymodule.submodule
>
> When all listed modules are successfully imported, "nothing happens", when at 
> lest one fails to import, the entire build fails. The above line is 
> translated 
> very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the 
> implementation [0] for more accurate representation). Given the Python 
> semantics, it is possible to use commas as module separators as well (but no 
> parentheses).
>
> The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
>
> The runtime dependencies are obviously needed for this to work, so they need 
> to 
> be manually BuildRequired or even better, generated in 
> %generate_buildrequires 
> via `%pyproject_buildrequires -r` to use this macro.
>
> The macro can be used repeatedly when importing multiple modules at once is 
> undesired (e.g. when only one module can be imported from the same Python 
> interpreter):
>
>  %check
>  %py3_check_import mymodule.either
>  %py3_check_import mymodule.or
>
> Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
>
>   - Do you have better ideas for the macro name?
>   - Do you have better ideas for the macro semantics?

This looks pretty good imho. Would it somehow be possible for the macro
to automatically try to import the module name from the generated
python3.Ydist() provides? That would make the macro even more convenient
to use and reduce any potential user error further.


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

Macro to smoke-test-import a Python module in %check

[Miro Hrončok]

Hello Python RPM packagers,

based on some discussion in the "F35 Change: Python Packaging Guidelines 
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that 
can help to test-import a Python module in %check when no other tests exist or 
are when they cannot be executed during build [1].


The semantics is quite simple:


%check
%py3_check_import mymodule mymodule.submodule

When all listed modules are successfully imported, "nothing happens", when at 
lest one fails to import, the entire build fails. The above line is translated 
very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the 
implementation [0] for more accurate representation). Given the Python 
semantics, it is possible to use commas as module separators as well (but no 
parentheses).


The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.

The runtime dependencies are obviously needed for this to work, so they need to 
be manually BuildRequired or even better, generated in %generate_buildrequires 
via `%pyproject_buildrequires -r` to use this macro.


The macro can be used repeatedly when importing multiple modules at once is 
undesired (e.g. when only one module can be imported from the same Python 
interpreter):


%check
%py3_check_import mymodule.either
%py3_check_import mymodule.or

Before I merge this and backport to all Fedoras and EPELs, I'd like to know:

 - Do you have better ideas for the macro name?
 - Do you have better ideas for the macro semantics?


[0] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZSFZG76OYMB64K2N55QT2CRNPCKRAIYY/

[1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
--
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

Macro to smoke-test-import a Python module in %check

[Miro Hrončok]

Hello Python RPM packagers,

based on some discussion in the "F35 Change: Python Packaging Guidelines 
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that 
can help to test-import a Python module in %check when no other tests exist or 
are when they cannot be executed during build [1].


The semantics is quite simple:


%check
%py3_check_import mymodule mymodule.submodule

When all listed modules are successfully imported, "nothing happens", when at 
lest one fails to import, the entire build fails. The above line is translated 
very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the 
implementation [0] for more accurate representation). Given the Python 
semantics, it is possible to use commas as module separators as well (but no 
parentheses).


The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.

The runtime dependencies are obviously needed for this to work, so they need to 
be manually BuildRequired or even better, generated in %generate_buildrequires 
via `%pyproject_buildrequires -r` to use this macro.


The macro can be used repeatedly when importing multiple modules at once is 
undesired (e.g. when only one module can be imported from the same Python 
interpreter):


%check
%py3_check_import mymodule.either
%py3_check_import mymodule.or

Before I merge this and backport to all Fedoras and EPELs, I'd like to know:

 - Do you have better ideas for the macro name?
 - Do you have better ideas for the macro semantics?


[0] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZSFZG76OYMB64K2N55QT2CRNPCKRAIYY/

[1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
--
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: [ELN] Rebuild ordering and side-tag support

[Mohan Boddu]

On Mon, Jun 28, 2021 at 3:33 PM Dan Horák  wrote:
>
> On Mon, 28 Jun 2021 11:55:21 -0400
> Stephen Gallagher  wrote:
>
> > Summary: I think we can fix the ELN side-tag rebuild problems and make
> > the composes more reliable if we change the mechanism for kicking off
> > rebuilds. I'm soliciting feedback to help identify potential issues
> > with this proposed approach.
>
> have you considered re-using koji-shadow? It might already know
> everything you need ...

But it requires another koji instance that needs maintenance.

>
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: GNOME on Wayland does not work on latest Rawhide

[Florian Weimer]

* Mohan Boddu:

> On Mon, Jun 28, 2021 at 3:20 PM Florian Weimer  wrote:
>>
>> * Mohan Boddu:
>>
>> > Not sure if its related, but bolt is also having an issue:
>>
>> What's your glibc version?  glibc-2.33.9000-25.fc35 is the first build
>> with the (then downstream-only) fix.
>
> I should have mentioned this earlier, but I updated to
> glibc-2.33.9000-25.fc35

Then this must be a different bug.  glibc or not glibc, I don't know.  A
backtrace with debuginfo might help.  Maybe the received udev message
has an unexpected format.

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

Re: GNOME on Wayland does not work on latest Rawhide

[Mohan Boddu]

On Mon, Jun 28, 2021 at 3:20 PM Florian Weimer  wrote:
>
> * Mohan Boddu:
>
> > Not sure if its related, but bolt is also having an issue:
>
> What's your glibc version?  glibc-2.33.9000-25.fc35 is the first build
> with the (then downstream-only) fix.

I should have mentioned this earlier, but I updated to glibc-2.33.9000-25.fc35

>
> boltd issues have been reported as well, but I'm not sure if we have
> verified that they went away with the fix for the larger issue.
>
> Thanks,
> Florian
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

[Dan Horák]

On Mon, 28 Jun 2021 11:55:21 -0400
Stephen Gallagher  wrote:

> Summary: I think we can fix the ELN side-tag rebuild problems and make
> the composes more reliable if we change the mechanism for kicking off
> rebuilds. I'm soliciting feedback to help identify potential issues
> with this proposed approach.

have you considered re-using koji-shadow? It might already know
everything you need ...


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: GNOME on Wayland does not work on latest Rawhide

[Florian Weimer]

* Mohan Boddu:

> Not sure if its related, but bolt is also having an issue:

What's your glibc version?  glibc-2.33.9000-25.fc35 is the first build
with the (then downstream-only) fix.

boltd issues have been reported as well, but I'm not sure if we have
verified that they went away with the fix for the larger issue.

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

Re: [ELN] Rebuild ordering and side-tag support

[Till Maas]

Hi,

On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote:
> Summary: I think we can fix the ELN side-tag rebuild problems and make
> the composes more reliable if we change the mechanism for kicking off
> rebuilds. I'm soliciting feedback to help identify potential issues
> with this proposed approach.

did you consider mirroring the rawhide side-tag for eln directly from
the beginning, so that a build for the rawhide side-tag triggers a
rebuild for the eln side-tag and then the eln side-tag can be merged at
a similar time as the rawhide side-tag. This way the build order would
be the same (except if there are wait-repo delays that are not visible
for the eln automation) and the build load would be distributed.

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

F35 Change: Boost 1.76 upgrade (System-Wide Change proposal)

[Ben Cotton]

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


== Summary ==
This change brings Boost 1.76 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.

== Owner ==

* Name: [[User:trodgers| Thomas Rodgers]]
* Email: trodg...@redhat.com


== Detailed Description ==

The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is absent from Boost, this entails rebuilding of
all dependent packages. This also entails the change owner assisting
maintainers of client packages in decoding cryptic boost-ese seen in
output from g++.

The equivalent changes for previous releases were
[[Changes/F34Boost175]], [[Changes/F33Boost173]],
[[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora
29 Change]], [[Changes/F28Boost166|Fedora 28 Change]],
[[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora
26 Change]], [[Changes/F25Boost161|Fedora 25 Change]],
[[Changes/F24Boost160|Fedora 24 Change]],
[[Changes/F23Boost159|Fedora 23 Change]] and
[[Changes/F22Boost158|Fedora 22 Change]].

== Benefit to Fedora ==

Fedora 35 includes Boost 1.76

Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.76 does not bring any new components but includes many
fixes and enhancements to existing components. Boost 1.76 also
introduces some breaking changes -

* Boost.DLL : boost::dll::import was renamed to
boost::dll::import_symbol to avoid collision with C++20 import
keyword.
* Boost.Math : Drops C++03 support.
* Boost.Multiprecision : Explicitly requires C++11 or later.

== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f35-boost"
[https://docs.pagure.org/releng/sop_adding_side_build_targets.html
build system tag]
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): https://pagure.io/releng/issue/9474
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).

* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.

* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.

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


== Upgrade/compatibility impact ==
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too much of a problem and could always
be resolved before deadline.

== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(`dnf install boost`) on Fedora and checking that it does not break
other packages (see below for a way to obtain a list of boost
clients).


== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.
* Developers using `bjam` to build their own software will need to
switch to using the new name for the tool, `b2`

== Dependencies ==
Packages that must be rebuilt:
$ dnf repoquery -s --releasever=rawhide --whatrequires
libboost\* --disablerepo=* --enablerepo=fedora | sort -u

All clients:
$ dnf repoquery --releasever=rawhide --archlist=src
--whatrequires boost-devel --disablerepo='*'
--enablerepo=fedora-source

== Contingency Plan ==

* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F34 with Boost 1.73, which is already in rawhide. It
would also be possible to ship the 1.74.0 which would still be newer
than in current Fedora releases and contains numerous fixes and
improvements to existing Boost components.

* Blocks release? No
* Blocks product? None


== Documentation ==
* https://www.boost.org/users/history/version_1_76_0.html (released on
16 April 2021)
* https://www.boost.org/users/history/version_1_75_0.html (released on
11 December 2020)
* https://www.boost.org/users/history/version_1_74_0.html (released on
14 August 2020)
* https://www.boost.org/users/history/version_1_73_0.html (released on
28 April 2020)
* https://www.boost.org/users/history/version_1_72_0.html (released on
11 December 2019)
* https://www.boost.org/users/history/version_1_71_0.html (released on
19 August 2019)
* https://www.boost.org/users/history/version_1_70_0.html (released on
12 April 2019)
* https://www.boost.org/development/index.html

== Release Notes 

F35 Change: Boost 1.76 upgrade (System-Wide Change proposal)

[Ben Cotton]

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


== Summary ==
This change brings Boost 1.76 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.

== Owner ==

* Name: [[User:trodgers| Thomas Rodgers]]
* Email: trodg...@redhat.com


== Detailed Description ==

The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is absent from Boost, this entails rebuilding of
all dependent packages. This also entails the change owner assisting
maintainers of client packages in decoding cryptic boost-ese seen in
output from g++.

The equivalent changes for previous releases were
[[Changes/F34Boost175]], [[Changes/F33Boost173]],
[[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora
29 Change]], [[Changes/F28Boost166|Fedora 28 Change]],
[[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora
26 Change]], [[Changes/F25Boost161|Fedora 25 Change]],
[[Changes/F24Boost160|Fedora 24 Change]],
[[Changes/F23Boost159|Fedora 23 Change]] and
[[Changes/F22Boost158|Fedora 22 Change]].

== Benefit to Fedora ==

Fedora 35 includes Boost 1.76

Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.76 does not bring any new components but includes many
fixes and enhancements to existing components. Boost 1.76 also
introduces some breaking changes -

* Boost.DLL : boost::dll::import was renamed to
boost::dll::import_symbol to avoid collision with C++20 import
keyword.
* Boost.Math : Drops C++03 support.
* Boost.Multiprecision : Explicitly requires C++11 or later.

== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f35-boost"
[https://docs.pagure.org/releng/sop_adding_side_build_targets.html
build system tag]
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): https://pagure.io/releng/issue/9474
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).

* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.

* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.

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


== Upgrade/compatibility impact ==
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too much of a problem and could always
be resolved before deadline.

== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(`dnf install boost`) on Fedora and checking that it does not break
other packages (see below for a way to obtain a list of boost
clients).


== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.
* Developers using `bjam` to build their own software will need to
switch to using the new name for the tool, `b2`

== Dependencies ==
Packages that must be rebuilt:
$ dnf repoquery -s --releasever=rawhide --whatrequires
libboost\* --disablerepo=* --enablerepo=fedora | sort -u

All clients:
$ dnf repoquery --releasever=rawhide --archlist=src
--whatrequires boost-devel --disablerepo='*'
--enablerepo=fedora-source

== Contingency Plan ==

* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F34 with Boost 1.73, which is already in rawhide. It
would also be possible to ship the 1.74.0 which would still be newer
than in current Fedora releases and contains numerous fixes and
improvements to existing Boost components.

* Blocks release? No
* Blocks product? None


== Documentation ==
* https://www.boost.org/users/history/version_1_76_0.html (released on
16 April 2021)
* https://www.boost.org/users/history/version_1_75_0.html (released on
11 December 2020)
* https://www.boost.org/users/history/version_1_74_0.html (released on
14 August 2020)
* https://www.boost.org/users/history/version_1_73_0.html (released on
28 April 2020)
* https://www.boost.org/users/history/version_1_72_0.html (released on
11 December 2019)
* https://www.boost.org/users/history/version_1_71_0.html (released on
19 August 2019)
* https://www.boost.org/users/history/version_1_70_0.html (released on
12 April 2019)
* https://www.boost.org/development/index.html

== Release Notes 

Re: [ELN] Rebuild ordering and side-tag support

[Kevin Fenzi]

On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote:
> Summary: I think we can fix the ELN side-tag rebuild problems and make
> the composes more reliable if we change the mechanism for kicking off
> rebuilds. I'm soliciting feedback to help identify potential issues
> with this proposed approach.

I wonder if it would be better/possible to take builds in the order in
which they were built in the side tag with wait-repos between?

ie, chain build the builds from the side tag based on when they were
tagged into it? Unless maintainers make some mistake they would do
things in the order they need to build, no?

I guess the downside is that this would be linear, and that could take a
long time on a large sidetag, but it should work without having to tag
in the f34 build?

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

[Bug 1976029] perl-IPC-Shareable-1.04 is available

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-06-28 18:58:53



--- Comment #6 from Tom "spot" Callaway  ---
1.04 in rawhide.


-- 
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: Announcing fmt library soversion bump

[Richard Shaw]

Here's the projects that are affected:

0ad
bear
ceph
dolphin-emu
domoticz
fb303
fbthrift
folly
freeopcua
gerbera
libsemigroups
mkvtoolnix
nheko
spdlog
watchman
waybar
zswap-cli

You may want to send notification emails to the maintainers directly using
the -maintain...@fedoraproject.org email addresses since you can't
perform the rebuilds yourself.

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

Re: GNOME on Wayland does not work on latest Rawhide

[Mohan Boddu]

Not sure if its related, but bolt is also having an issue:

Stack trace of thread 10114:
#0  0x7fbde5b3993d n/a (libc.so.6 + 0x17c93d)
#1  0x7fbde5ebc688 g_strdup (libglib-2.0.so.0 + 0x72688)
#2  0x7fbde5c4e685 value_collect_string
(libgobject-2.0.so.0 + 0x33685)
#3  0x7fbde5c3fa9c g_object_set_valist
(libgobject-2.0.so.0 + 0x24a9c)
#4  0x7fbde5c3fd74 g_object_set
(libgobject-2.0.so.0 + 0x24d74)
#5  0x5587d18a6c49 handle_udev_device_event (boltd
+ 0x12c49)
#6  0x5587d18addcb bolt_manager_initialize (boltd + 0x19dcb)
#7  0x7fbde5ceebfa g_initable_new_valist
(libgio-2.0.so.0 + 0x78bfa)
#8  0x7fbde5ceecad g_initable_new (libgio-2.0.so.0
+ 0x78cad)
#9  0x5587d18a29ec on_bus_acquired (boltd + 0xe9ec)
#10 0x7fbde5d86196 connection_get_cb.lto_priv.0
(libgio-2.0.so.0 + 0x110196)
#11 0x7fbde5d24a7a g_task_return_now
(libgio-2.0.so.0 + 0xaea7a)
#12 0x7fbde5d24c7b g_task_return (libgio-2.0.so.0 + 0xaec7b)
#13 0x7fbde5d837c2 bus_get_async_initable_cb
(libgio-2.0.so.0 + 0x10d7c2)
#14 0x7fbde5d24a7a g_task_return_now
(libgio-2.0.so.0 + 0xaea7a)
#15 0x7fbde5d24abd complete_in_idle_cb
(libgio-2.0.so.0 + 0xaeabd)
#16 0x7fbde5e9b1cb g_idle_dispatch
(libglib-2.0.so.0 + 0x511cb)
#17 0x7fbde5e9ef4f g_main_context_dispatch
(libglib-2.0.so.0 + 0x54f4f)
#18 0x7fbde5ef3628
g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa9628)
#19 0x7fbde5e9e513 g_main_loop_run
(libglib-2.0.so.0 + 0x54513)
#20 0x5587d18a1aa4 main (boltd + 0xdaa4)
#21 0x7fbde59e87e0 n/a (libc.so.6 + 0x2b7e0)
#22 0x7fbde59e888c n/a (libc.so.6 + 0x2b88c)
#23 0x5587d18a1dae _start (boltd + 0xddae)

Stack trace of thread 10118:
#0  0x7fbde5ac00af n/a (libc.so.6 + 0x1030af)
#1  0x7fbde5ef35bc
g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa95bc)
#2  0x7fbde5e9c683 g_main_context_iteration
(libglib-2.0.so.0 + 0x52683)
#3  0x7fbde5e9c6d1 glib_worker_main
(libglib-2.0.so.0 + 0x526d1)
#4  0x7fbde5ecd6a2 g_thread_proxy
(libglib-2.0.so.0 + 0x836a2)
#5  0x7fbde5a49207 n/a (libc.so.6 + 0x8c207)
#6  0x7fbde5acbdd4 n/a (libc.so.6 + 0x10edd4)

Stack trace of thread 10119:
#0  0x7fbde5ac574d n/a (libc.so.6 + 0x10874d)
#1  0x7fbde5eeccb3 g_cond_wait (libglib-2.0.so.0 + 0xa2cb3)
#2  0x7fbde5e6f47b
g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x2547b)
#3  0x7fbde5ecf5ea g_thread_pool_spawn_thread
(libglib-2.0.so.0 + 0x855ea)
#4  0x7fbde5ecd6a2 g_thread_proxy
(libglib-2.0.so.0 + 0x836a2)
#5  0x7fbde5a49207 n/a (libc.so.6 + 0x8c207)
#6  0x7fbde5acbdd4 n/a (libc.so.6 + 0x10edd4)

Stack trace of thread 10120:
#0  0x7fbde5ac574d n/a (libc.so.6 + 0x10874d)
#1  0x7fbde5eed2bc g_cond_wait_until
(libglib-2.0.so.0 + 0xa32bc)
#2  0x7fbde5e6f461
g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x25461)
#3  0x7fbde5e6f5e6 g_async_queue_timeout_pop
(libglib-2.0.so.0 + 0x255e6)
#4  0x7fbde5ed0639
g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x86639)
#5  0x7fbde5ecd6a2 g_thread_proxy
(libglib-2.0.so.0 + 0x836a2)
#6  0x7fbde5a49207 n/a (libc.so.6 + 0x8c207)
#7  0x7fbde5acbdd4 n/a (libc.so.6 + 0x10edd4)

Stack trace of thread 10121:
#0  0x7fbde5ac00af n/a (libc.so.6 + 0x1030af)
#1  0x7fbde5ef35bc
g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa95bc)
#2  0x7fbde5e9e513 g_main_loop_run
(libglib-2.0.so.0 + 0x54513)
#3  0x7fbde5d86d5a
gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x110d5a)
#4  0x7fbde5ecd6a2 g_thread_proxy
(libglib-2.0.so.0 + 0x836a2)
#5  0x7fbde5a49207 n/a (libc.so.6 + 0x8c207)
#6  0x7fbde5acbdd4 n/a (libc.so.6 + 0x10edd4)

On Thu, Jun 24, 2021 at 5:49 AM Florian Weimer  wrote:
>
> * Florian Weimer:
>
> > We could use some basic GNOME SHell debugging help here.  Ideally, we'd
> > like to run GNOME Shell in such a way that it does not perform X
> > fallback and does not re-exec itself, and uses a specified VT (so that
> > we can launch it over an SSH session).
> >
> > (This is about bug 1974970.)
>
> I got 

[Bug 1977021] New: perl-HTTP-Message-6.33 is available

[bugzilla]

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

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



Latest upstream release: 6.33
Current version/release in rawhide: 6.32-2.fc35
URL: http://search.cpan.org/dist/HTTP-Message/

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


-- 
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: use unit names in systemd output by default?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 28, 2021 at 10:31:09AM -, Paweł Marciniak wrote:
> > What log analysis tools is this change likely to break?
> If you set StatusUnitFormat to "name" or "description", then nothing will 
> change and it will work as always.

Also, you can't base "analysis tools" on the Description strings… They change
all the time!

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: F35 Change: LLVM 13 (Self-Contained Change proposal)

[Otto Urpelainen]

Ben Cotton kirjoitti 28.6.2021 klo 19.57:

https://fedoraproject.org/wiki/Changes/LLVM-13

== Summary ==
Update all llvm sub-projects in Fedora to version 13.

== Scope ==
* Proposal owners:
** When the upstream LLVM project releases version 12.0.0-rc1 (Late
July 2021), package this and build it into the side tag.


This is a copy-parse error and should be 13.0.0-rc1, right?

Otto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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-IoT-34-20210628.0 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test not failed in Fedora-IoT-34-20210624.0):

ID: 918775  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/918775

Old failures (same test failed in Fedora-IoT-34-20210624.0):

ID: 918766  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/918766
ID: 918770  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/918770
ID: 918772  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/918772
ID: 918779  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/918779
ID: 918783  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/918783

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

Old soft failures (same test soft failed in Fedora-IoT-34-20210624.0):

ID: 918761  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/918761

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.07 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/915594#downloads
Current test data: https://openqa.fedoraproject.org/tests/918756#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

F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec

== Summary ==

OpenDNSSec' enforcer has a (deprecated) -sha1 CLI option that brings
back the old behavior, e.g. include the SHA1 version of the DS. As
SHA1 use is deprecated in favour of SHA256, disable the -sha1 CLI knob
so that it only displays a warning.

== Owner ==
* Name: [[User:fcami| François Cami]]
* Email: fc...@redhat.com


== Detailed Description ==

OpenDNSSec changed the default behavior to not include SHA1 DS by
default, and added the -sha1 knob as an immediately-deprecated
compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
default ‘ods-enforcer key export –ds’ included the SHA1 version of the
DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
use the –sha1 flag. This flag is immediately deprecated and will be
removed from future versions of OpenDNSSEC." (see ChangeLog:
https://www.opendnssec.org/archive/releases/ ).

The proposal is to disable the -sha1 knob in Fedora. I will also open
an issue upstream to remove all the sha1-related code.

Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
[from ICANN] (2020-1-24): "Now is the time for administrators of zones
at all levels of the DNS to stop using SHA-1 and change to algorithms
using stronger hashes."


== Benefit to Fedora ==
* This change makes sure OpenDNSSec in Fedora follows ICANN's
guidelines and does not propose SHA1 DS. This is is needed given the
[https://sha-mbles.github.io/ latest attacks against SHA-1]. More
in-depth articles are available
[https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
[https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/
there].
* This change is aligned with previous features:
** [[Features/StrongerHashes]]
** [[Changes/StrongCryptoSettings]]
** [[Changes/StrongCryptoSettings2]]

== Scope ==
* Proposal owners:
Patch the enforcer so that bsha1 is not honored anymore:
 ./enforcer/src/keystate/keystate_export_cmd.c-271-break;
 ./enforcer/src/keystate/keystate_export_cmd.c-272-case 's':
 ./enforcer/src/keystate/keystate_export_cmd.c:273:bsha1 = 1;
 ./enforcer/src/keystate/keystate_export_cmd.c-274-break;
 ./enforcer/src/keystate/keystate_export_cmd.c-275-default:

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


== Upgrade/compatibility impact ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.
This change might break (very old) clients that only recognize SHA-1
but these should already be broken (on the Internet at least) because
the root zone is signed with SHA-256 only.


== How To Test ==


== User Experience ==

OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
With this change, this will no longer be possible. The migration from
SHA1 is underway anyway.


== Dependencies ==
FreeIPA (freeipa-server-dns) depends on OpenDNSSec.


== Contingency Plan ==
* Contingency mechanism: Keep the current -sha1 knob's behavior
(remove the patch).
* Contingency deadline: Beta freeze
* Blocks release? No, unless the change breaks IPA.


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

F35 Change: Golang 1.17 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/golang1.17

== Summary ==
Rebase of Golang package to upcoming version 1.17 in Fedora 35,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).

== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: a...@redhat.com, jca...@redhat.com


== Detailed Description ==

Rebase of Golang package to upcoming version 1.17 in Fedora 35. Golang
1.17 is scheduled to be released in August 2021.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.

== Benefit to Fedora ==

Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.17 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.

== Scope ==
* Proposal owners: Rebase Golang package in Fedora 35, help resolve
possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild.
* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
None

== How To Test ==
;0.
:a) Install golang 1.17 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.17 should work as expected.

== User Experience ==

None

== Dependencies ==

dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'


Omitted due to the number of packages listed ~1600.


Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.

== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.16.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
https://tip.golang.org/doc/go1.17



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

F35 Change: Rebase firewalld to upstream v1.0.0 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/firewalld-1.0.0

== Summary ==
Firewalld upstream is about to release v1.0.0. As indicated by the
major version bump this includes behavioral changes.

== Owner ==
* Name: [[User:erig0| Eric Garver]]
* Email: egar...@redhat.com


== Detailed Description ==
Firewalld v1.0.0 includes breaking changes meant to improve the
overall health of the project. The majority of the changes are
centered around improving and strengthening the zone concept. All
breaking changes are detailed in depth in the
[https://firewalld.org/2021/06/the-upcoming-1-0-0 upstream blog].

Major changes:

* Reduced dependencies
* Intra-zone forwarding by default
* NAT rules moved to inet family (reduced rule set)
* Default target is now similar to reject
* ICMP blocks and block inversion only apply to input, not forward
* tftp-client service has been removed
* iptables backend is deprecated
* Direct interface is deprecated
* CleanupModulesOnExit defaults to no (kernel modules not unloaded)


== Benefit to Fedora ==
The major benefit to Fedora is more predictability in the stock
firewall. In particular, "Default target is now similar to reject"
addresses many subtle issues encountered by users. "NAT rules moved to
inet family" also significantly reduces the rule set size for users of
`ipset`s.

== Scope ==
* Proposal owners: Changes are isolated to firewalld, but given
firewalld is core a System Wide Change is being filed.
* Other developers: None. Isolated change.

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


== Upgrade/compatibility impact ==
* Most configurations will migrate. No intervention required.
** Exceptions
*** configurations that utilize `tftp-client` service will have
firewalld start in `failed` state because the service has been
removed. As noted in the upstream blog this service has ''never''
worked properly.
* Zones that users have not modified will now have intra-zone
forwarding enabled.
** for this to occur the user must ''not'' have added an interface,
service, port, etc. to the zone
** minimal concern because this also means the zone was not in use,
the exception being an unmodified default zone, e.g.
`FedoraWorkstation`

== How To Test ==
Testing for this rebase should revolve around integrations.

* libvirt
** verify VMs still have network access
* podman
** verify containers still have network access
** verify forwarding ports via podman still works
* NetworkManager
** verify connection sharing still works

== User Experience ==
N/A

== Dependencies ==
firewalld has yet to release v1.0.0. It is expected in early July.

== Contingency Plan ==
* Contingency mechanism: revert package to v0.9.z (what f34 uses)
* Contingency deadline: July 27, 2021
* Blocks release? No

== Documentation ==
https://firewalld.org/2021/06/the-upcoming-1-0-0

== Release Notes ==
firewalld has been rebased to v1.0.0. This includes some breaking
changes that may affect users.

Major changes:

* Reduced dependencies
* Intra-zone forwarding by default
* NAT rules moved to inet family (reduced rule set)
* Default target is now similar to reject
* ICMP blocks and block inversion only apply to input, not forward
* tftp-client service has been removed
* iptables backend is deprecated
* Direct interface is deprecated
* CleanupModulesOnExit defaults to no (kernel modules not unloaded)

Full details on the upstream blog:
https://firewalld.org/2021/06/the-upcoming-1-0-0


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

F35 Change: LLVM 13 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LLVM-13

== Summary ==
Update all llvm sub-projects in Fedora to version 13.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 13, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang12 and llvm12 will be added to ensure that
packages that currently depend on clang and llvm version 12 libraries
will continue to work.


== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request a side-tag.
** Build llvm12 and clang12 into the side-tag.
** When the upstream LLVM project releases version 12.0.0-rc1 (Late
July 2021), package this and build it into the side tag.
** Merge side-tag into rawhide prior to the f35 branch date.
** Continue packaging newer release candidates into rawhide and f35
until the final release is complete (Late September 2021)

* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang12 and llvm12
compatibility packages if they want to rebuild their package and it
does not work with LLVM 13 yet.  The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
13 is added to Fedora.  The compatibility packages will ensure that
already built packages continue to work.

* Release engineering: [https://pagure.io/releng/issues/10179]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
This change should not impact upgradeability.

== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
13.

== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.

== Dependencies ==
This change can be made without updating any other packages.  However,
as mention before, packages that need to use LLVM 12 will need to
update their spec file on their first rebuild after this change.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?):  If there are
major problems with LLVM 13, the compatibility package provide a way
for other packages to continue using LLVM 12.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 13:

* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
* flang
* mlir
* polly
* libclc

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

F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec

== Summary ==

OpenDNSSec' enforcer has a (deprecated) -sha1 CLI option that brings
back the old behavior, e.g. include the SHA1 version of the DS. As
SHA1 use is deprecated in favour of SHA256, disable the -sha1 CLI knob
so that it only displays a warning.

== Owner ==
* Name: [[User:fcami| François Cami]]
* Email: fc...@redhat.com


== Detailed Description ==

OpenDNSSec changed the default behavior to not include SHA1 DS by
default, and added the -sha1 knob as an immediately-deprecated
compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
default ‘ods-enforcer key export –ds’ included the SHA1 version of the
DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
use the –sha1 flag. This flag is immediately deprecated and will be
removed from future versions of OpenDNSSEC." (see ChangeLog:
https://www.opendnssec.org/archive/releases/ ).

The proposal is to disable the -sha1 knob in Fedora. I will also open
an issue upstream to remove all the sha1-related code.

Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
[from ICANN] (2020-1-24): "Now is the time for administrators of zones
at all levels of the DNS to stop using SHA-1 and change to algorithms
using stronger hashes."


== Benefit to Fedora ==
* This change makes sure OpenDNSSec in Fedora follows ICANN's
guidelines and does not propose SHA1 DS. This is is needed given the
[https://sha-mbles.github.io/ latest attacks against SHA-1]. More
in-depth articles are available
[https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
[https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/
there].
* This change is aligned with previous features:
** [[Features/StrongerHashes]]
** [[Changes/StrongCryptoSettings]]
** [[Changes/StrongCryptoSettings2]]

== Scope ==
* Proposal owners:
Patch the enforcer so that bsha1 is not honored anymore:
 ./enforcer/src/keystate/keystate_export_cmd.c-271-break;
 ./enforcer/src/keystate/keystate_export_cmd.c-272-case 's':
 ./enforcer/src/keystate/keystate_export_cmd.c:273:bsha1 = 1;
 ./enforcer/src/keystate/keystate_export_cmd.c-274-break;
 ./enforcer/src/keystate/keystate_export_cmd.c-275-default:

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


== Upgrade/compatibility impact ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.
This change might break (very old) clients that only recognize SHA-1
but these should already be broken (on the Internet at least) because
the root zone is signed with SHA-256 only.


== How To Test ==


== User Experience ==

OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
With this change, this will no longer be possible. The migration from
SHA1 is underway anyway.


== Dependencies ==
FreeIPA (freeipa-server-dns) depends on OpenDNSSec.


== Contingency Plan ==
* Contingency mechanism: Keep the current -sha1 knob's behavior
(remove the patch).
* Contingency deadline: Beta freeze
* Blocks release? No, unless the change breaks IPA.


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

F35 Change: Golang 1.17 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/golang1.17

== Summary ==
Rebase of Golang package to upcoming version 1.17 in Fedora 35,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).

== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: a...@redhat.com, jca...@redhat.com


== Detailed Description ==

Rebase of Golang package to upcoming version 1.17 in Fedora 35. Golang
1.17 is scheduled to be released in August 2021.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.

== Benefit to Fedora ==

Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.17 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.

== Scope ==
* Proposal owners: Rebase Golang package in Fedora 35, help resolve
possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild.
* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
None

== How To Test ==
;0.
:a) Install golang 1.17 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.17 should work as expected.

== User Experience ==

None

== Dependencies ==

dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'


Omitted due to the number of packages listed ~1600.


Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.

== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.16.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
https://tip.golang.org/doc/go1.17



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

F35 Change: Rebase firewalld to upstream v1.0.0 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/firewalld-1.0.0

== Summary ==
Firewalld upstream is about to release v1.0.0. As indicated by the
major version bump this includes behavioral changes.

== Owner ==
* Name: [[User:erig0| Eric Garver]]
* Email: egar...@redhat.com


== Detailed Description ==
Firewalld v1.0.0 includes breaking changes meant to improve the
overall health of the project. The majority of the changes are
centered around improving and strengthening the zone concept. All
breaking changes are detailed in depth in the
[https://firewalld.org/2021/06/the-upcoming-1-0-0 upstream blog].

Major changes:

* Reduced dependencies
* Intra-zone forwarding by default
* NAT rules moved to inet family (reduced rule set)
* Default target is now similar to reject
* ICMP blocks and block inversion only apply to input, not forward
* tftp-client service has been removed
* iptables backend is deprecated
* Direct interface is deprecated
* CleanupModulesOnExit defaults to no (kernel modules not unloaded)


== Benefit to Fedora ==
The major benefit to Fedora is more predictability in the stock
firewall. In particular, "Default target is now similar to reject"
addresses many subtle issues encountered by users. "NAT rules moved to
inet family" also significantly reduces the rule set size for users of
`ipset`s.

== Scope ==
* Proposal owners: Changes are isolated to firewalld, but given
firewalld is core a System Wide Change is being filed.
* Other developers: None. Isolated change.

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


== Upgrade/compatibility impact ==
* Most configurations will migrate. No intervention required.
** Exceptions
*** configurations that utilize `tftp-client` service will have
firewalld start in `failed` state because the service has been
removed. As noted in the upstream blog this service has ''never''
worked properly.
* Zones that users have not modified will now have intra-zone
forwarding enabled.
** for this to occur the user must ''not'' have added an interface,
service, port, etc. to the zone
** minimal concern because this also means the zone was not in use,
the exception being an unmodified default zone, e.g.
`FedoraWorkstation`

== How To Test ==
Testing for this rebase should revolve around integrations.

* libvirt
** verify VMs still have network access
* podman
** verify containers still have network access
** verify forwarding ports via podman still works
* NetworkManager
** verify connection sharing still works

== User Experience ==
N/A

== Dependencies ==
firewalld has yet to release v1.0.0. It is expected in early July.

== Contingency Plan ==
* Contingency mechanism: revert package to v0.9.z (what f34 uses)
* Contingency deadline: July 27, 2021
* Blocks release? No

== Documentation ==
https://firewalld.org/2021/06/the-upcoming-1-0-0

== Release Notes ==
firewalld has been rebased to v1.0.0. This includes some breaking
changes that may affect users.

Major changes:

* Reduced dependencies
* Intra-zone forwarding by default
* NAT rules moved to inet family (reduced rule set)
* Default target is now similar to reject
* ICMP blocks and block inversion only apply to input, not forward
* tftp-client service has been removed
* iptables backend is deprecated
* Direct interface is deprecated
* CleanupModulesOnExit defaults to no (kernel modules not unloaded)

Full details on the upstream blog:
https://firewalld.org/2021/06/the-upcoming-1-0-0


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

F35 Change: LLVM 13 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LLVM-13

== Summary ==
Update all llvm sub-projects in Fedora to version 13.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 13, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang12 and llvm12 will be added to ensure that
packages that currently depend on clang and llvm version 12 libraries
will continue to work.


== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request a side-tag.
** Build llvm12 and clang12 into the side-tag.
** When the upstream LLVM project releases version 12.0.0-rc1 (Late
July 2021), package this and build it into the side tag.
** Merge side-tag into rawhide prior to the f35 branch date.
** Continue packaging newer release candidates into rawhide and f35
until the final release is complete (Late September 2021)

* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang12 and llvm12
compatibility packages if they want to rebuild their package and it
does not work with LLVM 13 yet.  The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
13 is added to Fedora.  The compatibility packages will ensure that
already built packages continue to work.

* Release engineering: [https://pagure.io/releng/issues/10179]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
This change should not impact upgradeability.

== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
13.

== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.

== Dependencies ==
This change can be made without updating any other packages.  However,
as mention before, packages that need to use LLVM 12 will need to
update their spec file on their first rebuild after this change.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?):  If there are
major problems with LLVM 13, the compatibility package provide a way
for other packages to continue using LLVM 12.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 13:

* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
* flang
* mlir
* polly
* libclc

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

[ELN] Rebuild ordering and side-tag support

[Stephen Gallagher]

Summary: I think we can fix the ELN side-tag rebuild problems and make
the composes more reliable if we change the mechanism for kicking off
rebuilds. I'm soliciting feedback to help identify potential issues
with this proposed approach.


## Background Information ##
Currently in ELN, merging a side-tag into Rawhide results in all of
the packages from that side-tag being rebuilt concurrently in ELN.
This leads to two problems:

 1. Side-tags containing large numbers of package builds will trigger
many ELN builds at the same time, possibly overwhelming available
resources on the ELN automation systems.
 2. Many (most?) side-tags exist to ensure that packages are built in
a particular order so as to ensure that they are built after their
dependencies. Launching all the rebuilds concurrently means that many
of the builds may succeed *and still be wrong* (such as if they are
built against an older soname).

## Proposed Solution ##
I had a discussion with Miro Hrončok this morning where we tackled
this problem and may have come up with a workable solution for 99% of
cases. Instead of treating side-tags as a special event and trying to
sort the builds such that they are built in the same order, we can
instead tag in the Rawhide packages first, then issue the rebuilds
together. With the Rawhide packages available, we won't need to worry
about the ordering, because the dependencies will already be present
in a sufficiently-recent version. As a bonus, we'll reduce the
likelihood of broken ELN composes, since if an ELN rebuild fails, the
Rawhide version will still be present to satisfy dependencies.

In greater detail:

Whenever a build is tagged into the 'f35' tag (later, whatever tag
matches Rawhide), ELN automation would take the following steps:

 * Identify whether this package is on the list of packages that ELN rebuilds[1]
 * Tag the Rawhide build into the 'eln' tag (so it is now tagged with
both 'f35' and 'eln')
 * Enqueue a Koji build against the 'eln' target from the same Git commit

The queue mentioned above should be maintained in a separate thread
and used to submit tasks in batches to avoid overloading the
infrastructure. If the Koji build against the 'eln' target fails, the
Rawhide build will remain as the most-recently-tagged version of the
package in ELN and become part of the compose until the ELN rebuild
can be fixed.

Note that this process would apply to ALL builds in Rawhide, not just
those coming from side-tags. There would be no difference in behavior
between standard direct builds and side-tag merged builds.


## Known potential issues ##

 * Some packages may auto-detect functionality based on functionality
made available by one of their dependencies. If the Rawhide and ELN
versions of that dependency differ in visible functionality, then
building an ELN package with a Rawhide version of its dependency could
result in unexpected behavior. I believe this issue to be rare and
generally best handled by the packager as the subject matter expert.
They'd just need to bump the release number and rebuild the package in
ELN. Alternatively, if this is known to be regularly problematic for a
package, the maintainer can opt out of the automatic rebuild and work
out a strategy with the ELN SIG for dealing with it.



[1] This will be the set of packages provided by
https://tiny.distro.builders/view--view-eln.html minus any packages
that have opted out of automatic rebuilds (they perform manual
rebuilds for ELN).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 1976029] perl-IPC-Shareable-1.04 is available

[bugzilla]

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



--- Comment #5 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/M/MS/MSOUTH/IPC-Shareable-1.04.tar.gz to
./IPC-Shareable-1.04.tar.gz


-- 
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 1976029] perl-IPC-Shareable-1.04 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-IPC-Shareable-1.03 is  |perl-IPC-Shareable-1.04 is
   |available   |available



--- Comment #4 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.04
Current version/release in rawhide: 1.00-1.fc35
URL: http://search.cpan.org/dist/IPC-Shareable

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


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

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 7/199 (x86_64), 11/134 (aarch64)

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

ID: 918241  Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/918241
ID: 918376  Test: aarch64 Server-dvd-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/918376
ID: 918401  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/918401
ID: 918511  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/918511

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

ID: 918257  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/918257
ID: 918259  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/918259
ID: 918265  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/918265
ID: 918268  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/918268
ID: 918301  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/918301
ID: 918310  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/918310
ID: 918382  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/918382
ID: 918384  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/918384
ID: 918388  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/918388
ID: 918389  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/918389
ID: 918390  Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/918390
ID: 918503  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/918503
ID: 918514  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/918514
ID: 918515  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/918515

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

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

ID: 918328  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/918328
ID: 918335  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/918335
ID: 918392  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/918392
ID: 918418  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/918418
ID: 918427  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/918427
ID: 918457  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/918457

Passed openQA tests: 189/199 (x86_64), 106/134 (aarch64)

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

ID: 918216  Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/918216
ID: 918274  Test: x86_64 Workstation-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/918274
ID: 918348  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/918348
ID: 918485  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/918485
ID: 918502  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/918502
ID: 918510  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/918510
ID: 918535  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/918535

Skipped non-gating openQA tests: 14 of 333

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.28 to 0.17
Previous test data: https://openqa.fedoraproject.org/tests/917376#downloads
Current test data: https://openqa.fedoraproject.org/tests/918213#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 0.14 to 0.32
Previous test 

Rules for adding users to groups at install time by default

[Vladimir Slavik]

Hello,
anaconda has a bug about adding new users to the "vboxsf" group to help
with sharing folders.

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

As far as I can tell, the group depends on having the guest additions
package installed. Without detecting the platform, the easiest way to
fulfill the request is to just try adding the user to the group and
skipping if it doesn't exist.

Is there any policy about this - adding users to groups?

Best,
Vladimir


-- 
Vladimír Slávik 
Software Engineer, Platform Engineering
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 1976778] perl-SNMP-Info-3.73 is available

[bugzilla]

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



--- Comment #4 from Upstream Release Monitoring 
 ---
An unexpected error occurred while creating the scratch build and has been
automatically reported. Sorry!


-- 
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 1976778] perl-SNMP-Info-3.73 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-SNMP-Info-3.72 is  |perl-SNMP-Info-3.73 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.73
Current version/release in rawhide: 3.71-3.fc35
URL: http://search.cpan.org/dist/SNMP-Info/

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


-- 
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 1976758] Upgrade perl-Net-Telnet to 3.05

[bugzilla]

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

Robin Lee  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Net-Telnet-3.05-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-06-28 14:47:29




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

Fedora-IoT-35-20210628.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 918568  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/918568

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

ID: 918559  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/918559
ID: 918563  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/918563
ID: 918565  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/918565
ID: 918566  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/918566
ID: 918567  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/918567
ID: 918572  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/918572
ID: 918574  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/918574
ID: 918575  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/918575
ID: 918576  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/918576

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-20210626.0):

ID: 918548  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/918548
ID: 918549  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/918549
ID: 918554  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/918554
ID: 918564  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/918564

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

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.84 to 1.07
Previous test data: https://openqa.fedoraproject.org/tests/916873#downloads
Current test data: https://openqa.fedoraproject.org/tests/918564#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: New RPM submission

[Matthew Miller]

On Sat, Jun 26, 2021 at 10:34:02PM +0200, Emmanuel Seyman wrote:
> You need to seek out a sponsor:
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Probably in this case, someone else with knowledge of / interest in Dovecot
and the related ecosystems would make sense.

-- 
Matthew Miller

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

Re: [Test-Announce] 2021-06-28 @ 15:00 UTC - Fedora QA Meeting

[Luna Jernberg]

Hello!

is this meeting on Libera or Freenode, the email says Freenode but i think
thats a copy paste error right?

On Sun, Jun 27, 2021 at 5:25 PM Adam Williamson 
wrote:

> # Fedora Quality Assurance Meeting
> # Date: 2021-06-28
> # Time: 15:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location: #fedora-meeting on irc.freenode.net
>
> Greetings testers!
>
> We didn't meet for a couple of weeks, so let's get together and check in.
>
> If anyone has any other items for the agenda, please reply to this
> email and suggest them! Thanks.
>
> == Proposed Agenda Topics ==
>
> 1. Previous meeting follow-up
> 2. Fedora 35 status and Change check-in
> 3. Test Day / community event status
> 4. Open floor
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: [HEADS UP] Planned Sphinx update to 4.x - many packages fail to build

[Karolina Surma]

Hello,

I'd like to inform you that python-sphinx 4.0.2 has landed in Rawhide as 
planned [0].


This means you no longer need to use the test Copr. You can now test 
your packages using Koji scratch build as you're used to.


koji build --scratch rawhide 


Thank you to all who have helped with mitigating the impact of the upgrade.

There are still some packages with issues whose maintainers I've BCC'd. 
Please take a look at them. If you already have, please ignore the 
notification.


I'll be opening Bugzillas for the remaining packages, so that the 
information is not lost in the thread.


Feel free to reach me through this thread or ping on #fedora-python on 
libera.chat (ksurma).



Cheers,

Karolina Surma


[0] https://fedoraproject.org/wiki/Changes/Sphinx4



Maintainers by package:
Mayavi   chedi orion
ansible  kevin toshio wzzrd
ara  dmsimard
arbor    ankursinha
botan    thm
condor   bbockelm bcotton eerlands matt matyas stevetraylen 
tstclair ttheisen valtri
copr-keygen  clime dturecek frostyx msuchy praiskup - 
blocked by python-sphinxcontrib-httpdomain FTI

gcc  aoliva jakub law mpolacek
ghc  petersen
php-opencloud-openstack lcts
python-djvulibre terrycloth
python-f5-sdk    xavierb
python-glue  lgs
python-h2    eclipseo
python-libpysal  qulogic
python-patsy sergiopr
python-pkginfo   thrnciar
python-pycryptodomex melmorabity
python-pynetdicom    alciregi
python-pyswarms  iztokf
python-rjsmin    kwizart mrunge
python-ruffus    qulogic
python-sphinx-tabs   hobbes1069
python-sphinxcontrib-asyncio fab
python-sphinxcontrib-httpdomain dcallagh
python-sphinxcontrib-phpdomain fab
python-sphinxcontrib-trio jcaratzas thm
python-whoosh    rkuska sgallagh
python-zarr  qulogic
rebase-helper    nforro phracek
tortoisehg   kiilerix nbecker
waiverdb gnaponie lholecek lucarval mprahl ralph vmaljulin
xeus qulogic
xtl  qulogic

Packages by maintainer:
alciregi   python-pynetdicom
ankursinha arbor
aoliva gcc
bbockelm   condor
bcotton    condor
chedi  Mayavi
clime  copr-keygen
dcallagh   python-sphinxcontrib-httpdomain
dmsimard   ara
dturecek   copr-keygen
eclipseo   python-h2
eerlands   condor
fab    python-sphinxcontrib-asyncio python-sphinxcontrib-phpdomain
frostyx    copr-keygen
gnaponie   waiverdb
hobbes1069 python-sphinx-tabs
iztokf python-pyswarms
jakub  gcc
jcaratzas  python-sphinxcontrib-trio
kevin  ansible
kiilerix   tortoisehg
kwizart    python-rjsmin
law    gcc
lcts   php-opencloud-openstack
lgs    python-glue
lholecek   waiverdb
lucarval   waiverdb
matt   condor
matyas condor
melmorabity python-pycryptodomex
mpolacek   gcc
mprahl waiverdb
mrunge python-rjsmin
msuchy copr-keygen
nbecker    tortoisehg
nforro rebase-helper
orion  Mayavi
petersen   ghc
phracek    rebase-helper
praiskup   copr-keygen
qulogic    python-libpysal python-ruffus python-zarr xeus xtl
ralph  waiverdb
rkuska python-whoosh
sergiopr   python-patsy
sgallagh   python-whoosh
stevetraylen condor
terrycloth python-djvulibre
thm    botan python-sphinxcontrib-trio
thrnciar   python-pkginfo
toshio ansible
tstclair   condor
ttheisen   condor
valtri condor
vmaljulin  waiverdb
wzzrd  ansible
xavierb    python-f5-sdk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 1136745] perl-Convert-PEM-0.08-13.fc22 FTBFS randomly: 'errstr matches decrypt failed' t/02-encode.t test fails

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2021-976a98491a has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-976a98491a


-- 
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: Requesting for package review and sponsor

[Sumantro Mukherjee]

On Mon, Jun 28, 2021 at 5:52 PM Ben Cotton  wrote:

> On Mon, Jun 28, 2021 at 6:10 AM Sumantro Mukherjee 
> wrote:
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1976464
> >
>
> I'll take the review. Sounds like an app I'd benefit from anyway. :-)
>
>
Thanks a lot, Ben!

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: 20210628.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210627.n.0
NEW: Fedora-Rawhide-20210628.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   41
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   2.10 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20210628.n.0.iso

= DROPPED IMAGES =
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20210627.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  accountsservice-0.6.55-7.fc35
Old package:  accountsservice-0.6.55-6.fc34
Summary:  D-Bus interfaces for querying and manipulating user account 
information
RPMs: accountsservice accountsservice-devel accountsservice-libs
Size: 1.22 MiB
Size change:  -29.06 KiB
Changelog:
  * Fri Jun 25 2021 Bj??rn Esser  - 0.6.55-7
  + accountsservice-0.6.55-7
  - Add patch to use yescrypt for new user passwords, fixes rhbz#1976334


Package:  blueberry-1.4.4-1.fc35
Old package:  blueberry-1.4.3-1.fc35
Summary:  Bluetooth configuration tool
RPMs: blueberry
Size: 1.22 MiB
Size change:  50 B
Changelog:
  * Sun Jun 27 2021 Mukundan Ragavan  - 1.4.4-1
  - Update to 1.4.4


Package:  bout++-4.3.2-10.fc35
Old package:  bout++-4.3.2-9.fc35
Summary:  Library for the BOUndary Turbulence simulation framework
RPMs: bout++-common bout++-doc bout++-mpich bout++-mpich-devel 
bout++-openmpi bout++-openmpi-devel python3-bout++ python3-bout++-mpich 
python3-bout++-openmpi
Size: 25.75 MiB
Size change:  -124.81 KiB
Changelog:
  * Sat Jun 26 2021 David Schw??rer  4.3.2-10
  - Split out boututils and boutdata
  - Add recommends for python packages to read data


Package:  dummy-test-package-gloster-0-4249.fc35
Old package:  dummy-test-package-gloster-0-4229.fc35
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 262.01 KiB
Size change:  1.14 KiB
Changelog:
  * Sun Jun 27 2021 packagerbot  - 0-4230
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4231
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4232
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4233
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4234
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4235
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4236
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4237
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4238
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4239
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4240
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4241
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4242
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4243
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4244
  - rebuilt

  * Sun Jun 27 2021 packagerbot  - 0-4245
  - rebuilt

  * Mon Jun 28 2021 packagerbot  - 0-4246
  - rebuilt

  * Mon Jun 28 2021 packagerbot  - 0-4247
  - rebuilt

  * Mon Jun 28 2021 packagerbot  - 0-4248
  - rebuilt

  * Mon Jun 28 2021 packagerbot  - 0-4249
  - rebuilt


Package:  fastd-22-1.fc35
Old package:  fastd-21-4.fc35
Summary:  Fast and secure tunneling daemon
RPMs: fastd
Size: 578.53 KiB
Size change:  27.28 KiB
Changelog:
  * Sun Jun 27 2021 Felix Kaechele  - 22-1
  - update to 22
  - add L2TP kmod recommends to enable L2TP offloading feature
  - add git helper macros for easier prerelease testing


Package:  fltk-1.3.6-1.fc35
Old package:  fltk-1.3.5-11.fc35
Summary:  C++ user interface toolkit
RPMs: fltk fltk-devel fltk-fluid fltk-static
Size: 29.80 MiB
Size change:  -426.04 KiB
Changelog:
  * Sun Jun 27 2021 Richard Shaw  - 1.3.6-1
  - Update to 1.3.6.


Package:  ghostwriter-2.0.2-1.fc35
Old package:  ghostwriter-2.0.1-1.fc35
Summary:  Cross-platform, aesthetic, distraction-free Markdown editor
RPMs: ghostwriter
Size: 6.88 MiB
Size change:  -102 B
Changelog:
  * Sun Jun 27 2021 Vitaly Zaitsev  - 2.0.2-1
  - Updated to version 2.0.2.


Package:  glibc-2.33.9000-29.fc35
Old package:  glibc-2.33.9000-25.fc35
Summary:  The GNU libc libraries
RPMs: compat-libpthread-nonshared glibc glibc-all-langpacks 
glibc-benchtests glibc-common glibc-devel glibc-doc glibc-gconv-extra 
glibc-headers-s390 glibc-headers-x86 glibc-langpack-aa glibc-langpack-af 
glibc-langpack-agr glibc-langpack-ak glibc-langpack-am glibc-langpack-an 
glibc-langpack-anp glibc-langpack-ar glibc-langpack-as glibc-langpack-ast 
glibc-langpack-ayc glibc-langpack-az glibc-langpack-be glibc-langpack-bem 
glibc-langpack-ber glibc-langpack-bg glibc-langpack-bhb glibc-langpack-bho 
glibc-langpack-bi

[Bug 1976496] perl-Data-OptList-0.112 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Data-OptList-0.112-1.f
   ||c35
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-06-28 12:39:20



--- Comment #3 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=70961683


-- 
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: Requesting for package review and sponsor

[Ben Cotton]

On Mon, Jun 28, 2021 at 6:10 AM Sumantro Mukherjee  wrote:
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1976464
>

I'll take the review. Sounds like an app I'd benefit from anyway. :-)



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

[Bug 1976453] F35FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Alien-pkgconf-0.17-8.f
   ||c35
 Resolution|--- |RAWHIDE
Last Closed||2021-06-28 10:38:26




-- 
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: use unit names in systemd output by default?

[Paweł Marciniak]

> What log analysis tools is this change likely to break?
If you set StatusUnitFormat to "name" or "description", then nothing will 
change and it will work as always.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 1976330] ctstream-30 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||ctstream-30-1.fc35




-- 
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 1976330] ctstream-30 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-c6cfb14f08 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-c6cfb14f08


-- 
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 1976330] ctstream-30 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-0a154bf2e0 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-0a154bf2e0


-- 
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 1976330] ctstream-30 is available

[bugzilla]

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



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


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

Requesting for package review and sponsor

[Sumantro Mukherjee]

Hey All,

I am Sumantro and been working in Fedora's QA team for some time now.
I have decided to try out packaging and maintain a few packages as
well. I have taken a few steps of making a PR[0] and submitting one
package for review[1]. It will be awesome if someone can review and
also help me with a sponsor!

I am thankful to Frantisek(with PR), Ankur, and Vipul for helping me out!

[0] 
https://src.fedoraproject.org/rpms/python-click-repl/c/ebba5054e6fd70c9b4fce5c84e51c2b22fd0d377?branch=rawhide
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1976464


-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: use unit names in systemd output by default?

[Nico Kadel-Garcia]

What log analysis tools is this change likely to break? Not breaking
tools that already exist in userland is fairly important to API
changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 Source-git SIG report #1 (June 2021)

[Miroslav Suchý]

Dne 25. 06. 21 v 16:19 Peter Pentchev napsal(a):

FWIW, pristine-tar (http://joeyh.name/code/pristine-tar/) can handle
almost all upstream tarballs, and it also has support for storing
detached signatures alongside its metadata. I keep hearing people say
that there are cases when it fails, but it has worked for me for dozens
of packages. Of course, it does have its own expectations about
the structure of the Git repository, but those are mostly limited to
"give me a branch to play in, I'll take care of the rest".


https://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/

How well it is maintained nowadays? I cannot see recent commit in past few 
years.

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

Fedora-Cloud-34-20210628.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-20210627.0):

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

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

[Bug 1976330] ctstream-30 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


-- 
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 1976330] ctstream-30 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
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 1976778] perl-SNMP-Info-3.72 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-SNMP-Info-3.72-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=70949530


-- 
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 1976778] perl-SNMP-Info-3.72 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1795329
  --> https://bugzilla.redhat.com/attachment.cgi?id=1795329=edit
[patch] Update to 3.72 (#1976778)


-- 
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 1976778] New: perl-SNMP-Info-3.72 is available

[bugzilla]

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

Bug ID: 1976778
   Summary: perl-SNMP-Info-3.72 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-SNMP-Info
  Keywords: FutureFeature, Triaged
  Assignee: w...@gouldfamily.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
w...@gouldfamily.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.72
Current version/release in rawhide: 3.71-3.fc35
URL: http://search.cpan.org/dist/SNMP-Info/

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


-- 
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 1976747] F35FailsToInstall: bugzilla

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Flags|needinfo?(emmanuel@seyman.f |needinfo+
   |r)  |



--- Comment #2 from Emmanuel Seyman  ---
(In reply to Jitka Plesnikova from comment #1)
> 
> Emmanuel, could you please update perl-Email-Sender Provides version to have
> 6 digits after the decimal to preserve upgrade path?

I'ld do this later today.


-- 
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 1976747] F35FailsToInstall: bugzilla

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com
  Flags||needinfo?(emmanuel@seyman.f
   ||r)



--- Comment #1 from Jitka Plesnikova  ---
The module Email::Sender changed the numbering from 1.300036 to 1.500. 

$ rpm -qp -P perl-Email-Sender-1.500-1.fc35.noarch.rpm
perl(Email::Sender) = 1.500
perl(Email::Sender::Failure) = 1.500
perl(Email::Sender::Failure::Multi) = 1.500
perl(Email::Sender::Failure::Permanent) = 1.500
perl(Email::Sender::Failure::Temporary) = 1.500
perl(Email::Sender::Manual) = 1.500
perl(Email::Sender::Manual::QuickStart) = 1.500
perl(Email::Sender::Role::CommonSending) = 1.500
perl(Email::Sender::Role::HasMessage) = 1.500
perl(Email::Sender::Simple) = 1.500
perl(Email::Sender::Success) = 1.500
perl(Email::Sender::Success::Partial) = 1.500
perl(Email::Sender::Transport) = 1.500
perl(Email::Sender::Transport::DevNull) = 1.500
perl(Email::Sender::Transport::Failable) = 1.500
perl(Email::Sender::Transport::Maildir) = 1.500
perl(Email::Sender::Transport::Mbox) = 1.500
perl(Email::Sender::Transport::Print) = 1.500
perl(Email::Sender::Transport::SMTP) = 1.500
perl(Email::Sender::Transport::SMTP::Persistent) = 1.500
perl(Email::Sender::Transport::Sendmail) = 1.500
perl(Email::Sender::Transport::Test) = 1.500
perl(Email::Sender::Transport::Wrapper) = 1.500
perl(Email::Sender::Util) = 1.500
perl-Email-Sender = 1:1.500-1.fc35

The rpm does not determine correctly newer version.
$ rpmdev-vercmp 1.300036 1.500
1.300036 > 1.500

Emmanuel, could you please update perl-Email-Sender Provides version to have 6
digits after the decimal to preserve upgrade path?


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

Fedora-Cloud-33-20210628.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-20210627.0):

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

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

[Bug 1976758] New: Upgrade perl-Net-Telnet to 3.05

[bugzilla]

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

Bug ID: 1976758
   Summary: Upgrade perl-Net-Telnet to 3.05
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-Telnet
  Assignee: robinlee.s...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 3.04 version. Upstream released 3.05. When you have free
time, please upgrade it.


-- 
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 1976501] perl-Throwable-1.000 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Throwable-1.000-1.fc35
 Resolution|--- |RAWHIDE
   Assignee|jples...@redhat.com |emman...@seyman.fr
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-06-28 07:18:04




-- 
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 1976747] New: F35FailsToInstall: bugzilla

[bugzilla]

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

Bug ID: 1976747
   Summary: F35FailsToInstall: bugzilla
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: bugzilla
  Assignee: emman...@seyman.fr
  Reporter: mhron...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: as...@ionic.at, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
Blocks: 1927313 (F35FailsToInstall,RAWHIDEFailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically. If you feel that
this output has mistakes, please contact me via email (mhron...@redhat.com).

Your package (bugzilla) Fails To Install in Fedora 35:

can't install bugzilla:
  - nothing provides perl(Email::Sender) >= 1.300011 needed by
bugzilla-5.0.6-12.fc35.noarch

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.

P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors.

P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1927313
[Bug 1927313] Fedora 35 Fails To install Tracker
-- 
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

[389-devel] 389 DS nightly 2021-06-28 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/06/28/report-389-ds-base-2.0.6-20210628gitc0ca290ff.fc34.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure