Your system is up to date. (Solved)

[CaptSaltyJack]

What makes you think the Ubuntu update manager's notification is immediate?

It is near immediate in my experiences. At least within 30-60 minutes. Mint never seems to know without having to put the update manager in root mode by clicking on it once. The thing is, the Ubuntu update-notifier doesn't have to be run in root mode first in order for it to be aware of package updates... it just somehow knows.

My point, and my question is, why not just use Ubuntu's update-notifier in Mint? Ooh, I just realized I can install update-notifier via APT. I'm gonna try that and see how that works out. Your suggestion to add "apt-get update 2> /dev/null" to an hourly cron is a good idea and it works, but I feel this should work out of the box, ideally.

[CaptSaltyJack]

Ooh, I just realized I can install update-notifier via APT. I'm gonna try that and see how that works out.

Well. That did not work out so well.. bleh.

[clem]

As far as I know it relies on aptd.... which is extremely unstable, poorly documented, changes a lot from release to release and extremely tied with Ubuntu itself (<-- this is my personal opinion of course). We're using it in the Software Manager, and although, to you, things seem to work fine, it's a constant struggle for us to maintain release after release. What we could do, is a best effort option... i.e. a loose-couple between mintupdate and aptd... if it works then you gain better notifications, if it doesn't it just discreetly logs it and you're not affected by the failure. Just thinking loud here...

[viking777]

i.e. a loose-couple between mintupdate and aptd

But if the idea of an 'instant-on' mintupdate actually appeals to you then what is wrong with the cron route? I know I only instigated it on my system yesterday and 2 days evidence is not much to go on - tomorrow it might fail, but so far it hasn't.

My complete solution was a root crontab entry like this:

@reboot sleep 10 && apt-get update && rm -f /var/cache/apt/archives/lock > /dev/null

Coupled with a delay in Mintupdate/Preferences/Update Method/Start up delay 120sec (when I put this back to the default - 10sec I think - it stopped working)

I thought this would be enough but it wasn't, so I had to also introduce a start up delay to the actual boot of Mintupdate. In my case that is easy since I use the Fluxbox desktop by default, not Gnome, so

Code: Select all

sleep 30 && /usr/lib/linuxmint/mintUpdate/mintUpdate.py &

In ~/.fluxbox/startup

Is all I needed.

In Gnome/KDE it is not quite as easy, I guess you have to create a .desktop file with the delay written into it and put it in ~/.config/Autostart, but I am sure you know a lot more about that than I do.

The various delays may or may not all be necessary and you could certainly experiment with the timing of them. It might also seem that I am going to wait a long time for mintupdate to appear, but in fact that doesn't happen, pretty well as soon as my desktop has finished loading, mintupdate starts and straight away searches for updates. Since the apt cache is refreshed and the lock file is removed, if there are any it will display them and show the symbol and if there aren't it displays the tick.

I repeat two days evidence it not much to go on and it might not be that important to you anyway, but I repeat the procedure in detail here for those for whom such functionality is important.

[CaptSaltyJack]

As far as I know it relies on aptd.... which is extremely unstable, poorly documented, changes a lot from release to release and extremely tied with Ubuntu itself (<-- this is my personal opinion of course). We're using it in the Software Manager, and although, to you, things seem to work fine, it's a constant struggle for us to maintain release after release. What we could do, is a best effort option... i.e. a loose-couple between mintupdate and aptd... if it works then you gain better notifications, if it doesn't it just discreetly logs it and you're not affected by the failure. Just thinking loud here...

I'm not a super hardcore Linux guy, so I can't really advise technically how I think it should work. I can tell you, from a user standpoint, though, that I think ideally it would work like this:

1) Upon system boot (or user login), an automatic check for updates is run, and the user is notified accordingly.
2) After that, every hour (or so - maybe user-definable?) automatic checks are made for updates.

I'd say #1 is more important than #2. For #2, it could really be as spaced out as 3-6 hours. For me, what is more important is after a fresh login, I'm notified if there's something new I should grab. If I leave my workstation on (but locked) 24/7, then case #2 will kick in and when I come back to my computer in the morning, there will be a notification there.

[viking777]

On the off chance that anybody is interested in my musings on this topic I have another little update. It is not easy to work on this problem because I have to keep waiting for updates to be available and that may only happen once a day even on LMDE. However the following appears to be relevant.

The 30 second sleep delay I applied to the startup of mintupdate.py is enough most of the time and the system works. However on occasions I still get the 'Apt is in use' warning. If you think about it, the reason is pretty obvious, the time taken for cron to perform the apt-get update is dependant on a lot of factors - how busy my isp is, how busy the update server is, whether or not the update command has produced an error message that might stall it. So you cant always expect the update command to be finished before mintupdate starts, if it isn't finished you get the warning. I have increased the delay to 45 seconds now and it hasn't failed yet. To me it represents a big improvement over the default behaviour and it actually makes mintupdate worth autostarting. If you are going to autostart it and then have to run it manually you might as well use synaptic.

Btw. If you do get the 'Apt is in use' error all you have to do is to right click the tray icon and select 'refresh' and it will then work.

[mauromol]

In terms of reliability and rationale, it's not important that an available update appear "immediately". What's important though, is that mintupdate list all available updates in a consistent manner... so for instance, if there's a particular update listed by Synaptic that doesn't appear in MintUpdate that should be considered a bug and we should find the cause for it. If that's the case, please give me as much info as you can, logs, apt policy for the package, versions, etc..

Hi Clem,
I'm new to Linux Mint. I recently installed Linux Mint 10 KDE and I have the problem described at:
viewtopic.php?f=90&t=77045

In summary, I have installed Opera through the Software Manager. The installed version is 10.62.6438. After solving a problem with a key to verify signatures (as explained here: http://my.opera.com/desktopteam/blog/20 ... lse-on-a-d - I followed the instructions to just update the key, not to update the package), the Update Manager is working fine again. However, running Synaptic I see that version 11.50.1074 of Opera would be available, while the Update Manager doesn't show it, even if I refresh it manually.
I already checked that:

• the update is not a hidden update (level 4 or 5)
• the software source for Opera stable releases is listed and checked in the Update Manager options
• it is not a stale cache problem, since the Update Manager is run as root, I force a manual refresh, I issued an "apt-get update" and Synaptic is correctly showing me the update

What could be the problem? And, second question: why the Software Manager originally installed version 10.62.6438 instead of the latest one (11.50.1074)?