by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Björn Grüning
@bgruening
@TKlingstrom what is userlibs2/ that does not look like a path?
Martin Cech
@martenson
try using absolute paths
Tomas
@TKlingstrom
@bgruening , it was what I set the folder location to.
user_library_import_dir: userlibs2/
Björn Grüning
@bgruening
as @martenson said try a full-path - like /tmp/ or something
Tomas
@TKlingstrom
All the default options listed in the Galaxy configuration were relative paths so I thought it was the preferred option
Martin Cech
@martenson
when it works, it is, but we are debugging now
Tomas
@TKlingstrom
I'll try it tonight as soon as the kids sleep, thank you.
Tomas
@TKlingstrom
This message was deleted
Daniel Blankenberg
@blankenberg
Also hit an issue again with the uwsgi wheel on my mac, as mentioned by @mvdbeek, but i am on python 2.7.15. galaxyproject/galaxy#6470
Marius van den Beek
@mvdbeek
but for you it's pcre that's erroring out, right ?
mine's libexpat
(getting an update from brew didn't help)
galaxybot
@galaxybot
[dan] updating my brew before didn't help either, i just force installed the standard uwsgi
[dan] same sort of error as before
Daniel Blankenberg
@blankenberg
ImportError: dlopen(/Users/me/git/galaxy/.venv/lib/python2.7/site-packages/uwsgi.so, 2): Library not loaded: /usr/local/opt/pcre/lib/libpcre.1.dylib
Referenced from: /Users/me/git/galaxy/.venv/lib/python2.7/site-packages/uwsgi.so
Reason: image not found
Marius van den Beek
@mvdbeek
huh, at least for python 3 we're not even building wheels in starforge-recipes. that's a little weird
Marius van den Beek
@mvdbeek
too many environments, can't reproduce this right now
Daniel Blankenberg
@blankenberg
Does seem to be a strange outcome. At least manually installing uwsgi gets things going for me, but I can’t imagine that there is something terribly unique about my setup.
Marius van den Beek
@mvdbeek
did you try brew unlink pcre && brew link pcre ?
Daniel Blankenberg
@blankenberg
Did not, but brew info does show it as not being installed for me.
presumably manually installing it would work, but should it be required?
Marius van den Beek
@mvdbeek
no clue, seems like statically linking could be done during the build ?
Daniel Blankenberg
@blankenberg
That might be the correct thing to do.
pvanheus
@pvanheus
has anyone seen a _remove_dead_weakref error from planemo? I'm trying to test a new data manager I'm working on and hitting it (as in: https://gist.github.com/pvanheus/4269f262dfb5ccc99082cd0bcca42a88) - this is on Ubuntu 18.04 with a fresh planemo virtualenv...
this is normally something I see when I mix a conda python with a virtualenv - but there is no conda involved here...
Jennifer Hillman-Jackson
@jennaj
@martenson is this the best method? Do you want to recommend anything else? re: uploading large datasets in a local https://biostar.usegalaxy.org/p/29319/
pvanheus
@pvanheus
@jennaj they could something like the from-user-directory library import? https://galaxyproject.org/data-libraries/#from-user-folder
(and then use "link files instead of copying" if the user-folder stuff is going to be permanent)
Tomas
@TKlingstrom
I also got a library problem
Running a docker with the command:
docker run -p 8084:80 --name Ebba4 -v galaxy-test2:/export/ -e "GALAXY_CONFIG_BRAND=Friday" -e "GALAXY_CONFIG_USER_LIBRARY_IMPORT_DIR=/export/userlib" -e "GALAXY_CONFIG_USER_LIBRARY_IMPORT_DIR_AUTO_CREATION=true" bgruening/galaxy-stable
(absolut path due to debugging after previous chat with @martenson and Björn for debug)
The folder shows up perfectly as expected and are created when new users signs up.
But the library folders are not accessible through the GUI
Martin Cech
@martenson
@jennaj @pvanheus I suspect metadata is what slows them down
Jennifer Hillman-Jackson
@jennaj
@pvanheus I wasn't sure if that worked anymore. There are also the new collection uploader methods introduced in 18.05 ... but I don't think any of those keep galaxy from eventually ... well, what martin just said :)
pvanheus
@pvanheus
@martenson ah yes, it will scan that massive file. also if it is imported as fastq instead of fastq.gz it will be unpacked.
Jennifer Hillman-Jackson
@jennaj
right, the unpacking takes time. there is some chat about that, e.g. not unpacking if the file is .gz
pvanheus
@pvanheus
yes, but you need to explicitely select to store as gz - and I'm never sure which is the better option - of course, for disk space, compressed is good - but it will be unpacked to analyse anyway..
Jennifer Hillman-Jackson
@jennaj
I'm all for that - it isn't obvious that one should set the datatype during upload to a gz format to preserve that and not unpack
true
not all legacy tools accept gz .. likely only a problem on some public sites like .org
pvanheus
@pvanheus
but gz or not, that metadata scanning is going to take time. and I don't think that can be disabled.
Jennifer Hillman-Jackson
@jennaj
I don't think so either but suspect that someone, somewhere has hacked their Galaxy to not do it .. and take on all the risks involved with that (directly assigning metadata without some sanity checks)
pvanheus
@pvanheus
@jennaj add "fastq-withfakeseqcount" datatype with no sequence counting (because the slow part is this: https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/datatypes/sequence.py#L553) :)
Jennifer Hillman-Jackson
@jennaj
funny and probably useful for local servers with a lot of production throughput. the data probably goes through some type of validator/firewall even before going into Galaxy anyway
but don't change the public sites! please :)
since we started doing more sniffing, errors rooted all the way back to a problematic upload have reduced significantly, so it helps