Child Item

Dropbox is looking for deprecated package

Every time when I run Dropbox next message appear

'python-gpgme' package was interface to the gpgme before Ubuntu 17.10. From Ubuntu 17.10 (up to present) 'python-gpgme' is deprecated in favor of 'python-gpg' ('python3-gpg' for python 3). Currently 'python-gpgme' is no more in Ubuntu repositories!

Probably this is small mistake (forgotten package name) need to be corrected. Everything else works. Please forward the bug note to your technical team. This dummy message is really annoying and the checkbox 'Don't show this again' don't work.

Thanks in advance.

Find more posts tagged with

Setting Up the Apps

Desktop

Linux

Spam

Insightful

Accepted answers

Здравко

@Rich wrote:
Have you opened a ticket with Support?

Hi @Rich,

I suppose this have to be the funny part...

Just example of such ticket can be seen here. In this context, what I can rely on?! It's the same - here (in the forum with 'a few Dropboxers') or through a ticket. Very often users meet the same problem and can give more valuable advice. That's why I prefer to write here. In this thread I ask for technical support, not PR. If someone from the Dropboxers want, can forward all this to technical team (or at least the bug description). If not, ...

Anyway... Thanks for Your advice! I appreciate Your try to help.

I found a workaround (until the moment, if any, when this bug become fixed). Just introducing delay in running process, so more system resources are available and triggering the bug become less likely (in my case, till the moment, didn't happen). I implement this using a script like:

#!/bin/bash
sleep XXX

Where 'XXX' is carefully selected delay (in seconds), so heavy load time span to be jump over. It works for me. If someone else meet same problem can try this.

All comments

Здравко

Ooo... I found out what's wrong.

My dropbox installer package wasn't up to date. In the latest one this seems fixed.

In this context one next question: Why two package management systems have to be used? One for the installer (and runner) - the system one and another for the application managed by self. Isn't possible only one to be used? So (using single package) no version mistake could be possible (or less probable at least). My preference is - system management. Would be possible such thing to happen someday?

Здравко

No exactly fixed!

Yes, There is no more "Note" for deprecated package, but from time to time message asking me to "download the proprietary daemon" still appear: изображение.png

Both the installer package and the application are up to date (2019.02.14 and v69.4.102 accordingly). This dummy message is generated from installer package and not always, but from time to time. Any idea why this happens? And again, the previous question, why one application need two part from two completely different repositories? (The message erroneous ask for fetching application part from the second repository!!! This is already done before!)

Здравко

Like in many other cases, seems nobody can say anything (from Dropbox side)!

I think, It's stupid decision to conclude that dropbox isn't installed if there is some problem running it (even erroneously detected problem). I mean the code near line 1440 in 'dropbox':

    if not start_dropbox():
        if not should_install:
            console_print()
            console_print("The Dropbox daemon is not installed!")
            console_print("Run \"dropbox start -i\" to install the daemon")
            return

        # install dropbox!!!
        try:
            download()
        except:
            traceback.print_exc()

From other view point, in 'start_dropbox' function, near line 760 in the same file:

        # in seconds
        interval = 0.5
        wait_for = 60
        for _ in range(int(wait_for / interval)):
            if is_dropbox_running():
                return True
            # back off from connect for a while
            time.sleep(interval)

        return False

Can be seen that decision for successful running depends on 'is_dropbox_running' function result. This function result from other side depends on matching pid, set on time in '~/.dropbox/dropbox.pid', as can be seen near line 140 in the same file:

def is_dropbox_running():
    pidfile = os.path.expanduser("~/.dropbox/dropbox.pid")

    try:
        with open(pidfile, "r") as f:
            pid = int(f.read())
        with open("/proc/%d/cmdline" % pid, "r") as f:
            cmdline = f.read().lower()
    except:
        cmdline = ""

    return "dropbox" in cmdline

And here is the place where the problem comes from. On heavy loaded system, during initial login, many other services can query for processor time and disk access simultaneously, together with Dropbox! Additionally open web browser left from previous session, carrying few tenths of pages, and other similar applications can query together system resources. In such a situation setting correct pid can take some time. During all this time 'is_dropbox_running' function will think that the Dropbox is NOT running, even while it really runs (or at least going to, without totally finished initialization still)! The 'start_dropbox' function assumes the same, next some timeout. And finally, as result, follows stupid conclusion that Dropbox is not installed (erroneous)! The same erroneous conclusion (and initiating install action) could be triggered by virtually any runtime error in the daemon, during initialization (even incident one, non related in any way to the installation process)!

The easiest and fastest workaround is timeout set to be increased (for example doubled). Of course such action is definitely not a solution because there is no exact answer "How much?"! Real solution would be the chain of assumptions break. Wich mean restructuring the code and write it without assumption that something is, if there could be opposite situation (even when such situation seems not likely). If You don't follow above rule lead to error prone code (error - including race conditions and not only).

Again, please forward this to your technical team. I hope it will help improving Your code.

Здравко

Another good solution could be little modification in the daemon on next update (yes, in the daemon not the starter).

Now when the checkbox 'Start Dropbox on system startup' is checked, created launcher is exact copy of main program menu launcher (in the command line - including '-i' option). This is meaningless because the application (already installed, of course!), in such a way, is querying to be installed again during next login!?!... The only result is the noted message. This '-i' option is meaningful only in main program menu launcher (or in console). If the '-i' option is striped from autorun launcher discused bug will still exist but will stay without visible 'symptoms'.

Rich

@Здравко wrote:
Like in many other cases, seems nobody can say anything (from Dropbox side)!

Have you opened a ticket with Support?

This is primarily a user-supported forum. While there are a few Dropboxers here, they aren't part of the client team. You'll need to open a ticket with Support if you need a response to this, or post in the release thread for the specific version that you're having a problem with.

Open your ticket here: https://dropbox.com/support
Track your ticket here: https://dropbox.zendesk.com

Replies take approximately 1 - 3 business days with Plus, Professional and Business users getting priority (longer for Basic users).

Здравко

@Rich wrote:
Have you opened a ticket with Support?

Hi @Rich,

I suppose this have to be the funny part...

Anyway... Thanks for Your advice! I appreciate Your try to help.

#!/bin/bash
sleep XXX

Where 'XXX' is carefully selected delay (in seconds), so heavy load time span to be jump over. It works for me. If someone else meet same problem can try this.

nocibambi

Thanks for this, and also for the great investigation!

However, I am not sure about having your workaround accepted. This just makes this issue hidden from the support team...

Здравко

Hi @nocibambi,

No, no... It don't make this issue hidden for support team. Every one post on any one thread (including mark as accepted) is on support team attention. Another story is the processing level provided from this "support team" (just PR staff). Like many other things, probably this issue never reached (and will never reach) technical staff attention, unfortunately. Seems just company politics...