Byobu not clearing update numbers after updates

[Calcipher]

I am running byobu on Debian Testing and, as of the last week or two, byobu has started not clearing the update counter even after updates. Even exiting byobu completely and starting a new session does not clear the indicator, only updating do it. Sometimes, and this is not consistent, running an `apt-get update` causes the indicator to clear itself.

~$ uanme -a
    Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64 GNU/Linux
~$ byobu -v
    byobu version 5.87
    Screen version 4.04.00 (GNU) 19-Jun-16

[Dustin Kirkland  (kirkland)]

Hmm, I'm unable to reproduce this on Ubuntu 16.04 and byobu version 5.110 and tmux 2.1.

How did you do the upgrade? "sudo apt-get dist-upgrade"?

[Calcipher (calcipher)]

Dustin, this is on Debian Testing where the problem exists. I have replicated it on Kali Linux Rolling as well. I use screen as my back-end if that helps.

[Colin Bell (colbell)]

Happens for me as well on Ubuntu 16.10 after running both 'apt upgrade' and 'apt full-upgrade'.

~ uname -a
   Linux colin-t460 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:03:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

~ byobu -v
   byobu version 5.112
   tmux 2.2

~ zsh --version
  zsh 5.2 (x86_64-ubuntu-linux-gnu)

[Gregory M. Blumenthal Scharf (llameadrpc)]

Same problem with aptitude full-upgrade on Linux Mint.

uname -a
Linux server 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

byobu -v
byobu version 5.106
tmux 2.1

 bash --version
GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)

cat /etc/*release*
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18
DISTRIB_CODENAME=sarah
DISTRIB_DESCRIPTION="Linux Mint 18 Sarah"
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.3
DISTRIB_CODENAME=rosa
DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa"
NAME="Linux Mint"
VERSION="18 (Sarah)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 18"
VERSION_ID="18"
HOME_URL="http://www.linuxmint.com/"
SUPPORT_URL="http://forums.linuxmint.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/linuxmint/"
UBUNTU_CODENAME=xenial
cat: /etc/upstream-release: Is a directory

[James Sinton (jksinton)]

You can force byobu to update the updates available by clearing the cache files, which store the number of updates available. I use screen, so my cache is stored here:

rm /dev/shm/byobu-<user>-<XXXXXXXX>/cache.screen/updates-available
rm /dev/shm/byobu-<user>-<XXXXXXXX>/cache.screen/updates-available.lock

Regards,
James

[James Sinton (jksinton)]

So the problem seems to be with ___update_needed() and the checks for Debian/Ubuntu. After running an upgrade, the updates-available cache file and /var/lib/apt had the exact same modification times (based on ls) whereas /var/lib/apt/lists was older than the updates-available cache file.

I added an echo statement to monitor the return value of the [ FILE1 -nt FILE2 ] checks:
        if $BYOBU_TEST apt-get >/dev/null; then
                # Debian/ubuntu
                [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ]
                local nt=$?
                echo "updated_needed returns: $nt" >> /home/byobu-user/byobu.log
                return $nt

This is what I get:

updated_needed returns: 1

Again, this was after the upgrade.

Then I tried hardcoding updated_needed to return 0. And, voilà the updates-available cache file updated successfully.

[James Sinton (jksinton)]

The bug is definitely is caused by the modification time check in updated_needed(): [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ].

The problem is that during an upgrade by running apt-get upgrade, /var/lib/apt is modified, but not upon completion of the upgrade. So byobu triggers an update to the cache during the upgrade, but not afterwards. See the stats of the files after the upgrade I used to verify this situation:

$stat /var/lib/apt/lists
  File: '/var/lib/apt/lists'
  Size: 20480 Blocks: 40 IO Block: 4096 directory
Device: 846h/2118d Inode: 661369 Links: 3
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-12-13 12:30:47.271921285 -0600
Modify: 2016-12-13 12:30:47.263921961 -0600
Change: 2016-12-13 12:30:47.263921961 -0600
 Birth: -

$ stat /var/lib/apt
  File: '/var/lib/apt'
  Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 846h/2118d Inode: 530070 Links: 6
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-12-13 12:35:11.761565067 -0600
Modify: 2016-12-13 13:05:24.564724270 -0600
Change: 2016-12-13 13:05:24.564724270 -0600
 Birth: -

Stat of updates_available:
$stat /dev/shm/byobu-user-XXXXXXXX/cache.screen/updates-available
  File: '/dev/shm/byobu-user-XXXXXXXX/cache.screen/updates-available'
  Size: 4 Blocks: 8 IO Block: 4096 regular file
Device: 15h/21d Inode: 29 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ james) Gid: ( 1000/ james)
Access: 2016-12-13 13:06:01.117645947 -0600
Modify: 2016-12-13 13:05:30.820197467 -0600
Change: 2016-12-13 13:05:30.820197467 -0600
 Birth: -

As shown above, the updates_available file has a more recent modification time than /var/lib/apt and /var/lib/apt/lists. So we need to find a file that indicates the upgrade is complete to tell byobu to update the cache file. I chose /var/log/dpkg.log, which works. A caveat is that monitoring /var/log/dpkg.log may trigger updates to the cache for any activity logged to dpkg, which includes installations, not just upgrades.

My implementation is this:
if $BYOBU_TEST apt-get >/dev/null; then
                # Debian/ubuntu
                [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ] || [ "/var/log/dpkg.log" -nt "$mycache" ]
                        return $?

Regards,
James

[Justin Coffman (jcoffman)]

I can confirm that this issue is present on CentOS 7 (via EPEL), Fedora 24/25, and Arch Linux (via AUR package). If you need data from any of these distros for this issue, please let me know.

[James Sinton (jksinton)]

Justin,
This seems to be a low priority bug. The debian/ubuntu issue is with the updated_needed() function in /usr/lib/byobu/updates_available. Specifically, here: https://github.com/dustinkirkland/byobu/blob/master/usr/lib/byobu/updates_available#L88

I suggest testing the next two elif blocks for Fedora and Arch Linux to see if those update needed checks need to be tweaked as well.
Regards,
James

[dAnjou (danjou)]

Can confirm the bug on Fedora 25 (see screenshot).

byobu version 5.115
tmux 2.2

[dAnjou (danjou)]

Addition to my comment above: I've uninstalled PackageKit because it was a resource hog. Would be nice to use something else for checking the update cache.

[jokrebel (jokrebel)]

Hi to all,

since I did a do-release-upgrade from Ubuntu LTS 14.04 to 16.04 LTS this bug reached me.

What i can not understand, why this should be only "low importance".
It is an very important status information, whether there are updates and/or reboots nessasary. That is an major reason for using byobu by many people i think!

Description: Ubuntu 16.04.2 LTS
Linux 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:28:22 UTC 2017 i686 i686 i686 GNU/Linux
Package: byobu
Priority: optional
Section: misc
Installed-Size: 639
Maintainer: Dustin Kirkland <email address hidden>
Architecture: all
Version: 5.106-0ubuntu1

[James Sinton (jksinton)]

Hey jokrebel et al.,

I've forked byobu on GitHub and provided a fix for Ubuntu:
https://github.com/jksinton/byobu

Caution: This fork should not be used as an alternative to the master byobu branch. I'm not keeping it up-to-date with other commits on the master branch. This fork merely provides a solution for this particular bug under Ubuntu 16.04.

dAnjou and Justin,

I don't have the resources or the availability to test CentOS, Fedora, and Arch Linux. But are either of you available to propose a fix for the update_needed() function and test it?
See https://github.com/jksinton/byobu/blob/master/usr/lib/byobu/updates_available#L80

If so, I will add those fixes to the fork of byobu, and hopefully they can be added to the master branch of byobu.

Thanks,
James

[jokrebel (jokrebel)]

Thanks https://launchpad.net/~jksinton.

But I would prefer an official soon fix.
I can not understand, why https://launchpad.net/~kirkland tells in #1 he is

"unable to reproduce this on Ubuntu 16.04"

and where he got (in July 2016!)

"byobu version 5.110" in this ubuntu version (can't be the ubuntu-version).

My Ubuntu is absolutely up to date has only
byobu version 5.106
tmux 2.1

[jokrebel (jokrebel)]

Ok, once again. Because I first didn't understand.
Seems to be fixed here with changeing Line 88 in /usr/lib/byobu/updates_available:

from (old):

[ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ]

to (new):

[ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ] || [ "/var/log/dpkg.log" -nt "$mycache" ]

good luck!

[jokrebel (jokrebel)]

[UPDATE:] ...sorry - seems not to work proper. (Or be the wrong workaround)

...after a few times it worked...

Just did 3 Updates, but the red "3!" for "Updates available" still in the bottom line :-(

Did update/full-upgrade for 3 more times. No Updates to do! But Byobu still claims it.

Any hints?
Thanks a lot

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[jokrebel (jokrebel)]

just trying with the PPA "sudo add-apt-repository ppa:byobu/ppa"

byobu -v
byobu version 5.118
tmux 2.1

...hope will do a better job at update notification

[jokrebel (jokrebel)]

Sorry. No good news. With byobu version 5.118 the problem still exists. Just did 3 Updates. Now I have:

Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

but in byobu still there is the red backgrounded "3!"

:-(

[James Sinton (jksinton)]

@jokrebel

As far as I can tell, nothing has been updated in 5.118 to address the updates available issue. See https://github.com/dustinkirkland/byobu/blob/master/usr/lib/byobu/updates_available#L86

I would not expect the latest version to fix this.

Can you try clearing the byobu cache related to the updates available and then test my proposed fix in updates_available?
https://github.com/jksinton/byobu/blob/master/usr/lib/byobu/updates_available#L90

As I mentioned above, you can clear the cache for screen implementations using commands similar to this:

rm /dev/shm/byobu-<user>-<XXXXXXXX>/cache.screen/updates-available
rm /dev/shm/byobu-<user>-<XXXXXXXX>/cache.screen/updates-available.lock

If you don't feel comfortable deleting the cache, just rename the files (e.g., mv updates-available updates-available.bak).

Use this command to find your particular cache files:
find /dev/shm -name 'updates-available*'

[Andreas Hasenack (ahasenack)]

I just tried today on a xenial long-running container that I have and there was one update available: vlan. byobu correctly flagged it with a red "1!" in the status bar after a few seconds.

I then upgraded (dist-upgrade), and a few seconds later (less than 10) then "1!" disappeared.

byobu 5.106-0ubuntu1

[jokrebel (jokrebel)]

@jksinton

I went back to byobu version 5.106 with tmux 2.1 and than tried your tip:

changed line 88 (as i tested before) into:
[ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ] || [ "/var/log/dpkg.log" -nt "$mycache" ]

and deleted /dev/shm/byobu-<user>-<XXXXXXX>/cache.tmux/updates-available*

suddenly the red "5!" disapeared.

Some time later, there was another 2 updates. I let them go with "sudo apt update&&sudo apt full-upgrade&&sudo apt-get autoremove" and the red note disappeared.

I was happy but wanted to wait one more test for posting here once again. And - what can I say; after a newly arrived update (3 for now) I did my job and installed it again with "sudo apt update&&sudo apt full-upgrade&&sudo apt-get autoremove". But the red "3!" is still there :-(

In /dev/shm/byobu-<user>-<XXXXXXX>/cache.tmux/ there is a updates-available and a updates-available-lock again. In the updates-available there stands "3 0". If I change it to "0 0" the red note goes away quick.

Do I have to clear or change it sometimes by hand from now on?

[David Britton (dpb)]

Hi @jokrebel --

I've also tried this on ubuntu Xenial and can't reproduce. Seems like it might be flaky for you. Until it gets clear reproduction steps in ubuntu, I'll mark it as incomplete. This is not saying it's not a problem, just that it lacks a clear way to reproduce (thus lacks a clear way for us to fix it in the distro).

Feel free to re-open if this situation changes.

Thanks!

[jokrebel (jokrebel)]

Thanks a lot for the time you all spent to try reproduce it.

it's not allways (not after each update that is aviailiable).

And yes, on other Ubuntu installations i own it has never happend to me too.
I have no idea what's going wrong with that 1 installation.
May be i get time and install the whole linux newly some day.

best regards and thanks for your work.
byobu is still great at all

[Mark Kelly (mckub1)]

I will confirm this happens to me sometimes also on 16.04 on several different machines.
I have debugged as well and will also confirm it has to do with the file dates and how long an update takes, so it is not easily reproducible. But the logic flow shows how it can happen.
I have patched the updates_available script as shown above to add the third check, thanks so much.
Before that I was thinking about having the update be done in a sub-script and at the end of that touch the cache file, so the sub-script would still run in the background but the cache file would get a more recent mod time.

[Mark Kelly (mckub1)]

Maybe this dbg output from updates_available helps reveal the issue:

___update_needed() entr 2017-04-19 17:57:22:332517641
___update_needed(): mycache = 2017-04-19 17:56:55:299087230
___update_needed(): /var/lib/apt = 2017-04-19 17:57:20:275457556
___update_needed(): /var/lib/apt/lists = 2017-04-19 17:56:48:442985575
------ mycache ^^^
1 0
------ mycache ###
___update_needed() exit 2017-04-19 17:57:22:335366171 (rc=0)
___update_cache() entr 2017-04-19 17:57:22:335890178
___update_cache() about to run update-notifier: 2017-04-19 17:56:55:299087230
--- mycache ^^^
1 0
--- mycache ###
flock -xn "/dev/shm/byobu-username-IPAtHq8s/cache.tmux/updates-available.lock" /usr/lib/update-notifier/apt-check 2>&1 | awk '-F;' 'END { print $1, $2 }' >"/dev/shm/byobu-username-IPAtHq8s/cache.tmux/updates-available" 2>/dev/null &
___update_cache() after running update-notifier (rc=0 pid=23482) in the background: 2017-04-19 17:57:22:331488041
---- mycache ^^^
---- mycache ###
___update_cache() exit 2017-04-19 17:57:22:343179552
___update_available() exit 2017-04-19 17:57:22:343674285
___update_available() entr 2017-04-19 17:57:29:349651054
___print_updates() entr 2017-04-19 17:57:29:350254352
----- mycache ^^^
1 0
----- mycache ###
___print_updates() exit 2017-04-19 17:57:29:351550685
___update_needed() entr 2017-04-19 17:57:29:352151300
___update_needed(): mycache = 2017-04-19 17:57:23:307502514
___update_needed(): /var/lib/apt = 2017-04-19 17:57:20:275457556
___update_needed(): /var/lib/apt/lists = 2017-04-19 17:56:48:442985575
------ mycache ^^^
1 0
------ mycache ###
___update_needed() exit 2017-04-19 17:57:29:356254254 (rc=1)
___update_available() exit 2017-04-19 17:57:29:356856277
___update_available() entr 2017-04-19 17:57:36:364345395
___print_updates() entr 2017-04-19 17:57:36:364951726
----- mycache ^^^
1 0
----- mycache ###

[jokrebel (jokrebel)]

Hi all,

just had the same temporarily problem occured at a ubuntu 17.10.

After "sudo apt update&&sudo apt full upgrade&& full-upgrade&&sudo apt autoremove"
byobu statusline shows me "53!" in red.
Same line called several more times tells me "... 0 nicht aktualisiert" but the red number does not disappear. At that PC even it is _not_ always so.

@Mark Kelly Did not find your patch "I have patched the updates_available script as shown above to add the third check, " or i misunderstood because my poor shool english

[jokrebel (jokrebel)]

[UPDATE] ...after about 10 more "sudo apt update&&sudo apt full upgrade&& full-upgrade&&sudo apt autoremove" the red number is gone

[Mark Kelly (mckub1)]

@jokrebel, hi

The patch I used is this: (changing one line)

# orig:
# [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ]
# new:
        [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ] || [ "/var/log/dpkg.log" -nt "$mycache" ]

So far with this change I have not seen the problem occur.
I was working on a different approach but this above is more simple.

[jokrebel (jokrebel)]

Hi once more,

in the /usr/lib/byobu/updates_available? I did this some days bevor.
I posted this in #15 an #16 but it solved the problem not.
It still occurs from time to time (not always)

but nevertheless thanks for your time

[Mark Kelly (mckub1)]

@jokrebel, hi
ok, sorry. I will post another patch soon and we can see if that helps fix it.

[Mark Kelly (mckub1)]

@jokrebel, hi
Just to confirm, do you have this file on your system ?

/usr/lib/update-notifier/apt-check

-thanks

[jokrebel (jokrebel)]

@mckub1 thanks once mor for your time. Yes there is a file:
lrwxrwxrwx 1 root root 12 Mär 28 00:36 apt-check -> apt_check.py

[Mark Kelly (mckub1)]

@jokrebel, hi
What is your status-interval set to (how many seconds between status bar updates) ?
When you still have a red 3! (or whatever the number) after an upgrade - can you press the F5 key a few times to see if the red 3! update goes away ?
The additional check for if the cache file is newer than /var/log/dpkg.log at the next status update cycle should cause update_cache() to run again and this should be after the update has completed and thus should echo a "0 0" to the cache file and the red 3! to go away.

[jokrebel (jokrebel)]

@mckub1

Hi once more,

first thanks a lot for your interest on my problem. After some new updates on several installations now i can tell some more.

i never changed the setting of the interval (don't even know where i could). Think it should be something between 1 an 3 seconds (looks like).

On my 16.04 Laptop it just cleared it for once at the last time.
But not on the other machine with the 17.10.
On the same old PC at a 16.04 partition it cleared not until a "apt-get autoremove" (random?)

Pressing F5 is unfortunately not clearing the shown <number>!
(which is no more correct after had done the full-upgrade).

You told "...it has to do with the file dates and how long an update takes,..".
May be its helpful to tell that for me it only occures some time on older slower PC.
And after a reboot it seems to be always cleared.

[jokrebel (jokrebel)]

[Update] just occured on a third not quite as old computer (core2) with a siduction64 linux.
3 times update/full-upgrade did not clear the wrong "214!" (had to be "0" after the first time). It cleared after starting "apt autoremove"

[Mark Kelly (mckub1)]

After a few weeks of use, I have to say the fix -

    [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ] || [ "/var/log/dpkg.log" -nt "$mycache" ]

to the /usr/lib/byobu/updates_available script has worked well for me on two different systems (both Ubuntu 16.04 with HWE).
After an apt-get upgrade the notification is sometimes still there - but hitting a few F5's (boybu status updates) or waiting until the status update runs again always clears the notification.

Until you solve it you don't need to reboot, you can simply remove the cache file to clear the notification with -

rm $BYOBU_RUN_DIR/cache.tmux/updates-available

[Mark Kelly (mckub1)]

PS - I set my status interval with a setting in my ~/.byobu/.tmux.conf file -

set -g status-interval 10

[James Sinton (jksinton)]

@mckub1 I've been running the proposed fix for Ubuntu for about 7 months now. I've only seen it fail to update the updates_available value once during an upgrade. The failure with the proposed fix was running under a virtual instance of Ubuntu on my MacBook Pro (13-inch, Late 2016), which screamed through an upgrade. However, I have not seen such a failure since, and clearing the cache manually always fixes it.

In general, this issue requires a special race condition to reproduce, since some system configuration are not experiencing it. My older server, which runs on a quad-core AMD Phenom II, was the first to exhibit the issue of failing to update the updates_available value.

[Mark Kelly (mckub1)]

With the proposed fix, today my status bar showed a 1! and after an update && upgrade, for the first time in a while the 1! is still present.

[jokrebel (jokrebel)]

Hello again,

since I do "sudo apt update && sudo apt full-upgrade && sudo apt autoremove" and then first wait at least 1 minute _before_ I press the "y" for start it, the bug did no more occur for me.

Not a solution - but a workaround ;-)

HTH
jokrebel

[Mark Kelly (mckub1)]

Hi,

Thanks. I have had it happen only two times in a few months after that
patch fix, so like you it still happens but I put up with it and didn't
bother to spend time to fix for sure.
But yes it is a 'timing' issue and the script should do something like loop
and re-check for when dpkg.log does not change etc before returning.

take care,
mark

On Sat, Nov 11, 2017 at 2:54 AM jokrebel <email address hidden> wrote:

> Hello again,
>
> since I do "sudo apt update && sudo apt full-upgrade && sudo apt
> autoremove" and then first wait at least 1 minute _before_ I press the
> "y" for start it, the bug did no more occur for me.
>
> Not a solution - but a workaround ;-)
>
> HTH
> jokrebel
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Incomplete
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[jokrebel (jokrebel)]

Hi again,

error still happens on different distros randomly. The workaround to wait some time after
"apt update && apt full-upgrade"
bevor pressing "y" (for getting it go) works mostly but also not allways.

If not; my dirty workaround for the workaround *urks* if the red "!xy" notfication still there:
...do for example a

"sudo apt install --reinstall weechat-devel-ruby" (or an other small pakage)

best regards
jokrebel

[Mark Kelly (mckub1)]

Hi,

Happy New Year to you.
Yes, thx, I agree, I have seen it happen a few times myself and some apt
cmds get it to resolve.
If I find some time I will try to look at it more, it is annoying.

take care,

On Sun, Jan 7, 2018 at 4:55 AM jokrebel <email address hidden> wrote:

> Hi again,
>
> error still happens on different distros randomly. The workaround to wait
> some time after
> "apt update && apt full-upgrade"
> bevor pressing "y" (for getting it go) works mostly but also not allways.
>
> If not; my dirty workaround for the workaround *urks* if the red "!xy"
> notfication still there:
> ...do for example a
>
> "sudo apt install --reinstall weechat-devel-ruby" (or an other
> small pakage)
>
> best regards
> jokrebel
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[Mark Kelly (mckub1)]

Hi,

I think the easiest work-around is to remove the cache file -

rm -f $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available

-mark

On Sun, Jan 7, 2018 at 8:54 AM M Kelly <email address hidden> wrote:

> Hi,
>
> Happy New Year to you.
> Yes, thx, I agree, I have seen it happen a few times myself and some apt
> cmds get it to resolve.
> If I find some time I will try to look at it more, it is annoying.
>
> take care,
>
> On Sun, Jan 7, 2018 at 4:55 AM jokrebel <email address hidden>
> wrote:
>
>> Hi again,
>>
>> error still happens on different distros randomly. The workaround to wait
>> some time after
>> "apt update && apt full-upgrade"
>> bevor pressing "y" (for getting it go) works mostly but also not allways.
>>
>> If not; my dirty workaround for the workaround *urks* if the red "!xy"
>> notfication still there:
>> ...do for example a
>>
>> "sudo apt install --reinstall weechat-devel-ruby" (or an other
>> small pakage)
>>
>> best regards
>> jokrebel
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1604750
>>
>> Title:
>> Byobu not clearing update numbers after updates
>>
>> Status in byobu:
>> Confirmed
>> Status in byobu package in Ubuntu:
>> Confirmed
>> Status in Fedora:
>> New
>>
>> Bug description:
>> I am running byobu on Debian Testing and, as of the last week or two,
>> byobu has started not clearing the update counter even after updates.
>> Even exiting byobu completely and starting a new session does not
>> clear the indicator, only updating do it. Sometimes, and this is not
>> consistent, running an `apt-get update` causes the indicator to clear
>> itself.
>>
>> ~$ uanme -a
>> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
>> GNU/Linux
>> ~$ byobu -v
>> byobu version 5.87
>> Screen version 4.04.00 (GNU) 19-Jun-16
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>>
>

[bsy (bennet-yee)]

for apt, why not use something like apt list --upgradeable | wc -l to determine whether updates are needed / the number of upgradeable packages? apt list output is not stable yet, but should be soon, one hopes.

[Mark Kelly (mckub1)]

Hi,

Q: when the status bar incorrectly shows 2! (or whatever the count is) when
you know there are no more updates to do, does your updates-available cache
file show "2 2" or "0 0" ?
The cache file is located in:

BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available

-mark

On Fri, Jan 19, 2018 at 8:37 PM M Kelly <email address hidden> wrote:

> Hi,
>
> I think the easiest work-around is to remove the cache file -
>
> rm -f $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available
>
> -mark
>
> On Sun, Jan 7, 2018 at 8:54 AM M Kelly <email address hidden> wrote:
>
>> Hi,
>>
>> Happy New Year to you.
>> Yes, thx, I agree, I have seen it happen a few times myself and some apt
>> cmds get it to resolve.
>> If I find some time I will try to look at it more, it is annoying.
>>
>> take care,
>>
>> On Sun, Jan 7, 2018 at 4:55 AM jokrebel <email address hidden>
>> wrote:
>>
>>> Hi again,
>>>
>>> error still happens on different distros randomly. The workaround to
>>> wait some time after
>>> "apt update && apt full-upgrade"
>>> bevor pressing "y" (for getting it go) works mostly but also not allways.
>>>
>>> If not; my dirty workaround for the workaround *urks* if the red "!xy"
>>> notfication still there:
>>> ...do for example a
>>>
>>> "sudo apt install --reinstall weechat-devel-ruby" (or an other
>>> small pakage)
>>>
>>> best regards
>>> jokrebel
>>>
>>> --
>>> You received this bug notification because you are subscribed to the bug
>>> report.
>>> https://bugs.launchpad.net/bugs/1604750
>>>
>>> Title:
>>> Byobu not clearing update numbers after updates
>>>
>>> Status in byobu:
>>> Confirmed
>>> Status in byobu package in Ubuntu:
>>> Confirmed
>>> Status in Fedora:
>>> New
>>>
>>> Bug description:
>>> I am running byobu on Debian Testing and, as of the last week or two,
>>> byobu has started not clearing the update counter even after updates.
>>> Even exiting byobu completely and starting a new session does not
>>> clear the indicator, only updating do it. Sometimes, and this is not
>>> consistent, running an `apt-get update` causes the indicator to clear
>>> itself.
>>>
>>> ~$ uanme -a
>>> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04)
>>> x86_64 GNU/Linux
>>> ~$ byobu -v
>>> byobu version 5.87
>>> Screen version 4.04.00 (GNU) 19-Jun-16
>>>
>>> To manage notifications about this bug go to:
>>> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>>>
>>

[Mark Kelly (mckub1)]

Hi,

Yes, good idea, thanks for that info.

-mark

On Thu, Jan 25, 2018 at 1:05 PM bsy <email address hidden> wrote:

> for apt, why not use something like apt list --upgradeable | wc -l to
> determine whether updates are needed / the number of upgradeable
> packages? apt list output is not stable yet, but should be soon, one
> hopes.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "updates_available.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[jokrebel (jokrebel)]

Sorry for a noob question. I have no idea how to use that "updates_available.patch" out of post #52 - for me that file is only a cryptical unreadable (maybe) code. Would be nice to get a guide how and where to place/add/whatever

thanks a lot for your work again

[Mark Kelly (mckub1)]

Hi.
Either of 1). or 2) will do it -

1). save complete updates_available file in post #50 then do:
    a). cd /usr/lib/byobu
    b). sudo cp updates_available updates_available.orig
    c). save the new updates_available file from post #50 here
    d). sudo chmod 755 updates_available

or using patch file -

2). save patch file from post #52
    a). cd /usr/lib/byobu
    b). save updates_available.patch from post #52 here
    c). run patch cmd with it -
           sudo patch < updates_available.patch

The bottom line is there are only two lines different to change from the original file.
And either method above should work.

Thank you for trying/testing. Let me know if it improves the issue.

[jokrebel (jokrebel)]

Hello again,

tryed Way 2 but got:

sudo patch < updates_available.patch
patching file updates_available
Hunk #1 FAILED at 50.
Hunk #2 FAILED at 85.
2 out of 2 hunks FAILED -- saving rejects to file updates_available.rej
 :/

[Mark Kelly (mckub1)]

Hi,
The patch method expects the updates_available file is in its original condition and to be the same as mine. Have you modified it before this or perhaps its older or from a different version of byobu/Ubuntu ? If so that is probably the reason it failed.
Which is why I also posted the complete updates_available file in post #50, so that it could be saved and used as is.

But also here are the 2 differences I made to the file if you make the changes by hand:

at line 53 -
orig:

    flock -xn "$flock" /usr/lib/update-notifier/apt-check 2>&1 | awk '-F;' 'END { print $1, $2 }' >"$mycache" 2>/dev/null &

changes to:

    flock -xn "$flock" sh -c "(rm -f \"$mycache\" ; /usr/lib/update-notifier/apt-check 2>&1 | awk '-F;' 'END { print \$1, \$2 }' >\"${mycache}-x\" 2>/dev/null ; sleep 5 ; mv \"${mycache}-x\" \"$mycache\") &"

at line 88 -

orig:

    [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ]

changes to:

    [ "/var/lib/apt" -nt "$mycache" ] || [ "/var/lib/apt/lists" -nt "$mycache" ] || [ "/var/log/dpkg.log" -nt "$mycache" ]

(this line 88 change was made a long time ago as mentioned above)

NOTE: both these changes are each a single line - the above may have shown up as multiple lines, but they are really each a long single line.

hth

[jokrebel (jokrebel)]

Thanks again for your time :-)

yes, I did some modifications (see the older posts from me in this thread since May 2017) hoping to get a fix for the problem which is only sometimes occurring!

for now i put Your

1.) updates_available file from #50 into /usr/lib/byobu (after backuo the old) and than did
2.) sudo chmod 755 updates_available

I am looking forward to a hopefull better future and will give a feedback after a few updates
(Remember; the error does not always occur)

best regards

[jokrebel (jokrebel)]

Sorry, bad news

after 3 updates where the counter went away immediately the 4th failed :-(

There is still a red " 6!" after 2 "sudo apt update&&sudo apt full-upgrade&&sudo apt autoremove" that tells "0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert."

After doing a "sudo apt install --reinstall weechat-devel-ruby" and wait some seconds the update-available counter got cleared.

sad to have to tell that

[Mark Kelly (mckub1)]

Hi,

It's ok - I learned something from this and I will keep going and
eventually solve :-)
Next time it happens, before you issue the --reinstall command, can you
check the cache file and tell
me if it has the 2 2 (or whatever the number your status shows) or a 0 0 in
it ?
I want to see if the status file was updated or if it is just the date of
the file causing it to not be re-read.

thanks,
mark

On Sat, Feb 3, 2018 at 12:39 PM jokrebel <email address hidden> wrote:

> Sorry, bad news
>
> after 3 updates where the counter went away immediately the 4th failed
> :-(
>
> There is still a red " 6!" after 2 "sudo apt update&&sudo apt full-
> upgrade&&sudo apt autoremove" that tells "0 aktualisiert, 0 neu
> installiert, 0 zu entfernen und 0 nicht aktualisiert."
>
> After doing a "sudo apt install --reinstall weechat-devel-ruby" and wait
> some seconds the update-available counter got cleared.
>
> sad to have to tell that
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[jokrebel (jokrebel)]

Hi again,

"Next time it happens, before you issue the --reinstall command, can you check the cache file and tell me if it has the 2 2 (or whatever the number your status shows) or a 0 0 in it ?"

of cause i will do, but can you tell me exactly the name of the file and the path where to find?

thanks a lot

[Mark Kelly (mckub1)]

Hi,

Yes, the cache file is at:

$BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available

-mark

On Mon, Feb 5, 2018 at 1:29 AM jokrebel <email address hidden> wrote:

> Hi again,
>
> "Next time it happens, before you issue the --reinstall command, can you
> check the cache file and tell me if it has the 2 2 (or whatever the
> number your status shows) or a 0 0 in it ?"
>
> of cause i will do, but can you tell me exactly the name of the file and
> the path where to find?
>
> thanks a lot
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[Mark Kelly (mckub1)]

Hi,

Can you verify you have this file ?

 /usr/lib/update-notifier/apt-check

The extra logic I added was only for when this file is on your system and I
just want to confirm if this is true for you.

thanks,
-mark

On Mon, Feb 5, 2018 at 7:31 PM M Kelly <email address hidden> wrote:

> Hi,
>
> Yes, the cache file is at:
>
> $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available
>
> -mark
>
> On Mon, Feb 5, 2018 at 1:29 AM jokrebel <email address hidden>
> wrote:
>
>> Hi again,
>>
>> "Next time it happens, before you issue the --reinstall command, can you
>> check the cache file and tell me if it has the 2 2 (or whatever the
>> number your status shows) or a 0 0 in it ?"
>>
>> of cause i will do, but can you tell me exactly the name of the file and
>> the path where to find?
>>
>> thanks a lot
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1604750
>>
>> Title:
>> Byobu not clearing update numbers after updates
>>
>> Status in byobu:
>> Confirmed
>> Status in byobu package in Ubuntu:
>> Confirmed
>> Status in Fedora:
>> New
>>
>> Bug description:
>> I am running byobu on Debian Testing and, as of the last week or two,
>> byobu has started not clearing the update counter even after updates.
>> Even exiting byobu completely and starting a new session does not
>> clear the indicator, only updating do it. Sometimes, and this is not
>> consistent, running an `apt-get update` causes the indicator to clear
>> itself.
>>
>> ~$ uanme -a
>> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
>> GNU/Linux
>> ~$ byobu -v
>> byobu version 5.87
>> Screen version 4.04.00 (GNU) 19-Jun-16
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>>
>

[jokrebel (jokrebel)]

Hi Mark,

yes - there is a file /usr/lib/update-notifier/apt-check

but where/how to check the cache file when it will occur next time i got no idea with your line

$BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available

The most used computer over mosh/ssh with byobu and exclusively updated over that is a ubuntu 16.04 LTS (if this information is necessary)

Thanks again for all your work

[Mark Kelly (mckub1)]

Hi,

I would just cat that file, as in:

cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available

On my system this is what it I do:

% cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available
0 0

So I can see the file has just "0 0" in it at this moment.

You could also use less, more, nano, vi, emacs, etc. - any utility to view
the file contents.
Also do this as you, you do not need to use sudo.

thanks,
mark

On Tue, Feb 6, 2018 at 11:05 AM jokrebel <email address hidden> wrote:

> Hi Mark,
>
> yes - there is a file /usr/lib/update-notifier/apt-check
>
> but where/how to check the cache file when it will occur next time i got
> no idea with your line
>
> $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available
>
> The most used computer over mosh/ssh with byobu and exclusively updated
> over that is a ubuntu 16.04 LTS (if this information is necessary)
>
> Thanks again for all your work
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[jokrebel (jokrebel)]

good morning,

thanks for your detailed explanation.

It just occured again. Before and also afterwards i got a 7 1 after using
cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available

have a nice day

[Mark Kelly (mckub1)]

Hi,

Just to be complete, for example, my system shows a 4! in red this morning.
My cache file shows 4 1
I do an:
sudo apt-get update
sudo apt-get upgrade
and then for about 5 seconds my cache file still shows 4 1 and the red 4!,
but after 5 seconds it automatically changes to 0 0 and the Red 4! goes
away.

But when it happens to you - the cache file stays at 7 1 forever or
until you issue a:
sudo apt-get --reinstall ....

Is that right ?

thanks,
mark

On Wed, Feb 7, 2018 at 1:35 AM jokrebel <email address hidden> wrote:

> good morning,
>
> thanks for your detailed explanation.
>
> It just occured again. Before and also afterwards i got a 7 1
> after using
> cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available
>
> have a nice day
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[jokrebel (jokrebel)]

Yes, you are right i think (my english is not so good)

1) there was a red 7!! in the bottom line
2) I checked "cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available" and got "7 1"
3) did "sudo apt update && sudo apt full-upgrade && sudo apt autoremove" (apt tells all 0)
4) waited a few minutes (red 7!! still there and went not away)
5) checked "cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available" again and still got "7 1"
6) did 3) 4) 5) again with same results
7) did "sudo apt install --reinstall weechat-devel-ruby"
8) about 5 seconds later the red 7!! disappeared and
9) "cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available" now tells "0 0"

hope now to have been exactly enough

[jokrebel (jokrebel)]

Just confirmed the same issue at an other machine with actual siduction

after "update && full-upgrade" still got red "93!" in the byobu panel

update once more did not clear it.

"cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available" tells "93"

hope to help for findig the problem

[Mark Kelly (mckub1)]

Hi,

Yes it helped thanks. Thinking on it.

-mark

On Sat, Feb 10, 2018, 8:54 AM jokrebel <email address hidden> wrote:

> Just confirmed the same issue at an other machine with actual siduction
>
> after "update && full-upgrade" still got red "93!" in the byobu panel
>
> update once more did not clear it.
>
> "cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available" tells "93"
>
> hope to help for findig the problem
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1604750
>
> Title:
> Byobu not clearing update numbers after updates
>
> Status in byobu:
> Confirmed
> Status in byobu package in Ubuntu:
> Confirmed
> Status in Fedora:
> New
>
> Bug description:
> I am running byobu on Debian Testing and, as of the last week or two,
> byobu has started not clearing the update counter even after updates.
> Even exiting byobu completely and starting a new session does not
> clear the indicator, only updating do it. Sometimes, and this is not
> consistent, running an `apt-get update` causes the indicator to clear
> itself.
>
> ~$ uanme -a
> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
> GNU/Linux
> ~$ byobu -v
> byobu version 5.87
> Screen version 4.04.00 (GNU) 19-Jun-16
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>

[Mark Kelly (mckub1)]

Hi,

I've got a fix :-)
Let me test it more tomorrow and then I'll post a new updates_available
script

-mark

On Sat, Feb 10, 2018 at 9:00 AM M Kelly <email address hidden> wrote:

> Hi,
>
> Yes it helped thanks. Thinking on it.
>
> -mark
>
> On Sat, Feb 10, 2018, 8:54 AM jokrebel <email address hidden> wrote:
>
>> Just confirmed the same issue at an other machine with actual siduction
>>
>> after "update && full-upgrade" still got red "93!" in the byobu panel
>>
>> update once more did not clear it.
>>
>> "cat $BYOBU_RUN_DIR/cache.$BYOBU_BACKEND/updates-available" tells "93"
>>
>> hope to help for findig the problem
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1604750
>>
>> Title:
>> Byobu not clearing update numbers after updates
>>
>> Status in byobu:
>> Confirmed
>> Status in byobu package in Ubuntu:
>> Confirmed
>> Status in Fedora:
>> New
>>
>> Bug description:
>> I am running byobu on Debian Testing and, as of the last week or two,
>> byobu has started not clearing the update counter even after updates.
>> Even exiting byobu completely and starting a new session does not
>> clear the indicator, only updating do it. Sometimes, and this is not
>> consistent, running an `apt-get update` causes the indicator to clear
>> itself.
>>
>> ~$ uanme -a
>> Linux enekk 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
>> GNU/Linux
>> ~$ byobu -v
>> byobu version 5.87
>> Screen version 4.04.00 (GNU) 19-Jun-16
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/byobu/+bug/1604750/+subscriptions
>>
>

[Mark Kelly (mckub1)]

Hi,

Attached is another update. This one adds an additional time check to run the update_cache once an hour. Save it to /usr/lib/byobu/updates_available, and make sure it is executable, just like before.
    a). cd /usr/lib/byobu
    b). cp/save the new updates_available file you downloaded into this dir
    c). sudo chmod 755 updates_available
thx

[jokrebel (jokrebel)]

OK - then the next try with #73 file ....

the one before (you deleted it?) worked for 7 times and failed just today at the 8th try/update

[jokrebel (jokrebel)]

...just for now a status report:

worked fine for 10 updates - no fault :-) ... I hope it stays that way

thanks for the work
jokrebel

[Mark Kelly (mckub1)]

Hi,
Any update ? I have not had the problem now for about a month.
I hope its ok with you also ?
-mark

[jokrebel (jokrebel)]

Hi and thanks; great work!

didn't occur for about 20 updates till now. Looks fine :-)

[the "updates_available" from post #73 seems to do the best job]

best regards
Achim

[Mark Kelly (mckub1)]

Hi,
I have not seen the problem for a while now.
Is it still ok with you ?
take care,
-mark

[jokrebel (jokrebel)]

All fine ;-) since I put in the update_available from #73 into my /usr/lib/byobu the problem seems ti be fixed (at that system i have done that ;-)

greate Work! And release it to all you can do as quick as possible.

For now is si noct even in Debian Sid i think

best regards
jokrebel

[Mark Kelly (mckub1)]

Hi,

Awesome. I submitted a pull request for this on GitHub:

https://github.com/dustinkirkland/byobu/pull/26

Perhaps Dustin will see it and use it, or make another fix/change in his own words.

thx so much for byobu and everyone's help,
-mark

[Mark Kelly (mckub1)]

It was merged and will appear in byobu 5.126

[Andreas Hasenack (ahasenack)]

5.126 is in cosmic, marking this bug as fix released.