date:20210303

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

Product Security DevOps Team  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |UPSTREAM
Last Closed||2021-03-04 01:01:56



--- Comment #2 from Product Security DevOps Team  ---
This CVE Bugzilla entry is for community support informational purposes only as
it does not affect a package in a commercially supported Red Hat product. Refer
to the dependent bugs for status of those individual community products.


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1933852] perl-Locale-Codes-3.67 is available

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



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

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


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

[Bug 1931135] perl-Module-CoreList-5.20210220 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021
   |0220-1.fc35 |0220-1.fc35
   |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021
   |0220-1.fc34 |0220-1.fc34
   ||perl-Module-CoreList-5.2021
   ||0220-1.fc32
 Resolution|--- |ERRATA
Last Closed||2021-03-03 23:24:46



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-2fd7bd74cc has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1890793] EPEL8 Request: perl-Devel-REPL

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2021-9131b38ccb has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9131b38ccb

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


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

Re: Bodhi client prompting for a password

2021-03-03 Thread Björn Persson

Fabio Valentini wrote:
> On Wed, Mar 3, 2021 at 9:31 PM Miro Hrončok  wrote:
> >
> > On 03. 03. 21 21:08, Florian Weimer wrote:  
> > > I want to run this command:
> > >
> > >bodhi updates trigger-tests FEDORA-2021-279dee1742
> > >
> > > But I'm prompted for a username and password.  I have a working Kerberos
> > > setup for koji/fedpkg, so this is somewhat surprising.  Is this
> > > expected?  
> >
> > Yes, that is how bodhi CLI client works.  
> 
> Yes. Sadly, most Fedora projects use different methods for
> authenticating with your FAS account.
> 
> koji uses kerberos, bodhi uses OpenID over HTTP, dist-git uses SSH ...

It wouldn't be a user interface problem if they'd all fetch the
passcode from the same keyring. Then the user wouldn't need to know how
many different protocols are used under the hood.

Björn Persson


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

[Bug 1933914] perl-Data-Printer-1.000004 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Data-Printer-1.03  |perl-Data-Printer-1.04
   |is available|is available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.04
Current version/release in rawhide: 1.01-1.fc35
URL: http://search.cpan.org/dist/Data-Printer/

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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi client prompting for a password

2021-03-03 Thread Kevin Fenzi

On Wed, Mar 03, 2021 at 11:36:17PM +0100, Fabio Valentini wrote:
> On Wed, Mar 3, 2021 at 9:31 PM Miro Hrončok  wrote:
> >
> > On 03. 03. 21 21:08, Florian Weimer wrote:
> > > I want to run this command:
> > >
> > >bodhi updates trigger-tests FEDORA-2021-279dee1742
> > >
> > > But I'm prompted for a username and password.  I have a working Kerberos
> > > setup for koji/fedpkg, so this is somewhat surprising.  Is this
> > > expected?
> >
> > Yes, that is how bodhi CLI client works.
> 
> Yes. Sadly, most Fedora projects use different methods for
> authenticating with your FAS account.

yep. ;( 

> koji uses kerberos, bodhi uses OpenID over HTTP, dist-git uses SSH ...

dist-git can also use https/OIDC token. 

> Which is why the bodhi client needs to use your username and password
> (because it basically uses a web login form).
> But I don't know how the upcoming switch from FAS2 to noggin will
> affect those things.

Mostly not much, but we are pondering on if we want to change dist-git
ssh some at that point (as it has some anoying side effects). 

kevin


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

[Bug 1933852] perl-Locale-Codes-3.67 is available

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



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

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


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

Re: Bodhi client prompting for a password

2021-03-03 Thread Fabio Valentini

On Wed, Mar 3, 2021 at 9:31 PM Miro Hrončok  wrote:
>
> On 03. 03. 21 21:08, Florian Weimer wrote:
> > I want to run this command:
> >
> >bodhi updates trigger-tests FEDORA-2021-279dee1742
> >
> > But I'm prompted for a username and password.  I have a working Kerberos
> > setup for koji/fedpkg, so this is somewhat surprising.  Is this
> > expected?
>
> Yes, that is how bodhi CLI client works.

Yes. Sadly, most Fedora projects use different methods for
authenticating with your FAS account.

koji uses kerberos, bodhi uses OpenID over HTTP, dist-git uses SSH ...
Which is why the bodhi client needs to use your username and password
(because it basically uses a web login form).
But I don't know how the upcoming switch from FAS2 to noggin will
affect those things.

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

Schedule for Thursday's FPC Meeting (2021-03-04 17:00 UTC)

2021-03-03 Thread James Antill

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-03-04 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2021-03-04 09:00 PST  US/Pacific
2021-03-04 12:00 EST  --> US/Eastern <--
2021-03-04 17:00 GMT  Europe/London 
2021-03-04 17:00 UTC  UTC   
2021-03-04 18:00 CET  Europe/Berlin 
2021-03-04 18:00 CET  Europe/Paris  
2021-03-04 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-03-05 01:00 HKT  Asia/Hong_Kong
2021-03-05 01:00 +08  Asia/Singapore
2021-03-05 02:00 JST  Asia/Tokyo
2021-03-05 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

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

= Followup Actions =

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

#topic #1018
 * mhroncok
   will help design the brp script

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1018 Review exception request: Xorg utility deaggregation
.fpc 1018
https://pagure.io/packaging-committee/issue/1018

= Followup Pull Requests =

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

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

= Open Floor = 

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

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

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



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

[Bug 1934824] New: CVE-2020-28591 slic3r: Out-of-bounds read in AMFParserContext::endElement() [fedora-all]

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

Bug ID: 1934824
   Summary: CVE-2020-28591 slic3r: Out-of-bounds read in
AMFParserContext::endElement() [fedora-all]
   Product: Fedora
   Version: 33
Status: NEW
 Component: slic3r
  Keywords: Security, SecurityTracking
  Severity: low
  Priority: low
  Assignee: mhron...@redhat.com
  Reporter: psamp...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: mhron...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora




This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs

When submitting as an update, use the fedpkg template provided in the next
comment(s).  This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.

NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time.  If you need to fix the versions independent of each other,
you may clone this bug as appropriate.


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934823] New: CVE-2020-28591 slic3r: Out-of-bounds read in AMFParserContext::endElement()

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

Bug ID: 1934823
   Summary: CVE-2020-28591 slic3r: Out-of-bounds read in
AMFParserContext::endElement()
   Product: Security Response
  Hardware: All
OS: Linux
Status: NEW
 Component: vulnerability
  Keywords: Security
  Severity: low
  Priority: low
  Assignee: security-response-t...@redhat.com
  Reporter: psamp...@redhat.com
CC: mhron...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Other



An out-of-bounds read vulnerability exists in the AMF File
AMFParserContext::endElement() functionality of Slic3r libslic3r 1.3.0 and
Master Commit 92abbc42. A specially crafted AMF file can lead to information
disclosure. An attacker can provide a malicious file to trigger this
vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2020-1215


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934823] CVE-2020-28591 slic3r: Out-of-bounds read in AMFParserContext::endElement()

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



--- Comment #1 from Pedro Sampaio  ---
Created slic3r tracking bugs for this issue:

Affects: fedora-all [bug 1934824]


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934823] CVE-2020-28591 slic3r: Out-of-bounds read in AMFParserContext::endElement()

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

Pedro Sampaio  changed:

   What|Removed |Added

 Depends On||1934824





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1934824
[Bug 1934824] CVE-2020-28591 slic3r: Out-of-bounds read in
AMFParserContext::endElement() [fedora-all]
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934824] CVE-2020-28591 slic3r: Out-of-bounds read in AMFParserContext::endElement() [fedora-all]

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



--- Comment #1 from Pedro Sampaio  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# low, medium, high, urgent (required)
severity=low

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1934823,1934824

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934824] CVE-2020-28591 slic3r: Out-of-bounds read in AMFParserContext::endElement() [fedora-all]

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

Pedro Sampaio  changed:

   What|Removed |Added

 Blocks||1934823 (CVE-2020-28591)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1934823
[Bug 1934823] CVE-2020-28591 slic3r: Out-of-bounds read in
AMFParserContext::endElement()
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Update gating test is "failed" with no useful information

2021-03-03 Thread David Cantrell

On Tue, Mar 02, 2021 at 08:26:31AM -0800, Adam Williamson wrote:

On Tue, 2021-03-02 at 13:59 +, Richard W.M. Jones wrote:

Other tests are kind of random. I mean, what does this mean?

https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/12861/testReport/(root)/tests/

Stuff like:

1) File /usr/lib64/ocaml/cmdliner/cmdliner.a changed content on x86_64.

Amazing! The package was rebuilt, what did you expect?

The test description does explain this to some extent:
"Report changed files from the before build to the after build.
Certain file changes will raise additional warnings if the concern is
more critical than just reporting changes (e.g., a suspected security
impact)."
I suspect the types of files that changed here are flagged as being
"critical" on the basis that they are effectively ABI, so this is
telling you more or less the same thing as the abidiff failure: the
update changes the ABI. Note that many other files in the package will
have changed, but they're not *all* shown in the test results, just
these specific ones.

The question here is more "should ABI change-type issues be counted as
failures on Rawhide 'updates'?", I think.

No, it shouldn't count. What I did yesterday is add a 'rawhide'
profile to rpminspect-data-fedora:

https://github.com/rpminspect/rpminspect-data-fedora/blob/master/profiles/fedora/rawhide.yaml

This will be used by the rpminspect runner for all rawhide builds. It
just turns off a lot of inspections that are not useful for active and
ongoing development.

Some context: what rpminspect does is largely based on what the
internal rpmdiff tool did, unraveling that, and then building new
inspections in rpminspect. About half of the rpmdiff checks were tied
to stuff like this where the assumption is we are comparing builds in
a maintenance release of RHEL. That is, we don't want any unexpected
surprises in the packages. A file changing that we didn't want to
change should raise some sort of alarm. Those checks have been
implemented in rpminspect and broken out in to more logical sections,
but rpminspect also has the ability to turn off entire inspections you
don't want or need to run.

For information on what can go in the rpminspect configuration file,
see the generic template:

https://github.com/rpminspect/rpminspect/blob/master/data/generic.yaml

When rpminspect runs for Fedora builds it will first read in
/usr/share/rpminspect/fedora.yaml, then if a profile is specified it
reads that in and overlays that on the current configuration, and
lastly if you have a local 'rpminspect.yaml' file in your dist-git
branch then it reads that in last for any final overlays.

To see the default Fedora config file:

https://github.com/rpminspect/rpminspect-data-fedora/blob/master/fedora.yaml

I keep promising a man page for the rpminspect.yaml file and I promise
I will do it soon, I just haven't gotten around to it. The generic
template fills the need for config file docs for the moment.

Please let me know if you have any questions.

Thanks,

--
David Cantrell
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

Re: Bodhi client prompting for a password


On 03. 03. 21 21:08, Florian Weimer wrote:

I want to run this command:

   bodhi updates trigger-tests FEDORA-2021-279dee1742

But I'm prompted for a username and password.  I have a working Kerberos
setup for koji/fedpkg, so this is somewhat surprising.  Is this
expected?


Yes, that is how bodhi CLI client works.

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

[389-devel] please review: PR 4655 - UI - migrate modals to PF4

2021-03-03 Thread Mark Reynolds


https://github.com/389ds/389-ds-base/pull/4655

--

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora/f35 compile error

2021-03-03 Thread Carol Bouchard

In our code base (restraint), we patch and recompile the m4 code base.
https://github.com/tar-mirror/gnu-m4
In their code, they have the following which fails to compile when SIGSTKSZ
< 16384 is interpreted.
This is going to be a challenge to make work.

# define SIGSTKSZ 8192
#ifndef SIGSTKSZ
# define SIGSTKSZ 16384
#elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
/* libsigsegv 2.6 through 2.8 have a bug where some architectures use
   more than the Linux default of an 8k alternate stack when deciding
   if a fault was caused by stack overflow.  */
# undef SIGSTKSZ
# define SIGSTKSZ 16384
#endif

On Wed, Mar 3, 2021 at 3:05 PM Florian Weimer  wrote:

> * Carol Bouchard:
>
> > Thank you Daniel and Richard.  I'm going to have to study this some to
> > understand how this solves the compile issue cause the glibc code
> > isn't gone.  It's still there.
>
> SIGSTKSZ is no longer a (preprocessor) constant.  If you use it in place
> where a variable is expected, it works.  But you can't use it in
> preprocessor conditionals anymore.
>
> Thanks,
> Florian
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Bodhi client prompting for a password

2021-03-03 Thread Florian Weimer

I want to run this command:

  bodhi updates trigger-tests FEDORA-2021-279dee1742

But I'm prompted for a username and password.  I have a working Kerberos
setup for koji/fedpkg, so this is somewhat surprising.  Is this
expected?

I'm a bit hesitant to enter my Fedora Kerberos password in random
places.

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

Re: Fedora/f35 compile error

2021-03-03 Thread Florian Weimer

* Carol Bouchard:

> Thank you Daniel and Richard.  I'm going to have to study this some to
> understand how this solves the compile issue cause the glibc code
> isn't gone.  It's still there.

SIGSTKSZ is no longer a (preprocessor) constant.  If you use it in place
where a variable is expected, it works.  But you can't use it in
preprocessor conditionals anymore.

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

Re: Fedora/f35 compile error

2021-03-03 Thread Carol Bouchard

Thank you Daniel and Richard.  I'm going to have to study this some to
understand how this solves the compile issue cause the glibc code isn't
gone.  It's still there.

Carol

On Wed, Mar 3, 2021 at 11:31 AM Richard W.M. Jones 
wrote:

> On Wed, Mar 03, 2021 at 02:24:35PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
> > > I'm seeing the following compile error in my product which I'm not
> seeing
> > > with earlier versions of Fedora.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *make[4]: Entering directory
> > > '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
> > > gl_avltree_oset.o  CC   binary-io.o  CC   c-ctype.o  CC
> > > c-stack.oIn file included from /usr/include/signal.h:315,
> > >  from ./signal.h:52, from c-stack.c:49:c-stack.c:55:26:
> > > error: missing binary operator before token "("   55 | #elif
> > > HAVE_LIBSIGSEGV && SIGSTKSZ < 16384  |
> > >  ^~~~*
> > >
> > > In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide,
> I'm
> > > seeing
> > > the following in file /usr/include/bits/sigstksz.h.
> > >
> > >
> > > */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).
> */#
> > > undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
> > >
> > > This looks like an issue to be addressed in Fedora and not by applying
> a
> > > patch.  Please advise.
> >
> > The glibc change was intentionale and unavoidable per this previous
> > thread:
> >
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU
> >
> > So you'll need to patch the application so that it doesn't make an
> > assumption that SIGSTKSZ evaluates to a static constant.
>
> FWIW these were the two proposed fixes for this in OCaml (the second
> one was accepted).  Not too bad, you just have to be aware that the
> structure can no longer be statically allocated:
>
>
> https://pagure.io/fedora-ocaml/c/dfb5e954a04f59b0456cc4c0ddf3acaf22e0ff07?branch=fedora-35-4.12.0
>
> https://github.com/ocaml/ocaml/pull/10266/files
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934690] perl-URI-5.09 is available

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-f8d4087924 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-f8d4087924


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934690] perl-URI-5.09 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-URI-5.09-1.fc35




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934759] New: perl-JavaScript-Minifier-1.16 is available

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

Bug ID: 1934759
   Summary: perl-JavaScript-Minifier-1.16 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JavaScript-Minifier
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.16
Current version/release in rawhide: 1.15-1.fc34
URL: http://search.cpan.org/dist/JavaScript-Minifier/

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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-URI] PR #1: Tests

2021-03-03 Thread Jitka Plesnikova


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

Merged pull-request:

``
Tests
``

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

Re: Building custom kernels

2021-03-03 Thread stan via devel

Thanks for doing the work and posting the result / solution.

On Wed, 3 Mar 2021 19:19:14 +0100
Julian Sikorski  wrote:

> I did actually manage to get this working, big thanks go to
> chenxiaolong for their guide [1]. I did mix-and-match some of the
> info from Fedora docs [2][3], mainly regarding how to create a
> certificate. It basically goes like:
> 
> 1. Create certs with openssl
> 2. import them with certutil and pk12util as per [3]
> 3. add self to /etc/pesign/users
> 4. run sudo /usr/libexec/pesign/pesign-authorize
> 5. restart pesign service
> 6. unlock database (pesign-client -u)
> 7. add 
> config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/var/run/pesign',
>  
> '/var/run/pesign')) to mock site-defaults.cfg
> 8. work around bugs
> 9. run mock adding -D 'pe_signing_token NSS Certificate DB' -D 
> 'pe_signing_cert foo'
> 10. enroll the cert on the target machine
> 
> It is worth noting that for some reason the pe_signing_cert nickname
> was not the one I specified using certutil -n parameter, but an
> amalgamation of O and CN values from the certificate. Check with
> certutil -L to be sure. Moreover, while bug 1508094 mentioned by
> chenxiaolong is fixed, there are two more bugs which need to be
> worked around for all of this to work [4][5].
> Finally, the rationale: given that the Renoir APU s0ix patches have
> just missed 5.12 merge window from the looks of it, I will likely
> have to keep building my own kernels for a while. Getting the rpm
> signed automatically saves me a lot of time. Disabling secure boot
> causes windows to ask for drivelock recovery password so it is not an
> option
> 
> Best regards,
> Julian
> 
> [1]
> https://gist.github.com/chenxiaolong/520914b191f17194a0acdc0e03122e63
> [2]
> https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/
> [3]
> https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1880858 
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1934719
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Linux 34 Beta Go/No-Go meeting next week

2021-03-03 Thread Ben Cotton

Hi everyone,

It's that time already! The Fedora Linux 34 Beta Go/No-Go[1] meeting
is scheduled for Thursday 11 March at 1700 UTC in #fedora-meeting. At
this time, we will determine the status of the F34 Beta for the 16
March preferred target date. For more information about the Go/No-Go
meeting, see the wiki[2].

[1] https://apps.fedoraproject.org/calendar/meeting/9923/
[2] https://fedoraproject.org/wiki/Go_No_Go_Meeting

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

Fedora Linux 34 Beta Go/No-Go meeting next week

2021-03-03 Thread Ben Cotton

Hi everyone,

It's that time already! The Fedora Linux 34 Beta Go/No-Go[1] meeting
is scheduled for Thursday 11 March at 1700 UTC in #fedora-meeting. At
this time, we will determine the status of the F34 Beta for the 16
March preferred target date. For more information about the Go/No-Go
meeting, see the wiki[2].

[1] https://apps.fedoraproject.org/calendar/meeting/9923/
[2] https://fedoraproject.org/wiki/Go_No_Go_Meeting

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-URI] PR #1: Tests

2021-03-03 Thread Jitka Plesnikova


jplesnik opened a new pull-request against the project: `perl-URI` that you are 
following:
``
Tests
``

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

Re: Building custom kernels

2021-03-03 Thread Julian Sikorski

W dniu 03.03.2021 o 17:01, stan via devel pisze:

On Wed, 3 Mar 2021 14:27:16 +0100
Julian Sikorski wrote:

Am 03.03.21 um 14:00 schrieb Dominik 'Rathann' Mierzejewski:

There seems to be some documentation on the wiki:
https://fedoraproject.org/wiki/BuildingUpstreamKernel#Sign_the_kernel_for_Secure_Boot

Regards,
Dominik

This explains how to sign a kernel build locally with make, not how
to make mock & rpbmbuild use a self-signed certificate for the RPM
package.

I build a custom kernel tuned for my system from Fedora src.rpms
locally using rpmbuild (older technique without mock). I then install it
using dnf -C and sign it using a method similar to the above (pesign
instead of sbsign). What do you gain by having the rpms signed?
My thought is, if a person has the authority to run dnf to install
local packages on the system, secure boot is meaningless as protection.
Is it that you want the build process to sign the kernel in the rpm
package with your local keys so you don't have to go through the
process of signing the kernel after it is installed? If that is what
you want, and you get it working, would you post the technique here.

Hi,

I did actually manage to get this working, big thanks go to chenxiaolong
for their guide [1]. I did mix-and-match some of the info from Fedora
docs [2][3], mainly regarding how to create a certificate. It basically
goes like:

1. Create certs with openssl
2. import them with certutil and pk12util as per [3]
3. add self to /etc/pesign/users
4. run sudo /usr/libexec/pesign/pesign-authorize
5. restart pesign service
6. unlock database (pesign-client -u)
7. add
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/var/run/pesign',
'/var/run/pesign')) to mock site-defaults.cfg

8. work around bugs
9. run mock adding -D 'pe_signing_token NSS Certificate DB' -D
'pe_signing_cert foo'

10. enroll the cert on the target machine

It is worth noting that for some reason the pe_signing_cert nickname was
not the one I specified using certutil -n parameter, but an amalgamation
of O and CN values from the certificate. Check with certutil -L to be sure.
Moreover, while bug 1508094 mentioned by chenxiaolong is fixed, there
are two more bugs which need to be worked around for all of this to work
[4][5].
Finally, the rationale: given that the Renoir APU s0ix patches have just
missed 5.12 merge window from the looks of it, I will likely have to
keep building my own kernels for a while. Getting the rpm signed
automatically saves me a lot of time. Disabling secure boot causes
windows to ask for drivelock recovery password so it is not an option

Best regards,
Julian

[1] https://gist.github.com/chenxiaolong/520914b191f17194a0acdc0e03122e63
[2]
https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/
[3]
https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/

[4] https://bugzilla.redhat.com/show_bug.cgi?id=1880858
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1934719
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2021-03-03 Thread Tim Landscheidt

Kevin Fenzi  wrote:

> […]

> The purpose here is to make the Fedora project a more welcoming place to
> people who _do_ find those terms unwelcome. That doesn't mean everyone
> does. It means we want to be welcoming and not jerks.
 ^
> I'm personally happy to do things to make people more welcome.
> Even if they are small things and cause a small amount of work for us
> existing contributors.

> […]

"Disagreement is no excuse for poor behavior and poor man-
ners."

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

Re: ELN SIG First Meeting

2021-03-03 Thread Kevin Fenzi

On Tue, Mar 02, 2021 at 01:04:56AM +, Davide Cavalca via devel wrote:
> On Mon, 2021-03-01 at 12:47 -0800, Kevin Fenzi wrote:
> > I'm not sure exactly what you mean here... 
> > 
> > I think (please correct me if I'm wrong) you are wanting "all EPEL
> > packages" to also be built as part of ELN and shipped as some sort of
> > 'EPEL-ELN' ?
> 
> Yes, the idea I had in mind was that each package that currenty has an
> "epel8" branch would also get an "epeln" branch that would be built
> against ELN. Then when ELN branches into CentOS Stream, the epeln
> branches could be used as the starting point for the corresponding EPEL
> release.

So, the problem here is that it doesn't map to well to the rhel
timeframes. In Fedora, you just keep maintaining a package until you
need to retire/replace/rename it. In EPEL, there's 3 years between major
versions. A lot can happen in 3 years. For example, epel7 has Xfce 4.12
in it, epel8 has Xfce 4.14, Fedora has Xfce 4.16. In each of those, some
components changed. There's some 4.12 packages that were dropped
entirely by 4.14, sometimes there's new ones. I wouldn't want to
maintain 4.14 in epel9, I would want it to be the latest one. 

All that said, we could change this and just mass branch everything and
leave it to maintainers to clean up/dead.package/retire things they no
longer wish to maintain. That pushes more work on them tho (as well as
more releng work to mass branch, build everything, etc). 

kevin

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2021-03-03 Thread Kevin Fenzi

On Tue, Mar 02, 2021 at 11:36:45AM -0600, Renich Bon Ciric wrote:
> I haven't read the whole thread but I cannot believe everybody just
> went with it.
> 
> What is the practical purpose of changing master to main? I see no
> benefit whatsoever. We're only making this politicized.
> 
> I haven't checked the tickets but I'd bet my left arm on us not having
> a single ticket from an individual telling us they were discouraged to
> participate in any of our projects due to our use of "master" in git.
> This, for me, is beyond ridiculous but, even more incredible that
> nobody dared to lift their arm against it.
> 
> This isn't helping anyone. It's just succumbing to political pressure.
> And here I was thinking that people here wouldn't have it.
> 
> I, for one, totally disagree with this change. Especially for the
> reasons it's being done.

So, I think it's pretty moot at this point, since the change was already
discussed, approved and implemented and the chances of us reverting it
are very small. 

That said, I think you deserve at least a reply here. 

The purpose here is to make the Fedora project a more welcoming place to
people who _do_ find those terms unwelcome. That doesn't mean everyone
does. It means we want to be welcoming and not jerks. 

I'm personally happy to do things to make people more welcome. 
Even if they are small things and cause a small amount of work for us
existing contributors.

If you have a few minutes, take a look at:
https://www.youtube.com/watch?v=o0shU2g4IoI
(Rich Bowens talk at nest with fedora on this topic). 

kevin

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

Re: OCaml 4.12

2021-03-03 Thread Jerry James

On Wed, Mar 3, 2021 at 9:05 AM Jerry James  wrote:
> Oh no!  I thought I had tracked down all of the consumers of
> ocaml-ppx-tools-versioned.  So, no, ocaml-ppx-tools is not a straight
> replacement.  Users of ocaml-ppx-tools-versioned are supposed to
> migrate to ocaml-ppxlib.  I'll see what needs to be done to fix this.
> Sorry about that.

Haxe does not directly consume ocaml-ppx-tools-versioned.  It has
several transitive BuildRequires, formerly needed due to the
ocaml-sedlex dependency, which can now be omitted, namely:

BuildRequires:  ocaml-migrate-parsetree-devel
BuildRequires:  ocaml-ppx-derivers-devel
BuildRequires:  ocaml-ppx-tools-versioned-devel

Those should be removed.  However, after doing that I ran into an
incompatibility with the version of ocaml-extlib currently in Rawhide.
Andy seems to be aware of this:

https://github.com/HaxeFoundation/haxe/pull/10086

Once that is fixed, haxe should build in Rawhide again.  Also, Andy,
I'd like to point out that ocaml-luv is now available in Fedora, so it
should be possible to update to haxe 4.2.x.  Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

2021-03-03 Thread Hans de Goede

Hi,

On 3/2/21 5:20 PM, Pavel Březina wrote:
> On 3/2/21 4:25 PM, Ray Strode wrote:
>> Hi,
>>
>> Ahh, okay.
>>
>> On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede  wrote:
>>> sudo authselect select minimal
>>> sudo authselect apply-changes
>>>
>>> Which results in the following /etc/pam.d/fingerprint-auth file:
>>>
>>> [hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth
>>> # Generated by authselect on Tue Mar  2 15:24:53 2021
>>> # Do not modify this file manually.
> 
> minimal profile does not support fingerprint

So it seems there are 4 profiles:

[hans@x1 ~]$ authselect list
- minimalLocal users only for minimal installations
- nisEnable NIS for system authentication
- sssd   Enable SSSD for system authentication (also for local users 
only)
- winbindEnable winbind for system authentication

What I want is a profile which uses just the good old /etc files to
avoid the overhead of running a local daemon (sssd tends to show up as
one of the top 10 wakeup sources in powertop on an idle system) and I
also don't want a config which tries to go out on the network.

So minimal seems to meet my needs; and although I personally do not
have much of a need for fingerprint auth, I don't really see why we
could not do fingerprint auth with the minimal config. I'm pretty
sure I can manually create a pam-config where this works just fine.

I guess its in the name minimal, where as "local" might be (1) a better
name. Note I'm not suggesting to add another profile just for this
but it would be nice if fingerprint auth would at least be a
(default off) feature for the minimal config.

Shall I file a RFE issue for this at:
https://github.com/authselect/authselect/issues/

?

Regards,

Hans

1) Might have been a better name in retrospect, but meh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934690] perl-URI-5.09 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|caillon+fedoraproject@gmail |
   |.com, ka...@ucw.cz, |
   |p...@city-fan.org,  |
   |rhug...@redhat.com, |
   |rstr...@redhat.com, |
   |sandm...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934690] New: perl-URI-5.09 is available

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

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



Latest upstream release: 5.09
Current version/release in rawhide: 5.08-1.fc35
URL: http://search.cpan.org/dist/URI/

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


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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora/f35 compile error

2021-03-03 Thread Richard W.M. Jones

On Wed, Mar 03, 2021 at 02:24:35PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
> > I'm seeing the following compile error in my product which I'm not seeing
> > with earlier versions of Fedora.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > *make[4]: Entering directory
> > '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
> > gl_avltree_oset.o  CC   binary-io.o  CC   c-ctype.o  CC
> > c-stack.oIn file included from /usr/include/signal.h:315,
> >  from ./signal.h:52, from c-stack.c:49:c-stack.c:55:26:
> > error: missing binary operator before token "("   55 | #elif
> > HAVE_LIBSIGSEGV && SIGSTKSZ < 16384  |
> >  ^~~~*
> > 
> > In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
> > seeing
> > the following in file /usr/include/bits/sigstksz.h.
> > 
> > 
> > */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */#
> > undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
> > 
> > This looks like an issue to be addressed in Fedora and not by applying a
> > patch.  Please advise.
> 
> The glibc change was intentionale and unavoidable per this previous
> thread:
> 
>   
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU
> 
> So you'll need to patch the application so that it doesn't make an
> assumption that SIGSTKSZ evaluates to a static constant.

FWIW these were the two proposed fixes for this in OCaml (the second
one was accepted).  Not too bad, you just have to be aware that the
structure can no longer be statically allocated:

https://pagure.io/fedora-ocaml/c/dfb5e954a04f59b0456cc4c0ddf3acaf22e0ff07?branch=fedora-35-4.12.0

https://github.com/ocaml/ocaml/pull/10266/files

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: OCaml 4.12

2021-03-03 Thread Jerry James

On Tue, Mar 2, 2021 at 4:57 AM Richard W.M. Jones  wrote:
> haxe FTBFS because it depends on ocaml-ppx-tools-versioned-devel which
> was removed from Rawhide.  I'm not clear if ocaml-ppx-tools is a
> straight replacement, but I didn't attempt to fix this package, so
> please take a look.  Also ISTR there was an haxe update upstream.

Oh no!  I thought I had tracked down all of the consumers of
ocaml-ppx-tools-versioned.  So, no, ocaml-ppx-tools is not a straight
replacement.  Users of ocaml-ppx-tools-versioned are supposed to
migrate to ocaml-ppxlib.  I'll see what needs to be done to fix this.
Sorry about that.

> I also recall there was some discussion about whether we need
> OCaml 4.12 in Fedora 34.  I would prefer _not_ to do this, not only
> because it's another couple of days of work, but also because
> Fedora 34 is feeding into RHEL 9 and it would pull at least one more
> OCaml package in RHEL 9 which I'd like to avoid.  But if there was a
> real reason why we needed it in F34 then let me know.

I have no reason for needing 4.12 in Fedora 34.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Building custom kernels

2021-03-03 Thread stan via devel

On Wed, 3 Mar 2021 14:27:16 +0100
Julian Sikorski  wrote:

> Am 03.03.21 um 14:00 schrieb Dominik 'Rathann' Mierzejewski:
> > 
> > There seems to be some documentation on the wiki:
> > https://fedoraproject.org/wiki/BuildingUpstreamKernel#Sign_the_kernel_for_Secure_Boot
> > 
> > Regards,
> > Dominik
> >   
> This explains how to sign a kernel build locally with make, not how
> to make mock & rpbmbuild use a self-signed certificate for the RPM
> package.

I build a custom kernel tuned for my system from Fedora src.rpms
locally using rpmbuild (older technique without mock). I then install it
using  dnf -C  and sign it using a method similar to the above (pesign
instead of sbsign). What do you gain by having the rpms signed?
My thought is, if a person has the authority to run dnf to install
local packages on the system, secure boot is meaningless as protection.
Is it that you want the build process to sign the kernel in the rpm
package with your local keys so you don't have to go through the
process of signing the kernel after it is installed?  If that is what
you want, and you get it working, would you post the technique here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

2021-03-03 Thread Fabio Valentini

On Wed, Mar 3, 2021 at 9:20 AM Pierre-Yves Chibon  wrote:
>
> On Wed, Mar 03, 2021 at 01:07:44AM +0100, Miro Hrončok wrote:
> > On 02. 03. 21 22:05, Pierre-Yves Chibon wrote:
> > > The devil is in the details: pre-release, snapinfo, minorbump aren't 
> > > really
> > > covered by distance being just an integer bumped.
> >
> > I don't see this covered in the current method either. Or was it in the
> > meantime? Anyway:
>
> It is planned and part of the work to be done with this proposal:
> https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html#using-autorel

I'm not sure that this is a good idea. Why not just make the %autorel
macro return the "incrementing number" part of Release?
That would work for all the use cases we have in Fedora today, without
the need for implementing it internally in the %autorel macro.

> > - pre-release should go into version (~)
> > - snapinfo should go into version (~ or ^)
> >
> > The only real problem I see here is minorbump. We could have something like:
> > %{autorel -m}. That means, micobump since this was added here. But I guess
> > it is ugly.
> >
> > > I know we considered the "number of commits since the last version bump" 
> > > when we
> > > looked into this. I honestly do not remember precisely why we didn't go 
> > > with it.
> >
> > IIRC it was because you considered building several rebuilds with different
> > releases from the same commit a goal (while I'd rather require an empty
> > commit that explains the reason for the rebuild).
>
> Indeed, that approach would not allow rebuilding a commit without adding a new
> (potentially empty) commit.
> One of the idea being that not having to add commits would make it easier to 
> do
> auto-rebuild of dependency chains.

That sounds like an anti-feature to me. Having that information (even
if it's an empty commit with the "rebuilt for libfoo soname change")
is valuable IMO.
Also, where would the changelog entry for subsequent rebuilds for the
same commit come from?

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

Summary/Minutes from today's FESCo Meeting (2021-03-03)

2021-03-03 Thread Zbigniew Jędrzejewski-Szmek

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-03-03/fesco.2021-03-03-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-03-03/fesco.2021-03-03-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-03-03/fesco.2021-03-03-15.00.log.html

Meeting summary
---
* init process  (zbyszek, 15:00:16)

* #2584 Fedora 34 incomplete changes: 100% complete dealine  (zbyszek,
  15:03:04)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1906540
(bcotton, 15:04:10)

* #2579 F35 Change: Autoconf-2.71  (zbyszek, 15:06:04)
  * AGREED: APPROVED (+5, 0, 0)  (zbyszek, 15:11:47)
  * ACTION: zbyszek to ask for the details about who will update
packages to be added to the Change page  (zbyszek, 15:12:14)

* #2581 F35 Change: POWER 4KiB page size  (zbyszek, 15:12:22)
  * AGREED: REJECTED (0, 0, -5)  (zbyszek, 15:20:37)

* #2585 systemd-resolved: stub resolver is not following CNAME for
  resolution  (zbyszek, 15:20:41)
  * AGREED: Beta blocker is APPROVED (+6, 0, 0)  (zbyszek, 15:32:35)

* Next week's chair  (zbyszek, 15:32:39)
  * ACTION: zbyszek will chair next meeting  (zbyszek, 15:35:03)

* Open Floor  (zbyszek, 15:35:06)

Meeting ended at 15:46:01 UTC.




Action Items

* zbyszek to ask for the details about who will update packages to be
  added to the Change page
* zbyszek will chair next meeting
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1933868] perl-Date-Manip-6.85 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

[Bug 1933852] perl-Locale-Codes-3.67 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

Re: Draft of New Python Packaging Guidelines - 0.3

2021-03-03 Thread Petr Viktorin

Hello,
After (other parts of) $DAY_JOB delayed this for a while, a slightly 
updated draft is at https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg (and attached).

More importantly, here is the requested summary of changes from the old 
guidelines, roughly sorted by "importance": 
https://hackmd.io/LPfT6FKQSRyMcnqNU-zw2g (and attached).

There were two major objections to the earlier versions. The discussion 
died ou, so I'll repeat them. (Both of these should go in a change 
document rather than the guidelines).

- Why are the new macros better than the old ones?
They allow other build tools than just Setuptools, use upstream metadata 
for BuildRequires.
And they're being improved, with the vision that metadata should be 
taken from upstream rather than duplicated in the spec file. (If 
upstream is wrong, metadata should be patched just as you'd patch code.)

- Why do project names need to match PyPI?

This is because everywhere else (except in linux distros or tightly 
controlled corporate environments), a package name in a Python 
requirements list means a name on PyPI. Even at run time, when Python 
code checks if a package is installed, it assumes PyPI names.
Maintaining a separate namespace of project names, which could be mixed 
with the PyPI namespace, is *hard*. And building automation on top of 
such mixed namespaces is harder still.
Companies hit by the "dependency confusion" attack are to pin versions, 
use private proxies and/or block PyPI names.
There are ideas to add namespace support to PyPI, and Fedora should 
start using that when/if that happens. But until then, I really think 
the best we can do as Fedora packagers is in the draft:

If your package is not or cannot be published on PyPI, you can:
- Ask upstram to publish it
- If you wish: publish it to PyPI yourself and maintain it
- Ask Python SIG to block the name on PyPI for you
- Email PyPI admins to block the name for you, giving the project name and 
explaining the situation

Packages that aren't on PyPI are so rare, I'll be happy to handle the 
blocking myself (and pass the responsibility on within Red Hat 
python-maint when I retire from Fedora).

Also, no other ecosystem in Fedora does this. Python would be the first. 
If the other ecosystems also use a flat package namespace, and want to 
automate packaging, they'll probably run into the same problem.

Ultimately, syncing Fedora with the wider Python ecosystem is the main 
idea behind the draft. I'd be glad to hear how it can be done better, 
but to me, the new guidelines wouldn't make sense without this part.

On 4/30/20 3:41 PM, Petr Viktorin wrote:

Hello!
Below is a draft of new Packaging Guidelines! It's full of unfinished 
areas (marked with XXX), but it's ready for scrutiny.
A possibly updated version is on 
https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg?view

Generally, for rules marked **SHOULD** we know of cases where they 
should be broken; for things marked **MUST** we don't.

We have tried to only take the Good Existing Things™ (macros, practices) 
and revise the rest without thinking about the past much. Some used 
technology is unfortunately not compatible with current EPELs, but we 
have considered Fedora 31+. Using the current Python guidelines will 
still be an option for people who target EPEL 6/7/8.

The main controversial idea (of many) is synchronizing Fedora's names 
(a.k.a. `python3dist(...)`, a.k.a. `name` in `setup.py`) with the Python 
Package Index (PyPI, pypi.org), which has by now become the de-facto 
canonical namespace for freely redistributable Python packages.
We believe that this will help both Fedora and the greater Python 
ecosystem, but there will definitely be some growing pains.

Most of Fedora Python packages already are on PyPI, but more than 250 
are missing. There is software developed within Fedora (e.g. pagure, 
fedpkg, rust2rpm); projects that aren't primarily Python packages (e.g. 
perf, ceph, xen, setroubleshoot, iotop); and others.
A full list is attached. The names have been temporarily blocked on PyPI 
to keep trolls from taking them while this is discussed.
Over at the Python Discourse we are discussing how to properly handle 
these; once that discussion is settled they should be unblocked: 
https://discuss.python.org/t/pypi-as-a-project-repository-vs-name-registry-a-k-a-pypi-namesquatting-e-g-for-fedora-packages/4045 

Another general idea is that package metadata should be kept upstream; 
the spec file should duplicate as little of it as possible. Any 
adjustments should be done with upstreamable patches.

The draft lives on hackmd.io, which we found easy to collaborate with. 
If you have an account there, we can add you. If you'd like to 
collaborate some other way, let us know.

Petr and Miro

---

Current draft for inline comments:

 > [IMPORTANT]
 > This is a DRAFT; it is not in effect yet.

# Python Packaging Guidelines (draft)

 > [IMPORTANT]
 > This is a *beta* version of the Python

Fedora-IoT-34-20210303.0 compose check report

No missing expected images.

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

Old failures (same test failed in Fedora-IoT-34-20210227.0):

ID: 798176  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/798176
ID: 798185  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/798185
ID: 798192  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/798192

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

Old soft failures (same test soft failed in Fedora-IoT-34-20210227.0):

ID: 798168  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/798168
ID: 798169  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/798169
ID: 798170  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/798170
ID: 798184  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/798184

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

New passes (same test not passed in Fedora-IoT-34-20210227.0):

ID: 798189  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/798189
ID: 798198  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/798198
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1931967] perl-App-cpm-0.997003 is available

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

Bug 1932395 Summary: Review Request: perl-CPAN-02Packages-Search - Search Perl 
modules in 02packages.details.txt
https://bugzilla.redhat.com/show_bug.cgi?id=1932395

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1934532] EPEL8 Request: perl-Astro-FITS-CFITSIO

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

Orion Poplawski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|or...@nwra.com  |jakub.jedel...@gmail.com
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Orion Poplawski  ---
I've add you.  Thanks for the help!


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-34-20210303.n.0 compose check report

No missing expected images.

Failed openQA tests: 24/126 (aarch64), 17/187 (x86_64)

New failures (same test not failed in Fedora-34-20210302.n.1):

ID: 797974  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/797974
ID: 797981  Test: aarch64 Server-dvd-iso 
install_repository_nfs_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/797981
ID: 797989  Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/797989
ID: 797990  Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/797990
ID: 797991  Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/797991
ID: 798086  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/798086
ID: 798123  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/798123
ID: 798137  Test: aarch64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/798137
ID: 798139  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/798139

Old failures (same test failed in Fedora-34-20210302.n.1):

ID: 797891  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/797891
ID: 797892  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/797892
ID: 797895  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/797895
ID: 797898  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/797898
ID: 797899  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/797899
ID: 797903  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/797903
ID: 797904  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/797904
ID: 797914  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/797914
ID: 797923  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/797923
ID: 797927  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/797927
ID: 797932  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/797932
ID: 797942  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/797942
ID: 797943  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/797943
ID: 797983  Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/797983
ID: 798001  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/798001
ID: 798002  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/798002
ID: 798005  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/798005
ID: 798008  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/798008
ID: 798009  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/798009
ID: 798014  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/798014
ID: 798015  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/798015
ID: 798034  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/798034
ID: 798049  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/798049
ID: 798050  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/798050
ID: 798063  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/798063
ID: 798126  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/798126
ID: 798127  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/798127
ID: 798134  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/798134
ID: 798161  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/798161
ID: 798164  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL:

Re: Fedora/f35 compile error

2021-03-03 Thread Daniel P . Berrangé

On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
> I'm seeing the following compile error in my product which I'm not seeing
> with earlier versions of Fedora.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *make[4]: Entering directory
> '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
> gl_avltree_oset.o  CC   binary-io.o  CC   c-ctype.o  CC
> c-stack.oIn file included from /usr/include/signal.h:315,
>  from ./signal.h:52, from c-stack.c:49:c-stack.c:55:26:
> error: missing binary operator before token "("   55 | #elif
> HAVE_LIBSIGSEGV && SIGSTKSZ < 16384  |
>  ^~~~*
> 
> In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
> seeing
> the following in file /usr/include/bits/sigstksz.h.
> 
> 
> */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */#
> undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
> 
> This looks like an issue to be addressed in Fedora and not by applying a
> patch.  Please advise.

The glibc change was intentionale and unavoidable per this previous
thread:

  
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU

So you'll need to patch the application so that it doesn't make an
assumption that SIGSTKSZ evaluates to a static constant.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora/f35 compile error

2021-03-03 Thread Carol Bouchard

I'm seeing the following compile error in my product which I'm not seeing
with earlier versions of Fedora.











*make[4]: Entering directory
'/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
gl_avltree_oset.o  CC   binary-io.o  CC   c-ctype.o  CC
c-stack.oIn file included from /usr/include/signal.h:315,
 from ./signal.h:52, from c-stack.c:49:c-stack.c:55:26:
error: missing binary operator before token "("   55 | #elif
HAVE_LIBSIGSEGV && SIGSTKSZ < 16384  |
 ^~~~*

In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
seeing
the following in file /usr/include/bits/sigstksz.h.


*/* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */#
undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*

This looks like an issue to be addressed in Fedora and not by applying a
patch.  Please advise.

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

Re: Fedora Account System and Bugzilla Mismatch email

2021-03-03 Thread Pierre-Yves Chibon

On Wed, Mar 03, 2021 at 11:27:44AM -, Lukas Zapletal wrote:
> Hey,
> 
> I got an email asking me to change my fedora email to match my BZ account. 
> Problem is, in BZ I have to use my redhat account which allows me to be 
> granted special permissions for RH-related bugs. Fedora wants to do this for 
> the same reason, however I'd like to separate my upstream contribution and 
> all accounts from my work account, therefore I'd like to continue using my 
> private email.
> 
> Is this something that can be solved? Like by adding a special field which is 
> used to link BZ so users can set these individually?

There is an override file at:
https://pagure.io/fedora-infra/ansible/raw/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml
that can be used to, well override email in FAS with email in bugzilla.

Feel free to open a pull-request to edit that file and add yourself :)


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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

Miro Hrončok wrote:
> 1) Why 269 and not 2.69?

I guess that this is a historical thing: past autoconf compatibility 
packages always had names such as autoconf213. Back then, dots in package 
names were considered unusual or harmful, standard practice was to omit 
them. The rule that the dot should be included was added relatively recently 
(but already a couple years ago by now) to the packaging guidelines.

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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

Miro Hrončok wrote:
> 2) Is the parallel installability worth the trouble of different names?

IMHO, yes. Some projects require developers to run autoconf to pregenerate 
the scripts, so they will need to be able to work with more than one 
version.

Past autoconf compatibility packages in Fedora have always worked like this, 
with suffixed names.

What we could do is adding an additional autoconf2.69-unversioned-commands 
subpackage with unversioned symlinks, Requires: autoconf2.69, and Conflicts: 
autoconf. That would bring us the best of both worlds: parallel 
installability for end users, and an easy porting procedure 
(s/^\(BuildRequires:[ \t]*\)autoconf/\1autoconf2.69-unversioned-commands/g 
*.spec) to get a package to build in Mock/Koji.

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

Re: Building custom kernels

2021-03-03 Thread Julian Sikorski


Am 03.03.21 um 14:00 schrieb Dominik 'Rathann' Mierzejewski:

On Wednesday, 03 March 2021 at 13:53, Julian Sikorski wrote:
[...]

Now that the kernels have built successfully I have another question: is
there an easy way of signing them so that secureboot can stay enabled? I
have generated a key/certificate pair as described in the docs [1] but I was
not able to figure out how to feed these to rpmbuild/mock. The kernel spec
uses two .cer files instead of .priv/.der pair, and the docs [2] are out of
date as %{pe_signing_cert} are nowhere to be found in the spec.


There seems to be some documentation on the wiki:
https://fedoraproject.org/wiki/BuildingUpstreamKernel#Sign_the_kernel_for_Secure_Boot

Regards,
Dominik

This explains how to sign a kernel build locally with make, not how to 
make mock & rpbmbuild use a self-signed certificate for the RPM package.


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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

On Wed, Mar 3, 2021 at 1:51 PM Miro Hrončok  wrote:

> On 03. 03. 21 13:47, Ondrej Dubaj wrote:
> >
> >
> > On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok  > > wrote:
> >
> > On 03. 03. 21 12:49, Ondrej Dubaj wrote:
> >  > Compat package prepared.
> >  >
> >  > Package autoconf269-2.69-1 provides:
> >  >
> >  > /usr/bin/autoconf269
> >  > /usr/bin/autoheader269
> >  > /usr/bin/autom4te269
> >  > /usr/bin/autoreconf269
> >  > /usr/bin/autoscan269
> >  > /usr/bin/autoupdate269
> >  > /usr/bin/ifnames269
> >  > ...
> >  >
> >  > Parallel installation successful.
> >  >
> >  > Any suggestions/concerns are welcome.
> >
> > My concerns are:
> >
> > 1) Why 269 and not 2.69?
> >
> > Just a naming convention, if needed can be easily changed
>
> There is no need to complicate stuff by removing the dot. The naming
> convention
> for compat packages is to include the version:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


Ok, will change immediately.

>
>
> > 2) Is the parallel installability worth the trouble of different
> names?
> >
> > It is up to us to discuss this.
>
> How are most of the packages in Fedora using? Is it spelling out
> "autoconf" in
> the spec file, or trough some configure scripts? If it is the second, I
> worry
> that a command will mean patching (or sedding) would be required.
>

Both, actually.

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

Fedora 34 compose report: 20210303.n.0 changes

2021-03-03 Thread Fedora Rawhide Report

OLD: Fedora-34-20210302.n.1
NEW: Fedora-34-20210303.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Merging mingw specs into native spec

2021-03-03 Thread Richard W.M. Jones

On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote:
> V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a):
> > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > > +%if %{_with_mingw}
> > > +
> > > +%package -n mingw32-libvirt-glib
> > > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > > +BuildArch: noarch
> > > +Requires: pkgconfig
> > > +
> 
> Why are the packages noarch if they contain a machine code?

Dan already noted that you can run the cross-compiler on any
architecture.

However it is a good question about why the final packages are
"noarch".  Windows these days only exists on i686, x86-64 and aarch64.
I don't know what mingw-w64's support for aarch64 is like, but we only
bother building i686 ("mingw32-*") and x86-64 ("mingw64-*") packages.

Normally the end result is intended to be run on Windows, so it's
"noarch" as far as Fedora is concerned.  The normal deployment method
is to use NSIS to generate an installer (from files in the RPMs you've
installed locally) which is copied over to Windows.  You can do this
on any arch.  But you can also run the code under Wine on an x86-64
host.  Probably on i686 host but I doubt anyone has done that in a
long while.  Wine doesn't work on non-x86 arches.

I don't think that Koji / RPM is really designed to cope with all this
subtlety though.  And implementing it just for mingw is way too much work.

> Fullarch Linux packages are built on various architectures. Is MinGW
> toolchain available on all of them? E.g if my Linux package builds
> on s390x, is there a crosscompiler available and is thus possible to
> build Windows binaries there? What about runnning tests in %check
> phase?

Yes, any build arch can be used.  We don't usually run tests in %check
because running Wine under Koji is a pain.  It requires a specifically
configured $HOME, and X server (even for console programs).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Building custom kernels

2021-03-03 Thread Dominik 'Rathann' Mierzejewski

On Wednesday, 03 March 2021 at 13:53, Julian Sikorski wrote:
[...]
> Now that the kernels have built successfully I have another question: is
> there an easy way of signing them so that secureboot can stay enabled? I
> have generated a key/certificate pair as described in the docs [1] but I was
> not able to figure out how to feed these to rpmbuild/mock. The kernel spec
> uses two .cer files instead of .priv/.der pair, and the docs [2] are out of
> date as %{pe_signing_cert} are nowhere to be found in the spec.

There seems to be some documentation on the wiki:
https://fedoraproject.org/wiki/BuildingUpstreamKernel#Sign_the_kernel_for_Secure_Boot

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

Re: Building custom kernels

2021-03-03 Thread Julian Sikorski

Am 02.03.21 um 18:24 schrieb Julian Sikorski:

W dniu 02.03.2021 o 18:10, Julian Sikorski pisze:

W dniu 02.03.2021 o 13:42, Justin Forbes pisze:
On Tue, Mar 2, 2021 at 3:32 AM Julian Sikorski
wrote:

Am 01.03.21 um 17:37 schrieb Brandon Nielsen:

On 2/28/21 12:00 PM, Julian Sikorski wrote:

W dniu 27.02.2021 o 20:59, Julian Sikorski pisze:

Hi,

I am trying to test some Renoir s2idle patches [1]. It appears that
Fedora kernel source is now maintained on gitlab as kernel-ark [2].
What I tried is adding the patches to the fedora-5.11 branch and
running make dist-srpm, but it failed due to config mismatch on
CONFIG_INIT_STACK_NONE:

Processing
/home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config

... Error: Mismatches found in configuration files
Found CONFIG_INIT_STACK_NONE=y after generation, had
CONFIG_INIT_STACK_NONE=is not set in Source tree
make[1]: *** [Makefile:145: dist-configs-check] Błąd 1

Is this expected? Is there a better way of testing patches on Fedora
kernels? Thanks for the help in advance.

Best regards,
Julian

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230
[2] https://gitlab.com/cki-project/kernel-ark

Hi,

the same keeps happening if I try to merge os-build into agdf5
tree or

even if I try to make srpm in the ark-latest branch. Is this normal?

Best regards,
Julian

I found the same last week and the documentation[0] feels really
unloved.

I eventually resorted to rebuilding from the SRPM and apply patches
there.

[0] -
https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/

___

Hi,

there is more documentation available [1], but unfortunately one gets
the error I mentioned above when trying to follow it.

Aha, I seem to have forgotten where this came from. You are actually
missing a buildreq for the kernel. I believe that 'dnf install
gcc-plugin-devel' will fix your issue with the config mismatch. Also,
if you are working with the fedora-5.11 branch, I have included a
script in redhat/fedora-dist-git-test.sh which will generate a test
version of a dist-git update. While that may not be your goal, it
would be worth looking at the command line there for generating a
proper srpm.

Thanks,
Justin

Thanks, 5.11 branch with s0ix patches on top went further now:

Processing
/home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-i686-fedora.config
... Found unset config items, please set them to an appropriate value

CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=n

os-build no longer cleanly merges with agd5f s0ix branch so fixing the
above is likely the easiest option to get going.

Best regards,
Julian

I fixed it with attached patch, I can generate a SRPM now. Thanks again!

Best regards,
Julian

Now that the kernels have built successfully I have another question: is
there an easy way of signing them so that secureboot can stay enabled? I
have generated a key/certificate pair as described in the docs [1] but I
was not able to figure out how to feed these to rpmbuild/mock. The
kernel spec uses two .cer files instead of .priv/.der pair, and the docs
[2] are out of date as %{pe_signing_cert} are nowhere to be found in the
spec.

[1]
https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/
[2]
https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/

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

[Bug 1934532] New: EPEL8 Request: perl-Astro-FITS-CFITSIO

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

Bug ID: 1934532
   Summary: EPEL8 Request: perl-Astro-FITS-CFITSIO
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Astro-FITS-CFITSIO
  Assignee: or...@nwra.com
  Reporter: jakub.jedel...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: or...@nwra.com, perl-devel@lists.fedoraproject.org,
scitech-b...@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hello, I would appreciate if you could build perl-Astro-FITS-CFITSIO for EPEL8.
Feel free to add me (kubo) as co-maintainer. Thanks.


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)


On 03. 03. 21 13:47, Ondrej Dubaj wrote:



On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok > wrote:


On 03. 03. 21 12:49, Ondrej Dubaj wrote:
 > Compat package prepared.
 >
 > Package autoconf269-2.69-1 provides:
 >
 > /usr/bin/autoconf269
 > /usr/bin/autoheader269
 > /usr/bin/autom4te269
 > /usr/bin/autoreconf269
 > /usr/bin/autoscan269
 > /usr/bin/autoupdate269
 > /usr/bin/ifnames269
 > ...
 >
 > Parallel installation successful.
 >
 > Any suggestions/concerns are welcome.

My concerns are:

1) Why 269 and not 2.69?

Just a naming convention, if needed can be easily changed


There is no need to complicate stuff by removing the dot. The naming convention 
for compat packages is to include the version:


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


2) Is the parallel installability worth the trouble of different names?

It is up to us to discuss this.


How are most of the packages in Fedora using? Is it spelling out "autoconf" in 
the spec file, or trough some configure scripts? If it is the second, I worry 
that a command will mean patching (or sedding) would be required.


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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok  wrote:

> On 03. 03. 21 12:49, Ondrej Dubaj wrote:
> > Compat package prepared.
> >
> > Package autoconf269-2.69-1 provides:
> >
> > /usr/bin/autoconf269
> > /usr/bin/autoheader269
> > /usr/bin/autom4te269
> > /usr/bin/autoreconf269
> > /usr/bin/autoscan269
> > /usr/bin/autoupdate269
> > /usr/bin/ifnames269
> > ...
> >
> > Parallel installation successful.
> >
> > Any suggestions/concerns are welcome.
>
> My concerns are:
>
> 1) Why 269 and not 2.69?
>
Just a naming convention, if needed can be easily changed

2) Is the parallel installability worth the trouble of different names?
>
It is up to us to discuss 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: srpm rebuilding on RISC-V fedora image

2021-03-03 Thread Peter Robinson

On Wed, Mar 3, 2021 at 12:30 PM Richard W.M. Jones  wrote:
>
> On Wed, Mar 03, 2021 at 05:45:35PM +0530, Billa Surendra wrote:
> > Dear Richard,
>
> Please send messages to the Fedora devel list so there is
> a public record and so others can help.
>
> > I am trying to initialize the mock chroot before performing the first 
> > rebuild
> > SRPM on RISC-V fedora image.
> >
> > In order to initialize the chroot for fedora-33-riscv64 I have started 
> > running
> > the below command:
> >
> > $ mock -r fedora-33-riscv64.cfg --init
> >
> > But initialization did not proceed further. I am getting following error.
> >
> > Error:
> >
> > [root@fedora-riscv mock]# mock -r fedora-33-riscv64.cfg --init
> > INFO: mock.py version 2.8 starting (python version = 3.9.1, NVR =
> > mock-2.8-1.fc33)...
> > Start(bootstrap): init plugins
> > INFO: selinux disabled
> > Finish(bootstrap): init plugins
> > Start: init plugins
> > INFO: selinux disabled
> > Finish: init plugins
> > INFO: Signal handler active
> > Start: run
> > Start: clean chroot
> > Finish: clean chroot
> > Start(bootstrap): chroot init
> > INFO: calling preinit hooks
> > INFO: enabled root cache
> > INFO: enabled package manager cache
> > Start(bootstrap): cleaning package manager metadata
> > Finish(bootstrap): cleaning package manager metadata
> > INFO: enabled HW Info plugin
> > Mock Version: 2.8
> > INFO: Mock Version: 2.8
> > Start(bootstrap): dnf install
> > No matches found for the following disable plugin patterns: local, spacewalk
> > fedora   14 kB/s |  71 kB 00:04
> > Errors during downloading metadata for repository 'fedora':
> >   - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=
> > fedora-33=riscv64 (IP: 13.212.21.54)
> > Error: Failed to download metadata for repo 'fedora': Cannot prepare 
> > internal
> > mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?
> > repo=fedora-33=riscv64 (IP: 13.212.21.54)
> > ERROR: Command failed:
> >  # /usr/bin/dnf --installroot 
> > /var/lib/mock/fedora-33-riscv64-bootstrap/root/
> > --releasever 33 --setopt=deltarpm=False --allowerasing --disableplugin=local
> > --disableplugin=spacewalk install dnf dnf-plugins-core
> > No matches found for the following disable plugin patterns: local, spacewalk
> > fedora   14 kB/s |  71 kB 00:04
> > Errors during downloading metadata for repository 'fedora':
> >   - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=
> > fedora-33=riscv64 (IP: 13.212.21.54)
>
> This URL is wrong.  You're going to need to work out how to point to
> the Fedora/RISC-V Koji instance (http://fedora.riscv.rocks/koji/).  I
> don't know exactly how to do that but I'm sure someone on the Fedora
> development list can help.

Is that just the direct koji made repos? I suspect what we actually
need to do is like what we used to do on the secondary arches which
was a Minimal "Everything" compose, AKA just enough compose, to
generate the Everything repos and then sync that somewhere that is not
on the koji instance for a "Emerging Architecture" so it can then be
fronted by MirrorManager which would correctly point the URL above to
the right location.

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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)


On 03. 03. 21 12:49, Ondrej Dubaj wrote:

Compat package prepared.

Package autoconf269-2.69-1 provides:

/usr/bin/autoconf269
/usr/bin/autoheader269
/usr/bin/autom4te269
/usr/bin/autoreconf269
/usr/bin/autoscan269
/usr/bin/autoupdate269
/usr/bin/ifnames269
...

Parallel installation successful.

Any suggestions/concerns are welcome.


My concerns are:

1) Why 269 and not 2.69?
2) Is the parallel installability worth the trouble of different names?

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

Re: Orphaned Telegram packages

2021-03-03 Thread Vitaly Zaitsev via devel


On 03.03.2021 12:57, Kevin Kofler via devel wrote:

Indeed, next time please orphan packages instead of retiring them outright.
They will be automatically retired if nobody adopts them.


Got it. Thanks for the info.

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

Re: srpm rebuilding on RISC-V fedora image

2021-03-03 Thread Richard W.M. Jones

On Wed, Mar 03, 2021 at 05:45:35PM +0530, Billa Surendra wrote:
> Dear Richard,

Please send messages to the Fedora devel list so there is
a public record and so others can help.

> I am trying to initialize the mock chroot before performing the first rebuild
> SRPM on RISC-V fedora image.
> 
> In order to initialize the chroot for fedora-33-riscv64 I have started running
> the below command:
> 
> $ mock -r fedora-33-riscv64.cfg --init
> 
> But initialization did not proceed further. I am getting following error.
> 
> Error: 
> 
> [root@fedora-riscv mock]# mock -r fedora-33-riscv64.cfg --init
> INFO: mock.py version 2.8 starting (python version = 3.9.1, NVR =
> mock-2.8-1.fc33)...
> Start(bootstrap): init plugins
> INFO: selinux disabled
> Finish(bootstrap): init plugins
> Start: init plugins
> INFO: selinux disabled
> Finish: init plugins
> INFO: Signal handler active
> Start: run
> Start: clean chroot
> Finish: clean chroot
> Start(bootstrap): chroot init
> INFO: calling preinit hooks
> INFO: enabled root cache
> INFO: enabled package manager cache
> Start(bootstrap): cleaning package manager metadata
> Finish(bootstrap): cleaning package manager metadata
> INFO: enabled HW Info plugin
> Mock Version: 2.8
> INFO: Mock Version: 2.8
> Start(bootstrap): dnf install
> No matches found for the following disable plugin patterns: local, spacewalk
> fedora                                           14 kB/s |  71 kB     00:04   
>  
> Errors during downloading metadata for repository 'fedora':
>   - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=
> fedora-33=riscv64 (IP: 13.212.21.54)
> Error: Failed to download metadata for repo 'fedora': Cannot prepare internal
> mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?
> repo=fedora-33=riscv64 (IP: 13.212.21.54)
> ERROR: Command failed:
>  # /usr/bin/dnf --installroot /var/lib/mock/fedora-33-riscv64-bootstrap/root/
> --releasever 33 --setopt=deltarpm=False --allowerasing --disableplugin=local
> --disableplugin=spacewalk install dnf dnf-plugins-core
> No matches found for the following disable plugin patterns: local, spacewalk
> fedora                                           14 kB/s |  71 kB     00:04   
>  
> Errors during downloading metadata for repository 'fedora':
>   - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=
> fedora-33=riscv64 (IP: 13.212.21.54)

This URL is wrong.  You're going to need to work out how to point to
the Fedora/RISC-V Koji instance (http://fedora.riscv.rocks/koji/).  I
don't know exactly how to do that but I'm sure someone on the Fedora
development list can help.

Rich.

> Error: Failed to download metadata for repo 'fedora': Cannot prepare internal
> mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?
> repo=fedora-33=riscv64 (IP: 13.212.21.54)
> 
> 
> Here I am planning to rebuild gcc SRPM on a mock by utilizing 
> fedora-33-riscv64
> arch on RISC-V fedora image. Can you please suggest what I have to do now.
> 
> Thanks
> 
> Billa
> 
> 
> 
> On Wed, Feb 24, 2021 at 4:03 PM Richard W.M. Jones  wrote:
> 
> On Wed, Feb 24, 2021 at 02:50:02PM +0530, Billa Surendra wrote:
> > Dear David and Richard,
> >
> > As you suggested, I have downloaded the latest RISC-V fedora image from
> this
> > link  state=closed=flat=
> > createAppliance=-id> and booted by using QEMU emulator. 
> >
> > Now started rebuilding gcc srpm  taken from this  dl.amnesia.boum.org/
> > fedora/releases/33/Everything/source/tree/Packages/g/>  on booted
> fedora. 
> >
> > Here I have changed the gcc.spec file for not supporting compressed
> > instructions. again re created  srpm.
> >
> > Actually here QEMU takes a lot of time (2-3 days) for rebuilding, even 
> it
> hangs
> > some time in fairly fast x86 hardware (25 GB RAM and 8 cores).
> 
> It takes 3 days to rebuild GCC even on SiFive Unleashed.  You just
> have to be patient and don't make a mistake.
> 
> > Is there any way to increase the number of cores from 8 to 24 in QEMU 
> -smp 8 
> > option ?.  or I have to use a sifive board for that.
> 
> Last time I looked into this, 8 was an architectural limit on the
> number of cores.  I don't know if more are supported now - try it and
> see.  I doubt it will give you very much more performance for building
> GCC even if it works.
> 
> Rich.
> 
> 
> > If you feel a sifive board is best for rebuilding fedora 
> packages(without
> > compressed support), which one I have to use ?.
> >
> > Please help out regarding the above problem.
> >
> > Thanks in advance
> >
> > Billa
> >   
> >
> >  
> >
> >
> 
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/
> ~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
>

Re: OCaml 4.12

Richard W.M. Jones wrote:
> I also recall there was some discussion about whether we need
> OCaml 4.12 in Fedora 34.  I would prefer _not_ to do this, not only
> because it's another couple of days of work, but also because
> Fedora 34 is feeding into RHEL 9 and it would pull at least one more
> OCaml package in RHEL 9 which I'd like to avoid.  But if there was a
> real reason why we needed it in F34 then let me know.

A RHEL release should really not be the deciding factor on whether something 
is accepted into a Fedora release or not.

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

Re: Orphaned Telegram packages

Dan Čermák wrote:
> The package is now retired, was that intentional? Note that this makes
> adopting it much more of a hassle.

Indeed, next time please orphan packages instead of retiring them outright. 
They will be automatically retired if nobody adopts them.

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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

Compat package prepared.

Package autoconf269-2.69-1 provides:

/usr/bin/autoconf269
/usr/bin/autoheader269
/usr/bin/autom4te269
/usr/bin/autoreconf269
/usr/bin/autoscan269
/usr/bin/autoupdate269
/usr/bin/ifnames269
/usr/share/autoconf269
/usr/share/autoconf269/Autom4te
/usr/share/autoconf269/Autom4te/C4che.pm
/usr/share/autoconf269/Autom4te/ChannelDefs.pm
/usr/share/autoconf269/Autom4te/Channels.pm
/usr/share/autoconf269/Autom4te/Configure_ac.pm
/usr/share/autoconf269/Autom4te/FileUtils.pm
/usr/share/autoconf269/Autom4te/General.pm
/usr/share/autoconf269/Autom4te/Getopt.pm
/usr/share/autoconf269/Autom4te/Request.pm
/usr/share/autoconf269/Autom4te/XFile.pm
/usr/share/autoconf269/INSTALL
/usr/share/autoconf269/autoconf
/usr/share/autoconf269/autoconf/autoconf.m4
/usr/share/autoconf269/autoconf/autoconf.m4f
/usr/share/autoconf269/autoconf/autoheader.m4
/usr/share/autoconf269/autoconf/autoscan.m4
/usr/share/autoconf269/autoconf/autotest.m4
/usr/share/autoconf269/autoconf/autoupdate.m4
/usr/share/autoconf269/autoconf/c.m4
/usr/share/autoconf269/autoconf/erlang.m4
/usr/share/autoconf269/autoconf/fortran.m4
/usr/share/autoconf269/autoconf/functions.m4
/usr/share/autoconf269/autoconf/general.m4
/usr/share/autoconf269/autoconf/go.m4
/usr/share/autoconf269/autoconf/headers.m4
/usr/share/autoconf269/autoconf/lang.m4
/usr/share/autoconf269/autoconf/libs.m4
/usr/share/autoconf269/autoconf/oldnames.m4
/usr/share/autoconf269/autoconf/programs.m4
/usr/share/autoconf269/autoconf/specific.m4
/usr/share/autoconf269/autoconf/status.m4
/usr/share/autoconf269/autoconf/types.m4
/usr/share/autoconf269/autom4te.cfg
/usr/share/autoconf269/autoscan
/usr/share/autoconf269/autoscan/autoscan.list
/usr/share/autoconf269/autotest
/usr/share/autoconf269/autotest/autotest.m4
/usr/share/autoconf269/autotest/autotest.m4f
/usr/share/autoconf269/autotest/general.m4
/usr/share/autoconf269/autotest/specific.m4
/usr/share/autoconf269/m4sugar
/usr/share/autoconf269/m4sugar/foreach.m4
/usr/share/autoconf269/m4sugar/m4sh.m4
/usr/share/autoconf269/m4sugar/m4sh.m4f
/usr/share/autoconf269/m4sugar/m4sugar.m4
/usr/share/autoconf269/m4sugar/m4sugar.m4f
/usr/share/autoconf269/m4sugar/version.m4
/usr/share/config.site
/usr/share/doc/autoconf269
/usr/share/doc/autoconf269/AUTHORS
/usr/share/doc/autoconf269/ChangeLog
/usr/share/doc/autoconf269/NEWS
/usr/share/doc/autoconf269/README
/usr/share/doc/autoconf269/THANKS
/usr/share/doc/autoconf269/TODO
/usr/share/emacs/site-lisp/autoconf269
/usr/share/emacs/site-lisp/autoconf269/autoconf-mode.el
/usr/share/emacs/site-lisp/autoconf269/autoconf-mode.elc
/usr/share/emacs/site-lisp/autoconf269/autotest-mode.el
/usr/share/emacs/site-lisp/autoconf269/autotest-mode.elc
/usr/share/emacs/site-lisp/site-start.d
/usr/share/emacs/site-lisp/site-start.d/autoconf-init.el
/usr/share/info/autoconf269.info.gz
/usr/share/licenses/autoconf269
/usr/share/licenses/autoconf269/COPYING
/usr/share/licenses/autoconf269/COPYING.EXCEPTION
/usr/share/licenses/autoconf269/COPYINGv3
/usr/share/man/man1/autoconf269.1.gz
/usr/share/man/man1/autoheader269.1.gz
/usr/share/man/man1/autom4te269.1.gz
/usr/share/man/man1/autoreconf269.1.gz
/usr/share/man/man1/autoscan269.1.gz
/usr/share/man/man1/autoupdate269.1.gz
/usr/share/man/man1/config.guess269.1.gz
/usr/share/man/man1/config.sub269.1.gz
/usr/share/man/man1/ifnames269.1.gz

Package autoconf-2.71-1 provides:

/usr/bin/autoconf
/usr/bin/autoheader
/usr/bin/autom4te
/usr/bin/autoreconf
/usr/bin/autoscan
/usr/bin/autoupdate
/usr/bin/ifnames
/usr/share/autoconf
/usr/share/autoconf/Autom4te
/usr/share/autoconf/Autom4te/C4che.pm
/usr/share/autoconf/Autom4te/ChannelDefs.pm
/usr/share/autoconf/Autom4te/Channels.pm
/usr/share/autoconf/Autom4te/Config.pm
/usr/share/autoconf/Autom4te/Configure_ac.pm
/usr/share/autoconf/Autom4te/FileUtils.pm
/usr/share/autoconf/Autom4te/General.pm
/usr/share/autoconf/Autom4te/Getopt.pm
/usr/share/autoconf/Autom4te/Request.pm
/usr/share/autoconf/Autom4te/XFile.pm
/usr/share/autoconf/INSTALL
/usr/share/autoconf/autoconf
/usr/share/autoconf/autoconf/autoconf.m4
/usr/share/autoconf/autoconf/autoconf.m4f
/usr/share/autoconf/autoconf/autoheader.m4
/usr/share/autoconf/autoconf/autoscan.m4
/usr/share/autoconf/autoconf/autotest.m4
/usr/share/autoconf/autoconf/autoupdate.m4
/usr/share/autoconf/autoconf/c.m4
/usr/share/autoconf/autoconf/erlang.m4
/usr/share/autoconf/autoconf/fortran.m4
/usr/share/autoconf/autoconf/functions.m4
/usr/share/autoconf/autoconf/general.m4
/usr/share/autoconf/autoconf/go.m4
/usr/share/autoconf/autoconf/headers.m4
/usr/share/autoconf/autoconf/lang.m4
/usr/share/autoconf/autoconf/libs.m4
/usr/share/autoconf/autoconf/oldnames.m4
/usr/share/autoconf/autoconf/programs.m4
/usr/share/autoconf/autoconf/specific.m4
/usr/share/autoconf/autoconf/status.m4
/usr/share/autoconf/autoconf/trailer.m4
/usr/share/autoconf/autoconf/types.m4
/usr/share/autoconf/autom4te.cfg
/usr/share/autoconf/autoscan
/usr/share/autoconf/autoscan/autoscan.list
/usr/share/autoconf/autotest

Fedora Account System and Bugzilla Mismatch email

2021-03-03 Thread Lukas Zapletal

Hey,

I got an email asking me to change my fedora email to match my BZ account. 
Problem is, in BZ I have to use my redhat account which allows me to be granted 
special permissions for RH-related bugs. Fedora wants to do this for the same 
reason, however I'd like to separate my upstream contribution and all accounts 
from my work account, therefore I'd like to continue using my private email.

Is this something that can be solved? Like by adding a special field which is 
used to link BZ so users can set these individually?

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

Re: Pytest 4 in Fedora, let's get rid of it please


On 03. 03. 21 11:53, Paul Howarth wrote:

On Tue, 2 Mar 2021 09:10:32 -0800
Kevin Fenzi  wrote:


On Tue, Mar 02, 2021 at 04:40:54PM +, Paul Howarth wrote:

Hi all,

On Tue, 2 Mar 2021 16:06:40 +0100
Miro Hrončok  wrote:
   

Given the lack of communication from the paramiko/invoke
maintainers, I've just orphaned python-pytest4. If nobody picks
it up, I plan to continue maintaining it in Fedora 33 and 34.


The paramiko/invoke maintainers would be me. Sorry for not
responding but was very busy with work and I kept kicking it down
the road.

My interest in paramiko comes from use with ansible, which I am an
active user of. I picked up paramiko when it got orphaned.

...snip...

So, I am sure you are aware, but just to note, ansible can use
paramiko (and indeed thats default for el6, but nothing newer with
ControlPersist in ssh) but largely doesn't need it anymore.

As ansible maintainer I would be ok dropping it from ansible, but if
you are going to keep it around, ansible can keep Requiring it in
case some usecase needs it. :)


Good to know, thanks. I've dropped the invoke and pytest-relaxed
dependencies from paramiko now so there's no reason why it shouldn't
stay around.


Awesome! Thanks.

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

[Bug 1933836] perl-Sys-Virt-7.1.0 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Sys-Virt-7.1.0-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-03-03 10:56:41




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Pytest 4 in Fedora, let's get rid of it please

2021-03-03 Thread Paul Howarth

On Tue, 2 Mar 2021 09:10:32 -0800
Kevin Fenzi  wrote:

> On Tue, Mar 02, 2021 at 04:40:54PM +, Paul Howarth wrote:
> > Hi all,
> > 
> > On Tue, 2 Mar 2021 16:06:40 +0100
> > Miro Hrončok  wrote:
> >   
> > > Given the lack of communication from the paramiko/invoke
> > > maintainers, I've just orphaned python-pytest4. If nobody picks
> > > it up, I plan to continue maintaining it in Fedora 33 and 34.  
> > 
> > The paramiko/invoke maintainers would be me. Sorry for not
> > responding but was very busy with work and I kept kicking it down
> > the road.
> > 
> > My interest in paramiko comes from use with ansible, which I am an
> > active user of. I picked up paramiko when it got orphaned.  
> ...snip...
> 
> So, I am sure you are aware, but just to note, ansible can use
> paramiko (and indeed thats default for el6, but nothing newer with
> ControlPersist in ssh) but largely doesn't need it anymore. 
> 
> As ansible maintainer I would be ok dropping it from ansible, but if
> you are going to keep it around, ansible can keep Requiring it in
> case some usecase needs it. :)

Good to know, thanks. I've dropped the invoke and pytest-relaxed
dependencies from paramiko now so there's no reason why it shouldn't
stay around.

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

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

2021-03-03 Thread Pavel Březina


On 3/2/21 10:21 PM, Ray Strode wrote:

Hi,

On Tue, Mar 2, 2021, 11:20 AM Pavel Březina  wrote:

Can you reiterate the problem? The snippet above don't tell me much.

Sorry, let me summarize (but also see Benjamin's email).

Right now, if fingerprint auth is disabled in authselect, it's not
disabling fingerprint auth at the graphical login screen.

To disable fingerprint auth at the login screen, it needs to write out
a dconf file to tweak the enabled authentication methods.
I'm pretty sure it used to do this, or at least authconfig did.

If it doesn't disable it in the dconf config, the login screen will
try to use it.  It will then fail, and the user will see an error
message
blink by 3 times as it keeps retrying.


Authselect writes dconf but apparently it is missing from the minimal 
profile, I'll add it there.


https://github.com/authselect/authselect/issues/237


Now, on to Benjamin's point, if the fingerprint-auth service returned
AUTHINFO_UNAVAIL, then the login screen would treat the
failure as a "service unavailable" failure, and know not to retry,
which would be better that status quo. It would fix the user
experience,
but it's still not as good as not trying in the first place.

Of course, it wouldn't have to be an either/or.  authselect could
write out the dconf config, and make sure the fingerprint-auth stub
service returns PAM_AUTHINFO_UNAVAIL instead of falling back to
PAM_AUTH_ERR from the pam_deny in /etc/pam.d/other


https://github.com/authselect/authselect/issues/238


make sense?


Yes, thank you. I opened the tickets and will fix them soon.



--Ray


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

Fedora-IoT-35-20210303.0 compose check report

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

Old failures (same test failed in Fedora-IoT-35-20210301.0):

ID: 797599  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/797599
ID: 797608  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/797608
ID: 797612  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/797612
ID: 797615  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/797615
ID: 797621  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/797621

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

Old soft failures (same test soft failed in Fedora-IoT-35-20210301.0):

ID: 797591  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/797591
ID: 797592  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/797592
ID: 797593  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/797593
ID: 797607  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/797607

Passed openQA tests: 10/15 (aarch64), 12/16 (x86_64)

New passes (same test not passed in Fedora-IoT-35-20210301.0):

ID: 797610  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/797610
ID: 797618  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/797618
ID: 797619  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/797619

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 192 MiB to 172 MiB
Previous test data: https://openqa.fedoraproject.org/tests/794391#downloads
Current test data: https://openqa.fedoraproject.org/tests/797591#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 192 MiB to 172 MiB
Previous test data: https://openqa.fedoraproject.org/tests/794392#downloads
Current test data: https://openqa.fedoraproject.org/tests/797592#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Used mem changed from 208 MiB to 185 MiB
Previous test data: https://openqa.fedoraproject.org/tests/794422#downloads
Current test data: https://openqa.fedoraproject.org/tests/797607#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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Merging mingw specs into native spec

2021-03-03 Thread Daniel P . Berrangé

On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote:
> V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a):
> > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > > +%if %{_with_mingw}
> > > +
> > > +%package -n mingw32-libvirt-glib
> > > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > > +BuildArch: noarch
> > > +Requires: pkgconfig
> > > +
> 
> Why are the packages noarch if they contain a machine code?
> 
> Fullarch Linux packages are built on various architectures. Is MinGW toolchain
> available on all of them? E.g if my Linux package builds on s390x, is
> there a crosscompiler available and is thus possible to build Windows
> binaries there? What about runnning tests in %check phase?

The mingw toolchain is a cross compiler, and available on all Fedora
arches, so it doesn't matter what arch we build the DLLs on. Generally
we dont run tests in %check for mingw, but in theory you could use
wine to do this.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Wednesday's FESCo Meeting (2021-03-03)

2021-03-03 Thread Zbigniew Jędrzejewski-Szmek


Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
irc.freenode.net.

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

or run:
  date -d '2021-03-03 15:00 UTC'


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


= Followups =

#2584 Fedora 34 incomplete changes: 100% complete dealine
https://pagure.io/fesco/issue/2584


= New business =

#2579 F35 Change: Autoconf-2.71
https://pagure.io/fesco/issue/2579

#2581 F35 Change: POWER 4KiB page size
https://pagure.io/fesco/issue/2581

#2585 systemd-resolved: stub resolver is not following CNAME for resolution
https://pagure.io/fesco/issue/2585


= Open Floor = 

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-32-20210303.0 compose check report

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-20210302.0):

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

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1933868] perl-Date-Manip-6.85 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-ccb745c82e has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ccb745c82e


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20210303.n.0 compose check report

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 14/187 (x86_64), 14/126 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210228.n.0):

ID: 797104  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/797104
ID: 797129  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/797129
ID: 797141  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/797141
ID: 797270  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/797270
ID: 797359  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/797359
ID: 797375  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/797375
ID: 797378  Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/797378
ID: 797385  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/797385
ID: 797395  Test: aarch64 universal upgrade_2_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/797395

Old failures (same test failed in Fedora-Rawhide-20210228.n.0):

ID: 797133  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/797133
ID: 797150  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/797150
ID: 797159  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/797159
ID: 797163  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/797163
ID: 797168  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/797168
ID: 797178  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/797178
ID: 797179  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/797179
ID: 797180  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/797180
ID: 797219  Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/797219
ID: 797243  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/797243
ID: 797285  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/797285
ID: 797286  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/797286
ID: 797299  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/797299
ID: 797362  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/797362
ID: 797363  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/797363
ID: 797370  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/797370
ID: 797397  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/797397
ID: 797398  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/797398
ID: 797402  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/797402

Soft failed openQA tests: 77/187 (x86_64), 48/126 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20210228.n.0):

ID: 797160  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/797160
ID: 797225  Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/797225
ID: 797251  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/797251
ID: 797261  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/797261

Old soft failures (same test soft failed in Fedora-Rawhide-20210228.n.0):

ID: 797091  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/797091
ID: 797092  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/797092
ID: 797094  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/797094
ID: 797099  Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/797099
ID:

Re: Self Introduction: Tomáš

2021-03-03 Thread Tomas Halman

Thank you for your offer. I'm taking over few packages from Jakub Hrozek
now and he provides
all the information that I need. So far so good :)

Tom

On Tue, Mar 2, 2021 at 8:31 PM Matthew Miller 
wrote:

> On Tue, Mar 02, 2021 at 10:40:27AM +0100, Tomas Halman wrote:
> > My name is Tomáš or Tom for short.
> >
> > I have worked with linux since Red Hat 3 and Fedora 1 :)
> > Now I would like to join the community and put some effort into Fedora.
> We
> > might have met before on Devconf or Fosdem, eventually in the ZeroMQ
> > community.
>
> Wow, that's going back a ways. :) Welcome to the project! Anything we can
> do
> to help you get started?
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

Actually yes, you are right. Currently all fedora prackages are buildable
with autoconf-2.69 and there is a small part (~190), which are not
buildable with autoconf-2.71 (will use compat package instead).

Thanks for your advice, I didn't realize this at the moment.

Ondrej

On Wed, Mar 3, 2021 at 9:31 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote:
> > Understand, starting to work on delivering autoconf-2.69 compat package.
> > Have to investigate if it would be possible to install autoconf-2.69 and
> > autoconf-2.71 next to each other on the system. Will keep you updated.
>
> Actually, it might not be necessary to have them parallel-installable.
> If that is easy, then that's a nice property to have. But just being
> able to install one or the other in mock is enough.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

2021-03-03 Thread Dominique Martinet

Zbigniew Jędrzejewski-Szmek wrote on Wed, Mar 03, 2021 at 08:25:30AM +:
> On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote:
> > Understand, starting to work on delivering autoconf-2.69 compat package.
> > Have to investigate if it would be possible to install autoconf-2.69 and
> > autoconf-2.71 next to each other on the system. Will keep you updated.
> 
> Actually, it might not be necessary to have them parallel-installable.
> If that is easy, then that's a nice property to have. But just being
> able to install one or the other in mock is enough.

For what it's worth debian has compat packages so it doesn't look too bad:

configure --normal-flags --program-suffix=2.69
make pkgdatadir=/usr/share/autoconf2.69
mv /usr/share/autoconf /usr/share/autoconf2.69 (at install time)

seems to be most of it

(that said I do agree it's not worth spending hours on it)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Merging mingw specs into native spec

2021-03-03 Thread Petr Pisar

V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a):
> On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > +%if %{_with_mingw}
> > +
> > +%package -n mingw32-libvirt-glib
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +

Why are the packages noarch if they contain a machine code?

Fullarch Linux packages are built on various architectures. Is MinGW toolchain
available on all of them? E.g if my Linux package builds on s390x, is
there a crosscompiler available and is thus possible to build Windows
binaries there? What about runnning tests in %check phase?

-- Petr


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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

2021-03-03 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote:
> Understand, starting to work on delivering autoconf-2.69 compat package.
> Have to investigate if it would be possible to install autoconf-2.69 and
> autoconf-2.71 next to each other on the system. Will keep you updated.

Actually, it might not be necessary to have them parallel-installable.
If that is easy, then that's a nice property to have. But just being
able to install one or the other in mock is enough.

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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)