i have a problem using the fedora-checksums script in repair mode. When i run it in validate mode, it says there are 2306 invalid checksum(s), but when i use the repair switch, it says
"Checked 2474 object(s), updated 8 datastream(s), Error saving 12 datastream(s)"
where the 12 datastreams are fedora internal schema objects (so it is probably ok not to update them). But none of the 2306 invalid checksums is updated, no other error messages occur.

i use

• Fedora Commons 3.6.2
• EulFedora 0.19.2 - which is a great package :-)
• the latest version of fedora-checksums script from github

Do i need to upgrade EulFedora to use the repair function of the script?

Hello,

I did a pip install eulfedora, eulcommon but django can't find syncrepo, when I do python manage.py help it shows only :

 cleanup
compilemessages
createcachetable
dbshell
diffsettings
dumpdata
flush
inspectdb
loaddata
makemessages
reset
runfcgi
shell
sql
sqlall
sqlclear
sqlcustom
sqlflush
sqlindexes
sqlinitialdata
sqlreset
sqlsequencereset
startapp
startproject
syncdb
test
testserver
validate

Can you help me to debug that problem please ?

'str' object is not callable
Request Method: GET
Request URL: http://localhost:8000/objects/simplerepo:1/
Django Version: 1.5.1
Exception Type: TypeError
Exception Value:
'str' object is not callable
Exception Location: /usr/local/lib/python2.7/site-packages/django/core/handlers/base.py in get_response, line 115
Python Executable: /usr/local/bin/python2.7
Python Version: 2.7.5

Traceback Switch to copy-and-paste view

/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py in get_response
response = callback(request, _callback_args, *_callback_kwargs) ...
▶ Local vars

I have an XML datastream that's been modified, and I want to retrieve previous versions of the datastream content.

Here's what I currently have:
obj.api.getDatastreamDissemination(obj.pid, 'MODS', asOfDateTime=obj.mods.history().versions[0].created).text
That gives me the text of the datastream for whichever version I want - but am I missing an easier way?

Something like this would be nice:
obj.mods.history().versions[0].content
That way I wouldn't need to know how to call getDatastreamDissemination. Also, 'content' could return the actual XmlDatastreamObject, like obj.mods.content does.

possibly a build/config issue (missing django dependency?)

Fedora 3.8.1 returns a 500 error with no message if there's a checksum mismatch in addDatastream. This means that ChecksumMismatch doesn't get raised in HTTP_API_BASE._make_request.

Is anyone else seeing this issue? Is there any interest in a patch that would validate the checksum in eulfedora?

Creating new issue based on conversations from Issue #15.

The problem arises when the datastream information is particularly long (e.g. labels), causing it be longer than the moving window for reading datastream information.

Bumping the window size on line 206 and lines 252-255 from 200 / 250 to something like 750 worked for a particular set of objects with long datastream labels, but might not be a permanent solution.

When I download a file directly from fedora, get the content-disposition header set. When I download it through the raw_datastream view, I do not see this header. This is useful if you want to make sure a datastream is downloaded with a specific filename as passed through from fedora.

This made a difference when returning Digital Negative files (dng) which end up having a mimetype image/tiff. I received a file named download.tif as opposed to ORIGINAL_NAME.dng

I'm willing to work on this but not sure where to start.

I am building a project with multiple DigitalObject models and I have added a few of my own XmlDatastreams using my personal XML Schemas. What I ended up doing was copying dc.py and modifying it so there was one for each XML Schema. It appears to work on an individual basis, however when I have multiple declarations within my models.py Django project, it is pointing all of the XMLDatastreamObjects to the last declared one. For example:

class FileObject(DigitalObject):
FILE_CONTENT_MODEL = 'info:fedora/genrepo:File-1.0'
CONTENT_MODELS = [ FILE_CONTENT_MODEL ]
file = FileDatastream("FILE", "Binary datastream", defaults={
'versionable': True,
})
extra_meta = XmlDatastream("EXTRA_META, "Extra Metadata", ExtraMetaXML)
second_meta = XmlDatastream("SECOND_META", "Second Metadata", SecondMetaXML)

class AnotherObject(DigitalObject):
CONTENT_MODELS = ['info:fedora/%s:ResultsObject' % FEDORA_PIDSPACE]
third_meta = XmlDatastream("THIRD_META", "Third Metadata", ThirdMetaXML)

Using this models.py, both first_meta, second_meta, and third_meta all show up as ThirdMetaXML objects when declaring a new FileObject or AnotherObject (obj.first_meta.content, etc). Commenting out third_meta declaration in models.py makes the remaining two SecondMetaXML.

Am I declaring these XmlDatastreams properly in the models.py or is there another way these datastreams should be declared?

It would be helpful to have a custom panel that could report on the fedora api requests & response time it takes to generate a given django page.

I was able to add something similar for xqueries in eulexistdb based on the caching panel in django-debug-toolbar without too much difficulty, should be a similar way to hook into the api here too. emory-libraries/eulexistdb@814c77f

With python 2.7, we were getting the error with regards to progressbar:
AttributeError: 'module' object has no attribute 'DataSize'

As it turns out, we had version 2.3, which pip install gave us. Looks like we need newer versions of progressbar that include DataSize under widgets, and those newer versions fall under progressbar2.

Updating progressbar to progressbar2 here worked for us:
https://github.com/emory-libraries/eulfedora/blob/master/setup.py#L58

But didn't want to submit a pull request yet, as maybe there was more thinking behind falling back to progressbar(1) there.

Perhaps this is not a bug, and just how unicode and string objects are treated differently with Eulfedora, but it has caused us various bouts of confusion when creating relationships with add_relationship, and thought it might be worth mentioning.

When using add_relationship(), if you provide unicode objects instead of plain strings, they are not added as rdf:resource to the triple, but instead, as string literals.

For example, object_handle.add_relationship(u'fedora-rels-ext:hasContentModel',u'info:fedora:CM:Collection')

would create the RELS-EXT triple, <hasContentModel xmlns="info:fedora/fedora-system:def/relations-external#">info:fedora/CM:Collection</hasContentModel>

Where, object_handle.add_relationship('fedora-rels-ext:hasContentModel','info:fedora:CM:Collection')

would create, <hasContentModel xmlns="info:fedora/fedora-system:def/relations-external#" rdf:resource="info:fedora/CM:Collection"></hasContentModel>

Now that we know to look out for that, it's relatively easy to manage for, but was not obvious at first.

Since version 2.11.0 requests expects header attributes to be of type str or bytes:
https://github.com/kennethreitz/requests/blob/fb014560611f6ebb97e7deb03ad8336c3c8f2db1/requests/utils.py#L754

eulfedora specify the verify attribute as a bool:
https://github.com/emory-libraries/eulfedora/blob/master/eulfedora/api.py#L91

This causes requests to raise InvalidHeader exceptions when eulfedora uses it.

pycrypto is insecure and deprecated in favor of pycryotodome

please see pycrypto/pycrypto#238

First, thanks for this project, which we've been using for a while.

Is this project still active? Are any PRs going to be accepted? I have forked the project and added some commits - is there any interest in a PR?

The homepage states that Eulfedora is compatible with Fedora Commons versions up to version 3.8. Is this information still up-to-date? Are there any plans to support current versions of Fedora?

https://github.com/emory-libraries/eulfedora/blob/master/eulfedora/models.py#L181
Seems like it should say imgfile.read()... is that correct?