[General] Change release naming to 2018.10

[igorpecovnik]

No description provided.

[ThomasKaiser]

Well, switching to such a naming schemes creates a few impressions: stable releases (not really true), a time frame for new releases (when will 2019.04 be released?), nice source of confusion (Ubuntu 18.04 being part of Armbian 18.10? Users will even more fail to understand what's Armbian and what's Debian/Ubuntu -- great source for new support efforts).

In the end it will most probably put a lot more pressure on an already shrinking team.

[zador-blood-stained]

I don't think that using Ubuntu naming scheme can be applied to images that can be based on different Ubuntu or Debian releases.
In addition the displayed (i.e. in MOTD) version number in reality means just the BSP package version while everything else could be from a matching stable, very old stable, nightly or user-built image. We may as well use short commit ID like 790a158 instead of the version number (and it will provide the exact state of the build script repository used to create the BSP), or use "user-friendly" names (Ubuntu 18.04 Bionic Beaver? How about Armbian 18.10 Scorched Earth User-Made Boot Script Customizations?)

[igorpecovnik]

Primary idea is to get rid of the naming which doesn't tell much. True. "stable" does not tell much and it's better to be removed and leave only "nightly" and "user-build" labels.

Whole thing is already confusing for people that come from x86 world. Once, there will be one arm32 and one arm64 kernel ...

Here we only need to know quickly which version we are running, while for support this login prompt is pointless anyway.

Which is best: 1,2,3,4,5?

 _   _      _ _           _  _   
| | | | ___| (_) ___  ___| || |  
| |_| |/ _ \ | |/ _ \/ __| || |_ 
|  _  |  __/ | | (_) \__ \__   _|
|_| |_|\___|_|_|\___/|___/  |_|  
                                 
Welcome to Armbian 2018.10 (Debian Stretch)

Linux: 		   4.14.74-mvebu
System load:   0.02 0.01 0.00   Up time:       2 days

 _   _      _ _           _  _   
| | | | ___| (_) ___  ___| || |  
| |_| |/ _ \ | |/ _ \/ __| || |_ 
|  _  |  __/ | | (_) \__ \__   _|
|_| |_|\___|_|_|\___/|___/  |_|  
                                 
Welcome to Armbian 2018.10 (Ubuntu Bionic) with Linux 4.14.74-mvebu

System load:   0.02 0.01 0.00   Up time:       2 days

 _   _      _ _           _  _   
| | | | ___| (_) ___  ___| || |  
| |_| |/ _ \ | |/ _ \/ __| || |_ 
|  _  |  __/ | | (_) \__ \__   _|
|_| |_|\___|_|_|\___/|___/  |_|  
                                 
Welcome to Armbian 2018.10 (Ubuntu Bionic) with Linux 4.14.74-mvebu !User-build!

System load:   0.02 0.01 0.00   Up time:       2 days

 _   _      _ _           _  _   
| | | | ___| (_) ___  ___| || |  
| |_| |/ _ \ | |/ _ \/ __| || |_ 
|  _  |  __/ | | (_) \__ \__   _|
|_| |_|\___|_|_|\___/|___/  |_|  
                                 
Welcome to Armbian 790a158 (Ubuntu Bionic) with Linux 4.14.74-mvebu !User-build!

System load:   0.02 0.01 0.00   Up time:       2 days

 _   _      _ _           _  _   
| | | | ___| (_) ___  ___| || |  
| |_| |/ _ \ | |/ _ \/ __| || |_ 
|  _  |  __/ | | (_) \__ \__   _|
|_| |_|\___|_|_|\___/|___/  |_|  
                                 
Welcome to Armbian Bionic 790a158 with Linux 4.14.74-mvebu

System load:   0.02 0.01 0.00   Up time:       2 days

@g-provost We need to change boot script to ask user if overwrite. Then perhaps future Armbian naming will be more towards romantic comedy gender :)

[ThomasKaiser]

My last 2 cents:

• current way to display any version information is broken since ever. Your motd approach simply sucks since not reporting Armbian version but BSP package version.
• 'stable' is a design goal not a fancy label. Unless Armbian (or let's better say the maintainer(s)) get an idea that if something bases on such boring and horribly outdated distros like Debian or Ubuntu that are only used since users want something stable also requires Armbian providing a stable branch nothing can improve.

Your proposed naming change suggest Armbian would now be stable but this is not the case. Upstream Debian and Ubuntu projects have teams for bootloader and kernel that are way larger than all Armbian contributors added over the last few years. And they roll out way less bootloader and kernel upgrades than Armbian (now even bootscript updates can brick boards).

[zador-blood-stained]

Which is best: 1,2,3,4,5?

Welcome to Ubuntu Bionic with Armbian Linux 4.14.74-mvebu

Everything else does not need to be displayed in MOTD but can be included in the armbianmonitor -u log.

Edit: I don't mean that toilet board name and uptime should be removed from MOTD, I only added my view on the image identification / version string.

[igorpecovnik]

Your motd approach simply sucks

It is yet another left over from a pet project. Back then it was just fine.

and horribly outdated distros like Debian or Ubuntu

Yes they are and there is nothing we can do about. I would like to see something better. Perhaps as an option. Once when there will be more people interested to contribute for such change.

Can we switch to something better without rewriting half of the code?

Your proposed naming change suggest Armbian would now be stable but this is not the case.

Not sure if? I follow the idea that current naming scheme is pointless. At least we agree on that in 100%. Labels as "Nightly" indicates they nobody test that, "use-build" is not eligible for support, "stable" was. Since we are removing "stable" it should be better support wise. We don't say anything.

Welcome to Ubuntu Bionic with Armbian Linux 4.14.74-mvebu

No versions, no labels. OK. I have one more concern.

Linux Mint. They are making a distro from both, Ubuntu and Debian and they have their own naming and leave "based on" in a small print, specs. They do some desktop tuneup, remix, don't really know the details ... Our focus and work is elsewhere, different but changes are at least functionally more important than most of the Debian/Ubuntu distros(remixes) out there. For many hardware you have Armbian vs. bareily usable shit, complex install, no support, ... It is larger diff than Ubuntu vs. Mint vs. Debian on shiny Dell XPS or Macbook, right?

Do we actually need attachment to Ubuntu/Debian this strong? Welcome/git page already communicate "Debian based".

Kernel is and will be board/family dependent for some time. U-boot as well. Some need more updating, some less. Ideally it would be to have dedicated board maintainers (as they are in u-boot, but redundance is what helps on stability) and they decide (and send to /upload) when some boot loader needs an update or not. Not that we(I) run update on all, do some tests and hope for the best ... Mainstream distros. Debian and Ubuntu ARM support is poor(er) and both are outdated ... despite their large(r) teams. What about Fedora? https://www.youtube.com/watch?v=9u3a1UtkrH8

[g-provost]

Well before jumping ahead with a release naming convention, we should discuss the overall versioning logic in Armbian. And i think it's pointless to change release name till the following is not improved and agreed.

For my opinion, and it's something I already shared with Igor via PM, the biggest issue in Armbian is that all Armbian packages shared the same version number. It is not normal in a distro that a package get its version bumped even if nothing has changed in the package.

Here what i said to Igor :

I understand it's tricky to do differently, but I had the exact same challenge in a recent project, we needed to avoid building over and over the packages that didn't have any changes and avoid bumping its version (the version was also coming from an overall meta version, similar to your use case where you use armbian version string for the dpkg version).

So we use a manifest file for each package (could be actually embedded inside the dpkg CONTROL file) that contains the list of git repo that are used to build the dpkg. For each git repo we have the url/branch + commit + path. ( Note : 'path' info is optional, it is used to indicated we are only interested to monitor changed in a folder of a git repo.)

When the build script is about to build the dpkg, it goes fetch the manifest of the latest dpkg version in the dpkg repo then check for each git repo entry in the manifest if new commits have been made in the those git repo since the commits recorded in the manifest. If none, it will skip building the dpkg and just fetch directly the package from the dpkg repo. If one or more commit was made since last commits recorded in the manifest, then the build script will build the dpkg and then update the manifest with latest commit hash. 

I know it would require quite some effort. But changing Armbian release naming is the right opportunity to decouple once for all the OS versioning from the packages versioning and avoid all those package rebuilding and version bumping.

OS version should only be seen as a meta version info and/or freeze point on a timeline. I think using Armbian - Distro_Name (YYYY.MM) is workable and maybe it's time to start reusing git releases for that.

You could also build a debian metapackage to keep the hard/soft relation between the Armbian OS version and the Armbian packages version.

As for the Armbian packages, I think the current X.YY would still work, but it would means they wouldn't have at the same point of time the same version. Example :

Armbian - Strech (2019.02) would be composed of the following :

• armbian-config 5.72
• armbian-firmware 5.64
• armbian-tools-stretch 5.78
• linux-dtb-next-mvebu 5.64
• linux-image-next-mvebu 5.78
• linux-stretch-root-next-helios4 5.72
• linux-u-boot-helios4-next 5.64

(maybe a bit of dpkg naming harmonization should be done also)

On the stable, nightly and user-build build topic : I think YYYY.MM would indicate it is a stable / official release build. Otherwise YYYY.MM should be replace by the git commit hash therefore indicating it is a nightly build. As for user-build, well I'm not really sure I understand the use case.

Welcome to Armbian - Stretch (2019.02) Linux 4.14.74-mvebu

or

Welcome to Armbian - Stretch (790a158) Linux 4.14.74-mvebu

@g-provost We need to change boot script to ask user if overwrite. Then perhaps future Armbian naming will be more towards romantic comedy gender :)

Not sure i understand the relation with topic.

[zador-blood-stained]

Linux Mint. They are making a distro from both, Ubuntu and Debian and they have their own naming and leave "based on" in a small print, specs. They do some desktop tuneup, remix, don't really know the details ... Our focus and work is elsewhere, different but changes are at least functionally more important than most of the Debian/Ubuntu distros(remixes) out there. For many hardware you have Armbian vs. bareily usable shit, complex install, no support, ... It is larger diff than Ubuntu vs. Mint vs. Debian on shiny Dell XPS or Macbook, right?

From a quick glance at Mint repository they rebuild and mirror a significant number of (upstream) packages, so they have to use their internal versioning.
Armbian vs other SBC distros have close to 0 userspace package differences because they use 90+% of upstream Debian/Ubuntu precompiled packages.

Speaking of Armbian, usually "barely usable shit" does not break on upgrades because they don't upgrade critical parts like u-boot and boot script, but this does not have any security implications like not upgrading kernel or userspace packages.

Labels as "Nightly" indicates they nobody test that, "use-build" is not eligible for support, "stable" was. Since we are removing "stable" it should be better support wise. We don't say anything.

A couple clicks in armbian-config kernel and branch switching menus and these labels won't reflect the actual state of the image.

Do we actually need attachment to Ubuntu/Debian this strong? Welcome/git page already communicate "Debian based".

Do you want to answer questions like "how to install a $name database on Armbian / how to install a VPN server on Armbian / how to install a web server on Armbian / etc."? Oh, wait, these questions mostly come from logrotate/ramlog not working reliably enough compared to other "barely usable shit" distros.

Ideally it would be to have dedicated board maintainers (as they are in u-boot, but redundance is what helps on stability) and they decide (and send to /upload) when some boot loader needs an update or not. Not that we(I) run update on all, do some tests and hope for the best ...

And how do you see your versioning working in this scenario when random kernel/u-boot/BSP packages may have different versions?

[chwe17]

Welcome to ARMBIAN (Debian Stretch/Stretch) Kernel: 4.14.70-rockchip maybe with a:
Welcome to *random crap* based on ARMBIAN (Debian Stretch/Stretch) Kernel: 4.14.70-rockchip for user-built images to point clearly that this isn't a official Armbian Image.

Ubuntu/Debian are just flavors of Armbian. Most (all?) changes we make get applied to all distributions (e.g. zram, ramlog, armbian-config). We may also reconsider our kernel naming (default, next, dev). I propose something like:

• Vendor (for bsp kernels)
• Vanilla (for all vanilla based kernel - maybe a bit missleading as well cause we patch them sometimes quite heavy, in my field you would call it purum)

Maybe such a structure might work?

-Vendor
 |___default
   |_testing
   |_nightly
-Vanilla
 |___default (must be an LTS)
 | |_testing
 | |_nightly
 |
 |___next (only availble during switch to the next LTS e.g. 4.14 --> 4.19)
 | |_testing
 | |_nightly
 |
 |___dev (any vanilla kernel)
   |_testing
   |_nightly

Default gets only updated with every release cycle and we test/guarantee update from the last default to the new one (testing procedure might be a way easier). The interesting stuff will happens in testing. Similar to the kernel, testing would have a merge window followed by a testing phase. If it works --> new default, when not reject it (and fix it for the next merge window). Support only for default and a sub-forum for testing where only issues should be reported. I'm not sure if such a structure is maintainable for our small team but it should reduce the support questions. Indeed people would have a less recent kernel. But if it reduces the 'Armbian broke my pet-project' questions, it might be worth.. Kernels without enough response (in testing) and/or no interest from the maintainers get dropped.

[g-provost]

Oky it seems the bootscript update thingy has posed some problem and that this thread should definitively be more than just about release naming. You might think I'm polluting the thread but I still want to insist on the point i was trying to made and I will use the bootscript update as a perfect use case.

• Should we be able to update bootscript via dpkg ? Yes
• Should bootscript update from one board impacts another board ? No
• Should bootscript get updated (overwrite) every time we update armbian-bsp ? No

So in order to fulfill properly the 3 points above, I only see one solution :

1. Boot script must be packaged in a dedicated package or in u-boot dpkg (which is of course board specific )
2. Armbian packages needs to be decouple from OS version and only be rebuilt (+ version bump) when something has changed.

Do you guys agree or not ? Or Armbian should carry on with this same monolithic versioning that it uses so far.

Ideally a Software Parts diagram should be done to visually explain the relation / dependency between the different armbian dpkg. From there it's easy then to define a platform versioning system and please everyone on the syntax of version strings.

If you guys you are keen to introduce a new dpkg dedicated to bootscript, then this dpkg can be the first candidate to use a smart build workflow that only rebuilt it if something as changed.

Side point : when I look at the Depends, Conflicts and Replaces value in dpkg CONTROL file of armbian-bsp and armbian-config I'm getting confused... seems to be some mistake there.

[igorpecovnik]

I think YYYY.MM would indicate it is a stable / official release build. Otherwise YYYY.MM should be replace by the git commit hash therefore indicating it is a nightly build.

Yes, that sounds reasonable.

Speaking of Armbian, usually "barely usable shit" does not break on upgrades because they don't upgrade critical parts like u-boot and boot script

A naming change is partially related to this. Moving the update logic from all to what is needed.

A couple clicks in armbian-config kernel and branch switching menus and these labels won't reflect the actual state of the image.

We can rely on the diff between /etc/armbian-image-release and /etc/armbian-release

Do you want to answer questions like "how to install a $name database on Armbian

I don't think removing wording Debian/Ubuntu can bring noticeable change. Those who asks now will continue to do so in the future.

these questions mostly come from logrotate/ramlog

Yes, there are bugs in our scripts. We should be "at Ubuntu 18.04.0" and we have to push it to 18.04.5. I know that my head sometimes jumps ahead to fast ...

And how do you see your versioning working in this scenario when random kernel/u-boot/BSP packages may have different versions?

• make BSP always?
• make a new meta package for this?

Most (all?) changes we make get applied to all distributions

Almost all. The idea is that both should look and feel the same. Most accurate way is as Zador pointed to: Welcome to Ubuntu Bionic with Armbian kernel xxxx ... but we have freedom to define whatever. Our own wording ... IMO relation to the codename is important to be present.

our kernel naming

There is a wish and a tendency to lower the number and merge as many kernels as possible. In the future, there will be only one/two. I am aware that this is still pretty distant, but theory stands.

I am not sure we have the capacity for such expansion while there are more basic problems out there waiting to be fixed.

Should bootscript update from one board impacts another board ?
Should bootscript get updated (overwrite) every time we update armbian-bsp ?

Board specific things go into board support packages. We still need to have a system that all packages for all boards are made and the update don't break anything. In this specific case we can declare boot script as a config file which is overwritten only if user accept this. If boot script in BSP = installed one, it doesn't bother.

Boot script must be packaged in a dedicated package

Not sure if that is really needed at this point, but it can be done, yes.

Armbian packages needs to be decouple from OS version and only be rebuilt (+ version bump) when something has changed.

If this is solved and build system creates only changed packages + general meta pkg for versioning, we are already cool, right? Any simple way how to know when a package must be created?

Side point : when I look at the Depends, Conflicts and Replaces value in dpkg CONTROL file of armbian-bsp and armbian-config I'm getting confused... seems to be some mistake there.

Possible, but let's do those specifics elsewhere. We are human who make mistakes and we lack humans to correct them.

[g-provost]

If this is solved and build system creates only changed packages + general meta pkg for versioning, we are already cool, right? Any simple way how to know when a package must be created?

Just an idea :

== uboot_helios4_next_changes.track ===================
#Helios4 U-Boot - Code change tracker file

github.com/armbian/build.git / master / ab56789
path : patch/u-boot/u-boot-helio4/

github.com/armbian/build.git / master / e87475e
path : config/sources/mvebu.conf

github.com/armbian/build.git / master / f8c456a
path : config/sources/mvebu-helios4.inc

github.com/helios-4/u-boot-marvell.git / u-boot-2013.01-15t1-helios4 / 3df5432
path : /

=================================================

compile_uboot()
{
  foreach entry in .track file
       [[ latest commit hashref in path != entry hashref ]] && CHANGES++  
  done

  if !CHANGES then use latest dpkg in repo.

  if CHANGES then
    increment package_version
    build package
    update href in tracker file
    publish in dpkg repo
}

[zador-blood-stained]

A naming change is partially related to this. Moving the update logic from all to what is needed.

I think that moving u-boot and boot script update logic from auto (forced) to initiated by user explicitly (like you do BIOS/EFI/EC firmware upgrades in x86/x64 world) with a changelog (that gives a valid reason to upgrade beyond "Updated u-boot from 2018.09 to 2018.11" and lists added/fixed/broken features specific for the particular device) is better in the long term, if we had board maintainers that could provide that changelog.

We can rely on the diff between /etc/armbian-image-release and /etc/armbian-release

/etc/armbian-release reflects only the BSP version, so it is a version without real meaning, it only matters for debugging BSP issues.

Yes, there are bugs in our scripts.

I wouldn't call it a bug, it's just a concept that can't be reliably implemented and tested in a reasonable time period.

[g-provost]

I think that moving u-boot and boot script update logic from auto (forced) to initiated by user explicitly (like you do BIOS/EFI/EC firmware upgrades in x86/x64 world).

Makes complete sense.

[igorpecovnik]

/etc/armbian-release reflects only the BSP version, so it is a version without real meaning, it only matters for debugging BSP issues.

For example. My Helios image is "user-build" but upgraded on "stable" repository. This tells it's not completely official build and it should read /etc/armbian-release and display commit value (from BSP or META pkg):
Welcome to Armbian - Stretch (790a158) Linux 4.14.74-mvebu
instead of
Welcome to Armbian - Stretch (2019.02) Linux 4.14.74-mvebu # support is strictly limited to those.

I think that moving u-boot and boot script update logic from auto (forced) to initiated by user explicitly (like you do BIOS/EFI/EC firmware upgrades in x86/x64 world).

OK. Than u-boot package and BSP package (if u-boot script remained there) both must prompt for confirming and do nothing if installation is unattended. Changelog (if available) should be inside the package and shown up on this prompt?

Further mess could be solved with one "table/template/configuration" where we define which kernels are safe for upgrade/rebuild when a build cycle comes. Once set, this will not change much. This is valid for nightly builds as well. They should represent the same reality as next stable release.

Defaults per system (lib/configuration.sh), kernel family and branch (config/sources) and per board (config/boards).
KERNEL_REBUILD="yes" # valid for DTB, headers and sources
U-BOOT_REBUILD="no"
BSP_REBUILD="yes"
FIRMWARE_REBUILD="no"

Meta package is made always and force switch should be there.

Will that work?

[g-provost]

OK. Than u-boot package and BSP package (if u-boot script remained there) both must prompt for confirming and do nothing if installation is unattended. Changelog (if available) should be inside the package and shown up on this prompt?

Don't you guys think it's a bit too much to require user to explicitly trigger bsp package update. I think it is better to pull out the boot script from bsp package then. And just require user to manually initiate u-boot and boot script packages as Zador suggested.

[zador-blood-stained]

OK. Than u-boot package and BSP package (if u-boot script remained there) both must prompt for confirming and do nothing if installation is unattended. Changelog (if available) should be inside the package and shown up on this prompt?

First, since we started going from vendor to mainline u-boot and back on some platforms it would make sense to package the boot script into the u-boot package.
And second, I would prefer not having any prompts. "Don't touch if it works" is a good idea when dealing with u-boot, and a lot of peoplethink that "newer == better "so they'll answer "Upgrade" without reading the changelog if you give them the prompt.

[g-provost]

@zador-blood-stained you right the easiest way for now is to move boot scripts to the u-boot package. I'm also not a big fan of prompt, plus the way the armbian dpkg are generated today, adding debconf would make compile_uboot() bloated :P

To make u-boot a dpkg that never get updated by apt upgrade, we can either put the package on Hold via dpkg command or use Apt Preference (Pin-Priority). I think the latest it's the easiest.

[igorpecovnik]

To make u-boot a dpkg that never get updated by apt upgrade, we can either put the package on Hold via dpkg command or use Apt Preference (Pin-Priority). I think the latest it's the easiest.

Or start using new names for u-boot packages which are installed, applied and de-installed on the spot. From armbian-config menu.

[chwe17]

why not simply separate armbian-config freeze? Freeze kernel & freeze u-boot and shipping the next armbian-config with freeze u-boot as default? If a kernel needs for whatever reason a newer version of u-boot this could be solved with dependencies right?
https://www.debian.org/doc/debian-policy/ch-relationships.html

[chwe17]

Ubuntu-/Debian-version is now missing (e.g. 18.04 or Bionic). I would prefer having it still there.

[igorpecovnik]

Aha, I see. There it should be written Bionic not Ubuntu. Fixing ...

[igorpecovnik]

 _   _                         _   __  __ _  _   
| \ | | __ _ _ __   ___  _ __ (_) |  \/  | || |  
|  \| |/ _` | '_ \ / _ \| '_ \| | | |\/| | || |_ 
| |\  | (_| | | | | (_) | |_) | | | |  | |__   _|
|_| \_|\__,_|_| |_|\___/| .__/|_| |_|  |_|  |_|  
                        |_|                      
Welcome to Armbian - Xenial (2018.10) Linux 4.4.161-rk3399`

[ThomasKaiser]

Great! Armbian - Xenial (2018.10) -- so as usual we babble a lot, express concerns here, here and there and all that's happening is ignoring everything and doing your own thing. Well done.

[g-provost]

Can you add in the uboot dpkg postinst the following code : bf5a2fe#diff-b225c05602cb04e6ba6998e442c3a092

Since now U-Boot update can only be triggered manually, I thought that it was going to be OK to make the postinst update the bootscript. Otherwise what was the point of all this (beside release renaming).

[zador-blood-stained]

Freeze u-boot package by default

This is not exactly what I meant, this affects only old images so we are not fixing potential and existing problems with them. In some platforms we still have complicated (and broken) logic for detecting where to write the u-boot binary - SD/eMMC/eMMC special partition, etc.

IMO postinstall code should be moved to a separate script.

[g-provost]

@zador-blood-stained Then why not make the u-boot postinst script board specific ?
Example : config/bootscripts/boot-mvebu-next.postinst

And during compile_uboot() we pull the script for the specific board. This way no need to bother with a complex single u-boot postinst logic that would address all boards at once.

[zador-blood-stained]

@zador-blood-stained Then why not make the u-boot postinst script board specific ?

This can be done where it is needed, but it still doesn't solve the issue of determining where to flash the u-boot on boards with SD, eMMC and SPI flash present.

[igorpecovnik]

This is not exactly what I meant, this affects only old images so we are not fixing potential and existing problems with them.

Then dropping all changes related to u-boot in this PR and develop a new u-boot package (in separate PR) would be the best option? Current packages will not receive updates anymore which means we are OK for older version. This new u-boot package will replace this one and should contain at least separate u-boot versions for different targets along with scripts and separate u-boot versions for different packages (Espressobin).

And some scripting which asks user to choose where he wants to flash this u-boot and optionally with which speed/memory version?

[lanefu]

@igorpecovnik may we close this PR? Did #1423 address the release naming change?