Fix /etc/os-release

[anaconda]

According to /etc/xbian_version we're on RC2, not 1.0 final.

According to the manual:

• PRETTY_NAME should include the release code name, if it exists;
• VERSION_ID is the machine-parsable version;
• VERSION is the human-parsable one and should include a code name, if it exists;
• BUG_REPORT_URL should point to the actual page a user is supposed to report a bug.

[CurlyMoo]

@anaconda, wouldn't you like to develop for XBian on a more regular basis. Maybe take over some package development that could relieve @mk01? We can give you direct access to the git repositories if you'd like and more permissions on the forum to also see hidden forums.

[anaconda]

Being unemployed I've plenty of time 😄. Not sure I could take over some packages, but I can certainly help. (On a side note, I'm already in contact with mk01 to see what I can do.)

[CurlyMoo]

Do you already have a forum account?

[anaconda]

Do you already have a forum account?
It’s menakite.

[CurlyMoo]

I've upgraded you to developers. Can you check if you see additional accounts?

[anaconda]

Aha, I see the secret forums with your plans for world domination! (Thank you.)

[CurlyMoo]

Just open a thread there and i can give you access to everything you need to help us with our plans to try to take over the world:

[mk01]

@anaconda

it is the other way around. os-release was already prepared for 1.0 and all was in-line with that (xbian_version file etc) but then from some reasons I decided for one more round (RC2) instead of (1.0).

but good eye. beside XBian's RC2 in name there were no changes to it's code / or workflows for some time (not considering minor bug fixes - what is rather continual process) and it should have been already frozen, tagged on git and bundled into .img as v1.0. if there is not anything special going at XBian's forum (as reason not to bundle v1.0 now), let's do it.

my capacity is currently going into the rebuilding of repos to include the building part - @anaconda just to follow our last discussion - I already have idea (and decided) how to do it. when finalised, current easy-to-use approach (clone repo, run gen package script) will stay, just enhanced with fetch source - patch - compile - move to ./content part.

so for us / user instead of "clone & gen.package.sh" package it changes to "clone & run make". something like for instance one can see with yocto or archlinux. unfortunately I'm still far even from thinking of universal multi arch folder structure, build config / Makefile structure or debcontrol files templates, but this is rather the "easier" part as there is lot of inspiration around, so at the end we can re-use, inspire, combine whatever later ... past week I was consolidating my 2TB of sources / patches / everything to have it cleaned and ready for automated operations.

also I was assessing options for a common buildplatrorm (buildroot). but finally i do not consider it at all appropriate for our use. it is too much "complicated" for newcomers, not very easy to keep overview of it's properties as a core system (libs / versions / functionalities etc). also even smallest change to core sources is triggering recompilation of everything from scratch - so it is amazing what is it doing - but comparing to modularity / easy of use / of available binary distros it is like feeding a dinosaur in 21st century. it is like very bad example how to make from free code / software - absolutely closed and hardly versatile system / bundle (my humble personal opinion).

instead I decided for debootstraped target binary distros (we build for). compilation is a bit slower as for instance I run armhfwheezy armhfjessie and armhfraspberry roots on x86_64 and qemu but beside that creating this buildplatforms from scratch took 30minutes, with 5 lines of commands and it's use is literally 1:1 the same as targets auto updated to always keep link destinations as they should be - in other words there is nothing different from native building. and the biggest benefit is really how close this is to newcomer. I already prepared kernels & xbmc for RPI/IMX6 (as stated above - link to sources, patches, build setups). on clean machine in 2h one can have binary kernel & xbmc packages for those two platforms - without any issues with building errors, reading docs or forums and spending hours/days.

@anaconda
do you have facetime or skype or anything similar?

[anaconda]

it is the other way around. os-release was already prepared for 1.0 and all was in-line with that (xbian_version file etc) but then from some reasons I decided for one more round (RC2) instead of (1.0).
Yeah, that’s what I supposed.
This leaves us with the other changes (“According to the manual”). Do you want me to update the pull requests for 1.0? A force-push will do it.

but good eye. beside XBian’s RC2 in name there were no changes to it's code / or workflows for some time (not considering minor bug fixes - what is rather continual process) and it should have been already frozen, tagged on git and bundled into .img as v1.0. if there is not anything special going at XBian's forum (as reason not to bundle v1.0 now), let's do it.
Is the Cubox-i “port” at the same level of functionality, known bugs, [insert here] as the Raspberry Pi?
I’d prefer if we could release 1.0 only when the 2 platforms are “synchronized” in regards to these things (except, of course, platform-specific bugs).
Also - not that this actually impacts a user in any way, but… - I’d like to have the Git repositories cleaned up (if needed; e.g. delete old dead/merged branches) and all the APT repositories (testing, devel) on GitHub (in its own branch), before 1.0. And we need the Cubox-i repos on GitHub.
The APT repository could need a reorganization, instead of marking the Cubox-i packages “-6q” we could just use different URIs:

(sources.list, just for comparison with current one)

Raspberry Pi repository: deb http://xbian.brantje.com/rpi stable main
Cubox-i repository: deb http://xbian.brantje.com/6q stable main

That could avoid the possibility of someone installing a Raspberry Pi package on the Cubox-i, or vice versa. (I call this “fixing user bugs”.)

(Also, hey, that should really be “apt.xbian.org” or “archive.xbian.org” - something .xbian.org. A HTTP redirect will ensure backward compatibility.)

my capacity is currently going into the rebuilding of repos to include the building part
That’s a supercool idea.
I already have idea (and decided) how to do it. when finalised, current easy-to-use approach (clone repo, run gen package script) will stay, just enhanced with fetch source - patch - compile - move to ./content part.
I was thinking something similar, but without a Makefile or anything like that, I’d prefer to split the build setps. Let’s say this tool is xbian-mkdeb:
$ xbian-mkdeb -h
Usage: xbian-mkdeb [-t branch] [—download-only] [—no-download]

E.g.:
$ xbian-mkdeb -t staging lirc
[…git clones for branch “staging”, corresponding to the “staging” APT repository…]
[…configures and compiles…]
[…builds a deb package…]
[…echo “Package lirc (version 1.2.3) built successfully for platform “Raspberry Pi” and saved to /home/xbian/mysupercoolpackages/xbian-package-lirc_1.2.3-1_armhf.deb”…]
$ sudo dpkg -i xbian-packages-lirc*.deb

$ xbian-mkdeb —download-only lirc
[…git clones…]
[…echo “sources saved in ~/xbian-package-lirc”…]

[User changes the sources manually, then applies a patch and changes the ./configure options for his needs]

$ xbian-mkdeb —no-download lirc
[…ok, just configuring and compiling…]
[…echo “package lirc… built… saved to…”…]

My idea is to have a directory “build” with a series of scripts (run-parts): 01-apply-patches, 02-configure, 03-compile, …
Wouldn’t it be simplier?

so for us / user instead of “clone & gen.package.sh” package it changes to “clone & run make". something like for instance one can see with yocto or archlinux.
I don’t know either of them, I’ll see tomorrow what Google have to say about ‘em.

do you have facetime or skype or anything similar?
Only IRC, sorry. I’m quite anti-social :-)

Edit: sorry, apparently there's no Markdown for email replies.

[mk01]

@anaconda

I see the cleaning as part of the structure expanding (functionality expanding). so definitely yes.

almost all repositories are actual, that's fine. what is causing most confusion is the old repo under /xbian (which contains files etc as a diff against a plain binary distro). all the content was divided -> reused in the respective packages (repositories) so currently it is really just like a safe copy. but a bit too long (1y). then there is one specific general repo (xbian-patches). it is updated to reflect state what I'm building (for both imx6 and rpi). in the process it should be removed as well as patches will become part of the specific repositories again.

and because the git repos will become primary source for binary generation, problem of keeping them up-to-date will no longer exists.

speaking about the scripts we deliver / use - I don't care about specific approach (make, bash, python whatsoever) but we see similar in the expected functionality there. get sources, build sources, rm / keep after build, move bin to bin build dir, build binary, deploy binary.
with some very basic rules - separation on level of code & setup so it stays easy to read and understand for anyone without need of howto.

last thing, /xbian will contain just main top level wrapper to be able to deploy the build environment (including predefined platforms and -dev packages needed to install extra with list of all xbian repos with ability do the initial setup fetch (and then call the specific builder scripts per repo) and maybe ability to call xbianclone tool to create .img - but not only from existing partition, but use debootstrap with installing mini variant of requested disto + xbian debs from repo.
(and of course needed instructions how all this can be used with the structure and workflow described)

maybe curly will add some points too.

[CurlyMoo]

maybe curly will add some points too.

Only thing i want to see is documentation, documentation and last but not least documentation. That's all.

That however doesn't mean i want you to write everything in detail, as long as the community and team members have something to write the documentation and changelogs for you.

[CurlyMoo]

FYI, with my pilight project, the figures are as follows:
main website: 22.601 visitors in 2014
forum: 26.527 visitors in 2014
wiki: 43.831 visitors in 2014

That's how important a good wiki is. It nearly get's twice as much visitors.

Last but not least, check the image download statistics once in a while:
http://sourceforge.net/projects/xbian/files/release/

XBian_1.0_RC_2_Raspberry_Pi.img.gz      2014-05-28  287.8 MB    3.331
XBian_2014.05.26_CuBox-i.img.gz         2014-05-27  374.7 MB    1.208
XBian_2014.03.15_CuBox-i.img.gz         2014-03-16  1.7 GB      67
XBian_1.0_Beta_2_Raspberry_Pi.img.gz    2013-12-13  335.8 MB    720

[anaconda]

Pull request updated to remove the version change (1.0->1.0RC2).

[anaconda]

@mk01 Are you ok with merging this? See my last comment, it doesn't change the version anymore.
Also, see my last e-mail about XBMC Helix as for why I wanted to fix /etc/os-release.