Bug - Not A Bug svn update broken

Boesbert

Member
Most recent build, most recent Chromium.

This likely has to do with the latest sourceforge outage; at least the problem originated from that time. It looks like it is caused by

a) running "svn update" when any script reports having a newer version than runs locally, or
b) manually trying to update a script with "svn update scriptname" even when it does not have a new version out.

The effect is that there is no real updating of the affected scripts (it just goes through "Validating repo... // Repo validated. // Updating scriptname... // /home/user/.kolmafia/svn/scriptname // Requests complete") and then the queue hangs itself up, meaning all other commands are blocked from being executed. The only solution at that point seems to restart mafia.

For me, this problem when caused by "a)" had to do with a Cheesecookie script (those I think are on sourceforge) but also one single Ezandora script (the Genie relay override which resides on github, like all the other Ezandora scripts). A clannie who also had the Genie overlay did not report having any problem with it in that way.
 

Ryo_Sangnoir

Developer
Staff member
To give an alternate guess: it's something to do with the new CI server's build.

I have a jar file from Feb 2017 that works; others have also reported that older builds work. As the code hasn't changed, that leaves the build process itself.

With the current daily jar, I can't even svn checkout a new project (I get the same as for update -- it doesn't actually run svn update, but I can run it on the commandline. I get a message saying there are unfinished transactions and a working copy modification. I still got that message even after I deleted the relevant folder entirely).

Downloading the source code and running ant daily locally (using IntelliJ), I get a jar file that works perfectly. This is unfortunate: I was hoping it would fail so I could debug it.

I built the file successfully using jdk1.8.0_121; is perhaps the CI server is using the latest version, jdk1.8.0_161, or even java 9, and something's going wrong?
 

fewyn

Administrator
Staff member
This should now be fixed. It seems the latest version of Ubuntu Server is now defaulting to Java 9 and I overlooked it.
 

fronobulax

Developer
Staff member
I unlocked this because I am not sure where it belongs. I will investigate eventually but if I post maybe someone will beat me.

I'm building r18485 locally and running it under Java 8, so most of the server issues, that have been fixed, should not apply.

The SVN update commands seem to be generating two kinds of errors:

rlbond86-mafia-scripts-fax_tell-trunk not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E160013: '/p/rlbond86-mafia-scripts/code/!svn/vcc/default' path not found: 404 Not Found (https://svn.code.sf.net)

and

psychoseamatic not checked - exception: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: PROPFIND of '/': 403 Forbidden (https://svn.code.sf.net)

I spot checked some of the 404's and I can access them in a browser so it is probably mafia and not SourceForge.

I tried Tortoise and was able to reprobrowse although things were wonky for a moment.

Ezandora's Guide shows as up to date. I mention that because it is the only script I use that I am sure is hosted at github.
 

Fessor Eli

New member
If it's helpful, here's from a user, not developer. I tried svn update using three different builds including r18485.
A sample (a few out of many) of messages:
svn: E175002: OPTIONS request failed on '/p/ccascend/code/snapshot'
wrldwzrd89-mafia-scripts-trunk-pandamonium-quest not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E210003: connection refused by the server
slimetube not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server
svn: E175002: OPTIONS request failed on '/p/slimetube/code'
zlib not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server
svn: E175002: OPTIONS request failed on '/p/zlib/code'
digitrev-fishbot not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server
svn: E175002: OPTIONS request failed on '/p/digitrev/code/fishbot'
guyymafia-slimecalc not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server
svn: E175002: OPTIONS request failed on '/p/guyymafia/code/slimecalc'
formhtml not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server
Ezandora's scripts were the only ones that got a response.
 
After I switched off auto SVN update, I could finally use mafia. Before this, it kept trying to update, and throwing up error messages. Any other script that I run after logging in would just hang.

I think it also affects the maximizer. It keeps hanging I get the error:
svn: E175002: timed out waiting for server
Something went wrong while fetching svn directory info
 
Last edited:
I thought it was just me, svn updates seemed to be going ok until I had a system crash (yesterday) and had to restore an old preferences file. It seems inconsistent with the same script updates sometimes succeeding, sometimes failing. I guess I'll quit wrestling with this until I hear something further.
 

Veracity

Developer
Staff member
This has, literally, nothing to do with KoLmafia.
This has, literally, everything to do with Sourceforge.

KoLmafia cannot update from Sourceforge unless/until Sourceforge is willing/able to send updates.

Can we mark this "not a bug" soon, please?
 

fronobulax

Developer
Staff member
This has, literally, nothing to do with KoLmafia.
This has, literally, everything to do with Sourceforge.

KoLmafia cannot update from Sourceforge unless/until Sourceforge is willing/able to send updates.

Can we mark this "not a bug" soon, please?

When this was started there was credible evidence that a SVN problem was due to the new server. Some problems were attributed to running a build compiled under Java 9 (on the new server) on a system that was running Java 8. That was, however, fixed a few days ago and subsequent issues are entirely due to Sourceforge's unavailability.
 
Top