text:
Hitting delete in empty gene box removes last gene

@GarabetY found this bug. Steps to reproduce:

Prod
Add spleen
Click into gene drop down, select the first three genes
Click in empty gene box
Hit delete on your keyboard
The last gene you selected is removed from the dot plot

Desired solution: Nothing should happen in this case.

High probability of SDS bug

Just confirmed that this is SDS thing! Will double check if it's a feature or a bug lol

Just asked SDS support channel for verification if the behavior is a feature or a bug!
https://czi-sci.slack.com/archives/C032S43KKFV/p1678296205703739?thread_ts=1678296154.403999&cid=C032S43KKFV

Masoud from SDS will take a look at this today!

I'm going to reach out to Masoud about this today.

The fix will come in the next version of SDS, not sure if we have any blockers preventing a version bump, but I'll investigate this when the update is released.

Sure, here it is.
https://user-images.githubusercontent.com/70176538/228310336-10e663d7-eba1-4e93-a38b-05e7ac3cfac1.mov

ohhhhhhhhhhhhhh okay I was hitting Delete instead of Backspace
Thank you!! I'll look into it

SDS has fixed the bug, so hopefully updating czifui on our repo will fix the bug on our end! Thanks for doing this, @ashin-czi 🙏

hmmmm upgraded to czifui v14.4.1 but still seeing the bug, but I know it's updated cause some things look slightly different. It seems fixed on my local story book though

Ah, I think the fix wasn't applied to MenuSelect since I could still repro it on:
https://chanzuckerberg.github.io/sci-components/?path=/story/menuselect-to-be-depreciated--multi-select-with-search
The lowest effort way is just to apply to same fix to MenuSelect, release it, and then we upgrade again
I actually tried using Dropdown when I was doing the migration to MUIv5, but ran into some styling issue. Maybe it's worth a quick try again to see if that's still the case. If it's still hard to upgrade, let's just go with the lowest effort way above

@signechambers1 @karenliang0 @hthomas-czi @tihuan
rdev: https://gene-select-delete-frontend.rdev.single-cell.czi.technology/gene-expression
I updated czifui to v14.4.1
There are some noticeable visual changes, specifically the left sidebar filters. Just wanted to make sure if everyone was okay with this and to see if there were other cases where components look different and need to be altered!

Ooh amazing! Thanks for migrating to Dropdown 🤩 👏 !
Left is new, right is old:

I agree - the header (filters) as well as the filter dropdowns themselves are blending together. Also there's a lot more spacing between each filter dropdown which I don't think is needed? Will look into this today!

@hthomas-czi @karenliang0 Any updates on this? Did we want to go with another SDS style?

PR out to fix SDS MenuSelect!
https://github.com/chanzuckerberg/sci-components/pull/413
Once this is merged and released, I'll ping @ashin-czi to use the latest czifui and we can go back to use MenuSelect for a little longer
Thanks all!

I think SDS is releasing today! Will keep you posted, @ashin-czi 👍
CC: @cathystoli

Good news! v14.5.0 is just released with the fix ✨ MenuSelect should no longer have the bug
@ashin-czi please kindly try upgrading czifui and hopefully it'll just work lol
https://chanzuckerberg.github.io/sci-components/?path=/story/menuselect-to-be-depreciated--multi-select-with-search
Thank you!

Amazing! This looks great. Thank you so much!
All the best,
Garabet
On Thu, Apr 20, 2023 at 3:58 PM Timmy Huang @.***>
wrote:

Closed #4156
https://github.com/chanzuckerberg/single-cell-data-portal/issues/4156
as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/chanzuckerberg/single-cell-data-portal/issues/4156#event-9061062986,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4LJXKXT2FPAIWBXFTGFLSTXCGIPXANCNFSM6AAAAAAUUQBHXI
.
You are receiving this because you were mentioned.Message ID:
<chanzuckerberg/single-cell-data-portal/issue/4156/issue_event/9061062986@
github.com>

authors: GarabetY ashin-czi karenliang0 seve signechambers1 tihuan


text:
bug( ): Data Portal UI Displays Dataset Version ID as title instead of Dataset ID when an empty dataset is initialized by Curation API

Describe the bug
bug( ): Data Portal UI Displays Dataset Version ID as title instead of Dataset ID when an empty dataset is initialized by Curation API
To Reproduce
Steps to reproduce the behavior:

Create Empty Dataset via Curation API in a Private Collection
Check Collection in Data Portal UI, and look at list of Datasets

Expected behavior
Dataset Name Column should display Dataset ID, not Dataset Version ID when initialized and empty
Environment
N/A

Triaging with @metakuni - closing since this is not a significant fit and finish issue with the curators. CC: @jahilton .

source: gharchive/issue

authors: brianraymor nayib-jose-gloria

repo: chanzuckerberg/single-cell-data-portal

license: MIT

license_type: permissive

license_source: github-api


text:
error running detect_spots

The gather step of munge.py is giving a ValueError: setting an array element with a sequence.
The error arises during the pd.melt in the function below. Haven't tried to chase down further, wanted to flag it.
def gather(df, key, value, cols):
    id_vars = [col for col in df.columns if col not in cols]
    id_values = cols
    var_name = key
    value_name = value
    return pd.melt(df, id_vars, id_values, var_name, value_name)

what versions of pandas and python are you on? can you report the stack trace? i have't seen this error come up on anyone else's machine yet.

tracked it down, must have been the pandas version, will close!

authors: dganguli freeman-lab

repo: chanzuckerberg/starfish


text:
add config validate and adjustment for server mode

Users need to specify all configs when injecting failure with server mode.
For example, below is a command for network attack:
$ curl -X POST "127.0.0.1:31767/api/attack/network" -H "Content-Type: application/json" -d '{"device": "eth0", "ipaddress": "172.16.4.4", "action": "duplicate", "percent": "50", "correlation": "0"}'

The correlation is 0, but we can not ignore it, otherwise, it will get an error:
curl -X POST "127.0.0.1:31767/api/attack/network" -H "Content-Type: application/json" -d '{"device": "eth0", "ipaddress": "172.16.4.4", "action": "duplicate", "percent": "50"}'
{"error":true,"message":"error.api.internal_server_error: strconv.ParseFloat: parsing \"\": invalid syntax","code":"error.api.internal_server_error","full_text":"error.api.internal_server_error: strconv.ParseFloat: parsing \"\": invalid syntax\n at github.com/chaos-mesh/chaosd/pkg/server/httpserver.(*httpServer).createNetworkAttack()\n\t/home/xiang/chaosd/pkg/server/httpserver/server.go:131\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/context.go:161\n at github.com/chaos-mesh/chaosd/pkg/server/utils.MWHandleErrors.func1()\n\t/home/xiang/chaosd/pkg/server/utils/error.go:46\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/context.go:161\n at github.com/gin-gonic/gin.RecoveryWithWriter.func1()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/recovery.go:83\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/context.go:161\n at github.com/gin-gonic/gin.LoggerWithConfig.func1()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/logger.go:241\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/context.go:161\n at github.com/gin-gonic/gin.(*Engine).handleHTTPRequest()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/gin.go:409\n at github.com/gin-gonic/gin.(*Engine).ServeHTTP()\n\t/home/xiang/go/pkg/mod/github.com/gin-gonic/gin@v1.6.3/gin.go:367\n at net/http.serverHandler.ServeHTTP()\n\t/usr/local/go/src/net/http/server.go:2887\n at net/http.(*conn).serve()\n\t/usr/local/go/src/net/http/server.go:1952\n at runtime.goexit()\n\t/usr/local/go/src/runtime/asm_amd64.s:1371"}

So we should add adjustments for some config, set default values for them when they are not specified, and add validations for them, just like the command mode https://github.com/chaos-mesh/chaosd/blob/0ace2adfe883b50cd1b60c8c44f148eeb2cb2632/pkg/core/network_command.go#L51 https://github.com/chaos-mesh/chaosd/blob/0ace2adfe883b50cd1b60c8c44f148eeb2cb2632/cmd/chaosd/ctl/command/network_command.go#L54

close via #76

repo: chaos-mesh/chaosd


text:
Show usage with -h/--help is passed

--help currently claims to print usage but doesn't

Hah! Thanks!

source: gharchive/pull-request

authors: chaoticbob iburinoc

repo: chaoticbob/SPIRV-Reflect


text:
promoting tool citation

I wonder if there's a way that bcbio can promote citing the tools used in an analysis. I think it's easy to omit a tool like peddy that a project will (hopefully) use (hopefully) once, and then move on. I know I am guilty of omissions of this sort. Since, to some degree, citations are the currency that keep me (and a lot of us) employed, it would be nice to facilitate that in bcbio. e.g. in a pipeline that uses GATK, samtools, indexcov, multiqc, picard, bcbio could output a citation file with dois and citations in some format. Likewise if it annotates with VEP, ensembl or gnomad
I put this issue here not because bcbio is an offender, but because it's a centralized place to facilitate this. Thoughts?

For what it's worth, I agree. Make looking up the author and benchmarking data user in the publication easier as well. Could also contain they link to the repo, if available. Had to be maintained by someone, though ;)

Brent and Sven-Eric;
Thanks for starting this discussion, it would be great to make it easier for folks using bcbio to give academic credit for code and tools used in workflows.
From a representation side, I'd propose including the citation information as part of bioconda packages. There is in progress work to provide links to biotools (https://github.com/bioconda/bioconda-recipes/pull/6294) which we could then use to query publications (https://bio.tools/bedtools) and try to generate an output report from a bcbio run. This could expand the version file we currently provide with richer metadata. This way we're not maintaining these in bcbio but as part of a larger project.
Data is harder because our installs are not as structured. We're using ggd recipes which have unstructured comments in the headers for provenance. I've still been waiting to support a bioconda-like data project if anyone gets one started.
Definitely happy to hear other approaches. Thanks again for the discussion.

Don't know if it's maintained, but I recall the SciCrunch DB in that context.

which we could then use to query publications (https://bio.tools/bedtools) and try to generate an output report from a bcbio run.

That would be extremely useful. When writing methods for papers it is not unusual that I miss one citation or two given the plethora of tools that are used.

The citation list is updated as a first approximation. Everybody is welcome to contribute and make it better!

https://bcbio-nextgen.readthedocs.io/en/latest/contents/citations.html
https://github.com/bcbio/bcbio-nextgen/blob/master/docs/contents/citations.md

authors: brentp chapmanb lbeltrame naumenko-sa schelhorn

repo: chapmanb/bcbio-nextgen

license: mit

license_source: bigquery


text:
Updating Next.js entity types should clear caches using relevant cache tags

At the moment, updating Next.js entity types is not clearing any caches when configuration is updated. This means that if any of the entity pages are cached, the cached version of the page is still served even if the rendering of the entity should change based on the Next.js entity types configuration.
Steps for reproducing

Enable dynamic page caching
Generate new node using any content type and visit the node page
Visit /admin/config/services/next/entity-types and configure the entity type to be rendered using Next.js
Visit the node page again and confirm that the page is still rendered by Drupal
Clear all caches
Confirm that now the page is rendered using the Next.js preview

Bug confirmed. Adding this to the current work I'm doing on preview (where we fixed a bug with the router cache rebuild: #217)
Thanks @lauriii

I've moved this to the 1.3.0 release since the work done in #217 might take a while and be probably added in the 2.0.0 release.

The fix here would be something like the following, correct?
Override \Drupal\Core\Config\Entity\ConfigEntityBase::invalidateTagsOnSave in \Drupal\next\Entity\NextEntityTypeConfig. Get the entity view builder for the target entity type and merge in \Drupal\Core\Entity\EntityViewBuilder::getCacheTags to the invalidated tags.
[$entity_type_id, ] = explode('.', $this->id(), 2);

authors: lauriii mglaman shadcn

repo: chapter-three/next-drupal


text:
After importing fonts and adding them to the library, an error occurred when saving as SVG images

COM object that has been separated from its underlying RCW cannot be used.
   at System.Runtime.InteropServices.McgMarshal.GetInterface(__ComObject, RuntimeTypeHandle) + 0xfe
   at __Interop.ComCallHelpers.Call(__ComObject, RuntimeTypeHandle, Int32, Void*) + 0x3a
   at __Interop.ForwardComStubs.Stub_3[TThis, TResult](__ComObject, Int32) + 0x37
   at CharacterMap.Views.FontMapView.<FontMapView_Loaded>b__30_0(Object, AppNotificationMessage) + 0x20
   at CharacterMap!<BaseAddress>+0x436e8e
   at Microsoft.Toolkit.Mvvm.Messaging.WeakReferenceMessenger.Send[TMessage, TToken](TMessage, TToken) + 0x29d
   at Microsoft.Toolkit.Mvvm.Messaging.IMessengerExtensions.Send[TMessage](IMessenger, TMessage) + 0x3f
   at CharacterMap.ViewModels.FontMapViewModel.<SaveSvgAsync>d__169.MoveNext() + 0x29f
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0x70
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x38
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task) + 0x17
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult() + 0xb
   at CharacterMap.ViewModels.FontMapViewModel.<<-ctor>b__148_1>d.MoveNext() + 0x8c
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__7_0(Object) + 0x1e
   at System.Action`1.Invoke(T) + 0x28
   at System.Threading.WinRTSynchronizationContext.Invoker.InvokeCore() + 0x33

OS Version: 10.0.17763.316
OS Architecture: X64
App Version: 2021.3.0.0
App Culture: zh-CN

After restarting the application, it returns to normal.

repo: character-map-uwp/Character-Map-UWP


text:
Replace deprecated CordovaWebView.sendJavascript with alternate method

The CordovaWebView.sendJavascript method is deprecated, and using it in pre KitKat devices with the latest Cordova 5.1 version throws an error during plugin initialization. The error is not observable in Lollipop and newer devices, and never happened when using previous Cordova versions (3.7).

Thanks for this pull request. I'm closing #323 fixes the same problem.

authors: don homer-jay

repo: chariotsolutions/phonegap-nfc


text:
TOML parse error: Invalid table header: Duplicate key version

Run ruff . with this pyproject.toml in an empty directory:
# pyproject.toml

[tool.hatch]
version.source = "vcs"

[tool.hatch.version.raw-options]
local_scheme = "no-local-version"

Outputs error only without --isolated in newest 0.0.222:
$ ruff --version
ruff 0.0.222
$  ruff .
error TOML parse error at line 6, column 1
  |
6 | [tool.hatch.version.raw-options]
  | ^
Invalid table header
Duplicate key `version`

$ ruff . --isolated
warning: No Python files found under the given path(s)

This file is parsed fine by other tools, such as Hatchling, python-build, Black, isort etc. Fuller version at https://github.com/hugovk/norwegianblue/
Error both with and without --isolated in 0.0.219:
$ ruff --version
ruff 0.0.219
$ ruff .
error TOML parse error at line 6, column 1
  |
6 | [tool.hatch.version.raw-options]
  | ^
Invalid table header
Duplicate key `version`

$ ruff . --isolated
error TOML parse error at line 6, column 1
  |
6 | [tool.hatch.version.raw-options]
  | ^
Invalid table header
Duplicate key `version`

Error only without --isolated in 0.0.220:
$ ruff --version
ruff 0.0.220
$ ruff .
error TOML parse error at line 6, column 1
  |
6 | [tool.hatch.version.raw-options]
  | ^
Invalid table header
Duplicate key `version`

$ ruff . --isolated
warning: No Python files found under the given path(s)

Looks like both toml and toml_edit fail to parse the toml content, see https://www.rustexplorer.com/b/vthrz3
$ ./playground
Err(
    Error {
        inner: ErrorInner {
            kind: Custom,
            line: Some(
                5,
            ),
            col: 0,
            at: Some(
                55,
            ),
            message: "duplicate key: `version`",
            key: [
                "tool",
                "hatch",
            ],
        },
    },
)
Err(
    TomlError {
        message: "TOML parse error at line 6, column 1\n  |\n6 | [tool.hatch.version.raw-options]\n  | ^\nInvalid table header\nDuplicate key `version`\n",
        line_col: Some(
            (
                5,
                0,
            ),
        ),
    },
)

I'm not familiar with the Rust release process, will this be closed when https://github.com/toml-rs/toml/issues/439 is available in Ruff, so I can just watch this issue? :)

Yeah it should be! I'll try upgrading. It looks like they just cut a release.

Looks like #2040 should close this out.

Sorry, a little confusion with respect to the toml crate -- the upgrade I performed did solve this problem, but it had the potential to introduce some other incompatibilities with TOML 1. So I want to revert for now, just to minimize churn. I expect this to be closed out soon-ish, but we do need a new release. (See: #2058.)

Thank you for the fix, I can confirm this is fixed in 0.0.231.
I'm impressed it only took 9 days for: report to Ruff, report upstream to Rust TOML library, report upstream to the language-agnostic TOML test suite, then the test suite updated and released, then the TOML library updated and released, and then Ruff updated and released!

authors: charliermarsh henryiii hugovk messense

repo: charliermarsh/ruff


text:
PLC1901 false positives/incorrect response

code:
def bug(query: str | None):
    if query == "":
        ...
    else:
        ...

this should not be flagged as "" is different from None.
Additionally, ruff provides the following error:
 PLC1901 `query == ""` can be simplified to `query` as an empty string is falsey

This is inaccurate, it should be simplified to not query (if it wasn't possible for query to be None).
possible related issue but not the same: GH-3494

I think this is fixed by #3497.

I think this is fixed by #3497.

Only the second part. Linked PR does not touch the case where there is information about the variable type and the type is Union.

I'm seeing the not:
src/scikit_build_core/settings/sources.py:159:55: PLC1901 `self.env[name] != ""` can be simplified to `not self.env[name]` as an empty string is falsey

That's the backward "not", but also, the original was:
def ...(...) -> bool:
    return name in self.env and self.env[name] != ""

It's not valid to simply that without the incorrect not, as self.env[name] is probably not a bool, and and returns the last truthy value - without the not making it a bool, it's not a bool. IIRC, pylint might suggest wrapping it in bool. (A better way to simplify it would probably be to use get & truthiness, actually)
I don't think you need variable type info; pylint doesn't do full type checking, you just can only simplify in cases were it's known to be a bool, via not or wrapping in bool.

FWIW, Pylint treats these identically. Every example shared here is flagged by Pylint:
def bug(query: str | None):
    if query == "":
        ...
    else:
        ...

def f() -> bool:
    return name in self.env and self.env[name] != ""

Yields:
foo.py:1:0: C0114: Missing module docstring (missing-module-docstring)
foo.py:1:0: C0104: Disallowed name "foo" (disallowed-name)
foo.py:1:0: C0116: Missing function or method docstring (missing-function-docstring)
foo.py:2:7: C1901: Avoid comparisons to empty string (compare-to-empty-string)
foo.py:7:0: C0116: Missing function or method docstring (missing-function-docstring)
foo.py:7:0: C0103: Function name "f" doesn't conform to snake_case naming style (invalid-name)
foo.py:8:11: E0602: Undefined variable 'name' (undefined-variable)
foo.py:8:19: E0602: Undefined variable 'self' (undefined-variable)
foo.py:8:32: C1901: Avoid comparisons to empty string (compare-to-empty-string)
foo.py:8:32: E0602: Undefined variable 'self' (undefined-variable)
foo.py:8:41: E0602: Undefined variable 'name' (undefined-variable)

In tests/* we will ignore rule PLC1901 because we want to be sure results are empty strings.
[], {}, 0, False, and None are all falsey, but are not empty strings.

Yes, but most of the time, you either have something that's always a string, or you have an interface that can produce some of those other values, and you should also check to make sure it's a string. For example, x != "" will also be True if x is some other falsey value, which might then break the next line in your tests where you expect it to be a non-empty string. You could also overload a class to compare equal to an empty string. (I'd say this is not totally impossible to find, ROOT overloads classes to compare equal to None...)
There are certain types of tests where this can't be simplified (like testing custom __eq__), but I'd carefully think about it before doing an ignore on tests/**. But ignoring a rule is always fine, you don't have to accept any rule, and can disable them on patterns!
Above, I was only worried about the case where the value is not in a place where the bool is directly evaluated and can leak the value (and/or is itself not a boolean context unless inside if or bool())`. If Pylint does this (I'm running pylint on my codebase and don't have this rule disabled, and haven't seen an error here), then that's fine. I'd expect the pylint checks to behave like pylint.

Ahh, it's working now (0.256!). Pylint and Ruff are both happy. I think the not fix also fixed the FP.

Ahh, empty string comparisons is an optional checker in pylint. Okay, I'm happy, I'd want Ruff'd Pylint checker to behave like pylint. Though if it was a hair smarter and could tell boolean context (assert, if, bool()) from places that could see the result, that'd be an improvement, but I think that could be proposed to pylint first. :)

If I go to https://play.ruff.rs and in Settings enable PL and then in Source put:
s == ""  # Rasises PLC1901
s != ""  # Rasises PLC1901

Is there a syntax you would recommend or just # noqa: PLC1901 on all lines where we really want to test for empty str?

You can use "tests/<filename>" = ["PLC1901"] or put # ruff: noqa: PLC1901  at the top for a file that has multiple of these that you'd like to silence. I have checks for a series of attributes, and it's much more symmetric to write == "" for the ones that are empty strings, rather that to make it look like a bool, so that test file is a good candidate for this sort of disable. And for any file that has just one or two instances, after verifying they are correct, you can just pass --add-noqa to Ruff to get it to add the ignores for you per line.

Ah yeah, sorry, I should've mentioned that this is behind a Pylint extension.
I'm honestly a little tempted to remove this rule given the number of false positives 🙈 But I try to defer to upstream plugins, and so look to Pylint as a guide, and... it has the same behavior.

authors: CalumY Czaki cclauss charliermarsh henryiii onerandomusername


text:
config_template.yml: Add DeepSeek models to template

Deepseek uses the openai API.

thanks!

repo: charmbracelet/mods


text:
iOS showFullScreenButton not display fullscreen button.

iOS showFullScreenButton not display fullscreen button.
"react-native": "0.61.5",
"react-native-youtube-sdk": "^1.0.4",
Thank you for greate lib.

Hi, I have the same issue. +1
"react-native": "0.62.1",
"react-native-youtube-sdk": "^1.0.6",
@farad4y

same here :/

I have solved issue, new version will be released today
@bilalcorbacioglu @MacKentoch @ducpt2

This button is no longer visible

https://github.com/AaronDsilva97/react-native-youtube-sdk
Have forked this library and the full screen button is visible by default
There is something wrong with showFullScreenButton

repo: charmy/react-native-youtube-sdk


text:
Unexpected value NaN parsing y1 attribute.

null value for Y axis (hole in data) in combination with time series and Chartist.Interpolation.step() produces unexpected behavior:

Hello @WURMiL 👋
Chartist has recently been updated to version 1.0 with some new exciting changes like ESM and TypeScript support. The migration guide can be found right here.
Please let me know if the issue is still relevant to you so we can further investigate it!

authors: Arantiryo WURMiL

repo: chartist-js/chartist


text:
Negative bar chart downward facing

Feature Proposal
I want to be able to render bar chart inverted, so y value will be on top, negative y values will go down.
Possible Implementation
No response

@dmatis2 maybe I'm wrong but it's already working in this way. Codepen: https://codepen.io/stockinail/pen/oNarQmE
I think I misunderstand your need.

Oh nice, does it work when all data are below 0?

yes! I have changed the codepen. https://codepen.io/stockinail/pen/oNarQmE
Have a look again.

Great! Probably I have some silly mistake somewhere. Will check on pc later. Thanks


text:
rtl options for axis and labels

Currently, Chart.js supports right-to-left (RTL) layout for legends and tooltips, but other chart elements like axes, labels, and some other components still use left-to-right (LTR) format. This creates an inconsistency when building charts for RTL languages.
It would be helpful if Chart.js provided full RTL support for all chart elements, not just legends and tooltips. This would ensure that the entire chart aligns correctly for RTL languages, making it more cohesive and user-friendly.
If there's another solution or workaround to achieve this without needing options for every individual element, please let me know.

Maby I am understanding you wrong, in which case please correct me. But by default the labels for the ticks in the scales are centered. In which case it won't make a difference.
You can already set the alignment of the ticks to start or end  instead of center I think will give you the same effect you are looking for.

I was referring to the axis. If the Y-axis is positioned on the left side in the LTR direction, it should shift to the right side in the RTL direction, if possible.
Currently, in RTL mode, I can see that the legends are adjusting their position according to the RTL direction, but the axis remain aligned with the LTR layout.


text:
Issue with DonutChart in Safari

Expected Behavior
In this screenshot (left: Chrome v63.*, right Safari v10.1.2) you see two sets of three donut charts.
These charts hold statistics data (though there is no data at this moment).
screenshot
Actual Behavior
In Chrome and Firefox they are rendered as expected. In Safari however, the colors are reversed it seems. It also doesn't show the text in Safari.
We're using vue-chartjs as a wrapper for this package. The author of the package thought this issue we're having is not part of his package.
In our DonutChart.vue file we perform this code in the mounted() section:
this.addPlugin({
                id: 'donut-text-plugin',
                beforeDraw: function (chart) {
                    if (chart.config.options.elements.center) {
                        // Get ctx from string
                        let ctx = chart.chart.ctx;

                        // Get options from the center object in options
                        let centerConfig = chart.config.options.elements.center;
                        let fontStyle = centerConfig.fontStyle || 'Arial';
                        let txt = centerConfig.text;
                        let color = centerConfig.color || '#000';
                        // Start with a base fontsize of 30px
                        let size = centerConfig.fontSize || '30px';
                        let sidePadding = centerConfig.sidePadding || 20;
                        let sidePaddingCalculated = (sidePadding / 100) * (chart.innerRadius * 2);
                        ctx.font = size + ' ' + fontStyle;

                        //Get the width of the string and also the width of the element minus 10 to give it 5px side padding
                        let stringWidth = ctx.measureText(txt).width;
                        let elementWidth = (chart.innerRadius * 2) - sidePaddingCalculated;

                        // Find out how much the font can grow in width.
                        let widthRatio = elementWidth / stringWidth;
                        let newFontSize = Math.floor(30 * widthRatio);
                        let elementHeight = (chart.innerRadius * 2);

                        // Pick a new font size so it will not be larger than the height of label.
                        let fontSizeToUse = Math.min(newFontSize, elementHeight);

                        // Set font settings to draw it correctly.
                        ctx.textAlign = 'center';
                        ctx.textBaseline = 'middle';
                        let centerX = ((chart.chartArea.left + chart.chartArea.right) / 2);
                        let centerY = ((chart.chartArea.top + chart.chartArea.bottom) / 2);
                        ctx.font = fontSizeToUse + "px " + fontStyle;
                        ctx.fillStyle = color;

                        // Draw text in center
                        ctx.fillText(txt, centerX, centerY);
                    }
                }
            });

            // Overwriting base render method with actual data.
            this.renderChart(this.chartData, this.options);
        },

After console logging color (immediately after defining it) and reloading the page it looked like this: screenshot 2.
Apparently it fixed itself like that, even though it's been happening for at least two weeks...
Anyway, as you can see, on Safari the background is a bit darker and does not show the percentage in the center.
Does anyone know a fix for this?
Environment

vue.js version: 2.4.1
vue-chart.js version: 2.7.1
npm version: 5.3.0

@CrixuAMG sorry for the late reply. Does this still occur? Does it reproduce on slightly older safari versions like 10.1.1? I have a feeling this might be browser related but it can be hard to tell

The issue still occurs, yes.
I'll try it out later on an older version of Safari and let you know!

I tested this in Safari 11 on both OSX and iOS and this doesn't seem to reproduce in the docs.

A colleague of mine fixed the issue. It was because of the fact that Safari apparently does not allow 0% and 100% values.

authors: CrixuAMG etimberg


text:
Use data directly when parsing is disabled

Alternative to #6814 and #6815
Master:

PR:

Fixed the test. @benmccann can you add that to #6814 (and add the array maintenance required to pass it)?

I added the test to #6814. It passes it. There's no additional array maintenance required. It just replaces the entire array with the user-provided array, so we don't have to do work to keep them in sync

I think it's a bit confusing that when parsing's on we retrieve data from a different place than when parsing is off and that https://github.com/chartjs/Chart.js/pull/6814 is a bit more consistent in this regard

I kind of agree. #6814 uses a little more memory and is a bit faster on the _getParsed part.

Thank you for providing the test!

@benmccann @kurkle between this and #6814 which is preferred?

@etimberg my preference would be for #6814

authors: benmccann etimberg kurkle


text:
Get other annotations width from an annotation scriptable option.

Hey, thank's for this usefull plugin !
I would like to get the width of an annotation from within another annotation scriptable option (to place the 2nd annotation next to the first relative to the width of the 1st annotation).
I want to accomplish something like that:
annotation1: {
	type: 'label',
	xValue: () => 0,
	yValue: () => 1,
	content: () => "Annotation 1",
	padding: 5,
	color: 'black',
},

annotation2: {
	type: 'label',
	xValue: () => 0,
	yValue: () => 1,
	xAjust: (cxt) => {
		return ctx.chart.options.plugins.annotation.annotations.annotation1.width
	},
	content: () => "Annotation 2",
	padding: 5,
	color: 'black',
}

But the problem is ctx.chart.options.plugins.annotation.annotations.annotation1.width doesn't exists.
Is it possible to achieve ?
Thanks in advance.

@evenmind the width of an annotation is a property of the annotation elements which are NOT exported (and then expose).
There is a workaround to access to the elements but not documented and let me call it "private".
Let me ask you if the center of the first label must be the point you selected or not. If not, you could use position option to align them.
Make sense for you?

Anyway, even accessing to the loaded elements, you don't know the width of the label you want to change therefore it's quite difficult I guess.

I will check the private state in the meantime the next version is live, thanks.

I get undefined for window['chartjs-plugin-annotation']

I get undefined for window['chartjs-plugin-annotation']

Can you provide a sample to reproduce the issue?

I literally just
annotation2: {
	type: 'label',
	xValue: () => 0,
	yValue: () => 1,
	xAjust: (cxt) => {
		console.log(window['chartjs-plugin-annotation'])
	},
	content: () => "Annotation 2",
	padding: 5,
	color: 'black',
}

and get undefined. Maybe this is because I'm using vue-chartjs wrapper and it does not inject 'chartjs-plugin-annotation' in the window ?

Maybe this is because I'm using vue-chartjs wrapper and it does not inject 'chartjs-plugin-annotation' in the window ?

Yes, I think so. I think you are importing the plugin, something like:
import annotationPlugin from 'chartjs-plugin-annotation';

If yes, use annotationPlugin instance instead

If yes, use annotationPlugin instance instead
Works ! Thank you.

authors: evenmind stockiNail

repo: chartjs/chartjs-plugin-annotation


text:
求解 这是咋回事

(chatchat) D:\PycharmProjects\Langchain-Chatchat-master\libs\chatchat-server>python chatchat/cli.py kb --recreate-vs
2024-08-30 05:45:47.804 | WARNING  | chatchat.server.utils:detect_xf_models:107 - cannot connect to xinference host: http://127.0.0.1:9997, please check your configuration.
2024-08-30 05:45:47.809 | WARNING  | chatchat.server.utils:get_default_llm:205 - default llm model openai-api is not found in available llms, using qwen:7b instead
2024-08-30 05:45:47.840 | WARNING  | chatchat.server.utils:get_default_embedding:214 - default embedding model bge-m3 is not found in available embeddings, using quentinz/bge-large-zh-
2024-08-30 05:45:55.196 | WARNING  | chatchat.server.utils:get_default_llm:205 - default llm model openai-api is not found in available llms, using qwen:7b instead
2024-08-30 05:45:55.231 | WARNING  | chatchat.server.utils:get_default_embedding:214 - default embedding model bge-m3 is not found in available embeddings, using quentinz/bge-large-zh-
v1.5 instead
2024-08-30 05:45:55.241 | WARNING  | chatchat.server.utils:get_default_embedding:214 - default embedding model bge-m3 is not found in available embeddings, using quentinz/bge-large-zh-
v1.5 instead
2024-08-30 05:45:55.248 | WARNING  | chatchat.server.utils:get_default_embedding:214 - default embedding model bge-m3 is not found in available embeddings, using quentinz/bge-large-zh-
v1.5 instead
2024-08-30 05:45:55.253 | WARNING  | chatchat.server.utils:get_default_embedding:214 - default embedding model bge-m3 is not found in available embeddings, using quentinz/bge-large-zh-
v1.5 instead
2024-08-30 05:45:55.256 | ERROR    | chatchat.init_database:worker:61 - (sqlite3.OperationalError) unable to open database file
(Background on this error at: https://sqlalche.me/e/20/e3q8)

xinference 先把后端大模型跑起来，readme 中有写；

我想调用星火api，也用xinference吗
---原始邮件---
发件人: @.>
发送时间: 2024年8月30日(周五) 中午11:37
收件人: @.>;
抄送: @.@.>;
主题: Re: [chatchat-space/Langchain-Chatchat] 求解 这是咋回事 (Issue #4885)
xinference 先把后端大模型跑起来，readme 中有写；
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

我想调用星火api，也用xinference吗
…
---原始邮件--- 发件人: @.> 发送时间: 2024年8月30日(周五) 中午11:37 收件人: @.>; 抄送: @.@.>; 主题: Re: [chatchat-space/Langchain-Chatchat] 求解 这是咋回事 (Issue #4885) xinference 先把后端大模型跑起来，readme 中有写； — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

可以先把星火放到openai转接

我想调用星火api，也用xinference吗
…
---原始邮件--- 发件人: @.> 发送时间: 2024年8月30日(周五) 中午11:37 收件人: @.>; 抄送: @.@.>; 主题: Re: [chatchat-space/Langchain-Chatchat] 求解 这是咋回事 (Issue #4885) xinference 先把后端大模型跑起来，readme 中有写； — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

可以先把星火放到openai转接

authors: annanfree aximu smartadpole

repo: chatchat-space/Langchain-Chatchat


text:
FOR DISCUSSION: chore(style): add pylint checks

We use pylint in most of our codebases, many devs
add it to their dev cycle, and we commonly include pylint comments in our code which can help declare
intent when we have code that could be flagged by
pylint.
Notes: this does not block builds or tests

I think we should either gate on pylint (and get a good, well-tuned pylint config) or not use it at all. I'm not a big fan of the "in-between" solution.

You also don't want to end up with code full of pylint: disable comments that are there just to pass the gate. "well-tuned" is key. We've historically gated on the total number of pylint W/E/R errors, but not forced it to be zero. Hence the || true in tox.ini. That requires code or a tool (like Jenkins) than can parse, track, report, and gate on pylint error count.

I did some experimentation with this branch. It seems like the main checks we want pylint to do are C, E, and F (Convention, Error, and Fatal, respectively). There are a few exceptions. The R (Refactor) warnings are ostensibly useful, but they're mostly just "too-many-X" warnings, which I find to be a bit silly and arbitrary.
By playing around with the config and tweaking a couple of things, I came up with a small patch that gives us a perfect score, but keeps many of the critical checks in place:
diff --git a/pylintrc b/pylintrc
index 192b684..bf63a0c 100644
--- a/pylintrc
+++ b/pylintrc
@@ -1,7 +1,8 @@
 [Messages Control]
-# W0511: TODOs in code comments are fine.
-# W0142: *args and **kwargs are fine.
-disable=W0511,W0142
+enable=C,E,F
+disable=W,R,I,fixme,too-many-arguments,wildcard-import,no-absolute-import,bad-builtin,import-error
+# NOTE(larsbutler): import-error is a spurious message from a bug, it seems.
+# See https://bitbucket.org/logilab/pylint/issues/324/namespaces-and-virutlaenv.

 [BASIC]
 # Don't require docstrings on tests or Python Special Methods
diff --git a/simpl/git.py b/simpl/git.py
index 8d401a1..e501d77 100644
--- a/simpl/git.py
+++ b/simpl/git.py
@@ -600,6 +600,7 @@ class GitRepo(object):
         """Create an annotated tag."""
         return git_tag(self.repo_dir, tagname, message=message, force=force)

+    # pylint: disable=invalid-name
     def ls(self):
         """Return a list of *all* files & dirs in the repo.

diff --git a/tox.ini b/tox.ini
index 2df5a61..3392994 100644
--- a/tox.ini
+++ b/tox.ini
@@ -18,8 +18,7 @@ commands = nosetests {posargs} --with-doctest --with-coverage --cover-package=si
 # - tests may not have docstrings
 commands =
     flake8 setup.py simpl
-    # Skip linting errors; just write out a file that can be used for analysis
-    /bin/bash -c "pylint -f parseable {posargs:simpl} > pylint.log || true"
+    pylint simpl

 [flake8]
 #flake8 default settings

Let me know what you think!

@larsbutler this rc would disable all warning, refactor, and info messages?

@samstav Correct.

@samstav Those are the messages which are, in my opinion, not so important. flake8 should catch a lot of that.

@larsbutler - that's great! Thanks. I'm all for get something in and then tweak as we see fit. I'll update the patch.

LGTM, although I would like to know what @Pablosan thinks of this configuration, since he has opinions about pylint.

@larsbutler @ziadsawalha this looks great to me! Thanks for doing the research on this Lars. It looks very balanced to me.

authors: Pablosan larsbutler samstav ziadsawalha

repo: checkmate/simpl


text:
This is based on goindex not GDindex

Kindly mention it clearly on what platform its built on?
you have mentioned GDindex but i guess its based on goindex, if its built on goindex than can you make it or create new repository for GDindex?
bcoz my bot requires GDindex and it doesnt work on goindex.
I really love this theme and wanna use it.
thanks

When I naming the repo, I just only thought of a short form of Google Drive Index but Completely forgot that there is another index named GDIndex. So I mentioned that this theme is based on goindex in the readme.md :)

When naming the repo, I just only thought of a short form of Google Drive Index but Completely forgot that there is another index named GDIndex. So I mentioned that this theme is based on goindex in the readme.md :)

When naming the repo, I just only thought of a short form of Google Drive Index and completely forgot that there is another index named GDIndex. So later I mentioned that this theme is based on goindex in the readme.md :)

When naming the repo, I just only thought of a short form of Google Drive Index and completely forgot that there is another index named GDIndex. So later I mentioned that this theme is based on goindex in the readme.md :)

thanks for the response.
btw can u make this with GDindex?
and also can u add dual audio support so that we can switch audio from the player?

The video/audio compatibility in browsers is limited, open it with the local player. Then it is possible to switch between audio tracks

authors: askfriends cheems

repo: cheems/GDIndex


text:
Add log_file_name property to chef_client_scheduled_task

This way it doesn't use any attributes
Signed-off-by: Tim Smith tsmith@chef.io

Does this break stuff that rely on the old behavior?

Yep this is going to be a breaking change in a major release

repo: chef-cookbooks/chef-client


text:
docker_container :run action always times out after 20 seconds, even when using timeout property

Cookbook version
2.13.0
Chef-client version
12.17.44
Platform Details
Ubuntu 16.04.1 LTS
Scenario:
I am using docker_container resource, I started getting Docker::Error::TimeoutError: Container billing-app failed to change to running state after 20 seconds. I was trying to increase the timeout to 60 but no success.
Steps to Reproduce:
Using the timeout property in docker_container resource
docker_container 'billing-app' do
  ...
  timeout 60
end

Expected Result:
I am expecting the docker_container to wait 60 seconds for timeout and not 20
Actual Result:
> chef-client -l debug
...
  * docker_container[billing-app] action run[2017-02-07T17:15:10+02:00] INFO: Processing docker_container[billing-app] action run (cs-nix-billing-app::default line 48)
[2017-02-07T17:15:10+02:00] DEBUG: Skipping update of docker_container[billing-app]: has not changed any of the specified properties ...

    ================================================================================
    Error executing action `run` on resource 'docker_container[billing-app]'
    ================================================================================

    Docker::Error::TimeoutError
    ---------------------------
    Container billing-app failed to change to running state after 20 seconds

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/docker/libraries/helpers_container.rb:88:in `wait_running_state'
    /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:316:in `block (2 levels) in <class:DockerContainer>'
    /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:311:in `block in <class:DockerContainer>'
    /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:167:in `call_action'
    /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:345:in `block in <class:DockerContainer>'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/cs-nix-billing-app/recipes/default.rb

     48: docker_container 'billing-app' do
     49:   repo '.../billing-app'
             ...
     62:   timeout 60
     63:   end
     64:

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/cs-nix-billing-app/recipes/default.rb:48:in `from_file'

    docker_container("billing-app") do
      action [:run]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :docker_container
      ...
      timeout 60
      container_name "billing-app"
      connection #<Docker::Connection:0x00000003cdd748 @url="unix:///", @options={:socket=>"/var/run/docker.sock", :read_timeout=>60}>
      network_mode "default"
      api_version "1.24"
    end

    Platform:
    ---------
    x86_64-linux

[2017-02-07T17:15:31+02:00] INFO: Running queued delayed notifications before re-raising exception
[2017-02-07T17:15:31+02:00] DEBUG: Re-raising exception: Docker::Error::TimeoutError - docker_container[billing-app] (cs-nix-billing-app::default line 48) had an error: Docker::Error::TimeoutError: Container billing-app failed to change to running state after 20 seconds
/var/chef/cache/cookbooks/docker/libraries/helpers_container.rb:88:in `wait_running_state'
  /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:316:in `block (2 levels) in <class:DockerContainer>'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/mixin/why_run.rb:52:in `add_action'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:176:in `converge_by'
  /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:311:in `block in <class:DockerContainer>'
  (eval):2:in `block in action_start'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `instance_eval'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `compile_and_converge_action'
  (eval):2:in `action_start'
  /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:167:in `call_action'
  /var/chef/cache/cookbooks/docker/libraries/docker_container.rb:345:in `block in <class:DockerContainer>'
  (eval):2:in `block in action_run'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `instance_eval'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `compile_and_converge_action'
  (eval):2:in `action_run'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:145:in `run_action'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource.rb:622:in `run_action'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:69:in `run_action'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `block (2 levels) in converge'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `each'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `block in converge'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:96:in `converge'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:670:in `block in converge'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:665:in `catch'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:665:in `converge'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:704:in `converge_and_save'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:284:in `run'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:294:in `block in fork_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:282:in `fork'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:282:in `fork_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:247:in `block in run_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/local_mode.rb:44:in `with_server_connectivity'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:235:in `run_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:464:in `sleep_then_run_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:451:in `block in interval_run_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:450:in `loop'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:450:in `interval_run_chef_client'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:434:in `run_application'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:59:in `run'
  /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/bin/chef-client:26:in `<top (required)>'
  /usr/bin/chef-client:57:in `load'
  /usr/bin/chef-client:57:in `<main>'

Running handlers:
[2017-02-07T17:15:31+02:00] ERROR: Running exception handlers
Running handlers complete
[2017-02-07T17:15:31+02:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 30 seconds
[2017-02-07T17:15:31+02:00] DEBUG: Server doesn't support resource history, skipping resource report.
[2017-02-07T17:15:31+02:00] DEBUG: Audit Reports are disabled. Skipping sending reports.
[2017-02-07T17:15:31+02:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2017-02-07T17:15:31+02:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2017-02-07T17:15:31+02:00] DEBUG: Docker::Error::TimeoutError: docker_container[billing-app] (cs-nix-billing-app::default line 48) had an error: Docker::Error::TimeoutError: Container billing-app failed to change to running state after 20 seconds
/var/chef/cache/cookbooks/docker/libraries/helpers_container.rb:88:in `wait_running_state'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:316:in `block (2 levels) in <class:DockerContainer>'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/mixin/why_run.rb:52:in `add_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:176:in `converge_by'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:311:in `block in <class:DockerContainer>'
(eval):2:in `block in action_start'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `compile_and_converge_action'
(eval):2:in `action_start'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:167:in `call_action'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:345:in `block in <class:DockerContainer>'
(eval):2:in `block in action_run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `compile_and_converge_action'
(eval):2:in `action_run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:145:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource.rb:622:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:69:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `each'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:96:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:670:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:665:in `catch'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:665:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:704:in `converge_and_save'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:284:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:294:in `block in fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:282:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:282:in `fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:247:in `block in run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/local_mode.rb:44:in `with_server_connectivity'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:235:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:464:in `sleep_then_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:451:in `block in interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:450:in `loop'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:450:in `interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:434:in `run_application'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:59:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/bin/chef-client:26:in `<top (required)>'
/usr/bin/chef-client:57:in `load'
/usr/bin/chef-client:57:in `<main>'

>>>> Caused by Docker::Error::TimeoutError: Container billing-app failed to change to running state after 20 seconds
/var/chef/cache/cookbooks/docker/libraries/helpers_container.rb:88:in `wait_running_state'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:316:in `block (2 levels) in <class:DockerContainer>'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/mixin/why_run.rb:52:in `add_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:176:in `converge_by'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:311:in `block in <class:DockerContainer>'
(eval):2:in `block in action_start'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `compile_and_converge_action'
(eval):2:in `action_start'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:167:in `call_action'
/var/chef/cache/cookbooks/docker/libraries/docker_container.rb:345:in `block in <class:DockerContainer>'
(eval):2:in `block in action_run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:361:in `compile_and_converge_action'
(eval):2:in `action_run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/provider.rb:145:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource.rb:622:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:69:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `each'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:97:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/runner.rb:96:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:670:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:665:in `catch'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:665:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:704:in `converge_and_save'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/client.rb:284:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:294:in `block in fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:282:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:282:in `fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:247:in `block in run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/local_mode.rb:44:in `with_server_connectivity'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:235:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:464:in `sleep_then_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:451:in `block in interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:450:in `loop'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:450:in `interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application/client.rb:434:in `run_application'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/lib/chef/application.rb:59:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44/bin/chef-client:26:in `<top (required)>'
/usr/bin/chef-client:57:in `load'
/usr/bin/chef-client:57:in `<main>'
[2017-02-07T17:15:31+02:00] ERROR: docker_container[billing-app] (cs-nix-billing-app::default line 48) had an error: Docker::Error::TimeoutError: Container billing-app failed to change to running state after 20 seconds
[2017-02-07T17:15:31+02:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

OK so I now found that I should use running_wait_time, but whatever value I set for it the action times out
When running with Docker CLI ad same parameters (docker run ...), it runs the container fairly quick
Not sure how to continue investigating

Upgrading the cookbook to 2.14.3 seemed to resolve the issue

repo: chef-cookbooks/docker


text:
Fix load balancer test failures

@Vasu1105 I think this is ready for merge!
I reverted https://github.com/chef/chef-provisioning-aws/pull/552/commits/a464e484611228789c41b46bef441fe4c2760945 because that change effectively makes the . create_an_aws_load_balancer compare the exact same two values.
The first string passed to create_an_aws_load_balancer is used to lookup an aws_object based on the aws_object method. With the change you had, it was then comparing that object to another object looked up from AWS in the exact same way. So the expected and actual values were the same looked up object from AWS.
I fixed some of the comparison operator's failure to deal with Structs and I think this is ready for review now!

@NimishaS @Vasu1105 I think we want/need to get this merged before final release. Can you take a look?

LGTM @btm

LGTM

authors: NimishaS Vasu1105 btm tyler-ball

repo: chef/chef-provisioning-aws


text:
Chef Infra Server test matrix

Confidence that Chef Infra Server and Automate Infra API distributions do not contain regressions
Automated testing for the different topologies of Chef Infra Server.
The supported topologies for chef-server are:

Standalone
Tiered
External Postgres
External elasticsearch

The supported configurations are:

FIPS
With SSL for external postgres or elasticsearch
With Addons (manage + push-jobs)
Ipv6
Ldap

Please find more details in: https://docs.google.com/document/d/1l4fOu_zohLvWjKTFYs3-lgyqWzDwJ7WK35Eehj-DFs4/edit
A cross matrix of with scenarios from above topologies and configurations: (Sheet: test release plan) https://docs.google.com/spreadsheets/d/1_gwxdrMnUiV8t2noi8zs1HyGivtIGMEx9KbYriIw7BY/edit#gid=1411321437
Acceptance Criteria:

Developer / Release engineer is able to run a test suite testing different topologies in various configurations easily before release.
The tests give a clear indication incase of a failure with a certain topology or configuration.
The infrastructure is modular, it is easy to add/ change scenarios for testing. (A scenario is a combination of topologies and configurations)
If possible there is an ease of updating the package to stable after the test suite is run.
The pipeline can be run once a week perhaps or when desired?

Aha! Link: https://chef.aha.io/epics/CHEF-E-64

The integration tests have been in place for some time with the exception of habitat artifacts.
Testing of habitat artifacts will be tracked in #1744

authors: btm christopher-snapp

repo: chef/chef-server


text:
Add missing description to windows_service load_current_resource for idempotent check to be successful

When using windows_service to create/configure Windows services, if you specify a description, it will trigger a change on every execution due to the value not being discovered in load_current_value

Description
Discover the Windows Service description from win-32/service output.
Related Issue

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have run the pre-merge tests locally and they pass.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] If Gemfile.lock has changed, I have used --conservative to do it and included the full output in the Description above.
[ ] All new and existing tests passed.
[x] All commits have been signed-off for the Developer Certificate of Origin.

This is broken.  ServiceConfigInfo does not include a description field, do we even test things anymore?
https://github.com/chef/win32-service/blob/67a0f7ac46a5e0332d95867f1ee2e7cd733b9117/lib/win32/service.rb#L206-L217

@tpowell-progress this is still broken...

This is broken. ServiceConfigInfo does not include a description field, do we even test things anymore?

Yes, we have added an internal UAT process which is part of the longer timeframes between releases. However, the focus of those tests are generally product driven requests. My fault for not requesting an explicit test to validate the new code, but I'm assuming that the resource continues to work without the description, or else there would be kitchen-tests that would be failing in CI.

authors: bdwyertech jakauppila tpowell-progress

repo: chef/chef


text:
Added Phil Cogbill, fixed link.

Added Phil Cogbill
Description
Added Phil Cogbill to devops-kungfu
Fixed link above Phil Cogbill
Related Issue
None.
Types of changes
New adherent Phil Cogbill added.
Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have run the pre-merge tests locally and they pass.
[x] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] All commits have been signed-off for the Developer Certificate of Origin.

Signed-off-by: Julia Child juliachild@chef.io
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate open
source license and I have the right under that license to
submit that work with modifications, whether created in whole
or in part by me, under the same open source license (unless
I am permitted to submit under a different license), as
Indicated in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.

Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate open
source license and I have the right under that license to
submit that work with modifications, whether created in whole
or in part by me, under the same open source license (unless
I am permitted to submit under a different license), as
Indicated in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.

Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate open
source license and I have the right under that license to
submit that work with modifications, whether created in whole
or in part by me, under the same open source license (unless
I am permitted to submit under a different license), as
Indicated in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.

repo: chef/devops-kungfu


text:
Fix warning: Kernel#open is deprecated

Description
Opening URIs by redirecting through Kernel#open is deprecated as of Ruby 2.7 and is dropped in Ruby 3.0.
To unblock applications that use Ruby 3, we need to replace these calls with URI.open.
See also:

https://rubyreferences.github.io/rubychanges/2.7.html#network-and-web
https://github.com/ruby/open-uri/commit/53862fa35887a34a8060aebf2241874240c2986a

Related Issue
n/a
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have run the pre-merge tests locally and they pass.
[-] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[x] All commits have been signed-off for the Developer Certificate of Origin.

Build failure look unrelated:

STDERR: /opt/asdf/installs/ruby/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.4/lib/bundler/spec_set.rb:87:in `block in materialize': Could not find ffi-1.10.0 in any of the sources (Bundler::GemNotFound)

It is also happening in other MRs, e.g.: https://buildkite.com/chef-oss/chef-license-scout-master-verify/builds/140#f51d32ff-3efe-4342-9c6b-dc773e962cc4

@tduffield Could you or another maintainer do a code review and assist with fixing the build? Build failures do not look related to recent changes in pull requests.

There are also 3 tests that fail locally after a fresh checkout of the project when on master:
$ bundle exec rspec
...
Finished in 5.1 seconds (files took 0.3487 seconds to load)
157 examples, 3 failures

Failed examples:

rspec ./spec/license_scout/dependency_manager/bundler_spec.rb:134 # LicenseScout::DependencyManager::Bundler#dependencies bundler 2.x project returns an array of Dependencies found in the directory
rspec ./spec/license_scout/dependency_manager/cargo_spec.rb:86 # LicenseScout::DependencyManager::Cargo#dependencies cargo project returns an array of Dependencies found in the directory
rspec ./spec/license_scout/dependency_manager/mix_spec.rb:80 # LicenseScout::DependencyManager::Mix#dependencies returns an array of Dependencies found in the directory

testoutput.log
Will break out a separate issue for this.

Will break out a separate issue for this.

https://github.com/chef/license_scout/issues/265

@tduffield Could you or another maintainer do a code review and assist with fixing the build? Build failures do not look related to recent changes in pull requests.

Or @danielsdeleo maybe?

@mttkay Apologies for the delay; I'm out on PTO this week. I'll take a look at this first thing when I get back (next Tuesday).

@mttkay Apologies for the delay; I'm out on PTO this week. I'll take a look at this first thing when I get back (next Tuesday).

No worries! I happen to be out on PTO myself all of next week -- enjoy your time off and thanks for looking into it!

Okay, I've fixed the issue in the pipeline. You should be able to rebase on the latest master branch.

Excellent, thanks! I am traveling all day today, but should be able to get to this some time tomorrow :+1:

Thanks @tduffield, build is green now.

Thank you @tduffield for including this in 2.6.2 and tagging a new release. I am not familiar with the release cycle of Chef, but I noticed that the latest version on rubygems.org is still 2.5.1: https://rubygems.org/gems/license_scout
To adopt the new version, would we have to wait for a new Chef release, or is it possible to deploy 2.6.2 of license_scout to rubygems.org independently?

@mttkay the new ruby gem (2.6.2) exists now

Thanks @nkierpiec -- sorry to be a bother, but I only now realized that chef-omnibus actually pins license_scout to 1.x, so I cannot declare a dependency on 2.6.2. We're on omnibus 7, but even on master this is still pinned to 1.x+: https://github.com/chef/omnibus/blob/master/omnibus.gemspec#L31
Should this be ~> 2.0, since otherwise, no one will ever pull in the 2.x releases via a bundle update? :thinking:
I'm not very familiar with the chef ecosystem of libraries and dependencies so I could be missing something.

To illustrate:
Fetching https://dev.gitlab.org/gitlab/omnibus.git
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Bundler could not find compatible versions for gem "license_scout":
  In Gemfile:
    license_scout (~> 2.6.2)

    omnibus was resolved to 7.0.10, which depends on
      license_scout (~> 1.0)

Hey, @mttkay, not a bother, I am going to have to see if Tom has more insight on this since he has worked more closely with this product. @tduffield is this something you can clarify for @mttkay? Thanks!

@mttkay There are changes required to Omnibus in order to have it support LicenseScout 2.x. If you're having issues with 1.x, you can open a PR against the 1-stable branch, which is our release branch for 1.x.

Thanks all. I consulted with a co-worker as well, and it looks like we use a fork of Omnibus 7.0 so I was able to test these changes against our own repo; however, just requiring the newer licsense_scout version did not work because I ran into dependency errors with mixlib-shellout between what chef, omnibus and license_scout think it should be (chef and omnibus require or allow for 3.x, while license_scout pins it to 2.2).
I am now testing if we can relax that pin here: https://github.com/chef/license_scout/pull/269
Not sure I'm venturing in the right direction with this but I hope this will fix the problem.

authors: mttkay nkierpiec tduffield


text:
新增函数: Sattolo shuffle algorithm

Sattolo's algorithm is a shuffling algorithm that differs slightly from the standard Fisher-Yates (or Durstenfeld) shuffling algorithm. Its main purposes are:
To generate a random permutation where no element remains in its original position.
To create a random cyclic permutation (where each element moves to a new position).
This algorithm is particularly useful in certain specific scenarios, such as:
Creating a secret Santa gift exchange, ensuring no one draws their own name.
In certain games, ensuring each player moves to a new position.
In some algorithmic problems where a random permutation guaranteeing all elements change positions is needed.
Sattolo 算法是一种洗牌算法，但与标准的 Fisher-Yates（或 Durstenfeld）洗牌算法略有不同。其主要用途是：
生成一个随机排列，其中没有元素保持在原位置。
创建一个随机循环排列（每个元素都移动到一个新位置）。
这在某些特定场景下非常有用，例如：
创建一个秘密圣诞老人gift交换，确保没有人抽到自己。
在某些游戏中，确保每个玩家都移动到一个新位置。
在某些算法问题中，需要一个保证所有元素都改变位置的随机排列

感谢分享，测试用例很完善，点赞！

authors: chenbimo sikamedia

repo: chenbimo/yidash


text:
🛑 Homepage is down

In 04a1a8e, Homepage (https://larrychen.tech) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Homepage is back up in a39ff39.

repo: chendachao/uptime


text:
🛑 tt is down

In 5520de7, tt (https://telebot-app-serverless-i7z8-chenhaonanniubi.vercel.app/checkhealth) was down:

HTTP code: 500
Response time: 1656 ms

Resolved: tt is back up in 7ee513d after 10 minutes.

repo: chenhaonanniubi/upptime


text:
🛑 tt is down

In 7a93f64, tt (https://telebot-app-serverless-i7z8-chenhaonanniubi.vercel.app/checkhealth) was down:

HTTP code: 500
Response time: 2740 ms

Resolved: tt is back up in 6265f56.


text:
🛑 tt is down

In 2e6afa3, tt (https://telebot-app-serverless-i7z8-chenhaonanniubi.vercel.app/checkhealth) was down:

HTTP code: 500
Response time: 1903 ms

Resolved: tt is back up in 3e88677 after 45 minutes.


text:
🛑 tt is down

In ce67e1b, tt (https://telebot-app-serverless-i7z8-chenhaonanniubi.vercel.app/checkhealth) was down:

HTTP code: 500
Response time: 2428 ms

Resolved: tt is back up in 4cfb8ae.