[389-devel] 389 DS nightly 2020-08-01 - 95% PASS

[vashirov]

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

Re: Review swaps

[Qiyu Yan]

Jerry James  于 2020年8月1日周六 上午5:24写道：

> I need two packages reviewed to enable some optional functionality in
> the normaliz package.  The second depends on the first:
>
> antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862615

Done for this.

>
> e-antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862616

Maybe we should wait the former one to be ready in rawhide, then this?

>
>
> Let me know what I can review for you in exchange.   Thanks,
> --
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-713ebad0a1   
golang-1.13.14-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d1b24a2a25   
snmptt-1.4.2-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

mozilla-https-everywhere-2020.5.20-1.el6
qpid-proton-0.31.0-3.el6

Details about builds:



 mozilla-https-everywhere-2020.5.20-1.el6 (FEDORA-EPEL-2020-1aa81038ca)
 HTTPS enforcement extension for Mozilla Firefox

Update Information:

Sorry for the late update everyone. Laptop decided to die for a couple months.
- EASE HTTP Once CSS fix - Allow users to whitelist hosts from the option page -
EASE mode fixes for locale issue - Fetch Test Prep, TLS 1.2 update - Fetch Test
Prep, Updated check rules script - Fix options page appearance on Firefox when
dark mode is on - Dark mode adjustments - Reverting Onboarding page for the time
being - Patch for whitelisting rules and EASE mode issue - Double rule load
patch in update channels - Fix minor JS and UX issues

ChangeLog:

* Fri Jul 31 2020 Russell Golden  - 2020.5.20-1
- EASE HTTP Once CSS fix
- Allow users to whitelist hosts from the option page
- EASE mode fixes for locale issue
- Fetch Test Prep, TLS 1.2 update
- Fetch Test Prep, Updated check rules script
- Fix options page appearance on Firefox when dark mode is on
- Dark mode adjustments
- Reverting Onboarding page for the time being
- Patch for whitelisting rules and EASE mode issue
- Double rule load patch in update channels
- Fix minor JS and UX issues
* Tue Jul 28 2020 Fedora Release Engineering  - 
2019.11.7-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed Jan 29 2020 Fedora Release Engineering  - 
2019.11.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

References:

  [ 1 ] Bug #1809025 - mozilla-https-everywhere EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1809025
  [ 2 ] Bug #1814134 - mozilla-https-everywhere-2020.5.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814134




 qpid-proton-0.31.0-3.el6 (FEDORA-EPEL-2020-2fe96ee806)
 A high performance, lightweight messaging library

Update Information:

Added rubygem-qpid_proton package.

ChangeLog:

* Wed Jul 29 2020 Irina Boverman  - 0.31.0-3
- Added rubygem-qpid_proton sub-package


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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d4ceeda8e   
java-latest-openjdk-14.0.2.12-1.rolling.el8
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cf43d780cc   
chromium-84.0.4147.89-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2b702ad070   
rpki-client-6.7p1-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88b5647c18   
radare2-4.5.0-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

ark-19.12.2-2.el8
hashcat-6.1.1-1.el8
mozilla-https-everywhere-2020.5.20-1.el8
patchelf-0.11-1.el8
perl-HTML-Element-Extended-1.18-21.el8
python-click-completion-0.5.2-3.el8
python-git-url-parse-1.2.2-6.el8
python-twine-2.0.0-1.el8
qpid-proton-0.31.0-3.el8
seamonkey-2.53.3-3.el8

Details about builds:



 ark-19.12.2-2.el8 (FEDORA-EPEL-2020-6ba549ab3a)
 Archive manager

Update Information:

Security fix for CVE-2020-16116 - maliciously crafted archive can install files
anywhere in the user's home directory

ChangeLog:

* Fri Jul 31 2020 Than Ngo  - 19.12.2-2
- Fix #1862466 - CVE-2020-16116, maliciously crafted archive can install files 
anywhere in the user's home directory

References:

  [ 1 ] Bug #1862466 - CVE-2020-16116 ark: maliciously crafted archive can 
install files anywhere in the user's home directory [epel-8]
https://bugzilla.redhat.com/show_bug.cgi?id=1862466




 hashcat-6.1.1-1.el8 (FEDORA-EPEL-2020-6a4135a079)
 Advanced password recovery utility

Update Information:

Updated to version 6.1.1.

ChangeLog:

* Fri Jul 31 2020 Vitaly Zaitsev  - 6.1.1-1
- Updated to version 6.1.1.
* Tue Jul 28 2020 Fedora Release Engineering  - 
6.0.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 mozilla-https-everywhere-2020.5.20-1.el8 (FEDORA-EPEL-2020-684a47c87c)
 HTTPS enforcement extension for Mozilla Firefox

Update Information:

Sorry for the late update everyone. Laptop decided to die for a couple months.
- EASE HTTP Once CSS fix - Allow users to whitelist hosts from the option page -
EASE mode fixes for locale issue - Fetch Test Prep, TLS 1.2 update - Fetch Test
Prep, Updated check rules script - Fix options page appearance on Firefox when
dark mode is on - Dark mode adjustments - Reverting Onboarding page for the time
being - Patch for whitelisting rules and EASE mode issue - Double rule load
patch in update channels - Fix minor JS and UX issues

ChangeLog:


References:

  [ 1 ] Bug #1809025 - mozilla-https-everywhere EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1809025
  [ 2 ] Bug #1814134 - mozilla-https-everywhere-2020.5.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814134




 patchelf-0.11-1.el8 (FEDORA-EPEL-2020-1fe12c8b56)
 A utility for patching ELF binaries

Update Information:

Updated to 0.11.

ChangeLog:

* Fri Jul 31 2020 Jeremy Sanders  - 0.11-1
- Updated to 0.11 (#1846586)
- Rebuild for EPEL
* Tue Jul 28 2020 Fedora Release Engineering  - 0.10-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed Jan 29 2020 Fedora Release Engineering  - 0.10-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 perl-HTML-Element-Extended-1.18-21.el8 (FEDORA-EPEL-2020-c3d39d5e26)
 Various HTML::Element extensions

Update 

[Bug 1811618] [RFE] EPEL8 branch of perl-HTML-Element-Extended

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-c3d39d5e26 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-2020-c3d39d5e26

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > Looks like it's in the buildroots now.  Let me know if that doesn't fix the
> > problem.
> 
> Looks as if "ar" is segfaulting again ...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> 
> That was built with binutils 2.35-8.fc33
So -9 is currently in the buildroot.  -10 should hit relatively soon.  I've
verified -10 will build libguestfs and itself.  I've also verified all the
programs in the binutils packages have no absolute symbols.

I still plan to download all the mass-rebuild binaries and look for absolute
symbols.  THat will tell us every package that should be rebuilt with binutils-
2.35-10.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > Looks like it's in the buildroots now.  Let me know if that doesn't fix the
> > problem.
> 
> Looks as if "ar" is segfaulting again ...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> 
> That was built with binutils 2.35-8.fc33
Just an FYI binutils-2.35-9 is in the buildroots.  It's got the fix for the LTO
issue, but does not turn on LTO for binutils itself (that'll be in the -10
build).

I've confirmed that the -9 build will correctly build binutils-2.35-10.  I've
also confirmed that the -9 build will correctly build libguestfs.

I'm going to take my local -10 build and use that to build libguestfs as an
additional sanity check.

jeff

ps.  I found out why SuSE didn't stumble on these issues.  They disabled LTO in
binutils.  Their ChangeLog says it's just the testsuite, but the implementation
is for the entire build.  I suspect they probably have a few packages that are
either silently broken or where they've turned off LTO due to failures without a
real root-cause-analysis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1862651] New: perl-IO-Compress-2.096 is available

[bugzilla]

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

Bug ID: 1862651
   Summary: perl-IO-Compress-2.096 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Compress
  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,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
rland...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.096
Current version/release in rawhide: 2.093-2.fc32
URL: http://search.cpan.org/dist/IO-Compress/

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


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

[EPEL-devel] Continuing playground discussion

[Troy Dawson]

We were having a good discussion about epel8-playground in the
Steering Committee meeting this week.  Since we ran out of time I'd
like to continue it via email.

Most everyone agreed that playground is currently a bit of a mess and
it's hard to explain to end users what it is for, or when to use it.
It was also agreed that we need to decide on a plan of "this is what
playground is for" and then work to setup/cleanup/document things.

There seemed to be two main opinions of what to set the plan to.

A) epel8-playground is meant for package development and testing for
major changes.  We stop doing the "build on both epel8 and
epel8-playground", and epel8-playground packages only get built from
the epel8-playground dist-git branch.

B) epel8-playground is meant for future RHEL/CentOS testing, and thus
everything built in epel8-playground get's built off CentOS Stream.
We would continue the "build on both epel8 and epel8-playground" and
this would make sure packages would be able to build on the newer
RHEL.

Both of these plans would require epel8-playground cleanup, and
re-implementation.  Both would require work.  But the work would be
quite different with the different plans.  So until we decide which
way to go, we don't know what to do.

Thoughts on which plan to choose?  Or if there is something different?

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

[Bug 1862641] New: perl-Compress-Raw-Bzip2-2.096 is available

[bugzilla]

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

Bug ID: 1862641
   Summary: perl-Compress-Raw-Bzip2-2.096 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Compress-Raw-Bzip2
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.096
Current version/release in rawhide: 2.093-2.fc32
URL: http://search.cpan.org/dist/Compress-Raw-Bzip2/

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


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

[Bug 1862640] New: perl-Compress-Raw-Zlib-2.096 is available

[bugzilla]

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

Bug ID: 1862640
   Summary: perl-Compress-Raw-Zlib-2.096 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Compress-Raw-Zlib
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.096
Current version/release in rawhide: 2.093-2.fc32
URL: http://search.cpan.org/dist/Compress-Raw-Zlib/

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


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

Review swaps

[Jerry James]

I need two packages reviewed to enable some optional functionality in
the normaliz package.  The second depends on the first:

antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862615
e-antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862616

Let me know what I can review for you in exchange.   Thanks,
-- 
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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 20:51 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 01:37:25PM -0600, Jeff Law wrote:
> > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > > Looks like it's in the buildroots now.  Let me know if that doesn't fix 
> > > > the
> > > > problem.
> > > 
> > > Looks as if "ar" is segfaulting again ...
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > > 
> > > That was built with binutils 2.35-8.fc33
> > I think I know what Nick did wrong.  I think he built binutils-2.35-8 with 
> > the
> > broken binutils.  WHat needed to happen was to build the fixed binutils 
> > without
> > LTO, get that into the buildroot, then build again with LTO re-enabled.
> > 
> > I can't seem to post to fedora-releng.  Can you ask someone to untag 2.35-8.
> >  I'll back back online in an hour or so to bootstrap binutils and get this 
> > fixed
> > for the *final* time.
> 
> Kevin Fenzi just untagged that one.  However you may need to wait for
> the buildroot to regenerate before building again, ie:
> 
>   $ koji wait-repo f33-build --build=binutils-2.35-XXX.fc33 --timeout=1
> 
> substituting XXX = whatever the latest good version is now (6?).
I'm not even sure myself.  I'll have to pull them out of koji, examine the
binaries and see which is the right one to start the bootstrap process.

I could think of better ways to spend my afternoon.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

On Fri, Jul 31, 2020 at 01:37:25PM -0600, Jeff Law wrote:
> On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > Looks like it's in the buildroots now.  Let me know if that doesn't fix 
> > > the
> > > problem.
> > 
> > Looks as if "ar" is segfaulting again ...
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > 
> > That was built with binutils 2.35-8.fc33
> I think I know what Nick did wrong.  I think he built binutils-2.35-8 with the
> broken binutils.  WHat needed to happen was to build the fixed binutils 
> without
> LTO, get that into the buildroot, then build again with LTO re-enabled.
> 
> I can't seem to post to fedora-releng.  Can you ask someone to untag 2.35-8.
>  I'll back back online in an hour or so to bootstrap binutils and get this 
> fixed
> for the *final* time.

Kevin Fenzi just untagged that one.  However you may need to wait for
the buildroot to regenerate before building again, ie:

  $ koji wait-repo f33-build --build=binutils-2.35-XXX.fc33 --timeout=1

substituting XXX = whatever the latest good version is now (6?).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Kevin Fenzi]

On Fri, Jul 31, 2020 at 01:37:25PM -0600, Jeff Law wrote:
> On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > Looks like it's in the buildroots now.  Let me know if that doesn't fix 
> > > the
> > > problem.
> > 
> > Looks as if "ar" is segfaulting again ...
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > 
> > That was built with binutils 2.35-8.fc33
> I think I know what Nick did wrong.  I think he built binutils-2.35-8 with the
> broken binutils.  WHat needed to happen was to build the fixed binutils 
> without
> LTO, get that into the buildroot, then build again with LTO re-enabled.
> 
> I can't seem to post to fedora-releng.  Can you ask someone to untag 2.35-8.
>  I'll back back online in an hour or so to bootstrap binutils and get this 
> fixed
> for the *final* time.

Done.

kevin


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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > Looks like it's in the buildroots now.  Let me know if that doesn't fix the
> > problem.
> 
> Looks as if "ar" is segfaulting again ...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> 
> That was built with binutils 2.35-8.fc33
I think I know what Nick did wrong.  I think he built binutils-2.35-8 with the
broken binutils.  WHat needed to happen was to build the fixed binutils without
LTO, get that into the buildroot, then build again with LTO re-enabled.

I can't seem to post to fedora-releng.  Can you ask someone to untag 2.35-8.
 I'll back back online in an hour or so to bootstrap binutils and get this fixed
for the *final* time.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > Looks like it's in the buildroots now.  Let me know if that doesn't fix the
> > problem.
> 
> Looks as if "ar" is segfaulting again ...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> 
> That was built with binutils 2.35-8.fc33
Actually, it's "nm" that's faulting rather than "ar" and it's happening during
debuginfo extraction, so this could be something completely different.

Anyway, I'm looking at it now.

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

Re: Fedora rawhide compose report: 20200731.n.0 changes

[Fabio Valentini]

On Fri, Jul 31, 2020 at 8:24 PM Fedora Rawhide Report
 wrote:
>
> OLD: Fedora-Rawhide-20200721.n.0
> NEW: Fedora-Rawhide-20200731.n.0

Wild Rawhide Compose appears!
Thanks to everybody who made this one finally happen.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> Looks like it's in the buildroots now.  Let me know if that doesn't fix the
> problem.

Looks as if "ar" is segfaulting again ...

https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log

That was built with binutils 2.35-8.fc33

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

Re: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Mon, 2020-07-27 at 18:20 +0200, Nikola Forró wrote:
> On Sat, 2020-07-25 at 01:11 -0600, Jeff Law wrote:
> > So at a high level ar makes a call to lrealpath.  That naturally goes 
> > through the
> > PLT.  The PLT stub loads the value out of the GOT and jumps to it.  The 
> > problem
> > is the entry in the GOT is *zero* when it should be pointing to the 
> > resolver.
> > 
> > Now lrealpath is provided by libiberty and a copy is in libbfd.so and the 
> > GOT
> > entry in libbfd.so looked right.  But by the time the program has hit main, 
> > the
> > GOT entry has been reset to zero.  Naturally that's happening inside the 
> > dynamic
> > linker (as expected, confirmed with a watchpoint).  If you've ever had to 
> > debug
> > ld.so, you'll know it's an insanely painful experience, but it proved 
> > fruitful.
> > 
> > The key was finding out that we were not using the libbfd.so linker map to
> > resolve lrealpath, instead we were using the linker map for the main 
> > program (ar
> > in this case).  So natrually it's time to look a bit more closely at the 
> > symbol
> > table for ar.
> > 
> > The main symbol table for ar it doesn't mention lrealpath.  But that's just 
> > a
> > confusing byproduct of having two symbol tables.  What matters to ld.so is 
> > the
> > *dynamic* symbol table.  And ar has lrealpath in its dynamic symbol table.  
> > And
> > here's the kicker, it's an absolute symbol with the value 0:
> > 
> >  A lrealpath
> > 
> > A symbol in the main program takes precedence over a symbol in a DSO.  So 
> > the
> > dynamic linker was actually doing the right thing given the input it was
> > provided.
> > 
> > Now why (*&@#$ does ar have lrealpath as an absolute symbol?  It's got to be
> > related to the fact that when we link ar we pull in another copy of 
> > libiberty.
> >  In fact, ar links against libiberty twice.  Once via -liberty then again 
> > against
> > libiberty.a (and kindof a 3rd time indirectly via libbfd).  BUt even so that
> > shouldn't be creating an absolute symbol.  That's just weird.
> > 
> > This smells like a linker bug to me.  Not surprisingly if I force the 
> > system to
> > use ld.gold, then I don't see the bogus absolute symbol and the resultant ar
> > works just fine.
> > 
> > It's late and I'll dig further over the weekend, but right now this looks 
> > like a
> > linker bug to me.  I may turn off LTO globally or in the various instances 
> > of
> > binutils -- I need to sleep on that.
> 
> I'm seeing the same behavior with man-db, more specifically with accessdb
> linking to libmandb:
> 
> $ nm -D accessdb | grep xmalloc
>  A xmalloc
> 
> Obviously it segfaults, unless I disable LTO.
> 
> Is there a bugzilla for that linker bug?
Note the linker bug should be fixed now.  So you should be able to rebuild 
man-db 
with LTO now.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 18:49 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 10:55:15AM -0600, Jeff Law wrote:
> > On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote:
> > > * Richard W. M. Jones:
> > > 
> > > > Here's another one:
> > > > 
> > > >   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
> > > >   libguestfs-tools-c-1.43.1-2.fc33.x86_64
> > > >   readline-8.0-5.fc33.x86_64
> > > >   $ guestfish --version
> > > >   Segmentation fault (core dumped)
> > > > 
> > > >   (gdb) bt
> > > >   #0  0x in  ()
> > > >   #1  0x7f3212b72dad in history_filename
> > > >   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at 
> > > > ../histfile.c:152
> > > >   #2  0x7f3212b75e2d in read_history_range
> > > >   (filename=, from=0, to=-1) at ../histfile.c:280
> > > >   #3  0x5592dd33e646 in main ()
> > > > 
> > > > It also caused a build failure of another package in Koji
> > > > (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> > > > 
> > > >   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> > > > 
> > > > I suspect the problem isn't in readline but is in the main package,
> > > > mainly because I tried an older readline and that failed in the same
> > > > way.
> > > 
> > > This looks like the ld bug producing incorrect absolute symbols:
> > > 
> > > $ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
> > >   790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
> > >   791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
> > >   799:    1294 FUNCGLOBAL DEFAULT  ABS 
> > > locale_charset
> > > 
> > > 
> > > 
> > > I believe a fix for that is on its way to rawhide.
> > Yup.  binutils with the ld fix is nearly done building (just waiting on 
> > s390x).
> >  I'll have my eye on things today in case there's further fallout.
> > 
> > So Richard, wait for binutils-2.35.8 to hit the buildroots, respin 
> > guestfish and
> > we should be good.
> 
> No problem, will test when it arrives.
Looks like it's in the buildroots now.  Let me know if that doesn't fix the
problem.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

On Fri, Jul 31, 2020 at 10:55:15AM -0600, Jeff Law wrote:
> On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote:
> > * Richard W. M. Jones:
> > 
> > > Here's another one:
> > > 
> > >   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
> > >   libguestfs-tools-c-1.43.1-2.fc33.x86_64
> > >   readline-8.0-5.fc33.x86_64
> > >   $ guestfish --version
> > >   Segmentation fault (core dumped)
> > > 
> > >   (gdb) bt
> > >   #0  0x in  ()
> > >   #1  0x7f3212b72dad in history_filename
> > >   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at 
> > > ../histfile.c:152
> > >   #2  0x7f3212b75e2d in read_history_range
> > >   (filename=, from=0, to=-1) at ../histfile.c:280
> > >   #3  0x5592dd33e646 in main ()
> > > 
> > > It also caused a build failure of another package in Koji
> > > (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> > > 
> > >   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> > > 
> > > I suspect the problem isn't in readline but is in the main package,
> > > mainly because I tried an older readline and that failed in the same
> > > way.
> > 
> > This looks like the ld bug producing incorrect absolute symbols:
> > 
> > $ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
> >   790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
> >   791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
> >   799:    1294 FUNCGLOBAL DEFAULT  ABS 
> > locale_charset
> > 
> > 
> > 
> > I believe a fix for that is on its way to rawhide.
> Yup.  binutils with the ld fix is nearly done building (just waiting on 
> s390x).
>  I'll have my eye on things today in case there's further fallout.
> 
> So Richard, wait for binutils-2.35.8 to hit the buildroots, respin guestfish 
> and
> we should be good.

No problem, will test when it arrives.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disable LTO for now ?

[Vitaly Zaitsev via devel]

On 31.07.2020 19:15, Jeff Law wrote:
> Umm, those builds look fine -- I don't see any failures in those builds.

Switching to GCC fixed these issues.

> I would not generally recommend switching compilers to work around issues of 
> any
> kind. 

I used Clang only as a workaround to issue with another package, as it
was incompatible with GCC 10.

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

Re: Chromium failing on aarch64 in rawhide

[Jeff Law]

On Fri, 2020-07-31 at 13:26 -0400, Tom Callaway wrote:
> This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of 
> ffmpeg code that has not changed in _years_.
> 
> [clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC 
> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed 
> -Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so" 
> -Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp"
> FAILED: libclearkeycdm.so 
> g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro 
> -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -o 
> "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so" 
> @"./libclearkeycdm.so.rsp"
> obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function 
> `ff_prefetch_aarch64':
> (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol 
> `ff_prefetch_aarch64' defined in .text section in 
> obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
> error: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build)
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
> 
> The function it references is defined in libavcodec/aarch64/videodsp.S:
> 
> function ff_prefetch_aarch64, export=1
> subsw2,  w2,  #2
> prfmpldl1strm, [x0]
> prfmpldl1strm, [x0,  x1]
> add x0,  x0,  x1,  lsl #1
> b.gtX(ff_prefetch_aarch64)
> ret
> endfunc
> 
> Did something change in rawhide that might be breaking this?
Lots has changed ;-)  What's weird is this looks like conditional self recursion
and I don't see how we'd be getting an out of range branch.  But then again, 
it's
not clear what macro magic might be happening to turn that into actual assembler
code and how that might also be interacting with the compiler.

More seriously though, this could be LTO, or the branch tracking bits for 
aarch64
or something else entirely.

I'd try a non-LTO build first to see if that helps.  The standard way to turn 
LTO
off is

%define _lto_cflags %{nil}

Jeff

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

Chromium failing on aarch64 in rawhide

[Tom Callaway]

This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of
ffmpeg code that has not changed in _years_.

[clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed
-Wl,-O2 -Wl,--gc-sections -rdynamic -o "./libclearkeycdm.so"
-Wl,-soname="libclearkeycdm.so" @"./libclearkeycdm.so.rsp"
FAILED: libclearkeycdm.so
g++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro
-Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic
-o "./libclearkeycdm.so" -Wl,-soname="libclearkeycdm.so"
@"./libclearkeycdm.so.rsp"
obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function
`ff_prefetch_aarch64':
(.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against
symbol `ff_prefetch_aarch64' defined in .text section in
obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
error: Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.zGpENj (%build)
Child return code was: 1
EXCEPTION: [Error()]

The function it references is defined in libavcodec/aarch64/videodsp.S:

function ff_prefetch_aarch64, export=1
subsw2,  w2,  #2
prfmpldl1strm, [x0]
prfmpldl1strm, [x0,  x1]
add x0,  x0,  x1,  lsl #1
b.gtX(ff_prefetch_aarch64)
ret
endfunc

Did something change in rawhide that might be breaking this?

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

Re: Disable LTO for now ?

[Jeff Law]

On Thu, 2020-07-30 at 10:54 +0200, Vitaly Zaitsev via devel wrote:
> On 29.07.2020 15:59, Jeff Law wrote:
> > In general I want to have a very good indicator the issue is LTO related 
> > before I
> > disable.  THe build you referenced doesn't have any good indicators that 
> > LTO is
> > the problem.
> 
> My packages nheko and mtxclient are failed due to LTO. Can you check
> them? Currently built with Clang, but I can try to switch to GCC.
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1558560
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1558793
Umm, those builds look fine -- I don't see any failures in those builds.

I would not generally recommend switching compilers to work around issues of any
kind. 

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > Here's another one:
> > 
> >   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
> >   libguestfs-tools-c-1.43.1-2.fc33.x86_64
> >   readline-8.0-5.fc33.x86_64
> >   $ guestfish --version
> >   Segmentation fault (core dumped)
> > 
> >   (gdb) bt
> >   #0  0x in  ()
> >   #1  0x7f3212b72dad in history_filename
> >   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at 
> > ../histfile.c:152
> >   #2  0x7f3212b75e2d in read_history_range
> >   (filename=, from=0, to=-1) at ../histfile.c:280
> >   #3  0x5592dd33e646 in main ()
> > 
> > It also caused a build failure of another package in Koji
> > (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> > 
> > I suspect the problem isn't in readline but is in the main package,
> > mainly because I tried an older readline and that failed in the same
> > way.
> 
> This looks like the ld bug producing incorrect absolute symbols:
> 
> $ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
>   790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
>   791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
>   799:    1294 FUNCGLOBAL DEFAULT  ABS locale_charset
> 
> 
> 
> I believe a fix for that is on its way to rawhide.
Yup.  binutils with the ld fix is nearly done building (just waiting on s390x).
 I'll have my eye on things today in case there's further fallout.

So Richard, wait for binutils-2.35.8 to hit the buildroots, respin guestfish and
we should be good.

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

Re: Fedora 32 aarch64 build failures on copr

[Jeff Law]

On Fri, 2020-07-31 at 11:44 -0300, Augusto Caringi wrote:
> Hi,
> 
> On Thu, Jul 30, 2020 at 12:47 PM Jeremy Linton  wrote:
> > On 7/28/20 4:39 PM, Jeff Law wrote:
> > > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> > > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law  wrote:
> > > > > If this is a new failure (say in the last week), it could be an out
> > > > > of memory
> > > > > scenario.  Try disabling LTO.  The standard way to do that is
> > > > > 
> > > > > %define _lto_cflags %{nil}
> > > > > 
> > > > > In your %build stanza in the spec file.
> > > > > 
> > > > > Heff
> > > > 
> > > > I agree, it's almost certainly OOM because it says "fatal error:
> > > > Killed." I've never seen that happen for any reason other than OOM.
> > > I've seen it happen for a variety of reasons.  Please test with LTO 
> > > disabled and
> > > let me know if that helps.
> > 
> > As a FYI: I had similar problems not long ago building a tensorflow.
> > Reducing the build parallelism in that case helped reduce the memory
> > footprint sufficiently that the build completed.
> 
> I'm facing a similar problem building the bpftrace package...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48268388
> 
> But for me, it seems gcc is crashing with a simple cmake test program:
> 
> CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:60 (message):
>   The C compiler
> "/usr/bin/cc"
>   is not able to compile a simple test program.
> 
> /builddir/build/BUILD/bpftrace-0.11.0/CMakeFiles/CMakeTmp/testCCompiler.c:1:
> internal compiler error: Segmentation fault
> 
> https://kojipkgs.fedoraproject.org//work/tasks/9180/48269180/build.log
annobin failure.  From the log:

annobin: 
/builddir/build/BUILD/bpftrace-0.11.0/CMakeFiles/CMakeTmp/testCCompiler.c: 
AArch64: The annobin plugin is out of date with respect to gcc

Clearly Nick and Jakub need to be coordinating better to prevent these problems,
they come up far too regularly.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 17:19 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 05:19:15PM +0100, Richard W.M. Jones wrote:
> > (It's a bit big so I sent this to you privately)
> 
> Ooops, at least that was what I intended to do.
NP.  And yes, this is definitely the linker bug.  THe tell-tale sign is the
absolute symbols (type A in the nm output).

I've got a couple messages from Nick this morning on the issue, but I haven't
reviewed them yet.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

On Fri, Jul 31, 2020 at 05:19:15PM +0100, Richard W.M. Jones wrote:
> (It's a bit big so I sent this to you privately)

Ooops, at least that was what I intended to do.

Rich.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

(It's a bit big so I sent this to you privately)

On Fri, Jul 31, 2020 at 10:07:09AM -0600, Jeff Law wrote:
> On Fri, 2020-07-31 at 11:52 +0100, Richard W.M. Jones wrote:
> > Here's another one:
> > 
> >   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
> >   libguestfs-tools-c-1.43.1-2.fc33.x86_64
> >   readline-8.0-5.fc33.x86_64
> >   $ guestfish --version
> >   Segmentation fault (core dumped)
> > 
> >   (gdb) bt
> >   #0  0x in  ()
> >   #1  0x7f3212b72dad in history_filename
> >   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at 
> > ../histfile.c:152
> >   #2  0x7f3212b75e2d in read_history_range
> >   (filename=, from=0, to=-1) at ../histfile.c:280
> >   #3  0x5592dd33e646 in main ()
> > 
> > It also caused a build failure of another package in Koji
> > (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> > 
> > I suspect the problem isn't in readline but is in the main package,
> > mainly because I tried an older readline and that failed in the same
> > way.
> > 
> > I'm going to disable LTO in libguestfs and rebuild it.
> This is almost certainly the linker bug. I analyzed last week.
> 
> nm --dynamic guestfish
> 
> Would be enough for me to say conclusively.

 U abort
 U accept
 U accept4
 U access
 U add_history
 U append_history
 U __asprintf_chk
 U __assert_fail
 U bind
 U bindtextdomain
 U calloc
 U chdir
 U clearerr
 U clear_history
 U close
 U config_destroy
 U config_init
 U config_lookup_bool
 U config_read
 U connect
 U __ctype_b_loc
 U __ctype_get_mb_cur_max
 U __cxa_atexit
 w __cxa_finalize
 U dcgettext
 U dup
 U dup2
 U __errno_location
 U error
 U execvp
 U _exit
 U exit
 U fclose
 U fdopen
 U ferror
 U fflush
 U fgets
 U fileno
 U fnmatch
 U fopen
 U fork
 U __fpending
 U __fprintf_chk
 U fputc
 U fputs
 U free
 U fwrite
 U __gcc_personality_v0
 U __getdelim
 U getenv
 U geteuid
 U getopt_long
 U getpid
 U getpwent
 U gettimeofday
 w __gmon_start__
 U guestfs_acl_delete_def_file
 U guestfs_acl_get_file
 U guestfs_acl_set_file
 U guestfs_add_cdrom
 U guestfs_add_domain_argv
 U guestfs_add_drive_opts
 U guestfs_add_drive_opts_argv
 U guestfs_add_drive_ro
 U guestfs_add_drive_ro_with_if
 U guestfs_add_drive_scratch
 U guestfs_add_drive_scratch_argv
 U guestfs_add_drive_with_if
 U guestfs_aug_clear
 U guestfs_aug_close
 U guestfs_aug_defnode
 U guestfs_aug_defvar
 U guestfs_aug_get
 U guestfs_aug_init
 U guestfs_aug_insert
 U guestfs_aug_label
 U guestfs_aug_load
 U guestfs_aug_ls
 U guestfs_aug_match
 U guestfs_aug_mv
 U guestfs_aug_rm
 U guestfs_aug_save
 U guestfs_aug_set
 U guestfs_aug_setm
 U guestfs_aug_transform_argv
 U guestfs_available
 U guestfs_available_all_groups
 U guestfs_base64_in
 U guestfs_base64_out
 U guestfs_blkdiscard
 U guestfs_blkdiscardzeroes
 U guestfs_blkid
 U guestfs_blockdev_flushbufs
 U guestfs_blockdev_getbsz
 U guestfs_blockdev_getro
 U guestfs_blockdev_getsize64
 U guestfs_blockdev_getss
 U guestfs_blockdev_getsz
 U guestfs_blockdev_rereadpt
 U guestfs_blockdev_setbsz
 U guestfs_blockdev_setra
 U guestfs_blockdev_setro
 U guestfs_blockdev_setrw
 U guestfs_btrfs_balance_cancel
 U guestfs_btrfs_balance_pause
 U guestfs_btrfs_balance_resume
 U 

[Bug 1859506] perl-Mail-Transport-3.005 is available

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-07-31 16:15:51



--- Comment #3 from Tom "spot" Callaway  ---
In rawhide.


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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 11:52 +0100, Richard W.M. Jones wrote:
> Here's another one:
> 
>   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
>   libguestfs-tools-c-1.43.1-2.fc33.x86_64
>   readline-8.0-5.fc33.x86_64
>   $ guestfish --version
>   Segmentation fault (core dumped)
> 
>   (gdb) bt
>   #0  0x in  ()
>   #1  0x7f3212b72dad in history_filename
>   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at ../histfile.c:152
>   #2  0x7f3212b75e2d in read_history_range
>   (filename=, from=0, to=-1) at ../histfile.c:280
>   #3  0x5592dd33e646 in main ()
> 
> It also caused a build failure of another package in Koji
> (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> 
> I suspect the problem isn't in readline but is in the main package,
> mainly because I tried an older readline and that failed in the same
> way.
> 
> I'm going to disable LTO in libguestfs and rebuild it.
This is almost certainly the linker bug. I analyzed last week.

nm --dynamic guestfish

Would be enough for me to say conclusively.


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

librealsense soname bump to 2.38

[Till Hofmann]

Hi all,

I'm updating librealsense to 2.38.0 in the next few days, which includes
an soname bump.

The only dependency is fawkes, which I also maintain (and which is
currently FTBFS for other reasons).

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

spot pushed to perl-Mail-Transport (master). "3.005"

[notifications]

Notification time stamped 2020-07-31 15:25:39 UTC

From dd46d0973fab88525a5e1b49817aa348379cf54f Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Jul 31 2020 15:25:34 +
Subject: 3.005


---

diff --git a/.gitignore b/.gitignore
index b713ac6..185a4a3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Mail-Transport-3.002.tar.gz
 /Mail-Transport-3.003.tar.gz
 /Mail-Transport-3.004.tar.gz
+/Mail-Transport-3.005.tar.gz
diff --git a/perl-Mail-Transport.spec b/perl-Mail-Transport.spec
index 8a89679..38faa82 100644
--- a/perl-Mail-Transport.spec
+++ b/perl-Mail-Transport.spec
@@ -1,6 +1,6 @@
 Name:  perl-Mail-Transport
-Version:   3.004
-Release:   6%{?dist}
+Version:   3.005
+Release:   1%{?dist}
 Summary:   Email message exchange
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/Mail-Transport
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/Mail::Transport::Sendmail.3*
 
 %changelog
+* Fri Jul 31 2020 Tom Callaway  - 3.005-1
+- update to 3.005
+
 * Tue Jul 28 2020 Fedora Release Engineering  - 
3.004-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
 
diff --git a/sources b/sources
index 2c32fb9..3ccc12e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Mail-Transport-3.004.tar.gz) = 
133d093abb7fb6d596ae99ecc3d8559c9e8b61539e89505347a87e3735bf474a053ea429e2afe9c0d6b6d6900c91a23c9a137b5f9d233bdabea619e1d74f9c95
+SHA512 (Mail-Transport-3.005.tar.gz) = 
58e5b445207707cc259ce189d506423d66bd455c41c933ef3c5eb8a72645dd7f993276345a1be86658d5bab8fbb207eed48faecba6428b65fb48701c72585ad7



https://src.fedoraproject.org/rpms/perl-Mail-Transport/c/dd46d0973fab88525a5e1b49817aa348379cf54f?branch=master
___
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

[Test-Announce] Fedora-IoT 33 RC 20200731.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 33 RC 20200731.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33iot

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

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200731.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200731.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 aarch64 build failures on copr

[Augusto Caringi]

Hi,

On Thu, Jul 30, 2020 at 12:47 PM Jeremy Linton  wrote:
>
> On 7/28/20 4:39 PM, Jeff Law wrote:
> > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> >> On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law  wrote:
> >>> If this is a new failure (say in the last week), it could be an out
> >>> of memory
> >>> scenario.  Try disabling LTO.  The standard way to do that is
> >>>
> >>> %define _lto_cflags %{nil}
> >>>
> >>> In your %build stanza in the spec file.
> >>>
> >>> Heff
> >>
> >> I agree, it's almost certainly OOM because it says "fatal error:
> >> Killed." I've never seen that happen for any reason other than OOM.
> > I've seen it happen for a variety of reasons.  Please test with LTO 
> > disabled and
> > let me know if that helps.
>
> As a FYI: I had similar problems not long ago building a tensorflow.
> Reducing the build parallelism in that case helped reduce the memory
> footprint sufficiently that the build completed.

I'm facing a similar problem building the bpftrace package...

https://koji.fedoraproject.org/koji/taskinfo?taskID=48268388

But for me, it seems gcc is crashing with a simple cmake test program:

CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler
"/usr/bin/cc"
  is not able to compile a simple test program.
/builddir/build/BUILD/bpftrace-0.11.0/CMakeFiles/CMakeTmp/testCCompiler.c:1:
internal compiler error: Segmentation fault

https://kojipkgs.fedoraproject.org//work/tasks/9180/48269180/build.log

Thoughts?

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



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

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Richard,

> guestfish on x86-64 was failing for me with something that looks a lot
> like the same PLT problem.  But it's not aarch64.  Very easy to
> reproduce, see:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/

This looks like it might be the binutils/LTO thing:

  https://sourceware.org/bugzilla/show_bug.cgi?id=26314

The patches for that PR are now in rawhide and a rebuild is taking place,
(It has not finished yet as builds are taking a very long time today).
Look for binutils-2.35-8.fc33 to appear in the buildroot and then try again.

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

Re: Duplicate package was reviewed

[Michael Schwendt]

On Fri, 31 Jul 2020 12:48:44 +0200, Tomasz Torcz wrote:

>   What about bringing old, possibly unmaintained library into Fedora?
> It may contain unfixed security bugs.  Not that I know of any, but it's
> a possibility.

1) First it would need to pass the review process. Submitter _and_
reviewer both ought to notice that it is "old, possibly unmaintained"
software. In case of a lib, there's also the related question of "what
will use this lib?". Later it will be "what still uses this lib?" and
"are there alternatives or a successor?".

2) Once a package has been included in the package collection, "old,
possibly unmaintained" software is sort of a grey area. There are
thousands of packages in the collection, "possibly" with undiscovered
security issues. For those that are known to contain major vulnerabilities
and are unmaintained (like wxGTK2), it may be necessary to remove a
package from the collection.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

module build: BuildrootError: could not init mock buildroot

[Jun Aruga]

Hi,
Sometimes once per a few times,  I faced the following weird build
error when building Ruby modules.
Did you see it? Known issue?

https://koji.fedoraproject.org/koji/taskinfo?taskID=48194471
BuildrootError: could not init mock buildroot, mock exited with status
20; see root.log for more information

https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/root.log
  => looks ok.
https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/build.log
  => empty.

Thanks.

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

[Bug 1811618] [RFE] EPEL8 branch of perl-HTML-Element-Extended

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

[Test-Announce] Fedora 33 Rawhide 20200731.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200731.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
python-blivet - 20200721.n.0: python-blivet-3.2.2-2.fc33.src, 20200731.n.0: 
python-blivet-3.2.2-4.fc33.src
pyparted - 20200721.n.0: pyparted-3.11.5-2.fc33.src, 20200731.n.0: 
pyparted-3.11.5-3.fc33.src
parted - 20200721.n.0: parted-3.3-3.fc33.src, 20200731.n.0: 
parted-3.3-4.fc33.src
lorax - 20200721.n.0: lorax-33.7-1.fc33.src, 20200731.n.0: lorax-33.8-1.fc33.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

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

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200731.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Mark Wielaard]

On Fri, 2020-07-31 at 12:44 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote:
> > That binutils was rebuilt (thanks to Richard Jones) and I have now
> > built an even newer one which contains a fix for AArch64 PLT problems.
> > Both of these are built with LTO disabled, so the bug should not affect 
> > them.
> 
> guestfish on x86-64 was failing for me with something that looks a lot
> like the same PLT problem.  But it's not aarch64.  Very easy to
> reproduce, see:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/

Just for the record, I don't think that is the aarch64 plt thing.
Which is https://bugzilla.redhat.com/show_bug.cgi?id=1862110
That would show up as "Failed to update file: invalid section entry
size". I think this is a real LTO issue (both the aarch64 plt and zero
DWARF version weren't, just "normal" bugs in binutils as and binutils
ld, unrelated to LTO).

Cheers,

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Florian Weimer]

* Richard W. M. Jones:

> Here's another one:
>
>   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
>   libguestfs-tools-c-1.43.1-2.fc33.x86_64
>   readline-8.0-5.fc33.x86_64
>   $ guestfish --version
>   Segmentation fault (core dumped)
>
>   (gdb) bt
>   #0  0x in  ()
>   #1  0x7f3212b72dad in history_filename
>   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at ../histfile.c:152
>   #2  0x7f3212b75e2d in read_history_range
>   (filename=, from=0, to=-1) at ../histfile.c:280
>   #3  0x5592dd33e646 in main ()
>
> It also caused a build failure of another package in Koji
> (search the logs for "ext2.img] Segmentation fault (core dumped)"):
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
>
> I suspect the problem isn't in readline but is in the main package,
> mainly because I tried an older readline and that failed in the same
> way.

This looks like the ld bug producing incorrect absolute symbols:

$ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
  790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
  791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
  799:    1294 FUNCGLOBAL DEFAULT  ABS locale_charset



I believe a fix for that is on its way to rawhide.

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

Re: Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

On Fri, Jul 31, 2020 at 11:52:05AM +0100, Richard W.M. Jones wrote:
> Here's another one:
> 
>   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
>   libguestfs-tools-c-1.43.1-2.fc33.x86_64
>   readline-8.0-5.fc33.x86_64
>   $ guestfish --version
>   Segmentation fault (core dumped)
> 
>   (gdb) bt
>   #0  0x in  ()
>   #1  0x7f3212b72dad in history_filename
>   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at ../histfile.c:152
>   #2  0x7f3212b75e2d in read_history_range
>   (filename=, from=0, to=-1) at ../histfile.c:280
>   #3  0x5592dd33e646 in main ()
> 
> It also caused a build failure of another package in Koji
> (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> 
> I suspect the problem isn't in readline but is in the main package,
> mainly because I tried an older readline and that failed in the same
> way.
> 
> I'm going to disable LTO in libguestfs and rebuild it.

And indeed building it again with LTO disabled, it now works:

$ rpm -qf /usr/bin/guestfish 
libguestfs-tools-c-1.43.1-3.fc33.x86_64
$ guestfish --version
guestfish 1.43.1fedora=33,release=3.fc33,libvirt

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote:
> Hi Guys,
> 
> >> Yes, because the commit adding the DWARF 4 patch has also
> >> turned LTO back on...
> 
> *double sigh*.  Yes I was trying to fix the LTO bug at the same time, 
> and forgot that I had re-enabled it in my local copy of the rawhide
> sources in order to investigate the problems.
> 
> That binutils was rebuilt (thanks to Richard Jones) and I have now
> built an even newer one which contains a fix for AArch64 PLT problems.
> Both of these are built with LTO disabled, so the bug should not affect them.

guestfish on x86-64 was failing for me with something that looks a lot
like the same PLT problem.  But it's not aarch64.  Very easy to
reproduce, see:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/

Rich.

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

Another possible LTO failure in guestfish (or maybe readline)

[Richard W.M. Jones]

Here's another one:

  $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
  libguestfs-tools-c-1.43.1-2.fc33.x86_64
  readline-8.0-5.fc33.x86_64
  $ guestfish --version
  Segmentation fault (core dumped)

  (gdb) bt
  #0  0x in  ()
  #1  0x7f3212b72dad in history_filename
  (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at ../histfile.c:152
  #2  0x7f3212b75e2d in read_history_range
  (filename=, from=0, to=-1) at ../histfile.c:280
  #3  0x5592dd33e646 in main ()

It also caused a build failure of another package in Koji
(search the logs for "ext2.img] Segmentation fault (core dumped)"):

  https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041

I suspect the problem isn't in readline but is in the main package,
mainly because I tried an older readline and that failed in the same
way.

I'm going to disable LTO in libguestfs and rebuild it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Duplicate package was reviewed

[Tomasz Torcz]

On Fri, Jul 31, 2020 at 12:01:53PM +0200, Michael Schwendt wrote:
> libqmatrixclient vs libquotient
> 
> Absolutely no conflict whatsoever. Different SONAME, different file/folder
> names, different package names, different project name. Even if they came
> from the same project, the old compat- naming scheme would not have applied.

  What about bringing old, possibly unmaintained library into Fedora?
It may contain unfixed security bugs.  Not that I know of any, but it's
a possibility.

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: We have to talk about annobin... again

[Neal Gompa]

On Fri, Jul 31, 2020 at 6:02 AM Kevin Kofler  wrote:
>
> Mark Wielaard wrote:
> > Although the sync issues are annoying I do think we, as developers of
> > and developers on the Fedora platform benefit from having the annobin
> > notes in the binaries. It is like making sure there is unwind
> > information or debug packages for each binary.
>
> I am not convinced that this cannot be addressed by my proposed approach of
> doing periodic annobin rebuilds in a side tag, only published through Koji
> or through some secondary mirror, not in the production repositories. You
> have the information you want in those rebuilds then.
>

I think it does have value, however I think the Red Hat compiler team
drastically underestimated how much breakage we're willing to tolerate
for it.

> > If things are perfect, they are just there for assurance. But if there is
> > an issue you want to look into, or you get a crash, want to do some
> > profiling to see what your machine is doing, writing a new program,
> > combine two libraries, etc. you are glad the information is there.
>
> I do not see how the annotations from annobin help in most of those use
> cases. In the case of a crash from conflicting flags, the flag conflict can
> be debugged by looking at the annotations in the packages from the side tag
> proposed above. For profiling, the compiler flags are not really needed. At
> most, you may want to document them when publishing results, and you can
> also do that from the side tag proposed above.
>
> The thing is, those flags are not going to magically change with every
> single package build, and they are also not going to be different if you
> rebuild the same SRPM in a side tag containing either the same RPMs or
> annobin rebuilds of them (or most likely a mix of both).
>

That's not true. Since Koji 1.18, it's been possible to modify the
build process by setting simple RPM macros and mock flags in build
tags. And with the module builds (which operate in chain builds on
side tags), there is a higher potential for modifications that can
result in a different set of binaries since it'll generate macros
packages on demand to do complex build environment changes.



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

Re: Duplicate package was reviewed

[Michael Schwendt]

libqmatrixclient vs libquotient

Absolutely no conflict whatsoever. Different SONAME, different file/folder
names, different package names, different project name. Even if they came
from the same project, the old compat- naming scheme would not have applied.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

>> Yes, because the commit adding the DWARF 4 patch has also
>> turned LTO back on...

*double sigh*.  Yes I was trying to fix the LTO bug at the same time, 
and forgot that I had re-enabled it in my local copy of the rawhide
sources in order to investigate the problems.

That binutils was rebuilt (thanks to Richard Jones) and I have now
built an even newer one which contains a fix for AArch64 PLT problems.
Both of these are built with LTO disabled, so the bug should not affect them.

Cheers
  Nick

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

Re: Orphaning openbabel

[Kevin Kofler]

Alexander Ploumistos wrote:
> The next release of Molsketch is going to build against Open Babel
> 3.x, so I started working on updating the openbabel package around the
> time version 3.1.1 came out, which supposedly fixed some issues
> related to packaging on linux. Based on your spec file, I was trying
> to see which patches were obsolete, what else might be required to get
> it to build with as many features as possible and then test the
> "abandonware" that depends on it. Unfortunately (fortunately?), the
> local lockdown was lifted and I was among the people authorized back
> in the lab and I got swamped with work, so I didn't get very far. I
> got the base stuff building at some point, but I had trouble with some
> runtime dependencies. In the meantime, there's been the CMake change
> and I don't know if what I got building still does.

We will likely also need an openbabel2 compatibility package then, because I 
doubt that everything will build against OpenBabel 3 without non-trivial 
porting.

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

Re: We have to talk about annobin... again

[Kevin Kofler]

Mark Wielaard wrote:
> Although the sync issues are annoying I do think we, as developers of
> and developers on the Fedora platform benefit from having the annobin
> notes in the binaries. It is like making sure there is unwind
> information or debug packages for each binary.

I am not convinced that this cannot be addressed by my proposed approach of 
doing periodic annobin rebuilds in a side tag, only published through Koji 
or through some secondary mirror, not in the production repositories. You 
have the information you want in those rebuilds then.

> If things are perfect, they are just there for assurance. But if there is
> an issue you want to look into, or you get a crash, want to do some
> profiling to see what your machine is doing, writing a new program,
> combine two libraries, etc. you are glad the information is there.

I do not see how the annotations from annobin help in most of those use 
cases. In the case of a crash from conflicting flags, the flag conflict can 
be debugged by looking at the annotations in the packages from the side tag 
proposed above. For profiling, the compiler flags are not really needed. At 
most, you may want to document them when publishing results, and you can 
also do that from the side tag proposed above.

The thing is, those flags are not going to magically change with every 
single package build, and they are also not going to be different if you 
rebuild the same SRPM in a side tag containing either the same RPMs or 
annobin rebuilds of them (or most likely a mix of both).

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

Re: Duplicate package was reviewed

[Kevin Kofler]

Vitaly Zaitsev via devel wrote:
> Previously it wasn't allowed to push different versions of the same
> project into repositories. That's why Fedora Modularity was invented.

That is what the Modularity developers wanted you to believe. The fact is, 
parallel-installable compatibility libraries have always been allowed, and 
they are the best approach to this problem, because they allow applications 
using the old and new library to be installed on the same system at the same 
time (without workarounds such as chroots, containers, or even VMs), unlike 
the mutually exclusive module versions in the Modularity approach.

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

Re: We have to talk about annobin... again

[Zdenek Dohnal]

Hi all,

I just want to warn you the error got into Fedora 32 too.

The symptoms are the same - not being able to build on aarch64 due 'gcc
is not able to create executables'.

Builds:

https://koji.fedoraproject.org/koji/taskinfo?taskID=48241569

https://koji.fedoraproject.org/koji/taskinfo?taskID=48234800

On 7/25/20 11:33 AM, Neal Gompa wrote:
> Hey all,
>
> So I was trying to update libseccomp last night, and I was able to
> build it for everything except aarch64 on Rawhide because it says the
> compiler can't build executables[1].
>
> Looking a bit closer, it looks like the compiler stack is out of sync
> again with annobin.
>
> Is there anything that can be done to keep the compiler teams from
> submitting gcc into rawhide without doing the required rebuild cycle
> to make it so annobin works?
>
> And we're going to have the same problem with clang now that annobin
> grew a clang plugin, so I would want neither LLVM nor GCC to land in
> Rawhide unless those teams are literally ensuring that annobin isn't
> breaking the compiler afterward.
>
> I'm personally very tired of having the compiler break so frequently
> because of that plugin. Either some kind of mechanism to hold back GCC
> builds until annobin works is implemented, or I'd much rather see the
> whole thing go away. Obviously, you could just *bundle* annobin into
> the GCC package and build it together to ensure it never broke, but
> that option was discarded already[2].
>
> Somebody fix it. ASAP.
>
> [1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=47796366
> [2]: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2DXP7WE2TY2Q2ZTW4L5R5WO5UJVKXESB/
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

[Bug 1811618] [RFE] EPEL8 branch of perl-HTML-Element-Extended

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jples...@redhat.com
   Assignee|nott...@splat.cc|jples...@redhat.com



--- Comment #2 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/27288
https://pagure.io/releng/fedora-scm-requests/issue/27289


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