Join Log in
Score:7
Yogesh Devi avatar Ubuntu

Creating a deb package for both ARM and AMD64 returns error: "Skipping acquire of configured file"

ph flag
Yogesh Devi

We have a product that we want to install on both AMD64/x86 based Ubuntu servers and ARM-based Ubuntu servers. We package our product as deb packages. So I need to create a deb package that can be installed on both AMD64 and ARM64. I did refer to https://wiki.ubuntu.com/MultiarchSpec.

I started with using the Architecture wildcard in my package (all" ...) control file ( I also tried any):

Package: my-package 
Version: X.Y.Z
Architecture: all
...

I thus created a deb package and tried to install it on the target server.

However, I realized that my packages are NOT identified by the the apt package manager. I suppose this was because the wildcard that the deb package used was NOT in the "foreign architectures" list of dpkg. So I tried adding architecture wildcards using the following dpkg command:

# add foreign architectures 
dpkg --add-architecture all

This however gives me an error ( see another specific question posted for the dpkg --add-architecture error) - but basically I abandoned that

Just out of desperation I added "ALL", that I could successfully add . However this ( as expected ) gives me an error since the wild card "ALL" is invalid and does not amount to "all" The error I got is as follows

 # apt update 
 ...
 N: Skipping acquire of configured file 
'restricted/binary-ALL/Packages' as repository 
'http://ports.ubuntu.com/ubuntu-ports focal- 
 updates InRelease' doesn't support architecture 
'ALL'
N: Skipping acquire of configured file 
'restricted/binary-linux-any/Packages' as 
repository 'http://ports.ubuntu.com/ubuntu-ports 
focal-updates InRelease' doesn't support 
architecture 'linux-any'

So I am now not sure how to go about creating packages targeted for multiple architectures and how to install those on a Ubuntu server running on both AMD64 and ARM64 processor family

Any suggestions are welcome.

999
1 + 2
apt
sudodus avatar
jp flag
sudodus
Software that consists of shellscripts and other interpreting program tools are often working in different architectures while compiled code often are specific for the architecture. - What about your software, @YogeshDevi?
2
Reply
Yogesh Devi avatar
ph flag
Yogesh Devi
The code is mostly interpreted - Java and Python
1
Reply
Score:7
MAFoElffen avatar Ubuntu
in flag
MAFoElffen

I have a package in my PPA (ppa:mafoelffen/system-info) that is Multi-Arch. sudodus is one of my contributors. He asked me to come here and answer what I do for this.

The people involved with the testing of my script in this package made sure it tested well on amd64, arm64, armhf, ppc64el, powerpc, riscv64, s390x.

This is what I did (reference: https://www.debian.org/doc/debian-policy/ch-controlfields.html#architecture):

dpkg-architecture -L

For the Debian package, in the ./PackageName-VersionNumber/debian folder/control file, I have this:

Architecture: all

That is all it needs in the control file. Building it locally, will create a ProjectName-VersionNumber_all.deb file. I test this package locally before uploading the source package to the PPA.

In the PPA "Change Details" page, for "processors" I have all arches selected that it would let me do as self-service. (All except riskv64. Long story.)

When it first gets uploaded to the PPA, in the PPA "View Package Details" page it will initially show the status as the arch it was built on. For me this was "amd64". When published, that status changes to a green check mark. If I look at the package details, it has system-info_02.00.07_all.deb, which I then tested, from there, on all my target arches. "riscv64" is another discussion, but since mine has no upstream code (I am "the upstream") as dependencies, it was built for that also.If it had, that would be another story with more details.

There is nothing at the PPA pages that shows anything else about arch/package details. I had to investigate elsewhere to find that...

Risc-V 64 was a question for me, since I wanted to include that arch target, and it wouldn't let me select that option on my own. I know this is not your target arch, but the details of what I found will answer that. I went to the PPA repo that is created by the build, and that the people using the PPA would get packages from: REPO. If you check there, after the build it creates the different arches, name as binary-<arch>. If you follow the branches of the directory tree down to the release file for each arch, it will tell you the arch it was built for. That is how I confirmed that it was built for each arch.

I then tested each arch by (from a machine with that arch) adding the PPA, installing and testing on each.

Note that if you are creating a local build of your Debian Packages (.deb), that Architecture line in the control file is what determines the ***_arch***.deb part of the package, indicating the target arch. For just two arches, like you noted, then do "amd64" in one control file, build the .deb package, then do "arm64", and build it again. That will create PackageName_VersionNumber_amd64.deb and PackageName_VersionNumber_arm64.deb packages. One for each arch.

I use this to build the source to upload to the PPA:

debuild -us -uc -i -I -S -sa

I use this to build the packages locally to create Debian the .deb packages to test:

debuild -us -uc
+ 1
Yogesh Devi avatar
ph flag
Yogesh Devi
Splendid response MAFoElffen ; much appreciate . A BIG THANKS - I will follow this and share my experience
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.