SPDX Office hours

[Miroslav Suchý]

Hello.

the owners of SPDX Change proposal want to have this Change as smooth as 
possible. For this reason we set up Office Hours.

Do you have any questions about SPDX migration?
Do you hesitate about what steps you should take?
How to proceed with your package? We will do our best to help you.
This is intended to be every second week.
Every time in a different time, to match the time of different people in 
different time zones.

The next round will happen on Tuesday 2023-02-28 15:00-16:00 UTC. (16pm CET, 
10am EST)

Google Meet joining info
Video call link: https://meet.google.com/jbz-erzk-btc
Or dial: ‪(CZ) +420 234 610 762‬ PIN: ‪887 372 910‬#

More phone numbers: https://tel.meet/jbz-erzk-btc?pin=6402543107895

Or join via SIP: sip:6402543107...@gmeet.redhat.com


Miroslav

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

Re: questions about requesting new package into official Fedora repository?

[Mattia Verga via devel]

Il 21/02/23 06:27, Robin Lee ha scritto:
> On Tue, Feb 21, 2023 at 11:14 AM Felix Wang  wrote:
>> If I want to packaging a new package into Fedora repository, I did a koji 
>> scratch build, which it failed on some architecture. Is there a minimum  
>> architecture requirement, which builds successfully on some architecture 
>> (like x86_64?), in order to adopt the new package?
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_support
> -robin
>
To further enhance the paragraph of the Packaging Guidelines, I'd like
to add that you, as a packager, should try to find out why the build is
failing on some architecture and try to work out with upstream a fix for
that. Unless, of course, that package is not meant to run on some
architectures or upsteam developer is not interested at all in fixing it.

In the past I had handled successfully some situations like this and
upstream was very collaborative and in the end upstream was happy to
find out some flaws in their code and have their packages successfully
run on "unusual" arches.

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

Re: Help with systemd/cgroup task limits in koji

[Florian Weimer]

* Kevin Fenzi:

> Greetings.
>
> We are running into some anoying limits on koji builds of chromium.
>
> First, since a long time ago, the koji.service file we are using has:
>
> TasksMax=infinity
>
> But yet, chromium was failing, seemingly hitting a task limit.
> "ninja: fatal: posix_spawn: Resource temporarily unavailable"
> in the build and:
> "kernel: cgroup: fork rejected by pids controller in
> /machine.slice/machine-7d12b2e6dcfb4230b04d2c2c0b499171.scope/payload"
> on the builder.
>
> Investigation and some help from folks in the #devel room
> (many thanks glb!)
> Showed that the systemd-nspawn container mock started has:
>
> systemctl show systemd-nspawn@0b3f01a2a8e345a389b30c477812c471
> TasksMax=16384
>
> So, I put in place a:
> /etc/systemd/system/systemd-nspawn@.service.d/override.conf
> with:
>
> [Service]
> TasksMax=infinity
>
> and that seemed to be used for the mock systemd-nspawn containers.
>
> However, the builds with lots of cpus is now failing later with:
>
> Error: spawn /usr/bin/node-18 EAGAIN
>     at Process.ChildProcess._handle.onexit
> (node:internal/child_process:283:19)
>     at onErrorNT (node:internal/child_process:476:16)
>     at processTicksAndRejections (node:internal/process/task_queues:82:21)
> [!] Error: unfinished hook action(s) on exit:
>
> Is there yet another layer here that has another limit?
>
> Is there anything here I can set that says "infinity all the way down' ?
>
> Assistance welcome. I can file a systemd bug, but I am not sure
> this is a bug more than a lack of documentation.

It could be an old kernel bug:

  Task exit is signaled before task resource deallocation, leading to
  bogus EAGAIN errors
  

There have been recent namespace optimizations which introduce a similar
pattern there.  While they improve throughput in many cases, continuous
allocation and deallocation can now fail, even though the program logic
ensures that resources are never exceeded.

Guiseppe, any suggestions how to debug this?

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: questions about requesting new package into official Fedora repository?

[Robin Lee]

On Tue, Feb 21, 2023 at 11:14 AM Felix Wang  wrote:
>
> If I want to packaging a new package into Fedora repository, I did a koji 
> scratch build, which it failed on some architecture. Is there a minimum  
> architecture requirement, which builds successfully on some architecture 
> (like x86_64?), in order to adopt the new package?

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

Re: [Fedora-legal-list] Update on SPDX license id adoption in Fedora

[John Reiser]

On 2/20/23 17:51, Richard Fontana wrote:

If anyone has
suggestions for what form such documentation could take that would be
helpful. :)


Presentation: a .ods spreadsheet with one row per identifiable hunk of software,
with columns: name, version, release, architecture(s), minimum date, maximum 
date,
SPDX license(s) name-and-version (perhaps one column for each applicable 
license.)
Then the user can search, sort, select, print, etc.
The spreadsheet should be additive (cumulative) since its inception;
the user easily can select any combination of desired versions, releases, 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

questions about requesting new package into official Fedora repository?

[Felix Wang]

If I want to packaging a new package into Fedora repository, I did a koji 
scratch build, which it failed on some architecture. Is there a minimum  
architecture requirement, which builds successfully on some architecture (like 
x86_64?), in order to adopt the new package?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedora-legal-list] Update on SPDX license id adoption in Fedora

[Richard Fontana]

On Mon, Feb 20, 2023 at 7:17 PM Jilayne Lovejoy  wrote:

> Let us know if you have any questions or suggestions for improvements. We've 
> had two "office hours" so far with no attendees, but happy to schedule a few 
> more for open discussion or questions!

We've also talked about developing more documentation around help in
determining how packages are licensed (and/or how to
describe/represent how packages are licensed). If anyone has
suggestions for what form such documentation could take that would be
helpful. :)

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

Help with systemd/cgroup task limits in koji

[Kevin Fenzi]

Greetings.

We are running into some anoying limits on koji builds of chromium.

First, since a long time ago, the koji.service file we are using has:

TasksMax=infinity

But yet, chromium was failing, seemingly hitting a task limit.
"ninja: fatal: posix_spawn: Resource temporarily unavailable"
in the build and:
"kernel: cgroup: fork rejected by pids controller in
/machine.slice/machine-7d12b2e6dcfb4230b04d2c2c0b499171.scope/payload"
on the builder.

Investigation and some help from folks in the #devel room
(many thanks glb!)
Showed that the systemd-nspawn container mock started has:

systemctl show systemd-nspawn@0b3f01a2a8e345a389b30c477812c471
TasksMax=16384

So, I put in place a:
/etc/systemd/system/systemd-nspawn@.service.d/override.conf
with:

[Service]
TasksMax=infinity

and that seemed to be used for the mock systemd-nspawn containers.

However, the builds with lots of cpus is now failing later with:

Error: spawn /usr/bin/node-18 EAGAIN
    at Process.ChildProcess._handle.onexit
(node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:476:16)
    at processTicksAndRejections (node:internal/process/task_queues:82:21)
[!] Error: unfinished hook action(s) on exit:

Is there yet another layer here that has another limit?

Is there anything here I can set that says "infinity all the way down' ?

Assistance welcome. I can file a systemd bug, but I am not sure
this is a bug more than a lack of documentation.

Thanks!

kevin


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

Update on SPDX license id adoption in Fedora

[Jilayne Lovejoy]

Thanks to all the package maintainers who have been diligently updating 
their packages to SPDX identifiers! Here are a few interesting stats:


- 160 issues in the Fedora-license-data, which has resulted in 34 new 
license/TOML files being added to the data, and 18 more ready to be 
added 
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?sort=created_date=opened_name%5B%5D=TOML%20file%3A%3Aneeded_page_size=100


- As of the SPDX License List v3.20 release this past week, 40 new 
licenses have been added to the SPDX License List 
https://github.com/spdx/license-list-XML/releases/tag/v3.20
The vast majority of these have been as a result of Fedora's new policy 
(and most of those have been submitted by Richard)


- We continue to improve the documentation for guidance on updating 
existing packages


Related to process, a couple reminders:

Please review the process description for license review 
https://docs.fedoraproject.org/en-US/legal/license-review-process/ and 
make sure you see the process through to the end!


Issue titles in Gitlab: The License Review template does not add a Title 
- if you have a current issue in the Fedora License Data and could 
update the title to "License Review: " that would be 
immensely helpful. If you end up submitting the license to SPDX, 
ensuring the name of the license in the issue is consistent in both 
repos would also be really helpful.


Engage with the SPDX-legal community:  if your license requires 
submission there, helping see that process through. (It is not scalable 
for Richard to submit most of the licenses to SPDX and me to create the 
files for those licenses... :)


We have been implementing labels in the Fedora License Data repo to help 
indicate what is needed next. I think I've caught up on noting in the 
corresponding the ones that have been dealt with on the SPDX side, but 
please check your issues and tag me if I've missed something.


Don't forget the last step: create a MR to add the TOML file to the 
Fedora-license-data!


Let us know if you have any questions or suggestions for improvements. 
We've had two "office hours" so far with no attendees, but happy to 
schedule a few more for open discussion or questions!


Thanks,
Jilayne


___
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 2171943] perl-SNMP-Info-3.92 is available

[bugzilla]

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



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


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

[bugzilla]

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

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



Releases retrieved: 3.92
Upstream release that is considered latest: 3.92
Current version/release in rawhide: 3.89-2.fc38
URL: http://search.cpan.org/dist/SNMP-Info/

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


More information about the service that created this bug can be found at:
https://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/3318/


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


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

[bugzilla]

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



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


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

[bugzilla]

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

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



Releases retrieved: 5.20230220
Upstream release that is considered latest: 5.20230220
Current version/release in rawhide: 5.20230120-1.fc38
URL: http://search.cpan.org/dist/Module-CoreList/

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


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


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

[bugzilla]

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

Bug ID: 2171927
   Summary: perl-CPAN-Perl-Releases-5.20230220 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



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

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2171927
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Ben Beasley]

Your analysis of grpc/grpc-cpp and gtest seems reasonable to me. Thanks for 
having a look at these cases.

– Ben

On Mon, Feb 20, 2023, at 4:28 PM, Gordon Messmer wrote:
> On 2023-02-20 12:57, Ben Beasley wrote:
>> This is one of the C libraries, which have a more conventional integer ABI 
>> version. For the C++ libraries, have a look at the grpc-cpp subpackage. You 
>> will find libraries like:
>>
>> libgrpc++.so.1.48()(64bit)
>
>
> I see.  That also looks like it's compatible with the proposed change.
>
> $ dnf -C repoquery --provides grpc-cpp | fgrep .so.
> libgrpc++.so.1.48
> libgrpc++.so.1.48()(64bit)
> ...
>
> ...where the full path is /usr/lib64/libgrpc++.so.1.48.3.  If the ELF 
> dependency generator truncated the version, it should produce 
> "Requires: 
> libgrpc++.so.1.48()(64bit) >= 1.48", which wouldn't really improve 
> anything for this package, but for this type of package, where all 
> interfaces changes are already visibly breaking changes, maybe there's 
> nothing to be improved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 12:57, Ben Beasley wrote:

This is one of the C libraries, which have a more conventional integer ABI 
version. For the C++ libraries, have a look at the grpc-cpp subpackage. You 
will find libraries like:

libgrpc++.so.1.48()(64bit)



I see.  That also looks like it's compatible with the proposed change.

$ dnf -C repoquery --provides grpc-cpp | fgrep .so.
libgrpc++.so.1.48
libgrpc++.so.1.48()(64bit)
...

...where the full path is /usr/lib64/libgrpc++.so.1.48.3.  If the ELF 
dependency generator truncated the version, it should produce "Requires: 
libgrpc++.so.1.48()(64bit) >= 1.48", which wouldn't really improve 
anything for this package, but for this type of package, where all 
interfaces changes are already visibly breaking changes, maybe there's 
nothing to be improved.

___
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

Note section size too big (was: Re: FTBFS bug filed, build already deleted)

[Julian Sikorski]

Am 20.02.23 um 19:14 schrieb Orion Poplawski:

On 2/20/23 10:46, Fabio Valentini wrote:
On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  
wrote:


Hello,

FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
build [2] has already been deleted. This is not ideal from maintainer
perspective as it effectively is a bug with no info provided whatsoever.
Not to mention being quite wasteful from the resources perspective as
mame builds take quite a while.
While not much can be done now, can we make sure that the mass rebuild
builds do not get garbage collected, or at least the build logs are
saved somewhere? Thanks.


As far as I know, at least some form of truncated build.log used to
get attached when FTBFS bugs were filed after a mass rebuild ... maybe
this time this wasn't possible, because bugs were reported *weeks*
after the mass rebuild?

And I agree, having no logs at all for something that takes a long
time to build is annoying :(


Well, if your package is tracked by koschei (which I highly recommend), 
you likely could get a current build log from there.



Good idea, this allowed me to get further.
I have hit another issue:

error: Recognition of file 
"/builddir/build/BUILDROOT/mame-0.251-3.fc39.x86_64/usr/bin/mame" 
failed: mode 100755 , dynamically linked, interpreter 
/lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=4cb9f6821033586b869d516b865fa1d8e7b8b5f9, for GNU/Linux 
3.2.0 Note section size too big (137005660 > 134217728) (Invalid argument)


I am already building with -g1. What can be done about the error above? 
Thanks!


Best regards,
Julian
___
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: Creating a F37 remix/spin LiveCD without a desktop environment

[Globe Trotter via devel]

Hi Sergio,

Thanks! Yes, slim was retired but I just make my own RPM for F37 locally. It is 
very straightforward and works fine. I would be happy to unretire it if that is 
possible.

But that does not explain to me why the remix does not get created.





On Monday, February 20, 2023 at 03:00:31 PM CST, Sérgio Basto 
 wrote: 





On Mon, 2023-02-20 at 02:28 +, Globe Trotter via devel wrote:
> Hello,
> 
> Since about Fedora 20 or so, I have been rolling my own Fedora spin
> without a desktop environment, and with openbox and slim (simple
> login manager). All worked well, because I did not need to roll these
> that often, with dnf upgrade on existing installations, except up
> until now when I need a new LiveCD for a new machine coming online. I
> last successfully made a LiveCD with Fedora 34. 
> 

I just notice slim package was retired on Fedora 37 

https://src.fedoraproject.org/rpms/slim

HTH 

> Recently, I went back to making a live cd for Fedora 37, and realized
> that there is a new way of handling these: specifically, I have to
> install env-group to resolve RH Bug:1891500.
> 
> With an environment, it turns out one has to do something like
> 
> 
> @^lxde-desktop-environment
> 
> but I do not want an environment. 
> 
> I tried putting this in, and removing all the LXDE things
> 
> -@'Dial-up Networking Support'
> -@LXDE
> -@Fonts
> -@'LXDE Desktop'
> -@'Multimedia'
> -@base-x 
>    
> -@core
> -@fonts
> -@'Guest Desktop Agents'
> -@'Input Methods'
> -@'Printing'
> -@'Hardware Support'
> -lxpanel
> -lxlauncher
> -libfm
> -menu-cache
> -pcmanfm
> -lxde-common
> 
> and this works, but not quite. I still get large components of the 
> LXDE environment, slim (which I roll my personal rpm of) does not get
> started, and I get a slower system. 
> I tried explicitly getting rid of the following that I could see:
> 
> -clipit
> -galculator
> -dnfdragora
> -dnfdragora-updater
> -xpad
> -icon
> -xarchiver
> -xscreensaver
> -gigolo
> -samba\*
> -firewall-config
> -firewalld
> -lx\*
> 
> but still, there are lx\* things in the LiveCD. 
> 
> Can I get a LiveCD environment without all this, and with slim? 
> 
> 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

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
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: Creating a F37 remix/spin LiveCD without a desktop environment

[Sérgio Basto]

On Mon, 2023-02-20 at 02:28 +, Globe Trotter via devel wrote:
> Hello,
> 
> Since about Fedora 20 or so, I have been rolling my own Fedora spin
> without a desktop environment, and with openbox and slim (simple
> login manager). All worked well, because I did not need to roll these
> that often, with dnf upgrade on existing installations, except up
> until now when I need a new LiveCD for a new machine coming online. I
> last successfully made a LiveCD with Fedora 34. 
> 

I just notice slim package was retired on Fedora 37 

https://src.fedoraproject.org/rpms/slim

HTH 

> Recently, I went back to making a live cd for Fedora 37, and realized
> that there is a new way of handling these: specifically, I have to
> install env-group to resolve RH Bug:1891500.
> 
> With an environment, it turns out one has to do something like
> 
> 
> @^lxde-desktop-environment
> 
> but I do not want an environment. 
> 
> I tried putting this in, and removing all the LXDE things
> 
> -@'Dial-up Networking Support'
> -@LXDE
> -@Fonts
> -@'LXDE Desktop'
> -@'Multimedia'
> -@base-x 
>    
> -@core
> -@fonts
> -@'Guest Desktop Agents'
> -@'Input Methods'
> -@'Printing'
> -@'Hardware Support'
> -lxpanel
> -lxlauncher
> -libfm
> -menu-cache
> -pcmanfm
> -lxde-common
> 
> and this works, but not quite. I still get large components of the 
> LXDE environment, slim (which I roll my personal rpm of) does not get
> started, and I get a slower system. 
> I tried explicitly getting rid of the following that I could see:
> 
> -clipit
> -galculator
> -dnfdragora
> -dnfdragora-updater
> -xpad
> -icon
> -xarchiver
> -xscreensaver
> -gigolo
> -samba\*
> -firewall-config
> -firewalld
> -lx\*
> 
> but still, there are lx\* things in the LiveCD. 
> 
> Can I get a LiveCD environment without all this, and with slim? 
> 
> 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

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Ben Beasley]

On Mon, Feb 20, 2023, at 3:12 PM, Gordon Messmer wrote:
> On 2023-02-20 11:32, Ben Beasley wrote:
>> The grpc C++ libraries have CMake SOVERSION e.g. “1.48” for the 1.48.x minor 
>> release. There is no attempt at ABI compatibility across minor releases, and 
>> the entire string “1.48” is effectively a major version for ABI purposes. 
>> The “patch” relases of grpc only change internal implementation details. 
>> This approach is fairly common in C++ projects.
>
>
> I'm finding it difficult to fully follow the path through grpc's build 
> system, but it looks like the soname matches the "major" component of 
> "CORE_VERSION":
>
> https://github.com/grpc/grpc/blob/v1.48.0/Makefile
>
> $ dnf -C repoquery --provides grpc | grep libgrpc.so
> libgrpc.so.26()(64bit)
>
> ...where the full path is: /usr/lib64/libgrpc.so.26.0.0
>
> All of that seems compatible with the proposal, regardless of whether we 
> use the full version string or truncate it.

This is one of the C libraries, which have a more conventional integer ABI 
version. For the C++ libraries, have a look at the grpc-cpp subpackage. You 
will find libraries like:

libgrpc++.so.1.48()(64bit)
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 11:32, Ben Beasley wrote:

The grpc C++ libraries have CMake SOVERSION e.g. “1.48” for the 1.48.x minor 
release. There is no attempt at ABI compatibility across minor releases, and 
the entire string “1.48” is effectively a major version for ABI purposes. The 
“patch” relases of grpc only change internal implementation details. This 
approach is fairly common in C++ projects.



I'm finding it difficult to fully follow the path through grpc's build 
system, but it looks like the soname matches the "major" component of 
"CORE_VERSION":


https://github.com/grpc/grpc/blob/v1.48.0/Makefile

$ dnf -C repoquery --provides grpc | grep libgrpc.so
libgrpc.so.26()(64bit)

...where the full path is: /usr/lib64/libgrpc.so.26.0.0

All of that seems compatible with the proposal, regardless of whether we 
use the full version string or truncate it.




The gtest library uses the entire project version number for the CMake 
SOVERSION, so the library for gtest/gmock 1.13.0 is “1.13.0”; this entire 
string is effectively a major version for the ABI. This is appropriate because 
upstream does not concern itself with ABI stability at all, so even patch 
updates must be considered to break the ABI. This is an even more common 
approach in C++-land



$ dnf -C repoquery --provides gtest | fgrep .so.
Last metadata expiration check: 1:12:51 ago on Mon 20 Feb 2023 10:57:22 
AM PST.

libgtest.so.1.12.1
libgtest.so.1.12.1()(64bit)
libgtest_main.so.1.12.1
libgtest_main.so.1.12.1()(64bit)

In their case, any change to the version number is a breaking change, 
both today and after the proposed change, so this seems fine.

___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

As there is some discussion of whether the ELF dependency generator 
should use the full version string presented by the library file name's 
suffix, or should assume a SemVer-style major.minor and truncate the 
requirement to the first two dot-separated numbers, questions about 
rpminspect come to mind:


I see that rpminspect is run in Fedora CI for updates.  For example, 
libnghttp2:


https://bodhi.fedoraproject.org/updates/FEDORA-2022-888dfc8170
https://artifacts.dev.testing-farm.io/627326f9-7f83-4d0b-aca0-68c50c5e9b09/

Looking at this result, I think I see one bug and one RFE.

First, the bug.  From these results, it looks like rpminspect is only 
comparing the primary package to the old build.  I do see a result for 
the package "nghttp2", but I don't see an rpminspect result for 
"libnghttp2".  Are sub-packages not tested, or are the results simply 
not exposed?  (Or am I simply missing the path to find them?)


Second, the RFE: I am assuming that this test raises an error if abidiff 
reports a breaking change between two packages (either a bumped soname, 
or a removed or changed symbol without an soname bump.)  In order to 
make the ELF dependency generator reliable if it truncates versions to a 
major.minor style version, would it be possible for the tooling to 
detect a backward-compatible change (a new symbol) that didn't also 
increment the major.minor version?


Should I report those in bugzilla, and if so, against what component?
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Ben Beasley]

The grpc C++ libraries have CMake SOVERSION e.g. “1.48” for the 1.48.x minor 
release. There is no attempt at ABI compatibility across minor releases, and 
the entire string “1.48” is effectively a major version for ABI purposes. The 
“patch” relases of grpc only change internal implementation details. This 
approach is fairly common in C++ projects.

The grpc C libraries use a single integer that is bumped on some but not all 
minor releases. The CMake-based build system does not implement the 
libtool-style “age” semantics.

The gtest library uses the entire project version number for the CMake 
SOVERSION, so the library for gtest/gmock 1.13.0 is “1.13.0”; this entire 
string is effectively a major version for the ABI. This is appropriate because 
upstream does not concern itself with ABI stability at all, so even patch 
updates must be considered to break the ABI. This is an even more common 
approach in C++-land. See flatbuffers for another example of this.

On Mon, Feb 20, 2023, at 1:44 PM, Gordon Messmer wrote:
> On 2023-02-20 02:16, Daniel P. Berrangé wrote:
>> You mention 'libtool' multiple times through this thread. libtool
>> defines specific semantics for 3 digits in the version number.
>> Not all shared libraries are built with libtool, and even those
>> which did use libtool didn't neccesarily apply libtool's semantics.
>>
>> Possibly this proposal works fine regardless ? In fact, presumably it
>> must, otherwise its going to break stuff.
>>
>> If so, then I'd suggest removing references to libtool and describing
>> directly what kind of versions it looks for and what it does with them.
>
>
> Yes, the naming of things is a question I raised in the PR.  I'm open to 
> suggestions.  :)
>
> I'm also interested in looking at examples of non-libtool behavior, 
> since I'm proposing that we enforce versioning semantics where they have 
> not been enforced in the past.  Can we find libraries that provide only 
> two dot-separated numbers?  What about more than three?  Can we treat 
> the first two as major.minor, or do we have examples where "minor" is 
> evidently a later number in the set?
>
> The currently open PR will only generate a versioned dependency if the 
> library's real name ends in ".so." followed by numbers and dots.  If 
> there's a letter (e.g. libssl.so.1.1.1q), it doesn't get a version.  
> Mostly because:
>
> $ rpmdev-vercmp 1.2.3git 1.2.3
> 1.2.3git > 1.2.3
>
> Is 1.2.3git a release from git leading up to 1.2.3, or is it a release 
> after 1.2.3 with fixes from git?
>
> How should maintainers handle packages where libraries have versions 
> that don't conform to the semantics we want?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 02:06, Petr Pisar wrote:

I applaud the struggle for ensuring compatibility. However, I worry that it
will make downgrading RPM packages less feasible. Imagine a user who updates
a system, finds a regression in a library, attempts to downgrade the library
and it will result into downgrading later-built reverse dependencies only
because the library applied a (wrong) fix and the triplet has changed.

Do you know meaning of the numbers?



I will say that there are bits that I do not understand:

https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

The documentation describes a system in which the library indicates the 
first interface version it supported, and the latest interface version 
it supports, as well as a revision counter that indicates changes in the 
source that do not change the interface. As far as I can tell, this 
manifests in a file name that ends in ".so.$(current - 
age).$(age).$(revision)", which seems like a complicated way to arrive 
at Semantic Versions.  I don't know if "current" and "age" appear in the 
ELF headers.


I'm sympathetic to the idea that providing the entire version number is 
more strict than is necessary, but I'm not sure under what circumstances 
it is safe to provide less.  Are there cases where the version number is 
more or less than three dot-separated number sequences?  If we always 
truncate to two, is that the correct thing to do for both versions with 
only two numbers and for versions with more than three numbers?



___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 10:01, Richard W.M. Jones wrote:

Does it have to be something which looks so much like it might be a
version number?  For example it could be helpful for debugging if the
generated requires was something like:

   Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1



You mean the literal string "soname", right?  I don't know a reason that 
wouldn't work off the top of my head, but I also can't think of a reason 
that it would add information that wasn't inferred in the current 
iteration.  One reason we might want to stick with something that looks 
like a version is that we might need to extend the system to allow an 
epoch in the future (though I really hope that isn't necessary.)

___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 02:16, Daniel P. Berrangé wrote:

You mention 'libtool' multiple times through this thread. libtool
defines specific semantics for 3 digits in the version number.
Not all shared libraries are built with libtool, and even those
which did use libtool didn't neccesarily apply libtool's semantics.

Possibly this proposal works fine regardless ? In fact, presumably it
must, otherwise its going to break stuff.

If so, then I'd suggest removing references to libtool and describing
directly what kind of versions it looks for and what it does with them.



Yes, the naming of things is a question I raised in the PR.  I'm open to 
suggestions.  :)


I'm also interested in looking at examples of non-libtool behavior, 
since I'm proposing that we enforce versioning semantics where they have 
not been enforced in the past.  Can we find libraries that provide only 
two dot-separated numbers?  What about more than three?  Can we treat 
the first two as major.minor, or do we have examples where "minor" is 
evidently a later number in the set?


The currently open PR will only generate a versioned dependency if the 
library's real name ends in ".so." followed by numbers and dots.  If 
there's a letter (e.g. libssl.so.1.1.1q), it doesn't get a version.  
Mostly because:


$ rpmdev-vercmp 1.2.3git 1.2.3
1.2.3git > 1.2.3

Is 1.2.3git a release from git leading up to 1.2.3, or is it a release 
after 1.2.3 with fixes from git?


How should maintainers handle packages where libraries have versions 
that don't conform to the semantics we want?

___
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: FTBFS bug filed, build already deleted

[Fabio Valentini]

On Mon, Feb 20, 2023 at 7:15 PM Orion Poplawski  wrote:
>
> On 2/20/23 10:46, Fabio Valentini wrote:
> > On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  wrote:
> >>
> >> Hello,
> >>
> >> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> >> build [2] has already been deleted. This is not ideal from maintainer
> >> perspective as it effectively is a bug with no info provided whatsoever.
> >> Not to mention being quite wasteful from the resources perspective as
> >> mame builds take quite a while.
> >> While not much can be done now, can we make sure that the mass rebuild
> >> builds do not get garbage collected, or at least the build logs are
> >> saved somewhere? Thanks.
> >
> > As far as I know, at least some form of truncated build.log used to
> > get attached when FTBFS bugs were filed after a mass rebuild ... maybe
> > this time this wasn't possible, because bugs were reported *weeks*
> > after the mass rebuild?
> >
> > And I agree, having no logs at all for something that takes a long
> > time to build is annoying :(
>
> Well, if your package is tracked by koschei (which I highly recommend),
> you likely could get a current build log from there.

True, but that doesn't help if the failure occurred on s390x or i686,
which aren't tracked in koschei.

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

Re: FTBFS bug filed, build already deleted

[Kevin Fenzi]

On Mon, Feb 20, 2023 at 06:46:31PM +0100, Fabio Valentini wrote:
> On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  wrote:
> >
> > Hello,
> >
> > FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> > build [2] has already been deleted. This is not ideal from maintainer
> > perspective as it effectively is a bug with no info provided whatsoever.
> > Not to mention being quite wasteful from the resources perspective as
> > mame builds take quite a while.
> > While not much can be done now, can we make sure that the mass rebuild
> > builds do not get garbage collected, or at least the build logs are
> > saved somewhere? Thanks.
> 
> As far as I know, at least some form of truncated build.log used to
> get attached when FTBFS bugs were filed after a mass rebuild ... maybe
> this time this wasn't possible, because bugs were reported *weeks*
> after the mass rebuild?

yes, thats exactly why.

> And I agree, having no logs at all for something that takes a long
> time to build is annoying :(

Sorry about that. ;( 

kevin


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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Kevin Fenzi]

On Sun, Feb 19, 2023 at 01:33:33PM -0800, Gordon Messmer wrote:
> On 2023-02-19 12:30, Stephen Smoogen wrote:
> > 
> > > - You mention "over the course of two releases" but don't
> > mention what
> > >    is done in each one?
> > 
> > I don't know the specifics of how package builds are ordered in a
> > mass
> > rebuild, so I tend to think the safest rollout is a slow one:
> > enable the
> > 
> > 
> > I think they are usually done 'alphabetically' with various subgroups
> > done in 'order by the maintainer' beforehand (or afterwards if the mass
> > rebuild broke it) as additional side-tags.

Yes, mass rebuild is done in a-z order in a rebuild side tag. None of
the builds update the buildroot, they just inherit the normal rawhide
buildroot.

> If there's no dependency ordering in the mass rebuild, then I think the
> shortest possible timeline for enabling both macros would be to enable
> _elf_provide_fallback_versions globally, wait for the next mass rebuild, and
> then globally enable the _elf_require_fallback_versions macro.  At that
> point, dependencies should have been made consistent by the mass rebuild,
> and improved dependency information should be generated as it's needed (as
> packages are built after the mass rebuild).
> 
> However, FTBFS very probably means that a short timeline like that would be
> difficult, as once _elf_require_fallback_versions was enabled globally any
> packages that depend on something that didn't rebuild would need to be opted
> out of the system temporarily by disabling _elf_require_fallback_versions in
> their spec file.  So, it might be preferable to roll out that half of the
> system later.

Right, mass rebuild doesn't mean everything is rebuilt, but most things
are. 

kevin


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

Re: FTBFS bug filed, build already deleted

[Orion Poplawski]

On 2/20/23 10:46, Fabio Valentini wrote:

On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  wrote:


Hello,

FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
build [2] has already been deleted. This is not ideal from maintainer
perspective as it effectively is a bug with no info provided whatsoever.
Not to mention being quite wasteful from the resources perspective as
mame builds take quite a while.
While not much can be done now, can we make sure that the mass rebuild
builds do not get garbage collected, or at least the build logs are
saved somewhere? Thanks.


As far as I know, at least some form of truncated build.log used to
get attached when FTBFS bugs were filed after a mass rebuild ... maybe
this time this wasn't possible, because bugs were reported *weeks*
after the mass rebuild?

And I agree, having no logs at all for something that takes a long
time to build is annoying :(


Well, if your package is tracked by koschei (which I highly recommend), 
you likely could get a current build log from there.


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 03:08, Florian Weimer wrote:

* Gordon Messmer:

As you noted at the end of your message, that would involve querying
the rpm DB from the ELF dependency generator, which the rpm
maintainers want to avoid.

Not really.  We could dump an extract of the RPM database to a text file
at the start of the build, after the dependencies have been installed.



Setting aside the mechanics of rpm db access for the moment:

My initial suggestion for this work *was* to use the rpm package 
version.  One of the advantage that I see to that approach is that rpm 
versions have really well defined semantics, including an "epoch" if we 
need to reset version ordering for a given package for some reason.


However, one of the major down sides to this is that it makes swappable 
/ compatibility libraries much harder to support.  In the rpm PR, Neal 
provided the examples of SDL/sdl12-compat and 
jack-audio-connection-kit/pipewire-jack-audio-connection-kit. Ideally, 
as long as those packages provide the same interface, users should be 
able (or should have been able) to install either option.  If we use the 
rpm package versions, that seems a little more difficult.  As far as I 
can tell, rpm sub-packages can have version numbers distinct from the 
primary package, so I would *guess* that it's possible for maintainers 
to coordinate packaging those individual libraries in a package whose 
version was the library's interface version rather than the source 
package's release version.


This seems like a more complex approach, but might be worth further 
discussion...

___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Richard W.M. Jones]

On Mon, Feb 20, 2023 at 06:01:12PM +, Richard W.M. Jones wrote:
> On Sat, Feb 18, 2023 at 04:21:55PM -0800, Gordon Messmer wrote:
> > On  2023-02-18 15:53, Fabio Valentini wrote:
> > >I see a big hole in that problem (assuming that I understand
> > >Things correctly): What happens to packages where this .so.x.y.z
> > >pattern does not match their actual version?
> > 
> > In this implementation, there is no relationship between the version
> > of the shared object and the package version.
> > 
> > libnghttp2-1.51.0-1.fc37, for example, will "Provides:
> > libnghttp2.so.14()(64bit) = 14.24.1", and any package that is linked
> > to that shared object will "Requires: libnghttp2.so.14()(64bit) >=
> > 14.24.1"
> 
> Does it have to be something which looks so much like it might be a
> version number?  For example it could be helpful for debugging if the
> generated requires was something like:
> 
>   Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1
> 
> or:
> 
>   Requires: libnghttp2.so.14()(64bit)(soname) >= 14.24.1
> 
> (if that is possible)

BTW I think the proposal overall is great, and solves a real problem
I've encountered often.

Rich.

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Richard W.M. Jones]

On Sat, Feb 18, 2023 at 04:21:55PM -0800, Gordon Messmer wrote:
> On  2023-02-18 15:53, Fabio Valentini wrote:
> >I see a big hole in that problem (assuming that I understand
> >Things correctly): What happens to packages where this .so.x.y.z
> >pattern does not match their actual version?
> 
> In this implementation, there is no relationship between the version
> of the shared object and the package version.
> 
> libnghttp2-1.51.0-1.fc37, for example, will "Provides:
> libnghttp2.so.14()(64bit) = 14.24.1", and any package that is linked
> to that shared object will "Requires: libnghttp2.so.14()(64bit) >=
> 14.24.1"

Does it have to be something which looks so much like it might be a
version number?  For example it could be helpful for debugging if the
generated requires was something like:

  Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1

or:

  Requires: libnghttp2.so.14()(64bit)(soname) >= 14.24.1

(if that is possible)

Rich.

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Petr Pisar]

V Mon, Feb 20, 2023 at 11:04:43AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Feb 20, 2023 at 11:06:10AM +0100, Petr Pisar wrote:
> > V Sat, Feb 18, 2023 at 09:20:20AM -0800, Gordon Messmer napsal(a):
> > > For shared libraries without versioned symbols, the provides will change
> > > from:
> > > 
> > >   Provides: libnghttp2.so.14()(64bit)
> > > 
> > > to:
> > > 
> > >   Provides: libnghttp2.so.14()(64bit) >= 14.24.1
> > > 
> > > ... while requirements on that package will change from:
> > > 
> > >   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
> > >   Requires: libnghttp2.so.14()(64bit)
> > > 
> > > to:
> > > 
> > >   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
> > >   Requires: libnghttp2.so.14()(64bit) >= 14.24.1
> > > 
> > [...]
> > > Dependencies are generated using dlmopen() to locate a required library
> > > named in an ELF header, and then resolving the symlink to a full path. If
> > > the full path ends in ".so.x.y.z", where "x.y.z" is a series of numbers
> > > separated by dots, then the numbers and dots suffix is treated as a 
> > > version
> > > number for that library.
> > > 
> > I applaud the struggle for ensuring compatibility. However, I worry that it
> > will make downgrading RPM packages less feasible. Imagine a user who updates
> > a system, finds a regression in a library, attempts to downgrade the library
> > and it will result into downgrading later-built reverse dependencies only
> > because the library applied a (wrong) fix and the triplet has changed.
> > 
> > Do you know meaning of the numbers? I only guess that the first number
> > tracks incompatible changes, the second number tracks added interfaces and 
> > the
> > last number tracks interface-irrelevant changes (fixes usually).
> 
> Such use is what the libtool docs and other guidelines recommend.
> 
> > Provided my guess is correctm would it make sense to exclude the last number
> > from the RPM dependencies? I.e.  libnghttp2.so.14.24.1 library file name 
> > would
> > produce "libnghttp2.so.14()(64bit) >= 14.24" dependency. This less strict
> > approach would provide users a freedom to downgrade/upgrade libaries without
> > changes in the interface.
> 
> This is true, with this proposal implemented in full, the user will be forced 
> to
> install at least the same .x.y.z versions of dependecies as that against which
> the package was built. This is limiting to some extent, but I think the 
> overall
> quality will be higher.
> 
> Note that the .z number reflects "fixes". When the package is built against 
> that
> version, it is also *tested* against that version. Configuration-time tests,
> tests in %check, and autoqa / CI tests would all be done against that version,
> and since testers who have updates-testing enabling would also generally 
> install
> the full package set, so they would also usually test the latest versions of
> all dependencies. I don't think we want to test against the latest version 
> with
> all the fixes but then provide a much looser version dependency for users.
> If the upsteam is doing a good job, higher .z numbers should be stricly better
> than the lower ones.
> 
That's all true, but I as a user do not want trade-offs.

Imagine a library and an application which uses the library. Both get fixed,
but for independent reasons: The library for an miniscule bug, the application
for a security bug.  After the upgrade, a regression is found in the library
which prevents the user from using the application. Now the user stands in
front of a dilemma: Should he downgrade both library and the application to
get his system working again, but becoming vulnerable, or should he keep it
malfcuntioned and waiting on an upstream fix? Consider that delivering the fix
can take weeks. Without the overstrict versioning the user would simply
downgrade the library, his system would stay safe and functioning.

Another example is bisecting build root when locating a regression causeing
a build/test failure. The proposed one-way compatibily will unnecessarily
complicate it: Instead of simply downgrading changed packages, you will be, in
addition, forced to rebuild all reverse dependencies.

For me it sound like throwing out a baby with the bath water.

-- Petr


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

Re: FTBFS bug filed, build already deleted

[Fabio Valentini]

On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  wrote:
>
> Hello,
>
> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> build [2] has already been deleted. This is not ideal from maintainer
> perspective as it effectively is a bug with no info provided whatsoever.
> Not to mention being quite wasteful from the resources perspective as
> mame builds take quite a while.
> While not much can be done now, can we make sure that the mass rebuild
> builds do not get garbage collected, or at least the build logs are
> saved somewhere? Thanks.

As far as I know, at least some form of truncated build.log used to
get attached when FTBFS bugs were filed after a mass rebuild ... maybe
this time this wasn't possible, because bugs were reported *weeks*
after the mass rebuild?

And I agree, having no logs at all for something that takes a long
time to build is annoying :(

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

FTBFS bug filed, build already deleted

[Julian Sikorski]

Hello,

FTBFS bug was filed against mame [1]. Unfortunately, the corresponding 
build [2] has already been deleted. This is not ideal from maintainer 
perspective as it effectively is a bug with no info provided whatsoever. 
Not to mention being quite wasteful from the resources perspective as 
mame builds take quite a while.
While not much can be done now, can we make sure that the mass rebuild 
builds do not get garbage collected, or at least the build logs are 
saved somewhere? Thanks.


Best regards,
Julian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2171602
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=96377011
___
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] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa  wrote:

> On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson  wrote:
> >
> > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  wrote:
> >>
> >> Hi Troy,
> >>
> >> On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
> >> > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
> >> > epel-devel@lists.fedoraproject.org> wrote:
> >> >
> >> > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
> >> > > > I think this whole process should be automated. File bugs that say
> >> > > > "Heads up:
> >> > > > your package will be automatically retired after the release of
> RHEL
> >> > > > X.X" and
> >> > > > provide some explanation.
> >> > >
> >> > > Agreed. This is a pretty mechanical process: all the maintainer
> would
> >> > > do is run "fedpkg retire" for the appropriate branches, and that
> looks
> >> > > reasonable to automate. If we're concerned about bugs in the
> automation
> >> > > retiring packages that shouldn't be impacted, we can have it file a
> >> > > ticket for signoff on the EPEL tracker (or have some other process
> to
> >> > > spot check, at least until we're confiden it'll do the right thing).
> >> > >
> >> >
> >> > Sorry for delaying this for so long. Things came up, but now I have
> some
> >> > time.
> >> >
> >> > I think step one in this automation workflow is to not assign the
> bugs to
> >> > the package at all.
> >> > Assign the bugs to EPEL / distribution, but keep them as blockers on
> the
> >> > EPEL2RHEL tracker[1].
> >> > This gets rid of the busy maintainer problem.  Where they just read
> the
> >> > subject and do what it says.
> >> > This also allows the automation to not have to deal with all the
> different
> >> > packages.
> >>
> >> I'm not sure filling against distribution is a good idea. I'd just file
> >> bugs against the affected component, set the bug assignee to yourself,
> >> and close it once you preform the automatic retirement. This way, you
> >> won't have to worry about CCing the proper maintainer on the
> >> distribution bug and the bugs will be more organized. The subject is a
> >> separate problem.
> >>
> >> > I think for the automation to happen, we also have to get the subject
> line
> >> > updated.
> >> > If we can get it to have what release is in it, parsing the subject
> line is
> >> > much easier than going through all the bugzilla comments trying to
> find
> >> > what release this is supposed to come out in.
> >> > Something like "Remove yara from epel8 when RHEL 8.7 is released"
> >>
> >> I'd prefer something like the originally suggested "Notice: PACKAGE_HERE
> >> will be automatically retired in RHEL X.X" so it's clear that
> >> maintainers don't need to take manual action.
> >
> >
> > That is a good point.
> >
> > On a related note.
> > For the past month or so, as new packages get added to the tracker I've
> been manually adding a comment that the package shouldn't be retired until
> (date) which is when (release) will come out.  That has usually been May
> 2023 when RHEL 8.8 / 9.2 comes out.
> > Several of the maintainers have thanked me for the clarification.
> > I've been doing this mainly so I can get a feel for what the script
> should be doing.  But one thing came up that I don't have an answer to.
> >
> > I haven't said "We will automatically retire this for you" because I
> don't know who "we" is/are.
> > Is it the committee?  (could be, that seems the most likely)
> > Is it the epel-packagers-sig? (I don't think that's right.)
> > Is it a different "retirement group"?
> >
> > Thoughts?
>
> It should probably be done by automation, not a person.
>

That scares me more than anything.
There are so many things that can go wrong when checking if a package is in
the repo.
The script I was planning on writing would send a list of packages to be
removed somewhere and then someone would manually remove them.

Troy
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

Builds are starting now.

On Thu, Feb 16, 2023 at 9:54 AM Thomas Rodgers  wrote:

> We expect to start rebuilds for
> https://fedoraproject.org/wiki/Changes/F39Boost181
> in the f39-boost side tag Monday 2022-02-20.
>
> If your package depends on Boost, or just if you see a "Rebuilt for
> Boost 1.81" commit pushed to your package's dist-git repo, please
> coordinate with me about any updates to the package. If you need
> to push other changes to rawhide then you will need to build in the
> side tag, or we'll have to rebuild it multiple times.
>
> I expect to complete the builds and request the merge of the f39-boost
> side tag by Friday 2022-02-24.
>
>
>
___
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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-02-20)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 15:00:22 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting/2023-02-20/flatpak-sig.2023-02-20-15.00.log.html
.



Meeting summary
---
* Init process  (kalev, 15:00:22)

* Announcements  (kalev, 15:03:47)
  * 15 new flatpaks added over the last two weeks, thanks to yselkowitz
(14) and pwalter (1)  (kalev, 15:03:58)
  * LINK: https://bodhi.fedoraproject.org/releases/F37F has all the
updates  (kalev, 15:04:04)
  * xberry has a fork of flatpak-module-tools to merge in the parts of
fedmod we need   (kalev, 15:04:06)
  * LINK:

https://pagure.io/fork/xberry/flatpak-module-tools/c/1f7eeb562a72aae60e53babc3935ddb6eca54043?branch=master
(kalev, 15:04:09)
  * Allan created a gitlab repo where we can track flatpak-specific
issues: https://gitlab.com/fedora/sigs/flatpak  (kalev, 15:04:12)
  * xberry will also work on porting the "to be bundled" fedmod from
libmodulemd to libmodulemd v2  (tpopela[m], 15:05:51)
  * LINK:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/7 is
blocking a few apps  (AllanDay[m], 15:06:49)

* Policy for app id discrepencies  (kalev, 15:07:27)
  * LINK:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/7
(kalev, 15:07:30)
  * LINK: https://docs.fedoraproject.org/en-US/packaging-guidelines/ is
the packaging guidelines that I refer to  (kalev, 15:16:40)

* timeframe for migrating to f38  (kalev, 15:36:19)
  * LINK: https://wiki.gnome.org/FortyFour has the gnome schedule and
44.0 is March 18  (kalev, 15:47:35)

Meeting ended at 16:00:10 UTC.




Action Items






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




People Present (lines said)
---
* kalev (109)
* travier (46)
* zodbot (13)
* yselkowitz[m] (12)
* AllanDay[m] (9)
* tpopela[m] (7)
* chromebittin (6)
* ssmoogen (5)
* rishi[m] (4)
* sberg_ (3)




Generated by `MeetBot`_ 0.4

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

[Bug 2171353] /usr/lib/rpm/perl.req create bogus requirements on usage function of dpkg-source.pl

[bugzilla]

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



--- Comment #3 from Sergio Basto  ---
to checkout you may run :

fedpkg clone dpkg 
cd dpkg
git reset HEAD~1 --hard # to remove my hack 
fedpkg prep
/usr/lib/rpm/perl.req dpkg-1.21.20/scripts/dpkg-source.pl


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2171353
___
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 2171353] /usr/lib/rpm/perl.req create bogus requirements on usage function of dpkg-source.pl

[bugzilla]

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



--- Comment #2 from Sergio Basto  ---
I tried yesterday without success fixed the regexp , adding more one simple
rule, lines or comnand must be ended with semi-colon (;) ,
if you can add this rule it will fix my case !


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2171353
___
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: SIG status, visibility, etc. [Re: Risc-V SIG?

[Jun Aruga (he / him)]

> I am big fan of using FAS for SIG membership:
>
> https://fedoraproject.org/wiki/SIGs/Ruby#Members
>
> Not that we would did some cleanup of that group, but in theory, the
> inactive members could be removed easier then just editing some random
> wiki page.

I am sure that maintaining members of a SIG by FAS (Fedora account
system) is convenient and effective when giving the permission to do
"git push" to the necessary dist-git repositories related to the SIG.
It's especially convenient for a matured SIG which has a broad
ecosystem of packages like Ruby SIG. I don't intend to deny the
current operations.

> If anyone is interested in tackling this, I'd love to hear your thoughts
(either now, or save them up for when we get to planning the details of that
part of the strategy).

I remember how I started to engage (deal) with special interest groups
in Reddit. I think Fedora might be inspired by Reddit. I think Reddit
is a collection of special interest groups. Users connect by their
interesting themes. Once a user creates an account in Reddit, joining
or leaving a group is easy, just clicking the "Join" or "Leave"
button. Admins of the groups don't need to manage the list of the
members. I remember my engagement started just by asking a question or
commenting on someone's question. So, why did I want to ask a question
on Reddit? Because the topic to ask questions is very niche, and I
didn't know any other places to ask questions casually.

In the case of the early phase of the SIGs, perhaps we can simplify
the process to join the places (groups) to ask questions for a
specific themes/topics.

My proposal is to create categories for SIGs on Fedora Discussion if they want.
https://discussion.fedoraproject.org/

Jun




-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 2171353] /usr/lib/rpm/perl.req create bogus requirements on usage function of dpkg-source.pl

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Jitka Plesnikova  ---
perl-req is able to skip 
* the here-docs "<<" blocks
* q{} quoted sections
* documentation
* assign statements with multiline string
* multiline print

For multiline print, it expects `print` and `"` or `'`. It is not so easy cover
each user defined function e.g. `g_`.

perl-generators tries to filter as many lines as possible, but it can't filter
everything what we need.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2171353
___
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: Creating a F37 remix/spin LiveCD without a desktop environment

[Globe Trotter via devel]

I put the following here, in case anyone wants to take a look. The LiveCD 
formed does not boot.


fpaste fedora-shunya-common.ks
Uploading (3.7KiB)...
https://paste.centos.org/view/529252f8


$ fpaste fedora-live-shunya-37.ks
Uploading (3.2KiB)...
https://paste.centos.org/view/b73160cd

I also put the old one that used to work at least with F34 here:


$ fpaste fedora-live-shunya-old.ks
Uploading (3.3KiB)...
https://paste.centos.org/view/34c9dfe3

This has the same effect as the new one. At least, that is what it looks like. 

Many thanks!




On Sunday, February 19, 2023 at 11:18:38 PM CST, Globe Trotter via devel 
 wrote: 





On Sunday, February 19, 2023 at 09:25:50 PM CST, Neal Gompa 
 wrote: 





On Sun, Feb 19, 2023 at 9:33 PM Globe Trotter via devel
 wrote:
>
> Hello,
>
> Since about Fedora 20 or so, I have been rolling my own Fedora spin without a 
> desktop environment, and with openbox and slim (simple login manager). All 
> worked well, because I did not need to roll these that often, with dnf 
> upgrade on existing installations, except up until now when I need a new 
> LiveCD for a new machine coming online. I last successfully made a LiveCD 
> with Fedora 34.
>
> Recently, I went back to making a live cd for Fedora 37, and realized that 
> there is a new way of handling these: specifically, I have to install 
> env-group to resolve RH Bug:1891500.
>
> With an environment, it turns out one has to do something like
>
>
> @^lxde-desktop-environment
>
> but I do not want an environment.
>
>
> Can I get a LiveCD environment without all this, and with slim?
>

> Yes, you can just avoid using environment groups altogether. The bug you 
> reference should not apply in your case.

-- 
Thanks! Not? but it does not work. A LiveCD is  created if I do not add that 
line to my ks, but. I get something that hangs when the LiveCD boots. Did not 
happen before. 



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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Neal Gompa]

On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson  wrote:
>
> On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  wrote:
>>
>> Hi Troy,
>>
>> On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
>> > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
>> > epel-devel@lists.fedoraproject.org> wrote:
>> >
>> > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
>> > > > I think this whole process should be automated. File bugs that say
>> > > > "Heads up:
>> > > > your package will be automatically retired after the release of RHEL
>> > > > X.X" and
>> > > > provide some explanation.
>> > >
>> > > Agreed. This is a pretty mechanical process: all the maintainer would
>> > > do is run "fedpkg retire" for the appropriate branches, and that looks
>> > > reasonable to automate. If we're concerned about bugs in the automation
>> > > retiring packages that shouldn't be impacted, we can have it file a
>> > > ticket for signoff on the EPEL tracker (or have some other process to
>> > > spot check, at least until we're confiden it'll do the right thing).
>> > >
>> >
>> > Sorry for delaying this for so long. Things came up, but now I have some
>> > time.
>> >
>> > I think step one in this automation workflow is to not assign the bugs to
>> > the package at all.
>> > Assign the bugs to EPEL / distribution, but keep them as blockers on the
>> > EPEL2RHEL tracker[1].
>> > This gets rid of the busy maintainer problem.  Where they just read the
>> > subject and do what it says.
>> > This also allows the automation to not have to deal with all the different
>> > packages.
>>
>> I'm not sure filling against distribution is a good idea. I'd just file
>> bugs against the affected component, set the bug assignee to yourself,
>> and close it once you preform the automatic retirement. This way, you
>> won't have to worry about CCing the proper maintainer on the
>> distribution bug and the bugs will be more organized. The subject is a
>> separate problem.
>>
>> > I think for the automation to happen, we also have to get the subject line
>> > updated.
>> > If we can get it to have what release is in it, parsing the subject line is
>> > much easier than going through all the bugzilla comments trying to find
>> > what release this is supposed to come out in.
>> > Something like "Remove yara from epel8 when RHEL 8.7 is released"
>>
>> I'd prefer something like the originally suggested "Notice: PACKAGE_HERE
>> will be automatically retired in RHEL X.X" so it's clear that
>> maintainers don't need to take manual action.
>
>
> That is a good point.
>
> On a related note.
> For the past month or so, as new packages get added to the tracker I've been 
> manually adding a comment that the package shouldn't be retired until (date) 
> which is when (release) will come out.  That has usually been May 2023 when 
> RHEL 8.8 / 9.2 comes out.
> Several of the maintainers have thanked me for the clarification.
> I've been doing this mainly so I can get a feel for what the script should be 
> doing.  But one thing came up that I don't have an answer to.
>
> I haven't said "We will automatically retire this for you" because I don't 
> know who "we" is/are.
> Is it the committee?  (could be, that seems the most likely)
> Is it the epel-packagers-sig? (I don't think that's right.)
> Is it a different "retirement group"?
>
> Thoughts?

It should probably be done by automation, not a person.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  wrote:

> Hi Troy,
>
> On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
> > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
> > epel-devel@lists.fedoraproject.org> wrote:
> >
> > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
> > > > I think this whole process should be automated. File bugs that say
> > > > "Heads up:
> > > > your package will be automatically retired after the release of RHEL
> > > > X.X" and
> > > > provide some explanation.
> > >
> > > Agreed. This is a pretty mechanical process: all the maintainer would
> > > do is run "fedpkg retire" for the appropriate branches, and that looks
> > > reasonable to automate. If we're concerned about bugs in the automation
> > > retiring packages that shouldn't be impacted, we can have it file a
> > > ticket for signoff on the EPEL tracker (or have some other process to
> > > spot check, at least until we're confiden it'll do the right thing).
> > >
> >
> > Sorry for delaying this for so long. Things came up, but now I have some
> > time.
> >
> > I think step one in this automation workflow is to not assign the bugs to
> > the package at all.
> > Assign the bugs to EPEL / distribution, but keep them as blockers on the
> > EPEL2RHEL tracker[1].
> > This gets rid of the busy maintainer problem.  Where they just read the
> > subject and do what it says.
> > This also allows the automation to not have to deal with all the
> different
> > packages.
>
> I'm not sure filling against distribution is a good idea. I'd just file
> bugs against the affected component, set the bug assignee to yourself,
> and close it once you preform the automatic retirement. This way, you
> won't have to worry about CCing the proper maintainer on the
> distribution bug and the bugs will be more organized. The subject is a
> separate problem.
>
> > I think for the automation to happen, we also have to get the subject
> line
> > updated.
> > If we can get it to have what release is in it, parsing the subject line
> is
> > much easier than going through all the bugzilla comments trying to find
> > what release this is supposed to come out in.
> > Something like "Remove yara from epel8 when RHEL 8.7 is released"
>
> I'd prefer something like the originally suggested "Notice: PACKAGE_HERE
> will be automatically retired in RHEL X.X" so it's clear that
> maintainers don't need to take manual action.
>

That is a good point.

On a related note.
For the past month or so, as new packages get added to the tracker I've
been manually adding a comment that the package shouldn't be retired until
(date) which is when (release) will come out.  That has usually been May
2023 when RHEL 8.8 / 9.2 comes out.
Several of the maintainers have thanked me for the clarification.
I've been doing this mainly so I can get a feel for what the script should
be doing.  But one thing came up that I don't have an answer to.

I haven't said "We will automatically retire this for you" because I don't
know who "we" is/are.
Is it the committee?  (could be, that seems the most likely)
Is it the epel-packagers-sig? (I don't think that's right.)
Is it a different "retirement group"?

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster 
wrote:

> On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski
>  wrote:
>
> > It would be really nice if the wording of the bug could contain some
> > kind of a "thank you" note to the EPEL maintainers of the package in
> > question. Not everyone will understand this process as "great, I don't
> > have to maintain package X anymore, Red Hat will be doing that for me
> > from now on". Some folks may take it as "Oh no! Red Hat is taking away
> > my toy! Why?!" Ideally, there should still be a way for EPEL
> > maintainer(s) to continue contributing to the RHEL package.
>
> Perhaps add something like (wordsmithed by someone
> competent in such things):
>
> "The package you have been maintaining in EPEL is now
> considered important enough to a large enough part of our
> customers that Red Hat has decided to promote it to being
> an officially supported part of the product"
>

I like that idea.  It's much more positive.  A nice "Thank you for doing
this in EPEL" type of feel.

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

Orphaning rubygem-spring-watcher-listen

[Pavel Valena]

Hello,

I'm $SUBJ, as it's not used in Rails anymore:
https://github.com/rails/rails/pull/36377

Thanks to vonduch for updating the package!

Pavel
https://src.fedoraproject.org/rpms/rubygem-spring-watcher-listen
___
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 38 compose report: 20230220.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-38-20230219.n.0
NEW: Fedora-38-20230220.n.0

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

Size of added packages:  57.97 KiB
Size of dropped packages:0 B
Size of upgraded packages:   115.35 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-38-20230219.n.0.iso

= ADDED PACKAGES =
Package: python-sphinxygen-1.0.0-1.fc38
Summary: A script to read Doxygen XML output and emit ReST for Sphinx
RPMs:python3-sphinxygen
Size:36.73 KiB

Package: rust-time-core-0.1.0-1.fc38
Summary: Internal implementation details of the 'time' crate
RPMs:rust-time-core+default-devel rust-time-core-devel
Size:21.24 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  budgie-desktop-10.7.1-1.fc38
Old package:  budgie-desktop-10.7-1.fc38
Summary:  A feature-rich, modern desktop designed to keep out the way of 
the user
RPMs: budgie-desktop budgie-desktop-devel budgie-desktop-docs
Size: 12.90 MiB
Size change:  93.43 KiB
Changelog:
  * Thu Feb 16 2023 Joshua Strobl  - 10.7-2
  - Add preliminary mutter 12 ABI support patch

  * Sun Feb 19 2023 Joshua Strobl  - 10.7.1-1
  - Update to Budgie 10.7.1 release


Package:  corectrl-1.3.2-1.fc38
Old package:  corectrl-1.3.1-3.fc38
Summary:  Friendly hardware control
RPMs: corectrl
Size: 3.79 MiB
Size change:  -686.66 KiB
Changelog:
  * Sun Feb 19 2023 Artem Polishchuk  - 1.3.2-1
  - build: Update to 1.3.2


Package:  emacs-slime-2:2.28-1.fc38
Old package:  emacs-slime-2:2.26-4.fc36
Summary:  The superior lisp interaction mode for emacs
RPMs: emacs-slime
Size: 675.06 KiB
Size change:  1.97 KiB
Changelog:
  * Thu Jul 21 2022 Fedora Release Engineering  - 
2:2.26-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Wed Aug 03 2022 Bhavin Gandhi  - 2:2.27-1
  - Update to 2.27, fixes rhbz#2113203 rhbz#1908571

  * Thu Jan 19 2023 Fedora Release Engineering  - 
2:2.27-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

  * Mon Feb 20 2023 Filipe Rosset  - 2:2.28-1
  - Update to 2.28, fixes FTBFS rhbz#2164770


Package:  gjots2-3.2.1-1.fc38
Old package:  gjots2-3.2.0-3.fc38
Summary:  A hierarchical note jotter - organize your ideas, notes, facts in 
a tree
RPMs: gjots2
Size: 258.65 KiB
Size change:  -358 B
Changelog:
  * Mon Feb 20 2023 Bob Hepple  - 3.2.1-1
  - new version
  - migrated to SPDX license


Package:  gtkwave-3.3.114-1.fc38
Old package:  gtkwave-3.3.113-2.fc38
Summary:  Waveform Viewer
RPMs: gtkwave
Size: 9.86 MiB
Size change:  -34.48 KiB
Changelog:
  * Sun Feb 19 2023 Paul Howarth  - 3.3.114-1
  - Update to 3.3.114
- Buffer overflow fixes in FST reader


Package:  guacamole-server-1.5.0-1.fc38
Old package:  guacamole-server-1.4.0-7.fc38
Summary:  Server-side native components that form the Guacamole proxy
RPMs: guacd libguac libguac-client-kubernetes libguac-client-rdp 
libguac-client-ssh libguac-client-telnet libguac-client-vnc libguac-devel
Size: 3.77 MiB
Size change:  34.79 KiB
Changelog:
  * Sun Feb 19 2023 Robert Scheck  - 1.5.0-1
  - Update to 1.5.0 (#2169593)


Package:  ibus-m17n-1.4.19-1.fc38
Old package:  ibus-m17n-1.4.18-2.fc38
Summary:  The M17N engine for IBus platform
RPMs: ibus-m17n
Size: 758.90 KiB
Size change:  794 B
Changelog:
  * Sun Feb 19 2023 Mike FABIAN  - 1.4.19-1
  - Update to 1.4.19
  - Translation update from Weblate (Sinhala, si 100%)


Package:  libcupsfilters-2.0b3-3.fc38
Old package:  libcupsfilters-2.0b3-2.fc38
Summary:  Library for developing printing filters
RPMs: libcupsfilters libcupsfilters-devel
Size: 3.04 MiB
Size change:  1.18 KiB
Changelog:
  * Mon Feb 20 2023 Zdenek Dohnal  - 2.0b3-3
  - fix double free caused by coverity fix


Package:  librsync-2.3.4-1.fc38
Old package:  librsync-2.3.2-5.fc38
Summary:  Rsync remote-delta algorithm library
RPMs: librsync librsync-devel librsync-doc
Size: 780.86 KiB
Size change:  113.58 KiB
Changelog:
  * Sat Feb 18 2023 Robert Scheck  2.3.3-1
  - Upgrade to 2.3.3 (#2170502)

  * Sun Feb 19 2023 Robert Scheck  2.3.4-1
  - Upgrade to 2.3.4 (#2170502 #c2)


Package:  nsd-4.6.1-1.fc38
Old package:  nsd-4.3.9-5.fc38
Summary:  Fast and lean authoritative DNS Name Server
RPMs: nsd
Size: 3.62 MiB
Size change:  213.87 KiB
Changelog:
  * Sun Feb 19 2023 Fabio Alessandro Locati  - 4.6.1-1
  - Update to 4.6.1


Package:  nwg-panel-0.7.17-1.fc38
Old package:  nwg-panel-0.7.16-2.fc38
Summary:  GTK3-based panel for sway window manager
RPMs

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 20, 2023 at 11:04:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 20, 2023 at 11:06:10AM +0100, Petr Pisar wrote:
> > V Sat, Feb 18, 2023 at 09:20:20AM -0800, Gordon Messmer napsal(a):
> > > For shared libraries without versioned symbols, the provides will change
> > > from:
> > > 
> > >   Provides: libnghttp2.so.14()(64bit)
> > > 
> > > to:
> > > 
> > >   Provides: libnghttp2.so.14()(64bit) >= 14.24.1
> > > 
> > > ... while requirements on that package will change from:
> > > 
> > >   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
> > >   Requires: libnghttp2.so.14()(64bit)
> > > 
> > > to:
> > > 
> > >   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
> > >   Requires: libnghttp2.so.14()(64bit) >= 14.24.1
> > > 
> > [...]
> > > Dependencies are generated using dlmopen() to locate a required library
> > > named in an ELF header, and then resolving the symlink to a full path. If
> > > the full path ends in ".so.x.y.z", where "x.y.z" is a series of numbers
> > > separated by dots, then the numbers and dots suffix is treated as a 
> > > version
> > > number for that library.
> > > 
> > I applaud the struggle for ensuring compatibility. However, I worry that it
> > will make downgrading RPM packages less feasible. Imagine a user who updates
> > a system, finds a regression in a library, attempts to downgrade the library
> > and it will result into downgrading later-built reverse dependencies only
> > because the library applied a (wrong) fix and the triplet has changed.
> > 
> > Do you know meaning of the numbers? I only guess that the first number
> > tracks incompatible changes, the second number tracks added interfaces and 
> > the
> > last number tracks interface-irrelevant changes (fixes usually).
> 
> Such use is what the libtool docs and other guidelines recommend.
> 
> > Provided my guess is correctm would it make sense to exclude the last number
> > from the RPM dependencies? I.e.  libnghttp2.so.14.24.1 library file name 
> > would
> > produce "libnghttp2.so.14()(64bit) >= 14.24" dependency. This less strict
> > approach would provide users a freedom to downgrade/upgrade libaries without
> > changes in the interface.
> 
> This is true, with this proposal implemented in full, the user will be forced 
> to
> install at least the same .x.y.z versions of dependecies as that against which
> the package was built. This is limiting to some extent, but I think the 
> overall
> quality will be higher.
> 
> Note that the .z number reflects "fixes". When the package is built against 
> that
> version, it is also *tested* against that version. Configuration-time tests,
> tests in %check, and autoqa / CI tests would all be done against that version,
> and since testers who have updates-testing enabling would also generally 
> install
> the full package set, so they would also usually test the latest versions of
> all dependencies. I don't think we want to test against the latest version 
> with
> all the fixes but then provide a much looser version dependency for users.
> If the upsteam is doing a good job, higher .z numbers should be stricly better
> than the lower ones.

Replying to myself… probably not a good sign. After pressing "send" I realized
the following:

On Fri, Feb 17, 2023 at 07:03:26PM -0800, Gordon Messmer wrote:
> This change would make manual, selected versioned dependencies unnecessary
> by generating them automatically for any package that provides libtool-style
> versioned shared objects.  (Though, again, objects that provide versioned
> symbols are excluded, because versioned symbols are already handled
> properly, and are the preferred mechanism.)

This creates a mismatch in how strictly we handle libs with versioned symbols
and those without. Symbol versioning only describes the version of the library
when the symbol was introduced, which corresponds to the x.y part of the file
suffix. The .z part (patch level) is not reflected at all.

With the proposed generator, we'll now treat dependencies without symbol 
versioning
more strictly, because the generator will specify >=x.y.z. For dependencies with
symbol versioning, we get the equivalent of >=x.y.

I'm not sure what we should do. If the goal is provide the equivalent solution
for non-symbol-versioned deps as for symbol-version-deps, then as Petr 
suggested,
ignoring .z in the requirements would be appropriate. This is enough to fix the
linker errors described as the motivation.

OTOH, as I wrote above, I think that there are good reasons to use the stricter
versioning… In that case, I think we should consider enhancing the generator
for versioned symbols to use versions:
  -Provides: libsystemd.so.0(LIBSYSTEMD_209)
  +Provides: libsystemd.so.0(LIBSYSTEMD_209) = 0.34.0
and:
  -Requires: libsystemd.so.0(LIBSYSTEMD_209)
  +Requires: libsystemd.so.0(LIBSYSTEMD_209) >= 0.34.0

The good part is that the Provides side should use the full version, as there is
not reason not to. The decision whether to use >=x.y or >=x.y.z in Requires 

Re: pipenv / pipfile support in pyproject-rpm-macros

[Lumír Balhar]

Hi Mikel.

The way upstream manages the dependencies of the project seems to be 
weird to me. They use setuptools as a build backend and have runtime 
dependencies in pyproject.toml but at the same time, they have Pipfile 
and Pipfile.lock with runtime and test dependencies.


The best would be to have the list of testing dependencies defined in 
pyproject.toml as extras.


But, it does not really matters to you because it seems that the list of 
the test dependencies is full of linter, formatters and type checkers 
you should not use in Fedora: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


So, even if it would be possible to use the list of test dependencies in 
the specfile, you should remove a lot of them first so it's probably 
easier to just specify the subset of them you really need.


Hope that helps. Have a nice day.

Lumír

On 2/20/23 12:08, Mikel Olasagasti wrote:

Hi team,

I maintain a package, python-mirakuru[1], and the spec file uses
pyproject-rpm-macros.

With the latest release, 2.5.0, the project migrated[2] from using
requirements.txt files to use pipenv/Pipfile to declare dependencies.

I found that after bumping the version in the spec it fails during the
%check phase as some dependencies are missing. I can easily workaround
by declaring missing BuildRequires, but I wonder if there is an
automagic way to support pipenv with pyproject-rpm-macros to avoid
manually having to define BRs.

Kind regards,
Mikel Olasagasti

[1] https://src.fedoraproject.org/rpms/python-mirakuru
[2] https://github.com/ClearcodeHQ/mirakuru/pull/622/files
___
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

___
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

Re: Errors when updating repo information

[Petr Pisar]

V Sat, Feb 18, 2023 at 11:58:58AM +0300, Benson Muite napsal(a):
> For builds on COPR and when using Fedora in the cloud, occasionally get
> an error when trying to read rawhide repository information:
> 
> $ sudo dnf install wget
> Fedora - Rawhide - Developmental packages for t  13 MB/s |  21 MB
> 00:01
> Errors during downloading metadata for repository 'rawhide':
>   - Curl error (23): Failed writing received data to disk/application
> for
> https://d2lzkl7pfhq30w.cloudfront.net/pub/fedora/linux/development/rawhide/Everything/aarch64/os/repodata/9f84bd5273bb6a0e5dd74da9d9726a71912ad7a866f84e0c63072ca0cf0e12df-filelists.xml.zck
> [Failure writing output to destination]
> Error: Failed to download metadata for repo 'rawhide': Yum repo
> downloading error: Downloading error(s):
> repodata/9f84bd5273bb6a0e5dd74da9d9726a71912ad7a866f84e0c63072ca0cf0e12df-filelists.xml.zck
> - Download failed: Curl error (23): Failed writing received data to
> disk/application for
> https://d2lzkl7pfhq30w.cloudfront.net/pub/fedora/linux/development/rawhide/Everything/aarch64/os/repodata/9f84bd5273bb6a0e5dd74da9d9726a71912ad7a866f84e0c63072ca0cf0e12df-filelists.xml.zck
> [Failure writing output to destination]
> 
> Does this affect anyone else? Has it been reported?

It's a bug in rawhide's curl-7.88.0-1.fc39. It has been reported and fixed in
curl-7.88.0-2.fc39 .

-- Petr


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

pipenv / pipfile support in pyproject-rpm-macros

[Mikel Olasagasti]

Hi team,

I maintain a package, python-mirakuru[1], and the spec file uses
pyproject-rpm-macros.

With the latest release, 2.5.0, the project migrated[2] from using
requirements.txt files to use pipenv/Pipfile to declare dependencies.

I found that after bumping the version in the spec it fails during the
%check phase as some dependencies are missing. I can easily workaround
by declaring missing BuildRequires, but I wonder if there is an
automagic way to support pipenv with pyproject-rpm-macros to avoid
manually having to define BRs.

Kind regards,
Mikel Olasagasti

[1] https://src.fedoraproject.org/rpms/python-mirakuru
[2] https://github.com/ClearcodeHQ/mirakuru/pull/622/files
___
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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Florian Weimer]

* Gordon Messmer:

> As you noted at the end of your message, that would involve querying
> the rpm DB from the ELF dependency generator, which the rpm
> maintainers want to avoid.

Not really.  We could dump an extract of the RPM database to a text file
at the start of the build, after the dependencies have been installed.

But I really don't get why read-only access to the RPM database during
the build is so problematic.  I don't see how it can be worse than what
we do with package notes.

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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 20, 2023 at 11:06:10AM +0100, Petr Pisar wrote:
> V Sat, Feb 18, 2023 at 09:20:20AM -0800, Gordon Messmer napsal(a):
> > For shared libraries without versioned symbols, the provides will change
> > from:
> > 
> >   Provides: libnghttp2.so.14()(64bit)
> > 
> > to:
> > 
> >   Provides: libnghttp2.so.14()(64bit) >= 14.24.1
> > 
> > ... while requirements on that package will change from:
> > 
> >   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
> >   Requires: libnghttp2.so.14()(64bit)
> > 
> > to:
> > 
> >   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
> >   Requires: libnghttp2.so.14()(64bit) >= 14.24.1
> > 
> [...]
> > Dependencies are generated using dlmopen() to locate a required library
> > named in an ELF header, and then resolving the symlink to a full path. If
> > the full path ends in ".so.x.y.z", where "x.y.z" is a series of numbers
> > separated by dots, then the numbers and dots suffix is treated as a version
> > number for that library.
> > 
> I applaud the struggle for ensuring compatibility. However, I worry that it
> will make downgrading RPM packages less feasible. Imagine a user who updates
> a system, finds a regression in a library, attempts to downgrade the library
> and it will result into downgrading later-built reverse dependencies only
> because the library applied a (wrong) fix and the triplet has changed.
> 
> Do you know meaning of the numbers? I only guess that the first number
> tracks incompatible changes, the second number tracks added interfaces and the
> last number tracks interface-irrelevant changes (fixes usually).

Such use is what the libtool docs and other guidelines recommend.

> Provided my guess is correctm would it make sense to exclude the last number
> from the RPM dependencies? I.e.  libnghttp2.so.14.24.1 library file name would
> produce "libnghttp2.so.14()(64bit) >= 14.24" dependency. This less strict
> approach would provide users a freedom to downgrade/upgrade libaries without
> changes in the interface.

This is true, with this proposal implemented in full, the user will be forced to
install at least the same .x.y.z versions of dependecies as that against which
the package was built. This is limiting to some extent, but I think the overall
quality will be higher.

Note that the .z number reflects "fixes". When the package is built against that
version, it is also *tested* against that version. Configuration-time tests,
tests in %check, and autoqa / CI tests would all be done against that version,
and since testers who have updates-testing enabling would also generally install
the full package set, so they would also usually test the latest versions of
all dependencies. I don't think we want to test against the latest version with
all the fixes but then provide a much looser version dependency for users.
If the upsteam is doing a good job, higher .z numbers should be stricly better
than the lower ones.

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: Orphaning pulseeffects

[Vascom]

I'm afraid to make a mistake in the procedure.

пн, 20 февр. 2023 г. в 13:34, Sandro :
>
> On 20-02-2023 10:09, Vascom wrote:
> > This package can be retired. There is no need for anyone to take it.
>
> Why not retire it directly, if adoption makes no sense?
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
>
> -- Sandro
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning pulseeffects

[Sandro]

On 20-02-2023 10:09, Vascom wrote:

This package can be retired. There is no need for anyone to take it.


Why not retire it directly, if adoption makes no sense?

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/

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

On 20-02-2023 08:39, Miro Hrončok wrote:

maildirproc   orphan 0 weeks ago


Taken. I may have some personal use case for it.

-- Sandro
___
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 2165855] Cleanup spec file for arm platform

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

Version|38  |rawhide
 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
Last Closed||2023-02-20 10:22:43




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2165855
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Florian Weimer]

* Gordon Messmer:

> * Other developers:
>
> Other developers are not expected to make any specific changes, though
> if any package is manually creating versioned dependencies (as the
> curl package is), they can remove those and rely on the internal
> dependency generator when the change is complete.

I think there's at least one more thing that impacts compatibility.

For the most part, installed DSO names were opaque strings before this
change (because Fedora does not ship multiple implementation of the same
soname in the same directory).  We have an ordering algorithm in
glibc/ldconfig (_dl_cache_libcmp), but I do not think it is the same as
the RPM ordering algorithm, particularly since it works on the entire
name and not just the part following the “.so.“ string (which I think
this change is proposing).  Furthermore, upstream might change the
installed name because from an ELF perspective, it's an implementation
detail.  I think package maintainers need to be aware of that.

Does the dependency generate look at the actual symbol references, and
does it try to generate version information based on what the actually
used symbols bind to?

And alternative implementation would just look at the DT_NEEDED entries
and use the RPM versions found in the buildroot.  This wouldn't need a
mass rebuild to become effective.  It would force more package updates,
and thus make it harder to install packages directly out of Koji
(instead of a compose), but perhaps that's a better trade-off?

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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Daniel P . Berrangé]

On Fri, Feb 17, 2023 at 07:03:26PM -0800, Gordon Messmer wrote:
> Following a recent thread discussing a reproducible failure caused by
> mismatched library interfaces, I proposed a change to the RPM ELF dependency
> generator.  After discussion in the PR, I've provided an implementation
> suggested by keszybz@ which would use libtool-style versions collected from
> library filenames to provide versioned library requirements.  Before merging
> that feature, RPM's maintainers are interested in feedback from a wider
> audience.

You mention 'libtool' multiple times through this thread. libtool
defines specific semantics for 3 digits in the version number.
Not all shared libraries are built with libtool, and even those
which did use libtool didn't neccesarily apply libtool's semantics.

Possibly this proposal works fine regardless ? In fact, presumably it
must, otherwise its going to break stuff.

If so, then I'd suggest removing references to libtool and describing
directly what kind of versions it looks for and what it does with them.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Petr Pisar]

V Sat, Feb 18, 2023 at 09:20:20AM -0800, Gordon Messmer napsal(a):
> For shared libraries without versioned symbols, the provides will change
> from:
> 
>   Provides: libnghttp2.so.14()(64bit)
> 
> to:
> 
>   Provides: libnghttp2.so.14()(64bit) >= 14.24.1
> 
> ... while requirements on that package will change from:
> 
>   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
>   Requires: libnghttp2.so.14()(64bit)
> 
> to:
> 
>   Requires: libc.so.6(GLIBC_2.3.4)(64bit)
>   Requires: libnghttp2.so.14()(64bit) >= 14.24.1
> 
[...]
> Dependencies are generated using dlmopen() to locate a required library
> named in an ELF header, and then resolving the symlink to a full path. If
> the full path ends in ".so.x.y.z", where "x.y.z" is a series of numbers
> separated by dots, then the numbers and dots suffix is treated as a version
> number for that library.
> 
I applaud the struggle for ensuring compatibility. However, I worry that it
will make downgrading RPM packages less feasible. Imagine a user who updates
a system, finds a regression in a library, attempts to downgrade the library
and it will result into downgrading later-built reverse dependencies only
because the library applied a (wrong) fix and the triplet has changed.

Do you know meaning of the numbers? I only guess that the first number
tracks incompatible changes, the second number tracks added interfaces and the
last number tracks interface-irrelevant changes (fixes usually).

Provided my guess is correctm would it make sense to exclude the last number
from the RPM dependencies? I.e.  libnghttp2.so.14.24.1 library file name would
produce "libnghttp2.so.14()(64bit) >= 14.24" dependency. This less strict
approach would provide users a freedom to downgrade/upgrade libaries without
changes in the interface.

-- Petr


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

Fedora rawhide compose report: 20230220.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230219.n.0
NEW: Fedora-Rawhide-20230220.n.0

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

Size of added packages:  57.97 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.40 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230220.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230220.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-sphinxygen-1.0.0-1.fc39
Summary: A script to read Doxygen XML output and emit ReST for Sphinx
RPMs:python3-sphinxygen
Size:36.73 KiB

Package: rust-time-core-0.1.0-1.fc39
Summary: Internal implementation details of the 'time' crate
RPMs:rust-time-core+default-devel rust-time-core-devel
Size:21.24 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  budgie-desktop-10.7.1-1.fc39
Old package:  budgie-desktop-10.7-2.fc39
Summary:  A feature-rich, modern desktop designed to keep out the way of 
the user
RPMs: budgie-desktop budgie-desktop-devel budgie-desktop-docs
Size: 12.90 MiB
Size change:  124.20 KiB
Changelog:
  * Sun Feb 19 2023 Joshua Strobl  - 10.7.1-1
  - Update to Budgie 10.7.1 release


Package:  coin-or-Ipopt-3.14.11-1.fc39
Old package:  coin-or-Ipopt-3.14.9-2.fc38
Summary:  Interior Point OPTimizer
RPMs: coin-or-Ipopt coin-or-Ipopt-common coin-or-Ipopt-devel 
coin-or-Ipopt-mpich coin-or-Ipopt-mpich-devel coin-or-Ipopt-openmpi 
coin-or-Ipopt-openmpi-devel
Size: 19.76 MiB
Size change:  215.13 KiB
Changelog:
  * Sun Feb 19 2023 Antonio Trande  - 3.14.11-1
  - Release 3.14.11


Package:  corectrl-1.3.2-1.fc39
Old package:  corectrl-1.3.1-3.fc38
Summary:  Friendly hardware control
RPMs: corectrl
Size: 3.79 MiB
Size change:  -685.06 KiB
Changelog:
  * Sun Feb 19 2023 Artem Polishchuk  - 1.3.2-1
  - build: Update to 1.3.2


Package:  emacs-slime-2:2.28-1.fc39
Old package:  emacs-slime-2:2.26-4.fc36
Summary:  The superior lisp interaction mode for emacs
RPMs: emacs-slime
Size: 675.05 KiB
Size change:  2.00 KiB
Changelog:
  * Thu Jul 21 2022 Fedora Release Engineering  - 
2:2.26-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Wed Aug 03 2022 Bhavin Gandhi  - 2:2.27-1
  - Update to 2.27, fixes rhbz#2113203 rhbz#1908571

  * Thu Jan 19 2023 Fedora Release Engineering  - 
2:2.27-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

  * Mon Feb 20 2023 Filipe Rosset  - 2:2.28-1
  - Update to 2.28, fixes FTBFS rhbz#2164770


Package:  gjots2-3.2.1-1.fc39
Old package:  gjots2-3.2.0-3.fc38
Summary:  A hierarchical note jotter - organize your ideas, notes, facts in 
a tree
RPMs: gjots2
Size: 258.75 KiB
Size change:  -265 B
Changelog:
  * Mon Feb 20 2023 Bob Hepple  - 3.2.1-1
  - new version
  - migrated to SPDX license


Package:  golang-github-avast-retry-4.3.3-1.fc39
Old package:  golang-github-avast-retry-4.0.3-4.fc38
Summary:  Simple golang library for retry mechanism
RPMs: golang-github-avast-retry-devel
Size: 19.86 KiB
Size change:  1.21 KiB
Changelog:
  * Sun Feb 19 2023 Fabian Affolter  - 4.3.3-1
  - Update to latest upstream release 4.3.3 (closes rhbz#2074310)


Package:  golang-github-casbin-2-2.63.0-4.fc39
Old package:  golang-github-casbin-2-2.36.1-4.fc38
Summary:  An authorization library for ACL, RBAC and ABAC
RPMs: golang-github-casbin-2-devel
Size: 94.62 KiB
Size change:  8.63 KiB

Package:  golang-github-cenkalti-backoff-4.2.0-1.fc39
Old package:  golang-github-cenkalti-backoff-4.1.2-4.fc38
Summary:  Exponential backoff algorithm in Go
RPMs: compat-golang-github-cenkalti-backoff-4-devel 
golang-github-cenkalti-backoff-devel
Size: 33.98 KiB
Size change:  327 B
Changelog:
  * Sun Feb 19 2023 Fabian Affolter  - 4.2.0-1
  - Update to latest upstream release 4.2.0 (closes rhbz#2073829)


Package:  golang-uber-goleak-1.2.1-1.fc39
Old package:  golang-uber-goleak-1.2.0-3.fc38
Summary:  Goroutine leak detector
RPMs: golang-uber-goleak-devel
Size: 25.58 KiB
Size change:  -76 B
Changelog:
  * Sun Feb 19 2023 Fabian Affolter  - 1.2.1-1
  - UPdate to latest upstream release 1.2.1 (closes rhbz#2169588)


Package:  gtkwave-3.3.114-1.fc39
Old package:  gtkwave-3.3.113-2.fc38
Summary:  Waveform Viewer
RPMs: gtkwave
Size: 9.86 MiB
Size change:  -34.67 KiB
Changelog:
  * Sun Feb 19 2023 Paul Howarth  - 3.3.114-1
  - Update to 3.3.114
- Buffer overflow fixes in FST reader


Package:  guacamole-server-1.5.0-1

Re: Orphaning coffee-script + rubygem-coffee-script{,source}

[Vít Ondruch]

BTW these are the packages currently depending on CoffeeScript:

~~~

$ sudo dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --whatrequires '*coffee-script*'

Last metadata expiration check: 0:22:49 ago on Mon Feb 20 09:48:42 2023.
coffee-script-0:1.10.0-20.fc38.noarch
nodejs-diagnostic-language-server-0:1.13.0-4.fc38.src
perl-Mojolicious-Plugin-AssetPack-0:2.14-1.fc38.src
rubygem-coffee-script-0:2.4.1-16.fc38.noarch
rubygem-coffee-script-0:2.4.1-16.fc38.src
rubygem-coffee-script-doc-0:2.4.1-16.fc38.noarch
rubygem-coffee-script-source-0:1.10.0-15.fc38.noarch
rubygem-coffee-script-source-0:1.10.0-15.fc38.src
rubygem-coffee-script-source-doc-0:1.10.0-15.fc38.noarch
vim-syntastic-coffee-0:3.10.0-18.fc38.noarch

~~~


Vít


Dne 20. 02. 23 v 10:02 Vít Ondruch napsal(a):

Hi all,

I have orphaned rubygem-coffee-script{,source}, which used to be used 
by Ruby on Rails asset pipeline, but they are not anymore:


https://github.com/rails/ruby-coffee-script/issues/22#issuecomment-1162413725 



And therefore I have made sure that nothing depends on them in Fedora. 
There two packages also prevented update of coffee-script to version 
2+. This should be now possible. Since I know there was some interest 
and I have no other need for CoffeeScript, I also orphaned 
coffee-script package and it is now free to take (adding the possibly 
interested folks on CC).



Vít



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

Orphaning pulseeffects

[Vascom]

I have orphaned pulseeffects package because it replaced by
easyeffects at upstream and at Fedora.

This package can be retired. There is no need for anyone 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

Orphaning coffee-script + rubygem-coffee-script{,source}

[Vít Ondruch]

Hi all,

I have orphaned rubygem-coffee-script{,source}, which used to be used by 
Ruby on Rails asset pipeline, but they are not anymore:


https://github.com/rails/ruby-coffee-script/issues/22#issuecomment-1162413725

And therefore I have made sure that nothing depends on them in Fedora. 
There two packages also prevented update of coffee-script to version 2+. 
This should be now possible. Since I know there was some interest and I 
have no other need for CoffeeScript, I also orphaned coffee-script 
package and it is now free to take (adding the possibly interested folks 
on CC).



Vít



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