Description of problem: On Dropbox's last attempt to update itself, it failed because it couldn't find libatomic.so.1. The only other package dependent on the library is google-chrome-stable, which is often installed already. I didn't have Chrome installed, so I needed to install the libatomic RPM. It needs to be made a dependency of Dropbox as well. Version-Release number of selected component (if applicable): How reproducible: Try to install Dropbox without Google Chrome already present. It will install, but the Dropbox daemon cannot run. Steps to Reproduce: 1. 2. 3.
IMO as dropbox uses bundled libs this should be reported to upstream first.
Do I do that?
Please, do.
The Help link on Dropbox is like many: it is almost impossible to start a new issue. Apparently there is a ticket system, but no link to it. I have posted my problem to the user forum, and will proceed as directed.
Dropbox have replied that they test with one .deb system (Ubuntu) and one RPM system (Fedora.) For problems in any other distro, they don't care. I replied that by adding one library, they could make Dropbox bullet-proof; it would be easier than getting the world to change its preferred distro to theirs.
My depression is getting to me; I am likely to pick a fight with somebody. Years ago, for another distro, there was a suggestion to have a partition where data used by multiple distros could be put. Fat32 was the suggested filesystem. Nowadays, I am using an USB stick in much the same way. I needed Dropbox for an activity that I have resigned from; I can manage without it now.
Can understand the angst. Dropbox's attitude is cynical. BTW can you please post here the URL to your complaint upstream? Do not give up yet. BUT we do have libatomic: $ urpmq -l libatomic1 | grep libatomic | sort -u /usr/lib64/libatomic.so.1 /usr/lib64/libatomic.so.1.2.0 /usr/lib/libatomic.so.1 /usr/lib/libatomic.so.1.2.0 so did you try installing the libatomic1 package ? That might work. (In reply to Doug Laidlaw from comment #0) > On Dropbox's last attempt to update itself, it failed because it couldn't > find libatomic.so.1 Does this mean that the package we provide interactively updates itself on-line? Did it work before - without libatomic.so.1? Can the update be refused? (In reply to Jani Välimaa from comment #1) Thanks for jumping in. > IMO as dropbox uses bundled libs this should be reported to upstream first. Note the 'first'. If Doug succeeds with dropbox by pre-installing libatomic1, would it not be simple to make it a requirement? Not ideal, but needs must. What use the dropbox package if it is not going to work in the future without libatomic1 (unless I have misunderstood something)?
CC: (none) => lewyssmith
There is a Dropbox package that is proprietary, and must be downloaded from the Dropbox Web site. Theoretically, that is all you need. It has a folder ~/.dropbox-dist/ in the user's home directory. Within that folder is a sub-folder "dropbox-<version>" containing the necessary libraries, to make Dropbox independent of system libraries. All this is put there by the download, and Dropbox updates it periodically. User rights are sufficient to install or update it. Dropbox cannot start its user-level daemon unless it can find libatomic.so.1. libatomic is not among the libraries in the folder, but Dropbox will use it if it is there already. Installing the Google Chrome package will pull it in. libatomic is part of the gcc group made available by building the gcc SRPM: see the listing in [Bug 25685]. The Mageia Dropbox package is not essential, as Dropbox runs happily without it. The RPM provides integration tools only. There is no other RPM on which it can be made a dependency to resolve this bug. I don't see how Mageia can do anything to fix this bug. Maybe I should just close it with a WONTFIX. The URL for the Dropbox forum is https://community.dropbox.com/t5/Installs-integrations/Dropbox-daemon-can-t-run-on-Linux-without-dependency/m-p/379197#M83077 They have now made a ticket for it, Ticket #9968375. It seems that they use Zendesk
Thanks for all the enlightenment. > Dropbox cannot start its user-level daemon unless it can find libatomic.so.1 However, you did not answer the vital point: If you install the Mageia 'libatomic' package which provides it c(omment 7), can you then employ DropBox correctly? You may have to copy it from /usr/lib64/libatomic.so.1 or /usr/lib/libatomic.so.1 to the directory you describe in your previous comment. Please do try this (if not already) and report the result. > There is a Dropbox package that is proprietary, and must be downloaded from > the Dropbox Web site. So it is not for Mageia to support it. Which does not ignore the possibility of making it work. Our DropBox package is not quite what you think: "This package provides a command line interface to the Dropbox, the easiest online file storage, synchronization and sharing service." In addition, there are several file manager extensions to integrate DropBox.
In answer to your two points: 1. I have already written that Dropbox will use system libraries if it can find them. I have installed the libatomic package, and it was a complete fix. I don't know how Google Chrome brings in libatomic.so.1. If in Mageia, it calls the libatomic RPM [and on the newsgroup, Dave said that it does,] it is doing exactly what I did. If it provides its own copy, Dropbox can find it. 2. We are not dealing with the interfaces to Dropbox. We are dealing with the user-level daemon at ~/.dropbox-dist/dropboxd that Dropbox cannot start. The number of RPMs that can alter SHOME are very limited, and the Dropbox RPM isn't one of them. On a fresh installation, if libatomic is present, Dropbox will run without the RPM. It doesn't need the interfaces; they are there only for the convenience of the user. If no interfaces are installed, the Dropbox folder can be viewed and managed in the default file manager. The daemon is what makes the difference.
As I see it, because Dropbox isn't installed by an RPM, and can run without any RPM installed, there is no way that it can have a dependency RPM. There won't be a README.urpmi, even.
[Sorry, I think in small mouthfuls.] I should be able to copy libatomic.so.1 from its present location to be with the bundled libraries, then remove the libatomic RPM. That is what I suggested to Dropbox. libatomic.so.1 is a symlink to libatomic.so.1.2.0. I copied the 64-bit libatomic.so.1.2.0 across, created a local symlink to libatomic.so.1, then removed the libatomic RPM, and it worked!
(In reply to Doug Laidlaw from comment #10) > 1. I have already written that Dropbox will use system libraries if it can > find them. I have installed the libatomic package, and it was a complete > fix. Which is what matters. Thank you for this confirmation. We can close the bug satisfactorily. Hope your depression has gone! > I don't know how Google Chrome brings in libatomic.so.1 This is a red herring: you knew that if you installed Google Chrome it pulled in the vital library. [I could not even find it in our packages - thankfully; it is the ultimate spyware; some obscure repo?] It was just an indirect and heavyweight way of installing the library which can be installed directly. > 2. We are not dealing with the interfaces to Dropbox. I only cited the Mageia DropBox package as a user interface, not the provider of other things. BTW You might add to your thread chez DropBox the suggestion simply for them to make it clear (System Requirements for example) that libatomic.so.1 must be installed on your system. That is ludicrously simple, and would have avoided this bug & your angst.
Resolution: (none) => WORKSFORMEStatus: NEW => RESOLVED
OK, resolved. The fix I gave in Comment 12 wouldn't survive an update from Dropbox.