Re: [Duplicity-talk] webdav in trunk broken - File /tmp/... not found locally after get from backend

[edgar . soldin]

On 08.05.2014 16:38, Michael Terry wrote:
> On 8 May 2014 10:26, <address@hidden <mailto:address@hidden>> wrote:
> 
>     we could make 2.6.x our requirement. but i'd like to see more bugs like 
> this one to convince me to explain users that tend not to read docs which 
> revision number of python they need on the mailing list.
>     also this one seems to be pretty easy to fix by simply keeping the old 
> urlparse if push comes to shove.
> 
>     we should strive to KISS and draw the line at minor versions.
> 
> 
> I agree that this fix is likely easy and we probably don't need to define a 
> micro version for our py26 support.
> 
> However, I think the larger point of having a way to determine the minimum 
> python requirement is worth considering.  A) Who are the users that have 
> py2.6.0 and want to use duplicity?  Clearly you do.  But you're using an 
> EOL-by-three-years distro -- what's going on there man?  :)  

the usual. production system with components (here plesk) that will not work if 
the system would be upgraded.
also. too many needed and running services which makes it risky to upgrade. 
also there is no time nor money to setup a replacement and shut the old machine 
down.

in the worst case i'd hand compile a fresher python, if need arises.

>I hope most users wouldn't run into this problem in the first place.  We've 
>got stuff like heartbleed out there, people should be on supported distros 
>(though I recognize you're probably using it as a desktop machine, but still).

not at all. webserver. but heartbleed is irrelevant here as it has no openssl 
services. it uses an external ssl proxy.

the apache is very old indeed and even serves a site with php4 where the 
customer does not want to port it to php5.

grim reality - i can only minimize the attack surface by minimizing the 
services available (http, shh) and hardenapache itself and the script runtimes.

> 
> B) We need to consider our ability to test against the python version we 
> declare.  If we lose easy access to py2.6.0, that could be a problem.  
> Supporting py24 was becoming a nightmare.
> 

my main issue with old python versions is mainly to get python libs (e.g. 
lockfile) into them. not the setting up part as mentioned above.

..ede