[arch-general] Dropbox requires setup each time I boot
Hello, I use the dropbox client as provided on their web site. Everything works as expected however, when I reboot my machine it requires me to setup my local folder each time. I also run a Fedora 20 system with a similar setup and I only had to set up my local folder once. Anyone know what would cause this behavior and how to correct it? My permissions look like: drwx-- 5 squall squall 155 Sep 22 12:29 .dropbox drwxr-xr-x 3 squall squall 68 Jul 29 18:44 .dropbox-dist Thank you Squall -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N https://github.com/headmastersquall
Re: [arch-general] Dropbox requires setup each time I boot
Are you using the dropbox aur package? If not, it might be worth trying that. Your permissions look to be the same as the ones I have locally. drwx-- 6 joel users4096 Sep 20 14:28 .dropbox drwxr-xr-x 3 joel users4096 Sep 12 18:33 .dropbox-dist Joel
[arch-general] testing/ca-certificates-utils problem installing
Packahe testing/ca-certificates-utils seems to have a packaging problem: ... :: Starting full system upgrade... :: Replace ca-certificates-java with testing/ca-certificates-utils? [Y/n] ... (7/7) loading package files [] 100% (7/7) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) ca-certificates-utils: /etc/ssl/certs/java/cacerts exists in filesystem Errors occurred, no packages were upgraded.
Re: [arch-general] testing/ca-certificates-utils problem installing
> Packahe testing/ca-certificates-utils seems to have a packaging problem: > > ... > :: Starting full system upgrade... > :: Replace ca-certificates-java with testing/ca-certificates-utils? [Y/n] > ... > (7/7) loading package files [] 100% > (7/7) checking for file conflicts [] 100% > error: failed to commit transaction (conflicting files) > ca-certificates-utils: /etc/ssl/certs/java/cacerts exists in filesystem > Errors occurred, no packages were upgraded. I can confirm this problem. --SM signature.asc Description: OpenPGP digital signature
Re: [arch-general] Out-of-date sbcl has fairly serious ASDF bug
On Sun, Sep 21, 2014 at 06:09:27AM -0500, Drake Wilson wrote: > (I originally attempted to send this to arch-dev-public, but apparently > that's only for > making discussions from a relatively closed circle visible? The list > descriptions > on the listinfo page were very ambiguous; if even things like packaging > issues should go > to -general if from third parties, perhaps the -dev-public description should > be updated > to be clearer about this.) > > The currently packaged sbcl 1.2.2-1 seems subject to the ASDF bug at > https://bugs.launchpad.net/asdf/+bug/982285 where systems installed into > /usr (e.g., according to the Arch Linux Lisp Package Guidelines) are not > found when > the environment variable XDG_DATA_DIRS is unset. (A workaround is to set > XDG_DATA_DIRS to /usr/local/share:/usr/share explicitly.) Yes, the arch-dev-public is for Developers[1] only. If you really feel like your issue is not getting sufficient attention (did you flag the package as out-of-date?), you can find the package maintainer's info on the package page and contact them directly. I would also suggest checking the testing repo to see if a new version of the package is available to be tested. --Sean [1] https://www.archlinux.org/developers/
Re: [arch-general] testing/ca-certificates-utils problem installing
Same problem, except I faced two filesystem conflicts: error: failed to commit transaction (conflicting files) ca-certificates-utils: /etc/ssl/certs/ca-certificates.crt exists in filesystem ca-certificates-utils: /etc/ssl/certs/java/cacerts exists in filesystem Errors occurred, no packages were upgraded. On Tue, Sep 23, 2014 at 8:13 AM, Stephen Martin wrote: > > > Packahe testing/ca-certificates-utils seems to have a packaging problem: > > > > ... > > :: Starting full system upgrade... > > :: Replace ca-certificates-java with testing/ca-certificates-utils? [Y/n] > > ... > > (7/7) loading package files [] 100% > > (7/7) checking for file conflicts [] > 100% > > error: failed to commit transaction (conflicting files) > > ca-certificates-utils: /etc/ssl/certs/java/cacerts exists in filesystem > > Errors occurred, no packages were upgraded. > I can confirm this problem. > > --SM > >
[arch-general] Errors regarding the ssl certificates
Curl needs to be recompiled with the new locations of the certificates. A quick glance at the PKGBUILD shows me that the compile flag --with-ca-bundle is set to /etc/ssl/certs/ca-certificates.crt, while as of the last update (20140923-2 in testing), this location does not seem to exist any more. This throws up errors while running the AUR manager cower, which complains of a non-existent path. ABS has similar problems. -- Cheers!
Re: [arch-general] testing/ca-certificates-utils problem installing
On Tue, Sep 23, 2014 at 3:34 AM, Genes Lists wrote:
> Packahe testing/ca-certificates-utils seems to have a packaging problem:
>
> ...
> :: Starting full system upgrade...
> :: Replace ca-certificates-java with testing/ca-certificates-utils? [Y/n]
> ...
> (7/7) loading package files [] 100%
> (7/7) checking for file conflicts []
> 100%
> error: failed to commit transaction (conflicting files)
> ca-certificates-utils: /etc/ssl/certs/java/cacerts exists in filesystem
> Errors occurred, no packages were upgraded.
This got rushed, poorly, and the updates were removed. I'm very sorry.
Please downgrade again:
pacman -S core/ca-certificates{,-cacert}
extra/{nss,ca-certificates-{mozilla,java},p11-kit}
And if you have multilib:
pacman -S multilib/lib32-p11-kit
Re: [arch-general] Errors regarding the ssl certificates
On Tue, Sep 23, 2014 at 8:28 AM, Mailing Lists
wrote:
> Curl needs to be recompiled with the new locations of the certificates.
> A quick glance at the PKGBUILD shows me that the compile flag
> --with-ca-bundle is set to /etc/ssl/certs/ca-certificates.crt, while as
> of the last update (20140923-2 in testing), this location does not seem
> to exist any more. This throws up errors while running the AUR manager
> cower, which complains of a non-existent path. ABS has similar problems.
>
> --
> Cheers!
This got rushed, poorly, and the updates were removed. I'm very sorry.
Please downgrade again:
pacman -S core/ca-certificates{,-cacert}
extra/{nss,ca-certificates-{
mozilla,java},p11-kit}
And if you have multilib:
pacman -S multilib/lib32-p11-kit
Re: [arch-general] Dropbox requires setup each time I boot
Hi Squall, 2014-09-22 20:46 GMT+02:00 Squall Lionheart : > I use the dropbox client as provided on their web site. Everything works > as expected however, when I reboot my machine it requires me to setup my > local folder each time. I also run a Fedora 20 system with a similar setup > and I only had to set up my local folder once. > > Anyone know what would cause this behavior and how to correct it? Do you have a particular reason for not running the dropbox package in the AUR, as Joel suggested? I'm using it without problems. Anyway, the first thing I'd do would be to launch dropboxd from the command line to see if it outputs some useful error messages. Another thing I'd try would be to backup and then rm the .dropbox and .dropbox-dist folders (or, alternatively, setup dropbox in a clean environment, e.g. from a test user). FWIW, my permissions are the same as yours. Hope this helps, Lorenzo -- "If you think the problem is bad now, just wait until we've solved it."
