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 925072

Summary: bacula: Does not support aarch64 in f19 and rawhide
Product: [Fedora] Fedora Reporter: Dennis Gilmore <dennis>
Component: baculaAssignee: Simone Caronni <negativo17>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: andreas, fschwarz, gwync, lnykryn, negativo17, paul, phracek, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-04 17:45:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 922257    

Description Dennis Gilmore 2013-03-23 00:06:29 UTC
Support for the ARM 64 bit CPU architecture (aarch64) was introduced in 
autoconf 2.69.  bacula appears to use an earlier version of 
autoconf, preventing its being built.  This can be fixed in of three ways (In order of preference):

1. Work with upstream to migrate the package to autoconf 2.69.

2. Rerun autoconf or autoreconf in %prep or %build prior to running 
configure.

3. Apply the patch at http://ausil.fedorapeople.org/aarch64/bacula/bacula-aarch64.patch
which updates config.guess and config.sub to recognize aarch64.

Comment 1 Petr Hracek 2013-03-25 11:20:49 UTC
Hello Dennis,

thanks for reporting that bug but before correcting could you please describe me
how to simulate build on aarch64 architecture?

I will need to test at least whether build is OK.

Thank you
Petr

Comment 2 Simone Caronni 2013-03-25 13:23:17 UTC
Yeah, me too. I see there's an arm koji instance at

http://arm.koji.fedoraproject.org/koji/

I would like to know if I can also use that instance for building/testing packages.

Comment 3 Paul Howarth 2013-03-25 13:26:14 UTC
Not at the moment.

See: http://lists.fedoraproject.org/pipermail/devel/2013-March/180643.html

Comment 4 Petr Hracek 2013-03-25 15:18:50 UTC
I have tested attached patch on architectures like i386 and x86_64 and bacula is build able.

I have checked also whether we can run commands like:
AUTOMAME=%{_bindir}/true autoreconf -fi\
which can be usefull as second solution
but unfortunatelly all scripts (like configure.ac or configure.in) are placed in autoconf directory and configure script is stored in upper (root) directory.
Therefore second one solution is not acceptable I think.

Comment 5 Petr Hracek 2013-05-14 11:57:54 UTC
Hello Andreas,

you have assigned this MR.
I suggest to apply patch as mentioned in the attachment.

Structure of bacula source is pretty different from another opensource project.
Unfortunately autoreconf -fi is not working because of some files are stored in different directories.

Repackaging bacula source so that autoreconf will work is pretty hard I think.

I will apply that patch to Fedora and Simone or you will apply that patch in upstream.

Will it be ok for you?

Petr

Comment 6 Simone Caronni 2013-05-14 13:07:14 UTC
Andreas has disappeared from Fedora a couple of years ago; I'm reassigning the bug to myself.

I will try to make the patch upstream along with the others you have included in the package.

Thanks,
--Simone

Comment 7 Fedora Update System 2013-05-16 10:35:59 UTC
bacula-5.2.13-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/bacula-5.2.13-10.fc19

Comment 8 Fedora Update System 2013-05-28 02:18:23 UTC
bacula-5.2.13-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.