Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 11:40
    jfallmann closed #18110
  • 11:39
    jfallmann review_requested #18110
  • 11:38
    biocondabot[bot] commented #18108
  • 11:36
    mjsteinbaugh closed #18111
  • 11:36
    mjsteinbaugh review_requested #18111
  • 11:26
    biocondabot[bot] commented #18111
  • 11:17
    biocondabot[bot] commented #18112
  • 11:15
    althonos commented #17923
  • 11:15
    biocondabot[bot] commented #18041
  • 11:08
    biocondabot[bot] commented #18110
  • 11:05
    micknudsen synchronize #18092
  • 11:03
    BiocondaBot labeled #18112
  • 11:03
    BiocondaBot labeled #18112
  • 11:03
    BiocondaBot opened #18112
  • 11:03
    BiocondaBot closed #15495
  • 11:03
    BiocondaBot labeled #18111
  • 11:03
    BiocondaBot labeled #18111
  • 11:03
    BiocondaBot opened #18111
  • 11:01
    biocondabot[bot] commented #18109
  • 10:58
    lucventurini commented #18108
Pablo Moreno
@pcm32
ahhh, I was wondering given the message of the lack of free executors whether it might be related to that.
Devon Ryan
@dpryan79
The word from CircleCI is that there was a bug on their end yesterday that they think was causing our issues. I've looked at the queue this morning and it looks like we haven't had any "build error" issues in 8-9 hours, so it seems things are back to normal.
Please note that there's a nightly cron job that goes through all of the packages and tries to build and upload those for which such problems arose, so don't be concerned that these will never be built.
Devon Ryan
@dpryan79
Actually, I'll merge everything into the bulk branch after my morning "review and merge all the PRs" run. That will ensure things get pushed out a bit sooner.
Pablo Moreno
@pcm32
Thanks @dpryan79 that would be great!
Devon Ryan
@dpryan79
I'm doing this now :)
Pablo Moreno
@pcm32

Hi there, I’m getting a weird issue when doing conda build <local-recipe>. In the recipe one of the previous dependencies was scanpy ==1.3.7 and after changing that to scanpy >=1.4.2 I get now this weird error:

Solving environment: ...working... failed
failed to get install actions, retrying.  exception was: Unsatisfiable dependencies for platform noarch: {'scanpy==1.3.7', "scanpy[version='>=1.4.2']"}
WARNING:conda_build.build:failed to get install actions, retrying.  exception was: Unsatisfiable dependencies for platform noarch: {'scanpy==1.3.7', "scanpy[version='>=1.4.2']”}

even though the 1.3.7 line is not there anymore. It used to be as well that we were calling as dependency another package which dependend itself on scanpy 1.3.7, but I have removed that as well and the same error keeps coming back. Is there a cache or something that I should be getting rid of? Any advice appreciated! Thanks!

Pablo Moreno
@pcm32
conda clean -a didn’t help… in the end changing the version of the recipe itself did the trick, there is some additional caching somewhere that doesn’t get cleaned… go figure.
Pablo Moreno
@pcm32
Hi! Although tests have passed, the linting is stuck here: bioconda/bioconda-recipes#18024 can the biocondabot be invoked to do something?
Pablo Moreno
@pcm32
We have an issue with execution of a python program that uses click in python 3.7 inside the mulled container. Somewhere the software requires UTF-8 encoding locale but apparently this is not available in the container… is there a workaround to add the locale to the container when the recipe container is being built?
Nicola Soranzo
@nsoranzo
Is that for testing on CircleCI?
Pablo Moreno
@pcm32
Thanks @nsoranzo ! What if it is not only for testing on CircleCI?
Nicola Soranzo
@nsoranzo
You shouldn't see the issue on a "normal" computer
It normally happens in reduced container images
Pablo Moreno
@pcm32
No, we see it inside the container (we run tools inside the mulled containers).
Nicola Soranzo
@nsoranzo
You surely know more about containers than me, I doubt I can give you any advice there!
Devon Ryan
@dpryan79
@pcm32 Please use the extended container for any recipes that use click
Have a look at the multiqc recipe as an example, since it's the one I always look at when I forget how to deal with click :P
Nicola Soranzo
@nsoranzo
It's the same as for the planemo recipe I linked above.
I think the issue is the mulled container should also be "extended"
Alexander Peltzer
@apeltzer
@BiocondaBot autobump sexdeterrmine
Bioconda Bot
@BiocondaBot
@apeltzer: Scheduled autobump check of recipe(s) sexdeterrmine
@apeltzer: Scheduled autobump check of recipe(s) sexdeterrmine
Jim Procter
@foreveremain
@bgruening #javapackaging - any advice about differentiating java 8 and java 11+ compatible builds of the same package ? After merge of #18028 I now realise conda-jalview-2.11 isn't compatible with Jupyter java kernels, which may be a blocker for a handful of people.
Björn Grüning
@bgruening
Which version does Jupyter need?
Jim Procter
@foreveremain
java 11+ - the beakerx kernel relies on java9+ features. the source distribution can do both java 8 and java 11, but I assumed most people would prefer the official java 8 build for now.
Björn Grüning
@bgruening
We could simply depend on openjdk>=9 in this case, isn't it?
Jim Procter
@foreveremain
certainly - a minor patch to the build script will be needed though.
alternatively the build could produce both java8 and java11 jars, and the jalview.sh can determine which one to run based on what is available - leaving it to the installee to decide whether they want to use the java 11 version.
Björn Grüning
@bgruening
we could build against multiple Java version, but this involves some small work on our pinnings and our build-env. It is possible but not sure if worth the pain.
Jim Procter
@foreveremain
:D all for avoiding pain.
Björn Grüning
@bgruening
;)
Jim Procter
@foreveremain
I'll hack a new jalview.sh that will determine which java is available and pick the appropriate jar - the downside is bytecode duplication (jalview-all-j1.8.jar and jalview-all-j11.jar) but it means that anyone can easily to spin up jupyter+beakerx+jalview on mybinder.
Björn Grüning
@bgruening
But currently you will get OpenJDK 8 no matter what you do if you are using conda
foreveremain @foreveremain thinks we may need to get a room
Jim Procter
@foreveremain
yes - If the runtime requirement is changed to openjdk>=1.8_152 then people could pick their own preference ?
Björn Grüning
@bgruening
In this case yes
Nice user-name btw.
Jim Procter
@foreveremain
thank you ! :)
Björn Grüning
@bgruening
You have all my support! :)
Jim Procter
@foreveremain
We can only hope ! (or march!) .. meanwhile - PR will be on the way.
Björn Grüning
@bgruening
March >> Hope!
Jim Procter
@foreveremain
#18080 is now building - is there a way to run tests under two different deployment scenarios ?
Björn Grüning
@bgruening
not really
Johannes Köster
@johanneskoester
@BiocondaBot autobump rust-bio-tools
Bioconda Bot
@BiocondaBot
@johanneskoester: Scheduled autobump check of recipe(s) rust-bio-tools
@johanneskoester: Scheduled autobump check of recipe(s) rust-bio-tools
Johannes Köster
@johanneskoester
@BiocondaBot autobump snakemake
Bioconda Bot
@BiocondaBot
@johanneskoester: Scheduled autobump check of recipe(s) snakemake