Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 05/12/2022 16:00, Jarek Prokop wrote:



On 12/5/22 14:57, Peter Robinson wrote:

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
  wrote:

On 05/12/2022 12:39, Terry Barnaby wrote:

I am wondering what Fedora's policy is on depreciated old shared
libraries and particularly compat RPM's ?

Fedora is a bleeding edge distribution. If you need old versions, you
should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
gnome-boxes, and probably others I forgot).
There shouldn't be a problem spinning up a graphical environment of 
CentOS 7, getting EPEL and then using the tool.


Maybe the tool would work using the `toolbox` utility using last known 
good Fedora version for the tool.

That is just my wild guess however.

This is sometimes the tax for being "too" modern.
If the vendor does not want to support Fedora, we can't be held 
accountable to fully support their solution.
Does the software work? Yes? That is great! If not, well… we can't do 
much without the source code under nice FOSS license, can we.


Regards,
Jarek

Although yes, there are things like VM's, containers etc. which we use 
for old development environments all of these are, IMO, clumsy and 
awkward to use and difficult to manage especially within automated build 
environments that build the complete code for an embedded system with 
various CPU's, FPGA's, other tools etc.


I know Fedora is fairly bleeding edge (really too bleeding edge for our 
uses, but others are too far behind), but there is obviously going to be 
a balance here so that Fedora is still useful to as many people as 
reasonably possible, hence the question on a policy.


In the particular case I am talking about, libncurses*5.so, this is a 
fairly common shared library used by quite a few command line tools. A 
lot of external/commercial programs are built on/for Redhat7 as it is a 
de-facto base Linux platform and programs built on it will likely work 
on many other Linux systems. These companies are not going to build for 
a version of Fedora, it changes far to fast and would require large 
amounts or development/support work because of this. Some of the tools I 
am using were built/shipped in Feburary 2022, so we are not talking 
about old tools here.


My view is that compat versions of the commonly used shared libraries 
for programs that are used on Redhat7 should be kept available until 
most people are not producing programs for that system at least +nyears 
and then I guess Redhat8 once that really becomes a core base platform 
that external people use. A core list of these (there are only a few) 
could be kept somewhere and when one is to be depreciated, or users see 
problems when Fedora is updated,  a decision on this can be then made 
with that info. This would keep the Fedora system relevant for more 
users needs without too much work. In the case of ncurses, it is really 
just putting back into the SPEC file that which was removed for F37 plus 
the extra storage on mirrors for the compat RPM's.





___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.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 2151095] perl-Perl-Critic-1.144 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Scratch build failed. Details below:

GenericError: File upload failed:
cli-build/1670308203.786443.IBDzJEag/perl-Perl-Critic-1.144-1.fc36.src.rpm
Traceback:
  File
"/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
  File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3083, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
  File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3018, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))

If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues


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

[bugzilla]

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

Bug ID: 2151095
   Summary: perl-Perl-Critic-1.144 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Perl-Critic
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, mspa...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.144
Upstream release that is considered latest: 1.144
Current version/release in rawhide: 1.142-1.fc38
URL: http://search.cpan.org/dist/Perl-Critic/

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


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


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

[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators

[Maxwell G via epel-devel]

On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
> Could be the following file added to the package epel-rpm-macros (or 
> anything like this) for EPEL 9?

It could, but it might be better to include this in a subpackage of
epel-rpm-macros or as a separate perl-generators-epel component. We
could pull it in with (package-name-here if perl-generators). This won't
work in EPEL 7 which unfortunately doesn't support rich dependencies.

> But I don't know how to do it for EPEL 7/8, because the above file 
> doesn't work.
> It ends with error [2]:
> error: Couldn't exec perl-libs: No such file or directory
>
> Do you have any idea if there is any other way how to provide 
> maintainers this functionality for EPEL 7/8?

Parametric macro dependency generators are not supported in EPEL 7 and
8's RPM versions. You can still implement this using a "regular"
dependency generator. This is also described in the RPM
documentation[1]. Instead of specifying %__perlcompat_requires() and
writing an RPM macro that accepts a path name as %1, you specify
`%__percompat_requires /path/to/executable`. That script receives a
newline separated list of paths as stdin and prints the generated
dependencies to stdout separated by newlines.

So perlcompat.attr could look something like

```
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}

# %%__perlcompat_path can stay the same.
```

These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
passed to the script as an argument, because the script of course
doesn't have access to the RPM context. This can be any executable
written in any language, but it should be straightforward to do this in
shell.


[1]: 
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Gary Buhrmaster]

On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa  wrote:

> It has a similar impact that turning back on frame pointers would.
>
> Cf. 
> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost
>

That article explicitly states:
  "We need a proper study of performance and code size to understand
the magnitude of the impact"

I look forward to seeing the results of that proper study before
this is even considered for approval (since, after all, one of the
strong push-backs for -fno-omit-frame-pointer was performance).
___
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 2073893] CVE-2022-22624 webkitgtk: Use-after-free leading to arbitrary code execution

[bugzilla]

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



--- Comment #6 from Product Security DevOps Team  ---
This bug is now closed. Further updates for individual products will be
reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2022-22624


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
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 2073893] CVE-2022-22624 webkitgtk: Use-after-free leading to arbitrary code execution

[bugzilla]

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

Product Security DevOps Team  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|NEW |CLOSED
Last Closed||2022-12-06 02:33:26




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

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Jaroslav Prokop]

Hi,

This is underwhelming and I have several questions inline

On 12/5/22 20:58, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags

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 ==
Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
improve mitigation of security issues arising from buffer overflows in
packages in Fedora.

== Owner ==
* Name: [[User:siddhesh| Siddhesh Poyarekar]]
* Email:sipoy...@redhat.com


== Detailed Description ==

Default C and C++ compiler flags to build packages in Fedora currently
includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
some functions in glibc, thus providing some mitigation against buffer
overflows.  Since glibc 2.34 and GCC 12, there has been a new
fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage
of this mitigation.

The core change to bring in this mitigation is to change the default
build flags in `redhat-rpm-config` so that packages build by default
with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
that do not interact well with `_FORTIFY_SOURCE` and will also need a
workaround to downgrade fortification to level 2. The change will also
include this override.


How come systemd gets an exception? If it is a security option, it 
should be enabled everywhere.


I do not see benefit in a security change that ignores PID 1 process,

If the feature, on the GCC side, is not 100% done.
How do I tell a difference of a bug with the _FORTIFY_SOURCE which I 
will ignore and a bug with my package?


I do not have the knowledge or the time to be able to say that GCC 
generated the wrong machine code and therefore it is not a bug with my 
package.
If my program was not complaining before the change and is now 
complaining with the change, I am opting out of the change, and filing a 
bug against GCC on Fedora.


I assume that by the package providing the exception, packagers get to 
choose themselves and we do not need to go through FESCO

to disable a security feature?


== Benefit to Fedora ==

[https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing
Analysis of packages] in Fedora rawhide indicate that the improvement
of mitigation coverage is on average over 2.4x, in some cases
protecting more than half of the fortified glibc calls in the target
application.

This change will thus harden Fedora to a significant extent, thus
making it a more secure distribution out of the box.


1) Is there some complete source for all these findings? If google 
sheets cannot handle all the "raw data" as noted in the comment,

maybe it is the wrong medium.

2) What does *anything* on that google sheet mean. I have managed to 
figure out, from the article, that bos and bdos correspond to level 2 
and 3 of _FORTIFY_SOURCE.
However, total of /.*/? Violated accesses? Segfaults? Then followed by 
"Sum of total". For rubygem-ffi, this reaches into hundreds while "bdos" 
is 2. That is the only sum I can make, with the data provided.

I am no wiser from looking at it, what do the data mean?

3) I cannot speak to much else than Ruby, I do not see ruby in neither 
the failures or "All x86_64". Should we attempt to test it ourselves?


Please provide a proper "how to test" section, I cannot fix what I 
cannot test or compare results when I have no idea what I am seeing.


Actually, last time I heard about number of packages, it was around 50k 
(not source, build result), and as I stated,
Ruby is missing, and so are quite a few dependent packages that should 
have GCC involved somewhere:

~~~
$ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" 
--enablerepo="fedora" 2>/dev/null | grep -v "i686" | uniq | wc -l

115
~~~

If we also filter rubygem-* packages that depend on the *libruby.so* 
(and most probably contain a binary extension written in C/C++ that 
links to Ruby), I get 68 packages.
When I search "All x86_64" for "ruby" I get 28 packages. That is... not 
adding up.



== Scope ==
* Proposal owners: Post a merge request to redhat-rpm-config with the
actual change to build flags.

* Other developers:
Resolve bugs filed for build failures, either by fixing the bug
exposed by `_FORTIFY_SOURCE=3` or by disabling `_FORTIFY_SOURCE=3` for
the package if it is a false positive or if the package is unable to
adapt to the change.

* Release engineering: Mass rebuild required
* Policies and guidelines: Guidelines should include workaround for
packages that fail to build with `-Wp,-D_FORTIFY_SOURCE=3` due to a
false positive.
I'll just ask, what is a false positive. How can I tell. What are the 
steps for this.

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


== Upgrade/compatibility impact ==
No ABI 

[Bug 2150992] perl-generators 1.14 started to create bogus dependencies on perl(.::t/lifecycles/utils.pl)

[bugzilla]

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

Charles R. Anderson  changed:

   What|Removed |Added

 CC||c...@fea.st



--- Comment #1 from Charles R. Anderson  ---
I'm sorry to say this was caused by my fix for bug #2029995.  I'm not sure what
the proper fix should be.


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

[Neal Gompa]

On Mon, Dec 5, 2022 at 6:38 PM Emmanuel Seyman  wrote:
>
> * Neal Gompa [04/12/2022 22:26] :
> >
> > Smooge challenged me earlier in this conversation to provide patches
> > and effort, and I'm doing just that.
>
> Thank you for doing this, btw.
>
> Over the weekend, this became a discussion where none of the
> participants seemed to be listening to the others and it became somewhat
> painful to read. It's nice to see something constructive come out of it.
>

Pretty much the entire time this thread was going on, I was doing some
legwork or actual work on it. It's rare that I'm totally an armchair
engineer about things. :)

Usually I have a lot of other things going on so I can't do as much as
I'd like. Alas, I don't get paid to work on Fedora. :P

But in general, it looks like an upgrade to ImageMagick 7 will be
rather easy to do.




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

Re: Review Request: ImageMagick7

[Emmanuel Seyman]

* Neal Gompa [04/12/2022 22:26] :
>
> Smooge challenged me earlier in this conversation to provide patches
> and effort, and I'm doing just that.

Thank you for doing this, btw.

Over the weekend, this became a discussion where none of the
participants seemed to be listening to the others and it became somewhat
painful to read. It's nice to see something constructive come out of it.

Emmanuel
___
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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Adam Williamson]

On Mon, 2022-12-05 at 22:44 +0100, Kevin Kofler via devel wrote:
> Mattia Verga via devel wrote:
> > Or let's just get rid of Bodhi and trust all packagers to "know exactly
> > what they are doing with their package".
> 
> Yes please!

Exhibits 1 through 2636 for why this is a bad idea:
https://bodhi.fedoraproject.org/updates/?search==unpushed=1
-- 
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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Neal Gompa]

On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
 wrote:
>
> On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> >
>
> It is my vague recollection (I could easily be wrong, so
> correct me as appropriate) that _FORTIFY_SOURCE=3
> adds some runtime overhead that did not apply in
> previous levels.
>
> If that is correct, has the potential performance impact
> been evaluated and documented somewhere?  And, if
> correct, the change proposal should probably be modified
> to mention the potential performance impacts.

It has a similar impact that turning back on frame pointers would.

Cf. 
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost

I'm extremely displeased now, as the toolchain team basically told us
they wouldn't accept register pressure on x86_64 and then turned
around and made a proposal that does the same thing. Apparently
quality of life improvements for developers and real-time tracing
(e.g. making bpftrace useful) isn't worth it, but this is.

I want a really good justification for not doing both at the same time
if we're going to accept this.


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

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Neal Gompa]

On Mon, Dec 5, 2022 at 4:44 PM Kevin Kofler via devel
 wrote:
>
> Mattia Verga via devel wrote:
> > Or let's just get rid of Bodhi and trust all packagers to "know exactly
> > what they are doing with their package".
>
> Yes please!
>

NO! That way is madness! It penalizes fresh packagers too much in
favor of experts, and raises the bar for things too high.



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

Re: Policy on supporting old and external software packages and compat RPMS

[Kevin Kofler via devel]

Vitaly Zaitsev via devel wrote:

> On 05/12/2022 12:39, Terry Barnaby wrote:
>> I am wondering what Fedora's policy is on depreciated old shared
>> libraries and particularly compat RPM's ?
> 
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.

Or you can just build the compat package you need in a Copr, see, e.g.:
https://copr.fedorainfracloud.org/coprs/kkofler/compat-libgfortran-48/
(which I do not really use anymore, but I have kept the Copr up in case it 
is useful for other people).

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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kevin Kofler via devel]

Mattia Verga via devel wrote:
> Or let's just get rid of Bodhi and trust all packagers to "know exactly
> what they are doing with their package".

Yes please!

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: Can apmd be retired?

[Neal Gompa]

On Mon, Dec 5, 2022 at 4:01 PM Florian Weimer  wrote:
>
> It's a low-level package only built for i686.  If it actually works on
> x86-64 kernels, it should be built as an x86-64 package, too.  If it
> doesn't work on x86-64 kernels, I don't see why we should keep building
> it.
>

The only use I can think of for apmd on x86_64 systems is power
management for PCMCIA cards, but I can't remember the last time I saw
one of those... :)



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

Can apmd be retired?

[Florian Weimer]

It's a low-level package only built for i686.  If it actually works on
x86-64 kernels, it should be built as an x86-64 package, too.  If it
doesn't work on x86-64 kernels, I don't see why we should keep building
it.

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

[EPEL-devel] Replace versioned MODULE_COMPAT_ requires by generators

[Jitka Plesnikova]

Hi,

I am preparing replacement of versioned MODULE_COMPAT_ requires by 
dependency generators.

More details about the change can be found in mail thread [1].

The dependency generator, which I have prepared for Fedora, does not 
work for EPEL.


I would like to help maintainers who prefer one version of the spec file 
for all releases,

if it is possible.

Could be the following file added to the package epel-rpm-macros (or 
anything like this) for EPEL 9?

$ cat perlcompat.attr
%__perlcompat_requires() %{lua:
    local path = rpm.expand('%1')
    local perl_ver = rpm.expand('%{perl_version}')
    if path:match('.+%.so$') and perl_ver ~= "" then
   print('perl(:MODULE_COMPAT_' .. perl_ver .. ')')
    else
   print('perl-libs')
    end
}
%__perlcompat_path 
^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+


But I don't know how to do it for EPEL 7/8, because the above file 
doesn't work.

It ends with error [2]:
error: Couldn't exec perl-libs: No such file or directory

Do you have any idea if there is any other way how to provide 
maintainers this functionality for EPEL 7/8?


Thanks for any advice,
Jitka


[1] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/CGJYXUYNYRAFT5FOMEIJCCYAPXGTL3NY/
[2] 
https://download.copr.fedorainfracloud.org/results/jplesnik/perl-epel/centos-stream+epel-next-8-x86_64/05078720-perl-Data-Dumper/builder-live.log.gz


--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
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

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Gary Buhrmaster]

On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>

It is my vague recollection (I could easily be wrong, so
correct me as appropriate) that _FORTIFY_SOURCE=3
adds some runtime overhead that did not apply in
previous levels.

If that is correct, has the potential performance impact
been evaluated and documented somewhere?  And, if
correct, the change proposal should probably be modified
to mention the potential performance impacts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Ben Cotton]

On Mon, Dec 5, 2022 at 2:58 PM Ben Cotton  wrote:
>
> * Release engineering: Mass rebuild required

Please file a ticket with Release Engineering if you haven't already.

> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) If too many
> packages are found to be broken at runtime, the default for
> fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38.
> Change owner will do this in `redhat-rpm-config`
>
> * Contingency deadline: Beta freeze

Would a full mass rebuild be required to invoke the contingency
mechanism, or would we just need to rebuild affected packages? In
either case (but definitely if a full mass rebuild is required), I'm
concerned that this contingency deadline is too late in the schedule.
Branch day (2023-02-07) seems like it would be a better fit.


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

F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags

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 ==
Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
improve mitigation of security issues arising from buffer overflows in
packages in Fedora.

== Owner ==
* Name: [[User:siddhesh| Siddhesh Poyarekar]]
* Email: sipoy...@redhat.com


== Detailed Description ==

Default C and C++ compiler flags to build packages in Fedora currently
includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
some functions in glibc, thus providing some mitigation against buffer
overflows.  Since glibc 2.34 and GCC 12, there has been a new
fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage
of this mitigation.

The core change to bring in this mitigation is to change the default
build flags in `redhat-rpm-config` so that packages build by default
with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
that do not interact well with `_FORTIFY_SOURCE` and will also need a
workaround to downgrade fortification to level 2. The change will also
include this override.

== Benefit to Fedora ==

[https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing
Analysis of packages] in Fedora rawhide indicate that the improvement
of mitigation coverage is on average over 2.4x, in some cases
protecting more than half of the fortified glibc calls in the target
application.

This change will thus harden Fedora to a significant extent, thus
making it a more secure distribution out of the box.

== Scope ==
* Proposal owners: Post a merge request to redhat-rpm-config with the
actual change to build flags.

* Other developers:
Resolve bugs filed for build failures, either by fixing the bug
exposed by `_FORTIFY_SOURCE=3` or by disabling `_FORTIFY_SOURCE=3` for
the package if it is a false positive or if the package is unable to
adapt to the change.

* Release engineering: Mass rebuild required
* Policies and guidelines: Guidelines should include workaround for
packages that fail to build with `-Wp,-D_FORTIFY_SOURCE=3` due to a
false positive.

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


== Upgrade/compatibility impact ==
No ABI change, so there should be no impact on compatibility in a
mixed environment.

== How To Test ==
* Smoke testing of packages to ensure that they continue to work
correctly. Some packages may have overflows exposed at runtime, which
may need to be fixed.

== User Experience ==
No noticeable change to users.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) If too many
packages are found to be broken at runtime, the default for
fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38.
Change owner will do this in `redhat-rpm-config`

* Contingency deadline: Beta freeze
* Blocks release? Yes
* Blocks product? No

== Documentation ==

[https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
More context on `_FORTIFY_SOURCE=3` improvements].

== Release Notes ==



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

F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags

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 ==
Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
improve mitigation of security issues arising from buffer overflows in
packages in Fedora.

== Owner ==
* Name: [[User:siddhesh| Siddhesh Poyarekar]]
* Email: sipoy...@redhat.com


== Detailed Description ==

Default C and C++ compiler flags to build packages in Fedora currently
includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
some functions in glibc, thus providing some mitigation against buffer
overflows.  Since glibc 2.34 and GCC 12, there has been a new
fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage
of this mitigation.

The core change to bring in this mitigation is to change the default
build flags in `redhat-rpm-config` so that packages build by default
with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
that do not interact well with `_FORTIFY_SOURCE` and will also need a
workaround to downgrade fortification to level 2. The change will also
include this override.

== Benefit to Fedora ==

[https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing
Analysis of packages] in Fedora rawhide indicate that the improvement
of mitigation coverage is on average over 2.4x, in some cases
protecting more than half of the fortified glibc calls in the target
application.

This change will thus harden Fedora to a significant extent, thus
making it a more secure distribution out of the box.

== Scope ==
* Proposal owners: Post a merge request to redhat-rpm-config with the
actual change to build flags.

* Other developers:
Resolve bugs filed for build failures, either by fixing the bug
exposed by `_FORTIFY_SOURCE=3` or by disabling `_FORTIFY_SOURCE=3` for
the package if it is a false positive or if the package is unable to
adapt to the change.

* Release engineering: Mass rebuild required
* Policies and guidelines: Guidelines should include workaround for
packages that fail to build with `-Wp,-D_FORTIFY_SOURCE=3` due to a
false positive.

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


== Upgrade/compatibility impact ==
No ABI change, so there should be no impact on compatibility in a
mixed environment.

== How To Test ==
* Smoke testing of packages to ensure that they continue to work
correctly. Some packages may have overflows exposed at runtime, which
may need to be fixed.

== User Experience ==
No noticeable change to users.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) If too many
packages are found to be broken at runtime, the default for
fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38.
Change owner will do this in `redhat-rpm-config`

* Contingency deadline: Beta freeze
* Blocks release? Yes
* Blocks product? No

== Documentation ==

[https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
More context on `_FORTIFY_SOURCE=3` improvements].

== Release Notes ==



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

[Bug 2150998] New: perl-RT-Client-REST-0.71 is available

[bugzilla]

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

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



Releases retrieved: 0.71
Upstream release that is considered latest: 0.71
Current version/release in rawhide: 0.70-1.fc38
URL: http://search.cpan.org/dist/RT-Client-REST/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #14 from Miro Hrončok  ---
(In reply to Ralf Corsepius from comment #13)
> FWIW: This rpm/mock/whatever regression has not yet affected f36.
> 
> May-be this rings a bell to somebody ;)

As said in bz2150992, this is introduced in perl-generators 1.14.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2150992] perl-generators 1.14 started to create bogus dependencies on perl(.::t/lifecycles/utils.pl)

[bugzilla]

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

Miro Hrončok  changed:

   What|Removed |Added

Summary|perl-generators 1.4 started |perl-generators 1.14
   |to create bogus |started to create bogus
   |dependencies on |dependencies on
   |perl(.::t/lifecycles/utils. |perl(.::t/lifecycles/utils.
   |pl) |pl)




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #13 from Ralf Corsepius  ---
FWIW: This rpm/mock/whatever regression has not yet affected f36.

May-be this rings a bell to somebody ;)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||rt-5.0.3-3.fc38
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-12-05 19:40:23



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #11 from Ralf Corsepius  ---
(In reply to Miro Hrončok from comment #10)
> (In reply to Miro Hrončok from comment #9)
> > Looking at
> > https://src.fedoraproject.org/rpms/rt/c/
> > f8b483ba61a51d43152395f9ff0d6e49d2e3034a?branch=rawhide
> > 
> > I think the second definition of the __requires_exclude macro overrides the
> > first one.
> 
> Mea culpa, it does not.

Exactly. It appends. This construct is being used in many perl-*.rpms


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #10 from Miro Hrončok  ---
(In reply to Miro Hrončok from comment #9)
> Looking at
> https://src.fedoraproject.org/rpms/rt/c/
> f8b483ba61a51d43152395f9ff0d6e49d2e3034a?branch=rawhide
> 
> I think the second definition of the __requires_exclude macro overrides the
> first one.

Mea culpa, it does not.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #9 from Miro Hrončok  ---
Looking at
https://src.fedoraproject.org/rpms/rt/c/f8b483ba61a51d43152395f9ff0d6e49d2e3034a?branch=rawhide

I think the second definition of the __requires_exclude macro overrides the
first one.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #8 from Miro Hrončok  ---
> This bug is caused by a behavioral change/regression somewhere in rpm, mock 
> or related.

I've opened bz2150992 for the problem.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2150992] New: perl-generators 1.4 started to create bogus dependencies on perl(.::t/lifecycles/utils.pl)

[bugzilla]

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

Bug ID: 2150992
   Summary: perl-generators 1.4 started to create bogus
dependencies on perl(.::t/lifecycles/utils.pl)
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-generators
  Assignee: jples...@redhat.com
  Reporter: mhron...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Description of problem:
Between perl-generators-1.13-8.fc37 and perl-generators-1.14-1.fc38 a new
boghus dependency started to be generated for rt-tests.

Use the rt package from this commit:
https://src.fedoraproject.org/rpms/rt/c/78d6db9676df2a5032f42471348e20ce5d37ceda?branch=rawhide
(the bigus require was later filtered out manually).


perl-generators-1.13-8.fc37:
$ rpm -qRp rt-tests-5.0.3-2.fc38.noarch.rpm
/bin/sh
/usr/bin/bash
/usr/bin/perl
/usr/bin/prove
/usr/bin/rm
perl(CGI::PSGI)
perl(DBD::SQLite)
...


perl-generators-1.14-1.fc38:
$ rpm -qRp rt-tests-5.0.3-2.fc38.noarch.rpm
/bin/sh
/usr/bin/bash
/usr/bin/perl
/usr/bin/prove
/usr/bin/rm
perl(.::t/lifecycles/utils.pl)
perl(CGI::PSGI)
perl(DBD::SQLite)
...


$ rg -F 't/lifecycles/utils.pl' rt-5.0.3
rt-5.0.3/t/lifecycles/types.t
4:BEGIN {require  './t/lifecycles/utils.pl'};

rt-5.0.3/t/lifecycles/basics.t
4:BEGIN {require  './t/lifecycles/utils.pl'};

rt-5.0.3/t/lifecycles/dates.t
4:BEGIN {require './t/lifecycles/utils.pl'};

rt-5.0.3/t/lifecycles/moving.t
4:BEGIN {require './t/lifecycles/utils.pl'};

rt-5.0.3/t/lifecycles/unresolved-deps.t
4:BEGIN {require  './t/lifecycles/utils.pl'};

rt-5.0.3/t/lifecycles/unprivileged.t
4:BEGIN { require './t/lifecycles/utils.pl' }

rt-5.0.3/t/web/lifecycle_mappings.t
4:BEGIN { require './t/lifecycles/utils.pl' }

rt-5.0.3/t/web/lifecycle_rights.t
4:BEGIN {require './t/lifecycles/utils.pl'};


Version-Release number of selected component (if applicable):
perl-generators-1.14-1.fc38


How reproducible: always


Steps to Reproduce:
1. build rt from 78d6db9676df2a5032f42471348e20ce5d37ceda

Actual results:
perl(.::t/lifecycles/utils.pl) is required

Expected results:
perl(.::t/lifecycles/utils.pl) is not required

Additional info:
See https://bugzilla.redhat.com/show_bug.cgi?id=2148952#c6


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #6 from Ralf Corsepius  ---
This bug is caused by a behavioral change/regression somewhere in rpm, mock or
related.


Rationale: The only difference between 5.0.3-1 and 5.0.3-2 is a change to the
license-tag:

diff --git a/rt.spec b/rt.spec
index 39f8f31..3fbc8c0 100644
--- a/rt.spec
+++ b/rt.spec
@@ -52,10 +52,10 @@ Requires: mod_fcgid

 Name:  rt
 Version:   5.0.3
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Request tracker

-License:   GPLv2+
+License:   GPL-2.0-or-later
 URL:   https://bestpractical.com/request-tracker
 Source0:  
https://download.bestpractical.com/pub/rt/release/rt-%{version}.tar.gz
 # Notes on running the testsuite
@@ -648,6 +648,9 @@ fi
 %endif

 %changelog
+* Mon Nov 28 2022 Ralf Corsépius  - 5.0.3-2
+- Convert license to SPDX.
+
 * Wed Jul 27 2022 Ralf Corsépius  - 5.0.3-1
 - Upgrade to 5.0.3.


Rebuilding rt with current rpm/mock/... on fc37 and rawhide (Haven't tried <
fc37) pulls in this bogus requires on both on fc38 and fc37.
Former builts did not, as can be clearly seen in the released
rt-5.0.3-1.fc37.noarch.rpm

I'll likely apply a __requires_exclude filter to this package to work around
this rpm/mock/.. regression.

Snide side remark: This incident demonstrates that 
- the SPDX-license change stuff is as not harmless, as those people who are
enforcing it probably thought.
- some changes went into Fedora 37 which breaks rebuilding fc37 rpm.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #5 from Miro Hrončok  ---
In the meantime, I've opened:

https://pagure.io/releng/pull-request/11167 Stress out that the FTI bugzilla
reminders are automated
https://pagure.io/releng/issue/11168 Change the attitutde of the FTI reminder
bugzilla comments
https://pagure.io/releng/issue/11169 Dedicated bugzilla account/email address
for the FTI bugzillas


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #4 from Miro Hrončok  ---
Sorry, the link was supposed to be just
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148952
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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



--- Comment #3 from Miro Hrončok  ---
Ralf, the message is automated. I am sorry that it offended you.

If you have an idea for better wording, feel free to propose it at
https://pagure.io/releng/issues or contact me by email, there is no reason to
clutter this bugzilla with it.

If you think bugzillas like this one are not helpful, feel free to discuss that
with others (and not just me) via the usual communication channels, e.g.
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/2ZKJ7FWMOIXERV5AFH6I5G5R5WRLQTU3/

I'm just the messenger here, following a Fedora-wise approved policy. This is
not my ill will.

If you wish to be spared such Bugzillas without changing the policy, consider
testing future updates for installability prior to shipping them. The Zuul CI
has the ability to do that for the packager:
https://fedoraproject.org/wiki/Zuul-based-ci


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

Re: Orphaned packages looking for new maintainers

[Emmanuel Seyman]

* Chuck Anderson [05/12/2022 13:06] :
>
> Would you lke to take perl-Term-ShellUI as well?  It is a dependency
> of kpcli which requires perl-File-KeePass.  Otherwise I'm happy to
> take it.

Taken as well. Co-maintainers are welcome.

Emmanuel
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Flags|needinfo?(rc040203@freenet. |
   |de) |



--- Comment #2 from Ralf Corsepius  ---
(In reply to Miro Hrončok from comment #1)
> Hello,
> 
> This is the first reminder (step 3 from
> https://docs.fedoraproject.org/en-US/fesco/
> Fails_to_build_from_source_Fails_to_install/
> #_package_removal_for_long_standing_ftbfs_and_fti_bugs).
> 
> If you know about this problem and are planning on fixing it, please
> acknowledge so by setting the bug status to ASSIGNED. If you don't have time
> to maintain this package, consider orphaning it, so maintainers of dependent
> packages realize the problem.

Change your attitude, Miro!

Filing a bug and then threatening maintainers this way one week later, is just
rude and hostile.

You are in error to believe your behavior is helpful. You seem to be missing
that volunteer contributor are working on Fedora in their spare time and are
not your subordinates.


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

Schedule for Tuesday's FESCo Meeting (2022-12-06)

[Miro Hrončok]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2022-12-06 17:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

enable systemd preset for waagent.service (WALinuxAgent)
https://pagure.io/fesco/issue/2849
APPROVED conditionally (+3,0,-0)

Nonresponsive maintainer: ModemManager lkundrak
https://pagure.io/fesco/issue/2888
lkundrak is still interested in maintaining their Fedora packages

Nonresponsive maintainer: ultrafredde
https://pagure.io/fesco/issue/2892
APPROVED (+1,0,-0)

Change: Ruby 3.2
https://pagure.io/fesco/issue/2893
APPROVED (+5,0,-0)

Change: MobilityPhoshImage
https://pagure.io/fesco/issue/2896
APPROVED (+2,0,-0)

Change: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH
https://pagure.io/fesco/issue/2899
APPROVED (+5, 0, -0)

Change: Enable bootupd for Fedora Silverblue & Kinoite
https://pagure.io/fesco/issue/2900
APPROVED (+4,0,-0)

Change: Prevent from building RPM packages providing python3dist(...) = 0
https://pagure.io/fesco/issue/2903
APPROVED (+7,0,-0)

Change: Remove initial-setup from KDE Spin & Kinoite
https://pagure.io/fesco/issue/2904
APPROVED (+3,1,-0)

= New business =

#2905 Re-approval of Change proposal: RPM Macros for Build Flags for F38
https://pagure.io/fesco/issue/2905

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or 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.

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

Review request: Python-pypresence

[Steve Cossette]

Good afternoon/morning everyone,

I'm a co-packager for Lutris, and the newest version (0.5.12) had a couple
more package requirements, one of which is pypresence, which isn't packaged
with Fedora.

I created a review request here:
https://bugzilla.redhat.com/show_bug.cgi?id=2150506 if anyone could help in
reviewing the package so we can update Lutris, that would be greatly
appreciated.

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

Re: Orphaned packages looking for new maintainers

[Chuck Anderson]

On Mon, Dec 05, 2022 at 01:28:28PM +0100, Emmanuel Seyman wrote:
> * Miro Hrončok [05/12/2022 12:36] :
> >
> > perl-App-PFT  orphan   1 weeks 
> > ago
> > perl-File-KeePass cra, echevemaster, orphan,   0 weeks 
> > ago
> >   xavierb
> > perl-HTTP-Server-Simple-Authenorphan   1 weeks 
> > ago
> > perl-Library-CallNumber-LCorphan   1 weeks 
> > ago
> > perl-PFT  orphan   1 weeks 
> > ago
> > perl-Pod-PseudoPodorphan   1 weeks 
> > ago
> > perl-Pod-PseudoPod-LaTeX  orphan   1 weeks 
> > ago
> > perl-Proc-PID-Fileorphan   1 weeks 
> > ago
> > perl-WWW-xkcd orphan   0 weeks 
> > ago
> 
> I have taken the above packages.

Emmanuel,

Would you lke to take perl-Term-ShellUI as well?  It is a dependency
of kpcli which requires perl-File-KeePass.  Otherwise I'm happy to
take it.
___
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 2148952] F38FailsToInstall: rt-tests

[bugzilla]

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

Miro Hrončok  changed:

   What|Removed |Added

  Flags||needinfo?(rc040203@freenet.
   ||de)



--- Comment #1 from Miro Hrončok  ---
Hello,

This is the first reminder (step 3 from
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs).

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


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

Re: Orphaned packages looking for new maintainers

[Ron Olson]

I’d be willing to take Toilet, as I love that utility.

On 5 Dec 2022, at 5:36, Miro Hrončok wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2022-12-05.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
>
> Package  (co)maintainers   Status 
> Change
> 
> 5minute   orphan   0 weeks ago
> CFR   jvanek, orphan   0 weeks ago
> CheMPS2   orphan   0 weeks ago
> PolicyKit-olpcorphan   1 weeks ago
> abiword   chimosky, herrold, huzaifas, 0 weeks ago
>   orphan
> aboot orphan   0 weeks ago
> albatross orphan   1 weeks ago
> alleyoop  orphan   1 weeks ago
> alure orphan   0 weeks ago
> amor  jgrulich, kde-sig, orphan,   1 weeks ago
>   rdieter, than
> anki  chkr, orphan 0 weeks ago
> asn1c orphan   0 weeks ago
> backup-managerorphan   1 weeks ago
> bbkeysorphan   0 weeks ago
> bharati-m17n  orphan   0 weeks ago
> bibtex2html   orphan, thofmann 0 weeks ago
> biosdevname   lnykryn, msekleta, orphan,   0 weeks ago
>   vpavlin
> blackbox  cicku, orphan0 weeks ago
> bluecurve-classic-metacity-   gnome-sig, orphan, rstrode   0 weeks ago
> theme
> bluecurve-gnome-theme gnome-sig, orphan, rstrode   0 weeks ago
> bluecurve-gtk-themes  gnome-sig, orphan, rstrode   0 weeks ago
> bluecurve-icon-theme  gnome-sig, orphan, rstrode   0 weeks ago
> bluecurve-kde-theme   gnome-sig, kkofler, orphan,  0 weeks ago
>   rdieter, rstrode, than
> bluecurve-metacity-theme  gnome-sig, orphan, rstrode   0 weeks ago
> bluecurve-xmms-skin   gnome-sig, orphan, rstrode   0 weeks ago
> brainfuck orphan   0 weeks ago
> buildbot  besser82, ignatenkobrain,1 weeks ago
>   limb, ngompa, orphan, radez,
>   smilner
> cairo-clock   orphan   0 weeks ago
> code-editor   orphan   1 weeks ago
> compton   orphan   1 weeks ago
> converseenorphan   1 weeks ago
> cups-bjnp orphan   1 weeks ago
> curlpporphan   0 weeks ago
> dmz-cursor-themes company, orphan  1 weeks ago
> docker-composelsm5, orphan, ttomecek   1 weeks ago
> ejabberd  bowlofeggs, jcline, orphan,  0 weeks ago
>   xavierb
> enchant   orphan   0 weeks ago
> erlang-epgsql lkundrak, orphan 1 weeks ago
> eurekaorphan   0 weeks ago
> fcitx cheeselee, cicku, orphan, pwu,   1 weeks ago
>   yanqiyu
> 

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Mattia Verga via devel]

IMO, buildroot overrides are devil, because may have impact on builds performed 
by other unaware users. The reported examples may be handled by sidetags or 
requesting exceptions to releng:

Il 03/12/22 00:14, Kalev Lember ha scritto:

> However, having said that, I also find buildroot overrides useful. Some 
> examples:
>
> 1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new 
> version through the freeze, but that includes a library soname bump.
>
> What I would do in that case is submit the GNOME megaupdate to Bodhi, and 
> also submit the library as a buildroot override to ensure that nothing can 
> build against the old soname -- I am fairly confident that the GNOME 
> megaupdate, together with the soname bump makes it to stable first.

The premise here is that a library got a soname bump. That means that the 
megaupdate should include all packages which depends on that library.

Say, in the megaupdate there's foo-1.0.0-1 which was built against libbar.so.2. 
If any other user makes a build of foo-1.0.0-2 against the old libbar.so.1, we 
can have Bodhi stop the user when they try to create the update, since there's 
already a pending multiple update containing foo. After the megaupdate is 
pushed to stable, if the user tries to push again foo-1.0.0-2, QA tests should 
see it depends on the old soname and again block the update.

> 2) I need to do a container build and include a new CVE fix (as it's critical 
> and we need to get fixes out ASAP), but that package build to include in the 
> container is only in updates-testing.
>
> What I'd do in this case is to submit a buildroot override because everything 
> that's overridden gets included in container builds. After my container build 
> is done I'd expire the buildroot override.

If the CVE fix is so urgent, it doesn't make sense to push it out only for 
container. We should have a policy for asking Releng exemptions about the 
testing period and push the update out for everything.

> 3) We've had some "fun" issues with sysprof symbols leaking out from the GTK 
> stack into other libraries consuming it. This has caused subtle ABI issues 
> and when working on a fix and to make sure no package can build against the 
> "wrong" GTK version, I've used buildroot overrides.

Same as above. Broken builds which causes breakage of other dependencies should 
be removed or the update should be pushed ASAP by Releng.

> 4) Compiler issues, with compilers producing broken code.
>
> To test the fixes and make sure packages start using the new fixed versions 
> ASAP, a buildroot override is often useful.

Same as above.

The purpose we have an update system is to avoid not only distribution 
breakages for end users, but also buildroot breakages. Buildroot overrides just 
overrides everything, so I think they must be a Releng right only.

Or let's just get rid of Bodhi and trust all packagers to "know exactly what 
they are doing with their package".

Mattia___
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/CentOS planned outage 2022-12-08 19:00 UTC

[Stephen Smoogen]

lanned Outage - IAD2 Outage - 2022-12-08 19:00 UTC

There will be an outage starting at 2022-12-08 19:00 UTC,
which will last approximately 4 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-12-08 19:00 UTC'

Reason for outage:

There will be a multi hour outage as a hardware firewall is changed out of
the IAD2 data center where most Fedora systems are housed. Outages should
be in short cycles as the firewall is changed over to new hardware and
rules are tested and confirmed.

Affected Services:

Most Fedora and CentOS Services will be affected
Build systems for s390x will need to be restarted as NFS will break
Builds in CentOS Stream and other infrastructure will be blocked during
this time.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

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

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

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

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

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

Package  (co)maintainers   Status Change

5minute   orphan   0 weeks ago
CFR   jvanek, orphan   0 weeks ago
CheMPS2   orphan   0 weeks ago
PolicyKit-olpcorphan   1 weeks ago
abiword   chimosky, herrold, huzaifas, 0 weeks ago
  orphan
aboot orphan   0 weeks ago
albatross orphan   1 weeks ago
alleyoop  orphan   1 weeks ago
alure orphan   0 weeks ago
amor  jgrulich, kde-sig, orphan,   1 weeks ago
  rdieter, than
anki  chkr, orphan 0 weeks ago
asn1c orphan   0 weeks ago
backup-managerorphan   1 weeks ago
bbkeysorphan   0 weeks ago
bharati-m17n  orphan   0 weeks ago
bibtex2html   orphan, thofmann 0 weeks ago
biosdevname   lnykryn, msekleta, orphan,   0 weeks ago
  vpavlin
blackbox  cicku, orphan0 weeks ago
bluecurve-classic-metacity-   gnome-sig, orphan, rstrode   0 weeks ago
theme
bluecurve-gnome-theme gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-gtk-themes  gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-icon-theme  gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-kde-theme   gnome-sig, kkofler, orphan,  0 weeks ago
  rdieter, rstrode, than
bluecurve-metacity-theme  gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-xmms-skin   gnome-sig, orphan, rstrode   0 weeks ago
brainfuck orphan   0 weeks ago
buildbot  besser82, ignatenkobrain,1 weeks ago
  limb, ngompa, orphan, radez,
  smilner
cairo-clock   orphan   0 weeks ago
code-editor   orphan   1 weeks ago
compton   orphan   1 weeks ago
converseenorphan   1 weeks ago
cups-bjnp orphan   1 weeks ago
curlpporphan   0 weeks ago
dmz-cursor-themes company, orphan  1 weeks ago
docker-composelsm5, orphan, ttomecek   1 weeks ago
ejabberd  bowlofeggs, jcline, orphan,  0 weeks ago
  xavierb
enchant   orphan   0 weeks ago
erlang-epgsql lkundrak, orphan 1 weeks ago
eurekaorphan   0 weeks ago
fcitx cheeselee, cicku, orphan, pwu,   1 weeks ago
  yanqiyu
fcitx-chewing cheeselee, orphan, yanqiyu   1 weeks ago
fcitx-cloudpinyin cheeselee, orphan, yanqiyu   1 weeks ago
fcitx-configtool  cheeselee, orphan, yanqiyu   1 weeks ago
fcitx-fbterm   

Re: Policy on supporting old and external software packages and compat RPMS

[Jarek Prokop]

On 12/5/22 14:57, Peter Robinson wrote:

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
  wrote:

On 05/12/2022 12:39, Terry Barnaby wrote:

I am wondering what Fedora's policy is on depreciated old shared
libraries and particularly compat RPM's ?

Fedora is a bleeding edge distribution. If you need old versions, you
should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
gnome-boxes, and probably others I forgot).
There shouldn't be a problem spinning up a graphical environment of 
CentOS 7, getting EPEL and then using the tool.


Maybe the tool would work using the `toolbox` utility using last known 
good Fedora version for the tool.

That is just my wild guess however.

This is sometimes the tax for being "too" modern.
If the vendor does not want to support Fedora, we can't be held 
accountable to fully support their solution.
Does the software work? Yes? That is great! If not, well… we can't do 
much without the source code under nice FOSS license, can we.


Regards,
Jarek
___
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

[Gwyn Ciesla via devel]

I've taken python-humblewx, buildbot, php-adodb.

signature.asc
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

Fedora/CentOS planned outage 2022-12-08 19:00 UTC

[Stephen Smoogen]

lanned Outage - IAD2 Outage - 2022-12-08 19:00 UTC

There will be an outage starting at 2022-12-08 19:00 UTC,
which will last approximately 4 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-12-08 19:00 UTC'

Reason for outage:

There will be a multi hour outage as a hardware firewall is changed out of
the IAD2 data center where most Fedora systems are housed. Outages should
be in short cycles as the firewall is changed over to new hardware and
rules are tested and confirmed.

Affected Services:

Most Fedora and CentOS Services will be affected
Build systems for s390x will need to be restarted as NFS will break
Builds in CentOS Stream and other infrastructure will be blocked during
this time.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.

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

Re: Policy on supporting old and external software packages and compat RPMS

[Stephen Smoogen]

On Mon, 5 Dec 2022 at 08:56, Florian Weimer  wrote:

> * Stephen Smoogen:
>
> > Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29
> > weeks. Getting code to compile for it on newer OS's is harder and
> > packagers volunteer time is limited.
>
> For official information on support life-cycles, please consider this
> official resource:
>
>   Red Hat Enterprise Linux Life Cycle
>   
>
> In particular the “Life-cycle Dates” page.
>
>
I was going from

Maintenance SupportRed Hat Enterprise Linux
VersionGeneral availabilityFull support endsMaintenance Support 1
endsMaintenance
Support or Maintenance Support 2 endsExtended life cycle support (ELS)
add-on endsExtended life phase endsFinal minor release
7 June 10, 2014 August 6, 2019 August 6, 2020 June 30, 2024 June 30, 2026
Ongoing 7.9

While there is ELS going to 2026, that is an additional contract outside of
general service.


> Thanks,
> Florian
>
>

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

Re: wlroots 0.16 update announcement

[Frantisek Zatloukal]

>From gamescope perspective, a new release would require wlroot 0.16 (commit
is already present in master), so can you cc me whenever you do wlroot 0.16
in bodhi? I'd either backport the specific commit/or a new release and add
it to the update.

I'll handle rawhide when we have a new release or when you create the f37
update, whichever is sooner, I don't think we need to hurry there.

On Sun, Dec 4, 2022 at 5:26 AM Artem Tim  wrote:

> Thanks! labwc and wayfire updated for Rawhide [1]. Please ping when you
> consider new wlroots 0.16 mature enough and start updating it for f37.
>
> [1]:
> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-9bac007398
> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-1bbf74fbb8
> ___
> 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
>


-- 

Best regards / S pozdravem,

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

Re: Policy on supporting old and external software packages and compat RPMS

[Peter Robinson]

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
 wrote:
>
> On 05/12/2022 12:39, Terry Barnaby wrote:
> > I am wondering what Fedora's policy is on depreciated old shared
> > libraries and particularly compat RPM's ?
>
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Florian Weimer]

* Stephen Smoogen:

> Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29
> weeks. Getting code to compile for it on newer OS's is harder and
> packagers volunteer time is limited.

For official information on support life-cycles, please consider this
official resource:

  Red Hat Enterprise Linux Life Cycle
  

In particular the “Life-cycle Dates” page.

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: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 05. 12. 22 12:36, Miro Hrončok wrote:

The following packages are orphaned...

     Package  (co)maintainers   Status 
Change

python-argon2-cffi    atim, epel-packagers-sig,    0 weeks ago
   limb, orphan, salimma


Taken and updating it:

https://src.fedoraproject.org/rpms/python-argon2-cffi/pull-request/4

Needs python-argon2-cffi-bindings:

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

--
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 2053166] perl-XML-LibXML: Validation succeeds even though the DTD could not be loaded [fedora-all]

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Version|35  |36




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

Re: Orphaned packages looking for new maintainers

[Emmanuel Seyman]

* Miro Hrončok [05/12/2022 12:36] :
>
> perl-App-PFT  orphan   1 weeks ago
> perl-File-KeePass cra, echevemaster, orphan,   0 weeks ago
>   xavierb
> perl-HTTP-Server-Simple-Authenorphan   1 weeks ago
> perl-Library-CallNumber-LCorphan   1 weeks ago
> perl-PFT  orphan   1 weeks ago
> perl-Pod-PseudoPodorphan   1 weeks ago
> perl-Pod-PseudoPod-LaTeX  orphan   1 weeks ago
> perl-Proc-PID-Fileorphan   1 weeks ago
> perl-WWW-xkcd orphan   0 weeks ago

I have taken the above packages.

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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 05 December (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 5th
December(today!) at 1300UTC in #fedora-neuro on Matrix or IRC
(Libera.chat).  The meeting is a public meeting, and open for everyone
to attend. You can join us over:

Matrix: https://matrix.to/#/#neuro:fedoraproject.org
IRC: https://webchat.libera.chat/?channels=#fedora-neuro

You can use this link to see the local time for the meeting:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20221205T13=%3A=1

or you can use this command in a terminal:
$ date --date='TZ="UTC" 1300 today'

The meeting will be chaired by @ankursinha. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Package health check: 
https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check for F38: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

The meeting announcement is also posted on the NeuroFedora blog here:
https://neuroblog.fedoraproject.org/2022/12/05/next-open-neurofedora-meeting-5-december-1300-utc.html

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Orphaned packages looking for new maintainers

[Sandro Mani]

Taking these


mingw-dbus orphan   1 weeks ago
mingw-qt5-qtquickcontrols orphan, smani 1 weeks ago
mingw-xerces-c    orphan 1 weeks ago


Can take this if no-one else is interested (@Sergio Basto?)

> docker-compose    lsm5, orphan, ttomecek   1 
weeks ago


This one

> enchant orphan   0 weeks ago

is a dependency for gtkspell, which is dead and superseded by gtkspell3 
and I'd be tempted to also let go. Dependencies are:


emelfm2
gummi
logjam
ocaml-lablgtk
perl-Gtk2-Spell
pidgin
purple-plugin_pack-pidgin
sylpheed

--

Sandro



smilner: python-oauthlib, buildbot
snits: tss2
spot: alure, python-requests-oauthlib, enchant, libbonoboui, 
libbonobo, ibus-table-others
ssp: libgnome, enchant, libbonoboui, gtkhtml3, liboil, gconf-editor, 
libbonobo, ibus-table-others, libgnomeui

stahnma: rubygem-syntax, rubygem-yard
stefw: seahorse-nautilus
steve: nqp, libgnome, gl-117, rakudo, libbonoboui, moarvm, libgnomeui
stevetraylen: python-django-tastypie, python-argon2-cffi, 
python-requests-oauthlib

stingray: enchant
supakeen: python-argon2-cffi
survient: holland
tagoh: ibus-table-others
tartare: libgnomeui, libgnome, libbonoboui
tchaikov: python-isodate
tdawson: rubygem-yard, rubygem-memcache-client, rubygem-ZenTest, 
python-multilib, rubygem-archive-tar-minitar, python-argon2-cffi

tdecacqu: nvml
terjeros: nvml
thalman: python-requests-oauthlib
than: amor, bluecurve-kde-theme, enchant
thm: libbonobo, libbonoboui
thofmann: bibtex2html
thunderbirdtr: qconf
tingping: enchant
tlavocat: nvml
tomegun: nvml
tomh: mingw-xerces-c, mingw-pcre
totol: python-argon2-cffi
tpokorra: libgnomeui, libbonobo, libgnome, libbonoboui
trb143: hunspell-kn
ttomecek: python-dockerpty, docker-compose, python-multilib
twaugh: python-multilib
ueno: fcitx
valtri: rubygem-yard
vanessakris: mingw-xerces-c, mingw-pcre
vascom: nvml, perl-Term-ShellUI, enchant
virtmaint-sig: nvml
vkmc: python-oauthlib
vokac: libmacaroons
vondruch: rubygem-yard
vpavlin: biosdevname
vpv: hunspell-kn
vrutkovs: python-multilib
wsato: ibus-table-others
wwoods: nvml, python-multilib
xavierb: perl-File-KeePass, perl-Term-ShellUI, ibus-table-others, 
python-requests-mock, ejabberd

yaneti: perl-Test-POE-Server-TCP
yanqiyu: kcm-fcitx, golang-github-fvbommel-sortorder, fcitx, 
fcitx-cloudpinyin, golang-github-containerd-stargz-snapshotter, 
fcitx-unikey, fcitx-m17n, golang-github-mitchellh-cli, 
golang-github-tonistiigi-rosetta, fcitx-chewing, fcitx-configtool, 
enchant, fcitx-fbterm, fcitx-sunpinyin, sunpinyin, fcitx-table-extra, 
fcitx-table-other, fcitx-hangul, golang-github-hanwen-fuse, 
fcitx-ui-light

ykarel: python-requests-mock
yunyings: tboot
zaitcev: python-oauthlib
zaneb: python-oauthlib
zawertun: nvml
zbyszek: nvml
zuul: nvml, python-argon2-cffi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20221205.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221204.n.0
NEW: Fedora-Rawhide-20221205.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  3
Dropped packages:1
Upgraded packages:   58
Downgraded packages: 0

Size of added packages:  121.98 KiB
Size of dropped packages:4.99 MiB
Size of upgraded packages:   150.61 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   902.85 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-hatch-jupyter-builder-0.8.1-1.fc38
Summary: A hatch plugin to help build Jupyter packages
RPMs:python3-hatch-jupyter-builder
Size:53.48 KiB

Package: python-jupyter-events-0.5.0-1.fc38
Summary: Jupyter Event System library
RPMs:python3-jupyter-events
Size:46.18 KiB

Package: python-pytest-console-scripts-1.3.1-1.fc38
Summary: Pytest plugin for testing console scripts
RPMs:python3-pytest-console-scripts
Size:22.32 KiB


= DROPPED PACKAGES =
Package: adapta-backgrounds-0.5.3.1-13.fc37
Summary: Wallpaper collection for adapta-project
RPMs:adapta-backgrounds
Size:4.99 MiB


= UPGRADED PACKAGES =
Package:  accel-config-3.5.2-3.fc38
Old package:  accel-config-3.5.1-2.fc38
Summary:  Configure accelerator subsystem devices
RPMs: accel-config accel-config-devel accel-config-libs
Size: 302.30 KiB
Size change:  -13.97 KiB
Changelog:
  * Sun Dec 04 2022 Jun Miao  - 3.5.2-3
  - Update to v3.5.2 release


Package:  ansible-collection-community-docker-3.3.0-1.fc38
Old package:  ansible-collection-community-docker-3.2.2-1.fc38
Summary:  Ansible modules and plugins for working with Docker
RPMs: ansible-collection-community-docker
Size: 218.98 KiB
Size change:  2.69 KiB
Changelog:
  * Sat Dec 03 2022 Maxwell G  - 3.3.0-1
  - Update to 3.3.0.


Package:  asahi-scripts-20221129-1.fc38
Old package:  asahi-scripts-20221122-1.fc38
Summary:  Miscellaneous admin scripts for Asahi Linux
RPMs: asahi-fwextract asahi-scripts dracut-asahi linux-firmware-vendor 
update-m1n1
Size: 54.71 KiB
Size change:  519 B
Changelog:
  * Sun Dec 04 2022 Davide Cavalca  20221129-1
  - Update to 20221129; Fixes: RHBZ#2149785


Package:  bdii-5.2.26-10.fc38
Old package:  bdii-5.2.26-9.fc37
Summary:  The Berkeley Database Information Index (BDII)
RPMs: bdii
Size: 30.06 KiB
Size change:  -185 B
Changelog:
  * Sun Dec 04 2022 Mattias Ellert  - 5.2.26-10
  - Use mdb slapd backend (Fedors 36+, EPEL 9+)


Package:  conda-22.11.0-2.fc38
Old package:  conda-4.13.0-5.fc37
Summary:  Cross-platform, Python-agnostic binary package manager
RPMs: conda python3-conda
Size: 1.28 MiB
Size change:  -6.43 KiB
Changelog:
  * Sat Aug 06 2022 Orion Poplawski  4.14.0-1
  - Update to 4.14.0

  * Sun Dec 04 2022 Orion Poplawski  22.11.0-1
  - Update to 22.11.0 (Fixes FTBFS bz#135403) Update licensing, use SPDX
Cleanup bundled provides

  * Sun Dec 04 2022 Orion Poplawski  22.11.0-2
  - Set av_dir to /etc/conda; Do not add /usr/condabin to PATH


Package:  coturn-4.6.1-1.fc38
Old package:  coturn-4.6.0-2.fc38
Summary:  TURN/STUN & ICE Server
RPMs: coturn coturn-client-devel coturn-client-libs coturn-utils
Size: 1.70 MiB
Size change:  1.67 KiB
Changelog:
  * Sun Dec 04 2022 Robert Scheck  - 4.6.1-1
  - Upgrade to 4.6.1 (#2150608)


Package:  dqlite-1.12.0-1.fc38
Old package:  dqlite-1.11.1-1.fc38
Summary:  Embeddable, replicated and fault tolerant SQL engine
RPMs: dqlite dqlite-devel
Size: 476.42 KiB
Size change:  17.92 KiB
Changelog:
  * Sun Dec 04 2022 Reto Gantenbein  - 1.12.0-1
  - Update to 1.12.0


Package:  golang-github-containerd-cgroups-1:1.0.4-2.fc38
Old package:  golang-github-containerd-cgroups-1.0.4-1.fc38
Summary:  Cgroups package for Go
RPMs: golang-github-containerd-cgroups-devel
Size: 91.00 KiB
Size change:  232 B
Changelog:
  * Sun Dec 04 2022 Robert-Andr?? Mauchin  1.0.4-2
  - Add new import path

  * Sun Dec 04 2022 Robert-Andr?? Mauchin  1:1.0.4-1
  - Revert "Add new import path"

  * Sun Dec 04 2022 Robert-Andr?? Mauchin  1:1.0.4-2
  - Fix Epoch


Package:  golang-x-sys-0.3.0-1.fc38
Old package:  golang-x-sys-0-25.20220803gita90be44.fc37
Summary:  Go packages for low-level interaction with the operating system
RPMs: golang-x-sys-devel
Size: 506.46 KiB
Size change:  8.83 KiB
Changelog:
  * Sun Dec 04 2022 Robert-Andr?? Mauchin  0.3.0-1
  - Update to 0.3.0


Package:  gopass-1.15.0-1.fc38
Old package:  gopass-1.14.10-1.fc38
Summary:  The slightly more awesome standard unix password manager for teams
RPMs: golang-github-gopasspw-gopass-devel gopass
Size: 29.05 MiB
Size change:  178.73 KiB
Changelog:
  * Sun Dec 04 2022 Fabio Alessandro Locati  1.15.0-1
  - update to 1.15.0. Fixes rhbz#2125917


Package:   

Re: Policy on supporting old and external software packages and compat RPMS

[Vitaly Zaitsev via devel]

On 05/12/2022 12:39, Terry Barnaby wrote:
I am wondering what Fedora's policy is on depreciated old shared 
libraries and particularly compat RPM's ?


Fedora is a bleeding edge distribution. If you need old versions, you 
should try CentOS or RHEL.


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

Re: Policy on supporting old and external software packages and compat RPMS

[Stephen Smoogen]

On Mon, 5 Dec 2022 at 06:45, Terry Barnaby  wrote:

> Hi,
>
> With the latest release of Fedora37 we were hit with an issue where the 
> ncurses-compat-libs
> RPM had been depreciated. Due to this some of the tools we use would no
> longer install from their respective RPM's or their tar based installs
> would not run as they needed the libncurses*5.so shared libraries.
>
> We use a number of software packages for Electronics and Software
> development, some of which are developed by organisations and companies
> outside of Fedora. This includes things like ARM GCC compilers, FPGA
> compilers, PCB tools, manufacturers utilities etc. Many of these are built
> for Redhat7, being a good general and stable base Linux system for these
> companies/organisations to target. There are a few shared libraries that
> are commonly used and ncurses is one of these.
>
> I am wondering what Fedora's policy is on depreciated old shared libraries
> and particularly compat RPM's ?
>
>
The policy is that if there are packagers who are actively going to be able
to maintain the code, AND the code can be built with the current tools in
the build system, it is kept. If the packagers want it but the code can't
be built, then it is removed. If the packagers don't want it but the code
could still be built, it is still removed.

Sometimes the packager isn't willing anymore because they don't need it
anymore in their work. Other times it is because they asked on a list and
no one answered. Or a dozen other reasons.

Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29 weeks.
Getting code to compile for it on newer OS's is harder and packagers
volunteer time is limited.



> If there isn't one, for the benefit of users and making Fedora OS more
> generally useful, can I suggest that relatively often used compat RPMS are
> kept available at least while a major base system such as Redhat7 is still
> widely used as a build platform for external companies/organisations and/or
> perhaps for at least 15? years (or some defined time) after they become
> compat RPM's ?
>
> Terry
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


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

Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

Hi,

With the latest release of Fedora37 we were hit with an issue where the 
ncurses-compat-libs RPM had been depreciated. Due to this some of the 
tools we use would no longer install from their respective RPM's or 
their tar based installs would not run as they needed the 
libncurses*5.so shared libraries.


We use a number of software packages for Electronics and Software 
development, some of which are developed by organisations and companies 
outside of Fedora. This includes things like ARM GCC compilers, FPGA 
compilers, PCB tools, manufacturers utilities etc. Many of these are 
built for Redhat7, being a good general and stable base Linux system for 
these companies/organisations to target. There are a few shared 
libraries that are commonly used and ncurses is one of these.


I am wondering what Fedora's policy is on depreciated old shared 
libraries and particularly compat RPM's ?


If there isn't one, for the benefit of users and making Fedora OS more 
generally useful, can I suggest that relatively often used compat RPMS 
are kept available at least while a major base system such as Redhat7 is 
still widely used as a build platform for external 
companies/organisations and/or perhaps for at least 15? years (or some 
defined time) after they become compat RPM's ?


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

Orphaned packages looking for new maintainers

[Miro Hrončok]

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

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

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

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

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

Package  (co)maintainers   Status Change

5minute   orphan   0 weeks ago
CFR   jvanek, orphan   0 weeks ago
CheMPS2   orphan   0 weeks ago
PolicyKit-olpcorphan   1 weeks ago
abiword   chimosky, herrold, huzaifas, 0 weeks ago
  orphan
aboot orphan   0 weeks ago
albatross orphan   1 weeks ago
alleyoop  orphan   1 weeks ago
alure orphan   0 weeks ago
amor  jgrulich, kde-sig, orphan,   1 weeks ago
  rdieter, than
anki  chkr, orphan 0 weeks ago
asn1c orphan   0 weeks ago
backup-managerorphan   1 weeks ago
bbkeysorphan   0 weeks ago
bharati-m17n  orphan   0 weeks ago
bibtex2html   orphan, thofmann 0 weeks ago
biosdevname   lnykryn, msekleta, orphan,   0 weeks ago
  vpavlin
blackbox  cicku, orphan0 weeks ago
bluecurve-classic-metacity-   gnome-sig, orphan, rstrode   0 weeks ago
theme
bluecurve-gnome-theme gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-gtk-themes  gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-icon-theme  gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-kde-theme   gnome-sig, kkofler, orphan,  0 weeks ago
  rdieter, rstrode, than
bluecurve-metacity-theme  gnome-sig, orphan, rstrode   0 weeks ago
bluecurve-xmms-skin   gnome-sig, orphan, rstrode   0 weeks ago
brainfuck orphan   0 weeks ago
buildbot  besser82, ignatenkobrain,1 weeks ago
  limb, ngompa, orphan, radez,
  smilner
cairo-clock   orphan   0 weeks ago
code-editor   orphan   1 weeks ago
compton   orphan   1 weeks ago
converseenorphan   1 weeks ago
cups-bjnp orphan   1 weeks ago
curlpporphan   0 weeks ago
dmz-cursor-themes company, orphan  1 weeks ago
docker-composelsm5, orphan, ttomecek   1 weeks ago
ejabberd  bowlofeggs, jcline, orphan,  0 weeks ago
  xavierb
enchant   orphan   0 weeks ago
erlang-epgsql lkundrak, orphan 1 weeks ago
eurekaorphan   0 weeks ago
fcitx cheeselee, cicku, orphan, pwu,   1 weeks ago
  yanqiyu
fcitx-chewing cheeselee, orphan, yanqiyu   1 weeks ago
fcitx-cloudpinyin cheeselee, orphan, yanqiyu   1 weeks ago
fcitx-configtool  cheeselee, orphan, yanqiyu   1 weeks ago
fcitx-fbterm   

Re: Headers file in python package

[Miro Hrončok]

On 04. 12. 22 9:51, Mattia Verga wrote:

I'm reviewing the un-retirement ticket of python-nss [1] and rpmlint is 
complaining about header files under the python module directory. The specfile 
is using the %pyproject_save_files macro to get the file list.
I'm unsure if this is a false positive or I must ask the submitter to filter 
out those files in a -devel package...
What do you think?


What is the purpose of the header files? Does the package function without 
them? In that case, I think they shall be completely eliminated, not moved to a 
devel subpackage.


To eliminate them, I would suggest modifying setup.py not to install them at 
all, however looking at it I have no idea how would I do that.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=2133080



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

[rpms/perl-Locale-Codes] PR #20: Update license to SPDX format

[Michal Josef Špaček]

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

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/20
___
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-Locale-Codes] PR #20: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Locale-Codes` that 
you are following:
``
Update license to SPDX format
``

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

CPE Weekly Update for Week 48 of 2022

[Adam P]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
The report could be found at
https://communityblog.fedoraproject.org/cpe-weekly-update-week-48-2022/.

If you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/ or
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop
sending them in 2023.

Regards,
CPE Team
___
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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Miro Hrončok]

On 05. 12. 22 11:03, Vít Ondruch wrote:
It seems that all the mentioned issues are about the (upcoming) stable 
releases. But I think Rawhide is different and maybe overrides does not make a 
sense there.


There are no buildroot overrides for rawhide.

--
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: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump

[Miro Hrončok]

On Fri, Dec 2, 2022 Adam Williamson  wrote:

I may think about having openQA Rawhide update tests enable the
buildroot repo that includes packages from the release tag; this would
make it include packages that have gone 'stable' since the previous
Rawhide compose. I'd have to think if there are any potential drawbacks
to doing that. Ironically, Fedora CI currently does that but is
considering *not* doing it any more due to "unpleasant surprises":
https://pagure.io/fedora-ci/general/issue/376 
 . I'm not sure exactly

what the surprises were, I'll have to look into it.


(Replying to a reply because for some reason I have not received the actual 
email from Adam.)


This is exactly the reason I think the buildroot repo should always be enabled 
for tests and why I am concerned by https://pagure.io/fedora-ci/general/issue/376


--
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: Review Request: ImageMagick7

[Vít Ondruch]

Dne 03. 12. 22 v 17:25 Sérgio Basto napsal(a):

On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote:

On 03/12/2022 00:30, Sérgio Basto wrote:

The proposal now is to keep ImageMagick 6 and make a new package
with
ImageMagick 7 , when we have all applications use only ImageMagick
7,
we move the sources from ImageMagick7 to ImageMagick

I think it would be better to update the ImageMagick package to
version
7 and create a compatibility package ImageMagick6.

Anyone is going to review the package or not ?



If you have provided ImageMagic6 as most of the people suggests, you 
wold not need review at all:


https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/


~~~

Contributors and reviewers MUST follow the Package Review Process 
, 
with the following exceptions:


* The package is being created so that multiple versions of the same 
package can coexist in the distribution (or coexist between EPEL and 
RHEL). The package MUST be properly named according to the naming 
guidelines 
 
and MUST NOT conflict with all other versions of the same package.


~~~


Vít


  
I already explain the situation in the other emails on this thread .


I estimate that I will need about 200 hours to do what your brilliants
minds ask .

And btw, asking to the others to have the work that you maybe don't
have in your packages , is very easy. if I do the compat package and
wait for 200 packages dependency adapt to the change, will be a chaos ,
and I don't like ignore all the tickets opened around it.

ImageMagick-7.0.1-10 was release on 2016-06-07, today is 2022-12-03 so
after 6 Years and 5 Months and 26 Days, we still haven't  any
ImageMagick 7 in Fedora or EL, so or you help me on do it in my way ,
or I won't do it .

That is why package guidelines should be a guide and not all  and not
the all truth rule, when in practice you don't follow it just claim it.






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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Vít Ondruch]

Dne 04. 12. 22 v 20:27 Zbigniew Jędrzejewski-Szmek napsal(a):

On Fri, Dec 02, 2022 at 03:35:31PM -0800, Adam Williamson wrote:

On Sat, 2022-12-03 at 00:14 +0100, Kalev Lember wrote:

On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson 
wrote:


So there's this CI ticket ATM[0] about whether the environment in which
CI tests are run should or should not include and update from the
'buildroot' repo, which contains both:

1. Packages that have been pushed stable since the last time a compose
succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
Branched compose, for stable releases it's an updates compose)
2. Packages that have active buildroot overrides

Thinking about this reminded me again why buildroot overrides are such
a bad idea:
https://pagure.io/fedora-ci/general/issue/376#comment-830638

Buildroot overrides have unpredictable consequences for builds, updates
*and* tests. I really feel like we should consider disallowing them and
requiring all rebases to be done using side tags. Side tags are a
*much* better design that avoids the problem of packages unexpectedly
being built against a buildroot override somebody else submitted, and
means test systems aren't stuck in a bind of not really knowing for
sure what other packages should be installed when testing any given
package.

What does everyone else think? Has the time come? Or is there more we
need to do to make side tags usable for all cases before getting rid of
overrides?


I would say that side tags are almost always the correct tool for ABI
rebuilds. I imagine people who submit global buildroot overrides to handle
a library soname bump are almost always doing it because they haven't
learned the "new" ways of doing it.

I'd go as far as to say that anyone who does ABI rebuilds using global
buildroot overrides are doing it wrong.

However, having said that, I also find buildroot overrides useful. Some
examples:

1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new
version through the freeze, but that includes a library soname bump.

What I would do in that case is submit the GNOME megaupdate to Bodhi, and
also submit the library as a buildroot override to ensure that nothing can
build against the old soname -- I am fairly confident that the GNOME
megaupdate, together with the soname bump makes it to stable first.

2) I need to do a container build and include a new CVE fix (as it's
critical and we need to get fixes out ASAP), but that package build to
include in the container is only in updates-testing.

What I'd do in this case is to submit a buildroot override because
everything that's overridden gets included in container builds. After my
container build is done I'd expire the buildroot override.

3) We've had some "fun" issues with sysprof symbols leaking out from the
GTK stack into other libraries consuming it. This has caused subtle ABI
issues and when working on a fix and to make sure no package can build
against the "wrong" GTK version, I've used buildroot overrides.

4) Compiler issues, with compilers producing broken code.

To test the fixes and make sure packages start using the new fixed versions
ASAP, a buildroot override is often useful.

I could continue with the list but I think you get my point that there are
some cases where it's useful :) However I'd never use buildroot overrides
for soname bump rebuilds; that's what side tags are good for.

Well, hmm.

The examples you provide are definitely interesting. They all
essentially boil down to, well, "I know exactly how this process works
and I'm gonna take advantage of that to achieve the right outcome
behind the scenes".

Yeah, those four examples are very good. But they all can be summed up as
"we need this update that is in updates-testing (or possibly will soon be there)
to apply to all subsequent builds".



It seems that all the mentioned issues are about the (upcoming) stable 
releases. But I think Rawhide is different and maybe overrides does not 
make a sense there.




Vít



  Thus, maybe it would be enough to replace
buildroot overrides with a single switch that says "make this update visible
in the buildroot *now*".

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


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 

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 05, 2022 at 12:05:59AM -0500, Neal Gompa wrote:
> On Mon, Dec 5, 2022 at 12:02 AM Adam Williamson
>  wrote:
> >
> > On Sun, 2022-12-04 at 19:27 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > >
> > > > The examples you provide are definitely interesting. They all
> > > > essentially boil down to, well, "I know exactly how this process works
> > > > and I'm gonna take advantage of that to achieve the right outcome
> > > > behind the scenes".
> > >
> > > Yeah, those four examples are very good. But they all can be summed up as
> > > "we need this update that is in updates-testing (or possibly will soon be 
> > > there)
> > > to apply to all subsequent builds". Thus, maybe it would be enough to 
> > > replace
> > > buildroot overrides with a single switch that says "make this update 
> > > visible
> > > in the buildroot *now*".
> >
> > Isn't that...what a buildroot override *is*, though?
> 
> Yes, but I guess the idea is that the workflow is simplified to allow
> you to submit an update and an override in one go.

Yeah. And also, by "single switch" I really mean "1 bit of information".
I.e. all the additional metadata: description, expiration date, owner, separate 
name
would be gone, replaced with the boolean change that the update is *also* 
visible
in the buildroot as long as its on the way to stable.

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

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Vitaly Zaitsev via devel]

On 05/12/2022 02:36, Demi Marie Obenour wrote:

Can those be fixed?


I doubt. All side tags must be regenerated after each build in it or 
after each global buildroot override, which is a very slow process.


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

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Vitaly Zaitsev via devel]

On 04/12/2022 20:48, Neal Gompa wrote:

I would prefer that*every*  build would automatically generate a side
tag, even if it's a side-tag of one package.


No, please. Koji is already dying with 100 side tags regeneration (check 
my first message in this thread). When there will be 1000+ we will wait 
forever for our builds.


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

Re: Review Request: ImageMagick7

[Vitaly Zaitsev via devel]

On 04/12/2022 20:25, Sérgio Basto wrote:
I don't indent change /usr/bin/convert from ImageMagick6 so probably it 
will /usr/bin/convert-7


Such name change is not a good idea, because /usr/bin/convert and all 
other ImageMagick binaries are used in many scripts and SPECs. You must 
provide symbolic links to unversioned versions.


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