We have the prove of concept Nethserver can run on a Raspberry PI;
If you want to try it follow the instructions on the wiki page, (thanx @dz00te)
and have a look at this post.
As said before, being amazed how good NS behaves in this little experiment I like the idea to see this brought to the next level.
Some question’s (going to) immerge, which I will post separately.
First some paper work.
Probably violated every license agreement , trade mark or whatever. I reckoned as long i’ll do this within the community no harm is done.
How to fix this? (don’t know J@ck $h!t about these matters)
And how closely related, how are we going to call this thingy?
I began with nethserver-7arm , @dz00te called the repo nethpi. Although Nethpi does not* cover all aspects (it probably run’s on all armv7 devices with Centos 7) it is catchy. Personally i don’t care, as long everybody is happy.
*EDIT: typo, forgot ‘not’
How are we going to manage the packages from the EPEL repository?
reading this:
link from this
http://www.spinics.net/lists/centos-arm-devel/msg01147.html
and this
http://www.spinics.net/lists/centos-arm-devel/msg01160.html
It’s going to take a long time (if ever) there is an official arm-epel repo.
Already installed some packages from this dev-epel.
http://armv7.dev.centos.org/repodir/epel-pass-1/
Till now only munin-node needed a little patch, to adopt to specific PI-hardware (irq) requirements.
My proposition is to use this dev-epel and only rebuild if it’s really necessary.
yes i admit that i don’t have thought much about the name of the repository…but i agree with you, nethserver-7arm is probably more appropriated, and as an alpha rel of an alpha rel i think we have the time to change it 
let’s see what devs/community think about it…
Ok for nethserver-arm even if “Raspberry” keyword is more attractive for the audience 
I don’t see any license violated, what do you mean?
I don’t think so! 
I agree with @dz00te: nethserver-7arm
Until EPEL is no released, we must include all needed packages inside the main repository, maybe using a firectory named epel.
I agree, figured a side effect of this little exercise is testing the packages they build and contribute to solve a catch 22: it needs testing before it can be released. If nobody uses it , it does not get tested…
suggestion:
Gratefully making use of their hard work and contribute by testing the packages. We need to be able to ‘enable’ a epel repo and a file called epel.repo on our install’s anyway.
Oke 
As said not my territory
Hey, where can you look for issues on the centos web site?
(have been browsing it for half an hour, subscribed to mailing arm list and so on…)
We’ve got a known (for many arm boards) memory leak, IRQ balance.
I want to discus that…
having a go on the mail server; (@dz00te, did you do some work on this?)
spamassassin is currently missing.
build it: build log states some functionality is missing:
NOTE: the optional fetch binary is not installed.
Sa-update will use curl, wget or fetch to download updates.
Because perl module LWP does not support IPv6, sa-update as of
3.4.0 will use these standard programs to download rule updates
leaving LWP as a fallback if none of the programs are found.
*IMPORTANT NOTE*: You only need one of these programs.
dependency check complete...
optional module missing: Digest::SHA1
optional module missing: DB_File
optional module missing: Mail::SPF
optional module missing: Geo::IP
optional module missing: Razor2
optional module missing: IO::Socket::IP
optional module missing: IO::Socket::INET6
optional module missing: IO::Socket::SSL
optional module missing: Mail::DKIM
optional module missing: DBI
optional module missing: LWP::UserAgent
optional module missing: Encode::Detect
optional module missing: Net::Patricia
optional binary missing or nonfunctional: fetch
warning: some functionality may not be available,
please read the above report before continuing
does someone know if we need one or more of the missing modules in NS7?
If spamassassin build I think we’re all set.
We can check optional deps later, after installing it.
Oke,
Fighting through dovecot-devel, could you put your RPMs in the repo?
thnx
no I’m sorry, I did not have much time … 
I just installed the new rpi3
if you can, test them with
yum --enablerepo="*" clean all
yum --enablerepo=nethserver-testing update
if they are ok i can move them to updates…
tested nethserver-base…80. , the install scripts needs a smal change:
Confict with NetworkManager is solved, it can’t be removed now without errors (dhclient). nethserver-ntp needs to be updated (crony)
changed tactics: copy packages from dev-epel including alledy (re)build packeges. Everything still runs fine.
Collectd works too…
Struggling with dovecot-devel, no problem building the libraries. The old fashioned way “make”: Still have to get in the rpm packaging
@dz00te, this is NOT for publishing!
just to let you know where i’am working on…
https://drive.google.com/file/d/0B4zCoP0frJBBUlczWm81TzlnazQ/view?usp=sharing
seems there is only one dependency missing for the mail-server:
Error: Package: amavisd-new-2.10.1-5.el7.noarch (epel)
Requires: perl(Razor2::Client::Version)
Probably this:
Any ideas/leads to solve this?
can you try with this?
http://armv7.dev.centos.org/repodir/epel-pass-1/perl-Razor-Agent/2.85-15.el7/armv7hl/
thx!
Transaction Summary
=====================================================================================================================
Install 2 Packages (+116 Dependent packages)
Total download size: 21 M
Installed size: 159 M
Is this ok [y/d/N]:
Still needs a little bit of debugging (and a lot of testing 
)
Nevertheless so far so good:
@dz00te, just cleaned up my local repository, and build ns’s missing depend’s in mock. Going to test it one more time to tomorrow evening. if all turns out oke, we got a mail server and some graphs.
Thinking to include phone-home to0, or not??
I think it will “report” being a 7.2.1511 …
