| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0006178 | Spring engine | General | public | 2019-03-20 11:34 | 2019-03-25 23:36 | ||||
| Reporter | sprung | ||||||||
| Assigned To | abma | ||||||||
| Priority | low | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 104.0 +git | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0006178: SpringFiles seems not to classify recent maps correctly | ||||||||
| Description | I have been told to report here. SpringFiles seems not to classify recently uploaded maps correctly. Here are the latest entries: https://springfiles.com/spring/spring-maps/mini-super-speed-metal-wide-fix https://springfiles.com/spring/spring-maps/bridge-1 https://springfiles.com/spring/spring-maps/blockfort https://springfiles.com/spring/spring-maps/passe-muraille-defense https://springfiles.com/spring/spring-maps/ziggurat-defense They belong to the [Spring > Spring Maps] category correctly but that's what the uploader selects. However, SF also does some classification on its own (in particular, it detects whether the repo is a map https://github.com/springfiles/upq/blob/master/jobs/extract_metadata.py#L273 ) and this is what matters when accessing SF maps through its API ( https://api.springfiles.com/?category=map ), none of these maps show up there (not present in https://api.springfiles.com/files/maps/ either). Apparently this can happen legitimately with solid archives but at least some of these aren't solid. | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | Irrelevant | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
abma (administrator) 2019-03-25 23:34 |
https://github.com/springfiles/upq/commit/c2c02998932e35ce862300513a822d04193678bd thanks for reporting! |
|
abma (administrator) 2019-03-25 23:35 |
very likely some os update broke it: the code before worked as it was. :-| |
|
abma (administrator) 2019-03-25 23:36 |
for the reference, traceback was: 2019-03-25 23:30:48,380 ERROR upq.upqqueuemngr.new_job() l.148 : (download) couldn't load module: Traceback (most recent call last): File "/home/upq/upq/upqqueuemngr.py", line 141, in new_job upqjob_class = module_loader.load_module(jobname) File "/home/upq/upq/module_loader.py", line 29, in load_module module = imp.load_module(name, fp, pathname, description) File "/home/upq/upq/jobs/download.py", line 16, in <module> import requests File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 97, in <module> from . import utils File "/usr/lib/python2.7/dist-packages/requests/utils.py", line 42, in <module> if platform.system() == 'Windows': File "/usr/lib/python2.7/platform.py", line 1333, in system return uname()[0] File "/usr/lib/python2.7/platform.py", line 1300, in uname processor = _syscmd_uname('-p','') File "/usr/lib/python2.7/platform.py", line 1035, in _syscmd_uname rc = f.close() IOError: [Errno 10] No child processes |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-03-20 11:34 | sprung | New Issue | |
| 2019-03-25 22:52 | abma | Assigned To | => abma |
| 2019-03-25 22:52 | abma | Status | new => assigned |
| 2019-03-25 23:34 | abma | Status | assigned => resolved |
| 2019-03-25 23:34 | abma | Resolution | open => fixed |
| 2019-03-25 23:34 | abma | Note Added: 0019893 | |
| 2019-03-25 23:35 | abma | Note Added: 0019894 | |
| 2019-03-25 23:36 | abma | Note Added: 0019895 | |
| Issue History |