How to safely upgrade svn on ubuntu 16?
I am running svn on Ubuntu 16.04.6 LTS. It reports the following: $ svn --version svn, version 1.9.3 (r1718519) compiled Aug 10 2017, 16:59:15 on x86_64-pc-linux-gnu The Ubuntu machine acts as a backup for a Windows 16 based VisualSvn server running at a separate location. Backups are performed using nightly svnsync commands via the Internet. The Ubuntu machine and svn were setup for this purpose about a year ago and since then Ubuntu has been kept updated using apt upgrade and apt dist-upgrade as adviced on the login screen when I regularly check in via PuTTY. But it seems like svn is not being touched by these operations So what is the advice on what to do in order to at least get to the latest 1.9 stable release of svn on this machine? It seems like that would be 1.9.10... Since this is a production backup server I am reluctant to risk breaking it, obviously. -- Bo Berglund Developer in Sweden
Re: Weird behavior of `svn --non-interactive`
On Tue, Feb 26, 2019 at 10:15:32PM -0800, Alexey Neyman wrote: > How does SVN decide when to use gpg-agent and when to use gnome-keyring? By > the way, I am running KDE so I'd assume the kwallet would be the default - > but it isn't... Subversion does not know that you're running it in KDE. By default it will prefer gpg-agent, detected by checking for the existence of a shared socket (the location of which unfortunately changes between versions of gpg-agent and between Linux distros). If that socket doesn't exist or has no gpg-agent listening on it, SVN will keep trying other auth stores in the default order given in the config file you've found. > If you need me to build Subversion with some kind of debugging patch, let me > know. Since you have several password stores running, the best bet to get reliable behaviour is to pick the one you actually want to use and configure it in the ~/.subversion/config file. By the way, 'svn auth' will list cached credentials and also show which password cache they are stored in.
Re: Weird behavior of `svn --non-interactive`
On 2/26/19 8:42 PM, Alexey Neyman wrote: On 2/26/19 12:07 AM, Stefan Sperling wrote: On Mon, Feb 25, 2019 at 05:41:13PM -0800, Alexey Neyman wrote: Hi all, I am encountering some weird behavior after upgrading my workstation to Ubuntu 18.10 - which also upgraded the SVN to version 1.10.0 (r1827917). An attempt to query anything from the server using the `--non-interactive` flag fails, unless there has been a recent "interactive session" with this server. aneyman@yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/ svn: E170013: Unable to connect to a repository at URL 'svn://svn.lynx.com/lynxsecure' svn: E170001: Can't get username or password aneyman@yehat:~/work/lsk-ranges$ svn pl ^/ Properties on 'svn://svn.lynx.com/lynxsecure': reviewboard:url aneyman@yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/ Properties on 'svn://svn.lynx.com/lynxsecure': reviewboard:url This happens during various actions by `rbt` (RBTools) which runs svn with --non-interactive flag. Note that the "interactive" run of svn does not even query the password - it happily uses the stored password and proceeds. Why isn't the non-interactive invocation doing the same? I also tried the development version of Subversion a couple of weeks ago; it has the same behavior. Regards, Alexey. I agree this looks like a bug. To find the bug we'll likely need to know which password store is actually being used by your installation of Subversion. plaintext? gpg-agent? gnome-keyring? kwallet? SVN configuration doesn't have the password store option specified, so I assume it is using the default - according to the comment in the .subversion/config, it is "gpg-agent,gnome-keyring,kwallet". I have kwallet installed and configured with empty master password. I also have gpg-agent and gnome-keyring installed, but I don't think I ever used either of them on that machine. How can I check which store was SVN actually trying to use at the time it happens? Actually, it is gpg-agent. I went to $HOME/.subversion/auth/svn.simple; somehow there is a mixture of files using gpg-agent and gnome-keyring authentication methods. I found the one corresponding to the repository URL; it has: K 8 passtype V 9 gpg-agent Funny thing is, I found another file in that directory that refers to the same repository, just with a different URL (one is using the FQDN of the Subversion server, the other just the hostname). That other file uses gnome-keyring and it seems to work fine: aneyman@yehat:~/work/lsk-pristine$ svn --non-interactive pl svn://svn/lynxsecure Properties on 'svn://svn/lynxsecure': reviewboard:url aneyman@yehat:~/work/lsk-pristine$ svn --non-interactive pl svn://svn.lynx.com/lynxsecure svn: E170013: Unable to connect to a repository at URL 'svn://svn.lynx.com/lynxsecure' svn: E170001: Can't get username or password How does SVN decide when to use gpg-agent and when to use gnome-keyring? By the way, I am running KDE so I'd assume the kwallet would be the default - but it isn't... If you need me to build Subversion with some kind of debugging patch, let me know. Regards, Alexey.
Re: Weird behavior of `svn --non-interactive`
On 2/26/19 12:07 AM, Stefan Sperling wrote: On Mon, Feb 25, 2019 at 05:41:13PM -0800, Alexey Neyman wrote: Hi all, I am encountering some weird behavior after upgrading my workstation to Ubuntu 18.10 - which also upgraded the SVN to version 1.10.0 (r1827917). An attempt to query anything from the server using the `--non-interactive` flag fails, unless there has been a recent "interactive session" with this server. aneyman@yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/ svn: E170013: Unable to connect to a repository at URL 'svn://svn.lynx.com/lynxsecure' svn: E170001: Can't get username or password aneyman@yehat:~/work/lsk-ranges$ svn pl ^/ Properties on 'svn://svn.lynx.com/lynxsecure': reviewboard:url aneyman@yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/ Properties on 'svn://svn.lynx.com/lynxsecure': reviewboard:url This happens during various actions by `rbt` (RBTools) which runs svn with --non-interactive flag. Note that the "interactive" run of svn does not even query the password - it happily uses the stored password and proceeds. Why isn't the non-interactive invocation doing the same? I also tried the development version of Subversion a couple of weeks ago; it has the same behavior. Regards, Alexey. I agree this looks like a bug. To find the bug we'll likely need to know which password store is actually being used by your installation of Subversion. plaintext? gpg-agent? gnome-keyring? kwallet? SVN configuration doesn't have the password store option specified, so I assume it is using the default - according to the comment in the .subversion/config, it is "gpg-agent,gnome-keyring,kwallet". I have kwallet installed and configured with empty master password. I also have gpg-agent and gnome-keyring installed, but I don't think I ever used either of them on that machine. How can I check which store was SVN actually trying to use at the time it happens? Regards, Alexey.
Re: Weird behavior of `svn --non-interactive`
On Mon, Feb 25, 2019 at 05:41:13PM -0800, Alexey Neyman wrote: > Hi all, > > I am encountering some weird behavior after upgrading my workstation to > Ubuntu 18.10 - which also upgraded the SVN to version 1.10.0 (r1827917). > > An attempt to query anything from the server using the `--non-interactive` > flag fails, unless there has been a recent "interactive session" with this > server. > > aneyman@yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/ > svn: E170013: Unable to connect to a repository at URL > 'svn://svn.lynx.com/lynxsecure' > svn: E170001: Can't get username or password > aneyman@yehat:~/work/lsk-ranges$ svn pl ^/ > Properties on 'svn://svn.lynx.com/lynxsecure': > reviewboard:url > aneyman@yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/ > Properties on 'svn://svn.lynx.com/lynxsecure': > reviewboard:url > > This happens during various actions by `rbt` (RBTools) which runs svn with > --non-interactive flag. > > Note that the "interactive" run of svn does not even query the password - it > happily uses the stored password and proceeds. Why isn't the non-interactive > invocation doing the same? > > I also tried the development version of Subversion a couple of weeks ago; it > has the same behavior. > > Regards, > Alexey. I agree this looks like a bug. To find the bug we'll likely need to know which password store is actually being used by your installation of Subversion. plaintext? gpg-agent? gnome-keyring? kwallet?
