Arm development topics/issues

Discourse is some kind of mailing list replacement with steroids :smiley:
If you need infos just search using the icon above.

I don’t know because I’m an ARM noob and I still didn’t dive into ARM builds for NethServer! But please help me to validate some ideas.

My goal is to run the same development/release workflow of x86_64. Is that a dream?

What drives me is that arch-dependant packages are rarely updated; our daily job is developing nethserver-* config packages that are loosely bound to the underlying architecture :slight_smile:

So, if our noarch packages are really noarch (that means they don’t depend on other arch-dependant packages), each time they are uploaded by Travis-CI.org to Index of /nethserver/7.5.1804/updates/x86_64/Packages they can be automatically copied/hardlinked to http://packages.nethserver.org/nethserver/7.5.1804/updates/armhfp/Packages/. Our mighty nethbot will take care of them!

Additional repositories, like EPEL, which does not provide armhfp can be managed in a different way. How much disk space does your mini-EPEL “mirror” require?

I hope we can still host them under packages.nethserver.org/something and synchronized to mirrors as well.

Do not see big issues why this can’t be accomplished. Although not al packages are ported to arm (jet). because of a kmod : freepbx and ndpi. nethsever-dc proved to work in the past although it required some tinkering to get it up and running due to installation/configuration timeouts and decided it is not feasible to provide it. Other packages considered not to be feasible : nethserver-ejaberd, nethserver-iaxmodem

It will require more (manual) labor to (re)build dependencies/packages hosted by nethserver repositories for arm (think of duc or coova-chilli-dedalo). Maybe these packages can be build on travis cli using qemu-arm in the future. I do not mind to do this manually.

As it stands now we have 4 “noarch” packages which differ from x86_64: nethserver-nextcloud, nethserver-release, nethserver-mock and nethserver-base. Changes in mock and base may be merged; not so sure about nethserver-release and because we have PHP72-SCL it’s hard/impossible to merge nextcloud.

The configuration of at least 2 packages (openVPN and Web proxy) refer to /usr/lib64. We made a simlink from /usr/lib64 to /usr/lib to avoid the need to change those packages for armhfp (=arm 32bit).
An equivalent in perl for the rpm macro %{_libdir} would be more elegant, on the other hand the simlink does the job.

As said, not all packages are ported. if it is possible select packages to be linked this can be feasible.
Experience so far packages only broke if additional / other dependencies (recently this was perl-Proc-ProcessTable for nethserver-backup) where/are introduced. So we need to be aware of this.

As it stands about 880 MB for epel and 100 Mb for PHP72-SCL. Note only the newest/latest packages are mirror right now. We might consider to keep one extra to be able to down-grade if a update causes problems.

My proposal is to follow upstream centos scheme: mirror/altarch ie packages.nethserver.org/altarch/base/armhfp and packages.nethserver.org/altarch/base/aarch64 and so on.

2 Likes

We could define a whitelist: if the uploaded noarch package is whitelisted it is automatically copied to armhfp repo. What do you think?

I forgot to mention that when an RPM is uploaded to packages.nethserver.org an automated procedure validates it by running repoclosure: if we are missing some dependency the RPM is not published.

1 Like

Great Idea, as said i think we can be brave and push al whitelisted updates to arm automatically. Especially if the dependency check / repoclosure is in place.

1 Like

A projectcard about minor adjustments / patches for arm integration is ready to be converted into an issue.

Without objections this will be done as soon as my git repositories are rebased to the latest nethserver- origins. After which PR’s are going to be submitted for evaluation.

EDIT: added card for SOGo specs to in NethForge

2 Likes

To me it looks like it is possible to make the code of nethserver-dc arch indifferent;

@davidep could you have a look at the 2 commits in my arm branch?

Is this acceptable?

4 Likes

Sounds reasonable! We’ll wait your PRs!

2 Likes

this solution should be applied to restic too https://github.com/NethServer/restic/blob/master/restic.spec

cc @giacomo @davidep

for restic it could be like this

%ifarch %{arm}
%define architecture arm
%else
%define architecture amd64
%endif
Source0: https://github.com/restic/restic/releases/download/v%{version}/restic_%{version}_linux_%{architecture}.bz2

what good macro name we could use (everywhere) instead or architecture

1 Like

I guess Fedora guys already addressed this issue!

1 Like

IMHO they made a mess of the naming :

$ rpm --eval "%{arm}"
armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7hnl

and yum:

$ python -c 'import yum, pprint; yb = yum.YumBase(); pprint.pprint(yb.conf.yumvar, width=1)'
Loaded plugins: fastestmirror
{'arch': 'armv7hl',
 'basearch': 'armhfp',
 'contentdir': 'altarch',
 'infra': 'a7-bp',
 'kvariant': 'generic',
 'releasever': '7',
 'uuid': 'e154cf6b-b5b0-4ac0-ad4b-3745e88d0544'}

arm and amd64 are Debian architecture names (wisely used in golang too).

Let’s see if Mark can find a good general macro, otherwise we will need to code something specific for each package.

All core packages have been released: Integration of arm specific requirements · Issue #5610 · NethServer/dev · GitHub

2 Likes

Let me dig a little bit further, IMHO most imported is to try to make the code arch indifferent. In I often see distarch or capillized DISTARCH as variable (?) for the distro specific architecture designator (ie adm64 / x86_64) in cross dirsto build systems.
And i agree with @stephdl to encourage some uniformity.

thanx :+1: will upgrade the arm devel repo tonight.

1 Like

I added your code to my PR here

I’m looking forward for ns-samba ARM binary packages. I can upload them to https://github.com/NethServer/ns-samba/releases/edit/4.9.13 and make nethserver-dc manual builds work for ARM too :wink:

1 Like

they are building,

Be patient it takes a while in arm :joy:

3 Likes

For arm-assets See:

took on both machines approx. 1 hour and 10 minutes…

2 Likes

Referring to https://github.com/NethServer/nethserver-dc/pull/103#discussion_r327085779

I’d like to pull ns-samba from a dedicated repo in the future during nsdc install/upgrade. Maybe for 7.8…

1 Like

Like that idea and if we think of it when 7.8 arrives :
Let it conflict with the kernel to be pretty sure it only installs in a container ? :thinking:

2 Likes