Bug 1675237

Summary: kronosnet: FTBFS in Fedora rawhide/f30
Product: [Fedora] Fedora Reporter: Fedora Release Engineering <releng>
Component: kronosnetAssignee: digimer <digimer>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: digimer, jpokorny, philwyett
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-11 17:04:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1674516    
Attachments:
Description Flags
build.log
none
root.log
none
state.log none

Description Fedora Release Engineering 2019-02-11 20:38:37 UTC
kronosnet failed to build from source in Fedora rawhide/f30

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


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
Please fix kronosnet 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,
kronosnet will be orphaned. Before branching of Fedora 31,
kronosnet 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 2019-02-11 20:38:39 UTC
Created attachment 1530822 [details]
build.log

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

Comment 2 Fedora Release Engineering 2019-02-11 20:38:41 UTC
Created attachment 1530823 [details]
root.log

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

Comment 3 Fedora Release Engineering 2019-02-11 20:38:42 UTC
Created attachment 1530824 [details]
state.log

Comment 4 Jan Pokorný [poki] 2019-02-11 21:56:54 UTC
FYI, this will get fixed once rebased to 1.7:
https://github.com/kronosnet/kronosnet/releases/tag/v1.7
(a bug to update the packaged version would be auto-created if enabled
somewhere in package settings and/or tracked w/ release-monitoring.org)
since it contains:
https://github.com/kronosnet/kronosnet/commit/97924ac12d8da26b61d3bc3ab90fbd86b0b58e72

If there's an urgency to make the package buildable again, this PR
(chronologically preceding the v1.7 release) can be pulled in:
https://src.fedoraproject.org/rpms/kronosnet/pull-request/1

Comment 5 Phil Wyett 2019-04-11 17:04:44 UTC
Fixed with 1.7 and now 1.8.

Package quality is not good.

Comment 6 Jan Pokorný [poki] 2019-04-11 21:53:04 UTC
re [comment 5]:

Thanks for the effort.

> Package quality is not good.

Yep, it wasn't when I volunteered to review the package, sadly, there
were some political forces behind that, it seemed, so not sure that
everything was in order.

Seeing your recent PRs like:
https://src.fedoraproject.org/rpms/kronosnet/pull-request/9
makes me wonder, did ldconfig invocations, something I expressly
pointed out in the review [bug 1507103 comment 79] actually recidivate?
Interesting.  Or maybe not.

Comment 7 Phil Wyett 2019-04-12 01:07:19 UTC
(In reply to Jan Pokorný [poki] from comment #6)
> re [comment 5]:
> 
> Thanks for the effort.
> 
> > Package quality is not good.
> 
> Yep, it wasn't when I volunteered to review the package, sadly, there
> were some political forces behind that, it seemed, so not sure that
> everything was in order.
> 
> Seeing your recent PRs like:
> https://src.fedoraproject.org/rpms/kronosnet/pull-request/9
> makes me wonder, did ldconfig invocations, something I expressly
> pointed out in the review [bug 1507103 comment 79] actually recidivate?
> Interesting.  Or maybe not.

The ldconfig stuff has been in this spec since I came across it while testing f29 -> f30 upgrade and f29 was 1.7 and rawhide was 1.5. I did PRs at that time, but these were missed apparently. I am now doing baby step bug reports and PRs. Hopefully we can get these in and the packaging of kronosnet up to par, and educate the maintainer in the process.