Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 16 05:27
    ossdev07 commented #3846
  • Jan 15 18:39
    forrestwaters closed #3849
  • Jan 15 18:39
    forrestwaters commented #3849
  • Jan 15 18:35

    msarahan on csoja-patch-1

    (compare)

  • Jan 15 18:35

    msarahan on master

    Update issue template add code… Merge pull request #3853 from c… (compare)

  • Jan 15 18:35
    msarahan closed #3853
  • Jan 15 18:29
    forrestwaters commented #3849
  • Jan 15 17:28
    csoja review_requested #3853
  • Jan 15 17:28
    cla-bot[bot] labeled #3853
  • Jan 15 17:28
    csoja opened #3853
  • Jan 15 17:27

    csoja on csoja-patch-1

    Update issue template add code… (compare)

  • Jan 15 14:09
    mingwandroid synchronize #3812
  • Jan 15 10:58
    cla-bot[bot] commented #3846
  • Jan 15 10:58
    ossdev07 synchronize #3846
  • Jan 14 17:07
    mingwandroid synchronize #3812
  • Jan 14 01:58
    scottwsides opened #3852
  • Jan 13 16:53
    sdebionne reopened #3849
  • Jan 13 16:53
    sdebionne commented #3849
  • Jan 13 16:15
    mingwandroid synchronize #3812
  • Jan 13 14:24
    sdebionne closed #3849
deepali-c
@deepali-c
so shall I post in the conda gitter
Duncan Macleod
@duncanmmacleod
@deepali-c, my question was totally unrelated to yours, sorry for any confusion
Nehal J Wani
@nehaljwani
@duncanmmacleod you should build the package in a manner such that all binaries end up in bin. Any particular reason why you want to use sbin ?
Duncan Macleod
@duncanmmacleod
@nehaljwani, I am just building an existing package that includes daemon scripts that naturally belong in sbin
I understand that sbin is mainly for administrator control, I was just wondering if ‘don’t use sbin’ is a conda policy, or just nobody has tried it until now
Nehal J Wani
@nehaljwani
Conda doesn't add sbin to PATH on activation
Duncan Macleod
@duncanmmacleod
Sorry, my original question was badly worded, I am wondering if that very fact is a choice that was long-considered or just an oversight
Nehal J Wani
@nehaljwani

My understanding is that the sbin folder on Linux systems is for segregating binaries meant to be run by privileged users. (generally speaking, sysadmins)

But conda is a generic package manager and doesn't make such distinctions, so the need for segregating binaries doesn't make much sense here.

Anthony Scopatz
@scopatz
Hi All, is missing_dso_whitelist undocumented?
Seems so
Anthony Scopatz
@scopatz
Yeah that is what I was looking for
or at, rather
Nehal J Wani
@nehaljwani
It is definitely supported though. Are you repackaging something?
Anthony Scopatz
@scopatz
yeah, a haskel package
Anthony Scopatz
@scopatz
here is the existing issue: conda/conda-build#3360
Anthony Scopatz
@scopatz
So does rpaths not add entries to the RPATH for things in the bin/ directory?
Nehal J Wani
@nehaljwani
What entries did you list in rpaths? I thought CB used patchelf on binaries in bin for adding those paths.
Anthony Scopatz
@scopatz
x86_64-conda_cos6-linux-gnu/sysroot/lib/ and ../lib
Nehal J Wani
@nehaljwani
It is relative to $PREFIX I think, not $PREFIX/bin
Anthony Scopatz
@scopatz
yeah that is what I thought too
Nehal J Wani
@nehaljwani
Not sure what adding sysroot to the RPATH would achieve?
If you simply want --error-overlinking to pass, just add the C compiler and any links to glibc libs will stop complaining about missing deps
Anthony Scopatz
@scopatz
Right, yes, but there is no need for the compiler, since this is a haskell binary repackage
Nehal J Wani
@nehaljwani
If every component is being repackaged and 0 compilation, you can add '*' in the missing_dso_whitelist section
It allows patterns
Every CDT package recipe has that
Anthony Scopatz
@scopatz
Agreed, but the problem is deeped than just skipping the overlinking check. On the conda-forge CI, it fails the tests because it actually can't find the libraries
Probably because haskell links them to /lib64/
Nehal J Wani
@nehaljwani
Ah, so you need to force the rpath entries. Do you have a link?
Nehal J Wani
@nehaljwani
Oh no elm-format: /lib64/libc.so.6: version GLIBC_2.14 not found (required by elm-format) this is basically saying that it has been built with glibc 2.14 and the system you are running on, is perhaps centos6 based, which is glibc 2.12
Anthony Scopatz
@scopatz
Yeah, it is.
Nehal J Wani
@nehaljwani
So you can't run the tests, sorry.
Anthony Scopatz
@scopatz
damn, ok
Nehal J Wani
@nehaljwani
Why not build it from source? We already have a haskell compiler, don't we?
Anthony Scopatz
@scopatz
I didn't think we did
conda-forge just has ghc for linux, which I guess would work here
Nehal J Wani
@nehaljwani
yeah, that one
Anthony Scopatz
@scopatz
I guess I should go down that route
Tadeu Manoel
@tadeu
Hi all, did someone ever see an error like this on macOS, being unable to extract a .zip file in the beginning of the recipe build?
Traceback (most recent call last):
  File "/usr/local/miniconda/bin/conda-build", line 11, in <module>
    sys.exit(main())
  File "/usr/local/miniconda/lib/python3.7/site-packages/conda_build/cli/main_build.py", line 449, in main
    execute(sys.argv[1:])
(...)
  File "/usr/local/miniconda/lib/python3.7/site-packages/libarchive/extract.py", line 50, in extract_entries
    write_header(write_p, entry._entry_p)
  File "/usr/local/miniconda/lib/python3.7/site-packages/libarchive/ffi.py", line 91, in check_int
    raise archive_error(args[0], retcode)
  File "/usr/local/miniconda/lib/python3.7/site-packages/libarchive/ffi.py", line 75, in archive_error
    raise ArchiveError(msg, errno(archive_p), retcode, archive_p)
libarchive.exception.ArchiveError: Could not open CGAL-4.14.1 (errno=22, retcode=-30, archive_p=140295874731728)
Link for the recipe PR: conda-forge/cgal-cpp-feedstock#6
the errno keeps varying, in this build it is 22 (Invalid Argument), but before it was 14 (Invalid File Descriptor)
the file is ok, it's being built correctly in Linux
Tadeu Manoel
@tadeu
ah, I just found out this new issue: conda-forge/libarchive-feedstock#43
will change to .tar.gz
dsentinel
@dsentinel
I've adapted tk-feedstock to create a mac package that uses X11 instead of the default aqua. Others are interested in this and I'd like to start a PR, but I am unsure how to create a package with the same name and version, but uses different compile flags and dependencies.
This is similar to mkl "option" but it's not a mutex, and I'm not sure if build string is right either.
I need something very much like macports variant
Marcelo Duarte Trevisani
@marcelotrevisani
Hi @dsentinel , you can create a separated branch for that