BootInfoScript 0.61 + Step-to-step guide

[Adys]

My apologies for interrupting. I think this info might be relevant, not only for this specific topic, but for Salix and users in general.

There is a new version of boot_info_script (BIS); v0.61 was just released.

Code: Select all

http://sourceforge.net/projects/bootinfoscript

Code: Select all

http://bootinfoscript.sourceforge.net/

changelog:

Code: Select all

http://bootinfoscript.git.sourceforge.net/git/gitweb.cgi?p=bootinfoscript/bootinfoscript;a=log

( @Salix mods and devs, please review the following codes, as it may need some corrections to work correctly under Salix. Please post any necessary corrections so we, users, learn for future reference. TIA)

Get latest development version of Boot Info Script from git, make it executable and execute it:

Code: Select all


wget -O bootinfoscript 'http://bootinfoscript.git.sourceforge.net/git/gitweb.cgi?p=bootinfoscript/bootinfoscript;a=blob_plain;f=bootinfoscript;hb=HEAD'

chmod a+x bootinfoscript

bootinfoscript



Or, alternatively, the user 'should' be able to download the latest development version of BIS with
(no root rights should be needed)

Code: Select all

./bootinfoscript --update <filename>

or

Code: Select all

./boot_info_script --update <filename>

or

Code: Select all

./boot-info-script --update <filename>

depending on the filename we gave to the previous (before the new downloaded one) BIS.

If no filename is specified, the file should be saved ( probably in the home directory? ) as "<bootinfoscript_yyyy-MM-dd_hh:mm:ss>".

As before, make it executable (beware not to copy the code "as-is", but to change the <filename> accordingly):

Code: Select all

# chmod a+x ./<filename>

To see which version was downloaded (beware not to copy the code "as-is", but to change the <filename> accordingly):

Code: Select all

$ ./<filename> --version

And execute it (beware not to copy the code "as-is", but to change the <filename> accordingly):

Code: Select all

$ ./<filename>

Again, @Salix mods and devs, please post any correction needed to the above codes so to be able to run it correctly under Salix (maybe some ".sh" or "bash" or similar are needed to execute BIS under Salix?) and you might want to update Salix repository with the latest BIS v.0.61 just released if you are interested .

Thanks to Gert Hulsemans for maintaining BIS and thanks to Salix Team.

HTH.

[Shador]

Topic splitted and moved. I really don't see how this post should closely relate with the original topic. A short cross reference would have been acceptable but not such a book with little related content.

Package doesn't apply for upgrade before next Salix version (i.e. current). Anybody feel free to test those instructions, if you want, but I see no need.

[Adys]

FWIW,

The reason I previously posted the info in the original topic ( viewtopic.php?f=31&t=3157 ) was because:

A_ Shador mentioned in that topic that BIS v0.60 was just added to Salix repository, while there is v0.61 available, with some improvements.
B_ In the original topic, there were 5 posts (in addition to the first mention about BIS) related to BIS.

So I though that might have been useful. My apologies if the way I posted was inadequate.

Independently of that topic, I still think BIS is a useful script to have available, and even better if it is updated to include more info or supporting more cases.

Anyway, if anyone finds out there is any step that is incorrect or any other suggestion about BIS, please post it here so it would be useful for everyone else. Thanks.

[Shador]

So I though that might have been useful. My apologies if the way I posted was inadequate.

It's not inadequate neither useful. Just the location were you posted was suboptimal. I think in its own topic more people can benefit and that's where it comes into its own. I was never criticizing you and never meant to. I went through the trouble because I think it can be useful.

Independently of that topic, I still think BIS is a useful script to have available

I agree. Therefor the package.

and even better if it is updated to include more info or supporting more cases.

Yes, in a future Salix releases. But feature additions, minor bugfixes and a change of the executable's name, definitely don't qualify for a stable release. If I were to upgrade it solely because of the version and features, many other packages would qualify too. Consequently we would be maintaining an unstable stable release. That Oxymoron says everything.

[Adys]

I guess you are correct.

... feature additions, minor bugfixes and a change of the executable's name, definitely don't qualify for a stable release...

I don't know what "minor bugfixes" means for this particular case. Between the old version and v0.60 there were a lot of improvements; so in relation to that, they sure are minor changes (whichever the changes were). AFAIK, the new version 0.61 was the result of some cases posted in Ubuntuforums.org that were not working optimally before.

So this new version (and the above steps, if they are 100% correct) may be helpful for some additional users. In case someone posts BIS info in the forum and it is not clear or incomplete, then at least the Team (and other forum members) now knows there is a BIS update that may help.

@Shador, thank you for your replies and your work.

[Shador]

Minor means not important here as in not crucial. Example of changes that would qualify are security fixes or broken applications among others of course.

So this new version (and the above steps, if they are 100% correct) may be helpful for some additional users.

That's more features then. Because it makes something work that never worked. I'm more thinking about bug fixes as regressions, i.e. something used to work but is broken now. Features never qualify for upgrades and regressions/bug fixes only with high severity.
Each release is a snapshot (unlike with rolling-release) and because we don't want to introduce regressions as few as possible is changed. If there really is a regression within a release to itself, that's fixed. But just adding features, higher reliability or more use cases is done with a new release. This ensures that users can be sure if a release is working for them or working the way they like it that state won't change and they can always go back to it. That's the whole purpose of releases and their archives, otherwise they're pointless and a rolling-release cycle could be used.

[Adys]

@Shador,

I understand your point about regressions and bug fixes. I'm not trying to convince you of anything. I'm just letting you know that there is a new release available, just in case.

About "more features", or whatever work went into BIS exactly, I don't know. I also don't know if it is acceptable to link to other forums, or quote or whatever (so to show what apparently triggered the changes between v0.60 and v0.61).

I might have misunderstood something else though (from the topic where I originally posted the first post that you moved to this current topic). I thought you just added BIS to Salix repository a few days ago (just before it was updated from v0.60 to v0.61). From your post above, it seems like BIS was not an addition of the last few days, but it was already part of the current Salix, and only when the next Salix will be built (whatever that means), BIS could (or not) be updated in the repository, according to the relevant testing.

Whichever the case, the important thing is that any user could try BIS v0.60, and if that is not enough, then maybe v0.61 could be useful. So for anyone here in the forum helping by means of BIS, just take this new version into account. The worst thing that could happen is that there is some dependency issue, but it won't break the user's system nor leave any crap. So knowing that there is a new version available for the users is harmless at least. With the steps above (if they are 100% correct for Salix), the user seeking help here can follow simple steps to run the latest version whenever any mod here would request it, if there is any need to it.

I hope it helps, that's all.