Arm development topics/issues


(Mark Verlinde) #1

Still working on the NS-arm 7.5.1804 and running in to some topics/issues I’d like to discus

EPEL arm-32bit
We talked about the status of the unofficial epel for arm-32bit before; but as stated getting the mirror of this nice and clean is time consuming and quite honest not a pleasant task to do.
My proposition is we work on a alpha release which researches directly in to the unofficial epel,
for the last RC we build up the mirror and if all is well we go to final. This would speed up development and getting test images out.

Simple wifi (WPA-Supliant) module.
Need help for a for a Simple wifi (WPA-Supliant) module. I can make some action scripts around wpa-cli to set a wifi connection up. However if we wat something in http-admin i miss the php skills. @denis.robel You did some work on hostapd, could this be a better route than wpa-cli?

Would pushing some arm specific patches “upstream” x64_86 be accepted?:

(small stuff)
Base Dashboard Hardware info
Most arm devices we are targeting now do not have a bios, they are device-tree based. hence /sys/devices/virtual/dmi/ is not present. A rather small patch from @dz00te would clean it up enough.

Just one if elif else and adding two configuration files would do the job.
Not important rather a small frustration of me: building on relatively slow hardware, I want to propose to keep the chroot between building he sRPM and the RPM. This would speed up a lot! Keep in mind the builddir is the chroot is cleaned-up by mock even if you opt for --no-clean, it just keeps the chroot…

(bigger stuff)
Disable local AD option for arm-32bit maybe 64-bit. Did not thought about how to do this, it would imply greying out a button is arch = arm.

Dropping smartmontools dependency for nethserver-base
(Again) Most arm devices we are targeting don’t have SMART-enabled diskdrives…
Dropping dependency for nethserver-base implies moving all smartmonitor parts from nethserver-base to nethserver-smartd. nethserver-smartd is a mysterious package, it just holds the default-db part of the service. Why? And could we shift parts (if there are any) from base to smartd?

grtz mark

@dz00te @denis.robel @m.traeumner @

(Giacomo Sanchietti) #2

No problem at all but the code should be platform dependent. I think we can simply find a condition for it.

I think we can merge it as is, would you mind to open a PR?

I think this could be conditional too. Am I right @davidep?

Maybe we can also try to create some Travis jobs ( ?

We can do it, then add back the package inside nethserver-iso yum group.

I think there is no real configuration apart for the record to enable the daemon.
Could you please point me to other smartd stuff inside nethserver-base?

(Mark Verlinde) #3

Thanx for the answers, you can expect some new “isues” on the bug tracker with PR’s the comming days

well I could not find any… Hopped you knew :grinning:
Did not look in to it much, now there is an principle of acceptance, I will look in to it in more detail.

Would be great, looked for a arm build node and did not find it… As I have little understanding of this travis-cli infrastructure didn’t put much time in it, also because i never looked in to docker…:roll_eyes: (just use nspawn if i need a container)

(Giacomo Sanchietti) #4

So, this confirms we can safely remove the dependency from nethserver-base :+1:

(Giacomo Sanchietti) #5

Mark, could you please open all PRs including the one to nethserver-base?
After that, I will create a recap issue where all PRs will be linked togheter

(Mark Verlinde) #6

PR’s are in the making, working on them i found this code scrip-let in FirstConfigWiz/RootPassword.php of nethserver-base:

 *  show this page only if the root user has still the default password:
 *  @return mixed The integer position, or NULL if this page must be hidden
public function getWizardPosition() {
    return $this->user->getCredential('hasDefaultPassword') === TRUE ? self::WIZARD_POSITION : NULL;

how can we get this to pop up on the first boot of a nethserver-arm image? i.e when is ‘hasDefaultPassword’ TRUE?

(Davide Principi) #7

When the user logs in the typed password is compared with the default one Nethesis,1234 and the result is recorded.

(Mark Verlinde) #8

:+1: Nethesis,1234 is going to be the new default-password!

(Mark Verlinde) #9

As discussed in this post i’d like to push some arm-specific patches to “upstream” x86_64.

It did not make sense to do this as-long it is in a “devel” state by now the basic modules proved to be stable and can be regarded being in a beta-state maybe even RC1.

Holding me back is the infrastructure: one patch, nethsever-mock, includes the repositories for arm.
I am very happy (having full rights/control) with the development repository provided by @mrmarkuz. :+1:

From another point of view it’s not so good: it would be better if the maintenance / development can be done / shared by a group of people. This implies more people have rights to manage the repositories.
Moreover it’s about time we start to (re)sign the packages.

How do we proceed?

To get the discussion going some options / ideas:

  • Push stable parts to repo provided by @dz00te
  • Provide stable repo on infrastructure provided by @mrmarkuz
  • Can nethsever / nethesis set-up an DNS record / forward requests?
    (It would not mater where the repo “moves” to in the future… )
  • Host repositories on infrastructure provided by nethsever/nethesis
  • Signing packages: which key ?

More ideas?

cc// @davidep @giacomo @alefattorini

(Davide Principi) #10

I’m personally favorable to add the arm architecture to repositories, which already provides authentication and automated RPM signing.

(Mark Verlinde) #11

Sounds good to me!
What do have in mind? An altarch branch like centos does?

for armhfp (32 bit) we have two out of the ordinary repositories:

  • a partial mirror of the unsigned “epel”.
    This mirror is kept update manually with a simple (= unforgiving) script.
  • a mirror of the community effort for SCL-PHP72.

How to deal with those two?