uname not showing r1beta3

[kallisti5]

Just noticed that uname is not showing "r1beta3" anywhere in it.

Not sure if that's expected, but we might want to address it.

[kallisti5]

The AboutSystem window gets the branch name from the BEOS:APP_VERSION of libbe.so. (src/apps/aboutsystem/AboutSystem.cpp)

uname gets the version as the hrev from get_haiku_revision() (src/system/libroot/posix/sys/uname.c)

Ideally, maybe uname.c should see a "non-nightly" (Walter) version in BEOS:APP_VERSION and report the branch instead of the hrev?

[kallisti5]

The alternative would be reporting branch(hrev...) in uname. Example:

• Nightly: Walter(hrev12345), Walter~hrev12345
• Release: r1beta3(hrev12345+8), r1beta3~hrev12345+8

[pulkomandy]

This should not be patched in uname. Instead, we should give "real" versions to releases instead of using hrevs there. But the ticket about that was closed without actually making any changes during the beta1 release process. And so we have this stupid versionning scheme where the haiku package version is something like "hrev1~beta3_hrev12345+8" where it should just be "hrev1~beta3+15" or something simple like that (with the 15 being the number of commits since the beta tag).

[pulkomandy]

Actually "uname -r" (kernel release) just returns "1" for Haiku R1. I think we should keep it that way and update it to 1.1, 1.2, etc for releases after R1.

In theory we could put 1~beta3 there but I think it will just confuse tools trying to parse uname output?

[kallisti5]

The kernel release doesn't show up in uname -a which is what most programs use for identification.

1~beta3 (or 1.0~beta3) seems reasonable?

uname -k giving a "1" isn't very descriptive anyway :-)

[kallisti5]

nevermind.. you're right. the 1 is in "uname -a" Theoretically appending stuff onto the 1 shouldn't break parsing.. most things just split on space.

Linux: Linux eris.discord.local 5.12.13-arch1-2 #1 SMP PREEMPT Fri, 25 Jun 2021 22:56:51 +0000 x86_64 GNU/Linux

Haiku: Haiku shredder 1 hrev55181+16 Jun 29 2021 20:25: x86_64 x86_64 Haiku

Just noticed our kernel "version" has an extra : on the end which seems odd. Something getting cut off?

[madmax]

Replying to kallisti5:

Just noticed our kernel "version" has an extra : on the end which seems odd. Something getting cut off?

Yeah, not an extra : but the seconds being cut off. It's strlcatting ​revision with build date and time in ​a 32 bytes string and the last two chars don't fit in this case.

[nielx]

Ticket retargeted after milestone closed

[pulkomandy]

Moving various tickets out of the beta4 milestone because no one is actively working on them.