Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
aports
aports
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 677
    • Issues 677
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 156
    • Merge Requests 156
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • alpine
  • aportsaports
  • Issues
  • #12039

Closed
Open
Opened Oct 22, 2020 by Duncan Bellamy@a16bitsysopContributor

abuild saving APK files to X86_64 directory not X86

I have a docker build with buildx and Qemu that builds an APK from source using abuild on alpine 3.12 on GitHub actions using the docker Qemu and buildx actions.

If it is called from docker buildx build --platform Linux/386, the APK files are stored in X86_64 folder.

If it is called with docker buildx build --platform Linux/arm64 , the APK files are stored in aarch64 folder.

I opened an issue on the Qemu action and they said 386 is not emulated but it is a 32bit environment.

uname -mp on the 386 build gives x86_64 unknown

arch on the 386 build gives x86_64

Is Qemu wrong, or is something missing to get abuild to recognise the 32bit environment?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: alpine/aports#12039