Merge commits not in newest release?

[kapilhp]

Disclaimer: I am not sure how the updates of crouton are supposed to work.
I updated crouton to check that #3410 and #3514 had indeed been fixed. However, the "real" installer downloaded by crouton still contains the older versions of croutonclip etc.
If this is as intended, then please close this issue.

Kapil.

[DennisLfromGA]

@kapilhp,

Show us the output of sudo edit-chroot -all
If you reboot you're sure to get a fresh copy 'crouton'.

Hope this helps,
-DennisL

[kapilhp]

Output of sudo edit-chroot -all:

name: min
encrypted: yes, unlocked
Entering /mnt/stateful_partition/crouton/chroots/min...
crouton: version 1-20171119224248~master:c73e7a80
release: buster
architecture: amd64
xmethod: xiwi
targets: extension,xiwi,x11
host: version 10032.39.0 (Official Build) beta-channel cyan
kernel: Linux localhost 3.18.0-16283-gde9f7f8596fa #1 SMP PREEMPT Tue Nov 14 22:07:19 PST 2017 x86_64 GNU/Linux
freon: yes

Your suggestion does not work for the following reason.

Running
curl -# -L --connect-timeout 60 --max-time 300 retry 2 https://github.com/dnschneid/crouton/raw/releases/crouton > crouton
gives the "real" installer. At the end of this script is a .tar.bz2 consisting of the scripts to be installed. These are the "old" scripts not the new ones.

My guess is that the contents of "raw.github.com/dnschneid/crouton" have not been updated after the latest commit. Since this should be automatic, I am puzzled.

Alternatively, since I am behind a web proxy, it is possible that it has incorrectly cached the older version of the installed and is giving me that. I will check.

Kapil.

[kapilhp]

I downloaded the real installer from a few other sites that I have access to and found that the installer is the same. So as far as I can see the update has not propagated to the installer.

Kapil.

[dnschneid]

Maybe because I somehow pushed a release that didn't include the latest merge :(

Sorry about that. The most obvious way to tell is by going to the network graph and seeing how the release branch relates to master. release should always be to the right of master, and if you mouse-over the release commit, the bit after the tilde will be the hash of the related master commit. If you then mouse-over a commit on master, you can see the hash in low-contrast gray in the top-right corner of the pop-up, truncated one character further than the hash in the release message.