Fedora-Cloud-33-20201104.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20201103.0):

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

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] RHEL 8.3

[Thomas Stephen Lee]

Hi,

RHEL 8.3 got released.

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

[389-devel] 389 DS nightly 2020-11-04 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/04/report-389-ds-base-2.0.1-20201104git04ba05e.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Fedora-IoT-33-20201104.1 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test not failed in Fedora-IoT-33-20201102.0):

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

Old failures (same test failed in Fedora-IoT-33-20201102.0):

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

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

Old soft failures (same test soft failed in Fedora-IoT-33-20201102.0):

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

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

New passes (same test not passed in Fedora-IoT-33-20201102.0):

ID: 714786  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/714786
ID: 714795  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/714795

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.04 to 0.18
Previous test data: https://openqa.fedoraproject.org/tests/713777#downloads
Current test data: https://openqa.fedoraproject.org/tests/714765#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

New openQA and os-autoinst deployed on lab (stg)

[Adam Williamson]

Hey folks! Just a heads up that I've deployed new git snapshots of
openQA and os-autoinst to lab (stg), with ~3 months worth of changes in
each. I did a quick test run on my own pet deployment and nothing blew
up, but yell if you see anything awful. If they work OK for the next
few days I'll send them to prod.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org

[Bug 1869049] RPM spec assumes [UTF-8] Changes file is iso8859-1 encoded

[bugzilla]

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

Dick Franks  changed:

   What|Removed |Added

Version|31  |32




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1878468] RPM spec has unnecessary dependencies

[bugzilla]

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

Dick Franks  changed:

   What|Removed |Added

Version|31  |32




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1894304] perl-IO-Tty-1.15 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1894304] New: perl-IO-Tty-1.15 is available

[bugzilla]

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

Bug ID: 1894304
   Summary: perl-IO-Tty-1.15 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Tty
  Keywords: FutureFeature, Triaged
  Assignee: spo...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com, spo...@gmail.com, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.15
Current version/release in rawhide: 1.14-5.fc34
URL: http://search.cpan.org/dist/IO-Tty/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/7281/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #25 from Tom "spot" Callaway  ---
I've looked at this again with fresh eyes and I _think_ I see the issue and a
potential fix, but it would be really helpful to have a reproducer (even if the
reproducer is me making a scratch build and you testing it on your setup where
the problem occurs).


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #24 from Tom "spot" Callaway  ---
Be grateful you are not a perl programmer. :)

It seems the values can be initialized but NULL and trigger this, but I cannot
make it happen locally. The comment block directly above the line of code says:

# If the file was changed the same second as it was last read,
# we only reopen it if it's length has changed. The alternative is that
# sometimes, files would be reopened needlessly, and with reset_tail
# set to -1, we would see the whole file again.
# Of course, if the file was removed the same second as when it was
# last read, and replaced (within that second) with a file of equal
# length, we're out of luck. I don't see how to fix this.

Which leads me to believe their algorithm is totally wrong.

The challenge in trying to debug this is that I simply cannot reproduce it. I
put in code that I thought would fix the issue, but you reported that it did
not. Everything seems to be initialized and the entire existing test suite
passes. I had hoped upstream would be able to provide insight (5 years ago),
but they have clearly abandoned the effort.

Given all of that, I am hesitant to make additional changes to the algorithm
logic without a reproducer. Are you still actively using a setup that could
reproduce this?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #23 from Harald Reindl  ---
i am not a perl programmer, but "Use of uninitialized value in numeric eq (==)
at /usr/share/perl5/vendor_perl/File/Tail.pm line 391" in PHP would likely cost
me one line before to just make sure what ever is used in 391 is initalized if
it's not already


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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



--- Comment #3 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1379554] perl-XML-Twig: expand_external_ents option fails to work as documented [fedora-all]

[bugzilla]

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



--- Comment #10 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: [Fedocal] Reminder meeting : Prioritized bugs and issues

[Ben Cotton]

On Tue, Nov 3, 2020 at 6:01 AM  wrote:
>
> You are kindly invited to the meeting:
>Prioritized bugs and issues on 2020-11-04 from 11:00:00 to 12:00:00 
> America/Indiana/Indianapolis
>At fedora-meet...@irc.freenode.net
>
> The meeting will be about:
> Evaluation meeting
>
> More information available at: 
> https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process
>
Here are the bugs on tomorrow's agenda:

* acpica-tools: FTBFS in Fedora rawhide/f33
- https://bugzilla.redhat.com/show_bug.cgi?id=1863143
* Secure Boot fails to boot F33 Beta image
- https://bugzilla.redhat.com/show_bug.cgi?id=1883609
* Rebuilding of rpm db set wrong SELinux context
- https://bugzilla.redhat.com/show_bug.cgi?id=1461313

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Depend on git-core instead of git if possible

[clime]

On Tue, 3 Nov 2020 at 21:22, clime  wrote:
>
> On Tue, 3 Nov 2020 at 19:25, Neal Gompa  wrote:
> >
> > On Tue, Nov 3, 2020 at 1:08 PM clime  wrote:
> > >
> > > On Tue, 3 Nov 2020 at 17:42, Florian Weimer  wrote:
> > > >
> > > > >> Or switch to depend on `%{_bindir}/git`?
> > > > >
> > > > > If we do it like this, we will never be able drop repo download times
> > > > > for Fedora users.
> > > >
> > > > Files in %{_bindir} already end up in the primary metadata, don't they?
> > >
> > > Ok, I didn't know that. Do you happen to know if there is
> > > documentation of what ends up in primary metadata and what not?
> > >
> >
> > There is not, but it's generally supposed to be */bin and */lib.
>
> I think it might be a good idea to state this in packaging guidelines...
>
> i.e. "Packages should either specify their requirements explicitly by
> package names or optionally by a filesystem path for files under
> /usr/bin and /usr/lib paths. Requirements on files at other paths are
> technically also possible but they might trigger the need for download
> of additional repodata files by dnf when such a package is being
> installed, therefore they are not recommended."
>
> ... or something like that. I will need to check the exact paths etc.
> but after some more polishcould i open a pull request for this
> somewhere? I think it doesn't matter that lazy loading is not
> implemented yet.

Well, i should have read what Vit recommended first :):
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies

Packages SHOULD NOT include file dependencies outside of the following
directories:

/usr/bin
/usr/sbin
/etc

So I guess...nevermind...
clime

>
> Thank you
> clime
>
> >
> >
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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

Re: Depend on git-core instead of git if possible

[clime]

On Tue, 3 Nov 2020 at 19:25, Neal Gompa  wrote:
>
> On Tue, Nov 3, 2020 at 1:08 PM clime  wrote:
> >
> > On Tue, 3 Nov 2020 at 17:42, Florian Weimer  wrote:
> > >
> > > >> Or switch to depend on `%{_bindir}/git`?
> > > >
> > > > If we do it like this, we will never be able drop repo download times
> > > > for Fedora users.
> > >
> > > Files in %{_bindir} already end up in the primary metadata, don't they?
> >
> > Ok, I didn't know that. Do you happen to know if there is
> > documentation of what ends up in primary metadata and what not?
> >
>
> There is not, but it's generally supposed to be */bin and */lib.

I think it might be a good idea to state this in packaging guidelines...

i.e. "Packages should either specify their requirements explicitly by
package names or optionally by a filesystem path for files under
/usr/bin and /usr/lib paths. Requirements on files at other paths are
technically also possible but they might trigger the need for download
of additional repodata files by dnf when such a package is being
installed, therefore they are not recommended."

... or something like that. I will need to check the exact paths etc.
but after some more polishcould i open a pull request for this
somewhere? I think it doesn't matter that lazy loading is not
implemented yet.

Thank you
clime

>
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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

Re: Repository metadata signing?

[Marek Marczykowski-Górecki]

On Tue, Nov 03, 2020 at 08:52:09AM -0800, Kevin Fenzi wrote:
> Yes, it's possible... but it needs work in both pungi and robosignatory. 

Oh, that's unfortunate. I thought it was already supported.

> If you're interested in moving it forward, please work with the
> robosignatory and pungi developers (links to the issues on those in the
> infra ticket).

I'll look into it. I am vaguely familiar with pungi code, but not so
much with robosignatory.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[Bug 1878468] RPM spec has unnecessary dependencies

[bugzilla]

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



--- Comment #1 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1869049] RPM spec assumes [UTF-8] Changes file is iso8859-1 encoded

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1744419] Replace /etc/rc.d/init.d/httpd by systemctl

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|jples...@redhat.com |
   Fixed In Version|1731718 |




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1744419] Replace /etc/rc.d/init.d/httpd by systemctl

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com
   Fixed In Version||1731718




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1716324] Module::Build lists the object files after the linker flags, causing underlinking with -Wl,--as-needed

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

Version|31  |rawhide




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1522685] Upgrade perl-Authen-Krb5 to 1.903

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Version|31  |rawhide




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: RFC: Mangle Python shebangs to fully qualified interpreter (/usr/bin/pythonX.Y)

[Miro Hrončok]

On 11/3/20 6:32 PM, Neal Gompa wrote:

Hey all,

An "interesting" Linux support issue at work with another Linux
distribution opened my eyes to the possibility of how badly things
would break if /usr/bin/python3 was swapped or otherwise altered by an
external force. In such a scenario where it was overridden to point to
another Python 3 interpreter that wasn't the system one, things would
break pretty badly.

Now that we've been moving toward a model where it becomes possible
for first-party or third-party multi-Python RPMs, I'm wondering if it
would make sense to evolve the shebang mangling for Python to resolve
to the fully qualified Python interpreter path (that is,
/usr/bin/pythonX.Y instead of /usr/bin/pythonX) for packaged Python
code. Presumably this may make things easier for switching Python
versions without everything breaking, too.

In practice, I don't think this is a *huge* issue Fedora-side, since
we don't manage /usr/bin/python3 via alternatives. But I can easily
see people wanting /usr/bin/python3 to be swappable in Red Hat
Enterprise Linux, while everything is still parallel installable and
fully functional. The Python interpreter packaging even mostly
supports this now.

What do y'all think? Is this doable? Is this desirable?


Hey Neal. I am glad you brought this up. In fact, we've been discussing this 
internally in the Python Maint team on several occasions.


Some of the conclusions:

We don't want to support /usr/bin/python3 to be swappable in RHEL. The 
alternatives mechanism in RHEL 8 proved to be painful to get right both from the 
maintenance perspective and users/sysadmin perspective. We want people to be 
able to to use a well-known entry point (/usr/bin/python3) as "the Python that's 
running the system". /usr/libexec/platform-python is a downstream-only hack (we 
plan to keep it for backwards compatibility, but that's it).


IMHO people who want swappable python3 commond don't *actually* need 
/usr/bin/python3, they can have /usr/local/bin/python3 or ~/.local/bin/python3.


Changing shebangs to fully qualified (X.Y) Python version brings additional 
bootstrapping issues when upgrading Python. For example, in Fedora, we currently 
have ~3500 source packages that build at least one package requiring python(abi) 
and/or libpython X.Y specifically. Such packages need to be bootstrapped when we 
upgrade Python and it is not trivial. On top of that, we have ~400 more 
requiring /usr/bin/python3 "only". Adding them to the problem is not 
significant, but it is more work nevertheless.


Additionally, if we support swappable /usr/bin/python3, shebangs are the easy 
part. We have learned the hard way (with /usr/bin/python) that shebnags are 
easily checked/asserted/mangled/counted, but it's the non-shebang invocations 
that are lurking everywhere. The only way to actually discover the usage in 
Fedora packages was to remove the executable from the Python package and it took 
many releases to get rid of all of them (but honestly, we cannot be sure if we did).


OTOH I've been thinking we should set the shebang of dnf to a fully qualified 
Python version as an exception: In case people will get ideas about changing the 
/usr/bin/python3 symbolic link target (as I am sure they will), at least they 
would be able to run `sudo dnf reinstall python3` to recover.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

[Bug 1666098] Overspecification in perl -MExtUtils::Embed -e ldopts

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|ka...@ucw.cz,   |
   |mmasl...@redhat.com |
Version|31  |rawhide



--- Comment #5 from Jitka Plesnikova  ---
Still valid


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1894057] perl-CPANPLUS-Dist-Fedora-0.4.1 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-CPANPLUS-Dist-Fedora-0
   ||.4.1-1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-11-03 16:09:06




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Depend on git-core instead of git if possible

[Neal Gompa]

On Tue, Nov 3, 2020 at 1:08 PM clime  wrote:
>
> On Tue, 3 Nov 2020 at 17:42, Florian Weimer  wrote:
> >
> > >> Or switch to depend on `%{_bindir}/git`?
> > >
> > > If we do it like this, we will never be able drop repo download times
> > > for Fedora users.
> >
> > Files in %{_bindir} already end up in the primary metadata, don't they?
>
> Ok, I didn't know that. Do you happen to know if there is
> documentation of what ends up in primary metadata and what not?
>

There is not, but it's generally supposed to be */bin and */lib.





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

Re: Depend on git-core instead of git if possible

[Vít Ondruch]

Dne 03. 11. 20 v 19:07 clime napsal(a):

On Tue, 3 Nov 2020 at 17:42, Florian Weimer  wrote:

Or switch to depend on `%{_bindir}/git`?

If we do it like this, we will never be able drop repo download times
for Fedora users.

Files in %{_bindir} already end up in the primary metadata, don't they?

Ok, I didn't know that. Do you happen to know if there is
documentation of what ends up in primary metadata and what not?



I think this is the only documentation:

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

There is not more insights unfortunately.


Vít




Thank you!
clime


Is this about removing them?  They are just 36,217 lines out of
2,253,333, or something like that.  They also should compress well
(better than all those hashes), so I don't see how they would impact
metadata download times.

Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

___
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

___
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

Re: Depend on git-core instead of git if possible

[clime]

On Tue, 3 Nov 2020 at 17:42, Florian Weimer  wrote:
>
> >> Or switch to depend on `%{_bindir}/git`?
> >
> > If we do it like this, we will never be able drop repo download times
> > for Fedora users.
>
> Files in %{_bindir} already end up in the primary metadata, don't they?

Ok, I didn't know that. Do you happen to know if there is
documentation of what ends up in primary metadata and what not?

Thank you!
clime

> Is this about removing them?  They are just 36,217 lines out of
> 2,253,333, or something like that.  They also should compress well
> (better than all those hashes), so I don't see how they would impact
> metadata download times.
>
> Thanks,
> Florian
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
> O'Neill
___
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

Re: ld segfaults on rawhide

[Justin Forbes]

On Tue, Nov 3, 2020 at 11:17 AM Miro Hrončok  wrote:
>
> On 11/3/20 6:08 PM, Jeff Law wrote:
> >
> > On 11/3/20 9:56 AM, Kevin Fenzi wrote:
> >> On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote:
> >>> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes  
> >>> wrote:
>  On Sat, Oct 31, 2020 at 10:32 AM Jeff Law  wrote:
> >
> > On 10/31/20 9:13 AM, Christoph Junghans wrote:
> >> Hi,
> >>
> >> I am getting the following error on all archs on rawhide:
> >> collect2: fatal error: ld terminated with signal 11 [Segmentation
> >> fault], core dumped
> >> in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411
> >>
> >> any ideas?
> > Given it's happening on multiple architectures, I'd guess its a linker
> > bug of some kind.
> >
>  Definitely seems to be. Killed every arch for the kernel builds today as 
>  well.
> 
> >>> Would it be possible/wise to untag the bad binutils build from rawhide
> >>> until an answer is found here?
> >> Well, it may already be out in yesterdays rawhide?
> >>
> >> I see:
> >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1637660
> >> landed today...
> >>
> >> Does that one work any better?
> >
> > I ping'd Nick on this issue about an hour ago and he indicated it was
> > now fixed in rawhide.
> >
>
> It appears to be fixed in binutils 2.35.1-12.fc34
>
> At least rpm builds again.
>

kernel as well.

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

Re: Depend on git-core instead of git if possible

[Vít Ondruch]

Dne 03. 11. 20 v 17:55 Miro Hrončok napsal(a):

On 11/3/20 5:10 PM, clime wrote:

On Tue, 3 Nov 2020 at 15:40, Vít Ondruch  wrote:



Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a):

On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote:

git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
git.src requires cvs
git-cvs.noarch requires cvs

 ( )
 requires git

Note that if xinetd indeed goes away, your package will most likely 
not be

affected, unless you actually need git-cvs.

Nontheless the packagers should review their packages whether they 
indeed have
to depend on the full-blown git which pulls in Perl and Python. Very 
probably

they could switch to a tinier git-core:


Or switch to depend on `%{_bindir}/git`?


If we do it like this, we will never be able drop repo download times
for Fedora users.

I personally think packages should depend on package names only even
though filelists.xml lazy loading is not yet implemented
(https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7I6HII4Y62BYVU2DEY67VMONJKZENDJC/). 



Actually, several locations end up in primary metadata.

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



And as a side note, it is not recommended to use %{_bindir} in 
buildrequires. The package actually needs /usr/bin/git even if you 
redefine %{_bindir} (e.g. in a flatpak build). However I cannot find 
the discussion about this.




I could find at least discussion in one of package review I did 
recently, but I still disagree. Even for flatpak, it would be better to 
use some prefix such as %{root_bindir} if it was supported.


Anyway, this is OT here. But if somebody decides to propose this into 
guidelines, I'd like to be part of the discussion.



Vít



[1] https://github.com/rpm-software-management/rpm/issues/721
___
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

RFC: Mangle Python shebangs to fully qualified interpreter (/usr/bin/pythonX.Y)

[Neal Gompa]

Hey all,

An "interesting" Linux support issue at work with another Linux
distribution opened my eyes to the possibility of how badly things
would break if /usr/bin/python3 was swapped or otherwise altered by an
external force. In such a scenario where it was overridden to point to
another Python 3 interpreter that wasn't the system one, things would
break pretty badly.

Now that we've been moving toward a model where it becomes possible
for first-party or third-party multi-Python RPMs, I'm wondering if it
would make sense to evolve the shebang mangling for Python to resolve
to the fully qualified Python interpreter path (that is,
/usr/bin/pythonX.Y instead of /usr/bin/pythonX) for packaged Python
code. Presumably this may make things easier for switching Python
versions without everything breaking, too.

In practice, I don't think this is a *huge* issue Fedora-side, since
we don't manage /usr/bin/python3 via alternatives. But I can easily
see people wanting /usr/bin/python3 to be swappable in Red Hat
Enterprise Linux, while everything is still parallel installable and
fully functional. The Python interpreter packaging even mostly
supports this now.

What do y'all think? Is this doable? Is this desirable?


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

Re: ld segfaults on rawhide

[Miro Hrončok]

On 11/3/20 6:08 PM, Jeff Law wrote:


On 11/3/20 9:56 AM, Kevin Fenzi wrote:

On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote:

On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes  wrote:

On Sat, Oct 31, 2020 at 10:32 AM Jeff Law  wrote:


On 10/31/20 9:13 AM, Christoph Junghans wrote:

Hi,

I am getting the following error on all archs on rawhide:
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411

any ideas?

Given it's happening on multiple architectures, I'd guess its a linker
bug of some kind.


Definitely seems to be. Killed every arch for the kernel builds today as well.


Would it be possible/wise to untag the bad binutils build from rawhide
until an answer is found here?

Well, it may already be out in yesterdays rawhide?

I see:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1637660
landed today...

Does that one work any better?


I ping'd Nick on this issue about an hour ago and he indicated it was
now fixed in rawhide.



It appears to be fixed in binutils 2.35.1-12.fc34

At least rpm builds again.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ld segfaults on rawhide

[Jeff Law]

On 11/3/20 9:56 AM, Kevin Fenzi wrote:
> On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote:
>> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes  wrote:
>>> On Sat, Oct 31, 2020 at 10:32 AM Jeff Law  wrote:

 On 10/31/20 9:13 AM, Christoph Junghans wrote:
> Hi,
>
> I am getting the following error on all archs on rawhide:
> collect2: fatal error: ld terminated with signal 11 [Segmentation
> fault], core dumped
> in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411
>
> any ideas?
 Given it's happening on multiple architectures, I'd guess its a linker
 bug of some kind.

>>> Definitely seems to be. Killed every arch for the kernel builds today as 
>>> well.
>>>
>> Would it be possible/wise to untag the bad binutils build from rawhide
>> until an answer is found here?
> Well, it may already be out in yesterdays rawhide?
>
> I see:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1637660
> landed today... 
>
> Does that one work any better?

I ping'd Nick on this issue about an hour ago and he indicated it was
now fixed in rawhide.


jeff

___
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

Re: ld segfaults on rawhide

[Miro Hrončok]

On 10/31/20 4:13 PM, Christoph Junghans wrote:

Hi,

I am getting the following error on all archs on rawhide:
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411

any ideas?


Yes, see:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XH22TZWCLRUC5GOOVH4ZB5QPDRYAN4CJ/

and

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

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ld segfaults on rawhide

[Kevin Fenzi]

On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote:
> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes  wrote:
> >
> > On Sat, Oct 31, 2020 at 10:32 AM Jeff Law  wrote:
> > >
> > >
> > > On 10/31/20 9:13 AM, Christoph Junghans wrote:
> > > > Hi,
> > > >
> > > > I am getting the following error on all archs on rawhide:
> > > > collect2: fatal error: ld terminated with signal 11 [Segmentation
> > > > fault], core dumped
> > > > in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411
> > > >
> > > > any ideas?
> > >
> > > Given it's happening on multiple architectures, I'd guess its a linker
> > > bug of some kind.
> > >
> >
> > Definitely seems to be. Killed every arch for the kernel builds today as 
> > well.
> >
> 
> Would it be possible/wise to untag the bad binutils build from rawhide
> until an answer is found here?

Well, it may already be out in yesterdays rawhide?

I see:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1637660
landed today... 

Does that one work any better?

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

Re: Depend on git-core instead of git if possible

[Miro Hrončok]

On 11/3/20 5:10 PM, clime wrote:

On Tue, 3 Nov 2020 at 15:40, Vít Ondruch  wrote:



Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a):

On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote:

git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
git.src requires cvs
git-cvs.noarch requires cvs

 ( )
 requires git

Note that if xinetd indeed goes away, your package will most likely not be
affected, unless you actually need git-cvs.

Nontheless the packagers should review their packages whether they indeed have
to depend on the full-blown git which pulls in Perl and Python. Very probably
they could switch to a tinier git-core:


Or switch to depend on `%{_bindir}/git`?


If we do it like this, we will never be able drop repo download times
for Fedora users.

I personally think packages should depend on package names only even
though filelists.xml lazy loading is not yet implemented
(https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7I6HII4Y62BYVU2DEY67VMONJKZENDJC/).


Actually, several locations end up in primary metadata.

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

And as a side note, it is not recommended to use %{_bindir} in buildrequires. 
The package actually needs /usr/bin/git even if you redefine %{_bindir} (e.g. in 
a flatpak build). However I cannot find the discussion about this.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Repository metadata signing?

[Kevin Fenzi]

On Tue, Nov 03, 2020 at 03:28:02PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Nov 03, 2020 at 12:24:45AM -0500, Neal Gompa wrote:
> > On Tue, Nov 3, 2020 at 12:16 AM Marek Marczykowski-Górecki
> >  wrote:
> > > Is it possible to enable the first one, but leave the second to the
> > > user, until DNF is adjusted for better UX around the keys? That would
> > > allow power users to enable metadata verification manually (and accept
> > > that key import prompt).
> > >
> > 
> > Yes, this should be possible. File a ticket here:
> > https://pagure.io/fedora-infrastructure
> 
> Opened here: https://pagure.io/fedora-infrastructure/issue/9436

And closed WONTFIX. :( 

Yes, it's possible... but it needs work in both pungi and robosignatory. 
I don't want to speak for others, but I think the people who work on
those normally have a number of higher priority items they are currently
working on.

If you're interested in moving it forward, please work with the
robosignatory and pungi developers (links to the issues on those in the
infra ticket). 

If it gets implmented so we can just turn it on, then I'm happy to look
at doing so. (Although I wouldn't make checking it default until the dnf
issues were ironed out). 

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

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #22 from Tom "spot" Callaway  ---
This is my favorite bug, because I get to see it once a year.

Harald, I cannot reproduce this locally, because the only person who can
trigger it is you. The program you claim triggers the bug (mailgraph) depends
on a working mailserver using syslog, which I do not have (either, a mailserver
or a system using syslog). It also hasn't been updated since 2007.

File::Tail has been abandoned since 2015. 

So, unless you can assist me with a reproduction case that does not involve
installing a mailserver and an archaic logging infrastructure, this bug will be
closed WONTFIX.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora Security Team

[Dominique Martinet]

Marek Marczykowski-Górecki wrote on Tue, Nov 03, 2020:
> Do you know if some parts of the above already exist? I know Debian has
> automatic checks for latest upstream versions, but I haven't seen it in
> Fedora.

Fedora has "Upstream Release Monitoring"

https://fedoraproject.org/wiki/Upstream_release_monitoring

I sometimes see bug automatically opened to notify of new updates but
not for all packages, it looks opt-in ?

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

Re: Depend on git-core instead of git if possible

[Florian Weimer]

>> Or switch to depend on `%{_bindir}/git`?
>
> If we do it like this, we will never be able drop repo download times
> for Fedora users.

Files in %{_bindir} already end up in the primary metadata, don't they?
Is this about removing them?  They are just 36,217 lines out of
2,253,333, or something like that.  They also should compress well
(better than all those hashes), so I don't see how they would impact
metadata download times.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Re: Looking for sponsorship to be a package maintainer

[Kevin Fenzi]

On Mon, Nov 02, 2020 at 10:19:32PM +, Isaac True wrote:
> Hello all,
> 
> I'm hoping to become the maintainer of an orphaned package (gr-iio, GNU Radio 
> blocks for Analog Devices platforms) but I need some sponsorship to become a 
> package maintainer. The releng team recommended that I send a message on this 
> list to hopefully find someone.
> 
> I'm a software engineer and I've built a few .rpm's and .deb's over the 
> years, so I'm already pretty capable at putting together a package. I would 
> love for the opportunity to give back to the Fedora community, and to improve 
> and unorphan a few packages.
> 
> Regarding the gr-iio package, I already know what needs to be done in order 
> to bring it up to speed and compiling on the new Fedora versions, so it 
> wouldn't be too much effort or take too long to get the new version of the 
> package ready.

Could you open a pull request against the package with your fixes?

That should help sponsors see that you know what you are doing packaging
wise. ;) 

https://src.fedoraproject.org/rpms/gr-iio/

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

Re: Fedora Security Team

[Marek Marczykowski-Górecki]

On Tue, Nov 03, 2020 at 10:02:24AM +, P J P wrote:
> * Right, Fedora package CVEs and relevant bugs are filed by Red Hat Product 
> security team.
> 
> * CVEs/bugs are fixed in the upstream sources first. Fedora package 
> maintainers do rebuild
>   of the package with released fixes.

I see currently over 1000 such tracking bugs[1].
I realize it some cases it may be missing upstream fix and it is not a
Fedora package maintainers responsibility to develop a fix (although
anyone can help upstream to develop a fix). But by looking at few random
items there, it seems the fix is available in a subsequent upstream
release and what is missing is just bumping the package version in
Fedora. In some (many?) cases, the newer package is even already there,
but the missing part is closing related tracking bug (and I'd guess the
update lacked info it was a security fix, but I haven't verified that).

There are also many tracking bugs assigned to no longer supported Fedora
version (28 specifically) - have auto-closing bot malfunctioned (I see
a remainder message, but not the actual close)? But in some cases the
bug may still apply to a newer release.

I think some at least some of the above can be automated. CVE do
contain machine-readable affected versions info. Perhaps this can be
used to (scripted) close already fixed bugs? If we can get latest
upstream version automatically, then another set of bugs can be marked
with info like "fixed upstream release available". And similar approach
applied in the future to mark package update as fixing specific CVEs.

Do you know if some parts of the above already exist? I know Debian has
automatic checks for latest upstream versions, but I haven't seen it in
Fedora.

[1] 
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=Fedora_format=advanced_desc=CVE_desc_type=allwordssubstr

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[Bug 1744419] Replace /etc/rc.d/init.d/httpd by systemctl

[bugzilla]

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



--- Comment #3 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1744424] perl-Gtk2-SourceView2-0.10-21.fc31 FTBFS: pkgconfig(gtksourceview-2.0) dependency does not exist

[bugzilla]

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



--- Comment #1 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Depend on git-core instead of git if possible

[clime]

On Tue, 3 Nov 2020 at 15:40, Vít Ondruch  wrote:
>
>
> Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a):
>
> On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote:
>
> git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
> git.src requires cvs
> git-cvs.noarch requires cvs
>
>  ( )
>  requires git
>
> Note that if xinetd indeed goes away, your package will most likely not be
> affected, unless you actually need git-cvs.
>
> Nontheless the packagers should review their packages whether they indeed have
> to depend on the full-blown git which pulls in Perl and Python. Very probably
> they could switch to a tinier git-core:
>
>
> Or switch to depend on `%{_bindir}/git`?

If we do it like this, we will never be able drop repo download times
for Fedora users.

I personally think packages should depend on package names only even
though filelists.xml lazy loading is not yet implemented
(https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7I6HII4Y62BYVU2DEY67VMONJKZENDJC/).

clime

>
>
> Vít
>
>
>
> $ dnf --quiet repoquery --exact --whatrequires git-core |wc -l
> 48
> $ dnf --quiet repoquery --exact --whatrequires git |wc -l
> 91
>
> -- Petr
>
>
> ___
> 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
>
> ___
> 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
___
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

[Bug 1731718] perl-Convert-Color depends on files/directories from non-standard locations

[bugzilla]

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



--- Comment #3 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1731700] rt depends on files/directories from non-standard locations

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: ld segfaults on rawhide

[Justin Forbes]

On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes  wrote:
>
> On Sat, Oct 31, 2020 at 10:32 AM Jeff Law  wrote:
> >
> >
> > On 10/31/20 9:13 AM, Christoph Junghans wrote:
> > > Hi,
> > >
> > > I am getting the following error on all archs on rawhide:
> > > collect2: fatal error: ld terminated with signal 11 [Segmentation
> > > fault], core dumped
> > > in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411
> > >
> > > any ideas?
> >
> > Given it's happening on multiple architectures, I'd guess its a linker
> > bug of some kind.
> >
>
> Definitely seems to be. Killed every arch for the kernel builds today as well.
>

Would it be possible/wise to untag the bad binutils build from rawhide
until an answer is found here?

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

[Bug 1716324] Module::Build lists the object files after the linker flags, causing underlinking with -Wl,--as-needed

[bugzilla]

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



--- Comment #6 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Self Introduction: John Kacur

[Matthew Miller]

On Mon, Nov 02, 2020 at 09:20:40PM -0500, John Kacur wrote:
> I have mostly been a lurker when it comes to Fedora development, but
> hopefully that will change soon!

Welcome, and thanks for de-lurking! Let me know if there's anything I can do
to help!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1666098] Overspecification in perl -MExtUtils::Embed -e ldopts

[bugzilla]

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



--- Comment #4 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1646141] Upgrade perl-HTML-Selector-XPath to 0.25

[bugzilla]

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



--- Comment #7 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1643855] Upgrade perl-prefork to 1.05

[bugzilla]

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



--- Comment #5 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #21 from Harald Reindl  ---
i am tired about that thoughtless "end of life" actions when damned bugs don't
get fixed over *five years*


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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

Harald Reindl  changed:

   What|Removed |Added

Version|31  |32




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1522685] Upgrade perl-Authen-Krb5 to 1.903

[bugzilla]

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



--- Comment #4 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #20 from Ben Cotton  ---
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: EOL and Obsoletes in Modularity

[Petr Pisar]

On Tue, Nov 03, 2020 at 03:22:45PM +0100, Vít Ondruch wrote:
> Have anybody considered to use AppData for that information? Or at least
> similar approach?
> 
I haven't. AppData looks very similar to our use case. Thanks for the pointer.

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

Re: Depend on git-core instead of git if possible

[Vít Ondruch]

Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a):

On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote:

git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
git.src requires cvs
git-cvs.noarch requires cvs

 ( )
 requires git

Note that if xinetd indeed goes away, your package will most likely not be
affected, unless you actually need git-cvs.


Nontheless the packagers should review their packages whether they indeed have
to depend on the full-blown git which pulls in Perl and Python. Very probably
they could switch to a tinier git-core:



Or switch to depend on `%{_bindir}/git`?


Vít




$ dnf --quiet repoquery --exact --whatrequires git-core |wc -l
48
$ dnf --quiet repoquery --exact --whatrequires git |wc -l
91

-- Petr

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

Re: Repository metadata signing?

[Marek Marczykowski-Górecki]

On Tue, Nov 03, 2020 at 12:24:45AM -0500, Neal Gompa wrote:
> On Tue, Nov 3, 2020 at 12:16 AM Marek Marczykowski-Górecki
>  wrote:
> > Is it possible to enable the first one, but leave the second to the
> > user, until DNF is adjusted for better UX around the keys? That would
> > allow power users to enable metadata verification manually (and accept
> > that key import prompt).
> >
> 
> Yes, this should be possible. File a ticket here:
> https://pagure.io/fedora-infrastructure

Opened here: https://pagure.io/fedora-infrastructure/issue/9436

> > Is there any dnf command similar to `rpm --import`, to preemptively
> > import the key, or the only option is to accept the prompt? I can't find
> > anything about it in dnf's man page...
> >
> 
> Alas, no. That's part of the problem here.

Ah, I see...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Depend on git-core instead of git if possible

[Petr Pisar]

On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote:
>   git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
>   git.src requires cvs
>   git-cvs.noarch requires cvs
> 
>( )
>requires git
> 
> Note that if xinetd indeed goes away, your package will most likely not be
> affected, unless you actually need git-cvs.
> 
Nontheless the packagers should review their packages whether they indeed have
to depend on the full-blown git which pulls in Perl and Python. Very probably
they could switch to a tinier git-core:

$ dnf --quiet repoquery --exact --whatrequires git-core |wc -l
48
$ dnf --quiet repoquery --exact --whatrequires git |wc -l
91

-- Petr


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: EOL and Obsoletes in Modularity

[Vít Ondruch]

Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a):

On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote:

Daniel Mach  writes:

The API is clear: DNF expects additional 'modulemd-obsoletes' YAML
documents in modules.yaml. The new document format is getting into
libmodulemd and there's going to be documentation on how to write it.

Then there's a question how to get the documents into modules.yaml. From
my perspective, it's up to Fedora infra/releng/packaging people. Whether
it should be in dist-git, git repo (similar to modulemd-defaults or
comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's
entirely their call.

I think the package/module maintainer should be able to set the EOL and
obsoletes for their module in a simple fashion, preferably without
requiring to create tickets for releng or anyone else. So that leaves
dist-git as the only option, right?


I also like the idea of having EOL data in dist-git in hands of the packagers.

The problem is that a compose process run by relengs does not use dist-git at
all. It picks up builds from Koji and data from various git repositories. The
various git repositores is where the module default profiles live. Problem is
that the various repositories are not dist-git. They have a rigid commit
access by a few people. Those are not packagers.

We could create a dedicated repository in dist-git for collecting the EOL data
from various module maintainers and give the module maintainers a commit
access there. But the problem with dist-git is that a special repository does
not fit into the namespace schemata (rpms, modules, tests).

We could create a dedicated repository on pagure.io instead, give maintainers
a commit access there (the account system is shared with Fedora, I think) and
confugure pungi (a tool run by relengs to make composes) to read EOL data from
there. But there still had to be a manual step of granting the commit access.

Another option would be adding the EOL data into modules dist-git
repositories. To the same branches where modules are built from. But
a different file. Pungi would enumarate all module builds directed to
a compose, locate their dist-git sources by mapping name:stream to
git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
there. That would enable module maintains to control EOLs simply by pushing an
eol.yaml file into the branch of the module.

Wouldn't relengs object that it's not accountable because the EOL data can be
updated asynchrously of module builds and tagging in Koji? And isn't that what
we want to acheive -- EOL data independent from the module builds?

Alternatively we could append EOL YAML document to modulemd YAML document in
the dist-git (a YAML file can contain multiple YAML documents) and rebuild the
build. That way the EOL data would get together with the modulmd to Koji
and to the compose. But that would bind the EOL data to module builds. If we
wanted to EOL a module stream, we would have to make an unnecessary module
build. Would it be still worthwile?

-- Petr



Have anybody considered to use AppData for that information? Or at least 
similar approach?



Vít
___
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

[389-devel] Re: stable/dev branches

[Stanislav Levin]

03.11.2020 15:58, Mark Reynolds пишет:
> 
> On 11/3/20 4:41 AM, Stanislav Levin wrote:
>> Hello.
>>
>> Currently, I package 1.4.1 branch as the former-stable for ALTLinux.
>> But it is not updated since July, too stable?
>>
>>
>> 1.4.x branches in upstream:
>>
>>   upstream/389-ds-base-1.4.1
> This is no longer being maintained
>>   upstream/389-ds-base-1.4.2
> This branch is about to stop being maintained
>>   upstream/389-ds-base-1.4.3
> This would be the "most" stable branch at this time.
>>   upstream/389-ds-base-1.4.4
>>   upstream/master
> 
> 1.4.4 and master (2.0.0) are not "stable" and include more cutting edge
> changes and features.
> 
> HTH,
> 
> Mark

It would be much appreciated such future changes will be announced at
time. I think the other distro-packagers need this information too.

Thank you very much!


OpenPGP_0xABABFE8D5D9A19E8.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: EOL and Obsoletes in Modularity

[Petr Pisar]

On Tue, Nov 03, 2020 at 02:17:59PM +0100, Petr Šabata wrote:
> On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar  wrote:
> > Another option would be adding the EOL data into modules dist-git
> > repositories. To the same branches where modules are built from. But
> > a different file. Pungi would enumarate all module builds directed to
> > a compose, locate their dist-git sources by mapping name:stream to
> > git://src.fedoraproject/org/modules/name.git#stream and download EOL data 
> > from
> > there. That would enable module maintains to control EOLs simply by pushing 
> > an
> > eol.yaml file into the branch of the module.
> 
> This is not a reliable method as the branch name can be anything if
> stream name is defined in modulemd. Technically even the repository name
> can be anything.
>
I know. But In my option it's a problem of the module maintainer. (Doctor, it
hurts when I stab a needle into my eye! Doctor: Then don't do it.)

And even we had such a module build, the EOL format can be abused the same
way. You can EOL/obsolete foreign module:stream. Technically it can be misued
the same way to EOL a module build with overriden module:stream. You only need
to find a victim module repository to put it into. At the end, we already have
a fedora-osbolete-packages package. We can have fedora-obsolete-modules module
for the purpose of EOLing misnamed module builds.

In my opinion it's only a matter of policy.

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

Re: EOL and Obsoletes in Modularity

[Petr Šabata]

On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar  wrote:
> Another option would be adding the EOL data into modules dist-git
> repositories. To the same branches where modules are built from. But
> a different file. Pungi would enumarate all module builds directed to
> a compose, locate their dist-git sources by mapping name:stream to
> git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
> there. That would enable module maintains to control EOLs simply by pushing an
> eol.yaml file into the branch of the module.

This is not a reliable method as the branch name can be anything if
stream name is defined in modulemd. Technically even the repository name
can be anything.

You could look at the xmd section and check out the relevant commit used
to build it. That would imply you couldn't change EOL for already
built artifacts,
however. Only new ones.

Also I don't remember if xmd gets stripped during compose. If so, pungi
would need to ask MBS or Koji about every build.

P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1894057] New: perl-CPANPLUS-Dist-Fedora-0.4.1 is available

[bugzilla]

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

Bug ID: 1894057
   Summary: perl-CPANPLUS-Dist-Fedora-0.4.1 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPANPLUS-Dist-Fedora
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.4.1
Current version/release in rawhide: 0.4.0-1.fc34
URL: http://search.cpan.org/dist/CPANPLUS-Dist-Fedora/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/5882/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] Re: stable/dev branches

[Mark Reynolds]

On 11/3/20 4:41 AM, Stanislav Levin wrote:

Hello.

Currently, I package 1.4.1 branch as the former-stable for ALTLinux.
But it is not updated since July, too stable?


1.4.x branches in upstream:

   upstream/389-ds-base-1.4.1

This is no longer being maintained

   upstream/389-ds-base-1.4.2

This branch is about to stop being maintained

   upstream/389-ds-base-1.4.3

This would be the "most" stable branch at this time.

   upstream/389-ds-base-1.4.4
   upstream/master


1.4.4 and master (2.0.0) are not "stable" and include more cutting edge 
changes and features.


HTH,

Mark




Any plans on supporting these?
Which one is stable now?

Thanks.

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: EOL and Obsoletes in Modularity

[Daniel Mach]

Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a):

On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote:

Daniel Mach  writes:

The API is clear: DNF expects additional 'modulemd-obsoletes' YAML
documents in modules.yaml. The new document format is getting into
libmodulemd and there's going to be documentation on how to write it.

Then there's a question how to get the documents into modules.yaml. From
my perspective, it's up to Fedora infra/releng/packaging people. Whether
it should be in dist-git, git repo (similar to modulemd-defaults or
comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's
entirely their call.


I think the package/module maintainer should be able to set the EOL and
obsoletes for their module in a simple fashion, preferably without
requiring to create tickets for releng or anyone else. So that leaves
dist-git as the only option, right?


I also like the idea of having EOL data in dist-git in hands of the packagers.

The problem is that a compose process run by relengs does not use dist-git at
all. It picks up builds from Koji and data from various git repositories. The
various git repositores is where the module default profiles live. Problem is
that the various repositories are not dist-git. They have a rigid commit
access by a few people. Those are not packagers.

We could create a dedicated repository in dist-git for collecting the EOL data
from various module maintainers and give the module maintainers a commit
access there. But the problem with dist-git is that a special repository does
not fit into the namespace schemata (rpms, modules, tests).

We could create a dedicated repository on pagure.io instead, give maintainers
a commit access there (the account system is shared with Fedora, I think) and
confugure pungi (a tool run by relengs to make composes) to read EOL data from
there. But there still had to be a manual step of granting the commit access.

Another option would be adding the EOL data into modules dist-git
repositories. To the same branches where modules are built from. But
a different file. Pungi would enumarate all module builds directed to
a compose, locate their dist-git sources by mapping name:stream to
git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
there. That would enable module maintains to control EOLs simply by pushing an
eol.yaml file into the branch of the module.

Wouldn't relengs object that it's not accountable because the EOL data can be
updated asynchrously of module builds and tagging in Koji? And isn't that what
we want to acheive -- EOL data independent from the module builds?

Alternatively we could append EOL YAML document to modulemd YAML document in
the dist-git (a YAML file can contain multiple YAML documents) and rebuild the
build. That way the EOL data would get together with the modulmd to Koji
and to the compose. But that would bind the EOL data to module builds. If we
wanted to EOL a module stream, we would have to make an unnecessary module
build. Would it be still worthwile?

-- Petr


Thanks for your write-up, it perfectly describes the workflow issues and 
challenges.


The mapping from dist-git to compose or bodhi update is not entirely 
straightforward. It starts when a package is built and tagged in a tag 
associated with a release. That makes me think that extending this to 
modulemd-obsoletes could also work, but that would require "building" (a 
simple import from dist-git to the build system might be sufficient) and 
tagging them in the build system. That would allow tagging the 
modulemd-obsoletes for a compose or attaching them to a bodhi update. 
There's only one if - if someone could extend the infra tools to support 
this new content...


The non-dist-git git repos with limited access are a workaround for lack 
of tagging support - you simply export the repo content and include it 
where you need without tagging / cherry-picking / organizing content in 
the build system.

___
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

[Bug 1893759] perl-DBD-Mock-1.58 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1893759] perl-DBD-Mock-1.58 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1893873] perl-CPANPLUS-Dist-Fedora-0.4.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-CPANPLUS-Dist-Fedora-0
   ||.4.0-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-03 12:05:31




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1893759] perl-DBD-Mock-1.58 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-DBD-Mock-1.58-1.fc34



--- Comment #2 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 32.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1893759] perl-DBD-Mock-1.58 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Repository metadata signing?

[Colin Walters]

On Tue, Nov 3, 2020, at 12:16 AM, Marek Marczykowski-Górecki wrote:

> Is there any dnf command similar to `rpm --import`, to preemptively
> import the key, or the only option is to accept the prompt? I can't find
> anything about it in dnf's man page...

See also https://github.com/rpm-software-management/libdnf/issues/43
___
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

Re: EOL and Obsoletes in Modularity

[Petr Pisar]

On Mon, Nov 02, 2020 at 12:33:23PM +0100, Daniel Mach wrote:
> From DNF team's perspective, a packaging system is not complete without
> Obsoletes. That's why we believe module Obsoletes are a must have to ensure
> smooth system upgrades and regular updates on systems consuming Rawhide (or
> any other rolling stream). I created a Fedora Change[1] which got accepted
> already. We'll deliver support for module Obsoletes in DNF as soon as
> possible and we hope it's going to be used in Fedora 34 (or 35 at latest).
> 
[...]
> [1]
> https://fedoraproject.org/w/index.php?title=Changes/Module_Obsoletes_and_EOL

Do you read a discussion for that page? Or where can I comment on the format
of the EOL data? 

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

Re: EOL and Obsoletes in Modularity

[Petr Pisar]

On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote:
> Daniel Mach  writes:
> > The API is clear: DNF expects additional 'modulemd-obsoletes' YAML 
> > documents in modules.yaml. The new document format is getting into 
> > libmodulemd and there's going to be documentation on how to write it.
> >
> > Then there's a question how to get the documents into modules.yaml. From 
> > my perspective, it's up to Fedora infra/releng/packaging people. Whether 
> > it should be in dist-git, git repo (similar to modulemd-defaults or 
> > comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's 
> > entirely their call.
> 
> I think the package/module maintainer should be able to set the EOL and
> obsoletes for their module in a simple fashion, preferably without
> requiring to create tickets for releng or anyone else. So that leaves
> dist-git as the only option, right?
> 
I also like the idea of having EOL data in dist-git in hands of the packagers.

The problem is that a compose process run by relengs does not use dist-git at
all. It picks up builds from Koji and data from various git repositories. The
various git repositores is where the module default profiles live. Problem is
that the various repositories are not dist-git. They have a rigid commit
access by a few people. Those are not packagers.

We could create a dedicated repository in dist-git for collecting the EOL data
from various module maintainers and give the module maintainers a commit
access there. But the problem with dist-git is that a special repository does
not fit into the namespace schemata (rpms, modules, tests).

We could create a dedicated repository on pagure.io instead, give maintainers
a commit access there (the account system is shared with Fedora, I think) and
confugure pungi (a tool run by relengs to make composes) to read EOL data from
there. But there still had to be a manual step of granting the commit access.

Another option would be adding the EOL data into modules dist-git
repositories. To the same branches where modules are built from. But
a different file. Pungi would enumarate all module builds directed to
a compose, locate their dist-git sources by mapping name:stream to
git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
there. That would enable module maintains to control EOLs simply by pushing an
eol.yaml file into the branch of the module.

Wouldn't relengs object that it's not accountable because the EOL data can be
updated asynchrously of module builds and tagging in Koji? And isn't that what
we want to acheive -- EOL data independent from the module builds?

Alternatively we could append EOL YAML document to modulemd YAML document in
the dist-git (a YAML file can contain multiple YAML documents) and rebuild the
build. That way the EOL data would get together with the modulmd to Koji
and to the compose. But that would bind the EOL data to module builds. If we
wanted to EOL a module stream, we would have to make an unnecessary module
build. Would it be still worthwile?

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

Re: Packaging rules for build from source vs BPF byte code ?

[Vitaly Zaitsev via devel]

On 03.11.2020 11:48, Daniel P. Berrangé wrote:

We do have the exception that allows firmware to be shipped as
pre-built blobs, but I'm thinking that BPF programs could not
be considered as firmware.


According to Fedora packaging guidelines, all packages must be built 
from sources. No exceptions. BPF is not a firmware.


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

Re: Packaging rules for build from source vs BPF byte code ?

[Daniel P . Berrangé]

On Tue, Nov 03, 2020 at 11:13:53AM +, Daniel P. Berrangé wrote:
> On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote:
> > On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé  
> > wrote:
> > >
> > > In QEMU there's a desire to make use of BPF programs for implementing
> > > some networking features. The current patches are proposing adding
> > > prebuilt BPF byte code to the QEMU repo, with source available, but
> > > not actually building from source during a build.
> > >
> > > I was wondering if we had any specific guidance or rules covering the
> > > shipping BPF programs in particular ?
> > >
> > > To me it feels like BPF programs should fall under normal Fedora
> > > practice that expects everything to be built from master source.
> > >
> > > We do have the exception that allows firmware to be shipped as
> > > pre-built blobs, but I'm thinking that BPF programs could not
> > > be considered as firmware.
> > >
> > > Has this been discussed before, if so can someone point to the
> > > results, as I'm not finding anything specific to BPF programs and
> > > Fedora packaging via Google.
> > >
> > > Regards,
> > > Daniel
> > 
> > If there are no specialized Packaging Guidelines for something, then
> > the general guidelines apply - so in this case, compiling from source
> > is required, since Fedora packages MUST NOT ship precompiled binaries.
> > 
> > Side note: Regarding BPF programs - I seem to remember that recent
> > kernel security features (the Lockdown patches?) restricted and/or
> > disabled the ability to run BPF programs at all. Have you considered
> > that by default, those BPF programs might not be able to run under the
> > Fedora default configuration?
> 
> Yes, that is one of the issues raised upstream by other people.

BPF appears to only be restricted if lockdown is running in
"confidentiality mode", not "integrity mode", with the latter
used in Fedora now according to

https://bugzilla.redhat.com/show_bug.cgi?id=1815571#c3

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

Re: Packaging rules for build from source vs BPF byte code ?

[Florian Weimer]

* Daniel P. Berrangé:

> On Tue, Nov 03, 2020 at 11:58:32AM +0100, Florian Weimer wrote:
>> * Daniel P. Berrangé:
>> 
>> > In QEMU there's a desire to make use of BPF programs for implementing
>> > some networking features. The current patches are proposing adding 
>> > prebuilt BPF byte code to the QEMU repo, with source available, but
>> > not actually building from source during a build.
>> >
>> > I was wondering if we had any specific guidance or rules covering the
>> > shipping BPF programs in particular ?
>> 
>> Is this even technically feasible?  I don't think the kernel presents a
>> stable interface to BPF programs.
>
> I'm not sure to be honest, but I'll raise that as a question to the
> patch submitter. I'm not very familiar with BPF, just saw the suggestion
> to ship pre-built BPF bytecode and was concerned this would not be
> acceptable for Fedora.

Is this about ebpf/rss.bpf.c?  It looks more like an attempt to bypass
the Fedora kernel module policy.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Re: Packaging rules for build from source vs BPF byte code ?

[Daniel P . Berrangé]

On Tue, Nov 03, 2020 at 11:58:32AM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > In QEMU there's a desire to make use of BPF programs for implementing
> > some networking features. The current patches are proposing adding 
> > prebuilt BPF byte code to the QEMU repo, with source available, but
> > not actually building from source during a build.
> >
> > I was wondering if we had any specific guidance or rules covering the
> > shipping BPF programs in particular ?
> 
> Is this even technically feasible?  I don't think the kernel presents a
> stable interface to BPF programs.

I'm not sure to be honest, but I'll raise that as a question to the
patch submitter. I'm not very familiar with BPF, just saw the suggestion
to ship pre-built BPF bytecode and was concerned this would not be
acceptable for Fedora.

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

Re: Packaging rules for build from source vs BPF byte code ?

[Daniel P . Berrangé]

On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote:
> On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé  
> wrote:
> >
> > In QEMU there's a desire to make use of BPF programs for implementing
> > some networking features. The current patches are proposing adding
> > prebuilt BPF byte code to the QEMU repo, with source available, but
> > not actually building from source during a build.
> >
> > I was wondering if we had any specific guidance or rules covering the
> > shipping BPF programs in particular ?
> >
> > To me it feels like BPF programs should fall under normal Fedora
> > practice that expects everything to be built from master source.
> >
> > We do have the exception that allows firmware to be shipped as
> > pre-built blobs, but I'm thinking that BPF programs could not
> > be considered as firmware.
> >
> > Has this been discussed before, if so can someone point to the
> > results, as I'm not finding anything specific to BPF programs and
> > Fedora packaging via Google.
> >
> > Regards,
> > Daniel
> 
> If there are no specialized Packaging Guidelines for something, then
> the general guidelines apply - so in this case, compiling from source
> is required, since Fedora packages MUST NOT ship precompiled binaries.
> 
> Side note: Regarding BPF programs - I seem to remember that recent
> kernel security features (the Lockdown patches?) restricted and/or
> disabled the ability to run BPF programs at all. Have you considered
> that by default, those BPF programs might not be able to run under the
> Fedora default configuration?

Yes, that is one of the issues raised upstream by other people.

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

Re: Packaging rules for build from source vs BPF byte code ?

[Fabio Valentini]

On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé  wrote:
>
> In QEMU there's a desire to make use of BPF programs for implementing
> some networking features. The current patches are proposing adding
> prebuilt BPF byte code to the QEMU repo, with source available, but
> not actually building from source during a build.
>
> I was wondering if we had any specific guidance or rules covering the
> shipping BPF programs in particular ?
>
> To me it feels like BPF programs should fall under normal Fedora
> practice that expects everything to be built from master source.
>
> We do have the exception that allows firmware to be shipped as
> pre-built blobs, but I'm thinking that BPF programs could not
> be considered as firmware.
>
> Has this been discussed before, if so can someone point to the
> results, as I'm not finding anything specific to BPF programs and
> Fedora packaging via Google.
>
> Regards,
> Daniel

If there are no specialized Packaging Guidelines for something, then
the general guidelines apply - so in this case, compiling from source
is required, since Fedora packages MUST NOT ship precompiled binaries.

Side note: Regarding BPF programs - I seem to remember that recent
kernel security features (the Lockdown patches?) restricted and/or
disabled the ability to run BPF programs at all. Have you considered
that by default, those BPF programs might not be able to run under the
Fedora default configuration?

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

Re: Packaging rules for build from source vs BPF byte code ?

[Florian Weimer]

* Daniel P. Berrangé:

> In QEMU there's a desire to make use of BPF programs for implementing
> some networking features. The current patches are proposing adding 
> prebuilt BPF byte code to the QEMU repo, with source available, but
> not actually building from source during a build.
>
> I was wondering if we had any specific guidance or rules covering the
> shipping BPF programs in particular ?

Is this even technically feasible?  I don't think the kernel presents a
stable interface to BPF programs.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Re: Fedora 33 redhat-rpm-config package update stuck in pending

[Fabio Valentini]

On Tue, Nov 3, 2020 at 11:52 AM Florian Weimer  wrote:
>
> * Fabio Valentini:
>
> > On Tue, Nov 3, 2020 at 10:13 AM Florian Weimer  wrote:
> >>
> >> This update:
> >>
> >>   
> >>
> >> appears to be stuck in the pending state.
> >>
> >> What can I do to move it forward?
> >>
> >> Thanks,
> >> Florian
> >
> > There's an "Actions" dropdown next to the update's state, which
> > contains a "Push to testing" button.
> > I've pushed that button for you, it looks like the update has been
> > poked into the "pending testing" state successfully now.
>
> Thanks.  I did not see that dropdown with my level of Bodhi permissions.

We share the same permissions (packager+provenpackager), so I assume
bodhi was waiting for the build to be signed before showing the
dropdown, or something like that.

> Does bug state matter to Bodhi?

I don't think bodhi looks at a bug's state at all, as far as I can
tell, it only *writes* to bugzilla, but doesn't *read* bug information
(other than the title, for displaying it in bodhi).

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

Depend on git-core instead of git if possible

[Petr Pisar]

On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote:
>   git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
>   git.src requires cvs
>   git-cvs.noarch requires cvs
> 
>( )
>requires git
> 
> Note that if xinetd indeed goes away, your package will most likely not be
> affected, unless you actually need git-cvs.
> 
Nontheless the packagers should review their packages whether they indeed have
to depend on the full-blown git which pulls in Perl and Python. Very probably
they could switch to a tinier git-core:

$ dnf --quiet repoquery --exact --whatrequires git-core |wc -l
48
$ dnf --quiet repoquery --exact --whatrequires git |wc -l
91

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

Re: Fedora 33 redhat-rpm-config package update stuck in pending

[Florian Weimer]

* Fabio Valentini:

> On Tue, Nov 3, 2020 at 10:13 AM Florian Weimer  wrote:
>>
>> This update:
>>
>>   
>>
>> appears to be stuck in the pending state.
>>
>> What can I do to move it forward?
>>
>> Thanks,
>> Florian
>
> There's an "Actions" dropdown next to the update's state, which
> contains a "Push to testing" button.
> I've pushed that button for you, it looks like the update has been
> poked into the "pending testing" state successfully now.

Thanks.  I did not see that dropdown with my level of Bodhi permissions.

Does bug state matter to Bodhi?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Packaging rules for build from source vs BPF byte code ?

[Daniel P . Berrangé]

In QEMU there's a desire to make use of BPF programs for implementing
some networking features. The current patches are proposing adding 
prebuilt BPF byte code to the QEMU repo, with source available, but
not actually building from source during a build.

I was wondering if we had any specific guidance or rules covering the
shipping BPF programs in particular ?

To me it feels like BPF programs should fall under normal Fedora
practice that expects everything to be built from master source.

We do have the exception that allows firmware to be shipped as
pre-built blobs, but I'm thinking that BPF programs could not
be considered as firmware.

Has this been discussed before, if so can someone point to the
results, as I'm not finding anything specific to BPF programs and
Fedora packaging via Google.

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

Re: Fedora 33 redhat-rpm-config package update stuck in pending

[Fabio Valentini]

On Tue, Nov 3, 2020 at 10:13 AM Florian Weimer  wrote:
>
> This update:
>
>   
>
> appears to be stuck in the pending state.
>
> What can I do to move it forward?
>
> Thanks,
> Florian

There's an "Actions" dropdown next to the update's state, which
contains a "Push to testing" button.
I've pushed that button for you, it looks like the update has been
poked into the "pending testing" state successfully now.

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

[Bug 1893586] perl-IO-Pager-2.01 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-IO-Pager-2.01-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-03 10:25:30



--- Comment #2 from Petr Pisar  ---
This renamed prompt() method. Suitable for Rawhide only.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora Security Team

[P J P]

Hello Marek,

On Tuesday, 3 November, 2020, 5:38:39 am IST, Michael Catanzaro 
 wrote: 
>On Tue, Nov 3, 2020 at 12:53 am, Marek Marczykowski-Górecki 
> wrote:
>> How are in practice security issues handled in Fedora? Is there an
>> active security team to help patching those in timely manner? Or is it
>> responsibility of individual package maintainers only?
>
>Red Hat Product Security is responsible for monitoring CVEs and 
>reporting bugs when they determine that a CVE affects Fedora. Fixing 
>the CVEs is the responsibility of individual package maintainers. Many 
>maintainers respond to bugs expeditiously, but also it's pretty common 
>for maintainers to ignore the bug reports filed by Product Security. 
>Sometimes this has unfortunate results. It really differs on a 
>component-by-component basis.

* Right, Fedora package CVEs and relevant bugs are filed by Red Hat Product 
security team.

* CVEs/bugs are fixed in the upstream sources first. Fedora package maintainers 
do rebuild
  of the package with released fixes.

* Often, Fedora package maintainer is also an upstream developer/maintainer.
  It helps to fix issues sooner.

* Fedora security team was more looking into auditing and improving Fedora 
distribution security
  via safe default configurations and policies etc. While also following up 
with maintainers
  for fixing CVE bugs sooner.


Thank you.
---
  -P J P
http://feedmug.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1893873] perl-CPANPLUS-Dist-Fedora-0.4.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|i...@cicku.me  |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] stable/dev branches

[Stanislav Levin]

Hello.

Currently, I package 1.4.1 branch as the former-stable for ALTLinux.
But it is not updated since July, too stable?


1.4.x branches in upstream:

  upstream/389-ds-base-1.4.1
  upstream/389-ds-base-1.4.2
  upstream/389-ds-base-1.4.3
  upstream/389-ds-base-1.4.4
  upstream/master


Any plans on supporting these?
Which one is stable now?

Thanks.


OpenPGP_0xABABFE8D5D9A19E8.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Retiring ntp

[Miroslav Lichvar]

On Mon, Nov 02, 2020 at 09:52:59PM +, Gary Buhrmaster wrote:
> On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia  wrote:
> 
> > So, use "chrony" instead?
> 
> For some use cases, there is also the option of
> systemd-timesyncd as a ntp client.

timesyncd is a very minimal NTP client. It can be recommended in some
specific use cases, like a local network with a trusted server, but
not in the most common case of a client using random public servers on
Internet. There are other minimal clients that should be considered
before timesyncd, e.g. openntpd or the busybox ntpd.

> > and can the ntp.conf files be ported gracefully to a
> > compatible chrony.conf setting?

In the vast majority of cases, yes, it can. There is even a ntp2chrony
script for automatic conversion.

The most common thing that people seem to miss is the mode-6 protocol,
which is needed by some monitoring tools. That won't be supported in
chrony, but it is in ntpsec.

Autokey has been superseded by NTS.

Broadcast/multicast modes are better supported by PTP (linuxptp).

> If you are using hardware to discipline your server
> using one/more of the hardware specific drivers
> things get more complicated.

Reference clocks shouldn't be a big issue. The refclock drivers from
ntp will stay in Fedora, at least for now, in the ntp-refclock
package. In future it might need to be switched to the ntpsec drivers.
For GPS receivers, which are by far the most common reference clocks,
there is also gpsd.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20201103.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20201102.0):

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

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 redhat-rpm-config package update stuck in pending

[Florian Weimer]

This update:

  

appears to be stuck in the pending state.

What can I do to move it forward?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

[Bug 1893586] perl-IO-Pager-2.01 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Self Introduction: John Kacur

[Dominik 'Rathann' Mierzejewski]

Hello, John!

On Tuesday, 03 November 2020 at 03:20, John Kacur wrote:
> Hello. My name is John Kacur
> I'm a real-time developer with Red Hat, who I've been with for over 11 years.
> Before that I worked for approximately 8 years with IBM on the compiler team.
> 
> I am the upstream co-maintainer of rt-tests that includes cyclictest
> for real-time latency testing.
> I am also the upstream co-maintainer of rteval that tests the ability
> of hardware to run the real-time kernel.
> I am also the RH packager of the above packages.
> 
> I am also an upstream co-maintainer of tuna, python-schedutils and
> python-linux-procutils, and the RH packager of these packages as well.
> 
> There are probably a few other things that are relevant, but the most
> important ones are listed above.

Interesting stuff. Welcome to Fedora!

> I have mostly been a lurker when it comes to Fedora development, but
> hopefully that will change soon!

We're looking forward to your contributions. :)

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

Re: Deprecating SCP

[Jakub Jelen]

On 11/2/20 10:29 PM, David Howells wrote:

Jakub Jelen  wrote:


Today, I set up a copr repository with the current openssh from Fedora + the
patch [2] for anyone to test and provide feedback, either here on the mailing
list, or in the github PR according to ones preferences.


Does it work with connection sharing (ControlPath, ControlMaster,
ControlPersist config options)?


It should keep working the same way as it worked before with scp.

Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
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