[rpms/perl-String-Errf] PR #1: 0.009 bump; Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-String-Errf` that you 
are following.

Merged pull-request:

``
0.009 bump; Package tests
``

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

Re: opensubdiv: strange failure on doc subpackage

[Luya Tshimbalanga]

On 2023-01-02 16:44, Todd Zullinger wrote:

Hi,

Luya Tshimbalanga wrote:

Hello team,

While building opensubdiv, the failure[1] occurred on doc subpackage with
the following line:

BuildError: The following noarch package built differently on different 
architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm
rpmdiff output was:
added   /usr/share/doc/opensubdiv/doxy_html/a00785.js
removed /usr/share/doc/opensubdiv/doxy_html/a00788.js


Any idea about root cause?

[...]

[1]https://koji.fedoraproject.org/koji/taskinfo?taskID=95728588

This happens frequently with doxygen documentation.  It
looks like only a few adjustments are needed to resolve it
though.  I prepared the changes in a fork of the package
repo:

 https://src.fedoraproject.org/fork/tmz/rpms/opensubdiv/c/0cd9137

and ran a scratch build:

 https://koji.fedoraproject.org/koji/taskinfo?taskID=95730383

I'm far from an expert with Doxygen; others may have better
ideas on how to resolve this.

Here's a PR with the changes, for testing and review:

 https://src.fedoraproject.org/rpms/opensubdiv/pull-request/1



Thank you for the patch. I'll merge the fix.

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

Orphaning dlib

[Luya Tshimbalanga]

Hello team,

I am orphaning dlib as I no longer need it for dependencies like howdly 
(Windows Hello type authentication app) and I no longer have a 2018 HP 
Envy 2-in-1 device for testing. The package is well maintained and  up 
to date with upstream. Feel free to take it.


Reference: https://src.fedoraproject.org/rpms/dlib/

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

Re: Orphaned packages looking for new maintainers

[Alexander Ploumistos]

On Mon, Jan 2, 2023 at 7:21 PM Dale Turner via devel
 wrote:
>
> As I mentioned last week, I would be interested in xaos. BUT, I am not 
> presently a packager/maintainer...

Hi Dale,

Unfortunately there's nothing that can be done (except perhaps
delaying the retirement of xaos) until you become a package
maintainer:
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

If it does get a "stay of execution", you will be able to claim it
once you are in the packagers group, but even if that doesn't happen,
you will be able to get it reintroduced into the distribution.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Miroslav Suchý]

Dne 02. 01. 23 v 22:39 Otto Liljalaakso napsal(a):
Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly meant mock should support such usage? 


Mock cannot add such support, because Mock rarely operate on top of dist-git (or even git). So there is no way how to 
retrieve git log.


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

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

[Neal Gompa]

On Mon, Jan 2, 2023 at 10:52 PM Demi Marie Obenour
 wrote:
>
> On 1/2/23 22:30, Kevin Kofler via devel wrote:
> > Fabio Valentini wrote:
> >> - incompatible compile-time options (i.e. resulting in conditional
> >> compilation): different packages depend on crates with different sets
> >> of features enabled, sometimes with conflicting options. Even with a
> >> stable ABI, you'd need to build crates for all necessary combinations
> >> of configurations, and that matrix quickly explodes (i.e. usually
> >> exponentially - 2^n builds for for n independent flags). This is a
> >> deal-breaker for shared libraries in most cases, and also can't be
> >> solved by using a different compiler. (Unless you want to figure out
> >> *which* combinations to build, and *only* build these.)
> >
> > Let me try formulating my criticism more constructively (since my previous
> > reply failed both at being polite and at getting my point through, sorry
> > again for that):
> >
> > I am really surprised to read above that Rust apparently allows applications
> > to pick the flag with which the libraries they depend on are compiled. I
> > really have to wonder why anyone would think that allowing that would be a
> > good idea, but then again I guess I know the answer: Whoever added this
> > feature was so set in a mindset where everything is compiled on demand and
> > statically linked that they figured: why not?
>
> One of the major uses is to allow code that requires a particular
> dependency to be disabled when that dependency is not available.
> In particular, Rust targets platforms (such as OS kernels and embedded
> systems) where the standard library is not available.  This would be
> extremely difficult without Cargo features.
>

platforms != features. That said, some crates do support "nostd" as a
feature flag, others don't. It depends.

> > And if you are in that mindset, that actually sounds like a reasonable call
> > to make. Source-based software distributions do have the advantage of
> > offering this kind of flexibility on demand, see also the USE flags in
> > Gentoo. Those are in fact one of the main reasons some people decide to
> > compile an entire GNU/Linux distribution from source (and hence pick a
> > distribution such as Gentoo) to begin with. Likewise, the Rust way of
> > compiling dependencies on demand allows applications to make this kind of
> > settings for them.
> >
> > Still, I can see several issues with that approach, e.g., what if an
> > application depends on two libraries A and B that both depend on library C,
> > but with conflicting flags?
>
> Last I checked, Cargo features are additive, so the answer is that
> C will be compiled with the union of all flags used by A and B.
>
> > But the main issue is that, as you point out, it
> > makes binary distribution of shared libraries highly impractical. That is
> > why I think this was a short-sighted design decision.
>
> Cargo features are supposed to be additive, so one can sometimes ship
> a single package with the union of all features used by its reverse
> dependencies.  This must be handled on a case-by-case basis, though.

Even if it wasn't, building a library in various feature modes would
be possible. Cargo would just need to know which binary object to
select to link with, which I imagine it would learn how to do if
someone cared about shared libraries in Rust upstream.



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

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

[Demi Marie Obenour]

On 1/2/23 22:30, Kevin Kofler via devel wrote:
> Fabio Valentini wrote:
>> - incompatible compile-time options (i.e. resulting in conditional
>> compilation): different packages depend on crates with different sets
>> of features enabled, sometimes with conflicting options. Even with a
>> stable ABI, you'd need to build crates for all necessary combinations
>> of configurations, and that matrix quickly explodes (i.e. usually
>> exponentially - 2^n builds for for n independent flags). This is a
>> deal-breaker for shared libraries in most cases, and also can't be
>> solved by using a different compiler. (Unless you want to figure out
>> *which* combinations to build, and *only* build these.)
> 
> Let me try formulating my criticism more constructively (since my previous 
> reply failed both at being polite and at getting my point through, sorry 
> again for that):
> 
> I am really surprised to read above that Rust apparently allows applications 
> to pick the flag with which the libraries they depend on are compiled. I 
> really have to wonder why anyone would think that allowing that would be a 
> good idea, but then again I guess I know the answer: Whoever added this 
> feature was so set in a mindset where everything is compiled on demand and 
> statically linked that they figured: why not?

One of the major uses is to allow code that requires a particular
dependency to be disabled when that dependency is not available.
In particular, Rust targets platforms (such as OS kernels and embedded
systems) where the standard library is not available.  This would be
extremely difficult without Cargo features.

> And if you are in that mindset, that actually sounds like a reasonable call 
> to make. Source-based software distributions do have the advantage of 
> offering this kind of flexibility on demand, see also the USE flags in 
> Gentoo. Those are in fact one of the main reasons some people decide to 
> compile an entire GNU/Linux distribution from source (and hence pick a 
> distribution such as Gentoo) to begin with. Likewise, the Rust way of 
> compiling dependencies on demand allows applications to make this kind of 
> settings for them.
> 
> Still, I can see several issues with that approach, e.g., what if an 
> application depends on two libraries A and B that both depend on library C, 
> but with conflicting flags?

Last I checked, Cargo features are additive, so the answer is that
C will be compiled with the union of all flags used by A and B.

> But the main issue is that, as you point out, it 
> makes binary distribution of shared libraries highly impractical. That is 
> why I think this was a short-sighted design decision.

Cargo features are supposed to be additive, so one can sometimes ship
a single package with the union of all features used by its reverse
dependencies.  This must be handled on a case-by-case basis, though.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

Fabio Valentini wrote:
> - incompatible compile-time options (i.e. resulting in conditional
> compilation): different packages depend on crates with different sets
> of features enabled, sometimes with conflicting options. Even with a
> stable ABI, you'd need to build crates for all necessary combinations
> of configurations, and that matrix quickly explodes (i.e. usually
> exponentially - 2^n builds for for n independent flags). This is a
> deal-breaker for shared libraries in most cases, and also can't be
> solved by using a different compiler. (Unless you want to figure out
> *which* combinations to build, and *only* build these.)

Let me try formulating my criticism more constructively (since my previous 
reply failed both at being polite and at getting my point through, sorry 
again for that):

I am really surprised to read above that Rust apparently allows applications 
to pick the flag with which the libraries they depend on are compiled. I 
really have to wonder why anyone would think that allowing that would be a 
good idea, but then again I guess I know the answer: Whoever added this 
feature was so set in a mindset where everything is compiled on demand and 
statically linked that they figured: why not?

And if you are in that mindset, that actually sounds like a reasonable call 
to make. Source-based software distributions do have the advantage of 
offering this kind of flexibility on demand, see also the USE flags in 
Gentoo. Those are in fact one of the main reasons some people decide to 
compile an entire GNU/Linux distribution from source (and hence pick a 
distribution such as Gentoo) to begin with. Likewise, the Rust way of 
compiling dependencies on demand allows applications to make this kind of 
settings for them.

Still, I can see several issues with that approach, e.g., what if an 
application depends on two libraries A and B that both depend on library C, 
but with conflicting flags? But the main issue is that, as you point out, it 
makes binary distribution of shared libraries highly impractical. That is 
why I think this was a short-sighted design decision.

But we will have to work around this one way or another, because I doubt 
anyone will be willing to remove that questionable feature now that 
developers have come to rely on it. (And no, I do not think the current 
Fedora approach of packaging crates in source form only is the optimal 
approach, for reasons I have already pointed out in other threads on this 
list.)

I hope that the above now brings my point across constructively.

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

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

[updates]

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

fastfetch-1.8.2-1.el8
tcpreplay-4.4.3-1.el8
voms-2.1.0-0.27.rc3.el8

Details about builds:



 fastfetch-1.8.2-1.el8 (FEDORA-EPEL-2023-e0c1352c6c)
 Like neofetch, but much faster because written in c

Update Information:

update to 1.8.2

ChangeLog:

* Mon Jan  2 2023 Jonathan Wright  - 1.8.2-1
- Update to 1.8.2 rhbz#2156978




 tcpreplay-4.4.3-1.el8 (FEDORA-EPEL-2023-9b39348cfc)
 Replay captured network traffic

Update Information:

This is Tcpreplay suite 4.4.3. It contains bug fixes only.  What's Changed  -
Feature #759: Upgrade autogen/libopts to 5.18.16 by @fklassen in #760 - Bug #751
don't exit after send error by @fklassen in #761 - Bug #750: configure: libpcap
version robustness by @fklassen in #764 - Bug #749 flow stats: avoid overstating
flow packet count by @fklassen in #765 - Bug #750 more libpcap version updates
by @fklassen in #766 - Bug #767 tests: support for out-of-tree tests by
@fklassen in #768 - Bug #750 - fix macOS test failure by @fklassen in #770 -
4.4.3 by @fklassen in #769 and #771

ChangeLog:

* Mon Jan  2 2023 Bojan Smojver  - 4.4.3-1
- bump up to 4.4.3
- remove merged patch from https://github.com/appneta/tcpreplay/pull/757
* Thu Nov 24 2022 Florian Weimer  - 4.4.2-2
- Avoid implicit int, implicit function declarations in configure




 voms-2.1.0-0.27.rc3.el8 (FEDORA-EPEL-2023-512d2dc2c9)
 Virtual Organization Membership Service

Update Information:

VOMS 2.1.0 rc3

ChangeLog:

* Mon Jan  2 2023 Mattias Ellert  - 2.1.0-0.27.rc3
- Update to version 2.1.0-rc3
- Drop patches accepted upstream
- Add new patches (the PRs have been accepted upstream)
* Wed Dec 21 2022 Mattias Ellert  - 2.1.0-0.26.rc2
- Rebuild for gsoap 2.8.124 (Fedora 38)
* Sat Jul 23 2022 Fedora Release Engineering  - 
2.1.0-0.25.rc2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild


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

[Bug 2156199] perl-ExtUtils-MakeMaker-7.66 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

Re: Orphaned packages looking for new maintainers

[Maxwell G via devel]

On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote:
> I went ahead and took vim-nerdtree.


FYI: Nerdtree is unmaintained upstream:
https://github.com/preservim/nerdtree/issues/1280

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

Re: opensubdiv: strange failure on doc subpackage

[Todd Zullinger]

Hi,

Luya Tshimbalanga wrote:
> Hello team,
> 
> While building opensubdiv, the failure[1] occurred on doc subpackage with
> the following line:
> 
> BuildError: The following noarch package built differently on different 
> architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm
> rpmdiff output was:
> added   /usr/share/doc/opensubdiv/doxy_html/a00785.js
> removed /usr/share/doc/opensubdiv/doxy_html/a00788.js
> 
> 
> Any idea about root cause?
[...]
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=95728588

This happens frequently with doxygen documentation.  It
looks like only a few adjustments are needed to resolve it
though.  I prepared the changes in a fork of the package
repo:

https://src.fedoraproject.org/fork/tmz/rpms/opensubdiv/c/0cd9137

and ran a scratch build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=95730383

I'm far from an expert with Doxygen; others may have better
ideas on how to resolve this.

Here's a PR with the changes, for testing and review:

https://src.fedoraproject.org/rpms/opensubdiv/pull-request/1

-- 
Todd


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

Re: Orphaned packages looking for new maintainers

[Philip Wyett]

On Mon, 2023-01-02 at 17:02 +0100, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/;
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2023-01-02.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 
>  Package  (co)maintainers   Status 
> Change
> 
> 5minute   orphan   4 weeks ago
> CFR   jvanek, orphan   4 weeks ago
> CheMPS2   orphan   4 weeks ago
> PolicyKit-olpcorphan   5 weeks ago
> aboot orphan   4 weeks ago
> albatross orphan   5 weeks ago
> alleyoop  orphan   5 weeks ago
> alure orphan   4 weeks ago
> amor  jgrulich, kde-sig, orphan,   5 weeks ago
>rdieter, than
> anki  chkr, orphan 4 weeks ago
> ansible-collection-google-cloud   infra-sig, orphan3 weeks ago
> asn1c orphan   4 weeks ago
> backup-managerorphan   5 weeks ago
> bharati-m17n  orphan   4 weeks ago
> bibtex2html   orphan, thofmann 4 weeks ago
> bluecurve-classic-metacity-   gnome-sig, orphan, rstrode   4 weeks ago
> theme
> bluecurve-gnome-theme gnome-sig, orphan, rstrode   4 weeks ago
> bluecurve-gtk-themes  gnome-sig, orphan, rstrode   4 weeks ago
> bluecurve-icon-theme  gnome-sig, orphan, rstrode   4 weeks ago
> bluecurve-kde-theme   gnome-sig, kkofler, orphan,  4 weeks ago
>rdieter, rstrode, than
> bluecurve-metacity-theme  gnome-sig, orphan, rstrode   4 weeks ago
> bluecurve-xmms-skin   gnome-sig, orphan, rstrode   4 weeks ago
> cairo-clock   orphan   4 weeks ago
> code-editor   orphan   5 weeks ago
> compton   orphan   5 weeks ago
> cups-bjnp orphan   5 weeks ago
> devilspie2orphan   2 weeks ago
> dmz-cursor-themes company, orphan  5 weeks ago
> ejabberd  bowlofeggs, jcline, orphan,  4 weeks ago
>xavierb
> erlang-epgsql lkundrak, orphan 5 weeks ago
> fwsnort   orphan   5 weeks ago
> gdeploy   godas, orphan4 weeks ago
> ghasher   orphan   4 weeks ago
> gl-117orphan, steve4 weeks ago
> glusterfs-selinux kkeithle, orphan, shwetha4 weeks ago
> gnome-activity-journalorphan   5 weeks ago
> gnome-nds-thumbnailer orphan   5 weeks ago
> gnome-search-tool gnome-sig, orphan4 weeks ago
> gnome-shell-theme-selene  orphan   5 weeks ago
> gnonlin   orphan   4 weeks ago
> golang-github-gocomply-scap   go-sig, orphan   5 weeks ago
> golang-github-justinas-alice  go-sig, orphan   4 weeks ago
> golang-github-lpabon-godbcgo-sig, orphan   5 weeks ago
> golang-github-pkg-browser go-sig, 

[Bug 2144904] perl-App-cpm for EPEL 9

[bugzilla]

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

Bug 2148461 Summary: Add perl-CPAN-02Packages-Search to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2148461

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

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

[updates]

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

novnc-1.3.0-5.el7
tcpreplay-4.4.3-1.el7
voms-2.1.0-0.27.rc3.el7

Details about builds:



 novnc-1.3.0-5.el7 (FEDORA-EPEL-2023-e9a9c081af)
 VNC client using HTML5 (Web Sockets, Canvas) with encryption support

Update Information:

Security fix for [CVE-2017-18635] Update to 1.3.0

ChangeLog:

* Wed Dec  7 2022 Jonathan Wright  - 1.3.0-5
- Add require on 'which' rhbz#2150521
* Fri Jul 22 2022 Fedora Release Engineering  - 
1.3.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Thu Jan 20 2022 Fedora Release Engineering  - 
1.3.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Nov 19 2021 Lee Yarwood  - 1.3.0-2
- Add novnc_proxy and associated man pages
- Drop various utilities, tests and other files not required from the package
- Add docs/API.md docs/EMBEDDING.md docs/LIBRARY.md as docs
* Thu Nov  4 2021 Lee Yarwood  - 1.3.0-1
- New upstream release 1.3.0
* Thu Jul 22 2021 Fedora Release Engineering  - 
1.2.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Tue Jan 26 2021 Fedora Release Engineering  - 
1.2.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Tue Aug 25 2020 Lee Yarwood  - 1.2.0-2
- Drop py2 support
* Tue Aug 25 2020 Lee Yarwood  - 1.2.0-1
- New upstream release 1.2.0
* Tue Jul 28 2020 Fedora Release Engineering  - 
1.1.0-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed Jan 29 2020 Fedora Release Engineering  - 
1.1.0-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Aug  9 2019 Lee Yarwood  1.1.0-6
- Drop use of pathfix for py2 builds.
* Fri Aug  9 2019 Lee Yarwood  1.1.0-5
- Make the spec compatible for both py2 and py3.
* Fri Aug  9 2019 Lee Yarwood  1.1.0-4
- Fix bogus changelog date.
* Thu Aug  8 2019 Lee Yarwood  1.1.0-3
- launch.sh: Check for a local websockify directory
* Thu Jul 25 2019 Fedora Release Engineering  - 
1.1.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri Jul  5 2019 Lee Yarwood  - 1.1.0-1
- Update to 1.1.0
* Fri Feb  1 2019 Fedora Release Engineering  - 
1.0.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Thu Aug  2 2018 Lee Yarwood  - 1.0.0-1
- Update to 1.0.0
* Fri Jul 13 2018 Fedora Release Engineering  - 
0.6.1-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Mon Mar 19 2018 Iryna Shcherbina  - 0.6.1-5
- Update Python 2 dependency declarations to new packaging standards
  (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)
* Thu Feb  8 2018 Fedora Release Engineering  - 
0.6.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Jul 27 2017 Fedora Release Engineering  - 
0.6.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Sat Feb 11 2017 Fedora Release Engineering  - 
0.6.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Thu Jul 28 2016 Lon Hohberger  0.6.1-1
- Rebase to upstream 0.6.1
* Thu Feb  4 2016 Fedora Release Engineering  - 
0.5.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
* Wed Jun 17 2015 Fedora Release Engineering  
- 0.5.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

References:

  [ 1 ] Bug #1765660 - CVE-2017-18635 novnc: XSS vulnerability via the messages 
propagated to the status field
https://bugzilla.redhat.com/show_bug.cgi?id=1765660




 tcpreplay-4.4.3-1.el7 (FEDORA-EPEL-2023-8e34bc081a)
 Replay captured network traffic

Update Information:

This is Tcpreplay suite 4.4.3. It contains bug fixes only.  What's Changed  -
Feature #759: Upgrade autogen/libopts to 5.18.16 by @fklassen in #760 - Bug #751
don't exit after send error by @fklassen in #761 - Bug #750: configure: libpcap
version robustness by @fklassen in #764 - Bug #749 flow stats: avoid overstating
flow packet count by @fklassen in #765 - Bug #750 more libpcap version updates
by @fklassen in #766 - Bug #767 tests: support for out-of-tree tests by
@fklassen in #768 - Bug #750 - fix macOS test failure by @fklassen in #770 -
4.4.3 by @fklassen in #769 and #771

ChangeLog:

* Mon Jan  2 2023 Bojan Smojver  - 4.4.3-1
- bump up to 4.4.3
- remove merged patch from https://github.com/appneta/tcpreplay/pull/757

Re: HEADS UP: icu 72 coming to rawhide

[Frantisek Zatloukal]

On Sat, Dec 31, 2022 at 2:30 PM Pete Walter  wrote:

> This is now done. The following 4 packages failed to rebuild. The rest of
> 102 packages built fine and are all rebuilt in rawhide.
>
> mozjs78: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691022
> mozjs91: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691025
> mozjs102: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691005
>

All mozjs* packages fixed and rebuilt!

-- 

Best regards / S pozdravem,

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

opensubdiv: strange failure on doc subpackage

[Luya Tshimbalanga]

Hello team,

While building opensubdiv, the failure[1] occurred on doc subpackage 
with the following line:


BuildError: The following noarch package built differently on different 
architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm
rpmdiff output was:
added   /usr/share/doc/opensubdiv/doxy_html/a00785.js
removed /usr/share/doc/opensubdiv/doxy_html/a00788.js


Any idea about root cause? For the time being, that subpackage is 
temporarily disabled.


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=95728588

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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

On Mon, Jan 2, 2023 at 4:40 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Jan 02, 2023 at 05:59:07PM +0100, mkol...@redhat.com wrote:
> > On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote:
> > > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> > > > Hi all,
> > > >
> > > > > == Benefit to Fedora ==
> > > > > * Better secure boot support (specifically the initrd is covered
> > > > > by
> > > > > the signature).
> > > > > * Better confidential computing support (measurements are much
> > > > > more
> > > > > useful if we know what hashes to expect for the initrd).
> > > > > * More robust boot process (generating the initrd on the
> > > > > installed
> > > > > system is fragile, root cause for kernel bugs reported is simply
> > > > > a
> > > > > broken initrd sometimes).
> > > > Just want to add Anaconda installation environment is also fighting
> > > > with the
> > > > second point.
> > >
> > > Third point I assume, i.e. initrd generation problems being reported
> > > as
> > > anaconda bugs?
> > >
> > > While being at it: anaconda seems to explicitly call dracut to
> > > generate
> > > the initrd (according to the messages it prints).  What is the reason
> > > for this?  Shouldn't this already happen as part of the rpm
> > > transaction,
> > > when the kernel install scripts are running?
> > IIRC the main reason is the esentially random package installation
> > order during the RPM transaction.
>
> kernel-core scriptlets call 'kernel-install add' (which in turns calls dracut 
> at
> some point) from %posttrans. So package installation order is not relevant, 
> that
> all happens after all packages are in place. Maybe anaconda doesn't need to 
> call
> dracut a second time.
>

It does need to call it for non-package transaction based
installations (live OS, ostree, etc.).



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

Re: UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

[Dominik 'Rathann' Mierzejewski]

On Monday, 02 January 2023 at 17:25, Gerd Hoffmann wrote:
> On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
> > [...]
> > > Note that uefi http boot can also work with iso images, i.e. you can
> > > have the dhcp server hand out URLs to the fedora netboot iso.  The
> > > firmware will fetch the iso, create a ramdisk, add a acpi table for
> > > it so the OS finds it too, then go boot as it would be a physical
> > > cdrom all the way up to anaconda.
> > 
> > That sounds very interesting. Could you describe how to set this up
> > and/or provide some links to documentation?
> 
> On uefi http boot:
> 
> https://www.redhat.com/sysadmin/uefi-http-boot-libvirt
> 
> To boot iso images you essentially have to just replace
> http://server/path/binary.efi with
> http://server/path/netboot.iso

Thanks a lot! I'll dig into this when I get a chance.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Michel Alexandre Salim]

On Mon, Jan 02, 2023 at 05:02:41PM +0100, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> salimma: libstroke

I don't even remember why I was maintaining libstroke - if there's
anyone who still needs it, please pick it up. Looks like it's a build
dependency for fvwm (cc:ing the maintainers).

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

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

[Otto Liljalaakso]

Zbigniew Jędrzejewski-Szmek kirjoitti 2.1.2023 klo 22.44:

On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:

* Vitaly Zaitsev via devel:


On 30/12/2022 20:01, Ben Cotton wrote:

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


-1 until these known issues[1] are fixed, especially with changelogs
  and using rpmautospec in COPR or mock.

[1]:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints


The page doesnt discuss COPR/mock?

COPR seems to work in some cases, specifically with the dist-git build
(but not just building from dist-git).

A quick check suggests that rpmautospec does the right thing and
produces a portable source RPM that doesn't depend on rpmautospec
anymore.  As a result, the compatibility impact won't be too severe, I
hope.


Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.


All these examples work because 'fedpkg srpm' does the rpmautospec 
conversion, and all the used fedpkg commands imply 'fedpkg srpm'.


If you generate an srpm which still contains %autorelease and 
%autochangelog with 'rpmbuild -bs', mock will not convert them by 
itself. Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly 
meant mock should support such usage?


But I wonder, if that is really necessary? In many cases like local test 
builds, the default values for uncoverted %autorelease and 
%autochangelog are just fine, and if the real values are needed, 'fedpkg 
srpm' can be called before invoking mock.

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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 02, 2023 at 05:59:07PM +0100, mkol...@redhat.com wrote:
> On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote:
> > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> > > Hi all,
> > > 
> > > > == Benefit to Fedora ==
> > > > * Better secure boot support (specifically the initrd is covered
> > > > by
> > > > the signature).
> > > > * Better confidential computing support (measurements are much
> > > > more
> > > > useful if we know what hashes to expect for the initrd).
> > > > * More robust boot process (generating the initrd on the
> > > > installed
> > > > system is fragile, root cause for kernel bugs reported is simply
> > > > a
> > > > broken initrd sometimes).
> > > Just want to add Anaconda installation environment is also fighting
> > > with the
> > > second point.
> > 
> > Third point I assume, i.e. initrd generation problems being reported
> > as
> > anaconda bugs?
> > 
> > While being at it: anaconda seems to explicitly call dracut to
> > generate
> > the initrd (according to the messages it prints).  What is the reason
> > for this?  Shouldn't this already happen as part of the rpm
> > transaction,
> > when the kernel install scripts are running?
> IIRC the main reason is the esentially random package installation
> order during the RPM transaction.

kernel-core scriptlets call 'kernel-install add' (which in turns calls dracut at
some point) from %posttrans. So package installation order is not relevant, that
all happens after all packages are in place. Maybe anaconda doesn't need to call
dracut a second 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2157775] Please branch and build cpanspec in epel9

[bugzilla]

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



--- Comment #1 from vladimir.pach...@gooddata.com ---
Hello team,

please, branch and build cpanspec in epel9.

Thank you
Vladimir


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

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

[Miroslav Suchý]

Dne 02. 01. 23 v 22:01 Richard Shaw napsal(a):


Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.


This is my problem with the proposal. Our tools haven't been fully integrated. For a typical update I do not need to 
run git directly, but for this workflow I do.


For a typical bump all I need is:

rpmdev-bumpspec -c "Change here"
fedpkg commit -c -p
fedpkg build

Our tools need to handle this automagically. I shouldn't have to know I need to add 
"--allow-empty". It should just work.


https://pagure.io/rpkg/pull-request/644

You are welcome.

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

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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 02, 2023 at 03:01:16PM -0600, Richard Shaw wrote:
> On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> > > * Vitaly Zaitsev via devel:
> > >
> > > > On 30/12/2022 20:01, Ben Cotton wrote:
> > > >> This document represents a proposed Change. As part of the Changes
> > > >> process, proposals are publicly announced in order to receive
> > > >> community feedback. This proposal will only be implemented if approved
> > > >> by the Fedora Engineering Steering Committee.
> > > >
> > > > -1 until these known issues[1] are fixed, especially with changelogs
> > > >  and using rpmautospec in COPR or mock.
> > > >
> > > > [1]:
> > > >
> > https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints
> > >
> > > The page doesnt discuss COPR/mock?
> > >
> > > COPR seems to work in some cases, specifically with the dist-git build
> > > (but not just building from dist-git).
> > >
> > > A quick check suggests that rpmautospec does the right thing and
> > > produces a portable source RPM that doesn't depend on rpmautospec
> > > anymore.  As a result, the compatibility impact won't be too severe, I
> > > hope.
> >
> > Also mock builds seem fine. I tested this now on F37 with a few different
> > scenarios:
> > - fedpkg mockbuild
> > - git commit --allow-empty -m Rebuild && fedpkg mockbuild
> > - fedpkg srpm && mock *.src.rpm
> > seem to generate the expected versions numbers and changelogs.
> >
> 
> This is my problem with the proposal. Our tools haven't been fully
> integrated. For a typical update I do not need to run git directly, but for
> this workflow I do.
> 
> For a typical bump all I need is:
> 
> rpmdev-bumpspec -c "Change here"
> fedpkg commit -c -p
> fedpkg build
> 
> Our tools need to handle this automagically. I shouldn't have to know I
> need to add "--allow-empty". It should just work.

Yes, it'd be nice if 'fedpkg' handled this natively more nicely.
There is nothing to do for rpmdev-bumpspec in this case. The first two
steps should/could be replaced by one command:

  fedpkg commit -m 'Change here' -p

I filed https://pagure.io/fedpkg/issue/494 asking for this.
I'll add this to the Scope section of the proposal so we don't lose
track.

Zbyszek

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

[Bug 2157775] New: Please branch and build cpanspec in epel9

[bugzilla]

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

Bug ID: 2157775
   Summary: Please branch and build cpanspec in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: cpanspec
  Assignee: psab...@redhat.com
  Reporter: vladimir.pach...@gooddata.com
QA Contact: extras...@fedoraproject.org
CC: ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
psab...@redhat.com, st...@silug.org
  Target Milestone: ---
Classification: Fedora




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

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

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 01, 2023 at 12:06:51PM -0500, Neal Gompa wrote:
> On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
> > > On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok  wrote:
> > > >
> > > > On 31. 12. 22 15:07, Josh Boyer wrote:
> > > > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
> > > > >>
> > > > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> > > > >>  wrote:
> > > > >>>
> > > > >>> On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> > > >  On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  
> > > >  wrote:
> > > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > > >  Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > >  that they don't truncate or eliminate the Git history anymore? 
> > > >  Because I would
> > > >  personally be very displeased if my historical attribution went 
> > > >  away
> > > >  because of broken processes like the one used to fork all the 
> > > >  Fedora
> > > >  Linux 34 packages for CentOS Stream 9.
> > > > >>>
> > > > >>> I can't speak for the RH folks who do the forking… It'd be great if
> > > > >>> somebody who knows how that's done could answer.
> > > > >>>
> > > > >>> Fedora is already using rpmautospec widely enough that (if it was to
> > > > >>> be problem at all), it must already be a problem.
> > > > >>>
> > > > >>> At the level of specific solutions, obviously the obvious answer is 
> > > > >>> to
> > > > >>> keep the git history. It's in general a great of source of 
> > > > >>> information
> > > > >>> and discarding that is just an error. But if somebody were really 
> > > > >>> to do that,
> > > > >>> it's fairly trivial to undo the conversion and get a static 
> > > > >>> changelog
> > > > >>> again by inserting the output of 'rpmautospec changelog' in the 
> > > > >>> %changelog
> > > > >>> section.
> > > > >>>
> > > > >>
> > > > >> As they are the most prominent downstream we have, I would like this
> > > > >> resolved before changing Fedora's defaults.
> > > > >>
> > > > >> At the time we branched from Fedora Linux 34, there were very few
> > > > >> packages using rpmautospec and I don't think any that were kept used
> > > > >> rpmautospec. Now it is very obvious it would be a problem, so I would
> > > > >> like that fixed first. CentOS and RHEL infrastructure needs to 
> > > > >> account
> > > > >> for it properly and not gut the Git history.
> > > > >
> > > > > We can look into it, but at the moment this is unlikely to change on
> > > > > the CentOS Stream/RHEL side.
> > > >
> > > > Are the packages imported on SRPM level with the changelogs rendered?
> > > >
> > >
> > > They are not. It's done using distrobaker[1], which syncs Git content
> > > and lookaside data.
> > >
> > > Example commit:
> > > https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecacbf1c94c4d6f8000ef113c1e7c92
> > >
> > > [1]: https://github.com/fedora-eln/distrobaker
> >
> > I don't think that changes in Fedora should be held hostage by some 
> > downstream
> > utils. We know that the problem is solvable and in fact not hard at all. We
> > certainly can notify RHEL maintainers about this, which I did right now [1],
> > but actual implementation is something that we have no control of from the
> > Fedora side.
> >
> > [1] https://github.com/fedora-eln/distrobaker/issues/12
> >
> 
> I think it's absolutely reasonable to consider the effects of people
> forking the packages in a way where attribution is lost. Losing
> attribution and correct package history is just not acceptable to me.
> 
> In many respects, this is *extremely* personal to me, because all I
> *have* is that attribution. I don't make any money on my work in
> Fedora. Nobody pays me to do it. The absolute *least* anyone can do is
> respect my copyright and preserve the attribution and history.
> 
> I am insulted that you think that's an issue that can be hand-waved
> away. This is a hill I will die on.
>
> Fix it. And that means fundamentally changing how distrobaker works.
> Either preserve the whole Git history or always eliminate rpmautospec
> and expand the changelog when importing into RHEL. The current
> situation is simply not acceptable.

I fully support what you are saying. I do a lot of work in Fedora on my
free time too, and I would very much like for it to be attributed properly.
I also agree with the solutions you propose: I wrote the very same suggestions
in the issue I linked above. (I also think that the problem already exists,
*right now*, because rpmautospec is being used fairly widely, and if 
attributions
are stripped, this is not nice to those maintainers and also deprives downstream
users of useful information.)
I just don't think that we should ask Fedora contributors to make plans or
promises for a downstream distro. You are sending your complaints not to the
people who can fix 

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

[Matthew Miller]

On Mon, Jan 02, 2023 at 01:06:52PM +0100, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > Okay. no. This is not how we do things here.
> Apologies for my snide remark that visibly came out rude, sorry.

Thank you, Kevin.


-- 
Matthew Miller

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

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

[Richard Shaw]

On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> > * Vitaly Zaitsev via devel:
> >
> > > On 30/12/2022 20:01, Ben Cotton wrote:
> > >> This document represents a proposed Change. As part of the Changes
> > >> process, proposals are publicly announced in order to receive
> > >> community feedback. This proposal will only be implemented if approved
> > >> by the Fedora Engineering Steering Committee.
> > >
> > > -1 until these known issues[1] are fixed, especially with changelogs
> > >  and using rpmautospec in COPR or mock.
> > >
> > > [1]:
> > >
> https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints
> >
> > The page doesnt discuss COPR/mock?
> >
> > COPR seems to work in some cases, specifically with the dist-git build
> > (but not just building from dist-git).
> >
> > A quick check suggests that rpmautospec does the right thing and
> > produces a portable source RPM that doesn't depend on rpmautospec
> > anymore.  As a result, the compatibility impact won't be too severe, I
> > hope.
>
> Also mock builds seem fine. I tested this now on F37 with a few different
> scenarios:
> - fedpkg mockbuild
> - git commit --allow-empty -m Rebuild && fedpkg mockbuild
> - fedpkg srpm && mock *.src.rpm
> seem to generate the expected versions numbers and changelogs.
>

This is my problem with the proposal. Our tools haven't been fully
integrated. For a typical update I do not need to run git directly, but for
this workflow I do.

For a typical bump all I need is:

rpmdev-bumpspec -c "Change here"
fedpkg commit -c -p
fedpkg build

Our tools need to handle this automagically. I shouldn't have to know I
need to add "--allow-empty". It should just work.

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

Re: Rpmautospec howto do a rebuild for something

[Luya Tshimbalanga]

On 2023-01-02 04:52, Maxwell G via devel wrote:

On Mon Jan 2, 2023 at 12:32 +, Sérgio Basto wrote:

I need rebuild a package that is using rpmautospec , how I can rebuild
the package and increase relversion ?

`git commit --allow-empty -m "Changelog entry here"` will do what you
want. The empty commit will result in a release and changelog bump.

Will it be possible to document this instruction on the guideline for 
future packagers? Thanks.


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

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

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> * Vitaly Zaitsev via devel:
> 
> > On 30/12/2022 20:01, Ben Cotton wrote:
> >> This document represents a proposed Change. As part of the Changes
> >> process, proposals are publicly announced in order to receive
> >> community feedback. This proposal will only be implemented if approved
> >> by the Fedora Engineering Steering Committee.
> >
> > -1 until these known issues[1] are fixed, especially with changelogs
> >  and using rpmautospec in COPR or mock.
> >
> > [1]:
> > https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints
> 
> The page doesnt discuss COPR/mock?
> 
> COPR seems to work in some cases, specifically with the dist-git build
> (but not just building from dist-git).
> 
> A quick check suggests that rpmautospec does the right thing and
> produces a portable source RPM that doesn't depend on rpmautospec
> anymore.  As a result, the compatibility impact won't be too severe, I
> hope.

Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.

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

[Bug 2157192] perl-Config-MVP-2.200013 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Config-MVP-2.200013-1.
   ||fc38
Last Closed||2023-01-02 19:42:51



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105530


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

[Bug 2157197] perl-Role-HasMessage-0.007 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |CLOSED
   Fixed In Version||perl-Role-HasMessage-0.007-
   ||1.fc38
 Resolution|--- |RAWHIDE
Last Closed||2023-01-02 19:42:11



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105534


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

[Bug 2157215] perl-App-Cmd-0.335 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Fixed In Version||perl-App-Cmd-0.335-1.fc38
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
 Resolution|--- |RAWHIDE
Last Closed||2023-01-02 19:41:34



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105539


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

[Bug 2157224] perl-Role-Identifiable-0.009 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Role-Identifiable-0.00
   ||9-1.fc38
Last Closed||2023-01-02 19:40:48



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105540


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

[Bug 2157232] perl-Config-INI-0.028 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Fixed In Version||perl-Config-INI-0.028-1.fc3
   ||8
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
 Status|NEW |CLOSED
Last Closed||2023-01-02 19:40:12



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105541


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

[Bug 2157234] perl-Config-MVP-Reader-INI-2.101465 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Config-MVP-Reader-INI-
   ||2.101465-1.fc38
 Resolution|--- |RAWHIDE
Last Closed||2023-01-02 19:39:43



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105543


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

[Bug 2157238] perl-MooseX-OneArgNew-0.007 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Fixed In Version||perl-MooseX-OneArgNew-0.007
   ||-1.fc38
Last Closed||2023-01-02 19:38:33



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105544


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

[Bug 2157239] perl-MooseX-Types-Perl-0.101344 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-MooseX-Types-Perl-0.10
   ||1344-1.fc38
 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
Last Closed||2023-01-02 19:37:53



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105548


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

[Bug 2157242] perl-Test-Routine-0.029 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Fixed In Version||perl-Test-Routine-0.029-1.f
   ||c38
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
 Resolution|--- |RAWHIDE
Last Closed||2023-01-02 19:37:14



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105549


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

Copr - look back at 2022

[Miroslav Suchý]

Let me sum up what the Copr team did during 2022. The review of 2021 can be found at 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R2MWYN7CRF34WKSRUUYNLAISQB47MHXI/ 



Mock:

 *

   We did six releases of Mock 
Starting with a 
major
   upgrade to 3.x that dropped python2 support and EL7 as the host platform.

 *

   We added `--list-chroots` option. Allow better customization of used tar 
binary and adapt to the new split of
   qemu-user-static package.

 *

   We also added lots of new chroots: AlmaLinux, RockyLinux, EuroLinux, 
OpenEuler, and a few others…


Copr:

 *

   We did nine releases of Copr 
and upgraded Copr servers 
to
   Fedora 37.

 *

   We wrote two “4 cool new projects to try in Copr”
   
articles
 for Fedora Magazine

 *

   Beside previously built of all gems from Rubygems.org we built all modules 
from PyPI as RPM packages Thousands of
   PyPI and RubyGems RPMs now available for RHEL 9 | Red Hat Developer
   
Big
 thanks
   to Karolina Surma from Python team on cooperation on this. As a side effect, 
we introduced pyp2spec as a second
   option to build directly from PyPI.

 *

   We presented at Fedora Nest.

 *

   We dropped APIv2. And provided guidance how to migrate your scripts
   https://fedora-copr.github.io/posts/api3-migration-helper 


 *

   We added Kerberos authentication to command line tools and API
   https://fedora-copr.github.io/posts/how-to-use-kerberos-in-copr
   

 *

   We cooperated with Packit on building SRPM in Copr 
https://packit.dev/postcs/copr-srpms/
   

 *

   We started using IBM Cloud for native s390x builders
   
https://pavel.raiskup.cz/blog/fedora-copr-uses-ibm-cloud.htmlAs
   a side effect we packaged python modules for managing resources in IBM Cloud.

 *

   We spent lots of time optimizing the scheduler in Copr. E.g.

 o

   Builds from webhooks are now background jobs
   
https://docs.pagure.org/copr.copr/release-notes/2022-02-03.html#webhook-rebuilds-are-background-jobs-now
   


 o

   We improved the throughput when the queue is bigger than 70k jobs
   
https://docs.pagure.org/copr.copr/release-notes/2022-03-21.html#large-queue-improvements
   


 o

   And we were able to increase quota of parallel builds for one user from 
35 to 45.

 *

   We started using SHA256 for signing packages
   
https://docs.pagure.org/copr.copr/release-notes/2022-03-21.html#signing-packages-with-sha256
   


 *

   We started using OpenPGP v4 signatures and we were one of the first to 
discover issues with new Sequoia backend of
   RPM with older version of signatures.

 *

   We created a webUI statistics page that shows the utilization of resalloc
   resources
   
https://docs.pagure.org/copr.copr/release-notes/2022-06-22.html#resalloc-webui

 *

   We (finally) were able to count download statistics from CDN
   
https://docs.pagure.org/copr.copr/release-notes/2022-08-18.html#rpm-download-statistics
   


 *

   You can submit more builds at once from command line
   
https://docs.pagure.org/copr.copr/release-notes/2022-07-27.html#submitting-multiple-builds-at-once-via-copr-cli
   


 *

   We upgraded aarch64 builders to stronger Graviton3 machines
   
https://docs.pagure.org/copr.copr/release-notes/2022-11-28.html#updated-aarch64-builders-to-graviton3-processors
   


 *

   We migrated our git project to GitHub
   
https://docs.pagure.org/copr.copr/release-notes/2022-11-28.html#development-moved-to-github
   


 *

   We migrated to new storage as we hit 16 TB hard limit for 

[Bug 2157193] perl-Data-Section-0.200008 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Data-Section-0.28-
   ||1.fc38
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
Last Closed||2023-01-02 18:43:20



--- Comment #1 from Paul Howarth  ---
Built for Rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2105532


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

Re: Orphaned packages looking for new maintainers

[Dale Turner via devel]

Hello.

As I mentioned last week, I would be interested in xaos. BUT, I am not 
presently a packager/maintainer...

Dale




Sent with Proton Mail secure email.

--- Original Message ---
On Monday, January 2nd, 2023 at 12:02 PM, Miro Hrončok  
wrote:


> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
> 
> Request package ownership via the Take button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2023-01-02.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 
> Package (co)maintainers Status Change
> 
> 5minute orphan 4 weeks ago
> CFR jvanek, orphan 4 weeks ago
> CheMPS2 orphan 4 weeks ago
> PolicyKit-olpc orphan 5 weeks ago
> aboot orphan 4 weeks ago
> albatross orphan 5 weeks ago
> alleyoop orphan 5 weeks ago
> alure orphan 4 weeks ago
> amor jgrulich, kde-sig, orphan, 5 weeks ago
> rdieter, than
> anki chkr, orphan 4 weeks ago
> ansible-collection-google-cloud infra-sig, orphan 3 weeks ago
> asn1c orphan 4 weeks ago
> backup-manager orphan 5 weeks ago
> bharati-m17n orphan 4 weeks ago
> bibtex2html orphan, thofmann 4 weeks ago
> bluecurve-classic-metacity- gnome-sig, orphan, rstrode 4 weeks ago
> theme
> bluecurve-gnome-theme gnome-sig, orphan, rstrode 4 weeks ago
> bluecurve-gtk-themes gnome-sig, orphan, rstrode 4 weeks ago
> bluecurve-icon-theme gnome-sig, orphan, rstrode 4 weeks ago
> bluecurve-kde-theme gnome-sig, kkofler, orphan, 4 weeks ago
> rdieter, rstrode, than
> bluecurve-metacity-theme gnome-sig, orphan, rstrode 4 weeks ago
> bluecurve-xmms-skin gnome-sig, orphan, rstrode 4 weeks ago
> cairo-clock orphan 4 weeks ago
> code-editor orphan 5 weeks ago
> compton orphan 5 weeks ago
> cups-bjnp orphan 5 weeks ago
> devilspie2 orphan 2 weeks ago
> dmz-cursor-themes company, orphan 5 weeks ago
> ejabberd bowlofeggs, jcline, orphan, 4 weeks ago
> xavierb
> erlang-epgsql lkundrak, orphan 5 weeks ago
> fwsnort orphan 5 weeks ago
> gdeploy godas, orphan 4 weeks ago
> ghasher orphan 4 weeks ago
> gl-117 orphan, steve 4 weeks ago
> glusterfs-selinux kkeithle, orphan, shwetha 4 weeks ago
> gnome-activity-journal orphan 5 weeks ago
> gnome-nds-thumbnailer orphan 5 weeks ago
> gnome-search-tool gnome-sig, orphan 4 weeks ago
> gnome-shell-theme-selene orphan 5 weeks ago
> gnonlin orphan 4 weeks ago
> golang-github-gocomply-scap go-sig, orphan 5 weeks ago
> golang-github-justinas-alice go-sig, orphan 4 weeks ago
> golang-github-lpabon-godbc go-sig, orphan 5 weeks ago
> golang-github-pkg-browser go-sig, orphan 4 weeks ago
> golang-github-spaolacci-murmur3 go-sig, orphan 4 weeks ago
> golang-github-sqshq-sampler atim, go-sig, orphan 3 weeks ago
> golie go-sig, orphan 5 weeks ago
> grads orphan 5 weeks ago
> gsm-ussd orphan 5 weeks ago
> heisenbug-kde-theme jreznik, orphan 5 weeks ago
> highcontrast-qt jgrulich, orphan 5 weeks ago
> holland orphan, survient 5 weeks ago
> jama orphan 4 weeks ago
> jargs ellert, orphan 4 weeks ago
> java-mersenne-twister orphan 5 weeks ago
> javadocofflinesearch orphan 6 weeks ago
> jcodings orphan 5 weeks ago
> jffi orphan 5 weeks ago
> jgrapht gil, orphan 5 weeks ago
> jnr-constants orphan 5 weeks ago
> jnr-ffi orphan 5 weeks ago
> jnr-netdb orphan 5 weeks ago
> jnr-posix orphan 5 weeks ago
> jnr-x86asm orphan 5 weeks ago
> js-web-socket-js orphan 5 weeks ago
> kcm-fcitx cheeselee, orphan, yanqiyu 5 weeks ago
> kfaenza-icon-theme orphan 5 weeks ago
> kfilefactory orphan 5 weeks ago
> kompose dustymabe, go-sig, orphan 5 weeks ago
> libannodex orphan 4 weeks ago
> libbsr orphan 4 weeks ago
> libcmml orphan 4 weeks ago
> libfap orphan 5 weeks ago
> libmacaroons ellert, orphan 4 weeks ago
> libnatspec orphan 5 weeks ago
> libstroke orphan 4 weeks ago
> libusbauth-configparser orphan 5 weeks ago
> libverto-jsonrpc orphan 4 weeks ago
> lttv greenscientist, orphan 4 weeks ago
> lua-fun orphan 4 weeks ago
> mediawiki-backtick-code orphan 5 weeks ago
> mediawiki-semantic orphan 4 weeks ago
> mediawiki-validator orphan 4 weeks ago
> mesos orphan 5 weeks ago
> mingw-cxxtest orphan 5 weeks ago
> mingw-sigar orphan 5 weeks ago
> moarvm orphan 5 

[rpms/perl-String-Errf] PR #1: 0.009 bump; Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-String-Errf` that 
you are following:
``
0.009 bump; Package tests
``

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

Re: Orphaned packages looking for new maintainers

[Robby Callicotte via devel]

On Monday, January 2, 2023 10:02:41 AM CST Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
 that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life 
> Note: If you received this mail directly you (co)maintain one of the
> affected
 packages or a package that depends on one. Please adopt the
> affected package or retire your depending package to avoid broken
> dependencies, otherwise your package will fail to install and/or build when
> the affected package gets retired. 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2023-01-02.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 
>  Package  (co)maintainers   Status
> Change
> ===
> = 5minute   orphan   4
> weeks ago CFR   jvanek, orphan 
>  4 weeks ago CheMPS2   orphan  
> 4 weeks ago PolicyKit-olpcorphan   
>5 weeks ago aboot orphan
>   4 weeks ago albatross orphan 
>  5 weeks ago alleyoop  orphan  
> 5 weeks ago alure orphan   
>4 weeks ago amor  jgrulich,
> kde-sig, orphan,   5 weeks ago rdieter, than
> anki  chkr, orphan 4 weeks
> ago
 ansible-collection-google-cloud   infra-sig, orphan3
> weeks ago asn1c orphan 
>  4 weeks ago backup-managerorphan  
> 5 weeks ago bharati-m17n  orphan   
>4 weeks ago bibtex2html   orphan, thofmann  
>   4 weeks ago bluecurve-classic-metacity-   gnome-sig, orphan,
> rstrode   4 weeks ago theme
> bluecurve-gnome-theme gnome-sig, orphan, rstrode   4 weeks
> ago
 bluecurve-gtk-themes  gnome-sig, orphan, rstrode   4
> weeks ago bluecurve-icon-theme  gnome-sig, orphan, rstrode 
>  4 weeks ago bluecurve-kde-theme   gnome-sig, kkofler, orphan, 
> 4 weeks ago rdieter, rstrode, than
> bluecurve-metacity-theme  gnome-sig, orphan, rstrode   4 weeks
> ago
 bluecurve-xmms-skin   gnome-sig, orphan, rstrode   4
> weeks ago cairo-clock   orphan 
>  4 weeks ago code-editor   orphan  
> 5 weeks ago compton   orphan   
>5 weeks ago cups-bjnp orphan
>   5 weeks ago devilspie2orphan 
>  2 weeks ago dmz-cursor-themes company, orphan 
> 5 weeks ago ejabberd  bowlofeggs,
> jcline, orphan,  4 weeks ago xavierb
> erlang-epgsql lkundrak, orphan 5 weeks
> ago
 fwsnort   orphan   5
> weeks ago gdeploy   godas, orphan  
>  4 weeks ago ghasher   orphan  
> 4 weeks ago gl-117orphan, steve
>4 weeks ago glusterfs-selinux kkeithle, orphan,
> shwetha4 weeks ago gnome-activity-journalorphan
>   5 weeks ago gnome-nds-thumbnailer orphan 
>  5 weeks ago gnome-search-tool
> gnome-sig, orphan4 weeks ago gnome-shell-theme-selene  
>orphan   5 weeks ago gnonlin
>   orphan   4 weeks ago
> golang-github-gocomply-scap   go-sig, orphan   5 weeks
> ago golang-github-justinas-alice  go-sig, orphan   4
> weeks ago golang-github-lpabon-godbcgo-sig, orphan 
>  5 weeks ago golang-github-pkg-browser go-sig, orphan  
> 4 weeks ago golang-github-spaolacci-murmur3   go-sig, orphan 

[Bug 2157188] perl-Test-Abortable-0.003 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Abortable-0.003-1
   ||.fc38
 Resolution|--- |RAWHIDE
Last Closed||2023-01-02 17:32:45




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

[rpms/perl-Test-Abortable] PR #1: 0.003 bump; Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Test-Abortable` that 
you are following.

Merged pull-request:

``
0.003 bump; Package tests
``

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

[Bug 2157225] perl-String-Errf-0.009 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




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

[rpms/perl-Test-Abortable] PR #1: 0.003 bump; Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Test-Abortable` 
that you are following:
``
0.003 bump; Package tests
``

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

Re: Linking problem with ncurses on rawhide, not f37

[Florian Weimer]

* Miroslav Lichvar:

> On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote:
>> It may work to use this for libtinfo.so:
>> 
>> GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED 
>> (/usr/lib64/ncurses-novs/libncurses.so.6))
>
> FWIW, I tried this and the error messages from the swift-lang build
> changed from:
>
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `tparm@NCURSES6_TINFO_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `_nc_name_match@NCURSES6_TINFO_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `wtimeout@NCURSES6_TINFO_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `_nc_doalloc@NCURSES6_TINFO_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `_nc_safe_strcat@NCURSES6_TINFO_5.2.20001021'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `baudrate_sp@NCURSES6_TINFO_5.8.20110226'
> /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
> `_nc_update_screensize@NCURSES6_TINFO_5.0.19991023'
> ...
>
> to 
>
> /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> `wmove@NCURSES6_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> `derwin@NCURSES6_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> `wenclose@NCURSES6_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
> `_nc_panelhook_sp@NCURSES6_5.8.20110226'
> /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> `wcursyncup@NCURSES6_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> `copywin@NCURSES6_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> `newpad@NCURSES6_5.0.19991023'
> /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
> `wnoutrefresh@NCURSES6_5.0.19991023'
> ...
>
> libform and libpanel depend on libncurses.

Could you give them a similar treatment, with more linker scripts?

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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[mkolman]

On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote:
> On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> > Hi all,
> > 
> > > == Benefit to Fedora ==
> > > * Better secure boot support (specifically the initrd is covered
> > > by
> > > the signature).
> > > * Better confidential computing support (measurements are much
> > > more
> > > useful if we know what hashes to expect for the initrd).
> > > * More robust boot process (generating the initrd on the
> > > installed
> > > system is fragile, root cause for kernel bugs reported is simply
> > > a
> > > broken initrd sometimes).
> > Just want to add Anaconda installation environment is also fighting
> > with the
> > second point.
> 
> Third point I assume, i.e. initrd generation problems being reported
> as
> anaconda bugs?
> 
> While being at it: anaconda seems to explicitly call dracut to
> generate
> the initrd (according to the messages it prints).  What is the reason
> for this?  Shouldn't this already happen as part of the rpm
> transaction,
> when the kernel install scripts are running?
IIRC the main reason is the esentially random package installation
order during the RPM transaction.

Unlike on normal system during installation the RPM transaction
basically puts files into an empty folder, so if the kernel RPM script
that triggers dracut runs too early, some of the things it tries to
grab from the system might not yet be there & will be missing from the
initrd. On an already installed system, there would already be
something in places, while possibly a bit outdated, that dracut could
harvest and put to the initrd.

One concrete issue this caused was that users would use specific
characters in their LUKS password, Anaconda would make sure the given
package containing the layout is installed, but it would come after the
kernel package in the transaction & the layout would be missing from
the initrd. As a result, the user would not be able to type their
password.

In any case, this situation is sub-optimal, as we currently run dracut
at least twice - once via the kernel RPM script trigger and then again
when Anaconda triggers it. We really need to finally reach out to the
kernel package maintainers and device some mechanism that tells the
kernel package to skip the dracut run during the installation.



> 
> > Thanks to the PXE boot it's maybe even more fragile
> > environment.
> 
> Yep.  I'd highly recommend to use uefi http boot whenever possible.
> 
> Note that uefi http boot can also work with iso images, i.e. you can
> have the dhcp server hand out URLs to the fedora netboot iso.  The
> firmware will fetch the iso, create a ramdisk, add a acpi table for
> it so the OS finds it too, then go boot as it would be a physical
> cdrom all the way up to anaconda.
> 
> BTW: Having some way other than the kernel command line to pass
> config
> options to anaconda would make this much more useful.
> 
> take care,
>   Gerd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2157188] perl-Test-Abortable-0.003 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




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

[Bug 2157099] perl-DateTime-Format-Natural-1.14 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Depends On||2157746





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2157746
[Bug 2157746] Review Request: perl-Test-MockTime-HiRes - Replaces actual time
with simulated high resolution time
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157099
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Linking problem with ncurses on rawhide, not f37

[Miroslav Lichvar]

On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote:
> It may work to use this for libtinfo.so:
> 
> GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED 
> (/usr/lib64/ncurses-novs/libncurses.so.6))

FWIW, I tried this and the error messages from the swift-lang build
changed from:

/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`tparm@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_name_match@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`wtimeout@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_doalloc@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_safe_strcat@NCURSES6_TINFO_5.2.20001021'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`baudrate_sp@NCURSES6_TINFO_5.8.20110226'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_update_screensize@NCURSES6_TINFO_5.0.19991023'
...

to 

/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`wmove@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`derwin@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`wenclose@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
`_nc_panelhook_sp@NCURSES6_5.8.20110226'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`wcursyncup@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`copywin@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`newpad@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
`wnoutrefresh@NCURSES6_5.0.19991023'
...

libform and libpanel depend on libncurses.

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

Re: UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

[Gerd Hoffmann]

On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
> [...]
> > Note that uefi http boot can also work with iso images, i.e. you can
> > have the dhcp server hand out URLs to the fedora netboot iso.  The
> > firmware will fetch the iso, create a ramdisk, add a acpi table for
> > it so the OS finds it too, then go boot as it would be a physical
> > cdrom all the way up to anaconda.
> 
> That sounds very interesting. Could you describe how to set this up
> and/or provide some links to documentation?

On uefi http boot:

https://www.redhat.com/sysadmin/uefi-http-boot-libvirt

To boot iso images you essentially have to just replace
http://server/path/binary.efi with
http://server/path/netboot.iso

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2023-01-02.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

5minute   orphan   4 weeks ago
CFR   jvanek, orphan   4 weeks ago
CheMPS2   orphan   4 weeks ago
PolicyKit-olpcorphan   5 weeks ago
aboot orphan   4 weeks ago
albatross orphan   5 weeks ago
alleyoop  orphan   5 weeks ago
alure orphan   4 weeks ago
amor  jgrulich, kde-sig, orphan,   5 weeks ago
  rdieter, than
anki  chkr, orphan 4 weeks ago
ansible-collection-google-cloud   infra-sig, orphan3 weeks ago
asn1c orphan   4 weeks ago
backup-managerorphan   5 weeks ago
bharati-m17n  orphan   4 weeks ago
bibtex2html   orphan, thofmann 4 weeks ago
bluecurve-classic-metacity-   gnome-sig, orphan, rstrode   4 weeks ago
theme
bluecurve-gnome-theme gnome-sig, orphan, rstrode   4 weeks ago
bluecurve-gtk-themes  gnome-sig, orphan, rstrode   4 weeks ago
bluecurve-icon-theme  gnome-sig, orphan, rstrode   4 weeks ago
bluecurve-kde-theme   gnome-sig, kkofler, orphan,  4 weeks ago
  rdieter, rstrode, than
bluecurve-metacity-theme  gnome-sig, orphan, rstrode   4 weeks ago
bluecurve-xmms-skin   gnome-sig, orphan, rstrode   4 weeks ago
cairo-clock   orphan   4 weeks ago
code-editor   orphan   5 weeks ago
compton   orphan   5 weeks ago
cups-bjnp orphan   5 weeks ago
devilspie2orphan   2 weeks ago
dmz-cursor-themes company, orphan  5 weeks ago
ejabberd  bowlofeggs, jcline, orphan,  4 weeks ago
  xavierb
erlang-epgsql lkundrak, orphan 5 weeks ago
fwsnort   orphan   5 weeks ago
gdeploy   godas, orphan4 weeks ago
ghasher   orphan   4 weeks ago
gl-117orphan, steve4 weeks ago
glusterfs-selinux kkeithle, orphan, shwetha4 weeks ago
gnome-activity-journalorphan   5 weeks ago
gnome-nds-thumbnailer orphan   5 weeks ago
gnome-search-tool gnome-sig, orphan4 weeks ago
gnome-shell-theme-selene  orphan   5 weeks ago
gnonlin   orphan   4 weeks ago
golang-github-gocomply-scap   go-sig, orphan   5 weeks ago
golang-github-justinas-alice  go-sig, orphan   4 weeks ago
golang-github-lpabon-godbcgo-sig, orphan   5 weeks ago
golang-github-pkg-browser go-sig, orphan   4 weeks ago
golang-github-spaolacci-murmur3   go-sig, orphan   4 weeks ago
golang-github-sqshq-sampler   atim, go-sig, orphan 3 weeks ago
golie   

UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

[Dominik 'Rathann' Mierzejewski]

On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
[...]
> Note that uefi http boot can also work with iso images, i.e. you can
> have the dhcp server hand out URLs to the fedora netboot iso.  The
> firmware will fetch the iso, create a ramdisk, add a acpi table for
> it so the OS finds it too, then go boot as it would be a physical
> cdrom all the way up to anaconda.

That sounds very interesting. Could you describe how to set this up
and/or provide some links to documentation?

Regards,
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Gerd Hoffmann]

On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> Hi all,
> 
> > == Benefit to Fedora ==
> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
> > * Better confidential computing support (measurements are much more
> > useful if we know what hashes to expect for the initrd).
> > * More robust boot process (generating the initrd on the installed
> > system is fragile, root cause for kernel bugs reported is simply a
> > broken initrd sometimes).
> Just want to add Anaconda installation environment is also fighting with the
> second point.

Third point I assume, i.e. initrd generation problems being reported as
anaconda bugs?

While being at it: anaconda seems to explicitly call dracut to generate
the initrd (according to the messages it prints).  What is the reason
for this?  Shouldn't this already happen as part of the rpm transaction,
when the kernel install scripts are running?

> Thanks to the PXE boot it's maybe even more fragile
> environment.

Yep.  I'd highly recommend to use uefi http boot whenever possible.

Note that uefi http boot can also work with iso images, i.e. you can
have the dhcp server hand out URLs to the fedora netboot iso.  The
firmware will fetch the iso, create a ramdisk, add a acpi table for
it so the OS finds it too, then go boot as it would be a physical
cdrom all the way up to anaconda.

BTW: Having some way other than the kernel command line to pass config
options to anaconda would make this much more useful.

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

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Sam Varshavchik]

Florian Weimer writes:


After installing redhat-rpm-config, this works in bash and similar
shells:

$ eval `rpm --eval %set_build_flags`

Maybe we can make it more clear in buildflags.md that this macro is a
shell script fragment?


I find it more convenient to generate parameters for an autoconf-generated  
configure script. I do not need to always use the same build flags as rpm.  
Sometimes you want to build without optimizations, for debugging purposes.


What I do is

./configure `rpmflags`

with "rpmflags" being this script:

#! /bin/bash

echo -n "CXXFLAGS='"
rpm -E '%build_cxxflags' | tr -d '\012'
echo -n "' CFLAGS='"
rpm -E '%build_cflags' | sed 's/ *$//' | tr -d '\012'
echo -n "' LDFLAGS='"
rpm -E '%build_ldflags' | sed 's/ *$//' | tr -d '\012'
echo "'"

I suppose I can turn this inside-out, and change this to use  
%set_build_flags and directly run configure.




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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Gerd Hoffmann]

On Fri, Dec 23, 2022 at 09:01:52AM +0100, Vitaly Zaitsev via devel wrote:

> I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode
> and vice versa.

Needs installing the signing keys to the shim key database using
mokutil, but should otherwise work just fine.

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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Gerd Hoffmann]

  Hi,

> A much better approach is to install a TPM-generated key in the TPM’s
> NVRAM, with a policy that only allows the key to be used once a trusted
> operating system has booted.  That can be used as a trust anchor even
> without support from buggy UEFI firmware.

Side note: measuring kernel + initrd happens using UEFI firmware services.

(once the kernel is up'n'running it will use its own tpm drivers instead
of depending on the firmware services).

> Furthermore, measured boot allows tying e.g. LUKS keys to a
> combination of the actual OS booted and a passphrase needed to unlock
> the TPM.  This allows the TPM’s protection against brute-force attacks
> to be used.

You also want protect the initrd against modifications to make sure an
attacker can't sniff your passphrase.  Unified kernels help here too
because the initrd for a given kernel has a fixed and known hash.

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

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Vít Ondruch]

Dne 02. 01. 23 v 14:09 Florian Weimer napsal(a):

* Vít Ondruch:


And yes, that is the problem why upstream can't see the issues we see,
despite they were so kind to test on Fedora. Luckily, there was
analysis of the issue which initially triggered this discussion done
by Mamoru [1] and it seem that the issue are caused by
LTO. Nevertheless, if there was some way to tell them lets say:

1) $ sudo dnf install fedora-official-build-flags

2) $ with-fedora-official-build-flags make

That would be super convenient and I still find surprising we don't
have anything like this.

After installing redhat-rpm-config, this works in bash and similar
shells:

$ eval `rpm --eval %set_build_flags`

Maybe we can make it more clear in buildflags.md that this macro is a
shell script fragment?



My gut answer was something about "who reads the documentation", but 
since I was referring to the buildflags.md in the issue, then this could 
be probably good start :D


But still, if there was something I can remember or even find via e.g. 
tab completion, that would be much better.



Vít



Thanks,
Florian



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

Disabling Fedora 35 chroots in Copr

[Jiri Kyjovsky]

Hello,

we have just disabled Fedora 35 chroots in Copr.

According to the Fedora wiki [1], Fedora 35 reached the end of its life
on 2022-12-13 and therefore we are disabling it in Copr.

That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:

- fedora-35-x86_64
- fedora-35-i386
- fedora-35-ppc64le
- fedora-35-aarch64
- fedora-35-armhfp
- fedora-35-s390x

Additionally, according to Outdated chroots removal policy [2], Copr is
going to preserve existing build results in those chroots for another
180 days and then automatically remove them unless you take an action
and prolong the chroots life span in your projects. Read more about this
feature in the  Copr - Removing outdated chroots blog post [3].


[1] https://fedoraproject.org/wiki/End_of_life
[2]
https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[3] http://frostyx.cz/posts/copr-removing-outdated-chroots

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

[Bug 2152966] perl-PPIx-Regexp-0.086 is available

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2023-01-02 13:20:49




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

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Florian Weimer]

* Vít Ondruch:

> And yes, that is the problem why upstream can't see the issues we see,
> despite they were so kind to test on Fedora. Luckily, there was
> analysis of the issue which initially triggered this discussion done
> by Mamoru [1] and it seem that the issue are caused by
> LTO. Nevertheless, if there was some way to tell them lets say:
>
> 1) $ sudo dnf install fedora-official-build-flags
>
> 2) $ with-fedora-official-build-flags make
>
> That would be super convenient and I still find surprising we don't
> have anything like this.

After installing redhat-rpm-config, this works in bash and similar
shells:

$ eval `rpm --eval %set_build_flags`

Maybe we can make it more clear in buildflags.md that this macro is a
shell script fragment?

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

[Bug 2157630] Add perl-Image-Sane to EPEL9

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Petr Pisar  ---
https://pagure.io/releng/fedora-scm-requests/issue/50132


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

[Bug 2156981] perl-Log-Dispatch-Array-1.005 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-Log-Dispatch-Array-1.0
   ||05-1.fc38
 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
Last Closed||2023-01-02 12:53:28




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

[Bug 2157630] New: Add perl-Image-Sane to EPEL9

[bugzilla]

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

Bug ID: 2157630
   Summary: Add perl-Image-Sane to EPEL9
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Image-Sane
  Keywords: FutureFeature
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2151714
  Target Milestone: ---
Classification: Fedora



I need perl-Image-Sane for gscan2pdf in EPEL9. Please add the package there.



Referenced Bugs:

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

[rpms/perl-Log-Dispatch-Array] PR #1: 1.005 bump; Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Log-Dispatch-Array` 
that you are following.

Merged pull-request:

``
1.005 bump; Package tests
``

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

Re: Rpmautospec howto do a rebuild for something

[Maxwell G via devel]

On Mon Jan 2, 2023 at 12:32 +, Sérgio Basto wrote:
> I need rebuild a package that is using rpmautospec , how I can rebuild
> the package and increase relversion ?

`git commit --allow-empty -m "Changelog entry here"` will do what you
want. The empty commit will result in a release and changelog bump.

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

Re: Rpmautospec howto do a rebuild for something

[Mikel Olasagasti]

Hi Sérgio,

Hau idatzi du Sérgio Basto (ser...@serjux.com) erabiltzaileak (2023
urt. 2, al. (13:40)):
>
> I need rebuild a package that is using rpmautospec , how I can rebuild
> the package and increase relversion ?

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

[Bug 2157099] perl-DateTime-Format-Natural-1.14 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Depends On||2157628





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2157628
[Bug 2157628] Review Request: perl-DateTime-HiRes - Create DateTime objects
with sub-second current time resolution
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157099
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-PPIx-Regexp] PR #14: 0.086 bump

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-PPIx-Regexp` that you 
are following.

Merged pull-request:

``
0.086 bump
``

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

Rpmautospec howto do a rebuild for something

[Sérgio Basto]

Hi,

I need rebuild a package that is using rpmautospec , how I can rebuild
the package and increase relversion ? 


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

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Vít Ondruch]

Dne 24. 12. 22 v 20:49 Florian Weimer napsal(a):

* Vít Ondruch:


Working with upstream on one issue [1], it seems that the culprit is in
the Fedora compiler options. Is there some convenient way to set them
up? Of course I can copy them from log, or somehow put together from the
RPM macros, but I'd appreciate if there was some easier way. Can we e.g.
distribute some script, which would set them up, as part or some RPM?

Build systems and test harnesses often tweak the build flags, so it's
probably best to enable logging there to see what's going on.



Of course the build flags can be seen from the build log, but precisely 
for the reason that "Build systems and test harnesses often tweak the 
build flags", I'd like to have easy way to provide upstream with the 
default Fedora build flags.





Different distributions also have different compiler defaults.  For
example, most of Fedora's explicit compiler flags are enabled by
default in Ubuntu's GCC.



And yes, that is the problem why upstream can't see the issues we see, 
despite they were so kind to test on Fedora. Luckily, there was analysis 
of the issue which initially triggered this discussion done by Mamoru 
[1] and it seem that the issue are caused by LTO. Nevertheless, if there 
was some way to tell them lets say:


1) $ sudo dnf install fedora-official-build-flags

2) $ with-fedora-official-build-flags make

That would be super convenient and I still find surprising we don't have 
anything like this.



Vít


[1] https://bugs.ruby-lang.org/issues/19248#note-14



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

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

[Kevin Kofler via devel]

Dominik 'Rathann' Mierzejewski wrote:
> Personally, I use the kernel's recommended commit to the oldest
> supported branch and merge upwards workflow and I've learned not to be
> afraid of merge commits. If any branch needs some specific fixes,
> I just apply them there and only there, without using spec conditionals.
> This keeps the specfiles clean and readable, even if they differ
> between branches. Obviously, this can't be (easily) automated and
> doesn't scale to hundreds or thousands of packages, but it works well
> for leaf packages.
> 
> rpmautospec doesn't work with the above workflow as it breaks on those
> merge commits, produces bogus changelog messages and artificially
> inflates Release counters.

This (the failure to handle merge commits) is a serious limitation because 
this is one of the workflows where an autochangelog would be most useful, in 
order to avoid the merge conflicts on the changelog.

If you work the way I do, avoiding merge commits in favor of fast forwards 
and specfile conditionals, then rpmautospec can in principle generate the 
autochangelog, but in that case, I do not really need it because my manual 
changelog fast-forwards just fine along with the rest of the commit.

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

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

[Kevin Kofler via devel]

Matthew Miller wrote:
> Okay. no. This is not how we do things here.

Apologies for my snide remark that visibly came out rude, sorry.

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

[rpms/perl-PPIx-Regexp] PR #14: 0.086 bump

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-PPIx-Regexp` that 
you are following:
``
0.086 bump
``

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

[Bug 2157618] perl-Dancer-1.3520 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Dancer-1.3520-1.fc36.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=95721511


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

[Bug 2157618] perl-Dancer-1.3520 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1935279
  --> https://bugzilla.redhat.com/attachment.cgi?id=1935279=edit
Update to 1.3520 (#2157618)


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

[Bug 2157618] New: perl-Dancer-1.3520 is available

[bugzilla]

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

Bug ID: 2157618
   Summary: perl-Dancer-1.3520 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dancer
  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,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.3520
Upstream release that is considered latest: 1.3520
Current version/release in rawhide: 1.3513-15.fc38
URL: https://metacpan.org/release/Dancer

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


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


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


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


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


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

[Bug 2157274] perl-File-Find-Object-0.3.7 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-File-Find-Object-0.3.7
   ||-1.fc38
 Resolution|--- |ERRATA
Last Closed||2023-01-02 11:52:04



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


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

[Bug 2157274] perl-File-Find-Object-0.3.7 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-7853466083 has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-7853466083


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

[Bug 2157099] perl-DateTime-Format-Natural-1.14 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




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

[Bug 2152966] perl-PPIx-Regexp-0.086 is available

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Michal Josef Spacek  ---
Changes:

0.086   2022-12-13  T. R. Wyant
Add width(), which returns the number of characters matched. Note
that an indefinite upper boumd is represented as IEEE 754 Inf if
that appears to be supported; otherwise by a singleton object
overloaded to allow stringification, numification, and numeric
tests.

Use width() to enhance the detection of variable-width look-behinds.

Serious clean-up on accepts_perl() subsystem.

There are API changes, only for rawhide


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

[rpms/perl-Log-Dispatch-Array] PR #1: 1.005 bump; Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: 
`perl-Log-Dispatch-Array` that you are following:
``
1.005 bump; Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Log-Dispatch-Array/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2156981] perl-Log-Dispatch-Array-1.005 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|iarn...@gmail.com,  |
   |jose.p.oliveira.oss@gmail.c |
   |om, jples...@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.
https://bugzilla.redhat.com/show_bug.cgi?id=2156981
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2156233] perl-podlators-5.01 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-podlators-5.01-1.fc38
 Status|ASSIGNED|CLOSED
Last Closed||2023-01-02 11:06:32




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

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

[Dominik 'Rathann' Mierzejewski]

On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
> Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > produces bogus changelog messages and artificially
> > inflates Release counters.
> 
> I always wondered why people are afraid of gaps in numbering? It is
> just a number. The number will not object if you skip some of them. :)

Gaps in release numbering are just not neat. To me, they create an
unnecessary confusion. Each bump in Release field should have a
corresponding build in koji and it makes me wonder why if it doesn't.

> Or it is my origin in BASIC that I am not afraid of that? We numbered
> the lines as a multiply of 5 or 10. :)

I've written code in BASIC back in the day. This comment is irrelevant
to the issue at hand.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Jiri Konecny]

Similar situation happens if you have spec file in upstream. The problem 
is that mass rebuilds are
adding entries to dowstream spec file only, so you have to manually 
merge the upstream and
downstream or ideally do a backport upstream before realese. This is 
nice and easy solution for

the issue.

Even though, we solved that by using Packit for releasing.

Jirka

Dne 01. 01. 23 v 20:51 Fabio Valentini napsal(a):

On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen  wrote:

My main questions are what is this supposed to fix long term?

I have guessed that it has to do with automation, the shrinking number of active 
packagers in operating systems, and the exploding number of packages in requested 
languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say 
"HOW" this gets to dealing with this long term. It also isn't clear what the 
underlying remaining active packagers want to be part of.

Speaking for myself: Using rpmautospec has massively reduced the
maintenance burden for the Rust stack, and also for other packages
that I maintain.

Due to the way optional dependencies / features are mapped to RPM
subpackages (this works like with "extra" dependencies in Python
packages, so this is not unique to Rust), you really should regenerate
the entire spec file with rust2rpm for every new version (and every
time when touching a patch that modifies features / optional
dependencies in Rust crate metadata).

Previously, this meant arduously copying the old changelog contents
somewhere, regenerating the spec file with rust2rpm, copying the old
changelog back, set the Release count to "0", run "rpmdev-bumpspec"
for the latest change, and commit the changes (usually with a useless
duplicate of the changelog entry as commit message).

With rpmautospec, all steps except "regenerate the spec file with
rust2rpm" and "git commit -c 'changelog contents'" are eliminated,
which makes updating packages *much* easier, faster, and less
error-prone.

Additionally, not having Release counter and changelog in the .spec
file means that you can usually freely cherry-pick or merge bug-fix
commits across different dist-git branches. This wasn't possible
without rpmautospec due to merge conflicts caused by different Release
counter or changelog contents.

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

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

Fedora rawhide compose report: 20230102.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230101.n.0
NEW: Fedora-Rawhide-20230102.n.0

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

Size of added packages:  24.06 KiB
Size of dropped packages:0 B
Size of upgraded packages:   4.41 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230102.n.0.iso
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20230102.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-clap_lex0.2-0.2.4-1.fc38
Summary: Minimal, flexible command line parser
RPMs:rust-clap_lex0.2+default-devel rust-clap_lex0.2-devel
Size:24.06 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ansible-lint-1:6.10.1-1.fc38
Old package:  ansible-lint-1:6.10.0-1.fc38
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Size: 507.02 KiB
Size change:  2.37 KiB
Changelog:
  * Mon Jan 02 2023 Parag Nemade  - 1:6.10.1-1
  - Update to 6.10.1 version (#2157189)


Package:  babel-2.11.0-1.fc38
Old package:  babel-2.10.3-3.fc37
Summary:  Tools for internationalizing Python applications
RPMs: babel babel-doc python3-babel
Size: 6.87 MiB
Size change:  -35.28 KiB
Changelog:
  * Sun Jan 01 2023 Felix Schwarz  - 2.11.0-1
  - update to 2.11.0


Package:  cross-gcc-12.2.1-2.fc38
Old package:  cross-gcc-12.2.1-1.fc38
Summary:  Cross C compiler
RPMs: cross-gcc-common gcc-aarch64-linux-gnu gcc-alpha-linux-gnu 
gcc-arc-linux-gnu gcc-arm-linux-gnu gcc-avr32-linux-gnu gcc-bfin-linux-gnu 
gcc-c++-aarch64-linux-gnu gcc-c++-alpha-linux-gnu gcc-c++-arc-linux-gnu 
gcc-c++-arm-linux-gnu gcc-c++-avr32-linux-gnu gcc-c++-bfin-linux-gnu 
gcc-c++-c6x-linux-gnu gcc-c++-frv-linux-gnu gcc-c++-h8300-linux-gnu 
gcc-c++-hppa-linux-gnu gcc-c++-hppa64-linux-gnu gcc-c++-ia64-linux-gnu 
gcc-c++-m68k-linux-gnu gcc-c++-microblaze-linux-gnu gcc-c++-mips64-linux-gnu 
gcc-c++-mn10300-linux-gnu gcc-c++-nios2-linux-gnu gcc-c++-openrisc-linux-gnu 
gcc-c++-powerpc64-linux-gnu gcc-c++-powerpc64le-linux-gnu 
gcc-c++-ppc64-linux-gnu gcc-c++-ppc64le-linux-gnu gcc-c++-riscv64-linux-gnu 
gcc-c++-s390x-linux-gnu gcc-c++-sparc64-linux-gnu gcc-c++-tile-linux-gnu 
gcc-c++-x86_64-linux-gnu gcc-c++-xtensa-linux-gnu gcc-c6x-linux-gnu 
gcc-frv-linux-gnu gcc-h8300-linux-gnu gcc-hppa-linux-gnu gcc-hppa64-linux-gnu 
gcc-ia64-linux-gnu gcc-m68k-linux-gnu gcc-microblaze-linux-gnu 
gcc-mips64-linux-gnu gcc-mn10300-linux-gnu gcc-nios2-linux-gnu 
gcc-openrisc-linux-gnu gcc-powerpc64-linux-gnu gcc-powerpc64le-linux-gnu 
gcc-ppc64-linux-gnu gcc-ppc64le-linux-gnu gcc-riscv64-linux-gnu 
gcc-s390x-linux-gnu gcc-sparc64-linux-gnu gcc-tile-linux-gnu 
gcc-x86_64-linux-gnu gcc-xtensa-linux-gnu
Size: 3.66 GiB
Size change:  -194.19 KiB
Changelog:
  * Sun Jan 01 2023 Dan Hor??k  - 12.2.1-2
  - fix the openrisc toolchain triplet to match binutils (rhbz#2096361)


Package:  edgar-1.36-1.fc38
Old package:  edgar-1.35-3.fc37
Summary:  A platform game
RPMs: edgar
Size: 489.79 MiB
Size change:  11.68 KiB
Changelog:
  * Sun Jan 01 2023 Andrea Musuruane  - 1.36-1
  - Updated to new upstream release


Package:  fontforge-20230101-2.fc38
Old package:  fontforge-20220308-3.fc37
Summary:  Outline and bitmap font editor
RPMs: fontforge fontforge-devel fontforge-doc
Size: 34.80 MiB
Size change:  303.07 KiB
Changelog:
  * Mon Jan 02 2023 Parag Nemade  - 20230101-1
  - Update to 20230101 version (#2157290)

  * Mon Jan 02 2023 Parag Nemade  - 20230101-2
  - Update license tag to SPDX format
  - Fix test failure


Package:  golang-github-docker-22.06.0~beta.0-7.fc38
Old package:  golang-github-docker-22.06.0~beta.0-4.fc38
Summary:  Collaborative project for the container ecosystem
RPMs: compat-golang-github-moby-devel golang-github-docker-devel
Size: 2.66 MiB
Size change:  -2.35 KiB

Package:  golang-github-inconshreveable-mousetrap-1.1.0-1.fc38
Old package:  golang-github-inconshreveable-mousetrap-1.0.0-11.fc37
Summary:  Detect starting from Windows explorer
RPMs: golang-github-inconshreveable-mousetrap-devel
Size: 14.32 KiB
Size change:  2.23 KiB
Changelog:
  * Mon Jan 02 2023 Maxwell G  - 1.1.0-1
  - Update to 1.1.0. Fixes rhbz#2116345.


Package:  golang-x-term-0.3.0-1.fc38
Old package:  golang-x-term-0-0.8.20220129git03fcf44.fc37
Summary:  Go terminal and console support
RPMs: golang-x-term-devel
Size: 24.26 KiB
Size change:  -5.06 KiB
Changelog:
  * Mon Jan 02 2023 Maxwell G  0.3.0-1
  - Update to 0.3.0.


Package:  gputils-1.5.2-0.fc38
Old package:  gputils-1.5.0-10.fc37

[Bug 2156233] perl-podlators-5.01 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |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.
https://bugzilla.redhat.com/show_bug.cgi?id=2156233
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2156199] perl-ExtUtils-MakeMaker-7.66 is available

[bugzilla]

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



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


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

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

[Maxwell G via devel]

On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
> Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > produces bogus changelog messages and artificially
> > inflates Release counters.
>
> I always wondered why people are afraid of gaps in numbering? It is
> just a number. The number will not object if you skip some of them. :)

The release number shows how many builds of the same version have been
made. A high release is also baseline indicator that a package/project
is stale downstream and/or upstream. When the first build of foo v1.5.0
is foo-1.5.0-6 because the author took the time to split up logical
changes into separate commits, the value of that release number is lost.

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

Kernel 6.1 Test Week 2023-01-03 through 2023-01-08

[Sumantro Mukherjee]

Hey All,

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

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

[0] http://fedoraproject.org/wiki/Test_Day:2023-01-03_Kernel_6.1_Test_Week
[1] https://testdays.fedoraproject.org/events/146

Happy New Year and Happy Testing!
-- 
//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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2156199] perl-ExtUtils-MakeMaker-7.66 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-ExtUtils-MakeMaker-7.6
   ||6-1.fc38
 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |ppi...@redhat.com   |
 Status|NEW |MODIFIED




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

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

[Miroslav Suchý]

Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):

produces bogus changelog messages and artificially
inflates Release counters.


I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you 
skip some of them. :)


Or it is my origin in BASIC that I am not afraid of that? We numbered the lines 
as a multiply of 5 or 10. :)

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

[Bug 2156168] perl-ExtUtils-Install-2.22 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-ExtUtils-Install-2.22-
   ||1.fc38
 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
Last Closed||2023-01-02 08:45:17




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

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

[Dominik 'Rathann' Mierzejewski]

On Sunday, 01 January 2022 at 20:51, Fabio Valentini wrote:
[...]
> Additionally, not having Release counter and changelog in the .spec
> file means that you can usually freely cherry-pick or merge bug-fix
> commits across different dist-git branches. This wasn't possible
> without rpmautospec due to merge conflicts caused by different Release
> counter or changelog contents.

Personally, I use the kernel's recommended commit to the oldest
supported branch and merge upwards workflow and I've learned not to be
afraid of merge commits. If any branch needs some specific fixes,
I just apply them there and only there, without using spec conditionals.
This keeps the specfiles clean and readable, even if they differ
between branches. Obviously, this can't be (easily) automated and
doesn't scale to hundreds or thousands of packages, but it works well
for leaf packages.

rpmautospec doesn't work with the above workflow as it breaks on those
merge commits, produces bogus changelog messages and artificially
inflates Release counters.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-ExtUtils-Install] PR #1: 2.22 bump; Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-ExtUtils-Install` 
that you are following.

Merged pull-request:

``
2.22 bump; Package tests
``

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