text:
Proposal: Validator

Proposal
Build a validator service specifically for concrete5 that allows generic validation managers for common needs like passwords and potentially emails, and allows easy extension to create your own validators.
Backwards incompatible changes
None, everything should continue to respect the same configuration values as before. Existing functionality like \Concrete\Core\Application\Service\User::validNewPassword may be modified to use the new bound managers.
Goals

Provide a generic validator interface that could eventually be used throughout the core.
Enable easy simple extension
Allow changing or removing default requirements
Allow adding new requirements to default validators
Create a path to get translatable requirements of a validator
Create a path to get translatable errors from a failed validation
Provide standard default validators for generic types that can be used by packages

Examples we looked at

Zend validator
Symfony

Example user level extension
Example binding
<?php

// Service provider binding
$this->application->bindShared('example/validator/image', function($app) {
    // Lets define our min and max values first
    $minimum_width = 150;
    $minimum_height = 150;

    $maximum_width = 500;
    $maximum_height = 500;

    // Create a new validator manager
    $example_image_validator_manager = $app->make('\Concrete\Core\Validator\ValidatorManager');

    // Create a new example minimum size validator
    $minimum_size_validator = $app->make('\Example\Image\Validator\MinimumSizeValidator', array($minimum_width, $minimum_height));

    // Create a new example maximum size validator
    $maximum_size_validator = $app->make('\Example\Image\Validator\MaximumSizeValidator', array($maximum_width, $maximum_height));

    // Add the minimum size validator to the validator stack
    $example_image_validator_manager->setValidator('minimum', $minimum_size_validator);
    $example_image_validator_manager->setValidator('maximum', $maximum_size_validator);

    return $example_image_validator_manager;
});

Example Usage

// Usage
$validator = $this->application->make('example/validator/image');

// Create an example object to validate
$image = new \Example\ExampleImage();
$image->setWidth(100);
$image->setHeight(550);

// Create a new error object to capture the errors
$error = new \Concrete\Core\Error\Error();

// Attempt validation
if (!$validator->validate($image, $error)) {
    $error->output();
} else {
    die('Valid image!');
}

New app bindings

validator/password
Returns the default validator manager instance for passwords matching current password requirements

Planned app bindings

validator/email
Default email validator manager instance matching current requirements
validator/username
Default username validator manager instance matching current requirements

Interfaces
\Concrete\Core\Validator\ValidatorInterface
<?php
namespace Concrete\Core\Validator;

/**
 * Interface ValidatorInterface
 * A generic validator cabable of describing itself and validating mixed values
 *
 * @package Concrete\Core\Validator
 */
interface ValidatorInterface
{

    /**
     * Get the validator requirements in the form of an array keyed by it's respective error code
     *
     * Example:
     *    [ self::E_TOO_SHORT => 'Must be at least 10 characters' ]
     *
     * @return string[]
     */
    public function getRequirementStrings();

    /**
     * Is this mixed value valid
     *
     * @param mixed             $mixed Can be any value
     * @param \ArrayAccess|null $error
     * @return bool
     * @throws \InvalidArgumentException Invalid mixed value type passed.
     */
    public function isValid($mixed, \ArrayAccess $error = null);

}

\Concrete\Core\Validator\TranslatableValidatorInterface
<?php
namespace Concrete\Core\Validator;

/**
 * Interface TranslatableValidatorInterface
 * A modifier to the standard validator interface that enables translatable requirements and errors
 *
 * @package Concrete\Core\Validator
 */
interface TranslatableValidatorInterface extends ValidatorInterface
{

    /**
     * Set the requirement string to a mixed value
     * Closure format:
     *    function(TranslatableValidatorInterface $validator, int $code): string
     *
     * @param int             $code    The error code
     * @param string|\Closure $message Either a plain string, or a closure that returns a string
     * @return void
     */
    public function setRequirementString($code, $message);

    /**
     * Set the error string to a string or to a closure
     * Closure format:
     *    function(TranslatableValidatorInterface $validator, int $code, mixed $passed): string
     *
     * where `$passed` is whatever was passed to `ValidatorInterface::isValid`
     *
     * @param int             $code    The error code
     * @param string|\Closure $message Either a plain string, or a closure that returns a string
     * @return void
     */
    public function setErrorString($code, $message);

}

\Concrete\Core\Validator\ValidatorManagerInterface
<?php
namespace Concrete\Core\Validator;

/**
 * Interface ValidatorManagerInterface
 * A generic validator manager interface that enables validating against many validators at once
 *
 * @package Concrete\Core\Validator
 */
interface ValidatorManagerInterface extends ValidatorInterface
{

    /**
     * Get a list of all validators
     *
     * @return ValidatorInterface[] Array of validators keyed by their handles
     */
    public function getValidators();

    /**
     * Does a validator with this handle exist
     *
     * @param string $handle
     * @return bool
     */
    public function hasValidator($handle);

    /**
     * Add a validator to the stack.
     * Validators are unique by handle, so adding a validator with the same handle as a validator in the stack
     * replaces the old validator with the new one.
     *
     * @param string                                      $handle
     * @param \Concrete\Core\Validator\ValidatorInterface $validator
     * @return void
     */
    public function setValidator($handle, ValidatorInterface $validator=null);

    /**
     * Is this mixed value valid based on the added validators
     *
     * @param mixed                           $mixed Can be any value
     * @param \ArrayAccess|null $error The error object that will contain the error strings
     * @return bool
     * @throws \InvalidArgumentException Invalid mixed value type passed.
     */
    public function isValid($mixed, \ArrayAccess $error = null);

}

Translations
The validator manages translations by pushing all message resolving to the user:
<?php

$min_length = new \Concrete\Core\Validator\String\MinimumLengthValidator(5);
$min_length->setErrorString($min_length::E_TOO_SHORT, t('String must be at least 5 characters long.'));
$min_length->setRequirementsString($min_length::E_TOO_SHORT, t('Must be at least 5 characters long.'));

As context is important with translations, we also provide the ability to bind a closure in place of a string
<?php

$min_length = new MinimumLengthValidator(5);
$min_length->setErrorString($min_length::E_TOO_SHORT, function (MinimumLengthValidator $validator, $code, $passed) {
    return t('String "%s" is too short. Must be at least %s characters long.', $passed, $validator->getMinimumLength());
});

Validators we will provide with the first iteration
We're only going to provide validators pertinent to password validation with the first iteration of the validator package.

\Concrete\Core\Validator\String\MinimumLengthValidator
\Concrete\Core\Validator\String\MaximumLengthValidator
\Concrete\Core\Validator\String\RegexValidator

Implementation
https://github.com/concrete5/concrete5/pull/3034

This looks great. :+1:

This looks very interesting, thank you.

@ahukkanen Symfony validators follow a slightly different pattern than I am suggesting but I believe it doesn't offer anything that we can't adjust to offer as well. Symfony's implementation at first glance looks to rely on symfony/intl which won't work with our current t('') setup and will leave us with non-translatable errors.
Is there something specific that Symfony has that we don't provide in this proposal or are you just wanting to offer it as a means to arrive to #2717?

Yes, I would eventually want to see something like #2717, that's the basic reason. I also feel if there are multiple libraries doing the same thing, it's not very efficient. And I have never liked the way validations have been handled in concrete5, the Symfony way makes a lot more sense to me, at least.
symfony/intl can be bundled to work with c5 as shown in the example implementation but of course, it would produce some redundant and duplicate code, add also some overhead. I think there would still be a need on discussions on how to solve those issues in case this was taken forward.

The interfaces I've described can be changed to work with zend validator quite easily if we so choose, for now I think we should just get this merged in.

We're going to accept this validation update. It's done now, and it's needed for a core update next week.
It's very likely that our next major version will address form building in concrete5, along with providing some abstractions to handle generic data types – something not unlike a GUI for ORM entities, with support for concrete5 attributes, and more. To be truly compelling, that solution will need to build forms and provide validation – and when that happens, we will be looking into the best ways to provide those form interfaces and handle that validation. We will endeavor to make sure that our validation framework will work well with whatever solution we choose for it – whether it's something homegrown, Symfony forms, or something else.

authors: KorvinSzanto MrKarlDilkington aembler ahukkanen joe-meyer


text:
Installation fails to correctly check support for PATH_INFO on HTTPS

I found a bug in installation scripts when running on HTTPS-only website. The script tries to parse PATH_INFO and fails, even though the PATH_INFO is supported and provided correctly. The whole bug is in the method of checking for the support, which is done with AJAX call, which generates a request on http://, not on https:// as it should, thus being blocked by browser with Mixed Content: The page at ... This request has been blocked; the content must be served over HTTPS. error, which prevents installation to continue.
How to reproduce?
Install clean installation of C5 on HTTPS website, run installer and see the Mixed Request error.

@MyFlower could you share the URL that's being loaded via HTTP instead of HTTPS? (the domain is not relevant, just the path after it)

I figured out, where the problem is. I'm running my C5 behind reverse proxy which servers the HTTPS certificate and forwards communication to the destination on port 80, not 443. So the script fails to get the correct protocol, because the $_SERVER["https"] variable is not set correctly.
Putting SetEnvIf X-Forwarded-Proto "https" HTTPS=on into my Apache configuration did the trick. I'm not sure, if this is still something to be concerned with on your side, or if this is just a bug in my configuration and it should't happen.
BTW, if you set the protocol not only by checking the $_SERVER["https"] var, but also by checking if $_SERVER['HTTP_X_FORWARDED_PROTO'] is set and has the value of https, that would be best for all people that might run into same problem.

You can configure concrete5 to work flawlessly behind a reverse proxy.
See for example http://mlocati.github.io/articles/nginx-apache-concrete5.html

This issue just occured for me also, Loadbalancer -> Ec2 server with a fresh install of C5. My url loaded i.e. https://www.example.com and I also got the same error, I effectively did the same thing by forcing https to be on if XFORWARD was https. I think there is some validatiy to potentially check the HTTP_X_FORWARDED_PROTO at least when initially installing the C5 application.

source: gharchive/issue

authors: JustGetSchwifty MyFlower matt9mg mlocati

license: mit

license_type: permissive

license_source: bigquery


text:
Password Requirements dashboard page was not installed via 8.5.0 & 8.5.1 fresh install

When you tried clean install concrete5 8.5.0 & 8.5.1, Password Requirement page doesn't get installed.
You forgot to add installation xml page.
Adding additional migration script for 8.5.0 & 8.5.1 fresh-installed site.
I didn't bother to add downgradeSchema(). Which is also set in Version20181222183445.php.

I think you may have to change the value in the config file also if you add a migration script. See: #7624

Opps. I forgot about concrete.php... Thx @hissy !

Thanks! I have manually merged this in order to fix conflicts.

source: gharchive/pull-request

authors: aembler hissy katzueno


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #2.
If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!
Here's a checklist to do before merging.

[ ] Bump the build number if needed

Fixes #2

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/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

For recipe/meta.yaml:

ℹ No valid build backend found for Python recipe for package arcp using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12388990999. Examine the logs at this URL for more detail.

Attempted to address these issues in https://github.com/conda-forge/arcp-feedstock/pull/6
This PR can be closed in favour of the above.

authors: conda-forge-admin ewels

repo: conda-forge/arcp-feedstock

license_source: github-api


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.2.2) 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

repo: conda-forge/azure-mgmt-feedstock


text:
install static libraries and import libraries for support libraries

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, rerender

This has caused some of our asan builds to fail with:
/conda-env/bin/../lib/gcc/x86_64-conda-linux-gnu/13.2.0/../../../../x86_64-conda-linux-gnu/bin/ld: warning: libstdc++.so.6, needed by /conda-env/bin/../lib/gcc/x86_64-conda-linux-gnu/13.2.0/libasan.so, not found (try using -rpath or -rpath-link)

Minimal repro:
bin/x86_64-conda_cos6-linux-gnu-g++ -g -fno-omit-frame-pointer -fsanitize=leak -fsanitize=address -flto -fno-fat-lto-objects repro.cpp -lfmt

#include <fmt/format.h>
#include <iostream>

int main() { std::cout << fmt::format("hello world\n"); }

authors: apmorton isuruf

repo: conda-forge/ctng-compilers-feedstock


text:
dash-pydantic-form v0.10.1

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

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

ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12351480921. Examine the logs at this URL for more detail.

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/12351486139. Examine the logs at this URL for more detail.

authors: RenaudLN conda-forge-admin


text:
fix recipe lint: SPDX, etc

didn't quite get it through on #12, but we should investigate the correct license string to appease the linter.

This lint is a more of a suggestion, nice to get it fixed though so automated tools can parse the licenses.

Things Not Strings!

Fixed by #17

authors: bollwyvl ocefpaf

repo: conda-forge/deap-feedstock


text:
Update to 3.0a6

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/finesse-feedstock


text:
Rebuild for uhd420

Checklist

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

authors: conda-forge-linter ryanvolz

repo: conda-forge/gnuradio-feedstock


text:
Remove conda-build overdepending warnings

Checklist

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

libaio (linux) and libiconv (osx) appear to be build-only requirements. By removing them from the host requirements, I removed the following conda-build warnings about overdepending:
# linux
WARNING (libtiledb-sql): run-exports library package conda-forge/linux-64::zlib==1.2.13=hd590300_5 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)

# osx
WARNING (libtiledb-sql): run-exports library package conda-forge/osx-64::libiconv==1.17=hd75f5a5_2 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)

Note that this means libaio and libiconv will no longer be installed at runtime. The current tests only check for the presence of installed files, and don't actually confirm the installed code is functional. Does it make sense that libaio and libiconv would only be needed at build time?
xref: https://github.com/conda-forge/libtiledb-sql-feedstock/pull/160#issuecomment-2070456339

Does it make sense that libaio and libiconv would only be needed at build time?

I investigated this question more.
libaio
I am pretty confident that libaio only needs to be installed at build time.
For Debian/Ubuntu, libaio is split into a development only package (libaio-dev) and a shared library package (libaio1).
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

$ apt search libaio
Sorting... Done
Full Text Search... Done
libaio-dev/jammy 0.3.112-13build1 amd64
  Linux kernel AIO access library - development files

libaio1/jammy 0.3.112-13build1 amd64
  Linux kernel AIO access library - shared library

The TileDB-MariaDB Dockerfile installs libaio-dev and not libaio1. Similarly, the Debian Control file for the MariaDB server lists libaio-dev in the section Build-Depends.
Lastly, I confirmed that the conda-forge recipe produces the required header file libaio.h.
libiconv
I am less certain about libiconv:

The library mode. This works on all systems, and uses a library libiconv.so
and a header file <iconv.h>. (Both are installed through "make install".)
To use it, simply #include <iconv.h> and use the functions.

The string "iconv" doesn't appear anywhere in TileDB-MariaDB.
From the discussion in https://github.com/MariaDB/server/pull/1743, it is clear that libiconv is required at build time on macOS.
However, searching for "iconv" in MariaDB server, I can't find any explicit evidence that they are using the header file via iconv.h. I did find the following LINK_LIBRARIES call in storage/connect/CMakeLists.tx, but it is unclear to me from the CMake docs if this is static or dynamic linking.
MYSQL_ADD_PLUGIN(connect ${CONNECT_SOURCES}
  STORAGE_ENGINE
  COMPONENT connect-engine
  RECOMPILE_FOR_EMBEDDED
  LINK_LIBRARIES ${ZLIB_LIBRARY} ${XML_LIBRARY} ${ICONV_LIBRARY}
    ${ODBC_LIBRARY} ${MONGOC_LIBRARY} ${IPHLPAPI_LIBRARY} ${REST_LIBRARY})

repo: conda-forge/libtiledb-sql-feedstock


text:
Update to 12.0.0rc3

SVML patches are currently commented out.

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)
[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)
[ ] 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/llvmdev This is ready for review/merge.

Can you merge this with master?

@isuruf Merged with master and got CI back to green :)

Now CI is green 💚

@isuruf Any idea on the Linux failures?

There is an upstream bug report for this https://bugs.llvm.org/show_bug.cgi?id=48992

llvm 12.0.0 was released; let's hope that bug gets fixed soon -> carry patch or wait for 12.0.1?

llvm 12.0.0 was released; let's hope that bug gets fixed soon -> carry patch or wait for 12.0.1?

There is currently no patch for the issue.

I understand, hence "let's hope that bug gets fixed soon". Sorry for making this hard to grok by mixing in the consequences of that yet-to-be bugfix missing 12.0.0

There is currently no patch for the issue.

Speaking of which, I saw you have an account on bugs.llvm - could you mark the issue as blocking 12.0.1 so that it hopefully doesn't miss the boat again?

@isuruf I would skip the failing tests on Linux and then would like to merge this to also update the remaining LLVM bits (MLIR, clang) to the latest RC. This would help us (i.e. myself) to prepare the recipes for when we merge the 12 release here. Would that be OK with you?

We can directly go to packaging 12.0.0. I don't think there's anything useful in packaging 12.0.0.rc5

I only wanted to do this as we probably don't want to merge the release until the SVML patches are updated.

I only wanted to do this as we probably don't want to merge the release until the SVML patches are updated.

I think that's fine. SVML patches are only needed for numba which doesn't support LLVM 12 yet (not even 11)

authors: conda-forge-linter h-vetinari isuruf xhochy

repo: conda-forge/llvmdev-feedstock


text:
DO NOT MERGE (Hopefully satisfy linter)

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.

Closing, replaced by https://github.com/conda-forge/mcstas-suite-feedstock/pull/13

repo: conda-forge/mcstas-suite-feedstock


text:
Add myself as maintainer

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.
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.

@conda-forge-admin, please rerender

authors: conda-forge-linter jan-janssen

repo: conda-forge/mutagen-feedstock


text:
Update to version 0.3.0

It seem the conda bot has not seen it yet.
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.

All green, and that should fix the last test in napari related to bundles.

authors: Carreau conda-forge-linter


text:
Fix pkgconfig

Checklist

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

Move lib/pkgconfig to omniorb-libs.
Without those files, pkg-config can't find the libraries when installing only omniorb-libs.
This should avoid having to install omniorb as build/host requirement.
I also noticed a lot of extra files included in omniorb when testing the build locally. The output was relying on conda-build to filter on new files but that's not supposed to work when specifying multiple outputs. Not sure why it worked until now.
I listed explicitly all files to include (using some regex on files - can't be used on directories).
I compared the list of files with previous packages.

@conda-forge-admin, please rerender

repo: conda-forge/omniorb-feedstock


text:
Pre-release 2024.2.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.

@conda-forge-admin, please rerender

repo: conda-forge/openvino-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

repo: conda-forge/pkg-config-feedstock


text:
GooString: only export non-inline methods for MSVC builds, not the whole class

As noted in the comment of the patch, exporting the whole class causes
duplicated symbols to be exported, and other link issues as can be seen
in downstream GDAL project: https://github.com/OSGeo/gdal/issues/5513.
The GDAL build failure occured when Conda updated from poppler-21.03.0
to poppler-22.01.0
The issue specifically appears on Windows Conda Poppler builds, that
build thee 'poppler' library as a shared one (cf
https://github.com/conda-forge/poppler-feedstock/blob/127ae45699e7442aee3be4b55f5d1e37fc166658/recipe/exportsymbols.patch#L10)
This patch (actually a slightly modified version that applies on top of
Poppler master) has been submitted to upstream Poppler project per:
https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1134

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 @rouault! I bumped the build number and I'll mark the build number 1 as broken.

https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1134 was just merged into Poppler master, so once a next Poppler release is out, the patch added here can be removed

https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1134 was just merged into Poppler master, so once a next Poppler release is out, the patch added here can be removed

That PR didn't bump the build number, so I think it needs to be rerendered and pushed again to have effect.

That PR didn't bump the build number, so I think it needs to be rerendered and pushed again to have effect.

Sorry, I misread the diff. It did.

It should only have held up the particular linux-aarch64 build which failed. I retriggered it, so hopefully that one should go through soon as well.

authors: conda-forge-linter hobu ocefpaf pkgw rouault

repo: conda-forge/poppler-feedstock


text:
v045

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.

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: DirkEilander conda-forge-linter

repo: conda-forge/pyflwdir-feedstock


text:
Cannot install pymultinest with conda-forge

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
I try conda install -c conda-forge pymultinest and I get the error
> conda install -c conda-forge pymultinest
Collecting package metadata (current_repodata.json): done
Solving environment: unsuccessful initial attempt using frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: unsuccessful initial attempt using frozen solve. Retrying with flexible solve.

PackagesNotFoundError: The following packages are not available from current channels:

  - pymultinest

Current channels:

  - https://conda.anaconda.org/conda-forge/osx-arm64
  - https://conda.anaconda.org/conda-forge/noarch
  - https://repo.anaconda.com/pkgs/main/osx-arm64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/r/osx-arm64
  - https://repo.anaconda.com/pkgs/r/noarch

To search for alternate channels that may provide the conda package you're
looking for, navigate to

    https://anaconda.org

and use the search bar at the top of the page.

I tried searching online and found this direction:
https://anaconda.org/conda-forge/pymultinest
conda install -c conda-forge pymultinest
conda install -c "conda-forge/label/cf201901" pymultinest
conda install -c "conda-forge/label/cf202003" pymultinest
but none of those worked.
I also tried ensuring conda-forge was an available channel by doing:
> conda config --show channels

channels:
  - conda-forge
  - defaults

Installed packages
# Name                    Version                   Build  Channel
absl-py                   1.4.0                    pypi_0    pypi
appnope                   0.1.2           py38hca03da5_1001
arviz                     0.16.1                   pypi_0    pypi
astropy                   5.2.2            py38h90f3b1b_0    conda-forge
asttokens                 2.0.5              pyhd3eb1b0_0
astunparse                1.6.3                    pypi_0    pypi
attrs                     23.1.0             pyh71513ae_1    conda-forge
backcall                  0.2.0              pyhd3eb1b0_0
bilby                     2.1.1              pyhd8ed1ab_0    conda-forge
bilby.cython              0.4.0            py38hb39dbe9_0    conda-forge
bilby_pipe                1.1.2              pyhd8ed1ab_0    conda-forge
blosc                     1.21.3               h1d6ff8b_0    conda-forge
boost-cpp                 1.78.0               h9ed8d21_3    conda-forge
brotli                    1.0.9                h1a8c8d9_9    conda-forge
brotli-bin                1.0.9                h1a8c8d9_9    conda-forge
brotli-python             1.0.9            py38h2b1e499_9    conda-forge
bzip2                     1.0.8                h3422bc3_4    conda-forge
c-ares                    1.19.1               hb547adb_0    conda-forge
ca-certificates           2023.5.7             hf0a4a13_0    conda-forge
cached-property           1.5.2                hd8ed1ab_1    conda-forge
cached_property           1.5.2              pyha770c72_1    conda-forge
cachetools                5.3.1                    pypi_0    pypi
certifi                   2023.5.7                 pypi_0    pypi
cffi                      1.15.1           py38ha45ccd6_3    conda-forge
cfitsio                   4.2.0                h2f961c4_0    conda-forge
charset-normalizer        3.2.0              pyhd8ed1ab_0    conda-forge
click                     8.1.6           unix_pyh707e725_0    conda-forge
colorama                  0.4.6              pyhd8ed1ab_0    conda-forge
configargparse            1.5.5              pyhd8ed1ab_0    conda-forge
contourpy                 1.0.7            py38h9dc3d6a_0    conda-forge
corner                    2.1.0              pyhd3deb0d_1    conda-forge
cryptography              41.0.2           py38h92a0862_0    conda-forge
cycler                    0.11.0             pyhd8ed1ab_0    conda-forge
cyrus-sasl                2.1.27               h59bf3fd_6    conda-forge
decorator                 5.1.1              pyhd3eb1b0_0
deepdish                  0.3.7              pyhd8ed1ab_0    conda-forge
dill                      0.3.6              pyhd8ed1ab_1    conda-forge
dqsegdb2                  1.1.4              pyhd8ed1ab_0    conda-forge
dust-extinction           1.2                      pypi_0    pypi
dynesty                   2.1.2              pyhd8ed1ab_0    conda-forge
emcee                     3.1.4              pyhd8ed1ab_0    conda-forge
exceptiongroup            1.1.2              pyhd8ed1ab_0    conda-forge
executing                 0.8.3              pyhd3eb1b0_0
extinction                0.4.6                    pypi_0    pypi
fftw                      3.3.10          nompi_h3046061_106    conda-forge
fgivenx                   2.4.1              pyhd8ed1ab_0    conda-forge
flatbuffers               23.5.26                  pypi_0    pypi
fonttools                 4.41.0           py38hb192615_0    conda-forge
freetype                  2.12.1               hd633e50_1    conda-forge
future                    0.18.3             pyhd8ed1ab_0    conda-forge
gast                      0.4.0                    pypi_0    pypi
google-auth               2.22.0                   pypi_0    pypi
google-auth-oauthlib      1.0.0                    pypi_0    pypi
google-pasta              0.2.0                    pypi_0    pypi
grpcio                    1.56.0                   pypi_0    pypi
gsl                       2.7                  h6e638da_0    conda-forge
gwdatafind                1.1.3              pyhd8ed1ab_0    conda-forge
gwosc                     0.7.1              pyhd8ed1ab_0    conda-forge
gwpy                      3.0.5              pyhd8ed1ab_0    conda-forge
h5netcdf                  1.0.2                    pypi_0    pypi
h5py                      3.9.0           nompi_py38hbfe8551_100    conda-forge
hdf5                      1.14.0          nompi_h6b85c65_102    conda-forge
healpy                    1.16.2           py38hcc1952c_0    conda-forge
icu                       72.1                 he12128b_0    conda-forge
idna                      3.4                pyhd8ed1ab_0    conda-forge
igwn-auth-utils           0.4.0              pyhd8ed1ab_0    conda-forge
importlib-metadata        6.8.0              pyha770c72_0    conda-forge
importlib-resources       6.0.0                    pypi_0    pypi
iniconfig                 2.0.0              pyhd8ed1ab_0    conda-forge
ipython                   8.12.0           py38hca03da5_0
jedi                      0.18.1           py38hca03da5_1
jinja2                    3.1.2              pyhd8ed1ab_1    conda-forge
joblib                    1.3.1                    pypi_0    pypi
keras                     2.13.1                   pypi_0    pypi
kiwisolver                1.4.4            py38h9dc3d6a_1    conda-forge
krb5                      1.20.1               h69eda48_0    conda-forge
lalinference-data         4.1.3                hce30654_0    conda-forge
lalsimulation-data        5.1.0                hce30654_0    conda-forge
lalsuite                  7.16                     pypi_0    pypi
lcms2                     2.15                 hd835a16_1    conda-forge
ldas-tools-al             2.6.7                hb7217d7_4    conda-forge
ldas-tools-framecpp       2.9.2                hd9792b9_0    conda-forge
lerc                      4.0.0                h9a09cb3_0    conda-forge
libaec                    1.0.6                hb7217d7_1    conda-forge
libblas                   3.9.0           17_osxarm64_openblas    conda-forge
libbrotlicommon           1.0.9                h1a8c8d9_9    conda-forge
libbrotlidec              1.0.9                h1a8c8d9_9    conda-forge
libbrotlienc              1.0.9                h1a8c8d9_9    conda-forge
libcblas                  3.9.0           17_osxarm64_openblas    conda-forge
libclang                  16.0.6                   pypi_0    pypi
libcurl                   8.1.2                h912dcd9_0    conda-forge
libcxx                    14.0.6               h848a8c0_0
libdeflate                1.18                 h1a8c8d9_0    conda-forge
libedit                   3.1.20191231         hc8eb9b7_2    conda-forge
libev                     4.33                 h642e427_1    conda-forge
libffi                    3.4.4                hca03da5_0
libframel                 8.42.2               h1a8c8d9_1    conda-forge
libgfortran               5.0.0           11_3_0_hca03da5_28
libgfortran5              11.3.0              h009349e_28
libjpeg-turbo             2.1.5.1              h1a8c8d9_0    conda-forge
liblal                    7.3.1           fftw_hca2794d_100    conda-forge
liblalburst               2.0.1                h50b553b_0    conda-forge
liblalframe               3.0.1                h1a8c8d9_0    conda-forge
liblalinference           4.1.3                h689202d_0    conda-forge
liblalinspiral            4.0.1                h50b553b_0    conda-forge
liblalmetaio              4.0.1                h1a8c8d9_0    conda-forge
liblalsimulation          5.1.0                h689202d_0    conda-forge
liblapack                 3.9.0           17_osxarm64_openblas    conda-forge
libmetaio                 8.5.1             h76d750c_1002    conda-forge
libnghttp2                1.52.0               hae82a92_0    conda-forge
libntlm                   1.4               h3422bc3_1002    conda-forge
libopenblas               0.3.23          openmp_hc731615_0    conda-forge
libpng                    1.6.39               h76d750c_0    conda-forge
libsqlite                 3.42.0               hb31c410_0    conda-forge
libssh2                   1.11.0               h7a5bd25_0    conda-forge
libtiff                   4.5.0                h4f7d55c_6    conda-forge
libwebp-base              1.3.1                hb547adb_0    conda-forge
libxcb                    1.15                 hf346824_0    conda-forge
libzlib                   1.2.13               h53f4e23_5    conda-forge
ligo-gracedb              2.11.0             pyhd8ed1ab_0    conda-forge
ligo-segments             1.4.0            py38hb991d35_4    conda-forge
ligotimegps               2.0.1                      py_0    conda-forge
llvm-openmp               14.0.6               hc6e5704_0
lscsoft-glue              3.0.1            py38hb991d35_1    conda-forge
lz4-c                     1.9.4                hb7217d7_0    conda-forge
markdown                  3.4.3                    pypi_0    pypi
markupsafe                2.1.3            py38hb192615_0    conda-forge
matplotlib-base           3.6.3            py38hbbe890c_0    conda-forge
matplotlib-inline         0.1.6            py38hca03da5_0
mpi                       1.0                     openmpi
mpi4py                    3.1.4            py38he4f2fd2_0
mpmath                    1.3.0              pyhd8ed1ab_0    conda-forge
multiprocess              0.70.14          py38hb991d35_3    conda-forge
munkres                   1.1.4              pyh9f0ad1d_0    conda-forge
ncurses                   6.4                  h313beb8_0
nds2-client               0.16.8               h5f84315_3    conda-forge
nestcheck                 0.2.1              pyhd8ed1ab_0    conda-forge
nmma                      0.0.13                   pypi_0    pypi
numexpr                   2.8.4            py38hfaca753_0    conda-forge
numpy                     1.24.2           py38hac8ee1c_0    conda-forge
oauthlib                  3.2.2                    pypi_0    pypi
openjpeg                  2.5.0                hbc2ba62_2    conda-forge
openmpi                   4.1.1                h840aa90_1
openssl                   3.1.1                h53f4e23_1    conda-forge
opt-einsum                3.3.0                    pypi_0    pypi
p-tqdm                    1.4.0              pyhd8ed1ab_0    conda-forge
packaging                 23.1               pyhd8ed1ab_0    conda-forge
pandas                    2.0.0            py38h61dac83_0    conda-forge
parallel-bilby            2.0.2              pyhd8ed1ab_0    conda-forge
parso                     0.8.3              pyhd3eb1b0_0
pathos                    0.3.0              pyhd8ed1ab_0    conda-forge
patsy                     0.5.3              pyhd8ed1ab_0    conda-forge
pesummary                 1.0.0              pyhd8ed1ab_0    conda-forge
pexpect                   4.8.0              pyhd3eb1b0_3
pickleshare               0.7.5           pyhd3eb1b0_1003
pillow                    9.5.0            py38h3f590de_1    conda-forge
pip                       23.2                     pypi_0    pypi
platformdirs              3.9.1              pyhd8ed1ab_0    conda-forge
plotly                    5.15.0             pyhd8ed1ab_0    conda-forge
pluggy                    1.2.0              pyhd8ed1ab_0    conda-forge
pooch                     1.7.0              pyha770c72_3    conda-forge
pox                       0.3.2              pyhd8ed1ab_0    conda-forge
ppft                      1.7.6.6            pyhd8ed1ab_0    conda-forge
prompt-toolkit            3.0.36           py38hca03da5_0
protobuf                  4.23.4                   pypi_0    pypi
pthread-stubs             0.4               h27ca646_1001    conda-forge
ptyprocess                0.7.0              pyhd3eb1b0_2
pure_eval                 0.2.2              pyhd3eb1b0_0
pyasn1                    0.5.0                    pypi_0    pypi
pyasn1-modules            0.3.0                    pypi_0    pypi
pycondor                  0.6.0              pyhd8ed1ab_0    conda-forge
pycparser                 2.21               pyhd8ed1ab_0    conda-forge
pyerfa                    2.0.0.3          py38hb39dbe9_0    conda-forge
pyfftw                    0.12.0           py38h22c8ccb_3    conda-forge
pygments                  2.15.1             pyhd8ed1ab_0    conda-forge
pyjwt                     2.8.0              pyhd8ed1ab_0    conda-forge
pyopenssl                 23.2.0             pyhd8ed1ab_1    conda-forge
pyparsing                 3.1.0              pyhd8ed1ab_0    conda-forge
pyrxp                     3.0.1            py38hb991d35_3    conda-forge
pysocks                   1.7.1              pyha2e5f31_6    conda-forge
pytables                  3.7.0            py38hd2f1acd_4    conda-forge
pytest                    7.4.0              pyhd8ed1ab_0    conda-forge
pytest-runner             6.0.0              pyhd8ed1ab_0    conda-forge
python                    3.8.17          h3ba56d0_0_cpython    conda-forge
python-dateutil           2.8.2              pyhd8ed1ab_0    conda-forge
python-lal                7.3.1           fftw_py38h19824b6_100    conda-forge
python-lalburst           2.0.1            py38hb7ed40b_0    conda-forge
python-lalframe           3.0.1            py38h90f3b1b_0    conda-forge
python-lalinference       4.1.3            py38h90f3b1b_0    conda-forge
python-lalinspiral        4.0.1            py38h90f3b1b_0    conda-forge
python-lalmetaio          4.0.1            py38h90f3b1b_0    conda-forge
python-lalsimulation      5.1.0            py38h90f3b1b_0    conda-forge
python-ldas-tools-al      2.6.10           py38h9dc3d6a_2    conda-forge
python-ldas-tools-framecpp 2.6.14           py38h61dac83_2    conda-forge
python-ligo-lw            1.8.3            py38hb991d35_1    conda-forge
python-nds2-client        0.16.12          py38h61dac83_3    conda-forge
python-tzdata             2023.3             pyhd8ed1ab_0    conda-forge
python_abi                3.8                      3_cp38    conda-forge
pytz                      2023.3             pyhd8ed1ab_0    conda-forge
pyyaml                    6.0              py38hb991d35_5    conda-forge
readline                  8.2                  h1a28f6b_0
requests                  2.31.0             pyhd8ed1ab_0    conda-forge
requests-oauthlib         1.3.1                    pypi_0    pypi
rsa                       4.9                      pypi_0    pypi
safe-netrc                1.0.0                      py_0    conda-forge
schwimmbad                0.3.2            py38h10201cd_3    conda-forge
scikit-learn              1.0.2            py38h9197a36_1
scipy                     1.10.1           py38h7b4f323_0    conda-forge
scitokens                 1.7.4              pyhd8ed1ab_0    conda-forge
seaborn                   0.12.2               hd8ed1ab_0    conda-forge
seaborn-base              0.12.2             pyhd8ed1ab_0    conda-forge
setuptools                67.8.0           py38hca03da5_0
six                       1.16.0             pyh6c4a22f_0    conda-forge
snappy                    1.1.10               h17c5cce_0    conda-forge
sncosmo                   2.10.1                   pypi_0    pypi
sqlite                    3.41.2               h80987f9_0
stack_data                0.2.0              pyhd3eb1b0_0
statsmodels               0.14.0           py38h58b515d_1    conda-forge
tenacity                  8.2.2              pyhd8ed1ab_0    conda-forge
tensorboard               2.13.0                   pypi_0    pypi
tensorboard-data-server   0.7.1                    pypi_0    pypi
tensorflow                2.13.0                   pypi_0    pypi
tensorflow-estimator      2.13.0                   pypi_0    pypi
tensorflow-macos          2.13.0                   pypi_0    pypi
termcolor                 2.3.0                    pypi_0    pypi
threadpoolctl             2.2.0              pyh0d69192_0
tk                        8.6.12               hb8d0fd4_0
tomli                     2.0.1              pyhd8ed1ab_0    conda-forge
tqdm                      4.65.0             pyhd8ed1ab_1    conda-forge
traitlets                 5.7.1            py38hca03da5_0
typing-extensions         4.5.0                    pypi_0    pypi
unicodedata2              15.0.0           py38hb991d35_0    conda-forge
urllib3                   1.26.16                  pypi_0    pypi
wcwidth                   0.2.5              pyhd3eb1b0_0
werkzeug                  2.3.6                    pypi_0    pypi
wheel                     0.38.4           py38hca03da5_0
wrapt                     1.15.0                   pypi_0    pypi
xarray                    2023.1.0                 pypi_0    pypi
xarray-einstats           0.3.0                    pypi_0    pypi
xorg-libxau               1.0.11               hb547adb_0    conda-forge
xorg-libxdmcp             1.1.3                h27ca646_0    conda-forge
xz                        5.4.2                h80987f9_0
yaml                      0.2.5                h3422bc3_2    conda-forge
zipp                      3.16.2             pyhd8ed1ab_0    conda-forge
zlib                      1.2.13               h53f4e23_5    conda-forge
zstd                      1.5.2                h4f39d0f_7    conda-forge

Environment info
active environment : nmma_venv
    active env location : /opt/homebrew/anaconda3/envs/nmma_venv
            shell level : 2
       user config file : /Users/brendanking/.condarc
 populated config files : /Users/brendanking/.condarc
          conda version : 23.5.0
    conda-build version : 3.25.0
         python version : 3.11.3.final.0
       virtual packages : __archspec=1=arm64
                          __osx=13.3=0
                          __unix=0=0
       base environment : /opt/homebrew/anaconda3  (writable)
      conda av data dir : /opt/homebrew/anaconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/osx-arm64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/osx-arm64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-arm64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /opt/homebrew/anaconda3/pkgs
                          /Users/brendanking/.conda/pkgs
       envs directories : /opt/homebrew/anaconda3/envs
                          /Users/brendanking/.conda/envs
               platform : osx-arm64
             user-agent : conda/23.5.0 requests/2.29.0 CPython/3.11.3 Darwin/22.4.0 OSX/13.3
                UID:GID : 501:20
             netrc file : None
           offline mode : False

Wow that's odd. It just worked fine for me. Any ideas @conda-forge/core?

Maybe try and see if you can install each of the requirements https://github.com/conda-forge/pymultinest-feedstock/blob/main/recipe/meta.yaml

Are you on osx-arm64? The pymultinest package doesn't seem to be available there.

I am on a brand new mac, would that be osx-arm64?

Yep. M1/M2 chips.
I think we can make this package noarch, which would make it available on osx-arm64 quicker. Let me see...

Noarch will solve this package, but we still won't have a build of multinest itself on osx-arm64.

Thanks @ocefpaf, could you please follow this up and report whether the issue is resolved and installs work now?

Thanks @ocefpaf, could you please follow this up and report whether the issue is resolved and installs work now?

There is nothing else we can do here but we need to add multinest to the osx-arm64 migration list in https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/migrations/osx_arm64.txt
The bot will send a PR with the boilerplate stuff to make multinest available on modern mac but, looking at the multinest feedstock, that may not help much and some expert help will probably be needed there.

authors: JohannesBuchner beckermr bking-astro ocefpaf

repo: conda-forge/pymultinest-feedstock


text:
DM-29521: Pin sqlite to avoid UNION ALL problem.

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)
[ ] 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 ktlim

repo: conda-forge/rubinenv-feedstock


text:
Adding v1.0.4

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.

repo: conda-forge/youtokentome-feedstock


text:
adding a note about setting the completion cache

As title

@Hanspe-3019 @jezdez -- trying to improve the user-experience here after the report in #60. What do you think?

The alternative would be to disable package completion, unless use-cache is set.

I just tried to avoid the cache by setting:
zstyle ':completion::complete:*' use-cache 0

but it seems this setting as no effect? Can anyone reproduce?

I'm going to merge this now, feel free to submit more PRs if you were not happy with how this turned out.

repo: conda-incubator/conda-zsh-completion

license: WTFPL


text:
v2.2.0 SemVer requirement breaks miniconda-version

The latest version of this action breaks pinning to specific versions of miniconda. The miniconda-version argument takes the form py37_4.9.2, which then gets rejected by the SemVer checker with a cryptic error message like this:
Run conda-incubator/setup-miniconda@v2.2.0
  with:
    miniconda-version: py37_4.9.2
    auto-update-conda: true
    activate-environment: saturn-k8s
    python-version: 3.7
    auto-activate-base: true
    remove-profiles: true
    architecture: x64
    clean-patched-environment-file: true
    run-post: true

Gathering Inputs...
Error: Invalid Version: py37_4.9.2

Pinned setup-miniconda back to v2.1.1 to get around the problem.

Hi @bhperry, thanks for the heads up,
Will look into it!
Cheers

I also ran into this today, see the workflow run here: https://github.com/Cantera/conda-recipes/actions/runs/9648308218/job/26609160590 This is still a problem with v3

As a workaround I think we can use installer-url pointing to the direct URL of the Miniconda installers, I think.

I think I just encountered this issue. The only problem with the workaround is that the installer-url depends on platform and python version, so one has to assemble the filename on the fly.

authors: bhperry bryanwweber goanpeca jaimergp javierggt

repo: conda-incubator/setup-miniconda

license: MIT


text:
deps: upgrade to Go 1.20.5

Upgrading to the latest Go version.
Fixes: #1139

The CI failure of controller test seems to be on GitHub's side, could anyone trigger a re-run? @bpradipt @stevenhorsman
Btw, is there a team like @confidential-containers/cloud-api-adaptor-maintainers one can mention?

Btw, is there a team like @confidential-containers/cloud-api-adaptor-maintainers one can mention?

Yes - the team is peer-pod-maintainers. I've also invited you to peer-pod-commiters, so you should be able to re-run the GHA yourself now

Thank you so much @stevenhorsman, happy to be part of the team! :blush:

Thank you so much @stevenhorsman, happy to be part of the team! 😊

You deserve for your contribution and the difference you've made, so thank you!

On this actual PR - we were trying to stay in sync with the kata-container's version of go (which is back on 1.19.3) for stability reasons, but if 1.20.5 is working and we keep the go.mod versions at 1.19 for compatibility, then I don't think there should be any issues?

and we keep the go.mod versions at 1.19 for compatibility

That would only be relevant if kata-containers would import cloud-api-adaptor as Go module, which it doesn't, right? If no other module with smaller module version imports cloud-api-adaptor, we can use the newest set of features regardless of what out dependencies do.
Go has strong backward-compatibility promises. Building code that uses an older feature set (like kata, with a smaller version in go.mod) can (and should) always be built with the newest Go toolchain/command. Using the newest toolchain will ensure that the latest security fixes in the standard library will be included in the binary (I also tried to explain this in https://github.com/confidential-containers/cloud-api-adaptor/pull/1116#discussion_r1242598594).
You can check locally, if you have an older Go command installed, run:
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

Thanks for the extra explanation!

Btw, is there a team like @confidential-containers/cloud-api-adaptor-maintainers one can mention?

Yes - the team is peer-pod-maintainers. I've also invited you to peer-pod-commiters, so you should be able to re-run the GHA yourself now

This was due. Thanks @stevenhorsman for doing the needful.
@katexochen thanks a lot for your contributions

authors: bpradipt katexochen stevenhorsman


text:
KREST-1031 Upgrade Jetty and Jersey to address a number of CVEs

See #252 - this merges the changes from there to 5.3.x, fixing the conflicts along the way. It should then be merged up with -s ours, as #246 and #249 have already introduced these changes in 5.4.x and up.

If #252 is merged with "Rebase and merge", we should be able to push the changes from here without further rebasing.

The CI run is failing because of a downstream dependency failure - blueway's control-center.
See https://github.com/confluentinc/rest-utils/pull/252#issuecomment-842114666.

repo: confluentinc/rest-utils


text:
Enable ezETH on Base

Background
ezETH to Base
Linked Issues & Documentation

List of linked issues, external links, etc

Definition Of Done
Describes in 1-2 sentences what the output of the Task is, so that it can be verified by another team member easily. “Feature X is implemented as described and can be verified by using it”
Tasks

[x] Whitelist ezETH token on base
[x] Add to UIs
[x] Test slow
[ ] (later) Add router liq
[ ] (later) Test fast

We are waiting on liquidity
cc: @alexwhte @par94

Moving it in backlog as we are waiting on above step

repo: connext/monorepo


text:
fix: typo

Description

Fixes issue here
Type of change

[ ] Docs change / dependency upgrade
[ ] Configuration / tooling changes
[ ] Refactoring
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Requires changes in customer code

High-level change(s) description - from the user's perspective

Related Issue(s)
Fixes
Related pull request(s)

closing in favor of https://github.com/connext/nxtp/pull/2341

repo: connext/nxtp


text:
fix(deps): move React from deps to devDeps to not bundle it in

This just makes it so that using this package doesn't accidentally bring in React 16.9, even when technically the peerDep says 16.8

Good catch!

word

published as 2.2.0

🎉

authors: chrisdhanaraj conorhastings jamesplease


text:
ASC 资产链上币申请

审核官您好，
ASC 致力于利用通证经济重构不动产行业，将从前由公司制度建立的生产关系过度到链上生态型通证经济，用公心重塑链上房地产生态，让每一个个体都能分享到不动产整个产业链的价值。
此项目目标与公司的现有地产项目整合，正在筹备交易所的上线工作。
有问题欢迎加微信讨论：lucky_sunyu
Best Regards,
Sun

这是空气币，上次还拿白皮书找我们发币，我们不同意

找的是专门发币的搞得看来，名字都没出来

楼上冒充ImToken管理员行骗，不成功则开始污蔑。水平太差，已向官方邮箱反馈。

"github": "https://github.com/dmsggg/token-profile",
github地址竟然是这个，你们的代码就是提交imtoken改图标的代码吗，空气币害人，官网也就一个home page ，找人做网站找个贵点的。。。

而且区块链浏览器上合约地址都没有名字，  还好意思写上"state": "NORMAL",你知道这个normal啥意思吗

真是笑死个人哈哈哈
sick.......市场不如预期，你们这些害人精有一份功劳，还蛮理直气壮。。。都是什么东西

PR里写都没上交易所，你的initial price 怎么来的，你做梦梦出来的吗，写有210亿，合约里都还没添加，还0.02ETH，你咋不去抢呀，超越比特币就靠你们了，币圈笑死人，负责吗

回家吧，你们在币圈就是害人

close 这个PR ..........

卧槽，本来就是装装B ，想让你消失，问你要钱了吗，你这个币上次找我发币我就没同意，17年末就瞎几把编了白皮书，我现在电脑里可能还有你之前的白皮书，现在就是改了个封面而已，你们后来不是想去做矿厂，怎么，还想来发个空气币割韭菜吗，你能ICO，我第一个举报，看怎么抓你，ASSET也是你有资源随便上链，国家搞这个也就会是无币区块链，白皮书麻烦下次多花点钱。。。。

可以移除没有的链接，另外请提供相关区块链媒体报道
   "reddit": "",
    "slack": "",
    "medium": ""

authors: Eiminyang ForBTM dmsggg makoshan

repo: consenlabs/token-profile


text:
Add the NFSC Token

Add the NFSC Token
0xf3871f565a6a216fbe0ea3cf806ab15a32830c1c.json
0xf3871f565a6a216fbe0ea3cf806ab15a32830c1c.png

请问0x0b6bc42cb9b89259a3aa986363fa37a9cbf03b8e.json这个文件提示错误，怎么解决
这个不是我上传的呀

Logo 需要居中

authors: fsc-cash makoshan


text:
GERC files upload.

GERC files upload.

GERC files upload.

你好，logo请勿有阴影，谢谢。


text:
Support for canvas elements

Thanks, great polyfill! Would it be possible to add support for polyfilling object-fit on thecanvas element as well?

We would also be interested in a work around for the canvas element.

Hey, so sorry it took me so long to get to this (no good excuse, I just needed a kick in the butt)! <canvas> should now be supported in the latest 2.2.0 version. I've thrown up an example of it here:
http://constancecchen.github.io/object-fit-polyfill/demo/
Let me know if it works for you! :)

Awesome, thanks!

authors: constancecchen fThues johndgiese

repo: constancecchen/object-fit-polyfill

license: ISC


text:
🛑 rosebud.partouze-cagoule.fr is down

In 0834174, rosebud.partouze-cagoule.fr (https://rosebud.partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: rosebud.partouze-cagoule.fr is back up in 1d88896.

repo: constructions-incongrues/status


text:
🛑 radio.musiqueapproximative.net is down

In e61ab66, radio.musiqueapproximative.net (https://radio.musiqueapproximative.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: radio.musiqueapproximative.net is back up in 2f34df4.


text:
🛑 mirror.pastis-hosting.net is down

In b17d0df, mirror.pastis-hosting.net (https://mirror.pastis-hosting.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: mirror.pastis-hosting.net is back up in 129f1cb.


text:
Concurrent Pull may return error snapshot already exists.

Concurrent client.Pull of the same image may return error failed to prepare extraction layer:  snapshot already exists.
This is caused by a known race. Need to address TODO to fix this.
To help prioritize:
This is not super urgent for us now, because we only pull image sequentially in production for the sake of some docker concurrent image pulling issue. However, we may want to enable concurrent image pulling in the future, if containerd image pulling is reliable.

@Random-Liu - I'll try to work on this one next week.

@yastij Any luck?

authors: Random-Liu stevvooe yastij

repo: containerd/containerd


text:
how can restore container from the image_path using ctr

What is the problem you're trying to solve
How can i restore container form the criu_image_path using ctr comamnd after i checkpoint the task into a image_path directory.
Describe the solution you'd like
Restore a container using the ctr comamnd, just like ctr container create --criu_image_path DIR Image|RootFS CONTAINER [COMMAND] [ARG...]
Additional context
cr: support checkpoint/restore without image

If only the image_path is there, it may not be possible to restore the complete container, and there may be errors in the restore, we may actually need a snapshot of the container rw layer during restore, so it is recommended to use ctr container checkpoint and ctr container restore to checkpoint/restore the container

If it's just to accelerate container startup in Serverless Computing,  do we need a snapshot of the container rw layer?

It looks like it's not needed, you can use ctr container checkpoint --task --image to not save the rw layer and restore to using ctr container restore --live.


text:
[release/1.3] Update .mailmap with changes from master

includes the changes made in https://github.com/containerd/containerd/pull/4037

don't merge yet; two more changes coming

Codecov Report

Merging #4038 into release/1.3 will increase coverage by 0.01%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release/1.3    #4038      +/-   ##
===============================================
+ Coverage        42.46%   42.47%   +0.01%
===============================================
  Files              129      129
  Lines            14355    14355
===============================================
+ Hits              6096     6098       +2
+ Misses            7364     7363       -1
+ Partials           895      894       -1

Flag
Coverage Δ

#linux
45.98% <ø> (+0.01%)
:arrow_up:

#windows
37.5% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

snapshots/btrfs/btrfs.go
58.29% <0%> (+0.89%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5811bc9...a2d1cbf. Read the comment docs.

authors: codecov-io thaJeztah


text:
Refactor validate and verify testing to containerd/project infra

We should do our validation and verification testing using containerd/project infra code. This is one of the steps we need to do for moving containerd/cri into containerd/containerd.
We currently do most of our verify testing via a clone of kubernetes infra code.
I have started a migration to containerd/project validation and verification testing.
If you look at .github/workflows/ci.yml you'll see we are already using:
../project/script/validate/dco
../project/script/validate/vendor
To to items:

[x] move to github actions for validation testing
[ ] move to github actions for verification testing
[x] modify makefile validation testing to use /project (PR in progress)
[ ] modify makefile verification to use /project

I'll add more sub-steps here.

Still need to work on moving our cri verification testing to the /project way. Need to do this as a larger part of moving the CRI plugin into containerd so we can avoid the release and vendor work to keep us in sync.

repo: containerd/cri


text:
nerdctl push  level=fatal msg="content digest sha256:xxx: not found"

Description
nerdctl push  level=fatal msg=content digest sha256:xxx: not found
Steps to reproduce the issue
command :

nerdctl commit --namespace xxx "${CONTAINER_ID}" "${_IMAGE_INFO}"

nerdctl push --namespace xxx "${_IMAGE_INFO}" --all-platforms --insecure-registry --hosts-dir /etc/cert/certs.d/

Describe the results you received and expected
1.return msg:
level=warning msg="Image lacks label "nerdctl/platform", assuming the platform to be "linux/arm64/v8""
sha256:91d29b450fd577c6178932589d82d6605cfba904b7d16b75d6e81bbf00426057
2.return msg:
level=warning msg="skipping verifying HTTPS certs for "harbor address""
manifest-sha256:0ec2084b9ea28247e6039d3a4d4a1dc7303283a2d026dbc136d1bc52b488278c: waiting        |--------------------------------------|
config-sha256:91d29b450fd577c6178932589d82d6605cfba904b7d16b75d6e81bbf00426057:   waiting        |--------------------------------------|
elapsed: 0.1 s                                                                    total:   0.0 B (0.0 B/s)
manifest-sha256:0ec2084b9ea28247e6039d3a4d4a1dc7303283a2d026dbc136d1bc52b488278c: waiting        |--------------------------------------|
config-sha256:91d29b450fd577c6178932589d82d6605cfba904b7d16b75d6e81bbf00426057:   waiting        |--------------------------------------|
elapsed: 0.2 s                                                                    total:   0.0 B (0.0 B/s)
level=fatal msg="content digest sha256:cd25eaaf6be54ee842ccee9897790061be5fc8f83a04a3766fe9b94c14669855: not found"
What version of nerdctl are you using?
1.5.0
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
No response

Please try removing --all-platforms

Removing  --all-platforms  will be the same problem.

+1 I had the same problem.

+1 I had the same problem.
but nerdctl run works fine.

I did some research and found that the issue was caused by the absence of the compressed layer in the base image. You need to first execute nerdctl pull xxxx --unpack=false for the base image, and then push the committed image.
Does this meet your expectations?

@kebe7jun  I`ll try , thanks.

repo: containerd/nerdctl


text:
Testing framework runs use multiple VPCs

Our biggest bottle neck in our testing infrastructure is the AWS VPCs. The testing framework has been reduced to once a day to reduce the impact of this on our testing infrastructure, however we should revisit the testing framework to identify if we can reduce VPC usage.
Thread context: https://redhat-internal.slack.com/archives/C06S75ZF9JT/p1714776356330419?thread_ts=1714770376.544109&cid=C06S75ZF9JT
/cc @lmilbaum

Other options are to use different regions for different pipelines and/or increase the number of VPCs limit

authors: Gregory-Pereira lmilbaum

repo: containers/ai-lab-recipes


text:
Add FromLogrusLevel helper

What type of PR is this?
/kind feature
What this PR does / why we need it:
This allows easy type conversion between the log levels and avoids mismatches like "warn" (conmon-rs) and "warning" (logrus).
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

Added `FromLogrusLevel` helper function.

@rphillips @haircommander PTAL

@saschagrunert is anything using the new function?

@saschagrunert is anything using the new function?

CRI-O will use it. Found a bug between the “warning” and “warn” mismatch.

/lgtm

authors: rphillips saschagrunert

repo: containers/conmon-rs


text:
[WIP] Add tcp-established to checkpoint/restore

This adds the possibility to checkpoint and restore containers with established TCP connections. See third commit for details and examples. This PR also includes updates to the bash completion which was missing a few of the recently added checkpoint/restore features.

See https://github.com/kubernetes-sigs/cri-o/pull/1926 for required conmon changes.

FYI @rst0git

Since this depends on conmon changes, I'll hold off on adding an approved tag until that merges

Hmm, all checkpoint tests are failing, strange. It works locally. Need to figure what is going on.

Ah, so I have an idea why the checkpoint tests are failing. Since today criu 3.11 is part of all Fedora branches and now a criu version is automatically installed which has all the features for Podman.
Up until now the container in container checkpoint tests were not run, because the CRIU version in the container was too old. Now it is new enough, but CRIU cannot handle to checkpoint a container running in another container. Need to try the test cases (Podman in Podman) locally.

Pushed a test commit. See also https://github.com/containers/libpod/pull/1855

Pushed a test commit. See also #1855

the patch LGTM.  If it fixes the CI failures it is probably worth to move it to its own PR so to unblock other PRs as well

the patch fixes the tests, could you please move it to a separate PR?

Since this PR is adding support for tcp-established to enable checkpoint of established TCP connections, should also add support for skip-in-flight and tcp-close for completeness?

Since this PR is adding support for tcp-established to enable checkpoint of established TCP connections, should also add support for skip-in-flight and tcp-close for completeness?

Yes and no :grin: The reason to not add it is to have only 'one' change in this PR and the real reason is, that runc does not yet support those CRIU flags. So first the changes need to be added to runc and then we can look at adding those features to Podman. Which makes more sense as another PR.

@TomSweeneyRedHat thanks a lot for your review. I addressed all your reviews and force pushed a version.
Without the changes which are now part of #1858

conmon changes have been merged

/restest

/approve

/ok-to-test

Let's see if the tests pick up the new conmon version or if we hardcode a commit somewhere

The CI failures seem to be related to problems with the container registries.

bot, retest this please

Cirrus timeout is suspicious - I re-triggered, but we'll see.
Really annoying it's not actually throwing whatever error caused it to hang, if it is one.

@adrianreber Seems to be timing out trying to restore?
Running: /usr/bin/podman --root /tmp/podman_test449995664/crio --runroot /tmp/podman_test449995664/crio-run --runtime /usr/bin/runc --conmon /usr/libexec/podman/conmon --cni-config-dir /etc/cni/net.d --cgroup-manager cgroupfs --storage-driver=vfs container restore -l

@mheon thanks for looking into it. It seems my test for testing checkpointing with tcp-established does not work correctly in the CI. I am starting a container with --network=host and I am trying to connect to it. It works locally, but probably not in the CI. I will remove the test case to see if that helps. Too many changes in one PR it seems.

I also see errors like this in cirrus https://cirrus-ci.com/task/6388882125881344:
varlink.error.VarlinkError: {'parameters': {'reason': 'cgroups: cgroup mountpoint does not exist'}, 'error': 'io.podman.ErrorOccurred'}```

Is this a known problem? Or triggered by my changes?

Known flake that seems to have gotten a lot more common now - previously was 1 in 10 or 15 runs, now seems like it's happening every time. I'll grab @jwhonce and see if I can get a fix in.

Cool, everything green. This includes an updated conmon and new CRIU version. Instead of pointing to the CRIU development branch which will be rebased/rewritten occasionally this now points to the stable branch which has stable commits.
From my point of view this is no longer WIP as the necessary conmon changes have been merged and pulled in in this PR for testing.

LGTM
@mheon @baude @umohnani8 @jwhonce @vrothberg PTAL

Looks fine, merging
/lgtm

authors: adrianreber giuseppe mheon rhatdan rst0git

repo: containers/libpod


text:
Podman Desktop E2E nightly pipeline on Mac fails sometimes with an error from program execution of the shell script

We can see sometimes an error from executing various command from the pde2e-runner script:
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
node-v20.11.1-darwin-arm64/bin/node: Lzma library error:  No progress is possible
tar: Error exit delayed from previous errors.
Node Installation path found
Node.js Version:
npm Version:
git version 2.39.3 (Apple Git-146)
Installing pnpm
pd-e2e/runner.sh: line 282: 23854 Killed: 9               sudo npm install -g pnpm

This time it seems that downloading/installing node was not really finished.

maybe concurrency of another job is the problem on this machine.


text:
WIP: Extending e2e graphical happy path scenario

What does this PR do?

Implements AI Lab Page
Extends ai-lab-extension.spec.ts test

Screenshot / video of UI
N/A

What issues does this PR fix or reference?
#978

How to test this PR?

cd
yarn install
yarn test:e2e:build
cd
export PODMAN_DESKOTP_ARGS=; yarn test:e2e

Nice seeing some e2e for podman AI Lab 🚀 !
Was wondering, should the tests stop if one fails ? Like it does not make sense to continue if the installation fail, not sure if this is possible with vitest/playwright

Nice seeing some e2e for podman AI Lab 🚀 !
Was wondering, should the tests stop if one fails ? Like it does not make sense to continue if the installation fail, not sure if this is possible with vitest/playwright

It would be a bit hacky, but possible, imho. It is great idea!

authors: ScrewTSW axel7083 odockal


text:
podman_container_mem_usage_bytes metrics disappeared

Describe the bug
I used to query podman_container_mem_usage_bytes in prometheus, but now noticed it's not exposed anymore. a manual crawl of the /metrics file confirms this.
To Reproduce
unfortunately I can't really say what has changed. First I assumed a permission problem on the podman socket and created a separate one only for the prometheus-podman-exporter container:
/ $ id
uid=65534(nobody) gid=65534(nobody)
/ $ ls -la /run/podman/podman.sock
srw-------    1 nobody   nobody           0 Dec  5 17:35 /run/podman/podman.sock
/ $

logs (last 7 lines repeat):
ts=2022-12-05T17:35:47.710Z caller=exporter.go:63 level=info msg="Starting podman-prometheus-exporter" version="(version=1.3.0, branch=main, revision=dev.1)"
ts=2022-12-05T17:35:47.711Z caller=handler.go:93 level=info msg="enabled collectors"
ts=2022-12-05T17:35:47.711Z caller=handler.go:104 level=info collector=container
ts=2022-12-05T17:35:47.711Z caller=handler.go:104 level=info collector=image
ts=2022-12-05T17:35:47.711Z caller=handler.go:104 level=info collector=network
ts=2022-12-05T17:35:47.711Z caller=handler.go:104 level=info collector=pod
ts=2022-12-05T17:35:47.711Z caller=handler.go:104 level=info collector=system
ts=2022-12-05T17:35:47.711Z caller=handler.go:104 level=info collector=volume
ts=2022-12-05T17:35:47.711Z caller=exporter.go:74 level=info msg="Listening on" address=127.0.0.1:9882
ts=2022-12-05T17:35:47.712Z caller=tls_config.go:232 level=info msg="Listening on" address=127.0.0.1:9882
ts=2022-12-05T17:35:47.712Z caller=tls_config.go:235 level=info msg="TLS is disabled." http2=false address=127.0.0.1:9882
ts=2022-12-05T17:35:58.307Z caller=handler.go:34 level=debug msg="collect query:" filters="unsupported value type"
ts=2022-12-05T17:35:58.312Z caller=collector.go:135 level=debug msg="collector succeeded" name=network duration_seconds=0.002719641
ts=2022-12-05T17:35:58.323Z caller=collector.go:135 level=debug msg="collector succeeded" name=pod duration_seconds=0.013724029
ts=2022-12-05T17:35:58.349Z caller=collector.go:135 level=debug msg="collector succeeded" name=volume duration_seconds=0.040115157
ts=2022-12-05T17:35:58.363Z caller=collector.go:135 level=debug msg="collector succeeded" name=container duration_seconds=0.053379088
ts=2022-12-05T17:35:58.511Z caller=collector.go:135 level=debug msg="collector succeeded" name=system duration_seconds=0.202251355
ts=2022-12-05T17:35:58.558Z caller=collector.go:135 level=debug msg="collector succeeded" name=image duration_seconds=0.24884938

testing the socket itself seems OK
$ echo -e "GET /containers/json HTTP/1.0\r\n" | podman unshare nc -U ${SOCKET}
HTTP/1.0 200 OK
Api-Version: 1.41
Content-Type: application/json
Libpod-Api-Version: 4.3.1
Server: Libpod/4.3.1 (linux)
X-Reference-Id: 0xc0003c8000
Date: Mon, 05 Dec 2022 18:13:37 GMT

[{"Id":"1ef8fdf2102ba787e29125f3def643e6a4c5da4b22266daccffd2b24423b2549","Names" [...]

Expected behavior
have podman_container_mem_usage_bytes available in metrics exposed by prometheus-podman-exporter
environment

CentOS 9 Stream
Podman Version 4.3.1
exporter run in a podman container: /bin/podman_exporter --collector.enable-all --collector.store_labels --debug --web.listen-address 127.0.0.1:9882

Additional context
Any help in debugging this is welcome

Hi @felixkrohn
I have tried on FC37 the and cannot reproduce the issue (building from main branch).
Will try on CentOS 9 stream and let you know.
[navid@devnode prometheus-podman-exporter]$ ./bin/prometheus-podman-exporter --version
prometheus-podman-exporter (version=1.3.0, branch=main, revision=dev.1)

Example output:
# HELP podman_container_mem_usage_bytes Container memory usage.
# TYPE podman_container_mem_usage_bytes gauge
podman_container_mem_usage_bytes{id="1cddd7e911ef"} 3.01056e+06
podman_container_mem_usage_bytes{id="42907dc71261"} 49152
podman_container_mem_usage_bytes{id="5241480811bd"} 0
podman_container_mem_usage_bytes{id="bd7627e4d928"} 45056
podman_container_mem_usage_bytes{id="c81bdeea85df"} 2.740224e+06

Can u please also attach the output of
curl http://localhost:9882/metrics | grep containers

The container metrics on that server spontaneously reappeared about one week ago without any manual intervention. I have no clue what lead to this, it must have been on a podman auto-update run? Sorry, I really don't know what broke and what fixed it, I'll close this issue.

authors: felixkrohn navidys

repo: containers/prometheus-podman-exporter


text:
check: lint: ineffassign in qemu.go

We were not checking the return err from addDeviceToBridge, which
can validly error out. lint/ineffassign picked this up.
Let's check the error return then...
Fixes: #650
Signed-off-by: Graham whaley graham.whaley@intel.com

lgtm

LGTM

authors: grahamwhaley jodh-intel sboeuf

repo: containers/virtcontainers


text:
Print logfile when test case crash

Because we run bash with -e,  when a test case crash, the parent process will also exit, without print out the logfile.
This is confusing for run a single crash test case since the printed result is same with a successful one.
Like the "mounts/mounts.t"

Codecov Report

Merging #265 (8c86ef8) into main (7f6bc2c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #265   +/-   ##
=======================================
  Coverage   40.89%   40.89%
=======================================
  Files          15       15
  Lines        1445     1445
  Branches      410      410
=======================================
  Hits          591      591
  Misses        649      649
  Partials      205      205

authors: chenyukang codecov-commenter

repo: containers/youki


text:
Problem downloading traefik:v1.5.4 (actual :latest)

docker pull traefik:v1.5.4

v1.5.4: Pulling from library/traefik
no matching manifest for linux/amd64 in the manifest list entries

but
docker pull traefik:v1.5.3

v1.5.3: Pulling from library/traefik
5d3835484afe: Pull complete
0feefa6e9e49: Pull complete
Digest: sha256:d277007b55a8a8d972b1983ef11387d05f719821a2d2e23e8fa06ac5081a302f
Status: Downloaded newer image for traefik:v1.5.3

Build/Docker Build seems to be broken, it happens every now and then unfortunately with not only this repo. From my experience you just have to wait a few for it to go back to normal.
Pro tip: setup a local mirror for docker hub, saves you a lot of pain having images cached locally.

Indeed, the 1.5.4 release has still not been built. We are on it: https://github.com/docker-library/official-images/pull/4129#issuecomment-373621107

It finally works :tada:, closing this one then :)

authors: emilevauge hermanocabral joariasl

repo: containous/traefik-library-image


text:
how to do add header.

What did you expect to see?
I think to kubernetes add header.
I want see.

[root@localhost ~]# curl -I -XGET "http://aaa.com/" -x10.80.95.135:80
> GET http://aaa.com/ HTTP/1.1
> User-Agent: curl/7.29.0
> Host: aaa.com
< HTTP/1.1 200 OK
< X-Script-Name : kubernetes      <---this is i want see.

my traefik.toml

    attempts = "3"
    interval = "15s"
    idleTimeout = "120s"
    defaultEntryPoints = ["http","https"]
    [entryPoints.http]
    address = ":80"
      X-Script-Name = "Kubernetes"
    [entryPoints.https]
    address = ":443"
      [entryPoints.https.tls]
        [[entryPoints.https.tls.certificates]]
        certFile = "/traefik.crt"
        keyFile = "/traefik.key"

my image: traefik:v1.6.6
thanks.

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI tells me this one is neither of them.
I encourage your to seek community support: join our Slack workspace and reach out to us on the #support channel.
Another option is to use Stack Overflow and tag your question traefik.
You can of course double check Traefik's documentation :sweat_smile:

repo: containous/traefik


text:
Question/Proposal for defaultRouter or defaultMiddlewares for Service Discovery Providers

Do you want to request a feature or report a bug?
Feature
Where I see a gap in functionality
I'm trying out Traefik 2.1 now that the Consul Catalog provider has been merged in #5395.
I can pull in Services defined in my Consul Catalog, and the defaultRule template works well to map a named service from a Host header. Easy stuff is easy so far.
What I want to do now is define a set of common Middlewares for thinks like CORS headers, HTTPS redirects, IP whitelist/blacklist. It seems like I can do this inside a Traefik config file with Routers and Middlewares but only for Services that are defined inside the Traefik config file.
I do not want to duplicate my middleware configs into hundreds of services' tags in Docker or Consul, so I think maybe I'm missing something here, but... is it the case that I cannot connect a Middleware defined in a traefik.yml config file to a Service that is created from a Service Discovery mechanism?
What I'd like to see to close the gap
I would like to have something like defaultRouter: [specific router from http section] or defaultMiddlewares: [list of middlewares defined in http section] ala defaultRule that already exists for service discovery providers.
One issue that comes to mind with defaultRouter is how that would mix with defaultRule because each Service needs its own rules, such as a Host header match. Adding defaultMiddlewares first seems like less work for this reason?

Example of what I have in mind:
## traefik.yml

providers:
  consulCatalog:
    endpoint:
      address: http://localhost:8500
    constraints: "Tag(`public`)"
    defaultRule: "Host(`{{ .Name }}.example.com`)"
    defaultRouter: myrouter

http:
  routers:
    myrouter:
      middlewares:
        - usefuldefaults
  middlewares:
    usefuldefaults:
      chain:
        middlewares:
          - cors
          - retries
    retries:
      retry:
       attempts: 4
    cors:
      headers:
        accessControlAllowMethods:
          - GET
          - OPTIONS
          - PUT
        accessControlAllowOrigin: "origin-list-or-null"
        accessControlMaxAge: 100
        addVaryHeader: true
        sslRedirect: true
        customFrameOptionsValue: SAME-ORIGIN

Duplicate of #5630

I don’t quite agree that this is a duplicate of that, and also the hostility on that other ticket made it impossible for me to have discovered what you think is a duplicate in the first place.
Can you explain a) if you plan to implement anything that would resolve the other ticket, and b) if I embark on developing this feature what guidance would you give so I don’t waste time developing something you won’t accept?
Would you accept my proposed defaultRouter or defaultMiddlewares on a provider section if I posted a PR?

Thank you for your proposal.
We will work on that, it's in the v2.2 scope.

The more I think about this, defaultRule could be completely replaced by defaultRouter, since a Router has a rule parameter in it.
I would also suggest that a provider section be able to restrict against accepting label configs from a given provider. There are cases where I need to forcibly set certain baseline requirements that a developer cannot opt-out of when deploying their own service; think of IP address restrictions and mTLS with a CDN provider, for example.

authors: ldez sodabrew


text:
Ordering associations

Would it be possible somehow to order a models children? Maybe something similar to:
Faq.all.order(:name, 'questions.name').load
class Faq < ContentfulModel::Base
  self.content_type_id = 'category'
  has_many :questions
end

or would I have to do it on the array? faq.questions.sort_by(&:name).each

Hey @Frexuz,
Currently the only way of fetching them in a sorted manner is by doing it on the array.
It could be a good idea to add more options in the future for allowing the related resources to be already sorted and maybe add filtering as well.
Currently that involves a lot of work and is a very low priority. But since you are already asking for it, it's definitely worth consideration.
Thanks for the submission
Cheers

I thought so :)

Hey @Frexuz,
Adding sorting and filtering options has been added to our backlog, we'll be tackling this issue in the few months to come.
I'll mark this as closed.
Cheers

authors: Frexuz dlitvakb


text:
💬 Feedback - Please clarify automatic content updates on Netlify

Hey, this template is working really great for me. I deployed my app to Netlify, got great Lighthouse scores, and the content changes I published in Contentful became visible live in minutes.
I have a question regarding this last part, as I do not fully understand how it works. I was expecting that I need to add some webhook that triggers a build on Netlify on a content change in Contentful. However, this seems to be working OOTB using the template.
Can you please tell me how this works and where is it set up? I assume that Netlify hosts static HTML created in the build process and that any content change requires a new build. How did you solve this? Does every content change rebuild the complete project or only the affected pages?
BR,
Daniel

Hi Daniel,
We are thrilled your experience with the template is positive.
Before explaining further the content changes publishing I would like to know if you kept the default template Content Preview configuration (pointing to https://blog.templates.contentful.com) or if you added yours, pointing to your deployed Netlify URL?

Hi Remy,
for now I kept the default settings as I was interested more in the end
user experience.
Best regards,
Daniel Strmečki
On Tue, 23 Jul 2024 at 11:59, Rémy Lenoir @.***> wrote:

Hi Daniel,
We are thrilled your experience with the template is positive.
Before explaining further the content changes publishing I would like to
know if you kept the default template Content Preview
https://www.contentful.com/developers/docs/tutorials/general/content-preview/
configuration (pointing to https://blog.templates.contentful.com) or if
you added yours, pointing to your deployed Netlify URL?
—
Reply to this email directly, view it on GitHub
https://github.com/contentful/template-blog-webapp-nextjs/issues/174#issuecomment-2244775501,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7UTWSRUNN35JOIGQAONI3ZNYSORAVCNFSM6AAAAABLHFWWGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBUG43TKNJQGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi @cf-remylenoir,
I still don't understand how my content changes in Contentful are visible on the Netlify live site within seconds/minutes: https://contenful-strmecki.netlify.app/ without me adding any webhooks or seeing any builds in Netlify?
Can you please explain how did you solve this? I assume there is something OOTB doing the magic here. Does every content change rebuild the complete project or only the affected pages?

Nevermind, I find an answer to my question, I see that the tutorial uses TTL-based invalidation of 60 sec.
BR,
Daniel

repo: contentful/template-blog-webapp-nextjs


text:
Failed supervisord services do not quit the container

When a supervisor program fail too many times, it won't be restarted by supervisord, but supervisor won't fail. Therefore the program is not running but the container orchestrator do not see the container as quitted and therefore can consider it as healthy...
We need to have supervisor failing in such scenario.

This is fixed by #210

and.... merged!

authors: kierenevans sroze

repo: continuouspipe/dockerfiles


text:
fix for netplugin panic while vtep deleteion. fixes #274

(1) removing the duplicate add/delete Peer Host calls.
We were doing a AddPeerHost twice, once for OFNET_AGENT_VLAN_PORT and then for OFNET_AGENT_VXLAN_PORT. Similarly, the DeletePeerHost was also getting done twice.
But the AddPeerHost/DeletePeerHost methods, do not use the port at all. They use only the IP, this was causing a double deletion and hence the panic.
(2) added guarding checks for array length.

LGTM
Thanks for taking care of this..

authors: shaleman vvb

repo: contiv/netplugin


text:
Set option fullscreen or maximized to true will freeze contour

Contour Terminal version
Contour Terminal Emulator 0.3.13-master-59df9d6b
Installer source
Github: source code cloned
Operating System
Windows 11 wsl2 Arch
Architecture
x86-64
Other Software
No response
Steps to reproduce

set fullscreen or maximized to true
open contour, and contour will be unresponsive

Expected Behavior
Open contour correctly with option fullscreen or maximized is true
Actual Behavior
contour will be unresponsive with option fullscreen or maximized is true
Additional notes
No response

I assume that this is windows build, right ?

I assume that this is windows build, right ?

Yes, it build on Windows11, and open with shell command: wsl -d Arch --cd ~

This can be connected with https://github.com/contour-terminal/contour/issues/1093

Now that I put some time into finding this myself, before finding this issue: it still exists :D

Small note: the freeze also happens if you set the windows shortcut to Run: Maximized, instead of trying to set it in contour configs.

authors: Yaraslaut ferdinandyb rhcher

repo: contour-terminal/contour


text:
onChange is not fired

onChange event is not fired. Tested with react 17.0.1

Can you give more specifics - code sample, what browser you're testing in, etc.

Tested with a small component similar to the one in the doc:
import { useMediaQuery } from 'react-responsive'

const Sample = () => {

  const handleMediaQueryChange = (matches) => {
    console.log('matches', matches)
  }

  const isWide = useMediaQuery(
    { minDeviceWidth: 1280 }, undefined,  handleMediaQueryChange
  );

  return (
    <div>
        Screen is wide: {isWide ? '😃' : '😢'}
    </div>
  )
}

export default Sample

I'm seeing that not only the onChange fails. IsWide detection also fails, which always returns 😃
Tested in Windows 10, with react 17.0.1, react-scripts 4.0.0, react-responsive 8.1.0
Browsers: Chrome 86.0.4240.183, Firefox 82.0.2. Same results in both.

I have found the problem. Sorry, my mistake, I was using minDeviceWidth in testing with desktop browsers, when I should be using minWidth.

authors: contra tambaqui

repo: contra/react-responsive


text:
JuMP.jl vs OptimalControl.jl

We should add in the tutorial, a very simple comparison of JuMP.jl and OptimalControl.jl. In terms of modelisation and resolution with the time and using @benchmark.
Which problem(s) do we choose? One or two, not more.

Ce can show some examples with InfiniteOpt.jl and Casadi also.


text:
🛑 CC - BACKOFFICE POC is down

In 5529bb4, CC - BACKOFFICE POC (https://dev.netz-sap.macoapp.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CC - BACKOFFICE POC is back up in 22420b5 after 5 minutes.

repo: conuti-das/status-nbsap


text:
🛑 CC - BACKOFFICE POC is down

In 5bca5fc, CC - BACKOFFICE POC (https://dev.netz-sap.macoapp.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CC - BACKOFFICE POC is back up in cd051fb after 6 minutes.


text:
slog: error logging should be Any to allow err

I'm going to be working (and installing) from this branch to avoid unnecessary releases!

This is fully working! Good to merge / release for prototype.

repo: converged-computing/nfd-source


text:
Pin watchdog to 4.0.2

Watchdog 5.0.0 was recently released. This update causes Werkzeug to reload the Django server much more frequently than desired (causing the local docker development build to barely load).

Description

Checklist:

[x] I've made sure that tests are updated accordingly (especially if adding or updating a template option)
[x] I've updated the documentation or confirm that my change doesn't require any updates

Rationale
Without this change, playing around with the local docker development build consistently fails with ECONNRESET due to page loads triggering inotify events and therefore django server reboots
I've not tried to reproduce this issue on other environments, but this is the case on my M3 Mac.

Would it be worth pinning it in werkzeug instead?

I think this has now been fixed in werkzeug 3.0.5 so I'll remove this pin when I merge the upgrade: https://github.com/pallets/werkzeug/issues/2945

authors: browniebroke novucs

repo: cookiecutter/cookiecutter-django


text:
FLV file not supprting

FLV file not supporting

Is flv supported ?

repo: cookpete/react-player


text:
[Bug] Added support for HTTP source URLs in Git source

Currently only support HTTPS Git source.
I tried HTTP Git source and getting below error.

I solved this issue.
Let me know if you need any other information.

Thanks for the PR!

authors: andrasbacsai f-kawamura

repo: coollabsio/coolify