Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1799514 - hugo: FTBFS in Fedora rawhide/f32
Summary: hugo: FTBFS in Fedora rawhide/f32
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: hugo
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Athos Ribeiro
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F32FTBFS
TreeView+ depends on / blocked
 
Reported: 2020-02-06 18:21 UTC by Fedora Release Engineering
Modified: 2020-04-12 22:12 UTC (History)
6 users (show)

Fixed In Version: hugo-0.65.2-1.fc32~bootstrap
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-08 08:50:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (32.00 KB, text/plain)
2020-02-06 18:21 UTC, Fedora Release Engineering
no flags Details
root.log (32.00 KB, text/plain)
2020-02-06 18:21 UTC, Fedora Release Engineering
no flags Details
state.log (1020 bytes, text/plain)
2020-02-06 18:21 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2020-02-06 18:21:11 UTC
hugo failed to build from source in Fedora rawhide/f32

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


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
Please fix hugo at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
hugo will be orphaned. Before branching of Fedora 33,
hugo will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://fedoraproject.org/wiki/Fails_to_build_from_source

Comment 1 Fedora Release Engineering 2020-02-06 18:21:14 UTC
Created attachment 1659298 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2020-02-06 18:21:16 UTC
Created attachment 1659299 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2020-02-06 18:21:17 UTC
Created attachment 1659300 [details]
state.log

Comment 4 Ben Cotton 2020-02-11 17:05:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 5 Fedora Release Engineering 2020-02-16 04:31:03 UTC
Dear Maintainer,

your package has not been built successfully in 32. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
will be orphaned if this bug remains in NEW state more than 8 weeks.

A week before the mass branching of Fedora 33 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 31 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedoraproject.org/wiki/Releases/33/Schedule

Comment 6 Fedora Release Engineering 2020-03-01 04:22:41 UTC
Dear Maintainer,

your package has not been built successfully in 32. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
will be orphaned if this bug remains in NEW state more than 8 weeks.

A week before the mass branching of Fedora 33 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 31 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedoraproject.org/wiki/Releases/33/Schedule

Comment 7 Fedora Release Engineering 2020-03-08 04:22:50 UTC
Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 32.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (that's on 2020-04-02).

A week before the mass branching of Fedora 33 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 31 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

Comment 8 Fedora Release Engineering 2020-03-29 04:22:52 UTC
Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 32.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (that's on 2020-04-02).

A week before the mass branching of Fedora 33 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 31 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

Comment 9 W. Michael Petullo 2020-04-01 16:06:04 UTC
I am willing to maintain Hugo.

Comment 10 Ranjan Maitra 2020-04-01 18:50:07 UTC
(In reply to W. Michael Petullo from comment #9)
> I am willing to maintain Hugo.

Excellent. I don't know if this is something that you already know of, but in case you don't:

https://docs.fedoraproject.org/en-US/fesco/

Btw, it may be worth considering bundling Hugo with the extended version, as per BZ #1756202.

Comment 11 W. Michael Petullo 2020-04-01 19:27:51 UTC
Regarding the extended version, I was the one who submitted https://src.fedoraproject.org/rpms/hugo/pull-request/10. I do indeed intend to merge that if I am allowed to maintain Hugo.

Comment 12 W. Michael Petullo 2020-04-01 19:31:58 UTC
Reverted status to new to allow package to become orphaned. I will pick it up once formally orphaned, based on advice provided at https://pagure.io/releng/issue/9374.

Comment 13 Robert-André Mauchin 🐧 2020-04-03 20:32:43 UTC
Hugo was built by qulogic on F32 and F33 several months ago, why is this bug still opened?

Comment 14 Ranjan Maitra 2020-04-04 00:08:49 UTC
(In reply to Robert-André Mauchin from comment #13)
> Hugo was built by qulogic on F32 and F33 several months ago, why is this bug
> still opened?

Perhaps qulogic needs to take and close this bug with an update? And also take W. Michael Petullo as a co-maintainer?

Comment 15 W. Michael Petullo 2020-04-04 01:10:59 UTC
I would be happy to co-maintain, I just did not want to see Hugo drop into a retired status.

Comment 16 Ranjan Maitra 2020-04-05 03:56:38 UTC
(In reply to W. Michael Petullo from comment #15)
> I would be happy to co-maintain, I just did not want to see Hugo drop into a
> retired status.

You may want to ask on the Fedora-devel mailing list. I don't understand why qulogic is not on this thread.

Comment 17 Elliott Sales de Andrade 2020-04-08 08:50:12 UTC
Indeed, this is already fixed for F32. I'm not a maintainer though, I only rebuild as part of Go SIG, and it doesn't get CC'd on all BZ.

Comment 18 Ranjan Maitra 2020-04-08 13:08:37 UTC
(In reply to Elliott Sales de Andrade from comment #17)
> Indeed, this is already fixed for F32. I'm not a maintainer though, I only
> rebuild as part of Go SIG, and it doesn't get CC'd on all BZ.

Not completely sure what this means, but perhaps Michael can maintain this officially and coordinate with you?

Comment 19 Elliott Sales de Andrade 2020-04-08 19:26:35 UTC
He would have to ask the existing maintainer; I have no powers to do that.

Comment 20 Ranjan Maitra 2020-04-10 15:04:24 UTC
(In reply to Elliott Sales de Andrade from comment #19)
> He would have to ask the existing maintainer; I have no powers to do that.

The original maintainter is most likely non-responsive because this was on the orphan list, but Michael can ask on fedora-devel and ask to take over its maintenance.  

Michael, here is the policy, including how exceptions may be needed:

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#orphaning-process

Comment 21 W. Michael Petullo 2020-04-10 19:37:12 UTC
I sent an email to Athos, the current Hugo maintainer, inquiring about whether I could help maintain the Hugo package.

Comment 22 Athos Ribeiro 2020-04-12 22:12:47 UTC
Hi Mike!

I replied to your email and reviewed your PR.

About Hugo, qulogic has been doing all the work there recently.

Are you in the go SIG? if you join it, you can help maintaining not only Hugo but the dependencies as well.

Thanks for fixing this one, Elliott


Note You need to log in before you can comment on or make changes to this bug.