[Arm-dev] enough packages for a @core install ?

[Fabian Arrotin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/15 11:36, Gordan Bobic wrote:
> On 2015-06-03 07:55, Fabian Arrotin wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 02/06/15 11:07, Gordan Bobic wrote:
>>> On 2015-06-02 02:23, cc35359 at gmail.com wrote:
>>>> I just read about the Google summer of code project in
>>>> regards to repacking/customizing arm 32 images, how does that
>>>> effect what we are looking to accomplish? I don't mind
>>>> assisting in the rootfs build (the right way), but I've never
>>>> tried it in my 20 years of nix :-). I'm wondering if I use my
>>>> pi image, chroot into a new pqrtition and do the installs in
>>>> that? That sounds easy, but not sure if it is that easy.
>>> 
>>> On the subject of images, it also occurs to me that it would
>>> make sense to standardise the image contents between CentOS
>>> and RedSleeve to keep them at least similar if not 100%
>>> identical.
>>> 
>>> Gordan
>> 
>> That's a good idea, so we can discuss that. My idea was to have
>> "minimal" reflecting what we have for x86_64 (and i686 now in
>> beta !)
> 
> Good to hear you guys got there with the i686 build in the end.
> I'd been using the Scientific Linux i686 port as a base to build my
> own, but the main reason I've needed it for is WINE builds and the
> odd Steam and Optimus/Bumblebee dependency, so once I had a
> complete mock chroot build set for those I didn't bother with
> completing the package build.

I've myself built wine i686 for CentOS 7 (for family members) in July
last year, just pointing mock to the public repositories (having
i{3,6}86 packages) on http://buildlogs.centos.org :-)

> 
>> for CentOS 7, so reusing the comps.xml and installing @core. I've
>> quickly done a test yesterday , and built an initial test image
>> through appliance-creator (thanks Howard for the pointer !) but
>> without "cleaning up" the comps.xml so it installed some firwmare
>> (noarch) files that aren't needed at all on the arm platform.
> 
> Do you have a link handy to a copy of the CentOS 7 (and CentOS 6
> for that matter) comps.xml file?

Well, not sure to understand the question, as the comps is in the
distro itself, and so directly in the mirror tree (like
http://mirror.centos.org/centos-7/7/os/x86_64/repodata/175ddec2056ec6b5ef267cea35f8ec679314afbfb019957e53f71725bcc5d829-c7-x86_64-comps.xml)

But we also have that in a git repo, including some of the tools used
to merge/produce those and sanitize the xml output
(https://git.centos.org/summary/?r=sig-core/comps.git)

> 
>> It needed 706Mb on / (normal for @core), but we can reduce that.
> 
> I am not even sure it is worth wasting too much time trying to
> skim that down a bit. I find that having a few extra things is
> really quite handy, and helps greatly to get up and running
> quickly.
> 
<snip>
> 
> I'm not sure what your plans are for CentOS, but given the sheer
> volume of various hardware, I don't think it is reasonable for the
> core project to try to cover everything. My experience with
> RedSleeve is that most people are using R-Pi (1 and 2), Odroid,
> Cubies and CuBox-es - which interestingly means next to no overlap
> with my own hardware so I can't support it. I mostly use Kirkwood
> devices (*Plug, QNAP NAS), Tegra2 (Toshiba AC100) and Chromebook
> (Exynos) machines, I was donated a CuBox to get an image built for
> it, and other than that I have a few relatively obscure machines
> that I have on the shelf that I have not yet had a chance to even
> look at getting up and running yet, and since I got them the
> manufacturers of some of them appear to have gone out of business.
> :(

Yeah .. the beauty of "Secondary Arch" is that there is no real plan
nor "things written in stone", so we can discuss and implement slowly
what we want :-)

> 
> The point I'm getting to is that some engagement from the
> community is likely to be necessary for such things, purely because
> to support the hardware you have to have the hardware, and without
> a substantial toy and manpower budget it will almost certainly have
> to fall to the community members to figure out and support anything
> but the most widely used hardware.

Yes, so community interested into having it working would need to work
on it and we can centralize all the needed steps for automated builds
for those images.

> 
> This is also made more difficult by the fact that even when the
> sources are available, the kernels in use are massively heavily
> patched, and pretty ancient. Ignoring the issue of bugs and
> security with such ancient kernels, it is still a case of having to
> have a separate specific kernel build for many devices, some of
> which require various additional bodges to make them work. For
> example, on the Exynos Chromebook, the kernel firmware loader isn't
> quite up to the task of loading the firmwares itself, which means
> much of the hardware won't work with the 3.4 kernel built from 
> sources in the usual way. The only workaround that makes it work
> with systemd is to glue the firmware blobs into the kernel itself.
> Getting to a fully working system took me most of the last weekend,
> and from experience much ARM hardware is like that. And that is a
> LOT of man-days to spend on an unfunded project to support a wide
> range of hardware.
> 
> Gordan

Indeed, the kernel part will be the most obscure / more difficult part
to do.
Probably good to at least centralize the doc around various boards,
and start from that experience.
As you said, I was expecting more people to be interested in
raspi2/odroid/bananapi/cubie


- -- 

Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlVu7LQACgkQnVkHo1a+xU43IACfUOoJYGgZ+IOPs4TnPjrkPr9K
1fAAn2A1Z8oG+ZeDz4/Y/0CXMlUBKAcC
=qNPr
-----END PGP SIGNATURE-----