Arm development topics/issues


(Alessio Fattorini) #21

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

(Davide Principi) #22

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 to they can be automatically copied/hardlinked to 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 and synchronized to mirrors as well.

(Mark Verlinde) #23

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 and and so on.

(Davide Principi) #24

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 an automated procedure validates it by running repoclosure: if we are missing some dependency the RPM is not published.

(Mark Verlinde) #25

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.

(Mark Verlinde) #26

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

(Mark Verlinde) #27

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?

(Davide Principi) #28

Sounds reasonable! We’ll wait your PRs!

(Stéphane de Labrusse) #29

this solution should be applied to restic too

(Stéphane de Labrusse) #30

cc @giacomo @davidep

for restic it could be like this

%ifarch %{arm}
%define architecture arm
%define architecture amd64

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

(Davide Principi) #31

I guess Fedora guys already addressed this issue!

(Mark Verlinde) #32

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).

(Giacomo Sanchietti) #33

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

(Giacomo Sanchietti) #34

All core packages have been released:

(Mark Verlinde) #35

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.