[bug] conan search only finds recipe, revisions but not packages

[Hopobcn]

Hi, recently I noticed that for some of the packages I store in artifactory, when I try to 'conan search' them, only the recipe appears to be visible. But when inspecting artifactory I see the binary packages.

Environment Details (include every applicable attribute)

• Operating System+version: Centos 7.9
• Compiler+version: not-applicable
• Conan version: 1.44.1
• Python version: 3.6.8
• Artifactory version: 6.23.19

Steps to reproduce (Include if Applicable)

Issuing a 'conan-search' only sees the recipe:

$ conan search foo/1.2.3@ -r company-develop
Existing packages for recipe foo/1.2.3:

Existing recipe in remote 'company-develop':

There are no packages for reference 'foo/1.2.3', but package recipe found.

For instance, by providing --revisions I can see that the latest revision is efb77ebd55594925f55ac7297cd8477e

$ conan search foo/1.2.3@ -r company-develop --revisions
Revisions for 'foo/1.2.3' at remote 'company-develop':
efb77ebd55594925f55ac7297cd8477e (2022-01-26 16:11:27 UTC)
57dc855aa6c9355da89b61b957917197 (2022-01-25 14:16:17 UTC)
de6f2e37e53075ddd57ac0662765e390 (2022-01-25 11:38:45 UTC)

and this revision appears to have a binary package in artifactory:

Any idea of what is happening?

Logs (Executed commands with output) (Include/Attach if Applicable)

My conan.conf:

$ cat ~/.conan/conan.conf
[log]
run_to_output = True                  # environment CONAN_LOG_RUN_TO_OUTPUT
run_to_file = False                   # environment CONAN_LOG_RUN_TO_FILE
level = critical                      # environment CONAN_LOGGING_LEVEL
print_run_commands = False            # environment CONAN_PRINT_RUN_COMMANDS

[general]
default_profile = default
compression_level = 9                 # environment CONAN_COMPRESSION_LEVEL
sysrequires_sudo = True               # environment CONAN_SYSREQUIRES_SUDO
request_timeout = 60                  # environment CONAN_REQUEST_TIMEOUT (seconds)
default_package_id_mode = recipe_revision_mode
revisions_enabled = 1
required_conan_version = >=1.43.1

[storage]
path = ~/.conan/data

[proxies]

[hooks]
attribute_checker

[memsharded]

Hi @Hopobcn

Yes, this is unexpected. The binaries should show there when conan search <full-ref> -r=<remote>. Could you please check:

• When clicking on Artifactory web UI, on the specific package binary, and going to the "Conan" tab, you should see some Conan package information, like the settings "os=Linux" etc. Please let us know what you see there.
• If you can download and share here the conaninfo.txt file inside the Artifactory binary, that could be useful.
• Also, try conan search <full-ref#exact_revision> -r=`, including the revision explicitly, just to double check.

What I am suspecting here is that there is some parsing error of the conaninfo.txt file in the Artifactory side, lets see if that could be it.

[Hopobcn]

Hi @memsharded, first of all, thanks for your help!

This is what I see in the Artifactory UI:

And the conaninfo.txt:

[settings]
    arch=x86_64
    build_type=Release
    compiler=gcc
    compiler.cppstd=17
    compiler.libcxx=libstdc++11
    compiler.version=7
    os=Linux
    os.distro=Ubuntu
    os.distro.version=16.04

[requires]
    boost/1.72.0#8ff1c16d4f9f11f7104527320951c0e1:524ea35a8120baabdde02483add58d81bf541327
    deviceApi/0.1.0#8623c129a12dae5f221f43ab9b9ddc55:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    elfio/3.8#eaef5a1fc05b3ed7deb260b73ee286dc:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    g3log/1.3.3#a71fecff43d664d5c6fcec364e2b8b3c:feaa0d69e04b9d3726f800cc87df7cc6e90eb96d
    gflags/2.2.2#a9e419e6405eed0e33216a290eabf7d4:4e3d194cc788e0bfd26a993047d081212c1506d3
    glog/0.4.0#72b88379da493c365343222d21b374a7:edc3f107978cb7cba3f6614c86fb880098043c25
    gtest/1.8.1#40938ea0ac2d6f5e064c60ea8b667d9b:89c67cf632149b66c4155d2a112edb4d2c2fd7b3
    fooPkg/0.1.0#1a251ccbdee01aed2aa68b1a06bb6fac:bdca9aa0e810fa4be6930bccc0e956b632950ed8
    barPkg/0.1.0#169a05699024ee5f35b096dc898f8be3:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    zee-pkg/0.2.0#365aa850ec34995608e491169ed4ce5f:308969d0104fff109b777198104cf9410158e733

[options]
    fPIC=True
    shared=False
    with_tests=False

[full_settings]
    arch=x86_64
    build_type=Release
    compiler=gcc
    compiler.cppstd=17
    compiler.libcxx=libstdc++11
    compiler.version=7
    os=Linux
    os.distro=Ubuntu
    os.distro.version=16.04

[full_requires]
    boost/1.72.0:524ea35a8120baabdde02483add58d81bf541327
    deviceApi/0.1.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    elfio/3.8:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    g3log/1.3.3:feaa0d69e04b9d3726f800cc87df7cc6e90eb96d
    gflags/2.2.2:4e3d194cc788e0bfd26a993047d081212c1506d3
    glog/0.4.0:edc3f107978cb7cba3f6614c86fb880098043c25
    gtest/1.8.1:89c67cf632149b66c4155d2a112edb4d2c2fd7b3
    fooPkg/0.1.0:bdca9aa0e810fa4be6930bccc0e956b632950ed8
    barPkg/0.1.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    zee-pkg/0.2.0:308969d0104fff109b777198104cf9410158e733

[full_options]
    fPIC=True
    shared=False
    with_tests=False
    boost:asio_no_deprecated=False
    boost:buildid=None
    boost:bzip2=True
    boost:debug_level=0
    boost:diagnostic_definitions=False
    boost:error_code_header_only=False
    boost:extra_b2_flags=None
    boost:filesystem_no_deprecated=False
    boost:header_only=True
    boost:i18n_backend=deprecated
    boost:i18n_backend_iconv=libc
    boost:i18n_backend_icu=False
    boost:layout=system
    boost:lzma=False
    boost:magic_autolink=False
    boost:multithreading=True
    boost:namespace=boost
    boost:namespace_alias=False
    boost:numa=True
    boost:pch=True
    boost:python_executable=None
    boost:python_version=None
    boost:segmented_stacks=False
    boost:system_no_deprecated=False
    boost:visibility=hidden
    boost:with_stacktrace_backtrace=True
    boost:without_atomic=False
    boost:without_chrono=False
    boost:without_container=False
    boost:without_context=False
    boost:without_contract=False
    boost:without_coroutine=False
    boost:without_date_time=False
    boost:without_exception=False
    boost:without_fiber=False
    boost:without_filesystem=False
    boost:without_graph=False
    boost:without_graph_parallel=True
    boost:without_iostreams=False
    boost:without_locale=False
    boost:without_log=False
    boost:without_math=False
    boost:without_mpi=True
    boost:without_program_options=False
    boost:without_python=True
    boost:without_random=False
    boost:without_regex=False
    boost:without_serialization=False
    boost:without_stacktrace=False
    boost:without_system=False
    boost:without_test=False
    boost:without_thread=False
    boost:without_timer=False
    boost:without_type_erasure=False
    boost:without_wave=False
    boost:zlib=True
    boost:zstd=False
    g3log:change_debug_to_dbug=False
    g3log:enable_fatal_signal_handling=True
    g3log:fPIC=True
    g3log:log_full_filename=False
    g3log:shared=False
    g3log:use_dynamic_logging_levels=True
    g3log:use_dynamic_max_message_size=True
    gflags:fPIC=True
    gflags:namespace=gflags
    gflags:nothreads=True
    gflags:shared=False
    glog:fPIC=True
    glog:shared=False
    glog:with_gflags=True
    glog:with_threads=True
    gtest:build_gmock=True
    gtest:fPIC=True
    gtest:hide_symbols=False
    gtest:no_main=False
    gtest:shared=False
    fooPkg:shared=False
    fooPkg:with_tests=True
    zee-pkg:backtrace=False
    zee-pkg:profiling=False
    zee-pkg:shared=False

[recipe_hash]
    efb77ebd55594925f55ac7297cd8477e

[env]

These binaries use a modified settings.yml that I extended with os.distro & os.distro.version (like discussed here https://docs.conan.io/en/latest/extending/custom_settings.html#adding-new-sub-settings). But I don't think this is the source of my problems. We don't depend on CCI binaries directly, instead we re-use the recipe and build the binaries ourselves. Interestingly this issue doesn't seem to be happening with CCI packages:

conan search gtest/1.8.1@ -r company-develop
Existing packages for recipe gtest/1.8.1:

Existing recipe in remote 'company-develop':

    Package_ID: 89c67cf632149b66c4155d2a112edb4d2c2fd7b3
        [options]
            build_gmock: True
            fPIC: True
            hide_symbols: False
            shared: False
        [settings]
            arch: x86_64
            build_type: Release
            compiler: gcc
            compiler.cppstd: 17
            compiler.libcxx: libstdc++11
            compiler.version: 7
            os: Linux
            os.distro: Ubuntu
            os.distro.version: 16.04
        Outdated from recipe: False

Providing the revision doesn't seem to help:

% conan search foo/1.2.3@#efb77ebd55594925f55ac7297cd8477e -r company-develop            
Existing packages for recipe foo/1.2.3:

Existing recipe in remote 'company-develop':

There are no packages for reference 'foo/1.2.3', but package recipe found.

I suspect that is something about SCM. Because packages that don't use scm (like CCI ones) are not affected.

[memsharded]

Thanks for the detailed report!

I suspect that is something about SCM. Because packages that don't use scm (like CCI ones) are not affected.

I am checking the codebase, I cannot find a reason why the scm could affect the conan search <ref> for binaries.

Do you have access to the Artifactory traces? Can you get the traces that match that conan search request?

This is looking like a difficult to debug problem. Probably the next thing that I would try would be:

• Download a local ArtifactoryCE in your computer and run it. Upload the offending package to that server and check.
• This allows also to test with more modern Artifactory versions, just in case (I am not aware of specific issues around this in the 6.X version, but just in case)

[Hopobcn]

Do you have access to the Artifactory traces? Can you get the traces that match that conan search request?

Unfortunately no, but I will try to see If I can request that data.

I will get back to you after testing with another artifactory instance.

[Hopobcn]

Closing. Finally discovered it was an artifactory problem.

The majority of packages were uploaded by the annonymous user (that unfortunately in my organization has Read and Deploy/Cache permissions). Logging in with conan user with a conan administrative account solved the issue (now i'm able to use conan inspect with a version range and /v2/conans/search will return the correct thing).

[memsharded]

Thanks very much @Hopobcn for following up and reporting! Happy that you found the issue and manage to make it work.