-----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@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/175ddec2056ec6b5ef267...)
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