[mk01]

@samu

almost whole BetaX line (until recently) was developed in VM (RPI target). the only "problem" was that XBMC doesn't run there so you are limited to system development only. second problem is that even with the same kernel you can't debug/develop are bug/issues as the VM kernel needs to be recompiled for another target (similar to RPI but not the same - so your test environment is not 100% the one you should be debugging).

thanks to RPI & iMX6 being both armhf with vfp fpu 95% of code base (even binaries if tuning down to CortexA9 & NEON & VFPv3-D16 is not needed) is the same meaning that it is not really important to test&develop cubox staff only on CB and RPI/RPI.

all the code base (but not kernel & not xbmc - for those there are only XBian specific patches on git) is on git, each XBian package having own repository (99% rule all start with "xbian-package-").

if you want to jump onto development feel free to start looking at least on specific packages (their general function), some latest commits (what's going around) and on github reported issues. those are by users all reported under XBian's main repo called "xbian" (https://github.com/xbianonpi/xbian).

in past 1Y my focus was on development mostly and having a system for "unified" deb creation. so each repo (xbian package) has needed .deb structure and .sh script which will directly generate the specific package. unfortunately the process of deb generation is manual and currently on my good will only. so even though there are others historically maintaining their packages (or even others committing to code), until I find the time, pull all new commits / generate debs and copy to APT repo, all is on hold . but this is mostly only question of writing a "small" script as that part is having a "standard template", structure and data hosted on the github.

but what I see as really needed now would be to split "xbian-patches" content to their respective repositories and include the build script/configfile/short howto to allow full automated (or by any 3rd party user) compilation (in case of binary packages - which are only few, but still are - xbmc, kernel, cec, few others). currently this is somehow historically done by members - knowhow mostly not shared etc etc etc. I don't have any kind of BIG expectations for start, but definitely I wan't to start somewhere and to be honest have no much experience there (in any kind of "standardized" build and/or source management systems).

so currently we have final files / binaries / scripts, this is structured & unified, packaging process easily to automate & even post to APT repositories. but then you ask ok, but where are this "half-way-done" & bin files taken from (and how).

there are some original documents & scripts from times of XBian Alpha versions as the last really engaged person with this part of building XBian was CurlyMo.

but again, we welcome any other poor soul putting personal time into public project (any part of it), this one I was speaking about is something I feel more and more as badly ignored and at the end not only it will help to project directly, but it also will open it significantly more to others.

another issue was lack of easy user documentation & even starters guide. a bit pitty because despite really hi-level of knowhow in the team, until you have an easy, human independent, anytime accessible way how to share it to the users, you have nothing (and users no benefit). but for this we have found a guy who from the perspective of frustrated user decided to take the opportunity to make a first step behind the magic frontier )

---

@IriDium

can you please move mine and samu's post to any more convenient forum ? THANKS