{23} Trac comments (3729 matches)

Results (1701 - 1800 of 3729)

← 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 →
Ticket Posixtime Author Newvalue
#1177 1307361157000000 fccoelho to upgrade I used the method describeb on bitbucket, after upgrading pip-requirements: pip -E pyenv install -r pip-requirements.txt after that I did a paster --plugin ckan db upgrade --config ckan.emap.fgv.br.ini the revision id on my pyenv/src/ckan is: 5730c79db461+ tip yes, I have restarted apached after upgrading
#1177 1307365496000000 rgrp The issue here is that the line should never be reached because g.has_commenting should be False: https://bitbucket.org/okfn/ckan/src/5730c79db461/ckan/lib/app_globals.py @Flavio: have you modded your code in any way? is self.has_commenting False in your app_globals.py A quick fix would be to remove the template lines calling to remove the lines in the template: {{{ ${h.subnav_link(c, h.icon('comments') + _('Comments & Questions'), controller='package', action='comments', id=c.pkg.name)} }}}
#1177 1307366621000000 fccoelho I have not modded the code in any way... I'll look for those lines in the template.which template is it? read.html does not have a line such as this.
#1177 1307367354000000 fccoelho OK I did an fgrep on all package template and found the line on layout.html, I'll comment the block and test.
#1177 1307367923000000 fccoelho Ok it fixed it! thanks a lot!! Is there any side effects to the removal of this line, I should know of?
#1177 1307374897000000 dread I think rgrp was suggesting you have mistakenly set has_commenting to "True" in app_globals or elsewhere. But either way, this should have no side-effects.
#1176 1310557852000000 dread This is occurring several times a day now - James can you suggest what's happening?
#1176 1314273012000000 dread This occurs when you browse {{{/error/document}}} directly, rather than being directed there on error. In this case there is no 'original_response'. Fixed in cset:c67d5934fb0b for ckan 1.4.3 and merged to default.
#1175 1307350866000000 dread Flavio, can you post here the exception that you get?
#1175 1307372833000000 fccoelho Thats the thing, I don't get any error message, no even in the logs. But I can't even load a page.
#1175 1314030683000000 dread Hi Flavio, is this still a concern? I'd like to close this ticket unless you can provide details of the error from your logs or exception email.
#1175 1325355170000000 dread This error (which will be in the apache or ckan log) must be unrelated. Stats extension runs fine elsewhere.
#1174 1307615200000000 pudo wontfix as thejimmyg wants to turn REST API into RPC API and this doesn't fit in. Not an excellent plan in my idea but this is to be discussed elsewhere.
#1173 1307000249000000 pudo I propose we do a bit of frameworkiness here: set up a two-part content type registry and refactor the API controller to use it. The idea would be to do the following things: 1. Create a registry mapping format extensions to mime types: RepresentationRegistry.add_format('json', 'application/json') 2. Create a registry of (mime types, entity types) -> converter functions that yield an appropriate representation of the entity. 3. Hook this into the _finish method of the API controller based on Accept: handling 4. Add support for /api/rest/ENTITY/NAME.{format} and /ENTITY/NAME.{format} to routing, use registry from (1) to rewrite accept headers. 5. Register converters in load_environment or via IConfigurable plugins 6. Document What do you think?
#1173 1307615271000000 pudo Now available in ckanext-rdf and linked to from WUI.
#1172 1312991332000000 dread I've started this on branch defect-1172-exceptions
#1172 1314118281000000 dread Is in cset:47225f03e2af and merged to default for 1.4.4. It now barfs instead of failing silently: * if the ckan config file has any errors * search indexing error There are some other "except Exception" statements
#1172 1314118883000000 dread I took out "raise" by mistake in ckan/lib/search/worker.py:26 but John has added it in in the corresponding place in ckan/lib/search/__init__.py on branch feature-1275-solr-search anyway.
#1171 1347358705000000 ross I have implemented this on the datahub, but this change likely needs to be made to CKAN core. Probably as part of 2.0. The format on tdh is currently: ${TITLE}. ${AUTHOR}. Retrieved ${UTC time}. ${DATASET LINK} Best discuss and agree on what format should be supported. Mark, I've assigned this to you as it is tagged academia ;)
#1170 1306864422000000 dread Done in cset:4d2d0857281f on default
#1169 1306754833000000 dread Done on default. Will appear on ckan.net next time it is branched and updated.
#1168 1310134901000000 thejimmyg This is now working on dgu-buildbot.okfn.org. The code that manages it is partly the repo.py script from http://hg.3aims.com/public/BuildKit/ and partly the fab code in https://bitbucket.org/okfn/buildbot-scripts
#1168 1310396585000000 dread This might run manually on the us7, but the buildbot is not running these automatically or any sort of testing, which is what this ticket is about.
#1168 1325866142000000 thejimmyg Quick update... we now have: * An automated way to build the deb packages * An automated way to install them into a fresh virtual machine We don't currently run them via buildbot or have smoke tests.
#1167 1306856992000000 sebbacon Yes to all the above. Further question: which extensions should be installed as standard? I would argue: * ckanext-stats * ckanext-googleanalytics * ckanext-disqus * ckanext-solr (implies installing a running solr, too...) * ckanext-follower * ckanext-admin Note that googleanalytics and disqus both require user accounts set up at the corresponding service. Not sure how we would handle this in the instance setup.
#1167 1306857142000000 sebbacon Another thing to consider: how do we ensure we keep a single, up-to-date version available? (I'm thinking wrt developer / sysadmin workflow)
#1167 1306857750000000 thejimmyg Creating the AMI is really just the icing on the cake. The hard bit is getting the packaging right so that's where we need to concentrate first. Once the packaging works we just make sure apt-get upgrade is run regularly. +1 to the list above. I also agree we should install solr by default. Who has actually done a CKAN solr install? I haven't but together with whoever has I can try to package it up. Wrt to usernames and passwords, I'll look into how dpkg manages those blue pop-up screens for entering configuration options.
#1167 1307358318000000 dread debconf seems the preferred way to question the user post-install and run setup scripts. It seems a bit of a faff. The person that is able to spin up an EC2 instance is no doubt technically able enough to follow a couple of instructions in README.txt saying edit /etc/ckan/<instancename>/<instancename>.ini and add your Google Analytics credentials. So I don't think this ticket is the driver for a debconf setup.
#1167 1311178516000000 thejimmyg I've now written a 20 page guide on using CKAN on Amazon EC2. I haven't explicitly created an AMI, but I don't think we should do that anyway for a few reasons: * it is fiddly * there is no advantage to the user as CKAN installation is so easy and so well documented * we don't want to have to maintain the image going forward * we might not want to promote a non-open approach The guide will form part of Anna PS's work on the overall documentation but you can also see the original version here: https://bitbucket.org/okfn/ckan-debs-public/src/489a5ecf369f/ec2/
#1166 1306847326000000 thejimmyg Also, rather than INSPIRE=true we should probably have information about the harvesting mechanism and the harvest object type? This also relates to our use of the kind field on the resource.
#1166 1317381932000000 amercader Fixed on d5bee3de9957
#1165 1306413953000000 nils.toedtmann this is similar, but not equal to #1096
#1165 1307444733000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1164 1308647224000000 amercader Done. See it in action here: http://publicdata.eu/map
#1161 1306408026000000 amercader Duplicate of #1157
#1159 1307615133000000 pudo Rudimentary RDFa has been added with seeAlso to API.
#1156 1306855111000000 pudo Both are now implemented but may need further work to adhere to developing conventions wrt to location etc.
#1155 1306773174000000 pudo Now implemented based on CSV export available on the catalogue page: * http://data.london.gov.uk/catalogue
#1154 1314120497000000 johnglover Fixed in core (branch feature-1275-solr-search).
#1154 1314177477000000 dread Looking at the changeset, it now does a connection check at start-up of CKAN. If it fails then CKAN runs but doesn't show any packages, apart from via the Tags interface, and the search page and widget on the front-page are removed. (BTW Is this a useful thing to do? Without search, perhaps CKAN should simply not start?) I believe the problem pudo is referring to is temporary periods when the SOLR server is slow/overloaded/down. During this time pudo and I get exception emails saying connection failed for request. e.g. {{{ Module ckan.controllers.home:29 in index << query = query_for(model.Package) query.run(query='*:*', facet_by=g.facets, limit=0, offset=0, username=c.user) c.facets = query.facets c.fields = [] >> limit=0, offset=0, username=c.user) Module ckan.lib.search.common:115 in run << self.query = QueryParser(query, terms, fields) self.query.validate() self._run() self._format_results() return {'results': self.results, 'count': self.count} >> self._run() Module ckanext.solr.backend:63 in _run << # this wrapping will be caught further up in the WUI. log.exception(e) raise SearchError(e) finally: conn.close() >> raise SearchError(e) SearchError: [Errno 111] Connection refused }}} (recently from nl.ckan.net)
#1154 1314178325000000 johnglover > Looking at the changeset, it now does a connection check at start-up of CKAN. If it fails then CKAN runs but doesn't show any > packages, apart from via the Tags interface, and the search page and widget on the front-page are removed. (BTW Is this a > useful thing to do? Without search, perhaps CKAN should simply not start?) When discussing the ticket we agreed that we should allow ckan to start without search. It is possible that people simply want to list/view information without searching for it and we decided not to prevent them from doing so. > I believe the problem pudo is referring to is temporary periods when the SOLR server is slow/overloaded/down. During this > time pudo and I get exception emails saying connection failed for request. Ok, other options then: * if an error occurs during search, return 0 results * if an error occurs during search, redirect to a generic 'search is unavailable' page * if an error occurs during search, retry the query a certain number of times before giving up and doing one of the above. What do you suggest?
#1154 1314179290000000 dread Search requests - option one seems like a bad user experience, and option three seems too complicated. I should do option 2, explain it may well be a temporary problem, and let the user press reload, as per any normal web request. A more difficult problem though is what to do about a failed search indexing. Because of the try/except catch we've had until the patch yesterday, we get no exception emails for this, but I'm worried that this has caused packages to not be indexed, and hence are essentially lost in CKAN (unless someone realises there is a problem and does a reindex at some point). BTW I added paster command 'search-index check' for looking at this problem, but I don't think it was ever added to solr. Is it easy to add get_all_entity_ids for the purpose of checking for this problem?
#1154 1314191496000000 johnglover Ok I'll implement option 2 for search query issues. Yes it is easy to get a list of IDs from Solr so I'll have a look at that command and make sure that it works. I think a case could be made for not allowing a package to be added if it cannot be indexed however, and making the user simply retry the request.
#1154 1314192324000000 dread Yes, forcing a retry may be possible, although I guess on these occasions you'd be looking at rolling back the creation of the package object too, which is not really in the spirit of the notifications system at present. This is why we had the queue for solr for occasions like this - is it here no longer?
#1154 1314192753000000 johnglover Not in core, there is a queue feature in the extension still which I could add to core. I think though it was a case of using either the queue or synchronous search, I don't think it would automatically fall back to the queue if there was an indexing problem, but we could look at that. Was there not talk of changing the queue system recently though? There are also no tests for the Solr queue so that would take a bit of work as well.
#1154 1314193633000000 johnglover RE search queries failing: Just having a look through the controller code and the package search controller and the search api both perform option 2 already, so I'll just update the home controller.
#1154 1314195684000000 dread Ok, I chatted to David about this and we feel it should go like this: notification to search indexer fails and raises an exception, this gets passed through the notification system back up to the code that creates the package, and you do a roll back. Does this tally with what you mentioned in the last comment or is what's there better? Thanks for the info on the queue and ckanext-solr. It sounds like this isn't deployed successfully anywhere (or does pudo know if it is?). In this case we should be clear that it is not what it says it is: "This extension adds support for package search using Apache Solr to CKAN" and maybe simply mark it as deprecated. Pudo what do you think?
#1154 1314196683000000 johnglover > Ok, I chatted to David about this and we feel it should go like this: notification to search indexer fails and raises an exception, > this gets passed through the notification system back up to the code that creates the package, and you do a roll back. Does this > tally with what you mentioned in the last comment or is what's there better? This sounds good to me, definitely better than what is currently there. > Thanks for the info on the queue and ckanext-solr. It sounds like this isn't deployed successfully anywhere (or does pudo > know if it is?). I'm not actually sure if the queue works or not, but if it does I'll have to write some tests for it before we could add it to core. A working queue system would be useful generally however, as there are other things that it would be useful for (such as QA), but yes, going forward the Solr extension should really be deprecated.
#1154 1314287519000000 johnglover All attempts to index packages should now throw a SearchIndexError if Solr is unavailable and the create/update will be rolled back. These errors are caught in the main package controller (redirecting to an error page) and the API controller. I have added tests for both controllers. Also updated the paster 'search-index check' command to work with solr.
#1152 1307352165000000 amercader Bumping to ckan-v1.5-sprint-3 and updating the CC email addresses so people actually get any updates.
#1151 1330908188000000 rgrp Not sure we will be able to fix this easily as we need a dataproxy for general case. Think it better to focus on the case where data in DataStore and we use Recline. As such closing as wontfix for the present.
#1150 1311178163000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one too please? Cheers, James
#1150 1311774141000000 johnglover Unicode data should be fine in the new datapreview code, for example: http://test.ckan.net/package/afghanistan-election-data
#1149 1305971672000000 kindly cset:b1634d405066
#1149 1306090663000000 kindly Failed dgu tests due to as_dict not working on deleted objects. fixed by cset:c9b9cf513e44
#1148 1305969925000000 kindly complete cset:96a43c9d8bd7
#1143 1307024681000000 dread All done in ckanext-stats cset:bc54790cacd4 (apart from "fix x axis to start at first revision" which was not a problem after all)
#1142 1305880901000000 sebbacon The guys at Wikimedia also produced this spreadsheet including notable users and features of other software. Could be useful.: https://spreadsheets2.google.com/ccc?authkey=CLWu1cgP&hl=en&key=tYiwc9kUVLLlALOQEzFqujw&hl=en&authkey=CLWu1cgP#gid=0
#1142 1305881244000000 lucychambers Replying to [ticket:1142 rgrp]: > Previous super ticket (from 3m ago): http://trac.ckan.org/ticket/927 > > * CKAN 1-page overview (for enterprise and for data hackers) > * Administrator's Guide (including install) > * Extensions Guide > * Separate CKAN.net info from Software Documentation (?) > > == Minor Items == > * Include guide on how to configure local filesystem storage, instead of Google storage. (http://lists.okfn.org/pipermail/ckan-discuss/2011-May/001235.html)
#1142 1308326118000000 annapowellsmith List of new docs tasks agreed by APS and RGRP: * Tutorial on the wiki (long-term): Integration with Wordpress and Drupal and Javascript * Overview of domain model both for average users and for devs * 2-page glossy brochure * Vision for CKAN http://notebook.okfn.org/2011/04/27/data-hubs-data-management-systems-and-ckan/ * Comparison : use http://wiki.ckan.net/Related_Software as starting point - build on wiki - Socrata and OGDI * Renaming: separation between ckan.org and ckan.net * More documentation in the code ... * Config options generated from code or move this to WUI ... See also proposed overhaul at http://wiki.ckan.net/Documentation_Plans
#1142 1313775665000000 rgrp This was completed 4 weeks ago and can now be marked as complete. See http://docs.ckan.org/ and http://wiki.ckan.net/ and http://ckan.org/
#1141 1308828928000000 dread I've merged this into default in preparation for release 1.4.2, but there may be a couple of useful additions that could be done on this or another branch/ticket. Getting a package at a specified revision is really useful. This can be used: * links in the package history (#103) (while in there, the 'moderated' flag should be shown in the package history too if not already) * should also be added to the package API (as a replacement for the AJAX call?) The history_ajax call looks like an almost duplicate of the Package Revision API. Can these be merged and put just in the API?
#1141 1318862183000000 dread What's the status of this now? The ckanext-moderatededits README still says you need a branch of ckan. Can you say which version of CKAN is required instead? I say we close this if ajax call is now in a better place in the API. (I expect it is now, with the logic layer).
#1141 1318862773000000 johnglover Well, it runs on datacatalogs.org with the current default so CKAN 1.5, but it needs quite a bit of updating to work with all of the new 1.5 UI changes, and as it has been a low priority for quite a while I haven't scheduled time to work on it. Really I would need to spend a few days on it to tidy it up for standard 1.5.
#1141 1325352507000000 dread Closing, with remaining tidy up work for newer CKAN versions split off into new ticket: #1604
#1140 1312491320000000 kindly fixed cset:987da68ea4f6 The package group table needed to trigger a reindex of the package.
#1140 1312537257000000 dread Broken since CKAN v1.1. I have added this fix to v1.4.2 and v1.4.3 releases.
#1138 1316965357000000 rgrp Cannot see this issue any more on default (as deployed on e.g. test).
#1137 1305211672000000 rgrp Most of this change has been implemented in the changeset branch [1] but could be backported reasonably easily to main. [1]: https://bitbucket.org/okfn/vdm/src/changeset/
#1137 1305217449000000 kindly I am not sure this needs to be done. I think we should keep the continuity object always in the table, even if it is deleted. The querying should be done through the logic layer so the deleted state should not be an issue. The clients should be entirely state aware. The only thing that needs to be done is to remove all statefullness of relations. These are the only things that are complicated. This would make vdm just a simple copy on write mechanism, with the client controlling the state.
#1136 1305210925000000 rgrp Most of this change has been implemented in the changeset branch [1] but could be backported reasonably easily to main. [1]: https://bitbucket.org/okfn/vdm/src/changeset/
#1136 1305216218000000 kindly This would be nice but it is not necessary. The current mapper implementation may be nice but not is battle tested..
#1136 1305217553000000 kindly Replying to [comment:2 kindly]: > This would be nice but it is not necessary. The current mapper implementation may be nice but not is battle tested.. I meant the mapper extension "IS" battle tested.
#1136 1340632980000000 icmurray Re-assigned to @kindly.
#1135 1305210134000000 rgrp Work on this is largely complete in changeset branch: https://bitbucket.org/okfn/vdm/src/changeset/ Overview docs: https://bitbucket.org/okfn/vdm/src/changeset/doc/changeset.rst
#1135 1340632267000000 icmurray Re-assigned to kindly
#1134 1305125228000000 thejimmyg Great stuff. Yes, I agree with all this, but as initial thoughts I suggest that for phase 1, the info() method returns one more key called "form_config_interface" which takes a string representing a the type of interface for the config field on the form. If the key is missing it is treated as "None". The two possible values are: None - the field is not present and must always be stored as NULL Text - a single text field will be provided on the interface Whatever the interface, the value built will always be stored in the config column of the table. We then also provide a "get_schema()" method that returns a schema cablable of parsing the data submitted by the form and storing it as a single key named "config". ckanext-inspire will then add other functions to the schema for URL etc so that regardless of what the harvest plugin does, the key fields ckanext-harvest are always there. This then allows: * Customiseable config interfaces * Customisable valiation * A consistent place to store config in the database Sound good?
#1134 1305623531000000 sebbacon Agreed with James that we should consider *from the start* how to provide for a nice UI -- my worry is if we start out with people editing raw JSON we'll end up keeping that for years :)
#1133 1324057072000000 dread Works for me - change occurs successfully. {{{ (pyenv-ckan)dread@dread-laptop:~/gitroot/ckan$ paster rights add russianfan admin warandpeace /home/dread/gitroot/pyenv-ckan/lib/python2.6/site-packages/pylons/templating.py:610: UserWarning: Unbuilt egg for setuptools [unknown version] (/usr/lib/python2.6/dist-packages) Engine = entry_point.load() User russianfan -> is admin on -> Package warandpeace (pyenv-ckan)dread@dread-laptop:~/gitroot/ckan$ paster rights /home/dread/gitroot/pyenv-ckan/lib/python2.6/site-packages/pylons/templating.py:610: UserWarning: Unbuilt egg for setuptools [unknown version] (/usr/lib/python2.6/dist-packages) Engine = entry_point.load() 22 results User visitor -> is editor on -> Package annakarenina User logged_in -> is editor on -> Package annakarenina User testsysadmin -> is admin on -> System system User logged_in -> is editor on -> System system User visitor -> is reader on -> Group david User annafan -> is admin on -> Package annakarenina AuthorizationGroup anauthzgroup -> is reader on -> Package warandpeace User visitor -> is editor on -> Package warandpeace AuthorizationGroup anauthzgroup -> is editor on -> Group david User logged_in -> is editor on -> Package warandpeace User logged_in -> is reader on -> Group david User visitor -> is reader on -> Group roger User logged_in -> is reader on -> Group roger User russianfan -> is admin on -> Package warandpeace User visitor -> is admin on -> Package warandpeace AuthorizationGroup anotherauthzgroup -> is editor on -> AuthorizationGroup anauthzgroup User russianfan -> is admin on -> Group roger User russianfan -> is admin on -> Group david AuthorizationGroup anauthzgroup -> is admin on -> AuthorizationGroup anotherauthzgroup User visitor -> is anon_editor on -> System system User visitor -> is admin on -> Group roger AuthorizationGroup anauthzgroup -> is editor on -> System system }}} Tests would be nice, but it currently works, is only for admins and is therefore not as high priority as other other tests, such as front-end js.
#1132 1307352675000000 dread Yes, these are apparently search-related and so are skipped when testing under sqlite. See README.rst for more info. Compare with this: {{{ $ nosetests --ckan --with-pylons=test-core.ini ckan/tests/functional/test_authz.py ............................................ ---------------------------------------------------------------------- Ran 44 tests in 69.287s OK }}}
#1131 1305537897000000 dread Fixed on branch release-v1.3.5 cset:3461ed6bab0c
#1130 1340633514000000 icmurray Unassign for triage.
#1129 1305116419000000 thejimmyg Great proposal, here's my thinking: * The current VDM model (where we have things like a single package table which logs changes to a package_revision table) is very well tested and works well and we should only consider a radical change with good reason * Although we are making a move from *model objects* being the central components to the *logic layer functions* being the central components, there is no need yet to have the database structures we store (for revisioning or otherwise) start to look like the dictized representation. The logic layer itself is designed to do that mapping. * Since we do have this logic layer though, there is less need for "magic" SQLAlchemy objects to support dicts and lists (eg the stateful objects used to make a list of tags on a package behave like a list), a few simple (and easily debuggable) queries in the logic layer would work better. In the longer term we may want to look at serialising more dictized-looking objects and that may lend itself to a more dictized changeset model or even a more dictized storage system (eg no-SQL) but for the time being we are not at that point. I recommend the following: * We continue to use the current default branch of VDM (not the changeset branch) * We continue to treat the package table (and other non-revision tables) as the most recent revision (even though the *active* revision displayed in CKAN might well be in the revision tables because more recent changes haven't been moderated yet) * We slowly stop using stateful lists and dicts in CKAN because we have move control with explicit queries in the logic layer Sound good?
#1129 1305139980000000 rgrp It seems like this ticket is getting a bit confused with ticket:1076 (changes re vdm) :-) Some general conclusions relevant to both: * General feeling is not to change to changeset model * I'm personally +0 on changeset model * I would note main benefit is simplicity and orthogonality of changesets to core system. I also think cost of change is small. * That said we can simplify current model as well. * There seems some misunderstanding: change to have logic layer has almost nothing to do with being able to remove main stateful stuff in vdm. To be able to remove most of stateful stuff in vdm requires us to make some other changes (re foreign keys from revision objects to continuity) * There are other simplifications we should make to vdm before embarking on this (e.g. move to SessionExtension from MapperExtension). This is easy as that work has been done in changeset branch and can be backported. What I don't see in this CEP as yet is any discussion of the complexities around pending stuff (e.g. do we allow multiple pending, do new edits get shown current or latest pending). I'll try and comment more on this but a lot of this was in original vdm discussion last summer.
#1129 1305209601000000 rgrp Replying to [comment:2 rgrp]: > It seems like this ticket is getting a bit confused with ticket:1076 (changes re vdm) :-) I of course ;0 meant ticket:1077
#1129 1305212467000000 kindly > * There seems some misunderstanding: change to have logic layer has almost nothing to do with being able to remove main stateful stuff in vdm. To be able to remove most of stateful stuff in vdm requires us to make some other changes (re foreign keys from revision objects to continuity) The logic layer does not automatically help out, however it makes our life easier if we want to handle state ourselves. For example take package tags, if we remove the stateful_m2m properties and just use normal sqlalchemy relations. We will still want statefullness (i.e active, pending, deleted) on the package_tags table. We should update those on the table ourselves in the logic layer. > * There are other simplifications we should make to vdm before embarking on this (e.g. move to SessionExtension from MapperExtension). This is easy as that work has been done in changeset branch and can be backported. I agree but event thought the MapperExtension way is not great, it is very well field tested.
#1129 1325268100000000 rgrp More UI work remains in #1141
#1128 1310567803000000 dread Loader in ckanext/bin/loadscotland.py. Done upload to ckan.net: {{{ (pyenv-ckanext)dread@dread-laptop:~/hgroot/ckanext$ scotland_loader -k xyz -H http://ckan.net/api /home/dread/ckan-local/data/scotland-2010-10-18.csv /home/dread/hgroot/pyenv-ckanext/lib/python2.6/site-packages/pylons/templating.py:610: UserWarning: Unbuilt egg for setuptools [unknown version] (/usr/lib/python2.6/dist-packages) Engine = entry_point.load() No handlers could be found for logger "vdm" 2011-07-13 15:29:17,983 INFO [ckanext.importlib.loader] Loading scottish_neighbourhood_statistics 2011-07-13 15:29:20,109 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:22,089 INFO [ckanext.importlib.loader] Loading traveline_scotland 2011-07-13 15:29:24,579 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:27,045 INFO [ckanext.importlib.loader] Loading sqa_qualifications 2011-07-13 15:29:30,869 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:32,561 INFO [ckanext.importlib.loader] Loading scotxed 2011-07-13 15:29:34,017 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:35,286 INFO [ckanext.importlib.loader] Loading iscjis_vocabularies 2011-07-13 15:29:36,592 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:37,782 INFO [ckanext.importlib.loader] Loading ecare_multi-agency_store_data_model_and_vocabulary 2011-07-13 15:29:39,043 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:40,267 INFO [ckanext.importlib.loader] Loading digital_archive_scottish_archive_network 2011-07-13 15:29:41,690 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:43,727 INFO [ckanext.importlib.loader] Loading the_scottish_register_of_tartans 2011-07-13 15:29:45,159 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:46,816 INFO [ckanext.importlib.loader] Loading scotlands_images 2011-07-13 15:29:48,563 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:49,983 INFO [ckanext.importlib.loader] Loading national_library_of_scotland 2011-07-13 15:29:51,709 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:53,122 INFO [ckanext.importlib.loader] Loading scottish_government_statistics 2011-07-13 15:29:55,857 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:57,118 INFO [ckanext.importlib.loader] Loading scotbis 2011-07-13 15:29:58,883 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:00,264 INFO [ckanext.importlib.loader] Loading historic_scotland 2011-07-13 15:30:02,086 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:03,609 INFO [ckanext.importlib.loader] Loading scheduled_monuments_in_scotland 2011-07-13 15:30:05,057 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:06,987 INFO [ckanext.importlib.loader] Loading scotlands_house_prices_service_consumer_information 2011-07-13 15:30:08,687 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:09,932 INFO [ckanext.importlib.loader] Loading air_quality_in_scotland 2011-07-13 15:30:11,278 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:12,637 INFO [ckanext.importlib.loader] Loading river_and_coastal_flooding_updates_for_scotland 2011-07-13 15:30:13,940 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:15,637 INFO [ckanext.importlib.loader] Loading public_contracts_scotland 2011-07-13 15:30:17,280 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:18,666 INFO [ckanext.importlib.loader] Loading scottish_government_consultations 2011-07-13 15:30:20,673 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:22,234 INFO [ckanext.importlib.loader] Loading scottish_public_health_observatory 2011-07-13 15:30:24,025 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:26,297 INFO [ckanext.importlib.loader] Loading scotlands_information_landscape 2011-07-13 15:30:28,308 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:29,758 INFO [ckanext.importlib.loader] Loading isd_scotland 2011-07-13 15:30:31,847 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:33,074 INFO [ckanext.importlib.loader] Loading scotlandspeople 2011-07-13 15:30:34,541 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:35,754 INFO [ckanext.importlib.loader] Loading general_register_office_for_scotland_statistics 2011-07-13 15:30:37,273 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:39,330 INFO [ckanext.importlib.loader] Loading baseline_scotland_-_groundwater_chemistry_data 2011-07-13 15:30:40,716 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:41,919 INFO [ckanext.importlib.loader] Loading the_centre_for_the_study_of_retailing_in_scotland_data_sets 2011-07-13 15:30:43,275 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:44,515 INFO [ckanext.importlib.loader] Loading growing_up_in_scotland 2011-07-13 15:30:46,215 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:47,582 INFO [ckanext.importlib.loader] Loading scottish_parliament_msp_allowances 2011-07-13 15:30:49,580 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:51,272 INFO [ckanext.importlib.loader] Loading scottish_government_ministerial_hospitality 2011-07-13 15:30:53,764 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:55,642 INFO [ckanext.importlib.loader] Loading scottish_government_expenditure_over_25000 2011-07-13 15:30:58,012 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:59,674 INFO [ckanext.importlib.loader] Loading scottish_local_government_financial_statistics 2011-07-13 15:31:01,869 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:03,382 INFO [ckanext.importlib.loader] Loading scottish_government_disclosure_of_high_earners 2011-07-13 15:31:07,086 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:11,493 INFO [ckanext.importlib.loader] Loading scotlands_places 2011-07-13 15:31:14,452 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:31,743 INFO [ckanext.importlib.loader] Loading scottish_national_heritage_facts 2011-07-13 15:31:36,223 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:37,830 INFO [ckanext.importlib.loader] Loading scottish_natural_spaces 2011-07-13 15:31:40,245 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:41,764 INFO [ckanext.importlib.loader] Loading scotland_national_address_gazetteer 2011-07-13 15:31:43,810 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:45,069 INFO [ckanext.importlib.loader] Loading scottish_environment_protection_agency 2011-07-13 15:31:47,975 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:49,525 INFO [ckanext.importlib.loader] Loading traffic_scotland 2011-07-13 15:31:52,396 INFO [ckanext.importlib.loader] ...creating package }}}
#1128 1310568028000000 dread Note, I added a title column and made one or two minor corrections that I spotted - see attached CSV for the result.
#1127 1304602084000000 wwaites The proposal is not comparable to PEP and DEP because the projects have vastly different requirements. The API stability needs of a programming language or an operating system (e.g. fundamental building blocks that you don't expect to change often or radically) are very different from a web application. The plone one is comparable. The idea itself is a double-edged sword. It will promote stability which is good but can also tend towards rigidity and stagnation which is bad. Each added bit of bureaucracy and process means fewer people will be willing to collaborate or participate in improving the software. Overall, -1.
#1127 1304606094000000 dread Fixed links
#1127 1305128000000000 thejimmyg This is great idea and it has taken on well. +1 from me. We can update/create new CREP policies as needed.
#1127 1305458020000000 rgrp I'm obviously a strong +1 but feel we should stick with the CEP name (we have PEP and DEP and CREP really does sound weird compared to CEP). Also I think we may need to do a bit more to clarify when you just do a good ticket and when one does a CEP (looking at what has occurred already). I think this may be one reason to keep CEPs separate in drafting from trac as will clearly distinguish CEPs from standard tickets.
#1127 1305458489000000 rgrp one other thing: i think the plan is for CEPs to be in restructured text (for easy transfer to docs). This should be mentioned and the template in the wiki should be in ReST.
#1126 1304587078000000 dread Fixed in cset:61bb142a6b7c for ckan v1.3.5.
#1124 1304601771000000 nils.toedtmann I installed the python-ckanext-solr package rom http://apt-alpha.ckan.org/datanl-dev onto us10/DataGM too, and it seems to work just fine, see http://datagm.test.ckan.net/package?q=manchester
#1124 1323168132000000 thejimmyg Solr is now properly supported in the ckan-1.5 repository.
#1124 1323168156000000 thejimmyg Re-open this if it still affects DataGM.
#1123 1307374691000000 dread I'll change the architecture to "all" as per this article: http://linuxreviews.org/man/deb-control/
#1123 1307790563000000 thejimmyg This isn't necessarily a trivial thing. Let's get the build system for the packages stable before we start changing it all to support alternative architectures. Once the packaging is working well it would be trivial to switch those servers to amd64. I'm sorry, but this isn't worth the investment in manpower at the moment.
← 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 →
Note: See TracReports for help on using and creating reports.