text:
Upgrading to Beta 6 Issue

I've tried the various methods for upgrading, but always end up with the same outcome.  To be honest i'm not sure if this is an issue, or something with our overrides, but it doesn't make sense that it would be that with my limited SQL.
Debug screen image
Output below:
`Doctrine\DBAL\Exception\InvalidFieldNameException thrown with message "An exception occurred while executing 'select Pages.cID, Pages.pkgID, Pages.siteTreeID, Pages.cPointerID, Pages.cPointerExternalLink, Pages.cIsActive, Pages.cIsSystemPage, Pages.cPointerExternalLinkNewWindow, Pages.cFilename, Pages.ptID, Collections.cDateAdded, Pages.cDisplayOrder, Collections.cDateModified, cInheritPermissionsFromCID, cInheritPermissionsFrom, cOverrideTemplatePermissions, cCheckedOutUID, cIsTemplate, uID, cPath, cParentID, cChildren, cCacheFullPageContent, cCacheFullPageContentOverrideLifetime, cCacheFullPageContentLifetimeCustom from Pages inner join Collections on Pages.cID = Collections.cID left join PagePaths on (Pages.cID = PagePaths.cID and PagePaths.ppIsCanonical = 1) where Pages.cID = ?' with params [1]:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'Pages.siteTreeID' in 'field list'"
Stacktrace:
#28 Doctrine\DBAL\Exception\InvalidFieldNameException in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:71
#27 Doctrine\DBAL\Driver\AbstractMySQLDriver:convertException in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:116
#26 Doctrine\DBAL\DBALException:driverExceptionDuringQuery in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:836
#25 Doctrine\DBAL\Driver\PDOException in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:93
#24 PDOException in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:91
#23 PDOStatement:execute in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:91
#22 Doctrine\DBAL\Driver\PDOStatement:execute in /var/www/html/updates/concrete5-8.0.0b6/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
#21 Doctrine\DBAL\Connection:executeQuery in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Page/Page.php:142
#20 Concrete\Core\Page\Page:populatePage in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Page/Page.php:117
#19 Concrete\Core\Page\Page:getByID in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Entity/Site/Site.php:138
#18 Concrete\Core\Entity\Site\Site:getSiteHomePageObject in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Page/Page.php:388
#17 Concrete\Core\Page\Page:getFromRequest in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Routing/DispatcherRouteCallback.php:40
#16 Concrete\Core\Routing\DispatcherRouteCallback:execute in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/DefaultDispatcher.php:115
#15 Concrete\Core\Http\DefaultDispatcher:handleDispatch in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/DefaultDispatcher.php:53
#14 Concrete\Core\Http\DefaultDispatcher:dispatch in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/DispatcherDelegate.php:39
#13 Concrete\Core\Http\Middleware\DispatcherDelegate:next in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/FrameOptionsMiddleware.php:39
#12 Concrete\Core\Http\Middleware\FrameOptionsMiddleware:process in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/MiddlewareDelegate.php:38
#11 Concrete\Core\Http\Middleware\MiddlewareDelegate:next in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/CookieMiddleware.php:37
#10 Concrete\Core\Http\Middleware\CookieMiddleware:process in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/MiddlewareDelegate.php:38
#9 Concrete\Core\Http\Middleware\MiddlewareDelegate:next in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/ApplicationMiddleware.php:29
#8 Concrete\Core\Http\Middleware\ApplicationMiddleware:process in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/MiddlewareDelegate.php:38
#7 Concrete\Core\Http\Middleware\MiddlewareDelegate:next in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/Middleware/MiddlewareStack.php:86
#6 Concrete\Core\Http\Middleware\MiddlewareStack:process in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Http/DefaultServer.php:85
#5 Concrete\Core\Http\DefaultServer:handleRequest in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Foundation/Runtime/Run/DefaultRunner.php:94
#4 Concrete\Core\Foundation\Runtime\Run\DefaultRunner:run in /var/www/html/updates/concrete5-8.0.0b6/concrete/src/Foundation/Runtime/DefaultRuntime.php:102
#3 Concrete\Core\Foundation\Runtime\DefaultRuntime:run in /var/www/html/updates/concrete5-8.0.0b6/concrete/dispatcher.php:39
#2 require in /var/www/html/concrete/bootstrap/configure.php:49
#1 require in /var/www/html/concrete/dispatcher.php:16
#0 require in /var/www/html/index.php:3
`

I don't know that we're planning to support upgrade from beta at this point, @aembler?

My team have a had a few sessions with @aembler (2xLiams) and the impression was given that the update was possible.
We're developing a site within the beta, how would you recommend upgrading in this case? Fresh install and copy over the overrides?

@tylerhagan When my site gets borked, a lot of the time I can get it working by creating a backup and doing the following:
$ ./concrete/bin/concrete5 orm:schema-tool:update --dump-sql

Then I review the sql and if all looks well I run:
$ ./concrete/bin/concrete5 orm:schema-tool:update --force
$ ./concrete/bin/concrete5 orm:generate-proxies

and that usually does the trick.

Cheers @KorvinSzanto will give it a shot!

@tylerhagan Are you updating from a previous beta, or from 5.7.5.9? Updating from a previous beta will likely not work – but updating from 5.7.5.9 should. You shouldn't have to run any commands to do an update – just copy the concrete directory over the previous one, load the site, and the upgrade happens in the background.

@aembler That'll be the case then, as it's from a previous beta version to the new one. I'll go for a fresh install and migrate the necessary shi*!
Cheers for clearing that up

authors: KorvinSzanto aembler tylerhagan


text:
[Bug] Incorrect handling of URL's by DefaultDispatcher

There is a bug where some URL's are being handled incorrectly by the DefaultDispatcher which is causing non-existent pages to appear as if they exist. Here are the steps to replicate:
Scenario 1
1. Navigate to the following URL
a. {your-path}/a
b. This path will renders a 404 as expected
Scenario 2
1. Enable multilingual
2. Set the home page URL to something different
a. e.g. "/en" for the English site
3. Navigate to the following URL:
a. {your-domain}/enx
4. This path renders the home page while it should render a 404
5. Navigate to the following URL:
a. {your-domain}/enxa
b. This renders a 404 as expected
I have found that this issue is only visibly detectable on the root page when adding 1 character to the end of the URL (as described in scenario 2), however the bug actually affects all URL's because every request is checked against the home page - see line 405 in the ResponseFactory (concrete\src\Http\ResponseFactory.php) to see if there are parameters that match controllers.
Cause
I think this bug is being caused by Line 207 in the PageController (\concrete\src\Page\Controller\PageController.php) file. This function is attempting to extract URL parameters from the current URL and is inadvertently letting an additional character in the URL slip past and be detected as an actual page.
Solution
I am not sure if I have done the right thing here - please review my pull request
https://github.com/concrete5/concrete5/pull/6902

I'm reopening this – merging that pull request broke every path on the site. Couldn't get to the dashboard, couldn't view anything. So something is definitely wrong there.

@aembler I created a new PR fixing the issue: https://github.com/concrete5/concrete5/pull/6910
Sorry for the mess-up here, simple things slip past us. Looking forward to your feedback

source: gharchive/issue

license: mit

license_type: permissive

license_source: bigquery


text:
Images in a private storage location

Currently, getThumbnailURL() returns incorrect URL (see attachment image) if the image is in the private storage location. Let's return /download_file/view_inline/fID URL instead.

We don't have to generate thumbnails if the image is in the private storage location. No one can access to these thumbnails, it's just wasting disk space.

After this pull request merged

@hissy does this also fix the thumbnails in the file manager thumbnail view? or the thumbnails used in the Simple Galalery block? Maybe I'm doing something wrong, but they seem broken there, too:
File manager thumbnail view:

Simple Gallery block:

@wordish This fix will affect images stored in a storage location it has not public URL.

source: gharchive/pull-request

authors: hissy wordish


text:
[v8]Optimize memory usage to handle large number of records on batch processing

Recently, when we ran the index_search job on an 8.5.5 site it got failed due to the consumption of a lot of memory.
It took around 250MB to process about 34000 records.
With this small fix, the peak usage of the memory was only 45MB.
I haven't opened the pull request for v9 as things have been changed a lot there. But if you want I'll check that too.

No, a PR against develop isn't necessary – that's going to be changing significantly in an upcoming PR.

I think this may have unintended consequences. Not all operations can work well when the entity manager is cleared. For example if you try and do this with anything working with attributes unless you disable the cache you'll get errors when you try and clear the entity manager.
I think you ought to move this into the index search job itself instead of in the QueueableJob class.

@aembler
How about now?

We are suffering from minor memory limit issue of update_statistics.php.
@biplobice, we may want to add this implementation to update_statistics.php as well.

Let's close this and implement this in version 9.

authors: aembler biplobice katzueno


text:
[libevent-2.1.10] arcticdb 4.5.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.

We need to port the new specification on rc to this branch.
Do you see how to perform this, @G-D-Petrov? Or shall I do it?

@jjerphan I am not sure you mean exactly, can you please do it?

Done with 832ead4.
@conda-forge-admin, please rerender

authors: G-D-Petrov jjerphan

repo: conda-forge/arcticdb-feedstock

license_source: github-api


text:
add noarch label

Checklist

[x] 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.

Make the package noarch, closes #19

This is the first time I have done this, I followed https://www.anaconda.com/blog/condas-new-noarch-packages

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

noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.
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.

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 used the proposed documentation in this PR conda-forge/conda-forge.github.io#1839 from @jaimergp, thanks!

Happy to merge once green.
Also feel free to add yourself as a maintainer of the package if you want.

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

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.

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 tried without a python version selector, which failed linting. I tried with python >=3.7 but that fails CI

package python-3.7.10-0_73_pypy requires python_abi 3.7 *_pypy37_pp73, but none of the providers can be installed

Is there a way around that?

@conda-forge-admin, please rerender

trying to select for python >=3.8, since conda-forge will be dropping python ==3.7 in after next week's 3.11 release anyway.

@hadim this is green, and will provide no-arch packages for python3.8 and over, meaning now aarch64, ppc64le, and macos arm64 support will be provided but only for python3.8+. The older 1.19.1 platform-specific packages will remain available for python3.7 and under.

Thanks.

authors: conda-forge-linter hadim mattip

repo: conda-forge/blessed-feedstock


text:
Update bw2io req for bw2=2.4.5

@cmutel bw2io pin to 0.8.12 needs to be done here too.

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.

@conda-forge-admin, please rerender


text:
Drop Python 3.7

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.

Due to pyproj 3.3 requiring python 3.8+, we can't proceed with migrations like proj=8.2.1 due to the lack of a python 3.7 build of pyproj.
conda-forge/pyproj-feedstock#115 indicates that dropping python 3.7 builds from cartopy is the path forward 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.

authors: akrherz conda-forge-linter

repo: conda-forge/cartopy-feedstock


text:
[17.x] add missing pin to libcxx-devel; fix libcxx run-export

Backport #315

Unpinning libcxx-devel here actually confuses the solver to the point that it cannot find a valid solution anymore. So I'm leaving the pins as is. We can revisit this if/once we rebuild this branch after moving our clang baseline to 18.

repo: conda-forge/clangdev-feedstock


text:
v0.49.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] 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 wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [38]

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: aymondebroglie conda-forge-linter

repo: conda-forge/ddtrace-feedstock


text:
updated 1.44.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)
[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: aschonfeld conda-forge-linter

repo: conda-forge/dtale-feedstock


text:
Rebuild to support p11-kit

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.

This PR blocks https://github.com/conda-forge/openconnect-feedstock/pull/9.

@conda-forge/p11-kit This is ready. PTAL 🙂

Sorry... Pinged the wrong team... @conda-forge/gnutls this is blocking p11-kit, PTAL 😅

Thanks, @sachalau 🙏

repo: conda-forge/gnutls-feedstock


text:
jupysql v0.10.15 (amend update)

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)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

No valid build backend found for Python recipe for package jupysql 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 almost always follow the syntax in our documentation. For the host section of the recipe, you should almost always use python {{ python_min }}.* for the python entry. You may need to override the python_min variable if the package requires a newer Python version than the currently supported minimum version on conda-forge.
noarch: python recipes should almost always follow the syntax in our documentation. For the run section of the recipe, you should almost always use python >={{ python_min }} for the python entry. You may need to override the python_min variable if the package requires a newer Python version than the currently supported minimum version on conda-forge.
noarch: python recipes should almost always follow the syntax in our documentation. For the test.requires section of the recipe, you should almost always use python ={{ python_min }} for the python entry. You may need to override the python_min variable if the package requires a newer Python version than the currently supported minimum version on conda-forge.

@edublancas ready for your review

@conda-forge-admin please re-lint

@flaviomartins this usually takes about an hour to be live, please test it and let me know if everything works as expected

@flaviomartins this usually takes about an hour to be live, please test it and let me know if everything works as expected

@edublancas Seems to be working just fine.

awesome, thanks!

repo: conda-forge/jupysql-feedstock


text:
debug windows

The Windows package was blank, trying to debug that...

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.

@gillins this is what I get locally on my Windows machine:
[90/92] Linking CXX shared library bin\spatialindex_c-64.dll
BoundsQuery.cc.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
   Creating library bin\spatialindex_c-64.lib and object bin\spatialindex_c-64.exp
Generating code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\datastream.cc(108) : warning C4702: unreachable code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\datastream.cc(110) : warning C4702: unreachable code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\datastream.cc(111) : warning C4702: unreachable code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\sidx_api.cc(194) : warning C4702: unreachable code
Finished generating code
[91/92] Linking CXX executable bin\test-tprtree-Exhaustive.exe
Exhaustive.cc.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
Generating code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\test\tprtree\exhaustive.cc(193) : warning C4702: unreachable code
Finished generating code
[92/92] Linking CXX executable bin\libsidxtest.exe
main.cc.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
Generating code
Finished generating code
[0/1] Install the project...
-- Install configuration: "Release"
CMake Error at src/cmake_install.cmake:36 (file):
  file cannot create directory: C:/Program Files/spatialindex/lib.  Maybe
  need administrative privileges.
Call Stack (most recent call first):
  cmake_install.cmake:37 (include)

I'm re-starting the CIs here to see if we can revive the logs. (I did not know that Azure removed logs 😱)

I guess it was a simple fix due to my oversight in the original PR in the first place. Merging this.

authors: conda-forge-linter ocefpaf

repo: conda-forge/libspatialindex-feedstock


text:
@conda-forge-admin rerender

Additional comment:
No response

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I rerendered the recipe in conda-forge/mattspy-feedstock#20.

authors: beckermr conda-forge-linter

repo: conda-forge/mattspy-feedstock


text:
ENH: Add Linux aarch64, ppc64le and macOS arm64 builds

Enable builds for platforms: linux_aarch64, linux_ppc64le, osx_arm64.
Bump build number.

Checklist

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

authors: conda-forge-admin matthewfeickert


text:
Add migrators

Checklist

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

Hi! This is the friendly conda-forge automerge bot!
I considered the following status checks when analyzing this PR:

linter: passed
azure: failed

Thus the PR was not passing and not merged.

authors: awvwgk conda-forge-admin

repo: conda-forge/multicharge-feedstock


text:
Use clang.exe directly

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter isuruf

repo: conda-forge/normaliz-feedstock


text:
Add @j-wags as a 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 wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

There are 1 too many lines.  There should be one empty line at the end of the file.

@j-wags speak now or forever hold your pizza

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 mattwthompson

repo: conda-forge/openff-evaluator-feedstock


text:
Change package source to github and update dependencies in recipe

Checklist

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

@conda-forge-admin please rerender

This PR changes the source for the package to the github repository, and updates the requirements to match the latest changes in the main repo. I hope that this will now be able to build an up-to-date version of the package 🤞

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:

Recipes should usually depend on matplotlib-base as opposed to matplotlib so that runtime environments do not require large packages like qt.

The primary issue is that py4dstem depends on PyQt =5.13 which is not yet available on Conda-Forge https://github.com/conda-forge/pyqt-feedstock/issues/98

Hey @jan-janssen,
Thanks for the help!
I was able to figure out that the PyQt5 dependency was the main thing that was preventing the build from working, so in the latest release we relaxed that dependency:(https://github.com/py4dstem/py4DSTEM/blob/34086d441350f1663ffae418bd661c6b6e4acbfa/setup.py#L27)
As for tags, the py4DSTEM team (pinging @bsavitzky) has recently resolved to start creating GitHub tags for our releases, so I can change that in the recipe, as soon as we tag this latest version.
I see in the build that was automatically attempted that it was not able to download the origin/main tag, though this did work on my local machine in build_locally.py. Do you think that is related to this or is there another mistake hiding there?

authors: conda-forge-linter jan-janssen sezelt


text:
MNT: Add Jan Boelts as a maintainer

Add @janfb to the maintainers list.

c.f. https://github.com/sbi-dev/pyknos/issues/40

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)

As this is a docs only PR no need to make a new release to Anaconda.org.

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

repo: conda-forge/pyknos-feedstock


text:
pymove version 1.2.0

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

repo: conda-forge/pymove-feedstock


text:
Update meta.yaml

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

@conda-forge-admin, please rerender

authors: conda-forge-linter mdbartos

repo: conda-forge/pysheds-feedstock


text:
python-ligo-lw v1.8.0

Checklist

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

repo: conda-forge/python-ligo-lw-feedstock


text:
[qt6] Rebuild for openssl3

Seems that #70 hasn't really helped the bot. Picking up migrations from main and #63, and exploratorily trying to remove the compiler pins on osx after https://github.com/conda-forge/qt-main-feedstock/commit/f0911622c19cc87e865bc8caad9f2dcf892ea9b5.

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!

I dont know if its related but now conda cannot seem to pick up 6.4.1 and errors with:
conda.CondaMultiError: Error with archive C:\Miniforge\pkgs\qt6-main-6.4.0-he608ae7_3.tar.bz2.
You probably need to delete and re-download or re-create this file.
Message was: failed with error: seeking backwards is not allowed

Maybe the download was corrupted. Perhaps try clearing the cache locally and retrying?

its not locally, but on the CI: for example this one https://github.com/conda-forge/pyside2-feedstock/pull/153

Thanks for the pointer. Hmm...we've had some issues with recent conda, conda-build, and conda-package-handling versions. Maybe this is pointing to an issue in one of them. There are a couple bug fixes lined up for them. Idk if they will fix this issue, but that might be worth testing out once they are published

ok, thanks for the heads up

authors: conda-forge-linter h-vetinari jakirkham jschueller

repo: conda-forge/qt-main-feedstock


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #85.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

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.


text:
Update to 0.4.1

Checklist

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

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 dbast

repo: conda-forge/r-rcppprogress-feedstock


text:
Release v0.4.18

Checklist

[x] 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)
[x] Ensured the license file is being packaged.

@conda-forge-admin please rerender

repo: conda-forge/radioactivedecay-feedstock


text:
Update minimum Python version and add update-grayskull bot

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.

Fixes #12

@conda-forge-admin, please rerender

repo: conda-forge/rdata-feedstock


text:
[ci skip] adding user @conda-forge/sphinx

Hi! This is the friendly automated conda-forge-webservice.
I've added user @conda-forge/sphinx as instructed in #9.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #9

Hi @AA-Turner, happy to see the sphinx team interested in this plugin! Merging now.

authors: Zeitsperre conda-forge-admin


text:
Rebuild for 9.5.0

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.

@conda-forge-admin, please rerender


text:
ENH adding python 2.7

Hi! This is the friendly automated conda-forge-webservice.
I've added python 2.7 as instructed in #3.
Merge this PR to enable Python 2.7.
WARNING: Python 2.7 reached end-of-life on 2020-01-01. conda-forge provides no support for Python 2.7 builds and all existing builds are provided on an "as-is" basis. Python 2.7 builds on the win platform are not possible since we do not build against vs2008 in our CI providers.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

Fixes #3

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

authors: Wentzell conda-forge-linter


text:
uassist update to v0.0.7

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: conda-forge-linter nathanmckinney

repo: conda-forge/uassist-feedstock


text:
Slow solution times on ubuntu-latest

My solution times for both mamba and conda have increased from ~3 minutes to >30 in the past week even though I have not changed the environment file.
Do you know what could be going on?

Fast Solution: logs_973.zip
Slow Solution: logs_1054.zip

It looks like it's not timing out in your environment solving, but before that, when it's trying to install mamba on the bundled Miniconda. I'd give Miniforge a try using this config:
      - uses: conda-incubator/setup-miniconda@v2
        with:
          environment-file: envs/environment-cpu.yml
          activate-environment: test
          auto-activate-base: true
          auto-update-conda: false
          remove-profiles: true
          architecture: x64
          clean-patched-environment-file: true
          run-post: true
          use-mamba: true
          miniforge-version: latest

It includes mamba already, so there's no need to install it.

Nice! That fixed it. Thanks!

authors: WardLT jaimergp

repo: conda-incubator/setup-miniconda

license: MIT


text:
Custom header CorsPolicy [BUG]

As soon as i give an extra custom header the cors policy blocks it eventhough if i devine the policy in prepare like
    CORSPolicy.defaultPolicy.allowedRequestHeaders = ["*"]; or with the names of the headers it keeps on throwing
[INFO] conduit: OPTIONS /auth/token 21ms 403 {user-agent : Mozilla/5.0 (X11; CrOS x86_64 14816.82.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36\nconnection : keep-alive\nsec-fetch-dest : empty\naccept-encoding : gzip, deflate, br\nsec-fetch-site : same-site\nreferer : http://localhost:4200/\naccept : */*\nsec-fetch-mode : cors\naccept-language : nl,en;q=0.9\norigin : http://localhost:4200\nhost : localhost:8888\naccess-control-request-headers : authorization,x-first-password,x-second-password,x-username\naccess-control-request-method : POST\n}

heres my full channel.dart
import 'package:baschack/baschack.dart';
import 'package:baschack/controllers/cards_controller.dart';
import 'package:baschack/controllers/cards_subdomain_controller.dart';
import 'package:baschack/controllers/confirm_controller.dart';
import 'package:baschack/controllers/double_password_controller.dart';
import 'package:baschack/controllers/register_shop_controller.dart';
import 'package:baschack/controllers/register_shopper_controller.dart';
import 'package:baschack/controllers/user_controller.dart';
import 'package:baschack/models/config.dart';
import 'package:baschack/models/user.dart';
import 'package:conduit/managed_auth.dart';
import 'package:mailer/smtp_server.dart';

/// This type initializes an application.
///
/// Override methods in this class to set up routes and initialize services like
/// database connections. See http://conduit.io/docs/http/channel/.
class BaschackChannel extends ApplicationChannel {
  /// Initialize services in this method.
  ///
  /// Implement this method to initialize services, read values from [options]
  /// and any other initialization required before constructing [entryPoint].
  ///
  /// This method is invoked prior to [entryPoint] being accessed.
  ManagedContext? context;
  AuthServer? authServer;
  Config? config;
  SmtpServer? smtp;
  @override
  Future prepare() async {
    logger.onRecord.listen(
        (rec) => print("$rec ${rec.error ?? ""} ${rec.stackTrace ?? ""}"));
    config = Config(options!.configurationFilePath!);
    CORSPolicy.defaultPolicy.allowedOrigins = ["*"];
    CORSPolicy.defaultPolicy.allowedRequestHeaders = ["*"];
    CORSPolicy.defaultPolicy.exposedResponseHeaders = ["*"];
    final dataModel = ManagedDataModel.fromCurrentMirrorSystem();
    final store = PostgreSQLPersistentStore.fromConnectionInfo(
      config!.database!.username,
      config!.database!.password!,
      config!.database!.host,
      config!.database!.port,
      config!.database!.dbName);
    context = ManagedContext(dataModel, store);

    final authStorage = ManagedAuthDelegate<User>(context);
    authServer = AuthServer(authStorage);
    smtp = gmail(config!.smtp!.username!, config!.smtp!.password!);
  }

  /// Construct the request channel.
  ///
  /// Return an instance of some [Controller] that will be the initial receiver
  /// of all [Request]s.
  ///
  /// This method is invoked after [prepare].
  @override
  Controller get entryPoint {
    final router = Router();

    // Prefer to use `link` instead of `linkFunction`.
    // See: https://conduit.io/docs/http/request_controller/
    router.route("/example").linkFunction((request) async {
      return Response.ok({"key": "value"});
    });
    router.route('/register-shop').link(() => RegisterShopController(context!, authServer!, config!, smtp!));
    router.route('/register-shopper').link(() => RegisterShopperController(context!, config!, smtp!, authServer!));
    router.route('/confirm/:confirmation').link(() => ConfirmController(context!));
    router.route('/auth/token').link(() => DoublePasswordController(context!, authServer!))!.link(() => AuthController(authServer!));
    router.route('/user').link(() => Authorizer.bearer(authServer!))!.link(() => UserController(context!));
    router.route('/cards').link(() => Authorizer.bearer(authServer!))!.link(() => CardsController(context!));
    router.route('/cards-subdomain/:subdomain').link(() => CardsSubdomainController(context!));
    return router;
  }
}

and the doublepassword controller
import 'package:baschack/models/user.dart';
import 'package:conduit/conduit.dart';
class DoublePasswordController extends Controller {
  final ManagedContext context;
  final AuthServer authServer;
  DoublePasswordController(this.context, this.authServer);

  @override
  Future<RequestOrResponse> handle(Request request) async {
    final userQuery = Query<User>(context)..where((u) => u.username).equalTo(request.raw.headers.value('username')!);
    final user = await userQuery.fetchOne();
    if (user!.firstPassword == authServer.hashPassword(request.raw.headers.value('first-password')!, user.salt!) && (user.lock == null || user.lock!.isAfter(DateTime.now()))) {
      if (user.hashedPassword == authServer.hashPassword(request.raw.headers.value('second-password')!, user.salt!)) {
        return request;
      } else {
        final timelockUserQuery = Query<User>(context)..where((i) => i.id).equalTo(user.id)..values.lock = DateTime.now().add(const Duration(hours: 1));
        await timelockUserQuery.updateOne();
      }
    }
    return Response.badRequest(body: {
      "error": "invalid credentials or account is still locked for one hour"
    });
  }
}

I had to append with addAll to the list of accepted headers instead of using =

repo: conduit-dart/conduit


text:
Fix/fix copy metrics

PR to address issue

Hey @vjsliogeris just had the time to test everything so took a bit longer. I think its good to merge, thank you so much! Also come join our discord, would love working together: https://discord.com/invite/a3K9c8GRGt

@penguine-ip Will do! Currently I'm using this library quite a lot so I'm getting intimate with the code.

authors: penguine-ip vjsliogeris

repo: confident-ai/deepeval


text:
config: Revert "config: Remove kata-qemu-se"

This reverts commit bfba38f90a1cfe35de6053e6cebf1ec0d8ee2b1f. This will fix a test failure at http://jenkins.katacontainers.io/job/confidential-containers-operator-main-ubuntu-20.04-s390x-SE-daily/
Fixes: #300
Signed-off-by: Hyounggyu Choi Hyounggyu.Choi@ibm.com

@BbolroC - I think you might want to revert https://github.com/confidential-containers/operator/commit/63fa8b02e386188bf3cbe78af41c8bdf57e1a8f2 too?

@BbolroC - I think you might want to revert 63fa8b0 too?

Oh, yes. I missed it. Thanks for pointing it out.

/test

@BbolroC - DCO sign-off failing on the 2nd commit

/test

I am working on fixing the CI failure on s390x.

@stevenhorsman  It looks the check tests-e2e-ubuntu-20.04-x86_64-containerd_kata-clh has been never fetched by Jenkins. I've checked the corresponding job http://jenkins.katacontainers.io/view/all/job/confidential-containers-operator-main-ubuntu-20.04-x86_64-containerd_kata-clh-PR/ was disabled yesterday. Why don't we take it out of the list?

authors: BbolroC stevenhorsman

repo: confidential-containers/operator


text:
Where to report Security Bug of Confluent

Hey team,
I have found a security bug in one the code of confluent. Can we have talk regarding it ?

@anchitj

repo: confluentinc/confluent-kafka-dotnet


text:
Fix/KFS-1609 multibyte chars

I fixed the util functions that we use and will create a ticket to fix the other ones. More details in the ticket.

LGTM since all my comments resolved themselves in the next commit. Personally, seems overkill to add Godash (Lodash for Go, get it? Why the heck did they not use that name?!) for the one remaining usage (afaict), though.

Coming from the frontend world, I totally agree that loading a lib like loadash only for a one func is totally using a sledgehammer to crack a nut.
However, the beauty in go is that unused stuff from a package will be dropped by the linker and won't clutter the binary, so a library like this makes much more sense in go.
Also, I think at least in all repos I worked in our team we informally try to use this (quite nice) lib when we can to reduce the bloat from go.

repo: confluentinc/go-prompt


text:
MINOR: Bump version to 5.4.3

This is a version bump for CCS Kafka now that 5.4.2 is released. I will merge this over to ce-kafka after approval here.

Hmm, don't we also have to change instances of 2.4.2 to 2.4.3 as part of this?

Hmm, don't we also have to change instances of 2.4.2 to 2.4.3 as part of this?

Looking here:
https://kafka.apache.org/downloads
I do not see 2.4.2, so a bump to 2.4.3 isn't coming, 2.4.2 would be the "next" one, which this codebase is already at. Any comments @sdanduConf ?

Ah I see, so previously, we moved from 5.4.1 to 5.4.2 at the same time as AK moved from 2.4.1 to 2.4.2, whereas right now we're moving to 5.4.3 without a corresponding bump for AK. Makes sense, approved.

authors: agam andrewegel

repo: confluentinc/kafka


text:
Ability to customize the thread pool and size of request queue.

This is new PR for customizing the thread pool and size of request queue. This PR is from old PR https://github.com/confluentinc/rest-utils/pull/150. It is too much work for merging the PR 150 due to code had dramatic changes since supporting one Jetty Server instance can contain multiple Applications.

@confluentinc It looks like @jeffhuang26 just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

@jeffhuang26 Changes looks good to me.
BTW, What is the motivation for this PR? Have we seen any issues related no. of threads/requests?

This request is based on issue reported by SEC-592:
https://confluentinc.atlassian.net/browse/SEC-592
By default, when Jetty is booted it has:
a worker thread pool of 8 threads that scales to a max of 200 threads
an unbounded Queue to store requests, if all worker threads are busy
This means that, if for some reason the MDS got stuck in a bad state, it could eat all the memory on the Kafka broker it is hosted on by storing all the incoming requests in memory.
Given that we are going to let clients write scripts against MDS, we should make it so that
A) we can configure the thread pool size Jetty uses
B) we can limit the size of the request queue.

repo: confluentinc/rest-utils


text:
When ActionBar is set to auto hide hitting paste icon is impossible

As sayed in #285
I can hit it when not set to auto hide.

Are you using an emulator? This never seems to happen on a real device for me, but I am seeing it occasionally on an emulator.

@alescdb, please verify that #293 fixes this issue.

authors: alescdb rhansby

repo: connectbot/connectbot


text:
Translate ctrl plus @ into ctrl-@

Fix issue #515

Changes Unknown when pulling 74101331a53cde4f6312cf47c48e49df8350c6b1 on natebragg:fix_515 into ** on connectbot:master**.

authors: coveralls natebragg


text:
Simulating mining dispute & using merkle roots for peer validation

Hey Conrado, great improvement from the original naivecoin project, follows smoothly. I had a few questions for my own fork and was hoping you or some other clever guy could help me out.
I was wondering how could I simulate a mining dispute, where 2 or more miners are each trying to validate a block. Is there a mechanism for a miner to stop the mining if another miner broadcasts a valid block? If both miners find a block at almost the same time, is there a mechanism for forking and later on consolidating the chain? If not, how do you think a possible adaption would go on?
Still on peer info validation, how would a merkle root validation process best fit inside the existing codebase? I know how the merkle tree and root construction goes on, but I'm still a bit confused as to what code should be removed and substituted with the merkle steps

Hey!

I was wondering how could I simulate a mining dispute, where 2 or more miners are each trying to validate a block. Is there a mechanism for a miner to stop the mining if another miner broadcasts a valid block? If both miners find a block at almost the same time, is there a mechanism for forking and later on consolidating the chain? If not, how do you think a possible adaption would go on?

I think it's just a matter of implementing that. In this project, the mining is happening in another thread. So the mining thread should check from time to time if its blockchain has received a new block, if it is, it should recreate the block to be mine and then restart all over.

Still on peer info validation, how would a merkle root validation process best fit inside the existing codebase? I know how the merkle tree and root construction goes on, but I'm still a bit confused as to what code should be removed and substituted with the merkle steps

To be honest, I need to study more about the merkle root validation to even try to think about how to implement it.
Without further studying, probably this is something related to the indexing of the blockchain database. So if I'm not wrong (and it's very likely I am) there is no modification in the node, operator and http server side. Just in how to access and get blocks from the blockchain.
Best

Thanks for the fast reply :)
I'll try implementing a successful mining dispute, clear winners and losers.
From what I got from the resources below, the merkle root would be used by participating nodes with no means of checking each and every transaction's signature and structure in a block so that it could be trusted. Instead of looping through every transaction, the node would recreate the block's merkle tree and root, comparing the "expected root" with the "actual root". That leads to O(log(n)) verifications for the node to do, instead of O(n). Makes sense?
merkle roots in js - pt1 Calculating the merkle root
merke roots in js - pt2 Using the merkle root
why does each block store a merkle root?
what is the merkle root?

authors: conradoqg eaverdeja

repo: conradoqg/naivecoin


text:
CI pipelinine to autobuild for various OS & Archs

linux-x86_x64, linux-arm64, linux-arm32, windows-amd64, windows-amd32, macos-intel64, macos-AppleSilicon

@jbeyerstedt can you double check, if the workflow file is correct ?

@jbeyerstedt can you double check, if the workflow file is correct ?

I did try it out with a PR, "vx.x.x" Tag and push on main branch. Seems to work fine. Im not sure if the filenaming is "correct"

@jbeyerstedt dont merge yet. There are sone issues it seems like

@jbeyerstedt Okay now its ready to be merged

Borked windows build in between because it's the only one with .exe file names.

authors: OemerYilmazConsiderIT jbeyerstedt

repo: consider-it/mqtt-record-replay


text:
🛑 mazemod.org is down

In 93c635e, mazemod.org (https://mazemod.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: mazemod.org is back up in 7f2f2bc after 13 minutes.

repo: constructions-incongrues/status


text:
🛑 lesetoilesflottantes.resterdigne.net is down

In c9c90db, lesetoilesflottantes.resterdigne.net (https://lesetoilesflottantes.resterdigne.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: lesetoilesflottantes.resterdigne.net is back up in 0aae0c8 after 3 hours, 1 minute.


text:
🛑 data.musiques-incongrues.net is down

In eddea81, data.musiques-incongrues.net (https://data.musiques-incongrues.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: data.musiques-incongrues.net is back up in 7991dc9 after 7 hours, 44 minutes.


text:
🛑 Da ! Heard It Records - home is down

In 5573f91, Da ! Heard It Records - home (https://daheardit-records.net/fr/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Da ! Heard It Records - home is back up in 6fbd51e after 17 minutes.


text:
🛑 zeitgeist.musiques-incongrues.net is down

In c653a10, zeitgeist.musiques-incongrues.net (https://zeitgeist.musiques-incongrues.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: zeitgeist.musiques-incongrues.net is back up in c74f57d.


text:
Installer should honor current settings during update

Description of the new feature/enhancement
When updating the installer defaults to enable run at system startup but I have this turned off. I have to deselect this every time I update. If I would have chosen not to add the start menu item I would also need to deselect this option every time I update.
Proposed technical implementation details (optional)
Read current configuration during update.

Solved in PR #57 release v.1.1.1

authors: markrexwinkel rouke-broersma

repo: container-desktop/container-desktop


text:
test: add bats test suite to utility files

Adds test for the current util files:

[x] util.sh
[x] environment.sh
[x] filesystem.sh
[x] linking.sh

Not sure why it replaces the versions in the yarn.lock. If you know how to fix this, let me know.
I added bats with yarn add --dev <url>

@viceice We broke the shell_wrapper function with our shellcheck changes: https://github.com/containerbase/buildpack/pull/258/files#diff-01d7a5c53bd60ed4d24d3a6a36b3450bdcab4927ba6a9b487e83811ee87f4ae1R90
I should be able to fix it once I am refactoring the utils files.

Should be ready for review. I left a bit of code in it that I will enable once we have testable methods.

@viceice Is there a way to rerun the checks or do I need to push a bogus commit?

@viceice Is there a way to rerun the checks or do I need to push a bogus commit?

Retrigger seems to be hung, yesterday, so now done again. 🤔

authors: Chumper viceice

repo: containerbase/buildpack


text:
adopters: remove eliot.run

Eliot appears to be defunct and the domain is for sale.

@samuelkarp There is a reference of Eliot in https://github.com/containerd/containerd/blame/main/ADOPTERS.md#L35, Should that also be removed?. Its not a broken link since it points to the github repo of the project.

@akhilerm Last update of that repo looks to be 5 years ago (2018), so yeah I'd probably remove it.

Will raise a PR to remove it.

authors: akhilerm samuelkarp


text:
Move shim API into linux sub pkg

This moves the shim into the linux/shim pkg so that its API is kept with the implementation.  The shim is an implementation detail of the linux runtime, they should be kept together.
This also refactors some of the shim loading and how it is killed to help make it more robust.
Based on #1057

Codecov Report

Merging #1077 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1077   +/-   ##
=======================================
  Coverage   54.51%   54.51%
=======================================
  Files          16       16
  Lines        1229     1229
=======================================
  Hits          670      670
  Misses        386      386
  Partials      173      173

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 6ad3ba7...260ad5c. Read the comment docs.

@stevvooe updated

LGTM

authors: codecov-io crosbymichael stevvooe

repo: containerd/containerd


text:
vendor: update BurntSushi/toml for MIT license

Follow-up to #2088
v0.3.0 still contains "WTFPL"
https://github.com/BurntSushi/toml/commits/master
Signed-off-by: Akihiro Suda suda.akihiro@lab.ntt.co.jp

Codecov Report

Merging #2090 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2090   +/-   ##
=======================================
  Coverage   45.37%   45.37%
=======================================
  Files          96       96
  Lines        9447     9447
=======================================
  Hits         4287     4287
  Misses       4449     4449
  Partials      711      711

Flag
Coverage Δ

#linux
50.28% <ø> (ø)
:arrow_up:

#windows
40.29% <ø> (ø)
: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 44f6bc4...36a2deb. Read the comment docs.

@stevvooe
Should we cherrypick this to release/1.0?

LGTM

Should we cherrypick this to release/1.0?

Please!

authors: AkihiroSuda codecov-io stevvooe


text:
[testing] use smaller filesize on 4KB pagesize systems

Uses a much smaller value when creating this file to be used
as a loopback device on non-ppc64le platforms.
This file has to be so large on ppc64le, because mkfs.btrfs
uses the default architecture pagesize as blocksize, which is 64KB
on ppc64le, but only 4KB on amd64 and s390x.
Signed-off-by: Christopher Jones tophj@linux.vnet.ibm.com

Codecov Report

Merging #2132 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2132   +/-   ##
=======================================
  Coverage   45.53%   45.53%
=======================================
  Files          80       80
  Lines        8726     8726
=======================================
  Hits         3973     3973
  Misses       4107     4107
  Partials      646      646

Flag
Coverage Δ

#linux
50.24% <ø> (ø)
:arrow_up:

#windows
41.09% <ø> (ø)
: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 002caba...6f4285d. Read the comment docs.

minor nit: given it's not implicitly clear why the linkage between page size and temp filesystem mount, a comment might be useful for someone else coming across this code

LGTM

authors: codecov-io crosbymichael estesp tophj-ibm


text:
ParseSignal: drop add'l check for numeric signals

The kernel will return an error anyway.

There was an associated test :)
--- FAIL: TestParseSignal (0.00s)
    --- FAIL: TestParseSignal/65536/0/true (0.00s)
        signals_test.go:40: ParseSignal(65536) should return error

Whoops, forgot to fix that. Fixed now.

authors: estesp kolyshkin


text:
Executing nerdctl run in k8 environment is stuck

Description
Executing nerdctl run in the k8 environment is stuck, but k8s can create pods normally
Steps to reproduce the issue
1.[root@m1 ~]# nerdctl ps
CONTAINER ID    IMAGE                                                                                COMMAND                   CREATED           STATUS    PORTS    NAMES
f0571a9094ce    quay.io/cilium/hubble-ui-backend@sha256:0e0eed917653441fded4e7cdb096b7be6a3bddded5a2dd10812a27b1fc6ed95b    "/usr/bin/backend"        6 minutes ago     Up                 k8s://kube-cilium/hubble-ui-77555d5dcf-pj77v/backend
046ba04231f7    docker.io/wangyanglinux/myapp:v1                                                                            "nginx -g daemon off;"    6 minutes ago     Up                 k8s://default/test-z2gms/test
5c6c52541c37    docker.io/wzxmtlw/metrics-server:v0.6.3                                                                     "/metrics-server --c…"    6 minutes ago     Up                 k8s://kube-system/metrics-server-5c7b6df7d8-md58r/metrics-server
fcb24a33d77a    quay.io/cilium/hubble-relay@sha256:d352d3860707e8d734a0b185ff69e30b3ffd630a7ec06ba6a4402bed64b4456c         "hubble-relay serve"      7 minutes ago     Up                 k8s://kube-cilium/hubble-relay-7bc7544857-95dqm/hubble-relay
....
2.[root@m1 ~]# nerdctl run --name test --rm -it busybox:1.28 /bin/sh
Executing the above command gets stuck
3.Can nerdctl run be executed outside the k8s environment
Describe the results you received and expected
null
What version of nerdctl are you using?
[root@m1 ~]# nerdctl version
Client:
Version:	v2.0.2
OS/Arch:	linux/amd64
Git commit:	1220ce7ec2701d485a9b1beeea63dae3da134fb5
buildctl:
Version:	v0.17.1
GitCommit:	8b1b83ef4947c03062cdcdb40c69989d8fe3fd04
Server:
containerd:
Version:	v2.0.1
GitCommit:	88aa2f531d6c2922003cc7929e51daf1c14caa0a
runc:
Version:	1.2.2
GitCommit:	v1.2.2-0-g7cb36325
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
[root@m1 ~]# nerdctl info
Client:
Namespace:	k8s.io
Debug Mode:	false
Server:
Server Version: v2.0.1
Storage Driver: overlayfs
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Log:     fluentd journald json-file none syslog
Storage: native overlayfs
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version:   5.14.0-427.13.1.el9_4.x86_64
Operating System: Rocky Linux 9.4 (Blue Onyx)
OSType:           linux
Architecture:     x86_64
CPUs:             4
Total Memory:     3.793GiB
Name:             m1
ID:               b26f2865-ca8a-49fa-a3a2-ec66adae9813

[root@m1 ~]# kubectl version
Client Version: v1.31.4
Kustomize Version: v5.4.2
Server Version: v1.31.4

@wzxmt I am not sure how to reproduce your problem.
Against a kind cluster, things are working just fine / as expected.
I need more details about your specific deployment.

How can I reproduce it from scratch?
How did you create your kube cluster exactly?
What else is involved here?
What are your containerd details?
output of nerdctl info?
re-run the failing/stuck nerdctl command with --debug-full

@wzxmt I am not sure how to reproduce your problem.
Against a kind cluster, things are working just fine / as expected.
I need more details about your specific deployment.

How can I reproduce it from scratch?
How did you create your kube cluster exactly?
What else is involved here?
What are your containerd details?
re-run the failing/stuck nerdctl command with --debug-full

My K8s deployment method uses binary deployment, and I tried again. Running "nerdctl run --name test --rm -it busybox:1.28 /bin/sh" in Flannel mode works without any stutter, but it stutters in Cilium mode. Here are the deployment modes:
linux-amd64/helm template cilium cilium/cilium --version 1.15.11
--namespace kube-cilium
--set operator.replicas=1
--set k8sServiceHost=apiserver.cluster.local
--set k8sServicePort=8443
--set ipv4NativeRoutingCIDR=172.16.0.0/16
--set ipam.operator.clusterPoolIPv4PodCIDRList=172.16.0.0/16
--set hubble.relay.enabled=true
--set hubble.ui.enabled=true
--set hubble.ui.service.type=NodePort
--set hubble.ui.service.nodePort=31235
--set routing-mode=native
--set kubeProxyReplacement=strict
--set bpf.masquerade=true
--set bandwidthManager.enabled=true >>${HOST_PATH}/roles/components/templates/cilium.yaml
[root@m1 ~]# containerd -v
containerd github.com/containerd/containerd/v2 v2.0.1 88aa2f531d6c2922003cc7929e51daf1c14caa0a
[root@m1 ~]# nerdctl info
Client:
Namespace:	k8s.io
Debug Mode:	false
Server:
Server Version: v2.0.1
Storage Driver: overlayfs
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Log:     fluentd journald json-file none syslog
Storage: native overlayfs
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version:   5.14.0-427.13.1.el9_4.x86_64
Operating System: Rocky Linux 9.4 (Blue Onyx)
OSType:           linux
Architecture:     x86_64
CPUs:             6
Total Memory:     5.755GiB
Name:             m1
ID:               97bb3274-41ea-4a43-a74b-7dc0b86e3fa9
[root@m1 ~]# nerdctl run --name test --rm -it --debug-full busybox:1.28 /bin/sh
DEBU[0000] verifying process skipped
DEBU[0000] generated log driver: binary:///apps/containerd/bin/nerdctl?_NERDCTL_INTERNAL_LOGGING=%2Fvar%2Flib%2Fnerdctl%2F1935db59

Thanks @wzxmt
What happens with nerdctl network ls, or when starting your container with different container options? (eg: --net host)
@AkihiroSuda anyone around familiar with Kube + eBPF/Cillium who could help debug this?

nerdctl network ls

I later tried the Calico mode and it worked fine. Running "nerdctl network ls" in Cilium mode still stutters, but other modes can be executed normally.
flannel
[root@m2 ~]# nerdctl network ls
NETWORK ID      NAME      FILE
cbr0      /etc/cni/net.d/10-flannel.conflist
17f29b073143    bridge    /etc/cni/net.d/nerdctl-bridge.conflist
host
none
calico
[root@m3 ~]# nerdctl network ls
NETWORK ID      NAME               FILE
k8s-pod-network    /etc/cni/net.d/10-calico.conflist
17f29b073143    bridge             /etc/cni/net.d/nerdctl-bridge.conflist
host
none
Cilium stutters
[root@m1 ~]# nerdctl network ls

nerdctl network ls

I later tried the Calico mode and it worked fine. Running "nerdctl network ls" in Cilium mode still stutters, but other modes can be executed normally.

Interesting.
Staying stuck is rather unusual.
What I am thinking is locking on the same directory.
Been browsing Cilium source code, and indeed they do use filesystem locking, possibly on the same directory as us.
@wzxmt if you feel like it, the most helpful thing you could do is:
# clone nerdctl source code
git clone git@github.com:containerd/nerdctl.git
cd nerdctl

# Edit https://github.com/containerd/nerdctl/blob/main/pkg/netutil/netutil.go#L224
# Line 224, find this:
#	err = lockutil.WithDirLock(e.NetconfPath, fn)
# Replace it with:
#      fn()

# Compile a new nerdctl binary
make binaries

# The updated binary is under `_output`

# Now, try again
_output/nerdctl network ls

If it still does not help, you could pepper fmt.Println("debug message something") in this function (and the caller) to figure out where it is getting stuck.
I wish I could test Cilium but I am short on time right now.
Thanks @wzxmt

nerdctl network ls

I later tried the Calico mode and it worked fine. Running "nerdctl network ls" in Cilium mode still stutters, but other modes can be executed normally.

Interesting.
Staying stuck is rather unusual. What I am thinking is locking on the same directory. Been browsing Cilium source code, and indeed they do use filesystem locking, possibly on the same directory as us.
@wzxmt if you feel like it, the most helpful thing you could do is:
clone nerdctl source code
git clone git@github.com:containerd/nerdctl.git
cd nerdctl
Edit https://github.com/containerd/nerdctl/blob/main/pkg/netutil/netutil.go#L224
Line 224, find this:
err = lockutil.WithDirLock(e.NetconfPath, fn)
Replace it with:
fn()
Compile a new nerdctl binary
make binaries
The updated binary is under _output
Now, try again
_output/nerdctl network ls
If it still does not help, you could pepper fmt.Println("debug message something") in this function (and the caller) to figure out where it is getting stuck.
I wish I could test Cilium but I am short on time right now.
Thanks @wzxmt

Edit https://github.com/containerd/nerdctl/blob/main/pkg/netutil/netutil.go#L224，make binaries
You can execute nerdctl network ls, and execute nerdctl run --name test --rm -it --debug-full busybox:1.28 /bin/sh but there is still a problem

Thanks a lot @wzxmt
I think this confirms what the issue is: cilium is very likely trying to lock the same directory as nerdctl (likely the cni configuration directory).
The problem here will not be trivial to solve.
We need to flock when accessing the cni conf - this is the only way to prevent racy/concurrent modifications.
What we could do is move the lock to a different location though (purely nerdctl).
cc @AkihiroSuda

authors: apostasie wzxmt

repo: containerd/nerdctl


text:
[fix] filter images panic

nerdctl images --filter before=not-exist-image will panic.
Fix: #3467

CI failures notes:

the windows failure is #3437
the docker failure is my fault, and will get fixed in #3464

Tagging @djdongjin @AkihiroSuda for maintainers review.

authors: apostasie xyz-li


text:
status: Use prepare_for_write instead of require_root

This prevents /sysroot from switching to being
persistently mounted as rw.

I'm a bit confused since the link for "
Integration Test / integration (x86_64, rhel-9-5) (pull_request_target) Failing after 49m " to testing farm takes me to something for Fedora 40?

Ah, at least it looks like the integration tests are incorrectly testing for this behavior:
TASK [assert] ******************************************************************
fatal: [guest]: FAILED! => changed=false
  assertion: result_sysroot_mount_status.stdout == "rw"
  evaluated_to: false
  msg: /sysroot is not mounted with rw permission

Not sure why the install tests suddenly started falling over with ENOSPC...trying to debug

authors: cgwalters ckyrouac

repo: containers/bootc


text:
how to enable traffic from pod to another pod's port?

/kind feature
Description
I need a bit guidance. I don't get traffic from one pod to another on the same host. How to enable pod to pod traffic within podman?
Steps to reproduce the issue:

I start pod for mqtt, it listens to 1883/tcp:

sudo podman run --name mosquitto \
  --rm -p "9001:9001" -p "1883:1883" \
  -v "/var/lib/containers/exported_volumes/mosquitto-config/mosquitto.conf:/mosquitto/config/mosquitto.conf:Z" \
 -v "/var/lib/containers/exported_volumes/mosquitto-data:/mosquitto/data:Z" \
 -v "/var/lib/containers/exported_volumes/mosquitto-log:/mosquitto/log:Z" \
  --conmon-pidfile  /%t/%n-pid --cidfile /%t/%n-cid \
  eclipse-mosquitto:latest

I start another pod as mqtt client for sending traffic to mqtt broker:

podman run \
   -it \
   -v /home/redhatter/data:/app/data:Z \
   --device=/dev/ttyACM0 \
   -e TZ=Europe/Helsinki \
   -v /run/udev:/run/udev:ro \
   --privileged=true \
   --name z2m
   koenkk/zigbee2mqtt

Describe the results you received:
I've tried both setting the bridge ip for mqtt client and also the host public ip. In either case I don't get connection:
zigbee2mqtt:info  2020-02-24 20:50:42: Connecting to MQTT server at mqtt://192.168.1.5
zigbee2mqtt:error 2020-02-24 20:51:22: Not connected to MQTT server!

I also tried allowing internal traffic for public ip:
firewall-cmd --permanent --zone=public --add-rich-rule=' rule family="ipv4" source address="10.88.0.0/16" port protocol="tcp" accept'

here are the relevant network device settings:
    link/ether 00:0d:b9:4b:31:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.5/24 brd 192.168.1.255 scope global dynamic noprefixroute enp1s0
       valid_lft 84409sec preferred_lft 84409sec
    inet6 fe80::e7bd:5bae:a01e:bfa4/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
5: cni-podman0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d2:20:02:52:ca:ac brd ff:ff:ff:ff:ff:ff
    inet 10.88.0.1/16 brd 10.88.255.255 scope global cni-podman0
       valid_lft forever preferred_lft forever
    inet6 fe80::d020:2ff:fe52:caac/64 scope link
       valid_lft forever preferred_lft forever
9: vethfb218ddb@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni-podman0 state UP group default
    link/ether 2e:e3:bc:ce:91:0c brd ff:ff:ff:ff:ff:ff link-netns cni-041d8968-3756-8188-e622-96223e850187
    inet6 fe80::2ce3:bcff:fece:910c/64 scope link
       valid_lft forever preferred_lft forever

I also got instructed at #podman@freenode to drop the firewall section, and add default gw to bridge config:
{
    "cniVersion": "0.4.0",
    "name": "podman",
    "plugins": [
        {
            "type": "bridge",
            "bridge": "cni-podman0",
            "isGateway": true,
            "isDefaultGateway": true,
            "ipMasq": true,
            "ipam": {
                "type": "host-local",
                "routes": [
                    {
                        "dst": "0.0.0.0/0"
                    }
                ],
                "ranges": [
                    [
                        {
                            "subnet": "10.88.0.0/16",
                            "gateway": "10.88.0.1"
                        }
                    ]
                ]
            }
        },
        {
            "type": "portmap",
            "capabilities": {
                "portMappings": true
            }
        }
    ]
}

Describe the results you expected:
MQTT client to connect to MQTT broker
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version:            1.6.4
RemoteAPI Version:  1
Go Version:         go1.12.12
OS/Arch:            linux/amd64

Output of podman info --debug:
debug:                                                                                [7/335]
  compiler: gc
  git commit: ""
  go version: go1.12.12
  podman version: 1.6.4
host:
  BuildahVersion: 1.12.0-dev
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.6-1.module+el8.1.1+5259+bcdd613a.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.6, commit: 6ffbb2ec70dbe5ba56e4bfde946fb04f19dd8bbf'
  Distribution:
    distribution: '"rhel"'
    version: "8.1"
  MemFree: 2986414080
  MemTotal: 3945947136
  OCIRuntime:
    name: runc
    package: runc-1.0.0-64.rc9.module+el8.1.1+5259+bcdd613a.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 1073737728
  SwapTotal: 1073737728
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: apu.konttikoulu.fi
  kernel: 4.18.0-147.5.1.el8_1.x86_64
  os: linux
  rootless: false
  uptime: 37m 27.94s
registries:
  blocked: null
  insecure: null
  search:
  - registry.access.redhat.com
  - registry.fedoraproject.org
  - registry.centos.org
  - docker.io
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 2
  GraphDriverName: overlay
  GraphOptions: {}
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 4
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):
podman-1.6.4-2.module+el8.1.1+5363+bf8ff1af.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
physical rhel8.1

The request here seems to be to access another pod via ports forwarded to the host with PortMap (that is, hit another pod via the host's IP and a forwarded port).
@mccv1r0 PTAL

On Fedora 30 (my laptop) a quick test for me works fine.  I can connect to the port specified via -p using either the IP address assigned to the LOM device which gets dhcp address from corp network as well as the podman0 Linux bridge.
What is your iptables FORWARD policy?  Actually, to save a few round trips, what are your iptables rules for filter and nat tables?
The value of these sysctl variables will be helpful too:
net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-ip6tables
net.bridge.bridge-nf-call-iptables

Make sure br_netfilter module is loaded as well

@ikke-t : if possible can you try to insert a rule into firewalld FORWARD chain at the beginning:
sudo iptables -I FORWARD -s 10.88.0.0/16 -j ACCEPT
If the last rule is a REJECT that matches everything, setting the default policy to ACCEPT isn't going to help.

Thanks a lot guys, now it works!
The magic there was that by default, RHEL doesn't load the br_netfilter. Also, one needs to put the bridge ip or host public ip instead of localhost.
I believe localhost is the 127.0.0.1 in the pod net namespace, instead the host one. I also removed the above mentioned trial of adding firewalld rich rule for bridge ip range, it is not needed once br_netfilter is loaded.
So all in all, perhaps podman should load br_netfilter to make sure the firewall rules work?
While debugging, I went throught the firewall rules, and otherwise they looked fine. I didn't have the default reject there.

I propose you add br_netfilter loading to podman rpm. As otherwise people will fail a lot with this. I fixed it like this on my system:
echo br_netfilter > /etc/modules-load.d/podman.conf

Seems like a packaging issue as opposed to an upstream issue.
@lsm5 WDYT?

@lsm5 Reping

@lsm5 Reping

I'll add this..

added to rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=42876942

Can you add it to F32 as well?

Can you add it to F32 as well?

yup, will do

Can you add it to F32 as well?

https://koji.fedoraproject.org/koji/taskinfo?taskID=42891689

I believe this is fixed in the package now.

repo: containers/libpod


text:
cmd/podman/pull: refactor code

Refactor and simplify the code in cmd/podman/pull.go to address a couple
of issues w.r.t. how the arguments were passed.  Also make sure to
always use the c/image API for parsing instead of working around it.
Signed-off-by: Valentin Rothberg rothberg@redhat.com

LGTM

LGTM

/lgtm

authors: mheon rhatdan vrothberg


text:
Update nix to 0.27.*

ref : https://github.com/containers/youki/pull/2312
Nix has released a breaking version, and we need to do some corresponding code changes and verify that nothing is breaking.

/assign

Hi, I'm also working on resolving this issue. #2369.
Feel free to offer suggestions.

@anti-entropy123 please comment on the issue before you make the PRs especially if it is assigned to someone else already ... :slightly_smiling_face:
@lengrongfu are you also working on this? Is it fine if I re-assign this?

Of course, please redistribute it @YJDoc2 .thank you for your contribution @anti-entropy123 .

this is closed via #2369
Thanks @anti-entropy123 !

repo: containers/youki


text:
Ingress Status is not updated

Do you want to request a feature or report a bug?

Bug

What did you do?
Step # 1
Installed Traefik with helm:
helm install traefik traefik/traefik -n ctct-system \
    --set kubernetes.ingressEndpoint.useDefaultPublishedService=true \
    --set rbac.enabled=true \
    --set logLevel=DEBUG \
    --set accessLogs.enabled=true \
    --set dashboard.enabled=true

Step # 2
Annotate Traefik service
kubectl annotate service traefik  -n ctct-system "external-dns.alpha.kubernetes.io/hostname=example.com"

This creates an A record and TXT record in AWS Route53 for example.com
Step # 3
Deploy an app. Showing ingress configuration:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hello-app
  labels:
    app: hello-app
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: panda.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: hello-app
          servicePort: 80

What did you expect to see?
Treafik should be updating the status field in Ingress object.
What did you see instead?
Status field in ingress object remains empty.
status:
  loadBalancer: {}

Output of traefik version: (What version of Traefik are you using?)
Version:  2.2.1
Codename: chevrotin
Go version: go1.14.2
Built:  2020-04-29T18:02:09Z
OS/Arch:  linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
Following is configuration for Traefik Pod.
spec:
   containers:
   - args:
     - --global.checknewversion
     - --global.sendanonymoususage
     - --entryPoints.traefik.address=:9000/tcp
     - --entryPoints.web.address=:8000/tcp
     - --entryPoints.websecure.address=:8443/tcp
     - --api.dashboard=true
     - --ping=true
     - --providers.kubernetescrd
     - --providers.kubernetesingress

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
traefik time="2020-06-25T17:03:03Z" level=error msg="Cannot create service: subset not found" serviceName=hello-app namespace=default providerName=kubernetes servicePort=80 ingress=hello-app  │

Hello @tahirali-endurance,
thanks for your interest in the project. Could you please also provide us with the Deployment manifest?
Thanks

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2020-06-26T21:10:13Z"
  generation: 1
  labels:
    app.kubernetes.io/instance: traefik
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: traefik
    helm.sh/chart: traefik-8.7.0
  name: traefik
  namespace: ctct-system
  resourceVersion: "281857"
  selfLink: /apis/apps/v1/namespaces/ctct-system/deployments/traefik
  uid: b70fa8cc-b6c1-4706-a76b-020133ab8098
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/instance: traefik
      app.kubernetes.io/name: traefik
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app.kubernetes.io/instance: traefik
        app.kubernetes.io/managed-by: Helm
        app.kubernetes.io/name: traefik
        helm.sh/chart: traefik-8.7.0
    spec:
      containers:
      - args:
        - --global.checknewversion
        - --global.sendanonymoususage
        - --entryPoints.traefik.address=:9000/tcp
        - --entryPoints.web.address=:8000/tcp
        - --entryPoints.websecure.address=:8443/tcp
        - --api.dashboard=true
        - --ping=true
        - --providers.kubernetescrd
        - --providers.kubernetesingress
        image: traefik:2.2.1
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /ping
            port: 9000
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        name: traefik
        ports:
        - containerPort: 9000
          name: traefik
          protocol: TCP
        - containerPort: 8000
          name: web
          protocol: TCP
        - containerPort: 8443
          name: websecure
          protocol: TCP
        readinessProbe:
          failureThreshold: 1
          httpGet:
            path: /ping
            port: 9000
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        resources: {}
        securityContext:
          capabilities:
            drop:
            - ALL
          readOnlyRootFilesystem: true
          runAsGroup: 65532
          runAsNonRoot: true
          runAsUser: 65532
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /data
          name: data
        - mountPath: /tmp
          name: tmp
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        fsGroup: 65532
      serviceAccount: traefik
      serviceAccountName: traefik
      terminationGracePeriodSeconds: 60
      volumes:
      - emptyDir: {}
        name: data
      - emptyDir: {}
        name: tmp
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2020-06-26T21:10:13Z"
    lastUpdateTime: "2020-06-26T21:10:13Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2020-06-26T21:10:13Z"
    lastUpdateTime: "2020-06-26T21:10:29Z"
    message: ReplicaSet "traefik-5f44464f86" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

Can you check namespaces for your application, your ingress and your service? It appears that you might have the app in ctct-system but the ingress in the default namespace.
If everything lines up, could you please also post your service manifest.

Updated the entire app configuration. The question had copying issue in configuration.  All objects including deployments, service and ingress are in same namespace(ctct-system).

Hello @tahirali-endurance,
thanks for all those information.
After taking a closer look, I can see that you mixed up 2things. You're helm installation from above, uses some settings (e.g. * kubernetes.ingressEndpoint.useDefaultPublishedService* which are currently only available on the Traefik Version 1.X helm chart.
This is not supported with V2 and thus, setting it in the helm installation does not have an effect.
What you can do, is append on your Traefik Deployment Manifest
      - args:
        - --global.checknewversion
        - --global.sendanonymoususage
        - --entryPoints.traefik.address=:9000/tcp
        - --entryPoints.web.address=:8000/tcp
        - --entryPoints.websecure.address=:8443/tcp
        - --api.dashboard=true
        - --ping=true
        - --providers.kubernetescrd
        - --providers.kubernetesingress
        - --providers.kubernetesingress.ingressendpoint.publishedservice= ctct-system/traefik

guessing, that your Traefik service is also named Traefik.
As this is a question in regards to configuration and not a bug, I'll close that issue. If you have more configuration issues, do not hesitate to head over to the community forum https://community.containo.us/c/traefik/traefik-v2/10 and share your issues there.

I changed the configuration based on above suggestion:
helm install traefik traefik/traefik -n ctct-system \
    --set kubernetes.ingressEndpoint.ingressendpoint.publishedservice="ctct-system/traefik" \
    --set rbac.enabled=true \
    --set logLevel=DEBUG \
    --set accessLogs.enabled=true \
    --set dashboard.enabled=true

But still the load balancer status of ingress object is not changed.

Never mind, I did it using additional properties. It would be nice, if that property can be set directly without additional arguments.
helm install traefik traefik/traefik -n ctct-system \
    --set="additionalArguments={--providers.kubernetesingress.ingressendpoint.publishedservice=ctct-system/traefik}" \
    --set rbac.enabled=true \
    --set logLevel=DEBUG \
    --set accessLogs.enabled=true \
    --set dashboard.enabled=true

authors: AndrewSav SantoDE tahirali-endurance

repo: containous/traefik


text:
Merge v1.2.1 master

This PR merges v1.2.1 back into master.
There is an issue, commits from Add v1.2 codename to Merge pull request #1204 from containous/prepare-release-v1.2.0-rc2 should not be in this PR. Those are already in master thanks to https://github.com/containous/traefik/pull/1208. It seems that the problem comes from PR https://github.com/containous/traefik/pull/1208 where there is no merge commit and commit hashes are different :thinking:
So,
1. either I leave it like this (with some duplicates in the history)
2. either I can rebase interactively and drop commits from Add v1.2 codename to Merge pull request #1204 from containous/prepare-release-v1.2.0-rc2. The history will look better, but I fear that the next merge will end to the same issue :'(
WDYT @containous/traefik ?
Finally, what I did:

on branch v1.2,  git rev-list --no-merges --reverse 9b24e13..fba3db5 > /tmp/rebase: list all commits without merge commits

On branch merge-v1.2.1-master (from master), cat /tmp/rebase | git cherry-pick --stdin

This is pretty much impossible to review due to the sheer number of lines changed. I suggest we merge and deal with any potential problems in master.
If I remember our agreement correctly, we are going to do cherry-picking from release branches into master in the future. In that case, it's okay to not try to "save the merge" here and go with the cherry-picking solution already (which will presumably make future merges of the release branch into master harder, but we won't have to do that again).

@containous/traefik your review is required to merge :)

OMG it's green, I can finally merge this PR!

410 files changed?

We all love vendoring ;)

authors: emilevauge timoreimann


text:
Extract some code in packages

Reviving #1006 👼

This will help split stuff in smaller, better tested packages
This moves some stuff like the traefik command to package cmd

It's build on top of #1444, so only the 2nd commit should be reviewed 👼
🦁

I think you'll need to adjust the Makefile targets and script/ helpers since the build target changed from root to cmd.
Docs in .github/CONTRIBUTING.md likely need a small update too.

Hmm, given that the build ran for quite a while (even though erroneously), my comment might be false. Maybe you can double check.

@timoreimann yep, I need to update docs, just want to make sure these changes are ok for @emilevauge and everybody before doing it 👼

@vdemeester Looks very good to me ( love the new server package :heart_eyes: )

Updated with the docs 👼

authors: emilevauge timoreimann vdemeester


text:
Refs 3372: Drop all snapshots in stage

Summary
Deletes all snapshots in stage, so we can migrate to a new pulp server.  Will be merged after snapshotting is disabled in stage.  The repos & versions will remain in the pulp server, but we will eventually just drop the pulp server.  The rpms will remain in the s3 bucket, but we will switch to a new bucket and delete the old one.
Testing steps
Create a repo with snapshotting, let it snapshot, see a snapshot is created.
run: go run cmd/cleanup_versions/main.go  --force
snapshot should no longer exist.
Checklist

[ ] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

DO NOT MERGE until snapshotting is disabled in stage

https://issues.redhat.com/browse/HMS-3372


text:
Adds missing meta data to Entry, Asset and ContentType responses

This will add missing meta information back into the resolved responses:
Assets
import Contentful.Query
alias Contentful.Asset
alias Contentful.Delivery.Assets

{:ok, asset} = Assets |> fetch_one("my_asset_id")

"my_asset_id" = asset.id
"<a timestamp for updated_at>" = asset.sys.updated_at
"<a timestamp for created_at>" = asset.sys.created_at
"<a locale string>" = asset.sys.locale

Entries
import Contentful.Query
alias Contentful.{ContentType, Entry, SysData}
alias Contentful.Delivery.Entries

{:ok, entry} = Entries |> fetch_one("my_entry_id")

"my_entry_id" = entry.id
"<a timestamp for updated_at>" = entry.sys.updated_at
"<a timestamp for created_at>" = entry.sys.created_at
"<a locale string>" = entry.sys.locale
%ContentType{id: "the_associated_content_type_id"} =  entry.sys.content_type

ContentTypes
import Contentful.Query
alias Contentful.ContentType
alias Contentful.Delivery.ContentTypes

{:ok, content_type} = ContentTypes |> fetch_one("my_content_type_id")

"my_content_type_id" = content_type.id
"<a timestamp for updated_at>" = content_type.sys.updated_at
"<a timestamp for created_at>" = content_type.sys.created_at

Why is the id not part of sys?
Because I am lazy and the id is most likely just important enough to warrant being access by entity.id instead of entity.sys.id. I am open to feedback here :wink:
Shoutout to @OldhamMade for bringing this to my attention in #44.
fixes #44.

Pull Request Test Coverage Report for Build 61f49c93bd0388eb2e80d45e2f94811343db4f12-PR-45

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 67.568%

Totals

Change from base Build a6abd60cc5669f1709058a46396f4a84fbb52dfc:
0.0%

Covered Lines:
75

Relevant Lines:
111

💛  - Coveralls

Why is the id not part of sys?

When I was working on a similar (more hobby) project/SDK for another language I also struggled with the sys property. In the end I think it is fine to not have structural equality between API presentation and language environment, the only important thing is that the necessary information there. Esp. for the CDA, which is a read-only API, we can flatten or strip presentational structure if it makes handling the data more convenient, since we don't really need to keep it for updates (a CMA concern).
tl;dr: I'm totally fine with structural changes for a "one-way" API.

Ultimately, there probably will be a CMA integration with this library - that's when the question of sys.id or id will probably pop up again, but it should be easy to serialize/deserialize this on the fly.
Don't quote me years from now please.

Pull Request Test Coverage Report for Build d7bc398c5630db514f89bd8833632e6d3b0b1e74-PR-45
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 67.568%

Totals

Change from base Build a6abd60cc5669f1709058a46396f4a84fbb52dfc:
0.0%

Covered Lines:
75

Relevant Lines:
111

💛  - Coveralls

authors: asaaki coveralls floriank


text:
create-contentful-app command fails to build bootstrap

Hello, I've encountered something odd: I cannot get a new Contentful app bootstrap to build.
Steps to reproduce

npx @contentful/create-contentful-app init my-first-app
give permission for npx to continue

Expected behavior
create-contentful-app to build a bootstrapped directory called 'my-first-app'
Actual behavior
Build fails with the following warning:
You are running `create-react-app` 4.0.3, which is behind the latest release (5.0.0).

We no longer support global installation of Create React App.

Please remove any global installs with one of the following commands:
- npm uninstall -g create-react-app
- yarn global remove create-react-app

The latest instructions for creating a new app can be found here:
https://create-react-app.dev/docs/getting-started/

The suggested fix does not work because I do not have create-react-app installed globally.
Following the instructions from the provided link, running npx create-react-app my-app works just fine.
Versions
node: 16.13.1
npm: 8.1.2
macOS: 12.1
Please let me know, if there is any other information that is needed. Thank you.

Hello @dmbdesignpdx and thanks for reaching out!
We have managed to reproduce the issue and we're currently working on fixing it. Me or one of my colleagues will update this thread as soon as we are ready with a fix.
Thanks again and apologies for the inconvenience

I believe this issue is now fixed. Please let us know if you have any further problems @dmbdesignpdx

authors: Jwhiles dmbdesignpdx shikaan

repo: contentful/create-contentful-app


text:
Der Inhalt des Messen-Reiters ist nicht sichtbar

Fixed in https://github.com/conterra/mapapps-sketching-enhanced/commit/6bae99cc35fdbf5071f506317faac72361541638

authors: marcwilkes matthiasstein

repo: conterra/mapapps-sketching-enhanced


text:
Automatically call "to tabs" after accepting diff depending on detected indentation of file

Validations

[X] I believe this is a way to improve. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that requests the same enhancement

Problem
Indentation type does not match user selection, which is a problem in python.
Solution
Process the AI generated code to replace indentation with the detected indentation of the file (provided by the IDE)

"to tabs" being the Jetbrains action

This is on our radar, thanks for the +1 here!

authors: Patrick-Erichsen oxysoft

repo: continuedev/continue


text:
fix: fix 100% indexing progress

Description
This pull request fixes below issues:

Indexing progress should be 1, not 100.
100% progress log is missing.

Checklist

[x] The base branch of this PR is dev, rather than main
[x] The relevant docs, if any, have been updated or created

Screenshots
[ For visual changes, include screenshots. ]
Testing
[ For new or modified features, provide step-by-step testing instructions to validate the intended behavior of the change. ]

Good catch! Based on this logic in gui/src/components/loaders/IndexingProgressBar.tsx this seems like the correct choice.
  const fillPercentage = Math.min(
    100,
    Math.max(0, indexingState.progress * 100),
  );```

authors: Patrick-Erichsen shigma


text:
default deny is not required in namespace in v1.

Signed-off-by: Ranjith rchirakk@users.noreply.github.com

build PR

LGTM

repo: contiv/netplugin