Re: Silent changes in Packaging Guidelines

[Kevin Kofler via devel]

Petr Pisar wrote:
> However, this is not true anomore. E.g. In February a ban for wildcard
> %files was augmented from dynamic libraries to all top-level files
> :

When will this silliness ever stop? It just does not make sense to 
explicitly list every single file in the RPM. Wildcards are often the only 
reasonable way.

It is already enough of a PITA that we are now forced to explicitly maintain 
the soname for libraries in our specfiles. (I have always been opposed to 
that. Soversions are the main thing for which I used to *always* use a 
wildcard.)

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: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Benson Muite]

On 11/2/22 13:03, Florian Weimer wrote:

* Demi Marie Obenour:


On 11/2/22 02:56, Florian Weimer wrote:

* Benson Muite:


On 11/1/22 06:35, Orion Poplawski wrote:

While poking at building openmpi with clang, I started wondering
about flang and some things:
* Should %set_build_flags set FC?  I think it should since it sets
FCFLAGS.
* Is flang-new even worth bothering with?  See the following
configure check:



Yes, this will be helpful.  Significant work has gone into optimizing
this for A64FX


Fedora does not run well on A64FX because we enable PAC+BTI, adding
significant overhead to most function calls.


How is this specific to A64FX?


It just is?  I'm not aware of any other AArch64 CPUs that are impacted
in the same way.
It is not specific to A64-FX, but flang has been optimized for aarch64 
as a result of this.  Thus, use of flang likely to grow in use for 
applications that use MPI.  My expectation is that Fedora is mostly used 
for testing MPI applications, though with increasing core counts, 
production use on workstations will likely grow.


Maybe I don't understand the question.

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

[Test-Announce] Fedora 37 Candidate RC-1.6 Available Now!

[rawhide]

According to the schedule [1], Fedora 37 Candidate RC-1.6 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.6_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on libera.chat [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-37/f-37-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_37_RC_Release_Criteria
[4] https://web.libera.chat/?channels=#fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Karma for OpenSSL needed

[Sam Varshavchik]

Otto Liljalaakso writes:


Kevin Fenzi kirjoitti 2.11.2022 klo 20.33:

So, I suppose the web interface could offer signed copies if they exist,
but might be confusing if you don't know what the various keys short
hash is. Feel free to file a RFE for koji folks: https://pagure.io/koji


I personally will not, because I have been happily downloading the unsigned  
builds from Koji for testing, thus I cannot really present the case.
But perhaps somebody who would prefer, or insists on, using only signed  
builds wants to?


Given the package URLs are https:// URLs to the fedoraproject.org domain,  
their downloads are effectively signed by fedoraproject.org's SSL  
certificate, which is comparably cryptographically strong as PGP-signed RPMs.


Without having any direct knowledge of the process that PGP-signs the built  
RPMs, I suppose that it's theoretically possible for fedoraproject.org's web  
server to be compromised, which would allow for distribution of compromised  
RPMs, without compromising the PGP-signing infrastructure. But, in  
exceptional situations like the current one, everyone can weigh all the risk  
factors and make an intelligent decision by themselves.




pgp7nqtHC98ST.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: libxml2-2.10.3-1.fc36 breaks (part of) GraphicsMagick

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 01 November 2022 at 10:06, Petr Pisar wrote:
> V Tue, Nov 01, 2022 at 05:31:08PM +0900, Mamoru TASAKA napsal(a):
> > Michael J Gruber wrote on 2022/10/29 5:19:
> > > With this libxml2 update:
[...]
> > This is perhaps due to the following change:
> > https://gitlab.gnome.org/GNOME/libxml2/-/commit/a0a0f3be93753e387e31e7de95904a24b3c876dd
> > 
> [...]
> > 
> > I think libxml2 2.10.x (with current configuration) should not have brought 
> > into
> > F37/36/35 branches. Currently at least the following action is required.

+1

> > * Either rebuilding all packages requiring the above symbol
> > * Or fixing libxml2 2.10.x

+1, rebuild libxml2 --with-ftp in %configure call.

> > * Or introduce epoch on libxml2 and downgrade to 2.9.x
> > 
> https://bugzilla.redhat.com/show_bug.cgi?id=2136800

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

rpmsodiff test containing removed symbols should trigger negative
karma automatically.

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

[EPEL-devel] Is is worth packaging PHP stuff in EPEL8+?

[Orion Poplawski]

Is is worth packaging PHP stuff in EPEL8+?

It seems very modular in RHEL and Remi's repos, but EPEL isn't doing modules.

If it is worthwhile, is anyone interested in helping out?  I was hoping to get
mediawiki 1.35 into EPEL8.

Orion

-- 
Orion Poplawski
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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

F38 proposal: Ruby 3.2 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_3.2

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.

== Summary ==
Ruby 3.2 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 3.1 in Fedora 37 to
Ruby 3.2 in Fedora 38, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondr...@redhat.com


== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== WASI based WebAssembly support ===

This is an initial port of WASI based WebAssembly support. This
enables a CRuby binary to be available on Web browser, Serverless Edge
environment, and other WebAssembly/WASI embedders. Currently this port
passes basic and bootstrap test suites not using Thread API.

=== Regexp timeout ===

A timeout feature for Regexp matching is introduced.

It is known that Regexp matching may take unexpectedly long. If your
code attempts to match an possibly inefficient Regexp against an
untrusted input, an attacker may exploit it for efficient Denial of
Service (so-called Regular expression DoS, or ReDoS).

The risk of DoS can be prevented or significantly mitigated by
configuring `Regexp.timeout` according to the requirements of your
Ruby application. Please try it out in your application and welcome
your feedback.

=== Other Notable New Features ===

* Language
** Anonymous rest and keyword rest arguments can now be passed as
arguments, instead of just used in method parameters.
** A proc that accepts a single positional argument and keywords will
no longer autosplat.
** Constant assignment evaluation order for constants set on explicit
objects has been made consistent with single attribute assignment
evaluation order.
** Find pattern is no longer experimental.
** Methods taking a rest parameter and wishing to delegate keyword
arguments through `foo(*args)` must now be marked with
`ruby2_keywords`
* Performance improvements
** YJIT
*** Support arm64 / aarch64 on UNIX platforms.
*** Building YJIT requires Rust 1.58.1+.

=== Other notable changes since 3.1 ===

* Hash
** Hash#shift now always returns nil if the hash is empty, instead of
returning the default value or calling the default proc.
* MatchData
** MatchData#byteoffset has been added.
* Module
** Module.used_refinements has been added.
** Module#refinements has been added.
** Module#const_added has been added.
* Proc
** Proc#dup returns an instance of subclass.
** Proc#parameters now accepts lambda keyword.
* Refinement
** Refinement#refined_class has been added.
* Set
** Set is now available as a builtin class without the need for
`require "set"`. It is currently autoloaded via the `Set` constant or
a call to `Enumerable#to_set`.
* String
** String#byteindex and String#byterindex have been added.
** Update Unicode to Version 14.0.0 and Emoji Version 14.0. (also
applies to Regexp)
** String#bytesplice has been added.
* Struct
** A Struct class can also be initialized with keyword arguments
without `keyword_init: true` on `Struct.new`

=== Compatibility issues ===

* Removed constants
** `Fixnum` and `Bignum`
** `Random::DEFAULT`
** `Struct::Group`
** `Struct::Passwd`
* Removed methods
** `Dir.exists?`
** `File.exists?`
** `Kernel#=~`
** `Kernel#taint`, `Kernel#untaint`, `Kernel#tainted?`
** `Kernel#trust`, `Kernel#untrust`, `Kernel#untrusted?`

=== C API updates ===

* Removed C APIs
** `rb_cData` variable.
** "taintedness" and "trustedness" functions.


== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.2. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/134
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.2 properly.

* Release engineering: [https://pagure.io/releng/issues/5 #5]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.

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


== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
* Ruby packages/application dependencies might need to be adjusted if
newly bundled gems are used.

== How To Test ==
* No special 

F38 proposal: Ruby 3.2 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_3.2

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.

== Summary ==
Ruby 3.2 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 3.1 in Fedora 37 to
Ruby 3.2 in Fedora 38, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondr...@redhat.com


== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== WASI based WebAssembly support ===

This is an initial port of WASI based WebAssembly support. This
enables a CRuby binary to be available on Web browser, Serverless Edge
environment, and other WebAssembly/WASI embedders. Currently this port
passes basic and bootstrap test suites not using Thread API.

=== Regexp timeout ===

A timeout feature for Regexp matching is introduced.

It is known that Regexp matching may take unexpectedly long. If your
code attempts to match an possibly inefficient Regexp against an
untrusted input, an attacker may exploit it for efficient Denial of
Service (so-called Regular expression DoS, or ReDoS).

The risk of DoS can be prevented or significantly mitigated by
configuring `Regexp.timeout` according to the requirements of your
Ruby application. Please try it out in your application and welcome
your feedback.

=== Other Notable New Features ===

* Language
** Anonymous rest and keyword rest arguments can now be passed as
arguments, instead of just used in method parameters.
** A proc that accepts a single positional argument and keywords will
no longer autosplat.
** Constant assignment evaluation order for constants set on explicit
objects has been made consistent with single attribute assignment
evaluation order.
** Find pattern is no longer experimental.
** Methods taking a rest parameter and wishing to delegate keyword
arguments through `foo(*args)` must now be marked with
`ruby2_keywords`
* Performance improvements
** YJIT
*** Support arm64 / aarch64 on UNIX platforms.
*** Building YJIT requires Rust 1.58.1+.

=== Other notable changes since 3.1 ===

* Hash
** Hash#shift now always returns nil if the hash is empty, instead of
returning the default value or calling the default proc.
* MatchData
** MatchData#byteoffset has been added.
* Module
** Module.used_refinements has been added.
** Module#refinements has been added.
** Module#const_added has been added.
* Proc
** Proc#dup returns an instance of subclass.
** Proc#parameters now accepts lambda keyword.
* Refinement
** Refinement#refined_class has been added.
* Set
** Set is now available as a builtin class without the need for
`require "set"`. It is currently autoloaded via the `Set` constant or
a call to `Enumerable#to_set`.
* String
** String#byteindex and String#byterindex have been added.
** Update Unicode to Version 14.0.0 and Emoji Version 14.0. (also
applies to Regexp)
** String#bytesplice has been added.
* Struct
** A Struct class can also be initialized with keyword arguments
without `keyword_init: true` on `Struct.new`

=== Compatibility issues ===

* Removed constants
** `Fixnum` and `Bignum`
** `Random::DEFAULT`
** `Struct::Group`
** `Struct::Passwd`
* Removed methods
** `Dir.exists?`
** `File.exists?`
** `Kernel#=~`
** `Kernel#taint`, `Kernel#untaint`, `Kernel#tainted?`
** `Kernel#trust`, `Kernel#untrust`, `Kernel#untrusted?`

=== C API updates ===

* Removed C APIs
** `rb_cData` variable.
** "taintedness" and "trustedness" functions.


== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.2. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/134
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.2 properly.

* Release engineering: [https://pagure.io/releng/issues/5 #5]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.

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


== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
* Ruby packages/application dependencies might need to be adjusted if
newly bundled gems are used.

== How To Test ==
* No special 

How to fix RPM ARCH not defined?

[Markus Neteler]

Hi,

I am one of the maintainers of the GRASS GIS package (also a core
developer) and currently stuck with this bug report:

RPM ARCH not defined
https://bugzilla.redhat.com/show_bug.cgi?id=2138373

I was able to reproduce it in a F37 docker container but have no clue
how to address this problem.
The dirty hack of settings these env variables "solves" it but there
must be a real solution:

export RPM_ARCH=bla
export RPM_PACKAGE_RELEASE=bla
export RPM_PACKAGE_VERSION=bla
export RPM_PACKAGE_NAME=bla

Hints welcome!

Thanks,
Markus

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

Schedule for Thursday's FPC Meeting (2022-11-03 16:00 UTC)

[James Antill]

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

 Local time information (via. uitime):

= Day: Thursday ==
2022-11-03 09:00 PDT  US/Pacific
2022-11-03 12:00 EDT  --> US/Eastern <--
2022-11-03 16:00 GMT  Europe/London 
2022-11-03 16:00 UTC  UTC   
2022-11-03 17:00 CET  Europe/Berlin 
2022-11-03 17:00 CET  Europe/Paris  
2022-11-03 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2022-11-04 00:00 HKT  Asia/Hong_Kong
2022-11-04 00:00 +08  Asia/Singapore
2022-11-04 01:00 JST  Asia/Tokyo
2022-11-04 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

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

= Followup Actions =

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

= New Pull Requests =

#1201 initial Ansible Collection guidelines 
https://pagure.io/packaging-committee/pull-request/1201

#1207 Ruby: update instructions for checking out excluded tests 
https://pagure.io/packaging-committee/pull-request/1207

= Followup Issues =

#topic #1159 Ban use of %configure in %prep
.fpc 1159
https://pagure.io/packaging-committee/issue/1159

#topic #1193 Clarify packaging guidelines for .NET applications 
.fpc 1193
https://pagure.io/packaging-committee/issue/1193

= Followup Pull Requests =

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

#topic #pr-1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097

= Open Floor = 

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

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

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





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

Re: Advice on packaging Python with Rust dependency

[Fabio Valentini]

On Wed, Nov 2, 2022 at 12:42 PM Ondrej Pohorelsky  wrote:
>
> The missing dependency is pkg-version[0]. It seems like its only outside 
> dependency is already packaged[1] in Fedora.
>
> It would be great if you could package it. If not, I'll look into it.
>
>
> [0]https://docs.rs/pkg-version/latest/pkg_version/index.html
> [1]https://src.fedoraproject.org/rpms/rust-proc-macro-hack

I wonder why there need to be two (yes, pkg-version and
pkg-version-impl) libraries just to read three environment variables?

Are you sure that reading the "CARGO_PKG_VERSION_MAJOR" /
"CARGO_PKG_VERSION_MINOR" / "CARGO_PKG_VERSION_PATCH" environment
variables directly wouldn't be ... easier ... than adding two
additional dependencies?

I mean, I *can* package these two crates, but they are comically small
(~two dozen lines of code), and their functionality could in most
cases be replaced with single lines of dependency-free Rust code :(

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

Re: Karma for OpenSSL needed

[Otto Liljalaakso]

Kevin Fenzi kirjoitti 2.11.2022 klo 20.33:

On Wed, Nov 02, 2022 at 08:15:00PM +0200, Otto Liljalaakso wrote:


Would it be possible to update Koji's web UI so that it offers the signed
one for download? Is there anything going for the current behavior of
offering the unsigned one instead?


Which signed one?
Some packages have multiple signed copies at the same time.

koji also only knows them by their short hash of the key, not
'fedora-37' or something.

Signed packages are cleaned up after some amount of time if they are not
in a tag requiring keeping them.


Thank you for this information, I was not aware of these details.


So, I suppose the web interface could offer signed copies if they exist,
but might be confusing if you don't know what the various keys short
hash is. Feel free to file a RFE for koji folks: https://pagure.io/koji


I personally will not, because I have been happily downloading the 
unsigned builds from Koji for testing, thus I cannot really present the 
case.
But perhaps somebody who would prefer, or insists on, using only signed 
builds wants to?

___
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: Karma for OpenSSL needed

[Josh Stone]

On 11/1/22 3:51 PM, Kevin Fenzi wrote:
> On Tue, Nov 01, 2022 at 02:55:34PM -0700, Josh Stone wrote:
>> On 11/1/22 11:16 AM, Neal Gompa wrote:
>>> That said, the packages *are* signed in Koji, because as soon as it's
>>> submitted to Bodhi, the packages are signed in-place in Koji.
>>
>> Is that really in-place? Bodhi says these are signed, but when I
>> download from koji, "rpm -qip" still shows "Signature: (none)".
> 
> If you download the direct build links you get unsigned copies. 
> 
> If you use something like: 
> 
> koji download-build --key=5323552a openssl-3.0.5-2.fc37
> 
> you get builds signed with the f37 key. 
> 
> Or you can look directly at: 
> https://kojipkgs.fedoraproject.org/packages/openssl/3.0.5/3.fc37/data/signed/5323552a/

It would be great to have that linked from Bodhi, perhaps on the Builds
tab on the "Build signed" key icon for each package.
___
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 2139510] New: perl-URI-5.17 is available

[bugzilla]

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

Bug ID: 2139510
   Summary: perl-URI-5.17 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-URI
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 5.17
Upstream release that is considered latest: 5.17
Current version/release in rawhide: 5.16-1.fc38
URL: http://search.cpan.org/dist/URI/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139510
___
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: Karma for OpenSSL needed

[Kevin Fenzi]

On Wed, Nov 02, 2022 at 08:15:00PM +0200, Otto Liljalaakso wrote:
> Vít Ondruch kirjoitti 2.11.2022 klo 16.18:
> > 
> > Dne 01. 11. 22 v 18:59 Fabio Valentini napsal(a):
> > > On Tue, Nov 1, 2022 at 6:53 PM Demi Marie Obenour
> > >  wrote:
> > > > 
> > > > Please push them out to testing immediately.  Some, such as
> > > > myself, simply
> > > > refuse to install unsigned packages.
> > > The packages are already signed, no need to wait for them to be pushed
> > > to testing.
> > > 
> > 
> > Just FTR, this is the URL which can be obtained from Koji:
> > 
> > https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm
> > 
> > and this is the signed version:
> > 
> > https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/data/signed/5323552a/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm
> > 
> > 
> > Not sure if there is any better way to obtain the signed version early.
> 
> Would it be possible to update Koji's web UI so that it offers the signed
> one for download? Is there anything going for the current behavior of
> offering the unsigned one instead?

Which signed one?
Some packages have multiple signed copies at the same time. 

koji also only knows them by their short hash of the key, not
'fedora-37' or something. 

Signed packages are cleaned up after some amount of time if they are not
in a tag requiring keeping them. 

So, I suppose the web interface could offer signed copies if they exist,
but might be confusing if you don't know what the various keys short
hash is. Feel free to file a RFE for koji folks: https://pagure.io/koji

kevin


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

Heads Up: hamlib 4.5 coming to Rawhide and f36+

[Richard Shaw]

Because hamlib is essentially a driver packaged as a library it is
desirable to have the latest version packages on all supported releases.
That being said, with the imminent release of f37 coming, I don't plan to
update f35.

The following packages will need to be rebuilt:
cqrlog
CubicSDR
direwolf
fldigi
freedv
gpredict
js8call
klog
qle
qsstv
soundmodem
tlf
tucnak
wsjtx
xlog

I already maintain most of these so coordination will be pretty
straightforward.

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: Karma for OpenSSL needed

[Otto Liljalaakso]

Vít Ondruch kirjoitti 2.11.2022 klo 16.18:


Dne 01. 11. 22 v 18:59 Fabio Valentini napsal(a):
On Tue, Nov 1, 2022 at 6:53 PM Demi Marie Obenour 
 wrote:


Please push them out to testing immediately.  Some, such as myself, 
simply

refuse to install unsigned packages.

The packages are already signed, no need to wait for them to be pushed
to testing.



Just FTR, this is the URL which can be obtained from Koji:

https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm

and this is the signed version:

https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/data/signed/5323552a/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm


Not sure if there is any better way to obtain the signed version early.


Would it be possible to update Koji's web UI so that it offers the 
signed one for download? Is there anything going for the current 
behavior of offering the unsigned one instead?

___
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: ELN build failures

[Sergey Mende]

Troy,

thanks a lot for clarification.

> I know copr *can* build for ELN, but it shouldn't be automatic.
It was not automatic, the ELN builds were enabled manually.

Kind regards,
Sergey
___
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: ELN build failures

[Troy Dawson]

On Wed, Nov 2, 2022 at 10:05 AM Sergey Mende  wrote:

> > On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson  wrote:
> > What package(s) are you having problems with?
> Troy,
>
> the package in question is libClipper2 [0] that undergoes the review
> presently. It is not go-related. It requires the Google Test that is
> unavailable in ELN. It is not really a goal to make it included into ELN:
> initially the ELN builds were enabled in COPR and then started to fail
> after unbundling Google Test. So, the question arose if there is a need or
> a way to mark a package as presently incompatible with a distribution apart
> from putting a plain comment into the spec.
>
> Thank you,
> Sergey
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=2130903
>

Lets take a step back.
Packages are only built for ELN if
1 - They are specifically requested by the RHEL teams to be in the next
RHEL release
or
2 - They are a direct runtime or build dependency of anything in (1)

If you are not expecting a new package to be in ELN, then it most likely
won't be.
Having a package build on ELN should not be part of a Fedora package review.
If it has become part of it, then we need to review the process.

I'm not sure why copr was building for ELN.
I know copr *can* build for ELN, but it shouldn't be automatic.

In short, don't worry about the failed copr ELN builds.
Just make sure your package builds and is packaged correctly for Fedora
Rawhide.

Troy
___
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: ELN build failures

[Stephen Gallagher]

On Wed, Nov 2, 2022 at 1:04 PM Sergey Mende  wrote:
>
> > On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson  > What package(s) are you having problems with?
> Troy,
>
> the package in question is libClipper2 [0] that undergoes the review 
> presently. It is not go-related. It requires the Google Test that is 
> unavailable in ELN. It is not really a goal to make it included into ELN: 
> initially the ELN builds were enabled in COPR and then started to fail after 
> unbundling Google Test. So, the question arose if there is a need or a way to 
> mark a package as presently incompatible with a distribution apart from 
> putting a plain comment into the spec.
>

There's no requirement for it to work in ELN unless known to be
replacing or supplementing something already in ELN. So don't worry
about it during code review.
___
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: Deprecating intents in Modularity

[Petr Šabata]

On Wed, Nov 2, 2022 at 5:04 PM Petr Pisar  wrote:
> Summing all these facts suggests that intents in Modularity are completely
> unused and their future won't be better. Therefore I'd like to deprecate
> intents in Modularity.
>
> What would it mean? The current YAML specification for module-defaults would
> warn that intents are deprecated. Any future tools or speciciations for
> modularity would not implement the intents.
>
> Does anybody have a problem with deprecating intents?

No, +1. As you note, this never became a thing and no one was really
interested in it.

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

Fedora CoreOS Meeting Minutes 2022-11-02

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-02/fedora_coreos_meeting.2022-11-02-16.29.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-02/fedora_coreos_meeting.2022-11-02-16.29.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-02/fedora_coreos_meeting.2022-11-02-16.29.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:29:39 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-02/fedora_coreos_meeting.2022-11-02-16.29.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:29:43)

* Action items from last meeting  (dustymabe, 16:33:12)
  * bgilbert addressed VMWare concerns in

https://github.com/coreos/fedora-coreos-tracker/issues/567#issuecomment-1294655290
(dustymabe, 16:34:05)

* Update OpenSSL for CVE-2022-3786 and CVE-2022-3602  (dustymabe,
  16:35:10)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1329
(dustymabe, 16:35:16)
  * the `testing` and `next` streams have a fix for the OpenSSL CVEs -
`stable` will roll out later today  (dustymabe, 16:35:53)

* Non-default OSTree deployments accessible without GRUB password
  (CVE-2022-3675)  (dustymabe, 16:37:22)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1333
(dustymabe, 16:37:28)
  * please see the announcement for more context on the nature of the
security issue and the release fix schedule:

https://discussion.fedoraproject.org/t/non-default-ostree-deployments-accessible-without-grub-password-cve-2022-3675/43715
(dustymabe, 16:48:24)

* open floor  (dustymabe, 16:51:47)
  * LINK:
https://github.com/openshift/os/issues/1036#issuecomment-1299168792
(jlebon, 16:54:21)

Meeting ended at 17:01:42 UTC.




Action Items






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




People Present (lines said)
---
* dustymabe (42)
* bgilbert (21)
* zodbot (20)
* jdoss (14)
* jlebon (11)
* fifofonix (3)
* walters (3)
* c4rt0 (2)
* jmarrero (2)
* jbrooks (1)
* gursewak (1)
* lucab (1)
* copperi[m] (1)
* spresti[m] (1)




Generated by `MeetBot`_ 0.4

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

Re: ELN build failures

[Sergey Mende]

> On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson  What package(s) are you having problems with?
Troy,

the package in question is libClipper2 [0] that undergoes the review presently. 
It is not go-related. It requires the Google Test that is unavailable in ELN. 
It is not really a goal to make it included into ELN: initially the ELN builds 
were enabled in COPR and then started to fail after unbundling Google Test. So, 
the question arose if there is a need or a way to mark a package as presently 
incompatible with a distribution apart from putting a plain comment into the 
spec.

Thank you,
Sergey  
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2130903
___
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

PSA: Rawhide KDE users, do not update

[Adam Williamson]

Hey, folks. Just a heads up: today's Rawhide has a new Qt which seems
to make SDDM crash on startup, so the system boots to a black screen
and you can't log in. So, updating may not be a great idea!

I've filed this as https://bugzilla.redhat.com/show_bug.cgi?id=2139465
and https://github.com/sddm/sddm/issues/1608 . Unfortunately haven't
been able to get a usable backtrace yet.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Fwd: Your message to devel@lists.fedoraproject.org awaits moderator approval

[Richard Shaw]

On Wed, Nov 2, 2022 at 10:33 AM Kevin Fenzi  wrote:

> On Wed, Nov 02, 2022 at 08:02:07AM -0500, Richard Shaw wrote:
> > U... Isn't it considered a good practice to CC maintainers of
> affected
> > packages? Should I have done it as BCC instead?
>
> You could do BCC instead, but then if there's some feedback that someone
> wants to send to everyone, you would have to resend to everyone.


While I wouldn't neglect direct communication anyway, perhaps BCC is better
because it's really just an, "FYI in case you miss the message in devel or
don't know your package is affected." Hopefully they respond on the devel
thread if more appropriate.



> Or you can just ignore the moderation message. I pass all these through
> moderation anyhow, it's just a slight delay.
>

Got ya. I wasn't sure if it was actively or occasionally monitored :)

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

Deprecating intents in Modularity

[Petr Pisar]

Hello module maintainers,

do you know intents
?
I believe you don't. Do you use intents? I hope you don't.

In modularity, default streams and default profiles can be parametrized by
a system role (purpose, variant, spin). Modularity calls it an "intent".

Theoretically, if you install Fedora Workstation and then install a postgresql
module, client libraries or tools for PostgreSQL could be installed. While
installing the same module on a Server spin would instead install PostgreSQL
server.

I write theoretically because Fedora has no way of signalling the intent
(fedora-release-* packages do not drop any configuration files; on RHEL one
uses subscription-manager for that purpose) and DNF does not implement
handling the intents at all.

I did a small survey and I was told that:

* DNF is not interrested in implementing this feature because there is no
established distribution-agnostic mechanism for setting and getting the
intents (even Fedora and RHEL differ).

* I was also told that Anaconda, a distribution installer, only interfaces
with intents through subscription-manager (RHEL-only thing) and that the
interface is clumsy.

* I was told that even RHEL, from version 9, does not use system purposes and
that it's quite possible that the interface will disappear from
subscription-manager.

* I also confirmed that module defaults in Fedora repositories do not utilize
the intents.

Summing all these facts suggests that intents in Modularity are completely
unused and their future won't be better. Therefore I'd like to deprecate
intents in Modularity.

What would it mean? The current YAML specification for module-defaults would
warn that intents are deprecated. Any future tools or speciciations for
modularity would not implement the intents.

Does anybody have a problem with deprecating intents?

-- Petr


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

[Bug 2139129] perl-HTML-Parser-3.80 is available

[bugzilla]

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



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

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=2139129
___
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: Fwd: Your message to devel@lists.fedoraproject.org awaits moderator approval

[Kevin Fenzi]

On Wed, Nov 02, 2022 at 08:02:07AM -0500, Richard Shaw wrote:
> U... Isn't it considered a good practice to CC maintainers of affected
> packages? Should I have done it as BCC instead?

You could do BCC instead, but then if there's some feedback that someone
wants to send to everyone, you would have to resend to everyone. 

Or you can just ignore the moderation message. I pass all these through
moderation anyhow, it's just a slight delay. 

kevin
--
> 
> -- Forwarded message -
> From: 
> Date: Wed, Nov 2, 2022 at 7:59 AM
> Subject: Your message to devel@lists.fedoraproject.org awaits moderator
> approval
> To: 
> 
> 
> Your mail to 'devel@lists.fedoraproject.org' with the subject
> 
> New OpenColorIO 2.2.0 requires yaml-cpp 0.7.0
> 
> Is being held until the list moderator can review it for approval.
> 
> The message is being held because:
> 
> Message has more than 10 recipients
> 
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.

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



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: ELN build failures

[Troy Dawson]

On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson  wrote:

> On Wed, Nov 2, 2022 at 6:42 AM Stephen Gallagher 
> wrote:
>
>>
>>
>> On Wed, Nov 2, 2022 at 12:26 AM Benson Muite 
>> wrote:
>>
>>> If there is a build failure for a package on ELN, does anything need to
>>> be added to a package spec file?  Currently
>>
>>
>> It varies wildly from package to package. Sometimes things can be handled
>> with a spec file conditional, other times it may be more complicated (like
>> the compiler flags for RHEL are revealing a coding bug that the Fedora
>> flags happen to miss or optimize out).
>>
>>
>>
>> reviewing a package where
>>> there is a missing dependency, but helpful to also
>>
>>
>> A new package review shouldn’t be expected to build on ELN, and failing
>> to do so shouldn’t block the review, in general. (Exception: a new package
>> that is Obsoleting a package currently in ELN might need special handling).
>>
>> know if anything
>>> should be done in general. The documentation at [0] is not clear on
>>> this.  Unclear also if ExcludeArch: ELN with a comment for the reason
>>> for build failures on ELN would be a useful thing to have in new spec
>>> files.
>>
>>
>> ELN is not an arch, so that would have no effect whatsoever. ELN already
>> only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages.
>> See https://tiny.distro.builders for the list.
>>
>
> Stephen is correct, ELN is not an arch, but there are some packages that
> do not build on all arches of ELN but do in rawhide.
> The biggest one is golang.
>
>
I should have put this in the email.
If your package needs any golang package to build you should put in

ExclusiveArch:  %{golang_arches}


What package(s) are you having problems with?
>
> Troy
>
>
___
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: ELN build failures

[Troy Dawson]

On Wed, Nov 2, 2022 at 6:42 AM Stephen Gallagher 
wrote:

>
>
> On Wed, Nov 2, 2022 at 12:26 AM Benson Muite 
> wrote:
>
>> If there is a build failure for a package on ELN, does anything need to
>> be added to a package spec file?  Currently
>
>
> It varies wildly from package to package. Sometimes things can be handled
> with a spec file conditional, other times it may be more complicated (like
> the compiler flags for RHEL are revealing a coding bug that the Fedora
> flags happen to miss or optimize out).
>
>
>
> reviewing a package where
>> there is a missing dependency, but helpful to also
>
>
> A new package review shouldn’t be expected to build on ELN, and failing to
> do so shouldn’t block the review, in general. (Exception: a new package
> that is Obsoleting a package currently in ELN might need special handling).
>
> know if anything
>> should be done in general. The documentation at [0] is not clear on
>> this.  Unclear also if ExcludeArch: ELN with a comment for the reason
>> for build failures on ELN would be a useful thing to have in new spec
>> files.
>
>
> ELN is not an arch, so that would have no effect whatsoever. ELN already
> only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages.
> See https://tiny.distro.builders for the list.
>

Stephen is correct, ELN is not an arch, but there are some packages that do
not build on all arches of ELN but do in rawhide.
The biggest one is golang.

What package(s) are you having problems with?

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

[Miro Hrončok]

On 02. 11. 22 13:58, Jens-Ulrik Petersen wrote:
On Mon, Oct 31, 2022 at 8:39 PM Miro Hrončok > wrote:


llvm11.0                          orphan, tstellar                 3 weeks 
ago


Let's retire it right away in that case?

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

[Bug 2139129] perl-HTML-Parser-3.80 is available

[bugzilla]

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



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

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=2139129
___
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

New OpenColorIO 2.2.0 requires yaml-cpp 0.7.0

[Richard Shaw]

I have added the OCIO new version BZ# as a blocker to the yaml-cpp new
version BZ# and added NEEDINFO from the maintainer. That being said the bug
has been open since 2021 so I'll give it a couple of days, after which I
plan to update yaml-cpp myself.

The following packages will need to be rebuilt:
calamares
cantera
daggy
dcm2niix
librime
libzypp
mir
OpenColorIO
opencolorio1
pdns
qt-creator
rstudio
supercollider
thinkfan
vfrnav
workspace

As usual, all builds will be done in a side tag. Dependent maintainers,
please let me know if I should hold off if you have updates in the works.

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: systemd 252 feature: SUPPORT_END in /etc/os-release

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 01, 2022 at 04:15:03PM -0700, Stewart Smith via devel wrote:
> Matthew Miller  writes:
> > See:  
> > https://lists.freedesktop.org/archives/systemd-devel/2022-October/048519.html
> >
> >Systemd will set the taint flag 'support-ended' if it detects that
> >the OS image is past its end-of-support date. This date is declared
> >in a new /etc/os-release field SUPPORT_END= described below.
> >
> >[...]
> >
> >os-release gained a new field SUPPORT_END=-MM-DD to inform the user
> >when their system will become unsupported.
> >
> >
> > Should we set this? I kind of think we should.
> 
> Yes!
> 
> We have started to set it in Amazon Linux 2022, and likely will at some
> point do so in prior versions as well (even though they all use older
> than 252 versions of systemd).

Hi,

I'm happy to hear that you're already making use of this ;)

Just to reply to the part about older releases: I think it'd be totally
fine to add the metadata to an older release in an update. The tooling
to actually make use of this information may even be external (e.g. something
looking _into_ a container or some other image), and may make use of without
the system _in_ the release caring about the field.

> This is very much so we can get as much information as possible into
> machine readable formats for security tooling to be able to read.
> 
> > I would suggest we set it to the expected EOL based on the nominal schedule.
> > We could either release updates to extend it if we slip... or... just not do
> > that.
> 
> The update is a rather small and unobtrusive one, and in our experience
> of doing updates to our system-release package (equivalent of
> fedora-release), we've managed to not cause any negative customer issues
> with modifications to it that weren't functional in some way
> (e.g. switching default repository setup to https endpoints rather than http)

+1

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

[rpms/perl-Text-Soundex] PR #1: Package tests

[Michal Josef Špaček]

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

Merged pull-request:

``
Package tests
``

https://src.fedoraproject.org/rpms/perl-Text-Soundex/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: Karma for OpenSSL needed

[Vít Ondruch]

Dne 01. 11. 22 v 18:59 Fabio Valentini napsal(a):

On Tue, Nov 1, 2022 at 6:53 PM Demi Marie Obenour  wrote:


Please push them out to testing immediately.  Some, such as myself, simply
refuse to install unsigned packages.

The packages are already signed, no need to wait for them to be pushed
to testing.



Just FTR, this is the URL which can be obtained from Koji:

https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm

and this is the signed version:

https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/data/signed/5323552a/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm


Not sure if there is any better way to obtain the signed version early.


Vít



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: ELN build failures

[Stephen Gallagher]

On Wed, Nov 2, 2022 at 12:26 AM Benson Muite 
wrote:

> If there is a build failure for a package on ELN, does anything need to
> be added to a package spec file?  Currently


It varies wildly from package to package. Sometimes things can be handled
with a spec file conditional, other times it may be more complicated (like
the compiler flags for RHEL are revealing a coding bug that the Fedora
flags happen to miss or optimize out).



reviewing a package where
> there is a missing dependency, but helpful to also


A new package review shouldn’t be expected to build on ELN, and failing to
do so shouldn’t block the review, in general. (Exception: a new package
that is Obsoleting a package currently in ELN might need special handling).

know if anything
> should be done in general. The documentation at [0] is not clear on
> this.  Unclear also if ExcludeArch: ELN with a comment for the reason
> for build failures on ELN would be a useful thing to have in new spec
> files.


ELN is not an arch, so that would have no effect whatsoever. ELN already
only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages.
See https://tiny.distro.builders for the list.



>
> 0) https://docs.fedoraproject.org/en-US/eln/ftbfs/
> ___
> 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

Non-responsive maintainer check for package ModemManager

[Tao J]

This is an accompanying mail for [0] in accordance with "Non-responsive 
maintainer policy"

ModemManager[1] has some abrt issues [2][3][4][5] and also need a version 
bump[6][7] to support new hardware.

A PR was sent about two months ago and no action from the maintainer. For the 
past two years, "Peter Robinson" is the sole committer to this package, while 
listed 4 maintainers has no commits.

To fix both problem A bump to version >= 1.18.12 is suggested. [8]
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=2137444
[1]: https://src.fedoraproject.org/rpms/ModemManager
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2139298
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=2139291
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=2139279
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=2129461
[6]: 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/806
[7]: https://bugzilla.redhat.com/show_bug.cgi?id=2134227
[8]: 
https://lists.freedesktop.org/archives/modemmanager-devel/2022-September/009419.html
___
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 2139129] perl-HTML-Parser-3.80 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-7ce8befa29 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-2022-7ce8befa29`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-7ce8befa29

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=2139129
___
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: systemd 252 feature: SUPPORT_END in /etc/os-release

[Luna Jernberg]

Nice new feature, i think it should be set

On 11/2/22, Ben Cotton  wrote:
> Cosign. We'd definitely want to set it to the "EOL date if we hit the
> early target" so that way we're never EOL less than we say. I do like
> the idea of updating it when the EOL date moves out, but if that gets
> forgotten it's not a big deal.
>
> I'm happy to make this the Fedora Program Manager's responsibility,
> but if RelEng wants to own that, that's fine too. In fact, if it
> doesn't cause RelEng to break into a cold sweat, I'd be happy to be
> added as a maintainer to make the updates directly. Otherwise, I'll
> file PRs and pester until they're merged. :-)
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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 2139414] New: perl-Dancer-1.3513-14.fc38 FTBFS: Devel::Hide hides Clone.pm; Can't locate Clone.pm at /usr/share/perl5/vendor_perl/HTTP/Headers.pm line 8.

[bugzilla]

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

Bug ID: 2139414
   Summary: perl-Dancer-1.3513-14.fc38 FTBFS: Devel::Hide hides
Clone.pm; Can't locate Clone.pm at
/usr/share/perl5/vendor_perl/HTTP/Headers.pm line 8.
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dancer
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2117176 (F38FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Dancer-1.3513-14.fc38 fails to build in Fedora 38 because a test fails:

t/12_response/10_error_dumper.t . ok
Devel::Hide hides Clone.pm
Can't locate Clone.pm in @INC (hidden)
BEGIN failed--compilation aborted at
/usr/share/perl5/vendor_perl/HTTP/Headers.pm line 8.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Response.pm line 14.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Response.pm line 14.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/SharedData.pm line 8.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/SharedData.pm line 8.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Request.pm line 13.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Request.pm line 13.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Route.pm line 13.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Route.pm line 13.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Route/Registry.pm line 8.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/Route/Registry.pm line 8.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/App.pm line 12.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer/App.pm line 12.
Compilation failed in require at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer.pm line 10.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/Dancer-1.3513/blib/lib/Dancer.pm line 10.
Compilation failed in require at t/12_response/10_error_dumper_without_clone.t
line 17.
BEGIN failed--compilation aborted at
t/12_response/10_error_dumper_without_clone.t line 17.
t/12_response/10_error_dumper_without_clone.t ... 
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 
[...]
Test Summary Report
---
t/12_response/10_error_dumper_without_clone.t (Wstat: 65280 (exited 255)
Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=222, Tests=2158, 42 wallclock secs ( 0.58 usr  0.31 sys + 32.74 cusr 
7.10 csys = 40.73 CPU)
Result: FAIL

A difference between passing and failing build roots is at
. This failure is probably
triggered by upgrading perl-HTTP-Message from 6.43-2.fc38 to 6.44-1.fc38.
HTTP-Message-6.44 added a dependency on Clone, from Changes:

Made the Clone module a hard requirement, so we don't have to provide a
fallback function for HTTP::Headers::clone(). We require at least Clone 0.46,
as that release now supports Perl back to 5.8.1, just like us. (GH#184) (Neil
Bowers)

while the Dancer test exhibits hiding Clone module.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2117176
[Bug 2117176] Fedora 38 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139414
___
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

Fwd: Your message to devel@lists.fedoraproject.org awaits moderator approval

[Richard Shaw]

U... Isn't it considered a good practice to CC maintainers of affected
packages? Should I have done it as BCC instead?

-- Forwarded message -
From: 
Date: Wed, Nov 2, 2022 at 7:59 AM
Subject: Your message to devel@lists.fedoraproject.org awaits moderator
approval
To: 


Your mail to 'devel@lists.fedoraproject.org' with the subject

New OpenColorIO 2.2.0 requires yaml-cpp 0.7.0

Is being held until the list moderator can review it for approval.

The message is being held because:

Message has more than 10 recipients

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.
___
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

[Jens-Ulrik Petersen]

On Mon, Oct 31, 2022 at 8:39 PM Miro Hrončok  wrote:

> llvm11.0  orphan, tstellar 3 weeks
> ago
>

(Just noting that llvm11.0 should indeed be retired as it's an unwanted
duplicate of the Fedora llvm11 package.)
___
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 37 compose report: 20221102.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20221101.n.0
NEW: Fedora-37-20221102.n.0

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

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   31.41 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -7.02 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-37-20221101.n.0.s390x.qcow2

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  libksba-1.6.2-1.fc37
Old package:  libksba-1.6.1-1.fc37
Summary:  CMS and X.509 library
RPMs: libksba libksba-devel
Size: 1005.97 KiB
Size change:  726 B
Changelog:
  * Fri Oct 07 2022 Jakub Jelen  - 1.6.2-1
  - New upstream release (#2132953)


Package:  openssl-1:3.0.5-3.fc37
Old package:  openssl-1:3.0.5-2.fc37
Summary:  Utilities from the general purpose cryptography library with TLS 
implementation
RPMs: openssl openssl-devel openssl-libs openssl-perl
Size: 30.42 MiB
Size change:  -7.73 KiB
Changelog:
  * Tue Nov 01 2022 Dmitry Belyavskiy  - 1:3.0.5-3
  - CVE-2022-3602: X.509 Email Address Buffer Overflow
  - CVE-2022-3786: X.509 Email Address Buffer Overflow
Resolves: CVE-2022-3602
Resolves: CVE-2022-3786



= DOWNGRADED PACKAGES =
___
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-Text-Soundex] PR #1: Package tests

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Text-Soundex` that 
you are following:
``
Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Text-Soundex/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

Fedora rawhide compose report: 20221102.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221101.n.0
NEW: Fedora-Rawhide-20221102.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  12
Dropped packages:1
Upgraded packages:   250
Downgraded packages: 1

Size of added packages:  52.24 MiB
Size of dropped packages:161.06 KiB
Size of upgraded packages:   8.19 GiB
Size of downgraded packages: 477.38 KiB

Size change of upgraded packages:   -65.74 MiB
Size change of downgraded packages: 17.97 KiB

= ADDED IMAGES =
Image: Server_KVM qcow2 ppc64le
Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20221102.n.0.ppc64le.qcow2

= DROPPED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20221101.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: crosswords-0.3.5-2.fc38
Summary: Solve crossword puzzles
RPMs:crossword-editor crosswords crosswords-doc 
crosswords-puzzle-sets-cats-and-dogs crosswords-puzzle-sets-uri ipuz-convertor
Size:42.53 MiB

Package: lunchbox-1.17.0-6.fc38
Summary: C++ library for multi-threaded programming
RPMs:lunchbox lunchbox-devel
Size:1.28 MiB

Package: mingw-python-build-0.9.0-1.fc38
Summary: MinGW Python build library
RPMs:mingw32-python3-build mingw64-python3-build
Size:119.10 KiB

Package: mingw-python-flit-core-3.7.1-2.fc38
Summary: MinGW Python flit_core library
RPMs:mingw32-python3-flit-core mingw64-python3-flit-core
Size:212.35 KiB

Package: mingw-python-installer-0.5.1-2.fc38
Summary: MinGW Windows Python installer library
RPMs:mingw32-python3-installer mingw64-python3-installer
Size:549.83 KiB

Package: mingw-python-pep517-0.13.0-4.fc38~bootstrap
Summary: MinGW Windows Python pep517 library
RPMs:mingw32-python3-pep517 mingw64-python3-pep517
Size:55.92 KiB

Package: mingw-python-pip-22.2.2-3.fc38
Summary: MinGW Windows Python pip library
RPMs:mingw32-python3-pip mingw64-python3-pip
Size:6.84 MiB

Package: mingw-python-wheel-0.37.1-2.fc38
Summary: MinGW Windows Python wheel library
RPMs:mingw32-python3-wheel mingw64-python3-wheel
Size:234.36 KiB

Package: mrack-1.10.0-1.fc38
Summary: Multicloud use-case based multihost async provisioner
RPMs:mrack mrack-cli python3-mrack-aws python3-mrack-beaker 
python3-mrack-openstack python3-mrack-podman python3-mrack-virt python3-mracklib
Size:301.62 KiB

Package: python-dunamai-1.13.2-3.fc38
Summary: Dynamic version generation
RPMs:python3-dunamai
Size:59.20 KiB

Package: python-rust-update-set-0.0.1-1.fc38
Summary: A tool to help Fedora packagers update Rust packages
RPMs:rust-update-set
Size:77.87 KiB

Package: rust-schemafy_core-0.6.0-1.fc38
Summary: Generates serializeable Rust types from a json schema
RPMs:rust-schemafy_core+default-devel rust-schemafy_core-devel
Size:18.06 KiB


= DROPPED PACKAGES =
Package: mingw-python-setuptools_scm-6.4.2-2.fc37
Summary: MinGW Windows Python setuptools_scm library
RPMs:mingw32-python3-setuptools_scm mingw64-python3-setuptools_scm
Size:161.06 KiB


= UPGRADED PACKAGES =
Package:  CalcMySky-0.2.1-1.fc38
Old package:  CalcMySky-0.1.0-2.fc38
Summary:  Simulator of light scattering by planetary atmospheres
RPMs: CalcMySky CalcMySky-devel
Size: 8.12 MiB
Size change:  7.28 KiB
Changelog:
  * Tue Nov 01 2022 Gwyn Ciesla  - 0.2.1-1
  - 0.2.1


Package:  GeographicLib-2.1.1-2.fc38
Old package:  GeographicLib-2.1.1-1.fc37
Summary:  Library for geographic coordinate transformations
RPMs: GeographicLib GeographicLib-devel GeographicLib-doc 
mingw32-GeographicLib mingw32-python3-GeographicLib mingw64-GeographicLib 
mingw64-python3-GeographicLib python3-GeographicLib
Size: 3.74 MiB
Size change:  30.58 KiB
Changelog:
  * Wed Oct 19 2022 Sandro Mani  - 2.1.1-2
  - Switch to python3-build


Package:  WALinuxAgent-2.8.0.11-1.fc38
Old package:  WALinuxAgent-2.7.3.0-1.fc37
Summary:  The Microsoft Azure Linux Agent
RPMs: WALinuxAgent WALinuxAgent-udev
Size: 723.59 KiB
Size change:  15.22 KiB
Changelog:
  * Tue Oct 18 2022 Chris Patterson  - 2.7.3.0-2
  - Add ConditionVirtualization=|microsoft triggering condition

  * Mon Oct 31 2022 Vitaly Kuznetsov  - 2.8.0.11-1
  - Update to 2.8.0.11 (#2128547)


Package:  asahi-scripts-20221027-4.fc38
Old package:  asahi-scripts-20221027-2.fc38
Summary:  Miscellaneous admin scripts for Asahi Linux
RPMs: asahi-fwextract asahi-scripts dracut-asahi linux-firmware-vendor 
update-m1n1
Added RPMs:   linux-firmware-vendor
Size: 52.13 KiB
Size change:  9.98 KiB
Changelog:
  * Tue Nov 01 2022 Davide Cavalca  20221027-3
  - Add linux-firmware-vendor subpackage

  * Tue Nov 01 2022 Davide Cavalca  20221027-4
  - Refresh PR#9 patch


Package:  astrometry-0.91-1.fc38
Old package:  astrometry-0.89-4.fc38
Summary:  Blind astrometric calibration of arbitrary astronomical images
RPMs: astrometry astrometry-data

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

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

  Flags|requires_doc_text?  |needinfo?(g...@zimt.uni-siege
   ||n.de)



--- Comment #2 from Petr Pisar  ---
Gerd, if you don't have time to maintain perl-Pegex in EPEL9, can you give
somebody (salimma, ppisar, epel-packagers-sig group) the permission at
?


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

Re: Advice on packaging Python with Rust dependency

[Ondrej Pohorelsky]

The missing dependency is pkg-version[0]. It seems like its only outside
dependency is already packaged[1] in Fedora.

It would be great if you could package it. If not, I'll look into it.


[0]https://docs.rs/pkg-version/latest/pkg_version/index.html
[1]https://src.fedoraproject.org/rpms/rust-proc-macro-hack

On Wed, Nov 2, 2022 at 11:24 AM Fabio Valentini 
wrote:

> On Wed, Nov 2, 2022 at 11:11 AM Miro Hrončok  wrote:
> >
> > On 02. 11. 22 10:48, Ondrej Pohorelsky wrote:
> > > Thanks, that did the trick!
>
> I concur.
> With setuptools_rust, you're pretty much already set up, just look at
> whatever python-cryptography is doing.
>
> Sadly the other popular build tool for Rusty Python packages (maturin)
> will take a while to get packaged for Fedora ...
>
> > > The only problem is, that one of the other dependencies which I
> haven't caught
> > > before is not packaged in Fedora.
> > > So I guess there is no other way than vendor all dependencies or
> package the
> > > missing dependency myself.
> >
> > Let's package it. The Rust SIG will usually help co-maintain it.
>
> Yes. Option 3: Ask a member of the Rust SIG to help you.
> You don't need to be an expert Rust packager just because one of your
> projects starts to include / depend on Rust code.
> If you actually post the name of the crate that's missing from Fedora,
> I will look into packaging it for you.
>
> 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
>


-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

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

Re: Advice on packaging Python with Rust dependency

[Richard W.M. Jones]

On Wed, Nov 02, 2022 at 10:48:27AM +0100, Ondrej Pohorelsky wrote:
> Thanks, that did the trick!
> 
> The only problem is, that one of the other dependencies which I haven't caught
> before is not packaged in Fedora.
> So I guess there is no other way than vendor all dependencies or package the
> missing dependency myself.

See how memfd is bundled here:

http://oirase.annexia.org/reviews/libblkio/libblkio.spec

(This is a package under review, not actually in Fedora yet, but the
principle is the same).

Note the vendor tarball which just contains the single missing
package, the "Provides: bundled..." line, and the update to Cargo.toml
so that cargo will use the bundled package and not try to download it.

You should also create a BZ to get the missing rust package added to
Fedora long term.  We are working on that for memfd too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: Advice on packaging Python with Rust dependency

[Fabio Valentini]

On Wed, Nov 2, 2022 at 11:11 AM Miro Hrončok  wrote:
>
> On 02. 11. 22 10:48, Ondrej Pohorelsky wrote:
> > Thanks, that did the trick!

I concur.
With setuptools_rust, you're pretty much already set up, just look at
whatever python-cryptography is doing.

Sadly the other popular build tool for Rusty Python packages (maturin)
will take a while to get packaged for Fedora ...

> > The only problem is, that one of the other dependencies which I haven't 
> > caught
> > before is not packaged in Fedora.
> > So I guess there is no other way than vendor all dependencies or package the
> > missing dependency myself.
>
> Let's package it. The Rust SIG will usually help co-maintain it.

Yes. Option 3: Ask a member of the Rust SIG to help you.
You don't need to be an expert Rust packager just because one of your
projects starts to include / depend on Rust code.
If you actually post the name of the crate that's missing from Fedora,
I will look into packaging it for you.

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

Re: Advice on packaging Python with Rust dependency

[Miro Hrončok]

On 02. 11. 22 10:48, Ondrej Pohorelsky wrote:

Thanks, that did the trick!

The only problem is, that one of the other dependencies which I haven't caught 
before is not packaged in Fedora.
So I guess there is no other way than vendor all dependencies or package the 
missing dependency myself.


Let's package it. The Rust SIG will usually help co-maintain it.

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

Re: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Florian Weimer]

* Demi Marie Obenour:

> On 11/2/22 02:56, Florian Weimer wrote:
>> * Benson Muite:
>> 
>>> On 11/1/22 06:35, Orion Poplawski wrote:
 While poking at building openmpi with clang, I started wondering
 about flang and some things:
 * Should %set_build_flags set FC?  I think it should since it sets
 FCFLAGS.
 * Is flang-new even worth bothering with?  See the following
 configure check:
>> 
>>> Yes, this will be helpful.  Significant work has gone into optimizing
>>> this for A64FX
>> 
>> Fedora does not run well on A64FX because we enable PAC+BTI, adding
>> significant overhead to most function calls.
>
> How is this specific to A64FX?

It just is?  I'm not aware of any other AArch64 CPUs that are impacted
in the same way.

Maybe I don't understand the question.

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: Advice on packaging Python with Rust dependency

[Ondrej Pohorelsky]

Thanks, that did the trick!

The only problem is, that one of the other dependencies which I haven't
caught before is not packaged in Fedora.
So I guess there is no other way than vendor all dependencies or package
the missing dependency myself.

On Tue, Nov 1, 2022 at 2:41 PM Miro Hrončok  wrote:

> On 01. 11. 22 14:01, Ondrej Pohorelsky wrote:
> > Hi,
> >
> > I'm a package maintainer of Breezy [0] in Fedora.
> >
> > Recently in the newest version (3.3.0), which I'm trying to update to,
> upstream
> > started requiring python-setuptools-rust as a BuildRequire,
> > because they are shipping rio-py package [1]. This is a simple rust
> input
> > output library, which requires Rust crate lazy_static.
> > This is where build fails every time, because build_rust wants to update
> > crates.io , which then tries to connect to the
> github.com
> > ,
> > which is prohibited on Fedora builders.
> >
> > I looked through fedora-devel threads and I found a thread[2],
> discussing a
> > similar issue with a C package, where it was suggested to
> > vendor the Rust dependencies. I don't think this is a good solution for
> Breezy,
> > as calling `cargo vendor` creates a folder about 120 MB big.
> > This is more than three times the standard package.
> >
> > Fortunately, we have the lazy_static dependency already packaged in
> Fedora[3],
> > which would resolve the issue.
> > The question is, how can I feed this package to build_rust, so it does
> not want
> > to connect to the internet and crash the build all the time?
> > Is this even possible, or is there a better solution?
>
> Have a look at python-cryptography.
>
> It has some fedora/RHEL conditionals in the spec thta show two approaches
> of
> how it can be done.
>
> Not sure if it will work with breezy exactly as it is there, but it should
> give
> you some hints.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

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

Re: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Demi Marie Obenour]

On 11/2/22 02:56, Florian Weimer wrote:
> * Benson Muite:
> 
>> On 11/1/22 06:35, Orion Poplawski wrote:
>>> While poking at building openmpi with clang, I started wondering
>>> about flang and some things:
>>> * Should %set_build_flags set FC?  I think it should since it sets
>>> FCFLAGS.
>>> * Is flang-new even worth bothering with?  See the following
>>> configure check:
> 
>> Yes, this will be helpful.  Significant work has gone into optimizing
>> this for A64FX
> 
> Fedora does not run well on A64FX because we enable PAC+BTI, adding
> significant overhead to most function calls.

How is this specific to A64FX?
-- 
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

[Bug 2139129] perl-HTML-Parser-3.80 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-14a0eb2643 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-14a0eb2643


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139129
___
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 2139129] perl-HTML-Parser-3.80 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-7ce8befa29 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-7ce8befa29


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139129
___
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 2139129] perl-HTML-Parser-3.80 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-HTML-Parser-3.80-1.fc3
   ||8




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139129
___
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-HTML-Parser] PR #7: 3.80 bump

[Jitka Plesnikova]

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

Merged pull-request:

``
3.80 bump
``

https://src.fedoraproject.org/rpms/perl-HTML-Parser/pull-request/7
___
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-HTML-Parser] PR #7: 3.80 bump

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-HTML-Parser` that 
you are following:
``
3.80 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTML-Parser/pull-request/7
___
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

Silent changes in Packaging Guidelines

[Petr Pisar]

It used to be a good practice to announce changes in Packaging Guidelines
 here on this
list. The forkflow was that Fedora Packaging Committee accepted a change on
it's meeting and then announced it in their meeting notes posted here. This
workflow allowed packagers to notice the changes and apply them to their
packages.

However, this is not true anomore. E.g. In February a ban for wildcard %files
was augmented from dynamic libraries to all top-level files
:

commit 2bc90a6463ae591ed134955485da0596c2fe958b
Author: Carl George 
Date:   Wed Feb 2 18:52:03 2022 -0600

Adapt Python's explicit lists guidance to the main guidelines

diff --git a/guidelines/modules/ROOT/pages/index.adoc 
b/guidelines/modules/ROOT/pages/index.adoc
index 2bb4f9e..5ec0896 100644
--- a/guidelines/modules/ROOT/pages/index.adoc
+++ b/guidelines/modules/ROOT/pages/index.adoc
@@ -2574,6 +2574,27 @@ The %defattr directive in the %files list
 SHOULD ONLY be used when setting a non-default value,
 or to reset to the default value after having set a non-default value.

+=== Explicit lists
+
+Packagers *SHOULD NOT* simply glob everything under a shared directory.
+
+In particular, the following *SHOULD NOT* be used in `+%files+`:
+
+* `+%{_bindir}/*+`
+* `+%{_datadir}/*+`
+* `+%{_includedir}/*+`
+* `+%{_mandir}/*+`
+* `+%{_docdir}/*+`

To my surprise the first time when I get known to this new rule was today
in a review of my new package.

It could be that my memory failed. So I checked FPC and found these two
relevant issues:




Which do not contain any description or summary. Simply bunch of "+1"
comments. Then I searched a February archive of this list and found these
three FPC posts:

Schedule for Thursday's FPC Meeting (2022-02-03 17:00 UTC)

Schedule for Thursday's FPC Meeting (2022-02-10 17:00 UTC)

Schedule for Thursday's FPC Meeting (2022-02-17 17:00 UTC)


None of them mentions this change.


Could we please resume announcing substantial changes in the guidelines on
this mailing list?

-- Petr


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

Re: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Florian Weimer]

* Benson Muite:

> On 11/1/22 06:35, Orion Poplawski wrote:
>> While poking at building openmpi with clang, I started wondering
>> about flang and some things:
>> * Should %set_build_flags set FC?  I think it should since it sets
>> FCFLAGS.
>> * Is flang-new even worth bothering with?  See the following
>> configure check:

> Yes, this will be helpful.  Significant work has gone into optimizing
> this for A64FX

Fedora does not run well on A64FX because we enable PAC+BTI, adding
significant overhead to most function calls.

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: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Florian Weimer]

* Orion Poplawski:

> While poking at building openmpi with clang, I started wondering about
> flang and some things:
>
> * Should %set_build_flags set FC?  I think it should since it sets FCFLAGS.

I see that FC is actually documented for GNU Make, so it makes sense if
we want to go in that direction.

> * Is flang-new even worth bothering with?  See the following configure
>   check:
>
> configure:32655: flang-new -c -O2 -flto -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS --config
>  /usr/lib/rpm/redhat/redhat-hardened-clang.cfg
> -fstack-protector-strong -m64  -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -I/usr/lib64/gfortran/modules conftest.F >&5
> flang-new: warning: argument unused during compilation: '-fexceptions'
> flang-new: warning: argument unused during compilation: '-g'
> flang-new: warning: argument unused during compilation:
> '-grecord-command-line'
> flang-new: warning: argument unused during compilation: '-Wall'
> flang-new: warning: argument unused during compilation:
> '-Wp,-D_FORTIFY_SOURCE=2'
> flang-new: warning: argument unused during compilation:
> '-Wp,-D_GLIBCXX_ASSERTIONS'
> flang-new: warning: argument unused during compilation:
> '-fstack-protector-strong'
> flang-new: warning: argument unused during compilation: '-mtune=generic'
> flang-new: warning: argument unused during compilation:
> '-fasynchronous-unwind-tables'
> flang-new: warning: argument unused during compilation:
> '-fstack-clash-protection'
> flang-new: warning: argument unused during compilation:
> '-fcf-protection=full'
> error: Only `-Werror` is supported currently.
>
> Of particular note is ignoring the '-g' option.

I can't find documentation on the supported options, and --help is not
particularly illuminating.  Maybe flang-new follows the option syntax of
some other Fortran compiler and not gfortran?

> I started poking at implementing this in redhat-rpm-config, but it
> seems pretty tricky as for the most part we seem to assume that every
> compiler can accept the same set of flags.
>
> This also bites us if we try to use gfortran with clang as I end up
> with it trying to use the clang config.

Yes, if we enable flang, gfortran will not be able to use those flags.
Alternatively we can treat Fortran like Go and not control the compiler
by toolchain settings.

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: c99-port branches in dist-git

[Florian Weimer]

* Fabio Valentini:

>> It wasn't intended to use COPR originally, it's just that Fedora releng
>> ignored my request for close to a year.
>>
>> I filed  for the branch removals.
>>
>> I must say this is quite confusing.  Why offer self-service branch
>> creation at all if we aren't supposed to use it in general?
>>
>> What's the recommended way to collaborate with packages/provenpackagers?
>> Someone's personal fork on src.fedoraproject.org with a branch with a
>> wide-open ACL?
>
> Either that (provenpackagers can already push to forks on src.fp.o),
> or just push fixes to the rawhide branch directly?

This was for the infrastructure support, i.e. given maintainers a
compiler & buildroot with which they can validate their fixes.  These
changes cannot be pushed to rawhide because we do not want to change the
compiler defaults there.

The individual package fixes can go into rawhide for sure.

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