text:
Peak picking some MS levels only

Thank you for ThermoRawFileParser, which I happily use on Linux.
It seems that peak picking is either activated on all scans or none, using -p. Unless I have missed it, it would be great to be able to apply peak picking only on some, use-defined MS levels. My typical use case would be to do it on MS2 scans and leave the MS1 scans in profile. I am using the latest release 1.3.3.

Hi @lgatto,
That is correct, it is either all centroided (default) or all profile, if it is present ( -p ). The feature you request can be implemented in the next release.

That would be great, thank you.
Is there a release data for the next one, or is it whenever it is ready?

No, we do not have the release date yet, but if you comfortable using prerelease build and/or build TRFP from the source, you can get it faster.

Thanks, will do.

Are there any build instructions available somewhere?

I don't think we have official building instructions, but in principle, it is just cloning the repository and building with msbuild, assuming you have complete mono installation. For older versions of mono xbuild should be used instead.
Below is the excerpt from the Dockerfile I use locally, the compiled version will be in /home/biodocker/build/bin/x64/Debug/
    git clone -b master --single-branch --depth 1 https://github.com/compomics/ThermoRawFileParser /home/biodocker/build
    msbuild /home/biodocker/build

There is a Dockerfile included in the repository, it should work as well.

It ran
git clone -b master --single-branch --depth 1 https://github.com/compomics/ThermoRawFileParser
cd ThermoRawFileParser
msbuild

Which seemed successful. But
$ mono bin/x64/Debug/ThermoRawFileParser.exe --version
1.3.3

still indicates version 1.3.3 and I can't spot anything in the documentation about picking peaks in some MS levels.

The feature is still to be implemented. I will update the issue when it will be ready. Sorry for the confusion.

Ah ok, thanks.

273ff2cfaf6ad1b8e270e87a111fa23b94046c17 implements the feature
The -p|--noPeakPicking now supports additional value argument limiting it to some MS levels, the argument can be a list of numbers or intervals (including open) separated by commas, for example
just -p (no value defined) - no peak picking for all MS levels
-p=2- - no peak picking for MS2 and higher
-p=1,3,5 - no peak picking for level MS1, MS3, and MS5
-p=1 - no peak picking for MS1 only
Please, note, that due to the limitation of the command line parsing library optional arguments has to be defined without white spaces, i.e. any of -p=1,2,3, -p:1,2,3, -p1,2,3 will work, but -p 1,2,3 won't.
You can build it from branch 1.4.0, i.e.
git clone -b 1.4.0 --single-branch --depth 1 https://github.com/compomics/ThermoRawFileParser

Yes, I confirm it works. Thanks!

This feature is available in version 1.3.4

authors: caetera lgatto nielshulstaert

repo: compomics/ThermoRawFileParser


text:
Extend available options

This request extends existing parameters to allow

separators of the decimal part of the number
brackets as negative markers
negativeOut to be controlled separately for left and right markers
I have kept these changes to work alongside the old options so this part is backward compatible

The other change that I have made is to expect the input decimal char to be ".".
This is on the basis that the input should be unformatted "computer" format.
I've also written lots of tests to both check some of the existing functionality and the new.
FYI My plan is to create another 'project' to use deconstruct-number-format  to pass parameters to this

Merged as 2bd079372a1880af7565e232b72a8582b25660f2 along with a change to how you override the units and separators.  N.B. this will be a breaking change so we will have to check for any places we currently call format-number to ensure that they work.

thanks.
I'll carry out the review

source: gharchive/pull-request

authors: DeeLindesay ForbesLindesay

repo: componitable/format-number

license_type: permissive

license_source: bigquery


text:
Added files for blog page

Main Changes

Added new layout page for blog in _layouts folder.
Added 3 sample post based on the figma design in _post folder.
Added 3 images from figma, under assests/images/blog

Screen shot of the page

Let me know if any changes or improvements are required !

This PR is associated with issue #95

@gaurovgiri Thank you for the feedback, I have added the requested changes !

Changes

Now blog card only show Excerpt, whole blog is in the next page
Made the whole card clickable
Made the title color to match with other pages
Updated nav.html to support asset management. src="{{ site.baseurl }}/assets/images/logo.png" (This fixed an issue of logo not showing up ion redirected blog pages)

My suggestion we can create a new issue for the redirected blog page, if yes i can create the issue and work on it.
Let me know regarding these changes .

Changes

FIxed the card sizing issue by adding css and Truncate the excerpt to the first 10 words so cards can maintain uniform size

@BISHALTWR Let me know if this commit works

Thank you guys for the approvals and feedbacks, Looking forward to contribute more !

license: MIT

license_source: github-api


text:
As a creator I want to assign permissions per department

Extension of #48 & #63
Acceptance criteria:

[ ] When assigning permissions as a creator, there should be a button "Assign permissions to department"
[ ] Those permissions are valid for all new and existing users, that are part of that department

Department list with checkboxes and more. Maybe add here or are part of another CMS user story.

source: gharchive/issue

authors: DevPhilB eddifab

repo: conclurer/midnightboard


text:
Usability enhancements

Make game harder to guess [#151102389]

remedial score is any score that doesn't get a star (<33)
randomly placed target must be 30% width of target from previous target

Adjust sizes of WebViews for hints [#151150980], [#151152456], [#151152800]
Reset hint counter after showing hint [#151150991]
CODAP attribute name changes

"Challenge number" -> "Challenge" [#151148412]
"Start height above ground" -> "Height" [#151148155]

Hide feedback elements that correspond to hidden sliders [#151148376]

Height above ground
Distance up ramp

@kswenson I'm not sure moving only 30% the width of the target (at a minimum) will guarantee a big enough move. If you take a look at the story, it asks for a move of 30% of the length of the ramp. Unfortunately, I was not very clear as well. I meant the ramp runout length. We have a constant ramp runout length of 5 meters, so I probably should have requested a move of at least 5*0.30 meters as a minimum move.

@ddamelin Doh! I read the PT story for the minimum target move incorrectly. Will be fixed shortly.

authors: ddamelin kswenson


text:
Add Kansas University to partner list in footer

Added new partner to footer on home page.

@dougmartin @433eros I made one more edit to the footer. Thanks for fixing the indent issue.

@ddamelin , I'm merging this PR so we can have the master ready to release.

authors: ddamelin tejal-shah

repo: concord-consortium/rigse

license: mit


text:
In this sample project, the inspector doesn't show a controlled shadow

https://utopia.app/p/5b0c4ce1-tar-panda/

In view mode, click on one of the dots. It should be styled as "selected" (blue box shadow)
Select that dot in the navigator
look at the inspector

Expected: there's a controlled shadow section
Observed: there isn't

@maltenuhn If you edit the component, the div inside it has a controlled shadow, is that not correct?

@seanparsons Yes, once you edit the component, the inspector is correct. This ticket is about this divergence:

if you edit/isolate the component and the select the outermost div it renders, it shows you the background set to '#FF00AA', the border set to 1px solid white, and the boxShadow as controlled
if you only select the component (without editing/isolating it), you see the background correctly set to #ff00aa in the inspector, and the border correctly set to 1px solid white -  but the shadow section is completely empty

I believe that the shadow should also show up (as controlled) in the second case, hence this ticket.

authors: maltenuhn seanparsons

repo: concrete-utopia/utopia


text:
403 Error in Page Defaults when using REDIS for Caching

We have activated/ tested Caching with REDIS for some of our projects. - Originally in order to work around another issue with the conventional caching method.
Most aspects run fine& fast with the REDIS Cache and we would definitly like to use it in the future.
There is one Problem however, that doesn't really make sense to me, but it definitly relies on REDIS Caching to be active to occur:
Whenever you try to edit Page Default Content for any given Page Type (/dashboard/pages/types/output/edit_defaults/), you get a 403 Permission Error.
How to reproduce:

Activate Caching with REDIS via Config File.
Go to: /dashboard/pages/types
Click on the "Output" Button for any of the available Page Types

The Problem disappears as soon as you switch back to conventional Caching.

So it's not just redis it's any cache that might have a delay in read (slow filesystem, memcached), its the way the core does the session set via alias
I though i fixed this in the core but i forgot about it I guess..
you can use this override to fix it until next release
https://gist.github.com/deek87/11196937104a653d369fa2b29a56dd6a -


text:
Bugfix : error on form submission (events class not found)

(concerning jozzeh-patch-2)
When a form is submitted an error would occur (Events class not found).
This patch fixes that error and it also uses the new Events dispatch method instead of the old fire method. Fully tested
Added Events class at top of the file
+
Changed deprecated event fire method to current dispatch method
This is a bugfix and should be merged asap.

@aembler, @KorvinSzanto, @JohntheFish
This fix is fully tested and cross-checked with the approved version of form auto reply package.
https://www.concrete5.org/marketplace/addons/form-auto-reply/
The previous pull request had an error in it, because I made the pull request between 2 versions of the package.

Thanks, good catch.

authors: Jozzeh aembler


text:
Updating Express Navigation Dashboard Singlepages

This PR address issue #8558

Updates main Express navigation
Match requested styling

I think this has an older version of the dependencies in it. It installs jQuery 3.4.1, older font awesome, etc...


text:
Fix Bitrise badge

I think that it's been a while since the bitrise badge it's not displaying any useful data.
It may be necessary to also fix bitrise build workflow as well

Based on my answer on #117 I think that we can close this issue, what do you think? @cs-bruno-silva

repo: concretesolutions/kappuccino


text:
1.4.3 is available only for linux?

according to https://anaconda.org/conda-forge/annexremote .  I didn't look inside -- is there a reason or is it just adjusting the recipe?

what I mean is that there is noarch for old ones, but new arch specific only for linux

repo: conda-forge/annexremote-feedstock


text:
tag 1.6.7rc4

Checklist

[ ] Used a personal 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.

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.

authors: conda-forge-linter prjemian

repo: conda-forge/apstools-feedstock


text:
meta: use pypi as a source instead of github releases

Asyncssh stopped using github releases awhile back https://github.com/ronf/asyncssh/releases ,
which resulted in no automatic PRs since 2.5.0. Using pypi instead is more reliable and used
by most other packages. After this PR, regro-cf-autotick-bot  will automatically create a PR for 2.6.0
Fixes https://github.com/conda-forge/asyncssh-feedstock/issues/40

Checklist

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

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.

@conda-forge-admin, please rerender

Oh, looks like a new tag got pushed to https://github.com/ronf/asyncssh/releases and thus triggered https://github.com/conda-forge/asyncssh-feedstock/pull/42 :tada:
Still, it is better to depend on pypi releases, so this PR is still relevant.

@vamega Thank you! :pray:

authors: conda-forge-linter efiop

repo: conda-forge/asyncssh-feedstock


text:
@conda-forge-admin, please update circle

@conda-forge-admin, please update circle

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I updated the circle-ci deploy key and followed the project.

authors: conda-forge-linter ocefpaf


text:
@conda-forge-admin,please add bot automerge

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
N.A.
Installed packages
N.A.

Environment info
N.A.

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/brotlicffi-feedstock#7.

authors: conda-forge-linter sarthakpati

repo: conda-forge/brotlicffi-feedstock


text:
Version 2.2

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] 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)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

repo: conda-forge/capytaine-feedstock


text:
Bump to version 1.1.0.

Checklist

[ ] Used a personal 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.

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.

@conda-forge-admin, please rerender

authors: conda-forge-linter moorepants

repo: conda-forge/cyipopt-feedstock


text:
bump build and update maintainers

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] 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)
[x] Ensured the license file is being packaged.

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.

repo: conda-forge/django-jinja-feedstock


text:
MNT: Re-render the feedstock [ci skip]

Hi! This is the friendly conda-forge-admin automated user.
I've re-rendered this feedstock with the latest version of conda-smithy (2.1.1) and noticed some changes.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Remember, for any changes to the recipe you would normally need to increment the version or the build number of the package.
Since this is an infrastructural change, we don't actually need/want a new version to be uploaded to anaconda.org/conda-forge, so the version and build/number are left unchanged and the CI has been skipped.
Thanks!

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.

authors: conda-forge-admin conda-forge-linter


text:
Win

Checklist

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

@conda-forge-admin, please rerender

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.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

authors: awvwgk conda-forge-linter

repo: conda-forge/gcp-correction-feedstock


text:
update to 7.20181105

update to 7.20181105

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.
I do have some suggestions for making it better though...
For recipe:

Using toolchain directly in this manner is deprecated.  Consider using the compilers outlined here.

Is there a way to declare that this would break datalad <= 0.11.1 (yet to be released ;))?

@yarikoptic You can specify that in the datalad recipe:
https://github.com/conda-forge/datalad-feedstock/blob/master/recipe/meta.yaml#L40
using the syntax from here:
https://conda.io/docs/user-guide/tasks/build-packages/package-spec.html#package-match-specifications

p.s. did you mean datalad >= 0.11.1 ?

nope... I did mean "Breaks: datalad <= 0.11.1" to be declared within git-annex package ;)
It is a way we use in Debian to declare that some "root" package breaks some 3rd party packages relying on it. That prevents upgrade of the root package until 3rd party packages can be updated to that version which is known to tolerate such new root package.  pip doesn't have a way to do such specifications and I wouldn't be surprised if conda neither.  In that page I found nothing to declare it.
It comes quite handy, and could be used in conda e.g. for recent keyring/keyrings.alt ... at least it is easy to quickly push new release (of keyrings.alt in that case) but some user systems might remain broken until they are upgraded in full

@yarikoptic I don't think conda supports this.  If git-annex versions followed https://semver.org/ you could declare datalad dependence on the current major version and know it won't break the spec; but git-annex doesn't.  The solution is to update recipes for past datalad versions with new build numbers, adding a constraint on git-annex version.

@yarikoptic Do you want to hold off on merging this git-annex update until you do that?

Since we have them only got Linux, probably don't bother - majority if not all tests should be passing and we will issue a bug fix soon for datalad

authors: conda-forge-linter notestaff yarikoptic

repo: conda-forge/git-annex-feedstock


text:
add host dependency on scotch

ipopt links scotch directly, meaning it should track version pins. Lacking this leads to installation with incompatible libscotch at runtime, resulting in:
    import cyipopt
../../../miniconda3/envs/test/lib/python3.12/site-packages/cyipopt/__init__.py:12: in <module>
    from ipopt_wrapper import *
E   ImportError: dlopen(/Users/runner/miniconda3/envs/test/lib/python3.12/site-packages/ipopt_wrapper.cpython-312-darwin.so, 0x0002): symbol not found in flat namespace '_SCOTCH_errorPrint'

This is reported in the conda build output:
WARNING (ipopt,lib/libipopt.so.3.14.16): Needed DSO lib/libesmumps.so found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
WARNING (ipopt,lib/libipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
WARNING (ipopt,lib/libipopt.so.3.14.16): Needed DSO lib/libscotch.so.7.0.4 found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
WARNING (ipopt,lib/libipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
WARNING (ipopt,lib/libipopt.so.3.14.16): Needed DSO lib/libscotcherr.so found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
WARNING (ipopt,lib/libipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

Past builds will need to be patched via repodata to match whatever scotch they were built with

Thanks!

This is the correct dependency for how ipopt is build, but I think I was a bit hasty, because I think the actual fix is to remove the linking to scotch and metis, since only mumps is used directly.

It seems that there are also still warnings in the CI:
2024-09-26T07:16:15.3615297Z WARNING (ipopt,lib/libsipopt.so.3.14.16): Needed DSO lib/libesmumps.so found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
2024-09-26T07:16:15.3617003Z WARNING (ipopt,lib/libsipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
2024-09-26T07:16:15.3623372Z WARNING (ipopt,lib/libsipopt.so.3.14.16): Needed DSO lib/libscotch.so.7.0.4 found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
2024-09-26T07:16:15.3625076Z WARNING (ipopt,lib/libsipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
2024-09-26T07:16:15.3630865Z WARNING (ipopt,lib/libsipopt.so.3.14.16): Needed DSO lib/libscotcherr.so found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
2024-09-26T07:16:15.3632424Z WARNING (ipopt,lib/libsipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

I think everything works anyway as we have a run dependency on scotch==7.0.4 that itself depends on libscotch==7.0.4, but eventually we could also link libscotch directly.

It seems that there are also still warnings in the CI:
2024-09-26T07:16:15.3615297Z WARNING (ipopt,lib/libsipopt.so.3.14.16): Needed DSO lib/libesmumps.so found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
2024-09-26T07:16:15.3617003Z WARNING (ipopt,lib/libsipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
2024-09-26T07:16:15.3623372Z WARNING (ipopt,lib/libsipopt.so.3.14.16): Needed DSO lib/libscotch.so.7.0.4 found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
2024-09-26T07:16:15.3625076Z WARNING (ipopt,lib/libsipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
2024-09-26T07:16:15.3630865Z WARNING (ipopt,lib/libsipopt.so.3.14.16): Needed DSO lib/libscotcherr.so found in ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5']
2024-09-26T07:16:15.3632424Z WARNING (ipopt,lib/libsipopt.so.3.14.16): .. but ['conda-forge/linux-64::libscotch==7.0.4=h2fe6a88_5'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

I think everything works anyway as we have a run dependency on scotch==7.0.4 that itself depends on libscotch==7.0.4, but eventually we could also link libscotch directly.

But this will be superseded by https://github.com/conda-forge/ipopt-feedstock/pull/112 .

authors: minrk traversaro

repo: conda-forge/ipopt-feedstock


text:
[DRAFT] Switch to use autotools upstream build system also on Windows instead of vendored CMake

*DO NOT MERGE EVEN IF GREEN, AS PROBABLY THIS MAY CHANGE THE ABI, in case this works we will wait for a new release before merging.
Checklist

[ ] Used a personal 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.

@conda-forge-admin, please rerender

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/meta.yaml) and found it was in an excellent condition.

Not bad for the first run, something compiles but then there is this failure:
2024-11-23T18:29:04.0249502Z lld-link: error: undefined symbol: dmumps_c
2024-11-23T18:29:04.0251688Z >>> referenced by Algorithm/LinearSolvers/.libs/IpMumpsSolverInterface.o:(public: __cdecl Ipopt::MumpsSolverInterface::MumpsSolverInterface(void))
2024-11-23T18:29:04.0253191Z >>> referenced by Algorithm/LinearSolvers/.libs/IpMumpsSolverInterface.o:(public: virtual __cdecl Ipopt::MumpsSolverInterface::~MumpsSolverInterface(void))
2024-11-23T18:29:04.0254253Z >>> referenced by Algorithm/LinearSolvers/.libs/IpMumpsSolverInterface.o:(private: enum Ipopt::ESymSolverStatus __cdecl Ipopt::MumpsSolverInterface::SymbolicFactorization(void))
2024-11-23T18:29:04.0255051Z >>> referenced 5 more times
2024-11-23T18:29:04.0372308Z clang++: error: linker command failed with exit code 1 (use -v to see invocation)
2024-11-23T18:29:06.1985153Z ../../../../src/Apps/AmplSolver/AmplTNLP.cpp:18:10: fatal error: 'asl.h' file not found

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11989503242. Examine the logs at this URL for more detail.

New failure:
make[3]: Entering directory '/d/bld/ipopt_1732388316225/work/build/src/Apps/AmplSolver'
../../../../src/Apps/AmplSolver/AmplTNLP.cpp:1775:25: warning: 'strdup' is deprecated: The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _strdup. See online help for details. [-Wdeprecated-declarations]
 1775 |       suftab_[i].name = strdup(suffix_ids_[i].c_str());
      |                         ^
>>> referenced by .libs/AmplTNLP.o:(public: void * __cdecl Ipopt::AmplOptionsList::Keywords(class Ipopt::SmartPtr<class Ipopt::OptionsList> const &, class Ipopt::SmartPtr<class Ipopt::Journalist const>, void **))

lld-link: error: undefined symbol: C_val_ASL
>>> referenced by .libs/AmplTNLP.o:(char * __cdecl Ipopt::get_str_opt(struct Option_Info *, struct keyword *, char *))
>>> referenced by .libs/AmplTNLP.o:(char * __cdecl Ipopt::get_haltonerror_opt(struct Option_Info *, struct keyword *, char *))

lld-link: error: undefined symbol: D_val_ASL
>>> referenced by .libs/AmplTNLP.o:(char * __cdecl Ipopt::get_num_opt(struct Option_Info *, struct keyword *, char *))

lld-link: error: undefined symbol: I_val_ASL
>>> referenced by .libs/AmplTNLP.o:(char * __cdecl Ipopt::get_int_opt(struct Option_Info *, struct keyword *, char *))
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

Probably there is something wrong on the ampl-asl Windows package.

The asl.dll built on Windows does not export the symbols correctly.

ASL symbols are now resolved, but strdup is still not found.

Thanks, I added a patch in the latest commit.

Linking now works, now the failure is:
  line>includedir=${prefix}/include/coin-or
 Variable declaration, 'includedir' has value 'D:/bld/ipopt_1732463061264/_test_env/Library/include/coin-or'
  line>
  line>Name: Ipopt
  line>Description: Interior Point Optimizer
  line>URL: https://github.com/coin-or/Ipopt
  line>Version: 3.14.16
  line>Cflags: -I${includedir}
  line>Libs: -L${libdir} -lipopt
  line>
  line>
Path position of 'ipopt' is 1
Adding 'ipopt' to list of known packages
find: 'Optimal Solution': No such file or directory
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30157 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cpp_example.cpp
MyNLP.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 14.29.30157.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:cpp_example.exe
ipopt-3.lib
cpp_example.obj
MyNLP.obj
LINK : fatal error LNK1181: cannot open input file 'ipopt-3.lib'
WARNING: Tests failed for ipopt-3.14.16-hfa42872_10.conda - moving package to D:\bld\broken
Traceback (most recent call last):
  File "D:\Miniforge\Lib\site-packages\conda_build\build.py", line 3483, in test
    utils.check_call_env(
  File "D:\Miniforge\Lib\site-packages\conda_build\utils.py", line 404, in check_call_env
    return _func_defaulting_env_to_os_environ("call", *popenargs, **kwargs)

It seems that the import library are called ipopt.dll.lib or libipopt.la, while msvc/pkg-config expects ipopt-3.lib . I am not sure why this happens, I will try to replicate the build locally.

It seems that the import library are called ipopt.dll.lib or libipopt.la, while msvc/pkg-config expects ipopt-3.lib . I am not sure why this happens, I will try to replicate the build locally.

The renaming is probably happening in https://github.com/conda-forge/autotools_clang_conda-feedstock/blob/main/recipe/conda_build_wrapper.sh#L57, the problem is probably that the previous windows binary hardcoded the import library name to be libipopt-3.lib, but for coherence with official ipopt binaries and the installed pkg-config file it could make sense to just call it libipopt.lib.

Removing the hardcoded ipopt-3.lib from the tests, everything is working, that was less complicate then expected.

We also need to rename manually Library/lib/ipoptamplinterface.dll.lib and Library/lib/sipopt.dll.lib to Library/lib/ipoptamplinterface.lib and Library/lib/sipopt.lib, for compatibility with the installed .pc files.

This is ready to go, but to avoid any problem we can probably sync it with the future release of ipopt, see https://github.com/coin-or/Ipopt/issues/806 .

This is ready to go, but to avoid any problem we can probably sync it with the future release of ipopt, see coin-or/Ipopt#806 .

The new version of ipopt was released, this PR is now superseded by https://github.com/conda-forge/ipopt-feedstock/pull/125 .

authors: conda-forge-admin metab0t traversaro


text:
Release 4.0.0

Checklist

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

@conda-forge-admin, please rerender

Also added a run constrained on jupytelrab

Lookin' good now, thanks for the update and welcome aboard.

Looks like the CI didn't fire on main yet... will keep an eye on it...

It's up now: https://anaconda.org/conda-forge/jupyterlab-kernelspy/files?version=4.0.0

authors: bollwyvl martinRenou


text:
Remove duplicated key

xref: https://github.com/scientific-python/lazy_loader/issues/73 and error logs in https://conda-forge.org/status/#version_updates
9.00 attempts - The recipe did not change in the version migration, a URL did not hash, or there is jinja2 syntax the bot cannot handle!

Please check the URLs in your recipe with version '0.3' to make sure they exist!

We also found the following errors:

 - We found a problem parsing the recipe for version '0.3':

DuplicateKeyError('while constructing a mapping',   in "", line 35, column 3:
      home: https://pypi.org/project/l ...
      ^ (line: 35), 'found duplicate key "dev_url" with value "https://github.com/scientific-python/lazy_loader" (original value: "https://github.com/scientific-python/lazy-loader")',   in "", line 46, column 3:
      dev_url: https://github.com/scie ...
      ^ (line: 46), '\n                    To suppress this check see:\n                        http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys\n                    ', '                    Duplicate keys will become an error in future releases, and are errors\n                    by default when using the new API.\n                    ')

traceback:
  File "/home/runner/work/cf-scripts/cf-scripts/cf-scripts/conda_forge_tick/update_recipe/version.py", line 411, in update_version
    cmeta = CondaMetaYAML(raw_meta_yaml)
  File "/home/runner/work/cf-scripts/cf-scripts/cf-scripts/conda_forge_tick/recipe_parser/_parser.py", line 492, in __init__
    self.meta = self._parser.load("".join(lines))
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/main.py", line 426, in load
    return constructor.get_single_data()
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 113, in get_single_data
    return self.construct_document(node)
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 122, in construct_document
    for _dummy in generator:
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 1473, in construct_yaml_map
    self.construct_mapping(node, data, deep=True)
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 1362, in construct_mapping
    value = self.construct_object(value_node, deep=deep)
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 144, in construct_object
    data = self.construct_non_recursive_object(node)
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 185, in construct_non_recursive_object
    for _dummy in generator:
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 1473, in construct_yaml_map
    self.construct_mapping(node, data, deep=True)
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 1363, in construct_mapping
    if self.check_mapping_key(node, key_node, maptyp, key, value):
  File "/home/runner/micromamba/envs/cf-scripts/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 275, in check_mapping_key
    raise DuplicateKeyError(*args)
    ```

Thanks @bsipocz !

authors: bmcfee bsipocz


text:
chore(release): bump to version 6.0

There is #4 but I think it's reasonable to make v6.0 builds available too. Will handle #4 after this PR.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] 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.

@conda-forge-admin, please rerender

repo: conda-forge/libdispatch-feedstock


text:
Update to version 1.0.29 and enable Windows build with CMake

Checklist

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

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.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

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.

thanks!

authors: conda-forge-linter ryanvolz wolfv

repo: conda-forge/libsndfile-feedstock


text:
Delete scripts

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.

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.

authors: conda-forge-linter marcelotrevisani

repo: conda-forge/libtvm-feedstock


text:
Remove zstd runtime dependency

To avoid conflicts with the symengine package that also depends on zstd.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] 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)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

repo: conda-forge/lpython-feedstock


text:
add windows build

Checklist

[ ] Used a personal 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.

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/meta.yaml) and found it was in an excellent condition.

@conda-forge-admin rerender

authors: conda-forge-admin isuruf


text:
Try unexporting all symbols to remove libc++ dynamic link

Checklist

[ ] Used a personal 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.

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.

cc @chrisburr

authors: conda-forge-linter isuruf

repo: conda-forge/micromamba-feedstock


text:
Bump package

Checklist

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

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/meta.yaml) and found it was in an excellent condition.

authors: conda-forge-admin renan-r-santos

repo: conda-forge/poetry-conda-feedstock


text:
v1.0.2 (build 2)

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.

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.
I do have some suggestions for making it better though...
For recipe:

Whenever possible python packages should use pip. See https://conda-forge.org/docs/meta.html#use-pip

Closing because we're already on the next version!

authors: adam-iris conda-forge-linter

repo: conda-forge/pyweed-feedstock


text:
Packages installed via install.packages in R conflict with packages installed via conda.

[x] I read the conda-forge documentation and could not find the solution for my problem there.

Issue:
Packages installed via install.packages in R conflict with packages installed via conda.
Reproduction steps
Here is an example to demonstrate this problem:

Create and activate a conda environment with the r-brio package:

 ~ $ mamba create -n rtest1 r-base r-brio
<snip>
Executing transaction: done
<snip>
 ~ $ conda activate rtest1

Use R to install the brio package

~ $ Rscript -e "install.packages('brio', repos='https://cran.rstudio.com')"
trying URL 'https://cran.rstudio.com/src/contrib/brio_1.1.2.tar.gz'
Content type 'application/x-gzip' length 12069 bytes (11 KB)
==================================================
downloaded 11 KB

* installing *source* package ‘brio’ ...
<snip>
* DONE (brio)

Try to create another conda environment with the r-brio package and watch the carnage

 ~ $ mamba create -n rtest2 r-base r-brio
<snip>
Verifying transaction: /
SafetyError: The package for r-base located at /home/izahn/.conda/pkgs/r-base-4.0.5-h8cab1ac_0
appears to be corrupted. The path 'lib/R/doc/html/packages.html'
has an incorrect size.
  reported size: 2946 bytes
  actual size: 3102 bytes

done
Executing transaction: done

Cleanup
The mess (intentionally) created above can be cleaned up be deleting the environments and cleaning out unused packages:
 ~ [1] $ conda deactivate
 ~ $ mamba env remove -n rtest1

Remove all packages in environment /home/izahn/.conda/envs/rtest1:

 ~ $ mamba env remove -n rtest2

Remove all packages in environment /home/izahn/.conda/envs/rtest2:

 ~ $ conda clean --yes --all

Proposed solution
I propose that we fix this problem by creating the site-library directory when building the r-base package. Here is a demonstration showing that this solves the problem:

Create conda environment with r-brio as before

 ~ $ mamba create -n rtest1 r-base r-brio

<snip>

Finished r-base                               (00m:03s)              24 MB     28 MB/s
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

Create the site-library directory this is the crucial step

 ~ $ mkdir ~/.conda/envs/rtest1/lib/R/site-library

Activate environment and install brio with install.packages, as before

 ~ $ conda activate rtest1
 ~ $ Rscript -e "install.packages('brio', repos='https://cran.rstudio.com')"
Installing package into ‘/home/izahn/.conda/envs/rtest1/lib/R/site-library’
(as ‘lib’ is unspecified)
trying URL 'https://cran.rstudio.com/src/contrib/brio_1.1.2.tar.gz'
Content type 'application/x-gzip' length 12069 bytes (11 KB)
==================================================
downloaded 11 KB

* installing *source* package ‘brio’ ...
<snip>
* DONE (brio)

Create another conda environment including r-brio -- all good!

 ~ $ mamba create -n rtest2 r-base r-brio
<snip>
Executing transaction: done
#
# To activate this environment, use
#
#     $ conda activate rtest2
#
# To deactivate an active environment, use
#
#     $ conda deactivate

I'm happy to make a PR including the proposed change, but I wanted to propose and discuss it here first to see if there are any objections or concerns.

Details about  conda and system ( conda info ):

$ conda info

 active environment : mamba
active env location : /home/izahn/.conda/envs/mamba
        shell level : 1
   user config file : /home/izahn/.condarc

populated config files : /opt/mambaforge/.condarc
/home/izahn/.condarc
conda version : 4.10.1
conda-build version : not installed
python version : 3.9.2.final.0
virtual packages : __linux=5.12.2=0
__glibc=2.33=0
__unix=0=0
__archspec=1=x86_64
base environment : /opt/mambaforge  (read only)
conda av data dir : /opt/mambaforge/etc/conda
conda av metadata url : https://repo.anaconda.com/pkgs/main
channel URLs : https://conda.anaconda.org/conda-forge/linux-64
https://conda.anaconda.org/conda-forge/noarch
package cache : /home/izahn/.conda/pkgs
envs directories : /home/izahn/.conda/envs
/opt/mambaforge/envs
platform : linux-64
user-agent : conda/4.10.1 requests/2.25.1 CPython/3.9.2 Linux/5.12.2-arch1-1 arch/rolling glibc/2.33
UID:GID : 1000:1000
netrc file : None
offline mode : False

@izahn Thanks for the detailed example. I was able to reproduce it (copied below). My initial thoughts are:

This is only a warning. The R and r-brio installed in the environment rtest2 appear to work fine. The warning comes because the file packages.html was modified when brio was installed with install.packages(). There isn't any actual security or functionality concern, but I understand why users may be concerned when they see those messages.

I'm open to the potential of using the site-library. Other than removing this warning, I'd have to think about the potential side effects and collisions with other install directories. Also I suspect you'll get similar push back as in my PR #65.

Output from reproducing example

mamba create --yes -n rtest1 r-base r-brio
conda activate rtest1
Rscript -e '.libPaths()'
[1] "/home/jdblischak/miniconda3/envs/rtest1/lib/R/library"
Rscript -e 'find.package("brio")'
## [1] "/home/jdblischak/miniconda3/envs/rtest1/lib/R/library/brio"
Rscript -e 'library("brio")'
Rscript -e "install.packages('brio', repos='https://cran.rstudio.com')"
## ...
## Updating HTML index of packages in '.Library'
## Making 'packages.html' ... done
Rscript -e 'find.package("brio")'
## [1] "/home/jdblischak/miniconda3/envs/rtest1/lib/R/library/brio"
Rscript -e 'library("brio")'
conda deactivate

mamba create --yes -n rtest2 r-base r-brio
## ...
## WARNING Size incorrect, file modified in package cache "/home/jdblischak/miniconda3/pkgs/r-base-4.0.5-h8cab1ac_0/lib/R/doc/html/packages.html"
## ...
## SafetyError: The package for r-base located at /home/jdblischak/miniconda3/pkgs/r-base-4.0.5-h8cab1ac_0
## appears to be corrupted. The path 'lib/R/doc/html/packages.html'
## has an incorrect size.
##   reported size: 2946 bytes
##   actual size: 3102 bytes
## ...
conda activate rtest2
Rscript -e 'find.package("brio")'
## [1] "/home/jdblischak/miniconda3/envs/rtest2/lib/R/library/brio"
Rscript -e 'library("brio")'
conda deactivate

mamba env remove -n rtest1
mamba env remove -n rtest2
conda clean --yes --all

mamba create --yes -n rtest1 r-base r-brio
mkdir ~/.conda/envs/rtest1/lib/R/site-library
## mkdir: cannot create directory ‘/home/jdblischak/.conda/envs/rtest1/lib/R/site-library’: No such file or directory
echo $CONDA_PREFIX
## /home/jdblischak/miniconda3
mkdir $CONDA_PREFIX/envs/rtest1/lib/R/site-library

conda activate rtest1
Rscript -e "install.packages('brio', repos='https://cran.rstudio.com')"
## Installing package into ‘/home/jdblischak/miniconda3/envs/rtest1/lib/R/site-library’
## ...
conda deactivate
ls $CONDA_PREFIX/envs/rtest1/lib/R/site-library
## brio

mamba create --yes -n rtest2 r-base r-brio

conda info
##
##      active environment : base
##     active env location : /home/jdblischak/miniconda3
##             shell level : 1
##        user config file : /home/jdblischak/.condarc
##  populated config files : /home/jdblischak/.condarc
##           conda version : 4.10.1
##     conda-build version : 3.21.4
##          python version : 3.7.9.final.0
##        virtual packages : __linux=4.4.0=0
##                           __glibc=2.27=0
##                           __unix=0=0
##                           __archspec=1=x86_64
##        base environment : /home/jdblischak/miniconda3  (writable)
##       conda av data dir : /home/jdblischak/miniconda3/etc/conda
##   conda av metadata url : https://repo.anaconda.com/pkgs/main
##            channel URLs : https://conda.anaconda.org/conda-forge/linux-64
##                           https://conda.anaconda.org/conda-forge/noarch
##                           https://conda.anaconda.org/bioconda/linux-64
##                           https://conda.anaconda.org/bioconda/noarch
##                           https://repo.anaconda.com/pkgs/main/linux-64
##                           https://repo.anaconda.com/pkgs/main/noarch
##                           https://repo.anaconda.com/pkgs/r/linux-64
##                           https://repo.anaconda.com/pkgs/r/noarch
##           package cache : /home/jdblischak/miniconda3/pkgs
##                           /home/jdblischak/.conda/pkgs
##        envs directories : /home/jdblischak/miniconda3/envs
##                           /home/jdblischak/.conda/envs
##                platform : linux-64
##              user-agent : conda/4.10.1 requests/2.25.1 CPython/3.7.9 Linux/4.4.0-19041-Microsoft ubuntu/18.04.2 glibc/2.27
##                 UID:GID : 1000:1000
##              netrc file : None
##            offline mode : False

@izahn Thanks for the detailed example. I was able to reproduce it (copied below). My initial thoughts are:
1. This is only a warning.

The actual message says SafetyError, which at least sounds worse than a warning!

The R and r-brio installed in the environment rtest2 appear to work fine. The warning comes because the file packages.html was modified when brio was installed with install.packages(). There isn't any actual security or functionality concern, but I understand why users may be concerned when they see those messages.

I think the fundamental issue is that conda and install.packages from R should not be trying to install things in the same place. Things might work after R overwrites a conda package, but they might not, and on the face of it this sounds like a bad idea. It definitely should not be the default behavior.

2. I'm open to the potential of using the site-library. Other than removing this warning, I'd have to think about the potential side effects and collisions with other install directories.

site-library is the documented and official place to install installation-wide packages. That is why just creating that directory is enough to get R to install packages to it by default. I don't see any reason why conda should not take advantage of this standard R mechanism.

Also I suspect you'll get similar push back as in my PR #65.

Maybe, but from my perspective this is clearly a bug, and there is an easy and non-hacky solution. We should fix it!

I think the fundamental issue is that conda and install.packages from R should not be trying to install things in the same place.

I thought of a potential issue. If site-library is created when r-base is installed, how will that affect conda R recipes built with conda build? Since build.sh simply calls R CMD INSTALL --build, I think it would install the package in site-library. I think we would need to modify build.sh to specify --library to point to the current install location. Otherwise conda and install.packages() will still be writing to the same directory.
$ R CMD INSTALL --help
Usage: R CMD INSTALL [options] pkgs

Install the add-on packages specified by pkgs.  The elements of pkgs can
be relative or absolute paths to directories with the package
sources, or to gzipped package 'tar' archives.  The library tree
to install to can be specified via '--library'.  By default, packages are
installed in the library tree rooted at the first directory in
.libPaths() for an R session run in the current environment.

Maybe, but from my perspective this is clearly a bug, and there is an easy and non-hacky solution. We should fix it!

I say go for it then! Worse case scenario: the issue is better known and better documented.

Definitely need to be careful not to affect the conda build process for R packages! My first thought is to create the site-library directory in recipe/post-link.sh, and only if CONDA_BUILD is not set.

Definitely need to be careful not to affect the conda build process for R packages! My first thought is to create the site-library directory in recipe/post-link.sh, and only if CONDA_BUILD is not set. I gave it a quick stab, seems harder then I expected :-(

authors: izahn jdblischak

repo: conda-forge/r-base-feedstock


text:
libnsl.so.1 not found at runtime

[x] I read the conda-forge documentation and could not find the solution for my problem there.

Issue:
r-sf installs successfully with conda, but when I try to load the package in R, I get an error that libnsl.so.1 cannot be found.
R --quiet -e 'library(sf)'
> library(sf)
Error: package or namespace load failed for ‘sf’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/root/miniconda3/lib/R/library/sf/libs/sf.so':
  libnsl.so.1: cannot open shared object file: No such file or directory
Execution halted

This does not occur if I install the sf package as source, directly from CRAN.
Steps to reproduce:
# Run a fedora container:
podman run --rm -it registry.fedoraproject.org/fedora-toolbox:34

# Install miniconda
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
chmod +x Miniconda3-latest-Linux-x86_64.sh
./Miniconda3-latest-Linux-x86_64.sh
source ~/.bashrc

# Install r-sf
conda config --add channels conda-forge
conda config --set channel_priority strict
conda install r-sf
R -e 'library(sf)'

Where is libnsl.so.1? (ldd and find)

find /root/miniconda3/ -name 'libnsl.so.1'
/root/miniconda3/x86_64-conda-linux-gnu/sysroot/lib64/libnsl.so.1
/root/miniconda3/pkgs/sysroot_linux-64-2.12-he073ed8_14/x86_64-conda-linux-gnu/sysroot/lib64/libnsl.so.1

ldd /root/miniconda3/lib/R/library/sf/libs/sf.so
	linux-vdso.so.1 (0x00007ffc2adc0000)
	libproj.so.22 => /root/miniconda3/lib/R/library/sf/libs/../../../../libproj.so.22 (0x00007fedea99a000)
	libgdal.so.29 => /root/miniconda3/lib/R/library/sf/libs/../../../../libgdal.so.29 (0x00007fede91ce000)
	libgeos_c.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../libgeos_c.so.1 (0x00007fede9193000)
	libR.so => /root/miniconda3/lib/R/library/sf/libs/../../../lib/libR.so (0x00007fede8cb4000)
	libstdc++.so.6 => /root/miniconda3/lib/R/library/sf/libs/../../../../libstdc++.so.6 (0x00007fede8b09000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fede89c0000)
	libgcc_s.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../libgcc_s.so.1 (0x00007fede89ab000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fede87dc000)
	libsqlite3.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libsqlite3.so.0 (0x00007fede86af000)
	libtiff.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libtiff.so.5 (0x00007fede861b000)
	libcurl.so.4 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libcurl.so.4 (0x00007fede857c000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fede855b000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fede8554000)
	libcrypto.so.1.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libcrypto.so.1.1 (0x00007fede8288000)
	libtiledb.so.2.3 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libtiledb.so.2.3 (0x00007fede77d3000)
	libpoppler.so.108 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libpoppler.so.108 (0x00007fede7475000)
	libjson-c.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libjson-c.so.5 (0x00007fede745f000)
	libfreexl.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libfreexl.so.1 (0x00007fede7453000)
	libwebp.so.7 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libwebp.so.7 (0x00007fede73cb000)
	libkmlbase.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libkmlbase.so.1 (0x00007fede73aa000)
	libkmldom.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libkmldom.so.1 (0x00007fede7301000)
	libkmlengine.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libkmlengine.so.1 (0x00007fede72c6000)
	libkmlxsd.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libkmlxsd.so.1 (0x00007fede72b0000)
	libkmlregionator.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libkmlregionator.so.1 (0x00007fede72a2000)
	libexpat.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libexpat.so.1 (0x00007fede7274000)
	libxerces-c-3.2.so => /root/miniconda3/lib/R/library/sf/libs/../../../.././libxerces-c-3.2.so (0x00007fede6ed1000)
	libopenjp2.so.7 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libopenjp2.so.7 (0x00007fede6e6f000)
	libnetcdf.so.19 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libnetcdf.so.19 (0x00007fede6ce4000)
	libmfhdf.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libmfhdf.so.0 (0x00007fede6cb8000)
	libdf.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libdf.so.0 (0x00007fede6c0a000)
	libgif.so.7 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libgif.so.7 (0x00007fede6bfb000)
	libgeotiff.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libgeotiff.so.5 (0x00007fede6bc7000)
	libpng16.so.16 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libpng16.so.16 (0x00007fede6b8e000)
	libcfitsio.so.8 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libcfitsio.so.8 (0x00007fede6873000)
	libpq.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libpq.so.5 (0x00007fede6823000)
	libzstd.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libzstd.so.1 (0x00007fede6735000)
	libjpeg.so.9 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libjpeg.so.9 (0x00007fede66f7000)
	libdeflate.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libdeflate.so.0 (0x00007fede66e7000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fede66dc000)
	libspatialite.so.7 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libspatialite.so.7 (0x00007fede5f7e000)
	libdap.so.25 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libdap.so.25 (0x00007fede5de9000)
	libdapserver.so.7 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libdapserver.so.7 (0x00007fede5dd8000)
	libdapclient.so.6 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libdapclient.so.6 (0x00007fede5d90000)
	libz.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libz.so.1 (0x00007fede5d76000)
	liblzma.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../.././liblzma.so.5 (0x00007fede5d4b000)
	libicui18n.so.68 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libicui18n.so.68 (0x00007fede5a47000)
	libicuuc.so.68 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libicuuc.so.68 (0x00007fede585d000)
	libicudata.so.68 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libicudata.so.68 (0x00007fede3d1c000)
	libuuid.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libuuid.so.1 (0x00007fede3d13000)
	libpcre.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libpcre.so.1 (0x00007fede3ccd000)
	libLerc.so => /root/miniconda3/lib/R/library/sf/libs/../../../.././libLerc.so (0x00007fede3c2f000)
	libiconv.so.2 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libiconv.so.2 (0x00007fede3b49000)
	libxml2.so.2 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libxml2.so.2 (0x00007fede39e1000)
	libkea.so.1.4 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libkea.so.1.4 (0x00007fede396c000)
	libhdf5_cpp.so.200 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libhdf5_cpp.so.200 (0x00007fede38f1000)
	libhdf5.so.200 => /root/miniconda3/lib/R/library/sf/libs/../../../.././libhdf5.so.200 (0x00007fede34ec000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fedeadd1000)
	libgeos-3.9.1.so => /root/miniconda3/lib/R/library/sf/libs/../../../.././libgeos-3.9.1.so (0x00007fede3302000)
	libblas.so.3 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../../libblas.so.3 (0x00007fede12d2000)
	libgomp.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../../libgomp.so.1 (0x00007fede129c000)
	libreadline.so.8 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../../libreadline.so.8 (0x00007fede1246000)
	libpcre2-8.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../../libpcre2-8.so.0 (0x00007fede119f000)
	libbz2.so.1.0 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../../libbz2.so.1.0 (0x00007fede118b000)
	libnghttp2.so.14 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libnghttp2.so.14 (0x00007fede1162000)
	libssh2.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libssh2.so.1 (0x00007fede111d000)
	libssl.so.1.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libssl.so.1.1 (0x00007fede108c000)
	libgssapi_krb5.so.2 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libgssapi_krb5.so.2 (0x00007fede1037000)
	libkrb5.so.3 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libkrb5.so.3 (0x00007fede0f63000)
	libk5crypto.so.3 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libk5crypto.so.3 (0x00007fede0f49000)
	libcom_err.so.3 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libcom_err.so.3 (0x00007fede0f43000)
	liblz4.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././liblz4.so.1 (0x00007fede0f0f000)
	libfreetype.so.6 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libfreetype.so.6 (0x00007fede0e58000)
	libfontconfig.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libfontconfig.so.1 (0x00007fede0e11000)
	libminizip.so => /root/miniconda3/lib/R/library/sf/libs/../../../../././libminizip.so (0x00007fede0e02000)
	liburiparser.so => /root/miniconda3/lib/R/library/sf/libs/../../../../././liburiparser.so (0x00007fede0de3000)
	libkmlconvenience.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libkmlconvenience.so.1 (0x00007fede0dc2000)
	libnsl.so.1 => not found
	libhdf5_hl.so.200 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libhdf5_hl.so.200 (0x00007fede0d9b000)
	libzip.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libzip.so.5 (0x00007fede0d7d000)
	librttopo.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././librttopo.so.1 (0x00007fede0d06000)
	libcharset.so.1 => /root/miniconda3/lib/R/library/sf/libs/../../../../././libcharset.so.1 (0x00007fede0d01000)
	libgfortran.so.5 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../.././libgfortran.so.5 (0x00007fede0b56000)
	libtinfo.so.6 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../.././libtinfo.so.6 (0x00007fede0b18000)
	libkrb5support.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../.././././libkrb5support.so.0 (0x00007fede0b09000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fede0aed000)
	libquadmath.so.0 => /root/miniconda3/lib/R/library/sf/libs/../../../lib/../.././libquadmath.so.0 (0x00007fede0ab3000)

Environment (conda list):

$ conda list
# packages in environment at /root/miniconda3:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                 conda_forge    conda-forge
_openmp_mutex             4.5                       1_gnu    conda-forge
_r-mutex                  1.0.1               anacondar_1    conda-forge
binutils_impl_linux-64    2.36.1               h193b22a_2    conda-forge
binutils_linux-64         2.36                 hf3e587d_1    conda-forge
boost-cpp                 1.74.0               h312852a_4    conda-forge
brotlipy                  0.7.0           py39h3811e60_1001    conda-forge
bwidget                   1.9.14               ha770c72_0    conda-forge
bzip2                     1.0.8                h7f98852_4    conda-forge
c-ares                    1.17.2               h7f98852_0    conda-forge
ca-certificates           2021.5.30            ha878542_0    conda-forge
cairo                     1.16.0            h6cf1ce9_1008    conda-forge
certifi                   2021.5.30        py39hf3d152e_0    conda-forge
cffi                      1.14.6           py39he32792d_0    conda-forge
cfitsio                   3.470                hb418390_7    conda-forge
chardet                   4.0.0            py39hf3d152e_1    conda-forge
charset-normalizer        2.0.0              pyhd8ed1ab_0    conda-forge
colorama                  0.4.4              pyh9f0ad1d_0    conda-forge
conda                     4.10.3           py39hf3d152e_1    conda-forge
conda-package-handling    1.7.3            py39h3811e60_0    conda-forge
cryptography              3.4.7            py39hbca0aa6_0    conda-forge
curl                      7.78.0               hea6ffbf_0    conda-forge
expat                     2.4.1                h9c3ff4c_0    conda-forge
font-ttf-dejavu-sans-mono 2.37                 hab24e00_0    conda-forge
font-ttf-inconsolata      3.000                h77eed37_0    conda-forge
font-ttf-source-code-pro  2.038                h77eed37_0    conda-forge
font-ttf-ubuntu           0.83                 hab24e00_0    conda-forge
fontconfig                2.13.1            hba837de_1005    conda-forge
fonts-conda-ecosystem     1                             0    conda-forge
fonts-conda-forge         1                             0    conda-forge
freetype                  2.10.4               h0708190_1    conda-forge
freexl                    1.0.6                h7f98852_0    conda-forge
fribidi                   1.0.10               h36c2ea0_0    conda-forge
gcc_impl_linux-64         9.4.0                h03d3576_8    conda-forge
gcc_linux-64              9.4.0                h391b98a_1    conda-forge
geos                      3.9.1                h9c3ff4c_2    conda-forge
geotiff                   1.6.0                h4f31c25_6    conda-forge
gettext                   0.19.8.1          h0b5b191_1005    conda-forge
gfortran_impl_linux-64    9.4.0                h0003116_8    conda-forge
gfortran_linux-64         9.4.0                hf0ab688_1    conda-forge
giflib                    5.2.1                h36c2ea0_2    conda-forge
graphite2                 1.3.13            h58526e2_1001    conda-forge
gsl                       2.7                  he838d99_0    conda-forge
gxx_impl_linux-64         9.4.0                h03d3576_8    conda-forge
gxx_linux-64              9.4.0                h0316aca_1    conda-forge
harfbuzz                  2.9.1                h83ec7ef_0    conda-forge
hdf4                      4.2.15               h10796ff_3    conda-forge
hdf5                      1.12.1          nompi_h2750804_100    conda-forge
icu                       68.1                 h58526e2_0    conda-forge
idna                      3.1                pyhd3deb0d_0    conda-forge
jbig                      2.1               h7f98852_2003    conda-forge
jpeg                      9d                   h36c2ea0_0    conda-forge
json-c                    0.15                 h98cffda_0    conda-forge
kealib                    1.4.14               h87e4c3c_3    conda-forge
kernel-headers_linux-64   2.6.32              he073ed8_14    conda-forge
krb5                      1.19.2               hcc1bbae_0    conda-forge
ld_impl_linux-64          2.36.1               hea4e1c9_2    conda-forge
lerc                      2.2.1                h9c3ff4c_0    conda-forge
libblas                   3.9.0           11_linux64_openblas    conda-forge
libcblas                  3.9.0           11_linux64_openblas    conda-forge
libcurl                   7.78.0               h2574ce0_0    conda-forge
libdap4                   3.20.6               hd7c4107_2    conda-forge
libdeflate                1.7                  h7f98852_5    conda-forge
libedit                   3.1.20191231         he28a2e2_2    conda-forge
libev                     4.33                 h516909a_1    conda-forge
libffi                    3.3                  h58526e2_2    conda-forge
libgcc-devel_linux-64     9.4.0                hd854feb_8    conda-forge
libgcc-ng                 11.1.0               hc902ee8_8    conda-forge
libgdal                   3.3.1                h6214c1d_3    conda-forge
libgfortran-ng            11.1.0               h69a702a_8    conda-forge
libgfortran5              11.1.0               h6c583b3_8    conda-forge
libglib                   2.68.4               h3e27bee_0    conda-forge
libgomp                   11.1.0               hc902ee8_8    conda-forge
libiconv                  1.16                 h516909a_0    conda-forge
libkml                    1.3.0             h238a007_1014    conda-forge
liblapack                 3.9.0           11_linux64_openblas    conda-forge
libnetcdf                 4.8.1           nompi_hb3fd0d9_101    conda-forge
libnghttp2                1.43.0               h812cca2_0    conda-forge
libopenblas               0.3.17          pthreads_h8fe5266_1    conda-forge
libpng                    1.6.37               h21135ba_2    conda-forge
libpq                     13.3                 hd57d9b9_0    conda-forge
librttopo                 1.1.0                h1185371_6    conda-forge
libsanitizer              9.4.0                h79bfe98_8    conda-forge
libspatialite             5.0.1                h8694cbe_5    conda-forge
libssh2                   1.10.0               ha56f1ee_0    conda-forge
libstdcxx-devel_linux-64  9.4.0                hd854feb_8    conda-forge
libstdcxx-ng              11.1.0               h56837e0_8    conda-forge
libtiff                   4.3.0                hf544144_1    conda-forge
libuuid                   2.32.1            h7f98852_1000    conda-forge
libwebp-base              1.2.1                h7f98852_0    conda-forge
libxcb                    1.13              h7f98852_1003    conda-forge
libxml2                   2.9.12               h72842e0_0    conda-forge
libzip                    1.8.0                h4de3113_0    conda-forge
lz4-c                     1.9.3                h9c3ff4c_1    conda-forge
make                      4.3                  hd18ef5c_1    conda-forge
ncurses                   6.2                  h58526e2_4    conda-forge
openjpeg                  2.4.0                hb52868f_1    conda-forge
openssl                   1.1.1l               h7f98852_0    conda-forge
pango                     1.48.9               hb8ff022_0    conda-forge
pcre                      8.45                 h9c3ff4c_0    conda-forge
pcre2                     10.37                h032f7d1_0    conda-forge
pip                       21.2.4             pyhd8ed1ab_0    conda-forge
pixman                    0.40.0               h36c2ea0_0    conda-forge
poppler                   21.03.0              h93df280_0    conda-forge
poppler-data              0.4.11               hd8ed1ab_0    conda-forge
postgresql                13.3                 h2510834_0    conda-forge
proj                      8.0.1                h277dcde_0    conda-forge
pthread-stubs             0.4               h36c2ea0_1001    conda-forge
pycosat                   0.6.3           py39h3811e60_1006    conda-forge
pycparser                 2.20               pyh9f0ad1d_2    conda-forge
pyopenssl                 20.0.1             pyhd8ed1ab_0    conda-forge
pysocks                   1.7.1            py39hf3d152e_3    conda-forge
python                    3.9.7           h49503c6_0_cpython    conda-forge
python_abi                3.9                      2_cp39    conda-forge
r-base                    4.1.1                hb93adac_1    conda-forge
r-class                   7.3_19            r41hcfec24a_0    conda-forge
r-classint                0.4_3             r41h859d828_2    conda-forge
r-cpp11                   0.3.1             r41hc72bb7e_0    conda-forge
r-dbi                     1.1.1             r41hc72bb7e_0    conda-forge
r-e1071                   1.7_8             r41h03ef668_0    conda-forge
r-kernsmooth              2.23_20           r41h742201e_0    conda-forge
r-magrittr                2.0.1             r41hcfec24a_1    conda-forge
r-mass                    7.3_54            r41hcfec24a_0    conda-forge
r-proxy                   0.4_26            r41hcfec24a_0    conda-forge
r-rcpp                    1.0.7             r41h03ef668_0    conda-forge
r-s2                      1.0.6             r41h42b9fc4_0    conda-forge
r-sf                      1.0_2             r41h41e2acd_0    conda-forge
r-units                   0.7_2             r41h03ef668_0    conda-forge
r-wk                      0.5.0             r41h03ef668_0    conda-forge
readline                  8.1                  h46c0cb4_0    conda-forge
requests                  2.26.0             pyhd8ed1ab_0    conda-forge
ruamel_yaml               0.15.80         py39h3811e60_1004    conda-forge
sed                       4.8                  he412f7d_0    conda-forge
setuptools                58.0.4           py39hf3d152e_0    conda-forge
six                       1.16.0             pyh6c4a22f_0    conda-forge
sqlite                    3.36.0               h9cd32fc_1    conda-forge
sysroot_linux-64          2.12                he073ed8_14    conda-forge
tiledb                    2.3.4                he87e0bf_0    conda-forge
tk                        8.6.11               h27826a3_1    conda-forge
tktable                   2.10                 hb7b940f_3    conda-forge
tqdm                      4.62.2             pyhd8ed1ab_0    conda-forge
tzcode                    2021a                h7f98852_2    conda-forge
tzdata                    2021a                he74cb21_1    conda-forge
udunits2                  2.2.27.27            hc3e0081_2    conda-forge
urllib3                   1.26.6             pyhd8ed1ab_0    conda-forge
wheel                     0.37.0             pyhd8ed1ab_1    conda-forge
xerces-c                  3.2.3                h9d8b166_2    conda-forge
xorg-kbproto              1.0.7             h7f98852_1002    conda-forge
xorg-libice               1.0.10               h7f98852_0    conda-forge
xorg-libsm                1.2.3             hd9c2040_1000    conda-forge
xorg-libx11               1.7.2                h7f98852_0    conda-forge
xorg-libxau               1.0.9                h7f98852_0    conda-forge
xorg-libxdmcp             1.1.3                h7f98852_0    conda-forge
xorg-libxext              1.3.4                h7f98852_1    conda-forge
xorg-libxrender           0.9.10            h7f98852_1003    conda-forge
xorg-libxt                1.2.1                h7f98852_2    conda-forge
xorg-renderproto          0.11.1            h7f98852_1002    conda-forge
xorg-xextproto            7.3.0             h7f98852_1002    conda-forge
xorg-xproto               7.0.31            h7f98852_1007    conda-forge
xz                        5.2.5                h516909a_1    conda-forge
yaml                      0.2.5                h516909a_0    conda-forge
zlib                      1.2.11            h516909a_1010    conda-forge
zstd                      1.5.0                ha95c52a_0    conda-forge

Details about  conda and system ( conda info ):

$ conda info
     active environment : base
    active env location : /root/miniconda3
            shell level : 1
       user config file : /root/.condarc
 populated config files : /root/.condarc
          conda version : 4.10.3
    conda-build version : not installed
         python version : 3.9.7.final.0
       virtual packages : __linux=5.13.14=0
                          __glibc=2.33=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /root/miniconda3  (writable)
      conda av data dir : /root/miniconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /root/miniconda3/pkgs
                          /root/.conda/pkgs
       envs directories : /root/miniconda3/envs
                          /root/.conda/envs
               platform : linux-64
             user-agent : conda/4.10.3 requests/2.26.0 CPython/3.9.7 Linux/5.13.14-200.fc34.x86_64 fedora/34 glibc/2.33
                UID:GID : 0:0
             netrc file : None
           offline mode : False

I reran this with Mambaforge and did not encounter any issue.
$ docker run --rm -it registry.fedoraproject.org/fedora-toolbox:34
$ wget https://github.com/conda-forge/miniforge/releases/latest/download/Mambaforge-Linux-x86_64.sh
$ chmod +x Mambaforge-Linux-x86_64.sh
$ ./Mambaforge-Linux-x86_64.sh
## yes
## yes
$ source ~/.bashrc
(base) $ mamba create -yn foo r-sf
(base) $ mamba activate foo
(foo) $ R -e 'library("sf")'

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-conda-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library("sf")
Linking to GEOS 3.11.0, GDAL 3.5.2, PROJ 9.1.0; sf_use_s2() is TRUE
>
(foo) $

Notably, it did install libnsl=2.0.0=h7f98852_0 from Conda and checking ldd ${CONDA_PREFIX}/lib/R/library/sf/libs/sf.so showed it was detected:
## ...
libnsl.so.3 => /root/mambaforge/envs/foo/lib/R/library/sf/libs/./../../../../././libnsl.so.3 (0x00007fd2df3d5000)

I also reran with a similar specification as OP: mamba create -yn foo r-base=4.1 r-sf=1.0_2. Again, this installed libnsl, showed it was correctly linked in ldd, and loaded without issue in R.
I'm closing this as resolved, but please comment if you think it should remain open.

authors: karldw mfansler

repo: conda-forge/r-sf-feedstock


text:
sensormapgeo 1.0.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] 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.

@conda-forge-admin, please rerender

repo: conda-forge/sensormapgeo-feedstock


text:
MNT: Re-render the feedstock [ci skip]

Hi! This is the friendly conda-forge-admin automated user.
I've re-rendered this feedstock with the latest version of conda-smithy (1.6.1) and noticed some changes.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Remember, for any changes to the recipe you would normally need to increment the version or the build number of the package.
Since this is an infrastructural change, we don't actually need/want a new version to be uploaded to anaconda.org/conda-forge, so the version and build/number are left unchanged and the CI has been skipped.
Thanks!

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.

repo: conda-forge/toro-feedstock


text:
Add cffi to runtime requirements

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] 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)
[x] Ensured the license file is being packaged.

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.

Using pip check complained that zstandard is missing the cffi dependency after installing from conda forge, this should fix it.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

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.

I could reproduce it:
(base) root@16b5f0f237b7:/# conda create -n testenv python=3.8 zstandard
Collecting package metadata (current_repodata.json): done
Solving environment: done
Segmentation fault
(base) root@16b5f0f237b7:/# conda create -n testenv2 python=3.8 zstandard
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /opt/conda/envs/testenv2

  added / updated specs:
    - python=3.8
    - zstandard

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    python-3.8.6               |h852b56e_0_cpython        22.1 MB  conda-forge
    zstandard-0.14.0           |   py38h950e882_2         582 KB  conda-forge
    ------------------------------------------------------------
                                           Total:        22.7 MB

The following NEW packages will be INSTALLED:

  _libgcc_mutex      conda-forge/linux-64::_libgcc_mutex-0.1-conda_forge
  _openmp_mutex      conda-forge/linux-64::_openmp_mutex-4.5-1_gnu
  ca-certificates    conda-forge/linux-64::ca-certificates-2020.6.20-hecda079_0
  certifi            conda-forge/linux-64::certifi-2020.6.20-py38h924ce5b_2
  ld_impl_linux-64   conda-forge/linux-64::ld_impl_linux-64-2.35-h769bd43_9
  libffi             conda-forge/linux-64::libffi-3.2.1-he1b5a44_1007
  libgcc-ng          conda-forge/linux-64::libgcc-ng-9.3.0-h5dbcf3e_17
  libgomp            conda-forge/linux-64::libgomp-9.3.0-h5dbcf3e_17
  libstdcxx-ng       conda-forge/linux-64::libstdcxx-ng-9.3.0-h2ae2ef3_17
  ncurses            conda-forge/linux-64::ncurses-6.2-he1b5a44_2
  openssl            conda-forge/linux-64::openssl-1.1.1h-h516909a_0
  pip                conda-forge/noarch::pip-20.2.4-py_0
  python             conda-forge/linux-64::python-3.8.6-h852b56e_0_cpython
  python_abi         conda-forge/linux-64::python_abi-3.8-1_cp38
  readline           conda-forge/linux-64::readline-8.0-he28a2e2_2
  setuptools         conda-forge/linux-64::setuptools-49.6.0-py38h924ce5b_2
  sqlite             conda-forge/linux-64::sqlite-3.33.0-h4cf870e_1
  tk                 conda-forge/linux-64::tk-8.6.10-hed695b0_1
  wheel              conda-forge/noarch::wheel-0.35.1-pyh9f0ad1d_0
  xz                 conda-forge/linux-64::xz-5.2.5-h516909a_1
  zlib               conda-forge/linux-64::zlib-1.2.11-h516909a_1010
  zstandard          conda-forge/linux-64::zstandard-0.14.0-py38h950e882_2

Proceed ([y]/n)? y

Downloading and Extracting Packages
python-3.8.6         | 22.1 MB   | ####################################################################################################################################### | 100%
zstandard-0.14.0     | 582 KB    | ####################################################################################################################################### | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
#
# To activate this environment, use
#
#     $ conda activate testenv2
#
# To deactivate an active environment, use
#
#     $ conda deactivate

(base) root@16b5f0f237b7:/# conda activate testenv2
(testenv2) root@16b5f0f237b7:/# pip check
zstandard 0.14.0 requires cffi, which is not installed.

authors: conda-forge-linter maxnoe rmax

repo: conda-forge/zstandard-feedstock


text:
CEP: Conda Version Support

This CEP aims to provide a clear support windows for the conda package manager. This is still a work in progress and everyone is invited to comment on this PR with suggestions as we refine and develop this policy.

Curious, what statistics have we already looked at?

@jezdez found a model we could potentially follow: https://devguide.python.org/versions/
We should definitely have a nice graph included in this CEP 😉

I'm happy to answer any questions folks might have about Python's support policy.

@jakirkham, we have download/user agent statistics for anaconda.org.

The following graph gives a pretty good overview of current version usage. The data used come from access logs to anaconda.org from 2022-11-10 and 2022-12-09. It show the cumulative summation of version usage from oldest to newest.

This graph shows the percentage of conda users per version based on the same access log data:

I learned something interesting today about pip:

The latest version of the pip is the only supported version, previous versions should be considered unsupported. Users are encouraged to make regular updates to their version of pip in order to remain supported.

source: https://pip.pypa.io/en/latest/development/release-process/#supported-versions
I'm not sure such a release schedule would work for conda, but I'd be interested to hear to some other opinions. So far, I'm leaning towards something like Python has. Basically, we would only support the last four or five releases with categories for "bugfix" and "security" level fixes. Considering releases come out about every two months, this would give our users eight to 10 months of using an officially supported version of conda.

Selfishly, from a tooling perspective, the shorter the better as it means we don't have to maintain support for buggy conda versions for as long. 😁 But I think it really comes down to how much will it cost to backport bug fixes to versions that are still under the support SLA, and are you willing to pay that cost? Are you okay backporting across potentially e.g. 5 maintenance branches when a fix in main comes in? From a CPython perspective, having to maintain main and up to two more bugfix branches has a definite cost, and that's with tooling to help automate the backports.

Since we don't backport patches to older versions of conda I'd argue that we don't currently "support" anything beyond the most recent release. It's rather the rest of the infrastructure (e.g., anaconda.org, conda-build, etc.) that supports a longer conda tail. Will this proposal change this? Will this proposal dictate that bug fixes will need to be backported to all supported versions?
Enterprise users are fickle and often have IT policies that don't allow for frequent updates. It wouldn't be unreasonable for these users to update once or twice a year. Is this something we care about in the first place? Since our release policy dictates bi-monthly/six releases per year, the deprecation policy was written to slow down the window of forced updates. Perhaps we could designate the deprecation releases (the March and September releases) as also being LTS releases that are supported longer than the rest of our releases? Something like normal releases are supported until the next release and LTS releases are supported (with bugfix patching) for a year? This would mean that at any one point in time we'd be supporting at most 3 versions of conda.

Does the release frequency of Miniconda play a role in this?
The latest I can get from https://repo.anaconda.com/miniconda/ currently is 4.12.0.
Is there another simple way to bootstrap conda with a newer version?

@rolweber, check out Miniforge. Their latest release has conda 22.9. It points to the conda-forge channel be default though, so you have to explicitly add Anaconda channels if you need them.
Also, just for your information, this CEP will not affect anything related to Miniconda releases. It purely deals with conda.

I think it depends on what is meant by "support".
As the long tail shows we still have quite old versions hitting our server. This is often because they are embedded in long-running systems, so updates are challenging. Or it might just be because this is the root environment they've been using for a long time and unnecessary updates always come with risk of breakage. Perhaps it is baked in an old VM or Docker container.
And from a user's perspective, why not stay where they are? If it's working for them, there is no need to fix it, unless we force them to: only when we add a new assumption to conda behavior that old versions do not meet; virtual meta packages for example. A simple security patch or even new convenience feature usually does not alter behavior in a breaking way, so if users choose to forego such an update they do not suffer significant consequences.
So I would like to make sure that we differentiate between these two kinds of "support" in any proposal we make.

A simple security patch or even new convenience feature usually does not alter behavior in a breaking way, so if users choose to forego such an update they do not suffer significant consequences.

But it does impact those that are tool integrators of conda. If you take CPython as an example, even supporting just security fixes as a source release is enough to cause people to ask/demand that you support them and the version they are choosing to use because there is some semblance of upstream support.

we should not expect everyone to adopt aggressive update strategies.

What's aggressive to you?

Good feedback, Brett, thank you!
I often find myself dealing with people on that long tail. They have built out data science workflows that embed conda deeply enough that the version they are using is not top-of-mind. Above I mentioned the introduction of the virtual metapackages as once case that exposed a number of customers who were running exceedingly old versions of conda. This intersected, interestingly, with a surprising cohort of customers who were still running CentOS/RHEL 6!
The introduction of the compatible release operator ~= was another one. That one proved interesting because it was sort of a sleeper: it was introduced in conda in 2018, but it took awhile before its use began to appear in conda repodata. But when it did, it caused non-trivial pain for users who were running older versions of conda. For customers that needed time to update their workflows, we bought them time by showing them how to exclude the offending packages from their mirrors.
But I think it's important to point out that an important commonality in the examples I'm thinking of is that they aren't desktop cases. Instead these were cases where conda was embedded into systems and processes. When I think about how, for instance, VSCode leverages conda, I do think it is more reasonable to assume that users should be able to stay reasonably up-to-date.
In the end, what I'm thinking is that I would welcome a restrictive conda version support policy if we also explicitly endorse a commitment to a good-faith effort to minimize changes that break the basic behavior of conda in the manner that virtual metapackages and the compatible release operator did. We won't always be able to avoid that, mind you, but we're more likely to do it unintentionally if it's not consciously considered.
Note that I'm writing this as a stakeholder but not an official voter. In the end I will work with the consensus view!

Thanks for providing a different type of user perspective and historical context @mcg1969. I believe it will be possible to ensure stability in conda going forward via CEP-9: Conda Deprecation Schedule.
@kenodegard, brings a up a good point in saying that effectively we really only support the latest release of conda. We would like to support more, but we also need to make that this CEP does not set us up for failure. As @kenodegard, suggested it may be nice to introduce LTS releases that are tied to our "deprecation" releases, which means that we would only have to support three releases simultaneously.
After thinking about this some more and reflecting on the current capacity of the conda development team, I am still not convinced that we actually have the capacity to do this. In other words, if we agree to something like this, we may be setting ourselves up for failure, leaving our team vulnerable to getting bogged down in LTS version support. But, these concerns might be a little overblown. I am just trying to be conservative here.
Perhaps a way forward here would be to involve our community of users and developers more. Instead of putting the maintenance burden squarely on the current development team, we could instead announce that these LTS versions will no longer be patched by our team, but we will welcome community pull requests for bug fixes. The conda development team will subsequently handle any release related work.
I'm interested to know if any other OSS projects operate this way (i.e. we do not fix bugs with a release but will accept fixes for it). Surely there must be users out there willing to patch their own software and push it upstream, right? 🤷 😅

I'm interested to know if any other OSS projects operate this way (i.e. we do not fix bugs with a release but will accept fixes for it).

I can't remember where I have seen this, but I have seen it. Typically, though, it's been around unofficial support, e.g. patches from the community to keep an older version running unofficially as long as it didn't make code harder to maintain were accepted.

It might be helpful if old conda versions could detect when breaking features have been rolled out to the repositories, so they can bail out with a meaningful error message. Of course that won't help with the old versions that are currently out there. But maybe add this to one of the next releases, which will become old versions in the future.

@conda-incubator/steering
This vote falls under the "Enhancement Proposal Approval" policy of the conda governance policy,
please vote and/or comment on this proposal at your earliest convenience.
It needs 60 % of the Steering Council to vote yes to pass.
To vote, please leave yes, no or abstain as comments below.
If you have questions concerning the proposal, you may also leave a comment or code review.
This vote will end on 2023-04-06, End of Day, Anywhere on Earth (AoE).

yes

It might be helpful if old conda versions could detect when breaking features have been rolled out to the repositories, so they can bail out with a meaningful error message. Of course that won't help with the old versions that are currently out there. But maybe add this to one of the next releases, which will become old versions in the future.

Anaconda.org could reject serving to old clients by detecting the version in the user agent, if available. Just leaving that thought out there before I forget :D

Yes.

Yes.

Yes

yes

yes

yes

yes

yes

Yes

authors: brettcannon chenghlee goanpeca jaimergp jakirkham jezdez kenodegard kkraus14 mariusvniekerk mcg1969 msarahan ocefpaf rolweber travishathaway wolfv xhochy

repo: conda-incubator/ceps


text:
Bit hard to figure out what to type for a local file on windows in installer-url

I spent quite some time this morning figuring this out as it wasn't obvious from the docs or examples. It may be obvious for a Javascript developer that knows how this works:
// Node program to demonstrate the
// URL.fileURLToPath() API as Setter

// Importing the module 'url'
const url = require('url');

// Some random path from system
const file = 'file:///C:/path/example/gfg'

// Converting the file to properly encoded path
console.log(url.fileURLToPath(file))

which returns:
 C:\path\example\gfg

taken from: https://www.geeksforgeeks.org/node-js-url-fileurltopath-api/
I finally got a local exe to build on a Github action with:
      - uses: conda-incubator/setup-miniconda@v3
        with:
          auto-update-conda: true
          installer-url: file:///D:/r/repoowner/reponame/anaconda-installer-Windows-x86_64.exe

I can also probably remove the full path, but the key things are 1) use forward slashes, even if you are on windows and 2) use three forward slashes after file:.
It could be helpful to give an example of this in the docs of this repo. Thanks for the action!

There is this:
https://github.com/conda-incubator/setup-miniconda/blob/3ec85ceb97e2734f6ff7320c7c9a341f4ffc9fef/.github/workflows/example-5.yml#L42
but that is on Ubuntu so it wasn't obvious for me what to do on Windows (use forward slashes not backslashes).

One more note is that the path to the file must be absolute. A relative path failed.

I cannot confirm your findings here. I have a running action with the following URL:
installer-url: file://D:\a\helios-installer\helios-installer/dist/helios-2.0.0a1-Windows-x86_64.exe

which does not have triple / and mixed / and \. You find the code here: https://github.com/ssciwr/helios-installer/blob/main/.github/workflows/installer.yml#L102

Here are the various commits that show what I tried: https://github.com/moorepants/anaconda-dee-config/pull/1
It works now, so I will stick with the triple and forward slashes.

authors: dokempf moorepants

repo: conda-incubator/setup-miniconda