You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(35) |
Apr
(26) |
May
(46) |
Jun
(5) |
Jul
(10) |
Aug
(29) |
Sep
(39) |
Oct
(13) |
Nov
(19) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(17) |
May
|
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(4) |
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(16) |
May
(8) |
Jun
(10) |
Jul
(3) |
Aug
(32) |
Sep
(27) |
Oct
(8) |
Nov
(5) |
Dec
(1) |
2009 |
Jan
(14) |
Feb
(2) |
Mar
(12) |
Apr
(50) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(6) |
Sep
(36) |
Oct
(70) |
Nov
(51) |
Dec
(41) |
2010 |
Jan
(3) |
Feb
(6) |
Mar
(11) |
Apr
(54) |
May
(17) |
Jun
(31) |
Jul
(13) |
Aug
|
Sep
(7) |
Oct
(168) |
Nov
(58) |
Dec
(10) |
2011 |
Jan
(83) |
Feb
(25) |
Mar
(11) |
Apr
(8) |
May
(46) |
Jun
(53) |
Jul
(49) |
Aug
(117) |
Sep
(31) |
Oct
(13) |
Nov
(7) |
Dec
|
2012 |
Jan
|
Feb
(3) |
Mar
(35) |
Apr
(21) |
May
(7) |
Jun
(6) |
Jul
(8) |
Aug
(12) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(11) |
2013 |
Jan
(1) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2012-03-16 00:14:02
|
Bugs item #3400488, was opened at 2011-08-29 17:49 Message generated for change (Settings changed) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3400488&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: Terry O'Neill (terryoneill) Summary: multiple output files not removed on cancel or error Initial Comment: Any action in Xena that results in multiple output files will not clean up all of these output files in situations where it should, these situations being: - on an error - when the user chooses Cancel (and confirms to delete output) Actions that result in multiple output files are: - normalisation/conversion of archive files - normalisation/conversion of files where the option to create a text version is selected and the file would create a text version There may be other situations where this error occurs. The underlying problem is that Xena is only setup to record a NormalisationResult with one output file. Thus when cleaning up the core components only know of one output file and only clean that file. This should be changed. Note that this issue was previously recorded as bugs 3380615 and 2866252 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3400488&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-16 00:11:36
|
Bugs item #3413901, was opened at 2011-09-25 20:47 Message generated for change (Settings changed) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3413901&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: Terry O'Neill (terryoneill) Summary: Xena Viewer - no error message opening from CLI Initial Comment: When using the command line interface to open a Xena file with the Xena Viewer then if the file is not a valid Xena file an error is not displayed (the loading cursor just stays). This is different from when trying to open from the Xena Viewer GUI by pressing the open button in which case an error message is given if the Xena file is not valid. This is particularly an issue when the windows installer has been used as double clicking on a .xena file will result in a call using the CLI passing the file name as a parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3413901&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-16 00:09:19
|
Bugs item #3418857, was opened at 2011-10-04 20:29 Message generated for change (Settings changed) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3418857&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Interface Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: margotc (margotc) Summary: XML Tree View does not show Data in package:content Initial Comment: When viewing xena files created from tiff files a number of these do not show the value for the actual Data of the contained file (png) in the XML Tree View. For example if the below attached eurotext.tif file is normalised then the resulting xena file will only have the following under the "package:content" tag when viewed with the XML Tree View: png:png png:metadata [Data]: Note that the contained Base64 encoded data is still present and using the export functionality still works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3418857&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-16 00:06:42
|
Bugs item #3419372, was opened at 2011-10-05 23:34 Message generated for change (Comment added) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3419372&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-audio Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: Kirti Chennareddy (kirtic) Summary: Playing audio in Xena - no play after pause Initial Comment: After normalising a particular audio file ("non-quadriga bwf.wav") in Xena then opening with the viewer, pressing play and then pressing pause results in the play button no longer appearing; the button stays as pause. This is reproducible with this file; which is too big to attach here. ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-03-15 17:06 Message: Please test with a variety of files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3419372&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-16 00:04:32
|
Bugs item #3428602, was opened at 2011-10-25 21:30 Message generated for change (Comment added) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3428602&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-office Group: None Status: Open >Resolution: Postponed Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Nobody/Anonymous (nobody) Summary: Conversion does not always produce the same results Initial Comment: One file (4th Injury-Paper.doc) has been found to produce a different output each time it is normalised or converted with Xena. In this case it is caused by the underlying conversion (as done by LibreOffice version 3.3.3). Xena should produce the same output when run on the same file wherever possible. In this file one of the elements in the footer is the full name of the file, which could be one cause for differing results (although in this case LibreOffice is aware that this is a file name). Note that this particular file produces different output when doing multiple conversions immediately after one another using the same input file. This also brings up the issue of other situations where it may be possible that re-normalising will produce a different result. This would seem particularly likely for documents with content that is not fully supported for conversion (which might result in something like converting formulas to static values) particularly if that content is metadata or dynamic content that is likely to change (e.g. today's date). ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-03-15 17:04 Message: May not be worthwhile fixing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3428602&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-15 23:53:23
|
Bugs item #3435270, was opened at 2011-11-08 21:33 Message generated for change (Settings changed) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3435270&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-image Group: None Status: Open Resolution: Fixed Priority: 7 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: Kirti Chennareddy (kirtic) Summary: File Descriptors not released when processing tiff files Initial Comment: When Xena processes tiff files that have an EXIF IFD Tag it creates a file descriptor to a temporary file used during processing but does not release this file descriptor. It does remove the actual temporary file. When processing large numbers of tiff files this can result in reaching the maximum for the number of open files for the process. This has occurred for us when using the Digital Preservation Recorder and is present as bug 3434210 in the tracker for the Digital Preservation Recorder. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2011-11-08 21:34 Message: Fixed in testing branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3435270&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-15 23:52:36
|
Bugs item #3436294, was opened at 2011-11-10 17:45 Message generated for change (Comment added) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3436294&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None >Status: Closed >Resolution: Wont Fix Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: Updater from windows installer sees same version as new Initial Comment: When the Xena 6.0.0 windows installer is used and the user installing specifies to install "Only for me" then the version of Xena will not be written to the registry. This registry key is used by the Updater to compare if the version available from our website is newer than the version installed. The result is that when the user checks for updates they will see the same version they have (6.0.0) as available for update rather than seeing a message to say "Your software is up to date". This can be fixed by using a different method to determine if the local version is newer than the latest version on our website. This only involves changing the http://xena.sourceforge.net/updates.txt file that is used by the updater and project file that is used to generate this update file (in git://xena.git.sourceforge.net/xena/installers). ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-03-15 16:52 Message: We will remove update functionality in new release ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2011-11-10 20:06 Message: In testing have found that using the size of xena.jar works however this brings up a bug present with the updater. When called and there are no updates quite frequently an access violation results. This seems to be a known bug with the Advanced Installer: http://www.advancedinstaller.com/forums/viewtopic.php?f=2&t=10919&p=29995&hilit=0xc0000005#p29995 http://www.advancedinstaller.com/forums/viewtopic.php?f=2&t=19622&p=46907&hilit=0xc0000005&sid=cc35dc262378e56c4fa1e19436f38913#p46907 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3436294&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-15 23:41:59
|
Feature Requests item #3505603, was opened at 2012-03-15 16:41 Message generated for change (Tracker Item Submitted) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3505603&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: margotc (margotc) Assigned to: Terry O'Neill (terryoneill) Summary: Directory structure on normalisation is flat Initial Comment: We could add a functional option in th UI reflect the orginal directory structure on normalisation. Currently the directory is flattened on normalisation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3505603&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-09 00:42:38
|
Bugs item #3499719, was opened at 2012-03-08 08:35 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3499719&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: S. Walz (s-walz) Assigned to: Terry O'Neill (terryoneill) Summary: Retain Directory Structure option not working Initial Comment: When Normalising or Converting directories with sub-directories, the output records are being saved in top level output directory, without the originating sub-directory structure being retained, even though the Retain Directory Strcture option is selected. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-03-08 16:42 Message: Tested and confirmed that this is always a flat output. This is a quite plain bug in the case of conversion. In the case of normalisation it is a bit more complex. In this case what is happening here is that the "Retain Directory Structure" is being used by Xena for returning files in their original directory structure when they are Exported. Thus normalised files are always being output in a flat single directory output when normalised but when exported they are exported back to their original structure. This may best be solved by adding an additional option. Perhaps a sub-option like: X Retain Directory Structure ---- X For Export Only (Flat Structure for Normalisation) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3499719&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-09 00:18:56
|
Bugs item #3500054, was opened at 2012-03-08 16:18 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3500054&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Building Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: Ant build results in missing Plastic3DLookAndFeel Initial Comment: In some circumstances after building Xena in the normal way with: ant ant build_plugins When attempting to run with the xena.sh file the following exception will be given: Exception in thread "main" java.lang.Error: Unresolved compilation problem: at au.gov.naa.digipres.xena.litegui.LiteMainFrame.main(LiteMainFrame.java:1428) When attempting to run with "java -jar xena.jar" the more detailed error message is: Exception in thread "main" java.lang.Error: Unresolved compilation problems: The import com.jgoodies cannot be resolved Plastic3DLookAndFeel cannot be resolved to a type Plastic3DLookAndFeel cannot be resolved to a type at au.gov.naa.digipres.xena.litegui.LiteMainFrame.<init>(LiteMainFrame.java:111) at au.gov.naa.digipres.xena.core.XenaMain.main(XenaMain.java:56) This can sometimes be fixed by running the ant builds from xena/ext/src/looks-2.2.2 to the main build.xml file but sometimes the build for looks-2.2.2 results in a fail with the problem: jar-all: BUILD FAILED /home/toneill/workspaceXenaTest/xena/xena/ext/src/looks-2.2.2/build.xml:247: /home/toneill/workspaceXenaTest/xena/xena/ext/src/looks-2.2.2/conf/service descriptors does not exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3500054&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-08 22:33:12
|
Bugs item #3499719, was opened at 2012-03-08 08:35 Message generated for change (Settings changed) made by mcarden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3499719&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: S. Walz (s-walz) >Assigned to: Terry O'Neill (terryoneill) Summary: Retain Directory Structure option not working Initial Comment: When Normalising or Converting directories with sub-directories, the output records are being saved in top level output directory, without the originating sub-directory structure being retained, even though the Retain Directory Strcture option is selected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3499719&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-08 16:35:55
|
Bugs item #3499719, was opened at 2012-03-08 08:35 Message generated for change (Tracker Item Submitted) made by s-walz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3499719&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: S. Walz (s-walz) Assigned to: Nobody/Anonymous (nobody) Summary: Retain Directory Structure option not working Initial Comment: When Normalising or Converting directories with sub-directories, the output records are being saved in top level output directory, without the originating sub-directory structure being retained, even though the Retain Directory Strcture option is selected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3499719&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-02 05:47:59
|
Bugs item #3496202, was opened at 2012-03-01 21:47 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3496202&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: Status bar wrong number of total files when Normalising Initial Comment: I have come across a situation where during normalisation the status bar at the bottom will give a smaller number for the number of total files to be normalised than there actually are. In this case 278 files got normalised but the status bar says only 271 were normalised. The difference was files in a subdirectory. Binary Normalising did not give this problem. This seems to be something to do with the doFiltering function in NormalisationThread. If I can duplicate this on a smaller sample case I will attach that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3496202&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-02 01:29:44
|
Bugs item #3491559, was opened at 2012-02-22 19:22 Message generated for change (Comment added) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3491559&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-website (wsx) Group: None Status: Open >Resolution: Fixed Priority: 7 Private: No Submitted By: Michael Carden (mcarden) Assigned to: margotc (margotc) Summary: Odd attribute in normalised html Initial Comment: After normalisation, any instance of the html anchor tag <a> has an attribute shape="rect" added to it. This needs to not happen and any other random insertions should be tracked down and removed as well. ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-03-01 17:29 Message: Malformed HTML caused this problem. Href tag had /> and should have been closed as expected. Link tag always has shape="rect" and this shouldn't affect the link. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3491559&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-01 23:48:16
|
Bugs item #3495834, was opened at 2012-02-29 16:04 Message generated for change (Comment added) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-office Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: Kirti Chennareddy (kirtic) Summary: Libreoffice GUI opening up when it should not Initial Comment: When Xena processes a Office file it is opening up a graphical interface for LibreOffice when it should not. This seems to be a problem specific to the machine it is run on as this did not occur on the old development machines but does on the new ones. When testing this please use the 6.0.0 release files to confirm that this behaviour is present on the machine first. ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-03-01 15:48 Message: Some specific testing scenarios are required to test this. ---------------------------------------------------------------------- Comment By: margotc (margotc) Date: 2012-03-01 13:26 Message: I think it's a good idea to investigate these options during testing. I will look into the switches suggested. I would like to test the -headless option on the older machines before other testing occurs. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-02-29 16:08 Message: Assigned to margot as she has fixed this with a "-headless" option. Note that there are other options that we do not have such as "-nofirststartwizard" which may be worth looking into. Also note that there is possibly more to this so probably would be a good idea to test with an old development machine as well to try to nail down other differences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-01 21:26:56
|
Bugs item #3495834, was opened at 2012-02-29 16:04 Message generated for change (Comment added) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-office Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: margotc (margotc) Summary: Libreoffice GUI opening up when it should not Initial Comment: When Xena processes a Office file it is opening up a graphical interface for LibreOffice when it should not. This seems to be a problem specific to the machine it is run on as this did not occur on the old development machines but does on the new ones. When testing this please use the 6.0.0 release files to confirm that this behaviour is present on the machine first. ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-03-01 13:26 Message: I think it's a good idea to investigate these options during testing. I will look into the switches suggested. I would like to test the -headless option on the older machines before other testing occurs. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-02-29 16:08 Message: Assigned to margot as she has fixed this with a "-headless" option. Note that there are other options that we do not have such as "-nofirststartwizard" which may be worth looking into. Also note that there is possibly more to this so probably would be a good idea to test with an old development machine as well to try to nail down other differences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-01 00:08:54
|
Bugs item #3495834, was opened at 2012-02-29 16:04 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-office Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: margotc (margotc) Summary: Libreoffice GUI opening up when it should not Initial Comment: When Xena processes a Office file it is opening up a graphical interface for LibreOffice when it should not. This seems to be a problem specific to the machine it is run on as this did not occur on the old development machines but does on the new ones. When testing this please use the 6.0.0 release files to confirm that this behaviour is present on the machine first. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-02-29 16:08 Message: Assigned to margot as she has fixed this with a "-headless" option. Note that there are other options that we do not have such as "-nofirststartwizard" which may be worth looking into. Also note that there is possibly more to this so probably would be a good idea to test with an old development machine as well to try to nail down other differences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-03-01 00:04:22
|
Bugs item #3495834, was opened at 2012-02-29 16:04 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-office Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: margotc (margotc) Summary: Libreoffice GUI opening up when it should not Initial Comment: When Xena processes a Office file it is opening up a graphical interface for LibreOffice when it should not. This seems to be a problem specific to the machine it is run on as this did not occur on the old development machines but does on the new ones. When testing this please use the 6.0.0 release files to confirm that this behaviour is present on the machine first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3495834&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-02-23 03:22:18
|
Bugs item #3491559, was opened at 2012-02-22 19:22 Message generated for change (Tracker Item Submitted) made by mcarden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3491559&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: plugin-website (wsx) Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Michael Carden (mcarden) Assigned to: margotc (margotc) Summary: Odd attribute in normalised html Initial Comment: After normalisation, any instance of the html anchor tag <a> has an attribute shape="rect" added to it. This needs to not happen and any other random insertions should be tracked down and removed as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3491559&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-02-16 00:36:33
|
Bugs item #3488039, was opened at 2012-02-15 15:46 Message generated for change (Settings changed) made by mcarden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3488039&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Sean Mosely (seanmosely) >Assigned to: margotc (margotc) Summary: MSG files with attachments not preservation normalising Initial Comment: I seem to have encountered a bug with the preservation normalisation of MSG files. A recent transfer job (NAA transfer job no. 2012/00695808) threw up an error for approximately 10 MSG files. The error read “Exception: org.xml.sax.SAXException: Message body is empty. Perhaps this isn’t really a MSG file?” I can confirm that these files are indeed MSG files and that their message bodies are not empty. It seems that these MSG files also contain attachments. Furthermore, it should be noted that not all MSG files failed to preservation normalise in this batch. I’m afraid I can’t provide too much more information, but I am more than happy to show people the binary normalised files if it will help put you on the right track. Similar bugs: 1195637 – “Email within an email doesn’t work – MSG” – closed 05/05/2005 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3488039&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-02-15 23:46:57
|
Bugs item #3488039, was opened at 2012-02-15 15:46 Message generated for change (Tracker Item Submitted) made by seanmosely You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3488039&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sean Mosely (seanmosely) Assigned to: Nobody/Anonymous (nobody) Summary: MSG files with attachments not preservation normalising Initial Comment: I seem to have encountered a bug with the preservation normalisation of MSG files. A recent transfer job (NAA transfer job no. 2012/00695808) threw up an error for approximately 10 MSG files. The error read “Exception: org.xml.sax.SAXException: Message body is empty. Perhaps this isn’t really a MSG file?” I can confirm that these files are indeed MSG files and that their message bodies are not empty. It seems that these MSG files also contain attachments. Furthermore, it should be noted that not all MSG files failed to preservation normalise in this batch. I’m afraid I can’t provide too much more information, but I am more than happy to show people the binary normalised files if it will help put you on the right track. Similar bugs: 1195637 – “Email within an email doesn’t work – MSG” – closed 05/05/2005 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3488039&group_id=85722 |
From: SourceForge.net <no...@so...> - 2011-11-11 04:06:43
|
Bugs item #3436294, was opened at 2011-11-10 17:45 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3436294&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: Updater from windows installer sees same version as new Initial Comment: When the Xena 6.0.0 windows installer is used and the user installing specifies to install "Only for me" then the version of Xena will not be written to the registry. This registry key is used by the Updater to compare if the version available from our website is newer than the version installed. The result is that when the user checks for updates they will see the same version they have (6.0.0) as available for update rather than seeing a message to say "Your software is up to date". This can be fixed by using a different method to determine if the local version is newer than the latest version on our website. This only involves changing the http://xena.sourceforge.net/updates.txt file that is used by the updater and project file that is used to generate this update file (in git://xena.git.sourceforge.net/xena/installers). ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2011-11-10 20:06 Message: In testing have found that using the size of xena.jar works however this brings up a bug present with the updater. When called and there are no updates quite frequently an access violation results. This seems to be a known bug with the Advanced Installer: http://www.advancedinstaller.com/forums/viewtopic.php?f=2&t=10919&p=29995&hilit=0xc0000005#p29995 http://www.advancedinstaller.com/forums/viewtopic.php?f=2&t=19622&p=46907&hilit=0xc0000005&sid=cc35dc262378e56c4fa1e19436f38913#p46907 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3436294&group_id=85722 |
From: SourceForge.net <no...@so...> - 2011-11-11 01:45:03
|
Bugs item #3436294, was opened at 2011-11-10 17:45 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3436294&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: Updater from windows installer sees same version as new Initial Comment: When the Xena 6.0.0 windows installer is used and the user installing specifies to install "Only for me" then the version of Xena will not be written to the registry. This registry key is used by the Updater to compare if the version available from our website is newer than the version installed. The result is that when the user checks for updates they will see the same version they have (6.0.0) as available for update rather than seeing a message to say "Your software is up to date". This can be fixed by using a different method to determine if the local version is newer than the latest version on our website. This only involves changing the http://xena.sourceforge.net/updates.txt file that is used by the updater and project file that is used to generate this update file (in git://xena.git.sourceforge.net/xena/installers). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3436294&group_id=85722 |
From: SourceForge.net <no...@so...> - 2011-11-11 00:19:13
|
Bugs item #2870533, was opened at 2009-09-29 23:52 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2870533&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christopher Smart (csmart) >Assigned to: Terry O'Neill (terryoneill) Summary: Windows installer deletes extracted install files Initial Comment: Although told not to delete, the installer is removing the extracted install files (CAB and MSI). This means users cannot re-install/fix the install. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2011-11-10 16:19 Message: This is fixed with the Xena 6.0.0 release windows installer. Files related to the installer can be found in the git://xena.git.sourceforge.net/xena/installers repository. This bug is fixed in the initial commit for this repository. Note that this installer now adds an extra folder for the version in the location where the cab and msi files are extracted. This was done to prevent an issue where installing a new version would fail because the installer would attempt to remove the cab and msi of the old version after they were replaced by files of the same name from the new version. In windows 7 the cab and msi files are normally placed in C:\ProgramData\Nation Archives of Australia\Xena\<version>\ (version 5.0.0 does not use a version but places the files in the base directory). Note that when opening the Advanced Installer project for the Xena windows installer the install location can be found under (Deployment) Media -> (Buildwinx86) Bootstrapper -> (Install Options) Extract Location. ---------------------------------------------------------------------- Comment By: Christopher Smart (csmart) Date: 2011-01-17 18:57 Message: This might not be a problem any more, I can't remember :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2870533&group_id=85722 |
From: SourceForge.net <no...@so...> - 2011-11-10 23:39:01
|
Bugs item #3411721, was opened at 2011-09-19 23:49 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3411721&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Allan Cunliffe (acunliffe) Assigned to: Terry O'Neill (terryoneill) Summary: Unable to start Xena after running installer Initial Comment: Installer 6.0.0 Setup-test-19sep1740 - Windows Vista and Windows 7 First I install Xena using the installer (either selecting to make it available to me or all users makes no difference). Then I try to run Xena. I get the busy indicator and then nothing happens. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2011-11-10 15:39 Message: Fixed this problem by adding the "-Xmx 1024M" option for the executables generated by Advanced Installer. Note that, surprisingly, when run on a VM with less than 512M the program will still run (even thought Xms is still at 512M). This change can be found in the git://xena.git.sourceforge.net/xena/installers repository in the initial commit. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2011-09-25 18:23 Message: This appears to be a problem with the memory options when running Java. It is currently set to use the -Xms512M option. When run from the command line on my Windows XP test virtual machine I get the following: java -Xms512M -jar xena.jar Error occurred during initialization of VM Incompatible minimum and maximum heap sizes specified Looking up this problem it seems that the default maximum heap size is 64M in this case. Adding the Xmx1024M option fixes this problem. This will require more looking into however as different JVMs and different memory situations would be expected to produce different results. Also it should be worth noting that on the Windows XP virtual machine I am using I have the memory set to 256M which is less than the minimum memory parameter (512M) yet the program still runs. It is also worth noting that specifying the Xmx option too high for available memory can result in the program not running at all. Finally it is possible to set the installer to check for a minimum memory size which may be worthwhile. This issue still needs some testing to find what parameters should be used and will probably still exist in certain combinations of JVM used and machine memory available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3411721&group_id=85722 |