<div dir="ltr"><div>I'm excited to see real efforts for a wholly free ARM distro going 
on, something higher than Debian I mean.
 There are far more ARM CPUs than x86 ones nowadays, and while not all 
of them will be able to work with free software a substantial proportion
 will. Those ought to be covered. This is an increasingly important 
computing platform dominated by GNU+Linux, Android/Linux and other 
free-software-based operating systems; therefore the success of ARM 
indirectly is the success of free software for the masses too.<br><br>Ok, so here I will be trying to address some issues that I think went overlooked before the thread forked:<br><br>>We need some research before packaging anything:<br>
><br>>- how <a href="http://archlinuxarm.org" target="_blank">archlinuxarm.org</a> works (e.g. crossbuilding) and what we should use<br>>  from them?<br></div><br>Maybe everything that is already libre or can be repackaged to meet the standards, as you do with normal Arch I guess. The big problem with ArchARM is the myriad of kernels they support. See <a href="https://bbs.archlinux.org/viewtopic.php?pid=1227684#p1227684" target="_blank">https://bbs.archlinux.org/viewtopic.php?pid=1227684#p1227684</a> for a light discussion on merging Arch with ArchARM, developers from both camps joined and discussed kernel proliferation. I just counted 48 from ArchARM's [core] repo but we may not need to support them all. The details can be found on my attatchment and I hope this introductory research will help Parabola decide what kernels to use (deblobbed) from ArchARM if any. I could add this info somewhere in the wiki during the following days if you like it. It would be nice to do the same for u-boot.<br><div><br><br>>- what devices we want to support: popular here, sufficiently free and<br>>  also something fast for building packages (some certainly don't<br>>  support cross-compiling and native builds are a good way of finding<br>>  bugs); will we compile packages for ARMv7 only?<br>
><br>>- what kernels will we use?  can we avoid deblobbing and releasing a<br>>  different kernel tree for each board?<br>><br>>- u-boot trees; there are existing deblobbing projects for specific<br>>  boards<br>><br>>- what's missing in the development tools that we used for mips64el?<br><h3><font><span style="font-weight:normal"><span name="Michał Masłowski"><font>Michał Masłowski clearly knows what he says. This is the way to go</font><br></span></span></font></h3></div><div class="gmail_extra">>We should aim for compiling all packages<br><br></div><div class="gmail_extra">Even packages that don't need repackaging? Is this what you do with x86 Arch?<br><br>>Do you know any fast multicore boards with much RAM and a SATA port that<br>
>would work for native builds?  I think i.MX6 Quad and Tegra K1 are the<br>>fastest SoCs that work without known to me bootloader blobs (Samsung<br>>Exynos is not ok).<br><br></div><div class="gmail_extra">All in all Novena board is a good candidate: iMX6 Quadcore, 4 GiB in RAM, works without nonfree software, in fact there's just a couple trivial blobs keeping it from being FSF-endorseable at the time, no treacherous computing of course and unlike many board developers the Novena people is working hard to collaborate upstream and keep their software updated. Linaro was interested in getting some Novenas and use them to build software natively.<br></div></div>