Check for changes then forcibly mv in javareconf.in #84

mbargull · 2019-06-16T21:20:52Z

Checklist

Used a fork of the feedstock to propose changes
Bumped the build number (if the version is unchanged)
Reset the build number to 0 (if the version changed)
Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
Ensured the license file is being packaged.

addresses (=not completely fixes) gh-67

EDIT: This patch does the following:

Remove the rm -f from the previous patch, so that the mv -f is the only write operation to the final files.
Retain the mv => mv -f from the previous patch.
Check if the files need to be written to at all, i.e., check if the sed command's output via cmp -s against the current file content. If no change is detected, the file is not written to at all.
Suggested by @mingwandroid: change the temporary file extension from .new to .$$ (i.e., add the PID of the current process instead of the constant new string).

Point 1. (+2.) and 3. both independently help to reduce/avoid concurrent writes and thus combining them should only reduce the overall failure probability even more.
In the (unlikely) case that the Java configuration did change and thus the cmp -s from point 3. fails, point 4. is to avoid concurrent creation of the same temporary files.

conda-forge-linter · 2019-06-16T21:20:58Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

mbargull · 2019-06-16T21:22:25Z

recipe/0017-Check-for-changes-then-forcibly-mv-in-javareconf.in.patch

     ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" > "${file}.new"
     if test -f "${file}.new"; then
 -	mv "${file}.new" "${file}"
-+	if test -f "${file}"; then
-+	    rm -rf "${file}" >/dev/null 2>&1


@mingwandroid, in which cases do you think the rm -rf ... ; mv -f is necessary, rather than just a simple mv -f?

Should be fine. What do you think to using instead of .new using .$$? doesn't work so well in these docker days sometimes but still worth doing too I think?

I'm not sure. I'll have to think about it for a minute. I guess it should be fine.

Yeah, I'll update it to use $$. No harm in doing so, I guess.

mbargull · 2019-06-16T21:23:35Z

NB: this isn't tested at all.

mbargull · 2019-06-16T21:39:04Z

recipe/0017-Check-for-changes-then-forcibly-mv-in-javareconf.in.patch

     ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" > "${file}.new"
     if test -f "${file}.new"; then
 -	mv "${file}.new" "${file}"
-+	if test -f "${file}"; then
-+	    rm -rf "${file}" >/dev/null 2>&1
-+	fi
 +	mv -f "${file}.new" "${file}"
     else
 	echo "*** cannot create ${file}.new~*** Please run as root if required.~" | ${SED-sed} -e 'y/~/\n/' >&2


...~" | ${SED-sed} -e 'y/~/\n/' >&2

Just saw that now -- made me laugh :D.

mbargull · 2019-06-16T21:44:12Z

@conda-forge-admin, please rerender

…da-forge-pinning 2019.06.09

mingwandroid · 2019-06-16T22:00:10Z

Nice @mbargell, many thanks as always. I'll try to test it out, but does anyone have good pointers for how to reproduce this? I have no NFS, but regardless, I don't think this will make things any worse.

dpryan79 · 2019-06-17T14:00:25Z

The easiest way to test this is to use something like snakemake to invoke a bunch of R processes (2 will usually suffice) at once.

mbargull · 2019-06-17T15:29:01Z

It can be reproduced on Linux with

conda create -qynr -c conda-forge r-rjava
num_processes=48 ; seq "${num_processes}" | xargs -P"${num_processes}" -L1 bash -lc 'conda activate r && R -e "library(rJava)" 2>&1 1>/dev/null'

You may need to adjust num_processes. For me, it failed more often with podman running on fuse-overlayfs since that has a slower I/O perf.
You can also "simulate" slow rm/mvs by putting some rm/mv scripts in ${CONDA_PREFIX}/bin that sleep a bit before running the actual rm/mv.

It runs just as I expected with the new patch:

Removing the rm from the old patch reduces the rate of concurrent (=failing) mv/rm operations significantly.
The additional cmp -s guard avoids those concurrent mv/rm operations altogether. (That is, when the java configuration didn't change -- the case that I expect to happen almost any time.)

mbargull · 2019-06-17T15:54:37Z

@pbordron, @RodrigoGM, @lecorguille, @NTLx, @Fedorov113, @Finesim97, @valscherz, @johanneskoester, @epruesse, @dpryan79:
If you are able to reproduce gh-67 and are able to give the patch from this PR a try, please feel free to report whether it resolves the issue.
In the file lib/R/bin/javareconf it replaces

    ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" > "${file}.new"
    if test -f "${file}.new"; then
	if test -f "${file}"; then
	    rm -rf "${file}" >/dev/null 2>&1
	fi
	mv -f "${file}.new" "${file}"
    else
	echo "*** cannot create ${file}.new~*** Please run as root if required.~" | ${SED-sed} -e 'y/~/\n/' >&2
	exit 1
    fi

with

    ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" | cmp -s - "${file}" || {
    ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" > "${file}.$$"
    if test -f "${file}.$$"; then
	mv -f "${file}.$$" "${file}"
    else
	echo "*** cannot create ${file}.$$~*** Please run as root if required.~" | ${SED-sed} -e 'y/~/\n/' >&2
	exit 1
    fi
    }

mbargull · 2019-06-17T16:27:00Z

recipe/build.sh

-        curl --insecure -C - -o ${DLCACHE}/miktex-portable-${MIKTEX_VER}.exe -SLO https://miktex.org/download/ctan/systems/win32/miktex/setup/windows-x86/miktex-portable-${MIKTEX_VER}.exe || true
+        # From https://miktex.org/download#portable :
+        #   Please note that there is no seperate installer. Just download the standard installer and rename it to miktex-portable.exe.
+        curl --insecure -C - -o ${DLCACHE}/miktex-portable-${MIKTEX_VER}.exe -SL https://miktex.org/download/ctan/systems/win32/miktex/setup/windows-x86/basic-miktex-${MIKTEX_VER}.exe || true


@conda-forge/r-base

I'm a monkey and don't know what I'm doing here, so PTAL ;)

The old URL didn't work, so I updated it.

Removed the -O flag since it's redundant with -o-.

The old miktex-portable-${MIKTEX_VER}.exe URL scheme doesn't work anymore; now it's just basic-miktex-${MIKTEX_VER}.exe or the unversioned miktex-portable.exe.

(Temporarily?) Copied the the note from their website to avoid future head scratches about that.

Well, turns out a simple 7za x doesn't cut it anymore. Now the installer contains an archive with still packed components. Running the installer with --portable should do it. See https://docs.miktex.org/manual/setupwiz.html.

johanneskoester · 2019-06-17T17:13:57Z

Thanks a lot @mbargull!

mbargull · 2019-06-17T17:16:31Z

@johanneskoester, you're welcome! I can imagine you have quite a number of downstream snakemakers that bug you with this ;).

Fedorov113 · 2019-06-17T19:17:50Z

@pbordron, @RodrigoGM, @lecorguille, @NTLx, @Fedorov113, @Finesim97, @valscherz, @johanneskoester, @epruesse, @dpryan79:
If you are able to reproduce gh-67 and are able to give the patch from this PR a try, please feel free to report whether it resolves the issue.
In the file lib/R/bin/javareconf it replaces

    ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" > "${file}.new"
    if test -f "${file}.new"; then
	if test -f "${file}"; then
	    rm -rf "${file}" >/dev/null 2>&1
	fi
	mv -f "${file}.new" "${file}"
    else
	echo "*** cannot create ${file}.new~*** Please run as root if required.~" | ${SED-sed} -e 'y/~/\n/' >&2
	exit 1
    fi

    ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" | cmp -s - "${file}" || {
    ${SED-sed} -e "s|JAVA =.\{0,\}|JAVA = $JAVA|" -e "s|JAVA_HOME =.\{0,\}|JAVA_HOME = ${JAVA_HOME}|" -e "s|: \${JAVA_HOME=.\{1,\}|: \${JAVA_HOME=${JAVA_HOME}}|" -e "s|: \${R_JAVA_LD_LIBRARY_PATH=.\{1,\}|: \${R_JAVA_LD_LIBRARY_PATH=${JAVA_LD_LIBRARY_PATH_SH}}|" -e "s|JAVA_LIBS =.\{0,\}|JAVA_LIBS = ${JAVA_LIBS}|g" -e "s|JAVA_LD_LIBRARY_PATH =.\{0,\}|JAVA_LD_LIBRARY_PATH = ${JAVA_LD_LIBRARY_PATH}|" -e "s|JAVAC =.\{0,\}|JAVAC = $JAVAC|" -e "s|JAVAH =.\{0,\}|JAVAH = $JAVAH|" -e "s|JAR =.\{0,\}|JAR = $JAR|" -e "s|JAVA_CPPFLAGS =.\{0,\}|JAVA_CPPFLAGS = ${JAVA_CPPFLAGS}|g"  "${file}" > "${file}.$$"
    if test -f "${file}.$$"; then
	mv -f "${file}.$$" "${file}"
    else
	echo "*** cannot create ${file}.$$~*** Please run as root if required.~" | ${SED-sed} -e 'y/~/\n/' >&2
	exit 1
    fi
    }

I can confirm that this patch works! Tested on my usual setup: cluster execution with snakemake through drmaa, spawning 10-30 jobs in parallel.

dpryan79 · 2019-06-18T14:04:37Z

I can also confirm that this fixes the problem (using 100 parallel R jobs via snakemake).

mingwandroid · 2019-06-18T14:48:47Z

Very cool! Shall we merge?

johanneskoester · 2019-06-18T14:52:06Z

Yes please!

dpryan79 · 2019-06-18T14:55:38Z

Is it passing on Windows (not that I care about Windows)?

mbargull · 2019-06-18T15:18:13Z

Is it passing on Windows (not that I care about Windows)?

Nope. Pushed a shady temporary workaround that should be removed as soon as possible. (Or, if someone is willing to put up the time and nerve, the overall build process on Windows should be made more resilient/with less hacks)

mingwandroid · 2019-06-18T15:24:14Z

TexLive seems pretty broken to me. I've spent a while trying to fix it so that it finds it's configuration files but it isn't currently playing ball.

Miktex changes the way they distribute their stuff basically every time we rebuild R too. It really is a rock and a hard place.

mbargull · 2019-06-18T15:26:05Z

recipe/build.sh

+        #   MIKTEX_VER=2.9.7100
+        #   curl --insecure -C - -o ${DLCACHE}/basic-miktex-${MIKTEX_VER}.exe -SL https://miktex.org/download/ctan/systems/win32/miktex/setup/windows-x86/basic-miktex-${MIKTEX_VER}.exe || true
+        #   echo "Extracting basic-miktex-${MIKTEX_VER}.exe, this will take some time ..."
+        #   ${DLCACHE}/basic-miktex-${MIKTEX_VER}.exe --portable=${PWD} --unattended --no-registry || exit 1


This works on a local Windows machine. The progress is displayed with a GUI, though, so tough luck inspecting it on the CI...
The installer does something on the CI, as seen by 6e29463 which outputs:

Extracting basic-miktex-2.9.7100.exe, this will take some time ... du: cannot access './*': No such file or directory 0 total ======================== 11885 ./texmfs 11885 total ======================== 66684 ./texmfs 66684 total ======================== 147410 ./texmfs 147410 total ======================== 244796 ./texmfs 244796 total ======================== 373200 ./texmfs 373200 total ======================== 426704 ./texmfs 426704 total ======================== 437725 ./texmfs 437725 total ======================== 437725 ./texmfs 437725 total ======================== ...

but it obviously hangs somewhere...

mbargull · 2019-06-18T15:30:44Z

Miktex changes the way they distribute their stuff basically every time we rebuild R too. It really is a rock and a hard place.

Doesn't sound like fun at all. Maybe it makes sense for you to create come intermediate build packages such that you can use them in requirements/build and copy stuff over from a Conda package where possible. That way you'd only have to fight that battle when you recreate/update those helper packages instead of for every R build.

…da-forge-pinning 2019.06.18

mbargull · 2019-06-18T17:19:26Z

@msarahan: All Windows builds failed with

concurrent.futures.process._RemoteTraceback: 
"""
Traceback (most recent call last):
  File "C:\Miniconda36-x64\lib\shutil.py", line 544, in move
    os.rename(src, real_dst)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\tmp0pg1q4fm\\info\\about.json' -> 'C:\\bld\\win-64\\.cache\\about\\r-base-3.5.1-hdf77c54_1007.tar.bz2.json'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "C:\Miniconda36-x64\lib\concurrent\futures\process.py", line 175, in _process_worker
    r = call_item.fn(*call_item.args, **call_item.kwargs)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\index.py", line 1274, in _extract_to_cache
    _cache_info_file(tmpdir, 'about.json', about_cache_path)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\index.py", line 847, in _cache_info_file
    move(info_path, cache_path)
  File "C:\Miniconda36-x64\lib\shutil.py", line 559, in move
    os.unlink(src)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\tmp0pg1q4fm\\info\\about.json'
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "C:\Miniconda36-x64\Scripts\conda-build-script.py", line 10, in <module>
    sys.exit(main())
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\cli\main_build.py", line 445, in main
    execute(sys.argv[1:])
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\cli\main_build.py", line 436, in execute
    verify=args.verify, variants=args.variants)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\api.py", line 209, in build
    notest=notest, need_source_download=need_source_download, variants=variants)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\build.py", line 2299, in build_tree
    notest=notest,
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\build.py", line 1596, in build
    newly_built_packages = bundlers[pkg_type](output_d, m, env, stats)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\build.py", line 1029, in bundle_conda
    update_index(os.path.dirname(output_folder), verbose=metadata.config.debug)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\index.py", line 323, in update_index
    current_index_versions=current_index_versions)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\index.py", line 1015, in index
    subdir, verbose=verbose, progress=progress)
  File "C:\Miniconda36-x64\lib\site-packages\conda_build\index.py", line 1164, in index_subdir
    fn, mtime, size, index_json = future.result()
  File "C:\Miniconda36-x64\lib\concurrent\futures\_base.py", line 425, in result
    return self.__get_result()
  File "C:\Miniconda36-x64\lib\concurrent\futures\_base.py", line 384, in __get_result
    raise self._exception
PermissionError: [Errno 13] Access is denied: 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\tmp0pg1q4fm\\info\\about.json'
Command exited with code 1

Since I don't want to delay this PR anymore and am not able/willing to investigate, I just forced the CI to use conda-build=3.17 by avoiding the current 3.18 versions. Let's see if this will build successfully.
(That hack will automatically be ineffective if either a new conda-build version is released on conda-forge or the feedstock is rerendered.)

mbargull · 2019-06-18T18:13:35Z

@conda-forge/r-base: If you are fine with the shady/temporary workarounds in
82295ac#diff-44a73bcc045c193c3bd45da87994b03bR337
and
e59a242 (#84 (comment)),
feel free to merge.

isuruf · 2019-06-18T20:29:20Z

Thanks

lecorguille · 2019-06-19T13:53:41Z

I don't have quickly any test to validate this PR.
But thanks for all the effort on this issue.

My question is what next?
Are all the R conda packages have to be rebuild to get this fix?

dpryan79 · 2019-06-19T13:56:18Z

@lecorguille Just update r-base in your envs, nothing needs to be rebuilt otherwise.

lecorguille · 2019-06-19T13:58:06Z

And for new envs, they will target this new build?

dpryan79 · 2019-06-19T14:02:05Z

In general they should, yes. Conda does some complicated things when deciding which builds to use, but all things being equal it'll take a higher build number (i.e., this one).

mbargull added 2 commits June 16, 2019 23:14

0017-Check-for-changes-then-forcibly-mv-in-javareconf.in.patch

cebab79

bump build number

e835a6b

mbargull commented Jun 16, 2019

View reviewed changes

update javareconf.in.patch to use .$$

3652bdf

MNT: Re-rendered with conda-build 3.18.2, conda-smithy 3.3.7, and con…

848e9f4

…da-forge-pinning 2019.06.09

fix typo in javareconf.in.patch

6575cc3

Windows: update MIKTEX_VER=2.9.7100

911605c

mbargull force-pushed the issue-67-javareconf branch from 328e45e to 911605c Compare June 17, 2019 16:19

mbargull commented Jun 17, 2019

View reviewed changes

Windows: MiKTeX installer is no simple 7z SFX anymore

36bc2be

mbargull added 4 commits June 17, 2019 23:11

Mingw_w64_makefiles: try conda instead of conda.bat

29dc98e

Windows: try crude setup monitor

6e29463

Mingw_w64_makefiles: try "${SYS_PYTHON}" -m conda instead of conda

45396d1

Windows/MiKTeX: maybe --no-registry? IDK what stalls...

18581d3

Windows/MiKTeX: ugly temporary workaround using web.archive.org

82295ac

mbargull commented Jun 18, 2019

View reviewed changes

MNT: Re-rendered with conda-build 3.17.8, conda-smithy 3.3.7, and con…

c0fe36b

…da-forge-pinning 2019.06.18

mbargull mentioned this pull request Jun 18, 2019

Rebuild for gsl-2.5 #85

Closed

madness: try conda-build=3.17 by forcing conda-build'<3.18.0|>3.18.2'

e59a242

mbargull force-pushed the issue-67-javareconf branch from 92fb516 to e59a242 Compare June 18, 2019 17:21

isuruf merged commit 554c57f into conda-forge:master Jun 18, 2019

valscherz added a commit to metagenlab/zAMP that referenced this pull request Jun 19, 2019

conda-force up in env def. for conda-forge/r-base-feedstock#84

fa6dfc6

valscherz mentioned this pull request Jun 19, 2019

Can't open /miniconda3/622b4111/lib/R/etc/ldpaths metagenlab/zAMP#1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Check for changes then forcibly mv in javareconf.in #84

Check for changes then forcibly mv in javareconf.in #84

mbargull commented Jun 16, 2019 •

edited

Loading

conda-forge-linter commented Jun 16, 2019

mbargull Jun 16, 2019

mingwandroid Jun 16, 2019

mbargull Jun 16, 2019

mbargull Jun 16, 2019

mbargull commented Jun 16, 2019

mbargull Jun 16, 2019

mbargull commented Jun 16, 2019

mingwandroid commented Jun 16, 2019

dpryan79 commented Jun 17, 2019

mbargull commented Jun 17, 2019 •

edited

Loading

mbargull commented Jun 17, 2019 •

edited

Loading

mbargull Jun 17, 2019

mbargull Jun 17, 2019

johanneskoester commented Jun 17, 2019

mbargull commented Jun 17, 2019 •

edited

Loading

Fedorov113 commented Jun 17, 2019

dpryan79 commented Jun 18, 2019

mingwandroid commented Jun 18, 2019

johanneskoester commented Jun 18, 2019

dpryan79 commented Jun 18, 2019

mbargull commented Jun 18, 2019

mingwandroid commented Jun 18, 2019

mbargull Jun 18, 2019

mbargull commented Jun 18, 2019

mbargull commented Jun 18, 2019

mbargull commented Jun 18, 2019

isuruf commented Jun 18, 2019

lecorguille commented Jun 19, 2019

dpryan79 commented Jun 19, 2019

lecorguille commented Jun 19, 2019

dpryan79 commented Jun 19, 2019

Check for changes then forcibly mv in javareconf.in #84

Check for changes then forcibly mv in javareconf.in #84

Conversation

mbargull commented Jun 16, 2019 • edited Loading

conda-forge-linter commented Jun 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbargull commented Jun 16, 2019

Choose a reason for hiding this comment

mbargull commented Jun 16, 2019

mingwandroid commented Jun 16, 2019

dpryan79 commented Jun 17, 2019

mbargull commented Jun 17, 2019 • edited Loading

mbargull commented Jun 17, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johanneskoester commented Jun 17, 2019

mbargull commented Jun 17, 2019 • edited Loading

Fedorov113 commented Jun 17, 2019

dpryan79 commented Jun 18, 2019

mingwandroid commented Jun 18, 2019

johanneskoester commented Jun 18, 2019

dpryan79 commented Jun 18, 2019

mbargull commented Jun 18, 2019

mingwandroid commented Jun 18, 2019

Choose a reason for hiding this comment

mbargull commented Jun 18, 2019

mbargull commented Jun 18, 2019

mbargull commented Jun 18, 2019

isuruf commented Jun 18, 2019

lecorguille commented Jun 19, 2019

dpryan79 commented Jun 19, 2019

lecorguille commented Jun 19, 2019

dpryan79 commented Jun 19, 2019

mbargull commented Jun 16, 2019 •

edited

Loading

mbargull commented Jun 17, 2019 •

edited

Loading

mbargull commented Jun 17, 2019 •

edited

Loading

mbargull commented Jun 17, 2019 •

edited

Loading