Making my own deb package resulsts in default InRelease' doesn't support architecture 'amd64'

Macley · October 17, 2024, 10:32am

Problem:
I’m trying to create my own deb package to upload to foreman, so we can install it everywhere and update it easily.
However when i upload my deb package into a repository and publish it, all the hosts report the following when doing apt update:
N: Skipping acquire of configured file ‘all/binary-amd64/Packages’ as repository ‘katello://foreman.domain.lan/pulp/deb/acme/Production/CV_UBUNTU_22-04/custom/Ubuntu_22-04/Today_I_Patched_Package default InRelease’ doesn’t support architecture ‘amd64’

I’ve changed within my control file the Architecture to amd64 but i don’t see this reflected in the repository debs:

For easier reference, i’ve build witin gitlab the following structure and use it exactly the same as this:

I only put it under a different named folder named pocket_mouse and i change the permissions of the postinst and preinst to 0555.

I’ve also tried setting it as Architecture amd64, but to noavail (i do recreate the repository each time)

I decided then to try some common premade packages. And i noticed the following:
http://archive.ubuntu.com/ubuntu/ubuntu/ubuntu/pool/main/v/vim/vim-common_7.4.052-1ubuntu3.1_amd64.deb ← does work

http://archive.ubuntu.com/ubuntu/ubuntu/ubuntu/pool/main/v/vim/vim-doc_9.0.1672-1ubuntu2_all.deb ← doesn’t work

Does foreman look at the filename itself instead of the architecture in the .deb file?

Does anyone have an example package setup that i could reuse in our CI/CD in gitlab to adjust it to our needs?

Expected outcome:

Custom created .deb file made for amd64 or all that’s able to be uploaded and downloaded from an ubuntu server.

Foreman and Proxy versions:
3.12.0

Foreman and Proxy plugin versions:
ansible-collection-theforeman-foreman-4.2.0-1.el9.noarch
candlepin-4.4.16-1.el9.noarch
candlepin-selinux-4.4.16-1.el9.noarch
dynflow-utils-1.6.3-1.el9.x86_64
foreman-3.12.0-1.el9.noarch
foreman-cli-3.12.0-1.el9.noarch
foreman-dynflow-sidekiq-3.12.0-1.el9.noarch
foreman-installer-3.12.0-1.el9.noarch
foreman-installer-katello-3.12.0-1.el9.noarch
foreman-obsolete-packages-1.10-1.el9.noarch
foreman-postgresql-3.12.0-1.el9.noarch
foreman-proxy-3.12.0-1.el9.noarch
foreman-redis-3.12.0-1.el9.noarch
foreman-release-3.12.0-1.el9.noarch
foreman-selinux-3.12.0-1.el9.noarch
foreman-service-3.12.0-1.el9.noarch
katello-4.14.0-1.el9.noarch
katello-ca-consumer-vcdsat01.virtualcenter.lan-1.0-7.noarch
katello-certs-tools-2.10.0-1.el9.noarch
katello-client-bootstrap-1.7.9-2.el9.noarch
katello-common-4.14.0-1.el9.noarch
katello-repos-4.14.0-1.el9.noarch
katello-selinux-5.0.2-1.el9.noarch
pulpcore-obsolete-packages-1.2.0-1.el9.noarch
pulpcore-selinux-2.0.1-1.el9.x86_64
python3.11-pulp-ansible-0.21.8-1.el9.noarch
python3.11-pulp-cli-0.27.2-1.el9.noarch
python3.11-pulp-container-2.20.3-1.el9.noarch
python3.11-pulp-deb-3.2.1-1.el9.noarch
python3.11-pulp-glue-0.27.2-1.el9.noarch
python3.11-pulp-python-3.11.3-1.el9.noarch
python3.11-pulp-rpm-3.26.1-1.el9.noarch
python3.11-pulpcore-3.49.21-1.el9.noarch
rubygem-dynflow-1.9.0-1.el9.noarch
rubygem-foreman-tasks-9.2.3-1.fm3_12.el9.noarch
rubygem-foreman_ansible-14.2.1-1.fm3_12.el9.noarch
rubygem-foreman_azure_rm-2.3.0-1.fm3_11.el9.noarch
rubygem-foreman_discovery-24.0.2-1.fm3_12.el9.noarch
rubygem-foreman_maintain-1.7.4-1.el9.noarch
rubygem-foreman_openscap-9.0.4-1.fm3_12.el9.noarch
rubygem-foreman_remote_execution-13.2.5-1.fm3_12.el9.noarch
rubygem-foreman_rh_cloud-10.0.1-1.fm3_12.el9.noarch
rubygem-hammer_cli-3.12.0-1.el9.noarch
rubygem-hammer_cli_foreman-3.12.0-1.el9.noarch
rubygem-hammer_cli_foreman_ansible-0.7.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_azure_rm-0.3.1-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_remote_execution-0.3.0-1.el9.noarch
rubygem-hammer_cli_foreman_tasks-0.0.21-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_virt_who_configure-0.1.0-1.fm3_10.el9.noarch
rubygem-hammer_cli_katello-1.14.3-1.el9.noarch
rubygem-katello-4.14.0-1.el9.noarch
rubygem-pulp_ansible_client-0.21.7-1.el9.noarch
rubygem-pulp_certguard_client-3.49.17-1.el9.noarch
rubygem-pulp_container_client-2.20.2-1.el9.noarch
rubygem-pulp_deb_client-3.2.1-1.el9.noarch
rubygem-pulp_file_client-3.49.17-1.el9.noarch
rubygem-pulp_ostree_client-2.3.2-1.el9.noarch
rubygem-pulp_python_client-3.11.2-1.el9.noarch
rubygem-pulp_rpm_client-3.26.1-1.el9.noarch
rubygem-pulpcore_client-3.49.17-1.el9.noarch
rubygem-puppetdb_foreman-6.0.2-1.fm3_10.el9.noarch
rubygem-smart_proxy_dynflow-0.9.3-1.fm3_12.el9.noarch
rubygem-smart_proxy_pulp-3.3.0-1.el9.noarch

Distribution and version:
RHEL 9.4

Other relevant data:

quba42 · October 17, 2024, 1:39pm

I am going to try to unpack this, since I see several distinct aspects to this issue:

The root cause

Your package uses architecture all. This means it will be referenced in the repository metadata of you published APT repo within the file found at dists/default/all/binary-all/Packages. Since your repo does not contain any packages that are explicitly amd64 and you did not sync an upstream repo that advertises itself as supporting amd64, Pulp has no way of knowing that this repository is intended for amd64 hosts. As a result the release file found in the published Pulp repository (at dists/default/Release) does not list amd64 in its Architectures: field.

Since your hosts are amd64 they will complain about repositories that do not do this, that is the message you are seeing.

Maybe it just works inspite of the message

Have you actually tried to install your package on one of your hosts with the repo configured?
In spite of the fact that your hosts say: N: Skipping acquire of configured file ‘all/binary-amd64/Packages’ (because this file does not exist in the repo), maybe they do still acquire all/binary-all/Packages which does exist and inludes the metadata for your package.

You tried to change your package to amd64 which did not change anything

I am not sure why this does not fix things. If you have a amd64 type package in the repo, then the metadata should list amd64 as a supported architecture and the message should go away. Maybe the hosts are still using outdated metadata try clearing any local APT caches. Otherwise this sounds like a bug.

Possible workarounds

First of all, see “Maybe it just works in spite of the message” above.

One way that should get rid of the message, is to also upload some amd64 architecture specific package to the repo that you verified as “working”. You mentioned http://archive.ubuntu.com/ubuntu/ubuntu/ubuntu/pool/main/v/vim/vim-common_7.4.052-1ubuntu3.1_amd64.deb did the trick. You now have a package you don’t need in your repo, but so long as it does not hurt…

Some other points

The filename should be irrelevant, but official Ubuntu packages with all in their file name, most likely also have all in their metadata, which is relevant.

Outlook

I think we have here an edge case that is either downright broken/buggy or at the very least could be improved.

Since we are transitioning the APT/deb repo support in Katello to use structured APT, we will most likely fix it for structured APT mode only.

Macley · October 17, 2024, 6:01pm

Hi! First of all i want to thank you again for your reply!

So regarding trying to upload a different package and trying to see if i can install my custom package. Sadly i tried it down below:

But i was only able to see the vim-common package, but the one i created (and even with specifying amd64) isn’t findable. I did do a subscription-manager refresh and apt update. But alas i couldn’t find the package and i checked the /var/lib/apt/lists and then the repo it offers and it only shows the vim-common one sadly.

I haven’t heard of structured APT before, but i tottaly understand and we’ll glady transition using the newer format!

I do feel like the way i create the package is different then what other package developers make. Because how is it possible that vim-common (and i also tried a package that never has been in foreman, but it’s previous versions also worked always) works, but mine doesn’t?

quba42 · October 18, 2024, 7:32am

That does sound like there is something different about your package.

Can you check if the package actually ended up in the underlying Pulp repository?

I am thinking that maybe pulp_deb considers something about the package invalid, and did not fully create it during upload.

Is it listed in the dists/default/all/binary-all/Packages file?

If not, then my previous thinking went in the wrong direction.

Is there anything in the system log when you upload the package to a repo?

Would it be possible for me to obtain an affected package to run a test of my own?

Macley · October 18, 2024, 8:36am

Is it listed in the dists/default/all/binary-all/Packages file?

Sadly not, i added mypackage and while it should see both, it only sees the vim-common one.
I just noticed the foreman page hides the part of the cat command where i cat both the release and packages file, but i can assure you that it’s not listed sadly.

Would it be possible for me to obtain an affected package to run a test of my own?

For sure! Here’s everything you need to make the same package i want to release into our environments!

Control file contents:

Package: Today-I-Patched-Package
Maintainer: Linux Comp.
Architecture: amd64
Description: Set the creation date of this package in /etc/facts.d/last_patch.fact to keep track when which system is packaged with which updated packages.

Steps to compile:

apt update && apt install -y curl --no-install-recommends
mkdir -p pocket_mouse/DEBIAN pocket_mouse/etc/ansible/facts.d/
echo "{\"date\":\" $(date +'%d-%m-%Y %Z')\"}" > pocket_mouse/etc/ansible/facts.d/last_patch.fact
colon=":"
echo "Version$colon $(date +%Y.%m.%d)-1" >> control
mv control pocket_mouse/DEBIAN/control
dpkg-deb --build pocket_mouse

You can also download the same .deb file here:
pocket_mouse.tar (2.5 KB)
but i understand if you rather want to compile it yourself!

As you can see the package only really puts a json file so we can query it with ansible

Macley · October 18, 2024, 9:24am

Well, so i just did a test where i upload my custom made deb through the web ui and that actually just works, which explains why i felt like i have seen this working somehow.

Not entirely sure if it’s related to this bug: Upload deb package through hammer results in empty/invalid packages in repo - #9 by Macley
but it seems uploading the same deb through the api gives a different result then uploading it through the UI.

Infact, uploading it through the UI actually fixes the:
N: Skipping acquire of configured file ‘all/binary-amd64/Packages’ as repository ‘katello://server.foreman.lan/pulp/deb/acme/Production/CV_UBUNTU_22-04/custom/Ubuntu_22-04/Today_I_Patched_Package default InRelease’ doesn’t support architecture ‘amd64’

May i ask if you also experience the same behavior on your side?

quba42 · October 18, 2024, 9:34am

If the UI path works, but Hammer/API does not, then it could definitely share the same underlying cause with the other issue you linked to.

Regarding that other issue, we have not yet started working on it, but it is on our internal board for our current release cycle with “must fix” priority, so we will work on it soon. I think your best bet is to wait for that fix.

Macley · October 18, 2024, 9:58am

I just want to say i really apprecate your responses on the problems i encounterd! <3

Tottaly understand that work hasn’t started on that issue, i’m actually suprised the bug i reported is considered a must fix even before we found out the upload also alters the way it can be fetched aswell. I will refer to this post aswell in the bug for reference.

Thank you again to you and the rest of the team, it really brings me a smile to use this project and interract with the community behind it
Have a great weekend!

Bernhard_Suttner · October 25, 2024, 7:27am

Would be very interesting, if the same happens if the deb package is uploaded in pulp directly. So, to understand if the issue is on pulp or on katello side.