Nightly build (or at least a recent working version?)

[JesseOMember]

My version of Geexbox (from August) is starting to act wonky on my Cubox-i4pro, so I tried to download the latest nightly build to make a new SD card. My desktop is running OS X, so I need an .img file, which seem to not exist at the moment. Without Linux, is there any way I can compile the build into an img file, or is there a recent img file floating around somewhere that I could try? Thanks in advance…

[Warped RudiModerator]

Our build infrastructure is a bit flaky and we are not happy with that situation. There was a problem with the *.img.xz creation, which has been resolved a few days ago.

[JesseOMember]

Thanks. I just downloaded the build.

[PeterMember]

Its a more general question: im trying to find info about whats changed on the latest img build wich is downloadble
Ive seen lots of new builds(dates) the last few days uploaded. (keep up the good work! :), im glad that there are a lot of enthousiast people who spent a lot of time to keep Geexbox updated.)
The only thing is:I can’t find related info text in mercurial repositories or in the GitHub links,(latest is the geexbox updater), to read what is repaired or added to the build.

Do i look at the wrong pages?

(maybe its possible to ad a text file or pdf to that download page for essential info about difference from the previous build. like 3 nov and now 5 nov, a small change or a importand repair?

Its not a complain but more a request.

[tomlohaveModerator]

Please have a look here :
https://github.com/OpenBricks/openbricks
That is where all things come from.

To be honest, adding a list of what has changed is not in our todo list …

[PeterMember]

Thanks for the replay; I did have a look (and found your input; and im sure that its crystal clear and readable for developers but for just users (like me) its just looks like program languages and does not give away any clue like what is fixed or added.

So what i mean is a smal(sticky) thread or so in this forum where in very very short text is explained what the developers like you been working on to make Geexbox the best of all.
The only thing you or an other developer, need to do is ad a post to the sticky thread after a update or fix in the nightly build. (10 sec work i think.)

Something like this:

“Geexbox (nightly build) fix and options:(these are not based on real issues)

28 aug 2014: unable to wake up after days standby by IR-remote=> problem fixed.
14 sept2014: geexbox updater gifs script error => problem fixed (add link if usefull)
29 sept2014: [CuBox-i]DTS-HD MA and Dolby True HD => added to audio….
10 nov 2014: new skin added.[link to screenshot]
14 nov 2014:black screen and just audio after pauze or restart movie. => problem fixed
15 nov 2014: stable version 4.11
1 jan 2015: …..

so when i, or someone else, have a issue on the GeexBox, i look at my build-/flash img- or compiling date, read trough the list, starting from that build date till last post and i see my problem and its fixed posted, answere is clear: update! or flash new .img
When mine, or someone elses, problem issnt in the list: well its not detected yet or its (maybe) a option setting and not a bug.

again,Its only a suggestion, no push. (im shutting up now ;-P)

[tomlohaveModerator]

Could be an idea

Let’s see how we can do that.
Thanks

Rudi, your opinion on that ?

[Warped RudiModerator]

Hmm, while I understand Peter’s motivation I’m not so much a fan of it. Especially, since we don’t know in advance when a specific feature will be included. I.e. I make a local change, test it (ideally ;), commit it and done. It may show up in a downloadable snapshot the other day or the other week. Who knows? And I do not really feel like back-checking this. With the old Mercurial we had this upwards counting revision number so that we could say that a revision with a number greater than xyz will include a certain patch. However, with Git we have these hashes that can only be compared for equality. Or is there another way to attach a numerical comparable build number to the file? The date thing is IMHO not an option.

[tomlohaveModerator]

There is another way to compare : “git rev-list HEAD -count” returns the numbers of commits (like we can see on github)
I can , I think, add this to our buildbot.

We can even force buildbot to build only a specific revision, ie build only when we need it.

Now it depends too on what we want : release more often, or switch to “rolling release” with periodic snapshots. So the buildbot can help here to build this kind of automatic “release”

[togathMember]

I like the idea of having a dedicated changelog.

The bot should be able to add to each snapshot a file with the delta-list of things changed compared to the previous snaphot, like

snapshot 2014-11-11
> fixed bug startup....
+ added feature X
- .... 
snapshot 2014-11-10
> fixed bug DTS-Master ....
snapshot 2014-11-09
+ added feature Yabbadabaduuu

And if you do a release than (all|major) changes compared to the last (v3.1 in this caes) are listed.

[tomlohaveModerator]

The problem are :
– changes are sometimes only internal for the build process. (like the refactor process)
– some packages are upgraded but do not concern really the target (only for the host)
– merge commits
– …

so having an automatic log generated by the bot is, I think, a not so good idea.

[PeterMember]

@Warped Rudi: The date’s in mine example are just posting dates not specialy fixing dates, and im understand your hesitation. Not every patch or adding needs to be added every time.
A montly update list revering to a build version is also good.
As a user i will look into that list for reason to update incase of a error/bug (fix) or just to see of an update is usefull because of some added features or several patches so a normal running Geexbox is just updating to an other stable version and not to a version that give’s some problems because of hmm “not yet tested” changes.:) (now its more a gamble because of the lack of (understandable) info.
(We users are happy when we can hop from one good working version to an other.And ofcours we will help detect errors or help to improof.)

All other small changes or special added programming wich are not for general using arn’t need to post in the list/thread.

So if only the bigger changes or a cluster of error fix’s /feature adding are posted whit the buildversion filename. That is also already a big plus for us hombel users, and save’s a lot of posted questions about updating or not.

@Tomlohave: i think thats what you meen by “rolling release”
Maybe is every month (12 time a year) or three month’s (4 times a year) a post with a list of changes revering to a buildversion posible?

regards
Peter

[Author]

Posts