Custom Query (73 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 73)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#79 fixed Errors when building survex RPM for fedora Olly Betts jmbegley
Description

There are 2 errors with the survex.spec file when attempting to build a RPM for fedora 23. These are:

1) The survex mime file has moved from /usr/share/mime/survex* to /usr/share/mime/packages/survex.xml so the %files section of the spec file needs updating, and

2) Fedora 23 has upgraded to RPM version 4.13, which is fussier about empty package files. By default an empty 'survex-debug' package will be built, which will now cause the rpmbuild process to fail. Google suggests that the 'fix' for this is to include

# workaround for rpm 4.13 %define _empty_manifest_terminate_build 0

in the spec file - I just added this before the %description section and the build then worked fine.

Cheers, James

#78 fixed CLINO and BACKCLINO readings must be of the same type for DOWN/DOWN, corrected backsights Olly Betts Andy Edwards
Description

Here's an except of my data:

*begin ; 111: <REDACTED>
*date 1983.07.13

*team <REDACTED>
*team <REDACTED>
*units tape feet
*calibrate BACKCOMPASS 180.00
*calibrate BACKCLINO 0.00 -1.00

*data normal from to tape compass backcompass clino backclino
;From       To          Distance    Compass     BackCompass Clino       BackClino  
<...REDACTED>
HC14        HC15        10.7        296         296         -26         -26               
HC15        HC16        1.3         -           -           DOWN        DOWN      

Cavern complains that "CLINO and BACKCLINO readings must be of the same type" for the DOWN/DOWN line, but not the -26/-26 line.

Is this invalid Survex data or is it a bug in Cavern?

#77 fixed missing "error: " or "warning: " in front of "CLINO and BACKCLINO readings must be of the same type" Olly Betts Andy Edwards
Description

I recently started contributing to Cavewhere, which uses Survex as a backend. When I tried importing Fisher Ridge data into it, Cavern crashed saying "too many errors -- giving up".

I couldn't find "error" anywhere in its output, but I did see the following message in several places. Is this a warning or an error?

0kz1lsqn0fg37x3tt94dvdsm0000gn/T/Cavewhere.L39692:11033: CLINO and BACKCLINO readings must be of the same type

I think Cavewhere relies on finding "warning" or "error" in Cavern output to mark warnings and errors in its UI.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.